raphaël coupat méthodologie pour les études d'automatisation et

UNIVERSITE DE REIMS CHAMPAGNE-ARDENNE

T H E S E

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

Mme Subias Audine

Professeur à l’Ecole Centrale de Lille

Maître de conférences HDR à l’Université de Toulouse

Président du jury :

M. Lahaye Sébastien

Co-Encadrants de Thèse :

Professeur à l’Université d'Angers

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

3

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.

4

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.

5

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

Les systèmes de traction ferroviaire .............................................................................................. 23 1.2.1 Rôle des Sous-stations ................................................................................................................... 24 1.2.2

1.3 L’ALIMENTATION ELECTRIQUE ......................................................................................................................... 26 L’alimentation en courant continu 1500 V .................................................................................... 27 1.3.1 L’alimentation en courant alternatif monophasé 25 KV 50 Hz ..................................................... 28 1.3.2 L’alimentation en courant alternatif 2x25KV 50 Hz ...................................................................... 29 1.3.3 Architecture d’un secteur caténaire 25KV ou 2x25KV ................................................................... 30 1.3.4 Architecture d’une sous-station 25KV/2x25KV .............................................................................. 31 1.3.5

1.4 SYSTEME DE CONTROLE/COMMANDE DES EALE................................................................................................. 32 Architecture SCADA ....................................................................................................................... 34 1.4.1 Architecture de Conduite Local et d’Automatismes ...................................................................... 35 1.4.2

Le système PA ...................................................................................................................................... 35 1.4.2.1 Le système SCLA .................................................................................................................................. 36 1.4.2.2 Les différents types d’abonnés ............................................................................................................ 38 1.4.2.3

1.5 SURETE DU FONCTIONNEMENT DU SYSTEME DE CONTROLE/COMMANDE ................................................................. 39 Définition de la sûreté du fonctionnement dans le domaine des EALE ......................................... 39 1.5.1

Fiabilité ................................................................................................................................................ 39 1.5.1.1 Maintenabilité ..................................................................................................................................... 40 1.5.1.2 Disponibilité......................................................................................................................................... 40 1.5.1.3 Sécurité des abonnés .......................................................................................................................... 40 1.5.1.4 Événement critique redouté ............................................................................................................... 41 1.5.1.5 Intégrité des données .......................................................................................................................... 41 1.5.1.6

Sûreté du fonctionnement des cartes Entrées/Sorties .................................................................. 41 1.5.2 Carte 4 Télé Commandes Doubles / 4 Télé Signalisations Doubles (4TCD/TSD).................................. 42 1.5.2.1 Carte 16 Télé Signalisations Simples (16 TSS) ...................................................................................... 42 1.5.2.2

1.6 PROGRAMMES BINAIRES OU NOYAU ISAGRAF ................................................................................................. 43 Description des programmes automates ...................................................................................... 45 1.6.1

Programme de la phase « Début » ...................................................................................................... 46 1.6.1.1 Programmes séquentiels (SFC) ............................................................................................................ 47 1.6.1.2 Programmes de fin de cycle ................................................................................................................ 47 1.6.1.3

Synthèse ........................................................................................................................................ 48 1.6.21.7 LE METIER DES EALE .................................................................................................................................... 48 1.8 CONCLUSION .............................................................................................................................................. 51

6

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

Composante économique et technique ......................................................................................... 56 2.2.1 Composante humaine ................................................................................................................... 56 2.2.2

2.3 1ER

AXE D’AMELIORATION : LA GENERATION AUTOMATIQUE DE LIVRABLES ............................................................... 59 UML ou MDD pour la génération de code ? .................................................................................. 60 2.3.1 Principes de la génération de code par MDA et DSM .................................................................... 61 2.3.2

Principes du MDA ................................................................................................................................ 61 2.3.2.1 Principes du DSM................................................................................................................................. 64 2.3.2.2 Avantages de DSM pour le domaine spécifique métier ...................................................................... 65 2.3.2.3

Synthèse des deux philosophies MDA et DSM ............................................................................... 66 2.3.3 Examen des méthodes et des techniques de génération de code ................................................. 67 2.3.4

Les approches de génération de code ................................................................................................. 67 2.3.4.1 Les types de générateur de code ......................................................................................................... 67 2.3.4.2 Les techniques de génération du code ................................................................................................ 69 2.3.4.3

Solutions DSM pour les automatismes industriels......................................................................... 72 2.3.5 Présentation de la solution Odil de la société Prosyst ................................................................... 76 2.3.6

La solution Odil .................................................................................................................................... 77 2.3.6.1 Visual Standard : Solution de développement du Progiciel SNCF EALE ............................................... 77 2.3.6.2

Synthèse ........................................................................................................................................ 79 2.3.72.4 2

EME AXE D’AMELIORATION : LA COMMANDE...................................................................................................... 80

Approches de conception de la commande : le cas des EALE ........................................................ 80 2.4.1 La SCT (Supervisory Control Theory) .............................................................................................. 84 2.4.2 La synthèse algébrique .................................................................................................................. 86 2.4.3 La commande par contraintes logiques ........................................................................................ 90 2.4.4 Validation et Vérification : V&V .................................................................................................... 94 2.4.5

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

Standardisation des programmes ............................................................................................... 108 3.4.1 Qualimétrie du code API .............................................................................................................. 109 3.4.2 Analyse par PLC Checker ............................................................................................................. 111 3.4.3 Formalisation des langages ......................................................................................................... 115 3.4.4 Analyse structurelle pour la modélisation du système ................................................................ 116 3.4.5

Décomposition de la Partie Opérative ............................................................................................... 117 3.4.5.1 Décomposition de la Partie Commande ............................................................................................ 119 3.4.5.2 Liens entre PO et PC .......................................................................................................................... 120 3.4.5.3

Définition des templates de génération de code ......................................................................... 121 3.4.6 Outil de mise en œuvre de la génération .................................................................................... 123 3.4.7

