Présentation de projet de fin d'étude

1. Nombre d’objets connectés en fonction de la population mondiale
1/33

2. École Nationale d‘Ingénieurs de Tunis
Projet de fin d’études
Présenté le 02/06/2016
TelCar
Solution de lecture des informations de bord de véhicules
Encadré par : M. Mourad ZERIBI (Telnet Innovation Labs)
M. Tahar EZZEDINE (ENIT)
Présenté par : Ghassene CHAIEB

3. Introduction
Cadre du projet
Solution et architecture globale
Étude de la partie embarquée
Étude de la partie BackOffice
Démonstration
Conclusion
I
III
II
VI
V
IV
VII
Plan
3/33

4. I- Introduction
L'Internet des objets est un réseau d'objets physiques contenant des technologies
intégrées et permettant de communiquer et de détecter, ou d'interagir avec leurs états
internes ou l'environnement externe. « Gartner »
L’Internet des objets 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. « Union internationale des télécommunications »
4/33

5. II- Cadre du projet
1- Enterprise d'accueil
 Telnet est groupe de sociétés tunisien,
 Crée en 1994,
 Conseil, innovation et hautes technologies.
5/33

6. II- Cadre du projet
2- Problématique
Surveiller et être alerté
à tout moment lorsque
votre voiture est en
mouvement.
prévenir les services d’urgence
en cas de panne, de malaise ou
d’accident en communiquant
votre position géographique.
suivre l’état de votre
véhicule :
• dépenses,
• entretiens,
• diagnostic,
• etc.
6/33

7. II- Cadre du projet
2- Problématique
• Est-il possible de profiter des mêmes services avec des véhicules
entrée de gamme ?
• Est-il possible de placer nos véhicules au cœur de l’internet
des objets?
7/33

8. III- Solution et architecture globale
1- Solution proposée :
• Le boîtier TelCar permet de bénéficier de ces données en temps réel sur son
smartphone.
• Notre solution baptisé « TelCar » (Telnet-Car) est un dispositif embarqué à
brancher sur la prise OBD (On Board Diagnostic) d’un véhicule.
• Cette solution permet d’exploiter des données uniquement accessibles aux
professionnels de la réparation et de l’entretien automobile.
8/33

9. III- Solution et architecture globale proposées
2- Architecture globale de la solution
Services Web
Le boitier
« TelCar » 9/33

10. IV- Étude de la partie embarquée
La partie embarquée est composée de :
• Une partie permettant de lire et de traiter les données provenant
du réseau CAN (Controller Area Network ) du véhicule,
• Une partie communicante capable d’envoyer les données traitées
au serveur de l’application.
10/33

11. 11
IV- Étude de la partie embarquée
Modem 4GGatewayMicrocontrôleurConnecteur OBD
11/33

12. 12/33
1- La Gateway : Raspberry Pi
IV- Étude de la partie embarquée
1.1 Caractéristiques :
 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

13. 1- La Gateway : Raspberry Pi
IV- Étude de la partie embarquée
1.2 Le Système d’exploitation Raspbian :
• C’est un système d'exploitation libre basé sur Debian
(Linux) optimisé pour le matériel Raspberry Pi.
• Raspbian fournit plus qu'un simple système
d’exploitation : il est livré avec plus de 35.000
paquets des logiciels précompilés qui nous facilitent
le développement.
13/33

14. 1- La Gateway : Raspberry Pi
IV- Étude de la partie embarquée
1.3 Compilation croisée du module Linux pour Raspberry Pi
Les ressource matérielles du Raspberry Pi sont limitées ( CPU, mémoire RAM, etc)
ce qui rend nécessaire la compilation croisée du module linux.
La compilation croisée se traduit par la possibilité d’ajouter ou de supprimer des
modules logiciels pour étendre ou limiter les fonctionnalités du noyau.
14/33

15. 1- La Gateway : Raspberry Pi
IV- Étude de la partie embarquée
1.3 Compilation croisée du module Linux pour Raspberry Pi
15/33

16. 16
IV- Étude de la partie embarquée
Modem 4GLa GatewayMicrocontrôleurConnecteur OBD
16/33

17. 2- Le modem 4G
IV- Étude de la partie embarquée
Type : Quectel 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.
Il est équipé d’un récepteur GNSS permettant de
localiser le module rapidement et en temps réel
le module.
17/33

18. Le pilote QMI (Qualcomm Mobile Station Modems Interface) :
C’est un protocole binaire conçu pour remplacer la communication avec les modems
basés sur les commandes AT. Il est compatible avec les chipsets Qualcomm.
IV- Étude de la partie embarquée
2- Le module 4G
18/33

