Vous êtes sur la page 1sur 102

Ministre de lEnseignement Suprieur

et de la Recherche Scientifique

Universit de Carthage

Institut National des Sciences
Appliques et de Technologie

Projet de Fin dEtudes


Pour lobtention du

Diplme National dIngnieur


en Sciences Appliques et en Technologie

Filire : Rseaux Informatique et Tlcommunication


Sujet :

Mise En Place d'une Plateforme de Contrle d'une


usine base de la technologie RFID et le standard
EPCglobal
Ralis par : Wafa LAKDHAR
Entreprise daccueil :

Soutenu le 02/10/15

Responsable lentreprise : Mlle Marwa CHAMEKH


Responsable lINSAT: M. Soufiene MEJRI
M. Yassine FRIAA

Anne Universitaire : 2014/2015

Ddicace
A Mes trs chers parents Abdel Malek et Amna
En tmoignage de ma profonde gratitude et de mon incontestable reconnaissance, pour tous
les sacrifices quils font pour moi, toute la confiance quils maccordent et tout lamour dont ils
mentourent.
A Mes chers frres Zouhaier et Amine
Pour leur encouragement, et pour leur amour infini en exprimant ma gratitude et mon profond
amour.
A Mes meilleurs amies
Les mots ne suffisent gure pour exprimer lattachement, lamour et laffection que je porte
pour vous.
A Tous Mes professeurs pendant mon parcours ducatif de lcole vers luniversit.
A Tous ceux qui mont aid.

Remerciements
Je tiens tout dabord remercier ALLAH le tout puissant et misricordieux, qui ma donn
la force et la patience daccomplir ce modeste projet.
Au terme de ce travail, je voudrais remercier tous ceux qui, sans leur aide inestimable, ce
projet naurait jamais t men son terme.
Mes remerciements sadressent particulirement : Monsieur Mahfoud AOUICHRI, Directeur Gnral de la socit ITesLab, pour mavoir prodigu lhonneur de travailler avec eux.
Mon encadrante Mademoiselle Marwa CHAMEKH qui ma suggr le sujet de ce projet et
qui ma fait lhonneur de me diriger tout au long de sa ralisation.
Mes encadrants Messieurs Sofiane MEJRI et Yassine FRIAA pour le temps prcieux quils
mont gnreusement consacr.
Mon dernier mot sadresse tous les membres du jury pour lhonneur quils nous font de
participer lexamen de notre mmoire, sans oublier tous nos professeurs lINSAT pour la
formation de qualit quils nous ont prodigue tout au long de notre cursus universitaire.

ii

Table des Matires

Rsum

Liste des Figures

vi

Liste des Tableaux

viii

Introduction Gnrale
I

Prsentation du cadre du stage


1
Prsentation de la socit ITesLab . . . . . . . . . . . . . . . .
1.1
Mission . . . . . . . . . . . . . . . . . . . . . . . . . .
1.2
Schma organisationnel . . . . . . . . . . . . . . . . . .
2
Prsentation du projet . . . . . . . . . . . . . . . . . . . . . .
2.1
Cadre du projet . . . . . . . . . . . . . . . . . . . . . .
2.2
Problmatique . . . . . . . . . . . . . . . . . . . . . . .
3
Mthodologie du travail . . . . . . . . . . . . . . . . . . . . .
3.1
Le processus de dveloppement . . . . . . . . . . . . .
3.1.1
tude comparative de quelques mthodologies
3.1.2
Choix de la mthodologie Scrum . . . . . . .
3.1.3
Application de la mthodologie . . . . . . . .
3.2
Formalisme de modlisation . . . . . . . . . . . . . . .
3.3
Planification du projet . . . . . . . . . . . . . . . . . .

.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.

II Etude Pralable
1
Etat de lart . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.1
Chaine dapprovisionnement . . . . . . . . . . . . . . . . . . . . . . . .
1.2
Traabilit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.2.1
Dfinition : . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.2.2
Technologies de Traabilit . . . . . . . . . . . . . . . . . . .
1.3
Approfondissement sur la technologie RFID . . . . . . . . . . . . . . .
1.3.1
Dfinition . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.3.2
Architecture dun systme didentification par radiofrquence
1.3.3
Caractristiques des systmes RFID . . . . . . . . . . . . . .
2
Etude de lexistant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

.
.
.
.
.
.
.
.
.
.
.
.
.

3
3
4
4
4
5
5
6
6
7
7
8
9
10

.
.
.
.
.
.
.
.
.
.

11
11
12
13
13
14
14
14
15
18
24

iii

Remerciements
2.1
2.2
2.3

Prsentation de quelques solutions . . . . . . . . . . . . . . . . . . . . . . 24


Critique de lexistant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
Solution propose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

III Analyse et Spcification des besoins


1
Identification des acteurs . . . . . . . . . . . . .
2
Recueil des besoins globaux . . . . . . . . . . .
2.1
Besoins fonctionnels . . . . . . . . . . .
2.2
Besoins non fonctionnels . . . . . . . . .
2.3
Diagramme de cas dutilisation globale
3
Analyse fonctionnelle . . . . . . . . . . . . . . .
3.1
Description dtaille des cas dutilisation

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

IV Conception et architecture de la plateforme


1
Architecture globale de la plateforme . . . . . . . . . . . .
2
Architecture globale et conception du middleware . . . . .
2.1
Conception globale du middleware . . . . . . . . .
2.2
Conception dtaille du middleware . . . . . . . .
2.2.1
Diagramme de classe du middleware . .
2.2.2
Diagramme de squence dobjet . . . . . .
3
Architecture globale et conception de lapplication web . .
3.1
Conception globale de lapplication web . . . . . . .
3.2
Conception dtaille de lapplication web . . . . . .
3.2.1
Diagramme de package . . . . . . . . . . .
3.2.2
Diagramme de classe de lApplication Web
3.2.3
Diagramme de squence dobjet . . . . . .

.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.

V Implmentation de la plateforme de contrle


1
Environnement et outils de travail . . . . . . . . . . . . . . . .
1.1
Environnement matriel . . . . . . . . . . . . . . . . .
1.2
Environnement logiciel . . . . . . . . . . . . . . . . . .
1.2.1
Outils de modlisation . . . . . . . . . . . .
1.2.2
Outils de dveloppement . . . . . . . . . . . .
1.2.3
Outils de la mise en place du middleware . . .
1.2.4
Serveur dapplication . . . . . . . . . . . . . .
1.2.5
Outil dadministration de la base de donnes .

.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.
.

28
28
29
29
30
31
31
31

.
.
.
.
.
.
.
.
.
.
.
.

42
42
44
45
45
45
50
51
51
52
53
54
55

.
.
.
.
.
.
.
.

60
60
60
61
61
61
62
64
64

iv

Table des Matires

2
3

1.2.6
Conteneur Web . . . . . . . . . . . . .
1.2.7
Autres . . . . . . . . . . . . . . . . . .
1.3
Choix technologique . . . . . . . . . . . . . . .
Architecture technique de la solution . . . . . . . . . .
Travail ralis . . . . . . . . . . . . . . . . . . . . . . .
3.1
Plateforme de contrle . . . . . . . . . . . . . .
3.1.1
Emulation de lenvironnement RFID .
3.1.2
Mise en place du middleware Fosstrak
3.1.3
Lapplication web du management . .

.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.

65
66
66
67
68
69
69
69
74

Conclusion Gnrale et Perspectives

80

Bibliographie

81

Acronyme

85

Annexe

86

Liste des Figures

I.1
I.2
I.3
I.4
I.5

Architecture organisationnelle de la socit


Bte corne concernant la problmatique .
Les rles dans Scrum . . . . . . . . . . . .
Processus de dveloppement Scrum [6] . .
Diagramme de Gant . . . . . . . . . . . .

ITesLab
. . . . .
. . . . .
. . . . .
. . . . .

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

. 4
. 6
. 8
. 9
. 10

II.1 Un modle de chane dapprovisionnement [22] . . . . . . . . .


II.2 Gestion dentrept grce travers la technologie RFID [23] . .
II.3 Infrastructure de la technologie RFID [11] . . . . . . . . . . .
II.4 Etiquette RFID [18] . . . . . . . . . . . . . . . . . . . . . . .
II.5 Communication Lecteur-Tag . . . . . . . . . . . . . . . . . . .
II.6 Composants dun middleware . . . . . . . . . . . . . . . . . .
II.7 Les gammes de frquences RFID [13] . . . . . . . . . . . . . .
II.8 Architecture du rseau EPCglobal . . . . . . . . . . . . . . . .
II.9 Structure du code EPC [17] . . . . . . . . . . . . . . . . . . .
II.10 Liste des cryptographies intgr dans la version 2 du EPC Gen
II.11 Architecture de la solution ClearStream [18] . . . . . . . . . .
II.12 Architecture de la solution Hub ?ID [20] . . . . . . . . . . . .

.
.
.
.
.
.
.
.
.
2
.
.

. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
[42]
. . .
. . .

.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.

12
13
15
16
16
17
18
20
22
23
25
26

III.1 Diagramme de Cas dutilisation GLOBAL . . . . . . . . . . . . . . . . . . . . . 31


III.2 Diagramme de Cas dutilisation Administrer systme pour un administrateur 33
III.3 Diagramme de Cas dutilisation Grer Stock pour le responsable de stock. . 37
IV.1 Architecture globale de la plateforme de contrle . . . . . . . . . . . . . . . . .
IV.2 Diagramme de dploiement global . . . . . . . . . . . . . . . . . . . . . . . . .
IV.3 Architecture globale du middleware . . . . . . . . . . . . . . . . . . . . . . . .
IV.4 Diagramme de classe du middleware . . . . . . . . . . . . . . . . . . . . . . .
IV.5 Diagramme de classe du package Application de capture . . . . . . . . . . . .
IV.6 Diagramme dactivit de module de scurit . . . . . . . . . . . . . . . . . . .
IV.7 Diagramme de squence du fonctionnement du middleware . . . . . . . . . . .
IV.8 Diagramme de squence du middleware aprs lajout du module de vrification
IV.9 Architecture de lapplication web . . . . . . . . . . . . . . . . . . . . . . . . .
IV.10Diagramme de package de lapplication web . . . . . . . . . . . . . . . . . . .

.
.
.
.
.
.
.

43
44
45
46
47
49
50
51
. 52
. 53

vi

Liste des Figures


IV.11Diagramme
IV.12Diagramme
IV.13Diagramme
IV.14Diagramme
IV.15Diagramme
IV.16Diagramme

de
de
de
de
de
de

classe du package Mtier . . . . . . . . . . . . . .


classe du package Service . . . . . . . . . . . . . .
squence ajout Outillage . . . . . . . . . . . . .
squence Grer Alerte par le ResponsebleStock
squence EnvoyerNotifAndroid . . . . . . . . .
squence VisualiserMap . . . . . . . . . . . . .

V.1 Logo du Netbeans [36] . . . . . . . . . . . . . . .


V.2 Logo dEclipse [37] . . . . . . . . . . . . . . . . .
V.3 Logo dEclipse RCP & RAP Developers [34] . . .
V.4 Logo Fosstrak [30] . . . . . . . . . . . . . . . . . .
V.5 Logo Rifidi [33] . . . . . . . . . . . . . . . . . . .
V.6 Architecture technique de la plateforme . . . . . .
V.7 Prototype de lusine . . . . . . . . . . . . . . . .
V.8 de configuration du serveur de filtrage et collecte .
V.9 Interface de LLRP Commander du Fosstrak . . .
V.10 ROAccessReports du lecteur readerZon2.2 . . . .
V.11 Interface dAccueil . . . . . . . . . . . . . . . . .
V.12 Interface dauthentification . . . . . . . . . . . . .
V.13 Interface despace Administrateur . . . . . . . . .
V.14 Interface denregistrement au service GCM . . . .
V.15 Notification par lapplication Androde . . . . . .
V.16 Interface de Gestion des alertes . . . . . . . . . .
V.17 Interface du prototype linstant "t" . . . . . . .
V.18 Le Map visualis linstant "t" . . . . . . . . . .
V.19 Interface de visualisation des logs . . . . . . . . .

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

54
55
56
57
58
59

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

61
62
62
63
64
68
69
72
73
73
74
75
75
76
77
77
78
78
79

A.1 Fichier ECSpec.xml . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86


A.2 Fichier LRSpec.xml . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
A.3 ROSpec.xml . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91

vii

Liste des Tableaux

I.1

Tableau comparatif entre les diffrentes mthodologies . . . . . . . . . . . . . . .

II.1 Les lments de larchitecture du rseau EPCglobal . . . . . . . . . . . . . . . . 21


II.2 Tableau comparatif entre les diffrentes mthodologies . . . . . . . . . . . . . . . 27
III.1
III.2
III.3
III.4
III.5
III.6
III.7
III.8

Description
Description
Description
Description
Description
Description
Description
Description

des acteurs principaux . . . . . . . . . . . . . . . . . . . . . . . .


du cas dutilisation sauthentifier . . . . . . . . . . . . . . . .
du cas dutilisation Gnrer les ractions de rponse aux alertes
du cas dutilisation configurer les seuils de dclanchement . . . .
du cas dutilisation Ajouter employ . . . . . . . . . . . . . . .
du cas dutilisation Gnrer le rapport de marchandise dE/S .
du cas dutilisation Grer les cellules de production . . . . . . .
du cas dutilisation Visualiser lhistorique des mouvements . .

.
.
.
.
.
.
.
.

29
32
34
35
36
38
39
40

V.1 Caractristiques de quelques exemples dintergiciels RFID [31] . . . . . . . . . . 63


A.1 tude comparative entre les approches danalyse dun fichier XML . . . . . . . . 90

viii

Introduction Gnrale
Les entreprises oprent dans un environnement complexe, caractris par une concurrence
vive , des prix , des volutions technologiques et sur tout dune rduction des cycles de vie des
produits ... etc. Pour assumer ces exigences, les entreprises doivent trouver , en continu des
techniques pour amliorer leurs processus et leurs stratgies.
Aussi bien lentreprise daujourdhui nagit pas isolment mais dans une association dentreprise appele chane logistique.
Dou lintgration des activits intra et inter-entreprises semble tre une rponse la complexit
de lenvironnement et la rduction du temps pour le dveloppement des produits.
En effet le dveloppement de la collaboration inter-organisationnelle ncessite une visibilit
continue de linformation et une traabilit des produits tout au long leur cycle de vie. Et
pour assurer cette visibilit diverses technologies de capture automatique des donnes se sont
imposes savoir : les codes barres, lidentification par la biomtrie, les cartes magntiques,
les cartes puce et notamment lidentification par Radio frquence.
La technologie didentification par radiofrquence (RFID) est la plus mergeante qui va profondment transformer les processus et pratiques daffaires de la chane dapprovisionnement.
Cette technologie est un moyen dautomatiser lidentification , le suivi et le traage du parcours
des objets tagus.
Electronic Product Code (EPC) Gnration 2 (Gen2) est un exemple typique des tiquettes
RFID passives. Il reprsente llment cl dune architecture RFID, nomme EPCglobal network. Ces tiquettes portent des informations personnelles du porteur de ltiquette, pour ce
fait une protection de ses informations est exige.
Cest dans ce cadre quil nous a t confi au titre de projet de fin dtude lInstitut National des Sciences Appliques et de la Technologie (INSAT), pour concevoir et dvelopper une
plateforme de contrle de production dans lusine base de la technologie RFID et le standard
EPCglobal ainsi lintgration dun module de scurit afin de protger les informations portes
sur les tiquettes . Cette plateforme est base sur trois modules : le premier est le middleware
qui a pour rle de grer, de collecter et de mettre en forme les donnes pour les transformer vers
les couches suprieur. Tandis que le second est lapplication web qui est responsable lexcution des processus mtiers globaux de lentreprise, tels que la gestion du stock , lexpdition et

