Monia & Nesrine

Mmoire de projet denvergure

Pour lobtention de

Diplme National DIngnieur

Spcialit: Informatique Applique

Sujet

Conception et ralisation dun systme de maintenanceet de contrle des vhicules distance

Soutenu le 21 Juin 2008 par :

Nesrine HARRATH

Monia ETTOUIL

Encadr par Membres de jury

M. Ridha BOUALLEGUE M. Ridha BOUALLEGUE (Prsident)

Mme. Rim GUEDRIA

M. Lotfi HAMROUNI

Anne Universitaire 2007/2008

18 Janvier BAB JEDID 4000 Sousse, Tunisiewww.eniso.rnu.tn [email protected] [email protected]

Tel: +216 73 220 664 +216 73 220 664 665 Fax: +216 73 220 470

Projet dEnvergure Tldiagnostic des vhicules

2


3

Ddicaces

Dieu merci

mon cher pre Belgacem et ma mre Aicha,

Pour leurs soutiens moral et financier durant mes tudes,

Pour lducation et le grand amour dont ils mont entour depuis ma naissance,

Et pour leurs patiences et leurs sacrifices,

mon frre Yahia,

mes surs Najia, Lamya, Amel, Radhia et Ahlem,

ma binme Nesrine,

Ziko pour son soutien moral durant ce projet,

mes amies Mdalela, Jamila, Massaouda, Majida, Awatef et Amina

tous ceux qui mont aid,

tous ceux que jaime, tous ceux qui maiment,

Je ddie ce modeste travail.

Monia


4

Ddicaces la mmoire de mon pre Mohamed

ma chre mre Mariouma

Pour son soutien moral durant mes tudes,

Et pour sa patience et ses sacrifices,

mon cher frre et ami Bad

Pour son soutien moral et financier tout au long de mes tudes

mon frre Imed et sa femme Zakia

tous mes frres Samyra, Sami et Otta

ma sur Leila et son mari Khaled

ma binme Monia

A mes chers Wasoula, Rabouba, Chouchou, Ouba, Douma, Souma et Hama

mes chers amies Rim, Rawzeta et Nesrine

Je ddie ce modeste travail

Nesrine


5

Remerciements

La rdaction de ce manuscrit de mmoire touche sa fin et clt un

travail tal sur deux annes.

Au terme de ce rapport de projet de fin dtude nous tenons

exprimer notre profonde reconnaissance tous ceux qui, de prs ou de

loin, nous ont aids llaboration de ce prsent travail et ont prsent

leur soutien moral.

Nous tenons ici remercier particulirement M.Bouallegue Ridha pour

son encadrement et son aide tout au long de ce mmoire pour ses

claircissements scientifiques pertinents, pour ses remarques

constructives et les recadrages indispensables tout au long de lavance

de ce projet.

Nous tenons galement souligner sa gentillesse et sa disponibilit

malgr ses nombreuses fonctions administratives.

Nous tenons de plus remercier Mme.Rim Guedria davoir aimablement

accept la charge de rapporteur, ainsi que M.Lotfi Hamrouni pour avoir

particip notre jury de mmoire.

Nous remercions galement toutes les personnes que nous avons

ctoyes ces deux annes, tout le personnel de lENISo ainsi que les

enseignants.


6

Rsum

Les garagistes ont troqu leurs cls molette contre des ordinateurs croire que coup de lapanne est devenu une stratgie de l'ingnieur informatique. Avec la multiplication des

fonctions de scurit et de confort, et les micro-ordinateurs embarqus qu'elles impliquent,

impossible dsormais de comprendre ce qui se passe sous le capot. A moins de se munir de

l'outil de diagnostic informatique adquat. Dans ce projet, nous montrerons que les systmes

mcatroniques complexes, prsentent certaines caractristiques utiles pour l'observation et la

commande. La possibilit de reprsenter le systme sous forme de sous systmes

interconnects continus, discrets ou hybrides permet d'exploiter les proprits physiques et

d'amliorer l'observabilit et la contrlabilit.

Ces informations seront utiles pour le diagnostic. La tche de diagnostic consiste dtecterles anomalies intervenant sur un systme puis expliquer ces erreurs en indiquant les

composants pouvant tre fautifs. Elle doit tre faite distance via le rseau GPRS permettant

ainsi un mcanicien distant de superviser le vhicule, dintervenir pour rparer les

anomalies si cest possible ou bien envoyer des messages dalertes au conducteur pour

intervenir immdiatement lui-mme ou passer vers le mcanicien le plus proche. Notre

travail consiste donc raliser les trois tches suivantes :

1) Programmer le module GM862 pour pouvoir envoyer et recevoir des donnes entre le

tlmcanicien et le vhicule.

2) Programmer les modes de communication entre le kit de test et le vhicule dune part et

le kit et le rseau de communication GPRS dune autre part.

3) Crer un site web qui contient une reprsentation de notre projet sous forme de pages

web facilitant ainsi tout abonn la navigation sur le site, linscription et la dcouverte de

nos services offerts dans le domaine de diagnostic.

Mots ClefEtat du vhicule, supervision, aide la conduite, dtection de dfauts, envoie SMS, message

dalerte, gestion et enregistrement sur une base de donnes, communication avec le module

GM862, application web, accs site.


7

Abstract

Mechanics have exchange their open-end wrenches adjustable counters computers, tobelieve that blow of the breakdown became a strategy of the data-processing engineer.

With the multiplication of the functions of safety and comfort and the microcomputers

embedded that they imply impossible from now on to include/understand what occurs

under the cap. Unless providing itself with the tool for adequate data-processing diagnosis.

In this project we will show that the complex mechanic systems show certain useful

characteristics for the observation and the order. The possibility of representing the

system in the form of under systems inter-connect continuous discrete or hybrid allows to

exploit the physical properties and to improve observation and the control.

These information will be useful for the diagnosis. The diagnostic task consists indetecting system's anomalies then in attempting to explain those errors by indicating the

components that can be faulty. It must be done at distance via network GPRS permitting so

to a distant mechanic to supervise the vehicle, to repair anomalies so this is possible or else

to send alarms to the conductor to repair it himself or to go to the mechanic the most near.

During this project, we have to make sure that the process of diagnostic is progressing

successfully. We have so three essential tasks to do:

1) To program the module GM862 for sending and receiving data.

2) To program different windows.

3) To create our site which contains a representation of our project containing pages

facilitating so looking inside the site, making the registration and discovering our services.

Keywords

State of the vehicle, supervision, help to the leadership, default detection, sending SMS,

message of alert, management and registration data bases , communication with the kit

GM862, web application, web site.


8

Sommaire

Introduction gnrale ................................................................................................................................14

Partie1 :Prsentation gnrale du projet ...............................................................................................16

I. Objectifs du projet ..................................................................................................................................................17

II. Organisation, structures et mode de fonctionnement ............................................................................21

III. Les principes du projet ....................................................................................................................................22

IV. Contexte du projet et dfinition globale des besoins..........................................................................22

1. Contexte du projet............................................................................................................................................. 22

2. Dfinition gnrale des besoins...................................................................................................................23

3. Planification des tches...................................................................................................................................25

Partie 2 : Conception de lapplication ..................................................................................................27

I. Introduction ..............................................................................................................................................................28

II. Conception de la base de donnes ...................................................................................................................28

1. Le modle conceptuel de donnes (MCD) ............................................................................................... 28

1.1 Introduction ........................................................................................................................................................... 28

1.2 Dmarche dlaboration du schma conceptuel de donnes.............................................................29

1.3 Le MCD Conu........................................................................................................................................................ 30

2. Le modle physique de donnes (MPD)...................................................................................................33

2.1 Introduction ........................................................................................................................................................... 33

2.2 Le MPD conu ........................................................................................................................................................ 33

III. Conception UML .................................................................................................................................................35

1. Dfinition............................................................................................................................................................... 35

2. Diagrammes utiliss ......................................................................................................................................... 35

2.1 Diagramme de cas dutilisation ...............................................................................................................36

2.1.1 lments des diagrammes de cas dutilisation ............................................................................36

2.1.2 Ralisation du diagramme.........................................................................................................................38

2.2 Le diagramme de squence ......................................................................................................................40

2.2.1 Reprsentation des messages ........................................................................................................40

2.2.2 Ralisation du diagramme.................................................................................................................... 41

2.3 Diagramme de classes .................................................................................................................................44

2.3.1 Les lments de diagramme de classe.............................................................................................45

2.3.2 Ralisation de diagramme de classe ................................................................................................46

IV. Conclusion ............................................................................................................................................................51

Partie 3 : Ralisation de lapplication ..................................................................................................52


