Architecture Basée Agents pour le

République Algérienne Démocratique et Populaire

Ministère de l'Enseignement Supérieur Et de la Recherche Scientifique

Université d’Oum Bouaghi Larbi Ben M’hidi

Faculté des Sciences Exactes et Sciences de la Nature et de la Vie

Département de Mathématiques et informatique

Mémoire

Présenté en vue de l’obtention du diplôme de MASTER EN INFORMATIQUE

Option

Architectures Distribuées

Présenté Par

MELITI NEDJEMA

DEVANT LE JURY

PRESIDENT M.GUERRAM Tahar MCB Université d’Oum Bouaghi

EXAMINATEUR M.ACHICHI Boubakeur MAA Université d’Oum Bouaghi

ENCADREUR Mme.KOUAH Sofia MCB Université d’Oum Bouaghi

Promotion Juin 2017

Architecture Basée Agents pour le

diagnostic d’un système d’IoT (Internet of

Things)

ii

Remerciement

Je tiens à la fin de ce travail à remercier ALLAH le tout puissant de m'avoir donné la foi et

de m'avoir permis d'en arriver là.

Mes vifs remerciements accompagnés de toute ma gratitude vont également à mon

encadreur Mme KOUAH SOFIA. Je lui suis particulièrement reconnaissante pour son soutient, sa

disponibilité, ses précieux conseils avisés, ses orientations et ses encouragements.

Mes remerciements vont également à mes parents, mes oncles et tantes de tous les sacrifices

qu'ils ont consentis pour me permettre de suivre mes études dans les meilleures conditions

possibles et n'avoir jamais cessez de m'encourager tout au long de mes années d'étude.

Je remercie les membres de jury : de m’avoir fait l’honneur d’accepter de participer à mon

jury.

Je remercie ceux qui m’ont aidé à l’aboutissement de ce travail ; mon formidable promotion

2017 du département d’Informatique de l’Université d’Oum Bouaghi Larbi Ben M’hidi.

iii

Dédicace

Je dédie ce mémoire à ma mère, à ma mère, à ma mère et à mon père,

A mon frère, mes sœurs,

A tous mes oncles et tantes, cousins et cousines,

A tous mes amis que je n'ai pas cités et à tous ceux qui me connaissent, les étudiants

de ma promotion Master 2 2017 Architectures Distribuées à l’université d’Oum Bouaghi,

A tous qui m’aide pour terminer ce travail particulièrement M.Laaboudi

A la fin, je veux dédier ce modeste travail à tous les enseignants et enseignantes qu’ils

m’aider pour arriver ici depuis le début de mes études.

iv

Résumé

L’internet des objets est un nouvel outil de connectivité et de mobilité, qui transforme les

affaires et la vie quotidienne à des objets connectés. Les objets courants deviennent des actifs

intelligents, s’intègrent de façon transparente a un réseau mondial et sont en mesure de produire et

d’échanger des données utiles sans intervention humaine. Il s’agit d’un réseau de réseaux qui

permet, via des systèmes d’identification électronique normalisés et sans fil, d’identifier et de

communiquer numériquement avec des objets physiques afin de pouvoir mesurer et échanger des

données entre les mondes physiques et virtuels. A travers un tel paradigme, aujourd’hui l’internet

des objets est anticipé avec de nouveaux domaines d’applications comprenant la surveillance, la

sécurité, la santé, les maisons et villes intelligentes ainsi que les systèmes de logistique et de

transportation intelligents.

Généralement un système d’IOT utilise les capteurs, ces capteurs peuvent subir Des

pannes et des défaillances dues à différentes causes, ce qui nécessite un mécanisme de diagnostic.

Le diagnostic est un thème de recherche fédérant différentes communautés

scientifiques, il a pour but d’établir un lien entre un symptôme observé, la défaillance qui est

survenue, et ses causes.

Afin établir une méthode de diagnostic d’un système d’IOT, et vu la distribution et

la diversité des processus et composants impliqués dans ce système, les systèmes multi agent

présentent une solution adéquate pour la mise en œuvre de cette application. Il s’agit de la

modélisation de ce système par d’entités autonomes, intelligentes et coopératives appelées agents.

Ces agents communiquent entre eux à travers des moyens sophistiqués de communication en

utilisant des langages et des protocoles agents.

L’objectif de ce mémoire est de mettre en œuvre une application basée agents pour le

diagnostic d’un système d’IOT. L’approche proposée distingue deux types d’agents : un agent

capteur (plusieurs instances, un par type de capteur) et un agent coordinateur (unique). Les agents

capteurs élaborent un diagnostic local, envoient leurs résultats à l’agent coordinateur. Ce dernier

élabore un diagnostic global. Cette approche est mise en œuvre en utilisant la plateforme Arduino,

coté objet connecté, et la plateforme Jade, coté modélisation du système multi agents.

Mots clé : IoT (Internet des objets), Système multi-Agents, Diagnostic, Plateforme

Arduino, Plateforme multi-Agents.

v

ملخص

شياءأ نتيجة الأشياء المتصلة، الحياة اليوميةو الأعمال وتحويل نقل،والت لتواصلل جديدة أداة هو الأشياء إنترنت

بارةوهي ع .بشري تدخل دون مفيدة بيانات وتبادل نتا لإ عالمية شبكة في ةبسهول تتكامل ذكية، تصبح اليومية الحياة من

لتمكين وتبادل المعلومات في العالم الحقيقي والافتراضي وذلك عن طريق انظمة تحديد الكترونية الشبكات من شبكة عن

ديدةج مجالات مع الأشياء إنترنت المتوقع ومن اليوم النموذ ، هذا خلال من المادية. الأشياء مع رقميالاسلكية للتواصل

.كيةالذ النقل وأنظمة اللوجستية والخدمات الذكية، والمدن والمنازل والصحة والأمن المراقبة ذلك في بما التطبيقات من

لالفشالأجهزة ان تتعرض العطل او هذهل ويمكن الاستشعار، أجهزة الأشياء إنترنت نظام يستخدم عموما

.التشخيصضرورة استخدام وسيلة إلى الحاجة جاءت هنا ومن. مختلفة بلأسبا نتيجة

نتا المرئية لاست أعراض ربط إلى تهدف والتي المختلفة، العلمية لمجتمعاتا بحث موضوع هو التشخيص

فشل. حدث نإ العطل واسبابه

هذا في الداخلة والمكونات العمليات عوتنو عللتوز ونظرا الأشياء، إنترنت النظام لتشخيص طريقة لوضع

،مستقلة النظام بوحدات هذا الغرض. وذلك عن طريق نمذجة هذا لتنفيذ المناسب الحلالعملاء هي متعددة نظمةالا ،النظام

اتلغ باستخدام للاتصال متطورة وسائل خلالهؤلاء العملاء يتواصلون فيما بينهم من ومتعاونة تدعى العملاء، ةذكي

.والعملاء بروتوكولاتو الديناميكية جةالبرم

:كلمات المفتاحية

، منصة متعددة العملاءArduinoمنصة التشخيص، أنظمة متعددة العملاء، انترنت الأشياء،

vi

Table des matières :

Introduction générale : ............................................................................................................................. 2

Chapitre 1:Internet des Objets(Internet Of Things) ....................................................................... 4

1.Introduction ............................................................................................................................................. 4

2.Internet des Objets (IoT : Internet Of Things) ............................................................................. 4

2.1.L’objet connecté ....................................................................................................................... 4

2.2.Définition de l’IoT ................................................................................................................... 5

3.Les composants impliqués dans l'Internet des Objets ............................................................... 5

4.Les caractéristiques d’un objet connecté ........................................................................................ 5

5.Exemples d’objets connectés .............................................................................................................. 6

6.Etude détaillée des composants d’un objet connecté : ............................................................... 7

6.1.Microcontrôleur ........................................................................................................................ 7

6.2.Module de connectivité ......................................................................................................... 11

6.3.Les capteurs ............................................................................................................................. 11

6.4.Les câbles : ............................................................................................................................... 15

6.5.Bradford (carte d’essai) : ........................................................................................................ 15

6.6.Les LEDs [21] ......................................................................................................................... 16

6.7.Résistance [16] ......................................................................................................................... 16

7.Développement des objets connectés ............................................................................................ 16

7.1.Domaines d’application d’IoT ............................................................................................... 17

7.2.Les limites et les défis d’IoT : ................................................................................................ 17

8.Modélisation des systèmes d’internet des objets par le paradigme des agents. ................ 18

vii

8.1.La technologie d'agent, pourquoi est-elle nécessaire pour l’IoT ? ................................ 18

8.2.Agent Orienté IoT ............................................................................................................... 18

9.Conclusion .............................................................................................................................................. 19

Chapitre 2 : Etude des approches de diagnostic des systemes .................................................. 21

1.Introduction ........................................................................................................................................... 21

2.Terminologie : ....................................................................................................................................... 21

3.Définition de diagnostic ..................................................................................................................... 22

4.Principe de fonctionnement de diagnostic ................................................................................... 23

4.1.La Détection ............................................................................................................................ 23

4.2.L’Analyse ................................................................................................................................. 23

5.Les méthodes de diagnostic .............................................................................................................. 24

5.1.Méthode de diagnostic a base modèle ................................................................................. 25

5.2.Le diagnostic à base d’arbre de décision ............................................................................. 27

5.3.Les systèmes experts .............................................................................................................. 28

6.Diagnostic centralisé, décentralisé et hybride ............................................................................. 30

7.Comparaison entre le diagnostic centralisé, décentralisé et hybride .................................... 30

8.Conclusion .............................................................................................................................................. 32

Chapitre 3 : Etude des systèmes multi-agents ................................................................................ 35

1.Introduction ........................................................................................................................................... 35

2.Les Agents …………………………………………………………………………………35

2.1.Les propriétés d’un agent ...................................................................................................... 36

2.2.Typologie des agents .............................................................................................................. 36

2.3.Architecture des Agents ........................................................................................................ 37

2.4.Agent vs. Objet ....................................................................................................................... 40

viii

3.Système multi-Agent ........................................................................................................................... 41

3.1.L’environnement ............................................................................................................... 41

3.2.Types de systèmes multi agents ...................................................................................... 42

4.Les interactions dans un SMA .......................................................................................................... 42

4.1.Les protocoles de coordination ....................................................................................... 44

4.2.Communication entre les agents ....................................................................................... 44

5.Domaines d’application des Systèmes Multi-Agents ................................................................ 48

6.Approches de développement des systèmes multi-Agent : ...................................................... 48

7.Conclusion .............................................................................................................................................. 49

Chapitre 4 :conception et réalisation d’un Objet connecté ......................................................... 54

1.Introduction ........................................................................................................................................... 54

2.Analyse des besoins ............................................................................................................................. 54

2.1.Description de l’objet à réaliser ...................................................................................... 54

2.2.Les propriétés de la pièce à surveiller ............................................................................ 54

2.3.L’ensemble des capteurs à utiliser : ................................................................................ 55

2.4.Etude générale des capteurs choisis ............................................................................... 55

2.5.Impact des grandeurs physiques choisis sur la vie humaine ....................................... 57

2.6.Caractéristique des capteurs ............................................................................................ 58

2.7.Désignation des composants électroniques de l’objet connecté ................................ 58

2.8.Motivation du choix de la carte Arduino UNO : ......................................................... 61

2.9.Description détaillée de la carte ARDUINO UNO : ................................................. 61

2.10.Diagramme de cas d’utilisation .................................................................................... 65

2.11.Diagramme de séquences : ........................................................................................... 65

3.Conception de l’application mobile ................................................................................................ 67

ix

3.1.Architecture du système à réaliser ................................................................................. 67

4.Réalisation ............................................................................................................................................. 73

4.1.Branchement des capteurs : ................................................................................................ 73

4.2.L’objet connecté ................................................................................................................... 74

4.3.Langages et outils utilisés : .................................................................................................. 75

4.4.Description de l’application ................................................................................................ 76

5.Quelques interfaces ............................................................................................................................. 78

6.Conclusion .............................................................................................................................................. 81

Chapitre 5 :Conception et Réalisation d’une Application Multi-Agents pour le Diagnostic

d’un système d’IoT ................................................................................................................................. 81

1.Introduction ........................................................................................................................................... 81

2.Objectif de l’application ..................................................................................................................... 81

3.Description générale de la solution à proposer ........................................................................... 82

4.Analyse des besoins ............................................................................................................................. 82

5.Conception de l’application serveur ............................................................................................... 88

6.Réalisation de l’application serveur ................................................................................................ 92

7.Intégration des applications mobile et Serveur ........................................................................... 94

8.Description des interfaces et résultats de l’application multi agents pour le diagnostic

d’un système d’IoT. ................................................................................................................................ 96

9.Conclusion ............................................................................................................................................ 100

Conclusion Général ............................................................................................................................... 102

Les références : ....................................................................................................................................... 103

x

Liste des figures :

Figure 1: Un microcontrôleur. ........................................................................................................................................ 8

Figure 2: les cartes d'essai ............................................................................................................................................... 15

Figure 3: les LEDs ........................................................................................................................................................... 16

Figure 4: résistance .......................................................................................................................................................... 16

Figure 5: Relation de causalité entre défaillance, panne et défaut ........................................................................... 22

Figure 6: procédure de diagnostic. [29]........................................................................................................................ 24

Figure 7: Classification des méthodes de diagnostic [50] ......................................................................................... 25

Figure8: Génération des résidus [45] ........................................................................................................................... 26

Figure 9: Principe de diagnostic a base modèle [33].................................................................................................. 27

Figure 10: Architecture d’agent purement réactif ...................................................................................................... 38

Figure 11: Architecture d’gent avec état ...................................................................................................................... 38

Figure 12: Architecture en couches .............................................................................................................................. 40

Figure 13: Communication entre 2 agents ................................................................................................................. 45

Figure 14: Vue générale du système d’IoT à développer.......................................................................................... 51

Figure 15: carte Arduino UNO [84] ............................................................................................................................. 59

Figure 16: Câble USB et des câbles de pointage [85] ................................................................................................ 60

Figure 17: description détaillé de la carte ARDUINO UNO[79] ........................................................................... 62

Figure 18: L’interface de l’Arduino. ............................................................................................................................. 64

Figure 19: diagramme de cas d’utilisation ................................................................................................................... 65

Figure 20: diagramme de séquence capteur température ......................................................................................... 66

Figure 21: Diagramme de séquence capteur CO2 ..................................................................................................... 66

Figure 22: Diagramme de séquence du système d’IOT ............................................................................................ 67

Figure 23: Architecture matérielle du système ........................................................................................................... 67

Figure 24: capteur de température LM35 .................................................................................................................... 68

xi

Figure 25: capteur de Monoxyde de carbone CO2 ................................................................................................... 68

Figure 26: détecteur de distance HC-SR04 ................................................................................................................. 69

Figure 27: le module Bluetooth HC-06 ....................................................................................................................... 69

Figure 28: Flow de données de l’application mobile. ................................................................................................ 70

Figure 29: Architecture logicielle du système d’IoT .................................................................................................. 71

Figure 30: diagramme d'activité globale ...................................................................................................................... 72

Figure 31: diagramme d’activité envoyer les données au serveur ........................................................................... 72

Figure 32: diagramme de class de l’application IoT .................................................................................................. 73

Figure 33: Branchement du capteur de température. ................................................................................................ 73

Figure 34: Branchement du capteur de CO2 .............................................................................................................. 74

Figure 35: Branchement du capteur de distance. ....................................................................................................... 74

Figure 36: notre l’objet connecté. ................................................................................................................................. 75

Figure 37:l’interface principale d’Arduino UNO. ...................................................................................................... 75

Figure 38: Environnement de programmation Android .......................................................................................... 76

Figure 39:l'interface principale de middleware ........................................................................................................... 79

Figure 40: interface principale de l'application mobile ............................................................................................. 79

Figure 41: le code de télévesement Arduino ............................................................................................................... 79

Figure 42:l’affichage sur la console de l'arduino ........................................................................................................ 80

Figure 43: affichage des données reçus par Bluetooth sur le smartphone ............................................................ 80

Figure 44: les données reçus sur le pc .......................................................................................................................... 81

Figure 45: Schéma global de l’application multi-agents. ........................................................................................... 82

Figure 46: Diagramme de cas d’utilisation du système. ............................................................................................ 83

Figure 47: Fonctionnement de l’agent capteur (exemple Agent CO2). ................................................................. 84

Figure 48: Fonctionnement de l’agent coordinateur ................................................................................................. 84

Figure 49: Fonctionnement de l’agent d’interface. .................................................................................................... 85

Figure 50: Diagramme AUML de l’Agent CO2. ........................................................................................................ 85

Figure 51: Diagramme AUML de l’agent coordinateur. ........................................................................................... 86

xii

Figure 52: Diagramme AUML de l’agent d’interface ................................................................................................ 86

Figure 53: Diagramme d’AUML du l’application serveur. ....................................................................................... 88

Figure 54: Architecture interne de l’agent capteur..................................................................................................... 89

Figure 55: Base de règles de l’agent température. ...................................................................................................... 89

Figure 56: Architecture interne de l’agent coordinateur ........................................................................................... 90

Figure 57: Diagramme de classes de l’application serveur. ...................................................................................... 91

Figure 58: Diagramme d’activité de l’application serveur. ....................................................................................... 92

Figure 59: Interface principale de la plateforme jade ................................................................................................ 93

Figure 60: Interface d’exécution de SwiProlog .......................................................................................................... 93

Figure 61: Interface principale de l'application serveur ............................................................................................ 94

Figure 62: Diagramme de package de l’intégration des applications mobile et serveur. ..................................... 95

Figure 63: Diagramme de déploiement de l’application ........................................................................................... 96

Figure 64: Lancement de l'objet connecté .................................................................................................................. 96

Figure 65: Lancement de l'application SMA ............................................................................................................... 97

Figure 66: Class java de l'agent température ............................................................................................................... 97

Figure 67: Snifer (les interactions entre les agents de système) ............................................................................... 98

Figure 68: Interface d'affichage des données reçu. .................................................................................................... 98

Figure 69: interface pour remplir les propriétés de la salle ...................................................................................... 99

Figure 70: interface d'affichage des résultats .............................................................................................................. 99

Figure 71: le cas d'une anomalie ................................................................................................................................. 100

xiii

Liste des tableaux

Tableau 1: les microcontrôleurs .................................................................................................................................... 11

Tableau 2: capteurs de température ............................................................................................................................. 12

Tableau 3: capteur de CO2 ............................................................................................................................................ 13

Tableau 4: capteurs de mouvement .............................................................................................................................. 14

Tableau 5 : capteurs de mouvement ............................................................................................................................ 14

Tableau 6 : Comparaison entre les trois approches de diagnostic [41] .................................................................. 31

Tableau 7: les points fort et faible pour chaque approche de diagnostic .............................................................. 32

Tableau 8: classification des situations d’interaction [55]. ........................................................................................ 43

Tableau 9 : les propriétés des capteurs ........................................................................................................................ 57

Introduction générale


2

Introduction Générale

1. Contexte de travail

L’internet est devenue en quelques années le vecteur principal de diffusion de

l’information, il s’est imposé dans de nombreux domaines comme une infrastructure essentielle

pour les individus, les entreprises et les institutions toute fois, ses capacité d’extension, au-delà des

seuls ordinateurs et terminaux mobiles, sont encore considérables car il devrait permettre

l’interaction d’un nombre croissant d’objets entre eux ou avec nous-mêmes. L’internet se

transforme progressivement en un réseau étendu, appelé « internet des objets » [3].

L'Internet des Objets que l'on appelle aussi Internet of Things (IoT) est un nouveau

paradigme qui gagne du terrain de jour en jour dans le monde des télécommunications et des

réseaux informatiques. L'apparition de ce concept est due à la variété des équipements et des objets

qu'on utilise dans notre vie quotidienne (ordinateurs, capteurs, actionneurs, smartphones, véhicules

connectés, smart homes, .etc). L'IoT représente une évolution des systèmes M2M1. Il est considéré

comme étant l'extension d'Internet à des choses et à des lieux du monde physique et prétend

modéliser des échanges de données provenant de dispositifs présents dans le monde réel vers le

réseau Internet. Chaque objet doit être autonome, capable d'interagir et coopérer avec d'autres

objets afin d'atteindre des objectifs communs.

2. Problématique et objectifs :

Dans un système d’IoT les capteurs utilisés peuvent subir des pannes et des

défaillances dues à des différentes causes. Ces causes peuvent être internes ou externes selon leur

origine.

En effet, le diagnostic a pour le but d’établir un lien entre les symptômes observé, les

défaillances qui peuvent survenue et ses causes.

Afin de concrétise le mécanisme de diagnostic d’un système d’IoT, et vue la

distribution et la diversité des processus et composant impliquer de ce système, donc le système

multi-agent présente une solution adéquate pour la mise en œuvre de cette application.

Cette application vise à mettre en œuvre une application basée agents pour le diagnostic

d’un system d’IoT.

3. Les travaux réalisés dans la littérature :

1 Machine to Machine


3

L'Internet des objets : Projets « WINGS » et « Proxi Produit »

Lancement du project WINGS « Widening Interoperability for Networking Global

Supply Chains ». Ce projet, coordonné par GS1 et soutenu par l'Agence Nationale de

la Recherche (ANR) dans le cadre de l'appel à projets Verso sur l'Internet du futur, vise

à améliorer l'interopérabilité des services ONS fédérés et à fiabiliser leurs interactions

avec les services de découverte ("multi Discovery Services") [97].

Les travaux sur l'ONS2 fédéré servent de bases théoriques au projet d’expérimentation

Proxi Produit, réalisé en partenariat avec GS1 et la société Adenyo. Soutenu par le

Secrétariat d'État chargé de la prospective et du développement de l'économie

numérique, [97]

Le Gouvernement a demandé aux équipes projet des solutions numériques de la Nouvelle

France Industrielle d’établir une feuille de route commune sur l’Internet des objets. cette

feuille a été élaborée à partir d’une consultation publique organisée par la Direction générale

des entreprises du 4 au 28 avril 2016 qui a permis de recueillir plus de 100 réponses de

fournisseurs et utilisateurs de solutions IoT, ainsi que d’accompagnants et d’acteurs de

l’écosystème [96].

4. Description de solution proposée :

Dans le cadre de notre projet de fin d’études, il nous a été confié le proposé d’une

architecture basée agents pour le diagnostic d’un système d’internet des objets ; permettant

de proposer une solution logicielle intégrée pour la détection et la localisation des anomalies dans

un système d’IoT.

5. Structuration de mémoire :

Ce mémoire est organisé comme suit :

Partie 1 : état de l’art

Chapitre 1 : L’internet des Objets (définition, les objets connectés, domaine

d’application, …….)

Chapitre 2 : Etude des approches de diagnostic des systèmes (définition, les

méthodes de diagnostic, …….)

Chapitre 3 : Etude des Agent et système multi-Agent (définition, les Architecture

d’agent, les systèmes multi-agent……)

Partie 2 : contributions

Chapitre 4 : conception et réalisation d’un objet connecté (les composants de

l’objet connecté, la réalisation concrète de l’objet, ………)

Chapitre 5 : conception et réalisation d’une application basé agent pour le

diagnostic d’un système IoT (Architecture de l’application multi-

Agent,…………).