Introduction Gnrale
la rception des produits, lanalyse de lhistorique.
Le prsent rapport est de ce fait la synthse des tapes de mise en oeuvre de cette plateforme. Il a pour but de situer le contexte du projet, de dcrire son sujet, les mthodes et outils
utiliss ainsi que les rsultats obtenus. Il est organis comme suit :
Le premier chapitre intitul Contexte du projet est consacr la prsentation de lorganisme
daccueil, ainsi que la mise en contexte du projet. Nous prsentons aussi dans ce chapitre la
mthodologie que lon va adopter tout au long de llaboration de ce projet.
Ensuite, dans le second chapitre, nous entamons une description de ltat de lart et de
ltude de lexistant qui consiste dcrire les solutions actuelles existantes, en relevant ses insuffisances et en proposant la solution adopte.
Dans le troisime chapitre, nous spcifions les fonctionnalits et les besoins issus de la proposition effectue dans le chapitre prcdent.
Larchitecture et la phase de conception de la solution font lobjet du quatrime chapitre
dans lequel nous dtaillons notre mthode, et ce pour rpondre aux problmes aussi bien dordre
conceptuel que technique.
Puis, nous prsentons les fonctionnalits de base ainsi que les diagrammes ncessaires la
conception du solution.
Enfin, nous exposons dans le cinquime chapitre lenvironnement matriel et logiciel. Il y
aura par la suite une dmonstration du travail ralis en discutant le droulement de quelques
cas dutilisations particuliers.
Ce rapport sachve sur une conclusion gnrale rsumant les fonctionnalits ralises et
proposant des perspectives en vue dlargir et damliorer ce travail.

Chapitre I
Prsentation du cadre du stage
" Tout projet nat dune ide...quelle naisse dun besoin, dune exprience ou dun
savoir-faire, il sagit au dpart dune intuition ou encore dune simple envie qui grandit au fil
du temps. "

Plan
1

Prsentation de la socit ITesLab . . . . . . . . . . . . . . . . . . .

1.1

Mission . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1.2

Schma organisationnel . . . . . . . . . . . . . . . . . . . . . . . . . .

Prsentation du projet . . . . . . . . . . . . . . . . . . . . . . . . . .

2.1

Cadre du projet

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2.2

Problmatique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Mthodologie du travail

. . . . . . . . . . . . . . . . . . . . . . . . .

3.1

Le processus de dveloppement

. . . . . . . . . . . . . . . . . . . . .

3.2

Formalisme de modlisation . . . . . . . . . . . . . . . . . . . . . . . .

3.3

Planification du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

Introduction
Dans ce chapitre, il sagit de mettre le projet dans son contexte organisationnel et mthodologique. Tout dabord, nous prsentons lorganisme daccueil. Ensuite, nous dcrivons
brivement le sujet, la problmatique rsoudre, et la mthodologie de travail adopte.

Prsentation de la socit ITesLab

ITesLab est un centre de R et D fonde en 2012, spcialis en RIA (Rich Internet Applications), dveloppement, intgration, personnalisation et validation des solutions mobile et
embarqu SW pour les industries des tlcommunications[1].

I.2 Prsentation du projet

1.1

Mission

Pour gagner la confiance de ses clients, ITesLab est en mesure de crer une culture de
transparence avec eux en les assistant durant toutes les phases de pr-lancement jusquau
service aprs-vente, et ce par le biais de ses activits principales qui sont :
Dvelopper, intgrer, valider et maintenir des solutions emparqu, mobiles et des applications ;
Innover et dynamiser le march de la clientle avec des nouvelles ides ;
Fournir des produits de haute qualit par la mise en oeuvre des processus rigoureux pour
le contrle du cycle de vie des solutions softwares ;
Garantir les besoins des clients et le temps pour livrer les produits ;

1.2

Schma organisationnel

Figure I.1 Architecture organisationnelle de la socit ITesLab

Prsentation du projet

La prsentation du sujet de notre projet de fin dtudes aura le mrite de mettre au point ses
composantes, de donner un aperu sur les moyens daction permettant de rpondre, efficacement
et avec concision, aux spcifications.

I.2 Prsentation du projet

2.1

Cadre du projet

Ce rapport est rdig dans le cadre de la prparation du mmoire de fin dtudes en vue de
lobtention du diplme National dIngnieur en Rseaux Informatiques et Tlcommunications
de lInstitut National des Sciences Appliques et de la Technologie pour lanne universitaire
2014/2015.

2.2

Problmatique

Notre travail, convient-il de le rappeler, porte sur ltude des impacts de la technologie RFID
et du rseau EPC sur la gestion de la chane dapprovisionnement dans lindustrie .
Lide gnrale du projet consiste donc concevoir une plate forme de contrle qui pourra
de faon concrte permettre un administrateur deffectuer la supervision (configuration, historique d vnements, contrle employs ,Produits et matriaux) en se basant sur linventaire
des objets connects (produits, employs, et matriaux). Un fonctionnaire utilisera le mme
systme pour grer les objets connects mais avec des droits daccs limits.
Avant de plonger dans ltude proprement dite de la solution, il est indispensable de prendre
du recul et de faire un rsum des problmes concrets existants que rencontrent au jour le jour
nos diffrents acteurs.
a.Le manque de traabilit et de suivi :
De nos jours, le contrle et le suivi des oprations techniques et financires ainsi les quipements
et les produits dans les entreprises se font mais pas de manire automatises et scurises.
b. Le manque du contrle des employs :
Pour ladministrateur le contrler des employs demeure une ncessit incontournable afin de
grer de manire efficace leur temps de travail de ce fait a va augmenter leur productivit.
c.Linscurit :
Les tiquettes des objet connects (Produits, outillages et employs) peuvent contenir plus dinformations quun simple identifiant, comme les donnes personnelles du porteur de ltiquette.
Par consquent, des protections sont ncessaires pour protger la vie prive du porteur.
Nous pouvons formaliser notre problmatique par lintermdiaire du diagramme de la Figure
I.2 :
Lapplication propose devra donc tre mesure dapporter une solution concrte la prise
en charge des diffrents problmes ci-dessus.

I.3 Mthodologie du travail

Figure I.2 Bte corne concernant la problmatique

Mthodologie du travail

Nous prsentons dans cette section, les diffrents choix conceptuels relatifs au dveloppement
de notre projet savoir le processus du dveloppement et le formalisme de modlisation.

3.1

Le processus de dveloppement

La gestion de projet est une dmarche visant organiser, du dbut la fin, le bon droulement dun projet. Au dbut de projet, le premier rflexe est dessayer de tout prvoir et tout
anticiper, ce qui nest pas toujours possible et mne parfois lchec. Nous pouvons donc citer
deux limites de cette approche prdictive [2] :
Gestion des risques :Impossible danticiper tous les risques car des imprvues peuvent
apparatre tout moment.
Dveloppement : Impossible de prvoir toutes les taches faire et comment les faire,
de nouvelles possibilits et ides seront dcouvertes tout le long du projet.
Pour cette raison, et depuis une quinzaine dannes, la majorit des projets de dveloppement
logiciel sappuie sur des mthodes dites agiles .
Il existe une varit de mthodes agiles tels que XP, RAD, et SCRUM. Reconnaissant limportance et les avantages de ces mthodes, nous optons par un dveloppement agile qui reste le
seul garant de la convergence vers les besoins du client.

I.3 Mthodologie du travail


3.1.1

tude comparative de quelques mthodologies

Une comparaison entre les diffrents processus de dveloppement est faite afin de choisir le
mieux adapt notre projet. Vu le nombre important de mthodologies, nous allons nous limiter
une comparaison entre XP et SCRUM qui sont frquemment utiliss dans les entreprises. Voici
ci-dessous un tableau comparatif de ces mthodologies.

Mthode
XP

Avantage
- Des pratiques robustes.
- Lutilisateur choisit les priorits des fonctionnalits.
- Le dveloppeur fixe les estimations.
- Grer le feedback des clients.
- Refactorisation.

SCRUM

- Dveloppement du backlog du produit et du


sprint.
- Les "User Stories" sont centraliss sur la valeur
du business.
- Des courtes itrations (de 2 4 semaines).
- Plusieurs outils supportent la mthodologie
SCRUM.
- La possibilit davoir des certifications.
- Dfinit des rles et des runions pour faciliter la
communication.
- Au moins une fonctionnalit doit fonctionner correctement la fin de chaque itration.
- Dans une seule itration, on peut trouver toutes
les phases de dveloppement.

Inconvenients
- Le client est prsent sur le site.
- Trs difficile pour les nouveaux
utilisateurs de grer larchitecture
et la conception.
- Des standards de dveloppement rigides.
- Demande des connaissances
techniques.
- Ne supporte pas le reengineering (utiliser le modle
hybride : SCRUM + les pratiques
dingnierie XP).

Tableau I.1 Tableau comparatif entre les diffrentes mthodologies

3.1.2

Choix de la mthodologie Scrum

Le dveloppement de ce projet est rgi par le processus SCRUM pour les raisons suivantes :
Sa facilit de mise en oeuvre et sa flexibilit aux changements.
Son appui sur lavancement rel du projet au lieu de lavancement thorique.
Son style organisationnel qui se focalise sur le processus de production dun produit.

I.3 Mthodologie du travail


3.1.3

Application de la mthodologie

a. Prsentation des rles : Il y a principalement trois rles dans Scrum, savoir le Product
Owner, le ScrumMaster, et le Team.
Product Owner(Directeur de Produit) : Le Product Owner dirige le projet dun point de
vue du mtier. Il communique une vision claire du produit et en dfinit les caractristiques
principales [3]. Il sinvestit dans le processus en priorisant les fonctionnalits du logiciel ou
plus gnralement du produit. Il est prsent pour pouvoir rpondre aux interrogations de
lquipe et galement chaque fin ditration pour valider les fonctionnalits du produit.
Ce rle est essentiellement jou par le directeur gnral.
ScrumMaster : Membre de lEquipe, et dont la tche principale est doptimiser la capacit
de production de lEquipe en laidant travailler de faon autonome et samliorer
constamment. Il est galement le garant de la bonne implmentation de Scrum [4]. Cest
Mlle. Marwa CHAMEKH qui joue ce rle.
Team : LEquipe qui prend en charge le dveloppement du produit. Elle est en relation
directe avec le Product Owner en cas dinterrogation sur une des fonctionnalits implmenter. Cette Equipe est prsente par moi-mme pour les phases de planification, de
conception, de codage et de documentation et Mlle. Marwa CHAMEKH pour la phase de
test.
La figure I.3 prsente les rles dfinis dans notre projet.

Figure I.3 Les rles dans Scrum

I.3 Mthodologie du travail


b. La planification : Scrum dcoupe les tches en un ensemble de sous tches pour les
traiter sous forme de sprints. Les sprints peuvent durer entre quelques heures et un mois (avec
une prfrence pour deux semaines). Chaque sprint commence par une estimation suivie dune
planification oprationnelle.
Le sprint se termine par une dmonstration de ce qui a t achev, et contribue augmenter la valeur daffaires du produit. Avant de dmarrer un nouveau sprint, lquipe ralise une
rtrospective : elle analyse ce qui sest pass durant le prcdent sprint, afin de samliorer pour
le prochain [5].
La figure I.4 prsente le processus de dveloppement Scrum.

Figure I.4 Processus de dveloppement Scrum [6]

3.2

Formalisme de modlisation

Nous utilisons Unified Modeling Language (UML) pour la spcification et la conception de ce travail, ce langage est la base de plusieurs mthodes Agile comme les Processus unifis.
UML permet de dcrire les besoins et documenter les systmes ainsi que desquisser les
architectures logicielles et il sarticule autour de neuf diagrammes ddi la prsentation dun
concept particulier du systme tudi. Toutefois, pour viter de surcharger le rapport et dentrer
dans certains dtails techniques, nous ne prsentons que quelques diagrammes que nous jugeons
utiles pour comprendre le projet savoir les diagrammes de cas dutilisation, les diagrammes

I.3 Mthodologie du travail


de paquetages les diagrammes de classes et les diagrammes de squence :
Les diagrammes de cas dutilisation : permettent lnumration des fonctions de
lapplication de point de vue de lutilisateur.
Les diagrammes de classes et de paquetages : permettent une reprsentation
statique du systme tudi, en reprsentant les classes, les paquetages et les relations
entre eux.
Les diagrammes de squences : permettent une reprsentation temporelle et comportementale des objets et leurs interactions.

3.3

Planification du projet

Cette tape est aussi particulirement importante non seulement parce quelle fait partie des
objectifs, mais aussi car elle structure par avance notre travail et nous fixe des dates buttoirs qui
motivent nos recherches. Cette planification a t formalise par le diagramme Gantt prsent
sur la Figure I.5.

Figure I.5 Diagramme de Gant

Conclusion
A travers ce premier chapitre, nous avons prsent le cadre organisationnel et mthodologique dans lequel se situe le projet en introduisant lorganisme daccueil, en dgageant la
problmatique et les objectifs du projet et en rvlant la mthodologie adopte.
Dans le chapitre suivant, nous allons aborder quelques notions gnrales ncessaires pour la
comprhension de notre projet, ainsi quune tude sur les solutions existantes.

10

Chapitre II
Etude Pralable
"Celui qui dplace les montagnes le fait en dplaant de petites pierres."

Plan
1

Etat de lart

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

11

1.1

Chaine dapprovisionnement . . . . . . . . . . . . . . . . . . . . . . . . 12

1.2

Traabilit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

1.3

Approfondissement sur la technologie RFID . . . . . . . . . . . . . . . 14

Etude de lexistant

. . . . . . . . . . . . . . . . . . . . . . . . . . . .

24

2.1

Prsentation de quelques solutions . . . . . . . . . . . . . . . . . . . . 24

2.2

Critique de lexistant . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

2.3

Solution propose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

Introduction
Afin datteindre les objectifs de notre projet, ltude des solutions existantes et des diffrents moyens mis notre disposition est une tape invitable. En fait, elle permet dabord de
dcortiquer les fonctionnalits dj dveloppes et surtout de mettre en relief leurs limites.
Ensuite, nous pouvons dgager la solution envisageable qui peut faire face aux problmes lis
la solution existante. Suite cette constatation, nous prsentons, dans la premire partie de
ce chapitre une tude thorique qui va nous permettre de nous accommoder avec les diffrents
standards et technologies utiliss au cours du dveloppement. Dans la deuxime partie, nous
exposons les solutions existantes en dgageant leurs faiblesses.

