Contribution à la Commande des Systèmes à Événements Discrets par Filtre Logique

HAL Id: tel-01993790

https://hal.archives-ouvertes.fr/tel-01993790

Submitted on 25 Jan 2019

HAL is a multi-disciplinary open access archive for the deposit and dissemination of sci- entific research documents, whether they are pub- lished or not. The documents may come from teaching and research institutions in France or abroad, or from public or private research centers.

L’archive ouverte pluridisciplinaire HAL, est destinée au dépôt et à la diffusion de documents scientifiques de niveau recherche, publiés ou non, émanant des établissements d’enseignement et de recherche français ou étrangers, des laboratoires publics ou privés.

Événements Discrets par Filtre Logique

Romain Pichard

To cite this version:

Romain Pichard. Contribution à la Commande des Systèmes à Événements Discrets par Filtre

Logique. Informatique [cs]. Université de Reims Champagne-Ardenne, 2018. Français. �tel-01993790�

UNIVERSITÉ DE REIMS CHAMPAGNE-ARDENNE

ÉCOLE DOCTORALE SCIENCES DU NUMÉRIQUE ET DE L’INGÉNIEUR

THÈSE

Pour obtenir le grade de

DOCTEUR DE L’UNIVERSITÉ DE REIMS CHAMPAGNE-ARDENNE Discipline : AUTOMATIQUE, SIGNAL, PRODUCTIQUE, ROBOTIQUE

Spécialité : Automatique et Traitement du Signal Présentée et soutenue publiquement par

Romain PICHARD

Le 30 novembre 2018

Contribution à la Commande des Systèmes à Événements Discrets par Filtre Logique

Thèse dirigée par Bernard RIERA

JURY

M. Jean-Marc ROUSSEL Maître de conférences HDR LURPA – École Normale Supérieure Paris- Saclay

Rapporteur M. Laurent PIÉTRAC Maître de conférences HDR AMPÈRE – Institut National des Sciences

Appliquées de Lyon

Rapporteur Mme Véronique CARRÉ-MÉNÉTRIER Professeur des Universités CReSTIC – Université de Reims Champagne-

Ardenne

Examinatrice M. Jean-François PÉTIN Professeur des Universités CRAN – Université de Lorraine Examinateur M. Serge DEBERNARD Professeur des Universités LAMIH – Université Polytechnique Hauts-de-

France

Examinateur Mme Ramla SADDEM Maître de conférences CReSTIC – Université de Reims Champagne-

Ardenne

Examinatrice Co-encadrante M. Alexandre PHILIPPOT Maître de conférences CReSTIC – Université de Reims Champagne-

Ardenne

Examinateur Co-encadrant Mme Pascale MARANGÉ Maître de conférences CRAN – Université de Lorraine Invitée M. Bernard RIERA Professeur des Universités CReSTIC – Université de Reims Champagne-

Ardenne

Examinateur Directeur de thèse

Les travaux de th` ese pr´ esent´ es dans ce manuscrit ont ´ et´ e r´ ealis´ es dans l’´ equipe Commande et Diagnostic des Syst` emes ` a Ev´ enements Discrets du CReSTIC (Centre de Recherche en STIC) de l’Universit´ e de Reims Champagne-Ardenne.

Je remercie Monsieur le Professeur Bernard RIERA, directeur du CReSTIC, de m’avoir accueilli au sein du laboratoire et d’avoir dirig´ e mes travaux. Etre le « berger d’un trou- peau de chats » n’est pas chose ais´ ee, mais tu as toujours su m’accorder le temps n´ ecessaire pour r´ epondre ` a mes questions. Malgr´ e tout le s´ erieux que tu peux avoir, ton rire est com- municatif et r´ esonnera dans ma tˆ ete aussi longtemps que dans les couloirs du laboratoire.

Je remercie vivement les rapporteurs de ce manuscrit de th` ese, Monsieur Laurent PI´ E- TRAC de l’Institut National des Sciences Appliqu´ ees de Lyon (laboratoire AMP` ERE) et Monsieur Jean-Marc ROUSSEL de l’´ Ecole Normale Sup´ erieure Paris-Saclay (laboratoire LURPA). Je leur suis tr` es reconnaissant pour avoir pris le temps n´ ecessaire ` a l’´ etude de mes travaux. Merci ´ egalement pour vos remarques, aussi pr´ ecises que pertinentes, qui m’ont permis d’am´ eliorer ma pr´ esentation.

Merci ` a Monsieur le Professeur Jean-Fran¸cois P´ ETIN pour avoir accept´ e d’examiner mes travaux deux fois, lors du comit´ e de mi-th` ese puis lors de ma th` ese. Ses avis et conseils m’ont permis de clarifier la route ` a suivre. Merci ´ egalement ` a Monsieur le Professeur Serge DEBERNARD pour m’avoir fait l’honneur d’examiner mes travaux et de pr´ esider ce jury de th` ese. Merci ` a Madame Pascale MARANG´ E pour avoir initi´ e ses travaux il y a quelques ann´ ees, pour ces ´ echanges durant toute la th` ese et pour avoir particip´ e ` a mon jury de th` ese.

Je souhaite ` a pr´ esent remercier mes encadrants, en commen¸cant par Madame Ramla SADDEM qui a accept´ e de suivre mes travaux, mˆ eme lorsque ceux-ci s’´ eloignaient de sa sp´ ecialit´ e. J’enveloppe dans ce paragraphe mes remerciements ` a Monsieur Alexandre PHILIPPOT, ses conseils et son aide m’ont permis d’avancer dans ce cirque parsem´ e de scolopendre qu’est une th` ese. Le travail avec toi est chose ais´ ee de par ta g´ en´ erosit´ e et ton humanit´ e.

Je tiens ` a remercier mes coll` egues d’´ equipe, Monsieur Fran¸cois GELLOT pour sa douce

voix et son aide sur la Cellflex, Monsieur le Professeur Janan ZAYTOON pour ses mots

d’encouragement et ses conseils tout au long de la th` ese et lors du comit´ e de mi-th` ese,

Monsieur Mohamed NIANG pour les bons moments pass´ es ensemble ` a discuter science

et Madame Imane TAHIRI pour son sourire et sa bonne humeur. Je remercie tout par-

ticuli` erement Madame la Professeur V´ eronique CARR´ E-M ´ EN´ ETRIER pour avoir dirig´ e

cette ´ equipe CDSED, sa bienveillance et ses mots d’encouragement quotidiens font d’elle

une vraie m` ere pour cette ´ equipe et ce laboratoire.

Remerciements 3

Merci ` a mes coll` egues, devenus amis, Messieurs Laurent ARCESE et Sinuh´ e MARTINEZ- MARTINEZ pour avoir su m’apporter leurs avis ext´ erieurs durant cette th` ese. Ces liens que nous avons cr´ e´ es entre deux coups de raquette, autour d’un caf´ e ou d’une pizza, ne s’effaceront pas.

Merci ` a Madame Ida LENCLUME pour son aide en administratif, en chocolat et en blague carambar et ` a Madame Sarah FILALI pour son soutien en bonbon et en discussion.

Je remercie chaleureusement ma famille pour son soutien durant ces nombreuses ann´ ees d’´ etudes. Merci ` a vous d’avoir fait le d´ eplacement pour cette importante journ´ ee qu’a

´

et´ e ma soutenance de th` ese. Un merci particulier ` a Elvire et Edith pour m’avoir aid´ e ` a corriger les « quelques » fautes de fran¸cais pr´ esentes initialement dans ce manuscrit.

Pour finir en beaut´ e, je souhaite d´ edier ces travaux ` a la personne qui m’accompagne depuis

tant d’ann´ ees. Tu m’as toujours soutenu et su tirer le meilleur de moi, je ne serai pas ici

sans ton aide, ton avis et ton amour. Notre nouvelle vie ` a trois va bientˆ ot commencer et

je suis combl´ e d’entamer cette aventure avec toi. Merci L´ ea.

Remerciements 2

Table des mati` eres 4

Table des figures 9

Liste des tableaux 11

Introduction g´ en´ erale 13

I Commande des syst` emes automatis´ es : contexte industriel et acad´ e-

mique 17

I-1 La conception de contrˆ oleur dans l’industrie du futur . . . . 17

I-1.1 Les besoins pour les syst` emes automatis´ es de production du futur . 18 I-1.2 Principe de la conception d’un contrˆ oleur . . . . 18

I-2 La conception d’un contrˆ oleur : contexte industriel . . . . 21

I-2.1 Normes pour l’ing´ enierie syst` eme et les API . . . . 21

I-2.2 M´ ethodes de conception . . . . 23

I-2.2.1 M´ ethodes cycliques . . . . 23

I-2.2.2 Approches agiles . . . . 26

I-2.3 Outils d’aide ` a la conception . . . . 28