9

Chapitre1 : Communication RS232 .....................................................................................................53

I. Gnralits sur la communication srie........................................................................................................53

1. La communication............................................................................................................................................. 53

2. Protocoles de communication ......................................................................................................................53

3. Communication avec le circuit.....................................................................................................................54

II. Module GM862+Kit dvaluation RS232.......................................................................................................54

1. Description du module GM862 .................................................................................................................... 54

1.1 Description technique .................................................................................................................................54

1.2 Description logicielle .................................................................................................................................. 56

2. Kit dvaluation RS232 ....................................................................................................................................57

2.1 Description de la carte ................................................................................................................................57

2.2 Composition de la carte .............................................................................................................................58

3. Introduction Python...................................................................................................................................... 59

3.1 Prsentation du langage .............................................................................................................................59

3.2 Caractristiques du langage .....................................................................................................................59

III. Les interfaces de communication ...............................................................................................................63

1. Interface pour les commandes AT ..............................................................................................................64

2. Interface pour la communication srie ...................................................................................................67

2.1. Gnralits sur le logiciel Delphi ............................................................................................................67

2.2. Interface de communication .................................................................................................................... 69

Chapitre 2 : Dveloppement du site web ............................................................................................71

I. J2EE ..............................................................................................................................................................................71

1. Introduction .........................................................................................................................................................71

2. L'environnement d'excution des applications J2EE..........................................................................72

II. Base de donnes......................................................................................................................................................75

1. Introduction.........................................................................................................................................................75

2. EasyPHP.................................................................................................................................................................76

III. Hibernate ..............................................................................................................................................................76

1. Introduction .........................................................................................................................................................76

2. Architecture .........................................................................................................................................................77

3. Utilisation dans lapplication ........................................................................................................................ 79

3.3.2 Driver basepfe ....................................................................................................................................79

6.2 Lajout dHibernate ....................................................................................................................................81

IV. Struts.......................................................................................................................................................................84

1. Introduction .........................................................................................................................................................84

2. Utilisation dans lapplication ........................................................................................................................ 85

V. JSP .................................................................................................................................................................................87

1. Introduction.........................................................................................................................................................87

2. Le choix entre JSP et Servlets........................................................................................................................ 87


10

3. JSP et Struts ..........................................................................................................................................................88

VI. Le site...................................................................................................................................................................... 88

Conclusion gnrale ..................................................................................................................................97

Bibliographie ...........................................................................................................................................99


11

Liste des figures

Figure 1: La tlmatique ...............................................................................................................17

Figure 2: Concepts du projet : Supervision et Diagnostic des vhicules distance .....................18

Figure 3: Etapes de diagnostic ......................................................................................................20

Figure 4: Exemple de diagnostic local ..........................................................................................21

Figure 5: Architecture du systme de tldiagnostic ...................................................................24

Figure 6: Cycle de dveloppement en V simplifi ........................................................................25

Figure 7: Planification des tches du PFE sous forme du diagramme de GANT .........................26

Figure 8: Palette utilise pour concevoir le MCD .........................................................................30

Figure 9: Schma conceptuel de la base de donnes .....................................................................32

Figure 10: tapes de gnration du modle physique de donnes ................................................33

Figure 11: Le MPD conu .............................................................................................................34

Figure 12: Palette utilise pour concevoir le diagramme de cas d'utilisation ...............................39

Figure 13: Diagramme de Cas dutilisation de l'application web .................................................39

Figure 14: Diagramme des cas de la communication srie ...........................................................40

Figure 15: Message de squence ...................................................................................................41

Figure 16: Cration dun diagramme de squences ......................................................................41

Figure 17: Palette utilise pour concevoir le diagramme de squences ........................................42

Figure 18: Diagramme de squence du tldiagnostic ..................................................................43

Figure 19: Diagramme de squence pour la communication PC et Module GM862 ...................44

Figure 20: Structure d'une classe...................................................................................................45

Figure 21: Palette utilise pour concevoir le diagramme de classes .............................................47

Figure 22: Diagramme de Classe du tldiagnostic ......................................................................51

Figure 23: Schma dun port srie ................................................................................................53

Figure 24: Le module GM862 GSM/GPRS ..................................................................................55

Figure 25: Structure du systme embarqu ...................................................................................56

Figure 26: Fonctionnement du module GM862 ............................................................................57

Figure 27: Le kit d'valuation RS232 et les diffrents quipements............................................58

Figure 28: Installation du Python ..................................................................................................61

Figure 29: Fentre principale de Python .......................................................................................62

Figure 30: Fentre Hyperterminal .................................................................................................62

Figure 31: Insertion des paramtres de la communication srie ...................................................63

Figure 32: Vue globale de l'interface ............................................................................................64

Figure 33: Interface des commandes AT ......................................................................................65


12

Figure 34: Configuration du module GM862 ...............................................................................66

Figure 35: Interface pour la gestion des appels .............................................................................67

Figure 35: Fentre principale Delphi ............................................................................................68

Figure 36: Fentre principale pour envoie des donnes ................................................................69

Figure 37: Fentre principale la rception ..................................................................................70

Figure 38: Architecture d'une application J2EE............................................................................72

Figure 40: Configuration du projet sur Tomcat ............................................................................74

Figure 41: page daccueil de Tomcat ............................................................................................74

Figure 42: Administration dEasyPHP..........................................................................................75

Figure 43: Base de donnes "bd_pfe" ...........................................................................................76

Figure 44: Architecture simple dHibernate..................................................................................77

Figure 45: architecture complte dHibernate ...............................................................................77

Figure 46: Cration du driver "basepfe".......................................................................................80

Figure 47: tapes de connexion ....................................................................................................80

Figure 52: Architecture de struts ...................................................................................................85

Figure 53: Ajout de Struts .............................................................................................................86

Figure 54: Exemple du Struts-config.xml ...............................................................................86

Figure 55: Accueil.jsp ...................................................................................................................89

Figure 56: Prsentation de l'activit de la socit .........................................................................90

Figure 57: Page Notre quipe ........................................................................................................90

Figure 61: Formulaire pour envoie SMS.......................................................................................93

Figure 62: Authentification de l'administrateur ............................................................................94

Figure 63: Formulaire d'authentification du Tlsuperviseur .......................................................95

Figure 64: Formulaire derreur dauthentification du Tlsuperviseur .........................................95

Figure 65: Page Tlsuperviseur ...................................................................................................96


13

Liste des tableaux

Tableau 1 : Description de la classe Client .............................................................................47

Tableau 2 : Description de la classe Tl-superviseur ............................................................48

Tableau 3 : Description de la classe Technicien .....................................................................48

Tableau 4 : Description de la classe vhicule................................................................................49

Tableau 5 : Description de la classe tat .......................................................................................49


14

Introduction gnrale

a complexit des systmes embarqus bord des vhicules automobiles, ne cesse de

crotre, ainsi que le nombre de leurs interactions. Dans le pass, lautomobile tait

essentiellement compose de systmes lectriques et mcaniques jusqu' ce que le vhicule

devienne un outil indispensable pour la mobilit de lhomme. Lexigence de performance et les

contraintes de scurit, conjugus avec les nouvelles technologies, ont impos un niveau

dautomatisation plus performant, plus rigoureux et plus fiable.

Dans ce cadre, le diagnostic est un processus intressant de plus en plus les industriels qui

essaient la mise en uvre de compromis entre le niveau de qualit intrinsque associ aux outils

de diagnostics, et les efforts de dveloppement consacrs aux systmes proprement dits.

En effet, un processus de diagnostic peut permettre d'aider le rparateur en lui indiquant le

symptme et en lui fournissant une liste de composants pouvant expliquer le symptme. Ainsi,

cela rsulte en un gain de temps qui se rpercute par une diminution du cot de la rparation.

Le processus de diagnostic de sous-systmes automobiles devient de plus en plus difficile

assurer, et son informatisation renvoie un dfi technique encore suprieur, que ce soit sur un

mode embarqu ou dans le cadre dun atelier intgr. Cela dplace la difficult au niveau de la

production de logiciels de diagnostic, et pourrait apparatre comme un problme classique de

qualit logicielle. Nanmoins, il apparat que lintroduction des applications logicielles de

diagnostic sophistiques embarques bord de vhicules automobile, peut tre considre

comme une premire tape, mais ne saurait simposer en tant que solution fondamentale aux

problmes de diagnostic rencontrs sur les systmes actuels. Relever ce dfi technologique, et

identifier des solutions requirent une approche radicalement nouvelle base sur la

comprhension de la difficult de ce processus.

