Conception d’un environnement de simulation
intelligent

Représentation graphique des objets de la simulation : le modèle iconique

Les objets qui constituent un système physique peuvent se définir comme « un ensemble d’éléments en interaction dynamique en fonction d’un but ». La représentation de tels objets peut être vue comme une représentation physique ou mentale d’un système réel, et s’exprime en général sous forme graphique ou mathématique. Le problème qui se pose pour nous est la représentation des objets, ou des phénomènes physiques au sein de l’interface. Dans ce cadre, il s’agit de définir un modèle d’interaction entre l’utilisateur et la machine. Les modèles d’interaction les plus adaptés aux applications interactives sont fondés sur la manipulation directe. Il s’agit de représenter les objets de l’interaction, et d’utiliser des actions physiques sur ces objets (généralement à l’aide de la souris). Les effets de ces actions doivent être visibles et facilement réversibles. Ces modèles doivent aussi permettre d’interrompre une tâche pour en effectuer une autre, de mener des tâches en parallèle, ou d’effectuer une sous-tâche. Le succès d’un système à manipulation directe est fortement lié à l’analogie avec le monde réel. Le modèle d’interaction directe le plus connu est le modèle iconique, popularisé par le Macintosh (principe WYSWYG : What You See What You Get). Il se base sur la représentation des objets, tels que l’on peut les trouver sur un bureau, par des images de taille réduite appelées icônes. L’utilisateur peut manipuler ces icônes par quelques actions simples (sélectionner, effacer, déplacer, activer une commande sur les icônes sélectionnées) depuis un menu et/ou depuis le clavier. Un inconvénient des modèles iconiques est la combinatoire des opérations possibles qui augmente avec le nombre de types d’icônes disponibles, chaque type n’autorisant pas les mêmes opérations. Ce problème peut être contourné en rendant le fonctionnement intuitif grâce à l’aspect graphique des icônes (couleur, forme, indicateurs particuliers). Le modèle iconique ne devient performant que si les icônes correspondent à des objets concrets, ou reconnus de l’utilisateur. Les icônes ne suffisent pas en général à interfacer l’ensemble des fonctionnalités de l’interface. Cependant, le modèle iconique peut s’adapter à de nombreux environnements. Les fonctions classiques de l’icône sont la représentation des documents, des dossiers pour classer des documents, des applications et des volumes disques. Il nous est aussi apparu que le modèle iconique est bien adapté à la préparation des données de simulation (fichier DECK pour le code de calcul TRNSYS), notamment grâce à la manipulation d’objets de deux types : – les icônes ; – les liens entre les icônes, qui définissent les interactions entre des couples d’objets ; dans le cadre dUSIBât, cet objet sera appelé « liaison ». Les objets qui nous intéressent (bâtiment, zones, parois, équipements) sont plutôt vus par les utilisateurs des codes de simulation pour les « services » qu’ils peuvent rendre. L’utilisateur ne s’intéresse aux objets que pour constituer un réseau, le plus judicieux possible, à partir de processeurs élémentaires dont il connaît le comportement. En général, l’utilisateur n’est pas le développeur du modèle et n’a pas les compétences nécessaires pour comprendre la structure interne du modèle : cet objet lui apparaît donc comme une boîte noire. La représentation des objets sous forme de boîtes noires, Chapitre 2 : Présentation de l’interface réalisée 55 familière dans la pratique, devient alors commode à utiliser : pour un utilisateur d’un code de simulation, un objet réel est en fait une boîte qui a un certain comportement. Remarque : la structure interne des objets n’intéresse que les utilisateurs qui créent de nouveaux objets à partir d’objets existants (« Ingénieurs Concepteurs » cf. § 2-2-2). Les utilisateurs ont toujours un point de vue sur les objets , ils les considèrent à travers un filtre qui correspond à leurs préoccupations. Par exemple, l’objet « fenêtre » sera considéré par un thermicien comme une simple résistance thermique, bien plus faible que celle d’un mur. Si le thermicien a une certaine habitude des caméras infra-rouge, il pourra aussi voir l’objet « fenêtre » comme un objet déperditif rouge, par comparaison au mur froid et donc bleu. Le même objet sera vu par un spécialiste de sécurité incendie comme une masse consumable possible, qui présente dans certaines conditions données, une certaine durée de résistance au feu. Paramètres Entrées Sorties 2-6 : Représentation d’un objet sous forme d’une boîte noire La représentation des objets sous la forme de boîtes noires n’est en fait qu’un macrolangage qui permet de dialoguer, de comprendre ce que veut exprimer l’utilisateur, et de le traduire en terme de fichiers d’entrées (fichier DECK pour le code de calcul TRNSYS), et ceci quelque soit le code choisi. 

