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

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.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 applicat ions

et les systèmes hétérogènes dans le but d e 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 format normalisé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.

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)

http://www.itu.int/en/ITU-T/gsi/iot/

http://www.gartner.com/newsroom/id/3165317

http://www.groupe-telnet.net/

http://www.usine-digitale.fr/article/bien-choisir-sa-plate-forme-pour-faire-communiquer-ses-objets-connectes.N342721

http://www.usine-digitale.fr/article/bien-choisir-sa-plate-forme-pour-faire-communiquer-ses-objets-connectes.N342721

https://xively.com/whats_xively/

https://www.raspberrypi.org/downloads/

https://personal.xively.com/dev/tutorials/

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

Engineering

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