I-2.3.1 Mise en service virtuelle (virtual commissioning) . . . . . 28

I-2.3.2 Qualim´ etrie de code automate . . . . 29

I-2.3.3 G´ en´ eration automatique de code API . . . . 30

I-2.4 Les m´ ethodes formelles dans le cycle de vie . . . . 31

I-2.4.1 Principe . . . . 31

I-2.4.2 Diff´ erents niveaux d’applications . . . . 32

I-2.4.3 Compromis effort/exhaustivit´ e . . . . 34

I-2.5 Bilan . . . . 35

I-3 Commande des syst` emes ` a ´ ev´ enements discrets . . . . 35

I-3.1 Les syst` emes ` a ´ ev´ enements discrets . . . . 36

I-3.1.1 Notions d’´ ev´ enements et vocabulaire . . . . 36

I-3.1.2 Automates programmables industriels . . . . 37

I-3.1.3 Formalismes et langages de programmation . . . . 38

I-3.2 Th´ eorie de la commande par supervision . . . . 40

TABLE DES MATI` ERES 5

I-3.3 Limitations de la SCT . . . . 42

I-3.3.1 Sp´ ecification : comment cr´ eer les mod` eles . . . . 42

I-3.3.2 Synth` ese : risque d’explosion combinatoire . . . . 43

I-3.3.3 Impl´ ementation : probl` emes li´ es aux API . . . . 44

I-3.3.4 Bilan . . . . 46

I-3.4 Extensions et am´ eliorations de la SCT . . . . 47

I-3.4.1 Aide ` a la sp´ ecification . . . . 47

I-3.4.2 R´ eduction du risque d’explosion combinatoire par l’archi- tecture . . . . 48

I-3.4.3 Modification des algorithmes . . . . 49

I-3.4.4 Prise en compte du fonctionnement de l’API . . . . 50

I-3.4.5 Gestion de l’initialisation par la reconfiguration . . . . 50

I-3.5 Bilan . . . . 51

I-4 Approches de commande des SED par contraintes logiques . . . . 51

I-4.1 Alg` ebre de Boole : d´ efinitions et notations . . . . 52

I-4.2 Synth` ese alg´ ebrique . . . . 53

I-4.3 Filtre logique de commande . . . . 56

I-4.3.1 Principe d’un filtre et utilisations . . . . 56

I-4.3.2 Travaux relatifs au filtre de commande . . . . 57

I-4.3.3 Verrous restants . . . . 61

I-4.4 Liens avec la programmation par contraintes . . . . 62

I-5 Conclusion . . . . 67

II Du cahier des charges ` a l’impl´ ementation : exemples et motivations 69 II-1 Introduction . . . . 69

II-2 Retour d’exp´ erience sur la conception d’un contrˆ oleur . . . . 70

II-2.1 Pr´ esentation du cas d’´ etude . . . . 70

II-2.2 Protocole exp´ erimental . . . . 73

II-2.2.1 Groupe A . . . . 73

II-2.2.2 Groupe B . . . . 74

II-2.3 Synth` eses et analyses des r´ esultats . . . . 74

II-2.3.1 Synth` ese des r´ esultats du groupe A . . . . 74

II-2.3.2 Synth` ese des r´ esultats du groupe B . . . . 78

II-2.4 Analyse des r´ esultats . . . . 80

II-2.5 Application de la SCT ` a l’exemple du portail . . . . 81

II-3 N´ ecessit´ e d’adaptation des approches formelles . . . . 83

II-3.1 Le chat et la souris : r´ esultats classiques . . . . 84

II-3.1.1 Mod´ elisation du syst` eme . . . . 84

II-3.1.2 Mod´ elisation des exigences : sp´ ecification . . . . 85

II-3.1.3 Synth` ese du superviseur . . . . 86

II-3.2 Hypoth` eses classiques et limitations . . . . 87

II-3.3 Hypoth` eses moins restrictives pour l’approche SCT . . . . 89

II-3.3.1 Prise en compte d’un ´ etat initial global . . . . 89

II-3.3.2 Prise en compte de potentiels synchronismes d’´ ev´ enements 91

II-3.3.3 Limitations de l’approche . . . . 92

II-4 Conclusion . . . . 93

III Contribution ` a la commande par filtre logique pour les SED 95 III-1 Introduction . . . . 95

III-2 M´ ethodologie de conception du filtre logique . . . . 96

III-2.1 Principe et d´ efinitions . . . . 96

III-2.2 Obtention d’un filtre logique . . . . 98

III-2.3 Outil logiciel d’aide ` a la conception : SEDMA . . . 100

III-2.4 Utilisations du filtre logique . . . 101

III-2.5 Exemple du portail . . . 102

III-3 Formalisation du filtre logique . . . 103

III-3.1 D´ efinition des contraintes logiques . . . 104

III-3.2 Utilisation des contraintes . . . 106

III-3.3 R´ esolution d’une contrainte . . . 109

III-3.3.1 R´ esolution d’une contrainte simple . . . 109

III-3.3.2 R´ esolution d’une contrainte combin´ ee . . . 111

III-4 V´ erification formelle d’un ensemble de contraintes logiques . . . 118

III-4.1 G´ en´ eralit´ es . . . 118

III-4.2 Cas particulier : coh´ erence d’un ensemble de contraintes simples . . 123

III-4.3 Proposition d’une approche de v´ erification formelle de la coh´ erence 124 III-4.3.1 Existence d’un espace de solutions . . . 125

III-4.3.2 R´ eduction du probl` eme par analyse structurelle . . . 125

III-4.3.3 D´ efinition du graphe d’atteignabilit´ e . . . 127

III-4.3.4 Analyse du graphe d’atteignabilit´ e . . . 128

III-5 Apports mutuels entre SCT et filtre logique : exemple du chat et de la souris130 III-5.1 G´ en´ eration automatique des contraintes logiques . . . 131

III-5.2 Analyse de l’ensemble de contraintes g´ en´ er´ e automatiquement . . . 134

III-5.3 Discussion . . . 137

III-6 Conclusion . . . 138

IV Algorithmes et outils relatifs ` a l’approche par filtre logique 139 IV-1 Introduction . . . 139

IV-2 Algorithme it´ eratif . . . 140

IV-2.1 Principe de filtrage par masques logiques . . . 141

IV-2.2 Cas particulier : algorithme de r´ esolution d’un ensemble de contraintes simples . . . 142

IV-2.3 Cas g´ en´ eral : algorithme de r´ esolution d’un ensemble de contraintes 144 IV-3 Commande par filtre logique ` a base de techniques SAT . . . 147

IV-3.1 Filtre logique par solveur SAT : preuve de concept . . . 148

IV-3.1.1 ´ Ecriture des contraintes logiques en probl` eme SAT-CNF . 148

IV-3.1.2 Utilisation d’un solveur SAT en python pour la commande

par filtre logique . . . 149

IV-3.2 Algorithme de recherche locale bas´ ee sur la distance de Hamming . 152

TABLE DES MATI` ERES 7

IV-3.3 Solveur SAT pour automate programmable industriel . . . 155

IV-4 Synth` ese et comparaison des algorithmes propos´ es . . . 159

IV-5 Conclusion . . . 164

V Application ` a un syst` eme r´ eel : CellFlex 165 V-1 Description du syst` eme . . . 166

V-2 Application ` a trois stations . . . 169

V-2.1 Convoyeur central . . . 169

V-2.1.1 Cahier des charges . . . 171

V-2.1.2 D´ efinition des contraintes de s´ ecurit´ e . . . 171

V-2.1.3 Analyse de la coh´ erence des contraintes de s´ ecurit´ e . . . . 173

V-2.1.4 Impl´ ementation du filtre de s´ ecurit´ e . . . 174

V-2.1.5 D´ efinition du programme fonctionnel . . . 174

V-2.2 Transfert . . . 175

V-2.2.1 Cahier des charges . . . 176

V-2.2.2 D´ efinition des contraintes de s´ ecurit´ e . . . 179

V-2.2.3 Analyse de la coh´ erence des contraintes de s´ ecurit´ e . . . . 182

V-2.2.4 Impl´ ementation du filtre de s´ ecurit´ e . . . 183

V-2.2.5 D´ efinition du programme fonctionnel . . . 183

V-2.3 Import/Export . . . 184

V-2.3.1 Cahier des charges . . . 184

V-2.3.2 D´ efinition des contraintes de s´ ecurit´ e . . . 187

V-2.3.3 Analyse de la coh´ erence des contraintes de s´ ecurit´ e . . . . 191

V-2.3.4 Impl´ ementation du filtre de s´ ecurit´ e . . . 192

V-2.3.5 D´ efinition du programme fonctionnel . . . 192

V-3 Conclusion . . . 195

