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

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

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.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
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
PUT Entêtes HTTP
seulement
Datastreams Supprimer Json,
xml,
csv
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
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/
PUT Entêtes HTTP
seulement
Devices Supprimer n/a https://api.xively.com/v2/products/
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
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.

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)

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

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

En vedette

En vedette (20)

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

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

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