SlideShare une entreprise Scribd logo
MINISTERE DE L’ENSEIGNEMENT SUPERIEUR DE LA RECHERCHE SCIENTIFIQUE ET DE LA
TECHNOLOGIE
UNIVERSITE TUNIS EL MANAR
ÉCOLE NATIONALE D’INGENIEURS DE TUNIS
DEPARTEMENT TECHNOLOGIES DE L’INFORMATION ET DE LA COMMUNICATION
Projet de Fin d’études
Présenté par
Chaieb Ghassene
Pour l’obtention du
Le Diplôme National d’Ingénieurs en Télécommunications
Sujet
TelCar
Solution de lecture des informations de bord de véhicule
Réalisé à
TELNET Innovation Labs
Jury :
Président : M. Rabah JERAD (Groupe TAWASOL)
Co-Présidente : Mme Houria REZIG (ENIT)
Rapporteur : M. Mahmoud AMMAR (ENIT)
Encadrant Telnet : M. Mourad ZERIBI (Telnet Holding)
Encadrant ENIT : M. Taher EZZEDINE (ENIT)
Soutenu le 02/06/2016
Année universitaire : 2015-2016
Signatures des encadrants
M. Mourad ZERIBI
M. Taher EZZEDINE
Remerciements
Dédicaces
Avec tout respect et amour je dédie ce modeste travail
À mes chers parents :
Aucune dédicace ne saurait exprimer l’amour, l’estime, le dévouement
et le respect que j’ai toujours eu pour vous. Ce travail est le fruit de
vos sacrifices que vous avez consentis pour mon éducation et ma
formation.
À ma cher ma chère fiancée Sabrine
Pour tout l'amour et le soutien que tu m'as offert. Que dieu réunisse
nos chemins pour un long commun serein
À tous mes frères et mes amis,
Pour tous les instants inoubliables que j'ai passés avec vous. Je vous
souhaite le succès dans vos vies.
À tous ceux que j'aime et qui m'aiment.
Je dédie ce travail espérant avoir répondu à leurs souhaits de me
voir réussir.
Chaieb Ghassene
Résumé
La nécessité de contrôler nos véhicules, les suivre en temps réel nous a poussé de créer
le boîtier « TelCar » qui se connecte à la prise diagnostic d'une voiture. Autonome, il
communique avec un smartphone et offre une palette de services dignes des derniers
modèles de voitures haut de gamme.
Notre solution est composée de trois parties :
 La partie embarquée qui permet de collecter les informations de bord
du véhicule à travers le réseau CAN et d’envoyer des données au serveur
de l’application.
Mots clé : Internet des objets, Gateway, Raspberry pi, Services Web, Cloud
Abstract
The need to control our vehicles, track it in real time have pushed us to create the
"Telcar" box that connects to the diagnostic socket of a car. Autonomous, it
communicates with a smartphone and offers a range of services worthy of the latest
models of high-end cars.Our solution consists of three parts:
 The mobile part that allows the customer to control their cars via smartphone
(maintenance expenses, diagnostics, recommendations, etc.);
 A Back Office that allows managers to manage and control the functionality of
the application ;
 The board part that collects the edge information of the vehicle through the CAN
network and send data to the application server.
Keywords: Internet of Things, Gateway, Raspberry Pi, Web Services, Cloud
Table des matières
Introduction générale...........................................................................................1
Chapitre 1 Etat de l’art et solution proposée ......................................................2
1. Introduction................................................................................................................................3
2. Contexte du projet ......................................................................................................................3
2.1 Cadre du projet...................................................................................................................................3
2.2 Entreprise d’accueil : Telnet Holding..................................................................................................3
2.3 Problématique....................................................................................................................................4
3. Etude de l’existant.......................................................................................................................4
3.1 ZUS .....................................................................................................................................................4
3.2 CanCan............................................................................................................................................5
4. Solution et architecture proposée................................................................................................5
4.1 Solution ..............................................................................................................................................5
4.2 Architecture proposée........................................................................................................................6
5. Choix des technologies ................................................................................................................7
5.1 La Plate-forme Cloud IoT ....................................................................................................................7
5.1.1 Critères de choix..........................................................................................................................7
5.1.2 Étude comparative et choix de la plate-forme ............................................................................8
5.1.3 La plate-forme Xively...................................................................................................................8
5.2 La Gateway : Raspberry Pi ..................................................................................................................9
5.3 Le module Qualcomm EC20 LTE ......................................................................................................10
5.4 Le langage de programmation : Python............................................................................................10
5.5 Les web services ...............................................................................................................................11
5.5.1 Introduction...............................................................................................................................11
5.5.2 Service Web REST ......................................................................................................................11
5.5.3 Avantages de REST.....................................................................................................................12
5.5.4 Limites de REST..........................................................................................................................12
6. Conclusion ................................................................................................................................12
Chapitre 2 Etude et implémentation de la partie embarquée .............................. 13
1. Introduction..............................................................................................................................14
2. Préparation du Raspberry Pi ......................................................................................................14
2.1 Le Système d’exploitation Raspbian.................................................................................................14
2.2 Compilation croisée du module Linux pour Raspberry Pi .................................................................14
2.3 Connexion à distance au Raspberry pi : le protocole SSH.................................................................15
3. Le pilote QMI WWAN pour Quectel EC20 LTE .............................................................................15
3.1 Le protocole QMI..............................................................................................................................15
3.2 Le contrôleur ModemUP ..................................................................................................................16
3.3 Système GNSS/GPS...........................................................................................................................17
4. Lecture des informations de bord de véhicule ............................................................................18
4.1 Traitement des données du réseau CAN ..........................................................................................18
4.2 Communication SPI Raspberry-Microcontrôleur..............................................................................18
4.3 Protocole de communication ...........................................................................................................20
4.3.1 Format de la trame envoyée par le Raspberry ..........................................................................20
4.3.2 Format de la trame envoyée par le microcontrôleur.................................................................21
4.3.3 Contrôle de redondance cyclique (CRC) ....................................................................................21
5. Conclusion ................................................................................................................................21
Chapitre 3 Etude et implémentation de la partie BackOffice............................... 22
1. Introduction..............................................................................................................................23
2. Xively - Notions de base ............................................................................................................23
3. La phase de Développement......................................................................................................23
3.1 Xively Developer Workbench ...........................................................................................................24
3.1.1 Les canaux (Channels)................................................................................................................24
3.1.2 La localisation ............................................................................................................................25
3.1.3 Les déclencheurs .......................................................................................................................25
3.2 L’API REST de Xively..........................................................................................................................25
3.3 Création de périphérique .................................................................................................................27
3.4 Création des déclencheurs (Triggers) ...............................................................................................28
3.4.1 Zapier.........................................................................................................................................28
3.4.2Twilio..........................................................................................................................................29
4. La phase de Déploiement ..........................................................................................................29
4.1 Le processus de provisionnement ....................................................................................................30
4.2 Le scénario d'activation de l’appareil ...............................................................................................30
5. La phase de Gestion ..................................................................................................................31
6. Conclusion ................................................................................................................................32
Chapitre 4 Réalisation et tests de validation de notre solution ........................... 33
1. Introduction..............................................................................................................................34
2. Préparation du Raspberry Pi ......................................................................................................34
2.1 Installation du système d’exploitation Raspbian ..............................................................................34
2.2 Connexion à distance au Raspberry pi..............................................................................................34
2.3 Cross-compilation du module Linux .................................................................................................36
2.3.1 Compilation Locale sur Raspberry Pi .........................................................................................36
2.3.2 Compilation croisée avec Toolchain ..........................................................................................36
3. Installation du driver QMI WWAN pour Quectel EC20 ................................................................37
4. Création de l’application avec Xively..........................................................................................38
4.1 La phase de Développement : ..........................................................................................................38
4.1.1 Prototypage...............................................................................................................................38
4.1.2 Création de déclencheur avec Zapier ........................................................................................39
4.2 La phase de Déploiement .................................................................................................................40
5. Tests de validation ....................................................................................................................41
5.1 Activation de l’appareil.....................................................................................................................41
5.2 Envoi des données à la plateforme Xively ........................................................................................41
5.3 Envoi des données de localisation....................................................................................................42
5.4 Test des déclencheurs ......................................................................................................................43
6. Conclusion ................................................................................................................................43
Conclusion générale........................................................................................... 44
Bibliographie...................................................................................................... 45
Liste des figures
Figure1. 1 : Logo de Telnet Holding..................................................................................................................3
Figure1. 2 : La solution ZUS ..............................................................................................................................5
Figure1. 3 : Logo de la solution CanCan............................................................................................................5
Figure1. 4 : Architecture globale de la solution proposée................................................................................6
Figure1. 5 : Logo de Xively................................................................................................................................8
Figure1. 6 : La carte Raspberry Pi .....................................................................................................................9
Figure1. 7 : Le module Qualcomm EC20 LTE .................................................................................................10
Figure1. 8 : Logo de Python............................................................................................................................10
Figure2. 1 : Logo du système d'exploitation Raspbian ...................................................................................14
Figure2. 2 : Le diagramme d'états-transitions du script ModemUp ...............................................................16
Figure2. 3 : Communication SPI entre Master-slave ......................................................................................18
Figure2. 4 : Liaison SPI entre le Raspberry et le microcontrôleur...................................................................19
Figure2. 5 : Format de trame envoyée par le Raspberry ................................................................................20
Figure2. 6 : Format de la trame envoyée par le microcontrôleur...................................................................21
Figure3.1 : Logo de Xively Developer Workbench.........................................................................................23
Figure3.2 : Capture d'écran de l'interface Xively Developer Workbench .....................................................24
Figure3.3 : Architecture API/services de Xively .............................................................................................25
Figure3.4 : les Logos des bibliothèques de Xively...........................................................................................28
Figure3.5 : Logo de Zapier .............................................................................................................................28
Figure3.6 : Capture d'écran de site web Zapier.com .....................................................................................29
Figure3.7 : Logo de Twilio..............................................................................................................................29
Figure3.8 : Capture d'écran de la console de gestion....................................................................................31
Figure4.1 : Installation du Raspbian avec Win32 Disk Imager .......................................................................34
Figure4.2 : Capture d'écran del 'interface graphique du Raspberry sur VNC Viewer. ....................................35
Figure4.3 : Réservation de l'adresse 192.168.0.100 au Raspberry ................................................................35
Figure4.4 : Le menu USB Network Adaptaters de Raspbian..........................................................................37
Figure4.5 : les interfaces réseau de notre Raspberry ....................................................................................38
Figure4.6 : Xively Developer Workbench ......................................................................................................39
Figure4.7 : Création de déclencheur avec Xively et Zapier............................................................................39
Figure4.8 : Capture d'écran de la phase de déploiement..............................................................................40
Figure4.9 : Insertion des numéros de série des périphériques......................................................................40
Figure4.10: Activation du périphérique..........................................................................................................41
Figure4.11: Envoi des données à la plateforme Xively ...................................................................................41
Figure4.12: Visualisation des données ...........................................................................................................42
Figure4.13: Lecture des données de localisation ...........................................................................................42
Figure4.14: Envoi des données de localisation à la plateforme Xively ...........................................................43
Figure4.15: La localisation du périphérique avec Xively.................................................................................43
Figure4.16: Résultat du déclencheur..............................................................................................................43
Liste des tableaux
Tableau1. 1 : tableau comparatif des plateformes Cloud IoT...........................................................................8
Tableau 2 : Lees opérations accessibles via l'API REST de Xively....................................................................26
Liste des acronymes
AES : Advanced Encryption Standard
API : Application Programming Interface
CAN : Controller Area Network
CoAP : Constrained Application Protocol
CPU : Central Processing Unit
CRC : Cyclic Redundancy Check
CRUD : Create, Read, Update, Delete
CSV : Comma-Separated Values
DHCP : Dynamic Host Configuration Protocol
GLONASS : GLObal NAvigation Satellite System
GNSS : Global Navigation Satellite System
GPIO : General Purpose Input/Output
GPS : Global Positioning System
GSM : Global System for Mobile communications
HTML : Hypertext Markup Language
HTTP : HyperText Transfer Protocol
IdO : Internet des Objets
IoT : Internet of Things
IP : Internet Protocol
IPsec : Internet Protocol Security
JSON : JavaScript Object Notation
LTE : Long Term Evolution
MAC : Media Access Control
MQTT : Message Queuing Telemetry Transport
OBD : On-Board Diagnostics
PaaS : Platform as a Service
PCI : Peripheral Component Interconnect
QMI : Qualcomm Mobile Station Modems Interface
REST : REpresentational State Transfer
SPI : Serial Peripheral Interface
SSH : Secure SHell
URI : Uniform Resource Identifier
URL : Uniform Resource Locator
VNC : Virtual Network Computing
XML : eXtensible Markup Language
1
Introduction générale
Selon l’Union internationale des télécommunications, l’Internet des objets (IdO) est une
«infrastructure mondiale pour la société de l'information, qui permet de disposer de services évolués
en interconnectant des objets (physiques ou virtuels) grâce aux technologies de l'information et de la
communication interopérables existantes ou en évolution ». [1]
L’IdO couvre actuellement plusieurs applications telles que:
 les téléphones portables;
 les compteurs électriques « intelligents » qui donnent un compte-rendu de la
consommation en temps réel;
 les « objets intelligents » dans le secteur de la logistique, l’industrie manufacturière
ou la vente au détail.
 Etc.
Parmi les domaines dans lesquels l’internet des objets intervient, nous allons se focaliser sur le secteur
de l’automobile.
En effet, Connaître l'emplacement de sa voiture en temps réel ou recevoir des informations sur son
état actuelle sont des fonctionnalités que les constructeurs de véhicule ont déjà intégrées dans leurs
modèles de voitures haute gamme.
Dans le cadre de ce projet de fin d’études réalisé à « Telnet innovation Labs », Nous nous proposons
de mettre les fonctionnalités citées ci-dessus, à la disposition des voitures entrée de gamme. Nous
proposons ainsi une solution baptisée « TelCar » qui consiste en un boitier à brancher sur la prise de
diagnostic OBD d’un véhicule. Cette boite sera capable de traiter et d’envoyer les informations de
bord au serveur de gestion. Une application mobile sera par la suite capable de récolter ces
informations et les présenter d’une manière simple à l’utilisateur.
Dans ce cadre nous allons particulièrement nous intéresser à deux parties de ce projet :
a) Développer une solution permettant d’envoyer les informations de bord d’un véhicule à un
serveur d’application,
b) Développer la partie BackOffice permettant de gérer l’ensemble des nœuds (Véhicule) et de
contrôler le fonctionnement de l’application.
Pour présenter la démarche que nous avons suivie, notre rapport se présente de la façon
2
Suivante :
Le premier chapitre sera consacré à la présentation du contexte du projet, une étude des applications
existantes et un aperçu sur notre solution ainsi que les technologies à utiliser.
Le deuxième chapitre présentera une étude de la partie embarquée de cette solution. Ensuite, la
troisième partie mettra l’accent sur l’étude et l’implémentation de la partie BackOffice. Enfin, le
dernier chapitre détaillera les différentes étapes réalisé ainsi que les tests de validation.
Nous finissons le rapport par une conclusion générale.
2
Chapitre 1
Etat de l’art et solution proposée
Sommaire
1. Introduction................................................................................................................................3
2. Contexte du projet ......................................................................................................................3
3. Etude de l’existant.......................................................................................................................4
4. Solution et architecture proposée................................................................................................5
5. Choix des technologies ................................................................................................................7
6. Conclusion ................................................................................................................................12
1. Introduction..............................................................................................................................14
3
1. Introduction
Dans ce chapitre, Nous exposons le contexte général du projet ainsi que la démarche
et les technologies qui vont nous servir à mieux comprendre notre sujet.
2. Contexte du projet
2.1 Cadre du projet
2.2 Entreprise d’accueil : Telnet Holding
Figure1. 1 : Logo de Telnet Holding
TELNET est un groupe de sociétés tunisien spécialisé dans le conseil dans l'innovation
et les hautes technologies. Crée en 1994, Elle est rapidement devenue leader dans son cœur de métier
à l’échelle nationale. Elle a cherché depuis sa création à élargir ses champs de compétences afin
de proposer à ses clients des prestations de qualité et diversifiées selon les spécifications demandées.
4
Dans un souci de proximité de ses clients, TELNET opère selon un modèle Front office / back
office, elle propose essentiellement des prestations d’ingénierie en Offshore pour et en Nearshore
pour le compte des plus grands groupes internationaux.
Elle est considérée comme un acteur majeur dans le domaine des hautes technologies et occupe
un positionnement de plus en plus important à l’échelle régionale. Elle développe une expertise métier
notamment dans le développement de Systèmes Intégrés le design Électronique et Microélectronique
ainsi que dans l’Ingénierie Mécanique. (Telnet holding, 2009)
2.3 Problématique
Surveillez et soyez alertez à tout moment si votre voiture est en mouvement, prévenez les services
d’urgence en cas de panne, malaise et automatiquement en cas d’accident en communiquant votre
position géographique et suivre l’état de votre véhicule (dépenses, entretiens, diagnostique, etc.) sont
des fonctionnalités disponibles sur les véhicules neufs possédant un système communicant.
Mais ce sont généralement les véhicules sophistiqués des marques premium et qui coûte très cher.
Est-il possible de profiter des mêmes services avec n'importe quelle voiture, pour peu qu'elle soit âgée
de moins de quinze ans et possède une prise diagnostic ?
3. Etude de l’existant
3.1 ZUS
ZUS est un chargeur allume-cigare. À part recharger les mobiles sur la route, il fait également office
de traqueur Bluetooth afin de localiser la voiture depuis un smartphone. Il peut ainsi se servir
du GPS embarqué du mobile pour suivre et localiser l’emplacement de la voiture dès que le moteur
est éteint.
5
De cette manière, l’utilisateur est en mesure de retrouver facilement sa voiture même dans un parking
bondé. (Nonda, 2016)
Figure1. 2 : La solution ZUS
Le coût de la solution : $49.99
Limites : - Aucune interaction avec le réseau CAN de la voiture.
- Absence de Web services
3.2 CanCan
Figure1. 3 : Logo de la solution CanCan
CanCan délivre un diagnostic rapide du véhicule à chaque démarrage, grâce au dialogue avec
le réseau de bord CAN via la prise OBD. Cette boite communique en Bluetooth avec une application
sur smartphone. (Cancan, 2015)
Le coût de la solution : $200
Limites : - La solution n’offre pas une communication à distance (via des services Web) avec
l’utilisateur.
4. Solution et architecture proposée
4.1 Solution
Connaître l'emplacement de sa voiture en temps réel ou recevoir des informations sur son type
de conduite, ces applications sont déjà disponibles sur les véhicules neufs possédant un système
communicant. Mais ce sont généralement les véhicules sophistiqués des marques premium.
6
Toutefois, il reste possible de profiter des mêmes services avec n'importe quelle voiture, pour peu
qu'elle soit âgée de moins de quinze ans et possède une prise diagnostic. Notre solution baptisé
TelCar consiste à utiliser un boîtier à brancher sur cette prise OBD.
TelCar recueille les informations de bord du véhicule (celles du Bus Can) et possède son propre
module LTE. Communicant en réseau avec une application sur un smartphone, elle lui envoie toutes
les informations récoltées.
4.2 Architecture proposée
Comme il est indiqué dans la figure 1.4, notre solution se compose de trois parties :
 Une partie embarquée qui permet de collecter les informations de bord du véhicule à travers
