5 Conclusion

I-5 Conclusion

Ce chapitre introductif a permis de pr´esenter diff´erents aspects li´es `a la conception d’un

programme API.

Tout d’abord, la section I-1 a montr´e que la 4

r´evolution industrielle et les pr´eceptes

d´efinissant l’industrie du futur impliquent une ´evolution des techniques de conception

d’un contrˆoleur. Le principe g´en´erique de la conception d’un contrˆoleur a ´egalement ´et´e

introduit dans cette section.

Par la suite, des m´ethodes et outils disponibles dans l’industrie (section I-2) et dans le

monde acad´emique (section I-3) ont ´et´e pr´esent´es. Deux constats peuvent ˆetre soulev´es :

— les m´ethodes de conception du monde industriel permettent difficilement

d’at-teindre les objectifs de l’industrie du futur en terme de flexibilit´e et de fiabilit´e

des programmes API ;

— les m´ethodes formelles acad´emiques de conception ne sont ni connues ni utilis´ees

par l’industrie car trop complexes `a appliquer sur un syst`eme industriel complet.

Enfin, la section I-4 a pr´esent´e des approches acad´emiques alternatives ayant pour objectif

de faciliter l’utilisation pratique d’approches formelles pour la conception d’un programme

API. Dans ce but, diff´erents auteurs ont propos´e des approches `a base d’´equations logiques.

Ce formalisme d’´equations logiques `a base de variables logiques, en comparaison aux

approches `a base de langages formels ou de r´eseaux de Petri, est plus proche des pratiques

des automaticiens. La prise en main et l’utilisation de ces approches par le monde industriel

est donc simplifi´e.

Dans cette th`ese nous avons choisi de contribuer `a une approche `a base d’´equations

lo-giques appel´ee approche par filtre logique. Cette approche a l’avantage de pouvoir ˆetre

utilis´ee de diff´erentes mani`eres en fonction des besoins : commander un syst`eme contrˆol´e

par un API, v´erifier formellement un programme API ou bien mettre en s´ecurit´e un

pro-gramme API d´ej`a existant pr´esentant des erreurs. N´eanmoins, suite aux derniers travaux

sur le filtre logique (Riera et al., 2015), diff´erents verrous et points d’am´eliorations ont

´

Dans le but de proposer une m´ethode formelle, appuy´ee par des outils formels, s’int´egrant

dans les m´ethodologies industrielles, nous proposons de contribuer `a l’approche par filtre

logique `a diff´erents niveaux.

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

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

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

— La propri´et´e de coh´erence d’un filtre logique, introduite dans des travaux pr´ec´edents

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

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

Le chapitre suivant a pour objectif d’illustrer les constats effectu´es au d´ebut de cette

conclusion. Pour ce faire, deux exp´eriences distinctes sont pr´esent´ees et discut´ees. Par la

suite, les contributions m´ethodologiques et th´eoriques sont pr´esent´ees dans le chapitre III.

Puis, le chapitre IV pr´esente les contributions algorithmiques li´ees `a l’impl´ementation du

filtre logique dans un API. Enfin, le chapitre V applique l’approche par filtre logique sur

diff´erentes stations d’une cellule flexible r´eelle.

CHAPITRE II

Du cahier des charges `a l’impl´ementation : exemples

et motivations

II-1 Introduction

Le chapitre pr´ec´edent a pr´esent´e diff´erents points li´es `a la conception d’un programme API.

Il apparait que deux grands principes existent : d’un cˆot´e le monde industriel cherche `a

obtenir une solution rapidement puis `a it´erer sur cette solution afin de l’am´eliorer, de

l’autre cˆot´e le monde acad´emique cherche `a garantir la solution en utilisant des approches

formelles.

Le constat est qu’il existe un ´ecart m´ethodologique important entre ces deux mondes.

En effet, les m´ethodes formelles peuvent ˆetre complexes `a utiliser et peuvent impliquer

un temps de conception plus long par rapport `a une m´ethode de conception cyclique.

N´eanmoins, l’utilisation d’une m´ethode cyclique non-formelle ne permet pas de garantir

`

a 100% que le r´esultat est correct par rapport aux exigences et crit`eres.

L’objectif de ce chapitre est d’illustrer les diff´erents points de ce constat, pour ce faire deux

´

etudes ont ´et´e men´ees. Dans un premier temps, la section II-2 met en ´evidence un manque

de m´ethodologie, que l’on soit ´etudiant ou expert du domaine. Dans un second temps,

la section II-3 permet de montrer au travers d’un exemple simple, que l’utilisation des

m´ethodes formelles«classiques»est tr`es difficilement applicable `a un syst`eme industriel

r´eel.