Etat de lart

Cette partie est primordiale pour la construction du maximum dinformations sur le projet
aprs avoir bien cern la problmatique et les enjeux.
Cette tude de ltat de lart est consacre en premier lieu, la prsentation de la chaine dapprovisionnement.

11

II.1 Etat de lart


En second lieu nous tudions ce qui a t fait en matire de traabilit.
Nous compltons ensuite cette partie par la prsentation du systme didentification par radiofrquence (RFID).

1.1

Chaine dapprovisionnement

Une chane dapprovisionnement est dfinie comme un rseau dorganisations qui cooprent pour optimiser le flux de matriel entre le fournisseur et le client, loptimum tant
un flux aussi rapide que possible et un cot de production minimal. Lobjectif dune chane
dapprovisionnement est la satisfaction du client [21]
Prsentation de la chaine dapprovisionnement
Une chane logistique peut tre constitue par un ou plusieurs acteurs. On peut citer : les
fournisseurs, les fabricants, les distributeurs, les dtaillants et les clients, etc. La figure II.1
illustre un modle de chane logistique. Dans notre projet la chaine dapprovisionnement est

Figure II.1 Un modle de chane dapprovisionnement [22]

constitu que par le fabriquant pour le traage du parcours des produits, des employs et des
outils, comme le montre la figure II.2

12

II.1 Etat de lart

Figure II.2 Gestion dentrept grce travers la technologie RFID [23]

1.2

Traabilit

1.2.1

Dfinition :

La norme ISO 8402 a dfini la traabilit en 1987 : Laptitude retrouver lhistorique,


lutilisation ou la localisation dune entit (processus, produit, organisme, voire personne) au
moyen didentifications enregistres. [8].
On peut distinguer deux types de traabilit :
a. La traabilit logistique (Tracking) :
Elle correspond un suivi, elle permet de localiser les produits, dterminer les destinations et
les origines.
b.La traabilit produit (Tracing) :
Elle permet de reconstituer qualitativement le parcours des produits.
On lutilise pour rechercher les causes dun problme qualit : en amont si lincident sest produit chez un de ses fournisseurs, en aval si lincident sest produit, par exemple, lors du transport.
Notre projet se focalise sur la traabilit logistique.

13

II.1 Etat de lart


1.2.2

Technologies de Traabilit

Afin de mieux rpondre notre problmatique, nous avons raliser un tat de lart sur les
diffrents technologies de traabilit logistique.
On a tout dabord citer les solutions les plus simples pour finir avec les solutions les plus
avances.
Les codes barres Le code barres est un systme de traabilit trs apprci des entreprises de dfrent secteurs . Il fait partie de lauto-ID ou AIDC (Automatic Identification and
Data Capture)[8].
Lomniprsence des codes barres a un effet trs important sur la redressement de la productivit dans lindustrie du commerce de dtail, et cela se fait par la rduction des erreurs et le
temps de cycle ainsi lamlioration de la gestion des inventaires.
Le code 2D Les codes de type MATRICIELS ncessitent une technologie de capture vido
de limage et non plus un simple faisceau de lecture.
Ltiquette code 2D est standardise et normalise. Le code 2D est utilis dans des nombreuses
applications qui exigent un tiquetage avec une grande quantit de donnes : marquages directs
de pices (ex : Pices dtaches automobiles&aronautiques, circuits imprimes) .Dtiquetage
de produits (Emballages pharmaceutiques, cartouches dimprimantes, paquets postaux, caisses
plastiques, cartons, boites et palettes) [9].
Les techniques didentification par radiofrquences (RFID) La technologie RFID
est une solution qui ne ncessite ni contact physique ni contact visuel (comme pour les codes
barre) , elle fait partie aussi de lauto-ID ou AIDC (Automatic Identification and Data
Capture). Cette technologie assure la saisie automatique des donnes , notamment elle permet
la rduction des erreurs humaine ainsi elle offre une vision complte et en temps rel de la
chaine dapprovisionnement .

1.3
1.3.1

Approfondissement sur la technologie RFID


Dfinition

Lidentification par radiofrquence ou RFID (Radio Frequency Identification) est une technologie qui permet didentifier, distance, des objets, des animaux ou des personnes, sans
contact physique, ni visuel. Pour cela, les donnes sont stockes et rcupres distance en
utilisant les ondes radio comme mdia de communication[8].

14

II.1 Etat de lart


1.3.2

Architecture dun systme didentification par radiofrquence

Un systme dtiquette radio frquence est compos de [10] :


Une tiquette : une puce et une antenne ;
Un dcodeur et son antenne ;
Un systme informatique : middleware ;
La figure II.3 illustre ces composants et leurs interconnexions : Cette technologie permet

Figure II.3 Infrastructure de la technologie RFID [11]

didentifier un objet, den suivre le cheminement et den connaitre les caractristiques distance
grce une tiquette mettant des ondes radio, attache lobjet . La technologie RFID permet
la lecture des tiquette mme sans le contact directe et peut traverser de fines couches de
matriaux. Le middleware est en charge de grer linfrastructure RFID ainsi que les donnes
issues des lecteurs, afin de fournir lapplication mtier les donnes dont elle a besoin.
Etiquette RFID Ltiquette RFID est compose dune puce relie une antenne, toutes
deux encapsules ou colle dans un support comme il est prsent dans la figure II.4
Il existe trois grandes familles dtiquettes RFID [13] :
a. Les tiquette passives : Cette tiquette na aucune source dnergie intgre, telle quune

15

II.1 Etat de lart

Figure II.4 Etiquette RFID [18]

batterie.Dou elle absorbe lnergie lectromagntique mise par le lecteur et le converti en


alimentation DC (courant continu ) afin dactionner la puce. Elle transmet linformation par
rtrodiffusion dune partie dnergie reue.
b. Les tiquettes semi-passives : Une tiquette semi-passives a une batterie pour actionner
la puce. Elle utilise la rtrodiffusion pour la communication avec le lecteur , elle nutilise pas
sa batterie pour mettre des signaux. Donc elle agisse comme des tiquettes passives au niveau
de communication. Ces tiquettes utilisent leur batteries pour enregistrer les donnes lors du
transport.
c. Les tiquettes actives : Ces tiquettes sont actionnes par une batterie interne. Ainsi,
elles peuvent transmettre un signal RF en rponse au lecteur plutt que rtrodiffuser le signal
du lecteur comme les autres types.
Lecteurs RFID
Les lecteurs RFID permettent de lire de linformations dans les tags.
Un lecteur contient un module RF (transmetteur et rcepteur), une unit de contrle et un
lment rayonnant (Figure II.5) permettant la communication sans fil vers le tag.

Figure II.5 Communication Lecteur-Tag

On distingue deux types de lecteurs [10] :


a. Lecteurs fixes : Les lecteurs fixes sont positionnes des endroits stratgiques o ils interagissent avec les tags.

16

II.1 Etat de lart

b. Lecteurs mobiles : Un lecteur mobile est gnralement compos dun lecteur RFID,
dun antenne et dune unit de traitement. Sa porte est limite.
Le choix du lecteur RFID se faire selon deux critres la frquence des tiquettes RFID et la
distance de lecture souhaite.
systme de traitement de donnes en RFID
Le logiciel RFID, ou middleware RFID, charg de grer, de collecter et de mettre en forme
les donnes pour lapplication finale, application mtier ddie lentreprise (gestion de stock,
contrle daccs etc.).
Le middleware est divis en trois composants principaux [14], reprsents sur la Figure II.6.

Figure II.6 Composants dun middleware

a. Gestion des quipements : Le premier composant est le service de gestion des quipements, quivalent un service dabstraction matrielle. Il est l pour permettre lutilisateur
final de ne pas avoir grer la complexit et lhtrognit de ses quipements.
b. Gestion des donnes :] Ce composant a pour objectif la rcupration et le tri des
observations RFID brutes afin de les transformer en observations utiles lutilisateur final.

17

II.1 Etat de lart


c. Gestion de service : Les deux composants prcdents ont besoin de rgles pour
fonctionner. Ces rgles sont spcifiques chaque systme RFID et doivent tre dfinies par
lutilisateur. Ce dernier composant offre donc la possibilit lutilisateur de dfinir ces rgles.
Les rgles sont nonces en gnral vis--vis de lapplication finale.
1.3.3

Caractristiques des systmes RFID

Les systmes RFID sont caractriss principalement par les frquences, les normes, la porte
et le couplage .
Frquences En Rflchissant des ondes lectromagntique, les systmes RFID doivent ne pas
perturber le fonctionnement des autres systmes radio.
Donc les systmes RFID utilisent des plages de frquences spcifiques qui sont rserves aux
applications industrielles, scientifiques ou mdicales qui sont appeles ISM (Industriel ? Scientifique ?Mdical). Les principale plages de fonctionnement prsentes dans la figure II.7 : Les

Figure II.7 Les gammes de frquences RFID [13]

frquences attribues pour la RFID en UHF varient en fonction des rgions du monde.
En Europe, en Afrique et dans une grande partie de lAsie, les tiquettes RFID UHF fonctionnent de 865 MHz 868 MHz. En Amrique du Nord, les frquences attribues vont de 902
MHz 928 MHz [15] .
Porte Les performances dun systme RFID dpendent essentiellement de la qualit de la
porte entre lantenne de linterrogateur et celle de ltiquette. Ce dernier est fortement li la
frquence et la porte du systme, qui peut varier de quelques millimtres plus de dizaine

18

II.1 Etat de lart


mtres. Par ce fait on distingue trois types de systmes RFID en fonction du couplage [16] :
a. les systmes couplage rapproch : Ces systmes ont une porte trs faible, jusqu un
(1) cm.On les retrouve dans des applications qui utilisent le chiffrement, comme le verrouillage
de portes et les cartes puces sans contact. Ils sont de moins utiliss sur le march .
b. les systmes couplage distant : leur porte va jusqu ? un (1) mtre. Ils fonctionnent aussi avec des champs lectromagntiques par induction. Les frquences gnralement
utilises pour ces systmes sont 135 kHz et 13.56 MHz .
c. les systmes longue porte : la porte dpasse plus d ?un mtre. Les tiquettes
RFID sont trop loignes pour fonctionner par induction. En revanche, elles rflchissent les
ondes radio. Ces systmes fonctionnent en UHF et sur les micro-ondes.
Les normes Les normes contribuent crer un cadre harmonis, amliorer la transparence,
lefficacit et la scurit dans un march complexe en pleine croissance, tout en optimisant les
processus des entreprises et en rduisant leurs couts de fonctionnement[16].

Les normes ISO Les normes ISO ont des avantages pertinents dans le suivi des produits
lors de leurs dplacement dans la chaine dapprovisionnement, y compris pour la prvention
des pertes, la maitrise des inventaires et la visibilit durant lacheminement. En rponse aux
dernires tendances du march, lISO travaille actuellement sur des normes qui porteront lidentification RFID un nouveau stade dvolution [16].
La norme EPCglobal a. Prsentation de la norme EPCglobal
Le projet EPCglobal a t cr en juillet 2003 laccord entre Auto ID centre et GS1 Sa
mission est de dvelopper un standard dfinissant un systme didentifiant unique par objet
EPC (Electronic Product Code) [16] .
EPCglobal a mis , pour son standard, un Framework darchitecture sur lequel les dveloppeurs
hardware, software, les architectes de linformation ainsi que les socits qui veulent intgrer la
RFID dans leurs processus peuvent se baser .La figure II.8 prsente cette architecture :

19

II.1 Etat de lart

Figure II.8 Architecture du rseau EPCglobal

20

II.1 Etat de lart


Le tableau II.1 dcrit les principaux composants de cette architecture :
Composant
Reader Protocol

Description
Il implmente le protocole Reader Protocol Standard ddi
linteraction avec les appareils qui lisent ou crivent les tags
EPC
Le standard ALE dEPCGlobal (Application Level Event) dfinit les interfaces fournies par le composant de filtrage et
de Collection (F& C) aux couches suprieures de larchitecture (EPCIS, applications mtiers, etc.). Ces interfaces sont
au nombre de cinq :
- interface de lecture : Il fournit des mthodes pour grer
les spcifications dites ECSpecs, doprations de lecture. Un
fois que la spcification est envoye au F& C puis valide, lintergiciel va effectuer lopration et envoyer le rapport (appel
ECReports)
- Interface dcriture : offre la possibilit dcrire dans les
tiquettes RFID via les lecteurs ou les imprimantes.
- interface de lecteur logique : sert dfinir des lecteurs
logiques, utilisables pour les oprations de lectures et dcritures, regroupant une ou plusieurs sources physiques de lecture/criture .
- interface de spcification de la mmoire des tiquettes : Linterface pour la mmoire des tiquettes permet
au F&A de traiter des donnes non-EPC.
- interface de contrle daccs : contrle laccs des clients
aux autres interfaces.

ALE

Lapplication
capture
EPCIS

de

Elle retravaille les vnements reu par linterface ALE. Cette


application capture les ECReports travers linterface ALE
aprs les rarrange.
Aprs avoir filtr et collect les donnes lues par les lecteurs,
les vnements (annexe B) du composant F&C(Filtrage et
Collection) peuvent tre enregistrs dans une base de donnes.

Tableau II.1 Les lments de larchitecture du rseau EPCglobal

Note : Dans lannexe A nous avons dfinit quelques notions de ce tableau descriptif.

21

II.1 Etat de lart


b. Le code EPC (Electronic Product Code)
Le code ECP est un systme de codification permettant didentifier tout objet de faon
unique. Chaque objet est identifi par un code unique EPC Electronic Product Code. Chaque
objet peut tre donc tre suivi individuellement . Laccs dautres informations est possible
via internet comme le lieu de stockage, les conditions se stockage, la date darrive dans lentrept etc. [16]
Structure du code EPCglobal
Une code EPC se compose de :
Header : dfinit la longueur, la structure et la version de lEPC.
EPC Manager : identifie lentreprise qui a la responsabilit dattribuer les donnes Objet
Class et numro de srie.
Objet Class : identifie la classe ou le type dobjet.
Numro de srie : identifie lobjet de manire unique.

Figure II.9 Structure du code EPC [17]

Limplmentation du standard EPC nous permet de :


Faciliter lchange des informations et objets physiques entre les partenaires.
Encourager linnovation et la performance.
Dun suivi en temps rel des marchandises.
Protger la vie prive et de Lutter contre la contrefaon.
Rduction des cots.
c. Le standard EPC Gen 2 de RFID pour la logistique et le commerce
Le standard EPC Gen2 est le rfrentiel mondial pour le marquage RFID des produits manufacturs. Il exploite les qualits inhrentes aux frquences UHF. Les distances de lecture par
RFID sont adaptables selon les cas d ?usages : de quelques centimtres plusieurs mtres.
Ce standard ne connat pas de frontire en dpassant les diffrences de rglementation qui r-

22

II.1 Etat de lart


