sûreté de fonctionnement des systèmes rfid

Transcription

République Algérienne Démocratique Et Populaire
Ministère De L'Enseignement Supérieur Et De La Recherche
Scientifique
Université Es-Sénia Oran - Faculté des Sciences
Département Informatique
Mémoire
Présenté pour l'obtention du diplôme de Magister
Spécialité : Informatique
Option : Ingénierie des Données et des Connaissances
Titre:
Analyse des données d'un système
RFID en vue de sa sûreté de
fonctionnement
P r é s e n t é p a r : Imad Belkacem
Soutenu le
/
/
devant la commission de jury :
Président : Djilali Benhamamouch, Pr. Université Oran
Examinateur : Bouabdellah Kèchar, MC. Université Oran
Examinateur : Larbi Sékhri, MC. Université Oran
Encadré par : Safia Nait Bahloul, MC. Université Oran
Co-encadré par : Oum-El-Kheir Aktouf, MC. Grenoble INP – Esisar
Remerciements
La réalisation de ce mémoire a été possible grâce au concours de plusieurs personnes à qui je
souhaitais adresser mes remerciements les plus sincères.
Je tiens tout d'abord à remercier profondément la directrice de ce mémoire, Mlle Safia NAIT
BAHLOUL, pour sa patience, sa disponibilité et surtout ses judicieux conseils, qui ont contribué à
alimenter ma réflexion.
Je tiens tout à remercier également Mme Oum-El-Kheir AKTOUF, pour avoir encadré cette thèse et
pour les nouvelles idées qu’elle m’a appris.
Je remercie également les personnes qui ont accepté d’évaluer mon travail et m’ont fait l’honneur de
participer à mon jury de thèse :
M. Djilali BENHAMAMOUCH, Professeur à l’université d’Oran,
M. Bouabdellah KECHAR, Docteur à l’université d’Oran,
M. Larbi SEKHRI, Docteur à l’université d’Oran.
Mes remerciements vont également au directeur du laboratoire LITIO, M. Yahia LEBBAH, et à l’équipe
IDC du laboratoire.
Je voudrais aussi remercier tous mes professeurs, depuis l’école primaire jusqu’à l’université, qui
m’ont apporté leur savoir – faire et donc contribué de manière indirecte mais importante, à la
réalisation de cette thèse.
J'exprime ma gratitude à tous les consultants et internautes rencontrés lors des recherches effectuées
et qui ont accepté de répondre à mes questions avec gentillesse.
Je dois aussi beaucoup à mes parents, dont les bénédictions m’ont suivie tout au long de cette thèse.
Je leur exprime toute mon admiration, mon affection et ma gratitude.
Je tiens tout spécialement à remercier ma femme Fatiha BELKACEM pour son grand amour, sa
confiance et sa compréhension et surtout pour son soutien et ses encouragements sans condition
depuis toujours …
J'adresse mes plus sincères remerciements à tous mes proches et amis, qui m'ont toujours soutenue
et
encouragée
au
cours
de
la
réalisation
de
ce
mémoire.
Résumé
La technologie RFID (Radio Frequency Identification) fait partie des
technologies d’identification automatique. Les opérations de lecture et de
détection et les mesures des capteurs sont inévitablement soumises aux
erreurs. Nous étudions la tolérance aux fautes dans les systèmes RFID comme
un moyen pour assurer la sûreté de fonctionnement. La tolérance aux fautes
est l'ensemble des moyens pour que le logiciel fonctionne en dépit des
différentes fautes (fautes physiques, fautes de conception, erreurs de
l'utilisateur, fautes intentionnelles …). L’approche que nous développons
consiste à concevoir un système de décision RFID distribué qui détecte et
localise les défaillances en en comparant les résultats des inventaires des
différents lecteurs, d’une part et d’autre part, comparer les résultats des
différents capteurs homogènes en utilisant des techniques statistiques sur les
résultats obtenus et permettre à l’application de détecter l’élément
défectueux, corriger les fautes et continuer son exécution en présence de ces
entraves. Pour tester et évaluer nos méthodes, nous avons conçu un minimiddleware SOARFID basé sur la SOA (Service Oriented Architecture) et nous
avons intégré les modules d’analyse des données dans le module de filtrage et
de collection.
Mots-Clés — Sûreté de fonctionnement, RFID, Tolérance aux fautes,
Middleware, Services web, SOA.
Abstract
The operations of reading and detection of the readers and
measurements of the sensors in a RFID system are inevitably subject
to error. We study the Fault Tolerance (FT) in RFID systems as a mean
to ensure the dependability. The approach that we develop consists to
conceive a fault-tolerant distributed RFID system of decision that
detects and locates faults by comparing the results of the inventories
of different readers, first and second, compare the results of various
homogeneous sensors by using statistical techniques on results and
allow the application to detect the defective item, correct errors and
continue its execution in the presence of these faults.
Keywords — Dependability, RFID, Fault-Tolérance , Middleware, web
Services, SOA.
Table des matières
Introduction
.......................................................................................................................... 1
Chapitre I : INFRASTRUCTURE & MIDDLEWARE RFID
.......................................
I.1. INTRODUCTION ....................................................................................................................
I.2. LES SYSTEMES D'IDENTIFICATION AUTOMATIQUE ..............................................................
I.2.1. Le code barre .......................................................................................................
I.2.2. La reconnaissance optique de caractères ............................................................
I.2.3. Les Smart cards ....................................................................................................
I.2.4. Les systèmes RFID ................................................................................................
I.3. VERS UNE INFRASTRUCTURE DE SUSTÈME RFID ................................................................
I.4. ÉLÉMENTS DE L'INFRASTRUCTURE ......................................................................................
I.4.1. L’étiquette radiofréquence ..................................................................................
a. Les étiquettes passives ....................................................................................
b. Les étiquettes semi-passives ...........................................................................
c. Les étiquettes actives ......................................................................................
I.4.2. Capteur .................................................................................................................
a. L’étiquettes-capteur RFID..................................................................................
b. Capteurs RFID ..................................................................................................
I.4.3. Les lecteurs ...........................................................................................................
I.4.4. Le Contrôleur du Réseau de Lecteur (RNC) ..........................................................
I.4.5. Middleware ..........................................................................................................
a. Définition .........................................................................................................
b. Les rôles du middleware .................................................................................
I.5. LES NORMES RFID ................................................................................................................
I.5.1. Les Normes RFID ISO ...........................................................................................
I.5.2. La norme EPCglobal .............................................................................................
a. Présentation de la norme EPCglobal ..............................................................
b. Le Code EPC (Electronic Product Code) ...........................................................
I.6. OPÉRATIONS AU NIVEAU DU LECTEUR ...............................................................................
I.7. MIDDLEWARE RFID .............................................................................................................
I.7.1. Introduction et définitions ...................................................................................
I.7.2. Les fonctions principales d'un middleware RFID ..................................................
a. Dissémination des données RFID ....................................................................
b. Filtrage et agrégation ......................................................................................
c. Lecture et écriture d’une étiquette .................................................................
d. Intégration .......................................................................................................
e. Confidentialité des données ............................................................................
I.7.3. INFRASTRUCTURE DES MIDDLEWARE RFID ..........................................................
I.7.4. Exemples de middlewares RFID ............................................................................
a. MIDDLEWARE WinRFID ......................................................................................
- Présentation ............................................................................................
- Architecture de WinRFID .........................................................................
5
5
6
6
6
6
7
7
8
8
8
9
9
10
10
10
10
11
11
11
11
12
12
12
12
12
13
15
15
16
16
16
16
16
16
16
18
18
18
18
- Les services web – lecteur .......................................................................
b. AspireRFID ..........................................................................................................
- Présentation ............................................................................................
- Architecture de AspireRFID .....................................................................
c. Fosstrak ..............................................................................................................
- Présentation ............................................................................................
- Les Modules de Fosstrak .........................................................................
1. Fosstrak EPCIS ........................................................................
2. L'intergiciel ALE de Fosstrak ...................................................
3. Fosstrak LLRP Commander .....................................................
I.7.5. Synthèse sur les middlewares RFID ......................................................................
a. Les middlewares Open-source ..........................................................................
1 – Aspire ..................................................................................................
2 – Fosstrak ...............................................................................................
b. Un middleware non Open-Source : WinRFID .....................................................
I.8.CONCLUSION ........................................................................................................................
20
Chapitre II : SÛRETÉ DE FONCTIONNEMENT DES SYSTÈMES RFID
28
..............
II.1. INTRODUCTION ..................................................................................................................
II.2. CONCEPTS DE BASE DE LA SÛRETÉ DE FONCTIONNEMENT ...............................................
II.2.1. Service .....................................................................................................................
II. 2.2. La sûreté de fonctionnement des systèmes informatiques ....................................
a. Les entraves ........................................................................................................
1. Les fautes ...............................................................................................
2. Les erreurs .............................................................................................
3. Les défaillances ......................................................................................
b. Les attributs ........................................................................................................
1. Disponibilité ...........................................................................................
2. Fiabilité ..................................................................................................
3. Sécurité-innocuité ..................................................................................
4. Sécurité-confidentialité .........................................................................
5. Maintenabilité .......................................................................................
6. Performabilité ........................................................................................
7. Testabilité ..............................................................................................
c. Les moyens de la SF .............................................................................................
1. Prévention des fautes ...........................................................................
2. Tolérance aux fautes ............................................................................
3. Élimination des fautes ..........................................................................
4. Prévision des fautes ..............................................................................
II.2.3. Tolérance aux fautes ..............................................................................................
II.2.4. La détection des erreurs ........................................................................................
II.2.5. Redondance ...........................................................................................................
a. Redondance Matérielle .....................................................................................
1. Redondance matérielle passive ...........................................................
2. Redondance matérielle active .............................................................
- Duplication et comparaison ..................................................
20
20
20
23
23
23
23
24
24
25
26
26
26
27
27
29
29
29
29
30
30
30
30
31
31
31
31
32
32
32
32
32
32
32
32
32
33
34
34
34
35
36
36
- Utilisation des modules « spares » ........................................
- L’approche « pair-and-a-spare » ...........................................
3. Redondance matérielle hybride ..........................................................
b. La redondance logicielle ....................................................................................
1. N-self-checking programming .............................................................
2. N-Version programming ......................................................................
3. Blocs de recouvrement ........................................................................
II.3. TOLÉRANCE AUX FAUTES DES SYSTÈMES RFID ...................................................................
II.3.1.Tolérance aux fautes aux différents niveaux ............................................................
a. Matériel ...............................................................................................................
b. Niveau intermédiaire ...........................................................................................
II.3.2. Travaux sur la tolérance aux fautes dans les systèmes RFID ...................................
2
a. RF ID : Une infrastructure d’intergiciel fiable pour le déploiement de la RFID ...
b. Travail de Agusti Solanas et al .............................................................................
c. Le travail de Julien David ......................................................................................
II.4. LA TOLÉRANCE AUX FAUTES DANS LES RÉSEAUX DE CAPTEURS ........................................
II.4.1. Introduction .............................................................................................................
II.4.2. Les travaux sur la tolérance aux fautes dans les réseaux de capteurs ....................
a. Travail de Koushanfar ..........................................................................................
1. Présentation .......................................................................................
2. Percentile et intervalle de confiance ..................................................
- Percentiles ................................................................................
- Intervalle de confiance ..............................................................
36
37
37
37
37
37
38
38
38
39
39
39
40
40
41
41
41
42
42
42
43
43
44
b. La détection et la tolérance aux fautes distribuée dans les réseaux de capteurs 45
Synthèse sur les deux travaux ................................................................................. 46
II.5. CONCLUSION ...................................................................................................................... 47
CHAPITRE III : CONTRIBUTION : "ANALYSE DES DONNÉES D’UN
SYSTÈME RFID EN VUE DE SA SÛRETÉ DE FONCTIONNEMENT" ...................
48
III. 1. INTRODUCTION .................................................................................................................
III.2. CONTRIBUTION ET ARCHITECTURE DE NOTRE SYSTÈME ...................................................
III.2.1. Schéma adopté ......................................................................................................
III.2.2. Notre méthodologie ..............................................................................................
III.2.3. Validité de la prise de décision ..............................................................................
III.3. EXEMPLE D’ILLUSTRATIF ....................................................................................................
III.4. CONCLUSION .....................................................................................................................
48
CHAPITRE IV : IMPLÉMENTATION
61
..............................................................................
IV.1. INTRODUCTION .................................................................................................................
IV.2. TECHNOLOGIES SOUS-JACENTES .......................................................................................
IV.2.1. SOA pour notre architecture multi-tiers ...............................................................
a. Définition de SOA .............................................................................................
b. Concepts et fonctionnement d’une SOA .........................................................
50
50
53
54
55
60
61
62
62
62
63
c. Quelle différence entre une architecture orientée objet et une SOA ? ...........
1. Modèle orienté objets (POO) ....................................................................
2. Modèle orienté services (SOA) ..................................................................
d. Les avantages de SOA ......................................................................................
IV.2.2. Jdeveloper ............................................................................................................
IV.2.3. L’infrastructure J2EE .............................................................................................
IV.3. NOTRE MINI-MIDDLEWARE SOARFID ...............................................................................
IV.3.1. Présentation du problème .....................................................................................
IV.3.2.Architecture globale ...............................................................................................
IV.3.3.Modules de SOARFID ..............................................................................................
a. Module de communication avec le Matériel (MCM) .......................................
b. Module de Filtrage et de Collection (MFC) .......................................................
c. Module de gestion de l’entrepôt (MGE) ...........................................................
IV.3.4. L’interface C : Interface Matériel ...........................................................................
a. Composant Open-Source : L’émulateur de Rifidi ...........................................................
- Le lecteur Alien 9800 ..........................................................................................
- Présentation ...........................................................................................
- Communication .......................................................................................
- Authentification .....................................................................................
- Travaux et études sur le lecteur Alien 9800 ............................................
b. Les classes de nos composants matériels simulés ..........................................................
a. Capteurs ............................................................................................................
b. Étiquettes ..........................................................................................................
c. Stations ..............................................................................................................
d. Lecteurs .............................................................................................................
IV.4. PROCÉDURE DE DÉTECTION DE LA FAUTE .........................................................................
a. Au niveau du lecteur .....................................................................................
b. b. Au niveau des capteurs ..............................................................................
IV.5. EXEMPLE DE SIMULATION .................................................................................................
IV.6. CONCLUSION .....................................................................................................................
64
Conclusion générale ........................................................................................................
Bibliographie ......................................................................................................................
Annexe ...................................................................................................................................
83
64
65
65
66
66
67
67
68
69
69
70
70
70
70
70
70
70
71
71
72
72
73
74
74
75
76
77
78
82
Table des figures
Chapitre I : INFRASTRUCTURE & MIDDLEWARE RFID
FIG.I.1 - Le code barre ........................................................................................................
FIG.I.2 - Évolution vers une infrastructure de RFID ...............................................................
FIG.I.3 - Étiquette RFID ......................................................................................................
FIG.I.4 - Interaction étiquette-lecteur ..................................................................................
6
7
8
9
FIG.I.5 - Architecture du système de capteur de température ..............................................
FIG.I.6 - Structure du code EPC ...........................................................................................
FIG.I.7 - WinRFID - architecture multi-couches .....................................................................
FIG.I.8 - Architecture de AspireRFID ....................................................................................
FIG.I.9 - L'entrepôt EPCIS ...................................................................................................
FIG.I.10 - L'intergiciel ALE ...................................................................................................
FIG.I.11 - Fosstrak LLRP Commander ...................................................................................
11
13
19
20
23
24
24
Chapitre II : INFRASTRUCTURE & MIDDLEWARE RFID
FIG.II.1 – Service ................................................................................................................
FIG.II.2 - De la faute à la défaillance ....................................................................................
FIG.II.3 - Concepts de base de la sûreté de fonctionnement des systèmes informatiques ........
FIG II.4 - TMR (triple modular redundancy) .........................................................................
FIG II.5 - Système de contrôle industriel .............................................................................
FIG II.6 - N-self-checking programming ................................................................................
FIG.II.7 - Les couches d’intégration de la tolérance aux fautes dans un système RFID ..............
FIG II.8 - Infrastructure RFID/Réseau de capteurs ................................................................
FIG II.9 - Détection distribuée de l'événement .....................................................................
29
31
33
35
35
37
38
41
46
CHAPITRE III : CONTRIBUTION
FIG III.1. Tag RFID Active- capteur température ITEMS_ET° ...................................................
FIG.III.2 - Redondance matérielle passive ............................................................................
FIG III.3. Validité de la décision concernant le lecteur suspect ...............................................
FIG III.4. Exemple ..............................................................................................................
51
53
55
56
CHAPITRE IV : IMPLÉMENTATION
FIG.IV.1 - Modèle orienté objets .........................................................................................
FIG.IV.2 - Modèle orienté services ......................................................................................
FIG.IV.3 – Jdeveloper ..........................................................................................................
FIG IV.4 - Architecture de notre mini-middleware SOARFID ..................................................
FIG.IV.5 - Appel Alien 9800 ...............................................................................................
FIG IV.6 - Résultats des requêtes sur Rifidi .........................................................................
FIG IV.7 -Modèle UML : Diagramme de classes ....................................................................
FIG IV.8 - Exemple de simulation ........................................................................................
64
65
66
69
71
72
75
79
Tableaux
Tableau II.1. Résultats de mesure ................................................................................................
Tableau III.1. Résultats de captage ..............................................................................................
Tableau III.2. Matrice d’humidité .................................................................................................
Tableau III.3. Nouvelle matrice de données ..................................................................................
44
58
59
60
INTRODUCTION
Les premières applications à grande échelle de la technologie RFID (Radio Frequency
Identification) ont vu le jour durant les années 90 pour l’identification des animaux, principalement les
bovins et ovins, dans les systèmes de contrôle d’accès dans les immeubles ou les autobus, la logistique, ou
encore pour la protection contre le vol [1]. Les études de marché annoncent une utilisation accrue de
cette technologie dans les années à venir et ce dans divers domaines de la vie courante.
Le principe de base du fonctionnement de la RFID est simple. Il s’agit d’échanger des informations
numériques à moyenne distance par radiofréquence ; ces informations devront être contenues sur un
support de très petite taille et de très faible coût [2]. Cette technologie offre la possibilité de faire de la
lecture multiple (lecture de plusieurs objets simultanément) et la vision directe n’est pas nécessaire.
Au minimum, l'infrastructure RFID comporte des étiquettes, des lecteurs, un middleware et des
applications fonctionnant par exemple, sur des serveurs d'entreprise.
1
INTRODUCTION
Un système RFID simple est composé de deux parties :
-
Un élément communément appelé transpondeur, étiquette communicante ou tag qui se compose
d’une antenne et d’une puce électronique contenant des informations.
-
Un appareil de lecture communément appelé interrogateur, base station ou lecteur qui permet
de lire et d’écrire les informations numériques dans la puce du transpondeur.
Les éléments d’un système RFID - antennes, tags, lecteurs - sont rarement utilisés seuls.
En fait, seule leur utilisation dans le cadre de systèmes de production ou de distribution
complexes est susceptible d’apporter une grande plus value. Ainsi, les différents systèmes RFID
utilisés dans les systèmes de production sont généralement constitués de réseaux locaux
(regroupement de plusieurs lecteurs) et globaux (regroupement de plusieurs réseaux locaux)
ainsi que d’applications utilisant les données collectées. Dans ce contexte, les middlewares (ou
intergiciels) permettent de transférer les données capturées d’un lecteur vers une base de
données [3]. Ces middlewares constituent le lien entre le monde matériel et le monde logiciel.
L'intergiciel RFID, est indispensable pour trois raisons principales :
1. La nécessité de filtrer les lectures doubles et l'information redondante afin d'éviter la
transmission de l'information non nécessaire pour les applications, et en même temps optimiser
les ressources du réseau.
2. La nécessité d'une interface pour prendre en compte des lecteurs, des étiquettes et des
dispositifs dans un environnement à plusieurs fournisseurs hétérogènes.
3. La nécessité de passer et d'acheminer des flux de données RFID à différentes applications et bases
de données.
Alors le middleware RFID joue un rôle crucial en assurant plusieurs tâches. Il constitue le cerveau de la
chaîne logicielle qui confère de l'intelligence aux données récupérées sur les produits étiquetés d'une
puce radiofréquence [3].
Parmi les propriétés attendues des services offerts par les systèmes RFID: la sûreté de fonctionnement.
La sûreté de fonctionnement est " la propriété qui permet de placer une confiance justifiée dans les
services que délivrent ces systèmes" [4]. Malheureusement, les opérations de lectures et de détection et
les mesures de capteurs sont inévitablement soumises aux erreurs. Une faute peut être définie comme
une valeur arbitraire d'une opération de détection ou d’inventaire par un lecteur ou d’une mesure
incohérente par un capteur, qui ne peut pas être compensée systématiquement. L’une des techniques de
sûreté de fonctionnent que traite ce travail est la tolérance aux fautes. La tolérance aux fautes peut
être définie comme la : "méthode qui permet à un système de remplir ses fonctions en dépit des
fautes pouvant affecter ses composants, sa conception ou ses interactions avec des hommes ou
d'autres systèmes" [5].
La plupart des travaux sur la tolérance aux fautes ont été conçus et évalués dans les réseaux des
capteurs. Nous nous intéressons dans ce travail à deux travaux faits. Le premier est le travail présenté
dans [6] qui présente une technique basée sur la validation pour la détection en ligne des fautes des
capteurs. Le deuxième travail est celui présenté dans [7] dans lequel les auteurs traitent la tolérance aux
fautes distribuée dans les réseaux de capteurs. Peu de travaux ont étudié la tolérance aux
2
INTRODUCTION
fautes dans les systèmes RFID, la plupart des solutions dans ces systèmes traitent le manque de fiabilité
inhérent dans les technologies de RFID. Les auteurs dans [8] ont étudié le comportement incertain des
dispositifs de RFID et ils ont conçu et ont mis en application un intergiciel RFID appelé RF2ID
(infrastructure fiable pour l'identification par radiofréquence) pour organiser et soutenir des requêtes sur
des flux de données d'une façon efficace.
L’approche que nous développons consiste à concevoir un système de décision RFID tolérant aux
fautes et distribué qui détecte et localise les défaillances en comparant les résultats des inventaires des
différents lecteurs, d’une part et d’autre part, en comparant les résultats des différents capteurs
homogènes en utilisant des techniques statistiques non paramétriques sur les résultats obtenus. Ce qui
permet à l’application de détecter l’élément défectueux, corriger les fautes et continuer son exécution en
présence de ces entraves.
I. OBJECTIF PRINCIPAL
L’objectif de notre travail [9], [10] est d’assurer la sûreté de fonctionnement d’un système RFID en
développant des modules d’analyse de données statistiques fonctionnant au niveau du middleware et
précisément dans le module de filtrage et de collection.
Pour réaliser la tolérance aux fautes de manière extensible et distribuée, nous proposons un schéma de
détection dans lequel nous utilisons la technique de redondance logicielle avec utilisation d’un
middleware qui analyse les données provenant des stations. Nous utilisons aussi la redondance
matérielle passive. Si les valeurs obtenues pour un lecteur ou pour un capteur n’appartiennent pas à un
intervalle de confiance calculé par la méthode percentile, ce lecteur ou ce capteur est considéré
défectueux. Le middleware peut inventorier les étiquettes, prendre une décision binaire concernant
l’événement étudié (événement ou non événement) et détecter en ligne les lecteurs et les capteurs
défectueux.
Le résultat global est alors le développement d’un intergiciel RFID plus complexe qui tolère les fautes
qui peuvent survenir aux différents niveaux d’un système RFID, et qui prend des décisions finales
fiables malgré la présence de fautes.
Puisque notre système peut recouvrir plusieurs sites géographiques pour prendre des décisions sur
plusieurs événements, notre middleware ainsi que notre application doivent être distribués. Nous
utiliserons pour cela l’architecture SOA (Service Oriented Architecture) [11].
II.
ORGANISATION DU MÉMOIRE
Le chapitre I décrit les concepts necessaires pour familiariser le lecteur aux contextes de la RFID et lui
permettre de suivre sans difficulté le reste du mémoire. Ce chapitre présente la terminologie utilisée dans
le mémoire. Ce chapitre commence par définir la technologie RFID qui fait partie des technologies
d’identification automatique, que l’on appelle aussi AIDC (Automatic Identification and Data Capture).
3
INTRODUCTION
Ensuite, il décrit les différents éléments de l’infrastructure RFID : les étiquettes, les capteurs, les lecteurs
et les middlewares RFID. Il réalise à la fin une synthèse sur les middlewares les plus connus.
Le chapitre II présente, en particulier, la notion de sûreté de fonctionnement et les méthodes statistiques
utilisées. La première section de ce chapitre présente brièvement les concepts de base de la sûreté
de fonctionnement. Elle donne quelques techniques de sûreté de fonctionnement et de tolérance aux
fautes. Sa deuxième section discute la tolérance aux fautes à deux niveaux d'abstraction (le matériel et
l'intergiciel). Les travaux sur la tolérance aux fautes au niveau des systèmes RFID, les travaux faits et
évalués sur la tolérance aux fautes dans les réseaux de capteurs et dont nous nous sommes inspiré sont
décrits dans ce chapitre.
Le chapitre III présente notre contribution : Tolérance aux fautes distribuée à base de redondance
matérielle,, les composants matériels principaux et la méthodologie proposée pour palier au problème
de la tolérance aux fautes dans les systèmes RFID. Ce chapitre alors propose un schéma de détection pour
réaliser la tolérance aux fautes de manière extensible et distribuée dans lequel la technique de
redondance logicielle est utilisée avec l’utilisation d’un middleware qui analyse les données provenant des
lecteurs et des capteurs RFID. Un exemple d’illustration et de validation est ensuite fourni.
Le chapitre IV présente une implémentation réalisée en deux parties :
- La première partie prépare l'ensemble des outils utiles à mettre en œuvre notre minimiddleware RFID à base de SOA. Ces technologies renferment, particulièrement, la SOA, J2EE, et
JDeveloper.
- La seconde partie concerne la proposition de notre mini-middleware basé sur la SOA (Service
Oriented Architecture).
Une Conclusion clôture ce travail et souligne les principales perspectives et l’aspect recherche liée à la
sûreté de fonctionnement dans les systèmes RFID.
4
Chapitre
1
INFRASTRUCTURE & MIDDLEWARE RFID
I.1. INTRODUCTION
La technologie RFID (Radio Frequency IDentification) — ou identification par fréquence radio — fait partie
des technologies d’identification automatique, au même titre que la reconnaissance optique de
caractères ou de codes barre. Le but de ces technologies est de permettre l’identification d’objets ou
d’individus par des machines [1]. La technnologie RFID a la particularité de fonctionner à distance, sur le
principe suivant : un lecteur émet un signal radio et reçoit en retour les réponses des étiquettes — ou tags
— qui se trouvent dans son champ d’action. Il existe une variété presque infinie de systèmes RFID;
différents types de mémoire, différentes fréquences, différentes portées, différents types d’alimentation,
etc. La technologie RFID est utilisée depuis longtemps et à large échelle, notamment dans les secteurs de
la logistique, la protection contre le vol ou encore l’identification des animaux.
Ce chapitre décrit les concepts necessaires de la technologie RFID. Ensuite, il décrit les différents éléments
de l’infrastructure RFID : les étiquettes, les capteurs, les lecteurs et les middlewares RFID. Il réalise à la fin
une synthèse sur les middlewares les plus connus.
5
Chapitre I
I.2. LES SYSTEMES D'IDENTIFICATION AUTOMATIQUE [1]
Les systèmes RFID font partie des technologies d’identification automatique, que l’on appelle aussi AIDC
(Automatic Identification and Data Capture). Nous présentons quelques-unes de ces technologies
importantes à connaître pour comprendre le fonctionnement des systèmes RFID.
I.2.1 Le code barre
Omniprésents dans notre vie quotidienne, les codes barre dominent les systèmes d’identification
automatique depuis plus de 20 ans. Le code barre est un code binaire représenté par une séquence de
barres vides et de barres pleines, larges ou étroites, disposées parallèlement (voir la FIG.I.1). La séquence
peut être interprétée numériquement ou alphanumériquement. Elle est lue par balayage optique au
laser, c’est-à-dire d’après la différence de réflexion du rayon laser par les barres noires et les espaces
blancs.
FIG.I.1 – Le code barre
Malgré son grand âge, le code barre conserve des avantages importants comme son coût quasiment nul
et sa large diffusion. En revanche, il présente plusieurs inconvénients : il est fragile et doit être lu de
manière optique. De plus, il ne peut pas être modifé à distance, contient peu d’informations et n’a bien
sûr aucune capacité de traitement de données.
I.2.2 La reconnaissance optique de caractères
La reconnaissance optique de caractères (Optical Character Recognition, OCR) est utilisée depuis les
années 1960. Elle fonctionne avec des polices de caractères conçues pour être lisibles aussi bien par les
hommes que par les machines. Elle est utilisée aujourd’hui dans le domaine administratif et les services
bancaires, notamment pour l’encaissement de moyens de paiement, tels que les chèques ou les bulletins
de versement. Si les systèmes OCR ne sont pas plus répandus, c’est notamment dû à la complexité des
lecteurs et à leur prix élevé.
I.2.3 Les Smart cards
Une smart card (« carte intelligente » ou « carte à puce »), est un système électronique de stockage de
données, éventuellement avec une capacité de traitement (carte microprocesseur) qui, par commodité,
est incorporé dans une carte en plastique de la taille d’une carte de crédit. Les premières smart cards sont
apparues en 1984, sous la forme de cartes téléphoniques prépayées. Pour fonctionner, les smart cards
doivent être placées dans un lecteur, qui entre en contact avec la surface de contact de la smart card. Le
lecteur fournit à la smart card l’énergie et la pulsation d’horloge. Les transferts de données entre le
lecteur et la carte se font par une interface série bidirectionnelle (port E/S). Un des principaux avantages
des smart cards est que les données qui y sont stockées peuvent être protégées contre les accès (lecture
et/ou écriture) non désirés. Les smart cards simplifient et sécurisent de nombreux services, à commencer
par les transactions financières. Les smart cards comptent plusieurs inconvénients, basés sur la nécessité
6
Chapitre I
du contact et des manipulations : elles sont vulnérables à la corrosion et la poussière. Les lecteurs qui
sont utilisés fréquemment (cabines téléphoniques, automates à billets. . .) tombent en panne et sont
chers à entretenir. De plus, les lecteurs accessibles au public ne peuvent pas être protégés contre les mal
intentionnés.
I.2.4 Les systèmes RFID
Les systèmes RFID sont très proches des smart cards. Comme sur les smart cards, les données sont
stockées sur une puce électronique (tag). Cette puce peut être de type « machine à états » ou contenir un
microprocesseur. Elle peut avoir différents types de mémoire. Par contre, à la différence des smart cards,
il n’y a pas de contact physique entre la puce et le lecteur ; l’alimentation électrique de la puce se fait par
induction électromagnétique. Les données sont aussi transmises selon ce principe, ainsi que par réflexion
des ondes radio. C’est bien de là que vient le nom de cette technologie : Radio Frequency IDentification.
I.3. VERS UNE INFRASTRUCTURE DE SYSTÈME RFID
Les premières générations des systèmes RFID ont été déployées sur un seul site avec généralement peu
de lecteurs communicant à travers des liens dédiés vers un seul ou plusieurs serveurs d'application. Une
telle architecture (Fig.I.2) marche bien pour un essai ou pour la validation d'un principe, mais devient plus
difficile à exploiter pour des implémentations d'enterprise avec plus de lecteurs, plus de sites et plus
d'applications [2].
FIG.I.2. Évolution vers une infrastructure de RFID
Cette technologie permet d’identifier un objet, d’en suivre le cheminement et d’en connaître les
caractéristiques à distance grâce à une étiquette émettant des ondes radio, attachée ou incorporée à
l’objet. La technologie RFID permet la lecture des étiquettes même sans ligne de vue directe et peut
traverser de fines couches de matériaux (peinture, neige, etc.). Il y a des difficultés principales auxquelles
la technologie RFID doit faire face. Ces difficultés sont en voie d’être surmontées : coût de l’étiquette,
gestion des collisions en cas de lecture de nombreuses étiquettes en simultané, lecture au travers des
fluides, adoption ou convergence trop lente de certains standards, remise en cause de processus anciens,
problèmes de sécurité et d'éthique, etc.
7
Chapitre I
I.4. ÉLÉMENTS DE L'INFRASTRUCTURE [2]
L'infrastructure de système RFID comprend les éléments qui contrôlent les dispositifs et les données
d'étiquette. Les consommateurs des données sont les éléments du réseau du client (typiquement les
applications utilisateurs). Les éléments du réseau entre l'étiquette et les clients forment le conduit qui
transporte des données d'étiquette aux applications, et donnent des commandes opérationnelles
d'étiquette aux dispositifs de RFID. Au minimum, l'infrastructure RFID (FIG.I.2) comporte des étiquettes,
des lecteurs, des RNCs (contrôleurs de réseau de lecteurs) et des applications fonctionnant par exemple,
sur des serveurs d'entreprise.
En outre, d'autres dispositifs pourraient également être dans le réseau tel que des lecteurs de codes
barre, des unités d'E/S et des applicateurs intelligentes utilisant les étiquettes.
Typiquement, un lecteur transmet un signal RF (radiofréquence) dans la direction d'une étiquette, qui
répond au signal avec un autre signal RF contenant l'information identifiant l'article auquel l'étiquette est
attachée, et probablement d'autres données. L'étiquette peut également inclure des données
additionnelles des capteurs de puissance intégrés ou un détecteur environnemental pour fournir des
données comme la température ou l'humidité de l'environnement.
Le lecteur reçoit l'information et fournit les données d'étiquette au RNC qui peut faire une transformation
ultérieure avant d'envoyer les données aux applications.
I.4.1. L’étiquette radiofréquence
L’étiquette radiofréquence est composée d’une puce (en anglais « chip ») reliée à une antenne, toutes
deux encapsulées dans un support ( RFID Tag ou RFID Label ) ( FIG.I.3).
FIG.I.3 - Étiquette RFID
Il existe trois grandes familles d'étiquettes RFID : les étiquettes passives, les étiquettes semi-passives et
les étiquettes actives.
a. Les étiquettes passives. À son plus simple, une étiquette inclut une petite antenne reliée à une puce.
Cette étiquette est passive dans le sens qu'elle n'a aucune source d'énergie intégrée, telle qu'une
batterie. Au lieu de cela, l'étiquette moissonne l'énergie électromagnétique émise par le lecteur,
convertissant cette énergie en alimentation DC (courant continu) pour actionner la puce. L'étiquette
transmet alors l'information au lecteur par rétrodiffusion d’une partie de l'énergie -propagée à courte
distance -qu’elle reçoit. Ces étiquettes à moindre coût sont généralement plus petites et possèdent une
durée de vie quasi-illimitée. Ces étiquettes passives sont programmées avec des données non
modifiables, pour une capacité de 32 à 128 bits. Elles sont fournies vierges à l’utilisateur. La FIG.I.4
montre l'interaction entre un lecteur et une étiquette passive.
8
Chapitre I
b. Les étiquettes semi-passives. Une étiquette semi-passive a une batterie pour actionner la puce, et
emploie également la rétrodiffusion pour communiquer avec le lecteur. Son rayon n'est plus limité par la
nécessité d'actionner l'étiquette à partir du champ RF, mais par la sensibilité du récepteur du lecteur [Pat
08]. De telles étiquettes ont un rayon considérablement plus long que les étiquettes passives. Ces
étiquettes n’utilisent pas leur batterie pour émettre des signaux. Elles agissent comme des étiquettes
passives au niveau communication. Mais leur batterie leur permet, par exemple, d’enregistrer des
données lors du transport. Ces étiquettes peuvent disposer de capteurs leur permettant d’identifier des
variations physiques comme la température (produits surgelés par exemple) [12].
c. Les étiquettes actives. Le troisième type d'étiquette est de type actif, actionné par une batterie interne
plus efficace. Ainsi, il peut réellement transmettre un signal RF en réponse au lecteur, plutôt que
rétrodiffuser le signal du lecteur. Ceci permet une plus large gamme de fonctions, telles que des
communications d'étiquette à étiquette. La batterie interne peut également actionner les capteurs
environnementaux intégrés et maintenir des données et l'information d'état dynamiquement dans une
mémoire incluse dans l'étiquette allant jusqu’à 10 Kbits [2]. Ces étiquettes actives ne dépassent pas 10
ans d’âge [12].
La Figure I. 4 illustre également le chemin perdu sur le chemin lecteur-étiquette et le chemin inverse
étiquette-lecteur pour une étiquette passive. Le rayon maximum sur lequel le lecteur peut communiquer
avec l'étiquette dépend de la puissance de transmission du lecteur, de l'environnement que le signal RF
traverse, de la présence d’interférences, du seuil d'activation minimum de l'étiquette et de la sensibilité
de réception du lecteur. Les pertes en raison de l'atténuation du signal et de l'interférence par chemins
multiples réduisent le rayon. L'atténuation est basse ou négligeable pour des gaz dans l'atmosphère,
comme l'azote et l'oxygène, et également pour le papier, le carton et certains plastiques. Les matériaux
comme le métal et les liquides ont un effet atténuant plus fort selon leur épaisseur.
FIG.I.4 Interaction étiquette-lecteur
Le protocole sans fil standard définit le protocole de signalisation de couche du lien de communication,
les procédures de fonctionnment du lecteur et de l’étiquette, les commandes et le plan d'arbitrage de
collision pour l'identification d’une étiquette simple dans un environnement multi-étiquettes. Ce dernier
processus est connu comme étant la singularisation.
9
Chapitre I
I.4.2. Capteur
Un appareil électronique qui produit un signal électronique en réponse à une stimulation physique. Les
capteurs sont plus fréquemment intégrés dans des étiquettes RFID. Comme exemple, nous avons le
contrôle de température d'un article. Le capteur peut être intégré à n’importe quelle classe d’étiquettes
(passives, semi-passives et actives). On distingue :
a. L’étiquettes-capteur RFID
L’étiquettes-capteur RFID (Sensor enabled RFID tag ou “sensor tag”) est une étiquette RFID qui contient
un capteur pour surveiller un certain paramètre physique (par exemple, la température) mais contient
également la même la fonction d'identification qu'une étiquette « normale » de RFID. Ce genre
d'étiquette-capteur peut être de classe 2, classe 3 ou classe 4 dans la classification de l'étiquette
d'EPCglobal [13].
Comme entièrement passive, une étiquette de la classe 2 peut mesurer des paramètres physiques
seulement une fois mise sous tension par l’interrogateur. Puisque la classe 3 des étiquettes ont une
batterie, les capteurs peuvent travailler indépendamment. Par conséquent, ils peuvent contenir des
dispositifs de notation pour maintenir des résultats de mesure en fonction du temps ou ils peuvent
enregistrer des événements prédéfinis. L'avantage de la classe 4 est la fiabilité accrue de lecture.
b. Capteurs RFID
Les capteurs sont des « dispositifs qui transforment des quantités physiques telles que la pression ou
l'accélération en signaux de sortie (habituellement électriques) pour servir d'entrées pour contrôler le
système» [14].
Le développement rapide de la technologie de RFID présente une occasion neuve pour évoluer
l'application de capteurs. Les étiquettes RFID qui portent des capteurs qui peuvent être employées dans
des domaines tels que le cheminement de projet, le contrôle de l'environnement, système électronique
des véhicules à moteur, télémédecine et le contrôle de processus, etc., sont multipliés comme résultat.
Les capteurs primaires en service aujourd'hui peuvent être classifiées selon leurs fonctions comme :
- Capteurs de température
- de pression
- d’accélération
- d’inclination
- d’humidité
- de lumière
- Capteurs de gaz
- Capteurs chimiques
I.4.3. Les lecteurs
Ce sont des dispositifs actifs, émetteurs de radiofréquences qui vont activer les tags qui passent devant
eux en leur fournissant à courte distance l’énergie dont ceux-ci ont besoin. La fréquence utilisée est
variable, selon le type d’application visé et les performances recherchées. Une fréquence plus élevée
présente l’avantage de permettre un échange d’informations (entre lecteur et marqueur) à des débits
plus importants qu’en basse fréquence. Les débits importants permettent l’implémentation de nouvelles
fonctionnalités au sein des étiquettes (cryptographie, mémoire plus importante, anti-collision).
10
Chapitre I
Un lecteur RFID a typiquement un embout avant RF qui sert une ou plusieurs antennes, un processeur de
signal RF, une machine de traitement du protocole air-protocol, la machine d'état, les algorithmes, et le
processeur d'interface de réseau pour communiquer avec les éléments ascendants du réseau. Quelques
lecteurs ont un support pour les ports numériques d'E/S. Ces ports sont employés pour se relier en série
aux détecteurs (capteurs), déclencheurs ou contrôleurs.
Les conceptions de lecteurs couvrent un spectre étendu basé sur différents facteurs:
1. Nombre d’antennes: antennes multiples (typiquement 4 à 8) ou une simple antenne intégrée.
2. Complexité de traitement: le traitement inclut des processus intelligents, ou juste une intelligence
RF.
3. Fonctions d'accès à l’étiquette: certaines exécutent toutes les opérations du air-protocol (read,
write, lock et kill étiquette), d'autres juste inventorient les étiquettes.
4. Connectivité: Ethernet, série, ou wireless (non filaires).
I.4.4. Le Contrôleur du Réseau de Lecteurs (Reader Network Controller ou RNC)
Le contrôleur RNC joue le rôle de la couche d'infrastructure RFID. Il réside logiquement au-dessus de la
couche lecteur comme une extension du réseau d'entreprise. Il met une collection de lecteurs et de
dispositifs autonomes dans un réseau relié et fiable. La fonctionnalité du RNC inclut un contrôle adaptatif
en temps réel et une gestion des lecteurs et dispositifs, la localisation de l’emplacement de l’étiquette et
le traitement des données des différents capteurs, ainsi que les services standards de données pour les
applications utilisant les données RFID. Cette fonctionnalité peut être implémentée dans un seul matériel
autonome, comme un logiciel autonome fonctionnant dans un serveur d'entreprise, comme logiciel
intégré avec l’intergiciel personnalisé d'entreprise ou directement avec les applications RFID. Le choix
pour le déploiement dépend principalement de la complexité des opérations de gestion et de contrôle
des dispositifs, la charge de données, les conditions de traitement et les conditions des services
d'application [2].
I.4.5. Middleware
a. Définition [3]
Le middleware RFID, un élément de l’infrastructure RFID est un logiciel qui :
- met en œuvre la majorité des standards EPC Global (définis dans la sous section I.5.2).
- transmet les données vers d’autres systèmes.
- s’occupe des échanges avec le matériel
b. Les rôles du middleware
Les fonctions principales du middleware sont:
- Gestion des Lecteurs RFID.
- Gestion des données (agrégation, filtrage).
- Appel à des fonctions d'application (ERP) ou envoi des résultats.
- Gestion des règles et des exceptions.
- Log des événements.
- Collection et traitement des données en temps réel ou en asynchrone.
Ces fonctions seront développées par la suite dans la section I.7.2.
11
Chapitre I
I.5. Les NORMES RFID
Les normes contribuent à créer un cadre harmonisé, à améliorer la transparence, l'efficacité et la sécurité
dans un marché complexe en pleine croissance, tout en optimisant les processus des entreprises et en
réduisant leurs coûts de fonctionnement.
I.5.1. Les Normes RFID ISO [15]
Les normes RFID de l'ISO apportent également des avantages significatifs dans le suivi des produits à
mesure qu'ils se déplacent dans la chaîne d'approvisionnement, y compris pour la prévention des pertes,
la maîtrise des inventaires et la visibilité durant l’acheminement. En réponse aux dernières tendances du
marché, l'ISO travaille actuellement sur des normes qui porteront l'identification RFID à un nouveau stade
d’évolution.
Nous citons ici deux normes RFID ISO.
a. Interface radiofréquence
code : ISO 18000 – x
Elle consiste à définir :
a) la fréquence de fonctionnement
b) le mode de communication entre les étiquettes RFID et les interrogateurs.
Cette norme garantit l’interopérabilité des matériels.
b. Identification unique d’étiquette
code : ISO 15 963
L’identifiant unique est composé de 3 éléments :
•le RC (registration category)
•le numéro d’identité du fabricant
•un numéro de série
Cette norme garantit la compatibilité des identifiants attribués par les différents fabricants de puce.
I.5.2. La norme EPCglobal
a. Présentation de la norme EPCglobal
Le Projet EPCglobal a été créé en juillet 2003 suite à l’accord entre AutoID center (leader des laboratoires
de recherche sur les systèmes RFID) et GS1 (Organisme qui définit et diffuse les standards GS1 (RFID)). Sa
mission première est de Développer un standard définissant un système d’identifiant unique par objet
EPC (Electronic Product Code) [3].
b. Le Code EPC (Electronic Product Code)
Le Code EPC est un système de codification permettant d'identifier tout objet de façon unique. Chaque
objet est identifié par un code unique EPC Electronic Product Code. Chaque objet peut donc être suivi
individuellement [3]. L’accès à d’autres informations est possible via internet comme le lieu de stockage,
les conditions de stockage, la date d’arrivée dans l’entrepôt etc...
12
Chapitre I
- Structure de base du code EPCglobal
Un code EPC se compose de :
- Header : définit la longueur, la structure et la version de l'EPC.
- EPC Manager : identifie l'entreprise qui a la responsabilité d'attribuer les données Object Class et
numéro de série.
- Object Class : identifie la classe ou le type d'objet (voir le numéro d'article).
- Numéro de série : identifie l'objet de manière unique.
FIG.I.6 - Structure du code EPC
- Le réseau EPCglobal [3]
Chaque intervenant du réseau possède une puce RFID (produit, entrepôts etc.). Cette puce permet de
tracer le chemin de vie d’un produit. Les données sont disponibles par le biais :
- de systèmes d'informations en ligne.
- de bases de données accessibles via Internet.
I.6. OPÉRATIONS AU NIVEAU DU LECTEUR [2]
L’infrastructure comporte trois chemins de communications: le traitement (chemin des données), la
gestion de dispositifs (chemin de gestion), le contrôle des dispositifs et la coordination (le chemin de
contrôle). Le chemin des données se réfère aux informations des étiquettes et des capteurs rassemblées
par les lecteurs et transmises au RNC (Reader Network Controller) et applications. Avec l'arrivée des
protocoles standards sans fil sophistiqués comme la deuxième génération UHF Gen2, et le déploiement
d’un grand nombre de lecteurs, le contrôle et la coordination des lecteurs dans l'architecture devient
important. De même, avec les types divers de dispositifs déployés dans une entreprise, la gestion des
dispositifs et le contrôle (le chemin de gestion) deviennent très importants aussi. En général, une
infrastructure RFID doit assurer les points suivants :
1. • Opérations du lecteur
2. • Traitement des données de l’étiquette
3. • Gestion et surveillance des dispositifs
13
Chapitre I
Dans ce qui suit nous nous intéressons aux opérations du lecteur.
Un lecteur effectue typiquement des opérations d'inventaire ou d'accès sur une population d'étiquettes.
L'inventaire, comme le nom le suggère, est une identification d’une population d’étiquettes utilisant une
séquence d'ordres du protocole standard sans fil. En utilisant un algorithme de "singularisation", le
lecteur isole une réponse simple d'étiquette et lit le contenu de la mémoire de l'étiquette. L'accès est
employé pour décrire l'opération supplémentaire de la communication avec (lecture de et/ou écriture
vers) d'autres régions mémoire sur une étiquette. Semblable à l'opération d'inventaire, l'accès comporte
des ordres multiples du protocole standard sans fil.
L'opération de lecture traite le contrôle et la coordination des lecteurs pour maximiser au niveau système
l'exécution de l’application RFID. Bien que la communication entre un lecteur et une étiquette soit locale,
l'impact d'interférence dû à cette communication locale est global. Cela signifie que les paramètres
d'exploitation d'un lecteur seul qui maximisent la performance de la communication locale entre le
lecteur et son ensemble d'étiquettes ne peuvent pas conduire à une performance maximale. Au niveau
système, le taux d'accès et la latence lors de l'inventaire des étiquettes sont les principaux paramètres
d'optimisation du traitement pour une infrastructure RFID.
Avec les lecteurs multiples, les performances système peuvent être affectées par interférence de lecteurà-étiquette et de lecteur-à-lecteur.
L’interférence Lecteur-à-étiquette se produit quand les lecteurs multiples activent simultanément les
mêmes étiquettes, les confondent et les empêchent d'être lues.
L'interférence lecteur-à-lecteur se produit quand un lecteur reprend un signal de transmission d'un autre
lecteur, sur ou près de la même fréquence.
La stratégie de contrôle du fonctionnment d’un lecteur implique trois sous composants :

