Modélisation par contraintes et exploitation d'une gamme automobile : nouveaux problèmes, nouvelles requêtes, nouveaux besoins en programmation par contraintes

HAL Id: inria-00520306

https://hal.inria.fr/inria-00520306

Submitted on 22 Sep 2010

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.

Modélisation par contraintes et exploitation d’une gamme automobile : nouveaux problèmes, nouvelles

requêtes, nouveaux besoins en programmation par contraintes

Jeam-Marc Astesana, Laurent Cosserat, Hélène Fargier

To cite this version:

Jeam-Marc Astesana, Laurent Cosserat, Hélène Fargier. Modélisation par contraintes et exploita-

tion d’une gamme automobile : nouveaux problèmes, nouvelles requêtes, nouveaux besoins en pro-

grammation par contraintes. JFPC 2010 - Sixièmes Journées Francophones de Programmation par

Contraintes, Jun 2010, Caen, France. pp.33-42. �inria-00520306�

Actes JFPC 2010

Mod´ elisation par contraintes et exploitation d’une gamme automobile : nouveaux probl` emes,

nouvelles requˆ etes, nouveaux besoins en programmation par contraintes

Jean Marc Astesana ¹ Laurent Cosserat ¹ H´ el` ene Fargier ²

1 Renault SA, 13 avenue Paul Langevin 92359 Plessis Robinson

2 IRIT-CNRS, 118 route de Narbonne 31062 Toulouse Cedex 9

{jean-marc.astesana,laurent.cosserat}@renault.com [email protected]

Abstract