gissent l ?emploi de la bande UHF dans le monde.
Lorganisation GS1 a annonc la ratification de la dernire version du standard EPC Gnration2 UHF RFID V2 (EPC Gen 2 v2) [24].
Cette nouvelle version propose de nouvelles fonctionnalits qui permettront de :
Lutter contre la contrefaon grce la vrification de lauthenticit d ?un tag,
Renforcer la scurit en modifiant les informations contenues dans un tag de manire
scurise.
Assurer une meilleure gestion de fichiers par la cration des fichiers et attribuer des
privilges daccs. Il sera possible de grer jusqu 1023 fichiers denviron 2 Mbytes chacun.
Faciliter la prvention des pertes par lutilisation du tag en tant que systme antivol.
Parmi les techniques de scurit ajoutes au standard EPC Gen 2 v2 , on trouve la Cryptographie. La figure 2.10 rsume les diffrents types de cryptographie intgrs dans ce standard
.

Figure II.10 Liste des cryptographies intgr dans la version 2 du EPC Gen 2 [42]

Applications Les applications de la RFID varient en fonction des bandes de frquences


comme suit [16] :
a. les systmes en basse frquence (125 135 kHz) : qui sont utiliss pour lidentification des animaux de compagnie, des animaux sauvages, du btail. Ils constituent la base des
systmes de cls lectroniques de certains modles automobiles, ou encore de systme dantidmarrage cod, dantivol .
b. les systmes haute frquence (13,56 MHz) : qui sont utiliss dans les services de

23

II.2 Etude de lexistant


contrle daccs aux btiments, sous forme de badge sans contact, intgrant un systme dauthentification. Le passeport biomtrique et la carte puce sans contact sont des applications qui
se retrouvent dans cette classe de frquence. Ces systmes sont aussi utiliss pour la traabilit
des livres dans les librairies et les bibliothques ainsi que la localisation des bagages dans les
aroports .
c. les systmes ultra haute frquence (UHF) : qui sont utiliss pour la traabilit des
palettes et conteneurs dans les entrepts et les usines. Cette catgorie de systmes RFID est
adapte au secteur de la grande distribution .
d. les systmes micro-ondes (2,45 GHz) : qui sont adapts pour le contrle daccs
longue distance des vhicules, comme par exemple sur les grandes zones industrielles. Les
tiquettes RFID utilises sont gnralement des tiquettes actives.

Etude de lexistant

Aprs avoir ralis ce travail de veille sur cette technologie ,jai effectu une tude de march
de la technologie RFID pour savoir quels taient les principaux acteurs dans ce domaine et quel
type de solution tait disponible la vente.
Aprs une tude approfondie qui a retenu une dure de trois semaines des produits mis en
vente sur Internet je me suis rendu compte, que ce secteur de march tait occup par des trs
nombreux acteurs et que nexiste pas encore une solution RFID normalise.
En effet j ?ai dnombr une dizaine de vendeurs de produits. Voici par exemple une liste des
socits tudies : Nexsees, Tagsys, SenseYou , Coppernic, RFit Technologies, IER, TACEIT,
ClearStream. Ainsi Nous avaons slectionn les trois les plus connues dans le monde dans mon
rapport .
Cette tude est une prparation la phase des choix techniques pour la conception et la
ralisation de notre solution.

2.1

Prsentation de quelques solutions

ClearStream Cette solution vise rendre plus facile pour les utilisateurs de grer les lecteurs
EPC Gen 2 UHF RFID fixe, et lire et crire des donnes codes sur les tiquettes puis stocker
ces informations sur un PC [18].
La figure II.11 illustre larchitecture de cette solution .

24

II.2 Etude de lexistant

Figure II.11 Architecture de la solution ClearStream [18]

ClearStream supporte les Tags Inlay, actives et passives.


Elle a cot 2500 dollars.

TRACEIT TRACEIT t conu en rponse aux problmatiques identifies de gestion


des outillages et biens dquipements, en particulier ceux soumis vrification priodique.
Principes de fonctionnement
Le systme met en oeuvre des systmes de capture automatique par RFID qui dtectent les
mouvement darticles, contrlent les conformits et alertent lutilisateur .
Des terminaux portables industriels quips de lecteurs RFID permettant denregistrer des
transactions denlvement et de livraisons, directement depuis les sites avec synchronisation
des donnes.
La solution exploite les standards EPC/ISO offrant ainsi la possibilit de mutualiser les infrastructures de collecte de donnes[19].
Cette solution cote environ 500 euros.

HubID HubID est une plateforme middleware qui collecte en temps rel, fusionne, centralise, et restitue les donnes mises par ces multiples capteurs. Les donnes sont alors formates
et enrichies (filtrage, dboulonnage, agrgation...)[20].
HubID supporte EPC Gen 2 tags. La figure II.12 prsente larchitecture de la solution.

25

II.2 Etude de lexistant

Figure II.12 Architecture de la solution Hub ?ID [20]

la solution HubID garantit la matrise du norme standard EPC Global et la fiabilit des
donnes vers le systme dinformation.

2.2

Critique de lexistant

Une analyse des solutions existantes montre que la plupart de ces applications offrent des
fonctionnalits de base de gestion des outillages et des articles dune usine.
Au regard de ces informations, nous pouvons relever quelles rpondent au besoin principal des
utilisateurs. Nanmoins, nous pouvons aussi noter les inconvnients suivants :
Tous ces solutions ne sont pas open source au contraire elles sont trs chres ;
Ces solutions noffre pas une traabilit et un suivi des tches administrative et financire
effectues, elles sont conues juste pour le contrles des produits et les matriaux ;
Ces solutions sont conus juste pour la traabilit des produits et des outillages pas de
contrle daccs des employs ;
ClearStream ne permet pas un utilisateur dintgrer ses propres modules pour une bonne
performance de sa usine ;
Tous ces solutions RFID prsente des faiblesses en matire de scurit ;
Cot scurit nous navons pas pu trouver des spcifications ou des dtails sur les rgles et les
algorithmes de scurit utiliss par ces solutions. Mais, avec une petite tude dans la littrature
et sa projection sur les matriaux et les applications dans le march, nous avons pu dgager
quelques points faibles en termes de scurit.
Le tableau ci-dessus prsente les diffrentes insuffisances en termes de scurit et les objectifs
industriels atteindre.

26

II.2 Etude de lexistant

Les problmes de scurit des solutions


existantes
Problme de clonage
Problme de dni de service
Problme de la linkabilit
Systme non volutive
Problme du TTP ( Trusted Third Party)
Problme de la confidentialit des donnes

- Problme de la faiblesse contre les attaques


au niveau des canaux
- Problme de confidentialit entre les partenaires

Objectifs industriels
Visibilit et traabilit

Rduire les erreurs humaines et crer la


confiance entre les partenaires portabilit des
objets
- Processus daffaires efficaces, tels que suivi
en temps rel et mouvement du produit.

Tableau II.2 Tableau comparatif entre les diffrentes mthodologies

2.3

Solution propose

Aprs avoir ralis cette tude de march, jai consult mon encadrant de stage, Mlle Marawa
CHAMEKH, afin que nous dfinissions ensemble les grandes lignes du projet et connatre plus
en dtails ce quil souhaitait mettre en oeuvre. Cette runion prparatrice a t forte utile et
pleine denseignements. En effet aprs avoir consult les diffrents solutions existantes, elle m
a demander de dvelopper une plateforme de contrle bas sur un middleware open-source en
lui ajoutant un module de vrification des signatures . Notre solution est conue en mode Web,
donc lapplication doit tre trs rapide dployer et permettre un accs hirarchis la base
de traabilit, depuis nimporte quel PC quip dun navigateur.

Conclusion
La comprhension des diffrents standards et technologies voqus dans ce chapitre nous a
permis de rflchir sur les besoins fonctionnels et non fonctionnels de notre projet.
Au cours de ce chapitre, nous avons tudi lexistant. Aprs lanalyse de ce dernier, nous avons
prsent notre solution qui consiste implmenter une plateforme de contrle qui facilite la
gestions des produits des employs et des outillages dans une usine. Il offrira galement les
fonctionnalits numrs prcdemment.
Dans le chapitre suivant, nous allons aborder lanalyse et la spcification des besoins de notre
solution RFID.

27

Chapitre III
Analyse et Spcification des besoins
" Celui qui ne sait pas o il va se retrouve ailleurs."

Plan
1

Identification des acteurs . . . . . . . . . . . . . . . . . . . . . . . . .

28

Recueil des besoins globaux . . . . . . . . . . . . . . . . . . . . . . .

29

2.1

Besoins fonctionnels . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

2.2

Besoins non fonctionnels . . . . . . . . . . . . . . . . . . . . . . . . . . 30

2.3

Diagramme de cas dutilisation globale . . . . . . . . . . . . . . . . . 31

Analyse fonctionnelle . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.1

Description dtaille des cas dutilisation

31

. . . . . . . . . . . . . . . . 31

Introduction
Dans ce chapitre, nous prsentons lensemble des fonctionnalits que doivent satisfaire les
modules dvelopper, ainsi que les diffrentes contraintes quils doivent respecter. Le chapitre
sorganise du gnral au spcifique : on commence par les acteurs et les besoins de la solution
globalement puis on entame chaque module en dcrivant ses acteurs et son analyse fonctionnelle.

Identification des acteurs

Nous commenons tout dabord par numrer les acteurs susceptibles dinteragir avec le
systme. Dans notre solution, nous pouvons distinguer cinq types dutilisateurs :
Administrateur
Responsable de stock
Voici un tableau descriptif de ces acteurs

28

III.2 Recueil des besoins globaux

Acteur
Administrateur

Responsable de stock

Description
Il a laccs total tous les modules. Il a le droit deffectuer toutes sortes doprations telles que la configuration
du systme, le contrle des connexions, le contrle du
suivi des objets, laffectation des fournisseurs, budgets,
contrats et bien dautre.
Il assure la gestion du stock tel que le contrle du rseaux
RFID et des marchandises entrantes / sortantes.

Tableau III.1 Description des acteurs principaux

Recueil des besoins globaux

Dans cette partie nous commenons par la description de lensemble des fonctionnalits
relatives chaque module du systme global.

2.1

Besoins fonctionnels

a.Gestion des objets connects (tags) :


Module de suivi des chances : dates de contrles, premption, maintenance.
Module de suivi des niveaux de stocks
Module de gestions des donnes captures (collecte, acquisition, filtrage des donnes des
objets connects).
Module de gestion des cellules des productions .
Module dadministration des objets : cration, modification, proprit.
Module dadministration des infrastructures / appareils mobiles : cration, modification,
proprits.
Module dadministration des utilisateurs / profils : cration, modification, proprits et
visualisation des employs (contrle des accs surveills, ) .
b.Gestion des historiques de mouvements des objets connects (rapport) :

Module
Module
Module
Module
Module

de
de
de
de
de

visualisation des historiques de mouvements par localisation, objets.


visualisation des historiques de contrles raliss par localisation, objets.
visualisation de la map de lusine.
visualisation des historiques des alertes.
gnration de rapports.

29

III.2 Recueil des besoins globaux


