Overblog
Editer l'article Suivre ce blog Administration + Créer mon blog

Archives

Publié par Michel Rousseau

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. Pour ce faire, il est important de proposer différentes latences, puisque la notification de la disponibilité de ces données varie en fonction des applications concernées. Certaines ont besoin de répondre instantanément dans le cadre d’une interaction locale avec les objets physiques et nécessitent par voie de conséquence une latence quasi nulle. D'autres au contraire n’ont rien à voir avec la manipulation du flux de données (i.e. ERP) et peuvent largement recevoir ces données par lots à des intervalles de temps prédéfinis

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

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.

Intégration du lecteur dans le système d’administration de l’environnement IT

La prolifération des lecteurs impose de gérer ceux-ci dans un contexte d’asset management. 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

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ée 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.). Il est en effet vital de savoir à tout instant à qui on a affaire. C'est ainsi que l'identifiant du dispositif est analysé par le middleware et que les droits et privilèges accordés à cet appareil sont approuvés pour son entrée dans le réseau.

Par ailleurs, dans un environnement par essence traçable, il faut faire la part des choses entre données publiques et données privées. Certaines informations ne sont en effet pas bonnes à mettre entre toutes les mains, ne serait-ce que celles de certains clients ou fournisseurs. C'est pourquoi on commence à voir apparaître des systèmes d’identité fédérée permettant à partir d’un même identifiant placé dans l’étiquette et en fonction du middleware lisant les données provenant de celle-ci de n’avoir accès qu’à la portion d’information concernant l'entreprise. Cette fonction est encore rare, mais devrait se généraliser sur les middlewares de deuxième génération dès 2007.

Commenter cet article