Élaboration et exploitation d’un modèle pendant la phase de conception architecturale

Télécharger le fichier pdf d’un mémoire de fin d’études

La conception préliminaire

La conception préliminaire est une phase du processus de conception (voir figure 1), qui se situe dans les premières phases du cycle de vie d’un produit industriel [Pah96]. Le cycle de vie d’un produit correspond aux différentes étapes que rencontre un produit : expression d’un besoin fonctionnel, conception préliminaire, conception détaillée, réalisation/conformité, vente et fin de vie. Le cahier des charges fonctionnel (CdCF) traduit le besoin fonctionnel et sert de base à la conception préliminaire, qui vise alors à définir l’architecture globale qui sera détaillée par la suite. Le processus de conception est achevé lorsque le dossier de définition du produit est établi en fin de conception détaillée. Il décrit exhaustivement toutes les caractéristiques et les performances du produit. Ensuite des prototypes du produit sont réalisés et leur conformité (au besoin initial, aux normes, etc.) est validée, avant de passer à sa phase d’utilisation par le client et, pour finir sa fin de vie (recyclage, etc.) qui termine le cycle de vie du produit.
Assez peu d’outils de traitement numérique des modèles de dimensionnement et de validation des concepts, aident le concepteur dans les phases amonts du processus de conception [Yan03]. Pourtant ces phases préliminaires sont primordiales d’un point de vue économique et stratégique dans le développement d’un produit. La conception de produit vise à satisfaire autant que possible les objectifs définis dans le cahier des charges. Il est souvent difficile de remplir tous ces objectifs et des compromis sont nécessaires.

Le processus de conception d’un système mécanique

Le processus de conception est jalonné de plusieurs phases [Pah96] que l’on peut généralement séquencer ainsi (voir figure 1) : expression du besoin, recherche de concepts, conception architecturale (pré-dimensionnement : choix d’architecture, de structure et de topologie du produit), conception détaillée. Résoudre un problème de conception peut alors être considéré comme [Jan90,Sca04a] : partir des spécifications fonctionnelles d’un produit et en construire une représentation respectant :
– des lois physiques,
– des données impératives provenant de la phase de réalisation ou de fabrication du produit : matériaux ou ressources disponibles par exemple, limitations de coûts, de temps, etc.,
– la prise en compte de critères portant sur le produit (robustesse, coût, simplicité) ou sur sa réalisation (coût de fabrication, gestes métiers, etc.).

La phase de recherche de concepts

Elle est basée sur l’exploration de concepts ou principes permettant de répondre aux besoins fonctionnels énoncés dans le cahier des charges fonctionnel. Des méthodes liées à la créativité peuvent être utilisées pour trouver des concepts innovants satisfaisant les besoins fonctionnels. Elle aboutit donc à une structure fonctionnelle répondant au besoin identifié, définissant alors un principe de solution.

La phase de conception architecturale

L’enjeu de cette phase est d’orienter, le plus tôt possible, la conception vers les meilleurs concepts de solution en étudiant leur faisabilité (physique, économique, etc.) [Yao97]. Les connaissances rassemblées lors de la phase de recherche de concepts sont alors synthétisées dans des modèles permettant d’évaluer la viabilité des architectures possibles. Lors de cette synthèse, apparaissent des formes, des arrangements de composants, des matériaux, etc. Les modèles ainsi définis sont souvent hétérogènes et peuvent s’avérer complexes à traiter, mais ils doivent tenir compte de l’imprécision et des incertitudes existant à ce stade peu avancé de la conception. Ainsi, la phase de conception architecturale vise à réaliser des choix : de technologies, de dimensions principales (grandes dimensions, dimensions de caractéristiques clés : key characteristics [Tho99]), de principaux composants, de structure (par exemple : nombre d’étages, agencements) et de topologies (liaisons entre composants, sens et direction des flux). Ces choix aboutissent à une architecture produit principale ou une configuration optimale (du point de vue du modèle traité) par rapport aux critères définis dans le cahier des charges fonctionnel.

Aide à la décision en conception architecturale