Physique : les parametères du lien lecteur-à-étiquette dans les deux sens.

Inventaire d'étiquettes: la stratégie de « singularisation » utilisée.

Accès aux données : l'ordre d'opération du protocole standard sans fil.
Une stratégie réussie implique une adaptation dynamique de ces trois composants de contrôle en
réponse aux événements en temps réel (tels que des mouvements d'étiquette aux lecteurs, par exemple);
RF externe, l'auto-interférence et les contraintes de normalisation.
14
Chapitre I
I.7. MIDDLEWARE RFID
I.7.1. Introduction et définitions
Les technologies informatiques ont évolué rapidement, mais sophistiquées, les systèmes spécialisés matériels, logiciels système ou logiciel d'application - demeurent distincts, hétérogènes, et concourent à
la résolution de problèmes critiques. L'intergiciel est le paradigme de logiciel utilisé par l’industrie pour
intégrer ces technologies dans l'infrastructure de traitement établie avec un minimum de perturbations.
Un intergiciel est un logiciel qui sert d'intermédiaire transparent entre des logiciels d'application
appartenant à des systèmes hétérogènes liés en réseau, lesquels entretiennent le plus souvent des
relations basées sur le modèle client-serveur. Le réseau est mis en œuvre par l'utilisation d'une même
technique d'échange d'informations dans toutes les applications impliquées à l'aide de composants
logiciels [16].
Les composants logiciels du middleware assurent la communication entre les applications. Les techniques
les plus courantes d'échange d'informations sont l'échange de messages, l'appel de procédures à distance
et la manipulation d'objets à distance.
Nous expliquons ici le concept de l'intergiciel RFID et montrons le rôle crucial qu'il joue.
Un système RFID se compose de matériel, à l’exemple des lecteurs RFID, et de logiciel. Le logiciel
fonctionne sur des PCs ou des serveurs ordinaires et se compose de l'intergiciel, qui contient la logique de
l'application RFID, et d'un système de base de données principal (par exemple, Oracle, serveur SQL,
Postgres, MySQL) pour stocker des informations sur les étiquettes. Typiquement, les étiquettes
contiennent un numéro d'identification et probablement de l'information spécifique à l’article désigné.
Dans l'Internet des objets (*), le middleware RFID constitue le cerveau de la chaîne logicielle qui confère
de l'intelligence aux données récupérées sur les produits étiquetés d'une puce radiofréquence. Il gère les
différents lecteurs et il détermine l’interaction qu’ils devront avoir avec les étiquettes RFID. C’est
également l’élément qui permet d’effectuer un pré traitement des informations capturées (filtrage,
routage, élimination des doublons, etc...) afin de faciliter leur insertion dans les bases de données du
système d’information. Ce sont les tâches premières du middleware RFID. Aujourd’hui, les offres
middleware dédiées aux RFID se positionnent comme des solutions à moyen/long terme permettant aux
entreprises de mieux profiter des apports de la RFID.
(*) Internet des Objets
L'Internet des Objets est une extension de l'Internet actuel à tous les objets pouvant communiquer de
manière directe ou indirecte avec des équipements électroniques eux-mêmes connectés à l'Internet.
L'utilisation des codes à barres ou des étiquettes RFID (Radio Frequency IDentification ou radioidentification) permet une telle extension.
15
Chapitre I
Selon WinterGreen Research, le marché du middleware RFID est amené à croître considérablement dans
les années à venir. Les prévisions l’estiment à près de $770 millions en 2010, et à plus de $1.550 millions
un an plus tard, en 2011 [17].
I.7.2. Les fonctions principales d'un middleware RFID [18]
Parmi les fonctions du middleware, nous avons :
a. Dissémination des données RFID : L’information capturée par un lecteur n’intéresse généralement pas
qu’une seule application, mais un ensemble de processus métier dans l'entreprise et aussi chez ses
partenaires. De ce fait, les données capturées doivent être diffusées aux entités indiquant leur intérêt
pour de telles données.
b. Filtrage et agrégation : Hors de question pour la plupart des applications de recevoir autre chose que
des données prétraitées. Par ailleurs, certaines peuvent n’être intéressées que par un sous ensemble de
ces données provenant des étiquettes et des lecteurs. Puisque la RFID permet l’identification au niveau de
l’instance plutôt qu’à celui de la classe de l’objet concerné, il est ainsi possible de mettre en place une
granularité extrêmement fine.
c. Lecture et écriture d’une étiquette : Certains tags ont suffisamment d’espace mémoire pour y mettre
autre chose qu’un simple identifiant. De ce fait, le middleware doit pouvoir fournir des fonctionnalités
d’écriture lecture de cette mémoire additionnelle. Celle-ci pourra être utilisée pour stocker des données
en provenance des applications concernées comme par exemple la date d’expiration du produit, ceci afin
de faciliter les échanges de données lorsqu’un accès réseau n’est pas disponible.
d. Intégration du lecteur dans le système d’administration de l’environnement IT : C’est une des
fonctions que l’on est en train de voir apparaître sur certains middlewares, une fonction à notre sens
incontournable puisqu’elle permet de gérer les incidents, les modifications de configuration, les
migrations de parc, etc .
e. Confidentialité des données : Partant d'un identifiant unique assurant le rôle de pointeur vers des
sources de données réparties sur le réseau et gérées par des entreprises, l'une des questions importantes
à se poser est de savoir ce qui autorise une application quelconque à accéder à une donnée particulière.
D'où la nécessité pour le middleware d'assurer également une gestion des politiques de vérification
d'identité des dispositifs connectés sur le réseau (lecteur RFID, application fournisseur accédant à une
base de données entreprise, terminal de lecture distributeur, etc.).
I.7.3. INFRASTRUCTURE DES MIDDLEWARE RFID [17]
Par infrastructure de middleware RFID, on désigne les composants logiciels de base qui réalisent
l’intégration entre des dispositifs RFID (lecteurs de tags de toutes natures) et les applications
informatiques qui s’exécutent sur les serveurs d’entreprise. Cette intégration comprend trois volets:

Connectivité qui met en oeuvre deux types de réseaux : Internet pour le coeur des
communications à grande échelle et divers types de réseaux hétérogènes (réseaux de
terrain, réseaux sans fil) pour la partie capillaire qui permet l’accès aux lecteurs des
étiquettes. La connectivité universelle consiste à utiliser les protocoles de
communication fondés sur IP de bout en bout (ou du moins au plus près possible des
lecteurs).
16
Chapitre I

Intégration de données qui permet de collecter les données brutes, de les transformer
en ligne et de les router vers le (ou les) sites d’exploitation ou d’archivage. Cette forme
d’intégration est définie par un ensemble de flots de données qui traversent la chaîne de
liaison depuis les lecteurs jusqu’aux serveurs d’application.

Intégration d’applications dont l’objectif est de réaliser l’interopérabilité entre diverses
applications opérant sur des données partagées (au sein d’une entreprise ou entre des
entreprises).
D’un point de vue physique une infrastructure RFID s’apparente à un système M2M (Machine to
Machine) qui est organisé selon une architecture multi-niveaux :

Les lecteurs RFID lorsqu’ils sont accessibles directement ou les contrôleurs de proximité
qui gèrent l’accès aux lecteurs.

La passerelle Internet qui assure l’interface entre le monde des équipements (lecteurs ou
contrôleurs) et le monde de l’Internet.

Les serveurs de proximité qui hébergent là où c’est nécessaire l’intelligence de
traitement et de routage des données RFID,

