Une approche multiagent pour la planification des trajectoires

des navires dans un espace spatio-temporel

Mémoire présenté

à la Faculté des études supérieures de l'université Laval

pour l'obtention du grade de Maître ès Sciences (M. Sc.)

Département d'informatique FACULTE DES SCIENCES ET GENIE

UNIgrERSITE LAVAL

MAI 2001

O Nafaâ Jabeur, 2001

National Library I * m of Canada Bibliothèque nationale du Canada

Acquisitions and Acquisitions et Bibliographie Services services bibliographiques

395 Wellington Street 395. nie Wellington Ottawa ON K? A ON4 Ottawa ON K I A ON4 Canada Canada

Your fila Votre rdference

Ouf fi& Notre #!d/~liCB

The author has granted a non- L'auteur a accordé une licence non exclusive licence allowing the exclusive permettant à la National Library of Canada to Bibliothèque nationale du Canada de reproduce, loan, distribute or seIl reproduire, prêter, distribuer ou copies of this thesis in microfonn, vendre des copies de cette thèse sous paper or electronic formats. la forme de microfiche/fb, de

reproduction sur papier ou sur format électronique.

The author retains ownership of the L'auteur conserve la propriété du copyright in this thesis. Neither the droit d'auteur qui protège cette thèse. thesis nor substantial extracts fkom it Ni la thèse ni des extraits substantiels may be printed or otherwise de celle-ci ne doivent être imprimés reproduced without the author's ou autrement reproduits sans son permission. autorisation.

Abstract

The maritime traffic on the Saint-Lawrence River represents an important econornic

activity. Vessels, having different sizes, take this channel for commercial and tounstic purposes.

Due to several dynamic constraints, such as tides, currents and ice, navigation through the

channel provides many difficulties. The constraints, mentioned above, cause delays and threaten

the security of vessels.

The Canadian Coast Guard, the Canadian Hydrographie Services and many other

organisations have developed several systems to ensure secure and d i a b l e navigation on the

Saint-Lawrence. These systerns are generdly devoted to resolve just one constraint at a time and

do not offer any autonomy to navigators. Moreover, they are not designed to collaborate.

Knowing that the management of navigation on the Saint-Lawrence River must take into

consideration d l navigational constraints, this thesis proposes a solution that rnay enable existing

systems to collaborate even though they are heterogeneous. This solution is based on a

multiagent approach. To support this proposition, we present, through this paper, a system that

we have developed to solve the problem of ship course planning on the Saint-Lawrence. Our tool

provides a multiagent solution, which cdculates a vessel trajectory in the channel, based on

information about the tide, the current and the vessel. It enables us to know the probable arriva1

time of vessels. As well, it enables us to ensure better secunty to vessels by advising navigators

to depart at a new time in order to avoid low-level water zones in the channel. In addition to this,

Our tool provides an advantage, compared to other existing systems, by giving more autonomy to

navigators who, currently, follow orders from the Coast Guard.

Résumé

Le trafic maritime sur le fleuve Saint-Laurent représente une activité économique

importante. Des navires, de diverses grandeurs, empruntent la voie du fleuve pour des fins

commerciales ou touristiques. À cause de plusieurs contraintes dynamiques, entre autres les

marées, les courants et les glaces, la navigation dans le chenal présente des difficultés. Ces

contraintes engendrent, outre des retards, des problèmes de sécurité pour les navires.

La Garde Côtière Canadienne, le Service Hydrographique Canadien ainsi que plusieurs

autres organismes ont mis en place des systèmes pour assurer une navigation sure et fiable sur le

Saint-Laurent. Ces systèmes sont généralement destinés à résoudre une contrainte de navigation à

la fois et n'offrent actuellement aucune autonomie aux navigateurs. De plus, ces systèmes ne sont

pas conçus pour coopérer.

Ayant la conviction que la gestion de la navigation sur le Saint-Laurent doit prendre en

considération toutes les contraintes de navigation, ce mémoire propose une solution qui pourrait

faire coopérer les systèmes existants malgré leur hétérogénéité. Cette solution est basée sur

l'approche multiagent. Pour appuyer cette proposition, nous présentons. à travers ce rapport, le

système que nous avons développé pour la planification des itinéraires sur le Saint-Laurent. Notre

outil fournit une solution multiagent qui calcule les trajectoires des navires sur le fleuve en se

basant sur des informations concernant les marées, les courants et le navire. Il permet de

connaître les heures d'arrivées probables des navires. Il permet aussi d'assurer une meilleure

sécurité des navires en suggérant des nouvelles heures de départ à l'usager afin d'éviter les zones

du chenal à bas niveau d'eau. Aussi, notre outil offre un avantage par rapport aux systèmes de

gestion de la navigation utilisés actuellement en donnant plus d'autonomie aux navigateurs qui,

jusqu'à date, ne font que suivre les consignes de la Garde Côtière.

Ouébec. Mai 200 1

Nafaâ JABEUR

Étudiant

-- Bernard MOULIN

Directeur de recherche

Bnan MORSE

Codirecteur

Dédicaces

Avant-propos

Table des matières

Table des matières

1 . CONTEXTE

. 1 LNTRODUC~ION ....................................................................................................................................................... 5 ............................................................................................................................................... 2 . DOMAINE DU PROJET 5

3 . ~vPORTANCE DE LA NAVIGATION SUR LE SAINT-LAURENT ..................................................................................... 7 . 4 CONTRAWTES DE NAVIGATION .............................................................................................................................. 9

5 . ETAT ACTUEL ....................................................................................................................................................... I O 6 . SPÉCIFICATION DU PROJEI- ................................................................................................................................... 1 2

.................................................................................................. 6.1 L'initiative MGOI .................................... ,.., 12 6.2 L'architecture de MGDI ................................................................................................................................ 12 6.3 L'approche mriltiagent ................................................................................................................................... 13

................................................................................................................. 6.3.1 Les agents .....................,......,............... 13 6.3.2 Les systkmes multiagents ........................................................................................................................................... 14

6.4 Les contraintes de la planification des itinéraires ......................................................................................... 14 6.5 Besoins des usagers ........................................................................................................................................ I S 6.6 O bjecrifs du projet ......................................................................................................................................... 1 6

................................................................................................................................ II . TECHNOLOGIE CHOISIE 18

LOGICIELS I . I Introduction .................................................................................................................................................... 19 1.2 Les agents logiciels ........................................................................................................................................ 19

1.2.1 Définidons .............................................................................................................................................................. 19 ........................................................................................................... 1.2.2 Les propriétés des agents ........................ ,.. 20

1.3 Les systèmes multiagents ................................................................................................................................ 22 ...................... ....................................................................................................................... 1.3.i Présentation générale .. 22

1.3.2 Les propridtés des systèmes multiagents .................................... ,,. ............................................................................. 23 1.4 Interaction, coopération, coordination et négociation entre les agents ................................................... 24

.................................................................................................................... 1.5 Commrrnicarion entre les agents 26 1.6 Appotîs des systèmes rnultiagents .................................................................................................................. 2 6 1.7 Systèmes distribugs et Systèmes multiagen ts ................................................................................................. 2 7 1.8 Utilisation de L'approche multiagent dans le domaine des applications marines .......................................... 28

. . . .

1.9 Conclusion ................................................................................................................................................ 3 0 2 . BEE-GENT .......................................................................................................................................................... 31

2.1 Introduction .................................................................................................................................................... 31 2.2 Le framework Bee-gent ..................... ..,..... ............................................................................................. 3 2 2.3 Caractéristiques de Bee-genr ......................................................................................................................... 32 2.4 Architecture de Bee-gent ................................................................................................................................ 33

........................................................................................ 2.5 Frameworks de développement d'objets distribués 35 ..

2.6 Liste des fonctionnalités (Comparaison) .................................................................................................... 36 2.7 Concepts de base de Bee-gent ............ ........................................ .................................................................. 36 2.8 Conversations XMUA C L ............................................................................................................................... 38

3.1 Pourquoi Java ? ................................ .. ....................................................................................................... 39 4 . MAuB ................................................................................................................................................................ 42

4 . I Pourquoi Matlab ? ....................................................................................................................................... 42 5 . CONCLUSION ......................................................................................................................................................... 43

Liste des figures

Liste des figures

Figure1 . 1 : Trafic combiné par type de cargaison (Voie maritime du Saint-Laurent) .................................................... 8 Figure 2-1 : Les propriétés des agents ...................................................................................................................... ....20 Figure 2.2 : Application de l'approche multiagent dans le domaine des applications marines ..................................... 29 Figure 2.3 : Interconnexion d'applications réseau sous Bee.gent ................................................................................ 31 Figure 2.4 : Framework du Bee-gent .......................................................................................................................... - 3 2 Figure 2.5 : Structure de couches de Bee.gent ............................................................................................................. 34 Figure 2.6 : Architecture type de Bee-gent .................................................................................................................. 34 Figure 2.7 : Communication inter-agents sous CORBA .............................................................................................. 35 Figure 2.8 : Cornmucication inter-agents sous JI NI ............................ .. .................................................................. 35 Figure 2.9 : Communication inter-agents sous Bee-gent .............................................................................................. 36 Figure 2.10 : Protocole d'interaction ............................................................................................................................ 37

............................................................................................................. Figure 2.1 1 : Schéma de la portabilité de Java 40 .................................................................................. Figure 3.1 : Architecture du systtme multiagent proposée ........46

Figure 3.2 : Interface de l'Agent Navire ....................................................................................................................... 47 Figure 3.3 : Interface de l'agent Marée lors de l'exécution du système ....................................................................... 48 Figure 3.4 : Interface de l'agent Courant lors de L'exécution du système ...................................................................... 48 Figure 3.5 : Transmission de la table de courants lors de l'exécution du système ............ .. ......................................... 49 Fi-we 3.6 : Interface de l'agent Fédérateur lors de I'exécutiûn du système ................................................................. 50 Figure 3.7 : Interface de l'agent Navire à la fin de l'exécution du système ................................................................ 51 Figure 3.8 : Courbes des niveaux d'eau entre Montréal et Québec pour un seuI jour ................................................... 52 Figure 3.9 : Delimitation des zones de passages interdites ................................................................. 53 Figure 3.10 : Calcul des trajectoires au plus tôt et au plus tard du navire ................................................................. 54 Figure 3.1 1 : Calcul de l'heure de départ suggérée afin d'éviter l'arrêt du navire ...................................................... 55 Figure 3.12 : Diagramrne de transition de l'agent Navire ............................................................................................. 57 Figure 3.13 : Diagramme de transition de l'agent Marée ............................................................................................. -58 Figure 3- 14 : Diagramme de transition de l'agent Courant ........................................................................................... 59 Figure 3.15 : Diagramme de transition de l'agent Fédérateur ....................................................................................... 60

................................................................................... Figure 3.16 : Interfaçage agent Fédérateur/Progamrne Matlab 61 ........................................................................................................................ Figure 3.1 : Organigramme du serveur -65

Figure 4.2 : Organigramme du client ........................................................................................................................... 66 Figure 4.3 : Organigramme du premier état de l'agent Courant. .................................................................................. 68 Figure 4.4 : Organigramme du deuxième état de l'agent Courant ................................................................................ 69 Figure 4.5 : Schéma du message XMUACL envoyé par l'agent Navire ...................................................................... 70

..................................................................................... Figure 4.6 : Organigramme du premier état de l'agent Navire 71 Figure 4.7 : Organigramme du deuxième état de l'agent Navire ............................................................................. .....72 Figure 4.8 : Organigramme du premier état de l'agent Fédérateur ....................... .. ................................................. 73 Figure 4.9 : Organigramme du deuxième état de l'agent Fédérateur ............................................................................ 75 Figure 4.10 : Organigramme du uoisième état de l'agent Fédérateur ................................................................ ..........77 Figure 4.1 1 : Organigramme de la planification des itinéraires ................................................................................... 79 Figure 4.12 : Modélisation 3D (Distance, temps et niveau d'eau) ................................................................................ 81

...................................................................................................................... Figure 4.13 : Courbes des niveaux d'eau 82 Figure 4.14 : Délimitation des zones interdites au passage des navires ...................................................................... -83 Figure 4.15 : Modèle de variation des courants en intensité et en direction ................................................................. 84 Figure 4.16 : Approche de traçage de la trajectoire du navire ...................................................................................... 85 Figure 4.17 : Exemple de calcul des trajectoires des navires ....................................................................................... 85 Figure 4.18 : Calcul de l'heure 3 suggérer au navigateur .............................................................................................. 87 Figure 5.1 : Architecture du système multiagent proposé en perspective ................................................ ....................94

Liste des tableaux

Liste des tableaux

Tableau 2.1 . 1 : Propriétés intrinsèques des agents ..................................................................................................... -21 Tableari 2.1.2 : Propriétés extrinsèques des agents ....................................................................................................... 21 Tableau 2.1.3 : Propriétés des systèmes multiagents .................................................................................................. 23 Tableau 2.1 -4 : Propriétks de i'environnemznt des systèmes multiagents ......................................... ... ................... 24 Tableau 2.2.1 : Comparaison des fonctionnalités de Bee.gent, CORBA et JINI ......................................................... 36

Introduction

Introduction

Le Saint-Laurent canalise un trafic intense qui ne cesse de se développer. Son

emplacement géographique fait de lui un raccourci entre l'Ouest européen et le Nord américain.

Grâce à cet emplacement stratégique, il est sollicité par des navires de plus en plus grands et par

une industrie en pIeine expansion. Le fleuve dessert, de plus, le Port de Montréal qui focalise, à

lui seul, 20% des échanges commerciaux effectués à travers le Saint-Laurent.

Pour maintenir la confiance des armateurs et garantir des meilleures rentabilités, des

organismes canadiens, entre autres la Garde Côtière Canadienne (GCC) et le Service

Hydrographique Canadien (SHC), veillent sur la gestion de la navigation dans le chenal du Saint-

Laurent et garantissent un passage sécuritaire des navires. Cette tâche est loin d'être simple ;

plusieurs facteurs perturbent la navigation et peuvent porter atteinte à la sécurité des bateaux.

Parmi ces facteurs on cite les marées, les courants et les glaces, sans oublier les caractéristiques

