osiris : une architecture multi-agent de couplage de processus ...

3 e Conférence Francophone de MOdélisation et SIMulation «Conception, Analyse et Gestion des Systèmes Industriels »MOSIM’01 – du 25 au 27 avril 2001 – Troyes (France)OSIRIS : UNE ARCHITECTURE MULTI-AGENT DE COUPLAGE DEPROCESSUS PHYSIQUES POUR SIMULER LE FONCTIONNEMENTHYDRO-SALIN D’UNE RÉGION IRRIGUÉEEdem Fianyo, Jean-Pierre TreuilIRD - UR GEODES32, avenue Henri Varagnat,93143 Bondy cedexMél :{fianyo, treuil}@bondy.ird.frYves DemazeauLab. LEIBNIZ – Institut IMAG46, avenue Felix Viallet,38000 GrenobleMél : Yves.Demazeau@imag.frSuzanne PinsonUniversité Paris IX – DauphineLAMSADEPl. du Mal de Lattre de TassignyMél : pinson@lamsade.dauphine.frRÉSUMÉ : Le système OSIRIS (Outil de Simulation et d'Intégration de processus physiques pour l'étude d'une RégionIrriguée du Sénégal) a pour objectif de permettre le couplage dynamique de modèles conçus indépendamment. Lecontexte d'application de ce travail est la modélisation de l'évolution saline d'une région irriguée (région du Ngalenkaau Nord - Sénégal) par l'intégration des modèles des processus physiques qui entrent en jeu dans le phénomène desalinisation (irrigation, infiltration, percolation, évapotranspiration, etc.). L'idée mise en œuvre consiste à proposerune démarche de couplage permettant à l'utilisateur d'un tel outil la construction d'une vision spécifique de son mondesur laquelle il peut greffer les différents modèles. L'intégration se fait sur deux points : une synchronisation temporelleentre processus est réalisée par l'utilisation de contrôleurs de temps ; l'interface entre les paramètres des modèles deprocessus et les entités représentant la vision du monde simulé, est réalisée par l'utilisation de fonctions decorrespondance. Il est possible de définir pour chaque processus des règles de contrôle. Ces règles vont être vérifiéesdynamiquement au cours de la simulation par des agents de contrôle qui ont également pour rôle d'adapter au contextecourant le comportement du modèle de processus auquel chacun est associé.MOTS-CLÉS : système multi-agent, simulation, couplage de modèles.1. INTRODUCTIONLe couplage de modèles est une démarche qui est souventenvisagée lorsque l'on se trouve confronté à une questioncomplexe ou globale qui a fait l'objet de plusieursréponses partielles que l'on souhaite rassembler. C'est lecas de nombreux problèmes posés en écologie (prévisionclimatique, étude de pollution, etc.). Une démarche decouplage se fait classiquement de deux façons. Lapremière méthode consiste à construire un super modèledans lequel on va fondre les modèles de départ, modifiésau besoin pour éviter d'éventuelles incompatibilités etplus généralement pour résoudre le problème de lacorrespondance entre données manipulées. On parle dansce cas de couplage fort (Pouliot, 1999). La secondeméthode (on parle alors de couplage faible), consiste àcréer un outil d'interface qui va dialoguer avec chacun desmodèles et qui va se charger de tout le travail decorrespondance entre données et entre traitements. Unetelle forme de couplage présente l'avantage de laisserintacts les modèles de départ, dont l'architecture internen'a pas à être connue, et dont l'utilisation a déjà étévalidée auparavant. Les modèles de départ peuvent parailleurs ne pas être obligatoirement développés sur lamême plate-forme. Dans notre problématique, lesmodèles que l'on veut assembler ont été développés defaçon indépendante par des spécialistes provenant dedisciplines différentes. De plus on souhaite disposer d'unoutil d'interface assez souple permettant l'ajout ultérieurde modèles non prévus au départ. Pour satisfaire lescontraintes de ce problème, nous proposons unearchitecture multi-agent de couplage de modèles.2. CONTEXTE D'APPLICATIONLe point de départ de ce travail concerne l'étude de lasalinité dans une région irriguée du Nord-Sénégal. Lapratique de l'irrigation, employée dans la plupart despays sahéliens où les conditions écologiques(irrégularités des pluies) sont instables, présente desrisques pour le milieu. On constate notamment desdégradations salines (accumulation de sels solubles) etalcalines (accumulation de bases faibles) qui peuventconduire à rendre le sol complètement inexploitable pourles cultures. De nombreuses études ont été menées sur cesujet. Mais elles ont généralement été conduites selon unpoint de vue spécifique (pédologique, hydrologique,agronomique) et ont souvent abouti à une appréhensionpartielle du risque de salinisation et parfois à une sousestimationde ce risque (Boivin, 1997). Un processus desalinisation fait en effet intervenir différents processusphysiques tels qu'on peut les schématiser sur la figure 1,chacun de ces processus physique relevant d'un domaineparticulier : l'agronome s'intéresse à la modélisation del'évapotranspiration des plantes alors que la percolationrelève du domaine d'intérêt de l'hydrologue. La mise enroute d'un nouveau projet d'irrigation dans le secteurNgalenka amont (département de Podor, au nord duSénégal) a relancé l'intérêt d'une mise en commun detoutes les connaissances acquises sur les processusphysiques qui entrent en jeu dans un phénomène desalinisation.

MOSIM’01 – du 25 au 27 avril 2001 – Troyes (France)IrrigationEvapo-transpirationImbibitionPercolationNAPPEPluieDrainageFigure 1. Processus physiques influençant le phénomènede salinisation3. COUPLER DES MODÈLES POUR MIEUXÉTUDIER L’ENVIRONNEMENTLa reconnaissance croissante du caractère complexe dela maîtrise des questions environnementales (Stengel etGelin, 1998) ainsi que l’acceptation de l’idée selonlaquelle « la science est un tout » (Omnès, 1994) aconduit au développement des études pluridisciplinaireset à la construction de modèles intégrant le savoir dedifférentes disciplines. On peut citer pour exemple, leprojet MOPA (Lefur et Bommel, 1998) d’étude d’unsystème de pêche où les auteurs ont réalisés un couplaged’un modèle halieutique décrivant la dynamique d’uneressource marine (un stock de sardinelles) avec unmodèle socio-économique représentant le comportementdes communautés actives (pêcheurs et mareyeursartisans). La communication entre les deux modèless’effectue par l’intermédiaire d’une variable commune,le stock de poisson variant en fonction de l’action de lapêche et de l’action de la dynamique de la ressource.Belouze (Belouze, 1996) dans une approche intégrée decompréhension d’un système irrigué a couplé troismodèles : un modèle de simulation hydraulique detransport de l’eau, un modèle micro-économiquedéterminant les décisions des agriculteurs concernant lagestion d’une parcelle irriguée en fonction de différentescontraintes et un modèle hydrodynamique du transportd’eau et de sel dans le sol. Le modèle intégré ayant étéconstruit avec le logiciel Matlab et son interfacegraphique Simulink qui considère un modèle comme uneboite noire munie d’inport et d’outports, les modèles dedépart ont été reliés deux à deux, après avoir étésimplifiés pour permettre leur adaptation temporelle.La démarche de couplage retenue dans ces deuxexemples est la démarche classique adoptée enenvironnement. Cependant, comme le souligne Maxwell(Maxwell, 1998), elle implique que le modélisateur quiveut coupler des modèles possède la capacité decomprendre et de manipuler des concepts souventcomplexes n’appartenant pas à son propre domaine decompétence. Maxwell note également que la structuredes modèles complexes caractérisés par des interactionsentre multiples composants est très souvent malexplicitée, ce qui limite la compréhension de cesmodèles par les utilisateurs et leur capacité à êtreréutilisés dans des opérations d’intégration. C’est pourdépasser ces limites qu’une plate-forme de simulation aété proposée dans le cadre de la construction d’un outild’étude intégrant les aspects économiques et écologiquesde la région Patuxent (Maryland, USA). Le modèle PLM(Patuxent Landscape Model) a été conçu pour étudier lesinteractions entre les dynamiques physiques etbiologiques de la région du Patuxent, conditionnées parle comportement socio-économique de la région (Voinovet al., 1999). Le couplage du modèle écologique et dumodèle socioéconomique a été réalisé par l’intermédiaired’une représentation spatiale de la région d’étude sousforme de grille, chaque maille de la grille présentant unehomogénéité et un niveau de détail permettant aux deuxmodèles de se communiquer directement desinformations de calcul sans transformationsupplémentaire. Une unité du modèle (qui représente enfait l’ensemble du modèle couplé) est appliquée surchaque maille de la grille spatiale, avec des donnéesdifférant en fonction de la maille considérée. Cette unitéde modèle est le résultat de l’opération de couplageeffectuée avec l’outil GEM - General Ecosystem Model(Fitz et al., 1996). Cet outil logiciel permet de connecterdifférents modèles conçus indépendamment dès lorsqu’ils peuvent être manipulés par le logiciel desimulation STELLA. L’environnement spatial demodélisation SME (Maxwell et Costanza, 1995) associéau langage de modélisation modulaire MML (Maxwellet Costanza, 1997) proposés par Maxwell et Costanza,s’appuyant sur ces différents outils présente alorsl’intérêt certain d’offrir au modélisateur un cadre devisualisation graphique facilitant de couplage demodèles. L’intégration de modèles s’effectue via lamanipulation d’icônes représentant chacun des modèlesque l’on veut coupler. L’application du modèle intégrépeut être réalisée par l’utilisation d’un systèmed’information géographique (SIG), chaqueenregistrement de la base de donnée spatiale étantassociée à une unité de modèle ce qui favorise une rapidecompréhension des résultats de la simulation. Cependantcette solution présente l’inconvénient de ne permettreque le couplage de modèles réalisés graphiquement. Celaexclut un grand nombre de modèles ne bénéficiant pasd’une interface leur permettant d’être manipulés par unlogiciel de simulation graphique. Par ailleurs,l’application de l’ensemble du modèle intégré à chaquemaille d’une grille spatiale, si elle permet une meilleurevisibilité des résultats (on obtient de fait un SIGdynamique), contraint très fortement la forme du modèleintégré qui doit pouvoir être appliqué à partir desdonnées de chaque maille sans modificationsupplémentaire. De plus, cette application systématique àtoutes les mailles de la grille est coûteuse en temps decalcul.Dans la construction du système OSIRIS, notre objectif aégalement été la construction d’un outil de couplage quifacilite la manipulation des modèles de départ par

MOSIM’01 – du 25 au 27 avril 2001 – Troyes (France)l’utilisation d’une interface. Cependant, au contraire dusystème PLM, la démarche d’intégration est réalisée parl’application indépendante de chaque modèle sur unmonde simulé construit par l’utilisateur.4. LE SYSTÈME OSIRISL'outil OSIRIS (Outil de Simulation et d'intégration deprocessus physiques pour l'étude d'une Région Irriguéedu Sénégal) est l'aboutissement et le support desréflexions qui ont été menées dans le cadre de notretravail de thèse. L'objectif général a été, au-delà du castraité, de concevoir un outil suffisamment souple pourautoriser l'incorporation incrémentale de modèles deprocessus potentiellement intéressants, non prévus audépart.Il s'agit donc d'une contribution aux travaux sur lecouplage en modélisation, qui en plus de la réalisationd'une interconnexion de modèles, propose une démarcheque nous pensons être originale.De façon plus concrète, OSIRIS est un système multiagentdistribué permettant de contrôler des codesnumériques s'exécutant dans des environnements(machines, systèmes d'exploitation) différents.4.1. Architecture interneLa plate-forme OSIRIS est construite à partir dedifférents concepts : on distingue dans le système lesentités, les processus, ainsi que les mécanismes decontrôle qui assurent l'intégration. Ces concepts sontexplicités dans les paragraphes suivants.4.1.1. Les entitésLe monde est décrit sous forme d'entités dans OSIRIS. Ily a différentes sortes d'entités : les entités spatiales quibénéficient d'une représentation graphique, les entitésactives qui peuvent déclencher des processus et lesautres entités qualifiées d'ordinaires qui sont simplementle réceptacle d'informations utiles pour l'application.Entité spatialeUne entité spatiale est un objet du monde, pertinent pourle système, disposant de coordonnées géographiques. Parexemple : un périmètre, une nappe, etc. Une entitéspatiale est pertinente pour le système si elle permet dereprésenter l'effet des processus que l'on veut voir agir.Entité activeLes entités actives sont caractérisées par leur autonomiede fonctionnement. De telles entités possèdent lacapacité de déclencher et d'arrêter un processus donné.Les acteurs humains comme les exploitants sontreprésentés dans le système par des entités actives.Entité ordinaireUne entité ordinaire est un utilitaire. Ce type d'entité necorrespond pas obligatoirement à un objet existant dansle monde simulé, mais son existence facilite lamanipulation du système. On peut classer dans cettecatégorie les séries historiques comme par exemple lecalendrier cultural.4.1.2. Les processusLa notion de processus dans le système OSIRIS réfère àla définition donnée en écologie. Un processus (Blondel,1995) est défini comme la description dans l'espace etdans le temps de l'action d'un phénomène donné et desmécanismes de cette action. Les processus sont étudiéset donnent naissance à divers modèles en fonction desobjectifs recherchés par les modélisateurs. L'action duprocessus percolation consiste à diminuer la teneur eneau de la zone du sol non saturée en augmentant enconséquence la hauteur de la nappe. Le mécanisme d'untel processus est décrit par les lois de Darcy. Pour unmême processus, on peut trouver plusieurs modèlesfonctionnant à des résolutions d'espace et de tempsdifférents.La principale condition nécessaire à la prise en comptepar OSIRIS d'un modèle numérique à coupler est qu'ildoit observer un fonctionnement en mode « batch » :lecture des paramètres d'entrée à partir d'un fichier,écriture des résultats dans un fichier de sortie.4.1.3. Les mécanismes d'intégration et decontrôleL'interconnexion des modèles se fait par l'intermédiairede deux principaux mécanismes : l'utilisation decontrôleurs de temps permet de synchroniser lesdifférents modèles de processus qui s'exécutent dans lesystème distribué, tandis que la correspondance entre lesdifférentes vues (paramètres manipulés par les modèles,entités de la plate-forme de simulation) est pris en chargepar la définition de fonctions de correspondance. Lesagents de contrôle qui justifient l'utilisation duqualificatif multi-agent du système OSIRIS ont pour rôlede contrôler dynamiquement l'ensemble.Prendre en compte l'hétérogénéité du temps : lescontrôleurs de tempsLes contrôleurs de temps ont pour objet la prise encompte explicite du temps de la simulation (Fianyo etal., 1998). Dans le système OSIRIS, il n'y a pas dedéfinition d'un temps global de la simulation. Il existe unensemble de contrôleurs de temps associés chacun à uneunité de temps donnée qui est utilisée par un desprocessus évoluant dans le système. Les contrôleurs detemps sont liés deux à deux par un entier qui exprime lacorrespondance entre les unités de temps. Tout processusdu système est rattaché à un contrôleur de temps existantdont la tâche est de contrôler la périodicité avec laquellele processus s'exécute. Les liens de correspondancesentre contrôleurs de temps sont modifiables. Il estégalement possible d'insérer de nouveaux contrôleurs detemps. Le temps simulé est donc flexible.Tenir compte de l'hétérogénéité des points de vue : lesfonctions de correspondanceNous définissons la notion de fonction decorrespondance comme outil de prise en compte del'hétérogénéité des points de vue. Dans une démarche de

