Architectures protocolaires interopérables pour le réseau de collecte de l'Internet des objets

HAL Id: tel-03270739

https://tel.archives-ouvertes.fr/tel-03270739

Submitted on 25 Jun 2021

HAL is a multi-disciplinary open access archive for the deposit and dissemination of sci- entific research documents, whether they are pub- lished or not. The documents may come from

L’archive ouverte pluridisciplinaire HAL, est destinée au dépôt et à la diffusion de documents scientifiques de niveau recherche, publiés ou non, émanant des établissements d’enseignement et de

Architectures protocolaires interopérables pour le réseau de collecte de l’Internet des objets

Nicolas Gonzalez

To cite this version:

Nicolas Gonzalez. Architectures protocolaires interopérables pour le réseau de collecte de l’Internet des objets. Réseaux et télécommunications [cs.NI]. Université Toulouse le Mirail - Toulouse II, 2020.

Français. �NNT : 2020TOU20054�. �tel-03270739�

THÈSE

En vue de l’obtention du

DOCTORAT DE L’UNIVERSITÉ DE TOULOUSE

Délivré par l'Université Toulouse 2 - Jean Jaurès

Présentée et soutenue par Nicolas GONZALEZ

Le 16 octobre 2020

Architectures protocolaires interopérables pour le réseau de collecte de l'Internet des Objets

Ecole doctorale : EDMITT - Ecole Doctorale Mathématiques, Informatique et Télécommunications de Toulouse

Spécialité : Informatique et Télécommunications Unité de recherche :

IRIT : Institut de Recherche en Informatique de Toulouse Thèse dirigée par

Thierry VAL et Adrien VAN DEN BOSSCHE Jury

M. Michel MISSON, Rapporteur M. François SPIES, Rapporteur Mme Nathalie MITTON, Examinatrice

M. Laurent TOUTAIN, Examinateur Mme Réjane DALCE, Examinatrice Mme Katia JAFFRES-RUNSER, Examinatrice

M. Thierry VAL, Directeur de thèse

M. Adrien VAN DEN BOSSCHE, Co-directeur de thèse

Remerciements

Je tiens ` a remercier Monsieur le Professeur ´ em´ erite Michel Misson et Monsieur le Professeur Fran¸ cois Spies pour l’int´ erˆ et qu’ils ont port´ e ` a mes travaux en acceptant de les rapporter.

Je remercie tout particuli` erement Monsieur le Professeur Thierry Val ainsi que Monsieur le Docteur Habilit´ e Adrien Van Den Bossche pour avoir accept´ e de prendre la direction de mes travaux. Je vous remercie pour votre confiance, votre ´ ecoute, vos conseils, et de fa¸con g´ en´ erale votre bienveillance ` a l’´ egard de ma personne et de mes travaux. Je vous remercie de m’avoir accord´ e l’autonomie qui m’a permis de d´ ecouvrir, d’apprendre et de m’essayer au m´ etier d’enseignant et de chercheur.

Je remercie vivement Benjamin Freeman avec qui j’ai partag´ e un bout de cette th` ese en tant qu’ami, co-bureau, coll` egue, binˆ ome et maintenant en tant qu’associ´ e dans l’entreprise OperaMetrix que nous avons co-fond´ ee. Ta fidelit´ e, ta patience et ta franchise m’enrichissent autant sur le plan personnel que professionnel. Je te remercie pour ta confiance et pour ton aide dans ces ´ epreuves.

Je remercie du fond du coeur Julien Bresciani et Laurent Guerby qui ont fait beaucoup pour moi et principalement dans le cadre de cette th` ese. Souvent dans l’ombre et sans en r´ ecolter les honneurs vous agissez pour rendre les choses possibles. Je tiens aujourd’hui ` a vous remercier pour tout cela et vous prie de croire en ma reconnaissance infinie ` a l’affection que vous m’avez apport´ ee.

Je remercie l’ensemble du personnel de l’IUT de Blagnac pour son accueil chaleureux et sa sympathie le long de ce bout de chemin que l’on a fait ensemble. Votre confiance m’a permis de m’´ epanouir sur de nombreux aspects, dont l’enseignement. Je remercie tout particuli` erement R´ emi Boulle qui m’a permis de r´ ealiser des enseignements et d’en cr´ eer de nouveaux sur mes th´ ematiques de recherche. Ta confiance m’a profond´ ement touch´ e.

Je remercie mes amis et ma famille qui m’accompagnent dans tous les challenges que je tente de relever. L’indisponibilit´ e physique et souvent c´ er´ ebrale, la charge de travail, les phases de stress ou encore les nombreuses heures ` a travailler en dehors des p´ eriodes acceptables vous font supporter les cˆ ot´ es n´ egatifs de mes choix. Vous ˆ etes pourtant toujours l` a pour m’accompagner, me soutenir, m’encourager dans ces

´

etapes de ma vie que je ne pourrais franchir sans vous. Et pour tout cela, je vous remercie tendrement de votre patience et de votre confiance dans la sinc´ erit´ e de mon amour pour vous.

Je tiens ` a remercier Pauline qui subit au quotidien ma charge de travail et mon implication forte dans

de nombreux projets. Tu m´ eriterais ton nom sur la premi` ere page de cette th` ese tant ta contribution

morale m’a ´ et´ e n´ ecessaire. Ta gentillesse, ta patience et ta tol´ erance sont d’une raret´ e dont je prends

conscience un peu plus chaque jour qui passe.

Table des mati` eres

Remerciements 3

Introduction 9

1 L’Internet des Objets pour l’industrie et les enjeux de l’interop´ erabilit´ e 11

1.1 D´ efinition et origines . . . . 13

1.1.1 D´ efinition . . . . 13

1.1.2 Origines . . . . 19

1.2 L’Internet des Objets pour l’industrie (IIoT) . . . . 22

1.2.1 Vers de nouvelles formes d’organisation des entreprises . . . . 22

1.2.2 Strat´ egie de valorisation des donn´ ees . . . . 24

1.2.3 La probl´ ematique de l’interop´ erabilit´ e . . . . 25

1.3 Etat de l’art scientifique sur l’interop´ ´ erabilit´ e . . . . 27

1.3.1 S´ emantique et encodage des donn´ ees . . . . 27

1.3.2 Architectures interop´ erables pour l’IoT . . . . 28

1.3.3 Protocoles de transport des donn´ ees . . . . 28

1.3.4 Encapsulation des messages . . . . 29

1.3.5 Architecture IoT event-driven . . . . 29

1.4 Les concepts et composants de base de l’IoT . . . . 31

1.4.1 La couche d’acquisition des informations . . . . 32

1.4.2 La couche de collecte des informations . . . . 36

1.4.3 La couche de traitement des informations . . . . 40

1.5 Premi` ere piste d’architecture interop´ erable . . . . 42

1.5.1 Impl´ ementation du mod` ele de graphe de flux . . . . 42

1.5.2 Limitation de Node-RED . . . . 43

1.5.3 Conclusion . . . . 43

1.6 Syst` eme de messagerie pour l’Internet des Objets . . . . 43

1.6.1 Le format et le type des messages . . . . 44

1.6.2 Repr´ esentation au format JSON . . . . 44

1.6.3 Limitations des capacit´ es des objets . . . . 45

1.6.4 N´ ecessit´ e d’un interm´ ediaire . . . . 45

1.7 Garantir l’interop´ erabilit´ e ` a l’aide du protocole MQTT . . . . 46

1.7.1 Int´ erˆ ets . . . . 46

1.7.2 Paradigme Publish/Subscribe . . . . 46

1.7.3 Impl´ ementation des mots cl´ es dans MQTT . . . . 47

1.7.4 Impl´ ementation de la couche transport . . . . 48

1.7.5 Utilisation de MQTT dans le cadre de l’Internet des Objets . . . . 48

1.7.6 Couche de transport augment´ ee en espace utilisateur . . . . 49

1.7.7 Gestion du multicast par la QoS . . . . 49

1.8 Conclusion . . . . 51

2 Les r´ eseaux LPWAN : originalit´ es, architectures et d´ eploiement 53 2.1 Origines de la d´ emarche de recherche . . . . 55

2.1.1 D´ eveloppement actif d’entreprises autour des LPWAN . . . . 55

2.1.2 Appropriation des LPWAN par le milieu acad´ emique . . . . 55

2.1.3 Les promesses des r´ eseaux LPWAN . . . . 56

2.2 Etat de l’art scientifique sur les LPWAN ´ . . . . 57

2.2.1 P´ eriode 2015/2016 : les premi` eres publications sur les LPWAN et la couche physique LoRa . . . . 57

2.2.2 P´ eriode 2017/2018 : d´ ebut de cette th` ese et intensification des publications . . . . 57

2.2.3 P´ eriode 2019/2020 : d´ eploiement des premiers r´ eseaux de recherche . . . . 58

2.2.4 R´ eseaux maill´ es avec couche physique LoRa . . . . 58