du navire (ses dimensions, son tirant d'eau, etc.). La majorité de ces facteurs changent de façon

dynamique en fonction du temps et de l'espace, ce qui complique davantage la gestion de la

navigation sur le fleuve. Les impacts de ces contraintes de navigation sont coûteux en temps et en

argent. Outre les retards notés sur les heures d'arrivées des navires et les perturbations du trafic

maritime, elles génèrent des perturbations de l'activité portuaire.

Plusieurs solutions ont été développées pour réduire au maximu.m les effets des

contraintes de navigation. On cite entre autres le système Atlas pour la prédiction des marées,

EPDSS pour la gestion de la glace, SINECO qui donne ie niveau d'eau en temps réel, les cartes

électroniques et les systèmes de positionnement géographique GPS. La plupart de ces solutions

Introduction

ne gèrent qu'une seule contrainte de navigation et ne fournissent par conséquent qu'une partie de

la solution du problème global de la gestion de la navigation dans le Saint-Laurent.

Quoique ces solutions soient performantes, les besoins des utilisateurs vont au-delà des

résultats actuels. Ils réclament une navigation plus sécuntaire, plus de facilités pour l'accès au

Port de Montréal ainsi que plus d'autonomie pour les navigateurs. Pour rkpondre à ces besoins, il

faut concevoir un système unique qui permet la gestion de toutes les contraintes de navigation.

Ce système doit utiliser plusieurs applications existantes et réduire le degré de dépendance vis-à-

vis des propriétaires de ces solutions. Il faut employer une approche qui permet d'utiliser les

solutions existantes malgré leurs hétérogénéités, de les faire coopérer et de fournir la possibilité

d'étendre le système global en intégrant des nouvelles solutions.

L'approche multiagent est utilisée pour la mise en œuvre d'un système qui permet

d'intégrer plusieurs applications existantes. Elle facilite leurs coopérations ainsi que le partage

des informations communes. Cette approche permet aussi de découper le problème en un

ensemble de tâches qui seront désormais effectuées par des programmes agents autonomes. Il

reste, donc, à prouver que cette approche est bel est bien appropriée au domaine des applications

marines et qu'elle répond aux exigences mentionnées auparavant.

Afin de mettre en valeur l'approche multiagent, nous avons choisi de l'appliquer à la

résolution du problème de la planification des itinéraires dans la section du chenal entre Montréal

et la ville de Québec, une section qui s'étend sur une distance d'environ 260 km. Ce choix s'inscrit

dans le projet MASAT (Marine Applications and Software Agent Technology) lamé en

décembre 1999. La planification des itinéraires est un problème dynamique de type 3D (temps,

espace, hauteur). Il s'agit de calculer les trajectoires des navires en tenant compte des

informations concernant le navire et des contraintes de navigation qui règnent dans le fleuve

(marées, courants, etc.). Il s'agit aussi de fournir des suggestions concernant les horaires de départ

des navires afin d'échapper aux perturbations générées par les contraintes de navigation telles que

les zones à faibles niveaux d'eau. Le travail prévu doit viser la génération d'un système global

dans lequel plusieurs solutions pour la gestion de la navigation sur le Saint-Laurent coopèrent. De

plus, il doit répondre au mieux aux besoins des utilisateurs en matière de sécurité des navires et

des informations concernant la navigation des navires.

Le présent mémoire présente le travail effectué pour la résolution du problème de la

pIanification des trajectoires des navires dans un espace spatio-temporel, en l'occurrence le fleuve

Saint-Laurent. 11 comporte cinq parties. La première est consacrée au contexte général du projet.

Elle présente son domaine (en l'occurrence le fleuve Saint-Laurent) et les contraintes de

navigation qui s'y trouvent. Elle présente, aussi, les problèmes générés par ces contraintes, les

besoins des utilisateurs ainsi que le but du projet. La deuxième partie est dédiée à la technologie

choisie pour résoudre le problème de la planification des itinéraires. Entre autre, elle passe en

revue la technologie des agents et du multiagent ainsi que Bee-gent en tant que plate-forme de

génération de systèmes multiagents. La troisième partie est consacrée à la solution rnultiagent

adoptée. Elle présente l'architecture du système global et les différents agents qui y figurent ainsi

que les systèmes avec lesquels ils s'interfacent. La quatrième partie concerne la réalisation

technique de l'outil généré au cours de ce travail. Elle détdle les caractéristiques des agents et les

systèmes conçus durant ce mémoire. La dernière partie est dédiée aux résultats obtenus et aux

perspectives que nous jugeons pertinentes pour toute personne intéressée par cet effort. Il est à

noter que des annexes clôturent ce rapport et présentent, entre autres, tout ce qui à trait à la

terminologie marine et le langage de communication des agents ACL.

Contexte Général

1. Introduction

2. Domaine du projet

3. Importance de la navigation sur Le Saint-Laurent

4. Contraintes de la navigation sur le Saint-Laurent

5. État actuel de la navigation

6. Spécification du projet

1. Introduction

La voie navigable du Saint-Laurent représente un raccowci entre l'Amérique du Nord et

le nord-ouest européen. Elle est empruntée par des navires ayant des tonnages de plus en plus

importants. Leurs navigations sont sujettes à des problèmes de sécurité à cause de la topologie du

fleuve et aux conditions naturelles qui règnent dans la région. Ces facteurs affectent la navigation

en influençant entre autres les vitesses des navires et leurs horaires de départ et d'arrivée.

Plusieurs organismes canadiens travaillent depuis bien des années à la gestion du trafic

sur le Saint-Laurent. Ils esszyent d'assurer une navigation sure et optimale en temps et en argent.

Les recherches ont donné un ensemble de systèmes matériels et logiciels certes efficaces, mais

n'offrant aucune autonomie pour les navigateurs. De plus, ces systèmes ne prennent

généralement pas en considération toutes les contraintes de navigation. Ils demeurent pour cette

raison incompIets pour une gestion globale de la navigation sur le fleuve.

Le présent projet met l'accent sur l'autonomie à accorder aux navigateurs. On vise à

développer un système d'aide à la planification des trajectoires des navires sur le Saint-Laurent et

plus précisément dans la section du chenal entre Québec et MontréaI.

2. Domaine du projet Le volume du trafic maritime dans le Saint-Laurent est de plus en plus important. Des

navires géants assurent le transport des marchandises le long du chenal. À I'entrée du port de

Montréal, ils observent parfois des attentes qui leur coûtent cher en temps et en argent.

L'évolution des navires en forme et en tonnage et le développement de la voie navigable du

Saint-Laurent ne se font pas avec le même rythme. Le passage des grands vraquiers est possible,

mais les mesures de sécurité leur imposent des réductions de vitesse dépendemment de l'endroit

et de l'heure de la navigation. Pour gérer au mieux ces restrictions et optimiser les attentes en

plus de l'assurance d'une navigation sure, les organismes canadiens emploient plusieurs systèmes

de surveillance, d'aide à la décision, d'intervention, etc. La Garde Côtière Canadienne (GCC)

Chapitre 1 : Contexte aénéral

met dans différents points stratégiques du fleuve des radars et des caméras de surveiIlance, des

ilots artificiels ainsi que toute une infrastructure de télécommunication. Elle a recours aux images

satellites pour mieux contrôler la voie navigable. Elle assure, en plus, les opérations de secours en

cas d'incidents. D'autres organismes sont aussi impliqués dans la gestion de la navigation sur le

Saint-Laurent dont on cite le Service Hydrographique Canadien (SHC).

Entre Québec et Montréal, la voie navigable du Saint-Laurent présente des topologies

différentes. Certaines sections offrent un niveau d'eau suffisant et permettent le passage des

grands navires sans problèmes de sécurité et sans restrictions. D'autres sections sont critiques. Le

niveau d'eau est non seulement faible mais, aussi, sujet & des variations importantes à cause des

marées et des courants qui règnent dans la région. La navigation est parfois impossible pour des

grands navires à certaines heures. En hiver, l'accumulation de la glace rend difficile la

navigation. L'intervention des brises-glace est parfois nécessaire pour briser l'accumulation de la

glace qui peut bloquer certains passages.

Devant de telles contraintes, les organismes canadiens essayent de planifier les passages

des navires. Il faudrait que :

Les navires qui veulent atteindre le port de Montréal y entrent sans attente et s'il y a des

délais, qu'ils soient les plus courts possibles.

Les navires puissent respecter leurs calendriers en évitant au mieux les retards affectant les

heures de départ et d'arrivée.

L'accumulation de la glace ne perturbe pas la navigation.

La navigation soit sure le long du chenal. La profondeur de l'eau au moment du passage d'un

navire ne doit pas être un souci de sécurité.

Les plus grands navires puissent naviguer librement en transportant la quantité de

marchandises voulue.

Les systèmes développés et proposés par les différents organismes canadiens permettent

une bonne gestion de la navigation sur le Saint-Laurent, entre autres entre Québec et Montréal.

Le navigateur n'a pratiquement pas de soucis pour la sécurité de son navire. Il n'a qu'à suivre les

consignes de la GCC pour traverser le fleuve. Cependant, dans cette configuration, le navigateur

ne possède aucune autonomie. L'accès au système qui gère sa navigation n'est possible que via

l'organisme qui le possède.

Les moyens déployés pour la gestion de la navigation sur le Saint-Laurent sont très

importants. Le paragraphe suivant met l'accent sur l'importance de la navigation sur le Saint-

Laurent qui explique la motivation et la forte présence des investisseurs.

6

3. Importance de la navigation sur le Saint-Laurent La voie maritime du Saint-Laurent renferme l'un des ports les plus sollicités par !a

navigation dans le nord de l'Amérique ; c'est le port de Montréal. Grâce à sa position stratégique

et ses différents services et moyens, il accepte un traf3c commercial croissant et stimule tous les

secteurs d'activité de la région. L'impact économique actuel est de presque 1.2 milIiards de

dollars par année et de 14000 emplois directs et indirects [2 ] .

Les navires qui traversent le Saint-Laurent sont de plus en plus grands en taille et en

volume. Ce développement de la part des bateaux n'est pas suivi par un mouvement pareil de la

part du fleuve qui n'a pas beaucoup changé depuis plus de 20 ans [2 ] . Cela impose un besoin

incessant de disposer d'outils d'aide à la décision pour les navigateurs. Des mesures

d'aménagement du chenal entre le pont de Québec et Montréal assurent une profondeur minimale

de 11 mètres, ce qui permet aux navires d'une capacité de 40 000 à 50 000 tonnes d'atteindre le

port de Montréal sans encombre [7]. D'autres mesures ont permis aux Iaquiers de dimensions

adaptées aux conditions de la voie maritime (222.5 mètres de longueur et 23.1 mètres de largeur)

d'emprunter le chemin du Saint-Laurent pour effectuer leurs commerces [7].

Le réseau portuaire québécois accueille une variété de types et de tailles de navires allant

de la barge au vraquier géant de 300 000 tonnes. Au total, ce réseau manutentionne entre 100 et

120 millions de tonnes de fret par an. Cela représente environ 30% des trafics pour tout le Canada

et fait du Québec la première province pour le transport maritime au pays [7]. Selon les

statistiques de la GCC, les ports du Saint-Laurent enregistrent entre 6000 et 7000 mouvements de

navires par année [7].

Les cargaisons transportées le long du fleuve atteignent actuellement environ 50 millions

de tonnes par an. Elles englobent les cargaisons en vrac qui représentent environ 90% du tonnage

annuel. Ses principales marchandises sont les céréales, le charbon et les produits laitiers. Le

deuxième type de cargaisons représente les cargaisons générales et sont la plus forte valeur par

tonnage de cargaison de la voie maritime (la Voie maritime représente les 1600 kilomètres du

fleuve du Saint-Laurent entre l'atlantique et Montréal). Elles représentent les produits emballés

manufacturés et transformés. Ses produits les plus courants sont l'acier et les machines 141. 80%

du trafic annuel concerne les céréales, Ie fer et le minerai de fer, l'acier et le charbon. Les 20%

restants englobent le coke, les produits chimiques et pétroliers, le bois et les produits miniers [4]

(Figure 1.1).

Chavirre I : Conrexte aénéral

Figure1.2 : Trafic combiné par type de cargaison (Voie maritime du Saint-Laurent).

Le trafic commercial n'est pas le seul présent sur le chenal du Saint-Laurent. On recense

aussi le transport des personnes qui représente une activité importante sur le fleuve. Les

traversiers qui assurent le passage entre ses rives jouent un rôle fondamental pour le passage des

véhicules. Les croisières d'excursions, actives durant la période estivale, représentent un secteur

d'activité d'une centaine d'entreprises. Chaque année, on estime un nombre de passagers

d'environ 900 000. Les bénéfices directs ou indirects de cette activité sont évalués à un chiffre de

100 rnillions de dollars 171.

À ces types de trafics sur le fleuve s'ajoute la navigation de plaisance. Une activité

permanente lors des périodes estivales. Chaque année, des centaines de bateaux de plaisance

empruntent la voie du Saint-Laurent pour le spoa et pour profiter des paysages qui se trouvent le

long de ses rives.

Chapitre 1 : Contexte aénéraf

4. Contraintes de navigation La section précédente a montré l'importance du fleuve Saint-Laurent tant au niveau social

que commercial. Du point de vue commercial, cette importance est assurée grâce aux efforts

considérables des organismes canadiens pour maintenir une navigation sure en tout temps et en

toute circonstance. Cependant, plusieurs facteurs, sunout naturels, peuvent perturber la

navigation des navires.

Le chenal du Saint-Laurent contient des zones à niveaux d'eau faibles. Il contient aussi

plusieurs îlots qui, parfois, réduisent considérablement la largeur du fleuve déjà étroit dans

certains endroits. Plusieurs rivières et ruisseaux alimentent le chenal. En son fond, des creux et

des roches font varier la profondeur de l'eau. Les dunes de sables sont présentes et représentent

un danger potentiel. En 1999, ces dunes étaient Ia cause du naufrage d'une croisière à côté de la

ville du Québec. Des dégâts matériels énormes ont été enregistrés.

Cette géographie difficile du fleuve influence le mouvement de l'eau. Le facteur des

marées (Voir annexe 1) fait varier Ie niveau de l'eau d'une façon non uniforme dépendemment

des lieux. Ainsi, dans la section du chenal entre Montréal et Trois-Rivières, la variation du niveau

de l'eau est raisonnable et non importante. Plus on s'approche de Québec, plus cette variation est

grande. Elle peut atteindre dans certaines zones le seuil de 10 mètres et plus en quelques heures.

Dans de telles sections du fleuve, et compte tenu de la grandeur des vraquiers géants, une

navigation sécuritaire en tout moment et en toute circonstance est remise en question.

Généralement, il faut que le passage des grands navires s'effectue lors des marées hautes (Voir

annexe 1).

Conjointement au facteur des marées, la contribution des ruisseaux qui dimentent le chenal

du Saint-Laurent entraîne la variation des courants (Voir annexe I ) en sens et en intensité. La

topologie du fond du fleuve intensifie de son côté ces courants. L'avancement des navires est

favorisé ou empêché selon la direction de ces courants. La manœuvrabilité est parfois difficile en

présence des courants forts puisqu'ils ne permettent pas aux navigateurs de garder la direction

prévue de leurs navires. La section du chenal entre Québec et Montréal présente des zones de

forts courants de marées, des chenaux peu profonds et des endroits restreints [l].

Le vent est un autre facteur naturel présent dans la région. Son influence sur Ies grands

navires n'est pas importante. Néanmoins, elle peut être néfaste pour les bateaux de plaisance.

Lors des tempêtes de neige, les vents réduisent considérablement la visibilité qui peuvent

engendrer 1' arrêt de la navigation.

Chapitre 1 : Contexte général

Les marées, les courants ainsi que la topographie du fleuve sont des facteurs qui

perturbent la navigation. Il s'ajoute à cette liste la glace. L'accumulation de grandes quantités de

glace Iors de la période hivernale génère une résistance à l'avancement des navires. Au niveau de

certains passages étroits, cette glace peut générer une congestion qui exige l'intervention des

brises-glace. Aussi, son entassement entraine une augmentation du niveau de l'eau. Des

inondations potentielles peuvent avoir lieu à cause de l'accumulation de la glace en certains

endroits.

Du côté du navire, il faut prendre certains paramètres en considération, entre autres, son

tirant d'eau et son enfoncement dans l'eau. Généralement, plus grandes sont sa vitesse et sa taille,

plus important est son enfoncement dans I'eau. Sous de telles conditions de tailIe et de vitesse, un

passage plus sécuritaire demande un niveau d'eau plus élevé.

Compte tenu des contraintes mentionnées, la navigation sur le Saint-Laurent est rendue

difficile, voire impossible dans certains cas. La sécurité de l'activité est un souci permanent. Les

incidents impliquant les grands navires sont probables. Le dernier en liste est l'échec d'une

croisière en 1999 à côté de la ville de Québec après avoir heurté une dune de sable.

Face à ces problèmes et se souciant d'une éventuelle perte de la confiance des armateurs,

les responsables canadiens du fleuve Saint-Laurent se sont penchés sur l'étude des meilleurs

moyens qui permettent une navigation sure. Plusieurs solutions prometteuses ont été mises en

place. On parle de plus en plus d'une navigation électronique, d'une augmentation des tonnages

des navires et encore mieux d'une navigation sure sans le moindre risque.

État actuel Le port de Montréal détient presque 22% du marché du transport en Amérique du Nord

[l]. Ses principaux concurrents sont New York, Baltimore, Saint-Jean (NB) et Halifax [l]. Les

contraintes de navigation déjà citées peuvent entraîner des retards pour les navires qui veulent

l'atteindre. Cette situation n'est pas en sa faveur en terme de compétitivité.

Pour améliorer la confiance des armateurs, les organismes canadiens tentent de réduire les

délais d'attente des navires et de leur assurer une navigation en toute sécurité. Plusieurs travaux

ont abouti à des recommandations et à des systèmes d'intervention qui sont axés généralement

sur :

- La gestion de la glace : Plusieurs systèmes ont été développés et mis en place pour éviter

toute congestion du chenal à cause de la glace ou encore éviter toute inondation en

10

conséquence. Entre autres, on trouve EPDSS (Environmental Prediction Decision Support

Systern) [9] qui est développé par la GCC-RL (GCC Région Laurencienne), ICENAV et

IceSim.

La prédiction des courants des marées : Le modèle Atlas donne la direction et l'intensité des

courants sur la surface du Saint-Laurent entre Trois-Rivières et Bon-Désir toutes les 20

minutes.

Les recherches sur l'amélioration de la forme du navire surtout au niveau de sa coque dans le

but de résoudre tout problème lié au dégagement sous pi l le . Dans ce sens, la GCC a employé

la technologie GPS-OTF (Global Positionning System On-The-FIy) qui permet de mesurer

directement l'enfoncement de certains navires entre Québec et Montréal. On trouve aussi le

guide de dégagement sous quille UKCG qui est un élément développé et intégré aux systèmes

de gestion du traf̂ xc maritime [Il]. D'autres travaux existent pour la mesure des dégagements

sous quille des navires tel que le projet squat de la GCC [l O].

L'instauration d'une navigation électronique via la technique des Cartes de Navigation

Électronique (CNE) développée par le SHC.

La surveiIlance du trafic sur le chenal. Dans ce contexte la GCC a mis en place le projet AIS

(Surveillance Automatisée d'Identification).

La prédiction des niveaux d'eau. Le système SINECO mis en place par le SHC diffuse les

niveaux d'eau en temps réel et donne des prédictions pour les prochaines heures.

L'utilisation d'un arsenal d'outils sophistiqués tels que les GPS (Système de Positionnement

Global), les radars, les satellites, les caméras de surveillance, les îlots artificiels, etc.

En plus de cet ensemble de systèmes et de projets, il existe le système Sailsafe de la GCC

qui rassemble un certain nombre d'expertises de navigation maritime [6] . On y trouve entre

autres les cartes vectorielles du SHC, les systèmes de positionnement par satellite GPS et le

réseau des niveaux d'eau en temps réel.

Plusieurs systèmes sont mis en place pour la gestion de la navigation dans le Saint-

Laurent. Les cartes de navigation électronique, les GPS, la surveillance automatisée du chenal,

etc. sont des outils employés qui donnent de bons résultats. Néanmoins, deux critiques sont à

signaler. Tout d'abord, la plupart des systèmes traitent une seule contrainte de navigation à la fois

(marées, courants, glace, dégagement sous quille du navire, etc.). En présence de plusieurs

facteurs, les résultats pourraient être non fiables. Dans ce cas une collaboration entre eux

permettra sans doute une meilleure gestion de la navigation sur le chenal. Deuxièmement, l'accès

aux systèmes développés ne se fait que via l'organisme qui en est propriétaire. Les navigateurs

11

Chapitre I : Contexte général

n'ont pas d'autonomie dans la gestion de leurs tâches de navigation. Tout choix de vitesse et

d'horaire leur est imposé.

6. Spécification du projet

6.1 L'initiative MGDI [3] L'initiative MGDI (Marine Geospatiai Data Infrastructure) est lancée dans le cadre de la

mise en œuvre d'une architecture spatio-temporelle standard pour I'infrastmcture des données

géospatiales marines en utilisant un noyau basé sur les modèles de données, des interfaces

d'applications ouvertes et une syntaxe de langage standardisée. Les buts de cette initiative sont :

Fournir une interopérabilité entre les systèmes développés par la mise en œuvre d'une

infrastructure d'informations marines.

Favoriser et appuyer le développement des technologies canadiennes existantes CU en

évolution (CEONet, MID-C, AquaGIS, OGDI, etc.).

Pénétrer dans les marchés internationaux par I'établissement de coopérations avec des

organismes internationaux opérant dans le même secteur d'activité.

Promouvoir la présence canadienne dans l'établissement et l'évolution des standards

internationaux.

La démonstration d'une solution intégrant les informations géospatides, les applications et

les services.

6.2 L'architecture de MGDI [3] L'architecture de MGDI comporte plusieurs composants dont on cite :

Un modèle de données spatiales commun Four assurer la communication entre les

composants logiciels.

Un processus intégré et un environnement de modélisation de données pour assurer une

communication rapide et claire entre les intervenants.

Un langage spatial commun et un format d'échange de données pour garantir un accès ouvert

aux données.

Des mécanismes pour la gestion, l'interrogation et la livraison de données pour sauvegarder

l'intégrité et garantir cette livraison.

Des outils qui garantissent l'accès pour tous les niveaux du public et du gouvernement.

12

Cha~irre 1 : Contexte aénéral

Cette architecture permet le partage des informations par plusieurs applications en

accédant à plusieurs entrepôts de données valables via les communications réseaux. Elle doit

assumer l'interaction des applications avec les bases de données. En outre, elle doit soulever le

problème des systèmes hétérogènes qui devraient partager et accéder aux données communes.

Cependant, cette interaction ne se restreint pas au seul échange de données mais mssi à la

coordination des activités dans le but de fournir un selvice intégré aux usagers.

Pour mettre en œuvre l'architecture système du MGDI, il faut faire le meilleur choix des

outils logiciels de développement. Ces outils devraient faire face aux différents contextes

conceptuels, méthodologiques et techniques tels que :

- L'hétérogénéité des systèmes existants en raison de la diversité de leurs modèles de données

de leurs interfaces.

- La diversité des vocabulaires employés par différentes classes d'utilisateurs.

- La complexité de développer et de maintenir de tels systèmes hétérogènes avec des approches

de conception traditionnelles.

6.3 L'approche multiagent

6.3.1 Les agents

Une des définitions représente l'agent comme étant un programme logiciel autonome qui

possède une base de connaissances reflétant entre autres ses perceptions à propos de son

environnement ainsi que ses capacités. Cet agent interagit avec l'environnement qui I ' ent oure par

le biais de ses détecteurs, ce qui lui permet de mettre à jour sa base de connaissances. À la suite

des excitations résultant du changement de son entourage ou des messages externes, il agit en

conséquence à I'aide de ses efiécteurs'. D'autres définitions et détails sur les agents seront donnés

ultérieurement.

Plusieurs classifications d'agents ont été proposées. Les agents logiciels sont

généralement classés en deux catégories [3] :

- Les agents réactifs : ce sont des agents réagissant à la suite des stimulations de leur

environnement qui peut contenir d'autres agents.

- Les agents délibératifs : ils sont capables de raisonner à propos de leurs objectifs, de diviser

leurs plans d'actions et d'exécuter ces actions s'ils décident de le faire.

-- --

Les moyens qu'a l'agent pour intervenir sur son environnement

13

Chaoitre J : Contexte nénéral

Techniquement, les agents logiciels manipulent habituellement des stmcnires de données

correspondant aux 131 :

- Croyances (beliefss) : ce sont les faits connus.

- Buts (goals) : utilisés pour raisonner à propos des décisions à prendre.

- Artentes (expectations) : pour modéliser les événements ou les états qui sont attendus par

l'agent.

6-32 Les systèmes multiagents

Un système rnultiagent est un ensemble d'agents qui interagissent ensemble dans un

environnement donné pour résoudre un problème qu'ils ne peuvent pas résoudre individuellement

1121. En collaborant avec Ies autres, un agent contribue à la solution en fournissant les

informations qu'il détient et en accomplissant un ensemble de tâches requises qu'il est capable

d'exécuter.

Cette définition évoque Ia notion importante d'environnement qu'il faut spécifier. En

effet, ce dernier offre I'infrastructure des interactions qui auront lieu entre les agents. Cette

infrastructure est exprimée en terme de protocoles d'interaction et de communication. D'autres

notions importantes telles que la capacité de l'agent, sa façon d'agir dans son environnement

ainsi que son degré d'autonomie seront détaillées ultérieurement.

6.4 Les contraintes de la planification des itinéraires

Le développement incessant de l'industrie sur Ie bord du fleuve Saint-Laurent intensifie

davantage Ia navigation et pose de plus en plus de pressions et d'exigences en termes de sécurité

et de tolérance aux retards. Pour répondre aux besoins de cette industrie, les travaux se

concentrent sur une meilleure gestion de la navigation sur le Saint-Laurent. On aimerait bien que

le chenal soit accessibIe par toute sorte de navire, sans souci de sécuriti ni d'attente, surtout pour

l'accès au port de Montréal. Ce sont ces raisons qui font que la planification des itinéraires s'avère

impérative. La question majeure qui doit être résolue est comment peut-on organiser la

navigation de telle façon que n'importe quel navire puisse passer tout au long du chenal en

sécurité et accéder au port de Montréal sans attente ?

Les contraintes qui perhxbent la navigation sur le Saint-Laurent sont de type spatio-

temporel. Elles varient dépendemment du temps et de l'espace. Les marées et les courants sont

dépendants surtout de la lune (Voir annexe 1). De son côté, la topographie du fleuve influence

Chapitre I : Contexte aénéral

leurs intensités. Elle fait de même varier le niveau d'eau. Lors de la période hivernale,

I'accumulation de la glace vient s'ajouter aux contraintes de navigation.

Les caractéristiques du navire doivent être prises en considération dans le but de savoir si

le passage du navire par certains endroits est possible ou non. Ces caractéristiques sont aussi

importantes pour gérer les vitesses des navires afin d'empêcher toute éventualité d'inondation des

habitations et des installations sur le bord du fleuve surtout en présence de la glace.

La planification des itinéraires doit non seulement prendre en considération les contraintes

citées auparavant mais gérer aussi les contraintes résultantes de la présence de plusieurs navires

dans le chenal. Dans le cas du croisement de plusieurs navires en un point donné du fleuve, il faut

éviter toute collision probable et gérer les vitesses à ces fins. Pour ce faire, des informations

pertinentes sur les niveaux d'eau, sur la largeur du fleuve ainsi que sur les coordonnées des autres

navires doivent être fournies en temps réeI.

En plus des objectifs mentionnés de la planification des itinéraires, il faut gérer l'accès au

port de Montréal. Ce dernier est très sollicité par les navires qui sont obligés parfois d'observer

des attentes d'autorisation de longues durées avant d'y accéder. La planification des itinéraires

doit prendre en considération le problème de congestion du port et organiser la navigation afin

d'éliminer au mieux ce problème ou bien réduire ses impacts.

6.5 Besoins des usagers Plusieurs secteurs d'activités partagent I'utiIisation du fleuve Saint-Laurent. L'industrie de

l'énergie, du fer et du bois en sont des exemples. Le développement de ces industries entraîne des

nouvelles exigences de la part des usagers en terme de fiabilité et de sécurité de la navigation sur

le Saint-Laurent. Plus de vraquiers et de marchandises empruntent la voie navigable du fleuve.

La planification des trajectoires des navires ainsi que tous les travaux de gestion de la

navigation sur le Saint-Laurent doivent répondre aux différents besoins des usagers qu'on résume

dans les points suivants :

- Garantir la sécurité des navires si grands soient-ils le long du chenal et en présence de

n'importe quelle contrainte.

- Réduire au minimum les retards engendrés par les contraintes de navigation sur les voyages

des navires.

- Faciliter l'accès au port de Montréal ou réduire au minimum les délais d'attente pour y

accéder.

Chapitre I : Contexte ~énéral

- Posséder au bord du navire des moyens de prédiction et d'aide à la décision qui supportent le

navigateur pour faire passer en toute sécurité son navire. Les informations demandées doivent

être fournies en temps réel ou dans les meilleurs délais.

- Avoir plus d'autonomie vis-à-vis des solutions proposées.

- Avoir des informations pertinentes sur le voyage des navires telles que sa durée, l'heure

d'arrivée ainsi que des suggestions concernant l'heure de départ et la vitesse.

En résumé, la planification des itinéraires doit prendre en considération routes les

contraintes de navigation. Elle doit organiser la navigation pour garantir une sécurité maximale

des navires et un accès facile au port de Montréal. Elle doit aussi réduire les retards enregistrés le

long des voyages. L'utilisation des solutions proposées pour effectuer la tâche de planification

doit se fixer l'objectif de donner Ie plus d'autonomie possible aux navigateurs.

6.6 Objectifs du projet

Au fil des paragraphes précédents, plusieurs caractéristiques qui marquent la navigation

sur le Saint-Laurent ont été mentionnées. Nous avons notamment invoqué l'importance de la

navigation et ses contraintes ainsi qu'un ensemble de solutions proposées par différents

organismes canadiens pour y faire face. Ces solutions permettent certes une bonne sécurité pour

les navigateurs, mais ignorent un aspect important en matière d'autonomie à accorder aux

navigateurs. Nous avons invoqué aussi les besoins des usagers vis-à-vis de la navigation sur le

Saint-Laurent.

Le présent projet se place dans ce contexte de navigation. Ii se concentre sur la

planification des trajectoires des navires sur le fleuve Saint-Laurent et plus précisément dans la

section du fleuve entre Québec et Montréal. Un navire désirant quitter le port de Montréal

pourrait connaître l'allure de sa trajectoire et son heure d'amvée en spécifiant quelques

paramètres tels que sa vitesse et son heure de départ. Le projet vise, aussi, le couplage dans un

seul système de plusieurs solutions conçues chacune pour remédier à l'une des contraintes de

navigation mentionnées. Cette approche améliorerait, certainement, les précisions des calculs et

la gestion de la navigation sur le chenal. Pour ce faire, on a opté pour la technologie des systèmes

multiagents. On montrera que cette technologie est belle est bien adaptée au contexte des

applications marines, généralement hétérogènes. En outre, le système proposé par ce projet vise à

donner plus d'autonomie aux navigateurs qui deviendront dans la nouvelle configuration ses

partenaires interactifs. De plus, nous voulons que notre système aide ces navigateurs en leur

Chauitre I : Contexte ~énéral

fournissant des suggestions quant aux horaires de départ de leurs navires afin d'éviter les zones

risquées du fleuve.

II. Technologie choisie

1. Agents logicieis et Systèmes Multiagents

2. Bee-gent

3. Java

4. Matlab

5. Conclusion

1. Agents logiciels et Systèmes Multiagents

1.1 Introduction Le concept d'agent a fait son apparition depuis bien d'années dans plusieurs disciplines.

Entre autres, il est fortement présent dans le domaine de l'intelligence artificielle, de la robotique

ainsi que dans d'autres domaines ne touchant pas à l'informatique tels que la psychologie. Cette

utilisation multiple et étendue des agents a généré plusieurs définitions. Ces définitions sont

relatives à ce que l'agent est capable de faire, à son environnement, & son autonomie, etc. C'est

ainsi que certains utilisateurs présument que t'agent doit être intelligent et d'autres présument

qu'il doit être autonome. L'agent doit décider comment agir sans aucune intervention extérieure.

1.2 Les agents logiciels

1.2.1 Définitions

Compte tenu de I'absence d'une définition standard, on donnera dans la suite un ensemble

de définitions d'agent logiciel telles que proposées par divers auteurs.

a- DéFrnition 1 [13]

Un agent logiciel est un programme dont l'exécution est régie par des conditions sur les

données ainsi que par des événements se produisant dans son environnement. Ce programme

n'est pas sous le contrôle direct et continu d'un utilisateur humain.

On note dans cette définition le fait que :

- L'auteur accorde un degré d'mtononiie à l'agent.

- L'agent peut agir selon ses connaissances propres parce que le contrôle qu'il subit n'est pas

continu.

b- Définition 2 [14]

Un agent est une entité autonome capable d'agir sur elle-même et sur son environnement

et qui peut communiquer avec d'autres agents dans un univers multiagent. Le comportement de

l'agent est conséquence de ses observations, de ses connaissances et de ses interactions avec les

autres agents.

Chapitre 2 : Technobaie chorkit-

Cette définition dote l'agent des capacités d'autonomie, du pouvoir d'action, de

communication ainsi que de perception.

c- Définition 3 1141

Un agent est un système informatique situé dans un environnement. Il agit de façon

autonome et fiexible pour atteindre les objectifs pour lesquels il a été conçu.

Cette définition accorde à l'agent les qualités d'autonomie et de flexibilité en terme de

réponses, de prise de décision et d'action. Le qualificatif "situé" fait que l'agent est conscient de

son existence dans son environnement et qu'il est capable d'agir selon ce qu'il détecte par le biais

de ses entrées sensorielles.

Pratiquement toutes Ies définitions des agents logiciels ont au moins un point en commun

: l'agent est considéré comme quelque chose qui agit ou peut agir.

1.2.2 Les propriétés des agents [14]

L'utilisation des agents dans diverses disciplines a permis de dégager un ensemble de

propriétés que peuvent avoir ces agents. Plusieurs travaux ont dressé des listes de propriétés qui

ne sont pas les mêmes quoiqu'elles soient en accord sur certains points. Toutefois, on peut classer

les propriétés des agents en quatre groupes (Figure 2.1). Le premier groupe concerne l'âgent et

rassemble ses caractères intrinsèques et extrinsèques. Le second identifie les propriétés du

système multiagent. Le troisième groupe s'intéresse aux propriétés du cadre d'exécution de

l'agent. Finalement, le dernier groupe concerne l'environnement d'exécution de l'agent.

1 PLp>étés des agents I

Propriétés extrinsèques

Figure 2.1 : Les prcrpriétis des agents.

Cha~itre 2 :Technobaie choisie

Les propriétés intrinsèques et extrinsèques des agents sont résumées dans les deux

tableaux suivants :

1 Propriété 1 Valeurs de la propriété 1 Durée de vie

Architecture

Mobilité

Construction

Adaptabilité

De transitoire à longue

Réactive ou délibérative

Fixe ou itinérante

Déclarative ou procédurale

Fixe, ajustée ou autodidacte

Tableau 2.1.1 : Propriétés intrinsèques des agents.

1 Propriété

Endroit

Sociabilité

Autonomie sociale

VaIeurs de la propriété

Local ou distant

Autistique, responsable ou conscient

Indépendante ou contrôlée

Coopératif, compétitif ou antagoniste

Logistique : direct ou via des intermédiaires

Sémantique : communication déclarative ou

procédurale

Tableau 2.1.2 : Propriétés extrinsèques des agents.

Généralement, un agent n'est pas conçu pour opérer tout seul dans son environnement. Il

est certes capable de résoudre un certain nombre de problèmes, mais il serait incapable

solitairement de donner la solution d'un probIème complexe. C'est la raison d'être de systèmes

rassemblant une société d'agents qu'on nomme systèmes multiagents.

Chu~irre 2 :TechnoIonie choisie

1.3 Les systèmes multiagents

1.3.1 Présentation générale

Un système multiagent est un système distribué qui renferme plusieurs agents en

interaction. La coexistence, la concurrence, la coordination, la négociation ainsi que la

coopération entre les agents caractérisent de tels systèmes. Les agents s'entraident pour résoudre

un problème qu'ils sont incapables de résoudre individuellement. Chaque agent possède une

connaissance partielle du problème à résoudre. Ses capacités sont par la suite limitées. Tout seul,

il n'est capabIe que de contribuer à une partie de la solution.

Les systèmes multiagents fonctionnent sans contrôle global. C'est la coopération entre les

agents et les qualités que ces derniers possèdent qui orientent son exécution. Dans ce cadre, un

agent donné peut refuser ou accepter la requête de demande de service qui lui parvient d'un autre

agent. Aucune intervention externe n'est faite pour orienter le fonctionnement des agents- De ce

fait, les traitements et les calculs qui se font dans les systèmes rnultiagents sont asynchrones. Ces

systèmes sont aussi caractérisés par leurs données décentralisées.

Les systèmes multiagents possèdent plusieurs avantages tels que la facilité de

maintenance et l'extensibilité. Ils présentent des schémas d'interaction permettant la coopération,

la coordination ainsi que la négociation [14]. Pour pouvoir tirer profit de ces avantages. il faut

soulever un bon nombre de défis qui sont inhérents à la conception et à l'implantation de ces

systèmes multiagents. Ces défis concernent [14] :

La formulation et la description des problèmes.

La synthèse des résultats.

La façon de faire communiquer les agents.

L'assurance de la cohérence dans les actions des agents. Pour ce faire, il faut prendre en

considération les actions et les décisions des agents, gérer les effets de leurs décisions et

éviter les interactions nuisibles.

La coordination entre les agents. Il faut permettre à l'agent de raisonner sur les actions et les

plans des autres agents pour qu'il puisse se coordonner avec eux.

La gestion de la répartition des ressources limitées.

L'établissement d'un compromis dans le cas où les buts des agents se trouveraient bloqués i

cause de leurs incompatibilités ou de la concurrence. Ii faut décider des traitements qui seront

affectés à un seul agent et des traitements distribués entre plusieurs agents.

Chapitre 2 :Technoloaie choisie

- L'élimination des effets indésirables qui nuisent au comportement du système global.

- La conception des plates-formes technologiques et méthodologiques de développement pour

les systèmes multiagents.

1.3.2 Les propriétés des systèmes multiagents

Un système multiagent possède un ensemble de propriétés qui portent sur l'autonomie, la

structure de contrôle, la granularité et l'unicité. Ces propriétés sont indépendantes de celles des

agents composant le système.

I Propriété

Unicité

Granularité

Structure de contrôle

Autonomie d'interface

1 Autonomie d'exécution

Valeurs de la progriiité

Homogène ou hétérogène

De fine à grosse

Hiérarchique ou démocratique

Communication : vocabulaire spécifique, langage, protocole

Habilités : buts, croyances, procédures, ontologies

Indépendant ou contrôlé

Tableau 2.1.3 : Propriétés des systèmes mu1 tiagents.

L'autonomie peut être relative à l'interface que propose le système multiagent ou à

l'exécution. Dans le premier cas, elle concerne la communication et les habiletés. Ainsi, un

nouvel agent voulant accéder au système multiagent en place devra être conforme au protocole,

au langage ainsi qu'au vocabulaire employés par le système. L'autonomie d'exécution est définie

par le degré de liberté que possède un agent lors de son exécution. La propriété de structure de

contrôle concerne la manière avec laquelle le système gère sa société d'agents. Le système

impose une structure de contrôle qui peut être démocratique autorisant l'agent à agir librement ou

hiérarchique imposant aux agents un certain ordre lors de l'exécution. En ce qui concerne la

propriété de granularité, elle est définie par le degré de détails des informations manipulées par le

système. Finalement, l'unicité d'un système multiagent s'étend d'homogène à hétérogène. Il est

qualifié d'homogène si tous les agents se ressemblent et possèdent les mêmes propriétés. Dans le

cas contraire, le système est dit hétérogène. Le tableau suivant résume les propriétés des systèmes

multiagents précédemment évoquées [14].

Cha~itre 2 :Technoloaie choisie

Un agent s'exécutant dans un système multiagent donné profite des qualités et des

propriétés que ce système lui offre. De plus, il est influencé par les caractéristiques de son

environnement d'exécution. Il serait donc judicieux d'énumérer les propriétés de cet

environnement telles que proposées dans 1141 (Tableau 2.1.4).

L'environnement d'exécution des agents fournit l'infrastructure qui spécifie les protocoles

d'interaction et ceux de communication des agents. Les premiers protocoles permettent aux

agents d'interagir alors que les autres assurent Ia compréhension des messages.

Propriété

1 d'interaction

Vaieurs de la propriété

Autonomie de conception Langage, architecture interne, plate-forme et protocole

Infrastructure de

communication

Protocole de

communication

Tableau 2.1.4 : Propriétés de l'environnement des systèmes muitiagents.

- Mémoire partagée

- Point à point, multidiffusion ou diffusion générale

- Connexe ou non connexe

- Synchrone ou asynchrone

- KQML

- HTTPetHTML

- OLE, CORBA, DCOM

Sécurité

Support des opérations

Services de médiation

1.4 Interaction, coopération, coordination et négociation entre les

~ s t a m ~ i l l e , authentification

Archivage, redondance, restauration, . . . Transactionnels ou basés sur l'ontologie

agents

Dans un système multiagent, les agents coopèrent en vue de réaliser une tâche qu'ils sont

incapables de faire individuellement. Cette coopération est concrétisée par l'interaction des agents

qui communiquent directement ou par I'interrnédiaire d'autres agents.

Un agent est souvent caractérisé par ses ressources, ses capacités à réaliser certaines

tâches ainsi que par ses buts. Les conflits entre les agents sont possibles. Ils sont centrés sur les

24

Chaoitre 2 :Technoluaie choisie

buts qui peuvent êtrc incompatibles ou sur l'accès aux ressources partagées et limitées.

L'interaction permet à un agent donné de demander l'aide d'un autre agent pour qu'il puisse

réaliser son plan d'action. Elle permet, en outre, la gestion des éventuels conflits. Ferber [15]

classifie l'interaction en plusieurs types. Entre autres, elle peut être une collaboration simple, une

compétition individuelle, etc.

L'implantation de la coopération dans un système multiagent présente un grand degré de

complexité. Il faut non seulement gérer les ressources limitées et les éventuels blocages dus aux

buts probablement incompatibles, mais, aussi, il faut prendre en considération le coût de la

communication réseau. La coopération entre les agents est traduite par un échange de messages.

Cette communication peut ralentir, voire congestionner le réseau si elle est intense.

Dans un système multiagent ou un système distribué, les agents doivent coordonner leurs

efforts pour mener B terme la résolution du problème posé. En l'absence de cette coordination, le

comportement des agents peut générer une situation chaotique. Mintsberg a proposé trois

processus principaux de coordination [16] : I'ajustement mutuel, la supervision directe et la

coordination par standardisation. Dans le cas de l'ajustement mutuel les agents partagent les

ressources et font en cas de nécessité des ajustements à leurs propres comportements. La

supervision directe s'explique par le fait qu'un agent possède un contrôle sur les autres agents du

système. ll gère, ainsi, l'accès aux ressources partagées. Cet agent peut aussi imposer certains

comportements. Dans le cas de la coordination par standardisation un agent joue le rôle de

superviseur. Dans des situations reconnues, il coordonne les activités en établissant les

procédures que les autres agents doivent suivre.

La coordination s'appuie généralement sur l'allocation des ressources rares et la

communication des résultats intermédiaires. Dans des systèmes complexes ces deux tâches

deviennent difficiles à gérer. Une solution est que le système multiagent devra posséder un agent

centralisateur qui détient les informations pertinentes sur les autres agents telles que les intentions

et les buts à réaliser.

La coopération et la coordination entre les agents peuvent déboucher sur des situations

conflictuelles. L'incompatibilité des buts, l'absence de capacités suffisantes ainsi que l'accès aux

ressources limitées en sont des causes possibles. Pour débloquer tout conflit possible, les agents

entament des négociations en vue d'établir des accords sur les plans d'action ou les points de vue

communs. Cette négociation est concrétisée par un échange d'informations pertinentes. Elle est

assurée par des protocoles de communication dont le plus connu est le protocole du réseau

contractuel (Con tract-Net).

Chapitre 2 : Technoloaie choisie

La négociation peut être effechiée directement par les agents concernés ou par

l'intermédiaire d'autres agents médiateurs. À titre d'exemple, un agent représentant des employés

peut négocier directement la hausse des salaires avec un deuxième agent représentant les patrons.

Cette négociation peut êîre indirecte si un troisième agent représentant le syndicat intervient en

faisant la médiation entre les employés et leurs patrons.

1.5 Communication entre les agents L'interaction entre les agents est accomplie via des procédures de communication qui

peuvent être de type linguistique ou non. Le premier type qualifie la corninunication entre les

agents alors que le second qualifie Ies actions entreprises par un agent pour modifier son

environnement. La communication permet aux agents de coordonner leurs activités, d'échanger

des informations et d'organiser les accès aux ressources.

Dans Ies systèmes multiagents, la communication entre les agents se fait selon deux

stratégies. Elle peut être directe ou via un tableau. Ce tableau permet aux agents entre autres

d'obtenir de l'information, insérer des résultats et écrire des messages. Les messages échangés

entre les agents sont porteurs d'information. Dans le cas de la communication directe, les agents

peuvent échanger leurs plans d'action en totalité. Cette approche présente plusieurs

inconvénients. En plus du coût de la communication, sa mise en œuvre est difficile en raison des

incertitudes concernant les états actuels et futurs de I'environnement et des actions présentées

dans les plans.

En pratique, l'établissement à l'avance des plans d'action est quasi impossible. Ainsi, au

lieu d'échanger des plans, on échange des stratégies générales. On met plus l'accent sur la

communication des agents via des protocoles établis. La difficulté de cette approche vient des

caractéristiques des agents. Il faut que les protocoles offrent des procédures et des syntaxes

compréhensibles par tous les agents et comprises de la même façon.

Les conversations qui se font lors de l'échange des messages utilisent des langages tels

que KQML et ACL. Ces derniers définissent un ensemble de types de messages appelés

performatifs [23]. Ces performatifs définissent les types des requêtes envoyées d'un agent à un

autre. Une requête peut être, entre autres, une demande d'information, une information livrée sur

demande, une acceptation ou un rejet de service.

1.6 Apports des systèmes multiagents L'approche multiagent est généralement employée pour la conception des systèmes

complexes. Particulièrement, dans le cas d'une population d'agents hétérogènes ou possédant des

Cha~itre 2 :Technolonie choisie

buts conflicniels, les systèmes multiagents sont bien appropriés. Cette approche permet la

réutilisation des applications existantes. En effet, même en présence d'hétérogénéité entre ces

applications, on peut leur affecter des agents qui les encapsulent et qui assurent leurs

communications avec le reste du système. Cela diminue considérablement le coût de

développement et de modifications à apporter à ces applications dans le but de les faire

communiquer.

Un autre avantage des systèmes multiagents concerne la vitesse d'exécution du système

global. En effet, cette technologie facilite le traitement parallèle des tâches. Chaque agent prend

en charge l'exécution d'une partie du système global puis fournit un éliment de solution. Ce

travail peut être exécuté indépendamment des autres tâches et en même temps. C'est ainsi que

tout système pouvant être décomposé en un ensemble de composants indépendants peut

bénéficier de l'approche rnultiagent.

Les systèmes multiagents offrent, en général, une bonne qualité de robustesse. Ils

contiennent, éventuellement, des agents redondants. Cette configuration tolère l'échec d'un ou

plusieurs agents : les agents redondants qui sont logés sur des machines différentes assurent la

continuité du bon fonctionnement du système global.

Un aiitre avantage important de la technologie multiagent est l'extensibilité. Les systèmes

multiagents sont généralement ouverts et extensibles. On peut ajouter autant d'agents qu'on veut.

Les systèmes dont les paramètres et les capacités sont en évolution constante peuvent profiter de

l'approche multiagent.

Du côté de la programmation, le développement d'un système multiagent se caractérise

par la modularité. Le programmeur identifie les différents sous-tâches du système et les affecte à

des agents. Le développement peut ainsi évoluer sur différents volets et de façon parallèle.

1.7 Systèmes distribués et Systèmes multiagents Un système distribué est une cdlection de machines autonomes qui donne l'illusion aux

utilisateurs de travailler avec un seul système. Ces machines sont interconnectées par des réseaux

pouvant être hétérogènes et indépendants. Les applications, Zn collaboration, qui sont logées sur

ces machines sont assimilées à un système distribué. Elles coopèrent en échangeant des messages

pour former une seule machine virtuelle.

Les problèmes qui sont inhérents à la coopération des composants d'un système distribué

résultent entre autres de l'hétérogénéité des réseaux ainsi que des langages de programmation qui

sont parfois incompatibles. C'est ainsi que plusieurs applications d'un système distribué ne

C h a ~ f t E 2 :Technologie choisie

peuvent pas coopérer facilement quoiqu'elles soient complémentaires comme dans le cas où elles

n'utilisent pas les mêmes formats de données ou les traitent avec des vitesses différentes

entraînant des blocages.

Dans un environnement complexe, plusieurs systèmes peuvent coexister offrant chacun

un élément de solution. Sous certaines contraintes, les échanges d'information sont difficiles,

voire impossibles, de façon automatique à cause de l'hétérogénéité que présentent ces systèmes. Il

en résulte qu'on alimente ces systèmes par les données requises de façon manuelle ou semi-

automatique. Dans d'autres cas, la conception et l'implantation de certains systèmes ne prennent

pas en considération la coopération des autres. Cette configuration ne permet pas une utilisation

optimale de ces systèmes. Il s'ensuit que la réutilisabilité est faible et qu'on a recours à

l'acquisition de nouvelles solutions ou au redéveloppement d'une grande partie de ces systèmes.

On aimerait bien, donc, regrouper les éIéments de solutions pour former un système unique

permettant de couvrir toute la solution. La question qui se pose à ce niveau : Est-ce que cette

tâche est faisable et avec quelle approche ?

L'approche multiagent répond à cette question et est bien adaptée à ce contexte. Chaque

agent du système est affecté à une application existante. Il assure la communication avec elle et

se présente par la même occasion comme une interface qui assure les échanges d'information

avec le reste du système global. Dans cette architecture, les agents communiquent ensemble par

le biais des protocoles utilisés par le système multiagent. Quant à la communication entre l'agent

et l'application, elle se fait selon les possibilités offertes par le langage de programmation de

l'agent et par celui de l'application. C'est pour cette raison qu'il est important de choisir un

langage de programmation des agents qui soit portable et compatible avec un plus grand nombre

possible de langages.

1.8 Utilisation de I'approche multiagent dans le domaine des

applications marines L'apport majeur de l'approche multiagent dans le cas de plusieurs systèmes

complémentaires et hétérogènes qu'on veut faire communiquer, c'est qu'elle permet une meilleure

réutilisation des applications existantes. Dans le domaine de la navigation maritime, la

planification des trajectoires des navires est régie par un ensemble de contraintes. E ~ t r e autres, il

faut prendre en considération les phénomènes des marées, des courants, de la glace ainsi que des

caractéristiques des navires. Certes, les solutions proposées telles que la prédiction des niveaux

d'eau en temps réel et la mesure du dégagement sous-quille des bateaux sont complémentaires.

Chmitre 2 :Technolwie choisie

Mais, elles sont hétérogènes aussi bien au niveau des langages de programmation qu'au niveau du

matériel employé. L'utilisation de l'approche multiagent est bien appropriée pour faire coopérer

l'ensemble des solutions sous un seul système. Ainsi, à chaque système est attribué un agent avec

lequel il communique et via lequel il échange les informations avec les autres systèmes. La

cohabitation de I'ensemble des systèmes donne un système distribué qui permettra d'offrir une

solution complète aux contraintes de navigation (Figure 2.2). La planification des itinéraires

bénéficie bien de l'apport de l'approche multiagent. La coopération des différents systèmes

Dermet d'évaluer les impacts de toutes les contraintes et bien gérer cette tâche de planification.

Système de 1 prédiction du Agent 1 niveau d'eau I

Agent 4 prédiction des

Système /+-l ( Agentn concernant le 1

navire

Figure 2.2 : Application de l'approche multiagent dans le domaine des applications marines.

Remarque : L'architecture du système multiagent proposée par la figure ci-dessus représente un

cas possible. Tl est 2 noter qu'elle n'est pas optimale et qu'elle vise à illustrer des communications

possibles entre différents agents et différents systèmes de gestion de contraintes de navigation.

L'emploi de l'approche rnultiagent pour la résolution du problème de planification

d'itinéraires pose un certain nombre de questions. Quels sont les agents qui devront être

Cha~itre 2 :Technulupie choisie

développés et affectés aux systèmes existants et avec quels langages devront-ils être implantés ?

Comment va-t-on assurer la communication entre ces agents et ces systèmes ? On s'interroge

également sur la façon de fonctionner du système global ainsi que sur les types de

communications qui seront établies entres les agents.

1.9 Conclusion La notion d'agent ne possède pas, jusqu'à date, une définition standard. Plusieurs auteurs

lui attribuent des définitions selon ce que I'agent est capable de faire dans son domaine

d'utilisation. Cette absence de définition standard n'affecte aucunement l'importance des agents.

Ses utiiisations diverses, non seulement dans le domaine informatique mais aussi en médecine, en

psychologie, etc. lui attribuent de nouvelles qualités et performances.

Dans la mesure où un agent n'est pas toujours capable de résoudre tout seul un problème dans

lequel il est impliqué, il a besoin de coopérer avec d'autres agents dans le cadre d'un système

multiagent. Ces systèmes présentent plusieurs avantages. Citons, entre autres, la vitesse

d'exécution, la robustesse, la modularité et l'extensibilité sans oublier le fait que ces systèmes

permettent l'utilisation des appIications existantes ( 5 1.6).

Ce dernier point est fort important. En effet, l'hétérogénéité entre les applications

existantes est un problème qui les empêche de coopérer quoiqu'elles soient complémentaires.

Cette hétérogénéité est coûteuse. En effet, dans plusieurs cas, la solution adoptée est le

développement d'une partie de ces applications. Avec les systèmes multiagents, on peut

concevoir un système global dans lequel ces applications collaborent. Cette approche est réalisée

en affectant à chaque application un agent qui I'encapsule. La communication entre les différents

agents est supportée par le protocole adopté par le système multiagent. Il reste à assurer la

communication entre l'agent et l'application qu'il encapsule. Ceci est garanti grâce à un bon choix

du langage du développement de l'agent.

Un exemple de domaine dans lequel le problème d'hétérogénéité existe est la navigation

sur le fleuve Saint-Laurent. Cette navigation se heurte à plusieurs perturbations dues aux

nombreuses contraintes qui règnent dans le chenal. Plusieurs solutions ont été développées pour

ce problème. Certes elles sont efficaces, mais leur degré de collaboration est quasi-nul.

Pour garantir une meilleure gestion de la navigation, il est intéressant d'appliquer

l'approche multiagent et évaluer ses performances dans le domaine des applications marines.

Cette approche semble donner tous les atouts nécessaires à la collaboration de ces applications.

Chu~itre 2 :Technologie choisie

La question qui se pose à ce niveau : Quelles sont les meilleurs outils qu'on peut utiliser pour

tester l'approche multiagent dans ce domaine ?

2.1 Introduction Bee-gent est un frarnework qui permet un développement aisé et rapide de systèmes

multiagents. consiste en 17agenti!cation de toute forme de communication entre agents par le

biais d'agents mobiles qui prennent en charge le transport de tout message vers sa destination.

Bee-gent est un moyen de conception de systèmes distribués flexibles et ouverts pouvant utiliser

toute application déjà existante.

Bee-gent propose une interface agent via laquelle une application donnée s'interface avec

le reste du système. Cette approche permet une solution fiable pour la communication réseau

entre différentes applications logicielles incompatibles (Figure 2.3).

Agent wrapper Agent m,t!diateur Agent Yrapper

component-ware

Agent wrapper

Figure 2.3 : Interconnexion d'applications réseau sous Bee-gent.

2.2 Le framework Bee-gent

Bee-gent est doté de deux types d'agents : - L'agent wrupper : il permet d'agentifier les applications existantes.

- L'agent médiateur: il supporte Ia coordination inter-application en assurant la

communication entre des agents wrappers.

Un agent wrapper gère l'état de l'application qu'il encapsule. Il prend en charge la

communication avec cette application ainsi que l'activation des traitements requis. Il traite les

échanges de communication inter-applications en recevant ou en gérant les requêtes qui seront

communiquées au reste des agents du système par le biais des agents médiateurs.

Les agents médiateurs se déplacent d'un site d'une application 2 un autre transportant

avec eux les requêtes générées par les agents wrappers. Leurs tâches ne se limitent pas au

transport des messages, en effet, ces agents peuvent connaître les natures des requêtes et

déterminer la meilleure course d'action.

1 Applicatioq existante 1 1 . Agent wrapper 1

Application Agent médiateur agent A

Application agent B

Figure 2.4 : Frarnework du Bee-gent.

2.3 Caractéristiques de Bee-gent - Toute modification de la configuration du système ne se répercute pas sur les interactions de

coordination qui sont désormais encapsulées. L'agent médiateur gère ces interactions entre

les diverses applications d'une manière unique dans le but de simplifier le développement et

d'éviter tout traitement individuel sur la base des caractéristiques d'une application.

- Réduction du trafk sur le réseau. En effet, toutes les communications inter-agents sont

locales. L'agent médiateur migre sur le site de l'agent wrapper concerné par la

Chvitre 2 :Technolopie choisie

communication et entame l'échange de messages et de requêtes requis. Il transporte avec lui

lors de cette migration son propre programme, ses propres données ainsi que son état courant.

- Les agents wrappers proposent des interfaces uniformes communes permettant une

interopérabilité large entre Ies applications. Par le biais de cette technique, le développeur,

sous Bee-gent, peut concevoir des systèmes ouverts de grande échelle vu que la tâche de

communication et d'interfaçage sont assumées par les agents médiateurs et les agents

wrappers.

- Les agents wrappers agenfifient les applications existantes. Cette stratégie permet la

protection de haut niveau des informations en contrôlant juste les requêtes en provenance des

agents. L' interaction inter-agents peut changer de façon flexible dépendemment de la

situation parce que la communication utilise le langage ACL (Agent Communication

Language).

- Les méthodes de communication et d'échange d'informations sont compatibles avec les

applications Intemet. En effet, la migration et la communication des agents médiateurs

adoptent le protocole H ï l T . D'un autre côté, Bee-gent se base sur XMUACL (extensible

Markup Language/Agent Communication Language) comme format de représentation d' ACL

en tant que langage de communication entre agents.

- Bee-gent utilise un système de sécurité et d'authentification «digital fingerpnnt» basé sur le

cryptage de clés secrètes.

- Bee-gent est conforme au standard de la technologie des agents F P A (Foundation for

Intelligent Physical Agents) qui est une agence internationale de standardisation pour la

technologie des agents.

2.4 Architecture de Bee-gent

Bee-gent utilise Java TM (JDK1.1 et versions postérieures). II possède une bibliothèque de

classes Java qui offre des fonctionnalités de communication et de migration pour les agents

wrappers et les agents médiateurs. Leurs actions peuvent être reprises sur des diagrammes de

transition. Bee-gent offre l'outil RAD (Rapid Application Developrnent) pour la conception de

patron (pattern).

Chmitre 2 :Technolo~ie choisie

La structure interne de Bee-gent montre la disposition en couches suivante :

?

Propiam Generat ion M d i m Agrt

- - - -- -

Figure 2.5 : Structure de couches de Bee-gent.

L'architecture type de Bee-gent peut être résumée par la Figure 2.6. Sur un site A donné,

un agent wrapper encapsule une application et lui offre une interface via laquelle les échanges

d'informations et de requêtes seront faits. D'autres agents wrappers feront de même sur d'autres

sites avec d'autres applications à interconnecter dans le système à concevoir. Les agents

médiateurs gèrent les communications entre les différents agents wrappers des différents sites.

Mediation Agents

Figure 2.6 : Architecture type de Bee-gent.

34

Cha~itre 2 :Technoloaie choisie

2.5 Frameworks de développement d'objets distribués Les frameworks visent la conception de systèmes distribués ouverts qui permettent

l'utilisation et l'interconnexion des applications existantes aussi hétérogènes soient-elles. Cette

interconnexion n'est pas le seul objectif à mettre en œuvre. La coordination entre ces applications

est primordiale pour exploiter au mieux les services qu'elles peuvent offrir. CORBA, JINI et

Bee-gent sont des exemples de frameworks de développement de systèmes distribués.

CORBA : En CORBA la communication entre objets hétérogènes se fait en transformant les

messages en une interface standard.

Figure 2.7 : Communication inter-agenfs sous CORBA.

JINI : Dans le modèle de communication JINI les destinations de la connexion sont vues comme

des serveurs mandatés qui assurent la sécurité @roxys) et avec lesquels cette communication sera

faite à distance.

Figure 2.8 : Communication inter-agents sous JI NI.

Bee-gent : La communication sous Bee-gent se fait par le biais des agents médiateurs qui migrent

sur les sites où résident les applications sollicitées. Ces agents sont dotés de procédure de

coordination. Ils peuvent savoir quoi faire avec tel ou tel objet et connaître le site de l'application

concernée.

Chauitre 2 :Technolo~ie choisie

- - - -

Figure 2.9 : Communication inter-agents sous Bee-gent.

2.6 Liste des fonctionnalités (Comparaison)

Le tableau ci-dessous représente la liste des fonctionnalités de Bee-gent, CORBA et JINI.

1 Fonctionnalité 1 Bee-gent 1 CORBA

1 Agents mobiles I - 1 Communication inter-agents I

I

Communication asynchrone 1 x 1 x

l

Disponibilité avec les applets 1 x I Espace de données partagé X

/ Sécurité 1 Partielle 1 Partielle

Indépendance avec les langages de programmation

Tableau 2.2.1 : Comparaison des fonctionnalités de Bee-gent, CORBA et JINI.

2.7 Concepts de base de Bee-gent

I

Protocole d'interaction

Un protocole d'interaction définit le comportement des différents

X

agents

X

qui concourent à

la réalisation d'une tâche donnée. Ce comportement est défini par des interactions basées sur les

échanges de messages entre agents. Le protocole d'interaction résume donc l'ensemble

d'interactions et de conversations entre agents wrappers et médiateurs. II est basé sur les deux

concepts d'état et de transition (Figure 2.10).

Chu-vitre 2 :Technologie choisie

Action

Action

Action €3 Action to

Figure 2.10 : Protocole d'interacîion.

Chaque agent possède un état courant. II exécute une action donnée si sa précondition

coïncide avec son état courant. Il passe ainsi à un nouvel état. Ce passage est une transition. Le

protocole d'interaction est donc défini par la spécification des préconditions des états possibles,

les actions ainsi que les règles d e transition.

Précondition

Une précondition est une condition préalable. Une fois que l'agent satisfait cette précondition, il

exécute l'action définie dans son état et transite vers un nouvel état.

Action

Une action est un traitement local au sein d'un même agent ou c'est une interaction définie sous

forme de conversation (envoi ou réception de messages XMUACL).

Règle de îransition

Une règle de transition définit l'état avec lequel un agent doit transiter conformément au résultat

de 1 ' exécution d'une action donnée.

Cha~itre 2 :Technologie chokie

2.8 Conversations XMLJACL La conversation entre les différents agents de Bee-gent se fait par le biais du langage ACL

(Voir annexe 2). La structure logique d'une de ses expressions est représentée par XML. C'est la

raison pour laquelle la communication sous Bee-gent est nommée XMUACL. ACL possède les

caractéristiques suivantes :

- C'est un langage qui représente les intentions. - Il possède des protocoles qui spécifient les flots de conversations.

- Il possède des performatifs qui représentent les intentions des messages. On cite à titre

d'exemple inform, query et request. Les autres performatifs sont disponibles à l'annexe 2.

L'exemple ci-dessous exprime un message request dans un format XML.

< ! DOCTYPE request SYSTEM " reqilest . dtdl'>

creques t>

csender>Mediation Agentc/sender>

<receiver>Agent Wrapperc/ weceiver>

<content>

<action>actl</action>

<actor>Agent Wrapper</actor>

cargs>null</args>

</content>

cprotocol>Request-inform</protocol>

creply-with>MSG-ID:lc/reply-with>

contology>default</ontology~

</request>

01 : type du message XML qui est automatiquement inséré lorsque I'agent wrapper et I'agent

médiateur envoient ou reçoivent des messages.

02 : représente l'intention du message. Dans ce cas c'est un performatif request qui exprime

l'intention de l'agent (qui est à l'origine du message) de demander un service au destinataire.

03 : agent qui est à l'origine du message.

38

Chauitre 2 :Technolonie choisie

04 : agent qui recevra le message.

05 à 09 : représente le contenu du message. Entres autres, la ligne 06 permet de définir l'action à

entreprendre par I'agent sollicité (ligne 07) en utilisant les arguments attachés au message Oigne

OS).

10 : protocole utilisé par le message.

11 : identifiant du message qui sera attaché à la réponse de la conversation entamée.

12 : ontologie utilisée par Ie message.

3. Java

3.1 Pourquoi Java ?

Les solutions proposées pour la gestion de la navigation sur le Saint-Laurent sont

généralement hétérogènes. Cette hétérogénéité se manifeste au niveau de la plate-forme

matérielle utilisée (PC, MAC, Station UNIX, etc.), au niveau des systèmes d'exploitations

employés (Windows NT, Unix, etc.), au niveau des langages de programmation (Java, Visual

Basic, C, etc.) mais aussi au niveau du matériel utilisé qui émane de divers constructeurs.

Afin de mettre en œuvre un système multiagent qui regroupe des solutions de ce genre, il

faut se doter d'un outil capable de :

Éliminer les hétérogénéités entre les différentes solutions qu'on veut regrouper.

Retourner un système qui peut s'exécuter en monoposte ou en réseau (Intranet et Intemet) car

les utilisateurs et les applications qui forment le système multiagznt sont dispersés

géographiquement.

Offrir un moyen pour la réutilisation des solutions existantes afin de réduire l'effort de

développement.

Offrir tous les avantages du paradigme Onenté Objet, car les agents sont assimilables à des

objets. Dans ce contexte, des programmes autonomes qui possèdent leurs propres données,

leurs propres propriétés ainsi que leurs propres fonctions.

Garantir un bon niveau de performance, de robustesse, de sécurité et de stabilité au niveau des

applications développées.

Le choix est fait sur le langage Java qui répond bien aux exigences susmentionnées et

nous en donne davantage. Les principaux atouts de ce langage sont résumés dans les points

suivants :

Cha~itre 2 :Technolopie choisie

La portabilité

C'est la caractéristique la plus importante de Java. Ce langage est totalement indépendant

du matériel utilisé. Ii tourne sur toutes les plates-formes (PC, MAC, Station UNIIX, etc.). Pour ce

faire, le code Java est d'abord compilé en un petit programme compact [18] appelé Pseudo-code

ou Bytecode. Cette action est assurée par un compilateur que possède chaque plate-forme.

L'avantage du Bytecode c'est qu'il est indépendant de la plate-forme cible et par

conséquent portable. Il comporte des instructions proche du code machine mais non spécifiques à

un ordinateur.

Le Bytecode généré est mis ensuite sur un serveur pour être exécuté directement ou pour

être téléchargé par un client qui I'exécute à l'aide d'un interpréteur, propre à chaque plate-forme

(Figure 2.1 1). Cette qualité de Java permet d'éliminer les problèmes qui ont trait à l'hétérogénéité

des solutions de gestion de la navigation.

Figure 2.11 [I 81 : Schéma de la porta bilité de Java.

40

Chapitre 2 :Technolonie choisie

Langage Orienté Objet

Java est ur, langage Orienté Objet. Il dispose de plusieurs bibliothèques et classes qui

permettent entre autres la gestion des bases de données, des fichiers, des réseaux et des interfaces.

C'est un langage simple dérivé de C w [18]. Il permet de simplifier les tâches difficiles sous C++

telles que la gestion des pointeurs. Tout simplement, Java n'en dispose pas ; il gère

automatiquement la mémoire.

Les langages de type Orienté Objet fournissent une particularité par rapport aux autres

langages en terme de réutilisabilité. Cette réutilisabilité est réalisée grâce aux trois mécanismes

fondamentaux : l'héritage, le polymorphisme et la liaison dynamique. À tire d'exemple, pour

modifier une méthode d'une classe donnée, on peut ne pas toucher à l'interface de cette classe.

Pour cela, il suffit de créer une classe héritée et de ne modifier que la méthode qui ne convient

Pas. Grâce à ses avantages en tant que langage Orienté Objet et grâce à sa portabilité, Java

permet d'utiliser les applications existantes. Il assure cette fonction par ses concepts d'héritage, de

polymorphisme et de liaison dynamique. Il i'assure, aussi, par encapsulation de ces appIications

ainsi que par sa qualité de pouvoir s'exécuter sur toutes les plates-formes.

La sécurité

Java permet de renforcer la sécurité des systèmes et des applications développés :

- Il offre des vérificateurs de Bytecode.

- II contrôle la mémoire.

- 11 gère les accès aux fichiers.

Lu robustesse

Java contrôle l'allocation de la mémoire. JI permet, aussi, d'éviter la surcharge du serveur

et du réseau en utilisant les moyens de calcul de la machine client (le programme Java peut être

téléchargé et exécuté sur la machine client) [19].

Pour résumer, Java est choisi essentiellement pour sa portabilité. Son indépendance vis-à-

vis des plates-formes permet d'éliminer les problèmes d'hétérogénéité entre les applications de

gestion de la navigation existantes. Java est aussi choisi pour sa robustesse et sa sécurité. En

outre, il est choisi parce qu'il permet de réduire l'effort de développement en permettant la

réutilisation des applications existantes.

Chavitre 2 :Technoloaie choisie

4. Matlab

4.1 Pourquoi Matlab ?

Pour réaliser la planification des itinéraires, on prend en considération plusieurs données

dont le volume peut être considérable et qui concernent, entre autres, les marées et les courants.

Pour effectuer les calculs requis sur ces données, il est important d'utiliser un outil qui présente

une bonne puissance de calcul. Il est aussi important que cet outil permette d'effectuer des calculs

mathématiques sur les données afin de calculer les trajectoires des navires. Il est enfin fortement

recommandé que les résultats des calculs soient rapportés sur des graphiques qui les appuient.

Le choix est fait sur Matlab vu les performances qu'il offre. Matlab est un environnement

de calcul scientifique et de visualisation des données. Il intègre le calcul mathématique, la

visualisation et un puissant langage technique. MATLAB gère de nombreuses tâches de calcul en

ingénierie et en sciences, depuis les acquisitions et les analyses de données jusqu'au

développement d'applications 1201. Il contient diverses boîtes à outils qui renferment plusieurs

fonctions mathématiques et graphiques. Les professionnels du domaine technique préfèrent

MATLAB à C car il permet d'accélérer leur recherche et raccourcir le temps consacré à l'analyse

et au développement. Matlab permet aussi de réduire les coûts des projets et produire des

solutions efficaces

MATLAB donne des interfaces intégrées qui permettent de lire et d'importer rapidement

des données à partir de périphériques, de fichiers, de bases de données et de programmes

externes. De plus, il permet d'intégrer aux applications des routines externes écrites en C , C++,

Fortran et Java [SOI.

Les outils de Matlab

Matlab inclut plusieurs outils pour [20] :

- L'analyse et l'exploration des données.

- La visualisation et le traitement des images.

- Le prototypage et le développement d'algorithmes.

- La modélisation et la simulation.

- L'acquisition des données.

- La programmation et le développement d'applications.

Les fonctionnalités de Matlab

Matlab possède plusieurs fonctionnalités. On en cite [20] :

- Calcul numérique pour des résultats rapides et précis.

Chavirre 2 :Technologie choisie

- Des graphiques pour analyser et visualiser les données.

- Un langage et un environnement de programmation interactifs.

- Des outils pour la conception des interfaces utilisateurs graphiques.

- Des interfaces avec des langages externes tels que C, C++, Java et Fortran.

- La prise en charge de l'importation des données à partir des fichiers et des périphériques

externes ainsi que l'accès aux bases de données.

- La conversion des applications Matlab en C et CU.

Pour résumer, Matlab est un outil important qui permet d'offrir et d'exécuter les calculs

mathématiques nécessaires aux calculs des trajectoires des navires. Ses outils graphiques

permettent de confirmer les résultats obtenus et de donner plus d'idées sur les trajectoires ainsi

que sur les conditions sur Ie fleuve.

5. Conclusion Pour résoudre le problème de la planification des itinéraires sur le fleuve Saint-Laurent,

nous avons choisi d'utiliser les technologies suivantes : les agents logiciels et les systèmes

multiagents, Bee-gent en tant que plate-forme de développement des systèmes multiagent, Java

pour le développement des agents et finalement Matlab pour le calcul et la visualisation des

trajectoires des navires. Le choix est fait sur la base des performances qu'offrent ces outils.

Grâce à sa portabilité, Java permet de résoudre les problèmes qui ont trait à l'hétérogénéité

des solutions existantes. C'est un langage qui tourne sur n'importe quelle plate-forme (PC, MAC,

etc.), en monoposte ou en réseau. Cette caractéristique permet de résoudre le problème de

dispersion des solutions utilisées sur plusieurs sites.

Bee-gent assure la création et la communication des agents développés en Java. Grâce au

langage ACL, il supporte la communication qui se fait facilement par échange des messages

XMUACL. De son côté, Matlab assure le traitement des données concernant, entre autres, les

marées et les courants. Grâce à sa puissance de calcul, il permet d'effectuer tous les calculs

nécessaires pour déterminer les trajectoires des navires et les visualiser.

Le problème qui se pose à ce niveau est en relation avec l'interfaçage entre Matlab et Java.

Certainement, des solutions existent pour ce problème. À titre d'exemple, on peut utiliser le

langage C comme langage intermédiaire par iequel les données à échanger transitent. Toutefois, il

est préférable de trouver une solution directe qui permet de faire communiquer Java et Matlab

sans intermédiaire.

III. Solution multiagent proposée

1. Architecture du système multiagent

2. Fonctionnement du système multiagent

3. La planifYication des itinéraires

4. Utilisation de Bee-gent

Chapirre 3 : Solution mulriagem orooosée

1. Architecture du système multiagent Le présent travail ne prend pas en considération toutes les contraintes de navigation

identifiées auparavant. C'est ainsi que I'impact de la présence de la glace dans le chenal n'est pas

considéré. Le travail effectué fournit plutôt une maquette qui exprime la faisabilité de

l'application de l'approche multiagent dans le contexte de la planification des itinéraires marines.

L'intégration de toute autre contrainte pouvant perturber la navigation est rendue possible grâce à

l'architecture ouverte du système multiagent proposé.

Le système multiagent développé offre un module de détermination des niveaux d'eau et

de calcul des trajectoires des navires. Ces calculs se font en tenant compte des facteurs des

marées, des courants ainsi que des caractéristiques du navire. Le système donne des suggestions

dont le but est d'aider le navigateur à bien choisir ses heures de départ. Tous les résultats sont

représentés sur des interfaces graphiques offertes par le langage Matlab.

Le système multiagent proposé contient quatre agents principaux : Agent Marée, agent

Courant, agent Navire et agent Fédérateur.

1.1 Les agents Marée et Courant Ces agents devraient connecter des soiutions de prédiction et de gestion des marées et des

courants à l'ensemble des éléments du système développé. Leurs rôles dans le présent système

sont de fournir respectivement Ia table des marées et celle des courants demandées pour la date

spécifiée par le navigateur. Ce rôle peut être plus complexe en intégrant des solutions réelles.

1.2 L'agent Navire Cet agent représente la fenêtre par laquelle le navigateur interagit avec le système. En

effet, le navigateur fournit par le biais de cet agent les informations concernant son navire telles

que la date de départ, les heures de départ au plus tôt et au plus tard ainsi que sa vitesse. Ces

informations sont les plus significatives pour le système multiagent implanté. Néanmoins,

l'architecture ouverte du système permet de les étendre et d'intégrer des nouvelles informations

teIIes que le dégagement sous-quille du navire.

ChiZ~itrt? 3 : Solution multiaaent oroposée

1.3 L'agent Fédérateur L'agent Fédérateur est conçu dans le but d'organiser les échanges d'information dans le

système. Il exerce un contrôle sur le fonctionnement global. On implante ainsi le processus de

coordination par supervision directe proposé par Mitsberg et mentionné dans le chapitre

précédent (§ II. 1 -4).

L'agent Fédérateur communique avec tous les autres agents du système. Il récupère les

données concernant le navire auprès de l'agent Navire. I1 cherche les tables des marées et des

courants pour la date de départ prévue par le navire auprès des agents Marée et Courant. Les

informations collectées sont transmises à un programme codé en Matlab qui fait les calculs

nécessaires pour la planification des itinéraires. Ce progamme retourne ses résultats à l'agent

Fédérateur qui les transmet ii son tour 2t l'agent Navire.

L'utilisation de l'agent Fédérateur permet de contrôler le fonctionnement global du

système et gérer la communication des nouveaux agents avec le reste du système (Figure 3.1).

-

O '

Agent Fédérateur Tables des marées

O

Agent Courant

t i Tables des courants

Figure 3.1 : Architecture du système mulîîugent proposée.

Chapitre 3 : Solution multiaeent nro~osée

2. Fonctionnement du système multiagent Le système multiagent proposé contient 8 flux d'information entre les agents. Ces flux

modélisent l'interaction au sein du système.

- Flux O : L'agent Navire envoie à l'agent Fédérateur les données saisies par le navigateur. Ces

données concernent la date de départ, les heures de départ au plus tôt et au plus tard ainsi que

la vitesse du navire. Ces informations sont saisies à partir de l'interface qu'offre le système

pour l'agent Navire (Figure 3.2).

..: L'agent Navire en attente ...

.; Transmission d e s données à l'agent Fédérateur ... I

Figure 3.2 : Interface de l'Agent Navire.

Flux : L'agent Fédérateur demande d'établir une connexion avec l'agent Marée. Il lui

demande la table des marées qui correspond à la date de départ spécifiée par l'agent Navire.

La connexion établie entre les deux agents est de type Client/Serveur. Elle fait intervenir

l'agent Fédérateur comme client lors de cette connexion. L'agent Fédérateur spécifie en plus

de la date de départ du navire son port d'écoute pour permettre l'établissement de la

connexion et par lequel la table sera transmise.

Chapitre 3 : Sukition rnultiaaent - ~roposée

- Flux 8 : L'agent Marée accepte d'établir la connexion Client/Serveur avec I'agent Fédérateur

et procède à l'envoi de la table des marées correspondante à la date spécifiée par I'agent

Fédérateur.

gragent Maree en attente ... 3: . . . Réception d'un message de la part de I'agent Fédérateur . . ... ' :,- _,. I I .

Établissement de la communication CUenUÇerveur avec l'agent Fede ::$ . .- ..! t J

Le serveur est lancé pour le transfert de la table des marées , . ._ . . , . . -, .*..,. ..... , .., .... ,.,. . Transfert de la table des marées en cours ... .;..:>j;;

:'"a;! . -. . - . , a > , ..-

Figure 3.3 : In te~ace de l'agent Marée lors de l'exécution du système.

- Flux CD : L'agent Fédérateur demande d'établir une connexion Client/Serveur avec l'agent

Courant. Dans cette connexion, il joue le rôle du client. Il lui demande la table des courants

pour la date spécifiée. II spécifie par la même occasion son poa d'écoute.

- F h x a : L'agent Courant accepte et établit la connexion Client/Serveur avec l'agent

Fédérateur et lui transmet la table des courants demandée.

Figure 3.4 : Interface de l'agent Courant lors de l'exécution du système.

Cha~itre 3 : Solution multia~enr ~ r o ~ o s é e

Heure Distance Intemit6 du courant

Figure 3.5 : Transmission de la fable de courants lors de l'exécution du système.

- Flux @ : Après avoir recueilli toutes les données nécessaires au calcul des trajectoires du

navire, l'agent Fédérateur appelle le programme Matlab et lui passe toutes ces données.

- Flux @ : Le programme Matlab effectue les calculs nécessaires, trace les trajectoires du

navire et retourne les résultats à l'agent Fédérateur. Dans le cas où il serait judicieux de

changer l'heure de départ, le programme Matlab suggère au navigateur une nouvelle heure de

départ et trace la trajectoire que devrait avoir le navire pour cette heure.

Chapitre 3 : Solution rnultiaaent ~rooosée

J'al un message de la part de navire ... . .y .:.! :; ., <.. . - - .!/. ..,'. .- . Y i - -. . -... J'ai besoin de la table des marees ... ., . _'>. . - . :S.. ::;. 7 :-,

Attente : activer la communication ClientlServeur avec l'agent Maree ... :::c:-;r - .'.;!: Cagant Maree est pret pour le transfert de fichier ... -

-.>:r2; .i

Transmission de la table des marees en cours ... Transmission de la table des marees terminee avec succes. J'ai besoin de la table des courants .., L'agent Courant est pret pour le transfert de fichier ... Mente : demande de la table des courants ... Transfert de la tabie des courants en cours ... transmission de la table des courants terminee avec succes. Attente : j'ai besoin du programme Matiôb ... Appel du programme Matlab ... Lancement des calculs des trajectoires des navires ... Récupération,des résultats des calculs à partir de Matlab ... Heure suggérée pour le départ au plus tôt: 08h08mn Attente : envoyer les resultats a l'agent Navire ...

.. 2 ' . . . .- - . p. . . . ' 1 . i l - . .. . .. .,

. . . . ' :. / ' . . . ,

Figure 3.6 : Interface de l'agent Fédérateur lors de l'exécution du système.

- Flux O : L'agent Fédérateur récupère les résultats des calculs de la part du programme

Matlab. II ne lui reste qu'à envoyer les résultats des calculs à l'agent Navire. Les résultats

seront affichés et consultés par le navigateur qui décidera de son heure de départ.

?:]L'agent Navire en attente ...

Figure 3.7 : Interface de l'agent Navire à la fin de l'exécution du système.

3 ..- z::

.:$

:: :: ':

I

Commentaires

Transmission des données à l'agent Fédérateur ... Attente de [a reponse de l'agent Fédérateur ... Réception des résultats de l'agent Fédérateur ...

Départ au plus tôt 1 Départ au plus tard

Départ 1 (00.000,06.35) 1 (00.000,09.30) Arrêt 1 (1 74654,12.20) j ?a"">

Reprise 1 ( 3 74654,14.00) ] VI- Arrivée 1 (259260,16.43) 1 (259260,17.50) Heure de depart au plus tôt suggérée est: 08hO8mn. Cela vous permettra d'atteindre la destination sans arrêt

Le navigateur décide de quitter le port de Montréal à 06h35mn. À 12h20mn il serait obligé de

s'arrêter car le niveau d'eau n'est pas sufisant pour le passage de son navire. Il ne peut

reprendre son voyage qu'à 14h. Il arrivera à Québec à 16h43mn. Dans le cas où le navigateur

déciderait de quitter le port de Montréal à 09h30mn, son navire peut passer sans problème

jusqu'à destination.

Le système propose au navigateur de modifier son heure de départ au plus tôt pour qu'il

puisse passer sans arrêt jusqu'à Québec. Dans l'exemple choisi, il est suggéré de quitter le port

de Montréal au plus tôt 08h08mn.

L'agent Marée et l'agent Courant peuvent utiliser des bases de données où sont stockées

respectivement les tables des marées et des courants. Dans le cas du système multiagent

proposé, les deux agents utilisent des fichiers séparés pour enregistrer les tables sans aucune

organisation de base de données.

Chapitre 3 : Solution multiaaenr - . . urmosée

3. La planincation des itinéraires Après la collecte des données nécessaires, la planification des itinéraires est réalisée grâce

à un programme implanté en Matlab. Ce programme permet entre autres de tracer les courbes des

niveaux d'eau et de tracer les trajectoires du navire correspondant à l'heure de départ au plus tôt et

celle au plus tard. Dans le cas où le navire serait obligé de s'arrêter à cause du niveau d'eau

insuffisant, ce programme calcule l'heure de départ que devrait choisir le navigateur.

3.1 Calcul des niveaux d'eau Notre programme Matlab permet de calculer les niveaux d'eau pour la date de dépm

spécifiée par le navigateur en tenant compte du phénomène des marées. Il permet de représenter

graphiquement ces niveaux sous forme de courbes (Figure 3.8). Ces courbes sont nécessaires

pour cerner les zones de niveaux d'eau suffisants pour un passage sécuritaire du navire.

Figure 3.8 : Courbes des niveaux d'eau entre Montréal et Québec pour un seul jour.

Chapitre 3 : Solution multianent ~rouosée

Remarque : Le programme Matlab permet de tracer sur la même figure les courbes de niveaux

d'eau pour un ou plusieurs jours.

3.2 Détermination des zones de passage interdites En tenant compte des caractéristiques du navire, on peut déterminer le niveau d'eau

minimal nécessaire à un passage sécuritaire du navire. Sur cette base, le programme Matlab

permet de cerner les zones n'ayant pas le niveau d'eau requis pour un passage sécuritaire du

navire (Figure 3.9). Ces mesures sont importantes dans la mesure où la détermination des

trajectoires des navires doit éviter ces zones dangereuses. Connaissant la vitesse et l'heure de

départ spécifiées, le programme Matlab permet de prédire si le navire pouvait passer sans qu'il

entre dans ces zones ou il serait obligé de s'arrêter en l'attente de l'augmentation du niveau d'eau.

Zones ayant un niveau d'eau inférieur à 12x11

Figure 3.9 : Délimitation des zones de passages interdites.

Chavirre 3 : Solution multiaaent ~ r o ~ o s é e

3.3 Calcul des trajectoires Après avoir tracé les courbes des niveaux d'eau et cerné les zones de passage interdites, le

programme Matlab calcule et trace les trajectoires du navire. Ces trajectoires sont établies pour la

vitesse spécifiée et pour les heures de départ au plus tôt et au plus tard communiquées par le

navigateur (Figure 3.10).

Les trajectoires calculées tiennent compte du phénomène des courants qui perturbe la

vitesse du navire. L'intensité des courants peut être favorable ou défavorable. Le long du trajet, le

progamme Matiab calcule la vitesse du navire qui est la résultante de la vitesse du navire à la

surface et la vitesse du courant. Il fait une interpolation sur les heures et les distances. En effet,

entre Montréal et Québec, on compte presque 260 km qui sont divisés en 341 sections de

distance. Pour chaque section et chaque quart d'heure, le programme calcule la nouvelle vitesse

en tenant compte de la vitesse courante et de la moyenne de l'intensité des courants entre les deux

sections.

Dans le cas où la trajectoire du navire couperait une zone de passage interdite, le

p r o s a m e Matlab prévoit l'arrêt du navire jusqu'au moment où le niveau d'eau sera suffisant. Il

reprend ensuite le calcül à partir de l'heure où les conditions seront favorables.

Figure 3.10 : Culcul des tmjectoires au plus tût et au plus tard du navire.

54

Chapitre 3 : Solution multiaaent ~rooosée

3.4 Calcul des trajectoires des navires par procédure inverse II est possible que l'heure de départ du navire soit mal choisie. Le navire serait obligé de

s'arrêter dans l'attente d'un niveau d'eau suffisant pour sa sécurité. Cet arrêt doit être évité vu les

pertes en temps et en consommation de carburants qui s'en suivent. Le programme Matlab prévoit

une procédure de calcul de l'heure de départ suggérée en tenant compte de la vitesse du navire et

des courants. Les calculs sont faits selon des interpolations sur le temps et sur les sections de

distance. Les résultats permettent de tracer la trajectoire que devrait avoir le navire pour l'heure

suggérée (Figure 3.1 1).

Cette tâche est une aide à la décision permettant aux navigateurs de faire de meilleurs

choix pour leurs départs. C'est ainsi que dans l'exemple de la Figure 3.1 1, le navire sera obligé de

s'arrêter. Le programme fait ses calculs et lui suggère une nouvelle heure de départ (Courbe du

milieu).