Conclusion g´ en´ erale 197 Bibliographie 204 A Rappels et d´ efinitions 214 I-1 Les automates ` a ´ etats finis . . . 214

I-2 Notion de Langages . . . 215

B SEDMA - un outil logiciel pour la Mod´ elisation et l’Analyse des SEDs217 II-1 Introduction . . . 217

II-2 L’interface graphique . . . 218

II-3 Pr´ esentation des fonctionnalit´ es principales . . . 220

II-3.1 Automates ` a ´ etats finis . . . 220

II-3.2 R´ eseaux de Petri . . . 224

II-3.3 Filtre logique . . . 227

II-3.4 Diagnostic . . . 229

II-3.5 G´ en´ eration automatique de programme API . . . 230

II-3.6 Algorithme personnalis´ e . . . 230

II-4 Conclusion . . . 231

C Exp´ erimentation Scratch2 et HOME I/O 232 D Filtre logique ` a base de solveur SAT 235 IV-1 Code Python pour la preuve de concept . . . 235

IV-2 Impl´ ementation ST de l’algorithme ` a base de distance de Hamming . . . . 241

IV-3 Impl´ ementation ST d’un solveur SAT . . . 246

IV-3.1 Initialisation du solveur et de la structure de donn´ ee . . . 246

IV-3.2 Ajouts des contraintes ` a la structure de donn´ ee . . . 247

IV-3.3 Fonction principale . . . 250

IV-3.4 Back-tracking . . . 252

R´ esum´ e 255

Table des figures

1 Approche formelle propos´ ee pour la conception d’un filtre logique . . . . . 14

2 Organisation des contributions . . . . 16

3 Cycle g´ en´ erique de validation et v´ erification (Inspir´ e de Foures (2015)) . . 19

4 Principe de l’IS (inspir´ e de l’AFIS) . . . . 22

5 Cycle en V . . . . 24

6 Cycle it´ eratif . . . . 26

7 Projets NASA : corr´ elation effort phases amont / respect du budget . . . . 32

8 Cycle en V formel . . . . 32

9 Compromis effort/fiabilit´ e . . . . 34

10 Syst` eme ` a ´ ev´ enement discret . . . . 37

11 Syst` eme ` a ´ ev´ enement discret sous contrˆ ole . . . . 37

12 Principe de fonctionnement d’un API . . . . 38

13 Principe et positionnement de la SCT . . . . 41

14 Architectures de contrˆ ole . . . . 49

15 M´ ethodologie de la synth` ese alg´ ebrique . . . . 54

16 Principe d’un filtre . . . . 56

17 Principe d’impl´ ementation du filtre bloquant dans un API . . . . 58

18 Approche par model-checking de v´ erification de la suffisance (Marang´ e, 2008) 59 19 Principe d’impl´ ementation du filtre correcteur dans un API . . . . 59

20 Principe de l’algorithme it´ eratif . . . . 60

21 Portail de HOME I/O . . . . 70

22 Interface de Scratch 2 . . . . 72

23 Repr´ esentation de la maison . . . . 84

24 Mod` eles des mouvements . . . . 85

25 Mod` eles des sp´ ecifications . . . . 86

26 Superviseur avec hypoth` eses classiques . . . . 87

27 Superviseurs pour diff´ erents ´ etats initiaux . . . . 88

28 Mod` eles avec ´ etat initial global . . . . 90

29 Superviseur avec ´ etat initial global . . . . 91

30 Mod` ele de la souris avec ´ ev´ enements synchrones et ´ etat initial global . . . 92

31 Etapes du cycle de d´ ´ eveloppement couvertes par le chapitre III . . . . 96

32 Entr´ ees/sorties du filtre logique . . . . 97

33 M´ ethode cyclique formelle de conception d’un filtre logique . . . . 99

34 Filtres en cascade . . . 101

35 Portail automatique . . . 102

36 Principe g´ en´ eral de r´ esolution . . . 120

37 M´ ethode de v´ erification formelle de la coh´ erence . . . 124

38 Graphe structurel pour l’exemple 2 . . . 126

39 Graphe d’atteignabilit´ e pour les priorit´ es fonctionnelles de l’exemple 4 . . . 128

40 Graphe d’atteignabilit´ e pour les priorit´ es fonctionnelles de l’exemple 5 . . . 130

41 Variante m´ ethodologique pour l’obtention du filtre utilisant la SCT . . . . 131

42 Configuration du g´ en´ erateur de gardes . . . 132

43 Etapes du cycle de d´ ´ eveloppement couvertes par le chapitre IV . . . 140

44 Mise ` a jour de l’algorithme it´ eratif . . . 141

45 Cycle API avec filtre logique it´ eratif simple . . . 143

46 Filtre logique it´ eratif complet . . . 145

47 Partie op´ erative simul´ ee contrˆ ol´ ee par un programme Python . . . 150

48 Cycle API avec solveur SAT . . . 157

49 La CellFlex . . . 165

50 Les stations de la CellFlex . . . 167

51 Architecture r´ eseau de la Cellule Flexible . . . 169

52 Description du convoyeur central . . . 170

53 Graphe structurel pour le convoyeur central . . . 173

54 Grafcets du programme fonctionnel pour la zone 1 du convoyeur central . . 175

55 Description de la station de transfert . . . 178

56 IHM de contrˆ ole manuel pour la station de transfert . . . 183

57 Description de la station d’import/export . . . 186

58 Graphe structurel pour l’import/export . . . 191

59 Grafcets du programme fonctionnel pour l’import/export . . . 194

60 Exemple de la souris dans une maison . . . 215

61 Diff´ erentes zones de l’interface graphique. . . 218

62 Repr´ esentation graphique d’un automate de Moore dans SEDMA . . . 222

63 Repr´ esentation graphique d’un r´ eseau de Petri dans SEDMA . . . 224

64 Exemple de fichier d´ ecrivant les contraintes logiques . . . 228

65 Exemple de cr´ eation d’un algorithme personnalis´ e . . . 230

Liste des tableaux

1 Lois de composition interne de l’alg` ebre de Boole . . . . 53

2 Formalisation de phrases en langage naturel (Hietter, 2009) . . . . 54

3 Approche de sp´ ecification utilis´ ee . . . . 75

4 Architectures utilis´ ees . . . . 75

5 Exemple de sc´ enarios de validation . . . . 77

6 R´ esultats synth´ etis´ es du groupe A . . . . 78

7 Approche de sp´ ecification utilis´ ee . . . . 78

8 Architectures utilis´ ees . . . . 79

9 R´ esultats synth´ etis´ es du groupe B . . . . 79

10 R´ esultats quantitatifs de l’approche (Cantarelli et Roussel, 2008) . . . . 82

11 Comparaison quantitative des superviseurs . . . . 92

12 Capteurs et actionneurs . . . 102

13 Contraintes g´ en´ er´ ees automatiquement . . . 134

14 Contraintes g´ en´ er´ ees manuellement . . . 136

15 Analyse des ensembles par solveur SAT . . . 136

16 Comparaison des algorithmes propos´ es . . . 164

17 Mn´ emoniques du convoyeur central . . . 172

18 Mn´ emoniques pour la station de transfert . . . 177

19 Mn´ emoniques pour l’import/export . . . 185

20 R´ ecapitulatif de l’analyse des contraintes de l’import/export . . . 192

21 R´ ecapitulatif . . . 195

Introduction g´ en´ erale

Les travaux de cette th` ese contribuent ` a une m´ ethode formelle de conception d’un pro- gramme de contrˆ ole/commande pour les syst` emes automatis´ es de production (SAP) contrˆ ol´ es par des automates programmables industriels (API). Les syst` emes automati- s´ es de production seront consid´ er´ es comme des syst` emes ` a ´ ev´ enements discrets (SED) (Cassandras et Lafortune, 2009) ayant des entr´ ees et des sorties logiques (Balemi et al., 1993).

Les SAP sont, avec les op´ erateurs humains, les pierres angulaires de l’efficacit´ e d’une ligne de production. Les SAP sont g´ en´ eralement contrˆ ol´ es par des dispositifs ´ electroniques appel´ es automates programmables industriels (API). La performance et la fiabilit´ e des SAP et des API sont encore aujourd’hui des enjeux majeurs en recherche th´ eorique et appliqu´ ee. De plus, l’arriv´ ee de la 4

r´ evolution industrielle et des principes de l’industrie du futur imposent aux syst` emes d’ˆ etre toujours plus flexibles et fiables.

Les approches industrielles de conception des programmes de contrˆ ole/commande des SAP sont tr` es souvent bas´ ees sur la capacit´ e de l’automaticien ` a anticiper et d´ etecter efficacement les erreurs pr´ esentes dans un programme. Ces approches permettent de tendre vers un r´ esultat acceptable apr` es plusieurs allers-retours entre la conception et les tests.

N´ eanmoins, elles ne peuvent garantir ni la validit´ e ni l’optimalit´ e du r´ esultat.

Les approches issues du monde acad´ emique visent au contraire ` a garantir formellement