La diversité, voire l’hétérogénéité de la connaissance à synthétiser pendant la phase de conception architecturale rend cette phase difficile à aborder. Le concepteur est souvent confronté au début de la conception préliminaire à une difficulté de recensement des connaissances nécessaires et suffisantes pour réaliser cette phase. De plus, il doit prendre à plusieurs reprises des décisions a priori dans un contexte de connaissances imprécises. Pour réduire l’ambiguïté et l’incertitude dans les premières phases du processus de conception, il faut aider le concepteur à écrire un modèle approprié au problème de conception, afin d’aider ensuite à la prise de décision [Sca04b, Ver04]. L’aide à la décision en conception architecturale passe alors par l’utilisation d’outils ou de méthodologies aidant le concepteur à formaliser la connaissance relative à un produit, tout en évaluant cette connaissance, pour estimer les risques encourus et ainsi prendre de « bonnes » décisions.
La hiérarchisation des connaissances est alors primordiale pour ne considérer que les informations pertinentes à ce stade peu avancé de la conception d’un produit [Sca04a]. Cela permet de prendre en compte un maximum d’informations utiles sur le produit sans surcharger les modèles inutilement. La qualité des résultats obtenus est alors améliorée aussi bien du point de vue des performances de résolution que des solutions elles-mêmes. La hiérarchisation des connaissances liées au produit permet ainsi de trier les critères selon leur pertinence, ce qui permet d’aider le concepteur à mieux évaluer les architectures mises en évidence par le processus de résolution. Cependant, l’optimisation de la solution retenue ne se fait généralement pas lors de la résolution, mais à posteriori. En effet, les critères de validité d’une solution peuvent évoluer durant le processus de conception et le contexte précoce de la conception préliminaire induit un certain nombre d’incertitudes sur le produit et ses composants. Il est alors plus facile pour le concepteur de considérer un ensemble de solutions, qu’il peut trier suivant les critères qu’il considère à un moment donné. Il faut bien prendre en compte le fait qu’un modèle au sens mathématique du terme ne traduit qu’une partie des connaissances d’un concepteur. « L’optimisation » est alors réalisée à posteriori en prenant en compte des connaissances n’ayant pas été formalisées.
Tout au long du processus de conception, les concepteurs et/ou les décideurs sont amenés à prendre des décisions stratégiques par rapport à un produit. Ces décisions sont soumises à l’appréciation des risques (à tout niveau) encourus. Le risque de conception correspond au fait que le produit conçu ne réponde pas à l’ensemble des exigences. Ces exigences peuvent être très diverses suivant les contextes :
– Spécifications du produit : les directives du cahier des charges ne correspondent pas aux attentes du client.
– Marché : le produit arrive trop tard, les coûts objectifs sont dépassés, le produit ne correspond pas aux critères du marché.
– Technique : (1) la conception proposée ne respecte pas les spécifications, (2) non-compatibilité des interfaces [Cav95], (3) degré de complexité élevé.
– Délais : remise en cause des décisions, reconception.
– Financier.
– Ressources : les ressources de développement ne sont pas disponibles.
– Risque environnemental : le produit, ses composants, les procédés affectent l’environnement. Les « risques produit » sont principalement supportés par l’utilisateur final durant la phase d’utilisation du produit. Les « risques programme » sont surtout associés aux dérives des objectifs de performances, de coût, de délai [Cav95]. Les risques encourus peuvent être estimés tout au long du processus de conception en se basant sur les modèles établis à chaque étape, en considérant l’apport qu’ils fournissent pour aider à la prise de décision.

Modèle en conception architecturale

