Table des matières

Introduction générale : ............................................................................................................... 4

Chapitre I : cadre générale du projet : ........................................................................................ 5

I. Introduction : ....................................................................................................................... 5

II. Présentation de l’entreprise d’accueil : ............................................................................... 5

1. Présentation générale : .................................................................................................... 5

2. Produits et services : ........................................................................................................ 6

III. Présentation de projet : ........................................................................................................ 7

1. Contexte du projet : ......................................................................................................... 7

2. Problématique : ............................................................................................................... 7

3. Objectif du projet : .......................................................................................................... 7

4. Etude de l’existant : ......................................................................................................... 7

Conclusion :................................................................................................................................ 9

Chapitre II : Modélisation du fonctionnement du système : .................................................... 10

I. Introduction : ..................................................................................................................... 10

II. Le schéma fonctionnel : .................................................................................................... 10

III. Description des fonctionnalités du système ...................................................................... 11

IV. Outils de développements hardware : ............................................................................... 12

1. Choix du microcontrôleur : ........................................................................................... 12

2. Le prise diagnostic embarqué OBD : ............................................................................ 13

3. ELM327 : ...................................................................................................................... 16

V. Outils de développement software : .................................................................................. 19

1. IDE Arduino : ................................................................................................................ 19

2. Plateforme IOT : ThingSpeak : ..................................................................................... 20

VI. Définitions des protocoles de communication utilisée ..................................................... 21

1. UART : .......................................................................................................................... 21

2. CAN : ............................................................................................................................ 21

1
Conclusion :.............................................................................................................................. 23

Chapitre III : Réalisation du système ....................................................................................... 24

I. Introduction : ..................................................................................................................... 24

II. ENVIRONNEMENT DE REALISATION : .................................................................... 24

1. Environnement matériel ................................................................................................ 24

2. Environnement logiciel ................................................................................................. 24

a. Arduino IDE : ............................................................................................................ 24

b. CarDaig et MotorData OBD : ................................................................................ 25

c. Bluetooth Mac Address Finder : ................................................................................ 26

d. Microsoft Word 2016 :........................................................................................... 26

III. TRAVAIL PRATIQUE : .................................................................................................. 26

1. Plan du travail : ............................................................................................................. 26

2. Mise en pratique ............................................................................................................ 27

2.1. Communication sans fil. (Utilisation de l’ESP32) : .................................................. 27

a. Connexion à un port OBD de véhicule ...................................................................... 27

b. Commandes OBD .................................................................................................. 28

c. Connecter à une carte ESP32 : .................................................................................. 31

d. Cloud nos données ................................................................................................. 32

2.2. Communication câblé. (Utilisation de l’Arduino Uno) : ........................................... 35

Conclusion :.............................................................................................................................. 37

Conclusion générale ................................................................................................................. 38

Bibliographie ............................................................................................................................ 39

2
 Liste des figures

Figure 1: Logo de SFM ........................................................................................................................... 5

Figure 2: Architecture proposée. ............................................................................................................. 9
Figure 3: Schéma fonctionne du projet. ................................................................................................ 10
Figure 4: La carte ESP32....................................................................................................................... 12
Figure 5: Connexion directe à travers le connecteur OBD. ................................................................... 13
Figure 6: Le connecteur OBD2 ............................................................................................................. 14
Figure 7: (a) communication cablé, (b) et (c) communication sans fil. ................................................. 16
Figure 8: ELM327 ................................................................................................................................. 16
Figure 9: schéma fonctionnel pour la carte ELM327 ............................................................................ 17
Figure 10: Forme de trame reçue et envoyer par le circuit ELM327. ................................................... 17
Figure 11 : IDE Arduino ....................................................................................................................... 20
Figure 12: Arduino IDE. ....................................................................................................................... 25
Figure 13: Valeur de l'adresse Mac ....................................................................................................... 27
Figure 14: Marque de voiture selon le code VIN déterminer ................................................................ 30
Figure 15: Les réponses pour les commandes OBD envoyées. ............................................................. 32
Figure 16: Régime de moteur RPM en tr/min et la vitesse en Km/h afficher par le serveur................. 33
Figure 17: Température de moteur °C et la distance parcourue avec erreur en Km/h afficher par le
serveur ................................................................................................................................................... 34
Figure 18: distance parcourue sans erreur en Km et la distance restant jusqu'au prochain vidange en
Km afficher par le serveur ..................................................................................................................... 34
Figure 19: le protocole de communication adopté pour le modèle de voiture utilisé............................ 35
Figure 20: CAN BUS SHIELD ............................................................................................................. 35

Liste des Tableaux

3
 Introduction générale :

Les méthodes de collecte de données pour les véhicules sont basées sur les nouvelles
technologies ont évolué au cours des dernières décennies.

Pour les entreprises, ces données sont essentielles pour le suivi en temps réel de la
gestion de flotte. L'état du véhicule, la répartition de la charge de travail, l'efficacité de
l'essence et même l'emplacement du véhicule peuvent tous être renvoyés à un système de
contrôle central via le Cloud. Les entreprises peuvent utiliser l'apprentissage automatique pour
intégrer les données dans un modèle de formation afin de prédire le coût et même d'analyser
les caractéristiques du conducteur.