(i.e. math´ ematiquement) le r´ esultat. Ces approches formelles se basent sur une description

math´ ematique du probl` eme ` a r´ esoudre ainsi que sur des propri´ et´ es, des th´ eor` emes et

des outils permettant la r´ esolution automatique du probl` eme. N´ eanmoins, les approches

actuelles pour la conception formelle d’un programme API ne sont que peu connues et

encore moins utilis´ ees par les automaticiens de l’industrie. Ce fait peut ˆ etre expliqu´ e

par la complexit´ e de ces approches et leur inad´ equation par rapport aux pratiques de l’automaticien.

Pour r´ epondre aux besoins de flexibilit´ e et de fiabilit´ e des SAP du futur, cette th` ese a pour objectif de proposer une m´ ethode et des outils formels, utilisables dans l’industrie par les automaticiens, permettant la conception d’un programme API reposant sur l’utilisation d’un filtre logique de commande.

Contributions de la th` ese

L’approche propos´ ee se base sur la notion de contrainte logique et de filtre logique pour la commande (Riera et al., 2015). L’objectif des travaux est de fournir une m´ ethode et des outils utilisables dans l’industrie permettant, ` a partir du cahier des charges, d’obtenir un programme API g´ en´ er´ e automatiquement et v´ erifi´ e formellement. La m´ ethode de concep- tion propos´ ee dans cette th` ese pour l’obtention d’un filtre logique est pr´ esent´ ee dans la figure 1.

Validation : propriété de suffisance

Spécification manuelle Exigences

Contraintes et priorités

Filtre logique

Intégration

Cohérence ? Ensemble de

contraintes Modèles automates à

états finis

Existence de solutions ? Spécification manuelle

Traduction automatique

Choix d'une solution : priorités

Implémentation automatique

Figure 1 – Approche formelle propos´ ee pour la conception d’un filtre logique Dans le but de supporter la m´ ethode propos´ ee, diff´ erentes contributions th´ eoriques et algorithmiques sont propos´ ees et pr´ esent´ ees succinctement ci-dessous.

— La formalisation des contraintes logiques d´ efinissant le filtre logique est retravaill´ ee

pour am´ eliorer l’expressivit´ e de ces contraintes.

Introduction g´ en´ erale 15

— La notion de priorit´ e entre les variables d’une contrainte, pr´ esent´ ee dans des travaux pr´ ec´ edents (Coupat, 2014), est formalis´ ee (Pichard et al., 2018b).

— La propri´ et´ e de coh´ erence d’un filtre logique, introduite dans des travaux pr´ ec´ edents (Riera et al., 2015), est formalis´ ee. De plus, une solution fournissant une condition n´ ecessaire et suffisante pour la v´ erification formelle de cette propri´ et´ e est propos´ ee (Pichard et al., 2017b).

— Dans la m´ ethodologie de base, la d´ efinition des contraintes logiques est effectu´ ee manuellement ` a partir des exigences textuelles du cahier des charges. Dans cette th` ese, une approche ` a base d’automates ` a ´ etats finis est propos´ ee pour g´ en´ erer automatiquement les contraintes logiques.

— L’algorithme d’impl´ ementation « classique » du filtre logique (Coupat, 2014), est mis ` a jour dans cette th` ese pour prendre en compte le nouveau formalisme.

— Deux algorithmes de recherche locale de solutions sont propos´ ees en se basant sur des techniques de solveur SAT. Ces solutions d’impl´ ementation permettent de simplifier les ´ etapes de conception en amont de l’impl´ ementation (Pichard et al., 2018a).

Enfin, afin de valider l’approche propos´ ee dans cette th` ese et de faciliter son utilisation, diff´ erentes ´ etapes de conception sont int´ egr´ ees dans un environnement logiciel : SEDMA (Pichard et al., 2017a). Ce manuscrit ne d´ etaille pas la conception de ce logiciel. L’annexe B d´ ecrit SEDMA et les fonctionnalit´ es disponibles.

Organisation du m´ emoire de th` ese

Le premier chapitre permet tout d’abord d’introduire la probl´ ematique de conception d’un programme de contrˆ ole/commande pour un automate programmable industriel (API).

Puis, des approches de conception issues du monde industriel et du monde acad´ emique sont discut´ ees. Enfin, l’approche par filtre logique retenue est pr´ esent´ ee, des limitations sont soulev´ ees et des contributions autour de cette approche sont propos´ ees.

Le chapitre II a pour objectif d’illustrer et de motiver plus en d´ etail les propos du chapitre

I. Pour ce faire, deux ´ etudes sont pr´ esent´ ees et discut´ ees. La premi` ere permet de montrer

qu’il existe un manque de m´ ethodologie pratique, lorsque l’objectif est de concevoir un

programme API. La seconde met en ´ evidence que les m´ ethodes formelles, issues du monde acad´ emique, ne permettent pas actuellement une conception efficace de programme API.

Le chapitre III d´ etaille les contributions, m´ ethodologiques et formelles, apport´ ees ` a l’ap- proche par filtre logique. Tout d’abord une m´ ethodologie de conception, bas´ ee sur un cycle de d´ eveloppement en V formel, est propos´ ee. Puis, une formalisation des ´ el´ ements permettant de d´ efinir un filtre logique est pr´ esent´ ee. Ensuite, une approche de v´ erification formelle, n´ ecessaire et suffisante, de la coh´ erence d’un filtre logique est propos´ ee. Enfin, des liens entre la th´ eorie de la commande par supervision (SCT) et l’approche par filtre logique sont discut´ es. Cette association d’approches permet de proposer une solution de g´ en´ eration automatique des contraintes logiques d´ efinissant le filtre logique.

Le chapitre IV d´ etaille les contributions li´ ees ` a l’impl´ ementation du filtre logique dans un API. Dans un premier temps, l’algorithme initial d’impl´ ementation du filtre logique est discut´ e et des am´ eliorations sont propos´ ees. Dans un second temps, deux algorithmes de recherche locale de solutions sont propos´ ees en se basant sur des techniques de solveur SAT.

Chapitre IV

Validation : propriété de suffisance

Spécification manuelle Exigences

Contraintes et priorités

Filtre logique

Intégration

Cohérence ? Ensemble de

contraintes Modèles automates à

états finis

Existence de solutions ? Spécification manuelle

Traduction automatique

Choix d'une solution : priorités

Implémentation automatique

Chapitre III

Figure 2 – Organisation des contributions

Enfin, le chapitre V est consacr´ e ` a une application de l’approche propos´ ee sur un syst` eme

r´ eel. Ce syst` eme comporte plusieurs sous stations command´ ees chacune par un API. Pour

trois de ces sous stations, le cahier des charges, les contraintes logiques d´ efinissant le filtre

logique, l’analyse du filtre logique et l’impl´ ementation de celui-ci sont pr´ esent´ es.

CHAPITRE I

Commande des syst` emes automatis´ es : contexte industriel et acad´ emique

I-1 La conception de contrˆ oleur dans l’industrie du futur

Le concept « Industrie 4.0 » apparaˆıt pour la premi` ere fois lors du salon de la technologie industrielle de Hanovre en 2011. On parle alors de quatri` eme r´ evolution industrielle illus- trant une nouvelle fa¸con d’organiser les moyens de production, et ce grˆ ace ` a l’´ emergence du digital et de la robotisation. Elle fait suite ` a la m´ ecanisation dans l’industrie et l’uti- lisation de la machine ` a vapeur au 18

si` ecle, ` a l’´ electrification et au travail ` a la chaˆıne pour la production de masse (fin 19

, d´ ebut du 20

si` ecle), et ` a l’apparition des premiers syst` emes programm´ es ´ electroniquement dans les ann´ ees 1970.

Pour mener ` a bien cette transformation, diff´ erents enjeux sont identifi´ es : ´ economiques, technologiques, organisationnels, environnementaux, soci´ etaux

. Pour r´ epondre aux en- jeux technologiques, l’industrie du futur s’appuie sur diff´ erents concepts et outils :

— continuit´ e num´ erique (IIoT, BigData, jumeaux num´ eriques, etc.) ;

— cybers´ ecurit´ e (acc` es donn´ ees clients, intrusion dans le syst` eme de production, etc.) ;

— flexibilit´ e (production ` a la demande, moyens de production modulable, etc.) ;

— maintenance 2.0 (standardisation, op´ erateurs augment´ es, etc.) ;

1. http://industriedufutur.fim.net/

— ´ eco-usine (r´ eduction de l’empreinte ´ ecologique, optimisation de l’´ energie, etc.).

Cette th` ese se focalise sur deux des enjeux technologiques li´ es aux syst` emes automatis´ es de production : la flexibilit´ e des contrˆ oleurs et la standardisation des programmes.