La mise au point et l’exploitation de la gamme commerciale d’un constructeur automobile pr´ esentent de multiples probl` emes m´ etier qui peuvent se mod´ eliser comme des probl` emes CSP : d´ etection et analyse d’inco- h´ erence dans la sp´ ecification de la gamme, configuration v´ ehicule, configuration de la pr´ evision. Ces probl` emes mettent en jeu des donn´ ees de taille importante, et leur r´ esolution en situation r´ eelle doit ˆ etre effectu´ ee dans un temps de calcul limit´ e. Cet article pr´ esente, formalise et

´

etudie la complexit´ e de plusieurs de ces probl` emes. Au- del` a de l’´ etude d’une application r´ eelle, son objectif est de proposer ` a la communaut´ e CSP non pas de nouvelles approches de r´ esolution, mais de nouvelles requˆ etes, de nouveaux probl` emes, voire de nouveaux besoins.

1 Introduction

Le formalisme des probl` emes de satisfaction de contraintes (CSP) offre un cadre de formalisation puis- sant pour l’expression d’une multitude de probl` emes, en particulier de nombreux probl` emes acad´ emiques ou issus du monde r´ eel (par exemple les probl` emes de co- loration de graphes, d’ordonnancement, d’affectation de fr´ equence, . . .). R´ esoudre un CSP c’est, quasiment toujours, d´ eterminer s’il est coh´ erent et/ou lui trouver une solution -dans certains cas une solution optimale- et c’est une question difficile : le probl` eme de d´ ecision associ´ e est NP-complet. La grande majorit´ e des tra- vaux de la communaut´ e a donc port´ e sur ce probl` eme, soit en l’abordant de front (proposer les algorithmes les plus efficaces possibles pour d´ eterminer la coh´ erence d’un CSP), soit en cherchant comment le contourner,

par l’´ etude de sous-classes qui seraient polynomiales ou par la d´ efinition d’algorithmes sains mais incomplets.

Or si les CSP, ou les langages de programmation par contraintes, sont largement utilis´ es, ce n’est pas seule- ment parce qu’ils sont munis d’algorithmes de r´ esolu- tion efficaces. C’est aussi parce qu’ils permettent d’ex- primer simplement les donn´ ees des applications mod´ e- lis´ ees. Mais dans ces applications, la question n’est pas toujours de savoir si le CSP est coh´ erent ni mˆ eme d’en trouver une solution. Les applications en configuration de produit, par exemple, d´ efinissent des CSP coh´ erents (pourvus de centaines de milliers de solutions) ... et la machine n’est pas utilis´ ee pour extraire une solution, mais pour aider l’utilisateur ` a construire la sienne.

L’ambition de cet expos´ e est de proposer ` a la com- munaut´ e non pas de nouvelles approches de r´ esolution, mais de nouvelles requˆ etes, de nouveaux probl` emes, voire de nouveaux besoin en mod´ elisation, en exposant quelques probl` emes m´ etier de Renault qui ont pour point commun la n´ ecessit´ e d’inf´ erer sur le syst` eme de contraintes repr´ esentant la gamme, et notamment la configuration de v´ ehicules automobiles.

2 Mod´ elisation ` a base de contraintes de la gamme Renault

La gamme de v´ ehicules de Renault est tr` es ´ etendue.

Le nombre de v´ ehicules diff´ erents dans la gamme d’un

mod` ele peut ˆ etre ´ enorme. Par exemple, l’ensemble

des petites fourgonnettes ”Trafic” comprend 10 ²¹ v´ e-

hicules diff´ erents. Ce nombre rend impossible l’´ enu-

m´ eration de l’ensemble de ces v´ ehicules dans une base

de donn´ ees. Cet ensemble doit alors ˆ etre repr´ esent´ e en intention. La gamme peut ˆ etre vue comme sp´ e- cifi´ ee par mod` ele, et dans la suite de cet article on entend par ”gamme” l’ensemble de toutes les diff´ e- rentes variantes possibles d’un mod` ele. Les v´ ehicules sont d´ efinis par des variables (carburant, couleur, etc.) qui prennent des valeurs dans des domaines ´ enum´ er´ es ({essence, diesel, gpl}, {blanc, noir, rouge}, etc.). Les choix possibles pour ces variables ne sont pas ind´ e- pendants les uns des autres (typiquement, un niveau d’´ equipement donn´ e n’est pas disponible sur toutes les motorisations) : des d´ ependances sont mod´ elis´ ees par un syst` eme de contraintes entre ces variables. On a ainsi tous les ingr´ edients d’un probl` eme CSP, dont chaque solution d´ efinit un v´ ehicule pr´ ecis de la gamme.

Plusieurs travaux ont propos´ e d’utiliser des exten- sions des CSP pour formaliser des probl` emes de confi- guration, traitant g´ en´ eralement de difficult´ es de repr´ e- sentation sp´ ecifiques ` a ces types de probl` emes, comme par exemple le fait que l’existence d’une variable puisse d´ ependre la valeur affect´ ee ` a une autre. L’´ etude des probl` emes de configuration a ainsi pouss´ e la commu- naut´ e ` a ´ etendre le mod` ele CSP de base, d´ efinissant ainsi les CSP dynamiques [8], CSP composites [10], CSP interactifs [7], CSP ` a hypoth` eses [1], etc. Dans cet article, nous n´ egligerons la prise en compte de ces difficult´ es de repr´ esentation pour nous tourner plutˆ ot vers les requˆ etes adress´ ees au mod` ele, vers la question de l’exploitation des donn´ ees. On supposera donc que la gamme est repr´ esent´ ee par un CSP ”classique” .

Les notations et d´ efinitions pr´ ecises n´ ecessaires ` a la formalisation de l’ensemble des questions ´ etudi´ ees ici seront introduites en Section 4. Disons pour l’instant simplement qu’un CSP est un triplet P =< X, D, C >

o` u X est l’ensemble de ses variables, D l’ensemble des domaines respectifs de ces variables et C l’ensemble (suppos´ e fini) de ses contraintes ; on d´ esignera par Sols(P ) l’ensemble des solutions de P.

Comme la plupart des instances issues de probl` emes r´ eels, les CSP repr´ esentant les mod` eles de la gamme Renault poss` edent des sp´ ecificit´ es particuli` eres, en termes s´ emantiques (type de variables et contraintes) et syntaxiques (forme du graphe de contraintes).

La gamme de Renault est construite suivant ce qu’on appelle le ”mod` ele version-options”. Selon ce mo- d` ele, les variables se r´ epartissent en deux cat´ egories :

– un petit nombre de variables servant ` a d´ efinir les versions : appelons-les variables majeures. Soit M aj ⊂ X leur ensemble : pour fixer les id´ ees, on peut consid´ erer que la restriction de Sols(P ) aux variables de M aj d´ efinit l’ensemble des versions de la gamme. Une variable encodant pr´ ecis´ ement la version peut exister, mais ce n’est pas syst´ ema- tiquement le cas : dans le cas contraire, la notion

de version n’existe qu’implicitement, comme com- binaison de valeurs de variables majeures.

– le reste des variables, la grande majorit´ e, dont les valeurs possibles d´ ependent de la version : ce sont les variables mineures ´ el´ ements de M in. M aj et M in forment une partition de X . Une valeur du domaine d’une variable mineure pourra ainsi ˆ etre impossible sur une version, optionnelle sur une autre et obligatoire sur une troisi` eme.

On peut regrouper comme suit les contraintes de sp´ e- cification de la gamme :

– Les contraintes majeures portent sur des variables majeures qui d´ efinissent l’ensemble des versions.

Typiquement, une contrainte majeure est directe- ment d´ efinie par une Table, c’est-` a-dire par l’´ enu- m´ eration explicite des combinaisons autoris´ ees de valeurs des variables de la contrainte.

– Les contraintes options sont des contraintes de la forme ”(x = v) ⇒ (y ∈ A)”, x ´ etant une va- riable majeure, v une valeur de son domaine, y une variable mineure, et A un sous-ensemble du domaine de x. Par exemple, on peut utiliser ce type de contrainte pour sp´ ecifier la liste des auto- radios disponibles sur les versions haut de gamme.

– Les contraintes packs. Il arrive qu’un lot de plu- sieurs options soit regroup´ e en une seule : un pack (ces options s’appellent alors les compo- sants du pack). Les packs donnent lieu ` a de nom- breuses contraintes qui complexifient le CSP. Par exemple, la contrainte de d´ efinition d’un pack ex- prime que le choix d’un pack pack implique la s´ e- lection de la totalit´ e de ses n composants opt i : (x = pack) ⇒ ∧ ⁿ _i=1 (x i = opt i ). De plus, une mˆ eme option peut ˆ etre un composant de plusieurs packs, qui s’excluent alors mutuellement.

– Les contraintes quelconques. Il reste des contraintes ne faisant pas partie des cat´ ego- ries pr´ ec´ edentes. Elles peuvent inclure des variables majeures et mineures.

Notons que certaine contraintes, comme les contraintes options, s’expriment par des combinaisons bool´ eennes de conditions (variable = valeur) ou de conditions (variable ∈ sous-domaine ) ; par exemple la contrainte (carburant = diesel) ∧ (type boite = boite auto) ⇒ (type chauf f age = clim regulee). On parle alors d’expression bool´ eenne ¹ .

Dans les param` etres les plus dimensionnants des

1

Il est bien entendu possible de mod´ eliser la gamme de ma-

ni` ere enti` erement bool´ eenne et d’obtenir ainsi des formules de

la logique propositionnelle ; plusieurs codages sont possibles -

voir par ex [13], mais pour des raisons de lisibilit´ e, c’est souvent

l’encodage direct qui est utilis´ e : pour chaque variable var qui

admet les valeurs possibles val

, ..., val

on d´ efinit n variables

bool´ eennes val

, ..., val

. Ces variables sont classiquement li´ ees

par des contraintes d’exhaustivit´ e et d’exclusivit´ e.

probl` emes CSP d´ efinissant une gamme, on peut citer : – La combinatoire des variables majeures. En confi- guration commerciale il y a au plus une centaine de versions, mais sur des gammes dites techniques, la projection de Sols(P) sur les variables majeures peut en comporter plusieurs dizaines de milliers.

– le nombre de variables mineures et majeures. On peut supposer que card(M in) ≤ 150. Le nombre de variables majeures est de l’ordre de 10.

La complexit´ e est aggrav´ ee par les packs : au pire on peut en avoir une dizaine, chacun impliquant typi- quement de 2 ` a 5 options composantes.

Mais l’essentiel de la difficult´ e vient des contraintes quelconques. Contrairement aux contraintes options, qui relient les variables de mani` ere essentiellement hi´ e- rarchique, ces contraintes peuvent porter sur n’im- porte quelles variables, et donc complexifier le graphe de contraintes. Il peut y en avoir jusqu’` a une cen- taine : elles portent g´ en´ eralement sur moins de quatre variables (sur deux variables dans la moiti´ e des cas).

3 Exploitation de la gamme

Nous d´ ecrivons maintenant les requˆ etes m´ etier qui se posent chez Renault lors des tˆ aches d’´ elaboration, la maintenance et l’exploitation d’une gamme de v´ ehi- cules - dit autrement, lors de la d´ efinition, la modifi- cation ou l’exploitation de ce CSP. Leur formalisation en termes de CSP sera abord´ ee en Section 4.

3.1 ´ Elaboration de la documentation v´ ehicule Les premi` eres tˆ aches interviennent en amont du pro- bl` eme de configuration client, en phase de mod´ elisa- tion de la gamme par un syst` eme de contraintes. On parle d’´ elaboration de la ”documentation v´ ehicule”. Il s’agit de savoir si la gamme d´ ecrite par le syst` eme est coh´ erente, dans un sens ´ etendu : dans certains cas, il ne suffit pas qu’il existe des v´ ehicules compatibles avec les contraintes, il faut aussi que les possibilit´ es sp´ ecifi´ ees par les contraintes soient effectives. Suppo- sons par exemple qu’une contrainte signifie ”Les v´ ehi- cules ayant le moteur M3 peuvent avoir comme type de chauffage : climatisation manuelle ou climatisation r´ egul´ ee.” Si d’autres contraintes rendent incompatible le moteur M3 et la climatisation manuelle, la docu- mentation v´ ehicule est consid´ er´ ee comme incoh´ erente.

Autrement dit, certaines contraintes de la documen- tation v´ ehicule ont une double s´ emantique : n´ egative (elles interdisent des combinaisons de valeurs), et po- sitive (les combinaisons autoris´ ees par une contrainte doivent ˆ etre effectivement possibles) : nous appelons cette propri´ et´ e coh´ erence positive. C’est le cas des contraintes majeures et des contraintes options. Les

questions qui se posent sont :

Coh´ erence (contextuelle) de la gamme : Y a-t-il au moins un v´ ehicule r´ epondant ` a cette d´ efinition de gamme ? ´ Etant donn´ ee une liste de quelques variables dont on impose la valeur, y a-t-il dans la gamme au moins un v´ ehicule compatible avec cette affectation ? Plus g´ en´ eralement, ´ etant don- n´ ee une expression bool´ eenne c portant sur des paires (variable = valeur), y a-t-il dans la gamme au moins un v´ ehicule v´ erifiant c ?

Lorsque la r´ eponse ` a ces questions est non, c’est que la documentation v´ ehicule est erron´ ee dans son ´ etat courant. Il faut alors analyser l’incoh´ erence, c’est-` a- dire d´ eterminer un jeu minimal de contraintes qui suf- fit ` a expliquer l’impossibilit´ e des v´ ehicules pr´ evus :

Conflits : Trouver un ensemble de contraintes in- coh´ erent, qui soit minimal pour l’inclusion.

Conflits contextuels : Etant donn´ ´ ee une liste de va- riables dont la valeur est impos´ ee, trouver un en- semble de contraintes incoh´ erent avec ces affecta- tions qui soit minimal pour l’inclusion.

Coh´ erence positive Pour chaque contrainte ` a s´ e- mantique positive, et chaque tuple qu’elle auto- rise, existe il un v´ ehicule de la gamme qui r´ ealise ce tuple. De la mˆ eme fa¸ con, pour chaque variable et chaque valeur de son domaine, existe-t-il un v´ ehicule qui affecte cette valeur ` a cette variable.

3.2 Restitution de la gamme

Lorsque la gamme a ´ et´ e d´ efinie de mani` ere coh´ e- rente, on cherche ` a en extraire des donn´ ees significa- tives techniquement en consid´ erant des ensembles de variables {x ₁ , . . . , x _k } (g´ en´ eralement, k ≤ 6), et g´ e- n´ erant automatiquement des descriptions synth´ etiques des combinaisons des valeurs possibles de ces variables, typiquement sous la forme d’expressions bool´ eennes sur des propositions de type variable = valeur.

Validit´ e de description synth´ etique : Tester si tous les v´ ehicules de la gamme v´ erifient une descrip- tion synth´ etique c donn´ ee.

Simplification de description synth´ etique : Une description synth´ etique c donn´ ee est elle mini- male (peut-on, sans supprimer une variable de c sans compromettre sa validit´ e ?)

G´ en´ eration de description synth´ etique : Etant ´

donn´ e un ensemble de variables, quelles sont les

combinaisons de valeurs pour ces variables qui

sont autoris´ ees par la gamme (id´ ealement, on

voudrait g´ en´ erer cette projection sous la forme

d’une description synth´ etique minimale) ?

On cherche enfin ` a dimensionner la diversit´ e de la

gamme, en termes de nombres de v´ ehicules diff´ erents :

Comptage : Combien de v´ ehicules la gamme

compte-t-elle ? Combien de v´ ehicules ayant un ensemble donn´ e de valeurs impos´ ees la gamme compte-t-elle ? Combien de combinaisons de va- leurs diff´ erentes sont autoris´ ees pour un sous- ensemble de variables Y : typiquement, on peut vouloir dimensionner la ”diversit´ e technique”, c’est-` a-dire le nombre de v´ ehicules existant dans la gamme, hors consid´ erations de teinte , appella- tion commerciale et pays de commercialisation.

3.3 Elaboration de la documentation pi` ´ eces La documentation pi` eces de Renault sp´ ecifie les pi` eces mont´ ees sur les v´ ehicules de la gamme consi- d´ er´ ee. Elle est distincte de la documentation v´ ehicule, dont les variables repr´ esentent des prestations per¸ cues par les clients et non des pi` eces. Le lien est assur´ e par ce qu’on appelle le ”cas d’emploi” : le cas d’emploi d’une pi` ece p i est une expression bool´ eenne c i portant sur des atomes variable = valeur de la documentation v´ ehicule - cette contrainte sp´ ecifie les v´ ehicules sur la- quelle la pi` ece est mont´ ee. Par exemple, une pi` ece se monte sur les v´ ehicules qui ont un moteur essence et une boˆıte automatique mais pas de toit ouvrant.

Les pi` eces sont regroup´ ees en ”pi` eces g´ en´ eriques”.

Une pi` ece g´ en´ erique, par exemple l’autoradio, est une fonction r´ ealis´ ee par la pi` ece. Pour que la documenta- tion pi` eces soit coh´ erente, il faut que chaque v´ ehicule ait un autoradio (propri´ et´ e d’exhaustivit´ e), qu’aucun v´ ehicule n’en ait plusieurs (propri´ et´ e de non-dualit´ e) et que tout autoradio soit utilis´ e dans au moins un v´ ehi- cule. On peut voir une pi` ece g´ en´ erique comme une va- riable suppl´ ementaire p dont les valeurs sont les pi` eces associ´ ees p 1 , ..., p n . A chaque p i correspond une ex- pression bool´ eenne c _i d´ efinissant son cas d’emploi. Les questions qui se posent alors sont :

Concision de la doc. : Pour chaque pi` ece associ´ ee (chaque cas d’emploi), existe-t-il au moins un v´ e- hicule de la gamme qui le valide ?

Exhaustivit´ e de la doc. : Existe-t-il un v´ ehicule ne montant aucune des pi` eces associ´ ees ` a une pi` ece g´ en´ erique donn´ ee (ne validant aucun des cas d’em- ploi de la pi` ece g´ en´ erique) ?

Non-dualit´ e des Emplois : Existe-t-il un v´ ehicule montant deux des pi` eces, ou plus, associ´ ees ` a une pi` ece g´ en´ erique donn´ ee (validant au moins deux des cas d’emplois de la pi` ece g´ en´ erique) ?

Si la r´ eponse est ”oui” ` a l’un des deux derniers points, on veut caract´ eriser ces v´ ehicules ou ces pi` eces : Emplois Inconnus : Donner une condition sur les atomes ”variable = valeur” qui caract´ erise l’en- semble des v´ ehicules ne montant aucune des pi` eces associ´ ees ` a une pi` ece g´ en´ erique donn´ ee ? Emplois Multiples : Quelles sont les ensembles de

pi` eces qui peuvent ˆ etre mont´ ees simultan´ ement

sur un v´ ehicule ; pour chaque ensemble, donner une condition sur les atomes ” variable = valeur”

qui caract´ erise l’ensemble des v´ ehicules suppor- tant ces pi` eces simultan´ ement ?

Il peut sembler relativement simple de construire ces conditions caract´ eristiques en formant des com- binaisons logiques ` a partir des cas d’emplois et des contraintes du CSP, si tant est qu’elles sont expri- m´ ees par des conditions logiques. La difficult´ e est que chaque condition caract´ eristique recherch´ ee doit ˆ etre simplifi´ ee (aucune variable ne doit pouvoir en ˆ etre sup- prim´ ee sans compromettre l’ensemble qu’elle d´ efinit).

3.4 Configuration en ligne

Les probl` emes li´ es ` a la configuration en ligne ont ´ et´ e d´ ej` a abord´ es dans plusieurs articles (voir par exemple [1]). Le principe de la configuration en ligne est que l’utilisateur (un client potentiel) d´ efinit le produit qu’il d´ esire en choisissant interactivement des valeurs pour les variables ; il peut ´ egalement revenir en arri` ere en relˆ achant un ou plusieurs de ses choix. Apr` es chaque action, les domaines de valeurs possibles fournis ` a l’uti- lisateur doivent ˆ etre modifi´ es de mani` ere ` a contenir toutes les valeurs compatibles avec les choix courants, et seulement les valeurs compatibles avec ces choix.

L’utilisateur peut forcer le choix d’une valeur d´ etect´ ee comme incompatible : le CSP devient alors incoh´ e- rent. Quand l’ensemble des choix est incoh´ erent avec les contraintes du CSP, il doit pouvoir revenir sur ses choix pr´ ec´ edents et les relˆ acher.

L’utilisateur doit pouvoir ´ egalement avoir une id´ ee du prix du v´ ehicule qu’il est en train de construire, et du d´ elai d’obtention. Les informations prix sont d´ e- crites par des coˆ uts associ´ es aux valeurs de variables, ou par des fonctions de coˆ ut portant sur quelques va- riables. Le prix d’un v´ ehicule est la somme des prix unitaires. Notons que certains coˆ uts peuvent ˆ etre n´ e- gatifs (ce qui correspond ` a un retrait d’option par rap- port au choix ”standard”). On peut, en simplifiant, supposer que les informations d´ elai sont port´ ees par des conditions compos´ ees sur la gamme et d´ efinissant des intervalles de valeurs (”si le moteur choisit est hy- bride, alors le d´ elai est d’au moins deux mois”).

Pour aider l’utilisateur dans sa d´ emarche, le syst` eme doit r´ epondre aux requˆ etes suivantes :

Coh´ erence globale : Assurer, apr` es chaque modifi- cation de domaine (choix de valeur ou relaxation) que les domaines correspondent exactement aux valeurs compatibles avec les choix courants.

Estimation du prix / du d´ elai : Calculer le prix (ou le d´ elai) min (ou max) des v´ ehicules de la gamme compatibles avec les choix courants.

Calcul de restauration : En cas d’incoh´ erence,

identifier un ou des sous-ensembles maximaux

coh´ erents de restrictions utilisateur.

Calcul de conflit : Identifier des sous-ensembles mi- nimaux de choix utilisateur incoh´ erents, ou inco- h´ erents avec des choix de valeur de variable.

Simulation des choix : D´ eterminer quel serait l’´ etat des domaines si l’utilisateur choisissait telle valeur pour telle variable (ce qui revient ` a la premi` ere requˆ ete, la coh´ erence globale)

Compl´ etion de la configuration : Lorsqu’un cer- tain nombre de variables ”obligatoires” ont ´ et´ e renseign´ ees, compl´ etion automatique de la confi- guration courante ` a la demande de l’utilisateur (´ eventuellement sur un crit` ere de minimisation de prix ou de d´ elai).

3.5 Probabilisation de la gamme

La sp´ ecification de la gamme permet ´ egalement ` a l’entreprise de construire des pr´ evisions sur les ventes - typiquement, pour dimensionner sa production et celle de ses fournisseurs. Pour un mod` ele, ces pr´ evisions sont

´

equivalentes ` a la donn´ ee d’un volume global et de pro- babilit´ es (des taux pr´ evisionnels) sur les valeurs de va- riables, conditionn´ ees ´ eventuellement par un contexte.

(”On pr´ evoit le choix de si` eges en cuir dans 30% des v´ ehicules vendus”, ”En Pologne, 25% des v´ ehicules ven- dus seront diesel”). Ces probabilit´ es individuelles sont en principe les projections d’une distribution de proba- bilit´ e jointe sur la gamme. Cette d´ emarche - construire une telle distribution ` a partir de taux - est appel´ ee pro- babilisation de la gamme.

Cette distribution n’est pas connue, mais elle est sp´ ecifi´ ee partiellement par la donn´ ee de certaines de ses projections sur des variables (on parle de distributions marginales) et par la d´ efinition de la gamme. Il est pos- sible qu’elle soit sur-sp´ ecifi´ ee, c’est-` a-dire qu’il n’existe aucune distribution de probabilit´ e sur la gamme dont les marginales correspondent aux taux renseign´ es, ceci