3.5 DEMARCHE DE GENERATION DU FILTRE A BASE DE CONTRAINTES DE SECURITE ........................................................ 126 Définition du filtre robuste à base de contraintes ....................................................................... 128 3.5.1

Principe d’écriture des contraintes ................................................................................................... 130 3.5.1.1 Démarche de définition des contraintes ........................................................................................... 131 3.5.1.2

Propriétés des contraintes ........................................................................................................... 133 3.5.2 Algorithme de la commande basée sur les contraintes logiques ................................................ 135 3.5.3

Prise en considération des CSs et des CFs ......................................................................................... 136 3.5.3.1 Prise en considération des CSc .......................................................................................................... 139 3.5.3.2

Synthèse ...................................................................................................................................... 142 3.5.43.6 CONCLUSION ............................................................................................................................................ 143

7

CHAPITRE 4 : APPLICATION DE LA METHODOLOGIE AUX ETUDES D’AUTOMATISATION DES EALE ............... 145

4.1 INTRODUCTION.......................................................................................................................................... 145 4.2 ANALYSE DU SYSTEME ................................................................................................................................. 146

Partie HT ...................................................................................................................................... 148 4.2.1 Groupe Traction........................................................................................................................... 151 4.2.2 Départ Traction ........................................................................................................................... 153 4.2.3 Batterie de Condensateurs .......................................................................................................... 154 4.2.4 Communs ..................................................................................................................................... 155 4.2.5

Barre 25kV ......................................................................................................................................... 156 4.2.5.1 Pontage ............................................................................................................................................. 156 4.2.5.2

4.3 STANDARDISATION ET ANALYSE DU CODE ........................................................................................................ 157 Etudes des principes d’automatisation des EALE ........................................................................ 158 4.3.1 Etude minutieuse des programmes pour la standardisation ...................................................... 158 4.3.2 Analyse des résultats PLC Checker............................................................................................... 159 4.3.3

4.4 FORMALISME DES LANGAGES ........................................................................................................................ 163 Structure de fichiers IsaGraf 3.32 ................................................................................................ 163 4.4.1 Grammaire du fichier source du dictionnaire .............................................................................. 164 4.4.2 Grammaire du fichier source d’un sous-programme ................................................................... 165 4.4.3 Grammaire du fichier source d’un sous-programme Ladder Diagram ........................................ 165 4.4.4

4.5 DEFINITION DE LA STRUCTURE DU MODELE ...................................................................................................... 168 Méta-modèle et modèle de PO ................................................................................................... 168 4.5.1 Modèle d’associations entre PO et PC ......................................................................................... 170 4.5.2 Modèles des SePO ....................................................................................................................... 171 4.5.3

4.6 GENERATION DE CODE ET DOCUMENTS ........................................................................................................... 172 Choix d’une solution pour la génération de livrables .................................................................. 172 4.6.1 Odil GREMLINS ............................................................................................................................ 175 4.6.2

4.7 DEFINITION DES TEMPLATES DANS VISUAL STANDARD ....................................................................................... 183 Génération des fichiers d’un projet ............................................................................................. 183 4.7.1 Template d’un fichier ST .............................................................................................................. 184 4.7.2 Template d’un fichier LD.............................................................................................................. 186 4.7.3

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

Quelles attentes de la solution ? ............................................................................................. 197 4.10.1 Utilisation ............................................................................................................................... 197 4.10.2 Gains ....................................................................................................................................... 198 4.10.3 Synthèse des résultats ............................................................................................................ 199 4.10.4

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

Principe fonctionnel du RAP actuel .............................................................................................. 207 5.2.1 Programmes API actuels ............................................................................................................. 209 5.2.2

Programme de Commande de l’IMP ................................................................................................. 210 5.2.2.1 Programme de la fonction DAP ......................................................................................................... 211 5.2.2.2 Programme de la fonction RAP ......................................................................................................... 211 5.2.2.3

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

Définition des observateurs et des contraintes ........................................................................... 217 5.4.1 Description des observateurs ............................................................................................................ 217 5.4.1.1 Contraintes de Sécurité simples ........................................................................................................ 220 5.4.1.2 Contraintes de Sécurité combinés ..................................................................................................... 222 5.4.1.3

Contraintes Fonctionnelles simples ............................................................................................. 224 5.4.2 Prise en considération des CSs et des CFs .................................................................................... 224 5.4.3 Prise en considération des CSc .................................................................................................... 225 5.4.4

8

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 Présentation d’UPPAAL ............................................................................................................... 229 5.6.1 Modèle de Partie Opérative ........................................................................................................ 230 5.6.2

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

Calcul des bénéfices ..................................................................................................................... 278 5.8.1 Calcul du temps de rentabilisation du projet ............................................................................... 279 5.8.2

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

9

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

10

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

11

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 Figure 68 : Technique basée sur les templates, le méta-modèle du métier et la grammaire de

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

12

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

13

Glossaire, abréviations et symboles

Abréviations

Abréviations Décompositions AA API ACS Batt. K BT CES CdCF CdG (WD) CF CFs CF CO CG CSc CSs CSS CLE CReSTIC DAP Déf. C DJ DSM DT EALE ElPO EN FMDS FICTIF FIP FG GREMLINS GT HT IEC IFTE IHM IMP IPA LD LDI LGV LS

