• Aucun résultat trouvé

2020 — Étude comparative de cadriciels libres pour le développement d'applications IoT

N/A
N/A
Protected

Academic year: 2021

Partager "2020 — Étude comparative de cadriciels libres pour le développement d'applications IoT"

Copied!
172
0
0

Texte intégral

(1)

par

Zeineb BABA CHEIKH

MÉMOIRE PRÉSENTÉ À L’ÉCOLE DE TECHNOLOGIE SUPÉRIEURE

COMME EXIGENCE PARTIELLE À L’OBTENTION DE LA MAÎTRISE

AVEC MÉMOIRE EN GÉNIE, CONCENTRATION GÉNIE LOGICIEL

M. Sc. A.

MONTRÉAL, LE 11 JUIN 2020

ÉCOLE DE TECHNOLOGIE SUPÉRIEURE

UNIVERSITÉ DU QUÉBEC

(2)
(3)

PAR UN JURY COMPOSÉ DE:

Mme Ghizlane EL BOUSSAIDI, directeur de mémoire

Département de génie logiciel et des TI, École de technologie supérieure

M. Julien GASCON-SAMSON, co-directeur

Département de génie logiciel et des TI, École de technologie supérieure

M. Francis BORDELEAU, président du jury

Département de génie logiciel et des TI, École de technologie supérieure

M. Sègla KPODJEDO, membre du jury

Département de génie logiciel et des TI, École de technologie supérieure

IL A FAIT L’OBJET D’UNE SOUTENANCE DEVANT JURY ET PUBLIC LE 05 JUIN 2020

(4)
(5)

ce mémoire.

Je voudrais en premier lieu remercier les membres du jury d’avoir accepté de juger mon modeste travail.

Je remercie très chaleureusement mon encadrante Mme Ghizlane EL-BOUSSAIDI pour sa disponibilité et son écoute, la qualité d’encadrement et ses conseils précieux. Je remercie également mon co-directeur M. Julien GASCON-SAMSON, pour l’encadrement et les conseils. Je désire aussi remercier l’organisme MITACS pour m’avoir offert une telle opportunité de poursuivre les études supérieures au Canada, dans une école prestigieuse, et avec une meilleure qualité d’enseignement, telle que l’École de Technologies Supérieures. Je remercie ainsi le cadre administratif et enseignant de l’ÉTS. J’adresse aussi mes sincères mots de gratitude à tous les professeurs qui ont contribué à ma formation tant en Tunisie qu’au Canada.

Je voudrais aussi remercier ma famille : mon père Jalel, ma mère Sabeh, ma soeur Maryem, son époux Achref et leur petit bout de choux attendu. Merci également à ma chère Fatma de m’avoir tendu la main dans les moments les plus difficiles.

(6)
(7)

RÉSUMÉ

Le marché de l’Internet des objets (IoT) se développe rapidement avec un nombre croissant d’appareils connectés. Cela a conduit de nombreuses entreprises à se concentrer sur le dévelop-pement et la recherche de solutions IoT. Le dévelopdévelop-pement de l’IoT a ses propres défis. En effet, les solutions IoT typiques sont composées d’objets, de protocoles et de logiciels hétérogènes. Pour relever ces défis, de nombreux frameworks sont disponibles pour aider les développeurs à créer des applications IoT. Certains de ces frameworks sont open source et pourraient être d’un grand intérêt pour les petites et moyennes entreprises souhaitant créer des solutions IoT à moindre coût. Dans ce mémoire, nous présentons les résultats d’une étude expérimentale sur des frameworks de développement IoT open source. En particulier, nous avons utilisé ces frameworks pour déployer un échantillon de trois applications IoT et nous les analysons par rapport à un ensemble minimal d’exigences fonctionnelles et non fonctionnelles en IoT. Nous nous concentrons dans notre étude sur le développement IoT pour Raspberry PI, car c’est une plate-forme très populaire et très peu coûteuse.

Mots-clés: internet des objets, framework de développement IoT open source, applications IoT,

(8)
(9)

ABSTRACT

The Internet of Things (IoT) market is growing fast with an in-creasing number of connected devices. This led many software companies to shift their focus to develop and provide IoT solutions. IoT development has its own challenges as typical IoT solutions are composed of heterogeneous devices, protocols and software. To cope with these challenges, many frameworks are available to help developers to build IoT applications. Some of these frameworks are open source and might be of great interest for small and medium-sized companies wishing to build IoT solutions at a lower cost. In this thesis, we present the results of our study of open source IoT development frameworks. In particular, we used these frameworks to implement a sample of three IoT applications and we analyze them against a minimal set of IoT requirements.We focus in our study on the IoT development for Raspberry PI as it is a very low-cost and popular platform.

Keywords: internet of things, open source IoT development frameworks, IoT applications,

(10)
(11)

INTRODUCTION . . . .1

CHAPITRE 1 REVUE DE LITTÉRATURE . . . 7

1.1 Définitions des concepts clés . . . 7

1.1.1 Qu’est-ce que l’IoT . . . 7

1.1.2 Quels sont les composants d’une application IoT ? . . . 9

1.1.3 Qu’est-ce qu’un framework en IoT ? . . . 10

1.1.4 Qu’est-ce qu’une plate-forme en IoT ? . . . 11

1.2 Domaines d’utilisation de l’IoT . . . 11

1.3 Exigences et caractéristiques des applications IoT . . . 12

1.3.1 Besoins fonctionnels . . . 13

1.3.2 Besoins non fonctionnels . . . 13

1.3.3 Caractéristiques et exigences selon le standard ISO-RA . . . 14

1.3.4 Défis reliés aux applications IoT . . . 16

1.4 Technologies supportant les applications IoT . . . 16

1.4.1 Technologies de communication . . . 17

1.4.2 Protocoles de communication IoT . . . 19

1.5 Architectures des applications IoT . . . 21

1.5.1 Survol rapide des architectures décrites dans la littérature . . . 21

1.5.2 L’architecture de référence ISO . . . 25

1.6 Revue des travaux portant sur les frameworks et plates-formes IoT . . . 29

1.6.1 Travaux faisant un survol des frameworks et plates-formes en IoT . . . 29

1.6.2 Études comparatives des frameworks et plates-formes en IoT . . . 34

1.6.2.1 Étude comparative des plates-formes Cloud . . . 34

1.6.2.2 Étude comparative des frameworks IoT basée sur des aspects architecturaux . . . 37

1.6.2.3 Cadre d’évaluation des plates-formes IoT . . . 38

1.7 Conclusion . . . 41

CHAPITRE 2 DÉFINITION DE L’ÉTUDE EXPÉRIMENTALE . . . 43

2.1 Questions de recherche . . . 43

2.2 Choix des frameworks . . . 44

2.3 Choix des applications IoT à implémenter . . . 44

2.4 Choix de la plate-forme matérielle . . . 45

2.5 Caractéristiques des applications IoT . . . 46

CHAPITRE 3 RÉALISATION DES EXPÉRIMENTATIONS ET COLLECTE DE DONNÉES . . . 51

3.1 Eclipse Vorto . . . 51

(12)

3.1.2 Implémentation du système de gestion d’inventaire . . . 55

3.1.3 Implémentation du système de surveillance météorologique . . . 56

3.1.4 Implémentation du système de chauffage intelligent . . . 57

3.2 ThingML . . . 58

3.2.1 Présentation générale du framework . . . 58

3.2.2 Implémentation du système de gestion d’inventaire . . . 60

3.2.3 Implémentation du système de surveillance météorologique . . . 61

3.2.4 Implémentation du système de chauffage intelligent . . . 63

3.3 Node-Red . . . 67

3.3.1 Présentation générale du framework . . . 67

3.3.2 Implémentation du système de gestion d’inventaire . . . 69

3.3.3 Implémentation du système de surveillance météorologique . . . 73

3.3.4 Implémentation du système de chauffage intelligent . . . 75

3.4 OpenHab . . . 78

3.4.1 Présentation générale du framework . . . 78

3.4.2 Implémentation du système de gestion d’inventaire . . . 81

3.4.3 Implémentation du système de surveillance météorologique . . . 81

3.4.4 Implémentation du système de chauffage intelligent . . . 83

3.5 Eclipse Kura . . . 85

3.5.1 Présentation générale du framework . . . 85

3.5.2 Implémentation du système de gestion d’inventaire . . . 88

3.5.3 implémentation du système de surveillance météorologique . . . 88

3.5.4 Implémentation du système de chauffage intelligent . . . 90

CHAPITRE 4 ANALYSE DES RÉSULTATS EXPÉRIMENTAUX . . . 91

4.1 QR1 : Jusqu’à quel degré un framework open source supporte le développement des applications IoT ? . . . 91