Figure 3.11 : Calcul de l'heure de départ suggérée afin d'éviter l'arrêt du navire.

Chapitre 3 : Solution multhent ~ r o ~ o s é e

4. Utilisation de Bee-gent Le développement des agents qui constituent le système multiagent proposé est assuré par

le biais de Bee-gent. Cette plate-forme de génération de systèmes multiagents permet de coder les

agents en java. Elle met à la disposition des agents un ensemble de performatifs qui forment le

langage ACL (Agent Communication Language). Bee-gent offre plusieurs fonctions qui

supportent les communications entre les agents. Ces fonctions sont des messages XMUACL.

Elles sont essentiellement de deux types : Attendre (waitXML) et Envoyer (sendXML).

Les performatifs du langage ACL supportés par B ee-gent renferment plusieurs

informations qui concernent entre autres le type du performatif, la source, la destination ainsi que

le contenu du message. À sa réception, l'agent analyse le performatif afin de déterminer son

origine et l'action qui lui est demandée.

La modélisation d'un agent sous Bee-gent s'apparente à celle d'un automate. Chaque agent

exécute une tâche ou déclenche un traitement et passe à un état suivant. La représentation des

différents états par lesquels un agent passe est effectuée grâce aux diagrammes de transition que

Bee-gent permet de concevoir par le biais d'un de ses modules, en I'occurrence IPEditor. Les