Dans ce contexte nous avons réalisé un prototype pour les collectes des données via le
fiche OBD de voiture tout en assurant la meilleure méthode pour accédées à ces données.

L’étude de ce projet se divise en trois chapitres,

Dans le premier chapitre on introduit la cadre générale du projet. Il vise à décider les
concepts clés et introduire la problématique posée,

Puis le deuxième chapitre est consacré à la modélisation du fonctionnement du

système,

Pour le dernier chapitre est réservé à la partie réalisation ainsi que les résultats
obtenus.

Enfin, nous clôturons le rapport par une conclusion générale.

4
 Chapitre I : cadre générale du projet :

I. Introduction :
Dans ce chapitre nous exposons le contexte général du projet, nous présenterons tout
d’abord l’environnement ou nous avons effectué le travail, on détaillera par la suite le thème
général du projet et on décrit la problématique.

II. Présentation de l’entreprise d’accueil :

Dans cette partie, nous allons nous intéresser à la présentation de l’entreprise d’accueil
et aux différents produits et services qu’elle fournit.

1. Présentation générale :
Le groupe SFM, membre de I’ITU-D (SFM TECHNOLOGIES, SFM
INTERNATIONAL, SFM TELECOM et SFM CAMEROUN), est un cabinet d’ingénierie et
d’expertise en réseaux de télécommunications et technologies de l’information. Opérant en
Afrique, Asie, Europe, Océanie et Etats Unis depuis 1995.

SFM propose des prestations et solutions techniques, organisationnelles et des

formations sur mesure à très forte valeur ajoutée et se positionne en tant que véritable
partenaire de ses Clients

Figure 1: Logo de SFM

Le groupe de SFM est composé par : SFM Télécom Société mère positionnée sur le
marché local, SFM technologies Société exportatrice pour renforcer les activités de SFM à
l’international, SFM International Société dédiée uniquement pour la formation, SFM

5
Cameroun Pour l’expertise et le consulting Pour l’Afrique Centrale (Zone CEMAC), SFM
Burkina Faso Pour l’expertise et le consulting Pour l’Afrique Centrale (Zone UEMOA) et
SFM Europe Pour le marché Européen.

Les outils et les développements sur-mesure offerts par SFM se déclinent selon 3
axes :

 Digitalisation des process des entreprises.

 Cybersécurité.
 Big Data et Intelligence Artificielle avec des solutions destinées aux secteurs des
télécommunications, bancaire et aussi ajout de couches de « Machine Learning » et «
Deep Learning » dans les produits SFM.

2. Produits et services :
SFM a développé des outils dans le cadre de son laboratoire SFM Lab dédié à la
recherche et au développement de nouvelles solutions dont l’objet est de répondre aux besoins
évolutifs de Clients.

Exemple de service de la société :

 QoS Tracker : Contrôle & Suivi de la QoS Des Réseaux Radio Mobile
 QoEntum : Suivi de la Qualité d’Expérience des utilisateurs, Supervision des
Performances des réseaux mobiles et Aide à la Décision
 Tariffs Tracker : Contrôle Automatique des Tarifs des Services de
Télécommunications
 Solution Anti Faude et Simbox : Détection de GSM call bridging pour les régulateurs
de télécom
 Solution Revenue Assurance : Système de Revenu Assurance et de Billing

6
 III. Présentation de projet :

1. Contexte du projet :
Ce travail s’inscrit d’un projet dans le cadre du stage d’été. Le projet est un prototype
dans le domaine de l’automobile. Au sein de la société SFM, nous avons participé avec une
équipe pour développer une solution a pour objectif d’acquérir les données pour les véhicules
tels que : VIN (Numéro d’identification de véhicule), KM (kilométrage), consommation du
carburant, niveau de fluides, code défauts, … tout en gardant un prototype robuste, et de
fonctionnalité réalistes.

Afin de faire sauvegarder ces données dans une unité de stockage locale (carte SD, …)
pour faciliter le diagnostic de voiture et de renvoyées aussi dans un système de contrôle
centrale via le Cloud pour une surveillance en temps réel.

2. Problématique :
Nous avons besoin d'une interface pour accéder au système du véhicule. Les questions
qui se posent sont :

Quelle l’interface qui nous permettons d’accéder au système du véhicule ?

Qu'est-ce la prise de diagnostic OBDII, les protocoles adoptés par cette fiche ainsi que
les données accessibles ?

3. Objectif du projet :
L’objectif de notre projet est d’acquérir les données en se basant sur la fiche de type
ELM327, et par la suite d’exploiter la partie de stockage locale et l’envoi des données vers le
serveur.

4. Etude de l’existant :
Dans le marché, il existe plusieurs appareils diagnostic auto, chacune à sa propre
caractéristique comme il est indiqué par le tableau sous-dessous :

7
 Tableau 1: Tableau comparatif de quelque appareil diagnostic auto

Type d’appareil Avantages Inconvénients

o Pas cher
o Encombrement minime
o Connexion facile o Pas d’écran
DS150E
o Adapté aux petits et grands
véhicules
o Interface multilingue
o Compatible avec tout type
de voiture
o Ecran de contrôle intégré o Coûte un peu cher
VI700
o Appareil polyvalent
o Fourni avec plusieurs
accessoires
o Compatible avec les
camions
o Ecran peu fluide
Multidiag Pro+ o Bluetooth intégré
o Jeu de diversement inclus
o Fourni avec un câble USB
… … …