4.1.1 Eclipse Vorto . . . 91

4.1.2 ThingML . . . 93

4.1.2.1 Implémentation du système de gestion d’inventaire . . . 95

4.1.2.2 Implémentation du système de surveillance météorologique 96 4.1.2.3 Implémentation du système de chauffage intelligent . . . 96

4.1.3 Node-Red . . . 97

4.1.3.1 Implémentation du système de gestion d’inventaire . . . 97

4.1.3.2 Implémentation du système de surveillance météorologique 98 4.1.3.3 Implémentation du système de chauffage intelligent . . . 98

4.1.4 OpenHab . . . 98

4.1.4.1 Implémentation du système de surveillance météorologique 99 4.1.4.2 Implémentation du système de chauffage intelligent . . . 99

(13)

4.1.6 Sommaire de l’évaluation du support des frameworks étudiés . . . .100

4.2 QR2 : Jusqu’à quel degré un framework open source supporte un ensemble minimal d’exigences fonctionnelles et non fonctionnelles des applications IoT ? . . . .100

4.2.1 Analyse selon les exigences IoT . . . .100

4.2.2 Analyse par framework . . . .103

4.2.2.1 Eclipse Vorto . . . .104

4.2.2.2 ThingML . . . .106

4.2.2.3 Node-Red . . . 107

4.2.2.4 OpenHab . . . 111

4.2.2.5 Eclipse Kura . . . .113

CHAPITRE 5 SYNTHÈSE DES RÉSULTATS ET LIMITES DE L’ÉTUDE . . . 117

5.1 Synthèse des résultats . . . 117

5.2 Limites de l’étude . . . .119

5.2.1 Validité externe des résultats de l’étude . . . .119

5.2.2 Validité interne des résultats de l’étude . . . .120

CONCLUSION ET TRAVAUX FUTURS . . . .123

ANNEXE I SPÉCIFICATIONS TECHNIQUES DU MATÉRIEL UTILISÉ . . . .125

ANNEXE II TABLEAU DES CARACTÉRISTIQUES DE L’ARCHITECTURE D’UN SYSTÈME IOT SELON (ISO, 2018) . . . 127

ANNEXE III TABLEAU DES CARACTÉRISTIQUES FONCTIONNELLES DE L’IOT SELON (ISO, 2018) . . . .129

ANNEXE IV FONCTION C - LECTURE DES IDENTIFIANTS DE TAGS RFID . . . 131

ANNEXE V FONCTION C - LECTURE DE TEMPÉRATURE . . . .133

ANNEXE VI PROCÉDURE DE SÉCURISATION DE NODE-RED . . . 137

(14)
(15)

Tableau 1.1 Éléments d’un système IoT, selon (Rahman, Ozcelebi & Lukkien,

2016) . . . 10

Tableau 1.2 Fonctionnalités d’un système IoT, selon (Rahman et al., 2016) . . . 13

Tableau 1.3 Besoins non fonctionnels en IoT selon (Rahman et al., 2016) . . . 14

Tableau 1.4 Caractéristiques de fiabilité du système IoT . . . 15

Tableau 1.5 Listes des frameworks et plates-formes IoT par espace d’application . . . 32

Tableau 1.6 Catégorisation des frameworks et plates-formes par protocole supporté . . . 33

Tableau 1.7 Catégorisation des frameworks et plates-formes par couche . . . 33

Tableau 1.8 Critères de sélection des plates-formes . . . 35

Tableau 1.9 Description des rôles des modules principaux d’une plate-forme IoT . . . 39

Tableau 2.1 Les applications IoT sélectionnées par catégorie . . . 45

Tableau 4.1 Le support fourni par les frameworks pour l’implémentation des exemples d’applications choisis. . . .100

Tableau 4.2 Évaluation des frameworks étudiés selon notre liste d’exigences . . . 101

Tableau 4.3 Degré de support des exigences prises en charge par Eclipse Vorto . . . .104

Tableau 4.4 Degré de support des exigences prises en charge par ThingML . . . .106

Tableau 4.5 Degré de support des exigences prises en charge par Node-Red . . . .108

Tableau 4.6 Degré de support des exigences prises en charge par OpenHab . . . 111

(16)
(17)

Figure 0.1 Phases de la méthodologie. . . 4

Figure 1.1 Illustration du protocole MQTT, adapté de (Hermanudin, Ekadiyanto & Sari, 2019). . . 21

Figure 1.2 Architecture en couches, adaptée de (Vashi, Ram, Modi, Verma & Prakash, 2017). . . 22

Figure 1.3 Architectures en couches en IoT, adaptée de (Muccini & Moghaddam, 2018). . . 23

Figure 1.4 Modèle conceptuel de l’IoT, extrait de (ISO, 2018). . . 26

Figure 1.5 Modèle de référence basé sur les entités, extrait de (ISO, 2018). . . 27

Figure 1.6 Modèle de référence basé sur les domaines, extrait de (ISO, 2018). . . 28

Figure 1.7 Relation entre le modèle de référence basé sur les domaines et le modèle de référence basé sur les entités, extrait de (ISO, 2018). . . 30

Figure 1.8 Les modules d’une plate-forme IoT, extrait de (Salami & Yari, 2018). . . 39

Figure 1.9 Processus d’évaluation des plates-formes IoT, extrait de (Salami & Yari, 2018).. . . 40

Figure 1.10 Critères de comparaison des plates-formes IoT, extrait de (Salami & Yari, 2018).. . . 41

Figure 2.1 Montage expérimental . . . 47

Figure 3.1 Les différents éléments d’Eclipse Vorto et leurs interactions avec l’écosystème IoT, extrait de (Wagner, Laverman, Grewe & Schildt, 2016). . . 52

Figure 3.2 Les composants du DSL de Vorto. . . 53

Figure 3.3 InformationModel et FunctionBlock relatifs au lecteur de tags RFID . . . 55

Figure 3.4 L’infomodel et functionBlock du capteur de température DHT11. . . 56

(18)

Figure 3.6 Diagramme d’état HelloWorld de l’objet HelloThing . . . 59

Figure 3.7 Code ThingML de l’exemple HelloWorld . . . 60

Figure 3.8 Spécification du Lecteur de Tags RFID en utilisant ThingML . . . 61

Figure 3.9 Fichier ThingML représentant le capteur DHT11 . . . 62

Figure 3.10 Diagramme d’état du Thing SenseC relatif au capteur de température DHT11 . . . 63

Figure 3.11 Code thingML relatif aux fonctions définies pour implémenter l’application du chauffage intelligent . . . 64

Figure 3.12 Code ThingML relatif au diagramme d’état PiSenseC du thing SenseC . . . 65

Figure 3.13 Code thingML relatif à la LED. . . 65

Figure 3.14 Extrait de code thingML relatif à la configuration du DHT11 et de la LED . . . 66

Figure 3.15 Diagramme d’état du Heater . . . 67

Figure 3.16 Définition du protocole MQTT avec ThingML. . . 67

Figure 3.17 Éditeur de flux de Node-Red . . . 68

Figure 3.18 Identification de l’ID du lecteur de tags RFID . . . 69

Figure 3.19 Flux de données relatif à la lecture des tags RFID . . . 69

Figure 3.20 Configuration du nœud HIDdevice. . . 70

Figure 3.21 Fonction Select ID part . . . 70

Figure 3.22 Nœud FilterDigit . . . 71

Figure 3.23 Fonction Translate Bits . . . 71

Figure 3.24 Nœud Join ID Bytes . . . 72

Figure 3.25 Les tags RFID utilisés pour l’expérimentation . . . 72

Figure 3.26 Résultat du test du flux final . . . 73

(19)

Figure 3.28 Courriel reçu automatiquement depuis Node-Red . . . 74

Figure 3.29 Affichage graphique de la Température via l’outil graphique . . . 75

Figure 3.30 Flux de données entre le capteur DHT11 et la lampe LED lorsque connectés sur la même Raspberry Pi. . . 76

Figure 3.31 propriétés du nœud "MQTT in" . . . 76

Figure 3.32 Propriétés du nœud "MQTT out" . . . 77

Figure 3.33 Flux de données de l’objet DHT11 dans le cas des objets distribués . . . 77

Figure 3.34 Flux de données de l’objet LED dans le cas des objets distribués . . . 78

Figure 3.35 Interface graphique de OpenHab . . . 81

Figure 3.36 Application mobile de OpenHab . . . 81

Figure 3.37 Extrait du fichier DHT11.things pour le système de surveillance météo . . . 82

Figure 3.38 Extrait du fichier DHT11.items pour le système de surveillance météo . . . 82

Figure 3.39 Extrait du fichier DHT11.sitemap pour le système de surveillance météo . . . 82