Abonné Automate Automate Programmable Industriel Automate de Conduite Sécurisée Batterie de Condensateurs Basse Tension Conception et Expertise des Systèmes Cahier des Charges Fonctionnelles Chien de Garde (ou WatchDog) Contrainte Fonctionnelle Contrainte Fonctionnelle simple Commande Fermeture Commande Ouverture Contrôle Général Contrainte de Sécurité combinée Contrainte de Sécurité simple Central Sous-Station Commande Locale Ecran Centre de Recherche en STIC Déclenchement Automatique des Parallèles Défaut Complémentarité sur TSD ou TSS Disjoncteur Domain Specific Modeling Départ Traction Equipement d’Alimentation des Lignes Electrifiées Elément de Partie Opérative Norme Européenne Fiabilité Maintenabilité Disponibilité Sécurité Organe interne à l’équipement de télécommande servant de test Factory Information Protocol (RLI du SCLA) Fournié Grospaud GénéRateur Evolutif du Modèle et des LIvrables des Nouvelles Sous-stations Groupe Traction Haute Tension International Electrotechnical Commission Installation Fixe de Traction Electrique Interface Homme Machine Interrupteur de Mise en Parallèle Interface de Programmation d’Application Ladder Diagram (langage de programmation API) Led de contrôle du mode de commande « Local Individuel » Ligne à Grande Vitesse Ligne Spécialisée (quarte téléphonique pour les applications SNCF)

14

Abréviations Décompositions MDA MDD ODIL Organe PA PC PLC PO PSIGT PSIGT-TE RAP RFF RFN RLI RSS RTU RTE SCLA Sect SePO SF SFC SIL SHM SNCF SO SP (poste) SRB SSL SCT ST STIC TC TCO TCD TPL TSD TSS TM U (U1, U2) URCA UTE XML

Model Driven Architecture Model Driven Development Outil Description d’Ilots Désigne une TC, TSS ou TM Poste Asservi (aussi appelé Équipement de Télécommande) Partie Commande Programmable Logic Controller, acronyme anglais pour API Partie Opérative Département PROJETS SYSTEME INGENIERIE (SNCF) Département PROJETS SYSTEME INGENIERIE Traction Electrique Réenclenchement Automatique des Parallèles Réseau Ferré de France Réseau Ferré National Réseau Local Industriel Régulateur Sous-Station Remote Terminal unit Réseau de Transport d’Electricité Système de Conduite Locale et d’Automatismes Sectionneur Sous Ensemble de Partie Opérative (découpage fonctionnel GT, DT…) Signalisation position fermée de l’appareil Sequential Function Chart (langage de programmation API) Security Integrity Level Système Homme Machine Société Nationale des Chemins de Fer français Signalisation position ouverte de l’appareil Poste de sectionnement et de mise en parallèle Sectionneur à Rupture Brusque Signalisation Simple Locale Supervisory Control Theory Structured Text (langage de programmation API) Sciences et Technologies de l'Information et de la Communication Organe de Télé Commande Tableau de Contrôle Optique Télé Commande Double Tourner Pousser Lumineux Télé Signalisation Double (associée à une TCD) Télé Signalisation Simple Télé Mesure Tension (présence tension voie 1, présente tension voie 2) Université de Reims Champagne-Ardenne Union Technique de l'Electricité eXtensible Markup Language

15

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.

16

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.

17

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


18

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.


19

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.


20

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


21

œ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.

23

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

Les systèmes de traction ferroviaire 1.2.1

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


24

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.

Rôle des Sous-stations 1.2.2

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.


25

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.


26

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


27

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

L’alimentation en courant continu 1500 V 1.3.1

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.


28

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

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

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).


29

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

L’alimentation en courant alternatif 2x25KV 50 Hz 1.3.3

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.


30

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.

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

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


31

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 (SS)

Poste assurant la continuité ou la séparation électrique 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) (en 2x25KV)

Poste comprenant des autotransformateurs pour injecter la tension en opposition de phase du feeder sur la caténaire.

Architecture d’une sous-station 25KV/2x25KV 1.3.5Les 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.


32

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.

HT

GT

DT


33

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


34

Architecture SCADA 1.4.1

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


35

Architecture de Conduite Local et d’Automatismes 1.4.2

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.

Le système PA 1.4.2.1

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.


36

Tableau 2 : Tableau des éléments fonctionnels PA

Abonné Eléments Fonctionnels spécifiques

Fonction Abonné

PA (Selon architecture

du système PA)

Base PA Configuration, paramétrage, choix du mode de fonctionnement par

téléchargement depuis le PC via un coupleur V24 ou USB Communication avec les E/S déportées Interface aide à la maintenance de l’abonné et du support Signalisation de fonctionnement par led en face avant (mode RUN, Arbitre

de bus, défaut Configuration, Défaut Chien de Garde, …) 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

Le système SCLA 1.4.2.2

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


37

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


38

Les différents types d’abonnés 1.4.2.3

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

Abonnés A1 à A4 et A6 Fonctions communes

Configuration, paramétrage, choix du mode de fonctionnement par téléchargement depuis le PC via un coupleur V24 ou USB

Interface aide à la maintenance de l’abonné et du support Signalisation de fonctionnement par led en face avant (mode RUN, Arbitre

de bus, défaut Config, Défaut CdG, …) Abonnés A1 à A4

Fonctions communes Communication avec le RLI et Ethernet Arbitre de Bus potentiel

A1 RTU

Gestion du protocole de communication avec le CSS (HNZ) Applicatif SNCF (gestion de la datation par le protocole de communication) Configuration des paramètres de téléconduite (Vitesse de dialogue, Adresse

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

A2 Contrôle/commande

locale

Lecture des variables sur le RLI Affichage des informations sur le CLE Archivage des données de télégestion Conduite de l’installation en cas de contrôle local général

Abonnés A3 et A4 Fonctions communes

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 Terminal de dialogue pour paramétrage de variables de conduite (TSS

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, …)

Gestion d’un pupitre de commande locale individuelle

A3 Automate avec liaison

protection (Départs 25KV, Départs

1500V, Groupe Traction,....)

Acquisition des Entrées TOR (TSD, TSS et SSL) et des valeurs analogiques issues des capteurs

Exécution des séquences d’automatismes en fonction des variables externes et internes,

Gestions de liaisons pour communication (Modbus maître, IP) avec des protections numériques, des équipements d’interface de convertisseur de puissance spécifiques (compensateur de déséquilibre, survolteur, CVS 1,5KV=, 15KV 16 ,7Hz, …)

A4 Automate simple

(Partie commune)

Acquisition des Entrées TOR : TSD, TSS et SSL Exécution des séquences de contrôle et commande pour 8 Organes

A5

Automate déporté Réserve pour un abonné déporté

A6 Automate Programmable

seul (non connecté au RLI)

Configuration séquences (applicatif SNCF) Intégration des séquences d’automatisme Exécution des séquences Gestions de liaisons pour communication (Modbus maître, IP) avec d’autres

équipements Gestion d’un pupitre de commande locale individuelle


39

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).

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

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).