Avec ces méthodes de diagnostic existent, l’entretien d’un tel engin demande
beaucoup de temps et de minutie. Avec la solution qui nous avons proposons on peut
examiner le véhicule et détecter une éventuelle panne, avant d’appeler un technicien, la
surveillance du système se réalise en temps réel, notre solution consiste à utiliser un boitier à
brancher sur le prise OBDII.

8
 Figure 2: Architecture proposée.

Conclusion :
Dans ce chapitre, nous avons présenté l’entreprise au sein de laquelle nous avons
effectué le projet de stage d’été, ensuite nous avons posé la problématique à travers le cadre
général du projet. De plus, dans la deuxième partie, sera dédié à l’étude de sûreté de
fonctionnement du système

9
 Chapitre II : Modélisation du fonctionnement du
système :

I. Introduction :
Dans ce chapitre on s’intéresse à l’étude de différentes parties du projet tel que
l’acquisition des données et l’envoi vers le serveur, ainsi on détaillera le rôle de chaque bloc
fonctionnel en accordant une importance particulière pour la méthode de communication sans
fil entre la carte ESP32 et l’ELM327 qui garantit la meilleure solution pour accéder aux
paramètres demandés.

II. Le schéma fonctionnel :

Le système de collecte des données des véhicules via Bluetooth est fonctionné selon le
schéma fonctionnel ci-dessous :

Figure 3: Schéma fonctionne du projet.

D’après ce schéma fonctionnel, on montre que ce travail va se faire en trois parties :

 La mise en connexion entre le microcontrôleur et le port OBD de voiture qui se réalise

via le module Bluetooth des deux cotées,

10
  Une fois que le microcontrôleur connecté au véhicule, on commence à communiqué
avec la carte OBD à travers des trames des données qu’envoyer pour acquérir les
données accessibles,
 Et enfin, l’envoi des données vers le serveur pour le stocker et l’analyser.

III. Description des fonctionnalités du système

Notre projet est de réaliser un prototype qui me permet d’extraire les données OBD
des véhicules via Bluetooth.

 Les données qu'on veut extraire sont :

 VIN ou Vehicle Idenitification Number (Numéro d’identification du véhicule)

 KM (kilométrage)
 Indicateur de maintenance et/ou indicateur de vidange (pour les véhicules récents)
 Périodicité restante si disponible (durée jusqu’à la prochaine maintenance)
 TPMS si disponible (Tyre Pressure Monitoring System)
 Consommation de carburant
 Niveaux des fluides si disponibles : huile moteur, huile BV, huile de direction, liquide
de frein, huile de climatisation, AdBlue, gaz réfrigérant
 Codes défauts
 Vibrations et/ou acoustique et/ou thermique si disponible : ces informations
permettent de connaître l’évolution du comportement du véhicule, et prédire les
problèmes

Parfois nous pouvons trouver des données qu’on ne peut l’accéder (qu’il est crypté ou manque
de capteur pour le mesurer).

 Mémoires :

Le système réaliser doit avoir une mémoire externe destiné au stockage temporaire des
données, cette dernière permet la récupération des données manquantes au serveur web dues
aux coupures de communication.

11
 Support de communication :

Le système doit communiquer les informations collectées sur le réseau internet vers le
serveur web. Les supports des communications qu’on va utiliser sont : réseau WIFI, réseau
mobile (réseau de donnée 3G, 4G, 5G)

 Microcontrôleur :

Le microcontrôleur doit assurer la mise en connexion avec la carte OBD et la collecte

d’informations, les traiter, les paramétrer avec la configuration initiale d’utilisateur et les
acheminer vers la carte mémoire ensuite vers le module de communication.

IV. Outils de développements hardware :

1. Choix du microcontrôleur :
Nous allons choisir comme une carte d’E/S est module de communication sans fil
ESP32 avec module SIM800L GSM GPRS

Figure 4: La carte ESP32

ESP32 est une série de microcontrôleurs de type système sur une puce (SoC)
d'Espressif Systems, basé sur l'architecture Xtensa LX6 de Tensilica, intégrant la gestion du
Wi-Fi et du Bluetooth.

12
 Caractéristiques requises :
o Chipset: ESPRESSIF-ESP32 240MHz Xtensa Microprocesseur LX6 32 bits à
simple/double cœur
o FLASH: QSPI flash 4 mo/PSRAM 8 mo
o SRAM: 520 ko SRAM
o Tension de fonctionnement: 2.7V-3.6V
o Courant de travail: Sur 70mA
o Courant de sommeil: Sur 1.1mA
o Carte SIM: Prend uniquement en charge la carte Nano SIM
o Alimentation: USB 5V/1A
o Courant de charge: 500mA

2. Le prise diagnostic embarqué OBD :

