Intergiciel pour étiquettes électroniques

Une étiquette électronique est constituée d'une puce et d'une antenne. La puce contient un espace mémoire, permettant de stocker différentes informations (en fonction du type d'étiquette) dont un identifiant unique (un code produit électronique) qui permet d’identifier l'objet ou la personne sur lesquels est collée l'étiquette électronique. Il existe trois familles d'étiquettes électroniques :

• Les étiquettes passives : ne nécessitent pas de source d’énergie en dehors de celle fournie par les lecteurs au moment de leur interrogation.
• Les étiquettes semi-passives : équipées d'une batterie, mais n'émettent pas de signal (réponse à une requête comme les étiquettes passives).
• Les étiquettes actives : équipées d'une batterie, capables d'émettre un signal et être lues sur de longues distances.

Le choix de ce l'étiquette se fait en fonction des propriétés souhaitées, du coût, et de l'environnement; chaque puce ayant des caractéristiques physiques différentes[3].

Les codes-barres permettent d'identifier une famille de produits. Les étiquettes électroniques viennent rajouter un identifiant unique à cet identifiant de lot. Deux exemplaires d'un même produit ont le même code-barres, mais pas le même code produit électronique.

Il existe différents codes produits électroniques (EPC en anglais pour Electronic Product Code) associés au type d'objet associé à l'étiquette : SGTIN (de l'anglais Serialized Global Trade Item Number) pour un objet, SSCC (pour Serial Shipping Container Code) pour des conteneurs, SGLN (pour Serialized Global Location Number) pour une localisation.

Ces étiquettes sont appelées étiquettes RFID pour Radio Frequency IDentification, c'est-à-dire identification par radio fréquence.

L'Organisation internationale de normalisation (ISO) a produit plus d'une cinquantaine de normes pour les étiquettes électroniques. Le matériel d'une part, comme la norme ISO/CEI 18000, (nommée « information technologique »), qui définit l'architecture et les paramètres à standardiser. Elle est subdivisée en 6 sous-parties qui caractérisent chacune les spécifications en fonction des fréquences de fonctionnement des étiquettes. Et les usages d'autre part, comme les normes ISO 11784, 11785 et 14223 qui régissent l'identification d'animaux utilisant des étiquettes électroniques.

Les principales normes sont reprises dans les annexes.

Le consortium EPCGlobal est né de la coopération de l'Auto-ID labs du MIT et de GS1 (connu pour la création du format EAN). Il s'intéresse au développement et à l'établissement de standards pour les étiquettes électroniques, les codes produits électroniques et l'architecture EPCGlobal. Il a été créé dans le but de développer l'utilisation d'étiquettes électroniques au niveau mondial, et les intégrer dans un système global. Plusieurs axes ont été développés dans ce sens[4]

• Créer des étiquettes électroniques à bas coûts : les étiquettes apposées par un fabricant sur un produit ne lui sont pas retournées.
• Ces étiquettes doivent opérer en Ultra-Hautes Fréquence (UHF) pour avoir de bonnes propriétés physiques (permettant une distance de lecture par exemple)
• Rendre global le système RFID, afin de rendre possible l'utilisation des étiquettes apposées sur les produits à chaque intermédiaire (voir scénario).
• Créer une architecture en réseau, pour que tout un chacun puisse accéder aux informations associées à un numéro de série stocké sur une étiquette.

Ces deux derniers points mettent en avant le besoin d'interopérabilité (voir problèmes), et sont pour cela fondés sur des standards ouverts.

Le réseau EPC est une architecture d'interfaces standardisées et ouvertes, pensé pour supporter une meilleure visibilité de la localisation et des mouvements des objets dans les chaînes de production, avec une granularité jusqu'à l'identifiant unique EPC de chacun[5].

Contrairement à l'ISO, le consortium est composé d'acteurs industriels (Cisco Systems, Sony Corporation, DHL Solutions & Innovations entre autres), académiques (MIT), ou d'organisation à but non lucratif (GS1).

Le standard EPCglobal se compose:

• d'un système de codification séquentielle des produits, le code produit électronique (Electronic Product Code)
• d'un standard d'étiquette RFID, hiérarchisé en 4 classes[6]

  classe 1

  étiquettes epc simple lecture-seule

  classe 2

  fonctionnalités additionnelles :

  • lecture/écriture, sécurité des données
  • détection de vol

  classe 3

  classe 2 + batterie

  classe 4

  relais RFID autonome

• d'un réseau de partage d'informations, le réseau EPCglobal (en).

On trouve déjà de ces étiquettes pour reconnaître ou identifier à plus ou moins grande distance et dans un minimum de temps, un objet, un animal ou une personne porteuse d’une étiquette capable d’émettre des données en utilisant des ondes radio.

Citons parmi les applications actuelles : la carte d'accès sans contact, la carte d'étudiant[7], les passeports biométriques, certains forfaits dans certaines stations de sport d'hiver...

Le tableau ci-dessous met en valeur les principales différences entre les étiquettes électroniques et les codes-barres[8].

La capacité de lecture des étiquettes sans visée directe les amène dans le processus de traçabilité et de gestion de biens, ce qui soulève de nouveaux usages et de nouvelles problématiques, comme par exemple la mise à disposition des informations lues sur les étiquettes sur internet. C’est ce que l’on appelle l’internet des objets.

Une entreprise produit des biens dans une usine (U). Ces produits sont marqués d’une étiquette RFID et son acheminés chez un transporteur (T). Ce transporteur regroupe les produits par palette, et appose une étiquette électronique sur chaque palette. Enfin, ces produits sont livrés chez un distributeur (D) qui les stocke à l’arrière de la boutique. Chacun des intermédiaires U, T et D possède un système d’information qui lui est propre. L’usine possède donc les informations sur les familles de produits, le transporteur les associations palettes/produits, et le distributeur l’association entre un identifiant et une famille de produit. Il peut ainsi faire l’inventaire de ses stocks quasi-instantanément. Il faut donc rendre communes et accessibles aux 3 entités les données locales de chacune afin de rendre efficace le système d’information.

Voir le schéma[9]

Un des problèmes peut être l’hétérogénéité des lecteurs, qui rend dépendant le code de l’application métier au lecteur particulier. Ainsi, en cas de défaillance du lecteur (imposant un remplacement), il faut modifier l’application métier. Les lecteurs doivent donc être abstraits.

Ensuite, chaque application s’intéresse à différents types d’événements. Ainsi l’application métier du distributeur n’a nullement besoin de se voir remonter les informations des palettes du transporteur par exemple. Les informations doivent donc être filtrées.

Dans le cas de gros entrepôts, il peut y avoir plusieurs lecteurs RFID, ce qui soulève des problèmes physiques liés à la technologie RFID, et des problèmes liés à la multiplication de lecteurs :

• Les problèmes physiques sont essentiellement les brouillages entre lecteurs, et les brouillages entre tags[10].
• Un exemple de problème lié à la multiplication des lecteurs survient par exemple lorsqu’une application surveille un type de produit, et que plusieurs événements sont remontés de plusieurs lecteurs. Les données doivent donc être agrégées.

En outre, une application veut pouvoir avoir accès aux informations d’une étiquette, qu’elle soit présente ou non dans le champ d’un lecteur. Les informations doivent donc être stockées et localisée de façon à pouvoir être retrouvées facilement.

Enfin, un frein à l’échange d’informations entre les entités est le manque d’interopérabilité. Il est donc nécessaire d’utiliser des standards.

Un intergiciel est un logiciel intermédiaire entre les applications et le réseau qui autorise les dialogues entre des applications hétérogènes. Il permet d’accomplir des tâches techniques pour les applications telles que les connexions et les échanges de données[11].

Dans les cas d'un intergiciel pour étiquettes électronique, cet outil doit donc pouvoir gérer les problèmes cités ci-dessus, soit :

• Gestion des lecteurs et hétérogénéité des lecteurs
• Traitement des données des lecteurs (formatage, agrégation, filtrage)
• Collecte des données
• Gestion d'événements

L'idée est donc d'abstraire les lecteurs pour faciliter leur interrogation.

Le réseau EPC est une architecture d'interfaces standardisées et ouvertes, pensé pour supporter une meilleure visibilité de la localisation et des mouvements des objets dans les chaînes de production, avec une granularité jusqu'à l'identifiant unique EPC de chacun. Le réseau autorise une large distribution du contrôle et de la gestion des données.

Le réseau EPCGlobal fonctionne par couches:

• La couche d'identification
• La couche de capture des données
• La couche d'échange

Un schéma illustrant l'architecture globale est disponible sur le site d'EPCGlobal[12].

Cette couche regroupe deux standards de données[13]. Les paragraphes qui suivent sont issus des documents produits par EPCGlobal.

Extrait de la rubique TDS d'epcglobal[14]:
Le standard pour les étiquettes EPCGlobal définit le code produit électronique, et spécifie l'organisation en mémoire des étiquettes de seconde génération (GEN2 RFID tags). De façon plus précise:

• La spécification du code produit électronique, incluant sa représentation à différents niveaux de l'architecture EPCGlobal et sa correspondance aux autres codes existants (comme GS1).
• La spécification des données includes sur les étiquettes de seconde génération, incluant l'espace mémoire dédié à l'utilisateur, les informations de contrôle, et l'information fabricant de l'étiquette.

Extrait de la rubrique TDT d'epcglobal[15]:
Un code produit électronique peut-être exprimé dans plusieurs représentations, par exemple en binaire, en "tag-encoding URI", ou "pure-identity URI" etc ... Cette brique permet de faciliter la traduction (encodage / décodage) d'une représentation à l'autre d'un code produit électronique.

Exemple:

Le standard prévoit 4 briques logiques pour régir la capture de données.

Extrait de la rubrique LLRP d'epcglobal[16]:
Ce protocole définit une interface entre les lecteurs RFID et les clients. Il est appelé "low level" car il spécifie le contrôle des opérations d'accès au protocole air.

Extrait de la rubrique LLRP d'epcglobal[17]:
Ce standard est utilisé par les logiciels de gestion pour reporter le statut des opérations et l'état de lecteurs RFID compatibles avec la norme EPCGlobal.

Extrait de la rubrique DCI d'epcglobal[18]:
Ce standard permet de découvrir, configurer et initialiser des lecteurs RFID. Il a été créé par le même groupe que LLRP, et spécifie un nouveau périphérique appelé "Contrôleur d'Accès" qui effectue les fonctions de DCI. Il fournit des méthodes standardisées permettant:

• À un lecteur de découvrir un ou plusieurs contrôleur d'accès.
• À un contrôleur d'accès de découvrir un ou plusieurs lecteurs.
• À un lecteur de découvrir un ou des client(s).
• À un lecteur et un contrôleur d'accès d'échanger des informations d'identité et d'authentifier ces informations.
• À un client et un contrôleur d'accès d'authentifier leurs communications et leurs opérations.
• À un contrôleur d'accès:
  • De découvrir un ou plusieurs lecteurs.
  • De configurer le lecteur, ce qui inclut la mise à jour de logiciel/micrologiciel présent sur le lecteur.
  • D'initialiser le lecteur, en lui fournissant les paramètres nécessaires pour commencer des opérations.

Extrait de la rubrique ALE d'epcglobal[19]:
Le rôle de l'ALE au sein du réseau EPCGlobal est de fournir une indépendance entre les composants de l'infrastructure qui acquièrent l'information EPC "brute", les composants de l'architecture qui filtrent et comptent les données, et les applications qui utilisent ces données. Cela permet de changer un de ces composants sans avoir à changer les autres, facilitant le travail des fournisseurs de technologies et des utilisateurs finaux. C'est une des pièces maîtresse de l'intergiciel. Pour cela, l'ALE doit:

• Fournir au client un moyen de spécifier à haut niveau, et de façon déclarative, les données ou opération qui l'intéresse sans avoir à en écrire d'implémentation, laissant une grande latitude à la façon de choisir une stratégie pour satisfaire ces requêtes; ces stratégies pouvant-être influencées par des objectifs de performances, les capacités des lecteurs ou des éléments devant filtrer et compter les données au niveau firmware ou protocolaire.
• Fournir un format standard de reporting de données accumulées et filtrées, de façon indépendante de l'origine des données ou de la façon dont elles ont été collectées.
• Abstraire les canaux à travers lesquels les données lues transitent en utilisant la notion de "lecteur logique" (souvent associé à une localisation), cachant au client les détails exacts des périphériques physiques utilisés. Cela permet d'effectuer des modifications au niveau physique (par exemple remplacer un lecteur à 2 antennes par un lecteur doté de 3 antennes) sans affecter les applications clientes. De la même manière, cela abstrait la façon dont les données sont rassemblées (exemple combien de tentatives de lectures ont été nécessaires). Ces fonctionnalités sont une conséquence du design de l'interface de reporting.
• Abstraire la provenance des informations demandées, qu'elles soient stockées sur les étiquettes, ou dans une interface de plus haut niveau. Cela permet de maintenir une invariance dans la logique applicative malgré les différences qui peuvent exister entre l'organisation mémoire des différentes sources de données (par exemple entre les étiquettes de première ou seconde génération) et aussi de protéger la logique de l'application d'avoir à comprendre les mécanismes complexes entre les données et les façons de les parser.
• Fournir un mécanisme de sécurité permettant aux administrateurs de choisir quels opérations peuvent-être effectuées par quelles applications, comme une politique découplée de la logique applicative elle-même.

De façon plus synthétique : l'ALE sert à réduire le volume de donnée le plus tôt possible (filtrage), apporte le concept de lecteur logique, rend les données intelligibles par le système d'information, et reporte les productions de rapports et communication (accumulation, filtrage, comptage).

Cette couche vise à rendre disponibles les informations issues des étiquettes à un cadre plus large, comme internet.

Le service standard d'information d'EPC (EPCIS) définit une interface standard permettant aux entreprises d'échanger des informations granulaires à travers un protocol commun d'interrogation et de rapport. Il est découpé en 2 parties[5]:

• L'interface de capture EPCIS
  • Transforme un événement applicatif en événement EPCIS
  • Ajoute un contexte métier
  • Permet l'agrégation de données par critères (utilisateur, ou au niveau métier)
• Le repository EPCIS

L'EPCGlobal Object Naming Service (ONS) est fait pour fournir un mécanisme de recherche de sorte que tout le monde puisse trouver l'adresse des services (EPCIS par exemple) qui sont désignés par l'organisation qui a produit l'EPC d'un objet particulier[5].

Dans le scénario, chaque intermédiaire (Usine, Transporteur, Magasin) possède sa propre EPCIS. Les informations stockées sont complémentaires. Aussi, il faut pouvoir retrouver la base (EPCIS) où sont stockées les informations que l'on souhaite. C'est le rôle de l'ONS, et du format "ONS HOSTNAME" de l'EPC (code produit électronique).

Le standard CBV spécifie des éléments de vocabulaire et leurs valeurs à utiliser en corrélation avec le standard EPCIS. Les identificateurs du vocabulaire, et les définitions de ce standard vont permettre à tous les participants qui échangent des informations via EPCIS d'avoir une sémantique commune, donc un niveau de compréhension uniforme. En particulier, ce standard est fait pour définir des vocabulaires qui seront inclus dans les modèles abstraits d'EPCIS et qui seront applicables aux scénarios commun aux entreprises qui désirent partager des informations (partenariats). Son but est donc de fournir un ensemble de valeurs et de définitions compréhensibles par tous dans la chaîne d'approvisionnement.

Ce standard permet d'identifier les lecteurs en utilisant des certificats numériques.

Spécifie une architecture pour la maintenance et l'échange d'information du pedigree électronic (en).

Cette section ne cite pas suffisamment ses sources (mai 2017). 

Pour l'améliorer, ajoutez des références de qualité et vérifiables (comment faire ?) ou le modèle {{Référence nécessaire}} sur les passages nécessitant une source.

L'idée^[Quoi ?] est de permettre de découvrir les informations auquel un participant P1 à le droit d'accéder, alors que ces informations sont détenues par un autre participant P2 avec lequel P1 n'a pas de partenariat. Les bénéfices visés sont les suivants :

• Permettre aux partenaires d'accéder à toute information sur l'objet
• Permettre aux partenaires d'échanger des informations de façon sécurisée avec d'autres partenaires
• Assurer que chaque participant garde les droits de propriété sur ses propres données
• Assurer que les requêtes soient autorisées et authentifiées

WinRFID est un intergiciel développés en Microsoft .NET WinRFID a cinq couches principales :

1. Une couche traite le matériel - lecteurs, étiquettes et d'autres capteurs.
2. Une autre résume les protocoles de lecteur-étiquette.
3. Vient la couche informatique, qui traite les données produites par le réseau du lecteur.
4. Puis une couche constitue le cadre de XML pour la représentation de données et d'information.
5. Enfin la couche supérieure traite la présentation de données selon les conditions des utilisateurs ou des différentes applications d'entreprise.

La couche matériel traite l'abstraction de trois éléments de l'infrastructure de RFID - lecteurs, étiquettes et interfaces d'entrée-sortie. L'abstraction rend très simple de dériver n'importe quel lecteur ou d'étiquette.

Le composant protocole permet d'envelopper la syntaxe de commande et la sémantique d'une série de protocoles édités tels qu'ISO 15693, ISO 14443, A/B d' ISO 18000 - 6, ICode, EPC classe 0 et EPC classe 1.

La couche présentation des données facilite la visualisation de données pour la prise de décision.

La page du projet WinRFID

Cette section ne cite pas suffisamment ses sources (mai 2017). 

Pour l'améliorer, ajoutez des références de qualité et vérifiables (comment faire ?) ou le modèle {{Référence nécessaire}} sur les passages nécessitant une source.

Le middleware RFID IBM Websphere est composé de trois éléments :

• l'infrastructure dispositif RFID Websphere (WRDI). Qui permet de déployer entre autres les contrôleurs, les lecteurs et les imprimantes RFID. Tous ces appareils étant pilotés par le WRDI. Le WRDI permet également de filtrer et agréger les données RFID en éliminant les doublons et en identifiant les événements RFID pour minimiser le trafic sur le réseau.
• Le serveur RFID Premises WebSphere permet un déploiement de la RFID en entrepôt, dans des centres de distribution ou des ateliers. C'est une plate-forme applicative J2EE permettant d'intégrer les événements RFID provenant des différents capteurs mis en place dans l'entreprise dans les processus métier.
• le logiciel IBM WebSphere Business Integration ne fait pas à proprement partie du middleware mais peut-être considéré comme la partie émergée de l'iceberg puisqu'il permet l'intégration des processus RFID dans les applications métier de l'entreprise.

Cette section ne cite pas suffisamment ses sources (mai 2017). 

Pour l'améliorer, ajoutez des références de qualité et vérifiables (comment faire ?) ou le modèle {{Référence nécessaire}} sur les passages nécessitant une source.

Le projet d'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 RFID et sur les capteurs. Il met en œuvre 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 à bas niveau. AspireRFID permet les spécifications des processus permis par RFID. En conséquence, les outils produisent tous les objets RFID exigés pour déployer ces solutions sur l'AspireRfid middleware.

L'architecture d'Aspire RFID se compose :

1. D'une couche d'abstraction de matériel, dont le rôle 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.
2. La couche "Reader Core Proxy" qui permet de transformer un lecteur non conforme a la norme EPC en un lecteur conforme.
3. Une couche "Serveur de Filtrage et de Collection" qui permet d'btenir uniquement les données utile a l'application

Cette section ne cite pas suffisamment ses sources (mai 2017). 

Pour l'améliorer, ajoutez des références de qualité et vérifiables (comment faire ?) ou le modèle {{Référence nécessaire}} sur les passages nécessitant une source.

Fosstrak est une plate-forme logicielle open-source RFID qui met en application les caractéristiques de réseau de EPC. En outre, AspireRFID utilise Fosstrak. Fosstrak possède :

• un serveur de filtrage et d’agrégation des données
• un client autonome et WEB afin de pouvoir configurer les serveurs de filtrage

Tous les modules de Fosstrak implémentent la spécification EPCglobal.

RFID Gateway est une solution qui respecte les standard EPC

RFID Gateway possède une architecture modulaire pour une mise en œuvre progressive et possédant une capacité d’extension. Il est basé sur une architecture JAVA et ainsi compatible avec tout environnement JAVA sous Windows / Unix.

RFID GateWay permet également une intégration rapide avec les applications d’entreprise[20].

• Internet des objets
• Radio-identification
• Communication en champ proche

• (fr) Gateway RFID
• (en) http://www.epcglobalinc.org/standards/tds/
• (en) http://www.epcglobalinc.org/standards/TagClassDefinitions_1_0-whitepaper-20071101.pdf

• (en) Syed A. Ahson et Mohammad Ilyas, RFID Handbook : Applications, Technology, Security, and Privacy, CRC Press, 18 mars 2008, 712 p. (ISBN 978-1-4200-5499-6)
• (en) Klaus Finkenzeller, RFID Handbook : Fundamentals and Applications in Contactless Smart Cards and Identification 2nd Edition, Wiley, 23 mai 2003, 446 p. (ISBN 0-470-84402-7)
• (en) David Simplot Ryl, Natalie Mitton, Éric Schmidt, Bolić Miodrag et Ivan Stojmenović, RFID middleware : concepts and architecture, Wiley, 1^er juillet 2010, 576 p. (ISBN 978-0-470-74602-8 et 0-470-74602-5), p. 1–14

• (en) Christian Floerkemeier, Christof Roduner et Matthias Lampe, « RFID Application Development With the Accada Middleware Platform », IEEE SYSTEMS JOURNAL, vol. 1, n^o 2,‎ décembre 2007 (lire en ligne)

• Loic Schmidt, « Passage à l'échelle des intergiciels RFID pour l'informatique diffuse », Thèse de doctorat,,‎ 2010, p. 1–14
• Samuel Fosso Wamba et R. Anderson, « Les impacts de la technologie RFID et du réseau EPC sur la gestion de la chaîne d'approvisionnement », Thèse de doctorat, École Polytechnique de Montréal,‎ 2009, p. 1–14

• Xavier BARRAS, « RFID, Normes et Standards », Présentation,‎ 2005 (lire en ligne)
• (en) Shawn Willett, « RFID Middleware by Current Analysys », Forrester,‎ juin 2004 (lire en ligne)
• (en) S. Leaver, « Evaluating rfid middleware », Forrester review,‎ août 2004
• (en) Christian Floerkemeier, « Integrating RFID Readers in the Enterprise IT – Overview of Intra-organizational RFID System Services and Architectures », une publication AutoID lab,‎ 2005 (lire en ligne)
• (en) Fundamentals in Radio Frequency IDentification Publication pour l'auto-ID lab par Peter H. Cole.
• (en) The EPCglobal Network: Enhancing the Supply Chain, livre blanc de VeriSign.

• Portail de l’informatique