Fiabilité 1.5.1.1

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.


40

Maintenabilité 1.5.1.2

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.

Disponibilité 1.5.1.3

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 :

100

MTTRMTBFMTBFA

L’ensemble de l’équipement de télécommande doit répondre à la classe A3 (Disponibilité

supérieure à 99,95%).

Sécurité des abonnés 1.5.1.4

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).


41

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 ».

Événement critique redouté 1.5.1.5

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.

Intégrité des données 1.5.1.6

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.

Sûreté du fonctionnement des cartes Entrées/Sorties 1.5.2

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é.


42

Carte 4 Télé Commandes Doubles / 4 Télé Signalisations Doubles (4TCD/TSD) 1.5.2.1

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

Carte 16 Télé Signalisations Simples (16 TSS) 1.5.2.2

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*).


43

Entrée 1

Entrée 2

C24V=

C48V=

Led Verte

Led Verte

Electronique de Signalisation

8 Blocs de signalisations S1-S2, S3-4,.........à S15-S16

C125V=

Led Rouge Défaut Module TSS

Entrées

Com (*)

(*) 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…


44

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.


45

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.

Description des programmes automates 1.6.1

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


46

Programme de la phase « Début » 1.6.1.1

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.


47

Programmes séquentiels (SFC) 1.6.1.2

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.

Programmes de fin de cycle 1.6.1.3

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


48

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.

Synthèse 1.6.2

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


49

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


50

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

paramétrage 50h

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


51

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


52

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.

53

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

Chapitre 2 : Etude des voies d’amélioration possible du métier des EALE

54

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,


55

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


56

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.

Composante économique et technique 2.2.1

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.

Composante humaine 2.2.2

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


57

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


58

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.


59

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


60

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.

UML ou MDD pour la génération de code ? 2.3.1

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


61

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.

Principes de la génération de code par MDA et DSM 2.3.2

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.

Principes du MDA 2.3.2.1

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.


62

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


63

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.


64

Principes du DSM 2.3.2.2

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.


65

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.

Avantages de DSM pour le domaine spécifique métier 2.3.2.3

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


66

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).

Synthèse des deux philosophies MDA et DSM 2.3.3

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.


67

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.

Examen des méthodes et des techniques de génération de code 2.3.4

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.

Les approches de génération de code 2.3.4.1

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.

Les types de générateur de code 2.3.4.2

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


68

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.


69

Les techniques de génération du code 2.3.4.3

(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.


70

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.


71

(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é d’apprentissage

Utilisabilité pour les systèmes complexes

Utilisabilité pour les transformations de

modèles vers le code

Template + Filtrage Simple Pas très bonne Bonne

Template + Méta-Modèle Haute Très bonne Très bonne

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.


72

Solutions DSM pour les automatismes industriels 2.3.5

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


73

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.


74

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.


75

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


76

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.

Présentation de la solution Odil de la société Prosyst 2.3.6

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


77

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é.

La solution Odil 2.3.6.1

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.

Visual Standard : Solution de développement du Progiciel SNCF EALE 2.3.6.2

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é …).


78

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


79

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.

Synthèse 2.3.7

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.


80

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.

Approches de conception de la commande : le cas des EALE 2.4.1

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


81

(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


82

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).


83

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.


84

La SCT (Supervisory Control Theory) 2.4.2

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


85

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


86

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.

La synthèse algébrique 2.4.3

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) :


87

- 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 :


88

∏ (

)

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 :


89

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.


90

La commande par contraintes logiques 2.4.4

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.


91

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


92

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.


93

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


94

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.

Validation et Vérification : V&V 2.4.5

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


95

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.


96

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).


97

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


98

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


99

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

101

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

Chapitre 3 : Proposition d’une méthodologie pour les études d’automatisation

102

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


103

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.

Figure 33 : Méthodologie pour les études d’automatisation et la génération automatique de livrables


104

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 » :


105

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


106

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


107

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


108

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é.

Standardisation des programmes 3.4.1

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


109

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.

Qualimétrie du code API 3.4.2

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.


110

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)


111

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.

Analyse par PLC Checker 3.4.3

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.


112

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 :


113

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.


114

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.


115

Formalisation des langages 3.4.4

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.


116

Figure 39 : Technique basée sur les templates, le méta-modèle du métier et la grammaire de

l’Interface de Programmation

Analyse structurelle pour la modélisation du système 3.4.5

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 ?


117

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.

Décomposition de la Partie Opérative 3.4.5.1

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

SePO

1 *

ElPO

1 *

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.


118

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

GT

1 *

Transfo.

1 *

DT Batt. K

1 *11

*

11

Dj DT

1 *

TdC

11..21

1..2

1

Dj GT

1

*

1

1

1

SRB

1

*

1 1

1

DK

1

*

SK

1

1..21

1

1

0..11..2

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.


119

Décomposition de la Partie Commande 3.4.5.2

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 Sorties

Entrée

Carte E/S

Sortie

1 *

1

*

1

*

1

*

1

*

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.


120

Liens entre PO et PC 3.4.5.3

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.

Partie Opérative

SePO

1 *

ElPO

1 *

Partie Commande

API

1 *

Base

1

* 1 *

1 1

1 1

1

1..*

11

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.


121

Définition des templates de génération de code 3.4.6

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.


122

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.


123

Outil de mise en œuvre de la génération 3.4.7

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


124

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.


125

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)


126

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é


127

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.


128