le réseau CAN et d’envoyer des données au serveur de la plateforme Cloud Iot;
 Une partie BackOffice qui permet aux responsables de gérer et contrôler le fonctionnement de
l’application. Cette partie est centralisée dans une plate-forme Cloud IoT et permet de :
Ajouter/supprimer une véhicule Ajouter/supprimer un service, Stocker les données
et les métadonnées de chaque véhicule, etc;
 Une application mobile (FrontOffice) qui permet au client de contrôler ses voitures (entretiens,
diagnostique, recommandations, …).
Figure1. 4 : Architecture globale de la solution proposée
7
La communication entre les différentes composantes de la solution se fait à travers un web service
qui garantit l’interopérabilité.
Dans le cadre de notre projet de fin d’études, nous allons se focaliser sur deux parties de ce projet :
c) Développer une solution permettant d’envoyer les données du réseau CAN supposés déjà
traités,
d) Développer la partie BackOffice sur une plate-forme Cloud IoT permettant de gérer
l’ensemble des nœuds (Véhicule) et de contrôler le fonctionnement de l’application.
5. Choix des technologies
5.1 La Plate-forme Cloud IoT
Les plates-formes de l'Internet des objets (IdO) permettent de connecter des appareils hétérogènes
des applications et les faire communiquer entre eux. Elles jouent un rôle crucial pour réduire le coût
de développement des solutions et des applications IdO.
Elles permettent non seulement de connecter des objets, mais aussi d’implémenter des protocoles
de communication complexes et variés.
Ces plates-formes offrent aussi toute l’infrastructure back-end nécessaire pour le développement
des applications dédiées à l’internet des objets : management des objets, bases de données, serveurs
etc.
Aujourd'hui il existe plusieurs plates-formes IdO disponibles sur le marché. Une étude comparative
est indispensable pour bien choisir la solution.
5.1.1 Critères de choix
Savoir identifier la bonne plate-forme cloud IoT à utiliser sera un enjeu important et critique pour
la conception de notre projet. Le choix est basé sur 4 critères :
 Ouverture : C’est une caractéristique importante attendue d’une plate-forme cloud Iot.
L’interface de programmation applicative (API) devrait fournir un accès aux opérations
et aux données qui doivent être exposés à partir de la plate-forme. Ceci permet
aux applications et aux appareils hétérogènes de communiquer entre eux facilement. Souvent
on utilise des API REST pour atteindre cet objectif.
8
 Gestion des objets connectés : La plate-forme devrait maintenir une liste des périphériques
connectés et dépister leur état de fonctionnement.
 Sécurité et confidentialité : la connexion réseau entre les objets connectés et la plate-forme
IoT devrait être chiffrée avec un mécanisme de cryptage fort pour éviter tout espionnage
éventuel
 Protocoles de collecte de données : Une plate-forme IoT peut être relié à des millions voire