I-1.1 Les besoins pour les syst` emes automatis´ es de production du futur

Un syst` eme automatis´ e de production (SAP) a pour but de traiter une mati` ere d’œuvre pour lui apporter une valeur ajout´ ee de fa¸con reproductible et efficace. Il se d´ ecompose en deux parties : la partie op´ erative (PO) dont les actionneurs agissent sur le processus automatis´ e, et la partie commande (PC) qui coordonne les actions de la partie op´ erative.

Aujourd’hui, la majorit´ e des installations s’appuient sur une PO non-modulable contrˆ ol´ ee par un programme de contrˆ ole/commande ajust´ ee ` a celle-ci. De plus, la maintenabilit´ e et la lisibilit´ e des programmes sont rendues difficiles par manque de m´ ethodologie. En effet, les approches de conception de ces programmes s’appuient sur l’expertise m´ etier des automaticiens. Enfin, ce manque de m´ ethodologie restreint la possibilit´ e de garantir le bon fonctionnement des contrˆ oleurs.

Demain, dans le but de r´ epondre aux besoins de flexibilit´ e de l’usine du futur, les parties op´ eratives des SAP devront gagner en modularit´ e et les parties commandes en flexibilit´ e et fiabilit´ e. Les approches actuelles de conception de la PC ne permettant pas d’atteindre efficacement ces objectifs, de nouvelles propositions m´ ethodologiques seront n´ ecessaires.

De plus, afin de garantir la fiabilit´ e et am´ eliorer la maintenabilit´ e des programmes de contrˆ ole/commande, ces approches devront ˆ etre davantage formelles et standardis´ ees.

I-1.2 Principe de la conception d’un contrˆ oleur

Le d´ eveloppement d’un contrˆ oleur, quel que soit le syst` eme ` a piloter, passe par plusieurs grandes ´ etapes : l’analyse, la sp´ ecification, la conception, l’impl´ ementation et l’int´ egration.

Certaines de ces ´ etapes peuvent ˆ etre d´ etaill´ ees en sous-´ etapes permettant une parall´ elisa-

tion et un partage des tˆ aches. Tout au long du cycle de d´ eveloppement sont r´ ealis´ es des

tests, ceux-ci permettent la v´ erification et la validation des ´ etapes et du r´ esultat final.

I-1 La conception de contrˆ oleur dans l’industrie du futur 19

La v´ erification consiste ` a r´ epondre ` a la question « Le contrˆ oleur est-il bien fait ? » alors que la validation r´ epond ` a la question « Le contrˆ oleur fait-il bien son travail ? » (Boehm, 1987). Des d´ efinitions normalis´ ees sont pr´ esent´ ees ci-dessous.

D´ efinition 1. V´ erification (ISO9000, 2015)

Confirmation par des preuves tangibles que les exigences sp´ ecifi´ ees ont ´ et´ e sa- tisfaites

D´ efinition 2. Validation (ISO9000, 2015)

Confirmation par des preuves tangibles que les exigences pr´ evues pour une uti- lisation sp´ ecifique ou une application ont ´ et´ e satisfaites

Ces tests sont r´ ealis´ es tout au long du d´ eveloppement du contrˆ oleur. Ils permettent de s’assurer que l’´ etape en cours est bien r´ ealis´ ee mais ´ egalement de confirmer que le r´ esultat est conforme par rapport aux attentes des ´ etapes pr´ ec´ edentes. Foures (2015) propose une repr´ esentation g´ en´ erique des ´ etapes du cycle de vie pour le d´ eveloppement d’un syst` eme.

Nous proposons une version l´ eg` erement modifi´ ee permettant de mettre en ´ evidence l’´ etape d’impl´ ementation obligatoire lors de la conception d’un contrˆ oleur (Fig. 5).

Conforme ?

Architecture Conforme ?

Spécifications Exigences

Conforme ?

Programme

Analyse Spécification Conception Implémentation

Conforme ?

Le système contrôlé satisfait-il les exigences ?

Système contrôlé Intégration

Bien construit ? Bien construite ?

Bien construits ? VALIDATION

VERIFICATION

Le système contrôlé satisfait-il les besoins ?

Système

Figure 3 – Cycle g´ en´ erique de validation et v´ erification (Inspir´ e de Foures (2015))

Tout d’abord, une analyse du syst` eme doit ˆ etre r´ ealis´ ee. Celle-ci peut ˆ etre s´ epar´ ee en deux

parties : l’analyse fonctionnelle et l’analyse dysfonctionnelle. L’analyse fonctionnelle

permet de savoir ce que le syst` eme peut faire. L’analyse dysfonctionnelle va permettre

de savoir ce que le syst` eme ne doit pas faire. A partir de ces analyses, les besoins

vont pourvoir ˆ etre list´ es, ceux-ci expriment ce que l’on veut faire avec le syst` eme. Ces

analyses et les besoins repr´ esentent un ensemble d’exigences informelles, ces exigences

sont synth´ etis´ ees dans un document : le cahier des charges.

Le contrˆ oleur doit r´ epondre aux besoins tout en respectant les contraintes r´ esultantes de l’analyse dysfonctionnelle. N´ eanmoins les exigences sont informelles et donc peuvent ˆ etre comprises de diff´ erentes mani` eres. Une ´ etape de sp´ ecification des exigences est donc n´ ecessaire, cette ´ etape a pour objectif d’interpr´ eter le cahier des charges, il en r´ esulte un ensemble d’exigences formelles appel´ ees sp´ ecifications. Ces sp´ ecifications, ` a l’oppos´ e du cahier des charges, ne peuvent ˆ etre interpr´ et´ ees que d’une seule mani` ere.

A partir des sp´ ecifications, une conception architecturale est r´ ealis´ ee permettant la mise en relation des fonctions principales du contrˆ oleur. Puis, chaque fonction est d´ etaill´ ee en sous-fonctions afin de faciliter leur conception.

En fonction de l’architecture mat´ erielle li´ ee au syst` eme et des besoins, un langage informa- tique cible est d´ etermin´ e. Chaque fonction peut alors ˆ etre traduite vers ce langage cible, cette phase s’appelle l’impl´ ementation du contrˆ oleur.

Une fois le contrˆ oleur v´ erifi´ e et valid´ e d’un point de vue logiciel, il doit ˆ etre int´ egr´ e dans l’environnement mat´ eriel du syst` eme. Cette ´ etape d’int´ egration consiste ` a relier le contrˆ oleur physique, contenant le programme, au syst` eme ` a contrˆ oler.

Diff´ erentes m´ ethodologies existent permettant l’organisation de ces ´ etapes. Dans le monde industriel, les m´ ethodes utilis´ ees sont encore souvent bas´ ees sur l’exp´ erience et les com- p´ etences techniques des acteurs du d´ eveloppement. Ces m´ ethodes permettent une ´ etape de conception relativement rapide mais demandent plus d’effort au niveau de l’impl´ e- mentation et des tests. Les m´ ethodes formelles, principalement utilis´ ees dans le monde acad´ emique, cherchent ` a d´ ecrire math´ ematiquement le probl` eme ` a r´ esoudre. Ces m´ ethodes permettent une automatisation de certaines des ´ etapes pr´ ec´ edemment d´ ecrites pour une meilleure fiabilit´ e du r´ esultat. N´ eanmoins, les m´ ethodes formelles demandent en g´ en´ e- ral un niveau de connaissance th´ eorique ´ elev´ e et une dur´ ee allong´ ee pendant l’´ etape de conception (Frey et Litz, 2000).

Dans la section suivante, des m´ ethodologies et outils utilis´ es dans l’industrie pour la

conception d’un contrˆ oleur sont pr´ esent´ es.

I-2 La conception d’un contrˆ oleur : contexte industriel 21

I-2 La conception d’un contrˆ oleur : contexte indus- triel

Dans un contexte industriel, les m´ ethodologies principalement utilis´ ees pour le d´ eveloppe- ment d’un contrˆ oleur sont souvent tir´ ees, d’une part de l’ing´ enierie syst` eme et d’autre part des m´ ethodes de gestion de projet logiciel. Ces m´ ethodologies sont orchestr´ ees de diff´ e- rentes mani` eres selon l’organisation des diff´ erentes ´ etapes (analyse, sp´ ecification, concep- tion, impl´ ementation et int´ egration) et des tests. Dans la suite de cette section sont pr´ e- sent´ ees successivement, les principes de l’ing´ enierie syst` eme (section I-2.1), des m´ ethodes cycliques (section I-2.2.1) et des outils d’aide ` a la conception (section I-2.3). Enfin, les apports des m´ ethodes formelles dans les cycles de d´ eveloppement sont pr´ esent´ es (section I-2.4).