Définition du filtre robuste à base de contraintes 3.5.1

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.


129

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.


130

Principe d’écriture des contraintes 3.5.1.1

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).


131

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é.

Démarche de définition des contraintes 3.5.1.2

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


132

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.


133

Figure 50 : Démarche de définition des contraintes

Propriétés des contraintes 3.5.2

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)


134

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 :


135

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)

Algorithme de la commande basée sur les contraintes logiques 3.5.3

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).


136

Figure 51 : Schéma d’entrées et sorties de l’algorithme (et de son Design Pattern)

Prise en considération des CSs et des CFs 3.5.3.1

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


137

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.


138

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)

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.

0 0 (f0) 0 (f0) X (0 or 1)0 0 (f0) 0 (f0) X (0 or 1)0 0 (f0) 1 (f1) 1 (f1)0 1 1 0

abcd

S’k00

00011110

01 11 10

0 0 (f0) 0 (f0) X (0 or 1)0 0 (f0) 0 (f0) X (0 or 1)0 0 (f0) 1 (f1) 1 (f1)0 1 1 0

abcd

S’k00

00011110

01 11 10


139

{

(18)

Figure 54 : Exemple avec des caractéristiques fonctionnelles fausses

Le prochain paragraphe montre comment traiter les contraintes de sécurité combinées (CSc).

Prise en considération des CSc 3.5.3.2

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

0 0 (f0) 0 (f0) X (0 or 1)0 0 (f0) 0 (f0) X (0 or 1)0 0 (f0) 1 (f1) 1 (f1)0 1 1 0

abcd

S’k00

00011110

01 11 10


140

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)


141

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


142

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).

Synthèse 3.5.4

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.


143

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).


144

145

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.

Chapitre 4 : Application de la méthodologie aux études d’automatisation des EALE

146

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.


147

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


148

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)

Partie HT 4.2.1

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.


149

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.


150

3 3

SHT1

DJHT1

SBHT1 SBHT2

SHT2

DJHT2

GT1 GT3 GT2

Arrivée HT 1

Arrivée HT 2

AAi AAj

AAk

so/sf, Défauts

CO/CFAbonné Automate

Arrivée HT i

RLI tempos

so/sf, Défauts

CO/CFAbonné Automate

Arrivée HT j

RLI tempos

so/s

f,D

éfa

uts

CO

/CF

Abonné Automate Commun k

RLI tempos

RTE

RFN

SHT3 SHT4

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.


151

Groupe Traction 4.2.2

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.


152

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


153

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).

Départ Traction 4.2.3

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.


154

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

Batterie de Condensateurs 4.2.4

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


155

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

Communs 4.2.5

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…


156

Barre 25kV 4.2.5.1

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.

Pontage 4.2.5.2

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.


157

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.


158

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.

Etudes des principes d’automatisation des EALE 4.3.1

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.

Etude minutieuse des programmes pour la standardisation 4.3.2

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.


159

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 ) . (…)

Analyse des résultats PLC Checker 4.3.3

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


160

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 :


161

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.


162

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.


163

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.

Structure de fichiers IsaGraf 3.32 4.4.1

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.


164

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é.

Grammaire du fichier source du dictionnaire 4.4.2

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.


165

Grammaire du fichier source d’un sous-programme 4.4.3

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.

Grammaire du fichier source d’un sous-programme Ladder Diagram 4.4.4

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*)


166

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.


167

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).

Figure 69 : Technique basée sur les templates, le méta-modèle du métier et la grammaire de l’Interface de Programmation


168

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é.

Méta-modèle et modèle de PO 4.5.1

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.


169

Partie Opérative

SePO

1 *

ElPO

1 *

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

GT

1

DT Batt. K

1

1

PartieHT

1

Communs

1

1..3 1

11 1 1 1

0..21..4*

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.


170

Modèle d’associations entre PO et PC 4.5.2

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.

Partie Opérative

SePO

1 *

ElPO

1 *

Partie Commande

API

1 *

Base

1

* 1 *

1 1

1 1

1

1..*

11

Module E/S

Carte 16 TSS

Entrée

Carte 4 TCD/TSD

Sortie

1

*

1

16

1

*

1

*

16 8 8

Appareil

1 1..4

Information

1

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.


171

Modèles des SePO 4.5.3

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.

GT

Transfo.

1 *

Dj GT

1

*

1

1

1

SRB

1

*

1 1

1

Sect. HT

1

Sect. Phases

11

1

0..10..3

AAGT

1

1 1

Protection

1

1

1

Information

1

*

1

1

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


172

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.

Choix d’une solution pour la génération de livrables 4.6.1

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.


173

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.


174

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 Solutions

Total des coûts de prestation de développement

d’Odil GREMLINS

Total des coûts de

développement interne

2013 88,5k€ + 4 mois 6 à 8 mois 2014 30,5k€ + 4 mois 133k€ + 1 mois 2015 33k€ + 3 mois

Production 133k€ + 3 mois

2016 90k€ + 4 mois 2017 Production Coûts de Développement Coût de développement des solutions (en euros + heures)

152000€ + 11 mois

356000€ + 16 mois

Coût de développement des solutions (en euros)

284880 539280

Coûts de Maintenance Coût d'exploitation et de maintenance en production (en euros + heures)

33k€ + 2 mois 90k€ + 2 mois

Coût d'exploitation et de maintenance en production (en euros)

57160 114160


175

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.

Odil GREMLINS 4.6.2

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.


176

Figure 75 : Vue de description de la Partie Opérative


177

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


178

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)


179

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.


180

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.


181

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é


182

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)


183

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.

Génération des fichiers d’un projet 4.7.1

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, AcquiTSS.lsf, DefautGT.lsf, DefautES.lsf

AAGT

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).


184

<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.

Template d’un fichier ST 4.7.2

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.


185

#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.


186

Template d’un fichier LD 4.7.3

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.


187