Figure 3.40 Exécution du script python pour la lecture de Température et d’Humidité via DHT11 . . . 83

Figure 3.41 Extrait du fichier DHT11.things pour le système de chauffage intelligent . . . 84

Figure 3.42 Extrait du fichier DHT11.items pour le système de chauffage intelligent . . . 84

Figure 3.43 Extrait du fichier Heater.rules . . . 84

Figure 3.44 Extrait du fichier Heater.sitemap . . . 85

Figure 3.45 Services offerts par Eclipse Kura, extrait de (Kura, 2019) . . . 86

Figure 3.46 Éditeur de flux de données de Eclipse Kura . . . 87

Figure 3.47 Flux graphique réalisé avec Kura . . . 88

(20)

Figure 3.49 Configuration du Publisher . . . 89

Figure 3.50 Publication des valeurs configurées et de la température mesurée sur la Raspberry Pi . . . 90

Figure 4.1 Extrait du code généré par Vorto pour la FunctionBlock décrivant le DHT11 . . . 92

Figure 4.2 Exemples d’erreurs de compilation apparu à l’exécution du programme ThingML . . . 94

Figure 4.3 Hyperterminal "Gtkterm" pour la réalisation de l’application de la 1ère catégorie . . . 95

Figure 4.4 Résultats des mesures de la température avec ThingML . . . 96

Figure 4.5 Noeuds de Node-Red pour la gestion des connexions via le port USB . . . 97

Figure 4.6 Reposoir des objets de Vorto . . . .105

Figure 4.7 Méthode d’authentification au reposoir de Vorto. . . .105

Figure 4.8 Palette de noeuds offerts pour le cryptage/décryptage avec Node-Red . . . .109

Figure 4.9 Installation des noeuds de cryptage/décryptage à partir de l’interface de Node-Red . . . .109

Figure 4.10 Installation manuelle des noeuds de cryptage/décryptage avec Node-Red . . . .109

(21)

API interface de programmation applicative

APNS Apple Push Notification service

AwS Amazon Web Services

CISCO Computer Information System COmpany

CoAP Constrained Application Protocol

COTS Commercial off-the-shelf

CRM Customer Relationship Management

DSaaS Data Storage as a Service

DSL Domain Specific Language

DSML Domain Specific Modeling Language

EMF Eclipse Modeling Framework

GCM Google Cloud Messaging

GPIO General Purpose Input/Output

HART Highway Addressable Remote Transducer

HTTP Hypertext Transfer Protocol

IaaS Interface as a Service

IBM International Business Machines

ICN Information Centric Networking

IdO Internet des Objets

IEC International Electrotechnical Commission

IHM Intefrave Homme Machine

(22)

IoNT Internet of Nano Things

IoT Internet of Things

IP Internet Protocol

IPv4 Internet Protocol version 4

IPv6 Internet Protocol version 6

ISO International Organization for Standardization (Organisation internationale de normalisation)

ISO-RA International Organization for Standardization-Reference Architecture

JSON JavaScript Object Notation

LED Lampe Électroluminescente

LPDDR2 Low Power Double Data Rate 2

LTE Long-Term Evolution

LTE-A Long-Term Evolution -Advanced

M2M Machine to Machine

MPNS Microsoft Push Notification Services

MQTT Message Queuing Telemetry Transport

NFC Near Field Communication

OC Optical Code

OSGI Open Services Gateway initiative

OSI Open Systems Interconnexion

P2M Person to Machine

P2P Person to Person

PaaS Platform as a Service

Pub/Sub Publish/Suscribe

(23)

REST Representational state transfer

RFID Radio-frequency identification

SaaS Software as a Service

SDK Software Development Kit

SDRAM Synchronous Dynamic Random Access Memory

SEP 2.0 Smart Energy Profile 2.0

SMS Short Message Service

SOA Service Oriented Architecture

SSL Secure Sockets Layer

TCP Transmission Control Protocol

TI Technologie de l’Information

TLS Transport Layer Security

TSaaS TSimulus As A Service

UDP User Datagram Protocol

UML Unified Modeling Language

UMTS Universal Mobile Telecommunications System

USB Universal Serial Bus

WAN Wide Area Network

WiFi Wireless Fidelity

WSN Wireless sensor network

XML Extensible Markup Language

(24)
(25)

L’Internet des objets (IoT) est un réseau qui interconnecte un nombre énorme de dispositifs physiques (ISO, 2018). Ces objets appartiennent généralement à l’une des deux catégories : les capteurs, qui collectent les données du monde physique, et les actuateurs, qui agissent selon la situation afin de modifier l’état du monde physique. Le paysage de l’IoT s’est développé à un rythme considérable au cours des dernières années. Selon des études et rapports industriels récents, 20.6 milliards d’objets sont désormais connectés selon (Ericsson, 2018) et 5 quintillions d’octets de données sont produits quotidiennement par les objets de l’IoT selon (Stack, 2018). Cette tendance a poussé les entreprises informatiques à s’orienter vers l’IoT afin de trouver les solutions appropriées aux enjeux en IoT.

En effet, et contrairement aux applications logicielles traditionnelles qui reposent sur une infrastructure traditionnelle (par exemple, des ordinateurs, des serveurs, le cloud,etc.), l’IoT repose sur l’interconnexion d’objets et services hétérogènes. À titre d’exemple, les extrémités d’une application IoT (par exemple, les capteurs) sont généralement constituées de microcontrôleurs simples, tandis que les plates-formes matérielles en IoT (Raspberry Pi, Beaglebone,etc.) sont constituées de processeurs multicore, plusieurs gigaoctets de mémoire et peuvent exécuter des systèmes d’exploitation complets. Parallèlement, l’écosystème IoT présente une haute hétérogénéité des applications ; les applications en IoT proviennent de plusieurs domaines et émanent de différentes industries. Cette panoplie exige qu’on ait les outils et les pratiques nécessaires afin de gérer efficacement la diversité logicielle et matérielle des objets et des domaines d’application en IoT.

Dans cette perspective, plusieurs cadriciels (i.e. frameworks) IoT ont été proposés pour faciliter diverses tâches reliées à la mise en oeuvre des applications IoT. Certains frameworks permettent

(26)

le développement et le déploiement des applications IoT, d’autres offrent la possibilité de gérer les applications localement ou à distance, d’autres encore permettent d’analyser les données IoT pour en tirer des décisions d’affaire. Plusieurs de ces frameworks sont open source et pourraient être d’un grand intérêt pour les petites et moyennes entreprises souhaitant investir en IoT à moindre coût. En effet, au cours des dernières décennies, les technologies reliées à l’IoT changent et évoluent très rapidement. Ceci constitue un défi pour les petites et les moyennes entreprises désirant suivre cette tendance et visant à offrir des solutions innovatrices et à moindre coût à leurs clients. Dans ce contexte, les frameworks IoT open source peuvent aider ces entreprises.

Cependant, les frameworks IoT existants ciblent différents domaines et ont différents objec-tifs offrant ainsi un support différent pour le développement des applications IoT. En effet, pour la plupart, les frameworks IoT englobent des technologies qui permettent la gestion et l’automatisation des objets connectés dans les applications IoT. Un framework IoT connecte fondamentalement un objet aux autres objets disponibles. Les frameworks diffèrent selon la façon dont ils utilisent le cloud, les options et protocles de connectivité qu’ils supportent, les mécanismes de sécurité qu’ils offrent et leur capacité de traitement des données. Du point de vue de développeurs logiciels, ces frameworks fournissent un ensemble de fonctionnalités prêtes à l’emploi qui accélèrent considérablement le développement d’applications pour les objets connectés et qui prennent en charge l’évolutivité et la compatibilité entre les différents objets. Ces fonctionalités peuvent varier d’un framework à un autre, et elles peuvent inclure, par exemple, la description des interfaces des objets connectés, leur comportement et leurs caractéristiques physiques, ou la génération automatique du code à déployer. Il peut être donc difficile pour les développeurs d’identifier le framework le plus approprié pour concevoir et implémenter une application IoT donnée. Dans ce contexte, il est nécessaire de fournir aux développeurs un moyen leur permettant d’évaluer un framework et de le sélectionner en fonction du support qu’il peut leur fournir afin de développer leurs applications IoT.

(27)

Objectifs

L’objectif général de notre projet de recherche est d’évaluer et de comparer des frameworks IoT. En particulier, nous nous concentrons sur l’évaluation du support fourni par les frameworks open source pour développer et déployer des applications IoT.

À partir de notre objectif général, nous avons identifié deux sous-objectifs :

- évaluer le support qu’offrent les frameworks open source IoT pour le développement de