I-2.1 Normes pour l’ing´ enierie syst` eme et les API

L’ing´ enierie syst` eme (IS) peut ˆ etre d´ efinie comme « une d´ emarche m´ ethodologique pour maˆıtriser la conception des syst` emes et produits complexes »

. Les r` egles orchestrant cette d´ emarche d’IS sont d´ etaill´ ees dans des normes. Celles-ci sont ensuite r´ ealis´ ees ` a l’aide de m´ ethodes, support´ ees par des outils (Fig. 4). En France, l’Association Fran¸caise d’Ing´ enierie Syst` eme (AFIS) a pour vocation d’encadrer et de promouvoir l’application de l’IS.

La normalisation ou la standardisation est le fait d’´ etablir respectivement des normes et standards techniques. Ce sont des r´ ef´ erentiels communs et document´ es destin´ es ` a har- moniser l’activit´ e d’un secteur. Ceci est r´ ealis´ e par des organismes sp´ ecialis´ es, qui sont le plus souvent des organismes nationaux (AFNOR

, ANSI

), ou internationaux (ISO

, IEC

).

Les principales normes de l’IS, d’apr` es l’AFIS

sont pr´ esent´ ees ci-apr` es.

2. http://www.afis.fr/nm-is/default.aspx 3. https://www.afnor.org/

4. https://www.ansi.org/

5. https://www.iso.org/fr/home.html 6. http://www.iec.ch/

7. http://www.afis.fr/nm-is/Pages/Normes%20IS/Normes%20d%e2%80%99Ing%c3%a9nierie%

S'appuient sur Processus

S'appuient sur Méthodes

Outils

Activités à réaliser Résultats attendus

Avec des techniques de réalisation des activités

Pour améliorer

l'éfficacité dans la mise en oeuvre des méthodes Quoi, à quoi ?

Comment ?

Avec quoi ?

Figure 4 – Principe de l’IS (inspir´ e de l’AFIS)

— IEEE 1220 : Cette norme se focalise sur la conception du syst` eme (de l’analyse des exigences jusqu’` a la d´ efinition physique du syst` eme).

— EIA 632 : Cette norme ´ etend les principes de l’IEEE 1220 en int´ egrant le transfert du syst` eme r´ ealis´ e vers son utilisateur final.

— ISO 15288 : Cette derni` ere int` egre l’ensemble du cycle de vie d’un syst` eme (pro- duit), de sa conception ` a son retrait. Celle-ci apparait, aujourd’hui, comme la r´ e- f´ erence.

Le contrˆ ole/commande d’un syst` eme est une sous-partie du processus global de l’IS, cer- taines normes sp´ ecifiques existent alors en fonction des domaines d’applications. En ce qui concerne les Automates Programmables Industriels (API), servant ` a contrˆ oler les syst` emes automatis´ es de production, la principale norme est l’IEC61131 (2018). Celle-ci d´ efinit les diff´ erents aspects li´ es ` a un API : exigences mat´ erielles, langages de programmation, com- munications... Le principe de fonctionnement et les langages de programmation propres aux API seront pr´ esent´ es plus loin dans ce chapitre (section I-3.1.2).

Bien que ces normes encadrent l’utilisation, par exemple en limitant les langages de pro- grammation (IEC61131-3, 2013), elles n’imposent pas la fa¸con de les utiliser. Concr` ete- ment, deux constructeurs d’API diff´ erents, peuvent utiliser des structures de donn´ ees et des fichiers de sauvegarde de natures diff´ erentes pour un mˆ eme langage de programma- tion. De mˆ eme, deux d´ eveloppeurs de programmes peuvent r´ ealiser une mˆ eme fonction de diff´ erentes mani` eres.

Dans le but de faciliter l’interop´ erabilit´ e, la flexibilit´ e, la maintenance ou bien encore la

20Syst%c3%a8me.aspx

I-2 La conception d’un contrˆ oleur : contexte industriel 23

mise ` a jour d’un syst` eme, il est possible d’´ etablir des standards afin d’uniformiser l’utilisa- tion de ces normes. Un standard est un ensemble de recommandations ou de pr´ ef´ erences, en g´ en´ eral propos´ e par un groupe d’utilisateurs sp´ ecialis´ es du domaine.

En ce qui concerne la programmation des API, un standard de r´ ef´ erence est PLCopen

. Celui-ci se base principalement sur la norme IEC61131-3 (2013) d´ ecrivant les langages de programmation pour les API. PLCopen propose diff´ erentes r` egles de conception et syn- taxiques, d´ ecrivant des « bonnes pratiques » ` a suivre pour la conception d’un programme API. Le respect de ces r` egles permet de limiter le risque d’erreurs dans un programme, ainsi que de simplifier la lisibilit´ e et la maintenabilit´ e d’un programme.

I-2.2 M´ ethodes de conception

En fonction de l’organisation des ´ etapes de d´ eveloppement et des tests, diff´ erentes m´ e- thodes ont ´ et´ e propos´ ees. Cette section pr´ esente deux cat´ egories de m´ ethode : les m´ ethodes cycliques et les approches agiles.

I-2.2.1 M´ ethodes cycliques

Les m´ ethodes cycliques sont les plus connues pour la gestion de projet et la conception de syst` eme. Elles diff` erent principalement en fonction de leur structuration et de leur sou- plesse (vs. rigidit´ e). La structuration correspond ` a l’organisation hi´ erarchique des ´ etapes de d´ eveloppement et de la place des tests dans cette organisation. La souplesse est li´ ee ` a la possibilit´ e de r´ eagir efficacement ` a la d´ etection d’une erreur, ou bien de la modification des exigences du client.

Historiquement, le cycle en cascade a ´ et´ e propos´ e pour la gestion de projet dans le domaine du bˆ atiment (Royce, 1987). Ce cycle en cascade est bas´ e sur deux principes :

— une phase est d´ ebut´ ee uniquement si la pr´ ec´ edente est achev´ ee ;

— la modification d’une phase a un fort impact sur les phases suivantes.

Cette m´ ethodologie est tr` es lin´ eaire, donc simple ` a comprendre et ` a mettre en place. De plus, elle permet en th´ eorie, une estimation pr´ ecise de la date de fin de projet. N´ eanmoins,

8. http://www.plcopen.org/index.html

elle comporte de nombreux inconv´ enients comme en particulier la tr` es faible tol´ erance aux erreurs. En effet, les anomalies sont d´ etect´ ees tardivement et impliquent obligatoirement un retour ` a une phase pr´ ec´ edente voire, au d´ ebut du cycle. L’exemple du bˆ atiment est

´

edifiant : une erreur d´ etect´ ee sur les fondations apr` es la construction du toit implique en g´ en´ eral la reprise compl` ete du projet.

Afin de r´ esoudre le probl` eme de rigidit´ e du cycle en cascade, le mod` ele en V

a ´ et´ e propos´ e (Fig. 5). Avec ce mod` ele, chaque phase descendante est mise en relation avec les tests, ceci permet de d´ etecter plus rapidement les erreurs et de les corriger avant de passer aux phases suivantes.

Analyse des besoins

Spécification

Conception

Tests de validation Intégration et maintenance

Implémentation

Tests d'intégration et unitaires

Figure 5 – Cycle en V

D’un point de vue th´ eorique, cette organisation permet de tendre vers un produit enti` ere- ment conforme aux attentes du client. N´ eanmoins, dans un souci de gain de temps et donc de r´ eduction des coˆ uts de d´ eveloppement, certaines phases sont r´ eduites voire supprim´ ees.

La phase de sp´ ecification est souvent la premi` ere ` a ˆ etre mise de cˆ ot´ e. Comme dit pr´ ec´ e- demment, cette phase a pour but de formaliser les exigences et envies du client afin d’ob- tenir des sp´ ecifications, n´ eanmoins elle demande beaucoup de temps (aller/retour entre le client et l’´ equipe de sp´ ecification) ainsi qu’une maˆıtrise des outils formels permettant la repr´ esentation de tous types d’exigences.

Les attendus des tests sont normalement d´ efinis pendant les phases descendantes, cela permet d’oublier le minimum d’´ el´ ements car les tests ` a effectuer sont r´ edig´ es en mˆ eme temps que la conception de la fonction. Il s’av` ere que d’un point de vue pratique cela

9. http://www.geek-directeur-technique.com/2009/02/04/le-cycle-en-v

I-2 La conception d’un contrˆ oleur : contexte industriel 25