(*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>


188

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.


189


<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.


190

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.


191

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.


192

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


193

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.


194

Tableau 13 : Comparaison des étapes projets actuelles et des étapes projet avec Odil

GREMLINS pour les projets d’électrification de sous-stations

Phases workflow d'un projet actuel

Workflow actuel

Odil GREMLINS

Phases workflow Odil GREMLINS

10h Description Odil GREMLINS

5h Description PO 3h

2h Description PC 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

de paramétrage 50h 8h Relecture du code

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

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.


195

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 d'un projet actuel

Workflow actuel

Odil GREMLINS

Phases workflow Odil GREMLINS

5h Description Odil GREMLINS

3h Description PO 1h

1h Description PC 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

de paramétrage 30h 5h Relecture du code

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 Corrections 10h 5h Corrections

Corrections 10h 5h Corrections

Validations 30h 30h Validations Essais Site 30h 30h Essais Site

Total des heures 190 125 Total des heures


196

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 réalisations actuelles pour les sous-stations (en euros)

70400

Gain des solutions par rapport aux réalisations actuelles pour les postes (en euros)

91200

Gain total des solutions par rapport aux réalisations actuelles (en euros)

161600

Coût annuel d'exploitation et de maintenance en production (en euros)

57160

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é.


197

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.

Quelles attentes de la solution ? 4.10.1

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%.

Utilisation 4.10.2

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


198

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é.

Gains 4.10.3

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


199

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.

Synthèse des résultats 4.10.4

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.


200

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,


201

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


202

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.

203

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.

Chapitre 5 : Application de la commande par contraintes aux EALE

204

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


205

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é.


206

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).


207

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

Principe fonctionnel du RAP actuel 5.2.1

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é.


208

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.


209

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.

Programmes API actuels 5.2.2

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.


210

Programme de Commande de l’IMP 5.2.2.1

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é


211

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.

Programme de la fonction DAP 5.2.2.2

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)

Programme de la fonction RAP 5.2.2.3

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.


212

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.


213

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)


214

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.


215

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.


216

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).


217

Figure 98 : Démarche de définition des contraintes

Définition des observateurs et des contraintes 5.4.1

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.

Description des observateurs 5.4.1.1

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


218

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)


219

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.


220

Figure 101 : GRAFCET de suivi des tensions U1 et U2 pendant le RAP

Contraintes de Sécurité simples 5.4.1.2

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)


221

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)


222

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)

Contraintes de Sécurité combinés 5.4.1.3

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)


223

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)


224

Contraintes Fonctionnelles simples 5.4.2

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.

Prise en considération des CSs et des CFs 5.4.3

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)


225

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.

Prise en considération des CSc 5.4.4

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


226

(

)

(

)

(

)

(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.


227

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).


228

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


229

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.

Présentation d’UPPAAL 5.6.1

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.


230

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.

Modèle de Partie Opérative 5.6.2

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é.


231

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


232

é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


233

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 ».


234

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.


235

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.


236

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).


237

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.


238

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


239

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)

A

B

C

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


240

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.


241

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.


242

243

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.


244

Figure 110 : Méthodologie pour les études d’automatisation et la génération automatique de 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).


245

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


246

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).


247

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.


248

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


249

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.


250

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.

251

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.

Bibliographie

252

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.

Bibliographie

253

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.

Bibliographie

254

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.

Bibliographie

255

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.

Bibliographie

256

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.

Bibliographie

257

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

Bibliographie

258

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.

Bibliographie

259

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.

Bibliographie

260

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.

Bibliographie

261

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.

Bibliographie

262

263

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

Annexes

264

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

Annexes

265

Annexe 2 : Modèles d’une sous-station

Arrivée HT

Dj HT

1 *

Sect. HT

1

*

0..1

1

0..1

1

AACommun

1

1 1

Partie HT

11

0..2

Barre HT

Sect. HT

1 *

1

0..2

1

1

0..1

AACommun

1

1 1

Protection

1

*

1

0..1

Figure 111 : Modèle de la Partie Opérative

GT

Transfo.

1 *

Dj GT

1

*

1

1

1

SRB

1

*

1 1

1

Sect. HT

1

Sect. Phases

11

1

0..10..3

AAGT

1

1 1

Protection

1

1

1

Figure 112 : Modèle du Groupe Traction

Annexes

266

DT

TdC

1 *

Dj DT

1

*

1

1..2

1

Sect. By Pass

1

*

1..2 0..1

1

Sect. MR

1

Protection

11

1

0..11..2

AADT

1

1 1

Figure 113 : Modèle du Départ Traction

Batt. K

K

1 *

DK

1

*

1

1 1

1

SK

1

Protection

1

1

0..11

AACommun

1

1 11

Figure 114 : Modèle de la Batterie de Condensateurs

Annexes

267

Barre 25kV

Sect. Barre

1 *

0..2

1

AACommun

1

1 1

Commun

11

1

Pontage

Sect. P

1 *

1

1

1

1

0..4

AACommun

1

1 1

Sect. SM

1*

1

0..1

Figure 115 : Modèle des sous-ensembles de Partie Opérative Communs

Commun

AnnulPA

1

Interrupteur DU

1

*

1

*

Sect.

1

*

*

1 1

1

1

Figure 116 : Modèle des éléments de Partie Opérative Communs

Annexes

268

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 ++ --

Annexes

269

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

Problème

analyse des besoins Programme livrable

Tests d ’intégration

Tests systèmes

Test de recette (avec client)

Annexes

270

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 logiciel

80k€ 4

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 développement: Visual Studio 2012, MySQL

10k€ 10k€ 10k€ 10k€

Validation des programmes générés

1 mois

Total des coûts de développement

10k€ + 6 à 8 mois

133k€ + 1 mois

133k€ + 4 mois

90k€ + 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

Annexes

271

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.

Annexes

272

Montage financier d’Odil Gremlins

Tableau 19 : Récapitulatif du devis établi par Prosyst

2013 2014 2015… Prestations de développement et d’assistance

