Mémoire de Projet de Fin d’Études

Pour l’Obtention du Titre

D’un Master Spécialisé
FILIERE
Systèmes Embarqués Pour Automobile

Stage effectué à société Happy Agency Casablanca

Rapport de stage PFE

Sujet : Etude d’implémentation de diagnostic à distance des
véhicules

Réalisé par : Encadré par :

 OUBALLA Rachid  M .BERBIA Hassan

 FATHI khaoula  M .SAGHIR Omar
Dédicace

Nous dédions ce travail

À nos chers parents, source inépuisable de soutien et d’affection

inconditionnels,

À tous nos Encadrants sans qui, sa réalisation n’aurait pu être possible,

A l’ensemble de personnel de la société HAPPY AGENCY

À tous les étudiants du département de génie mécanique et productique.

À nos amis Et à tous ceux qui y ont contribué à l’intégration de ce stage.

1
 Remerciements

A l’échéance de ma période de stage, on tient à exprimer notre gratitude

à tous ceux qui y ont contribué et qui ont bien voulu nous offrir leur aide pour la
réalisation de ce travail.

Ils trouveront ici l’expression de notre respectueuse gratitude en

particulier:

L’ensemble du corps administrative et professorale de l’Ecole nationale

Supérieure d’informatique et d’Analyse de Systèmes; auprès desquels nous
avons eu à obtenir une formation lors de nos années estudiantines.

Nous tenons à remercier tout le personnel de l’entreprise HAPPY

AGENCY pour leur gentillesse, leur coopération et leur encouragement
continu, surtout:

Mr. Omar SAGHIR: le gérant de l’entreprise.

2
 Résumé

De nos jours, une grande majorité de société se plaignent du coût de leur

voiture notamment concernant la maintenance, .la plus part des sociétés aurons
besoin d’un suivi de leurs véhicules que ça soit les voitures de location ou
commerciales.

On pense à faire une étude d’implémentation d’un diagnostic à distance

des véhicules afin de pouvoir suivre leurs état ,c’est-à-dire diagnostiquer et
détecter les pannes en temps réel, notre projet a pour le but d’assurer la
maintenance préventive des véhicules ainsi de minimiser le maximum possible
les pannes persistants.

3
 Abstract

Nowadays, a large majority of companies complain about the cost of their

cars, especially regarding maintenance. Most companies will need a follow-up
of their vehicles, be it rental cars or commercial cars.

We plan to study the implementation of a remote diagnosis of the vehicles

in order to be able to follow their state, that is to say to diagnose and detect the
breakdowns in real time, our project has for the purpose of ensuring the
preventive maintenance vehicles thus minimizing as much as possible persistent
breakdowns.

4
 Tables des matières
Dédicas ............................................................................................................... 2
Remircimenet...................................................................................................... 3
Résumé ............................................................................................................... 4
Liste des figures.................................................................................................. 8
Introduction générale ......................................................................................... 9
Chapitre 1: Présentation générale ................................................................ 10
Introduction .............................................................................................. 11
I. Présentation de l’entreprise ............................................................ 12
II. Présentation des systèmes embarqués ............................................ 13
1. Historique................................................................................... 14
2. Définition .................................................................................. 15
3. Contraintes ................................................................................. 16
4. Temps réel .................................................................................. 18
5. Quelque chifres .......................................................................... 19
Conclusion ................................................................................................ 20
Chapitre 2: Diagnostic embarqué automobile.............................................. 21
Introduction ................................................. Error! Bookmark not defined.
I. Historique de diagnostic automobile .............................................. 23
1. Les principaux points de contrôle dans une voiture .................. 23
II. OBD II ............................................................................................. 26
1. Types .......................................................................................... 26
2. La norme OBD II ....................................................................... 27
3. Connecteur de liaison de données ............................................. 28
4. Broches du connecteur de liaison de données ........................... 29
5. Codes d’anomalie .................................................................... 29
Conclusion ................................................................................................. 31
Chapitre 3 : Cahier des charges ................................................................... 32
Introduction ............................................................................................... 33
I. Problèmatique ................................................................................. 34
II. Etude du marché automobile au Maroc.......................................... 35
III. Contexte du projet ........................................................................... 38
1. Définition ................................................................................... 38
2. Objectif du projet ....................................................................... 38
3. Analyse foncionnelle du besoin .................................................. 38
4. Planning de travail .................................................................... 40
Conclution ................................................................................................ 42
5
Chapitre 4 : Conception et réalisation ......................................................... 43
Introduction ............................................................................................... 44
I. Conception ...................................................................................... 45
1. Choix de microcontrôlleur ........................................................ 45
2. Choix de l’OBD ......................................................................... 48
3. Les étapes de projet ................................................................... 50
II. Réalisation....................................................................................... 53
1. Architecture de solution proposée ............................................. 53
2. Vue globale de la solution ......................................................... 54
3. Le scénario du système .............................................................. 55
4. Outils matériels ......................................................................... 57
5. Outils Logiciels ......................................................................... 58
6. Couche matériel ........................................................................ 60
7. Couche serveur .......................................................................... 61
8. Couche client.............................................................................. 63
Conclusion ................................................................................................. 64
Conclusion générale......................................................................................... 65

6
 Table des figures :
Figure 1: Illustration de l’Autonetics-D17, l’ordinateur de guidage .................................................................... 12
Figure 2 : Illustration de l’Apollo Guidance Computer et son écran d’utilisation ............................................... 12
Figure 3: Premier microprocesseur Intel 4004 ..................................................................................................... 13
Figure 4: Premier Electronic Control Unit (ECU) ............................................................................................... 13
Figure 5: Représentation de l’environnement général d’un système embarqué et de ses interactions ................. 15
Figure 6: Fonctions d’un véhicule moderne .......................................................................................................... 16
Figure 7: Représentation d’un système en temps réel avec son environnement .................................................... 18
Figure 8: Évolution du coût de l’électronique dans l’automobile ......................................................................... 19
Figure 9: évolution de la demande mondiale adressée aux pays constructeurs automobile ................................. 34
Figure 10: Evolution de la vente des VP 2019 ...................................................................................................... 35
Figure 11: Evolution des importations par principaux pays ................................................................................. 35
Figure 12: Perspectives de la production automobile mondiale à l’horizon 2020................................................ 36
Figure 13: Diagramme pieuvre ............................................................................................................................. 39
Figure 14: Planning du travail .............................................................................................................................. 39
Figure 15: Diagramme de Gant ............................................................................................................................ 40
Figure 16: Gestion de projet par Trello ................................................................................................................ 40
Figure 17: Architecture de la solution proposée ................................................................................................... 44
Figure 18: Tableau comparatif des cartes à microcontrôleur............................................................................... 44
Figure 19: Comparatif des interfaces OBD .......................................................................................................... 47
Figure 20: : Comparaison entre les OBD Bluetooth ............................................................................................. 48
Figure 21: Comparatif des 3 meilleurs OBD ........................................................................................................ 49
Figure 22: Interface OBD choisi ........................................................................................................................... 49
Figure 23: Materiel requis pour la réalisation du circuit ..................................................................................... 50
Figure 24: Installation logiciel Raspbian .............................................................................................................. 52
Figure 25: installation raspberry sur le véhicule .................................................................................................. 52
Figure 26: développement du choix proposé ......................................................................................................... 53
Figure 27: Validation du choix .............................................................................................................................. 54
Figure 28: Simulateur OBDsim ............................................................................................................................. 58
Figure 29: instalation pyOBD ............................................................................................................................... 59
Figure 30: Lecture et envoi des données de diagnostic de voiture (OBD-II) ........................................................ 59
Figure 31: Stockage des données et réponse aux requetés des applications ......................................................... 59
Figure 32: Affichage des donnés stockés dans la base de donnés MongoDB ....................................................... 59
Figure 33: Affichage des donnés stockés dans la base de donnés MongoDB ....................................................... 59
Figure 34: Stockage des données et réponse aux requetés des applications mobiles ........................................... 59
Figure 35: Application de diagnostic à distance des véhicules ............................................................................. 59

7
 Introduction générale
Les systèmes embarqués prennent une place grandissante dans
l’automobile : du lève-vitre électrique à la direction assistée, en passant par
l’ABS, la climatisation, … Ils y jouent un rôle crucial en matière de confort, de
sécurité.

Comme nous allons le voir dans une première partie, les systèmes embarqués
sont nombreux, de natures diverses, et dans leur ensemble très complexe. Un
bon nombre d’entre eux touche à la sécurité du véhicule et de ses passagers, et
c’est donc naturellement que nous nous sommes penchés sur ce thème dans
notre seconde partie. Nous approcherons donc la sécurité dans les systèmes
embarqués, leurs avantages, mais aussi leurs dangers, à l’heure où la sécurité
routière est un sujet d’actualité.