19. 2- Le module Quectel EC20 LTE
IV- Étude de la partie embarquée
ModemUp
Présent
Absent
Activé
Aésactivé
C’est un script Shell qui contrôle
de fonctionnement de notre
modem.
19/33

20. Connecté
Déconnecté
19/33

21. 21
IV- Étude de la partie embarquée
Modem 4GLa GatewayMicrocontrôleurConnecteur OBD
20/33

22. 3- Communication Raspberry-Microcontrôleur
IV- Étude de la partie embarquée
3.1 liaison SPI Raspberry-Microcontrôleur
GPIO
SCLK
MOSI
MISO
le scénario de communication :
1. Le Raspberry génère l’horloge et envoie la requête de
demande au microcontrôleur,
2. Le microcontrôleur fournit les informations demandées,
3. Pour envoyer des données critiques, le microcontrôleur
envoie un bit 1 au Raspberry par le biais de la liaison
GPIO,
4. Le Raspberry crée une interruption et envoie une
demande de lecture des informations critiques,
5. Le microcontrôleur founit les informations critiques au
Raspberry. Master Slave
21/33

23. 3- Communication Raspberry-Microcontrôleur
IV- Étude de la partie embarquée
3.2 Protocole de communication Raspberry-Microcontrôleur
Format de la trame envoyée par le Raspberry
Format de la trame envoyée par le microcontrôleur
22/33

24. V- Étude de la partie BackOffice
23/33

25. V- Étude de la partie BackOffice
1- Les Services web
• 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é.
• Les services web utilisent le protocole HTTP(S) (Hypertext Transfer Protocol) pour transférer
des données sous format normalisé (XML, JSON, CSV).
Service web REST (REpresentational State Transfer) :
• Léger : utilise le format de donnée JSON.
• Indépendance vis à vis du langage de programmation et de la plateforme sur laquelle ils
sont déployés.
• Simplicité d'implémentation.
24/33

26. V- Étude de la partie BackOffice
2- La plate-forme Cloud IoT Xively
Xively est une « Platform as a Service » (PaaS) pour l'internet des objets.
Elle simplifie l'interconnexion des équipements, des données,
des personnes et des lieux.
Le processus de création de solution sous Xively se compose de trois
étapes :
1. La phase de développement
2. La phase de Déploiement
3. La phase de Gestion
25/33

27. V- Étude de la partie BackOffice
2- La plate-forme Cloud IoT Xively
2.1 La phase de développement
L'objectif est d'obtenir un prototype de notre produit final qui répond à nos besoins.
Trois attributs doivent être configurés :
• Les canaux (Channels) : permettent l'échange bidirectionnel de points de données entre
la plateforme Xively et les périphériques.
• La localisation : permet l’identification de la position des nœuds avec Google Maps.
• Les déclencheurs : permettent de déclencher une action lorsque une condition est satisfaite.
26/33

28. 27/33

29. V- Étude de la partie BackOffice
2- La plate-forme Cloud IoT Xively
2.2 La phase de La phase de Déploiement
• Lors du déploiement, nous créons un lot de produits virtuels dans Xively qui correspond à un lot
de produits physiques fabriqués.
• Tous les nœuds doivent être pré-enregistrés en indiquant leurs numéros de série à Xively.
• Le pré-enregistrement permet à Xively de reconnaître les appareils lors du processus
de provisionnement.
28/33

30. Le processus de provisionnement (activation)
• Liste de Numéro de série
• Product Secret
Désactivé
Demande d’activation
Demande d’activation : Fonction de hachage (numéro de série, Product Secret )
Feed ID, API Key
Activé
Données
FeedID : Identifiant
API Key : Mot de passe
29/33

31. V- Étude de la partie BackOffice
2- La plate-forme Cloud IoT Xively
2.3 La phase de Gestion
Xively nous donne la possibilité de gérer les nœuds :
• 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 les requêtes en temps réel.
30/33

32. VI- Démonstration
31/33

33. 33

34. VII- Conclusion
• Nous avons réussi à :
 Développer un protocole de communication entre le Raspberry et le
microcontrôleur,
 Collecter les données par le Raspberry et les envoyer à la plateforme Cloud
Xively,
 Gérer l’ensemble des nœuds et stocker les données qui en proviennent.
• Ces composantes jouent un rôle crucial dans l’acheminement des données de bout
en bout : du véhicule à l’application mobile.
• Nous envisageons de compléter les parties restantes de ce projet.
32/33

35. Perspectives :
• Améliorer la communication entre les nœuds et Xively.
• Intégrer un système d’analyse de données (Big Data) dans la plateforme Xively.
33/33

36. 36
Merci pour votre attention