Middleware RFID, un poumon qui souffre d'une intégration au SI trop artisanale
En permettant la transformation des données brutes en flux compréhensibles par les systèmes d'information, le middleware constitue une brique centrale dans la chaîne RFID. Mais souffre encore de procédures d'intégration artisanales. L'offre, quant à elle, reste entre les mains des géants de l'ERP et des bases de données.
Dans l'Internet des objets, le middleware RFID constitue le cerveau de la chaîne logicielle qui vient donner de l'intelligence aux données récupérées sur les produits étiquetés d'une puce radio- fréquence. Un point central dans l'implémentation de la RFID en entreprise, pour qui a d'importantes quantités de données à traiter et, surtout, à partager avec l'ensemble de sa chaîne de valeur et de partenaires. Un distributeur doit fournir à ses partenaires des données compréhensibles par les systèmes en place. Et c'est bien là que réside l'enjeu du middleware.
Dans la RFID, la couche intergicielle est confrontée à de fortes contraintes. D'abord liées au matériel et à l'environnement dans lequel ce même matériel est déployé. Le choix de lecteurs et d'étiquettes RFID (Tag) adaptés correspond au premier enjeu, d'autant que les analystes s'accordent à dire que la qualité de lecture de ces capteurs est assez hétérogène. Puis vient ensuite celle de la législation sur l'utilisation des plages de fréquences autorisées qui diffèrent d'un pays à l'autre. Suivent ensuite le filtrage des flux de données ainsi récupérées, leur gestion centralisée et enfin la gestion de la qualité des services. Ce sont les tâches premières du middleware RFID. Suivront ensuite les procédures de transformation des données liées à l'intégration aux processus métier de l'entreprise. Une chaîne complexe, en somme.
Olivier Liechti, ancien architecte chez Sun et désormais professeur de sciences appliquées en Suisse, résume ainsi les procédures attachées à un middleware RFID : filtrage et validation des données brutes, fusion des données émises par les différents capteurs, transfert vers les applications métiers, gestion du système.
Techniquement, la mise en place d'un middleware RFID implique une approche fonctionnelle. En définissant minutieusement le périmètre d'activité de la RFID dans les processus métiers. Un point sur lequel insiste Laurent Gonzalez, auteur du livre, « RFID, les enjeux pour l'entreprise » : « Si vous mettez un lecteur et que vous questionnez toutes les 2 secondes les informations contenues dans les puces, même avec un code de 96 bits, vous allez générer une énorme masse de données. Alors qu'une vérification toutes les 30 secondes suffit pour détecter un produit manquant. […] Le but est d'automatiser les procédures pour travailler par exception ».
Le rôle du middleware RFID sera ainsi d'orchestrer la validation et l'agrégation des données.
« Car nous allons être confrontés à des lectures multiples du même produit [...] Il faut filtrer ces informations qui ne sont pas directement exploitables, depuis la lecture vers le SI. Puis, une fois qu'on les a agrégées, les purger de leurs erreurs », poursuit-il.
Un marché fragmenté
Aujourd'hui, le marché des middlewares RFID reste très atomisé, confirme Jean-Philippe Leclercq, responsable partenariat du Pôle Traçabilité, pôle de compétitivité localisé à Valence, spécialisé dans la thématique de la traçabilité . Avec d'un côté, les ténors des applications d'entreprises (base de données ou ERP), comme Oracle, Microsoft et SAP, et de l'autre, des spécialistes dont une des particularités est de se positionner sur des marchés verticaux.
« Pratiquement tous les éditeurs de d'infrastructures que ce soit Oracle, Sybase ou Progress Software, ont une offre adaptée RFID », commente Salem m'Zebla, consultant indépendant.
L'offre logicielle est donc majoritairement entre les mains des ténors du secteur. Reste encore à les différencier en comparant « l' aptitude des middlewares à intégrer l'ensemble des composants matériels. » Car une des contraintes premières du logiciel est de pouvoir gérer, à l'autre bout de la chaîne, une grande diversité de portiques et lecteurs, dont le marché fourmille. Un simple coup d'oeil dans les allées du salon RFID 2008 démontrait que le segment de la lecture de tag RFID est en plein effervescence.
« La difficulté du RFID est qu'il s'agit d'un marché extrêmement fragmenté. Du fondeur de silicium aux constructeurs qui intègrent la puce dans un smart label (étiquette imprimée comportant un transpondeur), on a un large spectre d'intervenants. Puis viennent ceux qui font les lecteurs. Et même chose pour les middlewares. Pour les clients, la difficulté est ainsi de savoir quelle est l'offre la plus adaptée. […] On reste dans des logiques de captation de marché, où les ténors de l'ERP tiennent le haut du pavé », explique Salem m'Zebla.
L'intégration par l'exemple
En dépit des standards EPCIS et ALE définis par EPC Global (voir encadré), l'intégration des middlewares RFID dans un système d'entreprise reste une démarche très artisanale. Pas assez de retours d'expérience, des pilotes à rallonge, des environnements complexes et parfois trop propriétaires, les recommandations des analystes invitent à la prudence. Et surtout à cumuler les tests pour s'assurer d'un fonctionnement adéquat.
C'est l'avis de Laurent Gonzalez : « Vous pouvez modéliser un système, mais rien ne donnera un meilleur retour d'expérience que de tester la solution dans votre environnement. C'est le seul moyen de gérer les imprévus, comme les problèmes d'interférences. Il s'agit de profiter du retour d'expérience qui commence à être réel chez les intégrateurs. » En clair, une démarche d'intégration RFID démarre nécessairement par une approche fonctionnelle, reposant sur des tests en conditions réelles.
Reste qu'aujourd'hui, c'est bien là que le bât blesse. Lorsqu'il s'agit d'aborder l'intégration de middleware RFID dans le SI, « on est plutôt dans une approche empirique que dans une approche systémique », insiste Salem M'Zebla. « Nous n'avons pas de recul suffisant pour pouvoir analyser suffisamment les pilotes dans chaque métier. Les projets ne sont pour l'heure pas finalisés. On en est encore au stade de l'EPCIS qui constitue ainsi, pour l'heure, la seule passerelle formalisée pour l'intégration d'un middleware RFID au plus près des processus d'une entreprise ».
Face à de lourds investissements qu'impliquent les déploiements de chaînes RFID, l'Union Européenne,a inauguré en janvier 2008 le projet Aspire (Advanced Sensors and lightweight Programmable middleware for Innovative RFID Enterprise applications), qui vise à faciliter l'accès à la technologie pour les PME.
« La RFID est une technologie très compliquée et les coûts importants freinent les PME dans leur démarche », explique Jean-Philippe Leclercq, responsable partenariat du Pôle Traçabilité, pôle de compétitivité localisé à Valence, spécialisé dans la thématique de la traçabilité, d'autant que les compétences dans ce genre de petites structures font généralement défaut.
Aspire, entièrement Open Source, doit fournir les briques essentielles d'intégration, en se basant sur un support optimisé des standards (comme ceux développé par EPC Global). L'idée est ainsi de livrer un middleware que l'on peut insérer entre un large panel de capteurs (lecteur ou portique) et tout type de systèmes d'entreprise, comme un ERP. Pour cela, le projet repose sur une communauté qui devra développer les interfaces entre les deux maillons de la chaîne.
« Il s'agit d'un projet ambitieux qui capitalise sur l'existant », rappelle Jean-Philippe Leclercq. Aspire est le résultat d'une fusion entre deux projets Open Source : Fosstrack - ex Accada – et UJF Suite. C'est le consortium OW2 qui héberge le projet depuis juin 2008.
En savoir plus :
Face à un marché fortement atomisé, l'organisation EPC Global, qui forme également l'épine dorsale de l'Internet des objets, avec son vaste réseaux d'interconnexion, a développé une série de standards dont le but est de proposer un socle applicatif que les éditeurs choisissent - ou non - d'intégrer dans leur solution.
Deux standards se détachent quand il s'agit de traiter les informations récupérées par le lecteur et transmises au SI : ALE et EPCIS (EPC Information Services).
Les flux de données récupérées des capteurs sont transcrits sous forme de documents XML conformes à la norme ALE (Application Level Event) et structurés sous forme d'événements. Ces données transformées sont alors inscrites dans un annuaire de mouvements, l'EPCIS. De façon à pouvoir le partager avec un réseaux de partenaires.
Grâce à ALE, le middleware fournit une couche d'abstraction au système, affirme Olivier Liechti, ancien architecte chez Sun et désormais professeur de sciences appliquées en Suisse. « ALE permet l'indépendance entre les composants qui capturent les données brutes, et ceux qui filtrent et fusionnent les données en les transformant en événement. »