La grande majorité des voitures sorties depuis 1996 supportent la norme OBD-II. De
nos jours, OBD-II est une norme universelle ayant été adoptée par tous les moyens de
transport routier des États-Unis et d'Europe. OBD signifie On-Board Diagnostics (diagnostic
embarqué), un système standardisé permettant à des outils matériels et logiciels externes de
communiquer avec l'ordinateur de bord d'un véhicule. Dans son implémentation moderne,
OBD-II propose un port d'accès électronique standardisé permettant de transmettre des
données sur l'un de ses protocoles de communication standardisés.

Figure 5: Connexion directe à travers le connecteur OBD.

 Historique OBD2 :
 OBD : standardisation du connecteur pour qu’il soit identique dans tous les véhicules,
mais le protocole de communication est spécifique aux marques.

13
  OBD2 : arrivé en 1996 aux États-Unis pour spécifier des protocoles communs à toutes
les marques.
 EOBD : (European On Board Diagnostics) – adaptation de l’OBDII pour les véhicules
européens. La norme EOBD a été rendue obligatoire par la directive européenne
98/69/EC. Les dysfonctionnements qui mènent au dépassement des seuils d’émission
sont détectés et indiqués par le voyant moteur sur le tableau de bord du véhicule.

À partir de là, la norme OBD2 a été déployée étape par étape :

 1996 : OBD2 rendu obligatoire aux États-Unis pour les voitures/camions légers
 2001 : Obligatoire dans l'UE pour les voitures à essence
 2003 : Obligatoire dans l'UE également pour les voitures diesel (EOBD)
 2005 : OBD2 était requis aux États-Unis pour les véhicules de poids moyen
 2008: les voitures américaines doivent utiliser ISO 15765-4 (CAN) comme base
OBD2
 2010 : Enfin, OBD2 était requis dans les véhicules lourds américains
 Le connecteur OBD2 :

Le rôle de connecteur OBD2 est permet d'accéder facilement aux données de voiture.
Un ensemble de cinq protocoles sur lesquels il peut fonctionner. De plus, depuis 2008, le bus
CAN (ISO 15765) est le protocole obligatoire pour OBD2 dans toutes les voitures vendues
aux États-Unis, ce qui élimine essentiellement les 4 autres protocoles au fil du temps.

Figure 6: Le connecteur OBD2

14
ISO15765-4 (CAN-BUS)

Ce protocole est le plus moderne, il est obligatoire sur tous les véhicules vendus aux États-
Unis depuis 2008. Votre véhicule européen de 2003 ou plus peut avoir le CAN.

ISO14230-4 (KWP2000)

C’est un protocole très commun pour les véhicules de 2003 et plus utilisant l’ISO9141 K-Line.
Il existe deux variantes de l’ISO14230-4 : le slow init (1.2 à 10.4 kbps) et le fast init (10.4 kbps).

ISO9141-2 (KWP)

Ce protocole est surtout utilisé sur les véhicules européens. Il utilise les broches 7 et 15
(optionnellement) du connecteur.

SAE J1850 VPW

Ce protocole est principalement utilisé par les véhicules GM (General Motors).

SAE J1850 PWM

Ce protocole est principalement utilisé par les véhicules Ford, mais ce n’est pas le cas des Ford
vendues en Europe qui utilisent un protocole ISO.

Les deux normes utilisées pour les OBD sont l'ISO 15765-4:2005 et la SAE J1939-73.
Chacune des deux normes est utilisée sur chacun des marchés américains et européens.

Une future norme, ISO 27145, doit permettre d'accéder aux diagnostics du véhicules depuis
l'extérieur, par TCP/IP7.

Tableau 2 : Déterminer le protocole utilisé par un véhicule.

15
Interface :

(a) (b) (c)

Figure 7: (a) communication cablé, (b) et (c) communication sans fil.

3. ELM327 :
Presque toutes les nouvelles automobiles produites aujourd'hui sont tenues, par la loi,
de fournir une interface à partir de laquelle l'équipement de test peut obtenir des informations
de diagnostic. Le transfert de données sur ces interfaces obéit à plusieurs standards dont aucun
n'est directement compatible avec les PC ou les PDA. L'ELM327 est conçu pour servir de
pont entre ces ports de diagnostic embarqué (OBD) et le module Bluetooth.

Figure 8: ELM327

16
 Architecture :

Figure 9: schéma fonctionnel pour la carte ELM327

 Forme de trame :

La trame reçue et envoyer par le circuit ELM327 est composé d’un identifiant et de
données :

Figure 10: Forme de trame reçue et envoyer par le circuit ELM327.

1. Identifiant :

Pour les messages OBD2, l’identifiant est standard 11 bits est utilisé pour distinguer
entre <les messages de demandes> (ID 7DF) et <les messages de réponse> (ID 7E8 à 7EF)

7E8 : sera généralement l’endroit où le moteur principal ou l’ECU répond.

2. Largeur :

Ceci reflète simplement la largeur en nombre d’octets des données restantes (03 à 06).

Pour l’exemple de vitesse de véhicule, c’est 02 pour la requête (puisque seuls 01 et 0D

suivant)

17
 3. Mode :

Pour les demandes, ce sera entre 01 et 0A.

Pour les réponses, ce sera entre 41 et 4A.  Le 0 et remplacé par 4.

Quel que soit le protocole de communication utilisé (SAE J2012 ou ISO 15031-6), la norme
OBD définit 10 modes de diagnostic décrits ci-dessous.