Notre projet a pour le but d’étudier l’implémentation d’un diagnostic a

distance des véhicules constitue une solution totalement innovante, qui confère à
l’atelier une nouvelle dimension. Il s’agit d’un outil miniaturisé qui, une fois
installé sur la prise de diagnostic du véhicule, est configuré en quelques minutes
et offre alors une typologie de services inédite, le garagiste a la possibilité
de suivre constamment et à distance, l’état du véhicule, en gérant la maintenance
de manière prédictive, réalisant même des réglages qui permettent de redonner
au véhicule ses conditions optimales de fonctionnement.

Il va se présente comme un élément de liaison entre le technicien et le véhicule

en circulation, fidélisant ainsi les clients grâce à un service d’assistance en
continu.

C’est également une solution idéale pour les conducteurs et les gestionnaires de
flottes, en mettant à jour régulièrement des éléments de leurs véhicules et en leur
permettant d’exécuter des actions ciblées liées à la réduction des coûts et à
l’optimisation de l’utilisation des véhicules, grâce à une application et à un
portail de gestion dédiés.

8
 Chapitre 1 :
Présentation de générale

9
 Introduction
Dorénavant les systèmes embarqués font partie intègre de notre vie, la
majorité des individus possède aujourd’hui des systèmes embarqué occupe une
place très importante dans le monde.

Nous pouvons actuellement en compter plus d’un milliard ayant chacun

leurs spécificités, recouvrant tous les domaines que ce soit l’aéronautique,
l’électroménager, la téléphonie ou encore l’automobile.

L’amélioration de la qualité des produits et l’ajout constant de nouvelles

fonctionnalités sont directement dues à l’intégration de systèmes embarqués et
permettent, dans le cadre du développement économique, de créer de la valeur
ajoutée, tout en améliorant la compétitivité de l’entreprise fabricante. Ainsi, les
systèmes embarqués apportent une plus-value certaine aux caractéristiques du
produit permettant de se différencier dans des marchés de masse tout en
apportant une disponibilité de fonctions techniques et complexes.

Dans ce chapitre on va présenter en générale l’organisme qui nous

accueillir durant notre projet de fin d’étude, et on va parler sur le cadre générale
de notre master qui est les systèmes embarqués dans l’automobile et ces
contrainte.

10
 I. Présentation de l’entreprise :
Happy Agency c’est une agence web digitale crée en 2017 spécialisé dans
la réaction des sites web et Mettre en place des solutions adaptées aux besoins
du client dans le domaine de l’informatique digital créative et de
communication, elle offre des services créatifs, modernes et innovants dans le
développement de solutions Web et informatique ( Site web, application
mobiles, solutions business, graphisme, ...), il assiste aussi le diagnostic et la
réparation automobile

1. Activités de l’entreprise :
1.1. Création des sites Web

Développement des modernes sites web

Mettre en œuvre des outils de points
Rendre le site web ergonomique et lucratif

1.2. Développement mobile et Marketing digital

Référencement SEO/SEA (SEM)

Le continu de la page
Les liens ou les urls
Les éléments techniques
Applications natives
Applications hybrides
Applications Web

1.3. Diagnostic et réparation Automobile

Diagnostic avec les appareilles OBD

Entretien des composants mécaniques
détériorés
Fabrication mécanique des pièces
mécaniques

11
 1.4. Community management

Réseaux sociaux
Analyses et reporting
Facebook: Pub & Bots

II. Présentation des Systèmes Embarqués :

1. Historique :
Les premiers systèmes embarqués, c’est-à-dire les premiers ordinateurs
autonomes ayant les ressources nécessaires afin de pouvoir fonctionner dans un
environnement externe, ont fait leur apparition au début des années 1960 aux
Etats-Unis.

Figure 1: Illustration de l’Autonetics-D17, l’ordinateur de guidage

Le tout premier système embarqué a été conçu en 1962 dans le but de

guider le missile nucléaire Minuteman I. Son poids était de 28 kg et contenait
plusieurs circuits intégrés afin de réaliser les tâches qui lui étaient dédiées
comme le guidage du missile selon le positionnement du missile.

Figure 2 : Illustration de l’Apollo Guidance Computer et son écran

d’utilisation

L’Apollo Guidance Computer a été également un des tous premiers

systèmes embarqués, qui comme l’Autonetics D-17, a pour principal but de
guider son appareil. Il a été conçu au début des années 1960 pour enfin être testé
et utilisé en 1966 lors du programme Apollo qui représente un voyage sur la
12
lune via une fusée spatiale. Deux de ce système étaient placés dans le vaisseau
afin de la guider. Son poids était de 32 kg et contenait plusieurs centaines de
circuits intégrés.

Figure 3: Premier microprocesseur Intel 4004

Ceci est le premier microprocesseur apparu en 1971 par l’entreprise Intel.

C’est le premier système embarqué ayant la capacité à pouvoir incorporer tous
les éléments d’un ordinateur (mémoire, contrôle d’accès, unité de calcul) dans
un même circuit intégré. Auparavant, plusieurs circuits ayant des fonctions
spécifiques devaient travailler ensemble pour accomplir une tâche. Or, depuis
l’apparition de ce microprocesseur, toutes les tâches pouvaient être réalisées par
un seul composant. C’est avec ce type de système que l’ère de l’informatique
embarquée débuta en faisant son apparition dans l’industrie du multimédia, de
l’électroménager et de l’automobile.

Dans l’automobile, les premiers systèmes embarqués sont apparus au

début des années 1970. Les sociétés automobiles surfèrent sur la vague de
l’innovation technologique des systèmes embarqués afin d’en tirer profit et de
pouvoir les utiliser dans leurs propres véhicules.

Figure 4: Premier Electronic Control Unit (ECU)

13
 Electronic Control Unit (Unité de Contrôle Electronique) représente tout
système qui permet la gestion de fonctions dans un véhicule. L’un des premiers
a été conçu par Chevrolet pour la Chevrolet Cosworth Vega en 1975, il
permettait la gestion complète

Du moteur et notamment la transmission automatique du carburant aux

cylindres. Une dizaine de capteurs lui transmettaient les informations
nécessaires à la réalisation de cette tâche.

2. Définition :
Un système embarqué est un ensemble d’éléments informatiques et
électroniques interagissant entre eux de façon autonome et complémentaire. Ces
systèmes sont conçus de manière à pouvoir répondre spécifiquement aux
besoins de leur environnement respectif.

Le terme « système » désigne l’ensemble des éléments qui constituent le

système embarqué, souvent ces systèmes sont composés de sous-systèmes étant
donné leur complexité.

Le terme « embarqué » représente la mobilité et l’autonomie du système en

interaction directe avec son environnement dans l’exécution de tâches précises,
afin de répondre à la finalité de celui-ci.

Contrairement aux systèmes classiques, les systèmes embarqués sont

conçus pour réaliser des tâches bien précises. Certains doivent répondre à des
contraintes de temps réel pour des raisons de fiabilité et de sécurité,
indispensables selon l’utilisation du système.

Un système embarqué regroupe à la fois la partie software (logicielle) et

la partie hardware (matériaux) étroitement liées afin de produire les résultats
escomptés.

14
 3. Contraintes :
Du fait que ce type de système soit « embarqué » ou « enfoui », plusieurs
contraintes lui sont imposées. Les systèmes embarqués se retrouvent aujourd’hui
partout dans différents types d’environnements (téléphone, véhicule, avion…) et
liés à différents types d’utilisations. C’est le secteur d’activité dans lequel est
utilisé le système qui va permettre de définir ses contraintes. Voici un aperçu
général des principales contraintes des systèmes embarqués :

Tableau 1 : Tableau des contraintes de système embarqué selon secteur d’activité

Figure 5: Représentation de l’environnement général d’un système

embarqué et de ses interactions

Cette figure illustre l’image d’encapsulation d’un système embarqué par

son environnement (ici les processus externes) qui interagit directement avec lui.
Des moyens de communications existent en tant qu’intermédiaire propre à
chaque environnement.

15
 Aujourd’hui, un véhicule contient une grande quantité d’électronique et
d’informatique : on retrouve plus de 100 capteurs, 30 à 50 calculateurs selon le
type de véhicule et parfois près d’un million de lignes de codes pour les
véhicules de dernière génération. Cette évolution s’explique par les demandes
exigeantes des consommateurs et l’envie de différenciation des concurrents sur
marché de l’automobile. S’ajoute à cela les contraintes économiques et
écologiques où l’électronique embarquée répond à ces nouvelles attentes. De
nouvelles fonctionnalités impliquent parfois une intégration électronique et
informatique par le biais de systèmes embarqués. Voici une représentation des
systèmes intégrés d’un véhicule moderne.

Figure 6: Fonctions d’un véhicule moderne