Les logiciels de diagnostic automobile ont pour mission de dtecter, prdire, localiser, et

identifier les dysfonctionnements sur les diffrents sous-systmes et permettre leur rparation et

leur remise en tat.

Cette affirmation vidente fournit les cls pour dterminer la nature des dfis relever :

L


15

o Les sous-systmes automobiles se dveloppent travers un niveau de complexit toujours

croissant, parce que leurs composants sont de plus en plus sophistiqus.

o Les sous systmes interagissent la fois travers leurs interactions physiques, mais aussi

travers lchange dinformations.

o Gnrer des logiciels de diagnostic susceptibles danticiper ces vnements devient de

plus en plus urgent, du fait des exigences croissantes sur le niveau de scurit des

vhicules, ainsi que leur impact sur lenvironnement,

o Les diffrents types de sous-systmes et de composants conduisent de multiples

dclinaisons, lies aux diffrents fournisseurs, conues pour diffrentes technologies,

renvoyant de nombreuses fonctionnalits, typologies de vhicules, versions, etc.., ce qui

ncessite de rendre compte de toutes ces variantes et dclinaisons dans le logiciel, et le

processus de dveloppement du logiciel.

Finalement, nous sommes confronts une tche complexe, dont les cots ne cessent de

crotre, du fait de ses aspects rptitifs. Puisque nous parlons de logiciels de diagnostic, le

recours des techniques dingnierie logicielle doit tre dun grand recours. Il faut suivre une

approche qui permet lexploitation et le traitement effectif de la connaissance et de linformation

concernant les technologies elles mmes, les sous-systmes physiques du vhicule, leurs

composants, ainsi que leurs structures.

Dans ce rapport, nous nallons pas seulement insister sur les ides cls et les fondements

scientifiques de notre application de diagnostic distance, mais nous montrerons galement les

diffrentes technologies utilises pour sa ralisation dans les paragraphes suivants, en prsentant

les outils informatiques et lectroniques utiliss. Finalement, nous montrons, une description

dtaille de droulement de processus de diagnostic ainsi que les diffrents messages affichs du

ct client ainsi que de ct tlmcanicien.


16

Partie1 :Prsentation gnrale du

projet


17

Partie 1 : Prsentation gnrale du projet

I. Objectifs du projet

L'avnement des technologies permettant de communiquer en temps rel avec des objets se

dplaant librement a rendu possible - et donc souhaitable le dveloppement de systmes

d'information grant des donnes "mobiles''. Cette communication est double sens. Le

dveloppement des outils de communication sans fil, notamment reprsent par l'explosion du

march des tlphones portables multiplie les changes d'informations entre units mobiles et

permet la transmission au systme central d'informations prcises sur la position, la direction, la

vitesse ainsi que ltat des objets mobiles.

Figure 1: La tlmatique

En tenant compte de ces diffrentes observations, le projet consistera dvelopper une

infrastructure de diagnostic embarque, qui permettra de suivre le comportement du vhicule, et

une infrastructure dbarque, qui permettra d'amliorer en affinant le diagnostic gnr par les

outils embarqus. Ainsi, notre projet se propose trois objectifs majeurs :

Dfinir l'architecture d'un environnement permettant le dploiement et l'excution

d'outils de diagnostic volutifs au sein du vhicule. Les langages orients objet JAVA

et Delphi ont t slectionns pour le dveloppement de l'environnement ainsi que le

langage Python pour la programmation des commandes AT.

Elaborer des mthodes formelles de diagnostic exploitants les observations effectuesen temps rel par la partie embarque.


18

Enregistrer les diffrentes donnes sur un site web afin de permettre la fois

linscription, la navigation aux diffrents clients y compris tlsuperviseurs,

conducteurs et techniciens et lexcution de la tche de diagnostic par ladministrateur

et ses partenaires.

Les diffrents objectifs de notre projet ainsi que les aspects lis au diagnostic distant peuvent tre

rsums dans le schma suivant (Figure 2) :

Figure 2: Concepts du projet : Supervision et Diagnostic des vhicules distance

Le tldiagnostic :

Le tldiagnostic par internet permet, en cas de difficult ou de panne rencontres par le

conducteur, daccder au vhicule et de procder directement au diagnostic voire deffectuer

immdiatement les mesures correctives permettant la remise en route du matriel distance.

Ceci bien sr ne pouvant seffectuer quavec accord pralable du client. Le tldiagnostic par

internet permet au tlsuperviseur davoir la visualisation instantane de ltat du vhicule et de

lensemble de donnes transmises.


19

Notre projet permet au tlsuperviseur, deffectuer un diagnostic immdiat et de remdier

instantanment au problme. Pour arriver enfin dterminer lanomalie et la rparer au niveau

du vhicule, le processus de diagnostic passe par les tapes suivantes :

1 Accueillir le client

Recueillir les informations du client et complter le contrat de rparation par

inscription du client dans notre site. Ca lui permet de choisir son tlsuperviseur.

Collecter et analyser les donnes ncessaires lintervention.

Apporter un conseil technique au client.

2 Contrler et Diagnostiquer

Vrifier les symptmes dcrits par la carte. mettre des hypothses sur le dysfonctionnement en prenant en compte les contraintes

lies aux conditions de fonctionnement.

Mettre en scurit le vhicule et/ou ses systmes. Slectionner les contrles, les mesures, les essais raliser.

Mesurer, contrler les caractristiques mcaniques, hydrauliques, pneumatiques et

lectriques.

Mettre enuvre un matriel daide au diagnostic.

Interprter les rsultats et identifier llment dfectueux.

Apprcier si lorigine du dysfonctionnement a pu entraner des consquences sur

dautres composants.

Dduire lintervention raliser.

3 Assurer la maintenance

Appliquer la procdure de maintenance prconise. Dposer, reposer les organes, les lments du systme concern.

Dmonter, remonter les organes, les lments du systme concern.

Remettre en conformit les organes, les lments conformment aux procduresconstructeur.

Contrler les performances du vhicule.

Mettre en conformit le vhicule avec les normes et prconisations du constructeur.

Se tenir inform des volutions techniques. Appliquer lautocontrle son activit.


20

4 Restituer le vhicule

Rendre compte de lintervention ralise.

Fournir les lments ncessaires la facturation. Informer le client dventuelles interventions prvoir.

La figure ci-dessous rsume bien les tapes du diagnostic:

Figure 3: Etapes de diagnostic

Les fichiers du client peuvent tre tlchargs pour permettre une analyse rapide. Pour plus de

confidentialit, le tlsuperviseur peut galement partager les applications de son propre poste de

travail avec le conducteur client afin de lui expliquer des manipulations particulires par envoie

dun SMS. Le tldiagnostic par internet facilite lanalyse prcise et lidentification des

composants dfectueux sans dplacement sur scne. Lintervention du technicien est alors

programme en fonction de la livraison de la pice incrimine. Le dpannage est effectif ds la

premire intervention.


21

La figure ci-dessous illustre un exemple concrt de droulement de processus de diagnostic mais

localement par utilisation dun PC.

Figure 4: Exemple de diagnostic local

II.Organisation, structures et mode de fonctionnement

La premire runion tenue lanne prcdente avec notre encadreur monsieur Ridha lcole.

Nous avons ainsi exprim les premires pistes de recherches explorer car le sujet tait novateur

dans le domaine des automobiles et des communications radio. Au cours des runions suivantes,

nous avons ainsi montr que ce domaine de recherche se formalisait puisque les pistes de

recherche se sont affines, que les travaux respectifs dbouchent tous sur une application relle

(transport, contrle de ltat du vhicule, diagnostic distance, ) et que lintrt de cette

thmatique se renforce.

Suite ces rencontres, nous avons discern deux orientations de recherche :

Modlisation de la mobilit, structuration et interrogation de donnes TR (temps rel),

Architecture de Systmes dInformation TR et mobile (embarqu) et communication des

donnes TR.

Les applications vises sont :

La collection des donnes issues des diffrents calculateurs vers le circuit embarqu,

Envoie des donnes en temps rel vers un serveur distant,

Ralisation de la tche de diagnostic distante par le tlsuperviseur concern.

Durant ce semestre, nous avons abord une nouvelle solution : Remplacer le vhicule par une

interface dveloppe par loutil Delphi, qui dfinit des champs pour saisir les tats des diffrents

composants du vhicule et les envoyer par une liaison RS232 vers le module GM862. Dans ce

cas nous naurons pas besoin de comprendre ni le fonctionnement des bus CAN ni le nom de

protocole de communication.


22

III. Les principes du projet

Le projet vise dvelopper un systme dinformation intgr ddi la supervision et au

