Recommandé
Contenu connexe
Tendances
Tendances (20)
Similaire à RFID
Similaire à RFID (20)
RFID
- 1. Réalisé par Wafa LAKDHAR Mlle. Marwa CHAMEKH (ITesLab) M. Soufiene MEJRI (INSAT) M.Yassine FRIAA (INSAT) Président du jury Mme. Saloua BEN YAHIA Examinatrice Mme. Olfa MESBEHI Mise en Place d’une Plateforme deContrôle d’une usine àbase e latechnologie RFIDet le standard EPCglobal Encadré par:
- 2. Introduction Problématique Solution proposée Analyse des besoins Implémentation Conclusion & perspectives Conception Plan 02
- 3. Introduction Problématique Solution proposée Analyse des besoins Implémentation Conclusion & perspectives Conception Plan 03
- 4. Environnement Processus Stratégie Introduction Problématique Solution Proposée Analyse des Besoins Conception Implémentation Conclusion et perspectives 04
- 5. Fournisseur Distributeur Chaine Logistique Traçabilité Visibilité Introduction Problématique Solution Proposée Analyse des Besoins Conception Implémentation Conclusion et perspectives Approvisionnement 05
- 6. Introduction Problématique Solution Proposée Analyse des Besoins Conception Implémentation Conclusion et perspectives Plateforme de Contrôle Configurer les évènements Historique d’évènement Controller employés, produits et outillages Tracer le parcours des objets connectés Idée générale 06
- 7. Introduction Problématique Solution proposée Analyse des besoins Implémentation Conclusion & perspectives Conception Plan 07
- 8. Introduction Problématique Solution Proposée Analyse des Besoins Conception Implémentation Conclusion et perspectives Produit OutilEmployéEntreprise Identification & Traçabilité Suppression la perte des outillages et des produits Augmentation de productivité Sécurité ses information Contrôle des employés Problématique 08
- 9. Introduction Problématique Solution proposée Analyse des besoins Implémentation Conclusion & perspectives Conception Plan 09
- 10. Introduction Problématique Solution Proposée Analyse des Besoins Conception Implémentation Conclusion et perspectives • Code à barre • Code 2 D • RFID Technologies d’identification 10
- 11. Caractéristique Technologies d’indentification RFID Code à barre Code 2D Capacité Stockage Haute Basse Moyenne Lecture Sans visibilité Visibilité Visibilité Vitesse de lecture Très rapide Rapide Rapide Simultanéité de Lecture Oui Non Non Robustesse au Milieu Haute Moyenne Basse Cout du Tags [0,1 - 1] € <0,10€ <0,01 € Cout du lecteur Élevé Bas Moyen Contexte du projet Problématique Solution Proposée Analyse des Besoins Conception Implémentation Conclusion et perspectives Tableau Comparative des technologies d’identification 11
- 12. Contexte du projet Problématique Solution Proposée Analyse des Besoins Conception Implémentation Conclusion et perspectives RFID est une technologie qui permet d’identifier, à distance, des objets, des animaux ou des personnes, sans contact physique, ni visuel. Pour cela, les données sont stockées et récupérées à distance en utilisant les ondes radio comme média de communication Qu’est ce qu’un système RFID 12
- 13. 011101010 100101010 101010101 111000010 101010101 010101010 101010101 010101101 MiddlewareLecteurTags Principe de fonctionnement du système RFID Introduction Problématique Solution Proposée Analyse des Besoins Conception Implémentation Conclusion et perspectives 13
- 14. Introduction Problématique Solution Proposée Analyse des Besoins Conception Implémentation Conclusion et perspectives Qu’est ce que le standard EPCglobal ? Le standard EPCglobal est un standard mondial de la traçabilité. Il nous permet de suivre la progression et le statut de nos objets. 14
- 15. Architecture du standard EPCglobal Introduction Problématique Solution Proposée Analyse des Besoins Conception Implémentation Conclusion et perspectives • « Reader Protocol Standard » dédié à l'interaction avec les lecteurs. Niveau RP • (Filltring and Collection ) qui implémente le standard ALE Niveau FC Middleware • (Application Level Events) , elle permet d’obtenir des données filtrés et cohérents prévenues d'une grande variété de sources ALE • (EPC Information Service), qui permet à plusieurs applications de gérer les données EPC à l'intérieur et à l'extérieur des entreprises. EPCIS • Cette application capture les ECReports à travers l’interface ALE après les réarrange. Capture Application 15
- 16. Avantages du standard EPC Gen 2 v2 Introduction Problématique Solution Proposée Analyse des Besoins Conception Implémentation Conclusion et perspectives Lutter contre la contrefaçon grâce à la vérification de l’authenticité d’un tag Renforcer la sécurité en modifiant les informations contenues dans un tag de manière sécurisée Assurer une meilleure gestion de fichiers par l’attribution des privilèges d’accès Faciliter la prévention des pertes par l’utilisation du tag en tant que système antivol EPC Gen 2 v2 16
- 17. Solution existante ClearStream TRACE’IT Introduction Problématique Solution Proposée Analyse des Besoins Conception Implémentation Conclusion et perspectives Cette solution vise à rendre plus facile pour les utilisateurs de gérer les lecteurs EPC Gen 2 UHF RFID fixe, et à lire et écrire des données codées sur les étiquettes puis stocker ces informations sur un PC Cette solution à été conçu en réponse aux problématiques identifiées de gestion des outillages et biens d’équipements, en particulier ceux soumis à vérification périodique. 17
- 18. Critique des solutions existantes Cout chère Non modularité Faiblesses en matière de sécurité 18
- 19. Solution Une plateforme de contrôle basée sur un middleware open-sourceen lui ajoutant un module de sécurité. Notre solution est conçue enmode Web, doncl’application doit être très rapide à déployer et permettre un accès hiérarchisé à la base de traçabilité, depuis n’importe quel PC équipé d’un navigateur. 19
- 20. Introduction Problématique Solution proposée Analyse des besoins Implémentation Conclusion & perspectives Conception Plan 20
- 21. Introduction Problématique Solution Proposée Analyse des Besoins Conception Implémentation Conclusion et perspectives Administrateur Responsable de Stock Les acteurs de la solution Solution 21
- 22. Introduction Problématique Solution Proposée Analyse des Besoins Conception Implémentation Conclusion et perspectives Analyse fonctionnelle Administrateur Gérer les objets connectés Gérer les alertes Gérer les employés Visualiser le Map de l’usine Gérer l’historique des mouvements Générer les rapports <<extended>> Configurer les seuils de déclanchement Gérer les réactions des alertes Visualiser les Alertes générés S’authentifier <<extended>> <<extended>> <<included>> <<included>> <<included>> Ajouter Employé Supprimer Employé Afficher Employé <<extended>><<extended>> <<extended>> 22
- 23. Introduction Problématique Solution Proposée Analyse des Besoins Conception Implémentation Conclusion et perspectives Responsable de Stock Gérer les cellules de prod Gérer les alertes Gérer le mouvement de stock en RT Générer le rapport des marchandise d’E/S Visualiser l’historique des objets connectésVisualiser le Map Générer Réaction des alertes Visualiser Alerte S’authentifier <<extended>> <<extended>> <<extended>> <<extended>> <<extended>> <<extended>> 23
- 24. Introduction Problématique Solution proposée Analyse des besoins Réalisation Conclusion & perspectives Conception Plan 24
- 25. Introduction Problématique Solution Proposée Analyse des Besoins Conception Implémentation Conclusion et perspectives Architecture globale de la plateforme Database "MySQL" Hardware RFID Data Adapter RFID Data Aggregator RFID Data Filter Reader Adapter Reader Adapter Reader Reader Reader TagTag Tag Tag ... ... ... RFID Database métier Middleware Web Application 25
- 26. Introduction Problématique Solution Proposée Analyse des Besoins Conception Implémentation Conclusion et perspectives Architecture globale du Middleware 26
- 27. Introduction Problématique Solution Proposée Analyse des Besoins Conception Implémentation Conclusion et perspectives Diagramme de classe du Middleware 27
- 28. Diagramme de classe du Capture Application Introduction Problématique Solution Proposée Analyse des Besoins Conception Implémentation Conclusion et perspectives 28
- 29. Données Métier Présentation DAO Logique métier Base de données Architecture de l’application Web ModelContrôleur Vue Introduction Problématique Solution Proposée Analyse des Besoins Conception Implémentation Conclusion et perspectives 29
- 30. Introduction Problématique Solution Proposée Analyse des Besoins Conception Implémentation Conclusion et perspectives Scénario de l’envoi de notification vers Androïde 30
- 31. Introduction Problématique Solution proposée Analyse des besoins Implémentation Conclusion & perspectives Conception Plan 31
- 32. Introduction Problématique Solution Proposée Analyse des Besoins Conception Implémentation Conclusion et perspectives Environnement de développement du Middleware Nom Famille d'étiquettes supporté Lang age cible Filtrage Agrégation Persistance modulaire Logiciel Libre Documen- tation Nombre maximums des lecteurs EPC Networking Java illimité EPC Networking Java limité EPC Networking Java illimité Conçu en webservices qui sont maintenus et générés avec Basé sur le standard EPCglobal Modulaire Configurable via des technologies 32
- 33. Introduction Problématique Solution Proposée Analyse des Besoins Conception Implémentation Conclusion et perspectives Présentation Traitement métier Données Environnement de développement de l’application Web 33
- 34. Autres frameworks et technologies utilisés Apache Tomcat Eclipse Eclipse RCP&RAP Developers SDK Androïde GCM Introduction Problématique Solution Proposée Analyse des Besoins Conception Implémentation Conclusion et perspectives GenyMotion 34
- 35. Introduction Problématique Solution Proposée Analyse des Besoins Conception Implémentation Conclusion et perspectives Serveur web Virtual World Fosstrak EPCIS event ECReports FCServer ALE Engine LLRP Comman-der Reader EPCIS Capture MySQL FCServer WebClient Web Elément existant Serveur BD MySQL Tags radio Capture ApplicationModule de Vérification Application Web ECSpec (HTTP/SOAP) LRSpec (HTTP/SOAP) ROSpec Agrégation module Signature A configurer A implémenter Architecture technique de la plateforme 35
- 36. Introduction Problématique Solution Proposée Analyse des Besoins Conception Implémentation Conclusion et perspectives 36
- 37. Introduction Problématique Solution Proposée Analyse des Besoins Conception Implémentation Conclusion et perspectives 37
- 38. Introduction Problématique Solution Proposée Analyse des Besoins Conception Implémentation Conclusion et perspectives 38
- 39. Introduction Problématique Solution Proposée Analyse des Besoins Conception Implémentation Conclusion et perspectives 39
- 40. Introduction Problématique Solution Proposée Analyse des Besoins Conception Implémentation Conclusion et perspectives 40
- 41. Introduction Problématique Solution Proposée Analyse des Besoins Conception Implémentation Conclusion et perspectives 41
- 42. 42 Introduction Problématique Solution Proposée Analyse des Besoins Conception Implémentation Conclusion et perspectives
- 43. Introduction Problématique Solution proposée Analyse des besoins Implémentation Conclusion & perspectives Conception Plan 43
- 44. • Assurer le contrôle de l’usine virtuelle • Améliorer le processus de suivi • Un Dashboard de suivie de pilotage • Standardiser la solution Introduction Problématique Solution Proposée Analyse des Besoins Conception Implémentation Conclusion et perspectives 44
- 45. Introduction Problématique Solution Proposée Analyse des Besoins Conception Implémentation Conclusion et perspectives • Intégrer la technologie IoT • Intégrer l’usine dans une chaine logistique • Ajouter quelques fonctionnalités dans l’application • Accessible par le smart phone 45
- 47. L’implémentation de l’architecture du Fosstrak n’a pas été d’une grande simplicité . Comprendre comment les modules s’imbriquent entre eux et les faire fonctionner ont nécessité un temps plus long que prévu. Travailler sur une version alpha apporte aussi son lot de contraintes : plantages, documentations limitées même si le site du Fosstrak est très bien documenté , etc. Faute du matériel (les lecteurs et les tags) , nous nous sommes orientés vers l’approche de simulation et nous avons pu atteindre la majorité des objectifs fixés D’où parfois on a obtenu des fausses résultats . Point de vue Stockages des données dans la base de donnés Conclusion Difficultés Ce que nous avons réalisé? Perspectives 47
Notes de l'éditeur
- Le plan de notre présentation sera comme suit : (*) Nous commencerons par présenter le contexte du projet (*) Puis nous enchainons avec la problématique et la solution proposée. (*) Suivi de la phase d’analyse et de spécification des besoins à satisfaire. (*) Après nous passons à l’architecture et la conception de notre projet. (*) Ensuite la phase de réalisation dans laquelle nous décrivons la solution mise en œuvre . (*) Pour finir avec la conclusion et les perspectives envisagées.
- Aujourd’hui l’entreprise opère dans environnement complexe caractérisé par : Une concurrence vive Des prix bas Une disponibilité plus grande des produits et une réduction des cycles de vie des produits
- L’entreprise n’agit plus isolément mais dans une logique étendue appelée chaine logistique ou supply chain L’integrité de l’activité inter et intra- entreprise nécessite une visibilité permanant de l’information et une traçabilité des produits tous au long de son cycle de vie
- L’idée générale du projet consiste donc à concevoir une plate forme de contrôle qui pourra de façon concrète permettre d’effectuer la supervision (configuration, historique d ’événements, contrôle employés ,Produits et matériaux) en se basant sur l’inventaire des objets connectés (produits, employés, et matériaux).
- Avant de plonger dans l’étude proprement dite de la solution, il est indispensable de prendre du recul et de parler des problèmes concrets existants que nous rencontrent au jour le jour. Voila ce digramme représente le Bête à corne de notre problématique Comment l’entreprise assure t – elle la traçabilité et l’identification des employés des outillages et des produits afin d………
- Pour assurer la traçabilité et l’identification divers technologies de capture automatique des données se sont imposées à savoir
- Le choix d’une technologie % à une autre se fait principalement en fonctionnement des applications mises en place. Pour ce fait nous avons effectué une étude comparative de ces technologies + La technologie RFID dispose une capacité de stockage plus importante que les autres technologies +La lecture des tags RFID est également plus rapide que les autres Tech car le temps nécessaire pour localiser ces derniers est supprimé. +Avec RFID un seul lecteur peut lire simultanément plusieurs tags par seconde, ce qui représente un gain de temps considérable +Les tags RFID semblent être plus résistants aux conditions de l’environnement que les codes à barre et les code 2D. Ces derniers sont facilement détériorés avec l’humidité, le soleil, la poussière, etc. + La technologie RFID ne requièrent pas un contact visuel direct avec les lecteurs pour être lus, par contre les autre tech ont besoins d’un conta Le seul point faible du RFID c’es qu’elle plus coûteuses que les autre technologies. Donc le choix est porté sur RFID
- 1.Le lecteur émet en permanence un champ électromagnétique 2.Lorsqu’un objet équipé d’un tag RFID rentre dans le champ du lecteur , L’énergie électromagnétique est transmise à la puce, qui s’active 3.Utilisant cette énergie, la puce répond en envoyant son ID et les données qu’elle contient. 4. Le lecteur reçoit l’information et le transmet au middleware qui a pour rôle de gérer, collecter et de mettre en forme les données pour l’application finale.
- Afin de standardiser notre solution nous avons intégré le standard EPCglobal dans notre solution .
- EPCglobal a mis pour son standard un Framework d’architecture .
- Pour le tags on a pensé de travailler avec le standard EPC Gen 2 V2
- Nous avons effectué une étude de marché de la solution RFID pour savoir quels étaient les principaux acteurs dans ce domaine et quel type de solution était disponible à la vente. Nous avons sélectionné les principaux solutions dans le marché qui sont :
- Parmi Les limites de ces sollution
- Notre solution consiste à mettre en place :….
- Passons maintenant à l’analyse fonctionnelle de la solution,
- notre solution s’adresse à deux acteurs principaux, à savoir : -L’administrateur -Responsable du stock
- Notre système offre à l’administrateur la possibilité de : Gérer les objets connectés il a le droit de Gérer les alertes Il peut éventuellement Gérer les employés par ajout, modif, suppression des employés Bien sûr tout cela nécessite une authentification au préalable.
- Également, nous permettant aux utilisateurs ayant le rôle responsable de stock de : Gérer les cellules de production Gérer les alertes Tout cela après s’être authentifié
- Décrivons maintenant l’architecture qu’on a choisit pour notre solution et sa conception
- Nous commençons par présenter l’architecture global de la solution Et nous détaillerons après les différents modules qu’ils composent Comme il est illustré notre solution se compose de trois parties : Hardware (Tag et readers) Middleware qui pour rôle de Collecter filtrer et agréger les données reçus des couches inférieurs et finalement la couche métier qui est une application web responsable de l'exécution des processus métiers globaux de l'entreprise, tels que la gestion du stock , l'expédition et la réception des produits, l'analyse de l'historique..
- Parlons maintenant du middleware Définition:… Il est composé de FCServer c’est le serveur de filtrage et de collection il est constitué de : Module de gestion des lecteurs Module de vérification des signatures reçus de tags . Module de Filtrage et d’agrégation des donnés montés. Après les données seront transférées vers l’application de capture qui va genèrer les événements et stockées dans EPCIS Repository .
- Détaillons le diagramme de classe du Middleware : Notre émulateur envoie les données au FCServer la classe Logical Reader fait l’agrégation de ces données
- CapptureAppLogger fait l’enregistrement systématique des ECReports entrants. La classe ReportHandlerScheduler a pour rôle de faire l’ordonnancement des ECReports reçus de ALE Engine en utilisant les règles de gestion de la classe ReportManager. Tandis que ReportHandlers’occupe de gestion des ces ECReports. Finalement ReportWriter crée les événements EPCIS.
- Notre application Web est composé de trois couches à savoir : Couche Présentation :correspondant à l’affichage, et le dialogue avec l’utilisateur. Couche métier : correspondant à la mise en œuvre de l’ensemble des règles de gestion et de la logique applicative Couche donnée : correspondant aux données qui sont destinées à être conservées sur la durée, voire de manière définitive => Il est clair ici que notre application suivit l’architecture MVC
- Après la définition de l’architecture de notre application Web nous présentons quelques scénarios
- Nous passons a la partie realisation et implementation
- Afin de mettre en place notre middleware on a effectué une étude comparative des middleware open source existant . Ce choix est …. Par la sélection du Fosstrak. Le problème majeur des autres middlewares c’est qu’ils ne sont pas modulaires de ce fait il est difficile de les adapter aux besoins des utilisateurs. Fosstrak est conçu en webservices qui sont maintenus et générés avec Maven . Configurable via des technologies XML, il est extensible ce qui nous permet d’implémenter des modules Basé sur le standard EPCgloabal
- Notre objectif était de mettre en place un système de suivi sécurisé des objets connectés d’une usine, en se basant sur la technologie RFID et permettre aux utilisateurs d’assurer le contrôle de ces objets. Afin d’integrer l’usine dans la chaine logistique. Pour atteindre cet objectif nous avons conçu les rapports nécessaire en utilisant qlq tech a savoir: …