2 ONS : Object Naming Service est un standard directement dérivé du DNS (« Domain Name

System »). Il permet typiquement d’associer des informations (page web par exemple) ou des services

(mobiles) à ces objets identifiés par leur nom


4

Partie 1 : état de l’art

Chapitre 1 : internet des

objets (internet of things)

Chapitre 1 : Internet des Objets (Internet Of Things)

4

Chapitre 1

Internet des Objets

(Internet Of Things)

1. Introduction

nternet est devenu en quelques années le vecteur principal de diffusion de l’information.

Il s’est imposé dans de nombreux domaines comme une infrastructure essentielle pour les

individus, les entreprises et les institutions. Toutefois, ses capacités d’extension, au-delà

des seuls ordinateurs et terminaux mobiles, sont encore considérables car il devrait

permettre l’interaction d’un nombre croissant d’objets entre eux ou avec nous-mêmes [15].

L’Internet se transforme progressivement en un réseau étendu, appelé « Internet des objets

» (en anglais : Internet of Things, IoT), reliant plusieurs milliards d’êtres humains mais aussi des

dizaines de milliards d’objets. Cette évolution sera accompagnée d’une évolution de l’écosystème

technologique environnant dans toute sa complexité. En effet, l’Internet a évolué ces dernières

décennies d’un réseau de calculateurs à un réseau d’ordinateurs personnels, puis vers un réseau qui

intègre tout dispositif communiquant : les tags RFID3, les réseaux de capteurs et actionneurs, les

réseaux véhiculaires, etc… [1]

Dans l'Union européenne, la valeur marchande de l'IoT devrait dépasser un billion d'euros

en 2020, alors qu'il est prévu que près de 26 milliards d'appareils IoT auront un impact quotidien

sur notre vie [2]. Les gens, les objets et les lieux participeront à Internet, étant globalement

identifiés, interconnectés, découverts et interrogés. Tout interagira automatiquement mais sans

interruption, même sans orchestration humaine stable, fournissant ainsi de nouveaux services

cyber-physiques aux humains et aux machines [1].

2. Internet des Objets (IoT : Internet Of Things)

2.1. L’objet connecté

L’objet est au centre de l’attention dans la technologie IoT. On peut dire que l’objet est tout

appareil et dispositif capable de se connecter au réseau internet [7]. Un tel appareil est suffisamment

équipé pour cette fin et permettra d’une manière ou d’une autre de communiquer à un serveur pour

recevoir et transmettre des informations. On parle également d’objets intelligents pour désigner ces

appareils connectés.

3 Radio Frequency Identification

I


5

2.2. Définition de l’IoT

Le terme «Internet des objets» (IoT) a été utilisé pour la première fois en 1999 par le

pionnier de la technologie britannique « Kevin Ashton » pour décrire un système dans lequel les

objets du monde physique pouvaient être connectés à l'Internet par des capteurs. Ashton a inventé

le terme pour illustrer la puissance des étiquettes d'identification par la radiofréquence (RFID)

utilisées dans les chaînes d'approvisionnement d'entreprise à l'Internet pour compter et suivre les

marchandises sans intervention humaine [4].

Le CERP-IoT4 définit l’Internet des objets comme : « une infrastructure dynamique d’un

réseau global. Ce réseau global a des capacités d’auto-configuration basée sur des standards et des

protocoles de communication interopérables. Dans ce réseau, les objets physiques et virtuels ont

des identités, des attributs physiques, des personnalités virtuelles et des interfaces intelligentes, et

ils sont intégrés au réseau d’une façon transparente » [1].

3. Les composants impliqués dans l'Internet des Objets

Généralement, le concept d’Internet des Objets exige la coordination des dispositifs suivants [13]:

une étiquette physique identifie chaque objet / une étiquette virtuelle identifie chaque lieu ;

un dispositif mobile (téléphone cellulaire, organiseur, ordinateur portable…) doté d’un logiciel

additionnel, lit les étiquettes physiques ou localise les étiquettes virtuelles ;

un réseau sans fil relie le dispositif portable à un serveur contenant l'information relative à

l'objet étiqueté ;

les informations sur les objets sont gérées dans des pages existantes sur le web ;

