D ́ esign ́ e, d ́ evelopement et ́ evaluation les performances d’un syst` eme l’autonome de r ́ eseaux capteurs sans fil pour la surveilance de l’environnement

l’Insittute de la Francophonie pour
l’Informatique

´seaux et Syste
`me
Rapport de stage - Master 2 Re
Communication

D´
esign´
e, d´
evelopement et ´
evaluation les
performances d’un syst`
eme l’autonome
de r´
eseaux capteurs sans fil pour la
surveilance de l’environnement

Supervisor:

Etudiant:

M. Han Mingding

La Thanh Tam

March 2015


Remerciements

Je souhaite tout d’abord remercier mon encadrant de stage, monsieur Han Mingding,
pour m’avoir accueilli dans l’´equipe, pour son soutien tout au long du stage, sa disponibilit´e, et ses conseils nombreux et ´eclair´es.
Merci ´egalement `
a Ma Xiaoping pour m’avoir aid´e `a me familiariser avec l’environnement de d´eveloppement `
a I2R, mais surtout pour sa gentillesse et son implication
dans mon stage.
Un grand merci `
a Brian et Alvin pour leurs conseils dans des nombreux probl`emes de
technique.
Enfin, merci `
a tous les mebres de SNS pour la gentillesse de m’aider `a familier avec le
nouvel environnement de travail et le nouveau pays.

i


R´esume
Ce travail vise `
a ´elaborer un ensemble de capteurs sans fil pour recueillir le signal de
luminance de l’environnement. Ce syst`eme sera attach´e `a la voiture ou en bus voyage
autour de la ville et envoyer les donn´ees recueillies sur le serveur par la connexion 3G /
4G en temps r´eel. L’analyse des donn´ees recueillies peut aider `a donner un plan pour le
syst`eme de lumi`ere maintenir, l’´economie d’´energie ou d’assurer la s´ecurit´e ...
Le syst`eme va g´erer les donn´ees bas´ee sur les signaux des capteurs de lumi`ere qui indiquent l’´etat de brillant, Unit´e de Mesure Inertielle(Inertial Measurement Unit) avec
la comination d’acc´el´erom`etres, gyroscopes, magn´etom`etres et un GPS pour donner la
potition et l’heure de ces donn´ees, enfin une modem 3G avec la 3G SIM carte fournir
une connexion `
a envoyer les donn´ees vers le serveur.
Pour les transfert de donn´ees, nous avons con¸cu un contrˆoleur pour surveiller l’intensit´e
du signal 3G et d´ecider quand les donn´ees seraint envoi´ees. L’objectif de ce contrˆoleur

est de sauver des ressources et de l’´energie tout en ´eviter la cause de r´eexp´edition inutile
de la mauvaise connexion. En fin, les r´esultats de l’exp´erimentation nous aideront `
a
construire un ensemble de r`egles pour obtient un contrˆoleur plus ”int´elligent”.
Dans ce projet, on utilise technologies de ”Message Queuing Telemetry Transport”, un
protocole l´eger pour le r´eseau de capteurs sans fil et son utilisation dans le domaine de
l’Internet des Objets (Internet of Things) - la future de l’Internet.
Abstract
This work aims to develop a wireless sensor package to collect the luminance signal
from the environment. This package can be binded to the car or bus travel around the
city and send the data collected to the server via 3G/4G connection in real time. The
analysis from data collected can help to give a plan for light system maintain, saving
energy or ensure a safe city, etc.
The package conducted data with the signals from the light sensors which show status
of shiny, Inertial Measurement Unit combination of accelerometers, gyroscopes, magnetometers and a GPS to give the location and time for these data, finally an 3G dongle
with 3G simcard provide connection to send the data to server.
For the data transferring, we have designed a controller to monitoring the 3G signal
strength and decide whether to send data or not. The objective of this controller is
saving resource and energy while avoid the unnecessary resending cause of the bad
connection. In the end, results from experimentation will help us to build a set of rules
for the intelligent controller


Contents
Acknowledgements

i

R´
esume

ii

Contents

iii

Liste des Figures

v

Liste des Tableaux

vii

Abbreviations

viii

1 Introduction
1.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.2 Les exigences du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1
1
2

2 Context
2.1 Internet des objets - la future de Internet . . . . . . . . . . . . . . . . .
2.2 Les protocoles dans la domain IoT . . . . . . . . . . . . . . . . . . . . .

2.2.1 Hypertext Transfer Protocol, un protocole bien connu . . . . . .
2.2.2 CoAP - Contrainte Application Protocol, le protocole pour le web
des objets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.2.3 Message Queuing Telemetry Transport . . . . . . . . . . . . . . .
2.2.4 Quel est le meilleur protocole? . . . . . . . . . . . . . . . . . . .

3
3
4
4

3 D´
eveloppement
3.0.5 Equipement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.0.5.1 Mat´eriel n´ecessaire . . . . . . . . . . . . . . . . . . . . .
3.0.6 Logiciel et environnement de configuration . . . . . . . . . . . . .
3.0.6.1 Configuration de l’environnement de d´eveloppement . .
3.0.6.2
BeagleBone Black syst`eme configuration . . . . . . . .
3.0.7 Architecture du syst`eme . . . . . . . . . . . . . . . . . . . . . . .
3.0.7.1 Noeud de capteur . . . . . . . . . . . . . . . . . . . . .
3.0.7.2 Server Backend . . . . . . . . . . . . . . . . . . . . . . .
3.0.8 Autres outils pour le d´eveloppement . . . . . . . . . . . . . . . .
3.0.8.1 Git - gratuit et open source syst`eme de contrˆole de version distribu´e . . . . . . . . . . . . . . . . . . . . . . . .
iii