83 k€ 25 k€ 5 k€

Formations 3 k€ 3 k€ - Licences annuelles, maintenance et support logiciel

2,5 k€ 2,5 k€ 28 k€

Total des coûts de prestation de Prosyst

88,5k€ 30,5k€ 33k€

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.

Annexes

273

Tableau 21 : Synthèse de coûts de développement et de maintenance des solutions

Synthèse des coûts annuels des Solutions

Total des coûts de prestation de développement

d’Odil Gremlins

Total des coûts de

développement

2013 88,5k€ + 4 mois 6 à 8 mois 2014 30,5k€ + 4 mois 133k€ + 1 mois

2015 33k€ + 3 mois Production 133k€ + 3 mois

2016 90k€ + 4 mois 2017 Production 2018 Coûts de Développement Coût de développement des solutions (en euros + heures)

152000€ + 11 mois

356000€ + 16 mois

Coût de développement des solutions (en euros) 284880 539280

Coûts de Maintenance Coût d'exploitation et de maintenance en production (en euros + heures)

33k€ + 2 mois 90k€ + 2 mois

Coût d'exploitation et de maintenance en production (en euros)

57160 114160

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€.

Annexes

274

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é.

Annexes

275

Tableau 22 : Etude des gains annuels pour les sous-stations

Pour une sous-station typique: (2HT, 2GT, 4DT)

Phases d'un projet

Temps estimé par projet (en

heures) Odil Gremlins Développment

phase 1

DCE 70h 35h 40h cadre réponse (CdCF) liste

matériel 40h 5h 10h

schémas généraux 30h 30h 30h

EXE/VISA 80h 40h 50h validation schémas 30h 30h 30h

Programmes et fichier de paramétrage 50h 10h 20h

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 progiciel 0 10h 20h

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

Annexes

276

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.

Annexes

277

Tableau 23 : Etude des gains annuels pour les postes

Pour un poste typique à IA

Phases d'un projet Temps estimé par projet (en heures) Odil Gremlins Développement

phase 1 DCE 50h 35h 30h cadre réponse (CdCF) liste

matériel 30h 5h 10h

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

du progiciel 0 5h 10h

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

Annexes

278

Calcul des bénéfices 5.8.1

Tableau 24 : Etude des bénéfices réalisables

Synthèse des gains annuels des Solutions

Solution Odil Gremlins

Solution développement

interne Gain des solutions par rapport aux réalisations actuelles pour les sous-stations (en euros)

70400 41600

Gain des solutions par rapport aux réalisations actuelles pour les postes (en euros)

91200 72000

Gain total des solutions par rapport aux réalisations actuelles (en euros)

161600 113600

Coût annuel d'exploitation et de maintenance en production (en euros)

57160 114160

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.

Annexes

279

Calcul du temps de rentabilisation du projet 5.8.2

Tableau 25 : Etude du temps de rentabilisation des solutions

Etude de la rentabilité des solutions

Solution Odil Gremlins

Solution développement

interne

Total des coûts de développement des solutions (euros*)

284880 539280

Bénéfices annuels (en euros) 104440 -560

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

Annexes

280

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 rentabilité des solutions

Total des coûts de prestation de

Prosyst (phase 1)

Total des coûts de développement

(phase 1)

Année de rentabilisation

2017 -

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.

Annexes

281

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

Test réalisé par Usine : Date du test Usine : Site Site

Annexes

282

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

Test réalisé par Usine : Date du test Usine : Site Site

Annexes

283

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_co2IMP= !co2IMP_P && co2IMP; fd_co2IMP= co2IMP_P && !co2IMP; fm_cf1IMP= !cf1IMP_P && cf1IMP; fd_cf1IMP= cf1IMP_P && !cf1IMP; fm_cf2IMP= !cf2IMP_P && cf2IMP; fd_cf2IMP= cf2IMP_P && !cf2IMP; 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; }

Annexes

284

// 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; } if(X22 and not(obs)) { 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; } if(X21 and not(obs)) { 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)

Annexes

285

{ 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))

Annexes

286

{ 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;

Annexes

287

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); CSC2 = S13 and not(S11); CSC3 = S10 and not(S11); CSC4 = S12 and not(S13); CSC5 = not(S10) and S11; CSC6 = not(S12) and S13; 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; S12= not(F02) and F12; 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;

Annexes

288

CCSs8 = not(soIMP) and not(cf1IMP_P) and cf1IMP; CCSC1 = cf1IMP and not(co1IMP); CCSC2 = cf2IMP and not(co2IMP); 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; }

Annexes

289

Annexe 8 : Code de la commande B : Commande actuelle SNCF traduite

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_co2IMP= !co2IMP_P && co2IMP; fd_co2IMP= co2IMP_P && !co2IMP; fm_cf1IMP= !cf1IMP_P && cf1IMP; fd_cf1IMP= cf1IMP_P && !cf1IMP; fm_cf2IMP= !cf2IMP_P && cf2IMP; fd_cf2IMP= cf2IMP_P && !cf2IMP; 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);

Annexes

290

//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;

Annexes

291

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; // Memorisation fin de cycle 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; }

Annexes

292

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; 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_co2IMP= !co2IMP_P && co2IMP; fd_co2IMP= co2IMP_P && !co2IMP; fm_cf1IMP= !cf1IMP_P && cf1IMP; fd_cf1IMP= cf1IMP_P && !cf1IMP; fm_cf2IMP= !cf2IMP_P && cf2IMP; fd_cf2IMP= cf2IMP_P && !cf2IMP; fm_OFRAP= !OFRAP_P && OFRAP; fd_OFRAP= OFRAP_P && !OFRAP; 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));

Annexes

293

//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); fm_OFRAP= !OFRAP_P && OFRAP; fd_OFRAP= OFRAP_P && !OFRAP; // 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; }

Annexes