Modèle ¡conique et outils de simulation

Pour illustrer nos propos, nous nous sommes intéressés à quatre codes de calcul : – TRNSYS (Transient System Simulation Program) développé à l’université de Madison (Wisconsin) [TRNSYS 90] ; – COMIS (Conjunction of Multizone Infiltration Specialists) [COMIS 91] ; – SPARK (Simulation Problem Analysis Kernel) développé à l’université de Berkeley [NATAF-WINKELMANN 91] ; – CSTBât développé au CSTB (Centre Scientifique et Technique du Bâtiment) [LARET 1-89]. Dans le cadre de TRNSYS, la représentation des objets sous forme de boîtes noires est toute naturelle. Ces boîtes possèdent des pattes qui représentent les entrées, les sorties et les paramètres. Deux boîtes communiquent entre elles par le biais des connexions entre les variables d’entrée/sorties. L’objet9 de type « DEPERDITIONS » modélisé par la formule D = GV (Ti – Te) est représenté de la façon suivante : Il ne s’agit pas ici d’objets au sens Programmation Orientée Objets, mais de composants appartenant à une bibliothèque Chapitre 2 : Présentation de l’interface réalisée 56 Figure 2-7 : Obiet de type « DEPERDITIONS » COMIS est un code de calcul, dont les objectifs principaux à l’heure actuelle sont : – calcul des distributions de pression dans un bâtiment ; – dimensionnement des composants de ventilation dans un projet ; – détermination de la distribution des polluants ; – estimation des déperditions de chaleur dues à la ventilation et aux infiltrations d’air ; – estimation de l’efficacité du système de ventilation. La conception informatique de ce code n’est pas modulaire : il existe certes des sousprogrammes correspondants aux composants physiques modélisés (par exemple, tel sous-programme modélise un ventilateur, tel autre un système de contrôle des débits, etc), mais la structure informatique même du code fait qu’il est très difficile de le modifier, d’ajouter ou de supprimer des sous-programmes ; cela est dû à l’option initiale choisie par les développeurs : elle consiste à déclarer des liaisons entre sous-programmes au sein même du code ; de ce fait, un module « COMIS » ne possède ni entrées, ni sorties connectables ; il possède par contre des paramètres, et des variables internes qui peuvent être déclarées comme sorties pour l’affichage des résultats. C’est là une limitation du logiciel, il est très difficile de personnaliser la bibliothèque des modèles « COMIS » par adjonction de nouveaux modèles sauf à parfaitement connaître la structure informatique interne du code Fortran. Cependant, du point de vue du développeur de projets ou de l’analyste, une telle structure offre des avantages au sens où, lorsqu’on réalise un assemblage, il n’est nul besoin de spécifier les connexions internes aux liaisons entre composants. Rappelons qu’avec TRNSYS, un de nos objectifs futurs est de développer une fonction qui permette la connexion automatique entre variables pour précisément affranchir l’utilisateur de cette tâche de définition dés connexions entre entrées et sorties. Une telle fonction, surtout si on la veut générique, est difficile à développer, mais une fois réalisée, les performances de l’interface avec TRNSYS deviennent égales à ce qu’elles sont avec COMIS (puisqu’alors, dans un cas comme dans l’autre, U suffit de positionner les composants et de déclarer les liaisons entre composants, les connexions internes étant, dans le cas de TRNSYS, réalisées par la fonction « connexion automatique » et, dans le cas de COMIS, les connexions étant déclarées de façon interne au programme), mais, avec la structure de TRNSYS, on conserve la modularité nécessaire à l’extension aisée des bibliothèques de modèles. Cependant, il faut noter qu’avec TRNSYS et la fonction « connexions automatiques », un certain travail peut être nécessaire lors de l’implémentation d’un nouveau composant pour enrichir la base de connaissances qui permet à la fonction « connexion automatique » d’effectuer les liaisons adéquates (cf. § 3-2-3). Quoi qu’il en soit, pour l’utilisateur terminal, c’est à dire pour le créateur de projets ou pour l’analyste, l’incorporation de COMIS au sein d’un Environnement de Simulation Intelligent comme IISIBât, lui donne l’illusion de la modularité et de l’aspect « orienté objets » du code, en ce sens qu’il manipule à l’écran des icônes représentant des objets Chapitre 2 : Présentation de l’interface réalisée 57 physiques indépendants ; mais il ne s’agit là que d’une apparence puisque derrière, les sous-programmes Fortran sur lesquels pointent ces « objets » sont étroitement dépendants les uns des autres. Paramètres Zone 1 Paramètre« Paramètres Infiltration 5 Zone 2 Figure 2-8: Boîte noire COMIS SPARK est un solveur numérique associé à une bibliothèque de modèles. Un objet SPARK est représenté par un ensemble d’équations, qui font intervenir toutes les variables utilisées : ainsi toute variable peut être soit une variable de sortie, soit une variable d’entrée, selon le cas. Soit l’équation suivante D – GV (Ti – Te) = 0. L’objet SPARK qui en découle est caractérisé par les quatres équations suivantes : f D = GV(Ti-Te) GV- D o v (Ti-Te) TÍ=TÍ?7 + Te « GV Te = Ti D GV Cet objet SPARK peut être représenté par une boîte noire (figure 2-9), possédant quatre pattes, chacune d’entre elles représente une variable pouvant être calculée en fonction des trois autres. Les boîtes communiquent par le biais de connexions entre les variables. Il n’y a pas , a priori, de variables d’entrée/sortie ; c’est le contexte de la simulation (exprimé en termes de données disponibles et d’objectifs) qui fournira les paramètres, les entrées et les sorties. Figure 2-9 : Boîte noire SPARK Remarque : l’objet TRNSYS, modélisé par la formule D « GV (Ti – Te) est un objet SPARK spécifique, orienté conception. L’objet TRNSYS, modélisé par la formule GV = D / (Ti – Te) est un objet SPARK spécifique, orienté audit (figure 2-10). Chapitre 2 : Présentation de l’interface réalisée 58 GY Figure 2-10 : Boîte noire SPARK orientée AUDIT CSTBât utilise la structure informatique du logiciel de simulation TRNSYS. Il s’articule autour de la modélisation analogique du bâtiment. Là aussi, tous les objets ou phénomènes physiques peuvent être représentés par des boîtes noires. Les boîtes noires rapportées au modèle de bâtiment (type 50 [LARET 1-89]) ne sont pas sur le même plan que les précédentes ; elles représentent en fait un réseau de conductances et de capacités. L’utilisateur peut vouloir affiner sa modélisation (ajouter des ponts thermiques par exemple) ; il devra alors manipuler des objets tels que des capacités, des conductances, des générateurs de courant (cf. § 1-5-1-2). De plus, une interface experte devra proposer des aides pour la discrétisation de l’espace modélisé et pour le calcul des valeurs des conductances.