.
.
.

. 4
. 7
. 10

.
.
.
.
.
.
.
.
.

12
12
12
17
17
20
21
21
26
27

. 27


Contents

iv
3.0.8.2

Trello - Outil pour garder trace de projet . . . . . . . . . 28

4 Exp´
erimentation et analyse
4.0.9 Background . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.0.10 Objectif exp´erimentation . . . . . . . . . . . . . . . . . . . . . . .
4.0.11 Exp´erimental configuration . . . . . . . . . . . . . . . . . . . . . .
4.0.12 La collecte des donn´ees . . . . . . . . . . . . . . . . . . . . . . . .
4.0.13 Analyse du rendement . . . . . . . . . . . . . . . . . . . . . . . . .
4.0.13.1 En comparant avec MQTT QoS0 DTN contrˆole vs MQTT
QdS1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.0.13.2 D´elai en comparaison avec RTT . . . . . . . . . . . . . .
4.0.13.3 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . .

30
30
30
31
32
33

5 Conclusion et perspectives

40

A Installer Archlinux dans BBB `
a partir de z´

ero

42

Bibliography

49

33
35
38


List of Figures
2.1

Protocole CoAP activer les services Web en int´egrant `a l’architecture Web
et HTTP 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.2 CoAP diagramme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.3 Un acc`es web demande l’utilisation de CoAP exemple `a l’aide de ressources
a distance via URI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
`
2.4 Observer ressources dans CoAP.3 . . . . . . . . . . . . . . . . . . . . . . . 6
2.5 un message CoAP avec l’en-tˆete seulement 4 octets (en-tˆete, option, donn´ee).
la source RFC 7252 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.6 MQTT sch´ema, Publisher et abonn´e . . . . . . . . . . . . . . . . . . . . . 8
2.7 Format d’un message MQTT . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.8 MQTT Qos = 0, un message sera envoy´e au plus un fois . . . . . . . . . . 9
2.9 MQTT Qos = 1, un message sera envoy´e au moins une fois . . . . . . . . 9
2.10 MQTT Qos = 2, un message sera envoy´e exactement une fois . . . . . . . 10

3.1
3.2
3.3
3.4
3.5
3.6
3.7
3.8
3.9
3.10
3.11
3.12
3.13
3.14
3.15
3.16

BeagleBone Black . . . . . . . . . . . . . . . . . . . . . . . . .
Capteur de lumi`ere (BH1750) . . . . . . . . . . . . . . . . . .
Les capteurs de lumi`ere sont r´epartis le long de la voiture . .
Inertial Measurement Unit (LSM303D) . . . . . . . . . . . . .
Acc´el´erom`etre . . . . . . . . . . . . . . . . . . . . . . . . . . .
R´ecepteur GPS (EM506) . . . . . . . . . . . . . . . . . . . . .
GPS shield . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Cˆ
ables et fils . . . . . . . . . . . . . . . . . . . . . . . . . . .
USB modem avex 3G simcard fournir une connexion `a Beagle
Beagle Bone Black et des capteurs connexion via des fils . . .
Architecture du syst`eme . . . . . . . . . . . . . . . . . . . . .
Architecture du syst`eme . . . . . . . . . . . . . . . . . . . . .

MBI file d’attente et base de donn´ees en attente . . . . . . .
Perturbation tol´erant le streaming de donn´ees de capteurs . .
Trello board pour LiteSense projet . . . . . . . . . . . . . . .
Exemple d’un ”Card” dans Trello . . . . . . . . . . . . . . .

4.1
4.2
4.3
4.4

Experiment avec deux noeud . . . . . . . . . . . . . . . . . . . . . . . .
L’exp´erimentation pour collecter les donn´ees . . . . . . . . . . . . . . . .
Comparison le nombre de messages envoy´ees en utilisant Qos . . . . . .
Comparison le nombre de messages envoy´ees en utilisant (i) QoS0 + DTN,
et (ii) QoS1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Comparison le taux de nombre de messages envoy´ees (i) QoS0 + DTN,
against (ii) QoS1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4.5

v

. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .

Bone Black
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .

13
13
14
14
15
15
15
16
16
17
21
22
25
25
28
29

. 31
. 32
. 33
. 34

. 34


Liste des figures
4.6
4.7
4.8
4.9
4.10

Comparison le d´elais en utilisant (i) QoS0 + DTN, against (ii) QoS1
Message Livraison D´elais avec temps pour QoS 0 . . . . . . . . . . .
Message Livraison D´elais avec temps pour QoS 1 . . . . . . . . . . .
Message Retard de livraison en fonction du temps ´ecoul´e pour QoS 0
Quelque messages peut ˆetre transf´erer dans un paquet TCP . . . . .

vi
.
.
.
.
.

.
.
.
.
.

.

.
.
.
.

35
35
36
37
38


List of Tables
3.1

Fr´equence de message (en seconde) g´en´eration pour les sujets dans la
couche de donn´ees . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

vii


Abbreviations
BBB

BeagleBone Black Recv - Le mat´eriel pricipale pour d´eployer le syst`eme