294

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; } if(X23 and not(obs)) { X23=0;

Annexes

295

X20=1; } if(X22 and not(obs)) { 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; } if(X21 and not(obs)) { 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;

Annexes

296

} //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;

Annexes

297

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; CSC1 = not(S10) and S12; CSC2 = S13 and not(S11); CSC3 = S10 and not(S11); CSC4 = S12 and not(S13); CSC5 = not(S10) and S11; CSC6 = not(S12) and S13; Flag = CSC1 or CSC2 or CSC3 or CSC4 or CSC5 or CSC6 ; Cpt = Cpt+1; Fc01 = CSC5; Fc03 = CSC6;

Annexes

298

Fc10 = CSC1; Fc11 = CSC2 or CSC3; Fc13 = CSC4; } /* STEP 3 */ if (Cpt==Ncsc) { S10= not(F00) and F10; S11= S10; S12= not(F02) and F12; 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; CCSC1 = cf1IMP and not(co1IMP); CCSC2 = cf2IMP and not(co2IMP); 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; U2_P = U2; soIMP_P = soIMP; sfIMP_P = sfIMP; COIMP_P = COIMP;

Annexes

299

CFIMP_P = CFIMP; co1IMP_P = co1IMP; co2IMP_P = co2IMP; cf1IMP_P = cf1IMP; cf2IMP_P = cf2IMP; OFRAP_P = OFRAP; }

Annexes

300

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, pleinement

Oui, éventuellement

Ne sais pas Non, pas vraiment

Non, pas du 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é

Utilisabilité Réduction du nombre d’outils

Réduction des erreurs

Optimisation de la charge mentale

Autre : …

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 Très lisible Lisible Correcte Peu lisible Illisible

c. Cahier de Recette Très lisible Lisible Correcte Peu lisible Illisible

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

Annexes

301

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 (Code inutilisable) (Code robuste, commenté, absence de code mort)

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

D’accord Neutre Pas d’accord Pas du tout 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

Annexes

302

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 ? Tout à fait

d’accord D’accord Neutre Pas d’accord Pas du tout

d’accord

18. Quelles améliorations logicielles aimeriez-vous ? (Question ouverte)

Annexes

303

Réponse n°2


Oui, pleinement



Non, pas du 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 100

(Code inutilisable) (Code robuste, commenté, absence de code mort)

Code robuste mais qui nécessiterait une remise au point 4. Quel a priori aviez-vous à propos de Gremlins ?

Très positif Positif Neutre Négatif Très négatif




Optimisation de la charge mentale ( ???)

Autre : …

Utilisation de Gremlins






Instantanément Après quelques explications Après quelques heures de manipulation

Après quelques jours de manipulation Toujours pas autonome

Annexes

304




Oui Non

c. Programmation

Oui Non




0 60 100 (Code inutilisable) (Code robuste qui nécessite des corrections dans le cas de sous-stations non standardisées)











b. La qualité

Oui Non

c. La sécurité

Oui Non

d. La fiabilité

Annexes

305

Oui Non

e. La maintenance

Oui Non

13. Quel pourcentage du projet a pu être généré par Gremlins ? échelle sur 100% 0 60 100

Gain en production 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





0 100


(Réduction de la charge de travail) Avis personnel

17. Etes-vous prêt à utiliser Gremlins pour vos prochains projets ?




Possibilité de réduire les corrections en cas de structure non standard.

Annexes

306

Réponse n°3


Oui, pleinement



Non, pas du tout

2. Comment estimez-vous votre charge de travail sans la solution Gremlins ? 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

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

0 75 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

Pour le moment




Optimisation de la charge mentale

Autre : …

Y’a jamais d’erreurs, juste du code inutilisé. Utilisation de Gremlins





Mais est-il à jour ?


Instantanément Après quelques explications Après quelques heures de manipulation

Après quelques jours de manipulation Toujours pas autonome

Annexes

307




Oui Non

c. Programmation

Oui Non




0 100 (Code inutilisable) (Code robuste, commenté, absence de code mort)











b. La qualité

Oui Non

c. La sécurité

Oui Non

d. La fiabilité

Annexes

308

Oui Non

e. La maintenance

Oui Non

13. Quel pourcentage du projet a pu être généré par Gremlins ? échelle sur 100% 0 100

Gain en production 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





0 100


Avis personnel

17. Etes-vous prêt à utiliser Gremlins pour vos prochains projets ? Tout à fait

d’accord D’accord Neutre Pas d’accord Pas du tout

d’accord 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=.

Annexes

309

Annexe 11 : Dictionnaire des variables

Tableau 26 : Dictionnaire des variables utilisées dans le chapitre 5

Variable Description CFIMP COIMP

Commande de fermeture par opérateur (modèle aléatoire) Commande d’ouverture par opérateur (modèle aléatoire)

cf1IMP cf2IMP co1IMP co2IMP

Sortie n°1 de commande de fermeture de l’IMP Sortie n°2 de commande de fermeture de l’IMP Sortie n°1 de commande d’ouverture de l’IMP Sortie n°2 de commande d’ouverture de l’IMP

DefIMP OfRAP

Défaut de l’IMP 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 soIMP

Signalisation de la position fermée de l’IMP Signalisation de la position ouverte de l’IMP

tmpCFIMP tmpCOIMP

Temps maximum de fermeture de l’IMP Temps maximum d’ouverture de l’IMP

U1 U2

Présence tension de la voie 1 Présence tension de la voie 2 Absence tension sur la voie 1 ou la voie 2 :

VA9 VA10

(= U1) Présence tension de la voie 1 (= U2) Présence tension de la voie 2

Annexes

310

Annexe 12 : Vérification des propriétés sous UPPAAL

Commande A

Figure 119 : Vérification des propriétés de la commande A

Annexes

311

Commande B

Figure 120 : Vérification des propriétés de la commande B

Annexes

312

Commande C

Figure 121 : Vérification des propriétés de la commande C

Annexes

313

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

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.

raphaël coupat méthodologie pour les études d'automatisation et

Documents