différentes catégories d’applications IoT : notre objectif ici est d’analyser la capacité des frameworks étudiés à couvrir plusieurs domaines d’applications nécessitant différents types d’objets connectés ;

- évaluer le support qu’offrent des frameworks open source IoT pour satisfaire aux exigences

fonctionnelles et non fonctionnelles des applications IoT : notre objectif ici est d’analyser de façon systématique les frameworks étudiés en fonction d’un ensemble de critères ; ces derniers correspondent à un ensemble minimal d’exigences identifiées dans la littérature et des standards comme étant nécessaires pour la mise en œuvre des applications IoT.

Pour atteindre nos objectifs, nous avons réalisé une étude comparative d’un ensemble de frameworks open source IoT. Notre étude combine deux types d’analyses : 1) des analyses basées sur nos expérimentations avec ces frameworks pour implémenter différentes applications, et 2) des analyses qualitatives basées, entre autres, sur la documentation disponible de chacun des frameworks.

Méthodologie de recherche

Pour réaliser notre projet de recherche, nous avons suivi la méthodologie illustrée dans la figure 0.1

(28)

Figure 0.1 Phases de la méthodologie.

Nous avons réalisé une revue de littérature qui nous a permis de nous familiariser avec les concepts de base reliés à l’IoT et en particulier à la mise en oeuvre des applications IoT. Notre revue de littérature avait aussi pour objectif d’identifier et comprendre les exigences des applications IoT et de faire un survol des travaux existants qui se sont intéressés à l’étude des frameworks IoT. Comme montré par la figure 0.1, l’étape de revue de littérature a duré tout au long de notre projet de recherche.

Dans l’étape 1 de notre méthodologie, nous avons défini la problématique et précisé nos objectifs en fonction des résultats de notre revue de littérature et en tenant compte des limites identifiés dans l’état de l’art. Dans l’étape 2 de notre méthodologie, nous avons procédé à la réalisation de l’étude comparative des frameworks IoT en vu de réaliser nos objectifs de recherche. Conformément aux directives de (Wohlin et al., 2012), notre étude se compose de 3 étapes, numérotées 2.1, 2.2 et 2.3 dans la figure 0.1. L’étape 2.1 consiste à spécifier les objectifs de l’étude en formulant les questions auxquelles l’étude doit répondre. Cette étape définit aussi les expérimentations à réaliser pour répondre à ses questions ; elle inclut l’identification des frameworks IoT à étudier. L’étape 2.2 consiste à collecter des données en analysant les frameworks IoT sélectionnés

(29)

et en réalisant des expérimentations avec ces frameworks. Nos expérimentations impliquent l’implémentation de différentes applications IoT. L’étape 2.3 consiste à analyser les données collectées et interpréter les résultats par rapport aux questions de recherche posées.

Organisation du mémoire

Ce mémoire est organisé comme suit : le premier chapitre présente un ensemble de définitions de base ainsi qu’un état de l’art sur les travaux reliés à l’évaluation et au survol des plates-formes et frameworks IoT. Dans le deuxième chapitre, nous détaillons la première étape de notre étude en présentant la problématique et les questions de recherches auxquels nous répondons au cours de cette étude ainsi que les choix que nous avons menés au cours de notre recherche. La collecte de données à travers les expériences que nous avons faites est présentée dans le troisième chapitre. Dans le quatrième chapitre, nous analysons les données collectées et nous interprétons et discutons les résultats obtenus. Le cinquième chapitre synthétise les résultats et présente les limitations de notre recherche. Finalement, nous présentons une conclusion générale ainsi que les perspectives de ce travail dans un dernier chapitre.

(30)
(31)

Dans ce chapitre, nous présentons des définitions de concepts de l’IoT et nous faisons un survol des travaux reliés à notre projet de recherche. En particulier, nous commençons par définir les concepts Internet des objets, "framework" et "plate-forme" en IoT. Nous présentons ensuite d’autres concepts et aspects reliés tels que l’architecture des applications IoT et les technologies les supportant. Nous présentons aussi une revue des différents travaux effectués à titre d’étude et/ou évaluation des différents frameworks et plates-formes IoT existantes.

1.1 Définitions des concepts clés

1.1.1 Qu’est-ce que l’IoT

Le terme IoT, de Internet of Things, ou du français, IdO (Internet des Objets) désigne théorique-ment l’ensemble des objets intelligents, connectés sur Internet. Toutefois, dans la littérature, plusieurs définitions ont été proposées. Atzori, Iera & Morabito (2010) définissent l’IoT comme étant l’interconnexion des différents objets pour la réalisation d’une valeur ajoutée aux utilisateurs finaux. Matta, Pant & Arora (2017) définissent l’IoT comme un réseau global composé d’un ensemble d’objets connectés, ou intelligents : objets, capteurs, actuateurs, et des composants de stockage. Miraz, Ali, Excell & Picking (2015) définissent l’IoT comme étant l’ensemble des objets électroniques et électriques de différentes tailles et capacités, qui sont connectés à Internet via différentes technologies telles que ZigBee, RFID, WSNs et des technologies basées sur la localisation (par exemple, GPS). Rahman et al. (2016) définissent l’IoT comme étant un système composé d’objets à faibles ressources, faible mémoire, puissance de traitement, énergie et accessibilité. Ces objets sont connectés via des réseaux IP restreints, c’est-à-dire avec un débit binaire bas, des limites de cycle de service, une perte de paquets élevée, des liaisons asymétriques, des primitives de communication de groupe restreint, mais réunis avec des réseaux

(32)

rapides et des services internet réguliers. Ces services Internet stockent et traitent normalement de grandes quantités de données.

L’IoT offre des possibilités infinies pour des scénarios innovants, caractérisés par le fait qu’il s’agit d’applications distribuées consistant en des services de collaboration s’exécutant sur des appareils distincts. Il est difficile de développer de telles applications en termes de configuration, de programmation et de cycles de vie des entités impliquées. ISO (2018) présente l’IoT comme étant un des secteurs les plus dynamiques et excitants en technologie de l’information. Il consiste à faire connecter des entités physiques avec le monde technologique à travers le réseau internet. Les fondamentaux de l’IoT sont les appareils électroniques qui interagissent avec le monde physique. Les capteurs collectent les variables du monde physique et les actuateurs agissent. Les capteurs et les actuateurs peuvent se présenter sous plusieurs formes, telles que les thermomètres, accéléromètres, caméra vidéo, microphones, transformateurs, chauffages ou des équipements industriels pour le contrôle des procédures et de la fabrication.

Le groupe RFID définit l’IoT comme étant un réseau mondial d’objets interconnectés et adressables de manière unique en se basant sur des protocoles de communication standard. D’après le pôle de recherche européenne (Sundmaeker, Guillemin, Friess & Woelfflé, 2010), les objets sont les principaux acteurs en IoT. Ils sont des participants actifs dans les processus commerciaux, informatiques et sociaux où ils sont capables d’interagir et de communiquer entre eux et avec l’environnement pour mesurer les variables, tout en réagissant de manière autonome aux événements réels/physiques avec ou sans interaction humaine. Enfin, Bélissent et al. (2010) définissent l’IoT comme étant un environnement intelligent qui utilise les informations et les technologies de communication pour rendre l’infrastructure des secteurs de l’éducation, la santé, les services publics, le transport, l’immobilier et tout autre secteur, modernes, efficaces et interactifs. Gubbi, Buyya, Marusic & Palaniswami (2013) proposent, quant à eux, une définition centrée sur l’utilisateur de l’IoT. Selon eux, une application IoT est l’interconnexion des capteurs et des actuateurs offrant la possibilité de partager l’information sur différentes plates-formes en suivant un framework donné. Ceci inclut la mesure des données physiques, l’analyse des données, la représentation des données sur le cloud.

(33)

Dans notre étude, nous adoptons la définition la plus commune de l’IoT qu’on considère comme étant l’ensemble des objets intelligents et interconnectés à travers un réseau.

1.1.2 Quels sont les composants d’une application IoT ?

Selon (Matta et al., 2017), l’IoT se compose de : objets, capteurs, actuateurs, et des composants de stockage :

- objets : ce sont les objets équipés en électronique, ayant une capacité de calcul et une interface de communication. On peut découvrir, gérer, interagir avec et contrôler ces objets via internet. Le terme objet peut englober les appareils, les êtres humains, ou toute autre entité à laquelle on peut associer des attributs ;