Durant les premières phases du processus de conception, les données sont imprécises, et il est difficile d’utiliser des outils informatiques permettant de faire des calculs exacts et précis [Ant01]. Les méthodes assistées par ordinateur comme la modélisation solide, l’optimisation, l’analyse de mécanisme, etc., demandent toute une représentation très précise des objets. Dans le cadre de la conception préliminaire, les concepteurs doivent alors faire beaucoup d’hypothèses [Cha92] et restreignent le champ de leurs investigations.
Les outils d’analyse conventionnels ne sont pas adaptés pour étudier une solution de conception incomplète [Saw01]. Ainsi, les concepteurs doivent souvent adopter une démarche empirique du type « essai-erreur » afin de déterminer les valeurs des paramètres de conception. Ils se limitent alors souvent à évaluer les performances d’une solution souvent arbitrairement valuée. Peu d’outils et méthodes s’orientent vers la synthèse automatique ou semi-automatique de concepts [Yan01]. Pendant le stade de la conception préliminaire, des décisions importantes sont prises par les concepteurs/décideurs alors que tous les éléments, permettant de faire des choix raisonnés, ne sont pas accessibles. Des outils de validation de la conception existent pour des phases plus avancées, lorsque la définition du produit est plus complète. La définition d’un modèle permettant de prendre de telles décisions est alors déterminant pour limiter les risques de mauvaise conception.
Les modèles utilisés synthétisent la connaissance sur le produit à chaque étape du processus de conception. Cependant, ces modèles ne peuvent représenter parfaitement le monde réel et le produit (qui d’ailleurs n’existe pas encore) [Pow05]. C’est précisément la particularité d’un modèle. Les modèles sont définis pour représenter des concepts réels ou abstraits. Des simulations ou des expérimentations permettent de les valider si nécessaire. Ils sont utiles lorsqu’un système n’existe pas, quand des expérimentations ne sont pas possibles ou trop coûteuses. L’utilisation des modèles en conception est importante et permet d’aider le concepteur à prendre des décisions. En effet, un concepteur définit des modèles pour répondre à ses besoins décisionnels, les modèles permettant de prédire le comportement d’un produit, son coût, etc. Par la suite, nous considèrerons la définition suivante pour la notion de modèle :
Définition (modèle) : Un modèle est une abstraction du monde réel ou d’un concept abstrait, qui tient compte d’un nombre fini d’informations. Ce nombre limité d’informations implique de faire des hypothèses simplificatrices quant à la description du sujet du modèle. Il est alors intrinsèquement relié à des niveaux d’exactitude et de précision. Un modèle est défini dans un but précis, qui détermine les compromis à effectuer entre la capacité d’un modèle à produire une aide à la décision et son intelligibilité.
L’intelligibilité d’un modèle correspond au fait qu’il soit à la fois expressif et compréhensible pour un concepteur, aussi bien pour chacun de ses éléments le composant, que dans sa globalité. Nous utilisons alors les définitions suivantes pour les termes introduits ici :
Définition (expressivité) : On parle d’expressivité à propos de variables ou de tout ce qui est associé à une valeur dans un modèle. Une valeur est expressive, si la quantité associée à cette valeur est riche d’informations pour le concepteur.
Définition (compréhensibilité) : On parle de compréhensibilité à propos des relations exprimées dans un modèle. Un modèle est compréhensible pour un concepteur, s’il peut s’approprier ces relations et les faire évoluer, les modifier ou les éliminer. La compréhensibilité concerne aussi les ensembles de relations structurées ou agencées que le concepteur doit pouvoir transformer, modifier ou éliminer.
Il est alors important d’évaluer la qualité d’un modèle par rapport au produit ou à la réalité qu’il représente, ainsi que par rapport aux besoins décisionnels auxquels il doit répondre. La qualification décisionnelle d’un modèle permet d’estimer dans quelle mesure il permet de prendre des décisions en accord avec ses besoins et un contexte décisionnel. Lorsque l’adéquation n’est pas suffisante, le concepteur peut adapter son modèle et limiter autant que possible les risques liés aux décisions à prendre. Ainsi, l’évaluation de l’état décisionnel d’un modèle peut aider le concepteur à gérer les risques qu’il encourt en fonction des décisions qu’il prend et de la connaissance qu’il représente et maîtrise.
La partie issue du cahier des charges est plus facile à définir, car elle se base sur les phases précédentes du processus de conception et sur l’expérience qu’a le concepteur du cycle de vie complet du produit. Les éléments qui la composent sont généralement peu concernés par la phase d’adaptation de modèle. Par contre, la description du comportement du produit est souvent délicate à établir. Le concepteur doit prendre en compte des modèles décrivant les composants, les phénomènes physiques identifiés, etc. Le concepteur est alors obligé de synthétiser la connaissance pour la définir de manière cohérente dans un modèle global. En effet, la description du comportement du produit ne doit pas être comparable aux simulations menées pendant la phase de conception détaillée. Les incertitudes sur le produit et le temps nécessaire pour établir et résoudre de tels modèles ne sont pas adaptés à la phase de conception architecturale.
La figure 4 illustre la complexité de la phase de conception préliminaire, avec à la fois les choix que doit faire le concepteur au niveau des concepts de fonctionnement, mais aussi lors de la modélisation d’un même concept. Les choix du concepteur ne s’arrêtent pas là, puisqu’il doit ensuite choisir une architecture parmi les solutions obtenues. Dans l’idéal, il faudrait étudier chaque alternative de concepts de fonctionnement, ainsi que chaque alternative de modélisation, mais dans un contexte industriel, le concepteur n’a pas le temps. Il fait alors des choix à priori, basés sur sa propre expérience et sur les besoins décisionnels liés au modèle qu’il doit définir. Pour le choix d’une alternative de dimensionnement ou d’une architecture, le concepteur peut s’aider de méthodes permettant de trier et de discriminer les solutions les unes par rapport aux autres, par rapport aux critères du cahier des charges et à une analyse de robustesse [Sca04a].