Les plates-formes de services qui hébergent les fonctions d’intégration avec le système
d’information de l’entreprise et avec les systèmes des partenaires via un système
d’information RFID partagé.
Une plate-forme de services peut également héberger des services techniques pour l’administration et le
contrôle de l’infrastructure distribuée. Les composants de l’architecture fonctionnelle sont hébergés sur
les divers éléments de l’architecture technique. Le principe directeur qui est retenu est celui de
l’intelligence distribuée dans lequel les fonctions de traitement de l’information sont distribuées sur
l’ensemble de la chaîne qui conduit des lecteurs jusqu’au système d’information. Les critères de
localisation d’une fonction sont multiples et concernent par exemple la proximité données/traitements, la
disponibilité de ressources matérielles adéquates, la sécurité, la fiabilité, etc. On distingue les éléments
suivants dans l’architecture fonctionnelle :
• Interface lecteur RFID. Cette interface définit une API uniforme d’accès à des lecteurs hétérogènes.
Cette interface est disponible sur la passerelle ou le contrôleur de proximité.
• Médiation RFID. La médiation RFID regroupe les fonctions de collecte, filtrage, transformation, routage
et transport fiable de données RFID. La médiation est distribuée sur les passerelles et les serveurs de
proximité et inter-opère avec la plate-forme de services. La médiation s’appuie sur un système de
communication asynchrone fiable (de type MOM) pour le transport des données. La médiation intègre les
fonctions de :
- Services d’intégration. Ces services assurent la liaison avec les applications métiers s’exécutant
dans le cadre du système d’information d’entreprise.
- Services d’exploitation. Une infrastructure RFID est un système distribué complexe qui met en jeu
un grand nombre de composants matériels et logiciels dans un contexte en constante évolution.
Un déploiement opérationnel d’un tel système requiert des fonctions d’administration élaborées
pour répondre aux besoins en termes de disponibilité, de souplesse d’exploitation, de sécurité et
de passage à l’échelle.
17
Chapitre I
• Système d’information RFID partagé. Ce système permet l’échange et le partage d’informations métiers
associées aux données RFID. Dans ce domaine un objectif pourrait être le développement d’une solution
alternative au controversé système ONS. Une infrastructure middleware est mise en œuvre par un
ensemble de composants logiciels qui s’exécutent en divers points de l’environnement distribué.
L’exploitation opérationnelle de telles infrastructures requiert des services d’administration dont on peut
considérer qu’ils sont partie intégrante de la solution middleware. Dans le cas des environnements RFID,
le facteur d’échelle est un critère de complexité complémentaire engendré par le grand nombre
d’équipements hétérogènes et les localisations multiples.
I.7.4. Exemples de middlewares RFID
Nous présentons dans cette sosus-section les middlewares : WinRFID, AspireRFID et Fosstrak.
a. Middleware WinRFID [19]
- Présentation
L’intergiciel WinRFID a été développé sur Microsoft .NET framework (WINMEC à l'UCLA). Il fournit un
environnement distribué pour traiter les données des étiquettes lues par les lecteurs, traduit les données
en cas de besoin, et les conduit à une série d'applications principales utilisant des technologies
appropriées telles que le Web et les services de Windows. L'intergiciel a un ensemble d'applications
programmées et interfaces d'intégration pour supporter le développement d'applications. En même
temps, WinRFID a des possibilités embrochables à adapter des technologies symbiotiques telles que les
services et les capteurs de position, qui augmenteraient non seulement l'efficacité technologique du
système RFID, mais ajouteraient également de la valeur aux processus métiers. Pour traiter des données à
fort débit, l'intergiciel de WinRFID est soutenu par des algorithmes originaux et des schémas de
représentation de données capables de traiter de grands nombres de données, rectifiant des erreurs en
temps réel, identifiant des modèles, des données d'événements, de réorganisation et récupérant des
défauts et des exceptions. L'interopérabilité comporte le fonctionnement distribué simultané de
récepteurs/lecteurs et transpondeurs/étiquettes à différentes fréquences utilisant différents protocoles,
avec des possibilités de lecture/écriture, de différents taux lus, et d'autres caractéristiques, comme
couche transparente aux applications. La gestion du réseau comporte le déploiement, l'initialisation et la
commande des récepteurs et des transpondeurs, qui peuvent être organisés en structure hiérarchisée
avec la syntaxe et la sémantique opérationnelles attachées à chacun ou groupe de récepteurs,
transpondeurs et concentrateurs ou même les ordinateurs de bord. Les défis que WinRFID essaye
d'atténuer sont l'intégration de la technologie, la gestion du matériel, le contrôle des échanges de
données à fort débit en temps réel, et la composition de la connaissance de décision pour la
consommation par des applications d'entreprise.
- Architecture de WinRFID
WinRFID a cinq couches principales. La première couche traite le matériel - lecteurs, étiquettes et autres
capteurs. La deuxième couche résume les protocoles de lecteur-étiquette. Au-dessus de cela se trouve la
couche informatique, qui traite les données produites par le lecteur. La quatrième couche constitue le
cadre de XML pour la représentation de données et d'information. La couche supérieure traite la
présentation de données selon les conditions des utilisateurs ou des différentes applications d'entreprise.
La figure I.7 montre les différentes couches.
18
Chapitre I
FIG.I.7 - WinRFID - architecture multi-couches [19]
La couche physique – Matériel Cette couche traite l'abstraction de trois éléments de l'infrastructure RFID
- lecteurs, étiquettes et interfaces d'entrée-sortie. L'abstraction simplifie l’extension de n'importe quel
lecteur, étiquette ou interface spécifique d'entrée-sortie pour enrichir les possibilités de l’intergiciel RFID.
Couche Protocoles Dans un intergiciel RFID complet, le support de protocoles d'étiquette multiples et les
possibilités d’ajout de nouveaux protocoles pour qu'ils deviennent disponibles est impératif.
Gestion des données Les problèmes dûs à la distance lecture/écriture, à l'orientation des étiquettes, au
matériel de l'article étiqueté, aux dysfonctionnements dans la lecture ou l'écriture comme les lectures
multiples de la même étiquette entraînent l’absence de lecture de quelques étiquettes, des lectures
erronées, etc.
Plateforme XML Les données brutes de l'étiquette (vérifiées et filtrées) nettoyées des streams de
données de la couche physique sont composées de plusieurs manières en une représentation à haut
niveau basée sur XML. L'information est filtrée, nettoyée, agrégée et adaptée selon les connexions faites
sur commande, qui peuvent être ajoutées aux services de l’intergiciel. L’objectif est de fournir des
données dans un format favorable à la prise de décision à la couche application.
Présentation des données Cette couche facilite la visualisation de données pour la prise de décision.
Actuellement, le portail et les connecteurs de base de données sont supportés. Le portail permet à des
utilisateurs de souscrire à l'information qui les intéresse. Le format de la livraison de données peut être
par défaut à la manière prévue par l'intergiciel ou l'abonné peut enregistrer des plug-ins d'adaptation de
données.
19
Chapitre I
Les services web - lecteur dans WinRFID
Dans WinRFID, le service web lecteur qui admet les lecteurs connectés à n'importe quelle plate-forme
(UNIX, Linux, etc, avec Java programming environment) supporte les standards des services web. Le
protocole SOAP (Simple Open Access Protocol) est utilisé pour transmettre des messages, WSDL (Web
Service Description Language) sert à décrire le protocole de communication (SOAP RPC ou SOAP orienté
message), le format de messages requis pour communiquer avec ce service, les méthodes que le client
peut invoquer ainsi que la localisation du service.
b. Le middleware AspireRFID [20]
- Présentation
Le projet AspireRFID vise à développer et promouvoir un middleware open-source, léger, conforme aux
standards, évolutif et intégré avec plusieurs outils pour faciliter le développement, le déploiement et la
gestion des applications basées sur la RFID et sur les capteurs. Il met en oeuvre plusieurs spécifications
des consortiums comme EPC Global, NFC Forum, JCP et OSGi Alliance. AspireRFID, fournit aussi un
ensemble d'outils permettant aux consultants RFID de déployer des solutions RFID sans avoir besoin de la
programmation ennuyeuse de bas niveau. AspireRFID permet les spécifications des processus permis par
la RFID. En conséquence, les outils produisent tous les objets RFID exigés pour déployer ces solutions sur
le middleware AspireRfid.
- Architecture de AspireRFID [21]
La figure I.8 montre les différentes couches de l’intergiciel RFID.
FIG.I.8 - Architecture de AspireRFID
20
Chapitre I
L’architcture est composée de :

Couche d'Abstraction de Matériel (Hardware Abstraction Layer HAL)
Le rôle de cette couche est d'unifier la façon dont l'intergiciel ASPIRE agit avec les lecteurs RFID des
différents fournisseurs qui supportent les différents protocoles. C'est basé sur l'introduction d'une
couche d'abstraction de matériel (HAL) et la mise à disposition d'un ensemble d'instructions fixe aux
couches du middleware qui consomment des lectures du matériel RFID.

Reader Core Proxy (RCP)
Pour rendre des lecteurs de protocole non EPC conformes, une application Reader Core Proxy est
utilisée comme médiateur entre un lecteur supportant le protocole "X" et l'Interface du protocole du
Lecteur.

Serveur de Filtrage et de Collection (Filtering & Collection Server ALE)
L'intergiciel de Filtrage et de Collection permet le filtrage et le comptage des opérations qui
produisent "des rapports" en réponse à des demandes ou "requêtes" du client. Le client sera
responsable d'interpréter et agir sur la signification du rapport.

Générateur des événements métier (Business Event Generator BEG)
L'architecture introduit un module Business Event Generator (BEG) entre le F&C et les modules de
partage d'information ou Sharing (par exemple, EPC-IS). Le rôle de la BEG est d'automatiser le
mapping entre les rapports émanant de F&C et les événements.

Entrepôt de Partage de l'information (Information Sharing Repository EPCIS)
Au cœur de l'architecture il y a l'entrepôt EPC-IS. L'Entrepôt de Partage de l'information ASPIRE est
responsable de la réception des données RFID du middleware, du filtrage et du stockage des données
RFID traduites dans des événements métier correspondants. L’entrepôt rend les activités métier et
des données de base disponibles et accessibles par d'autres applications, par l'interface
d'interrogation. En général, le partage des informations de l’entrepôt ASPIRE traite deux types de
données:
Les données RFID : Ces données changent très fréquemment, à des intervalles de temps où les
processus métier sont menés.
- Les données de l'entreprise Master, c'est-à-dire des données supplémentaires qui fournissent le
contexte nécessaire pour l'interprétation des données des évènements.
- L'intergiciel de partage d'information ASPIRE se compose de trois parties : d'une interface de capture
qui fournit des services web pour stocker des données, un entrepôt qui permet la persistance et
l'interface de requête qui fournit des services web qui récupèrent les données des événements de
l'entrepôt.

Application Connectrice (Connector Application)
L'interfaçage entre les systèmes IT et l'entrepôt de Partage de l'information EPCIS est réalisé grâce à
des composants middleware spécialisés qui sont appelés «connecteurs». L'objectif principal des
composants connecteurs est d'extraire l'interface entre l'entrepôt de Partage de l'information ASPIRE
et les systèmes d'Information de l'entreprise. Par conséquent, les connecteurs offrent des API, qui
permettent aux propriétaires de systèmes d'information d'entreprise d'échanger des informations
d'entreprise avec le système RFID middleware ASPIRE.
21
Chapitre I

La Gestion
L'architecture précise également la mise en œuvre des fonctionnalités de gestion de bout en bout
(E2E) basées sur la technologie JMX (Java Management Extension). À cette fin, un message JMX est
fixé pour chaque middleware et composant matériel. L'interface des messages JMX pour les lecteurs
est basé sur le protocole SNMP (Simple Network Management Protocol) et le protocole RM (Reader
Management), tout en reliant les composants middleware (par exemple, ALE, BEG, connecteur) en
utilisant MBeans qui accède à leurs propriétés de contrôle de niveau bas. Sur la base de ces messages
JMX, les applications de gestion sophistiquées composites peuvent être mises en œuvre. Les
applications de gestion peuvent être utilisées pour connecter et gérer les déclencheurs. Sur la base de
JMX, les commandes de contrôle des déclencheurs peuvent être émises lors de la survenance de
certains événements au niveau de n'importe quelle couche de l'intergiciel.

Déclencheurs
La plateforme de contrôle de déclencheurs définit certaines interfaces et déclencheurs que les
applications multi-tiers seront capables d'utiliser pour interagir avec succès avec les dispositifs
analogiques ou numériques, basés sur des événements du capteur. Ces capteurs sont soit des lecteurs
RFID soit d'autres capteurs physiques ASPIRE.

IEnvironnement de développement intégré (Integrated Development Environment AspireRfidIDE)
En ce qui concerne la facilité du développement et du déploiement, l'architecture spécifie l'existence
d'un IDE permettant la gestion visuelle de tous les fichiers de configuration et les méta-données qui
sont nécessaires à l'exploitation d'une solution RFID. Il s'agit notamment des outils suivants :
- Un éditeur de configuration pour les lecteurs physiques (Physical Reader Configuration Editor) :
pour configurer les lecteurs physiques ainsi que leurs paramètres de fonctionnement et
d'environnement.
- Un éditeur de configuration pour les lecteurs logiques (Logical Reader Configuration Editor) : qui
supporte la définition de lecteurs logiques (LLRP, RP, HAL et les lecteurs).
- F&C Commands Execution : qui aura comme objectif de fournir un client de contrôle pour
exécuter les commandes de spécification ALE sur un lecteur ou un composant qui implémente la
spécification ALE.
- Le configurateur des connecteurs (Connector Configurator) : qui sera capable d'interagir avec
l'application de connecteur pour révéler toutes ses fonctionnalités et configurations. Il devrait
permettre la configuration des connecteurs aux différents systèmes et bases de données.
- Un éditeur de données Maître (Le Master Data Editor) (avec le support de la description des
Processus métier élémentaires) qui permettra aux utilisateurs et / ou des consultants de modifier
les données d'entreprise incluant des informations sur l'emplacement de l'entreprise, ses lieux
d'affaires, ainsi que ses processus métier.
- Un éditeur de gestion de flux des processus métier (Business Prosess Workflow Management
Editor) qui peut offrir aux utilisateurs professionnels et aux consultants RFID une interface
utilisateur graphique pour la manipulation des processus métier complexes, qui sont composés
de flux de processus métier élémentaires. Cet outil de gestion de flux de travail va accroitre les
fonctionnalités de ces outils afin de soutenir les déploiements RFID conformément aux processus
métier particuliers.
22
Chapitre I
c. Le middleware Fosstrak [22]
- Présentation
Fosstrak est une plate-forme logicielle open-source RFID qui met en application les caractéristiques EPC. Il
est destiné aux créateurs d'applications et aux intégrateurs et fournit des composants logiciels de base
pour des applications de voie et de trace.
- Les Modules de Fosstrak
1. Fosstrak EPCIS : fournit un entrepôt EPCIS EPCglobal-certifié pour les requêtes clients. Il permet de :
- déployer un entrepôt EPCIS utilisant l'implémentation Fosstrak.
- interroger un entrepôt existant d'EPCIS utilisant une interface graphique utilisateur.
- remplir l'entrepôt EPCIS existant avec les données EPC utilisant l'interface graphique utilisateur.
Il comporte trois modules séparés :
- une implémentation de l'entrepôt EPCIS
- une application interactive de capture EPCIS
- une application interactive de requêtes EPCIS. La figure I.9 donne une vue d'ensemble de
l'implémentation de Fosstrak EPCIS.
FIG.I.9 - L'entrepôt EPCIS.
23
Chapitre I
2. L'intergiciel ALE de Fosstrak
L'intergiciel ALE de Fosstrak (voir la figure I .10) permet de filtrer et rassembler des données des lecteurs
RFID.
FIG.I.10 - L'intergiciel ALE.
L'intergiciel ALE de Fosstrak comporte trois modules séparés :
-
le serveur de filtrage et de collection (filtering and collection server)
- un client autonome (standalone client) pour configurer des serveurs de filtrage et de collection
- un client basé sur le WEB (a web-based client) pour configurer des serveurs de filtrage et de
collection.
Tous les modules implémentent la spécification EPCglobal ALE 1.1. Pour communiquer avec des lecteurs
RFID, l'intergiciel ALE de Fosstrak emploie le protocole LLRP. Pour les lecteurs qui ne supportent pas LLRP,
l'intergiciel ALE emploie la couche d'abstraction de matériel de Fosstrak (Hardware Abstraction Layer
HAL). Afin de configurer les lecteurs RFID qui supportent LLRP, Fosstrak LLRP Commander peut être
employé.
3. Fosstrak LLRP Commander : permet de configurer et contrôler les lecteurs RFID LLRP (voir Fig.I.11).
FIG.I.11 - Fosstrak LLRP Commander
24
Chapitre I
Parmi les middlewares open-source, il y a le middleware RIFIDI. Nous utiliserons quelques classes de cet
intergiciel dans notre implémentation. Ainsi, son émulateur sera utile pour pouvoir communiquer avec
des lecteurs (Alien 9800) et des étiquettes simulés (voir la section 3 du chapitre IV : Implémentation).
I.7.5. Synthèse sur les middlewares RFID
Dans les usines, les entrepôts, les centres serveurs de distribution et d'autres équipements beaucoup de
lecteurs et d'antennes distribués capturent les données RFID, qui doivent communiquer avec une série
d'applications telles que des systèmes de planification de ressource (ERP) d'entreprise, des systèmes de
gestion d'entrepôt (WMS), bases de données d'entreprise, systèmes de contrôle de processus industriel.
L'intergiciel RFID, dans ces équipements, est indispensable pour trois raisons principales :
1. La nécessité de filtrer les lectures doubles et l'information redondante afin d'éviter la transmission de
l'information non nécessaire pour les applications, et en même temps optimiser les ressources du réseau.
2. La nécessité d'une interface pour prendre en compte des lecteurs, des étiquettes et des dispositifs
dans un environnement à plusieurs fournisseurs hétérogènes.
3. La nécessité de passer et d'acheminer des flux de données RFID à différentes applications et bases de
données.
L'importance de l'intergiciel RFID entraîne le développement de plusieurs produits d'intergiciel. Le marché
est dominé par :
a. Les compagnies spécialisées qui offrent les produits qui intègrent des lecteurs RFID, filtrent les données
globales et incorporent même des principes économiques, et
b. Les fournisseurs géants tels qu'IBM, Microsoft, Oracle, SAP et Sun Microsystems, qui ont prolongé leur
développement d'applications et de technologies « intergiciel » pour manipuler la RFID.
On note plusieurs efforts pour fournir des produits d'intergiciel RFID Open Source, les plus connus sont :
- FossTrak [22].
- AspireRFID [20].
L’intergiciel RFID Open Source offre quelques avantages distincts, qui peuvent être récapitulés comme
suit :

L'intergiciel Open Source peut réduire le coût de propriété (Total Cost of Ownership TCO) pour
des déploiements RFID. Le coût d'une plate-forme d'intergiciel RFID est un facteur de contribution
au TCO d'une solution de déploiement de RFID. L'adoption d'une solution sans redevance d'OSS
pourrait aider des entreprises à réduire TCO qui est associé aux déploiements RFID. C'est
particulièrement important pour les petites et moyennes entreprises (Small-Medium-Enterprise
SMEs), qui ne peuvent pas avoir les moyens TCO hauts. Notons que la nécessité d'abaisser RFID
TCO est de nos jours plus pressante que jamais, étant donné que beaucoup de PME sont
actuellement frappées par la récession globale. Par conséquent, l'intergiciel d'OSS RFID peut
amplifier leur capacité d'innover en utilisant la technologie RFID [23].
25
Chapitre I

Le développement de la communauté Open Source a pu accélérer l'évolution et l'adoption des
solutions RFID de compagnies multiples. Spécifiquement, il pourrait servir comme base aux
entreprises à accroître la RFID dans leurs offres de produit. En s’appuyant sur un arrangement
approprié, une approche open-source pourrait permettre aux utilisateurs et intégrateurs de
présenter effectivement la RFID et de permettre des solutions dans leurs processus métiers.

Les produits d'OSS sont ouverts à un examen public minutieux. Par conséquent, l'intergiciel d'OSS
RFID a renforcé la protection de la vie privée en lien avec le traitement de données RFID. Nous
soutenons donc qu'une approche d'intergiciel source ouverte peut être la voie « intimité-amitié. »
a. Les middlewares Open-source
1. AspireRFID
Aspire est basé sur les technologies : Java, SOAP [24]. Il prolonge l'architecture EPC dans les secteurs
suivants :
- La génération configurable des événements métiers c.-à-d. visant le repérage automatisé de
l'étiquette RFID en fonction des données métiers.
- Soutien et intégration des capteurs de données, qui sont essentielles pour une série d'applications
qui doivent accroître des mesures physiques (par exemple, la température, humidité, poids,
s'allumant).
- Gestion bout à bout du réseau RFID, qui permet une approche holistique pour contrôler tous les
éléments d'une infrastructure.
- Programmabilité et environnements de développement intégrés (IDEs), qui facilitent le
développement et le déploiement visuels des solutions de RFID.
Les avantages de Aspire sont :
-
Entièrement gratuit et Open Source (LGPL v2.1)
Facilite l'accès à la RFID aux PME
Propose des outils d’aide au développement (IDE basé sur Eclipse)
Optimisé pour les standards (EPC Global)
Ses inconvénients :
- Nombre réduit de lecteurs supporté.
- Installation complexe et manque de support d’aide.
- Trop de fonctionnalités comparées au réel besoin.
- Manque d’informations.
2. Fosstrak
Fosstrak est une plate-forme logicielle RFID open-source qui met en application les caractéristiques de
réseau EPC. On le prévoit pour stimuler le prototypage rapide des applications RFID et pour accélérer le
développement de l’internet des objets (Internet of Things). Fosstrak est une plate-forme logicielle opensource qui facilite l’automatisation des processus métiers utilisant la technologie d'identification par
radiofréquence pour acheminer et identifier différents articles dans la chaîne d'approvisionnements.
26
Chapitre I
La deuxième ligne de la recherche dans Fosstrak est concernée par la programmation orientée endroit.
Motivés par l'observation que l'endroit est un concept clé dans le calcul omniprésent, des techniques sont
explorées pour faire de l'endroit une construction de programmation.
Ceci nécessite la création des modèles, des constructions de langage et des architectures de support de
sorte que des rapports locationbased et les aspects basés par la trajectoire sont facilement évalués,
accédés, et traités.
b. Un middleware non Open-source : WinRFID
L'intergiciel WinRFID attaque les caractéristiques importantes telles que l'évolutivité et l'administration
d'infrastructure, le traitement intelligent des événements et des données, les applications d'entreprise.
Différents modules ont été conçus qui faciliteraient le déploiement, la sécurité et la préparation facile de
données. L'intergiciel a un ensemble d'applications programmées et interfaces d'intégration pour le
développement d'applications. En même temps, WinRFID a des possibilités plug-in pour s'adapter à des
technologies symbiotiques telles que les services d'endroit et les capteurs qui augmenteraient non
seulement l'efficacité technologique du système de RFID, mais permettent également d’ajouter la valeur
aux processus métiers.
Le middleware WinRFID fournit un système RFID homogène qui peut fournir l'information intelligente en
filtrant et en agrégeant des données rassemblées au bord d'un réseau RFID d'une série de transpondeurs
à l'aide des lecteurs divers. La technologie d'infrastructure de WinRFID est examinée pour un ensemble
varié d'applications comprenant les soins médicaux, les chaînes d'approvisionnement, la gestion
bibliothécaire, la sécurité ….
WinRFID fournit un environnement rapide de développement d'applications indépendemment de la
plate-forme. Il soutient de divers scénarios d'applications. Il supporte une série de lecteurs/étiquettes des
différents fournisseurs de matériel (fréquences de LF, HF à UHF, protocoles EPC, ISO 0 ICode, Tiris et
d'autres protocoles) [25].
Il fournit aussi la capture intelligente des données, le lissage, le filtrage, le routage et l'agrégation. Il utilise
XML et le protocole SOAP pour la représentation de données et des évènements pour soutenir
l'interopérabilité. La base de données répartie et les données locales sont employées pour fournir la
persistance et la consistance des données. Il est facile à déployer pour contrôler le réseau de lecteurs. Il
soutient la collecte de données des différents capteurs comme la température, l'humidité, la pression
etc., utilisées fortement dans la gestion de la chaîne du froid et d'autres applications de la chaîne
d'approvisionnement. Malheureusement, WinRFID n'est pas open-source et les services Web et le
paradigme SOA sont en cours de développement.
I.8. Conclusion
Nous avons introduit dans ce chapitre la technologie RFID en étant l’une des technologies d’identification
automatique. Elle a la particularité de fonctionner à distance. Nous avons essayé de présenter les
différents éléments de l’infrastructure RFID et principalement l’intergiciel ou le middleware RFID qui joue
un rôle important dans notre contribution puisque nous avons développé nos méthodes d’analyse de
données au niveau de l’intergiciel et précisément dans le module de filtrage et de collection.
Le chapitre suivant présente les principaux concepts de la sûreté de fonctionnement et de tolérance aux
fautes dans les systèmes RFID.
27
/
Chapitre
2
SÛRETÉ DE FONCTIONNEMENT
DES SYSTÈMES RFID
II.1. INTRODUCTION
Nous présentons dans ce chapitre les principaux concepts de la sûreté de fonctionnement. Nous
introduisons d’abord la notion de sûreté de fonctionnement dans les systèmes informatiques. Elle peut être
définie comme la propriété qui permet de placer une confiance justifiée dans les services que délivrent ces
systèmes [4]. Ensuite, nous décrivons les différents concepts de base et les principales approches de sûreté
de fonctionnement et de tolérance aux fautes. Enfin, nous montrons les différents niveaux dans lesquels la
tolérance aux fautes peut être appliquée.
28
Chapitre II
SÛRETÉ DE FONCTIONNEMENT DES SYSTÈMES RFID
Nous consacrons une section pour définir les notions statistiques utilisées dans l’approche que nous
proposons pour réaliser l’analyse des données d’un système RFID en vue d’assurer sa tolérance aux fautes.
Ce chapitre est organisé comme suit : la première section introduit les concepts de base de la sûreté de
fonctionnement. La deuxième section discute la tolérance aux fautes à deux niveaux d'abstraction (le
matériel et l'intergiciel). La dernière section présente les travaux sur la tolérance aux fautes dans les réseaux
de capteurs dont nous nous sommes inspirés.
II. 2. CONCEPTS DE BASE DE LA SÛRETÉ DE FONCTIONNEMENT
La première sous-section définie le service. La deuxième sous-section définie la sûreté de fonctionnement
comme une propriété attendue des services des systèmes informatiques et présente quelques techniques
de sûreté de fonctionnement et de tolérance aux fautes.
II.2.1. Service
Un service est un ensemble de fonctions défini par une interface, "contrat" entre le fournisseur et
l’utilisateur du service [26] (Voir la figure II.1).
FIG.II.1 - Service
Parmi les propriétés attendues d’un service : la sûreté de fonctionnement.
II. 2.2. La sûreté de fonctionnement des systèmes informatiques
C’est " la propriété qui permet de placer une confiance justifiée dans les services que délivrent ces
systèmes." [4].
Les concepts de base de la sûreté de fonctionnement sont :
 Les entraves
 Les attributs
 Les moyens
La FIG.II.3 résume ces concepts et nous expliquons par la suite le sens de ces concepts.
29
Chapitre II
A. Les entraves
Nous avons trois types d’entraves : les fautes, les erreurs et les défaillances.
1. Les fautes
Une faute peut être définie comme une cause pouvant provoquer une erreur.
Les fautes de programmation, la malveillance et les catastrophes naturelles sont des exemples de fautes.
Quand une faute est activée, la partie du code affectée est exécutée. Une erreur est alors créée.
Les fautes peuvent être classées selon:

la cause comme les fautes physiques et les fautes dues à l’homme.

la nature comme les fautes accidentelles et les fautes intentionnelles.

la phase de création ou d’occurrence par rapport à la vie du système comme les fautes de
développement et les fautes opérationnelles.

la situation des fautes par rapport aux frontières du système comme les fautes internes et les fautes
externes.

la persistance comme les fautes permanentes et les fautes temporaires.
2. Les erreurs
Une erreur est un état (ou partie de l'état) du système susceptible de provoquer une défaillance.
Un exemple d’erreur est lorsqu’une connexion est coupée entre deux points qui devraient être reliés entre
eux.
3. Les défaillances
Une défaillance du système apparaît lorsque le service rendu par le système ne correspond pas à la
réalisation de la fonction du système. C'est une transition d’un service correct vers un service incorrect.
Les défaillances sont classées selon le domaine de défaillance comme des défaillances en valeur et des
défaillances temporelles.
Impact de la faute
On peut aller de la faute à la défaillance comme suit : quand une faute est activée, elle provoque une erreur.
En propageant, l’erreur engendre une défaillance (voir la FIG.II.2).
30
Chapitre II
FIG.II.2 - De la faute à la défaillance
La Fig.II.2 présente un système composé de trois modules M1, M2 et M3. L’activation de la faute au niveau du
module M1 a provoqué une erreur. En propageant, l’erreur 1 engendre une autre erreur au niveau du
module M2 puis une autre au niveau du module M3. Le service rendu par le système ne correspond pas à
l’objectif attendu : nous avons une défaillance.
Nous avons montré les différents états des entraves. Nous expliquerons par la suite les différents attributs de
la sûreté de fonctionnement.
B. Les attributs [4]
Les différents attributs de la sûreté de fonctionnement sont :
1. Disponibilité: c’est la capacité du système à être prêt à délivrer le service. C’est la fonction
du temps définie comme étant la probabilité que le système fonctionne correctement et est
disponible à un instant t.
2. Fiabilité: elle est définie par rapport à la continuité de service. C'est une fonction du temps
définie comme étant la probabilité conditionnelle que le système fonctionne correctement
pendant un intervalle de temps [t0,t] sachant que son fonctionnement était correct à
l'instant t0.
3. Sécurité-innocuité : elle est définie par rapport à l'écartement des conséquences
catastrophiques sur l'environnement du système. C’est la Fonction du temps définie comme
étant la probabilité à l’instant t qui fait que le système soit il fonctionne correctement soit il
s'arrête de fonctionner de manière à ne pas nuire à la sécurité des personnes et des autres
systèmes en relation avec lui.
31
Chapitre II
4. Sécurité-confidentialité : elle est définie par rapport à la préservation de la confidentialité
et de l'intégrité des informations.
5. Maintenabilité : elle mesure la facilité de réparation d'un système défaillant. C'est la
probabilité que le système défaillant revienne à un état de fonctionnement correct après un
délai t.
6. Performabilité : elle peut être définie comme étant la poursuite du fonctionnement correct
d'un système en présence d'éléments défaillants avec des performances moindres. C'est
une fonction du temps définie comme étant la probabilité que les performances du système
soient supérieures ou égales au seuil L à l'instant t.
7. Testabilité: mesure de la facilité d'exécution de certains tests sur le système.
C. Les moyens de la Sûreté de Fonctionnement (SF) [27]
Les moyens de la sûreté de fonctionnement sont classés en quatre familles:
1. Prévention des fautes
C’est la méthode qui permet d’empêcher l'introduction de fautes de conception ou de fabrication et
d’éviter l'apparition des fautes dans la phase opérationnelle (phase de programmation structurée, phase
de modularisation,...).
2. Tolérance aux fautes
C’est l’ensemble des moyens permettant au système de fonctionner en dépit des :
 fautes physiques,
 fautes de conception,
 erreurs de l'utilisateur,
 fautes intentionnelles.

Élimination des fautes
Elle peut être réalisée en réduisant le nombre ou la sévérité des :
 fautes fonctionnelles,
 fautes matérielles.
en utilisant des méthodes de test et de vérification.

Prévision des fautes
C’est la méthode qui permet d’estimer la présence, la création et les conséquences des fautes.
32
Chapitre II
La figure II .3 résume tous les concepts de la sureté de fonctionnement.
FIG.II.3. Concepts de base de la sûreté de fonctionnement des systèmes informatiques [28]
II.2.3. Tolérance aux fautes
La tolérance aux fautes peut être définie comme étant la « méthode qui permet à un système de remplir ses
fonctions en dépit des fautes pouvant affecter ses composants, sa conception ou ses interactions avec des
hommes ou d'autres systèmes » [5].
Quelles que soient les précautions prises, l’occurrence de fautes est inévitable (erreur humaine, malveillance,
vieillissement du matériel, catastrophe naturelle, etc.). Les mesures prises peuvent seulement réduire la
probabilité de leur occurrence [26].
33
Chapitre II
La technique la plus utilisée pour traiter les erreurs consiste à détecter l’existence d’un état incorrect (erreur)
puis remplacer l’état incorrect par un état correct (conforme aux spécifications).
L a sous-section suivante présente les différents types de moyens utilisés pour détecter l’erreur.
II.2.4. La détection des erreurs [5]
Il y a différents types de moyens de contrôle utilisés pour détecter l’erreur. Parmi ces types, nous citons :
1.
2.
3.
4.
5.
Codes détecteurs d'erreurs.
Redondance.
Contrôle de vraisemblance.
Contrôle de données structurées.
Le diagnostic en ligne:
La sous-section suivante présente l’une des techniques de contrôle utilisées pour détecter l’erreur : la
redondance.
II.2.5. Redondance [29]
Dans cette section, nous allons nous focaliser sur une technique trop utilisée et qui assure la sûreté de
fonctionnement : la redondance. Son principe est d’ajouter des ressources, de l’information, ou du temps
au-delà de ce qui est nécessaire pour le fonctionnement du système. L’objectif ici est de permettre la
détection des fautes et la tolérance aux fautes. Il existe quatre formes de redondance :
- matérielle
- logicielle
- temporelle
- d’information
Nous avons utilisé dans notre approche (dans le chapitre suivant) la redondance matérielle et nous comptons
dans nos futurs travaux utiliser la redondance logicielle. Nous présentons par la suite ces deux formes de
redondances.
a. Redondance Matérielle
C’est la forme la plus répandue de redondance en raison de la diminution de coût du matériel et de la
minimisation de la taille des composants. Il existe trois types de techniques :



Les techniques passives
Les techniques actives ou dynamiques
Les techniques hybrides.
34
Chapitre II
1. Redondance matérielle passive
L’objectif de la redondance matérielle passive est de masquer les fautes et éviter leur propagation en
erreurs. Son mécanisme de base est le vote majoritaire. Un exemple est la redondance modulaire triple
(Triple Modular Redundancy ou TMR) [30](voir la Fig.II.4).
FIG II.4 - TMR (triple modular redundancy).
La Fig.II.4 présente le TMR. M1, M2 et M3 sont trois modules qui génèrent des données homogènes. Le voteur
permet de produire la donnée finale.
Généralisation de TMR
On généralise le cas de la FIG.II.4 à N modaires : Redondance N-modulaire (N-modular redundancy ou NMR).
N modules identiques sont utilisés avec N impair.
Les systèmes utilisant la redondance matérielle passive se caractérisent par les points suivants :
a. Niveau d’insertion du vote
On donne dans la Fig.II.5 un exemple où Le vote peut être inséré à différents niveaux : Système de contrôle
industriel.
FIG II.5 - Système de contrôle industriel.
35
Chapitre II
b. Choix de conception
Le voteur peut être un voteur matériel ou un voteur logiciel.
Les critères pour choisir le type du voteur sont:




la disponibilité d’un processus,
la vitesse d’exécution du vote,
la limitation de puissance, de poids,
le nombre de voteurs à réaliser.
c. Discordance des valeurs obtenues
C’est quand les valeurs fournies par les différents modules sont différentes alors que l’environnement est
correct. Dans ce cas, on considère souvent la valeur médiane.
Nous avons présenté l’une des formes de la redondance matérielle : la redondance matérielle passive. La
sous-section suivante présente une autre forme : la redondance matérielle active.
2. Redondance matérielle active [29]
Il existe plusieurs types de redondance matérielle active : la duplication et la comparaison, l’utilisation des
modules « spares » et l’approche « pair-and-a-spare ».
- Duplication et comparaison
Elle consiste à :
1. Dupliquer le même matériel
2. Exécuter la même application sur chaque instance du matériel
3. Comparer les résultats obtenus
Les limitations de ce type de redondance sont :
- Le cas d’entrées fausses.
- L’inexactitude de la comparaison.
- La défaillance du comparateur.
- Utilisation des modules « spares »
On parle dans cette technique du remplacement standby ou de la disponibilité standby. Le principe est qu’un
seul module est opérationnel, les autres sont des spares (modules disponibles) ; si on détecte des fautes dans
le module principal, on procède à son remplacement.
On peut avoir :
- Un remplacement à chaud (modules de remplacement sont opérationnels).
- Un remplacement à froid (modules de remplacement non opérationnels).
36
Chapitre II
- L’approche « pair-and-a-spare »
Dans cette approche deux modules fonctionnent en parallèle et leurs résultats sont comparés. Si un module
est défaillant, on le remplace par un spare. On peut remplacer la paire entière en cas de défaillance.
3. Redondance matérielle hybride [29]
Dans cette technique, on combine la redondance active et la redondance passive. La faute est masquée pour
éviter la propagation en erreur. Si une erreur a lieu, elle est détectée et localisée pour permettre une
reconfiguration du système.
Nous avons présenté dans la sous-section a le premier type de redondance : la redondance matérielle. Nous
présentons dans la sous-section b une autre forme : la redondance logicielle.
b. La redondance logicielle
La redondance logicielle consiste à écrire plusieurs versions du programme. Elle est réalisée par les
techniques suivantes :
1. N-self-checking programming
Elle consiste à écrire N versions d’un même programme (voir la FIG II.6).. Chaque version possède son propre
jeu de test. Une logique de sélection choisit les résultats d’une version ayant passé avec succès l’ensemble de
ses tests.
FIG II.6 - N-self-checking programming
2. N-Version programming
Elle consiste à concevoir et coder le logiciel N fois et puis effectuer un vote majoritaire sur les N résultats
obtenus.
37
Chapitre II
Néanmoins, cette approche présente des inconvénients :
- Les concepteurs et programmeurs peuvent faire les mêmes erreurs.
- S’il y a des erreurs dans les spécifications, elles se propagent sur toutes les versions.
3. Blocs de recouvrement
Ce type est caractérisé par :
- N versions du programme
- Même ensemble de tests
- Une version est primaire, les autres sont secondaires.
Le principe est que si les tests indiquent une erreur dans la version primaire, nous prenons une version
secondaire, … etc.
Nous avons tenter de présenter les principaux concepts de la sûreté de fonctionnement : la tolérance aux
fautes et la redondance. La section suivante discute la tolérance aux fautes dans les systèmes RFID.
II. 3. TOLÉRANCE AUX FAUTES DES SYSTÈMES RFID
La tolérance aux fautes est l'une des problématiques cruciales dans le monde RFID, à cause de la nature
incertaine de la communication Radio Fréquence (RF).
Les étiquettes RFID sont attachées aux articles, elles peuvent être trouvées à n'importe quel moment par
l'intermédiaire des lecteurs RFID et du système de base de données géré en réseau, et elles peuvent être
contrôlées tout au long de leur cycle de vie. Les étiquettes RFID sont des puces de silicone avec leurs IDs, des
fonctions de radiofréquence, une certaine logique additionnelle et de la mémoire. La majeure partie des
étiquettes RFID est fournie avec la capacité de communiquer par radiofréquence avec des lecteurs externes.
L'infrastructure RFID peut recouvrir des sites multiples, qui entraînent le besoin de la configuration à distance
et d'outils de contrôle. De plus, pour une infrastructure robuste, la redondance doit être construite à chaque
couche, avec des capacités de sauvegarde.
II.3.1.Tolérance aux fautes aux différents niveaux
La tolérance aux fautes peut être intégrée à différents niveaux de l’infrastructure : le matériel, l’intergiciel et
l’application *5] (voir la FIG.II.7).
FIG.II.7 - Les couches d’intégration de la tolérance aux fautes dans un système RFID
38
Chapitre II
Nous allons discuter la tolérance aux fautes à deux niveaux d'abstraction (le matériel et l'intergiciel)
a. Matériel
Au niveau du matériel, se trouvent les puces et les lecteurs RFID.
Les lecteurs RFID disposent d'une vitesse de traitement appropriée et d'une mémoire importante. Grâce à la
puissante combinaison d'un processeur puissant et d'une mémoire en option pouvant atteindre jusqu'à 1Go,
le lecteur RFID est capable de fournir un traitement plus rapide.
Lorsque le système hôte ou l'alimentation électrique vient à faire défaut, l'importante capacité de mémoire
et les fonctionnalités de communication en mode différé garantissent la préservation des données, même
dans les environnements au volume d'étiquettes le plus important qui soit. En réalité, lorsque le disque dur
disponible en option est installé, les lecteurs RFID peuvent conserver des milliards d'étiquettes EPC.
En raison de la diversité de l'environnement d'application, les lecteurs RFID sont multi-protocoles et
supportent une grande variété de protocoles RFID, intègrent des modules de communication sans fil, et
utilisent le traitement à tolérance de fautes pour améliorer la fiabilité de la détection.
Les deux types d’étiquettes (les étiquettes passives et les étiquettes actives) sont très fiables en raison de
leur structure relativement simple et régulière.
La capacité des mémoires varie de 32 à 128 bits (non modifiables) pour les étiquettes passives et peut aller
jusqu’à 10 Kbits pour les étiquettes actives (peuvent être écrites plusieurs fois, effacées, modifiées et lues, le
nombre de répétitions de ces opérations peut dépasser les 500 000 ou 1 million pour ce type d'étiquettes)
[12].
Bien que la principale préoccupation des utilisateurs de la RFID soit le rendement d'exploitation du matériel
et des logiciels, les batteries jouent un rôle très important dans le système. Sans l'énergie de la batterie
fournie, le tag ne peut pas envoyer les informations nécessaires pour le lecteur système. Le choix de la
technologie des batteries a certainement un effet sur la performance globale du système dans le long terme.
Cet effet concerne des facteurs incluant la durée et la fiabilité du rendement du tag en toutes les
circonstances.
b. Niveau intermédiaire
Le principe de la tolérance aux fautes à ce niveau consiste à intégrer les mécanismes de tolérance aux
fautes dans l’intergiciel [5]. Puisqu'il est difficile de fournir la tolérance aux fautes d'une manière économique
au niveau lecteur-étiquette, nous comptons que les nombreuses approches insensibles aux défaillances pour
cette tâche apparaîtront au niveau d'intergiciel. Tandis qu'actuellement la plupart des applications sont très
simples, afin d'adresser des applications plus complexes, il y a un besoin de développer un intergiciel
beaucoup plus complexe [6].
Nous présentons ici quelques travaux qui se rapprochent de la tolérance aux fautes dans les systèmes RFID.
II.3.2. Travaux sur la tolérance aux fautes dans les systèmes RFID
La plupart des travaux sur la tolérance aux fautes ont été faits et évalués dans les réseaux des capteurs. Peu
de travaux ont étudié la tolérance aux fautes dans les systèmes RFID, la grande partie des solutions dans ces
systèmes traitent le manque de fiabilité inhérent dans les technologies de RFID.
39
Chapitre II
a. RF2ID : Une infrastructure d’intergiciel fiable pour le déploiement de la RFID [8]
Les auteurs dans [8] ont étudié des solutions de logiciel système pour réaliser un déploiement fortement
fiable qui atténue le manque de fiabilité inhérent dans les technologies RFID.
Ils ont développé:
1. une abstraction virtuelle de lecteur pour améliorer la nature potentiellement sujette aux erreurs des
données produites par les lecteurs.
2.
une abstraction originale de chemin pour capturer le flux d'information logique parmi les lecteurs
virtuels.
Ils ont conçu et ont mis en application un intergiciel RFID : RF2ID (infrastructure fiable pour l'identification par
radiofréquence) pour organiser et soutenir des requêtes sur des flux de données d'une façon efficace.
L'implémentation du prototype utilisant les lecteurs RFID et lecteurs simulés employant un modèle
empirique de lecteurs RFID montre que RF2ID peut fournir une fiabilité élevée et soutenir la détection basée
sur le chemin d'objet. Les auteurs emploient la nature du flux de données pour améliorer la fiabilité. De plus,
le flux de données peut aider dans l'organisation de données.
Les contributions principales de leur travail sont:
-
-
Étude du comportement incertain des dispositifs RFID : Ils ont fait une étude étendue de ces
dispositifs pour identifier la variété de paramètres qui affectent le fonctionnement du lecteur RFID.
La conception d'un système qui a une architecture basée sur le chemin : RF2ID utilise un chemin
virtuel (Vpath) pour distinguer logiquement l'écoulement des flux de données. Utilisant Vpath, le
système peut fournir une fiabilité plus élevée, fournir des possibilités pour organiser les flux de
données pour la gestion efficace des requêtes, et offrir un véhicule pour l'équilibrage de la charge
parmi les lecteurs.
Implémentation du système RF2ID et son évaluation : Ils ont développé un prototype de
l'architecture RF2ID. L'implémentation incorpore les lecteurs physiques aussi bien que les lecteurs
physiques simulés pour permettre des expériences commandées d'évolutivité. Les évaluations
démontrent la fiabilité du système et les possibilités améliorées de détection d'articles d'une
architecture basée sur la notion de chemin.
b. Travail de Agusti Solanas et al. [31]
Les auteurs dans [31] ont montré que les lecteurs peuvent localiser une étiquette en collaborant. Afin
d'exécuter correctement, les lecteurs doivent pouvoir communiquer entre eux. À cet effet, ils proposent
l'utilisation d'une topologie de réseau qui peut être représentée comme un graphe où les nœuds sont des
lecteurs et les arcs sont des connexions entre les lecteurs.
40
Chapitre II
c. Le travail de Julien David
Les contributions dans [32] étaient le développement d’un contrôleur de lecteurs RFID qui contrôle une
centaine de lecteurs et en réalisant la coordination entre eux. L’auteur a étudié l’émulateur du middleware
RIFIDI (nous l’utiliserons dans notre implémentation, voir la section 3.4 du Chapitre IV ). Il a constaté que cet
émulateur ne peut simuler plus que 6 lecteurs.
Nous avons présenté quelques travaux qui rapprochent de la tolérance aux fautes dans les systèmes RFID. La
section suivante parle de la tolérance aux fautes dans les réseaux de capteurs et des travaux dont nous nous
sommes inspirés.
II.4. LA TOLÉRANCE AUX FAUTES DANS LES RÉSEAUX DE CAPTEURS
II.4.1. Introduction
Un réseau de capteurs sans fil est un réseau ad hoc avec des petits nœuds sans fil communicants où chaque
nœud est équipé de composants multiples. En particulier, chaque nœud a un moteur de calcul, des soussystèmes de communication et de stockage, une batterie en réserve, des capteurs et dans certains cas des
composants en actions [6].
Les micro-capteurs sont capables de récolter et de transmettre des données environnementales d'une
manière autonome. La position de ces nœuds n'est pas obligatoirement prédéterminée. Ils peuvent être
aléatoirement dispersés dans une zone géographique, appelée « champ de captage » correspondant au
terrain d'intérêt pour le phénomène capté. Les données captées par les nœuds sont acheminées grâce à un
routage multi-saut à un nœud considéré comme un "point de collecte", appelé nœud-puits (ou sink). Ce
dernier peut être connecté à l'utilisateur du réseau (via Internet, un satellite ou un autre système). L'usager
peut adresser des requêtes aux autres nœuds du réseau, précisant le type de données requises et récolter
les données environnementales captées par le biais du nœud puits.
Le schéma de la figure II .8 montre la grande ressemblance au niveau de l'infrastructure entre un système
RFID complexe et un réseau de capteurs qui sont tous deux des systèmes embarqués.
FIG II.8. Infrastructure RFID/Réseau de capteurs
41
Chapitre II
Un système embarqué peut être défini comme un système électronique et informatique autonome, qui est
dédié à une tâche bien précise.
Un système embarqué intègre des logiciels et des matériels conjointement et spécifiquement conçus pour
assurer des fonctionnalités souvent critiques [33]. Ses ressources disponibles sont généralement limitées.
Cette limitation est généralement d'ordre spatial (taille limitée) et énergétique (consommation restreinte).
Le terme de système embarqué désigne aussi bien le matériel que le logiciel utilisé. Les systèmes embarqués
exécutent des tâches prédéfinies et ont un cahier des charges contraignant à remplir, qui peut aborder les
aspects :
-
Coût : le prix de revient doit être le plus faible possible surtout si le système est produit en grande
série.
Espace compté : ayant un espace mémoire limité de l'ordre de quelques Mo maximum. Il convient
de concevoir des systèmes embarqués qui répondent au besoin au plus juste pour éviter un surcoût.
Puissance de calcul. Il convient d'avoir la puissance de calcul juste nécessaire pour répondre aux
besoins et aux contraintes temporelles de la tâche prédéfinie. Ceci en vue d'éviter un surcoût de
l'appareil et une consommation excédentaire d'énergie (courant électrique).
Consommation énergétique la plus faible possible : due à l'utilisation de batteries et/ou, de
panneaux solaires voire de pile à combustible pour certains prototypes.
Temporel, dont les temps d'exécution et l'échéance temporelle d’une tâche sont déterminés (les
délais sont connus ou bornés a priori). Cette dernière contrainte fait que généralement de tels
systèmes ont des propriétés temps réel.
Sûreté de fonctionnement : s'il arrive que certains de ces systèmes embarqués subissent une
défaillance, ils mettent des vies humaines en danger ou mettent en péril des investissements
importants. Ils sont alors dits « critiques » et ne doivent jamais faillir.
Sécurité : ces systèmes peuvent se révéler être porteurs d'informations confidentielles pour leur(s)
utilisateur(s), qu'il convient de conserver et de protéger. Notamment, en ce qui concerne
l'acquisition et la transmission d'informations médicales. Par exemple, des systèmes personnels
permettant l'acquisition, par le patient lui-même, et la transmission à distance d'informations à
caractère confidentiel, comme des données médicales, ou relatives à la vie privée du ou des
utilisateurs en général.
Vu la quasi absence des travaux de tolérance aux fautes au niveau des systèmes RFID et vu la grande
ressemblance au niveau de l’infrastructure d’un réseau de capteur et un système RFID complexe, nous
pouvons nous inspirer des travaux faits pour la tolérance aux fautes dans les réseaux de capteurs.
Nous présentons par la suite les deux travaux sur la tolérance aux fautes dans les réseaux de capteurs dont
nous nous sommes principalement inspirés.
II.4.2. Travaux sur la tolérance aux fautes dans les réseaux de capteurs
A. Travail de Koushanfar : Tolérance aux fautes dans les réseaux de capteurs
Le travail de Farinaz Koushanfar et al. [6] présente une technique basée sur la validation pour la détection en
ligne des fautes de capteurs.
42
Chapitre II
Les auteurs réalisent l'analyse statistique sur les données pour chaque capteur. Si les valeurs obtenues pour
un capteur ne sont pas conformes dans un intervalle de confiance calculé par la méthode percentile, ce
capteur est considéré défectueux.
La sous-section suivante présente les notions statistiques : percentile et intervalle de confiance.
Percentile et intervalle de confiance
Cette section présente les notions statistiques mentionnées dans [6] et que nous allons utilisé dans notre
approche pour l’étude du comportement des lecteurs et des capteurs : le percentile et l’intervalle de
confiance.
- Percentiles [34]
Les statistiques d'ordre fournissent une manière d'estimer des proportions de données qui devraient être en
haut et au-dessous d'une valeur donnée, appelées un percentile. Le pième percentile est une valeur, Y (p), telle
qu’au plus (100p) % des mesures sont inférieures à cette valeur et au plus 100 (1 - p)% sont plus grandes. Le
cinquantième percentile s'appelle la médiane.
Les percentiles coupent un ensemble de données ordonnées en centièmes. Par exemple, 70% des données
devraient être au-dessous du soixante-dixième percentile.
Évaluation des percentiles
Les percentiles peuvent être estimés à partir des N mesures comme suit : pour le pième percentile, mettons
p(N+1) égale à k + d pour k un nombre entier, et d, une fraction supérieure ou égale à 0 et inférieure à 1.
1. Pour 0 < k < N,
2. Pour k = 0, Y (p) = Y [1]
3. Pour k = N, Y (p) = Y [N]
Un exemple
Nous donnons ici un exemple pour bien comprendre la méthode de calcul des percentiles.
Douze mesures d'une étude de mesures sont montrées ci-dessous. Les mesures sont en cm (voir Tableau
II.1).
43
Chapitre II
Tableau II.1. Résultats de mesure
i
1
2
3
4
5
6
7
8
9
10
11
12
Mesures
95.1772
95.1567
95.1937
95.1959
95.1442
95.0610
95.1591
95.1195
95.1065
95.0925
95.1990
95.1682
Statistiques d’ordre
95.0610
95.0925
95.1065
95.1195
95.1442
95.1567
95.1591
95.1682
95.1772
95.1937
95.1959
95.1990
Rang
9
6
10
11
5
1
7
4
3
2
12
8
Pour trouver le 90% percentile, nous remplaçons dans la formule de la condition (1) (voir : Évaluation des
percentiles).
p (N+1) = 0,9 (13) =11.7 ; k = 11, et d = 0,7 (avec N=12 et p=0,9).
De la condition (1), on estime que Y (0,90)= 95,1981 cm. Ce percentile, bien que ce soit une évaluation d'un
petit échantillon de mesures, il donne une indication sur la population des mesures.
- Intervalle de confiance [35]
En statistiques, et en particulier dans la théorie des sondages, lorsqu'on cherche à estimer la valeur d'un
paramètre, on parle d'intervalle de confiance lorsque l'on donne un intervalle qui contient, avec un certain
degré de confiance, la valeur à estimer. Le degré de confiance est en principe exprimé sous la forme d'une
probabilité. Par exemple, un intervalle de confiance à 95% (ou au seuil de risque de 5% et degré de confiance
de 95%) a une probabilité égale à 0,95 de contenir la valeur du paramètre que l'on cherche à estimer. Ainsi,
lorsqu'on effectue un sondage (tirage au hasard d'un sous-ensemble d'une population), l'estimation d'une
quantité d'intérêt donnée est soumise au hasard et correspond rarement d’une manière exacte à la valeur de
la quantité que l'on cherche à estimer. En présentant pour l'estimation non pas une valeur mais un
encadrement, on quantifie d'une certaine manière l'incertitude sur la valeur estimée.
Plus l'intervalle de confiance est de taille petite, plus l'incertitude sur la valeur estimée est petite.
Les bornes de l’intervalle de confiance sont des percentiles qui coupent l’ensemble de données. Par exemple,
pour l’intervalle de confiance IC95%, 95% des données devraient être au-dessus de la borne inférieure et audessous de la borne supérieure.
Pour bien interpréter l’intervalle de confiance et son étendue nous sommes allés à la référence [36]
Etendue de l’intervalle de confiance (IC) [36]
L’étendue de l’intervalle de confiance est égale à la borne supérieure moins la borne inférieure. Elle
quantifie la précision de l’estimation : plus l’étendue est faible plus l’estimation est précise.
44
Chapitre II
Plus la taille d’échantillon est importante, plus l’étendue de l’IC95% est faible. Pour réduire l’étendue de
moitié, il faut inclure 4 fois plus de sujets. Pour diviser l’étendue par k, il faut inclure k² fois plus de sujets.
Plus l’échantillon est hétérogène (i.e. plus la variance ou l’écart-type sont élevés), plus l’étendue est
importante. L’étendue de l ’IC% est directement proportionnelle à l’écart-type de la variable mesurée.
L'usage le plus simple des intervalles de confiance concerne les populations à distribution normale (en forme
de cloche) dont on cherche à estimer la moyenne [37]. Si on connaît l'écart type σ(X) (ou si on en connaît
une estimation assez fiable) de cette distribution, et si on mesure la moyenne sur un échantillon de taille n
pris au hasard, alors :