- capteurs : c’est une interface essentielle pour l’implémentation en IoT, considérée comme le "frontend" de l’environnement IoT. La collecte de données des capteurs est considérée comme l’évènement stimulant toutes les activités en IoT. La nature des capteurs utilisés dépend intrinsèquement de la nature de l’application elle-même. Certains capteurs sont spécifiques à un domaine d’application bien déterminé, alors que d’autres sont adaptés à différentes applications IoT. Les capteurs sont classifiés essentiellement selon la taille des données, la fréquence d’échantillonnage, le nombre d’appareils connectés et les types de signaux associés au capteur. On peut aussi identifier les capteurs comme capteur de proximité, capteur tactile, capteur d’humidité, capteur de température, capteur de pression, accéléromètre et gyroscope ;

- actuateurs : les données collectées par les capteurs sont analysées pour prendre des décisions et déclencher les actions appropriées. Cette étape est assurée généralement par les actuateurs. L’actuateur est donc un objet qui transforme les signaux électriques qu’il a reçu des capteurs (ceux-là transforment au paravent l’énergie fonctionnelle (informations/actions) en signaux électriques) en une énergie fonctionnelle (par exemple une énergie mécanique, une énergie dynamique). L’ensemble des capteurs-actuateurs forme la colonne vertébrale des applications IoT. Il est à noter que contrairement aux capteurs, le nombre d’actuateurs offets sur le marché ne répond toujours pas à la demande (Saad, 2016). Ceci peut être une bonne piste d’amélioration aux chercheurs voulant travailler sur cet aspect. Les actuateurs sont classés

(34)

en fonction de la source d’énergie dont ils ont besoin et qu’ils utilisent pour provoquer le mouvement. Les actuateurs IoT sont également identifiés comme étant pneumatiques, hydrauliques, électriques et thermiques ;

- les composants de stockage : étant un ensemble constitué d’un grand nombre d’objets, d’applications et de services qui communiquent entre eux, la quantité d’information manipulée en IoT est énorme. Selon le type d’application, l’information peut devoir être stockée. Le stockage des données peut se faire à l’interne (dans un fichier ou dans une base de données), ou sur le cloud.

Rahman et al. (2016) définissent les éléments d’un système IoT de façon plus granulaire. Ces éléments sont présentés dans le tableau 1.1.

Tableau 1.1 Éléments d’un système IoT, selon (Rahman et al., 2016)

Élément Rôle/Description

Capteur objet à faibles ressources ayant des capacités de capture de données Actuateur objet à faibles ressources ayant des capacités d’actionneur

Identificateur objet qui offre l’identification automatique à des objets qui y sont attachés Commutateur objet qui achemine les données aux destinataires, il opère principalement sur

la deuxième couche du modèle OSI

Passerelle objet qui permet de connecter deux réseaux de différents types (par exemple, différents protocoles de communication)

Périphérique de

stockage objet pour stocker l’information Périphérique des

utilisateurs

objets permettant aux utilisateurs d’exécuter les différentes applications (cellulaire, ordinateur,etc.)

périphériques

em-barqués objets ayant une capacité de calcul élevée

Ferme Collection de serveurs informatiques avec une capacité de stockage et d’exé-cution importante située sur Internet

1.1.3 Qu’est-ce qu’un framework en IoT ?

Selon (Derhamy, Eliasson, Delsing & Priller, 2015), le terme Framework en IoT désigne l’ensemble de principes directeurs, de protocoles et standards permettant l’implémentation

(35)

des applications IoT. Les frameworks ont pour principal but d’améliorer le développement des applications IoT et ce, en assurant une implémentation rapide, l’interopérabilité, la maintenabilité, la sécurité et la flexibilité technologique. Rahman et al. (2016) définissent un framework comme étant une "boîte à outils" pour développer des applications IoT selon un certain style ou méthode. Un framework IoT adopte un ou plusieurs protocole(s) IoT, et, fournit des APIs et des librairies qui implémentent des services en dessus des protocoles applicatifs. Il peut aussi fournir des outils de développement, test et déploiement. Dans le cadre de notre travail et dans tout le reste de ce mémoire, nous adoptons la définition de (Rahman et al., 2016) pour le concept de framework IoT ; i.e. un ensemble d’outils et d’APIs permettant de développer une application IoT.

1.1.4 Qu’est-ce qu’une plate-forme en IoT ?

Dans la littérature sur l’IoT, il n’est pas toujours évident de différencier les notions de frameworks et de plate-formes. Hejazi, Rajab, Cinkler & Lengyel (2018) définissent une plate-forme IoT comme étant une interface qui pourrait coordonner divers aspects essentiels qui conduisent à la réalisation des objectifs IoT. Cela inclut la définition de la méthode de communication des points finaux du système au réseau, et la façon dont les données sont collectées et leur lieu de stockage. Nous adoptons une définition similaire dans le reste de ce document, et on considère donc une plate-forme comme un outil qui permet à travers une interface de gestion, d’ajouter, supprimer, ou modifier les objets et de les interconnecter entre eux ou à travers le réseau.

1.2 Domaines d’utilisation de l’IoT

Actuellement, quasiment tous les secteurs utilisent l’IoT comme technologie de pointe et en tirent profil pour faciliter les tâches quotidiennes qu’ils mènent. Plusieurs articles survolent les principaux secteurs où l’IoT est le plus utilisé. Parmi les secteurs, nous listons ((Oracle, 2020), (Gubbi et al., 2013)) :

- transport et logistique : depuis l’apparition de l’IoT, les véhicules sont devenus de plus en plus "intelligents". On parle de voiture autonome, assistance propilote et gestion de la congestion

(36)

routière. Les voitures sont actuellement munies d’un très grand nombre de capteurs qui leur permettent d’assister le conducteur et d’éviter plusieurs accidents ;

- santé : le secteur de santé a connu une révolution technologique depuis l’apparition de l’IoT, permettant ainsi, aussi bien aux docteurs qu’aux patients, de recevoir des informations sur l’état de santé des malades, parfois en temps réel, et de sauver des vies, des fois sans même l’intervention du personnel médical (par exemple, injection automatique de l’insuline, dès la détection de la chute du taux de la substance chez un sujet diabétique) ;

- environnement intelligent : grâce à l’IoT, toutes les données de l’environnement demeurent disponibles en quasi-temps réel. Les données météorologiques et les données de localisation en sont des exemples. Ces données permettent d’offrir des services adaptés à des utilisateurs ;

- domotique : Ceci englobe principalement 4 applications : 1) L’automatisation des appareils d’électroménager, 2) La sécurité de la maison (par exemple les systèmes d’alarme, les caméras de surveillance), 3) la gestion des accès (ouverture et fermeture automatique des portes et des fenêtres) et 4) la gestion énergétique (chauffage/climatisation automatique). Cela permet d’assurer un certain confort aux habitants et de réduire les risques pour les personnes à mobilité réduite ;

- personnel et social : l’IoT a révolutionné la vie de tous les individus. On parle de montres intelligentes, habits intelligents, des smartphones ou téléphones connectés. Selon planetscope (Planetscope, 2018), il se vend environ 130 millions de téléphones intelligents par mois dans le monde soit 1,56 milliard par an.

1.3 Exigences et caractéristiques des applications IoT

Certains travaux abordent les caractéristiques des applications IoT et des exigences qui en découlent. Dans cette section, nous présentons une synthèse de ces exigences en terme de besoins fonctionnels et non fonctionnels. Nous discutons aussi des caractéristiques d’une application IoT telles que introduites par le standard ISO de l’IoT (ISO, 2018) et de quelques défis en relation avec ces caractéristiques.

(37)

1.3.1 Besoins fonctionnels

Les besoins fonctionnels en IoT sont l’expression des exigences opérationnelles qu’une application IoT doit satisfaire (ISO, 2018). Plusieurs travaux discutent des besoins fonctionnels. Le tableau 1.2 fait une synthèse des besoins les plus discutés (Rahman et al., 2016).

Tableau 1.2 Fonctionnalités d’un système IoT, selon (Rahman et al., 2016)

Fonction Description

Capture contrôle et connecte le capteur. Elle inclut le pré-traitement des données et la configuration du matériel via une commande au niveau de l’application. Action contrôle et connecte l’actuateur. Cela inclut la configuration du matériel via

une commande au niveau de l’application.

Profil expose des services selon le profil des objets, incluant des informations statiques (localisation, identité) et dynamiques (capteurs et actuateurs). Gestion des objets gère la configuration et le cycle de vie du système.

Contrôle

détermine le comportement de l’objet (comportement de l’actuateur en fonction de l’information reçue de la part du capteur), et traite les requêtes des utilisateurs pour modifier l’état/comportement du système

Application la combinaison des différentes fonctionnalités des objets afin de réaliser une application complète répondant aux besoins des utilisateurs finaux

API fournit des interfaces de programmation des applications pour des fonctions existantes

Découverte la fonctionnalité de découverte de nouveaux objets Stockage collecte les informations et les stocke