DTN

Disruption-Tolerant Networking - R´eseaux Tol´erants aux Perturbations

MBI

Message Broker Interface - L’interface pour les Messages de broker

DAQ

Data Acquisition Module - Module communique directment avec les capteurs

MQTT

Message Queuing Telemetry Transport

IMU

Inertial Measurement Unit - Unit´e pour Measurer l’Inertielle

SNS

Sense and Sense abilities

I2R

Institute for Infocomm Research

IoT

Internet of Things - R´eseaux des Objets

M2M

Mobile To Mobile

WSN

Wireless Sensors Network

viii


Chapter 1

Introduction
1.1

Introduction

Mon stage a ´et´e ´effectu´e au laboratoire ”Sense and Sens abilities” - Institute de Recherche
pour Infocomm de Singapour. Le sujet est de partir des exigences de Cosmiqo

1

,

une compagnie locale, qui a d´eploy´e des capteurs sur un v´ehicule syst`eme-attach´e pour
mesurer r´everb`ere luminance la nuit. Les donn´ees recueillies par une unit´e d’acquisition
de donn´ees seraient stock´ees dans un ordinateur portable qui est manuellement ramen´e
`a leur administrateur pour les stockage et l’analyse. Les donn´ees sont stocqu´ees dans des
fichiers au format CSV (valeurs s´epar´ees par des virgules ), et manipul´es manuellement
pour l’analyse des donn´ees et la g´en´eration de rapports.
Ce projet vise `

a am´eliorer le syst`eme existant avec transmission en temps r´eel de donn´ees
de mesures de capteurs d’intensit´e lumineuse. Toutefois, compte tenu de la connectivit´e
intermittente de cellulaire 3G / 4G dans les villes denses, la liaison sans fil peut parfois
ˆetre supprim´ee, ce qui entraˆıne la perte de packets.
L’objectif de la recherche de ce projet est de d´evelopper des protocoles r´eseaux tol´erants
aux perturbations qui s’adaptent aux changements dynamiques de la liaison de donn´ees,
et ´egalement de mettre en place un m´ecanisme de mise en m´emoire tampon de donn´ees
pour stocker temporairement des donn´ees localement lorsque la connecxion est en bas.

1

www.cosmiqo.com

1


Chapter 1. Introduction

1.2

2

Les exigences du projet

A partir de la demande des clients, nous avons sp´ecifi´ees pour le syst`eme:

• Concevoir et mettre un nouveau noeud de capteur qui se compose des capteurs de
la lumi`ere.
• Transfert les donn´ees de capteurs en temps r´eel avec perturbations tol´erant.
• D´esigner le sch`eme de m´emoire tampon pour stoquer et envoyer les donn´ees en

utilisant la qualit´e de la connection
• Mettre en œuvre les strat´egies ci-dessus dans le protocole de communication pour
la diffusion de donn´ees

Pour atteindre ces objectifs, il est n´ecessaire, dans un premier temps, d’acqu´erir une
bonne (i)connaissance de l’Internet des objets (IoT) [2] une partie inportante dans notre
projet. (ii) Une ´etude sur le protocole pour les transfert de donn´ees dans ce domaine
donnera id´ee sur les difficult´es et des d´efis pour le streaming en temps r´eel avec la
perturbations tol´erant. (iii) Il est ´egalement indispensable d’examiner les exigences
mat´erielles et logicielles pour donner un processus de d´eveloppement, les probl`emes
et les solutions. (iiii) Enfin l’exp´erimentation montrera les performances du syst`eme.
R´esultat analyse aide `
a donner conclusion et perspective pour le projet.


Chapter 2

Context
2.1

Internet des objets - la future de Internet

Au cours des derni`eres ann´ees, l’Internet des objets (Internet of Things - IoT), est
devenu le nouvel axe de recherche pour l’industrie et le milieu universitaire. Aujourd’hui,
Internet est non seulement un ensemble de l’ordinateur connect´e en tant que d´efinition
dans 19th si`ecle. Il est la connecxion entre tous les objets (les objets physique, les
t´el´ephone portable et aussi l’humaine ...)
Ce terme est devenu plus populaire o`
u l’Internet est reli´e aux mots physiques via le r´eseau
de capteurs sans fil. Avec le d´eveloppement des nouvelles technologies, les capteurs

sont devenus plus petits, moins de consommation d’´energie et assez pas cher `a utiliser
largement dans la vie quotidienne.
En g´en´eral, les capteurs ont des caract´eristiques communes, telles que les ressources
sont limit´ees de puissance, la capacit´e limit´ee, minimale de l’interaction avec l’humaine,
etc. A cause des limitations, minimiser la coˆ
ut des communications est une exigence
l’importance, mˆeme avec le d´ev´eloppement des technologies sans fils et 4G-LTE un
syst`eme de communication efficaces est encore n´ecessaire. Sur cette section, nous allons
concentrer sur la fa¸con dont les p´eriph´eriques communiquent, les d´efis de protocole IoT.

3


Chapter 2. Context

2.2

4

Les protocoles dans la domain IoT

En IoT les objets peuvent communiquer avec les autres (D2D) ou recueillir des donn´ees
et envoy´e `
a l’infrastructure de serveur (D2S). Cette serveur infrastructure peut partager
les donn´ees avec autre serveur (S2S), ou les objets pour analyser les donn´ees. Comme le
´enorme nombre de objets augment´e par l’ann´ee, trouver un bon protocole pour le r´eseau
est toujours un grand d´efi.
Dans cette section, on va avoir une vue ensemble sur quelques protocole pour la communication entre les objets et serveur. L’analisation sur leurs point fortes et les points
faibles pourrait nous donner une solution possible pour notre objet.

2.2.1

Hypertext Transfer Protocol, un protocole bien connu

Hypertext Transfer Protocol (HTTP) [RFC 2616] est un des protocoles les plus omnipr´esents dans l’Internet. Il d´efinit la fa¸con dont le Web navigateurs, proxys Web et les
serveurs Web doivent se comporter et d’interagir [6]. HTTP est ´evolutive, robuste et est
un protocole omnipr´esent en ce moment. Mais les probl`emes est l’en-tˆete du message
est lourds.
Une ´etude de Google[7] montre que les en-tˆetes des requˆetes aujourd’hui varient en taille
d’environ 200 octets de plus de 2 Ko. Il n’est pas applicable pour les p´eriph´eriques
qui n´ecessitent tr`es peu d’interaction. Ils consomment tr`es peu d’´energie et souvent
disposer d’une connectivit´e r´eseau pauvres. HTTP est trop lourd pour ˆetre un bon
ajustement pour ces dispositifs. Les frais g´en´eraux HTTP ajoute ´egalement `a l’IoT
charges d’exploitation tandis que les coˆ
uts actuels de la connectivit´e sans fil sont d´ej`
a
cher.