`

a cause des contraintes d´ efinissant la gamme. Dans le cas contraire, elle est g´ en´ eralement sous-sp´ ecifi´ ee : plusieurs distributions jointes diff´ erentes peuvent pro- duire les mˆ emes marginales. Dans ce cas la probabilit´ e d’un v´ ehicule n’est pas connue avec pr´ ecision, mais l’on peut en connaˆıtre la plus petite et la plus grande valeurs possibles. De la mˆ eme fa¸ con, plusieurs distri- butions peuvent ˆ etre envisag´ ees pour les marginales (pour les taux) non renseign´ ees. Les requˆ etes en rap- port avec la probabilisation de la gamme sont :

Coh´ erence des taux : Les taux sont-ils coh´ erents (existe-t-il une distribution de probabilit´ e sur la gamme dont les marginales sont pr´ ecis´ ement les taux renseign´ es) ?

Taux conflictuels : Si les taux sont incoh´ erents, en exhiber un sous-ensemble (minimal) incoh´ erent modulo la d´ efinition de la gamme.

Configuration des taux : Si les taux sont coh´ erents, calculer une borne min et une borne max de la probabilit´ e de l’affectation d’une valeur ` a une va- riable de v´ ehicule. Utilis´ e it´ erativement avec la d´ efinition de taux, ce m´ ecanisme permet de confi- gurer progressivement un jeu de taux qui reste coh´ erent ` a toutes les ´ etapes de la construction.

Extrapolation de taux : Si les taux sont coh´ erents, calculer une borne min et une borne max de la probabilit´ e d’une expression bool´ eenne sur des af- fectations - typiquement, sur des cas d’emploi. Ce calcul permet notamment d’encadrer les volumes pr´ evisionnels de pi` eces.