Mode 1 : Retourne les valeurs courantes (régime moteur, vitesse, températures, pressions, ...)

Mode 2 : Retourne les données gelées de défauts.

Mode 3 : Retourne les codes défauts enregistrés. Ces codes défauts ont été standardisés pour
toutes les marques de véhicule et classés en 4 catégories :

 P0xxx : défauts standards liés au système de propulsion (moteur et transmission)

 C0xxx : défauts standards liés au châssis
 B0xxx : défauts standards liés à la carrosserie
 U0xxx : défauts standards liés aux réseaux de communications

Mode 4 : Ce mode permet d’effacer les codes défauts enregistrés et d’éteindre le voyant
moteur orange.

Mode 5 : Retourne les résultats des autodiagnostics effectués sur les sondes à
oxygène/lambda. (Principalement aux véhicules essence)

Mode 6 : Retourne les résultats des autodiagnostics effectués sur les systèmes non soumis à
surveillance constante.

18
Mode 7 : Ce mode retourne les codes défauts non confirmés. Les codes utilisés sont
identiques à ceux du mode 3.

Mode 8 : Retourne les résultats des autodiagnostics effectués sur d’autres systèmes (il est très
peu utilisé en Europe).

Mode 9 : Retourne les informations concernant le véhicule telles que:

 Le VIN numéro d’identification du véhicule

 Les valeurs de calibration

Mode 10 : Ce mode retourne les codes défauts permanents. Les codes utilisés sont identiques
à ceux du mode 3 et 7. Contrairement aux modes 3 et 7, ces codes ne peuvent pas être effacés
à l’aide du mode 4. Seuls plusieurs cycles de conduite sans apparition du problème effaceront
les défauts.

4. PID :

Pour chaque mode, une liste de PID standard existe par exemple 0D pour la vitesse de
véhicule.

5. Ah, Bh, Ch, Dh :

Ce sont des données en hexadécimale, qui doivent converties en décimal

Notez que le dernier octet de données après Dh n’est pas utilisé.

Il est important de noter que toutes les voitures ne prenant pas en charges tous les PID (en
particulières les voitures les plus anciennes).

V. Outils de développement software :

1. IDE Arduino :
La famille ESP32 est supportée par une gamme complète d’outils logiciels. Il englobe
les environnements de développement intégrés traditionnels – IDEs (Integrated Development
Environment) avec compilateurs C/C++ et débogueurs de tierces parties majeures permettant
de configurer et d'initialiser le MCU ou de surveiller son comportement en temps réel.

19
 Les cartes ESP32 supportent plusieurs environnements de développement dont les plus
répondus sont :

 Arduino IDE avec le module ESP32 Arduino Core4,

 Espruino,
 FAUST, langage de programmation de traitement de données audio, utilisant son
DSP5,
 Lua RTOS pour ESP32,
 MicroPython, une variante pour l'embarqué du langage Python,
 mruby, une variante pour l'embarqué du langage Ruby,
 NodeMCU,
 MicroEJ6,

Dans notre sujet, nous avons utilisé l’IDE Arduino pour programmer la carte ESP32.

Figure 11 : IDE Arduino

2. Plateforme IOT : ThingSpeak :

ThingSpeak permet aux capteurs et aux sites Web d'envoyer des données vers le cloud
où elles sont stockées sur un canal privé ou public. ThingSpeak stocke les données dans des
canaux privés par défaut, mais les canaux publics peuvent être utilisés pour partager des
données avec d'autres. Une fois que les données figurent dans un canal ThingSpeak, on peut
les analyser et les visualiser, calculer de nouvelles données ou interagir avec les médias
sociaux, les services Web et d'autres appareils.

20
 L’analyse de ces données est garantie par MATLAB; qui est le logiciel référence de
calcul numérique, et qui nous aidera alors à comprendre visuellement les relations entre les
données à l'aide des fonctions de plot intégrées et à combiner les données de plusieurs canaux
pour créer une analyse plus sophistiquée (dans un cas où l’on se base sur plusieurs capteurs).

VI. Définitions des protocoles de communication utilisée

1. UART :
Le contrôleur UART (Universal Asynchronous Receiver / Transmitter) est l'élément
clé du sous-système de communication série d'un ordinateur. UART est également une
fonctionnalité intégrée commune dans la plupart des microcontrôleurs. L'UART prend des
octets de données et transmet les bits individuels de manière séquentielle. À la destination, un
second UART réassemble les bits en octets complets. La transmission en série d'informations
numériques (bits) par l'intermédiaire d'un seul fil ou d'un autre support est beaucoup plus
rentable que la transmission parallèle à travers plusieurs fils. La communication peut être «
full duplex » (envoyer et recevoir en même temps) ou « half duplex »

Le niveau logique de repos est le 1

Le protocole UART est utilisé pour la communication entre le module Bluetooth

(esp32) et le carte ELM327.

2. CAN :
Est un protocole de communication série qui supporte des systèmes temps réel avec un
haut niveau de fiabilité

21
 Classer dans la catégorie des réseaux de terrain utilisé dans l’industrie pour remplacer
la boucle analogique 20 mA.