diagrammes de transition permettent en particulier de modéliser le protocole de communication

entre les différents agents du système.

Chapitre 3 : Solution multiapenz urouosée

4.1 Diagramme de transition de l'agent Navire

Figure 3.12 : Diagramme de transition de l'agent Navire.

Le digramme de transition de l'agent Navire présente deux états essentiels. L'agent navire

commence par soumettre sa requête de calcul de trajectoire â l'agent fédérateur. Il lui envoie un

performatif inform qui contient toutes les données nécessaires (date de départ, heure de départ au

plus tôt, heure de départ au plus tard et sa vitesse). L'agent Navire passe après à un deuxième état

où if attend la réponse de l'agent Fédérateur.

Chapitre 3 : Solution rnultiaaent ~roposée

4.2 Diagramme de transition de I'agent Marée

Figure 3.13 : Diagramme de transition de I'agent Marée.

Le diagramme de transition de I'agent Marée contient deux états. Au début, I'agent Marée

observe un état d'attente jusqu'au moment où il est sollicité par I'agent Fédérateur. Ce dernier lui

envoie un performatif request lui demandant d'établir une connexion Client/Serveur. Il lui passe

en paramètre la date de départ du navire et son port d'écoute pour pouvoir se connecter. L'agent

Marée traite la requête de l'Agent Fédérateur et passe au deuxième état. Ensuite, il transmet à