G´ en´ eration d’´ echantillon : Les taux ´ etant coh´ e- rents, g´ en´ erer un ´ echantillon de n v´ ehicules conform´ ement ` a la distribution de probabilit´ e sous-jacente ; si elle est sous-sp´ ecifi´ ee, on peut se baser sur la distribution d’entropie maximale. Cet

´ echantillon sera utilis´ e comme une commande pr´ e- visionnelle par d’autres logiciels (simulation de la production, calcul de prix de revient, etc.).

3.6 Temps de r´ eponse

Pour les applications interactives (typiquement, la configuration en ligne) le temps de r´ eponse doit ˆ etre (au pire) de l’ordre de la seconde. Les applications hors ligne, elles, peuvent compter leur temps de calcul en heures. Mais si elles ont un grand nombre de requˆ etes

`

a effectuer, cela signifie que chaque requˆ ete devra ´ ega- lement prendre un temps r´ eduit (entre la milliseconde et la seconde, suivant les cas). Cependant, il reste pos- sible de consacrer un temps beaucoup plus ´ elev´ e (par exemple se comptant en minutes) pour les requˆ etes les plus difficiles, tant que cela ne modifie pas l’ordre de grandeur du temps de calcul total. C’est cette logique qui pr´ evaut pour les contrˆ oles de coh´ erence de la do- cumentation v´ ehicule et de la documentation pi` eces.

4 Formalisation des requˆ etes ; complexit´ e

Nous ´ etudions ici comment les requˆ etes pr´ esent´ ees en Section 3 peuvent ˆ etre formalis´ ees en termes de CSP, et pr´ esentons nos premiers r´ esultats quant ` a leur complexit´ e th´ eorique.

4.1 Notations et d´ efinitions

CSP Un CSP est, on l’a vu, un triplet P =<

X, D, C >. Pour toute variable x de X , D(x) est le domaine (suppos´ e fini) de x. Pour toute contrainte c de C, on note vars(c) l’ensemble des variables dont elle restreint les valeurs.

