telcar : solution de lecture des informations de bord de véhicule
TRANSCRIPT
Nombre d’objets connectés en fonction de la population mondiale
1/33
École Nationale d‘Ingénieurs de Tunis
Projet de fin d’études
Présenté le 02/06/2016
TelCarSolution 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
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
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
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
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
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
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
III- Solution et architecture globale proposées2- Architecture globale de la solution
Services Web
Données
Données
Le boitier « TelCar » 9/33
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
IV- Étude de la partie embarquée
Modem 4G GatewayMicrocontrôleur Connecteur OBD
11/33
12/33
1- La Gateway : Raspberry PiIV- É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
1- La Gateway : Raspberry PiIV- É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
1- La Gateway : Raspberry PiIV- É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
1- La Gateway : Raspberry PiIV- Étude de la partie embarquée
1.3 Compilation croisée du module Linux pour Raspberry Pi
15/33
16
IV- Étude de la partie embarquée
Modem 4G La GatewayMicrocontrôleur Connecteur OBD
16/33
2- Le modem 4GIV- É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
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
2- Le module Quectel EC20 LTEIV- É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
Connecté
Déconnecté
19/33
21
IV- Étude de la partie embarquée
Modem 4G La GatewayMicrocontrôleur Connecteur OBD
20/33
3- Communication Raspberry-MicrocontrôleurIV- Étude de la partie embarquée
3.1 liaison SPI Raspberry-Microcontrôleur
GPIOSCLKMOSIMISO
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
3- Communication Raspberry-MicrocontrôleurIV- É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
V- Étude de la partie BackOffice
Données
Données
Données
Données
Données
Données
Données
Données
23/33
V- Étude de la partie BackOffice1- 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
V- Étude de la partie BackOffice2- 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éploiement3. La phase de Gestion
25/33
V- Étude de la partie BackOffice2- 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
27/33
V- Étude de la partie BackOffice2- 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
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
V- Étude de la partie BackOffice2- 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
VI- Démonstration
31/33
33
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
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
Merci pour votre attention