l'intervalle :
est un intervalle de confiance de

l'intervalle :

à environ 68 %
à environ 95 %.
l'intervalle :
à environ 99,7%.
Ces formules sont valables pour des échantillons supposés grands (n>100). Dans le cas d'échantillon plus
petit, la consultation d'une table de distribution de la loi de Student est nécessaire.
Pour augmenter la confiance, il faut élargir l'intervalle et pour obtenir un intervalle plus fin avec le même
degré de confiance, il faut augmenter la taille de l'échantillon [36].
B. La détection et la tolérance aux fautes distribuée dans les réseaux de capteurs
Xuanwen Luo Ming Dong et Yinlun Huang [7], proposent la tolérance aux fautes distribuée.
L'idée fondamentale de la détection distribuée est que chacun des capteurs indépendants prend une
décision locale (typiquement binaire) et puis ces décisions sont combinées au niveau du capteur de fusion
pour produire la décision globale.
n capteurs (S1,S2, …,Sn) observent une hypothèse inconnue (voir FIG II.9).
Les observations des capteurs sont indépendantes et distribuées, donnant l'hypothèse inconnue.
45
Chapitre II
Chaque capteur transmet sa décision à travers un canal d'accès multiple à un capteur de fusion. Basé sur la
décision reçue du capteur, le capteur de fusion prend la conclusion définitive concernant l'hypothèse
inconnue.
Le réseau considéré est susceptible également de contenir des nœuds de capteurs défectueux dus à
l'environnement dur et à des raisons de fabrication. Normalement, un événement, s'il se produit, devrait
être détecté en tant que « événement » par des capteurs de position. Le comportement défectueux qu’ils
considèrent se produit quand la décision de détection est convertie en « non-événement » dû à la faute du
capteur ou vice versa. La tolérance aux faute est réalisée grâce à la redondance (n capteurs homogènes) : le
capteur de fusion se base sur le résultat de plusieurs capteurs pour donner sa décision finale sur
l’événement.
FIG II.9. Détection distribuée de l'événement
Synthèse sur les deux travaux
Le travail présenté dans [6] donne une technique basée sur la validation pour la détection en ligne des fautes
de capteurs. L'analyse statistique est réalisée sur les données pour chaque capteur pour détecter les
capteurs défectueux. L’intervalle de confiance utilisé dans ce travail nous permet (dans notre approche) de
détecter les lecteurs et les capteurs défectueux après l’analyse effectuée sur les résultats d’inventaires et de
captage.
Le travail présenté dans [7] propose la tolérance aux fautes distribuée. L'idée fondamentale de la détection
distribuée est que chacun des capteurs indépendants prend une décision locale (typiquement binaire) et
puis ces décisions sont combinées au niveau du capteur de fusion pour produire la décision globale. Les
observations des capteurs sont indépendantes et identiquement distribuées, donnant l'hypothèse inconnue.
Dans notre approche que nous définissons dans le chapitre III, chaque lecteur donne son résultat
d’inventaire indépendamment des autres lecteurs. Ainsi, chaque capteur donne son observation
indépendamment des autres capteurs. Tous ces résultats sont combinés au middleware qui les analyse et
donne une observation finale pour chaque type de capteur, un résultat final d’inventaire et la décision finale
concernant l’événement.
46
Chapitre II
II.5. CONCLUSION
Ce chapitre présente les principaux concepts de la sûreté de fonctionnement.
La première et la deuxième section introduisent les concepts de base de la sûreté de fonctionnement et
présente quelques techniques de sûreté de fonctionnement et de tolérance aux fautes.
La troisième section discute la tolérance aux fautes dans les systèmes RFID à deux niveaux d'abstraction (le
matériel et l'intergiciel). Puisque les travaux sur la tolérance aux fautes au niveau des systèmes RFID sont
quasiment inexistants et comme la ressemblance au niveau de l'infrastructure entre un système RFID
complexe et un réseau de capteurs est évidente, nous nous sommes inspirés des travaux faits et évalués
pour les réseaux de capteurs, la quatrième section présente ces travaux.
Le chapitre suivant donne notre contribution.
47
Chapitre
3
Contribution : Analyse des données
d’un système RFID en vue de sa sûreté
de fonctionnement
III. 1. INTRODUCTION
Parmi les propriétés attendues des services offerts par les systèmes RFID: la sûreté de fonctionnement.
Malheureusement, les opérations de lecture et de détection et les mesures de capteurs sont inévitablement
soumises aux erreurs. Une faute peut être définie comme une valeur arbitraire d'une opération de détection
ou d’inventaire par un lecteur ou d’une mesure incohérente par un capteur, qui ne peut pas être compensée
systématiquement. On considère des fautes liées aux mesures incorrectes. L’une des techniques de sûreté
48
Chapitre III Contribution : Analyse des données d’un système RFID en vue de sa sûreté de fonctionnement
de fonctionnent que traite ce mémoire est la tolérance aux fautes. Elle peut être définie comme la : «
méthode qui permet à un système de remplir ses fonctions en dépit des fautes pouvant affecter ses
composants, sa conception ou ses interactions avec des hommes ou d'autres systèmes » [5]. Quelles que
soient les précautions prises, l’occurrence de fautes est inévitable (erreur humaine, malveillance,
vieillissement du matériel, catastrophe naturelle, etc.). Cependant, il faut assurer la fourniture du service
malgré l’occurrence des fautes [26]. Puisqu'il est coûteux d’intégrer la tolérance aux fautes au niveau du
couple lecteur-étiquette, nous comptons que les nombreuses approches insensibles aux défaillances pour
cette tâche apparaîtront au niveau de l’intergiciel. Le développement d’applications complexes entraîne le
besoin de développer un intergiciel beaucoup plus complexe. L'intergiciel est le paradigme de logiciel utilisé
par l’industrie pour assimiler différentes technologies dans l'infrastructure de traitement établie avec un
minimum de perturbations. L'intergiciel offre des services de haut niveau liés aux besoins de communication
des applications. Nous expliquons ici le concept de l'intergiciel RFID et montrons le rôle crucial qu'il joue.
La plupart des travaux sur la tolérance aux fautes ont été faits et évalués dans les réseaux des capteurs.
Nous nous intéressons dans ce travail à deux travaux. Le premier est le travail de Farinaz Koushanfar,
Miodrag Potkonjak et Alberto Sangiovanni-Vincentelli [6] qui présente une technique basée sur la validation
pour la détection en ligne des fautes des capteurs. Le deuxième travail est celui de [7] dans lequel les
auteurs traitent la tolérance aux fautes distribuée dans les réseaux de capteurs. Peu de travaux ont étudié la
tolérance aux fautes dans les systèmes RFID, la plupart des solutions dans ces systèmes traitent le manque
de fiabilité inhérent dans les technologies de RFID et ne traitent pas précisément la tolérance aux fautes.
Dans [8], les auteurs ont étudié le comportement incertain des dispositifs de RFID et ils ont conçu et ont mis
en application un intergiciel RFID appelé RF2ID (infrastructure fiable pour l'identification par radiofréquence)
pour organiser et gérer des requêtes sur des flux de données d'une façon efficace.
L'approche que nous souhaitons développer est basée sur deux idées :
1. Concevoir un système de décision RFID distribué en s’inspirant du travail de Xuanwen Luo et al. [7].
2. Comparer les résultats des inventaires des différents lecteurs, d’une part. Ensuite, comparer les
résultats des différents capteurs homogènes en utilisant des techniques statistiques non
paramétriques sur les résultats obtenus pour identifier les mesures qui ne sont pas corrigeables.
Nous nous inspirons du travail de F. Koushanfar et al. [6].
Nous traitons dans la section suivante notre contribution et le schéma proposé pour palier au problème de la
tolérance aux fautes dans les systèmes RFID : " Analyse des données d’un système RFID en vue de sa sûreté
de fonctionnement"..
.
49
III.2. CONTRIBUTION : "ANALYSE DES DONNÉES D’UN SYSTÈME RFID EN VUE DE SA
SÛRETÉ DE FONCTIONNEMENT"
III.2.1. Schéma adopté
L’objectif de notre approche est de concevoir un système RFID de décision tolérant aux fautes concernant un
événement.
Nous considérons pour cela des articles auxquels sont attachées des étiquettes RFID, certaines de ces
étiquettes sont dotées de capteurs de chaleur, d’humidité,… (voir la FIG.III.2).
Nous avons N lecteurs détectant et inventoriant un ensemble d’étiquettes qui contiennent M capteurs pour
observer une hypothèse inconnue. Chaque lecteur transmet ses résultats (inventaire des étiquettes, résultats
des différents capteurs) au middleware. Nous comparons les valeurs pour chaque opération de détection
effectuée par les lecteurs et pour chaque mesure de capteur. Enfin, nous réalisons l’analyse statistique sur
les données pour chaque lecteur et pour chaque capteur. Si les valeurs obtenues pour un lecteur ou pour un
capteur n’appartiennent pas à un intervalle de confiance calculé par la méthode percentile, ce lecteur ou ce
capteur est considéré défectueux. Les lecteurs et les capteurs voisins sont susceptibles d’avoir des résultats
semblables. E étiquettes sont déployées dans une région donnée, certaines parmi ces étiquettes sont dotées
de capteurs (M capteurs) pour observer un événement.
Chaque lecteur RFID inventorie et détecte une population d’étiquettes indépendamment des autres lecteurs,
certaines étiquettes sont équipées de capteurs. Les résultats sont combinés par le middleware pour
permettre la prise de décision globale pour le phénomène étudié (la décision qu’il faut prendre au niveau du
middleware pour l’exemple d’illustration dans la section 5 pour les produits alimentaires : évènement
(produits alimentaires altérés) ou non évènement (produits alimentaires non altérés).
Nous avons réparti la charge entre plusieurs stations : chaque station sera responsable d'un ensemble de
lecteurs pour améliorer la nature des données produites par les lecteurs. Avec les grands volumes de
données, la distribution à travers des sites géographiques multiples des systèmes RFID, le système global doit
pouvoir parvenir à des complexités permettant son extensibilité pour répondre aux requêtes des utilisateurs
efficacement. Ces problèmes s’amplifient dans les systèmes RFID où des données sont produites par des
dispositifs qui peuvent être défaillants comme les lecteurs et les capteurs RFID. Généralement les lecteurs
voisins Lect1, Lect2, … , LectN et les capteurs voisins sont censés produire des résultats et des mesures
semblables.
Alors, Les composantes principales dans notre architecture sont les stations, les lecteurs, les étiquettes et les
capteurs RFID. Une station est responsable d'un ensemble de lecteurs. Une station est un composant
statique qui est identifié par son adresse ip.
50
Chaque lecteur est identifié par son adresse ip (la station à laquelle il appartient) et son numéro de port.
Les lecteurs sont les dispositifs actifs capables de détecter des étiquettes en émettant un signal avec une
certaine fréquence. Nous supposons qu'un lecteur a certaines capacités de traitement et de stockage (par
exemple, un lecteur doit pouvoir stocker un certain nombre d'identifiants dans une cache, etc.). Le champ de
couverture des lecteurs est un paramètre de système à prendre en considération pendant le procédé de
déploiement.
Les étiquettes considérées dans notre système sont des dispositifs actifs qui peuvent répondre à des
requêtes des lecteurs. Nous utilisons des étiquettes actives (comme les étiquettes Tag RFID Active- capteur
température ITEMS_ET° : ces étiquettes de longue portée avec capteur de température intégré, l’étiquette
donne les codes identification et la température) (Voir Fig.III.1) .
FIG III.1. Tag RFID Active- capteur température ITEMS_ET°
Chaque étiquette a un identifiant unique et le retourne une fois questionnée par un lecteur. En outre, Nous
supposons que les étiquettes peuvent changer leur endroit à tout moment.
Le réseau considéré est susceptible de contenir des lecteurs défaillants ou des capteurs défectueux et ceci
est du à : l’environnement qui est parfois dûr et aussi à des raisons de fabrication. Tandis que la sûreté de
fonctionnement des systèmes RFID ne dépend pas seulement de la sûreté de fonctionnement des lecteurs et
des capteurs mais aussi d’autres facteurs (interférence RF, environnement de déploiement, placement des
lecteurs et des étiquettes, configuration des lecteurs) [8].
Pour réaliser la tolérance aux fautes de manière extensible et distribuée, nous proposons un schéma de
détection (Figure III.2) dans lequel nous utilisons la technique de redondance logicielle avec utilisation d’un
middleware qui analyse les données provenant des stations. Nous utilisons aussi la redondance matérielle
51
passive. Le middleware reçoit les données provenant des différentes stations, chaque station S est
responsable d’un ensemble de lecteurs RFID physiques. Chaque station S est responsable de la gestion
des données, la gestion du chemin et la gestion des requêtes. Les stations utilisent des variables locales et
des structures de données pour prendre des décisions locales individuelles qui affectent le comportement du
système global.
À partir des résultats qui viennent des lecteurs, le middleware peut :
1.
inventorier les étiquettes;
2. détecter en ligne les lecteurs et les capteurs défectueux en faisant une analyse statistique sur les
résultas des lecteurs et des capteurs.
3. prendre une décision binaire concernant l’événement étudié (événement ou non événement, par
exemple si la température dépasse 40°, le produit alimentaire est considéré altéré);
Nous voulons que la décision finale prise par notre système soit fiable malgré la présence des défaillances au
niveau de quelques composants de notre système. Notre but est de réaliser la tolérance aux fautes
distribuée puisque la décision finale concernant l’inventaire n’est pas prise par un seul lecteur. Aussi la
décision finale pour chaque type d’observation n’est pas prise à partir des résultats d’un seul capteur. Les
lecteurs et les capteurs qui donnent des résultas non-conformes aux résultats des autres lecteurs et
capteurs sont considérés défectueux et leurs résultats sont éliminés dans l’analyse : nous avons une
correction des fautes qui peuvent influencer sur les résultats finaux du middleware.
52
FIG.III.2 - Redondance matérielle passive (duplication du matériel : lecteurs, capteurs et stations et un voteur
logiciel au niveau du middleware).
III.2.2. Notre méthodologie
Nous décrivons dans cette section notre méthodologie pour détecter les lecteurs et les capteurs défectueux
pour avoir une décision globale (événement ou non événement) plus fiable.
53
a. L’activation des lecteurs se fait pendant des intervalles de temps séparés pour éviter les
interférences lecteur-lecteur qui peuvent influencer l’exactitude de notre étude.
b. Le middleware récupère les résultats des différents lecteurs : l’inventaire des lecteurs et les données
des différents capteurs (de chaleur et d’humidité par exemple).
c. Le middleware fait l’analyse statistique sur les résultats des inventaires faits par les lecteurs en
choisissant un percentile approprié (95% par exemple). Le choix du percentile est décisif dans notre
étude. Si le résultat d’un lecteur n’appartient pas à l’intervalle de confiance IC (ici à 95%) ce lecteur
est considéré défectueux; alors les résultats pris par ce lecteur ne sont pas pris en compte dans
l’analyse statistique pour les capteurs. Nous insérons ce lecteur dans la liste des lecteurs défectueux
(LD).
d. L’analyse statistique est faite ensuite sur les données collectées par les capteurs. Nous souhaitons
détecter les capteurs endommagés. Nous faisons l’étude pour chaque type de capteur en ignorant
les résultats retournées par les lecteurs appartenant à LD. Nous concevons une matrice de données.
Nous choisissons l’intervalle de confiance à 95%. Nous récupérons les indices des capteurs qui ont
donné des résultats qui n’appartiennent pas à l’intervalle de confiance. Ces capteurs sont suspect
d’être défectueux. Cependant la question qui se pose : quand considérons nous qu’un capteur est
défectueux? Alors il faut définir un seuil de valeurs erronées dans chaque analyse à partir duquel
nous décidons que ce capteur est erroné.
e. Après élimination des valeurs prises par les capteurs défectueux, le middleware prend une
observation finale pour chaque type de capteur xi ( la moyenne recalculée peut être utile) et à partir
de laquelle une décision binaire globale u (événement ou non événement) est prise.
1 Si NE (Non événement)
0 Si E (Événement)
u= 
f.
Nous enregistrons la liste des lecteurs et capteurs suspects. Si un élément suspect (lecteur ou
capteur) persiste dans 3 analyses consécutives (deux analyses successives sont séparées par une
durée fixe t), cet élément devient défectueux, et il sera remplacé ou supprimé du système.
III.2.3. Validité de la prise de décision
Pour que la décision du middleware soit valide concernant l’état d’un lecteur, nous dotons chaque lecteur
d’un GPS. Si un lecteur est suspect d’être défectueux (les valeurs des inventaires prises par ce lecteur
n’appartiennent pas à l’intervalle de confiance), nous regardons si l’ensemble des étiquettes (par exemple
95%) sont dans le champ d’action de ce lecteur.
La zone où se trouvent (où se déplacent) les étiquettes est (Z). C’est un rectangle P1P2P3P4 (voir la Fig.III.3).
54
FIG III.3. Validité de la décision concernant le lecteur suspect
Nous supposons connues les coordonnées des quatre points d’extrémité P1, P2, P3, P4 de la zone où les
étiquettes se déplacent.
Le GPS nous retourne les informations relatives à l’emplacement du lecteur.
Nous calcule les distances D1, D2, D3, D4 et nous les comparons avec le rayon du champ d’action R du lecteur.
Si D1<R et D2<R et D3<R et D4 <R.
Cela signifie que le champ d’action couvre 100% la zone Z, alors le lecteur suspect devient défectueux.
III.3. EXEMPLE ILLUSTRATIF
La figure III.4 illustre notre exemple. Nous avons les données suivantes :
Nous avons 24 étiquettes, les étiquettes sont numérotées dans la figure E1,…, E24 . Certaines de ces
étiquettes sont équipées de capteurs. C1, C2, C3 sont des capteurs de chaleur ; C’1, C’2 , C’3 sont des capteurs
d’humidité.
55
Pour les capteurs de température : le capteur C1 est attaché à l’étiquette E1, le capteur C2 est attaché à
l’étiquette E10 et le capteur C3 est attaché à l’étiquette E20.
Pour les capteurs d’humidité : le capteur C’1 est attaché à l’étiquette E4, le capteur C’2 est attaché à
l’étiquette E14 et le capteur C’3 est attaché à l’étiquette E24.
FIG III.4. Exemple.
56
Ces étiquettes sont lues par 7 lecteurs qui sont attachés à deux stations : L1, L2, L3, L4 sont attachés à la
station S1 ; L’1, L’2, L’3 à la station S2.
En résumé, nous avons :
Le nombre d’étiquettes E=24.
Le nombre de lecteurs N=7 ; N1=4 , N2=3.
Le nombre de capteurs M=6 ; M1=M2=3.
La liste des lecteurs attachés à la station S1 : L1 = {L1, L2, L3, L4}.
La liste des lecteurs attachés à la station S2 : L2 = {L’1, L’2, L’3}.
La liste des capteurs de température : CT = {C1, C2, C3}.
La liste des capteurs d’humidité: CH = {C’1, C’2, C’3}.
Les étiquettes sont attachées à des produits alimentaires. Nous faisons les inventaires des différents lecteurs
et la collection des données des différents capteurs d’une façon périodique (chaque quart d’heure).
L’activation des lecteurs est séparée par une période t pour éviter les interférences lecteur-à-lecteur et
lecteur-à-étiquette [2].
Au niveau du middleware, nous avons la décision globale: le middleware décide après inventaires et après
récupération des résultats des capteurs quels sont les lecteurs et les capteurs défectueux. Si aucun lecteur ou
capteur n’est défectueux, le middleware prend :
- Une observation finale concernant chaque type de capteur X.
- la décision globale binaire concernant le produit alimentaire : événement ou non événement.
Si Température > 40° ou Humidité > 80% alors le produit alimentaire est altéré (événement) sinon le produit
alimentaire est non altéré (non événement).
Résultats des inventaires et des observations des capteurs :
Une étiquette est considérée lue si le lecteur parvient à lire son identifiant. Les résultats des inventaires des
différents lecteurs sont :
Pour la station S1 :
le lecteur L1 a détecté 22 étiquettes, le lecteur L2 a détecté 23 étiquettes, le lecteur L3
a détecté 24 étiquettes, le lecteur L4 a détecté 24 étiquettes .
Pour la station S2 : le lecteur L’1 a détecté 10 étiquettes,le lecteur L’2 a détecté 23 étiquettes le lecteur L’3
a détecté 22 étiquettes .
En lisant l’étiquette, le lecteur détecte si cette étiquette est dotée d’un capteur. Si c’est le cas, il détecte son
type et récupère son observation. Les observations des différents capteurs sont données dans le Tableau
III.1. Le symbole / Signifie que l’étiquette qui inclut ce capteur n’a pas été détectée par le lecteur associé.
57
Tableau III.1. Résultats de captage
C1
C2
C3
C’1
C’2
C’3
L1
37°
36°
37°
70%
50%
/
L2
38°
37°
36°
71%
23%
/
L3
37°
37°
36°
70%
69%
70%
L4
37°
37°
38°
70%
89%
70%
L’1
/
/
37°
72%
46%
/
L’2
37°
38°
38°
69%
25%
72%
L’3
38°
/
37°
68%
24%
69%
1ère Analyse des données
Analyse des résultats des inventaires
Nous appliquons la formule suivante pour calculer la moyenne arithmétique :
………… (1)
Avec n=7, X1=22 étiquettes, X2= 23 , X3=24 ,X4=24, X5=10,X6=23 ,X7=22, alors :
(la moyenne)= 21.24 .
Pour calculer l’écart-type σ , nous appliquons la formule suivante :
………… (2)
avec n=7, x =21.24 , alors : σ (écart-type)= 4.62
L’écart type est important ce qui signifie que les valeurs d’inventaires ne sont pas centrées autour de la
moyenne [38] , ce qui signifie qu’il est fort probable qu'un lecteur n’observe pas beaucoup d’étiquettes.
Si nous calculons l’intervalle de confiance de
(la moyenne) à environ 95% , l'intervalle de confiance à
95% est:
IC95% =
 X

x  2
n

; x
2
  X 
n


………………(3)
(  : écart type, x : moyenne, n : taille de l’échantillon).
Avec n=7, x = 21.24 (la moyenne) et σ (écart-type)= 4.62.
L’intervalle de confiance IC95% = [17.66, 24.62]
Le résultat du lecteur L’1 n’appartient pas à l’intervalle de confiance alors le lecteur L’1 est défectueux.
Nous ajoutons L’1dans la liste des lecteurs défectueux : LD = {L’1}.
Analyse des résultats des capteurs d’humidité
Nous concevons la matrice des valeurs en éliminant les valeurs prises par le lecteur L’1 (voir le Tableau III.2).
58
Tableau III.2. Matrice d’humidité
C’1
C’2
C’3
L1
70%
50%
/
L2
71%
23%
/
L3
70%
69%
70%
L4
70%
89%
70%
L’2
69%
25%
72%
L’3
68%
24%
69%
Nous utilisons la formule (1) pour calculer la moyenne x :
n=16, X1=70%, X2= 71%, X3=70%, X4=70%, X5=69%, X6=68%, X7=50%, X8=23%, X9= 69%, X10=89%, X11=25%,
X12=24%, X13=70%, X14=70%, X15=72% et X16= 69%. Alors : x (la moyenne) = 61.19%.
Nous appliquons la formule (2) pour calculer l’écart-type ө :
n=16, X1=70%, X2= 71%, X3=70%, X4=70%, X5=69%, X6=68%, X7=50%, X8=23%, X9= 69%, X10=89%, X11=25%,
X12=24%, X13=70%, X14=70%, X15=72%, X16= 69% et x (la moyenne) = 61.19%. Alors : ө (écart-type)=19.16.
Nous appliquons la formule (3) pour calculer l’intervalle de confiance à 95% :
Nous avons n=16, x (la moyenne) = 61.19% et ө (écart-type)=19.16 alors : IC95%= [51.61%, 70.77%]
Nous parcourons la matrice des valeurs et nous testons chaque valeur. Si cette valeur n’appartient pas à
l’intervalle de confiance, nous récupérons l’indice de ligne (indice du capteur).
Les valeurs 50% , 23% , 89% , 25% , 24%, 72% n’appartiennent pas à IC95%.
Discussion : Comment considérer qu’un capteur est défectueux ?
Les valeurs prises par chaque capteur peuvent être différentes : elles sont prises à des instants différents.
Nous pensons que nous ne pouvons pas considérer qu’un capteur est défectueux seulement s’il donne une
valeur qui n’appartient pas à l’intervalle de confiance. Alors nous proposons l’utilisation d’un rapport R pour
chaque capteur générant des résultats hors de l’intervalle de confiance pour prendre la décision si ce capteur
est défectueux ou pas. Pour chaque capteur dont nous avons récupéré l’indice, nous calculons le rapport :
Le nombre des valeurs qui n’appartiennent pas à IC95%
R = ─────────────────────────────────
Le nombre total des valeurs prises par ce capteur
Et nous définissons un seuil à partir duquel nous décidons que le capteur est défectueux, par exemple 80%
Pour C’2 : R=6/7=0.86% alors le capteur C’2 est défectueux.
Nous insérons ce capteur dans la liste des capteurs d’humidité défectueux : CHD={C’2}
Analyse des résultats des capteurs de température
Nous refaisons la même analyse pour les capteurs de température.
Nous utilisons la formule (1) pour calculer la moyenne x :
n=18, X1=37°, X2= 38°, X3=37°, X4=37°, X5=37°, X6=38°, X7=36°, X8=37°, X9= 37°, X10=37°, X11=38°, X12=37°,
X13=36°, X14=36°, X15=38°, X16= 37°, X17=38° et X18= 37°. Alors : x (la moyenne)=37.12°
Nous appliquons la formule (2) pour calculer l’écart-type ө :
n=18, X1=37°, X2= 38°, X3=37°, X4=37°, X5=37°, X6=38°, X7=36°, X8=37°, X9= 37°, X10=37°, X11=38°, X12=37°,
X13=36°, X14=36°, X15=38°, X16= 37°, X17=38°, X18= 37° et x (la moyenne)=37.12° . Alors : ө (écart-type)=0.67
59
Nous appliquons la formule (3) pour calculer l’intervalle de confiance à 95% :
Nous avons n=18, x (la moyenne) = 37.12° et ө (écart-type)=0.67 alors : IC95%=[36.79,37.45].
L’étendue=Borne Supérieure – Borne inférieure de l’IC95% =37.45-36.79=0.66 n’est pas importante.
L’écart type n’est pas important ce qui signifie que les valeurs d’inventaires sont centrées autour de la
moyenne, cela veut dire que tous les capteurs de température donnent des résultats proches et
raisonnables.
2ème Analyse : Réétude avec la non prise en compte des résultats provenant des lecteurs et capteurs
défectueux
Le but ici est la production de décisions finales fiables. Nous construisons une nouvelle matrice de données,
cette matrice n’inclut pas les résultats des lecteurs et des capteurs défectueux.
Tableau III.3. Nouvelle matrice de données
L1
L2
L3
L4
C1
C2
37°
36°
38°
37°
37°
37°
37°
37°
C3
C’1
C’3
37°
70%
/
36°
71%
/
36°
70%
70%
38°
70%
70%
L’2
37°
L’3
38°
38°
38°
/
37°
69%
72%
68%
69%
Inventaires des lecteurs : Nombre d’étiquettes = 23 étiquettes (la moyenne des inventaires est prise en
excluant le résultat du lecteur L’1).
Les capteurs de chaleurs : L’observation finale de température : x T=37.12°
Les capteurs d’humidité : L’observation finale d’humidité (après élimination les résultats du capteur C’2) :
x H = 69.90°.
La décision finale concernant l’événement : u=0 Produit non altéré (Non événement) car température < 40°
et Humidité < 80%.
Pour réaliser une meilleure correction de la faute, notre schéma de décision devrait prendre en compte
l’erreur de détection des lecteurs et la faute du capteur en choisissant un meilleur percentile et un meilleur
intervalle de confiance (si l’intervalle de confiance à 95% génère beaucoup de valeurs erronées nous pouvons
utiliser par exemple l’intervalle à 99,7%) et en optimisant le seuil R pour décider qu’un lecteur est
défectueux.
III.4. CONCLUSION ET FUTUR TRAVAIL
Nous avons présenté dans ce chapitre notre contribution pour palier le problème de la tolérance aux fautes
dans les systèmes RFID : "Analyse des données d’un système RFID en vue de sa sûreté de fonctionnement".
Pour réaliser la tolérance aux fautes de manière extensible et distribuée, nous avons proposé un schéma de
décision dans lequel nous avons utilisé la technique de redondance logicielle avec utilisation d’un
middleware qui analyse les données provenant des stations. Notre but était de réaliser la tolérance aux
fautes distribuée puisque la décision finale n’est pas prise par un seul lecteur et par un seul capteur pour
chaque type. Les lecteurs et les capteurs qui donnent des résultas non-conformes aux résultats des autres
lecteurs et capteurs sont considérés défectueux et leurs résultats sont éliminés dans l’analyse, ce qui permet
de corriger les fautes qui peuvent influencer sur nos résultats. Le chapitre suivant donne notre
implémentation.
60
Chapitre
4
IMPLÉMENTATION
IV.1. Introduction
Ce chapitre présente le mini-middleware SOARFID que nous avons conçu pour valider notre
approche. Nous avons constaté durant notre étude que les middlewares existants ne répondent pas à nos
besoins. Alors nous avons développé un mini-middleware expérimental pour montrer le but de notre
travail. Parallèlement, les logiciels actuels deviennent de plus en plus distribués et opèrent dans des
61
Chapitre IV
IMPLÉMENTATION
environnements hautement dynamiques. Pour cette raison, nous avons utilisé l’architecture SOA (Service
Oriented Architecture) pour rendre l’application ainsi que notre mini-middleware complètement
distribués. Nous avons intégré nos modules d’analyse de données provenant des lecteurs et des capteurs
précisément dans le module de filtrage et de collection MFC qui est un module du mini-middleware
SOARFID (voir la sous- section IV.3.3). La première section présente les outils et les technologies utilisés
pour concevoir SOARFID, principalement la SOA et le middleware RIFIDI. La seconde partie concerne la
proposition de notre mini-middleware basé sur la SOA (Service Oriented Architecture).
IV.2. Technologies sous-jacentes
Cette section prépare l'ensemble des outils utiles pour mettre en œuvre notre mini-middleware RFID à
base de SOA. Ces technologies renferment, particulièrement, la SOA, JDeveloper et J2EE.
IV.2.1. SOA pour notre architecture multi-tiers
Dans cette section, nous expliquerons les aspects de la SOA. Nous montrerons la différence entre une
architecture orientée objet et une architecture basée sur la SOA et nous donnerons les bénéfices qu’elle
nous a apportées.
a. Définition de SOA
Le concept SOA est une évolution de l'informatique distribuée, conçue pour permettre l'interaction de
composants logiciels appelés “services” sur l'ensemble d'un réseau. Les applications sont créées à partir
d'une combinaison de ces services, qui peuvent être partagés entre plusieurs applications [39].
L'architecture orientée services (Service Oriented Architecture, ou SOA) est une forme d'architecture de
médiation qui est un modèle d'interaction applicative qui met en œuvre des services (composants
logiciels) :
-
avec une forte cohérence interne (par l'utilisation d'un format d'échange pivot, le plus souvent
XML),
-
et des couplages externes faibles (par l'utilisation d'une couche d'interface interopérable, le plus
souvent un service web).
Le service est une action exécutée par un « fournisseur » (ou « producteur ») à l'attention d'un « client »
(ou « consommateur »), cependant l'interaction entre consommateur et producteur est faite par le biais
d'un médiateur responsable de la mise en relation des composants.
L'objectif d'une SOA est donc principalement de décomposer une fonctionnalité en un ensemble de
fonctions basiques, appelées services, fournies par des composants et de décrire finement le schéma
d'interaction entre ces services. L'idée sous-jacente est de cesser de construire la vie d'une architecture
autour d'applications classiques mais plutôt faire en sorte de construire une architecture logicielle globale
décomposée en services correspondant aux processus métiers gérant cette application [40].
La SOA est un moyen étendu de réutiliser les modèles existants et de les transformer en des services plus
agiles [41]. La base d’une SOA repose sur des services répondant, notamment, aux critères :
62
Chapitre IV
-
-
-
IMPLÉMENTATION
Faiblement couplés : Les applications traditionnelles incluent dans leur code les données métiers.
Elles sont complètement liées aux systèmes pour lesquels elles ont été conçues. Toute demande
de modification, qu’elle concerne l’accès aux modèles, les règles de gestion de leur simulation ou
celles de présentation des résultats de la simulation, nécessitera une refonte du code entraînant
coûts, délais, compétences spécifiques et surtout manque de réactivité et risque de
déstabilisation des applications.
Distribués : Les modèles et les services qui composent l’application peuvent être physiquement
répartis sur différents systèmes dans l’environnement de simulation, mais aussi au-delà. Ils
permettent une approche distribuée, à l’opposé des systèmes traditionnels centralisés. Là où
l’environnement devait maintenir certaines fonctions et données comme les tarifs des
fournisseurs de modèles, il pourra interroger directement, via son applicatif, le service du
fournisseur de modèles sans se préoccuper de sa mise à jour.
Invocables et publiables : Les services doivent être invocables et publiables quels que soient les
systèmes utilisés.
Orientés métier : Les services permettent de gérer l’application avec une approche fonctionnelle,
par l’intermédiaire de processus métiers intégrés à l’architecture, permettant de la piloter sans
développement conséquent.
b. Concepts et fonctionnement d’une SOA : L’architecture des services Web a trois rôles distincts :



un fournisseur de modèles : Le fournisseur crée le service Web intégrant le modèle et le met à la
disposition des clients qui souhaitent l’utiliser.
un demandeur (consommateur) : Un demandeur est une application cliente (ou un poste
utilisateur Windows ou web…) qui utilise le service Web. Le service Web demandé peut
également être client d’autres services Web.
un agent (un référentiel) : L’agent, qui peut être par exemple un registre de service, permet au
fournisseur et au demandeur d’un service Web de communiquer.
Les trois rôles de fournisseur, de demandeur et d’agent interagissent les uns avec les autres par
l’intermédiaire des opérations de publication, de recherche et de liaison. Le fournisseur informe l’agent
de l’existence du service Web en utilisant l’interface de publication de cet agent pour permettre aux
clients d’accéder au service. Les informations publiées décrivent le service et spécifient son emplacement.
Le demandeur consulte l’agent pour localiser un service Web publié. Grâce aux informations sur le service
Web obtenues par l’agent, le demandeur peut lier, ou appeler, le service Web.
Le concept des services web s'articule actuellement autour des trois acronymes suivants [42]:
SOAP (Simple Object Access Protocol) est un protocole d'échange inter-application indépendant de toute
plate-forme, basé sur le langage XML. Un appel de service SOAP est un flux ASCII encadré dans des balises
XML et transporté dans le protocole HTTP.
WSDL (Web Services Description Language) donne la description au format XML des Web Services en
précisant les méthodes pouvant être invoquées, leur signature et le point d'accès (URL, port, etc..). C'est,
en quelque sorte, l'équivalent du langage IDL, (Interactive Data Language), est un langage de
programmation propriétaire apparu a la fin des années 1970, et qui est rapidement monté en puissance
dans les domaines de la télédétection et de l'astronomie. pour la programmation distribuée CORBA.
63
Chapitre IV
IMPLÉMENTATION
UDDI (Universal Description, Discovery and Integration) normalise une solution d'annuaire distribué de
Web Services, permettant à la fois la publication et l'exploration. UDDI se comporte lui-même comme un
Web service dont les méthodes sont appelées via le protocole SOAP.
Un Web Service peut, dans un exemple simple, laisser un client communiquer avec lui en utilisant des
messages XML qui répondent au standard SOAP (Simple Object ou Service Oriented Architecture
Protocol). Il représente donc le format d'échange de données dont les protocoles primaires sont HTTP et
HTTPS. Prenons un Web service donnant, pour un identifiant client particulier et un identifiant produit, le
prix du produit désiré. Un message SOAP contenant les bonnes informations et un champ prix vide pourra
être envoyé au service. En retour, sera renvoyé le message avec le prix du produit renseigné.
Un fichier WSDL (Web Services Description Language) décrit un web service : c'est la fameuse interface
évoquée précédemment dans la description d'un service. Pour faire un rapprochement, on peut voir ce
fichier comme une interface en langage JAVA, on connaît les méthodes mais par leur implémentation.
Un registre UDDI Universal Decription Discovery and Integration) est un annuaire basé sur XML qui
permet de publier des services et facilite leur découverte par d'autres services en définissant comment ils
interagissent. Un scénario d'utilisation possible est donc la publication d'un fournisseur de service (donc
de son WSDL) auprès d'un registre en créant tout d'abord une entreprise et une catégorie de service. Un
client demande ensuite à un registre UDDI la localisation d'un service qui correspond au service venant
d'être ajouté à l'annuaire. Le WSDL du service demandé est alors reçu par le client qui peut communiquer
avec le fournisseur de services en SOAP.
c. Quelle différence entre une architecture orientée objet et une SOA ?
Nous présentons les deux architectures pour montrer l’intérêt de la SOA.
1. Modèle orienté objets (POO)
La FIG IV.1. présente une architecture à trois couches classique avec un modèle objet :
FIG.IV.1 - Modèle orienté objets
Nous remarquons tout de suite le nombre de liens entre la couche présentation et les objets métiers.
Le code client doit jongler directement avec le modèle objet de la couche métier, ce qui a pour
conséquence de lier celle-ci très fortement à un modèle spécifique et requiert un nombre d'appels
important entre les deux couches.
64
Chapitre IV
IMPLÉMENTATION
2. Modèle orienté services (SOA)
La FIG.IV.2. présente une architecture orientée services qui reposerait sur les mêmes objets métiers :
FIG.IV. 2 - Modèle orienté services
Nous remarquons qu’il est introduit un niveau d'indirection supplémentaire sous la forme de services. La
couche présentation ne manipule plus directement les objets métiers, mais passe par des services. Les
objets métiers se trouvent dans des bibliothèques de classes directement chargées dans le même
processus que les services, le coût des appels aux objets métiers est alors très faible.
Les services agissent comme des boites noires faisant abstraction de la complexité du modèle objet,
présentant un ensemble de fonctionnalités restreint et permettant de réduire les échanges entre les
couches.
c. Les avantages de SOA :
La SOA permet de créer de manière incrémentale de nouvelles fonctions, de les combiner aux services
existants pour créer des applications composites [40].
La mise en œuvre d'une approche SOA au sein d’une infrastructure multi-tiers procure les avantages
suivants :
-
-
-
-
Optimisation de la qualité des services : La technologie SOA favorise considérablement la
réutilisation accrue des modèles et des services, laquelle se traduit par une amélioration de la
fiabilité et de la qualité des services par le biais de multiples cycles de test effectués sur les
modèles par différents spécialistes.
Diminution des coûts d'intégration : Les services normalisés fonctionnent parfaitement les uns
avec les autres, garantissant ainsi une connexion rapide et aisée.
Minimisation des risques : Des services moins nombreux et réutilisables contribuent à améliorer
le contrôle des stratégies de gouvernance de simulation et des tâches de modélisation et à
diminuer les risques globaux de non-conformité des opérations.
Modification en temps réel d'une simulation : Une simulation peut, en effet être, modifiée sans
intervenir sur les processus métiers eux-mêmes. Le travail du développeur est simplifié et plus
sécurisé.
Développement : Les développeurs se concentrent sur des fonctions élémentaires sans se
préoccuper de l’infrastructure d’accueil.
La réutilisation des modèles : ouvre naturellement les services à une consommation par des
applications externes.
L’indépendance des fonctions : par rapport aux processus métiers et à l’architecture d’accueil, la
SOA préserve l’évolutivité, la flexibilité et l’intégration.
Vers plus de sécurité : Le système de sécurité est basé au niveau du service. C’est le point central
qui permet de renforcer la sécurité (multi niveaux d’authentification, authentification forte,…).
65
Chapitre IV
IMPLÉMENTATION
IV.2.2. JDeveloper
Nous utiliserons principalement l’environnement de développement Oracle JDeveloper (voir FIG IV.3).
FIG.IV.3 - JDeveloper
Oracle JDeveloper, l'un des composants d'Oracle Fusion Middleware, est un environnement de
développement intégré (IDE) complet pour le développement Java et SOA (architecture orientée services)
figurant en tête du classement des principaux fournisseurs Java dans l'étude Forrester TechRankings.
Optimisé pour s'exécuter avec Oracle Application Server et la base de données Oracle, JDeveloper repose
sur des normes et plates-formes ouvertes en prenant en charge tous les principaux serveurs
d'applications J2EE et bases de données [43]. Un environnement de développement intégré commercial
entièrement gratuit, Oracle s'attache à offrir aux développeurs un plus vaste éventail d'environnements
et de technologies de développement. Dans ce but, Oracle propose gratuitement JDeveloper, intégrant
divers outils graphiques et déclaratifs pour JSP, Struts, JavaServer Faces (JSF) et Business Process
Execution Language (BPEL), comblant ainsi les attentes des développeurs jugeant insuffisantes les
fonctions offertes par la plupart des IDE Java gratuits.
IV.2.3. L’infrastructure J2EE
La plate-forme J2EE (Java 2 Enterprise Edition) désigne l'ensemble constitué des services (API) accessibles
et de l'infrastructure d'exécution [44].
Principe
J2EE comprend notamment :
-
Les spécifications du serveur d'application, c'est-à-dire de l'environnement d'exécution : J2EE
définit finement les rôles et les interfaces pour les applications ainsi que l'environnement dans
lequel elles seront exécutées. Ces recommandations permettent ainsi à des entreprises tierces de
développer des serveurs d'application conformes aux spécifications ainsi définies, sans avoir à
redévelopper les principaux services.
66
Chapitre IV
-
IMPLÉMENTATION
Des services, au travers d'API, c'est-à-dire des extensions Java indépendantes permettant d'offrir
en standard un certain nombre de fonctionnalités. Sun fournit une implémentation minimale de
ces API appelée J2EE SDK (J2EE Software Development Kit).
Nous avons présenté dans cette section l'ensemble des outils utiles pour mettre en œuvre notre minimiddleware SOARFID : la SOA, JDeveloper et J2EE. La mise en œuvre d'une approche SOA au sein de notre
infrastructure multi-tiers procure des avantages considérables (réduction des coûts de développement.
optimisation de la qualité des services, modification en temps réel d'une méthode, la réutilisation des
modèles, l’indépendance des fonctions par rapport aux processus métiers et a l’architecture d’accueil,
vers plus de sécurité…). Dans la mesure où J2EE s'appuie entièrement sur le Java, il bénéficie des
avantages et inconvénients de ce langage, en particulier une bonne portabilité et une maintenabilité du
code. De plus, l'architecture J2EE repose sur des composants distincts, interchangeables et distribués, ce
qui permet d’étendre notre architecture et de faciliter la maintenabilité de notre application. En reposant
sur J2EE, notre système peut posséder des mécanismes de haute-disponibilité, afin de garantir une bonne
qualité de service.
La section suivante présente notre mini-middleware SOARFID.
IV.3. Notre mini-middleware SOARFID
Cette section présente le mini-middleware SOARFID conçu pour évaluer notre contribution : "Analyse des
données d’un système RFID en vue de sa sûreté de fonctionnement".
IV.3.1. Présentation du problème
Après l’étude des middlewares open-source existants AspireRFID [21], Fosstrak [22] et Rifidi [45], nous
avons constaté que :
1. Les lecteurs virtuels ne se comportent pas comme les lecteurs réels : ces lecteurs ne génèrent pas
des erreurs.
2. La tolérance aux fautes n’est pas étudiée dans ces middlewares.
3. L’implémentation de ces middleware ne couvre pas les capteurs qui sont des composants
matériels très importants pour notre étude.
4. Les services web ne sont pas suffisamment abordés dans ce middleware.
Pour ces raisons, nous avons conçu un mini- middleware RFID expérimental distribué en java qui doit :
-
Communiquer avec les lecteurs (lecteurs Alien 9800 ainsi que nos propres lecteurs virtuels
simulés).
-
Filtrer et agréger les données provenant des lecteurs et des capteurs.
-
Enregistrer les événements de lecture et de captage dans un entrepôt.
-
Tolérer les fautes qui peuvent être au niveau de la lecture et du captage.
67
Chapitre IV
-
IMPLÉMENTATION
Détecter les lecteurs et les capteurs défectueux.
L’objectif principal est de tester et évaluer nos méthodes d’analyse des données provenant des lecteurs et
des capteurs pour assurer la tolérance aux fautes dans notre système RFID. Nous voulons que les
échanges d’information entre les différentes couches du middleware soient basés sur les services web et
pour cela nous utiliserons l’architecture SOA (Service Oriented Architecture).
Notre middleware est construit sous une architecture multi-tiers, la figure VI.4 le représente au complet.
IV.3.2. Architecture globale
La FIG IV.4 montre l’architecture globale de notre mini-middleware SOARFID. Elle présente les différentes
interfaces de notre système :