Le Protocol CAN 2.0 comporte deux spécifications qui différent uniquement au niveau de la
longueur d’identificateur :

 La version 2.0A définit les identificateurs de 11 bits.

 Et La version 2.0B des identificateurs de 29 bits.

Une trame de données se décompose en 7 champs différents :

 Le début de trame SOF (Start Of Frame).

 Le champ d’arbitrage, 12 bits
 Le champ de contrôle, 6 bits
 Le champ de données, 0 à 64 bits.
 Le champ de CRC (Cycle Redundancy Code), 16 bits
 Le champ d’acquittement (Acknoledge), 2 bits.
 Le champ de fin de Trame EOF (End Of Frame), 7 bits

 Une trame de requête (Remote Frame) est constituée de la même manière qu’une trame de
données sauf que le champ de données est vide.

22
ID : identification, 11 bits pour le standard format et 29 bits pour la forme entendue.

IDE : Identifier extension

 0 : Standard format
 1 : Extanded Format.

RTR : Remote Transmission Request (Dominant)

 0 : Data Frame
 1 : Remote Frame.

SRR : Substitue Remote Request (Recessive)

r0, r1 : deux bits réservées.

DLC : Data length code, définit le nombre de data bytes pour le data de requête et le data de
réponse.

CRC field : ce champ de CRC permet de s’assurer de la validité du message transmis, et tous
les récepteurs doivent s’éteindre à ce procédé de vérification, le dernier bit est délimiteur de
fin de champ de CRC (bits toujours récessif)

ACK field : le champ d’acquittement possède deux bits :

 Le premier bit correspondant à l’acquittement par l’ensemble des nœuds ayant reçu le
message.
 Si aucune erreur n’a été détectée par un nœud, ce dernier émet un bit dominant sinon il
émet une trame d’erreur.
 Le second bit est un bit délimiteur d’acquittement qui doit toujours être récessif.

Conclusion :
Dans ce chapitre, nous avons présenté l’analyse fonctionnelle de notre système pour finir par
le choix final des différents composants. Nous avons également décrit les différents
protocoles de communication utilisées

23
 Chapitre III : Réalisation du système

I. Introduction :
Ce chapitre constitue le dernier volet de ce rapport, il a pour objectif d’exposer le travail
achevé. Pour ce faire, nous commençons par la description de l’environnement de réalisation
de notre projet. Ensuite, nous exposons les différentes étapes de réalisation de notre dispositif.
Enfin, nous clôturons ce chapitre par quelques captures d’écran de notre produit.

II. ENVIRONNEMENT DE REALISATION :

1. Environnement matériel
 Ordinateur portable,
 Plaque à essaie,
 TTGO ESP32 avec SIM800L chip CH9012,
 Arduino UNO,
 ELM327,
 CAN-BUS shield v1.2,
 Câble Adaptateur Pour Auto Diagnostic Scanner OBD2 To OBD9

2. Environnement logiciel
 IDE Arduino
 Application: CarDaig, MotorData OBD et Bluetooth Mac Address Finder.
 Outil de rédaction : Microsoft Word 2016

a. Arduino IDE :
Le logiciel de programmation des modules Arduino est une application Java, libre et
multiplateforme, servant d’éditeur de code et de compilateur, et qui peut transférer le firmware
(micrologiciel ou microcode) et le programme à travers la liaison série (RS-232, Bluetooth ou USB
selon le module). Il est également possible de se passer de l’interface Arduino, et de compiler et loader
(télé verser) les programmes via l’interface en ligne de commande. Le langage de programmation
utilisé est le C++, compilé avec avr-g++, et lié à la bibliothèque de développement Arduino,
permettant l’utilisation de la carte et de ses entrées/sorties. La mise en place de ce langage standard

24
rend aisé le développement de programmes sur les plates-formes Arduino, à toute personne maîtrisant
le C ou le C++. À l’ouverture, l’interface visuelle du logiciel s’affiche :

Figure 12: Arduino IDE.

Des boutons de commande en haut, une page blanche vierge (zone d’écriture du programme)
et une bande noire en bas (zone des messages d’erreur ou succès envoyés par le programme). Le
programme est lu par le microcontrôleur de haut en bas, une variable doit être déclarée avant d’être
utilisée par une fonction.

En fait, la structure minimale est constituée :

 En tête : déclaration des variables, des constantes.indication de l’utilisation de

bibliothèque etc....
 Un set up « void set up ( ) » : cette partie n’est lue qu’une seule fois.Elle comprend les
fonctions devant être réalisées au démarrage.
 Un loop « void loop ( ) » : cette partie est lue en boucle.

b. CarDaig et MotorData OBD :

25
 Application facile à utiliser, permet aux automatistes de diagnostiquer les véhicules
(pannes, usure des composants, pollution et score de conduite) en toute autonomie et à
moindre cout.

c. Bluetooth Mac Address Finder :

Mac Adress Finder est utilisé pour trouver les adresses mac de tous les types de
périphériques Bluetooth. Il peut également trouver une adresse mac de tout appareil.

d. Microsoft Word 2016 :

Microsoft Word est un logiciel de traitement de texte publié par Microsoft. La version
la plus récente est Word 2019. Word a été intégré en tant qu’élément de la suite Microsoft
office depuis 1993, même s’il était également vendu seul.

III. TRAVAIL PRATIQUE :