diagnostic des vhicules. Lampleur du projet et la diversit des aspects dont il traite, imposent

une mthodologie de travail rsume par quelques principes suivre tout au long des tapes de

dveloppement du projet :

Convivialit: le systme, dont nous avons conu une partie, est destin des utilisateursde diverses disciplines utilisant les automobiles dont une partie nest forcment

familiarise avec les outils informatiques et lectroniques intgrs lintrieur du

vhicule. Il faut donc leur offrir un systme autonome qui se charge de tout pour

transmettre linformation sur le vhicule vers le tlsuperviseur qui se charge, grce

des interfaces conviviales et simple utiliser, de superviser ltat du vhicule, en plus

linformation pertinente doit tre facilement accessible. Ainsi un travail dinterface

Homme-Machine est particulirement prsent lors du dveloppement du systme.

Portabilit: Afin de permettre un large nombre de bnficiaires daccder au systme

intgr, ce dernier doit pouvoir tre support par les diffrentes plates formes utilises.

Ainsi le dveloppement se base essentiellement sur des outils portables notamment le

langage JAVA, Delphi et loutil Easy PHP afin que le systme puisse tre utilis sur des

plates formes htrognes.

Modularit: La conception du systme repose sur le modle Orient Objet, lutilisation dulangage de programmation Oriente Objet JAVA et de loutil pour la cration de bases

de donnes Easy PHP permet de tirer profit des points forts de lOrient Objet :

rutilisation, polymorphisme.

Robustesse : Le systme intgre des logiciels de calcul puissant capables de traiter des

quantits normes de donnes, ces logiciels doivent pouvoir assurer des rsultats

efficaces et fiables.

IV. Contexte du projet et dfinition globale des besoins

1. Contexte du projet

Le projet vise dvelopper un systme dinformation intgr, comprenant plusieurs

interfaces de communication et daffichage dinformations afin de prsenter un

support daide la dcision assez complet au tlsuperviseur.

Ainsi, notre rle essentiel, dans ce projet, est de concevoir et de raliser avec les

applicatifs une plate forme capable dintgrer tous les outils de travail ncessaires la


23

supervision et au diagnostic afin de disposer dun environnement de travail organis et

complet. Notre projet denvergure sinscrit dans ce cadre.

2. Dfinition gnrale des besoins

Lindustrie automobile a connu une volution qui consiste en lintroduction massivede llectronique sous la forme des calculateurs embarqus assurant en gnral des

fonctions de contrle, de commande et de rgulation. A cause de cette volution les

actions de rparation et de prvention deviennent de plus en plus complexes et font

appel des connaissances de plus en plus varies et labores. Des outils et des

logiciels sont dvelopps afin daider les garagistes dans lanalyse de panne et de la

rparation de ces composants lectroniques et surtout lorsque ceci se fait distance et

par internet. Comme a le conducteur ne sera plus risqu de se trouver dans une

situation grave en quelques kilomtres loin du garagiste le plus proche, il ne doit pas

craindre tout vnement urgent qui peut arriver tout instant qui peut menacer son

vhicule. Notre systme est l pour superviser ltat du vhicule et informer le

tlsuperviseur de tout vnement brusque pour intervenir. Notre systme a donc pour

rle dintgrer plusieurs sous systmes la fois htrognes et complmentaires afin

de prsenter un espace de travail puissant et complet au tlsuperviseur.

Les principales fonctionnalits de ce systme sont les suivantes :

Acquisition des donnes htrognes (donnes sur ltat du moteur, delallumage, vitesse, bougies, temprature..) transmis du PC vers la carte

GM862.

Transfert des donnes via le rseau GSM vers un ordinateur distant (celui dutlsuperviseur).

Rception et organisation de ces donnes dans un site web cre par les logiciels dedveloppement et de gestion de bases de donnes JAVA et Easy PHP.

Envoie dun message dalerte vers le conducteur dans le cas dune panne.


24

Larchitecture des diffrents sous systmes de notre application peut tre illustre par la figure

suivante :

Figure 5: Architecture du systme de tldiagnostic

A partir de ce schma, nous pouvons dire que notre systme permet de coordonner, dune part,

les diffrents composants logiciels propres lapplication entre eux, et dautre part, ces

logiciels et les autres systmes dinformations externes ou gnriques (SGBD, le modem, le

rseau GPRS).

Pour rpondre ces besoins, deux principaux objectifs ont t fix :

Le dveloppement dune application stand alone grant ces diffrents composantslogiciels et offrant un espace de travail complet aux utilisateurs.

Le dveloppement dun ensemble dinterfaces offrant des fonctionnalits quivalentes enmode client serveur et permettant ainsi un large nombre de mcaniciens de tirer profit

de la puissance des outils de travail disponibles.

La plate forme ralise a t le dveloppement dun prototype dapplication Stand Alone

intgrant des simulateurs numriques et des composants logiciels relatifs au traitement et au

stockage des donnes ainsi qu la visualisation graphique. Ces deux besoins qui font lobjet de

notre PFE seront plus dtaills dans la partie suivante.


25

3. Planification des tches

Afin de mieux grer le droulement de notre PFE, nous nous sommes bases sur un cycle de

dveloppement en V (figure 5) ; en effet, outre la simplicit de cette approche, elle prsente

plusieurs avantages :

Meilleure dfinition des besoins.

Validation intgre et planifie du cycle de dveloppement.

Prsence de points de contrle tout au long du cycle.

Importance des tests.

Figure 6: Cycle de dveloppement en V simplifi

Dans les diffrentes tches indpendantes du projet, nous avons essay autant que peut de

respecter cette approche.


26

Le schma (Figure 7) suivant explique globalement la rpartition des diffrentes tches et leur

planification sur la dure de ralisation du projet : Nous avons commenc ds lanne prcdente

par une tude gnrale du projet : tude bibliographique et tude de lexistant. Au dbut de cette

anne nous avons commenc la conception et le dveloppement de la solution.

Figure 7: Planification des tches du PFE sous forme du diagramme de GANT


27

Partie 2 : Conception de lapplication


28

Partie 2: Conception de lapplication

I. Introduction

Dans ce chapitre, nous allons faire la conception de notre application. Le premier chapitre sera

consacr la conception de la base de donnes, le deuxime sera une conception UML (Le

Langage de Modlisation Unifi) vu quil est adapt toutes les phases de dveloppement et

compatible avec tout les techniques de ralisation et dfini plusieurs type de digrammes dont

trois sont les plus utilis et finalement le troisime chapitre prsente la ralisation de

lapplication.

II.Conception de la base de donnes

1. Le modle conceptuel de donnes (MCD)

1.1 Introduction

Avant de construire la base de donnes et de saisir et enregistrer les donnes, il convient de

concevoir le modle conceptuel de donnes. Un modle conceptuel de donnes (MCD) est un

schma qui a pour but d'crire de faon formelle les donnes qui seront utilises par le systme

d'information. Il s'agit donc d'une reprsentation des donnes, facilement comprhensible,

permettant de dcrire le systme d'information l'aide d'entits.

Une entit est la reprsentation d'un lment matriel ou immatriel ayant un rle dans le

systme que l'on dsire dcrire. On appelle classe d'entit un ensemble compos d'entits de

mme type, c'est--dire dont la dfinition est la mme. Le classement des entits au sein d'une

classe s'appelle classification (ou abstraction). Une entit est une instanciation de la classe.

Chaque entit est compose de proprits, donnes lmentaires permettant de la dcrire.

Prenons par exemple un ordinateur de la marque DELL, un autre de la marque Siemens et un

troisime IBM. Il s'agit de 3 entits faisant partie d'une classe d'entit que l'on pourrait appeler

Ordinateur. Lordinateur DELL est donc une instanciation de la classe Ordinateur. Chaque entit

peut possder les proprits vitesse de microprocesseur, taille du disque dure et mmoire RAM

propres lui. Les classes d'entits sont reprsentes par un rectangle.

Ce rectangle est spar en deux champs :


29

le champ du haut contient le libell. Ce libell est gnralement une abrviation pour

une raison de simplification de l'criture. Il s'agit par contre de vrifier qu' chaque

classe d'entit correspond un et un seul libell, et rciproquement.

le champ du bas contient la liste des proprits de la classe d'entit

Une relation (appele aussi association) reprsente les liens smantiques qui peuvent exister

entre plusieurs entits. Une classe de relation contient donc toutes les relations de mme type