l'agent Fédérateur le performatif inform pour lui dire qu'il est prêt à transmettre la table des

marées pour la date spécifiée. La connexion Client/Serveur est par la suite établie de façon

effective entre les deux agents et la transmission de la table des marées est déclenchée. À la fin,

l'agent Marée se déconnecte et quitte le système.

Cha~i tre 3 : Solution mulrianent orooosée

4.3 Diagramme de transition de l'agent Courant Le diagramme de transition de l'agent Courant est similaire à celui de l'agent IMarée. Il

possède les mêmes états et les mêmes transitions vu que les deux agents jouent des rôles

équivalents.

Figure 3.14 : Diagramme de îransition de l'agent Courant.

4.4 Diagramme de transition de l'agent Fédérateur Le diagramme de transition de l'Agent Fédérateur comporte trois états principaux. On y

trouve les performatifs envoyés par les autres agents et qui figurent dans leurs diagrammes de

transitions. On y trouve aussi les performatifs qui sont envoyés de sa part aux autres agents du

système.

Chapitre 3 : Solution multiapent ~ r o ~ o s é e

Figure 3.15 : Diagramme de tmnsition de l'agent Fédérateur.

5. Interfaçage JavaIMatlab : JmatLink Un des grands apports de l'approche rnultiagent est qu'elle permet de concevoir des

systèmes ouverts et extensibles. Elle permet aussi d'implanter des systèmes intégrant plusieurs

applications hétérogènes et de les faire communiquer.

Au niveau du système multiagent proposé, l'agent Fédérateur, développé en Java, interagit

avec le programme Matlab qui assure les calculs de la planification des itinéraires. L'interfaçage

entre les deux est permis grâce à une librairie Java appelée JmatLink. Cette librairie offre un

ensemble de fonctions qui permettent de lancer un programme Matlab à partir de Java et d'établir

un échange d'information entre les deux. Entre autres, il est pertinent de citer les fonctions

suivantes de JmatLink :

- engOpen : Cette fonction permet de lancer Matlab à partir de Java et par la suite d'établir la

connexion entre les deux.

Cha~itre 3 : Solution mdtianent pro~osée

- engEva1String : Cette fonction permet d'évaluer une expression sous Matlab. Dans le cas du

système rnultiagent proposé, les paramètres de cette fonction sont formés par une fonction

Matlab qui exécute le programme de planification des itinéraires ainsi que par les noms des

tables des marées et des courants.

- engGetArray : Cette fonction permet d'obtenir des données à partir de Matlab. Dans le cas

présent, l'agent Fedérateur utilise cette fonction pour récupérer les résultats de l'exécution du

programme de planification des itinéraires.

- engClose : Cette fonction permet de rompre la connexion avec Matlab.

Les quatre fonctions précédemment citées permettent I'interfaçage entre l'agent Fédérateur

et le programme Maclab de planification des itinéraires. Le schéma suivant résume l'ensemble des

échanges entre les deux parties.

Résultats Trujecroire au plus tôt . . . Trajectoire au plirs tard . . . Suggestions . . .