2.3 L´ egislation des bandes ISM . . . . 58

2.4 Evaluation des param` ´ etres de la couche physique . . . . 60

2.4.1 Id´ ee de d´ epart : du multi-saut au multi-m´ edium . . . . 60

2.4.2 Modulation LoRa . . . . 60

2.4.3 Codage de canal dans la couche physique LoRa . . . . 61

2.4.4 Temps d’´ emission et d´ ebit . . . . 62

2.5 Composants d’infrastructure . . . . 65

2.5.1 Passerelle LPWAN . . . . 65

2.5.2 Serveur de r´ eseau . . . . 66

2.5.3 Serveurs applicatifs . . . . 66

2.6 R´ eseaux LPWAN priv´ es et publics . . . . 68

2.6.1 R´ eseaux LPWAN publics . . . . 68

2.6.2 R´ eseaux LPWAN priv´ es . . . . 69

2.7 Protocoles de transport des messages . . . . 69

2.7.1 Packet Forwarder . . . . 70

2.7.2 Transport des trames via MQTT . . . . 73

2.8 De la th´ eorie ` a la pratique . . . . 73

3 Proposition d’une architecture de testbed urbain ouvert pour les LPWAN 75 3.1 Origines du projet . . . . 76

3.1.1 Testbed urbain . . . . 76

3.1.2 L’association Tetaneutral.net . . . . 76

3.1.3 Lancement du projet . . . . 76

3.2 Proposition d’architecture d’un testbed urbain ouvert . . . . 77

3.2.1 Passerelle LoRa . . . . 77

3.2.2 R´ eseau de collecte des trames LoRa . . . . 79

3.2.3 Concept de commutation au niveau du bus logiciel . . . . 81

3.3 Programmation de nouveaux r´ eseaux LoRa . . . . 82

3.3.1 Programmation de nouveaux services r´ eseau pour les LPWAN . . . . 82

3.3.2 Programmation des interactions avec les objets . . . . 84

3.4 Architecture globale du testbed urbain . . . . 86

3.4.1 Services r´ eseau du testbed urbain . . . . 86

3.5 Cas d’usages et valorisation scientifique du testbed . . . . 87

3.5.1 Cas d’usages . . . . 89

3.5.2 Valorisation . . . . 89

4 Vers l’extensibilit´ e d’un r´ eseau LoRa 91 4.1 Evaluation des performances de propagation de la modulation LoRa ´ . . . . 93

4.1.1 Travaux pr´ ealables de d´ ecouverte de la couche physique . . . . 93

4.1.2 Bilan de liaison d’une transmission LoRa . . . . 95

4.1.3 Mod` ele de propagation . . . . 96

4.1.4 Campagne de mesures . . . . 101

4.1.5 Analyse des conditions de collision entre les trames LoRa . . . . 104

4.1.6 Mod´ elisation des processus al´ eatoires de fading . . . . 105

4.2 Simulation d’un acc` es au m´ edium sur une topologie mono-passerelle . . . . 106

4.2.1 Objectifs de la simulation . . . . 106

4.2.2 Hypoth` eses instinctives d’´ etude . . . . 108

4.2.3 Topologie d’´ etude . . . . 108

4.2.4 Simulateur ` a ´ ev` enements discrets . . . . 108

4.2.5 Simulation d’un acc` es multiple ` a une gateway LoRa . . . . 110

4.2.6 Param´ etrage de la simulation . . . . 111

4.2.7 Disposition al´ eatoire des nœuds . . . . 111

4.2.8 Choix statique de param´ etrage du spreading factor . . . . 112

4.2.9 Analyse du taux de livraison des trames (FDR) . . . . 113

4.3 Optimisation du taux de livraison des trames (FDR) . . . . 115

4.3.1 Crit` ere d’optimisation . . . . 115

4.3.2 M´ ethode d’optimisation CMA . . . . 116

4.3.3 Proposition d’une nouvelle m´ ethode d’optimisation par bandes successives . . . . . 116

4.4 Etude de l’extensibilit´ ´ e de l’acc` es au m´ edium des r´ eseaux LoRa . . . . 120

4.4.1 Limite d’extensibilit´ e par canal . . . . 120

4.4.2 Limite d’extensibilit´ e globale . . . . 120

4.5 Algorithme de r´ eglage automatique des param` etres de la couche physique . . . . 122

4.5.1 Automatic Data Rate de LoRaWAN . . . . 122

4.5.2 Les trois zones comportementales . . . . 123

4.5.3 Proposition d’algorithme . . . . 125

4.5.4 Conclusion et perspectives de ces travaux . . . . 128 Conclusion g´ en´ erale et perspectives de recherche 131

Bibliographie 135

Glossaire 141

Table des figures 143

Liste des tableaux 147

Liste des publications 148

Introduction

Les ann´ ees 2000 ont ´ et´ e marqu´ ees par la d´ emocratisation massive de l’utilisation du r´ eseau Inter- net. L’int´ egration de l’acc` es aux donn´ ees mobiles dans les t´ el´ ephones cellulaires permet ` a chaque citoyen d’avoir un acc` es permanent en tous lieux au r´ eseau mondial. Cette connectivit´ e devient omnipr´ esente avec la cr´ eation de nombreuses plateformes d’´ echanges, de messagerie, d’achats et de partage d’informa- tions. Cet engouement n´ ecessite le d´ eveloppement de technologies de communication toujours plus rapides et de serveurs performants. Cette mont´ ee en charge favorise le d´ eveloppement du concept de ”Cloud Computing”, couche d’abstraction des infrastructures qui deviennent provisionnables automatiquement en fonction de l’utilisation. Ces infrastructures permettent d’envisager la collecte, le stockage et la ma- nipulation de volumes de donn´ ees de plus en plus importants. Les techniques de Machine Learning et d’Intelligence Artificielles d´ evelopp´ ees depuis les ann´ ees 60 redeviennent au goˆ ut du jour avec l’espoir qu’un volume de donn´ ees important ait des propri´ et´ es statistiques permettant de mod´ eliser des tendances et de prendre des d´ ecisions.

Dans un mˆ eme temps, la communaut´ e scientifique ´ etudie les r´ eseaux de capteurs sans fil avec l’id´ ee de rendre les objets ´ electroniques, communicants avec l’informatique de fa¸ con ` a collecter des donn´ ees issues du monde physique. Les applications industrielles sont nombreuses comme la surveillance des proc´ ed´ es, l’ob- servation de l’environnement, la logistique ou encore la robotique. Les applications grand public sont moins nombreuses mais se d´ eveloppent autour du smartphone principalement avec les technologies Bluetooth et Wi-Fi. C’est l’´ emergence des capteurs sportifs, des casques audio, des capteurs de surveillance de la maison ou des plantes, ou encore des interactions via des QR codes ou des tags NFC. La plupart de ces objets communicants fournissent leurs services sur un r´ eseau local, industriel ou personnel. Le d´ eveloppement du r´ eseau Internet et des infrastructures de la donn´ ee, comme ´ evoqu´ e au paragraphe pr´ ec´ edent, font ´ emerger le concept d’Internet des Objets (IoT), un r´ eseau mondial o` u les objets, les humains et les applications informatiques peuvent communiquer ensemble. La traduction de ce concept a ´ et´ e faite par la cr´ eation d’une nouvelle cat´ egorie de r´ eseaux sans-fil, les r´ eseaux LPWAN pour ”Low Power Wide Area Network”

qui visent ` a ˆ etre l’´ equivalent des r´ eseaux mobiles cellulaires mais adapt´ es aux objets. En effet, les objets transmettent des donn´ ees principalement de capteurs, avec une p´ eriodicit´ e d’´ emission suffisamment faible pour ˆ etre ´ economes en ´ energie. Pour cela, les r´ eseaux LPWAN sont d´ efinis afin d’envoyer des messages courts, sur une longue distance et avec un bilan ´ energ´ etique tr` es faible. Comme pour les r´ eseaux mobiles, la couverture doit ˆ etre globale de fa¸ con ` a rendre les applications de mobilit´ es viables.

Les technologies radios doivent pour exister faire des compromis tr` es importants au niveau de l’´ economie

d’´ energie, du d´ ebit, de la port´ ee, de la s´ ecurit´ e ou encore de la fiabilit´ e. Les applications sont souvent tr` es

exigeantes et n´ ecessitent le choix d’une ou plusieurs technologies adapt´ ees. Aucune technologie assez re-

configurable n’´ emerge de fa¸ con ` a unifier l’ensemble de ces compromis. D` es lors, les ´ equipes de recherche