L’interface A : représente notre application qui permet la communication avec le minimiddleware SOARFID. Nous avons utilisé principalement à ce niveau l’un des composants
de l’infrastructure J2EE : les pages JSF (Java Server Faces). Il s'agit de la partie chargée de
l'interface avec l'utilisateur lui permettant de :
-
Créer des lecteurs, des étiquettes et des capteurs virtuels.
Lancer le processus d’analyse des données.
Visualiser les résultats de l’analyse.
 L’interface B : représente notre mini-middleware SOARFID, il se compose de trois
modules :
-
-
Module de communication avec le Matériel (MCM).
Module de Filtrage et de Collection (MFC).
Module de gestion de l’entrepôt (MGE).
Nous expliquerons ces modules dans la sous-section IV.3.3.
 L’interface C : représente les classes des composants matériels simulés. Nous utilisons
des lecteurs, des étiquettes et des capteurs simulés. Nous allons insérer les fautes dans
les lecteurs et les capteurs pour pouvoir montrer le but de notre approche. Nous
utiliserons aussi des lecteurs (Alien 9800) et des étiquettes virtuels créés par l’émulateur
de RIFIDI [46]. Nous avons créé un service web qui permet la communication avec un
lecteur Alien 9800 : le module de communication avec le Matériel (MCM) envoie une
requête Telnet [47] au lecteur Alien 9800 [48]. Le lecteur répond par renvoyer la liste des
étiquettes qui se trouvent dans son champ d’action.
 L’interface D : représente l’entrepôt EPCIS qui permet d’enregistrer les résultats datées