Analyse verticale effectue des analyses sur les données d’un seul système Analyse

horizon-tale effectue des analyses sur les données de différents systèmes

Traduction traduit les données entre deux protocoles et achemine les données entre deux réseaux différents

1.3.2 Besoins non fonctionnels

Les besoins non fonctionnels en IoT incluent autant des attributs de qualité (e.g. performance, disponibilité, fiabilité, etc.) que des exigences en termes de respect de la vie privée et stockage des données. Comme dans les applications traditionnelles, les exigences non fonctionnelles ont une importance majeure dans les applications IoT. En effet, les applications IoT reposent majoritairement sur l’aspect "temps réel" et les données traitées en IoT peuvent être réparties

(38)

sur plusieurs objets. Ce dernier aspect présente des défis pour la protection des données et leur confidentialité. Le tableau 1.3 fait une synthèse des besoins non fonctionels les plus discutés dans la littérature (Rahman et al., 2016).

Tableau 1.3 Besoins non fonctionnels en IoT selon (Rahman et al., 2016) Besoin non fonctionnel Description

Latence le temps écoulé pour que les données passent de la source vers la

destination

Point unique d’échec existence potentielle d’un point unique d’échec Confidentialité le contrôle des données dans les domaines de gestion

Sécurité garantir une meilleure disponibilité, intégrité des données et du

système, autorisation et confidentialité des données

Complexité de décision la complexité des décisions qu’une fonction de contrôle élabore Dépendance en temps le besoin qu’un système soit à l’état actif à un certain temps Évolutivité la capacité de servir un nombre évolutif d’applications

Interopérabilité la capacité de faire communiquer un objet avec d’autres différents objets

Simplicité la facilité de développement et déploiement des applications IoT

aux utilisateurs

1.3.3 Caractéristiques et exigences selon le standard ISO-RA

Parmi les initiatives visant la standardisation de l’IoT, ISO (International Organization for Standardization) a proposé un standard pour l’IoT (ISO, 2018). Dans ce document, ISO propose une architecture de référence pour l’IoT (discutée à la section 1.5) et présente les meilleures pratiques de l’industrie en IoT. Ces pratiques sont présentées sous forme de caractéristiques auxquelles une application IoT doit se conformer. ISO divise les caractéristiques en trois catégories majeures :

- caractéristiques de fiabilité du système IoT : c’est les critères qui définissent le degré de fiabilité du système. En d’autres termes, jusqu’à quel point les parties prenantes peuvent être sûres que leurs applications peuvent faire face aux erreurs humaines et erreurs de calcul des variables d’environnement. Parmi ces caractéristiques, il y a la disponibilité, la

(39)

résilience, la protection des données et la sécurité. Le tableau 1.4 décrit sommairement ces caractéristiques ;

- caractéristiques de l’architecture du système IoT : critères relatifs à l’infrastructure de l’IoT (par exemple, architecture du système, protocoles réseau). Ces caractéristiques incluent, par exemple, la composabilité (capacité de combiner différents objets), la gestion de l’hétérogénéité, l’intégration des systèmes légataires, la modularité et l’identification unique. Le tableau II-1 en annexe décrit sommairement ces caractéristiques ;

- caractéristiques fonctionnelles du système IoT : critères reliés aux fonctions supportées par une application IoT. Ces caractéristiques incluent, par exemple, la précision des données, la configuration automatique du système IoT, la sensibilité au contexte et la découvrabilité des services. Ces caractéristiques sont décrits sommairement dans le Tableau III-1 en annexe.

Tableau 1.4 Caractéristiques de fiabilité du système IoT

Critère Description

Disponibilité Capacité d’un système à être accessible et utilisable à la demande par une entité autorisée.

Confidentialité Propriété que les informations ne soient pas rendues disponibles ou divulguées à des individus, entités ou processus non autorisés.

Intégrité Propriété de précision et de complétude des données du système Fiabilité Cohérence du comportement et des résultats attendus.

Protection des don-nées d’identité per-sonnelle

Concept chevauchant au concept de confidentialité, c’est un règlement judiciaire requis dans les différentes applications IoT impliquant des données personnelles. La protection des informations personnelles est une exigence générale, régie par une série de principes décrits dans la norme ISO / IEC 29100

Résilience Capacité d’un système ou d’un de ses composants à continuer son activité en présence d’une panne ou une défaillance

Sécurité

État dans lequel le risque sur la sécurité physique des individus et la sécurité du matériel est limité à un niveau acceptable. Le risque est la combinaison de la probabilité de survenue d’un préjudice et de la gravité de ce préjudice.

(40)

1.3.4 Défis reliés aux applications IoT

La satisfaction de certaines exigences des applications IoT reste un défi pour les industries. Certains des défis les plus importants sont ((Matta et al., 2017), (Miraz et al., 2015)) :

- plusieurs exigences de l’IoT nécessitent des standards et celà à différents niveaux ; par exemple, la sécurité en IoT, la découvrabilité, etc ;

- l’alimentation énergitique des capteurs est un enjeu en IoT. Cela représente un défi dans le cas où les capteurs sont distants, non accessibles et contrôlés à distance. Certaines technologies peuvent être exploitées pour aider dans ce contexte, notamment les générateurs thermiques et les cellules solaires ;

- l’architecture d’un tel réseau, aussi distribué et hétérogène constitue aussi un enjeu très important en IoT. L’évolutivité, l’interopérabilité, la gestion des objets et services sont des aspects importants à considérer dans le développement de ces architectures ;

- en ce qui concerne le traitement des données, les principaux problèmes sont le partage, la propagation, la collaboration, l’efficacité du traitement et la présentation des données ;

- la sécurité et la confidentialité des données, tant du point de vue des fournisseurs que des utilisateurs, constituent aussi des défis majeurs ;

- l’adoption de l’IoT constitue un enjeu sociétal, car il est parfois difficile de convaincre les utilisateurs de changer leurs habitudes. Plusieurs utilisateurs n’ont pas confiance en ce type de système par souci de sécurité et de protection de la vie privée et des données personnelles, notamment avec le taux alarmant des brèches de données. D’un autre côté, les applications doivent avoir des interfaces conviviales (user-friendly), pour inciter les gens à les utiliser.

1.4 Technologies supportant les applications IoT

L’IoT doit son progrès à plusieurs technologies existantes, notamment l’internet, le cloud et le Big-Data :

(41)

- Internet : Malgré la divergence des définitions de l’IoT, Internet reste le point commun de ces définitions. Internet forme donc une plate-forme d’implantation de l’IoT. Cependant, Internet sous sa forme traditionnelle permet d’interconnecter les objets, sans donner la capacité de capturer l’information. Une couche par dessus Internet "Sensing Layer" a permis d’avoir l’IoT, sous sa forme actuelle ;

- Cloud : L’utilisation du cloud dans l’IoT a permis d’intégrer l’IoT dans tous les secteurs. Ensemble, ils sont devenus omniprésents dans notre quotidien. Plusieurs plates-formes et frameworks Cloud open source et payants existent pour intégrer des services IoT, pour n’en nommer que quelques-uns, on cite : Arkessa, OpenIoT, Nimbits, LittleBits, OnePlatform, SmartThings, SensorCloud, Xively. Ces plates-formes assurent les services basés sur le cloud en IoT ;

- Big-Data : Le nombre énorme d’objets interconnectés à travers l’IoT contribue à génerer des données massives (Big-Data) qui doivent être traitées, analysées et stockées. Certaines technologies et services tels que Hadoop, SciDB et TSaaaS sont disponibles et prennent en charge l’analyse des Big Data. Elles sont également adaptées aux exigences en traitement de données de l’IoT.

Les applications IoT sont de nature hétérogène et, conséquemment, utilisent et intègrent diverses technologies et protocoles de communication réseau. Dans ce qui suit, nous faisons un survol rapide de ces technologies de communication suivi d’une présentation sommaire des protocoles utilisés en IoT.

1.4.1 Technologies de communication

Il existe plusieurs technologies de communication ciblant différents types d’équipements et offrant différentes portées et capacités. Les technologies suivantes figurent parmi les plus connues et/ou utilisées (Matta et al., 2017) :

- Near-Field Communication (NFC) et Radio frequency identification (RFID) : La technologie RFID a paru au tout début des années 2000s, son successeur, NFC l’a dominé. La technologie

(42)