s’orientent sur la piste de l’interop´ erabilit´ e. Lorsque les applications requi` erent de faire des compromis non

compatibles, les objets deviennent plus complexes en int´ egrant plusieurs technologies radio et en changeant

de mode de fonctionnement suivant l’usage.

Voici le contexte dans lequel les travaux issus de cette th` ese s’int` egrent. L’approche de l’Internet des Objets ne peut se faire sans cette vision globale des enjeux et de l’historique du d´ eveloppement des techno- logies. Nous avons fait le choix de garder cette approche globale, tout en impl´ ementant nos contributions sur une technologie en particulier, les r´ eseaux LoRa. La technologie LoRa permet un acc` es tr` es ais´ e aux composants mat´ eriels et logiciels autant en terme financier qu’en terme technique. Le transmetteur radio est le seul composant de l’architecture qui est prot´ eg´ e ce qui a permis la cr´ eation de briques libres pour chacun des autres composants.

La structure de ce m´ emoire est la suivante : nous d´ etaillons dans le premier chapitre le contexte dans lequel ces travaux ont ´ et´ e effectu´ es. Nous red´ efinissons de mani` ere acad´ emique le concept d’Internet des Objets en insistant sur les diff´ erents enjeux et sous-concepts qui le composent. Ce chapitre constitue les bases th´ eoriques n´ ecessaires ` a la compr´ ehension de nos contributions.

Dans le second chapitre, nous focalisons l’´ etude sur les r´ eseaux LPWAN et plus particuli` erement les r´ eseaux LoRa. Ce chapitre est plus technique et permet d’observer l’application ` a un cas concret des concepts et des enjeux d´ efinis. Nous d´ etaillons les composants logiciels et mat´ eriels n´ ecessaires au d´ eploiement d’une infrastructure de gestion d’un r´ eseau LPWAN.

Le chapitre trois pr´ esente la contribution majeure de cette th` ese, le d´ eveloppement de l’architec- ture et le d´ eploiement d’une plateforme d’enseignement et de recherche pour l’´ etude des r´ eseaux LoRa.

Cette plateforme est constitu´ ee de plusieurs dizaines de passerelles sur la ville de Toulouse, soit un ter- rain d’exp´ erimentation de niveau m´ etropolitain. Notre contribution scientifique consiste ` a proposer une m´ ethode et une architecture pour l’interop´ erabilit´ e de ces r´ eseaux.

Le chapitre quatre montre comment grˆ ace, ` a cette infrastructure, nous avons pˆ u r´ ealiser une ´ etude sur

la couverture et l’extensibilit´ e des r´ eseaux LPWAN. Le d´ eploiement d’une infrastructure d’exp´ erimentation

dans un environnement r´ eel permet de faire des campagnes d’exp´ erimentations pour tester un nouveau

protocole, un nouveau param´ etrage de la couche physique ou encore une nouvelle architecture logicielle.

Chapitre 1

L’Internet des Objets pour l’industrie et les enjeux de l’interop´ erabilit´ e

La r´ ecolte d’informations issues du terrain par un tr` es grand nombre d’objets communicants, est un challenge que de nombreuses entreprises cherchent ` a relever afin d’optimiser leur productivit´ e. Cette r´ ecolte est r´ ealis´ ee par des capteurs de diff´ erentes natures, avec des syst` emes embarqu´ es tr` es diff´ erents en terme d’´ energie et de capacit´ es de calcul. Ces syst` emes cherchent ` a converger vers l’Internet, le r´ eseau IP, au travers d’autres r´ eseaux qui ont tous des performances, des port´ ees et des d´ ebits tr` es in´ egaux. L’in- terop´ erabilit´ e est la capacit´ e que vont avoir ces objets ` a ˆ etre capable de communiquer entre eux malgr´ e la forte h´ et´ erog´ en´ eit´ e des technologies de communication.

Nous allons dans ce chapitre pr´ esenter les origines de l’Internet puis son ´ elargissement aux objets connect´ es. Apr` es un tour d’horizon des diff´ erents enjeux et architectures actuelles, nous expliquerons les choix de notre ´ etude dans le cadre de cette th` ese.

Sommaire

1.1 D´ efinition et origines . . . . 13

1.1.1 D´ efinition . . . . 13

1.1.2 Origines . . . . 19

1.2 L’Internet des Objets pour l’industrie (IIoT) . . . . 22

1.2.1 Vers de nouvelles formes d’organisation des entreprises . . . . 22

1.2.2 Strat´ egie de valorisation des donn´ ees . . . . 24

1.2.3 La probl´ ematique de l’interop´ erabilit´ e . . . . 25

1.3 Etat de l’art scientifique sur l’interop´ ´ erabilit´ e . . . . 27

1.3.1 S´ emantique et encodage des donn´ ees . . . . 27

1.3.2 Architectures interop´ erables pour l’IoT . . . . 28

1.3.3 Protocoles de transport des donn´ ees . . . . 28

1.3.4 Encapsulation des messages . . . . 29

1.3.5 Architecture IoT event-driven . . . . 29

1.4 Les concepts et composants de base de l’IoT . . . . 31

1.4.1 La couche d’acquisition des informations . . . . 32

1.4.2 La couche de collecte des informations . . . . 36

1.4.3 La couche de traitement des informations . . . . 40

1.5 Premi` ere piste d’architecture interop´ erable . . . . 42

1.5.1 Impl´ ementation du mod` ele de graphe de flux . . . . 42

1.5.2 Limitation de Node-RED . . . . 43

1.5.3 Conclusion . . . . 43

1.6 Syst` eme de messagerie pour l’Internet des Objets . . . . 43

1.6.1 Le format et le type des messages . . . . 44

1.6.2 Repr´ esentation au format JSON . . . . 44

1.6.3 Limitations des capacit´ es des objets . . . . 45

1.6.4 N´ ecessit´ e d’un interm´ ediaire . . . . 45

1.7 Garantir l’interop´ erabilit´ e ` a l’aide du protocole MQTT . . . . 46

1.7.1 Int´ erˆ ets . . . . 46

1.7.2 Paradigme Publish/Subscribe . . . . 46

1.7.3 Impl´ ementation des mots cl´ es dans MQTT . . . . 47

1.7.4 Impl´ ementation de la couche transport . . . . 48

1.7.5 Utilisation de MQTT dans le cadre de l’Internet des Objets . . . . 48

1.7.6 Couche de transport augment´ ee en espace utilisateur . . . . 49

1.7.7 Gestion du multicast par la QoS . . . . 49

1.8 Conclusion . . . . 51

1.1 D´ efinition et origines

1.1.1 D´ efinition

1.1.1.1 De l’Internet ` a l’Internet des objets

Le r´ eseau Internet tel que nous le connaissons aujourd’hui en 2020 et qui fait partie de notre quo- tidien (smartphones, tablettes, ordinateurs etc.) est un concept assez complexe ` a appr´ ehender dans son fonctionnement comme dans les enjeux sociaux associ´ es.

Le r´ eseau Internet puise ses racines dans les ann´ ees 1960-1970 lorsque le d´ eveloppement de l’informa- tique dans les grandes universit´ es et les grandes administrations a impos´ e la n´ ecessit´ e d’´ echanger et de partager des informations.

Les syst` emes informatique ` a cette ´ epoque sont tr` es loin de ce que nous connaissons aujourd’hui, les

mainframe ´ etaient des machines tr` es volumineuses et tr` es ch` eres. Seules les plus grandes universit´ es, centres de recherche et administrations ´ etaient capables d’investir l’argent n´ ecessaire dans l’achat d’un mainframe comme le CERN (figure 1.1). La complexit´ e de construction de ces syst` emes et leur faible nombre ont fait que le march´ e ´ etait assez restreint autour de quelques constructeurs (Bull, IBM, etc.).

Figure 1.1 – Le mainframe du CERN en octobre 1963 (http://information- technology.web.cern.ch/about/computer-centre/computing-history)

L’enjeu majeur ` a cette ´ epoque r´ eside sur le mat´ eriel. Historiquement, les premiers d´ eveloppeurs infor-

matique qui concevaient des programmes pour ces syst` emes ´ echangeaient les programmes et les astuces associ´ ees afin de permettre de faire avancer la discipline. Les financiers et les juristes n’´ etant ` a l’´ epoque pas inqui´ et´ es par ces ´ echanges car leurs regards ´ etaient fix´ es autour du mat´ eriel et de son financement.

D` es lors le besoin d’´ echanges entre ces syst` emes informatique est apparu, principalement entre les sites militaires pour le contrˆ ole-commande des sites de lancement d’ogives nucl´ eaires. En 1961 l’US Air Force confie ` a l’ARPA (aujourd’hui DARPA) le d´ eveloppement d’un r´ eseau entre les sites de commandement des bombardements nucl´ eaires. Dans le cahier des charges du projet figure la notion de r´ esilience du r´ eseau afin de ne pas rendre l’ensemble des points de commandement hors d’usage en cas d’attaque nucl´ eaire sur l’un de ces points. C’est pour cela que des travaux ont ´ et´ e men´ es pour concevoir le premier r´ eseau ` a commutation de paquets afin de ne pas avoir d’architecture centralis´ ee.