Figure 3.1 6 : Interfaçage agent Fédérateur/Progrumrn e Matlab.

C h ~ i t r e 3 : Solution rnultiapenr prouosée

6. Conclusion À travers ce chapitre, nous avons prouvé que l'approche multiagent est bien appropriée au

domaine des applications marines. Elle donne de bonnes performances et permet surtout de

simplifier les problèmes dans ce domaine en les découpant en des sous-problèmes. La résolution

de chaque sous-problème est assurée par un agent autonome. Nous avons prouvé aussi le bon

choix des technologies adoptées pour la résoiution du problème de la planification des itinéraires.

Grâce à la collaboration de Bee-gent, de Java et de l'approche multiagent, nous avons pu créer les

agents Navire, Marée, Courant et Fédérateur du système global et établir facilement la

communication entre eux. Le problème d'interfaçage entre Matlab et Java, invoqué dans la

conclusion du chapitre dédié à la technologie choisie, est résolu grâce à la librairie JmatLink.

Cette librairie nous a offert tous les moyens nécessaires pour l'appel du programme Matlab qui

effectue les calculs des trajectoires des navires. Elle nous a permis, aussi, de passer les

informations nécessaires à l'exécution de ce programme et la récupération des résultats à la fin.

L'impIication du navigateur dans le fonctionnement de notre système est une nouveauté

qui n'existe pas au niveau des systèmes conçus pour la gestion de la navigation sur le Saint-

Laurent. Avec notre système, le navigateur aurait la possibilité de spécifier les informations

concernant son navire. À la fin de l'exécution du système, il recevrait des informations

pertinentes concernant son voyage telles que son heure d'arrivée et éventuellement la suggestion

d'une nouvelle heure de départ d a s Ie cas où cette heure serait mal choisie au début.

L'utilisation des applications existantes dans notre système se restreint au programme

Matlab et aux programmes Client et Serveur que nous avons conçus pour le calcul des trajectoires

des navires et l'envoi des tables des marées et des courants à l'agent Fédérateur. L'absence des

applications opérationnelles est due à l'absence d'un accord avec leurs organismes propriétaires.

Cette absence ne touche en aucun cas le fondement de notre système. Ce dernier prouve qu'il est

extensible grâce aux atouts de l'approche multiagent et au langage Java.

Notre système permet de calculer et de tracer Ies trajectoires des navires en se basant sur

des informations concernant les marées, les courants ainsi que les navires. Pour expliquer plus en

détail son fonctionnement, nous consacrons le chapitre suivant à sa réalisation technique ;

Comment sont conçus les différents agents ? Comment se font les échanges entre eux ? Comment

fonctionne le programme Matlab ?

Réalisation technique

1. Réalisation technique : Les agents

2. Réalisation technique : Le programme MatIab

Chapitre 4 : Réalisation fechni~ue

1. Réalisation technique : Les agents

1.1 Introduction La communication au sein de notre système multiagent se base essentiellement sur

l'échange des messages XMUACL. Néanmoins, des données sont transmises via des connexions

Client/Serveur entre l'agent Marée et l'agent Fédérateur d'une part et l'agent Courant et L'agent

Fédérateur d'autre part. Ces connexions sont établies dans le but de transférer les tables des

marées et des courants vers l'agent Fédérateur.

Lors de chacune des connexio~s Client/Serveur, le programme client est encapsulé dans

l'agent Fédérateur. Le programme serveur, quant à lui, est intégré dans chacun des agents Marée

et Courant. Dans les deux cas, ce programme joue le même rôle. La seule différence réside au

niveau de la table à transférer.

Pour expliquer le fonctionnement de chaque agent et ses interactions avec les autres, on

présente dans cette section les organigrammes et les pseudo-algorithmes des différents agents du

système ainsi ceux des programmes client et serveur. Toutefois, on se contente de présenter l'un

des deux agents Marée ou Courant parce qu'ils jouent des rôles similaires. Le choix étant fait

pour l'agent Courant.

1.2 La connexion Clientfierveur

1.2.1 Le serveur

Le serveur commence par créer la socket via laquelle la transmission de la table des courants

sera effectuée.

Il passe ensuite à un état d'écoute, en attente d'une éventuelle demande de connexion

ClientlServeur. Si tel est le cas, la connexion est établie.

Le programme serveur cherche la table des courants pour la date spécifiée. Il vérifie par la

même occasion les permissions de lecture de cette table. En cas d'anomalies, un message

d'erreur est généré.

64

Cha~itre 4 : Réalisation techniaue

4. Si la table existe avec les droits requis, sa transmission commence de façon effective. Le

programme serveur lit la table caractère par caractère. Chaque caractère lu est écrit dans la

sortie de la socket. Il sera reçu et lu par le programme client de l'agent Fédérateur de l'autre

côté de la connexion.

5. Ce processus continue jusqutà la fin de la transmission de la totalité de la table. Après

l'achèvement du transfert, la connexion CIient/Serveur est rompue.

Organi'gramrne

Création Socket

Écoute : Attente connexion k

Connexion ? Q--- Recherche table et permissions 1

permission Erreur

Écriture Fin table ? Socket

t-- -:

Figure 4. I : Organigramme du serveur.

Cha~itre 4 : Réalisation technique

1.2.2 Le client

Pseudo-algorithme

1. Création d'une nouvelle socket sur le poste local sur lequel réside I'agent Fédérateur.

2. Établissement de la connexion Client/Serveur de façon effective.

3. Lecture de l'entrée de la socket.

4. Sauvegarde de l'information lue à partir de l'entrée de la socket dans un fichier de sortie.

5. Le programme client boucle sur les étapes 2 et 3 jusqu'à la fin de la transmission.

Création Socket

Etablissernent connexion

1 Fin 1

Figure 4.2 : Organigramme du client.

1.3 Agent Courant

La contribution de I'agent Courant dans notre système multiagent est l'envoi de la table

des courants à l'agent Fédérateur. Cette table correspond à la date de départ spécifiée par l'usager.

Lors de leur communication, les deux agents s'échangent des messages XMUACL contenant les

performatifs request (qui sert à demander la table des courants auprès de l'agent Courant) et

infonn (qui permet d'aviser l'agent Fédérateur de la possibilité d'établir une connexion

Client/Serveur).

Chapitre 4 : Réalisation techniuue

Le fonctionnement de I'agent Courant est marqué par deux états : l'établissement de la

communication avec I'agent Fédérateur et le transfert de la table des courants réclamée par cet

agent. Les pseudo-algorithmes et les organigrammes de ces deux états sont présentés dans la

suite.

Pseudo-algorithme correspondiznt à l'établissement de la communication

2 . L'agent Courant observe au début de son premier état une attente qui dure jusqu'à sa réception

d'un message XMLdACL.

2. Dès la réception de ce message, l'agent Courant vérifie son origine qui devrait être I'agent

Fédérateur. Si tel n'est pas le cas, une erreur est générée.

3. Ensuite, il vérifie la nature du performatif qui doit être de type requesf.

4. L'agent Courant analyse l'information contenue dans le message XMUACL. Il extrait à pxtir

de cette information la date de départ du navire.

5. Il envoie ensuite un message XMLIACL à I'agent Fédérateur de type inform pour lui

indiquer qu'il est prêt à étabIir une connexion CIient/Serveur avec lui.

6. L'agent Courant reprend son état d'attente jusqu'à Ia réception de la confirmation de

l'établissement de la connexion Client/Serveur de la part de l'agent Fédérateur. Il passe ainsi

au deuxième état.

Cha oitre 4 : Réalisation zechnioue

Organigramme correspondant à l'établissement de là communication

Fédérateur

II Réception message

XMUACL ? -- Identification de

la source du message

Féddrateur ? Erreur

Identification nature performatif

Request ? 6 Non 1 Traitement des

données du Fédérateur

Envoie message Fédérateur

1 Attente (État 2) 1

pp

Figure 4.3 : Organigramme du premier état de l'agent Courant.

Chauitre 4 : Réalisation technique

Établissement de la connexion ClientIServeur et transfert de la table des courants

1. L'agent Courant reçoit de la part de l'agent Fédérateur la confmation d'établir une connexion

Client/Serveur.

2. La connexion Client/Serveur est établie de façon effective.

3. IRs données de la table des courants sont transmises via cette connexion.

4. La connexion est rompue dès la fin de la transmission de la table des courants. L'agent

Courant termine ainsi son rôle et quitte le système multiagent-

Réception confirmation Fédérateur

Établissement connexion Client/Serveur

I I

I ~ - , , ~ - , - - , , , , , - - - , ~ i Transmission table courants

Figure 4.4 : Organigrurnme du deuxième état de l'agent Courant.

1.4 Agent Navire

L'agent Navire représente la fenêtre via laquelle le navigateur communique avec le reste

du système multiagent. Son fonctionnement est divisé en deux états. Lors du premier, il passe à

l'agent Fédérateur les informations concernant la date de départ du navire, ses heures de déps t au

plus tôt et au plus tard ainsi que sa vitesse. À la fin de ce premier état, l'agent Navire passe en

attente des résultats de la planification des itinéraires. Dès la réception de ces résultats, il entame

son deuxième état. Ii traite ces résultats et les affiche pour être exploités par l'usager.

Chauitre 4 : Réalisation rechniaue

fseudo-clgorithme du premier état du navire

L'agent Navire commence par un état d'attente jusqu'au moment où il sera sollicité par

l'usager qui saisit à travers son interface les données du navire.

L'agent Navire exerce un contrôle sur les informations saisies. Il s'attend par exemple à avoir

une heure de départ "06h30mn" sous la forme "0630". En cas d'erreur il demande de valider

les données saisies.

Lorsque les données saisies sont approuvées, l'agent Navire construit une chaîne de caractères

qui renferme toutes les données. Il construit ensuite son message XMUACL qu'il envoie à

l'agent Fédérateur. Ce message contient principalement les informations suivantes :

Per$ormatif : Inform Le performatif ACL à envoyer. Elle est de type inforan. Elle permet d'aviser l'agent Fédérateur qu'il va

Receiver : Fédérateur recevoir des informations.

Origine du message : L'agent Navire

Le contenu du message. Exemple : "260606300845 15 10"

Destination du message : L'agent Fédérateur

Figure 4.5 : Schéma du message XMUACL envoyépar l'agent Navire.

Après l'envoi du performatif à l'agent Fédérateur, l'agent Navire passe à un deuxième état

d'attente ; il attend les résultats des calculs des trajectoires du navire ainsi que les suggestions

éventuelIes Dour son heure de dériart.

Organigramme du premier état du navire

Navigateur

Contrôle des données du navire

1 Envoi message 1

Figure 4.6 : Organigramme du premier état de l'agent Navire.

Pseudo-algorithm e du deuxième état du navire

1. Dès que les résultats de la planification des itinéraires sont disponibles, l'agent Fédérateur les

passe à I'agent Navire qui est toujours en attente.

2. L'agent Navire vérifie le type du performatif ACL reçu dans le message W A C L et qui

doit être de type inform. Si tel n'est pas le cas, un message d'erreur est généré.

3. Les résultats reçus par l'agent Navire sont sous forme d'un tableau de chaînes de caractères.

L'agent Navire procède à l'interprétation de chaque case du tableau. Il extrait les résultats des

calculs des trajectoires du navire correspondantes aux heures de départ au plus tôt et au plus

tard. Dans le cas d'un mauvais choix de l'heure de départ, il extrait l'heure suggérée par le

système multiagent au navigateur.

4. L'agent Navire affiche les résultats de la planification des itinéraires.

Organigramme du deuxième état du navire

Fédérateur cct.cl Vérification du

type du message l

Interprdtation des résultats

résultats

-- -

Figure 4.7 : Organigramme du deuxième état de l'agent Navire.

1.5 Agent Fédérateur

L'agent Fédérateur représente la pièce centrale dans notre système multiagent. Il

communique avec l'agent Navire afin d'obtenir les informations concernant le navire. Ensuite, i l

communique avec les agents Marée et Courant pour chercher les tables des marées et des

courants.

Les informations obtenues auprès des trois agents précédemment mentionnés sont

transmises au programme Matlab qui assume la tâche de la planification des itinéraires. L'agent

Fédérateur récupère les résultats des calculs et les rend à l'agent Navire qui les affiche pour être

utilisés par l'usager.

L'ensemble des traitements effecniés par l'agent Fédérateur sont résumés à travers la suite

des organigrammes et des pseudo-algorithmes suivants :

Chuuirre 4 : Réalisation techniaue

Pseudo-algorithme du premier éfaf de l'agent Fédérateur

1. L'agent Fédérateur est en attente jusqu'à sa réception des informations du navire (date de

départ, heures de départ au plus tôt et au plus tard et vitesse du navire). Ces informations sont

reçues sous forme d'une chaîne de caractères.

2. L'agent Fédérateur extrait de cette chaîne de caractères la date de départ prévue par le

navigateur.

3. Il crée un message XMUACL contenant le performatif request et I'envoie à l'agent Marée. I1

lui demande la table des marées qui correspond à la date du départ du navire (Cette

information est spécifiée dans le contenu du performatif request).

4. L'agent Fédérateur demande ensuite d'établir une connexion ClientlServeur avec l'agent

Marée pour assurer l'envoi de la table des marées. R passe ensuite à un état d'attente dans

lequel il attend la réponse de l'agent Marée concernant sa requête.

Organigramme du premier état de l'agent Fédérateur

ta date de départ

Envoi message u d 7- connexion

Client/Serveur

Aitente e J Figure 4.8 : Organigramme du premier état de l'agent Fédérateur.

Cha~itre 4 : Réalisation technisue

Pseudo-algorithme du deuxième état de l'agent Fidérafeur

L'agent Fédérateur reçoit un message XMUACL de la part de l'agent Marée en réponse à sa

requête d'établissement d'une connexion Client/Serveur.

II examine le contenu du performatif. Si I'agent Marée n'est pas prêt, un message d'erreur

indiquant l'impossibilité d'établir une connexion Client/Serveur est généré.

Dans le cas contraire, l'agent Fédérateur établit la connexion ClientEerveur de façon effective

et commence à recevoir la table des marées. À la fin de la réception, la connexion entre les

deux agents est rompue.

L'agent Fédérateur envoie à l'agent Courant un message X W A C L ; Il lui demande la table

des courants correspondant à la date de départ prévue par Ie navigateur.

L'agent Fédérateur demande aussi d'établit une connexion Client/Serveur avec I'agent

Courant. Il passe ensuite à un état d'attente.

Chapitre 4 : Réalisation techniaue

Organigrnmme du deuxième état de l'agent Fédérateur

Réception message

XMUACL

Agent Mar6e est prêt ?

! L--, --, , , , , , ,, , J Réception table

I marées

Envoi message 4-1 XMUACL 1

I

connexion Client/Serveur

Attente E 5

4 Erreur 1

Figure 4.9 : Organigramme du deuxième état de l'agent Fédérateur.

Chapitre 4 : Réalisation technique

Pseudo-algorithme du troisième état de l'agent Fédérateu~

1 . L'agent Fédérateur observe un état d'attente jusqu'à sa sollicitation par l'agent Courant qui lui

envoie un message XMUACL.

2. L'agent Fédérateur examine le contenu du performatif Nifurm encapsulé dans le message

reçu. Si I'agent Courant n'est pas prêt, un message d'erreur indiquant l'impossibilité d'établir

une connexion Client/Serveur est généré.

3. Dans le cas contraire, l'agent Fédérateur étabiit la connexion ClientBerveur de façon effective

et commence à recevoir la table des courants réclamées. À la fin de la réception. la connexion

est rompue entre les deux agents.

4. À ce niveau, l'agent Fédérateur dispose des données nécessaires à la planification des

itinéraires. Il appelle le programme Matiab et il lui passe les données dont il dispose. Il passe

ensuite à un nouvel état d'attente.

5. Le programme Matlab effectue les calculs des trajectoires du navire et retourne ses résultats à

I'agent Fédérateur. Ces riisultats sont sous forme d'un tableau de chaînes de caractères.

6. L'agent Fédérateur interprète les informations contenues dans le tableau qui lui est envoyé par

le programme Matlab. Xi extrait les informations correspondantes à chacune des trajectoires

(au plus tôt et au plus tard) et vérifie si le programme Matlab suggère une nouvelle heure de

départ pour le navire. Les informations extraites sont ensuite rassemblées dans une seule

chaîne de caractères.

7. L'agent Fédérateur envoie un message XMWACL à I'agent navire contenant un performatif

ACL de type inform qui contient les résultats des calculs. Il termine ainsi sa tâche et quitte le

système multiagent.

Cha~itre 4 : Réalisation techniuue

Organigramme du troisième étnt de L'agent Fédérateur

message XMUACL 1

prêt ?

Passage données programme Matlab

des itinéraires

Attente 1

Récupération des résultats

Envoie message u 4 - 1 ycL 1

Figure 4.10 : Organigramme du troisième état de l'agent Fédérateur.

Chapitre 4 : Réalisation techniuue

1.6 Conclusion

À travers l'ensemble des organigrammes et des pseudo-algorithmes de cette partie, nous

avons présente le fonctionnement des différents agents du système conçu ainsi que le

fonctionnement des programmes Client et Senteur employés pour le transfert des tables des

marées et des courants vers l'agent Fédérateur. Ce dernier possède une grande importance dans

notre système rnultiagent ; il contrôle et oriente le fonctionnement du système global. Cette

importance est claire à travers les différents organigrammes. En effet, en les examinant, on y

trouve des interactions avec l'agent Fédérateur qui se manifestent par l'envoi ou la réception des

messages XMUACL.

Grâce 2 i ces messages, nous avons pu établir facilement la communication entre les

différents agents. Cette facilité se voit au niveau des pseudo-algorithmes. En effet, il suffit de

spécifier l'expéditeur, la destination et le contenu du performatif ACL. L'acheminement des

messages est assuré, ensuite, par Bee-gent. Les messages XMUACL permettent, aussi, de

synchroniser les fonctionnements des agents. Ces fonctionnements sont caractérisés par différents

états dont chacun peut être déclenché suite à la réception d'un message W A C L et peut être

fini en en envoyant un autre.

Cette partie traitait de la réalisation technique des agents et des programmes Client et

Serveur. La partie suivante est consacrée à l'explication des détails du programme Matlab et de

son interaction avec l'agent Fédérateur.

2. Réalisation technique : Le programme Matlab

2.1 Introduction

La planification des itinéraires est un processus qui renferme plusieurs étapes. Le

programme Matlab qui effectue le calcul des itinéraires assure les tâches qui figurent sur la

Figure 4.11 avant de rendre ses résultats à l'agent Fédérateur.

Chmitre 4 : Réalisation technwrce

Résultats des calculs de la trajectoire

Agent Fédérateur \ 1

Formatage des données du navire

1 Trapge des courbes des niveaux 1 I d 'eau I

1 D é l i m W n des zones interdites au 1 I passage du navire I

Calcul de la trajectoire du navire I Non

Mauvais choix de l'heure de

départ

Oui

Calcul de l'heure de départ à suggérer

1 Formatage des résultats + Programme Matlab

Figure 4.1 1 : Organigramme de la planification des itinéraires.

2.2 Formatage des données

La communication entre l'agent Fédérateur et le programme Matlab ne suit pas des règles

ou des protocoles complexes. Elle est supportée par JmatLink et se restreint à l'échange des

ch&nes de caractères et des tableaux dans ce cas du système multiagent conçu.

Les données du navire reçues par le programme Matlab sont sous forme d'une chaîne de

caractères. Cette chaîne représente les heures de départ au plus tôt et au plus tard du navire ainsi

que sa vitesse. Elle doit être formatée pour déceler chaque élément d'information. Le formatage

consiste en premier lieu A extraire les heures de départ du navire et à les convertir en des

décimaux. À titre d'exemple, une information de type '1030' veut dire que l'heure de départ est

10h30mn. Elle sera convertie en '10.50'. Ce formatage est nécessaire pour pouvoir faire les

calculs et rapporter les résultats graphiquement.

Cha~itre 4 : Réalisation techni~ue

Le pseudo algorithme général de cette tâche de formatage des données du navire est le

suivant :

Un exemple de données du navire : 063508401530

Heure départ au plus tôt 1 Vitesse du navire

Heure départ au plus tard

Pseudo algorithme Exemple

1. Extraire la chaîne codée sur 4 caractères et représentant

l'heure de départ au plus tôt

2. Convertir les deux derniers caractères en un nombre

3. Diviser le nombre obtenu sur 60

4. Convertir le résultat en une chaîne de caractères et en prendre

les deux premiers chiffres après le point

5. Faire la même chose avec la chaîne composée des 4

caractères situés entre la cinquième et la huitième position

6 . Reconstruire la chaîne de caractères représentant les données

du navire en remplaçant les minutes par les chaînes de 2

caractères obtenues dans l'étape 4 et 5 précédées par un point

À la fin du formatage des données, le programme Matlab procède au chargement des tables

des courants et des marées qui seront utilisées au cours des calculs des trajectoires des navires.

2.3 Traçage des courbes des niveaux d'eau Le calcul des niveaux d'eau prend en considération le facteur des marées. Il utilise pour

cette fin la table des marées précédemment chargée. Les résultats sont rapportés graphiquement

sur une figure que Matlab gère (Figure 4.13). À chaque niveau d'eau correspond une couleur sur

l'échelle des couleurs qui figure à droite du graphique. La représentation est en fait une projection

sur un plan 2D d'une modélisation en 3D (distance, temps et niveau d'eau) représentée par la

Figure 4.12.

Cha~itre 4 : Réalisation techniaue

Même courbes de niveaux d'eau de la Figure 4.13