RFID est le processus d’identifier les objets par un identifiant unique, en utilisant des ondes radio. Elle est basée sur la présence d’un tag RFID, un lecteur de tags RFID et une antenne. Le signal est transmis du lecteur au tag via les antennes. Le tag répond par la génération et la diffusion de son identifiant unique. Les tags qui produisent leur propre alimentation sont nommés tags actifs, les autres reçoivent l’alimentation du lecteur et sont nommés tags passifs. NFC a été introduit pour assurer la sécurisation des échanges. Contrairement au cas de RFID, en NFC, les tags, les lecteurs et l’antenne font tous partie d’un même appareil. Un appareil NFC est donc capable d’assurer par lui-même les communications Peer to peer ;

- Optical Codes (OC) et Quick Response Codes (QRC) : Les codes optiques tels que l’indique leur nom, sont généralement des codes de nature optique, lisibles par machine et utilisés pour représenter les données de longueur variée. Ces codes contiennent des informations valides et requises sur l’objet auquel ils sont associés. Ce code peut être à une dimension, ou à deux dimensions s’il est représenté par une figure bidimensionnelle. L’application la plus connue de ce type de code est le code à barres qu’on trouve sur les produits qu’on achète. Le code QRC est un code bidimensionnel dont la lecture se fait à l’aide d’un dispositif de lecture (la caméra d’un téléphone portable par exemple). Le type d’encodage utilisé peut être numérique, alphanumérique, binaire, ou kanji. Ce type de technologie doit son utilisation en IoT au fait qu’il est facile à utiliser, permet une lecture rapide, et permet l’identification, le suivi et la traçabilité de l’objet ;

- ZigBee : C’est une technologie de communication qui offre une faible portée, un faible taux de transmission et une alternative moins coûteuse pour la mise en œuvre des réseaux IoT. Basée sur le protocole IEEE 802.15.4, ZigBee opère sur la couche physique et MAC du réseau. L’intervalle de transmission en ZigBee est entre 10 à 100 mètres. Sa force réside dans sa faible consommation d’énergie. ZigBee est donc très répandue dans les domaines qui exigent un faible taux de transmission de données avec une durée optimale des batteries ;

- 6LOwPAN (IPv6 over Low power Wireless Personal Area Network) : C’est un ensemble de standards Internet qui permettent l’utilisation de l’IPv6 sur un réseau sans fil à faible puissance. L’utilisation de l’IPv6 procure un large spectre d’adresses IP, vu le nombre important d’objets connectés sur Internet, qui dépassent le nombre d’adresses fournies en

(43)

IPv4. 6LOwPAN vient remédier aux différents inconvénients des différents autres protocoles notamment pour la sécurité, puisqu’il supporte l’authentification IPsec, le cryptage, et des services web qui supportent des mécanismes de sécurisation de la couche transport, ainsi que les sockets sécurisés ;

- Advanced ( A) : Faisant partie du standard LTE (Long Term Evaluation), LTE-Advanced assure une connectivité mobile à grande vitesse. Cette technologie est conçue principalement pour le réseau 4G. Sa plus connue application est la connexion véhicule à véhicule, dans le domaine des voitures connectées ;

- Z-Wave : Cette technologie est utilisée dans les maison intelligentes, spécialement dans le contrôle à distance des lumières, des fenêtres, les piscines, les garages, et les systèmes de sécurité des maisons. Le système de communication peut être géré par combinaison de l’Internet et de la passerelle Z-wave ;

- WSN (Wireless Sensor Network) : Guadane, Bchimi, Samet & Affes (2017) présentent les réseaux de capteurs sans fils, ou WSN (de l’anglais, Wireless Sensor Network) comme une technologie de pointe utilisée en IoT. Un réseau de capteurs est un réseau ad hoc dont la plupart des nœuds sont des micro capteurs capables de récolter et de transmettre des variables d’environnement d’une manière autonome. La position de ces nœuds n’est pas obligatoirement déterminée. Ils peuvent être aléatoirement dispersés dans une zone géographique, nommée « champ de captage » correspondant au terrain d’intérêt pour le phénomène capté. On entend dire par réseau ad hoc, l’ensemble d’appareils auto configurables étant libres de se déplacer. C’est donc un réseau "décentralisé".

1.4.2 Protocoles de communication IoT

Les protocoles de communications sont très importants puisqu’ils définissent les règles et les procédures de communication des couches physique et liaison de données du modèle OSI. En IoT, certains protocoles commencent à dominer ; c’est notamment les cas de COAP (Constrained Application Protocol) et MQTT (Message Queue Telemetry Transport). Ces deux protocoles présentent des similarités et différences (Hejazi et al., 2018) :

(44)

- CoAP : CoAP est un protocole de communication conçu pour les objets IoT, inspiré du protocole HTTP (Hypertext Transfer Protocol) et utilisant une communication de bout en bout. Étant conçu pour des objets à ressources restreintes, CoAP est léger et génère le moins de trafic possible. CoAP ne prend donc pas en charge le protocole TCP/IP, mais plutôt le protocole UDP car ce dernier utilise moins de bande passante et ne prend pas en charge l’acquittement de réception (ACK) comme c’est le cas de TCP/IP. Il utilise moins de ressources et implémente plus de fonctionnalités que HTTP telles que des fonctionnalités d’observation, d’exécution et de découverte, ainsi que des fonctions de lecture et d’écriture. La fonctionnalité de découverte incluse dans CoAP permet de rechercher des objets situés et connectés dans l’environnement ;

- MQTT : MQTT est un protocole de messagerie implémenté sur TCP/IP, il s’agit d’un protocole léger adoptant la méthode Pub/Sub (Publier et Souscrire). Il utilise le serveur de courtier de messages (MQTT broker) au milieu des communications entre les objets. Ce n’est donc pas un protocole machine à machine. Il se compose de 3 éléments : Subscriber,

Publieur et un Broker. Les clients souscrivent et publient au Broker à travers des topics.

Tel qu’illustré dans la figure 1.1, si un client (Temperature sensor dans la figure) publie des valeurs de la température en lui attachant le topic "Temperature", les deux autres clients recevront les données s’ils sont souscrits au Broker avec le même topic, soit, "temperature". De point de vue sécurité, MQTT supporte SSL et TLS (Secure Sockets Layer et Transport Layer Security).

Le choix d’un protocole ou un autre dépend de la nature de l’application IoT visée, Dans le cas d’un réseau WAN (Wide Area Network), MQTT est approprié vu le concept du Broker qui réside au milieu de la communication entre les appareils. Il est donc utile pour une bande passante limitée ou sur différents sites distants. Par exemple, les services Amazon et Azure utilisent le protocole MQTT. Pour les services Web, CoAP est mieux adapté du fait de sa compatibilité avec HTTP. Il utilise UDP (User Datagram Protocol) qui prend en charge la multi-diffusion et la diffusion. Il est utilisé lorsque les objets doivent transmettre et recevoir des données à grande vitesse.

(45)

Figure 1.1 Illustration du protocole MQTT, adapté de (Hermanudin et al., 2019).

1.5 Architectures des applications IoT

De façon générale, une architecture définit les différents éléments d’un système informatique et l’interaction entre ces éléments. En IoT, plusieurs architectures ont été proposées. Dans cette section, nous présentons de façon sommaire quelques architecture décrites dans la littérature. Ensuite nous présentons l’architecture de référence proposée par l’ISO.

1.5.1 Survol rapide des architectures décrites dans la littérature

Vashi et al. (2017) propose une architecture inspirée de l’architecture orientée service. Cette architecture est organisée en 5 couches, tel qu’illustré sur la figure 1.2 :

- couche perception : Cette couche correspond à la couche physique du modèle OSI. Elle englobe les différents types de capteurs (par exemple, RFID, infrarouge, ZigBee, QR code). Cette couche gère généralement tous les appareils, à savoir, leur identification, la collecte des informations mesurées (par exemple, température, humidité, mouvement, pression). Les informations collectées seront transmises par la suite vers la couche réseau ;

- couche Réseau : Cette couche joue un rôle capital dans la sécurité et la confidentialité de l’information à travers le transfert sécurisé des données sensibles des capteurs aux unités

(46)

de contrôle. Ce transfert se fait via des réseaux, tels que 3G, 4G, UMTS, Wi-Fi, WiMAX, RFID, infrarouge, satellite ;

- couche MiddleWare : Partant du fait que IoT est un réseau qui englobe différents objets interconnectés qui communiquent entre eux, cette couche permet la gestion des services générés par les objets. De plus, cette couche permet le stockage des informations reçues de la couche inférieure dans des bases de données ainsi que le traitement et le calcul des informations, afin de générer une décision aux actuateurs ;

- couche Application : Cette couche est responsable de la gestion des applications en fonction du type de données reçues de la couche MiddleWare. Les applications IoT couvrent plusieurs secteurs, tels que la santé, les voitures, les maisons et le transport ;