Ce r´ eseau a ´ et´ e nomm´ e ARPANET et le premier paquet envoy´ e est lo , le 29 octobre 1969, car le syst` eme a plant´ e avant de pouvoir finir d’´ ecrire login .

Tr` es vite les universit´ es am´ ericaines ont ´ et´ e connect´ ees entres elles via ce r´ eseau ARPANET. De 23 noeuds en 1971, le r´ eseau est pass´ e ` a 111 en 1977. La figure 1.2 repr´ esente la carte de ce r´ eseau ` a l’´ epoque.

Figure 1.2 – La carte logique du r´ eseau ARPANET en 1977 (https://fr.wikipedia.org/wiki/ARPANET)

Ce qui est important de comprendre ` a ce moment l` a de l’histoire d’Internet est que l’architecture d´ ecentralis´ ee d’ARPANET qui a ´ et´ e pens´ ee pour sa r´ esilience est devenue une architecture int´ eressante pour les universit´ es. En effet, l’architecture d´ ecentralis´ ee permet de ne pas avoir de prise de pouvoir d’une universit´ e sur les autres d’un point de vue technique car si le r´ eseau d’une universit´ e est en panne, le r´ eseau reste fonctionnel pour les autres car le r´ eseau est maintenu par l’´ etat et donc consid´ er´ e comme

´ equitable face aux diff´ erentes universit´ es.

Le deuxi` eme point important est que les technologies (TCP, HTTP etc... ) qui ont ´ et´ e d´ evelopp´ ees dans le cadre de ce r´ eseau n’ont pas ´ et´ e brevet´ ees et sont rest´ ees ouvertes. Cette logique que l’on va retrouver dans l’Internet des Objets est importante car elle garantit la diss´ emination des techniques d’acc` es au r´ eseau et permet ainsi d’ˆ etre ´ equitable.

Dans les ann´ ees 1970 et 1980, ce r´ eseau va grossir et devenir national aux ´ Etats-Unis, puis mondial.

C’est la naissance d’Internet, un r´ eseau global, non centralis´ e, sans gouvernance et o` u les acteurs locaux peuvent participer au r´ eseau et ` a son infrastructure.

La popularit´ e d’Internet devient r´ eelle ` a partir de la cr´ eation du web et plus particuli` erement du protocole HTTP au d´ ebut des ann´ ees 1990 par Tim Berners-Lee et Robert Cailliau au CERN. Ce protocole va permettre les communications avec des images et du texte dans un navigateur ce qui facilite l’acc` es au r´ eseau et au partage d’informations aux personnes moins qualifi´ ees en informatique ou en r´ eseau.

La navigation sur Internet reste compliqu´ ee par l’absence de moteur de recherche afin de trouver l’URL des sites que l’on veut consulter et de rechercher des sites web en fonction de leur contenu.

Plusieurs moteurs de recherche voient le jour comme Yahoo ! en 1994, Altavista en 1995 puis Google en 1998.

A ce moment de l’histoire, le d´ ` eveloppement des processeurs et du mat´ eriel informatique en g´ en´ eral replace le logiciel au centre des attentions des financiers et des juristes. De nouvelles entreprises de logiciels sont apparues comme Microsoft en 1975 ou Apple en 1976. Ces entreprises d´ eveloppent des logiciels et les revendent sous la forme de licence d’exploitation. C’est un virage fort car c’est le d´ ebut du capitalisme du logiciel par opposition ` a la vision universelle et bas´ ee sur les communs des ann´ ees 1970. Les juristes ont travaill´ e de fa¸ con acharn´ ee pour faire accepter le logiciel comme une œuvre intellectuelle qui appartient

`

a son d´ eveloppeur ou ` a l’entreprise qui embauche le d´ eveloppeur par le biais du copyright. Ce copyright lui donne le droit de d´ efinir les conditions d’utilisation et de distribution de ce logiciel. En r´ eponse ` a ce mouvement d’enfermement des logiciels, Richard Stallman, c´ el` ebre d´ eveloppeur informatique issus du MIT publie en 1989, la premi` ere version de la GNU Public License . Cette premi` ere licence de logiciel libre se base habilement sur le concept de copyright non pas pour restreindre les droits sur le logiciel mais pour les lib´ erer. L’auteur du logiciel c` ede ainsi ses droits ` a la communaut´ e et autorise la distribution, la modification et l’ex´ ecution de ces logiciels ` a n’importe quelle personne.

A partir des ann´ ees 2003, Internet prend un nouveau virage lorsque les grandes entreprises s’aper¸coivent que ce ne sont plus les logiciels qui ont de la valeur mais les informations collect´ ees par leur biais.

C’est l’arriv´ ee des g´ eants du web avec Myspace (2003), Facebook (2004), Youtube (2005) et Twitter (2006). Le business model de ces entreprises est principalement bas´ e sur la collecte et la revente des donn´ ees. On passe d’un mod` ele du web o` u l’on fournit un service souvent gratuit aux clients en ´ echange de bandeaux publicitaires pour financer le service, ` a un mod` ele o` u les clients fournissent gratuitement les donn´ ees au service qui les revend ` a d’autres entreprises. Les internautes sont devenus des fournisseurs de donn´ ees et plus les clients principaux des acteurs majeurs du web.

1.1.1.2 Objets

La notion d’objet dans le contexte de l’Internet des Objets renvoie ` a la d´ efinition d’objet communicant car un objet physique devra ˆ etre en mesure de communiquer pour exister sur le r´ eseau Internet.

Definition 1.1.1. Objet communicant : Syst` eme physique constitu´ e au strict minimum d’un moyen de

communication afin d’´ echanger des informations avec d’autres objets ou des ´ equipements r´ eseaux. Un objet

est g´ en´ eralement constitu´ e de capteurs et/ou d’actionneurs qui permettent d’interagir avec l’environnement

en fonction des informations trait´ ees.

Definition 1.1.2. Capteur : Organe qui ´ elabore, ` a partir d’une grandeur physique, une autre grandeur physique, souvent de nature ´ electrique, utilisable ` a des fins de mesure ou de commande.

Definition 1.1.3. Actionneur : Appareil ou organe permettant d’agir sur une machine ou un processus en vue de modifier son comportement ou son ´ etat.

Les capteurs, les actionneurs et les interfaces de communication sont souvent des circuits standards qui sont assembl´ es ensemble via un circuit imprim´ e (PCB). Afin de pouvoir concevoir des applications sp´ ecifiques, il est n´ ecessaire d’avoir un processeur entre ces ´ el´ ements standards pour pouvoir ´ ecrire un sc´ enario d’interaction suivant l’application.

Definition 1.1.4. Unit´ e de traitement : Organe destin´ e, dans un ordinateur, ` a interpr´ eter et ex´ ecuter des instructions.

Un processeur ex´ ecute un logiciel de fa¸ con s´ equentielle, en r´ ealisant des op´ erations logiques et arithm´ etiques entre diff´ erents emplacements de la m´ emoire. Les p´ eriph´ eriques d’entr´ ees et de sorties ´ etant plac´ es en m´ emoire, il est possible de venir lire un capteur en entr´ ee, r´ ealiser un traitement et piloter un actionneur en sortie. Ce traitement peut aussi concerner l’utilisation de variables internes qui peuvent ˆ etre issues de la fusion d’entr´ ees ou d´ ependantes du temps d’ex´ ecution.

A partir de ces premi` ` eres d´ efinitions, il est possible de faire une repr´ esentation g´ en´ erique d’un syst` eme embarqu´ e comme le montre la figure 1.3.

Capteurs Actionneurs Bus de terrain Unité de traitement

IHM

Figure 1.3 – Mod´ elisation d’un syst` eme embarqu´ e standard

Ce mod` ele est tr` es g´ en´ erique et permet de repr´ esenter la plupart des syst` emes embarqu´ es. Les sections suivantes illustrent et donnent des exemples pour chacun des blocs.

1.1.1.2.1 Capteurs

Les capteurs sont ` a l’interface entre l’´ electronique et le monde physique, nous pr´ esentons ici les diff´ erents types de capteurs.

• Analogiques : ces capteurs sont capables de g´ en´ erer un signal qui est une fonction math´ ematique

d’une grandeur physique. Ce signal va devoir ˆ etre num´ eris´ e par un convertisseur analogique/-

num´ erique afin d’ˆ etre trait´ e

• Num´ eriques (binaire ou TOR) : ces capteurs sont capables de g´ en´ erer un signal bool´ een qui indique le pr´ esence ou non d’une grandeur physique

• Int´ egr´ es : ces capteurs sont constitu´ es d’une chaˆıne compl` ete d’acquisition avec un capteur, le conver- tisseur analogique/num´ erique et une interface de communication num´ erique comme l’I2C ou le SPI 1.1.1.2.2 Actionneurs

Les actionneurs permettent ` a l’´ electronique d’agir sur l’environnement via diff´ erentes formes de trans- fert de puissance.

• Moteurs : la motorisation permet d’entraˆıner des m´ ecanismes et/ou de d´ eplacer un robot ou une machine

• Relais : la commande d’´ equipements de puissance est souvent r´ ealis´ ee via l’ouverture ou la ferme- ture d’un relais. L’avantage d’un relais est ´ egalement de garantir l’isolation galvanique entre les

´ equipements

• Electrovannes : la commande de fluides est souvent r´ ´ ealis´ ee par des ´ electrovannes afin de commuter l’´ ecoulement dans les syt` emes

1.1.1.2.3 Bus de terrain

Les communications entre diff´ erents syst` emes ou sous-syst` emes sont r´ ealis´ ees via des bus de commu- nication ou bus de terrain.

• Bus sans couche physique Ethernet : ces bus sont historiques et permettent d’interconnecter des composants ´ electroniques tr` es simples. Ces bus sont souvent temporellement tr` es stricts et pr´ esents dans les automates comme le bus CAN [1], Modbus[2], Profibus [3], le bus LIN [4]

• Bus avec couche physique Ethernet : avec l’´ evolution des composants ´ electroniques, de plus en plus de composants int` egrent une interface physique Ethernet. Ces nouveaux bus permettent une interop´ erabilit´ e avec les syst` emes informatique existant via une passerelle

1.1.1.2.4 Unit´ e de traitement

L’unit´ e de traitement est le bloc programmable qui permet de r´ ealiser le traitement arithm´ etique et logique ainsi que la gestion de la m´ emoire des syst` emes embarqu´ es.

• Syst` emes ` a base de microcontrˆ oleur : ces syst` emes sont parmi les plus petits syst` emes num´ eriques pro- grammables. Ces syst` emes sont assez limit´ es en capacit´ e de calculs, de m´ emoire et de p´ eriph´ eriques.

Ces syst` emes sont assez complexes ` a mettre en oeuvre parce qu’ils n’ont g´ en´ eralement pas de syst` eme d’exploitation donc le logiciel est tr` es d´ ependant du mat´ eriel

• Syst` emes ` a base de microprocesseur : ces syst` emes int` egrent beaucoup plus de p´ eriph´ eriques comme

des interfaces Ethernet, des cam´ eras, du stockage. Ils ont g´ en´ eralement des syst` emes d’exploitation

plus ´ evolu´ es comme Linux. Il est possible d’avoir des syst` emes d’exploitation temps-r´ eel (avec des

garanties de temps de traitement) ou pas

• Syst` emes informatique : ces syst` emes sont constitu´ es des architectures que l’on peut retrouver dans les ordinateurs ou les serveurs

1.1.1.2.5 Interface Homme-Machine

L’humain a besoin de communiquer au syst` eme des informations de commande, de configuration et d’avoir en retour des indications sur son ´ etat et la prise en compte des ordres. L’ensemble des composants qui r´ ealisent ces fonctions s’appelle une Interface Homme-Machine.

• P´ eriph´ eriques d’entr´ ee : un op´ erateur peut interagir avec le syst` eme via des boutons, des joysticks, un clavier, etc.

• P´ eriph´ eriques de sortie : la machine peut interagir avec l’op´ erateur via des leds, des imprimantes, des dispositifs sonores, des hauts-parleurs etc.

• P´ eriph´ eriques de visualisation : les ´ ecrans tactiles sont de plus en plus utilis´ es car ils permettent une interaction riche via des vid´ eos, des images, des menus

1.1.1.3 Internet des Objets

L’Internet des Objets est comme son nom l’indique l’art de connecter ces objets au r´ eseau Internet mondial.

Les syst` emes embarqu´ es deviennent des syst` emes embarqu´ es communicants via l’ajout d’un module de communication. Le mod` ele de syst` eme embarqu´ e pr´ ec´ edent est ainsi modifi´ e pour ajouter la capacit´ e de communication.

Capteurs Actionneurs Bus de terrain Unité de traitement

IHM Communication

Figure 1.4 – Mod´ elisation d’un syst` eme embarqu´ e communicant

Ce module de communication va permettre l’´ echange de variables internes et d’´ ev` enements entre ce syst` eme et d’autres syst` emes. L’objet peut aussi ˆ etre command´ e ou configur´ e ` a distance.

Le concept d’Internet des Objets permet de relier ces objets au r´ eseau Internet de fa¸ con ` a ce qu’ils

puissent communiquer avec des services h´ eberg´ es sur des serveurs.

1.1.2 Origines

Nous avons parl´ e des origines d’Internet dans la section 1.1.1.1, il est ´ evident que les origines de l’Internet des Objets sont tr` es li´ ees aux origines de l’Internet, qui lui sert de support.

1.1.2.1 Les origines acad´ emiques

Nous avons vu que les origines d’Internet sous tr` es li´ ees au monde acad´ emique via le r´ eseau ARPANET et l’interconnexion des universit´ es aux ´ Etats-Unis. Les objets connect´ es ont ´ et´ e depuis longtemps tr` es

´

etudi´ es sous le nom de r´ eseaux de capteurs sans-fil Wireless Sensor Network.

Et c’est une fois de plus la DARPA qui lance le projet Smart Dust [5] au milieu des ann´ ees 1990. Ce projet militaire a pour but la cr´ eation d’un r´ eseau de capteurs communicants qui peuvent ˆ etre dispers´ es, par avion par exemple, sur une zone assez ´ eparse en vue de collecter des informations sur l’environnement.

Ces capteurs doivent ˆ etre petits pour ˆ etre discrets et sont par nature autonomes en ´ energie.

Ces contraintes fortes ont amen´ e les ´ equipes de recherche ` a cr´ eer de nouveaux syst` emes ´ electroniques toujours plus sobres, de nouveaux syst` emes d’exploitation temps-r´ eel d´ edi´ es aux r´ eseaux de capteurs, ainsi que des protocoles de communication sp´ ecifiques.

Les principaux leviers scientifiques qui ont ´ et´ e ´ etudi´ es dans cette discipline sont les suivants :

• Economie d’´ ´ energie sur les noeuds aliment´ es sur batterie,

• Adaptation du r´ eseau et de ses protocoles aux noeuds mobiles,

• Passage ` a l’´ echelle au niveau protocolaire des r´ eseaux sans fil,

• Cross-layering au niveau des empilements protocolaires,

• Routage multi-saut,

• Auto reconfiguration du r´ eseau.

Les deux principales technologies radio-fr´ equences qui sont sortis de ces travaux sont le Bluetooth [6]

et le standard IEEE 802.15.4 avec diff´ erentes couches hautes dont la plus connue est ZigBee [7].

1.1.2.1.1 IEEE 802.15.4 / ZigBee

Le standard IEEE 802.15.4 est la technologie la plus proche de l’id´ ee de d´ epart des r´ eseaux de capteurs sans fil.

Ce standard d´ efinit la couche physique et la couche de contrˆ ole d’acc` es au m´ edium pour des commu- nications ` a faible port´ ee, ´ economes en ´ energie et avec les fonctions d’organisation du r´ eseau.

Ce standard permet des communications synchronis´ ees via l’´ emission de beacons r´ eguliers ou un mode non synchronis´ e avec une m´ ethode d’acc` es au m´ edium de type CSMA/CA. La th` ese ”Proposition of a new deterministic medium access method for time-constrained wireless personal area networks” [8] d’Adrien Van Den Bossche d´ ecrit ces protocoles d’acc` es au m´ edium et propose une nouvelle m´ ethode d´ eterministe.

Les noeuds du r´ eseau peuvent avoir plusieurs niveaux d’implication dans la gestion du r´ eseau :

• Coordinateur du r´ eseau : c’est le coordinateur du r´ eseau PAN qui d´ efinit la p´ eriode de synchronisation

• Full Function Device : un nœud de type FFD se doit d’impl´ ementer les fonctionnalit´ es de base, ainsi que les fonctions d’agent actif du r´ eseau, en participant au routage des paquets.

• Reduced Function Device : un nœud de type RFD est le nœud le plus simple possible qui impl´ emente uniquement les fonctionnalit´ es de base et qui ne participe pas de fa¸ con active ` a l’organisation du r´ eseau

Le standard IEEE 802.15.4 n’est pas suffisant pour r´ ealiser une application de r´ eseau de capteurs, il a besoin d’une couche r´ eseau qui organise principalement le routage des paquets dans le r´ eseau.

Plusieurs protocoles sans-fil se basant sur les couches IEEE 802.15.4 ont vu le jour comme ZigBee ou 6LoWPAN [9].

Tree

Point to point Star Mesh

Figure 1.5 – Diff´ erentes topologies d’un r´ eseau ZigBee

L’union d’une couche basse IEEE 802.15.4 avec une couche haute de type ZigBee ou 6LoWPAN permet de cr´ eer des r´ eseaux de capteurs avec des topologies ´ etendues comme sur la figure 1.5, de type r´ eseau mesh ou r´ eseau sous forme d’arbre.

Ces technologies permettent bien de r´ epondre ` a la probl´ ematique des r´ eseaux de capteurs sans fil et autonomes en ´ energie, mais quid de la connexion entre ces r´ eseaux et Internet ?

ZigBee qui est la technologie historique n’int` egre pas de solution standard pour les ´ echanges de trames entre le monde IP et le r´ eseau ZigBee. 6LoWPAN est bas´ e sur l’id´ ee de relier ces deux mondes par conception. Cette vision est une des voies qui a bˆ ati la notion d’Internet des Objets, sur l’id´ ee que les services web et les objets doivent ˆ etre capables de dialoguer directement.

Il existe aujourd’hui une gamme de produit ZigBee relativement large avec des ampoules connect´ ees,

des d´ etecteurs et capteurs pour la domotique et quelques projets industriels.

1.1.2.1.2 Bluetooth

La norme Bluetooth a ´ et´ e cr´ e´ e par Ericson en 1994 en plein essor des t´ el´ ephones mobiles. L’objectif d’Ericson ´ etait de favoriser la communication ` a courte distance entre deux t´ el´ ephones mobiles ou entre un t´ el´ ephone mobile et des accessoires.

Voici les principaux cas d’usages de la technologie Bluetooth :

• Communications audio entre un t´ el´ ephone portable et une oreillette, un autoradio, une enceinte,

• Partage de donn´ ees comme un carnet d’adresse entre plusieurs t´ el´ ephones ou un t´ el´ ephone et un ordinateur,

• Communication sans fil entre un ordinateur et un clavier, une souris ou un casque audio.

Bluetooth a longtemps ´ et´ e cantonn´ e ` a ces applications d’accessoires autour du t´ el´ ephone mobile et des ordinateurs. L’id´ ee est de d´ eployer des accessoires ` a proximit´ e du maˆıtre via une liaison sans-fil pour favoriser la mobilit´ e et les interactions dans un rayon proche de l’utilisateur. Ces types de r´ eseaux sont appel´ es piconet ou scatternet dans la version ` a plusieurs sauts.

Au fil des versions du protocole Bluetooth et principalement ` a partir de la version 4.0 et Bluetooth Low Energy (BLE) en 2010, les cas d’usages ont ´ et´ e ´ etendus ` a destination des objets connect´ es qui doivent ˆ

etre ´ economes en ´ energie. Cette volont´ e est observable de plus par l’augmentation de la port´ ee possible ainsi que la r´ eduction de l’impact ´ energ´ etique des protocoles de s´ ecurit´ e [10].

Ces cas d’usages plus r´ ecents peuvent ˆ etre ajout´ es aux anciens :

• Eclairage connect´ ´ e,

• Mat´ eriel m´ edical et sportif : thermom` etre, oxym` etre, glucom` etre, podom` etre,

• Capteurs d’environnement,

• D´ etection de proximit´ e via des balises.

1.1.2.2 L’essor des smartphones

En 2006, la sortie de la technologie 3G permet d’avoir un d´ ebit assez ´ elev´ e pour naviguer sur Internet.

Les op´ erateurs commencent ` a proposer des forfaits avec une limite en volume de donn´ ees par mois qui permet de pouvoir laisser son t´ el´ ephone constamment connect´ e ` a Internet.

Le march´ e va totalement exploser ` a partir de 2007 avec la sortie du premier iPhone. Le t´ el´ ephone mobile se transforme en smartphone par l’ajout d’un grand ´ ecran tactile multipoint, la pr´ esence d’un syst` eme d’exploitation qui s’approche des fonctionnalit´ es que l’on peut avoir sur un ordinateur et le d´ eveloppement du concept d’applications.

En 2005 la guerre des syst` emes d’exploitation fait rage pour faire face ` a Apple qui ´ etait en train de d´ evelopper iOS. Microsoft s’allie avec HTC pour le d´ eveloppement de Windows Phone et Google rach` ete la startup Android.

Chaque syst` eme d’exploitation cr´ ee son SDK afin que chacun puisse d´ evelopper une application mobile

et la distribuer via une application particuli` ere qui sert d’annuaire et de gestionnaire d’installation. Afin

de ne pas avoir ` a cr´ eer une application pour chaque marque de t´ el´ ephone, Android a gagn´ e des parts de march´ e en offrant le syst` eme d’exploitation aux fabricants de smartphones en ´ echange de la pr´ esence des applications de Google par d´ efaut.

La d´ emocratisation entre 2006 et 2010 des smartphones et de leurs applications a permis de mettre dans la poche du tr` es grand nombre, une passerelle entre l’Internet et le monde physique. C’est dans un premier temps l’humain qui est devenu connect´ e, en interagissant avec son environnement au travers d’applications et des capteurs embarqu´ es dans les smartphones. Il a ´ et´ e possible d’envoyer via le r´ eseau 2G/3G/4G ou par WiFi ces informations directement ` a des serveurs distants. C’est l’essor des applications de navigation, des r´ eseaux sociaux, du partage de photos et de vid´ eos en direct etc.

1.1.2.3 Le smartphone comme premi` ere passerelle universelle

Avant l’arriv´ ee des smartphones, les t´ el´ ephones ´ etaient de plus en plus compacts, ce qui rendait la tˆ ache difficile pour l’int´ egration d’antennes et de transmetteurs radio. La tendance a ´ et´ e de limiter la connectivit´ e selon deux axes : les technologies mobiles et WiFi pour la liaison de donn´ ees et Bluetooth pour les accessoires.

Les smartphones qui n´ ecessitent des grands ´ ecrans tactiles ont permis d’inverser la tendance et d’avoir plus de volume pour l’int´ egration de capteurs et de technologies sans fil.

Malheureusement, tr` es peu de technologies ont ´ et´ e int´ egr´ ees en compl´ ement des existantes sauf l’Ultra Wide Band qui a ´ et´ e int´ egr´ e r´ ecemment dans l’Iphone 11 [11]. L’interaction avec les objets connect´ es se fait principalement via le Bluetooth ou le WiFi. Le Bluetooth n’´ etant pas pens´ e pour des r´ eseaux de capteurs

´ etendus, il est limit´ e aux interactions proches de l’utilisateur et donc plutˆ ot pour de la collecte de capteurs ambiants ou d’accessoires. Le WiFi ´ etant plutˆ ot consommateur d’´ energie, il ne peut ˆ etre qu’impl´ ement´ e par des noeuds non ´ economes en ´ energie.

Le probl` eme de concevoir un smartphone comme une passerelle pour un r´ eseau sans fil est limitant du fait que le smartphone est toujours port´ e par l’utilisateur et que l’utilisateur n’est pas toujours ` a port´ ee du r´ eseau de collecte et parfois mˆ eme du r´ eseau op´ erateur.

L’essor des smartphones a bouscul´ e la cr´ eation d’interfaces hommes-machine pr´ esentes sous forme d’´ ecrans LCD, de boutons et de leds en les rempla¸cant par des applications sur smartphone. Le smartphone est utilis´ e dans ce cadre l` a comme une interface homme-machine connect´ ee o` u l’on peut visualiser les informations du syst` eme et interagir avec lui lorsque l’on est proche de lui. La nouveaut´ e est qu’il est possible ´ egalement de transmettre ces donn´ ees ` a un serveur distant, de r´ ecup´ erer des donn´ ees d’autres syst` emes et de cette fa¸ con unir, dans une premi` ere approche le monde physique et le monde du num´ erique.

Il est important de souligner que cette interface permet aussi de g´ erer la mise ` a jour des objets, ce qui est un enjeu primordial autant pour la s´ ecurit´ e que pour la gestion d’un parc d’objets comme nous aurons l’occasion de le voir plus loin.

1.2 L’Internet des Objets pour l’industrie (IIoT)

1.2.1 Vers de nouvelles formes d’organisation des entreprises

Le d´ eveloppement des technologies de l’information et de la communication cr´ ee des modifications profondes dans nos soci´ et´ es.

Dans le pass´ e, l’apparition de l’´ ecriture, de l’imprimerie puis de la presse ´ ecrite a permis de partager

toujours plus d’informations via des supports vari´ es.

Ces technologies permettent au plus grand nombre d’avoir acc` es aux connaissances et de participer ` a cr´ eer, critiquer, modifier et partager ce savoir.

Internet est la derni` ere innovation majeure dans ce domaine. Il est int´ eressant de faire le parall` ele entre l’encyclop´ edie de Diderot qui a ´ et´ e rendue possible grˆ ace ` a l’invention de l’imprimerie et wikipedia, son pendant moderne, qui a ´ et´ e rendu possible grˆ ace ` a Internet.

Les entreprises ont compris que l’apparition de ces nouvelles technologies allait modifier de fa¸ con significative leur fa¸ con de collaborer, de vendre, d’´ echanger, de g´ erer ... et mˆ eme d’enseigner depuis la crise du Covid-19 ! La donn´ ee devient pour les entreprises actuelles une nouvelle source de valeur ajout´ ee et une nouvelle mati` ere premi` ere. Toutes les entreprises produisent des donn´ ees qui peuvent servir ` a mieux comprendre les performances de l’entreprise, les besoins de ses clients, l’´ evolution du march´ e etc.

L’enjeu des entreprises est de prendre conscience de l’existence de ces donn´ ees, du moyen de les collecter, de les prot´ eger et d’ˆ etre capable d’estimer leur valeur marchande.

Un nouveau mod` ele d’organisation des entreprises est en train d’´ emerger : le mod` ele d’holacratie [12].

La figure 1.6 pr´ esente une adaptation de ce mod` ele ` a la gestion des donn´ ees de l’entreprise. Chaque service de l’entreprise rend compte de ses actions non plus par un reporting ´ ecrit ou oral mais par des donn´ ees en continue. Les services rendent compte des variables de l’environnement externe ` a l’entreprise permettant ainsi de num´ eriser de fa¸ con globale l’action de l’entreprise et du contexte de cette ex´ ecution.

Figure 1.6 – Nouvelle forme d’organisation des entreprises autour de la donn´ ee

L’Internet des Objets pour l’industrie s’int´ eresse plus particuli` erement ` a la collecte des donn´ ees et de l’environnement de production, repr´ esent´ e avec des points d’interrogation sur la figure 1.6. Quelles donn´ ees sont pertinentes ? Comment les collecter, les transmettre et les stocker en flux tendu ?

L’id´ ee de cette d´ emarche est de pouvoir par la suite analyser ces donn´ ees centralis´ ees et normalis´ ees

`

a l’aide d’algorithmes afin d’en extraire des tendances, des indicateurs de performance et des d´ ecisions

´ eclair´ ees. Cette vision est d´ evelopp´ ee autour d’une strat´ egie de valorisation des donn´ ees au sein de l’en- treprise.

1.2.2 Strat´ egie de valorisation des donn´ ees

Dans un monde toujours de plus en plus complexe, il devient obligatoire pour prendre des d´ ecisions

´ eclair´ ees, de s’aider d’algorithmes statistiques qui explorent les volumes de donn´ ees m´ etier que poss` ede l’entreprise.

Imaginons un assistant personnel virtuel pour les entreprises ` a qui on puisse poser ce genre de questions :

• O` u dois-je ouvrir une boutique pour minimiser le temps de trajet de mes clients ?

• Quel est l’impact sur les finances de l’entreprise si on d´ ecide de fermer tel site ?

• Quelle est la machine qui a le plus de chance de tomber en panne dans une semaine ?

• Faut-il mieux signer le contrat A ou le contrat B ?

Afin de poursuivre cet objectif, les entreprises investissent de plus en plus dans une strat´ egie en trois

´ etapes comme d´ ecrites sur la figure 1.7.

Figure 1.7 – De la collecte des informations ` a l’agr´ egation et la mod´ elisation

Ces trois grandes ´ etapes qui sont des domaines de recherche ` a part enti` ere, repr´ esentent le cheminement

complet de la collecte d’informations sur le terrain ` a leur interpr´ etation sous forme logique. La figure 1.7

montre par des fl` eches les flux d’informations qui transitent entre les diff´ erentes fonctions. Les objets

connect´ es sont g´ en´ eralement tr` es nombreux et dispers´ es sur le territoire afin de collecter des donn´ ees

r´ eparties dans le p´ erim` etre d’action de l’entreprise. Ces flux de donn´ ees sont collect´ es et rassembl´ es afin

d’ˆ etre trait´ es de fa¸ con unifi´ ee. Il devient n´ ecessaire de sauvegarder ces donn´ ees de fa¸con ordonn´ ee afin

de faciliter par la suite le processus d’extraction. Cette extraction permet par la suite de mod´ eliser et de

transformer ces donn´ ees en informations logiques dans l’objectif de les combiner.

1.2.2.1 Collecte des informations

La collecte des informations dans l’environnement consiste ` a identifier les sources de donn´ ees et ` a mettre en œuvre des techniques d’extraction et de transmission de ces donn´ ees ` a travers diff´ erents r´ eseaux.

Les donn´ ees peuvent ˆ etre collect´ ees via un reporting num´ erique au travers d’applications, de formulaires ou de collecte de photos et de vid´ eos des ´ equipes de terrain. Cette collecte manuelle est per¸cue comme une perte de temps et d’´ energie alors que l’objectif initial doit rester l’optimisation et l’efficacit´ e du travail.

L’Internet des Objets est per¸ cu comme un moyen d’obtenir une partie de ces informations de fa¸ con automatique, en flux tendu de mani` ere ` a all´ eger cette tˆ ache fastidieuse et source d’erreurs. Pour cela, les ´ equipements, les machines, les entrepˆ ots, les usines vont ˆ etre ´ equip´ es de syst` emes embarqu´ es capables d’acqu´ erir et de transmettre ces informations pr´ ecieuses.

1.2.2.2 Agr´ egation des informations

Un fois la collecte r´ ealis´ ee, il est n´ ecessaire de stocker ces informations et de les trier dans des immenses entrepˆ ots de donn´ ees.

La collecte massive d’informations entraˆıne une redondance de l’information. Il faut proc´ eder ` a la suppression des doublons et ` a l’extraction de l’information utile. Par exemple, il est inutile de stocker une photo si l’information utile est par exemple, le nombre d’objets pr´ esents sur la photo.

Cette discipline est connue sous le nom de Big Data o` u l’art de stocker et d’agr´ eger d’´ enormes volumes de donn´ ees. [13]

1.2.2.3 Mod´ elisation des informations

La derni` ere ´ etape consiste ` a cr´ eer des mod` eles statistiques de ces donn´ ees qui vont pouvoir ˆ etre utilis´ es par des algorithmes afin de cat´ egoriser et d’analyser ces donn´ ees.

Le volume de donn´ ee ´ etant trop cons´ equent, le recours ` a des algorithmes d’apprentissage automatique est de plus en plus utilis´ e pour ´ eviter une mod´ elisation complexe.

Des r´ eseaux de neurones artificiels permettent apr` es une phase d’apprentissage sur des jeux de donn´ ees de test, d’ˆ etre en mesure de fournir des fonctions de tris, de d´ ecision, de traitement.

Cette discipline d’apprentissage automatis´ e par la machine est reconnue sous le nom de Machine Learning. [14]

1.2.3 La probl´ ematique de l’interop´ erabilit´ e

Dans une volont´ e de d´ eveloppement de cette strat´ egie, les entreprises investissent dans diff´ erents projets d’optimisation de leurs m´ etiers via la collecte de donn´ ees. Les difficult´ es structurelles et humaines des entreprises et plus particuli` erement des grands groupes, rendent difficile la mise en place d’une politique globale. Il est ais´ e de comprendre qu’une politique globale est n´ ecessaire afin de mutualiser des services, des objets, des moyens humains entre les diff´ erentes applications de mani` ere ` a ne pas multiplier les coˆ uts.

Ces difficult´ es entraˆınent le d´ eveloppement d’applications tr` es disjointes et concurrentes. Imaginez

que, lors du d´ eveloppement d’une nouvelle application qui n´ ecessite les mˆ emes donn´ ees que l’application

pr´ ec´ edente, de nouveaux objets soient d´ eploy´ es ` a quelques centim` etres des autres par ´ echec d’entente entre

les diff´ erents projets. Cette situation peut fait sourire mais est malheureusement r´ ealiste vis-` a-vis de la

complexit´ e des probl` emes humains et structurels.

Les architectures r´ esultantes de ce manque de collaboration sont d´ ecrites comme des silos applicatifs.

Une architecture en silos applicatifs est un ensemble de composants logiciels et mat´ eriels qui sont mis cˆ ote ` a cˆ ote afin de r´ epondre ` a un besoin sp´ ecifique sans se soucier de l’interop´ erabilit´ e. La figure 1.8 repr´ esente ces silos applicatifs dans le cadre d’applications pour l’Internet des Objets. Cette figure montre un enchaˆınement de logiciels et de mat´ eriels du terrain en bas jusqu’aux applications serveurs en haut.

Les donn´ ees transitent ` a travers cet enchaˆınement via diff´ erents protocoles et technologies r´ eseaux. Le concept de silo applicatif consiste ` a critiquer la mise en parall` ele de ce genre d’architecture sans chercher

`

a les unifier d’une fa¸ con ou d’une autre. Les architectures en silo proviennent de probl` emes politiques, techniques ou organisationnels qui motivent cette volont´ e de cloisonner les choses.

Objets de type A Réseau de

type A Plateforme de

type A Base de donnée de

type A Application de

type A

Silo applicatif A

Objets de type B Réseau de

type B Plateforme de

type B Base de donnée de

type B Application de

type B

Silo applicatif B

Objets de type C Réseau de

type C Plateforme de

type C Base de donnée de

type C Application de

type C

Silo applicatif C Figure 1.8 – Architecture en silos applicatifs

D’apr` es ce constat, nous d´ efinissons le sens du mot interop´ erabilit´ e dans le cadre de ces travaux : Definition 1.2.1. Interop´ erabilit´ e : Capacit´ e intrins` eque que poss` ede un syst` eme ` a pouvoir fonctionner avec d’autres syst` emes via la d´ efinition de ses interfaces. Dans le cadre des t´ el´ ecommunications, c’est plus pr´ ecis´ ement la capacit´ e des syst` emes ` a pouvoir communiquer avec d’autres syst` emes existants ou futurs par la d´ efinition d’interfaces de communication.

Par l’exp´ erience acquise durant cette th` ese, nous avons constat´ e que le fonctionnement des entreprises et particuli` erement des grandes entreprises rend souvent difficile le fait d’avoir une politique globale sur des projets diff´ erents. Les projets industriels dans l’Internet des Objets auxquels nous avons ´ et´ e confront´ es, ont ´ et´ e complexes ` a cause de ces mˆ emes raisons.

La principale raison est que les projets sont financ´ es ind´ ependamment et qu’ils sont en concurrence les uns avec les autres. Cette concurrence n’aide pas les diff´ erents projets ` a trouver un terrain d’entente sur des composants mutualisables ou sur des standards communs. Elle n’aide pas non plus ` a s’entendre sur un financement commun de ces ressources.

La deuxi` eme raison est que pour avoir une politique globale, il faut une entit´ e sp´ ecialis´ ee sur les probl´ ematiques d’Internet des Objets et ayant comme mission de chercher ` a mutualiser les ressources, les protocoles, les plateformes, etc.

Ce type d’architecture entraˆıne bien souvent des inter-d´ ependances entre les maillons de la chaˆıne

d’information. Ceci veut dire que le flux d’information transite de composant en composant et que chaque

maillon est effectivement d´ ependant de ses voisins.

Ces architectures sont difficiles ` a maintenir car g´ en´ eralement une erreur est constat´ ee dans l’interface de visualisation et il est difficile de trouver le maillon fautif dans la chaˆıne. Il est n´ ecessaire d’avoir un acc` es ` a l’interface entre chaque maillon afin de diagnostiquer dans quel maillon se situe l’erreur ou le d´ ebut d’erreur.

Ces architectures ne permettent pas de mutualiser les ressources, par exemple si une standardisation est faite au niveau de la base de donn´ ee, il est possible que les applications puissent facilement ˆ etre ´ evolutives sans gros efforts lorsque de nouveaux objets vont ˆ etre d´ eploy´ es.

Ce type d’architecture peut entraˆıner des coˆ uts ´ elev´ es s’il faut d´ eployer plusieurs infrastructures de r´ eseaux ou venir dupliquer des objets connect´ es pour en avoir un par application.

Afin de chercher une solution technique ` a cette probl´ ematique, il faut chercher des pistes d’interop´ erabilit´ e des composants par design en proposant de nouvelles architectures favorisant cette interop´ erabilit´ e. Comme nous l’avons d´ ecrit, ces probl´ ematiques ne sont pas uniquement d’ordre technique et n´ ecessitent des chan- gements profonds dans les organisations qui sortent du cadre de cette th` ese.

1.3 Etat de l’art scientifique sur l’interop´ ´ erabilit´ e

Nous pr´ esentons dans cette section une liste de travaux qui ont ´ et´ e propos´ es au sujet de l’interop´ erabilit´ e dans le contexte de l’Internet des Objets. Cette th´ ematique est tr` es importante dans le cadre de d´ eploiements r´ eels car l’id´ ee derri` ere l’interop´ erabilit´ e est de p´ erenniser dans le temps une application et d’´ eviter les solutions qui ne peuvent pas dialoguer ensemble. De cette fa¸ con, une couche d’interop´ erabilit´ e peut ˆ etre impl´ ement´ ee dans l’empilement de telle sorte que les objets puissent ˆ etre rempla¸cables facilement et avec peu d’impact sur les logiciels applicatifs.

Cette couche d’interop´ erabilit´ e peut ˆ etre impl´ ement´ ee de diff´ erentes mani` eres, nous avons observ´ e dans la litt´ erature ci-apr` es trois principales mani` eres, par codage, par design et par un protocole de transport.

1.3.1 S´ emantique et encodage des donn´ ees

Une premi` ere piste d’interop´ erabilit´ e qui a ´ et´ e ´ etudi´ ee est la d´ efinition d’un encodage standard des donn´ ees. L’id´ ee est que les r´ eseaux de syst` emes embarqu´ es communicants transportent la plupart du temps des informations issues de capteurs, d’actionneurs ou d’IHM et que c’est la mani` ere de repr´ esenter ces informations qui peut ˆ etre unifi´ ee afin de cr´ eer de l’interop´ erabilit´ e ` a la source.

OneM2M est une initiative de standardisation des architectures IoT. Dans le cadre de cette initiative, une d´ emarche de d´ efinition d’une ontologie a ´ et´ e effectu´ ee sous le nom de IoT-O. L’article ”Toward semantic interoperability in oneM2M architecture” [15] publi´ e en 2015 par ”IEEE Communications Magazine” d´ ecrit cette ontologie ainsi que des cas d’usage.

Une seconde initiative issue de l’IETF cette fois, propose SenML [16], une s´ emantique pour l’encodage de donn´ ees via CoAP ou HTTP. Cette s´ emantique peut ˆ etre ´ egalement utilis´ ee avec d’autres proto- coles de transport que ceux standardis´ es par l’IETF comme MQTT, dans la plateforme IoT open-source Mainflux[17]. Un ensemble de symboles sont d´ efinis pour repr´ esenter les unit´ es ou les labels ` a donner aux variables.

Ce champ de recherche est tr` es sp´ ecifique et rel` eve plus de la mod´ elisation que de la recherche en

r´ eseau, ainsi nous avons ´ ecart´ e cette piste dans le cadre de notre ´ etude.

1.3.2 Architectures interop´ erables pour l’IoT

Le survey ”Middleware for Internet of Things : A Survey” [18] est particuli` erement int´ eressant et original car il traite de l’interop´ erabilit´ e par design en pr´ esentant diff´ erents mod` eles. Ce survey a ´ et´ e publi´ e en novembre 2015 dans l’”IEEE Internet of Things Journal”. Il montre diff´ erentes architectures permettant d’offrir une interop´ erabilit´ e :

• une gestion par ´ ev` enement, avec la transmission d’´ ev` enements aux applications concern´ ees,

• une gestion par service, lorsque les donn´ ees traversent diff´ erents services logiciels qui traitent des fonctions sp´ ecifiques,

• une architecture par machine virtuelle (VM), avec des fonctions tr` es s´ epar´ ees qui sont unifi´ ees au plus proche des applications par une VM d’interop´ erabilit´ e,

• une architecture multi-agents, avec une grande importance donn´ ee aux objets qui impl´ ementent des fonctions d’interop´ erabilit´ e de tr` es bas niveau,

• une gestion par base de donn´ ees, lorsque les donn´ ees sont toutes stock´ ees dans des bases de donn´ ees ou des tables s´ epar´ ees par fonction et o` u les applications viennent g´ erer l’interop´ erabilit´ e en r´ ecup´ erant les donn´ ees dans toutes les bases de donn´ ees.

Cet article ne traite pas des architectures ` a base de conteneurs que nous allons ´ etudier dans cette th` ese.

1.3.3 Protocoles de transport des donn´ ees

La probl´ ematique de l’interop´ erabilit´ e peut ˆ etre trait´ ee au niveau r´ eseau en normalisant un protocole de transport. En effet, l’Internet des Objets int` egre forc´ ement la notion de r´ eseau o` u des messages transitent d’objets en objets puis ` a travers des passerelles rejoignent des serveurs en passant par le r´ eseau Internet.

De par cette nature de transport de donn´ ees, la couche de transport est id´ eale pour prendre en charge cette convergence.

De nombreux protocoles existent dans la litt´ erature et sont d´ ej` a mis en œuvre dans des applications IoT pour le transport des donn´ ees. Le tableau 1.1 liste les protocoles les plus r´ epandus actuellement.

De nombreux papiers ont apport´ e des ´ el´ ements de comparaison entre ces protocoles comme ”Choice of effective messaging protocols for IoT systems : MQTT, CoAP, AMQP and HTTP” [19] publi´ e en 2017 dans ”IEEE International Systems Engineering Symposium (ISSE)” duquel est extrait en partie le tableau 1.1.

Protocole MQTT AMQP CoAP HTTP

Ann´ ee 1999 2003 2010 2003

Paradigme Publish/Subscribe Producer/Consumer Request/Response Request/Response

Transport TCP TCP UDP TCP

S´ ecurit´ e TLS TLS DTLS TLS

Ports 1883/8883 5671/5672 5683/5684 80/443

Format Binaire, texte Binaire, texte Binaire, texte Binaire, texte

Licence Open Source Open Source Open Source Libre

Contraintes Faible Forte Tr` es faible Moyenne

Table 1.1 – Principaux protocoles de transport pour l’IoT