Toutes ces fonctions se catégorisent selon leur domaine d’action :

 Habitacle / Confort (climatisation, siège chauffant, allumage

automatique des feux…)
 Moteur / Transmission (contrôle injection, commande boite de
vitesses…)
 Sécurité (ABS, Airbags, ESP, radar de recul…)

16
 Abréviation Désignation Utilité
ECU ou ECM Engine Control Unit Système permettant la gestion
du bloc moteur

SCU Speed Control Unit Système de régulation de

vitesse, permet de rouler à une
vitesse constante

TCU Telematic Control Unit Permet de connaitre le

positionnement du véhicule et
les coordonnées GPS en temps
réel

BCM Brake Control Module Système représentant l’ABS,

permettant l’aide au freinage
lors des freinages d’urgences

BMS Battery Management System Système permettant de réguler

la batterie du véhicule

Tableau 2 : Les différents types d’ECU

Tous ces ECUs sont reliés à des capteurs et des actionneurs leur
permettant d’envoyer et de traiter les informations. Une communication est donc
présente entre tous ces composants électroniques via des bus de communication.
Toute cette composition forme l’électronique embarquée du véhicule.

4. Le temps réel :
Comme déjà spécifié, les systèmes embarqués sont soumis à des
contraintes différentes selon leur domaine d’utilisation. Et bien, le temps réel est
l’une des contraintes primordiales dans le secteur de l’automobile au niveau de
la performance mais surtout au niveau de la sécurité. Devant un ordinateur
classique, quelques minutes de latence ne pourront affecter que l’humeur de
l’utilisateur, sur un système embarqué d’automobile seules quelques secondes
de latence suffisent à provoquer un accident avec des conséquences terribles.

Le temps réel est le fait d’être constamment en adéquation temporelle

avec la réalité. Un système en temps réel est un système qui doit, non seulement,
produire un résultat juste mais dans une durée limitée, sans quoi ce résultat
deviendrait erroné. Ainsi, le système en temps réel doit fournir un résultat avec
une contrainte de temps

17
 Le temps est déterminé par l’environnement dans lequel se trouve le
système, celui-ci doit avoir l’image la plus réaliste de celle de son
environnement externe qui évolue lui-même avec le temps.

Figure 7: Représentation d’un système en temps réel avec son environnement

L’échelle de temps dépend de l’environnement dans lequel le système est

utilisé, il peut varier de quelques millisecondes à plusieurs heures. Lorsque nous
sommes dans notre véhicule, il est préférable de voir l’allure à laquelle nous
roulons aux millisecondes prés, (Marc Alias, Ingénieur automobile,
L’affichage de la vitesse à quelques minutes d’intervalles rendrait les données
complètement fausses.

5. Quelques chiffres :
Un véhicule renferme aujourd’hui plus de lignes de code qu’un avion
Airbus de première génération, soit près d’un million de lignes pour les
véhicules haut de gamme. (Institut Universitaire de Belford-Montbeliard, 2013)

On compte de nos jours jusqu’à 80 calculateurs par voiture, un constat

flagrant sur l’évolution des systèmes embarqués dans l’automobile.

18
 Ainsi, la part de l’électronique des véhicules a connu un essor de grande
envergure comme en témoigne ce graphique.

Figure 8: Évolution du coût de l’électronique dans l’automobile

Nous constatons que le coût de l’électronique représente aujourd’hui près

de 40% du prix total du véhicule. Certains véhicules de luxe valent aujourd’hui
plus de CHF 150'000.- due notamment à la quantité d’électronique qui y est
Intégrée pouvant proposer une multitude d’options.

Ainsi, les systèmes embarqués sont en plein essor avec les premières voitures
autonomes contenant beaucoup plus d’informatique embarqué que des véhicules
classiques et de plus en plus connectés au monde extérieur.

Conclusion

Les systèmes embarqués prennent une grande place dans le domaine de

l’automobile, plusieurs calculateurs dans un véhicule qui communique entre eux
via des protocoles de communication. Pour travailler sur notre sujet, les
connaissances informatique et électronique ne suffit pas ça nécessaire des fortes
connaissances en mécanique et le diagnostic particulièrement.

19
 Chapitre 2 :
Diagnostic embarqué automobile

20
Introduction :

Les véhicules embarquent de plus en plus de technologies permettant de

rouler en parfaite sécurité, ces technologies ne sont pas seulement plus
nombreuses. En effet, elles sont aussi de plus en plus intelligentes. C’est
notamment le cas des différents calculateurs qui, non content de faire
fonctionner toutes les nouvelles technologies intégrées dans les automobiles,
permettent également de transmettre des informations relatives à l’état et aux
performances de ces technologies aux usagers, par le biais d’un système de
diagnostic embarqué. Grâce à la transmission des données utiles récoltées par les
capteurs et envoyées aux logiciels de diagnostic,

Les systèmes de diagnostic embarqués, aussi nommés OBD (pour On-Board

Diagnostics) représentent l'ensemble des interfaces (outils spécialisés,
ordinateur, smartphone, …) embarquant un logiciel spécialement conçu pour
réaliser des diagnostics automobiles, et capables de communiquer avec les
différents calculateurs présents dans le véhicule, afin de recueillir les diverses
informations liées à l’état du véhicule.

21
 I. Historique de diagnostic automobile :
