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
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
Introduction générale
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
Introduction générale
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
Chapitre 1 : Internet des Objets (Internet Of Things)
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
Chapitre 1 : Internet des Objets (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].
Chapitre 1 : Internet des Objets (Internet Of Things)
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].
Chapitre 1 : Internet des Objets (Internet Of Things)
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 :
Chapitre 1 : Internet des Objets (Internet Of Things)
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.
Chapitre 1 : Internet des Objets (Internet Of Things)
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.
Chapitre 1 : Internet des Objets (Internet Of Things)
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.
Chapitre 1 : Internet des Objets (Internet Of Things)
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] :
Chapitre 1 : Internet des Objets (Internet Of Things)
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 :
Compatible de l'interface Grove
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
Chapitre 1 : Internet des Objets (Internet Of Things)
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 :
Compatible de l'interface Grove
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
Chapitre 1 : Internet des Objets (Internet Of Things)
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
Chapitre 1 : Internet des Objets (Internet Of Things)
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
Chapitre 1 : Internet des Objets (Internet Of Things)
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.
Chapitre 1 : Internet des Objets (Internet Of Things)
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
Chapitre 1 : Internet des Objets (Internet Of Things)
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
Chapitre 2 : Etude des Approches de Diagnostic des Systèmes
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
Chapitre 2 : Etude des Approches de Diagnostic des Systèmes
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.
Chapitre 2 : Etude des Approches de Diagnostic des Systèmes
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
Chapitre 2 : Etude des Approches de Diagnostic des Systèmes
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.
Chapitre 2 : Etude des Approches de Diagnostic des Systèmes
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.
Chapitre 2 : Etude des Approches de Diagnostic des Systèmes
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.
Chapitre 2 : Etude des Approches de Diagnostic des Systèmes
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
Chapitre 2 : Etude des Approches de Diagnostic des Systèmes
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
Chapitre 2 : Etude des Approches de Diagnostic des Systèmes
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
Chapitre 2 : Etude des Approches de Diagnostic des Systèmes
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.
Chapitre 2 : Etude des Approches de Diagnostic des Systèmes
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é.
Chapitre 2 : Etude des Approches de Diagnostic des Systèmes
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
Chapitre 3 : Etude des Système Multi-Agent
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].
Chapitre 3 : Etude des Système Multi-Agent
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
Chapitre 3 : Etude des Système Multi-Agent
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
Chapitre 3 : Etude des Système Multi-Agent
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]
Chapitre 3 : Etude des Système Multi-Agent
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 :
Chapitre 3 : Etude des Système Multi-Agent
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].
Chapitre 3 : Etude des Système Multi-Agent
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
Chapitre 3 : Etude des Système Multi-Agent
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].
Chapitre 3 : Etude des Système Multi-Agent
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.
Chapitre 3 : Etude des Système Multi-Agent
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).
Chapitre 3 : Etude des Système Multi-Agent
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
Chapitre 3 : Etude des Système Multi-Agent
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].
Chapitre 3 : Etude des Système Multi-Agent
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, …
Chapitre 3 : Etude des Système Multi-Agent
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 %.
chapitre 4 : conception et réalisation d’un objet connecté
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.
chapitre 4 : conception et réalisation d’un objet connecté
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).
chapitre 4 : conception et réalisation d’un objet connecté
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.
chapitre 4 : conception et réalisation d’un objet connecté
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.
chapitre 4 : conception et réalisation d’un objet connecté
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.
chapitre 4 : conception et réalisation d’un objet connecté
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.
chapitre 4 : conception et réalisation d’un objet connecté
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.
chapitre 4 : conception et réalisation d’un objet connecté
62
Figure 17: description détaillé de la carte ARDUINO UNO[79]
chapitre 4 : conception et réalisation d’un objet connecté
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
chapitre 4 : conception et réalisation d’un objet connecté
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é ?
chapitre 4 : conception et réalisation d’un objet connecté
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.
chapitre 4 : conception et réalisation d’un objet connecté
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 :
chapitre 4 : conception et réalisation d’un objet connecté
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
chapitre 4 : conception et réalisation d’un objet connecté
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.
chapitre 4 : conception et réalisation d’un objet connecté
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.
chapitre 4 : conception et réalisation d’un objet connecté
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 .
chapitre 4 : conception et réalisation d’un objet connecté
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é :
chapitre 4 : conception et réalisation d’un objet connecté
72
Figure 30: diagramme d'activité globale
Figure 31: diagramme d’activité envoyer les données au serveur
chapitre 4 : conception et réalisation d’un objet connecté
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.
chapitre 4 : conception et réalisation d’un objet connecté
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é
chapitre 4 : conception et réalisation d’un 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.
chapitre 4 : conception et réalisation d’un objet connecté
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
chapitre 4 : conception et réalisation d’un objet connecté
77
Code Arduino pour le capteur de co2
Code Arduino pour le détecteur de distance :
chapitre 4 : conception et réalisation d’un objet connecté
78
Code Arduino du Bluetooth
5. Quelques interfaces
Fenêtre principale sur smartphone
chapitre 4 : conception et réalisation d’un objet connecté
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 :
chapitre 4 : conception et réalisation d’un objet connecté
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
chapitre 4 : conception et réalisation d’un objet connecté
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.
Conception et réalisation d’une application multi-agents pour le diagnostic d’un système d’IoT
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 :
Conception et réalisation d’une application multi-agents pour le diagnostic d’un système d’IoT
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
Conception et réalisation d’une application multi-agents pour le diagnostic d’un système d’IoT
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.
Conception et réalisation d’une application multi-agents pour le diagnostic d’un système d’IoT
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
Conception et réalisation d’une application multi-agents pour le diagnostic d’un système d’IoT
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>
)
Conception et réalisation d’une application multi-agents pour le diagnostic d’un système d’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
Conception et réalisation d’une application multi-agents pour le diagnostic d’un système d’IoT
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.
Conception et réalisation d’une application multi-agents pour le diagnostic d’un système d’IoT
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.
Conception et réalisation d’une application multi-agents pour le diagnostic d’un système d’IoT
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.
Conception et réalisation d’une application multi-agents pour le diagnostic d’un système d’IoT
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].
Conception et réalisation d’une application multi-agents pour le diagnostic d’un système d’IoT
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]
Conception et réalisation d’une application multi-agents pour le diagnostic d’un système d’IoT
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.
Conception et réalisation d’une application multi-agents pour le diagnostic d’un système d’IoT
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).
Conception et réalisation d’une application multi-agents pour le diagnostic d’un système d’IoT
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
Conception et réalisation d’une application multi-agents pour le diagnostic d’un système d’IoT
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
Conception et réalisation d’une application multi-agents pour le diagnostic d’un système d’IoT
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 :
Conception et réalisation d’une application multi-agents pour le diagnostic d’un système d’IoT
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
Conception et réalisation d’une application multi-agents pour le diagnostic d’un système d’IoT
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
Conclusion générale
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.
Conclusion générale
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.
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 .
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.
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.],
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.
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.
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.