Dans une toute autre direction, nous avons ´egalement propos´e dans nos tous premiers travaux de recherche [203, 204]
* , bien ant´erieurement au d´eveloppement d’InCELL, une
contribution sur la combinaison entre recherche locale et propagation de contraintes. Cette combinaison suivait une autre voie que la voie CBLS, en consid´erant des mod`eles de programmation par contraintes classiques, non limit´es `a des mod`eles exprim´es comme des DAGs d’invariants. L’id´ee de base ´etait d’arriver `a b´en´eficier `a la fois de la libert´e dans le parcours de l’espace de recherche offerte par la recherche locale et de l’efficacit´e de la propagation de contraintes. Un exemple d’algorithme de la litt´erature qui r´ealisait cela ´
etait l’algorithme DR (Decision Repair [122]), qui g´en´eralise des algorithmes classiques tels que CBJ (Conflict-based BackJumping [225]) et DBT (Dynamic BackTracking [94]).
4.4. RECHERCHE LOCALE AVEC PROPAGATION DE CONTRAINTES 55
Le fonctionnement de ces algorithmes est illustr´e `a la figure 4.5. Ces algorithmes instan-cient progressivement les variables du probl`eme afin de trouver une instanciation solution, et ils utilisent de la propagation de contraintes pour ´elaguer l’espace de recherche apr`es chaque instanciation de variable. Mais alors qu’en cas de conflit une recherche arborescente classique repose sur du backtrack dit chronologique (remise en cause de la derni`ere instan-ciation de variable dans l’arbre de recherche), ces algorithmes exploitent une explication de l’incoh´erence courante pour d´eterminer sur quelles instanciations de variables revenir. L’algorithme DBT revient syst´ematiquement sur l’instanciation de la derni`ere variable impliqu´ee dans l’explication de l’incoh´erence courante, l’algorithme CBJ revient sur cette mˆeme instanciation mais en d´efaisant ´egalement les instanciations faites entre temps, et l’algorithme DR revient sur n’importe quelle variable impliqu´ee dans l’explication d’in-coh´erence courante. Ainsi, les variables ne sont pas forc´ement d´esinstanci´ees dans l’ordre de leur instanciation, ce qui implique par ailleurs de mettre en œuvre des techniques pour d´efaire intelligemment le travail fait par la propagation de contraintes. Au final, l’algo-rithme DR effectue une recherche locale dans l’espace des instanciations partielles guid´ee par les explications d’incoh´erence.
Chronological Dynamic
backtracking Decisionrepair
backtracking Conflict directedbackjumping variables variables Assigned Unassigned Dead end variable Conflicting variables
Figure 4.5 : Sch´emas d’instanciations et de d´esinstanciations de variables pour plusieurs algorithmes de recherche sur des instanciations partielles
Notre apport principal `a l’algorithme DR a concern´e l’´etude d’heuristiques efficaces pour d´eterminer quelle variable d´esinstancier en cas de conflit. Dans [203, 204], nous avons * notamment ´etudi´e trois heuristiques de d´esinstanciation :
• d´esintanciation al´eatoire, afin de diversifier la recherche ;
• d´einstanciation de la variable qui efface le plus de valeurs dans les domaines des autres variables, afin de r´eviser d’abord les instanciations les plus contraignantes ; cette heuristique s’est av´er´ee efficace sur des probl`emes coh´erents ;
• d´esinstanciation de la variable qui intervient le moins dans les justifications d’efface-ments de valeur, l’id´ee ´etant de conserver au maximum le cœur de l’incoh´erence ; cette heuristique s’est av´er´ee efficace sur des probl`emes incoh´erents ; nous avons ´egalement montr´e dans [204]que sous certaines conditions, cette heuristique de d´esinstanciation * ´
etait capable de prouver l’incoh´erence d’un probl`eme, contrairement aux algorithmes classiques de recherche locale sur des instanciations compl`etes.
4.5 Bilan
Dans ce chapitre, nous avons pr´esent´e nos contributions concernant l’utilisation de tech-niques de recherche locale pour r´esoudre des probl`emes de programmation par contraintes, en particulier des probl`emes d’ordonnancement incluant des contraintes temporelles com-plexes, des contraintes sur des profils d’´evolution, et des crit`eres d’optimisation quel-conques. Cette ligne de recherche s’est concr´etis´ee par le d´eveloppement de la biblioth`eque InCELL, et elle correspond au point le plus actif dans nos d´eveloppements en cours. Une des raisons `a cela est que la biblioth`eque InCELL permet de traiter effectivement des applications et de f´ed´erer des travaux de recherche. Plusieurs pistes d’´evolution sont envi-sag´ees pour l’approche CBLS InCELL. Nous d´ecrivons ces pistes dans le chapitre 7 d´edi´e aux perspectives.
Chapitre 5
Synth`ese de contrˆoleur en
contexte non d´eterministe
Les chapitres pr´ec´edents ont pr´esent´e diverses r´ealisations associ´ees `a la probl´ematique de la synth`ese de plans et de la synth`ese d’ordonnancements. Dans ce contexte, deux options ont ´et´e envisag´ees pour faire face aux incertitudes sur l’´evolution r´eelle du syst`eme `a contrˆoler et de son environnement :
• une option consistant `a faire de la planification r´eactive, correspondant `a calculer un plan `a partir d’une version d´eterminis´ee de la r´ealit´e, et `a r´eparer ce plan ou `a replanifier en cas de changement du contexte ;
• une option consistant `a produire un seul plan qui soit robuste et flexible temporelle-ment, repr´esent´e sous la forme d’un POS (Partial Order Schedule [192]).
Nous pr´esentons maintenant une autre cat´egorie de travaux, correspondant `a des ap-proches plus proactives dans lesquelles les incertitudes sur le syst`eme et son environne-ment sont trait´ees en amont. Dans ces approches, diff´erentes situations rencontrables `a l’ex´ecution sont anticip´ees et une r´eponse adapt´ee `a chacune de ces situations est pr´ e-calcul´ee. Les plans produits sont alors conditionnels, et l’ensemble des r´eponses `a chaque situation est appel´e une politique de d´ecision. Dans ce sens, toujours avec comme ligne directrice l’ambition d’utiliser la Programmation Par Contraintes (PPC), nous avons initi´e des travaux en synth`ese de politique pour traiter sp´ecifiquement des probl`emes de d´ecision dans lesquels l’incertitude est mod´elis´ee par une relation de transition non d´eterministe. Cette derni`ere sp´ecifie de mani`ere bool´eenne les ´evolutions possibles du syst`eme `a contrˆoler en fonction des d´ecisions prises. Nous d´ecrivons le contexte de ce travail (section 5.1), les mod`eles consid´er´es (section 5.2), les m´ethodes de r´esolution introduites (sections 5.3 `a 5.5) et un cas d’application trait´e (section 5.6).
5.1 Contexte et motivation
La motivation initiale de ce travail ´etait de pouvoir construire des contrˆoleurs logiciels capables de g´erer des sous-syst`emes embarqu´es `a bord d’un satellite ou d’un avion. Au sens large, un contrˆoleur logiciel est un automate qui se trouve dans un ´etat particulier `a
une ´etape donn´ee, et qui re¸coit des signaux d’entr´ee d´eclenchant ´eventuellement l’´emission de signaux de sortie ainsi qu’un changement d’´etat de l’automate. Voir la figure 5.1 pour une illustration.
k k’
o / c k: état interne du contrôleur avant transitionk’: état interne du contrôleur après transition o: observation réalisée
c: décision de contrôle renvoyée par le contrôleur Contrôleur
Décision c Observation o
Système à contrôler
Figure 5.1 : Sch´ema classique d’interaction entre contrˆoleur et syst`eme `a contrˆoler
La mani`ere couramment utilis´ee dans l’industrie pour construire ces contrˆoleurs consiste `
a les sp´ecifier directement sous la forme d’un ensemble de r`egles sp´ecifiant les sorties `a ´
emettre en fonction des entr´ees re¸cues. Il est ensuite n´ecessaire de valider des propri´et´es garantes du bon fonctionnement du contrˆoleur, soit par simulation, soit par validation formelle, ou par ces deux moyens. Pour la validation formelle, la d´emarche consiste `a confronter la sp´ecification du contrˆoleur avec les propri´et´es `a v´erifier. Si l’une de ces pro-pri´et´es n’est pas satisfaite, la sp´ecification du contrˆoleur est revue, les propri´et´es sont v´erifi´ees `a nouveau... jusqu’`a converger vers un contrˆoleur valide.
Dans les travaux que nous avons r´ealis´es, nous avons cherch´e `a proposer des m´ethodes permettant d’´eviter ces aller-retours entre sp´ecification du contrˆoleur et validation. Plus pr´ecis´ement, nous avons propos´e des m´ethodes de synth`ese de contrˆoleur [230], capables de synth´etiser automatiquement des contrˆoleurs `a partir des ´equations d’´evolution du syst`eme `
a contrˆoler et des propri´et´es devant ˆetre satisfaites par ce syst`eme. Les contrˆoleurs obtenus sont alors valides par construction.