air - User contributions [en]

Détection de trafic automobile et de d’attente aux feux

2012-04-06T06:18:16Z

Damontp: /* Difficultés rencontrées */

* Enseignant : Didier Donsez, Thomas Calmant
* Etudiants: CEYTE Christophe, DAMONT Pierre-Rémy.

==Description==

Ce projet a pour d'effectuer des décomptes de trafic automobiles à differents feux d'une ou plusieurs villes.
Les resultats seraient rendus à un serveur central sous forme de relevés.
Ces relevés pourraient être ensuite analysés et interprétés afin de modifier l'ordonnancement des feux, ou une modification de l'urbanisme.
Il pourrait aussi servir à reperer une voiture en infraction dans le cas du passage alors que le feu est rouge

==Materiel et configuration Requise==
* Deux ordinateurs dont un ayant une webcam
* OS : Linux ubuntu ou fedora
* Un JRE ou JDK java
* Plateforme OSGI Felix ou Equinox
* Librairie OpenCv
* Compilateur C/C++
* Apache Maven

==Architecture==
*Partie embarquée :
Cette partie est destinée a être embarquée sur les caméras positionnées aux feux à surveiller.
Composée de deux bundles proposant les services suivants : demarrer la Camera et recuperer le relevé de celle-ci.

*Partie fixe :
Cette partie est destinée a être installée sur un ordinateur fixe dont le role sera de récupérer les données des différentes caméras déployées.
Composée de deux bundles proposant les services suivants : demarrer les acquisitions et recuperer les relevés.

==Manuel d'installation==

-Récuperer les sources a l'adresse svn suivante :

http://subversion.assembla.com/svn/m2m_surveillance_flux_autoroutiers

-Le projet se découpe en 4 sous-projets maven et une partie C++:

La partie n°1 nommée Camera_Finale est à compiler obligatoirement sur le pc embarquant la caméra, du fait de la non portabilité du code C++.

Ces 2 parties sont à compiler et à déployer sur le pc embarqué avec la caméra
Partie n°2 nommée CameraServeur
Partie n°3 nommée CameraServlet

Ces 2 parties sont à compiler et à déployer sur le pc jouant le role du serveur
Partie n°4 nommée ServeurServlet
Partie n°5 nommée ServeurCentral

En effet le projet étant encore en développement, les chemins d'accès aux relevés et à l'executable doivent être modifiés.
(Notamment encas de deploiement sous système windows)

Architecture fonctionnelle :

[[File:Example.jpg]]

Architecture détaillée :

[[File:ArchitectureDetaillee.jpg]]

==Manuel d'utilisation==

Un fois les parties compilées avec les chemins adéquats, il faut insérer dans le répertoire bundle de felix les paquets générés par maven.
Ces paquets se situent dans le répertoire target du sous-projet maven correspondant à la partie en question.

Ainsi sous la plate-forme OSGI embarqué sur l'ordinateur possédant la caméra nous devons avoir ces bundles déployés :

camera-broker-bundle-0-SNAPSHOT.jar
camera-broker-servlet-bundle-0.0.1-SNAPSHOT.jar

Sous la pate-forme OSGI du serveur central ces deux-la :

information-broker-bundle-0.0.1-SNAPSHOT.jar
information-broker-servlet-bundle-0.0.1-SNAPSHOT.jar

Une fois ces bundles déployés un simple accés à la servlet du serveur via un navigateur web a l'url : http://localhost:8080/camera permettra de démarrerl'acquisition sur la caméra distante.

Pour récupérer le relevé de la caméra un accés à l'url : http://localhost:8080/releve permettra de télécharger le fichier releve.xml généré par le serveur de la caméra distante.