La programmation par contraintes

La programmation par contraintes est un paradigme expressif et puissant qui permet de représenter, résoudre et raisonner sur de nombreux problèmes complexes. Elle est généralement basée sur l’utilisation du formalisme des problèmes de satisfaction de contraintes (CSP) pour énoncer des problèmes. Elle regroupe l’ensemble des techniques liées à la résolution/satisfaction d’un ensemble de contraintes. Un CSP est traité à l’aide d’un solveur qui calcule un ensemble de solutions, qui explore l’espace de recherche défini par les domaines de variables, tout en s’assurant que les contraintes formulées restent cohérentes.
Les premiers travaux portant sur des techniques de satisfaction de contraintes ont principalement été amenés par le domaine de l’infographie [Mon74, Wal75]. Le concept de contrainte est une notion omniprésente dans notre environnement, une contrainte définissant une restriction sur un ou plusieurs éléments (abstraits ou concrets). Une contrainte peut définir une relation entre deux points d’une figure géométrique, si nous restons dans le domaine de l’infographie, mais elle peut tout aussi bien exprimer une limite de coût pour un produit, la déformation d’un objet suite à l’application d’un effort, etc. On peut définir une contrainte dès qu’il s’agit de restreindre un degré de liberté lié à l’évolution d’une variable caractéristique d’un objet. La difficulté est alors de pouvoir exprimer les restrictions relatives à un sujet d’étude de manière à utiliser efficacement un solveur générique de CSP, comme lors de la description d’un produit et de toutes les contraintes à prendre en compte pour étudier sa faisabilité. La généricité du paradigme des CSP permet de définir un cadre général pour la formalisation des problèmes. Ils sont décrits par des contraintes, qui s’appliquent à des variables associées à un domaine, qui représente l’ensemble de valeurs possible d’un domaine de calcul.
Définition (Contrainte) : Une contrainte c s’applique à un ensemble de variables x1,…,xk, noté var(c), associé à leurs domaines respectifs d1,…,dk. La contrainte c est alors égale à un sous-ensemble du produit cartésien des domaines des variables : c(x1,…,xk)⊆ d1 £ ¢ ¢ ¢ £ dk.
Une contrainte peut être définie en extension (tous les tuples ou l’ensemble des valeurs autorisées), ou en intention (expression synthétique de la restriction sur les domaines des variables). C’est en général cette dernière approche qui est utilisée, en particulier pour les problèmes de grande taille, car elle permet d’exprimer un problème de manière plus concise en décrivant uniquement les variables, les domaines et les relations existantes entre les variables d’un problème. C’est aussi cette approche qui est utilisée pour décrire des CSP numériques, car il n’est pas possible d’énumérer toutes les combinaisons de valeurs possibles pour des intervalles sur les nombres réels.
Définition (CSP) : Un problème de satisfaction de contraintes (CSP) est constitué de trois entités :
– Un ensemble de variables : X={x1,…,xn},
– Un ensemble de domaines associés aux variables : D={d1,…,dn}.
– Un ensemble de contraintes décrivant les restrictions appliquées aux domaines des variables : C={c1,…,cm},
Initialement, le paradigme des CSP est basé sur des domaines discrets (ensembles finis de valeurs, par exemple : dimensions normalisées, identifiant de composants à choisir, etc.). Ils correspondent aux valeurs qu’il est possible d’affecter aux variables. Cependant d’autres types de domaines peuvent être considérés pour représenter des problèmes réels, comme des domaines continus représentés par des intervalles (par exemple : dimensions, grandeurs physiques, etc.). Les CSP basés sur des domaines continus sont généralement appelés CSP numériques. En conception architecturale, ces deux types de domaines sont utilisés et dissocient généralement des variables issues du cahier des charges (domaine discret) et des variables spécifiques à la description du comportement physique du produit. Les domaines discrets sont alors principalement utilisés pour décrire des identifiants de composants à choisir, des dimensions ou grandeurs issues de catalogues, etc. alors que les domaines continus sont plus appropriés pour la description de dimensions, de variables d’état liées à des grandeurs physiques (pressions, températures, etc.). Lorsque plusieurs types de domaines sont utilisés conjointement dans un CSP, on parle de CSP mixte. Le traitement d’un problème mixte est encore difficile au vu des techniques actuelles [Gel03]. Par la suite, les variables discrètes, présentes dans les problèmes de conception, seront traitées comme des variables continues raffinées au fur et à mesure à l’aide des valeurs discrètes de leur domaine initial.
Une contrainte est considérée comme satisfaite par des domaines de variables, lorsque ces domaines sont cohérents avec la restriction définie par la contrainte. D’un point de vue ensembliste, le produit cartésien des k domaines de variables est inclus dans l’image de la relation ρc représentant une contrainte c : d1 £ ¢ ¢ ¢ £ dk ⊆ ρc(x1,…,xk).
On note alors c(d1,…,dk) le fait que c est satisfaite par les domaines des variables et ¬c(d1,…,dk) dans le cas contraire. Une solution d’un CSP est représentée par un tuple de valeurs associées aux variables, telles que toutes les contraintes d’un problème sont satisfaites. Lorsqu’un problème ne dispose pas de solution, il est qualifié d’inconsistant.
Un CSP peut être considéré comme une expression logique correspondant à une conjonction de toutes les contraintes de l’ensemble C. Les contraintes peuvent alors être vues comme des prédicats, ce qui permet, dans certains cas, de traiter des problèmes de satisfiabilité de formules logiques [Ben04, Mar06].
Deux CSP sont dits équivalents s’ils ont le même ensemble de solutions (et donc le même ensemble de variables) : Sol(CSP1) = Sol(CSP2) → CSP1 ≡ CSP2.
Cette équivalence entre problèmes est la base de la phase de propagation de contraintes qui permet, quand elle est complète, de remplacer un problème initial par un problème équivalent de plus petite taille.
La résolution d’un CSP fait généralement appel à deux types d’algorithmes : les algorithmes de propagation basés sur des opérateurs de réduction et des algorithmes de recherche. Ces deux types d’algorithmes sont suffisamment génériques pour s’appliquer à tout type de problèmes, à partir du moment où ils respectent le formalisme des CSP. Dans le cadre des CSP numériques, la résolution complète d’un problème est assurée par des techniques de recherche exhaustive, qui calcule un ensemble de solutions définies comme des produits cartésiens d’intervalles, appelés boîtes. La phase de recherche est accélérée à l’aide d’algorithmes de propagation de contraintes. La combinaison des techniques de consistances locales à une arithmétique des intervalles rigoureuse permet alors de fournir un encadrement, à une précision fixée, de l’ensemble des solutions [Ben94].