rallonge encore la phase de conception. Dans le but de r´ eduire ce temps de conception (descente du cycle), les tests ne sont g´ en´ eralement r´ edig´ es et effectu´ es qu’apr` es l’´ etape d’impl´ ementation.

Dans la pratique, la suppression de l’´ etape de sp´ ecification permet d’aboutir plus rapide- ment ` a un r´ esultat (apr` es l’´ etape d’impl´ ementation). N´ eanmoins cela reporte les probl` emes

`

a d’autres niveaux. En effet, le manque de formalisation doit se retrouver compens´ e par la capacit´ e des chefs de projets ` a anticiper les probl` emes et ` a bien comprendre les attentes des clients. De plus, le fait de ne pas avoir de tests organis´ es et hi´ erarchis´ es impose aux

´

equipes de d´ eveloppement d’ˆ etre tr` es rigoureuses et performantes. Dans le cas contraire, le temps gagn´ e dans la phase de conception risque d’ˆ etre perdu ` a cause des nombreuses it´ erations de tests/codages.

Bien que le cycle en V permette de mieux r´ eagir aux erreurs que le cycle en cascade, celui-ci ne permet pas d’int´ egrer efficacement le client dans les ´ etapes de conception. Par cons´ equent, un changement des exigences par le client risque d’allonger fortement le temps global du projet. Pour r´ epondre ` a ce probl` eme le cycle en spirale a ´ et´ e propos´ e (Boehm, 1988).

Le cycle en spirale reprend les phases du cycle en V, mais pr´ evoit l’impl´ ementation de ver- sions successives, ce qui permet de mettre l’accent sur la gestion des risques, la premi` ere phase de chaque it´ eration ´ etant d´ edi´ ee ` a ce poste. Le cycle en spirale pr´ evoit la livrai- son de prototypes (versions interm´ ediaires) pouvant s’agir de programmes partiellement fonctionnels : ` a chaque fonction principale peut correspondre un prototype.

Ce cycle apporte une grande flexibilit´ e. En effet, si chaque prototype apporte des fonction- nalit´ es ind´ ependantes, il est possible de changer l’ordre de d´ eveloppement des versions. De plus, le risque final est r´ eduit de par la pr´ esence accrue du client pendant le processus. En effet, le client peut tester chaque prototype et ainsi n’a pas besoin d’attendre la version finale pour faire remonter un probl` eme.

N´ eanmoins chaque cycle comporte de nombreuses phases et peut ˆ etre compliqu´ e ` a organi- ser. En r´ eduisant le nombre de phases d’un cycle, il est possible de d´ efinir le cycle it´ eratif (Fig. 6).

Tout commence par l’expression des besoins : le client explique ce qu’il veut, tout en

Expression des

besoins Spécification

Développement

Déploiement Validation

Evaluation

Figure 6 – Cycle it´ eratif

sachant que ces besoins peuvent ˆ etre modifi´ es par la suite du processus. Ensuite, le pro- cessus it´ eratif en lui-mˆ eme commence avec la r´ edaction des sp´ ecifications qui est suivie par le d´ eveloppement (impl´ ementation), puis la validation (tests) et enfin une ´ evaluation du travail qui servira d’information de d´ epart pour le cycle suivant (difficult´ es rencontr´ ees, fonctionnalit´ es abandonn´ ees, ...). Le d´ eploiement est r´ ealis´ e ` a l’issue de la validation : les livrables (il peut s’agir d’une version, ou d’une documentation) qui ont ´ et´ e valid´ es sont d´ eploy´ es, c’est-` a-dire mis ` a disposition.

Le cycle it´ eratif est le plus souple de tous ceux pr´ esent´ es jusqu’ici. Chaque it´ eration permet de s’adapter ` a ce qui a ´ et´ e appris dans les it´ erations pr´ ec´ edentes et le projet fini peut varier du besoin qui a ´ et´ e exprim´ e ` a l’origine. Comme dans le cycle en spirale, la mise

`

a disposition de livrables ` a chaque cycle permet un apprentissage de l’utilisateur final en douceur.

Bas´ e sur le mˆ eme besoin d’association du client dans le cycle de d´ eveloppement du sys- t` eme, les approches agiles ont ´ et´ e propos´ ees. La section suivante pr´ esente les principes fondamentaux de ces approches agiles et quelques m´ ethodes les mettant en œuvres.

I-2.2.2 Approches agiles

Les approches agiles

sont bas´ ees sur des valeurs et des principes, permettant de renfor- cer au maximum les liens entre clients et d´ eveloppeurs. Une description g´ en´ erale de ces approches a ´ et´ e rendue publique en 2001 (http://agilemanifesto.org/). Les valeurs fondamentales d’une approche agile sont les suivantes :

— les individus et leurs interactions plus que les processus et les outils ;

10. https://www.agiliste.fr/introduction-methodes-agiles/

I-2 La conception d’un contrˆ oleur : contexte industriel 27

— des logiciels op´ erationnels plus qu’une documentation exhaustive ;

— la collaboration avec les clients plus que la n´ egociation contractuelle ;

— l’adaptation au changement plus que le suivi d’un plan.

En plus de ces valeurs, 12 principes g´ en´ eraux sont ´ enonc´ es :

— satisfaire le client en priorit´ e ;

— accueillir favorablement les demandes de changement ;

— livrer le plus souvent possible des versions op´ erationnelles de l’application ;

— assurer une coop´ eration permanente entre le client et l’´ equipe projet ;

— construire des projets autour d’individus motiv´ es ;

— privil´ egier la conversation en face ` a face ;

— mesurer l’avancement du projet en termes de fonctionnalit´ es de l’application ;

— faire avancer le projet ` a un rythme soutenable et constant ;

— porter une attention continue ` a l’excellence technique et ` a la conception ;

— faire simple ;

— responsabiliser les ´ equipes ;

— ajuster ` a intervalles r´ eguliers son comportement et ses processus pour ˆ etre plus efficace.

Bas´ ees sur ces valeurs et principes, diff´ erentes m´ ethodes agiles ont ´ et´ e propos´ ees : Scrum (Schwaber, 2004), eXtreme Programming (XP) (Beck et Gamma, 2000), Adaptive Soft- ware Development (ASD) (Highsmith, 2013)... Diff´ erentes m´ ethodes existent car il n’y a jamais une seule fa¸con d’interpr´ eter des principes et de mettre en place des valeurs.

Scrum et XP sont les plus connues, et peuvent ˆ etre utilis´ ees ensemble car elles sont com- pl´ ementaires

(Schwaber et Mar, 2002). En effet, Scrum se positionne au niveau de la gestion et de l’organisation de projet l` a o` u XP se positionne au niveau des activit´ es de d´ eveloppement.

Pour r´ esumer ces m´ ethodes, Scrum adresse la probl´ ematique du processus de production du logiciel, l’organisation et la dynamique du projet. Le d´ eveloppement incr´ emental, n´ ean- moins, suppose des pratiques d’ing´ enierie logicielle rigoureuses et efficaces, que Scrum ne couvre pas.

11. https://blog.xebia.fr/2008/01/10/scrum-ou-xp-scrum-et-xp/

XP quand ` a elle, se focalise sur le d´ eveloppement. Dans XP, le test automatis´ e n’est pas seulement vu comme une bonne pratique du d´ eveloppement agile : il en est l’´ epine dorsale.

Cette m´ ethode a donn´ e naissance au principe du TDD (Test Driven Development) : le d´ eveloppeur ´ ecrit en premier lieu un test automatis´ e de la fonctionnalit´ e qu’il souhaite impl´ ementer, d´ eveloppe ensuite juste assez de code pour satisfaire le test, et finalement remanie le code pour am´ eliorer le design et supprimer la duplication.

Afin d’aider le concepteur de programme, diff´ erents outils int` egrent les normes, standards et m´ ethodes pr´ esent´ es pr´ ec´ edemment. La section suivante pr´ esente quelques outils li´ es ` a la conception d’un programme API.

I-2.3 Outils d’aide ` a la conception

Cette section pr´ esente trois concepts permettant d’aider l’automaticien ` a concevoir un programme API. Pour chacun de ces concepts, quelques outils les int´ egrant sont propos´ es.

I-2.3.1 Mise en service virtuelle (virtual commissioning)

Quelles que soient les m´ ethodes utilis´ ees, des tests sur le syst` eme sont n´ ecessaires. D’un point de vue gestion de projet, l’avancement du d´ eveloppement du programme API peut donc ˆ etre ralenti voire arrˆ et´ e si le syst` eme r´ eel n’est pas encore construit ou disponible pour des tests. Afin de palier ` a ce probl` eme, et dans le but de gagner du temps, il est possible d’utiliser des outils et techniques de virtual commissioning (mise en service virtuelle).

Le principe du virtual commissioning est d’utiliser un simulateur du syst` eme physique, et de lui associer le programme API r´ eel. Dans ces conditions, l’API r´ eel peut ˆ etre test´ e et valid´ e sans avoir besoin du syst` eme r´ eel. Cette technique pr´ esente plusieurs avantages :

— gain de temps : possibilit´ e d’acc´ el´ erer le temps dans la simulation, les tests sont effectu´ es avant/pendant la construction du syst` eme r´ eel ;

— gain d’exhaustivit´ e : il est possible d’automatiser tout ou partie des tests ;

— diminution des risques lors des tests : il est possible de tester des situations dan- gereuses, qu’il ne serait pas possible de tester sur le syst` eme r´ eel.

La principale difficult´ e d’utilisation d’une telle technique est la mod´ elisation du syst` eme

I-2 La conception d’un contrˆ oleur : contexte industriel 29

r´ eel (Lee et Park, 2014), celle-ci peut prendre du temps afin d’ˆ etre compl` ete. N´ ean- moins, les fabricants de machines utilisent de plus en plus des mod´ elisations 3D, et multi- physiques, pour la conception de leurs machines (Catia, SolidWorks, MapleSoft...). Les logiciels permettant d’effectuer du virtual commissioning (DELMIA, SIMAC, NX/MCD), proposent en g´ en´ eral l’import automatique de ces mod` eles de conception 3D. Cela dimi- nue donc fortement le temps de mod´ elisation, n´ ecessaire au virtual commissioning. Enfin, de plus en plus de fournisseurs proposent les mod` eles 3D de leurs ´ el´ ements de parties op´ eratives (par exemple FESTO).

Pour le moment, ces outils sont principalement utilis´ es pour les syst` emes « critiques », par exemple dans le ferroviaire (Niang et al., 2017; Coupat et al., 2018). N´ eanmoins, dans le contexte de l’industrie du futur o` u les syst` emes et les programmes doivent ˆ etre toujours plus robustes et flexibles, cette approche, ` a travers le concept de « jumeau num´ erique », apparaˆıt comme ´ etant de plus en plus n´ ecessaire (Pellicciari et al., 2009).

I-2.3.2 Qualim´ etrie de code automate

Dans l’industrie du futur, la continuit´ e num´ erique est un ´ el´ ement tr` es important. Pour un programme API, cette continuit´ e num´ erique n´ ecessite avant tout un programme compr´ e- hensible et lisible. Dans le but de faciliter la lisibilit´ e, et donc la maintenabilit´ e, d’un pro- gramme API, il est n´ ecessaire de suivre diff´ erentes r` egles de programmation et d’´ ecriture.

Ces r` egles peuvent concerner, la syntaxe pure (commentaires, nommages des variables...), l’architecture (d´ ecoupage du programme en POU (Program Organization Unit) et en sous-fonctions, langages utilis´ es...), ou bien encore la complexit´ e. Ces r` egles peuvent ˆ etre nombreuses et difficiles ` a ´ evaluer (pour la complexit´ e par exemple).

Le standard PLCopen, pr´ esent´ e pr´ ec´ edemment (section I-2.1), recense de nombreuses r` egles de ce genre. Bas´ e sur ce standard, le logiciel PLC checker

permet d’automati- ser la v´ erification de ces r` egles pour un programme API. L’outil prend en entr´ ee, une archive compl` ete du programme API, et fournit en sortie, une liste d’avertissements et d’erreurs (en fonction de la criticit´ e des r` egles) permettant au concepteur d’am´ eliorer son programme. Il est ´ egalement possible de cr´ eer ses propres r` egles, permettant d’ajuster la

12. http://www.itris-automation.fr/plc-checker/

v´ erification aux exigences de l’utilisateur final.

I-2.3.3 G´ en´ eration automatique de code API

Dans le but de simplifier l’application des r` egles d’´ ecriture li´ ees aux normes et standards, mais ´ egalement de r´ eduire le risque d’erreurs li´ ees ` a l’´ etape d’impl´ ementation, il existe des solutions permettant la g´ en´ eration de tout ou partie du programme API et des do- cumentations associ´ ees. Diff´ erentes techniques de g´ en´ eration automatique de codes et de documentations existent (Coupat, 2014) et diff´ erents outils logiciels permettent leur ap- plication (Bajovs et al., 2013).

La solution Odil de la soci´ et´ e Prosyst

est un exemple de logiciel pour la g´ en´ eration automatique de codes et de documentations. Les industriels sont de plus en plus attir´ es par ce type de solution : PSA, Michelin, Bombardier, Schneider Electric, SNCF...

La soci´ et´ e Iris Automation

propose une autre solution pour l’aide ` a la normalisation des programmes API : PLC Converter. Cette solution permet la conversion automatique d’un programme API provenant d’un environnement automate vers un autre environnement automate. La gestion des versions et des ´ equivalences de syntaxes entre les diff´ erentes marques d’automates est effectu´ ee automatiquement. Cette soci´ et´ e propose ´ egalement la solution PLC DocGen pour la g´ en´ eration automatique des documentations.

