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

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


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.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.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.3 Compilation croisée du module Linux pour Raspberry Pi

15/33

16


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


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


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


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


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

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

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