1. Plan du travail :
Maintenant nous allons ordonner les expériences et les observations qu’on à réaliser,
au sein de la société SFM, pour la réalisation de notre prototype. Dans un premier temps, pour
connecter au fiche OBD nous nous déterminons l’adresse MAC de couches physique pour
l’ELM327 pour réaliser une connexion correcte entre le microcontrôleur et le port OBD. Puis
nous exposons les tests réalisés tel que l’envoi des commandes AT, collecte des données, …
Enfin, on termine par l’envoi des données vers le serveur pour le stocker et l’analyser.

26
 2. Mise en pratique

2.1. Communication sans fil. (Utilisation de l’ESP32) :

a. Connexion à un port OBD de véhicule

De prime abord, il faut déterminer l’adresse MAC pour le module Bluetooth de
l’ELM327 pour ce faire nous avons utilisé l’application mobile Bluetooth Mac Adress Finder

La valeur de l’adresse Mac de notre ELM327 est présentée par la figure 13 suivant :

Figure 13: Valeur de l'adresse Mac

Après avoir obtenu la valeur de l'adresse Mac, nous l'utilisons au niveau du code pour
que le microcontrôleur ESP32 soit devenu automatiquement connecté à cette prise OBD.

Pour lire des paramètres OBD supplémentaires pour le véhicule, la carte OBD-II doit d'abord
être configurée sur le protocole OBD correct. Il existe plusieurs protocoles OBD différents, il

27
peut donc être déroutant de tenter de trouver le bon. Cependant, cette carte OBD-II peut
détecte automatiquement le protocole. Pour utiliser cette fonction de détection automatique, le
contact du véhicule doit être en position « On ». Cependant, le véhicule n'a pas
nécessairement besoin de rouler. Une fois le contact mis, envoyez la commande "ATSP0". La
carte répondra ensuite par « OK » une fois que le protocole approprié aura été détecté.

Une fois que vous avez détecté le bon protocole sur votre carte, nous pouvons commencer à
envoyer des commandes OBD à la carte.

b. Commandes OBD
Les commandes OBD sont constituées de codes hexadécimaux écrits en caractères
ASCII. Généralement, ces commandes contiennent 2 paires ou plus de nombres
hexadécimaux.

La première paire hexadécimale de la commande OBD représente le mode OBD qui

doit être utilisé. Le pair hexadécimal suivant représente l'ID de paramètre (PID) à lire à partir
du mode spécifié.

Dans la fenêtre suivante j’ai tapez quelque commande cette commande se traduit par
"mode, et quels PID sont pris en charge ?". Le moniteur affiche par la suite la réponse de la
commande.

Le PID le plus important est 00. Cela fonctionne sur tout véhicule prenant en charge
OBD et donne une liste des autres PID pris en charge par la voiture. Il existe une structure
générale que toutes les réponses OBD ont en commun. Le premier octet de réponse (dans ce
cas 0x41) répertorie le mode demandé dans la commande. Le deuxième octet est le paramètre

28
qui a été demandé, donc dans notre cas, 0x00. Tous les octets suivants sont les réponses à la
commande. Dans ce cas, les octets 0xBE, 0x3E, 0xB8 et 0x11 sont les PID pris en charge par
le véhicule.

Un autre paramètre couramment pris en charge est le 'VIN'. Exécutez la commande

"0902" et appuyez sur Entrée.

Code VIN reçue :

Pour Déterminer l’identifiant de véhicule qu’on à utiliser nous avons utilisé le site
internet suivant https://fr.vindecoder.pl/:

Le marque de voiture utiliser est présentée par les figures suivantes :

29
Figure 14: Marque de voiture selon le code VIN déterminer

30
 Parfois nous pouvons trouver des données qu’on ne peut l’accéder (qu’il est crypté ou
manque de capteur pour le mesurer) alors nous recevons en retour le message ‘No Data’, ce
indique que tous les voitures n’utiliseront pas tous les 10 modes et les PID.

Maintenant, on le fera connecter la carte OBD-II à une carte ESP32.

c. Connecter à une carte ESP32 :

En plus dont connecté directement à notre ordinateur avec la carte OBD-II, nous
pouvons également exécuter les données via une carte ESP32 et afficher les informations sur
le port série pour le préparer ces données à envoyer par la suite vers le serveur. Pour cette
section, nous aurons besoin d'une carte ESP32, et de câble USB pour le télé-versement de
code et l'affichage des données.

Dans cette partie, nous montrerons comment obtenir le régime moteur, la température
du liquide de refroidissement du moteur, la vitesse du véhicule, la distance parcourue et le
code d’identification VIN. Les commandes OBD pour ces quatre fonctions sont：

 010D // vitesse de la voiture

 010C // régime moteur
 0105 // température du liquide de refroidissement.
 0149 // DIST_TRAV_SINCE_CODES_CLEARED
 0133 // DIST_TRAV_WITH_ERROR
 0902 // Code VIN

Une fois les commandes envoyées, la carte ESP32 affiche sur le port série toute
réponse. Nous utilisons la bibliothèque ELMduino.h pour recevoir une réponse.

31
 Figure 15: Les réponses pour les commandes OBD envoyées.