des différentes analyses. Des événements seront déduits directement après la dernière
analyse, d’autres seront dédiées après plusieurs analyses.
La figure suivante (FIG IV.4 ) montre l’architecture globale de notre mini-middleware SOARFID.
68
Chapitre IV
IMPLÉMENTATION
Application (JSF)
-
Création des lecteurs, tags, capteurs virtuels
Lancement du processus d’analyse
Visualisation des résultats
A
Services web
MFC
- Récupération des données :
-
V : Vecteur des inventaires des lecteurs
MCH : Matrice de captage de chaleur
MH : Matrice de captage d’humidité
- Analyse des données + Décision
sw : Données non filtrées
(String,xml,…)
C
SOARFID
Matériel
- Lecteurs RFID
Alien 9800
- Lecteurs RFID
virtuels simulés
- Etiquettes
(Gen1,Gen2)
- Capteurs
virtuels
simulés
sw : Données
filtrées
B
sw : Requête :
commande
Telnet
MCM
sw : Réponse :
String
MGE
Classes :Telnet.java
AlientClient.java
Enregistrements des données
datées pour pouvoir les utiliser
ultérieurement
Entrepôt
EPCIS
D
FIG IV.4 – Architecture de notre mini-middleware SOARFID
IV.3.3. Modules de SOARFID
Nous montrons ici les modules de l’interface B (SOARFID) de notre système. Elle est composée de trois
modules :
a.
Module de communication avec le Matériel (MCM) : Le rôle de ce module est de
communiquer avec les lecteurs Alien 9800 (lecteurs virtuels) ainsi que nos propres lecteurs
virtuels et consommer les lectures du matériel RFID. Ce module utilise des classes Java de
Rifidi en plus de nos propres classes java développées.
69
Chapitre IV
b.
c.
IMPLÉMENTATION
Module de Filtrage et de Collection (MFC) : Le module de Filtrage et de Collection permet
le filtrage et le comptage des opérations qui produisent "des rapports" en réponse à des
demandes aux "requêtes" émises et d'interpréter et agir sur la signification des réponses.
Nous avons développé nos méthodes statistiques d’analyse des données dans ce module.
Nous donnons les algorithmes d’analyse des données des lecteurs et des capteurs dans la
sous-section IV.3.4.b.
Module de gestion de l’entrepôt (MGE) : Il est responsable de la réception des données
RFID du middleware de filtrage et de stocker les données RFID dans l’entrepôt. L’entrepôt
rend les activités métier et des données de base disponibles et accessibles par d'autres
applications.
IV.3.4. L’interface C : Interface Matériel
Pour évaluer notre approche, nous avons créé nos lecteurs et capteurs virtuels pour pouvoir simuler le
comportement défectueux. Aussi, Nous avons utilisé les lecteurs virtuels (Alien 9800 [48]) de l’émulateur
de l’intergiciel RIFIDI pour montrer l’impossibilité d’évaluer notre approche avec de tels lecteurs. La soussection suivante (a) présente l’émulateur de RIFIDI et les lecteurs Alien 9800. La sous-section b présente
nos composants matériels (lecteurs, étiquettes, stations et capteurs) simulés.
a. Composant Open-Source : L’émulateur de Rifidi
RIFIDI [45] est un intergiciel RFID open-source. Nous avons testé AspireRFID [21], Fosstrak [22] et RIFIDI.
Nous nous sommes focalisés sur RIFIDI pour sa simplicité. RIFIDI offre un émulateur qui rend la
consultation des étiquettes facile. Nous avons utilisé principalement le lecteur Alien 9800.
1. Le lecteur Alien 9800
- Présentation
Alien 9800 est produit par la technologie Alien. C'est un lecteur d'usage universel qui peut lire des
étiquettes de la GEN 2 de la classe 1 [48].
Ce lecteur a les caractéristiques suivantes :




Numéro du modèle : ALR 9800
Protocole : TCP/IP
Communication : LAN TCP/IP(RJ-45), RS-232
Antennes : 4 ports
- Communication
Le lecteur Alien envoie des messages textes à travers une connexion TCP. La connexion peut être
simplement testée en telnetant dans le lecteur et en envoyant des commandes. Vous trouverez une
description de l’outil Telnet dans l’annexe.
Il y a deux modes principaux pour obtenir des étiquettes du lecteur Alien. Le plus simple est le mode « on
demand », dans lequel l'utilisateur publie simplement une commande et le lecteur renvoie une liste
70
Chapitre IV
IMPLÉMENTATION
d'étiquettes. Le mode autonome permet au lecteur d'agir en tant que client et d'envoyer des listes
d'étiquettes à un serveur à un certain endroit.
- Authentification
Le lecteur Alien exige un nom d’utilisateur pour être identifié. Le nom d’utilisateur et le mot de passe par
défaut est "alien/password".
- Travaux et études sur le lecteur Alien 9800
Dans [8], les auteurs ont fait l'étude étendue du lecteur ALR-9800 (lecteur physique) avec deux antennes.
Ils ont étudié des comportements d'étiquette utilisant 6 étiquettes RFID passives avec la puissance de
lecteur réglée à son niveau maximal (31.5 dB). Leur étude prouve que des étiquettes sont souvent
manquées par le lecteur. Ce comportement démontre le manque de fiabilité inhérent de ces lecteurs. Le
lecteur fournit un ensemble riche d'API pour accéder à une série de paramètres de lecteur et d'étiquette.
Des méthodes heuristiques de lecteur telles que setDiscoveryListener () et startService () sont employées
pour la découverte de composantes de réseau dans le même sous-réseau. Pour un système large qui se
compose de milliers de lecteurs, cette découverte automatique est très efficace. Diverses méthodes de
lecteur sont employées pour obtenir et placer différents paramètres de lecteur et information observée
d'étiquette telle que getReaderType (), getAcquireMode (), getTagList (), setRFAttenuation () et setRFLevel
().
Les auteurs ont traité des problèmes comme :
• La localisation des articles disparus ou un article mal placé.
• Informations sur un lecteur défaillant (par exemple, un lecteur qui manque uniformément des
étiquettes).
Dans notre approche, nous avons utilisé la méthode getTagList() pour pouvoir dialoguer avec le lecteur
Alien 9800. Nous utiliserons la version RifidiEmulator-1.6 sous le système d’exploitation Microsoft
Windows XP et la machine Java : Sun Java Runtime Environment 1.6. C’est un émulateur écrit
complètement en Java [41].
La figure FIG.IV.5 montre comment créer un lecteur Alien 9800 virtuel sur l’adresse IP 127.0.0.1 et
l’adresse su port 10000 avec l’émulateur de RIFIDI.
FIG IV.5 - Appel Alien 9800
71
Chapitre IV
IMPLÉMENTATION
Pour voir les résultats des mouvements des étiquettes on peut utiliser l’outil Telnet [47] pour exécuter
une commande sur le lecteur. Pour telneter dans le lecteur, il faut simplement se connecter à l’adresse du
lecteur. Une fois connecté, les commandes suivantes sont utiles :
get TagList – Affiche les étiquettes détectées par le lecteur.
q – Ferme la connection
FIG IV.6 – Résultats des requêtes sur Rifidi.
Nous pouvons facilement remarquer l’affichage des résultats de commandes exécutées sur Java sur le
console de l’émulateur Rifidi (en vert dans la figure IV.6).
Après avoir étudié l’émulateur de RIFIDI et après avoir testé les lecteurs Alien 9800 simulés, nous avons
constaté que l’occurrence des fautes est improbable. Ainsi, l’intégration des capteurs dans les étiquettes
lues par ces lecteurs est inévidente. Alors, nous avons créé nos propres composants matériels simulés
pour pouvoir insérer la faute et la détecter après. La sous-section suivante présente les classes de ces
composants.
b. Les classes de nos composants matériels simulés
Cette sous-section présente les différentes classes des composants matériels virtuels simulés. Elle montre
aussi comment nous avons intégré la faute dans les lecteurs et les capteurs.
1. Capteurs
Beaucoup de mesures physiques ont approximativement une distribution gaussienne [49]; ceci fournit
une manière de simuler de telles valeurs. Les fonctions gaussiennes sont très utilisées en physique.
Nous avons créé deux types de capteurs virtuels : capteurs de température et capteurs d’humidité.
Pour générer des valeurs pseudo-aléatoires de chaleur et d’humidité, nous utiliserons la distribution
gaussienne (normale). Une description de la loi normale est dans l’annexe.
72
Chapitre IV
IMPLÉMENTATION
La classe GenererChaleur génère des valeurs de chaleur aléatoirement suivant une loi gaussienne de
moyenne 37° et de variance égale à 1.
Cette classe permet de générer des valeurs de température qui suivent une loi gaussienne de moyenne
37° et de variance égale à 1.
Pour simuler le comportement d’un capteur complètement défectueux nous utiliserons la classe Random
pour générer un flux de nombres pseudo-aléatoires.
La fonction genererHumidite génère un nombre aléatoire (mesure d’humidité) entre 0 et 100.
int genererHumidite() {
Random rnd = new Random();
int nbr = (int)rnd.nextInt(100);
return nbr;
}
La fonction h_10_60 génère un nombre entier aléatoire entre 10 et 60.
La méthode random() retourne naturellement un nombre aléatoire entre 0.0 and 1.0. Le résultat est
multiplié par 50. Quand 10 est ajouté à la valeur, l’intervalle deviendra *10,60+.
int h_10_60() {
return (int) (Math.random() * 50 + 10);
}
La fonction h_40_90 génère un nombre réel aléatoire entre 40 et 90.
double h_40_90() {
double randNumber = Math.random() * 50 + 40;
return randNumber;
}
b. Étiquettes
L’identifiant de l’étiquette est une suite de 24 caractères hexadécimaux. La norme EPC exige que
l’identifiant de l’étiquette doit être unique. Pour cela nous allons générer à la création de l’étiquette une
suite aléatoire de 24 nombres hexadécimaux et nous vérifions si cet identifiant existe dans l’entrepôt
EPCIS (dans la table des étiquettes) ; Nous refaisons le même processus tant que cet identifiant existe
dans l’entrepôt. L’identifiant généré pour l’étiquette créée persiste pendant tous le processus de
simulation, l’identifiant sera supprimé de la table à la fin de la simulation. La fonction Generer_id()
permet de générer aléatoirement un identifiant composé de 24 caractères hexadécimaux et de vérifier
s’il existe dans l’entrepôt. Sinon, il sera l’identifiant de l’étiquette créée.
73
Chapitre IV
IMPLÉMENTATION
Les pocédures Doter_capteur_temperature (Capteur_T CT) et Doter_capteur_humidite (Capteur_H CH)
permettent de doter l’étiquette créée soit d’un capteur de température soit d’un capteur d’humidité.
c. Stations
Une station est identifiée par son adresse IP.
Notre réseau est un réseau local dont la base de données se trouve sur le serveur. Chaque station doit
ensuite se voir affecter une adresse IP. L'attribution des adresses IP se fera automatiquement par notre
middleware, ce qui est préférable pour notre réseau local.
d. Lecteurs
On suppose qu'un lecteur a certaines capacités de traitement et de stockage (par exemple, un lecteur doit
pouvoir stocker un certain nombre d'identifiants dans une cache, produisent des nombres pseudoaléatoires, etc.).
Un lecteur est identifié par l’adresse IP (la station à laquelle il appartient) et son port. Un port est
distingué par son numéro. Grâce à cette abstraction, on peut attribuer plusieurs lecteurs à une même
machine.
Une étiquette est considérée lue si le lecteur arrive à lire son identifiant.
Pour simuler le comportement des lecteurs défectueux, nous allons prendre pour chaque lecteur un
nombre aléatoire entre 0 et le nombre total des étiquettes (Ne). Le lecteur ignorera Ne étiquettes. Une
étiquette ignorée signifie que le lecteur n’a pas pu lire son identifiant. Si cette étiquette contient un
capteur, le résultat de ce capteur est ignoré aussi, la valeur de captage de ce capteur dans la matrice des
valeurs sera -1.
La FIG.IV.7 représente le diagramme de classes des composants matériels virtuels (composants matériels
de l’interface C de l’architecture globale (voir la FIG.IV.4). Le principe EPC est préservé : pendant la durée
d’une simulation, un identifiant unique est attribué à chaque étiquette. Une station est identifiée par son
adresse IP. Un lecteur hérite l’adresse IP de la station à laquelle il appartient, et il a son numéro de port
propre. Une station ne peut pas gérer plus de 6 lecteurs [32]. Une étiquette peut être lue par plusieurs
lecteurs. Elle peut être une étiquette simple ou contenir soit un capteur d’humidité soit un capteur de
température.
74
Chapitre IV
IMPLÉMENTATION
FIG IV.7 – Modèle UML (Diagramme de classes) des composants matériels (les composants de l’interface
C)
Nous avons montré dans cette section comment insérer la faute en créant des lecteurs et des capteurs
qui peuvent être défectueux. La section suivante montre comment détecter cette faute.
IV.4. PROCÉDURES DE DÉTECTION DE LA FAUTE
Nous donnons ici deux algorithmes pour détecter la faute au niveau des lecteurs et des capteurs. Pour la
manipulation des lecteurs et des capteurs défectueux, nous proposons l’utilisation d’une structure de
75
Chapitre IV
IMPLÉMENTATION
données dynamiques : les listes linéaires chaînées. Une liste chaînée est une liste dont chaque élément
est relié au suivant par une référence à ce dernier [50].
a. Au niveau du lecteur
La procédure Analyse_Vecteur (I) permet de fournir la liste des lecteurs défectueux en analysant le
vecteur d’inventaire I.
Analyse_Vecteur( Vecteur I) // I : Vecteur d’inventaire
int n = la taille du vecteur d’inventaire
float tmp=0;
Créer_List (LecteursDefectueux); // Créer liste des lecteurs défectueux
float bi = I.getBorne_Inf_95(); // La borne inférieure de l’intervalle de confiance IC95%
float bs = I.getBorne_Sup_95(); // La borne supérieure de l’intervalle de confiance IC95%
Pour i allant de 0 à n-1 faire
int cpt= 0 ;
tmp = this.getValue(i); // Récupérer la ième valeur du vecteur d’inventaire.
Si (tmp<> -1)
Si ((tmp <bi) OU (tmp>bs))
int num=i+1; // Récupérer l’indice du lecteur
LecteursDefectueux.add (new Integer(num)); // Insérer ce lecteur dans la liste des
// lecteurs défectueux
FSI
FSI
FPOUR
Fin
76
Chapitre IV
IMPLÉMENTATION
b. Au niveau des capteurs
La procédure Analyse_Matrice (M) permet de fournir la liste des capteurs défectueux en analysant la
matrice des résultats de captage pour chaque type de capteur.
Analyse_Matrice( Matrice M)
int n = nombre de lignes de la matrice M.
int m = nombre de colonnes de la matrice M.
float tmp=0
Créer_List (CapteursDefectueux); // Créer la liste des capteurs défectueux
Vecteur v = new Vecteur(new float[n*m] ); // Créer un vecteur qui contient toutes les valeurs
V = Matrice_Vecteur(M);
float bi = v.getBorne_Inf_95();
// La borne inférieure de l’intervalle de confiance IC95%
float bs = v.getBorne_Sup_95();
// La borne supérieure de l’intervalle de confiance IC95%
Pour i allant de 0 jusqu’à n-1
int cpt1=0; // Pour calculer le nombre total des valeurs prises par ce capteur
int cpt2=0; // Pour calculer le nombre des valeurs qui n’appartiennent pas à IC95%
Pour j allant de 0 à m-1
tmp = M.getValue(i,j);
Si tmp <> -1)
cpt1++;
Si ((tmp<bi)OU (tmp>bs)) cpt2++;
FSi
FPour
77
Chapitre IV
IMPLÉMENTATION
Si cpt1<> 0
float r = cpt2/cpt1; // Le rapport de décision
int num=i+1;
if(r>=0.8) CapteursDefectueux.add(new Integer(num)); //Insérer le lecteur dans
// la liste des lecteurs défectueux
FSi
FPour
FIN
Nous avons montré comment détecter l’erreur en analysant les résultats d’inventaires pour découvrir les
lecteurs défectueux ; puis en analysant les résultats de captage pour chaque type de capteur pour
détecter les capteurs défectueux.
La section suivante fournit un exemple de simulation.
IV.5. EXEMPLE DE SIMULATION
La figure FIG.IV.8 illustre notre exemple. Nous avons les données suivantes :
-
Lecteurs : 7 lecteurs.
Étiquettes : 16 étiquettes.
Capteurs de température : 5 capteurs.
Capteurs d’humidité : 5 capteurs.
Le middleware répartit les 7 lecteurs entre 3 stations. Une station ne peut gérer plus de trois lecteurs. Le
middleware se charge aussi de doter les étiquettes des capteurs de température et d’humidité. Le
middleware s’occupe de l’analyse des données provenant des lecteurs et des capteurs.
78
Chapitre IV
IMPLÉMENTATION
FIG IV.8 – Exemple de simulation : redondance matérielle passive : 3 stations, 7 lecteurs, 16 étiquettes, 5
capteurs de température, 5 capteurs d’humidité et un voteur logiciel au niveau du middleware.
L’utilisateur peut démarrer le processus d’analyse. Nous avons pris un scénario complet de simulation. Le
voici :
79
Chapitre IV
IMPLÉMENTATION
Analyse du vecteur d'inventaire.
Nombre de lecteurs RFID = 7.
Vecteur d'inventaires
Lecteur
Lecteur 1 Lecteur 2 Lecteur 3 Lecteur 4 Lecteur 5 Lecteur 6 Lecteur 7
Résultat de l'inventaire 11.0
12.0
12.0
12.0
12.0
8.0
9.0
Graphe de Lecteurs
11.0
Lecteur 1
12.0
Lecteur 2
12.0
Lecteur 3
12.0
Lecteur 4
12.0
Lecteur 5
Lecteur 6
Lecteur 7
8.0
9.0
Moyenne = 10.857142.
Écart-type = 1.4638501.
IC95% Inventaire = [9.750576, 11.963709].
Les lecteurs défectueux sont : 6 , 7 .
Analyse de la matrice de température .
80
Chapitre IV
IMPLÉMENTATION
Matrice de température
Lecteur 1
Lecteur 2
Lecteur 3 Lecteur 4
Capteur 1 39.06037 30.051342 38.9284
Lecteur 5
Lecteur 6 Lecteur 7
30.868414 36.907112 38.46346 37.892094
Capteur 2 31.605927 39.365856 34.910633 32.643265 36.776558 34.73215 30.297815
Capteur 3 31.655745 34.93185 33.78401 30.017336 36.961334 35.321053 36.61625
Capteur 4 32.846947 37.38188 30.74904 30.23114 33.66501 37.276554 34.40921
Capteur 5 37.189896 36.456158 31.464838 34.894764 31.643309 39.00679 38.77344
Moyenne = 34.793713.
Écart-type = 2.951997.
IC95% Température = [33.795757,35.791668].
Les capteurs de température défectueux (IC 95%) sont : 1 , 5 .
Analyse de la matrice d'humidité.
Matrice d'humidité
Lecteur 1 Lecteur 2
Lecteur 3 Lecteur 4 Lecteur 5
Lecteur 6 Lecteur 7
Capteur 1 62.70757 68.856995 68.70732 67.97541 67.174866 61.336742 67.796036
Capteur 2 60.621746 66.62491 61.69436 68.0272 69.640915 67.47167 69.12723
Capteur 3 63.36364 64.19733 64.68458 67.04847 64.74811 61.007427 60.546444
Capteur 4 66.99305 69.591286 63.320095 67.27995 60.366196 /
67.24726
Capteur 5 64.29932 65.978806 65.15898 64.27834 65.57049 /
/
Moyenne = 65.42008.
Écart-type = 2.738613.
IC95% Température = [64.451836,66.38833].
Les capteurs d'humidité défectueux (IC 95%) sont : 1 , 2 .
Analyse Finale
1. Inventaire final : le nombre d'étiquettes : 12.
2.Température
Matrice de température
Capteur 1 /
/
/
/
/
/
/
Capteur 2 31.61
39.37
34.91
32.64
36.78
/
/
Capteur 3 31.66
34.93
33.78
30.2
36.96
/
/
Capteur 4 32.85
37.38
30.75
30.23
33.67
/
/
Capteur 5 /
/
/
/
/
/
/
81
Chapitre IV
IMPLÉMENTATION
Observation finale de température = 33.835102.
3. Humidité
Matrice d'humidité
Capteur 1 /
/
/
/
/
/
/
Capteur 2 /
/
/
/
/
/
/
Capteur 3 63.36
64.20
64.68
67.5
64.75
/
/
Capteur 4 66.99
69.59
63.32
67.28
60.37
/
/
Capteur 5 64.30
65.98
65.16
64.28
65.57
/
/
Observation finale d'humidité = 65.125244.
4. Résultat final sur l'événement
Événement (Produits alimentaires altérés).
Analyse de l’exemple de simulation
Le middleware analyse d’abord le vecteur d’inventaires, il constate que le lecteurs n° 6 et 7 manquent
beaucoup d’étiquettes, il les considère défectueux. Ensuite, il analyse la matrice de température puis la
matrice d’humidité. Les capteurs de température n° 1 et 5 donnent beaucoup de résultats hors l’intervalle
de confiance : ils sont défectueux. Les capteurs d’humidité n° 1 et 2 donnent aussi beaucoup de résultats
hors l’intervalle de confiance : ils sont défectueux. Pour la prise des décisions finales, le middleware
réanalyse le vecteur d’inventaires et les matrices de température et d’humidité en excluant les valeurs
prises par les lecteurs n° 6 et 7, par les capteurs de température n° 1 et 5 et par les capteurs d’humidité n°
1 et 2 . Dans le scénario pris, le middleware décide :