À partir des années 1980, les constructeurs automobiles ont commencé à
intégrer massivement de l'électronique dans leurs véhicules, en particulier à
travers l'utilisation d'un calculateur de contrôle moteur (aussi appelé calculateur
d'injection, initialement utilisé en essence) destiné à gérer le fonctionnement du
moteur et à diagnostiquer ses défaillances. Les diagnostics embarqués sont
devenus progressivement de plus en plus sophistiqués, pour permettre aux
moteurs de respecter les seuils d'émissions polluantes réglementaires de plus en
plus stricts. Aux États-Unis, c'est l'Agence de Protection de l'Environnement qui
a fixé les premiers seuils standard. Par la suite, les exigences règlementaires sont
allées plus loin que ces simples seuils et se sont étendues aux méthodes et
moyens à mettre en œuvre pour détecter toute perte de la capacité à maîtriser les
émissions et en avertir l'utilisateur. Cette règlementation des diagnostics OBD
est née en Californie en 1985.

1. Les principaux points de contrôle dans une voiture

Beaucoup de contre-visites résultent de défauts sur le véhicule qu’il est possible
de corriger en effectuant soi-même certaines vérifications. Voici notre check-list
des 9 points importants de contrôle technique fréquemment concernés par une
contre visite.

1.1. Immatriculation du véhicule

La vérification des plaques d’immatriculation à l’avant et à l’arrière

consiste à s’assurer que celles-ci sont conformes à la réglementation en
vigueur. Le lettrage doit bien sûr concorder avec le certificat d’immatriculation.
Les plaques doivent être lisibles, non détériorées et bien fixées. Deux types de
lettrages sont acceptés : AA-XXX-AA (pour les véhicules immatriculés depuis
2009) et XXXX AA XX (pour les véhicules immatriculés avant 2009).

1.2. Pneumatiques

Les pneus étant les seuls éléments en contact avec le sol, ils sont les
premiers garants de la qualité du freinage. C’est pourquoi le contrôle visuel
régulier des pneus est indispensable.
22
 Plusieurs vérifications simples sont à effectuer. Assurez-vous en premier
lieu que la pression est correcte et qu’ils ne sont pas déformés (pas de hernie ou
de déchirure au niveau des flancs, pas de corps étranger dans la bande de
roulement, pas de déformation de la jante). Contrôlez les témoins d’usure : la
profondeur des rainures de la bande de roulement ne doit pas être inférieure à
1,6 mm. Il est à noter également que les pneus d’un même essieu doivent être de
structure et de marque identique.

1.3. Freinage

Si vos plaquettes et disques de frein sont trop usés, il est recommandé,

en prévention, de les remplacer. Si vous constatez en conduisant que lors de
freinages appuyés votre véhicule se déporte à droite ou à gauche, cela signifie
que vos freins sont en mauvais état ou déséquilibrés. Il est également nécessaire
de contrôler le liquide de frein.

1.4. Amortisseurs

Le contrôle visuel des amortisseurs permet de s’assurer qu’ils ne fuient

pas. Il s’agit de vérifier l’absence de tâches d’huile qui pourraient indiquer une
fuite dans le circuit, de s’assurer qu’il n’y a pas de déformation de la tige ou du
corps de l’amortisseur, pas de corrosion et que l’état des fixations est correct.

1.5. Échappement

Si le pot d’échappement dégage une fumée noire au démarrage, cela doit

vous alerter sur le niveau de pollution de votre véhicule. Il est conseillé de faire
vérifier le véhicule par un professionnel. Assurez-vous également que le pot
d’échappement ne présente pas de fuites, et qu’il est correctement fixé.

1.6. Visibilité

Il s’agit de vérifier l’état du pare-brise et des vitres (pas de fissure

supérieure à 30 cm), des essuie-glaces et des rétroviseurs intérieurs et extérieurs.
Il convient également de s’assurer du bon fonctionnement de la commande de
réglage des rétroviseurs extérieurs ainsi que du système de désembuage du pare-
brise.

23
 1.7. Éclairage et signalisation

Il est recommandé de vérifier le bon fonctionnement de l’ensemble de vos

feux à l’avant et à l’arrière (feux de position, de croisement, de route et de stop),
de vos clignotants, du signal de détresse, du 3ème feu de stop, de l’éclairage de
la plaque d’immatriculation arrière et des catadioptres arrières et latéraux. Pour
finir, assurez-vous que le klaxon fonctionne bien.

1.8. Structure et carrosserie

Lors du contrôle visuel de la carrosserie, assurez-vous que celle-ci ne

comporte pas de parties saillantes qui risqueraient de blesser un tiers. Il convient
également de vérifier la bonne ouverture, fixation et fermeture des portes (de
l’intérieur et de l’extérieur), du coffre, des hayons et du capot moteur.

1.9. Équipements de l’habitacle

Pour vous assurer du bon état de votre équipement, voici l’ensemble des
éléments à contrôler : la fixation des sièges et le bon fonctionnement du réglage,
la présence et le bon fonctionnement des ceintures de sécurité. Si vous êtes
équipé d’un siège bébé, nous vous conseillons de l’enlever avant de venir passer
le contrôle technique afin qu’il ne gêne pas les vérifications. Sinon le contrôleur
devra le retirer.

2. Diagnostic électronique

Cet acte peut être réalisé en cas de panne ou d’allumage d’un voyant sur
le tableau de bord. En branchant son appareil, le garagiste pourra déterminer, à
l’aide d’un signal émis par la machine, quel élément électronique est défaillant.

Ensuite, il lui faudra contrôler, voire changer l’élément défectueux. Il n’est

toujours nécessaire de changer une pièce. Parfois, il peut s’agir d’un
dysfonctionnement qui nécessite simplement une remise à zéro du système ou
de réinitialiser des fonctions.

D’autre part, le diagnostic électronique peut être réalisé au moment de la

révision du véhicule.

24
 En effet, l’appareil peut accéder à la mémoire des différents ordinateurs de bord
afin de détecter si un élément est défectueux ou s’il est sur le point de s’altérer.
L’appareil peut anticiper une panne même si aucun voyant ne s’est allumé.
Difficile donc, sans disposer de cet appareil, de faire soi-même les vérifications
essentielles.

II. OBD :
La norme OBD (pour On Board Diagnostic) a été mise en place au départ par
la CARB (Californien Air Ressources Board) pour contrôler les émissions
polluantes des véhicules. L'arrivée des calculateurs électroniques de gestion du
moteur et des capteurs associés a permis aux véhicules de diminuer leurs rejets
polluants. L'OBD, en tant que tel, stipule que le véhicule doit, sur toute sa durée
de vie, surveiller en permanence le bon fonctionnement du moteur.

1. Types :
Il existe plusieurs normes de l'OBD :

L'OBD ou OBDI qui standardise le connecteur afin qu'il soit identique pour tous
les véhicules. Le protocole de communication lui reste plus ou moins spécifique
suivant les marques.

L'OBDII est venu en 1996 aux Etats Unis pour spécifier des protocoles
communs.

L'EOBD pour Européen OBD reprenant l'OBDII est spécifique pour les
véhicules européens.

L'EOBD a lui été instauré en Europe en même temps que la norme EURO3 sur
les rejets polluants des véhicules. Elle précise que les défaillances sur les
émissions doivent être signalées par un voyant au tableau de bord et que des
codes correspondants aux défaillances détectées doivent être enregistrés par le
véhicule.

25
 La plupart des voitures depuis les années 2000 disposent d’un système
électronique embarqué, en anglais On-Board Diagnostics (OBD) qui détecte les
défauts et pannes liés aux émissions de gaz d’échappement dans les véhicules
légers, les utilitaires et les poids lourds qui fonctionnent avec un moteur à
combustion interne.

Il existe plusieurs normes de l’OBD :

– L’OBD ou OBDI qui standardise le connecteur afin qu’il soit identique

pour tous les véhicules. Le protocole de communication lui reste plus ou
moins spécifique suivant les marques.
– L’OBDII venu en 1996 aux Etats Unis pour spécifier l’interface
standard d’accès au système de diagnostics embarqués.
– L’EOBD pour Européen OBD reprenant l’OBDII est spécifique pour les
véhicules européens.

Concrètement, le système de diagnostic embarqué de votre voiture détecte

qu’un composant du système d’injection, d’allumage ou antipollution est
défaillant. Grâce à un petit boitier ou une sorte de grosse clé USB que l’on
branche au connecteur OBD, vous pouvez lire le code erreur et savoir ainsi d’où
vient le problème.
Voici un exemple d’un outil de diagnostic universel autonome où vous pouvez
directement lire les informations sur l’écran

2. La norme OBD II :
La version II (OBDII) des diagnostics embarqués correspond à un
système conçu par la Society of Automotive Engineers (SAE) afin de normaliser
le diagnostic électronique des automobiles.

Depuis 1996, la plupart des nouveaux véhicules vendus aux États-Unis sont
conformes à l’OBDII.

Les techniciens peuvent désormais utiliser le même outil afin de tester les
véhicules conformes à l’OBDII sans nécessiter d’adaptateur spécial. La SAE a
défini des directives offrant :

26
 Un connecteur de liaison de données OBDII universel, appelé DLC du
véhicule, muni d’une disposition de broches dédiée; Un emplacement standard
pour le DLC du véhicule, bien visible sous le tableau de bord, du côté du
conducteur; Une liste normalisée des codes d’anomalie utilisée par tous les
constructeurs;

Une liste normalisée des données d’identification des paramètres (PID)

utilisée par tous les constructeurs; la capacité d’enregistrer les conditions de
service des systèmes du véhicule advenant une défaillance; possibilités avancées
de diagnostic permettant d’enregistrer un code lors de l’apparition d’une
condition ayant un impact sur l’émission du véhicule; la capacité d’effacer les
codes enregistrés dans la mémoire du véhicule grâce à l’analyseur-contrôleur.

3. Connecteur de liaison de données (DLC) OBDII

Le connecteur de liaison de données (DLC) OBDII permet à l’analyseur-
contrôleur de communiquer avec le ou les ordinateurs du véhicule.

Depuis 1996, les véhicules vendus aux États-Unis utilisent le DLC J1962
(OBDII), un terme tiré du numéro de spécification physique et électrique assigné
par la SAE (J1962). Le DLC devrait se trouver sous le tableau de bord, du côté
du conducteur. S’il ne s’y trouve pas, une étiquette indiquant son emplacement
devrait être fixée au tableau de bord, là où le DLC aurait dû se trouver.

27
 4. Broches du connecteur de liaison de données
(DLC) OBDII :

5. Codes d’anomalie (DTC) OBDII :

J2012 et ISO 15031-6 sont des normes relatives à tous les DTC ayant été
définies par la SAE, l’Organisation internationale de normalisation (ISO) et
d’autres entités dirigeantes.

Les codes et définitions assignés par ces spécifications sont connus sous le nom
de Codes OBDII génériques.

28
 L’OBDII exige que tous les véhicules automobiles, camions légers,
véhicules de patrouille blindés, véhicules de tourisme à usages multiples et VUS
vendus aux États-Unis se conforment à ces normes.

Les codes non utilisés par la SAE sont réservés au constructeur et sont
connus sous le nom de Codes spécifiques au constructeur.

Les codes d’anomalie sont utilisés afin d’aider à déterminer la cause de

problèmes d’un véhicule.

Ils consistent en un code alphanumérique à cinq chiffres.

Le format des DTC et les types de codes généraux sont décrits ci-dessous.

Exemple :

P0101 = Problème de plage/efficacité du circuit de débit massique ou volume

d’air

29
Conclusion

Le diagnostic électronique nous a permet de vérifier si le véhicule est

totalement sécurisé, ce que nous ne pouvons savoir tant qu’un voyant ne s’est
pas allumé. En réalisant un diagnostic régulier, il nous assure, l’anticipation, la
sécurité et celle des autres usagers de la route.

30
 Chapitre 3:
Cahier des charges

31
Introduction :

Lorsqu’on débute un nouveau projet, la notion de cahier des charges peut

Faire peur. Généralement, toutes les actions administratives à effectuer sont
envisagées, avant même de se lancer dans la rédaction. On pourrait croire qu’il
est contre-intuitif à l’heure des méthodes agiles et de cette volonté des entreprises
d’aller plus vite dans la conduite de projet.

Mais au contraire ! C’est en commençant par un cahier des charges clair, qu’un
bon projet peut être conduit de la meilleure des manières, en y intégrant
l’ensemble des parties prenantes.

Nous on s’intéresse à faire dans un premier temps l’étude du besoin et

l’analyse fonctionnel en général, ainsi d’élaboration du planning de travail pour
bien lister les taches et les durés en respectant la période de stage (date début,
date fin).

32
 I. Problématique :
La maintenance des flottes de véhicules est un enjeu majeur pour les autorités
et opérateurs de transport public. L’efficacité de la maintenance a un impact
direct sur la qualité du service, et elle est un critère économique déterminant
pour les opérateurs de transport public. Actuellement, la maintenance des
véhicules est gérée selon des procédures basiques et avec des outils propriétaires
à chacun des constructeurs de véhicules ou fournisseurs de systèmes. Dans le
meilleur des cas, le conducteur en exploitation signale rapidement l’allumage
des voyants du tableau de bord ou à défaut les reporte sous forme de main
courant en fin de service.

Généralement, le diagnostic est effectué une fois le véhicule tombé en panne,

sans aucune anticipation, avec un impact sur la qualité de service et parfois dans
des conditions difficiles. L'un des principaux obstacles au déploiement de
systèmes de télédiagnostic est le manque d'interopérabilité pour gérer une flotte
hétérogène de véhicules (variété de constructeurs de véhicules et des
fournisseurs de matériel embarqué). notre projet consiste à répond à cette
problématique d’interopérabilité en proposant un service de diagnostic à
distance (télédiagnostic) indépendant des constructeurs et fournisseurs, basé sur
les informations standardisées disponibles dans les véhicules. il va permet de
filtrer, prioriser et combiner toutes ces données pour optimiser la maintenance
de la flotte. Grace à la supervision en temps réel, les équipes de maintenance
peuvent anticiper les interventions et éviter les pannes en ligne. La qualité du
service est améliorée et les coûts se réduisent. Contrairement aux années
passées, le chiffre d’affaires des loueurs de voitures à enregistrer une
progression à deux chiffres en 2018. Cette dynamique liée au retour en force des
touristes étrangers. Le défi qui se pose est en termes de maintenance quotidienne
des véhicules. L’arrêt d’un véhicule en panne provoque la perte d’argent.

33
 II. Etude du marché automobile au Maroc :
Le secteur de l’automobile mondial a été marqué durant les dix dernières
années par une évolution de la demande mondiale adressée aux pays
constructeurs et par l’amplification du phénomène de la sous-traitance qui a
permis à beaucoup de pays émergents de développer une industrie automobile
contribuant ainsi à générer des flux additionnels à l’export très importants.

Figure 9: évolution de la demande mondiale adressée aux pays constructeurs automobile

Au regard des chiffres communiqués par l’Association des Importateurs de

Véhicules au Maroc (AIVAM), le classement des 10 premières marques en
termes des ventes VP du mois écoulé est toujours divisé en 2 :

Tout d’abord le Top Team Dacia/Renault qui s’octroie 42.7% du marché, reste
intouchable.

La troisième marche du podium est encore une fois très disputée entre
Volkswagen (+ 31,58%) et Peugeot (+ 32,67) qui remporte cette manche et le
titre officieux de « Best of the Rest ».

34
 Il est à noter les performances exceptionnelles de Fiat (+144,59%) et
Citroën (+72,11%) qui remonte respectivement à la 6ème et 7ème place.

En revanche, la descente aux enfers continue pour Ford (-40,35%) et Nissan (-

11,57%) qui perdent du terrain pour pointer aux 8 et 9ème rang

Figure 10: Evolution de la vente des VP 2019

En ce qui concerne les ventes cumulées totales (VP+ VUL) depuis le

début de l’année, on remarque des changements notoires dans le classement des
10 premiers.

Figure 11: Evolution des importations par principaux pays

Source : Données Office des Changes, élaboration DEPF

35
 Ce constat pose le défi de l’intégration locale de l’industrie automobile
nationale qui est considérée parmi les principaux enjeux du secteur, avec des
perspectives de développement, notamment, dans le cadre du nouveau plan
d’accélération industrielle 2014-2020.

Figure 12: Perspectives de la production automobile mondiale à l’horizon 2020

Source : Price WaterhouseCoopers, 2014

Du côté demande, son déplacement vers la Chine atteindra des niveaux

sans précédent en 2020 avec 34,7 millions d’unités. L’Amérique du Nord sera le
deuxième plus grand marché, avec près de 20% du volume des ventes annuel
mondial (20,7 millions). L’Europe de l'Ouest conservera, quant à lui, jusqu'au
2020 la troisième place devant l'Inde et l'ASEAN.

Le secteur automobile mondial connaît une phase de refonte de sa chaîne

de valeur avec un basculement de la demande et de l’offre mondiale vers les
pays émergents. Cette nouvelle restructuration de la chaîne de valeur mondiale a
incité un important redéploiement des capacités de production entre les grandes
zones géographiques.

36
 III. Contexte du projet
1. définition
Étude de l’implémentation d’un diagnostic à distance des véhicules

2. Objectif du projet
Une analyse de panne précise, afin d’éviter de remplacer inutilement des
pièces et ainsi gagner du temps.

Diagnostic complet, contrôle des valeurs, activations, adaptations, codage,

effacement défaut, analyse.

Inutile de lancer votre mécanicien dans des recherches de panne longues

et infructueuses, le diagnostic à distance vous fournit une analyse de panne
précise, afin d’éviter les réparations inutiles.

Améliorez ainsi la rentabilité des entreprises.

Meilleure satisfaction des clients et diminution des discussions suite à un

diagnostic erroné.

3. Analyse fonctionnelle du besoin :

2.1. Bête à cornes :

37
 Avant de se lancer dans la conception, il convient de bien identifier et
formaliser les objectifs du projet. Cette phase est essentielle, car elle fixe la
direction du travail qui va être entrepris. Pour faciliter cette tâche, il existe un
outil pratique afin d'expliciter les besoins plus aisément : la bête à cornes. Ce
diagramme simple d'utilisation sert de guide pour mener une analyse
fonctionnelle du besoin.

Cet outil se situe dans la première étape de la méthode APTE (méthode

d'analyse fonctionnelle et d'analyse de la valeur). Il a pour objectif de
représenter graphiquement l'expression du besoin à travers 3 questions simples
autour du sujet étudié :

A qui rend- il un service ?

Sur quoi agit-il ?
Dans quel but ?

2.2. Diagramme de SADT :

La méthode SADT, ou méthode d'analyse fonctionnelle descendante, est

une méthode graphique qui part du général pour aller au particulier. Elle permet
de décrire des systèmes complexes où coexistent différents flux de matière
d'œuvre : systèmes automatisés, asservis ou intégrant l'informatique.

38
 2.3. Diagramme Pieuvre :

L'outil “diagramme pieuvre” est utilisé pour analyser les besoins et

identifier les fonctions de service d'un produit. Le diagramme “pieuvre” met en
évidence les relations entre les différents éléments du milieu environnant et le
produit. ... Il crée une ou des relations entre 1 et 2.

Figure 13: Diagramme pieuvre

4. Planning de travail :
On travaille avec MS Project Office Pour pouvoir suivre l’avancement de
notre projet on a planifié les taches et les sous taches, cet outil nous a faciliter la
gestion du temps ainsi que l’analyse et la communication des données de projet
entre nous.

Figure 14: Planning du travail

39
 Figure 15: Diagramme de Gant

Pour faciliter la communication entre nous ; Trello parait la meilleure

solution pour la gestion de projet en ligne il nous permet de partage et échange
d’information ; ainsi le suivi d’état d’avancement à tout moment.

Figure 16: Gestion de projet par Trello

40
PRINCIPALES FONCTIONNALITÉS

 Joindre des fichiers

 Commenter
 Ajouter une liste de tâches
 Mettre une date limite
 Assigner des labels de couleur (important, urgent …)
 Déplacement facile d’une colonne à une autre par glisser / déposer
 Création illimité des colonnes
 Système de notifications très efficace

On peut donc, pour chaque aspect d’un projet, laisser nos commentaires,
répartir nos tâches, centraliser des informations et suivre l’état d’avancement.

Conclusion

Après l’élaboration de cahier des charges à l’aide de l’analyse fonctionnelle

(Diagramme pieuvre, Bête à cornes, Digramme de SADT), On a défini le cadre
générale de projet et ses perspectives, en suite la gestion de projet par Trello qui
est une application de partage des informations en ligne, et qui nous facilite suivi
des tâches par ordre de priorité.

41
 Chapitre 4 :
Conception et réalisation

42
 Introduction
La conception est la phase créative d’un projet
d’ingénierie. Le but premier de la conception est de permettre
de créer un système ou un processus répondant à un besoin en
tenant compte des contraintes. Le système doit être
suffisamment défini pour pouvoir être installé, fabriqué,
construit et être fonctionnel, et pour répondre aux besoins du
client.
Après la phase de conception on passe à la réalisation qui
s'agit de l'étape de développement de l'ouvrage proprement
dite. Cette étape est de la responsabilité du maître d'oeuvre,
sous contrôle du maître d'ouvrage. Lors de la réalisation de
l'ouvrage l'accent doit être mis sur la communication afin de
pouvoir prendre les décisions au plus vite en cas de problème.

43
 I. Conception :

Dans le cadre de ce projet on a décidé de faire une conception de

diagnostic à distance des véhicules à l’aide d’un OBD installé dans le prise de
diagnostic de la voiture qui va nous permettre de détecter les anomalies et les
codes erreurs de la voiture et les envoyer via une interface de traitement de
donnée généralement c’est un microcontrôleur dans l’objectif de les
communiquer au système d’exploitation à l’aide d’un réseau sans fil Bluetooth.

Figure 17: Architecture de la solution proposée

1. Choix du microcontrôleur

Figure 18: Tableau comparatif des cartes à microcontrôleur

44
 D’après le comparatif des modernes carte à microcontrôleurs qui existe
dans le marché, On trouve que le RaspBerry Pi3 c’est le seule microcontrôleur
qui répond à notre besoin dans ce projet puisque il se caractérise par plusieurs
performances qu’on doit prendre en considération tel que (Bluetooth, Wifi,
réseau Ethernet et la possibilité d’intégrer le module GRPS dans la carte).

Définition Raspberry :
Le Raspberry Pi 3 B+ est un ordinateur mono-carte pouvant se connecter à
un moniteur, à un ensemble clavier/souris et disposant d'interfaces Wi-
Fi et Bluetooth.

Il démarre depuis une carte micro-SD et fonctionne sous un O.S. Linux ou

Windows 10 IoT. Il est fourni sans boîtier, alimentation, clavier, écran et souris
dans le but de diminuer le coût et de favoriser l'utilisation de matériel de
récupération.

Le modèle Raspberry Pi3 B+ est basée sur un processeur ARM Cortex-

A53 64 bits quatre coeurs à 1,4 GHz, possède 1 GB de mémoire RAM, une
interface Wi-Fi, une interface Bluetooth, 4 ports USB, un port Ethernet, un port
HDMI, un port micro-SD et un connecteur GPIO avec 40 broches d'E/S.

Les interfaces WiFi et Bluetooth ont été améliorés par rapport à la version Pi 3
et supportent maintenant le Wi-Fi 2,4 et 5 GHz ainsi que le Bluetooth 4.2.
L'Ethernet a aussi été amélioré permettant des débits jusqu'à 300 Mbps (2x fois
plus rapide que le Pi 3).

Cette carte est basée sur un processeur ARM et permet l'exécution du système
d'exploitation GNU/Linux/Windows 10 IoT et des logiciels compatibles. Le
Raspberry Pi peut effectuer des tâches d’un PC de bureau (feuilles de calcul,
traitement de texte, jeux). Il peut également diffuser des vidéos en haute
définition grâce à son circuit Broadcom Videocore IV (permet le décodage des
flux Blu-ray full HD).

La Raspberry Pi 3 B+ nécessite une carte SD munie d'un OS, une alimentation,

un clavier USB, une souris USB, un boîtier et des câbles (non inclus). Pour
préparer une carte SD bootable, il faut disposer d'un PC avec lecteur de carte.

45
Remarque:

Une alimentation 5 Vcc/2,5 A est recommandée lors de l'utilisation avec

plusieurs périphériques.

Caractéristiques:
Alimentation à prévoir: 5 Vcc/maxi 2,5 A* via prise micro-USB (*
intensité maxi si toutes les fonctions sont utilisées)

CPU: ARM Cortex-A53 quatre coeurs 1,4 GHz

Wi-Fi: Dual-band 2,4 et 5 GHz, 802.11b/g/n/ac (Broadcom BCM43438)

Bluetooth 4.2 (Broadcom BCM43438)

Mémoire: 1 GB LPDDR2

Ethernet 10/100/1000: jusqu'à 300 Mbps

4 ports USB 2.0

Port ethernet 10/100 base T: RJ45

Bus: SPI, I2C, série

Support pour cartes micro-SD

Sorties audio:

- HDMI avec gestion du 5.1

- Jack 3,5 mm en stéréo
Sorties vidéo: HDMI

Dimensions: 86 x 54 x 17 mm

Poids: 50 g

Version: Raspberry Pi 3 B+

46
 2. Choix de l’interface OBD :
Pour réussir le choix des éléments de l’implémentation de projet on est obligé de
faire un tableau comparatif des interfaces OBD II en se basons sur leurs critères
principaux tell que (prix, compatibilité, connectivité, dimensions etc …) comme
ci-dessous :

Figure 19: Comparatif des interfaces OBD

Après on a choisi trois interfaces car ils sont plus performant et du coût
raisonnable pour les clients.
Pour choisir la meilleure interface OBD on doit se basé sur différents
critères de choix : Ils sont plus pratiques et ne nécessitent pas de connexion à un
autre appareil.

En outre, il est important qu’un OBD2 soit rapide et facile à installer et à

utiliser, qu’il soit performant, et que sa langue soit la même que la vôtre car il y
aura beaucoup de termes techniques… Enfin, sélectionnez un produit peu

47
encombrant car sa place sera sûrement dans votre véhicule, préférez donc un
OBD2 de petite taille et le moins chère, fiable et compatible avec tous les OS.

Et pour faire ce comparatif on est besoin de faire un score selon chaque

critère.

Figure 20: : Comparaison entre les OBD Bluetooth

Le tableau de figure précédent présente les déférents Interfaces OBD les

plus connues sur le marché nationale et internationale on les sélectionne selon
nos critères

48
 Figure 21: Comparatif des 3 meilleurs OBD

D’après le tableau comparatif des OBD on choisit ELM325 pour plusieurs

raisons suivants: il supporte tous les protocoles OBD (VPN, CAN, PWM, KWP)
Bluetooth est sans fil elle peut être utilisé aussi avec un ordinateur ou un
smartphone prix approprié pour tout le monde compatible avec plusieurs
systèmes d’exploitation .

Figure 22: Interface OBD choisi

49
 3. Les étapes de projet :
3.1. Matériel requis

Figure 23: Materiel requis pour la réalisation du circuit

Matériels utilisés :

 Raspberry Pi 3 modèle B+
 Adaptateur micro basse consommation Bluetooth 4.0 enfichable
 Alimentation de voiture 2A / commutateur ou chargeur de voiture micro
USB
 ELM327 Bluetooth
 Câble RCA
 Clavier (* facultatif)

50
 Figure : emplacement de l’interface OBD II

3.2. Qu'est-ce qu'un OBD-II?

OBD signifie "On-Board Diagnostics". Ce connecteur standard est

obligatoire aux États-Unis depuis 1996. Vous pouvez maintenant considérer
OBD-II comme un système informatique embarqué chargé de surveiller le
moteur, la transmission et le contrôle des émissions de votre véhicule.
Composants.

Les véhicules conformes aux normes OBD-II auront un connecteur de données à

environ 2 pieds du volant. Le connecteur OBD est officiellement appelé
connecteur de diagnostic SAE J1962, mais il est également connu par son
connecteur DLC, son port OBD ou OBD. Il a des positions pour 16 pins et
ressemble à ceci:

3.3. Installation Pi OBD

pyOBD (ou pyOBD-II ou pyOBD2) est un logiciel scantool conforme à OBD-II

et à code source ouvert (SAE-J1979), entièrement écrit en Python. Il est conçu
pour s’interfacer avec les interfaces de diagnostic à faible coût ELM 32x OBD-
II telles que ELM-USB. Cela nous permettra essentiellement de parler au
calculateur de la voiture, d’afficher les codes de panne, d’afficher les valeurs
mesurées, de lire les tests d’état, etc.

51
 3.4. Installation du logiciel

Figure 24: Installation logiciel Raspbian

3.5. Installation de véhicule

Figure 25: installation raspberry sur le véhicule

L'installation du véhicule est assez simple.

1. Insérez le dongle Bluetooth USB dans le Raspberry Pi avec la carte SD.

2. Insérez l'adaptateur Bluetooth OBD-II dans le connecteur SAE J196216

(port OBD).

3. Connectez le câble RCA à l’arrière de l’unité principale du marché des

pièces de rechange et branchez l’autre extrémité à votre Raspberry Pi.

52
 4. Installez le chargeur de voiture 2A ou chargeur de voiture micro USB.

5. Enfin, tournez la clé sur la position ON et dirigez l’unité principale vers

l'entrée auxiliaire.

6. Entrer l’identifiants de connexion et exécution:

7. Lancer BlueZ, la pile Bluetooth pour Linux. Associez + confiance à

l’adaptateur Bluetooth ELM327

8. Ouvrir le terminal et exécuter

# cd pyobd-pi
# sudo su
# python obd_gui.py

9. Enregistrement de données

II. Réalisation :
1. Architecture de solution proposée :

Figure 26: développement du choix proposé

53
Notre système est construit selon une architecture à 3 niveaux composés de trois
grandes parties :

 Une partie Hardware : relative aux composants matériels nécessaires

pour le fonctionnement du projet.
 Une partie logicielle : représentant le back-end tier de notre application
qui a pour rôle principale :
Le stockage des données reçu par la partie hardware (Donnée de diagnostic
envoyée d’une manière fréquentiel dans le temps – chaque 5 secondes) dans une
base de données rapide qui est mongo DB.
Répondre aux requêtes des terminaux finaux (Front-End Tier) en envoyant les
dernières données de diagnostic stockés.
 Partie Front End Tier : qui est la couche la plus proche de l’utilisateur
final.
 En fait, c’est l’application android à partir de laquelle l’utilisateur peut
consulter les dernières informations de diagnostic de ca voiture. D’un
système informatique, ce dernier étant composé de systèmes matériels et
de systèmes logiciels

2. Validation du choix

Figure 27: Validation du choix

54
 Le schéma suivant représente les déférents éléments qu’on a choisis
à partir des tableaux comparatifs parmi lesquels :

 OBD II de type ELM327

 Microcontrôleur Raspberry
 Module GPRS
 MongoDB
 NodeJs
 Etc…

GPRS : est une norme (protocole réseau) pour la téléphonie

mobile dérivée du GSM et complémentaire de celui-ci, permettant un débit de
données plus élevé. On le qualifie souvent de 2,5G ou 2G+. Le G est
l'abréviation de génération et le 2,5 indique que c'est une technologie à mi-
chemin entre le GSM (deuxième génération) et l'UMTS (troisième génération).
Le GPRS est une extension du protocole GSM : il ajoute par rapport à ce dernier
la transmission par paquets. Cette méthode est plus adaptée à la transmission des
données. En effet, les ressources ne sont allouées que lorsque des données sont
échangées, contrairement au mode « circuit » en GSM où un circuit est établi –
et les ressources associées – pour toute la durée de la communication. Le GPRS
a ensuite évolué au début des années 2000 vers la norme Edge également
optimisée pour transférer des données et qui utilise les mêmes antennes et les
mêmes fréquences radio.
NodeJS : est une plateforme
logicielle libre et événementielle en JavaScriptorientée vers les
applications réseau qui doivent pouvoir monter en charge.
Elle utilise la machine virtuelle V8 et implémente sous licence MIT les
spécifications CommonJS.
Parmi les modules natifs de Node.js, on retrouve http qui permet le
développement de serveur HTTP. Il est donc possible de se passer de serveurs
web tels que Nginx ou Apache lors du déploiement de sites et d'applications web
développés avec Node.js.
Concrètement, Node.js est un environnement bas niveau permettant l’exécution
de JavaScript côté serveur.

55
 MongoDB : Dans un système de base de données relationnelle les
données sont stockées par ligne dans des tables. Et il est souvent nécessaire de
faire des jointures sur plusieurs tables afin de tirer des informations assez
pertinentes de la base.
Dans MongoDB, les données sont modélisées sous forme de document sous un
style JSON.
On ne parle plus de tables, ni d'enregistrements mais de collections et de
documents. Ce système de gestion de données nous évite ainsi de faire des
jointures de tables car toutes les informations propres à une certaine donnée sont
stockées dans un même document.
JSON : JavaScript Object Notation (JSON) est un format de
données textuelles dérivé de la notation des objets du langage JavaScript. Il
permet de représenter de l’information structurée comme le permet XML par
exemple.
3. Le scenario du système :
OBD reçoit les données de diagnostic à partir de l’ordinateur de bord de la
voiture. Ensuite, il envoi ces informations au microcontrôleur (Rasberry) à
travers le protocole Bluetooth.

La carte Rasberry traite ces informations qui sont en hexadécimal et les

transferts en texte (par une requête ¨POST HTTP – protocole de communication
-) vers les serveurs NOde.js à travers le module GPRS.

Pour ce faire, Rasberry doit envoyer la requête à travers l’adresse statique du

serveur. Cependant, notre PC (qui est serveur dans notre cas) a une adresse
dynamique. Pour contourner le problème nous avions utilisé NO-IP qui nous a
permet d'avoir un ip fixe alors que votre fournisseur d'accès internet nous
attribut un ip dynamique.

Une fois le serveur NodeJS reçoit la requête POST à partir du Rasberry, il

stocke les informations détenues par la requête avec la date de réception dans la
base de données mongoDB qui est très rapide.

Une fois l’utilisateur final accède à l’application mobile, une requête de type
GET vers le serveur est envoyé. Du coup, il renvoi comme réponse contenant le
dernier Object diagnostique. Mentionnant aussi que l’application mobile envoie
chaque labs de temps une requête pour recevoir le dernier état diagnostique.
56
 4. Outils matériel
Pour réaliser ce projet on a fait appel à plusieurs composants électroniques
tell que :
OBD II de type ELM327 pour la détection des informations de véhicule et les
communiquer au microcontrôleur Raspberry avec une extension du module série
Bluetooth /Module GPRS

Module GPRS (General Packet Radio Service) :

Le service général de radiocommunication par paquets (GPRS) est un

service de données mobiles axé sur les paquets du système mondial de
communications mobiles (GSM) des systèmes de communications cellulaires
2G et 3G.

57
 5. Outils logiciels :
No-Ip : permet d'avoir un ip fixe alors que votre fournisseur d'accès
internet vous attribut un ip dynamique

OBDSim fournit un port de communication série virtuel aux applications

clientes (via une fonction de pseudo-terminal) et simule un adaptateur ELM327
connecté à un véhicule via le protocole OBD-II. Il comprend une interface de
ligne de commande pour une surveillance et un contrôle approfondis.

Android studio : est l’environnement de développement (IDE) officiel

pour le système d’exploitation Android de Google, construit sur le logiciel
IntelliJ IDEA de JetBrains et conçu spécifiquement pour le développement
Android. Il est disponible au téléchargement sur les systèmes d'exploitation
Windows, macOS et Linux. Il remplace les outils de développement Eclipse
Android (ADT) comme IDE principal pour le développement d'applications
Android natives.

5.1. Test de simulation en temps réel :

Pour faire les tests nous avions besoins d’une voiture à chaque fois on
modifie dans un script ou bien on veut juste tester notre écosystème. Pour
contourner ce problème nous avions utilisé dans un premier temps :

OBDSIM : Un émulateur de l'adaptateur OBD-II ELM327 connecté à un

véhicule. Puisqu'il n'est pas toujours possible de tester les applications liées à
OBD2 dans un environnement réel avec un véhicule, il existe une application
existante capable de simuler un véhicule avec un dispositif OBD branché.

Figure 28: Simulateur OBDsim

58
 OBDSim est l'un de ces simulateurs que nous avons utilisé pour tester
notre application mobile. Il s’agit d’une plate-forme multiplateforme
fonctionnant sur les plates-formes logicielles Windows / Linux. Semblable à
l'adaptateur ELM327 OBD2, cela fonctionne également sur les commandes AT
utilisées pour configurer un ELM327.

En effet, les différentes couches communiquent par le protocole http

Qui nos permettre un transfert de fichiers (essentiellement au format

HTML) localisés grâce à une chaîne de caractères appelée URL entre un
navigateur (le client) et un serveur Web (appelé d'ailleurs httpd sur les
machines UNIX).

5.2. Paramètres contrôlés :

Chaque requête de communication contient l’objet JSON relative à une

donnée diagnostique d’un R particulier. L’objet diagnostique contient 5 autres
informations :

- RPM : en mécanique c’est régime moteur est le nombre de rotations

effectuées par un moteur par unité de temps. En général, il est exprimé en
tours par minute, Il peut être mesuré au moyen d’un compte-tours ou
d’un stroboscope.
- Speed : vitesse de la voiture elle est en Km/h
- EnigneTemp : C’est la température du moteur Pour la plupart des
voitures, la température normale de fonctionnement du moteur est
comprise entre 195 et 220 degrés Fahrenheit, bien que la plupart des
indicateurs de température du tableau de bord ne montrent pas une
température exacte. Au lieu de cela, il existe généralement des marques de
froid et de chaud sur les bords de la jauge et une plage normale au milieu.
- MassAfflow : est un appareil destiné à contrôler le débit d'air et de
carburant qui sont injectés dans le moteur.
Il permet d'optimiser les performances du moteur mais aussi de limiter au
maximum la consommation de carburant
- ThrottlePosition : Pour fonctionner, un moteur à combustion requiert le
mélange d'un combustible (essence ou gazole) et d'air. Le boîtier papillon est un
boîtier (avec un volet qui s'ouvre ou se ferme pour faire entrer de l'air) contrôlé
par un calculateur qui connaît la position de la pédale d'accélérateur grâce à des
capteurs. Ainsi, par exemple, plus le conducteur appuie sur la pédale

59
 d'accélérateur, plus le boîtier papillon apportera de l'air au mélange
combustible/air en ouvrant plus ou moins le volet d'arrivée d'air. Ce boîtier
papillon se situe ainsi sur la pipe d'admission pour apporter l'air au mélange
combustible/air.

6. Couche matériel (RaspBerry Pi) :

En effet, dans la Raspberry dans avons installé le système d’exploitation
Ubuntu et nous nous somme connecté à l’aide de son HDMI. Et pour connecter
notre Raspberry Pi à un adaptateur Bluetooth OBD-II et à envoyer les données
du moteur en temps réel au serveur nous avons utilisé comme base un
programme en python que nous avons trouvé dans internet github.

Figure 29: instalation pyOBD

C’est un est un scantool conforme à OBD-II et à code source entièrement

écrit en langage de programmation Python. Il est conçu pour s’interfacer avec
l’interface de diagnostic à faible coût ELM 32x OBD-II. Cela permet
essentiellement de parler au calculateur de la voiture, d'afficher les valeurs
mesurées, de lire les tests d'état, etc.

60
 Figure 30: Lecture et envoi des données de diagnostic de voiture (OBD-II)

Le programme se connecte via l'interface OBD-II, affiche les données de

moteur en temps réel sur l'unité principale du marché secondaire de la voiture
dans une interface graphique interactive.

Normalement le script python que nous avons trouvez permet seulement

l’affichage des données dans la sortie de la raspberry ; du coup il fallait intégrait
de plus un fichier de code de plus qui permet d’envoyer en une requête post le
dernier Object diagnostic selon le modèle qu’on a déjà défini précédemment

61
 7. Couche serveur (NodeJS – MongoDB) :
Stockage des données et réponse aux requetés des applications mobile

Figure 31: Stockage des données et réponse aux requetés des applications

Normalement notre serveur NodeJS à travers son code écrit en javascript permet
d’exposée deux services possibles :

- Un service pour les requêtes de type Post pour stocker l’objet diagnostic
reçu dans la base de donnée mongodb.
- Un service pour les requêtes de type GET pour retourner le dernier objet
diagnostic qui existe dans la base de donnée mongodb.
Afin de s’assurer bien que les objets diagnostic sont stockés dans la base de
données, on peut se connecter via la ligne de commande de mongoDB et choisir
la base donnée adéquate qui est dans notre cas « DiagnosticDB » :

Show dbs : c’est pour afficher les bases de données existantes

Use database diagnosticDB : c’est pour utiliser une base de données particulière.

62
Alors qu’on vous voyez lorsqu’on introduit la commande db.diagnostic.find ()
qui permet de retourner tous les données dans une collection particulier en voie
bien que nos objets diagnostic selon le modèle que nous avions défini sont bien
stocké dans la base de donnée avec les différents informations telle que : Speed
of véhicule, mass airflow

Figure 32: Affichage des donnés stockés dans la base de donnés MongoDB

Alors qu’on vous voyez lorsqu’on introduit la commande db.diagnostic.find ()

qui permet de retourner tous les données dans une collection particulier en voie
bien que nos objets diagnostic selon le modèle que nous avions défini sont bien
stocké dans la base de donnée avec les différents informations telle que : Speed
of véhicule, mass airflow

Figure 33: Affichage des donnés stockés dans la base de donnés MongoDB

63
 8. Couche client (Android) :
Stockage des données et réponse aux requetés des applications mobiles :

Figure 34: Stockage des données et réponse aux requetés des applications mobiles

Comme nous avons déjà signalé, nous avons utilisé android studio pour créer
une application qui affiche les dernières données de diagnostic en temps réel de
la voiture à distance. Pour ce faire, le programme java d’android studio envoi
une requête de type GET chaque 5 seconde au serveur pour avoir le dernier objet
diagnostic stocké, après il mise à jour la page de l’application par les données
existant dans l’objet retourné par la requête.

64
 Figure 35: Application de diagnostic à distance des véhicules

Conclusion

Nous avons comme objectifs de créer une Application Mobile Android

comprenant un outil permettant d’obtenir les informations émises par la voiture
en temps réel, ainsi qu’un assistant intelligent, le tout codé en langage Java. Pour
cela, il faudra brancher un outil appelé ELM327 à la prise diagnostique de la
voiture, ainsi nous pourrons récupérer les données du véhicule par Bluetooth, et
les exploiter dans notre application afin de guider l’utilisateur à opter pour une
conduite plus souple en lui permettant de pouvoir suivre les données de son
véhicule en temps réel. Ces données étaient pour le moment uniquement
accessibles aux professionnels

65
Conclusion générale
Les travaux présentés dans ce rapport s’inscrivent dans le cadre de notre projet
de fin d’étude intitulé « Etude d’implémentation d’un diagnostic à distance des
véhicules ». Ce projet se dirige dans le cadre de notre master spécialisé en
systèmes embarqués au sein de Happy Agency à Casablanca. Cette étude a été
l’occasion pour nous d’apprendre et acquérir un ensemble de techniques et de
connaissances dans le domaine de diagnostic mécanique, informatique et
électronique. La visée de notre travail était de faire l’étude des différents
solutions existants au niveau de marché pour un diagnostic fiable et temps réels
puis choisir la meilleure on se basant sur plusieurs critères la parmi lesquelles le
coût, la fiabilité et la durabilité. Notre étude nous amène à développer une
application de diagnostic à distance qui nous a donné l’opportunité à découvrir
des nouvelles plateformes de développement et à enrichir notre savoir et notre
expérience. Une fois nos objectifs sont fixés une étude générale sur le diagnostic
automobile a été fait, on a assisté aussi à plusieurs séances de diagnostic
automobile au niveau de l’unité mécanique à base de l’OBD, après nous avons
enchaîné avec la conception et choisir les composants électroniques compatible
à nos besoins afin de mener à bien notre projet, nous avons procédé à la phase
de réalisation au cours de laquelle nous nous somme familiarisés avec le langage
de programmation java et python. En effet, le résultat de notre travail durant la
période de stage est la visualisation et consultation des données fourni par le
calculateur, nous somme par ailleurs convaincus que le travail élaboré n’est
qu’une étape primaire des études plus approfondies.

Pour conclure, ce projet nous a permis de découvrir de nouvelles choses comme:

la gestion d’un projet, le travail en équipe, la démarche à suivre pour arriver au
bout d’un projet, certaines nouvelles méthodes. De plus, cela nous a permis
d’approfondir nos connaissances en informatique et en langage java, ainsi que la
création d’une application mobile Android. Malgré les difficultés encourues,
nous avons pu finir notre application, dans de bonnes conditions.

66
 Bibliographie

https://l.facebook.com/l.php?u=https%3A%2F%2Fweb.maths.unsw.edu.au%2F
~lafaye%2FCCM%2Finternet%2Fhttp.htm%3Ffbclid%3DIwAR3JPnrdkwSz4jA
AzOV_3jAPbyr5UswpQkGwwfxj_WOibM4CdWGMnxmHUfo&h=AT3ZWV8Ox
wY436ncjnnz4pWn5B8laPWxuwNrhI6fHff2XebTl9V2Pezbo7fYxG6ihCfMY6q1Z
oSXM6ZaQ3AkCLdsS_DbqCLhg5rdVkSOIYHV5auxdj0uwZLlkXl_hMJXBwWv

http://digidiag.eu/digidiagwp/

http://www.projetsgeii.iutmulhouse.uha.fr/application-mobile-qui-permet-
lexploitation-de-donnees-en-temps-reel-dune-voiture/

https://github.com/

https://openclassrooms.com/fr/courses/1056721-des-applications-ultra-rapides-
avec-node-js
https://fr.atlassian.com/software/jira/landing?&aceid=&adposition=1t1&adgroup=61086479219&campaign=1
602108686&creative=331342227339&device=c&keyword=logiciel%20de%20gestion%20de%20projet%20en%2
0ligne&matchtype=b&network=g&placement=&ds_kids=p37928194418&ds_e=GOOGLE&ds_eid=70000000155
0060&ds_e1=GOOGLE&gclid=CjwKCAjw04vpBRB3EiwA0IieaqhrdZGSdjNK3fkNn8QwIJGe0dQw66OIG57D9VVLNi
_36N2zqhvBSxoCAqIQAvD_BwE&gclsrc=aw.ds

67