- couche Business : les fonctions de cette couche couvrent l’intégralité de la gestion des applications et des services IoT. Son principal rôle est analytique, tel que générer des rapports ou des graphes, en fonction de la quantité de données précises reçues de la couche inférieure et d’un processus d’analyse de données efficace. Cette information sera utile aux gestionnaires pour prendre des décisions sur les stratégies commerciales et les feuilles de route à adopter.

Figure 1.2 Architecture en couches, adaptée de (Vashi et al.,

(47)

Muccini & Moghaddam (2018) font un survol des travaux portant sur les architectures IoT et les styles architecturaux en IoT. D’après cette étude, on remarque la popularité des architectures en couches en IoT, avec un nombre de couches allant de trois jusqu’à six couches, tel que présenté dans la figure 1.3 :

Figure 1.3 Architectures en couches en IoT, adaptée de (Muccini & Moghaddam, 2018).

- perception : représente l’ensemble des capteurs et objets physiques permettant de collecter l’information du monde physique et de l’acheminer vers le monde informatique virtuel ;

- traitement et stockage de données : c’est la couche responsable de l’analyse, le traitement et le stockage des données collectées par les capteurs. Plusieurs techniques sont utilisées, telles que le Cloud Computing et le ubiquitous computing ;

- application : cette couche est responsable de fournir les différents services demandés par les utilisateurs (les requêtes des utilisateurs) ;

- Business : afin de gérer le système IoT entier, cette couche conçoit des feuilles de route en utilisant les modèles d’affaires relatifs aux domaines d’application ;

(48)

- réseau : représente les technologies et les protocoles de transmission des données permettant le transfert de données de la couche perception aux autres couches pour le traitement ;

- adaptation : cette couche se situe entre la couche perception et la couche réseau. Elle permet l’interopérabilité entre les différents objets en IoT.

En plus des architectures en couches, plusieurs autres architectures sont exploitées en IoT :

- architecture orientée service (SOA) : l’architecture SOA est un modèle d’interaction basée sur des services très peu couplés. Un service est fourni par un fournisseur et consommé par un client. Cette interaction se fait à travers un courtier de services qui décrit l’emplacement du service et garantit sa disponibilité. Un consommateur ou client de service demande au courtier de service de localiser un service et de déterminer comment communiquer avec ce service ;

- architecture basée sur le cloud : dans cette architecture, plusieurs fonctionnalités sont déléguées au Cloud, telles que l’analyse des données. Cela permet de traiter et de stocker une plus grande quantité d’information ;

- architecture Fog Computing : c’est un concept relativement récent en IoT. Cette architecture se caractérise par ses différents services pour fournir un système IoT et consiste à amener des services Cloud virtualisés aux extrémités afin de contrôler les appareils IoT ;

- microservices : un microservice est une application qui peut être déployée, mise à l’échelle et testée indépendamment et qui a une seule responsabilité. L’approche de l’architecture microservices consiste donc à utiliser l’architecture SOA et la virtualisation logicielle afin de pallier aux limites du SOA, telles que l’évolutivité ;

- RESTful : une API est RESTful, quand à elle, respecte le principe d’architecture REST. La particularité de cette architecture est que le serveur et le client communiquent sans que le client connaisse la structure et le contenu des informations stockées sur le serveur ;

- Publish/Subscribe : dans le style architectural Pub/Sub, le Publisher publie un message en y incluant un Topic particulier, et le Subsriber le reçoit à condition qu’il ait le même topic.

(49)

Généralement, ce processus est assuré grâce à un Broker, qui lui joue le rôle d’un serveur entre le Publisher et le Subscriber (MQTT en est un exemple) ;

- Information Centric Networking (ICN) : ICN fait des données une base de communication des objets. Elle correspond donc au modèle d’application des systèmes IoT et fournit un paradigme de communication efficace et intelligent pour l’IoT.

1.5.2 L’architecture de référence ISO

ISO (2018) propose une architecture de référence en IoT, nommée ISO-RA. Cette architecture est un guide pratique aux architectes voulant développer des applications IoT, afin de les aider à mieux comprendre les systèmes IoT et les différentes parties prenantes (i.e. fabricants des appareils, utilisateurs, développeurs des applications, etc.). ISO présente en premier lieu un modèle conceptuel du système IoT et un ensemble de caractéristiques qu’une application IoT doit respecter. Ces éléments sont utilisés pour définir un modèle de référence de l’IoT et des vues architecturales du système IoT incluant une vue fonctionnelle, une vue de déploiement, une vue communication et une vue d’utilisation.

Le modèle conceptuel (Figure 1.4) est composé d’entités et de domaines. Une entité est tout objet ayant une existence indépendante et distincte, tels que les personnes, les organisations et les objets. Ces entités peuvent être classées en 4 groupes :

- entité physique (Physical Entity) : c’est une entité discrète, observable et identifiable ;

- utilisateur (IoT-user) : c’est une entité pouvant être un humain, ou un non-humain ;

- système TI (ou entité digitale) (Entity) : correspond aux éléments de calcul et d’information, incluant les applications, les services, les entités virtuelles, les dépôts de données, les objets IoT et les passerelles IoT ;

- réseau de communication (Network) : c’est une entité importante de l’IoT permettant aux autres entités de se connecter et d’interagir. Chaque entité voulant se connecter à travers le réseau doit disposer d’un identifiant unique (un ensemble d’attributs qui servent pour

(50)

identifiant de l’entité dans un contexte donné). Une entité peut avoir plusieurs identifiants selon le contexte, mais doit au moins en avoir un.

Figure 1.4 Modèle conceptuel de l’IoT, extrait de (ISO, 2018).

La figure 1.5 montre le modèle de référence basé sur les entités du modèle conceptuel. Dans ce modèle de référence, une entité physique (Physical Entity) est physiquement connectée aux objets IoT (IoT Devices) : (capteurs /actuateurs), lesquels sont connectés physiquement à des passerelles IoT (IoT Gateways) et fictivement à un ensemble de sous-systèmes composé de sous-système de gestion et opération (Operation & management Sub-system), sous-système de service et

(51)

application (Applicatio & Service Sub-system) et sous-système de communication et accès (Access & Communication Sub-system) . Ces sous-systèmes sont connectés aux utilisateurs IoT (Humains, Objets/IHM). Chacun des Utilisateurs IoT (IoT-Users), les sous-systèmes, les passerelles IoT (IoT Gateways) et les objets IoT (IoT Devices) sont connectés physiquement au réseau. Les passerelles IoT (IoT Gateways) sont couramment utilisées dans les systèmes IoT. Ils forment une connexion entre le ou les réseaux de proximité locaux et le réseau d’accès étendu. Les passerelles IoT peuvent contenir d’autres entités et fournir un plus large éventail de fonctionnalités. Une passerelle IoT contient souvent un agent de gestion fournissant des fonctionnalités de gestion à distance. La passerelle IoT peut contenir un magasin de données, stockant les données des objets IoT associés.

Figure 1.5 Modèle de référence basé sur les entités, extrait de (ISO, 2018).

Les différentes entités IoT appartiennent généralement à un domaine donné. La figure 1.6, montre le modèle de référence basé sur les domaines. Cette représentation a pour but d’aider le concepteur des applications à focaliser sur les différentes tâches devant être réalisées. En d’autres termes, les domaines sont utilisés pour classifier les fonctions par responsabilités. Ces

Figure

Tableau 1.3 Besoins non fonctionnels en IoT selon (Rahman et al., 2016) Besoin non fonctionnel Description
Figure 1.2 Architecture en couches, adaptée de (Vashi et al.,
Figure 1.5 Modèle de référence basé sur les entités, extrait de (ISO, 2018).
Figure 1.6 Modèle de référence basé sur les domaines, extrait de (ISO, 2018).
+7

Références

Documents relatifs

Based on theoretical analysis of efficiency performance of energy harvesters for IoT applications, this work addresses the possibilities of increasing input power level

In this paper, we propose some techniques to support end-users when designing IoT applications that are not simplistic, thus can- not be built by simple rules or existing recipes

In this case, the recommender engine uses Content-based Filtering as the recommendation technology to find a related plan based on the user data.. Quantified-Self - Virtual

[r]

(a) Measured DC voltage as a function of the frequency: 3D rectenna (continuous blue line) versus 2D rectenna (dotted red line); (b) efficiency of the 2D rectenna as a function

We have proposed an algorithm to the controller placement problem in this SD-IoT architecture aiming at satisfy- ing the delay constraints between IoT devices and the controllers.

When 6 bits (with 3 bits fraction) are used, truncation (“Trunc”) caused by limited word length plus undersampling error makes the quantization error much higher than

• In terms of the fate and transport of petroleum hydrocarbons in the groundwater, based on the model predictions, the groundwater concentrations would not reach regulatory