Figure 4.12 : Modélisation 30 (Distance, temps et niveau d'eau).

Sur la figure des niveaux d'eau, une courbe délimite la hauteur de l'eau dans une zone

donnée. Toute la section qui se trouve à l'intérieur de cette courbe à l'exception d'une éventuelle

zone délimitée par une deuxième courbe possède le même niveau d'eau. Ce niveau est obtenu en

identifiant la valeur correspondante à la couleur.

Chavirre 4 : Réalisation techniaue

Figure 4.13 : Courbes des niveaux d'eau.

Le calcul et la présentation des niveaux d'eau se font pour la date de départ précisée par le

navigateur. Ceci est assuré par le fait que la table des marées utilisée pour les calculs est celle

correspondant à la date de départ du navire. Ces calculs sont supportés par la fonction Matlab

griddata qui fait une interpolation sur les heures et les distances. Elle trace en premier lieu le

niveau d'eau en chaque point correspondant à une heure et une distance données. En deuxième

lieu, elle trace la courbe du niveau d'eau en la faisant passer entre les points précédemment tracés

par une approche qui lui est propre.

est à noter que la variation des niveaux d'eau entre Montréal et Trois-Rivières ne

présente aucun souci quant à la sécurité des navires. Le niveau de l'eau est tout le temps suffisant

pour le passage des grands vraquiers. Ce n'est qu'à partir de Trois-Rivières et de proche en proche

vers Québec que ces variations se font sentir. Le niveau d'eau peut changer d'une valeur de 10

mètres et plus entre la période dufZot et celle du jusant (Voir définitions dans l'annexe 1).

Les variations des niveaux d'eau, qui sont parfois importantes, causent des problèmes de

sécurité pour les navires empruntant la voie navigable du Saint-Laurent. C'est pour cette raison

Chupitre 4 : Réalisation techniuue

qu'il faudrait connaître les heures des flots et des jusants qui permettront de mieux cerner les

zones interdites aux passages des navires.

2.4 Délimitation des zones interdites au passage du navire Chaque navire demande un niveau d'eau minimal pour qu'il puisse passer de façon

sécuritaire. La délimitation des zones interdites aux passages des navires se fait sur la base de ce

niveau d'eau (Sur la Figure 4.14, ce niveau est égal à 12m). Elle est réalisée selon le pseudo-

algorithme suivant :

1. Déterminer I'heure du flot (ou I'heure où on a le niveau d'eau le plus élevé).

2. Traiter la section du temps (représentant le jusant) avant l'heure du flot.

4 Parcourir la table des niveaux d'eau.

x Déterminer la distance minimale à partir de laquelle le passage est interdit (Xinn.

x Déterminer l'heure minimale à partir de laquelle le niveau d'eau serait insuffisant

pour un passage sécuritaire du navire (Yinf).

JC Déterminer l'heure maximale à partir de laquelle le passage du navire serait

sécuritaire (Ymax).

J Tracer les limites de la zone interdite au passage des navires en se basant sur les points

extremums précédemment identifiés.

3. Traiter de la même façon la section du temps représentant le jusant après l'heure du flot.

Figure 4.14 : Délimitation des zones interdites au passage des navires.

83

Cha_oitre 4 : Réalisation techniaue

2.5 Calcul et traçage des trajectoires des navires Le calcul des trajectoires des navires tient compte non seulement de la vitesse du navire

mais aussi des phénomènes des courants et des niveaux de l'eau le long du chenal de navigation.

Un navire qui quitte le port de Montréal à une heure donnée voit sa vitesse perturbée au

fur et A mesure de son avancement A cause des courants. De Montréal à Québec, on compte

presque 260 km de voie navigable qui sont divisés en 341 sections. Chaque section est

caractérisée par ses courants qui changent en direction et en intensité (Figure 4.15). Ces

caractéristiques sont spécifiées dans la table des courants pour chaque heure. Cette précision est

large. Le programme Matlab fait une interpolation et calcule une moyenne des courants chaque

quart d'heure. Si le navire franchit une nouvelle section de distance ou de temps, une nouvelle

valeur de l'intensité des courants est calculée. Cette valeur représente la moyenne de la valeur de

l'intensité du courant dans la section courante et de celle qui vient d'être franchie.

Temps

t+ 1

t

Variation du courant en intensité et en direction

T Distance

Figure 4.15 : Modèle de variation des courants en intensité et en direction.

En se basant sur la valeur de l'intensité du courant calculée, on peut déduire la vitesse

résultante du navire. En suivant cette approche, on peut calculer de proche en proche

l'avancement du navire et tracer sa trajectoire.

Temps A

t-t 1

t

-

Variation du courant en

Ir intensité et en direction

Trajectoire du navire

- - - -

Figure 4.I6 : Approche de traçage de la trajectoire du navire.

Le résultat final des calculs de la trajectoire d'un navire aboutit au schéma suivant :

I Frontière d'une zone interdite Zone i h rd i t e au au passage du navire passage du navire

Figure 4.17 : Exemple de calcul des trajectoires des navires

Chapitre 4 : Réalisation rechniaue

2.7 Calcul de I'heure de départ à suggérer au navigateur Sur l'exemple de calcul des trajectoires des navires de la figure précédente, il est à signaler

que le navire serait obligé de s'arrêter au milieu de son trajet à cause du niveau d'eau insuffisant.

Le progamme Matlab offre une procédure pour éviter cette situation coûteuse en terme de

consommation de carburants et entraînant des problèmes de pollution. Il calcule par une

procédure inverse l'heure à partir de laquelle le navire pourrait quitter le port de Montréal sans

arrêt le long de son voyage à direction du Québec. Le point de départ des calculs est le point

extremum correspondant à la limite de la zone interdite. Le pseudo algorithme générai de cette

procédure est le suivant :

Détecter si le navire a franchi une nouvelle section de distance ou de temps. Si la section de

temps courante est i alors la nouvelle section de distance est (i-1). Si la section de temps

courante est t dors la nouvelle section de temps est (t-0.25).

Calculer la moyenne de la valeur de I'intensité du courant entre la section courante est la

nouvelle section qui vient d'être franchie. Les valeurs de l'intensité des courants extraites à

partir de la table des courants sont multipliées par (-1) vu Ie sens des calculs.

CaIcuIer la nouvelle vitesse résultante du navire en tenant compte de la valeur de l'intensité

moyenne des courants.

Tracer Ia portion de Ia trajectoire jusqu'à l'atteinte d'une nouvelle section de distance ou de

temps.

Réitérer Ie processus jusqu'à I'atteinte du point de départ. L'heure obtenue en ce point de

départ est à suggérer au navigateur qui pourrait la prendre comme l'heure de départ au plus tôt

de son navire.

Chapirre 4 : Réalisation techniaue

Le calcul de l'heure à suggérer au navigateur pour l'exemple précédent aboutit au résultat

suivant :

Heure à suggérer Heure de dkpart choisie par le navigateur

Figure 4.18 : Calcul de l'heure à suggérer au navigateur.

2.8 Formatage des résultats Vu les restrictions au niveau de JmatLink en terme de possibilités d'interfaçage entre Java

et Matlab, la communication des résultats entre le programme Matlab de planification des

itinéraires et l'agent Fédérateur se fait sous forme d'échanges de chaînes de caractères. Après

l'achèvement des calculs des trajectoires du navire et la suggestion éventuelle d'une heure de

départ, le programme Matlab formate un tableau de chaînes de caractères dans lequel seront

stockés les resultats des calculs. Entre autres, ce tableau contient les informations concernant les

trajectoires correspondant aux heures de départ au plus tôt et au plus tard du navire (heure de

départ, heure et lieu de l'arrêt éventuel du navire, heure d'arrivée à Québec). Il contient aussi les

informations à propos de l'heure à suggérer au navigateur ainsi qu'à propos de la trajectoire

cha~i t re 4 : Réalisation technioue

correspondante. La transmission des résultats se fait grâce à la fonction engGeMrray de

JmatLink.

2.9 Conclusion La planification des itinéraires qu'assure le programme Matlab passe par les tâches des

calculs des trajectoires des navires ainsi que par la suggestion des heures de départ afin d'éliminer

tout arrêt probable des navires le long de leurs trajets. Ces calculs sont supportés par des

représentations graphiques qui permettent de mieux visualiser la situation.

L'architecture ouverte qu'offre I'approche rnultiagent permet de profiter de la puissance

des applications existantes. Dans le présent cas, le système multiagent conçu profite pleinement

de la puissance de Matlab en terme de simulation, de calcul et de représentation graphique. Cela

prouve une fois de plus l'utilité et l'adaptabilité de l'approche multiagent dans le domaine des

applications marines.

Chapitre 5 : Discussion des résultats et ~ersaectives

Discussion des résultats et perspectives

1. Discussion des résultats

2. Perspectives

Chavitre 5 : Discussion des résultats et persvecrives

1. Discussion des résultats Le présent travail fournit une maquette de planification des trajectoires des navires sur le

Saint-Laurent. Ce chenal présente plusieurs contraintes de navigation changeant en fonction du

temps et de l'espace.

La planification des trajectoires est effectuée en fonction des facteurs marées et courants

qui règnent dans le chenal et en se basant sur des paramètres concernant le navire (Date et heures

de départ et la vitesse). Elle consiste en un calcul et un traçage des trajectoires des navires pour la

date et les heures de départ spécifiées par le navigateur. Ce dernier peut assimiler notre logiciel à

un système d'aide à la décision. En effet, pour une date de départ mal choisie et pouvant affecter

la sécurité du navire, l'outil calcuie et propose une nouvelle heure de départ. Les dangers émanent

généralement des zones ne possédant pas le niveau d'eau nécessaire au passage du navire.

Techniquement, notre système comporte un système multiagent formé des agents Navire,

Marée, Courant et Fédérateur et qui s'interface avec un programme Matlab qui assure la tâche de

planification des itinéraires. Ce système donne une interface, en l'occurrence celle de l'agent

Navire, par laquelle le navigateur communique avec le reste du système en spécifiant les

paramètres de son navire et de son départ.

En se basant sur les informations saisies par le navigateur, le système déclenche un

processus de traitements et de calculs qui est réalisé conjointement par plusieurs programmes et

agents. Chacun d'entre eux contribue à la résolution du problème en fonction de ses capacités.

Cette architecture met l'accent sur le partage des tâches entre plusieurs systèmes en coopération :

Un problème initialement complexe peut être décomposer en plusieurs sous-problèmes dont les

résolutions sont assurées chacune par un p r o g r m e indépendant. Ces programmes ne sont pas

obligatoirement compatibles, il va de même pour les systèmes sur lesquels ils sont implantés.

L'utilisation des systèmes multiagents permet non seulement le partage des tâches mais

aussi l'interconnexion des différents programmes malgré leur hétérogénéité. Cette approche

présente tous les avantages de la stratégie de partage des tâches en terme de traitements parallèles

et donc de gain en temps d'exécution. Elle permet aussi la réutilisation des solutions déjà

existantes et qui pourraient fournir une partie de la solution globale.

Chu~itre 5 : Discussion des résultats er ~ers~ecr ives

Dans notre cas, le système multiagent mis en place découpe le problème de planification

des itinéraires en un ensemble de tâches : Gestion de la contrainte des marées, gestion de la

contrainte des courants, calcul des trajectoires des navires, etc. Chacune de ces tâches est

supportée par iin programme indépendant. Certes, ces programmes n'offrent pas un degré de

sophistication élevé, mais permettent de simuler un cas réel dans lequel des systèmes

professionnels coexistent et coopèrent pour résoudre le problème. C'est ainsi qu'au lieu d'utiliser

un module de prédiction des courants, on se contente d'utiliser une table de courants dans laquelle

sont indiquées les différentes valeurs de l'intensité du courant pour chaque heure et au niveau de

chaque section de distance définie le long du chenal.

Le sous-système de planification des itinéraires démontre un résultat important : Prouver

la pertinence de l'utilisation de l'approche multiagent dans le domaine des applications marines.

Cette approche est bel et bien adaptée au domaine marin et possède tous les atouts pour améliorer

la gestion de la navigation sur le Saint-Laurent. On peut aussi avancer que cette approche semble

être appropriée à des problèmes analogues tel que la gestion du Port de Montréal ; un problème

dépendant de plusieurs paramètres dynamiques.

Les différentes contraintes de navigation énumérées à travers ce mémoire montrent la

difficulté de concevoir une solution globale au problème de planification surtout qu'elles varient

de façon spatio-temporelle. Les organismes québécois, responsables de la gestion de la

navigation sur le chenal Saint-Laurent, ont conçu plusieurs systèmes. Chacun de ces systèmes

apporte une solution à une contrainte spécifique. Le niveau de coopération entre elles est

généralement quasi-absent. En conséquence, le problème de planification des itinéraires est

résolu par plusieurs systèmes complémentaires, hétérogènes et indépendants. Cette résolution est

caractérisée par l'intervention humaine fréquente entre autres pour fournir les résultats de

l'exécution d'un système donné ou encore la collecte des informations nécessaires au bon

fonctionnement d'un autre système.

Dans cette configuration, la résolution du problème de la planification des itinéraires est

dépendante étroitement des organismes propriétaires des systèmes contribuant à la solution

globale. En conséquence, le navire ne possède aucune autonomie lors de son passage dans le

chenal. En effet, il doit appliquer les directives qui lui sont dictées par des responsables de la

garde côtière.

Le systeme multiagent mis en place se distingue dans ce sens par le degré d'autonomie

qu'il permettrait d'offrir aux navigateurs. Outre le fait que le navigateur saisit les informations

concernant son navire, il peut décider de son heure de départ en se basant sur ce que le système

91

Chauitre 5 : Discussion des résulîats et ~erspectives

lui suggère cornme nouvelle heure si l'heure proposée initialement s'avère mal choisie. Le

navigateur peut, donc, décider de son départ en se référant aux calculs de notre outil de

planification des itinéraires mis en place. De plus, I'outiI calcule l'heure d'arrivée du navire. Ceci

permet, non seulement, une meilleure planification des activités sur le Saint-Laurent mais aussi

une meilleure planification des activités dans les ports telles que leurs accès et le transport des

marchandises.

En résumé, l'ensemble des résultats obtenus par ce travail est :

- L'utilisation de l'approche multiagent est bien appropriée au domaine des applications

marines.

- L'approche multiagent permettrait d'améliorer la gestion de la navigation dans le fleuve du

Saint-Laurent en offrant le moyen de faire coopérer les solutions existantes même en présence

d'hétérogénéité.

- La mise en œuvre d'une maquette qui permet la planification des itinéraires dans la section du

fleuve Saint-Laurent entre Montréal et Québec.

- Le calcul et le traçage des trajectoires des navires en tenant compte des marées. des courants,

de l'heure de départ de ces navires ainsi que de leurs vitesses.

- La représentation des niveaux d'eau sous formes de courbes sur des figures qui représentent

une projection 2D d'une figure 3D (distance, temps, hauteur).

- La réalisation d'un système qui pourrait donner de l'autonomie aux navigateurs ; Une facilité

absente dans tous les systèmes de navigation en vigueur.

- La mise en œuvre d'un système d'aide à la décision qui permettrait au navigateur de mieux

choisir ses heures de départ.

- Le système mis en œuvre permettrait dlarnéIiorer la gestion des activités telles que les

activités portuaires. En effet, ce système permet de prédire la date d'arrivée du navire, ce qui

permettrait de minimiser les attentes fréquentes à cause de l'incertitude à propos des amvées

des navires.

- La diminution de la consommation des carburants et par conséquent la diminution de la

pollution en évitant les arrêts et les réductions des vitesses le long des voyages des navires.

Chauirre 5 : Discussion des résultats er pers~ectives

2. Perspectives La maquette mise en œuvre dans ce présent mémoire avait pour but principal de prouver

l'utilité et l'adéquation de l'utilisation de l'approche multiagent dans Ie domaine des applications

marines. Certes, ce but est atteint, mais certaines améliorations peuvent être apportées sur la

maquette.

Le système résultant de ce travail ne tient pas compte de toutes les contraintes de

navigation. L'absence de la prise en compte des effets de la glace et des vents, par exemple, n'est

pas un choix stratégique. Ceci est dû à l'absence d'accords avec les organismes propriétaires des

systèmes en vigueur pour la gestion de teIIes contraintes de navigation. D'ailleurs, les agents

Marée et Courant employés dans le système multiagent mis en place se contentent d'envoyer

respectivement via des connexions ClientKerveur les tablss des marées et des courants. Leurs

tâches peuvent être plus complexes si on intègre des systèmes professionnels de gestion et de

prédiction des phénomènes des marées et des courants.

Grâce à I'architecture ouverte du système multiagent mis en œuvre, l'intégration de

nouveaux systèmes de gestion de nouvelles contraintes de navigation (Exemple : glace, vents) est

aisée. Il suffit de créer un nouvel agent wrapper qui intègre le système mu1 tiagent existant et qui

fait interface entre ce système et la nouvelIe solution adoptée.

Du côté du navire, certains paramètres peuvent influencer sa trajectoire. On peut citer

entre autres ses dimensions (largeur et longueur), son enfoncement dans l'eau ainsi que son

dégagement sous-quille. L'influence de ces facteurs n'est pas très grande. Néanmoins, on peut

dédier au navire un système pour renseigner le système multiagent sur les propriétés du bateau.

Son intégration peut se faire dans une étape suivante par un nouvel agent qui lui permet de

s'interfacer avec le système global.

Finalement, on peut intégrer un nouveau système qui fournit les informations en relation

avec les consignes des organisations qui gèrent la navigation sur le Saint-Laurent. Ces

informations ont trait à :

- La limitation de la vitesse des navires dans certaines sections du chenal.

- La localisation des autres navires le long du trajet et surtout dans les zones étroites grâce au

système de positionnement géographique GPS.

- Les avertissements concernant les tempêtes éventuelles ainsi que la réduction de la visibilité

qu'elles entraînent.

Cha~itre 5 : Discussion des résultats er persvectives

En se basant sur l'ensemble des perspectives mentionnées, on peut dresser une

architecture d'un système multiagent global comportant tous les systèmes avec lesquels

s'interface. Cette architecture est présentée dans la figure suivante :

Système de gestion d d g a g e m ; y

sous-quille, etc.

Systbme de prédiction des

marées

Système de prédiction des

courants

Agent Interface Agent Marée Navigateur

! !

1 Agent News 1 / Agent Vent 1 / Agent GLoce 1

gestion du vent gestion de la glace

Figure 5.1 : Architecture du s y s t h e muIfTagent proposé en perspective.

Cha~irre 5 : Discussion des résultats et ~ers~ec t ives

Remarques

L'agent interface Navire remplace 1 'agent Navire dans 1 'ancienne architecture. Il permet de

recueillir les informations saisies par le navigateur.

L'agent Navire fournit les informations relatives au dégagement sous-quille du navire ainsi

que toute autre information pertinente aux calculs.

La banque de données modélise les informations pertinentes aux calculs telle que les

limitations des vitesses dans certaines sections du fleuve pour éviter les probabilités d'inonder

les installations sur le bord du fleuve et diminuer l'enfoncement des navires dans l'eau.

L'architecture proposée est calquée sur celle du système mis en place. Toutefois, pour des

raisons de coopération directe entre les différents agents, elle peut être modifiée.

Conclusion

La navigation sur le fleuve Saint-Laurent est sujette à plusieurs perturbations et problèmes

de sécurité des navires. Les différentes contraintes énumérées dans ce mémoire telles que les

marées, les courants et la glace en sont des causes. La variation de ces contraintes en fonction du

temps et de l'espace complique la tâche des organismes canadiens qui gèrent la navigation sur le

chenal. Cette tâche de gestion du trafic maritime est encore difficile en présence des facteurs

instables et non cycliques tels que les tempêtes qui entraînent des réductions de visibilité

considérables lors des périodes hivernales.

Quoique des éléments de solution performants pour le problème de la gestion de la

navigation soient en usage actuellement, on relève encore plusieurs limitations dont le fait que

ces solutions ne gèrent, généralement, qu'une seule contrainte à la fois, que la coopération entre-

elles est quasi-absente et enfin le fait qu'elles n'offrent aucune autonomie aux navigateurs.

Pour tirer profil au mieux des solutions proposées pour la gestion de la navigation sur le

Saint-Laurent, il est judicieux de les rassembler dans un seul système qui gère toutes les

contraintes et dans lequel les différentes solutions pourraient coopérer et échanger résultats et

informations.

Afin de réaliser de tel système, nous avons employé l'approche multiagent qui offre divers

avantages tels que la possibilité de réutilisation des solutions existantes et l'architecture ouverte

des systèmes qu'elle permet de construire.

Le système multiagent que nous avons conçu prouve que l'approche multiagent est bien

appropriée au domaine des applications marines. I1 permet de surpasser les contraintes

d'hétérogénéité qui existent entre les solutions existantes. Ce résultat est important ; Les

responsables de la gestion de la navigation sur le Saint-Laurent peuvent constituer un système

-- - -

global à base d'agents qui prend en considération toutes les contraintes de navigation et qui

permet la planification des trajets des navires dans le chenal.

L'outil développé lors de ce mémoire permet d'appuyer cette affirmation. En effet, il

permet de réaliser la planification des itinéraires sur le Saint-Laurent. Il calcule et trace les

trajectoires des navires en se basant sur leurs dates et heures de départ ainsi que sur leurs vitesses.

Il donne des suggestions concernant les heures de départ mal choisies pour assurer la sécurité des

navires en évitant les zones à faible niveau d'eau. De plus, cet outil permet de simplifier la

complexité du problème initialement dans un espace 3D (temps, distance, hauteur) en le projetant

dans un espace 2D (temps, distance).

Notre outil apporte une facilité inexistante dans les systèmes existants en offrant

l'autonomie aux navigateurs qui, jusqu'à date, ne font que suivre les consignes de la Garde

Côtière.

À travers ce travail et en se basant sur les résultats et les perspectives me~tionnés dans le

chapitre précédent, nous avançons les recommandations suivantes :

- Concevoir et implémenter un système multiagent qui fait coopérer des solutions de gestion

des contraintes de navigation en vigueur telles que Atlas pour la prédiction des marées,

UKCG pour la gestion du dégagement sous quille du navire, INNAV, etc.

- Concevoir et implanter un système multiagent pour le problème de gestion des activités

portuaires.

- Faire coopérer, si ia nécessité se présente, les deux systèmes pour mieux &er la navigation

sur Ie Saint-Laurent ainsi que l'accès au Port de Montréal.

- Impliquer davantage les navigateurs dans la tâche de la gestion de la navigation sur le Saint-

Laurent.

Bibliographie

[l] : A. Taschereau, G. Ringuette et P. Hally, «La navigation électronique sur le fleuve St-

Laurent», Conférence Hydrographique canadienne 1996

[2] : http://www.chs-shc.dfo-mpo.gc.calchs~hq/contour/con94S/podeM.h, «Le port de

Montréal à l'avant garde», consulté le 23/12/2000

[3] : B. Moulin (October 19991, «Software Agent Technology for Intergrating Dynamic Spatial

Systerns in Marine Applications»

[4] : h t t p : / / w w w . s e a w a y . c a / f r a ~ c a i s / c a r a c t e ~ d i s e s . h t , «Réseau Grands Lacs/

Voie maritime du Saint-Laurent», consulté le 23/12/2000

[5] : h t t p : / / w w w . c c p g c c . g c . c d ~ b s - b s d s b g - g s n / «Incidents liés à la navigation de

plaisance au Canada», consulté Ie 21/12/2000

[6] : http://www.tc.gc.ca/TDC/news/ssafef.htrn, «La navigation électronique sur le Saint-

Laurent», consulté le 2 1/12/2000

[7] : http://www.sodes @ st-laurent.org/francais/info.htm, «Le Saint-Laurent est un géant

économique», consulté le 23/12/2000

[8] : http://www.lavoile.com/stlau.htm, «LE SAINT-LAURENT, Petite histoire du Saint-

Laurent», consulté le 23/12/2000

[9] : B. Morse, N. Crookshank (1998), «The candian Coast guard's environmental prediction

decision support system five years in the making», première conférence internationale sur les

technologies de l'information pour la prise de décision dans le génie civil, Montréal, Canada du

1 1 au 13 octobre 1998

[IO] : B. Morse, M. Lachance, G. Marceau, <<Measuring Under-Keel Clearance of Ships Using

GPS-OTF Technology », Conférence Hydrographique canadienne 1996

[ I l ] : P. Lacroix, J. Kightly, «An Under Keel Clearance Guide System for Ports and

Waterways», Conférence Hydrographique canadienne 1996

[12] : Édition de Gerhard Weiss, aul t iagent Systems, A Modem Approach to Distributed

Artificial Intelligence»

[13] : Jack Krupansky, «Software Agents», http://www.basetechnoloo~.com/AGENTS.HTM,

consulté le 13/12/2000.

1141 : Brahirn Chaib-Draa, «Agents et systèmes multiagents (notes de cours ET 6488 1 A)»,

Département d'informatique, Faculté de science et de génie, Université Laval, Québec, Novembre

1999.

[ 151 : J. Feber, «Les systèmes multiagents, vers une intelligence collective», ZnterEditions 1995.

Cl 61 : H. Mintzberg, «The structuring of organizations», Englewoods Cliffs 1979.

[17] : Computer & Network Systems Laboratory, Corporate Research & Development Center

TOSHlBA Corporation, http://www2.toshiba.co.ip/bee,aent/index.htm , consulté le 20/12/2000

[18] : N. Zykov, J-M. Lukowski <<Aide sur Java»,

http://www.dyadel.net/iean-mi/Proiet/Pravaht , consulté le 1 g / O W O O 1.

[19] : Société iware dava en bref», ht~://www.dvadel.net/iean-rni/Proiet/ProietJava.htm

consulté Ie Ig/O4/2OO 1.

[20] : Mathworks «MATLAI3 - Présentation générale»,

http://www.mathworks .com/products/rnatlab/description/overview.shtml , consulté le

l9/O4/2OO 1.

[2 T ] : E. S. Maloney, <<Navigation & Piloting», NAVAL INSTITUTE PRESS, Annapolis,

Maryland.

[22] : Computer & Network Systems Laboratory, Corporate Research & Development Center

TOSHIBA Corporation, http://www2.toshiba.co.ipheeo;entlacl/acl.htm , consulté le 20/12/2000

[23] : T. Finin, R. Fiitxson, D. McKay, HA Language and Protocol to Support Intelligent Agent Interoperability», Proceeding of the CE \& CALS Washington '92 Conference, Juin 1992

A n n e x e s

Le phénomène des marées et des courants [21]

1. Les marées Sous l'influence des forces gravitationnelles et centrifuges entre la terre d'une part et la

lune et le soleil de l'autre part, le niveau de la mer subit des montées et des descentes

périodiques. Ce mouvement vertical de l'eau. reconnu sous le nom de la marée (tide), est

dépendant de plusieurs facteurs outres les forces mentionnées ci-dessus et acquiert une

importance majeure surtout lorsqu'il s'agit de la sécurité des navires dans des passages de

niveaux d'eaux faibles.

Les conditions locales, telles que le vent et la configuration des côtes, peuvent influencer

la variation de la marée. L'expérience montre l'existence d'un cycle formé de deux montées ainsi

que de deux descentes d'eau de façon alternative et qui s'étale sur une journée lunaire (presque

24h 50mn). Le cycle d'après sera décalé de presque 50 minutes.

Conformément aux différentes étapes dudit cycle, on parle de :

La montée de la mer qui est connue sous le nom de la marée montante ouflot (high tide ou

high water).

La descente de la mer qui est connue sous le nom de la marée descendante ou jusant (low

fide ou low water).

L'étale de lu pleine mer (stand) qui survient à la fin du flot lorsque le niveau de l'eau reste

sensiblement constant durant un certain temps. Le même phénomène est observé à la fin du

jusant et est dit l'étale de la basse mer (stand).

L'intervalle de la marée (range of tide) : C'est la différence entre le niveau de la montée

totale et celui de la descente totale.

Le niveau de mer moyen (mean sea level) : C'est la hauteur moyenne de la surface de la mer

pour tous les états de la marée.

Le niveau de la mi-marée (halftide level) : c'est le plan intermédiaire entre la moyenne du

flot (mean high water) et la moyenne du jusant (mean low water).

1.1 L'effet de la lune Les océans sont affectés par les forces d'attraction entre la terre et la lune ainsi que par les

forces centrifuges résultant de leurs révolutions autour d'un centre commun situé à 1500 km

presque (810 miles) dans la terre sous sa surface. Ces deux types de forces sont en équilibre, ce

qui évite toute collision de la terre et de ia lune et empêche Ieur éloignement l'une de l'autre.

1.1.1 Les forces centrifuges

Ces forces sont les mêmes n'importe où sur la terre du moment que tout point sur sa

surface décrit le même mouvement autour du centre de masse commun. Elles sont parallèles

l'une à l'autre et parallèles à la ligne joignant le centre de la terre a celui de la lune.

1.1.2 Les forces gravitationnelles

Ces forces ne sont pas les mêmes en tout point de la terre. Plus on est proche de la lune,

plus la force gravitationnelle est importante. Sa direction est du point où on est vers le centre de

la lune. Cette configuration n'implique pas de parallélisme entre ce type de forces, et ce à

l'encontre des forces centrifuges.

La combinaison des deux forces précédemment mentionnées donne une résultante plus ou

moins importante. Son effet se traduit par l'écoulement de l'eau d'un point vers un autre ce qui

entraîne une variation des niveaux de l'eau en chacun de ces points

La rotation journalière de la terre autour de son axe, fait changer la ligne de direction vers

la Iune donnant en chaque point deux montées ainsi que deux descentes de l'eau. Ces montées et

Ces descentes ne sont pas de niveaux égaux vu l'inclinaison des axes de la terre.

1.2 L'effet du soleil

Certes le soleil est plus grand que la lune. Son effet sur la terre est moindre vu la grande

distance qui sépare les deux planètes.

Lorsque les trois astres (terre, lune et soleil) sont alignés (cas de la nouvelle lune ou de la

pleine lune), la terre subit une influence plus grande qui résulte de l'action commune des deux

autres planètes sur elle. La conséquence de ce phénomène est un niveau de marée supérieur à la

moyenne du flot et un autre niveau inférieur à la moyenne du jusant ; c'est la période des grandes

marées ou vives-eaux (spring Mes).

I Deux positions possibles de la lune I Figure AI.1 : Dispositions de Za tene, la lune et le soleil lors des vives-eaux.

Après cette période, l'amplitude de la marée décroît, on dit que les marées perdent.

Lorsque la disposition des trois planètes change, on assiste à d'autres phénomènes. Ainsi, lorsque

la lune et le soleil sont à 90" l'une de l'autre (premier et troisième quart de la lune), l'effet du

soleil contre partiellement celui de la lune. L'amplitude des marées est, donc, inférieure à la

normale pour les flots et pour les jusants. Cette période est celle des petites marées ou mortes-

eaux (neap tides).

Positions lune

Premier quart de la lune

possibles d e la

O Dernier quart de Ia lune

Soleil

O

Figure AL2 : Dispositions de k ferre, la lune et le soleil lors des mortes-eaux.

La lune tourne autour de la terre une fois chaque mois lunaire qui dure presque 28 jours.

Son passage par n'importe quel méridien sur terre se fait chaque 24h 50mn : c'est la période

requise pour deux flots et deux jusants et qui forme une journée marée (fida2 day). La période

d'un flot et d'un jusant est parfois désignée par un cycle marée (Mal cycle).

1 O3

Annexe 1

1.3 Types des marées Un corps d'eau a une période naturelle d'oscillation qui dépend de ses dimensions. Un

océan n'est pas perçu comme étant un corps d'oscillation à part entier, mais plutôt comme un

ensemble de bassins d'oscillation. Les réponses de ces bassins aux forces causant les marées ne

sont pas uniformes. Ainsi, certains répondent plus rapidement aux forces diurnes (diurnal

forces), d'autres aux forces semi-diurnes (semi-diurnal forces). Il en existe d'autres qui

répondent de façon presque égale aux deux types de forces. Selon le type de réponse, on classe

les marées en serni-diurnes (semidiumal), diurnes (diurnal) et mixfes (mixed) et ce

conformément aux caractéristiques du plan des marées en vigueur en ce lieu.

- Marée semi-diurne : Dans ce type de marée, il existe deux flots et deux jusants chaque

journée marée avec une petite inégalité relative des hauteurs des marées montantes et celles

descendantes consécutives.

- Marée diurne : Dans ce type de marée, il existe seulement un flot et un jusant chaque journée

marée.

- Marée mixte : Dans ce type de marée, les oscillations diurnes et semi-diurnes sont deux

facteurs importants. La marée est caractérisée par une large inégalité dans les hauteurs des

flots, dans celles des jusants ou les deux. Il existe toujours deux flots et deux jusants chaque

jour, cependant la marée peut occasionnellement devenir diurne.

La notion de l'amplitude des marées a été abordée jusque là sans aucune mention de la

référence à partir de laquelle on Ia calcule. Le paragraphe suivant précise le niveau à partir duquel

on peut mesurer l'amplitude de la marée.

1.4 Plans de référence pour les données des marées

Pour soulever toute confusion probable, la notion de l'amplitude de la marée (height of

tide) n'est pas la même que profondeur de l'eau (depth of water). Cette dernière réfère à la

distance verticale depuis la surface de I'eau jusqu'à son fond. La première est la distance

verticale depuis la surface de I'eau jusqu'à un niveau choisit arbitrairement ; c'est le plan de

référence (reference piune ou dnturn). Ce plan n'est pas un standard. La France le prend comme

étant le niveau des plus basses mers connues. L'Angleterre, quant à elle, le choisit comme étant le

niveau des basses mers moyennes de vives-eaux. Dans la suite, on se basera sur la moyenne des

basses-eaux (average of low water) comme étant le plan de référence retenu. On définit ainsi :

- Charîed depth : c'est la distance verticale depuis le plan de référence jusqu'au fond de la mer.

q e w el ap Jnajney + qadap paueyo = nea.1 ap mapuopld

: nva '1 ap ~napuojo-rd

~1 ap 1 n 3 p al mod a~duqs apuuoj ana3 ' ~ u o p 'a%x?%?p uo -a?leur el ap smalntq s a u y ~ a 3

ap sa~!le3?u s m a p sap md (sqqvj app) sa?mur sap s q q q sap ma+u ne au-mad?~ as u o y ~ n q s

aila3 y j d a p paj~vzp y amapaju! aqê inad m a . [ ap mapuojo~d el anb anbgdui! eIa3 .may?ju! al,?

!nl inad ma,] ap waniu al '~uaurn~op a3 suep !s!oqa a ~ u a q j ? ~ ap uqd ne ~uarn?mropo;)

-séqmt.u sa1 rnod a m q i f i a ~ ap uqd : E-IV arn%j

d'Amérique (Groenland inclus), les côtes Ouest du Nord et du Sud d'Amérique (les îles Hawaï

inclues) et les océans Pacifique et Indien centraux et nordiques. Ces volumes contiennent les

prévisions journalières de presque 197 ports de référence (reference ports) ainsi que des données

pour presque 6000 stations.

1.5.1 Stations références

Le premier volume de la table des marées est donné via l'extrait formulé dans le Tableau

1. Cet extrait représente une table dans laquelle sont listées l'heure et la hauteur de la marée à

chaque flot et à chaque jusant dans leurs ordres chronologiques, pour chaque jour de l'an et en un

nombre de places spécifiques désignées par stations références (reference stations).

HUMBOLDT BAY, CALEFORNIA 19ï7

HORAIRES ET HAUTEURS DES FLOTS ET DES JUSANTS

Avril Mai Juin

Jour Heure H.T Jour Heure HT Jour Heure H.T Jour Heure HT Jour Heure H-T Jour Heure HT

h.m ft. Hm ft. h m k Hm ft h.m ft. Hm ft.

Tableau 1 : Extrait du premier volume de la table des marées.

VU que le jour lunaire ou la journée marée dépasse 24 heures par 50 minutes presque. le

temps entre deux flots ou deux jusants successifs est plus de 12 heures. Quand un flot (ou un

jusant) survient juste avant minuit, son successeur apparaît vers midi le jour d'après. Le suivant

prend place juste après minuit. Sous ces conditions, trois flots (ou jusants) consécutifs peuvent

s'étaler sur trois jours.

Remarque

Durant certaines portions du mois, la marée devient diurne en certaines stations.

L'existence d'un seul flot et d'un seul jusant dans ce type de marée se répercute au niveau de la

table par un blanc.

1.5.2 Stations secondaires

Le second volume des tables de marées liste les stations secondaires (secondry ou

subordinare stations). Pour chacune de ces stations, est donné un numéro, une description de sa

localisation, sa position dans la latitude et la longitude à la plus proche minute. Le calcul des

horaires et des hauteurs de la marée en une station secondaire se fait à partir d'une station de

référence imprimée dans la même table.

Les autres formes des tables des marées donnent plusieurs informations qui concernent

entre autres les levées et les couchées du soleil et de la Iune, la méthode de conversion du temps

local en temps standard, etc.

1.6 Conclusion La connaissance de la hauteur des marées peut être d'une importance majeure pour un

navigateur lors de la traversée d'un canal à faible profondeur d'eau ou lors du passage au-dessous

d'un pont. Les tables des marées sont dans de telles circonstances très utiles. Cependant, à la suite

des vents persistants et forts, les valeurs disponibles dans ces tables peuvent être perturbées. Le

navigateur doit être capable de calculer rapidement et précisément le niveau de la marée en un

point donné à un moment donné et indépendamment du type de la station.

2. Les courants et leurs prédictions

2.1 Introduction

Les marées, étudiées dans la partie précédente, est le mouvement de I'eau de façon

verticale suite aux actions de la lune, du soleil et de maints autres facteurs. Ce phénomène n'est

pas le seul qui agit sur la hauteur de l'eau, on trouve aussi le courant (current) qui possède une

grande importance et qui se présente comme étant le mouvement horizontal de l'eau. Les effets

des courants peuvent être néfastes sur un navire ; Ils peuvent changer sa direction, diminuer sa

vitesse et parfois les deux.

La montée et la descente périodique et la marée ainsi que les mauvaises conditions

climatiques de long terme, sont les principaux facteurs qui causent les courants. Ils interviennent

parfois pour nuire au système normal des courants, soit par accentuation de leurs vitesses (dr@

ou speed), soit par changement de leurs directions (set).

2.2 Systèmes des courants des océans Le mouvement des courants dans les océans ouverts forme un système permanent et assez

bien connu. Il est causé en majeure partie par ies vents qui souffient dans la région. La

persistance d'un vent dominant, foa et de même direction détermine grandement la direction, la

vitesse, la profondeur et la permanence des courants qu'il génère. Néanmoins, les courants, dont

la vitesse est orientée vers le sud ou vers le nord, sont affectés par les forces de Coriolis (Coriolis

forces). Ce sont des forces résultant de la rotation de la terre et qui s'exercent sur tout corps en

mouvement. Elles sont responsables largement de la configuration circulaire des flots lents des

courants au nord et au sud de l'Atlantique et du Pacifique ainsi que dans l'océan Indien.

Le phénomène àes marées est une succession de montées et de descentes de I'eau. Cette

situation se traduit par un mouvement d'une quantité d'eau d'un point vers un autre, ce qui fait

entrer le point origine dans sa période de jusant et le point destination dans sa période de Rot. Ce

mouvement de va et vient est à l'origine des courants de marées (tidal currents). Ce phénomène

est de moindre importance dans les hautes mers, mais se voit attribué une ampleur significative

dans les côtes et les zones de basses profondeurs. On distingue deux types de mouvement

horizontal de I'eau. Le premier est vers la terre et est nommé courant deflux (flood current) et le

second est dans le sens inverse et est désigné courant de r e p w (ebb current). Entre ces deux

mouvements, il existe une brève période de changement de direction lors de laquelle le

mouvement horizontal de I'eau est quasiment nul ; C'est l'eau morte (slack water).

La répartition des courants les plus rapides n'est pas uniforme. Ainsi, dans les portions

droites d'un fleuve, les plus rapides de ces courants sont généralement localisés au milieu.

Cependant, dans les zones curvilignes, ils sont décalés du côté du bord externe de la courbe.

2.3 Prédiction des courants des marées

Annuellement, des tables de prédiction des courants des marées sont publiées. Elles ont

un format similaire à celui des tables des marées et sont utilisées de façon presque pareille. On en

distingue :

- Table 1 : elle donne les prédictions des horaires des mortes-eaux ainsi que la prédiction des

vitesses des courants des flux et des reflux maximums pour chaque jour de l'année.

--

- Table 2 : elle contient une liste de stations secondaires arrangées dans un ordre géographique.

Pour chacune de ces stations, on donne entre autres sa position en terme de latitude et de

longitude à la plus proche minute, sa station de référence et les rapports de vitesses des flux et

des reflux maximums.

- Table 3 : elle sert à déterminer la vitesse du courant à n'importe quel moment entre la morte-

eau et le courant maximal.

- Table 4 : elle est utilisée pour trouver la durée des mortes-eaux.

2.4 Conclusion Les courants sont généralement causés par les marées ainsi que par les conditions

climatiques en vigueur. La configuration des côtes et des fonds marins influent de leurs côtés ce

phénomène. Le courant subit, de plus, l'ampleur de la force de Coriolis qui s'exerce sur tout

corps en mouvement.

Les publications annuelles des prévisions des courants présentent un aide précieux pour

les navigateurs, qui, sous des conditions particulières de brume se voient obligés d'entamer des

calculs conjointement à l'utilisation de la sonde et ce pour répondre à une question majeure : ou

suis-je ?

ACL : Agent Communication Language 1221 ACL est un langage de communication d'agents basé sur la théorie speech-act. Cette

théorie est basée sur le paradigme des performatifs qui représentent des actions effectuees lors

des conversations entre les communiquants. Lorsqu'un agent envoie un performatif à un autre

agent du système. il exprime son intention d'agir. Il peut ainsi demander de l'information ou en

passer. Il peut demander aussi que l'autre agent lui effectue un service. À titre d'exemple, le

performatif request exprime le fait que l'agent expéditeur demande à l'agent destination

l'exécution d'un ensemble d'actions. L'agent destination a le choix d'accepter ou de refuser cette

demande.

Le tableau ci-dessous résume tous les performatifs de ACL que Bee-gent supporte :

Performatif

I n f o m

&-fP

Propose

1 Agree

Refuse t--

Fonctionnalité 1 L'expéditeur demande au récepteur de lui exécuter certaines

actions. I - - -- .-- . - -. - .

L'expéditeur interroge-le récepteur à propos de certaines

informations que ce dernier ne connais pas.

L'expéditeur informe le récepteur de certaines informations. Ces

informations sont connues par l'expéditeur.

L'expéditeur fait un appel pour avoir des propositions d'exécution

de certaines actions.

'=S SOUS L'expéditeur propose d'exécuter des actions spécifiqu,

certaines préconditions.

L'expéditeur accepte la proposition d'exécuter certaines actions qui

lui sont présentées à l'avance.

L'expéditeur rejette la proposition qui Iui est présentée.

L'expéditeur est d'accord pour exécuter certaines actions.

L'expéditeur refuse d'exécuter certaines actions parce qu'il n'est pas

capable de le faire.

L'expéditeur notifie qu'il a essayé d'exécuter certaines actions et

qu'il a échoué pour des raisons qu'il spécifie. I L'expéditeur notifie qu'il n'a pas comprit le message qu'il a reçu.