des milliards d’objets connectés (nœuds). Des protocoles de communication légers devraient
être utilisés pour garantir une faible consommation d’énergie et de bande passante.
5.1.2 Étude comparative et choix de la plate-forme
Tableau1. 1 : tableau comparatif des plateformes Cloud IoT
plate-forme
Cloud IoT
Gestion des
objets
API Sécurité Protocoles de
communication
Prise en
charge de la
visualisation
Appcelerator Non API REST Link
Encryption
(SSL, IPsec,
AES)
MQTT, HTTP Oui
Ericsson MDM
IoT Platform
Oui API REST Link Encryption
(SSL/TSL)
CoAP Non
Xively Oui API REST Link Encryption
(SSL/TSL)
HTTP, HTTPS,
Sockets/
Websocket,
MQTT
Oui
En tenant compte du tableau 1.1, nous pouvons déduire que la plate-forme Xively représente un outil
plus performant et mieux adapté à nos besoins. Elle offre des fonctionnalités avancés de gestion
des nœuds et utilise des protocoles de communication légers.
5.1.3 La plate-forme Xively
Xively est une « Platform as a Service » (PaaS) pour l'internet des objets. Xively simplifie
l'interconnexion d'équipements, des données, des personnes et des lieux en accélérant la création
de solutions convaincantes qui transforment la façon dont les gens vivent leur monde. (Xively,
Figure1. 5 : Logo de Xively
9
5.2 La Gateway : Raspberry Pi
La Gateway c’est la composante qui va assurer le transfert des données du véhicule vers
la plate-forme Cloud.
Parce qu'il est équipé d’un processeur ARMv7, il est capable de faire tourner toute la gamme
des distributions ARM GNU / Linux, y compris Snappy Ubuntu Core, ainsi que Microsoft Windows
10 IoT. Il est équipé de :
 CPU quad-core ARM Cortex-A7 900MHz
 1GB de RAM
 4 ports USB
 40 broches GPIO
 Port HDMI
 Port Ethernet
 Prise Jack
 Interface d'appareil photo
 Interface d'affichage
Figure1. 6 : La carte Raspberry Pi
10
5.3 Le module Qualcomm EC20 LTE
Figure1. 7 : Le module Qualcomm EC20 LTE
Le module Quectel EC20 LTE offre une connectivité de données sur les réseaux LTE, WCDMA
et les réseaux GSM avec l’interface standard PCI Express 1.2.
Il prend en charge plusieurs systèmes d'exploitation tels que WinCE, Linux et Android, etc.
Il est aussi équipé d’un récepteur GNSS qui supporte le GPS et le GLONASS permettant de localisé
rapidement et en temps réelle le module.
Pour pouvoir l’utiliser avec Raspberry Pi sous Linux, il faut installer le pilote QMI WWAN.
5.4 Le langage de programmation : Python
Python est un langage de programmation interprété orienté objet, qui a gagné en popularité en raison
de sa syntaxe claire et sa lisibilité. Il est multiplateforme (disponible sous Windows, Mac et Linux).
Figure1. 8 : Logo de Python
Python permet à la fois une programmation impérative dans le style du langage C et la programmation
orientée objet comme le Java et le C++.
11
5.5 Les web services
5.5.1 Introduction
Un service web est un composant logiciel permettant la communication entre les applications
et les systèmes hétérogènes dans le but de créer un environnement distribué. Ainsi, les applications
peuvent envoyer et recevoir des données en utilisant des technologies différentes (l’interopérabilité).
Les services web utilisent le protocole HTTP(S) (Hypertext Transfer Protocol) pour le transfert
des données sous format normalisés (XML, JSON, CSV).
Il existe plusieurs technologies derrière le terme services web, dans notre application nous allons
utiliser le service web de type REST (Representational state transfer).
5.5.2 Service Web REST
Le service web de type REST suit les règles suivantes :
Un service web est un composant logiciel permettant la communication entre les applications
et les systèmes hétérogènes dans le but de créer un environnement distribué. Ainsi, les applications peuvent envoyer et recevoir des données en utilisant des technolo gies différentes (l’interopérabilité). Les services web utilisent le protocole HTTP(S) (Hypertext Transfer Protocol) pour le transfert
des données sous formatnormalisés (XML,JSON,CSV).
12
5.5.3 Avantages de REST
5.5.4 Limites de REST
6. Conclusion
13
Chapitre 2
Etude et implémentation de la partie embarquée
Sommaire
1. Introduction..............................................................................................................................14
2. Préparation du Raspberry Pi ......................................................................................................14
3. Le pilote QMI WWAN pour Quectel EC20 LTE .............................................................................15
4. Lecture des informations de bord de véhicule ............................................................................18
5. Conclusion ................................................................................................................................21
14
1. Introduction
Dans ce deuxième chapitre, on s’intéresse à l’étude du module central de Gateway et sa liaison avec
la partie responsable du traitement des données de bord du véhicule.
2. Préparation du Raspberry Pi
2.1 Le Système d’exploitation Raspbian
La plupart des systèmes qui fonctionnent sur Raspberry Pi sont
des versions du système d'exploitation Linux. Parce que Linux est
open source, les développeurs peuvent l’adopter pour des buts
spécifiques. Dans le cas de Raspberry Pi, le matériel léger nécessite
un système réduit et privé d'applications inutiles
2.2 Compilation croisée du module Linux pour Raspberry Pi
Il existe deux méthodes principales pour la construction du noyau Linux. Nous pouvons le construire
localement sur notre Raspberry Pi (qui prendra beaucoup de temps); ou bien nous pouvons effectuer
Figure2.19 : Logo du système
d'exploitation Raspbian
15
une compilation croisée sur notre machine hôte avec « TOOLCHAIN », ce qui est beaucoup plus
rapide, mais nécessite plus de configuration.
2.3 Connexion à distance au Raspberry pi : le protocole SSH
Secure Shell (SSH) est un protocole de réseau crypté pour initier des sessions Shell textuelles sur
des machines distantes de manière sécurisée. Cela permet à un utilisateur d'exécuter des commandes
sur l'invite de commande d'une machine sans qu'ils soient physiquement présents à proximité
de la machine.
3. Le pilote QMI WWAN pour Quectel EC20 LTE
Pour pouvoir utiliser modem EC20 LTE de Quectel avec le Raspberry, nous devons installer le pilote
QMI WWAN.
3.1 Le protocole QMI
QMI (Qualcomm Mobile Station Modems Interface) est un protocole binaire conçu pour remplacer
la communication avec les modems basés sur les commandes AT. Il est disponible dans les appareils
avec des chipsets Qualcomm provenant de plusieurs fournisseurs (Huawei, Sierra Wireless, ZTE
et bien sûr Qualcomm lui-même).
Ce protocole définit différents «services», chacun d'entre eux est lié à différentes actions qui peuvent
être demandées au modem :
 Le service «DMS» (Device Management services) : offre des fonctions permettant de changer
les informations de l’appareil
 le service «NAS» (Network Access services) : offre des fonctions permettant de s’inscrire
dans le réseau.
 le service « WDS » (Wireless Data Service) : offre des fonctions permettant l'utilisateur
à créer des connexions de données et à demander les rapports de localisation GPS.
16
3.2 Le contrôleur ModemUP
Pour connecter notre Raspberry pi à internet par le biais du modem EC20, nous devons envoyer
des messages QMI après chaque redémarrage. Afin d’automatisé cette tâche, nous avons créé
un script « ModemUp » qui assure le bon fonctionnement de notre modem.
Ce script vérifie :
 la présence du modem EC20 LTE
 le statut de l’interface wwan
 le statut de la connexion internet
Le diagramme d'états-transitions du script ModemUp est le suivant :
Figure2.2 10 : Le diagramme d'états-transitions du script ModemUp
17
Enfin, pour les imprévus, nous devons relancer le script une fois par minute avec « cron » et mettre
les erreurs dans un fichier log.
3.3 Système GNSS/GPS
Le modem EC20 LTE est équipé d’un récepteur GNSS (Global Navigation Satellite System)
qui supporte le GPS (Global Positioning System) et le GLONASS (GLObal NAvigation Satellite
System) permettant de localiser rapidement et en temps réel le module.
Le GNSS permet de déterminer l’emplacement du modem sans aucune assistance du réseau.
La procédure de mise en marche du GNSS est présentée ci-dessous:
1. activer le GNSS avec la commande « AT + QGPS »,
2. obtenir les informations de localisation avec la commande « AT+QGPSLOC ». La trame
obtenue est la suivante :
« UTC », « latitude », « longitude », « hdop », « altitude », « fix », « spkm », « date », « nsat »
Avec :
 « UTC » : Heure UTC. Format: hhmmss.sss
 « latitude » : Latitude
 « longitude » : Longitude
 « hdop » : précision horizontale
 « altitude » : L'altitude de l'antenne par rapport au niveau de la mer (en mètre)
 « fix » : mode de positionnement GNSS (positionnement 2D ou 3D)
 « spkm » : Vitesse (en Km/h)
 « date » : La date de positionnement
 « nsat » : Nombre de satellites utilisés
3. arrêter le GNSS avec la commande « AT+QGPSEND »
18
4. Lecture des informations de bord de véhicule
4.1 Traitement des données du réseau CAN
Le traitement de ce fichier est réalisé par un microcontrôleur ST. Nous allons supposer que ce fichier
est déjà traité et que les données de bord sont présentes sur le microcontrôleur sous le format
« ID, valeur ». Par la suite, nous allons relier le Raspberry au microcontrôleur via le protocole SPI
pour extraire ces données.
4.2 Communication SPI Raspberry-Microcontrôleur
Le bus SPI utilise quatre signaux logiques :
Figure2.3 11 : Communication SPI entre Master-slave
19
Le microcontrôleur et le Raspberry sont connectés comme le montre la figure suivante :
Figure2.4 12 : Liaison SPI entre le Raspberry et le microcontrôleur
Nous avons configuré le Raspberry Pi comme maitre et le microcontrôleur comme esclave.
20
Dans le cas d’une alerte, et pour permettre au système de réagir en temps réel, nous avons configuré
le microcontrôleur pour envoyer une interruption au Raspberry suivant le scénario suivant :
1. La liaison GPIO est initialement à 0,
2. Le Raspberry génère l’horloge et envoie la requête de demande au microcontrôleur,
3. Le microcontrôleur repend par les informations demandées,
4. Fin de la communication,
5. Si le microcontrôleur veut envoyer des données critiques au Raspberry, il envoie un bit 1 par
le biais de la liaison GPIO.
6. Le Raspberry crée une interruption et envoie une demande de lecture des informations
critiques.
7. Le microcontrôleur repend par les informations critiques.
4.3 Protocole de communication
C’est l’ensemble des règles qui permettent l’échange des données entre les deux systèmes. Dans notre
cas, nous avons développé notre propre protocole qui se présente de la façon suivante :
1. Le Raspberry envoie une trame de demande au microcontrôleur.
2. Le microcontrôleur repend par une trame contenant les informations demandées.
4.3.1 Format de la trame envoyée par le Raspberry
La trame de demande d’information commence par le caractère « $ » suivi d’un champ qui indique
le nombre des informations demandés. Puis, les identifiant des informations demandés et enfin
un dernier champ de détection d’erreurs CRC.
Le format de la trame de demande est représenté dans la figure XX.
Figure2.513 : Format de trame envoyée par le Raspberry
21
4.3.2 Format de la trame envoyée par le microcontrôleur
La trame de réponse envoyée par le microcontrôleur commence par le caractère « $ ». Puis, un
champ qui indique l’identifiant de l’information demandée suivi de sa valeur. Enfin un dernier
champ de détection d’erreurs CRC.
Le format de la trame de demande est représenté dans la figure XX.
Figure2.6 14 : Format de la trame envoyée par le microcontrôleur
4.3.3 Contrôle de redondance cyclique (CRC)
5. Conclusion
Dans ce chapitre, nous avons détaillé les différentes étapes de préparation du Raspberry Pi comme
étant la partie centrale du Gateway. Dans le chapitre suivant, nous allons décrire les différentes phases
de création de la partie Backoffice.
22
Chapitre 3
Etude et implémentation de la partie BackOffice
Sommaire
1. Introduction..............................................................................................................................23
2. Xively - Notions de base ............................................................................................................23
3. La phase de Développement......................................................................................................23
4. La phase de Déploiement ..........................................................................................................29
5. La phase de Gestion ..................................................................................................................31
6. Conclusion ................................................................................................................................32
23
1. Introduction
Après avoir présenté les différentes parties de préparation de notre Raspberry ainsi que
le protocole de communication avec la partie responsable de traitement informations de bord
du véhicule, nous consacrons ce chapitre à la présentation des différentes phases de création
de la partie BackOffice qui jouera le rôle d’une interface entre les données et l’application mobile
et qui permettra les responsables de gérer et contrôler le fonctionnement de l’application.
2. Xively - Notions de base
Xively (anciennement connu sous le nom Cosm et Pachube) est une division
de LogMeIn. C’est une entreprise mondiale, publique qui offre une plateforme « PaaS »
(Platform as a Service) pour l'internet des objets. Elle simplifie l'interconnexion d'équipements
des données, des personnes et des lieux. Xively facilite la création de solutions convaincantes qui
transforment la façon dont les gens vivent leur monde.
Le processus de création de solution sous Xively se déroule en trois étapes :
 La phase de développement : Prototypage de l’application avec « Xively Developer
Workbench »,
 La phase de Déploiement : Transformation du prototype en produits,
 La phase de Gestion : Gestion du lot de produits sans considérer sa taille et contrôle des
appareils en temps réel.
3. La phase de Développement
Dans la phase de développement l'objectif est d'obtenir un prototype de notre produit final qui répond
à nos besoins. Nous pouvons facilement créer et connecter nos périphériques, services et/ou
applications grâce à « Xively Developer Workbench ».
Figure3.1 15 : Logo de Xively Developer Workbench
24
3.1 Xively Developer Workbench
Chaque périphérique connecté dispose de son propre dashboard personnalisable là où nous pouvons
configurer les canaux, les méta-données, les autorisations et la connexion avec d’autres services.
Figure3.2 16 : Capture d'écran de l'interface Xively Developer Workbench
3.1.1 Les canaux (Channels)
Un canal permet l'échange bidirectionnel de points de données entre la plate-forme Xively
et les périphériques, les applications et les services autorisés. Chaque canal est caractérisé par un nom
et un type de valeur.
25
3.1.2 La localisation
Il existe un lien pour ajouter manuellement les données de localisation à notre appareil s’il est
immobile, mais également notre nœud peut facilement envoyer ces données de localisation
à la plateforme Xively.
3.1.3 Les déclencheurs
Les déclencheurs sont utilisés pour intégrer des services. Il suffit de spécifier le canal, la condition de
déclenchement (par exemple Température>90…) et le type de déclencheur (SMS, Mail, Tweet …).
Lorsque la condition est satisfaite, les déclencheurs appellent le(s) service(s) concerné.
3.2 L’API REST de Xively
Le service Cloud Xively fournit la messagerie, l'archivage des données, les services
d'approvisionnement et d'annuaire qui sont accessibles via l'API Xively. L'API Xively rend rapide
et facile la création des produits qui se connectent sur l'internet des objets.
Figure3.3 17 : Architecture API/services de Xively
Le tableau suivant présente l'ensemble des opérations que nous pouvons effectuer avec l'API Xively.
Ces opérations sont effectuées en utilisant 7 ressources Xively: Products, Devices, Keys, Feeds,
Triggers, Datastreams, et Datapoints. Chaque ressource est associée à des attributs spécifiques.
26
Remarque: Il est à noter que si nous ne spécifions pas de type format de données : JSON, CSV ou
XML lors de l'interaction avec l'API Xively, le format par défaut accepté / retournée sera JSON.
Tableau 2 : Lees opérations accessibles via l'API REST de Xively
Ressources Opération Format Exemple d’URL Méthode Réponse
Feeds Lire json,
xml,
csv
https://api.xively.com/v2/feeds/ GET Flux
contenant
l'état actuel de
tous les Flux
de données et
de
métadonnées.
Feeds Lire
(intervalle)
Json,
xml,
csv
https://api.xively.com/v2/feeds/feed_id?range GET Flux
contenant
l’historique
de données de
chaque canal
(datastream)
Feeds Mettre à
jour
Json,
xml,
csv
https://api.xively.com/v2/feeds/feed_id PUT Entêtes HTTP
seulement
Datastreams Ecrire Json,
xml,
csv
https://api.xively.com/v2/feeds/feed_id/datastreams POST n/a
Datastreams Lire Json,
xml,
csv
https://api.xively.com/v2/feeds/feed_id/
datastreams/datastream_id
GET Flux
contenant
l'état actuel du
canal
(datastream)
demandé.
Datastreams Mettre à
jour
Json,
xml,
csv
https://api.xively.com/v2/feeds/feed_id/
datastreams/datastream_id
PUT Entêtes HTTP
seulement
Datastreams Supprimer Json,
xml,
csv
https://api.xively.com/v2/feeds/feed_id/
datastreams/datastream_id
DELETE Entêtes HTTP
seulement
Datasreams Toute la
liste
https://api.xively.com/v2/feeds/feed_id GET Flux contenat
tous les
canaux ainsi
que ses points
de données
Datapoints Supprimer n/a https://api.xively.com/v2/feeds/feed_id/
datastreams/datastream_id/datapoints/timestamp
DELETE Entêtes HTTP
seulement
Products Ecrire Json https://api.xively.com/v2/products POST Entête avec
l'emplacement
de produit
créé.
27
Ressources Opération Format Exemple d’URL Méthode Réponse
Products Mettre à
jour
Json https://api.xively.com/v2/products/product_id PUT Entêtes HTTP
seulement
Products Lire Json https://api.xively.com/v2/products/product_id GET Flux
contenant un
produit
unique
Product Supprimer n/a https://api.xively.com/v2/products/product_id DELETE Entêtes HTTP
seulement
Devices Ecrire Json https://api.xively.com/v2/products/product_id/devices Post Entête avec
l'emplacement
de l'appareil
créé
Devices Lire Json https://api.xively.com/v2/products/
product_id/devices/serial_number
GET Flux
contenant un
appareil
unique
Devices Mettre à
jour
Json https://api.xively.com/v2/products/
product_id/devices/serial_number
PUT Entêtes HTTP
seulement
Devices Supprimer n/a https://api.xively.com/v2/products/
product_id/devices/serial_number
DELETE Entêtes HTTP
seulement
Devices Activation Json,
csv
https://api.xively.com/v2/devices/
activation_code/activate
GET Entêtes HTTP
seulement
Key Ecrire Json,
xml
https://api.xively.com/v2/keys POST Entêtes HTTP
seulement
Key Supprimer n/a https://api.xively.com/v2/keys/key_id DELETE Entêtes HTTP
seulement
Triggers Ecrire Json,
xml
https://api.xively.com/v2/triggers/ POST Entêtes HTTP
seulement
Avec l’API REST de Xively, nous pouvons facilement exécuter des opérations sur nos ressources :
il suffit d’envoyer l’URL de l’opération désiré au serveur en utilisant une des requêtes HTTP : GET
PUT, POST, DELETE, UPDATE.
3.3 Création de périphérique
Pour créer un périphérique, il suffit de lui donner un nom, une description et de définir les droits
d'accès. Après la création d’un périphérique, Xively crée automatiquement un FEED ID
et un API KEY que nous aurons besoin pour connecter votre appareil.
Le FEED ID joue le rôle d’un identifiant de notre périphérique. C’est l'ensemble des flux de données
et de métadonnées définies pour un dispositif.
28
Figure3.4 18: les Logos des bibliothèques de Xively
L’API KEY détermine les droits d'accès aux ressources Xively créés pour notre périphérique. Xively
crée une clé API automatiquement pour notre prototype avec l'autorisation complète: lire
mettre à jour, écrire, supprimer. Nous pouvons également créer des clés avec des autorisations plus
fines pour plus de sécurité et pour obtenir le droit d'accès au bon moment et à la bonne personne.
Pour connecter notre appareil, il suffit de copier le FEED ID affichée et l’API KEY dans notre code
chargé d'établir une communication bidirectionnelle entre le Raspberry et Xively.
Pour rendre le processus plus facile, Xively fournit des bibliothèques « open source » et hébergé
sur Github.
Le test se fait avec « Xively Developer Workbench », nous pouvons déboguer en temps réel et
contrôler la communication bidirectionnelle entre l’appareil et Xively. Nous pouvons aussi suivre les
valeurs de mise à jour sur le canal l'historique de demande et les requêtes HTTP en temps réel.
3.4 Création des déclencheurs (Triggers)
3.4.1 Zapier
Figure3.5 19 : Logo de Zapier
Zapier est un service qui nous permet d'automatiser les tâches entre les applications web.
Connecter un déclencheur Xively à Zapier permet à notre application d’envoyer un tweet avec
Twitter, appeler ou envoyer un SMS avec Twilio ou activer des services existants dans des
applications web. Les déclencheurs Xively peuvent être activés lorsque la valeur d'un canal répond
des critères que nous définissons.
29
Mise en place d’un trigger avec Zapier:
 créer un Zap.
 Un Zap est composé d’un déclencheur et une action.
 Définir le déclencheur comme un Webhooks
 Définir l’action, par exemple « envoyer un Email »
Figure3.6 20 : Capture d'écran de site web Zapier.com
3.4.2Twilio
Figure3.7 21 : Logo de Twilio
Twilio est une plateforme Cloud qui permet aux développeurs de logiciels de passer et recevoir
des appels téléphoniques et des SMS en utilisant ses API de web service. Twilio peut être facilement
interfacé avec Zapier afin de créer des services à notre application.
4. La phase de Déploiement
Tournons le prototype en produits : Lors du déploiement, nous créons un lot de produits virtuels dans
Xively qui correspondent à un lot de produits physiques fabriqués. Un lot de produits est défini par
les canaux du produit et une liste des numéros de série de chaque périphérique.
Xively génère automatiquement un Product ID et un Product Secret pour notre nouveau lot
de produits qui seront utiles par la suite.
30
Pour pré-enregistrer les périphériques de ce lot, nous devons ajouter des numéros de série soit en
téléchargeant un fichier CSV qui contient un numéro de série par ligne ou en entrant les numéros
de série manuellement.
Le pré-enregistrement permet Xively de reconnaître les appareils autorisés quand ils se réveillent
et transmettent leur code d'activation au cours du processus de provisionnement.
4.1 Le processus de provisionnement
Le provisionnement est le processus d'activation de l'appareil. Le terme «Provisionnement» provient
du fait que le dispositif est «provisionné» avec un FEED ID et un API KEY lors de son premier appel
d'activation à l'API Xively.
L'API de provisionnement Xively rend la scalabilité facile, élimine le coût et la difficulté de
développement software en permettant à l’appareil d’être pré-configuré d'une manière qui garantit
son réveil, son activation et pouvoir l’associer avec l’utilisateur en toute sécurité.
4.2 Le scénario d'activation de l’appareil
L’activation de l’appareil se fait en 6 étapes :
1. Avant que le dispositif soit activé, il doit être préinscrit sur Xively sous son produit parent
de sorte que l'API attend un appel d'activation de ce dispositif particulier quand il se réveille
pour la première fois. Le Pré-enregistrement d'un périphérique est accompli en important
le numéro de série de l'appareil dans la plateforme Xively.
2. Le dispositif physique (pré-enregistré) est mis en ligne.
3. Le dispositif adresse une demande d'activation sécurisée contenant son code d’activation
en utilisant l’API Xively. Cela indique à Xively que le dispositif a réveillé pour la première
fois, et demande à être approvisionné avec un FEED ID et un API KEY.
Le code d'activation du dispositif est généré en utilisant un hachage HMAC-SHA1 qui
combine le numéro de série de l'appareil avec le Product Secret de son parent, ce qui rend
impossible pour quelqu'un l'extraction de Product Secret à partir du code d'activation.
4. La demande est validée par Xively pour assurer qu'il est correcte de point de vue
cryptographique et que le dispositif n'est pas encore activé.
5. Xively retourne les informations d’activation (FEED ID et l’API KEY) au périphérique
activé.
31
6. Le dispositif enregistre ces derniers afin qu'il puisse interagir en toute sécurité avec Xively
pour toutes opérations futures.
5. La phase de Gestion
Figure3.8 22 : Capture d'écran de la console de gestion
Xively nous donne la possibilité de gérer les lots de produits, peu importe la taille une ou un million
et soutenir nos appareils en temps réel. Maintenant, nous gérons nos produits, en utilisant la console
de gestion pour soutenir nos produits et nos clients de la manière suivante :
 Ajouter des numéros de série pour d'autres périphériques à notre lot de produit,
 afficher tous les périphériques du lot de produit,
 rechercher un appareil (filtrer la liste).
Un simple clic sur le numéro de série nous permet de contrôler l’appareil concerné. La page
de surveillance est pratiquement identique au « Workbench » sur lequel nous avons configuré notre
prototype original.
Nous pouvons contrôler les appareils, les canaux, la localisation, les métadonnées, le journal de
requêtes, l'API KEY, et les déclencheurs.
32
Les actions de contrôle sont les suivantes :
 Activer/Désactiver un appareil,
 Activer/désactiver un service,
 vérifier que les données provenant d'un appareil sont correctes
 déboguer et visualiser ou suivre les requêtes en temps réel.
6. Conclusion
Dans ce chapitre, nous avons décrire les différentes phases de création de la partie Backoffice qui
permettra lux responsables de gérer et contrôler le fonctionnement de l’application. Dans le chapitre
suivant, nous décrirons les différentes étapes de réalisation ainsi que les tests de validation.
33
Chapitre 4
Réalisation et tests de validation de notre solution
Sommaire
1. Introduction..............................................................................................................................34
2. Préparation du Raspberry Pi ......................................................................................................34
3. Installation du driver QMI WWAN pour Quectel EC20 ................................................................37
4. Création de l’application avec Xively..........................................................................................38
5. Tests de validation ....................................................................................................................41
34
1. Introduction
Ce chapitre constitue le dernier volet du rapport. Il a pour objectif d'exposer le travail achevé.
Pour ce faire, nous allons décrire les différentes étapes de préparation du Gateway (Raspberry Pi)
et les phases de création de l’application de gestion avec Xivey.
2. Préparation du Raspberry Pi
2.1 Installation du système d’exploitation Raspbian
Le Raspberry Pi est initialement sans système d’exploitation. D’abord nous avons téléchargé
Raspbian à partir du site officiel : raspberrypi.org/downloads. Puis nous l’avons installé sur la carte
mémoire par le biais d’un logiciel d’écriture d’image : « Win32 Disk Imager ».
Figure4.1 23 : Installation du Raspbian avec Win32 Disk Imager
2.2 Connexion à distance au Raspberry pi
Pour pouvoir se connecter à distance à notre Raspberry, il faut le connecter à un réseau local et faire
appel au protocole SSH.
Le serveur SSH est activé par défaut sur le Raspberry Pi. Sous Linux, le client étant intégré dans la
plupart des distributions.
35
Par contre, sous Windows nous devons installer « Putty » qui est un client SSH et Telnet. Ensuite, il
suffit d’entrer l’adresse IP du Raspberry dans Putty pour pouvoir se connecter. Afin d’accéder
à l’interface graphique, nous avons utilisé le système de visualisation VNC.
Le serveur VNC est installé sur le Raspberry en lançant la commande suivante :
 sudo apt-get install tightvncserver.
Ensuite, nous avons créé un fichier de démarrage automatique.
Le client VNC que nous avons utilisé est VNC Viewer dont le principe de connexion est similaire
à celui du SSH.
Figure4.2 24 : Capture d'écran del 'interface graphique du Raspberry sur VNC Viewer.
Un serveur DHCP distribue une adresse IP aux clients selon la disponibilité des adresses de la plage
définie. Cependant, il est possible de faire en sorte qu’un hôte ait toujours la même adresse IP attribué
c’est ce que l’on appelle de la réservation d’adresse. On doit donc indiquer dans le serveur DHCP
que telle adresse IP (x.y.z.w) est réservée à l’adresse MAC du notre Raspberry.
Figure4.3 25 : Réservation de l'adresse 192.168.0.100 au Raspberry
36
2.3 Cross-compilation du module Linux
Il existe deux méthodes principales pour la construction du noyau Linux pour Raspberry Pi. Nous
pouvons le construire localement sur notre Raspberry Pi qui prendra une longue période. Nous
pouvons aussi précéder à compilation croisée, qui est beaucoup plus rapide, mais nécessite plus de
configuration.
2.3.1 Compilation Locale sur Raspberry Pi
Après avoir installé la dernière version de Raspbian, nous devons connecter notre Raspberry pi à
internet pour lui donner un accès aux fichiers source.
 Les fichiers sources de linux sont hébergés à Github. Pour les obtenir, il suffit de lancer
la commande suivante :
 Configuration du noyau par défaut :
 Compilation et installation du noyau, cette étape prend beaucoup de temps.
2.3.2 Compilation croisée avec Toolchain
D’abord nous avons besoin d’une machine hôte avec un système d’exploitation approprié :
la distribution la plus recommandé est Ubuntu.
Les étapes que nous avons suivies sont les suivantes :
 Installation de Toolchain
 Obtention des fichiers source
 Installation sur la carte SD du Raspberry Pi :
GIT CLONE --DEPTH=1 HTTPS://GITHUB.COM/RASPBERRYPI/LINUX
CD LINUX
KERNEL=KERNEL
MAKE BCMRPI_DEFCONFIG
GIT CLONE HTTPS://GITHUB.COM/RASPBERRYPI/TOOLS
GIT CLONE --DEPTH=1 HTTPS://GITHUB.COM/RASPBERRYPI/LINUX
CD LINUX
KERNEL=KERNEL
MAKE ARCH=ARM CROSS_COMPILE=ARM-LINUX-GNUEABIHF- BCMRPI_DEFCONFIG
MAKE ARCH=ARM CROSS_COMPILE=ARM-LINUX-GNUEABIHF- ZIMAGE MODULES DTBS
37
3. Installation du driver QMI WWAN pour Quectel EC20
Pour installer le pilote QMI WWAN il faut :
 Modifier le code source du pilote : nous devons ajouter l’identifiant du fournisseur (VID)
Quectel ainsi que l’identifiant de son produit EC20 (PID) dans le fichier
[KERNEL]/drivers/net/usb/qmi_wwan.c
 Modifier la configuration du noyau : dans le menu USB Network Adaptaters, nous devons
activer la fonctionnalité « QMI WWAN driver for Qualcomm MSM based 3G and LTE
modems »
Figure4.4 26 : Le menu USB Network Adaptaters de Raspbian
 Configuration de l’APN (Access Point Name) : le modem doit utiliser un nom de point
d’accès spécifique fournit par l’opérateur. Dans notre cas, l’APN que nous avons utilisé
est « ooredoo.internet.tn ».
Lorsque le Raspberry Pi est attaché au pilote QMI WWAN, il va créer un canal réseau et un canal
QMI. Le canal réseau nommé wwanX est utilisé pour la transmission des données, par contre
le canal QMI est responsable de l’interaction entre le Raspberry Pi et le modem via des messages
QMI.
Nous pouvons s’assurer que le pilote fonctionne correctement en vérifiant l’existence
de l’interface réseau wwan sur le Raspberry avec la commande « ifconfig ».
38
Figure4.5 27 : les interfaces réseau de notre Raspberry
4. Création de l’application avec Xively
4.1 La phase de Développement :
4.1.1 Prototypage
Dans la phase de développement l'objectif est d'obtenir un prototype de notre produit final qui répond
à nos besoins. Pour valider notre travail, nous allons travailler sur les paramètres suivants :
 Les canaux : Vitesse, température du moteur, le niveau de carburant et l’état des airbags,
 La localisation,
 Les métadonnées : le propriétaire de la voiture et son adresse e-mail,
 Le déclencheur : Informer par e-mail l’utilisateur lorsque la voiture fait un accident.
39
Figure4.6 28 : Xively Developer Workbench
4.1.2 Création de déclencheur avec Zapier
La création de déclencheur avec Zapier se fait en deux étapes :
1. Définir la condition de déclenchement de service : lorsque le statut des airbags change
la plateforme Xively déclenche le service.
2. Créer le service : envoyer un e-mail à l’utilisateur.
Figure4.7 29 : Création de déclencheur avec Xively et Zapier
40
4.2 La phase de Déploiement
Après avoir créé notre prototype, nous allons passer au déploiement. Il suffit de cliquer sur le bouton
« Deploy ».
Figure4.8 30 : Capture d'écran de la phase de déploiement
Maintenant, c’est le temps d’insérer les numéros de série des appareils. Cette opération est effectuée
soit en téléchargeant un fichier CSV qui contient un numéro de série par ligne ou en entrant les
numéros de série manuellement.
À chaque appareil ajouté, Xively crée une instance du prototype.
Figure4.9 31 : Insertion des numéros de série des périphériques
41
5. Tests de validation
5.1 Activation de l’appareil
Initialement le Raspberry est désactivé.
Après son premier démarrage, le Raspberry envoie son code d’activation à la plateforme Xively. Si
le code est correct, Xively renvoie le Feed ID et l’API key au Raspberry.
Figure4.10 32 : Activation du périphérique
Après l’activation, Xively change le statut de notre appareil et indique l’heur de l’activation :
5.2 Envoi des données à la plateforme Xively
Grace aux Feed ID et API key, notre Raspberry est capable d’envoyer ses données périodiquement à
la plateforme Xively.
Figure4.11 33 : Envoi des données à la plateforme Xively
À partir du Tableau de bord de contrôle offert par Xively, nous pouvons vérifier que les données sont
bien reçues.
42
5.3 Envoi des données de localisation
Pour lire les données de localisation, le Raspberry Pi doit envoyer un message QMI au modem EC20
LTE. Ce dernier renvoie une trame « QGPSLOC » qui contient la longitude et la latitude de la
position.
Figure4.13 35 : Lecture des données de localisation
Par la suite le Raspberry envoie ses données de localisation à la plateforme Xively.
Figure4.12 34 : Visualisation des données
43
Figure4.14 36 : Envoi des données de localisation à la plateforme Xively
Dans le tableau de bord, nous pouvons vérifier que les données de localisation sont bien reçues.
Figure4.15 37 : La localisation du périphérique avec Xively
5.4 Test des déclencheurs
Dès que le statut des airbags passe à 1 (activé), Xively envoie automatiquement un e-mail à
l’utilisateur pour lui informer.
Figure4.16 38 : Résultat du déclencheur
6. Conclusion
Ce chapitre a été consacré à la présentation des différentes tâches réalisées dans ce projet pour
accomplir notre mission, nous avons commencé par la préparation du Raspberry Pi et l’installation
du driver QMI. Ensuite, nous avons détaillé les étapes de création de la partie BackOffice. Nous
clôturons notre rapport par une conclusion générale et les différentes perspectives recensées.
44
Conclusion générale
45
Bibliographie
[1] Union internationale des télécommunications, « s.d. ». Internet des objets – Normes mondiales. En ligne
http://www.itu.int/en/ITU-T/gsi/iot/
[2 ]R. Van Der Meulen, The impact of IoT on Business. Gartner, 2015. En ligne
http://www.gartner.com/newsroom/id/3165317 consulté le 03/05/2016.
[3] Telnet Holding, 2009. Qui sommes-nous. En ligne http://www.groupe-telnet.net/
[4] Bien choisir sa plate-forme, 2015. En ligne http://www.usine-digitale.fr/article/bien-choisir-sa-plate-
forme-pour-faire-communiquer-ses-objets-connectes.N342721 consulté le 25/02/2016.
[5] Xively by LogMeIn, « s.d. ». What is Xively. En ligne https://xively.com/whats_xively/
[6] Raspberry Foundation, 2016. Documentation. En ligne https://www.raspberrypi.org/resources/
[7]J. philippe Vasseur & A, Dunkels, Interconnecting Smart Objects with IP. Rick Adams, 2010.
(Cité page 102)
[8] Raspberry Foundation, 2016. Téléchargements. En ligne https://www.raspberrypi.org/downloads/
[9] Y. Carl, WCDMA&LTE Linux USB Driver User Guide. Quectel Wireless Solutions Co., Ltd, 2015.
(Cité page 22)
[10] T. Zhang, EC20 GNSS AT Commands Manual. Quectel Wireless Solutions Co., Ltd, 2015. (Cité page 16)
[11] D. Norris, The Internet of Things : Do-It-Yourself Projetcs with Arduini, Raspberry and BeagleBone.
McGraw-Hill Education, 2015. (Cité page 89)
[12] Xively by LogMeIn, « s.d. ». Tutoriels. En ligne https://personal.xively.com/dev/tutorials/
[13] Xively by LogMeIn, « s.d. ». Documentations de l’API REST. En ligne
https://personal.xively.com/dev/docs/api/
[14] D. Norris, The Internet of Things : Do-It-Yourself Projetcs with Arduini, Raspberry and BeagleBone.
McGraw-Hill Education, 2015. (Cité page 36)

Contenu connexe

Tendances

Système de supervision des réseaux de capteurs sans fil
Système de supervision des réseaux de capteurs sans filSystème de supervision des réseaux de capteurs sans fil
Système de supervision des réseaux de capteurs sans fil
Samia HJ
 
Rapport Stage ingénieur
Rapport Stage ingénieurRapport Stage ingénieur
Rapport Stage ingénieur
Mhamdi Imed
 
Version finale
Version finaleVersion finale
Version finale
Nâw Fél
 
Mise en place d’une plateforme de formation IMS
Mise en place d’une plateforme de formation IMSMise en place d’une plateforme de formation IMS
Mise en place d’une plateforme de formation IMS
Kokou Gaglo
 
Mise en place d'une Plateforme de Supervision et de Détection d'Intrusion Sys...
Mise en place d'une Plateforme de Supervision et de Détection d'Intrusion Sys...Mise en place d'une Plateforme de Supervision et de Détection d'Intrusion Sys...
Mise en place d'une Plateforme de Supervision et de Détection d'Intrusion Sys...
Alaaeddine Tlich
 
Contributions aux environnements de développement de services de télécoms da...
Contributions aux environnements de développement de  services de télécoms da...Contributions aux environnements de développement de  services de télécoms da...
Contributions aux environnements de développement de services de télécoms da...
Kokou Gaglo
 
Conception et Développement d'un Network Management System ATM Nortel
Conception et Développement d'un Network Management System ATM NortelConception et Développement d'un Network Management System ATM Nortel
Conception et Développement d'un Network Management System ATM Nortel
Tidiane Sylla
 
Relevé De Compte Ccp Par Sms
Relevé De Compte Ccp Par SmsRelevé De Compte Ccp Par Sms
Relevé De Compte Ccp Par Sms
Lamine.o
 
Développement d’un Outil d’Aide À la Planification du Réseau Coeur GSM
Développement d’un Outil d’Aide À la Planification du Réseau Coeur GSMDéveloppement d’un Outil d’Aide À la Planification du Réseau Coeur GSM
Développement d’un Outil d’Aide À la Planification du Réseau Coeur GSM
Mohamed Raafat OMRI محمد رأفت عمري
 
Cours reseau ouya
Cours reseau ouyaCours reseau ouya
Cours reseau ouyaYaya Diako
 
ETUDE ET MISE EN PLACE D’UNE SOLUTION DE GESTION DE LA SECURITE DU RESEAU : C...
ETUDE ET MISE EN PLACE D’UNE SOLUTION DE GESTION DE LA SECURITE DU RESEAU : C...ETUDE ET MISE EN PLACE D’UNE SOLUTION DE GESTION DE LA SECURITE DU RESEAU : C...
ETUDE ET MISE EN PLACE D’UNE SOLUTION DE GESTION DE LA SECURITE DU RESEAU : C...
Tidiane Sylla
 
Mise en place d’une solution de tests de sécurité pour les passerelles réside...
Mise en place d’une solution de tests de sécurité pour les passerelles réside...Mise en place d’une solution de tests de sécurité pour les passerelles réside...
Mise en place d’une solution de tests de sécurité pour les passerelles réside...
Salmen HITANA
 
Interconnexion de deux_serveurs_asterisk_et_mise_en_place_d%e2%80%99un_r%c3%a...
Interconnexion de deux_serveurs_asterisk_et_mise_en_place_d%e2%80%99un_r%c3%a...Interconnexion de deux_serveurs_asterisk_et_mise_en_place_d%e2%80%99un_r%c3%a...
Interconnexion de deux_serveurs_asterisk_et_mise_en_place_d%e2%80%99un_r%c3%a...Prince King
 
Realistic simulations of delay tolerant networks
Realistic simulations of  delay tolerant networksRealistic simulations of  delay tolerant networks
Realistic simulations of delay tolerant networks
Amir Krifa
 
Mise en place des réseaux LAN interconnectés par un réseau WAN
Mise en place des réseaux LAN interconnectés par un réseau WANMise en place des réseaux LAN interconnectés par un réseau WAN
Mise en place des réseaux LAN interconnectés par un réseau WAN
Ghassen Chaieb
 
Etude et Mise en oeuvre d'une architecture de téléphonie sur IP sécurisée au ...
Etude et Mise en oeuvre d'une architecture de téléphonie sur IP sécurisée au ...Etude et Mise en oeuvre d'une architecture de téléphonie sur IP sécurisée au ...
Etude et Mise en oeuvre d'une architecture de téléphonie sur IP sécurisée au ...
stepmike
 
AD hoc routage ad hocroutage ad hocroutage ad hoc
AD hoc routage ad hocroutage ad hocroutage ad hocAD hoc routage ad hocroutage ad hocroutage ad hoc
AD hoc routage ad hocroutage ad hocroutage ad hoc
ismail eljadidi
 
Optimisation centralisée et distribuée de la durée de vie des réseaux de capt...
Optimisation centralisée et distribuée de la durée de vie des réseaux de capt...Optimisation centralisée et distribuée de la durée de vie des réseaux de capt...
Optimisation centralisée et distribuée de la durée de vie des réseaux de capt...
Papa Cheikh Cisse
 

Tendances (20)

Système de supervision des réseaux de capteurs sans fil
Système de supervision des réseaux de capteurs sans filSystème de supervision des réseaux de capteurs sans fil
Système de supervision des réseaux de capteurs sans fil
 
Rapport Stage ingénieur
Rapport Stage ingénieurRapport Stage ingénieur
Rapport Stage ingénieur
 
Version finale
Version finaleVersion finale
Version finale
 
Mise en place d’une plateforme de formation IMS
Mise en place d’une plateforme de formation IMSMise en place d’une plateforme de formation IMS
Mise en place d’une plateforme de formation IMS
 
Mise en place d'une Plateforme de Supervision et de Détection d'Intrusion Sys...
Mise en place d'une Plateforme de Supervision et de Détection d'Intrusion Sys...Mise en place d'une Plateforme de Supervision et de Détection d'Intrusion Sys...
Mise en place d'une Plateforme de Supervision et de Détection d'Intrusion Sys...
 
Contributions aux environnements de développement de services de télécoms da...
Contributions aux environnements de développement de  services de télécoms da...Contributions aux environnements de développement de  services de télécoms da...
Contributions aux environnements de développement de services de télécoms da...
 
Conception et Développement d'un Network Management System ATM Nortel
Conception et Développement d'un Network Management System ATM NortelConception et Développement d'un Network Management System ATM Nortel
Conception et Développement d'un Network Management System ATM Nortel
 
50868690 rapport-lte
50868690 rapport-lte50868690 rapport-lte
50868690 rapport-lte
 
Relevé De Compte Ccp Par Sms
Relevé De Compte Ccp Par SmsRelevé De Compte Ccp Par Sms
Relevé De Compte Ccp Par Sms
 
Développement d’un Outil d’Aide À la Planification du Réseau Coeur GSM
Développement d’un Outil d’Aide À la Planification du Réseau Coeur GSMDéveloppement d’un Outil d’Aide À la Planification du Réseau Coeur GSM
Développement d’un Outil d’Aide À la Planification du Réseau Coeur GSM
 
Cours reseau ouya
Cours reseau ouyaCours reseau ouya
Cours reseau ouya
 
ETUDE ET MISE EN PLACE D’UNE SOLUTION DE GESTION DE LA SECURITE DU RESEAU : C...
ETUDE ET MISE EN PLACE D’UNE SOLUTION DE GESTION DE LA SECURITE DU RESEAU : C...ETUDE ET MISE EN PLACE D’UNE SOLUTION DE GESTION DE LA SECURITE DU RESEAU : C...
ETUDE ET MISE EN PLACE D’UNE SOLUTION DE GESTION DE LA SECURITE DU RESEAU : C...
 
Mise en place d’une solution de tests de sécurité pour les passerelles réside...
Mise en place d’une solution de tests de sécurité pour les passerelles réside...Mise en place d’une solution de tests de sécurité pour les passerelles réside...
Mise en place d’une solution de tests de sécurité pour les passerelles réside...
 
Asterisk
AsteriskAsterisk
Asterisk
 
Interconnexion de deux_serveurs_asterisk_et_mise_en_place_d%e2%80%99un_r%c3%a...
Interconnexion de deux_serveurs_asterisk_et_mise_en_place_d%e2%80%99un_r%c3%a...Interconnexion de deux_serveurs_asterisk_et_mise_en_place_d%e2%80%99un_r%c3%a...
Interconnexion de deux_serveurs_asterisk_et_mise_en_place_d%e2%80%99un_r%c3%a...
 
Realistic simulations of delay tolerant networks
Realistic simulations of  delay tolerant networksRealistic simulations of  delay tolerant networks
Realistic simulations of delay tolerant networks
 
Mise en place des réseaux LAN interconnectés par un réseau WAN
Mise en place des réseaux LAN interconnectés par un réseau WANMise en place des réseaux LAN interconnectés par un réseau WAN
Mise en place des réseaux LAN interconnectés par un réseau WAN
 
Etude et Mise en oeuvre d'une architecture de téléphonie sur IP sécurisée au ...
Etude et Mise en oeuvre d'une architecture de téléphonie sur IP sécurisée au ...Etude et Mise en oeuvre d'une architecture de téléphonie sur IP sécurisée au ...
Etude et Mise en oeuvre d'une architecture de téléphonie sur IP sécurisée au ...
 
AD hoc routage ad hocroutage ad hocroutage ad hoc
AD hoc routage ad hocroutage ad hocroutage ad hocAD hoc routage ad hocroutage ad hocroutage ad hoc
AD hoc routage ad hocroutage ad hocroutage ad hoc
 
Optimisation centralisée et distribuée de la durée de vie des réseaux de capt...
Optimisation centralisée et distribuée de la durée de vie des réseaux de capt...Optimisation centralisée et distribuée de la durée de vie des réseaux de capt...
Optimisation centralisée et distribuée de la durée de vie des réseaux de capt...
 

En vedette

Gateway d’un système de monitoring
Gateway d’un système de monitoringGateway d’un système de monitoring
Gateway d’un système de monitoring
Ghassen Chaieb
 
L’entrepreneuriat vert
L’entrepreneuriat vertL’entrepreneuriat vert
L’entrepreneuriat vert
Ghassen Chaieb
 
ALOHA for Exchange 2010
ALOHA for Exchange 2010ALOHA for Exchange 2010
ALOHA for Exchange 2010EXCELIANCE
 
Exchange Server 2010
Exchange Server 2010Exchange Server 2010
Exchange Server 2010
Souhaib El
 
Introduction to Bitreactive
Introduction to BitreactiveIntroduction to Bitreactive
Introduction to Bitreactive
Ghassen Chaieb
 
Développement d’une application de gestion des licences des contrôleurs aériens
Développement d’une application de gestion des licences des contrôleurs aériensDéveloppement d’une application de gestion des licences des contrôleurs aériens
Développement d’une application de gestion des licences des contrôleurs aériens
Ghassen Chaieb
 
Etude, conception et réalisation d'une antenne planaire HF en technologie mic...
Etude, conception et réalisation d'une antenne planaire HF en technologie mic...Etude, conception et réalisation d'une antenne planaire HF en technologie mic...
Etude, conception et réalisation d'une antenne planaire HF en technologie mic...
Ghassen Chaieb
 
VPN NOMADE AVEC AUTHENTIFICATIO AD SOUS ROUTEUR CISCO
VPN NOMADE AVEC AUTHENTIFICATIO AD SOUS ROUTEUR CISCOVPN NOMADE AVEC AUTHENTIFICATIO AD SOUS ROUTEUR CISCO
VPN NOMADE AVEC AUTHENTIFICATIO AD SOUS ROUTEUR CISCO
Manassé Achim kpaya
 
Vpn d’acces avec cisco asa 5500 et client
Vpn d’acces avec cisco asa 5500 et clientVpn d’acces avec cisco asa 5500 et client
Vpn d’acces avec cisco asa 5500 et client
Manassé Achim kpaya
 
Mise en place d'un système de messagerie sous debian avec: postfix, dovecot, ...
Mise en place d'un système de messagerie sous debian avec: postfix, dovecot, ...Mise en place d'un système de messagerie sous debian avec: postfix, dovecot, ...
Mise en place d'un système de messagerie sous debian avec: postfix, dovecot, ...
Manassé Achim kpaya
 
Transition ipv4-ipv6
Transition ipv4-ipv6Transition ipv4-ipv6
Transition ipv4-ipv6Arrow Djibio
 
Active Directory : nouveautés Windows Server 2012
Active Directory : nouveautés Windows Server 2012Active Directory : nouveautés Windows Server 2012
Active Directory : nouveautés Windows Server 2012
Microsoft Technet France
 
Important Vm Ware Infrastrucutre Slides
Important Vm Ware Infrastrucutre SlidesImportant Vm Ware Infrastrucutre Slides
Important Vm Ware Infrastrucutre Slidesnouari
 
IPv6
IPv6IPv6
IPv6
medalaa
 
Lire les tables de routage
Lire les tables de routageLire les tables de routage
Lire les tables de routage
belhadj_rached
 
Projet de fin d etudes
Projet de fin d etudesProjet de fin d etudes
Projet de fin d etudes3azwa
 
Mon Projet Fin d'étude: Conception et développement d'une application de géol...
Mon Projet Fin d'étude: Conception et développement d'une application de géol...Mon Projet Fin d'étude: Conception et développement d'une application de géol...
Mon Projet Fin d'étude: Conception et développement d'une application de géol...
rim elaire
 
Securing the Cloud
Securing the CloudSecuring the Cloud
Securing the Cloud
GGV Capital
 

En vedette (20)

Gateway d’un système de monitoring
Gateway d’un système de monitoringGateway d’un système de monitoring
Gateway d’un système de monitoring
 
L’entrepreneuriat vert
L’entrepreneuriat vertL’entrepreneuriat vert
L’entrepreneuriat vert
 
ALOHA for Exchange 2010
ALOHA for Exchange 2010ALOHA for Exchange 2010
ALOHA for Exchange 2010
 
Exchange Server 2010
Exchange Server 2010Exchange Server 2010
Exchange Server 2010
 
KAMAL 2016
KAMAL 2016KAMAL 2016
KAMAL 2016
 
Introduction to Bitreactive
Introduction to BitreactiveIntroduction to Bitreactive
Introduction to Bitreactive
 
Développement d’une application de gestion des licences des contrôleurs aériens
Développement d’une application de gestion des licences des contrôleurs aériensDéveloppement d’une application de gestion des licences des contrôleurs aériens
Développement d’une application de gestion des licences des contrôleurs aériens
 
Etude, conception et réalisation d'une antenne planaire HF en technologie mic...
Etude, conception et réalisation d'une antenne planaire HF en technologie mic...Etude, conception et réalisation d'une antenne planaire HF en technologie mic...
Etude, conception et réalisation d'une antenne planaire HF en technologie mic...
 
VPN NOMADE AVEC AUTHENTIFICATIO AD SOUS ROUTEUR CISCO
VPN NOMADE AVEC AUTHENTIFICATIO AD SOUS ROUTEUR CISCOVPN NOMADE AVEC AUTHENTIFICATIO AD SOUS ROUTEUR CISCO
VPN NOMADE AVEC AUTHENTIFICATIO AD SOUS ROUTEUR CISCO
 
Vpn d’acces avec cisco asa 5500 et client
Vpn d’acces avec cisco asa 5500 et clientVpn d’acces avec cisco asa 5500 et client
Vpn d’acces avec cisco asa 5500 et client
 
Mise en place d'un système de messagerie sous debian avec: postfix, dovecot, ...
Mise en place d'un système de messagerie sous debian avec: postfix, dovecot, ...Mise en place d'un système de messagerie sous debian avec: postfix, dovecot, ...
Mise en place d'un système de messagerie sous debian avec: postfix, dovecot, ...
 
Transition ipv4-ipv6
Transition ipv4-ipv6Transition ipv4-ipv6
Transition ipv4-ipv6
 
Active Directory : nouveautés Windows Server 2012
Active Directory : nouveautés Windows Server 2012Active Directory : nouveautés Windows Server 2012
Active Directory : nouveautés Windows Server 2012
 
Important Vm Ware Infrastrucutre Slides
Important Vm Ware Infrastrucutre SlidesImportant Vm Ware Infrastrucutre Slides
Important Vm Ware Infrastrucutre Slides
 
IPv6
IPv6IPv6
IPv6
 
Résumé vlsm et cidr
Résumé vlsm et cidrRésumé vlsm et cidr
Résumé vlsm et cidr
 
Lire les tables de routage
Lire les tables de routageLire les tables de routage
Lire les tables de routage
 
Projet de fin d etudes
Projet de fin d etudesProjet de fin d etudes
Projet de fin d etudes
 
Mon Projet Fin d'étude: Conception et développement d'une application de géol...
Mon Projet Fin d'étude: Conception et développement d'une application de géol...Mon Projet Fin d'étude: Conception et développement d'une application de géol...
Mon Projet Fin d'étude: Conception et développement d'une application de géol...
 
Securing the Cloud
Securing the CloudSecuring the Cloud
Securing the Cloud
 

Similaire à TelCar : Solution de lecture des informations de bord de véhicule

Implémentation d’un gestionnaire de parc automobile
 Implémentation d’un gestionnaire de parc automobile Implémentation d’un gestionnaire de parc automobile
Implémentation d’un gestionnaire de parc automobile
Afaf MATOUG
 
Dimensionnement réseau de transmission pour un réseau GSM-R - AIT KADDOUR Ghi...
Dimensionnement réseau de transmission pour un réseau GSM-R - AIT KADDOUR Ghi...Dimensionnement réseau de transmission pour un réseau GSM-R - AIT KADDOUR Ghi...
Dimensionnement réseau de transmission pour un réseau GSM-R - AIT KADDOUR Ghi...
ImaneKneyti
 
Modélisation et résolution d’un problème de localisation des nœuds d’accès da...
Modélisation et résolution d’un problème de localisation des nœuds d’accès da...Modélisation et résolution d’un problème de localisation des nœuds d’accès da...
Modélisation et résolution d’un problème de localisation des nœuds d’accès da...fedi zouari
 
Rapport PFE "Conception et développement d'un Portail web pour le Smart Met...
Rapport  PFE  "Conception et développement d'un Portail web pour le Smart Met...Rapport  PFE  "Conception et développement d'un Portail web pour le Smart Met...
Rapport PFE "Conception et développement d'un Portail web pour le Smart Met...
Hajer Dahech
 
Memoire license iii
Memoire license iiiMemoire license iii
Memoire license iii
Gilles Kouamé
 
Rapport de-stage-technecien
Rapport de-stage-technecienRapport de-stage-technecien
Rapport de-stage-technecien
ghazwanikhouloud
 
Application anti-fraude
Application anti-fraudeApplication anti-fraude
Application anti-fraude
ts4riadhoc
 
Radio Mobile -Technologie sans fil
Radio Mobile -Technologie sans filRadio Mobile -Technologie sans fil
Radio Mobile -Technologie sans fil
KONAN MARTIAL
 
Radio Mobile -Technologie sans fil
Radio Mobile -Technologie sans filRadio Mobile -Technologie sans fil
Radio Mobile -Technologie sans fil
KONAN MARTIAL
 
Eisti - École d'ingénieurs pour DUT 2015-2016
Eisti - École d'ingénieurs pour DUT 2015-2016Eisti - École d'ingénieurs pour DUT 2015-2016
Eisti - École d'ingénieurs pour DUT 2015-2016
EISTI
 
(VPN)Virtual Private Network : ETUDE COMPARATIVE ET REALISATION D’UN VPN MPL...
(VPN)Virtual Private Network :  ETUDE COMPARATIVE ET REALISATION D’UN VPN MPL...(VPN)Virtual Private Network :  ETUDE COMPARATIVE ET REALISATION D’UN VPN MPL...
(VPN)Virtual Private Network : ETUDE COMPARATIVE ET REALISATION D’UN VPN MPL...
BelgeKilem
 
rapport de mémoire de mastère : sécurisation du réseau nan au sein des smart ...
rapport de mémoire de mastère : sécurisation du réseau nan au sein des smart ...rapport de mémoire de mastère : sécurisation du réseau nan au sein des smart ...
rapport de mémoire de mastère : sécurisation du réseau nan au sein des smart ...
yosra fraiji
 
2011 germine seide
2011 germine seide2011 germine seide
2011 germine seideAhlem DRIRA
 
Rapport_Memoire_Mastère_SRT_LARAFA_Mohamed_Akram.pdf
Rapport_Memoire_Mastère_SRT_LARAFA_Mohamed_Akram.pdfRapport_Memoire_Mastère_SRT_LARAFA_Mohamed_Akram.pdf
Rapport_Memoire_Mastère_SRT_LARAFA_Mohamed_Akram.pdf
LARAFA Mohamed Akram
 
memoire Magaye Gaye_ESMT Fevrier 2012 Dr Ouya_Dr Boudal Ing Ousseynou Diop
memoire Magaye Gaye_ESMT Fevrier 2012 Dr Ouya_Dr Boudal Ing Ousseynou Diopmemoire Magaye Gaye_ESMT Fevrier 2012 Dr Ouya_Dr Boudal Ing Ousseynou Diop
memoire Magaye Gaye_ESMT Fevrier 2012 Dr Ouya_Dr Boudal Ing Ousseynou Diop
MAGAYE GAYE
 
NGN MULTIMEDIA/IMS UMTS DIMENSIONEMENT
NGN MULTIMEDIA/IMS  UMTS  DIMENSIONEMENTNGN MULTIMEDIA/IMS  UMTS  DIMENSIONEMENT
NGN MULTIMEDIA/IMS UMTS DIMENSIONEMENT
MAGAYE GAYE
 
Etude et conception d'antenne reconfigurable pour radiocommunications
Etude et conception d'antenne reconfigurable pour radiocommunicationsEtude et conception d'antenne reconfigurable pour radiocommunications
Etude et conception d'antenne reconfigurable pour radiocommunications
ouissam cherier
 
Memoire version finale kenfack
Memoire version finale kenfackMemoire version finale kenfack
Memoire version finale kenfack
valmy roi
 

Similaire à TelCar : Solution de lecture des informations de bord de véhicule (20)

Implémentation d’un gestionnaire de parc automobile
 Implémentation d’un gestionnaire de parc automobile Implémentation d’un gestionnaire de parc automobile
Implémentation d’un gestionnaire de parc automobile
 
Dimensionnement réseau de transmission pour un réseau GSM-R - AIT KADDOUR Ghi...
Dimensionnement réseau de transmission pour un réseau GSM-R - AIT KADDOUR Ghi...Dimensionnement réseau de transmission pour un réseau GSM-R - AIT KADDOUR Ghi...
Dimensionnement réseau de transmission pour un réseau GSM-R - AIT KADDOUR Ghi...
 
Modélisation et résolution d’un problème de localisation des nœuds d’accès da...
Modélisation et résolution d’un problème de localisation des nœuds d’accès da...Modélisation et résolution d’un problème de localisation des nœuds d’accès da...
Modélisation et résolution d’un problème de localisation des nœuds d’accès da...
 
Rapport PFE "Conception et développement d'un Portail web pour le Smart Met...
Rapport  PFE  "Conception et développement d'un Portail web pour le Smart Met...Rapport  PFE  "Conception et développement d'un Portail web pour le Smart Met...
Rapport PFE "Conception et développement d'un Portail web pour le Smart Met...
 
Memoire license iii
Memoire license iiiMemoire license iii
Memoire license iii
 
PFE_Report
PFE_ReportPFE_Report
PFE_Report
 
Kallel mehdi
Kallel mehdiKallel mehdi
Kallel mehdi
 
Rapport de-stage-technecien
Rapport de-stage-technecienRapport de-stage-technecien
Rapport de-stage-technecien
 
Application anti-fraude
Application anti-fraudeApplication anti-fraude
Application anti-fraude
 
Radio Mobile -Technologie sans fil
Radio Mobile -Technologie sans filRadio Mobile -Technologie sans fil
Radio Mobile -Technologie sans fil
 
Radio Mobile -Technologie sans fil
Radio Mobile -Technologie sans filRadio Mobile -Technologie sans fil
Radio Mobile -Technologie sans fil
 
Eisti - École d'ingénieurs pour DUT 2015-2016
Eisti - École d'ingénieurs pour DUT 2015-2016Eisti - École d'ingénieurs pour DUT 2015-2016
Eisti - École d'ingénieurs pour DUT 2015-2016
 
(VPN)Virtual Private Network : ETUDE COMPARATIVE ET REALISATION D’UN VPN MPL...
(VPN)Virtual Private Network :  ETUDE COMPARATIVE ET REALISATION D’UN VPN MPL...(VPN)Virtual Private Network :  ETUDE COMPARATIVE ET REALISATION D’UN VPN MPL...
(VPN)Virtual Private Network : ETUDE COMPARATIVE ET REALISATION D’UN VPN MPL...
 
rapport de mémoire de mastère : sécurisation du réseau nan au sein des smart ...
rapport de mémoire de mastère : sécurisation du réseau nan au sein des smart ...rapport de mémoire de mastère : sécurisation du réseau nan au sein des smart ...
rapport de mémoire de mastère : sécurisation du réseau nan au sein des smart ...
 
2011 germine seide
2011 germine seide2011 germine seide
2011 germine seide
 
Rapport_Memoire_Mastère_SRT_LARAFA_Mohamed_Akram.pdf
Rapport_Memoire_Mastère_SRT_LARAFA_Mohamed_Akram.pdfRapport_Memoire_Mastère_SRT_LARAFA_Mohamed_Akram.pdf
Rapport_Memoire_Mastère_SRT_LARAFA_Mohamed_Akram.pdf
 
memoire Magaye Gaye_ESMT Fevrier 2012 Dr Ouya_Dr Boudal Ing Ousseynou Diop
memoire Magaye Gaye_ESMT Fevrier 2012 Dr Ouya_Dr Boudal Ing Ousseynou Diopmemoire Magaye Gaye_ESMT Fevrier 2012 Dr Ouya_Dr Boudal Ing Ousseynou Diop
memoire Magaye Gaye_ESMT Fevrier 2012 Dr Ouya_Dr Boudal Ing Ousseynou Diop
 
NGN MULTIMEDIA/IMS UMTS DIMENSIONEMENT
NGN MULTIMEDIA/IMS  UMTS  DIMENSIONEMENTNGN MULTIMEDIA/IMS  UMTS  DIMENSIONEMENT
NGN MULTIMEDIA/IMS UMTS DIMENSIONEMENT
 
Etude et conception d'antenne reconfigurable pour radiocommunications
Etude et conception d'antenne reconfigurable pour radiocommunicationsEtude et conception d'antenne reconfigurable pour radiocommunications
Etude et conception d'antenne reconfigurable pour radiocommunications
 
Memoire version finale kenfack
Memoire version finale kenfackMemoire version finale kenfack
Memoire version finale kenfack
 

TelCar : Solution de lecture des informations de bord de véhicule

  • 1. MINISTERE DE L’ENSEIGNEMENT SUPERIEUR DE LA RECHERCHE SCIENTIFIQUE ET DE LA TECHNOLOGIE UNIVERSITE TUNIS EL MANAR ÉCOLE NATIONALE D’INGENIEURS DE TUNIS DEPARTEMENT TECHNOLOGIES DE L’INFORMATION ET DE LA COMMUNICATION Projet de Fin d’études Présenté par Chaieb Ghassene Pour l’obtention du Le Diplôme National d’Ingénieurs en Télécommunications Sujet TelCar Solution de lecture des informations de bord de véhicule Réalisé à TELNET Innovation Labs Jury : Président : M. Rabah JERAD (Groupe TAWASOL) Co-Présidente : Mme Houria REZIG (ENIT) Rapporteur : M. Mahmoud AMMAR (ENIT) Encadrant Telnet : M. Mourad ZERIBI (Telnet Holding) Encadrant ENIT : M. Taher EZZEDINE (ENIT) Soutenu le 02/06/2016 Année universitaire : 2015-2016
  • 2. Signatures des encadrants M. Mourad ZERIBI M. Taher EZZEDINE
  • 4. Dédicaces Avec tout respect et amour je dédie ce modeste travail À mes chers parents : Aucune dédicace ne saurait exprimer l’amour, l’estime, le dévouement et le respect que j’ai toujours eu pour vous. Ce travail est le fruit de vos sacrifices que vous avez consentis pour mon éducation et ma formation. À ma cher ma chère fiancée Sabrine Pour tout l'amour et le soutien que tu m'as offert. Que dieu réunisse nos chemins pour un long commun serein À tous mes frères et mes amis, Pour tous les instants inoubliables que j'ai passés avec vous. Je vous souhaite le succès dans vos vies. À tous ceux que j'aime et qui m'aiment. Je dédie ce travail espérant avoir répondu à leurs souhaits de me voir réussir. Chaieb Ghassene
  • 5. Résumé La nécessité de contrôler nos véhicules, les suivre en temps réel nous a poussé de créer le boîtier « TelCar » qui se connecte à la prise diagnostic d'une voiture. Autonome, il communique avec un smartphone et offre une palette de services dignes des derniers modèles de voitures haut de gamme. Notre solution est composée de trois parties :  La partie embarquée qui permet de collecter les informations de bord du véhicule à travers le réseau CAN et d’envoyer des données au serveur de l’application. Mots clé : Internet des objets, Gateway, Raspberry pi, Services Web, Cloud
  • 6. Abstract The need to control our vehicles, track it in real time have pushed us to create the "Telcar" box that connects to the diagnostic socket of a car. Autonomous, it communicates with a smartphone and offers a range of services worthy of the latest models of high-end cars.Our solution consists of three parts:  The mobile part that allows the customer to control their cars via smartphone (maintenance expenses, diagnostics, recommendations, etc.);  A Back Office that allows managers to manage and control the functionality of the application ;  The board part that collects the edge information of the vehicle through the CAN network and send data to the application server. Keywords: Internet of Things, Gateway, Raspberry Pi, Web Services, Cloud
  • 7. Table des matières Introduction générale...........................................................................................1 Chapitre 1 Etat de l’art et solution proposée ......................................................2 1. Introduction................................................................................................................................3 2. Contexte du projet ......................................................................................................................3 2.1 Cadre du projet...................................................................................................................................3 2.2 Entreprise d’accueil : Telnet Holding..................................................................................................3 2.3 Problématique....................................................................................................................................4 3. Etude de l’existant.......................................................................................................................4 3.1 ZUS .....................................................................................................................................................4 3.2 CanCan............................................................................................................................................5 4. Solution et architecture proposée................................................................................................5 4.1 Solution ..............................................................................................................................................5 4.2 Architecture proposée........................................................................................................................6 5. Choix des technologies ................................................................................................................7 5.1 La Plate-forme Cloud IoT ....................................................................................................................7 5.1.1 Critères de choix..........................................................................................................................7 5.1.2 Étude comparative et choix de la plate-forme ............................................................................8 5.1.3 La plate-forme Xively...................................................................................................................8 5.2 La Gateway : Raspberry Pi ..................................................................................................................9 5.3 Le module Qualcomm EC20 LTE ......................................................................................................10 5.4 Le langage de programmation : Python............................................................................................10 5.5 Les web services ...............................................................................................................................11 5.5.1 Introduction...............................................................................................................................11 5.5.2 Service Web REST ......................................................................................................................11 5.5.3 Avantages de REST.....................................................................................................................12 5.5.4 Limites de REST..........................................................................................................................12 6. Conclusion ................................................................................................................................12 Chapitre 2 Etude et implémentation de la partie embarquée .............................. 13 1. Introduction..............................................................................................................................14 2. Préparation du Raspberry Pi ......................................................................................................14 2.1 Le Système d’exploitation Raspbian.................................................................................................14
  • 8. 2.2 Compilation croisée du module Linux pour Raspberry Pi .................................................................14 2.3 Connexion à distance au Raspberry pi : le protocole SSH.................................................................15 3. Le pilote QMI WWAN pour Quectel EC20 LTE .............................................................................15 3.1 Le protocole QMI..............................................................................................................................15 3.2 Le contrôleur ModemUP ..................................................................................................................16 3.3 Système GNSS/GPS...........................................................................................................................17 4. Lecture des informations de bord de véhicule ............................................................................18 4.1 Traitement des données du réseau CAN ..........................................................................................18 4.2 Communication SPI Raspberry-Microcontrôleur..............................................................................18 4.3 Protocole de communication ...........................................................................................................20 4.3.1 Format de la trame envoyée par le Raspberry ..........................................................................20 4.3.2 Format de la trame envoyée par le microcontrôleur.................................................................21 4.3.3 Contrôle de redondance cyclique (CRC) ....................................................................................21 5. Conclusion ................................................................................................................................21 Chapitre 3 Etude et implémentation de la partie BackOffice............................... 22 1. Introduction..............................................................................................................................23 2. Xively - Notions de base ............................................................................................................23 3. La phase de Développement......................................................................................................23 3.1 Xively Developer Workbench ...........................................................................................................24 3.1.1 Les canaux (Channels)................................................................................................................24 3.1.2 La localisation ............................................................................................................................25 3.1.3 Les déclencheurs .......................................................................................................................25 3.2 L’API REST de Xively..........................................................................................................................25 3.3 Création de périphérique .................................................................................................................27 3.4 Création des déclencheurs (Triggers) ...............................................................................................28 3.4.1 Zapier.........................................................................................................................................28 3.4.2Twilio..........................................................................................................................................29 4. La phase de Déploiement ..........................................................................................................29 4.1 Le processus de provisionnement ....................................................................................................30 4.2 Le scénario d'activation de l’appareil ...............................................................................................30 5. La phase de Gestion ..................................................................................................................31 6. Conclusion ................................................................................................................................32 Chapitre 4 Réalisation et tests de validation de notre solution ........................... 33 1. Introduction..............................................................................................................................34 2. Préparation du Raspberry Pi ......................................................................................................34
  • 9. 2.1 Installation du système d’exploitation Raspbian ..............................................................................34 2.2 Connexion à distance au Raspberry pi..............................................................................................34 2.3 Cross-compilation du module Linux .................................................................................................36 2.3.1 Compilation Locale sur Raspberry Pi .........................................................................................36 2.3.2 Compilation croisée avec Toolchain ..........................................................................................36 3. Installation du driver QMI WWAN pour Quectel EC20 ................................................................37 4. Création de l’application avec Xively..........................................................................................38 4.1 La phase de Développement : ..........................................................................................................38 4.1.1 Prototypage...............................................................................................................................38 4.1.2 Création de déclencheur avec Zapier ........................................................................................39 4.2 La phase de Déploiement .................................................................................................................40 5. Tests de validation ....................................................................................................................41 5.1 Activation de l’appareil.....................................................................................................................41 5.2 Envoi des données à la plateforme Xively ........................................................................................41 5.3 Envoi des données de localisation....................................................................................................42 5.4 Test des déclencheurs ......................................................................................................................43 6. Conclusion ................................................................................................................................43 Conclusion générale........................................................................................... 44 Bibliographie...................................................................................................... 45
  • 10. Liste des figures Figure1. 1 : Logo de Telnet Holding..................................................................................................................3 Figure1. 2 : La solution ZUS ..............................................................................................................................5 Figure1. 3 : Logo de la solution CanCan............................................................................................................5 Figure1. 4 : Architecture globale de la solution proposée................................................................................6 Figure1. 5 : Logo de Xively................................................................................................................................8 Figure1. 6 : La carte Raspberry Pi .....................................................................................................................9 Figure1. 7 : Le module Qualcomm EC20 LTE .................................................................................................10 Figure1. 8 : Logo de Python............................................................................................................................10 Figure2. 1 : Logo du système d'exploitation Raspbian ...................................................................................14 Figure2. 2 : Le diagramme d'états-transitions du script ModemUp ...............................................................16 Figure2. 3 : Communication SPI entre Master-slave ......................................................................................18 Figure2. 4 : Liaison SPI entre le Raspberry et le microcontrôleur...................................................................19 Figure2. 5 : Format de trame envoyée par le Raspberry ................................................................................20 Figure2. 6 : Format de la trame envoyée par le microcontrôleur...................................................................21 Figure3.1 : Logo de Xively Developer Workbench.........................................................................................23 Figure3.2 : Capture d'écran de l'interface Xively Developer Workbench .....................................................24 Figure3.3 : Architecture API/services de Xively .............................................................................................25 Figure3.4 : les Logos des bibliothèques de Xively...........................................................................................28 Figure3.5 : Logo de Zapier .............................................................................................................................28 Figure3.6 : Capture d'écran de site web Zapier.com .....................................................................................29 Figure3.7 : Logo de Twilio..............................................................................................................................29 Figure3.8 : Capture d'écran de la console de gestion....................................................................................31 Figure4.1 : Installation du Raspbian avec Win32 Disk Imager .......................................................................34 Figure4.2 : Capture d'écran del 'interface graphique du Raspberry sur VNC Viewer. ....................................35 Figure4.3 : Réservation de l'adresse 192.168.0.100 au Raspberry ................................................................35 Figure4.4 : Le menu USB Network Adaptaters de Raspbian..........................................................................37 Figure4.5 : les interfaces réseau de notre Raspberry ....................................................................................38 Figure4.6 : Xively Developer Workbench ......................................................................................................39 Figure4.7 : Création de déclencheur avec Xively et Zapier............................................................................39 Figure4.8 : Capture d'écran de la phase de déploiement..............................................................................40 Figure4.9 : Insertion des numéros de série des périphériques......................................................................40 Figure4.10: Activation du périphérique..........................................................................................................41 Figure4.11: Envoi des données à la plateforme Xively ...................................................................................41 Figure4.12: Visualisation des données ...........................................................................................................42 Figure4.13: Lecture des données de localisation ...........................................................................................42 Figure4.14: Envoi des données de localisation à la plateforme Xively ...........................................................43 Figure4.15: La localisation du périphérique avec Xively.................................................................................43 Figure4.16: Résultat du déclencheur..............................................................................................................43
  • 11. Liste des tableaux Tableau1. 1 : tableau comparatif des plateformes Cloud IoT...........................................................................8 Tableau 2 : Lees opérations accessibles via l'API REST de Xively....................................................................26
  • 12. Liste des acronymes AES : Advanced Encryption Standard API : Application Programming Interface CAN : Controller Area Network CoAP : Constrained Application Protocol CPU : Central Processing Unit CRC : Cyclic Redundancy Check CRUD : Create, Read, Update, Delete CSV : Comma-Separated Values DHCP : Dynamic Host Configuration Protocol GLONASS : GLObal NAvigation Satellite System GNSS : Global Navigation Satellite System GPIO : General Purpose Input/Output GPS : Global Positioning System GSM : Global System for Mobile communications HTML : Hypertext Markup Language HTTP : HyperText Transfer Protocol IdO : Internet des Objets IoT : Internet of Things IP : Internet Protocol IPsec : Internet Protocol Security JSON : JavaScript Object Notation LTE : Long Term Evolution MAC : Media Access Control MQTT : Message Queuing Telemetry Transport OBD : On-Board Diagnostics PaaS : Platform as a Service PCI : Peripheral Component Interconnect QMI : Qualcomm Mobile Station Modems Interface REST : REpresentational State Transfer SPI : Serial Peripheral Interface SSH : Secure SHell URI : Uniform Resource Identifier URL : Uniform Resource Locator VNC : Virtual Network Computing XML : eXtensible Markup Language
  • 13. 1 Introduction générale Selon l’Union internationale des télécommunications, l’Internet des objets (IdO) est une «infrastructure mondiale pour la société de l'information, qui permet de disposer de services évolués en interconnectant des objets (physiques ou virtuels) grâce aux technologies de l'information et de la communication interopérables existantes ou en évolution ». [1] L’IdO couvre actuellement plusieurs applications telles que:  les téléphones portables;  les compteurs électriques « intelligents » qui donnent un compte-rendu de la consommation en temps réel;  les « objets intelligents » dans le secteur de la logistique, l’industrie manufacturière ou la vente au détail.  Etc. Parmi les domaines dans lesquels l’internet des objets intervient, nous allons se focaliser sur le secteur de l’automobile. En effet, Connaître l'emplacement de sa voiture en temps réel ou recevoir des informations sur son état actuelle sont des fonctionnalités que les constructeurs de véhicule ont déjà intégrées dans leurs modèles de voitures haute gamme. Dans le cadre de ce projet de fin d’études réalisé à « Telnet innovation Labs », Nous nous proposons de mettre les fonctionnalités citées ci-dessus, à la disposition des voitures entrée de gamme. Nous proposons ainsi une solution baptisée « TelCar » qui consiste en un boitier à brancher sur la prise de diagnostic OBD d’un véhicule. Cette boite sera capable de traiter et d’envoyer les informations de bord au serveur de gestion. Une application mobile sera par la suite capable de récolter ces informations et les présenter d’une manière simple à l’utilisateur. Dans ce cadre nous allons particulièrement nous intéresser à deux parties de ce projet : a) Développer une solution permettant d’envoyer les informations de bord d’un véhicule à un serveur d’application, b) Développer la partie BackOffice permettant de gérer l’ensemble des nœuds (Véhicule) et de contrôler le fonctionnement de l’application. Pour présenter la démarche que nous avons suivie, notre rapport se présente de la façon
  • 14. 2 Suivante : Le premier chapitre sera consacré à la présentation du contexte du projet, une étude des applications existantes et un aperçu sur notre solution ainsi que les technologies à utiliser. Le deuxième chapitre présentera une étude de la partie embarquée de cette solution. Ensuite, la troisième partie mettra l’accent sur l’étude et l’implémentation de la partie BackOffice. Enfin, le dernier chapitre détaillera les différentes étapes réalisé ainsi que les tests de validation. Nous finissons le rapport par une conclusion générale.
  • 15. 2 Chapitre 1 Etat de l’art et solution proposée Sommaire 1. Introduction................................................................................................................................3 2. Contexte du projet ......................................................................................................................3 3. Etude de l’existant.......................................................................................................................4 4. Solution et architecture proposée................................................................................................5 5. Choix des technologies ................................................................................................................7 6. Conclusion ................................................................................................................................12 1. Introduction..............................................................................................................................14
  • 16. 3 1. Introduction Dans ce chapitre, Nous exposons le contexte général du projet ainsi que la démarche et les technologies qui vont nous servir à mieux comprendre notre sujet. 2. Contexte du projet 2.1 Cadre du projet 2.2 Entreprise d’accueil : Telnet Holding Figure1. 1 : Logo de Telnet Holding TELNET est un groupe de sociétés tunisien spécialisé dans le conseil dans l'innovation et les hautes technologies. Crée en 1994, Elle est rapidement devenue leader dans son cœur de métier à l’échelle nationale. Elle a cherché depuis sa création à élargir ses champs de compétences afin de proposer à ses clients des prestations de qualité et diversifiées selon les spécifications demandées.
  • 17. 4 Dans un souci de proximité de ses clients, TELNET opère selon un modèle Front office / back office, elle propose essentiellement des prestations d’ingénierie en Offshore pour et en Nearshore pour le compte des plus grands groupes internationaux. Elle est considérée comme un acteur majeur dans le domaine des hautes technologies et occupe un positionnement de plus en plus important à l’échelle régionale. Elle développe une expertise métier notamment dans le développement de Systèmes Intégrés le design Électronique et Microélectronique ainsi que dans l’Ingénierie Mécanique. (Telnet holding, 2009) 2.3 Problématique Surveillez et soyez alertez à tout moment si votre voiture est en mouvement, prévenez les services d’urgence en cas de panne, malaise et automatiquement en cas d’accident en communiquant votre position géographique et suivre l’état de votre véhicule (dépenses, entretiens, diagnostique, etc.) sont des fonctionnalités disponibles sur les véhicules neufs possédant un système communicant. Mais ce sont généralement les véhicules sophistiqués des marques premium et qui coûte très cher. Est-il possible de profiter des mêmes services avec n'importe quelle voiture, pour peu qu'elle soit âgée de moins de quinze ans et possède une prise diagnostic ? 3. Etude de l’existant 3.1 ZUS ZUS est un chargeur allume-cigare. À part recharger les mobiles sur la route, il fait également office de traqueur Bluetooth afin de localiser la voiture depuis un smartphone. Il peut ainsi se servir du GPS embarqué du mobile pour suivre et localiser l’emplacement de la voiture dès que le moteur est éteint.
  • 18. 5 De cette manière, l’utilisateur est en mesure de retrouver facilement sa voiture même dans un parking bondé. (Nonda, 2016) Figure1. 2 : La solution ZUS Le coût de la solution : $49.99 Limites : - Aucune interaction avec le réseau CAN de la voiture. - Absence de Web services 3.2 CanCan Figure1. 3 : Logo de la solution CanCan CanCan délivre un diagnostic rapide du véhicule à chaque démarrage, grâce au dialogue avec le réseau de bord CAN via la prise OBD. Cette boite communique en Bluetooth avec une application sur smartphone. (Cancan, 2015) Le coût de la solution : $200 Limites : - La solution n’offre pas une communication à distance (via des services Web) avec l’utilisateur. 4. Solution et architecture proposée 4.1 Solution Connaître l'emplacement de sa voiture en temps réel ou recevoir des informations sur son type de conduite, ces applications sont déjà disponibles sur les véhicules neufs possédant un système communicant. Mais ce sont généralement les véhicules sophistiqués des marques premium.
  • 19. 6 Toutefois, il reste possible de profiter des mêmes services avec n'importe quelle voiture, pour peu qu'elle soit âgée de moins de quinze ans et possède une prise diagnostic. Notre solution baptisé TelCar consiste à utiliser un boîtier à brancher sur cette prise OBD. TelCar recueille les informations de bord du véhicule (celles du Bus Can) et possède son propre module LTE. Communicant en réseau avec une application sur un smartphone, elle lui envoie toutes les informations récoltées. 4.2 Architecture proposée Comme il est indiqué dans la figure 1.4, notre solution se compose de trois parties :  Une partie embarquée qui permet de collecter les informations de bord du véhicule à travers le réseau CAN et d’envoyer des données au serveur de la plateforme Cloud Iot;  Une partie BackOffice qui permet aux responsables de gérer et contrôler le fonctionnement de l’application. Cette partie est centralisée dans une plate-forme Cloud IoT et permet de : Ajouter/supprimer une véhicule Ajouter/supprimer un service, Stocker les données et les métadonnées de chaque véhicule, etc;  Une application mobile (FrontOffice) qui permet au client de contrôler ses voitures (entretiens, diagnostique, recommandations, …). Figure1. 4 : Architecture globale de la solution proposée
  • 20. 7 La communication entre les différentes composantes de la solution se fait à travers un web service qui garantit l’interopérabilité. Dans le cadre de notre projet de fin d’études, nous allons se focaliser sur deux parties de ce projet : c) Développer une solution permettant d’envoyer les données du réseau CAN supposés déjà traités, d) Développer la partie BackOffice sur une plate-forme Cloud IoT permettant de gérer l’ensemble des nœuds (Véhicule) et de contrôler le fonctionnement de l’application. 5. Choix des technologies 5.1 La Plate-forme Cloud IoT Les plates-formes de l'Internet des objets (IdO) permettent de connecter des appareils hétérogènes des applications et les faire communiquer entre eux. Elles jouent un rôle crucial pour réduire le coût de développement des solutions et des applications IdO. Elles permettent non seulement de connecter des objets, mais aussi d’implémenter des protocoles de communication complexes et variés. Ces plates-formes offrent aussi toute l’infrastructure back-end nécessaire pour le développement des applications dédiées à l’internet des objets : management des objets, bases de données, serveurs etc. Aujourd'hui il existe plusieurs plates-formes IdO disponibles sur le marché. Une étude comparative est indispensable pour bien choisir la solution. 5.1.1 Critères de choix Savoir identifier la bonne plate-forme cloud IoT à utiliser sera un enjeu important et critique pour la conception de notre projet. Le choix est basé sur 4 critères :  Ouverture : C’est une caractéristique importante attendue d’une plate-forme cloud Iot. L’interface de programmation applicative (API) devrait fournir un accès aux opérations et aux données qui doivent être exposés à partir de la plate-forme. Ceci permet aux applications et aux appareils hétérogènes de communiquer entre eux facilement. Souvent on utilise des API REST pour atteindre cet objectif.
  • 21. 8  Gestion des objets connectés : La plate-forme devrait maintenir une liste des périphériques connectés et dépister leur état de fonctionnement.  Sécurité et confidentialité : la connexion réseau entre les objets connectés et la plate-forme IoT devrait être chiffrée avec un mécanisme de cryptage fort pour éviter tout espionnage éventuel  Protocoles de collecte de données : Une plate-forme IoT peut être relié à des millions voire des milliards d’objets connectés (nœuds). Des protocoles de communication légers devraient être utilisés pour garantir une faible consommation d’énergie et de bande passante. 5.1.2 Étude comparative et choix de la plate-forme Tableau1. 1 : tableau comparatif des plateformes Cloud IoT plate-forme Cloud IoT Gestion des objets API Sécurité Protocoles de communication Prise en charge de la visualisation Appcelerator Non API REST Link Encryption (SSL, IPsec, AES) MQTT, HTTP Oui Ericsson MDM IoT Platform Oui API REST Link Encryption (SSL/TSL) CoAP Non Xively Oui API REST Link Encryption (SSL/TSL) HTTP, HTTPS, Sockets/ Websocket, MQTT Oui En tenant compte du tableau 1.1, nous pouvons déduire que la plate-forme Xively représente un outil plus performant et mieux adapté à nos besoins. Elle offre des fonctionnalités avancés de gestion des nœuds et utilise des protocoles de communication légers. 5.1.3 La plate-forme Xively Xively est une « Platform as a Service » (PaaS) pour l'internet des objets. Xively simplifie l'interconnexion d'équipements, des données, des personnes et des lieux en accélérant la création de solutions convaincantes qui transforment la façon dont les gens vivent leur monde. (Xively, Figure1. 5 : Logo de Xively
  • 22. 9 5.2 La Gateway : Raspberry Pi La Gateway c’est la composante qui va assurer le transfert des données du véhicule vers la plate-forme Cloud. Parce qu'il est équipé d’un processeur ARMv7, il est capable de faire tourner toute la gamme des distributions ARM GNU / Linux, y compris Snappy Ubuntu Core, ainsi que Microsoft Windows 10 IoT. Il est équipé de :  CPU quad-core ARM Cortex-A7 900MHz  1GB de RAM  4 ports USB  40 broches GPIO  Port HDMI  Port Ethernet  Prise Jack  Interface d'appareil photo  Interface d'affichage Figure1. 6 : La carte Raspberry Pi
  • 23. 10 5.3 Le module Qualcomm EC20 LTE Figure1. 7 : Le module Qualcomm EC20 LTE Le module Quectel EC20 LTE offre une connectivité de données sur les réseaux LTE, WCDMA et les réseaux GSM avec l’interface standard PCI Express 1.2. Il prend en charge plusieurs systèmes d'exploitation tels que WinCE, Linux et Android, etc. Il est aussi équipé d’un récepteur GNSS qui supporte le GPS et le GLONASS permettant de localisé rapidement et en temps réelle le module. Pour pouvoir l’utiliser avec Raspberry Pi sous Linux, il faut installer le pilote QMI WWAN. 5.4 Le langage de programmation : Python Python est un langage de programmation interprété orienté objet, qui a gagné en popularité en raison de sa syntaxe claire et sa lisibilité. Il est multiplateforme (disponible sous Windows, Mac et Linux). Figure1. 8 : Logo de Python Python permet à la fois une programmation impérative dans le style du langage C et la programmation orientée objet comme le Java et le C++.
  • 24. 11 5.5 Les web services 5.5.1 Introduction Un service web est un composant logiciel permettant la communication entre les applications et les systèmes hétérogènes dans le but de créer un environnement distribué. Ainsi, les applications peuvent envoyer et recevoir des données en utilisant des technologies différentes (l’interopérabilité). Les services web utilisent le protocole HTTP(S) (Hypertext Transfer Protocol) pour le transfert des données sous format normalisés (XML, JSON, CSV). Il existe plusieurs technologies derrière le terme services web, dans notre application nous allons utiliser le service web de type REST (Representational state transfer). 5.5.2 Service Web REST Le service web de type REST suit les règles suivantes : Un service web est un composant logiciel permettant la communication entre les applications et les systèmes hétérogènes dans le but de créer un environnement distribué. Ainsi, les applications peuvent envoyer et recevoir des données en utilisant des technolo gies différentes (l’interopérabilité). Les services web utilisent le protocole HTTP(S) (Hypertext Transfer Protocol) pour le transfert des données sous formatnormalisés (XML,JSON,CSV).
  • 25. 12 5.5.3 Avantages de REST 5.5.4 Limites de REST 6. Conclusion
  • 26. 13 Chapitre 2 Etude et implémentation de la partie embarquée Sommaire 1. Introduction..............................................................................................................................14 2. Préparation du Raspberry Pi ......................................................................................................14 3. Le pilote QMI WWAN pour Quectel EC20 LTE .............................................................................15 4. Lecture des informations de bord de véhicule ............................................................................18 5. Conclusion ................................................................................................................................21
  • 27. 14 1. Introduction Dans ce deuxième chapitre, on s’intéresse à l’étude du module central de Gateway et sa liaison avec la partie responsable du traitement des données de bord du véhicule. 2. Préparation du Raspberry Pi 2.1 Le Système d’exploitation Raspbian La plupart des systèmes qui fonctionnent sur Raspberry Pi sont des versions du système d'exploitation Linux. Parce que Linux est open source, les développeurs peuvent l’adopter pour des buts spécifiques. Dans le cas de Raspberry Pi, le matériel léger nécessite un système réduit et privé d'applications inutiles 2.2 Compilation croisée du module Linux pour Raspberry Pi Il existe deux méthodes principales pour la construction du noyau Linux. Nous pouvons le construire localement sur notre Raspberry Pi (qui prendra beaucoup de temps); ou bien nous pouvons effectuer Figure2.19 : Logo du système d'exploitation Raspbian
  • 28. 15 une compilation croisée sur notre machine hôte avec « TOOLCHAIN », ce qui est beaucoup plus rapide, mais nécessite plus de configuration. 2.3 Connexion à distance au Raspberry pi : le protocole SSH Secure Shell (SSH) est un protocole de réseau crypté pour initier des sessions Shell textuelles sur des machines distantes de manière sécurisée. Cela permet à un utilisateur d'exécuter des commandes sur l'invite de commande d'une machine sans qu'ils soient physiquement présents à proximité de la machine. 3. Le pilote QMI WWAN pour Quectel EC20 LTE Pour pouvoir utiliser modem EC20 LTE de Quectel avec le Raspberry, nous devons installer le pilote QMI WWAN. 3.1 Le protocole QMI QMI (Qualcomm Mobile Station Modems Interface) est un protocole binaire conçu pour remplacer la communication avec les modems basés sur les commandes AT. Il est disponible dans les appareils avec des chipsets Qualcomm provenant de plusieurs fournisseurs (Huawei, Sierra Wireless, ZTE et bien sûr Qualcomm lui-même). Ce protocole définit différents «services», chacun d'entre eux est lié à différentes actions qui peuvent être demandées au modem :  Le service «DMS» (Device Management services) : offre des fonctions permettant de changer les informations de l’appareil  le service «NAS» (Network Access services) : offre des fonctions permettant de s’inscrire dans le réseau.  le service « WDS » (Wireless Data Service) : offre des fonctions permettant l'utilisateur à créer des connexions de données et à demander les rapports de localisation GPS.
  • 29. 16 3.2 Le contrôleur ModemUP Pour connecter notre Raspberry pi à internet par le biais du modem EC20, nous devons envoyer des messages QMI après chaque redémarrage. Afin d’automatisé cette tâche, nous avons créé un script « ModemUp » qui assure le bon fonctionnement de notre modem. Ce script vérifie :  la présence du modem EC20 LTE  le statut de l’interface wwan  le statut de la connexion internet Le diagramme d'états-transitions du script ModemUp est le suivant : Figure2.2 10 : Le diagramme d'états-transitions du script ModemUp
  • 30. 17 Enfin, pour les imprévus, nous devons relancer le script une fois par minute avec « cron » et mettre les erreurs dans un fichier log. 3.3 Système GNSS/GPS Le modem EC20 LTE est équipé d’un récepteur GNSS (Global Navigation Satellite System) qui supporte le GPS (Global Positioning System) et le GLONASS (GLObal NAvigation Satellite System) permettant de localiser rapidement et en temps réel le module. Le GNSS permet de déterminer l’emplacement du modem sans aucune assistance du réseau. La procédure de mise en marche du GNSS est présentée ci-dessous: 1. activer le GNSS avec la commande « AT + QGPS », 2. obtenir les informations de localisation avec la commande « AT+QGPSLOC ». La trame obtenue est la suivante : « UTC », « latitude », « longitude », « hdop », « altitude », « fix », « spkm », « date », « nsat » Avec :  « UTC » : Heure UTC. Format: hhmmss.sss  « latitude » : Latitude  « longitude » : Longitude  « hdop » : précision horizontale  « altitude » : L'altitude de l'antenne par rapport au niveau de la mer (en mètre)  « fix » : mode de positionnement GNSS (positionnement 2D ou 3D)  « spkm » : Vitesse (en Km/h)  « date » : La date de positionnement  « nsat » : Nombre de satellites utilisés 3. arrêter le GNSS avec la commande « AT+QGPSEND »
  • 31. 18 4. Lecture des informations de bord de véhicule 4.1 Traitement des données du réseau CAN Le traitement de ce fichier est réalisé par un microcontrôleur ST. Nous allons supposer que ce fichier est déjà traité et que les données de bord sont présentes sur le microcontrôleur sous le format « ID, valeur ». Par la suite, nous allons relier le Raspberry au microcontrôleur via le protocole SPI pour extraire ces données. 4.2 Communication SPI Raspberry-Microcontrôleur Le bus SPI utilise quatre signaux logiques : Figure2.3 11 : Communication SPI entre Master-slave
  • 32. 19 Le microcontrôleur et le Raspberry sont connectés comme le montre la figure suivante : Figure2.4 12 : Liaison SPI entre le Raspberry et le microcontrôleur Nous avons configuré le Raspberry Pi comme maitre et le microcontrôleur comme esclave.
  • 33. 20 Dans le cas d’une alerte, et pour permettre au système de réagir en temps réel, nous avons configuré le microcontrôleur pour envoyer une interruption au Raspberry suivant le scénario suivant : 1. La liaison GPIO est initialement à 0, 2. Le Raspberry génère l’horloge et envoie la requête de demande au microcontrôleur, 3. Le microcontrôleur repend par les informations demandées, 4. Fin de la communication, 5. Si le microcontrôleur veut envoyer des données critiques au Raspberry, il envoie un bit 1 par le biais de la liaison GPIO. 6. Le Raspberry crée une interruption et envoie une demande de lecture des informations critiques. 7. Le microcontrôleur repend par les informations critiques. 4.3 Protocole de communication C’est l’ensemble des règles qui permettent l’échange des données entre les deux systèmes. Dans notre cas, nous avons développé notre propre protocole qui se présente de la façon suivante : 1. Le Raspberry envoie une trame de demande au microcontrôleur. 2. Le microcontrôleur repend par une trame contenant les informations demandées. 4.3.1 Format de la trame envoyée par le Raspberry La trame de demande d’information commence par le caractère « $ » suivi d’un champ qui indique le nombre des informations demandés. Puis, les identifiant des informations demandés et enfin un dernier champ de détection d’erreurs CRC. Le format de la trame de demande est représenté dans la figure XX. Figure2.513 : Format de trame envoyée par le Raspberry
  • 34. 21 4.3.2 Format de la trame envoyée par le microcontrôleur La trame de réponse envoyée par le microcontrôleur commence par le caractère « $ ». Puis, un champ qui indique l’identifiant de l’information demandée suivi de sa valeur. Enfin un dernier champ de détection d’erreurs CRC. Le format de la trame de demande est représenté dans la figure XX. Figure2.6 14 : Format de la trame envoyée par le microcontrôleur 4.3.3 Contrôle de redondance cyclique (CRC) 5. Conclusion Dans ce chapitre, nous avons détaillé les différentes étapes de préparation du Raspberry Pi comme étant la partie centrale du Gateway. Dans le chapitre suivant, nous allons décrire les différentes phases de création de la partie Backoffice.
  • 35. 22 Chapitre 3 Etude et implémentation de la partie BackOffice Sommaire 1. Introduction..............................................................................................................................23 2. Xively - Notions de base ............................................................................................................23 3. La phase de Développement......................................................................................................23 4. La phase de Déploiement ..........................................................................................................29 5. La phase de Gestion ..................................................................................................................31 6. Conclusion ................................................................................................................................32
  • 36. 23 1. Introduction Après avoir présenté les différentes parties de préparation de notre Raspberry ainsi que le protocole de communication avec la partie responsable de traitement informations de bord du véhicule, nous consacrons ce chapitre à la présentation des différentes phases de création de la partie BackOffice qui jouera le rôle d’une interface entre les données et l’application mobile et qui permettra les responsables de gérer et contrôler le fonctionnement de l’application. 2. Xively - Notions de base Xively (anciennement connu sous le nom Cosm et Pachube) est une division de LogMeIn. C’est une entreprise mondiale, publique qui offre une plateforme « PaaS » (Platform as a Service) pour l'internet des objets. Elle simplifie l'interconnexion d'équipements des données, des personnes et des lieux. Xively facilite la création de solutions convaincantes qui transforment la façon dont les gens vivent leur monde. Le processus de création de solution sous Xively se déroule en trois étapes :  La phase de développement : Prototypage de l’application avec « Xively Developer Workbench »,  La phase de Déploiement : Transformation du prototype en produits,  La phase de Gestion : Gestion du lot de produits sans considérer sa taille et contrôle des appareils en temps réel. 3. La phase de Développement Dans la phase de développement l'objectif est d'obtenir un prototype de notre produit final qui répond à nos besoins. Nous pouvons facilement créer et connecter nos périphériques, services et/ou applications grâce à « Xively Developer Workbench ». Figure3.1 15 : Logo de Xively Developer Workbench
  • 37. 24 3.1 Xively Developer Workbench Chaque périphérique connecté dispose de son propre dashboard personnalisable là où nous pouvons configurer les canaux, les méta-données, les autorisations et la connexion avec d’autres services. Figure3.2 16 : Capture d'écran de l'interface Xively Developer Workbench 3.1.1 Les canaux (Channels) Un canal permet l'échange bidirectionnel de points de données entre la plate-forme Xively et les périphériques, les applications et les services autorisés. Chaque canal est caractérisé par un nom et un type de valeur.
  • 38. 25 3.1.2 La localisation Il existe un lien pour ajouter manuellement les données de localisation à notre appareil s’il est immobile, mais également notre nœud peut facilement envoyer ces données de localisation à la plateforme Xively. 3.1.3 Les déclencheurs Les déclencheurs sont utilisés pour intégrer des services. Il suffit de spécifier le canal, la condition de déclenchement (par exemple Température>90…) et le type de déclencheur (SMS, Mail, Tweet …). Lorsque la condition est satisfaite, les déclencheurs appellent le(s) service(s) concerné. 3.2 L’API REST de Xively Le service Cloud Xively fournit la messagerie, l'archivage des données, les services d'approvisionnement et d'annuaire qui sont accessibles via l'API Xively. L'API Xively rend rapide et facile la création des produits qui se connectent sur l'internet des objets. Figure3.3 17 : Architecture API/services de Xively Le tableau suivant présente l'ensemble des opérations que nous pouvons effectuer avec l'API Xively. Ces opérations sont effectuées en utilisant 7 ressources Xively: Products, Devices, Keys, Feeds, Triggers, Datastreams, et Datapoints. Chaque ressource est associée à des attributs spécifiques.
  • 39. 26 Remarque: Il est à noter que si nous ne spécifions pas de type format de données : JSON, CSV ou XML lors de l'interaction avec l'API Xively, le format par défaut accepté / retournée sera JSON. Tableau 2 : Lees opérations accessibles via l'API REST de Xively Ressources Opération Format Exemple d’URL Méthode Réponse Feeds Lire json, xml, csv https://api.xively.com/v2/feeds/ GET Flux contenant l'état actuel de tous les Flux de données et de métadonnées. Feeds Lire (intervalle) Json, xml, csv https://api.xively.com/v2/feeds/feed_id?range GET Flux contenant l’historique de données de chaque canal (datastream) Feeds Mettre à jour Json, xml, csv https://api.xively.com/v2/feeds/feed_id PUT Entêtes HTTP seulement Datastreams Ecrire Json, xml, csv https://api.xively.com/v2/feeds/feed_id/datastreams POST n/a Datastreams Lire Json, xml, csv https://api.xively.com/v2/feeds/feed_id/ datastreams/datastream_id GET Flux contenant l'état actuel du canal (datastream) demandé. Datastreams Mettre à jour Json, xml, csv https://api.xively.com/v2/feeds/feed_id/ datastreams/datastream_id PUT Entêtes HTTP seulement Datastreams Supprimer Json, xml, csv https://api.xively.com/v2/feeds/feed_id/ datastreams/datastream_id DELETE Entêtes HTTP seulement Datasreams Toute la liste https://api.xively.com/v2/feeds/feed_id GET Flux contenat tous les canaux ainsi que ses points de données Datapoints Supprimer n/a https://api.xively.com/v2/feeds/feed_id/ datastreams/datastream_id/datapoints/timestamp DELETE Entêtes HTTP seulement Products Ecrire Json https://api.xively.com/v2/products POST Entête avec l'emplacement de produit créé.
  • 40. 27 Ressources Opération Format Exemple d’URL Méthode Réponse Products Mettre à jour Json https://api.xively.com/v2/products/product_id PUT Entêtes HTTP seulement Products Lire Json https://api.xively.com/v2/products/product_id GET Flux contenant un produit unique Product Supprimer n/a https://api.xively.com/v2/products/product_id DELETE Entêtes HTTP seulement Devices Ecrire Json https://api.xively.com/v2/products/product_id/devices Post Entête avec l'emplacement de l'appareil créé Devices Lire Json https://api.xively.com/v2/products/ product_id/devices/serial_number GET Flux contenant un appareil unique Devices Mettre à jour Json https://api.xively.com/v2/products/ product_id/devices/serial_number PUT Entêtes HTTP seulement Devices Supprimer n/a https://api.xively.com/v2/products/ product_id/devices/serial_number DELETE Entêtes HTTP seulement Devices Activation Json, csv https://api.xively.com/v2/devices/ activation_code/activate GET Entêtes HTTP seulement Key Ecrire Json, xml https://api.xively.com/v2/keys POST Entêtes HTTP seulement Key Supprimer n/a https://api.xively.com/v2/keys/key_id DELETE Entêtes HTTP seulement Triggers Ecrire Json, xml https://api.xively.com/v2/triggers/ POST Entêtes HTTP seulement Avec l’API REST de Xively, nous pouvons facilement exécuter des opérations sur nos ressources : il suffit d’envoyer l’URL de l’opération désiré au serveur en utilisant une des requêtes HTTP : GET PUT, POST, DELETE, UPDATE. 3.3 Création de périphérique Pour créer un périphérique, il suffit de lui donner un nom, une description et de définir les droits d'accès. Après la création d’un périphérique, Xively crée automatiquement un FEED ID et un API KEY que nous aurons besoin pour connecter votre appareil. Le FEED ID joue le rôle d’un identifiant de notre périphérique. C’est l'ensemble des flux de données et de métadonnées définies pour un dispositif.
  • 41. 28 Figure3.4 18: les Logos des bibliothèques de Xively L’API KEY détermine les droits d'accès aux ressources Xively créés pour notre périphérique. Xively crée une clé API automatiquement pour notre prototype avec l'autorisation complète: lire mettre à jour, écrire, supprimer. Nous pouvons également créer des clés avec des autorisations plus fines pour plus de sécurité et pour obtenir le droit d'accès au bon moment et à la bonne personne. Pour connecter notre appareil, il suffit de copier le FEED ID affichée et l’API KEY dans notre code chargé d'établir une communication bidirectionnelle entre le Raspberry et Xively. Pour rendre le processus plus facile, Xively fournit des bibliothèques « open source » et hébergé sur Github. Le test se fait avec « Xively Developer Workbench », nous pouvons déboguer en temps réel et contrôler la communication bidirectionnelle entre l’appareil et Xively. Nous pouvons aussi suivre les valeurs de mise à jour sur le canal l'historique de demande et les requêtes HTTP en temps réel. 3.4 Création des déclencheurs (Triggers) 3.4.1 Zapier Figure3.5 19 : Logo de Zapier Zapier est un service qui nous permet d'automatiser les tâches entre les applications web. Connecter un déclencheur Xively à Zapier permet à notre application d’envoyer un tweet avec Twitter, appeler ou envoyer un SMS avec Twilio ou activer des services existants dans des applications web. Les déclencheurs Xively peuvent être activés lorsque la valeur d'un canal répond des critères que nous définissons.
  • 42. 29 Mise en place d’un trigger avec Zapier:  créer un Zap.  Un Zap est composé d’un déclencheur et une action.  Définir le déclencheur comme un Webhooks  Définir l’action, par exemple « envoyer un Email » Figure3.6 20 : Capture d'écran de site web Zapier.com 3.4.2Twilio Figure3.7 21 : Logo de Twilio Twilio est une plateforme Cloud qui permet aux développeurs de logiciels de passer et recevoir des appels téléphoniques et des SMS en utilisant ses API de web service. Twilio peut être facilement interfacé avec Zapier afin de créer des services à notre application. 4. La phase de Déploiement Tournons le prototype en produits : Lors du déploiement, nous créons un lot de produits virtuels dans Xively qui correspondent à un lot de produits physiques fabriqués. Un lot de produits est défini par les canaux du produit et une liste des numéros de série de chaque périphérique. Xively génère automatiquement un Product ID et un Product Secret pour notre nouveau lot de produits qui seront utiles par la suite.
  • 43. 30 Pour pré-enregistrer les périphériques de ce lot, nous devons ajouter des numéros de série soit en téléchargeant un fichier CSV qui contient un numéro de série par ligne ou en entrant les numéros de série manuellement. Le pré-enregistrement permet Xively de reconnaître les appareils autorisés quand ils se réveillent et transmettent leur code d'activation au cours du processus de provisionnement. 4.1 Le processus de provisionnement Le provisionnement est le processus d'activation de l'appareil. Le terme «Provisionnement» provient du fait que le dispositif est «provisionné» avec un FEED ID et un API KEY lors de son premier appel d'activation à l'API Xively. L'API de provisionnement Xively rend la scalabilité facile, élimine le coût et la difficulté de développement software en permettant à l’appareil d’être pré-configuré d'une manière qui garantit son réveil, son activation et pouvoir l’associer avec l’utilisateur en toute sécurité. 4.2 Le scénario d'activation de l’appareil L’activation de l’appareil se fait en 6 étapes : 1. Avant que le dispositif soit activé, il doit être préinscrit sur Xively sous son produit parent de sorte que l'API attend un appel d'activation de ce dispositif particulier quand il se réveille pour la première fois. Le Pré-enregistrement d'un périphérique est accompli en important le numéro de série de l'appareil dans la plateforme Xively. 2. Le dispositif physique (pré-enregistré) est mis en ligne. 3. Le dispositif adresse une demande d'activation sécurisée contenant son code d’activation en utilisant l’API Xively. Cela indique à Xively que le dispositif a réveillé pour la première fois, et demande à être approvisionné avec un FEED ID et un API KEY. Le code d'activation du dispositif est généré en utilisant un hachage HMAC-SHA1 qui combine le numéro de série de l'appareil avec le Product Secret de son parent, ce qui rend impossible pour quelqu'un l'extraction de Product Secret à partir du code d'activation. 4. La demande est validée par Xively pour assurer qu'il est correcte de point de vue cryptographique et que le dispositif n'est pas encore activé. 5. Xively retourne les informations d’activation (FEED ID et l’API KEY) au périphérique activé.
  • 44. 31 6. Le dispositif enregistre ces derniers afin qu'il puisse interagir en toute sécurité avec Xively pour toutes opérations futures. 5. La phase de Gestion Figure3.8 22 : Capture d'écran de la console de gestion Xively nous donne la possibilité de gérer les lots de produits, peu importe la taille une ou un million et soutenir nos appareils en temps réel. Maintenant, nous gérons nos produits, en utilisant la console de gestion pour soutenir nos produits et nos clients de la manière suivante :  Ajouter des numéros de série pour d'autres périphériques à notre lot de produit,  afficher tous les périphériques du lot de produit,  rechercher un appareil (filtrer la liste). Un simple clic sur le numéro de série nous permet de contrôler l’appareil concerné. La page de surveillance est pratiquement identique au « Workbench » sur lequel nous avons configuré notre prototype original. Nous pouvons contrôler les appareils, les canaux, la localisation, les métadonnées, le journal de requêtes, l'API KEY, et les déclencheurs.
  • 45. 32 Les actions de contrôle sont les suivantes :  Activer/Désactiver un appareil,  Activer/désactiver un service,  vérifier que les données provenant d'un appareil sont correctes  déboguer et visualiser ou suivre les requêtes en temps réel. 6. Conclusion Dans ce chapitre, nous avons décrire les différentes phases de création de la partie Backoffice qui permettra lux responsables de gérer et contrôler le fonctionnement de l’application. Dans le chapitre suivant, nous décrirons les différentes étapes de réalisation ainsi que les tests de validation.
  • 46. 33 Chapitre 4 Réalisation et tests de validation de notre solution Sommaire 1. Introduction..............................................................................................................................34 2. Préparation du Raspberry Pi ......................................................................................................34 3. Installation du driver QMI WWAN pour Quectel EC20 ................................................................37 4. Création de l’application avec Xively..........................................................................................38 5. Tests de validation ....................................................................................................................41
  • 47. 34 1. Introduction Ce chapitre constitue le dernier volet du rapport. Il a pour objectif d'exposer le travail achevé. Pour ce faire, nous allons décrire les différentes étapes de préparation du Gateway (Raspberry Pi) et les phases de création de l’application de gestion avec Xivey. 2. Préparation du Raspberry Pi 2.1 Installation du système d’exploitation Raspbian Le Raspberry Pi est initialement sans système d’exploitation. D’abord nous avons téléchargé Raspbian à partir du site officiel : raspberrypi.org/downloads. Puis nous l’avons installé sur la carte mémoire par le biais d’un logiciel d’écriture d’image : « Win32 Disk Imager ». Figure4.1 23 : Installation du Raspbian avec Win32 Disk Imager 2.2 Connexion à distance au Raspberry pi Pour pouvoir se connecter à distance à notre Raspberry, il faut le connecter à un réseau local et faire appel au protocole SSH. Le serveur SSH est activé par défaut sur le Raspberry Pi. Sous Linux, le client étant intégré dans la plupart des distributions.
  • 48. 35 Par contre, sous Windows nous devons installer « Putty » qui est un client SSH et Telnet. Ensuite, il suffit d’entrer l’adresse IP du Raspberry dans Putty pour pouvoir se connecter. Afin d’accéder à l’interface graphique, nous avons utilisé le système de visualisation VNC. Le serveur VNC est installé sur le Raspberry en lançant la commande suivante :  sudo apt-get install tightvncserver. Ensuite, nous avons créé un fichier de démarrage automatique. Le client VNC que nous avons utilisé est VNC Viewer dont le principe de connexion est similaire à celui du SSH. Figure4.2 24 : Capture d'écran del 'interface graphique du Raspberry sur VNC Viewer. Un serveur DHCP distribue une adresse IP aux clients selon la disponibilité des adresses de la plage définie. Cependant, il est possible de faire en sorte qu’un hôte ait toujours la même adresse IP attribué c’est ce que l’on appelle de la réservation d’adresse. On doit donc indiquer dans le serveur DHCP que telle adresse IP (x.y.z.w) est réservée à l’adresse MAC du notre Raspberry. Figure4.3 25 : Réservation de l'adresse 192.168.0.100 au Raspberry
  • 49. 36 2.3 Cross-compilation du module Linux Il existe deux méthodes principales pour la construction du noyau Linux pour Raspberry Pi. Nous pouvons le construire localement sur notre Raspberry Pi qui prendra une longue période. Nous pouvons aussi précéder à compilation croisée, qui est beaucoup plus rapide, mais nécessite plus de configuration. 2.3.1 Compilation Locale sur Raspberry Pi Après avoir installé la dernière version de Raspbian, nous devons connecter notre Raspberry pi à internet pour lui donner un accès aux fichiers source.  Les fichiers sources de linux sont hébergés à Github. Pour les obtenir, il suffit de lancer la commande suivante :  Configuration du noyau par défaut :  Compilation et installation du noyau, cette étape prend beaucoup de temps. 2.3.2 Compilation croisée avec Toolchain D’abord nous avons besoin d’une machine hôte avec un système d’exploitation approprié : la distribution la plus recommandé est Ubuntu. Les étapes que nous avons suivies sont les suivantes :  Installation de Toolchain  Obtention des fichiers source  Installation sur la carte SD du Raspberry Pi : GIT CLONE --DEPTH=1 HTTPS://GITHUB.COM/RASPBERRYPI/LINUX CD LINUX KERNEL=KERNEL MAKE BCMRPI_DEFCONFIG GIT CLONE HTTPS://GITHUB.COM/RASPBERRYPI/TOOLS GIT CLONE --DEPTH=1 HTTPS://GITHUB.COM/RASPBERRYPI/LINUX CD LINUX KERNEL=KERNEL MAKE ARCH=ARM CROSS_COMPILE=ARM-LINUX-GNUEABIHF- BCMRPI_DEFCONFIG MAKE ARCH=ARM CROSS_COMPILE=ARM-LINUX-GNUEABIHF- ZIMAGE MODULES DTBS
  • 50. 37 3. Installation du driver QMI WWAN pour Quectel EC20 Pour installer le pilote QMI WWAN il faut :  Modifier le code source du pilote : nous devons ajouter l’identifiant du fournisseur (VID) Quectel ainsi que l’identifiant de son produit EC20 (PID) dans le fichier [KERNEL]/drivers/net/usb/qmi_wwan.c  Modifier la configuration du noyau : dans le menu USB Network Adaptaters, nous devons activer la fonctionnalité « QMI WWAN driver for Qualcomm MSM based 3G and LTE modems » Figure4.4 26 : Le menu USB Network Adaptaters de Raspbian  Configuration de l’APN (Access Point Name) : le modem doit utiliser un nom de point d’accès spécifique fournit par l’opérateur. Dans notre cas, l’APN que nous avons utilisé est « ooredoo.internet.tn ». Lorsque le Raspberry Pi est attaché au pilote QMI WWAN, il va créer un canal réseau et un canal QMI. Le canal réseau nommé wwanX est utilisé pour la transmission des données, par contre le canal QMI est responsable de l’interaction entre le Raspberry Pi et le modem via des messages QMI. Nous pouvons s’assurer que le pilote fonctionne correctement en vérifiant l’existence de l’interface réseau wwan sur le Raspberry avec la commande « ifconfig ».
  • 51. 38 Figure4.5 27 : les interfaces réseau de notre Raspberry 4. Création de l’application avec Xively 4.1 La phase de Développement : 4.1.1 Prototypage Dans la phase de développement l'objectif est d'obtenir un prototype de notre produit final qui répond à nos besoins. Pour valider notre travail, nous allons travailler sur les paramètres suivants :  Les canaux : Vitesse, température du moteur, le niveau de carburant et l’état des airbags,  La localisation,  Les métadonnées : le propriétaire de la voiture et son adresse e-mail,  Le déclencheur : Informer par e-mail l’utilisateur lorsque la voiture fait un accident.
  • 52. 39 Figure4.6 28 : Xively Developer Workbench 4.1.2 Création de déclencheur avec Zapier La création de déclencheur avec Zapier se fait en deux étapes : 1. Définir la condition de déclenchement de service : lorsque le statut des airbags change la plateforme Xively déclenche le service. 2. Créer le service : envoyer un e-mail à l’utilisateur. Figure4.7 29 : Création de déclencheur avec Xively et Zapier
  • 53. 40 4.2 La phase de Déploiement Après avoir créé notre prototype, nous allons passer au déploiement. Il suffit de cliquer sur le bouton « Deploy ». Figure4.8 30 : Capture d'écran de la phase de déploiement Maintenant, c’est le temps d’insérer les numéros de série des appareils. Cette opération est effectuée soit en téléchargeant un fichier CSV qui contient un numéro de série par ligne ou en entrant les numéros de série manuellement. À chaque appareil ajouté, Xively crée une instance du prototype. Figure4.9 31 : Insertion des numéros de série des périphériques
  • 54. 41 5. Tests de validation 5.1 Activation de l’appareil Initialement le Raspberry est désactivé. Après son premier démarrage, le Raspberry envoie son code d’activation à la plateforme Xively. Si le code est correct, Xively renvoie le Feed ID et l’API key au Raspberry. Figure4.10 32 : Activation du périphérique Après l’activation, Xively change le statut de notre appareil et indique l’heur de l’activation : 5.2 Envoi des données à la plateforme Xively Grace aux Feed ID et API key, notre Raspberry est capable d’envoyer ses données périodiquement à la plateforme Xively. Figure4.11 33 : Envoi des données à la plateforme Xively À partir du Tableau de bord de contrôle offert par Xively, nous pouvons vérifier que les données sont bien reçues.
  • 55. 42 5.3 Envoi des données de localisation Pour lire les données de localisation, le Raspberry Pi doit envoyer un message QMI au modem EC20 LTE. Ce dernier renvoie une trame « QGPSLOC » qui contient la longitude et la latitude de la position. Figure4.13 35 : Lecture des données de localisation Par la suite le Raspberry envoie ses données de localisation à la plateforme Xively. Figure4.12 34 : Visualisation des données
  • 56. 43 Figure4.14 36 : Envoi des données de localisation à la plateforme Xively Dans le tableau de bord, nous pouvons vérifier que les données de localisation sont bien reçues. Figure4.15 37 : La localisation du périphérique avec Xively 5.4 Test des déclencheurs Dès que le statut des airbags passe à 1 (activé), Xively envoie automatiquement un e-mail à l’utilisateur pour lui informer. Figure4.16 38 : Résultat du déclencheur 6. Conclusion Ce chapitre a été consacré à la présentation des différentes tâches réalisées dans ce projet pour accomplir notre mission, nous avons commencé par la préparation du Raspberry Pi et l’installation du driver QMI. Ensuite, nous avons détaillé les étapes de création de la partie BackOffice. Nous clôturons notre rapport par une conclusion générale et les différentes perspectives recensées.
  • 58. 45 Bibliographie [1] Union internationale des télécommunications, « s.d. ». Internet des objets – Normes mondiales. En ligne http://www.itu.int/en/ITU-T/gsi/iot/ [2 ]R. Van Der Meulen, The impact of IoT on Business. Gartner, 2015. En ligne http://www.gartner.com/newsroom/id/3165317 consulté le 03/05/2016. [3] Telnet Holding, 2009. Qui sommes-nous. En ligne http://www.groupe-telnet.net/ [4] Bien choisir sa plate-forme, 2015. En ligne http://www.usine-digitale.fr/article/bien-choisir-sa-plate- forme-pour-faire-communiquer-ses-objets-connectes.N342721 consulté le 25/02/2016. [5] Xively by LogMeIn, « s.d. ». What is Xively. En ligne https://xively.com/whats_xively/ [6] Raspberry Foundation, 2016. Documentation. En ligne https://www.raspberrypi.org/resources/ [7]J. philippe Vasseur & A, Dunkels, Interconnecting Smart Objects with IP. Rick Adams, 2010. (Cité page 102) [8] Raspberry Foundation, 2016. Téléchargements. En ligne https://www.raspberrypi.org/downloads/ [9] Y. Carl, WCDMA&LTE Linux USB Driver User Guide. Quectel Wireless Solutions Co., Ltd, 2015. (Cité page 22) [10] T. Zhang, EC20 GNSS AT Commands Manual. Quectel Wireless Solutions Co., Ltd, 2015. (Cité page 16) [11] D. Norris, The Internet of Things : Do-It-Yourself Projetcs with Arduini, Raspberry and BeagleBone. McGraw-Hill Education, 2015. (Cité page 89) [12] Xively by LogMeIn, « s.d. ». Tutoriels. En ligne https://personal.xively.com/dev/tutorials/ [13] Xively by LogMeIn, « s.d. ». Documentations de l’API REST. En ligne https://personal.xively.com/dev/docs/api/ [14] D. Norris, The Internet of Things : Do-It-Yourself Projetcs with Arduini, Raspberry and BeagleBone. McGraw-Hill Education, 2015. (Cité page 36)