un dispositif d’affichage (écran d'un téléphone mobile, par exemple) permet de consulter les

informations relatives à l'objet ou à un ensemble d’objets.

4. Les caractéristiques d’un objet connecté

Les objets connectés se définissent en termes d’identité, d’interactivité, d’objet ombre «Shadowing»,

de sensibilité et d’autonomie [13].

Identité : pour que les objets soient gérables, ils doivent être identifiables comme une entité

unique.

Interactivité : les progrès technologiques ont permis de connecter une grande variété d’objets

et de dispositifs. Un objet n’a pas besoin d’être connecté à un réseau à tout moment. Pour des

objets dits passifs tels que des livres ou des DVD, des étiquettes RFID doivent seulement être

en mesure de signaler leur présence, de temps en temps, comme au moment de quitter un

magasin.

Object Ombre (Shadowing) : La notion de shadowing désigne le fait qu’un programme logiciel

puisse tout connaître d’un objet physique et agir en son nom. Grâce à cela, même un objet

physique « muet » peut avoir une représentation virtuelle relativement intelligente. Ceci est

parfois désigné sous le nom de cyber-objet ou d’agent virtuel.

4 Cluster of European Research Projects on the Internet of Things


6

Sensibilité : Un objet peut transmettre des informations non seulement sur son propre état,

mais aussi sur les caractéristiques de son environnement. Il peut ainsi avoir des capteurs

signalant les niveaux de température, d’humidité, de vibrations, d’emplacement ou de bruit [13].

Autonomie : Les objets doivent pouvoir être traités et surveillés individuellement,

généralement depuis un point éloigné, et doivent fonctionner indépendamment d’une

télécommande. Le concept d’« indépendance » est ainsi central : chaque objet devient

responsable de lui-même, même s’il peut être interrogé par un tiers pour connaître son état.

Les objets peuvent ainsi présenter divers degrés d’autonomie .

Ces caractéristiques permettent non seulement aux éléments physiques d’acquérir de

nouvelles capacités, mais aussi de créer de nouveaux objets. L’Internet des objets ouvre donc un

environnement ultra-connecté, des capacités et des services permettant une interaction avec et

entre les objets physiques et leur représentation virtuelle [21].

5. Exemples d’objets connectés

L’Apple Watch

Smart Toothbrush

Les lunettes Google

L’Apple Watch est une montre connectée qui

permet à l’utilisateur de réaliser des tâches

directement depuis son poignet, l’appareil devant

être relié à un iPhone (à partir d’iPhone 5)[8]

La brosse de faisceau (Smart Toothbrush) est

une brosse à dent connectée, engage les

utilisateurs avec leur routine quotidienne de

l'hygiène [10].


7

Le serre-tête qui lit vos pensées

Le canapé connecté

6. Etude détaillée des composants d’un objet connecté :

Dans cette section, nous présentons les composants de base pour la réalisation d’un objet connecté.

6.1. Microcontrôleur

Un microcontrôleur est une petite unité de calcul accompagné de mémoire, de ports

d’entrée/sortie et de périphériques permettant d’interagir avec son environnement. Parmi les

périphériques, on recense généralement des Timers, des convertisseurs analogique-numérique, des

liaisons Séries, etc. On peut comparer un micro contrôleurs à un ordinateur classique, mais avec

un système d’exploitation et une puissance de calcul considérablement plus faible [1].

Les lunettes Google, à réalité augmentée,

permettent de superposer à une image du

monde réel des éléments virtuels comme un

plan, une photo ou une affiche récupérés sur

internet [9].

C'est un étrange bandeau. Il se place comme

un serre-tête. Et puis, d'un coup, sur un écran,

un texte s'affiche. Les mots apparaissent en

gras, en italique. Ils sont surlignés, effacés,

réécrits [9].

Un canapé qui commande la télévision ? C’est

l’étonnante invention développée par la

compagnie Joshfire. Le sofa détecte une puce

RFID installée sur un téléphone ou un

portefeuille et identifie l’utilisateur pour lui

proposer un affichage personnalisé à l’écran

[9].


8

Figure 1: Un microcontrôleur.

Les microcontrôleurs sont inévitables dans les domaines de l’informatique embarquée, de

l’automatique et de l’informatique industrielle. Ils permettent de réduire le nombre de composant

et de simplifier la création de cartes électroniques logiques [1].

Un microcontrôleur est constitué par un ensemble d’éléments qui ont chacun une fonction bien

déterminée. Il est en fait constitue des mêmes éléments que sur la carte mère d’un ordinateur [1]:

La mémoire [1]

Il en possède 5 types de mémoires :

La mémoire Flash : C'est celle qui contiendra le programme à exécuter. Cette mémoire

est effaçable et réinscriptible.

RAM : c'est la mémoire dite "vive", elle va contenir les variables de votre programme. Elle

est dite "volatile" car elle s'efface si on coupe l'alimentation du microcontrôleur.

EEPROM : C'est le disque dur du microcontrôleur. Vous pourrez y enregistrer des infos

qui ont besoin de survivre dans le temps, même si la carte doit être arrêtée. Cette mémoire

ne s'efface pas lorsque l'on éteint le microcontrôleur ou lorsqu'on le reprogramme.

Les registres : c'est un type de mémoire utilise par le processeur.

La mémoire cache : c'est une mémoire qui fait la liaison entre les registres et la RAM.

Le processeur [1]

C'est le composant principal du microcontrôleur. C'est lui qui va exécuter le programme qu'on lui

donnera à traiter. On le nomme souvent le CPU.

Pour que le microcontrôleur fonctionne, il lui faut une alimentation. Cette alimentation se fait en

générale par du +5V. D'autres ont besoin d'une tension plus faible, du +3,3V.

En plus d'une alimentation, il a besoin d'un signal d'horloge. C'est en fait une succession de 0 et de

1 ou plutôt une succession de tension 0V et 5V. Elle permet en outre de cadencer le

fonctionnement du microcontrôleur a un rythme régulier. Grace à elle, il peut introduire la notion

de temps en programmation.

6.1.1. Type des cartes à microcontrôleurs : Il existe plusieurs modèles de cartes à

microcontrôleurs, nous citons à titre d’exemple les modèles suivants :


9

La carte Photo

Arduino UNO [2]

Microcontrôleur : ATmega328.

Tension de fonctionnement nominale : 5V.

Tension d'alimentation (recommandé) :7-12V.

Tension d'alimentation (limites) : 6-20V.

Entrées/sorties digitales : 14 (dont 6 pouvant être utilisées comme sorties PWM).

Entrées Analogiques : 6.

DC Current per I/O Pin: 40 mA.

DC Current for 3.3V Pin: 50 mA.

Mémoire Flash : 32 KB (ATmega328) dont 0.5 KB utilisé par le bootloader.

SRAM: 2 KB (ATmega328).

EEPROM: 1 KB (ATmega328).

Fréquence d'horloge : 16 MHz.

Arduino officiel fabriqué en Italie.

Arduino Yun [2]

Microcontrôleur : ATMEGA32U4.

Tension de fonctionnement nominale : 5V.

Tension d'entrée : 5V via microUSB ou PoE 802.3af.

Entrées/sorties digitales : 14 (dont 7 pouvant être utilisées comme sorties PWM).

Voies d'entrée analogique : 6 (plus 6 multiplexé sur 6 broches numériques).

Courant par I / O Pin : 40 mA.

Courant pour Pin 3.3V : 50 mA.

Mémoire Flash : 32 Ko (ATMEGA32U4) dont 4 Ko utilisé par bootloader.

SRAM : 2,5 KB (ATMEGA32U4).

EEPROM : 1 Ko (ATMEGA32U4).

Vitesse d'horloge : 16 MHz.

Processeur : MIPS 24K fonctionnant jusqu'à 400 MHz.

Mémoire : DDR2 64Mo de RAM et 16 Mo Flash SPI.

AP ou routeur : Complete IEEE 802.11bgn 1x1

Hôte / Périphérique : USB 2.0.

MicroSD : PoE 802.3af support de carte compatible.


10

Raspberry pi - model a+ 512 mo[2]

CPU : Broadcom BCM2835 ARM1176JZ-F cadencé à 700 MHz.

Mémoire : 512Mo de SDRAM.

Dimension : 66 x 56 x 14mm.

Alimentation : Micro-USB.

USB : 4 ports disponibles sur connecteurs extérieur.

Vidéo en HDMI et RCA Audio sur Jack 3,5mm ou HDMI.

Stockage : micro SD card.

Port extension : GPIO 40 pin.

Banana PI [3]

La Banana Pi est possède un dual-core Allwinner A20 ARM Cortex – A7 à 1 GHz. Le Banana Pi possède jusqu’à 1Go de RAM. La Banana Pi dispose d’un connecteur pour carte SD, de prises HDMI et vidéo composite, d’une prise audio 3,5 mm et d’un microphone intégré, un port Gigabit Ethernet, 2 ports USB 2.0, un port micro-USB pour l’alimentation, un récepteur infrarouge, un connecteur GPIO à 26 broches, compatible avec celui du Raspberry Pi, et même un connecteur pour la caméraPi.

Seeeduino v4.2 (atmega 328p)[2]

Microcontrôleur : Atmel ATmega328 (AVR 8-bit) en package TQFP-32.

Boot-loader: Arduino Duemilanove w/Atmega328.

Tension de fonctionnement : 5V ou 3.3V (sélectionnable par switch).

Courant max sur la sortie 5V ou 3V3 : en 5V - 500mA, en 3V3 - 800mA (nécessite une alimentation externe via Jack DC jack ou Vin).

Courant max sur les pins numériques : 40mA Tension d'entrée sur le port miniUSB : 5V, Maximum à 5.5V.

Tension d'entrée sur le DC Jack & Vin : de 7V to 12V (le plus bas est préconisé).

Maximum à 20V. Si l'entrée est plus basse que 7V et que le switch est sur 5V, alors le

VCC de l'AVR sera autour de 2V.

Entrées/sorties digitales : 14 (dont 6 pouvant être utilisées comme sorties PWN).

Entrées Analogiques : 8 (dont 2 sont utilisée pour la communication i2C - PC4 et PC5).

Mémoire Flash : 32 KB.

SRAM : 2 KB.


11

EEPROM : 1 KB.

Vitesse d'horloge : 16 MHz.

Tableau 1: les microcontrôleurs

6.2. Module de connectivité

Selon la technique utilisée pour véhiculer les données, on distingue cinq types de réseaux sur PC

comme sur Macintosh [14] :

Wi-Fi (WLAN)

Bluetooth (WLAN)

Infrarouge (WLAN)

Ethernet (LAN)

CPL (LAN)

Deux modes de connectivité sont distingués : filaire et sans fils [15].

6.2.1. Connectivité filaire

Le réseau filaire est un réseau, qui comme son nom l'indique, que l'on utilise grâce à une connexion

avec fils. Ce réseau utilise des câbles Ethernet pour relier des ordinateurs et des périphériques grâce

à un routeur ou à un commutateur [16].

Exemples : L’Ethernet, CPL (courant porteur en ligne) ….

6.2.2. Connectivité sans fils : ce réseau est sans liaison filaire. C’est un réseau dans lequel au

moins deux terminaux peuvent communiquer sans liaison filaire.

Examples: Wi-Fi (Wireless Fidelity), Bluetooth, Infrarouge…

6.3. Les capteurs

Les capteurs sont très largement utilisés de façon courante et sont essentiels pour la mise en œuvre

d’applications. A titre d’exemple, ils sont les yeux, les oreilles, les doigts et dans certains cas peu

courants l’odorat et le goût d’un système robotique [17].

Les capteurs traduisent la variation de la grandeur physique ou le changement de l’état physique

en un signal compatible avec l’unité de traitement de la partie commande [10].

Suivant la nature du signal exploitable, les capteurs se classent en trois catégories [17]:

Capteurs analogiques : Le signal délivré est la traduction exacte de la loi de variation de la

grandeur physique mesurée.

Capteurs logiques : Le signal ne présente que deux niveaux, ou deux états, qui s’affichent par

rapport au franchissement de deux valeurs; ces capteurs du type tout ou rien sont également

désignés par détecteurs.

Capteurs numériques : Le signal est codé au sein du même capteur par une électronique

associée ; ces capteurs sont également désignés par codeurs et compteurs.


12

6.3.1. Exemples de capteurs

Il existe une variété de modèles pour chaque type de capteur, parfois on les trouve combinés dans

un seul. Nous présentons les exemples suivants :

Capteurs de température : plusieurs modèles sont distingués [20] :

Image Description technique Capteur

Ce capteur de température permet d'acquérir une température ambiante. Une fois alimenté, il va délivrer une tension analogique proportionnelle à la température. Tension d'alimentation : 2,7V à 5,5V Etendu de mesure : -40°C à 125°C Précision : ± 2°C Echelle : 10mV/°C Calibration : 750mV à 25°C Ce produit est facilement utilisable à travers un pin analogique d'une carte Arduino.

Capteur de température

tmp36

Ce circuit comprend un capteur DHT11 qui fournit une information numérique proportionnelle à la température et l'humidité mesurée par le capteur. La technologie utilisé par le capteur DHT11 garantie une grande fiabilité, une excellente stabilité à long terme et un temps de réponse très rapide. Caractéristiques : Alimentation : 5V. Consommation : 0.5 mA en nominal / 2.5 mA

maximum. Etendue de mesure température : 0°C à 50°C ±

2°C. Etendue de mesure humidité : 20-90%RH

±5%RH.

Dht11 - capteur de température et

humidité digital

Le module Grove capteur de température utilise une thermistance qui va fournir une température ambiante entre -40°C et +125°C avec une précision de 1.5°C. Un câble au standard Grove est fourni avec ce module. Caractéristiques :

Compatible de l'interface Grove

Plage de Température : -40 à 125°C

Précision : 1,5°C.

Capteur de température –

Grove

Tableau 2: capteurs de température

Capteur de co2 : plusieurs modèles sont distingués [20] :


13

Nom Caractéristiques Image

Capteur de qualité d'air - Grove - v1.3

Le module Grove Capteur de qualité de l'air permet d'obtenir une information sur la qualité de l'air en détectant les gaz principaux : Monoxyde de carbone, alcool, acétone, diluant, formaldéhyde et autres gaz peu toxiques. Un câble au standard Grove est fourni avec ce module. Caractéristiques :


Faible consommation d'énergie, Haute sensibilité et longue durée de vie.

Alimentation en 5V ou 3,3V

Capteur ： Winsen MP503

Dimension : 40x20mm

Capteur EE893 Le procédé de calibration multipoint en CO2 et température permet une excellente précision de mesure de CO2 sur toute la gamme de température, ce qui est parfait dans les processus de contrôle et dans les applications en extérieur. La cellule de mesure utilise la technologie infrarouge E+E à double longueur d’onde NDIR qui compense les effets du vieillissement, est particulièrement résistant à la pollution et offre une grande stabilité à long terme [18].

Tableau 3: capteur de CO2

Capteur d’Humidité [20] :

Nom Caractéristique Image

Dht22- capteur de température et humidité digital

La DHT22 est un capteur à bas cout permettant d'acquérir une température et une humidité ambiante d'une manière numérique. Il utilise un capteur d'humidité capacitif et une thermistance pour mesurer la température et l'humidité de l'air et la transmet d'une manière numérique sur un bus série. Les données sont actualisées toutes les 2 secondes Caractéristiques :

Bas cout.

Alimentation : 3 to 5V.

Consommation : 2.5mA max pendant la conversion.

Etendue de mesure humidité : de 0% à 100% avec une précision à 2-5%.

Etendue de mesure température : de -40°C à 80°C avec une précision ±0.5°C


14

E échantillonnage à 0.5 Hz (tous les 2 seconds)

Dimension : 27mm x 59mm x 13.5mm (1.05" x 2.32" x 0.53") 4 pins, 0.1" spacing

Capteur de température et d'humidité si7021

Ce module capteur de température et d'humidité est basé sur le circuit Si7021, il dispose d'une précision de ±3% sur l'humidité sur une plage de 0% à 80% et d'un précision de ±0,4° sur une plage de -40°C à +85°C. Ce qui est excellent pour vos projets. Il utilise une liaison I2C qui est courante sur la plupart des projets. Caractéristiques :

Dimensions : 17.8mm x 15.3mm x 3.0mm / 0.7" x 0.6" x 0.1"

Poids : 1.0g / 0.0oz

Tableau 4: capteurs de mouvement

Capteur de mouvements [20] :

Nom Caractéristiques image

Capteur de mouvement PIR - grove

Le module Grove capteur de mouvement va permettre de détecter le moindre mouvement à proximité afin d'activer la sortie SIG à l'état haut. Caractéristiques :


Alimentation : 3V - 5V

Angle de détection : 120°

Distance de détection max : 6m

Temps de réponse : de 0.3s à 25s

Dimension : 20 mm x 40mm

Précision : 1,5°C

Détecteur de mouvement PIR avec réglages

Les détecteurs de mouvement PIR sont utilisés pour détecter les mouvements des humains et des animaux dans un rayon de 6 mètres (Ils peuvent détecter également les zombies, mais ce n'est pas garanti). Ce modèle dispose d'un réglage de seuil de détection avant déclenchement de 2 à 4 secondes ainsi que d'un réglage de sensibilité. Un câble avec connecteur de 30 cm est fourni afin de simplifier son câblage Caractéristiques :

Longueur : 24.03mm / 0.94in

Largeur : 32.34mm / 1.27in

Diamètre du trou de vis : 2mm

Hauteur (avec objectif) : 24.66mm / 0.97in

Tableau 5 : capteurs de mouvement


15

6.4. Les câbles :

Les câbles sont utiliser pour relier les différents composants, pour la construction de notre

objet on va utiliser des câbles de pointage pour brancher les déférents capteurs a la carte Arduino

au plus pour assurer l’alimentation des capteurs. Une câble USB est utilisé pour téléverser le code

Arduino ver le microcontrôleur, il est utilisé aussi pour l’alimentation de la carte, il suffit simplement

de la connecter à un ordinateur à l’aide de ce câble USB.

6.5. Bradford (carte d’essai) :

Les plaques d'essai sont des circuits imprimés comportant des bandes de cuivre déjà percées.

La méthode pour tester un montage électronique sans réaliser de circuit imprimé consiste à utiliser

une plaque d’essai. Grâce à ce petit outil, il n’y a pas besoin de souder, il suffit juste de placer les

composants sur la plaque de test [19].

Pour la plupart des projets, il est souvent nécessaire d’ajouter des fonctionnalités aux cartes

Arduino. Plutôt que d’ajouter soit même des composants extérieurs (sur une platine d’essai, circuit

imprimé, etc.), il est possible d’ajouter des shields. Un shield est une carte que l’on connecte

directement sur la carte Arduino qui a pour but d’ajouter des composants sur la carte. Ces shield

viennent généralement avec une librairie permettant de les contrôler. On retrouve par exemple,

des shields Ethernet, de contrôle de moteur, lecteur de carte SD, etc. [1]

Il existe plusieurs types de carte d’essai [20]:

Nom Description Image

Breadboard - 400 contacts

Une platine Labdec (appelé en anglais Breadbord, solderies Breadbord, protoboard ou plugboard) est un dispositif qui permet de réaliser le prototype d'un circuit électronique et de le tester. L'avantage de ce système est d'être totalement réutilisable, car il ne nécessite pas de soudure. Ce dernier point distingue les platines Labdec des stripboards (ou veroboards), des perfboards ou des circuits imprimés qui sont, eux, utilisés pour réaliser des prototypes permanents et que l'on sera donc moins à même de démonter.

Breadboard - 830 contacts

Cette platine d'essais (BreadBoard) 830 points est idéale pour réaliser vos prototypages électroniques sans soudure. 2 zones sont présentes : Une pour le prototypage : 10 x63 contacts repérés. Une pour les alimentations : 2 X 2 X 50 points arrangé en ligne. Ces breadboard disposent d'un adhésif pour une fixation facile sur l'arrière.

Figure 2: les cartes d'essai


16

6.6. Les LEDs [21]

Les LEDs sont de petites lampes spéciales (LED signifie Light Emitting Diode, ou diode

électroluminescente) qui sont disponibles dans une large sélection de tailles et de couleurs. La taille

la plus commune est de 5 mm de diamètre. Cependant, une diode de taille plus importante (10 mm,

par exemple) pourra également être utilisée, pour plus de plaisir. La majorité des LED sont de

couleur unique.

Figure 3: les LEDs

6.7. Résistance [16]

La résistance s’oppose au passage du courant, proportionnellement à sa “ résistance” exprimée

en Ohm. On utilise souvent une résistance de 560 Ω pour la sécurité de la led, elle est donnée par

la loi : R(résistance)=U(voltage) /I(l’ampérage).

Figure 4: résistance

7. Développement des objets connectés

Les objets connectés se développent très vite sans que tout le monde n’ait pris conscience

du mouvement. La concurrence accélère le phénomène. Mais concrètement combien existe-t-

il aujourd’hui d’objets connectés et quelle évolution est prévue ? Quels sont les chiffres ?[7]

L’Idate ( Institut de l’audiovisuel et des télécommunications en Europe ) estime qu’il y

aurait à l’heure actuelle 15 milliards d’objet connectés à internet contre 4 milliards seulement

en 2010 ce qui confirme la vitesse de ce phénomène. Et ces derniers ne comptent pas s’arrêter

là puisque d’après une étude menée par Gartner et l’Idate en 2020 on peut estimer que le

nombre d’objets connectés en circulation à travers le monde s’élèvera entre 50 et 80 milliards.

En clair chaque personne détiendra environ 6 objets connectés, 6 milliards. C’est le chiffre

impressionnant qu’évoque le cabinet Gartner pour les objets connectés qui seraient mis en

circulation à partir de 2018[7].

Les chiffres sont en véritable augmentation depuis plusieurs années grâce à l’arrivée

progressive des objets connectés dans nos foyers. De plus en plus polyvalents, ils ont su sortir d’un

public essentiellement geek pour toucher un public plus large comme le prouve l’étude publiée par

l’IAB en juillet 2016. Si tout le monde ne les connaît pas encore, 69% des français interrogés

connaissent les objets connectés et savent les utiliser. Pour 53% d’entre eux, ces équipements

représentent le futur, dans des domaines comme la sécurité, la santé et la domotique. 47% mettent


17

l’accent sur l’aspect pratique et utile alors que pour 29%, il s’agit d’un simple phénomène de monde

[7].

7.1. Domaines d’application d’IoT

La Santé intelligente (Smart Heath) [10]: l'IoT contribuera également à élargir l'accès et à

améliorer la qualité de l'éducation et de la santé. À mesure que la demande de soins de santé

doublera, les appareils intelligents connectés aideront à relever ce défi en soutenant une gamme

de services de santé en ligne qui améliorent l'accès et permettent le suivi des maladies

chroniques et des conditions liées à l'âge à la maison. Ce faisant, ils amélioreront la qualité des

soins et la qualité de vie des patients, tout en réduisant la pression exercée sur l'ensemble du

système de santé.

Les villes intelligentes (Smart Cities) [6] : dans les villes, le développement de réseaux

intelligents, d'analyse de données et de véhicules autonomes constituera une plate-forme

intelligente pour fournir des innovations en matière de gestion de l'énergie, de gestion du trafic

et de sécurité, en partageant les bénéfices de cette technologie dans toute la société.

Dans les transports [5] : la dernière avancée majeure fut l’adoption du GPS. Les petits

appareils IoT possédant une connectivité sont un excellent choix pour développer des produits

dans le domaine du transport. Selon le département américain des transports, plus de 32 000

personnes sont mortes dans des accidents de voiture aux États-Unis. Ça permis de mettre en

place une solution innovante utilisant l’IoT. Plus de 3000 capteurs ont été placés sur les routes

pour réduire le délai entre un accident et l’arrivée des secours.

Le bien-être et le confort [5] : La domotique ou la maison intelligente est un classique.

Imaginez un instant que votre thermostat soit capable de se mettre en marche tout seul en

fonction de l'emplacement de votre voiture vous permettant de vous réchauffer une fois rentré

à la maison. Aussi, imaginez que votre réfrigérateur vous informe lorsque vous aurez besoin

d'acheter du lait ou qu'il soit capable de créer une liste d'achats personnalisée en fonction de

vos articles les plus achetés. Ou encore vous dire quand votre nourriture est sur le point de

périmer !

7.2. Les limites et les défis d’IoT :

Donc, les principaux défis que rencontre l’IoT sont [11] :

La détection d'un environnement complexe : des façons novatrices de saisir et de diffuser

de l'information - du monde physique au nuage.

Connectivité : Une variété de normes de connectivité câblées et sans fil sont requises pour

permettre différents besoins d'application.

La puissance est critique : de nombreuses applications IoT doivent fonctionner pendant des

années sur des batteries et réduire la consommation globale d'énergie.

La sécurité est vitale : protéger la confidentialité des utilisateurs et l'IP des fabricants;

Détection et blocage d'activités malveillantes.

IoT est complexe : le développement d'applications IoT doit être facile pour tous les

développeurs, pas seulement pour les experts.

Cloud est important : les applications IoT requièrent des solutions de bout en bout, y compris

des services en nuage.


18

Donc, plusieurs obstacles pourraient ralentir la progression de l’IoT, notamment le déploiement

du protocole IPv6, l’alimentation des capteurs et la définition de normes [13].

8. Modélisation des systèmes d’internet des objets par le paradigme des agents.

Au cours des dernières années, les recherches et les expériences industrielles dans un large

éventail de domaines d'application (logistique, économie, sciences sociales, automatisation) ont déjà

démontré les avantages découlant de l'utilisation de l’informatique basée Agent (ABC5) dans le

développement de systèmes complexes répartis sous forme de Système Multi Agents (SMA6). Dans

le cas de l'IoT, qui peut être considéré comme un système décentralisé des objets intelligents

coopérants, l'ABC est encore plus apte à soutenir le développement d’objet intelligent unique (dans

le petit) et du système IoT global (dans le grand) [2].

8.1. La technologie d'agent, pourquoi est-elle nécessaire pour l’IoT ?

L'IoT a besoin d'une architecture ouverte pour maximiser l'interopérabilité entre les

systèmes hétérogènes et les ressources distribuées, y compris les fournisseurs et les consommateurs

d'informations et de services, qu'il s'agisse d'êtres humains, de logiciels, d'objets intelligents ou de

dispositifs. Cette architecture devrait également considérer que l’IoT peut être formé par une

myriade de dispositifs différents, qui doivent être adressés et localisés, en utilisant des mécanismes

efficaces faciles à utiliser pour les développeurs d'applications [12].

La technologie de l'agent offre les moyens nécessaires pour gérer de manière satisfaisante

de nombreuses exigences de distribution IoT [12]: les agents logiciels sont réactifs, proactifs et leur

communication est supportée par des plateformes d'agents distribués (APs) [12]. Il existe différents

plates-formes d’agent qui fonctionnent dans certains des périphériques IoT. Ainsi, les agents qui

s'exécutent dans les nœuds IoT fournissent un bon moyen d'encapsuler la fonctionnalité, d'extraire

des applications du matériel hétérogène sous-jacent et des détails d'implémentation. De plus, si

chaque objet ou nœud IoT est un agent, la découverte de nouveaux agents est faisable (c'est-à-dire

les nouveaux objets et les nœuds IoT) via le DF7 fourni par l'AP, traitant adéquatement du

problème d'adressabilité de l'IoT [2].

8.2. Agent Orienté IoT

Le processus de développement de l'écosystème IoT comprend plusieurs exigences, à la

fois au niveau du système (par exemple, l'évolutivité, la robustesse, la conformité aux normes, la

découverte) et au niveau de l’objet (par exemple, interopérabilité, virtualisation, intelligence

intégrée) [2].

L’informatique basée agents offre les solutions nécessaires pour répondre de manière

satisfaisante à ces exigences en exécutant des agents dans des nœuds IoT et donc en traitant

l'écosystème IoT comme un SMA. L'idée de coupler étroitement chaque objet intelligent avec (au

moins) un agent [2] a de multiples avantages puisque l'agent (s) permet d'atténuer les lacunes

5 Agent-Based Computing 6 Multi-Agents System 7 Directory Facilitator


19

matérielles / logicielles de l'hôte SO. En fait, les agents sont capables d'encapsuler des

fonctionnalités complexes en les abstrayant des détails d'implémentation sous-jacents,

communiquent simultanément sur différentes technologies d'accès, interagissent avec la

proactivité, l'autonomie et la sociabilité [12].

En conséquence, les agents fonctionnant dans différents SOs coopérants constituent un

SMA décentralisé, maximisant l'interopérabilité entre les sous-systèmes hétérogènes et les

ressources distribuées, facilitant la modélisation et le développement du système, augmentant

l'évolutivité et la robustesse, tout en réduisant le temps de conception ainsi que le délai de mise sur

le marché [2].

9. Conclusion

Ce chapitre a fait l’objet d’une étude détaillée de la technologie d’IoT. Nous avons présenté les

différents concepts et composants ainsi que les caractéristiques liés à l’IoT. En outre, nous avons

étudié l’utilisation des systèmes multi agents dans le domaine d’IoT.

Afin de mettre le point sur l’avantage d’adopter une modélisation basée agent des systèmes d’IoT,

nous consacrons tout un chapitre pour l’étude de ce paradigme (voir chapitre 3).

Parmi les problématiques posées par l’utilisation des systèmes d’IoT, on trouve le diagnostic qui

consiste à détecter les composants défaillants. C’est auteur de ce point que se concentre notre

recherche. Donc, le prochain chapitre est consacré à l’étude des différentes techniques de

diagnostic des systèmes.

Chapitre 2 : étude des

approches de diagnostic

des systèmes

Chapitre 2 : Etude des Approches de Diagnostic des Systèmes

21

Chapitre 2

Etude des Approches de

Diagnostic des Systèmes

1. Introduction

e diagnostic des systèmes informatiques suscite, depuis plusieurs décennies, un intérêt

croissant tant au niveau du monde industriel que de la recherche scientifique. A

l’origine, le diagnostic se limitait aux applications industrielles à haut niveau de risque

pour des communautés telles que la nucléaire ou l’aéronautique [46], ainsi qu’aux

secteurs d’activité de pointe tels que l’industrie de l’armement ou l’aérospatial. Les premiers travaux

concernant le thème diagnostic datent du début des années 1970 [47] En raison de l’intérêt croissant

suscité dans plusieurs domaines, le diagnostic est devenu peu à peu un thème de recherche à part

entière.

2. Terminologie :

Avant d’aller plus loin, il convient de définir quelques concepts et notions utilisés au sein

de la communauté du diagnostic, entre autres, un défaut, une défaillance, une panne, un état de

fonctionnement normal, termes auxquels nous aurons souvent recours dans la suite de ce

manuscrit.

Fonctionnement normal d’un système : Un système est dit dans un état de

fonctionnement normal lorsque les variables le caractérisant (variables d’état, variables de

sortie, variables d’entrée, paramètres du système) demeurent au voisinage de leurs valeurs

nominales [22].

Dysfonctionnement : Le dysfonctionnement peut être défini comme étant toute

irrégularité intermittente survenant au niveau d’une fonction remplie par le processus [23].

Défaut : On appelle défaut tout écart entre la caractéristique observée sur le dispositif et la

caractéristique théorique. Cet écart est idéalement nul en l’absence de défaut. Les défauts

peuvent apparaître au niveau des capteurs, des actionneurs ou au niveau du processus lui-

même [22].

Défaillance : Une défaillance est l’altération ou la cessation de l’aptitude d’un ensemble à

accomplir sa ou ses fonctions requises avec les performances définies dans les spécifications

techniques. Une défaillance est un dysfonctionnement du système, le processus présente

alors un fonctionnement inacceptable du point de vue des performances. Il est clair qu’une

défaillance implique l’apparition d’un défaut puisqu’il existe un écart entre la caractéristique

mesurée et la caractéristique théorique. Par contre, un défaut n’implique pas nécessairement

L


22

une défaillance puisque le diapositif peut très bien continuer à assurer sa fonction principale

[22].

Panne : Une panne est l’inaptitude d’un dispositif à accomplir une fonction requise. Une

panne résulte toujours d’une défaillance et donc d’un défaut. La relation entre défaillance,

panne et défaut peut être résumée ainsi par le schéma ci-dessous :

Figure 5: Relation de causalité entre défaillance, panne et défaut

Perturbation : Une perturbation est entrée du système physique qui n’est pas une

commande. Autrement dit, c’est une entrée non contrôlée [24].

Résidu : Un résidu est un indicateur de défauts basé sur la différence entre les mesures

et les calculs [23].

3. Définition de diagnostic

Dans cette section, nous présentons quelques définition du diagnostic afin de clarifier un

tel domaine et de dégager ses propriétés et caractéristiques.

Le diagnostic est défini comme étant l’identification de la cause probable de la (ou des)

défaillances à l’aide d’un raisonnement logique fondé sur un ensemble d’informations

provenant d’une inspection ou d’un contrôle sur le système à diagnostiquer. Par exemple, le

système peut observer une perte de données et la diagnostiquer en identifiant si elle provient

de fautes logicielles, de pannes de nœuds ou de problèmes de liaisons, etc [25].

Un diagnostic est un état expliqué d’un système physique compatible avec les informations

disponibles sur le comportement réel du système et avec le modèle de comportement de

référence disponible. Habituellement, le diagnostic est exprimé par les états des composants ou

les états des relations de description du comportement [26].

Le diagnostic consiste à détecter, localiser et éventuellement identifier les défauts qui affectent

un système [27]

Détection : Premier niveau du diagnostic consiste à prendre une décision binaire : soit

le système fonctionne correctement, soit une panne s'est produite. Le résultat de la

procédure de détection est une alarme signifiant que le fonctionnement réel du système

ne concorde plus avec le modèle de fonctionnement sain.

Localisation : Deuxième niveau du diagnostic, déclenché par une procédure de

détection, consistant à déterminer de manière plus approfondie les composants

défaillants : capteur, actionneur, processus ou unité de commande.

Identification : L'identification d'un défaut est le fait d'estimer l'amplitude et l'évolution

temporelle du défaut afin d'expliquer au mieux le comportement du système. Cette partie

Défaillance Panne Défaut


23

d'identification du défaut est la dernière phase de la procédure de diagnostic. Elle est

optionnelle.

4. Principe de fonctionnement de diagnostic

D’après la troisième définition du diagnostic, nous pouvons dire que la détection et la

localisation constituent les deux étapes essentielles d’une procédure de diagnostic. D’autres étapes

supplémentaires peuvent être rajoutées afin de mieux raffiner le diagnostic et ce par rapport à des

objectifs fixés liés aux méthodes de diagnostic utilisées [43].

4.1. La Détection

Egalement appelée « génération de symptômes », il s’agit de vérifier, grâce à des tests, la

consistance entre des informations sur le comportement réel d’un système physique tel qu’il peut

être observé par l’intermédiaire de capteurs par exemple et son comportement attendu tel qu’il peut

être prédit grâce aux modèles de bon ou mauvais comportement. Toute contradiction entre

les observations et les prédictions déduites des modèles est nécessairement la manifestation d’un

dysfonctionnement, c’est-à-dire de la présence d’un ou plusieurs défauts. La détection détermine

donc le fonctionnement normal ou anormal du système [29]. Différents types d’algorithmes de

détection dédiés aux systèmes physiques ont été conçus par les chercheurs des communautés FDI

(Fault Detection and Isolation), SED (Systèmes à évènement discrets) et DX (communauté

d’Intelligence Artificielle). Dans la plupart des cas, les méthodes de diagnostic sont liées à la

connaissance disponible sur le système et à sa représentation et sont classées de différentes façons

par de nombreux auteurs [28].

4.2. L’Analyse

Connue aussi sous l’appellation de localisation ou raisonnement diagnostic, elle consiste à

analyser les symptômes disponibles fournis par les tests de détection pour déterminer les états

plausibles d’un système physique. La localisation permet de remonter à l’origine de l’anomalie et de

localiser le ou les composants défectueux [28].

Les méthodes d’analyse sont liées à la connaissance disponible sur le système à

diagnostiquer et à sa représentation et sont classées de différentes façons par de nombreux auteurs

[29]. La terminologie et la classification ne sont pas toujours homogènes, influencées par les

contextes et les terminologies particulières à chaque communauté et domaine d’application [43].

Les méthodes de diagnostic varient selon le type de connaissance du système à

diagnostiquer, selon la façon de structurer cette connaissance et de l’utiliser lors de la génération

d’un diagnostic. Il est donc possible de classer les méthodes de diagnostic selon l’un ou l’autre de

ces trois aspects [44]. Trois grandes catégories de méthodes sont identifiées dans cette classification

[41] :

les approches à base de règles.


24

les approches à base de modèles.

les approches à base de données.

Les techniques de diagnostic à base de modèles (DBM) issues de la communauté de

l’intelligence artificielle (DX) sont fondées sur une théorie logique. Dans ces approches la détection

est considérée comme une tâche du diagnostic. Les premiers travaux s’appuyaient sur des

associations de connaissances empiriques, comme ce qui est fait dans les systèmes experts. Ces

approches utilisent des modèles basés sur la connaissance du système à diagnostiquer [43].

De façon générale, deux types d’approches de DBM peuvent être distinguées [41] : celles

s’appuyant sur un modèle de comportement anormal (fautes) et celles qui reposent sur des modèles

du comportement normal (bon) du système. Dans ce dernier cas, le modèle décrit uniquement

comment se comporte le système quand il fonctionne correctement. De nombreux travaux dans

ce domaine sont connus sous l’appellation de « diagnostic à partir des principes premiers » ou à base de

cohérence [28] et s’appuient sur un modèle de la structure du système et du comportement de ses

composants, pour effectuer des prédictions sur les états du système.

Figure 6: procédure de diagnostic. [29]

5. Les méthodes de diagnostic

Les méthodes de diagnostic se distinguent selon différents critères [31] :

la dynamique du procédé (discret, continu ou hybride),

la complexité du procédé, l’implémentation du diagnostic en ligne et/ou hors ligne,

la nature de l’information (qualitative et/ou quantitative),

la profondeur de l'information (structurelle, fonctionnelle et/ou temporelle), sa distribution

(centralisée, décentralisée ou distribuée), ….

En général, ces méthodes sont classées en trois catégories [45] :

Les méthodes internes : (model-based methods) qui représentent des méthodes à base de

modèles quantitatifs et/ou qualitatifs.

Modèle Différence de

structure

Différence de

comportement

Système physique

Comportement

observé Comportement

attendu


25

Les méthodes externes: (model-free methods) qui sont des méthodes soit à base de

connaissances, soit des méthodes empiriques et/ou de traitement du signal.

Méthodes basées sur le mode de raisonnement: sont basée sur le mode de raisonnement

utilisée pour remonter à la cause de la défaillance.

Une autre classification est donnée par la figure 3 :

Figure 7: Classification des méthodes de diagnostic [50]

5.1. Méthode de diagnostic a base modèle

Cette méthode s’appuie uniquement sur la vérification de la consistance entre le

comportement réellement observé du système et le comportement attendu de ce système. Selon la

connaissance du processus, il est possible de définir trois formulations différentes de cette approche

à base de modèles [30].

Approche FDI [31] : Cette approche se consacre principalement à la partie détection qui

consiste à générer les symptômes les plus révélateurs possible de l’état courant du système.

Cette approche se base sur les modèles quantitatifs.

Les méthodes de la communauté FDI sont nommées “méthode des résidus”. Ces

méthodes comportent deux étapes [31] :

Génération des résidus.

Le choix d’une règle de décision pour l’analyse diagnostique Les résidus représentent

des changements entre le comportement réel du système et celui attendu par le modèle.

Ces résidus doivent avoir une valeur nulle en fonctionnement normal (pas de défauts).

Au contraire, en présence de défauts, la valeur de ces résidus sera non nulle.


26

Figure8: Génération des résidus [45]

Ces résidus doivent être sensibles aux défauts et insensibles aux perturbations (bruit de

mesure et bruit de structure qui sont conçus comme normaux). L’approche FDI vise autant que

possible à faire qu’un résidu soit sensible à un seul défaut. Lorsque cela est possible, l’analyse

diagnostique devient triviale mais n’offre malheureusement aucune garantie de résultat c’st-`a-dire

qu’il n’est pas possible de prouver que le diagnostic fourni est juste même si la modélisation l’est :

cela est dû à l’hypothèse d’exonération qui consiste à considérer qu’en l’absence d’anomalie, tous

les composants couverts par un test fonctionnent correctement. Dans la pratique, cette hypothèse

est rarement vérifiée car un modèle de défaut ne se révèle pas en permanence [31].

Approche DX [32] : L’approche DX, issue de la communauté de l’Intelligence Artificielle

exprime explicitement le lien entre un composant et les formules décrivant son comportement.

Le but de cette théorie est de déterminer les composants défectueux d’un système physique.

Cette approche est basée sur l’analyse d’inconsistance entre les observations et le

comportement attendu [32].

Pour analyser la diagnosabilité des systèmes, l’approche DX utilise le concept de conflit.

Un conflit est un ensemble de composants dont les hypothèses de comportement correct ne

sont pas consistantes avec les observations réelles. Si un défaut se produit dans le système, alors

l’utilisation de la technique de raisonnement à base de consistance nous permet de localiser les

composants défectueux [32].

Approche bridge entre FDI et DX [45] : Des études comparatives entre l’approche FDI et

l’approche DX ont été réalisées par le groupe de travail français IMALAIA. Dans cette

approche, le mécanisme de localisation de défauts est basé sur l’approche DX, et l’avantage

principal est que les défauts multiples peuvent être implicitement manipules.

Dans cette approche, nous supposons que le système est composé d’un ensemble de

composants C. Le comportement de chaque composant c ∈ C est modélisé par un ensemble

de relations. Ce comportement peut varier selon le mode comportemental du composant.


27

L’outil principal de diagnostic dans l’approche bridge est la conception des RRAs. Une relation

de redondance analytique RRA est une contrainte déduite du modèle du système, qui ne

contient que des variables connues et qui peut être évaluée à chaque observation.

Figure 9: Principe de diagnostic a base modèle [33].

Les avantages des approches à base modèle [34]:

La connaissance sur le système est découplée de la connaissance de diagnostic

Il s’agit de connaissance de conception plutôt que d’exploitation

Les fautes et les symptômes ne doivent pas être anticipés

Le coût de développement et de maintenance est moindre

Les modèles fournissent un support adéquat pour l’explication (structure du système

explicitement représentée).

5.2. Le diagnostic à base d’arbre de décision

Principe [49] : L’arbre de décision est un outil qui permet de créer des scénarios pour

diagnostiquer un système. Chaque scénario est décrit sous forme arborescente comportant des

nœuds et des branches descendantes de chaque nœud. Chaque nœud est étiqueté par une

question ou une décision. Un arbre de décision commence par un nœud initial nommé "racine"

et il se termine par des nœuds terminaux nommés "feuilles". La racine et les nœuds

intermédiaires guident l’opérateur à effectuer des tests ou des mesures sur le système. Les

feuilles donnent des diagnostics finaux. Selon la réponse à la question, une branche descendante

de l’arbre est atteinte.

Les avantages [35]: L’avantage de l’arbre de décision est qu’il donne un outil simple et facile

à appréhender pour décrire des procédures de résolution de problème. Il peut être utilisé pour

les systèmes de diverses natures. Potentiellement, il permet de diagnostiquer des défauts

multiples en garantissant les diagnostics obtenus mais avec condition que toutes les situations

soient présentées.


28

Les inconvénients [35] : L’inconvénient de cette approche est qu’elle dépend totalement de

l’expertise et de la diversité des situations d’observation. Pour des symptômes initiaux

différents, les arbres peuvent être différents.

5.3. Les systèmes experts

Définition : Les systèmes experts sont des outils de l'intelligence artificielle, utilisés

lorsqu’aucune méthode algorithmique exacte n'est disponible ou praticable. De façon générale,

nous pouvons dire qu'un système expert sert à codifier la connaissance humaine en termes

d'expérience, raisonnement approximatif, analogie, raisonnement par défaut, apprentissage, etc

[48].

De ce fait, la propriété principale de ces systèmes est de pouvoir représenter et restituer les

connaissances acquises par les spécialistes d'un domaine technique précis. Les connaissances

utilisées, dans la plupart des cas, pour le développement d'un système expert d'aide au

diagnostic, reposent sur l'apprentissage des relations entre les causes et les effets observés pour

chaque défaillance. Néanmoins, il est possible aussi d'utiliser les modèles fonctionnels décrivant

les comportements des composantes de systèmes complexes [52].

L'approche par systèmes experts est différente des méthodes précédentes, dans le sens où

elle vise à évaluer les symptômes obtenus par la détection matérielle ou logicielle.

Le système expert se compose habituellement d'une combinaison de règles logiques du genre :

SI [état du système i] ET (fait observable) ALORS [état du système j],

Où chaque conclusion peut, alternativement, servir d'état dans une prochaine règle

jusqu'à ce que la conclusion finale soit atteinte. Le système expert peut soit fonctionner grâce

à l'information qui lui est présentée par la détection matérielle ou logicielle ou soit interagir avec

un opérateur humain, s'enquérant auprès de lui des symptômes particuliers et le guidant au

travers des processus entièrement logiques [52].

Les composants d'un système experts : Un système expert est composé de deux parties

indépendantes :

Une base de connaissances : elle-même composée d'une base de règles qui modélise la

connaissance du domaine considéré et d'une base de faits qui contient les informations

concernant le cas traité,

Un moteur d'inférences : capable de raisonner à partir des informations contenues dans

la base de connaissances, de faire des déductions, etc. Au fur et à mesure que les règles sont

appliquées des nouveaux faits se déduisent et se rajoutent à la base de faits.

Principe [51] : Les systèmes experts utilisent une information heuristique pour lier les

symptômes aux défauts [53] Ce sont des systèmes à base de règles qui établissent des

associations empiriques entre effets et causes [54].

Ces associations sont généralement fondées sur l’expérience de l’expert plutôt que

sur une connaissance de la structure et/ou du comportement du système. Leur


29

fonctionnalité est de trouver la cause de ce qui a été observé en parcourant les règles par

un raisonnement inductif par chaînage avant ou arrière.

Les informations nécessaires :

utilisent une information heuristique pour lier les symptômes aux défauts,

l’expérience de l’expert plutôt que sur une connaissance de la structure et/ou du

comportement du système,

établissement des associations empiriques entre effets et causes.

Les principaux domaines d’application [51] : On trouve des systèmes expert de diagnostic

dans des secteurs aussi divers que la médecine, l’industrie, l’assurance…

Dans l’industrie, on développe des systèmes expert dans différents domaines d’activité

tels que la Conception Assistée par Ordinateur (CAO mécanique ou électronique), la

productique (contrôle/ commande de processus, ordonnancement, planification de tâches,

robotique), et le diagnostic qui regroupe : diagnostic de panne, incident, défaut de fabrication

...

Un système expert peut également aider à choisir un matériau ou un composant dans

une base de données.

En effet, chaque réalisation d’un système expert s’intègre dans un environnement

particulier de développement et doit être adaptée au cadre d’utilisation.

Un système expert est développé, par exemple, pour :

4. sauvegarder une expertise accumulée ;

5. la diffuser dans le temps ;

6. la diffuser dans l’espace ;

7. formaliser une connaissance de conception.

Les avantages et les inconvénients : Les principaux avantages des systèmes experts pour le

diagnostic sont leur capacité à raisonner sous incertitude et leur capacité à apporter des

explications des solutions fournies. La qualité première des systèmes experts réside dans leur

efficacité au niveau temps de calcul. Le système doit simplement attendre les événements

observables des règles pour "sauter" directement aux conclusions. De plus, l’interprétation du

résultat est généralement compréhensible pour l’opérateur puisque ces règles sont le produit

d’experts humains. Enfin, les systèmes experts sont facilement implantables puisqu’il s’agit

d’une énumération de règles [51].

Cependant, ils sont totalement dépendants de l’expertise, et les règles acquises sur une

application ne peuvent pas être utilisées sur une autre application. Dans le cas de nouveaux

systèmes, il n’y a pas ou peu d’expériences au sujet des pannes pouvant se produire, ce qui rend

difficile l’acquisition des règles. Un système expert ne peut être opérationnel dès le début de

son exploitation et a donc besoin de temps pour son apprentissage. Il en est de même lors

d’ajouts ou de suppressions de composants. Enfin, un système expert est la conséquence d’une

règle reconnue. Il ne donne pas d’explication sur les conclusions données et rend donc difficile


30

la détection sur la propagation de pannes, La difficulté spécifique de leur mise en œuvre est la

formalisation de la démarche cognitive qui a pour objectif, à partir d'une situation donnée, de

définir et de décrire le raisonnement associé [51].

6. Diagnostic centralisé, décentralisé et hybride

Approche centralisée [41] : Elle repose sur un nœud central qui diagnostique les fautes

en se basant sur des informations recueillies des nœuds du réseau. Cette approche assure

une supervision globale de l’état du réseau permettant de garantir une exactitude quant au

diagnostic des problèmes complexes (par exemple, la défaillance des nœuds critiques,

l’occurrence des fautes simultanées ou l’affection d’une zone complète des nœuds, etc.). Les

limites de cette approche sont liées à une dépendance forte due à la centralisation exclusive

des opérations de diagnostic. D’une part, cette approche n’est pas robuste vis-à-vis de la

perte des messages transmis sur un réseau sans fils de communication multi saut. De plus,

l’arrêt accidentel du point central entraîne également l’arrêt du système de diagnostic [41].

Approche distribué (décentralisé) [41] : La détection des fautes est réalisée de façon

distribuée par l’ensemble des nœuds du réseau. Elles permettent de limiter la surcharge de

la communication et d’améliorer la robustesse du système. Cependant, des mécanismes de

coopération doivent être mis en œuvre pour assurer la cohérence dans les opérations de

gestion exécutées par les nœuds [41].

Les méthodes de diagnostic dites décentralisées deviennent nécessaires lorsqu’on

considère des systèmes à événements discrets où l’information est décentralisée. Ceci est le

cas lorsque le système a une architecture répartie où plusieurs sites observent son

comportement. Chaque site reçoit les observations d’un sous-ensemble de l’ensemble des

capteurs et doit faire son propre diagnostic en se basant sur ses observations et sur le

modèle de l’ensemble du système. Les sites ne peuvent pas échanger entre eux des messages

durant l’évolution du système. Par contre, les résultats du diagnostic local à chaque site sont

communiqués à un coordonnateur où les diagnostics locaux sont fusionnés. Nous nous

intéressons au cas où le coordonnateur a une structure qui est la plus simple possible, c’est-

à-dire qu’il consiste d’une simple fonction booléenne sans mémoire [41].

Approche hybride [41] : Elle combine le principe des deux approches centralisée et

distribuée. Le but est de pouvoir profiter des avantages des deux approches : l’exactitude

et la précision des approches centralisées et l’efficacité de la gestion de l’énergie et le passage

à l’échelle des approches distribuées [41].

7. Comparaison entre le diagnostic centralisé, décentralisé et hybride

Critère de comparaison Diagnostic

Centralisé

Diagnostic

Distribué

Diagnostic

Hybride

Précision/exactitude Bonne Moyen Bonne


31

Consommation d’énergie Forte Faible Moyenne

Robustesse Non Oui Oui

Latence de détection Bonne Faible Faible

Complexité

d’implémentation

Non Oui Oui

Impacts sur la

performance du réseau

Oui Fiable ou moyenne Moyenne

Passage à l’échelle Non Oui Oui

Visibilité limitée de

l’état du système

Non Oui Non

Tableau 6 : Comparaison entre les trois approches de diagnostic [41]

La méthode Approche de

diagnostic Les points fort et faible de chaque technique

A base Modèle FDI donne un outil pour traiter les modèles quantitatifs.

elle exige des modèles mathématiques précis et complets.

N’est pas garantie

la comparaison entre les vecteurs colonnes d’observation et

les vecteurs colonnes de signature dans la table de signature

ne permet pas de détecter facilement les défauts multiples..

DX permet aussi de traiter les défauts simples et multiples

obtenir une garantie des résultats

le raisonnement diagnostique logique à partir des conflits peut

conduire aux diagnostics physiquement impossibles.

Bridge

entre FDI et

DX

Combine les points forts des 2 approché précédents

Arbre de

décision

il donne un outil simple et facile à appréhender pour décrire des procédures

de résolution de problème.

Il peut être utilisé pour les systèmes de diverses natures.


32

Tableau 7: Etude critique des approches de diagnostic présentées

8. Conclusion

La tâche de diagnostic consiste à détecter les anomalies (défauts) intervenant sur un

système puis à expliquer ces erreurs en indiquant les composants pouvant être défaillants. Pour

cela, le diagnostic à base de modèles utilise une description du fonctionnement du système [42].

Il est ainsi clair que la diversité apparente des méthodes proposées dans la littérature

pour réaliser le diagnostic des systèmes dynamiques présentent des points incontournables : toutes

sont basées d’une part sur la connaissance générale du système étudié, sur son auscultation serrée

au moyens de chaînes de mesures et de capteurs et finalement sur le croisement d’information à

l’aide de redondances, que celles-ci soient physiques ou analytiques. Il s’agira donc, afin de répondre

aux contraintes économiques et de sécurité, de faire une exploitation optimale d’une information

redondante minimale [44].

Dans ce travail, nous allons utiliser une approche de diagnostic à base de consistance

utilisant un système à base de connaissances comme modèle de diagnostic. La mise en œuvre de

il permet de diagnostiquer des défauts multiples en garantissant les

diagnostics obtenus mais avec condition que toutes les situations soient

présentées.

il dépend totalement de l’expertise et de la diversité des situations

d’observation.

Pour des symptômes initiaux différents, les arbres peuvent être différents.

Système

expert

La capacité à raisonner sous incertitude et leur capacité à apporter des

explications des solutions fournies.

La qualité première des systèmes experts réside dans leur efficacité au niveau

temps de calcul.

l’interprétation du résultat est généralement compréhensible pour l’opérateur

puisque ces règles sont le produit d’experts humains.

les systèmes experts sont facilement implantables puisqu’il s’agit d’une

énumération de règles.

ils sont totalement dépendants de l’expertise, ne peuvent pas être utilisées sur

une autre application.

Dans le cas de nouveaux systèmes, il n’y a pas ou peu d’expériences au sujet

des pannes pouvant se produire, ce qui rend difficile l’acquisition des règles.

besoin de temps pour son apprentissage.

un système expert est la conséquence d’une règle reconnue. Il ne donne pas

d’explication sur les conclusions données et rend donc difficile la détection

sur la propagation de pannes, La difficulté spécifique de leur mise en œuvre

est la formalisation de la démarche cognitive qui a pour objectif, à partir d'une

situation donnée, de définir et de décrire le raisonnement associé.


33

cette approche est basée sur le paradigme des systèmes multi agents. Ce paradigme fait l’objet du

prochain chapitre

Chapitre 3 : étude des

systèmes multi agents

Chapitre 3 : Etude des Système Multi-Agent

35

Chapitre 3

Etude des Systèmes

Multi-Agents

1. Introduction

e domaine des systèmes multi-agents (SM), s’il n’est pas récent, est actuellement

un axe de recherche très actif. Cette discipline est à la connexion de plusieurs

domaines en particulier de l’intelligence artificielle, des systèmes informatique

distribués et du génie logiciel. C’est une discipline qui s’intéresse aux

comportements collectifs produits par les interactions de plusieurs entités

autonomes et flexibles appelées agents.

Ce chapitre introduit les notions d’agents et de systèmes multi-agents ainsi

que leurs caractéristiques, architectures, domaines d’applications et d’autres concepts sous-jacents

à ce paradigme.

2. Les Agents

Dans la littérature, on trouve plusieurs définitions d’agents qui se ressemblent mais qui

diffèrent selon le type d’application pour lequel l’agent est conçu. D’après Ferber [55], un agent est

une entité physique ou virtuelle qui agit dans un environnement, communique directement avec

d’autres agents, possède des ressources propres, est capable de percevoir partiellement son

environnement et possède des compétences. En fonction des ressources, des compétences et des

communications, un agent tend à satisfaire ses objectifs.

Voici l’une des premières définitions de l’agent due à Ferber [58] : ‘’Un agent est une entité autonome,

réelle ou abstraite, qui est capable d’agir sur elle-même et sur son environnement, qui, dans un univers multi-

agent, peut communiquer avec d’autres agents, et dont le comportement est la conséquence de ses observations, de

ses connaissances et des interactions avec les autres agents.’’

Il ressort de ses définitions que l’agent reçoit des informations de son environnement et

peut agir en retour dessus.

Pour Wooldrige [59] : « Un agent est un système informatique qui est situé dans un certain environnement,

et qui est capable d'agir de manière autonome dans cet environnement afin de répondre à ses objectifs de

conception. ».

L


36

Un agent est une entité autonome se situant dans un environnement spécifique, il est

capable de vivre autonome et flexible en percevant et en s’agissant sur son environnement pour

obtenir son propre but [56].

2.1. Les propriétés d’un agent

Autonomie : L’agent doit agir, prendre ses décisions seul sans l’intervention des autres en

fonction des informations qu’il possède sur l’environnement et les autres agents [72] .

La réactivité : est la propriété essentielle pour un agent. Cette caractéristique rend l’agent

capable d’interagir avec l’environnement et avec les autres agents. C’est-à-dire perçoit les

événements de son environnement et réagir par conséquence [72].

La proactivité : Prendre l’initiative pour satisfaire les buts [72].

L’efficacité : C’est la capacité de résoudre le problème posé et atteindre l’objectif [72].

L’adaptation : L’agent doit être capable d’apprentissage c’est-à-dire de résoudre des nouveaux

problèmes à partir des problèmes résolus précédemment ; que l’on s’appelle l’expérience [72].

La robustesse : Cette propriété est le complémentaire de la précédente. La robustesse c’est

que l’agent n’adapte pas trop vite afin de ne pas tomber dans le problème d’être influencé par

des faux signaux. Pour cela l’agent doit donc avoir un juste équilibre entre l’adaptation et la

robustesse [72].

La sociabilité : L’agent doit obligatoirement avoir des capacités de communication (un

comportement social) pour vivre dans son environnement avec les autres agents [62].

2.2. Typologie des agents

Selon Ferber [55] ; il existe deux grandes écoles de pensée dans la communauté des agents :

l’école cognitive qui conçoit les agents comme des entités intelligentes et l’école réactive qui

conçoit les agents comme des entités très simples réagissant directement aux modifications de

l’environnement. Ces deux grandes familles d'agents sont classées selon leurs capacités de

résolution de problèmes.

La première école « cognitive » ou dit délibérative représente le domaine de l’intelligence

artificielle distribuée à cause de son origine qui est de faire communiquer des systèmes experts

classiques. Dans ce sens ; un SMA se compose des agents « intelligents », chacun d’entre eux à

une base de connaissance comprenant les informations et les savoir-faire nécessaires. Ces

agents également possèdent des buts et des plans explicites pour satisfaire ces derniers [73].

Contrairement la deuxième école « réactive » considère qu’il n’est pas nécessaire que tous

les agents soient intelligents individuellement pour obtenir un système avec un comportement

global intelligent. Ce type d’agents possède des mécanismes de réaction aux évènements très

simples en absence de l’explicitation des buts et les mécanismes de planification ; et en

recueillant le tout on peut résoudre le problème complexe. L’exemple réel de ce genre est celui

de la fourmilière qui ne donne pas à une fourmi l’autorité stricte sur les autres mais les fourmis

se coordonnent pour que la colonie survivre et battre des problèmes complexes tels que la

recherche de nourriture, la construction des nids … etc [57].

En réalité cette division cognitif/réactif est parfois trop simpliste. Il nous faut l’affiner en

choisissant d’autres dimensions de classification [73]. Pour cela Nwana dans son article [60] a

proposé plusieurs axes de classification d’agents qui sont :

1) Mobilité : Un agent peut être mobile ou statique c’est-à-dire son capacité de se déplacer dans le

réseau[60].


37

2) Délibératif / réactif : un agent délibératif est un agent qui possède un modèle de raisonnement

interne et une présentation symbolique de l’environnement ; il engage dans la négociation et la

planification afin de réaliser la coordination avec les autres agents[60].

3) Rôles : Les agents peuvent parfois être classés en fonction de leurs rôles. Par exemple les agents

d’informations ou d’internet qui aident à gérer la grande quantité d'informations dans les

réseaux[60].

4) Hybride : Ces agents combinent deux ou trois philosophies d’agent en un seul. Ce type d’agent

est conçu pour surmonter les faiblesses des agents réactifs et des systèmes cognitifs. Ils

consistent à maintenir une certaine réactivité d’un agent en le dotant de composants réactifs et

de rendre les autres composants cognitifs pour garantir un raisonnement de qualité[60].

2.3. Architecture des Agents

Un agent se caractérise essentiellement par la manière dont il à partir d’un ensemble

d’entrées ; produit un ensemble d’action sur l’environnement ou sur les autres agents, en

d’autres termes par son architecture. Wooldridge dans [64] a divisé ces architectures en 2

parties :

2.3.1. Architecture abstraite

Nous pouvons facilement formaliser le vue abstrait d’agent par modéliser tous les états

possibles de l’environnement par l’ensemble S = {s1, s2 … }, et tous les actions possibles de

l’agent par A = {a1, a2 … }. En conséquence on peut voir l’agent comme la fonction

suivante : action ∶ S∗ → A Pour un environnement changer son état il utilise la fonction

suivante : env ∶ S X A → φ(S) qui prend l’état actuel de l’environnement et l’action de l’agent

et les coupler pour obtenir l’état de l’environnementenv (s, a). L'environnement est

déterministe si tous les ensembles compris dans env sont tous des singletons, (si le résultat

d’exécuter toute action en tous les états est un ensemble contenant un seul membre.

L’interaction entre l’agent et l’environnement est l‘historique de cet agent. Elle est illustrée

dans la séquence suivante : 𝑠0𝑎0→ 𝑠1

𝑎1→ 𝑠2

𝑎2→ 𝑠3

𝑎3→ …

𝑎 𝑢−1→ 𝑠 𝑢

𝑎 𝑢→ … En générale on est

intéressé par les agents ayant un historique infini. Pour plus de détails consulté [64].

a. Agent purement réactif : cet agent ne possède pas d’historique. Ces actions sont ce

concentre sur l’état actuel de l’environnement seulement. L’équation suivante

représente un exemple de la fonction action d’un agent purement réactif : 𝑎𝑐𝑡𝑖𝑜𝑛(𝑠) =

{ℎ𝑒𝑎𝑡𝑒𝑟 𝑜𝑓𝑓 𝑆𝑖 𝑡𝑒𝑚𝑝𝑒𝑟𝑎𝑡𝑢𝑟𝑒 𝑜𝑘

ℎ𝑒𝑎𝑡𝑒𝑟 𝑜𝑛 𝑠𝑖𝑛𝑜𝑛 La figure suivante illustre cette architecture


38

Figure 10: Architecture d’agent purement réactif

b. Agent avec état : Ce type d’agents possède une structure de données pour stocker les

états de l’environnement et leur historique. La fonction de sélection d’action inclut l’état

interne de l’agent. Voir la figure suivante

Figure 11: Architecture d’gent avec état

2.3.2. Architecture concret :

Dans l’architecture abstraite nous avons représenté l’état de l’agent d’une manière abstraite et

nous ne savons pas que ce qu’elle est exactement. Egalement nous avons considéré le processus de

prise de décision comme une fonction abstraite (la fonction action) ; mais nous n’avons pas expliqué

comment l’implémenter. Dans ce niveau nous allons remplir cette lacune par l’architecture

concrète. Cette architecture classifie les agents en 4 classes. [64]

a. L'architecture à base de logique : L’approche traditionnelle de la construction d’un

système de l’intelligence artificielle est de représenter son environnement et son

comportement souhaité symboliquement ; et de le traiter syntaxiquement. Dans ce genre

d’architecture ; cette représentation est des formules logiques, et la manipulation syntaxique


39

correspond à déduction logique, ou démonstration de théorèmes. Dans les approches de

construction d’agents basés sur la logique, la prise de décision est considérée comme

déduction, et le processus de sélection d'une action est dû au un problème de preuve. Ces

approches sont élégantes et ont une sémantique claire. Malgré ça ils présentent de

nombreux inconvénients ; y compris la complexité des calculs qui le rend incompatibles

avec les environnements de temps limité. [73]

b. L’architecture réactive : Les problèmes insolubles qui ont ravagé l'approche symbolique

a guidé les chercheurs à la rejeter et adopter une nouvelle approche ; Voilà pourquoi ils ont

pris cette architecture. Cette section présente un aperçu de l'architecture subsomption, qui est

sans doute l'architecture de l'agent réactif le plus connu développée par Rodney Brooks.

L’architecture Subsomption a deux caractéristiques essentielles. La première est que le

processus de décision couple chaque perception avec une tâche à accomplir. Et cela facilite

et accélère l’opération. La deuxième est que plusieurs comportements peuvent déclencher

en en parallèle, ce qui provoque un problème. Brooks a proposé de réarranger cette

architecture en hiérarchie ; de tel façon que le couche inférieure est capable d’empêcher le

comportement de la couche plus supérieure, et remplacer les entrées d’une couche inferieur

par les sorties de la couche plus supérieure. [64]

c. L’architecture BDI : (croyance - désir - intention) [64]

Croyance : Les informations de l’agent sur son environnement ou sur d’autres

agents.

Désire : Les états de l’environnement (ou de lui-même) que l’agent aimerait voir

réaliser

Intention : sont les désires que l’agent à décidés d’accomplir ou les actions qu'il a

décidé de faire pour accomplir ses désirs

d. Architecture en couches : L’agent est capable de se comporter d’une façon réactive et

proactive. Pour ça nous devions créer des sous-systèmes séparés pour faire face à ces

différents types de comportements. Cette idée a conduit naturellement à une classe

d'architectures dans lesquelles les différents sous-ensembles sont agencés selon une

hiérarchie de couches qui interagissent. En règle générale, il y aura au moins deux couches,

pour faire face aux comportements réactifs et proactifs, respectivement. D'une manière

générale, nous pouvons identifier deux types de flux de contrôle dans les architectures en

couches (voir la figure suivante). [64]


40

Figure 12: Architecture en couches

i. Couches verticales : Dans cette architecture ; chacun de l’entrée de la perception et

la sortie de l’action sont traités par une couche au plus. Nous distinguons 2

modèles de ce type :

i.1. Un seul sens : (One pass) L’entrée perceptuelles grimpe les couche

commençant par la couche la plus inférieure pour sortir les actions à travers la

couche la plus supérieure.

i.2. Deux sens : (Two pass) Dans les architectures à deux passes,

l'information circule jusqu'à la dernière couche (de haut), puis vers le bas pour

produire l’action résulante.

ii. Couches horizontales : Les couches ici sont chacun reliés directement à l’entrée et

à la sortie à la fois. En effet, chaque couche agit comme un agent produisant

des suggestions pour l'action à exécuter. Le grand avantage de ces architectures

est leur simplicité conceptuelle : si nous avons besoin d'un agent pour présenter

n différents types de comportement, nous mettons en œuvre n différentes

couches tout simplement. Les couches sont chacun en effet en concurrence

avec un autre pour générer des suggestions d'action ; la raison pour laquelle il y

a un danger que le comportement global de l'agent ne sera pas cohérent. Afin

d'éviter cette entrave ; ils comprennent généralement une fonction de médiateur,

qui prend des décisions quelle couche a le contrôle de l'agent à un moment

donné. [64]

2.4. Agent vs. Objet [67]

Un agent, comme un objet, encapsule un état et un comportement, mais :


41

L’agent a le contrôle sur son comportement ; un objet n’a le contrôle que sur son état.

L’agent exerce ce contrôle de différentes manières (réactif, dirigé par les buts, social

L’agent est autonome.

3. Système multi-Agent

On appelle Système Multi-Agent (SMA), un système composé des éléments suivants [55]

:

Un environnement E : c’est-à-dire un espace disposant généralement d’une métrique.

Un ensemble d’objets O : Ces objets sont situés, c’est-à-dire que, pour tout objet, il est possible,

à un moment donné, d’associer une position dans E. Ces objets sont passifs, c’est-à-dire

qu’ils peuvent être perçus, créés, détruits et modifiés par les agents.

Un ensemble A d’agents : qui sont des objets particuliers, lesquels représentent les entités

actives du système.

Un ensemble de relations R : qui unissent des objets (et donc des agents) entre eux.

Un ensemble d’opérations Op : permettant aux agents de A de percevoir, produire, consommer,

transformer et manipuler des objets de O.

Des opérateurs : chargés de représenter l’application de ces opérations et la réaction du

monde à cette tentative de modification, que l’on appellera les lois de l’univers.

3.1. L’environnement

L’environnement est l’ensemble des objets passifs composant le monde dans lequel évolue

l’agent [55]. Bien que l’environnement de l’agent soit composé d’un ensemble des objets passifs,

l’environnement lui-même est considéré comme une entité active et dynamique [71]. En effet,

l’environnement peut être modélisé par un ou plusieurs agents [71].

L'environnement est l'espace dans lequel les agents vont interagir. Cet espace

généralement est en deux ou trois dimensions. Les environnements viennent en plusieurs types.

Les principales distinctions à faire sont les suivantes [74]:

1. L’accessibilité : (accessible, non-accessible) Nous disons que l'environnement est accessible à cet

agent si ses capteurs détectent tous les états de cet environnement. Un environnement

accessible est plus pratique parce que l'agent n'a pas besoin de conserver tous les états internes

pour garder une trace du monde [74].

2. Le déterminisme : (déterministe, non-déterministe) Si le prochain état de l'environnement est

complètement déterminé par l'état actuel et les actions sélectionnées par les agents, alors nous

disons que l'environnement est déterministe [74].

3. Le dynamisme : (statique, dynamique) Si l'environnement peut changer cependant qu’un agent

délibère, alors nous disons que cet environnement est dynamique pour cet agent ; sinon il est

statique [74].

8. La continuité : (discret, continu) S'il y a un nombre limité de perceptions et d’actions clairement

définies, nous disons que l'environnement est discret. Le jeu d’échecs par exemple est discret,

il y a un nombre fixe de mouvements possibles sur chaque tour [74].


42

9. Épisodicité : (épisodique, non-épisodique) Dans un environnement épisodique, l'expérience de

l'agent est divisé en «épisodes». Chaque épisode est composé de la perception de l'agent et après

son réaction. La qualité de son action dépend juste de l'épisode lui-même. Les environnements

épisodiques sont beaucoup plus simples parce que l'agent n'a pas besoin de penser à l'avance

[74].

3.2. Types de systèmes multi agents

Les SMAs peuvent être catégorisés selon : le nombre d’agents, la nature et la complexité de

ces agents, en [65] :

SMAs ouverts : les agents y entrent et en sortent librement.

SMAs fermés : où l’ensemble d’agents restent le même.

SMA homogène : dont tous les agents sont construits sur le même modèle.

SMA hétérogène : dont les agents sont construits sur des modèles différents.

4. Les interactions dans un SMA

En général, les interactions sont mises en œuvre par un transfert d'informations entre

agents ou entre les agents et leur environnement, soit par perception, ou bien par communication.

Par la perception, les agents détiennent la connaissance de changement de comportement d'un tiers

au travers du milieu. Par la communication, un agent fait un acte délibéré de transfert

d'informations vers un ou plusieurs autres agents [63].

Situations d'interaction

Dans les systèmes multi agents, la communication est l'un des moyens utilisés pour

échanger des informations entre agents (exemples : plans, résultats partiels, buts, etc.). La capacité

de communiquer et, par conséquent, de coopérer des agents s'appuient sur un fond commun

d'aptitudes aussi complexes que la perception, l'apprentissage, la planification et le raisonnement.

On retrouve ainsi dans la résolution de problèmes des situations d'interaction et des stratégies

coopératives non déterministes, difficiles à interpréter et parfois non complètement reproductibles.

L'équilibre entre l'autonomie des agents, dotés d'un comportement plus ou moins intelligent, et la

convergence vers un objectif global caractérise l'interaction [55].

Plusieurs types d'interaction ont été définis et analysés à travers divers composantes [1].

J Ferber donne une classification des situations d'interaction abordées selon le point de vue d'un

observateur extérieur. Cette classification présente les différentes situations d'interaction que l'on

retrouve en fonction des objectifs des agents (compatibles ou incompatibles), des ressources dont

ils disposent (suffisantes ou insuffisantes) et de leurs compétences pour la résolution d'un problème

[56].

Conformément à Ferber [55] on définit la situation d'interaction comme suit : « un

ensemble de comportements résultant du regroupement d’agents qui doivent agir pour satisfaire leurs objectifs en tenant


43

compte des contraintes provenant des ressources plus ou moins limitées dont ils disposent et de leurs compétences

individuelles ». On peut classifier les principales situations d’interaction par rapport à trois critères :

les objectifs des agents qui peuvent être compatibles ou pas, le nombre de ressources disponibles

dans le système ainsi que les compétences des agents. Dans le tableau suivant on va citer tous les

cas possibles [55].

Buts Ressources Compétences Types de situation Remarques

Compatibles Suffisantes Suffisantes Independence Situation

d’indépendance

Compatibles Suffisantes Insuffisantes Collaboration simple Situation de

coopération

Compatibles Insuffisantes Suffisantes Encombrement

Compatibles Insuffisantes Insuffisantes Collaboration

coordonnée

Incompatibles Suffisantes Suffisantes Compétition

individuelle pure

Situation

d’antagonisme

Incompatibles Suffisantes Insuffisantes Compétition collective

pure

Incompatibles Insuffisantes Suffisantes Conflits individuels

pour les ressources

Incompatibles Insuffisantes Insuffisantes Conflits collectifs pour

les ressources

Tableau 8: classification des situations d’interaction [55].

Cependant, nous pouvons classifier les protocoles d’interaction selon [68], ou il a classifié

les protocoles d’interaction en quatre principales classes : les protocoles de coordination, les

protocoles de coopération, les protocoles de négociation et les protocoles de vente aux enchères

[55].


44

4.1. Les protocoles de coordination

Dans des environnements à ressources limitées, la coordination se traduit par un

comportement individuel visant à servir ses propres intérêts tout en essayant de satisfaire le but

global du système. JENINGS dans [69] caractérise la coordination par deux aspects étroitement

liés, à savoir les engagements et les conventions [69] :

Les engagements fournissent la structure nécessaire pour des interactions prévisibles. Pendant

que les situations changent, les agents doivent évaluer si les engagements existants sont encore

valides.

Les conventions fournissent des moyens pour contrôler les engagements dans des

circonstances changeantes. Un des exemples de protocole pour la coordination est celui du

réseau contractuel (Contract-Net).

4.1.1. Les protocoles de coopération

Les protocoles de coopération consistent à décomposer un problème en tâches

puis à les distribuer. Cette approche a l’avantage de réduire la complexité d’un problème. Mais

il risque d’avoir des interactions entre les tâches et par conséquent des conflits entre les agents.

Il existe plusieurs mécanismes pour distribuer les tâches. On cite les mécanismes d’élection où

les tâches sont attribuées à des agents suite à un accord ou un vote, les réseaux contractuels où

des tâches sont attribuées aux agents suite à des cycles d’appels d’offres ou de propositions

[69].

4.1.2. Les protocoles de négociation

Les protocoles de négociation sont utilisés dans le cas où les agents ont des buts

différents. Les dispositifs principaux de la négociation sont : le langage utilisé, le protocole suivi

dans le principe de négociation et la procédure de décision que chaque agent utilise pour

déterminer ses positions, ses concessions et ses critères pour l’accord [69].

5.2. Communication entre les agents

5.2.1. Définition

« La communication est l’échange intentionnel d’informations occasionné par la production et la

perception de signes issus d’un système partagé de signes conventionnels. » [65] .

Selon FERBER dans [61], Il existe deux formes de communications :

les communications intentionnelles qui mettent en contact des agents cognitifs par le biais

d’envois de messages. Cette forme de communication est surtout utilisée par des agents

organisés en réseaux.


45

les communications réactives qui prennent la forme de signaux transmis entre agents réactifs.

On rencontre ces formes de communication surtout dans la robotique collective mobile et la

simulation de sociétés animales, beaucoup moins dans les réseaux.

Figure 13: Communication entre 2 agents

Pour mieux comprendre le modèle de communication dans les SMA nous devons voir

les questions abordées par un modèle de communication qui sont proposées par MAZOUZI [68],

ces question peuvent être résumées par l'interrogation suivante : qui communique quoi, à qui,

quand, pourquoi, et comment ? [68]

Pourquoi les agents communiquent-ils ?, la communication doit permettre la mise en œuvre

de l'interaction et par conséquent la coopération et la coordination d'actions.

Quand les agents communiquent-ils ?, les agents sont souvent confrontés à des situations

où ils ont besoin d'interagir avec d'autres agents pour atteindre leurs buts locaux ou globaux.

La difficulté réside dans l'identification de ces situations. Par exemple, une communication peut

être sollicitée suite à une demande explicite par un autre agent.

Avec qui les agents communiquent-ils ?, les communications peuvent être sélectives sur

un nombre restreint d'agents ou diffusées à l'ensemble des agents. Le choix de l'interlocuteur

dépend essentiellement des accointances de l'agent (connaissances qu'a l'agent sur les autres

agents).

Comment les agents communiquent-ils ?, la mise en œuvre de la communication nécessite

un langage de communication compréhensible et commun à tous les agents. Il faut identifier

les différents types de communication et définir les moyens permettant non seulement l'envoi

et la réception de données mais aussi le transfert de connaissances avec une sémantique

appropriée à chaque type de message.

5.2.2. L’acte de langage

Les systèmes de communication entre agents sont principalement bases sur le modèle

de la théorie des actes de langage propose par les linguistes pour modéliser les échanges

d'informations entre humains [55].

En 1962, Austin pose les fondements du concept d'acte de langage dans « Quand dire,

C'est faire » [55]. Comme son titre l'indique, il considère la communication comme une action sur

l'environnement. Une demande de service revient à la réalisation même de ce service (du moins en

ce qui concerne l'état de l'environnement).


46

Après un travail de fondation important réalisé par Austin, Searle et Vanderlee [70] ont

formalisé cette théorie. Au cours de ces travaux, ils extraient du langage naturel un groupe de verbes

qu'ils baptisent performatifs5 car le fait même de les prononcer a un effet sur l'environnement, ou

plutôt sur les entités qui perçoivent le message. C'est ainsi que l'annonce d'une tragédie va

déclencher des réactions fortes par le simple fait de son énonciation [55].

Ils distinguent également trois aspects dans un message : le locutoire (le message

proprement dit), l'illocutoire (l'acte que représente le message) et le perlocutoire (les effets du

message). Ainsi, le message \il neige ce matin" est le niveau locutoire, alors que la dimension

illocutoire est la prise de conscience par les récepteurs du fait qu'il neige (assertion dans sa base de

connaissances), et la dimension perlocutoire une invitation à se couvrir [70].

Ils séparent enfin les performatifs en cinq classes en fonction de leur but illocutoire [72]

:

les assertifs, ajoutent des informations sur le monde (affirmer,. . .).

les directifs, poussent à la transformation du monde (demander, interdire,.. .).

les engageants, engagent l'émetteur (s'engager à, promettre,. . .).

les expressifs, n'ont d'effets que sur la communication (remercier, saluer,. . .).

les déclaratifs, affectent le monde et tous les interactions (déclarer la guerre,. . .).

C'est de cette modélisation du langage que sont issus les langages de communication

entre agents

5.2.3. Langages de communication inter-agents

Ces langages se focalisent essentiellement sur la manière de décrire exhaustivement des

actes de communication d'un point de vue syntaxique et sémantique supportant un langage de

représentation des connaissances. Toutefois, l'aspect ontologique et l'utilisation de conventions

garantissant un comportement collectif cohérent du système et l'aspect conversationnel n'est pas

facile à garantir [68].

KQML :

Aux Etats-Unis, un standard de langage de communication de haut niveau appelé

KQML “ Knowledge Quercy and Manipulation Language ” (Labrou et Finin, 1997) a été

développé. Ce dernier est fondé sur la théorie des actes de langage dans le but de permettre aux

agents cognitifs de coopérer. Il est basé sur le fait de pouvoir coder explicitement dans les messages

des actes illocutoires en termes de type de message ou “ performatives ” et repose sur les états

mentaux des agents. Le contenu du message échangé est une expression spécifiée en KIF

(Knowledge Interchange Format) qui utilise le formalisme de la logique de premier ordre [75].

KQML est un langage de communication et un protocole de haut niveau pour

l'échange de l'information, orienté messages et indépendant de la syntaxe du contenu et de

l'ontologie applicable. Une ontologie est une spécification ou une vue simplifié et abstraite du

domaine qui sera représenté. En d'autres termes, une ontologie définit le vocabulaire dans un


47

domaine donné pour que les agents puissent se comprendre. Conceptuellement, nous pouvons

identifier trois couches dans un message de KQML : contenu, communication et message [68].

La couche “ contenu ” comporte la teneur réelle du message utilisant un langage de

représentation propre au système. KQML peut supporter n'importe quel langage de

représentation, y compris des langages exprimés en ASCII et ceux exprimés en utilisant la

numération binaire [75].

La couche de “communication ” code un ensemble de dispositifs au message qui décrivent

les paramètres de communication les plus bas, tels que l'identité de l'expéditeur et du

destinataire et un identifiant unique associé à la communication [68].

La couche “ message ”, qui code un message qu'une application voudrait transmettre à une

autre, est le noyau de KQML. Cette couche détermine les genres d'interactions au sein des

agents dialoguant via KQML [68].

Langage de communication FIPA-ACL :

Récemment, la collaboration internationale des membres d'organisations universitaires

et industrielles regroupées au sein de FIPA (Foundation for Intelligent Physical Agents) a permis de

spécifier des standards dans la technologie agent et vise à favoriser l'interopérabilité des

applications, des services et des équipements informatiques basés sur le paradigme agent [70].

Ils ont défini un certain nombre de spécifications principales d'agents. Notamment,

un standard de langage de communication agent ACL (Agent Communication Language) a été proposé

et spécifié. Comme KQML, ce dernier est basé sur la théorie des actes de langage : les messages

sont des actions ou des actes communicatifs, car ils sont prévus pour effectuer une certaine action

en vertu de l'envoi. Les spécifications de FIPA-ACL se composent d'un ensemble de types de

message et de la description de leur pragmatique que sont, des effets sur les attitudes mentales des

agents (expéditeur et récepteur). Les spécifications décrivent chaque acte communicatif avec une

forme narrative et une sémantique formelle basée sur la logique modale [75].

Elles fournissent également la description normative d'un ensemble de protocoles

d'interaction de haut niveau, y compris la demande d'action, l'établissement de contrat et plusieurs

genres de ventes aux enchères. FIPA-ACL est superficiellement semblable à KQML. Sa syntaxe

est identique à celle de KQML excepté différents noms pour quelques primitifs réservés. Ainsi, il

maintient l'approche de KQML de distinguer le langage externe du langage interne. Le langage

externe définit la signification prévue du message ; le langage interne ou le contenu, dénote

l'expression à laquelle s'appliquent les croyances, les désirs, et les intentions des interlocuteurs [70].


48

5. Domaines d’application des Systèmes Multi-Agents

Les systèmes multi-agents et les agents autonomes fournissent une nouvelle méthode

pour analyser, concevoir, et implémenter des applications sophistiquées. En effet, ils font partie du

domaine de l’Intelligence Artificielle distribuée, qui est issue de la rencontre de disciplines aussi

différentes que l’intelligence artificielle, la sociologie, la psychologie sociale, les sciences cognitives,

la biologie, etc [69].

Vu de la diversité de ces domaines, les domaines d’application des systèmes multi

agents sont particulièrement riches. Ces domaines peuvent être scindés en cinq grandes catégories

:

La résolution de problèmes : Au sens large la résolution de problèmes, ‘Distributed Problem

Solving’ en terminologie anglo-saxonne, concerne en fait toutes les situations dans lesquelles

des agents logiciels, c’est à dire des agents purement informatiques, accomplissent des tâches

utiles aux êtres humains. Cette catégorie est subdivisée en trois classes [69]: la résolution

distribuée de problèmes, la résolution de problèmes distribués et les techniques distribuées de

résolution de problèmes.

La simulation multi-agent : La simulation est une branche très active de l’informatique qui

constitue l’un des plus puissants outils d’analyse des systèmes complexes. Elle consiste à

analyser les propriétés de modèles théoriques, dans l’objectif d’expliquer et de prévoir les

phénomènes naturels. Pour cela, les chercheurs construisent des modèles de la réalité, puis

testent leur validité en les faisant ‘tourner’ sur ordinateurs. Généralement, ses modèles sont

donnés sous la forme de relations mathématiques entre des variables représentant des

grandeurs physiques mesurables dans la réalité. Ces modèles et les techniques de simulation

numérique associées présentent néanmoins certains problèmes (complexité, difficulté à

modéliser l’action, … etc.) [69].

La robotique distribuée : L’objectif de la robotique distribuée est de réaliser un ensemble de

robots qui coopèrent pour accomplir une mission. La contribution des SMAs réside dans la

définition de mécanismes de coordination et de coopération entre des agents concrets qui se

déplacent dans un environnement réel. De cette catégorie d’applications d’autres domaines

spécifiques ont été développés : la robotique mobile, la robotique fixe (ou cellulaire), la

coordination de véhicules, qu’il s’agisse d’avions, de voitures ou de bateaux [69].

La conception kénétique de programmes : La kénétique propose une nouvelle technologie

de construction de logiciels à partir des concepts d’agents et d’interaction. Cherchant à dépasser

les techniques informatiques pour réaliser des logiciels distribués fonctionnant avec une grande

souplesse et une grande adaptabilité à leur environnement, l’objectif de la conception kénétique

de logiciels est de donner naissance à des systèmes informatiques capables d’évoluer par

interaction, adaptation et reproduction d’agents relativement autonomes et fonctionnant dans

des univers physiquement distribués [69].

6. Approches de développement des systèmes multi-Agent :

Plusieurs approche de développement des systèmes multi-agent pouvant être distingué nous

citons à titre d’exemple : l’approche voyelle, ADELFE, …


49

L’approche la plus intuitive et la plus utilisé est l’approche voyelle.

L’approche voyelle [90] : Voyelles, ou AEIO, consiste à décomposer la vue d’un SMA selon cinq dimensions, à savoir Agents (A), Environnement (E), Interaction (I), Organisation (O) et Utilisateurs (U).

A : cette composante concerne les modèles (ou les architectures) utilisés pour la partie active de l’agent.

E : elle concerne les milieux dans lesquels sont plongés les agents et qui sont généralement spatiaux dans la plupart des applications multi-agents.

I : elle concerne les infrastructures, les langages et les protocoles d’interactions entre agents.

O : elle structure les agents en groupes, hiérarchies, relations, etc.

La dernière composante (U) étant optionnelle, selon le domaine d’application. Le processus de développement est guidé par les principes suivants [90]:

Déclaratif : un SMA est composé d’agents, d’environnements, d’interactions, et d’organisations. Il s’agit de la déclaration explicite des quatre briques, tel que :

SMA = Agents + Environnement + Interactions + Organisations

Computationnel : les fonctionnalités d’un SMA incluent les fonctionnalités individuelles des agents enrichies des fonctionnalités qui résultent de la valeur ajoutée par le SMA lui-même, parfois appelée intelligence collective. Il s’agit du principe fonctionnel, telle que :

Fonction(SMA) = Fonction(Agents) + Fonction collective.

Récursion : les SMA peuvent être considérés à un niveau d’abstraction supérieur comme des

entités multi-agents, tels que : SMA* = SMA.

7. Conclusion

Les SMAs proposent aujourd’hui une nouvelle technologie effective de mise en œuvre

de systèmes complexes dès lors que ceux-ci requièrent distribution, ouverture, coopération et

autonomie ajustable. Ces systèmes forment une communauté de recherche issue de plusieurs

influences [55]. Les principales sont :

l'intelligence artificielle distribuée ;

la vie artificielle ou les systèmes inspirés d'organismes vivants ;

les sciences sociales et les sciences cognitives.

Dans ce chapitre, nous avons présenté un état de l’art sur les agents et systèmes multi

agents.

Partie 2 : contribution

Contribution

51

Contributions

près avoir présenté les concepts fondamentaux nécessaires à la réalisation de notre

projet, cette deuxième partie du manuscrit concerne la conception et la réalisation

d’un système diagnostiqueur d’IoT.

La démarche à suivre est basée sur le paradigme des systèmes multi agents. La

motivation principale derrière ce choix se justifie par le fait que les besoins requis

pour une telle réalisation s’accolent avec les caractéristiques et les propriétés de

modélisation basée agents.

Nous rappelons que l’objectif principal de ce travail consiste à développer un système de

diagnostique pour une application d’IoT. L’application d’IoT choisie est un système de monitoring

de quelques propriétés d’air telles que la température, le taux de CO2, le pourcentage d’humidité.

Ainsi, l’accès à la pièce surveillée est sécurisé. Ce système d’IoT peut être utilisé dans plusieurs

domaines tels que l’assistance médicale, les laboratoires de chimie et les systèmes domotiques.

Afin de faire face à la complexité de développement de ce projet, nous proposons la

décomposition décrite par la figure 1.

Figure 14: Vue générale du système d’IoT à développer.

En premier lieu, nous commençons par la conception et la réalisation concrète de l’objet

connecté. Il s’agit d’une application mobile assurant la transmission des grandeurs physiques

obtenues auprès des objets connectés vers un serveur local.

Par la suite, nous développons l’application serveur qui assure le diagnostic des données

reçues depuis l’application mobile. Autrement dit, la réalisation du système multi agents qui assure

le monitoring et le diagnostic.

En fin, une phase d’intégration des deux applications su citées concrétise le projet visé.

A

Application

Mobile

Application

Serveur (SMA)

Objet

connecté

Objet

connecté

Chapitre 04 : conception

et réalisation d’un objet

connecté

chapitre 4 : conception et réalisation d’un objet connecté

54

Chapitre 4 :

Conception et réalisation

D’un objet connecté

1. Introduction

Ce chapitre est consacré à la mise en œuvre d’un objet connecté. On va présenter les

différents composants et modules électroniques nécessaires à la réalisation de cet objet ainsi que la

description détaillée de la partie software qui assure l’échange de données entre l’objet connecté et

l’application serveur. L’objet à réaliser est dédié à la surveillance d’une pièce (vérification de la

température, du taux de CO2 et d’humidité). L’accès à la pièce est sécurisé.

2. Analyse des besoins

2.1. Description de l’objet à réaliser

Notre objectif consiste à réaliser un système d’IoT pour la surveillance d’une pièce. Ce

système contrôle le degré de température, le pourcentage de CO2 et d'humidité. Il contrôle

également les mouvements dans la salle afin de garantir sa sécurité. Un tel système peut être utile

dans différents domaines tels que : la santé (surveillance des malades), la gestion des entreprises,

l’agriculture, la chimie,…etc. Ainsi, il peut être utilisé, voir enrichi par d’autres fonctionnalités pour

la domotique.

En fait, économiser l’énergie et respirer un air sain sont parmi les préoccupations

majeures des personnes : La température, l’humidité ou encore le taux de CO2 sont directement

liés à ces concepts, donc le choix de ce système est motivé par : l'influence du CO2, de température

et d’humidité sur la santé des personnes malades et le besoin d’un taux acceptable de ces grandeur

dans les milieux fermés, en outre l’économie d'énergie et l’augmentation du confort dans la vie

humain.

2.2. Les propriétés de la pièce à surveiller

Les propriétés de la pièce à surveiller peuvent être résumées par le fait d’avoir un air sain

(selon le domaine d’application) tout en assurant un accès sécurisé à cette pièce. A titre d’exemple,

nous adoptons les caractéristiques suivantes :

La température : doit être entre 17 et 23 degrés.

L'humidité : doit être entre 40 et 60 %.


55

Le CO2 : une excellente ou moyenne qualité d’air est entre 400 et 600 ppm.

Les mouvements doivent être contrôlés pour des raisons de sécurité.

Notons, que d’autres caractéristiques peuvent être ajoutées et ce selon le domaine

d’application.

2.3. L’ensemble des capteurs à utiliser :

D’après la description précédente, nous proposons d’utiliser les capteurs suivants :

(1 ou 2) capteur de température ;

(1 ou 2) capteur de CO2 ;

(1 ou 2) capteur d’humidité ;

1 détecteur de Mouvement.

Une alarme sonore pour alerter les utilisateurs dans le cas d’accès non autorisé à la salle.

Des lampes pour signaler les perturbations ou les défaillances occasionnées.

2.4. Etude générale des capteurs choisis

Capteur Description générale Renseignements

techniques

Température Sont des dispositifs permettant

de transformer l’effet du réchauffement

ou du refroidissement sur leurs

composants en signal électrique [87].

Les capteurs de température sont

utilisés dans de nombreuses industries

Chimie.

Alimentation.

Analyse et optimisation de

fonctionnement (moteur..etc.)

Gestion des bains de peinture,

traitement des métaux.

Définie à partir de

l’échelle kelvin par :

T (°C)=T(K) - 273 ,15.

Le meilleur degré de

température est 19 degrés

Le degré moyen est dans

l’intervalle [18,23]

le mauvais degré de

température doit être

inférieur à 16° et supérieur à

24°.

Remarque : l’intervalle de

température désirée dans une

salle dépend du domaine

d’application. C’est à

l’utilisateur final de décider les

bornes inférieur et supérieur

de cet intervalle.

https://fr.wikipedia.org/wiki/Signal_%C3%A9lectrique


56

CO2 Lorsque de nombreuses

personnes partagent un même espace,

l’air devient rapidement irrespirable. On

doit généralement prévenir cette

sensation au dioxyde de carbone (CO2)

présent dans l'air expiré.

Application : des capteurs de CO2

dans les écoles, les bureaux et les maisons

passives et économes en énergie

La mesure du dioxyde de carbone

est exigée dans plusieurs applications,

depuis le contrôle automatique des

bâtiments et les serres jusqu'aux sciences

de la vie et la sécurité.

L’unité de mesure s’exprime en

PPM (partie par million).

1ppm=1ml=44/22.4environ

2mol de gaze/m2 par ppm

<400 ppm : excellente qualité

d'air.

400-600 ppm : qualité

moyenne.

600-1000 ppm : taux

acceptable.

>1000 ppm : mauvaise qualité

d'air (danger).

Humidité La vapeur d'eau contenue dans

l'atmosphère influence le rayonnement

solaire. Les techniques utilisées par le

capteur d'humidité sont variables, en

effet elles dépendent par exemple de la

précision de la mesure et du milieu dans

lequel on veut mesurer l'humidité.

En termes météo l'humidité

relative est définie comme le rapport

entre le rapport de mélange et le rapport

de mélange saturant et s'exprime en

pourcent : U = 100 w/ws [88].

entre 40 et 60 % : bon taux

<30 % : trop sec.

>70 % : trop humide.

Mouvement Le détecteur de mouvement,

aussi appelé détecteur de présence, peut

être installé avec une alarme pour

protéger une pièce ou un lieu.

Les variations de températures

provoquées par un mouvement humain

Si un mouvement est détecté,

le signal en sortie du capteur

est mis au niveau HAUT (1).

Si aucun mouvement n’est

détecté, le signal en sortie du

capteur est mis au niveau BAS

(0).


57

(ou animal) sont repérées par les rayons

infrarouges [89].

Tableau 9 : les propriétés des capteurs

2.5. Impact des grandeurs physiques choisis sur la vie humaine

2.5.1. La température

Bien que l’homme se soit adapté à des climats très différents dans le monde, le domaine

des températures où se développe la vie humaine est assez étroit. Notre corps doit maintenir une

température interne d’environ 37 °C et les variations très au-dessus ou au-dessous de cette valeur

peuvent nous rendre malades et affecter gravement notre santé. Actuellement un des facteurs

climatiques les plus alertant pour notre santé, est le changement climatique, qui touche surtout les

zones de températures extrêmes. Il affecte tant directement qu’indirectement notre santé [77].

2.5.2. L’humidité :

Les personnes qui habitent dans une maison où il y a des moisissures et de l'humidité sont plus

susceptibles de présenter les symptômes suivants [78]:

Irritation des yeux, du nez et de la gorge

Toux et accumulation de mucus (mucosités)

Respiration sifflante et essoufflement

Aggravation des symptômes d'asthme

et autres réactions allergiques

Certaines personnes sont plus vulnérables que d'autres aux effets des moisissures. C'est le

cas des enfants, des aînés et des personnes qui ont des problèmes de santé, comme l'asthme et des

allergies graves. Puisque certaines personnes sont plus sensibles que d'autres, aucune quantité de

moisissures n'est dépourvue de risques [78].

Certaines moisissures en suspension dans l'air peuvent causer des infections

pulmonaires graves chez les personnes dont le système immunitaire est très affaibli, comme

celles qui sont atteintes de la leucémie ou du sida ou qui ont reçu une transplantation [78].

2.5.3. Le CO2:

Différentes études ont portés sur l’observation des effets induits sur des volontaires sains

par la respiration à travers un masque d’air enrichi en CO2. On citera parmi les effets observés

[86]:

Les symptômes dose-dépendants, sensation de souffle court, oppression thoracique,

palpitations, sudations, paresthésies des extrémités et vertiges. La fréquence respiratoire n’est

pas modifiée sous 6% de CO2, elle commence à augmenter à partir de 8%. Un tiers des sujets

présents des céphalées après 5 à 20 min à 8% de CO2.


58

Les performances de raisonnement logique et arithmétique sont significativement plus lentes

sous 6,5 et 7,5% de CO2.

Les seuils sensoriels sont augmentés à partir de 5% de CO2 inhalé (sensibilité auditive,

discrimination et délai d’apparition d’images visuelles)

Temps de réaction et durée d’exécution de mouvements complexes sont allongés entre 4% et

6%. Ceci suggère une réduction des capacités de réaction en cas d’exposition accidentelle.

Des effets dépresseurs ont aussi été observés pour des concentrations faibles de CO2, ils sont

d’origine centrale, lié à l’effet narcotique.

2.6. Caractéristique des capteurs

Les capteurs sont dotés des caractéristiques suivantes :

La plage de mesure

La plage de mesure, ou gamme de mesure, est la première chose à regarder dans le choix

d'un capteur ou d'un transducteur. C'est elle qui définit si vous allez pouvoir mesurer la

grandeur physique sur une grande plage ou non. Par exemple pouvoir mesurer une température

de -50°C à +200°C. Tout dépendra de ce que vous voudrez mesurer [76].

La précision

La précision est plus grande lorsque la plage de mesure est faible et inversement elle

devient moins grande lorsque la plage de mesure augmente. Il est aussi difficile de produire un

capteur avec une grande plage de mesure [76].

La tension d’alimentation

Il est en effet important de savoir à quelle tension il fonctionne le capteur, pour ne pas

avoir de mauvaise surprises lorsque l’on vent l’utiliser [76].

2.7. Désignation des composants électroniques de l’objet connecté

Dans notre projet, nous avons choisi les composants suivants :

2.7.1. Carte Arduino UNO

La carte Arduino repose sur un circuit intégré (un mini-ordinateur appelé également

microcontrôleur) associée à des entrées et des sorties qui permettent à l'utilisateur de brancher

différents types d'éléments externes [84] :

Côté entrées, des capteurs qui collectent des informations sur leur environnement comme la

variation de température via une sonde thermique, le mouvement via un détecteur de présence

ou un accéléromètre, le contact via un bouton-poussoir, etc.


59

Côté sorties, des actionneurs qui agissent sur le monde physique elle une petite lampe qui

produit de la lumière, un moteur qui actionne un bras articulé, etc.

Comme le logiciel Arduino, le circuit électronique de cette plaquette est libre et ses plans

sont disponibles sur internet. On peut donc les étudier et créer des dérivés. Plusieurs constructeurs

proposent ainsi différents modèles de circuits électroniques programmables et utilisables avec le

logiciel Arduino [84]

Figure 15: carte Arduino UNO [84]

2.7.2. Les câbles

Les câbles à utiliser sont : un câble USB qui sert à connecter le PC et l’objet connecté et

des câbles de pointages qui servent à connecter les différents capteurs et la carte Arduino. Notant,

que le câble USB utilisé ici veille seulement à alimenter l’objet. L’échange de données se fera via

Bluetooth.


60

Figure 16: Câble USB et des câbles de pointage [85]

2.7.3. Breadbord (carte d’essai):

On a choisi une carte d’essai de type Pri’s Kit BX-4112N.

2.7.4. Les LEDs :

On va utiliser 4 LEDs, une LED pour chaque capteur et une LED pour montrer qui

l’objet et allumé

2.7.5. Résistance :

Pour chaque type de capteur nous pouvons utiliser une résistance pour la sécurité de

capteur, les LED besoin obligatoirement des résistances car ils sont très sensible au courant

électrique.

On va utiliser une résistance pour chaque LED et une résistance pour les capteurs de

température.

2.7.6. Module Bluetooth :

On a choisi un Bluetooth de type HC-06

2.7.7. Capteurs :

On a choisi deux capteurs de température, un capteur de CO2 et un capteur de

mouvement. En effet, la duplication des capteurs présente un intérêt marquant particulièrement

pour rassurer de la précision des grandeurs physiques considérées ainsi que pour la tolérance aux

pannes.

Remarque : D’autres capteurs peuvent être rajoutés et ce selon le type d’application.


61

2.8. Motivation du choix de la carte Arduino UNO :

Les motivations qui nous ont incités à choisir Arduino Uno sont :

Le prix (réduits) : les cartes Arduino sont relativement peu coûteuses comparativement aux

autres plates-formes. C’est la moins chère des versions du module Arduino qui peut être

assemblée à la main.

Multi plateforme : le logiciel Arduino, écrit en C, tourne sous les systèmes d'exploitation

Windows, Macintosh et Linux. Sachant que la plupart des systèmes à microcontrôleurs sont

limités à Windows.

Logiciel Open Source et extensible : Le logiciel Arduino et le langage C (pour la

programmation de la carte) sont publiés sous licence open source.

Disponibilité : les cartes Arduino sont disponibles dans le marché par rapport aux autres

microcontrôleurs.

2.9. Description détaillée de la carte ARDUINO UNO :

Le module Arduino est un circuit imprimé en matériel libre (plateforme de contrôle) dont les

plans de la carte elle-même sont publiés en licence libre dont certains composants de la carte :

comme le microcontrôleur et les composants complémentaires qui ne sont pas en licence libre. Un

microcontrôleur programmé peut analyser et produire des signaux électriques de manière à

effectuer des tâches très diverses [80].

Arduino est utilisé dans beaucoup d'applications comme l'électrotechnique industrielle et

embarquée ; le modélisme, la domotique mais aussi dans des domaines différents comme l'art

contemporain et le pilotage d'un robot, commande des moteurs et faire des jeux de lumières,

communiquer avec l'ordinateur, commander des appareils mobiles (modélisme). Chaque module

d’Arduino possède un régulateur de tension +5 V et un oscillateur à quartez 16 MHz (ou un

résonateur céramique dans certains modèles). Pour programmer cette carte, on utilise l’logiciel IDE

Arduino [80].

Les caractéristiques techniques de cette carte sont déjà données dans le chapitre d’IoT.


62

Figure 17: description détaillé de la carte ARDUINO UNO[79]


63

2.9.1. Les sources de l'alimentation de la carte :

On peut distinguer deux genres de sources d’alimentation (Entrée / Sortie) et cela comme suit

[83] :

VIN : La tension d'entrée positive lorsque la carte Arduino est utilisée avec une source de

tension externe (à distinguer du 5V de la connexion USB ou autre source 5V régulée).

5V : La tension régulée utilisée pour faire fonctionner le microcontrôleur et les autres

composants de la carte. Le 5V régulé fourni par cette broche peut donc provenir soit de la

tension d'alimentation VIN via le régulateur de la carte, ou bien de la connexion USB (qui

fournit du 5V régulé) ou de tout autre source d'alimentation régulée.

3V3 : Une alimentation de 3.3V fournie par le circuit intégré FTDI (circuit intégré faisant

l'adaptation du signal entre le port USB de votre ordinateur et le port série de l'ATmega) de la

carte est disponible : ceci est intéressant pour certains circuits externes nécessitant cette tension

au lieu du 5V. L'intensité maximale disponible sur cette broche est de 50mA.

2.9.2. Entrées et sorties numériques [82]

Chacune des 14 broches numériques de la carte UNO (numérotées des 0 à 13) peut être

utilisée soit comme une entrée numérique, soit comme une sortie numérique. Ces broches

fonctionnent en 5V. Chaque broche peut fournir ou recevoir un maximum de 40mA d’intensité et

dispose d’une résistance interne de 20-50 KOhms.

De plus, certaines broches ont des fonctions spécialisées :

Communication Série : Broches 0 (RX) et 1 (TX). Utilisées pour recevoir (RX) et transmettre

(TX) les données séries de niveau TTL (Transistor Transistor Logic) est une famille de circuits

logiques utilisée en électronique, Cette famille est réalisée avec la technologie du transistor bipolaire

et tend à disparaître du fait de sa consommation énergétique élevée).

Interruptions Externes : Broches 2 et 3. Ces broches peuvent être configurées pour déclencher

une interruption sur une valeur basse, sur un front montant ou descendant, ou sur un changement

de valeur.

SPI (Interface Série Périphérique) : Broches 10 (SS), 11 (MOSI), 12 (MISO), 13 (SCK). Ces

broches supportent la communication SPI (Interface Série Périphérique) disponible avec la librairie

pour communication SPI. Les broches SPI sont également connectées sur le connecteur ICSP qui

est mécaniquement compatible avec les cartes Mega.

I2C : Broches 4 (SDA) et 5 (SCL). Supportent les communications de protocole I2C (ou interface

TWI (Two Wire Interface - Interface "2 fils"), disponible en utilisant la librairie Wire/I2C (ou TWI

- Two-Wire interface - interface "2 fils").

LED : Broche 13. Il y a une LED incluse dans la carte connectée à la broche 13. Lorsque la

broche est au niveau HAUT, la LED est allumée, lorsque la broche est au niveau BAS, la LED est

éteinte


64

2.9.3. Les ports de communications

La carte Arduino UNO a de nombreuses possibilités de communications avec l’extérieur.

L’Atmega328 possède une communication série UART TTL (5V), grâce aux broches numériques

0 (RX) et 1 (TX).

On utilise (RX) pour recevoir et (TX) transmettre (les données séries de niveau TTL).

Ces broches sont connectées aux broches correspondantes du circuit intégré ATmega328

programmé en convertisseur USB – vers – série de la carte, composant qui assure l'interface entre

les niveaux TTL et le port USB de l'ordinateur.

2.9.4. Programmation

La carte Arduino Uno peut être programmée avec le logiciel Arduino. Il suffit de

sélectionner "Arduino Uno" dans le menu Tools > Board (en fonction du microcontrôleur présent

sur la carte) [81].

Le microcontrôleur ATmega328 présent sur la carte Arduino Uno est livré avec un

bootloader (petit programme de démarrage) préprogrammé qui permet de transférer le nouveau

programme dans le microcontrôleur sans avoir à utiliser un matériel de programmation externe. Ce

bootloader communique avec le microcontrôleur en utilisant le Protocole Original STK500.

Figure 18: L’interface de l’Arduino.

Après avoir présenté les besoins en hardware nécessaires à la réalisation de l’application

IoT, passant maintenant aux besoins softwares. La question qui se pose maintenant est

comment ce système devra être afin d’aboutir au but visé ?


65

Les besoins conceptuel de cette application sont capturés par les diagrammes de cas

d’utilisation et les diagrammes de séquences donnés ci-après.

2.10. Diagramme de cas d’utilisation

L’identification des cas d’utilisations, nous donne un aperçu sur les fonctionnalités futures

que doit implémenter le système. Un seul acteur est recensé responsable pour veiller à la

surveillance et la gestion de la salle, c’est l’acteur principal du système. Ainsi, le Smartphone est

considéré comme étant un acteur. Il assure la communication des données entre l’objet et le

serveur.

Figure 19: diagramme de cas d’utilisation

2.11. Diagramme de séquences :

Nous présentons ci-dessous l’ensemble des diagrammes de séquence du système.


66

Figure 20: diagramme de séquence capteur température

Figure 21: Diagramme de séquence capteur CO2

Le diagramme de séquence global est décrit par la figure ci-dessous :


67

Figure 22: Diagramme de séquence du système d’IOT

3. Conception de l’application mobile

On se basant sur l’étude établie dans l’analyse des besoins, nous proposons une architecture

pour la mise en œuvre de l’objet connecté. Il est à noter que plusieurs alternatives peuvent être

envisagées et ce selon les besoins du domaine d’application (par exemple les contraintes

environnementales), le matériel utilisé et les choix conceptuels.

3.1. Architecture du système à réaliser

3.1.1. Architecture matérielle

Figure 23: Architecture matérielle du système


68

L’architecture matérielle est décrite par les éléments suivants :

Capteur de température

Le LM35 de National Semi-conducteurs : on le trouve facilement dans le commerce, sa

mise en œuvre s'avère des plus simples.

Figure 24: capteur de température LM35

Capteur de CO2 MQ-7 :

- Capteur simple à utiliser.

- Peut détecter partout des concentrations de monoxyde de carbone (CO2) de 20 à 2 000

ppm.

- Circuit d'entrainement très simple.

- Alimentation électrique : 5 V.

Figure 25: capteur de Monoxyde de carbone CO2

Détecteur de distance

Le capteur HC-SR04 utilise les ultrasons pour déterminer la distance d'un objet. Il offre

une excellente plage de détection sans contact, avec des mesures de haute précision et stables. Son

fonctionnement n'est pas influencé par la lumière du soleil ou des matériaux sombres, bien que des

matériaux comme les vêtements puissent être difficiles à détecter.


69

Figure 26: détecteur de distance HC-SR04

Une carte arduino UNO

Module de communication Bluetooth

Le module Bluetooth HC-06 est un accessoire indispensable si l’on souhaite communiquer

sans fil (avec par exemple un Smartphone en Bluetooth) avec une carte Arduino. Par défaut,

l’identifiant du module Bluetooth est "HC-06" et le code pin "1234".

Figure 27: le module Bluetooth HC-06

Pour assurer la communication entre l’objet connecté et l’application serveur, nous avons

choisi d’utiliser un smartphone comme un middleware. D’autres technologies peuvent être

également utilisées tel qu’une carte Raspberry, mais cela coûte un peu plus cher.

Les données prennent le chemin indiqué par la figure 15.

http://matechnologie.com/spip.php?article416


70

Figure 28: Flow de données de l’application mobile.

3.1.2. Architecture logiciel

À chaque fois que le Smartphone reçoit des données via le Bluetooth, il les envoie vers

l’application serveur afin d’être stockées, traitées et réutilisées.

Pour cela, nous allons utiliser une connexion de type Bluetooth pour lier le serveur et le

smartphone ainsi que pour connecter l’application mobile et l’objet connecté.

L’architecture logicielle proposée est donnée par la figure 28 .


71

Figure 29: Architecture logicielle du système d’IoT

Description de l’architecture logicielle :

Couche physique : comporte l’ensemble du matériel utilisé dans le système, dans cette

couche nous avons les traitements suivants :

Collection des données à partir de l’environnement.

Les capteurs transforment les grandeurs physiques à des grandeurs logiques ;

ensuite le microcontrôleur transforme les signaux à une chaîne binaire.

Le module Bluetooth transfert les données codées sous forme socket Bluetooth

vers la deuxième couche.

Couche applicative : comporte la gestion et le traitement des données. On distingue

principalement deux couches (applications): une application mobile et une application

serveur. La couche serveur sert à effectuer des traitements sur les données reçues à partir

de la couche mobile, elle s’occupe également du stockage et d’affichage des données.

L’application mobile est un middleware, à base de Bluetooth, qui assure la transmission des

données de la couche physique vers la couche serveur.

Les module de communication : notre application est repartie sur deux partie ce qui

nécessite l’existence des modules de communication, la technologie Bluetooth utiliser pour

transfert les données vers la première partie de l’application (application mobile)

Pour la communication entre les deux applications on utilise toujours la

technologie Bluetooth.

3.1.3. Les diagrammes d’activité :


72

Figure 30: diagramme d'activité globale

Figure 31: diagramme d’activité envoyer les données au serveur


73

3.1.4. Diagramme de class :

Figure 32: diagramme de class de l’application IoT

4. Réalisation

4.1. Branchement des capteurs :

Branchement des capteurs de température et Bluetooth

Pour établir le branchement du capteur de température, nous suivons le schéma de

connexion décrit par la figure ci-dessous :

Figure 33: Branchement du capteur de température.


74

Branchement des capteurs de CO2 et distance

Figure 34: Branchement du capteur de CO2

branchement détecteur de distance :

Figure 35: Branchement du capteur de distance.

4.2. L’objet connecté


75

Figure 36: notre l’objet connecté.

Après avoir réalisé la partie hardware du système, nous passons à la programmation de

l’objet ainsi qu’au middleware assurant la communication entre l’objet connecté et le serveur.

4.3. Langages et outils utilisés :

4.3.1. Arduino : la description d’Arduino a été déjà évoquée lors de la présentation d’Arduino

Uno.

Figure 37:l’interface principale d’Arduino UNO.

4.3.2. Android :

Android Studio est l'environnement de développement intégré officiel (IDE) pour la

plate-forme Android.

Basé sur le logiciel IntelliJ IDEA de JetBrains, Android Studio est conçu spécialement

pour le développement d'Android. Il est disponible en téléchargement sur Windows, MacOs et

Linux, et a remplacé Eclipse Android Développement Tools (ADT) en tant que premier IDE de

Google pour le développement d'applications Android natives.

Android Studio possède un périphérique virtuel Android (AVD) fourni avec des

émulateurs pour les périphériques Nexus 6 et Nexus 9. Il offre également des variantes de

construction et la capacité de générer plusieurs fichiers apk.


76

Figure 38: Environnement de programmation Android

3.1.5. Autres outils :

On va utilisera WampServer pour stoker les données dans le serveur sur (PC).

WampServer :

WampServer est une plate-forme de développement Web sous Windows pour des

applications Web dynamiques à l’aide du serveur Apache2, du langage de scripts PHP et d’une

base de données MySQL. Il possède également PHPMyAdmin pour gérer plus facilement vos

bases de données

4.4. Description de l’application

4.4.1. Les codes Arduino pour les déférant capteurs

Code Arduino pour le capteur de température


77

Code Arduino pour le capteur de co2

Code Arduino pour le détecteur de distance :


78

Code Arduino du Bluetooth

5. Quelques interfaces

Fenêtre principale sur smartphone


79

Figure 39:l'interface principale de middleware

Figure 40: interface principale de l'application mobile

Téléverser le code : l’affichage de télévesement du code Arduino.

Figure 41: le code de télévesement Arduino

Affichage des données sur la console Arduino :


80

Figure 42:l’affichage sur la console de l'arduino

Affichage des données sur le smartphone :

Figure 43: affichage des données reçus par Bluetooth sur le smartphone

Affichage de données sur le PC (dans une base de données) : les données recus par

l’application serveur afficher et stocker dans une base de données


81

Figure 44: les données reçus sur le pc

6. Conclusion

Dans ce chapitre on a présenté la conception et la réalisation d’un objet connecté ainsi

que du middleware assurant la transmission des données vers d’autres serveurs distants. La

technique de communication utilisée est sans fil par le biais du capteur Bluetooth.

L’application réalisée peut être intégrée avec d’autres applications serveurs afin de faire des

études et traitements sur les données collectées depuis l’objet connecté. Dans notre cadre de travail,

cette application sera intégrée avec un système diagnostiqueur qui fera l’objet du prochain chapitre

Chapitre 5 : conception et

réalisation d’une

Application multi-agents

pour le diagnostic d’un

système d’IoT

Chapitre 5

Conception et Réalisation

d’une Application Multi-Agents

pour le Diagnostic

d’un système d’IoT

1. Introduction

e chapitre est principalement consacré à la conception et la réalisation de

l’application serveur ; c’est une application basée agents pour le diagnostic d’un

système d’IoT. L’exemple d’IoT que nous avant choisi est bien évidement le

système de surveillance d’une salle, conçu dans le chapitre précédent.

L’application serveur est donc un système multi-agents composé de plusieurs types

d’agents dont l’objectif global est de faire l’analyse et la détection des défaillances du système

d’IoT. En premier lieu, nous présentons la conception de l’application serveur, par la suite, nous

étalons l’intégration de l’application mobile avec l’application serveur ce qui donne lieu au système

global : le système à base d’agents pour le diagnostic d’un système d’IoT.

2. Objectif de l’application

L'objectif global de notre application est l’utilisation du paradigme des systèmes

multi- agents pour le diagnostic d’un system d’IoT c.-à-d. : récupérer des informations depuis

l’objet connecté, ces données sont à traiter par le système multi-agent afin de réaliser le

diagnostic d’un tel système, cet objectif peut être décomposé en plusieurs sous tâches :

Récupération des données de l’objet connecté.

Analyse et diagnostic locale des données récupérées.

Détection des anomalies du système et élaboration d’un diagnostic global.

Affichage des résultats du diagnostic.

Une étape supplémentaire peut être rajoutée, il s’agit du pronostic. Autrement dit,

des conseils et des actions correctives peuvent être mise en place. Dans ce travail,

nous nous n’intéressons pas à la réalisation de cette tâche.

C

Conception et réalisation d’une application multi-agents pour le diagnostic d’un système d’IoT

82

3. Description générale de la solution à proposer

Il s`agit de concevoir un système multi-agents qui a pour but de diagnostiquer un système

d’IoT. Ce système multi-agents est composé de plusieurs agents chacun a un comportement bien

déterminé. Deux types d’agents sont distingués dans ce système : des agents réactifs et un agent

délibératif (unique). Les agents réactifs ; un agent par type de capteur ; perçoivent l’environnement,

collectent les données issues de l’objet connecté et élaborent chacun un diagnostic local. Le résultat

du diagnostic local est envoyé, par la suite, à l’agent délibératif. Cet agent est un coordinateur, il

possède une vue globale du SMA. Son rôle est d’élaborer un diagnostic global du système et ce en

se basant sur les diagnostics locaux reçus. Le lancement du système et l’affichage des résultats est

assuré par un Agent d’interface. La figure 45 représente une vision générale de la solution proposée.

Elle représente également l’organisation du système multi-agents.

Figure 45: Schéma global de l’application multi-agents.

Afin de concevoir cette application, plusieurs approches multi-agents peuvent être utilisées.

Nous adoptons une démarche génie logiciel, basée principalement sur la décomposition de

l’approche Voyelle (A : Agent, E : Environnement, O : Organisation, I : Interaction et U :

Utilisateur). [90].

4. Analyse des besoins

Cette phase consiste à identifier les agents du système multi-agents, l’environnement,

l’organisation et les interactions entre agents.

4.1. Identification des agents : le système est composé de :

Agent Interface : son rôle peut être résumé comme suit :

Responsable du lancement des autres Agents.

L’affichage des résultats.


83

Gère l’interface principale du système.

Agent coordinateur : son rôle peut être résumé comme suit :

Responsable du diagnostic global du système.

Agent capteur (Plusieurs) : son rôle peut être résumé comme suit :

Recevoir les valeurs des grandeurs physiques (température, co2, humidité,

mouvement,….) et ce de manière périodique.

Faire le diagnostic et l’analyse locale des données reçues.

A la détection d’une anomalie, envoyer les données à l’agent coordinateur pour

faire le diagnostic global.

Envoyer un message à l’agent interface pour afficher les résultats.

La voyelle U, modélisant l’utilisateur du système interagit directement avec l’agent

d’interface.

4.2. Fonctionnement du système

Le fonctionnement global du système est décrit par le diagramme de cas d’utilisation

ci-dessous (Voir Figure 46) :

Figure 46: Diagramme de cas d’utilisation du système.

Il est à noter qu’une factorisation des cas d’utilisations des deux applications (application

mobile et application serveur) est résumée par les cas d’utilisation : assurer la sécurité et contrôler la

qualité d’air. Ce qui garantit une cohérence lors de leur intégration, une fois la conception de

l’application serveur s’achève. Le cas d’utilisation diagnostic est spécifique à l’application serveur.

Fonctionnement de l’agent capteur : Le fonctionnement de l’agent capteur est représenté par

la figure 47 et peut être décrit ainsi comme suit :


84

Collecter les grandeurs physiques issues des différents capteurs ayant le même type.

Effectué un diagnostic local.

Communiquer le résultat avec l’agent coordinateur.

Figure 47: Fonctionnement de l’agent capteur (exemple Agent CO2).

Fonctionnement de l’agent coordinateur : Le fonctionnement de l’agent coordinateur est

représenté par la figure 48 et peut être décrit ainsi comme suit :

Recevoir les résultats des diagnostics locaux auprès des agents capteurs.

Elaborer un diagnostic global.

Communiquer le résultat du diagnostic global avec l’agent d’interface.

Figure 48: Fonctionnement de l’agent coordinateur


85

Fonctionnement de l’agent d’interface : Le fonctionnement de l’agent d’interface est

représenté par la figure 49 et peut être décrit ainsi comme suit :

Lancer le système multi-Agent.

Afficher les résultats des diagnostics locaux ainsi que du diagnostic global.

Figure 49: Fonctionnement de l’agent d’interface.

4.3. Identification des interactions

Cette phase consiste à identifier les interactions et les messages échangés entre les

agents du système.

Les interactions des agents capteurs (température, co2, mouvement) :

Pas de communication entre les agents capteurs.

Les agents capteurs reçoivent les valeurs des grandeurs physiques depuis le middleware.

Chacun des agents capteurs, après élaboration du diagnostic local informe le résultat à

l’agent coordinateur.

Les interactions de l’agent CO2 sont décrites par le diagramme AUML de le figure 50 .

Figure 50: Diagramme AUML de l’Agent CO2.


86

Les diagrammes des autres agents capteurs utilisent le même type de la séquence des

messages, illustrée par la figure de l’agent CO2 (figure 50) ; la seule différence réside dans le type

de données échangées.

Les interactions de l’agent coordinateur

Après la réception des résultats des diagnostics locaux des agents capteurs (température,

CO2 et distance), l’agent coordinateur élabore le diagnostic global.

Par la suite, il envoie les résultats du diagnostic global à l’agent d’interface pour affichage.

Figure 51: Diagramme AUML de l’agent coordinateur.

Les interactions de l’gent Interface :

L’agent interface lance les agents du système (les agents capteurs et l’agent coordinateur).

Il affiche également les résultats du diagnostic.

Figure 52: Diagramme AUML de l’agent d’interface


87

Format des messages échangés : Cette section présente le format des messages

échangés entre les agents du SMA. Le langage de communication utilisé dans ce système est le

FIPA-ACL. Pour l’ontologie, nous supposons l’utilisation d’une ontologie prédéfinie, appelée IoT.

Message entre l’agent capteur (CO2) et l’agent coordinateur :

Message entre l’agent coordinateur et l’agent d’interface :

Diagramme d’AUML globale

Ce diagramme représente les interactions entre les différentes entités du système multi agents.

Au départ, les agents capteurs reçoivent les données des capteurs à partir du middleware via

Bluetooth. Ensuite, les agents capteurs élaborent chacun un diagnostic local des données reçus. Par

la suite, ils envoient les résultats à l’agent coordinateur. A partir de ces résultats, l’agent

coordinateur, établit un diagnostic global du système.

Le résultat du diagnostic global de l’agent coordinateur est envoyé à l’agent d’interface pour

affichage.

(Inform

: Sender< Agent CO2>

: Receiver <Agent Coordinator>

: Content <résultat- diagnostic-local>

: Language < prolog>

: Ontology <IoT>

)

(Inform

: Sender < Agent coordinator>

: Receiver <Agent interface>

: Content <résultat-diagnostic-global>

: Language < prolog>

: Ontology <IoT>

)


88

Figure 53: Diagramme d’AUML du l’application serveur.

4.4. Identification de l’environnement

C'est l'environnement physique supportant les actions des agents et disposant des

ressources, il est constitué de :

L’objet connecté (la carte Arduino et l’ensemble des capteurs et composants

d’interconnexion).

Smartphone qui joue le rôle d’un middleware.

4.5. Identification de l’organisation

Le schéma organisationnel décrivant l’application serveur est déjà présenté par la figure

(la 1ière figure 45, voir page 83). Elle représente les relations qui existent entre les agents de

l’application. C’est une structure organisationnelle hiérarchique dont l’agent coordinateur joue

le rôle d’un centralisateur du mécanise de diagnostic. Ils tentent à fusionner les diagnostics

locaux issus des agents capteurs.

5. Conception de l’application serveur

Cette partie représente l’architecture de l’application multi agents, en suivant la structure

organisationnelle décrite précédemment et modélisant les besoins fonctionnels identifiés lors

de la phase d’analyse des besoins.

5.1. Architecture Interne des agents de l’application

5.1.1. Architecture interne de l’agent capteur : un agent capteur est modélisé par les modules

suivants (voir la Figure 54) :

Module de perception : l’agent capteur est un agent réactif possédant un module de

perception lui permettant de percevoir son environnement, entre autres les valeurs des

grandeurs physiques issues des capteurs.

Module de diagnostic local : constitue le module de raisonnement de l’agent. Il est

constitué en deux sous modules : module de détection et module de localisation, appelé

aussi module d’analyse. La détection consiste à détecter toute incohérence au niveau de la

base de connaissances en analysant les données reçues des capteurs. Autrement dit, tester


89

la contradiction entre les observations et les prédictions du comportement attendu décrites

par les règles d’inférences. Dans le cas d’une inconsistance détectée, le module d’analyse

cherche à localiser le composant défaillant. Ce module et mise en œuvre par le résolveur

Prolog. Un exemple de base de règle pour l’agent capteur de température est décrit par la

figure 55.

Module Action : il exécute les actions de l’agent capteur, entre autres l’envoi des résultats

du diagnostic local à l’agent coordinateur.

Figure 54: Architecture interne de l’agent capteur.

Figure 55: Base de règles de l’agent température.

Exemple de requêtes pour l’agent capteur de température :

Requête de Détection : hort_interval_temperature(T, Min, Max).

bonne_interval(MinI, MaxI, Y) :- MinI=<Y, Y=<MaxI.

bonne_valeur(Min, Max, X) :- Min =< X, X =< Max.

bonne_temperature(MinI, MaxI, T, Min, Max) :-

bonne_interval(MinI, MaxI, T),

bonne_valeur(Min, Max, T),

write('les valeurs sont normal').

%vérifié si les 2 valeurs sont différant

dif(X, Y) :- when(?=(X, Y), X \== Y).

fd_domain(Y ,0 ,150).

fd_domain(Z ,0 ,150 ).

ecart(X, Y, Z) :- X is Y - Z.


90

Requête de localisation : etat_innormal(T, Min, Max):- hort_interval_capteur(T);

hort_interval_temperature(T, Min, Max).

5.1.2. Architecture interne de l’agent coordinateur

Un agent coordinateur est modélisé par les modules suivants (voir la Figure 56) :

Module d’interaction : ce module assure la communication entre l’agent coordinateur et les

autres agents, il est responsable ainsi de la collecte des données (perception).

Module de diagnostic : c’est le module principal de cet agent (module de raisonnement). Le

raisonnement de l’agent coordinateur est plus élaboré que le raisonnement de l’agent capteur,

en termes des cas à prendre en considération et en termes d’interférence entre les valeurs des

différents types de capteurs. En effet, les deux agents utilisent le même principe de diagnostic.

Cependant l’agent coordinateur essaye en quelque sorte de fusionner les résultats des

diagnostics locaux par élaboration de règles d’inférences.

Figure 56: Architecture interne de l’agent coordinateur

Exemple de requêtes pour l’agent coordinateur :

Requête de Détection :

etat_innormal_Systeme(T, MinT, MaxT, C, MinC, MaxC, D):-

etat_innormal_temperature(T, MinT, MaxT);

etat_innormal_co2(C, MinC, MaxC);

etat_innormal_co2(C, MinC, MaxC), etat_innormal_temperature(T, MinT, MaxT).

5.2. Diagramme de classe : La vue statique du système multi agents est décrite par le

diagramme de classe ci-dessous (Figure 57) :

5.2.1. Description des classes : L’ensemble des classes de l’application sont les suivants :

La classe agent capteur : stéréotypé par <Agent>, modélise l’agent capteur utilisant

et communiquant avec l’objet connecté. C’est une classe abstraite dont plusieurs agents

capteurs peuvent hériter de cette classe ; nous avons utilisé les agents suivants:

L’agent température : responsable des capteurs de température.

L’agent CO2 : responsable des capteurs de CO2.


91

L’agent mouvement : responsable des capteurs de mouvement.

D’autres agents capteurs peuvent être rajoutés facilement.

La classe agent coordinateur : stéréotypé <Agent> ; modélise l’agent coordinateur.

Responsable d’assurer le diagnostic global du système et de maintenir sa cohérence

globale.

La classe agent d’interface : stéréotypé <Agent> ; modélise l’agent d’interface.

La classe Middleware : c’est classe ordinaire (n’est pas stéréotypé <Agent>),

représentant le Middleware réalisé dans le chapitre précédent.

Figure 57: Diagramme de classes de l’application serveur.

5.3. Diagramme d’activité

La vue dynamique du système est modélisée par le diagramme de séquences décrit

précédemment ainsi que la donnée du diagramme d’activités représenté par la figure58. Nous

avons utilisé une représentation avec couloir d’activités afin de modéliser le comportement

global du système en termes de traitements effectués.


92

Figure 58: Diagramme d’activité de l’application serveur.

6. Réalisation de l’application serveur

6.1. Outils utilisés

Cette phase consiste à mettre en œuvre l’application serveur. Pour ce faire, nous allons

utiliser les outils suivants :

La plateforme JADE : Est une plate-forme multi-agent développée en Java par CSELT

(Groupe de recherche de Gruppo Telecom, Italie) qui a comme but la construction des systèmes

multi-agent et la réalisation d'applications conformes à la norme FIPA [70]. JADE comprend deux

composantes de base : une plate-forme agents compatible FIPA et un paquet logiciel pour le

développement des agents Java [ref].

Un système basé sur JADE peut être distribué à travers les machines (qui n'ont même

pas besoin de partager le même système d'exploitation) et la configuration peut être contrôlée via

une interface graphique distante. La configuration peut être modifiée même au moment de

l'exécution en amenant des agents d'une machine à l'autre, au besoin [68].


93

Figure 59: Interface principale de la plateforme jade

Prolog : Prolog est un langage de programmation logique à usage général associé à

l'intelligence artificielle et à la linguistique computationnelle. Prolog, à ses racines dans

la logique de premier ordre, une logique formelle, et contrairement à beaucoup d'autres

langages de programmation, Prolog est déclaratif : la logique du programme s'exprime

en termes de relations, représentées comme des faits et des règles. Un calcul est lancé

en exécutant une requête sur ces relations [94].

La langue a d'abord été conçue par un groupe autour d'Alain Colmerauer à Marseille,

en France, au début des années 1970 et le premier système Prolog a été développé en

1972 par Colmerauer avec Philippe Roussel [95].

Figure 60: Interface d’exécution de SwiProlog

JPL : est une bibliothèque utilisant l'interface étrangère SWI-Prolog et l'interface Java

fournissant une interface bidirectionnelle entre Java et Prolog qui peut être utilisée pour

intégrer Prolog en Java ainsi que pour intégrer Java dans Prolog. Dans les deux

configurations, il fournit une interface bidirectionnelle réentrante [91]


94

Bluecove : est une bibliothèque Java pour Bluetooth (implémentation JSR-82) qui

interagit actuellement avec la pile Bluetooth Mac OS X, WIDCOMM, BlueSoleil et

Microsoft trouvée dans Windows XP SP2 ou Windows Vista et WIDCOMM et

Microsoft Bluetooth stack sur Windows Mobile [92]

MySQL connexion : Est un Driver pour se connecter à un serveur de base de données

MySQL via l'interface de programme d'application Open Database Connectivity

(ODBC), qui est le moyen standard de se connecter à n'importe quelle base de données.

Les utilisateurs peuvent se connecter à partir d'applications et d'environnements de

programmation courants, tels que Microsoft Access ou Excel ou Borland Delphi [93].

6.2. Description de l’interface principale de l’application

L’interface principale de l’application c’est interface gérée par l’agent d’interface.

Elle dispose : d’un bouton pour l’activation de Bluetooth et la réception des données, d’un

bouton pour la consultation des données reçues et d’un bouton pour activer les autres

agents qui vont lancer le mécanisme du diagnostic.

Figure 61: Interface principale de l'application serveur

Les autres interfaces sont présentées par la suite.

7. Intégration des applications mobile et Serveur

Malgré que l’application mobile et l’application multi-agent soient développées dans

deux plateformes différentes, l’intégration de ces applications ne posera aucun problème lors

de l’intégration. En effet, les deux applications communiquent entre elle via un Middleware en

suivant la technologie Bluetooth.


95

7.1. Diagramme de package

L’intégration est décrite par de diagramme de package de la figure 62.

Nous structurons l’intégration en trois packages :

Package application objet connecté

Package application serveur (application multi-agents)

Et package application mobile (Middleware)

Le dernier package est utilisé par les autres (relation d’importation). Le package

application mobile dépend du package application objet connecté.

Figure 62: Diagramme de package de l’intégration des applications mobile et serveur.

7.2. Diagramme de déploiement

L’architecture matérielle de l’application entière est donnée par le diagramme de

déploiement (Figure 63).


96

Figure 63: Diagramme de déploiement de l’application

8. Description des interfaces et résultats de l’application multi agents pour le diagnostic

d’un système d’IoT.

Lancement de l’objet connecté

Figure 64: Lancement de l'objet connecté

Lancement de l’application mobile

Lancement de l’application multi-Agent


97

Figure 65: Lancement de l'application SMA

Le comportement des agents capteur est de type TickerBehavieur (), car ces agents reçoivent

de manière périodique les données transmises par l’objet connecté à partir de middleware.

Le comportement de l’agent coordinateur est aussi de type tickerBehavieur () mais avec

un tic supérieur à celle des agents capteurs.

A titre d’exemple, la classe java de l’agent température est donnée par la figure 66.

Figure 66: Class java de l'agent température


98

Figure 67: Snifer (les interactions entre les agents de système)

Interface d’affichage des données reçues :

Figure 68: Interface d'affichage des données reçu.

Interface pour entrer les valeurs désirées par l’utilisateur :


99

Figure 69: interface pour remplir les propriétés de la salle

Interface d’affichage du résultat de diagnostic :

Figure 70: interface d'affichage des résultats


100

Figure 71: le cas d'une anomalie

9. Conclusion

Dans cette partie nous avons modélisé notre système, le but le plus important était

d'introduire la notion des systèmes multi-agent dans la pratique de l’IoT afin d'automatiser le

diagnostic du système

Conclusion Générale

Conclusion générale

102


Ce travail nous a permis de faire un état de l’art sur différents domaines de recherches,

à savoir l’IoT, le diagnostic et les systèmes multi-agents. En outre, la mise en œuvre d’une

application à base d’agents pour le diagnostic d’un système d’IoT nous a permis d’apprendre et

d’exploiter plusieurs plateformes, outils et langages de développement, entre autres les plateformes

Arduino et JADE, Java et Android.

La particularité de ce projet est la réalisation physique d’un système d’IoT qui présente la

première expérience au sein de notre département. Plusieurs concepts sont acquis, qui concernent

non seulement la partie software mais aussi la partie hardware dont on a réalisé un système d’IoT

pour la surveillance de la qualité d’air. Pour ce système, notre préoccupation majeure était la mise

en œuvre d’un mécanisme de diagnostic pour de tels systèmes.

La modélisation de ce système a été faite par le paradigme des systèmes multi agents. La

raison qui nous a incités à choisir ce paradigme est les propriétés et caractéristiques des systèmes

multi agents qui collent bien avec les besoins conceptuels pour le système à réaliser.

La solution proposée dans ce manuscrit comporte trois packages :

Un package pour la partie programmation du microcontrôleur

Un package pour l’application coté serveur (application multi-agent)

Un package Middleware (application mobile sous Android utilisant la technologie

Bluetooth).

En réalisant ses packages et l’intégrant ensemble, nous pouvons dire que l’objectif de notre

projet de Master a été bien achevé. Néanmoins, nous pouvons poursuivre ce travail en adoptant

d’autres perspectives telles que : la sécurité, le Big Data , le cloud computing et l’utilisation

d’autres dispositifs à fin de rendre l’objet plus fiable et plus indépendant , tels que :

Un module WIFI SHIELD au lieu du Bluetooth, pour un échange plus rapide de

données et ce depuis le capteur directement au serveur sans passer par le Smartphone.


103

Un module GPS pour la localisation des objets.

Bibliographie

Bibliographie :

[1] Yacine Challal. Sécurité de l’Internet des Objets : vers une approche cognitive et

systémique. Réseaux et télécommunications [cs.NI]. Université de Technologie de Compiégne,

2012.

[2] Giancarlo Fortino, Wilma Russo, and Claudio Savaglio, Simulation of Agent-oriented

Internet of Things Systems, DIMES - Department of Informatics, Modeling, Electronics and

Systems University of Calabria Via P. Bucci, cubo 41C, 87036 Rende (CS), Italy {g.fortino,

w.russo}@unical.it, [email protected].

[3] Teemu LEPPÄNEN and Jukka RIEKKI, A lightweight agent-based architecture

for the Internet of Things, Department of Computer Science and Engineering, University of Oulu,

Finland E-mail: {teemu.leppanen, jukka.riekki}@ee.oulu.fi.

[4] Karen Rose, Scott Eldridge, Lyman Chapin, The Internet of Things: An Overview

Understanding the Issues and Challenges of a More Connected World, October 2015.

[5] Yves-Marie, les différents usages des objets connectés.[en ligne].

http://www.objetconnecte.net/les-usages-des-objets-connectes/.[Page consultée le 13/05/2016]

[6] Internet of Things: Converging Technologies for Smart Environments and Integrated

Ecosystems, Consulting Series EditorsDr. Ovidiu Vermesan SINTEF, Norway Dr. Peter Friess

EU, Belgium. MARINA RUGGIERI, University of Roma “Tor Vergata”, Italy, HOMAYOUN

NIKOOKAR,Delft University of Technology The Netherlands.

[7] Anne Louise. Le développement des objets connectés : les chiffres.[en ligne].

http://www.objetconnecte.net/developpement-objets-connectes-les-chiffres/. [Page consultée le 13/04/2017]

[8] Vala Afshar. Internet of things. [en ligne]. http://fr.slideshare.net/ValaAfshar/internet-of-

thingsslideshare. [Page consultée le 05/05/2017]

[9] Paul laubacher. Les 13 objets connectés qui vont bouleverser votre vie.[en

ligne].http://o.nouvelobs.com/high-tech/20121220.OBS3279/dossier-les-13-objets-connectes-qui-vont-

bouleverser-votre-vie.html. [Page consultée le 13/04/2017]

[10]

S.BOUTELDJA,S.BENCHIKH LHOUSSINE.Spécification et Réalisation d’un objet

connecté dans le Domaine de la vérification de la qualité d’un paramètre Environnemental (Taux

de CO2 dans l’air). memoire master derigé par : Dr KITOUNI Ilham. Dr GUELLATI Souad.

Promotion 2016.

[11] Challenges in the Internet of Things IoT Readiness,

http://www.ti.com/ww/en/internet_of_things/iot-challenges.html.

mailto:jukka.riekki%[email protected]

http://www.ti.com/ww/en/internet_of_things/iot-challenges.html

105

[12] Proceedings of the Third International Workshop on INFRASTRUCTURES AND

TOOLS FOR MULTIAGENT SYSTEMS ITMAS 2012 June 5, 2012 Valencia, Spain.

[13] Dave Evans, L’Internet des objets Comment l’évolution actuelle d’Internet

transforme-t-elle le monde ?, Avril 2011.

[14] Mehdi Nemri, ‘Demain, l'Internet des objets’, département Développement

durable, http://www.strategie.gouv.fr/publications/demain-linternet-objets. Consulter le

12.04.2017.

[15] Jean-Paul Mesters et Patrick Collignon. Monter son réseau Wi-Fi ou Ethernet

© Groupe Eyrolles, 2004 ISBN 2-7464-0493-1.

[16] http://www.micro5etoiles.com/index.php?page=lesreseaux Réseaux filaires et

sans fil (Ethernet, Wifi, Bluetooth, ADSL, Fibre optique, VOIP…) consulter le 13.02.2017.

[17] Samedis bénévoles spécial Arduino,Workshop n°2 , FICHE F6 – CAPTEURS ET

ACTIONNEURS, http://www.sti.ac-versailles.fr/IMG/pdf/capter-grandeur_lc_v2015-10-

08.pdf

[18] Transmission de données - Le câblage,

http://www.commentcamarche.net/contents/1128-transmission-de-donnees-le-cablage

consulter le 10.11.2016

[19] Utiliser une plaque d’essai.[en ligne].http://www.elektronique.fr/montages/diviseur-

tension/utiliser-plaque-essai.php. [Page consultée le04/06/2017].

[20] https://boutique.semageek.com consulter le 12 /02/2017.

[21] La diode L.E.D. http://www.positron-

libre.com/cours/electronique/diode/led/diode-led.php . Consulter le 12.03.2017. Les

références 2:

[22] R. Toscano, Commande et diagnostic des systèmes dynamiques, Edition Ellipses

Paris, 2005.

[23] R. Isermann and P. Ballé, Terminology in the _eld of supervision, fault detection

and Diagnosis, Technical Committee of Safeprocess'97 (August, 1997).

[24] S.Touf, diagnostic logique des systèmes complexes dynamiques dans un contexte

[25] L banqué .M estarda. La notion de diagnostic dans le cadre d’applications de la

méthode verbo-tonale à l’apprentissage d’une Langue2/Langue Etrangère par des bilingues et à la

rééducation de patients aphasiques ; Université Autònoma de Barcelona .2006 .

http://www.strategie.gouv.fr/publications/demain-linternet-objets

http://www.micro5etoiles.com/index.php?page=lesreseaux

http://www.sti.ac-versailles.fr/IMG/pdf/capter-grandeur_lc_v2015-10-08.pdf

http://www.sti.ac-versailles.fr/IMG/pdf/capter-grandeur_lc_v2015-10-08.pdf

http://www.commentcamarche.net/contents/1128-transmission-de-donnees-le-cablage%20consulter%20le%2010.11.2016

http://www.commentcamarche.net/contents/1128-transmission-de-donnees-le-cablage%20consulter%20le%2010.11.2016

https://boutique.semageek.com/

http://www.positron-libre.com/cours/electronique/diode/led/diode-led.php

http://www.positron-libre.com/cours/electronique/diode/led/diode-led.php

106

[26] Rabah fellouah Contribution au Diagnostic de Pannes pour les Systèmes

Différentiellement Plats. Thèse doctorat université de toulouse.2007.

[27] Document interne de CE. Comité d'Experts Diagnostic et Sureté de

Fonctionnement 2007 .

[28] A.Slatna. Implémentation d’une application orientée surveillance pour les réseaux de

capteurs. Mémoire mastère université Tlemcen 2012.

[29] Samir Touaf. diagnostic logique des systèmes complexes et dynamiques dans un

contexte multi-agent. automatique / robotique. université Joseph-Fourier - Grenoble i, 2005.

français.

[30] coordination régional .réalisation d’une étude de diagnostic sur les systèmes

d’information.2016.

[31] N.Belfarhi. Conception d’un outil d’aide à la détection et diagnostic des défaillances

dans un système de production. Mémoire magistère 2012.

[32] A.Mokhtari. Diagnostic des systèmes hybrides: développement d'une méthode

associant la détection par classification et la simulation dynamique. Automatique / Robotique.

INSA de Toulouse, 2007. Français.

[33] A.Benahmed daho .diagnostic de pannes guidée par les données dans les réseaux

de capteurs sans fil. Mémoire mastère Université badji Mokhtar Annaba 2014.

[34] Système embarque temps réel d’aide au diagnostic des dysfonctionnements pour

véhicule terrestre légère. Mémoire mastère université des montagnes 2014 2015 ;

[35] Sebastian Lalle, Jack Mostow, Vanda Luengo, Nathalie Guin. Comparaison de

l'impact de Techniques de diagnostic des connaissances sur l'apprentissage d'une stratégie d'aide.

Journée EIAH&IA 2013, May 2013, Toulouse, France. 10 p., 2013.

[36] Abed Alrahim Yassine. Génération des tests et placement de capteurs pour le

diagnostic des systèmes physiques s'appuyant sur une modélisation structurelle. Automatique /

Robotique. Université Joseph-Fourier - Grenoble I, 2008. Français.

[37] Alexis.G. Contrôle et diagnostic par un réseau de capteurs magnétiques en

automobile. Autre. Université Grenoble Alpes, 2011. français.

[38] Nathalie Fabbe-Costes. Les systèmes experts de diagnostic technique :

Opportunité d'utilisation et contraintes de réalisation. L'Entreprise Logistique, Eurolog - Groupe

ESSEC et Society of Logistics Engainées - France, 1989, Intelligence Logistique et Systèmes

Experts

107

[39] N.Boutasseta. diagnostic robuste des systèmes énergétiques par l’approche bond

graphe. Mémoire magistère Université Badji Mokhtar ANNABA .2012.

[40] k.Merahi.estimation d’état et diagnostic de fonctionnement des systèmes non

linéaire. Mémoire magistère.2010.

[41] Dima Hamdan. Détection et diagnostic des fautes dans des systèmes à base de

réseaux de capteurs sans les. Autre [cs.OH]. Université de Grenoble, 2013. Français.

[42] Haithem Derbel. Diagnostic _a base de mod_eles des syst_emes temporis_es et

d'une sous-classe de syst_emes dynamiques hybrides. Automatique / Robotique. Universit_e

Joseph-Fourier - Grenoble I, 2009. Fran_cais.

[43]Y.Shou .cryptographie sur les courbes elliptiques et tolérance aux pannes dans les

réseaux de capteurs. Thèse de doctorat 2014.

[44] Quang Huy Giap. Sur le diagnostic interactif. Automatique / Robotique.

Université Grenoble Alpes, 2011. Français.

[45] Y. Huang, C. Kintala, N. Kolettis, N. Fulton, “Software Rejuvenation: Analysis,

Module and Applications”, Proc. 25th IEEE Int. Symp. Fault-Tolerant Computing (FTCS-25),

(Pasadena, CA, USA), pp.381-390, IEEE CS Press, 1995.

[46]Walker B.K., Gai E., “Fault detection threshold determination techniques using

Markov theory”, Int. J Guidance, Control and Dynamics, vol. 2, n°4, pp. 313-319, 1979.

[47] https://tel.archives-ouvertes.fr/tel-00008768/document. consulter le 10.2.2017.

[48] B. Hakami and J. Newborn, Expert Systems in Heavy Industry : An Application

of ICLX in a British Steel Corporation Works, ICL Technical Journal (1983), 347_359.

[49] N. Ramanathan, K. Chang, L. Girod, R. Kapur, E. Kohler D. Estrin. Sympathy

for the sensor network debugger. 3rd international conference on Embedded networked sensor

systems, May 2005, New York, USA, pp. 255 - 267.

[50] Isermann, R. and P. Balle (1997). Trends in the Application of Model-Based Fault

Detection and Diagnosis of Technical Processes, Control Engineering Practice, 5(5), pp. 709-719.

[51]J. N. Chatain, Diagnostic par Système Expert, Traité des Nouvelles Technologies,

série Diagnostic et Maintenance, édition Hermes1993.

[52] Watson, un système expert en diagnostic . https://bioinfo-fr.net/watson-un-

systeme-expert-en-diagnostic consulter le03.12.2016.

https://tel.archives-ouvertes.fr/tel-00008768/document.%20consulter%20le%2010.2.2017

https://bioinfo-fr.net/watson-un-systeme-expert-en-diagnostic

https://bioinfo-fr.net/watson-un-systeme-expert-en-diagnostic%20consulter%20le03.12.2016

https://bioinfo-fr.net/watson-un-systeme-expert-en-diagnostic%20consulter%20le03.12.2016

108

[53] Gilles Zwingelstein Diagnostic des défaillances: théorie et pratique . Éditeur,

Hermès, 1995. ISBN, 2866014634.

[54] Henri Farreny Contribution des systèmes a bases de connaissances . 1989

[55] J. Ferber, « les Systèmes Multi-Agents, Vers une intelligence collective »,

Inter Éditions, 1995

[56] Ho Tuong Vinh et Nguyen Manh Hung, Génie logiciel orienté agent. Travail d’intérêt

personnel encadré (TIPE), 2006, L'institut de la francophonie pour l’informatique (IFI).

[57] Thomas, V., Bourjot, C., & Chevrier, V. (2007). Construction de systèmes

multiagents par apprentissage collectif à base d'interactions. Revue d'Intelligence Artificielle, 21(5-6),

643-672.

[58] FERBER J., Les Systèmes Multi-Agent - Vers une Intelligence Collective, Inter

Editions, 1995.

[59] Michael Wooldridge, An Introduction to Multiagent Systems, JOHN WILEY & SONS,

LTD. 2002.

[60]Hyacinth S. Nwana, “Software Agents : An Overview,” Knowledge Engineering Review,

p. 42, 1996.

[61] Ferber, Jacques. « Technologie multi-agent ». Université Pière et Marie Curie

(ParisVI), 1999.

[62]Noémy PICARD, “Planarisation des graphes à l’aide des systèmes muti agents,”

Université de Mont-Saint-Aignan, Mémoire de stage, 2004 2003.

[63] Hichem RAHAB. Une approche à base d’agents adaptatifs pour la résolution des

systèmes complexes. MEMOIRE Présenté en vue de l’obtention du diplôme de MAGISTER EN

INFORMATIQUE.2010/2011

[64]: Michael Wooldridge, “Intelligent Agents,” in Multiagent Systems: A Modern Approach

to Distributed Modern Approach to Artificial Intelligence, The MIT Press Cambridge, Massachusetts,

London, England: Gerhard Weiss, 1999, pp. 36–66.

[65] S.J. Russell, P. Norvig, Artificial Intelligence: A Modern Approach.Englewood Cliffs, NJ:

Prentice Hall, 1995.],

https://www.google.dz/url?sa=t&rct=j&q=&esrc=s&source=web&cd=3&ved=0ahUKEwiKw6atrITUAhWEbRQKHQEiBZgQFggyMAI&url=https%3A%2F%2Fbooks.google.fr%2Fbooks%2Fabout%2FDiagnostic_des_d%25C3%25A9faillances.html%3Fhl%3Dfr%26id%3DcQU5PQAACAAJ&usg=AFQjCNEXyhHuD4oniRnQEChki6M3wk-_ww&sig2=QpUr8edZT0ZWrOVTkZTpPA

https://tel.archives-ouvertes.fr/tel-00815333/file/1989_Cres_Francois-Noel.pdf

109

[66] Guillaume Hutzler / Tarek Melliti Intelligence Artificielle Distribuée Systèmes

Multi-Agents(http://www.ibisc.univ-evry.fr/~hutzler/Cours/SMA.html)

[67] : « Systèmes Multi-Agents », Université de Pau, Eric Gouardères.

[68] : Mazouzi, Hamza. « Ingénierie des protocoles d’interaction : des systèmes distribués

aux systèmes Multi-agents » : thèse de docteur de l’université paris 9 Dauphine, octobre

2001.

[69] Jenings J.R. « Commitments and Conventions: The foundation of coordination in multiagent

systems ». The knowledge Engineering review, 2(3): pages 223-250, 1993.

[70] J.R.Searle. Speech Acts. Cambridge University Press, 1969.

[71] Z. Guessoum, R. Mandiau, P. Mathieu,et All, Systèmes Multi-Agents et Simulation,

Chapter in book "Information - Interaction - Intelligence, Le point sur le i(3)", F. Sèdes, P. Marquis,

J. M Ogier (Eds), Cépaduès Editions, Vol. ISBN 978.2.36493.009.4, pp 76-120, 2012

[72] fichier acte de langage http://asl.univ-

montp3.fr/e21slmc/doc_CM/Fiche_actes_de_langage.pdf

[73] Hyacinth S. Nwana, “Software Agents : An Overview,” Knowledge Engineering Review,

p. 42, 1996.

[74] Stuart J. Russell and Peter Norvig, Artificial Intelligence : A Modern Approach,

Englewood Cliffs. New Jersey: Alan Apt, 1995.

[75] Philippe Pasquier, “Communication entre agents”, doctorant DAMAS université Laval

Canada, 2001.

[76] https://zestedesavoir.com/tutoriels/686/arduino-premiers-pas-en-informatique-

embarquee/746_les-capteurs-et-lenvironnement-autour-darduino/3434_generalites-sur-les-

capteurs/

[77] http://www.alertes-meteo.com//ladcine – le climat & la senté consulter le

12/02/2017.

[78] http://Réduisez l’humidité et les moisissures - Canada.ca.html consulter le

14/01/2017.

[79] fichier arduino.PM5. dimanche 2mars 2014 ;presentation de la carte arduino

UNO.consulter le 03/11/2016.

http://www.ibisc.univ-evry.fr/~hutzler/Cours/SMA.html

110

[80] http://www.generationrobots.com/fr/152-arduino. Consulter le 12\01\2017.

[81] C. Tavernier, « Arduino applications avancées ». Version Dunod

[82] Arduino Uno. [en ligne].

http://www.monclubelec.fr/pmwiki_reference_Arduino/pmwiki.php?n=Main.MaterielU

no.[Page consultée le 13/05/2016]

[83] S.V.D.Reyvanth, G.Shirish, « PID controller using Arduino ».

[84] Arduino. Publisher : 2011 -12-22 License : None

[85] Becky Stewart .A l’aventure avec arduino dès 10 ans. ة DITIONS EYROLLES 61, bd

Saint-Germain 75240 Paris Cedex 05 www.editions-eyrolles.com.2015.

[86] MICHEL Fabienne : Asphyxie oxyprive,[document electronique], Strasbourg, janvier

2005 , http://medtrav54.free.fr/Nancy_05/Strasbourg/asphyxieanoxique.doc

[87] instrumentation CIRA. Mesure de températur.2005 /2006 ;

[88] https://fr.wikipedia.org/wiki/Sonde_de_temp%C3%A9rature consulter le

10 /02/2017 ;

[89] http://fr.farnell.com/capteurs-environnementaux_capteurs-d-humiditeconsulter le

10/02/2017; http://www.univ-pau.fr/~cpham [email protected]

[90] KOUAH SOFIA. Conception des systèmes multi-agents à base de modèles formels

integrant le flou.these doctorat.Thèse préparée au laboratoire MISC, Université de Abdelhamid

Mehri - Constantine2

[91] http://www.swi-prolog.org/packages/jpl/. Consulter le 10/05/2017.

[92] http://www.bluecove.org/. Consulter le 12 /05/2017.

[93] https://tecfa.unige.ch/guides/tie/html/mysql-intro/mysql-intro-7.html. Consulter le

02/04/2017.

[94] Lloyd, J. W. (1984). Foundations of logic programming. Berlin: Springer-Verlag. ISBN 3-

540-13299-6.

[95]Kowalski, R. A. (1988). "The early years of logic programming" (PDF). Communications

of the ACM. 31: 38. doi :10.1145/35043.35046

[96] : Axelle LEMAIRE, Christophe SIRUGUE.internet des objets nouvelle France

indistruelle.14/12/2016.

http://www.generationrobots.com/fr/152-arduino

https://fr.wikipedia.org/wiki/Sonde_de_temp%C3%A9rature

http://fr.farnell.com/capteurs-environnementaux_capteurs-d-humiditeconsulter%20le%2010/02/2017

http://fr.farnell.com/capteurs-environnementaux_capteurs-d-humiditeconsulter%20le%2010/02/2017

http://www.univ-pau.fr/~cpham

mailto:[email protected]

http://www.swi-prolog.org/packages/jpl/

http://www.bluecove.org/

https://tecfa.unige.ch/guides/tie/html/mysql-intro/mysql-intro-7.html

https://en.wikipedia.org/wiki/International_Standard_Book_Number

https://en.wikipedia.org/wiki/Special:BookSources/3-540-13299-6

https://en.wikipedia.org/wiki/Special:BookSources/3-540-13299-6

http://www.doc.ic.ac.uk/~rak/papers/the%20early%20years.pdf

https://en.wikipedia.org/wiki/Digital_object_identifier

https://doi.org/10.1145%2F35043.35046

111

[97] : https://www.afnic.fr/fr/expertises/labs/projets-realises/l-internet-des-objets-

projets-wings-et-proxi-produit.html consulter le 17/04/2017.

https://www.afnic.fr/fr/expertises/labs/projets-realises/l-internet-des-objets-projets-wings-et-proxi-produit.html

https://www.afnic.fr/fr/expertises/labs/projets-realises/l-internet-des-objets-projets-wings-et-proxi-produit.html

Documents

Architecture Basée Agents pour le