MOSIM’01 – du 25 au 27 avril 2001 – Troyes (France)couplage, l'un des principaux problèmes réside dans latraduction entre les différentes types de donnéesmanipulés par les modèles. Cette traduction se fait engénéral « en dur » dans le système, en fonction desmodèles étudiés. Le concept de fonction decorrespondance permet de généraliser cette démarche detraduction entre structure de données. Pour chaquemodèle de processus à intégrer dans le système OSIRIS,on associe une interface entre les fichiers de paramètresd'entrée et de sortie correspondant au modèle et lesattributs des différentes entités composant le système.Cette interface permet de spécifier la relation existantentre un paramètre et un (ou plusieurs) attribut(s) d'uneentité du système. Pour les besoins de notre application,nous avons défini un certain nombre de relations :fonctions identité, somme, moyenne. Il est possible derajouter dans le système d'autres relations dans unebibliothèque de fonctions de correspondance.Prendre en compte des dynamiques évolutives : lesagents de contrôleL'agent de contrôle est un des concepts clé du systèmeOSIRIS. Il permet le contrôle dynamique de l'exécutiondes modèles numériques du système. Pour chaqueprocessus, pour chaque modèle numérique qui lui estassocié, l'utilisateur peut poser des règles de contrôle àrespecter. Ces règles sont spécifiées à plusieurs niveaux :il est possible d'établir des règles de cohérence relativesaux données du système, afin de contrôler que lesrésultats fournis par les modèles n'entraînent pasl'existence de valeurs aberrantes. Des règles dechangement de comportement peuvent également êtrespécifiées (par exemple, changement de pas de temps) enfonction du contexte courant de la simulation.L'agent de contrôle associé à un processus vérifiepériodiquement (à chaque tentative de modification parle modèle d'un attribut d'une entité du système) au coursde la simulation, le respect de l'ensemble des règles etapplique en cas de besoin les actions nécessaires (quiont également été spécifiées par l'utilisateur). Pourl'instant, le type d'action possible est le changement de lavaleur d'une variable, nous n'avons pas développé demécanisme permettant de réaliser des actions pluscomplexes.Les agents de contrôle du système sont réalisés à l'aidede la plate-forme de construction d'agent Zeus (Collis etNdumu, 1999). L'architecture interne des agents decontrôle suit donc celle d'un agent Zeus. Lesmodifications se font par manipulation des ontologiesZeus, qui correspondent aux entités du système.Les règles de contrôleLes règles de contrôle permettent le contrôle dynamiquedes processus au cours de la simulation. Les règles decontrôle vont être spécifiées au niveau de la définitiond’une classe de processus. Une règle de contrôleconcerne soit un attribut d’une entité cible du processus,soit un paramètre d’exécution du processus. Lesparamètres d’exécution du processus considérés sont lescontrôleurs de temps et les modèles (codes numériques)possibles.Dans l’état actuel de l’application OSIRIS, une règle decontrôle suit le formalisme suivant : où est un attribut pris parmi l’ensemble desattributs des entités cibles du processus ; est une condition de la forme > valeur ou< valeur ou = valeur est une action primitive de la forme = valeurDans le cas où la règle est relative à l’exécution duprocessus, la partie action de la règle s ‘écrit :controleurTemps = , controleurTempsmodeleProcessus = Les différentes classes du système et leurs relationspeuvent être représentées par un diagrammeclasse/association suivant la notation UML, figure 2. Laclasse centrale de système est la classe Processus qui estliée par des liens de composition avec les autres classesdu système.AGENT de CTLcommuniquecontrôlese synchronise avecEst contrôlé parpossèdeEst représenté parCTR TEMPSPROCESSUSMODELEgèrecibleEst associé àLit donnéesÉcrit résultatsENTITEEst modifiéee parFICHIERpossèdeATTRIBUTEst traduitPARAMETREcontientFigure 2. Diagramme classes/association du systèmeOSIRIS4.2. Dynamique du systèmeLa dynamique du système OSIRIS peut être représentéeconceptuellement à l’aide d’une architecture en troiscouches :1. la première couche comprend les différentes entitésqui constituent le monde qui doit être modélisé etsimulé. C’est la couche statique.2. Ce monde évolue dans le temps sous l’action desdifférents processus physiques qui appartiennent àune deuxième couche, la couche dynamique. Lesprocessus du système évoluent indépendamment lesuns des autres. L’action de ces processus estcoordonnée temporellement par des contrôleurs detemps. L’action de chaque processus consiste enl’exécution d’un code numérique qui va fournir desrésultats en fonction des données provenant desattributs des entités traduits au besoin par lesfonctions de correspondance. Le code numériquereprésentant le comportement d’un processus est lerésultat d’une modélisation indépendante et peut ne

MOSIM’01 – du 25 au 27 avril 2001 – Troyes (France)pas se trouver sur la même plate-forme que lesystème OSIRIS. De plus les résultats qui sontfournis peuvent rentrer en conflit avec les valeursadmissibles de la première couche. Il est doncnécessaire d’instaurer un contrôle, ce qui est réalisépar la troisième couche.3. La troisième couche, couche contrôle, est constituéepar les différents agents de contrôle qui sont chacunassocié à un processus et dont le rôle est de mettreen œuvre les règles de contrôle qui ont été spécifiéespar l’utilisateur.Cette représentation du fonctionnement en couche estillustrée par la figure 3.Agents de contrôleCT1Dynamique du monde simulé : les processus instanciésCT2CT : contrôleur de tempsN° Signification :1 Autorisation par le contrôleur de temps courant del'exécution d'un cycle par le processus2 Demande d'autorisation d'exécution3 Autorisation d'exécution par l'agent de contrôleaprès vérification des différentes règles relativesau processus4 Création via le modèle-client courant du fichier dedonnées nécessaire à l'exécution du modèle client5 Envoi du fichier de données au modèle serveur etattente de la réponse6 Création d'un thread permettant l'exécution ducode numérique associé7 Envoi des résultats produit par le code numérique8 Récupération des valeurs via le modèle-client dansle fichier résultat et mise à jour des entités9 Demande de contrôle des valeurs mises à jour10 Signalement aux accointances des modificationseffectuées par le processus. Vérification des règlesde contrôle11 Signalement de la fin du cycle5. UNE DÉMARCHE DE COUPLAGE DEMODÈLESMonde simulé : les instances d ’entitésFigure 3. Organisation conceptuelle d ’OSIRISCette architecture est implémentée en langage Java. Celangage propose différents outils (threads, remotemethode interface) qui facilitent la construction d’uneapplication distribuée et constituée de composantsévoluant en parallèle. De plus la plate-forme Zeus estégalement construite avec ce langage, ce qui facilite lacommunication entre les sorties de cette plate-forme etl’application OSIRIS.La perspective dynamique du système peut alors êtrereprésentée suivant le diagramme de collaboration UMLde la figure 4.10AGENT DECONTROLE32PROCESSUS98411MODELE-CLIENTcourant517CONTROLEURDE TEMPScourantMODELESERVEURFigure 4. Perspective dynamique d ’OSIRIS : les actionsréalisées lors d ’un cycle du processus.Les différents numéros représentent différentes actionsqui s’interprètent alors comme suit :6Nous proposons une démarche de couplage qui se veut laplus générique possible. La plupart des systèmes decouplage de modèles imposent à l'utilisateur un certainnombre de choix réduisant d'autant son degré de liberté :ils comportent d'emblée le choix d'un point de vue sur lemonde. La démarche de couplage dans le systèmeOSIRIS inclut la possibilité pour l'utilisateur de définirsa propre vision du monde, sur laquelle vont être greffésles modèles. C'est donc le point de vue de l'utilisateur quiva diriger le couplage. Nous rendons ainsi son problèmeau modélisateur en lui offrant cependant les moyens dele traiter.L'utilisation de l'outil OSIRIS s'accompagne, dans cecadre, de la réalisation d'un certain nombre de tâchespréalables :1. il faut définir une vision du monde (c'est à direl'ensemble des objets et des attributs qui vontconstituer les composants du simulateur) ;2. il faut spécifier les processus physiques que l'onveut intégrer et les entités sur lesquelles ils opèrent ;les résolutions temporelles avec lesquelles on veutles simuler et à l'aide de quels modèles numériques ;3. il faut définir les règles de correspondance entre lesparamètres des modèles numériques choisis et lesentités et attributs représentant la vision du mondequi a été définie ;4. il faut enfin spécifier les règles de validitépermettant d'évaluer les résultats fournis par lesmodèles numériques que l'on intègre.Ce travail non négligeable est en général toujours réalisépar le modélisateur, l'outil OSIRIS permet de l'expliciter.

MOSIM’01 – du 25 au 27 avril 2001 – Troyes (France)6. VALIDATIONUne démarche de modélisation implique la prise encompte de la question de la validité du modèle proposé.La proposition d'un système comme OSIRIS qui se veutà la fois être un outil de simulation et de manipulation demodèles ne peut pas faire l'économie d'une réflexion surla validation, question déterminante vis à vis de l'intérêtde notre entreprise (Cordier, 1999).De façon classique, la validation d'un modèle s'effectuepar confrontation entre les résultats fournis par le modèleet les données observées dans la réalité. Dans notreproblématique, une telle validation nécessite la prise encompte de trois types de validation :• le premier type réside dans la vérification de lavalidité des modèles numériques à intégrer ;• le deuxième type de validation se situe dans lecontrôle du résultat obtenu par le mécanismed'intégration. Dans notre cas, un contrôle dynamiqueest effectué en fonction d'un ensemble de règlesposées par l'utilisateur . Il s'agit donc de vérifier lavalidité de ces règles;• le troisième type réside dans le respect des règlesposées au cours de la simulation.Seuls les deuxième et troisième types de validationconcernent spécifiquement le système OSIRIS. Onsuppose que les modèles à intégrer ont déjà été validésauparavant.Le respect des règles au cours de la simulation peut êtreassez facilement vérifié par une démarche classique dedebugage et de mise au point du système.Le deuxième type de validation pose deux catégories deproblèmes :conceptuel : à savoir que l'on soit capable de définir etd'apprécier globalement ce qu'est une bonne simulationde processus intégrés (par exemple, conservation de lamasse)technique : il s'agit du problème des outils proposés àl'utilisateur pour poser ses règles. Les possibilitésd'expression de règles dans le système OSIRIS sont pourl'instant très fortement limitées.Enfin la validation peut s'appliquer au schémaconceptuel et à la démarche d'OSIRIS et à son caractèregénérique. L'attitude des modélisateurs, lorsqu'on leurprésente l'outil, est de ce point de vue ouverte et positive.Ce « quatrième type » de validation passe parl'application effective de la démarche à d'autrescontextes.7. CONCLUSIONDans l'état actuel de notre travail, le système OSIRIS estun prototype dont le principal intérêt est de montrer lafaisabilité d'un ensemble de concepts potentiellementintéressants. Les concepts présentés dans cet article(synchronisation temporelle de modèles numériques parutilisation de contrôleurs de temps, traduction entredifférentes vues par l'intermédiaire de fonctions decorrespondance, contrôle dynamique par l'intermédiaired'agent de contrôle) pour la plupart implémentés, et quiont permis de simuler le couplage de deux modèles tests(non présentés dans cet article), se révèlent être de bonsoutils dans une démarche d'intégration de modèles.RÉFÉRENCESBelouze, P. (1996). Un modèle intégré d’un systèmeirrigué par la prise en compte de phénomèneshydrauliques, économiques et hydro-pédologiques.Mémoire de DEA, Ecole Nationale du Génie Rural,des Eaux et des Forêts, Montpellier.Blondel, J. (1995). Approche écologique et évolutive.Collection Ecologie numéro 27. Editions Masson.Boivin, P. (1997). Soil degradation in irrigation schemesin the Senegal river middle valley : Mechanisms,characterization methods and actual situation . DansK.M. Miezan et al.(eds) Irrigated rice in the Sahel :Prospects for Sustainable development. West AfricaRice Development Association, Bouake. pp 37-49.Collis, J. et Ndumu, D. (1999). The Zeus Agent BuildingToolkit : Zeus Methodology Documentation. BritishTelecommunications Labs.Cordier, M-O. (1999). Actes de la Journée autour de la"Validation de modeles traitant de processuscomplexes". INRA, Rennes.Fianyo, E., Treuil, J-P., Perrier E., et Demazeau,Y.(1998). Multi-Agent Architecture IntegratingHeterogeneous Models of Dynamical Processes: TheRepresentation of Time. In : Multi-Agent Systemsand Agent-Based Simulation Proceedings. LNAI,volume 1534, Springer-Verlag. pp 226-236.Fitz, H.C., DeBellevue, E., Costanza, R., Boumans, R.,Maxwell, T., Wainger, L., Sklar, F., (1996).Development of a general ecosystem model for arange of scales and ecosystems. EcologicalModelling 88 (1/3), 263-295.LeFur, J. et Bommel, P. (1998). Couplage d’un modèlemulti-agent de la dynamique d’une ressource marineavec un modèle multi-agent de l’exploitationhalieutique artisanale sénégalaise. Séminaire SMAS,INRA Montpellier.Maxwell, T. (1998). Collaborative Multi-ParadigmModeling of Environmental Systems. Proceedings ofthe 1998 Conference in Simulation Methods andApplications. Orlando, Florida.Maxwell, T et Costanza, R., (1995). Distributed ModularSpatial Ecosystem Modelling (special issue onAdvances Simulation Methodologies). InternationalJournal of Computer Simulation 5(3), 247-262.Maxwell, T et Costanza, R., (1997). A language formodular spatio-temporal simulation. Ecologicalmodelling 103 (2/3), 105-114.Omnès, R. (1994). Philosophie de la sciencecontemporaine. Gallimard, Paris.Pouliot, J.(1999). Définition d'un cadre géosémantiquepour le couplage des modèles prévisionnels decomportement et des SIG; application pour les

écosystèmes forestiers. Thèse de doctorat, EcolePolytechnique Fédérale de Lausanne.Stengel, P. et Gélin, S. , (1998). Sol, Interface Fragile.Collection « Mieux Comprendre ». INRA Editions,Versailles.Voinov A., Costanza R., Wainger L., Boumans, R.,Villa, F., Maxwell, T., Voinov, H., (1999) Patuxentlandscape model : integrated ecological economicmodeling of a watershed. Environmental Modelling& Software, 14 : 473-491. Elsevier Science Ltd.MOSIM’01 – du 25 au 27 avril 2001 – Troyes (France)