Démonstrateur objet communicant passif / actif

L’objet communicant passif est caractérisé pour offrir aux demandeurs de services un ensemble de services. Dans notre cas, les objets physiques offrent des services aux acteurs de l’entrepôt en s’appuyant sur les capacités de mémorisation fournies par des étiquettes électroniques RFID. Dans notre démonstrateur nous avons utilisé un système RFID OMRON V720S opérant avec des étiquettes électroniques I-CODE1 de 13.56 Mhz. La Figure 100 illustre la structure de la mémoire de cette étiquette électronique. L’étiquette contient 64 octets de mémoire. Les fonctions du système (SNR, protection d’écriture, EAS) sont composées de 5 pages de mémoire. Chaque page contient 4 octets (32 bits). Le FC (Family Code) et le AI (Aplication ID) sont utilisés pour enregistrer respectivement le type d’objet (produit, boites de produit, palette) et les services disponibles (actifs) d’un objet. L’aire utilisateur (user area) contient 11 pages (44 octets) de mémoire disponibles.

Figure 100 : Mémoire d’une étiquette électronique de produit communicant.

Dans notre démonstrateur, nous avons utilisé le mode de communication Single Access Mode, c’est-à-dire, le mode qui permet de lire ou écrire une étiquette à la fois. Cela veut dire que la relation objet physique - dispositif UPnP RFID est 1 : 1.

5.7.1.1 Création et description des services de l’objet communicant

Le processus de création des services d’un objet communicant est appuyé par l’outil Service Author fourni par Intel⁴⁵. Cet outil permet de générer et de valider automatiquement la description XML des services proposés pour un objet communicant. Pour créer un document XML, il faut définir les variables d’un service, et ensuite les actions qui vont être associées à ces variables. Une fois définies les variables et les actions dans l’outil Service Author, nous pouvons obtenir le fichier de description XML associé à un service. On va obtenir autant des fichiers de description XML que des services offerts par l’objet communicant. Ainsi, tous les services qui sont offerts par un objet communicant passif (décrits dans le point 5.3.3 de ce chapitre) peuvent être obtenus en utilisant cet outil.

Dans la Figure 101, nous illustrons un document XML décrivant le Service Composition d’une Boite. On observe deux actions permettant d’obtenir et de changer le nombre de produits contenus dans une boite de produits. Les deux actions sont associées à la variable NrProduits. La variable Code sera utilisée pour représenter le résultat d’une action donnée. Si le résultat d’une action est correct et sans erreur, la valeur sera « 0 ». Par exemple quand un demandeur de services exécute une action donnée sur l’objet communicant afin d’écrire une donnée sur l’étiquette électronique, le Code informera que l’action a été correctement réalisée. Dans la partie inférieure de la figure, on observe la description des variables associées au service : type de variable et son caractère événementiel. La variable NrProduits est définie comme événementielle afin de pouvoir informer les intéressés d’un changement interne.

Action 2 : Modifier le nombre de produits contenus dans une boite Action 1 : Obtenir le nombre de produits contenus dans une boite

Argument

Variable

Contrôle le résultat de l’action

Description des Variables <?xml version="1.0" encoding="utf-8"?> <scpd xmlns="urn:schemas-upnp-org:service-1-0"> <specVersion> <major>1</major> <minor>0</minor> </specVersion> <actionList> <action> <name>getNrProduits</name> <argumentList> <argument> <name>iNrProduits</name> <direction>out</direction> <relatedStateVariable>NrProduits</relatedStateVariable> </argument> </argumentList> </action> <action> <name>setNrProduits</name> <argumentList> <argument> <name>iNrProduits</name> <direction>in</direction> <relatedStateVariable>NrProduits</relatedStateVariable> </argument> <argument> <name>iCode</name> <direction>out</direction> <relatedStateVariable>Code</relatedStateVariable> </argument> </argumentList> </action> </actionList> <serviceStateTable> <stateVariable sendEvents="yes"> <name>NrProduits</name> <dataType>ui1</dataType> </stateVariable> <stateVariable sendEvents="no"> <name>Code</name> <dataType>ui1</dataType> </stateVariable> </serviceStateTable> </scpd>

Figure 101 : Diagramme XML décrivant le service « Composition d’une boite »

L’exemple de service expliqué sera associé à un objet physique « boite de produits » et à un objet physique « palette ». Après avoir créé la description de tous les services d’un objet communicant, l’outil Intel Device Spy (Universal Control Point) permet de tester l’invocation d’action et la souscription aux événements des variables d’un objet communicant.

5.7.1.2 Génération de l’application logiciel

L’outil Intel Device Builder permet de générer automatiquement le code source de base pour créer un dispositif UPnP à partir d’un ensemble de services et leurs descriptions XML. Le code résultant incorpore les fonctionnalités UPnP et les méthodes permettant d’exécuter les actions du dispositif. L’Intel Device Builder travail sous le Microsoft .Net Framework. L’outil permet de choisir plusieurs plateformes de travail (Linux, Windows, Pocket PC,…). Nous avons travaillé avec la plateforme .NET avec le langage de programmation C#. L’environnement de travail Visual Studio .NET 2005 permet d’éditer et de modifier le code de source de base. La compilation du code permet de créer l’application finale.

Dans notre cas, le code source doit être enrichi afin d’intégrer un système RFID dans le dispositif UPnP. La librairie de communication fournie par Franson Serial Tools46 nous a permis de gérer le port série de l’ordinateur afin de communiquer le système OMRON RFID depuis le dispositif UPnP. La communication entre le dispositif UPnP et le système RFID est réalisée au travers de fonctions supportées par le système OMRON RFID. Les fonctions les plus utilisées dans le démonstrateur sont : détection d’une étiquette, lecture d’une étiquette, écriture d’une étiquette, arrêt de la communication, test de communication. La Figure 102 illustre l’objet communicant obtenu.

Figure 102 : Dispositif ou Device Point d’un Objet Communicant Passif / Actif.

Dans le côté gauche de la Figure 102 on observe les données qui vont permettre d’identifier l’étiquette électronique (SNR), le Family Code afin d’identifier le type d’objet (produit, boite de produit, palette), l’AID (Application ID) afin d’identifier la liste de services actifs pour chaque objet physique, et le EAS (Electronic Article Surveillance) afin d’activer la fonctionnalité antivol de l’objet. Egalement, on observe les données stockées sur l’étiquette électronique (DATA) en format ASCII et Hexadécimal.

Dans la parte inférieure gauche de la figure, on présente l’historique des annonces de présence de l’objet physique dans la zone d’attraction RFID.

A droite dans la figure, on observe la liste de services actifs pour un type d’objet physique. La liste de chaque objet physique est obtenue grâce à l’Application ID. Dans le menu « options » (partie supérieure droite) il est possible de paramétrer l’usage du port série et du contrôleur RFID et d’ajouter de nouveaux services à la liste générique de services d’un objet physique.

Ce démonstrateur nous a permis de tester les interactions : produit communicant – point de contrôle / acteur de la chaîne logistique, produit communicant – capteur UPnP et produit communicant – base de

données (représentant un WMS). Dans ces interactions, l’objet communicant peut avoir un rôle de demandeur de services (vers des capteurs UPnP et vers une base de données) et de fournisseurs de services (vers un point de contrôle) dans un réseau ambiant UPnP.