(qui relient donc des entits appartenant des mmes classes d'entit). Une classe de relation

peut lier plus de deux classes d'entit. Les classes de relations sont reprsentes par des

hexagones (ou des ellipses) dont l'intitul dcrit le type de relation qui relie les classes d'entit

(gnralement un verbe). Les cardinalits permettent de caractriser le lien qui existe entre une

entit et la relation laquelle elle est relie. La cardinalit d'une relation est compose d'un

couple comportant une borne maximale et une borne minimale, intervalle dans lequel la

cardinalit d'une entit peut prendre sa valeur :

La borne minimale (gnralement 0 ou 1) dcrit le nombre minimum de fois qu'une entit

peut participer une relation.

La borne maximale (gnralement 1 ou n) dcrit le nombre maximum de fois qu'uneentit peut participer une relation.

Un identifiant (ou encore cl de lentit) est un ensemble de proprits (une ou plusieurs)

permettant de dsigner une et une seule entit. La dfinition originale est la suivante :

L'identifiant est une proprit particulire d'un objet telle qu'il n'existe pas deux occurrences de

cet objet pour lesquelles cette proprit pourrait prendre une mme valeur. Ainsi, chaque classe

d'entit doit possder au moins un attribut identifiant, et l'ensemble de ses attributs identifiants

doivent tre renseigns la cration de l'entit.

1.2 Dmarche dlaboration du schma conceptuel de donnes

Pour laborer un schma conceptuel, il faut suivre les tapes suivantes :

Identifier les entits

Regrouper autour dune mme entit tous ces caractristiques (attribut) : dterminerles dpendances fonctionnelles.

Choisir la cl de type entit.

Identifier les relations entre les entits


30

Des vnements du mode rel font parfois intervenir plusieurs entits ce qui peutmatrialiser les relations correspondantes. Plusieurs associations peuvent tre existes

entre deux entits : un vnement peut affecter une entit ou une relation

Prciser les cardinalits

Slectionner les lments pertinents

Il nest pas ncessaire que tout les entits et les relations peroivent une image dans lesystme : il ne faut pas retenir que les attributs qui prsentent un intrt.

Dessiner le modle conceptuel de donnes :

Placer les entits qui sont en relation proximit les une des autres.

Indiquer les cardinalits.

Souligner lidentifiant.

1.3 Le MCD Conu

La base de donnes que nous allons construire couvre toutes les ressources quutilise le tl-

superviseur pour atteindre ltat du vhicule. Pour ce la nous avons utilis la palette suivante :

Figure 8: Palette utilise pour concevoir le MCD

Entit

Association

Lien dassociation

Hritage


31

Pour raliser les classes suivantes :

client

Cette classe contient toutes les informations concernant les clients, tel que numro de la carte

didentit qui sera la cl primaire de celle-ci.

Tl superviseur

Puisque le tl-superviseur, pour ladministrateur de lapplication, nest autre quun client, cette

classe sera hrite de la classe prcdente. Chaque tl-superviseur doit avoir un mot de passe

pour accder son compte.

Technicien

Comme le tl-superviseur, le technicien est un client qui doit avoir son mot de passe.

vhicule

Cette classe couvre les diffrents types de vhicules diagnostiqus ou pas. Cette classe sera

identifie par le numro du matricule.

tat

On peut dire que cette classe est la plut importante dans la base de donnes puisquelle contient

ltat de chaque vhicule.


32

1,1

1,n

0,n

1,n

1,1

0,n1,1

1,10,n

1,n 0,n

0,n

0,n

1,1

cl ient

cin_clientnom_clientprenom_clientadresse_clientemail_cl ienttelephone_clientgsm_client

EntierTexteTexteTexteTexteTexteTexte

cin_client

vehicule

matricule_vehnaturedate_diag

TexteTexteDate

matricule_veh

telesuperviseur

cin_telesupnom_telesupprenom_telesupadresse_telesupemail_telesuptelephone_telesupgsm_telesupmotPass_telesup

EntierTexteTexteTexteTexteTexteTexteTexte

cin_telesup

technicien

cin_technom_techprenom_techadresse_techemail_techtelephone_techgsm_techmotPass_tech

EntierTexteTexteTexteTexteTexteTexteTexte

cin_tech

possede

avoir

gerer_distance

inscrire

contacter

inscrire1

gerer_direct

Etat

code_etatetat_eauetat_huileetat_carburateuretat_rouesetat_pompe-a-essenceetat_Bougietat_Feux-avantetat-Feux-arrireetat_alternateuretat_allumage

NumriqueTexteTexteTexteTexteTexteTexteTexteTexteTexteTexte

code_etat

Figure 9: Schma conceptuel de la base de donnes


33

2. Le modle physique de donnes (MPD)

2.1 Introduction

Le MPD dfinit la configuration physique de la base de donnes et permet d'en connatre les

dtails. Ce modle prend en compte la fois les structures de stockage du logiciel et celles des

donnes.

2.2 Le MPD conu

Aprs la ralisation du modle conceptuel de donnes loutil AMC Power Design permet de

gnrer automatiquement le modle physique de donnes, aprs le passage par ces tapes :

Figure 10: tapes de gnration du modle physique de donnes

Une fois nous choisissons les paramtres du diagramme MPD, nous obtenons le modle ci-

dessous :


34

FK_VEHICULE_POSSEDE_CLIENT

FK_ETAT_AVOIR_VEHICULE

FK_VEHICULE_GERER_DIS_TELESUPE

FK_CLIENT_INSCRIRE_TELESUPE

FK_TECHNICI_INSCRIRE1_TELESUPE

FK_GERER_DI_GERER_DIR_TECHNICI

FK_CONTACTE_CONTACTER_CLIENT

FK_GERER_DI_GERER_DIR_VEHICULE

FK_CONTACTE_CONTACTER_TECHNICI

client

cin_clientcin_telesupnom_clientprenom_clientadresse_clientemail_clienttelephone_clientgsm_client

integerintegerlong varcharlong varcharlong varcharlong varcharlong varcharlong varchar

vehicule

matricule_vehcin_clientcin_telesupnaturedate_diag

long varcharintegerintegerlong varchardate

telesuperviseur

cin_telesupnom_telesupprenom_telesupadresse_telesupemail_telesuptelephone_telesupgsm_telesupmotPass_telesup

integerlong varcharlong varcharlong varcharlong varcharlong varcharlong varcharlong varchar

technicien

cin_techcin_telesupnom_techprenom_techadresse_techemail_techtelephone_techgsm_techmotPass_tech

integerintegerlong varcharlong varcharlong varcharlong varcharlong varcharlong varcharlong varchar

Etat

code_etatmatricule_vehetat_eauetat_huileetat_carburateuretat_rouesetat_pompe-a-essenceetat_Bougietat_Feux-avantetat-Feux-arrireetat_alternateuretat_allumage

numericlong varcharlong varcharlong varcharlong varcharlong varcharlong varcharlong varcharlong varcharlong varcharlong varcharlong varchar

contacter

cin_clientcin_tech

integerinteger

gerer_direct

cin_techmatricule_veh

integerlong varchar

Figure 11: Le MPD conu


35

III. Conception UML

1. Dfinition

Pour programmer une application, il ne convient pas de se lancer directement dans lcriture du

code : il faut dabord organiser les ides, les documenter, puis organiser la ralisation en

dfinissant les modules et les tapes de la ralisation. Cest cette dmarche antrieure lcriture

que lon appelle modlisation ; son produit est un modle. Le langage UML est en train de

devenir un langage de modlisation universel. UML permet un change standardis depuis la

rdaction d'un cahier des charges fonctionnel, du le travail raliser par les architectes et

dveloppeurs. En effet, la notation unifie dfinit des diagrammes nombreux et dune lecture

aise pour reprsenter les diffrents points de vue de modlisation.

Ainsi, chaque organisation est libre de choisir le processus qui lui semble le plus adapt en

fonction du type d'applications dveloppes, des habitudes de ses dveloppeurs ou encore de leur

niveau de maturit objet. De fait, UML nest pas proprement parler une mthode mais un

support versatile adaptable de nombreuses mthodes de dveloppement.

2. Diagrammes utiliss

Il est impossible de donner une reprsentation graphique complte dun logiciel, ou de tout autre

systme complexe, de mme quil est impossible de reprsenter entirement un statu ( trois

dimensions) par des photographies ( deux dimensions). Mais il est possible de donner sur un tel

systme des vues partielles, analogues chacune une photographie dun statu, et dont la

conjonction donnera une ide utilisable en pratique sans risque derreur grave. UML 2.0

comporte ainsi treize types de diagrammes reprsentant autant de vues distinctes pour

reprsenter des concepts particuliers du systme dinformation. Ils se rpartissent en deux grands

groupes :

Diagrammes structurels ou diagrammes statiques (UML Structure) :

diagramme de classes (Class diagram)

diagramme dobjets (Object diagram)

diagramme de composants (Component diagram)

diagramme de dploiement (Deployment diagram)

diagramme de paquetages (Package diagram)

diagramme de structures composites (Composite structure diagram)

Diagrammes comportementaux ou diagrammes dynamiques (UML Behavior) :


36

diagramme de cas dutilisation (Use case diagram)

diagramme dactivits (Activity diagram)

diagramme dtats-transitions (State machine diagram)

diagrammes dinteraction (Interaction diagram) :

diagramme de squence (Sequence diagram)

diagramme de communication (Communication diagram)

diagramme global dinteraction (Interaction overview diagram)

diagramme de temps (Timing diagram)

Ces diagrammes, dune utilit variable selon les cas, ne sont pas ncessairement tous produits

loccasion dune modlisation. Les plus utiles pour la matrise douvrage sont les diagrammes de

cas dutilisation, dactivits, de classes, dobjets, de squence et dtats-transitions. Les

diagrammes de composants, de dploiement et de communication sont surtout utiles pour la

matrise duvre qui ils permettent de formaliser les contraintes de la ralisation et la solution

technique.

2.1 Diagramme de cas dutilisation

Le diagramme de cas dutilisation reprsente la structure des grandes fonctionnalits ncessaires

aux utilisateurs du systme. Cest le premier diagramme du modle UML, celui o sassure la

relation entre lutilisateur et les objets que le systme met enuvre.

2.1.1 lments des diagrammes de cas dutilisation

Acteur

Un acteur est lidalisation dun rle jou par une personne externe, un processus ou une chose

qui interagit avec un systme. Il se reprsente par un petit bonhomme avec son nom inscrit

dessous.


37

Cas dutilisation

Un cas dutilisation est une unit cohrente dune fonctionnalit visible de lextrieur. Il ralise

un service de bout en bout, avec un dclenchement, un droulement et une fin, pour lacteur qui

linitie. Un cas dutilisation modlise donc un service rendu par le systme, sans imposer le

mode de ralisation de ce service et se reprsente par une ellipse et optionnellement, au-

dessus du nom, un strotype.

Relation

Relation dinclusion

Un cas A inclut un cas B si le comportement dcrit par le cas A inclut le comportement du cas

B, le cas A dpend de B. Lorsque A est sollicit, B lest obligatoirement, comme une partie de A.

Cette dpendance est symbolise par le strotype include .

Relation dextension

On dit quun cas dutilisation A tend un cas dutilisation B lorsque le cas dutilisation A peut

tre appel au cours de lexcution du cas dutilisation B. Excuter B peut ventuellement

entraner lexcution de A : contrairement linclusion, lextension est optionnelle. Cette

dpendance est symbolise par le strotype extend

Relation de gnralisation

Un cas A est une gnralisation dun cas B si B est un cas particulier de A. Cette relation de

gnralisation/spcialisation est prsente dans la plupart des diagrammes UML et se traduit par

le concept dhritage dans les langages orients objet.


38

2.1.2 Ralisation du diagramme

Aprs avoir tudi la conception UML nous avons pass la ralisation. Au dbut nous avons

cre, par loutil Sun Java Studio Enterprise 8.1 , un nouveau projet de type UML.

Ensuite, nous avons cre un diagramme de cas dutilisation

Dans la conception cas dutilisation, nous avons utilis les outils qui sont prsents ci dessus.


39

Figure 12: Palette utilise pour concevoir le diagramme de cas d'utilisation

Ceci nous permet de concevoir le diagramme des cas de notre application web ainsi que de la

communication srie entre le PC et le module GM862:

Figure 13: Diagramme de Cas dutilisation de l'application web


40

Conducteur Tlsuperviseur

Supevision du vhicule

Dtection de pannes

Envoie SMS

rpartion de dfaut

Figure 14: Diagramme des cas de la communication srie

2.2 Le diagramme de squence

Le diagramme de squence reprsente la succession chronologique des oprations ralises par

un acteur. Il indique les objets que lacteur va manipuler et les oprations qui font passer dun

objet lautre.

2.2.1 Reprsentation des messages

Un message dfinit une communication particulire entre des lignes de vie. Plusieurs types de

messages existent, les plus communs sont :

lenvoi dun signal

linvocation dune opration

La cration ou la destruction dune instance.

Graphiquement, un message synchrone se reprsente par une flche en traits pleins et

lextrmit pleine partant de la ligne de vie dun objet expditeur et allant vers celle de lobjet

cible. Ce message peut tre suivi dune rponse qui se reprsente par une flche en pointill.


41

La cration dun objet est matrialise par une flche qui pointe sur le sommet dune ligne de

vie. La destruction dun objet est matrialise par une croix qui marque la fin de la ligne de vie

de lobjet.

Figure 15: Message de squence

2.2.2 Ralisation du diagramme

Cette fois nous choisissions Sequence Diagram :

Figure 16: Cration dun diagramme de squences

Pour obtenir le diagramme de squence souhait, nous devons utiliser les outils dcrits sur la

figure suivante :


42

Figure 17: Palette utilise pour concevoir le diagramme de squences

Toute cette dmarche a t conue pour atteindre enfin ce diagramme qui reprsente une vue

claire sur le passage de linformation entre le Tlsuperviseur, le systme et la carte pour faire le

diagnostic dun

vhicule..


43

Tl superviseur

1 : Ouvrir sit e Web

2 : Demand e d e m ot de pass e

3 : sais ir mot de pass e

5 : Vrification

6 : M en u p rincipale

4 : Conn ecter labase de don nes

Si le mot de pass e

es t in correcte al ler

au 3

Si le mot de pas seest correcte pass er

7 : Saisir les param tresd u client et du s on vhicule

8 : En reg les paramtres d an s la BD

9 : Vrifier cod e tat

10 : Enreg les d ans la BD

Client :Carte G M 86 2

13 : Message de la rpon se

11 : Con sulter la carte t ravers le rseau GPRS

14 : Corriger les p an nes

12 : Voir m m oireSi tat dfectueu x et lespannes peu ven t corriger distance :14

Si tat d fectueux etles p an nes ne p euventpas corriger a dis tance :15

15 : Informer le tech nicien

16 : Contacter le c liente t corri ge r le s pannes

TechnicienAdministrateur :Base de donnes

Si pas desprob lmes : 17

17 : Enregi strer les informat ions du rapport

Figure 18: Diagramme de squence du tldiagnostic


44

Concernant le diagramme de squence modlisant la communication entre le PC et le module

GM862, il est prsent comme suit.

PC Module GM862 Conducteur/ Client

envoie donnes

ecouter

indicati onde nouveau texte

ouverture de port srie

fermeturedu port

en registremen td es do nnes

fermeture dele connexion srie

envoie des d onnesvers le serveur web

enregistrementdans u ne base

de donnes

envoie SMS

Serveur web

Figure 19: Diagramme de squence pour la communication PC et Module GM862

2.3 Diagramme de classes

Le diagramme de classes est considr comme le plus important de la modlisation oriente

objet, il est le seul obligatoire lors dune telle modlisation. Alors que le diagramme de cas

dutilisation montre un systme du point de vue des acteurs, le diagramme de classes en montre

la structure interne. Il permet de fournir une reprsentation abstraite des objets du systme qui

vont interagir ensemble pour raliser les cas dutilisation. Il est important de noter quun mme

objet peut trs bien intervenir dans la ralisation de plusieurs cas dutilisation.

Les cas dutilisation ne ralisent donc pas une partition des classes du diagramme de classes. Un

diagramme de classes nest donc pas adapt (sauf cas particulier) pour dtailler, dcomposer, ou


45

illustrer la ralisation dun cas dutilisation particulier. Il sagit dune vue statique car on ne tient

pas compte du facteur temporel dans le comportement du systme. Le diagramme de classes

modlise les concepts du domaine dapplication ainsi que les concepts internes crs de toutes

pices dans le cadre de limplmentation dune application. Chaque langage de Programmation

Orient Objets donne un moyen spcifique dimplmenter le paradigme objet (pointeurs ou pas,

hritage multiple ou pas, etc.), mais le diagramme de classes permet de modliser les classes du

systme et leurs relations indpendamment dun langage de programmation particulier. Les

principaux lments de cette vue statique sont les classes et leurs relations : association,

gnralisation et plusieurs types de dpendances, telles que la ralisation et lutilisation.

2.3.1 Les lments de diagramme de classe

classe

Une classe est la description formelle dun ensemble dobjets ayant une smantique et des

proprits communes. Elle est reprsente par un rectangle divis en trois cinq compartiments,

Le premier indique le nom de la classe, le deuxime ses attributs et le troisime ses oprations.

Nom de la classe

A ttr ibu t_ 1 : in t

A ttr ibu t_ 2 : Str ing

M th ode_1 (a r g_1 , ar g_ 2)

M th ode_2 (a r g_1 , ar g_ 2, ar g_ 3)

Figure 20: Structure d'une classe

Les attributs

Les attributs dfinissent des informations quune classe ou un objet doivent connatre. Ils

reprsentent les donnes encapsules dans les objets de cette classe. Chacune de ces informations

est dfinie par un nom, un type de donnes, une visibilit et peut tre initialis. Le nom de

lattribut doit tre unique dans la classe.

Le type de lattribut () peut tre un nom de classe, un nom dinterface ou un type de

donn prdfini. La multiplicit () dun attribut prcise le nombre de valeurs que

lattribut peut contenir.

Association

Une association est une relation entre deux classes (association binaire) ou plus (association

n-aire), qui dcrit les connexions structurelles entre leurs instances.


46

Multiplicit ou cardinalit

La multiplicit associe une terminaison dassociation, dagrgation ou de composition dclare

le nombre dobjets susceptibles doccuper la position dfinie par la terminaison dassociation.

Voici quelques exemples de multiplicit :

Exactement un : 1 ou 1..1

Plusieurs : _ ou 0.._

Au moins un : 1.._

De un six : 1..6

2.3.2 Ralisation de diagramme de classe

Pour la ouverture dun nouveau diagramme, nous avons utilis la mme procdure que celle du

digramme de squence sauf quand mais Class Diagram au lieu de Sequence Diagram .

Nous utilisons les outils suivants pour construire le diagramme final :


47

Figure 21: Palette utilise pour concevoir le diagramme de classes

a. Liste des classes

Classe client : cette classe permet la gestion des diffrents clients du tlsuperviseur

(ajout, suppression, enregistrement).

Attribut Description Type

cin_client Numro de la carte didentit de chaque client Integer

cin_telesup CIN du tlsuperviseur integer

nom_client Nom du client String

prenom_client Prnom du client String

adresse_client Numro de tlphone du client String

email_client Ladresse lectronique du client String

telephone_client Le numro du tlphone du client Number

gsm_client Le numro du GSM du client Number

Tableau 1 : Description de la classe Client


48

Classe Tl-superviseur : cette classe reprsente le tlsuperviseur du

tldiagnostic.

Attribut Description Typecin_telesup CIN du tlsuperviseur Integer

nom_telesup Nom du tlsuperviseur String

prenom_telesup Prnom du tlsuperviseur String

adresse_telesup Adresse du tlsuperviseur String

email_telesup Email du tlsuperviseur String

telephone_telesup Tlphone du tlsuperviseur Number

gsm_telesup Gsm du tlsuperviseur Number

motPasse_telesup Reprsente le mot de passe du tl-superviseur String

Tableau 2 : Description de la classe Tl-superviseur

Classe Technicien : cette classe reprsente le technicien.


cin_tech CIN du technicien integer


nom_tech Nom du technicien String

prenom_tech Prnom du technicien String

adresse_tech Adresse du technicien String

email_tech Email du technicien String

telephone_tech Tlphone du technicien Number

gsm_tech Gsm du technicien Number

motPasse_tech Reprsente le mot de passe du technicien String

Tableau 3 : Description de la classe Technicien


49

Classe vhicule : cette classe permet la gestion des diffrents types de vhicule

(ajout, suppression, enregistrement).


matricule_veh La matricule du vhicule String

cin_client CIN du client integer


nature Nature du vhicule (exp : BMW) string

date_diag Date de diagnostic du vhicule Date

Tableau 4 : Description de la classe vhicule

Classe tat : cette classe contient les diffrents tats diagnostiquer, nous allons

prsenter dans le tableau ci-dessous quelques chantillons :


code_etat code de ltat a diagnostiqu String

etat_eau Bon ou dfectueux String

date1 Date de ltat de leau Date

etat_huile Bon ou dfectueux String

date2 Date de ltat de lhuile Date

etat_carburateur Bon ou dfectueux String

date3 Date de ltat du carburateur Date

etat_roues Bon ou dfectueux String

date4 Date de ltat des roues Date

etat_pompe-a-essence Bon ou dfectueux String

date5 Date de ltat de pompe essence Date

etat_bougies Bon ou dfectueux String

date6 Date de ltat des bougies Date

Tableau 5 : Description de la classe tat

b. Rgle de relation


50

Un client possde un ou plusieurs vhicules.

Un vhicule est associ un seul client.

Un client ne peut sinscrire que chez un et un seul tl-superviseur

Un tl-superviseur peut avoir un n clients.

Un technicien ne peut sinscrire que chez un et un seul tl-superviseur.

Un tl-superviseur peut avoir un n techniciens.

Un vhicule peut avoir un ou plusieurs tats.

Un tat est associ un seul vhicule.

Un tl-superviseur peut grer distance 0 n vhicules.

Un vhicule ne peut tre gr distance que par un et un seul tl-superviseur.

Un technicien peut grer en direct 0 n vhicules.

Un vhicule peut tre gr en direct par 0 n technicien.

Un technicien peut contacter 0 n clients.

Un client peut tre contact par 0 n technicien.

c. Reprsentation

Une fois nous crons les tables utiliser, les champs relatifs chaque table et les relations entre

les diffrentes classes ou objets, nous obtenons le diagramme de classes ci-dessous qui dcrit la

relation entre les diffrents membres concerns par le processus de diagnostic : Client, Vhicule,

Etat, Technicie et, Tlsuperviseur.


51

Client

CIN_Client : in t

Nom_Client : String

Prnom_Client : String

Email_Client : String

Adresse_Client : String

Tlphone_Client : number

GSM_Client : number

Ajouter (cin ,nom, pr,email,adre,tl,gsm)

Modifier (cin,nom, pr,email,adre,tl,gsm)

Supprimer (cin)

Rechercher ( cin)

Vhicule

Matricule_Vh : String

Nature : String

Date_Diag : Date

Ajouter (mat_vh, nature)

Modifier (mat_vh, nature, date_diag)

Supprimer (mat_vh)

Rechercher ( mat_vh)

Possde1..n 1..1

Etat

Code_tat : String

Etat_eau : String

Etat_huile : String

Etat_carburateur : String

Etat_roues : String

Etat_pompe-a-essence : String

Etat_bougis : String

Etat_feux-avant : String

Etat_feux-arrire : String

Etat_alternateur : String

Etat_allumage : String

Enregistrer ()

Modifier ( code_etat )

Avoir

1. .n

1..1

Technicien

MotPasse_technicien : String

Ajouter (cin,nom, pr,email,adre,tl,gsm, motPassTech)

Connecter (nom, motPassTech)

1..1

0..n

Grer direct

Hrite 1

Hrite 2

Informer

0. .n

0..n

1. .1

0 ..n

Inscrire

1..n

0..n

Contacter

1. .1

0..n

Tl suprviseur

MotPasse_tlsuperviseur : String

Ajouter (cin,nom, pr,email,adre,tl,gsm, motPassTl)

Connecter (nom, motPassTl)

Grer distance

Figure 22: Diagramme de Classe du tldiagnostic

IV. Conclusion

La phase de conception, comme lindique son nom, permet de tracer le squelette global de

lapplication. La phase suivante sera une mise en ouvre de cette dernire.


52

Partie 3 : Ralisation de lapplication

Chapitre 1 : Communication RS232

Chapitre 2 : Dveloppement du site web


53

Chapitre1 : Communication RS232

I. Gnralits sur la communication srie

1. La communication

Le programme doit effectuer une requte pour envoyer ltat du vhicule en temps rel vers le

port srie du PC. Le port RS232 se compose de 9 broches.

Deux broches sont utilises :

Une broche qui permet lcriture : requte

Une broche pour la lecture : lecture

Pour notre application, nous nallons utiliser que la broche destine lcriture, pour envoyer des

donnes sur ltat des diffrents composants du vhicule.

Figure 23: Schma dun port srie

2. Protocoles de communication

Lcriture des informations se fait sur une seule broche. Les informations duplex sont transmises

sous forme doctets. Chaque requte commence par ladresse du circuit code sur 7 bits.

Les 4 premiers bits sont invariants, ils dfinissent ladresse du circuit. Les 3 derniers identifient le circuit dans un rseau.

Un dernier bit gnr par le PC indique le sens dans lequel seffectuent les informations.


54

Chapitre1: Communication RS232

3. Communication avec le circuit

Nous devons prciser ladresse du circuit avec lequel nous voulons communiquer. Lorsque le

circuit sidentifie comme le destinataire dune requte (7 premiers bits), il renvoie un signal au

PC qui indique quil est prt communiquer avec lui. Ensuite, le PC envoie le reste de sa

requte, et attend si besoin une rponse.

Prsentons tout dabord le circuit avec lequel nous travaillons :

II. Module GM862+Kit dvaluation RS232

1. Description du module GM862

1.1 Description technique

Ce module OEM (Original Equipement Manufactures), est un GSM/GPRS "Quad-bande" va

nous permettre de raliser un transmetteur dalarme GSM sans fil exprimental. Pour ce faire

nous utiliserons un module GSM/GPRS GM862 "Quad-band" capable de supporter les

modes de communication "voix", "fax", "Data", "SMS". Il est spcialement conu pour la

ralisation d'applications de contrle de commandes distance et opre dans les bandes 850 /

900 / 1800 et 1900 MHz. Il est dot dun :

Connecteur "MMCX" pour antenne externe et

Lecteur de carte SIM intgr, Connecteur MOLEX pour le raccordement notre platine

Ce dernier se caractrise par ses faibles dimensions associes un prix trs comptitif et une

grande simplicit de mise en uvre. Ce module se pilote au moyen dune liaison srie via descommandes "AT" et Caractris par :

Alimentation: 3,4 4,2 V (3,8 V nominal)

Consommation: < 3,5 mA Consommation moyenne en mode voix (250 mA)

Liaison srie 1200 57600 bps

Connecteur d'antenne 50 ohm


55


Voice limage du module GM862 que nous allons utiliser dans notre application.

Figure 24: Le module GM862 GSM/GPRS

Afin de simplifier la ralisation, on aura recours une platine de test spcialement conue pour

pouvoir integrer le module GSM GM862 . Cette platine comprend un tage de rgulation

ainsi quun tage de mise en forme du signal de sortie du module GSM (afin que les niveaux

logiques de celui-ci soient compatibles avec une liaison RS232. Il nous suffira alors de connecter

une alimentation cette platine, une antenne au module GSM et dutiliser un cble pour le

relier au connecteur dans vhicule. La dernire opration indispensable consistera se munir

bien videmment dune carte SIM oprationnelle que lon aura insr (hors alimentation)

dans le module GM862 grce au connecteur prvu cet effet. Le code PIN de la carte

SIM devra tre effac afin de simplifier la procdure dutilisation du module GSM.

La figure ci-dessous prsente larchitecture complte de notre systme embarqu, ainsi que les

diffrents modes dinstallation.

Avant de commencer utiliser le module il faut bien placer les composants sur le kit

dvaluation srie comme le montre la figure ci-dessous :


56


Figure 25: Structure du systme embarqu

1.2 Description logicielle

Le script python interagit avec le terminal de donnes : le module GM862 travers 4 interfaces,

possdant chacune des fonctionnalits bien dtermines.

a. Linterface MDM

Linterface MDM est la plus importante. Elle permet au script python denvoyer des commandes

AT, de recevoir des rponses et des alertes, denvoier des donnes travers le rseau et recevoir

des donnes venant du rseau pendant la connexion. Elle joue le mme rle que linterface de

ports srie, la seule diffrence est que cette interface nest pas une interface de ports srie rels,

mais une interface interne.


57


b. Linterface SER

Elle permet au script python de lire et crire sur le port srie physique rel, dans lequel on trouve

linterface des commandes. On peut lutiliser pour crire des scripts python, lorsquil nest pas

utilis pour crire ou envoyer des commandes AT

c. Linterface GPIO

Elle permet au script python de manipuler des entres sorties de faon plus rapide que les commandes.

d. Linterface MOD

Elle contient la liste des fonctions utilises.

La figure ci-dessous dcrit en quelque sorte linteraction entre les diffrents modules.

Figure 26: Fonctionnement du module GM862

2. Kit dvaluation RS232

2.1 Description de la carte

Cette carte est un quipement lectronique adapt et pouvant tre install sur tout type de

vhicules. Il est dot dune mmoire pour le stockage des donnes de diagnostic du vhicule et

un module de communication radio GSM/GPRS. Elle permet la localisation en temps rel des

dfauts dans les vhicules par lecture partir dun port srie et le transfert de ces informations

un site distant de gestion.


58


Grce ses fonctionnalits avances de gestion et de traitement rapide des donnes, cette

dernire permet aux mcaniciens doptimiser leurs oprations et de donner de la valeur ajoute

leurs activits.

Le kit dvaluation permet lintgration des diffrents composants comme lindique la figure ci-

dessous.

Figure 27: Le kit d'valuation RS232 et les diffrents quipements

2.2Composition de la carte

Le connecteur DB9

Le connecteur DB9 est une prise analogique, comportant 9 broches, de la famille des

connecteurs. Il sert essentiellement dans les liaisons sries, permettant la transmission de

donnes asynchrone selon la norme RS-232 (RS-232C). Il fait linterface entre llectronique du

module de gestion et lenvironnement externe que constitue le circuit lectrique de la voiture et

les capteurs embarqu dans la voiture dans notre cas il assure la liaison avec le PC. Il assure la

gestion et la coordination.

Le module GM 862

Ce module, qui tait dj dcrit si dessous (section 2.2), gre les diffrentes tches ralises par les

autres modules.

Antenne GSM/GPRS

Cble RS232

Alimentation

Bouton reset


59


Rgulateur

Il permet de fournir une tension continue bien stable pour une large plage de courant de sortie.

Les rsistances

Elles permettent de la protection des Leds, en limitant le courant qui les parcourt 10mA.

Les capacits

Elles sont des composants passifs de filtrage associs au rgulateur et lhorloge pour le

dcouplage des hautes frquences.

Les 2 diodes

Pour lutter contre la chute de la tension de 1.2 V parce que le module GM862 est aliment de 3.8

V ainsi que pour la protection.

3. Introduction Python

3.1 Prsentation du langage

Python est un langage portable, dynamique, extensible, gratuit, qui permet (sans l'imposer)

une approche modulaire et oriente objet de la programmation. Python est dvelopp depuis

1989 par Guido van Rossum et de nombreux contributeurs bnvoles.

3.2 Caractristiques du langage

Dtaillons un peu les principales caractristiques de Python, plus prcisment, du langage et de

ses deux implantations actuelles:

Python est portable, non seulement sur les diffrentes variantes d'Unix, mais aussi sur lesOS propritaires: MacOS, BeOS, NeXTStep, MS-DOS et les diffrentes variantes de Windows.

Python est gratuit, mais on peut l'utiliser sans restriction dans des projets commerciaux.

Python convient aussi bien des scripts d'une dizaine de lignes qu' des projets

complexes de plusieurs dizaines de milliers de lignes.


60


La syntaxe de Python est trs simple et, combine des types de donnes volus

(listes, dictionnaires,...), conduit des programmes la fois trs compacts et trs lisibles.

Python gre ses ressources (mmoire, descripteurs de fichiers...) sans intervention du

programmeur, par un mcanisme de comptage de rfrences.

Python est (optionnellement) multi-thread. Python est orient-objet. Il supporte l'hritage multiple et la surcharge des oprateurs.

Dans son modle objets, et en reprenant la terminologie de C++, toutes les mthodes sont

virtuelles.

Python intgre, comme Java ou les versions rcentes de C++, un systme d'exceptions,qui permet de simplifier considrablement la gestion des erreurs.

Python est dynamique (l'interprteur peut valuer des chanes de caractres reprsentant

des

expressions ou des instructions Python), orthogonal (un petit nombre de concepts suffit

engendrer des constructions trs riches), rflectif (il supporte la mta programmation, par

exemple la capacit pour un objet de se rajouter ou de s'enlever des attributs ou des mthodes,

ou mme de changer de classe en cours d'excution) et introspectif (un grand nombre d'outils

de dveloppement, comme le debugger ou le profiler, sont implants en Python lui-mme).

Python possde actuellement deux implmentations. L'une, interprte, dans laquelle les

programmes Python sont compils en instructions portables, puis excuts par une machine

virtuelle. L'autre gnre directement du bytecode Java.

La bibliothque standard de Python, et les paquetages contribus, donnent accs une

grande varit de services : chanes de caractres et expressions rgulires

Ce logiciel est indispensable pour lexcution de notre application, grce ce logiciel nous

pouvons crire des scripts et les implmenter directement sur le module telle que envoie

SMS .


61


Figure 28: Installation du Python


62


Figure 29: Fentre principale de Python

Po

Documents

Monia & Nesrine