Les principes de base sur les CSP numériques

Les CSP numériques sont basés sur des contraintes exprimées en intention comme des relations sur des variables définies sur les nombres réels. Le traitement des domaines continus peut se faire suivant deux approches [Ben06] : une discrétisation des domaines continus sur l’ensemble des nombres flottants suivi de calculs algébriques ou une approche basé sur du calcul ensembliste. C’est cette approche que nous développerons par la suite. Elle fait appel à l’analyse par intervalles et à l’algorithmique qui en découle [Moo66]. Cependant, les domaines continus sont représentés par des intervalles dont les bornes sont des nombres réels, ce qui pose de nombreux problèmes quant à leur représentation informatique et leur utilisation dans les calculs [Ric68, Wan74]. Les nombres réels ne peuvent être tous définis à l’aide d’une représentation basée sur un nombre fini de bits en mémoire. La principale conséquence de cette représentation est l’erreur d’arrondi. A partir de là, le but principal des techniques basées sur les intervalles est de résoudre des problèmes définis comme des relaxations de problèmes continus. Un autre problème important est de prouver l’existence de solutions dans une boîte intervalle, pour garantir les solutions calculées.

Les erreurs d’arrondis

Les intervalles définissant les domaines continus sont bornés par des nombres réels. Ces derniers ne sont pas tous représentables en mémoire, car ils respectent la norme IEEE754 [IEEE754]. Les nombres définis par cette norme sont calculés à l’aide d’un bit de signe, d’une mantisse et d’un exposant: f = (¡1)s ¢ m ¢ 2E.
Ces nombres sont appelés nombres flottants. L’ensemble des nombres flottants est noté F et est inclus dans l’ensemble des nombres réels R. Lors des calculs, les nombres réels sont arrondis aux nombres flottants les plus proches, ce qui provoque des erreurs de calculs plus ou moins importantes suivant les valeurs et les opérations considérées.
Prenons l’exemple de la fonction de Rump [Rum88] : f (x, y) = 333.75y6 + x2(11×2 y2 − y6 − 121y4 − 2) + 5.5y8 + x/(2y). A l’aide de l’outil MuPad 2.5.3 sur un processeur Intel Pentium M, nous obtenons les résultats suivants pour l’évaluation de f(77617, 33096) décrit dans la table 1.
La valeur de f(77617; 33096) est -54767/66192, soit environ -0,8273960599. D’après les résultats de ce tableau, nous voyons clairement les écarts (parfois énormes) avec la solution réelle, qui peuvent avoir lieu à cause des erreurs d’arrondis.