2.2.2

CoAP - Contrainte Application Protocol, le protocole pour le
web des objets

Le Constrained Application Protocol (CoAP) [RFC 7252] est un web protocole sp´ecialis´e
pour transfert pour une utilisation avec des nœuds contraints et r´eseaux contraints `
a
l’internet des objets. Comme HTTP, CoAP est bas´ee sur le succ`es de REST [8](de
Representational State Transfer): serveurs fournir des ressources sous une URL, et les

Chapter 2. Context

5

clients ont acc`es `
a ces ressources en utilisant des m´ethodes telles que GET, PUT, POST
et DELETE.
CoAP est con¸cue pour interfacer ais´ement avec HTTP pour l’int´egration avec le Web
tout en r´epondant aux besoins sp´ecialis´es comme support multicast, tr`es peu de frais
g´en´eraux, et la simplicit´e pour environnements contraints. CoAP peut transporter
diff´erents types de charges utiles, et peut identifier le type de donn´ees sont utilis´e.
1

Figure 2.1: Protocole CoAP activer les services Web en int´egrant `a l’architecture
Web et HTTP 2

Sur ce sch´ema, lorsque le client veut acc´eder (lecture / ´ecriture) le resouce, il peut
utiliser une application envoyer demande via URI de la ressource disponible. Diff´erent
entre HTTP et CoAP est un est la base sur TCP, l’autre base sur UDP.

Figure 2.2: CoAP diagramme

Un exemple d’utiliser firefox Copper add-on avec l’URI ”coap://vs0.inf.ethz.ch:5683/path”
1

Source: 04 01 archive.html


Chapter 2. Context

Figure 2.3:

6

Un acc`es web demande l’utilisation de CoAP exemple `a l’aide de
ressources `a distance via URI

Un autre ´el´ement int´eressant avec le protocole CoAP est ressource observant que
signifie lorsque le client CoAP inscrire son int´erˆet dans une ressource. Il va d’abord
obtenir l’´etat actuel de la ressource (si disponible). Apr`es que le client recevra les
notifications sur les modifications tant que le serveur peut d´eterminer l’int´erˆet continu du
client dans la ressource. L’image ci-dessous montre un exemple d’un client CoAP inscrire
son int´erˆet dans une ressource et recevoir les notifications de trois: le premier moment
de l’inscription `
a l’´etat actuel, puis deux sur les changements `a l’´etat des ressources.
2

Figure 2.4: Observer ressources dans CoAP.3

En comparaison avec le protocole HTTP, COAP est plus efficace, car il permet de r´eduire
la taille de l’en-tˆete. Comme RFC 7252, un message vide ne contient que la tˆete de 4
2

source: />

Chapter 2. Context

7

octets. Il est capable (con¸cu) pour travailler sur des microcontrˆoleurs avec aussi peu

que 10 Kio de RAM et 100 KiB de l’espace de code [RFC 7228]. La s´ecurit´e est assur´ee
par la DTLS (de Datagram Transport Layer Security) [RFC 4347] couche pour soutenir
l’UDP fiable dans l’architecture abstraite.

Figure 2.5: un message CoAP avec l’en-tˆete seulement 4 octets (en-tˆete, option,
donn´ee). la source RFC 7252