c.Gestion les entre/sorties du stock :
Gestion des commandes (visualisation, validation des commandes.
Consulter le mouvement de stock en temps rel (incrmentation et dcrmentation de
stock).
Module de visualisation dinventaire temps rel des objets par localisation, type, emplacements.
Module de visualisation temps rel denvoi / emprunts / rception / retour des objets.
Rception / Prparation marchandise.
d.Gestion des alertes :
Alertes automatiques lorsque la date de contrle est dpasse ou lors dun dplacement
non autoris dun employ, matriel ou produits(nombre, zone...).
Paramtrage des seuils de dclenchement des alertes (seuil haut, seuil bas, seuil de rapprovisionnement).
Visualisation des alertes gnres.
Diffusion des alertes par : mail, sms, notification push par une application androde .
Gnration des ractions de rponse aux alertes : Les rponses aux alertes sont affiches
sous forme de liste de choix pour acclrer la raction des utilisateurs.

2.2

Besoins non fonctionnels

Conformit aux standards EPC Gen2 rgissant la technologie RFID UHF et EPCIS pour
les data.
Lutter contre la contrefaon grce la vrification du module de scurit.
Compatibilit avec nimporte quel systme dexploitation
Access depuis nimporte quel navigateur Web (Internet Explorer, Firefox, Chrome)
Le transfert des donnes entre lapplication Androde et le serveur de donnes doit tre
scuris.
Grer les erreurs lies la connexion au serveur.
Avoir un code lisible et il doit respecter la conception de loutil utilis afin que notre
outil final soit volutif et maintenable donnant lieu des amliorations futures. Ceci est
ncessaire pour faciliter lajout dune nouvelle fonctionnalit.
tre apte la maintenance et capacit dvolution : conforme larchitecture choisie lors
du dveloppement.

30

III.3 Analyse fonctionnelle

2.3

Diagramme de cas dutilisation globale

Dans cette figure , on illustre les besoins fonctionnels des acteurs principaux voqus prcdemment.

Figure III.1 Diagramme de Cas dutilisation GLOBAL

La figure ci-dessus reprsente le diagramme de cas dutilisation gnral de notre systme de


gestion de chaine dapprovisionnement.
Nous remarquons galement les relations dinclusions qui lient les diffrents cas dutilisations,
et qui indiquent simplement que le cas dutilisation vers lequel ils tendent devrait tre excut
au pralable.
Nous dtaillons par la suite ces besoins fonctionnels en passant par chaque module part.

Analyse fonctionnelle

Nous prsentons dans cette partie les besoins fonctionnels pour lapplication Web en dtaillant les cas dutilisations.

3.1

Description dtaille des cas dutilisation

Cas dutilisation : Sauthentifier

31

III.3 Analyse fonctionnelle


Cas dutilisation
Acteur
Description
Pr-condition

Sauthentifier
- Tous les Cinque acteurs
- Lutilisateur doit sauthentifier en introduisant un login
et un mot de passe, pour se servir des fonctionnalits de
cette application.
- Accder linterface dauthentification.
- Lutilisateur a un compte.

Post-condition
Droulement

- Linterface de la page daccueil saffiche. .


- Lutilisateur ouvre lapplication
-Le systme lui affiche linterface dauthentification
-Lutilisateur saisit son login et son mot de passe et il
clique sur le bouton "Ok".

Exception

- Login incorrect
- Mot de passe incorrect.

Squencement

Tableau III.2 Description du cas dutilisation sauthentifier

32

III.3 Analyse fonctionnelle


cas dutilisation Administrer Systme pour ladministrateur

Figure III.2 Diagramme de Cas dutilisation Administrer systme pour un administrateur

La figure III.2 nous prsente de faon plus dtaille le cas dutilisation Administrer systme . Nous pouvons donc entrevoir plusieurs fonctions qui servent grer les objets connects.

33

III.3 Analyse fonctionnelle


Dtail de quelques cas dutilisations :
Cas dutilisation : Gnrer les ractions de rponse aux alertes
Cas dutilisation
Acteur
Description
Pr-condition

Post-condition
Droulement

Exception

Gnrer les ractions de rponse aux alertes


- Administrateur
- Ce cas consiste grer les alertes gnrs cause dune
action non autorise ( par exemple en cas de manque
dun type de marchandises ).
- Rception dune Alerte.
- Lutilisateur doit tre authentifi.
- Accder au tableau de bord administration.
- lutilisateur choisit une raction de la liste de choix
pour grer lalerte.
- Ladministrateur sauthentifie.
- Il choisit de grer les alertes .
- Le systme lui affiche linterface de gestion des alertes
.
- Ladministrateur choisit une raction.
- rien .

Squencement

Tableau III.3 Description du cas dutilisation Gnrer les ractions de rponse aux alertes

34

III.3 Analyse fonctionnelle


Cas dutilisation : configurer les seuils de dclanchement
Cas dutilisation
Acteur
Description
Pr-condition
Post-condition
Droulement

Exception

Configurer les seuils de dclanchement


- Administrateur
-Ce cas consiste configurer les seuils de dclanchement
des alertes .
-Lutilisateur doit sauthentifier.
- Accder au tableau de bord administration.
- Les alertes sont configures.
- Ladministrateur sauthentifie.
- Il choisit de grer les alertes .
- Le systme lui affiche linterface de gestion des alertes
.
- Ladministrateur choisit de configurer les alertes : dfinir la seuil de dclanchement.
- Pas de gestion erreur.

Squencement

Tableau III.4 Description du cas dutilisation configurer les seuils de dclanchement

Cas dutilisation : Ajouter un employ

35

III.3 Analyse fonctionnelle


Cas dutilisation
Acteur
Description

Pr-condition
Post-condition
Droulement

Exception

- Ajouter employ
- Administrateur
- Ce cas consiste ajouter un employ. Ce cas se termine par lajout de ce client dans la base de donnes
et par la cration physique dun dossier, ayant comme
nom lidentificateur demploy, dans le dossier de travail de notre application. Ce dossier va contenir tous les
sous-dossiers et les fichiers de cet employ.
-Lutilisateur doit sauthentifier.
- Lutilisateur effectue la gestion des employs
- Lemploy est ajout dans notre base de donnes.
Le dossier, comportant comme nom lidentificateur
demploy, est ajout dans le dossier de travail.
- Lutilisateur choisit de manipuler ses employs .
- Le systme lui affiche linterface de gestion des employs.
- Lutilisateur clique sur le bouton " Nouveau".
- Le systme lui propose un formulaire.
- Lutilisateur remplit le formulaire.
- Lutilisateur valide laction dajout.
- Lajout de lemploy la base de donnes est ralis .
- La cration physique du dossier de lemploy est effectue avec succs.
- Le systme affiche un message de confirmation.
- Lajout dun client dj existant.
- Lutilisateur annule laction dajout.

Squencement

Tableau III.5 Description du cas dutilisation Ajouter employ

36

III.3 Analyse fonctionnelle


Diagramme de cas dutilisation Grer le Stock

Figure III.3 Diagramme de Cas dutilisation Grer Stock pour le responsable de stock.

37

III.3 Analyse fonctionnelle


Cas dutilisation : Gnrer le rapport de marchandise dE/S
Cas dutilisation
Acteur
Description
Pr-condition
Post-condition
Droulement
Exception

- Gnrer le rapport de marchandise dE/S


- Responsable stock
- Ce cas consiste gnrer le rapport de marchandise
dE/S partir de lhistorique de mouvement des produits.
-Lagent doit sauthentifier.
- Il effectue la visualisation de lhistorique de mouvement.
- le responsable du stock consulte le rapport dchange.
- Lagent sauthentifie.
- Il choisit de grer les mouvements de stock.
- Il visualise le rapport de marchandise.
- Pas de gestion erreur.

Squencement

Tableau III.6 Description du cas dutilisation Gnrer le rapport de marchandise dE/S

Cas dutilisation : Grer les objets connects

38

III.3 Analyse fonctionnelle


Cas dutilisation
Acteur
Description
Pr-condition
Post-condition
Droulement

Exception

- Grer les objets connects


- Responsable stock
- Ce cas consiste grer les objets connects (outils,
produits, ouvriers).
- Le responsable stock doit sauthentifier.
- Accder son tableau de bord.
- Les objets connects sont grs.
- Le responsable stock sauthentifie.
- Il choisit de grer les cellules de production.
- Il slectionne grer les objets connects.
- Le systme lui affiche linterface de gestion des Objets
connects.
- Il choisit soit dajouter, supprimer, visualiser (produit,
outil, ouvier).
- Pas de gestion erreur.

Squencement
39

III.3 Analyse fonctionnelle


Le tableau III.7 dtaille comment ladministrateur gre les Objets connects tout en choisissant une action dajout, daffichage ou de suppression dun lment, qui peut tre un employer,
un produit ou une outillage.
Cas dutilisation : Visualiser le map de lusine
Cas dutilisation
Acteur
Description
Pr-condition
Post-condition
Droulement
Exception

- Visualiser le map de lusine


- Responsable stock
- Ce cas consiste visualiser le map de lusine ( infrastructure et produits ).
- Il doit sauthentifier.
- Il effectue la visualisation du map.
- Le responsable de stock visualise le map.
- Il sauthentifie.
- Il choisit de consulter le map de lusine.
- Pas de gestion erreur.

Squencement
Tableau III.8 Description du cas dutilisation Visualiser lhistorique des mouvements

40

III.3 Analyse fonctionnelle

Conclusion
Dans ce chapitre, nous avons dgag les exigences de la solution propose et nous avons
dfini les spcifications fonctionnelles du projet.
Nous pouvons passer prsent la branche technique qui va se charger de prsenter les besoins
techniques indispensable au dveloppement de notre projet.

41

Chapitre IV
Conception et architecture de la plateforme
" Un modle est, par dfinition, une simplification de la ralit. "

Plan
1

Architecture globale de la plateforme . . . . . . . . . . . . . . . . .

42

Architecture globale et conception du middleware

44

. . . . . . . . .

2.1

Conception globale du middleware

. . . . . . . . . . . . . . . . . . . 45

2.2

Conception dtaille du middleware . . . . . . . . . . . . . . . . . . . 45

Architecture globale et conception de lapplication web . . . . . .

51

3.1

Conception globale de lapplication web . . . . . . . . . . . . . . . . . 51

3.2

Conception dtaille de lapplication web . . . . . . . . . . . . . . . . 52

Introduction
Afin de dtailler les besoins de notre projet, nous abordons tout au long de ce chapitre de
prsenter une conception claire et bien structure de notre application en se basant sur le langage
de modlisation UML. Dans un premier temps, nous nous intressons la conception globale
du systme en dfinissant larchitecture de dveloppement adopte. Ensuite, nous passons la
conception dtaille qui sera illustre par des diagrammes de classes et quelques diagrammes
de squence.

Architecture globale de la plateforme

Dans cette section, nous allons prsenter larchitecture globale de notre application et les
diffrents modules quils la compose travers le diagramme de dploiement. Tenant compte
des exigences dfinis dans le chapitre prcdant nous avons conu une architecture flexible et
hautement confortable, comme le montre le figure IV.1

42

IV.1 Architecture globale de la plateforme

Figure IV.1 Architecture globale de la plateforme de contrle

Notre Solution se dcompose en trois couches : hardware , middleware et mtier( applications web).
Diagramme de dploiement
Le diagramme de dploiement est une vue statique qui sert reprsenter lutilisation de linfrastructure physique par le systme et la manire dont les composants du systme sont rpartis
ainsi que leurs relations entre eux.

43

IV.2 Architecture globale et conception du middleware

Figure IV.2 Diagramme de dploiement global

Architecture globale et conception du middleware

Dans cette section, nous allons prsenter larchitecture globale du middleware et les diffrents
modules quils la compose et nous dressons les diagramme de classes. Puis, nous dtaillons
quelques diagrammes de squence .

44

IV.2 Architecture globale et conception du middleware

2.1

Conception globale du middleware

Comme il est dcrit dans le chapitre de ltude pralable, le middleware est charg de grer,
de collecter et de mettre en forme les donnes pour lapplication finale.

Figure IV.3 Architecture globale du middleware

La figure IV.3 montre que notre middleware implmente le standard EPCglobal.

2.2

Conception dtaille du middleware

Dans cette section nous prsentons les diagrammes de classe du middleware et de ses principaux modules .
2.2.1

Diagramme de classe du middleware

Le diagramme de la figure IV.4 prsente une combinaison des packages assurant la gestion
de notre middleware.

45

IV.2 Architecture globale et conception du middleware

Figure IV.4 Diagramme de classe du middleware

Les donnes des vnements enregistrs par le lecteur sont envoys au middleware progressivement, ils seront filtrs et enrichis avec une smantique daffaires tout au long ces niveaux.
Nous allons dtailler quelques packages.
Le package "Capture Application"

46

IV.2 Architecture globale et conception du middleware

Figure IV.5 Diagramme de classe du package Application de capture

Gnralement lapplication de capture gnre les vnements (voir annexe B) pour tre
stocks dans " EPCIS Repository" . A travers une socket , lapplication de capture reoit les
vnements de lecture venants de la couche de filtrage et Collection et stocke dans les fichiers
ECReport.
Le diagramme de la figure IV.5 dcrit larchitecture de notre application de capture. CapptureAppLogger fait lenregistrement systmatique des ECReports entrants. La classe ReportHandlerScheduler a pour rle de faire lordonnancement des ECReports reus de ALE
Engine en utilisant les rgles de gestion de la classe ReportManager. Tandis que ReportHandler soccupe de gestion des ces ECReports.
Finalement ReportWriter cre les vnements EPCIS.
Le Package "Verification Module"
Ce package est en relation avec deux modules qui sont :
Module de signature : implment au niveau des tags. Il sert essentiellement signer les messages envoyer. Le standard EPC Gen2 version 2 dfinit plusieurs techniques de signature

47

IV.2 Architecture globale et conception du middleware


(mentionnes dans le chapitre 2). Dans notre cas, on a choisi dutiliser ECC (elliptic curve
cryptography). Cette technique est efficace de point de vu nergie.
Module dagrgation : ce module sert agrger les signatures reues.
Si on suppose que le lecteur reoit deux paquets 1=1,1 , ... 1.n et 2=2,1 , ..., 2,n
prvenant de deus tags T1 et T2 avec leurs signatures Sig (Kpr ,1 , 1) et Sig (Kpr ,2 , 2)
avec Kpr est un cl priv.
Le lecteur doit faire lagrgation de ces signatures pour obtenir une nouvelle signature Sig (Kpr
, 1 + 2) tel que :
Sig (Kpr , 1 + 2 ) = f (Sig (Kpr ,1 , 1), Sig (Kpr ,2 , 2)) avec est une fonction dagrgation choisie
Lquation ci-dessus signifie que la signature obtenu est homomorphique. En effet, la vrification de Sig (Kpr , 1 + 2 ) implique obligatoirement la vrification de Sig (Kpr ,1 , 1) et
Sig (Kpr ,2 , 2).
Cette nouvelle technique garantie lauthentification et le privacy vu lutilisation de signatures.
En outre, lagrgation de ces signatures nous aide optimiser les communications entre le lecteur et le middleware.
Dans le serveur FC nous avons conu un module de vrification pour vrifier les signatures
des tags

48

IV.2 Architecture globale et conception du middleware

Figure IV.6 Diagramme dactivit de module de scurit

Note : Dans lactivit "Agrger les signatures Sig(Kpr, ) " , Sig(Kpr, ) = f i=0 , i=n
(Sig(Kpr ,i, i))

49

IV.2 Architecture globale et conception du middleware


2.2.2

Diagramme de squence dobjet

Figure IV.7 Diagramme de squence du fonctionnement du middleware

Le diagramme du figure IV.7 dcrit le fonctionnement du middleware.


Le WebClient est une entit dveloppe en JSP qui a pour rle de configurer le FCServer . Il
dfinit le comportement du middleware pour la collection et le filtrage des donnes RFID et
il spcifie les cycles des vnements RFID qui doivent tre dtects et par quels lecteurs. Ces
informations sont configures dans les fichiers ECspec.xml et LRSpec.xml. Ensuite il indique
ladresse de lapplication de capture qui va ajouter le contexte mtier dans les rapports envoyes
par le middleware avant dtre enregistrer dans la base de donnes.
Aprs lajout du module de vrification le diagramme de squence devient le suivant :

50

IV.3 Architecture globale et conception de lapplication web

Figure IV.8 Diagramme de squence du middleware aprs lajout du module de vrification

Architecture globale et conception de lapplication web

Dans cette partie, nous dcrivons le choix architectural de lapplication web ainsi les diffrents diagrammes de conception UML.

3.1

Conception globale de lapplication web

En gnie logiciel, une application web est une application livre aux utilisateurs partir
dun serveur web par un rseau tel que lInternet ou lIntranet. Les applications web sont trs
populaires grce lubiquit du Navigateur Web comme client.
Notre application est btie selon une architecture client-serveur trois tiers.
Nous avons essay de suivre le modle de dveloppement J2EE. Nous avons trois couches :
Couche Prsentation :correspondant laffichage, la restitution sur le poste de travail,
le dialogue avec lutilisateur.
Couche mtier : correspondant la mise en oeuvre de lensemble des rgles de gestion
et de la logique applicative.

51

IV.3 Architecture globale et conception de lapplication web


Couche donne : correspondant aux donnes qui sont destines tre conserves sur la
dure, voire de manire dfinitive .

Figure IV.9 Architecture de lapplication web

Comme il est clair dans la figure IV.9 prcdente, nous proposons une solution suivant larchitecture MVC ou Modle/Vue/Contrleur.
Le design pattern MVC : Il sagit dun patron de conception dont le but est de garantir
une sparation et un couplage faible entre les entits dune application afin de simplifier la
maintenance et lvolution de la solution. Le stockage des donnes est ainsi isol des actions et
de la prsentation de lapplication. [25]

3.2

Conception dtaille de lapplication web

Aprs la dfinition de larchitecture et des diffrents modules de notre plateforme, il sagit


alors de dresser les diagrammes de classes. Puis, nous dtaillons quelques diagrammes de squence correspondant aux scnarios les plus significatifs.

52

IV.3 Architecture globale et conception de lapplication web


3.2.1

Diagramme de package

Nous avons organis le systme en des paquetages afin de mieux le structurer et pour
faciliter la comprhension de ses fonctionnalits. La description dtaille de chaque paquetage
est labore dans le paragraphe suivant.

Figure IV.10 Diagramme de package de lapplication web

Vue : il contient les fichiers de vue .


Servlet : Le contrleur prend en charge la gestion des vnements de synchronisation pour
mettre jour la vue ou le modle et les synchroniser. Il reoit tous les vnements de la vue et
enclenche les actions effectuer.
Modele : Il contient les modles de donnes ncessaires pour le fonctionnement de lapplication.
Service : Il englobe toutes les oprations de traitement des donnes (ajout, modification,
suppression et recherche) ncessaires pour le fonctionnement de lapplication.

53

IV.3 Architecture globale et conception de lapplication web

DAO : Il contient la logique daccs aux donnes.


Connexion : Il fait la connexion aux bases de donnes existantes.

3.2.2

Diagramme de classe de lApplication Web

Un diagramme de classes dcrit les types des objets composant un systme et les relations
entre eux. Ce dernier reprsente galement les proprits, les oprations des classes, ainsi que
les contraintes qui dpendent de la faon dont les objets sont connects. Dans les parties qui
suivent nous prsentons des modles rduits des diagrammes de classes de notre application vu
la difficult de mettre tout les dtails dans un notre rapport.

Figure IV.11 Diagramme de classe du package Mtier

54

IV.3 Architecture globale et conception de lapplication web

Figure IV.12 Diagramme de classe du package Service

3.2.3

Diagramme de squence dobjet

Lobjectif du diagramme de squence objets est de reprsenter les interactions entre les
objets en indiquant la chronologie des changes.

55

IV.3 Architecture globale et conception de lapplication web

Figure IV.13 Diagramme de squence ajout Outillage

56

IV.3 Architecture globale et conception de lapplication web

Figure IV.14 Diagramme de squence Grer Alerte par le ResponsebleStock

Note : Pour le dernier cas [ Alerte = LocalObjet = ! LocalAllou ] objet signifie ouvrier,
produit ou outil.
Le responsable peut recevoir un mail et une notification sur son smart phone Androde.
Pour ce faire nous avons conu cette partie comme suit :

57

IV.3 Architecture globale et conception de lapplication web

Figure IV.15 Diagramme de squence EnvoyerNotifAndroid

Ce scnario est excut si y on a une alerte dclenche ladministrateur ou au responsable


de stock.
Nous avons intgrer un module de visualisation des produits en temps rel notre application. En effet le but de ce module tait de reproduire sur un plan dtaill le parcours dun
produit.

58

IV.3 Architecture globale et conception de lapplication web

Figure IV.16 Diagramme de squence VisualiserMap

LemulateurTag& Reader est lentit qui va simuler notre usine y compris les tags et
les lecteurs . Elle envoie le codeEPC vers FCServer qui va son tour le renvoyer vers Active
MQ.
Ce dernier envoie le code EPC vers NotifyRessource pour gnrer les notifications.
Sil sagit dun ArrivedTag cest dire lobjet tagu va entrer dans le champ de lecture on
lajoute dans le Map , si non on le supprime du Map.

Conclusion
Dans ce chapitre nous avons prsent larchitecture globale de lapplication ainsi que la
conception des diffrents modules de notre solution. La phase de conception nous a permis de
dcrire, de manire globale et dtaille, le fonctionnement dsir du systme afin den faciliter
la ralisation et la maintenance. Dans le prochain chapitre, nous passerons une description
des choix technologiques, lenvironnement du travail et ltat de la ralisation du projet.

59

Chapitre V
Implmentation de la plateforme de contrle
" Sil existe une faon de faire planter un systme, alors ce systme plantera tt ou tard. "

Plan
1

Environnement et outils de travail . . . . . . . . . . . . . . . . . . .

60

1.1

Environnement matriel . . . . . . . . . . . . . . . . . . . . . . . . . . 60

1.2

Environnement logiciel

1.3

Choix technologique . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

. . . . . . . . . . . . . . . . . . . . . . . . . . 61

Architecture technique de la solution . . . . . . . . . . . . . . . . .

67

Travail ralis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

68

3.1

Plateforme de contrle . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

Introduction
Dans ce chapitre, nous prsentons la partie ralisation et la partie de mise en oeuvre des
diffrents composants dcrits au niveau du chapitre prcdent. Dans un premier temps, nous
prsentons lenvironnement matriel et logiciel ainsi larchitecture de notre solution . Dans un
second temps, nous dcrivons le travail ralis en dtaillant quelques captures dcrans des
fonctionnalits ralises.

Environnement et outils de travail


Pour la ralisation de ce travail, nous avons eu recours aux environnements suivants.

1.1

Environnement matriel

Notre solution a t dveloppe laide dun micro-ordinateur DELL INSPIRON 15 ayant


les caractristiques suivantes :
Processeur : Intel Core (TM) i5 @ 1.60 GH 2.3 GHZ.
Disque dur de capacit de 1000 Go.
Mmoire installe RAM : 6GO.

60

V.1 Environnement et outils de travail


Carte graphique AMD Radeon HD 7670M.
Ecran LCD 15, 6.
Windows 7 Professionnel.

1.2

Environnement logiciel

Afin de mettre en place notre plateforme, nous nous sommes servis de lenvironnement
logiciel prsent l dessous :
1.2.1

Outils de modlisation

StarUML 5.0 : Cest un logiciel de modlisation UML cd comme open source par son
diteur, la fin de son exploitation commerciale, sous une licence modifie de GNU GPL
[26].
MiKTex 2.9, TeXnicCenter : Outil de rdaction du prsent rapport.
Dia : cest un logiciel libre de cration de diffrent types de diagramme : diagramme de
flux, diagramme de circuit lectrique, diagramme UML, etc. Il poursuit des buts similaires
Microsoft Visio.
Microsoft Visio : c est un logiciel de diagrammes et de synoptique pour Windows
qui fait partie de la suite bureautique Microsoft Office mais se vend sparment. On peut
ainsi crer diffrent types de diagramme [27] .
1.2.2

Outils de dveloppement

NetBeans 8.0.2 :
Nous avons choisi NetBeans comme Environnement de Dveloppement Intgr(EDI) open
source lanc par SUN en juin 2009 qui permet de dvelopper des applications Java, PHP, C,
C++ et Ruby. Il comprend toutes les caractristiques dun IDE moderne (diteur en couleur,
projets multi-langage, refactoring, diteur graphique dinterfaces et de pages Web) [36].

Figure V.1 Logo du Netbeans [36]

Eclipse 4.5 pour LLRP commander :


Eclipse est un environnement multi-langage de dveloppement comprenant un environnement
de dveloppement intgr (IDE) et un plug-in extensible systme. Il est crit principalement

61

V.1 Environnement et outils de travail


en Java et peut tre utilis pour dvelopper des applications en Java et, par le biais de divers
plug-ins, autres langages de programmation, y compris Ada, C, C + +, COBOL, Perl, PHP,
Python, Ruby [37].
Nous avons ajouter le plugin LLRP Commander afin de configurer nos lecteurs via le protocole
LLRP.

Figure V.2 Logo dEclipse [37]

Eclipse pour RCP et RAP Developers :


Un ensemble complet doutils pour les dveloppeurs qui souhaitent crer des plug-ins Eclipse,
les applications clientes ou plate-forme des applications distance (RCP + RAP), plus Mylyn,
et un diteur XML[34].
Nous avons utilis cette version dEclipse pour excuter le designer Rifidi partir de son code
source vu que le Rifidi designer est crit en Java.

Figure V.3 Logo dEclipse RCP & RAP Developers [34]

SDK Android :
Android SDK est indispensable pour dvelopper sous Android, cest un kit de dveloppement
cre pour tre intgr dans un IDE, il offre un ensemble doutils ncessaire pour le dveloppement et le test comme le ADT, le compilateur, lmulateur, le DDSM ?
1.2.3

Outils de la mise en place du middleware

Plateforme
Fosstrak Le middleware Fosstrak (Free and Open Source Software for Track and Trace)
anciennement Accada est un projet cr par lETH de Zrich en collaboration avec lAutoID Lab. Fosstrak est open-source , il implmente les spcifications du standard EPCglobal
networking. [30]

62

V.1 Environnement et outils de travail

Figure V.4 Logo Fosstrak [30]

Pourquoi Fosstrak
Avant de le mettre en place nous avons entrepris une tude comparative des middlewares opensource existant sur internet, aprs cette tude nous nous sommes rendu compte quil existe
plusieurs solution open-source. Nous avons rcupr les middlewares les plus utiliss.
Nous avons rcapitul les caractristiques de ces solutions dans le tableau V.1
Nom

Famille

Langage

dti-

cible

Filtrage

Agrgation

Persistance

modulaire

Logiciel

Documen

Nombre

Libre

tation

maxi-

quettes

mums des

support

lecteurs

Fosstrak

EPC
Networking

Java

oui

oui

oui

oui

oui

oui

illimit

Aspire

EPC
Networking

Java

oui

oui

oui

non

oui

non

limit

Rifidi

EPC
Networking

Java

oui

oui

non

non

non

non

illimit

Tableau V.1 Caractristiques de quelques exemples dintergiciels RFID [31]

Sur cette tude on a bas notre choix , de plus le fait que Fosstrak soit ouvert et encore en
version Alpha a provoqu notre enthousiasme.
Le problme majeur des autres middlewares cest quils ne sont pas modulaires de ce fait il est
difficile de les adapter aux besoins des utilisateurs comme la expliqu John Burnell "Middleware needs to be modular, easy to deploy, and able to be put in many places, because supply
chain activity takes place all over" [32].
Le but du Fosstrak est de mettre disposition une plateforme RFID qui sintgre au maximum et le plus facilement dans lenvironnement dune chaine de distribution.
Technologies utilises par Fosstrak
Les webservices du Fosstrak sont gnrs et maintenus avec Maven, logiciel libre cre par
la fondation Apache. Configurable via des technologies XML, et de plus il est extensible ce qui
nous permet dimplmenter des modules.
Toujours bases sur des standards, Fosstrak utilise majoritairement les technologies XML pour

63

V.1 Environnement et outils de travail


ses interfaces. Les mthodes de transport sont principalement en post sur http.
Note : Larchitecture du Fosstrak ainsi ses principales caractristiques sont dcrites dans lannexe C.
Rifidi Parmi les middlewares open-source quon a tudi , il y a le middleware Rifidi. Nous
utilisons son mulateur pour tester notre plateforme ainsi son dsigner pour visualiser notre
systme RFID.
Lutilisateur peut mettre en place sa chane de production avec les transporteurs, placer une
grille de lecture et voir le comportent de ses produits dans cet environnement.

Figure V.5 Logo Rifidi [33]

1.2.4

Serveur dapplication

Glassfish 4.2
GlassFish est un serveur dapplications certifi Java EE. Son dveloppement a t initi
lorsque Sun a ouvert le code de son serveur dapplications pour le licencier en Open Source. Il
utilise le moteur de persistance dOracle, TopLink Essentials.
GlassFish est constitu de :
un serveur web ddi au service de fichiers, cest--dire des pages HTML statiques,
images, vidos, ...etc.
un conteneur de servlets hbergeant des applications composes de servlets et/ou JSP.
un conteneur dEJB, pour la gestion des composants stateless, stateful, MDB et entity
beans ;
limplmentation de lAPI de persistance JPA dOracle (TopLink Essentials).
1.2.5

Outil dadministration de la base de donnes

phpMyAdmin Dans ce projet nous avons utilis phpMyAdmin pour grer les bases de
donnes MYSQL.
phpMyAdmin est une application web qui permet de grer un serveur de bases de donnes
MySQL [35].
Dans un environnement multi-utilisateurs, cette interface crite en PHP permet galement de

64

V.1 Environnement et outils de travail


donner un utilisateur un accs ses propres bases de donnes.
Principales fonctionnalits :
maintenance du serveur, des bases et des tables,
gestion des utilisateurs MySQL et de leurs privilges,
importation de donnes dans divers formats,
exportation de bases de donnes dans divers formats,
cration, suppression et modification de bases de donnes, tables, champs, index,
excution et mise en signet de requtes SQL,
cration de requtes avec Query-by-example (QBE),
synchronisation de deux bases de donnes rsidant sur le mme serveur ou distantes,
support de la rplication.
Pour ce faire, il doit tre connect un serveur MySQL.
SGBD : MySQL MySQL est un serveur de bases de donnes relationnelles SQL dvelopp dans un souci de performances leves en lecture. Il fait partie du quatuor LAMP (Linux,
Apache, MySQL, PHP). Il est multithreads et multi-utilisateurs. La base de donnes doit offrir
un vaste panel de fonctionnalits et mme si leur usage est rarement ncessaire, les avoir
disposition ainsi que leurs documentations reprsentent un lment de confort en termes de
mise en oeuvre et dadministration.
Pour choisir la bonne base de donnes, il faut prendre en considration, en plus des facteurs
techniques, dautres facteurs pouvant affecter son bon fonctionnement tels que :
la richesse fonctionnelle du SGBD
le type daccs aux donnes (dcisionnel, OLTP, reporting, mixte)
la politique de lentreprise
le budget disposition
la politique scuritaire
les comptences acquises en termes de dveloppement et dadministration
les architectures logicielles et matrielles.
Nous avons choisi MySQL en se basant sur les critres cits ci-dessus.
1.2.6

Conteneur Web

Apache Tomcat
Il est un conteneur web libre de servlets et JSP Java EE. Il implmente les spcifications des
servlets et des JSP, il est paramtrable par des fichiers XML et des proprits, et inclut des
outils pour la configuration et la gestion. Il comporte galement un serveur HTTP [38].

65

V.1 Environnement et outils de travail


1.2.7

Autres

Gantt Project cest un outil permettant de grer les projets sur le modles de Gantt.
Lapplication permet de dcomposer le projet en arborescence et dassigner des ressources
chacune des tches prvues au planning. Il est possible de crer des dpendances entre les
activits. Cette fonctionnalit se rvle indispensable lorsque le travail accompli sur une tche
est ncessaire pour une autre partie du projet [28].
Scrumwise
Scrumwise a t conu pour Scrum, la mthode agile la plus populaire. Il senrichit autour
des piliers de Scrum : item, Backlog, Sprint, ScrumMaster et product Owner. Loutil aide
appliquer les pratiques agiles essentielles et guide les quipes pendant leurs travails [29].

1.3

Choix technologique

Les premires questions que tous les programmeurs et chefs de projets se posent avant de
commencer dvelopper une application sont celles concernant les choix techniques du langage
de programmation et des Frameworks utiliss. Pour ceci et avant dentamer la ralisation, nous
allons tudier de plus prs les techniques utilises pour raliser notre application. Nous prsentons dans cette section les diffrents langages de programmation que nous avons utiliss afin de
raliser notre projet savoir :
HTML5
HTML5 (HyperText Markup Language 5) est la dernire rvision majeure dHTML. Il spcifie deux syntaxes dun modle abstrait dfini en termes de DOM : HTML5 et XHTML5.
Le langage comprend galement une couche application avec de nombreuses API, ainsi quun
algorithme afin de pouvoir traiter les documents la syntaxe non conforme. Dans le langage
courant, HTML5 dsigne souvent un ensemble de technologies Web (HTML5, CSS3 et JavaScript) permettant notamment le dveloppement dapplications [39].
JavaScript
JavaScript est un langage de programmation de scripts principalement employ dans les pages
web interactives mais aussi pour les serveurs. Cest un langage orient objet prototype, cest-dire que les bases du langage et ses principales interfaces sont fournies par des objets qui
ne sont pas des instances de classes, mais qui sont chacun quip de constructeurs permettant de crer leurs proprits, et notamment une proprit de prototypage qui permet den crer
des objets hritiers personnaliss. En outre, les fonctions sont des objets de premire classe [40].
JSP

66

V.2 Architecture technique de la solution


Les pages JSP sont une des technologies de la plate-forme Java EE les plus puissantes, simples
utiliser et mettre en place. Elles se prsentent sous la forme dun simple fichier au format
texte, contenant des balises respectant une syntaxe part entire. Le langage JSP combine la
fois les technologies HTML, XML, servlet et JavaBeans en une seule solution permettant aux
dveloppeurs de crer des vues dynamiques[41].
CSS3
Cascading StyleSheets le concept des feuilles de style en cascade est apparu avec la publication par le W3C. La version CSS3 est lvolution de CSS2, avec tout un tas de nouveauts, qui
permet darrondir les images, faire des ombres sur les div, des ombres sur du texte, des polices
de caractres plus fun, des bordures dimages, etc et surtout lajout de lanimation.
Admin LTE
cest une collection doutils utile la cration de sites web et applications web. Cest un ensemble qui contient des codes HTML et CSS, des formulaires, boutons, outils de navigation et
autres lments interactifs, ainsi que des extensions JavaScript en option. Cest lun des projets
les plus populaires sur la plate-forme de gestion de dveloppement GitHub.
Active MQ :
Cest une implmentation de JMS ( Java Message Service) qui permet denvoyer et de recevoir
des messages de manire asynchrone entre applications ou composants Java.

Architecture technique de la solution


La figure v.6 illustre larchitecture globale de notre application :

67

V.3 Travail ralis

Figure V.6 Architecture technique de la plateforme

Note : Pour savoir le rle du fichier ROSpec voir annexe D.


Notre Architecture se compose de trois parties :
Une application mtier : une application web responsable de lexcution des processus
mtiers globaux de lentreprise, tels que la gestion du stock , lexpdition et la rception des
produits, lanalyse de lhistorique...
Un middleware RFID (Fosstrak) : destin simplifier laccs et lexploitation des informations stockes dans des tiquettes RFID.
Un mulateur (Rifidi designer) : Il permet lmulation de lecteurs et dtiquettes. Ainsi
il cre des workflows visuels pour simuler des processus RFID.

Travail ralis

Cette partie est consacre la prsentation de la solution dveloppe durant les cinq mois
de stage. Nous allons dans ce qui suit simuler le fonctionnement des diffrents modules travers
des captures dcrans commentes.
Les fonctionnalits attendues par notre systme peuvent tre classes en trois grandes catgories :
lmulation dun environnement qui contient un rseau de lecteurs et des tags RFID, la collecte,

68

V.3 Travail ralis


le filtrage et le stockage des donnes RFID et en fin lexploitation de ces donnes RFID par
lapplication de gestion des objets connects.

3.1
3.1.1

Plateforme de contrle
Emulation de lenvironnement RFID

Vue quon na pas pu fournir des matriels pour notre environnement RFID nous avons
choisit dutiliser Rifidi designer afin de tester notre middleware ainsi de voir le comportement
des objets tagus dans cet environnement.
Nous avons dfini le scnario suivant avec le designer afin de simuler le comportement de notre
plateforme .

Figure V.7 Prototype de lusine

3.1.2

Mise en place du middleware Fosstrak

Comme il est indiqu dans lannexe C Fosstrak est compos de quatre modules savoir
TDT, ALE, EPCIS et LLRP Commander. Dans notre projet nous navons implment que
trois modules : ALE, EPCIS et LLRP Commander. Le module TDT est utilis en cas dautres
formats des identifiants EPC, ce qui nest pas notre cas.
Afin dassurer la communication entre les modules du Fosstrak nous avons configur : ECspec,
LRspec, ROspec et implment : Capture Appliction et le module de vrification comme il est

69

V.3 Travail ralis


indiqu dans la figure V.6
ECspec
Nous avons implment le fichier ECspec.xml de tel sorte quil dfinit les lecteurs logiques inclus dans lopration, la priode de lecture pour excuter cette opration toutes les 10000ms,
et cette opration dure 9500ms.
la dernire partie dcrit ce qui doit contenir le rapport : nous avons donc remont les identifiants des tiquettes prsentes dans les champs des lecteurs ( CURRENT ), nous pouvons
aussi mettre ADDITIONS ou DELETIONS , pour remonter respectivement les identifiants des tiquettes arrivant dans le champ du lecteur ou quittant ce champ durant la priode
de lecture ou depuis le dernier rapport . Nous avons dfinit aussi les patrons de groupement
des identifiants :
<pattern>u r n : e p c : p a t : s g t i n 96 :3.X .X. * . *</ pattern> tel que les X ici
dans les champs de filtre et de prfixe de compagnie et les * pour le numro de la classe
de lobjet et son numro de srie indiquent quon veut grouper les identifiants par filtre et
compagnie identique, mais objets diffrents. Par consquent, ce patron groupe les identifiants
par fabriquant.
Une fois que la spcification est envoye au F&C Server puis valide, LALE va effectuer
lopration et envoyer le rapport (appel ECReports).
Note : Pour consulter notre fichier ECspec.xml consulter lannexe A figure A.1
LRspec
Afin de configurer nos lecteurs physiques nous avons implment des fichiers LRspec.xml .
Nous avons dfini pour chaque lecteur le type dadaptateur utilis qui est LLRP dans notre cas,
ainsi ses caractristiques savoir son nom, son adresse IP et son port. Finalement nous avons
indiqu au F&C server que le lecteur est bien initialis. Dans lannexe A figure A.2 nous avons
mis la configuration du lecteur physique readerZonz1.1 .
ROSpec
Nous avons configur le module LLRPD Commander par le fichier ROSpec.xml en indiquant
aux nos quatre lectures les donnes traiter et quand vont tre traits. Voir annexe D

70

V.3 Travail ralis


Capture Application
Lapplication de capture par dfaut du Fosstrak reoit les ECReports des couches infrieurs
aprs elle les traite. Ce qui rend le traitement des rapports reus trs lourd sur tout lorsque
nous grons des milliers de tags. Ceci peut provoquer un surcharge des ressources et apporter
des pertes des ECReports qui va donc influencer sur le rendement du systme de contrle do
la ncessit de grer les flux des donnes reues des couches infrieurs.
pour cette raison nous avons chang lapplication de capture du Fosstrak en implmentant
une application qui dcouple la rception et le traitement des vnements de lectures. Cette
fonctionnalit est assur par lajout dun module qui fait la gestion et lordonnancement des
donnes reues.
Nous avons mis en place une classe Listener qui fonctionne avec le socket TCP dont le rle
est de lire les ECReports entrants et de les enregistrer dans une table MySQL.
Cette dernire met en oeuvre une file dattente FIFO pour grer en parallle les objets reus
travers le Handler.
De cette manire nous avons fournit loptimisation et la fiabilit notre application.
Nous avons configur FCserver en utilisant lentit Webclient du Fosstrak.

71

V.3 Travail ralis

Figure V.8 de configuration du serveur de filtrage et collecte

La configuration du LLRP Commander se fait par LRSpec par la mthode define(String


readerName, LRSpec spec).
Aprs cette tape, lchange de messages avec lALE middleware Fosstrak devrait tre observ
dans le Rifidi designer.
Aprs nous avons dfini le ECSpec pour informer lALE comment les tags lues soit filtrs et
agrgs et cela se fait en invoquant la mthode define (String SpecName, String specFilePath).
Dans cette tape nous avons besoin de dfinir un Listener en inscrivant notre application
de capture l ECSpec subscribe(String specName, String notificationUri) pour recevoir les
ECReports.
Afin dtablir une connexion entre notre prototype conu par Rifidi designer et LLRP Commander nous avons connect ce dernier l adaptateur distant des lecteurs, aprs nous avons
envoy ROSpec aux lecteurs physiques dans la figure V.9 nous avons prsent le cas du lecteur
readerZon2.2 .

72

V.3 Travail ralis

Figure V.9 Interface de LLRP Commander du Fosstrak

Aprs lenvoi du ROSpec au lecteur readerZon2.2 , ROAccessReports affiche les informations


que nous avons dsign dans ROSpec des tags lus par ce lecteur.

Figure V.10 ROAccessReports du lecteur readerZon2.2

Aprs que les tags lus sont filtrs et collects comme spcifi dans ECSpec, ils seront dlivrs
par lALE Engine du Fosstrak sous la forme des ECReports notre application de capture.

73

V.3 Travail ralis


Le stockage des donnes de capture dans la base de donnes se fait automatiquement lorsque
la configuration a t correctement effectue.
Limplmentation de larchitecture du Fosstrak na pas t dune grande simplicit . Comprendre comment les modules simbriquent entre eux et les faire fonctionner ont ncessit un
temps plus long que prvu.

3.1.3

Lapplication web du management

Le plus important module dans notre plateforme est lapplication web vue quelle va grer
les donnes filtres et collectes par le middleware. Cest un site web cr avec J2EE qui permet aux utilisateurs de notre plateforme de crer des comptes utilisateur pour suivre les objets
connects ainsi pour autre fonctionnalits divers.

Interface daccueil Au dmarrage de lapplication, la page daccueil saffiche et elle permet


au utilisateur soit de se connecter soit de sinscrire.

Figure V.11 Interface dAccueil

74

V.3 Travail ralis

Figure V.12 Interface dauthentification

Cest la premire page qui saffiche lutilisateur (administrateur ou Responsable du Stock),


elle lui offre la possibilit de sauthentifier en saisissant son login et mot de passe obtenu par
son inscription. Ici dans la figureV.13 cest le cas dauthentification dadministrateur.

Figure V.13 Interface despace Administrateur

La figure ci-dessus illustre le tableau de bord de ladministrateur tel quil peut grer les
objets connects les alertes ainsi il peut visualiser le Map et les logs.
Gestion dAlerte Nous avons dfini des scnarios pour la gnration des alertes. Notre
systme envoie un message vers lutilisateur soit son e-mail soit par une notification sur son
smart phone Androde.
Aprs la rception de lalerte lutilisateur doit choisir une raction pour rsoudre le problme.

75

V.3 Travail ralis


Notification Androde Nous avons implmenter ce module laide de service GCM
(Google Cloud Messaging) qui est un service gratuit , il nous a permis denvoyer les notifications depuis notre serveur application vers des appareils androdes.
Nous nous sommes enregistrs auprs du service GCM, en crant une cl serveur.

Figure V.14 Interface denregistrement au service GCM

La figure v.15 illustre la notification reu par le responsable du stock lorsque la quantit du
stock est infrieur au seuil.

76

V.3 Travail ralis

Figure V.15 Notification par lapplication Androde

Gestion dalerte
En cas dalerte ladministrateur reoit un e-mail ou une notification sur son smart phone, ainsi
notre application lui permet de choisir une raction

Figure V.16 Interface de Gestion des alertes

77

V.3 Travail ralis


Map Afin de visualis notre prototype et de suivre le parcours des produits tagus nous
avons conus un Map qui va nous afficher en temps rel lemplacement des objets lintrieur
de lusine simule.

Figure V.17 Interface du prototype linstant "t"

Lorsque lutilisateur veut visualiser la carte linstant "t" il va voir la Figure V.18

Figure V.18 Le Map visualis linstant "t"

Gnration des rapport Lapplication permet ladministrateur et au responsable du stock


de suivre les chances travers cette interface.

78

V.3 Travail ralis

Figure V.19 Interface de visualisation des logs

Cette interface lui permet aussi de gnrer aussi les logs sous forme dun fichier world

Conclusion
A ce stade, nous atteignons la fin de ltude du projet. Au cours de ce chapitre, nous avons
dfini en premier lieu, lenvironnement de travail logiciel .Ensuite, nous avons dcrit notre choix
des technologies pour le dveloppement. Enfin, nous avons prsent les captures de diffrentes
interfaces de notre plateforme .

79

Conclusion Gnrale et Perspectives


Aujourdhui lenvironnement des entreprises est caractris par lmergence de plusieurs
vnements imprvus. Face cette instabilit , ces entreprises se voient dans lobligation de
sadapter lincertitude et davoir une raction immdiate ces changements.
Do la ncessit de la disposition dune information continue afin dassurer une meilleur visibilit et traabilit des objets connects tout au long de la chaine dapprovisionnement. En
rponse cette ncessit, des technologies de capture et didentification automatique des donnes ont vu le jour.
Les technologies didentification automatique et plus spcifiquement, la technologie mergente didentification par radiofrquence (RFID) est la plus fiable qui va profondment transformer les processus daffaires de la chane dapprovisionnement.
Dans ce contexte, notre projet avait un objectif de mettre en place un systme de suivi
scuris des objets connects dune usine, en se basant sur la technologie RFID .
Pour aboutir ce rsultat , nous avons dabord commenc par une tude sur la technologie
RFID et les diffrents termes en relation. Puis, nous avons dtaill les besoins fonctionnels
et techniques de notre projet. Aprs, nous avons prsent la conception en commenant par
larchitecture adopte, pour aboutir par la suite une conception dtaille, qui met laccent
sur laspect statique et dynamique du systme. Enfin, nous avons abord ltape de ralisation
au cours de laquelle nous avons traduit notre modlisation conceptuelle en une implmentation
physique moyennant les diffrentes technologies et techniques choisies.
Faute du matriel (les lecteurs et les tags) , nous nous sommes orients vers lapproche de
simulation et nous avons pu atteindre la majorit des objectifs fixs.
La mise en place de la plateforme ainsi lutilisation des outils de simulation nous a permis
dacqurir des connaissances importantes et suffisantes pour une implmentation relle .
Grace son caractre extensible (modulaire) , notre plateforme peut tre enrichi par dautre
fonctionnalits savoir : linter-organisation qui permettra un suivi de lobjet tout au long
son cycle de vie en intgrant le module ONS du standard EPCglobal Networking, linternet
des Objets par lajout dune adresse ip au tag et un autre module de scurit qui assure une
protection entre le middleware et les lecteurs.
Nous pouvons aussi amliorer notre application web en la rendant accessible par les autres
employs mais en limitant leur des droits daccs.

80

Acronyme

AIDC : Automatic Identification and Data Capture


ALE : Application Level Event
DAO : Data Access Object
EC : Event Cycle
ECReport : Event Cycle Report
ECSpec : Event Cycle specification
EPC : Electronic Product Code
EPCIS : EPC Informatic Service
FCServer : Filltring and Collecting Server
Fosstrak : Free and Open Source Software for Track and Trace
GCM : Google Cloud Messaging
GS1 : Global Standards One
LLRP : Low Level Reader Protocol
LRSpec : Logical Reader specification
RF : Radio Frequency
RFID : Radio Frequency Identification
UHF : Ultra haute frequency

85

Bibliographique

[1] Socit ITesLab , http://www.iteslab.com/#Company, consult le 03/04/2015.

[2] S.M. Ross.Highsmith, J. (2002). Agile software development ecosystems. Addison-Wesley


Longman Publishing Co, Inc.

[3] ScrumAlliance.Scrum alliance group, 28 Fevrier 2011, http


://www.controlchaos.com/presentations/, consult le 14/04/2015.

[4] Coach, ., Hundermark, F. C. S. P. Meilleur Scrum.

[5] F. Eychenne, La conception logicielle applique au monde physique,


http ://www.latribune.fr/blogs/produire-autrement/20121022trib000726342/,

consult le 14/04/2015.
[6] ISynergie Quantum, Services - iSynergie Quantum Inc,
http://www.isynergie.com/services/, consult le 14/04/2015

[7] V. JEAN-LUC, Traabilit: outils, mthodes et pratiques. Paris, Editions dorganisation,


2005, vol. 237.

[8] S. FOSSO WAMBA, Les impacts de la technologie RFID et du rseau EPC sur la
gestion de la chane d'approvisionnement: le cas de l'industrie du commerce de dtail. 2009.
Thse de doctorat. cole Polytechnique de Montral.

[9] Logistique conseil Cameroun, Traabilit et technologie RFID - Codes barres - 2D,
http://www.logistiqueconseil.org/Articles/Logistique/Techniquestracabilite.htm, consult le 01/05/2015

81

[10] GS1,EPC/RFID, http://www.gs1.org/epc-rfid, consult le 01/05/2015

[11] Etilux, http://etiquettescodesbarres.be/fr/ms/ms/rfid-liege-4000/ms127456-p-29/, consult le 12/05/2015

[12] IGM, RFID - Principe, http://www-igm.univmlv.fr/~dr/XPOSE2012/RFID_Modbus/RFID/principe.html, consult le 12/05/2015

[13] CNRFID, Classification des tags RFID, http://www.centrenationalrfid.com/classification-des-tags-rfid-article-19-fr-ruid-17.html, consult le

12/05/2015

[14] G. FRITZ, Simulation de fautes pour l'valuation du test en ligne de systmes RFID.
2012. Thse de doctorat. Universit de Grenoble.

[15] D. BCHEVET, Contribution au dveloppement de tag RFID UHF et Microondes sur


matriaux plastiques. 2005. Thse de doctorat. Institut National Polytechnique de GrenobleINPG.

[16]I. BELKACEM et N. BAHLOUL, Analyse des donnes d'un systme RFID en vue de
sa sret de fonctionnement. In : 1st International Conference on Information Systems and
Technologies (ICIST 2011). 2011. p. 1.

[17] Amit Rawal, Monash University, Clayton, Victoria, Australia, RFID: The Next
Generation Auto-ID Technology, http://www.microwavejournal.com/articles/7632rfid-the-next-generation-auto-id-technology?v=preview, consult le 15/05/2015

[18] ClearStream , ClearStream RFID Solutions - Fixed RFID Apps,


http://www.clearstreamrfid.com/solutions/, consult le 16/03/2015

[19] JIDELEC, TRACE&#039;IT gestion d&#039;actifs par RFID - Jidelec,


http://www.jidelec.com/trace-it/, consult le 16/03/2015
[20] logismarket , Plateforme de services RFID opre - HubID,
82

http://www.logismarket.fr/hub-one/plateforme-de-services-rfidoperee/3091418412-762978540-p.html, consult le 16/03/2015

[21] C. Duron, S. Satyaveer Singh, J. Porth, Chanes d'approvisionnement :Conception,


contrle et outils, Herms - Lavoisier, 2003, rsum.

[22] BSE ELECTRONIC Solution, La matrise du systme d'information du cycle de


production au suivi logistique, http://www.bse-electronic.com/?page_id=123,
consult le 16/05/2015

[23] ULLDEMOLINS BES, Fanny, et al. Implementation of Fosstrak EPCIS RFID system.
2012.
[24] CNRFID , Ratification de la dernire version du standard EPC Gnration-2 UHF
RFID, http://www.centrenational-rfid.com/actualites-ratification-de-laderniere-version-du-standard-ep-fiche-311-fr-ruid-20.html?numPage=1, consult
le 16/03/2015

[25] zedtux, Designe Pattern MVC, http://blog.zedroot.org/designe-pattern-mvc/,


,consult le 27/06/2015

[26] StarUML, StarUML, http://staruml.io/, Consult le 15/04/2015

[27] Microsoft Visio, Visio, https://products.office.com/frfr/visio?legRedir=true&CorrelationId=a39dbb89-e9cb-4b08-904e-c5d33183c4a2,

consult le 11/05/2015

[28] T. Asana, Octobre 2013, OUTILS DE GESTION DE PROJET.

[29] iceScrum, iceScrum, Open Source Scrum &amp; Agile project manageme nt too ,
http://www.icescrum.org/, consult le 01/04/2015.

[30] Guithub,Fosstrak - Welcome, http://fosstrak.github.io/, consult le 01/04/2015

[31] TOFFALETTI, Sebastiano et SOLDATOS, John. RFID-ROI-SME Project Promises Big Help for
Small Business. RFID Journal, 2010, vol. 14.
83

[32] BURNELL, John. What Is RFID Middleware and Where Is It Needed?.RFIDupdate. com, 2006.

[33] Rifidi wiki,Documentation Guidelines, http://wiki.rifidi.net/index.php?title=Main_Page,


consult le 01/04/2015

[34] Eclipse ,Eclipse for RCP and RAP Developers,


http://www.eclipse.org/downloads/packages/eclipse-rcp-and-rapdevelopers/marsr/, consult le 05/06/2015

[35] Plume , phpMyAdmin | Fiche logiciel PLUME, https://www.projet


plume.org/fiche/phpmyadmin/, consult 12/06/2015

[36] netbeans,NETBEANS_DOWNLOAD_PAGE, https://netbeans.org/downloads/,


consult 12/06/2015

[37] Eclipse, eclipse, https://eclipse.org/users/, consult 12/06/2015

[38] Apache Tomcat, Apache Tomcat Configuration Reference - The Context Container,
https://tomcat.apache.org/tomcat-5.5-doc/config/context.html, consult
12/06/2015
[39] Margaret Rouse, What is HTML5? ,
http://searchsoa.techtarget.com/definition/HTML5, consult 14/06/2015

[40] Additeam, Dfinition de JavaScript Environnement Java Lexique de linformatique,


http://www.additeam.com/SSII/javascript/, consult 14/06/2015
[41] Margaret Rouse, What is JSP? , http://searchsoa.techtarget.com/definition/JSP
,consult 14/06/2015

[42] GROSS, Hannes, WENGER, Erich, MARTN, Honorio, et al. PIONEERa Prototype for
the Internet of Things Based on an Extendable EPC Gen2 RFID Tag. In : Radio Frequency
Identification: Security and Privacy Issues. Springer International Publishing, 2014. p. 54-73.

84

Annexe
lannexe A
EventCycle :
Un cycle de lvnement est la plus petite unit dinteraction entre le client ALE et ALE via
lAPI de lecture.
ECSpec :
Linterface de lecture fournit des mthodes pour grer les spcifications doprations de lecture.
Ces spcifications, appele ECSpecs, dfinissent les lecteurs logiques inclus dans lopration,
ainsi le type didentifiant filtrer et agrger.
ECSpecs est un fichier XML qui dfinit ce que le F& C server doit faire pour gnrer le rapport.
Voila notre fichier ECspec.xml.

Figure A.1 Fichier ECSpec.xml

LRspec Linterface des lecteurs logiques permet de dfinir des groupements de une ou
plusieurs sources de lectures/critures.
Il est ainsi plus facile de dfinir une spcification avec ce seul lecteur logique plutt que de
mettre tous les lecteurs physiques dans le fichier XML. Ces spcifications de lecteurs logiques

86

sont appeles LRspec.


Voila notre fichier LRspec pour la configuration du lecteur physique readerZonz1.1.

Figure A.2 Fichier LRSpec.xml

ECReports :
Un fois que la spcification est envoye au F& C puis valide, lintergiciel va effectuer lopration et envoyer le rapport (appel ECReports).

lannexe B
On distingue quatre types dvnement dans le standard EPCglobal Networking.
ObjectEvent :
Il capture des informations sur un vnement relatif un ou plusieurs objets physiques identifis
par EPC. Il comprend le champ daction ce qui dcrit la relation de lvnement pour le cycle
de vie dEPC (s) nomm dans lvnement. Ses options possibles sont :
ADD : Ajouter EPCs epcList.

87

OBSERVE : Lvnement reprsente une simple observation dEPC (s) nomm dans
lvnement, pas de leur service ou hors service.
DELETE : Les EPCs du epcList sont mis hors service et ne doivent pas tre observs
de nouveau.
AggregationEvent :
Lvnement type AggregationEvent dcrit les vnements qui appliquent aux objets qui ont
t physiquement agrges les unes aux autre.
Dans un tel cas, il ya un ensemble dobjets "contained" qui ont t agrge dans une "containing"
entit qui est destin identifier lagrgation physique lui-mme.
Agrgation signifie une association o il ya une forte relation physique entre les objets contained
et les objets containing tels quils occupent tous au mme endroit au mme moment, jusqu
ce que ils sont agrgs.
Lvnement dagrgation inclut ses deux champs :
parentID : est lURI du parent de lassociation (souvent un "containing " entit). Il est
obligatoire lorsque laction est ADD ou DELETE et lURI peut tre un EPC ou un autre
identifiant tir dun vocabulaire appropri prive.
childEPCs : Une liste non ordonne des EPC des objets contenus.
Ses options possibles sont :
ADD : Les EPCs qui se trouvent dans la liste du childEPCs seront agrger au parentID
durant cet vnement.
OBSERVE : Lvnement reprsente ni ajout ni retrait de child partir de lagrgation,
seule observation, et peuvent tre incompltes, ce qui signifie quil peut y avoir childs qui
font partie de lagrgation mais pas observ lors de cet vnement et ne figurent donc pas
dans le champ de cette AggregationEvent de childEPCs.
DELETE : Les EPC nomms dans la liste child ont t ventiles par le parent lors de
cet vnement. Si le champ est vide tout child peut tre ventiles.
QuantityEvent :

88

Un QuantityEvent capture un vnement qui a lieu par rapport une quantit dtermine dune
classe dobjet. Ce type dvnement peut tre utilis, par exemple, de signaler des niveaux dun
produit dinventaire. Par consquent, le domaine le plus important au sein de lvnement est le
champ de la quantit ce qui dcrit la quantit dobjet dans la catgorie dcrite par lvnement.
TansactionEvent :
Le TransactionEvent de type dvnement dcrit lassociation ou la dissociation des objets
physiques un ou plusieurs transactions commerciales.
Alors que dautres types dvnements ont un champ bizTransactionList optionnel qui peut
tre utilis pour fournir un contexte pour un vnement, lTransactionEvent est utilise pour
dclarer dune manire non quivoque que certains EPC ont t associs ou dissoci avec un ou
plusieurs transactions commerciales dans le cadre de lvnement.
Le champ action dfinit ses options :
ADD
OBSERVE
DELETE

Annexe C
Architecture gnrale
Larchitecture du Fosstrak se base sur le framework EPCglobal.
Elle est dcoupe en quatre modules distincts avec chacun leur couche dinterface leur permet
lchange des donnes.
Le module TDT (Tag Data Translation)
Ce module sert la traduction vers dautres formats des identifiants EPC. Fosstrak LLRP
Commander
Il aide configurer et de grer des lecteurs RFID LLRP .
Fosstrak Filtering and Collection Module [FC]
La partie Filtering and collection permet de rcuprer les informations envoyes par les lecteurs, de les filtrer et de les collecter. Elle permet aussi de crer des lecteurs logiques et de
les paramtrer, donc de grer de manire flexible ces lecteurs et dintervenir sur ceux-ci tout
moment.
Fosstrak EPCIS Repository Module

89

Le module EPCIS Repository est la couche de persistance de lapplication. Il va capturer les


informations, les stocker ainsi que les mettre disposition.
Le Tableau suivant illustre limplmentation du Fosstrak du standard EPCglobal
EPCglobal Networking Standard
Tag Data Standard
Tag Data Translation (TDT)
Tag Protocol EPC UHF Gen 2

No

Fosstrak prjetct
Fosstrk Tag
Data Translation(TDT)
-

Tag Protocol EPC HF

No

Low Level Reader Protocol (LLRP)


Discovery Configuration &
Initialization (DCI)
Reader Management (RM)
Application Level Events (ALE)
EPC Information Services (EPCIS)
Core Business Vocabulary(CBV)

Yes
No

Fosstrak LLRP Commander


-

Yes
Yes(v1.1)
Yes(v1.0.1)
No

Fosstrak LLRP Commander


Fosstrak ALE Middleware
Fosstrak EPCIS
-

No
No (standard in development)
No
No

Object Name Service(ONS)


Discovery Services
Certificate Profile
Pedigree

Implemted by Fosstrak
No
Yes(v1.0)

Tableau A.1 tude comparative entre les approches danalyse dun fichier XML

Annexe D

ROSpec (Reader Operation Specifications) :


Ce sont les commandes des configurations du lecteur, Elles contiennent une liste de commandes
squentielles des oprations dinventaire appel AISpec (Antenna Inventory Specifications).

90

Figure A.3 ROSpec.xml

91

RFID - EPCglobal
RFID
.
RFID
. EPC Gen 2 EPCglobal
Fosstrak RFID
J2EE EPCglobal
.
Fosstrak EPCglobal RFID :

Mise En Place d'une Plateforme de Contrle d'une usine base de la technologie RFID et le
standard EPCglobal
Ce travail met en valeur les apports de lapplication de la technologie RFID dans la chaine
d'approvisionnement vu que l'identification et la traabilit des produits sont devenues des
lments incontournables pour l'amlioration de la production.
Notre projet consiste mettre en place une plateforme de contrle et de suivi des objets
connects l'aide de la technologie RFID et le standard EPCglobal Networking en assurant la
scurit des informations ports sur les tiquette EPC Gen2.
Pour ce faire nous avons mul l'environnement RFID, nous avons mis en place un
middleware Fosstrak qui rpond aux spcifications de l'EPCglobal et enfin nous avons
dvelopper une application J2EE pour exploiter les donnes traites et collectes par le
middleware.
Mots-cls : identification, RFID, traabilit, EPCglobal, tag EPC Gen2, middleware,
Fosstrak, scurit.

Implementation of a control platform based on RFID and the standard EPCglobal


This project studies the contributions of the application of RFID technology in the Supply
Chain as the identification and traceability have become essential elements to improving
production.
Our project consists to develop a platform of control and tracking the connected objects using
RFID technology and the EPCglobal standard Networking ensuring the security of
information carried on the EPC Gen2 tag.
The purpose of our project is to emulate an RFID environment, set up a Fosstrak middleware
that responds to the specifications of EPCglobal and finally implement a J2EE application to
exploit the data collected and processed by the middleware.
Key Word: identification, RFID, tracking, EPCglobal, tag EPC Gen2, middleware, Fosstrak,
privacy.
Intitule et adresse complte de lentreprise :
Entreprise : iTesLab
Adresse : Parc El Ghazala des Technologies de la Communication, Bloc N, Route de Raoued
km 3,5 2083 Ariana - Tunisie
Tl. : +21694589991
Email : contact@iteslab.com