Définition d’un objet « icône »

La représentation des objets sous forme de boîtes noires reliées entre elles peut être généralisée à un grand nombre de codes de calcul. Elle donne à l’utilisateur la possibilité de structurer sa réflexion à propos d’une modélisation d’un système physique, tout en lui assurant une liberté d’action, du fait de l’aspect modulaire de l’approche. Les objets graphiques (boîtes noires -icônes- et liaisons) manipulées au sein de l’interface n’ont pas la même signification selon le code de simulation choisi (pour TRNSYS, l’icône est orientée, elle pointe sur des sous-programmes indépendants ; pour COMIS, l’icône ne possède ni entrées ni sorties, elle pointe sur des sous-programmes dépendants ; pour SPARK, l’icône, au niveau le plus générique de SPARK, ne possède que des variables, elle pointe sur des « objets SPARK » indépendants). L’idée est de trouver un moyen pour représenter ce qu’est une icône de la façon la plus générale possible, de telle sorte qu’il soit facile d’adapter cette forme aux spécificités de différents codes de simulation. Pour ce faire, l’approche orientée objets présente tous les avantages nécessaires : elle permet de créer un objet générique qui par spécification peut facilement permettre de créer des icônes bien adaptées à la manipulation des composants technologiques modélisés par le code considéré. Les icônes ainsi créées, du fait de l’utilisation d’une technique de programmation orientée objets, hériteront de toutes les caractéristiques et méthodes attachées à l’objet générique « icône » ; ainsi, lors de l’incorporation dans l’environnement de simulation intelligent, d’un nouveau code de calcul, il ne sera pas nécessaire de redéfinir une icône par une fonction nouvelle et spécifique, mais il suffira de spécifier l’icône générique existante, au niveau abstrait, au sein de cet environnement ; ainsi le travail du développeur de l’environnement de simulation s’en trouvera grandement facilité. Par ailleurs, cette technique assure une certaine cohérence d’aspect et de comportement entre les différentes représentations des objets modélisés par les différents codes de calcul, puisque ces représentations dérivent d’un objet unique ; cette cohérence d’aspect facilite la prise en mam des logiciels par les utilisateurs terminaux.