CoAP a ´et´e largement mis en œuvre jusqu’`a pr´esent. Il existe des biblioth`eques disponibles
pour C, C ++, Java et Python. Nous pouvons ´egalement trouver les biblioth`eques CoAP
dans Syst`emes d’exploitation embarqu´es ouverts avec le soutien 6LoWPAN pour capteurs (par exemple Contiki OS, TinyOS).
En conclusion, nous voyons que le protocole est con¸cu pour CoAP r´eseau de contrainte,
son sch´ema est capable pour les objets qui ont des faible performance avec connexion
`a faible coˆ
ut mais ils peut assurer que la base de la s´ecurit´e sur DTSL. Le message de
transmission fiable pour tenir le client au courant des modifications sur le serveur tant
que le registre des clients de la ressource int´eressante et serveur peut d´eterminer laquelle
des int´erˆets du client dans la ressource. Performance, fiabilit´e et largement mis en œuvre
en font un bon candidat pour le protocole de l’IoT.

2.2.3

Message Queuing Telemetry Transport

Message Queuing Telemetry Transport Protocol (MQTT) est une publication / abonnement protocole de messagerie con¸cu pour les communications M2M l´egers. Il a ´et´e
cr´e´e par IBM & Eurotech et remis `a Eclipse projet ”Paho” M2M (standard OASIS en
2014).
Dans ce sch´ema, Publisher (capteurs, appareils) publient un message avec le sujet
sp´ecifique au serveur. Un ´editeur (publisher) peut publier plusieurs sujet vers serveur
(exemple temp´erature, lumi`ere ...) et l’abonn´e peut choisir le sujet qu’ils veulent obtenir.

Chapter 2. Context

8

Figure 2.6: MQTT sch´ema, Publisher et abonn´e

MQTT est tr`es l´eger, le plus petite taille d’un paquet est seulement 2 octets (en-tˆete) et
ainsi adapt´e pour les communications M2M (mobile `a mobile), WSN (Wireless Sensor
Networks).

Figure 2.7: Format d’un message MQTT

En MQTT, QoS est responsable pour les donn´ees fiables. Le souscripteur et l’´editeur
peuvent d´efinir leur propre niveau de QoS quand publier et souscrire `a un sujet. La
qualit´e de service d’un message transmis `a un abonn´e peut donc ˆetre diff´erent pour les
donn´ees de qualit´e de service pour le message d’origine par l’´editeur. Le plus petite des
deux valeurs est utilis´ee pour transmettre un message.
Trois niveaux de QoS sont:

• QoS0, au plus une fois: Le message est remis au plus une fois, ou il ne peut
pas ˆetre livr´e `
a tous. Sa livraison sur le r´eseau est pas reconnu. Le message ne
sont pas stock´ees. Le message pourrait ˆetre perdu si le client est d´econnect´e, ou
si le serveur tombe en panne. QoS0 est le mode le plus rapide de transfert. Il est
parfois appel´e ”tire et oublie” (”fire and forget”).


Chapter 2. Context

9

Figure 2.8: MQTT Qos = 0, un message sera envoy´e au plus un fois

• QoS1, Au moins une fois: Le message est toujours livr´e au moins une fois. Il peut
ˆetre d´elivr´e plusieurs fois si une d´efaillance avant un accus´e de r´eception est re¸cu
par l’´emetteur. Le message doit ˆetre stock´e localement au niveau de l’´emetteur,
jusqu’`
a ce que l’exp´editeur re¸coit une confirmation que le message a ´et´e publi´ee
par le r´ecepteur. Le message est m´emoris´e dans le cas o`
u le message doit ˆetre
envoy´e `
a nouveau.

Figure 2.9: MQTT Qos = 1, un message sera envoy´e au moins une fois

• QoS2, Exactement une fois: Le message est toujours livr´e exactement une fois.
Le message doit ˆetre stock´e localement au niveau de l’´emetteur, jusqu’`a ce que
l’exp´editeur re¸coit une confirmation que le message a ´et´e publi´ee par le r´ecepteur.
Le message est m´emoris´e dans le cas o`
u le message doit ˆetre envoy´e `a nouveau.
QdS2 est le mode de transfert le plus sˆ
ur, mais plus lent. Une s´equence de prise


Chapter 2. Context

10

de contact et de reconnaissance plus sophistiqu´e est utilis´e que pour QoS1 `a ´eviter

la duplication des messages se produit.

Figure 2.10: MQTT Qos = 2, un message sera envoy´e exactement une fois

Un probl`eme commun `
a tous les protocole IoT est la s´ecurit´e. MQTT est bas´e sur TCP,
et utiliser la connexion SSL / TSL. Il fournit ´egalement la s´ecurit´e dans le cadre `a l’aide
de nom d’utilisateur et mot de passe et le cryptage de la charge utile.
Une autre caract´eristiques de l’avance de MQTT est de garder en vie un message
(courtier peut d´etecter connexion du client), retain (message publi´e est maintenue sur
courtier un nouvel abonn´e sur le sujet re¸coit le ”dernier-savoir” bon message).
Mˆeme sc´enario avec CoAP (client communiquer avec le serveur de l’infrastructure),
mais sur le sc´enario MQTT, capteurs (appareils) est de plus d’initiative, car ils peuvent
d´ecider quand il est n´ecessaire de publier des donn´ees. Petite tˆete est ´egalement un
avantage. Plus le niveau de s´ecurit´e QoS flexible et fiable assurer. Il est pas difficile de
trouver une mise en œuvre de MQTT, il ya certains projets comme HiveMQ, mqtt ou
mosquitto.

2.2.4

Quel est le meilleur protocole?

Il ya beaucoup de protocole pour l’IoT mais le meilleur protocole pour tous les sc´enarios
ne sont pas existent. Le choix du protocole d´epend au sc´enario. Certains protocoles ont
plus de fonctionnalit´es que les autres, mais n’est pas capables pour le projet ne peut pas


Chapter 2. Context

11

ˆetre un bon choix. Un syst`eme complexe peut utiliser plusieurs protocoles de profiter
de leurs avantages. Plusieurs standard peut ˆetre utilis´e pour ´evaluer protocole que la
performance, robuste, scalaire, la s´ecurit´e, mais toujours besoin d’´equilibre entre des
exigences et des performances de l’appareil.
HTTP est robuste, omnipr´esent mais tr`es lourd pour les appareils `a faible rendement.
CoAP est con¸cu pour le r´eseau de contrainte avec bouteille, s´ecurit´e et facilement applicable `
a http application, mais le mod`ele REST lorsque les capteurs sont g´en´eralement
serveur ne semble pas efficace comme ils ont besoin pour traiter la demande et la r´eponse.
MQTT est mieux en comparaison avec CoAP, car son en-tˆete est plus petit mais fiable
en raison de la QoS. Le cryptage des donn´ees assurer que les informations sont en
s´ecurit´e. Publier / Souscrire (publish/subscribe) mod`ele permet `a chaque utilisation de
l’appareil seulement leur propre tˆache (publier ou de souscription). Client ne dispose
pas d’envoyer la demande `
a des capteurs pour r´ecup´erer les donn´ees. Ce syst`eme permet
d’´eviter probl`eme potentiel.
Dans ce projet, nous utilisons mosquitto 3 , une impl´ementation l´eg`ere de MQTT. Nous
choisissons mosquitto grˆ
ace-aux performances et exp´eriences quand derier projet montrent qu’il peut s’adapter au projet en cours. Un serveur de courtier MQTT est mis
en œuvre par Cosmiqo. Le serveur est d´eploy´e dans le num´erique Digital Ocean Cloud
(r´egion de Singapour)

4

avec 1 Giga octets de m´emoire, 1 Core, 30 Giga octets SSD,

disque dure est 2 To de transfert et Centos 64bits install´e. Ce serveur est disponible
pour se connecter, le message avant de l’abonn´e et installer contrˆoleur de liaison ainsi.

3

4

/> />

Chapter 3

D´
eveloppement
Sur cette partie, nous allons pr´esenter le processus de d´eveloppement, les exigences sur
le mat´eriel et les logiciels, biblioth`eques utilis´ees avec des difficult´es et comment r´esoudre
ces probl`emes.

3.0.5

Equipement

L’exigences de clients est la mesure de la lumi`ere, donc nous avons choisi d’utiliser
le capteur de lumi`ere. Un GPS pour d´eterminer l’emplacement des donn´ees recueillies. Acc´el´erom`etre capteur est ´egalement utilis´e pour aider `a d´eterminer l’emplacement
lorsque le signal GPS n’est pas bon.
Tous les capteurs reli´es par le fil par l’interm´ediaire des PIN’S de la BBB. Le but principal
de ce fil est la transmission d’alimentation et de donn´ees. BBB recueillir des donn´ees, et
pr´e-traitement et envoy´e au serveur en utilisant la connexion 3G grˆace `a la 3G dongle
USB qui ont Singtel SIM carte avec la connecxion 3G.
La puissance d’energie est 5V pour BBB. Nous pouvons brancher le cˆable USB `
a
l’ordinateur portable ou utiliser une pile sp´ecifique avec sortie 5V.

3.0.5.1

Mat´

eriel n´
ecessaire

• Beagle Bone Black (Rev C)

12


Chapter 3. D´eveloppement

13

Figure 3.1: BeagleBone Black

”BeagleBone Black” est `
a bas prix, avoir un grand communit´e d’aides. Boot Linux
en moins de 10 secondes et se lancer sur le d´eveloppement en moins de 5 minutes
avec juste un simple cˆ
able USB. Il fonctionne comme un ordinateur, mais avoir
le port de connexion et de communication avec des capteurs. Comme il a besoin
l’entr´ee d’energie est 5V seulement, il est facile d’ex´ecuter BBB avec la batterie.
• Capteur de la lumi`
ere (BH1750)
BH1750 est un capteur num´erique de la lumi`ere, qui est un capteur de lumi`ere
ambiante pour I2C interface de bus num´erique. Il est possible de d´etecter large
gamme `
a haute r´esolution.

Figure 3.2: Capteur de lumi`ere (BH1750)

Plan de client pour r´epartir les capteurs de lumi`ere le long de la voiture, car il
donnera un des r´esultats impartiaux sur luminance.


Chapter 3. D´eveloppement

14

Figure 3.3: Les capteurs de lumi`ere sont r´epartis le long de la voiture

• Inertial Measurement Unit (LSM303D)
Le LSM303D combine un acc´el´erom`etre 3 axes et num´erique 3 axes magn´etom`etre
dans un package unique qui est id´eal pour faire une boussole avec compensation
d’inclinaison. Ce dispositif nous permet d’obtenir le changement de direction de
voiture et aussi aider `
a interpoler position dans un certain dispositif lieu GPS ne
peuvent pas obtenir le signal

Figure 3.4: Inertial Measurement Unit (LSM303D)

Acc´
el´
erom`
etre
Entr´ee de l’acc´el´erom`etre est rendu dans deux param`etres d’entr´ee: direction et
acc´el´eration. A partir de ces param`etres, nous pouvons connaˆıtre l’´etat de la
voiture (direction et sa vitesse). Et lorsque le GPS ne peut pas obtenir assez de
signal du satellite pour d´eterminer la position, nous pouvons utiliser la position
derri`ere-savoir (last-know) avec la participation de l’acc´el´erom`etre pour interpoler
la position de bus.

Chapter 3. D´eveloppement

15

Figure 3.5: Acc´el´erom`etre

• Syst`
eme de positionnement global (GPS)
Module EM-506 GPS est propuls´e par SiRF Star IV, il peut fournir avec une sensibilit´e sup´erieure et des performances encore en canyon urbain et de l’environnement
de feuillage dense. Il peut donner les positions avec un grande pr´ecision.

Figure 3.6: R´ecepteur GPS (EM506)

”GPS shield” aider `
a connecter capteur GPS avec BBB par les fils. Avant de
lancer, v´erifiez si le bouton situ´e sur le ”GPS shield” est r´egl´e sur ON, sinon nous
ne pouvons pas lire les donn´ees de module GPS.

Figure 3.7: GPS shield

• Cˆ
ables et fils


Chapter 3. D´eveloppement

16

Sur ce projet, nous utilisons les fils pour alimenter des capteurs via BBB et transferer les donn´ees.

Figure 3.8: Cˆables et fils

• USB 3G modem Sur ce projet, nous utilisons Huawei modem SingTel et SingTel
SIM carte avec le plan 3G pour fournir une connexion pour le transfert de donn´ees.
Pour utiliser ce dispositif, nous devons installer ppp et usb modeswtich sur le
syst`eme Archlinux dans le BBB.
pacman -S ppp usb_m odeswit ch

Figure 3.9: USB modem avex 3G simcard fournir une connexion `a Beagle Bone Black

Pin connection pour le BBB, BH1750, LSM303D, EM506

Beagle Bone Black :: PIN 1 ( GND )

<---> BH1750 (2):: GND

Beagle Bone Black :: PIN 3 (3.3 V ) <---> BH1750 (2):: VCC
Beagle Bone Black :: PIN 17 ( i2c -2 SCL ) <---> BH1750 (2):: SCL
Beagle Bone Black :: PIN 18 ( i2c -2 SDA ) <---> BH1750 (2):: SDA
BH1750 (2):: AD0 <---> BH1750 (2):: GND

LSM303D :: GND <---> BH1750 (1):: GND
LSM303D :: VCC <---> BH1750 (1):: VCC
LSM303D :: SCL <---> BH1750 (1):: SCL
LSM303D :: SDA <---> BH1750 (1):: SDA