Dans la programmation et le débogage, un moniteur série est utile mais lorsqu’il s’agit
d’une application réelle on ne peut pas besoin d’utilisé.

Après avoir extrait les données via les voitures ont commencé maintenant à envoyer
les données vers le serveur pour les stocker et le traiter.

d. Cloud nos données

L'avantage de l'ESP32 est son accessibilité à Internet. En ciblant les applications IOT,
l'ESP32 rendra le système plus intelligent et plus connectif

Dans les applications automobiles, le WIFI n’est peut-être pas la meilleure solution car
le signal WIFI est rare dans l’environnement extérieur, pour cela nous utilisons l’interface
GSM avec une carte SIM pour accéder vers le cloud qui ne pose aucun problème dans notre
application.

Il existe de nombreuses plates-formes cloud pour stocker, afficher et traiter les

données. Nous utilisons dans notre cas le serveur de thingspeak, dans laquelle nous avons
envoyé les données et l’afficher.

Le commande d’envoi de données est présenté ci-dessous :

32
 Sur le serveur ThingSpeak, nous devons créer un nouveau tableau de bord, et
l'intérieur de ce tableau de bord, créer des nouvelles sources de données (Fields). Cette source
de données et liez à notre objet que nous avons défini dans le code.

Ci-dessous, une capture d'écran de mon tableau de bord. Il indique la vitesse de la

voiture, régime moteur, température du liquide de refroidissement, DIST TRAV SINCE
CODES CLEARED et DIST TRAV WITH ERROR

Figure 16: Régime de moteur RPM en tr/min et la vitesse en Km/h afficher par le serveur

33
Figure 17: Température de moteur °C et la distance parcourue avec erreur en Km/h afficher
par le serveur

Figure 18: distance parcourue sans erreur en Km et la distance restant jusqu'au prochain
vidange en Km afficher par le serveur

34
 2.2. Communication câblé. (Utilisation de l’Arduino Uno) :
La voiture qu’on à utiliser (Dacia model 2016) est compatible avec le protocole ISO
15765 CAN :

Figure 19: le protocole de communication adopté pour le modèle de voiture utilisé

Pour cela la communication entre une carte Arduino et un véhicule est réalisé à travers
deux puces le MCP2551 et un contrôleur de protocole CAN. Les deux puces sont rassemblés
en un shield de type sparkfun

Figure 20: CAN BUS SHIELD

Pour tester la méthode de communication câblé, on écrit un programmer qui peut
collecter le régime de moteur RPM et d’afficher sur la moniteur série :

35
7E8 : sera généralement l’endroit où le moteur principal ou l’ECU répond.

0x41 est le mode demandé dans la commande suivie de 0x0C pour montrer que la
carte regarde la paramètre RPM. Le paramètre renvoyé de 0x0D 0x7E peut ensuite être
convertie en une valeur décimale de 863 tr/min

36
Conclusion :
Dans ce chapitre, nous avons dans un premier temps présenté le matériel et les logiciels
utilisés lors de la réalisation de la plate-forme. Ensuite, nous avons exposé en détail, les
différentes étapes du travail pratique, illustrées par des captures d’écrans.

37
 Conclusion générale
L’objectif de ce stage est de réalisé un prototype dans le but d’acquérir les données via
le fiche OBD de voiture.

Cette sujette est fort intéressant et difficile à perfectionner, mais nous ne regrettons pas
de l’avoir pris en tant qu’un projet de stage d’été. Ce projet, a été pour nous, en tant
qu’étudiants ingénieurs qui se préparent au PFE, une très bonne occasion pour consolider et
mettre en pratique nos connaissances théoriques. Ainsi, ça nous a appris comment gérer le
temps, travailler en groupe et sous plusieurs et diverses contraintes (matérielles, logicielles,
temporelles …).

En perspectives, plusieurs améliorations restent envisageables pour ce travail. Ces

améliorations touchent essentiellement la partie de stockage des données et l’analyse des
données.

38
Bibliographie
[1] https://github.com/JustDhia/OBD-II-DATA-LOGGER

[2] https://www.outilsobdfacile.fr/interface-diagnostic-elm-327.php

[3] https://www.eskuel.net/creation-dun-afficheur-obddata-logger-arduino--partie-1-1512

[4] https://www.elm327.fr/norme-obd/modes-obd/

[5] https://www.csselectronics.com/pages/obd2-explained-simple-intro

[6] ELM327 Fiches technique

[7] https://github.com/PowerBroker2/ELMduino

[8] http://jakubdziworski.github.io/obd/bluetooth/arduino/car/2020/07/13/arduino-obd-dpf-
monitor-insignia.html

[9] https://www.14core.com/wiring-the-mcp2515-shield-with-obd-on-arduino/

[10] https://learn.sparkfun.com/tutorials/obd-ii-uart-hookup-guide/all

[11] https://create.arduino.cc/projecthub/frankzhao/iot4car-1b07f1

[12] http://www.sbugra.com/2019/03/31/meraklisina-obd2-nedir-nasil-calisir-ornekli-anlatim/

[13] https://forum.arduino.cc/t/can-not-receive-can-data-from-arduino-uno-with-mcp2515-
module/387242

[14] https://www.redalyc.org/journal/4115/411556006003/html/

39