Nombre d’étiquettes : 12 étiquettes.
Observation finale de température = 33.84°.
Observation finale d’humidité= 65.13%.
Événement : Produits alimentaires altérés.
Nous remarquons que certains lecteurs manquent d’étiquettes et certains capteurs donnent des résultats
hors l’intervalle de confiance mais leurs résultats ne sont pas exclus lors de l’analyse : le middleware
tolère aux fautes.
IV.6. CONCLUSION
Nous avons développé un mini- middleware RFID expérimental distribué basé sur les services web SOA
pour le test et l’évaluation des méthodes d’analyse des données d’un système RFID en vue de sa sûreté
de fonctionnement. Les services web agissent au niveau des échanges entre le middleware et
l’application, entre le middleware et le matériel ainsi qu’entre les modules du middleware lui-même. Ce
travail est une preuve de la mise au point des concepts de sûreté de fonctionnement d’un système RFID à
base de SOA.
82
CONCLUSION GÉNÉRALE
L’effort fourni dans ce travail a ouvert un chemin vers la contribution dans le
développement de solutions distribuées pour le problème de tolérance aux fautes dans les systèmes
RFID. La technologie RFID est devenue de plus en plus utilisée dans les divers domaines de la vie. La
sûreté de fonctionnement de ces systèmes est donc indispensable pour permettre la livraison de
services corrects aux utilisateurs du système. Dans ce contexte, cette thèse avait pour objectif global
de contribuer à la tolérance aux fautes dans les systèmes RFID en concevant un système de décision
RFID distribué qui détecte et localise les défaillances en comparant les résultats des inventaires des
différents lecteurs, d’une part et d’autre part, comparer les résultats des différents capteurs
homogènes en utilisant des techniques statistiques sur les résultats obtenus et permettre à
l’application de détecter l’élément défectueux, corriger les fautes et continuer son exécution en
présence de ces entraves.
Un système RFID se compose de matériel, à l’exemple des lecteurs RFID, et du logiciel. À ce niveau là
apparaît le middleware RFID qui constitue le cerveau de la chaîne logicielle qui confère de
l'intelligence aux données récupérées sur les produits étiquetés d'une puce radiofréquence. Nous
avons expliqué le concept de l'intergiciel RFID et nous avons montré le rôle crucial qu'il joue en
expliquant ses fonctions principales (confidentialité des données, lecture et écriture d’une étiquette,
intégration du lecteur dans le système d’administration de l’environnement IT, filtrage et
agrégation…).
83
Ensuite, nous avons montré les différents éléments de l’infrastructure du middleware RFID qui est
organisée selon une architecture multi-niveaux (Interface lecteur RFID, médiation RFID, système
d’information RFID partagé…). Nous avons donné des exemples de middlewares RFID (WinRFID,
AspireRFID, Fosstrak ) suivie par une synthèse sur les middlewares RFID.
Après avoir décrit les différents éléments de l’infrastructure RFID et principalement l’intergiciel RFID
nous avons fait une brève présentation des concepts de base de la sûreté de fonctionnement
et de quelques techniques de sûreté de fonctionnement et de tolérance aux fautes.
Nous avons discuté la tolérance aux fautes à deux niveaux d'abstraction (le matériel et l'intergiciel).
Puisqu'il est difficile de fournir la tolérance de fautes d'une manière économique au niveau lecteurétiquette, notre approche pour la tolérance aux fautes apparaît au niveau d'intergiciel. Le principe ici
consiste à intégrer les mécanismes de tolérance aux fautes dans l’intergiciel.
La plupart des travaux sur la tolérance aux fautes ont été faits et évalués dans les réseaux des
capteurs. Peu de travaux ont étudié la tolérance aux fautes dans les systèmes RFID, la plupart des
solutions dans ces systèmes traitent le manque de fiabilité inhérent dans les technologies de RFID.
Nous nous sommes inspirés de deux travaux sur les réseaux de capteurs. Le premier est le travail de
Farinaz Koushanfar, Miodrag Potkonjak et Alberto Sangiovanni-Vincentelli qui présente une
technique basée sur la validation pour la détection en ligne des fautes des capteurs. Le deuxième
travail est celui de de Xuanwen, Luo, Ming, D., et Yinlun Huang dans lequel les auteurs traitent la
tolérance aux fautes distribuée dans les réseaux de capteurs.
Pour réaliser la tolérance aux fautes de manière extensible et distribuée, nous avons proposé
l’utilisation des méthodes d’analyse statistiques (les percentiles et l’intervalle de confiance) et nous
avons proposé un schéma de détection distribué dans lequel nous avons utilisé la technique de
redondance logicielle avec utilisation d’un middleware qui analyse les données provenant des
stations. Le middleware reçoit les données provenant des différents lecteurs et capteurs RFID.
Nous avons constaté durant notre étude que les middlewares existants ne répondent pas à nos
besoins (les lecteurs virtuels ne se comportent pas comme les lecteurs, l’implémentation de ce
middleware ne couvre pas les capteurs qui sont des composants matériels très importants pour notre
étude et les services web ne sont pas suffisamment abordés dans ce middleware).
Alors nous avons développé un mini-middleware expérimental pour montrer le but de notre
approche et qui peut :
-
Communiquer avec les lecteurs.
Filtrer et agréger les données provenant des lecteurs et des capteurs.
Enregistrer les événements de lecture et de captage dans un entrepôt.
Parallèlement, les logiciels actuels deviennent de plus en plus distribués et opèrent dans des
environnements hautement dynamiques. Pour cette raison, nous avons utilisé l’architecture SOA
(Service Oriented Architecture) pour rendre l’application ainsi que notre mini-middleware
complètement distribués.
84
Notre middleware est construit sous une architecture multi-tiers (Module de communication avec le
Matériel (MCM), Module de Filtrage et de Collection (MFC) et le Module de gestion de l’entrepôt
(MGE)). Les échanges d’information entre les différentes couches du middleware sont basés sur les
services web sous l’architecture SOA (Service Oriented Architecture).
Perspectives
Les perspectives à ce travail sont :

Compléter le middleware et le rendre totalement distribué en ajoutant plus de services dans
le mini-middleware.

L’utilisation d’autres techniques statistiques : Utiliser d’autres techniques statistiques autres
que les percentiles et l’intervalle de confiance pour l’analyse de données provenant des
différents lecteurs et capteurs RFID.

La tolérance aux fautes aux différents niveaux : Actuellement, notre middleware traite la
tolérance aux fautes au niveau matériel : lecteurs et capteurs RFID. Nous comptons que nos
futurs travaux de tolérance aux fautes des systèmes RFID opèrent au niveau application et au
niveau intermédiaire.
85
ANNEXE
Annexe
1. Notions de statistiques
1.1. Écart-type [38]
1.1.1. Définitions
La variance et l'écart-type sont deux mesures de dispersion des observations d'une variable
quantitative. On les calcule de manière systématique pour chacune des variables utilisées.
Ces mesures, liées à la moyenne, donnent une bonne représentation de la réalité, surtout si
la variable respecte la distribution normale. En eux-mêmes, ces indicateurs n'évoquent rien
de précis, cependant ils permettent de comparer mathématiquement la dispersion des
variables.
1.1.2. Formule mathématique
La variance (σ2) est la moyenne des carrés des déviations de la moyenne arithmétique.
L'écart-type (σ) est la racine carrée de la variance. Il est donc facile de trouver la variance à
partir de l'écart-type et vice versa [38].
La formule mathématique de la variance s'écrit comme suit :
où
σ2 , variance,
σ, écart type;
Xi, observation «i» de la variable X;
μ, moyenne de la variable X;
n, nombre d'observations;
1.1.3. L'interprétation de l'écart-type
Plus l'écart-type est élevé, plus grande est la dispersion des observations d'une variable. En
effet, l'écart-type doit englober les 68% des observations autour de la moyenne.
ANNEXE
L'écart-type est surtout utile pour comparer la dispersion d'une variable dans une même
population (P) à des temps différents ou auprès de deux populations comparables.
Comme toutes les observations d'une variable servent au calcul de l'écart-type, sa valeur
représente bien la dispersion de la variable.
FIG.1 – Distribution selon la loi normale
1.2. Loi normale [51]
En probabilité, on dit qu'une variable aléatoire réelle X suit une loi normale (ou loi normale
gaussienne, loi de Laplace-Gauss) d'espérance μ et d'écart type σ strictement positif (donc
de variance σ2) si cette variable aléatoire réelle X admet pour densité de probabilité la
fonction p(x) définie, pour tout nombre réel x, par :
Une telle variable aléatoire est alors dite variable gaussienne.
On note habituellement cela de la manière suivante :
FIG.2 - Représentation graphique d'une loi normale centrée réduite (dite courbe de Gauss ou
courbe en cloche).
ANNEXE
1.3. Loi de Student [51]
La loi de Student est une loi de probabilité, faisant intervenir le quotient entre une variable
suivant une loi normale centrée réduite et la racine carrée d'une variable distribuée suivant
la loi du χ².
Soit Z une variable aléatoire de loi normale centrée et réduite et soit U une variable
indépendante de Z et distribuée suivant la loi du χ² à k degrés de liberté. Par définition la
variable
suit une loi de Student à k degrés de liberté.
La densité de
notée
est donnée par :
pour k ≥ 1.
où Γ est la fonction Gamma d'Euler.
La densité
associée à la variable est symétrique, centrée sur 0, en forme de cloche.
Son espérance ne peut pas être définie pour k = 1, et est nulle pour k > 1.
Sa variance est infinie pour k ≤ 2 et vaut
pour k > 2.
FIG.3 - Loi de Student
ANNEXE
FIG.4 - Fonction de répartition
2. Le protocole Telnet [47]
2.1. Introduction au protocole Telnet
Le protocole Telnet est un protocole standard d'Internet permettant l'interfaçage de
terminaux et d'applications à travers Internet. Ce protocole fournit les règles de base pour
permettre de relier un client (système composé d'un affichage et d'un clavier) à un
interpréteur de commande (côté serveur).
Le protocole Telnet s'appuie sur une connexion TCP pour envoyer des données au format
ASCII codées sur 8 bits entre lesquelles s'intercalent des séquences de contrôle Telnet. Il
fournit ainsi un système orienté communication, bi-directionnel (half-duplex), codé sur 8 bits
facile à mettre en œuvre.
Le protocole Telnet repose sur trois concepts fondamentaux :



Le paradigme du terminal réseau virtuel (NVT, Network Virtual Terminal) ;
Le principe d'options négociées ;
Les règles de négociation.
2.2. Exécution de Telnet
Telnet est fourni en standard sous diverses plateformes, dont UNIX, Windows95,
WindowsNT, Linux...
La commande pour initier une session Telnet est généralement la suivante :
telnet nom_du_serveur
nom_du_serveur représente bien évidemment le nom de la machine distante à laquelle on
désire se connecter. Il est aussi possible de donner son adresse IP, par exemple :
telnet 125.64.124.77
Enfin il est également possible de préciser le port à utiliser en faisant suivre l'adresse IP ou le
nom du serveur par le numéro de port :
ANNEXE
telnet 125.64.124.77 80
2.3 Commandes sous Telnet
Une fois que vous vous connectez à la machine distante, un nom d'utilisateur (login) et un
mot de passe (password) vous seront demandés pour des raisons de sécurité afin de
restreindre l'accès aux seules personnes autorisées. En effet, Telnet est un protocole
puissant puisqu'il permet l'exécution de commandes à distance. Les commandes pouvant
être exécutées sous une session Telnet sont définies par l'administrateur réseau. Il s'agit
généralement de commandes UNIX étant donné que la plupart des serveurs Telnet
fonctionnent sous UNIX. Les commandes standard sont les suivantes :
Commande Description
?
Affiche l'aide
close
Termine la session Telnet
display
Affiche à l'écran les paramètres de la connexion (type de terminal, port)
environ
Permet de définir les variables d'environnement du système d'exploitation
logout
Permet de se déconnecter
mode
Bascule entre les modes de transfert ASCII (transfert d'un fichier en mode texte)
et BINARY (transfert d'un fichier en binaire)
open
Permet de lancer une autre connexion à partir de la connexion en cours
quit
Quitte l'application Telnet
set
Modifie les paramètres de la connexion
unset
Charge les paramètres de connexion par défaut
3. Classes Java qui permet de créer un lecteur virtuel Alien 9800
Voici la classe Java qui permet de créer un lecteur virtuel sur l’adresse IP 127.0.0.1 et le port
20000 sous Rifidi et d’avoir la liste des étiquettes d’un lecteur RFID déjà créé sur la même
adresse IP et le même port [48].
import java.io.BufferedReader;
import java.io.IOException;
import java.io.InputStreamReader;
import java.io.PrintWriter;
import java.net.Socket;
ANNEXE
public class AlienExampleClient {
public static final String IP_ADDRESS = new String("127.0.0.1");
public static final int READER_PORT = 20000;
private static Socket connection = null;
private static PrintWriter out = null;
private static BufferedReader in = null;
private void init() throws IOException, InterruptedException{
connection = new Socket("127.0.0.1", READER_PORT);
in = new BufferedReader(new InputStreamReader(connection
.getInputStream()));
out = new PrintWriter(connection.getOutputStream());
Thread.sleep(500);
System.out.println(readFromReader(in));
out.write("alien\n");
out.flush();
Thread.sleep(500);
out.write("password\n");
out.flush();
}
private void tearDown() throws IOException{
out.write("q");
out.flush();
connection.close();
}
private String getTags() throws IOException{
String command = "t";
out.write(command + "\n");
out.flush();
String returnVal = readFromReader(in);
return returnVal;
}
public static void main(String[] args) throws IOException, InterruptedException {
AlienExampleClient client = new AlienExampleClient();
client.init();
Thread.sleep(500);
String tags = client.getTags();
System.out.println(tags);
Thread.sleep(500);
client.tearDown();
}
ANNEXE
public static String readFromReader(BufferedReader inBuf) throws IOException{
StringBuffer buf=new StringBuffer();
int ch=inBuf.read();
while((char)ch!='\0'){
buf.append((char)ch);
ch=inBuf.read();
}
return buf.toString();
}
}
Bibliographie
[1] Klaus Finkenzeller. RFID Handbook : Fundamentals and Applications in Contactless Smart Cards
and Identification. Deuxième Édition, John Wiley & Sons, Ltd., England. ISBN 0-470-84402-7.
2003.
[2] Pattabhiraman Krishna et David Husak. RFID INFRASTRUCTURE. IEEE Communications Magazine.
Volume: 45, Issue: 9, Pages: 4-10. Septembre 2007.
[3] Yves Saint-Oyant et Jonathan Brisart. La norme RFID. Thèse de Master IAGL. Université de
sciences et technologies. Lille1. 2010.
[4] Laprie, J. C, et al. Guide de la sûreté de fonctionnement. 2ème édition, Cépaduès Éditions. ISBN
2-85428-382-1. 1996.
[5]
a. Thi-Quynh Bui, Oum-El-Kheir Aktouf, Michel Dang, Levent Gürgen et Claudia
Roncancio. Diagnosis Service for Software Component and Its Application to a
Heterogeneous Sensor Data Management System. depend, pp.143-149. Second
International Conference on Dependability. 2009.
b. Thi Quynh BUI. SERVICE DE DIAGNOSTIC EN LIGNE POUR LES APPLICATIONS A BASE
DE COMPOSANTS LOGICIELS. THESE pour obtenir le grade de DOCTEUR DE
GRENOBLE INP - Préparée au Laboratoire de Conception et d'Intégration des
Systèmes (LCIS) dans le cadre de l'Ecole Doctorale "Mathématiques, Sciences et
Technologies de l'Information, Informatiques (MSTII)" . 14 Octobre 2009.
[6] F. Koushanfar , M. Potkonjak et A. Sangiovanni-Vincentelli. Fault-Tolerance in Sensor Networks.
Book chapter, in: « Handbook of Sensor Networks », I. Mahgoub and M. Ilyas (eds.), CRC press,
Section VIII, no. 36. 2004.
[7] Xuanwen Luo, Ming Dong et Yinlun Huang. On Distributed Fault-Tolerant Detection in Wireless
Sensor Networks. IEEE Transactions on Computers, vol. 55, no. 1, pp. 58-70. Jan. 2006.
[8] Nova Ahmed, Rajnish Kumar, Robert Steven French et Umakishore Ramachandran. RF2ID: A
Reliable Middleware Framework for RFID Deployment. In the Proceedings of the 21st
International Parallel and Distributed Processing Symposium. IPDPS 2007. California.
[9] Imad Belkacem, Oum-El-Kheir Aktouf et Safia Nait Bahloul. Vers la tolérance aux fautes dans les
systèmes RFID. In Proceedings of the Second International Conference on Systems and
Information Processing, ICSIP’11. page 65. Guelma, Algeria. May 15-17, 2011.
[10] Imad Belkacem, Oum-El-Kheir Aktouf et Safia Nait Bahloul. Analyse des données d'un système
RFID en vue de sa sûreté de fonctionnement. In Proceedings of the 1st International Conference
on Information Systems and Technologies, ICIST’11. Tébessa, Algeria. 2011.
[11] I. Belkacem, I. Kara Mostapha. Simulation à base de services web. Mémoire de fin d’études pour
l’obtention du diplôme d’ingénieur d’état en informatique. Département d’Informatique,
Faculté des sciences, Université de Mostaganem. 2008.
[12] JEANNE-BEYLOT Bernard. ABC de l’identification par étiquettes radiofréquence. Décembre 2003.
[13] Antti Ruhanen , Marko Hanhikorpi , Fabrizio Bertuccelli , Annamaria Colonna , Westy Malik ,
Damith Ranasinghe , Tomas Sánchez López , Na Yan et Matti Tavilampi . Sensor-enabled RFID tag
handbook . Building Radio frequency IDentification for the Global Environment Project. 2008.
[14] H. Norton. Transducer fundamentals. In Handbook of Transducers. Englewood Cliffs, NJ: Prentice
Hall, ch. 2. 1989.
[15] Xavier BARRAS. RFID, Normes et Standards. Conférence. Salon de Traçabilité. CNIT. 2006.
[16] John Footen et Joey Faust. The Service-Oriented Media Enterprise: SOA, BPM, and Web Services
in Professional Media Systems, Focal Press. Chapitre 4 definition of a middleware. ISBN :
9780240809779. 2008.
[17] AIRIAU Roland (France Télécom R&D), BALTER Roland (ScalAgent / ObjectWeb), DONSEZ Didier
(Univ. Joseph Fourier, Grenoble), GENON-CATALOT Denis (Université Pierre Mendés France,
Valence), LEGENDRE Jean-François (AFNOR), LETELLIER François (INRIA / ObjectWeb), MENGA
David (EDF), ROJEY Laurent (Minéfi / DGE) , SARRAILLON Joël Pôle (Traçabilité), TATOUT Frédéric
(Minéfi / DGE) et THONNET Michèle (Ministère de la Santé). Étiquettes électroniques (RFID) Infrastructures logicielles et middleware. Rapport d’une étude RFID de la .Direction Générale des
Entreprises (Minéfi).2006.
[18] Michel Rousseau. Ce qu'attendent les applications d'un middleware RFID. Solutions et
applications RFID. 2006.
[19] B.S. Prabhu, Xiaoyong Su, Charlie Qiu, Harish Ramamurthy, Peter Chu et Rajit Gadh. WinRFID –
Middleware for Distributed RFID Infrastructure. Wireless Internet for the Mobile Enterprise
Consortium. University of California, Los Angeles. 2005.
[20] AspireRFID. Site officiel de AspireRFID. http://wiki.aspire.ow2.org.
[21] AspireRFID Architecture.
http://wiki.aspire.ow2.org/xwiki/bin/view/Main.Documentation/AspireRfidArchitecture.
[22] Fosstrak: Open Source RFID Software Platform .Site officiel de Fosstrak.
http://www.fosstrak.org/.
[23] John Soldatos et Didier Donsez. The AspireRfid Project: Is Open Source RFID Middleware still an
option? RFID World. 2009.
[24] Nikos Kefalakis, Nektarios Leontiadis, John Soldatos, and Didier Donsez. Middleware Building
Blocks for Architecting RFID Systems. 1st Mobilight Conference. May 2009.
[25] WinRFID. Site de WINMEC : http://winmec.ucla.edu/rfid/winrfid/.
[26] Jean Arlat, Yves Crouzet, Yves Deswarte, Jean-Charles Fabre, Jean-Claude Laprie et David Powell.
Tolérance aux fautes. Dans « Encyclopédie de l'informatique et des systèmes d'information », (J.
Akoka and I. Comyn-Wattiau, Eds.), Partie 1 : La dimension technologique des systèmes
d'information - Section 2 : L'architecture et les systèmes (M. Banâtre, Ed.), pp. 240-270. ISBN :
27117-4846-4,Vuibert. Paris, France. 2006.
[27]Mehdi JALLOULI. Méthodologie de conception d’architectures de processeur sûres de
fonctionnement pour les applications mécatroniques. THESE DE DOCTORAT présentée pour
obtenir le grade de docteur.Université Paul Verlaine – Metz. Discipline: Electronique, Spécialité:
Microélectronique. Juin 2009.
[28] J-C. Laprie. Sûreté de fonctionnement des systèmes : concepts de base et terminologie. Revue
de l’Électricité et de l’Électronique, No. 11, pp. 95-105. Déc 2004.
[29]Oum El Kheir Aktouf. Sûreté de fonctionnement des systèmes informatiques. Présentation de
cours. Université d’Oran. 2009.
[30]Lala, P. K. Self-Checking and Fault-Tolerant Digital Design. Morgan Kaufmann Publishers. USA.
2001.
[31] Agusti Solanas, Josep Domingo-Ferrer, Antoni Martínez-Ballesté et Vanesa Daza. A Distributed
Architecture for Scalable Private RFID Tag Identification. In Proceedings of Computer Networks,
Vol. 51, no. 0, pp. 2268-2279. ISSN: 1389-1286. Aug 2007.
[32] Julien David. Design d’un contrôleur de lecteurs RFID. Mémoire du projet de fin d’étude.
Université d’Ottawa. Juillet 2008.
[33] R. Zurawski. Embedded Systems Handbook. Editions CRC Press. 2005.
[34] Hyndman RH et Fan Y. Sample quantiles in statistical packages. The American Statistician 50 (4):
361-365. 1996.
[35] Zar, J.H. Biostatistical Analysis. Prentice Hall International, New Jersey. pp 43–45. 1984.
[36] G. COSTANTINI. Estimation ponctuelle- Estimation par intervalle de confiance. Cours de
statisiques.
www.sante.univ-nantes.fr/med/IntervalleDeConfiance.ppt.
[37]Rees. D.G. Essential Statistics. 4th Edition, Chapman and Hall/CRC. ISBN 1-58488-007-4. 2001.
[38]Walker, Helen. Studies in the History of the Statistical Method. Baltimore, MD: Williams & Wilkins
Co. pp. 24–25. 1931.
[39]M. Hadi Valipour, Bavar AmirZafari, Kh. Niki Maleki, Negin Daneshpour. A Brief Survey of
Software Architecture Concepts and Service Oriented Architecture . In Proceedings of 2nd IEEE
International Conference on Computer Science and Information Technology, ICCSIT'09, pp 34-38.
China. Aug 2009.
[40] Arsanjani A., Liang-Jie Zhang, Ellis M., Allam A. et Channabasavaiah K. S3: A Service-Oriented
Reference Architecture . IT Professional Volume 9, Issue 3, Pages:10–17. May-June 2007.
[41] Z. Chergui et K. Djelloul. Approche de simulation DEVS à base de services web. Mémoire de fin
d’études pour l’obtention du diplôme d’ingénieur d’état en informatique. Département
d’Informatique, Faculté des sciences, Université d’Oran. 2007.
[42]Christoph Schroth et Till Janner. Web 2.0 and SOA: Converging Concepts Enabling the Internet of
Services. IT Professional 9(3): 36-41 .2007.
[43] JDeveloper. Site officiel de Oracle JDeveloper.
http://www.oracle.com/technetwork/developer-tools/jdev/overview/index.html.
[44]M. Guedda, A. Yazid. Une approche J2EE pour piloter une simulation sur le web. Mémoire de fin
d’études pour l’obtention du diplôme d’ingénieur d’état en informatique, Département
d’Informatique, Faculté des sciences, Université d’Oran< ; 2002.
[45]Rifidi. Site officiel de Rifidi. http://wiki.rifidi.org/index.php.
[46] Emulator User's Guide. http://wiki.rifidi.org/index.php/Emulator_User%27s_Guide.
[47]Le protocole Telnet. Site officiel du protocole. http://www.telnet.org/
[48] Alien 9800. http://wiki.rifidi.org/index.php/Alien_9800.
[49]Honarkhah, M et Caers, J. Stochastic Simulation of Patterns Using Distance-Based Pattern
Modeling, Mathematical Geosciences, 42: 487 – 517. 2010.
[50] D.E Zegour. Structures de Données et de Fichiers : Programmation Pascal et C. Edition Chihab.
1996.
[51] Johnson, N.L., Kotz, S. et Balakrishnan, N. Continuous Univariate Distributions, Volume 2, 2nd
Edition. Wiley. ISBN 0-471-58494-0. 1995.

sûreté de fonctionnement des systèmes rfid

Transcription

Documents pareils

7. cleor - SupplyChainExpo

Halte aux implants électroniques ! La micro

bibliotheca hybrid gate™

Télécharger

RFID: Middleware et intégration avec le système d`information

Zebra® ZD500R™ Imprimante RFID UHF

L`optimisation des processus permet de réduire les frais de

Imprimante Zebra® P4T™/RP4T™

Histoires de rasoirs (2)