COUPAT 2014 Archivage

UNIVERSITE DE REIMS CHAMPAGNE-ARDENNE
THESE
Présentée pour obtenir le grade de
Docteur de l’Université de Reims Champagne-Ardenne
Discipline
GÉNIE INFORMATIQUE, AUTOMATIQUE ET TRAITEMENT DU SIGNAL
Présentée et soutenue publiquement le 27 novembre 2014 par
Raphaël COUPAT
Méthodologie pour les études d’automatisation et la génération

automatique de programmes Automates Programmables Industriels
sûrs de fonctionnement
Application aux Equipements d’Alimentation des Lignes Electrifiées
Devant un jury composé de :

Rapporteurs :
M. Toguyeni Armand Professeur à l’Ecole Centrale de Lille
Mme Subias Audine Maître de conférences HDR à l’Université de Toulouse
Président du jury :
M. Lahaye Sébastien Professeur à l’Université d'Angers
Co-Encadrants de Thèse :
M. Philippot Alexandre Maître de conférences à l’Université de Reims Champagne-Ardenne
M. Annebicque David Maître de conférences à l’Université de Reims Champagne-Ardenne
M. Burette Marc-Axel Ingénieur à la SNCF
Directeur de Thèse :
M. Riera Bernard Professeur à l’Université de Reims Champagne-Ardenne
Remerciements
Mes remerciements s’adressent aux rapporteurs, Madame Subias Audine et Monsieur

Toguyeni Armand pour le temps et l’énergie consacrés à la lecture de ce mémoire de thèse,
ainsi qu’à l’examinateur Monsieur Lahaye Sébastien pour l’intérêt qu’il a porté à ce travail.
Je tiens à remercier les membres du CReSTIC qui m’ont accueilli avec beaucoup de
sympathie et ont soutenu mon travail. Je tiens notamment à remercier Monsieur le Professeur
Bernard Riera qui m’a accordé sa confiance en prenant la direction de cette thèse, qui m’a
guidé, corrigé et appris énormément tout au long de ces trois années de travail. Je le remercie
également pour m’avoir appris à prendre de la hauteur et du recul pour comprendre un
problème dans sa globalité. Je n’oublierai pas les meilleurs moments que nous avons partagés.
Je tiens également à remercier Monsieur Alexandre Philippot et Monsieur François Gellot qui
m’ont supporté tous les jours et ont partagé leurs connaissances scientifiques et culturelles. Je
remercie Monsieur David Annebicque pour ses idées et son point de vue informaticien qui ont
grandement contribué à l’avancement de cette thèse. Je garderai un très bon souvenir de ces
trois années passées à travailler avec vous. Enfin je tiens à remercier Madame Ida Lenclume
pour son travail formidable et sa bonne humeur.
Je tiens à remercier la direction du département PROJETS SYSTEME INGENIERIE de

Traction Electrique (PSIGT-TE), Monsieur Christian Courtois, Monsieur Dominique Gehl,
Monsieur Jean Chabas, Monsieur Didier Augros et Monsieur Stéphane Avronsart qui ont
soutenu et encouragé ce projet de recherche malgré les mouvements hiérarchiques. Je tiens à
exprimer ma reconnaissance à Monsieur Marc Meslay qui a soutenu et organisé l’intégration
du logiciel développé au sein de la section Conception et Expertise des Systèmes (CES2). Je
remercie également tous les membres de CES2 (ex ZU13) pour leur soutien, leurs
explications, leur implication dans le but d’aider à la réussite de ce projet de recherche. En
particulier je remercie Monsieur Vincent Gardet, Monsieur Hervé Caron et Monsieur Marc-
Axel Burette qui ont activement participé à la mise en place de ce projet, à son lancement, à
sa supervision et à son rayonnement. Je remercie Monsieur Gal Blaszczyk, Monsieur
Alexandre Bouaziz, Monsieur Sébastien Lefèbvre et Monsieur Alexandre Mendeiros pour
leur participation active en groupes de travail « métier » et aux essais du logiciel.
3
Je remercie bien entendu ceux qui m’ont supporté (dans les deux sens du terme) pendant les
étapes difficiles de cette thèse, mes parents, mes amis et ma chérie, Claire. Merci Papa,
Maman, d’avoir cru en moi, de m’avoir poussé à aller jusqu’au bout et de m’en avoir donné
les moyens. Merci Claire d’avoir été là pour t’occuper de moi jusqu’à la fin et de rendre ma
vie simplement parfaite. Enfin, merci à mes amis que je ne vais pas énumérer, pour leur joie
de vivre et l’équilibre qu’ils m’apportent.
4
Table des matières
REMERCIEMENTS ............................................................................................................................................. 3
TABLE DES MATIERES ....................................................................................................................................... 5
INDEX DES TABLEAUX ET DES FIGURES ............................................................................................................. 9
TABLEAUX .............................................................................................................................................................. 9
FIGURES .............................................................................................................................................................. 10
GLOSSAIRE, ABREVIATIONS ET SYMBOLES ..................................................................................................... 13
ABREVIATIONS ...................................................................................................................................................... 13
SYMBOLES ........................................................................................................................................................... 15
GLOSSAIRE : EXTRAIT DU REGLEMENT (S11, 2012) ..................................................................................................... 15
INTRODUCTION GENERALE ............................................................................................................................ 17
CHAPITRE 1 : LE METIER DES EALE .................................................................................................................. 23
1.1 INTRODUCTION............................................................................................................................................ 23
1.2 ORGANISATION DU RESEAU ELECTRIQUE ........................................................................................................... 23
1.2.1 Les systèmes de traction ferroviaire .............................................................................................. 23
1.2.2 Rôle des Sous-stations ................................................................................................................... 24
1.3 L’ALIMENTATION ELECTRIQUE......................................................................................................................... 26
1.3.1 L’alimentation en courant continu 1500 V .................................................................................... 27
1.3.2 L’alimentation en courant alternatif monophasé 25 KV 50 Hz ..................................................... 28
1.3.3 L’alimentation en courant alternatif 2x25KV 50 Hz ...................................................................... 29
1.3.4 Architecture d’un secteur caténaire 25KV ou 2x25KV ................................................................... 30
1.3.5 Architecture d’une sous-station 25KV/2x25KV .............................................................................. 31
1.4 SYSTEME DE CONTROLE/COMMANDE DES EALE................................................................................................. 32
1.4.1 Architecture SCADA ....................................................................................................................... 34
1.4.2 Architecture de Conduite Local et d’Automatismes ...................................................................... 35
1.4.2.1 Le système PA ...................................................................................................................................... 35
1.4.2.2 Le système SCLA .................................................................................................................................. 36
1.4.2.3 Les différents types d’abonnés ............................................................................................................ 38
1.5 SURETE DU FONCTIONNEMENT DU SYSTEME DE CONTROLE/COMMANDE ................................................................. 39
1.5.1 Définition de la sûreté du fonctionnement dans le domaine des EALE ......................................... 39
1.5.1.1 Fiabilité ................................................................................................................................................ 39
1.5.1.2 Maintenabilité ..................................................................................................................................... 40
1.5.1.3 Disponibilité......................................................................................................................................... 40
1.5.1.4 Sécurité des abonnés .......................................................................................................................... 40
1.5.1.5 Événement critique redouté ............................................................................................................... 41
1.5.1.6 Intégrité des données .......................................................................................................................... 41
1.5.2 Sûreté du fonctionnement des cartes Entrées/Sorties .................................................................. 41
1.5.2.1 Carte 4 Télé Commandes Doubles / 4 Télé Signalisations Doubles (4TCD/TSD).................................. 42
1.5.2.2 Carte 16 Télé Signalisations Simples (16 TSS) ...................................................................................... 42
1.6 PROGRAMMES BINAIRES OU NOYAU ISAGRAF ................................................................................................. 43
1.6.1 Description des programmes automates ...................................................................................... 45
1.6.1.1 Programme de la phase « Début » ...................................................................................................... 46
1.6.1.2 Programmes séquentiels (SFC) ............................................................................................................ 47
1.6.1.3 Programmes de fin de cycle ................................................................................................................ 47
1.6.2 Synthèse ........................................................................................................................................ 48
1.7 LE METIER DES EALE .................................................................................................................................... 48
1.8 CONCLUSION .............................................................................................................................................. 51
5
CHAPITRE 2 : ETUDE DES VOIES D’AMELIORATIONS POSSIBLES DU METIER DES EALE .................................... 53
2.1 INTRODUCTION............................................................................................................................................ 53
2.2 UNE APPROCHE « SYSTEME HOMME-MACHINE » DU METIER DES EALE ................................................................ 54
2.2.1 Composante économique et technique ......................................................................................... 56
2.2.2 Composante humaine ................................................................................................................... 56
ER
2.3 1 AXE D’AMELIORATION : LA GENERATION AUTOMATIQUE DE LIVRABLES ............................................................... 59
2.3.1 UML ou MDD pour la génération de code ? .................................................................................. 60
2.3.2 Principes de la génération de code par MDA et DSM .................................................................... 61
2.3.2.1 Principes du MDA ................................................................................................................................ 61
2.3.2.2 Principes du DSM................................................................................................................................. 64
2.3.2.3 Avantages de DSM pour le domaine spécifique métier ...................................................................... 65
2.3.3 Synthèse des deux philosophies MDA et DSM ............................................................................... 66
2.3.4 Examen des méthodes et des techniques de génération de code ................................................. 67
2.3.4.1 Les approches de génération de code ................................................................................................. 67
2.3.4.2 Les types de générateur de code ......................................................................................................... 67
2.3.4.3 Les techniques de génération du code ................................................................................................ 69
2.3.5 Solutions DSM pour les automatismes industriels......................................................................... 72
2.3.6 Présentation de la solution Odil de la société Prosyst ................................................................... 76
2.3.6.1 La solution Odil .................................................................................................................................... 77
2.3.6.2 Visual Standard : Solution de développement du Progiciel SNCF EALE ............................................... 77
2.3.7 Synthèse ........................................................................................................................................ 79
EME
2.4 2 AXE D’AMELIORATION : LA COMMANDE...................................................................................................... 80
2.4.1 Approches de conception de la commande : le cas des EALE ........................................................ 80
2.4.2 La SCT (Supervisory Control Theory) .............................................................................................. 84
2.4.3 La synthèse algébrique .................................................................................................................. 86
2.4.4 La commande par contraintes logiques ........................................................................................ 90
2.4.5 Validation et Vérification : V&V .................................................................................................... 94
2.5 CONCLUSION .............................................................................................................................................. 97
CHAPITRE 3 : PROPOSITION D’UNE METHODOLOGIE POUR LES ETUDES D’AUTOMATISATION .................... 101
3.1 INTRODUCTION.......................................................................................................................................... 101
3.2 CYCLE DE PRODUCTION DE LA METHODOLOGIE ................................................................................................. 104
3.3 REVERSE ENGINEERING ET DONNEES D’ENTREES VERS LA STANDARDISATION .......................................................... 107
3.4 DEMARCHE DE GENERATION DU CODE API ...................................................................................................... 108
3.4.1 Standardisation des programmes ............................................................................................... 108
3.4.2 Qualimétrie du code API .............................................................................................................. 109
3.4.3 Analyse par PLC Checker ............................................................................................................. 111
3.4.4 Formalisation des langages ......................................................................................................... 115
3.4.5 Analyse structurelle pour la modélisation du système ................................................................ 116
3.4.5.1 Décomposition de la Partie Opérative............................................................................................... 117
3.4.5.2 Décomposition de la Partie Commande ............................................................................................ 119
3.4.5.3 Liens entre PO et PC .......................................................................................................................... 120
3.4.6 Définition des templates de génération de code ......................................................................... 121
3.4.7 Outil de mise en œuvre de la génération .................................................................................... 123
3.5 DEMARCHE DE GENERATION DU FILTRE A BASE DE CONTRAINTES DE SECURITE ........................................................ 126
3.5.1 Définition du filtre robuste à base de contraintes ....................................................................... 128
3.5.1.1 Principe d’écriture des contraintes ................................................................................................... 130
3.5.1.2 Démarche de définition des contraintes ........................................................................................... 131
3.5.2 Propriétés des contraintes ........................................................................................................... 133
3.5.3 Algorithme de la commande basée sur les contraintes logiques ................................................ 135
3.5.3.1 Prise en considération des CSs et des CFs ......................................................................................... 136
3.5.3.2 Prise en considération des CSc .......................................................................................................... 139
3.5.4 Synthèse ...................................................................................................................................... 142
3.6 CONCLUSION ............................................................................................................................................ 143
6
CHAPITRE 4 : APPLICATION DE LA METHODOLOGIE AUX ETUDES D’AUTOMATISATION DES EALE ............... 145
4.1 INTRODUCTION.......................................................................................................................................... 145
4.2 ANALYSE DU SYSTEME ................................................................................................................................. 146
4.2.1 Partie HT ...................................................................................................................................... 148
4.2.2 Groupe Traction........................................................................................................................... 151
4.2.3 Départ Traction ........................................................................................................................... 153
4.2.4 Batterie de Condensateurs .......................................................................................................... 154
4.2.5 Communs..................................................................................................................................... 155
4.2.5.1 Barre 25kV ......................................................................................................................................... 156
4.2.5.2 Pontage ............................................................................................................................................. 156
4.3 STANDARDISATION ET ANALYSE DU CODE ........................................................................................................ 157
4.3.1 Etudes des principes d’automatisation des EALE ........................................................................ 158
4.3.2 Etude minutieuse des programmes pour la standardisation ...................................................... 158
4.3.3 Analyse des résultats PLC Checker............................................................................................... 159
4.4 FORMALISME DES LANGAGES........................................................................................................................ 163
4.4.1 Structure de fichiers IsaGraf 3.32 ................................................................................................ 163
4.4.2 Grammaire du fichier source du dictionnaire .............................................................................. 164
4.4.3 Grammaire du fichier source d’un sous-programme ................................................................... 165
4.4.4 Grammaire du fichier source d’un sous-programme Ladder Diagram ........................................ 165
4.5 DEFINITION DE LA STRUCTURE DU MODELE ...................................................................................................... 168
4.5.1 Méta-modèle et modèle de PO ................................................................................................... 168
4.5.2 Modèle d’associations entre PO et PC ......................................................................................... 170
4.5.3 Modèles des SePO ....................................................................................................................... 171
4.6 GENERATION DE CODE ET DOCUMENTS........................................................................................................... 172
4.6.1 Choix d’une solution pour la génération de livrables .................................................................. 172
4.6.2 Odil GREMLINS ............................................................................................................................ 175
4.7 DEFINITION DES TEMPLATES DANS VISUAL STANDARD ....................................................................................... 183
4.7.1 Génération des fichiers d’un projet ............................................................................................. 183
4.7.2 Template d’un fichier ST .............................................................................................................. 184
4.7.3 Template d’un fichier LD.............................................................................................................. 186
4.8 AGILITE DE LA DEMARCHE D’AMELIORATION METIER ......................................................................................... 190
4.9 CONSEQUENCES SUR LE WORKFLOW DES CHARGES D’ETUDES ............................................................................. 193
4.10 ANALYSE DES QUESTIONNAIRES UTILISATEURS .................................................................................................. 197
4.10.1 Quelles attentes de la solution ?............................................................................................. 197
4.10.2 Utilisation ............................................................................................................................... 197
4.10.3 Gains ....................................................................................................................................... 198
4.10.4 Synthèse des résultats ............................................................................................................ 199
4.11 CONCLUSION ............................................................................................................................................ 200
CHAPITRE 5 : APPLICATION DE LA COMMANDE PAR CONTRAINTES AUX EALE ............................................. 203
5.1 INTRODUCTION.......................................................................................................................................... 203
5.2 SPECIFICATION D’UN POSTE DE MISE EN PARALLELE ET DE SES FONCTIONS .............................................................. 205
5.2.1 Principe fonctionnel du RAP actuel.............................................................................................. 207
5.2.2 Programmes API actuels ............................................................................................................. 209
5.2.2.1 Programme de Commande de l’IMP ................................................................................................. 210
5.2.2.2 Programme de la fonction DAP ......................................................................................................... 211
5.2.2.3 Programme de la fonction RAP ......................................................................................................... 211
5.3 PROPOSITION D’UNE COMMANDE RAP SEQUENTIELLE ...................................................................................... 213
5.4 DEMARCHE DE GENERATION DE LA COMMANDE SURE POUR LES POSTES DE MISE EN PARALLELE ................................. 216
5.4.1 Définition des observateurs et des contraintes ........................................................................... 217
5.4.1.1 Description des observateurs ............................................................................................................ 217
5.4.1.2 Contraintes de Sécurité simples ........................................................................................................ 220
5.4.1.3 Contraintes de Sécurité combinés ..................................................................................................... 222
5.4.2 Contraintes Fonctionnelles simples ............................................................................................. 224
5.4.3 Prise en considération des CSs et des CFs .................................................................................... 224
5.4.4 Prise en considération des CSc .................................................................................................... 225
7
5.5 PROPOSITION D’INTEGRATION DE LA COMMANDE ACTUELLE DANS LE DESIGN PATTERN
DE LA COMMANDE PAR CONTRAINTES ............................................................................................................. 227
5.6 VERIFICATION PAR MODEL-CHECKING ............................................................................................................. 229
5.6.1 Présentation d’UPPAAL ............................................................................................................... 229
5.6.2 Modèle de Partie Opérative ........................................................................................................ 230
5.7 VERIFICATION DES COMMANDES ................................................................................................................... 235
5.8 CONCLUSION ............................................................................................................................................ 240
CONCLUSION GENERALE ET PERSPECTIVES................................................................................................... 243
BIBLIOGRAPHIE ............................................................................................................................................ 251
ANNEXES ...................................................................................................................................................... 263
ANNEXE 1 : REGLES PLC CHECKER.......................................................................................................................... 263
Règles de Nommage ............................................................................................................................................... 263
Règles sur les Commentaires .................................................................................................................................. 263
Règles d’Ecriture ..................................................................................................................................................... 263
Règles de Structuration .......................................................................................................................................... 263
Informations Utiles ................................................................................................................................................. 264
ANNEXE 2 : MODELES D’UNE SOUS-STATION ............................................................................................................ 265
ANNEXE 3 : COMPARAISON TECHNIQUE DE DEUX SOLUTIONS ....................................................................................... 268
ANNEXE 4 : MONTAGE FINANCIER DES SOLUTIONS DE GENERATION DE CODE .................................................................. 269
Montage financier de la solution : Développement d’une solution ........................................................... 269
Montage financier du développement phase 1 ......................................................................................... 270
Montage financier de la solution : Odil Gremlins ...................................................................................... 271
Montage financier d’Odil Gremlins ............................................................................................................ 272
Synthèse des coûts de développement et de maintenance des solutions ................................................. 272
ANNEXE 5 : ETUDE FINANCIERE .............................................................................................................................. 274
Etude des gains potentiels des solutions ................................................................................................... 274
5.8.1 Calcul des bénéfices ..................................................................................................................... 278
5.8.2 Calcul du temps de rentabilisation du projet ............................................................................... 279
ANNEXE 6 : FICHES DU CAHIER DE RECETTE DE L’IMP ................................................................................................. 281
ANNEXE 7 : CODE DE LA COMMANDE A : APPLICATION DU DESIGN PATTERN A LA COMMANDE LA PLUS PERMISSIVE ............... 283
ANNEXE 8 : CODE DE LA COMMANDE B : COMMANDE ACTUELLE SNCF TRADUITE ........................................................... 289
ANNEXE 9 : CODE DE LA COMMANDE C : APPLICATION DU DESIGN PATTERN A LA COMMANDE ACTUELLE SNCF TRADUITE ...... 292
ANNEXE 10 : QUESTIONNAIRES DES UTILISATEURS DE LA SOLUTION ODIL GREMLINS ........................................................ 300
Réponse n°1 ............................................................................................................................................... 300
Réponse n°2 ............................................................................................................................................... 303
Réponse n°3 ............................................................................................................................................... 306
ANNEXE 11 : DICTIONNAIRE DES VARIABLES ............................................................................................................. 309
ANNEXE 12 : VERIFICATION DES PROPRIETES SOUS UPPAAL ....................................................................................... 310
Commande A ............................................................................................................................................. 310
Commande B ............................................................................................................................................. 311
Commande C.............................................................................................................................................. 312
8
Index des Tableaux et des Figures
Tableaux
Tableau 1 : Tableau descriptif des EALE et des fonctions élémentaires associées ................. 31
Tableau 2 : Tableau des éléments fonctionnels PA .................................................................. 36
Tableau 3 : Eléments fonctionnels des abonnés du SCLA ....................................................... 38
Tableau 4 : Temps limité pour chaque étape du projet ............................................................ 50
Tableau 5 : Comparaison des méthodes de génération d’après Völter .................................... 71
Tableau 6 : Variables ayant un nom trop court ...................................................................... 162
Tableau 7 : Récapitulatif des fichiers textes du dossier d’un abonné automate ..................... 165
Tableau 8 : Type de contact ................................................................................................... 165
Tableau 9 : Type de bobine .................................................................................................... 166
Tableau 10 : Type de Bloc fonctionnel .................................................................................. 166
Tableau 11 : Synthèse de coûts de développement et de maintenance des solutions ............ 174
Tableau 12 : Récapitulatif des fichiers textes du dossier d’un abonné automate ................... 183
Tableau 13 : Comparaison des étapes projets actuelles et des étapes projet
avec Odil GREMLINS pour les projets d’électrification de sous-stations ....... 194
Tableau 14 : Comparaison des étapes projets actuelles et des étapes projet
avec Odil GREMLINS pour les projets d’électrification de postes .................. 195
Tableau 15 : Synthèse des gains annuels de la solution Odil GREMLINS ........................... 196
Tableau 16 : Résultats de la vérification des propriétés des commandes étudiées ................ 239
Tableau 17 : Comparaison détaillée des deux solutions ........................................................ 268
Tableau 18 : Coûts de développements annuels et d’exploitation en dernière année ............ 270
Tableau 19 : Récapitulatif du devis établi par Prosyst ........................................................... 272
Tableau 20 : Coûts de développements annuels et d’exploitation en dernière année ............ 272
Tableau 21 : Synthèse de coûts de développement et de maintenance des solutions ............ 273
Tableau 22 : Etude des gains annuels pour les sous-stations ................................................. 275
Tableau 23 : Etude des gains annuels pour les postes ............................................................ 277
Tableau 24 : Etude des bénéfices réalisables ......................................................................... 278
Tableau 25 : Etude du temps de rentabilisation des solutions................................................ 279
Tableau 26 : Dictionnaire des variables utilisées dans le chapitre 5 ...................................... 309
9
Figures
Figure 1 : Schéma d’alimentation d’une ligne par les sous-stations. ....................................... 25

Figure 2 : Représentation simple d’une sous-station 1,5 KV et 25 KV ................................... 26
Figure 3 : Schéma d’alimentation des caténaires en 1500V .................................................... 28
Figure 4 : Schéma d’alimentation des caténaires en 25KV ..................................................... 29
Figure 5 : Schéma d’alimentation des lignes en 2x25KV ........................................................ 30
Figure 6 : Schéma unifilaire de la sous-station de Commune (2x25KV) ................................ 32
Figure 7 : Schéma de l’architecture hiérarchisée de contrôle/commande. ............................... 33
Figure 8 : Synoptique de la CLE de la sous-station de Velars ................................................. 33
Figure 9 : Photo du Central Sous-Station de Paris Rive Gauche ............................................. 34
Figure 10 : Représentation de la chaîne de communication ..................................................... 36
Figure 11 : Schéma de l’architecture distribuée du contrôle/commande au sein
des sous-stations. ................................................................................................... 37
Figure 12 : Représentation de la carte 4 TCD/TSD de l’ACS21 ............................................. 42
Figure 13 : Représentation d’une carte 16 TSS de l’ACS21. ................................................... 43
Figure 14 : Cycle API des cibles IsaGraf 3.32 ......................................................................... 45
Figure 15 : Vue ISaGRAF 3.32 : Gestion d’un projet et découpage temporel ........................ 45
Figure 16 : Découpage des phases d’un projet d’électrification .............................................. 49
Figure 17 : Courbe en U inversé montrant l’influence de la charge de travail sur la
performance (loi de Yerkes & Dodson, 1908). ..................................................... 58
Figure 18 : Exemple « métier » des modèles composant le MDA ........................................... 62
Figure 19 : DSM des services financiers d’une assurance (http://www.metacase.com) .......... 65
Figure 20 : Schéma de la méthode basée sur les templates et le filtrage ................................. 69
Figure 21 : Schéma de la méthode basée sur les templates et le méta-modèle ........................ 69
Figure 22 : Schéma de la méthode basée sur les IPA............................................................... 70
Figure 23 : Schéma de la méthode de génération « in-line » ................................................... 70
Figure 24 : Schématisation de la structure Progiciel d’Odil .................................................... 78
Figure 25 : Processus de conception pour les systèmes de contrôle/commande logique (Baresi
et al., 2000). ........................................................................................................... 81
Figure 26 : interprétation de Balemi (Balemi, 1993) ............................................................... 85
Figure 27 : Les quatre étapes de la méthode (Hietter, 2009) ................................................... 87
Figure 28 : Approches par filtre (à compléter avec les E/S) .................................................... 90
Figure 29 : Démarche de vérification des contraintes (Marangé, 2008) .................................. 91
Figure 30 : Sécurisation de la commande avant l’implémentation .......................................... 93
Figure 31 : Deux axes de recherche pour une méthodologie d’amélioration métier à trois
composantes .......................................................................................................... 98
Figure 32 : Application de la standardisation, de la génération automatique de livrables et du
filtre robuste de commande aux EALE ................................................................. 99
Figure 33 : Méthodologie pour les études d’automatisation et la génération automatique
de livrables .......................................................................................................... 103
Figure 34 : Représentation du développement itératif incrémental ....................................... 104
Figure 35 : Décomposition de la méthode du cycle itératif incrémental ............................... 105
Figure 36 : Démarche de génération du code API ................................................................. 106
Figure 37 : Méthode d’analyse des programmes ................................................................... 110
Figure 38 : La norme ISO 9126 définit 6 principes caractéristiques de la méthode Software
QUAlity Requirements and Evaluation (SQUARE) ............................................ 110
Figure 39 : Technique basée sur les templates, le méta-modèle du métier et la grammaire de
l’Interface de Programmation .............................................................................. 116
10
Figure 40 : Méta-modèle de la Partie Opérative .................................................................... 117
Figure 41 : Modèle simplifié d’une sous-station .................................................................... 118
Figure 42 : Méta-modèle de la Partie Commande .................................................................. 119
Figure 43 : Méta-modèle des connexions entre PO et PC...................................................... 120
Figure 44 : Méthode de définition des templates distribués................................................... 122
Figure 45 : Workflow pour la génération de code et de livrables ........................................... 124
Figure 46 : Démarche de génération de la commande par contraintes (en noir).................... 125
Figure 47 : Espace de commande du système ........................................................................ 126
Figure 48 : Modélisation du cycle API synchronisé par rapport à la PO ............................... 128
Figure 49 : Structure interne du filtre robuste ........................................................................ 131
Figure 50 : Démarche de définition des contraintes ............................................................... 133
Figure 51 : Schéma d’entrées et sorties de l’algorithme (et de son Design Pattern) ............. 136
Figure 52 : Exemple pédagogique .......................................................................................... 138
Figure 53 : Exemple avec des caractéristiques fonctionnelles correctes................................ 138
Figure 54 : Exemple avec des caractéristiques fonctionnelles fausses .................................. 139
Figure 55 : Algorithme de commande sûre de fonctionnement ............................................. 141
Figure 56 : Schéma unifilaire de la sous-station de Commune (2x25kV) ............................. 147
Figure 57 : Schéma unifilaire de la partie HT ........................................................................ 148
Figure 58 : Schéma de la partie Haute Tension pour un raccordement RTE en piquage ou en
antenne. ................................................................................................................ 150
Figure 59 : Schéma unifilaire d’un Groupe Traction avec commutateurs de phases ............. 151
Figure 60 : Schéma de mise en œuvre de l’architecture de contrôle/commande/protection du
Groupe Traction .................................................................................................. 152
Figure 61 : Schéma de mise en œuvre de l’architecture de contrôle/commande des
commutateurs de phases ...................................................................................... 152
Figure 62 : Schéma unifilaire de deux Départs Traction........................................................ 153
Figure 63 : Schéma de mise en œuvre de l’architecture de contrôle/commande/protection d’un
Départ Traction .................................................................................................... 154
Figure 64 : Schéma unifilaire d’une batterie de condensateurs.............................................. 154
Figure 65 : Schéma de mise en œuvre de l’architecture de contrôle/commande/protection
d’une batterie de condensateurs .......................................................................... 155
Figure 66 : Schéma unifilaire d’une barre 25kV .................................................................... 156
Figure 67 : Schéma unifilaire de deux pontages (un pontage par voie) ................................. 156
Figure 67 : Programme LD : exemple de l’ouverture de l’IMP par manque tension ............ 167
l’Interface de Programmation .............................................................................. 167
Figure 69 : Méta-modèle de la Partie Opérative .................................................................... 169
Figure 70 : Modèle d’une sous-station 25kV ......................................................................... 169
Figure 71 : Méta-modèle des connexions entre PO et PC...................................................... 170
Figure 72 : Modèle d’un Groupe Traction ............................................................................. 171
Figure 73 : Graphique des résultats comparés........................................................................ 173
Figure 76 : Vue de définition des défauts d’un Groupe Traction ........................................... 177
Figure 77 : Vue de synthèse par abonné (TCD/TSD, TSS, paramètres) ................................ 178
Figure 78 : Vue de connexion des appareils sur une carte 4TCD/TSD ................................. 179
Figure 79 : Vue de description de l’architecture SCLA ......................................................... 180
Figure 80 : Synthèse des TSS généré ..................................................................................... 181
Figure 81 : Exemple de fiche de recette générée (Arrêt Automate) ....................................... 182
Figure 82 : Rung en langage LD de construction de l’observateur defTR ............................. 186
Figure 83 : Rung en langage LD de la fonction de report de protection entre GT ................. 188
Figure 84 : Développement Agile du progiciel Odil GREMLINS ........................................ 191
11
Figure 85 : Extrait des programmes générés de La Voulzie .................................................. 192
Figure 86 : Mise en place du châssis de contrôle/commande de La Voulzie intégrant les
programmes API générés par Odil GREMLINS ................................................. 192
Figure 87 : Workflow pour la génération de code et de livrables ........................................... 193
Figure 88 : Intégration du Design Pattern permettant d’obtenir une commande sûre de
fonctionnement dans la méthodologie pour les études d’automatisation ............ 204
Figure 89 : Schéma d’exploitation simplifié d’un secteur électrifié en 25kV........................ 205
Figure 90 : Chronogramme du fonctionnement RAP sur défaut fugitif ................................ 206
Figure 91 : Chronogramme du fonctionnement RAP sur défaut persistant ........................... 207
Figure 92 : Mise en œuvre du système de contrôle/commande du poste de mise
en parallèle .......................................................................................................... 207
Figure 93 : GRAFCET de commande d’un IMP ................................................................... 210
Figure 94 : Construction de la variable OoIMP en langage Ladder Diagram (IEC 61131-3) 211
Figure 95 : Fonction RAP en langage Ladder (IEC 61131-3, 2003) ..................................... 212
Figure 96 : GRAFCET de surveillance du temps écoulé avant RAP (RSU) ......................... 213
Figure 97 : GRAFCET de gestion du RAP ............................................................................ 215
Figure 98 : Démarche de définition des contraintes ............................................................... 217
Figure 99 : GRAFCETs de commande IMP de l’opérateur ................................................... 218
Figure 100 : GRAFCET de gestion de la fonction RAP ........................................................ 219
Figure 101 : GRAFCET de suivi des tensions U1 et U2 pendant le RAP ............................. 220
Figure 102 : Décomposition de l’espace de liberté du système ............................................. 227
Figure 103 : Design Pattern de la commande par contraintes en tant que filtre de la
commande existante .......................................................................................... 228
Figure 104 : Décomposition temporelle cyclique du système ............................................... 231
Figure 105 : Modèle d’évolution des tensions ....................................................................... 232
Figure 106 : Modèle d’évolution des appareils ...................................................................... 232
Figure 107 : Modèle de commande opérateur ........................................................................ 233
Figure 108 : Modèle de temporisation ................................................................................... 234
Figure 109 : Représentation des trois commandes testées ..................................................... 238
Figure 110 : Méthodologie pour les études d’automatisation et la génération automatique de
livrables ............................................................................................................. 244
Figure 111 : Modèle de la Partie Opérative ........................................................................... 265
Figure 112 : Modèle du Groupe Traction ............................................................................... 265
Figure 113 : Modèle du Départ Traction ................................................................................ 266
Figure 114 : Modèle de la Batterie de Condensateurs ........................................................... 266
Figure 115 : Modèle des sous-ensembles de Partie Opérative Communs ............................. 267
Figure 116 : Modèle des éléments de Partie Opérative Communs ........................................ 267
Figure 117 : Cycle en V du développement logiciel .............................................................. 269
Figure 118 : Cycle en V de développement d’un progiciel .................................................... 271
Figure 119 : Vérification des propriétés de la commande A .................................................. 310
Figure 120 : Vérification des propriétés de la commande B .................................................. 311
Figure 121 : Vérification des propriétés de la commande C .................................................. 312
12
Glossaire, abréviations et symboles
Abréviations
Abréviations Décompositions
AA Abonné Automate
API Automate Programmable Industriel
ACS Automate de Conduite Sécurisée
Batt. K Batterie de Condensateurs
BT Basse Tension
CES Conception et Expertise des Systèmes
CdCF Cahier des Charges Fonctionnelles
CdG (WD) Chien de Garde (ou WatchDog)
CF Contrainte Fonctionnelle
CFs Contrainte Fonctionnelle simple
CF Commande Fermeture
CO Commande Ouverture
CG Contrôle Général
CSc Contrainte de Sécurité combinée
CSs Contrainte de Sécurité simple
CSS Central Sous-Station
CLE Commande Locale Ecran
CReSTIC Centre de Recherche en STIC
DAP Déclenchement Automatique des Parallèles
Déf. C Défaut Complémentarité sur TSD ou TSS
DJ Disjoncteur
DSM Domain Specific Modeling
DT Départ Traction
EALE Equipement d’Alimentation des Lignes Electrifiées
ElPO Elément de Partie Opérative
EN Norme Européenne
FMDS Fiabilité Maintenabilité Disponibilité Sécurité
FICTIF Organe interne à l’équipement de télécommande servant de test
FIP Factory Information Protocol (RLI du SCLA)
FG Fournié Grospaud
GREMLINS GénéRateur Evolutif du Modèle et des LIvrables des Nouvelles Sous-stations
GT Groupe Traction
HT Haute Tension
IEC International Electrotechnical Commission
IFTE Installation Fixe de Traction Electrique
IHM Interface Homme Machine
IMP Interrupteur de Mise en Parallèle
IPA Interface de Programmation d’Application
LD Ladder Diagram (langage de programmation API)
LDI Led de contrôle du mode de commande « Local Individuel »
LGV Ligne à Grande Vitesse
LS Ligne Spécialisée (quarte téléphonique pour les applications SNCF)
13
Abréviations Décompositions
MDA Model Driven Architecture
MDD Model Driven Development
ODIL Outil Description d’Ilots
Organe Désigne une TC, TSS ou TM
PA Poste Asservi (aussi appelé Équipement de Télécommande)
PC Partie Commande
PLC Programmable Logic Controller, acronyme anglais pour API
PO Partie Opérative
PSIGT Département PROJETS SYSTEME INGENIERIE (SNCF)
PSIGT-TE Département PROJETS SYSTEME INGENIERIE Traction Electrique
RAP Réenclenchement Automatique des Parallèles
RFF Réseau Ferré de France
RFN Réseau Ferré National
RLI Réseau Local Industriel
RSS Régulateur Sous-Station
RTU Remote Terminal unit
RTE Réseau de Transport d’Electricité
SCLA Système de Conduite Locale et d’Automatismes
Sect Sectionneur
SePO Sous Ensemble de Partie Opérative (découpage fonctionnel GT, DT…)
SF Signalisation position fermée de l’appareil
SFC Sequential Function Chart (langage de programmation API)
SIL Security Integrity Level
SHM Système Homme Machine
SNCF Société Nationale des Chemins de Fer français
SO Signalisation position ouverte de l’appareil
SP (poste) Poste de sectionnement et de mise en parallèle
SRB Sectionneur à Rupture Brusque
SSL Signalisation Simple Locale
SCT Supervisory Control Theory
ST Structured Text (langage de programmation API)
STIC Sciences et Technologies de l'Information et de la Communication
TC Organe de Télé Commande
TCO Tableau de Contrôle Optique
TCD Télé Commande Double
TPL Tourner Pousser Lumineux
TSD Télé Signalisation Double (associée à une TCD)
TSS Télé Signalisation Simple
TM Télé Mesure
U (U1, U2) Tension (présence tension voie 1, présente tension voie 2)
URCA Université de Reims Champagne-Ardenne
UTE Union Technique de l'Electricité
XML eXtensible Markup Language
14
Symboles
Notations Symboles Significations
S Sectionneur
Dj Disjoncteur
Int Interrupteur
Tt Transformateur en Tension
Tc Transformateur en Courant
TSA Transformateur de Services Auxiliaires
T Transformateur de Groupe Traction
R Redresseur
Glossaire : extrait du règlement (S11, 2012)
Caténaire : Ensemble distribuant le courant aux engins moteurs électriques par l’intermédiaire
de pantographes et constitué par les fils de contact, câbles porteurs, feeders, pendules et toutes
pièces intercalées entre ces éléments et les isolateurs séparant les parties sous tension des
supports ou les caténaires entre elles.
Circuit de retour du courant de traction : Ensemble des circuits électriques (rails de roulement,
connexions électriques, …) qui permettent le retour du courant de traction aux sous-stations.
Circulation électrique : toute circulation comportant au moins un pantographe.
Circuit en charge : Circuit dans lequel s’opère un débit de courant électrique.
15
Circuit à vide : Circuit sans débit appréciable de courant électrique.
Appareil d’interruption : Permet d’assurer une continuité électrique en position fermée et

d’interrompre celle-ci en position ouverte.
Disjoncteur : appareil d’interruption, manœuvrable à vide et en charge, destiné à ouvrir ou

fermer un circuit et capable d’interrompre automatiquement un courant de défaut. Sa capacité
à éliminer un défaut est appelée "pouvoir de coupure".
Interrupteur : Appareil d’interruption, manœuvrable à vide ou en charge, destiné à ouvrir ou

fermer volontairement un circuit. Certains interrupteurs peuvent s’ouvrir automatiquement.
Sectionneur : Appareil d’interruption, destiné à ouvrir ou fermer volontairement un circuit.

Les sectionneurs ne peuvent être ouverts qu’à vide.
Secteurs : Ensemble des installations alimentées normalement par un ou plusieurs

disjoncteurs.
Section élémentaire : Plus petit élément de caténaire pouvant être isolé par des appareils
d’interruptions.
Section commutable : Section caténaire pouvant être alimentée sous tensions différentes.
Section de séparation : Partie de caténaire comportant à chaque extrémité, un sectionnement

destiné à éviter le pontage, par les pantographes d’une circulation, des caténaires situées de
part et d’autre de cette section.
16
Introduction Générale
Suite à l’ouverture du marché, le Réseau Ferré National (RFN) français doit faire face à la
concurrence du transport ferroviaire européen. Afin de garder sa position de leader du marché
ferroviaire français, la Société Nationale des Chemins de Fer français (SNCF) cherche à
mettre en place des solutions innovantes permettant d’améliorer la productivité. Celle-ci ne
doit pas se faire au détriment de la sécurité des installations et des personnes dont l’ingénierie
de l’infrastructure SNCF est garante. Au sein de cette branche, le département PROJETS
SYSTEME INGENIERIE de Traction Electrique (PSIGT-TE) a pour mission de spécifier les
équipements de téléconduite, automatismes, protections Basse Tension (BT), du marché des
Equipements d’Alimentation des Lignes Electrifiées (EALE). Afin d’améliorer la productivité
et la performance, PSIGT-TE a décidé de mettre en place des solutions innovantes permettant
d’harmoniser le cadre de travail des études de conception du système de téléconduite,
automatismes, protections BT, réalisées sur les EALE au titre d’une maîtrise d’œuvre de
spécialité.
Les EALE sont les points d’alimentation en énergie électrique des lignes électrifiées, appelées
caténaires. Le rôle des EALE est de transformer, de distribuer et de redresser dans le cas
d’une alimentation continue, la tension du réseau Haute Tension en tension compatible avec
les engins de traction (1500 V continu ou 25 kV alternatif). Ces systèmes électriques sous
(très) Haute Tension sont soumis à des normes strictes de sécurité ferroviaire (EN 50126,
2012) (IEC 60870-4, 2013).
Les EALE sont des systèmes automatisés distribués dont le contrôle et la commande peuvent
se faire soit localement, soit à distance dans un poste de commande centralisé appelé Central
Sous-Stations (CSS). Les opérateurs d’exploitation peuvent manœuvrer les appareils HT
depuis cette salle de contrôle. Ils ont la responsabilité d’assurer l’alimentation des EALE en
régime nominal et dégradé (maintien de la tension caténaire), d’assurer la sécurité en cas de
travaux sur les EALE sous réglementation nationale (UTE C 18510, 1988) ou particulière
(S11, consignation C, 2012) et la coupure d’urgence en cas de danger électrique pour les
personnes et les biens.
L’objectif de ce travail de recherche, réalisé dans le cadre d’une Convention Industrielle de
Formation à la Recherche en Entreprise (CIFRE) signée entre la Direction de l’Ingénierie
SNCF et le Centre de Recherche en Sciences et Technologies de l'Information et de la
Communication (CReSTIC) de l’Université de Reims Champagne-Ardenne (URCA), est de
17
contribuer à l’amélioration des études de conception du contrôle/commande des projets

d’électrification menés par la section Conception et Expertise des Systèmes (CES2) de la
Direction de l’Ingénierie de la SNCF. L’amélioration de ces études doit répondre à trois
objectifs :
 Humains : Les études sont actuellement réalisées par les chargés d’études qui suivent
un planning de projet très serré. Il s’agit d’activités complexes mais aussi parfois
répétitives qui entraînent des variations de charge de travail importantes et stressantes
compte tenu des enjeux économiques et techniques. La solution proposée dans le cadre
de cette thèse vise à améliorer les conditions de travail des chargés d’études. Les
méthodes et outils développés doivent donc être nécessairement conçus et adaptés à
leurs besoins pour être acceptés. Pour cela, le chargé d’études doit pouvoir retrouver
son langage métier au sein de la solution proposée. L’idée suivie dans cette thèse a été
de développer un environnement unique dans lequel le chargé d’études puisse saisir
une seule fois toutes les données d’entrée de son projet en vue d’éviter les tâches
répétitives et les erreurs de recopie.
 Economiques : La diminution des coûts est un objectif important. Celui-ci peut être
obtenu par une diminution de la durée des projets d’études.
 Techniques : Un environnement de saisie unique des données d’un projet devrait
permettre de générer automatiquement, entre autres, le code des applications de
contrôle/commande distribuées des EALE. Des techniques existent permettant de
définir des modèles objets de l’architecture du système et de son contrôle/commande
pour générer les programmes des Automates Programmables Industriels (API). Pour la
SNCF, Il est important que les codes soient d’une part compatibles avec les API
actuels et futurs utilisés, et d’autre part restent lisibles et de qualité pour les chargés
d’études, en vue de répondre aux besoins de maintenabilité des programmes et
d’évolutivité des principes et des matériels mis en œuvre. La sécurité des biens et
surtout des personnes est la priorité pour la Direction de l’Ingénierie de la SNCF dans
tous les projets. Il est donc fondamental de garantir la sûreté du fonctionnement des
programmes de contrôle/commande des EALE. Actuellement, celle-ci est réalisée au
moyen de tests en usine et sur site à partir d’un cahier de recettes. Cette solution n’est
pas complétement satisfaisante car elle ne garantit pas formellement la validité des
programmes API.
18
Nous avons dans le cadre de ce travail de recherche proposé une méthodologie originale
répondant aux trois objectifs : humain, économique et technique. Le manuscrit de thèse est
décomposé en cinq chapitres.
Le premier chapitre présente le domaine « métier » (i.e. les EALE et leurs systèmes de
contrôle/commande) qui a fait l’objet de ce travail de recherche. Nous commencerons par
présenter le réseau ferroviaire français et les types d’alimentation électrique présents. Ensuite,
l’architecture d’un secteur caténaire et d’une sous-station alimentée en 25kV ainsi que les
programmes Automates Programmables Industriels (API) permettant la commande de ce
système complexe distribué sont décrits. Pour finir, le métier des chargés d’études
d’automatisation des EALE est présenté ainsi que les difficultés qu’ils rencontrent dans la
réalisation du workflow d’un projet.
Le deuxième chapitre présente un état de l’art des voies possibles d’amélioration du métier
des EALE. Etant donné le rôle central du chargé d’études, ce chapitre commence par
présenter une approche « Système Homme-Machine » (SHM) du métier des EALE. Cette
analyse permet entre autres de mettre en évidence que la génération automatique de livrables
(codes, schémas, Interfaces Homme-Machine (IHM), …) doit contribuer a priori à la
régulation de la charge de travail mentale des chargés d’études. Par conséquent, un premier
axe d’amélioration du métier est étudié au travers de la génération automatique de livrables
(codes, schémas, IHM, …). Celle-ci repose nécessairement sur une standardisation et une
modélisation du « métier ». L’approche MDD (Model Driven Development) du génie logiciel,
au travers des architectures MDA (Model Driven Architecture) et DSM (Domain Specific
Modeling), apporte des éléments de solution. Leur pertinence vis-à-vis du domaine applicatif
est étudiée et discutée. Il en ressort que l’approche DSM, au travers des solutions logicielles
reposant sur l’utilisation de « templates métiers », semble la plus adaptée. Toutefois, il est
fondamental de générer des livrables de qualité et du code API sûr de fonctionnement. En
complément des méthodes de validation et de vérification utilisées par la communauté des
automaticiens, trois approches de synthèse de la commande (la Supervisory Control Theory
(SCT), la synthèse algébrique et la commande par contraintes logiques) permettant a priori de
répondre à ces objectifs de sûreté sont présentées et discutées. La commande par contraintes
logiques présente l’avantage majeur de séparer la sécurité (qui est vérifiée formellement hors
ligne) et le fonctionnel, et de pouvoir être utilisée avec des programmes API existants, ne
remettant pas ainsi en cause la méthodologie de développement des chargés d’études.
19
Le troisième chapitre propose une méthodologie originale pour les études d’automatisation
devant contribuer à une amélioration du métier des chargés d’études intégrant les deux voies
de progrès : génération automatique de livrables et code API sûr de fonctionnement.
L’approche DSM au travers de l’outil logiciel ODIL de la société PROSYST, a été retenue.
Celui-ci permet, à partir d’une modélisation du « métier » des EALE, de générer
automatiquement des « templates » basés sur le code API existant. En vue de s’assurer de la
qualité de celui-ci, l’outil PLC Checker, proposé par la société Itris Automation Square, est
utilisé dans un premier temps afin d’analyser les codes API existants et de vérifier le respect
de règles de programmation établies par la SNCF. Le code est ensuite formalisé par une
grammaire du langage de programmation. Le deuxième axe d’amélioration métier proposé
dans notre démarche consiste à appliquer un algorithme original (ou Design Pattern) pour
obtenir une commande sûre de fonctionnement basée sur des contraintes logiques. Pour cela,
un ensemble de contraintes de sécurité doit être défini pour chaque sortie de l’API. Cette
approche permet de séparer clairement les aspects fonctionnels et sécuritaires de la
commande. Il est alors possible d’appliquer la proposition de Design Pattern de deux façons
différentes : i) filtre de sécurité + commande par contraintes fonctionnelles, ou ii) filtre de
sécurité + commande existante.
Le quatrième chapitre présente l’application de la méthodologie aux études d’automatisation

des EALE. Au travers de ce chapitre le premier axe d’amélioration de la méthodologie qui
consiste en la génération des livrables projets est appliqué. Toutes les étapes décrites dans le
chapitre 3 sont détaillées. Les vues, les modèles, les prototypes de génération du code sont
présentés. Nous insistons à la fin de ce chapitre sur le cycle Agile mis en place pour le
développement de l’outil Odil GREMLINS (GénéRateur Evolutif du Modèle et des LIvrables
des Nouvelles Sous-stations) et sur les conséquences que la solution développée a sur le
workflow et le métier des chargés d’études. Comme cela est préconisé par l’approche SHM,
une étape d’évaluation auprès des chargés d’études a été réalisée. A la fin de ce chapitre, les
questionnaires utilisateurs, utilisés pour analyser l’utilité et l’utilisabilité de la démarche et des
outils proposés, sont présentés. Les résultats obtenus sont satisfaisants et mettent en évidence
l’acceptabilité de la méthodologie et des outils par les chargés d’études.
Le cinquième et dernier chapitre présente l’application du deuxième axe de la méthodologie

sur un sous-système des EALE : le poste de mise en parallèle et ses fonctions de débouclage
et de réenclenchement automatique des parallèles. Les programmes actuellement mis en
20
œuvre sont complexes et peu lisibles. Nous proposons une nouvelle commande séquentielle
spécifiée en GRAFCET (IEC 60848, 2002). Les deux possibilités offertes par l’algorithme de
commande par contrainte sont ensuite explorées : i) la commande par contraintes intégrant les
contraintes fonctionnelles et ii) l’utilisation du Design Pattern comme filtre de la commande
actuellement implémentée par la SNCF. Pour comparer les performances des différentes
commandes proposées, le système (Partie Opérative et Partie Commande) a été modélisé au
moyen d’automates communicants et le model checker UPPAAL utilisé afin de vérifier si les
propriétés tirées du cahier de recettes du système sont formellement vérifiées par les
commandes implémentées. Les résultats obtenus mettent en évidence que le filtre de
commande permet de fiabiliser la commande existante.
Un bilan reprenant les objectifs, les propositions et les résultats obtenus dans le cadre de cette
thèse est présenté dans la conclusion générale. La démarche proposée et l’outil Odil
GREMLINS développé sont opérationnels et permettent :
1) une amélioration des conditions de travail des chargés d’études sans modifier leur métier
car les principes de développement des programmes API sont conservés.
2) un gain économique important car les temps consacrés aux études sont réduits.
3) une fiabilisation de la commande au travers de la proposition d’un Design Pattern simple à
implémenter et reposant sur un filtre à base de contraintes logiques (vérifiées formellement)
de sécurité et robuste aux erreurs de commande.
Ce travail ouvre également de nombreuses perspectives théoriques et applicatives de
recherche qui seront décrites en conclusion générale de ce document.
21
22
Chapitre 1 : Le métier des EALE
1.1 Introduction
Ce premier chapitre a pour but de décrire le domaine spécifique sur lequel nous avons
travaillé. Pour commencer, le domaine de la Traction Electrique, l’organisation du réseau
électrique et plus particulièrement l’alimentation sur laquelle nous avons travaillé par la suite,
l’alimentation en 25kV, sont décrites. Les principes et les avantages de ce type d’alimentation
sont détaillés. Dans la suite de ce chapitre, l’architecture des Equipements d’Alimentation des
Lignes Electrifiées (EALE) est présentée. Les EALE sont les installations en charge de
l’alimentation électrique des lignes de chemin de fer électrifiées. Ces installations sont
automatisées afin d’assurer leur contrôle et leur commande à distance mais également afin
d’automatiser certaines séquences de fonctionnement afin de répondre aux contraintes de
haute disponibilité du système. Les lignes sont électrifiées en permanence. La perte de
l’alimentation d’une voie lors de la circulation d’un train signifie un retard immédiat et un
risque de retard du trafic ferroviaire, c’est évidemment un événement redouté par la SNCF.
C’est pourquoi le système de contrôle/commande associé à ces installations, ainsi que les
problématiques techniques liées à ce domaine notamment en termes de sûreté du
fonctionnement, sont décrits. La fin de ce chapitre traite du métier sur lequel le projet de
recherche porte. Le périmètre de notre travail consiste à proposer des solutions pour améliorer
le métier des chargés d’études qui produisent et réalisent les études d’automatisation des
EALE. Ces problématiques techniques, économiques et humaines liées à la production des
études d’électrification des installations sont au cœur des préoccupations de ce projet de
recherche. L’objectif est d’améliorer les conditions de travail des chargés d’études tout en
diminuant le temps d’étude nécessaire et en garantissant la sûreté du fonctionnement du
système.
1.2 Organisation du réseau électrique
1.2.1 Les systèmes de traction ferroviaire
Au début du XXème siècle, la préoccupation principale des chemins de fer était de résoudre le
problème de la traction électrique afin de faire fonctionner les locomotives. Il existe en France
23
deux modes de traction pour les convois ferroviaires : électrique et thermique. Les
locomotives thermiques, « diesel », sont en complément des machines électriques.
Pour assurer la traction électrique, il est nécessaire de disposer d’un réseau de lignes
électrifiées. Le réseau est électrifié suivant deux systèmes différents :
 L’un à courant continu, avec une tension de 1.5 KV,
 L’autre à courant alternatif d’une tension de 25KV-50hz.
En 2012, les lignes exploitées sont estimées à une longueur de 30 000 Km, dont 14 176 Km
électrifiées et alimentés par 520 sous-stations. Parmi ces lignes électrifiées sont compris 2 034
Km de Lignes à Grande Vitesse (LGV).
Quel que soit le type d’électrification (1.5 KV ou 25KV-50Hz), un système d’alimentation
électrique est composé d’installations fixes comprenant :
 les sous-stations réparties le long de la ligne ferroviaire avec des distances allant
généralement de 8 à 20 Km pour le 1.5 KV et de 40 à 90 Km pour le 25 KV,
 les lignes de contact ou caténaires,
 les postes assurant l’alimentation ou la mise en parallèle des caténaires,
 les rails de roulement assurant le retour du courant vers la sous-station.
1.2.2 Rôle des Sous-stations
Les sous-stations sont les points d’alimentation en énergie électrique des lignes électrifiées.
Elles sont la propriété de RFF (Réseau Ferré de France). Leur rôle est de transformer (voir
transformer et redresser) la tension du réseau Haute Tension en tension compatible avec les
engins de traction (1,5 KV continu/ 25 KV alternatif). Les sous-stations alimentent des
tronçons de lignes, appelés secteurs.
La puissance délivrée par les transformateurs des sous-stations dépend du trafic de la ligne
qu’ils vont alimenter. En effet, plusieurs trains peuvent emprunter un même secteur, c’est
pourquoi la puissance à fournir est calculée préalablement à la réalisation de la sous-station.
24
Figure 1 : Schéma d’alimentation d’une ligne par les sous-stations.

Les lignes de contact ou caténaires (câbles de contact suspendu au-dessus de la ligne)
permettent à l’engin moteur de capter l’énergie électrique via le pantographe pour la
transformer en énergie mécanique afin d’assurer la traction du convoi (Figure 1).
Les sous-stations sont raccordées au réseau haute tension de distribution, propriété de RTE
(Réseau de Transport d’Electricité). Le courant est transformé et redressé (en 1500V) puis
distribué à la caténaire.
Une sous-station est composée de 4 parties (Figure 2) :
 La partie alimentation ou poste haute tension : raccordée au réseau RTE, constituée de
jeux de barres, de sectionneurs et de disjoncteurs.
 La partie conversion, constituée d’un transformateur et en 1500V d’un redresseur.
 La partie distribution, pour laquelle les disjoncteurs de départ alimentent et protègent
les caténaires.
 La partie énergie auxiliaire. Elle fournit l’énergie à l’appareillage de l’installation :
Courant BT 220V et 48 ou 120 V continu obtenus par les transformateurs de services
auxiliaires.
25
Figure 2 : Représentation simple d’une sous-station 1,5 KV et 25 KV

Elle peut être alimentée en 1500 V continu ou 25 KV alternatif par la sous-station. La section
suivante présente les principes et compare les types d’alimentation électrique.
1.3 L’alimentation électrique
Les types d’EALE qui permettent l’alimentation de la caténaire sont multiples. Chaque
installation a un rôle et des fonctions à assurer. Nous allons décrire le rôle et l’intérêt de
chaque installation.
L’architecture des sous-stations et du réseau a été pensée pour que n’importe quel secteur
puisse être alimenté en secours en situation dégradée (maintenance ou défaut sur
l’infrastructure). Ce découpage permet de séparer électriquement les secteurs entre eux et
ainsi d’assurer la maintenance d’un secteur sans bloquer l’alimentation de l’ensemble de la
ligne. Si l’alimentation d’un secteur est défectueuse un appareil de pontage entre deux
secteurs peut en faire la liaison (électriquement) pour assurer, malgré tout, son alimentation et
ainsi permettre aux trains de circuler.
La disponibilité des secteurs est l’objectif principal de l’alimentation électrique. Cette
disponibilité dépend de celle des installations amont, et de la capacité de reconfiguration du
26
système, réalisable par les pontages entre secteurs, leur mise en parallèle ou l’alimentation de
deux départs par le même disjoncteur comme il sera expliqué par la suite.
Pour répondre à l’augmentation des puissances appelées par les engins de traction, la solution
du transport de l’énergie de la caténaire vers les engins de traction sous une tension plus
importante fut retenue. A partir de 1950, les électrifications nouvelles sont réalisées en 25 KV
alternatif. Le courant étant redressé dans l’engin de traction pour alimenter les moteurs séries
à courant continu.
De ce fait, la distance séparant deux sous-stations s’est accrue considérablement, passant de
15 Km en 1500V continue à 65 Km en moyenne pour l’alimentation 25KV alternative.
L’emplacement d’une installation est surtout lié aux possibilités de piquage sur le réseau de
Réseau de Transport d’Electricité (RTE).
Le réseau SNCF comporte trois systèmes principaux d’alimentation des caténaires :
 le courant continu 1500 V
 le courant alternatif monophasé 25 KV 50 Hz
 le courant alternatif 2 x 25 KV 50 Hz
1.3.1 L’alimentation en courant continu 1500 V
C’est l’alimentation la plus ancienne qui nécessite l’infrastructure la plus importante, aussi
bien au niveau des sous-stations qu’en ligne.
Le courant 1500 V continu est obtenu par transformation et redressement d’une tension
triphasée. L’alimentation HT des sous-stations 1500 V, se fait en 15 KV, 20 KV, 30 KV, 63
KV ou 90 KV.
Le long de la voie, la répartition des sous-stations varie de 4 à 20 Km maximum. Entre
chaque sous-station, des postes de sectionnement et des postes de mise en parallèle sont
installés (Figure 3) :
 Les postes de sectionnement (Poste PMPS) sont utiles pour limiter les zones privées
de tension lors des consignations établies pour l’entretien de la caténaire, ils assurent
également la mise en parallèle des caténaires.
 Les postes de mise en parallèle (Poste PMP) sont installés pour diminuer la chute de
tension de la caténaire entre la sous-station et l’engin moteur ; les caténaires parallèles
jouent le rôle de feeder d’alimentation.
27
Figure 3 : Schéma d’alimentation des caténaires en 1500V
1.3.2 L’alimentation en courant alternatif monophasé 25 KV 50 Hz
L’électrification monophasée 25 KV 50 Hz est apparue dans les années 1950. Du fait de son
infrastructure plus légère donc moins onéreuse, ce système d’alimentation est installé au
détriment de l’alimentation 1500 V.
L’alimentation HT des sous-stations se fait en 90 KV. La tension 25 KV alternatif est obtenue
par des transformateurs monophasés reliés à 2 phases d’un réseau haute tension.
Le long de la voie, la répartition des sous-stations varie de 40 à 80 Km maximum. Entre
chaque sous-station des postes de sectionnement et des postes de mise en parallèle (Postes SP
et SSP) sont installés pour assurer le sectionnement et la mise en parallèle des caténaires
(Figure 4).
28
Figure 4 : Schéma d’alimentation des caténaires en 25KV
1.3.3 L’alimentation en courant alternatif 2x25KV 50 Hz
Le groupe traction est composé d’un transformateur 225KV / 2x25 KV à point milieu de 60
MVA. Le point milieu est relié au rail et à la terre. Une sortie du transformateur alimente la
caténaire, l’autre le feeder. La tension entre la caténaire et le rail est de 25 KV, de 50 KV
entre caténaire et feeder. Les deux tensions, caténaire et feeder, sont en opposition de phases.
Le feeder alimente la caténaire à travers des auto–transformateurs. Des injections sont faites à
chaque poste SP et PMP (Figure 5), ce qui renforce la caténaire et maintien une tension
constante sur tout le secteur. Grâce à ce type d’alimentation les secteurs sont allongés tout en
disposant d’une puissance maximale sur la ligne.
29
Figure 5 : Schéma d’alimentation des lignes en 2x25KV

Grâce à l’alimentation en 2x25KV, les sous-stations sont moins nombreuses, de 70 à 80
kilomètres entre les installations. Leur implantation est plus flexible, de façon à réduire la
longueur des lignes haute tension de RTE qui les alimentent, ce qui entraine une diminution
de coût. Grâce à ce type d’alimentation les boucles d’intensité sont démultipliées, cela
favorise le transport d’énergie en diminuant les pertes en ligne.
Le travail présenté dans ce manuscrit concerne essentiellement les installations assurant

l’alimentation 25 KV et 2x25 KV. Les prochaines sections détaillent davantage ces
installations.
1.3.4 Architecture d’un secteur caténaire 25KV ou 2x25KV
En général, pour éviter les transits d’énergie la mise en parallèle de deux sous-stations est
interdite. En effet, chaque sous-station est souvent raccordée sur une phase HT différente. Sur
les secteurs 25KV et 2x25KV, les postes permettent d’optimiser l’alimentation électrique du
secteur. La différence en 2x25KV est due à l’intégration d’autotransformateurs (AT) dans
certains postes qui permettent de réinjecter de la puissance sur la ligne. Le Tableau 1 décrit les
EALE qui composent une ligne. Les postes sont décrits selon une fonction élémentaire
associée. Cependant, dans la réalité, un poste réalise plusieurs fonctions élémentaires, comme
30
par exemple les postes PMP 2x25KV avec AT (Figure 5) qui réalisent les fonctions de mise
en parallèle et d’injection.
Tableau 1 : Tableau descriptif des EALE et des fonctions élémentaires associées

Installation Fonction
Sous-station (S/ST) Installation assurant la conversion de l'énergie électrique
délivrée par les réseaux de transport d'électricité pour
alimenter les ITE 25KV.
Postes de traction électrique (PTE)

Poste de mise en parallèle (P) Poste assurant la mise en parallèle entre secteurs ou sous-
secteurs.
Poste de sous-sectionnement Poste assurant la continuité ou la séparation électrique

(SS) entre deux sous-secteurs d'un même secteur.
Poste de sectionnement (S) Poste (au droit d’une zone neutre) assurant la séparation
et occasionnellement le pontage entre secteurs alimentés
par des sous-stations différentes.
Poste de Ligne (L) Poste assurant la continuité ou la séparation entre sections

élémentaires d’un même secteur ou sous-secteur.
Poste d'alimentation (A) Poste assurant l'alimentation de caténaires secondaires.
Poste d’injection (J) Poste comprenant des autotransformateurs pour injecter la

(en 2x25KV) tension en opposition de phase du feeder sur la caténaire.
1.3.5 Architecture d’une sous-station 25KV/2x25KV

Les sous-stations sont construites sur le même profil et constituées de trois parties principales
(Figure 6) :
 L’arrivée Haute Tension RTE
 Des Groupes Traction 25 KV ou 2x25KV
 Des Départs Traction 25 KV ou 2x25KV
Le schéma unifilaire de la sous-station de « Commune » (Figure 6) qui appartient à la ligne à

grande vitesse Paris-Lyon alimentée en 2x25 KV alternatif, permet de voir l’agencement des
éléments décrits précédemment.
31
DT
GT
HT
Figure 6 : Schéma unifilaire de la sous-station de Commune (2x25KV)

Sur la Figure 6, la partie HT provenant directement du réseau RTE est encadrée en bas, la
partie transformation d’énergie réalisée par deux groupes tractions est encadrée au milieu.
Enfin dans le cadre du haut, les quatre départs qui alimentent les caténaires voie 1 et voie 2 en
direction de Paris ainsi qu’en direction de Lyon.
La commande de ces appareils se fait à partir d’un ensemble « automatisme et
télécommande » décrit dans la section suivante.
1.4 Système de contrôle/commande des EALE
Le système de contrôle/commande des EALE est un système distribué et hiérarchisé (Figure

7). Les sous-stations sont contrôlées localement par un réseau d’automates distribués auxquels
sont assignés des tâches spécifiques. Ils peuvent communiquer entre eux par un réseau local
industriel. Ce réseau permet également d’échanger des informations avec la Commande
Locale Ecran (CLE - Figure 8) et le Central Sous-Station (CSS). Le CSS est chargé de
superviser plusieurs sous-stations en fonction de la situation géographique ou des lignes
électrifiées qu’il a en charge.
32
Figure 7 : Schéma de l’architecture hiérarchisée de contrôle/commande.
Figure 8 : Synoptique de la CLE de la sous-station de Velars
33
1.4.1 Architecture SCADA
Un CSS pilote plusieurs EALE situés dans une zone d'action qui varie de 200 à 400 Km. Ils
sont au nombre de 17 en France. Un CSS fonctionne 24 heures sur 24, les opérateurs,
nommés régulateurs sous-stations (RSS), sont chargés de surveiller l’état des installations et
de donner les consignations aux agents chargés de la maintenance et des travaux.
Le central est composé :
 D’un Tableau de Contrôle Optique (TCO) qui permet la visualisation globale de la
zone de contrôle avec l'état des appareils (disjoncteurs, sectionneurs…). Les TCO
« classiques » ont des boutons de commande intégrés (Tourner Pousser Lumineux -
TPL) qui permettent la manipulation des équipements. Dans les CSS plus récents, le
TCO est un mur d’image et les commandes se font depuis un poste informatique.
 Des postes de régulation à partir desquels les régulateurs pilotent les installations à
distance.
 Un local technique dans lequel des armoires permettent la communication avec les
postes distants et les sous-stations (Télécommande).
En fond de la Figure 9, se trouve le mur d’image (anciennement TCO). Tandis qu’au premier
plan, se trouvent les postes de régulation.
Figure 9 : Photo du Central Sous-Station de Paris Rive Gauche
34
1.4.2 Architecture de Conduite Local et d’Automatismes
La principale caractéristique du système de contrôle-commande-protection est la répartition

de l’intelligence suivant la tâche à effectuer. Le système est ainsi constitué d’un certain
nombre d’automates, chacun ayant un rôle bien défini.
Le système est destiné, soit à être utilisé dans un mode dit Poste Asservi (PA), disposant
seulement de fonctions télécommandes, soit à être utilisé dans un mode dit « SCLA »
(Système de Conduite Locale et Automatismes), disposant en plus de la fonction
télécommande, de fonctions d’automatismes et de conduite locale.
Bien que les deux systèmes (PA-SCLA) reposent sur la même base matérielle, les
fonctionnalités divergent. Ils sont composés notamment d’abonnés automate (AA),
équipements connectés au Réseau Local Industriel (RLI) et assurant des fonctions spécifiques.
1.4.2.1 Le système PA
Ce système est conçu pour répondre aux fonctions de téléconduite uniquement. Il reçoit des
ordres de télécommande, Commande d’Ouverture (CO) et Commande de Fermeture (CF) et
transmet des signalisations de type TSD (TéléSignalisations Doubles) du type Signalisation
d’Ouverture (SO) ou Signalisation de Fermeture (SF) et de types TSS (Télésignalisation
simple de type absente ou présente).
Le Tableau 2 décrit de manière non exhaustive les fonctions principales attendues par la mise
en œuvre des équipements.
35
Tableau 2 : Tableau des éléments fonctionnels PA

Abonné Eléments Fonctionnels spécifiques
Base PA
 Configuration, paramétrage, choix du mode de fonctionnement par
téléchargement depuis le PC via un coupleur V24 ou USB
Fonction Abonné  Communication avec les E/S déportées
 Interface aide à la maintenance de l’abonné et du support
PA  Signalisation de fonctionnement par led en face avant (mode RUN, Arbitre
(Selon architecture de bus, défaut Configuration, Défaut Chien de Garde, …)
du système PA)  Gestion du protocole de communication avec le CSS (HNZ)
 Gestion de la datation (applicatif SNCF)
 Configuration des paramètres de téléconduite (Vitesse de dialogue, Adresse
HNZ, Nombre TC et TSS de l’application), par terminal de dialogue
 Interface protocole de communication / réseau local
 Reconnaissance de la configuration de l’application
 Edition des trames d’échanges PC/PA complètes ou limitées, Edition au fil
de l’eau des événements en clair pour une pile de 200 événements minimum
 Acquisition des Entrées TOR : TSD et TSS
 Acquisition des entrées TéléMesures (TM)
 Terminal de dialogue pour paramétrage variables de conduite (TSS
inverse/directe, TC Non utilisée, Tempo de Sortie ouverture et fermeture
paramétrable de 1 à 30 s individuellement, cycle de remonté des TM)
 Gestion d’un pupitre de commande locale individuelle
Extension éventuelle
 Acquisition des Entrées TOR : TSD et TSS
 Acquisition des entrées TM
 Pupitre de commande locale individuelle
1.4.2.2 Le système SCLA
La mise en œuvre du système SCLA est décrite dans le document technique interne
(VZU13_68, 2001). Le système SCLA est, en plus de la fonction téléconduite, muni de la
fonction automatisme. Les automates reliés aux différents appareils et/ou capteurs échangent
des informations (ordres, états, mesures …) par l’intermédiaire d’un réseau FIP (Factory
Information Protocol). On distingue 6 types d’abonnés (A1, A2, …, A6) (Figure 11). Il
communique avec le CSS grâce au Remote Terminal Unit (RTU) par un protocole
propriétaire (HNZ).
Le RTU sert d’interface de zone entre la liaison HNZ (protocole de communication
propriétaire de la SNCF) et le réseau FIP de communication inter-automates (Figure 10). Le
RTU est considéré comme esclave, il répond aux interrogations du RTU maître situé au CSS.
HNZ FIP
CSS RTU PA
Figure 10 : Représentation de la chaîne de communication
36
Figure 11 : Schéma de l’architecture distribuée du contrôle/commande au sein des sous-

stations.
37
1.4.2.3 Les différents types d’abonnés
Le Tableau 3 présente l’ensemble des abonnés présents sur le réseau FIP du SCLA ainsi que
leurs éléments fonctionnels spécifiques. Chaque abonné a un rôle bien déterminé selon son
type comme la Figure 11 le présente.
Tableau 3 : Eléments fonctionnels des abonnés du SCLA

Abonné Eléments Fonctionnels spécifiques
 Configuration, paramétrage, choix du mode de fonctionnement par
téléchargement depuis le PC via un coupleur V24 ou USB
Abonnés A1 à A4 et A6
 Interface aide à la maintenance de l’abonné et du support
Fonctions communes  Signalisation de fonctionnement par led en face avant (mode RUN, Arbitre
de bus, défaut Config, Défaut CdG, …)
Abonnés A1 à A4  Communication avec le RLI et Ethernet
Fonctions communes  Arbitre de Bus potentiel
 Gestion du protocole de communication avec le CSS (HNZ)
 Applicatif SNCF (gestion de la datation par le protocole de communication)
A1  Configuration des paramètres de téléconduite (Vitesse de dialogue, Adresse
RTU PA, Nombre TC et TSS de l’application), par terminal de dialogue
 Interface protocole de communication avec le CSS / RLI
 Reconnaissance de la configuration de l’application
 Lecture des variables sur le RLI
A2  Affichage des informations sur le CLE
Contrôle/commande  Archivage des données de télégestion
locale  Conduite de l’installation en cas de contrôle local général
 Intégration des séquences d’automatisme spécifiques et initialisation de
l’abonné
 Commande des sorties selon le résultat des séquences d’automatismes
Abonnés A3 et A4  Terminal de dialogue pour paramétrage de variables de conduite (TSS
Fonctions communes inverse/directe, TC Non utilisée, Tempo de Sortie ouverture et fermeture
paramétrable de 1 à 30 s individuellement, Tempo de séquences, En/Hors
service de fonctions, …)
 Acquisition des Entrées TOR (TSD, TSS et SSL) et des valeurs analogiques
A3 issues des capteurs
 Exécution des séquences d’automatismes en fonction des variables externes
Automate avec liaison
et internes,
protection  Gestions de liaisons pour communication (Modbus maître, IP) avec des
(Départs 25KV, Départs protections numériques, des équipements d’interface de convertisseur de
1500V, Groupe Traction,....) puissance spécifiques (compensateur de déséquilibre, survolteur, CVS
1,5KV=, 15KV 16 ,7Hz, …)
A4  Acquisition des Entrées TOR : TSD, TSS et SSL
Automate simple  Exécution des séquences de contrôle et commande pour 8 Organes
(Partie commune)
A5
Réserve pour un abonné déporté
Automate déporté
A6  Configuration séquences (applicatif SNCF)
 Intégration des séquences d’automatisme
Automate Programmable
 Exécution des séquences
seul  Gestions de liaisons pour communication (Modbus maître, IP) avec d’autres
(non connecté au RLI) équipements
38
Les abonnés sont des automates programmables industriels (API) de type ACS21, la section
suivante décrit la couche matérielle et logicielle de ces abonnés en s’intéressant
principalement à l’aspect de sûreté du fonctionnement.
1.5 Sûreté du fonctionnement du système de contrôle/commande
Jusqu’en 2014, le type d’automates utilisé par la SNCF était l’Automate de Conduite
Sécurisée ACS21 de Leroy Automation, intégré par la société Fournié Grospaud (FG)
Energie. Un appel d’offres a été lancé en 2013 afin de renouveler le matériel utilisé.
Néanmoins, les principes appliqués au matériel jusqu’alors resteront valables. En effet, le
matériel de contrôle/commande respecte des normes spécifiques au domaine des EALE,
notamment de sûreté du fonctionnement (IEC 60870-4, 2013).
1.5.1 Définition de la sûreté du fonctionnement dans le domaine des EALE
La sûreté de fonctionnement fait appel à 4 composantes : Fiabilité, Maintenabilité,

Disponibilité et Sécurité (FMDS) définies ci-après selon la norme (IEC 60870-4, 2013).
1.5.1.1 Fiabilité
L’objectif de la fiabilité est de caractériser l’aptitude d'un système à accomplir une fonction
requise, dans des conditions données, pendant un intervalle de temps déterminé. Une mesure
pratique de la fiabilité est le MTBF (Mean Time Between Failure) qui est la durée moyenne
entre deux défaillances consécutives d’une entité réparée. Pour en obtenir une valeur, on peut
recourir au taux de défaillance . Ce taux est le rapport entre le nombre de pannes pendant le
cycle de vie du composant et le temps de fonctionnement cumulé correspondant. Si  est
supposé constant dans le temps (ce qui peut en général être considéré comme vrai sur la durée
de vie de la plupart des composants), la répartition des défaillances en fonction du temps est
exponentielle. D’après la norme IEC 60870-4, les équipements des EALE doivent répondre à
la Classe de fiabilité R3 soit un MTBF > 10 000 h. Cette valeur se réfère à la fiabilité d’un
équipement en mode simple pour une configuration maximale à une température externe de
55°C.
39
1.5.1.2 Maintenabilité
Le MTTR (Mean Time To Repair) est le temps de dépannage total mesuré pour un groupe
d’unités divisé par le nombre total de défaillances. Ce critère quantifie la maintenabilité d’un
système. Il est l’addition des composantes suivantes :
 le temps administratif : période de temps entre la détection d’une panne et la
notification au service de maintenance,
 le temps de transport : période de temps entre la notification au service de
maintenance et l’arrivée sur place du personnel de maintenance muni du matériel
nécessaire,
 le temps moyen de réparation (MRT (Mean Repairing Time)).
Les équipements des EALE doivent répondre aux exigences de la classe de maintenabilité M3
pour laquelle le temps de réparation est ramené à 15 minutes.
1.5.1.3 Disponibilité
La disponibilité caractérise l’aptitude d'un système à être en état d'accomplir une fonction
requise, dans des conditions données, à un instant donné ou pendant un intervalle de temps
déterminé, en supposant que la fourniture des moyens extérieurs soit assurée. La disponibilité
intrinsèque est exprimée numériquement à l’aide de la formule :
MTBF
A  100
MTBF  MTTR
L’ensemble de l’équipement de télécommande doit répondre à la classe A3 (Disponibilité
supérieure à 99,95%).
1.5.1.4 Sécurité des abonnés
Celle-ci est intrinsèquement liée à la conception de l'équipement, elle devra répondre à la

norme (NF C 63-850, 1988), relative aux automates programmables industriels.
En cas de défaut interne, l'équipement doit répondre aux classes d'emplois associées :
 au positionnement des sorties : aucun ordre intempestif ne devra être émis par le
système (catégorie d),
 à l'aptitude des autocontrôles à signaler des défauts internes : l’organe en défaut est
bloqué jusqu'à la prochaine réinitialisation du système (catégorie d).
40
Le comportement de l’équipement doit correspondre au type 3 prévu dans la norme NFC 63-
850, c'est-à-dire « que le défaut doit être détecté, signalé et les sorties doivent prendre un état
0 sur défaut interne ».
1.5.1.5 Événement critique redouté

L’événement critique redouté défini pour l’analyse de sûreté de fonctionnement du système
est un ordre intempestif. Si une commande intempestive était envoyée vers un appareil HT,
entraînant la fermeture de celui-ci, la sécurité des personnes et des installations ne serait alors
pas assurée. Aucun ordre intempestif ne doit être émis par le système qu’il soit en mode de
fonctionnement nominal ou dégradé.
L’organe en défaut est bloqué jusqu'à la prochaine réinitialisation du système (après
diagnostique, dépannage, contrôle, remise en service).
Le fournisseur doit démontrer, par une étude de sécurité basée sur l’analyse des arbres de
défaillance relatifs à cet événement critique identifié, que la probabilité de défaillance
conduisant à l’événement critique est inférieure à 10-5, ce qui correspond à un niveau
d’intégrité de sécurité SIL 2.
La notion de SIL (Security Integrity Level) découle directement de la norme (IEC 61508,
2010). Le SIL peut se définir comme une mesure de la sûreté de fonctionnement qui permet
de déterminer les recommandations concernant l’intégrité des fonctions de sécurité à assigner
aux systèmes E/E/PE (électrique / électronique / électronique programmable) concernant la
sécurité.
Cette étude de sécurité doit intégrer la transmission des données en interne à l’équipement.
1.5.1.6 Intégrité des données

L’intégrité des données est couverte par la classe I2 de la norme (IEC 60870-4, 2013)
définissant un taux de probabilité d’erreurs résiduelles d’informations inférieur ou égal à 10-
10
.
Cette exigence doit couvrir chaque moyen de communication interne (réseau compris) du
dispositif ou élément du dispositif.
1.5.2 Sûreté du fonctionnement des cartes Entrées/Sorties
Assurer l’intégrité des données commence par l’acquisition sécurisée des entrées et la
transmissions sécurisées des ordres. Ce paragraphe décrit les principes mis en place pour
assurer cette intégrité.
41
1.5.2.1 Carte 4 Télé Commandes Doubles / 4 Télé Signalisations Doubles (4TCD/TSD)
Les modules 4TCD/TSD (Figure 12) sont des cartes d’entrées/sorties sécurisées adaptées à la
commande de quatre appareils. Chaque appareil est connecté en face avant du module par un
câble qui part du bornier de l’appareil (face arrière du châssis) jusqu'à l’automate.
Ce module permet d’envoyer des ordres de Commande d’Ouverture (CO) et de Commande de
Fermeture (CF) vers quatre appareils. Il permet également de vérifier l’état des appareils au
travers des Signalisations Ouverte (SO) et Signalisation Fermée (SF). Une led Local Distant
Individuel (LDI) permet pour chaque organe de vérifier si le contrôle de l’appareil est en
commandé en local individuel. Une led d’avertissement Watchdog local (Wdl) permet de
vérifier le bon fonctionnement de la carte.
Un module de type TéléCommande Double (TCD) restitue des ordres issus de télécommande
et/ou de séquences d’automatismes. Il réalise l’acquisition des états de position (TSD) de
l’organe pris en compte, pour un traitement d’automatismes et/ou de télésignalisations.
Figure 12 : Représentation de la carte 4 TCD/TSD de l’ACS21
1.5.2.2 Carte 16 Télé Signalisations Simples (16 TSS)

Les modules 16 TSS (Figure 13) sont des cartes d’entrées redondées qui reçoivent des
signalisations. Les signalisations sont connectées deux par deux à l’automate. Ces modules
peuvent, comme les entrées des 4TCD/TSD, être alimentés en 24, 48, 120V.
Ces modules assurent l’acquisition des informations simples TOR issues des capteurs de
l’installation. Pour information on utilise le terme Signalisation (S*).
42
Entrées
Entrée 1 Led Verte

Entrée 2 Led Verte
C24V= Electronique
Com (*) de Signalisation
C48V=
C125V=
Défaut Module TSS Led Rouge
8 Blocs de signalisations S1-S2, S3-4,.........à S15-S16
(*) Dépend de la polarisation +24V, +48V, +125V
Figure 13 : Représentation d’une carte 16 TSS de l’ACS21.

Le principe de ce module pour les adaptations de tension est le même que pour le module
contrôle/commande. Chaque groupe de deux TSS sera totalement indépendant au niveau des
communs des deux signalisations. Une led d’avertissement Watchdog local (Wdl) permet de
vérifier le bon fonctionnement de la carte.
1.6 Programmes Binaires ou Noyau ISaGRAF
Les travaux réalisés pendant cette thèse ont été appliqués pour l’automate exploité et seront
appliqués pour les futurs automates. Les programmes, quel que soit l’API utilisé, devront
respecter les principes et la structure présentés dans cette section.
En dehors des abonnés RTU et TCO, chargés avec un programme applicatif dédié et
immuable, les abonnés automates ont besoin d’être préalablement initialisés avec un
programme appelé « Noyau ISaGRAF » permettant ainsi de charger dans chaque abonné
automate l’applicatif élaboré à partir du logiciel ISaGRAF de la société ICS Triplex.
Le noyau gère dans chaque abonné :
 Les mémoires (RAM, FLASH, EEPROM)
 Les ports de communication (FIP, Modbus, RS485,…)
 Les cartes Entrées/Sorties
 Cycle automate
 Watchdog
Il assure les liens entre les séquences d’automatismes provenant de l’atelier ISaGRAF et les
fonctions de lecture ou d’écriture sur FIP, les échanges des informations des ports Modbus,
les fonctions de lecture ou d’écriture en EEPROM…
43
Il contient également le domaine d’adresses TC et TSS de chaque abonné. Cela sous-entend

qu’il existe 16 « noyaux » différents correspondants chacun à une plage d’adresses HNZ ne se
chevauchant pas.
Certains paramètres tel que les temporisations d’ouverture ou de fermeture, l’activation ou la
désactivation d’une commande, le passage des TSS en direct ou en inverse, sont facilement
modifiables par l’intermédiaire du logiciel SCLA qui écrit ces paramètres dans l’EEPROM de
l’API.
L’atelier logiciel IsaGraf 3.32 permet d’écrire les séquences d’automatismes nécessaires au
fonctionnement des installations. Les langages utilisés dans les applications sont les langages
décrits par la norme (IEC 61131-3, 2003). Au commencement de cette norme, qui existe
depuis 1992, les programmes étaient considérés, d’une manière générale, comme composés
de sous-programmes pouvant être écrits dans l’un des cinq langages reconnus par la norme :
 FBD (Function Block Diagram) : ce langage permet de programmer graphiquement à
l’aide de blocs, représentant des variables, des opérateurs ou des fonctions. Il permet
de manipuler tous les types de variables,
 LD (Ladder Diagram) : ce langage graphique est essentiellement dédié à la
programmation d’équations booléennes, il est proche du schéma électrique et inspiré
des schémas à relais,
 ST (Structured Text) : ce langage est un langage textuel de haut niveau. Il permet la
programmation de tout type d’algorithme plus ou moins complexe, comparable au
langage C,
 IL (Instruction List) : ce langage textuel de bas niveau est un langage à instruction. Il
peut être comparé au langage assembleur,
 SFC (Sequential Function Chart) : représentation graphique issue du langage
GRAFCET (IEC 60848, 2002), ce langage, de haut niveau, permet la programmation
aisée de tous les procédés séquentiels, en s’appuyant sur l’un des quatre autres
langages pour la programmation des étapes et des transitions.
L’exécution des programmes des API cibles d’IsaGraf 3.32 est cyclique comme le montre la
Figure 14. L’exécution des programmes est découpée en trois phases distinctes. Ces trois
phases permettent de séparer les programmes en fonction de leur rôle.
44
Figure 14 : Cycle API des cibles IsaGraf 3.32

Cette décomposition se retrouve dans l’architecture d’un projet (Figure 15), dont les
programmes sont présentés succinctement dans le paragraphe suivant.
1.6.1 Description des programmes automates
La Figure 15 donne un aperçu des programmes qui composent un cycle API pour le
contrôle/commande des EALE. Ces programmes sont décrits dans trois sous-paragraphes
pour les démarquer selon la phase du cycle à laquelle ils interviennent (début, séquentiel et
fin).
Figure 15 : Vue ISaGRAF 3.32 : Gestion d’un projet et découpage temporel
45
1.6.1.1 Programme de la phase « Début »
Cette phase est composée des différentes séquences suivantes :

La séquence « initialisation » écrit les valeurs de paramètres par défaut pour la configuration
automate, l’identification sur le réseau FIP et initialise la communication Modbus si elle
existe.
La séquence « lecture des paramètres » est chargée de la lecture du fichier de paramètres dans
la mémoire EEPROM.
La séquence « écriture des paramètres » vérifie que la lecture des paramètres s’est bien passée
et renvoie un code d’erreur sinon.
La séquence « AcquiFIP » récupère les variables sur le réseau FIP. Les variables FIP sont
envoyées depuis les différents abonnés du réseau. Selon le rôle de l’abonné automate, cette
séquence récupère :
 des ordres provenant du RTU sur FIP,
 des ordres provenant du TCO sur FIP,
 des réflexes provenant des autres abonnés sur FIP,
 des positions des appareils des autres abonnés,
 des variables systèmes et d’aiguillage du système,
 des variables de synchronisation de la date et de l’heure.
La séquence « d’acquisition des entrées des cartes TCD/TSD » récupère pour chaque appareil,
les signalisations ouverte (so) et fermée (sf). La complémentarité de ces deux entrées est
vérifiée pour construire la position de l’appareil. Cette étape assure l’intégrité des données au
niveau logiciel.
La séquence « d’acquisition des entrées des cartes TSS » récupère pour chaque entrée TSS,
les deux signaux complémentaires. La complémentarité de ces deux entrées est vérifiée pour
construire la TSS. Cette étape assure l’intégrité des données au niveau logiciel.
La séquence de détection des « défauts d’entrées/sorties » vérifie le statut renvoyé par chaque
organe télécommandé de chaque carte TCD/TSD ainsi que le statut des cartes TSS pour
construire l’information défaut carte.
46
1.6.1.2 Programmes séquentiels (SFC)
Cette phase est constituée uniquement de programmes séquentiels de type SFC :

Les programmes SFC d’aiguillage permettent d’aiguiller les ordres de commande selon trois
cas. Un appareil peut être commandé en :
 distant, par le CSS.
 local général, toute l’installation est commandée localement par un agent de
maintenance sur le TCO local.
 local individuel, par un agent connecté localement sur l’automate par un poste de
commande locale (PCL)
Dans certain cas, des appareils sont prévus en réserve, alors une quatrième branche existe
permettant de définir l’appareil comme non utilisé.
Les programmes SFC de commande permettent l’exécution séquentielle des ordres reçus. Ils
activent les sorties des cartes TCD pour la bonne manœuvre des appareils et maintiennent les
ordres lorsque cela est nécessaire.
1.6.1.3 Programmes de fin de cycle
La séquence télégestion fige l’état des positions des appareils pendant 5 secondes afin
d’enregistrer les changements de positions et de les envoyer à la télégestion.
La séquence « PCL_OUT » crée les variables analogiques utilisées lors de la connexion en
local individuel à l’automate, c’est-à-dire lorsqu’un poste de commande local est connecté à
l’automate.
La séquence « FIP_OUT », fonctions d’écriture sur le réseau FIP est chargée de renvoyer des
informations pouvant être consommées par les autres abonnés, en outre :
 Ecriture des TSD distantes
 Ecriture des TSD locales
 Ecriture des TSS
 Ecriture des SSL (signalisations simples locales (messages afficheurs)
 Construction des réflexes (variables de déclenchement d’un appareil)
 Ecriture des réflexes
 Ecriture des SSI (variable LDI)
 Ecriture des SYS (Défaut Carte)
 Ecriture des analogiques
 Ecriture des infos télégestion
47
La séquence « défaut carte » force toutes les sorties de l’abonné à leur état de sûreté,
désactivée, en cas de détection d’un défaut sur une carte de l’API.
1.6.2 Synthèse
La sûreté du fonctionnement des installations est assurée par un système de

contrôle/commande/protection dont l’ingénierie de l’infrastructure SNCF est garante. Au sein
de cette branche, le département PROJETS SYSTEME INGENIERIE de Traction Electrique
(PSIGT-TE) est en charge de spécifier les équipements de téléconduite, automatismes,
protections Basse Tension (BT), du marché des Equipements d’Alimentation des Lignes
Electrifiées (EALE). Dans la partie suivante, la sûreté du fonctionnement est intégrée à la
présentation du métier des EALE pour comprendre les enjeux du travail réalisé par la section
en charge des études de téléconduite, automatismes et protection BT, CES2 (Conception et
Expertise des Systèmes).
1.7 Le métier des EALE
Un projet d’électrification d’EALE se décompose en plusieurs phases (Figure 16). D’abord

une phase préliminaire de définition des spécifications au travers d’un cahier des charges
fonctionnelles (CdCF) permettant de définir les besoins et les contraintes de l’installation.
Cette phase s’accompagne de la réalisation des schémas électriques décrivant l’installation et
l’architecture de contrôle/commande/protections associées. Viens ensuite la phase d’étude et
d’écriture des programmes d’automatisation qui doivent respecter les règles de conception
déjà établies par PSIGT-TE. Un ensemble de procédures d’essais, regroupé au sein d’un
cahier de recettes, doit ensuite être réalisé afin de permettre de vérifier et de valider le bon
fonctionnement des programmes (essais sur plateforme, phase 1) et du système. Les
procédures d’essais ont lieu en usine dans un premier temps pour valider le câblage (essais en
usine, phase 2) et la compatibilité des programmes. Après une phase de correction, les essais
ont lieu sur site pour valider l’ensemble du système et la commande électrique des appareils
Haute Tension (essais sur site, phase 3). La validation du cahier d’essais en usine et sur site
permet de s’assurer de la sécurité du système.
La sécurité du système de contrôle/commande des EALE nécessite d’introduire l’événement

critique redouté. Cet événement redouté est une commande intempestive d’appareil HT
(ouverture ou fermeture), elle entrainerait de lourdes conséquences matérielles et pourrait
48
compromettre la sécurité humaine. C’est pourquoi le domaine de la traction électrique est

soumis à des contraintes de sûreté du fonctionnement fortes (IEC 60870-4, EN 50126). Le
chargé d’études a la responsabilité de valider le cahier d’essais, une fois complété de
l’ensemble des tests réalisés et ainsi de confirmer que l’intégrité de l’installation est assurée.
Le cahier d’essais doit être le plus exhaustif possible pour vérifier l’ensemble des
fonctionnalités et surtout l’ensemble des fonctions sécuritaires du système de
contrôle/commande/protection. La rédaction de ce cahier de recette est une tâche longue et
peu intéressante pour le chargé d’études car les fiches d’essais existent et il n’a qu’à récupérer
et adapter les fiches correspondantes au système étudié.
Figure 16 : Découpage des phases d’un projet d’électrification

Des durées sont attribuées à chaque tâche (Tableau 4). Pour travailler sur un projet, le chargé
d’études doit pointer ses heures sur un compte projet. Etant donné le temps limité de chaque
tâche, un nombre d’heures équivalent lui est attribué. Ces deadlines sont sources d’un stress
supplémentaire pour les chargés d’études. Une étude a été menée auprès des chargés d’études
par rapport à l’évolution de leur charge de travail due aux travaux menés lors de ce projet de
recherche. Cette étude réalisée au travers d’un questionnaire anonyme montre que la charge
de travail estimée d’après les chargés d’études est supérieure à 100%. L’analyse des
questionnaires est détaillée à la fin du chapitre 4, les questionnaires sont disponibles en
49
Annexe 10. Cette surcharge de travail est due aux différents projets qu’ils ont à mener en
parallèle.
Tableau 4 : Temps limité pour chaque étape du projet
Phases d'un projet Temps estimé
par projet (en
heures)
Pré-études 70h
CdCF et liste matériel 40h
Schémas généraux 30h
Etudes 80h
Validation schémas 30h
Programmes et fichier de 50h
paramétrage
Vérifications 80h
Cahier de Recette 40h
Essais Usine 40h
Corrections 20h
Corrections 20h
Validations 40h
Essais Site 40h
Total des heures 290
Ce travail de conception et d’étude des EALE, réalisé par les chargés d’études, nécessite une
forte activité intellectuelle pendant toute la durée du projet et une concentration pour ne pas
commettre d’erreurs. Cette concentration peut être altérée par différents éléments. L’élément
le plus probant d’altération de cette concentration, réduisant l’efficacité du chargé d’études est
la pluralité des projets en cours qu’il doit réaliser dans un temps limité. En effet un nombre
d’heures est alloué à chaque tâche d’un projet, en fonction de la complexité de la structure de
l’EALE. La notion de deadline peut entrainer un stress supplémentaire (Sargent et Terry,
2000). Ne serait-ce qu’au sein du « workflow » du projet, la multiplicité des outils
informatiques de réalisation des différentes tâches n’aide pas le chargé d’études à optimiser
son temps de travail. Le changement d’outil peut entrainer une perte d’informations et des
50
erreurs de recopie. De plus une relation a été montrée entre la multiplication des ressources et
le travail de mémorisation (Baddeley, 1990) pouvant mener à une surcharge mentale (Young
& Stanton, 2001).
Cette pluralité des outils, indispensable pour fournir les différents livrables (documents,
programmes, schémas électriques…), entraine également une saisie multiple des mêmes
informations concernant un même projet. Cette répétitivité d’actions, en plus d’être source
potentielle d’erreurs et une perte de temps, nuit à la concentration ainsi qu’à l’intérêt que le
chargé d’études porte à son travail par le manque de valorisation et de reconnaissance. Sa
charge de travail mentale est de ce fait réduite, il s’agit de sous charge mentale (Stanton,
Young & McCaulder, 1997). Ces notions de charge mentale seront définies dans le chapitre
suivant, dans la partie traitant de l’aspect humain. De plus, les chargés d’études forment une
équipe mais travaillent séparément ce qui peut entrainer des différences d’interprétation des
principes mis en place.
1.8 Conclusion
L’ingénierie SNCF est aujourd’hui préoccupée par trois grandes problématiques :
 L’amélioration des conditions de travail des chargés d’études automatismes

 L’optimisation de la production
 La sûreté du fonctionnement
Comme nous venons de le voir, le workflow suivi pas les chargés d’études est composé de
phases nécessitant une forte concentration mais également de phases répétitives. Cette
variation de charge mentale n’est pas optimale pour la concentration des chargés d’études. Le
nombre d’outils menant à la saisie multiple des mêmes données d’entrée est également source
d’erreurs. Une solution permettant d’obtenir un environnement de saisie unique des données
d’entrées au travers d’une modélisation graphique semble donc intéressante. A partir de cette
saisie unique, la génération de documents tels que le cahier de recette, long et fastidieux à
écrire, peut offrir une alternative au workflow actuel que les chargés d’études accepteraient
d’intégrer dans leur travail.
Par optimisation de la production est sous-entendu un gain de temps de production des études
mais aussi une amélioration de la standardisation des études, qui mène a posteriori au même
51
objectif. Une solution pouvant mener à la résolution de cette problématique est la génération
de code API et de livrables des projets.
Les EALE sont des systèmes complexes, cependant leur structure est décomposable. Par cette
propriété, liée à l’aspect distribué de l’architecture de contrôle/commande/protection, un
travail sur la génération de code distribué est envisageable. L’aspect structurel et
décomposable en objets des installations est un aspect nécessaire et suffisant pour la
génération documentaire.
Ce chapitre a détaillé la sûreté du fonctionnement des EALE au niveau matériel et logiciel.

Pour améliorer d’avantage cet aspect, il a été proposé au département PSIGT-TE de travailler
sur les programmes de contrôle/commande afin d’apporter un niveau supplémentaire de
sécurité, séparé de la partie fonctionnelle, par la mise en place d’un filtre formellement
vérifié, empêchant l’envoi de commandes susceptibles de compromettre la sécurité du
système.
La sûreté des installations est également améliorable par la standardisation des principes et
des programmes. La génération de code est également considérée dans les moyens menant à
une évolution de la sûreté du fonctionnement du système.
Pour mettre en place ces deux propositions, qui ne sont pas décorrélées, une méthodologie
pour les études d’automatisation sera proposée dans le Chapitre 3. Les travaux qui ont inspiré
ce travail pour établir une méthodologie menant à la résolution des problématiques exprimées
par la SNCF, sont présentés dans le chapitre suivant.
52
Chapitre 2 : Etude des voies d’améliorations possibles du
métier des EALE
2.1 Introduction
Dans le chapitre précédent, les enjeux du domaine des Équipements d’Alimentation des
Lignes Electrifiées (EALE) ont été présentés. Les conditions de travail des chargés d’études,
l’optimisation de la production et la sûreté du fonctionnement sont les problématiques
auxquelles nous désirons apporter des éléments de solutions dans le cadre de ce travail de
recherche.
Les programmes des Automates Programmes Industriels (API) des EALE sont aujourd’hui
écrits par les chargés d’études. Ils s’inspirent de programmes existants d’installations
similaires ayant été validés en usine puis sur site. Cette façon de travailler, est critiquable car
elle ne permet pas de garantir la qualité des livrables et entraine une surcharge de travail des
chargés d’études comme cela a été montré dans le premier chapitre.
Ce chapitre présente les voies de progrès explorées afin de répondre à ces problématiques.
L’optimisation de la production des études d’électrification nécessite de prendre en
considération l’aspect économique, technique mais également humain.
L’approche présentée dans ce manuscrit propose et intègre deux axes d’amélioration visant
d’une part à augmenter la productivité tout en améliorant les conditions de travail des chargés
d’études, et d’autre part à garantir la sûreté de fonctionnement du système.
Le premier axe retenu est la génération automatique des livrables (documentation, schémas,
cahier de recettes…) et plus particulièrement du code API, réalisés par les chargés d’études.
C’est un moyen de réduire le temps de travail des chargés d’études en leur évitant des tâches
souvent routinières. Cette amélioration des conditions de travail devrait entrainer une
régulation et une amélioration de leur charge de travail mentale en évitant les erreurs
consécutives à la sous-charge et à des pics de surcharge. Toutefois, cela entraîne une
modification de leurs activités qui doit être acceptable et acceptée. Ce travail s’est présenté
dans une conjoncture favorable pour être accepté par les chargés d’études étant donné leur
53
Chapitre 2 : Etude des voies d’amélioration possible du métier des EALE
surcharge de travail généralisée, due au nombre important de projets prévus et au peu de

recrutements. Les chargés d’études voient le projet comme une aide et non comme un risque
ou un concurrent pouvant conduire à la suppression de leur poste. Il est également important
de noter que la génération automatique ne peut pas se faire sans standardisation. C’est une
condition nécessaire à la génération automatique des livrables et elle ne peut se faire sans le
partage du savoir-faire des chargés d’études.
Le deuxième axe concerne la commande. En effet, l’écriture des programmes API est
aujourd’hui une des tâches essentielles des chargés d’études. Il est fondamental, si nous
désirons automatiser partiellement ou totalement cette activité, de générer du code API de
qualité et standardisé tant sur le plan de l’écriture (respect de règles génériques ou métiers,
lisibilité, commentaires, absence de code mort) que du fonctionnel (code vérifié, validé, sûr
de fonctionnement et robuste aux erreurs des opérateurs humains des CSS).
Les aspects économiques, techniques et humains sont donc étroitement liés dans la recherche
d’outils et de solutions pour les chargés d’études responsables du contrôle/commande des
EALE. La première partie du chapitre s’intéresse aux EALE sous l’angle « Système Homme-
Machine » (SHM) en détaillant les composantes techniques et humaines. Ce travail permet
d’orienter les choix de solutions pour les 2 voies d’amélioration proposées.
La deuxième partie du chapitre est consacrée au premier axe d’amélioration : la génération

automatique de livrables (codes, documents…). Les approches « informaticiennes » sont
détaillées et les solutions existantes dans le monde des automatismes sont présentées. Enfin,
la troisième et dernière partie du chapitre s’intéresse à la synthèse de la commande et
concerne le deuxième axe d’amélioration retenu.
2.2 Une approche « Système Homme-Machine » du métier des EALE
Pourquoi et quand automatiser ? L’approche centrée technique considère qu’il faut

automatiser à partir du moment où cela est possible. L’approche humaniste consiste à
automatiser les tâches pénibles, ennuyeuses ou encore risquées pour un être humain.
L’approche économiste préconise l’automatisation lorsqu’elle revient moins chère. Enfin,
l’approche de l’automatique « humaine » considère que l’automatisation ne consiste pas à
retirer purement et simplement l’homme de la boucle de contrôle/commande. De ce fait,
54
automatiser consiste à concevoir un système qui accomplit partiellement ou totalement une

fonction qui était ou pourrait être partiellement ou totalement réalisée par un opérateur
humain (Parasuraman et al., 2000). Cette définition implique que l’automatisation peut varier
selon différents niveaux, allant du mode manuel au tout automatique, et qu’un système
automatisé est dans bien des cas amené à fonctionner avec un ou plusieurs opérateurs
humains. La prise en compte de ces derniers impose donc une approche différente de
l’automatisation (Riera et al., 2003) (Debernard et al., 2013).
Riera (Riera, 2001) a présenté l’approche de l’automatique humaine en l’articulant autour de

4 points :
1- L’objectif principal est l’amélioration globale du Système Homme-Machine (SHM) étudié.
Dans le cas des EALE, cela signifie que les solutions ou outils retenus doivent nécessairement
être adaptés aux chargés d’études et donc à leur langage métier.
2- Il ne faut pas s’intéresser uniquement aux performances techniques, mais aussi aux effets
induits par la mise en place d’un artefact. Pour cela, le SHM doit être étudié en tenant compte
aussi bien des caractéristiques de l’homme (nécessité de modèles décisionnels et d’activités)
que de celles du système technique. Le chargé d’études reste dans la boucle de conception du
contrôle/commande. Il n’est pas possible ni envisageable aujourd’hui de le retirer. Les outils
mis à sa disposition doivent être adaptés à ses besoins et non l’inverse. Il est donc absolument
nécessaire de le prendre en compte dans la phase de définition, de conception et de choix des
méthodes et des outils qui lui sont destinés.
3- L’automatique humaine propose des alternatives à l’automatisation centrée sur la
technique. La coopération homme-machine (Millot, 2014) et la répartition dynamique de
tâches (Debernard et al., 2014) sont des solutions originales proposées et évaluées par
l’automaticien humain.
4- L’automatique humaine attache beaucoup d’importance à la phase d’évaluation du système
homme-machine. Les critères d’évaluation doivent tenir compte des performances globales du
SHM, exprimées par exemple en termes d’écart entre la production réelle et les objectifs, mais
également de critères permettant d’évaluer les difficultés rencontrés par les opérateurs
humains dans la résolution de problèmes et la communication avec l’outil technique, au
travers par exemple de l’évaluation de la charge de travail. Ce point est également essentiel
dans notre cas d’études. Il est primordial d’avoir un retour d’expérience des chargés d’études
suite à l’introduction de nouveaux outils et méthodes modifiant ses activités et ses conditions
55
de travail. L’automaticien « humain » considère donc l’automatisation selon une approche

globale intégrant l’homme, en s’attachant également aux interactions entre l’homme et le
système technique.
Cette approche de l’automatisation est générique et s’applique également à notre cas d’étude :
l’automatisation des EALE par les chargés d’études.
2.2.1 Composante économique et technique
L’automatisation des EALE est confrontée à la même difficulté que l’automatisation des
systèmes manufacturiers. La qualité des études doit être améliorée tout en ayant un coût
moindre. Il s’agit donc de réduire le temps d’étude tout en assurant la sûreté du
fonctionnement et la sécurité du système. L’automatisation des EALE doit donc répondre à
des objectifs économiques et techniques. Les objectifs économiques s’intéressent aux
bénéfices financiers de l’entreprise et portent sur la diminution des coûts de fonctionnement,
gain de temps sur les études, amélioration structurelle du système, recherche de solutions
économes, … Les objectifs techniques sont liés au processus de conception de la Partie
Commande. Pour les atteindre, il est nécessaire de travailler sur :
 La diminution de la durée du cycle d’étude en prenant en compte les durées

administratives, d’approvisionnement, de réalisation…
 L’augmentation de la qualité des programmes en assurant le niveau de qualité attendu
par les exigences en termes de fiabilité, disponibilité, maintenabilité et sécurité
(FDMS),
 L’augmentation de la disponibilité des EALE en diminuant entre autres les temps de
maintenance.
L’automatisation des EALE, comme nous l’avons vu, ne peut pas être considérée sans
prendre en compte la composante humaine et les conditions de travail des chargés d’études.
2.2.2 Composante humaine
Les études EALE et les essais contiennent aujourd‘hui des tâches stressantes, répétitives,
pénibles pour les chargés d’études. Nous proposons d’analyser leur activité au travers du
concept de la charge de travail utilisé dans l’analyse des Systèmes Homme-Machine. Il s’agit
d’une notion complexe dont l’usage a été étendu à plusieurs secteurs de la psychologie et de
56
l’ergonomie (Richard, 1996). Elle désigne les conséquences physiques et mentales de

l’exécution de la tâche sur l’opérateur. La tâche proprement dite et ses contraintes sont
regroupées sous la dénomination d’exigences du travail (Leplat, 1997).
L’étude de la charge de travail met en relation l’aspect physique et l’aspect mental de
l’opérateur, car son état physique conditionne ses capacités mentales et sa tolérance à l’effort
(Cnockaert & Floru, 1991). Toutefois, nous considérons l’effort correspondant au coût de
travail mental comme résultant uniquement de la mobilisation de l’ensemble des fonctions
mentales mises en jeu par l’opérateur pour réaliser une tâche (Lancry & Lammens, 1998).
La charge de travail mentale (ISO 10075:1991) dans le domaine de l’automatisation est un

sujet au cœur des préoccupations depuis quelques années. Cette notion n’a jamais été
totalement cernée et fait partie du débat social lié à l’intensification du travail (Hamon-Cholet
& Rougerie, 2000 ; Askenazy & Caroli, 2003). Elle est définie comme la mesure quantitative
ou qualitative du niveau d’activité nécessaire à l’accomplissement d’un travail donné
(Sperandio, 1980). En d’autres termes, le concept de charge mentale se définit
fondamentalement en termes de relation entre l’offre (ressources disponibles) et la demande
(Wickens, 1984).
Lorsque le coût en travail mental est excessif par rapport à la tolérance de l’opérateur, il s’en
suit une situation de surcharge. La surcharge intervient donc dans une situation telle que
l’organisme ne peut plus traiter toute l’information disponible. La surcharge mentale peut
provoquer un nombre élevé d’erreurs (Millot, 1987) et nuit à la performance de l’opérateur.
A l’inverse, lorsque l’organisme travaille en deçà de ses possibilités, il est confronté à un
phénomène de sous-charge qui risque de provoquer un « endormissement » et des erreurs de
l’opérateur (Sperandio, 1988). On peut classer cet état dans la catégorie dite «
d’hypovigilance », observée le plus souvent dans les tâches répétitives (François, 1989). La
Figure 17 montre la relation entre la charge de travail mentale et la performance de
l’opérateur, elle montre bien que les extrêmes provoquent une baisse de la performance. La
sous-charge mentale diminue les performances de l’opérateur, comme nous pouvons
l’observer sur la partie gauche de la courbe de performance. En effet, après un travail peu
intéressant nécessitant peu de capacités intellectuelles, il est plus difficile pour un individu de
démarrer une tâche demandant un haut niveau de réflexion cognitive et de concentration
(Young & Stanton, 2002) ; ce qui est d’autant plus vrai dans le domaine de l’automatisation
des systèmes sécuritaires complexes comme le nôtre (Amalberti, 2001). Ce changement
soudain de niveau de concentration nécessaire peut être source d’erreurs humaines. Celles-ci
57
doivent être réduites au maximum dans la réalisation de systèmes sécuritaires. Bien qu’elles
puissent être décelées lors des essais de validation, il est préférable de les inhiber en amont.
Figure 17 : Courbe en U inversé montrant l’influence de la charge de travail sur la

performance (loi de Yerkes & Dodson, 1908).
Le travail de conception et d’étude des EALE, réalisé par les chargés d’études, nécessite en
moyenne une forte activité intellectuelle pendant toute la durée du projet et une concentration
pour ne pas commettre d’erreurs. Cette concentration peut être altérée par différents éléments
parmi lesquels on peut citer la pluralité des projets en cours qu’il doit réaliser dans un temps
limité. En effet un nombre d’heures est alloué à chaque tâche d’un projet, en fonction de la
complexité de la structure de l’EALE. Le stress dû aux « deadlines » (Sargent & Terry, 2000)
peut conduire à une surcharge mentale. Une autre difficulté rencontrée par le chargé d’études
concerne la multiplicité des outils informatiques de réalisation des différentes tâches au sein
du « workflow » du projet. Cela ne l’aide pas à optimiser son temps de travail. Le changement
d’outil peut entrainer une perte d’informations et des erreurs de recopie. A ce sujet, une
relation a été montrée entre la multiplication des ressources et le travail de mémorisation
(Baddeley, 1990) (Wickens et al., 1998) pouvant mener à une surcharge mentale (Young &
Stanton, 2001).
Il est donc concevable que la tâche cognitive de conception des EALE pourrait être assistée
par un outil logiciel afin d’éviter une surcharge de travail, mais également les erreurs de
routine (Coupat et al., 2013). L’homogénéisation des documents et des livrables, et leur
génération automatique semblent être une solution pertinente car elle permet de gagner en
performance et en qualité, et facilite la lecture d’un projet par l’ensemble des intervenants.
Toutefois, ce travail ne peut pas se faire sans standardisation et peut conduire à une
modification des activités des chargés d’études qu’il convient d’évaluer.
58
On notera également que la génération automatique de livrables en contribuant à

l’amélioration de leur qualité et de leur sûreté de fonctionnement évite du stress à celui qui
conçoit le système car la qualité des livrables peut être garantie.
2.3 1er axe d’amélioration : la génération automatique de livrables
Naturellement, une diminution du temps de réalisation des études conduit à une diminution
des coûts. Actuellement, une partie importante du temps d’étude est consacrée à un travail
répétitif. La standardisation permet la réutilisabilité et par là même la génération automatique
(de documents, codes, …). Il s’agit de thèmes de recherche d’actualités, porteurs d’enjeux
industriels importants, car ils contribuent à l’amélioration de la qualité et de la maintenabilité
tout en diminuant le temps de développement. Toutefois, ce problème est étroitement lié au
domaine applicatif et, reste encore ouvert. En effet, la technologie évolue sans cesse et
rapidement, tout comme les processus d'étude du domaine spécifique (c’est le cas des études
d’automatismes des EALE). La première raison qui explique que ce problème n'a pas encore
été résolu est la diversité technologique qui existe dans le milieu industriel. Chaque appareil a
un fonctionnement différent et donc une commande spécifique. Cette diversité conduit à une
nouvelle phase d’étude du système à chaque changement d'architecture technologique ou
typologique. En second lieu, même si le domaine spécifique est décrit à l'aide des outils
« traditionnels » du domaine, les modèles ainsi obtenus ne servent en général que de
documentation, de sorte qu'ils ne sont pas transformables en code de programme exécutable
par exemple. Le problème le plus observable est généralement le manque de spécifications
complètes et exactes décrivant les objectifs fonctionnels et sécuritaires des programmes ou
encore l’architecture que les programmes doivent suivre. Par conséquent, la difficulté majeure
du développement de logiciels spécifiques à un domaine métier est dû à un espace sémantique
entre les modèles et le langage de programmation (Bajovs et al., 2013), qui permet la
transformation de la description du domaine spécifique en code exécutable.
L'esprit humain perçoit l'information graphique bien mieux que l’information textuelle
(Bajovs et al., 2013). C’est pourquoi il est utile de décrire un système au travers un modèle
pendant sa phase de description. Le langage de modélisation unifiée (Unified Modeling
Language – (UML, 2011)) est très employé en génie logiciel pour modéliser les systèmes
orientés objets. L’UML a été créé non seulement comme outil de spécification de systèmes,
mais également comme outil permettant de produire automatiquement le code associé aux
modèles UML. On notera le développement de SysML (Pearce & Friedenthal, 2013) qui
59
reprend et adapte les concepts d’UML pour la conception dans le domaine de l’ingénierie des
systèmes.
Dans notre cadre d’étude, la génération de code API est un verrou technologique à lever sur
lequel une solution doit être apportée pour la SNCF. C’est pour cela que dans la suite de ce
chapitre nous focaliserons plus particulièrement le propos sur la génération de codes
informatiques. Toutefois, la standardisation doit également permettre la génération de la
documentation, des Interfaces Homme-Machine et du cahier de recette, qui sont également
des activités chronophages et sources d'erreurs pour les chargés d'études.
2.3.1 UML ou MDD pour la génération de code ?
Générer complètement du code à partir des modèles est un objectif industriel depuis de
nombreuses années. Les modèles servent de mécanismes à une meilleure compréhension et
une meilleure documentation, mais ils peuvent également être employés pour produire du
code complet et fonctionnel. Ceci automatise le développement menant à une amélioration en
productivité, en qualité et en dissimulation de la complexité. L'organisation OMG donne la
définition suivante d'un modèle (UML, 2011) : « Le modèle d'un système est une description
ou des spécifications de ce système et de son environnement pour certains objectifs ». (Völter
et al., 2013) insiste sur l'importance de l’utilisation de la modélisation en général dans le
développement de logiciel moderne en écrivant : « Sur la base des années de ma propre
expérience, aussi bien que sur l’expérience de la communauté globale du développement
dirigé par les modèles (Model Driven Development – MDD), je suis convaincu que le MDD
est un pas dans la bonne direction et provoque des améliorations significatives de la
productivité, de la qualité et de l’ensemble du système ». Selon (Völter & Groher, 2007), la
modélisation en MDD est compacte et formelle en même temps. Elle contient la signification
précise du code de programme de sorte que le modèle ne soit pas seulement une
documentation mais aussi une partie du logiciel. Le MDD est apparu parce qu'il y avait la
nécessité pour diminuer les efforts, de créer et d’employer des modèles d'analyse et de
conception à chaque étape du processus d’étude et de développement des programmes et
d'automatiser la transformation des modèles (Eveleens & Verhoef, 2010).
En informatique l’UML est un langage de modélisation graphique à base de pictogrammes. Il
est utilisé en développement logiciel, et en conception orientée objet. L’UML est couramment
utilisé dans les projets logiciels. Malheureusement, les outils actuels d’UML sont basés sur les
60
langages de programmation, ce qui limite les possibilités d'abstraction de conception pour

réaliser une génération de code complète. Par exemple, l’UML emploie directement les
concepts de programmation (classes, valeurs de retour, etc.) comme modelant des concepts.
Le symbole de rectangle illustre une classe dans un diagramme et sa représentation textuelle
équivalente dans un langage de programmation ne fournit pas de vraies possibilités de
génération. En général, seul le squelette de la classe est généré. Le niveau d’abstraction des
modèles et du code est identique.
L’Object Management Group (OMG, 2012), qui est à l’origine de l’UML, a proposé en 2001
une architecture dirigée par les modèles (Model Driven Architecture – (MDA, 2012)). Depuis
l’annonce du MDA, différents outils spécifiques ont été développés, capables de produire une
partie du code à partir du modèle du système. De nos jours, les outils de MDA sont annoncés
comme étant capables de supporter les transformations de modèles, comme par exemple le
passage de modèle indépendant de la plateforme (Platform Independant Model – PIM) au
modèle spécifique à une plateforme (Platform Specific Model - PSM) et à la génération de
code. Cependant, personne n’a encore communiqué sur un logiciel qui serait basé seulement
sur les principes de MDA. L'alternative à l'approche de MDA et d'UML est la modélisation
spécifique de domaine (Domain Specific Modeling – DSM (Tolvanen, 2005)), qui permet de
spécifier le comportement d’un système particulier.
2.3.2 Principes de la génération de code par MDA et DSM
Ce paragraphe décrit les principes de MDA et de DSM et les normes associées à la génération
de code, qui ont été créés par l’organisation OMG. L'importance de la génération de code a
été justifiée dans la section précédente par son intérêt qualitatif, productif et pérennisant. En
raison de l'importance de ce processus, les techniques, les méthodes et les approches relatives
ont été étudiées. Plusieurs solutions permettant d’atteindre l’objectif de génération de code
ont été étudiées.
2.3.2.1 Principes du MDA
L'approche du MDA considère les modèles comme centraux dans le processus de

développement (supposant que le modèle représente un ensemble de diagrammes, employé
pour exprimer le système entier) (Jacobson et al., 2002). Le MDA est considéré comme la
prochaine étape dans l'évolution du processus de développement de logiciel, qui tend à
apporter quelques améliorations à chaque étape du cycle de vie de développement de logiciel.
61
Le MDA propose de construire quatre modèles de base pour le système développé. La Figure
18 présente un exemple emprunté à la banque.
Figure 18 : Exemple « métier » des modèles composant le MDA

Les quatre modèles de base pour le système développé sont :
 Le modèle indépendant de l’implémentation (Computation Independent Model - CIM)
qui reflète le métier et ses modèles. Le CIM définit les besoins du métier et ses
contraintes sans prendre en compte les contraintes techniques de programmation. Dans
l’exemple proposé, le CIM est le modèle contenant les différents acteurs et processus
d’une banque.
 Le modèle indépendant de plate-forme (Platform Independent Model - PIM) qui
reflète les modèles d'analyse et de conception du logiciel métier à développer. La
phase de conception à cette étape du processus suppose l'application de Design
Pattern, le découpage de l'application en modules et sous-modules, etc. Le rôle des
PIM est de donner une vision structurelle et dynamique de l'application, toujours
indépendamment de la conception technique de l'application. Pour le modèle bancaire,
cela revient à décomposer les processus (workflow) en sous-tâches de sorte que
chacune soit modélisée et structurée indépendamment.
 Un ou plusieurs modèles spécifiques de plate-forme (Platform Specific Models -
PSM) qui reflètent les modèles de conception détaillée du logiciel métier à
développer. Le PSM est le modèle qui se rapproche le plus du code final de
l'application. Un PSM est un modèle de code qui décrit l'implémentation d'une
application sur une plateforme particulière, il est donc lié à une plateforme
62
d'exécution. Pour le modèle bancaire, le PSM correspond aux modèles des sous-tâches
PIM convertis dans le langage de programmation adapté (java, C++, php…).
 Un ou plusieurs codes sources qui représentent le résultat final du processus MDA, le
code source est obtenu par génération automatique (partielle ou totale) du code de
l'application à partir du PSM. Le code source obtenu peut toujours être enrichi ou
modifié manuellement. Les modèles PSM permettent de générer le code associé aux
sous-tâches comme une interface de banque en PHP et les applications d’analyse des
données en Java, C++…
Les composants de MDA, visibles sur la Figure 18, représentent toutes les activités incluses
dans le processus de développement MDA. Les modèles CIM, PIM et PSM constituent les
étapes principales de l'approche MDA. Chacun de ces modèles contient des informations
nécessaires à la génération du code source de l'application. Le code est obtenu par génération
automatique à partir du PSM. Le PSM est obtenu par transformations successives des modèles
CIM vers PIM et des modèles PIM vers PSM. La transformation de modèles est une étape
importante du processus MDA, c'est grâce aux transformations que les modèles deviennent
des éléments productifs de MDA. L'exécution des transformations permet d'assurer un lien de
traçabilité entre les différents modèles du processus MDA. Ces liens sont un gage de qualité
du processus de développement logiciel dans le MDA.
 Transformations CIM vers PIM : Les modèles CIM expriment les besoins du métier.
Cette étape consiste à construire, partiellement, des modèles PIM à partir des CIM. Il
s’agit de la transcription des spécifications du métier vers un modèle qui permette de
les prendre en compte quelques soient les contraintes techniques.
 Transformations PIM vers PSM : Cette étape consiste à créer des modèles PSM à
partir des informations fournies par les modèles PIM, en y ajoutant des informations
techniques relatives à la plateforme d'exécution cible.
 Transformations PSM vers code : La transformation des modèles PSM en code source
consiste à générer le code source de l'application, de façon totale ou partielle, à partir
des modèles PSM de l'application.
Cette dernière étape n'est pas à proprement dit considérée comme une transformation par
MDA. En effet, une transformation selon MDA est définie par la transformation d'un modèle
vers un autre modèle, chacun d'eux étant structuré par leur méta-modèle (Bévan, 2013). Or le
code source n'a pas de méta-modèle, la transformation des PSM vers le code est plutôt
considérée comme une retranscription textuelle du modèle PSM.
63
2.3.2.2 Principes du DSM
La philosophie soutenue par le DSM pour résoudre les problèmes de génération est d’élever le
niveau d’abstraction des modèles. Les modèles ne devraient pas être conçus pour visualiser
les langages de programmation (comme l’UML), mais pour décrire les abstractions de plus
haut niveau du domaine spécifique.
Dans le DSM, et c’est là l’originalité, les éléments de modèle représentent des éléments du
domaine spécifique, pas des éléments de programmes, voire de code. Le langage de
modélisation suit les abstractions et la sémantique de domaine spécifique, permettant aux
concepteurs de modèles de travailler directement avec les concepts de domaine. Les règles du
domaine peuvent être incluses dans le langage comme contraintes, rendant impossible la
spécification de modèles illégaux ou non désirés. Le rapprochement entre le langage du
domaine et le domaine spécifique du métier permet d’élever davantage le niveau
d’abstraction. Cet intérêt majeur est la clé d’une productivité améliorée, d’une meilleure
dissimulation de la complexité, et d’une meilleure qualité de système.
Le plus haut niveau de l'abstraction varie entre les applications et les produits. Chaque
domaine contient ses propres concepts et contraintes spécifiques de conception. Par
conséquent, le langage de modélisation doit être spécifique pour chaque domaine. Prenons un
exemple proposé par (Tolvanen, 2005). Si nous devions développer un portail pour la
comparaison de produits d'assurance, pourquoi ne pas employer la terminologie d'assurance
directement dans le langage de conception ? Les concepts tels que « Risque », « Bonus »,
« Malus », « Dégâts » communiquent mieux le langage des assurances que les concepts de
classes Java. Un langage spécifique aux assurances peut également garantir que les produits
modelés sont valides : l'assurance sans bonus n'est pas un bon produit, ainsi un tel produit
devrait être impossible à concevoir (contrainte du langage). Ces concepts de domaine sont en
général déjà connus et déjà utilisés, ils sont plus naturels et reflètent déjà les modèles
fondamentaux requis pour concevoir les produits. Le code final peut être généré à partir de
ces caractéristiques de haut niveau. La pierre angulaire pour la génération automatisée de
code à partir des modèles est que le langage et les générateurs ont besoin de répondre
uniquement aux exigences du domaine spécifique du métier.
64
Figure 19 : DSM des services financiers d’une assurance (http://www.metacase.com)

La Figure 19 spécifie les produits d’assurance d’un conducteur. Tous les types d’incidents
existants sont représentés dans le modèle et correspondent à un produit de l’assurance. Le
modèle peut évoluer en cas de nouveau produit ou incident. A partir du modèle, il est possible
de générer les formulaires, les descriptifs des incidents et produits, des pages web, etc.
2.3.2.3 Avantages de DSM pour le domaine spécifique métier
On peut supposer que plus le niveau d’abstraction est élevé plus le gain en productivité est
fort. En effet, les changements de spécifications concernent habituellement le domaine
spécifique du métier et non les outils de modélisation. De plus, des modifications dans le
langage de modélisation qui emploie les termes du domaine spécifique sont plus faciles.
Enfin, dans un domaine complètement spécifié, les non-programmeurs peuvent définir les
caractéristiques complètes d’un système et utiliser un Générateur basé sur le DSM pour
générer l’intégralité du code.
Le DSM réduit le besoin d'apprendre une nouvelle sémantique. Les concepts du domaine du
métier sont en général déjà connus et employés, une sémantique bien définie existe et est
considérée comme « naturelle » puisqu’elle appartient aux utilisateurs du métier. Puisque la
65
sémantique du domaine spécifique doit être maîtrisée autant l’utiliser pour en faire un modèle
de haut niveau. Cette vision spécifique différencie le DSM et le MDA.
Le DSM mène à un système de meilleure qualité, principalement pour deux raisons. D'abord,
le DSM peut inclure des règles d'exactitude du domaine spécifique, empêchant la définition
de caractéristiques illégales ou non désirées. En second lieu, les générateurs sont basés sur les
prototypes de code source établis par le métier, à un niveau plus proche du code, et le résultat
produit n'a pas besoin d'être édité par la suite (si le comportement intégral du système a été
modélisé).
Les spécifications écrites à partir du langage spécifique du métier sont normalement plus
lisibles, compréhensibles, appréhensibles, validables et communicables (Tolvanen, 2005).
2.3.3 Synthèse des deux philosophies MDA et DSM
Après avoir décrit les grands principes du DSM nous pouvons maintenant le comparer à
d'autres approches basées sur des modèles, notamment l’approche MDA. Fondamentalement,
le MDA implique de transformer des modèles d'UML d’un plus haut niveau de l'abstraction
en modèles d'UML d’un niveau d'abstraction plus bas. Généralement il y a deux niveaux
d’abstraction, les PIM et les PSM. Ces PIM et PSM sont des modèles UML simples et
n'offrent ainsi aucun gain d’abstraction.
Dans le MDA, à chaque étape les modèles sont enrichis pour, à la fin, produire un code
substantiel à partir du modèle final. Le but de l'OMG avec le MDA est de permettre
d'employer le même PIM pour différentes plates-formes logiciel et de normaliser toutes les
transformations et les formats de modèles de sorte que les modèles deviennent portatifs entre
les outils de différentes sociétés. Cette réalisation est très ambitieuse mais également loin
d’être achevée. Cette vision presque antagoniste à celle du DSM qui se concentre sur un
domaine spécifique établit clairement la différence entre les deux philosophies.
Le DSM exige l'expertise de domaine, une capacité qu'une société peut acquérir seulement en
travaillant sans interruption dans le même domaine de métier. Ce qui est typiquement le cas
de l’ingénierie technique, garante du savoir-faire métier. L'indépendance peut être facilement
réalisée avec le DSM en ayant différents générateurs de code pour différentes plates-formes
de logiciel et/ou de produit. Mais surtout le DSM répond particulièrement aux besoins
exprimés pour les études EALE qui est d'améliorer de manière significative la productivité, la
qualité des études tout en conservant le langage et le vocabulaire technique établis du métier.
66
Le MDA ne se concentre pas sur l’utilisation de langages spécifiques aux métiers mais sur
l’UML générique. Il ne regarde pas comment encapsuler l'expertise de domaine qui peut
exister dans un métier. Le MDA exige une connaissance profonde de sa méthodologie,
connaissance externe à la société qui doit être acquise par expérience. Ainsi, tandis que
l'expertise de domaine requise pour le DSM est déjà disponible et appliquée dans la société,
l'expertise de MDA doit être acquise ou achetée à l'extérieur.
2.3.4 Examen des méthodes et des techniques de génération de code
Lorsque l’organisation OMG a lancé le MDA, elle a également décrit comment fonctionne
l’architecture MDA. De nos jours plusieurs normes liées à la génération de code existent
(OMG, 2012), mais aucune méthode ne peut fournir les directives complètes sur la manière de
convertir toute cette théorie en pratique. Cependant, les diverses méthodes et techniques
existantes essayent de définir certains aspects importants du procédé de génération de code.
2.3.4.1 Les approches de génération de code
Selon (Czarnecki & Helsen, 2003), les deux approches principales de génération de code sont
l’approche « visitor-based » et l’approche « template-based ».
L’approche « visitor-based » propose de générer le code à partir d’une représentation textuelle
du modèle.
L'approche « template-based » est l’approche la plus utilisée et permet de générer le code
pour les systèmes complexes. Cette approche implique d’écrire des canevas ou prototypes
textuels spéciaux (templates), qui forment fondamentalement un ensemble de règles. Ces
règles spécifient la manière de générer le code d'un modèle spécifique. Cette approche semble
la plus adaptée aux systèmes dont il faut conserver le savoir-faire métier et respecter les règles
d’écriture établies.
2.3.4.2 Les types de générateur de code
Cinq types différents de générateurs de code peuvent être choisis (Herrington, 2003) :
1. Le « code-munger » est le plus simple de ces derniers. Le « Mung-ing » signifie
transformer une chose d'une forme en une autre forme, ainsi le générateur parcourt le
fichier et recherche des mots clés ou des signets pour les remplacer par le contenu à
générer vers le fichier de sortie. Ce genre de générateur peut être employé pour
67
produire de la documentation, pour rechercher et collecter quelques informations

spécifiques ou pour produire certaines analyses des données d'entrée.
2. Un générateur « in-line » lit le code source et insère le code à générer aux
emplacements prédéfinis dans le fichier. La différence avec le code-munger est que le
fichier généré est identique à celui d'entrée mais avec un contenu modifié ou ajouté.
3. Un générateur « mixed-code » est la combinaison des deux types précédents. La
différence vient de la possibilité de modifier des secteurs entiers du fichier d’entrée en
incluant des signets dans des secteurs.
4. Le générateur « partial class » a besoin en entrée, du fichier de définition de la classe
objet et du template du fichier à générer. En analysant le fichier de définition de
classe, le template est rempli avec les attributs variables de l’objet. Le générateur de
classe partielle est utilisé pour produire des structures de base ou des bases de classes
objet qui pourront ensuite être complétées manuellement.
5. Le générateur capable de générer plus d’un tiers d’une application est dit « tiers ou
layer ». Il est semblable au générateur « partial class », sauf qu'il est capable de
générer une partie importante du code. Cela signifie que le générateur est doté de
fonctionnalités suffisantes pour générer des couches supérieures à la base de la classe.
Ce générateur est considéré comme le générateur dirigé par les modèles (Model
Driven Generator – MDG) dans lequel le modèle UML est l’entrée et jusqu’à 100%
du code est généré. C’est par ce générateur que la génération des programmes et des
livrables du métier des EALE est envisageable. La génération du métier des EALE,
système complexe, demande de décomposer le système en sous-systèmes et en objets
instanciables afin d’intégrer les différentes architectures possibles.
68
2.3.4.3 Les techniques de génération du code
(Volter, 2011) et (Küster, 2011) décrivent les techniques de génération de code telles que :
 La technique basée sur les templates et le filtrage (Figure 20) définit des sections de
code source généralisées comme canevas textuels. Pendant le procédé de génération
de code, les variables de ces canevas sont associées au modèle de système.
Figure 20 : Schéma de la méthode basée sur les templates et le filtrage

 La technique basée sur les templates et le méta-modèle (Figure 21) est très semblable
au précédent, sauf que le méta-modèle du système est créé avant que le canevas soit
exécuté de manière définie par l'utilisateur. Cela signifie que les canevas ne dépendent
pas du modèle et pourraient être écrits dans n’importe quel langage de programmation.
Figure 21 : Schéma de la méthode basée sur les templates et le méta-modèle

 Les générateurs basés sur les Interfaces de Programmation d’Applications
(Application Programming Interface – IPA) (Figure 22) sont habituellement associés à
un langage de programmation unique. Ainsi ils fournissent à l'utilisateur un cadre
spécial, qui rend le procédé de génération de code plus intuitif. Le code source est
généralement spécifié à l'aide des canevas. Les générateurs basés sur les IPA ont
souvent des compilateurs intégrés qui peuvent évaluer le code produit immédiatement.
69
Figure 22 : Schéma de la méthode basée sur les IPA

 La technique de génération « in-line » (Figure 23) définit que le code source du
programme contient des segments de texte, qui au moment de la compilation, selon les
conditions, peuvent être inclus ou non dans le programme global. Une telle technique
de génération de code est tout à fait primitive, donc elle ne peut pas être employée en
tant que principale, elle doit être associée à d’autres techniques de génération de code.
Figure 23 : Schéma de la méthode de génération « in-line »

(Bajovs et al., 2013) établissent une taxonomie des approches, par types et techniques de
génération en les séparant selon les deux familles : « template-based » et « visitor-based ».
Les taxonomies présentées sont strictes, toutefois dans la pratique un générateur de code peut
avoir les caractéristiques des approches « visitor-based » et « template-based ». Pour ces
raisons, ils concluent leur taxonomie en affirmant qu’il est difficile d’établir une réelle
classification des générateurs puisqu’ils incluent différentes techniques. Sur ce principe
assumé, il est préférable de considérer qu’ils peuvent donc être conjugués pour optimiser la
génération de code.
70
(Völter, 2011) établit une comparaison synthétique des différentes techniques de génération
(Tableau 5) selon trois critères :
 difficulté d’apprentissage,
 utilisabilité pour les systèmes complexes,
 utilisabilité pour la transformation du modèle vers le code.
Tableau 5 : Comparaison des méthodes de génération d’après Völter

Technique Difficulté Utilisabilité pour les Utilisabilité pour les
d’apprentissage systèmes complexes transformations de
modèles vers le code
Template +
Simple Pas très bonne Bonne
Filtrage
Template +
Haute Très bonne Très bonne
Méta-Modèle
Basée sur les IPA Dépend des IPA Dépend des IPA Pas très bonne
« in-line » Simple Pas très bonne Pas très bonne
Le Tableau 5 met en évidence l’intérêt de l’approche par templates et méta-modèles par son
applicabilité aux systèmes complexes et sa capacité à transformer le modèle en code. Bien que
cette méthode soit considérée comme compliquée, elle est la meilleure option pour répondre
aux problématiques de génération de code.
(Bajovs et al, 2013) ont réalisé une étude comparative des outils de génération de code tels
qu’IBM Rational Software Architect 8.0, Sparx Enterprise Architect 9, Microsoft Visual
Studio 2010 et Eclipse 3.7.2. Leur conclusion montre que la complexité de ces outils n’aide
pas le monde industriel à pousser leur utilisation jusqu’à une génération de code aboutie. Ces
outils intègrent de multiples fonctionnalités mais ils ne prennent pas en compte les
particularités des plateformes spécifiques cibles. Ils peuvent réaliser différentes tâches mais
demandent l’application immédiate d’un haut niveau technique.
Cette complexité des outils et cet aspect multifonctions trop complexe ne correspondent pas
aux attentes d’un outil spécifique de génération adapté à un métier. Nous nous sommes alors
orientés vers un environnement progiciel dédié à la génération de code à partir d’une
approche DSM à base de méta-modèle et de templates.
71
2.3.5 Solutions DSM pour les automatismes industriels
De manière générale, la génération de code et de documents intéresse les entreprises, les

banques et les administrations et des solutions industrielles existent. Le problème dans notre
cas est de trouver un outil adapté au métier EALE qui respecte le périmètre de notre projet de
recherche : les études de contrôle/commande des EALE.
Dans le domaine des sous-stations en particulier, Bentley, qui est un leader mondial, se
consacre à la fourniture de solutions logicielles complètes pour les bureaux d’études afin de
les aider à gérer leurs infrastructures. Bentley Substation V8i fournit par exemple des modèles
intelligents d'informations, une panoplie importante d'outils et des flux de travaux intégrés
pour la conception électrique et physique des sous-stations. Ce logiciel hautement productif
accélère la réalisation des projets et réduit les coûts en fournissant :
 des modèles de sous-stations qui permettent aux utilisateurs multiples de travailler
efficacement dans un seul environnement avec des données fédérées,
 un ensemble d'outils d'ingénierie et de conception de sous-station avec une interface
utilisateur commune rendant l'utilisation du logiciel facile à assimiler par la saisie
unique,
 une architecture Cloud (nuage de données) pour connecter les personnes et les
informations et faciliter la gestion des contenus d'ingénierie ainsi que la collaboration
des équipes travaillant sur le projet.
Bentley Substation fournit un outil intégrant les composants et les exigences clés d'une sous-
station électrique :
 les schémas d'installation,
 les schémas électriques pour la protection et le contrôle/commande,
 le réseau de mise à la terre, la protection contre la foudre,
 le bâtiment (guérite) de contrôle et la conception de l'éclairage.
En outre, ce logiciel est compatible avec les solutions de Bentley d'ingénierie civile pour la
conception architecturale et pour la modélisation des bâtiments. Bentley Substation V8i
associe les capacités de conception électrique à une modélisation 3D complète. Les outils de
conception électrique fournissent une capacité de dessin et une génération automatisée des
rapports pour créer rapidement et facilement des schémas électriques, des plans de câblage.
La modélisation 3D, associée à l'organisation intégrée du réseau de mise à la terre et aux
algorithmes de câblage, donne aux utilisateurs les moyens d'optimiser l'organisation des sites
de sous-station et de minimiser les problèmes sur site en résolvant au début du cycle de vie du
72
projet les problèmes associés aux espaces libres, aux interférences et les autres problèmes
potentiels de construction.
En remplaçant la conception assistée par ordinateur (CAO) 2D traditionnelle, les flux de
travaux sur papier et les collections disparates de logiciels, par des outils 2D et 3D avancés
intégrés dans Bentley Substation, les équipes projet peuvent réduire la durée de conception
des systèmes électriques de sous-station.
Malheureusement cet outil dépasse notre périmètre d’action. Sa mise en œuvre nécessiterait
de modifier complètement les processus établis au sein de l’ensemble du département
PROJETS SYSTEME INGENIERIE de Traction Electrique (PSIGT-TE). Cet outil intègre
des modèles déjà existants, il faudrait alors que les chargés d’études s’adaptent à l’outil. Ce
qui ne correspond pas à la philosophie que nous souhaitons suivre.
Dans le domaine des sous-stations, la norme (IEC 61850, 2010) définit les standards de
communication. L’IEC 61850 a le potentiel de réduire de manière significative les coûts de la
planification, et peut permettre de configurer et d’améliorer le système d'automatisation de la
sous-station par la suite. L’expérience du terrain semble montrer que l'utilisation du format de
fichier standard (IEC 61850-6, 2010) : Substation Configuration Language (SCL) et de la
capacité d'auto-description du protocole peut réduire le temps requis pour installer le
dispositif de protection qui est une partie de la sous-station de 75% ou plus. Cependant il
existe encore peu d’outils intégrant les standards et les caractéristiques de description de la
norme IEC 61850. En effet, la mise en œuvre de l’IEC 61850 nécessite un matériel approprié
compatible mais également un outil de configuration logiciel adapté. Le développement des
produits compatibles IEC 61850 a suivi un modèle assez simple, les premiers équipements
étaient dédiés à une fonction particulière et développés pour être compatibles avec les
standards, comme par exemple les relais de protection. Les premiers outils de configuration
développés ont donc seulement dû prendre en compte quelques options des équipements
compatibles pour établir un modèle objet complet de la norme IEC 61850. L'utilisateur peut
choisir, par exemple, quels paramètres de protections à activer. L'outil de configuration
exploite ces quelques modifications pour établir automatiquement l'ensemble de données que
le dispositif produit sur le réseau. Au début, la vue de certains équipements compatibles IEC
61850 était fixe, sans options à spécifier. Avant de pouvoir utiliser la norme IEC 61850, il
faudra donc commencer par l’enrichir pour que le modèle objet considère toutes les options
possibles des équipements des EALE.
73
Une telle approche fonctionne très bien pour un appareil électronique intelligent spécialisé
(Intelligent Electronic Device - IED), mais pas aussi bien pour des dispositifs devant être plus
flexibles. Les dispositifs tels que les interfaces utilisateurs de sous-station, les convertisseurs
de protocole (RTU), les API doivent agir en tant que clients de l’IEC 61850, recueillant des
données de dizaines d'appareils électroniques intelligents (IEDs). Ils doivent lire les données
et les écrire dans leurs bases de données internes ; ils peuvent afficher les données ou les
traiter avant de les transmettre. Le nombre de type d’IED varie considérablement dans une
sous-station. Tandis que la norme IEC 61850 normalise comment les données devraient être
appelées et structurées, les spécifications de la norme concernant les appareils laissent la plus
grande liberté aux fournisseurs. Ainsi ils peuvent ajouter ou enlever des options de certains
appareils. Le nombre d’options n’étant pas limité, cela complexifie davantage la description
de l’installation.
L’idée intéressante de la norme IEC 61850 qui consiste à décrire la sous-station à partir des
équipements qui la compose correspond tout à fait à ce que nous souhaitons obtenir. La
structuration définie par la norme IEC 61850 ne correspond cependant pas à nos attentes par
rapport à l’aspect distribué du système de contrôle/commande. De plus, aujourd’hui les
équipements utilisés par la SNCF ne sont pas compatible avec cette norme. L’intégration des
standards IEC 61850 dans notre projet de recherche aurait pu être une piste intéressante mais
n’est pas envisageable dans l’état actuel des EALE.
Dans le secteur ferroviaire, Esterel Technologie a mis au point une méthode nommé SCADE
(Safety-Critical Application Development Environment). Cette méthode consiste à générer
automatiquement le code d’une application à partir d’un modèle formellement vérifié. Ainsi
les erreurs sont détectées au plus tôt. Le langage SCADE est graphique, ce qui permet à tous
les acteurs du projet de comprendre le sens du diagramme qui doit correspondre à leur métier.
Le langage SCADE inclut les flux de données et les machines à états. Le logiciel intègre des
vérifications sémantiques et syntaxiques des codes définis pour éviter les erreurs de
programmation. Mais surtout, lorsque le modèle est complet, SCADE permet de définir des
propriétés à respecter par le modèle. Il est alors possible de simuler le fonctionnement du
système, SCADE garantit que les résultats de la simulation du modèle sont identiques à ceux
qui seront obtenus plus tard par le code généré à partir du modèle sur la cible.
SCADE propose également de vérifier formellement par model-checking que les propriétés du
système sont respectées.
74
La démarche SCADE permet de générer du code sûr de fonctionnement et certifié SIL (Safety
Integrity Level) 3/4 de l’(EN 50128, 2012) pour le secteur ferroviaire, comme nous le
souhaitons à partir d’une modélisation graphique du système. Néanmoins, SCADE ne génère
que du code C, qui peut être implémenté dans certains API, mais pas dans tous. Surtout, le
code généré ne correspondrait pas aux attentes de la SNCF pour les programmes de
contrôle/commande des EALE, étant donné qu’ils souhaitent conserver la lisibilité actuelle
des programmes séquentiels et des programmes à contacts. L’approche SCADE révèle
également le besoin de vérifier formellement que la commande implémentée est sûre de
fonctionnement. La méthode SCALE ne sépare pas la partie fonctionnelle de la partie
sécuritaire de la commande, pourtant cette séparation parait tout à fait adaptée à la vision
objet de la méthode SCALE. Nous nous intéresserons à ces problématiques au travers du
deuxième axe d’amélioration.
Dans le domaine de l’automatisation, des sociétés comme Siemens avec Comos et Schneider
Electric avec Unity Application Generator (UAG), proposent des environnements dédiés à la
description d’un métier spécifique pouvant mener à la génération du code spécifique à leur
plateforme de programmation automate respective (TIA, Unity Pro XL, …). Les
cloisonnements qui existent entre les différents fournisseurs d’Automates Programmables
Industriels (API) sont des barrières à la mise en place d’outils pérennes dans le temps pour
une entreprise comme la SNCF. En effet le changement de type d’API (Automate
Programmable Industriel) lors d’un appel d’offre mettrait en péril les choix stratégiques ciblés
envers un seul fournisseur. Des standards comme PLCopen (http://www.plcopen.org) (Van
der Wal, 2009) visent une uniformisation des formats des fichiers de programmation d'API
(Programmable Logic Controller : PLC en anglais), sous la forme de fichiers XML. Plusieurs
groupes de travail ont été créés par cette organisation mondiale pour promouvoir les standards
définis dans la norme (IEC 61131-3, 2003) sur la structure des applications, les langages de
programmation, les adresses d’entrées/sorties, etc. Chaque groupe travaille sur la
standardisation d’un aspect de la programmation. Ainsi le groupe TC6 (Technical Committee)
de PLCopen tente de concevoir un schéma XSLT définissant la grammaire du langage XML
compatible avec l’ensemble des fournisseurs d’API. D’autres groupes sont en charge de
définir des niveaux de conformité ou de réutilisabilité de blocs fonctionnels. Le groupe 3 tente
de définir des blocs fonctionnels standards pour les systèmes manufacturiers et notamment
pour les systèmes motorisés. La standardisation est donc dans l’air du temps et il est
préférable de ne pas restreindre les possibilités de l’outil qui sera choisi par rapport au
75
matériel. C’est pourquoi une solution indépendante de tout fournisseur est préférable. Des
sociétés françaises comme ITRIS AUTOMATION SQUARE (PLC Converter, PLC DocGen)
ou PROSYST (ODIL) proposent ce type de solution. ODIL (Outils Descriptifs d’ILots),
contrairement aux outils logiciels de ITRIS AUTOMATION SQUARE, est une solution
« tout en un » qui encapsule, déploie et maintient les standards généraux de conception et les
standards organiques des métiers, pour rationaliser et garantir la conformité des études.
L'application est créée à partir des standards métiers afin de générer la documentation projet
(analyse fonctionnelle, manuels opérateurs), les schémas électriques, les programmes API, les
applications IHM, le modèle de simulation, etc. Pour ce faire, ODIL doit être adapté pour
chaque métier qui l’utilise. Visual Standard permet de modéliser et de définir l’architecture
d’ODIL et du métier spécifique. L’approche ODIL est fondée sur la modélisation du domaine
spécifique (Domain Specific Modeling – DSM). Comme cela a été montré dans la première
partie de ce chapitre, le DSM apporte une vision différente de l’utilisation du MDA. Tout en
conservant les méthodes de méta-modèle et templates, le DSM est une philosophie de
conception qui met le métier cible au cœur du modèle. Le DSM élève le niveau de
l'abstraction au-delà de la programmation, en spécifiant la solution directement à partir des
concepts de domaine. Les produits finis sont générés à partir de ces caractéristiques de haut
niveau. Cette abstraction est possible parce que le langage spécifique métier est spécifique à
l’entreprise et le générateur est spécifique au domaine métier.
2.3.6 Présentation de la solution Odil de la société Prosyst
Prosyst est une entreprise mûre, âgée de plus de 25 ans, fondée par des docteurs de
l’Université de Valenciennes désireux d’industrialiser leur solution de diagnostic pour les
automates. Ils ont développé des solutions d’automatisation pour l’ensemble du cycle de vie
d’un projet. De la génération de code et de livrable grâce à Odil, à l’aide au diagnostic et à
l’enregistrement d’événements précis jusqu’à la milliseconde, pour la vie du système
(Aidiag), en passant par la simulation de partie opérative pour tester les programmes générés
(SIMAC).
Odil a été développé il y a dix ans et n’a cessé d’évoluer depuis. A l’origine le logiciel a été
développé pour Renault dans le but de générer leurs cahiers de recette. Les possibilités d’Odil
ont ensuite montré la capacité de générer les programmes dans le cadre d’une standardisation
au niveau mondial. PSA, Michelin, Bombardier sont également clients de cette solution pour
76
l’industrie et la performance de production. Odil est aussi utilisé par Schneider Electric dans
le cadre des parcs photovoltaïques et par Areva dans le retraitement des déchets nucléaires.
Ces deux derniers domaines sont contraints par des normes de sécurité.
2.3.6.1 La solution Odil
Odil est un environnement logiciel pour les bureaux d’étude, sur un principe de « saisie
unique ». Chaque déclaration est propagée dans tous les points de vue et livrables du projet.
Odil accompagne l’étude des projets en suivant les étapes du « workflow » du projet.
L’objectif de l’intégration d’Odil dans notre démarche est de pouvoir générer le code des
applications API à partir d’une description graphique. Les chargés d’études décrivent le
schéma unifilaire de l’installation étudiée et définissent les propriétés des objets de
l’installation décrite.
Odil inclut une structure de données autonome, exploitée par le cœur d’Odil, contenant les
standards (templates) de conception et la personnalisation de l’environnement Odil. Cette
structure est développée et maintenue par les responsables Méthodes, à l’aide d’un éditeur
spécialisé : VISUAL Standard.
2.3.6.2 Visual Standard : Solution de développement du Progiciel SNCF EALE
Visual Standard permet de définir et d’adapter le comportement d’Odil aux besoins du

domaine spécifique (). Le progiciel intègre plusieurs éléments permettant de définir le métier.
Il permet également de définir l’interface sur laquelle les chargés d’études décriront
l’installation. Il est en effet possible de définir des vues spécifiques du métier.
Visual Standard définit la structure de la base de données Odil :
 tous les objets manipulés lors de l’étude automatisme,

 leurs propriétés et les valeurs par défaut,
 toutes leurs relations (parents-fils, association, cardinalité …).
77
Il définit les « métiers », ou « points de vue » différents d’une étude d’automatismes :
 Structurer l’interface Odil pour chacun des « points de vue » : vue Visio, Word,
éditeurs spécialisés, pour que l’Interface Homme Machine (IHM) soit agréable à
utiliser par les chargés d’études et qu’elle corresponde à leur langage.
 Définir la constitution des fichiers d’export pour chacun des livrables générés par
Odil, au travers des templates.
Visual Standard permet de construire le modèle de données autonome qui, intégré dans Odil,
personnalise l’environnement d’édition.
Figure 24 : Schématisation de la structure Progiciel d’Odil
La solution Odil offre une robustesse et une garantie de stabilité de l’environnement de

travail. Son architecture intégrant le progiciel SNCF permet une grande flexibilité par rapport
aux besoins d’évolutivités, de maintenabilité.
La réalisation du standard est appréhendable, ce qui rend possible la prise en main, à terme, de
Visual Standard pour faire évoluer l’ensemble du Progiciel au sein de la section CES2. La
génération des livrables et programmes se fait à partir de requêtes sur la base de données,
interprétées dans les templates de génération. Cette solution de génération s’intègre
parfaitement dans la démarche de génération d’un code de qualité pour les systèmes distribués
et reconfigurables. Odil intègre une vérification de la cohérence des données lors de la
78
réalisation d’un projet, ainsi il est impossible d’exporter les livrables tant que le projet ne
respecte pas les contraintes établies pour un projet.
De plus, la solution Odil s’intègre totalement dans l’approche Domain Specific Modeling que
nous préconisons. Le but est bien de décrire un langage métier qui corresponde au vocabulaire
des chargés d’études et de définir une interface graphique où celui-ci pourra modéliser son
système à partir d’éléments qu’il connaît. La modélisation objet réalisée est intégrée dans le
Standard et permet de récupérer toutes les informations des objets du système pour générer
correctement le code à partir des templates établis. Cette solution nous permet de générer un
code lisible pour les chargés d’études qui correspond à 100% au code qu’ils connaissent.
L’intégration du savoir-faire proposé par Prosyst au sein de notre démarche de génération

d’un code de qualité permet d’aller plus loin dans la génération des programmes et des
livrables. Cette solution est également plus viable sur le long terme en s’appuyant sur un
noyau maintenu par une entreprise assurant la maintenance évolutive et garantissant la
pérennité du savoir-faire au travers de la formation possible des agents.
A long terme, l’indépendance de cette société par rapport aux fournisseurs d’API est un atout
pérenne puisque quel que soit l’interface de programmation de l’application (IPA) du futur
API, les standards pourront être adaptés pour générer le code de n’importe quel atelier logiciel
(PL7 PRO, Unity Pro, STEP7, ISaGRAF, Straton…). Ainsi nous ne sommes pas dépendants
d’un fournisseur d’API et la solution peut évoluer de manière indépendante.
2.3.7 Synthèse
La génération automatique de livrables a été présentée au travers des philosophies, méthodes

et techniques utilisées pour la génération de codes informatiques. La philosophie du MDA a
été opposée à celle du DSM. Les méthodes et techniques permettant de passer d’un modèle à
la génération du code ont été expliquées et comparées. Enfin, les solutions industrielles
existantes ont été présentées. Toutefois, comme nous l’avons déjà signalé, la génération de
code API n’est qu’une brique parmi d’autres dans un projet d’automatisation des EALE.
L’approche DSM proposée par la société PROSYST au travers de la solution ODIL nous
semble très prometteuse. En effet, indépendance vis-à-vis de la cible automate, génération du
code API mais pas seulement, sont clairement des points qui jouent en faveur de ce logiciel.
79
Toutefois, générer du code API est une chose, encore faut-il que celui-ci soit de qualité et
standardisé. Sans standardisation, la génération automatique n’est pas envisageable. Le
deuxième axe d’amélioration proposé concerne donc la conception de la commande en vue de
générer un code API de qualité et sûr de fonctionnement.
2.4 2ème axe d’amélioration : la commande
Dans cette partie du chapitre, nous nous intéressons à la démarche de conception d’une
commande sûre de fonctionnement. La première partie de cette section s’intéresse aux
approches de conception de la commande et en particulier à la formalisation de la conception.
Trois approches de conception formelle sont explorées. Enfin la dernière partie de cette
section s’intéresse à deux concepts importants pour l’automaticien : la validation et la
vérification.
2.4.1 Approches de conception de la commande : le cas des EALE
Depuis les années 1970, l’automatisation industrielle ne cesse d’innover. Elle a fourni pendant
longtemps différents domaines de recherches, de développements et d’applications. Ce
secteur a produit ses propres méthodes de conception et langages de programmation. En
raison de son importance pour l'industrie, beaucoup de ces méthodes ont été normalisées
internationalement. Actuellement les normes les plus influentes sont les (IEC 61131-3, 2003),
(IEC 61499-2, 2000) ainsi que la norme (IEC 61850, 2010) pour le domaine des sous-stations.
Compte tenu du nombre de capteurs et d’actionneurs, il est difficile de décrire intégralement
l’espace d’état du vecteur d’entrées/sorties vu de la partie commande. Une des forces du
langage de spécification GRAFCET (IEC 60848, 2002) est de permettre une description de ce
que le système doit faire lorsqu’il est dans un état particulier. Cette approche est très
performante mais présente plusieurs inconvénients. Habituellement, les aspects sécuritaires et
fonctionnels sont mélangés. De plus, rien ne garantit que la commande réalisée soit sûre de
fonctionnement. C’est pour cette raison qu’aujourd’hui, l’utilisation de méthodes formelles de
validation et de vérification du code API est de plus en plus envisagée (EN 50126, 2012). En
effet, la complexité croissante des problèmes de contrôle, les contraintes de réduction du
temps d’élaboration, et la réutilisation possible des modules de logiciels existants ont comme
conséquence le besoin d'approches formelles dans la programmation API. Les articles de
80
(Baresi et al., 2000) et de (Antoniadis et Leopoulus, 2000) s’inscrivent principalement dans

cette direction.
De plus, la demande de solutions de haute qualité et particulièrement l'utilisation des API
dans les processus sécuritaires et critiques mènent à un besoin en procédures de vérification et
de validation, c’est-à-dire en méthodes formelles pour prouver les propriétés statiques et
dynamiques spécifiques des programmes, par exemple la vivacité ou le temps de réponse. Les
articles de (Canet et al, 2000) et de (Mertke et Menzel, 2000) traitent cet aspect de méthode
d’application formelle à la programmation des API.
La Figure 25 donne un modèle générique du processus de conception de contrôle/commande

logique (Frey & Litz, 1998) qui s’applique au cas d’étude des EALE. Cette figure est
représentée avec le formalisme « Channel Agency Net » décrit par (Reisig, 1992). Sans
utilisation des méthodes formelles le processus de conception du contrôleur comprend
seulement l'anneau externe. La réalisation du contrôleur est dérivée des spécifications
informelles par exécution directe. Elle est ensuite officiellement validée en tenant compte des
spécifications non formelles. Il s’agit donc d’une étape finale de vérification avant livraison
finale chez le client.
Figure 25 : Processus de conception pour les systèmes de contrôle/commande logique (Baresi

et al., 2000).
Généralement, le concepteur d'un système de contrôle/commande commence par écrire des
spécifications informelles (c’est-à-dire : non formelles) du problème. Dans le cas des EALE,
cette spécification informelle du système de contrôle/commande est réalisée par analogie au
moyen de programmes « exemples » d’installations à l’architecture standard. Ces derniers
81
respectent un ensemble de règles et sont globalement standardisés mais laissent une place non
négligeable au savoir-faire du chargé d’études. De plus, le fait de récupérer des « extraits »
d’études précédentes ne garantit pas que l’on ne recopie pas d’erreurs. En recopiant des
extraits, le risque est également une régression des principes mis en œuvre en récupérant une
ancienne version de programmes. Généralement les spécifications informelles se composent
d'une description du système, et des conditions normales d’exploitation. L'algorithme de
contrôle repose principalement sur l’expérience, la prise en considération des « bonnes
pratiques » indiquées par les fournisseurs d’équipements et l’utilisation de règles d’écriture
des programmes API de la SNCF. Il est important de noter que l’ensemble de ces
informations n’est pas standardisé dans un document référentiel.
Une des missions importantes attachée à cette thèse a donc été la définition de fiches
référentielles décrivant les fonctions des éléments constituants les EALE, permettant
ainsi une standardisation des spécifications et du métier de chargé d’études, nécessaire à
la génération automatique de livrables.
La méthode de validation utilisée dans le cas des EALE consiste en une phase de test du
système de contrôle/commande au moyen de fiches d’essais réalisées par les concepteurs et
les utilisateurs du système. Cette approche reste encore souvent utilisée dans l’industrie. Le
problème de cette validation est qu'elle n'est jamais complète, qu’elle est chronophage et
stressante pour les chargés d’études.
Ces dernières années, la communauté des automaticiens a réalisé le besoin de méthodes

formelles dans la validation/vérification du code API car il est fondamental de s’assurer que le
code API, et plus généralement l’ensemble des livrables, garantissent la sécurité, la fiabilité,
la disponibilité et la maintenabilité du système.
Un code API doit être correct tant sur le plan de son écriture (lisibilité, respect des règles
d’écriture, absence de code mort, …) que du respect des spécifications fonctionnelles.
Concernant ce dernier point, pour vérifier un code API existant, deux approches sont
possibles. La première consiste à réécrire le code API dans un langage interprétable par les
méthodes formelles. La seconde consiste à vérifier des propriétés directement à partir du code
API existant (Lampérière-Couffin et al., 1999).
82
Les approches pour la réinterprétation des programmes API écrits en langages normalisés par
(IEC 61131-3, 2003) (IL, LD, ST, FBD, SFC) peuvent être trouvés dans les articles suivants :
 (Mertke & Menzel, 2000) traduisent l'IL en réseaux de Petri.
 (Canet et al., 2000) utilisent un système de transition pour réinterpréter l'IL.
 (Hassapis et al., 1998) traduisent le SFC en automates hybrides.
 (Kowalewski & PreuBig, 1996) réinterprètent le SFC en systèmes orientés
condition/événement.
 (Volker & Kramer, 1999) représentent le ST, le SFC et le FBD par une logique de
d’ordre plus élevé, le SFC et le FBD étant d’abord convertis en ST avant la
réinterprétation.
 (Jimtnez-Fraustro & Rutten, 1999) emploient le langage synchrone SIGNAL pour
réinterpréter le ST.
 (Sarmento et al., 2008) transcrivent les programmes SFC pour vérifier formellement
des propriétés avec le model-checker UPPAAL.
 (Fernandez Adiego et al., 2013) transcrivent les programmes ST pour vérifier
formellement des propriétés avec le model-checker NuSMV.
Le problème de cette réinterprétation du code est qu’elle vérifie a posteriori que le code
respecte les spécifications sécuritaires et fonctionnelles. L’autre technique se rapproche des
méthodes de génération automatique vues dans la première partie de ce chapitre et consiste à
transcrire les spécifications en modèles (formels ou non) et à concevoir et/ou générer une
commande sûre de fonctionnement à partir de ceux-ci. Nous avons retenu trois approches qui
semblent a priori intéressantes : la Supervisory Control Theory (SCT), la synthèse algébrique
et la commande par filtre.
83
2.4.2 La SCT (Supervisory Control Theory)
Initialement développée par P.J.G. Ramadge et W.M. Wonham en 1987, la « Supervisory

Control Theory » (SCT) appelée aussi « théorie de la supervision » est une référence dans le
domaine des Systèmes à Evénements Discrets. L’idée de base est de synthétiser un
« superviseur » qui, une fois couplé à un procédé (à prendre au sens large), impose à celui-ci
de respecter un comportement désiré. Le procédé (ou système) est considéré comme un
générateur d’événements pouvant être « contrôlables » ou « non-contrôlables »
(« uncontrollables »). Comme illustré sur la Figure 26, tous les événements sont générés par
le modèle de processus. Les événements contrôlables peuvent être inhibés par un superviseur
tandis que les événements non contrôlables sont toujours autorisés. Dans ce contexte, le
superviseur n’est pas en mesure d’imposer l’occurrence d’un événement non contrôlable mais
uniquement d’interdire l’occurrence de cet événement. (Ramadge & Wonham, 1987) fournit
un cadre mathématique formel basé sur un outil appelé « théorie des langages » pour
déterminer le comportement du superviseur. L’objectif est de sélectionner les autorisations
d’événements contrôlables permettant de respecter des contraintes liées au fonctionnement du
système automatisé. Ces contraintes décrivent les situations ne devant pas se produire au
cours du fonctionnement du système car elles correspondent à des situations dangereuses ou
non souhaitées dans le cadre d’un fonctionnement nominal.
La synthèse de contrôleurs logiques à partir de la SCT fait l’objet de nombreux travaux de la

communauté des automaticiens.
Les optimisations successives ont permis d’améliorer le concept et de résoudre certains

problèmes liés à l’explosion combinatoire ou bien encore certaines difficultés de modélisation
(Rohée & Riera, 2009). Les travaux utilisant les réseaux de Petri tels que (Holloway & Krogh,
1994), (Toguyeni et al., 2007) sont nombreux car ils permettent d’associer la synthèse avec un
outil de modélisation simple d’utilisation et limitant l’explosion combinatoire. En revanche,
les travaux liés aux applications pratiques de la synthèse de la commande des systèmes
manufacturiers sont beaucoup moins nombreux. Les travaux de synthèse de Ramadge et
Wonham sont souvent basés sur des modèles hauts niveaux utilisant le principe de « requêtes
/ réponses ». La partie opérative est vue comme un générateur d’événements dont certains
peuvent être autorisés ou non par la commande. Cette vision peut être très utile pour les
applications liées à l’ordonnancement de tâches mais ne peut pas s’appliquer sur des systèmes
84
dans lesquels les valeurs des signaux dictent en permanence le comportement de la partie
opérative. Le superviseur ne pouvant pas imposer des évolutions mais seulement en autoriser
ou en interdire certaines, des problèmes de déterminisme lorsque plusieurs évolutions
associées à des événements contrôlables ou non sont simultanément possibles. Une nouvelle
interprétation a donc été proposée pour être plus proche des problématiques rencontrées dans
l’obtention d’un modèle de commande par la théorie de supervision dans le cadre des
systèmes automatisés manufacturiers utilisant les API.
Dans (Balemi, 1992, 1993), une interprétation de la théorie de supervision pour la conception
de contrôleurs logiques de systèmes automatisés de production est proposée. Le principe
consiste à étudier les valeurs des signaux échangés entre la partie commande et la partie
opérative. La partie opérative subit les changements de signaux de la partie commande. Les
termes « commandable » et « contrôlable » sont distingués en fonction de l’interprétation
utilisée : le terme « contrôlable » est utilisé dans la synthèse de Ramadge et Wonham tandis
que le terme « commandable » est utilisé dans l’interprétation de Balemi. Le modèle de
commande reçoit de la partie opérative des événements non commandables issus des capteurs
et envoie des événements commandables que la partie opérative doit exécuter (Figure 26).
Figure 26 : interprétation de Balemi (Balemi, 1993)
Cette interprétation donne un autre sens aux modèles : le modèle de commande impose des
événements commandables au modèle de partie opérative. Les événements non
commandables correspondent aux réponses de la partie opérative à ces sollicitations. Le
modèle de partie opérative n’est plus uniquement perçu comme un générateur d’événements
spontanés pouvant être inhibés par le superviseur.
L’utilisation d’API comme applicatif nécessite de s’intéresser plus particulièrement au
problème d’implantation. Un des problèmes auquel la synthèse de la commande fait face est
le type de résultat obtenu : en effet, la synthèse ne fournit pas le modèle de comportement de
85
la commande à proprement parler mais un modèle de commande supervisée décrivant le

comportement le plus large possible du modèle de commande sous contraintes. Le modèle de
la commande supervisée inclut donc toutes les évolutions possibles ne violant pas les
contraintes. Le modèle de comportement de la commande doit donc être extrait de ce modèle
de commande supervisée.
Par conséquent, l’approche SCT est séduisante d’un point de vue théorique mais se heurte à
des difficultés lorsque l’on tente de l’appliquer à la synthèse de contrôleur pour API. D’une
part, la formalisation des spécifications sous la forme d’automates n’est pas évidente et
modifie considérablement le travail de l’automaticien de terrain. D’autre part, la SCT pose le
problème de l’explosion combinatoire car même si la complexité de la méthode évolue de
manière polynomiale par rapport au nombre d’états du système, le nombre d’état peut évoluer
de manière exponentielle par rapport au nombre de composants. Enfin, le résultat obtenu est
un superviseur et non un contrôleur. L’algorithme de synthèse permet d’obtenir la solution
optimale c’est-à-dire celle offrant la plus grande permissivité.
Même si la SCT ne peut pas être utilisée en l’état pour résoudre le problème pratique de la
génération de code API sûr de fonctionnement pour les EALE, l’idée de base d’un
superviseur inhibant ou non les événements contrôlables nous semble très séduisante et sera
d’ailleurs exploitée dans la suite de ce mémoire.
Contrairement à la SCT, la deuxième approche de synthèse présentée est algébrique et permet

d’obtenir une loi de commande facilement programmable dans un API.
2.4.3 La synthèse algébrique
Les travaux conduits au LURPA de l’ENS Cachan entre autres par Hietter (2009) dans le
domaine de la synthèse sont originaux et séduisants. Les chercheurs ont apporté une réponse
algébrique au problème de la conception d’un contrôleur. L’objectif est de donner à
l’automaticien les moyens d’obtenir automatiquement les lois de commande à implanter dans
l’API à partir des fragments de spécification dont il dispose. La méthode proposée utilise un
cadre mathématique rigoureux (Hietter, 2009) : l’algèbre de Boole des fonctions booléennes,
et repose sur 4 étapes (Figure 27) :
86
- 1) la formalisation des fragments de la spécification sous la forme de relations entre

des fonctions booléennes permettant ainsi d’exprimer de manière non ambiguë tous
les fragments de spécification à la disposition du concepteur,
- 2) la vérification automatique de la cohérence des fragments de la spécification à partir
d’une analyse du système d’équations entre les fonctions booléennes. Cette étape
permet de s’assurer qu’il existe au moins une solution au problème de commande,
- 3) la résolution du système d’équations et la proposition sous forme algébrique
paramétrique de l’ensemble des solutions,
- 4) Le choix d’une solution par le concepteur. Cette étape lui permet de choisir une
solution optimale en fonction de ses propres critères (temps de réponse par exemple).
Dans la méthode initiale, ce travail est laissé à la charge de l’automaticien.
Figure 27 : Les quatre étapes de la méthode (Hietter, 2009)

La contribution théorique majeure du travail de Hietter (2009) concerne la résolution de
systèmes d’équations à n inconnues sur des algèbres de Boole et le théorème suivant :
Théorème 10 : Soit ( ̅ ) une algèbre de Boole. Soient ( ) et (

)( ) éléments de . Considérons l’équation suivante où les éléments sont
inconnus :
( )
Cette équation admet des solutions si et seulement si :
87
∏ ( )
Où est l’ensemble des n-uplets où chaque composante est l’un des éléments
particulier 0 et 1.
( )
Lorsque cette condition est respectée, cette équation admet un ou plusieurs n-uplets solutions
( ( ) ( )) où chaque composante peut être décrite à l’aide de la forme paramétrique
suivante :
( ) ∏ ( )
̅̅̅̅̅̅̅̅̅̅̅̅̅̅̅̅̅̅̅̅̅̅̅̅̅̅̅̅̅̅̅̅̅̅̅̅̅̅̅̅̅̅̅̅̅̅̅̅̅̅̅
∏ ( )
( un élément quelconque de )
où
( ) ( ) ( )
Appliqué à l’ordre 1, c’est-à-dire avec une seule inconnue, ce théorème permet d’écrire le
théorème suivant (Hietter, 2009) :
Théorème 8 : Soit ( ̅ ) une algèbre de Boole. Soient et trois éléments de

cette algèbre. Considérons l’équation suivante où les éléments est l’inconnue :
Cette équation admet des solutions si et seulement si :
88
Lorsque cette condition est respectée, cette équation admet une ou plusieurs solutions que la
forme paramétrique suivante permet de décrire :
où est un paramètre, élément de .
L’ensemble des solutions de l’équation peut également être décrit à l’aide de l’une de ces
deux formes équivalentes :
̅ ( )
̅ ̅
L’approche de synthèse algébrique présente de nombreux avantages parmi lesquels

l’obtention automatique de la loi de commande et par là même, éventuellement la génération
automatique du code API. Toutefois, cette méthode présente également des inconvénients
majeurs dans le cadre de notre application. D’une part, la méthode modifie considérablement
le travail du chargé d’études (formalisation des fragments de spécification, choix de la
solution parmi l’ensemble des solutions possibles, …) et la solution finale obtenue, sous la
forme d’un ensemble de fonctions logiques est très différente des standards de développement
de la SNCF et difficilement interprétable par les chargés d’études. L’approche de
l’automatique « humaine » nous impose d’en tenir compte dans le choix de la solution
retenue. De plus, rien ne garantit que la solution finale retenue soit sûre de fonctionnement car
elle dépend uniquement des fragments de spécification qui peuvent être l’objet d’erreurs de
formalisation. Toutefois, la résolution de systèmes d’équations à n inconnues sur des algèbres
de Boole est un résultat majeur qui sera exploité dans cette thèse.
La troisième et dernière approche de commande présentée dans ce mémoire repose sur des
travaux menés depuis 2006 au Centre de Recherche en STIC de l’Université de Reims
Champagne-Ardenne.
89
2.4.4 La commande par contraintes logiques
Cette approche repose initialement sur la surveillance de la commande au moyen d’un filtre
qui constitue un bloc de validation entre la PC et la PO (Figure 28). Cette approche (Lhoste,
1994 ; Alanche et al., 1986 ; Cruette 1991 ; El-Khattabi, 1993 ; Toguyeni, 1992) n’est pas
récente et a été remise d’actualités au travers la thèse de P. Marangé (Marangé, 2008) :
« synthèse et filtrage robuste de la commande pour des systèmes manufacturiers sûrs de
fonctionnement ».
Figure 28 : Approches par filtre (à compléter avec les E/S)

L’idée consiste à écrire les spécifications de sécurité au moyen de contraintes représentées
sous la forme d’un monôme logique (fonction booléenne) pouvant impliquer une ou plusieurs
sorties. L’ensemble de contraintes obtenues caractérise le filtre de sécurité. A chaque cycle
API, toutes les contraintes doivent être fausses pour garantir la sécurité de la Partie Opérative
(PO). L’originalité de la démarche repose sur une vérification hors ligne du filtre au moyen
d’un model-checker (Figure 29). En d’autres termes, une fois le filtre vérifié, la sécurité est
garantie indépendamment des spécifications fonctionnelles, et donc quel que soit le
programme implanté dans l’API.
90
Figure 29 : Démarche de vérification des contraintes (Marangé, 2008)

La démarche de vérification formelle hors ligne des contraintes permet de garantir la
robustesse du filtre aux erreurs de commande et s’appuie sur :
1. L’ensemble des positions et situations dangereuses de la PO qui est déterminé à partir
d’une analyse fonctionnelle et dysfonctionnelle du système. L’ensemble des propriétés
formelles est déduit des positions et situations interdites de la PO.
2. L’ensemble de contraintes est défini par un expert en vue d’interdire les positions et
situations dangereuses de la PO.
3. Les propriétés formelles sont vérifiées au moyen du model-checker UPPAAL
(Behrmann et al., 2002), sur le modèle de PO en interaction avec le modèle d’API. Le
modèle d’API correspond au fonctionnement cyclique (lecture des Entrées, calcul de
la commande la plus permissive, calcul des contraintes de sécurité et écriture des
Sorties). Si une contrainte est violée, la PO est mise en sécurité.
4. Si les propriétés sont satisfaites, cela signifie que l’ensemble de contraintes de sécurité
est suffisant pour garantir qu’aucune position ou situation dangereuse ne sera atteinte.
Dans ce cas, l’ensemble de contraintes a été validée et elles peuvent être implémentées
91
dans l’API. Sinon, il faut modifier l’ensemble de contraintes et refaire la vérification

des propriétés jusqu’à ce qu’elles soient satisfaites (étape 3).
P. Marangé a utilisé le model-checker UPPAAL pour vérifier que l’ensemble des contraintes
proposées par l’expert est suffisant et nécessaire pour garantir que la PO (actionneurs et
produit) n’atteint jamais, quelle que soit la commande envoyée, des états interdits.
L’originalité de la démarche est de s’assurer que, grâce aux contraintes, et en considérant la
commande la plus permissive possible, il n’existe pas de chemins menant la PO dans une
situation de danger. En d’autres termes, on ne cherche pas à vérifier qu’une commande
particulière répond à un cahier des charges et est sûr de fonctionnement, mais on cherche à
vérifier qu’un ensemble de contraintes est suffisant pour garantir la sécurité indépendamment
du cahier des charges et de la commande. Si la propriété « aucun état dangereux n’est atteint »
n’est pas vérifiée, cela signifie que l’ensemble des contraintes n’est pas suffisant, il convient
donc de revoir et de modifier la liste.
L’ensemble des contraintes vérifié formellement permet donc d’obtenir et de valider un filtre
robuste aux erreurs de commande suffisant pour garantir la sécurité du système. De plus,
chaque contrainte est une source d’informations. Quand une ou plusieurs d’entre elles ne sont
pas respectées par le programme de commande, cela signifie qu’il existe au moins un chemin,
que le model-checker peut fournir, conduisant la PO dans une situation dangereuse. La
connaissance du ou des chemins permet de fournir une explication à l’opérateur. Étant donné
que l’ensemble de contraintes est uniquement caractéristique et dépendant de la PO, le filtre
reste valable même s’il y a des changements dans le programme de commande. Il s’agit là
d’une propriété intéressante car il y a une séparation entre les aspects fonctionnels et
sécuritaires. Dans la méthode initiale, en cas de violation d’une contrainte, la PO se replie
dans un état sûr pré défini.
Cette approche nécessite de modéliser la PO, le fonctionnement de l’API, les contraintes et les
propriétés à vérifier. Ce dernier point est souvent problématique car une des difficultés du
model-checking est que les propriétés ne sont pas toujours évidentes à formaliser. Cela n’est
pas le cas dans l’approche proposée. La propriété correspond à une ou plusieurs positions
physiques des actionneurs et/ou des pièces et est donc simple à écrire.
92
Initialement le filtre avait été prévu pour stopper la commande en bloquant les actionneurs
dans un état de sécurité et empêcher ainsi l’évolution de la PO. Cette approche a été étendue
pour faire de la commande sûre de fonctionnement (Benlorhfar et al., 2011). L’idée consiste
en cas de violation d’une contrainte de sécurité à interdire le ou les ordres erronés de
commande uniquement pour le cycle API en cours. Ainsi, à la façon de la SCT, le filtre
autorise ou inhibe les événements commandables. Cette approche présente des avantages. Il
devient possible de séparer structurellement les parties « sécuritaire » et « fonctionnelle »
dans le contrôleur. Cela peut éventuellement permettre une simplification de la loi de
commande mais change radicalement la façon de travailler des automaticiens. Toutefois, cette
méthode peut également être utilisée pour sécuriser des programmes existants. Cette approche
(Figure 30) peut donc ne pas modifier considérablement la façon de concevoir la commande
et n’implique pas forcément des changements majeurs de méthodes de travail des chargés
d’études. Ce point est fondamental comme cela a été montré dans la première partie de ce
chapitre consacrée aux Systèmes Hommes-Machine.
Figure 30 : Sécurisation de la commande avant l’implémentation
93
Cette approche semble très prometteuse et adaptée à la problématique des EALE et au travail
des chargés d’études. Nous l’avons étendue et développée dans le cadre de ce travail de thèse
(cf. chapitre 4). En effet, en plus de garantir formellement la sécurité, elle est adaptée à des
programmes API existants.
2.4.5 Validation et Vérification : V&V
La norme (ISO 9000, 2005) propose les définitions suivantes. La validation est la «
confirmation par des preuves tangibles que les exigences pour une utilisation spécifique ou
une application prévues ont été satisfaites ». Le terme « validé » désigne l’état correspondant
et les conditions d’utilisation peuvent être réelles ou simulées. Valider, c’est donc répondre à
la question : « Faisons-nous le bon produit ? ». En revanche, la vérification, c’est la
« confirmation par des preuves tangibles que les exigences spécifiées ont été satisfaites ». Le
terme « vérifié » désigne l’état correspondant. La confirmation peut couvrir des activités telles
que la réalisation d’autres calculs, la comparaison d’une spécification de conception nouvelle
avec une spécification de conception similaire éprouvée, la réalisation d’essais et de
démonstrations, la revue des documents avant diffusion. En conception et développement, la
vérification concerne le processus d'examen du résultat d'une activité en vue de déterminer la
conformité aux exigences requises fixées pour ladite activité. Vérifier, c’est donc répondre à
la question : « Faisons-nous le produit correctement ? ».
C’est le point de vue de l’Association Française de NORmalisation (AFNOR) qui considère
que la vérification concerne essentiellement les contrôles en cours, et la validation, les
contrôles avant livraison. Validation et vérification concernent aussi bien les activités de
production que les activités de conception. Lorsque l'on produit un objet à travers une suite
chronologique d'opérations, il est possible d'effectuer des vérifications de conformité au cours
de chacune des phases du procédé de production. Cela permet d'éviter de constater une
anomalie grave en fin de procédé alors que celles-ci auraient pu être détectées lors des
opérations précédentes. Ensuite, lorsque l'objet est prêt à être livré au client, une dernière
vérification peut être réalisée (contrôle de fin de fabrication).
Pour les activités de conception, il est possible de la même manière d'effectuer des contrôles
au fur et mesure de la « production » de données de sortie de la conception. Une spécification,
un plan, un prototype seront vérifiés sans attendre la fin de la phase de conception. Les
vérifications se font souvent en regard des données d'entrée qui concernent l'élément produit.
Il s’agit de vérifier que l'on a bien tenu compte de toutes les informations et de tous les
94
paramètres entrants qui ont été bien identifiés et analysés au préalable. Les vérifications
peuvent être opérées soit par les personnes qui produisent les données de sortie à contrôler
soit par un groupe lors de revues de projets. Les vérifications peuvent bien entendu se
rapporter à des travaux internes (qui ne constituent pas de données de sortie) comme par
exemple des notes de calcul. Il est souhaitable que ces vérifications soient planifiées lors du
début des travaux ou lors de revues (par exemple au fur et à mesure de l'avancement de la
conception) et que les résultats des contrôles soient enregistrés.
La validation est donc une vérification finale de la performance de la conception. Elle
consiste, comme tout contrôle final, à vérifier que les exigences définies en début de
conception (et qui tiennent compte des évolutions possibles), c'est-à-dire : celles contenues
dans le cahier des charges, sont satisfaites. Ces exigences peuvent naturellement être des
éléments impactant la performance du produit. La validation peut être effectuée tout ou partie
chez un client pour simuler les conditions réelles de production des performances requises. La
validation ne peut pas être de la responsabilité du client. Dans une approche « client-
fournisseur », on comprend que ces deux notions puissent se recouvrir et que les outils et
méthodes soient les mêmes. Ces dernières peuvent être formelles ou non.
95
Actuellement, quatre techniques sont principalement utilisées pour vérifier et valider le

comportement d’un contrôleur :
 La simulation (ou tests) est une méthode très utilisée pour la vérification et la
validation. Particulièrement s'il y a un nombre important de signaux d'Entrées/Sorties
(E/S), la simulation est très chronophage puisque chaque situation possible doit être
vérifiée. Par conséquent, dans la plupart des cas, la simulation est limitée à
l’application directe des signaux d’entrées en fonction des signaux de sorties
déterminés par les spécifications. Dans ce cas, le comportement du processus, c’est-à-
dire sa réaction aux signaux d'entrées, est négligé et - plus critique, - seules certaines
parties du contrôleur sont examinées.
 Analyse d’atteignabilité: Les méthodes basées sur l'analyse d’atteignabilité
établissent l'espace d’états complet du système modélisé et vérifient les propriétés en
étudiant la structure et les composants de cet espace d’états (Kowalewski et al., 1996).
Le problème avec l'analyse d’atteignabilité est l'explosion du nombre d'états pour les
systèmes discrets comme les EALE : Le nombre d'états dans le système augmente
exponentiellement avec le nombre de variables discrètes.
 « Model-checking » : En model-checking, des caractéristiques du comportement du
système, appelées « propriétés », sont vérifiées automatiquement sur un modèle fini du
système. Les caractéristiques sont formulées en logique temporelle (Alur &
Henzinger, 1992) et (Henzinger, 1998). Le modèle est formalisé en utilisant des outils
comme les automates à états ou les réseaux de Petri par exemple. Le model-checking
n'évite pas le problème de l'explosion d'états si les propriétés à vérifier nécessitent de
modéliser l’intégralité des états du système complexe. Néanmoins, cette solution est
adaptée aux systèmes structurés dont les éléments ont un nombre d’associations limité
avec les éléments extérieurs.
 « Theorem proving » : Dans les méthodes par theorem proving, le système et ses
propriétés attendues sont formalisés en utilisant la logique mathématique. Les
formules de propriété doivent être rendues résistantes aux axiomes de la description de
système utilisant quelques règles d'interférence. Le theorem proving aide l'utilisateur
en formulant la preuve. Les approches utilisant le « raisonnement machine » peuvent
éviter l’inconvénient d'avoir besoin d'un utilisateur fortement qualifié. Un grand
avantage de cette méthode en revanche est qu’elle évite le problème de l’explosion
combinatoire (Shankar, 2000).
96
2.5 Conclusion
Ce chapitre a permis d’introduire deux voies d’amélioration du travail des chargés d’études et
de la qualité des livrables. La commande des EALE doit être sûre de fonctionnement pour
répondre aux exigences sécuritaires du domaine ferroviaire. Actuellement, un projet est
réalisé en s’inspirant des études précédentes existantes et est validé en usine et sur site au
moyen de fiche d’essais. Nous avons montré que des outils évolués de conception
d’automatismes existent mais ne sont pas à ce jour utilisés à la SNCF. Ils permettent entre
autres la génération automatique de livrables et de codes. Ces outils doivent être adaptés au
workflow du domaine spécifique pour répondre aux besoins du métier. C’est pourquoi
l’approche DSM semble la plus pertinente dans notre cas. Par la mise en place d’outils
évolués, il est ainsi possible d’améliorer les conditions de travail des chargés d’études, la
productivité et la sécurité. En effet, la génération de code API et de livrables permet d’éviter
les tâches répétitives, améliore le processus et les méthodes projet en focalisant l’attention des
acteurs sur les tâches importantes. La mise en place de la génération dans un premier temps,
permet d’assurer la non-régression des programmes et est un premier pas vers leur
fiabilisation en utilisant des templates de programmes déjà exploités dont le retour
d’expérience (REX) assure leur fiabilité. Des outils tels qu’ODIL de la société PROSYST
semblent répondre à nos besoins en terme de lisibilité, maintenabilité et conservation des
règles d’écriture des programmes par l’utilisation de « templates » basés sur les livrables
actuellement réalisés par les chargés d’études. En effet, il nous semble important de s’orienter
vers des solutions industrielles éprouvées que de développer une application « auteur »
difficile à maintenir et qui risque d’aboutir davantage à une preuve de concept qu’à un outil
véritablement utilisable par les chargés d’études.
Générer des livrables et le code API est une première étape, mais il est également
fondamental de garantir la sûreté de fonctionnement de la commande. L’approche de filtre
robuste aux erreurs de commande proposée par le CReSTIC est séduisante. Son extension par
la mise en place d’un algorithme de commande par contraintes formellement vérifiées hors
ligne par model-checking devrait permettre d’assurer l’objectif sécuritaire des programmes
tout en conservant la structure des programmes API existants. On notera également que le
filtrage sécuritaire de la commande doit permettre d’inhiber les erreurs de commande qui
97
pourraient provenir du Central Sous-Station (CSS) et ainsi également limiter le stress des
opérateurs de conduite des installations.
Les solutions envisagées pour les voies de progrès semblent économiquement et

techniquement prometteuses mais également adaptées au travail des chargés d’études et donc
cohérentes avec l’approche « Système Homme-Machine » (SHM). Cela devrait conduire à
des améliorations importantes en termes de conditions de travail des chargés d’études, de
productivité et de sécurité comme le montre la Figure 31. On notera toutefois qu’ils modifient
le travail des chargés d’études (en particulier le workflow des projets). Seule une étape
d’évaluation, comme cela est préconisé dans l’approche SHM, pourra apporter des éléments
de réponse sur le bien-fondé de notre approche.
Figure 31 : Deux axes de recherche pour une méthodologie d’amélioration métier à trois
composantes
La Figure 32 synthétise les deux voies de progrès que nous avons retenues dans cette thèse.
La génération automatique devrait améliorer l’intervention humaine dans la réalisation de ces
tâches. Cette solution est basée sur le principe de la saisie unique, permettant d’optimiser la
98
charge de travail. La description de l’EALE dans cet environnement logiciel unique, doit
permettre de générer tous les livrables (documents, programmes, schémas électriques…).
Cette solution logicielle doit faire partie, comme nous l’avons montré, d’un processus de
standardisation du métier.
La mise en place d’un filtre de commande à base de contraintes logiques et vérifié
formellement non bloquant doit permettre d’obtenir un contrôleur sûr de fonctionnement sans
modifier la structure des programmes API existants.
La méthodologie pour les études d’automatisation proposée intégrant ces deux voies de
progrès fait l’objet du chapitre suivant. Cette méthodologie est appliquée aux études
d’automatisation des EALE dans le chapitre 4.
Figure 32 : Application de la standardisation, de la génération automatique de livrables et du

filtre robuste de commande aux EALE
99
100
Chapitre 3 : Proposition d’une méthodologie pour les
études d’automatisation
3.1 Introduction
Le chapitre précédent a présenté un état de l’art des deux voies de progrès (ou axes de
recherche) préconisées pour améliorer les études d’automatisation des EALE : la génération
automatique de livrables et la commande sûre de fonctionnement. Nous proposons dans ce
chapitre une méthodologie originale, intégrant ces deux axes d’amélioration en vue
d’apporter, au travers du développement d’un progiciel destiné aux chargés d’études, une
réponse technique, économique et humaine aux études d’automatisation des systèmes
distribués.
La Figure 33 propose une méthodologie permettant d’aboutir à un progiciel « métier » destiné

aux chargés d’études et générant automatiquement des livrables de qualité (documents, code
API sûr de fonctionnement, …). Elle repose sur la standardisation et commence par l’étude du
métier, de ces principes et des documents et programmes existants. Au travers de ces
documents d’entrées, et par « reverse-engineering » des programmes API, il est possible de
définir des standards. Pour cela, il convient d’une part d’uniformiser les principes de
programmation et d’autre part, de s’assurer que le code API existant ne présente pas de
défaut. En effet, la génération automatique (cf. chapitre 2) repose sur la création de templates,
qui consiste à partir de règles à enrichir ou adapter des prototypes (ou exemples) prédéfinis de
code. Une étape d’analyse qualimétrique du code API existant est donc primordiale pour
valider voire améliorer les prototypes de code. Dans le chapitre 2, le standard de programmes
API, PLCopen a été présenté. Ce standard, s’il était interprétable par l’ensemble des interfaces
de programmation d’applications (IPA) serait le langage cible idéal pour la génération de code
API. Malheureusement, ce n’est pas le cas, en particulier pour la SNCF, et il est nécessaire
d’adapter les templates à l’IPA spécifique cible. C’est pourquoi une formalisation du langage
cible interprétable par l’atelier logiciel et de sa grammaire est une étape obligatoire. En effet,
générer le code source interprétable par l’IPA assure la lisibilité et la maintenabilité des
programmes API par les chargés d’études. L’analyse structurelle permet une décomposition
101
Chapitre 3 : Proposition d’une méthodologie pour les études d’automatisation
du système, et la construction de modèles de la Partie Opérative et de l’architecture de la

Partie Commande. C’est à partir de ces modèles (qui sont spécifiques à un domaine
« métier ») que nous proposons de définir les templates. La modélisation de l’architecture
matérielle de la Partie Commande est nécessaire afin d’établir les règles de distribution des
programmes dans les API. Les templates doivent être intégrés dans un environnement
progiciel avec une saisie unique des données d’entrée. Celui-ci doit permettre de générer
automatiquement les livrables, au moyen d’une Interface Homme Machine (IHM) adaptée au
langage métier des chargés d’études grâce aux modèles de PO et de PC. Une des forces de la
méthodologie est de capitaliser le fruit du savoir-faire des chargés d’études dans des templates
cohérents avec leurs méthodes de travail actuelles.
La méthodologie proposée permet également de générer une commande sûre de
fonctionnement. Celle-ci repose sur des travaux développés par le CReSTIC depuis 2008 sur
la définition d’un filtre logique à base de contraintes logiques de sécurité robuste aux erreurs
de commande (cf. chapitre 2). Actuellement, rien ne garantit formellement la sûreté de
fonctionnement des programmes API des EALE. Aujourd’hui, il n’est pas envisageable pour
des raisons de maintenabilité, d’acceptabilité et de formation de réviser en profondeur les
programmes API. L’originalité de notre approche consiste à fiabiliser les programmes API
mais sans les modifier. Pour cela, le filtre logique robuste aux erreurs de commande,
initialement bloquant, a été étendu pour en faire un contrôleur sûr de fonctionnement où les
aspects sécuritaires et fonctionnels sont clairement séparés. A partir des connaissances
acquises sur le métier et de la décomposition du système au travers de sa modélisation (PO et
PC), l’idée serait de générer automatiquement l’ensemble des contraintes de sécurité qui sont
vérifiées formellement par model-checking. On notera que des propriétés sécuritaires peuvent
être définies à partir du cahier de recette et des principes du métier. L’idée serait de créer un
template de commande à base de contraintes. Et c’est là, l’autre point fort de la méthodologie.
De cette façon, il devient possible de fiabiliser la commande « existante » obtenue
automatiquement grâce aux templates « métier ». En d’autres termes, les livrables générés
automatiquement sont très similaires à ceux produits actuellement. Il devient ainsi possible de
sécuriser la commande en conservant l’existant et donc les méthodes de développement
utilisées par les chargés d’études.
L’ensemble des étapes de la méthodologie proposée sont décrites dans ce chapitre. Cette
méthodologie, appliquée à un domaine « métier » particulier, doit aboutir au final au
développement d’un outil logiciel unique pour les chargés d’études leur permettant de générer
102
automatiquement des livrables de qualité et en particulier les programmes API sûrs de

fonctionnement. Le succès de cette démarche repose sur une gestion rigoureuse du projet de
développement de progiciel. Pour cela, le cycle de production adopté doit être adapté à la
méthodologie proposée. Le paragraphe suivant montre que la méthode Agile est, dans notre
cas, plus pertinente que la méthode en V.

livrables
103
3.2 Cycle de production de la méthodologie
Le cycle de production en V (Royce, 1970) est la méthode de gestion de projet la plus suivie
dans le monde de l’industrie. Pourtant cette méthode n’est pas la plus efficace dans tous les
cas. Pour un projet de recherche et de développement, la méthode Agile (Schwaber et al.,
2001) présente plusieurs avantages. Son point de vue incrémental est intéressant parce qu’il
permet d’avancer élément par élément puis groupe par groupe. Ainsi chaque développement
peut être testé avant de poursuivre, ce qui nous intéresse particulièrement puisque dans notre
cas, une fois que le modèle du système est implémenté, il reste à remplir les boites vides. Il
n’est cependant pas nécessaire de les remplir toutes en même temps. Cette méthode est tout à
fait adaptable aux systèmes décomposables en Sous-ensembles de Partie Opérative (SePO) et
Eléments de Partie Opérative (ElPO) qui composent les SePO.
La méthode Agile exploite le développement itératif incrémental (Figure 34). La méthode

Agile peut être représentée en incorporant la composante de temps. C’est une série de petits
cycles en V représentée par VvvvWvvvWvvvWvvvWvvvV. Le premier V est la mise en
place du projet, le dernier V est la livraison finale. Les pics durant le projet (ou W) sont des
moments spécifiques au projet (création du squelette, développement d’un groupe, essais de
versions...). Chaque itération est un mini cycle en V adapté à l'Agilité, le projet entier devient
ainsi Agile.
Figure 34 : Représentation du développement itératif incrémental
La méthode du cycle itératif incrémental (Figure 35), tente de formaliser une approche plus
pragmatique et maniable. Cette méthode se décompose en 7 étapes, dont 5 qui en constituent
le « cœur » :
104
Figure 35 : Décomposition de la méthode du cycle itératif incrémental
Pour commencer, le client exprime son besoin, dont la faisabilité est étudiée en termes de
temps et de technicité. Les informations fournies en entrée ainsi que le besoin peuvent évoluer
au cours des itérations du cycle. Une fois que le besoin est clairement défini ainsi que les
contraintes du projet, le processus itératif peut commencer :
 Spécification : à chaque itération du cycle, une partie du besoin doit être traduite en
spécification technique.
 Développement : le premier développement consiste à créer le squelette ou le noyau
de l’application. Dans les cycles suivants, il s’agit du développement d’une partie,
SePO ou ElPO.
 Vérification : l’équipe chargée du développement réalise les tests unitaires et vérifie
que ce qui est obtenu correspond aux spécifications.
 Validation: le fournisseur valide la partie réalisée en vérifiant que les fonctionnalités
développées correspondent aux besoins du client.
 Évaluation : cette étape permet un retour d’expérience à chaque itération du cycle.
Ainsi l’expérience des acteurs du projet augmente à chaque cycle et cela permet
d’éviter de réitérer les erreurs commises précédemment.
 Déploiement : les livrables qui ont été validés sont déployés pour être exploités par les
équipes en production.
La mise en place de cette démarche permet d’éviter les dérives entre le besoin exprimé et le
résultat obtenu. Les étapes de vérification et validation itérative permettent de re-corréler le
résultat avec le besoin si nécessaire et d’anticiper les futures dérives. Un retour d’expérience
105
est réalisé à chaque itération et permet aux acteurs d’apprendre et de corriger leurs erreurs
beaucoup plus rapidement qu’avec le cycle en V où les erreurs seront toutes corrigées a
posteriori.
Cette méthode permet également de redéfinir un planning réaliste régulièrement. Lors de
développements réalisés dans le cadre de projets de recherche, il est possible que des étapes
soient plus complexes à réaliser qu’initialement prévu. Dans ce cas, la divergence sera
anticipée au cycle suivant pour le développement du prochain SePO ou ElPO.
La première phase à laquelle est appliquée la méthode Agile est la phase de génération de
code API (Figure 36). La méthode Agile permet en effet de générer le code de la partie
commande étape par étape comme nous le verrons dans la section suivante. Ainsi le code
correspondant à chaque élément est vérifié avant de passer à l’élément suivant.
Figure 36 : Démarche de génération du code API
106
3.3 Reverse Engineering et données d’entrées vers la standardisation
La standardisation d’un métier nécessite de maîtriser le domaine (savoir-faire) et d’avoir une

vision globale (expert métier). Il est donc naturel que la première phase de cette démarche soit
une étude de l’ensemble des principes utilisés par le métier afin de s’approprier le savoir-faire.
La complexité de la formalisation et de la standardisation d’un métier dépend de la qualité des
données d’entrées disponibles. Certains métiers soucieux du secret industriel et de leur savoir-
faire formalisent très peu leur métier. La technique dite reverse-engineering permet d’extraire
le savoir-faire d’un métier à partir des programmes existants.
L’étude des programmes existants est également une étape importante dans la compréhension
du métier et de la philosophie du métier. Le reverse-engineering est un processus d’analyse
d’un système permettant d’obtenir des représentations de ce système à un niveau élevé
d’abstraction (Chikofsky & Cross, 1990). L’abstraction est une composante importante de la
formalisation, c’est pourquoi le reverse-engineering s’intègre initialement dans la
méthodologie proposée.
Le cahier de recette contient la liste exhaustive de tous les tests pratiqués par le fournisseur
avant la livraison du produit. Les tests unitaires, de validation et d'intégration sont considérés
comme relevant des tests de qualification en amont, au niveau du fournisseur. Cette phase
permet de vérifier que le système répond aux exigences fonctionnelles et sécuritaires. Par
retour d’expériences, après plusieurs années d’exploitation des installations, les cahiers de
recette permettent d’assurer le fonctionnement sécuritaire du système. Ils peuvent donc être
utilisés comme données d’entrée en termes de contraintes et de propriétés (sécuritaires et
fonctionnelles) auxquels doit répondre le système. Les fiches de tests du cahier de recette
contiennent les actions à réaliser et les réactions attendues. Une action et une réaction peuvent
être exprimées comme des ensembles d’états de capteurs et d’actionneurs de la partie
opérative (Entrées/Sorties de l’Automate Programmable Industriel (API)). Il est alors possible
d’exprimer ces actions et réactions sous la forme d’équations qui formeront des contraintes de
sécurité.
Les principes d’un métier regroupent le savoir-faire oral, écrit et mis en œuvre. L’expertise
métier, acquise par l’expérience, renforce le contenu, la pertinence, la régularité et la qualité
des études réalisées. L'amélioration du « métier » résulte de la recherche et développement,
des processus de formation, de la maîtrise et du perfectionnement des outils et méthodes de
travail, de l'expertise individuelle, de la communication, du partage et du retour
107
d’expériences. Ce partage écrit au travers de documents techniques, de normes ou de

référentiels décrit davantage ce que le système doit faire, mais rarement comment obtenir ce
résultat. C’est pourquoi le reverse engineering et l’étude des cahiers de recette sont des étapes
importantes de la méthodologie.
Dans l’industrie, de plus en plus d’organisations se recentrent sur les cœurs de métier. Autour
d’un responsable métier, des réunions métier sont organisées afin de capitaliser et de
mutualiser le savoir-faire individuel pour qu’il ne disparaisse pas. Ce sera d’ailleurs l’un des
intérêts de la démarche mise en œuvre puisqu’elle capitalisera l’ensemble du savoir-faire
métier.
3.4 Démarche de génération du code API
Cette section présente la partie génération de code API de la méthodologie. A partir des
programmes standardisés existants, il est possible de générer des programmes de qualité. Les
programmes actuels doivent tout d’abord subir une analyse qualimétrique. Les langages de
programmation mais également le langage métier doivent être formalisés afin de définir la
structure de la PO d’une part et de la PC d’autre part. Enfin, à partir des modèles établis de la
PO et de la PC et des programmes formalisés, des templates peuvent être définis afin de
générer le code API distribué.
3.4.1 Standardisation des programmes
Avant de vouloir générer des programmes, dans tous les cas, une étape de standardisation est
nécessaire. Des organisations telles que PLCopen (présentée dans le Chapitre 2) (Van der
Wal, 2009), mettent en avant le besoin de standardisation. PLCopen veut notamment
standardiser la structure des programmes pour qu’ils puissent être adaptés indépendamment
de la plateforme cible. C’est une première étape vers la standardisation que les programmes
doivent franchir. Mais la standardisation qui nous intéresse le plus est de plus bas niveau
puisque c’est la standardisation du code en lui-même. PLCopen sur ce problème propose
l’utilisation de bloc fonctionnel pour standardiser les programmes. Mais ces blocs
fonctionnels agissent comme des boites noires dont le fonctionnement interne devient inconnu
des utilisateurs à force d’utilisation. Dans notre cas, il est nécessaire que le comportement des
fonctions soit connu. C’est pourquoi plutôt que de révolutionner un métier en intégrant des
108
boites noires, nous préférons travailler de manière transparente en standardisant directement

les fonctions.
L’idée de cette approche de standardisation est de définir pour chaque programme ou fonction
ou « rung » de programme Ladder Diagram (LD), les entrées et les sorties possibles de cet
élément. Cette approche peut également être vue comme la définition d’un système
maximaliste prenant en compte toutes les options possibles. En ayant tous les cas de figure
répertoriés au sein d’une seule application, les templates n’ont qu’à définir les conditions
d’intégration de chaque fonction et de ses entrées/sorties.
Avant d’écrire les templates de génération de code, il faut être certain que les programmes
dont nous allons nous inspirer soient de qualité. Pour ce faire, nous proposons de réaliser une
analyse qualimétrique à partir de programmes maximalistes, reproduits à partir des
programmes existants. Ainsi, toutes les fonctions sont analysées et toutes les erreurs peuvent
être détectées.
3.4.2 Qualimétrie du code API
Pour apporter une vision objective à cette étude, une phase d’analyse des programmes et des
principes du système est nécessaire (Figure 37). Cette analyse mène la démarche de
standardisation vers la normalisation des règles de codage utilisées dans le métier. Cette
normalisation se fait à partir du savoir-faire, du retour d’expérience des chargés d’études et
grâce à l’analyse des programmes réalisée avec PLC Checker (Philippot et al., 2014). PLC
Checker est un outil d’analyse de code API développé par la société Itris Automation Square
(IAS). Cet outil analyse automatiquement les programmes automates et vérifie de façon
exhaustive leur conformité par des règles génériques décrites dans les normes se rapportant
généralement au domaine du génie logiciel, (ISO 9126, 2001) (Figure 38). Cette analyse
permet d’assurer la qualité des programmes qui serviront par la suite pour la définition des
templates.
109
Figure 37 : Méthode d’analyse des programmes
La norme ISO 9126 décrit des exigences de :

- Lisibilité (commentaires, nommage des variables)
- Fiabilité (toutes les entrées sont lues, toutes les sorties sont écrites, tous les défauts sont
évalués, toutes les sections sont présentes et dans l'ordre spécifié)
- Modularité (absence de code mort et de sous-routine non appelée, les variables sont
manipulées correctement et au bon endroit)
Figure 38 : La norme ISO 9126 définit 6 principes caractéristiques de la méthode Software

QUAlity Requirements and Evaluation (SQUARE)
110
L’utilisation de cet outil permet d’assurer le respect des règles génériques de programmation
mais également celui des règles spécifiques au métier. En effet, il est possible de définir des
règles complémentaires spécifiques afin de vérifier la cohérence et l’harmonie des
programmes.
Les corrections doivent être poursuivies jusqu’à ce que les types d’erreurs non justifiés
n’apparaissent plus dans le rapport généré par PLC Checker.
Ce processus de réécriture des programmes doit être réitéré jusqu’à ce que le rapport de PLC
Checker ne fasse plus mention des règles non justifiées. Un code de qualité est alors obtenu à
la fin de cette méthode et des règles d’écriture du langage métier ont pu être définies.
3.4.3 Analyse par PLC Checker
Ce paragraphe récapitule les règles et les informations utiles mentionnées dans les résultats
d’analyse de PLC Checker. Les règles spécifiques utilisées pour analyser les programmes API
sont expliquées. Une liste de l’ensemble des règles de PLC Checker est disponible en Annexe
1.
Tous les programmes, fonctions et variables doivent être commentés
Afin d’assurer la maintenabilité des applications :
 Chaque application doit être commentée avec :

o le nom du réalisateur,
o la date,
o le nom du projet et sa référence,
o la version,
o la description du projet.
 Chaque programme de l’application doit être :
o nommé et commenté explicitement.
 Chaque variable du dictionnaire doit être :
o nommée en respectant les règles de nommage établies,
o commentée explicitement.
 Chaque fonction appelée en langage ST doit être expliquée.
 Chaque « rung » en langage LD doit être commenté explicitement.
111
 Chaque étape et chaque transition d’un programme SFC doivent être commentées.
L’ensemble des commentaires permet de comprendre l’application. Leur homogénéité facilite

la lecture des programmes par les chargés d’études.
Toutes les variables doivent être écrites avant d’être lues

A l’exception des entrées et des variables système, toutes les variables doivent être écrites
avant d’être lues durant un cycle automate. Une variable lue avant d’être écrite a pour
conséquence de rendre le code non-réactif : un code efficace doit respecter un cycle lecture
des entrées → traitement → mise à jour des sorties. Par ailleurs, il faut s’assurer que les
variables qui ne sont jamais écrites par le code ont bien été initialisées ou proviennent de
l’extérieur du programme.
Dans certain cas, il est justifié de ne pas respecter cette règle :
 pour les variables qui ont été initialisées dans la base de données,
 pour les variables en provenance des communications,
 pour les variables d’état qui mémorisent la valeur d’un cycle antérieur.
Exemple :
if alarmeUrgente then
traitementAlarme;
end if;
# ...
alarmeUrgente := presenceDefaut AND ...;
Dans ce cas-là, compte tenu du fonctionnement séquentiel de l’API, l’appel de la routine de

traitement d’alarme se fait lors du cycle suivant, ce qui augmente le temps de réponse moyen.
Ce retard correspond à un cycle de l’API.
Une sortie physique ne doit être écrite qu’une seule fois par cycle automate
L’écriture multiple d’une sortie peut conduire à des problèmes de sécurité de fonctionnement.
Par ailleurs, un code dans lequel les sorties sont écrites plusieurs fois est moins facile à
comprendre et donc à maintenir. A noter que l’écriture dans une boucle est considérée comme
une écriture multiple et constitue donc une violation de cette règle.
Exemple :
112
if condition_tres_compliquee then
ma_sortie_critique := TRUE;
end if;
#... beaucoup plus loin dans le code
if une_autre_condition tres compliquee then
ma_sortie_critique := TRUE;
end if;
Dans le cas où cette sortie n’est pas commandée alors qu’elle le devrait, il est très difficile
d’identifier quelle affectation est exécutée.
Mesure de la complexité
Le code complexe cache des erreurs. Certaines parties de programmes sont plus complexes
que d’autres. C’est particulièrement vrai lorsque le flot d’exécution séquentiel du programme
est interrompu. Cette règle recherche certaines causes d’interruption du flot que sont les
boucles, les sauts en arrière et les niveaux d’imbrication d’instructions complexes trop élevés.
Nombre cyclomatique v(G)

La complexité cyclomatique (aussi nommée Mesure de McCabe) est un outil développé par
Thomas McCabe en 1976 pour mesurer la complexité d'un programme informatique. Cette
mesure comptabilise le nombre de « chemins » qu’un programme peut emprunter.
La complexité cyclomatique d'un programme structuré est définie par :
M = E − N + 2P
où
M = complexité cyclomatique
E = le nombre d'arêtes du graphe
N = le nombre de nœuds du graphe
P = le nombre de composantes connexes du graphe.
Le nombre cyclomatique donne une information relative à la complexité d’une routine. Il est
important que le nombre cyclomatique reste raisonnablement bas. Le nombre cyclomatique
représente le nombre de chemins d’exécution différents qui peuvent être exécutés dans une
routine. Plus ce nombre est élevé, plus il est difficile de valider le comportement correct de
cette routine. Il est alors nécessaire de diviser celles-ci en d’autres sous-routines de nombre
cyclomatique inférieur au seuil.
113
Ratio de code dupliqué sur l’application

Ce nombre détecte le pourcentage de code qui est dupliqué. Réutiliser le code en le
copiant/collant n’est pas une bonne pratique. La maintenance et l’évolution du programme
deviennent plus difficiles car les modifications doivent être appliquées à plusieurs endroits.
De plus l’opération manuelle consistant à Copier/Coller est souvent responsable d’erreurs
difficiles à détecter: De plus, la phase de modification qui suit la recopie est parfois
incomplète.
Règles spécifiques
PLC Checker permet également de définir des règles spécifiques. Une règle spécifique à la
SNCF par exemple, est la mise en œuvre de GRAFCET (IEC 60848, 2002) dans l’atelier de
programmation automate en langage SFC (IEC 61131-3, 2003). Grâce à ce langage, le
fonctionnement séquentiel des appareils est décrit visuellement. Ainsi les programmes SFC de
l’ensemble des projets suivent la même structure. Cette structure permet à n’importe quel
chargé d’études de comprendre le programme grâce au nommage et aux commentaires qui
doivent suivre les règles décrites.
Grâce à PLC Checker, il est possible d’analyser objectivement la qualimétrie des programmes
et d’obtenir un retour d’expériences sur les programmes (Figure 37). Après cette première
étape d’analyse, les règles spécifiques du métier peuvent être définies et intégrées dans PLC
Checker pour les analyses suivantes.
Une fois le retour d’expériences sur les programmes d’origine obtenu, des corrections peuvent
être apportées aux programmes afin de les améliorer. L’objectif est de corriger tous les
avertissements émis par PLC Checker afin de répondre aux exigences de la norme ISO 9126.
A la fin de cette étape, les programmes peuvent servir de base pour l’établissement des
templates de génération de code. Cette étape a permis de mettre en évidence quelques défauts
dans les programmes API existants et de les corriger. Les erreurs constatées proviennent
principalement du fait que les programmes actuels sont le résultat de nombreux projets
antérieurs. Par conséquent, des variables non utilisées ou encore du code mort ont été mis en
évidence. L’étape suivante consiste à décomposer la partie commande et la partie opérative
afin d’obtenir une architecture de contrôle/commande distribuée répondant aux besoins de
disponibilité du système.
114
3.4.4 Formalisation des langages
Maintenant que les programmes ont été étudiés et améliorés selon des critères de qualité, il est
possible de définir les liens qui existent entre eux et d’établir une structure générique. Le
paragraphe (2.3.4.3 – Les techniques de génération du code) du chapitre précédent a décrit
différentes techniques permettant de définir les templates qui serviront pour générer les
programmes. L’application de l’approche « template-based » à un domaine alliant concepts
métier et automatisation, permet la prise en considération de deux techniques (Figure 39) :
 Technique basée sur les Interfaces de Programmation d’Applications (Application

Programmation Interface - IPA) : Il s’agit de la définition du formalisme du langage
de programmation. Par exemple, le formalisme DTD (Document Type Definition)
permet de définir la grammaire que doit respecter un fichier XML (Extensible Markup
Language). Ce qui est applicable au fichier XML d’import/export de certains ateliers
de programmation API. La standardisation des sources XML est l’un des objectifs de
l’organisation PLCopen. L’intérêt évident de la standardisation des fichiers sources en
XMLOpen est l’interopérabilité des sources et par conséquent l’indépendance vis-à-
vis des fournisseurs d’API.
 Technique basée sur les templates et le méta-modèle : Il s’agit de définir un méta-
modèle du métier ou du système permettant de définir l’ensemble des variables du
système et de ses structures. Il est également possible de définir un méta-modèle pour
les API. La Partie Commande (PC), en fonction du type d’API ciblé, définit la
grammaire de l’IPA correspondante. L’IPA ciblée définit une grammaire propre de
définition des variables (dictionnaire des variables), de câblage des E/S, de
transcription des langages graphiques (LD, FBD, SFC) en fichier texte. Les structures
de la PC sont étudiées dans la section suivante. La Partie Opérative (PO) est
également étudiée dans la section suivante afin de faire le lien entre PO et PC.
115

l’Interface de Programmation
3.4.5 Analyse structurelle pour la modélisation du système
L'analyse structurelle est une méthode de structuration d'une réflexion collective. Le système
étudié peut être défini comme un ensemble d'éléments en interaction. L’objectif est de se
poser les bonnes questions et de mettre en évidence les variables et les critères influents.
Préalablement à la mise en place de cette démarche d’analyse structurelle, il est nécessaire de
définir les besoins au travers d’un modèle. Pour construire ce modèle, des données d’entrée
sont nécessaires :
 “Who?” Quels sont les objets qui forment le modèle ? Peuvent-ils être regroupés par
famille ou par groupe ?
 “What?” Quelles fonctionnalités (attributs et méthodes) apporteront ces objets ? Quels
héritages peuvent être mis en place ?
 “Where?” Où seront contrôlés les objets, par quel API ?
 “How?” Comment organiser ces objets avec cohérence dans le modèle final ?
116
A partir des réponses à ces interrogations, nous allons construire le modèle de PO d’une part
puis le modèle de PC et construire les liens existant entre la PO et la PC. Pour répondre à ces
questions et construire les modèles du système, il est nécessaire d’avoir intégré les principes
du métier et surtout de s’appuyer sur le savoir-faire des chargés d’études qui possèdent une
expertise du métier qui n’est pas forcément retranscrite dans les documents techniques.
3.4.5.1 Décomposition de la Partie Opérative
Pour répondre à ces questions, il faut partir du système global étudié : la Partie Opérative
(PO). La PO (Figure 40) peut être décomposée en sous-ensembles de Partie Opérative (SePO)
en fonction du rôle ou des tâches à effectuer de ces sous-ensembles. Enfin, chaque SePO est
composé d’éléments de Partie Opérative (ElPO), que forment les objets du système réel. Un
type d’ElPO ne peut être contenu que dans un type de SePO. Cette décomposition forme le
méta-modèle du système qui doit être respecté par le modèle du système qui sera proposé.
Partie Opérative
1
*
SePO
1
*
ElPO
Figure 40 : Méta-modèle de la Partie Opérative
La PO, les SePO et les ElPO sont des objets instanciables ayant des attributs et des méthodes.
Pour chacun, il faut recenser les variables qui le caractérisent. Ces attributs et ces méthodes
permettront de définir des comportements différents selon leur valeur lors de l’étape de
génération de code. Il est donc nécessaire de porter un grand intérêt à cette étape. Celle-ci ne
peut se faire sans une connaissance approfondie du système. L’intervention des experts du
domaine spécifique est donc indispensable pour cette étape. Ils connaissent les paramètres, les
options et les différences possibles de chaque SePO et ElPO.
117
Pour rester dans le thème des EALE, la Figure 41 donne une décomposition simplifiée d’une
sous-station. Cette décomposition permet de structurer la PO. Dans cet exemple, la
décomposition est structurée en groupes fonctionnels qui sont composés d’appareils HT. Ces
groupes fonctionnels sont instanciables et les relations sont comparables aux agrégations et
compositions des diagrammes de classe. Dans ce modèle simplifié et par conséquent
incomplet (Figure 41), une sous-station est composée d’un ou plusieurs DT, GT et Batteries
de condensateurs (Batt. K). Un DT est composé d’un ou deux appareils de coupure Tête de
Câble (TdC) et d’un ou deux Disjoncteurs (Dj) de DT. Un GT est composé d’un
Transformateur (Transfo.), d’un Sectionneur à Rupture Brusque (SRB) et d’un Disjoncteur de
GT. Une batterie de condensateurs est composée d’un disjoncteur (DK) et de zéro ou un
sectionneur (SK).
Sous-station
1 1
1 1
1
*
*
*
DT GT Batt. K
1 1 1 1 1 1 1
1
1..2
1
1 1 1..2
1 1 1
*
*
*
*
1..2 1..2 1 1 1 0..1 1

TdC Dj DT Dj GT Transfo. SRB SK DK
Figure 41 : Modèle simplifié d’une sous-station
Pour obtenir un découpage fonctionnel cohérent avec la suite de la méthode, la partie

commande ne doit pas être omise. Les SePO doivent, autant que possible, se rapprocher d’une
fonction attribuée à un API du système de contrôle/commande distribué. En effet, les
principes d’alimentation mis en œuvre dans les EALE décomposent le système en sous-
systèmes fonctionnels ayant chacun la charge d’une fonction. Pour assurer la disponibilité du
système, ces fonctions doivent être redondées. Afin de respecter cette redondance
fonctionnelle, la distribution du système de contrôle/commande doit correspondre au
découpage fonctionnel réalisé par les principes d’alimentation des EALE. Le paragraphe
suivant décrit la décomposition de la PC proposée pour répondre à la problématique de la
distribution.
118
3.4.5.2 Décomposition de la Partie Commande
La Partie Commande (PC) est décomposable en diagramme de classe en considérant plusieurs

niveaux de compositions et de généralisations (Figure 42).
Partie Commande
*
API
1
*
Module E/S
Carte Entrées Carte E/S Carte Sorties
1 1 1 1
*
*
Entrée Sortie
Figure 42 : Méta-modèle de la Partie Commande
La PC est toujours composée d’au moins un API. Un API est composé de modules
d’Entrées/Sorties (E/S). Un module d’E/S peut être soit une carte d’entrées, soit une carte de
sorties, soit une carte d’E/S. Selon les systèmes, ce modèle de PC peut être contraint. Par
exemple, pour les SCLA, il n’existe pas de cartes de Sorties. La position des appareils
commandés par les API est toujours contrôlée. Ils sont donc nécessairement connectés sur une
carte d’E/S.
Maintenant que la PO et la PC ont été décomposées, les liens entre les différents niveaux de
décomposition obtenus peuvent être établis.
119
3.4.5.3 Liens entre PO et PC
Dans un système automatisé, la PO et la PC ne peuvent pas être dissociées. Il convient alors

de définir les liens qui unissent ces deux parties. La Figure 43 présente le méta-modèle de
connexion entre ces deux parties qu’il convient de respecter autant que faire se peut afin
d’obtenir une architecture dont la disponibilité est optimale.
Base
1 1
1
*
*
Partie Commande Partie Opérative
1 1
1 1
*
*
API SePO
1 1
1
1
*
ElPO
1..*
Figure 43 : Méta-modèle des connexions entre PO et PC

Le méta-modèle définit la structure à laquelle doit ressembler le modèle d’une application
réelle. Le méta-modèle de PO obtenu permet d’identifier les SePO et les ElPO du système. Ils
sont associés à un API et à des E/S de cet API. Chacun d’eux peut être instancié et possède
des caractéristiques spécifiques. Ces caractéristiques et le méta-modèle décrit sont utilisés
pour définir les templates de génération de code. Les templates sont également associés aux
objets qui composent les modèles. L’instanciation d’un objet entraine l’instanciation d’un
template qui sera généré pour produire le code source final de l’application.
120
3.4.6 Définition des templates de génération de code
Les templates correspondent à la structure que doivent respecter les programmes liés à chaque
SePO ou ElPO. Le code généré est basé sur un template textuel rempli par un moteur de
génération grâce aux éléments contenus dans le méta-modèle.
Quelques règles de bonnes pratiques doivent être respectées :
1. Lisibilité du code généré : le code généré doit être facile à lire et comprendre. Il doit
respecter la mise en forme qui existait auparavant (indentation, commentaires, etc.).
2. Réutilisation : les templates doivent être réutilisables dans différents contextes. Ils
peuvent être utilisés par des objets abstraits du modèle. Le comportement du template
doit alors être adapté en fonction du contexte d’appel.
3. Maintenabilité : les templates sont créés pour être modifiés. Le changement doit être
fait d'une manière rapide et agile, il doit être lisible ou pouvoir être rendu lisible. En
effet les templates donnent la forme que suivront les fichiers générés. Toutefois,
trouver un compromis entre lisibilité du template et respect de la forme du fichier
généré n’est pas toujours évident.
4. Composition : un template doit être importable par d'autres templates.
5. Séparation des rôles : les templates génèrent le code des programmes, le moteur gère
l’architecture du fichier ou des fichiers à générer et un contrôleur vérifie que la
structure des fichiers est conforme à la grammaire ou au modèle du fichier.
6. Constance : l’exécution d’un template avec un ensemble de paramètres doit toujours
donner le même résultat.
A partir du code source d’une application, il est possible de définir les tâches exécutées et de
les affecter à différentes ressources. Dans notre cas les ressources sont les API. Pour chaque
tâche, des données d’entrée sont nécessaires et peuvent dépendre d’autres tâches parallèles. A
partir de cette analyse du partage des tâches par SePO et ElPO, qui doit correspondre à
l’architecture de la Partie Commande, les templates de l’application peuvent être définis
(Figure 44). Les templates d’une application API respectent des règles qui correspondent à la
grammaire du langage de l’Interface de Programmation. Chaque API exécute un programme
qui peut nécessiter des informations venant d’autres API. Dans tous les cas, un programme
API est toujours composé de l’architecture matérielle de l’API, de la définition des
connexions de ses E/S et des programmes (IL, LD, ST, FBD ou SFC) qu’il exécute.
121
Figure 44 : Méthode de définition des templates distribués

Par cette méthodologie de génération de code API, il est possible de reconstruire une
application complète sur la base d’une description de la PO contenant les SePO composés
d’ElPO et d’une description de la PC. Cette description unique détaillée permet alors de
générer l’ensemble des livrables en suivant le workflow existant du projet. Pour cela, le
développement d’un outil logiciel ou l’intégration d’un outil logiciel industriel existant est
nécessaire. En effet, pour que la génération puisse être appliquée, il est nécessaire de mettre à
la disposition des chargés d’études, un outil adapté, reprenant leur langage métier et leur
donnant envie de l’utiliser. Un effort doit être fait sur l’Interface Homme Machine (IHM) et
sur la manière de modéliser le système. Par exemple, dans le cas des études d’automatisation
réalisées par la SNCF, une donnée d’entrée utilisée par tous les chargés d’études est le schéma
unifilaire, décrivant électriquement l’architecture du système. Il semble alors opportun de
proposer aux chargés d’études de définir l’architecture de leur système sous la forme d’un
schéma unifilaire par l’intermédiaire d’objets graphiques prédéfinis.
122
3.4.7 Outil de mise en œuvre de la génération
Les modèles présentés dans cette section permettent d’établir les bases du domaine spécifique
des API. Ces règles sont applicables à tout système automatisé et distribué.
L’intégration d’un outil industriel de génération de code et de livrables par la méthode de
Domain Specific Modeling (DSM) (Tolvanen, 2005) permet de garantir la pérennité du projet
et d’apporter des garanties quant aux résultats de la démarche. En effet, l’industriel apporte en
plus de sa solution logicielle, l’expérience de réalisations passées. Par l’aspect DSM des outils
industriels, leur intégration au sein de notre démarche d’amélioration métier est naturelle.
L’avantage de ces solutions DSM est qu’une fois que le langage métier est défini et modélisé,
comme nous l’avons montré jusqu’ici dans ce chapitre, les cibles de génération peuvent
évoluer ou augmenter sans avoir à remettre en cause tous les modèles. Au contraire, à partir
des modèles existants, il suffit de définir de nouveaux templates pour générer de nouvelles
cibles d’export. L’avantage pour les chargés d’études est également de pouvoir leur apporter
une solution plus ergonomique. En effet, les solutions industrielles intègrent des vues pour
que les chargés d’études puissent définir la configuration de leur système de manière
graphique à partir d’objets prédéfinis qu’il faut paramétrer.
La génération à partir d’une saisie graphique évite une saisie multiple des mêmes
informations dans les livrables qui peut entrainer un sentiment de monotonie (Sperandio,
1988). Cette description unique permet alors de concentrer l’attention du chargé d’études et
ainsi d’optimiser et de lisser la courbe de sa charge de travail mentale. Il s’agit également par
cette description paramétrable, d’ajouter une première sécurité dans le processus de
génération du projet. En effet, lors de la description, un contrôle de cohérence est effectué afin
d’empêcher les saisies incohérentes. L’information est alors visible par le chargé d’études afin
qu’il puisse corriger lui-même son erreur. La cohérence est basée sur le modèle objet de
l’installation transcrit en modèle de Base de Données Relationnelle (BDR) correspondant au
modèle objet du système.
La génération des livrables à partir de la description unique effectuée par le chargé d’études
nécessite une relecture (Figure 45). Cette tâche cognitive demande davantage de
concentration au chargé d’études puisqu’il s’agit d’une tâche de validation des documents
qu’il aurait eu à écrire précédemment. Cette phase de relecture permet également au chargé
d’études d’avoir un regard critique sur les éléments générés, dont le retour permet d’améliorer
la génération. Il doit être concentré afin d’analyser les manques et compléter les éléments
générés. Cette tâche demande, elle aussi, une concentration importante du chargé d’études. Il
123
doit compléter à la fois les livrables mais aussi les programmes pour les ElPO qui n’ont pas
pu être définis lors de la description.
Figure 45 : Workflow pour la génération de code et de livrables

Ce nouveau workflow supprime les phases de sous charge mentale en les remplaçant par des
phases cognitives dont l’enchainement permet d’éviter une surcharge mentale. La saisie
unique dans un environnement logiciel unique permet au chargé d’études de rester concentré
et de ne pas perdre en performance. En effet, les informations contenues dans les livrables
peuvent être des doublons que le chargé d’études devait alors écrire plusieurs fois. Cette
répétitivité monotone qui rend le travail du chargé d’études peu intéressant, est source
d’erreurs et comme dit précédemment, de sous-charge mentale.
La concentration du chargé d’études est alors recentrée sur une nouvelle tâche, dans laquelle il
doit décrire une seule fois l’ensemble des paramètres du projet de conception de l’EALE pour
que les livrables standardisés soient générés. Une fois les livrables standardisés générés
d’après le modèle des livrables existants, le chargé d’études doit mettre en œuvre tout son
savoir-faire métier pour ajouter les éléments qui ne sont pas standards. En effet, la grande
diversité des installations rend impossible la standardisation complète. Chaque installation a
des particularités qui doivent être prises en compte par le chargé d’études.
L’ensemble des chargés d’études utilisera cette solution, ce qui rendra donc l’ensemble des
projets, homogènes et plus facilement compréhensibles par tous. Dans le chapitre 4, une
comparaison entre ce nouveau workflow et l’ancien sera présentée.
124
La deuxième partie de notre démarche consiste à intégrer une génération de la commande sûre
de fonctionnement. L'approche proposée sépare la partie commande fonctionnelle de la partie
commande sécuritaire. L’objectif de cette séparation de la partie fonctionnelle, de la partie
sécuritaire, est d’assurer la sécurité du système, quelle que soit la partie fonctionnelle
implémentée dans l’API. L’intérêt de la démarche de génération du filtre robuste et de la
commande par contraintes est d’assurer au chargé d’études qu’il ne risque pas de nuire à la
sécurité du système et des hommes. Ainsi, il peut être serein et éviter un état de stress pouvant
mener à une surcharge mentale. La section suivante présente la démarche de génération de la
commande par contraintes qui est intégrée dans la démarche globale proposée (Figure 46).
Figure 46 : Démarche de génération de la commande par contraintes (en noir)
125
3.5 Démarche de génération du filtre à base de contraintes de sécurité
Cette section présente une approche originale de la génération de la commande sûre de

fonctionnement pour contrôler et commander des systèmes automatisés. Cette commande est
basée sur la définition de contraintes booléennes permettant de limiter l’espace de liberté du
système. L’idée innovante de cette démarche de génération de la commande est de séparer la
partie sécuritaire de la partie fonctionnelle (Figure 47). Ainsi l’espace de liberté est contraint
par les contraintes de sécurité d’abord, puis par les contraintes fonctionnelles ou la partie
fonctionnelle suivant la solution d’implémentation choisie. Deux solutions sont possibles pour
intégrer cette commande sûre de fonctionnement :
 Synthèse d’un filtre à base de contraintes : dans ce cas, la partie fonctionnelle peut être
définie au gré de l’utilisateur final mais la partie sécuritaire à base de contraintes sera
ajoutée au programme afin d’assurer que quelle que soit la partie fonctionnelle, la
sécurité du système sera toujours assurée.
 Génération de la commande fonctionnelle : la partie sécuritaire étant gérée par les
contraintes de sécurité, l’utilisateur peut se contenter de décrire uniquement la partie
fonctionnelle de la commande. Cette approche modifie considérablement la manière
de concevoir la commande car elle revient à définir séparément les contraintes de
sécurité et les contraintes fonctionnelles.
Figure 47 : Espace de commande du système

Cette approche est une extension des travaux de recherche que le CReSTIC (Centre de
Recherche en Sciences et Technologies de l’Information et de la Communication) menés sur
la définition et la conception de contraintes Booléennes placées à la fin d’un programme API,
agissant en tant que filtre logique, pour assurer la robustesse du contrôleur aux erreurs de
commande. Dans les travaux initiaux présentés dans le chapitre 2, ces contraintes de sécurité
126
sont formellement vérifiées hors ligne par model-checking (Marangé et al., 2010) et sont
définies pour garantir l’espace de liberté du système sûr le plus large possible. En cas de
violation d’une contrainte pendant le cycle API, la commande envoyée permet de replier la
PO dans un état de repos sans danger. Les contraintes de sécurité sont exprimées sous la
forme d’un monôme (produit de variables logiques, forme ) qui est une fonction logique des
Entrées/Sorties de l’Automate Programmable Industriel (API) et d’éventuels observateurs
(fonction des Entrées) pour pallier au manque d’observabilité du système. Le filtre robuste
s’implémente à la suite du programme de commande dans l’API afin d’assurer la sécurité
quelle que soit la commande implémentée dans le contrôleur industriel (API).
Le travail de définition des contraintes de sécurité appliqué à l’automatisation des EALE ne
doit être fait qu’une seule fois. Seule la partie fonctionnelle des éléments peut être amenée à
être modifiée. C’est pourquoi l’intérêt d’assurer la sécurité des ElPO, SePO et du système
global, grâce au filtre formel, quelle que soit la commande implémentée dans l’automate
semble pertinente. Bien que cette approche formelle nécessite l’intervention d’un expert du
système, combinée à la démarche de standardisation, elle permet de renforcer la sécurité des
ElPO et SePO sans compliquer le travail des chargés d’études.
Dans la méthodologie initiale décrite par (Marangé et al., 2010 , Riera et al., 2009) et
présentée succinctement dans le chapitre 2, l’ensemble de contraintes de sécurité est vérifié
formellement au moyen du « model-checker » UPPAAL (Behrmann et al., 2002) et repose sur
une modélisation du système (PO et PC) au moyen d’automates à états temporisés prenant en
compte différents types de données (intervalle d’entiers, tableaux, …). Les propriétés
permettent de vérifier que les contraintes de sécurité garantissent que la PO ne se trouvera
jamais dans un état dangereux.
L’idée que nous avons développée consiste à étendre l’utilisation du filtre à la
commande. Pour cela, le principe s’apparente à la SCT de Ramadge et Wonham présentée
dans le chapitre 2 en autorisant ou en bloquant les événements commandables à chaque cycle
API. Contrairement à l’approche initiale du filtre, en cas de violation de contraintes, la PO
n’est pas systématiquement repliée dans un état de repos. Le paragraphe suivant présente
notre contribution théorique au domaine et développe la méthode, le formalisme du
filtre et son utilisation pour obtenir un contrôleur sûr de fonctionnement facilement
implémentable dans un API.
127
3.5.1 Définition du filtre robuste à base de contraintes
Les API ont un fonctionnement cyclique. Pour pouvoir reconstruire toutes les informations
nécessaires à la commande du système, il est nécessaire de mémoriser les valeurs des
informations, capteurs et sorties du cycle précédent. Dans la démarche, pour vérifier les
propriétés de sécurité, il est nécessaire de modéliser ce fonctionnement cyclique, qu’il faut
synchroniser par rapport aux évolutions de la PO. En effet, pendant le cycle de l’automate, le
système peut évoluer, mais ces évolutions ne seront lues qu’au cycle suivant. Cette
synchronisation est modélisée dans la Figure 48.
Figure 48 : Modélisation du cycle API synchronisé par rapport à la PO
Chaque cycle commence par la lecture des entrées de l’automate (Lecture !). Ensuite, la
commande est calculée. Dans l’approche initiale, aucune hypothèse n’est faite et le contrôleur
est modélisé par un automate à états non déterministes. En d’autres termes, tous les
changements possibles des sorties sont envisagés. Ensuite, une phase de reconstruction des
informations (calcul des fronts montants, descendants, observateurs) est nécessaire
(Reconstruction !) Les contraintes peuvent alors être calculées. Si une contrainte est violée, la
commande entrainant un repli de la PO est calculée (Contraintes !). Enfin les valeurs des
sorties sont écrites vers les actionneurs (Ecriture !). Les actions des actionneurs font évoluer
le modèle de partie opérative (PO !) avant le début du cycle suivant, qui commence par une
nouvelle lecture des entrées.
128
Les notations utilisées pour présenter l’approche sont les suivantes :

 t : cycle courant (du point de vue API),
 t-1 : cycle précédent (du point de vue API),
 ( ): variable logique correspondant à la kième valeur booléenne de sortie
(actionneur) de l’API à l’instant t. Les sorties courantes sont considérées comme les
seules variables pouvant être commandées à chaque cycle API. Toutes les autres
variables (entrées, sorties précédentes,…) sont non commandables, c’est-à-dire : en
lecture seule.
 ( ): variable logique correspondant à la kième valeur booléenne de sortie

(actionneur) de l’API à l’instant t-1 (cycle précédent de l’API),
 “.”, “+”, “‾‾” sont respectivement les opérateurs logiques AND, OR, et NOT. La
valeur 0 correspond à FAUX (ou FALSE) et 1 correspond à VRAI (ou TRUE),
 ∑ et ∏ correspondent respectivement à la somme logique (OR) et au produit

logique (AND) de variables logiques,
 ∑∏ est un polynôme logique (sommes de produits, aussi appelé SIGMA-PI),
 est un front montant calculé dans l’API de la variable booléenne ( ̅̅̅ ),
 est un front descendant calculé dans l’API de la variable booléenne (

̅ ),
 O: ensemble des variables de sortie à l’instant t,
 Y : ensemble des variables non commandables aux instants t, t-1, t-2 …,
 No : nombre de sorties logiques de l’API,
 NCSs: nombre de contraintes de sécurité simples,
 NCSc: nombre de contraintes de sécurité combinées.
La méthodologie proposée pour concevoir les contrôleurs sûrs est basée sur l'utilisation des
contraintes logiques de sécurité. Il est donc nécessaire de bien comprendre la philosophie de
définition des contraintes.
129
3.5.1.1 Principe d’écriture des contraintes
Les contraintes sont toujours définies du point de vue de la partie commande (PC), et il est
supposé que le temps de cycle API est suffisant pour détecter tous les changements du vecteur
d'entrées (opération synchrone, changements d'états simultanés des entrées de l’API
possibles).
Dans cette approche, les contraintes de sécurité sont exprimées sous la forme de monômes
logiques (produit des variables logiques, ∏). Les contraintes de sécurité doivent toujours être
égales à 0 (FAUX) à la fin de chaque cycle API avant la mise à jour des sorties, afin de
garantir la sécurité. L'état initial sûr de tous les actionneurs ( ) est défini à 0.
Les contraintes doivent être également définies afin de garantir la contrôlabilité du système.
Cela signifie que l’espace sécuritaire du système doit être suffisamment grand pour que le
système soit vivant. Après application des contraintes de sécurité, il doit être possible de
concevoir un contrôleur qui répond aux spécifications fonctionnelles du système. Par
exemple, en considérant l'hypothèse précédente au sujet de l'état initial sûr, un ensemble de
contraintes de sécurité qui remet à zéro toutes les sorties est sûr mais n'assure pas la
contrôlabilité.
Il faut différentier les contraintes qui impliquent une sortie unique à l’instant t (appelées
contraintes de sécurité simples, CSs), et les contraintes impliquant plusieurs sorties à l’instant
t (appelées contraintes de sécurité combinées CSc). Les contraintes exigent la connaissance
des E/S à l’instant t et aux instants précédents (présence de fronts par exemple).
Il peut être nécessaire de définir des observateurs dus au manque d'observabilité de système.
A titre d’exemple, une caisse peut être présente sur un convoyeur sans qu’un capteur indique
sa présence. Les observateurs correspondent idéalement à une fonction séquentielle des
entrées de l’API et permettent d’intégrer un état de la séquence aux contraintes de sécurité.
L'ensemble de contraintes de sécurité est considéré comme nécessaire et suffisant pour
garantir la sécurité du système. En d’autres termes, le retrait d’une contrainte ne garantit plus
la sécurité et l’ajout d’une contrainte n’apporte rien au niveau de la sécurité. Dans cette
approche, les contraintes de sécurité peuvent toujours être représentées comme des monômes
logiques et dépendent des entrées (à t, t-1, t-2…), sorties (à t, t-1, t-2…) et observateurs
(dépendant uniquement des entrées à t, t-1, t-2…) (Figure 49).
130
Figure 49 : Structure interne du filtre robuste

Le paragraphe suivant propose une démarche adaptée à la problématique de l’automatisation
des systèmes distribués pour définir les contraintes de sécurité.
3.5.1.2 Démarche de définition des contraintes
Seul un expert du domaine peut définir les contraintes du système. L’expert a le recul
suffisant sur le fonctionnement du système pour suivre la démarche proposée (Figure 50). Le
but est de parvenir à définir les contraintes de sécurité sans faire d’hypothèses sur la
commande proposée.
1. La première étape est une analyse structurelle du système. Dans le cas qui nous
intéresse, celle-ci fait partie de la méthodologie proposée en début de chapitre.
2. La deuxième étape consiste à définir le document d’entrée pour définir rigoureusement
les contraintes. Selon le système étudié, cette étape de définition peut se faire à partir
de différents documents d’entrées :
 A partir d’une analyse dysfonctionnelle, disponible ou réalisée par l’expert.
L’analyse dysfonctionnelle permet de définir les interactions entre ElPO et les
états que le système ne doit pas atteindre. Une analyse dysfonctionnelle est
généralement décomposée par élément et permet alors de définir
modulairement les CSs.
 A partir du cahier de recette, qui contient tous les tests d’intégration auxquels
doit répondre le système. Sa complétude est affirmée par le retour d’expérience
131
des systèmes exploités. Ainsi, l’expert qui écrit l’ensemble de contraintes à

partir du cahier de recette est certain d’atteindre le même niveau de sûreté du
système. Le cahier de recette contient toutes les interactions entre SePO et
ElPO. Une fiche du cahier de recette contient généralement l’état initial du
système pour réaliser la fiche, les actions à réaliser et les résultats attendus. Il
est alors assez simple de traduire les états en contraintes puisqu’elles sont
généralement écrites sous la forme d’actions entrainant des réactions.
3. La troisième étape consiste à identifier tous les états dangereux pour chaque SePO et
ElPO afin de définir les contraintes permettant de les empêcher.
4. Lors de la quatrième étape, l’expert vérifie la suffisance de l’ensemble de contraintes
(CSs, CSc) pour le système global. Cela consiste à définir les propriétés à vérifier. Il
vérifie également que le système est toujours vivant et que l’espace de fonctionnement
du système n’est pas trop contraint par l’ensemble de contraintes.
5. Comme précisé au début de cette section, deux solutions sont possibles :
 La synthèse complète de la commande par contraintes, auquel cas il faut
ajouter les contraintes fonctionnelles (CF) aux contraintes de sécurité (CSs et
CSc).
 L’intégration d’une partie fonctionnelle déjà existante à laquelle est ajoutée la
couche sécuritaire apportée par le filtre robuste à base de contraintes qui
garantit la sûreté du fonctionnement du système.
L’ensemble des contraintes fonctionnelles ou la partie fonctionnelle est alors ajoutée à
l’ensemble des contraintes de sécurité pour vérifier le fonctionnement global du
système.
6. Lorsque le fonctionnement global est vérifié, il reste à appliquer l’algorithme, c’est-à-
dire : le Design Pattern générique de la commande par contraintes pour obtenir une loi
de commande sûre de fonctionnement.
132
Figure 50 : Démarche de définition des contraintes
3.5.2 Propriétés des contraintes
Les CSs et les CSc sont représentés (équations (1) et (2)) comme des fonctions monômiales
logiques (∏) qui doivent toujours être égales à FAUX à la fin de chaque cycle pour garantir la
sécurité. Il est important de noter que chaque CSs dépend seulement d'une variable
commandable (sortie : ok) et chaque CSc dépend de plusieurs variables commandables (sorties
: ok, ol, …).
[ ] [ ]
∏( ) (1)
[ ] ( ) [ ]
∏( ) (2)
133
Il existe seulement deux formes exclusives des contraintes de sécurité simples (CSs) parce
qu'elles sont exprimées comme fonction de monôme, et elles impliquent seulement une sortie
unique à l’instant t (équation (3) ou (4)) :
[ ] [ ]
( ) (3)
XOR
̅̅̅ ( ) (4)
Ces contraintes de sécurité simples (CSs) expriment le fait que si ( ), qui est une fonction
monômiale (produit) de variables non commandables à l’instant t est VRAI, alors ok doit être
nécessairement FAUX (équation (3)) afin de maintenir les contraintes égales à 0. Si ( ) est
VRAI, ok doit être nécessairement VRAI (équation (4)).
Pour chaque sortie, il est possible d'écrire l'équation (5) correspondant à une somme logique
de toutes les contraintes de sécurité simples.
∑ ∑ ( ( )) (5)
( ) est une fonction logique ∑∏ indépendante des autres sorties à t étant donné que
seules les CSS sont considérées. ( ) peut être développé dans l'équation (6) où et
sont les fonctions polynômiales (somme de produits, ∑∏) des variables non
commandables (c’est-à-dire : lues uniquement). L'équation (6) doit toujours être égale à
FAUX étant donné que toutes les contraintes de sécurité simples doivent toujours être égales à
FAUX à la fin de chaque cycle API.
( ) ( ) ̅̅̅ ( ) (6)
En considérant toutes les CSs, il est possible d'écrire l'équation (7).
∑ ∑ ( ( ) ̅̅̅ ( )) (7)
On constate que nous retrouvons l’expression du théorème démontré par Hieter (2009)
présenté dans le chapitre 2. Par conséquent, les contraintes de sécurité simples doivent
respecter la propriété mathématique suivante (équation 8) pour que l’équation admette une
solution :
( ) ( )=0 (8)
En effet, si cette propriété n’est pas respectée, cela signifie que deux CSs sont en
contradiction et une des deux n'est pas vérifiée, ainsi l'ensemble de contraintes n'est pas
cohérent. Si fs0k = 0 ou si fs1k = 0, la propriété est logiquement vérifiée. Il est également
possible de démontrer la proposition suivante :
134
Proposition : si toutes les contraintes de sécurité simples impliquant la sortie ok dépendent

uniquement de fronts montants et de fronts descendants de la sortie ok, alors la propriété (8)
est toujours vérifiée (condition suffisante).
Preuve : si toutes les CSs impliquant ok, sont toutes basées sur un front montant ou sur un
front descendant, alors en utilisant le théorème d’expansion de Shannon, l’équation (9) est
obtenue :
( ) ̅̅̅̅ ( )
et
( ) ( ) (9)
En conséquence, comme ̅̅̅̅ et que l’état initial est sûr, la propriété (8) est vérifiée.
( ) ( ) ̅̅̅̅ ( ) ( ) (10)
3.5.3 Algorithme de la commande basée sur les contraintes logiques
L'algorithme de commande proposé sépare les exigences de sécurité des exigences

fonctionnelles. Ces dernières vont être formalisées au moyen de contraintes fonctionnelles
(CF). Toute contrainte qui ne fait pas partie de l’ensemble des contraintes de sécurité est
considérée comme une CF. L'algorithme de contrôle proposé consiste à chaque cycle API, à
autoriser les commandes fonctionnelles compatibles avec les exigences de sécurité. En
d’autres termes, il est possible de considérer une commande existante comme générant les
contraintes fonctionnelles. Si la commande est bien faite, en théorie aucune contrainte de
sécurité ne sera violée. Dans le cas contraire, la sécurité restera tout de même assurée sans
toucher à la commande existante. Cela signifie que l’algorithme de commande sûre développé
peut être intégré sans difficulté dans un template de commande à base de contraintes.
L’algorithme () va dans un premier temps être présenté sans tenir compte des contraintes de
sécurité combinées (CSc).
135
Figure 51 : Schéma d’entrées et sorties de l’algorithme (et de son Design Pattern)
3.5.3.1 Prise en considération des CSs et des CFs
Il est possible de définir, comme pour les CSs, des contraintes fonctionnelles simples (CFs) de
la sortie ok indiquant quand elle doit être égale à 0 ( ) ou à 1 ( ) (équation 11), d'un
point de vue fonctionnel.
( ) ( )
( ) ̅̅̅ ( ) (11)
Dans ce travail, uniquement les CFs et les sont considérées car cela correspond à la
réalité des programmes API existants. En effet, d’une part un programme API indique le plus
souvent à quel instant la sortie doit être activée et non pas à quel instant il ne faut pas
l’activer. D’autre part, les correspondent souvent à l’activation de sorties ( ) en fonction
des étapes de GRAFCET (IEC 60848, 2002) ou de SFC (IEC 61131-3, 2003) qui peuvent être
interprétés comme des observateurs. Dans le cas d’application de l’algorithme en tant que
filtre d’une commande existante, les correspondent aux valeurs des sorties calculées par
cette commande existante ( ) (équation 14) En intégrant les résultats de (Hietter, 2008)
sur la synthèse algébrique des contrôleurs logiques détaillée dans le chapitre 2, il est possible
136
d’écrire la solution paramétrique (où p est un paramètre booléen) de l'équation 6 (Riera,

Coupat et al., 2014a) permettant de calculer la valeur de la sortie (équation 12).
̅̅̅̅̅ (12)
Afin de garantir la sécurité en intégrant les contraintes fonctionnelles, il convient de choisir
p=1 et la solution devient l'équation (13). Cette équation traduit le fait que la sortie ( ) est
activée par sécurité lorsque la fonction polynomiale est vraie. Elle peut également être
activée par besoin fonctionnel lorsque est vraie si seulement si la fonction polynomiale
sécuritaire est fausse :
̅̅̅̅̅
̅̅̅̅̅ ̅̅̅̅̅ (13)
Pour utiliser l’algorithme en tant que filtre d’une commande existante, il suffit d’affecter à
chaque la sortie calculée par sa commande existante (équation 14).
(14)
La commande obtenue est sûre (s'il y a seulement des CSs) parce que la sécurité est assurée
indépendamment de la partie fonctionnelle. En effet, si les CFs tentent d’imposer une sortie à
0 ou à 1, en contradiction avec la sécurité, les membres et continuent de garantir la
sécurité. Par conséquent même si le programme API présente des erreurs de commande, la
sécurité reste assurée.
Un exemple pédagogique va permettre de bien comprendre l’idée de base. Supposons la table
de vérité d’un contrôleur, représentée par le tableau de Karnaugh de la Figure 52, où la sortie
(variable commandable) dépend de 4 entrées (variables non commandables) a, b, c, d.
Pour chaque vecteur d'entrées, la sortie est indiquée. Elle peut être égale à 0 ou 1 ou à une
valeur indéterminée (0 ou 1). Une valeur indéterminée vient d’une combinaison d’entrées
pour laquelle la valeur de la sortie n’a pas été définie par le concepteur, et par conséquent
n’influence pas le système. Certaines valeurs de la sortie sont imposées par la sécurité
(respectivement et ). Les autres valeurs relèvent des exigences fonctionnelles.
137
S’k ab
cd 00 01 11 10
00 0 0 (f0) 0 (f0) X (0 or 1)
01 0 0 (f0) 0 (f0) X (0 or 1)
11 0 0 (f0) 1 (f1) 1 (f1)
10 0 1 1 0
Figure 52 : Exemple pédagogique

Le calcul de la forme simplifiée de la sortie peut être obtenue en regroupant les ensembles
de 1 (ou de 0) (équation 15).
̅ (15)
A partir de ce tableau de Karnaugh, il est également possible d'exprimer l'expression

simplifiée de la sortie à l'aide de et et (équation 16). Il est essentiel de noter
que doit inclure, à minima, les états pour lesquels la sortie est activée du point de vue
fonctionnel. Cela peut être interprété de telle sorte que puisse en inclure davantage
(Figure 53).
{ ̅ ̅ (16)
S’k ab
cd 00 01 11 10
00 0 0 (f0) 0 (f0) X (0 or 1)
01 0 0 (f0) 0 (f0) X (0 or 1)
11 0 0 (f0) 1 (f1) 1 (f1)
10 0 1 1 0
Figure 53 : Exemple avec des caractéristiques fonctionnelles correctes

Dans cet exemple, représente un ensemble de 8 valeurs. Le résultat (équation 17) est le
même qu'obtenu selon (équation 15), et la condition fonctionnelle est plus simple à
exprimer.
̅̅̅̅̅
̅̅̅̅̅̅̅̅̅̅̅̅̅̅̅̅̅̅
( ̅ ̅ ) ̅ (17)
Un des points les plus intéressants est que, même si g1k est incorrectement exprimé (équation
18 et Figure 54), le calcul renvoie une valeur sûre. Ceci signifie que même si les
conditions fonctionnelles sont erronées la commande demeure sûre.
138
{ ̅ ̅ (18)
̅
S’k ab
cd 00 01 11 10
00 0 0 (f0) 0 (f0) X (0 or 1)
01 0 0 (f0) 0 (f0) X (0 or 1)
11 0 0 (f0) 1 (f1) 1 (f1)
10 0 1 1 0
Figure 54 : Exemple avec des caractéristiques fonctionnelles fausses

Le prochain paragraphe montre comment traiter les contraintes de sécurité combinées (CSc).
3.5.3.2 Prise en considération des CSc
Le problème des CSc semble être plus complexe. En effet, quand une CSc n'est pas vérifiée, il
est nécessaire d'accorder la priorité à une ou plusieurs sorties. Cependant, les CSc doivent
toujours être cohérentes avec les CSs, qui sont généralement prioritaires parce qu'elles
dépendent seulement des entrées et des observateurs. De plus, quand une CSc est résolue, cela
peut impliquer des problèmes avec d'autres CSc. Prenant en considération ces points, et
utilisant l'équation (13), il est possible d'écrire l'équation (19).
̅̅̅̅̅ (̅̅̅̅̅ ) (19)
fc0k et fc1k forcent la sortie ok à 0 ou 1 en prenant en considération les CSc. Durant le cycle API
à l’instant t, une valeur sûre de la sortie ok doit être trouvée. Cela signifie que la valeur de ok
doit être conforme avec toutes les CSc impliquant ok. Si fc0k et fc1k sont mal définis, une valeur
sûre de ok peut être impossible à calculer. Pour illustrer ce problème, prenons un exemple
simple. Soient les 2 CSc suivantes (équation 20) :
̅̅̅
̅̅̅ (20)
Les priorités sont définies telles que :

 lorsque CSc1 est VRAI la priorité est donnée à o1
 lorsque CSc2 est VRAI la priorité est donnée à o3
Dans ce cas, si o1 = 1 et o3 = 0, il est impossible de définir une valeur pour o2 respectant les 2
contraintes. Pour détecter ce problème, il faut vérifier qu’une CSc n’est pas violée deux fois
pendant un même cycle API. Ce sera le cas si une solution n’a pas été trouvée au bout de
(NCSc+1) tentatives au cours du même cycle API. En théorie, ce problème n’apparait pas si les
139
contraintes de sécurité ont été vérifiées formellement mais peut se produire en cas de
défaillance de capteurs par exemple.
Afin de présenter l’algorithme complet, il est nécessaire d’introduire des notations
complémentaires.
⃗⃗⃗⃗⃗ et ⃗⃗⃗⃗⃗ sont des vecteurs colonnes représentant respectivement les k valeurs de fc0k et fc1k.
⃗⃗⃗⃗⃗ et ⃗⃗⃗⃗⃗ peuvent être obtenus au moyen de deux matrices, MC0 et MC1 que le chargé
d’études doit définir pendant l'étape initiale d'analyse de sécurité pour indiquer la priorité
entre les sorties lorsque des CSc sont violées. MC0 et MC1 sont des matrices avec NCSc
colonnes et No lignes. MC0 et MC1 indiquent pour chaque CSc, si les sorties ( ⃗ ) doivent être
forcées respectivement à 0 ou à 1. Les équations (21 et 22) sont obtenues en utilisant le
produit logique de matrice.
⃗⃗⃗⃗⃗⃗⃗ ( ), vecteur colonne de CSc
⃗ ( ), vecteur colonne des sorties
⃗⃗⃗⃗⃗ ( ) ⃗⃗⃗⃗⃗⃗⃗
⃗⃗⃗⃗⃗ ( ) ( ) (21)
⃗⃗⃗⃗⃗ ( ) ⃗⃗⃗⃗⃗⃗⃗
⃗⃗⃗⃗⃗ ( ) ( ) (22)
140
La Figure 55 présente l'algorithme détaillé pour qu’il puisse être mis en application dans un
API en langage ST (IEC 61131-3, 2003).
/* g1k est calculé précédemment (programme existant ou non) ainsi que les observateurs (O) du
programme. Les matrices MC0 et MC1 des CSc sont également connues.
* Tous les sont calculés à chaque cycle API.
* Par sécurité, l’égalité suivante est vérifiée :
* Initialisation de et
Flag_CSs = FALSE
For k=1 to No
Flag_CSs = Flag_CSs + fs0k.fs1k
= False // INIT
= False // INIT
End for
Flag = not Flag_CSs
Cpt =0 // compteur pour les CSc
While (Flag and Cpt<NCSc)

// Chaque sortie ok est calculée selon : ̅̅̅̅̅ (̅̅̅̅̅ )
// olk est la valeur intermédiaire de ok
For k=1 to No
̅̅̅̅̅ (̅̅̅̅̅ )
End For
// Vérification que les CSc ne sont pas violées
Flag = FALSE
For i=1 to NCSc
Calcul de CSci avec les valeurs olk
Flag = Flag + CSci
End For
Cpt= Cpt +1
// si Flag =TRUE, la priorité est donnée à une sortie ok d’après les valeurs de MC0 et MC1
If Flag Then
For k=1 to No
For j=1 to NCSc
End For
End For
End If
End While
If Flag_CSs Then
print "Problème CSs"
Break // STOP avec erreur
End If
If (cpt= =NCSc) Then
print " Problème CSC"
// ok sont définies à une valeur sûre False en priorité.
For k=1 to No
̅̅̅̅̅
End For
End If
// Les sorties sont définies à une valeur sûre
For k=1 to No
End For
Figure 55 : Algorithme de commande sûre de fonctionnement
141
L’algorithme peut être utilisé comme Design Pattern de la commande, quel que soit le
système à commander et les spécifications. Il ne modifie pas en profondeur la commande
existante car le code correspondant au Design Pattern est ajouté à la fin des programmes
existants. Même si l’espace de fonctionnement restreint par la partie fonctionnelle (contraintes
fonctionnelles ou programmes existants) n’était pas suffisant pour garantir la sécurité du
système, celle-ci resterait assurée par les contraintes de sécurité. De plus, en cas de défaillance
matérielle du système, la structure « While » a été définie de telle sorte qu’elle ne risque pas
de provoquer de boucle infinie et donc le watchdog de l’API car le nombre de contraintes de
sécurité combinées (NCSc) est fini (Riera, Coupat et al., 2014b).
3.5.4 Synthèse
Cette section a présenté une méthode de génération de la commande sûre basée sur
l'utilisation des contraintes de sécurité (représentées comme ensemble de contraintes logiques
qui peuvent être simples ou combinées). Le résultat de ce travail est un algorithme générique
facile à implémenter dans un API ou à intégrer dans un template de commande par
contraintes. Le contrôleur programmé est sûr même si la partie fonctionnelle (contraintes
fonctionnelles ou programmes existants) est erronée car seule une commande respectant
les contraintes de sécurité est permise. La séparation des aspects « sécuritaires » et des
aspects « fonctionnels » offre des perspectives intéressantes comme l’amélioration des
performances et de la flexibilité du système. La gestion des modes de marche et arrêt ou des
modes opératoires liés au Manufacturing Execution System (MES) peuvent être facilité. Il en
est de même pour les modes « manuels » au travers des Interfaces Homme Machine (IHM) ou
des systèmes de supervision (Supervisory Control and Data Acquisition (SCADA)). Enfin,
cette méthodologie de définition de la commande pourrait changer la manière « traditionnelle
» de concevoir les contrôleurs des systèmes automatisés. Néanmoins, elle présente le grand
avantage de pouvoir être appliquée à une commande existante, ce qui est tout à fait approprié
au monde industriel. Dans le cas des EALE, cette vision du filtre de la commande est
intéressante et applicable car elle ne modifie pas fondamentalement le travail des chargés
d’études.
142
3.6 Conclusion
Ce chapitre a présenté notre contribution qui est à la fois méthodologique et théorique. Une
démarche originale pour les études d’automatisation permettant d’aboutir à la conception et la
réalisation d’un progiciel destiné aux chargés d’études et permettant la génération
automatique de livrables et de programmes API sûrs de fonctionnement a été proposée. Elle
entraîne in fine une amélioration du travail des chargés d’études sans modifier leur « savoir-
faire » car les livrables obtenus (à partir des templates) sont ceux qu’ils ont l’habitude de
produire. Elle s’applique, compte tenu de sa généricité, à tout domaine spécifique où la
commande est distribuée et la PO décomposable en SePO et ElPO. L’application de cette
méthodologie à un domaine « métier » se fait au moyen de la méthode itérative Agile (cycle
en VvvvWvvvWvvvV) de gestion de projets. En effet, une première étape de standardisation
est nécessaire afin d’établir les règles utilisées par le métier. Cette standardisation doit mener
à la définition des méta-modèles et de la grammaire des langages métier utilisés. Dès lors que
le métier est standardisé et le squelette du modèle défini, l’étude et le développement des
modèles et des templates de chaque SePO est réalisé indépendamment. Cette démarche
permet aux acteurs du projet d’avoir un retour d’expérience immédiat après chaque cycle du
processus. Ainsi, les vérifications ayant montré des erreurs dans la définition des templates
permettent d’établir des corrections qui seront également prises en compte pour les templates
suivants. L’intérêt de la décomposition en SePO intervient également lors de la génération du
filtre robuste aux erreurs de commande car elle permet d’éviter l’explosion combinatoire lors
de la vérification par model-checking des propriétés de sûreté et de fonctionnement. Une des
originalités de notre travail est d’avoir proposé une utilisation non bloquante du filtre de
commande à base de contraintes logiques, garantissant ainsi la sûreté de fonctionnement des
contrôleurs existants.
Dans le chapitre suivant, la méthodologie est appliquée au domaine spécifique des EALE.
Nous verrons comment elle a été mise en œuvre et quels outils ont permis l’aboutissement de
cette démarche.
Un exemple de la démarche de génération de la commande à base de contraintes sera donné

dans le chapitre 5, sur le problème concret du contrôle/commande des interrupteurs de mise
en parallèle (IMP) ayant les fonctions de déclenchement (DAP) et de refermeture automatique
des parallèles (RAP).
143
144
Chapitre 4 : Application de la méthodologie aux études
d’automatisation des EALE
4.1 Introduction
Le chapitre précédent a présenté une méthodologie originale pour les études d’automatisation
devant contribuer à une amélioration du métier des métiers d’études d’automatisation. Nous
avons montré que cette démarche est applicable à tout métier dont le système étudié peut être
divisé en Sous-ensembles de Partie Opérative (SePO) et dont l’architecture de
contrôle/commande est distribuée. Cette méthodologie a pour but de répondre aux
problématiques (humaines, techniques et économiques) énoncées dans le chapitre 1.
Deux axes de recherche ont été intégrés dans la démarche présentée en Figure 33 du chapitre
3. Ce chapitre traite de la première voie d’amélioration, à savoir, la démarche de
standardisation et de génération de livrables. Le second axe de recherche, la proposition d’une
commande sûre de fonctionnement sera traitée dans le chapitre 5.
Dans ce chapitre, le travail réalisé pour mettre en place la démarche de génération de code
orientée modèles, est présenté. A partir d’un métier standardisé, il est possible de générer des
livrables, dont la qualité doit être vérifiée et assurée. Pour s’assurer de la qualité du code, des
outils tels que PLC Checker, proposé par la société Itris Automation Square existent. Ils
permettent d’analyser le code API et de vérifier le respect de règles de programmation
établies. Lorsque le code est de qualité, il faut le formaliser. Pour cela il faut définir la
grammaire du langage de programmation. Enfin pour générer un code de qualité à partir de
modèles, puisque nous nous orientons vers la programmation à base de modèles, il faut définir
des modèles de la Partie Opérative (PO) mais également de la Partie Commande (PC) et
définir les associations qui lient ces deux parties du système. Pour englober ces travaux, deux
solutions ont été étudiées : le développement d’un outil spécifique et l’intégration d’une
solution industrielle existante. Les résultats de cette comparaison sont donnés et la solution
choisie est décrite. Les vues, les modèles, les templates de génération du code sont présentés.
Nous insistons à la fin de ce chapitre sur le cycle Agile mis en place pour le développement
de l’outil choisi et sur les conséquences que la solution développée a sur le workflow et le
métier des chargés d’études. Les résultats d’un questionnaire anonyme adressé aux chargés
d’études sont analysés à la fin de ce chapitre.
145
Chapitre 4 : Application de la méthodologie aux études d’automatisation des EALE
4.2 Analyse du système
Pour générer le code d’une application de contrôle/commande distribuée, il est nécessaire

d’étudier le système, sa décomposition et ses fonctions. Pour bien comprendre le
fonctionnement des sous-stations, nous avons suivi la réalisation d’un projet de
contrôle/commande d’une sous-station 25kV de sa conception jusqu’aux essais usine et site.
Cette étape nous a permis de comprendre le langage métier et les données d’entrée nécessaires
à la réalisation d’un projet. L’étude des principes mis en œuvre nous a également permis de
comprendre l’architecture de l’installation, sa décomposition mais également la structure du
contrôle/commande mis en œuvre dans le Système de Commande Locale et d’Automatismes
(SCLA). Dans cette section, les Sous-ensembles de Partie Opérative (SePO) et les Eléments
de Partie Opérative (ElPO) sont décrits d’après le schéma unifilaire d’une sous-station, qui est
la représentation principalement utilisée par les chargés d’études d’automatismes pour étudier
l’architecture du système (Figure 56). L’une des missions essentielles attachée à ce projet de
recherche a été la définition de fiches référentielles décrivant les fonctions des éléments
constituants les EALE permettant ainsi une standardisation complète du métier de chargé
d’études, nécessaire à la génération automatique de livrables. A chaque SePO correspond une
fiche référentielle qui reprend :
 la description de son rôle pour le système global,

 les ElPO qui le composent,
 les fonctions qui lui sont attribuées,
 la mise en œuvre de l’architecture de contrôle/commande associée,
 les défauts observés et les conséquences de ces défauts,
 les particularités de certaines fonctions ou commandes séquentielles.
146
Figure 56 : Schéma unifilaire de la sous-station de Commune (2x25kV)
Ce schéma décrit la Partie Opérative (PO) qu’il est nécessaire de décomposer en Sous-
ensembles de Partie Opérative (SePO) et en Eléments de Partie Opérative (ElPO).
Les paragraphes suivants reprennent le contenu des fiches référentielles et synthétisent les
informations pour décomposer et décrire le système étudié. Ainsi nous définissons les SePO
principaux d’une sous-station :
 Partie Haute Tension (HT)

 Groupe Traction (GT)
 Départ Traction (DT)
 Batterie de Condensateurs (Batt. K)
 Communs
Les SePO sont composés d’ElPO, dont voici une liste exhaustive. Chacun de ces types
d’ElPO peut être spécifié en fonction de la fonction qu’il doit remplir au sein d’un SePO
particulier. En effet, un ElPO peut apparaître dans deux SePO mais n’aura pas la même
fonction dans ces deux SePO. C’est pourquoi ils seront différentiés lors de l’analyse
147
structurelle du système (par exemple, le sectionneur de partie HT n’a pas la même fonction
qu’un sectionneur à rupture brusque (SRB) de GT) :
 Disjoncteur,
 Sectionneur,
 Transformateur en courant (Tc),
 Transformateur en Tension (Tt),
 Transformateur,
 Batterie de Condensateurs (Batt. K)
4.2.1 Partie HT
Cette partie haute tension est reliée au réseau haute tension RTE (entre 63kV et 400kV)
(Figure 57). Elle dépend du type de raccordement au réseau RTE (antenne, piquage, coupure
d’artère, double dérivation).
Figure 57 : Schéma unifilaire de la partie HT
Elle est composée à minima :
 D’un sectionneur (S11) délimitant la limite de propriété et d’exploitation entre RTE et

RFF. Il permet, entre autres, d’isoler l’arrivée RTE. Il peut être associé à un
sectionneur (ST11) permettant la Mise A La Terre (MALT) de l’arrivée RTE.
148
Suivant le type de raccordement, elle peut comporter également :

 Des disjoncteurs HT, associés à des réducteurs de mesures (Tc, Tt), situés directement
en aval de chaque sectionneur d’arrivée. Ils assurent la protection des équipements
avals.
 Un jeu de barres HT pour assurer la disponibilité de l’installation en commutant les
sources d’alimentation RTE indépendamment de l’exploitation des Groupes Traction.
Mise en œuvre de la Partie HT
Le schéma de la Figure 58 représente l’interface de contrôle/commande sur un exemple de

schéma HT maximaliste (2 arrivées RTE et 3 Groupes Traction). Afin d’assurer la
disponibilité du système, il convient de répartir le contrôle/commande des appareils dans
différents Abonnés Automate. La mise en œuvre SCLA décrite ci-dessous s’applique lors
d’un raccordement en antenne ou en piquage.
149
Arrivée Arrivée
HT 1 HT 2
3 AAi 3 AAj
RTE
RFN
SHT1 SHT2
CO/CF
Abonné Automate CO/CF
Arrivée HT i Abonné Automate
so/sf, Défauts Arrivée HT j
so/sf, Défauts
RLI tempos
RLI tempos DJHT1 DJHT2

RLI tempos
Abonné Automate
Commun k
SHT3 SHT4
Défauts
CO/CF
so/sf,
AAk
SBHT1 SBHT2
GT1 GT3 GT2
Figure 58 : Schéma de la partie Haute Tension pour un raccordement RTE en piquage ou en

antenne.
Dans le cas d’un raccordement RTE en coupure d’artère, la position des appareils est
récupérée par un unique Abonné Automate. Un transformateur en tension est positionné en
aval de chaque arrivée HT.
150
4.2.2 Groupe Traction
Le Groupe Traction a pour but de convertir la tension HT fournie par RTE en une tension
permettant l’alimentation des caténaires (25 kV, 2x25 kV).
Figure 59 : Schéma unifilaire d’un Groupe Traction avec commutateurs de phases
Il est composé à minima (Figure 59):

 D’un sectionneur bipolaire HT (le sectionneur bipolaire HT peut être mutualisé avec le
sectionneur d’arrivée HT amont, suivant le schéma d’alimentation défini.).
 Ou de sectionneurs unipolaires HT (CP10, CP14, CP18) permettant de choisir les deux
phases d’alimentation du transformateur de chaque Groupe Traction (commutateurs de
phases).
 D’un disjoncteur de GT (D1) associé à des réducteurs de mesures (Tc, Tt), situés soit
directement en aval du sectionneur bipolaire HT, soit directement en aval du
transformateur (par dérogation RTE). Il est également associé à un Tc Masse Cuve. Ils
assurent la protection du Groupe de Traction.
 D’un transformateur de puissance (T1), équipé de ses capteurs de surveillance
(Buchholz, Température (1 ou 2 seuils), Niveau d’huile, Surpression huile...).
 D’un sectionneur à rupture brusque (SRB1) 25kV ou 2x25kV.
151
Mise en œuvre GT
Le schéma de mise en œuvre (Figure 60) représente l’interface de contrôle/commande d’un

Groupe Traction. Les appareils du Groupe Traction sont contrôlés et commandés par
l’Abonné Automate du Groupe Traction correspondant, associé à sa protection.
Figure 60 : Schéma de mise en œuvre de l’architecture de contrôle/commande/protection du

Groupe Traction
Certains Groupes Tractions sont composés de sectionneurs de commutation de phases. Le

schéma ci-dessous présente la mise en œuvre de ces sectionneurs.
Mise en Œuvre d’un commutateur de phases
Le schéma de mise en œuvre (Figure 61) représente l’interface de contrôle/commande des

sectionneurs de commutation de phases d’un Groupe Traction. Les Sectionneurs de phases du
Groupe Traction sont contrôlés et commandés par l’Abonnée Automate du Groupe Traction
correspondant.
Figure 61 : Schéma de mise en œuvre de l’architecture de contrôle/commande des

commutateurs de phases
152
En cas d’arrivées HT par Groupe Traction, la limite de propriété RTE peut être située en
amont du sectionneur HT du GT. Celui-ci pourra être associé à un sectionneur de Mise A La
Terre (MALT) (Il n’y aura pas d’abonné automate Arrivée Haute Tension).
4.2.3 Départ Traction
Le Départ Traction a pour but de gérer l’alimentation et la protection des caténaires. En

général, deux départs traction alimentent les deux secteurs d’une même direction (Figure 62).
Figure 62 : Schéma unifilaire de deux Départs Traction
Le Départ Traction est composé :
 D’un disjoncteur de DT (DP1),

 De combinés de mesures/protections (Tt (TtcP1), Tc (TcfP1)),
 D’un sectionneur tête de câble (T1),
 Parfois d’un sectionneur de mise au rail (SMR), permettant le dégivrage de la
caténaire.
153
Deux Départs Traction alimentant les voies d’une même direction sont couplés par un
Sectionneur By Pass (SP) permettant l’alimentation du sectionneur tête de câble par le
disjoncteur de l’autre DT. La Figure 63 montre la mise en œuvre de deux départs traction
dans un abonné automate de départs traction correspondant, associés à deux protections.
Figure 63 : Schéma de mise en œuvre de l’architecture de contrôle/commande/protection d’un

Départ Traction
4.2.4 Batterie de Condensateurs
Le but de l’installation de batteries de condensateurs est d’optimiser le facteur de puissance de

l’installation, pour éviter les pénalités financières de RTE, et diminuer la demande de
puissance.
Figure 64 : Schéma unifilaire d’une batterie de condensateurs
154
La batterie de condensateurs (Figure 64) est composée :
 D’un disjoncteur de Batt. K (DK1),

 De combinés de mesures/protections (Tt (Tt), Tc (Tc et TcDiff)),
 D’un sectionneur de Batt. K (SK1) lié au sectionneur de MALT (STK1),
 D’une batterie de condensateurs (K1),
 D’une self.
La Figure 65 montre la mise en œuvre d’une batterie de condensateurs dans un abonné

automate commun qui n’est pas dédié à cette fonction mais devant être associé à une
protection.
Figure 65 : Schéma de mise en œuvre de l’architecture de contrôle/commande/protection

d’une batterie de condensateurs
4.2.5 Communs
Les autres éléments constitutifs d’une sous-station sont appelés communs. Le nombre
important de sous-stations, système complexe et évoluant dans le temps, est source de
particularités. C’est pourquoi ils sont regroupés dans les fonctions communes de l’installation.
Néanmoins, certaines fonctions de ces communs peuvent également être intégrées dans des
SePO : barre 25kV, pontage…
155
4.2.5.1 Barre 25kV
La barre 25kV assure la disponibilité de l’alimentation électrique en permettant l’exploitation

par demie-sous-station (un GT alimente les DT sous-jacents) et permet également d’isoler un
défaut (Figure 66).
Figure 66 : Schéma unifilaire d’une barre 25kV
Elle est composée de sectionneurs de barre 25kV (SPL1 et SPL2), positionnés entre chaque
GT.
4.2.5.2 Pontage
Les pontages permettent une alimentation secours en assurant la liaison électrique de deux
secteurs contigus normalement isolés par lame d’air (Figure 67). Cette exploitation en mode
dégradé peut avoir lieu lorsqu’un Départ Traction est en défaut.
Figure 67 : Schéma unifilaire de deux pontages (un pontage par voie)
Un pontage est composé :
 D’un sectionneur de pontage (P1),

 Suivant l’architecture du pontage, d’un sectionneur médian (SM1) qui peut être en
série ou en parallèle avec P1.
156
Pour chaque SePO décrit (HT, GT, DT, Communs), un type d’abonné automate est dédié.
Cette première étape d’analyse permet d’aborder l’étude des programmes en considérant la
structure du système. La qualité du code des programmes actuels est étudiée dans la section
suivante. Les programmes actuels sont utilisés depuis 1998, année de première utilisation de
l’API actuellement utilisé par la SNCF, l’ACS21. Bien que ces programmes n’aient jamais
entrainé de problèmes de contrôle/commande, ils n’ont pas cessé d’évoluer depuis 1998. C’est
pourquoi nous avons proposé d’évaluer leur qualité et leur niveau de standardisation. En effet,
les programmes sont réalisés par les chargés d’études, chacun ayant sa propre façon de
programmer. Les programmes initiaux ont donc subi de nombreuses mutations. Comme
proposé dans la méthodologie, les programmes API ont été homogénéisés et des règles, de
nommage par exemple, ont été établies, pour que tous les programmes puissent être lisibles
par l’ensemble des chargés d’études. Cette analyse des programmes mènera ensuite vers
l’analyse structurelle du système (PO) et de la Partie Commande (PC).
4.3 Standardisation et analyse du code
Dans le but de réaliser des programmes API seins, il convient d’examiner en détail le code
réalisé actuellement. Ce travail se décompose en trois phases.
Dans un premier temps, les principes de commande mis en œuvre sur le système sont étudiés
afin de comprendre le fonctionnement de ceux-ci. La partie commande doit être étudiée pour
comprendre comment elle est distribuée, comment les fonctions sont implémentées et
comment se font les échanges d’informations.
Etant donné l’aspect séquentiel important du système étudié, une phase d’étude des
GRAFCETs et des programmes SFC est indispensable pour comprendre leur évolution. Cette
étude minutieuse de reverse engineering, mise en relation avec l’étude préalable des principes
d’automatisation et l’étude fonctionnelle du système, permet de vérifier la cohérence du code
en plus des règles de codage utilisées dans le contrôle/commande des EALE. Les programmes
existants sont écrits par l’ensemble des chargés d’études, dont l’expérience en programmation
API est différente. Le code produit par chacun d’eux est par conséquent différent. Au travers
de cette étape, les bonnes pratiques du métier doivent être définies pour être intégrées dans les
templates de génération.
157
Enfin la dernière étape consiste à utiliser un outil permettant de vérifier les règles d’écriture
des programmes. Cet outil, très développé dans le milieu logiciel, nous a permis de mettre en
évidence des règles précises de codage et de définir de nouvelles règles spécifiques au
domaine des EALE. En effet PLC Checker de la société ITRIS Automation Square (cf.
chapitres 2 et 3) est un outil d’analyse qualimétrique du code adapté aux API. Basé sur la
norme (ISO 9126, 2001), il analyse les programmes et génère un rapport décrivant les règles
non respectées des programmes API.
4.3.1 Etudes des principes d’automatisation des EALE
La section précédente a présenté l’analyse du système et sa décomposition en SePO et ElPO.

Pour chaque SePO présenté, un API est associé. L’architecture de contrôle/commande des
EALE a été détaillée dans le chapitre 1. Pour chacun de ces types d’abonné, une analyse
rigoureuse est donc nécessaire. Les programmes contenus dans un abonné de DT, GT, Batt.K,
Partie HT ou de Communs sont différents. Pour ne pas diverger de l’objectif de cette section,
les résultats présentés dans la suite concerneront l’abonné GT.
L’un des objectifs de cette étape, est également de croiser les différentes réalisations afin de
mettre en évidence les divergences entre chaque projet. Les EALE étudiés par la direction de
l’ingénierie sont répartis sur l’ensemble du territoire français. Selon les régions, les règles de
maintenance peuvent évoluer de manière différente, le matériel peut également avoir évolué
ainsi que les principes d’exploitation qui leurs sont liés et des différences existent. Cette
dimension géographique, corrélée à l’évolution temporelle du système, dont les éléments sont
amenés à changer régulièrement en fonction des appels d’offre produit, explique l’existence
de divergence entre les programmes.
4.3.2 Etude minutieuse des programmes pour la standardisation
Les programmes étant réalisés par l’ensemble des chargés d’études, d’un programme à
l’autre, les variables ne sont pas nommées de la même manière, la casse des variables peut
être modifiée et les abréviations au sein des variables ne sont pas normalisées. Des règles de
nommage doivent donc être définies. Exemple : imaxGT ou ImaxGT ou iMaxGT pour
maximum d’intensité du Groupe Traction.
158
Les règles de casse permettent de savoir comment lire une variable, des règles d’abréviations
peuvent définir la décomposition du nom de chaque variable, en définissant un nombre de
caractères attribués à chaque partie composant le nom de la variable. Exemple : DeclDegiv ou
DecDegiv pour déclenchement dégivrage.
Dans le programme d’acquisition des TSS (AcquiTSS), les entrées observées en direct et en
inverse ne sont pas séparées. Les entrées observées en direct sont alimentées lorsqu’un signal
est reçu par l’API alors que les entrées observées en inverse sont alimentées lorsque le signal
disparaît. Ainsi, les informations sécuritaires sont envoyées en inverse, ainsi elles reçoivent
un signal en continu tant qu’il n’y a pas de défaut. L’apparition d’un défaut ou une défaillance
du système entraine la coupure du signal et le repli du système concerné dans un état de
sécurité, généralement le défaut entraine l’ouverture du disjoncteur associé. Ce mélange
d’informations sécuritaires et non sécuritaires peut porter à confusion lors de la lecture des
programmes. Une distinction permettrait de mettre en évidence directement les variables
sécuritaires.
Dans les programmes SFC, d’aiguillage et de commande des appareils, la complémentarité

des transitions dans les divergences en OU doit être vérifiée de manière approfondie. En effet
s’il y a une priorité de transition, alors le programme séquentiel évoluera forcement vers la
transition à gauche si les deux conditions sont vraies, ce qui est possible si les transitions ne
sont pas complémentaires.
Cette étude minutieuse peut également mener à la détection de simplifications possibles de

programmes, voir à la détection d’erreurs dans certains programmes. Par exemple, dans le
programme « loca_def » des départs traction 25kV, la construction de la variable REF2 peut
être simplifiée: REF2 = ( def_zone3_1 + def_zone3_1 . def_zone4_1 + def_zone4_1 ) . (…)
est simplifiable en : REF2 = ( def_zone3_1 + def_zone4_1 ) . (…)
4.3.3 Analyse des résultats PLC Checker
Dans ce paragraphe, les résultats obtenus par l’analyse effectuée avec PLC Checker sont
discutés. Nous avons vu dans le paragraphe 4.2 (Analyse du système) qu’il existe plusieurs
types d’abonnés automates en charge de fonctions différentes. Afin d’obtenir des résultats
cohérents et représentatifs de l’existant, des programmes maximalistes pour les différents
159
types d’abonnés ont été testés, c'est-à-dire qu’ils comprenaient toutes les options et fonctions
existantes :
 Une application API maximaliste de Groupe Traction,

 Une application API maximaliste de Départ Traction,
 Une application API maximaliste de Commun, comportant une Batterie de
Condensateurs.
Pour que l’analyse de ces programmes soit la plus juste possible, les programmes standards
maximalistes ont été écrits à partir du code des applications d’une vingtaine de projets
existants et en service. L’intérêt de tester des programmes maximalistes est que toutes les
options, toutes les fonctions et tous les cas sont traités. Ainsi, lorsque les templates seront
écrits, à partir de ces applications maximalistes, il faudra conditionner certaines fonctions
selon la structure des configurations ou certaines entrées/sorties de ces fonctions. Au total, au
travers des trois applications standards réalisées, ce sont environ 21 000 lignes de code qui ont
été testées. Pour chaque remarque rapportée par PLC Checker, l’évolution ou non des
programmes est justifiée.
Les remarques les plus récurrentes dans l’analyse des résultats sont les règles de commentaire.
Les commentaires doivent être homogénéisés et complétés dans l’ensemble des programmes.
Il est donc inutile de s’attarder sur cet aspect. Il est considéré comme essentiel à la
maintenabilité des programmes et donc pris en compte.
L’information I2 (commentaire contenant du code) ne doit plus apparaître après correction

des programmes. En effet pour générer un code optimisé, les commentaires doivent être
soignés et le fait qu’ils contiennent du code peut être source de confusion.
L’information I5 définit la complexité cyclomatique de chaque élément des GRAFCETs

(étapes et transitions). Le nombre cyclomatique donne une information relative à la
complexité d’une routine. Il est important que le nombre cyclomatique reste raisonnablement
bas. Dans les programmes, la majorité des éléments des GRAFCETs ont une complexité
cyclomatique inférieure ou égale à cinq. Pour accepter la complexité cyclomatique d’un
programme, il faut que les différents chemins empruntés par celui-ci puissent être testés.
Chaque cas doit être vérifié d’après le cahier de recette, prenons un exemple :
160
 Dans les aiguillages des appareils, l’étape de contrôle en local individuel a une
complexité cyclomatique de 10 :
if (liAPP1 > 1) then AnoLDI:=TRUE;

end_if;
if not(defautCarte) then
if((cfindAPP1=1) AND (coindAPP1=0)) then
cfAPP1 := TRUE;
coAPP1 := FALSE;
else if((cfindAPP1=0) AND (coindAPP1=1)) then
cfAPP1:=FALSE;
coAPP1:=TRUE;
else if((cfindAPP1=0) AND (coindAPP1=0)) then
cfAPP1:=FALSE;
coAPP1:=FALSE;
else
cfAPP1 := false;
coAPP1 := false;
AnoLDI:=TRUE;
end_if;
end_if;
end_if;
else
cfAPP1 := false;
coAPP1 := false;
end_if;
solAPP1 := soAPP1;
sflAPP1 := sfAPP1;
sodAPP1 := false;
sfdAPP1 := false;
Le code écrit dans cette étape ne peut pas être simplifié. En effet, l’affectation des variables
dépend des différents cas traités afin d’assurer la bonne prise en compte de la commande
souhaitée. Dans le cahier de recette, le contrôle/commande des appareils en local individuel
est testé selon son passage local (ldi), la commande envoyée (co/cf), la signalisation reçue
(so/sf). En considérant chaque cas et son inverse, la complexité cyclomatique de 10 est
atteinte et n’est donc pas gênante, étant donné que tous les cas sont testés.
 Le GRAFCET de commande des appareils a une complexité cyclomatique de 9.

Cependant il s’agit là de la complexité du GRAFCET global. Cela ne constitue pas
une tâche effectuée par l’automate à chaque cycle.
161
L’information N2 liste les variables et les programmes ayant un nom de moins de quatre
lettres. Les variables peuvent alors ne pas être explicites (Tableau 6).
Tableau 6 : Variables ayant un nom trop court

Variable Commentaire
LG Local Général
TCO Généralisation entre CLE et TCO
LDI Un appareil en commande Local Individuel
IGT Courant du GT renvoyée par la protection en modbus
UGT Tension du GT renvoyée par la protection en modbus
Le nom de ces variables fait partie du vocabulaire métier, leur présence dans les programmes
ne gêne pas la lecture.
La règle S12 indique les programmes où une structure conditionnelle de type « if then else »
n’a pas de cas par défaut. Ce problème ne risque pas d’entrainer de blocage sur le cycle
automate.
La règle S2 indique les variables qui sont écrites depuis plusieurs programmes. Dans les
applications API, les sorties sont toujours écrites dans le programme SFC de commande des
appareils ou dans le programme de mise à zéro de toutes les sorties. L’aspect séquentiel des
programmes est responsable de cette multi-écriture. Cependant, elle ne peut se produire au
cours d’un même cycle. Le programme SFC d’aiguillage des appareils est responsable de
l’écriture multiple des variables de signalisation distante et locale. Mais cette écriture est
nécessaire pour le choix du contrôle des appareils.
L’information S7 liste les variables n’étant pas utilisées dans les programmes. Un grand
nombre de variables apparaissent ainsi comme non utilisées, ceci est dû à une volonté de
standardisation des variables dans les programmes. Ainsi, d’un programme à l’autre, les
mêmes variables existent même si elles ne sont pas utiles dans le programme original, en cas
de modification, elles peuvent être utilisées par la suite. Cela évite aux chargés d’études de
devoir réécrire les variables dans le dictionnaire, le commentaire et l’adresse. Bien que cette
pratique soit compréhensible, vue la méthode de travail actuelle, les variables non utilisées
devront disparaître lorsque les programmes seront générés.
162
A partir des analyses qui viennent d’être présentées, un retour d’expérience sur la qualité des
programmes est obtenu. Les remarques remontées n’ayant pas de justifications valables
doivent être corrigées. Un code de qualité est alors obtenu à la fin de cette méthode et des
règles d’écriture du langage métier ont pu être définies (Figure 37).
Le code de qualité obtenu peut maintenant servir de template dans la suite de la démarche.
Les templates doivent être formalisés afin d’avoir une structure de référence permettant
d’éviter les erreurs de structure dans le fichier source. La prochaine section présente le
formalisme d’IsaGraf3.32, utilisé pour programmer l’ACS21, API pour le contrôle/commande
des EALE.
4.4 Formalisme des langages
Pour générer le code d’une application, il est nécessaire d’avoir un format d’import/export des
programmes lisibles dont la structure est formalisable. Ce format est généralement disponible
en XML dans la plupart des Interfaces de Programmation d’Applications (IPA). C’est le cas
d’Unity Pro, l’atelier de Schneider Electric ou encore de Straton, l’atelier de COPALP.
Malheureusement ce format d’import/export n’existe pas dans IsaGraf 3.32. IsaGraf 6, le
nouvel atelier proposé par ICS Triplex, est compatible avec IsaGraf 3.x et propose un format
XML d’import/export. Toutefois, la version actuelle d’IsaGraf 6 ne gère pas le langage SFC
en compatibilité de projet IsaGraf 3.x. Il a donc fallu trouver une autre solution pour générer
les programmes actuellement réalisés par la SNCF sous IsaGraf 3.x.
4.4.1 Structure de fichiers IsaGraf 3.32
Heureusement, les fichiers sources d’IsaGraf 3 sont lisibles. Pour chaque automate, un dossier
est créé dans le répertoire projet, par défaut dans le répertoire IsaGraf : C:\ISAWIN. Ce
dossier contient des fichiers textes lisibles selon l’architecture décrite dans le Tableau 7.
163
Tableau 7 : Récapitulatif des fichiers textes du dossier d’un abonné automate
Nom du fichier Contenu du fichier

Appli.txt Description du programme API (auteur, date, réf…)
Appli.300 Inclusion des timers
APPLI.CNX Définition de la configuration matérielle
APPLI.DRV Définition de l’adressage des variables d’entrées/sorties
APPLI.DLO Dictionnaire des variables booléennes
APPLI.DCO Dictionnaire des variables entières et réelles
APPLI.DTE Dictionnaire des temporisations (timer)
APPLI.HIE Fichier application IsaGraf, contient l’ordre d’appel des sous-
programmes automates
APPLI.HIS Fichier d’historisation des versions, sauvegardes et copies
APPLI.HIT Fichier contenant les commentaires associés aux sous-programmes de
l’automate.
APPLI.IDT Identifiant du programme API : Automate n° projet
$Prog$.LSF Fichier contenant le code du sous-programme $PROG$ inclus dans le
programme API.
Chacun de ces fichiers suit une structure particulière. Pour illustrer nos propos, la structure du
dictionnaire de variables et celle des sous-programmes API sont présentées dans les
paragraphes suivants. Ces structures particulières forment la grammaire de l’IPA. Cette
grammaire est détaillée pour chaque fichier source présenté.
4.4.2 Grammaire du fichier source du dictionnaire
Le dictionnaire de variables est divisé en sous-catégories :
 Dictionnaire des variables booléennes : Appli.DLO

 Dictionnaire des variables entières et réelles : Appli.DCO
 Dictionnaire des temporisations : Appli.DTE
Ces fichiers contiennent toutes les variables définies dans l’application. Pour chaque variable,
une ligne est écrite selon la grammaire suivante :
#B[1]%+[adresseVariable]%[NomVariable]%%%[CommentaireVariable]
[Si la variable a une valeur initiale ; =[ValeurInitiale] ;]
Le #B de l’exemple ci-dessous est utilisé pour les variables booléennes. Pour les variables
entières et réelles, la ligne commence par #A, pour les temporisations, la ligne commence par
#T.
164
4.4.3 Grammaire du fichier source d’un sous-programme
Pour chaque langage de programmation de la norme IEC 61131-3, une grammaire propre à
IsaGraf 3 existe.
Pour les langages textuels, tels que le Structured Text (ST) ou le Instructions List (IL), la
grammaire est celle du langage de programmation même. Il n’y a pas de grammaire
supplémentaire outre celle imposée par le langage de programmation.
La grammaire spécifique est présente pour les langages graphiques de la norme (IEC 61131-3,
2003). Ainsi, les grammaires des langages Ladder Diagram (LD), Function Block Diagram
(FBD) et Sequential Function Chart (SFC) doivent être définies. A titre d’exemple, la
grammaire du langage LD est présentée dans le paragraphe suivant.
4.4.4 Grammaire du fichier source d’un sous-programme Ladder Diagram
Le Ladder Diagram est un langage graphique dont l’idée initiale est la représentation de
fonction logique sous la forme de schémas électriques. Ce langage se lit rung par rung.
Chaque rung est composé des éléments suivants :
 les entrées (ou contacts), pour lire la valeur d'une variable booléenne :
Tableau 8 : Type de contact

Symbole Type de contact Grammaire
Direct XIC [[positionY],[positionX]] (*variable*) (*Commentaire*)
Inverse XIO [[positionY],[positionX]] (*variable*) (*Commentaire*)
Front montant XIP [[positionY],[positionX]] (*variable*) (*Commentaire*)
Front descendant XIF [[positionY],[positionX]] (*variable*) (*Commentaire*)
165
 les sorties (ou bobines), pour écrire la valeur d'une variable booléenne :
Tableau 9 : Type de bobine

Symbole Type de bobine Grammaire
Direct OTE [[positionY],[positionX]] (*variable*) (*Commentaire*)
Inverse OTO [[positionY],[positionX]] (*variable*) (*Commentaire*)
Mise à 1 OTS [[positionY],[positionX]] (*variable*) (*Commentaire*)
Mise à 0 OTR [[positionY],[positionX]] (*variable*) (*Commentaire*)
 les blocs fonctionnels pour réaliser des fonctions avancées :
Tableau 10 : Type de Bloc fonctionnel

Symbole Grammaire
FB [[positionY],[positionX]] (*NomBloc*) (**) ( (*en*)(**)
(**) , (*IN*)(*NomVarIN*) (**) ; (*eno*)(**) (**) ,
(*Q*)(*NomVarQ*) (**) )
Dans chaque rung, un élément a une position horizontale (positionX) et une position verticale
(positionY) dont le point d’origine est le début du rung.
Un rung commence toujours par son commentaire et l’ouverture du rung :
(*Commentaire*)
SOR [0,[ligneDuRang]] (**) (**)
Il se finit par :
EOR [4, [ligneDuRang]]
La ligne du rung permet d’identifier chaque rung par sa position.
Lorsqu’un élément est mis en parallèle d’un autre, l’instruction BST est mise avant l’élément
de la première ligne et l’instruction NXB devant l’élément de la ligne du dessous.
L’instruction BND permet de finir la mise en parallèle d’une ligne.
166
Exemple :
Figure 68 : Programme LD : exemple de l’ouverture de l’IMP par manque tension
Le rung graphique écrit en LD ci-dessus (Figure 68) se traduit par :

(*Ouverture IMP 1 sur manque tension*)
SOR [0,4] (**) (**)

BST XIC [1,0] (*VA9*) (**)
NXB XIC [1,1] (*VA10*) (**)
BND
XIO [2,0] (*AutoIMP1HS*) (**) OTE [3,0] (*OoIMP1*) (*ordre ouverture *)
EOR [4,0]
Cet exemple montre l’importance de la définition de la grammaire du langage. Pour pouvoir

générer ce type de fichier dont la structure peut être complexe, il faut comprendre comment le
générer, c’est pourquoi la génération basée sur les IPA s’intègre dans la démarche proposée
(Figure 69).

l’Interface de Programmation
167
Pour écrire les templates, sur la base de la grammaire de l’IPA, il est nécessaire d’intégrer
également les méta-modèles et les modèles de PO et de PC. La prochaine section décrit de
manière non exhaustive les méta-modèles et les modèles réalisés sur les sous-stations 25kV.
4.5 Définition de la structure du modèle
Dans le chapitre 3, les méta-modèles et modèles pouvant être adaptés à tout système
automatisé ont été présentés. Dans ce chapitre, pour poursuivre la présentation de la
démarche, les modèles d’une sous-station 25kV sont présentés ainsi que leur cohérence avec
les méta-modèles. Lors de la phase de modélisation, il est nécessaire de savoir dans quel but
le modèle est réalisé, pour cela des données d’entrées ont été définies dans le chapitre 3.
De cette analyse structurelle découlera l’ensemble des liens entre les objets du système.
Lorsque les templates seront écrits, pour la génération du code d’un élément, si cet élément a
un lien avec un autre élément du système, cet élément doit être accessible. La principale
relation observable dans les modèles est la composition, qui permet d’accéder à n’importe
quel élément du système en remontant les parents d’un élément puis en redescendant vers
l’élément recherché.
4.5.1 Méta-modèle et modèle de PO
La PO (Figure 70) peut être décomposée en sous-ensembles de Partie Opérative (SePO) en

fonction du rôle ou des tâches à effectuer de ces sous-ensembles. Chaque SePO est composé
d’éléments de Partie Opérative (ElPO), que forment les objets du système réel. Un type
d’ElPO ne peut être contenu que dans un type de SePO. Cette décomposition forme le méta-
modèle du système qui doit être respecté par le modèle du système.
168
Partie Opérative
*
SePO
*
ElPO
Figure 70 : Méta-modèle de la Partie Opérative
Pour commencer, la sous-station, qui est notre PO, est décomposée en SePO. L’analyse du
système a permis d’établir les sous-ensembles qui constituent une sous-station 25kV (Figure
71). La sous-station 25kV est composée de n éléments Communs, d’un à quatre Départs
Traction (DT), d’un à trois Groupes Traction (GT), de zéro à deux Batteries de Condensateurs
(Batt. K) et d’une Partie HT.
Sous-station
1 11 1 1 1
1
1
1
1
* 1..4 1..3 0..2 1

Communs DT GT Batt. K PartieHT
Figure 71 : Modèle d’une sous-station 25kV
Chacun de ces SePO peut être décomposé en ElPO. Le chapitre 3 a également traité du lien
entre PO et PC (Figure 72). Chaque SePO et ElPO défini doit être associé à un API et à des
E/S de cet API.
169
4.5.2 Modèle d’associations entre PO et PC
Le modèle simple présenté dans le chapitre 3 a été enrichi afin d’obtenir un modèle de
connexion adapté à notre système. Créer des liens de plus bas niveau entre la PO et la PC
permet de parcourir facilement les connexions E/S et facilite l’écriture des templates.
Base
1 1
1
1
*
*
Partie Commande Partie Opérative
1 1
1 1
*
*
API SePO
1 1
1
1 1
*
ElPO
*
Module E/S 1..*
Carte 16 TSS Carte 4 TCD/TSD Appareil
1 1..4
1 1 1
*
16 8 8
16
Entrée Sortie Information
1
1
Figure 72 : Méta-modèle des connexions entre PO et PC
Les SePO doivent, autant que possible, se rapprocher d’une fonction attribuée à un API du
système de contrôle/commande distribué. En effet, le contrôle/commande des sous-stations
25kV a été étudié pour assurer la disponibilité de l’installation. Outre les appareils communs,
chaque SePO est contrôlé et commandé par un abonné (API) spécifique.
170
4.5.3 Modèles des SePO
Les sous-stations fiabilisées sont composées à minima de deux GT et donc de deux abonnés
automates GT (AAGT). Chaque SePO renvoie des informations vers la PC. Les informations
comprennent également les défauts et sont câblées aux TSS. Les SePO sont composés
d’appareils connectés sur les cartes 4TCD/TSD. Chaque carte 4TCD/TSD peut contrôler et
commander 4 appareils.
Le modèle d’un GT est détaillé en Figure 73. Les modèles des autres SePO sont disponibles
en annexe 2.
1
11 GT AAGT
11 1 1
1 1
1 1 1 1
1
1 1 1
*
*
*
1 0..3 0..1
*
1 1 1 1
Protection Sect. Phases Sect. HT Dj GT Transfo. SRB Information
Figure 73 : Modèle d’un Groupe Traction
Le Groupe Traction est composé d’une partie supérieure (HT) qui se traduit par la présence
d’un sectionneur HT ou de trois sectionneurs (commutateurs) de phases ou d’aucun appareil
HT. Le GT possède un disjoncteur (Dj GT), un sectionneur à rupture brusque (SRB), une
protection et un transformateur. Il renvoie également des informations vers son abonné
(AAGT) dédié.
La PO, les SePO et les ElPO sont des objets instanciables ayant des attributs et des méthodes.
Pour chacun, il faut recenser les variables qui le caractérisent. Ces attributs et ces méthodes
permettront de définir des comportements différents selon leur valeur lors de l’étape de
génération de code. Il est donc nécessaire de porter un grand intérêt à cette étape. Celle-ci ne
peut se faire sans une connaissance approfondie du système. L’intervention des experts du
domaine spécifique est donc indispensable pour cette étape. Ils connaissent les paramètres, les
options et les différences possibles de chaque SePO et ElPO.
Chacun d’eux peut être instancié et possède des caractéristiques spécifiques. Ces
caractéristiques et le méta-modèle décrit sont utilisés pour définir les templates de génération
171
de code. La section suivante présente la solution de génération de code qui a été choisie par
rapport à une solution de développement interne.
4.6 Génération de code et documents
Maintenant que la grammaire de l’IPA IsaGraf 3 a été définie, que les modèles sont assez
évolués pour intégrer les compositions d’éléments, les liens entre chacun et les associations
existantes, il est nécessaire de choisir un environnement de développement du projet. En effet
l’écriture des templates dépend de la solution choisie et du langage de programmation de la
solution. Deux solutions permettant la génération de livrables ont été techniquement et
économiquement analysées.
4.6.1 Choix d’une solution pour la génération de livrables
Pour réaliser le logiciel de génération de livrables, deux solutions ont été explorées :
 La réalisation de ce logiciel en interne, par des services compétents de développement

logiciel de la Direction de l’Ingénierie.
 L’utilisation de logiciels déjà existants et pouvant être appliqués aux exigences
métiers sous forme d’un progiciel adapté. La solution retenue (cf. chapitre 2) est Odil,
logiciel de génération proposé par la société Prosyst (qui sera présenté en détail dans
la section suivante).
Les avantages et les inconvénients des deux solutions ont été étudiés dans la limite des
connaissances disponibles lors de l’étude. Les deux solutions ont été évaluées par les
responsables de la section Conception et Expertise des Systèmes (CES2) en charge des
installations de contrôle/commande des EALE, selon les critères suivants :
 Maîtrise : facilité de prise en main de l’architecture du logiciel, du développement, du

débogage et à terme, de prise en main du code source.
 Evolution : facilité de modification des standards, des modèles, des cibles de
génération.
 Risques : Aboutissement du projet, collaboration, partage du savoir-faire, santé de
l’entreprise.
172
 Coûts : de développement, de maintenance, d’évolution des templates ou des cibles de

génération.
 Livrables : possibilité de génération des programmes, du cahier des charges, de la liste
du matériel, des cahiers de recette…
L’évaluation des solutions a mené au diagramme présenté en Figure 74. Le détail de l’analyse
est disponible en Annexe 3.
Figure 74 : Graphique des résultats comparés
Que le logiciel soit développé en interne ou externe, il ne pourra pas être développé au sein de
la section des chargés d’études. Les compétences requises pour le développement d’un tel
outil dépassent notre cadre de travail. Le code source du logiciel ne pourra pas être modifié en
interne à cause du niveau d’expertise nécessaire au développement de celui-ci.
La propriété des sources est un avantage pérenne qui a pour inconvénient de devoir
disponibiliser des ressources spécifiques et rares dans l’entreprise. Cet inconvénient n’est pas
source de pérennité à cause de la dépendance envers cette ressource couteuse.
Le risque d’entreprise est différent dans les deux cas. Prosyst est responsable de la
maintenance du logiciel Odil. Une équipe est dédiée à ce travail. Le risque vient uniquement
de sa santé économique. Alors qu’un développement en interne aurait pour risque, le manque
de partage de la conception du logiciel. En effet celui-ci serait réalisé par un développeur qui
serait seul à connaitre le code source. La pérennité du logiciel ne dépendrait alors que de lui.
173
L’évolution des templates dépend du savoir-faire métier. Elle doit donc être réalisable par la
section des chargés d’études (CES2). Les modifications seront effectuées sur le progiciel
spécifique SNCF, sans avoir à modifier le code source du logiciel. Le cœur du logiciel
permettant la génération de code n’a pas de lien direct avec le métier d’IGTE, les évolutions
de cette partie doivent être réalisées par des informaticiens compétents au travers d’un contrat
de maintenance évolutive et corrective.
Prosyst a l’avantage de connaître le domaine de l’automatisation. Ses ingénieurs ont une

expérience des contraintes liées à la sécurité et à la fiabilité des programmes et de certaines
installations (photovoltaïque, nucléaire…). Cette considération n’est pas forcément partagée
par les développeurs informaticiens n’ayant pas l’expertise du métier. Les livrables générés
seront plus nombreux avec l’appui du savoir-faire de Prosyst.
Une étude financière a été menée pour comparer les deux solutions, le Tableau 11 présente les
résultats de l’étude (Annexe 4). Le tableau ci-dessous présente la synthèse des coûts de
développement annuels de chaque solution dans le but d’avoir une comparaison aisée de
celles-ci.
Tableau 11 : Synthèse de coûts de développement et de maintenance des solutions

Synthèse des coûts annuels des Total des coûts Total des coûts
Solutions de prestation de de
développement développement
d’Odil interne
GREMLINS
2013 88,5k€ + 4 mois 6 à 8 mois
2014 30,5k€ + 4 mois 133k€ + 1 mois
2015 33k€ + 3 mois 133k€ + 3 mois
Production
2016 90k€ + 4 mois
2017 Production
Coûts de Développement
Coût de développement des solutions 152000€ 356000€
(en euros + heures) + 11 mois + 16 mois
Coût de développement des solutions 284880 539280
(en euros)
Coûts de Maintenance
Coût d'exploitation et de maintenance 33k€ + 2 mois 90k€ + 2 mois
en production (en euros + heures)
Coût d'exploitation et de maintenance 57160 114160
en production (en euros)
174
Pour convertir les mois en valeur monétaire dans le Tableau 11, nous utilisons le nombre
d’heures travaillées par mois : 151h au tarif horaire d’un bureau d’étude : 80€. La synthèse de
l’étude financière montre que l’intégration de la solution Odil au sein de notre démarche
permet de limiter les coûts de développement logiciel. Ce qui parait cohérent puisque cette
solution se base sur une structure logicielle déjà existante qu’il est possible d’adapter en
décrivant le métier ciblé au travers d’un standard, comme il sera expliqué dans la suite de ce
chapitre.
La solution Odil offre une robustesse et une garantie de stabilité de l’environnement

de travail. Son architecture intégrant le progiciel SNCF permet une grande flexibilité par
rapport aux besoins exprimés par la SNCF. Dans le cadre de ce projet, la solution Odil a été
retenue. Dans la prochaine section, l’entreprise Prosyst et la solution Odil sont présentées.
4.6.2 Odil GREMLINS
Le progiciel développé pour les études de contrôle/commande des EALE a été baptisé
GénéRateur Evolutif du Modèle et des LIvrables des Nouvelles Sous-stations (GREMLINS)
Le progiciel intègre les vues suivantes :
 Une vue de Description de la Partie Opérative intégrant un arbre de description des

éléments. Deux sous-vues sont disponibles :
o Une vue graphique dans laquelle il est possible d’intégrer les différents
éléments d’une sous-station par « Drag and Drop » (glisser et déplacer) (Figure
75). Les propriétés des SePO et des ElPO sont modifiables dans la fenêtre
située en bas à gauche de l’interface. Les propriétés peuvent entrainer des
modifications au niveau graphique (ex : les départs sont différents en fonction
de la propriété simple DJ ou double DJ). La vérification de la cohérence par
rapport au modèle du système assure aux chargés d’études qu’il a
complètement décrit l’installation du point de vue PO.
175
Figure 75 : Vue de description de la Partie Opérative
176
o Une vue des défauts de chaque SePO, dans laquelle les chargés d’études
activent ou désactivent les défauts liés aux SePO de leur projet. La Figure 76
présente les défauts associés à un Groupe Traction.
Figure 76 : Vue de définition des défauts d’un Groupe Traction
177
 Une vue Architecture SCLA intégrant l’architecture de contrôle/commande du

système. Plusieurs sous-vues sont disponibles pour que les chargés d’études puissent
modifier l’architecture SCLA proposée.
o Une vue récapitulative pour chaque abonné automate (AARTU, AAGT,
AADT, AACom..), des connexions des informations sur les entrées des cartes
16 TSS et des connexions des appareils sur les sorties des cartes 4 TCD/TSD.
Une connexion par défaut de chaque ElPO est initialement définie mais il est
possible de modifier cette connexion automatique (Figure 77).
Figure 77 : Vue de synthèse par abonné (TCD/TSD, TSS, paramètres)
178
o Une vue de connexion des cartes E/S est créée pour chaque carte. Ces vues
permettent de connecter les TCD/TSD aux appareils et de connecter les TSS
aux défauts. La Figure 78 montre l’interface de connexion des appareils, celle
de connexion des défauts est équivalente.
Figure 78 : Vue de connexion des appareils sur une carte 4TCD/TSD
La vue SCLA permet de répartir les entrées/sorties de chaque SePO sur l’abonné automate
associé (Figure 79). Les abonnés communs doivent être ajoutés manuellement en fonction des
données d’entrées des chargés d’études. Un câblage automatique est alors proposé, respectant
les règles de disponibilité du système. Cette répartition peut être modifiée manuellement par
les chargés d’études pour chaque projet. Un contrôle de cohérence est effectué sur
l’association des appareils aux TCD/TSD et sur l’association des défauts et des informations
aux TSS.
179
Figure 79 : Vue de description de l’architecture SCLA
 Une vue API permettant de vérifier que toutes les propriétés des SePO et ElPO ont été
correctement complétées.
180
 Une vue documentation intégrant les différents documents générés. La liste du

matériel générée n’est pas visible à partir du logiciel, mais elle est générée
automatiquement à l’export. Pour les documents Word, Odil GREMLINS intègre le
logiciel Microsoft Word. Il est possible de voir directement les documents générés. Le
chapitrage et les pages correspondent à chaque élément du projet. En effet, les pages
générées par document, sont différentes en fonction de la structure de l’installation. Il
est possible d’effectuer des modifications manuelles sur les documents qui seront alors
enregistrées pour le projet. Les pages générées à la base sont des prototypes associés
aux SePO et les ElPO. Pour chaque document, une vue est créée :
o Synthèse des télécommandes (TC) et télésignalisations (TSS) envoyées au
CSS (la Figure 80 montre la génération de la synthèse des TSS) (.doc),
Figure 80 : Synthèse des TSS généré
181
o Cahier de Recette (.doc) contenant toutes les fiches de tests que doit subir le
système (la Figure 81 montre la génération de la fiche de recette « Arrêt
Automate »).
Figure 81 : Exemple de fiche de recette générée (Arrêt Automate)
182
4.7 Définition des templates dans Visual Standard
La génération des programmes automate est basée sur les fichiers sources des programmes
standardisés. Pour générer le code des projets IsaGraf 3, il faut créer les fichiers
correspondants à l’application voulue. Le but étant de ne pas ajouter de fichiers inutiles dans
le dossier de programmation lors de l’export des programmes.
4.7.1 Génération des fichiers d’un projet
Dans IsaGraf 3, un projet de programmation API est contenu dans un dossier. Ce dossier
contient l’ensemble des fichiers sources décrit dans le paragraphe 4.4.1. Des fichiers sont liés
automatiquement à la création d’un abonné (lié à un SePO) dans le projet, mais d’autres
fichiers sont ajoutés en fonction des ElPO présents dans cet SePO. Le Tableau 12 décrit les
fichiers contenus dans le dossier de programmation d’un AAGT à titre d’exemple et définit le
parent de chacun. C’est en fonction de la présence de ce parent que le fichier sera ajouté. Les
fichiers ayant pour parent AAGT, sont automatiquement ajoutés, c’est le cas de tous les
fichiers appli.*.
Tableau 12 : Récapitulatif des fichiers textes du dossier d’un abonné automate

Nom du fichier Parent
Appli.*** AAGT
Initial.lsf, LectPara.lsf, EcrPara.lsf, AcquiFIP.lsf, AcquiTSD.lsf, AAGT
AcquiTSS.lsf, DefautGT.lsf, DefautES.lsf
AIG_S1.lsf, CDE_S1.lsf Sect. HT
AIG_SRB1.lsf, CDE_SRB1.lsf SRB
AIG_DJGT.lsf, CDE_DJGT.lsf Dj. GT
Telegest.lsf, TraitSor.lsf, PLC_out.lsf, FIP_out.lsf, def_CT.lsf AAGT
Pour créer les fichiers qui ne dépendent pas de AAGT, des requêtes conditionnées de type «
pour chaque » sont utilisées. Par exemple, l’ensemble des sectionneurs, disjoncteurs et
interrupteurs héritent de la classe abstraite modeleAppareil. Pour créer les fichiers sources
LSF d’aiguillage et de commande de ces appareils, il suffit de parcourir les objets de type
modeleAppareil, fils du GT associé à l’AAGT. Dans le code ci-dessous les propriétés sont
appelées entre crochets ([NomAIG] par exemple).
183
<OdilExportXml
Fonction="Enumeration"
Requete="SELECT_FROM(Parent::modeleAppareil)">
<OdilExportXml Fonction="CreateFile"
FileProto=".\ProtosAPI\ProtosAAGT25kV\[NomAIG].LSF"
FileExport=".\[NomAIG].LSF">
<OdilExportXml Fonction="CreateFile"
FileProto=".\ProtosAPI\ProtosAAGT25kV\[NomCDE].LSF"
FileExport=".\[NomCDE].LSF.XML">
</OdilExportXml>
Le code source de ces fichiers contient des dépendances avec d’autres éléments. Le
paragraphe suivant présente l’écriture d’un template avec Visual Standard.
4.7.2 Template d’un fichier ST
A partir des fichiers sources de programmes existants, analysés avec PLC Checker, un code
standard de qualité est obtenu. A partir de ce code, les templates des programmes ont été
définis. Pour illustrer nos propos, l’exemple d’un extrait du fichier AcquiFIP.LSF du Groupe
Traction est donné.
Extrait 1 : Le code ci-dessous permet de récupérer les ordres envoyés par l’opérateur du CSS
sur le réseau FIP :
(* Lecture des ordres provenant du RTU sur FIP *)
codS1:=LectFIP('COD', 0);
cfdS1:=LectFIP('CFD', 0);
codD1:=LectFIP('COD', 3);
cfdD1:=LectFIP('CFD', 3);
codSRB1:=LectFIP('COD', 4);
cfdSRB1:=LectFIP('CFD', 4);
Pour générer le code ci-dessus, les modules d’E/S de toutes les cartes 4TCD/TSD de l’AAGT
sont parcourus. Lorsqu’un module n’est pas vide (sous-entendu connecté à un appareil) et
qu’il n’est pas connecté au retrait automatismes (fonction inhibant les reports de protections),
alors les lignes de lecture des ordres sont ajoutées avec des variables dépendantes de l’objet
connecté au module d’E/S. [NomConnexion] correspond au Mnémonique de l’appareil
connecté à la TCD/TSD. [NumAuto] correspond au numéro de ce module d’E/S parmi les
TCD/TSD de l’AAGT parent. Cet exemple illustre parfaitement le besoin d’association entre
le modèle de PO et le modèle de PC comme nous l’avions exprimé dans le chapitre 3 et dans
la section 4.5.2 de ce chapitre.
184
#combinatory
(* Lecture des ordres provenant du RTU sur FIP *)
<OdilExportXml
Fonction="Enumeration"
Requete="SELECT_FROM(TypeCarteTCD::ModeleES;[ET([TypeConnexion]!=[EMPTY()];
[NomConnexion]!=RetAuto)])" Tri="NumAuto">
<OdilExportXml Fonction="CreateNode">
<Node>
cod[NomConnexion]:=LectFIP('COD', [ARITHM([NumAuto]-1)]);
cfd[NomConnexion]:=LectFIP('CFD', [ARITHM([NumAuto]-1)]);
</Node>
</OdilExportXml>
</OdilExportXml>
Extrait 2 : Le code ci-dessous permet de récupérer les variables réflexes envoyées par les
autres abonnés sur le réseau FIP. Dans cet extrait, il s’agit de récupérer l’information de non
fonctionnement des Départs Traction à la bonne adresse sur le réseau.
(* Lecture des réflexes sur FIP *)

nfDA:=LectFIP('REFD',25); (* non fonctionnement départ A Marseille*)
nfDB:=LectFIP('REFD',33); (* non fonctionnement départ B Aubagne*)
nfDC:=LectFIP('REFD',41); (* non fonctionnement départ C Marseille*)
nfDD:=LectFIP('REFD',49); (* non fonctionnement départ D Aubagne*)
Pour générer les lignes ci-dessus, l’ensemble des objets de type abonné automate de DT
(AADT) est parcouru. Une variable {ValHexa} permet de créer les lettres d’identification des
départ à partir de leur identifiant [NumAuto]. Leur [Direction] est également indiquée pour
que le chargé d’études puisse identifier facilement le départ dont il s’agit.
<OdilExportXml Fonction="Enumeration" Requete="SELECT_ALL(TypeAADT;oui)"

Tri="NumAuto">
<Node>
<OdilExportXml Fonction="SetVarEvt" VarEvtName="HEXA"
Value="[ARITHM([Parent::NumAuto]+9)]">
</OdilExportXml>
nfD{ValHexa}:=LectFIP('REFD',[ARITHM(([NumAbonne]*8)-7)]); (* non
fonctionnement départ {ValHexa} [Parent::Direction]*)
</Node>
</OdilExportXml>
</OdilExportXml>
Ce programme est écrit en langage ST, il n’y a donc pas de grammaire spécifique au langage
à suivre. Le paragraphe suivant présente le template d’un fichier LD dont la grammaire a été
présentée dans le paragraphe 4.4.4.
185
4.7.3 Template d’un fichier LD
Pour illustrer nos propos, l’exemple d’un extrait du fichier DefautGT.LSF du Groupe Traction
est donné. Pour construire les rungs présentés ci-dessous, il est nécessaire d’être attentif à la
grammaire détaillée précédemment et de comprendre les objectifs de chaque rung. Pour
chaque extrait présenté, la représentation graphique introduit le résultat souhaité, le code
source correspondant est présenté et enfin le code du template correspondant est décrit.
Extrait 3 : Le premier rung présenté ci-dessous permet de reconstruire l’observateur defTR à

partir des defauts observables du transformateur (Figure 82).
Figure 82 : Rung en langage LD de construction de l’observateur defTR

Le code associé à cette représentation graphique est :
(*défaut transfo*)
SOR [0,1] (**) (**)

BST XIC [1,0] (*DefMC*) (*Défaut masse cuve*)
NXB XIC [1,1] (*BUCHH*) (*Défaut Buchholz de GT1*)
BND
OTE [2,0] (*defTR*) (*Défaut transfo *)
EOR [3,0]
Pour générer le code ci-dessus, il faut ajouter les défauts du transformateur en parallèle. Le
défaut Masse cuve récupéré par le réseau Modbus a été mis à part de la liste de défauts. Ce
défaut est ajouté par une instruction conditionnelle (Si, alors, sinon). Une propriété famille de
défauts [FamilleDef], appelée TRF (transformateur), a été créée. La liste des défauts TRF
conditionnée par la propriété [Actif] (défaut surveillé) est parcourue par l’instruction
« Enumération ». Chaque défaut répondant à ces conditions est ajouté soit dans un nœud
correspondant au dernier défaut de la liste [LastDefTRF], soit dans un nœud correspondant
aux défauts qui ne sont pas les derniers de la liste. En effet, le traitement de l’écriture de ces
nœuds est différent à cause de la grammaire spécifique d’IsaGraf 3. Enfin l’instruction BND
est ajoutée pour chaque défaut ajouté précédemment.
186
(*défaut transfo*)
SOR [0,[VAR_EVT(CPT)]] (**) (**)
<Condition>[SI([Parent::TypeProtection::ModbusMasseCuve]==oui;oui;non)]</Co
ndition>
<Node>
BST XIC [1,[VAR_EVT(CPT2)]] (*masseT1*) (*Défaut Masse Cuve TR *)
NXB
<OdilExportXml Fonction="SetVarEvt" VarEvtName="CPT2"
Value="[ARITHM([VAR_EVT(CPT2)]+1)]">
</OdilExportXml>
</Node>
</OdilExportXml>
<OdilExportXml Fonction="Enumeration"
Requete="SELECT_FROM(Parent::TypeDefaut;[ET([FamilleDef]==TRF;[Actif])])"
Tri="Rang">
<Condition>[Handle]!=[Parent::LastDefTRF]</Condition>
<Node>
BST XIC [1,[VAR_EVT(CPT2)]] (*[Mnemo]*) (*[Label]*)
NXB
<OdilExportXml Fonction="SetVarEvt" VarEvtName="CPT2"
Value="[ARITHM([VAR_EVT(CPT2)]+1)]">
</OdilExportXml>
</Node>
</OdilExportXml>
<Condition>[Handle]==[Parent::LastDefTRF]</Condition>
<Node>
XIC [1,[VAR_EVT(CPT2)]] (*[Mnemo]*) (*[Label]*)
</Node>
</OdilExportXml>
</OdilExportXml>
<Condition>[SI([Parent::TypeProtection::ModbusMasseCuve]==oui;oui;non)]</Co
ndition>
<Node>
BND
</Node>
</OdilExportXml>
<OdilExportXml Fonction="Enumeration"
Requete="SELECT_FROM(Parent::TypeDefaut;[ET([FamilleDef]==TRF;[Actif])])"
Tri="Rang">
<Condition>[Handle]!=[Parent::LastDefTRF]</Condition>
<Node>
BND
</Node>
</OdilExportXml>
</OdilExportXml>
OTE [2,0] (*defTR*) (*Défaut transfo *)
EOR [3,0]
<OdilExportXml Fonction="SetVarEvt" VarEvtName="CPT"
Value="[ARITHM([VAR_EVT(CPT)]+5)]">
</OdilExportXml>
187
Extrait 4 : Le rung ci-dessous construit l’observateur d’Ordre d’ouverture automatique par

défaut de l’autre Groupe Traction (Figure 83). Cette ouverture automatique a lieu uniquement
si la continuité électrique est effective entre les deux GT. C’est pourquoi tous les appareils
entre les deux GT sont ajoutés à l’équation de calcul d’OoGT2D1.
Figure 83 : Rung en langage LD de la fonction de report de protection entre GT
Le code associé à cette représentation graphique est :

(*ouverture DJ par défaut GT2*)
SOR [0,4] (**) (**)

XIO [1,0] (*soSRB1*) (*Signalo ouvert S*)
XIO [2,0] (*soSB1*) (*Signalo ouvert sectionneur barre*)
XIO [3,0] (*soSB2*) (*Signalo ouvert sectionneur barre*)
XIO [4,0] (*soSRB2*) (**)
XIC [5,0] (*defGT2*) (**)
OTE [6,0] (*OoGT2D1*) (**)
EOR [7,0]
Pour générer le code ci-dessus, le sectionneur SRB du GT courant est ajouté, ensuite une
énumération parcourt la liste des sectionneurs de barre ayant la propriété [câblé] entre le GT
courant et le GT « 2 » relatif au GT parent. Cette liste est créée par rapport à la position sur
l’axe horizontal des objets dans la zone de dessin Visio. Enfin les variables de position du
SRB du GT relatif « 2 », le défaut qu’il renvoie et l’ordre d’ouverture du disjoncteur D1 sont
ajoutés à la position correspondante dans le rung courant pour que la représentation graphique
soit correctement dessinée dans IsaGraf 3.
188
<Condition>[SI([LIST_COUNT([SELECT_ALL(ModeleGroupeTraction;oui)])]==2;oui;
non)]</Condition>
<Node>
(*ouverture DJ par défaut GT2*)
SOR [0,[VAR_EVT(CPT)]] (**) (**)
XIO [1,0] (*soSRB1*) (*Signalo ouvert S*)
<OdilExportXml Fonction="SetVarEvt" VarEvtName="VARJ" Value="2">
</OdilExportXml>
<OdilExportXml Fonction="Enumeration" Liste="[Parent::ListSectBarreGT2]"
Tri="NumAuto">
<Condition>[cable]</Condition>
<Node>
XIO [[VAR_EVT(VARJ)],0] (*so[Mnemo]*) (*Signalo ouvert sectionneur barre*)
<OdilExportXml Fonction="SetVarEvt" VarEvtName="VARJ"
Value="[ARITHM([VAR_EVT(VARJ)]+1)]">
</OdilExportXml>
</Node>
</OdilExportXml>
</OdilExportXml>
XIO [[ARITHM([VAR_EVT(VARJ)]+1)],0] (*soSRB2*) (**)
XIC [[ARITHM([VAR_EVT(VARJ)]+2)],0] (*defGT2*) (**)
OTE [[ARITHM([VAR_EVT(VARJ)]+3)],0] (*OoGT2D1*) (**)
EOR [[ARITHM([VAR_EVT(VARJ)]+4)],0]
<OdilExportXml Fonction="SetVarEvt" VarEvtName="CPT"
Value="[ARITHM([VAR_EVT(CPT)]+2)]">
</OdilExportXml>
</Node>
</OdilExportXml>
Les extraits présentés ci-dessus sont relativement simples, mais ils illustrent bien les
algorithmes utilisés pour écrire les templates. Mieux le modèle est construit et mieux la
grammaire est appréhendée, mieux les templates seront écrits et leur écriture sera facilitée. En
effet, plus le modèle est riche, moins les requêtes pour accéder aux autres objets sont
complexes. C’est pourquoi nous avons insisté sur l’importance de la modélisation et de la
méta-modélisation. Dans ce chapitre les langages FBD et SFC n’ont pas été présentés mais la
méthode pour étudier la grammaire et écriture des templates des programmes est équivalente à
celle du langage LD.
Dans la section suivante, le processus de réalisation de ce projet est synthétisé. L’intégralité

du cycle de vie suivi pour le développement et le débogage du logiciel est retracé. L’intérêt de
cette synthèse est de montrer que l’écriture des templates est une tâche qui demande de
l’expérience et l’appui des experts du domaine pour comprendre toutes les subtilités du code à
générer.
189
4.8 Agilité de la démarche d’amélioration métier
Le progiciel Odil GREMLINS a été développé en collaboration avec la société Prosyst,

notamment avec le chef de projet, Monsieur Khaled El Sanwar qui a partagé son savoir sur la
génération de code et mis ses compétences au profit de ce projet. Les modèles et les templates
ont été intégrés dans Visual Standard. La démarche Agile a été suivie tout au long du
développement du progiciel. Plusieurs étapes ont été nécessaires pour arriver au résultat
final (Figure 84):
1. La première étape consiste à définir le squelette de l’application en intégrant les

modèles de Partie Opérative et de Partie Commande. Les propriétés de chaque SePO
et ElPO sont définies. Les relations et les règles que doit suivre le modèle ont été
ajoutées.
2. La deuxième étape consiste à définir les templates de génération du code standardisé
pour un SePO à partir du code standardisé de qualité. Les templates de tous les fichiers
nécessaires à la compilation d’un projet IsaGraf 3.
3. La troisième étape a été de vérifier que le code généré correspondait au code voulu.
Cette vérification a été faite au travers de test unitaire, de comparaison avec des
projets types, dans plusieurs configurations de sous-stations possibles.
4. Suite à l’étape 3, des corrections ont été apportées aux templates mais aussi aux
modèles qu’il a fallu enrichir pour obtenir les résultats attendus.
5. Les étapes 2, 3 et 4 ont été répétées pour chaque autre SePO.
6. Une fois que les templates de tous les SePO ont été définis et corrigés, une application
complète a été générée.
7. La cohérence des données entre toutes les applications API générée a été étudiée et
corrigée si nécessaire.
8. Le progiciel était alors capable de générer une application complète. Il a été testé sur
une application réelle. Le projet retenu pour tester la qualité du code généré a été la
sous-station 25kV de La Voulzie. Le chargé d’études en charge de ce projet a utilisé
Odil GREMLINS pour générer les programmes et le fichier de paramétrage de cette
installation.
9. Une première phase de corrections a été effectuée lors de la phase de réalisation du
projet et d’essais sur plate-forme d’essais. Les templates ont été enrichis pour prendre
en compte des propriétés qui n’avaient pas été intégrées.
190
10. Le code généré a été testé lors de la recette usine sur le châssis de contrôle/commande
de La Voulzie. L’application a été testée au travers de l’intégralité du cahier de recette
du projet. Toutes les fiches du cahier de recette ont été réalisées et les corrections
restantes ont été réalisées manuellement et notées pour être ensuite intégrées dans les
templates.
11. Les corrections notées ont été intégrées dans les templates.
12. Le code généré et corrigé en usine a été testé sur site par validation des fiches du
cahier de recette.
13. La sous-station de La Voulzie est aujourd’hui en service.
Figure 84 : Développement Agile du progiciel Odil GREMLINS
Cette démarche permet de garantir que les programmes générés (Figure 85) respectent les
règles de sécurité et les principes mis en œuvre. Elle comprend une première validation sur la
plate-forme d’essais de la section CES2, suivie d’une validation usine sur des châssis, et se
termine par les essais sur site en situation réelle.
191
Figure 85 : Extrait des programmes générés de La Voulzie
Cette démarche s’est déroulée avec succès pour la première fois à la sous-station de LA
VOULZIE (Ligne Nouvelle 1 (LGV Paris – Lyon) – LN1), mise en service fin Mars 2014,
avec la coopération du responsable d’affaire Monsieur Gal Blaszczyk (Figure 86).
Figure 86 : Mise en place du châssis de contrôle/commande de La Voulzie intégrant les

programmes API générés par Odil GREMLINS
192
A la suite de la réalisation de cette sous-station, un projet de structure équivalente a été mené.

La sous-station de Moisenay a été générée avec Odil GREMLINS à 100%. La réussite de ce
deuxième projet a montré l’intérêt d’évolution itératif de la démarche. Toutes les corrections
effectuées sur La Voulzie ont permis d’obtenir une génération complète des programmes API.
4.9 Conséquences sur le Workflow des chargés d’études
Comme nous l’avons vu dans le chapitre 3, l’intégration d’Odil GREMLINS ajoute une étape
(Figure 87) au workflow des chargés d’études.
Figure 87 : Workflow pour la génération de code et de livrables

Cette nouvelle étape du workflow supprime les phases de sous charge mentale en les
remplaçant par des phases cognitives dont l’enchainement permet d’éviter une surcharge
mentale. La saisie unique dans un environnement logiciel unique permet au chargé d’études
de rester concentré et de ne pas perdre en performance. A terme, l’objectif est également de
gagner du temps en production. L’objectif visé par l’utilisation d’Odil GREMLINS pour
l’ensemble des projets est défini dans le Tableau 13 qui compare les étapes du workflow
actuel et du workflow à mettre en place par l’utilisation d’Odil GREMLINS. Le nouveau
workflow est décomposé dans le tableau de manière linéaire dans le temps, pour suivre le
même schéma que le workflow actuel.
193
Tableau 13 : Comparaison des étapes projets actuelles et des étapes projet avec Odil
GREMLINS pour les projets d’électrification de sous-stations
Phases workflow Workflow Odil Phases workflow

d'un projet actuel actuel GREMLINS Odil GREMLINS
10h Description Odil

GREMLINS
5h Description PO
3h Description PC
2h Vérification
Pré-études 70h 35h Pré-études

CdCF et liste matériel 40h 5h Génération CdCF et
liste du matériel
Schémas généraux 30h 30h Schémas généraux
Etudes 80h 40h Etudes

Validation schémas 30h 30h Validation schémas
Programmes et fichier 50h 8h Relecture du code
de paramétrage généré
Vérifications 80h 45h Vérifications

Cahier de Recette 40h 5h Relecture du Cahier de
Recette généré
Essais Usine 40h 40h Essais Usine
Corrections 20h 5h Corrections

Validations 40h 40h Validations

Essais Site 40h 40h Essais Site
Total des heures 290 175 Total des heures
Un nouveau workflow de projet a été défini pour intégrer Odil GREMLINS. Les tâches de
rédaction sont remplacées par la description graphique dans Odil GREMLINS et la
vérification des livrables générés. Les chargés d’études peuvent consacrer davantage de temps
aux tâches complexes comme la validation des schémas. Les tâches répétitives comme la
rédaction du cahier de recette sont remplacées par des tâches de relecture et correction si
nécessaire, ce qui évite des étapes de sous charge mentale et réduit le temps d’étude
nécessaire pour un projet d’électrification.
194
La charge de travail des chargés d’études peut être diminuée par la mise en place de ce
nouveau workflow. Etant donné qu’il y a environ 8 projets de régénération de sous-stations
par an, ce sont environ 920 heures par an qui peuvent être économisées. Sans compter que
cette démarche a également été appliquée aux postes d’alimentation électrique, dont les
régénérations sont des projets plus courts mais plus nombreux sur l’année, environ 20 projets
par an. Le détail du temps économisé par projet est donné dans le Tableau 14.
Tableau 14 : Comparaison des étapes projets actuelles et des étapes projet avec Odil
GREMLINS pour les projets d’électrification de postes
Phases workflow Workflow Odil Phases workflow

d'un projet actuel actuel GREMLINS Odil GREMLINS
5h Description Odil
GREMLINS
3h Description PO
1h Description PC
1h Vérification
Pré-études 50h 25h Pré-études

CdCF et liste matériel 30h 5h Génération CdCF et
liste du matériel
Schémas généraux 20h 20h Schémas généraux
Etudes 50h 25h Etudes

Validation schémas 20h 20h Validation schémas
Programmes et fichier 30h 5h Relecture du code
de paramétrage généré
Vérifications 50h 35h Vérifications

Cahier de Recette 20h 5h Relecture du Cahier de
Recette généré
Essais Usine 30h 30h Essais Usine

Validations 30h 30h Validations

Essais Site 30h 30h Essais Site
Total des heures 190 125 Total des heures
195
Au travers de ces gains en heures agents, il est facile d’obtenir des résultats en gain financier.
Le tarif horaire d’un chargé d’études est estimé à 80 euros. Le Tableau 15 propose une
estimation des bénéfices annuels prévisibles sur la base des coûts de développement présentés
dans la partie 4.6.
Tableau 15 : Synthèse des gains annuels de la solution Odil GREMLINS

Synthèse des gains annuels Solution Odil
GREMLINS
Gain des solutions par rapport aux 70400
réalisations actuelles pour les sous-stations
(en euros)
Gain des solutions par rapport aux 91200
réalisations actuelles pour les postes (en
euros)
Gain total des solutions par rapport aux 161600
réalisations actuelles (en euros)
Coût annuel d'exploitation et de 57160
maintenance en production (en euros)
Bénéfices annuels (en euros) 104440
La solution Odil GREMLINS sera donc rentable dans les trois années après son passage en
production. Ce qui peut mener à l’envie d’aller plus loin dans l’utilisation de cette solution
aux dirigeants de la SNCF.
Dans l’approche SHM présentée dans le chapitre 2, l’importance de l’acceptabilité de l’outil

proposé a été expliquée. Afin d’estimer l’acceptabilité et l’utilité de l’outil Odil GREMLINS
pour les chargés d’études, un questionnaire anonyme leur a été soumis. Dans la suite de ce
chapitre, nous présentons les résultats du questionnaire auquel ont répondu les chargés
d’études ayant utilisé le logiciel de génération, Odil GREMLINS. Au travers de cette section,
nous pourrons discuter les avantages et les inconvénients donnés par les chargés d’études sont
discutés et leur ressenti par rapport à l’utilisation du nouvel outil dans leurs projets est
analysé.
196
4.10 Analyse des questionnaires utilisateurs
Dans le but de recueillir les premiers retours des utilisateurs de la solution Odil GREMLINS,
nous avons distribué un questionnaire anonyme (Annexe 10). Le questionnaire se décompose
en trois parties :
 Préface : Quelles attentes avaient-ils par rapport à la solution proposée et en

ressentaient-ils le besoin ?
 Utilisation : La solution assure-t-elle la lisibilité, la facilité de prise en main, un
support métier suffisant ?
 Gains : en termes de qualité du code et en termes de temps lors de l’étude des projets.
Au travers de ces trois parties, le but est de vérifier dans un premier temps que les attentes des
utilisateurs correspondent bien à celles qui ont été traitées par la solution Odil GREMLINS.
Dans un deuxième temps, il s’agit de vérifier que l’utilisation d’Odil GREMLINS leur a
permis de répondre à ces attentes et de gagner du temps.
4.10.1 Quelles attentes de la solution ?
D’après les réponses au questionnaire proposé, un besoin réel de disposer d’un outil de
production adapté au métier est ressenti par les chargés d’études. Les attentes des chargés
d’études se portent sur les thèmes de :
 l’homogénéité des projets,

 l’augmentation de la productivité,
 la fiabilité des programmes générés et la réduction des erreurs,
 la réduction du nombre d’outils et l’utilisabilité de la solution.
L’intérêt des chargés d’études pour ces problématiques est également observable au travers de
leur charge de travail estimée au-delà des 100% et de leur évaluation de la qualité du code
produit sans la solution de génération, estimée à 70%.
4.10.2 Utilisation
L’utilisation de la solution Odil GREMLINS n’est pas encore généralisée et se fait en général
avec mon accompagnement. Les chargés d’études ne peuvent pas répondre qu’ils sont
197
autonomes lors de l’utilisation de l’outil de ce fait, néanmoins, ils se sentent capables de le

maîtriser après quelques heures de manipulation. Ayant travaillé avec eux lors de la
description, ils ont pu étudier l’interface graphique qu’ils ont jugée lisible. L’outil intégrant
une zone Microsoft Visio pour décrire l’installation, il est facile et rapide de reproduire le
schéma unifilaire de l’installation étudiée, ce qui doit permettre aux chargés d’études de
prendre en main facilement l’outil proposé et améliorer la lisibilité.
4.10.3 Gains
Une fois que l’installation est décrite, la répartition du contrôle/commande peut être définie.
L’utilisateur doit définir les automates communs qu’il souhaite ajouter. Les autres abonnés
automates ont été ajoutés automatiquement. Il lui reste alors à définir la répartition des
TCD/TSD, TSS s’il souhaite qu’elle soit différente de celle proposée de manière standard. En
effet, une répartition standard des appareils et des informations sur les cartes TCD/TSD et
TSS a été définie pour chaque sous-ensemble de Partie Opérative. Pour les chargés d’études
ayant défini un plan de câblage différent de celui proposé, l’outil ne les a pas aidé à le définir,
contrairement à ceux qui ont pu définir le câblage automatiquement en fonction des standards
grâce à Odil GREMLINS. Dans tous les cas, Odil GREMLINS a été utilisé pour générer les
programmes et le fichier de paramétrages associé. L’aide apporté par Odil GREMLINS a été
ressentie par chaque utilisateur.
Lors des premières utilisations d’Odil GREMLINS pour générer le code, l’outil était encore
en phase de tests et de déverminage. La lisibilité du code généré n’a pas été garantie,
notamment à cause des programmes écrits en Structured Text (ST), de communication sur le
réseau FIP. Les fonctions de communication prennent en compte 8 ou 16 arguments, qu’il
convient d’écrire à la suite ou ligne à ligne. Lors de la définition des premiers templates, la
mise en page n’était pas notre principale préoccupation. Ces problèmes de mise en page ont
été résolus depuis. La qualité du code et la standardisation du code a été jugée comme
Globalement Au Moins Equivalente (GAME) par les chargés d’études. Ce qui sous-entend
qu’ils reconnaissent le code généré comme équivalent à celui qu’ils écrivaient précédemment,
qu’ils n’ont pas besoin de faire d’efforts pour le comprendre ou le lire.
Les chargés d’études pensent que la solution Odil GREMLINS permet d’ajouter une qualité
supplémentaire aux documents et programmes générés. En effet, ils ne risquent plus d’avoir
de problèmes liés aux recopies de projets existants ni d’oublis de modifications. Pour les
198
chargés d’études, Odil GREMLINS est un moyen de maintenir l’homogénéité, la qualité, la

sécurité et la fiabilité des programmes et des livrables par son aspect génération et vérification
de la cohérence des données. Pour les projets standards, aucune modification des programmes
n’est nécessaire. L’inconvénient remarqué par les chargés d’études en revanche, est la perte
de maintenabilité des programmes. En effet, la génération de code diminue le temps passé par
les chargés d’études à réaliser les programmes de contrôle/commande des installations. Ils
redoutent une perte en maintenabilité des programmes, voir une perte de savoir-faire pour les
futurs chargés d’études.
Le gain de temps pour la répartition du contrôle/commande des appareils dans les abonnés
automates, la synthèse des TCD/TSD, des TSS, des SSL, la programmation des abonnés
automates et la rédaction des cahiers de recette a été reconnue par tous les chargés d’études
après les corrections effectuées avec la coopération de Monsieur Gal Blaszczyk. Ces phases
sont réduites à 100% dès lors que l’installation peut être décrite complètement, c'est-à-dire
qu’elle est standard. La répartition et la synthèse des informations et du câblage des appareils
est automatique, le code généré est fiable et complet, tout comme le cahier de recette. Pour
l’instant tous les chargés d’études s’accordent à dire que la solution leur permet de gagner du
temps et de réduire leur charge de travail, mais aucun n’a pu donner de chiffre quant à ce gain
de temps. Ce gain de temps se traduit également par leur volonté forte à réutiliser Odil
GREMLINS pour leurs prochains projets d’électrification.
4.10.4 Synthèse des résultats
L’homogénéité des projets, l’augmentation de la productivité, la fiabilité des programmes

générés et la réduction des erreurs, la réduction du nombre d’outils et l’utilisabilité de la
solution sont les attentes définies par les chargés d’études concernant l’outil. Odil
GREMLINS a permis de répondre à ces attentes par la génération d’un code standardisé et
lisible approuvé par les chargés d’études. Odil GREMLINS est une interface de saisie unique
qui permet de diminuer le nombre d’outils, une fois l’architecture de l’installation et du
contrôle/commande associé définies, les programmes et les livrables peuvent être générés. La
solution permet d’homogénéiser tous les projets par la génération automatique de la
répartition des appareils et des informations. L’utilisation de l’outil en autonomie par les
chargés d’études ne devrait pas présenter de difficultés particulières. L’outil intègre le langage
métier et s’inspire de documents existants (schémas unifilaires) pour la description graphique.
199
Certaines phases de projets peuvent être réduites de 100% par l’utilisation d’Odil
GREMLINS sur l’ensemble du workflow d’un projet. Pour l’instant, les chargés d’études
n’ont pas donné d’estimation de la réduction de leur charge de travail, mais il ne fait aucun
doute qu’Odil GREMLINS leur permet d’optimiser leur temps de travail et de se concentrer
sur les phases intéressantes de leur workflow.
4.11 Conclusion
La méthodologie proposée dans le chapitre 3 a été appliquée aux études d’automatisation des
EALE. A partir de l’étude des principes et des programmes déjà éprouvés sur les installations
en service, des standards de programmes API ont été définis. Ces standards ont été analysés à
l’aide du logiciel PLC Checker qui a permis d’améliorer la qualité du code standardisé.
Pour respecter la structure de la Partie Commande mise en place dans les projets de
contrôle/commande des EALE, des méta-modèles et des modèles ont été proposés. Ces
modèles respectent les normes du métier des EALE. Les modèles sont inspirés du langage
métier existant.
Une solution pour générer les programmes IsaGraf 3 a été trouvée au travers des fichiers de
code source. La grammaire du code IsaGraf 3 a été définie pour les fichiers sources ainsi que
pour les programmes API dans les langages de la norme (IEC 61131-3, 2003) : LD, ST, FBD,
SFC.
L’intégration du logiciel de génération Odil a permis d’apporter les garanties de pérennité du

projet ainsi qu’une assurance de robustesse de l’outil. Cet outil a également permis
l’intégration d’une Interface Homme Machine agréable et visuelle pour les chargés d’études.
Cette interface visuelle est basée sur la définition du schéma unifilaire des EALE, qui est une
donnée d’entrée très utilisée par les chargés d’études. Ils peuvent construire intuitivement la
représentation de leur projet. Les propriétés des objets sont définies par rapport au langage
spécifique de leur métier, ils comprennent intuitivement l’intérêt de chaque propriété.
L’intégration de ce logiciel éprouvé depuis plus de 10 ans par l’industrie française a

également permis de s’appuyer sur les compétences des ingénieurs de l’entreprise Prosyst et
leur expérience de génération de code. En effet la philosophie de définition des templates
n’est pas innée et même s’il existe plusieurs façons d’obtenir un résultat dans un template,
200
l’objectif est d’obtenir les templates les plus génériques possibles afin qu’ils permettent la
génération d’un maximum de configurations, même non standardisées.
La capacité d’Odil au niveau de la génération documentaire a été un réel bénéfice

supplémentaire pour la SNCF, puisqu’il a été possible d’ajouter aux cibles d’exports désirées,
le cahier de recette qui est un document volumineux et surtout pénible à rédiger par les
chargés d’études car ils doivent recopier des pages existantes. Ce travail répétitif est
maintenant généré automatiquement par Odil GREMLINS.
La démarche de génération des programmes API et des livrables a été menée avec succès et
l’application Odil GREMLINS a déjà été éprouvée sur des projets réels. Lorsque les derniers
développements pour la génération des cahiers des charges seront terminés, la charge de
travail mentale des chargés d’études sera reconcentrée sur des tâches intéressantes, pour
lesquelles leur savoir-faire métier apporte une réelle valeur ajoutée tandis que leurs tâches
répétitives seront fortement diminuées.
Ce premier axe d’amélioration du métier a permis de répondre aux objectifs humains en

diminuant les tâches répétitives et la complexité perçue du système par l’intégration d’une
interface de saisie unique et la génération du cahier de recette. La génération des livrables et
des programmes API est un gain en temps d’études qui intéresse la SNCF au niveau
économique mais également au niveau humain puisque la charge de travail des chargés
d’études est supérieure à 100%. L’analyse des questionnaires présentée à la fin de ce chapitre
montre que les chargés d’études voient l’intérêt de l’outil et que celui-ci ne représente pas une
concurrence pour eux mais bien une IHM à leur service. Cette démarche répond également
aux objectifs techniques, par la démarche de standardisation des programmes API et leur
génération sur la base de templates de codes déjà éprouvés. Les contraintes de lisibilité et de
maintenabilité ont également été respectées puisque le code généré correspond en tout point
au code d’origine mis en qualité.
Ce chapitre a donc présenté le premier axe de notre démarche vers l’amélioration du métier,
l’axe de génération automatique de code API et de livrables. Le deuxième axe d’amélioration,
au travers de l’intégration du filtre de contraintes formellement vérifié, est présenté dans le
chapitre suivant. En effet, le code API généré se fait à partir d’une analyse et d’une
standardisation du code existant. Son analyse qualimétrique a été réalisée. Toutefois, aucune
vérification formelle de sa sûreté de fonctionnement n’a été réalisée. Nous proposons une
201
solution formelle dans le chapitre suivant, permettant d’assurer que le code API généré sur la
base des programmes existants est sûr de fonctionnement en appliquant un algorithme original
de commande par contraintes en tant que filtre sécuritaire de la commande existante d’un
interrupteur de mise en parallèle 25kV. Pour cela, le chapitre 5 reprend les étapes nécessaires
à la définition des contraintes de sécurité à partir de l’analyse des spécifications du système et
du cahier de recette pour définir les propriétés sécuritaires que le système doit respecter. Afin
de montrer que l’ensemble de contraintes de sécurité est suffisant pour garantir la sécurité du
système, il est appliqué à la commande la plus permissive possible.
202
Chapitre 5 : Application de la commande par contraintes
aux EALE
5.1 Introduction
Le chapitre précédent a présenté l’application du premier axe de la méthodologie proposée

pour l’amélioration des études d’automatisation, l’axe de standardisation et de génération
automatique de code API et de livrables. La deuxième voie de progrès concerne l’intégration
de la commande par contraintes et fait l’objet ce chapitre. L’objectif de celui-ci est de montrer
l’applicabilité de l’algorithme (et de son Design Pattern) en tant que filtre d’une commande
existante. Au travers de la commande d’un système SNCF, nous montrons l’application de la
démarche présentée dans le chapitre 3 pour obtenir une commande sûre de fonctionnement.
Notre approche ne modifie pas fondamentalement la philosophie de travail des chargés
d’études. En considérant les programmes réalisés par les chargés d’études comme la partie
fonctionnelle du Design Pattern, il n’est pas nécessaire qu’ils sachent écrire des contraintes.
Une fois que le filtre a été défini à partir d’un ensemble de contraintes sécuritaires
formellement vérifié (par model-checking), quelle que soit la partie fonctionnelle, la sûreté du
fonctionnement du système est garantie.
L’applicabilité de cette partie de la démarche d’amélioration métier est présentée grâce à un

exemple concret sur la commande d’un interrupteur de mise en parallèle 25kV. Les
spécifications du système seront détaillées dans un premier temps. La commande
actuellement utilisée sera décrite afin de la comparer avec d’autres solutions par la suite. Dans
un deuxième temps, la méthode détaillée dans le chapitre 3 sera suivie étape par étape afin
d’obtenir, d’une part une commande par contraintes complète, et d’autre part une commande
par filtre basée sur les contraintes prenant la commande actuelle SNCF comme partie
fonctionnelle. Un modèle de la Partie Opérative sera détaillé pour réaliser la vérification de la
Partie Commande par model-checking. Les contraintes du système seront définies et
expliquées, avant d’appliquer le Design Pattern proposé pour synthétiser la commande par
contraintes. Enfin, les propriétés sécuritaires du système seront définies à partir des tests
consignés dans le cahier de recette.
203
Chapitre 5 : Application de la commande par contraintes aux EALE
Les vérifications des propriétés sécuritaires des commandes étudiées seront comparées et
expliquées. Des perspectives de travail dans la continuité de cet axe sont évoquées dans la
conclusion.
Figure 88 : Intégration du Design Pattern permettant d’obtenir une commande sûre de

fonctionnement dans la méthodologie pour les études d’automatisation
204
5.2 Spécification d’un poste de mise en parallèle et de ses fonctions
Le système étudié est un poste électrique 25kV de mise en parallèle des voies composé d’un
interrupteur de mise en parallèle (IMP) ayant les fonctions de débouclage et de refermeture
automatique des parallèles (DAP et RAP). En situation normale d’exploitation, chaque
secteur de ligne électrifiée est alimenté depuis une sous-station par un disjoncteur de Départ
Traction. Des postes de mise en parallèle sont implantés le long des secteurs, les interrupteurs
de mise en parallèle (IMP) effectuent une liaison électrique entre les deux voies, ceci pour
limiter la chute de tension car la résistance équivalente de la caténaire est divisée par deux par
rapport aux secteurs sans mise en parallèle (Figure 89). Cette configuration d’alimentation est
la condition d’application de la fonction RAP.
Lors d’un défaut, les disjoncteurs de la sous-station s’ouvrent et provoquent la mise hors
tension des secteurs.
Dans chaque poste de mise en parallèle la fonction de débouclage fait ouvrir les interrupteurs
de mise en parallèle. Elle est déclenchée par l’apparition d’une absence de tension sur les
deux caténaires.
Après quelques secondes, les disjoncteurs de la sous-station se referment automatiquement.
Si toutes les conditions nécessaires à l’activation de la fonction RAP sont réunies, alors la
fonction RAP referme les IMP.
Figure 89 : Schéma d’exploitation simplifié d’un secteur électrifié en 25kV
D’après le schéma d’exploitation normal de ce secteur, les disjoncteurs de Départ Traction de

la sous-station, DP1 et DP2 sont normalement fermés. L’IMP du poste de mise en parallèle
est également normalement fermé.
205
Un défaut fugitif sur la voie 1 ou la voie 2, entraine les actions suivantes (Figure 90) :
 déclenchement DP1 et DP2,
 absence tension détectée par les Transformateurs de tension (Tt) (UDP1, UDP2, UV1
et UV2),
 ouverture IMP1 par manque tension voie,
 réenclenchement DP1 et DP2,
 disparition de l’absence tension sur les quatre Tt,
 verrouillage du réenclencheur DP1 et DP2 pendant 15mn,
 refermeture automatique des parallèles par RAP.
Figure 90 : Chronogramme du fonctionnement RAP sur défaut fugitif

Un défaut persistant sur voie 1 ou 2 entraine les actions suivantes (Figure 91) :
 déclenchement DP1 et DP2,
 absence tension voie 1 et voie 2,
 ouverture IMP1 par manque tension voie 1 et voie 2,
 réenclenchement DP1 et DP2,
 disparition de l’absence tension voie 1 et voie 2,
 déclenchement DP1,
 absence tension voie 1,
 verrouillage du réenclencheur DP1 et DP2 pendant 15mn,
 recherche de défaut par le Régulateur Sous-Station (RSS).
206
Figure 91 : Chronogramme du fonctionnement RAP sur défaut persistant
Les postes de mise en parallèle sont des systèmes moins complexes que les sous-stations.
Leur système de contrôle/commande n’est pas distribué. Il est centralisé dans un seul abonné
automate qui reçoit les informations des Tt, contrôle et commande l’IMP et d’autres appareils
si nécessaire (Figure 92).
Figure 92 : Mise en œuvre du système de contrôle/commande du poste de mise en parallèle
5.2.1 Principe fonctionnel du RAP actuel
La fonction RAP est mise en service dans les postes de mise en parallèle 25kV d’après le
principe fonctionnel détaillé ci-après. Ce principe fonctionnel se traduit par l’implémentation
d’un programme dédié dans l’Automate Programmable Industriel (API) en charge du
contrôle/commande de l’IMP associé.
207
1. Mise en veille RAP
La mise en veille est effective si l’IMP est fermé et qu’il y a présence tension sur les 2 voies
depuis un temps supérieur à 15 minutes (T1).
La veille est désactivée en cas de :
 Commande volontaire de fermeture de l’IMP,
 Commande volontaire d’ouverture de l’IMP,
 Fin d’activation du relais d’ordre (perte de position fermée de l’IMP),
 Fin du temps de surveillance écoulé (RSU)
2. Armement RAP
L’armement de la fonction RAP se fait si la mise en veille est assurée correctement.

L’armement est initialisé sur la disparition simultanée de la tension des 2 voies.
A partir de cet instant, une temporisation de temps écoulé (RSU) est lancée (30s). Ceci permet
de s’assurer que quelle que soit la suite de la séquence, au bout de ce temps, le module sera
désactivé et verrouillé pendant 15 minutes. Ce principe permet de s’affranchir des problèmes
liés à la remise sous tension des voies.
Principe de la détection simultanée :
La détection simultanée de l’absence ou présence tension sur les voies évite les conséquences
liées au phénomène de ferro résonance. Le risque de ferro résonnance apparaît sur une
caténaire lorsque celle-ci est mise hors tension alors que la caténaire adjacente reste sous
tension.
 Détection hors tension : les états de la voie 1 et de la voie 2 sont surveillés. La

détection de l’état hors tension de l’une des 2 voies active la temporisation T2 (1s). Si
avant 1 s, les 2 voies sont hors tension, le relais R1 est actif et s’auto-maintient. La
veille est armée. Les 2 voies ont été mises hors tension simultanément. Dans le cas
contraire, si la deuxième voie est hors tension au-delà d’1 s, la veille n’est pas armée.
 Détection sous tension : les états de la voie 1 et de la voie 2 sont surveillés. La
détection de l’état sous tension de l’une des 2 voies active la temporisation T3 (3s). Si
avant 3 s, les 2 voies sont sous tension, le relais R2 est actif. Cela signifie, que la
tension a été remise simultanément sur les 2 voies.
208
3. Préparation fermeture RAP
La préparation de la fermeture de RAP est assurée si l’IMP est ouvert et que la présence
tension est détectée sur les 2 voies simultanément.
Si ces conditions sont vérifiées, la présence tension doit rester durant au moins 10 s (T4) à
partir de cet instant sur les 2 voies.
4. Ordre de fermeture de l’IMP
A l’issue de T4, une commande de fermeture (CF) est émise pendant 15 s (T5). Elle est
maintenue pendant T5 quel que soit l’état de l’appareil et des tensions caténaires. Une
information (TSS) « Fonctionnement RAP » est émise pendant la même durée.
5. Désactivation RAP
A la fin de T5, le module est désactivé, l’ensemble des étapes ci-dessus est mis à zéro. Le
module est verrouillé pendant 15 minutes (T1).
Dans le cas où la séquence est interrompue à partir de l’armement, la temporisation de temps
écoulé (RSU) désactive le module qui se verrouille pendant 15 minutes (T1).
A tout instant, le module peut être mis hors service, si un ordre de commande volontaire de
fermeture (CF) ou d’ouverture (CO) est reçu. Le module est alors verrouillé au moins 15
minutes (T1).
Le module restitue l’ordre de débouclage par manque de tension de façon à le dissocier d’un
ordre d’ouverture volontaire.
Le fonctionnement du RAP tel qu’il vient d’être décrit correspond au programme

actuellement implémenté dans les API. Dans la section suivante, les programmes de
commande de l’IMP, de surveillance de la fonction DAP et de la fonction RAP sont
présentés.
5.2.2 Programmes API actuels
Dans l’application API, plusieurs programmes influencent la commande de l’IMP étant donné
qu’il existe plusieurs fonctions qui font intervenir cet appareil. Les variables utilisées sont
décrites dans l’Annexe 12.
209
5.2.2.1 Programme de Commande de l’IMP
Un programme séquentiel (SFC) permet de contrôler et de commander l’IMP. Au travers de

celui-ci, les sorties de l’API correspondantes aux commandes de l’IMP sont activées pour
ordonner la fermeture ou l’ouverture de l’appareil. L’activation des sorties de l’API est
différente en fonction du type de commande électrique de l’interrupteur. Néanmoins, la
structure type du programme de commande est présentée sous forme d’un GRAFCET (IEC
60848, 2002) (Figure 93).
Figure 93 : GRAFCET de commande d’un IMP

Quel que soit le type de commande électrique de l’interrupteur, la commande d’ouverture est
envoyée en inverse. Si la commande électrique de l’interrupteur ne reçoit plus la polarité
envoyée par le contact CO de l’API (correspondant à l’état TRUE des variables co1IMP et
co2IMP), elle entraîne l’ouverture de l’appareil. Notons que le contact CF de l’API
(correspondant à l’état TRUE des variables cf1IMP et cf2IMP) envoie un ordre
d’enclenchement de la fermeture de l’appareil à la commande électrique. Cette particularité
210
existe sur les disjoncteurs et les interrupteurs, étant donné leur rôle sécuritaire dans
l’exploitation des EALE. En effet, en cas de perte d’alimentation ou de rupture de câble,
l’appareil s’ouvrira automatiquement.
L’activation de l’étape X1 provoque l’envoi des sorties de commande de l’IMP. Les ordres
cf1IMP, cf2IMP, co1IMP et co2IMP provoquent alors la fermeture de l’IMP. La réceptivité
menant à cet état peut être provoquée par un ordre de l’opérateur (CFIMP) ou par la fonction
RAP (OfRAP).
L’ouverture de l’IMP est normalement provoquée par le passage en étape X3. La transition
vers X3 peut être provoquée par un ordre de l’opérateur (COIMP) ou par un ordre d’ouverture
sur défaut (OoIMP). Dans notre cas, le défaut surveillé est l’absence de tension, la fonction
DAP.
5.2.2.2 Programme de la fonction DAP
Le déclenchement par absence tension est traité en début de cycle dans un programme de
traitement des entrées. Dans les programmes, la tension de la voie surveillée par la fonction
DAP est représentée par la variable VA9 (absence de tension sur la voie 1 par exemple)
(Figure 94) :
Figure 94 : Construction de la variable OoIMP en langage Ladder Diagram (IEC 61131-3)
5.2.2.3 Programme de la fonction RAP
Le principe fonctionnel du RAP décrit précédemment est traduit en langage Ladder Diagram
pour être implémenté dans l’API (Figure 95). Les variables VA9 et VA10 correspondent
respectivement à la présence de la tension sur les voies 1 et 2. Les états T1, T2, T3, T4, T5,
R1 et R2 décrits précédemment correspondent aux variables du programme.
211
Figure 95 : Fonction RAP en langage Ladder (IEC 61131-3, 2003)
Cette version de la fonction RAP manque de lisibilité. Il est impossible pour quelqu’un qui
voudrait comprendre ce programme de repérer les états dans lequel se trouve le système. Les
variables ne sont pas explicites. Nous proposons une version plus lisible de la fonction RAP
au travers d’un GRAFCET.
212
5.3 Proposition d’une commande RAP séquentielle
Etant donné l’aspect séquentiel de la fonction RAP décrite précédemment, il parait tout à fait
envisageable de pouvoir décrire cette fonction sous la forme d’un GRAFCET. Pour garder la
même philosophie de programmation, la commande de l’IMP est conservée telle qu’elle est
faite actuellement. De même pour la fonction DAP qui est très succincte.
Pour réaliser la fonction séquentielle RAP, le problème est décomposé en deux GRAFCETS.
La fonction RAP doit être réalisée dans les 30 secondes qui suivent l’apparition d’un manque
tension sur les deux voies. Un GRAFCET simple (Figure 96), synchronisé sur le GRAFCET
qui gère la séquence d’événements observables, permet de vérifier que la fonction s’exécute
dans le temps imparti, sinon une information est envoyée (RSU) pour réinitialiser la séquence
en état initial (X10).
Figure 96 : GRAFCET de surveillance du temps écoulé avant RAP (RSU)
213
Le GRAFCET de gestion du RAP (Figure 97) décompose le suivi des événements selon les
étapes suivantes, correspondant à certains états de la fonction RAP actuelle :
X0 : étape initiale, attente des conditions pour commencer la mise en veille.
X1 : « mise en veille », étape d’attente de 15 minutes successives dans les conditions de

veille. Si les conditions ne sont plus respectées, le GRAFCET repasse en X0, la temporisation
sera réinitialisée.
X2 : étape d’attente de l’armement du RAP. Tant que les conditions (pas d’ordre opérateur,
fonction RAP en service et RSU non atteint) sont respectées, le GRAFCET reste dans cette
étape jusqu’à l’apparition d’un manque tension sur l’une des deux voies.
X3 : « armement du RAP », étape temporisée à 1 seconde, le manque tension doit être apparu
sur les deux voies avant ce temps sinon la fonction RAP est réinitialisée, le GRAFCET
retourne en X0.
X4 : étape d’attente du retour de la tension sur l’une des deux voies qui doit être assuré par le
réenclenchement automatique des disjoncteurs de Départ Traction de la sous-station qui
alimente le secteur concerné. Si la tension n’est pas détectée dans les 30 secondes, le temps
RSU sera atteint et le GRAFCET réinitialisé, de même en cas de commande opérateur.
X5 : étape temporisée à 3 secondes, la tension doit être réapparue sur les deux voies avant ce
temps sinon la fonction RAP est réinitialisée, le GRAFCET retourne en X0.
X6 : « préparation fermeture RAP », la tension doit être présente sur les deux voies pendant
10 secondes et les conditions (pas d’ordre opérateur, fonction RAP en service et RSU non
atteint) doivent être respectées pendant ce temps sinon la fonction RAP est réinitialisée, le
GRAFCET retourne en X0.
X7 : « ordre de fermeture de l’IMP », envoie de l’ordre de refermeture automatique de l’IMP

(OfRAP) pendant 1 seconde avant le retour en étape initiale du GRAFCET.
214
Figure 97 : GRAFCET de gestion du RAP
Cette solution, bien qu’elle soit plus lisible par l’utilisateur et qu’elle décrive l’aspect
séquentiel de cette fonction, reste complexe à appréhender. Le GRAFCET de commande de
l’IMP contient des parties fonctionnelles et sécuritaires qu’il pourrait être pertinent de séparer.
L'algorithme de commande présenté dans le chapitre 3 permet de garantir la sécurité, par une
approche plus simple et plus formelle qu'une approche conventionnelle basée sur des
spécifications complètes en GRAFCET (IEC 60848, 2002) qui ne distingue pas l'aspect
fonctionnel de l’aspect sécuritaire. De plus, l’intérêt de la mise en place de notre démarche est
d’assurer formellement que la commande obtenue est sûre de fonctionnement puisque les
propriétés du système sont vérifiées par model-checking. Nous verrons par la suite comment
définir les propriétés que le système doit vérifier formellement.
215
Nous proposons donc d’appliquer la démarche de génération de commande sûre de

fonctionnement aux postes de mise en parallèle. La section suivante décrit la démarche étape
par étape.
5.4 Démarche de génération de la commande sûre pour les postes de mise

en parallèle
L’avantage de cette démarche est de séparer la partie sécuritaire de la partie fonctionnelle.

Ainsi, si la sécurité des fonctions DAP et RAP est vérifiée formellement par cette démarche,
le chargé d’études sera assuré qu’il ne risque pas de nuire à la sécurité du système et des
hommes. Quelles que soient les modifications de la partie fonctionnelle qu’il devra effectuer
pour réaliser son projet, les fonctions sécuritaires seront assurées. Ainsi il peut être serein et
éviter un état de stress pouvant mener à des erreurs.
La méthodologie proposée pour concevoir les contrôleurs sûrs est basée sur l'utilisation des
contraintes logiques de sécurité, qui agissent en tant que filtre logique placé à la fin du
programme API, et interdit d'envoyer une commande non sûre au système (Marangé et al.,
2010). L'ensemble de contraintes de sécurité agit en tant que filtre de la commande.
Afin de démontrer l’applicabilité de l’ensemble de la démarche proposée, la partie
fonctionnelle est également écrite sous forme de contraintes afin d’appliquer l’algorithme et
son Design Pattern présenté au chapitre 3 (Figure 98).
216
Figure 98 : Démarche de définition des contraintes
5.4.1 Définition des observateurs et des contraintes
Pour écrire les contraintes de ce problème séquentiel, il est nécessaire de créer des
observateurs correspondant à certains états du système. Ces observateurs sont créés par besoin
d’observabilité du système. Ils répondent à un besoin ressenti lors de l’écriture des
contraintes, mais il est plus clair de commencer par expliquer le rôle de ces observateurs avant
de détailler les contraintes.
5.4.1.1 Description des observateurs
Dans le but de vérifier les fonctions RAP et DAP, nous avons volontairement simplifié les
GRAFCETs de gestion des commandes opérateur. En effet, dans les GRAFCETs présentés en
Figure 99, l’opérateur envoie une commande de fermeture (CFIMP) tant qu’il veut garder
217
l’IMP fermé ou une commande d’ouverture (COIMP) tant qu’il veut garder l’IMP ouvert. Il
ne peut pas envoyer les deux commandes en même temps.
Figure 99 : GRAFCETs de commande IMP de l’opérateur
Le GRAFCET ci-dessous gère la fonction RAP (Figure 100). La variable Obs vérifie
qu’aucune commande venant de l’opérateur n’a été émise depuis plus de 900 secondes
(équation 23). X20 est l’étape initiale, d’attente des conditions initiales pour qu’un RAP
puisse avoir lieu (étape de mise en veille). X21 est l’étape d’attente de l’armement du RAP.
Lorsque les conditions d’armement du RAP sont réunies, X22 s’active pour un temps
maximum de 30 secondes, temps maximum de réalisation de la fonction RAP (RSU). Le
passage en X22 lance le GRAFCET de suivi des événements du RAP (Figure 101). Ce
GRAFCET permet de suivre l’évolution des tensions U1 et U2. Si l’ensemble des événements
a lieu pour activer le RAP, le GRAFCET de gestion du RAP évolue en X24 et un ordre de
refermeture de l’IMP automatique peut avoir lieu. Sinon le RAP est avorté et le GRAFCET
réinitialisé (X20).
̅̅̅̅̅̅̅̅̅ ̅̅̅̅̅̅̅̅̅̅ ( ) ( ) (23)
218
Figure 100 : GRAFCET de gestion de la fonction RAP
La Figure 101 présente le GRAFCET de suivi des tensions pendant le RAP. La suite
d’événements attendus correspond à celle décrite dans le RAP actuel. Lorsqu’une chute de
tension est observée sur une voie (X31), elle doit être observée sur les deux voies dans la
seconde qui suit (X32). La tension doit être vue sur une voie (X33) (avant la fin du temps
maximum de la fonction RAP), puis sur les deux voies dans les trois secondes qui suivent
(X34). Enfin la tension doit être observée continuellement sur les deux voies pendant 10
secondes (X35) avant que la refermeture automatique de l’IMP ne soit autorisée (X24). Si
l’une des étapes n’est pas franchie correctement ou que l’opérateur envoie une commande, le
GRAFCET est réinitialisé en X30.
219
Figure 101 : GRAFCET de suivi des tensions U1 et U2 pendant le RAP
5.4.1.2 Contraintes de Sécurité simples
A partir des étapes des GRAFCETs de la Figure 100, de la Figure 101 et des observateurs, les
contraintes du système peuvent être définies. L’observateur ̅ utilisé dans les contraintes
correspond à l’absence tension sur l’une des deux voies (équation 24).
̅ ̅̅̅̅ ̅̅̅̅ (24)
220
Dans un premier temps, les contraintes de sécurité simple (CSs) sont présentées :
 La sortie co1IMP ne peut pas être active s’il n’y a pas de tension U1 ou U2. La sortie
co1IMP est câblée en inverse. L’ouverture de l’IMP est ordonnée par la non-réception
de l’information co1IMP par le module de commande de l’appareil (équation 25) :
CSs1 : ̅ (25)
 La sortie co1IMP ne peut pas être activée si l’IMP n’est pas déjà ouvert. La sortie
co1IMP étant câblée en inverse, cette contrainte permet d’être sûr que l’ouverture de
l’IMP sera effectuée jusqu’à ce que la position soIMP soit atteinte (équation 26) :
CSs2 : ̅̅̅̅̅̅̅̅̅ (26)
 La sortie cf1IMP ne peut pas être active s’il n’y a pas de tension U1 ou U2 (équation
27) :
CSs3 : ̅ (27)
 La sortie cf1IMP ne peut pas être active si l’IMP est déjà fermé (sfIMP). Ce qui
implique également que la sortie cf1IMP est désactivée dès que l’IMP est fermé
(sfIMP) (équation 28) :
CSs4 : (28)
 La sortie cf1IMP ne peut pas être désactivée si l’IMP n’est pas fermé (sfIMP) et que la
tension est présente sur les 2 voies (U1 et U2). Cela se traduit également par le fait que
si un ordre de fermeture a été envoyé, la sortie est activée jusqu’à ce que l’IMP soit
fermé (sfIMP) (équation 29) :
CSs5 : ̅̅̅̅̅̅̅̅̅ (29)
221
 La sortie cf1IMP doit être active si l’étape X24 est active. Cette contrainte représente
l’ordre de refermeture automatique des parallèles (OFRAP). Par sécurité et par
cohérence vis-à-vis des autres contraintes, la présence tension des voies (U1 et U2) est
vérifiée. L’ordre de fermeture est arrêté dès que l’IMP est fermé (équation 30) :
CSs6 : ̅̅̅̅̅̅̅̅̅ ̅̅̅̅̅̅̅̅̅̅ (30)
 La sortie cf1IMP ne peut pas être activée si l’une des étapes X22 ou X23 est active. Le
RAP ne s’est pas déclenché avant la fin du temps maximum (RSU) et ne peut plus être
déclenché avant l’intervention d’un opérateur (équation 32). Pour écrire cette
contrainte simplement, l’observateur X22X23 est utilisé (équation 31).
(31)
CSs7 : ( ) (32)
 La sortie cf1IMP ne peut être activée si l’IMP n’est pas ouvert (équation 33). Si aucun
ordre n’est envoyé à la commande électrique de l’interrupteur, celui-ci s’ouvre
mécaniquement, une commande de fermeture ne peut donc avoir lieu qu’à partir du
moment où il est déjà ouvert.
CSs8 : ̅̅̅̅̅̅̅̅̅ (33)
5.4.1.3 Contraintes de Sécurité combinés
Les contraintes de sécurité combinées (CSc) considèrent deux sorties. Si la CSc est violée, la
valeur de l’une des deux est forcée pour obtenir le comportement désiré.
 La sortie co1IMP ne peut pas être désactivée si la sortie cf1IMP est active. La sortie
co1IMP sera activée pour que la CSc soit respectée. co1IMP étant câblé en inverse, on
considère qu’elle doit être activée lorsque cf1IMP est activée (équation 34) :
CSc1 : ̅̅̅̅̅̅̅̅̅̅ (34)
222
 La sortie co2IMP ne peut pas être désactivée si la sortie cf2IMP est active. La sortie
co2IMP sera activée pour que la CSc soit respectée. co2IMP et cf2IMP sont chacune
équivalentes aux sorties co1IMP et cf1IMP (équation 35) :
CSc2 : ̅̅̅̅̅̅̅̅̅̅ (35)
 Les CSc suivantes impliquent que co1IMP = co2IMP :

o La sortie co2IMP ne peut pas être désactivée si la sortie co1IMP est active. La
sortie co2IMP sera activée pour que la CSc soit respectée. (équation 36) :
CSc3 : ̅̅̅̅̅̅̅̅̅̅ (36)
o La sortie co2IMP ne peut pas être activée si la sortie co1IMP n’est pas active.
La sortie co2IMP sera désactivée pour que la CSc soit respectée. (équation
37) :
CSc4 : ̅̅̅̅̅̅̅̅̅̅ (37)
 Les CSc suivantes impliquent que cf1IMP = cf2IMP :

o La sortie cf2IMP ne peut pas être désactivée si la sortie cf1IMP est active. La
sortie cf2IMP sera activée pour que la CSc soit respectée. (équation 38) :
CSc5 : ̅̅̅̅̅̅̅̅̅̅ (38)
o La sortie cf2IMP ne peut pas être activée si la sortie cf1IMP n’est pas active.
La sortie cf2IMP sera désactivée pour que la CSc soit respectée. (équation
39) :
CSc6 : ̅̅̅̅̅̅̅̅̅̅ (39)
223
5.4.2 Contraintes Fonctionnelles simples
Pour tester l’algorithme complet par model-checking, les contraintes fonctionnelles permettant
de prendre en compte les commandes envoyées par l’opérateur sont définies :
 La sortie co1IMP doit être activée si l’étape X0 est active. Cette contrainte représente
la commande d’ouverture par l’opérateur (COIMP) (équation 40) :
CFs1 : ̅̅̅̅̅̅̅̅̅̅ (40)
 La sortie cf1IMP doit être activée si l’étape X11 est active. Cette contrainte représente
la commande d’ouverture par l’opérateur (CFIMP) (équation 41) :
CFs2 : ̅̅̅̅̅̅̅̅̅̅ (41)
Maintenant que les observateurs et toutes les contraintes (CSs, CSc et CFs) ont été définis, les
équations de chaque sortie peuvent être écrites.
5.4.3 Prise en considération des CSs et des CFs
A partir des contraintes fonctionnelles simples (CFs), l’équation de chaque sortie est
obtenue (équation 42 pour co1IMP et 43 pour cf1IMP) :
(42)
(43)
A partir des contraintes de sécurité simples (CSs), les équations de mise à zéro ( ), et de
mise à un ( ), de chaque sortie sont obtenues :
 Pour la sortie co1IMP (équations 44 et 45) :
̅̅̅̅ ̅̅̅̅ ̅̅̅̅̅̅̅̅̅ ̅̅̅̅̅̅̅̅̅̅̅̅ (44)
(45)
224
 Pour la sortie cf1IMP (équations 46 et 47) :
̅̅̅̅ ̅̅̅̅ (( ) ̅̅̅̅̅̅̅̅̅̅̅̅) ̅̅̅̅̅̅̅̅̅ ̅̅̅̅̅̅̅̅̅̅̅̅ (46)
̅̅̅̅̅̅̅̅̅ ̅̅̅̅̅̅̅̅̅ (47)
 Les équations des sorties co2IMP et cf2IMP sont respectivement égales à celles de
co1IMP et cf1IMP.
5.4.4 Prise en considération des CSc
Le problème des CSc semble être plus complexe. En effet, quand une CSc n'est pas vérifiée, il
est nécessaire d'accorder la priorité à une ou plusieurs sorties (cf. chapitre 3). Cependant, les
CSc doivent toujours être cohérentes avec les CSs, qui sont généralement prioritaires parce
qu'elles dépendent seulement des entrées et des observateurs qui sont des événements
incontrôlables. De plus, quand une CSc est résolue, cela peut impliquer des problèmes avec
d'autres CSc. Une solution pour éviter tes problèmes a été proposée dans le chapitre 3.
⃗⃗⃗⃗⃗ et ⃗⃗⃗⃗⃗ sont des vecteurs colonnes représentants respectivement les k valeurs de fc0k et fc1k.
⃗⃗⃗⃗⃗ et ⃗⃗⃗⃗⃗ peuvent être obtenus par deux matrices, MC0 et MC1 que le chargé d’études doit
définir pendant l'étape initiale d'analyse de sécurité pour indiquer la priorité entre les sorties.
MC0 et MC1 sont des matrices avec NCSc colonnes et No lignes. MC0 et MC1 indiquent pour
chaque CSc, si les sorties ( ⃗ ) doivent être forcées respectivement à 0 ou à 1. Les équations
(48 et 49) sont obtenues en utilisant le produit logique de matrice.
⃗⃗⃗⃗⃗⃗⃗ , vecteur colonne des CSc ⃗ ( ), vecteur colonne des sorties
( )
( ) ( ) , matrices de priorité des sorties
225
⃗⃗⃗⃗⃗ ( ) ⃗⃗⃗⃗⃗⃗⃗
⃗⃗⃗⃗⃗ ( ) (48)
( )
⃗⃗⃗⃗⃗ ( ) ⃗⃗⃗⃗⃗⃗⃗
⃗⃗⃗⃗⃗ ( ) (49)
( )
L'algorithme détaillé dans le chapitre 3 peut être implémenté dans un API en langage ST (IEC
61131-3, 2003) à partir des données d’entrée données dans les équations 42 à 49.
L’algorithme est utilisé comme Design Pattern de la commande.
Cet algorithme de génération de la commande par contraintes peut être utilisé différemment.
En effet, dans cette section, des contraintes fonctionnelles ont été définies en tant que partie
fonctionnelle de la commande. Il est tout à fait possible de conserver une commande existante
comme celle actuellement utilisée par la SNCF et de l’intégrer comme partie fonctionnelle en
tant que g1k.
226
5.5 Proposition d’intégration de la commande actuelle dans le Design

Pattern de la commande par contraintes
L’algorithme présenté permet de générer la commande complète d’un système. Il intègre

d’une part la partie sécuritaire au travers des CSs et CSc obtenues, et d’autre part, la partie
fonctionnelle au travers des CFs. L’ensemble de ces contraintes est intégré dans l’algorithme
pour obtenir une commande sûre de fonctionnement puisque la partie sécuritaire a été validée
formellement par model-checking. L’idée de cette section est que la partie fonctionnelle,
décrite par les contraintes fonctionnelles normalement établies, peut être remplacée par la
commande existante d’un système. La commande existante établit des valeurs à affecter aux
Sorties de l’API ( ⃗⃗⃗⃗⃗⃗⃗⃗⃗⃗⃗⃗⃗⃗⃗⃗
( )). Bien que cette commande intègre des parties sécuritaires et
fonctionnelles, cette commande peut être considérée comme la commande fonctionnelle
désirée. L’activation par la partie fonctionnelle de chaque sortie ( ⃗⃗⃗⃗⃗⃗ ) correspondra alors à la
valeur de la sortie calculée par la commande existante ( ⃗⃗⃗⃗⃗⃗⃗⃗⃗⃗⃗⃗⃗⃗⃗⃗
( )). Le Design Pattern proposé
agit alors comme un filtre de la commande existante et permet d’obtenir une commande sûre
de fonctionnement en sortie (⃗⃗⃗⃗⃗⃗⃗⃗⃗⃗⃗⃗⃗⃗⃗⃗⃗⃗
( )), quelle que soit la commande envoyée par les
programmes actuels (Figure 102). Si l’espace fonctionnel de la commande existante n’était
pas inclus dans l’espace sécuritaire, la commande générée par le Design Pattern empêcherait
toute commande mettant en péril la sécurité du système.
Figure 102 : Décomposition de l’espace de liberté du système
En effet la commande existante étant considérée comme la partie fonctionnelle de la

commande, la priorité est toujours donnée à la partie sécuritaire représentée par les CSs et les
CSc. Chaque sortie k reste calculée d’après les équations , , et (Figure 103).
227
Figure 103 : Design Pattern de la commande par contraintes en tant que filtre de la
commande existante
Par rapport à la section précédente, il s’agit alors uniquement de remplacer les équations (42
et 43) par les équations (50 et 51).
(50)
(51)
Cette vision du Design Pattern de la commande permet de conserver la commande existante

tout en assurant la sûreté de fonctionnement du système. Ainsi, les chargés d’études
conservent leur philosophie de programmation, ils peuvent modifier la partie existante
(fonctionnelle) sans risquer de mettre en péril la sécurité du système. Le Design Pattern est
ajouté aux programmes en fin de cycle pour agir comme filtre de la commande. Cette vision
du Design Pattern de la commande par contraintes est facilement applicable au monde
industriel dans lequel il est difficile de modifier les méthodes de travail. Elle permet
d’apporter une valeur ajoutée aux programmes par l’assurance de la sûreté de fonctionnement
sans pour autant pénaliser les chargés d’études en leur imposant une nouvelle philosophie de
programmation. Néanmoins, comme il l’a été montré au travers d’un exemple simple (Figure
54) du chapitre 3, si la partie fonctionnelle de la commande ( ) était fausse par rapport aux
228
spécifications fonctionnelles, l’algorithme de commande sûre permettra d’activer les sorties

( ) ou de les désactiver ( ) lorsque cela est nécessaire pour garantir la sécurité du
système mais pas lorsque cela est nécessaire du point du vue fonctionnel.
La prochaine étape de notre démarche est de vérifier formellement que la commande réalisée
par le Design Pattern est sûre de fonctionnement. Pour cela il est nécessaire de modéliser
notre système dans un model-checker. La prochaine section décrit le travail de modélisation
qui a été réalisé sur ce système. Nous proposons ensuite de comparer plusieurs commandes au
travers de la vérification de propriétés pour montrer l’intérêt de l’application du Design
Pattern de commande par contraintes.
5.6 Vérification par model-checking
Pour vérifier et valider le comportement de notre système et de la commande associée, l’outil

de modélisation et de vérification UPPAAL est utilisé (Behrmann et al., 2002). Nous nous
attacherons à réaliser un modèle de partie opérative le plus générique possible en intégrant les
propriétés d’un modèle objet. Ainsi, chaque élément de Partie Opérative (ElPO) est vu
comme un objet. Les objets définis doivent respecter le comportement de l’élément qu’ils
modélisent. Une fois que ce comportement est atteint, il peut être utilisé pour modéliser
plusieurs instances de ce modèle. L’intérêt de cette démarche est de pouvoir appliquer les
modèles définis à n’importe quelle configuration.
La suffisance de la commande générée par le Design Pattern sera vérifiée par

l’utilisation de la logique Computational Tree Logic (CTL) pour parcourir l’arbre des
évolutions du modèle (Clarke et al., 1986). Pour cela, des propriétés seront définies à partir du
cahier de recette de l’interrupteur de mise en parallèle.
5.6.1 Présentation d’UPPAAL
Nous utilisons UPPAAL pour simuler des modèles de parties opératives et pouvoir vérifier la
contrôlabilité ainsi que la sécurité du système étudié. UPPAAL est un outil de validation qui
propose un mode de vérification graphique par model-checking pour des systèmes temps réel.
L’intérêt de cet outil consiste à modéliser un système en utilisant des automates temporisés, le
simuler et vérifier les propriétés du système.
229
Le model-checking désigne une famille de techniques de vérification automatique des

systèmes dynamiques. Il s'agit de vérifier algorithmiquement si un modèle donné, le système
lui-même ou une abstraction du système, satisfait une spécification, souvent formulée en
termes de logique temporelle. On peut distinguer deux aspects du model-checking :
 Il peut s'agir de démontrer qu'une certaine classe de propriétés, ou une certaine

logique, est décidable, ou fait preuve d’une certaine complexité.
 Il peut s'agir de rechercher des algorithmes efficaces sur des cas intéressants en
pratique, de les implémenter, et de les appliquer à des problèmes réels.
UPPAAL permet de simuler le fonctionnement du système pas à pas, ou de revoir le

déroulement d’une vérification. Ainsi les traces de la vérification de l’équation logique
proposée peuvent être analysées afin de vérifier la succession d’événements qui a mené à une
solution ou non. Ceci dans le but de retrouver une erreur d’algorithme ou de modélisation
pour finalement pouvoir prouver formellement l’exactitude proche du modèle qui vérifiera un
ensemble de contraintes. En effet, la modélisation du système est également source d’erreurs.
Cette modélisation doit être testée et vérifiée avant de pouvoir fournir des résultats. Dans la
section suivante, les modèles que nous avons créés, vérifiés et utilisés sont présentés.
5.6.2 Modèle de Partie Opérative
Afin de vérifier les propriétés de notre système, il est primordial de proposer un modèle
cohérent. Ainsi la première étape de notre travail a consisté à définir les ElPO de notre
système et comment les modéliser pour obtenir le comportement désiré. Pour se faire,
l’espace temporel est décomposé autour du cycle de l’automate (Figure 104). L’espace
physique de la partie opérative est également décomposé.
230
Figure 104 : Décomposition temporelle cyclique du système
Lors du premier cycle de l’automate, une phase d’initialisation est nécessaire pour paramétrer
la partie opérative étudiée. Une fois cette initialisation effectuée, le cycle normal de
l’automate commence par la lecture des variables d’environnement. Dans le cas présent, il
s’agit par exemple de la lecture de la position de l’appareil (position ouverte, position fermée
de l’IMP) vers les entrées de l’API (signalisation ouverte, signalisation fermée de l’IMP).
Ensuite, les commandes envoyées par l’opérateur sont récupérées, sur le même principe que la
décomposition du cycle réalisé par la SNCF. En début de cycle, les entrées sont lues et les
ordres des opérateurs sont récupérés sur le réseau FIP. Une étape de reconstruction permet
ensuite de définir les observateurs, les fronts montants et descendants. L’étape suivante
consiste en l’application du Design Pattern de la commande par contraintes pour calculer les
Sorties de l’API. L’algorithme de commande calcule la valeur des Sorties (co1IMP, co2IMP,
cf1IMP, cf2IMP), qui sont écrites avant l’étape d’évolution de la PO. Pendant cette phase
d’évolution de la PO, le modèle de l’interrupteur évolue pour calculer les positions qui seront
lues au cycle suivant et les tensions U1 et U2 peuvent également évoluer aléatoirement. Le
cycle modélisé respecte le déroulement réel du cycle API.
La Figure 105 présente le modèle d’évolution aléatoire de la tension, appliqué aux tensions
U1 et U2 de notre système. Le modèle est synchronisé par rapport au cycle API. Lors de
l’étape PO, le modèle peut évoluer pour que la tension soit présente ou non, librement puisque
l’évolution n’est pas synchronisée par rapport à une étape. A l’étape Lecture, le modèle ne
peut plus évoluer jusqu’à la fin du cycle API et le retour en étape PO. Pour vérifier que
l’ensemble de contraintes est suffisant et qu’il est cohérent, une solution bloquant l’évolution
du modèle de commande est proposée (Etat « Err ») (équation 52). Si le système est dans un
231
état où une contrainte est violée après l’exécution de l’algorithme, alors la cohérence de
l’ensemble de contraintes n’est pas satisfaite. Si tel est le cas, l’évolution des modèles est
bloquée.
∑ ( ( )) ∑ ( ( )) (52)
Figure 105 : Modèle d’évolution des tensions
La Figure 106 représente le modèle d’évolution d’un appareil. Celui-ci représente en

particulier le modèle d’évolution de l’IMP mais est applicable à tout appareil de type
disjoncteur, sectionneur ou interrupteur. Initialement ouvert, un déplacement est calculé en
fonction de la valeur des Sorties de l’API (co1IMP, co2IMP, cf1IMP, cf2IMP), déterminant si
l’appareil s’ouvre ou se ferme. En fonction de la valeur de ce déplacement (d), le modèle peut
évoluer lors de la synchronisation PO!.
Figure 106 : Modèle d’évolution des appareils
232
Les sorties cf1IMP et cf2IMP sont câblées en direct sur le système réel, leur activation
entraine la fermeture de l’IMP. Les sorties co1IMP et co2IMP sont câblées en inverse, leur
désactivation entraine l’ouverture de l’IMP. Il faut donc activer co1IMP et co2IMP pour que
l’IMP puisse se fermer et rester fermé.
Sur le même principe de synchronisation que les tensions, les commandes envoyées par
l’opérateur peuvent évoluer librement entre l’étape Commande et l’étape Reconstruction.
L’opérateur ne peut envoyer une commande d’ouverture (CO) et une commande de fermeture
(CF) simultanément (Figure 107). En cas d’insuffisance ou d’incohérence de l’ensemble de
contraintes, l’évolution des commandes est également bloquée dans l’état « Err ».
Figure 107 : Modèle de commande opérateur
Le fonctionnement de l’appareil et de la fonction RAP étant séquentiels, un modèle de

temporisation est nécessaire (Figure 108). Cet observateur est synchronisé sur la Commande
et la Reconstruction afin d’avoir l’information d’évolution de cet observateur en début de
cycle. Lorsque le temps maximal de la temporisation est atteint une variable de validation
renvoie une information « fin de temporisation ».
233
Figure 108 : Modèle de temporisation
A partir de ces modèles, le fonctionnement du système étudié peut être reproduit. Pour cela, il
faut instancier ces modèles dans la déclaration système :
 Deux tensions (U1 et U2) sont nécessaires pour simuler la tension observable sur 2
caténaires,
 Un appareil de type interrupteur pour simuler l’appareil réel (IMP),
 Une commande opérateur pour simuler l’envoi d’ordres de manœuvre de l’IMP.
Trois solutions pour réaliser la commande de ce système ont été implémentées. L’objectif de
cette comparaison est de montrer qu’il est possible de formaliser la sûreté du fonctionnement
au travers de l’intégration du Design Pattern de commande par contraintes. Les commandes
présentées et comparées dans les sections suivantes sont implémentées dans la fonction
« Sequentiel() », appelée par l’étape synchronisée Contraintes! (Figure 104). La comparaison
est réalisée au travers des propriétés sécuritaires extraites du cahier de recette de ce système.
234
5.7 Vérification des commandes
UPPAAL fournit plusieurs solutions pour vérifier les propriétés sécuritaires du système et
ainsi s’assurer que les contraintes sont nécessaires et suffisantes. Le model-checker propose
de parcourir l’arbre des solutions en profondeur ou en largeur mais également de réduire
l’espace de recherche. Il est impératif de considérer le but de la vérification proposée afin
d’adapter méthodiquement les paramètres de parcours des solutions. Il est par exemple
préférable de parcourir l’arbre en profondeur pour vérifier l’existence d’un état (E<> (test)). A
contrario, il est préférable de parcourir l’arbre en largeur pour vérifier qu’une propriété est
valable pour tous les chemins (A[] (test)).
Les options de réduction de l’espace d’état permettent d’optimiser la vérification d’existence

d’une propriété : Si l’arbre est parcouru en profondeur, il est préférable d’utiliser l’option de
conservation. L’utilisation des options de parcours agressif ou extrême n’est utile que pour la
vérification en largeur.
Pour vérifier ou comprendre pourquoi une propriété n’est pas vérifiée, des traces d’exécution
peuvent être enregistrées. La trace peut décrire le plus court chemin, le plus rapide, ou
n’importe quel chemin. Le choix de la trace d’exécution est déterminant dans la réussite de
vérification d’une propriété. Par exemple, si une propriété nécessite de chercher une solution
en profondeur, il sera très long de chercher le chemin le plus court et cela risquerait de
nécessiter trop d’espace mémoire.
235
Avant de pouvoir vérifier les propriétés sécuritaires du système, il convient de commencer par
vérifier que le modèle est correct et que les commandes respectent les propriétés de vivacité
du système. Les propriétés fonctionnelles suivantes ont donc été vérifiées :
1. Il existe un chemin tel que l’IMP puisse être fermé :

o E <> sfIMP doit être vérifiée.
2. Il existe un chemin tel que la refermeture de l’appareil soit réalisée par la fonction
RAP :
o Pour la commande par contraintes : E<> X24 . sfIMP . obs doit être vérifiée :
la propriété est validée s’il existe un chemin tel que l’IMP soit fermé (sfIMP)
en ayant X24, l’état d’activation de la commande de fermeture par le RAP, et
obs qui signifie que l’opérateur n’est pas intervenu.
o Pour la commande SNCF : E<> T5. sfIMP doit être vérifiée : la propriété est
validée s’il existe un chemin tel que l’IMP soit fermé (sfIMP) en ayant T5,
l’état d’activation de la commande de fermeture par le RAP, incluant
également le fait que l’opérateur ne soit pas intervenu pour être actif.
3. Pour tous les chemins de l’arbre, il n’y a pas de chemin tel qu’une contrainte soit
violée après l’exécution de l’algorithme (uniquement pour les commandes incluant
l’algorithme) :
o E<> Erreur==1 ne doit pas être vérifiée.
La vivacité des systèmes a été vérifiée au travers de ces propriétés mais également au travers
de parcours manuels des états.
A partir des fiches du cahier de recette, des propriétés de sécurité ont été définies (Coupat et
al., 2014). Les fiches du cahier de recette sont disponibles en Annexe 6 et indiquent la
correspondance avec les propriétés décrites ci-dessous. Les propriétés définies et vérifiées
sont synchronisées par rapport au cycle également. Les propriétés sont vérifiées après
l’écriture des sorties et avant l’évolution de la Partie Opérative (tprop - Figure 104).
236
Les propriétés sécuritaires de l’interrupteur de mise en parallèle avec la fonction débouclage

automatique des parallèles (DAP) et réenclenchement automatique des parallèles (RAP) sont :
1. Il existe un chemin tel que l’opérateur peut envoyer un ordre de fermeture (CFIMP) et
la tension U1 est présente et que les sorties (cf1IMP et cf2IMP) sont activées :
o E <> CFIMP . U1 . cf1IMP . cf2IMP doit être vérifiée.
2. Il existe un chemin tel que les ordres de fermeture cf1IMP et cf2IMP peuvent être
envoyés alors que la tension U1 est présente :
o E<> cf1IMP . cf2IMP . U1 . obs doit être vérifiée.
3. Pour tous les chemins de l’arbre, il n’y a pas de chemin tel que les ordres de fermeture
cf1IMP et cf2IMP soient envoyés alors qu’il n’y pas de tension U1 (DAP) :
o E<> !U1 . cf1IMP . cf2IMP ne doit pas être vérifiée.
4. Pour tous les chemins de l’arbre, il n’y a pas de chemin tel que les ordres d’ouverture
(qui maintiennent la position fermée de l’IMP) co1IMP et co2IMP soient envoyés
alors qu’il n’y pas de tension U1 (DAP) :
o E<> !U1 . co1IMP . co2IMP ne doit pas être vérifiée : la propriété est validée
s’il n’existe aucun chemin tel que la tension est présente (U1) et que les sorties
(co1IMP et co2IMP) sont activées.
5. Il existe un chemin tel que les ordres de fermeture (cf1IMP et cf2IMP) sont envoyés
alors que les conditions d’ordre de RAP (OfRAP – X24 pour la commande par
contraintes – T5 pour la commande SNCF) sont réunies et qu’il n’y a pas eu d’ordres
opérateur depuis plus de 900s :
o Pour la commande par contraintes : E<> X24 . cf1IMP . cf2IMP doit être
vérifiée.
o Pour la commande SNCF : E<>T5 . cf1IMP . cf2IMP doit être vérifiée.
6. Pour tous les chemins de l’arbre, il n’y a pas de chemin tel que les ordres de fermeture
soient envoyés par le RAP (OfRAP – X24 pour la commande par contraintes – T5
pour la commande SNCF) et qu’il n’y a pas eu d’ordres opérateur depuis plus de 900s
alors que la tension (U1) n’est pas présente :
o Pour la commande par contraintes : E<> X24 . cf1IMP . !U1 ne doit pas être
vérifiée.
o Pour la commande SNCF : E<> T5 . cf1IMP . !U1 ne doit pas être vérifiée.
237
Nous proposons de vérifier ces propriétés selon trois commandes présentées précédemment
(Figure 109):
A. Commande générée avec le Design Pattern de la commande par contraintes avec les
contraintes fonctionnelles présentées dans la section 5.4.
B. Commande actuellement utilisée par la SNCF présentée dans la section 5.2 et traduite
sous forme d’équations.
C. Commande générée avec le Design Pattern de la commande par contraintes intégrant
comme partie fonctionnelle la commande actuelle SNCF, présentée dans la section
5.5.
Figure 109 : Représentation des trois commandes testées
Pour chaque système étudié, le code de la fonction séquentielle est donné en (Annexes 7, 8 et
9) pour montrer la correspondance entre les GRAFCETs présentés précédemment et le code
équivalent. Le Design Pattern de la commande par contraintes peut également être retrouvé
dans le code proposé.
Le Tableau 16 présente les résultats obtenus lors de la vérification des propriétés selon les
trois commandes proposées. Des copies d’écran des résultats obtenus sont disponibles en
Annexe 12. Pour vérifier ces propriétés, le parcours de l’arbre de solutions peut être réalisé en
profondeur (P) ou en largeur (L). Les propriétés 3, 4 et 6 demandent un parcours total de
l’arbre pour satisfaire leur vérification. Le parcours de l’ensemble des solutions peut s’avérer
coûteux en mémoire vive. Etant donné l’aspect séquentiel de la commande analysée et les
238
temporisations de plusieurs secondes voir minutes, le nombre d’états que peut atteindre le
système, en fonction de l’évolution aléatoire des tensions U1 et U2 et de la commande
opérateur, explose. Pour réduire cette explosion combinatoire, deux solutions ont été mise en
œuvre pour atteindre les meilleurs résultats :
 Les temporisations ont été réduites de manière proportionnelle pour réduire le nombre
d’évolutions des modèles entre les étapes de la fonction RAP.
 La solution complémentaire a consisté en l’utilisation du centre de calcul Romeo de
l’Université de Reims Champagne-Ardenne. Ne pouvant éviter un nombre d’états
important à cause des temporisations des événements séquentiels du système, il a été
nécessaire de se tourner vers une configuration matérielle suffisante pour répondre à
nos besoins, notamment en termes de mémoire vive. Chaque nœud du centre Romeo
étant composé de 32Go de RAM. L’utilisation d’un seul nœud a permis de vérifier les
propriétés du système A. Malheureusement nous n’avons pas eu le temps de réaliser
les démarches nécessaires pour augmenter le nombre de nœuds. Cela aurait
probablement permis de vérifier les propriétés du système C.
Les deux solutions mises en œuvre ont permis d’atteindre les résultats présentés dans le
Tableau 16 pour les systèmes A et B. Le nombre d’états du système C est plus élevé que celui
des systèmes A et B. Pour réduire davantage les évolutions possibles du système, nous avons
tenté de vérifier les propriétés 3, 4 et 5 avec une seule tension modélisée telle que (U1 = U2)
mais cette solution n’a pas été suffisante pour que l’arbre soit complètement parcouru. Les
propriétés 3, 4 et 5 du système C n’ont donc pas pu être formellement vérifiées.
Tableau 16 : Résultats de la vérification des propriétés des commandes étudiées
Commande/Prop 1 (P) 2 (P) 3(L) 4(L) 5(P) 6(L)
B ̅̅̅ ̅̅̅ ̅̅̅
Cette vérification formelle met en évidence que la commande SNCF n’est pas sûre. Le
problème révélé par l’analyse des propriétés de la commande SNCF vient d’un scénario
précis qui n’est pas testé dans le cahier de recette. Pour vérifier cette propriété dans le cahier
239
de recette, il faudrait simuler une absence de tension (U1) pendant la fermeture de l’IMP. En
effet, si la tension est présente au moment où l’opérateur envoie un ordre de fermeture
(CFIMP), la séquence de fermeture de l’IMP par le programme SFC de commande de l’IMP
est lancée. Les sorties cf1IMP, cf2IMP, co1IMP et co2IMP sont activées jusqu’à ce que
l’IMP soit fermé même si la tension disparait. L’étape X2 est alors atteinte, l’ordre
d’ouverture par manque tension (OoIMP) est actif, ce qui entraine l’ouverture immédiate de
l’IMP par la transition vers l’étape X3. Formellement les propriétés 3 et 4 ne sont donc pas
vérifiées. Le problème révélé par la propriété 6 est le même, si la tension baisse alors que la
refermeture automatique de l’IMP vient d’être autorisée par OfRAP, l’IMP se fermera jusqu’à
atteindre sa position fermée, puis s’ouvrira instantanément par manque tension (DAP). Ce
problème a pour conséquence un risque de réalimentation de défauts caténaires.
Ce problème est résolu lorsque le filtre généré par le Design Pattern est appliqué en sortie de
la commande SNCF. En effet la CSs3 (équation 27) empêche d’envoyer la commande de
fermeture de l’IMP (cf1IMP et cf2IMP) lorsque la tension n’est pas présente. Les sorties sont
donc forcées à zéro par le filtre et notamment par les équations et . Sur cet
exemple de commande de l’IMP, l’intérêt du filtre est évident, il ne contraint pas la vivacité
du système et assure formellement la sûreté de fonctionnement du système. Les propriétés à
vérifier étant obtenues à partir du cahier de recette, la commande obtenue répond aux
exigences de validation de la recette usine.
5.8 Conclusion
Au travers de ce chapitre, la commande d’un poste de mise en parallèle a été étudiée. La

commande actuelle, dont les fonctions RAP et DAP de l’IMP, a été présentée. La commande
actuelle manque de lisibilité, notamment la fonction RAP, une solution GRAFCET a donc été
proposée pour répondre à ce problème séquentiel. Cette commande ne sépare pas la partie
sécuritaire de la partie fonctionnelle. Afin de montrer l’applicabilité du Design Pattern à un
système réel, l’algorithme a été implémenté avec la commande la plus permissive. Une
commande qui allie la commande existante et la commande par contraintes, appliquée en tant
que filtre au travers du Design Pattern, prenant en entrée fonctionnelle les programmes
existants, a été proposée.
240
Pour tester les propriétés des commandes proposées, le comportement d’un poste de mise en
parallèle a été modélisé sous UPPAAL, un outil de model-checking. Grâce à celui-ci, les
propriétés auxquelles doivent répondre les commandes proposées ont été vérifiées
formellement. Les propriétés ont été définies à partir des fiches du cahier de recette,
permettant de vérifier le comportement du système lors des recettes usine et site.
Les résultats ont montré que le Design Pattern permet d’obtenir une commande sûre avec une
partie fonctionnelle la plus permissive. Son application en tant que filtre de la commande
existante a permis de sécuriser le comportement du système qui ne l’était pas entièrement.
L’implémentation du Design Pattern en tant que filtre s’intègre parfaitement à la

méthodologie proposée afin d’améliorer la commande. En effet, les contraintes simples et
combinées sont définies et validées, pour chaque sous-ensemble du système en amont. La
définition d’un template devrait permettre de générer le Design Pattern incluant les
contraintes de sécurité relative au système cible et garantir sa sécurité. Aujourd’hui cette
partie de la démarche d’amélioration de la commande n’est pas implémentée mais nous
espérons que la démonstration présentée dans ce chapitre permettra d’aller plus loin dans
l’intégration de cette partie.
Pour des raisons évidentes de sécurité, le domaine étudié des Equipements d’Alimentation des
Lignes Electrifiées (EALE), a toutes les raisons d’intégrer la vérification formelle dans ces
méthodes de travail. Marc Antoni écrit dans ses travaux sur la signalisation ferroviaire
(Antoni, 2012), et notamment sur le système ERTMS (Europan Rail Traffic Management
System), que des catastrophes telles que Fukushima doivent remettre en cause les approches
probabilistes selon laquelle des scénarii peu probables n’ont pas besoin d’être étudiés. Dans
notre domaine d’études, la sécurité est également au cœur des préoccupations, il serait donc
préférable de ne pas attendre une catastrophe pour généraliser l’utilisation des méthodes
formelles telles que le model-checking.
241
242
Conclusion Générale et Perspectives
Les travaux menés lors de ce projet de recherche ont abouti à une proposition de
méthodologie pour les études d’automatisation permettant d’améliorer les conditions de
travail des chargés d’études. Cette démarche (Figure 110) est basée sur une modélisation d’un
domaine spécifique (qui constitue le métier cible) et a été élaborée en considérant à la fois les
aspects humains, économiques et sécuritaires. Celle-ci intègre deux axes de recherche. Le
premier concerne la génération automatique de livrables (codes, documents, schémas…).
Celle-ci repose nécessairement sur une standardisation et une modélisation du « métier ».
L’approche MDD (Model Driven Development) du génie logiciel et l’approche DSM
(Domain Specific Modeling), apporte des éléments de solution reposant sur l’utilisation de
« templates métiers ». Toutefois, il est fondamental de générer des livrables de qualité et du
code API (Automates Programmables Industriels) sûr de fonctionnement. Le second axe de
recherche vise à garantir la sûreté de fonctionnement de la commande. Trois approches de
synthèse de la commande (la Supervisory Control Theory (SCT), la synthèse algébrique, la
commande par contraintes logiques) permettant a priori de répondre à ces objectifs de sûreté
ont été présentées et discutées. La commande par contraintes logiques possède l’avantage
majeur de séparer la sécurité (qui est vérifiée formellement hors ligne par model-checking) et
le fonctionnel, et de pouvoir être utilisée avec des programmes API existants, ne remettant pas
ainsi en cause la méthodologie de travail des chargés d’études.
243

livrables
Dans le cadre de cette thèse, un outil logiciel intégrant la contribution apportée par ce travail
de recherche a été développé : Odil GREMLINS. Il permet aux chargés des études
d’automatisation d’améliorer leur condition de travail et la sécurité tout en gagnant en
productivité et cela, sans modifier fondamentalement le workflow et le langage métier qu’ils
connaissent. L’utilisation de l’outil est basé sur la définition du système étudié à partir d’une
liste exhaustive d’objets métiers modélisés (model based design).
244
L’intérêt du model based design pour un domaine spécifique est la standardisation des étapes
du cycle de production tout en conservant le langage spécifique du domaine (Domain Specific
Language – DSL).
A partir de la description graphique effectuée par le chargé d’études, il devient ainsi possible
de réaliser automatiquement les tâches suivantes :
 la vérification de la cohérence des données du modèle par rapport aux modèles et aux
méta-modèles prédéfinis,
 la génération de la synthèse des entrées et des sorties des API,
 la génération du code des programmes API,
 la génération des cahiers de recette.
Les règles de programmation mises en œuvre pour le contrôle/commande des EALE ont été
définies et les programmes API ont été standardisés. L’intégration de l’outil PLC Checker au
sein de la démarche a permis d’assurer la qualité du code généré. Les programmes API
générés sont homogènes et respectent les règles établies (lisibilité, maintenabilité…).
Les modèles et méta-modèles des EALE et du système de contrôle/commande associé définis

permettent également de respecter l’architecture distribuée du système. Les modèles
respectent le langage métier des chargés d’études automatismes. Ainsi les sous-ensembles de
Partie Opérative (SePO) et les éléments de Partie Opérative (ElPO) correspondent aux
composants du système et les propriétés des objets appartiennent au langage spécifique du
métier. Cela assure la lisibilité du modèle et évite toute ambiguïté de langage pouvant être
source d’erreurs.
Les programmes sont générés sur la base de templates de code source respectant la grammaire
de l’Interface de Programmation d’Application (IPA) IsaGraf 3. La structure des programmes
a été définie d’après les fichiers sources lisibles présents dans un répertoire projet. Les
programmes ont pu être générés dans tous les langages de la norme (IEC 61131-3, 2003)
utilisés : LD, ST, FBD, SFC.
L’intégration du progiciel de génération Odil a permis de concevoir une Interface Homme

Machine (IHM) ergonomique et l’assurance de robustesse nécessaire au passage en
production de l’outil. Au moyen de celui-ci, les chargés d’études peuvent définir le modèle de
245
leur installation par drag and drop (glisser déplacer) d’objets prédéfinis composant le
système. Les objets et les propriétés sont standardisés par des valeurs attribuées par défaut,
qui peuvent être modifiées selon les besoins des projets. Ainsi, la description peut être rapide
pour des projets standards. L’architecture de contrôle/commande est également standardisée
est peut être spécifiée.
L’intégration de cet outil dans le workflow des projets d’automatisation des EALE permet
d’éviter les tâches répétitives telles que la rédaction du cahier de recette que les chargés
d’études devaient réaliser au travers de la recopie de fiches de tests existantes. L’outil évite
également, au travers du principe de saisie et de description unique, la saisie multiple des
mêmes informations. La standardisation et la génération des programmes API, sur la base de
templates définis par rapport aux programmes existants et analysés par un outil qualimétrique,
assurent l’homogénéité du code, sa qualité et surtout le respect des règles de programmation
établies par les experts métier.
La contribution théorique majeure de notre travail de recherche est une approche originale de
la commande. Celle-ci peut être exploitée en tant que commande à part entière ou en tant que
filtre robuste d’une commande existante. En effet, l’algorithme proposé et son Design Pattern
peuvent être utilisés dans les deux cas. L’approche proposée est basée sur la définition de
contraintes logiques limitant l’espace de fonctionnement du système. L’idée originale est de
séparer la partie sécuritaire de la partie fonctionnelle. La partie sécuritaire est définie à partir
des contraintes de sécurité simples (CSs) et des contraintes de sécurité combinées (CSc). La
partie fonctionnelle est définie à partir de contraintes fonctionnelles (CF) qui peuvent soit
provenir du programme API existant ou d’un programme gérant uniquement l’aspect
fonctionnel. Le but du filtre défini par le Design Pattern est d’assurer que la commande soit
sûre de fonctionnement. Pour cela, à partir du cahier de recette et de l’analyse des modes de
défaillances, les propriétés sécuritaires que le système doit respecter, ainsi qu’un ensemble de
contraintes de sécurité, sont définis. Pour vérifier que la commande générée par le Design
Pattern à partir des contraintes de sécurité est sûre de fonctionnement, nous avons proposé de
vérifier formellement par model-checking que les propriétés sécuritaires sont respectées. Les
approches formelles sont encouragées par les normes ferroviaires telles que l’(EN 50126,
2012) pour vérifier la sûreté du fonctionnement des applications de contrôle/commande, plus
généralement dans le monde industriel ayant des contraintes de sûreté de fonctionnement par
la norme (IEC 61508, 2010).
246
Nous avons montré l’intérêt de la vérification formelle et de l’application du Design Pattern

sur un cas concret. La commande d’un interrupteur de mise en parallèle a pu être améliorée
par l’application du Design Pattern en tant que filtre robuste de la commande existante.
L’intérêt de cette approche par filtre, au sein de notre démarche d’amélioration métier, est que
les contraintes peuvent être associées à un ElPO. Ainsi, l’ensemble de contraintes nécessaire
pour assurer la sûreté du fonctionnement du système peut être généré automatiquement à
partir de la description réalisée avec l’outil. Par conséquent, quelle que soit la configuration
du système, la sûreté du fonctionnement de celui-ci sera assurée. L’autre avantage de
l’utilisation du Design Pattern en tant que filtre robuste de la commande existante est qu’elle
ne change pas la philosophie de programmation des chargés d’études. En effet, la définition
des contraintes n’est pas une tâche habituelle et la lisibilité n’est pas aisée. C’est pourquoi
l’intégration du Design Pattern en tant que filtre est intéressante car elle permet de conserver
les programmes sans les modifier, tout en garantissant la sécurité.
Les solutions proposées sont en adéquation avec les principes de l’automatique « humaine »
qui vise à apporter des solutions originales au problème de l’automatisation en développant
des outils adaptés à l’opérateur humain. Une campagne expérimentale a été également
conduite en vue d’évaluer l’utilité et l’utilisabilité des outils coopératifs développés.
Ce travail de recherche a été concrétisé par le développement d’un outil logiciel supportant la
méthodologie. Celui-ci a été testé en production pour les sous-stations électrifiées en 25kV.
Le développement de l’outil pour les postes électrifiés en 25kV est en cours de finalisation et
devrait être livré pour la fin de l’année 2014. Il restera alors à appliquer la méthodologie aux
EALE électrifiés en 1500V. Grâce à l’expérience acquise sur les installations électrifiées en
25kV, nous espérons que l’adaptation aux EALE électrifiées en 1500V sera plus rapide même
si les principes et les architectures sont différents, le métier conserve le même langage, la
même grammaire et des principes proches.
Dans quelques mois, l’appel d’offre du Système de Conduite Locale et d’Automatisme

(SCLA) sera terminé et un nouveau fournisseur d’API sera désigné. Dès lors, l’outil devra
évoluer pour générer les programmes adaptés à cet API et s’il est compatible avec le langage
XML Open proposé par l’organisation mondiale PLC Open (Van der Wal, 2009) alors nous
aurons tout intérêt à nous orienter vers ce langage standard multiplateforme.
247
Ce travail ouvre également de nombreuses perspectives théoriques et applicatives de

recherche.
Comme nous l’avons vu, l’algorithme de commande proposé présente l’intérêt de pouvoir
sécuriser des programmes API existants sans les modifier. Toutefois, un autre de ses
avantages est de pouvoir séparer les parties fonctionnelles et sécuritaires d’un contrôleur. Il
devient donc possible de concevoir des programmes de façon très différente. En effet,
aujourd’hui, le plus souvent la spécification en GRAFCET mélange les aspects fonctionnels
et sécuritaires. Le fait de concevoir la commande en séparant les deux peut conduire à des
méthodes de conception originales et innovantes. Pour la SNCF, volontairement, nous avons
décidé d’utiliser l’algorithme en tant que filtre non bloquant d’une commande existante car
cela permet de ne pas modifier les méthodes et habitudes des chargés d’études. Il a été montré
sur un exemple réel (Interrupteur de Mise en Parallèle) qu’il devient possible d’obtenir une loi
de commande différente et qui semble au final plus simple et plus lisible. Il serait donc
intéressant d’appliquer cette approche sur d’autres programmes API de la SNCF.
La vérification par model-checker est très performante. Toutefois, il faut faire face à des
explosions combinatoires et dans notre cas, nous n’avons pas été en mesure de vérifier toutes
les propriétés avec la commande existante de la SNCF associée au filtre. Nous désirons d’une
part poursuivre les tests sur le super calculateur ROMEO de l’Université de Reims
Champagne-Ardenne en augmentant le nombre de nœuds et la mémoire vive disponible.
D’autre part, des travaux peuvent être menés pour modifier les modèles utilisés pour la
vérification en vue de tenter de limiter l’explosion combinatoire. Enfin, nous avons pu
prouver que la commande la plus permissive (CPP) associée au filtre était sûre de
fonctionnement. Si l’on arrive à prouver que la commande existante est inclue dans la CPP, il
est possible de prouver formellement toutes les propriétés et sans forcément avoir recours à
des moyens de calcul très performants.
L’algorithme de commande peut être également amélioré. Une analyse structurelle des
contraintes de sécurité (CS) devrait permettre de réduire le nombre de boucles dans la
structure WHILE. Actuellement, le nombre maximal d’itérations correspond au nombre de
contraintes de sécurité combinées. Il est possible de réduire ce nombre et ainsi d’augmenter
les performances de l’algorithme. En effet, une analyse structurelle d’un graphe des
248
contraintes peut mettre en évidence les cycles. Dès qu’un cycle est repéré (conséquence d’un
défaut sur la PO), il est possible de sortir de la structure WHILE.
Des liens semblent possibles entre l’algorithme de commande et le diagnostic. En effet, si les
contraintes de sécurité ont été formellement vérifiées, le fait de sortir de la boucle WHILE
suite à un dépassement du nombre maximal d’itérations indique vraisemblablement une
défaillance de la Partie Opérative. Il est donc possible d’une part d’étudier la cause logique de
l’incohérence des contraintes pour en déduire les causes possibles de défaillance. D’autre part,
un travail sur la définition des contraintes de sécurité en vue de faciliter le diagnostic peut être
envisagé.
Enfin, la définition des contraintes de sécurité ouvre également un champ important de

recherche. Les travaux sur la synthèse algébrique peuvent être une piste à creuser. Il est
également envisageable de les générer automatiquement à partir d’un modèle objet, en
développant l’approche initiée dans cette thèse.
Nous espérons également poursuivre ce travail de recherche en étendant la génération au

processus de conception de la commande. Les possibilités de génération de simulation 3D du
système doivent être étudiées pour que l’utilisateur final ait la meilleure représentation du
système possible. Il faudra trouver une solution permettant l’interface entre la commande
distribuée de la sous-station et la simulation du système. Cette interface pourrait être installée
sur la plate-forme d’essais de PSIGT-TE CES. Il faudra également étudier la possibilité de
vérifier et de valider certaines fonctions sécuritaires de la commande du système au travers de
la génération de modèles et de propriétés pour le model-checking en fonction de la
configuration du système (Fernandez Adiego et al., 2014). Pour cela, l’idéal serait d’être
capable de transcrire formellement les programmes API généré vers le langage de l’outil de
model-checking.
Notre contribution a donc été à la fois méthodologique, théorique et appliquée. Nous

avons suivi les concepts de l’automatique « humaine » et placé l’homme au centre de nos
travaux. L’objectif n’était pas de le retirer de la boucle de conception, mais de lui donner des
outils logiciels adaptés à ses tâches.
249
La méthodologie proposée et l’outil Odil GREMLINS développé sont aujourd’hui

opérationnels et permettent :
1) une amélioration des conditions de travail des chargés d’études sans modifier leur
métier car les principes de développement des programmes API sont conservés.
2) un gain économique important car les temps consacrés aux études sont réduits.
3) une fiabilisation de la commande au travers de la proposition d’un algorithme (ou

Design Pattern) simple à implémenter et reposant sur un filtre à base de contraintes logiques
(vérifiées formellement) de sécurité et robuste aux erreurs de commande.
250
Bibliographie
Alanche, P, Lhoste, P., Morel, G., Roesh, M., Salim, M., Salvi, P. (1986). Application de la
modélisation de la Partie opérative à la structuration de la commande, Journée AFCET,
Montpellier, 1986
Alur R., Henzinger, T.A. (1992). Logics and models of real time: a survey, Real Time: Theory
in Practice, Springer LNCS 600, pp. 74-106, 1992
Amalberti, R. (2001). La conduite de systèmes à risque. Paris: PUF.
Antoni, M. (2012). Méthode de validation formelle d’un poste d’aiguillage informatique.

Recherche Transports Sécurité, 28(2), 101-118.
Antoniadis, L.A., Leopoulus, V.I.N. (2000). A concept for the integrated process description,
PLC programming and simulation using Petri nets: Application in a production process, Proc.
of the IEEE SMC, 2000.
Askenazy, P., Caroli, E. (2003). Pratiques innovantes, accidents du travail et charge mentale:
résultats de l’enquête française sur les Conditions de travail. Pistes, 1 (5), 1-30.
Baddeley, A. (1990). Human memory: theory and practice. Hove: Lawrence Erlbaum
Associates.
Bajovs, A., Nikiforova, O., Sejans, J. (2013). Code Generation from UML Model: State of the
Art and Practical Implications, Applied Computer Systems. doi:10.2478/acss-2013-0002
Balemi, S., Kozák, P., Smedinga, R. (1993). Discrete Event Systems: Modeling and Control,
Progress in Systems and Control Theory, Birkháuser Verlag, Basel, Switzerland, 1993.
251
Bibliographie
Balemi, S. (1992). Control of discrete event systems: theory and application, PhD Thesis,
Swiss Federal Institute of Technology, Zürich, Switzerland, 1992.
Baresi, L., Mauri, M., Monti, A., and Pezzk, M., (2000). PLCTOOLS: Design, formal
validation, and code generation for programmable controllers, Proc. of the IEEE SMC 2000.
Behrmann, G., Bengtsson, J., David, A., Larsen, K.G., Pettersson, P., Yi, W. (2002). Uppaal
implementation secrets, 7th International Symposium on Formal Techniques in Real-Time and
Fault Tolerant Systems. Springer-Verlag London, UK 2002: 3-22.
Benlorhfar, R., Annebicque, D., Gellot F., Riera B. (2011). Robust filtering of PLC program
for automated systems of production, 18th World Congress of the International Federation of
Automatic Control, Milan, Italie, août 2011.
Bévan, R. (2013). Approche composant pour la commande multi-versions des systèmes

transitiques reconfigurables, thèse de doctorat, Lorient, 2013.
Bézivin, J., Gérard, S., Muller, P.-A., and Rioux, L. (2003). MDA components: Challenges
and Opportunities. Metamodelling for MDA, First International Workshop. York, UK, 2003.
Canet, G., Couffin, S., Lesage, J.-J., Petit, A., and Schnoebelen, P. (2000). Towards the
automatic verification of PLC programs written in instruction list, Proc. of the IEEE SMC,
2000.
Chikofsky, E.J., Cross, J.H. (1990). Reverse engineering and design recovery: A taxonomy,
IEEE Software 7: 13–17. doi:10.1109/52.43044
Clarke, E. M., Emerson, E. A., & Sistla, A. P. (1986). Automatic verification of finite-state
concurrent systems using temporal logic specifications. ACM Transactions on Programming
Languages and Systems (TOPLAS), 8(2), 244-263.
Cnockaert, J.C., & Floru, R. (1991). Introduction à la psychophysiologie du travail. Nancy:

PUN.
252
Bibliographie
Coupat, R., Meslay, M., Burette, M. A., Philippot, A., Annebicque, D., Riera, B. (2014).
Standardization and Safety Control Generation for SNCF Systems Engineer. 19th IFAC World
Congress 2014 (IFAC WC 2014), Cape Town, South Africa, 2014.
Coupat, R., Meslay, M., Burette, M. A., Philippot, A., Annebicque, D., Riera, B. (2013).
Standardized generation and Robust filtering for optimization of the mental workload of the
systems engineer. 12th IFAC Symposium on Analysis, Design, and Evaluation of Human-
Machine Systems (HMS 2013), Las Vegas, USA, 2013.
Cruette D. (1991). Méthodologie de conception des systèmes complexes à événements

discrets : application à la conception et à la validation hiérarchisée de la commande de
cellules flexibles de production dans l’industrie manufacturière, thèse de doctorat, Université
de Lille, février 1991.
Czarnecki K., Helsen, S. (2003). Classification of Model Transformation Approaches,

OOPSLA’03 Workshop on Generative Techniques in the Context of Model-Driven
Architecture, Anaheim, Canada: University of Waterloo, 2003, pp. 1-17.
Debernard, S., Riera, B., Poulain, T. (2014). Chapter 8 : The Common Work Space for the
Support of Supervision and Human–Machine Cooperation, Designing Human-machine
Cooperation Systems, Patrick Millot, Wiley InterScience, ISBN 978-1-84821-685-3, pp 285-
342, 2014.
Debernard, S., Riera, B., Poulain, T. (2013). ‘L'espace de travail commun pour l'aide à la
supervision et à la coopération homme-machine’. In P. Millot, Ergonomie des systèmes
homme-machine : Conception et coopération (Traité IC2, série Systèmes automatisés),
Hermès, pp. 295-341, ISBN 9782746239203.
El-Khattabi S. (1993). Intégration de la surveillance de bas niveau dans la conception des

systèmes à événements discrets : application aux systèmes de production flexibles, thèse de
doctorat, Université de Lille, Septembre 1993.
253
Bibliographie
EN 50126 (2012). Applications ferroviaires - Spécification et démonstration de la fiabilité, de

la disponibilité, de la maintenabilité et de la sécurité (FDMS).
Eveleens, J. L., Verhoef, C. (2010). “The Rice and Fall of the Chaos Report Figures”, IEEE
Software, IEEE Computer Society, 2010, pp. 30-36.
Fernandez Adiego, B., Darvas, D., Tournier, J.-C., Blanco Vinuela, E., Gonzalez, S., Victor,
M. (2014). “Bringing Automated Model Checking to PLC Program Development - a CERN
Case Study”, 12th IFAC - IEEE International Workshop On Discrete Event Systems
(WODES'14), Paris, France, 2014.
Fernandez Adiego, B., Blanco Vinuela, E., Tournier, J.-C., Victor, M., Gonzalez, S., Bliudze,
S. (2013). Model-based automated testing of critical PLC programs. 11th IEEE International
Conference on Industrial Informatics, pages 722–727, 2013.
François, M. (1989). Ergonomie des postes de contrôle qualité; étude bibliographique.

Cahiers des notes documentaires, 137, 595-606.
Frey, G., Litz, L. (1998) ‘Verification and Validation of Control Algorithms by Coupling of
Interpreted Petri Nets’, Proc. Of the IEEE SMC‘98, San Diego, Vol. 1, pp. 7-1 2, 1998.
Hamon-Cholet, S., & Rougerie, C. (2000). La charge mentale au travail : des enjeux
complexes pour les salariés. Économie et statistique, N°339-340, 9/10, 243-255.
Hassapis, G., Kotini, I., Doulgeri, Z. (1998). ‘Validation of a SFC software specification by
using hybrid automata’, INCOM’ 98, Volume 11, pp. 65-70, 1998.
Henzinger, T.A. (1998). ‘It’s about time: real-time logics reviewed’, Proceedings of the Ninth
International Conference on Concurrency Theory (CONCIJR 1998), Springer LNCS 1466,pp.
439-454, 1998.
Herrington, J. (2003). Code Generation in Action. Manning, 2003, pp. 342.
254
Bibliographie
Hietter, Y. (2009). Synthèse algébrique de lois de commande pour les systèmes à évènements
discrets logiques, thèse de doctorat, Cachan, École normale supérieure.
Hietter, Y., Roussel, J.-M., Lesage, J.-J. (2008). Algebraic synthesis of dependable logic
controllers, 17th IFAC World Congress, Seoul (Korea), pp. 4132-4137, July 2008.
Holloway, L.E., Krogh, B.H., (1994). Controlled Petri nets: A tutorial survey, 11th Int. Conf.
on Analysis and Optimization of Systems, Discrete Event Systems, volume 199 of LNCS,
1994
IEC 60848 (2002), Second edition 2003-01, Programmable controllers – Part 3: Programming
languages GRAFCET specification language for sequential function charts Reference number
CEI/IEC 60848: 2002.
IEC 60870-4 (2013). Telecontrol equipment and systems. Part 4: Performance requirements
Ed. 1.
IEC 61131-3 (2003). Automates programmables – Partie 3 : Langages de programmation -

Programmable controllers – Part 3: Programming languages, Reference number CEI/IEC
601131: 2003.
IEC 61499-2 (2000). (2nd committee Draft, Ed. 1.0), Function blocks for industrial-process
measurement and control systems - Part 2: Engineering Task Support.
IEC 61508 (2010). (Ed. 2.0 Commented version), Functional safety of electrical / electronic /
programmable electronic safety-related systems.
IEC 61850 (2010). Communication Networks and Systems in Substations
IEC 61850 (2010). Part 6 : Substation Configuration Language (SCL)
ISO 9000 (2005). Systèmes de management de la qualité - Principes essentiels et vocabulaire.
255
Bibliographie
ISO 9126 (2001). Software engineering-Product quality Ed.2, 2001.
ISO 10075 (1991). Principes ergonomiques concernant la charge de travail mental -- Termes
généraux et leurs définitions (1991).
ISaGRAF. ICS Triplex ISaGRAF Inc. - leading IEC 61131 and IEC 61499 software.
Available: http://www.isagraf.com
Jacobson, I., Booch, G., Rumbaugh, J. (2002). The Unified Software Development Process,
Addison-Wesley, 2002, pp. 512.
Jiménez-Fraustro, F., Rutten, E. (1999). A synchronous model of the PLC programming

language ST, Proceedings of the Work In Progress session, 1st Euromicro Conference on
Real-Time Systems, ERTS’99, York (GB), June 9-11, pp. 21-24, 1999.
Kowalewski, S., PreuRig, J. (1996). Verification of sequential controllers with timing

functions for chemical processes, Proc. of the. 13th IFAC World Congress, San Francisco,
Vol. J, pp. 419-424, 1996.
Küster, J. (2011). Model Driven Research Engineering, Code Generation, IBM Research,
Zurich, 2011.
Lampérière-Couffin, S., Rossi, O., Roussel J.M., Lesage, J.J. (1999). Formal validation of
PLC programs: A survey, Proceedings of the ECC’99, 1999.
Lancry, A., Lammens, J.M. (1998). Étude différentielle des fluctuations de performances à
une tâche complexe au cours de la journée. Le Travail Humain, 61 (2), 153-169.
Leplat, J. (1997). Regard sur l’activité en situation de travail. Paris: PUF.
Lhoste, P. (1994). Contribution au génie automatique : concepts, modèles, méthodes et outils,

Habilitation à diriger des recherches de l’Université de Nancy, février 1994.
256
Bibliographie
Marangé, P., Benlorhfar, R., Gellot, F., Riera, B. (2010). Prevention of human control errors
by robust filter for manufacturing system, 11th IFAC Symposium on Analysis, Design, and
Evaluation of Human-Machine Systems (HMS 10), France.
Marangé, P. (2008). Synthèse et filtrage robuste de la commande pour des systèmes

manufacturiers sûrs de fonctionnement, thèse de doctorat, Université de Reims Champagne-
Ardenne, 2008.
MDA (2012). Model Driven Architecture - A Technical Perspective

(http://www.omg.org/cgi-bin/doc?ormsc/2001-07-01).
Mertke, Th., and Menzel, Th., (2000). Methods and tools to the verification of safety-related
control software, Proc. of the IEEE SMC, 2000.
Millot, P. (2014). La conception centrée sur l'homme. In P. Millot, Ergonomie des Systèmes
Homme-machine: conception et coopération, Hermés, Paris, France, pp. 31-67
Millot, P. (1987). Coopération homme-machine dans les tâches de supervision des procédés
automatisés, thèse de doctorat, Valenciennes, 1987.
NF C 63-850 (1988). Appareillage industriel à basse tension - Automates programmables.
OMG (2012). Catalog of OMG Modeling And Metadata Specifications, 2012.

(http://www.omg.org/technology/documents/modeling_spec_catalog.htm)
Parasuraman, R., Sheridan, T., and Wickens, C. (2000). A model for types and levels of
human interaction with automation. IEEE Transactions on Systems, Man and Cybernetics,
SMC-30(3), 286–297.
Pearce, P. and Friedenthal, S., (2013). A Practical Approach for Modelling Submarine
Subsystem Architecture in SysML, Proceedings from the 2nd Submarine Institute of Australia
(SIA) Submarine Science, Technology and Engineering Conference, pp. 347-360, October
2013
257
Bibliographie
Philippot, A., Riera, B., Gellot, F., Annebicque, D., Coupat, R., Pierrel, E. (2014). Initiation à
la qualimétrie de code d’automate programmable industriel, Enseignement des Technologies
et des Sciences de l'Information et des Systèmes, CETSIS, Besançon, 2014.
Ramadge, P.J.G., Wonham, W.M. (1987). Supervisory Control of a Class of Discrete Event
Processes, SIAM J., Control and Optimisation, 25: 206-230, 1987.
Ramadge, P.J.G., Wonham, W.M. (1989). The Control of Discrete Event Systems, Proc. of
the IEEE, Vol. 77, pp. 81-97, 1989.
Reisig, W. (1992) A Primer in Petri Net Design, Berlin, Heidelberg, New York, Springer,
1992.
Richard, J.-F. (1996). Faut-il revoir la notion de charge mentale ? Psychologie Française, 41
(4), 309-312.
Riera, B., Coupat, R., Annebicque, D., Philippot, A., Gellot, F. (2014a). Control synthesis
based on safety Boolean guards for manufacturing systems: application to a sorting system,
10th International Conference on Modeling, Optimization & SIMulation (MOSIM'2014),
Nancy, France, 2014.
Riera, B., Coupat, R., Philippot, A., Gellot, F., Annebicque, D. (2014b). Control design
pattern based on safety logical constraints for Manufacturing Systems: Application to a
Palletizer, 12th IFAC - IEEE International Workshop On Discrete Event Systems
(WODES'14), Paris, France, 2014.
Riera, B., Philippot, A., Annebicque, D., Gellot, F. (2012). Safe control synthesis based on
Boolean constraints for manufacturing systems, 8th Symposium on Fault Detection,
Supervision and Safety of Technical Processes (SAFEPROCESS 2012), Mexico.
258
Bibliographie
Riera, B., Marangé, P., Gellot, F., Nocent, O., Magalhaes A., and Vigario B. (2009)
Complementary usage of real and virtual manufacturing systems for safe PLC training, 8th
IFAC Symposium on Advances in Control Education (ACE09), Kumamoto, Japon, 2009.
Riera, B., Debernard, S. (2003). Basic Cognitive Principles Applied to the Design of
Advanced Supervisory Systems for process control, Handbook of Cognitive Task Design,
Erick Holnagel (Ed.), Lawrence Erlbaum Associates, pp 255-281, 2003.
Riera, B. (2001). Contribution à la conception d’outils de supervision adaptés à l’homme.

Habilitation à Diriger des Recherches, Université de Valenciennes et du Hainaut-Cambrésis,
décembre 2001.
Rohée, B., Riera, B. (2009). Advanced supervisory control for manufacturing systems: from
concepts to a separated monitoring system, International Journal of Intelligent Systems
Technologies and Applications (IJISTA) special issue on intelligent system design and
development, 2009.
Royce, W.W. (1970). Managing the Development of Large Software Systems. IEEE Wescon,
p. 1-9, 1970
S11, consignation C (2012). Règlement S11: Prescriptions d’exploitation des installations de

traction électrique par caténaires 1500 volts courant continu ou 25 000 volts courant alternatif
monophasé, EPSF, IN 1709, 2012.
Sarmento, C.A., Silva, J.R., Miyagi, P.E., Santos Filho, D.J. (2008). Modeling of programs
and its verification for programmable logic controllers. 17th IFAC World Congress, 2008.
Sargent, L. D., Terry, D. J. (2000). The moderating role of social support in Karasek’s job
strain model. Work and Stress, Vol. 14, No. 3, pp. 245-261, 2000.
Schwaber, K., Beedle, M. (2001). Agile Software Development with SCRUM, Prentice Hall,
Upper Saddle River, New Jersey, 2001.
259
Bibliographie
Shankar, N. (2000). Combining theorem proving and model checking through symbolic
analysis, Concurrency Theory (pp. 1-16), Springer Berlin Heidelberg, 2000.
Sperandio, J. C. (1980). La psychologie en ergonomie (Vol. 80). Presses universitaires de

France.
Sperandio, J. C. (1988). L’ergonomie du travail mental, Paris, 1988.
Stanton, N. A., Young, M., and McCaulder, B. (1997). Drive-by-wire: The case of driver
workload and reclaiming control with adaptive cruise control. Safety Science, 27(2/3).
Toguyeni, A.K.A., Dangoumau, N, Lee, E.J. (2007). Synthesis Approach for Reconfigurable
Manufacturing Systems Design Based on Petri Nets, Studies in Informatics and Control
(SIC), volume 16 (1), 2007.
Toguyeni A.K.A., (1992). Surveillance et diagnostic en ligne dans les ateliers flexibles de
l’industrie manufacturière, thèse de doctorat, Université de Lille, novembre 1992.
Tolvanen , J. P. (2005) Domain-Specific Modeling for Full Code Generation, Methods and
Tools, 2005.
UML (2011). OMG, OMG Unified Modeling Language (UML) Specification, 2011.
UTE C 18510 (1988). Operations on electrical work and installations and in an electrical
environment - Electrical hazard prevention, 1988.
Van der Wal, E. (2009), PLCopen, IEEE Ind. Electron. Mag., vol. 3, p. 25, Dec. 2009.
Volker N., Kramer, B.J. (1999) Modular Verification of Function Block Based Industrial
Control Systems, Proc. 24th IFAC/lFIP Workshop on Real-Time Programming, May 1999.
Völter, M., Stahl, T., Bettin, J., Haase, A., & Helsen, S. (2013). Model-driven software
development: technology, engineering, management. John Wiley & Sons.
260
Bibliographie
Völter, M. (2011). From Programming to Modeling - and Back Again, IEEE Software, Nov.-
Dec. 2011, pp. 20-25.
Völter, M., Groher, I. (2007). Product Line Implementation using Aspect-Oriented and
Model-Driven Software Development, 11th International Software Product Line Conference,
SPLC, 2007.
VZU13_68 (2001). Mise en œuvre du Système de Commande Local et d’Automatismes

(SCLA), Equipement d’Alimentation des Lignes Electrifiées (EALE), Document Technique
N° 68, PSIGT-TE, 2001.
Wickens, C. D., Gordon, S. E., Liu, Y. (1998). An introduction to human factors engineering.
Wickens, C. D. (1984). Processing resources in attention. Varieties of attention (pp. 63-101).

New York: Academic Press.
Yerkes, R. M., Dodson, J. D. (1908). The relation of strength of stimulus to rapidity of habit-
formation. Journal of Comparative Neurology and Psychology 18: 459–482.
doi:10.1002/cne.920180503.
Young, M.S., Stanton, N.A. (2002). Attention and automation: new perspectives on mental
underload and performance, Theoretical Issues in Ergonomics Science, Taylor & Francis, 3,
2, 178-194, 2002.
Young, M. S., Stanton, N. A. (2001). Mental workload: theory, measurement, and application.
In W. Karwowski (Ed.), International encyclopedia of ergonomics and human factors: Vol. 1,
pp.507-509. London: Taylor and Francis.
261
Bibliographie
262
Annexes
Annexe 1 : Règles PLC Checker
Règles de Nommage
N.1 - Tous les éléments constituant le programme doivent être nommés

N.2 - Les noms des éléments du programme doivent avoir une taille minimum et maximum
N.3 - Les mnémoniques des éléments ne font pas référence à leur adresse physique
N.4 - Les mnémoniques de mise au point ne doivent pas faire partie du programme final
N.5 - Les caractères spéciaux sont interdits dans les noms des mnémoniques
N.6 - Les mots clefs des langages de programmation ne doivent pas servir de mnémoniques
Règles sur les Commentaires
C.1 - Tous les éléments constituant le programme doivent être commentés

C.2 - Les commentaires doivent comporter un minimum de caractères
C.3 - Chaque réseau doit être commenté
C.4 - Les commentaires ne contiennent pas le marqueur de début de commentaire
Règles d’Ecriture
E.1 - Non-spécifique - Toutes les variables doivent être écrites avant d’être lues
E.2.a, E.2.b - Les entrées des blocs fonctionnels utilisateur doivent être lues et ne pas être
écrites
E.2.c, E.2.d - Les entrées/sorties des blocs fonctionnels utilisateur doivent être lues et écrites
E.2.e - Les sorties des blocs fonctionnels utilisateur doivent être écrites avant leur éventuelle
lecture
Règles de Structuration
S.1 - Les sauts en arrière sont interdits

S.2 - Une variable doit être écrite au sein d’une seule routine
S.3 - Une variable doit être écrite au sein d’une seule tâche
S.4 - Une sortie physique ne doit être écrite qu’une seule fois par cycle automate
S.6 - Les instances de FB/DFB sont appelées une et une seule fois
S.7 - Les variables définies sont utilisées
S.8 - Les variables ne se chevauchent pas
S.9 - Mesure de la complexité
S.10 - Limitations dues aux SCADA
263
Annexes
Informations Utiles
I.1 - Taux de commentaires

I.2 - Présence de code dans les commentaires
I.3 - Présence de code mort
I.4 - Présence d’éléments verrouillés
I.5 - Nombre cyclomatique v(G)
I.6 - Complexité essentielle ev(G)
I.7 - Nombre de lignes de code
I.8 - Nombre d’étapes du Grafcet
I.9 - Nombre de branches du Grafcet
I.10 - Ratio de code dupliqué sur l’application
264
Annexes
Annexe 2 : Modèles d’une sous-station
Partie HT
1 1
1
1 0..2
Arrivée HT AACommun
1 1
1
1 1 1
1
1 1
*
*
0..1 *
0..1 0..1
Sect. HT Dj HT Protection
0..1
Barre HT
1
1
*
0..2
Sect. HT 1 1 AACommun
Figure 111 : Modèle de la Partie Opérative
1
11 GT AAGT
11 1 1
1 1
1 1 1
1
1 1
*
1 0..3 0..1
*
1 1 1
Protection Sect. Phases Sect. HT Dj GT Transfo. SRB
Figure 112 : Modèle du Groupe Traction
265
Annexes
1 DT AADT
11 1 1
1 1
1 1 1
1
1 1
*
1..2 0..1
*
1..2 1..2 0..1
Protection Sect. MR Dj DT TdC Sect. By Pass
Figure 113 : Modèle du Départ Traction
1 Batt. K AACommun
11 1 1
1 1
1 1
1
1
*
1 0..1
*
1 1
Protection SK DK K
Figure 114 : Modèle de la Batterie de Condensateurs
266
Annexes
Commun
1 1
1
1 1
Barre 25kV AACommun

1 1
1
1
1
*
0..2
Sect. Barre
0..4
Pontage AACommun
1 1
1
1 1
1
1
*
0..1 1
Sect. SM Sect. P
Figure 115 : Modèle des sous-ensembles de Partie Opérative Communs
Commun
1
1 11 1 1
1
*
*
*
*
Sect. Interrupteur AnnulPA DU
Figure 116 : Modèle des éléments de Partie Opérative Communs
267
Annexes
Annexe 3 : Comparaison technique de deux solutions
Tableau 17 : Comparaison détaillée des deux solutions

Critères Prosyst : ODIL Développement
interne
Maitrise
structure progiciel ++ --
Code Source -- ++
Architecture -- -
Développement ++ +
Débogage + -
Evolution
modification des standards ++ +
modification du générateur -- -
modification du modèle ++ +
Risques
Finalisation du logiciel ++ +
Collaboration + +
Savoir-faire/Compétences ++ --
Entreprise - +
Couts
Développement + ++
Maintenance + ++
Evolution des standards + ++
Livrables
Programmes ++ +
Cahier des charges ++ +
Liste du matériel ++ ++
Fiche IA (id automatismes) ++ ++
Prix objectif ++ ++
Cahiers de recette ++ +
Schémas électriques -- --
Synoptique CLE - PC Vue ++ --
268
Annexes
Annexe 4 : Montage financier des solutions de génération de code
Montage financier de la solution : Développement d’une solution
Afin d’estimer au plus juste le coût financier du développement d’un logiciel propre à PSIGT-
TE, celui-ci a été décomposé selon le cycle de production en V (Figure 117). Ainsi les phases
de réalisation d’un tel projet ont été décomposées.
Figure 117 : Cycle en V du développement logiciel
269
Annexes
Montage financier du développement phase 1
Tableau 18 : Coûts de développements annuels et d’exploitation en dernière année

2013 2014 2015 2016…
Développement du logiciel 120k€ 2
Tests et déverminage du logiciel 120k€ 3
Maintenance et évolution du 80k€ 4
logiciel
Charge de travail 6 à 8 mois 1 2 mois 2 3 mois 3 mois
Formations Base de données 3k€ 3k€

Licences pour les logiciels de 10k€ 10k€ 10k€ 10k€
développement:
Visual Studio 2012, MySQL
Validation des programmes 1 mois
générés
Total des coûts de 10k€ 133k€ 133k€ 90k€
développement + 6 à 8 mois + 1 mois + 4 mois + 3 mois
Financement R&D R&D R&D Gain sur
les projets
Commentaires par rapport au Tableau 18:

1: La définition des spécifications logicielles seraient beaucoup plus importante que la
spécification des exports standardisés. Il serait également nécessaire de développer un
démonstrateur montrant la mise en œuvre de la génération.
2: Le développement d’un logiciel de génération robuste, incluant une IHM confortable est un
travail nécessitant plus d’un homme/an. Le coût minimum de développement serait alors de
120k€.
3: La phase de test et de validation de la partie logicielle serait également un travail lourd
nécessitant un retour d’expérience sur le logiciel d’une « beta test ».
4: La maintenance du logiciel devrait être assurée par un spécialiste, ce qui nécessite de
disponibiliser une ressource rare spécifiquement dédiée à cette tâche
270
Annexes
Montage financier de la solution : Odil Gremlins
Afin d’estimer au plus juste le coût financier du développement du progiciel Odil pour les
études d’automatisation des EALE, le cycle de production a été adapté.
Figure 118 : Cycle en V de développement d’un progiciel
La Figure 118 montre le cycle en V complet d’un développement logiciel. La partie sur fond
bleu ne fait pas partie du cycle de développement progiciel. En effet, de par la structure
progicielle d’Odil, cette partie du cycle est considérée comme déjà réalisée. Il faut cependant
exprimer un besoin au travers du cahier des charges à fournir à Prosyst, pour qu’ils puissent
intégrer nos exigences dans le standard (progiciel) de nos EALE. Une fois que le progiciel
aura été validé par Prosyst et débogué, Prosyst garantit le bon fonctionnement d’Odil
Gremlins. Cependant au-delà du bon fonctionnement du progiciel, il est nécessaire de vérifier
que les exports générés assurent leurs fonctions et respectent les contraintes relatives au
métier (FDMS, standards de programmes…). Cette phase de vérification fonctionnelle aura
lieu lors des tests systèmes en usine puis sur site le cas échéant.
271
Annexes
Montage financier d’Odil Gremlins
Tableau 19 : Récapitulatif du devis établi par Prosyst

2013 2014 2015…
Prestations de développement et 83 k€ 25 k€ 5 k€
d’assistance
Formations 3 k€ 3 k€ -
Licences annuelles, maintenance et 2,5 k€ 2,5 k€ 28 k€
support logiciel
Total des coûts de prestation de 88,5k€ 30,5k€ 33k€

Prosyst
Des coûts supplémentaires s’ajoutent au travail qui sera réalisé par Prosyst :
Tableau 20 : Coûts de développements annuels et d’exploitation en dernière année
2013 2014 2015…
Total des coûts de prestation de Prosyst 88,5k€ 30,5k€ 33k€
Validation des programmes générés 1 mois
Charge de travail 4 mois 1 4 mois 2 2 mois 3
Financement R&D R&D Gain projets
Commentaires par rapport au Tableau 20 :

1: La charge de travail résulte du besoin de spécifications pour la génération des livrables
pour les projets d’électrification en 25kV alternatif.
2: Charge de travail estimée pour la saisie du standard pour les projets d’électrification en
1500V continu.
3: Charge de travail dédiée aux évolutions à saisir dans le standard.
Synthèse des coûts de développement et de maintenance des solutions
Le tableau ci-dessous présente la synthèse des coûts de développement de chaque solution

dans le but d’avoir une comparaison aisée des solutions.
272
Annexes
Tableau 21 : Synthèse de coûts de développement et de maintenance des solutions

Synthèse des coûts annuels des Total des coûts Total des coûts
Solutions de prestation de de
développement développement
d’Odil Gremlins
2013 88,5k€ + 4 mois 6 à 8 mois

2014 30,5k€ + 4 mois 133k€ + 1 mois
33k€ + 3 mois
2015 133k€ + 3 mois
Production
2016 90k€ + 4 mois

2017 Production
2018
Coûts de Développement
Coût de développement des 152000€ 356000€

solutions (en euros + heures) + 11 mois + 16 mois
Coût de développement des

284880 539280
solutions (en euros)
Coûts de Maintenance
Coût d'exploitation et de
maintenance en production (en euros 33k€ + 2 mois 90k€ + 2 mois
+ heures)
Coût d'exploitation et de
maintenance en production (en 57160 114160
euros)
Les mois sont convertis en valeur monétaire dans le Tableau 21, en utilisant le nombre
d’heures travaillées par mois : 151h au tarif horaire d’un bureau d’étude : 80€.
273
Annexes
Annexe 5 : Etude financière
L’étude est réalisée dans le cas le moins favorable, c'est-à-dire en considérant les coûts
maximums de développement d’une part. D’autre part, la rentabilité est calculée en sous
estimant le nombre de projets annuels. En effet, nous considérerons que 8 sous-stations et 20
postes sont réalisés annuellement.
Etude des gains potentiels des solutions
La réalisation d’un projet est décomposée en étapes pour lesquelles un temps est imparti. A
partir de cette décomposition, pour chaque solution le gain de temps réalisable grâce au
logiciel de génération standardisée a été estimé.
274
Annexes
Tableau 22 : Etude des gains annuels pour les sous-stations

Pour une sous-station typique: (2HT, 2GT, 4DT)
Temps estimé
Développment
par projet (en Odil Gremlins
phase 1
Phases d'un projet heures)
DCE 70h 35h 40h
cadre réponse (CdCF) liste
40h 5h 10h
matériel
schémas généraux 30h 30h 30h
EXE/VISA 80h 40h 50h

validation schémas 30h 30h 30h
Programmes et fichier de
50h 10h 20h
paramétrage
Synoptique CLE 2 500 € 2 500 € 2 500 €
DET 80h 50h 60h

Cahier de Recette 40h 10h 20h
Essais Usine 40h 40h 40h
DOE 20h 5h 5h
Correction 20h 5h 5h
AOR 40h 40h 40h

Essais Site 40h 40h 40h
Gain de temps sur le suivi -2
Temps de paramétrage du
0 10h 20h
progiciel
Total des heures 290 180 225
Total des prestations 2 500 € 2 500 € 2 500 €
Nombre de sous-stations traitées
annuellement 8
Total annuel des heures 2320 1440 1800
Gain des solutions par rapport
aux réalisations actuelles (en
heures) 0 880 520
Gain sur le Synoptique CLE (en
euros) 0 0
Coût horaire d'un chargé d'étude 80
Gain des solutions par rapport
aux réalisations actuelles (en
euros) 0 70400 41600
275
Annexes
Dans le Tableau 22, dans les phases où la génération n’intervient pas, le temps imparti reste le
même, il n’est modifié que lorsque la génération peut être utilisée pour les livrables de la
phase. Le temps réduit qui est alors imparti permet de paramétrer le logiciel ou le progiciel
d’une part et de vérifier le livrable généré d’autre part.
Dans la seconde partie du Tableau 22, les gains réalisables sur une sous-station typique sont
multipliés par le nombre réduit de projets réalisés annuellement au niveau des sous-stations.
Nous avons considéré que la qualité des livrables générés grâce à Odil permettrait de gagner
d’avantage de temps que la solution développée spécifique à nos besoins puisque nous
bénéficierons du savoir-faire de Prosyst et de leur retour d’expérience sur la cohérence de
données du modèle servant à la génération.
De la même manière, cette étude est effectuée sur les électrifications des postes.
276
Annexes
Tableau 23 : Etude des gains annuels pour les postes

Pour un poste typique à IA
Temps estimé par Développement
Odil Gremlins
Phases d'un projet projet (en heures) phase 1
DCE 50h 35h 30h
cadre réponse (CdCF) liste
30h 5h 10h
matériel
schémas généraux 20h 20h 20h
EXE/VISA 50h 25h 30h

validation schémas 20h 20h 20h
prog et fichier param 30h 5h 10h
DET 50h 35h 40h

Cahier de Recette 20h 5h 10h
Essais Usine 30h 30h 30h
DOE 10h 5h 5h
Correction 10h 5h 5h
AOR 30h 30h 30h

Essais Site 30h 30h 30h
Gain de temps sur le suivi -2
Temps de paramétrage
0 5h 10h
du progiciel
Total des heures 190 133 145
Nombre de sous-stations
traitées annuellement 20
Total annuel des heures 3800 2660 2900
Gain des solutions par
rapport aux réalisations
actuelles (en heures) 0 1140 900
Coût horaire d'un chargé
d'étude 80
Gain des solutions par
rapport aux réalisations
actuelles (en euros) 0 91200 72000
277
Annexes
5.8.1 Calcul des bénéfices
Tableau 24 : Etude des bénéfices réalisables

Synthèse des gains annuels des Solution Odil Solution
Solutions Gremlins développement
interne
Gain des solutions par rapport aux 70400 41600
réalisations actuelles pour les sous-
stations (en euros)
Gain des solutions par rapport aux 91200 72000
réalisations actuelles pour les postes
(en euros)
Gain total des solutions par rapport 161600 113600
aux réalisations actuelles (en euros)
Coût annuel d'exploitation et de 57160 114160
maintenance en production (en euros)
Bénéfices annuels (en euros) 104440 -560
Le Tableau 24 montre clairement les bénéfices réalisables grâce à la génération des livrables.
En effet en soustrayant les coûts annuels d’exploitation et de maintenance aux gains réalisés
sur les projets de sous-stations et de postes, les bénéfices annuels en exploitation sont obtenus.
Le Tableau 24 met en avant les résultats prometteurs d’une collaboration avec Prosyst. En
effet, les gains réalisables annuellement sur les projets sont supérieurs grâce à la qualité des
livrables. Les coûts annuels d’exploitation et de maintenance sont réduits par rapport à la
solution de développement, car cette solution nécessiterait de disposer d’un expert logiciel à
temps plein.
La solution proposée par Prosyst est la solution réalisable sans études complémentaires la plus
rentable comparée aux solutions de développement logiciel. Sachant que le développement
logiciel serait une solution ne générant pas de bénéfices.
278
Annexes
5.8.2 Calcul du temps de rentabilisation du projet
Tableau 25 : Etude du temps de rentabilisation des solutions

Etude de la rentabilité des Solution Odil Solution
solutions Gremlins développement
interne
Total des coûts de développement

284880 539280
des solutions (euros*)
104440 -560
Bénéfices annuels (en euros)
2014 -284880
2015 -180440
2016 -76000 -539280
2017 28440 -539840
2018 132880 -540400
2019 237320 -540960
2020 341760 -541520
2021 446200 -542080
2022 550640 -542640
2023 655080 -543200
2024 759520 -543760
2025 863960 -544320
2026 968400 -544880
2027 1072840 -545440
2028 1177280 -546000
2029 1281720 -546560
2030 1386160 -547120
2031 1490600 -547680
2032 1595040 -548240
2033 1699480 -548800
2034 1803920 -549360
2035 1908360 -549920
2036 2012800 -550480
2037 2117240 -551040
2038 2221680 -551600
2039 2326120 -552160
2040 2430560 -552720
279
Annexes
Le calcul du gain est réalisé à partir de l’année de mise en production du logiciel de

génération :
Gain à l’année n = Cumul des bénéfices à l’année n – Coûts de développement
L’étude de rentabilité sur 25 ans démontre clairement que la solution proposée par Prosyst est
la plus rentable.
Etude de la Total des coûts de Total des coûts de

rentabilité des prestation de développement
solutions Prosyst (phase 1) (phase 1)
Année de
2017 -
rentabilisation
La solution proposée en collaboration avec Prosyst est estimée rentable en trois années. Ce
qui correspond à une rentabilité de 1 pour 1, le temps de développement du projet étant
échelonné sur trois années. La solution de développement n’est pas rentable. Les bénéfices
générés par cette solution restent néanmoins relativement inférieurs à ceux espérés avec la
solution Odil GREMLINS.
280
Annexes
Annexe 6 : Fiches du cahier de recette de l’IMP
Fiche de test Réf Objet du test

C D 01 F N U/S Débouclage IMP
Conditions initiales
 IMP ouvert
 Tension injectée dans les BNU des Tt 6528-2 et Tt 6528-1= 0V~
 R.A. hors service et IMP en commande à distance.
 TSS 9 et 10 présentes
Actions à réaliser
1. Injecter 100V~ dans les BNU des Tt 6528-2 et Tt 6528-1.
2. Fermer les IMP (fermeture sous tension).
3. Couper l’injection de tension dans le BNU Tt 6528-1
4. Couper l’injection de tension dans le BNU Tt 6528-2
Résultats attendus
1. TSS 9 et 10 absentes.
2. IMP fermé.
3. TSS 10 présente.
4. TSS 10, 9 présentes. Ouverture de l’IMP.
Commentaires
 Prop1 : E<> CFIMP . U1
 Prop2 : E<> cf1IMP . cf2IMP . U1
 Prop3 : A[] not ( !U1 . cf1IMP . tprop )
ou E<> !U1 .cf1IMP . tprop  non vérifiée
 Prop4 : A[] not ( !U1 . co1IMP . tprop )
ou E<> !U1 .co1IMP . tprop  non vérifiée

Décisions
Correct Gênant Bloquant N° FFT
Usine : Usine :
Test réalisé par Date du test
Site Site
281
Annexes
Fiche de test Réf Objet du test

C E 01 F N U/S Réenclenchement Automatique
des Parallèles (RAP)
Conditions initiales
 IMP fermé depuis plus de 15min.
 Tension injectée dans les BNU des Tt 6528-2 & Tt 6528-1 = 100V~ depuis + de 15min.
 R.A. hors service.
 RAP en service (mise à 1 du paramètre « Mise en service de la fonction RAP »)
Actions à réaliser
1. Couper l’injecter dans les BNU des Tt 6528-2 & Tt 6528-1 simultanément (<1s) attendre
quelques secondes (<30s) et remettre l’injection 100V~ dans les BNU des Tt 6528-2 & Tt
6528-1 simultanément (<3s).
Résultats attendus
1. Ouverture IMP puis 10s après le retour de la présence tension sur les deux Tt,
réenclenchement IMP et TSS 14 (Fonctionnement RAP) présente durant le temps
paramétré.
Commentaires
 Prop3 : E<> X31 . cf1IMP . tprop ne doit pas être satisfaite
 Prop4 : E<> X24 . !cf1IMP . obs . tprop ne doit pas être satisfaite
Décisions
Correct Gênant Bloquant N° FFT
Usine : Usine :
Test réalisé par Date du test
Site Site
282
Annexes
Annexe 7 : Code de la commande A : Application du Design Pattern à la

commande la plus permissive
void sequentiel()
{
//Calcul des fronts
fmU1 = !U1_P && U1;

fdU1 = U1_P && !U1;
fm_COIMP= !COIMP_P && COIMP;

fd_COIMP= COIMP_P && !COIMP;
fm_CFIMP= !CFIMP_P && CFIMP;

fd_CFIMP= CFIMP_P && !CFIMP;
fm_co1IMP= !co1IMP_P && co1IMP;

fd_co1IMP= co1IMP_P && !co1IMP;

fm_cf1IMP= !cf1IMP_P && cf1IMP;

fd_cf1IMP= cf1IMP_P && !cf1IMP;

COnIMP = !COIMP;
CFnIMP = !CFIMP;
// obs = pas d ordre operateur depuis plus de 900 s
obs = not(COIMP) and not (CFIMP) and fintempo2 and fintempo4;
// GRAPHE COMMANDE CO OPerateur
if(X1 and not(COIMP))

{
X1=0;
X0=1;
}
if(X0 and COIMP and not(CFIMP))

{
X0=0;
X1=1;
}
283
Annexes
// GRAPHE COMMANDE CF OPerateur
if(X11 and not(CFIMP))

{
X11=0;
X10=1;
}
if(X10 and CFIMP and not(COIMP))

{
X10=0;
X11=1;
}
// Graphe RAP
if(X24 and (sfIMP or not(U1) or not(U2)))

{
X24=0;
X20=1;
}
if(X23 and not(obs))

{
X23=0;
X20=1;
}

{
X22=0;
X20=1;
}
if(X22 and fintempoX22 and obs)

{
X22=0;
X23=1;
}
if(X22 and not(fintempoX22) and X35 and obs)

{
X22=0;
X24=1;
}

{
X21=0;
X20=1;
}
if(X21 and ( not(U1) or not(U2) ) and not(sfIMP) and obs)

{
X21=0;
X22=1;
}
if(X20 and obs and sfIMP)
284
Annexes
{
X20=0;
X21=1;
}
// Graf Absences Tension
//X35
if(X35 and (sfIMP or not(obs)))
{
X35=0;
X30=1;
}
//X34
if(X34 and obs and (U1 and U2) and fintempoX34)
{
X34=0;
X35=1;
}
if(X34 and (not(obs) or (not(fintempoX34) and ( not(U1) or not(U2) ))))

{
X34=0;
X30=1;
}
//X33
if(X33 and obs and (U1 and U2) and not(fintempoX33))
{
X33=0;
X34=1;
}
if(X33 and ( not(obs) or fintempoX33))

{
X33=0;
X30=1;
}
//X32
if(X32 and obs and (U1 or U2))
{
X32=0;
X33=1;
}
if(X32 and obs)

{
X32=0;
X30=1;
}
//X31
if(X31 and ( not(obs) or fintempoX31) )
{
X31=0;
X30=1;
}
if(X31 and ( not(U1) and not(U2) ) and obs and not(fintempoX31))
285
Annexes
{
X31=0;
X32=1;
}
//X30
if(X30 and obs and X22 and (not(U1) or not(U2)))
{
X30=0;
X31=1;
}
// Contraintes
G10 = X0;
G11 = X0;
G12 = X11;
G13 = X11;
//co1IMP
F00 = not(U1) or not(U2) or (not(soIMP) and not(co1IMP_P));
F10 = false;
//co2IMP
F01 = false;
F11 = false;
//cf1IMP
F02 = (not(U1) or not(U2)) or ((X22 or X23)and not(cf1IMP_P)) or sfIMP or not(soIMP) and not(cf1IMP_P);
F12 = not(sfIMP) and U1 and U2 and cf1IMP_P or (X24 and U1 and U2 and not sfIMP);
//cf2IMP
F03 = false;
F13 = false;
/* STEP 1 : INIT */
Fc00 = false;
Fc10 = false;
Fc01 = false;
Fc11 = false;
Fc02 = false;
Fc12 = false;
Fc03 = false;
Fc13 = false;
Fc04 = false;
Fc14 = false;
Fc05 = false;
Fc15 = false;
Flag = true;
Cpt=0;
/* STEP 2 */
Ns = 4;
286
Annexes
Ncsc = 6;
while (Flag and Cpt < Ncsc)

{
S10 = not(F00) and (not(Fc00) and G10 or Fc10) or F10;

//S11 = not F01 and (not Fc01 and G11 or Fc11) or F11;
S11 = S10;
S12= not(F02) and (not(Fc02) and G12 or Fc12) or F12;

//S13 = not F03 and (not Fc03 and G13 or Fc13) or F13;
S13 = S12;
CSC1 = S12 and not(S10);

CSC5 = not(S10) and S11;
Flag = CSC1 or CSC2 or CSC3 or CSC4 or CSC5 or CSC6 ;
Cpt = Cpt+1;
Fc01 = CSC5;
Fc03 = CSC6;
Fc10 = CSC1;
Fc11 = CSC2 or CSC3;
Fc13 = CSC4;
/* STEP 3 */
if (Cpt==Ncsc)
{
S10= not(F00) and F10;
S11= S10;
S13= S12;
}
co1IMP = S10;
co2IMP = S11;
cf1IMP = S12;
cf2IMP = S13;
//Verif de violation des contraintes apres algo
CCSs1 = (not(U1) or not(U2)) and co1IMP;

CCSs2 = (not(soIMP) and not(co1IMP_P)) and co1IMP;
CCSs3 = (not(U1) or not(U2)) and cf1IMP;
CCSs4 = sfIMP and cf1IMP;
CCSs5 = not(sfIMP) and cf1IMP_P and U1 and U2 and not(cf1IMP);
CCSs6 = X24 and U1 and U2 and not (sfIMP) and not (cf1IMP) ;
CCSs7 = (X23 or X22) and not(cf1IMP_P) and cf1IMP;
287
Annexes
CCSs8 = not(soIMP) and not(cf1IMP_P) and cf1IMP;

CCSC1 = cf1IMP and not(co1IMP);
CCSC3 = co1IMP and not(co2IMP);
CCSC4 = cf1IMP and not(cf2IMP);
CCSC5 = not(co1IMP) and co2IMP;
CCSC6 = not(cf1IMP) and cf2IMP;
//Flag 1 CS violee apres algo

FlagCSpost = CCSs1 or CCSs2 or CCSs3 or CCSs4 or CCSs5 or CCSs6 or CCSs7 or CCSs8 or CCSC1 or
CCSC2 or CCSC3 or CCSC4 or CCSC5 or CCSC6;
//Si une contrainte est violee apres l algo, alors il y a une erreur dans la modelisation ou dans la commande alors
les evolutions des modeles sont bloquees
if((FlagCSpost))
{
Erreur=1;
}
// Memorisation fin de cycle
U1_P = U1;
soIMP_P = soIMP;
sfIMP_P = sfIMP;
COIMP_P = COIMP;
CFIMP_P = CFIMP;
co1IMP_P = co1IMP;
co2IMP_P = co2IMP;
cf1IMP_P = cf1IMP;
cf2IMP_P = cf2IMP;
288
Annexes
Annexe 8 : Code de la commande B : Commande actuelle SNCF traduite
void sequentiel()
{
//Calcul des fronts
fmU1 = !U1_P && U1;

fdU1 = U1_P && !U1;






COnIMP = !COIMP;
CFnIMP = !CFIMP;
// Trait Ent
OoIMP = not(U1);
//RAP originale version SNCF
// tempo sans commande opérateur Timer_1(EnHorRAP and not(T5) and not(RSU) and not(coIMP) and
not(cfIMP) and (sfIMP and U1 and U2 or T1), 10000) #900000) #(*900s = 15 minutes*)
oper = not(T5) and not(RSU) and not(COIMP) and not(CFIMP) and (sfIMP and U1 and U2 or T1);
// X31 Timer_2(EnHorRAP and not(T5) and not(RSU) and not(coIMP) and not(cfIMP) and T1 and (not(U1)
or not(U2)),1000) #(*1s*)
X31 = not(T5) and not(RSU) and not(COIMP) and not(CFIMP) and T1 and (not(U1) or not(U2));
//X33 Timer_3(EnHorRAP and not(T5) and not(RSU) and not(coIMP) and not(cfIMP) and T1 and (U1 or
U2),3000) #(*3s*)
X33 = not(T5) and not(RSU) and not(COIMP) and not(CFIMP) and T1 and (U1 or U2);
//X22 Timer_4(EnHorRAP and not(T5) and not(RSU) and T1 and R1,30000) #(*30s*)
X22 = not(T5) and not(RSU) and T1 and R1;
//X34 Timer_5(EnHorRAP and not(T5) and not(RSU) and T1 and R1 and soIMP and U1 and U2 and (not(T3)
or R2),10000) #(*10s*)
X34 = not(T5) and not(RSU) and T1 and R1 and soIMP and U1 and U2 and (not(T3) or R2);
289
Annexes
//trap Timer_6(EnHorRAP and not(T5) and not(RSU) and T1 and R1 and (T4 or R3),1000) #(*1s*)
trap = not(T5) and not(RSU) and T1 and R1 and (T4 or R3);
T1=not(T5) and not(RSU) and not(COIMP) and not(CFIMP) and (sfIMP and U1 and U2 or T1) and
fintempo1;
T2=not(T5) and not(RSU) and T1 and (not(U1) or not(U2)) and fintempoX31;
T3=not(T5) and not(RSU) and T1 and (U1 or U2) and fintempoX33;
R1=not(T5) and not(RSU) and T1 and (not(U1) and not(U2) and not(T2) or R1);
RSU=not(T5) and not(RSU) and T1 and R1 and fintempoRAP;
R2=not(T5) and not(RSU) and T1 and R1 and soIMP and U1 and U2 and (not(T3) or R2);
T4=not(T5) and not(RSU) and T1 and R1 and soIMP and U1 and U2 and (not(T3) or R2) and
fintempoX34;
R3=not(T5) and not(RSU) and T1 and R1 and (T4 or R3);
T5=not(T5) and not(RSU) and T1 and R1 and (T4 or R3) and trap;
OFRAP=not(T5) and not(RSU) and T1 and R1 and (T4 or R3) and not(T5);
fm_OFRAP= !OFRAP_P && OFRAP;

fd_OFRAP= OFRAP_P && !OFRAP;
// GRAF Sncf de Commande de l'IMP
//X4
if(X4 and fintempoX4)
{
X4=0;
X0=1;
}
//X3
if(X3 and soIMP and not(fintempoX3))
{
X3=0;
X0=1;
}
if(X3 and not(soIMP) and fintempoX3)

{
X3=0;
X4=1;
}
//X2
if(X2 and (COIMP or OoIMP) and sfIMP)
{
X2=0;
X3=1;
}
if(X2 and soIMP)

{
X2=0;
X0=1;
}
//X1
if(X1 and sfIMP and not(fintempoX1) )
{
X1=0;
290
Annexes
X2=1;
}
if(X1 and not(sfIMP) and fintempoX1)

{
X1=0;
X4=1;
}
//X0
if(X0 and soIMP and not(OoIMP) and (fm_CFIMP or fm_OFRAP))
{
X0=0;
X1=1;
}
if(X0 and sfIMP)

{
X0=0;
X2=1;
}
// Affectation des sorties
co1IMP = X1 or X2;
co2IMP = X1 or X2;
cf1IMP = X1;
cf2IMP = X1;
U1_P = U1;
U2_P = U2;
soIMP_P = soIMP;
sfIMP_P = sfIMP;
COIMP_P = COIMP;
CFIMP_P = CFIMP;
co1IMP_P = co1IMP;
co2IMP_P = co2IMP;
cf1IMP_P = cf1IMP;
cf2IMP_P = cf2IMP;
OFRAP_P = OFRAP;
291
Annexes
Annexe 9 : Code de la commande C : Application du Design Pattern à la

commande actuelle SNCF traduite
void sequentiel()
{
//Calcul des fronts
//Calcul des fronts
fmU1 = !U1_P && U1;

fdU1 = U1_P && !U1;







COnIMP = !COIMP;
CFnIMP = !CFIMP;
/***************** Commande Sncf ***********************************/
// Trait Ent
OoIMP = not(U1);
//RAP originale version SNCF
// tempo sans commande opérateur Timer_1(EnHorRAP and not(T5) and not(RSU) and not(coIMP) and
not(cfIMP) and (sfIMP and U1 and U2 or T1), 10000) #900000) #(*900s = 15 minutes*)
oper = not(T5) and not(RSU) and not(COIMP) and not(CFIMP) and (sfIMP and U1 and U2 or T1);
// XS31 Timer_2(EnHorRAP and not(T5) and not(RSU) and not(coIMP) and not(cfIMP) and T1 and (not(U1)
or not(U2)),1000) #(*1s*)
XS31 = not(T5) and not(RSU) and not(COIMP) and not(CFIMP) and T1 and (not(U1) or not(U2));
292
Annexes
//XS33 Timer_3(EnHorRAP and not(T5) and not(RSU) and not(coIMP) and not(cfIMP) and T1 and (U1 or
U2),3000) #(*3s*)
XS33 = not(T5) and not(RSU) and not(COIMP) and not(CFIMP) and T1 and (U1 or U2);
//XS22 Timer_4(EnHorRAP and not(T5) and not(RSU) and T1 and R1,30000) #(*30s*)
XS22 = not(T5) and not(RSU) and T1 and R1;
//XS34 Timer_5(EnHorRAP and not(T5) and not(RSU) and T1 and R1 and soIMP and U1 and U2 and (not(T3)
or R2),10000) #(*10s*)
XS34 = not(T5) and not(RSU) and T1 and R1 and soIMP and U1 and U2 and (not(T3) or R2);
//trap Timer_6(EnHorRAP and not(T5) and not(RSU) and T1 and R1 and (T4 or R3),1000) #(*1s*)
trap = not(T5) and not(RSU) and T1 and R1 and (T4 or R3);
T1=not(T5) and not(RSU) and not(COIMP) and not(CFIMP) and (sfIMP and U1 and U2 or T1) and
fintempoS1;
T2=not(T5) and not(RSU) and T1 and (not(U1) or not(U2)) and fintempoXS31;
T3=not(T5) and not(RSU) and T1 and (U1 or U2) and fintempoXS33;
R1=not(T5) and not(RSU) and T1 and (not(U1) and not(U2) and not(T2) or R1);
RSU=not(T5) and not(RSU) and T1 and R1 and fintempoSRAP;
R2=not(T5) and not(RSU) and T1 and R1 and soIMP and U1 and U2 and (not(T3) or R2);
T4=not(T5) and not(RSU) and T1 and R1 and soIMP and U1 and U2 and (not(T3) or R2) and
fintempoXS34;
R3=not(T5) and not(RSU) and T1 and R1 and (T4 or R3);
T5=not(T5) and not(RSU) and T1 and R1 and (T4 or R3) and trap;
OFRAP=not(T5) and not(RSU) and T1 and R1 and (T4 or R3) and not(T5);

// GRAF Sncf de Commande de l'IMP
//XS4
if(XS4 and fintempoXS4)
{
XS4=0;
XS0=1;
}
//XS3
if(XS3 and soIMP and not(fintempoXS3))
{
XS3=0;
XS0=1;
}
if(XS3 and not(soIMP) and fintempoXS3)

{
XS3=0;
XS4=1;
}
//XS2
if(XS2 and (COIMP or OoIMP) and sfIMP)
{
XS2=0;
XS3=1;
}
293
Annexes
if(XS2 and soIMP)

{
XS2=0;
XS0=1;
}
//XS1
if(XS1 and sfIMP and not(fintempoXS1) )
{
XS1=0;
XS2=1;
}
if(XS1 and not(sfIMP) and fintempoXS1)

{
XS1=0;
XS4=1;
}
//XS0
if(XS0 and soIMP and not(OoIMP) and (fm_CFIMP or fm_OFRAP))
{
XS0=0;
XS1=1;
}
if(XS0 and sfIMP)

{
XS0=0;
XS2=1;
}
// Affectation des sorties
co1IMPsncf = XS1 or XS2;

co2IMPsncf = XS1 or XS2;
cf1IMPsncf = XS1;
cf2IMPsncf = XS1;
/***************** Commande par contraintes ************************/
// obs = pas d ordre operateur depuis plus de 90 s (normalement 900s)
obs = not(COIMP) and not (CFIMP) and fintempo2 and fintempo4;
// Graphe RAP
if(X24 and (sfIMP or not(U1) or not(U2)))

{
X24=0;
X20=1;
}

{
X23=0;
294
Annexes
X20=1;
}

{
X22=0;
X20=1;
}
if(X22 and fintempoX22 and obs)

{
X22=0;
X23=1;
}
if(X22 and not(fintempoX22) and X35 and obs)

{
X22=0;
X24=1;
}

{
X21=0;
X20=1;
}
if(X21 and ( not(U1) or not(U2) ) and not(sfIMP) and obs)

{
X21=0;
X22=1;
}
if(X20 and obs and sfIMP)

{
X20=0;
X21=1;
}
// Graf Absences Tension
//X35
if(X35 and (sfIMP or not(obs)))
{
X35=0;
X30=1;
}
//X34
if(X34 and obs and (U1 and U2) and fintempoX34)
{
X34=0;
X35=1;
}
if(X34 and (not(obs) or (not(fintempoX34) and ( not(U1) or not(U2) ))))

{
X34=0;
X30=1;
295
Annexes
//X33
if(X33 and obs and (U1 and U2) and not(fintempoX33))
{
X33=0;
X34=1;
}
if(X33 and ( not(obs) or fintempoX33))

{
X33=0;
X30=1;
}
//X32
if(X32 and obs and (U1 or U2))
{
X32=0;
X33=1;
}
if(X32 and obs)

{
X32=0;
X30=1;
}
//X31
if(X31 and ( not(obs) or fintempoX31) )
{
X31=0;
X30=1;
}
if(X31 and ( not(U1) and not(U2) ) and obs and not(fintempoX31))

{
X31=0;
X32=1;
}
//X30
if(X30 and obs and X22 and (not(U1) or not(U2)))
{
X30=0;
X31=1;
}
// Contraintes
G10 = co1IMPsncf;
G11 = co2IMPsncf;
G12 = cf1IMPsncf;
G13 = cf2IMPsncf;
//co1IMP
F00 = not(U1) or not(U2) or (not(soIMP) and not(co1IMP_P));
F10 = false; //soIMP and U1 and U2;
//co2IMP
F01 = false;
296
Annexes
F11 = false;
//cf1IMP
F02 = (not(U1) or not(U2)) or ((X22 or X23) and not(cf1IMP_P)) or sfIMP or not(soIMP) and not(cf1IMP_P);
F12 = not(sfIMP) and U1 and U2 and cf1IMP_P or (X24 and U1 and U2 and not sfIMP);
//cf2IMP
F03 = false;
F13 = false;
/* STEP 1 : INIT */
Fc00 = false;
Fc10 = false;
Fc01 = false;
Fc11 = false;
Fc02 = false;
Fc12 = false;
Fc03 = false;
Fc13 = false;
Fc04 = false;
Fc14 = false;
Fc05 = false;
Fc15 = false;
Flag = true;
Cpt =0;
/* STEP 2 */
Ns = 4;
Ncsc = 6;
while (Flag and Cpt < Ncsc)

{
S10 = not(F00) and (not(Fc00) and G10 or Fc10) or F10;

/*Sl1 = not F01 and (not Fc01 and G11 or Fc11) or F11;*/
S11 =S10;
S12= not(F02) and (not(Fc02) and G12 or Fc12) or F12;

/*Sl3 = not F03 and (not Fc03 and G13 or Fc13) or F13;*/
S13 = S12;

Flag = CSC1 or CSC2 or CSC3 or CSC4 or CSC5 or CSC6 ;
Cpt = Cpt+1;
Fc01 = CSC5;
Fc03 = CSC6;
297
Annexes
Fc10 = CSC1;
Fc11 = CSC2 or CSC3;
Fc13 = CSC4;
/* STEP 3 */
if (Cpt==Ncsc)
{
S11= S10;
S13= S12;
}
co1IMP = S10;
co2IMP = S11;
cf1IMP = S12;
cf2IMP = S13;
//Verif de violation des contraintes apres algo
CCSs1 = (not(U1) or not(U2)) and co1IMP;

CCSs2 = (not(soIMP) and not(co1IMP_P)) and co1IMP;
CCSs3 = (not(U1) or not(U2)) and cf1IMP;
CCSs4 = sfIMP and cf1IMP;
CCSs5 = not(sfIMP) and cf1IMP_P and U1 and U2 and not(cf1IMP);
CCSs6 = X24 and U1 and U2 and not (sfIMP) and not (cf1IMP) ;
CCSs7 = (X23 or X22) and not(cf1IMP_P) and cf1IMP;
CCSs8 = not(soIMP) and not(cf1IMP_P) and cf1IMP;
CCSC3 = co1IMP and not(co2IMP);
CCSC4 = cf1IMP and not(cf2IMP);
CCSC5 = not(co1IMP) and co2IMP;
CCSC6 = not(cf1IMP) and cf2IMP;
//Flag 1 CS violee apres algo

FlagCSpost = CCSs1 or CCSs2 or CCSs3 or CCSs4 or CCSs5 or CCSs6 or CCSs7 or CCSs8 or CCSC1 or
CCSC2 or CCSC3 or CCSC4 or CCSC5 or CCSC6;
//Si une contrainte est violee apres l algo, alors il y a une erreur dans la modelisation ou dans la commande alors
les evolutions des modeles sont bloquees
if((FlagCSpost))
{
Erreur=1;
}
U1_P = U1;
U2_P = U2;
soIMP_P = soIMP;
sfIMP_P = sfIMP;
COIMP_P = COIMP;
298
Annexes
CFIMP_P = CFIMP;
co1IMP_P = co1IMP;
co2IMP_P = co2IMP;
cf1IMP_P = cf1IMP;
cf2IMP_P = cf2IMP;
OFRAP_P = OFRAP;
299
Annexes
Annexe 10 : Questionnaires des utilisateurs de la solution Odil Gremlins
Réponse n°1
Préface
1. Ressentiez-vous le besoin d'avoir un outil de productivité et de standardisation ?
  Oui,  Oui,  Ne sais pas  Non, pas  Non, pas du
pleinement éventuellement vraiment tout
2. Comment estimez-vous votre charge de travail sans la solution Gremlins ?

 0 100
3. Comment évalueriez-vous la qualité du code produit sans la solution Gremlins ?

 0 55 100
(Code inutilisable) (Code robuste, commenté, absence de code mort)
4. Quel a priori aviez-vous à propos de Gremlins ?
  Très positif  Positif  Neutre  Négatif  Très négatif
5. Quelles attentes aviez-vous en priorité de Gremlins ?

  Qualité  Productivité  Homogénéité  Ergonomie  Fiabilité
 Réduction du  Réduction  Optimisation  Autre : …
  Utilisabilité
nombre d’outils des erreurs de la charge
mentale
Utilisation de Gremlins
6. Trouvez-vous l’interface ergonomique (détailler éventuellement en sous point) ?
a. Description PO
  Très lisible  Lisible  Correcte  Peu lisible  Illisible
b. Architecture SCLA
c. Cahier de Recette
Non testé
7. Avez-vous facilement pris en main Gremlins ?
 Instantanément
 Après quelques explications
 Après quelques heures de manipulation
La manipulation a été réalisée conjointement avec M. Coupat vu les délais imposés par le
projet.
 Après quelques jours de manipulation
300
Annexes
 Toujours pas autonome
8. Gremlins vous a-t-il aidé dans la phase d’étude du système (répartition de la

commande des appareils ; synthèse des TC, TSS, SSL ; programmation) ?
a. Répartition du contrôle/commande des appareils dans les automates
  Oui  Non
b. Synthèse des TC / TSS / SSL
  Oui  Non
c. Programmation
  Oui  Non
d. Fichier de Paramétrage
  Oui  Non
Qualité de la génération
9. Comment évalueriez-vous globalement la qualité du code produit par la solution
Gremlins ?
 0 55 100
RQ : Code généré lorsque Gremlins était en phase de test/débugage
10. Les programmes générés sont-ils GAME en ce qui concerne :
a. La maintenabilité : Lisibilité
 Plus lisible  GAME  Moins lisible

b. La qualité/Efficacité : Absence de code mort, de variables non utilisées
 Plus efficace  GAME  Moins efficace

c. La standardisation
 Plus standard  GAME  Moins standard
11. Estimez-vous que Gremlins permette d’apporter une qualité supplémentaire aux
programmes et documents produits ?
  Tout à fait  D’accord  Neutre  Pas d’accord  Pas du tout
d’accord d’accord
12. Pensez-vous que Gremlins est la solution viable pour maintenir :

a. L’homogénéité
  Oui  Non
b. La qualité
  Oui  Non
c. La sécurité
  Oui  Non
301
Annexes
d. La fiabilité
  Oui  Non
e. La maintenance
  Oui  Non
13. Quel pourcentage du projet a pu être généré par Gremlins ? échelle sur 100%
 0 80 100
Rq : Code généré lorsque Gremlins était en phase de test/débugage. Certaines parties du code
n’avaient pas encore été programmées pour être générées.
Gain en production
Personnellement, je n’ai pas de point de comparaison car c’était mon premier projet. De plus,
le temps investi sur Gremlins et son code généré n’est absolument pas représentatif du gain
potentiel étant donné qu’il s’agissait d’une phase de test/débugage.
14. Combien estimez-vous avoir gagné de temps d’étude pour : (en heures)
a. La répartition du contrôle/commande des appareils dans les automates
 0 100
b. La synthèse des TC / TSS / SSL

 0 100
c. La programmation
 0 100
d. La rédaction du cahier de Recette

 0 100
15. Combien estimez-vous avoir gagné de temps en essai (optimisation du code) ? (en
heures)
 0 100
16. Comment estimez-vous votre charge de travail avec la solution Gremlins ?

 0 100
Avis personnel
17. Etes-vous prêt à utiliser Gremlins pour vos prochains projets ?

18. Quelles améliorations logicielles aimeriez-vous ? (Question ouverte)
302
Annexes
Réponse n°2
Préface
  Oui,  Oui,  Ne sais pas  Non, pas  Non, pas du

 0 >100

 0 100
Code robuste mais qui nécessiterait une remise au point
  Très positif  Positif  Neutre  Négatif  Très négatif

  Qualité  Productivité  Homogénéité  Ergonomie  Fiabilité
  Utilisabilité
mentale ( ???)
a. Description PO
 Instantanément
 Après quelques explications
303
Annexes

  Oui  Non
  Oui  Non
c. Programmation
  Oui  Non
  Oui  Non
Gremlins ?
 0 60 100
(Code inutilisable) (Code robuste qui nécessite des corrections dans le
cas de sous-stations non standardisées)



  Oui  Non
b. La qualité
  Oui  Non
c. La sécurité
  Oui  Non
d. La fiabilité
304
Annexes
  Oui  Non
e. La maintenance
  Oui  Non
 0 60 100
Gain en production
 0 100

 0 100
c. La programmation
 0 100

 0 100
heures)
 0 100

 0 100
(Réduction de la charge de travail)
Avis personnel

Possibilité de réduire les corrections en cas de structure non standard.
305
Annexes
Réponse n°3
Préface
  Oui,  Oui,  Ne sais pas  Non, pas  Non, pas du

Ce qui me prend le plus de temps ce n’est pas le code c’est tout le reste. La gestion de
projet, la validation des schémas, et le cahier de recette
0 25% 100
0 75 100
  Très positif  Positif  Neutre  Négatif  Très négatif
Pour le moment
 Qualité  Productivité  Homogénéité  Ergonomie  Fiabilité
 Utilisabilité
mentale
Y’a jamais d’erreurs, juste du code inutilisé.
a. Description PO
  Très lisible  Lisible  Correcte  Peu lisible  Illisible
  Très lisible  Lisible  Correcte  Peu lisible  Illisible
  Très lisible  Lisible  Correcte  Peu lisible  Illisible
Mais est-il à jour ?
 Instantanément
 Après quelques explications
306
Annexes

  Oui  Non
  Oui  Non
c. Programmation
  Oui  Non
  Oui  Non
Gremlins ?
 0 100


  Tout à fait  D’accord  Neutre  Pas d’accord  Pas du tout

  Oui  Non
b. La qualité
  Oui  Non
c. La sécurité
  Oui  Non
d. La fiabilité
307
Annexes
  Oui  Non
e. La maintenance
  Oui  Non
 0 100
Gain en production
 0 100

 0 100
c. La programmation
 0 100

 0 100
heures)
 0 100

 0 100
Avis personnel

  Tout à fait  D’accord  Neutre  Pas d’accord  Pas du tout
Si j’ai le temps. Pour résumer, pas le projet de quelqu’un d’autre et pas un projet avec
un groupement d’entreprises.
Qu’il fasse du 1,5kV=.
308
Annexes
Annexe 11 : Dictionnaire des variables
Tableau 26 : Dictionnaire des variables utilisées dans le chapitre 5

Variable Description
CFIMP Commande de fermeture par opérateur (modèle aléatoire)
COIMP Commande d’ouverture par opérateur (modèle aléatoire)
cf1IMP Sortie n°1 de commande de fermeture de l’IMP
cf2IMP Sortie n°2 de commande de fermeture de l’IMP
co1IMP Sortie n°1 de commande d’ouverture de l’IMP
co2IMP Sortie n°2 de commande d’ouverture de l’IMP
DefIMP Défaut de l’IMP
OfRAP Ordre de fermeture par la fonction RAP
obs Pas d’ordre opérateur (ouverture ou fermeture) depuis plus de 900s
RapEnService Activation ou inhibition de la fonction RAP
RSU « Reset tension » : temps maximum de la fonction RAP
sfIMP Signalisation de la position fermée de l’IMP
soIMP Signalisation de la position ouverte de l’IMP
tmpCFIMP Temps maximum de fermeture de l’IMP
tmpCOIMP Temps maximum d’ouverture de l’IMP
U1 Présence tension de la voie 1
U2 Présence tension de la voie 2
̅ Absence tension sur la voie 1 ou la voie 2 : ̅ ̅̅̅̅ ̅̅̅̅
VA9 (= U1) Présence tension de la voie 1
VA10 (= U2) Présence tension de la voie 2
309
Annexes
Annexe 12 : Vérification des propriétés sous UPPAAL
Commande A
Figure 119 : Vérification des propriétés de la commande A
310
Annexes
Commande B
Figure 120 : Vérification des propriétés de la commande B
311
Annexes
Commande C
Figure 121 : Vérification des propriétés de la commande C
312
Annexes
313
RESUME
Mots-clés : Systèmes à Evénements Discrets, Commande sûre de fonctionnement,
Génération de code API, Modélisation de Domaine Spécifique, Système Homme-Machine.
Le projet de recherche présenté dans cette thèse a été réalisé avec la collaboration de la
Direction de l’Ingénierie SNCF et le CReSTIC de l’Université de Reims Champagne-Ardenne
(URCA). L’objectif de ce projet est de contribuer à l’amélioration des études de conception
du contrôle/commande des projets d’électrification menées par les chargés d’études. Ce projet
doit répondre à des objectifs humains, économiques et techniques exprimés par la SNCF,
notamment appliqués au domaine des Equipements d’Alimentation des Lignes Electrifiées
(EALE). Pour répondre à ces problématiques, une méthodologie pour les études
d’automatisation est proposée. Elle intègre deux axes de recherche. Le premier axe est la
génération automatique de livrables (codes, documents, schémas…). Celle-ci repose
nécessairement sur une standardisation et une modélisation du « métier ». L’approche MDD
(Model Driven Development) du génie logiciel et l’approche DSM (Domain Specific
Modeling), apporte des éléments de solution reposant sur l’utilisation de « templates
métiers ». Toutefois, il est fondamental de générer des livrables de qualité et du code API
(Automates Programmables Industriels) sûr de fonctionnement. Le second axe de recherche
s’intéresse à la commande sûre de fonctionnement. Trois approches de synthèse de la
commande (la Supervisory Control Theory (SCT), la synthèse algébrique, la commande par
contraintes logiques) permettant a priori de répondre à ces objectifs de sûreté sont présentées
et discutées. La commande par contraintes logiques présente l’avantage majeur de séparer la
sécurité (qui est vérifiée formellement hors ligne par model-checking) et le fonctionnel, et de
pouvoir être utilisée avec des programmes API existants, ne remettant pas ainsi en cause la
méthodologie de travail des chargés d’études.
ABSTRACT
Keywords: Discrete Event System, safety control, PLC code generation, Domain
Specific Modeling, Human-Machine Interface.
The research project presented in this thesis has been realized with the collaboration of the
Engineer Department of the SNCF and the CReSTIC of the University of Reims Champagne-
Ardenne. The goal of this project is to contribute to the improvement of the control studies of
the electrification projects realized by the design engineers. This project must meet human,
economic and technical aims expressed by the SNCF applied to the field of the Power Supply
Equipments of the Electrified Lines (EALE in french). To answer these problems, a
methodology for the automation studies is proposed. It integrates two research orientations
were studied. The first axis is the automatic generation the deliverables (codes, documents,
diagrams…). This axis is based on standardization and modeling of the “work”. MDD (Model
Driven Development) and DSM (Domain Specific Modeling) approaches, brings suggestions
for solution based on the use of “work templates”. However, it is fundamental to generate
quality deliverables and safe PLC (Programmable Logic Controller) code. The second
research orientation is interested in safe control. Three approaches of control synthesis
(Supervisory Control Theory (SCT), the algebraic synthesis, the control by logical
constraints) permitting a priori to reach these aims of safety are presented and discussed. The
major advantage of the control by logical constraints is to separate the safety (which is
checked formally off line by model-checking) and the functional parts. It can be used with
existing PLC programs, which doesn’t change thus the working methodology of the design
engineers.
Génie Informatique, Automatique et Traitement du Signal - CReSTIC - UFR Sciences

Exactes et Naturelles - Moulin de la Housse - BP 1039 - 51687 Reims CEDEX 2 - FRANCE

COUPAT 2014 Archivage

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

COUPAT 2014 Archivage

Transféré par

Droits d'auteur :

Formats disponibles

UNIVERSITE DE REIMS CHAMPAGNE-ARDENNE

Présentée pour obtenir le grade de

Docteur de l’Université de Reims Champagne-Ardenne

Présentée et soutenue publiquement le 27 novembre 2014 par

Méthodologie pour les études d’automatisation et la génération

Devant un jury composé de :

Mes remerciements s’adressent aux rapporteurs, Madame Subias Audine et Monsieur

Je tiens à remercier la direction du département PROJETS SYSTEME INGENIERIE de

Figure 1 : Schéma d’alimentation d’une ligne par les sous-stations. ....................................... 25

Notations Symboles Significations

TSA Transformateur de Services Auxiliaires

T Transformateur de Groupe Traction

Glossaire : extrait du règlement (S11, 2012)

Circulation électrique : toute circulation comportant au moins un pantographe.

Circuit en charge : Circuit dans lequel s’opère un débit de courant électrique.

Appareil d’interruption : Permet d’assurer une continuité électrique en position fermée et

Disjoncteur : appareil d’interruption, manœuvrable à vide et en charge, destiné à ouvrir ou

Interrupteur : Appareil d’interruption, manœuvrable à vide ou en charge, destiné à ouvrir ou

Sectionneur : Appareil d’interruption, destiné à ouvrir ou fermer volontairement un circuit.

Secteurs : Ensemble des installations alimentées normalement par un ou plusieurs

Section de séparation : Partie de caténaire comportant à chaque extrémité, un sectionnement

contribuer à l’amélioration des études de conception du contrôle/commande des projets

Le quatrième chapitre présente l’application de la méthodologie aux études d’automatisation

Le cinquième et dernier chapitre présente l’application du deuxième axe de la méthodologie

1.2 Organisation du réseau électrique

1.2.1 Les systèmes de traction ferroviaire

1.2.2 Rôle des Sous-stations

Figure 1 : Schéma d’alimentation d’une ligne par les sous-stations.

Figure 2 : Représentation simple d’une sous-station 1,5 KV et 25 KV

1.3 L’alimentation électrique

1.3.1 L’alimentation en courant continu 1500 V

Figure 3 : Schéma d’alimentation des caténaires en 1500V

1.3.2 L’alimentation en courant alternatif monophasé 25 KV 50 Hz

Figure 4 : Schéma d’alimentation des caténaires en 25KV

1.3.3 L’alimentation en courant alternatif 2x25KV 50 Hz

Figure 5 : Schéma d’alimentation des lignes en 2x25KV

Le travail présenté dans ce manuscrit concerne essentiellement les installations assurant

1.3.4 Architecture d’un secteur caténaire 25KV ou 2x25KV

Tableau 1 : Tableau descriptif des EALE et des fonctions élémentaires associées

Postes de traction électrique (PTE)

Poste de sous-sectionnement Poste assurant la continuité ou la séparation électrique

Poste de Ligne (L) Poste assurant la continuité ou la séparation entre sections

Poste d'alimentation (A) Poste assurant l'alimentation de caténaires secondaires.

Poste d’injection (J) Poste comprenant des autotransformateurs pour injecter la

1.3.5 Architecture d’une sous-station 25KV/2x25KV

Le schéma unifilaire de la sous-station de « Commune » (Figure 6) qui appartient à la ligne à

Figure 6 : Schéma unifilaire de la sous-station de Commune (2x25KV)

1.4 Système de contrôle/commande des EALE

Le système de contrôle/commande des EALE est un système distribué et hiérarchisé (Figure

Figure 7 : Schéma de l’architecture hiérarchisée de contrôle/commande.

Figure 8 : Synoptique de la CLE de la sous-station de Velars

1.4.1 Architecture SCADA

Figure 9 : Photo du Central Sous-Station de Paris Rive Gauche

1.4.2 Architecture de Conduite Local et d’Automatismes

La principale caractéristique du système de contrôle-commande-protection est la répartition

Tableau 2 : Tableau des éléments fonctionnels PA

1.4.2.2 Le système SCLA

Figure 10 : Représentation de la chaîne de communication

Figure 11 : Schéma de l’architecture distribuée du contrôle/commande au sein des sous-

1.4.2.3 Les différents types d’abonnés

Tableau 3 : Eléments fonctionnels des abonnés du SCLA

1.5 Sûreté du fonctionnement du système de contrôle/commande

1.5.1 Définition de la sûreté du fonctionnement dans le domaine des EALE