La normalisation des fonctionnements, la standardisation des pratiques, et la simplification des tests ` a l’aide d’outils, sont des points cruciaux pour la v´ erification et la validation d’un programme API. N´ eanmoins, les tests ne sont jamais exhaustifs, les standards sont bas´ es sur des r` egles informelles, et les normes encadrent l’utilisation mais ne garantissent pas les fonctionnements. Dans le but de pouvoir garantir ` a 100% le bon fonctionnement d’un programme API, des m´ ethodes formelles doivent ˆ etre utilis´ ees durant la conception et les tests. La section suivante (section I-2.4), pr´ esente le principe des approches formelles et leurs utilisations dans la conception d’un programme API.

13. http://www.prosyst.fr/index.html

14. http://www.itris-automation.fr/

I-2 La conception d’un contrˆ oleur : contexte industriel 31

I-2.4 Les m´ ethodes formelles dans le cycle de vie

Les m´ ethodes de conception pr´ esent´ ees dans la section I-2.2, sont toutes bas´ ees sur un principe de v´ erification et de validation d’un programme d´ evelopp´ e « ` a la main » par raffi- nements successifs. Le poids de la r´ eussite d’un projet de conception de contrˆ oleur repose donc en grande partie sur l’ing´ enieur en automatisme : interpr´ etation des sp´ ecifications in- formelles et codage du contrˆ oleur. La conception du contrˆ oleur est en g´ en´ eral assist´ ee par des outils standardis´ es de programmation. N´ eanmoins, les exigences informelles doivent ˆ

etre traduites manuellement et intuitivement dans le programme de commande ´ etant donn´ e que l’´ etape de sp´ ecification n’est pas effectu´ ee par souci de temps et d’expertise.

Ces approches entraˆınent la plupart du temps des coˆ uts de d´ eveloppement suppl´ emen- taires dus aux erreurs d’interpr´ etations des sp´ ecifications informelles (Johnson, 2007).

Afin de r´ eduire au maximum le risque d’erreurs lors de la conception d’un contrˆ oleur, il est n´ ecessaire d’utiliser des m´ ethodes et outils formels permettant de garantir le bon fonctionnement d’un programme API.

I-2.4.1 Principe

Une m´ ethode peut ˆ etre qualifi´ ee de formelle lorsque, d’une part la notation est formelle, c’est-` a-dire d´ efinie math´ ematiquement et donc sans ambigu¨ıt´e. D’autre part les tests doivent ˆ etre formels, c’est-` a-dire que le traitement des mod` eles exprim´ es dans la nota- tion formelle est automatis´ e.

Lors d’un d´ eveloppement classique (comme pr´ esent´ e pr´ ec´ edemment), les erreurs sont en

g´ en´ eral d´ etect´ ees tardivement. Utiliser une approche formelle va permettre de d´ etecter des

ambigu¨ıt´es et des erreurs au plus tˆ ot lors des diff´ erentes phases. Les phases amont sont

par cons´ equent plus coˆ uteuses, mais cela permet un d´ eveloppement global plus efficace. La

figure 7 ´ etudie la corr´ elation entre l’effort allou´ e aux phases amonts et le respect du budget

global du projet (Bowen et Hinchey, 2005). Chaque point correspond ` a un projet termin´ e

de la NASA, cette ´ etude permet de mettre en ´ evidence que plus les phases d’analyse et

de formalisation sont importantes, plus le budget est respect´ e.

Figure 7 – Projets NASA : corr´ elation effort phases amont / respect du budget I-2.4.2 Diff´ erents niveaux d’applications

En fonction des domaines et des besoins, les m´ ethodes formelles peuvent ˆ etre appliqu´ ees

`

a diff´ erents niveaux lors du cycle de d´ eveloppement. Cette section pr´ esente la version formelle du cycle en V (Fig. 8).

Validation Exigences

Conception

Code

Tests d'intégration

Implémentation automatique Spécification

Vérification exhaustive et automatique

Figure 8 – Cycle en V formel

Sp´ ecification La sp´ ecification est une ´ etape tr` es importante et difficile quelles que

soient les m´ ethodes formelles utilis´ ees (Pi´ etrac, 2018). Celle-ci doit d´ eboucher sur une

repr´ esentation math´ ematique de l’ensemble des exigences informelles. C’est une ´ etape

g´ en´ eralement effectu´ ee manuellement, elle demande un niveau d’expertise ´ elev´ e et des

comp´ etences th´ eoriques fortes afin d’ˆ etre capable de transformer correctement n’importe

quelle exigence informelle en sp´ ecification formelle.