Une affectation d est une fonction qui associe ` a

chaque x ∈ X une valeur de son domaine ou le sym-

bole ∗, qui indique que la variable n’a pas ´ et´ e affect´ ee.

d est compl` ete (resp. partielle) si le symbole ∗ n’est pas (resp. est) pr´ esent. Plus largement, on dit que d affecte Y ⊆ X (resp. c) ssi pour tout x ∈ Y (resp. pour tout x ∈ vars(c)), d(x) 6= ∗. D(Y ) = {d, ∀x, d(x) = ∗ ⇔ x / ∈ Y } est l’ensemble des affectations de Y ⊆ X. En- fin, on note vars(d) les variables affect´ ees dans d, et on dit que d <sup>0</sup> ´ etend d (` a vars(d ⁰ )) ssi var(d) ⊆ vars(d ⁰ ) et ∀x ∈ vars(d), d(x) = d ⁰ (x) ; ceci est not´ e d ⁰ | = d.

Une contrainte peut ˆ etre vue comme une fonction c de l’ensemble des affectations de vars(c) dans {>, ⊥} : c(d) = > ssi d satisfait la contrainte. On ne fait pas d’hypoth` ese sur la mani` ere dont sont repr´ esent´ ees les contraintes, mais on suppose que, pour toute affecta- tion d affectant (au moins) toutes les variables de c, on peut tester en temps polynˆ omial (id´ ealement, lin´ eaire) si d satisfait c (not´ e d | = c) ou la viole (not´ e d 2 c). Une solution d’un CSP est une affectation compl` ete de ses variables qui satisfait toutes ses contraintes. On note Sols(P ) l’ensemble des solutions de P . Si Sols(P) = ∅, P est dit incoh´ erent, sinon, il est dit coh´ erent.

Sols(P ) ^↓Y = {d ∈ D(Y ) t.q. ∃d ⁰ ∈ Sols(P), d ⁰ | = d} d´ enote la projection de Sols(P ) sur Y ⊆ X.

On dit que v est une valeur globalement coh´ erente pour x ssi v ∈ Sols(P ) ^↓{x} . Lorsque toute les va- leurs des domaines du CSP sont globalement coh´ e- rentes pour la variable correspondante, on dit que les domaines du CSP sont globalement coh´ erents (ou sim- plement que le CSP est globalement coh´ erent).

Conditions Bool´ eennes Un fluent est un couple (x, A), avec x ∈ X (et g´ en´ eralement, A ⊆ D(x), mais pas n´ ecessairement) ; il est ´ el´ ementaire quand A est un singleton - il repr´ esente alors une affectation de x.

Une condition bool´ eenne est une formule logique (uti- lisant les op´ erateurs ∨, ∧, = ⇒ , ¬, ⇔ dans leur accep- tion classique) dont les atomes sont des fluents. vars(c) d´ enote l’ensemble des variables de c.

Une affectation d telle que x ∈ vars(d) satisfait le fluent f = (x, A) si et seulement si d(x) ∈ A (on note f (d) = >). Soit c une condition bool´ eenne et d une affectation de vars(c). La valeur de v´ erit´ e de c dans d, not´ ee c(d) est calcul´ ee conform´ ement ` a l’interpr´ etation habituelle des op´ erateurs logiques. d satisfait c (not´ e d | = c) ssi c(d) = >.

Certaines contraintes de la gamme seront repr´ esen- t´ ees par des conditions bool´ eennes - typiquement les contraintes options (c.f. section 2). Les description syn- th´ etiques utiles aux tˆ aches de restitution de la gamme (c.f. Section 3.2) et les cas d’emplois relatifs ` a la docu- mentation pi` eces (c.f. Section 3.3)le seront ´ egalement.

Dans la suite, on suppose g´ en´ eralement que les condi- tions bool´ eennes manipul´ ees sont intrins` equement co- h´ erentes (∃d ∈ D(vars(c)), c(d) = >) et que l’on peut

tester en temps polynˆ omial (id´ ealement, lin´ eaire) leur satisfaction par une affectation de leurs variables.

4.2 R´ esultats

Les Tables 1 ` a 4 d´ ecrivent comment les requˆ etes pr´ esent´ ees en section 3 peuvent ˆ etre formalis´ ees, et donnent nos premiers r´ esultats quant ` a leur com- plexit´ e. Certaines d´ efinissent clairement des probl` emes de d´ ecision au sens de la th´ eorie de la complexit´ e, par exemple le probl` eme de coh´ erence de la gamme (il revient ` a d´ eterminer si < X, D, C > est coh´ e- rent). D’autres sont des probl` emes de recherche sou- vent NP-difficiles. Dans les Tables qui suivent, nous essayons d’affiner cette information : la complexit´ e d’un probl` eme de recherche d’objet (ex : d’une so- lution d’un CSP, d’un ensemble minimal incoh´ erent de contraintes) est en effet directement li´ ee ` a celle de l’existence d’un tel objet ou ` a celle du test de confor- mit´ e de l’objet. Il peut arriver que le test de confor- mit´ e soit lin´ eaire alors que le test d’existence est diffi- cile (typiquement, pour l’existence / le test de solution d’un CSP) ; il peut ´ egalement arriver que le test d’exis- tence soit trivial, alors que le test de conformit´ e est difficile (par exemple, pour l’existence / le test d’en- sembles (minimaux) incoh´ erents de contraintes). Faute de place, seules les preuves de complexit´ e les moins

´

evidentes seront ´ evoqu´ ees ² .

Documentation v´ ehicule (voir Table 1). La requˆ ete de Coh´ erence (´ eventuellement contextuelle) corres- pond au test de coh´ erence, classique, d’un CSP, d’o` u sa NP-compl´ etude. Sans surprise, on appellera conflit un ensemble incoh´ erent de contraintes, et l’objectif est de connaˆıtre des conflits minimaux pour l’inclusion. On retrouve des notions de sous ensemble minimaux in- coh´ erents ´ etudi´ ees depuis la fin des ann´ ees 80 en IA et plus r´ ecement en configuration [3][4][1] [6] (voir en particulier [4][6] pour le cas contextuel). La recherche de conflits minimaux (´ eventuellement contextuels) est NP-difficile, puisque le simple test d’(in)coh´ erence de

< X, D, C ⁰ > appelle la r´ esolution d’un probl` eme de coh´ erence. D’apr` es [1], la question est BH ₂ -compl` ete. <sup>3</sup> La question de la coh´ erence positive du mod` ele est ´ evidement une question de coh´ erence globale des contraintes et des domaines. Elle est donc NP-difficile.

2

Pour plus de d´ etails voir ftp://ftp.irit.fr/IRIT/RPDMP/

PapersFargier/wsecai10.pdf

3

BH

est l’ensemble des probl` emes qui se ram` enent ` a un

probl` eme de NP et un probl` eme de CO-NP. Le probl` eme BH

-

complet canonique est le probl` eme SAT-UNSAT : il s’agit de

d´ eterminer si, ´ etant donn´ ee une paire (φ, ψ) de 3-CNF, la pre-

mi` ere est satisfiable et la seconde insatisfiable).

Nom Donn´ ee Requˆ ete Complexit´ e Coh´ erence de la gamme < X, D, C > < X, D, C > admet-il une solution ? NP-complet Coh´ erence contextuelle < X, D, C > < X, D, C ∪ {c} > admet-il une solution ? NP-complet

c une cond. bool´ eenne coh´ erente

Conflits < X, D, C > D´ eterminer si BH

-complet

C

⊆ C (i) < X, D, C

> incoh´ erent et (ii) ∀C” ( C

, < X, D, C” > coh´ erent

Conflits contextuels < X, D, C > D´ eterminer si BH

-complet

Cxt un ensemble de cond. (iii) < X, D, C

∪ Cxt > incoh´ erent et bool´ eennes coh´ erentes , (iv) ∀C” ( C

, < X, D, C” ∪ Cxt >

C

⊆ C coh´ erent

probl` eme de recherche : trouver un /tous les C

respectant (i) et (ii) (resp. (iii) et (iv))

Coh´ erence positive < X, D, C > Coh´ erent D´ eterminer si c est globalement coh´ erente NP-complet c ∈ C une contrainte (∀d ∈ D(vars(c)), d | = c y compris si d’arit´ e inf´ erieure ` a k ⇒ ∃d

∈ Sols(P ), d

| = d) c est unaire

Tab. 1 – R´ esultats : ´ Elaboration de la documentation v´ ehicule

Nom Donn´ ee Requˆ ete Complexit´ e

Validit´ e de description P =< X, D, C > coh´ erent, D´ eterminer si c est valide CO-NP complet c une cond. bool´ eenne coh´ erente (i.e. si ∀d ∈ Sols(< X, D, C >), d | = c)

Simplification de c une cond. bool´ eenne coh´ erente D´ eterminer si c est minimale O(d

)

description ∀x ∈ vars(c), ∃d, d

∈ D(vars(c)) t.q.

(∀y = xd(y) 6= d

(y)) ∧ (d | = c)(∧d

2 c))

G´ en´ eration de P =< X, D, C > coh´ erent, D´ eterminer si c ´ equivaut ` a Π

-complet description c une cond. bool´ eenne coh´ erente Sols(P )

(si ∀d ∈ D(vars(c)) :

c(d) = > ⇔ d ∈ Sols(P )

) probl` eme de recherche : trouver un c t.q. vars(c) ⊆ Y

et c ´ equivaut ` a Sols(P)

Comptage P =< X, D, C >, coh´ erent, Calculer |Sols(P )

| #P-difficile Y ⊆ X

Tab. 2 – R´ esultats : Restitution de la gamme

Nom Donn´ ee Requˆ ete Complexit´ e

Concision de la doc. P =< X, D, C >, coh´ erent D´ eterminer si C

est concis NP-complet C

un ensemble (∀c

∈ C

, < X, D, C ∪ {c

} > coh´ erent)

de cond. bool´ eennes coh´ erentes

Exhaustivit´ e de la doc. P =< X, D, C >, coh´ erent D´ eterminer si C

est exhaustif CO-NP complet C

un ensemble (si < X, D, C ∪ S

c⁰∈C⁰

{¬c

} >

de cond. bool´ eennes coh´ erentes est incoh´ erent)

probl` eme de recherche trouver une cond. bool´ eenne telle que d | = c ⇔ (∀c

∈ C

, d 2 c

) NP-difficile coh´ erente c

Non-dualit´ e des emplois P =< X, D, C >, coh´ erent D´ eterminer si C

comporte des cas NP-complet C

un ensemble de dualit´ e (si ∃c

6= c” ∈ C

de cond. bool´ eennes coh´ erentes t.q. < X, D, C ∪ {c

, c”} > coh´ erent)

probl` eme de recherche trouver une cond. bool´ eenne telle que ´ etant donn´ es c

, c

∈ C

: NP-difficile coh´ erente c ∀d ∈ Sols(P ) : (d | = c ⇔ d | = c

et d | = c”)

Tab. 3 – R´ esultats : ´ elaboration de la documentation pi` eces

Nom Donn´ ee Requˆ ete Complexit´ e Coh´ erence globale P =< X, D, C >, coh´ erent Existe t il d

∈ Sols(P ) t.q. NP-complet

x ∈ X \ vars(d), v ∈ D(x) d

(x) = v ?

Coh´ erence globale P =< X, D, C >, glb. coh´ erent Existe t il d

∈ Sols(P )

(version incr´ ementale) d tq. ∃d

∈ Sols(P), d

| = d d

| = d et d

(x) = v ? NP-complet x ∈ X, v ∈ D(x)

Estimation du prix P =< X, D, C >, coh´ erent Calculer

S un ens. fini de fct de coˆ ut sur X α

= min

Σ

s(d

) NP-difficile d une affectation (partielle) α

= max

Σ

s(d

) NP-difficile Estimation du d´ elai P =< X, D, C >, coh´ erent Calculer

x

une variable codant le d´ elai α

= min

d

(x

) NP-difficile d une affectation (partielle) α

= max

d

(x

) NP-difficile Calcul de restauration P =< X, D, C > Est il vrai que < X, D, C ∪ R > BH-2 complet

Choix un ens. de cond. bool´ eennes est coh´ erent et que ∀R

⊆ Choix t.q.

R ⊆ Choix R ( R

, < X, D, C ∪ R

>

est incoh´ erent ?

Calcul de conflit P =< X, D, C > Est il vrai que < X, D, C ∪ R > BH-2 complet Choix un ens. de cond. bool´ eennes est incoh´ erent et que ∀R

( R

R ⊆ Choix < X, D, C ∪ R

> est coh´ erent ?

Compl´ etion d une affectation (partielle) Existe-t-il d

∈ Sols(P ) t.q. d

| = d? trivial P =< X, D, C > glb. coherent pour d

Probl` eme de recherche Trouver d

∈ Sols(P ) t.q d

| = d ? ? ? ? ?

Probl` eme de recherche S un ens. fini de fct de coˆ ut Trouver d

∈ Sols(P ) tel que d

| = d NP-Difficile

version optimisation et que ∀d” ∈ Sols(P) si d” | = d

alors Σ

s(d

) ≤ Σ

s(d”)

x

une variable codant le d´ elai Trouver d

∈ Sols(P ) t.q. d

| = d NP-difficile et ∀d” ∈ Sols(P ), d” | = d ⇒ d”(x

) ≤ d

(x

)

Tab. 4 – R´ esultats : Configuration en ligne

Restitution de la gamme (voir Table 2). En resti- tution de la gamme, on cherche ` a obtenir des descrip- tions synth´ etiques sur des sous-ensembles de variables - techniquement, ce sont des projections de l’ensemble des solutions du CSP sur ces sous-ensembles. Id´ eale- ment, on les voudrait les plus simples possibles, c’est-` a- dire impliquant le moins de variables possible. Dans le contexte de notre application, ces description doivent ˆ etre donn´ ees sous la forme d’une condition bool´ eenne coh´ erente (la coh´ erence interne des descriptions ne doit pas ˆ etre une source de complexit´ e). Techniquement, nous dirons donc qu’une description bool´ eenne c est valide ssi ∀d ∈ Sols(P), d | = c, qu’elle est synth´ e- tique si elle co¨ıncide avec la projection de la gamme sur ses variables (∀d ∈ D(vars(d)), c(d) = > ⇔ d ∈ Sols(P ) ^↓vars(c) ) et qu’elle est minimale si il n’existe pas de Y ( vars(C) telle que la restriction de c ` a Y lui soit ´ equivalente. Le probl` emes de validit´ e est CO- NP complet, les probl` eme d’inf´ erence clausale ou de redondance de contrainte en ´ etant des cas particuliers.

Le test de conformit´ e associ´ e ` a la G´ en´ eration de description est Π ^P ₂ -complet ⁴ . Le principe de la d´ e-

4

Rappelons qu’un probl` eme appartient ` a Π

= NP

si on peut r´ esoudre son co-probl` eme en (1) faisant appel ` a un NP- oracle et (2) ´ etablissant un certificat non pas de mani` ere poly- nomiale mais en r´ esolvant un probl` eme de CO-NP. Le probl` eme

monstration de est dans notre cas : c est la condi- tion V

x∈Y (x, D(x)) : cette condition s´ electionne un certain nombre de variables (celles de Y ) sans res- treindre les valeurs. Dans ce cas c ´ equivaut ` a Sols(<

X, D, C >) ^↓vars(c) si et seulement si, pour toute af- fectation de Y , il existe une affectation de X \ Y qui satisfasse le CSP. On peut donc r´ eduire le probl` eme canonique de Π <sup>P</sup> <sub>2</sub> (∀Y 1 , ∃Y 2 : Σ, Σ ´ etant une CNF) au probl` eme de test de l’´ equivalence entre la projec- tion sur Y 2 d’un CSP repr´ esentant la CNF et la condi- tion c = V

x∈Y

(x, {true, f alse}). Le test d’apparte- nance ` a Π ^P ₂ est plus simple. L’implication d ∈ Sols(<

X, D, C >) ^↓vars(c) = ⇒ c(d) = > se falsifie avec un oracle (deviner d, v´ erifier que d satisfait toutes les contraintes puis v´ erifier que c(d) = ⊥). Pour falsifier c(d) = > = ⇒ d ∈ Sols(< X, D, C >) ^↓vars(c) , il faut deviner une affectation de vars(c), montrer qu’elle sa- tisfait c, puis montrer qu’elle est inconsistante avec le CSP (ce qui est un probl` eme de CO-NP).

Les probl` emes de d´ ecision li´ es ` a la restitution de la gamme sont typiquement des probl` emes d’inf´ erence.

Cela dit, la projection et la simplification sont basique- ment des probl` emes de recherche auxquels on peut r´ e-

canonique de Π

est celui qui consiste ` a d´ etermininer si une for- mule bool´ eenne quantifi´ ee de la forme ∀Y

∃Y

φ est valide , φ

´

etant une 3-CNF et {Y

, Y

} une partition de ses variables.

pondre par des algorithmes d’´ elimination de variables - en utilisant un espace potentiellement exponentiel.

Elaboration de la documentation pi` ´ eces (voir Table 3). L’id´ ee est de repr´ esenter chaque cas d’emploi par une condition bool´ eenne coh´ erente (la coh´ erence in- terne d’un cas d’emploi n’est pas une source de com- plexit´ e), et de consid´ erer l’ensemble C <sup>0</sup> des cas d’em- ploi d’une pi` ece g´ en´ erique : C ⁰ est exhaustif ssi ∀d ∈ Sols(P ), ∃c ⁰ ∈ C ⁰ t.q. d | = c ⁰ ; on dit que c ⁰ , c ⁰⁰ ∈ C ⁰ forme une paire d’emplois duale ssi ∃d ∈ Sols(P ), (d | = c ⁰ ) et (d | = c ⁰⁰ ). C ⁰ est non exhaustif ssi < X, D, C ∪ S

c

∈C

{¬c ⁰ } > est coh´ erent et il est non dual ssi cha- cun des probl` eme < X, D, C ∪ {c <sup>0</sup> , c <sup>00</sup> } > est inco- h´ erent (o` u c ⁰ , c ⁰⁰ ∈ C ⁰ ) . Enfin, la description de la pi` ece g´ en´ erique est concise ssi chacun des probl` emes

< X, D, C ∪ {c ⁰ } >, c ⁰ ∈ C ⁰ est coh´ erent.

Ces trois questions demandent de tester la coh´ erence ou l’incoh´ erence d’un CSP, coh´ erent au d´ epart, auquel on ajoute une ou plusieurs contraintes. Les preuves de complexit´ e associ´ ees ne pr´ esentent aucune difficult´ e.

Enfin, on veut caract´ eriser par une condition boo- l´ eenne c les v´ ehicules de la gamme ”en erreur” par rapport ` a l’exigence de non-dualit´ e ou d’exhausti- vit´ e de la pi` ece g´ en´ erique. c repr´ esente les cas de non-exhaustivit´ e ssi ∀d ∈ Sols(P ), d | = c ⇔ ∀c ⁰ ∈ C, d viole c ⁰ ; il repr´ esente les cas de non dualit´ e ssi

∀d ∈ Sols(P), d | = c ⇔ ∃c ⁰ , c ⁰⁰ ∈ C, d | = c ⁰ et d | = c ⁰⁰ . Dans le premier cas, la CO-NP difficult´ e se prouve par r´ eduction du probl` eme d’inf´ erence clausale (C = ∅, c est la clause ` a inf´ erer et les c ⁰ sont les n´ egations des clauses de la CNF). La CO-NP difficult´ e du second probl` eme se prouve par r´ eduction du mˆ eme probl` eme (c est la clause ` a inf´ erer et c ⁰ et c” repr´ esentent une partition des clauses).

Configuration en ligne (voir Table 4) La coh´ erence globale des domaines doit ˆ etre assur´ ee en amont de la configuration utilisateur, pour ne lui laisser comme choix de configuration que des valeurs d’option pr´ e- sentes dans au moins un v´ ehicule de la gamme. La version incr´ ementale est la r´ ep´ etition de ce principe en cours de configuration : l’utilisateur fixe une affec- tation d, coh´ erente, et l’on veut, pour toute variable x, ne laisser que des valeurs v pouvant effectivement conduire ` a un v´ ehicule d ⁰ tel que d ⁰ | = d et d ⁰ (x) = v.

Dans ses deux versions, le probl` eme de la maintenance de la coh´ erence globale est un probl` eme NP-difficile.

Pour la prise en compte des coˆ uts, on utisera une mod´ elisation proche de celle des probl` emes ` a contraintes souples (c.f. [12, 2]) : une ”fonction de coˆ ut”

est une fonction s sur D(vars(s)) prenant ses valeurs dans une ´ echelle, ici Z et le ”coˆ ut” d’une affectation est la somme des coˆ uts qui lui sont associ´ es par ces fonc-

tions. Notons que certains coˆ uts pouvant ˆ etre n´ egatifs, il faut th´ eoriquement relaxer l’exigence de monotonie de l’op´ erateur d’agr´ egation (ici, l’addition). Lorsque tous les coˆ uts sont positifs, que d n’instancie aucune variable et que C = ∅, le probl` eme d’estimation du prix est un probl` eme classique de minimisation de coˆ uts dans un CSP souple, r´ eput´ e NP-difficile.

Pour l’estimation du d´ elai, on peut repr´ esenter le d´ e- lai par une variable particuli` ere x t et coder les connais- sances par des conditions logiques du type c = ⇒ x t ∈ I 1 ∪ · · · ∪ I k , les I j ´ etant des intervalles (ex : x t ∈ (−∞, 8] ∪ [10, +∞)). L’estimation du d´ elai min (et du d´ elai max par ailleurs) est un probl` eme NP- difficile : lorsque d n’instancie aucune variable, et que seules des bornes inf´ erieures sont donn´ ees quant au d´ e- lai, on reconnaˆıt le probl` eme d’optimisation dans les CSP ` a priorit´ e [11] o` u il faut minimiser la priorit´ e de la plus importante des contraintes viol´ ees.

La compl´ etion de configuration est au sens d’un cri- t` ere de coˆ ut ou de d´ elai est ´ evidement un probl` eme NP-difficile. En revanche, on ne sait pas si il existe un algorithme polynomial permettant d’obtenir une so- lution ` a partir d’un probl` eme globalement coh´ erent.Si un tel algorithme existe (ce qui est peu probable), il ne proc` ede pas par r´ e´ etablissement de la coh´ erence glo- bale. Notre r´ esultat sur la coh´ erence globale incr´ emen- tale montre en effect que, sous l’hypoth` ese P 6= NP, il n’existe pas d’algorithme polynomial r´ e-´ etablissant la coh´ erence globale suite ` a l’affectation d’une variable.

Pour les probl` emes de calcul de restauration et de conflits, voir [1].

4.3 Probabilisation d’un CSP

Les probl` emes de gestion de taux ne peuvent pas ˆ

etre mod´ elis´ es de mani` ere simple sous la forme d’un CSP ou d’un CSP valu´ e, les taux n’´ etant pas ind´ epen- dants les uns des autres. Il faudrait pouvoir d´ efinir une notion de CSP probabilis´ e comme ´ etant un quadruplet P <sup>∗</sup> =< X, D, C, F >, o` u < X, D, C > est un CSP et F est un ensemble de distributions de probabilit´ es sur des sous-ensembles de X. Pour tout p ∈ F, on note vars(p) ⊆ X les variables sur lesquelles porte p.

On dira que P ^∗ est coh´ erent avec F si et seulement si il existe une distribution de probabilit´ e p ^∗ sur les affectations compl` etes de X telle que :

– d / ∈ Sols(< X, D, C >) = ⇒ p ^∗ (d) = 0 – ∀p ∈ F , d tel que vars(d) = vars(p) :

p(d) = Σ _d

∈Sols(<X,D,C>),d

| =d p ^∗ (d ⁰ )

On note Sols(P ^∗ ) l’ensemble des distributions de pro-

babilit´ e p ^∗ v´ erifiant les deux conditions ci dessus. Le

CSP probabilis´ e peut ˆ etre sur-sp´ ecifi´ e (aucune distri-

bution n’est coh´ erente avec les taux de F ) ou sous-

sp´ ecifi´ e, dans ce cas Sols(P ^∗ ) contient plusieurs p ^∗ .

La requˆ ete principale n’est pas le calcul explicite d’un p ^∗ , qui est une distribution sur un ensemble de taille exponentielle (Sols(< X, D, C >)). Dans notre application, on cherche plutˆ ot ` a connaˆıtre la probabi- lit´ e d’affectations de X , de valeurs v dans les domaines, ou plus g´ en´ eralement, d’´ ev´ enements. Pour toute condi- tion bool´ eenne c, on peut d´ efinir :

P _inf (c) = Inf _p

∈Sols(P∗) Σ _d

∈Sols(<X,D,C>),d

| =c p ^∗ (d ⁰ ) P _sup (c) = Sup _p

∈Sols(P ∗) Σ _d

∈Sols(<X,D,C>),d

| =c p ^∗ (d ⁰ ) Notons que P inf et P sup ne sont pas des mesures de probabilit´ e. Elle encadrent la mesure de probabilit´ e.

La notion de CSP probabilis´ e est bien diff´ erente des notions de CSP stochastique [14] ou probabiliste[5].

Dans ces deux formalismes (1) il existe deux types de variables, les variables de d´ ecision et les variables al´ ea- toires (dans un CSP probabilis´ e, toutes les variables sont al´ eatoires) (2) les variables al´ eatoires sont ind´ e- pendantes (il existe une unique p ^∗ et son calcul est imm´ ediat) et (3) on ne calcule pas la probabilit´ e d’une affectation mais la probabilit´ e qu’une affectation satis- fasse le CSP : plusieurs affectations peuvent avoir une probabilit´ e de 1 (dans un cSP probabilis´ e la somme des probabilit´ es des affectations est ´ egale ` a 1).

Les CSP probabilis´ es seraient une g´ en´ eralisation des r´ eseaux bay´ esiens, relachant l’hypoth` ese qu’il existe une unique distribution jointe dont les projections se- raient les distribution p ∈ F (les Tables du r´ eseau bay´ esien), et que le r´ eseau est acyclique. Par cons´ e- quent le simple calcul d’une affectation de probabilit´ e inf´ erieure maximale serait un probl` eme NP-difficile.

Sans entrer plus dans les d´ etails, disons simplement que l’analyse de la tˆ ache de gestion des taux en termes de programmation par contraintes fait apparaˆıtre le besoin d’un nouveau mod` ele qui serait une g´ en´ eralisa- tion de r´ eseaux bayesiens. L’analyse de la complexit´ e des requˆ etes associ´ ees et la d´ efinition d’algorithmes ef- ficaces sortent du cadre de cet article.

5 Conclusion

La formalisation d’un certain nombre d’applica- tions m´ etier utilisant une mod´ elisation ` a base de contraintes d’une gamme montre que la preuve de la coh´ erence d’un CSP est loin d’ˆ etre la seule requˆ ete que doivent addresser les algorithmes de programma- tion par contraintes : on rencontre notamment des pro- bl` emes d’inf´ erence, des probl` emes d’optimisation, des probl` emes de comptage et des probl` emes de margina- lisation, qui se situent souvent au dessus de NP.

Dans la plupart des cas, le CSP consid´ er´ e est notoi- rement coh´ erent, connu ` a l’avance, et commun ` a toute une s´ erie de requˆ etes. Chez Renault, l’´ equipe ”Intelli- gence Artificielle Appliqu´ ee ” en charge de ces appli- cations a choisi une approche par compilation du CSP

repr´ esentant la gamme [9], approche qui permet de r´ e- pondre en temps satisfaisant (de l’ordre du centi` eme de seconde pour la configuration en ligne, par exemple)

`

a la plupart des requˆ etes.

La question est maintenant de savoir (1) si les al- gorithmes propos´ es par la communaut´ e CSP peuvent donner des r´ esultats comparables, (2) si la commu- naut´ e peut proposer des algorithmes efficaces pour les probl` emes qui ne sont pas typiquement des probl` emes de satisfaction (par exemple, l’´ etablissement de la co- h´ erence globale, le calcul de marginalisations), et (3) comment ´ etendre le mod` ele CSP pour qu’il sache trai- ter de questions d’inf´ erence complexes - typiquement, effectuer de l’inf´ erence probabiliste.

R´ ef´ erences

[1] J. Amilhastre, H. Fargier, and P. Marquis. Consis- tency restoration and explanations in dynamic CSP - application to configuration. Artificial Intelligence, 135(1-2) :199–234, 2002.

[2] M. C. Cooper and T. Schiex. Arc consistency for soft constraints. Artificial Intelligence, 154(1-2) :199–227, 2004.

[3] Johan de Kleer. Problem solving with the atms. Ar- tificial Intelligence, 28(2) :197–224, 1986.

[4] J. L. de Siqueira N. and J-F Puget. Explanation-based generalisation of failures. In ECAI, pages 339–344, 1988.

[5] H. Fargier and J. Lang. Uncertainty in constraint sa- tisfaction problems : a probalistic approach. In ECS- QARU, pages 97–104, 1993.

[6] Alexander Felfernig, Gerhard Friedrich, Dietmar Jan- nach, and Markus Stumptner. Consistency-based diagnosis of configuration knowledge bases. Artif. In- tell., 152(2) :213–234, 2004.

[7] E. Gelle and R. Weigel. Interactive configuration using constraint satisfaction techniques. In PACT-96, pages 37–44, 1996.

[8] S. Mittal and B. Falkenhainer. Dynamic constraint satisfaction problems. In AAAI, pages 25–32, 1990.

[9] B. Pargamin. Vehicle sales configuration : the cluster tree approach. In ECAI’02 Configuration Workshop, 2002.

[10] D. Sabin and E. C. Freuder. Configuration as compo- site constraint satisfaction. In AI and Manufacturing Research Planning Workshop, pages 153–161, 1996.

[11] T. Schiex. Possibilistic constraint satisfaction pro- blems or ”how to handle soft constraints ?”. In UAI, pages 268–275, 1992.

[12] T. Schiex. Arc consistency for soft constraints. In CP, pages 411–424, 2000.

[13] T. Walsh. Sat v csp. In CP, pages 441–456, 2000.

[14] T. Walsh. Stochastic constraint programming. In

ECAI, pages 111–115, 2002.