Table des matières

CHAPITRE I – Introduction générale
I.1 – Positionnement de la thèse
I.2 – Contexte de la thèse et travaux précédents
I.2.1 – Projet RNTL CO2
I.2.2 – Outils et travaux existants autour de la conception par contraintes
I.3 – Organisation du document
CHAPITRE II – État de l’art
II.1 – La conception préliminaire
II.1.1 – Le processus de conception d’un système mécanique
II.1.2 – La phase de recherche de concepts
II.1.3 – La phase de conception architecturale
II.1.3.1 – Aide à la décision en conception architecturale
II.1.3.2 – Modèle en conception architecturale
II.2 – La programmation par contraintes
II.2.1 – Les principes de base sur les domaines continus
II.2.1.1 – Les erreurs d’arrondis
II.2.1.2 – Le calcul par intervalles
II.2.2 – La propagation de contraintes
II.2.2.1 – Les techniques de consistance locale
II.2.3 – Les algorithmes de recherche
II.2.3.1 – Les heuristiques de recherche
II.2.3.2 – L’exploration des domaines des variables
CHAPITRE III – Élaboration et exploitation d’un modèle pendant la phase de conception architecturale
III.1 – Introduction
III.1.1 – Objectifs et contexte de ce type de modèle
III.2 Modélisation et aide à la décision en conception architecturale
III.2.1 – Adaptation de modèles
III.3 – Connaissance formalisée pendant la phase de recherche de concepts
III.3.1 – Connaissance formalisée à l’aide du cahier des charges fonctionnel
III.4 – Connaissance formalisée pendant la phase de conception architecturale
III.5 – Exploitation du modèle et des solutions
III.6 – Pourquoi utiliser le paradigme des CSP?
III.7 – Points importants pour la réalisation d’un outil d’aide à la décision en conception architecturale
III.7.1 – Types des variables en conception
III.7.2 – Importance des variables de conception architecturale
III.7.3 – Variable explicite ou alias
III.7.4 – Précision des variables
III.7.5 – Représentation des phénomènes physiques
III.7.6 – Gestion des situations de vie
III.8 – Bilan
CHAPITRE IV – Concepts et apports en programmation par contraintes
IV.1 – Etude de l’existant
IV.2 – Nouveaux concepts
IV.2.1 – Gestion de la précision
IV.2.2 – Heuristiques de recherche
IV.2.2.1 – Variables de conception
IV.2.2.2 – Solution de conception
IV.2.2.3 – Apprentissage de la sensibilité
IV.2.3 – Contraintes par morceaux
IV.3 – Benchmarking
IV.4 – Bilan
CHAPITRE V – Étude de problèmes de conception
V.1 – Introduction
V.2 Problèmes de conception
V.1.1 – Circuit d’une pompe et de réservoirs
V.2.2 – Système de refroidissement d’apéritif
V.2.3 – Système de conditionnement d’air sans ailette
V.2.4 – Système de conditionnement d’air avec ailettes
V.3 – Analyse des performances de résolution
V.3.1 – Gestion de la précision des variables auxiliaires
V.3.2 – Analyse du ratio de l’heuristique sur les variables de conception
V.3.3 – Comparaison globale des performances des heuristiques de recherche
V.4 – Bilan
CHAPITRE VI – Conclusion et perspectives
VI.1 – Contribution apportée
VI.2 – Perspectives et futures évolutions
Références bibliographiques

Télécharger le rapport complet