Par défaut le téléchargement à lieu dans /home/"nom d'utilisateur" (Ce nom est a préciser par l'utilisateur lors de la compilation)

==Fonctionnalités envisagées==

Nous souhaitions disposer de n caméras, de pouvoir déclencher leur acquisition à distance sur une période donnée, et d'effectuer une collecte automatisée des relevés générés par ces caméras.
Ces relevés seraient stockés dans une base de données en attendant d'être traitées par un outil d'analyse.
Nous souhaitions aussi pouvoir détecter une inffraction.

D'autre part, bien qu'il ne s'agisse pas d'un projet ayant pour sujet le traitement d'image, l'objectif était d'avoir un système de reconnaissance minimal.

==Fonctionnalités réalisées==

Nous n'avons pu develloper un gestion de n caméras, actuellement le système ne fonctionne qu'avec un serveur central et une partie deportée abritant la caméra (simple webcam dans notre cas).

Nous avons mis en place un service de comptage minimal, le défaut étant qu'il reconnait tout les objets en mouvement, pas seulement les voitures, ce qui fausse le résultat.

L'édition de relevé a partir du comptage effectué est fonctionnel.
Ce relevé est téléchargeable a partir du serveur central, la remontée d'information est donc opérationnellev ia le protocole HTTP.

==Améliorations==

Il resterait à étendre la gestion des caméras à partir du serveur.
Par exemple fournir une api web permmettant d'ajouter ou de retirer des caméras suivants leur adresse.

D'autre part si nous avions la possibilité d'être connecter à l'automate du feu, nous pourrions lancer les aquisitions suivants l'état du feu.
Actuellement nous avons lançons l'acquisition pour une durée pré-determinée.

L'édition de relevés pourrait être ainsi plus conséquente, et s'étaler sur une journée entière et prendre ne compte plus d'informations (infractions par exemple).

La reconnaissance pourrait être affinée afin de reconnaitre des objets plus précis (seulement des voitures).

Un outil d'analyse des données sur le serveur central, permettant d'éditer des courbes par exemple serait utile à l'interprétation des résultats.

==Difficultés rencontrées==

- Découverte d'OSGI, packager les composants en bundle.

- Trouver un système de reconnaissance un minimum efficace et rapide, la solution actuelle étant un code open source "FastMatchTemplate".

- Appeller ce code C/C++ non portable à partir d'un bundle.

Détection de trafic automobile et de d’attente aux feux

2012-04-06T06:17:47Z

Damontp: /* Manuel d'installation */

ECOM Warehouse Management System

2012-04-06T00:09:54Z

Damontp: /* Manuel d'nstallation */

* Enseignant : Didier Donsez
* Etudiants M2PGI : CASAGRANDE Thierry, RICHARD David

==Matériel==
* RFID + QRCode + Barcode 1D
* USB Barcode reader
* USB NFC Reader

==Logiciels==
* Apache Felix
* Drools Expert

==Introduction==

Ce projet a pour but de fournir un système permettant la gestion d'un entrepôt. Le système doit gérer les entrées et sorties de produits. Un moteur de règles permettra d'analyser les différentes opérations et pour certains évènements particuliers (par exemple un produit bientôt en rupture de stock) le manager sera notifié.
Les mouvements de stock seront effectués à l'aide d'une scanette et d'un lecteur NFC.
Nous avons choisi de gérer un stockage de bouteilles de vins.

==Architecture==

Notre système se compose de trois parties :
Le "Tag System" qui permet d'utiliser le lecteur NFC pour communiquer avec le server de l'entrepôt
Le "Barcode System" qui permet d'utiliser une scanette pour communiquer avec le server de l'entrepôt
Le "Warehouse Server" qui permet de gérer l'entrepôt

[[Image:Architecture_V2.jpg|Architecture]]

Tag System et Barcode System sont tout deux composés de deux modules :
* Un module « Reader » (TagReader et BarcodeReader) qui permet de scanner les objets et de communiquer avec le serveur grâce à des requêtes REST
* Un module « GUI » (TagGUI et BarcodeGUI) qui offre une interface en Swing pour utiliser le module « Reader »

Warehouse Server :
* Une base de données pour stocker les informations des produits de l'entrepôt
* Un module « WarehouseManager » permettant d'effectuer des opérations sur la base de données
* Deux modules « Solver » (TagSolver et BarcodeSolver) exposant des services REST afin de récuperer les informations envoyées par les « Readers », les analyser et effectuer l'opération requise
* Un module « ManagerNotifier » offrant la possibilité d'envoyer des emails au manager de l'entrepôt (utilisation de l'API JavaMail)
* Un moteur de règles basé sur Drools pour implémenter une logique métier

Les différents modules étant des bundles OSGi, les systèmes devront tourner sur une plateforme OSGi.

==Fonctionnalités prévues et fonctionnalités réalisées==
L'objectif de ce projet était de réaliser les fonctionnalités suivantes :
* Ajouter un produit grâce à un lecteur NFC
* Ajouter un produit grâce à une scanette
* Retirer des produits du stock grâce à un lecteur NFC
* Retirer des produits du stock grâce à une scanette
* Stocker les informations des produits dans une base de données
* Interagir avec la base de données
* Envoyer un mail au manager en cas de stock faible d'un produit
* Envoyer un mail au manager pour l'informer des variations de stock sur une période donnée

Toutes les fonctionnalités ont été réalisées excepté l'envoi d'un mail au manager pour l'informer des variations de stock.

==Evolutions envisageables==

L'architecture a été pensée de manière à pouvoir facilement ajouter des modules supplémentaires pour interagir avec les « Reader », en plus de l'interface graphique déjà présente. Par exemple une console web, une interface en ligne de commmande ou une interface orientée smartphone (ce qui n'est pas le cas de l'interface actuelle)

Notre système permet la gestion de bouteilles de vin. Il aurait cependant été intéressant d'offrir au manager la possibilité de gérer d'autres produits en lui proposant une gestion générique des produits stockés.

Le moteur de règles pourrait être exploité d'une meilleure manière, de nouvelles règles plus élaborées pourraient être créées.

Permettre à l'utilisateur de configurer les éventuelles options d'un modules (Mail du manager, serveur de messagerie, url et port du serveur, …)

==Difficultés rencontrées==

Nous avons été confrontés à de nombreux problèmes de dépendances, il a fallut en effet trouver les bundles nécessaires au bon fonctionnement de notre système.

L'implémentation d'un moteur de règles est complexe et nécessite la compréhension de certains aspects non triviaux.

Nous avons rencontrés de nombreuses difficultés avec le lecteur NFC ainsi que sa librairie.

==Apports personnels==

Ce projet nous a permis d'améliorer nos compétences dans les domaines suivants :
* Utilisation d'une plateforme OSGi
* Création de bundles OSGi (Notamment avec iPOJO)
* Utilisation de Drools
* Utilisation de REST

==Manuel d'installation==

Les sources du projet sont disponibles sur le svn suivant :
https://subversion.assembla.com/svn/M2M-warehouse/

Notre projet est un projet Maven, il est donc nécessaire de le compiler grâce à cet outil. Le projet est découpé en trois modules distincts (TagSystem, BarcodeSystem, WarehouseServer) qu'il est possible de compiler séparément.
Les bundles générés doivent être déployés sur une plateforme OSGi (Par exemple Felix)

Le deploiement des bundles du projet nécessite des services fournis par d'autres bundles. Ces bundles nécessaires sont téléchargeables sur le svn dans le dossier Bundles présent à la racine du dépôt.

===Installation du lecteur NFC (Tikitag)===

Pour utiliser le lecteur NFC il est nécessaire d'installer les librairies suivantes :
* libccid
* pcscd
* pcsc-tools
* libpcsclite1
* libpcsclite-dev

===Installation de la scanette===
La scanette ne demande pas d'installation particulière, il suffit seulement de la brancher à un port USB.

===Base de données===
La base de données doit être une base MySQL, car nous avons choisi ce type de base pour implementer le WarehouseManager. Cette base doit contenir une table VINS. Cette table peut être créée à l'aide de la requête suivante :
create table VINS (idVin integer auto_increment, name varchar(256), year integer, color varchar(10), price float, quantity integer, tag varchar(30),
barcode varchar(30), primary key (idVin));

===Configuration Felix===

Nous avons du modifier le fichier de configuration de Felix pour exporter certaines classes afin qu'elles soient chargées par défaut par le système. Notre fichier est disponible sur le svn.

==Manuel Utilisateur==

L'utilisation de notre système est assez simple, que ce soit pour une utilisation avec la scanette ou le lecteur NFC elle se fait à travers l'interface. Cette interface permet à l'utilisateur de modifier la quantité d'un produit en ajoutant ou retirant une quantité choisie. Elle permet également d'ajouter un nouveau produit qui n'existerai pas dans la base.

Modification de la quantité d'un vin :
* Sélectionner l'action : Ajouter ou Supprimer
* Saisir la quantité à ajouter ou retirer
* Scanner le produit avec le lecteur NFC ou la scanette
* Valider le scan
* Le produit existe :
** Les informations et la nouvelle quantité pour le produit sont affichées
* Le produit n'existe pas :
** Compléter les informations concernant le produit dans le panel apparu
** Valider les informations entrées
*Possibilité de passer à un nouveau produit en recommençant la procédure

ECOM Warehouse Management System

2012-04-06T00:09:36Z

Damontp: /* Manuel Installation */

* Enseignant : Didier Donsez
* Etudiants M2PGI : CASAGRANDE Thierry, RICHARD David

==Matériel==
* RFID + QRCode + Barcode 1D
* USB Barcode reader
* USB NFC Reader

==Logiciels==
* Apache Felix
* Drools Expert

==Introduction==

Ce projet a pour but de fournir un système permettant la gestion d'un entrepôt. Le système doit gérer les entrées et sorties de produits. Un moteur de règles permettra d'analyser les différentes opérations et pour certains évènements particuliers (par exemple un produit bientôt en rupture de stock) le manager sera notifié.
Les mouvements de stock seront effectués à l'aide d'une scanette et d'un lecteur NFC.
Nous avons choisi de gérer un stockage de bouteilles de vins.

==Architecture==

Notre système se compose de trois parties :
Le "Tag System" qui permet d'utiliser le lecteur NFC pour communiquer avec le server de l'entrepôt
Le "Barcode System" qui permet d'utiliser une scanette pour communiquer avec le server de l'entrepôt
Le "Warehouse Server" qui permet de gérer l'entrepôt

[[Image:Architecture_V2.jpg|Architecture]]

Tag System et Barcode System sont tout deux composés de deux modules :
* Un module « Reader » (TagReader et BarcodeReader) qui permet de scanner les objets et de communiquer avec le serveur grâce à des requêtes REST
* Un module « GUI » (TagGUI et BarcodeGUI) qui offre une interface en Swing pour utiliser le module « Reader »

Warehouse Server :
* Une base de données pour stocker les informations des produits de l'entrepôt
* Un module « WarehouseManager » permettant d'effectuer des opérations sur la base de données
* Deux modules « Solver » (TagSolver et BarcodeSolver) exposant des services REST afin de récuperer les informations envoyées par les « Readers », les analyser et effectuer l'opération requise
* Un module « ManagerNotifier » offrant la possibilité d'envoyer des emails au manager de l'entrepôt (utilisation de l'API JavaMail)
* Un moteur de règles basé sur Drools pour implémenter une logique métier

Les différents modules étant des bundles OSGi, les systèmes devront tourner sur une plateforme OSGi.

==Fonctionnalités prévues et fonctionnalités réalisées==
L'objectif de ce projet était de réaliser les fonctionnalités suivantes :
* Ajouter un produit grâce à un lecteur NFC
* Ajouter un produit grâce à une scanette
* Retirer des produits du stock grâce à un lecteur NFC
* Retirer des produits du stock grâce à une scanette
* Stocker les informations des produits dans une base de données
* Interagir avec la base de données
* Envoyer un mail au manager en cas de stock faible d'un produit
* Envoyer un mail au manager pour l'informer des variations de stock sur une période donnée

Toutes les fonctionnalités ont été réalisées excepté l'envoi d'un mail au manager pour l'informer des variations de stock.

==Evolutions envisageables==

L'architecture a été pensée de manière à pouvoir facilement ajouter des modules supplémentaires pour interagir avec les « Reader », en plus de l'interface graphique déjà présente. Par exemple une console web, une interface en ligne de commmande ou une interface orientée smartphone (ce qui n'est pas le cas de l'interface actuelle)

Notre système permet la gestion de bouteilles de vin. Il aurait cependant été intéressant d'offrir au manager la possibilité de gérer d'autres produits en lui proposant une gestion générique des produits stockés.

Le moteur de règles pourrait être exploité d'une meilleure manière, de nouvelles règles plus élaborées pourraient être créées.

Permettre à l'utilisateur de configurer les éventuelles options d'un modules (Mail du manager, serveur de messagerie, url et port du serveur, …)

==Difficultés rencontrées==

Nous avons été confrontés à de nombreux problèmes de dépendances, il a fallut en effet trouver les bundles nécessaires au bon fonctionnement de notre système.

L'implémentation d'un moteur de règles est complexe et nécessite la compréhension de certains aspects non triviaux.

Nous avons rencontrés de nombreuses difficultés avec le lecteur NFC ainsi que sa librairie.

==Apports personnels==

Ce projet nous a permis d'améliorer nos compétences dans les domaines suivants :
* Utilisation d'une plateforme OSGi
* Création de bundles OSGi (Notamment avec iPOJO)
* Utilisation de Drools
* Utilisation de REST

==Manuel d'nstallation==

Les sources du projet sont disponibles sur le svn suivant :
https://subversion.assembla.com/svn/M2M-warehouse/

Notre projet est un projet Maven, il est donc nécessaire de le compiler grâce à cet outil. Le projet est découpé en trois modules distincts (TagSystem, BarcodeSystem, WarehouseServer) qu'il est possible de compiler séparément.
Les bundles générés doivent être déployés sur une plateforme OSGi (Par exemple Felix)

Le deploiement des bundles du projet nécessite des services fournis par d'autres bundles. Ces bundles nécessaires sont téléchargeables sur le svn dans le dossier Bundles présent à la racine du dépôt.

===Installation du lecteur NFC (Tikitag)===

Pour utiliser le lecteur NFC il est nécessaire d'installer les librairies suivantes :
* libccid
* pcscd
* pcsc-tools
* libpcsclite1
* libpcsclite-dev

===Installation de la scanette===
La scanette ne demande pas d'installation particulière, il suffit seulement de la brancher à un port USB.

===Base de données===
La base de données doit être une base MySQL, car nous avons choisi ce type de base pour implementer le WarehouseManager. Cette base doit contenir une table VINS. Cette table peut être créée à l'aide de la requête suivante :
create table VINS (idVin integer auto_increment, name varchar(256), year integer, color varchar(10), price float, quantity integer, tag varchar(30),
barcode varchar(30), primary key (idVin));

===Configuration Felix===

Nous avons du modifier le fichier de configuration de Felix pour exporter certaines classes afin qu'elles soient chargées par défaut par le système. Notre fichier est disponible sur le svn.

==Manuel Utilisateur==

L'utilisation de notre système est assez simple, que ce soit pour une utilisation avec la scanette ou le lecteur NFC elle se fait à travers l'interface. Cette interface permet à l'utilisateur de modifier la quantité d'un produit en ajoutant ou retirant une quantité choisie. Elle permet également d'ajouter un nouveau produit qui n'existerai pas dans la base.

Modification de la quantité d'un vin :
* Sélectionner l'action : Ajouter ou Supprimer
* Saisir la quantité à ajouter ou retirer
* Scanner le produit avec le lecteur NFC ou la scanette
* Valider le scan
* Le produit existe :
** Les informations et la nouvelle quantité pour le produit sont affichées
* Le produit n'existe pas :
** Compléter les informations concernant le produit dans le panel apparu
** Valider les informations entrées
*Possibilité de passer à un nouveau produit en recommençant la procédure

ECOM Warehouse Management System

2012-04-06T00:08:03Z

Damontp: /* Apports personnels */

* Enseignant : Didier Donsez
* Etudiants M2PGI : CASAGRANDE Thierry, RICHARD David

==Matériel==
* RFID + QRCode + Barcode 1D
* USB Barcode reader
* USB NFC Reader

==Logiciels==
* Apache Felix
* Drools Expert

==Introduction==

Ce projet a pour but de fournir un système permettant la gestion d'un entrepôt. Le système doit gérer les entrées et sorties de produits. Un moteur de règles permettra d'analyser les différentes opérations et pour certains évènements particuliers (par exemple un produit bientôt en rupture de stock) le manager sera notifié.
Les mouvements de stock seront effectués à l'aide d'une scanette et d'un lecteur NFC.
Nous avons choisi de gérer un stockage de bouteilles de vins.

==Architecture==

Notre système se compose de trois parties :
Le "Tag System" qui permet d'utiliser le lecteur NFC pour communiquer avec le server de l'entrepôt
Le "Barcode System" qui permet d'utiliser une scanette pour communiquer avec le server de l'entrepôt
Le "Warehouse Server" qui permet de gérer l'entrepôt

[[Image:Architecture_V2.jpg|Architecture]]

Tag System et Barcode System sont tout deux composés de deux modules :
* Un module « Reader » (TagReader et BarcodeReader) qui permet de scanner les objets et de communiquer avec le serveur grâce à des requêtes REST
* Un module « GUI » (TagGUI et BarcodeGUI) qui offre une interface en Swing pour utiliser le module « Reader »

Warehouse Server :
* Une base de données pour stocker les informations des produits de l'entrepôt
* Un module « WarehouseManager » permettant d'effectuer des opérations sur la base de données
* Deux modules « Solver » (TagSolver et BarcodeSolver) exposant des services REST afin de récuperer les informations envoyées par les « Readers », les analyser et effectuer l'opération requise
* Un module « ManagerNotifier » offrant la possibilité d'envoyer des emails au manager de l'entrepôt (utilisation de l'API JavaMail)
* Un moteur de règles basé sur Drools pour implémenter une logique métier

Les différents modules étant des bundles OSGi, les systèmes devront tourner sur une plateforme OSGi.

==Fonctionnalités prévues et fonctionnalités réalisées==
L'objectif de ce projet était de réaliser les fonctionnalités suivantes :
* Ajouter un produit grâce à un lecteur NFC
* Ajouter un produit grâce à une scanette
* Retirer des produits du stock grâce à un lecteur NFC
* Retirer des produits du stock grâce à une scanette
* Stocker les informations des produits dans une base de données
* Interagir avec la base de données
* Envoyer un mail au manager en cas de stock faible d'un produit
* Envoyer un mail au manager pour l'informer des variations de stock sur une période donnée

Toutes les fonctionnalités ont été réalisées excepté l'envoi d'un mail au manager pour l'informer des variations de stock.

==Evolutions envisageables==

L'architecture a été pensée de manière à pouvoir facilement ajouter des modules supplémentaires pour interagir avec les « Reader », en plus de l'interface graphique déjà présente. Par exemple une console web, une interface en ligne de commmande ou une interface orientée smartphone (ce qui n'est pas le cas de l'interface actuelle)

Notre système permet la gestion de bouteilles de vin. Il aurait cependant été intéressant d'offrir au manager la possibilité de gérer d'autres produits en lui proposant une gestion générique des produits stockés.

Le moteur de règles pourrait être exploité d'une meilleure manière, de nouvelles règles plus élaborées pourraient être créées.

Permettre à l'utilisateur de configurer les éventuelles options d'un modules (Mail du manager, serveur de messagerie, url et port du serveur, …)

==Difficultés rencontrées==

Nous avons été confrontés à de nombreux problèmes de dépendances, il a fallut en effet trouver les bundles nécessaires au bon fonctionnement de notre système.

L'implémentation d'un moteur de règles est complexe et nécessite la compréhension de certains aspects non triviaux.

Nous avons rencontrés de nombreuses difficultés avec le lecteur NFC ainsi que sa librairie.

==Apports personnels==

Ce projet nous a permis d'améliorer nos compétences dans les domaines suivants :
* Utilisation d'une plateforme OSGi
* Création de bundles OSGi (Notamment avec iPOJO)
* Utilisation de Drools
* Utilisation de REST

==Manuel Installation==

Les sources du projet sont disponibles sur le svn suivant :
https://subversion.assembla.com/svn/M2M-warehouse/

Notre projet est un projet Maven, il est donc nécessaire de le compiler grâce à cet outil. Le projet est découpé en trois modules distincts (TagSystem, BarcodeSystem, WarehouseServer) qu'il est possible de compiler séparément.
Les bundles générés doivent être déployés sur une plateforme OSGi (Par exemple Felix)

Le deploiement des bundles du projet nécessite des services fournis par d'autres bundles. Ces bundles nécessaires sont téléchargeables sur le svn dans le dossier Bundles présent à la racine du dépôt.

===Installation du lecteur NFC (Tikitag)===

Pour utiliser le lecteur NFC il est nécessaire d'installer les librairies suivantes :
* libccid
* pcscd
* pcsc-tools
* libpcsclite1
* libpcsclite-dev

===Installation de la scanette===
La scanette ne demande pas d'installation particulière, il suffit seulement de la brancher à un port USB.

===Base de données===
La base de données doit être une base MySQL, car nous avons choisi ce type de base pour implementer le WarehouseManager. Cette base doit contenir une table VINS. Cette table peut être créée à l'aide de la requête suivante :
create table VINS (idVin integer auto_increment, name varchar(256), year integer, color varchar(10), price float, quantity integer, tag varchar(30),
barcode varchar(30), primary key (idVin));

===Configuration Felix===

Nous avons du modifier le fichier de configuration de Felix pour exporter certaines classes afin qu'elles soient chargées par défaut par le système. Notre fichier est disponible sur le svn.

==Manuel Utilisateur==

L'utilisation de notre système est assez simple, que ce soit pour une utilisation avec la scanette ou le lecteur NFC elle se fait à travers l'interface. Cette interface permet à l'utilisateur de modifier la quantité d'un produit en ajoutant ou retirant une quantité choisie. Elle permet également d'ajouter un nouveau produit qui n'existerai pas dans la base.

Modification de la quantité d'un vin :
* Sélectionner l'action : Ajouter ou Supprimer
* Saisir la quantité à ajouter ou retirer
* Scanner le produit avec le lecteur NFC ou la scanette
* Valider le scan
* Le produit existe :
** Les informations et la nouvelle quantité pour le produit sont affichées
* Le produit n'existe pas :
** Compléter les informations concernant le produit dans le panel apparu
** Valider les informations entrées
*Possibilité de passer à un nouveau produit en recommençant la procédure

ECOM Warehouse Management System

2012-04-06T00:05:18Z

Damontp: /* Difficultés rencontrées */

* Enseignant : Didier Donsez
* Etudiants M2PGI : CASAGRANDE Thierry, RICHARD David

==Matériel==
* RFID + QRCode + Barcode 1D
* USB Barcode reader
* USB NFC Reader

==Logiciels==
* Apache Felix
* Drools Expert

==Introduction==

Ce projet a pour but de fournir un système permettant la gestion d'un entrepôt. Le système doit gérer les entrées et sorties de produits. Un moteur de règles permettra d'analyser les différentes opérations et pour certains évènements particuliers (par exemple un produit bientôt en rupture de stock) le manager sera notifié.
Les mouvements de stock seront effectués à l'aide d'une scanette et d'un lecteur NFC.
Nous avons choisi de gérer un stockage de bouteilles de vins.

==Architecture==

Notre système se compose de trois parties :
Le "Tag System" qui permet d'utiliser le lecteur NFC pour communiquer avec le server de l'entrepôt
Le "Barcode System" qui permet d'utiliser une scanette pour communiquer avec le server de l'entrepôt
Le "Warehouse Server" qui permet de gérer l'entrepôt

[[Image:Architecture_V2.jpg|Architecture]]

Tag System et Barcode System sont tout deux composés de deux modules :
* Un module « Reader » (TagReader et BarcodeReader) qui permet de scanner les objets et de communiquer avec le serveur grâce à des requêtes REST
* Un module « GUI » (TagGUI et BarcodeGUI) qui offre une interface en Swing pour utiliser le module « Reader »

Warehouse Server :
* Une base de données pour stocker les informations des produits de l'entrepôt
* Un module « WarehouseManager » permettant d'effectuer des opérations sur la base de données
* Deux modules « Solver » (TagSolver et BarcodeSolver) exposant des services REST afin de récuperer les informations envoyées par les « Readers », les analyser et effectuer l'opération requise
* Un module « ManagerNotifier » offrant la possibilité d'envoyer des emails au manager de l'entrepôt (utilisation de l'API JavaMail)
* Un moteur de règles basé sur Drools pour implémenter une logique métier

Les différents modules étant des bundles OSGi, les systèmes devront tourner sur une plateforme OSGi.

==Fonctionnalités prévues et fonctionnalités réalisées==
L'objectif de ce projet était de réaliser les fonctionnalités suivantes :
* Ajouter un produit grâce à un lecteur NFC
* Ajouter un produit grâce à une scanette
* Retirer des produits du stock grâce à un lecteur NFC
* Retirer des produits du stock grâce à une scanette
* Stocker les informations des produits dans une base de données
* Interagir avec la base de données
* Envoyer un mail au manager en cas de stock faible d'un produit
* Envoyer un mail au manager pour l'informer des variations de stock sur une période donnée

Toutes les fonctionnalités ont été réalisées excepté l'envoi d'un mail au manager pour l'informer des variations de stock.

==Evolutions envisageables==

L'architecture a été pensée de manière à pouvoir facilement ajouter des modules supplémentaires pour interagir avec les « Reader », en plus de l'interface graphique déjà présente. Par exemple une console web, une interface en ligne de commmande ou une interface orientée smartphone (ce qui n'est pas le cas de l'interface actuelle)

Notre système permet la gestion de bouteilles de vin. Il aurait cependant été intéressant d'offrir au manager la possibilité de gérer d'autres produits en lui proposant une gestion générique des produits stockés.

Le moteur de règles pourrait être exploité d'une meilleure manière, de nouvelles règles plus élaborées pourraient être créées.

Permettre à l'utilisateur de configurer les éventuelles options d'un modules (Mail du manager, serveur de messagerie, url et port du serveur, …)

==Difficultés rencontrées==

Nous avons été confrontés à de nombreux problèmes de dépendances, il a fallut en effet trouver les bundles nécessaires au bon fonctionnement de notre système.

L'implémentation d'un moteur de règles est complexe et nécessite la compréhension de certains aspects non triviaux.

Nous avons rencontrés de nombreuses difficultés avec le lecteur NFC ainsi que sa librairie.

==Apports personnels==

Ce projet nous a apporté de nouvelles compétences :
* Utilisation d'une plateforme OSGi
* Création de bundles OSGi (Notamment avec iPOJO)
* Utilisation de Drools
* Utilisation de REST

==Manuel Installation==

Les sources du projet sont disponibles sur le svn suivant :
https://subversion.assembla.com/svn/M2M-warehouse/

Notre projet est un projet Maven, il est donc nécessaire de le compiler grâce à cet outil. Le projet est découpé en trois modules distincts (TagSystem, BarcodeSystem, WarehouseServer) qu'il est possible de compiler séparément.
Les bundles générés doivent être déployés sur une plateforme OSGi (Par exemple Felix)

Le deploiement des bundles du projet nécessite des services fournis par d'autres bundles. Ces bundles nécessaires sont téléchargeables sur le svn dans le dossier Bundles présent à la racine du dépôt.

===Installation du lecteur NFC (Tikitag)===

Pour utiliser le lecteur NFC il est nécessaire d'installer les librairies suivantes :
* libccid
* pcscd
* pcsc-tools
* libpcsclite1
* libpcsclite-dev

===Installation de la scanette===
La scanette ne demande pas d'installation particulière, il suffit seulement de la brancher à un port USB.

===Base de données===
La base de données doit être une base MySQL, car nous avons choisi ce type de base pour implementer le WarehouseManager. Cette base doit contenir une table VINS. Cette table peut être créée à l'aide de la requête suivante :
create table VINS (idVin integer auto_increment, name varchar(256), year integer, color varchar(10), price float, quantity integer, tag varchar(30),
barcode varchar(30), primary key (idVin));

===Configuration Felix===

Nous avons du modifier le fichier de configuration de Felix pour exporter certaines classes afin qu'elles soient chargées par défaut par le système. Notre fichier est disponible sur le svn.

==Manuel Utilisateur==

L'utilisation de notre système est assez simple, que ce soit pour une utilisation avec la scanette ou le lecteur NFC elle se fait à travers l'interface. Cette interface permet à l'utilisateur de modifier la quantité d'un produit en ajoutant ou retirant une quantité choisie. Elle permet également d'ajouter un nouveau produit qui n'existerai pas dans la base.

Modification de la quantité d'un vin :
* Sélectionner l'action : Ajouter ou Supprimer
* Saisir la quantité à ajouter ou retirer
* Scanner le produit avec le lecteur NFC ou la scanette
* Valider le scan
* Le produit existe :
** Les informations et la nouvelle quantité pour le produit sont affichées
* Le produit n'existe pas :
** Compléter les informations concernant le produit dans le panel apparu
** Valider les informations entrées
*Possibilité de passer à un nouveau produit en recommençant la procédure

ECOM Warehouse Management System

2012-04-05T23:58:05Z

Damontp: /* Fonctionnalités prévues et fonctionnalités réalisées */

* Enseignant : Didier Donsez
* Etudiants M2PGI : CASAGRANDE Thierry, RICHARD David

==Matériel==
* RFID + QRCode + Barcode 1D
* USB Barcode reader
* USB NFC Reader

==Logiciels==
* Apache Felix
* Drools Expert

==Introduction==

Ce projet a pour but de fournir un système permettant la gestion d'un entrepôt. Le système doit gérer les entrées et sorties de produits. Un moteur de règles permettra d'analyser les différentes opérations et pour certains évènements particuliers (par exemple un produit bientôt en rupture de stock) le manager sera notifié.
Les mouvements de stock seront effectués à l'aide d'une scanette et d'un lecteur NFC.
Nous avons choisi de gérer un stockage de bouteilles de vins.

==Architecture==

Notre système se compose de trois parties :
Le "Tag System" qui permet d'utiliser le lecteur NFC pour communiquer avec le server de l'entrepôt
Le "Barcode System" qui permet d'utiliser une scanette pour communiquer avec le server de l'entrepôt
Le "Warehouse Server" qui permet de gérer l'entrepôt

[[Image:Architecture_V2.jpg|Architecture]]

Tag System et Barcode System sont tout deux composés de deux modules :
* Un module « Reader » (TagReader et BarcodeReader) qui permet de scanner les objets et de communiquer avec le serveur grâce à des requêtes REST
* Un module « GUI » (TagGUI et BarcodeGUI) qui offre une interface en Swing pour utiliser le module « Reader »

Warehouse Server :
* Une base de données pour stocker les informations des produits de l'entrepôt
* Un module « WarehouseManager » permettant d'effectuer des opérations sur la base de données
* Deux modules « Solver » (TagSolver et BarcodeSolver) exposant des services REST afin de récuperer les informations envoyées par les « Readers », les analyser et effectuer l'opération requise
* Un module « ManagerNotifier » offrant la possibilité d'envoyer des emails au manager de l'entrepôt (utilisation de l'API JavaMail)
* Un moteur de règles basé sur Drools pour implémenter une logique métier

Les différents modules étant des bundles OSGi, les systèmes devront tourner sur une plateforme OSGi.

==Fonctionnalités prévues et fonctionnalités réalisées==
L'objectif de ce projet était de réaliser les fonctionnalités suivantes :
* Ajouter un produit grâce à un lecteur NFC
* Ajouter un produit grâce à une scanette
* Retirer des produits du stock grâce à un lecteur NFC
* Retirer des produits du stock grâce à une scanette
* Stocker les informations des produits dans une base de données
* Interagir avec la base de données
* Envoyer un mail au manager en cas de stock faible d'un produit
* Envoyer un mail au manager pour l'informer des variations de stock sur une période donnée

Toutes les fonctionnalités ont été réalisées excepté l'envoi d'un mail au manager pour l'informer des variations de stock.

==Evolutions envisageables==

L'architecture a été pensée de manière à pouvoir facilement ajouter des modules supplémentaires pour interagir avec les « Reader », en plus de l'interface graphique déjà présente. Par exemple une console web, une interface en ligne de commmande ou une interface orientée smartphone (ce qui n'est pas le cas de l'interface actuelle)

Notre système permet la gestion de bouteilles de vin. Il aurait cependant été intéressant d'offrir au manager la possibilité de gérer d'autres produits en lui proposant une gestion générique des produits stockés.

Le moteur de règles pourrait être exploité d'une meilleure manière, de nouvelles règles plus élaborées pourraient être créées.

Permettre à l'utilisateur de configurer les éventuelles options d'un modules (Mail du manager, serveur de messagerie, url et port du serveur, …)

==Difficultés rencontrées==

L'architecture a été pensée de manière à pouvoir facilement ajouter des modules supplémentaires pour interagir avec les « Reader », en plus de l'interface graphique déjà présente. Par exemple une console web, une interface en ligne de commmande ou une interface orientée smartphone (ce qui n'est pas le cas de l'interface actuelle).

Notre système permet la gestion de bouteilles de vin. Il aurait cependant été intéressant d'offrir au manager la possibilité de gérer d'autres produits en lui proposant une gestion générique des produits stockés.

Le moteur de règles pourrait être exploité d'une meilleure manière, de nouvelles règles plus élaborées pourraient être créées.

Permettre à l'utilisateur de configurer les éventuelles options d'un modules (Mail du manager, serveur de messagerie, url et port du serveur, …)

==Apports personnels==

Ce projet nous a apporté de nouvelles compétences :
* Utilisation d'une plateforme OSGi
* Création de bundles OSGi (Notamment avec iPOJO)
* Utilisation de Drools
* Utilisation de REST

==Manuel Installation==

Les sources du projet sont disponibles sur le svn suivant :
https://subversion.assembla.com/svn/M2M-warehouse/

Notre projet est un projet Maven, il est donc nécessaire de le compiler grâce à cet outil. Le projet est découpé en trois modules distincts (TagSystem, BarcodeSystem, WarehouseServer) qu'il est possible de compiler séparément.
Les bundles générés doivent être déployés sur une plateforme OSGi (Par exemple Felix)

Le deploiement des bundles du projet nécessite des services fournis par d'autres bundles. Ces bundles nécessaires sont téléchargeables sur le svn dans le dossier Bundles présent à la racine du dépôt.

===Installation du lecteur NFC (Tikitag)===

Pour utiliser le lecteur NFC il est nécessaire d'installer les librairies suivantes :
* libccid
* pcscd
* pcsc-tools
* libpcsclite1
* libpcsclite-dev

===Installation de la scanette===
La scanette ne demande pas d'installation particulière, il suffit seulement de la brancher à un port USB.

===Base de données===
La base de données doit être une base MySQL, car nous avons choisi ce type de base pour implementer le WarehouseManager. Cette base doit contenir une table VINS. Cette table peut être créée à l'aide de la requête suivante :
create table VINS (idVin integer auto_increment, name varchar(256), year integer, color varchar(10), price float, quantity integer, tag varchar(30),
barcode varchar(30), primary key (idVin));

===Configuration Felix===

Nous avons du modifier le fichier de configuration de Felix pour exporter certaines classes afin qu'elles soient chargées par défaut par le système. Notre fichier est disponible sur le svn.

==Manuel Utilisateur==

L'utilisation de notre système est assez simple, que ce soit pour une utilisation avec la scanette ou le lecteur NFC elle se fait à travers l'interface. Cette interface permet à l'utilisateur de modifier la quantité d'un produit en ajoutant ou retirant une quantité choisie. Elle permet également d'ajouter un nouveau produit qui n'existerai pas dans la base.

Modification de la quantité d'un vin :
* Sélectionner l'action : Ajouter ou Supprimer
* Saisir la quantité à ajouter ou retirer
* Scanner le produit avec le lecteur NFC ou la scanette
* Valider le scan
* Le produit existe :
** Les informations et la nouvelle quantité pour le produit sont affichées
* Le produit n'existe pas :
** Compléter les informations concernant le produit dans le panel apparu
** Valider les informations entrées
*Possibilité de passer à un nouveau produit en recommençant la procédure

ECOM Warehouse Management System

2012-04-05T23:56:12Z

Damontp: /* Fonctionnalités prévues et fonctionnalités réalisées */

* Enseignant : Didier Donsez
* Etudiants M2PGI : CASAGRANDE Thierry, RICHARD David

==Matériel==
* RFID + QRCode + Barcode 1D
* USB Barcode reader
* USB NFC Reader

==Logiciels==
* Apache Felix
* Drools Expert

==Introduction==

Ce projet a pour but de fournir un système permettant la gestion d'un entrepôt. Le système doit gérer les entrées et sorties de produits. Un moteur de règles permettra d'analyser les différentes opérations et pour certains évènements particuliers (par exemple un produit bientôt en rupture de stock) le manager sera notifié.
Les mouvements de stock seront effectués à l'aide d'une scanette et d'un lecteur NFC.
Nous avons choisi de gérer un stockage de bouteilles de vins.

==Architecture==

Notre système se compose de trois parties :
Le "Tag System" qui permet d'utiliser le lecteur NFC pour communiquer avec le server de l'entrepôt
Le "Barcode System" qui permet d'utiliser une scanette pour communiquer avec le server de l'entrepôt
Le "Warehouse Server" qui permet de gérer l'entrepôt

[[Image:Architecture_V2.jpg|Architecture]]

Tag System et Barcode System sont tout deux composés de deux modules :
* Un module « Reader » (TagReader et BarcodeReader) qui permet de scanner les objets et de communiquer avec le serveur grâce à des requêtes REST
* Un module « GUI » (TagGUI et BarcodeGUI) qui offre une interface en Swing pour utiliser le module « Reader »

Warehouse Server :
* Une base de données pour stocker les informations des produits de l'entrepôt
* Un module « WarehouseManager » permettant d'effectuer des opérations sur la base de données
* Deux modules « Solver » (TagSolver et BarcodeSolver) exposant des services REST afin de récuperer les informations envoyées par les « Readers », les analyser et effectuer l'opération requise
* Un module « ManagerNotifier » offrant la possibilité d'envoyer des emails au manager de l'entrepôt (utilisation de l'API JavaMail)
* Un moteur de règles basé sur Drools pour implémenter une logique métier

Les différents modules étant des bundles OSGi, les systèmes devront tourner sur une plateforme OSGi.

==Fonctionnalités prévues et fonctionnalités réalisées==
L'objectif de ce projet était de réaliser les fonctionnalités suivantes :
* Ajouter un produit grâce à un lecteur NFC
* Ajouter un produit grâce à une scanette
* Retirer des produits du stock grâce à un lecteur NFC
* Retirer des produits du stock grâce à une scanette
* Envoyer un mail au manager en cas de stock faible d'un produit
* Envoyer un mail au manager pour l'informer des variations de stock sur une période donnée
* Stocker les informations des produits dans une base de données
* Interagir avec la base de données

Toutes les fonctionnalités ont été réalisées excepté l'envoi d'un mail au manager pour l'informer des variations de stock.

==Evolutions envisageables==

L'architecture a été pensée de manière à pouvoir facilement ajouter des modules supplémentaires pour interagir avec les « Reader », en plus de l'interface graphique déjà présente. Par exemple une console web, une interface en ligne de commmande ou une interface orientée smartphone (ce qui n'est pas le cas de l'interface actuelle)

Notre système permet la gestion de bouteilles de vin. Il aurait cependant été intéressant d'offrir au manager la possibilité de gérer d'autres produits en lui proposant une gestion générique des produits stockés.

Le moteur de règles pourrait être exploité d'une meilleure manière, de nouvelles règles plus élaborées pourraient être créées.

Permettre à l'utilisateur de configurer les éventuelles options d'un modules (Mail du manager, serveur de messagerie, url et port du serveur, …)

==Difficultés rencontrées==

L'architecture a été pensée de manière à pouvoir facilement ajouter des modules supplémentaires pour interagir avec les « Reader », en plus de l'interface graphique déjà présente. Par exemple une console web, une interface en ligne de commmande ou une interface orientée smartphone (ce qui n'est pas le cas de l'interface actuelle).

Notre système permet la gestion de bouteilles de vin. Il aurait cependant été intéressant d'offrir au manager la possibilité de gérer d'autres produits en lui proposant une gestion générique des produits stockés.

Le moteur de règles pourrait être exploité d'une meilleure manière, de nouvelles règles plus élaborées pourraient être créées.

Permettre à l'utilisateur de configurer les éventuelles options d'un modules (Mail du manager, serveur de messagerie, url et port du serveur, …)

==Apports personnels==

Ce projet nous a apporté de nouvelles compétences :
* Utilisation d'une plateforme OSGi
* Création de bundles OSGi (Notamment avec iPOJO)
* Utilisation de Drools
* Utilisation de REST

==Manuel Installation==

Les sources du projet sont disponibles sur le svn suivant :
https://subversion.assembla.com/svn/M2M-warehouse/

Notre projet est un projet Maven, il est donc nécessaire de le compiler grâce à cet outil. Le projet est découpé en trois modules distincts (TagSystem, BarcodeSystem, WarehouseServer) qu'il est possible de compiler séparément.
Les bundles générés doivent être déployés sur une plateforme OSGi (Par exemple Felix)

Le deploiement des bundles du projet nécessite des services fournis par d'autres bundles. Ces bundles nécessaires sont téléchargeables sur le svn dans le dossier Bundles présent à la racine du dépôt.

===Installation du lecteur NFC (Tikitag)===

Pour utiliser le lecteur NFC il est nécessaire d'installer les librairies suivantes :
* libccid
* pcscd
* pcsc-tools
* libpcsclite1
* libpcsclite-dev

===Installation de la scanette===
La scanette ne demande pas d'installation particulière, il suffit seulement de la brancher à un port USB.

===Base de données===
La base de données doit être une base MySQL, car nous avons choisi ce type de base pour implementer le WarehouseManager. Cette base doit contenir une table VINS. Cette table peut être créée à l'aide de la requête suivante :
create table VINS (idVin integer auto_increment, name varchar(256), year integer, color varchar(10), price float, quantity integer, tag varchar(30),
barcode varchar(30), primary key (idVin));

===Configuration Felix===

Nous avons du modifier le fichier de configuration de Felix pour exporter certaines classes afin qu'elles soient chargées par défaut par le système. Notre fichier est disponible sur le svn.

==Manuel Utilisateur==

L'utilisation de notre système est assez simple, que ce soit pour une utilisation avec la scanette ou le lecteur NFC elle se fait à travers l'interface. Cette interface permet à l'utilisateur de modifier la quantité d'un produit en ajoutant ou retirant une quantité choisie. Elle permet également d'ajouter un nouveau produit qui n'existerai pas dans la base.

Modification de la quantité d'un vin :
* Sélectionner l'action : Ajouter ou Supprimer
* Saisir la quantité à ajouter ou retirer
* Scanner le produit avec le lecteur NFC ou la scanette
* Valider le scan
* Le produit existe :
** Les informations et la nouvelle quantité pour le produit sont affichées
* Le produit n'existe pas :
** Compléter les informations concernant le produit dans le panel apparu
** Valider les informations entrées
*Possibilité de passer à un nouveau produit en recommençant la procédure

ECOM Warehouse Management System

2012-04-05T23:26:24Z

Damontp: /* Evolutions envisageables */

* Enseignant : Didier Donsez
* Etudiants M2PGI : CASAGRANDE Thierry, RICHARD David

==Matériel==
* RFID + QRCode + Barcode 1D
* USB Barcode reader
* USB NFC Reader

==Logiciels==
* Apache Felix
* Drools Expert

==Introduction==

Ce projet a pour but de fournir un système permettant la gestion d'un entrepôt. Le système doit gérer les entrées et sorties de produits. Un moteur de règles permettra d'analyser les différentes opérations et pour certains évènements particuliers (par exemple un produit bientôt en rupture de stock) le manager sera notifié.
Les mouvements de stock seront effectués à l'aide d'une scanette et d'un lecteur NFC.
Nous avons choisi de gérer un stockage de bouteilles de vins.

==Architecture==

Notre système se compose de trois parties :
Le "Tag System" qui permet d'utiliser le lecteur NFC pour communiquer avec le server de l'entrepôt
Le "Barcode System" qui permet d'utiliser une scanette pour communiquer avec le server de l'entrepôt
Le "Warehouse Server" qui permet de gérer l'entrepôt

[[Image:Architecture_V2.jpg|Architecture]]

Tag System et Barcode System sont tout deux composés de deux modules :
* Un module « Reader » (TagReader et BarcodeReader) qui permet de scanner les objets et de communiquer avec le serveur grâce à des requêtes REST
* Un module « GUI » (TagGUI et BarcodeGUI) qui offre une interface en Swing pour utiliser le module « Reader »

Warehouse Server :
* Une base de données pour stocker les informations des produits de l'entrepôt
* Un module « WarehouseManager » permettant d'effectuer des opérations sur la base de données
* Deux modules « Solver » (TagSolver et BarcodeSolver) exposant des services REST afin de récuperer les informations envoyées par les « Readers », les analyser et effectuer l'opération requise
* Un module « ManagerNotifier » offrant la possibilité d'envoyer des emails au manager de l'entrepôt (utilisation de l'API JavaMail)
* Un moteur de règles basé sur Drools pour implémenter une logique métier

Les différents modules étant des bundles OSGi, les systèmes devront tourner sur une plateforme OSGi.

==Fonctionnalités prévues et fonctionnalités réalisées==
L'objectif de ce projet était de réaliser les fonctionnalités suivantes :
* Ajouter un produit grâce à un lecteur NFC
* Ajouter un produit grâce à une scanette
* Retirer des produits du stock grâce à un lecteur NFC
* Retirer des produits du stock grâce à une scanette
* Envoyer un mail au manager en cas de stock faible d'un produit
* Envoyer un mail au manager régulièrement pour l'informer des variations de stock
* Stocker les informations des produits dans une base de données
* Interagir avec la base de données

Toutes les fonctionnalités ont été réalisées excepté l'envoi d'un mail au manager pour l'informer des variations de stock.

==Evolutions envisageables==

L'architecture a été pensée de manière à pouvoir facilement ajouter des modules supplémentaires pour interagir avec les « Reader », en plus de l'interface graphique déjà présente. Par exemple une console web, une interface en ligne de commmande ou une interface orientée smartphone (ce qui n'est pas le cas de l'interface actuelle)

Notre système permet la gestion de bouteilles de vin. Il aurait cependant été intéressant d'offrir au manager la possibilité de gérer d'autres produits en lui proposant une gestion générique des produits stockés.

Le moteur de règles pourrait être exploité d'une meilleure manière, de nouvelles règles plus élaborées pourraient être créées.

Permettre à l'utilisateur de configurer les éventuelles options d'un modules (Mail du manager, serveur de messagerie, url et port du serveur, …)

==Difficultés rencontrées==

L'architecture a été pensée de manière à pouvoir facilement ajouter des modules supplémentaires pour interagir avec les « Reader », en plus de l'interface graphique déjà présente. Par exemple une console web, une interface en ligne de commmande ou une interface orientée smartphone (ce qui n'est pas le cas de l'interface actuelle).

Notre système permet la gestion de bouteilles de vin. Il aurait cependant été intéressant d'offrir au manager la possibilité de gérer d'autres produits en lui proposant une gestion générique des produits stockés.

Le moteur de règles pourrait être exploité d'une meilleure manière, de nouvelles règles plus élaborées pourraient être créées.

Permettre à l'utilisateur de configurer les éventuelles options d'un modules (Mail du manager, serveur de messagerie, url et port du serveur, …)

==Apports personnels==

Ce projet nous a apporté de nouvelles compétences :
* Utilisation d'une plateforme OSGi
* Création de bundles OSGi (Notamment avec iPOJO)
* Utilisation de Drools
* Utilisation de REST

==Manuel Installation==

Les sources du projet sont disponibles sur le svn suivant :
https://subversion.assembla.com/svn/M2M-warehouse/

Notre projet est un projet Maven, il est donc nécessaire de le compiler grâce à cet outil. Le projet est découpé en trois modules distincts (TagSystem, BarcodeSystem, WarehouseServer) qu'il est possible de compiler séparément.
Les bundles générés doivent être déployés sur une plateforme OSGi (Par exemple Felix)

Le deploiement des bundles du projet nécessite des services fournis par d'autres bundles. Ces bundles nécessaires sont téléchargeables sur le svn dans le dossier Bundles présent à la racine du dépôt.

===Installation du lecteur NFC (Tikitag)===

Pour utiliser le lecteur NFC il est nécessaire d'installer les librairies suivantes :
* libccid
* pcscd
* pcsc-tools
* libpcsclite1
* libpcsclite-dev

===Installation de la scanette===
La scanette ne demande pas d'installation particulière, il suffit seulement de la brancher à un port USB.

===Base de données===
La base de données doit être une base MySQL, car nous avons choisi ce type de base pour implementer le WarehouseManager. Cette base doit contenir une table VINS. Cette table peut être créée à l'aide de la requête suivante :
create table VINS (idVin integer auto_increment, name varchar(256), year integer, color varchar(10), price float, quantity integer, tag varchar(30),
barcode varchar(30), primary key (idVin));

===Configuration Felix===

Nous avons du modifier le fichier de configuration de Felix pour exporter certaines classes afin qu'elles soient chargées par défaut par le système. Notre fichier est disponible sur le svn.

==Manuel Utilisateur==

L'utilisation de notre système est assez simple, que ce soit pour une utilisation avec la scanette ou le lecteur NFC elle se fait à travers l'interface. Cette interface permet à l'utilisateur de modifier la quantité d'un produit en ajoutant ou retirant une quantité choisie. Elle permet également d'ajouter un nouveau produit qui n'existerai pas dans la base.

Modification de la quantité d'un vin :
* Sélectionner l'action : Ajouter ou Supprimer
* Saisir la quantité à ajouter ou retirer
* Scanner le produit avec le lecteur NFC ou la scanette
* Valider le scan
* Le produit existe :
** Les informations et la nouvelle quantité pour le produit sont affichées
* Le produit n'existe pas :
** Compléter les informations concernant le produit dans le panel apparu
** Valider les informations entrées
*Possibilité de passer à un nouveau produit en recommençant la procédure

ECOM Warehouse Management System

2012-04-05T23:26:07Z

Damontp:

* Enseignant : Didier Donsez
* Etudiants M2PGI : CASAGRANDE Thierry, RICHARD David

==Matériel==
* RFID + QRCode + Barcode 1D
* USB Barcode reader
* USB NFC Reader

==Logiciels==
* Apache Felix
* Drools Expert

==Introduction==

Ce projet a pour but de fournir un système permettant la gestion d'un entrepôt. Le système doit gérer les entrées et sorties de produits. Un moteur de règles permettra d'analyser les différentes opérations et pour certains évènements particuliers (par exemple un produit bientôt en rupture de stock) le manager sera notifié.
Les mouvements de stock seront effectués à l'aide d'une scanette et d'un lecteur NFC.
Nous avons choisi de gérer un stockage de bouteilles de vins.

==Architecture==

Notre système se compose de trois parties :
Le "Tag System" qui permet d'utiliser le lecteur NFC pour communiquer avec le server de l'entrepôt
Le "Barcode System" qui permet d'utiliser une scanette pour communiquer avec le server de l'entrepôt
Le "Warehouse Server" qui permet de gérer l'entrepôt

[[Image:Architecture_V2.jpg|Architecture]]

Tag System et Barcode System sont tout deux composés de deux modules :
* Un module « Reader » (TagReader et BarcodeReader) qui permet de scanner les objets et de communiquer avec le serveur grâce à des requêtes REST
* Un module « GUI » (TagGUI et BarcodeGUI) qui offre une interface en Swing pour utiliser le module « Reader »

Warehouse Server :
* Une base de données pour stocker les informations des produits de l'entrepôt
* Un module « WarehouseManager » permettant d'effectuer des opérations sur la base de données
* Deux modules « Solver » (TagSolver et BarcodeSolver) exposant des services REST afin de récuperer les informations envoyées par les « Readers », les analyser et effectuer l'opération requise
* Un module « ManagerNotifier » offrant la possibilité d'envoyer des emails au manager de l'entrepôt (utilisation de l'API JavaMail)
* Un moteur de règles basé sur Drools pour implémenter une logique métier

Les différents modules étant des bundles OSGi, les systèmes devront tourner sur une plateforme OSGi.

==Fonctionnalités prévues et fonctionnalités réalisées==
L'objectif de ce projet était de réaliser les fonctionnalités suivantes :
* Ajouter un produit grâce à un lecteur NFC
* Ajouter un produit grâce à une scanette
* Retirer des produits du stock grâce à un lecteur NFC
* Retirer des produits du stock grâce à une scanette
* Envoyer un mail au manager en cas de stock faible d'un produit
* Envoyer un mail au manager régulièrement pour l'informer des variations de stock
* Stocker les informations des produits dans une base de données
* Interagir avec la base de données

Toutes les fonctionnalités ont été réalisées excepté l'envoi d'un mail au manager pour l'informer des variations de stock.

==Evolutions envisageables==

L'architecture a été pensée de manière à pouvoir facilement ajouter des modules supplémentaires pour interagir avec les « Reader », en plus de l'interface graphique déjà présente. Par exemple une console web, une interface en ligne de commmande ou une interface orientée smartphone (ce qui n'est pas le cas de l'interface actuelle)

Notre système permet la gestion de bouteilles de vin. Il aurait cependant été intéressant d'offrir au manager la possibilité de gérer d'autres produits en lui proposant une gestion générique des produits stockés.

Le moteur de règles pourrait être exploité d'une meilleure manière, de nouvelles règles plus élaborées pourraient être créées.

Permettre à l'utilisateur de configurer les éventuelles options d'un modules (Mail du manager, serveur de messagerie, url et port du serveur, …)

==Difficultés rencontrées==

L'architecture a été pensée de manière à pouvoir facilement ajouter des modules supplémentaires pour interagir avec les « Reader », en plus de l'interface graphique déjà présente. Par exemple une console web, une interface en ligne de commmande ou une interface orientée smartphone (ce qui n'est pas le cas de l'interface actuelle).

Notre système permet la gestion de bouteilles de vin. Il aurait cependant été intéressant d'offrir au manager la possibilité de gérer d'autres produits en lui proposant une gestion générique des produits stockés.

Le moteur de règles pourrait être exploité d'une meilleure manière, de nouvelles règles plus élaborées pourraient être créées.

Permettre à l'utilisateur de configurer les éventuelles options d'un modules (Mail du manager, serveur de messagerie, url et port du serveur, …)

==Apports personnels==

Ce projet nous a apporté de nouvelles compétences :
* Utilisation d'une plateforme OSGi
* Création de bundles OSGi (Notamment avec iPOJO)
* Utilisation de Drools
* Utilisation de REST

==Manuel Installation==

Les sources du projet sont disponibles sur le svn suivant :
https://subversion.assembla.com/svn/M2M-warehouse/

Notre projet est un projet Maven, il est donc nécessaire de le compiler grâce à cet outil. Le projet est découpé en trois modules distincts (TagSystem, BarcodeSystem, WarehouseServer) qu'il est possible de compiler séparément.
Les bundles générés doivent être déployés sur une plateforme OSGi (Par exemple Felix)

Le deploiement des bundles du projet nécessite des services fournis par d'autres bundles. Ces bundles nécessaires sont téléchargeables sur le svn dans le dossier Bundles présent à la racine du dépôt.

===Installation du lecteur NFC (Tikitag)===

Pour utiliser le lecteur NFC il est nécessaire d'installer les librairies suivantes :
* libccid
* pcscd
* pcsc-tools
* libpcsclite1
* libpcsclite-dev

===Installation de la scanette===
La scanette ne demande pas d'installation particulière, il suffit seulement de la brancher à un port USB.

===Base de données===
La base de données doit être une base MySQL, car nous avons choisi ce type de base pour implementer le WarehouseManager. Cette base doit contenir une table VINS. Cette table peut être créée à l'aide de la requête suivante :
create table VINS (idVin integer auto_increment, name varchar(256), year integer, color varchar(10), price float, quantity integer, tag varchar(30),
barcode varchar(30), primary key (idVin));

===Configuration Felix===

Nous avons du modifier le fichier de configuration de Felix pour exporter certaines classes afin qu'elles soient chargées par défaut par le système. Notre fichier est disponible sur le svn.

==Manuel Utilisateur==

L'utilisation de notre système est assez simple, que ce soit pour une utilisation avec la scanette ou le lecteur NFC elle se fait à travers l'interface. Cette interface permet à l'utilisateur de modifier la quantité d'un produit en ajoutant ou retirant une quantité choisie. Elle permet également d'ajouter un nouveau produit qui n'existerai pas dans la base.

Modification de la quantité d'un vin :
* Sélectionner l'action : Ajouter ou Supprimer
* Saisir la quantité à ajouter ou retirer
* Scanner le produit avec le lecteur NFC ou la scanette
* Valider le scan
* Le produit existe :
** Les informations et la nouvelle quantité pour le produit sont affichées
* Le produit n'existe pas :
** Compléter les informations concernant le produit dans le panel apparu
** Valider les informations entrées
*Possibilité de passer à un nouveau produit en recommençant la procédure

ECOM Warehouse Management System

2012-04-05T23:11:12Z

Damontp:

* Enseignant : Didier Donsez
* Etudiants M2PGI : CASAGRANDE Thierry, RICHARD David

==Matériel==
* RFID + QRCode + Barcode 1D
* USB Barcode reader
* USB NFC Reader

==Logiciels==
* Apache Felix
* Drools Expert

==Introduction==

Ce projet a pour but de fournir un système permettant la gestion d'un entrepôt. Le système doit gérer les entrées et sorties de produits. Un moteur de règles permettra d'analyser les différentes opérations et pour certains évènements particuliers (par exemple un produit bientôt en rupture de stock) le manager sera notifié.
Les mouvements de stock seront effectués à l'aide d'une scanette et d'un lecteur NFC.
Nous avons choisi de gérer un stockage de bouteilles de vins.

==Architecture==

Notre système se compose de trois parties :
Le "Tag System" qui permet d'utiliser le lecteur NFC pour communiquer avec le server de l'entrepôt
Le "Barcode System" qui permet d'utiliser une scanette pour communiquer avec le server de l'entrepôt
Le "Warehouse Server" qui permet de gérer l'entrepôt

[[Image:Architecture_V2.jpg|Architecture]]

Tag System et Barcode System sont tout deux composés de deux modules :
* Un module « Reader » (TagReader et BarcodeReader) qui permet de scanner les objets et de communiquer avec le serveur grâce à des requêtes REST
* Un module « GUI » (TagGUI et BarcodeGUI) qui offre une interface en Swing pour utiliser le module « Reader »

Warehouse Server :
* Une base de données pour stocker les informations des produits de l'entrepôt
* Un module « WarehouseManager » permettant d'effectuer des opérations sur la base de données
* Deux modules « Solver » (TagSolver et BarcodeSolver) exposant des services REST afin de récuperer les informations envoyées par les « Readers », les analyser et effectuer l'opération requise
* Un module « ManagerNotifier » offrant la possibilité d'envoyer des emails au manager de l'entrepôt (utilisation de l'API JavaMail)
* Un moteur de règles basé sur Drools pour implémenter une logique métier

Les différents modules étant des bundles OSGi, les systèmes devront tourner sur une plateforme OSGi.

==Evolutions envisageables==

L'objectif de ce projet était de réaliser les fonctionnalités suivantes :
* Ajouter un produit grâce à un lecteur NFC
* Ajouter un produit grâce à une scanette
* Retirer des produits du stock grâce à un lecteur NFC
* Retirer des produits du stock grâce à une scanette
* Envoyer un mail au manager en cas de stock faible d'un produit
* Envoyer un mail au manager régulièrement pour l'informer des variations de stock
* Stocker les informations des produits dans une base de données
* Interagir avec la base de données

Toutes les fonctionnalités ont été réalisées excepté l'envoi d'un mail au manager pour l'informer des variations de stock.

==Difficultés rencontrées==

L'architecture a été pensée de manière à pouvoir facilement ajouter des modules supplémentaires pour interagir avec les « Reader », en plus de l'interface graphique déjà présente. Par exemple une console web, une interface en ligne de commmande ou une interface orientée smartphone (ce qui n'est pas le cas de l'interface actuelle).

Notre système permet la gestion de bouteilles de vin. Il aurait cependant été intéressant d'offrir au manager la possibilité de gérer d'autres produits en lui proposant une gestion générique des produits stockés.

Le moteur de règles pourrait être exploité d'une meilleure manière, de nouvelles règles plus élaborées pourraient être créées.

Permettre à l'utilisateur de configurer les éventuelles options d'un modules (Mail du manager, serveur de messagerie, url et port du serveur, …)

==Apports personnels==

Ce projet nous a apporté de nouvelles compétences :
* Utilisation d'une plateforme OSGi
* Création de bundles OSGi (Notamment avec iPOJO)
* Utilisation de Drools
* Utilisation de REST

==Manuel Installation==

Les sources du projet sont disponibles sur le svn suivant :
https://subversion.assembla.com/svn/M2M-warehouse/

Notre projet est un projet Maven, il est donc nécessaire de le compiler grâce à cet outil. Le projet est découpé en trois modules distincts (TagSystem, BarcodeSystem, WarehouseServer) qu'il est possible de compiler séparément.
Les bundles générés doivent être déployés sur une plateforme OSGi (Par exemple Felix)

Le deploiement des bundles du projet nécessite des services fournis par d'autres bundles. Ces bundles nécessaires sont téléchargeables sur le svn dans le dossier Bundles présent à la racine du dépôt.

===Installation du lecteur NFC (Tikitag)===

Pour utiliser le lecteur NFC il est nécessaire d'installer les librairies suivantes :
* libccid
* pcscd
* pcsc-tools
* libpcsclite1
* libpcsclite-dev

===Installation de la scanette===
La scanette ne demande pas d'installation particulière, il suffit seulement de la brancher à un port USB.

===Base de données===
La base de données doit être une base MySQL, car nous avons choisi ce type de base pour implementer le WarehouseManager. Cette base doit contenir une table VINS. Cette table peut être créée à l'aide de la requête suivante :
create table VINS (idVin integer auto_increment, name varchar(256), year integer, color varchar(10), price float, quantity integer, tag varchar(30),
barcode varchar(30), primary key (idVin));

===Configuration Felix===

Nous avons du modifier le fichier de configuration de Felix pour exporter certaines classes afin qu'elles soient chargées par défaut par le système. Notre fichier est disponible sur le svn.

==Manuel Utilisateur==

L'utilisation de notre système est assez simple, que ce soit pour une utilisation avec la scanette ou le lecteur NFC elle se fait à travers l'interface. Cette interface permet à l'utilisateur de modifier la quantité d'un produit en ajoutant ou retirant une quantité choisie. Elle permet également d'ajouter un nouveau produit qui n'existerai pas dans la base.

Modification de la quantité d'un vin :
* Sélectionner l'action : Ajouter ou Supprimer
* Saisir la quantité à ajouter ou retirer
* Scanner le produit avec le lecteur NFC ou la scanette
* Valider le scan
* Le produit existe :
** Les informations et la nouvelle quantité pour le produit sont affichées
* Le produit n'existe pas :
** Compléter les informations concernant le produit dans le panel apparu
** Valider les informations entrées
*Possibilité de passer à un nouveau produit en recommençant la procédure

ECOM Warehouse Management System

2012-04-05T23:00:33Z

Damontp: /* Manuel Installation */

* Enseignant : Didier Donsez
* Etudiants M2PGI : CASAGRANDE Thierry, RICHARD David

==Matériel==
* RFID + QRCode + Barcode 1D
* USB Barcode reader
* USB NFC Reader

==Logiciels==
* Apache Felix
* Drools Expert

==Introduction==

Ce projet a pour but de fournir un système permettant la gestion d'un entrepôt. Le système doit gérer les entrées et sorties de produits. Un moteur de règles permettra d'analyser les différentes opérations et pour certains évènements particuliers (par exemple un produit bientôt en rupture de stock) le manager sera notifié.
Les mouvements de stock seront effectués à l'aide d'une scanette et d'un lecteur NFC.
Nous avons choisi de gérer un stockage de bouteilles de vins.

==Architecture==

Notre système se compose de trois parties :
Le "Tag System" qui permet d'utiliser le lecteur NFC pour communiquer avec le server de l'entrepôt
Le "Barcode System" qui permet d'utiliser une scanette pour communiquer avec le server de l'entrepôt
Le "Warehouse Server" qui permet de gérer l'entrepôt

[[Image:Architecture_V2.jpg|Architecture]]

Tag System et Barcode System sont tout deux composés de deux modules :
* Un module « Reader » (TagReader et BarcodeReader) qui permet de scanner les objets et de communiquer avec le serveur grâce à des requêtes REST
* Un module « GUI » (TagGUI et BarcodeGUI) qui offre une interface en Swing pour utiliser le module « Reader »

Warehouse Server :
* Une base de données pour stocker les informations des produits de l'entrepôt
* Un module « WarehouseManager » permettant d'effectuer des opérations sur la base de données
* Deux modules « Solver » (TagSolver et BarcodeSolver) exposant des services REST afin de récuperer les informations envoyées par les « Readers », les analyser et effectuer l'opération requise
* Un module « ManagerNotifier » offrant la possibilité d'envoyer des emails au manager de l'entrepôt (utilisation de l'API JavaMail)
* Un moteur de règles basé sur Drools pour implémenter une logique métier

Les différents modules étant des bundles OSGi, les systèmes devront tourner sur une plateforme OSGi.

==Evolutions envisageables==

L'objectif de ce projet était de réaliser les fonctionnalités suivantes :
* Ajouter un produit grâce à un lecteur NFC
* Ajouter un produit grâce à une scanette
* Retirer des produits du stock grâce à un lecteur NFC
* Retirer des produits du stock grâce à une scanette
* Envoyer un mail au manager en cas de stock faible d'un produit
* Envoyer un mail au manager régulièrement pour l'informer des variations de stock
* Stocker les informations des produits dans une base de données
* Interagir avec la base de données

Toutes les fonctionnalités ont été réalisées excepté l'envoi d'un mail au manager pour l'informer des variations de stock.

==Difficultés rencontrées==

L'architecture a été pensée de manière à pouvoir facilement ajouter des modules supplémentaires pour interagir avec les « Reader », en plus de l'interface graphique déjà présente. Par exemple une console web, une interface en ligne de commmande ou une interface orientée smartphone (ce qui n'est pas le cas de l'interface actuelle).

Notre système permet la gestion de bouteilles de vin. Il aurait cependant été intéressant d'offrir au manager la possibilité de gérer d'autres produits en lui proposant une gestion générique des produits stockés.

Le moteur de règles pourrait être exploité d'une meilleure manière, de nouvelles règles plus élaborées pourraient être créées.

Permettre à l'utilisateur de configurer les éventuelles options d'un modules (Mail du manager, serveur de messagerie, url et port du serveur, …)

==Apports personnels==

Ce projet nous a apporté de nouvelles compétences :
* Utilisation d'une plateforme OSGi
* Création de bundles OSGi (Notamment avec iPOJO)
* Utilisation de Drools
* Utilisation de REST

==Manuel Installation==

Les sources du projet sont disponibles sur le svn suivant :
https://subversion.assembla.com/svn/M2M-warehouse/

Notre projet est un projet Maven, il est donc nécessaire de le compiler grâce à cet outil. Le projet est découpé en trois modules distincts (TagSystem, BarcodeSystem, WarehouseServer) qu'il est possible de compiler séparément.
Les bundles générés doivent être déployés sur une plateforme OSGi (Par exemple Felix)

Le deploiement des bundles du projet nécessite des services fournis par d'autres bundles. Ces bundles nécessaires sont téléchargeables sur le svn dans le dossier Bundles présent à la racine du dépôt.

===Installation du lecteur NFC (Tikitag)===

Pour utiliser le lecteur NFC il est nécessaire d'installer les librairies suivantes :
* libccid
* pcscd
* pcsc-tools
* libpcsclite1
* libpcsclite-dev

===Installation de la scanette===
La scanette ne demande pas d'installation particulière, il suffit seulement de la brancher à un port USB.

===Base de données===
La base de données doit être une base MySQL, car nous avons choisi ce type de base pour implementer le WarehouseManager. Cette base doit contenir une table VINS. Cette table peut être créée à l'aide de la requête suivante :
create table VINS (idVin integer auto_increment, name varchar(256), year integer, color varchar(10), price float, quantity integer, tag varchar(30),
barcode varchar(30), primary key (idVin));

===Configuration Felix===

Nous avons du modifier le fichier de configuration de Felix pour exporter certaines classes afin qu'elles soient chargées par défaut par le système. Notre fichier est disponible sur le svn.

==Manuel Utilisateur==

L'utilisation de notre système est assez simple, que ce soit pour une utilisation avec la scanette ou le lecteur NFC elle se fait à travers l'interface. Cette interface permet à l'utilisateur de modifier la quantité d'un produit en ajoutant ou retirant une quantité choisie. Elle permet également d'ajouter un nouveau produit qui n'existerai pas dans la base.

Modification de la quantité d'un vin :
* Sélectionner l'action : Ajouter ou Supprimer
* Saisir la quantité à ajouter ou retirer
* Scanner le produit avec le lecteur NFC ou la scanette
* Valider le scan
* Le produit existe :
** Les informations et la nouvelle quantité pour le produit sont affichées
* Le produit n'existe pas :
** Compléter les informations concernant le produit dans le panel apparu
** Valider les informations entrées
*Possibilité de passer à un nouveau produit en recommençant la procédure

==Conclusion==

ECOM Warehouse Management System

2012-04-05T22:36:06Z

Damontp: /* Installation du lecteur NFC (Tikitag) */

* Enseignant : Didier Donsez
* Etudiants M2PGI : CASAGRANDE Thierry, RICHARD David

==Matériel==
* RFID + QRCode + Barcode 1D
* USB Barcode reader
* USB NFC Reader

==Logiciels==
* Apache Felix
* Drools Expert

==Introduction==

Ce projet a pour but de fournir un système permettant la gestion d'un entrepôt. Le système doit gérer les entrées et sorties de produits. Un moteur de règles permettra d'analyser les différentes opérations et pour certains évènements particuliers (par exemple un produit bientôt en rupture de stock) le manager sera notifié.
Les mouvements de stock seront effectués à l'aide d'une scanette et d'un lecteur NFC.
Nous avons choisi de gérer un stockage de bouteilles de vins.

==Architecture==

Notre système se compose de trois parties :
Le "Tag System" qui permet d'utiliser le lecteur NFC pour communiquer avec le server de l'entrepôt
Le "Barcode System" qui permet d'utiliser une scanette pour communiquer avec le server de l'entrepôt
Le "Warehouse Server" qui permet de gérer l'entrepôt

[[Image:Architecture_V2.jpg|Architecture]]

Tag System et Barcode System sont tout deux composés de deux modules :
* Un module « Reader » (TagReader et BarcodeReader) qui permet de scanner les objets et de communiquer avec le serveur grâce à des requêtes REST
* Un module « GUI » (TagGUI et BarcodeGUI) qui offre une interface en Swing pour utiliser le module « Reader »

Warehouse Server :
* Une base de données pour stocker les informations des produits de l'entrepôt
* Un module « WarehouseManager » permettant d'effectuer des opérations sur la base de données
* Deux modules « Solver » (TagSolver et BarcodeSolver) exposant des services REST afin de récuperer les informations envoyées par les « Readers », les analyser et effectuer l'opération requise
* Un module « ManagerNotifier » offrant la possibilité d'envoyer des emails au manager de l'entrepôt (utilisation de l'API JavaMail)
* Un moteur de règles basé sur Drools pour implémenter une logique métier

Les différents modules étant des bundles OSGi, les systèmes devront tourner sur une plateforme OSGi.

==Evolutions envisageables==

L'objectif de ce projet était de réaliser les fonctionnalités suivantes :
* Ajouter un produit grâce à un lecteur NFC
* Ajouter un produit grâce à une scanette
* Retirer des produits du stock grâce à un lecteur NFC
* Retirer des produits du stock grâce à une scanette
* Envoyer un mail au manager en cas de stock faible d'un produit
* Envoyer un mail au manager régulièrement pour l'informer des variations de stock
* Stocker les informations des produits dans une base de données
* Interagir avec la base de données

Toutes les fonctionnalités ont été réalisées excepté l'envoi d'un mail au manager pour l'informer des variations de stock.

==Difficultés rencontrées==

L'architecture a été pensée de manière à pouvoir facilement ajouter des modules supplémentaires pour interagir avec les « Reader », en plus de l'interface graphique déjà présente. Par exemple une console web, une interface en ligne de commmande ou une interface orientée smartphone (ce qui n'est pas le cas de l'interface actuelle).

Notre système permet la gestion de bouteilles de vin. Il aurait cependant été intéressant d'offrir au manager la possibilité de gérer d'autres produits en lui proposant une gestion générique des produits stockés.

Le moteur de règles pourrait être exploité d'une meilleure manière, de nouvelles règles plus élaborées pourraient être créées.

Permettre à l'utilisateur de configurer les éventuelles options d'un modules (Mail du manager, serveur de messagerie, url et port du serveur, …)

==Apports personnels==

Ce projet nous a apporté de nouvelles compétences :
* Utilisation d'une plateforme OSGi
* Création de bundles OSGi (Notamment avec iPOJO)
* Utilisation de Drools
* Utilisation de REST

==Manuel Installation==

Les sources du projet sont disponibles sur le svn suivant :
https://subversion.assembla.com/svn/M2M-warehouse/

Notre projet est un projet Maven, il est donc nécessaire de le compiler grâce à cet outil. Le projet est découpé en trois modules distincts (TagSystem, BarcodeSystem, WarehouseServer) qu'il est possible de compiler séparément.
Les bundles générés doivent être déployés sur une plateforme OSGi (Par exemple Felix)

Le deploiement des bundles du projet nécessite des services fournis par d'autres bundles. Ces bundles nécessaires sont téléchargeables sur le svn dans le dossier Bundles présent à la racine du dépôt.

===Installation du lecteur NFC (Tikitag)===

Pour utiliser le lecteur NFC il est nécessaire d'installer les librairies suivantes :
* libccid
* pcscd
* pcsc-tools
* libpcsclite1
* libpcsclite-dev

===Installation de la scanette===
La scanette ne demande pas d'installation particulière, il suffit seulement de la brancher à un port USB.

===Base de données===
La base de données doit être une base MySQL, car nous avons choisi ce type de base pour implementer le WarehouseManager. Cette base doit contenir une table VINS. Cette table peut être créée à l'aide de la requête suivante :
create table VINS (idVin integer auto_increment, name varchar(256), year integer, color varchar(10), price float, quantity integer, tag varchar(30),
barcode varchar(30), primary key (idVin));

==Manuel Utilisateur==

L'utilisation de notre système est assez simple, que ce soit pour une utilisation avec la scanette ou le lecteur NFC elle se fait à travers l'interface. Cette interface permet à l'utilisateur de modifier la quantité d'un produit en ajoutant ou retirant une quantité choisie. Elle permet également d'ajouter un nouveau produit qui n'existerai pas dans la base.

Modification de la quantité d'un vin :
* Sélectionner l'action : Ajouter ou Supprimer
* Saisir la quantité à ajouter ou retirer
* Scanner le produit avec le lecteur NFC ou la scanette
* Valider le scan
* Le produit existe :
** Les informations et la nouvelle quantité pour le produit sont affichées
* Le produit n'existe pas :
** Compléter les informations concernant le produit dans le panel apparu
** Valider les informations entrées
*Possibilité de passer à un nouveau produit en recommençant la procédure

==Conclusion==

ECOM Warehouse Management System

2012-04-05T22:35:36Z

Damontp: /* Manuel Installation */

* Enseignant : Didier Donsez
* Etudiants M2PGI : CASAGRANDE Thierry, RICHARD David

==Matériel==
* RFID + QRCode + Barcode 1D
* USB Barcode reader
* USB NFC Reader

==Logiciels==
* Apache Felix
* Drools Expert

==Introduction==

Ce projet a pour but de fournir un système permettant la gestion d'un entrepôt. Le système doit gérer les entrées et sorties de produits. Un moteur de règles permettra d'analyser les différentes opérations et pour certains évènements particuliers (par exemple un produit bientôt en rupture de stock) le manager sera notifié.
Les mouvements de stock seront effectués à l'aide d'une scanette et d'un lecteur NFC.
Nous avons choisi de gérer un stockage de bouteilles de vins.

==Architecture==

Notre système se compose de trois parties :
Le "Tag System" qui permet d'utiliser le lecteur NFC pour communiquer avec le server de l'entrepôt
Le "Barcode System" qui permet d'utiliser une scanette pour communiquer avec le server de l'entrepôt
Le "Warehouse Server" qui permet de gérer l'entrepôt

[[Image:Architecture_V2.jpg|Architecture]]

Tag System et Barcode System sont tout deux composés de deux modules :
* Un module « Reader » (TagReader et BarcodeReader) qui permet de scanner les objets et de communiquer avec le serveur grâce à des requêtes REST
* Un module « GUI » (TagGUI et BarcodeGUI) qui offre une interface en Swing pour utiliser le module « Reader »

Warehouse Server :
* Une base de données pour stocker les informations des produits de l'entrepôt
* Un module « WarehouseManager » permettant d'effectuer des opérations sur la base de données
* Deux modules « Solver » (TagSolver et BarcodeSolver) exposant des services REST afin de récuperer les informations envoyées par les « Readers », les analyser et effectuer l'opération requise
* Un module « ManagerNotifier » offrant la possibilité d'envoyer des emails au manager de l'entrepôt (utilisation de l'API JavaMail)
* Un moteur de règles basé sur Drools pour implémenter une logique métier

Les différents modules étant des bundles OSGi, les systèmes devront tourner sur une plateforme OSGi.

==Evolutions envisageables==

L'objectif de ce projet était de réaliser les fonctionnalités suivantes :
* Ajouter un produit grâce à un lecteur NFC
* Ajouter un produit grâce à une scanette
* Retirer des produits du stock grâce à un lecteur NFC
* Retirer des produits du stock grâce à une scanette
* Envoyer un mail au manager en cas de stock faible d'un produit
* Envoyer un mail au manager régulièrement pour l'informer des variations de stock
* Stocker les informations des produits dans une base de données
* Interagir avec la base de données

Toutes les fonctionnalités ont été réalisées excepté l'envoi d'un mail au manager pour l'informer des variations de stock.

==Difficultés rencontrées==

L'architecture a été pensée de manière à pouvoir facilement ajouter des modules supplémentaires pour interagir avec les « Reader », en plus de l'interface graphique déjà présente. Par exemple une console web, une interface en ligne de commmande ou une interface orientée smartphone (ce qui n'est pas le cas de l'interface actuelle).

Notre système permet la gestion de bouteilles de vin. Il aurait cependant été intéressant d'offrir au manager la possibilité de gérer d'autres produits en lui proposant une gestion générique des produits stockés.

Le moteur de règles pourrait être exploité d'une meilleure manière, de nouvelles règles plus élaborées pourraient être créées.

Permettre à l'utilisateur de configurer les éventuelles options d'un modules (Mail du manager, serveur de messagerie, url et port du serveur, …)

==Apports personnels==

Ce projet nous a apporté de nouvelles compétences :
* Utilisation d'une plateforme OSGi
* Création de bundles OSGi (Notamment avec iPOJO)
* Utilisation de Drools
* Utilisation de REST

==Manuel Installation==

Les sources du projet sont disponibles sur le svn suivant :
https://subversion.assembla.com/svn/M2M-warehouse/

Notre projet est un projet Maven, il est donc nécessaire de le compiler grâce à cet outil. Le projet est découpé en trois modules distincts (TagSystem, BarcodeSystem, WarehouseServer) qu'il est possible de compiler séparément.
Les bundles générés doivent être déployés sur une plateforme OSGi (Par exemple Felix)

Le deploiement des bundles du projet nécessite des services fournis par d'autres bundles. Ces bundles nécessaires sont téléchargeables sur le svn dans le dossier Bundles présent à la racine du dépôt.

===Installation du lecteur NFC (Tikitag)===

Pour utiliser le lecteur NFC il est nécessaire d'installer les librairies suivantes :
** libccid
** pcscd
** pcsc-tools
** libpcsclite1
** libpcsclite-dev

===Installation de la scanette===
La scanette ne demande pas d'installation particulière, il suffit seulement de la brancher à un port USB.

===Base de données===
La base de données doit être une base MySQL, car nous avons choisi ce type de base pour implementer le WarehouseManager. Cette base doit contenir une table VINS. Cette table peut être créée à l'aide de la requête suivante :
create table VINS (idVin integer auto_increment, name varchar(256), year integer, color varchar(10), price float, quantity integer, tag varchar(30),
barcode varchar(30), primary key (idVin));

==Manuel Utilisateur==

L'utilisation de notre système est assez simple, que ce soit pour une utilisation avec la scanette ou le lecteur NFC elle se fait à travers l'interface. Cette interface permet à l'utilisateur de modifier la quantité d'un produit en ajoutant ou retirant une quantité choisie. Elle permet également d'ajouter un nouveau produit qui n'existerai pas dans la base.

Modification de la quantité d'un vin :
* Sélectionner l'action : Ajouter ou Supprimer
* Saisir la quantité à ajouter ou retirer
* Scanner le produit avec le lecteur NFC ou la scanette
* Valider le scan
* Le produit existe :
** Les informations et la nouvelle quantité pour le produit sont affichées
* Le produit n'existe pas :
** Compléter les informations concernant le produit dans le panel apparu
** Valider les informations entrées
*Possibilité de passer à un nouveau produit en recommençant la procédure

==Conclusion==

ECOM Warehouse Management System

2012-04-05T22:33:25Z

Damontp: /* Manuel Installation */

* Enseignant : Didier Donsez
* Etudiants M2PGI : CASAGRANDE Thierry, RICHARD David

==Matériel==
* RFID + QRCode + Barcode 1D
* USB Barcode reader
* USB NFC Reader

==Logiciels==
* Apache Felix
* Drools Expert

==Introduction==

Ce projet a pour but de fournir un système permettant la gestion d'un entrepôt. Le système doit gérer les entrées et sorties de produits. Un moteur de règles permettra d'analyser les différentes opérations et pour certains évènements particuliers (par exemple un produit bientôt en rupture de stock) le manager sera notifié.
Les mouvements de stock seront effectués à l'aide d'une scanette et d'un lecteur NFC.
Nous avons choisi de gérer un stockage de bouteilles de vins.

==Architecture==

Notre système se compose de trois parties :
Le "Tag System" qui permet d'utiliser le lecteur NFC pour communiquer avec le server de l'entrepôt
Le "Barcode System" qui permet d'utiliser une scanette pour communiquer avec le server de l'entrepôt
Le "Warehouse Server" qui permet de gérer l'entrepôt

[[Image:Architecture_V2.jpg|Architecture]]

Tag System et Barcode System sont tout deux composés de deux modules :
* Un module « Reader » (TagReader et BarcodeReader) qui permet de scanner les objets et de communiquer avec le serveur grâce à des requêtes REST
* Un module « GUI » (TagGUI et BarcodeGUI) qui offre une interface en Swing pour utiliser le module « Reader »

Warehouse Server :
* Une base de données pour stocker les informations des produits de l'entrepôt
* Un module « WarehouseManager » permettant d'effectuer des opérations sur la base de données
* Deux modules « Solver » (TagSolver et BarcodeSolver) exposant des services REST afin de récuperer les informations envoyées par les « Readers », les analyser et effectuer l'opération requise
* Un module « ManagerNotifier » offrant la possibilité d'envoyer des emails au manager de l'entrepôt (utilisation de l'API JavaMail)
* Un moteur de règles basé sur Drools pour implémenter une logique métier

Les différents modules étant des bundles OSGi, les systèmes devront tourner sur une plateforme OSGi.

==Evolutions envisageables==

L'objectif de ce projet était de réaliser les fonctionnalités suivantes :
* Ajouter un produit grâce à un lecteur NFC
* Ajouter un produit grâce à une scanette
* Retirer des produits du stock grâce à un lecteur NFC
* Retirer des produits du stock grâce à une scanette
* Envoyer un mail au manager en cas de stock faible d'un produit
* Envoyer un mail au manager régulièrement pour l'informer des variations de stock
* Stocker les informations des produits dans une base de données
* Interagir avec la base de données

Toutes les fonctionnalités ont été réalisées excepté l'envoi d'un mail au manager pour l'informer des variations de stock.

==Difficultés rencontrées==

L'architecture a été pensée de manière à pouvoir facilement ajouter des modules supplémentaires pour interagir avec les « Reader », en plus de l'interface graphique déjà présente. Par exemple une console web, une interface en ligne de commmande ou une interface orientée smartphone (ce qui n'est pas le cas de l'interface actuelle).

Notre système permet la gestion de bouteilles de vin. Il aurait cependant été intéressant d'offrir au manager la possibilité de gérer d'autres produits en lui proposant une gestion générique des produits stockés.

Le moteur de règles pourrait être exploité d'une meilleure manière, de nouvelles règles plus élaborées pourraient être créées.

Permettre à l'utilisateur de configurer les éventuelles options d'un modules (Mail du manager, serveur de messagerie, url et port du serveur, …)

==Apports personnels==

Ce projet nous a apporté de nouvelles compétences :
* Utilisation d'une plateforme OSGi
* Création de bundles OSGi (Notamment avec iPOJO)
* Utilisation de Drools
* Utilisation de REST

==Manuel Installation==

Les sources du projet sont disponibles sur le svn suivant :
https://subversion.assembla.com/svn/M2M-warehouse/

Notre projet est un projet Maven, il est donc nécessaire de le compiler grâce à cet outil. Le projet est découpé en trois modules distincts (TagSystem, BarcodeSystem, WarehouseServer) qu'il est possible de compiler séparément.
Les bundles générés doivent être déployés sur une plateforme OSGi (Par exemple Felix)

Le deploiement des bundles du projet nécessite des services fournis par d'autres bundles. Ces bundles nécessaires sont téléchargeables sur le svn dans le dossier Bundles présent à la racine du dépôt.

* Installation du lecteur NFC (Tikitag)

Pour utiliser le lecteur NFC il est nécessaire d'installer les librairies suivantes :
** libccid
** pcscd
** pcsc-tools
** libpcsclite1
** libpcsclite-dev

* Installation de la scanette :
La scanette ne demande pas d'installation particulière, il suffit seulement de la brancher à un port USB.

* Base de données
La base de données doit être une base MySQL, car nous avons choisi ce type de base pour implementer le WarehouseManager. Cette base doit contenir une table VINS. Cette table peut être créée à l'aide de la requête suivante :
create table VINS (idVin integer auto_increment, name varchar(256), year integer, color varchar(10), price float, quantity integer, tag varchar(30),
barcode varchar(30), primary key (idVin));

==Manuel Utilisateur==

L'utilisation de notre système est assez simple, que ce soit pour une utilisation avec la scanette ou le lecteur NFC elle se fait à travers l'interface. Cette interface permet à l'utilisateur de modifier la quantité d'un produit en ajoutant ou retirant une quantité choisie. Elle permet également d'ajouter un nouveau produit qui n'existerai pas dans la base.

Modification de la quantité d'un vin :
* Sélectionner l'action : Ajouter ou Supprimer
* Saisir la quantité à ajouter ou retirer
* Scanner le produit avec le lecteur NFC ou la scanette
* Valider le scan
* Le produit existe :
** Les informations et la nouvelle quantité pour le produit sont affichées
* Le produit n'existe pas :
** Compléter les informations concernant le produit dans le panel apparu
** Valider les informations entrées
*Possibilité de passer à un nouveau produit en recommençant la procédure

==Conclusion==

ECOM Warehouse Management System

2012-04-05T22:32:01Z

Damontp: /* Manuel Installation */

* Enseignant : Didier Donsez
* Etudiants M2PGI : CASAGRANDE Thierry, RICHARD David

==Matériel==
* RFID + QRCode + Barcode 1D
* USB Barcode reader
* USB NFC Reader

==Logiciels==
* Apache Felix
* Drools Expert

==Introduction==

Ce projet a pour but de fournir un système permettant la gestion d'un entrepôt. Le système doit gérer les entrées et sorties de produits. Un moteur de règles permettra d'analyser les différentes opérations et pour certains évènements particuliers (par exemple un produit bientôt en rupture de stock) le manager sera notifié.
Les mouvements de stock seront effectués à l'aide d'une scanette et d'un lecteur NFC.
Nous avons choisi de gérer un stockage de bouteilles de vins.

==Architecture==

Notre système se compose de trois parties :
Le "Tag System" qui permet d'utiliser le lecteur NFC pour communiquer avec le server de l'entrepôt
Le "Barcode System" qui permet d'utiliser une scanette pour communiquer avec le server de l'entrepôt
Le "Warehouse Server" qui permet de gérer l'entrepôt

[[Image:Architecture_V2.jpg|Architecture]]

Tag System et Barcode System sont tout deux composés de deux modules :
* Un module « Reader » (TagReader et BarcodeReader) qui permet de scanner les objets et de communiquer avec le serveur grâce à des requêtes REST
* Un module « GUI » (TagGUI et BarcodeGUI) qui offre une interface en Swing pour utiliser le module « Reader »

Warehouse Server :
* Une base de données pour stocker les informations des produits de l'entrepôt
* Un module « WarehouseManager » permettant d'effectuer des opérations sur la base de données
* Deux modules « Solver » (TagSolver et BarcodeSolver) exposant des services REST afin de récuperer les informations envoyées par les « Readers », les analyser et effectuer l'opération requise
* Un module « ManagerNotifier » offrant la possibilité d'envoyer des emails au manager de l'entrepôt (utilisation de l'API JavaMail)
* Un moteur de règles basé sur Drools pour implémenter une logique métier

Les différents modules étant des bundles OSGi, les systèmes devront tourner sur une plateforme OSGi.

==Evolutions envisageables==

L'objectif de ce projet était de réaliser les fonctionnalités suivantes :
* Ajouter un produit grâce à un lecteur NFC
* Ajouter un produit grâce à une scanette
* Retirer des produits du stock grâce à un lecteur NFC
* Retirer des produits du stock grâce à une scanette
* Envoyer un mail au manager en cas de stock faible d'un produit
* Envoyer un mail au manager régulièrement pour l'informer des variations de stock
* Stocker les informations des produits dans une base de données
* Interagir avec la base de données

Toutes les fonctionnalités ont été réalisées excepté l'envoi d'un mail au manager pour l'informer des variations de stock.

==Difficultés rencontrées==

L'architecture a été pensée de manière à pouvoir facilement ajouter des modules supplémentaires pour interagir avec les « Reader », en plus de l'interface graphique déjà présente. Par exemple une console web, une interface en ligne de commmande ou une interface orientée smartphone (ce qui n'est pas le cas de l'interface actuelle).

Notre système permet la gestion de bouteilles de vin. Il aurait cependant été intéressant d'offrir au manager la possibilité de gérer d'autres produits en lui proposant une gestion générique des produits stockés.

Le moteur de règles pourrait être exploité d'une meilleure manière, de nouvelles règles plus élaborées pourraient être créées.

Permettre à l'utilisateur de configurer les éventuelles options d'un modules (Mail du manager, serveur de messagerie, url et port du serveur, …)

==Apports personnels==

Ce projet nous a apporté de nouvelles compétences :
* Utilisation d'une plateforme OSGi
* Création de bundles OSGi (Notamment avec iPOJO)
* Utilisation de Drools
* Utilisation de REST

==Manuel Installation==

Les sources du projet sont disponibles sur le svn suivant :
https://subversion.assembla.com/svn/M2M-warehouse/

Notre projet est un projet Maven, il est donc nécessaire de le compiler grâce à cet outil. Le projet est découpé en trois modules distincts (TagSystem, BarcodeSystem, WarehouseServer) qu'il est possible de compiler séparément.
Les bundles générés doivent être déployés sur une plateforme OSGi (Par exemple Felix)

Le deploiement des bundles du projet nécessite des services fournis par d'autres bundles. Ces bundles nécessaires sont téléchargeables sur le svn dans le dossier Bundles présent à la racine du dépôt.

* Installation du lecteur NFC (Tikitag)

Pour utiliser le lecteur NFC il est nécessaire d'installer les librairies suivantes :
* libccid
* pcscd
* pcsc-tools
* libpcsclite1
* libpcsclite-dev

* Installation de la scanette :
La scanette ne demande pas d'installation particulière, il suffit seulement de la brancher à un port USB.

* Base de données
La base de données doit être une base MySQL, car nous avons choisi ce type de base pour implementer le WarehouseManager. Cette base doit contenir une table VINS. Cette table peut être créée à l'aide de la requête suivante :
create table VINS (idVin integer auto_increment, name varchar(256), year integer, color varchar(10), price float, quantity integer, tag varchar(30),
barcode varchar(30), primary key (idVin));

==Manuel Utilisateur==

L'utilisation de notre système est assez simple, que ce soit pour une utilisation avec la scanette ou le lecteur NFC elle se fait à travers l'interface. Cette interface permet à l'utilisateur de modifier la quantité d'un produit en ajoutant ou retirant une quantité choisie. Elle permet également d'ajouter un nouveau produit qui n'existerai pas dans la base.

Modification de la quantité d'un vin :
* Sélectionner l'action : Ajouter ou Supprimer
* Saisir la quantité à ajouter ou retirer
* Scanner le produit avec le lecteur NFC ou la scanette
* Valider le scan
* Le produit existe :
** Les informations et la nouvelle quantité pour le produit sont affichées
* Le produit n'existe pas :
** Compléter les informations concernant le produit dans le panel apparu
** Valider les informations entrées
*Possibilité de passer à un nouveau produit en recommençant la procédure

==Conclusion==

ECOM Warehouse Management System

2012-04-05T22:31:28Z

Damontp: /* Manuel Installation */

* Enseignant : Didier Donsez
* Etudiants M2PGI : CASAGRANDE Thierry, RICHARD David

==Matériel==
* RFID + QRCode + Barcode 1D
* USB Barcode reader
* USB NFC Reader

==Logiciels==
* Apache Felix
* Drools Expert

==Introduction==

Ce projet a pour but de fournir un système permettant la gestion d'un entrepôt. Le système doit gérer les entrées et sorties de produits. Un moteur de règles permettra d'analyser les différentes opérations et pour certains évènements particuliers (par exemple un produit bientôt en rupture de stock) le manager sera notifié.
Les mouvements de stock seront effectués à l'aide d'une scanette et d'un lecteur NFC.
Nous avons choisi de gérer un stockage de bouteilles de vins.

==Architecture==

Notre système se compose de trois parties :
Le "Tag System" qui permet d'utiliser le lecteur NFC pour communiquer avec le server de l'entrepôt
Le "Barcode System" qui permet d'utiliser une scanette pour communiquer avec le server de l'entrepôt
Le "Warehouse Server" qui permet de gérer l'entrepôt

[[Image:Architecture_V2.jpg|Architecture]]

Tag System et Barcode System sont tout deux composés de deux modules :
* Un module « Reader » (TagReader et BarcodeReader) qui permet de scanner les objets et de communiquer avec le serveur grâce à des requêtes REST
* Un module « GUI » (TagGUI et BarcodeGUI) qui offre une interface en Swing pour utiliser le module « Reader »

Warehouse Server :
* Une base de données pour stocker les informations des produits de l'entrepôt
* Un module « WarehouseManager » permettant d'effectuer des opérations sur la base de données
* Deux modules « Solver » (TagSolver et BarcodeSolver) exposant des services REST afin de récuperer les informations envoyées par les « Readers », les analyser et effectuer l'opération requise
* Un module « ManagerNotifier » offrant la possibilité d'envoyer des emails au manager de l'entrepôt (utilisation de l'API JavaMail)
* Un moteur de règles basé sur Drools pour implémenter une logique métier

Les différents modules étant des bundles OSGi, les systèmes devront tourner sur une plateforme OSGi.

==Evolutions envisageables==

L'objectif de ce projet était de réaliser les fonctionnalités suivantes :
* Ajouter un produit grâce à un lecteur NFC
* Ajouter un produit grâce à une scanette
* Retirer des produits du stock grâce à un lecteur NFC
* Retirer des produits du stock grâce à une scanette
* Envoyer un mail au manager en cas de stock faible d'un produit
* Envoyer un mail au manager régulièrement pour l'informer des variations de stock
* Stocker les informations des produits dans une base de données
* Interagir avec la base de données

Toutes les fonctionnalités ont été réalisées excepté l'envoi d'un mail au manager pour l'informer des variations de stock.

==Difficultés rencontrées==

L'architecture a été pensée de manière à pouvoir facilement ajouter des modules supplémentaires pour interagir avec les « Reader », en plus de l'interface graphique déjà présente. Par exemple une console web, une interface en ligne de commmande ou une interface orientée smartphone (ce qui n'est pas le cas de l'interface actuelle).

Notre système permet la gestion de bouteilles de vin. Il aurait cependant été intéressant d'offrir au manager la possibilité de gérer d'autres produits en lui proposant une gestion générique des produits stockés.

Le moteur de règles pourrait être exploité d'une meilleure manière, de nouvelles règles plus élaborées pourraient être créées.

Permettre à l'utilisateur de configurer les éventuelles options d'un modules (Mail du manager, serveur de messagerie, url et port du serveur, …)

==Apports personnels==

Ce projet nous a apporté de nouvelles compétences :
* Utilisation d'une plateforme OSGi
* Création de bundles OSGi (Notamment avec iPOJO)
* Utilisation de Drools
* Utilisation de REST

==Manuel Installation==

Les sources du projet sont disponibles sur le svn suivant :
https://subversion.assembla.com/svn/M2M-warehouse/

Notre projet est un projet Maven, il est donc nécessaire de le compiler grâce à cet outil. Le projet est découpé en trois modules distincts (TagSystem, BarcodeSystem, WarehouseServer) qu'il est possible de compiler séparément.
Les bundles générés doivent être déployés sur une plateforme OSGi (Par exemple Felix)

Le deploiement des bundles du projet nécessite des services fournis par d'autres bundles. Ces bundles nécessaires sont téléchargeables sur le svn dans le dossier Bundles présent à la racine du dépôt.

* Installation du lecteur NFC (Tikitag)

Pour utiliser le lecteur NFC il est nécessaire d'installer les librairies suivantes :
libccid
pcscd
pcsc-tools
libpcsclite1
libpcsclite-dev
* Installation de la scanette :
La scanette ne demande pas d'installation particulière, il suffit seulement de la brancher à un port USB.
* Base de données
La base de données doit être une base MySQL, car nous avons choisi ce type de base pour implementer le WarehouseManager. Cette base doit contenir une table VINS. Cette table peut être créée à l'aide de la requête suivante :
create table VINS (idVin integer auto_increment, name varchar(256), year integer, color varchar(10), price float, quantity integer, tag varchar(30),
barcode varchar(30), primary key (idVin));

==Manuel Utilisateur==

L'utilisation de notre système est assez simple, que ce soit pour une utilisation avec la scanette ou le lecteur NFC elle se fait à travers l'interface. Cette interface permet à l'utilisateur de modifier la quantité d'un produit en ajoutant ou retirant une quantité choisie. Elle permet également d'ajouter un nouveau produit qui n'existerai pas dans la base.

Modification de la quantité d'un vin :
* Sélectionner l'action : Ajouter ou Supprimer
* Saisir la quantité à ajouter ou retirer
* Scanner le produit avec le lecteur NFC ou la scanette
* Valider le scan
* Le produit existe :
** Les informations et la nouvelle quantité pour le produit sont affichées
* Le produit n'existe pas :
** Compléter les informations concernant le produit dans le panel apparu
** Valider les informations entrées
*Possibilité de passer à un nouveau produit en recommençant la procédure

==Conclusion==

ECOM Warehouse Management System

2012-04-05T22:30:49Z

Damontp: /* Manuel Installation */

* Enseignant : Didier Donsez
* Etudiants M2PGI : CASAGRANDE Thierry, RICHARD David

==Matériel==
* RFID + QRCode + Barcode 1D
* USB Barcode reader
* USB NFC Reader

==Logiciels==
* Apache Felix
* Drools Expert

==Introduction==

Ce projet a pour but de fournir un système permettant la gestion d'un entrepôt. Le système doit gérer les entrées et sorties de produits. Un moteur de règles permettra d'analyser les différentes opérations et pour certains évènements particuliers (par exemple un produit bientôt en rupture de stock) le manager sera notifié.
Les mouvements de stock seront effectués à l'aide d'une scanette et d'un lecteur NFC.
Nous avons choisi de gérer un stockage de bouteilles de vins.

==Architecture==

Notre système se compose de trois parties :
Le "Tag System" qui permet d'utiliser le lecteur NFC pour communiquer avec le server de l'entrepôt
Le "Barcode System" qui permet d'utiliser une scanette pour communiquer avec le server de l'entrepôt
Le "Warehouse Server" qui permet de gérer l'entrepôt

[[Image:Architecture_V2.jpg|Architecture]]

Tag System et Barcode System sont tout deux composés de deux modules :
* Un module « Reader » (TagReader et BarcodeReader) qui permet de scanner les objets et de communiquer avec le serveur grâce à des requêtes REST
* Un module « GUI » (TagGUI et BarcodeGUI) qui offre une interface en Swing pour utiliser le module « Reader »

Warehouse Server :
* Une base de données pour stocker les informations des produits de l'entrepôt
* Un module « WarehouseManager » permettant d'effectuer des opérations sur la base de données
* Deux modules « Solver » (TagSolver et BarcodeSolver) exposant des services REST afin de récuperer les informations envoyées par les « Readers », les analyser et effectuer l'opération requise
* Un module « ManagerNotifier » offrant la possibilité d'envoyer des emails au manager de l'entrepôt (utilisation de l'API JavaMail)
* Un moteur de règles basé sur Drools pour implémenter une logique métier

Les différents modules étant des bundles OSGi, les systèmes devront tourner sur une plateforme OSGi.

==Evolutions envisageables==

L'objectif de ce projet était de réaliser les fonctionnalités suivantes :
* Ajouter un produit grâce à un lecteur NFC
* Ajouter un produit grâce à une scanette
* Retirer des produits du stock grâce à un lecteur NFC
* Retirer des produits du stock grâce à une scanette
* Envoyer un mail au manager en cas de stock faible d'un produit
* Envoyer un mail au manager régulièrement pour l'informer des variations de stock
* Stocker les informations des produits dans une base de données
* Interagir avec la base de données

Toutes les fonctionnalités ont été réalisées excepté l'envoi d'un mail au manager pour l'informer des variations de stock.

==Difficultés rencontrées==

L'architecture a été pensée de manière à pouvoir facilement ajouter des modules supplémentaires pour interagir avec les « Reader », en plus de l'interface graphique déjà présente. Par exemple une console web, une interface en ligne de commmande ou une interface orientée smartphone (ce qui n'est pas le cas de l'interface actuelle).

Notre système permet la gestion de bouteilles de vin. Il aurait cependant été intéressant d'offrir au manager la possibilité de gérer d'autres produits en lui proposant une gestion générique des produits stockés.

Le moteur de règles pourrait être exploité d'une meilleure manière, de nouvelles règles plus élaborées pourraient être créées.

Permettre à l'utilisateur de configurer les éventuelles options d'un modules (Mail du manager, serveur de messagerie, url et port du serveur, …)

==Apports personnels==

Ce projet nous a apporté de nouvelles compétences :
* Utilisation d'une plateforme OSGi
* Création de bundles OSGi (Notamment avec iPOJO)
* Utilisation de Drools
* Utilisation de REST

==Manuel Installation==

Les sources du projet sont disponibles sur le svn suivant :
https://subversion.assembla.com/svn/M2M-warehouse/

Notre projet est un projet Maven, il est donc nécessaire de le compiler grâce à cet outil. Le projet est découpé en trois modules distincts (TagSystem, BarcodeSystem, WarehouseServer) qu'il est possible de compiler séparément.
Les bundles générés doivent être déployés sur une plateforme OSGi (Par exemple Felix)

Le deploiement des bundles du projet nécessite des services fournis par d'autres bundles. Ces bundles nécessaires sont téléchargeables sur le svn dans le dossier Bundles présent à la racine du dépôt.

* Installation du lecteur NFC (Tikitag)

Pour utiliser le lecteur NFC il est nécessaire d'installer les librairies suivantes :
libccid
pcscd
pcsc-tools
libpcsclite1
libpcsclite-dev
* Installation de la scanette :
La scanette ne demande pas d'installation particulière, il suffit seulement de la brancher à un port USB.
* Base de données
La base de données doit être une base MySQL, car nous avons choisi ce type de base pour implementer le WarehouseManager. Cette base doit contenir une table VINS. Cette table peut être créée à l'aide de la requête suivante :
create table VINS (idVin integer auto_increment, name varchar(256), year integer, color varchar(10), price float, quantity integer, tag varchar(30), barcode varchar(30), primary key (idVin));

==Manuel Utilisateur==

L'utilisation de notre système est assez simple, que ce soit pour une utilisation avec la scanette ou le lecteur NFC elle se fait à travers l'interface. Cette interface permet à l'utilisateur de modifier la quantité d'un produit en ajoutant ou retirant une quantité choisie. Elle permet également d'ajouter un nouveau produit qui n'existerai pas dans la base.

Modification de la quantité d'un vin :
* Sélectionner l'action : Ajouter ou Supprimer
* Saisir la quantité à ajouter ou retirer
* Scanner le produit avec le lecteur NFC ou la scanette
* Valider le scan
* Le produit existe :
** Les informations et la nouvelle quantité pour le produit sont affichées
* Le produit n'existe pas :
** Compléter les informations concernant le produit dans le panel apparu
** Valider les informations entrées
*Possibilité de passer à un nouveau produit en recommençant la procédure

==Conclusion==

File:ArchitectureDetaillee.jpg

2012-04-05T22:15:42Z

Damontp:

Détection de trafic automobile et de d’attente aux feux

2012-04-05T22:15:19Z

Damontp: /* Manuel d'installation */

* Enseignant : Didier Donsez, Thomas Calmant
* Etudiants: CEYTE Christophe, DAMONT Pierre-Rémy.

==Description==

Ce projet a pour d'effectuer des décomptes de trafic automobiles à differents feux d'une ou plusieurs villes.
Les resultats seraient rendus à un serveur central sous forme de relevés.
Ces relevés pourraient être ensuite analysés et interprétés afin de modifier l'ordonnancement des feux, ou une modification de l'urbanisme.
Il pourrait aussi servir à reperer une voiture en infraction dans le cas du passage alors que le feu est rouge

==Materiel et configuration Requise==
* Deux ordinateurs dont un ayant une webcam
* OS : Linux ubuntu ou fedora
* Un JRE ou JDK java
* Plateforme OSGI Felix ou Equinox
* Librairie OpenCv
* Compilateur C/C++
* Apache Maven

==Architecture==
*Partie embarquée :
Cette partie est destinée a être embarquée sur les caméras positionnées aux feux à surveiller.
Composée de deux bundles proposant les services suivants : demarrer la Camera et recuperer le relevé de celle-ci.

*Partie fixe :
Cette partie est destinée a être installée sur un ordinateur fixe dont le role sera de récupérer les données des différentes caméras déployées.
Composée de deux bundles proposant les services suivants : demarrer les acquisitions et recuperer les relevés.

==Manuel d'installation==

-Récuperer les sources a l'adresse svn suivante :

http://subversion.assembla.com/svn/m2m_surveillance_flux_autoroutiers

-Le projet se découpe en 4 sous-projets maven et une partie C++:

La partie n°1 nommée Camera_Finale est à compiler obligatoirement sur le pc embarquant la caméra, du fait de la non portabilité du code C++.

Ces 2 parties sont à compiler et à déployer sur le pc embarqué avec la caméra
Partie n°2 nommée CameraServeur
Partie n°3 nommée CameraServlet

Ces 2 parties sont à compiler et à déployer sur le pc jouant le role du serveur
Partie n°3 nommée ServeurServlet
Partie n°3 nommée ServeurCentral

En effet le projet étant encore en développement, les chemins d'accès aux relevés et à l'executable doivent être modifiés.
(Notamment encas de deploiement sous système windows)

Architecture fonctionnelle :

[[File:Example.jpg]]

Architecture détaillée :

[[File:ArchitectureDetaillee.jpg]]

==Manuel d'utilisation==

Un fois les parties compilées avec les chemins adéquats, il faut insérer dans le répertoire bundle de felix les paquets générés par maven.
Ces paquets se situent dans le répertoire target du sous-projet maven correspondant à la partie en question.

Ainsi sous la plate-forme OSGI embarqué sur l'ordinateur possédant la caméra nous devons avoir ces bundles déployés :

camera-broker-bundle-0-SNAPSHOT.jar
camera-broker-servlet-bundle-0.0.1-SNAPSHOT.jar

Sous la pate-forme OSGI du serveur central ces deux-la :

information-broker-bundle-0.0.1-SNAPSHOT.jar
information-broker-servlet-bundle-0.0.1-SNAPSHOT.jar

Une fois ces bundles déployés un simple accés à la servlet du serveur via un navigateur web a l'url : http://localhost:8080/camera permettra de démarrerl'acquisition sur la caméra distante.

Pour récupérer le relevé de la caméra un accés à l'url : http://localhost:8080/releve permettra de télécharger le fichier releve.xml généré par le serveur de la caméra distante.

Par défaut le téléchargement à lieu dans /home/"nom d'utilisateur" (Ce nom est a préciser par l'utilisateur lors de la compilation)

==Fonctionnalités envisagées==

Nous souhaitions disposer de n caméras, de pouvoir déclencher leur acquisition à distance sur une période donnée, et d'effectuer une collecte automatisée des relevés générés par ces caméras.
Ces relevés seraient stockés dans une base de données en attendant d'être traitées par un outil d'analyse.
Nous souhaitions aussi pouvoir détecter une inffraction.

D'autre part, bien qu'il ne s'agisse pas d'un projet ayant pour sujet le traitement d'image, l'objectif était d'avoir un système de reconnaissance minimal.

==Fonctionnalités réalisées==

Nous n'avons pu develloper un gestion de n caméras, actuellement le système ne fonctionne qu'avec un serveur central et une partie deportée abritant la caméra (simple webcam dans notre cas).

Nous avons mis en place un service de comptage minimal, le défaut étant qu'il reconnait tout les objets en mouvement, pas seulement les voitures, ce qui fausse le résultat.

L'édition de relevé a partir du comptage effectué est fonctionnel.
Ce relevé est téléchargeable a partir du serveur central, la remontée d'information est donc opérationnellev ia le protocole HTTP.

==Améliorations==

Il resterait à étendre la gestion des caméras à partir du serveur.
Par exemple fournir une api web permmettant d'ajouter ou de retirer des caméras suivants leur adresse.

D'autre part si nous avions la possibilité d'être connecter à l'automate du feu, nous pourrions lancer les aquisitions suivants l'état du feu.
Actuellement nous avons lançons l'acquisition pour une durée pré-determinée.

L'édition de relevés pourrait être ainsi plus conséquente, et s'étaler sur une journée entière et prendre ne compte plus d'informations (infractions par exemple).

La reconnaissance pourrait être affinée afin de reconnaitre des objets plus précis (seulement des voitures).

Un outil d'analyse des données sur le serveur central, permettant d'éditer des courbes par exemple serait utile à l'interprétation des résultats.

==Difficultés rencontrées==

- Découverte d'OSGI, packager les composants en bundle.

- Trouver un système de reconnaissance un minimum efficace et rapide, la solution actuelle étant un code open source "FastMatchTemplate".

- Appeller ce code C/C++ non protable à partir d'un bundle.

File:Example.jpg

2012-04-05T22:13:13Z

Damontp:

Détection de trafic automobile et de d’attente aux feux

2012-04-05T22:12:49Z

Damontp: /* Manuel d'installation */

* Enseignant : Didier Donsez, Thomas Calmant
* Etudiants: CEYTE Christophe, DAMONT Pierre-Rémy.

==Description==

Ce projet a pour d'effectuer des décomptes de trafic automobiles à differents feux d'une ou plusieurs villes.
Les resultats seraient rendus à un serveur central sous forme de relevés.
Ces relevés pourraient être ensuite analysés et interprétés afin de modifier l'ordonnancement des feux, ou une modification de l'urbanisme.
Il pourrait aussi servir à reperer une voiture en infraction dans le cas du passage alors que le feu est rouge

==Materiel et configuration Requise==
* Deux ordinateurs dont un ayant une webcam
* OS : Linux ubuntu ou fedora
* Un JRE ou JDK java
* Plateforme OSGI Felix ou Equinox
* Librairie OpenCv
* Compilateur C/C++
* Apache Maven

==Architecture==
*Partie embarquée :
Cette partie est destinée a être embarquée sur les caméras positionnées aux feux à surveiller.
Composée de deux bundles proposant les services suivants : demarrer la Camera et recuperer le relevé de celle-ci.

*Partie fixe :
Cette partie est destinée a être installée sur un ordinateur fixe dont le role sera de récupérer les données des différentes caméras déployées.
Composée de deux bundles proposant les services suivants : demarrer les acquisitions et recuperer les relevés.

==Manuel d'installation==

-Récuperer les sources a l'adresse svn suivante :

http://subversion.assembla.com/svn/m2m_surveillance_flux_autoroutiers

-Le projet se découpe en 4 sous-projets maven et une partie C++:

La partie n°1 nommée Camera_Finale est à compiler obligatoirement sur le pc embarquant la caméra, du fait de la non portabilité du code C++.

Ces 2 parties sont à compiler et à déployer sur le pc embarqué avec la caméra
Partie n°2 nommée CameraServeur
Partie n°3 nommée CameraServlet

Ces 2 parties sont à compiler et à déployer sur le pc jouant le role du serveur
Partie n°3 nommée ServeurServlet
Partie n°3 nommée ServeurCentral

En effet le projet étant encore en développement, les chemins d'accès aux relevés et à l'executable doivent être modifiés.
(Notamment encas de deploiement sous système windows)

[[File:Example.jpg]]

==Manuel d'utilisation==

Un fois les parties compilées avec les chemins adéquats, il faut insérer dans le répertoire bundle de felix les paquets générés par maven.
Ces paquets se situent dans le répertoire target du sous-projet maven correspondant à la partie en question.

Ainsi sous la plate-forme OSGI embarqué sur l'ordinateur possédant la caméra nous devons avoir ces bundles déployés :

camera-broker-bundle-0-SNAPSHOT.jar
camera-broker-servlet-bundle-0.0.1-SNAPSHOT.jar

Sous la pate-forme OSGI du serveur central ces deux-la :

information-broker-bundle-0.0.1-SNAPSHOT.jar
information-broker-servlet-bundle-0.0.1-SNAPSHOT.jar

Une fois ces bundles déployés un simple accés à la servlet du serveur via un navigateur web a l'url : http://localhost:8080/camera permettra de démarrerl'acquisition sur la caméra distante.

Pour récupérer le relevé de la caméra un accés à l'url : http://localhost:8080/releve permettra de télécharger le fichier releve.xml généré par le serveur de la caméra distante.

Par défaut le téléchargement à lieu dans /home/"nom d'utilisateur" (Ce nom est a préciser par l'utilisateur lors de la compilation)

==Fonctionnalités envisagées==

Nous souhaitions disposer de n caméras, de pouvoir déclencher leur acquisition à distance sur une période donnée, et d'effectuer une collecte automatisée des relevés générés par ces caméras.
Ces relevés seraient stockés dans une base de données en attendant d'être traitées par un outil d'analyse.
Nous souhaitions aussi pouvoir détecter une inffraction.

D'autre part, bien qu'il ne s'agisse pas d'un projet ayant pour sujet le traitement d'image, l'objectif était d'avoir un système de reconnaissance minimal.

==Fonctionnalités réalisées==

Nous n'avons pu develloper un gestion de n caméras, actuellement le système ne fonctionne qu'avec un serveur central et une partie deportée abritant la caméra (simple webcam dans notre cas).

Nous avons mis en place un service de comptage minimal, le défaut étant qu'il reconnait tout les objets en mouvement, pas seulement les voitures, ce qui fausse le résultat.

L'édition de relevé a partir du comptage effectué est fonctionnel.
Ce relevé est téléchargeable a partir du serveur central, la remontée d'information est donc opérationnellev ia le protocole HTTP.

==Améliorations==

Il resterait à étendre la gestion des caméras à partir du serveur.
Par exemple fournir une api web permmettant d'ajouter ou de retirer des caméras suivants leur adresse.

D'autre part si nous avions la possibilité d'être connecter à l'automate du feu, nous pourrions lancer les aquisitions suivants l'état du feu.
Actuellement nous avons lançons l'acquisition pour une durée pré-determinée.

L'édition de relevés pourrait être ainsi plus conséquente, et s'étaler sur une journée entière et prendre ne compte plus d'informations (infractions par exemple).

La reconnaissance pourrait être affinée afin de reconnaitre des objets plus précis (seulement des voitures).

Un outil d'analyse des données sur le serveur central, permettant d'éditer des courbes par exemple serait utile à l'interprétation des résultats.

==Difficultés rencontrées==

- Découverte d'OSGI, packager les composants en bundle.

- Trouver un système de reconnaissance un minimum efficace et rapide, la solution actuelle étant un code open source "FastMatchTemplate".

- Appeller ce code C/C++ non protable à partir d'un bundle.

Détection de trafic automobile et de d’attente aux feux

2012-04-05T22:11:30Z

Damontp: /* Manuel d'installation */

* Enseignant : Didier Donsez, Thomas Calmant
* Etudiants: CEYTE Christophe, DAMONT Pierre-Rémy.

==Description==

Ce projet a pour d'effectuer des décomptes de trafic automobiles à differents feux d'une ou plusieurs villes.
Les resultats seraient rendus à un serveur central sous forme de relevés.
Ces relevés pourraient être ensuite analysés et interprétés afin de modifier l'ordonnancement des feux, ou une modification de l'urbanisme.
Il pourrait aussi servir à reperer une voiture en infraction dans le cas du passage alors que le feu est rouge

==Materiel et configuration Requise==
* Deux ordinateurs dont un ayant une webcam
* OS : Linux ubuntu ou fedora
* Un JRE ou JDK java
* Plateforme OSGI Felix ou Equinox
* Librairie OpenCv
* Compilateur C/C++
* Apache Maven

==Architecture==
*Partie embarquée :
Cette partie est destinée a être embarquée sur les caméras positionnées aux feux à surveiller.
Composée de deux bundles proposant les services suivants : demarrer la Camera et recuperer le relevé de celle-ci.

*Partie fixe :
Cette partie est destinée a être installée sur un ordinateur fixe dont le role sera de récupérer les données des différentes caméras déployées.
Composée de deux bundles proposant les services suivants : demarrer les acquisitions et recuperer les relevés.

==Manuel d'installation==

-Récuperer les sources a l'adresse svn suivante :

http://subversion.assembla.com/svn/m2m_surveillance_flux_autoroutiers

-Le projet se découpe en 4 sous-projets maven et une partie C++:

La partie n°1 nommée Camera_Finale est à compiler obligatoirement sur le pc embarquant la caméra, du fait de la non portabilité du code C++.

Ces 2 parties sont à compiler et à déployer sur le pc embarqué avec la caméra
Partie n°2 nommée CameraServeur
Partie n°3 nommée CameraServlet

Ces 2 parties sont à compiler et à déployer sur le pc jouant le role du serveur
Partie n°3 nommée ServeurServlet
Partie n°3 nommée ServeurCentral

En effet le projet étant encore en développement, les chemins d'accès aux relevés et à l'executable doivent être modifiés.
(Notamment encas de deploiement sous système windows)

[[Media:/home/damont/Downloads/architecture.jpg]]

[[Media:http://air.imag.fr/mediawiki/index.php/File:Architecture.jpg]]

==Manuel d'utilisation==

Un fois les parties compilées avec les chemins adéquats, il faut insérer dans le répertoire bundle de felix les paquets générés par maven.
Ces paquets se situent dans le répertoire target du sous-projet maven correspondant à la partie en question.

Ainsi sous la plate-forme OSGI embarqué sur l'ordinateur possédant la caméra nous devons avoir ces bundles déployés :

camera-broker-bundle-0-SNAPSHOT.jar
camera-broker-servlet-bundle-0.0.1-SNAPSHOT.jar

Sous la pate-forme OSGI du serveur central ces deux-la :

information-broker-bundle-0.0.1-SNAPSHOT.jar
information-broker-servlet-bundle-0.0.1-SNAPSHOT.jar

Une fois ces bundles déployés un simple accés à la servlet du serveur via un navigateur web a l'url : http://localhost:8080/camera permettra de démarrerl'acquisition sur la caméra distante.

Pour récupérer le relevé de la caméra un accés à l'url : http://localhost:8080/releve permettra de télécharger le fichier releve.xml généré par le serveur de la caméra distante.

Par défaut le téléchargement à lieu dans /home/"nom d'utilisateur" (Ce nom est a préciser par l'utilisateur lors de la compilation)

==Fonctionnalités envisagées==

Nous souhaitions disposer de n caméras, de pouvoir déclencher leur acquisition à distance sur une période donnée, et d'effectuer une collecte automatisée des relevés générés par ces caméras.
Ces relevés seraient stockés dans une base de données en attendant d'être traitées par un outil d'analyse.
Nous souhaitions aussi pouvoir détecter une inffraction.

D'autre part, bien qu'il ne s'agisse pas d'un projet ayant pour sujet le traitement d'image, l'objectif était d'avoir un système de reconnaissance minimal.

==Fonctionnalités réalisées==

Nous n'avons pu develloper un gestion de n caméras, actuellement le système ne fonctionne qu'avec un serveur central et une partie deportée abritant la caméra (simple webcam dans notre cas).

Nous avons mis en place un service de comptage minimal, le défaut étant qu'il reconnait tout les objets en mouvement, pas seulement les voitures, ce qui fausse le résultat.

L'édition de relevé a partir du comptage effectué est fonctionnel.
Ce relevé est téléchargeable a partir du serveur central, la remontée d'information est donc opérationnellev ia le protocole HTTP.

==Améliorations==

Il resterait à étendre la gestion des caméras à partir du serveur.
Par exemple fournir une api web permmettant d'ajouter ou de retirer des caméras suivants leur adresse.

D'autre part si nous avions la possibilité d'être connecter à l'automate du feu, nous pourrions lancer les aquisitions suivants l'état du feu.
Actuellement nous avons lançons l'acquisition pour une durée pré-determinée.

L'édition de relevés pourrait être ainsi plus conséquente, et s'étaler sur une journée entière et prendre ne compte plus d'informations (infractions par exemple).

La reconnaissance pourrait être affinée afin de reconnaitre des objets plus précis (seulement des voitures).

Un outil d'analyse des données sur le serveur central, permettant d'éditer des courbes par exemple serait utile à l'interprétation des résultats.

==Difficultés rencontrées==

- Découverte d'OSGI, packager les composants en bundle.

- Trouver un système de reconnaissance un minimum efficace et rapide, la solution actuelle étant un code open source "FastMatchTemplate".

- Appeller ce code C/C++ non protable à partir d'un bundle.

File:Architecture.jpg

2012-04-05T22:10:28Z

Damontp: uploaded a new version of "File:Architecture.jpg"

File:Architecture.jpg

2012-04-05T22:09:49Z

Damontp:

Détection de trafic automobile et de d’attente aux feux

2012-04-05T22:09:06Z

Damontp: /* Manuel d'installation */

* Enseignant : Didier Donsez, Thomas Calmant
* Etudiants: CEYTE Christophe, DAMONT Pierre-Rémy.

==Description==

Ce projet a pour d'effectuer des décomptes de trafic automobiles à differents feux d'une ou plusieurs villes.
Les resultats seraient rendus à un serveur central sous forme de relevés.
Ces relevés pourraient être ensuite analysés et interprétés afin de modifier l'ordonnancement des feux, ou une modification de l'urbanisme.
Il pourrait aussi servir à reperer une voiture en infraction dans le cas du passage alors que le feu est rouge

==Materiel et configuration Requise==
* Deux ordinateurs dont un ayant une webcam
* OS : Linux ubuntu ou fedora
* Un JRE ou JDK java
* Plateforme OSGI Felix ou Equinox
* Librairie OpenCv
* Compilateur C/C++
* Apache Maven

==Architecture==
*Partie embarquée :
Cette partie est destinée a être embarquée sur les caméras positionnées aux feux à surveiller.
Composée de deux bundles proposant les services suivants : demarrer la Camera et recuperer le relevé de celle-ci.

*Partie fixe :
Cette partie est destinée a être installée sur un ordinateur fixe dont le role sera de récupérer les données des différentes caméras déployées.
Composée de deux bundles proposant les services suivants : demarrer les acquisitions et recuperer les relevés.

==Manuel d'installation==

-Récuperer les sources a l'adresse svn suivante :

http://subversion.assembla.com/svn/m2m_surveillance_flux_autoroutiers

-Le projet se découpe en 4 sous-projets maven et une partie C++:

La partie n°1 nommée Camera_Finale est à compiler obligatoirement sur le pc embarquant la caméra, du fait de la non portabilité du code C++.

Ces 2 parties sont à compiler et à déployer sur le pc embarqué avec la caméra
Partie n°2 nommée CameraServeur
Partie n°3 nommée CameraServlet

Ces 2 parties sont à compiler et à déployer sur le pc jouant le role du serveur
Partie n°3 nommée ServeurServlet
Partie n°3 nommée ServeurCentral

En effet le projet étant encore en développement, les chemins d'accès aux relevés et à l'executable doivent être modifiés.
(Notamment encas de deploiement sous système windows)

[[Media:/home/damont/Downloads/architecture.jpg]]

==Manuel d'utilisation==

Un fois les parties compilées avec les chemins adéquats, il faut insérer dans le répertoire bundle de felix les paquets générés par maven.
Ces paquets se situent dans le répertoire target du sous-projet maven correspondant à la partie en question.

Ainsi sous la plate-forme OSGI embarqué sur l'ordinateur possédant la caméra nous devons avoir ces bundles déployés :

camera-broker-bundle-0-SNAPSHOT.jar
camera-broker-servlet-bundle-0.0.1-SNAPSHOT.jar

Sous la pate-forme OSGI du serveur central ces deux-la :

information-broker-bundle-0.0.1-SNAPSHOT.jar
information-broker-servlet-bundle-0.0.1-SNAPSHOT.jar

Une fois ces bundles déployés un simple accés à la servlet du serveur via un navigateur web a l'url : http://localhost:8080/camera permettra de démarrerl'acquisition sur la caméra distante.

Pour récupérer le relevé de la caméra un accés à l'url : http://localhost:8080/releve permettra de télécharger le fichier releve.xml généré par le serveur de la caméra distante.

Par défaut le téléchargement à lieu dans /home/"nom d'utilisateur" (Ce nom est a préciser par l'utilisateur lors de la compilation)

==Fonctionnalités envisagées==

Nous souhaitions disposer de n caméras, de pouvoir déclencher leur acquisition à distance sur une période donnée, et d'effectuer une collecte automatisée des relevés générés par ces caméras.
Ces relevés seraient stockés dans une base de données en attendant d'être traitées par un outil d'analyse.
Nous souhaitions aussi pouvoir détecter une inffraction.

D'autre part, bien qu'il ne s'agisse pas d'un projet ayant pour sujet le traitement d'image, l'objectif était d'avoir un système de reconnaissance minimal.

==Fonctionnalités réalisées==

Nous n'avons pu develloper un gestion de n caméras, actuellement le système ne fonctionne qu'avec un serveur central et une partie deportée abritant la caméra (simple webcam dans notre cas).

Nous avons mis en place un service de comptage minimal, le défaut étant qu'il reconnait tout les objets en mouvement, pas seulement les voitures, ce qui fausse le résultat.

L'édition de relevé a partir du comptage effectué est fonctionnel.
Ce relevé est téléchargeable a partir du serveur central, la remontée d'information est donc opérationnellev ia le protocole HTTP.

==Améliorations==

Il resterait à étendre la gestion des caméras à partir du serveur.
Par exemple fournir une api web permmettant d'ajouter ou de retirer des caméras suivants leur adresse.

D'autre part si nous avions la possibilité d'être connecter à l'automate du feu, nous pourrions lancer les aquisitions suivants l'état du feu.
Actuellement nous avons lançons l'acquisition pour une durée pré-determinée.

L'édition de relevés pourrait être ainsi plus conséquente, et s'étaler sur une journée entière et prendre ne compte plus d'informations (infractions par exemple).

La reconnaissance pourrait être affinée afin de reconnaitre des objets plus précis (seulement des voitures).

Un outil d'analyse des données sur le serveur central, permettant d'éditer des courbes par exemple serait utile à l'interprétation des résultats.

==Difficultés rencontrées==

- Découverte d'OSGI, packager les composants en bundle.

- Trouver un système de reconnaissance un minimum efficace et rapide, la solution actuelle étant un code open source "FastMatchTemplate".

- Appeller ce code C/C++ non protable à partir d'un bundle.

Détection de trafic automobile et de d’attente aux feux

2012-04-05T22:06:16Z

Damontp: /* Manuel d'utilisation */

* Enseignant : Didier Donsez, Thomas Calmant
* Etudiants: CEYTE Christophe, DAMONT Pierre-Rémy.

==Description==

Ce projet a pour d'effectuer des décomptes de trafic automobiles à differents feux d'une ou plusieurs villes.
Les resultats seraient rendus à un serveur central sous forme de relevés.
Ces relevés pourraient être ensuite analysés et interprétés afin de modifier l'ordonnancement des feux, ou une modification de l'urbanisme.
Il pourrait aussi servir à reperer une voiture en infraction dans le cas du passage alors que le feu est rouge

==Materiel et configuration Requise==
* Deux ordinateurs dont un ayant une webcam
* OS : Linux ubuntu ou fedora
* Un JRE ou JDK java
* Plateforme OSGI Felix ou Equinox
* Librairie OpenCv
* Compilateur C/C++
* Apache Maven

==Architecture==
*Partie embarquée :
Cette partie est destinée a être embarquée sur les caméras positionnées aux feux à surveiller.
Composée de deux bundles proposant les services suivants : demarrer la Camera et recuperer le relevé de celle-ci.

*Partie fixe :
Cette partie est destinée a être installée sur un ordinateur fixe dont le role sera de récupérer les données des différentes caméras déployées.
Composée de deux bundles proposant les services suivants : demarrer les acquisitions et recuperer les relevés.

==Manuel d'installation==

-Récuperer les sources a l'adresse svn suivante :

http://subversion.assembla.com/svn/m2m_surveillance_flux_autoroutiers

-Le projet se découpe en 4 sous-projets maven et une partie C++:

La partie n°1 nommée Camera_Finale est à compiler obligatoirement sur le pc embarquant la caméra, du fait de la non portabilité du code C++.

Ces 2 parties sont à compiler et à déployer sur le pc embarqué avec la caméra
Partie n°2 nommée CameraServeur
Partie n°3 nommée CameraServlet

Ces 2 parties sont à compiler et à déployer sur le pc jouant le role du serveur
Partie n°3 nommée ServeurServlet
Partie n°3 nommée ServeurCentral

En effet le projet étant encore en développement, les chemins d'accès aux relevés et à l'executable doivent être modifiés.
(Notamment encas de deploiement sous système windows)

==Manuel d'utilisation==

Un fois les parties compilées avec les chemins adéquats, il faut insérer dans le répertoire bundle de felix les paquets générés par maven.
Ces paquets se situent dans le répertoire target du sous-projet maven correspondant à la partie en question.

Ainsi sous la plate-forme OSGI embarqué sur l'ordinateur possédant la caméra nous devons avoir ces bundles déployés :

camera-broker-bundle-0-SNAPSHOT.jar
camera-broker-servlet-bundle-0.0.1-SNAPSHOT.jar

Sous la pate-forme OSGI du serveur central ces deux-la :

information-broker-bundle-0.0.1-SNAPSHOT.jar
information-broker-servlet-bundle-0.0.1-SNAPSHOT.jar

Une fois ces bundles déployés un simple accés à la servlet du serveur via un navigateur web a l'url : http://localhost:8080/camera permettra de démarrerl'acquisition sur la caméra distante.

Pour récupérer le relevé de la caméra un accés à l'url : http://localhost:8080/releve permettra de télécharger le fichier releve.xml généré par le serveur de la caméra distante.

Par défaut le téléchargement à lieu dans /home/"nom d'utilisateur" (Ce nom est a préciser par l'utilisateur lors de la compilation)

==Fonctionnalités envisagées==

Nous souhaitions disposer de n caméras, de pouvoir déclencher leur acquisition à distance sur une période donnée, et d'effectuer une collecte automatisée des relevés générés par ces caméras.
Ces relevés seraient stockés dans une base de données en attendant d'être traitées par un outil d'analyse.
Nous souhaitions aussi pouvoir détecter une inffraction.

D'autre part, bien qu'il ne s'agisse pas d'un projet ayant pour sujet le traitement d'image, l'objectif était d'avoir un système de reconnaissance minimal.

==Fonctionnalités réalisées==

Nous n'avons pu develloper un gestion de n caméras, actuellement le système ne fonctionne qu'avec un serveur central et une partie deportée abritant la caméra (simple webcam dans notre cas).

Nous avons mis en place un service de comptage minimal, le défaut étant qu'il reconnait tout les objets en mouvement, pas seulement les voitures, ce qui fausse le résultat.

L'édition de relevé a partir du comptage effectué est fonctionnel.
Ce relevé est téléchargeable a partir du serveur central, la remontée d'information est donc opérationnellev ia le protocole HTTP.

==Améliorations==

Il resterait à étendre la gestion des caméras à partir du serveur.
Par exemple fournir une api web permmettant d'ajouter ou de retirer des caméras suivants leur adresse.

D'autre part si nous avions la possibilité d'être connecter à l'automate du feu, nous pourrions lancer les aquisitions suivants l'état du feu.
Actuellement nous avons lançons l'acquisition pour une durée pré-determinée.

L'édition de relevés pourrait être ainsi plus conséquente, et s'étaler sur une journée entière et prendre ne compte plus d'informations (infractions par exemple).

La reconnaissance pourrait être affinée afin de reconnaitre des objets plus précis (seulement des voitures).

Un outil d'analyse des données sur le serveur central, permettant d'éditer des courbes par exemple serait utile à l'interprétation des résultats.

==Difficultés rencontrées==

- Découverte d'OSGI, packager les composants en bundle.

- Trouver un système de reconnaissance un minimum efficace et rapide, la solution actuelle étant un code open source "FastMatchTemplate".

- Appeller ce code C/C++ non protable à partir d'un bundle.

ECOM Warehouse Management System

2012-04-05T22:04:11Z

Damontp: /* Manuel Installation */

* Enseignant : Didier Donsez
* Etudiants M2PGI : CASAGRANDE Thierry, RICHARD David

==Matériel==
* RFID + QRCode + Barcode 1D
* USB Barcode reader
* USB NFC Reader

==Logiciels==
* Apache Felix
* Drools Expert

==Introduction==

Ce projet a pour but de fournir un système permettant la gestion d'un entrepôt. Le système doit gérer les entrées et sorties de produits. Un moteur de règles permettra d'analyser les différentes opérations et pour certains évènements particuliers (par exemple un produit bientôt en rupture de stock) le manager sera notifié.
Les mouvements de stock seront effectués à l'aide d'une scanette et d'un lecteur NFC.
Nous avons choisi de gérer un stockage de bouteilles de vins.

==Architecture==

Notre système se compose de trois parties :
Le "Tag System" qui permet d'utiliser le lecteur NFC pour communiquer avec le server de l'entrepôt
Le "Barcode System" qui permet d'utiliser une scanette pour communiquer avec le server de l'entrepôt
Le "Warehouse Server" qui permet de gérer l'entrepôt

[[Image:Architecture_V2.jpg|Architecture]]

Tag System et Barcode System sont tout deux composés de deux modules :
* Un module « Reader » (TagReader et BarcodeReader) qui permet de scanner les objets et de communiquer avec le serveur grâce à des requêtes REST
* Un module « GUI » (TagGUI et BarcodeGUI) qui offre une interface en Swing pour utiliser le module « Reader »

Warehouse Server :
* Une base de données pour stocker les informations des produits de l'entrepôt
* Un module « WarehouseManager » permettant d'effectuer des opérations sur la base de données
* Deux modules « Solver » (TagSolver et BarcodeSolver) exposant des services REST afin de récuperer les informations envoyées par les « Readers », les analyser et effectuer l'opération requise
* Un module « ManagerNotifier » offrant la possibilité d'envoyer des emails au manager de l'entrepôt (utilisation de l'API JavaMail)
* Un moteur de règles basé sur Drools pour implémenter une logique métier

Les différents modules étant des bundles OSGi, les systèmes devront tourner sur une plateforme OSGi.

==Evolutions envisageables==

L'objectif de ce projet était de réaliser les fonctionnalités suivantes :
* Ajouter un produit grâce à un lecteur NFC
* Ajouter un produit grâce à une scanette
* Retirer des produits du stock grâce à un lecteur NFC
* Retirer des produits du stock grâce à une scanette
* Envoyer un mail au manager en cas de stock faible d'un produit
* Envoyer un mail au manager régulièrement pour l'informer des variations de stock
* Stocker les informations des produits dans une base de données
* Interagir avec la base de données

Toutes les fonctionnalités ont été réalisées excepté l'envoi d'un mail au manager pour l'informer des variations de stock.

==Difficultés rencontrées==

L'architecture a été pensée de manière à pouvoir facilement ajouter des modules supplémentaires pour interagir avec les « Reader », en plus de l'interface graphique déjà présente. Par exemple une console web, une interface en ligne de commmande ou une interface orientée smartphone (ce qui n'est pas le cas de l'interface actuelle).

Notre système permet la gestion de bouteilles de vin. Il aurait cependant été intéressant d'offrir au manager la possibilité de gérer d'autres produits en lui proposant une gestion générique des produits stockés.

Le moteur de règles pourrait être exploité d'une meilleure manière, de nouvelles règles plus élaborées pourraient être créées.

Permettre à l'utilisateur de configurer les éventuelles options d'un modules (Mail du manager, serveur de messagerie, url et port du serveur, …)

==Apports personnels==

Ce projet nous a apporté de nouvelles compétences :
* Utilisation d'une plateforme OSGi
* Création de bundles OSGi (Notamment avec iPOJO)
* Utilisation de Drools
* Utilisation de REST

==Manuel Installation==

Les sources du projet sont disponibles sur le svn suivant :
https://subversion.assembla.com/svn/M2M-warehouse/

Notre projet est un projet Maven, il est donc nécessaire de le compiler grâce à cet outil. Le projet est découpé en trois modules distincts (TagSystem, BarcodeSystem, WarehouseServer) qu'il est possible de compiler séparément.
Les bundles générés doivent être déployés sur une plateforme OSGi (Par exemple Felix)

==Manuel Utilisateur==

L'utilisation de notre système est assez simple, que ce soit pour une utilisation avec la scanette ou le lecteur NFC elle se fait à travers l'interface. Cette interface permet à l'utilisateur de modifier la quantité d'un produit en ajoutant ou retirant une quantité choisie. Elle permet également d'ajouter un nouveau produit qui n'existerai pas dans la base.

Modification de la quantité d'un vin :
* Sélectionner l'action : Ajouter ou Supprimer
* Saisir la quantité à ajouter ou retirer
* Scanner le produit avec le lecteur NFC ou la scanette
* Valider le scan
* Le produit existe :
** Les informations et la nouvelle quantité pour le produit sont affichées
* Le produit n'existe pas :
** Compléter les informations concernant le produit dans le panel apparu
** Valider les informations entrées
*Possibilité de passer à un nouveau produit en recommençant la procédure

==Conclusion==

ECOM Warehouse Management System

2012-04-05T22:03:24Z

Damontp: /* Manuel Installation */

* Enseignant : Didier Donsez
* Etudiants M2PGI : CASAGRANDE Thierry, RICHARD David

==Matériel==
* RFID + QRCode + Barcode 1D
* USB Barcode reader
* USB NFC Reader

==Logiciels==
* Apache Felix
* Drools Expert

==Introduction==

Ce projet a pour but de fournir un système permettant la gestion d'un entrepôt. Le système doit gérer les entrées et sorties de produits. Un moteur de règles permettra d'analyser les différentes opérations et pour certains évènements particuliers (par exemple un produit bientôt en rupture de stock) le manager sera notifié.
Les mouvements de stock seront effectués à l'aide d'une scanette et d'un lecteur NFC.
Nous avons choisi de gérer un stockage de bouteilles de vins.

==Architecture==

Notre système se compose de trois parties :
Le "Tag System" qui permet d'utiliser le lecteur NFC pour communiquer avec le server de l'entrepôt
Le "Barcode System" qui permet d'utiliser une scanette pour communiquer avec le server de l'entrepôt
Le "Warehouse Server" qui permet de gérer l'entrepôt

[[Image:Architecture_V2.jpg|Architecture]]

Tag System et Barcode System sont tout deux composés de deux modules :
* Un module « Reader » (TagReader et BarcodeReader) qui permet de scanner les objets et de communiquer avec le serveur grâce à des requêtes REST
* Un module « GUI » (TagGUI et BarcodeGUI) qui offre une interface en Swing pour utiliser le module « Reader »

Warehouse Server :
* Une base de données pour stocker les informations des produits de l'entrepôt
* Un module « WarehouseManager » permettant d'effectuer des opérations sur la base de données
* Deux modules « Solver » (TagSolver et BarcodeSolver) exposant des services REST afin de récuperer les informations envoyées par les « Readers », les analyser et effectuer l'opération requise
* Un module « ManagerNotifier » offrant la possibilité d'envoyer des emails au manager de l'entrepôt (utilisation de l'API JavaMail)
* Un moteur de règles basé sur Drools pour implémenter une logique métier

Les différents modules étant des bundles OSGi, les systèmes devront tourner sur une plateforme OSGi.

==Evolutions envisageables==

L'objectif de ce projet était de réaliser les fonctionnalités suivantes :
* Ajouter un produit grâce à un lecteur NFC
* Ajouter un produit grâce à une scanette
* Retirer des produits du stock grâce à un lecteur NFC
* Retirer des produits du stock grâce à une scanette
* Envoyer un mail au manager en cas de stock faible d'un produit
* Envoyer un mail au manager régulièrement pour l'informer des variations de stock
* Stocker les informations des produits dans une base de données
* Interagir avec la base de données

Toutes les fonctionnalités ont été réalisées excepté l'envoi d'un mail au manager pour l'informer des variations de stock.

==Difficultés rencontrées==

L'architecture a été pensée de manière à pouvoir facilement ajouter des modules supplémentaires pour interagir avec les « Reader », en plus de l'interface graphique déjà présente. Par exemple une console web, une interface en ligne de commmande ou une interface orientée smartphone (ce qui n'est pas le cas de l'interface actuelle).

Notre système permet la gestion de bouteilles de vin. Il aurait cependant été intéressant d'offrir au manager la possibilité de gérer d'autres produits en lui proposant une gestion générique des produits stockés.

Le moteur de règles pourrait être exploité d'une meilleure manière, de nouvelles règles plus élaborées pourraient être créées.

Permettre à l'utilisateur de configurer les éventuelles options d'un modules (Mail du manager, serveur de messagerie, url et port du serveur, …)

==Apports personnels==

Ce projet nous a apporté de nouvelles compétences :
* Utilisation d'une plateforme OSGi
* Création de bundles OSGi (Notamment avec iPOJO)
* Utilisation de Drools
* Utilisation de REST

==Manuel Installation==

Les sources du projet sont disponible sur le svn suivant :
https://subversion.assembla.com/svn/M2M-warehouse/

Notre projet est un projet Maven, il est donc nécessaire de le compiler grâce à cet outil. Le projet est découpé en trois modules distincts (TagSystem, BarcodeSystem, WarehouseServer) qu'il est possible de compiler séparément.
Les bundles générés doivent être déployés sur une plateforme OSGi (Par exemple Felix)

==Manuel Utilisateur==

L'utilisation de notre système est assez simple, que ce soit pour une utilisation avec la scanette ou le lecteur NFC elle se fait à travers l'interface. Cette interface permet à l'utilisateur de modifier la quantité d'un produit en ajoutant ou retirant une quantité choisie. Elle permet également d'ajouter un nouveau produit qui n'existerai pas dans la base.

Modification de la quantité d'un vin :
* Sélectionner l'action : Ajouter ou Supprimer
* Saisir la quantité à ajouter ou retirer
* Scanner le produit avec le lecteur NFC ou la scanette
* Valider le scan
* Le produit existe :
** Les informations et la nouvelle quantité pour le produit sont affichées
* Le produit n'existe pas :
** Compléter les informations concernant le produit dans le panel apparu
** Valider les informations entrées
*Possibilité de passer à un nouveau produit en recommençant la procédure

==Conclusion==

ECOM Warehouse Management System

2012-04-05T22:03:03Z

Damontp: /* Manuel Installation */

* Enseignant : Didier Donsez
* Etudiants M2PGI : CASAGRANDE Thierry, RICHARD David

==Matériel==
* RFID + QRCode + Barcode 1D
* USB Barcode reader
* USB NFC Reader

==Logiciels==
* Apache Felix
* Drools Expert

==Introduction==

Ce projet a pour but de fournir un système permettant la gestion d'un entrepôt. Le système doit gérer les entrées et sorties de produits. Un moteur de règles permettra d'analyser les différentes opérations et pour certains évènements particuliers (par exemple un produit bientôt en rupture de stock) le manager sera notifié.
Les mouvements de stock seront effectués à l'aide d'une scanette et d'un lecteur NFC.
Nous avons choisi de gérer un stockage de bouteilles de vins.

==Architecture==

Notre système se compose de trois parties :
Le "Tag System" qui permet d'utiliser le lecteur NFC pour communiquer avec le server de l'entrepôt
Le "Barcode System" qui permet d'utiliser une scanette pour communiquer avec le server de l'entrepôt
Le "Warehouse Server" qui permet de gérer l'entrepôt

[[Image:Architecture_V2.jpg|Architecture]]

Tag System et Barcode System sont tout deux composés de deux modules :
* Un module « Reader » (TagReader et BarcodeReader) qui permet de scanner les objets et de communiquer avec le serveur grâce à des requêtes REST
* Un module « GUI » (TagGUI et BarcodeGUI) qui offre une interface en Swing pour utiliser le module « Reader »

Warehouse Server :
* Une base de données pour stocker les informations des produits de l'entrepôt
* Un module « WarehouseManager » permettant d'effectuer des opérations sur la base de données
* Deux modules « Solver » (TagSolver et BarcodeSolver) exposant des services REST afin de récuperer les informations envoyées par les « Readers », les analyser et effectuer l'opération requise
* Un module « ManagerNotifier » offrant la possibilité d'envoyer des emails au manager de l'entrepôt (utilisation de l'API JavaMail)
* Un moteur de règles basé sur Drools pour implémenter une logique métier

Les différents modules étant des bundles OSGi, les systèmes devront tourner sur une plateforme OSGi.

==Evolutions envisageables==

L'objectif de ce projet était de réaliser les fonctionnalités suivantes :
* Ajouter un produit grâce à un lecteur NFC
* Ajouter un produit grâce à une scanette
* Retirer des produits du stock grâce à un lecteur NFC
* Retirer des produits du stock grâce à une scanette
* Envoyer un mail au manager en cas de stock faible d'un produit
* Envoyer un mail au manager régulièrement pour l'informer des variations de stock
* Stocker les informations des produits dans une base de données
* Interagir avec la base de données

Toutes les fonctionnalités ont été réalisées excepté l'envoi d'un mail au manager pour l'informer des variations de stock.

==Difficultés rencontrées==

L'architecture a été pensée de manière à pouvoir facilement ajouter des modules supplémentaires pour interagir avec les « Reader », en plus de l'interface graphique déjà présente. Par exemple une console web, une interface en ligne de commmande ou une interface orientée smartphone (ce qui n'est pas le cas de l'interface actuelle).

Notre système permet la gestion de bouteilles de vin. Il aurait cependant été intéressant d'offrir au manager la possibilité de gérer d'autres produits en lui proposant une gestion générique des produits stockés.

Le moteur de règles pourrait être exploité d'une meilleure manière, de nouvelles règles plus élaborées pourraient être créées.

Permettre à l'utilisateur de configurer les éventuelles options d'un modules (Mail du manager, serveur de messagerie, url et port du serveur, …)

==Apports personnels==

Ce projet nous a apporté de nouvelles compétences :
* Utilisation d'une plateforme OSGi
* Création de bundles OSGi (Notamment avec iPOJO)
* Utilisation de Drools
* Utilisation de REST

==Manuel Installation==

Les sources du projet sont disponible sur le svn suivant :
[https://subversion.assembla.com/svn/M2M-warehouse/]

Notre projet est un projet Maven, il est donc nécessaire de le compiler grâce à cet outil. Le projet est découpé en trois modules distincts (TagSystem, BarcodeSystem, WarehouseServer) qu'il est possible de compiler séparément.
Les bundles générés doivent être déployés sur une plateforme OSGi (Par exemple Felix)

==Manuel Utilisateur==

L'utilisation de notre système est assez simple, que ce soit pour une utilisation avec la scanette ou le lecteur NFC elle se fait à travers l'interface. Cette interface permet à l'utilisateur de modifier la quantité d'un produit en ajoutant ou retirant une quantité choisie. Elle permet également d'ajouter un nouveau produit qui n'existerai pas dans la base.

Modification de la quantité d'un vin :
* Sélectionner l'action : Ajouter ou Supprimer
* Saisir la quantité à ajouter ou retirer
* Scanner le produit avec le lecteur NFC ou la scanette
* Valider le scan
* Le produit existe :
** Les informations et la nouvelle quantité pour le produit sont affichées
* Le produit n'existe pas :
** Compléter les informations concernant le produit dans le panel apparu
** Valider les informations entrées
*Possibilité de passer à un nouveau produit en recommençant la procédure

==Conclusion==

ECOM Warehouse Management System

2012-04-05T22:01:45Z

Damontp:

ECOM Warehouse Management System

2012-04-05T21:56:47Z

Damontp: /* Architecture */

Détection de trafic automobile et de d’attente aux feux

2012-04-05T21:56:36Z

Damontp: /* Manuel d'utilisation */

* Enseignant : Didier Donsez, Thomas Calmant
* Etudiants: CEYTE Christophe, DAMONT Pierre-Rémy.

==Description==

Ce projet a pour d'effectuer des décomptes de trafic automobiles à differents feux d'une ou plusieurs villes.
Les resultats seraient rendus à un serveur central sous forme de relevés.
Ces relevés pourraient être ensuite analysés et interprétés afin de modifier l'ordonnancement des feux, ou une modification de l'urbanisme.
Il pourrait aussi servir à reperer une voiture en infraction dans le cas du passage alors que le feu est rouge

==Materiel et configuration Requise==
* Deux ordinateurs dont un ayant une webcam
* OS : Linux ubuntu ou fedora
* Un JRE ou JDK java
* Plateforme OSGI Felix ou Equinox
* Librairie OpenCv
* Compilateur C/C++
* Apache Maven

==Architecture==
*Partie embarquée :
Cette partie est destinée a être embarquée sur les caméras positionnées aux feux à surveiller.
Composée de deux bundles proposant les services suivants : demarrer la Camera et recuperer le relevé de celle-ci.

*Partie fixe :
Cette partie est destinée a être installée sur un ordinateur fixe dont le role sera de récupérer les données des différentes caméras déployées.
Composée de deux bundles proposant les services suivants : demarrer les acquisitions et recuperer les relevés.

==Manuel d'installation==

-Récuperer les sources a l'adresse svn suivante :

http://subversion.assembla.com/svn/m2m_surveillance_flux_autoroutiers

-Le projet se découpe en 4 sous-projets maven et une partie C++:

La partie n°1 nommée Camera_Finale est à compiler obligatoirement sur le pc embarquant la caméra, du fait de la non portabilité du code C++.

Ces 2 parties sont à compiler et à déployer sur le pc embarqué avec la caméra
Partie n°2 nommée CameraServeur
Partie n°3 nommée CameraServlet

Ces 2 parties sont à compiler et à déployer sur le pc jouant le role du serveur
Partie n°3 nommée ServeurServlet
Partie n°3 nommée ServeurCentral

En effet le projet étant encore en développement, les chemins d'accès aux relevés et à l'executable doivent être modifiés.
(Notamment encas de deploiement sous système windows)

==Manuel d'utilisation==

Un fois les parties compilées avec les chemins adéquats, il faut insérer dans le répertoire bundle de felix les paquets générés par maven.
Ces paquets se situent dans le répertoire target du sous-projet maven correspondant à la partie en question.

Ainsi sous la plate-forme OSGI embarqué sur l'ordinateur possédant la caméra nous devons avoir ces bundles de déployés :

camera-broker-bundle-0-SNAPSHOT.jar

==Fonctionnalités envisagées==

Nous souhaitions disposer de n caméras, de pouvoir déclencher leur acquisition à distance sur une période donnée, et d'effectuer une collecte automatisée des relevés générés par ces caméras.
Ces relevés seraient stockés dans une base de données en attendant d'être traitées par un outil d'analyse.
Nous souhaitions aussi pouvoir détecter une inffraction.

D'autre part, bien qu'il ne s'agisse pas d'un projet ayant pour sujet le traitement d'image, l'objectif était d'avoir un système de reconnaissance minimal.

==Fonctionnalités réalisées==

Nous n'avons pu develloper un gestion de n caméras, actuellement le système ne fonctionne qu'avec un serveur central et une partie deportée abritant la caméra (simple webcam dans notre cas).

Nous avons mis en place un service de comptage minimal, le défaut étant qu'il reconnait tout les objets en mouvement, pas seulement les voitures, ce qui fausse le résultat.

L'édition de relevé a partir du comptage effectué est fonctionnel.
Ce relevé est téléchargeable a partir du serveur central, la remontée d'information est donc opérationnellev ia le protocole HTTP.

==Améliorations==

Il resterait à étendre la gestion des caméras à partir du serveur.
Par exemple fournir une api web permmettant d'ajouter ou de retirer des caméras suivants leur adresse.

D'autre part si nous avions la possibilité d'être connecter à l'automate du feu, nous pourrions lancer les aquisitions suivants l'état du feu.
Actuellement nous avons lançons l'acquisition pour une durée pré-determinée.

L'édition de relevés pourrait être ainsi plus conséquente, et s'étaler sur une journée entière et prendre ne compte plus d'informations (infractions par exemple).

La reconnaissance pourrait être affinée afin de reconnaitre des objets plus précis (seulement des voitures).

Un outil d'analyse des données sur le serveur central, permettant d'éditer des courbes par exemple serait utile à l'interprétation des résultats.

==Difficultés rencontrées==

- Découverte d'OSGI, packager les composants en bundle.

- Trouver un système de reconnaissance un minimum efficace et rapide, la solution actuelle étant un code open source "FastMatchTemplate".

- Appeller ce code C/C++ non protable à partir d'un bundle.

ECOM Warehouse Management System

2012-04-05T21:55:53Z

Damontp: /* Architecture */

File:Architecture V2.jpg

2012-04-05T21:55:04Z

Damontp: Architecture projet Warehouse

Architecture projet Warehouse

Détection de trafic automobile et de d’attente aux feux

2012-04-05T21:53:19Z

Damontp: /* Manuel d'utilisation */

* Enseignant : Didier Donsez, Thomas Calmant
* Etudiants: CEYTE Christophe, DAMONT Pierre-Rémy.

==Description==

Ce projet a pour d'effectuer des décomptes de trafic automobiles à differents feux d'une ou plusieurs villes.
Les resultats seraient rendus à un serveur central sous forme de relevés.
Ces relevés pourraient être ensuite analysés et interprétés afin de modifier l'ordonnancement des feux, ou une modification de l'urbanisme.
Il pourrait aussi servir à reperer une voiture en infraction dans le cas du passage alors que le feu est rouge

==Materiel et configuration Requise==
* Deux ordinateurs dont un ayant une webcam
* OS : Linux ubuntu ou fedora
* Un JRE ou JDK java
* Plateforme OSGI Felix ou Equinox
* Librairie OpenCv
* Compilateur C/C++
* Apache Maven

==Architecture==
*Partie embarquée :
Cette partie est destinée a être embarquée sur les caméras positionnées aux feux à surveiller.
Composée de deux bundles proposant les services suivants : demarrer la Camera et recuperer le relevé de celle-ci.

*Partie fixe :
Cette partie est destinée a être installée sur un ordinateur fixe dont le role sera de récupérer les données des différentes caméras déployées.
Composée de deux bundles proposant les services suivants : demarrer les acquisitions et recuperer les relevés.

==Manuel d'installation==

-Récuperer les sources a l'adresse svn suivante :

http://subversion.assembla.com/svn/m2m_surveillance_flux_autoroutiers

-Le projet se découpe en 4 sous-projets maven et une partie C++:

La partie n°1 nommée Camera_Finale est à compiler obligatoirement sur le pc embarquant la caméra, du fait de la non portabilité du code C++.

Ces 2 parties sont à compiler et à déployer sur le pc embarqué avec la caméra
Partie n°2 nommée CameraServeur
Partie n°3 nommée CameraServlet

Ces 2 parties sont à compiler et à déployer sur le pc jouant le role du serveur
Partie n°3 nommée ServeurServlet
Partie n°3 nommée ServeurCentral

En effet le projet étant encore en développement, les chemins d'accès aux relevés et à l'executable doivent être modifiés.
(Notamment encas de deploiement sous système windows)

==Manuel d'utilisation==

Un fois les parties compilées avec les chemins adéquats, il faut insérer dans le répertoire bundle de felix les paquets générés par maven.
Ces paquets se situent dans le répertoire target.

==Fonctionnalités envisagées==

Nous souhaitions disposer de n caméras, de pouvoir déclencher leur acquisition à distance sur une période donnée, et d'effectuer une collecte automatisée des relevés générés par ces caméras.
Ces relevés seraient stockés dans une base de données en attendant d'être traitées par un outil d'analyse.
Nous souhaitions aussi pouvoir détecter une inffraction.

D'autre part, bien qu'il ne s'agisse pas d'un projet ayant pour sujet le traitement d'image, l'objectif était d'avoir un système de reconnaissance minimal.

==Fonctionnalités réalisées==

Nous n'avons pu develloper un gestion de n caméras, actuellement le système ne fonctionne qu'avec un serveur central et une partie deportée abritant la caméra (simple webcam dans notre cas).

Nous avons mis en place un service de comptage minimal, le défaut étant qu'il reconnait tout les objets en mouvement, pas seulement les voitures, ce qui fausse le résultat.

L'édition de relevé a partir du comptage effectué est fonctionnel.
Ce relevé est téléchargeable a partir du serveur central, la remontée d'information est donc opérationnellev ia le protocole HTTP.

==Améliorations==

Il resterait à étendre la gestion des caméras à partir du serveur.
Par exemple fournir une api web permmettant d'ajouter ou de retirer des caméras suivants leur adresse.

D'autre part si nous avions la possibilité d'être connecter à l'automate du feu, nous pourrions lancer les aquisitions suivants l'état du feu.
Actuellement nous avons lançons l'acquisition pour une durée pré-determinée.

L'édition de relevés pourrait être ainsi plus conséquente, et s'étaler sur une journée entière et prendre ne compte plus d'informations (infractions par exemple).

La reconnaissance pourrait être affinée afin de reconnaitre des objets plus précis (seulement des voitures).

Un outil d'analyse des données sur le serveur central, permettant d'éditer des courbes par exemple serait utile à l'interprétation des résultats.

==Difficultés rencontrées==

- Découverte d'OSGI, packager les composants en bundle.

- Trouver un système de reconnaissance un minimum efficace et rapide, la solution actuelle étant un code open source "FastMatchTemplate".

- Appeller ce code C/C++ non protable à partir d'un bundle.

ECOM Warehouse Management System

2012-04-05T21:53:13Z

Damontp: /* Architecture */

Détection de trafic automobile et de d’attente aux feux

2012-04-05T21:50:20Z

Damontp: /* Manuel d'installation */

* Enseignant : Didier Donsez, Thomas Calmant
* Etudiants: CEYTE Christophe, DAMONT Pierre-Rémy.

==Description==

Ce projet a pour d'effectuer des décomptes de trafic automobiles à differents feux d'une ou plusieurs villes.
Les resultats seraient rendus à un serveur central sous forme de relevés.
Ces relevés pourraient être ensuite analysés et interprétés afin de modifier l'ordonnancement des feux, ou une modification de l'urbanisme.
Il pourrait aussi servir à reperer une voiture en infraction dans le cas du passage alors que le feu est rouge

==Materiel et configuration Requise==
* Deux ordinateurs dont un ayant une webcam
* OS : Linux ubuntu ou fedora
* Un JRE ou JDK java
* Plateforme OSGI Felix ou Equinox
* Librairie OpenCv
* Compilateur C/C++
* Apache Maven

==Architecture==
*Partie embarquée :
Cette partie est destinée a être embarquée sur les caméras positionnées aux feux à surveiller.
Composée de deux bundles proposant les services suivants : demarrer la Camera et recuperer le relevé de celle-ci.

*Partie fixe :
Cette partie est destinée a être installée sur un ordinateur fixe dont le role sera de récupérer les données des différentes caméras déployées.
Composée de deux bundles proposant les services suivants : demarrer les acquisitions et recuperer les relevés.

==Manuel d'installation==

-Récuperer les sources a l'adresse svn suivante :

http://subversion.assembla.com/svn/m2m_surveillance_flux_autoroutiers

-Le projet se découpe en 4 sous-projets maven et une partie C++:

La partie n°1 nommée Camera_Finale est à compiler obligatoirement sur le pc embarquant la caméra, du fait de la non portabilité du code C++.

Ces 2 parties sont à compiler et à déployer sur le pc embarqué avec la caméra
Partie n°2 nommée CameraServeur
Partie n°3 nommée CameraServlet

Ces 2 parties sont à compiler et à déployer sur le pc jouant le role du serveur
Partie n°3 nommée ServeurServlet
Partie n°3 nommée ServeurCentral

En effet le projet étant encore en développement, les chemins d'accès aux relevés et à l'executable doivent être modifiés.
(Notamment encas de deploiement sous système windows)

==Manuel d'utilisation==

==Fonctionnalités envisagées==

Nous souhaitions disposer de n caméras, de pouvoir déclencher leur acquisition à distance sur une période donnée, et d'effectuer une collecte automatisée des relevés générés par ces caméras.
Ces relevés seraient stockés dans une base de données en attendant d'être traitées par un outil d'analyse.
Nous souhaitions aussi pouvoir détecter une inffraction.

D'autre part, bien qu'il ne s'agisse pas d'un projet ayant pour sujet le traitement d'image, l'objectif était d'avoir un système de reconnaissance minimal.

==Fonctionnalités réalisées==

Nous n'avons pu develloper un gestion de n caméras, actuellement le système ne fonctionne qu'avec un serveur central et une partie deportée abritant la caméra (simple webcam dans notre cas).

Nous avons mis en place un service de comptage minimal, le défaut étant qu'il reconnait tout les objets en mouvement, pas seulement les voitures, ce qui fausse le résultat.

L'édition de relevé a partir du comptage effectué est fonctionnel.
Ce relevé est téléchargeable a partir du serveur central, la remontée d'information est donc opérationnellev ia le protocole HTTP.

==Améliorations==

Il resterait à étendre la gestion des caméras à partir du serveur.
Par exemple fournir une api web permmettant d'ajouter ou de retirer des caméras suivants leur adresse.

D'autre part si nous avions la possibilité d'être connecter à l'automate du feu, nous pourrions lancer les aquisitions suivants l'état du feu.
Actuellement nous avons lançons l'acquisition pour une durée pré-determinée.

L'édition de relevés pourrait être ainsi plus conséquente, et s'étaler sur une journée entière et prendre ne compte plus d'informations (infractions par exemple).

La reconnaissance pourrait être affinée afin de reconnaitre des objets plus précis (seulement des voitures).

Un outil d'analyse des données sur le serveur central, permettant d'éditer des courbes par exemple serait utile à l'interprétation des résultats.

==Difficultés rencontrées==

- Découverte d'OSGI, packager les composants en bundle.

- Trouver un système de reconnaissance un minimum efficace et rapide, la solution actuelle étant un code open source "FastMatchTemplate".

- Appeller ce code C/C++ non protable à partir d'un bundle.

ECOM Warehouse Management System

2012-04-05T21:49:06Z

Damontp:

Détection de trafic automobile et de d’attente aux feux

2012-04-05T21:49:01Z

Damontp: /* Améliorations */

* Enseignant : Didier Donsez, Thomas Calmant
* Etudiants: CEYTE Christophe, DAMONT Pierre-Rémy.

==Description==

Ce projet a pour d'effectuer des décomptes de trafic automobiles à differents feux d'une ou plusieurs villes.
Les resultats seraient rendus à un serveur central sous forme de relevés.
Ces relevés pourraient être ensuite analysés et interprétés afin de modifier l'ordonnancement des feux, ou une modification de l'urbanisme.
Il pourrait aussi servir à reperer une voiture en infraction dans le cas du passage alors que le feu est rouge

==Materiel et configuration Requise==
* Deux ordinateurs dont un ayant une webcam
* OS : Linux ubuntu ou fedora
* Un JRE ou JDK java
* Plateforme OSGI Felix ou Equinox
* Librairie OpenCv
* Compilateur C/C++
* Apache Maven

==Architecture==
*Partie embarquée :
Cette partie est destinée a être embarquée sur les caméras positionnées aux feux à surveiller.
Composée de deux bundles proposant les services suivants : demarrer la Camera et recuperer le relevé de celle-ci.

*Partie fixe :
Cette partie est destinée a être installée sur un ordinateur fixe dont le role sera de récupérer les données des différentes caméras déployées.
Composée de deux bundles proposant les services suivants : demarrer les acquisitions et recuperer les relevés.

==Manuel d'installation==

-Récuperer les sources a l'adresse svn suivante :

http://subversion.assembla.com/svn/m2m_surveillance_flux_autoroutiers

-Le projet se découpe en 4 sous-projets maven et une partie C++:

La partie n°1 nommée Camera_Finale est à compiler obligatoirement sur le pc embarquant la caméra, du fait de la non portabilité du code C++.

Ces 2 parties sont à compiler et à déployer sur le pc embarqué avec la caméra
Partie n°2 nommée CameraServeur
Partie n°3 nommée CameraServlet

Ces 2 parties sont à compiler et à déployer sur le pc jouant le role du serveur
Partie n°3 nommée ServeurServlet
Partie n°3 nommée ServeurCentral

En effet le projet étant encore en développement, les chemins d'accès aux relevés et à l'executable doivent être modifiés.
(Notamment encas de deploiement sous système windows)

==Fonctionnalités envisagées==

Nous souhaitions disposer de n caméras, de pouvoir déclencher leur acquisition à distance sur une période donnée, et d'effectuer une collecte automatisée des relevés générés par ces caméras.
Ces relevés seraient stockés dans une base de données en attendant d'être traitées par un outil d'analyse.
Nous souhaitions aussi pouvoir détecter une inffraction.

D'autre part, bien qu'il ne s'agisse pas d'un projet ayant pour sujet le traitement d'image, l'objectif était d'avoir un système de reconnaissance minimal.

==Fonctionnalités réalisées==

Nous n'avons pu develloper un gestion de n caméras, actuellement le système ne fonctionne qu'avec un serveur central et une partie deportée abritant la caméra (simple webcam dans notre cas).

Nous avons mis en place un service de comptage minimal, le défaut étant qu'il reconnait tout les objets en mouvement, pas seulement les voitures, ce qui fausse le résultat.

L'édition de relevé a partir du comptage effectué est fonctionnel.
Ce relevé est téléchargeable a partir du serveur central, la remontée d'information est donc opérationnellev ia le protocole HTTP.

==Améliorations==

Il resterait à étendre la gestion des caméras à partir du serveur.
Par exemple fournir une api web permmettant d'ajouter ou de retirer des caméras suivants leur adresse.

D'autre part si nous avions la possibilité d'être connecter à l'automate du feu, nous pourrions lancer les aquisitions suivants l'état du feu.
Actuellement nous avons lançons l'acquisition pour une durée pré-determinée.

L'édition de relevés pourrait être ainsi plus conséquente, et s'étaler sur une journée entière et prendre ne compte plus d'informations (infractions par exemple).

La reconnaissance pourrait être affinée afin de reconnaitre des objets plus précis (seulement des voitures).

Un outil d'analyse des données sur le serveur central, permettant d'éditer des courbes par exemple serait utile à l'interprétation des résultats.

==Difficultés rencontrées==

- Découverte d'OSGI, packager les composants en bundle.

- Trouver un système de reconnaissance un minimum efficace et rapide, la solution actuelle étant un code open source "FastMatchTemplate".

- Appeller ce code C/C++ non protable à partir d'un bundle.

ECOM Warehouse Management System

2012-04-05T21:48:04Z

Damontp:

Détection de trafic automobile et de d’attente aux feux

2012-04-05T21:41:28Z

Damontp: /* Fonctionnalités réalisées */

ECOM Warehouse Management System

2012-04-05T21:39:46Z

Damontp:

* Enseignant : Didier Donsez
* Etudiants M2PGI : CASAGRANDE Thierry, RICHARD David

==Matériel==
* RFID + QRCode + Barcode 1D
* USB Barcode reader
* USB NFC Reader

==Logiciels==
* Apache Felix
* Drools Expert

==Introduction==

==Architecture==

==Evolutions envisageables==

==Difficultés rencontrées==

==Apports personnels==

==Manuel Utilisateur==

==Manuel Installation==

==Conclusion==

Détection de trafic automobile et de d’attente aux feux

2012-04-05T21:35:21Z

Damontp: a

Détection de trafic automobile et de d’attente aux feux

2012-04-05T21:26:26Z

Damontp: /* Fonctionnalités */

Détection de trafic automobile et de d’attente aux feux

2012-04-05T21:22:39Z

Damontp: /* Manuel d'installation */

Détection de trafic automobile et de d’attente aux feux

2012-04-05T21:08:11Z

Damontp: /* Manuel d'installation */

Détection de trafic automobile et de d’attente aux feux

2012-04-05T21:07:18Z

Damontp: /* Materiel et configuration Requise */

Détection de trafic automobile et de d’attente aux feux

2012-04-05T21:06:58Z

Damontp: /* Manuel d'installation */

Détection de trafic automobile et de d’attente aux feux

2012-04-05T20:57:18Z

Damontp: /* Materiel et configuration Requise */