Conservatoire National des Arts et Métiersfredg78.free.fr/cnam/memoires_ingenieur/Memoire_CNAM_F... · Web viewCes requêtes servent à initialiser pour la session en cours des éléments

Conservatoire National des Arts et MétiersCentre régional de Montpellier

Mémoire présenté par

Frédéric Gomez

En vue d’obtenirLe diplôme d’ingénieur CNAM

Spécialité : Informatique – Réseaux, Système et Multimédia

Création d’une application serveur pour la publication et l’échange de données qualifiées provenant d’appareils de mesures dédiés via les

protocoles Ethernet et TCP/IP

Soutenu le 18/04/2007

Jury :Président : Monsieur Jean RANCHIN (CNAM Paris)

Membres : Monsieur Michel SALA (CNAM – UM1)Madame Isabelle MOUGENOT (UM2 - LIRMM)Monsieur Eric VERDOIRE (CNAM)Madame Thérèse LIBOUREL (UM2 – LIRMM)

Monsieur Loïc DESVEAUX (AT2E)Remerciements

Je remercie tout d’abord le CNAM qui offre la possibilité de poursuivre des études supérieures.

Je remercie très chaleureusement Isabelle MOUGENOT, docteur au LIRMM et maître de conférences à l’université de Montpellier II pour son encadrement, sa disponibilité et son aide précieuse.

Mes remerciement vont également à toute ma famille qui m’a soutenu et encouragé tout au long de mes études au CNAM.

Frédéric Gomez Création d’une application serveur pour la publication et l’échange de données qualifiées Mémoire Ingénieur CNAM provenant d’appareils de mesures dédiés via les protocoles Ethernet et TCP/IP

2

Introduction 5

1 Analyse préalable 7

1.1 Les partenaires du projet 71.2 Domaine d’étude du couple 81.3 Système de mesures de couple 81.3.1 Appareil pour la mesure de couple : TMV4 81.3.2 Logiciel développé par DALISOFT : Qualitorq 91.3.3 Architecture du système TMV4 – Qualitorq 11

2 Analyse détaillée 13

2.1 Les acteurs industriels impliqués 132.1.1 Concepteurs et fabricants de bouchons – bouteilles 142.1.2 Industries clientes 162.2 Limites et évolutions du système TMV4 – Qualitorq 192.2.1 D’où est venu l’idée de faire évoluer le système actuel ? 192.2.2 Un nouveau couplemètre (TMV5) 202.2.3 Evolution de l’architecture du système (Couplemètre + Logiciel) 212.2.4 Avantages de la nouvelle architecture du système 222.3 Objectifs du projet 232.3.1 Détail des objectifs à atteindre pour la partie logicielle 232.3.2 Détail des objectifs à atteindre pour la partie couplemètre 24

3 Développement de l’application serveur Qualitorq 25

3.1 Procédure de réalisation d’une session de mesures 253.2 Implémentation de l’application serveur 273.2.1 Choix des solutions technologiques 283.2.2 Gestion des connexions entre les couplemètres et l’application serveur 283.2.3 Gestion des threads et des accès aux ressources 323.2.4 Traitement des mesures 373.3 Protocole de communication 383.3.1 Objectifs d’un protocole dédié 393.3.2 Positionnement par rapport au modèle OSI 393.3.3 Détails sur le protocole « Application » 423.3.4 Détails des différentes demandes, commandes et réponses 433.4 Organisation de la communication entre les couplemètres 48 et l’application serveur3.4.1 Organisation des échanges de données entre les couplemètres 48 et l’application serveur3.4.2 Représentation des échanges par des diagrammes de séquences 493.5 Détails sur la base de données de l’application serveur 523.5.1 Détails sur les données composant la base de données 523.5.2 Représentation du modèle de données avec UML 543.6 Gestion des utilisateurs 553.6.1 Pourquoi mettre en place une gestion des utilisateurs 55


3

3.6.2 Gestion des droits utilisateurs 55

4 Fonctionnalité de l’application serveur Qualitorq 57

4.1 Interfaces graphiques de l’application serveur 584.1.1 Fenêtre principale 584.1.2 Fenêtre de configuration 594.2 Interfaces graphiques de l’application de gestion des données 604.2.1 Gestion des données relatives à la mesure de couple 604.2.2 Préparation d’une session de mesures avec une « Fiche mesures » 614.2.3 Visualisation des sessions de mesures clôturées 624.2.4 Recherche de sessions sur critères et calculs statistiques 624.2.5 Visualisation des évènements 644.2.6 Visualisation des sessions en cours 65

5 Test de l’application serveur Qualitorq 70

5.1 Comment et avec quoi tester 705.2 Détails sur les deux applications de test 705.2.1 Couplemètre TMV5 virtuel 715.2.2 Application pour simuler des montées en charge 74

Conclusion 76

Table des illustrations 78

Bibliographie 79

Glossaire 80

Annexes 82


4

Introduction

Tous les jours des millions de gens, de par le monde, achètent des boissons, des produits d’entretien, pharmaceutique ou de beauté sans se douter de l’attention que portent les industriels sur la qualité de finition et la sécurité des contenants : couple bouchon bouteille, capsule flacon ou packaging.

Imaginez que le bouchon de votre bouteille de soda soit si dur à ouvrir, qu’il faille utiliser une pince, que votre boisson gazeuse ne le soit presque plus car ce bouchon n’aurait pas été assez serré à l’embouteillage, que votre enfant arrive aisément avec ses petites mains à ouvrir les flacons de produits d’entretiens toxiques ou les boites de médicaments, ou encore que le bouchon d’une boisson gazeuse soit propulsé dans l’œil de quelqu’un suite à la montée en pression interne due à la chute de cette bouteille et d’une mauvaise fixation entre le bouchon et la bouteille.

Toutes ces choses qui n’arrivent heureusement que, dans de très rare cas, sont évitées par un travail continu des ingénieurs et techniciens qualité qui traquent sans cesse les erreurs de conception pendant la phase de développement et les problèmes en production : machine de serrage défaillante ou déréglée, mécanique des bouchons et bouteilles mal conçue, …

Pour contrôler cette qualité et y remédier en cas de problème, les ingénieurs et techniciens utilisent différents outils de contrôle et de test pour mettre à rude épreuve le contenant durant plusieurs étapes : dans les laboratoires de R&D quand il est en cours ou en fin de conception, durant sa fabrication, quand il arrive chez l’embouteilleur et enfin quand il est sur les lignes de remplissage et de mise en place du bouchon. Durant toutes ces étapes de tests, ces contrôles sont effectués avec différents appareils de mesure.

Parmi ces appareils de mesures, le couplemètre mesure la force de serrage d’un bouchon vissé sur une bouteille. Le couplemètre va du simple petit appareil servant à faire des mesures manuelles jusqu’aux appareils beaucoup plus imposants et sophistiqués qui font des mesures en automatique en conjuguant différents paramètres (vitesse de vissage ou de dévissage, angle parcouru, consigne de couple, …). Les couplemètres peuvent être exploités de manière indépendante mais sont généralement associés à des ordinateurs et des briques logicielles sous-jacentes qui gèrent l’acquisition, le stockage et l’exploitation des données mesurées et qui peuvent même aller jusqu’à assurer l’intégralité du pilotage du couplemètre.

Dans ce mémoire nous allons tout particulièrement nous intéresser à la partie logicielle. L’étude s’appuie de manière concrète sur un couplemètre spécifique commercialisé par la société AT2E qui, dans sa configuration originale, souffre d’un mode de communication limité avec l’ordinateur. L’objectif du mémoire est donc de proposer des solutions conceptuelles et techniques relevant de l’informatique pour s’affranchir de ces limites. Le projet dans sa globalité, porte également sur la réalisation d’un nouveau couplemètre, doté d’une connectivité, plus à même de satisfaire les exigences des besoins actuels qui s’orientent vers des architectures décentralisées s’appuyant sur des couches logiques traitant de la présentation, de la spécificité métier ou encore des données. L’idée, ici, est de privilégier l’évolutivité et la modularité du système mis en place et d’autoriser différentes configurations


5

d’utilisation possibles. L’accent est mis sur l’analyse, la conception et le développement d’une application serveur qui va être capable de gérer, en simultané, un ensemble de couplemètres connectés. L’application serveur s’appuie par ailleurs sur une base de données pour tout ce qui relève de la gestion des données.

Le défi est double :

- d’un point de vue technique, une nouvelle génération de couplemètres, gommant les limites des appareils actuels notamment en matière d’interfaces de communication, est en cours de développement

- d’un point de vue informatique, l’architecture des composants applicatifs associés, est repensée de manière à les rendre flexibles, modulaires et donc évolutifs. L’objectif est de pouvoir couvrir les besoins des partenaires industriels en fonction des nouveaux types de couplemètres mais aussi de se projeter dans l’avenir et d’anticiper les besoins d’éventuelles nouvelles innovations techniques.

Le projet s’ancre résolument dans une démarche d’informatique industrielle et se consacre à une problématique de contrôle qualité. Dans ce sens, notre démarche se veut précise, rigoureuse et méthodique. Les différents aspects (fonctionnels, statiques et dynamiques) du système informatique à mettre en place sont modélisés au travers de la notation UML (ref).

Le mémoire s’articule comme suit. Dans la section 1, le contexte du projet ainsi que l’existant en matière de systèmes de mesures de couple sont décrits. La section 2 est une étude détaillée des différents acteurs du système. Une hiérarchie d’acteurs ainsi que des cas d’utilisation donnant une vision fonctionnelle du système sont présentés. Les limites de l’existant et leur évolution en matière de systèmes de mesures de couple sont décrites.La section 3 est consacrée à la conception et à l’implémentation de l’application serveur. L’importance est notamment donnée à l’accès et à la gestion des données. Un protocole, adapté à la communication entre les couplemètres et la machine serveur, a ainsi été défini. Une base de données a également été conçue et implémentée pour le stockage et la restitution des données. Nous nous positionnons dans une optique de contrôle qualité et dans ce sens, les aspects gestion des utilisateurs, traçabilité, qualité et intégrité des données ont été tout particulièrement considérés. La section 4 aborde les couches présentation et traitement de l’application. Enfin la section 5 offre un juste retour des choses en terme de tests et de validations de l’application serveur.


6

1 Analyse préalable

Il s’agit dans cette première partie de donner un aperçu de la problématique et des enjeux du projet au travers notamment des sociétés concernées ainsi que de l’existant en matière de logiciels et d’appareils de mesures de couple.

D’un point de vue industriel, le projet relève d’une approche contrôle qualité. L’application serveur va servir à traiter des mesures de couple mettant en jeu un contenant et son système de fermeture et de toutes les données qui s’y rapportent.

Une première section sera consacrée à la présentation de l’ensemble des partenaires impliqués, une seconde section portera ensuite sur le domaine d’étude et une troisième section concernera enfin la version initiale du système de mesures de couple composée du couplemètre TMV4 et du logiciel Qualitorq.

L’analyse s’appuie sur différents cas d’utilisation et diagrammes de contexte issus de la notation UML et prenant en charge les aspects fonctionnels du système.

1.1 Les partenaires du projet

AT2E

La société AT2E, située en Île-de-France, étudie et réalise des appareils de contrôle qualité répondant aux besoins des entreprises, qu’il s’agisse d’industries agroalimentaires, cosmétiques, pharmaceutiques ou encore chimiques.

Ces appareils de contrôle vont répondre à diverses fonctions :

- Mesurer le couple de vissage entre un bouchon et une bouteille- Mesurer la pression à laquelle la première fuite apparaît après compression de l’air

dans une bouteille- Analyser l’état du packaging après l’avoir placé dans un caisson et avoir fait le vide.

Ces appareils se déclinent en outre en version manuelle et automatisée.

DALISOFT

La société DALISOFT, située à Montpellier, dont je suis le fondateur et le gérant, analyse, conçoit et réalise des logiciels sur cahier des charges et a pour dominante, une spécialité forte en informatique industrielle.DALISOFT compte, parmi ses activités, un partenariat avec la société AT2E, et développe tous les logiciels venant s’interfacer avec les appareils de contrôle qualité présentés au dessus.


7

1.2 Domaine d’étude du couple

Un couple, en mécanique, désigne l’effort en rotation appliqué à un axe. Il est ainsi nommé en raison de la façon caractéristique nécessaire à ce type d’action : un bras qui tire, un bras qui pousse, les deux forces étant égales et opposées. Il existe plusieurs unités pour quantifier la valeur de mesure de couple : N.cm (Newton par centimètre), N.m (Newton par mètre), Kgf.cm (Kilogramme force par centimètre), DaN.cm (Déca Newton par centimètre), Inch.lbs ; démontrant l’importance de la notion de couple mécanique.

On trouve de la mesure de couple, à l’instar de la mesure de poids, dans une pléthore d’applications.La mesure de couple, abordé ici, touche au packaging que l’on trouve dans différentes industries (pharmaceutiques, cosmétiques, agroalimentaires, …). Le packaging de type boîte en carton d’emballage n’est pas concerné ici. Il s’agit de contrôler la qualité du système de fermeture des contenants. Ces contenants peuvent posséder un bouchon qui se visse et se dévisse au travers d’une rotation (flacon, bouteille, pot de crème) ou encore comprendre une mécanique pour laquelle deux rotations s’exercent, de manière inversée, et actionne un pas de vis qui permet de faire sortir/entrer le cylindre qui supporte le produit (rouge à lèvres).Il est cependant à noter que la mesure de couple est parfois réalisée dans d’autres domaines avec d’autres objectifs. Ainsi dans l’industrie automobile, il s’agit bien souvent d’améliorer les performances du couple moteur d’une voiture.

Le but est ici de privilégier la sécurité plutôt que la performance. Le contrôle porte sur la qualité du vissage et donc sur la qualité du maintien du bouchon sur la bouteille.

1.3 Système de mesures de couple

Un premier système de mesures de couple, développé par AT2E, préexistait par rapport au projet. Les composantes couplemètre et logicielle de ce premier système sont décrites dans cette section.

1.3.1 Appareil pour la mesure de couple : TMV4

AT2E développe et commercialise un couplemètre nommé TMV4 pour Torque-Mètre version 4 (figure 1).


8

Fig. 1 Couplemètre TMV4

Cet appareil trouve ses applications en laboratoire et en production dans de nombreuses industries.Il est muni d’un écran LCD sur lequel vient s’afficher la valeur de couple. Quatre boutons de commande permettent les réglages (étalonnage, changement d’unité, mesure continue ou crête, mode haute précision, réglage heure et date, re-calibration du zéro, choix de la langue) et la validation des mesures.Cet appareil est muni d’une liaison série RS232 autorisant les communications avec soit une imprimante adapté soit un ordinateur (PC).Le principe de fonctionnement est le suivant : l’opérateur va positionner une bouteille ou un flacon, le bouchon vers le haut, sur le socle prévu à cet effet (étau), il va ensuite bloquer la bouteille sur ce socle grâce à une molette qui vient refermer l’étau adapté au culot de la bouteille. Il va alors dévisser de quelques degrés le bouchon de la bouteille, c'est-à-dire jusqu’à ce qu’il n’ait plus besoin de forcer pour dévisser (désigné par contrôle destructif). Une fois la manipulation terminée et la valeur maximum du couple affichée, l’utilisateur va appuyer sur le bouton « Valider ».

Deux possibilités se présentent selon la configuration choisie :

- Une imprimante est connectée au TMV4 et imprime la mesure.

- Un PC est connecté au TMV4 et une trame lui est envoyée. La trame sera alors traitée par le logiciel adapté Qualitorq (voir ci-dessous).

A chaque validation, la mesure est donc transmise, l’afficheur se réinitialise et le TMV4 se met en attente d’une nouvelle mesure.

Il existe aussi un TMV4 en version automatique, avec lequel on peut réaliser des mesures non destructrices. Ce n’est plus la main humaine qui actionne la bouteille mais une tête de vissage motorisée. Cette version automatisée offre des possibilités de mesure avancées comme le fait de pouvoir renseigner un angle de vissage ou de dévissage, ou encore une consigne de couple pour le vissage.

Le TMV4 manuel est très utilisé sur ligne de production, et nous intéresse au premier chef, alors que le TMV4 automatique est plutôt utilisé en laboratoire et, de ce fait, ne concerne pas le projet présenté ici.


9

1.3.2 Logiciel développé par DALISOFT : Qualitorq

DALISOFT développe donc un logiciel qui traite les mesures de couple faite avec le couplemètre TMV4, ce logiciel est nommé « Qualitorq ».

Spécificités de Qualitorq :

Qualitorq utilise la liaison série RS232 du PC pour communiquer avec le TMV4. Cette liaison va notamment lui permettre de recevoir les valeurs des mesures de couple après validation par l’opérateur, sous la forme d’une trame qu’il va rester ensuite à traiter.Le premier traitement porte sur la construction d’un tableau dans lequel vont venir s’afficher les mesures à leur arrivée et qui seront visibles sur l’écran du PC pour l’opérateur. Au fur et à mesure de l’arrivée des mesures, et donc de leur affichage dans le tableau, des statistiques sont automatiquement calculées (moyenne, écart-type, mesure minimum et maximum) et les courbes correspondantes à ces résultats sont tracées (courbe des mesures et courbe de gauss). Il est possible d’indiquer des seuils (ou bornes) qui serviront à apprécier les mesures de couple. Pour cela un responsable qualité va définir une valeur de couple (valeur définie en fonction des contraintes de production et des spécifications du couple bouchon - bouteille), celle-ci servira donc de seuil ou de référence, et chaque mesure réalisée par l’opérateur sera comparée à ce seuil et ainsi être qualifiée de faible ou de forte. L’on peut définir 1,2 ou 4 seuils, par exemple avec 2 seuils l’on peut avoir trois appréciations : « Faible, Bon et Fort », avec 4 seuils : « Très Faible, Faible, Bon, Fort et Très Fort », tout dépend des besoins. A savoir que chaque appréciation est matérialisée dans le logiciel , en plus de la mention, par des couleurs, comme par exemple la couleur verte pour « Bon », le rouge pour « Fort » et le bleu pour « Faible ». Cela offre une visualisation directe et rapide pour l’opérateur. Le logiciel établit aussi, parmi les statistiques, un pourcentage qualité qui correspond au nombre de valeurs jugées « Bonne » par rapport à l’ensemble des mesures.

Une fois que toutes les mesures ont été effectuées, l’opérateur peut enregistrer les résultats afin de les stocker dans la base de données de Qualitorq. Il peut aussi associer, à ces mesures, des informations additionnelles dont certaines relèvent de la méta-donnée comme son nom (pour savoir ensuite qui a fait quelles mesures), le nom du produit (référence bouchon, …) et le numéro de lot sur lequel les mesures ont été effectuées, le nom de la ligne de production sur laquelle les échantillons du produit ont été prélevés et des commentaires, à savoir que toutes ces données peuvent avoir été au préalablement saisie dans la base (sous la forme de « fiche mesures ») permettant ainsi à l’opérateur de n’avoir plus qu’à choisir dans des listes, lui évitant alors de devoir à chaque fois tout saisir, ce qui limite fortement les erreurs de saisie. Quand l’opérateur clique sur le bouton « Enregistrer » les mesures sont rattachées à un numéro de session unique généré par le logiciel ainsi que l’heure et la date.La notion de session de mesures est importante et va être reprise dans la suite du projet. Elle est composée d’un numéro de session unique qui l’identifie, d’informations concernant la session (nom et numéro de lot du produit mesuré, ligne de production sur laquelle ont été prélevé les échantillons, nom de l’opérateur, commentaires, date et heure de la session) et surtout des valeurs de couple mesurées pendant la session.

Une fois les mesures enregistrées dans la base de données, les opérateurs ont la possibilité, immédiatement ou ultérieurement, d’imprimer des rapports de session de mesures avec statistiques et courbes incluses.


10

Qualitorq offre aussi la possibilité de lancer des recherches de session en fonction de différents critères. Par exemple, le responsable qualité pourra faire une recherche de toutes les mesures qui ont été effectuées sur une référence bouchon et une période définie. Ensuite les résultats obtenus seront affichés dans un tableau, les courbes seront tracées et les statistiques seront calculées sur l’ensemble des mesures trouvées (min, max, moyenne, …). Il pourra s’il le désire imprimer les résultats.Les recherches peuvent être effectuées en fonction des critères suivant : Nom du produit, numéro de lot, ligne de production et dates.Il est très intéressant pour un responsable qualité de pouvoir faire ce type de recherche dans le temps, car il peut identifier des variations dans les mesures, variation qui peuvent être imputées à diverses raisons : déréglage des visseuses automatique, mauvais lot de bouchons – bouteilles, ...

Le logiciel Qualitorq est développé avec l’Atelier de Génie Logiciel (AGL) Windev de la société Montpelliéraine PCSoft. Le système de gestion de base de données proposé avec Windev se nomme Hyper File.

Je vais maintenant donner quelques explications sur la façon dont on installe le TMV4 avec Qualitorq, puisque Qualitorq peut fonctionner en monoposte ou en multiposte.

1.3.3 Architecture du système TMV4 - Qualitorq

La configuration du TMV4 et du logiciel Qualitorq peut s’envisager au travers d’une architecture monoposte ou multipostes selon les besoins des industriels.

1 er cas, configuration monoposte :

Le logiciel Qualitorq et la base de données associée sont installés sur un seul PC. Il s’agit de la configuration la plus courante, dans le cas, où le client possède un seul couplemètre TMV4.

Fig. 2 Couplemètre TMV4 et logiciel Qualitorq : installation monoposte


11

Il peut arriver que pour des raisons d’archivage et d’automatisation de la sauvegarde des données, la base de données soit plutôt implantée sur une autre machine qui disposera de fonctionnalités de serveur de fichiers plus à même de garantir la sécurité de ces données.

2 nd cas, configuration multipostes :

Le client possède plusieurs couplemètres TMV4, et veut centraliser les données au sein d’une seule base de données.Chaque couplemètre TMV4 est relié, via la liaison série, à un PC sur lequel est installé le logiciel Qualitorq (on a donc autant de PC que de couplemètres). Chacun de ses PC est relié en réseau avec la machine (serveur de données) abritant la base de données de Qualitorq et peut donc accéder à la base de données en lecture comme en écriture.

Fig. 3 Couplemètre TMV4 et logiciel Qualitorq : installation multipostes


12

Ce type de configuration est très utilisé en usine, étant donné le nombre important de lignes de productions et de contrôles de couple à effectuer par les opérateurs.

Après la description du système TMV4 et de ses applicatifs logiciels, il est maintenant nécessaire d’en expliquer les limites et d’entrevoir les attentes des partenaires face à un nouveau système.

2 Analyse détaillée

Il s’agit dans cette deuxième partie de décrire les besoins des différents acteurs industriels. L’objectif in fine est de répondre à ces besoins et de faire évoluer le système actuel vers un système flexible et ouvert et donc plus adapté aux besoins spécifiques de l’ensemble des industriels.

Une première section portera sur la présentation et la modélisation des acteurs industriels, utilisant déjà le système existant de mesures de couple, et qui seront susceptibles d’utiliser le nouveau système. Une seconde section détaillera les limites du système actuel à base de couplemètre TMV4 et montrera les apports du nouveau couplemètre TMV5. Enfin une troisième section détaillera tous les objectifs à atteindre pour mettre en place le nouveau système de mesures composé de l’application serveur et des couplemètre TMV5.

2.1 Les acteurs industriels impliqués

Les industries concernées sont de manière générale les industries répondant à des besoins directs des consommateurs dans leurs vies de tous les jours et leur assurant un confort de vie.Ces industries sont nombreuses puisqu’elles recouvrent en particulier tout ce qui va relever de l’alimentation, de la santé et/ou de l’hygiène.Une hiérarchie partielle d’acteurs qui ne modélise que les clients du système, propose une classification de ces acteurs industriels. Un acteur industriel se spécialise en industriel client et en industriel fabriquant. Le fabriquant est l’industriel qui a la charge de la conception et de la fabrication du contenant et de son système de fermeture et qui va en vérifier la qualité avant la mise en production. L’industriel client va tester la qualité des contenants et de leur fermeture avant de les exploiter comme contenants de leurs propres produits. Les industriels clients vont se spécialiser en industriel client agroalimentaire, industriel client cosmétique, … Les personnes chargées des contrôles qualité, dans ces industries, peuvent être chercheurs, ingénieurs, techniciens ou opérateurs de production mais ne sont pas représentés dans la hiérarchie d’acteurs.


13

Fig. 4 Hiérarchie partielle des acteurs

De manière plus approfondie, les bouchons et bouteilles fabriqués, subissent des tests tout au long de la chaîne de production et d’utilisation jusqu’à ce qu’on y mettre un produit à l’intérieur (boissons, produits chimiques, produits de cosmétique, …).Deux raisons expliquent les tests réalisés : l’une porte sur la sécurité du système de fermeture et l’autre porte sur l’adéquation du contenu face à son contenant en terme par exemple de conservation du contenu.

Un fabricant A vend ses bouchons avec, par exemple, la spécificité suivante : pour un vissage à X1 N.cm le bouchon doit se dévisser à X2 N.cm.L’embouteilleur vérifiera que les bouchons acquis auprès du fabricant A, respectent bien ces spécifications du cahier des charges constructeur et qu’en les vissant à X1 N.cm il obtient bien X2 N.cm au dévissage (avec + ou - de tolérances). L’embouteilleur vérifiera aussi chez lui que les têtes de vissage/serrage vissent toujours à la même consigne de couple et qu’il n’y a pas de dérive, et le cas échéant, il y remédiera en réglant les têtes.

Fig. 5 Diagramme de contexte statique


Acteur Industriel

Fabricant de bouchons et de

bouteilles

Industriel client

Industriel Cosmétique

Industriel Pharmaceutique

Industriel Agroalimentaire

Système(de mesures de couple)

Responsable / ingénieur Qualité

Opérateur de mesures

1..*

1..* Responsable / Administrateur du système

1..*

14

2.1.1 Concepteurs et fabricants de bouchons - bouteilles

Ils commercialisent après fabrication toutes sortes de bouchons/capsules, bouteilles/flacons (bouteilles d’eau, canettes de bière, bouteilles d’eau gazeuse, flacons de pilules, bouteilles et flacons avec sécurités enfant, …) et autres mécanismes (tubes de rouge à lèvre ou hydratant, pompes et pulvérisateurs de bouteille de parfums, …).Les tests commencent dans les laboratoires de R & D sur les premiers prototypes de bouchons et de bouteilles, et par la suite quand ils en sont au stade de fabrication. Un diagramme de cas d’utilisation donne une vision fonctionnelle des activités du concepteur/fabricant. Les acteurs humains vont être les ingénieurs ou les techniciens impliqués dans l’élaboration du prototype. Le couplemètre sera vu comme un acteur électronique externe au système de conception/fabrication qui viendra en mesurer la qualité.

Fig. 6 Cas d’utilisation : Conception - Fabrication

Quand un fabricant vend un lot de bouchons à un client, il doit lui préciser, par exemple, que pour avoir tel couple de dévissage, il doit appliquer tel couple de vissage. Il arrive que ce soit le client qui demande aux fabricants de bouchons - bouteilles des contraintes spécifiques.En effet, ce n’est pas parce que l’on visse un bouchon sur une bouteille à 10 N.cm qu’il faudra appliquer 10 N.cm pour le dévisser.


Conçoit : contenant + fermeture

Ingénieur mécanique

Technicien

Ingénieur matériaux

Concepteur/ Fabricant

Fabrique prototype

Teste la biocompatibilit

é

Comparaison avec les produits

de la concurrence

Mesure

<>

<>

<> <>

<>

Tester la rupture des ponts de la

bague d’inviolabilité Tester les pics de

duretés au dévissage

Fabrique en production

Couplemètre

<< Extend >> validation si test OK

15

Si un fabricant vend des bouchons avec sécurités enfant, c’est à dire ceux, par exemple, avec lesquels il faut pincer de chaque coté du bouchon ou appuyer sur le dessus pour les dévisser, celui-ci doit certifier que ses bouchons ne s’ouvriront que si une force suffisante est appliquée aussi bien à l’appui (ou au pincement) qu’au dévissage, ces contraintes rendant l’impossibilité à un enfant de dévisser le bouchon et d’avoir accès au contenu.

Afin de pouvoir définir tout cela, pendant les phases de développement, de longues séries de mesures sont effectuées afin de certifier toutes les valeurs spécifiques définies dans le cahier des charges.

Il faut savoir aussi qu’une fois dans les mains du consommateur et dès la première ouverture, on peut distinguer deux couples : le premier s’appelle « déblocage » (c’est en général le couple maximum) et le second « rupture » qui correspond comme son nom l’indique à la rupture des ponts de la bague d’inviolabilité.On peut aussi distinguer, par exemple, pour certaines briques de jus de fruit, un troisième couple qui correspond au perçage réalisé dans la brique par une sorte d’ergot en plastique qui s’actionne pendant le dévissage du bouchon après le déblocage et la rupture.

Fig. 7 Exemples de bouchons

2.1.2 Industries Clientes

Les industries clientes, vont utiliser les contenants produits par les fabricants comme supports de contention pour leurs propres produits (alimentaire, chimique, pharmaceutique, …).Les acteurs clients sont nombreux et appartiennent à divers secteurs d’activité. Leurs besoins face aux tests de qualité portant sur les contenants sont cependant communs. Dans ce sens, nous proposons un seul diagramme de cas d’utilisation qui synthétise ces besoins.Les acteurs spécialisant l’acteur industriel client sont le responsable qualité qui va prendre les décisions de rejet ou de mise en production selon les résultats des tests, ainsi que le technicien opérateur qui va réaliser les sessions de mesure. Le couplemètre est vu, là aussi comme un acteur électronique externe qui va permettre d’opérer les mesures ainsi que d’en assurer par le biais de la base de données la sauvegarde et l’exploitation ultérieure.


16

Fig. 8 Cas d’utilisation : Vérification et mise en production chez l’acteur industriel

Industrie Agro-alimentaire

Prenons le cas d’une entreprise qui fait des boissons. Il est très important de fournir aux consommateurs des jus, des produits laitiers ou des sodas qui gardent toute leur saveur. Cela signifie qu’il faut, en plus de fabriquer une boisson de bonne qualité, un emballage qui contribue aussi à garantir cette qualité. Cet emballage contenant la boisson, peut être de différentes formes et de différentes matières (en verre, en carton, en aluminium ou en plastique).

Pour ce qui concerne les emballages qui ne se ferment pas avec un bouchon, comme la brique de lait par exemple, les industriels pratiquent sur eux aussi des tests de qualité, comme par exemple le mise en pression pour tester l’étanchéité.

Prenons, comme autre exemple, la bouteille de soda, qui contient un jus gazeux, il faut que le bouchon ne soit pas trop serré afin d’éviter l’emploi d’un outil autre que la main humaine pour l’ouvrir et inversement un bouchon trop lâche créera une perte de saveur de la boisson et un risque de coulure selon la position.A l’achat d’une bouteille, le bouchon est serré à un certain couple, et de plus il est fixé à une bague d’inviolabilité par des ponts qui indiqueront par la suite si la bouteille a été ouverte une première fois. Ici aussi des tests sont effectués pour estimer la difficulté de rompre ces ponts reliant le bouchon à cette bague.


Responsable Qualité

Technicien / Opérateur

Acteur industriel client

Contrôle les lots bouchons - bouteilles

Mesure

<>

Teste les spécifications du

cahier des charges

Valide la mise en production

Retourne le lot au fabricant

Couplemètre

<< Extend >> Si tests conformes

<>

<< Extend >> Si tests non conformes

Teste régulièrement en production

<>

17

Fig. 9 Bouchon et bague d’inviolabilité

Concernant les boissons gazeuses on trouve aussi des contraintes de sécurité importantes. Il faut savoir qu’une bouteille contenant une boisson gazeuse qui fait une chute de 50 cm ou plus, monte en pression ; Cette pression pouvant atteindre environ 6 Bar (selon les boissons), il est important que le bouchon ne soit pas propulsé dans l’œil d’une personne. Cela peut arriver en cas de sur-vissage du bouchon. Pour donner un exemple, une personne fait tomber au sol, parce qu’elle lui échappe des mains, une bouteille contenant une boisson gazeuse, il l’a reprend dans ses mains et au moment de l’ouvrir, au lieu de dévisser, au contraire visse (ou « sur-visse ») le bouchon, à ce moment là s’il est mal conçu et donc « sur-visse », celui si va s’élargir en passant le bas du goulot de la bouteille, et donc le filet du bouchon n’étant plus en prise sur le goulot, le bouchon ne sera donc plus tenu correctement et sera propulsé loin de la bouteille par la pression intérieure.

Fig. 10 « Sur-vissage »

Industrie Pharmaceutique

Ce type d’industrie fabrique toutes sorte de médicaments qui doivent être pris selon un protocole bien défini par le médecin et le pharmacien, car certains peuvent être mortel dans le cas d’une prise trop importante ou selon l’âge de la personne. Il est donc évident que ces médicaments doivent être contenu dans un contenant qu’un enfant d’un certain age ne serait ouvrir de ses propres moyens. Prenons le cas par exemple du bouchon « Squeeze and Turn » (Presser et Tourner) qui oblige qu’on le pince, avec la force d’un adulte, de chaque coté pour pouvoir le dévisser. Il est quand même possible d’ouvrir ce bouchon sans pincer, mais pour cela, il faut appliquer une grande force au dévissage que seul un adulte de bonne constitution est capable de produire. Il faut donc tester ce bouchon en ouverture, sans pincer, et vérifier qu’il ne s’ouvre pas facilement et qu’il faut appliquer un couple minimum important pour arriver à l’ouvrir. En sachant que le bouchon est vendu par son fabricant avec un couple minimum d’ouverture.On trouve aussi des bouchons «Push and Turn » (Pousser et Tourner), c'est-à-dire que pour ouvrir une bouteille ou un flacon avec ce type de bouchon, il faut appuyer sur celui-ci et le dévisser. Si la force d’appui avec la main n’est pas assez importante, le bouchon tournera dans le vide et ne se dévissera pas. On retrouve ce type de bouchon couramment sur les bouteilles d’acide pour la maison, le « White Spirit », l’anti-calcaire, certains médicaments et d’autres produits nocifs pour la santé en cas de mauvaise utilisation.Inversement, le bouchon doit pouvoir être ouvert par un adulte sans qu’il ait besoin d’un outil pour y arriver.

Industrie Cosmétique

Dans ce type d’industrie aussi, on attribut un soin tout particulier au packaging, en sachant que certains produits sont destinés au luxe. Les grandes marques doivent être irréprochable


18

sur la qualité. C’est pourquoi rouge à lèvre, verni à ongle, mascara, fond de teint, entre autres, sont testés régulièrement en production. On peut ici donner l’exemple du mécanisme de pompe accompagné de son pulvérisateur à visser sur la bouteille de parfums une fois remplie. Il faut être très méfiant sur le couple de vissage à appliquer afin de ne pas endommager le système de pulvérisation du parfum par pression sur le dessus du pulvérisateur. Un autre exemple de test consiste à contrôler si un tube de rouge à lèvre fait coulisser correctement de bout en bout le petit plateau circulaire sur lequel repose le produit (rouge à lèvres) et cela avec un couple à peu près constant, sans pic important et sans blocage. A savoir que par rapport à ce dernier test, le couple est très faible et l’appareil se doit d’être très sensible. La mesure en mode haute précision est requise.

Fig. 11 Packaging Cosmétique

2.2 Limites et évolutions du système TMV4 – Qualitorq

Les limites du système de mesures actuel, composé du couplemètre TMV4 et du logiciel Qualitorq sont détaillées. Un nouveau couplemètre nommé TMV5 et différents objectifs à atteindre en terme de couche logicielle sont introduits.

2.2.1 D’où est venu l’idée de faire évoluer le système actuel ?

Des clients communs à Dalisoft et AT2E, ont demandé un système où tous les couplemètres seraient connectés à un seul PC (ou serveur). Sur ce PC, une seule application serveur, résultant d’une évolution de Qualitorq, pourrait gérer l’ensemble de la communication avec les couplemètres TMV4, les différents traitements des mesures et l’exploitation de la base de données.Le problème ne se pose pas au niveau de Qualitorq, mais plutôt du couplemètre TMV4 et de ses performances limitées notamment en matière de communication.

Le premier objectif a donc été d’étudier les différentes solutions possibles en terme de modifications pouvant être apportées au couplemètre.

Le TMV4 n’était pas modifiable sans passer par un coût financier important, ce qui a dans un premier temps largement limité les solutions pouvant être mises en place.Une première approche était de proposer, pour ces couplemètres qui ne sont munis que d’une connexion série, d’utiliser un concentrateur de port série. Malheureusement, le nombre de connecteurs maximum reste limité et ne couvre pas les besoins d’une ligne de production.

Une seconde approche était d’ajouter un convertisseur RS232 à destination des protocoles Ethernet et TCP/IP. Cette solution permettait alors de disposer d’un concentrateur Ethernet


19

entre le serveur et les couplemètres. L’idée ensuite était de définir un protocole spécifique pour l’envoi de mesures de couple et informations associées (session de mesures) depuis un ensemble de couplemètres. Il est nécessaire pour chaque envoi que la mesure soit validée par l’opérateur et que l’application serveur marque la fin d’envoi par un acquittement.

Les deux approches se sont révélées trop risquées à mettre en place, avec un effort de réalisation trop important au niveau de la couche logicielle, visant à pallier les limites trop patentes du couplemètre. La mise en œuvre d’une ou de l’autre de ces solutions a donc été abandonnée.

2.2.2 Un nouveau couplemètre (TMV5)

La conception et la réalisation d’un nouveau couplemètre a rendu à nouveau possible la conception et la réalisation d’une application évolutive destinée à répondre aux besoins de tous les partenaires clients.AT2E a ainsi conçu et fabriqué le successeur du TMV4 sous le nom de TMV5. Les aspects relevant de l’exploitation et de la communication ont été revus en profondeur et réalisés en adéquation avec les besoins en terme d’applicatif logiciel.

Fig. 12 Couplemètre TMV5

Le TMV5, comme le TMV4, fonctionne avec un système d’exploitation propriétaire, il est muni d’un écran tactile de 115x95mm et d’une connexion série (RS232). Il est surtout doté d’une capacité de mémorisation étendue par rapport au TMV4, de 1000 mesures environ et d’informations supplémentaires concernant la session de mesures.


20

L’innovation au niveau du TMV5 porte sur la capacité d’étendre les fonctionnalités de sa carte électronique interne, avec l’ajout d’un « chipset Socket ». Pour des raisons de coût, ce chipset n’est pas présent par défaut sur les couplemètres TMV5. Les utilisations d’un couplemètre hors chaîne de production ne nécessitent pas un tel investissement.

Le chipset peut se comparer à une carte réseau et sert d’ailleurs de carte réseau, avec prise RJ45 (câblé avec le chipset et une norme de connecteur Ethernet très répandu et utilisé avec du câble réseau avec paire torsadé), au TMV5 afin de le connecter sur un réseau Ethernet. En quelques mots, le « chipset socket » gère la partie physique du réseau et les couches Ethernet, IP et TCP/UDP.

Cette possibilité qui est offerte par le TMV5, va nous permettre de réaliser une mise en réseau plus aisé des couplemètres et donc de pouvoir répondre aux demandes, d’exploitation centralisée d’un ensemble de couplemètres, des clients industriels possédant des lignes de production.Le couplemètre TMV5 ayant fortement évolué par rapport à la version précédente (TMV4), il fallait également faire évoluer en profondeur le logiciel existant Qualitorq en privilégiant la modularité et la flexibilité de manière à pouvoir anticiper de nouveaux besoins.

2.2.3 Evolution de l’architecture du système (Couplemètre + Logiciel)

Les configurations vues précédemment lors de la présentation de TMV4-Qualitorq sont toujours d’actualité. En revanche des modifications importantes portent sur la gestion du formatage des trames venant du TMV5, puisque celles-ci comporte beaucoup plus d’informations que celles du TMV4. En effet, sur ce dernier, les trames étaient composées de seulement deux informations : L’unité sur quatre caractères et la valeur mesurée également sur quatre caractères avec deux caractères de fin de trame « CR + LF », donc 10 caractères au total. A savoir que la virgule de la valeur mesurée, se rajoute au moment de traiter la trame. On sait où la placer en fonction de l’unité.Le TMV5 quant à lui, envoie des trames de 105 caractères, comportant les informations suivantes : identifiant unique du couplemètre, numéro de mesure, valeur mesurée, unité de la mesure, nom du produit et numéro de lot sur lequel la mesure est faite, numéro de ligne sur laquelle est prélevé l’échantillon, date, heure et nom de l’opérateur qui effectue la mesure. On a aussi le « CR + LF » de fin de trame. Pour le reste du logiciel, des adaptations ont également portées sur la transmission d’informations vers la mémoire du TMV5, relatives aux sessions de mesure. Une part importante concerne également la révision de la base de données.

Il est à distinguer deux types de modifications. Le premier type de modifications vient d’être détaillé, ci-dessus, et relève surtout de la mise en adéquation de Qualitorq, et du nouveau couplemètre TMV5, sans changer les architectures monoposte et multiposte déjà évoquées.Le deuxième type de modifications est à rapprocher des capacités nouvelles du TMV5, et de la nouvelle architecture à mettre en place. En effet, la possibilité d’ajouter une « carte réseau » au TMV5, va permettre de le connecter à un réseau Ethernet et TCP/IP, qui sera soit déjà existant, ce qui est souvent le cas dans les entreprises, soit à créer en fonction du besoin.


21

Fig. 13 Architecture du système de mesures avec application serveur et couplemètres TMV5L’innovation est illustrée au travers de la figure 13, tous les couplemètres sont reliés, via le réseau Ethernet et TCP/IP, à un seul PC serveur. Le couplemètre TMV5 peut être assimilé à un petit PC dédié à la mesure de couple.

Dans cette solution, le logiciel Qualitorq, installé sur le serveur, devient l’application centrale et gère les communications et la gestion des mesures avec tous les couplemètres connecté sur le réseau et donc au serveur.L’application Qualitorq devient donc une application serveur et les TMV5 des clients.

Les modifications et les nouvelles fonctionnalités transformant Qualitorq en un « Serveur Qualitorq », seront décrites mais avant cela, les avantages de cette solution réseau (client/serveur) sont rappelés.

2.2.4 Avantages de la nouvelle architecture du système

Cette solution apporte des avantages non négligeables aussi bien pour les industries clientes que pour les sociétés DALISOFT et AT2E :

Avantages pour l‘industrie cliente :

Les avantages se mesurent essentiellement en terme d’économie de temps et d’argent.D’un point de vue financier, la nouvelle architecture va permettre une économie d’échelle puisque une seule machine serveur est nécessaire au lieu des n machines associées aux n couplemètres de la ligne de production. En outre, sur une ligne de production, les éclaboussures et les coulures de liquides et/ou produits chimiques peuvent arriver fréquemment. Il faut alors envisager une protection de type boîtier inox pour les PC qui vont


22

être associés aux couplemètres. Les surcoûts engendrés sont non négligeables et vont pouvoir être évités au sein de la nouvelle architecture.

L’économie de temps porte sur la maintenance informatique, il ne sera plus nécessaire de réaliser les n mises à jour sur les applicatifs (système d’exploitation, applications dédiées comme Qualitorq, …) sans compter la gestion corrective des pannes matérielles ou logicielles potentielles, puisque tout sera centralisé au sein d’une et d’une seule machine.

Avantages pour DALISOFT et AT2E :

Les gains portent également sur l’économie de maintenance évolutive comme corrective des machines comme des applications.

En revanche, il n’est pas toujours aisé de modifier le programme embarqué dans les couplemètres, surtout s’il faut démonter la carte électronique pour d’éventuelles mises à jour. L’idée est donc de déporter un maximum de fonctionnalités vers l’application serveur, et d’alléger les fonctionnalités propres du programme embarqué dans les couplemètres. Idéalement, il faudrait que la mise à jour des couplemètres puisse être contrôlée et automatisée à partir de la machine serveur via le réseau. Cette solution n’a pas encore été étudiée de manière concrète mais reste dans les perspectives du projet et sera à élaborer en collaboration, avec l’ingénieur en électronique chargé de la mise en place des cartes électroniques des couplemètres.2.3 Objectifs du projet

Les objectifs généraux sont donc de réviser l’architecture logique de Qualitorq et de l’envisager au travers d’un modèle client/serveur.Les clients sont les couplemètres TMV5, la machine serveur héberge Qualitorq qui doit être vue désormais comme l’application serveur qui va piloter les clients et servir tous les besoins en terme de ressources demandées (gestion et restitution des données) et de traitements associés. Des modifications sont aussi à prévoir au sein du couplemètre TMV5.

2.3.1 Détail des objectifs à atteindre pour la partie logicielle

Mettre en place l’application serveur Qualitorq implique :

- La création d’un protocole de communication pour la couche application, venant au dessus des couches TCP/IP afin de structurer les échanges entre les couplemètres et l’application serveur Qualitorq. Ces échanges vont pouvoir porter sur la gestion de la connexion et de l’identification de l’usager ou encore sur la gestion de A à Z d’une session de mesures. Une modélisation objet des échanges est à réaliser afin de comprendre tous les évènements pouvant survenir sur ces échanges. Un effort tout particulier porte sur la modélisation de la notion de session de mesures qui nous semble essentielle.

- L’implémentation des fonctions de l’application serveur dans une optique multi-utilisateurs : attente de connexion d’un opérateur par l’intermédiaire du TMV5 (gestion des utilisateurs) ; gérer plusieurs connexions en parallèles ; organiser les échanges de données en utilisant le protocole de la couche application ; faire suivre un


23

cheminement à l’opérateur dès le moment qu’il se connecte jusqu’à ce qu’il se déconnecte, avec entre temps la réalisation de toutes les procédures qui lui auront permis de réaliser une session de mesures ; traiter les mesures et les données relatives aux mesures; autoriser ou interdire certaines possibilités en fonction du statut de l’opérateur (administrateur, super utilisateur ou utilisateur) ; lire, écrire et chercher des données dans la base de données et gérer les accès concurrents ; mettre en place une gestion des évènements (visualisation dans une sorte de journal et action à réaliser en fonction de certains évènements) ; mettre en place une interface pour la supervision de l’application serveur.

- La mise en place d’une base de données dans laquelle l’application serveur pourra stocker toutes les mesures de couple et toutes les données relatives à ces mesures ; prévoir une interface pour la saisie de certaines données dans la base ; interface pour la visualisation des sessions de mesures réalisées ; interface pour effectuer des recherches et des statistiques sur les mesures ; gestion d’impression des résultats ; gestion des droits utilisateur sur l’accès aux données.

- La mise en place d’un logiciel simulant un couplemètre TMV5 pour les tests ; il devra aussi simuler des montées en charges pour tester la robustesse du serveur.

2.3.2 Détail des objectifs à atteindre pour la partie couplemètre

Rendre opérationnel un couplemètre TMV5 pour qu’il fonctionne avec l’application serveur Qualitorq comme un client implique :

- L’ajout d’un « chipset socket », plus les câblages nécessaires, sur la carte électronique du TMV5 pour qu’il puisse se connecter sur un réseau Ethernet.

- La possibilité au TMV5 de pouvoir gérer le protocole de communication et donc être en mesure de communiquer avec l’application serveur Qualitorq.

- La Modification de l’interface (IHM) qui s’affiche sur l’écran tactile du TMV5 pour qu’elle prenne en compte les nouvelles spécifications qui vont servir à gérer la communication avec l’application serveur et à ce que l’opérateur puisse effectuer des sessions de mesures.

Les objectifs à atteindre pour le TMV5 relèvent du cahier des charges de l’acteur électronicien d’AT2E et sera réalisé dans un second temps. Dans ce sens, les travaux présentés, ici, s’appuient sur une simulation du couplemètre TMV5 tel qu’il devrait être. Par la suite, l’électronicien devra s’appuyer le travail de spécifications réalisé pour pouvoir connecter et faire communiquer le TMV5 avec l’application serveur Qualitorq.


24

3 Développement de l’application serveur Qualitorq

Chaque objectif relevant de l’application serveur est repris point par point.

La gestion de la communication, la simplicité d’utilisation et d’évolution, la gestion des données relatives à la mesure de couple sont analysées et modélisées avec un maximum d’attention.

Dans un premier temps je montrerai la procédure à suivre pour réaliser une session de mesure, dans un second temps je parlerai des choix technologiques et de l’implémentation de certaines procédures pour la gestion des connexions et le traitement des mesures, dans un troisième temps j’expliquerai la gestion des échanges de données entre l’application serveur et les couplemètres grâce à la mise en place d’un protocole et d’une organisation des échanges, et enfin je parlerai de la base de données contenant toutes les données relatives à la mesure de couple ainsi que de la gestion des utilisateurs du système.

3.1 Procédure de réalisation d’une session de mesures

Pour réaliser une session de mesures l’opérateur doit se placer devant le couplemètre TMV5 (qui est connecté au serveur, via le réseau Ethernet et TCP/IP, sur lequel s’exécute l’application serveur) et utiliser l’écran tactile de celui-ci qui sert d’interface pour dialoguer avec l’application serveur. En effet, en plus de servir à faire des mesures, le couplemètre sert de terminal pour dialoguer avec l’application serveur.Pour commencer, l’opérateur doit se connecter à l’application serveur grâce à un nom d’utilisateur et un mot de passe, il suffit qu’il appuie avec son doigt sur le bouton indiquant


25

« connexion » pour qu’apparaissent deux champs de saisie, un pour le login et l’autre pour le mot de passe. Pour la saisie, et pour toutes les autres d’ailleurs, il utilisera le clavier virtuel, qui apparaît sur demande, à l’écran du TMV5.Une fois l’opérateur connecté, et avant de commencer les mesures, le but est d’indiquer à l’application serveur toutes les informations relatives à la session de mesures.Ces informations sont : le nom ou la référence du produit (bouchon - bouteille) sur lequel l’opérateur va faire les mesures, le numéro de lot de ce produit, la ligne de production sur laquelle il a prélevé les échantillons du produit, le nombre de mesures à effectuer, l’application serveur connaît déjà le nom de l’opérateur depuis la connexion, l’heure, la date et le numéro de session qui sont automatiques. Le choix des seuils (ou bornes) d’appréciation des mesures sont paramétrés en fonction du produit, c'est-à-dire que le responsable qualité aura au préalablement renseigné les seuils qu’il faut utiliser pour chaque produit et de ce fait quand un opérateur sélectionne un produit en particulier, les seuils se paramètrent automatiquement avec.

A titre informatif, les informations peuvent varier en fonction des utilisateurs et des entreprises. Certains utilisent des codes OF (Ordre de Fabrication), code SF ou PF (Semi Fini, Produit Fini), des numéro de lot et de sous lot, … Les informations détaillées sont celles qui sont présentes par défaut avec l’application serveur Qualitorq. Selon les besoins, des adaptations de données seront possibles sur demande des utilisateurs.

Pour paramétrer toutes ces données intrinsèques à la session de mesures, l’opérateur à trois possibilités qui dépendent de son statut et des paramètres qu’aura saisis le responsable qualité en fonction de l’opérateur :

1. L’opérateur va sélectionner toutes les données (nom produit, numéro de lot, …) les unes après les autres en s’y prenant de la façon suivante : il va cliquer (avec son doigt puisque l’écran du couplemètre TMV5 est tactile) sur la case produit (pour commencer), à ce moment là, la liste des produits va être envoyée par l’application serveur, sur demande du TMV5, que ce dernier va afficher, et ainsi l’opérateur n’aura plus qu’à cliquer sur le produit qui l’intéresse. Bien évidemment les produits auront été au préalablement saisie dans la base de données de l’application serveur. L’opérateur va procéder de la même manière pour les autres informations. Le numéro de lot change très souvent et il ne sera pas forcément déjà présent au sein de la base de données, l’opérateur pourra le paramétrer directement en utilisant le clavier virtuel. Ce nouveau numéro de lot sera alors enregistré dans la base de données dans la suite des opérations. Les données relatives à la session de mesures sont affichées à l’écran du TMV5 au fur et à mesure de leur sélection par l’opérateur. Cette sélection a de l’importance au niveau des opérations réalisées par l’application serveur.

2. L’opérateur va demander, en cliquant sur le bouton prévu à cet effet, que s’affiche la liste des « fiches mesures ». Une fiche mesures est au préalable créée par un responsable qualité et regroupe toutes les informations relatives à une session de mesures (nom produit, numéro de lot, …). Cette façon de procéder fait gagner beaucoup de temps à l’opérateur, qui n’a plus besoin de savoir quelles informations choisir et ne perd plus temps à sélectionner les données les unes après les autres.

3. L’opérateur va, ici aussi, demander au TMV5 d’afficher la liste des fiches mesures, sauf qu’ici une seule fiche mesures va apparaître en fonction de l’opérateur, de l’heure et de la date du jour. En effet, le responsable qualité peut paramétrer des fiches


26

mesures qui seront automatiquement attribuées selon l’opérateur connecté et selon la l’heure et la date du jour. Le gain de temps est encore plus important que pour la seconde possibilité.

Une fois toutes les données sélectionnées, une à une ou par le biais d’une fiche de mesures, l’opérateur n’a alors plus qu’à cliquer sur « START » pour que le couplemètre et l’application serveur se mettent en attente des mesures. Quand l’application serveur reçoit une commande « START », elle créée un numéro de session, unique, automatiquement et envoie une trame d’acquittement, comprenant toutes les informations paramétrées par l’opérateur, au couplemètre et enregistre dans la base de données toutes les informations de la session de mesures avec l’indication « Session non clôturée ». Ensuite l’application serveur enregistrera les mesures au fur et à mesure qu’elles arrivent, de cette manière s’il y a un bogue sur le couplemètre ou sur le serveur, il n’y a aucune perte d’information et la session pourra reprendre là où elle s’est arrêtée.

L’opérateur va donc effectuer un certain nombre de mesures, et à chaque mesure il clique sur « Valider » pour que le couplemètre l’envoie à l’application serveur. Quand cette dernière reçoit une mesure, elle envoie une trame d’acquittement dans laquelle elle confirme la bonne réception de la mesure, plus d’autres informations comme le numéro de la mesure reçue ainsi que la mesure minimum et maximum, la moyenne, l’écart type et le pourcentage qualité de bonnes valeurs calculé sur l’ensemble des mesures de la session en cours.Une fois toutes les mesures effectuées et avant qu’il ne clôture la session, l’opérateur pourra s’il le désire ajouter un commentaire à la session. Pour clôturer la session, il suffit à l’opérateur de cliquer sur « STOP », à ce moment là l’application serveur indique dans la base de données que la session est clôturée et effectue les traitements qui auront été configurés, comme par exemple imprimer un rapport de la session qui vient d’être clôturée.

L’opérateur pourra recommencer une session de mesures ou se déconnecter. Il a aussi la possibilité de reprendre une session non clôturée pour compléter avec les mesures manquantes et ensuite clôturer la session. Pour cela, comme il le ferait avec les fiches mesures, il va demander la liste des sessions non clôturées et en choisir une. Il est très rare d’avoir des sessions non clôturées, et si c’est le cas, c’est en général une session de mesures qui n’a pas pu être clôturée pour cause de problèmes avec le couplemètre ou le serveur, ou d’autres raisons exceptionnelles (arrêt de la ligne, perte ou casse d’un échantillon, opérateur inattentif, …).

Pour résumer, une session de mesures est donc un agrégat de mesures ([10 - 20] en moyenne) réalisées par un opérateur sur des échantillons prélevés dans un même lot de produit (bouchon - bouteille) et à laquelle on attache toutes les informations nécessaires : numéro de session unique, date, heure, nom et numéro de lot du produit, ligne sur laquelle l’opérateur a prélevé les échantillons, nom de l’opérateur qui a réalisé la session de mesures, identifiant du couplemètre avec lequel l’opérateur à effectué les mesures, l’unité (Kgf.cm, N.cm, Inch.lbs, …) et un commentaire si nécessaire.

3.2 Implémentation de l’application serveur

L’application serveur, nommé « Serveur Qualitorq », est au centre de l’architecture et gère la communication, et donc les échanges de données, avec les couplemètres TMV5. Tous les


27

couplemètres, sans exception, sont reliés au serveur via un réseau Ethernet et TCP/IP. Dans ces échanges de données, transitent différentes informations : des identifiants de connexion, des mesures de couple, des acquittements, toutes les informations relatives à ces mesures de couples (Nom produit, numéro de lot, …), des commandes de départ et d’arrêt de sessions, des commandes de demande de liste de données (liste des noms ou références des produits, liste des sessions non clôturées, liste des fiches de mesures, liste des noms ou numéro des lignes de production, liste des sessions en cours), une commande pour paramétrer le nombre de mesures à faire pendant la session (ce qui servira, entre autre, à signaler par un message sonore à l’opérateur, que le nombre de mesures à effectuer a été atteint) et des réponses indiquant des erreurs.

Pour arriver à échanger toutes ces données, l’application serveur Qualitorq est décomposée en plusieurs grandes fonctions. Dans la démarche de conception, l’idée est toujours de faire supporter un maximum de fonctions à l’application serveur Qualitorq et d’alléger les tâches déléguées aux couplemètres. Il est en effet toujours plus simple de mettre à jour l’application serveur que les couplemètres, qui nécessitent pour l’instant de reprogrammer l’Eprom et donc autant de manipulations que de couplemètres à disposition. Dans un avenir proche, une solution consistera à mettre à jour tous les couplemètres connectés grâce à l’application serveur en une seule manipulation.

3.2.1 Choix des solutions technologiques

DALISOFT conçoit et développe l’ensemble de ses logiciels clients au travers de l’Atelier de Génie Logiciel (AGL) WINDEV de PCSOFT. Cet AGL regroupe tous les éléments nécessaires aux étapes de conception, de développement et de validation: conception, maquette, dossier, langage L5G (Langage 5ème Génération), RAD (Rapid Application Development), édition, mise au point, test, traduction, diffusion, maintenance et exploitation.Avec WINDEV, la création d’Interfaces Homme-Machine IHM (Fenêtre, bouton, …) est très facile et de qualité. Windev peut en outre s’interfacer avec bon nombre de systèmes de gestion de bases de données (SGBDs) commerciaux ou libres de droit (AS/400, Oracle, SQL Serveur, MySQL, Access, …). Un SGBD nommé « Hyper File » est cependant distribué avec Windev.D’un point de vue financier, seule la licence est à payer au départ et offre une utilisation à durée illimitée.Le langage, nommé L5G, diminue considérablement le temps d’écriture du code, et la maintenance du code se fait alors plus facilement que pour d’autres langages.En revanche, Windev n’est pas un outil conçu, à la base, pour développer spécifiquement des applications serveur. Des environnements tels que Visual C++, J2EE autour de Java sont en effet plus à même de proposer des solutions appropriées pour le développement d’applications serveurs. Windev offre cependant toutes les fonctions nécessaires pour communiquer (Socket) et la possibilité de créer des traitements qui s’exécutent en parallèle (ou temps partagé) les un des autres (Thread).

Après quelques approfondissements, au travers notamment de consultations de forums et d’interviews de développeurs d’applications serveur sous Windev, il s’est avéré que Windev pouvait tout à fait se concevoir comme environnement de développement d’applications serveur. Les retours des interviews étaient en effet très positifs (serveurs disponibles 24/24,


28

pas de pannes ou de problème majeurs, facilité de la maintenance évolutive et corrective, …). L’expertise accumulée lors de développements antérieurs sous Windev a fait le reste et le choix de Windev a donc été conservé.

3.2.2 Gestion des connexions entre les couplemètres et l’application serveur

Pour échanger des données avec les couplemètres, l’application serveur attend, dans un premier temps, des connexions entrantes (principe Client/Serveur). Dans cette partie du mémoire, je traite donc de fonctions « Socket » pour l’établissement de connexion réseau (entre un client et un serveur) et de fonctions « Thread » pour la gestion de traitements en parallèle.Ces fonctions (Socket et Thread) me servent à construire le noyau central de l’application serveur qui permet à un ou plusieurs clients, en l’occurrence ici des couplemètres TMV5, de se connecter à l’application serveur Qualitorq, afin d’établir une connexion, le temps d’échanger toutes les informations nécessaires au bon déroulement d’une session de mesures, effectuée par un opérateur devant son couplemètre.

Rappel sur le principe de fonctionnement d’un système Client/Serveur

Le principe de fonctionnement d’un système Client/Serveur est très simple : Le client prend l’initiative de se connecter au serveur. Le serveur écoute sur un numéro de port défini, les demandes de connexion entrante de la part des clients. Le serveur, après réception d’une demande de connexion de la part d’un client, peut adopter deux comportements possibles :

- Gestion « Mono Client » : le serveur accepte une connexion, la traite, la connexion est ensuite fermée et le serveur se remet en attente d’une nouvelle connexion. Si d’autres demandes de connexion arrivent au même moment, elles seront mise en attente et seront traitées une fois la connexion en cours terminée.

- Gestion « Multi Clients » : le serveur peut accepter et traiter simultanément une à plusieurs connexions entrantes. A chaque nouvelle connexion entrante, le serveur créé un nouveau processus, ou un nouveau thread, afin de traiter la connexion (Selon la méthode de développement du serveur, soit on parlera de processus soit de thread).

Dans une gestion « multi clients », le serveur traite toutes les connexions de manière concurrente. Le nombre maximum de connexions en parallèle à traiter possède, cependant, une limite qui dépend du système d’exploitation et des capacités physiques du PC serveur (taille de la mémoire, capacité et rapidité de traitement du processeur, …). Chaque processus ou thread créé, occupe de la place mémoire. Plus il y a de processus ou de threads qui s’exécutent en parallèle, plus le processeur est sollicité. Il faut donc trouver un compromis entre nombre de connexions à traiter en parallèle et capacité physique du PC serveur, pour éviter que ce dernier ne s’écroule. Néanmoins, selon les applications, les gains de temps pour


29

chaque client dans une gestion « multi clients » (serveur concurrent) vont être indéniables par comparaison avec la gestion « mono client ».

Rappel sur le principe de fonctionnement des processus et des threads

Pour ce projet, les threads vont être exploités pour traiter les connexions. Les threads sont à distinguer des processus au sens classique du terme. Un processus recouvre la notion d’application en train de s’exécuter et tout processus contient au moins un thread créé au début de l’exécution. Ce thread est nommé « thread primaire » ou « thread principal ». Pour illustration, en langage C, le thread primaire correspond à la méthode « main() ». Un processus peut regrouper différents threads qui vont partager à la fois les ressources allouées et le travail à effectuer. Dans les deux cas, threads ou processus servent à exécuter du code (traitements, procédures) en parallèle de l’application principale. La figure 14 illustre les notions de threads et de processus.

Fig. 14 Processus et Threads

Un thread (appelé aussi « processus léger »), est une entité d’exécution interne à un processus et possédant un environnement simplifié. Il correspond ainsi pour le processus englobant à une « tâche indépendante de même niveau » vue en quelque sorte comme une « sous routine » avec laquelle il partage ses ressources et surtout ses données.Tous les threads d’un processus partagent le même espace d’adressage virtuel et peuvent accéder aux variables globales et aux ressources du processus, les threads peuvent donc facilement communiquer entre eux. Chaque thread a sa propre zone de pile et ses propres registres. Un thread qui se bloque ne bloque pas les autres threads. Le système crée et exécute les threads plus rapidement que les processus, car ils sont déjà dans l’espace d’adressage du processus.Le système distribue des petites tranches de temps processeur (quantum) aux threads en compétition : le thread en cours d’exécution est suspendu quand son quantum de temps est écoulé, afin de permettre à un autre thread de s’exécuter. Sur un système monoprocesseur, il ne peut y avoir qu’une seule opération à la fois, donc un seul thread qui s’exécute, à un instant donné. En revanche, sur un système multiprocesseurs, plusieurs threads peuvent être exécutés en simultané, puisque chaque processeur peut exécuter un thread.

Dans le contexte particulier d’une architecture client/serveur, il peut s’écouler de quelques millisecondes à quelques heures (voire plus) entre le moment où la connexion est acceptée par le serveur, et donc qu’un canal de communication temporaire se crée entre le client et le


Processus

Ressources

Espace d’adressage

Thread

Thread

Thread

Thread

30

serveur, et le moment où la connexion se ferme. Tout dépend de la demande effectuée par le client. Par exemple, une requête d’un navigateur Internet demandant, à un serveur Web, un envoi de page HTML de quelques dizaines de kilo-octets ne nécessitera que très peu de temps (au plus quelques secondes) en comparaison avec le téléchargement d’un fichier d’une centaine de mégaoctets qui lui pourra prendre quelques dizaines de minutes voir quelques heures selon le débit de la connexion.

L’application serveur Qualitorq va donc être rendue capable de traiter plusieurs clients en parallèle au moyen de threads, elle est ainsi en mesure de gérer plusieurs sessions de mesures en « simultané ». L’application serveur est, également, tout à fait à même de répondre à un ensemble de requêtes provenant de navigateurs Internet. Différentes fonctions exploitant le protocole HTTP (HyperText Transfert Protocol), qui est le protocole servant à l’échange de page Web entre un serveur et un client, ont été spécifiées dans la perspective d’afficher un contenu informationnel traitant des sessions de mesures dans le format de balisage HTML (HyperText Markup Language). Plus de détails sont donnés dans la section 4.2.6.

L’application serveur Qualitorq va traiter l’ensemble des connexions grâce à la procédure « AttenteConnexionCplm() » qui s’exécute dans un thread et qui traite toutes les demandes de connexions entrantes :

Fig. 15 Code de la procédure d’écoute et d’acceptation des connexions entrantes

Dans le thread créé, un canal de communication est ouvert sur un numéro de port défini (le numéro de port se paramètre dans un fichier de configuration de l’application serveur Qualitorq) afin d’attendre les demandes de connexion, en d’autres termes une socket d’écoute est créée, et tous les clients qui voudront se connecter devront ouvrir une socket à destination de l’application serveur sur le numéro de port associé. Quand l’application serveur reçoit une demande de connexion sur la socket d’écoute, elle peut l’accepter ou la rejeter. Si la demande est acceptée, l’application serveur lance alors un nouveau thread qui va traiter cette nouvelle connexion et créée une nouvelle socket de connexion au client. Le thread d’attente de


// Cette procédure est elle-même exécutée par un ThreadPROCEDURE AttenteConnexionCplm()

// NewCanalCom sert à contenir un identifiant unique qui correspond au nom du canal de //communication vers la socket client qui a demandé la connexionNewCanalCom est une chaîne

BOUCLE SI SocketAttendConnexion ("SocketServeur") ALORS

NewCanalCom = SocketAccepte ("SocketServeur") // Vérification de l'opération d'acceptation SI NewCanalCom = "" ALORS Erreur ("Impossible de créer la socket nécessaire à la nouvelle connexion", ErreurInfo ( )) SORTIR SINON // Création d’un nouveau Thread qui va exécuter la procédure « ConnexionCplm » ThreadExécute (NewCanalCom, threadNormal, ConnexionCplm, NewCanalCom) FIN FINFIN

31

demandes de connexion va pouvoir alors continuer son travail d’écoute sur la première socket créée à cet effet.

Dans le nouveau thread, créé à la suite de l’acceptation de la demande de connexion du client, l’application serveur va traiter la ou les requêtes du client. Les requêtes varient selon les applications et les protocoles utilisés. En ce qui concerne l’application serveur Qualitorq, la première requête est une requête d’identification requise par le serveur pour poursuivre la communication avec le client. Les requêtes clientes sont définies dans un protocole propriétaire (relevant de la couche application), créé pour structurer les échanges. Ce protocole est abordé en détail dans le chapitre 3.3.

Lorsque la communication se déroule dans de bonnes conditions, l’application serveur reçoit en général plusieurs requêtes qui vont porter sur différentes informations relatives aux sessions de mesures. Dans le contexte du couplemètre TMV5, les requêtes pourront porter sur la consultation d’une liste de produits (bouchons – bouteilles), de numéros de lot, de lignes ou de sessions non clôturées, autant d’informations présentes dans la base de données. Lorsqu’il s’agit d’une requête HTTP, l’application serveur Qualitorq restitue au navigateur une page HTML générée dynamiquement avec des informations sur les sessions de mesures en cours.

Le thread créé par l’application serveur Qualitorq, suite à l’acceptation d’une connexion demandé par un client (couplemètre TMV5), peut ensuite être détruit à la survenue de différents évènements :

- L’application serveur reçoit la commande de clôture de session. Il s’agit de l’évènement marquant la fin du thread le plus habituel.

- Des requêtes entachées d’erreurs sont envoyées à l’application serveur, en trop grand nombre (notion de seuil).

- Le délai d’inactivité est trop important (existence d’un time out).- L’application serveur reçoit la commande « QUIT ».- L’administrateur ou le responsable qualité décide, à partir de la console de supervision

de l’application serveur, de stopper la session.

Toutes ces méthodes d’arrêt, en dehors de celle qui intervient à la suite d’une clôture de session, ont été mises en place afin d’améliorer les performances du système. Il n’est pas judicieux d’allouer les ressources du serveur à des threads rendus inutiles soit par inactivité, soit par inadéquation au système des requêtes posées.

3.2.3 Gestion des threads et des accès aux ressources

Dans le paragraphe précédent, on a vu que plusieurs threads pouvaient être créés, selon le nombre de connexions, pour traiter les communications entre le serveur et les couplemètres.

Le fait de créer et d’arrêter des threads pour réaliser les traitements nécessaires, exige une grande vigilance dans la conception et la réalisation du code de l’application. En effet, les traitements exécutés dans chaque threads se partagent des variables dans lesquelles ils sont tous susceptible d’écrire ou de lire. Ces variables sont : les variables globales du programme, les tables de la base de données (accès concurrents), le tableau d’affichage, des sessions de mesures en cours, sur la fenêtre principale de l’application serveur et certaines parties des


32

traitements comme par exemple la création d’un numéro de session unique pour chaque session de mesures réalisée.

Pour faire en sorte que toutes ces variables soient écrites et lues au bon moment, et veiller au bon fonctionnement de l’application, des fonctions dédiées à la gestion des threads vont nous être d’une grande utilité. Ces fonctions de synchronisation des threads vont relever, de ce que l’on appelle, les « Sémaphores » et les « Sections critiques ».

Rappel sur les sémaphores

Les sémaphores servent à limiter l’exécution d’un code (traitement, procédure, ligne de code) à un ou plusieurs threads à un instant donné. Les sémaphores agissent comme des portillons qui compte les threads entrant et sortant d’une zone de code, et limite ainsi le nombre de threads qui peuvent y accéder en même temps.Les sémaphores, vont permettre, par exemple, de limiter le nombre maximal de connexions simultanées ou encore de gérer la synchronisation entre plusieurs processus lors du partage d’une ressource.

Rappel sur les sections critiques

Une section critique est un sémaphore limité à un seul thread. La section critique sert à protéger une section de code, ainsi un seul thread aura accès à ce code à un instant donné. L’intérêt en est notamment de protéger des données partagées.

Synchronisation des threads

Grâce aux sémaphores et aux sections critiques, l’on va pouvoir synchroniser les threads. En manipulant ces fonctions, les accès sur certaines variables ou portions de code seront coordonnés et ainsi on évitera de lire ou d’écrire une variable à un moment inopportun. Un thread se synchronise lorsqu’il interrompt volontairement son exécution en attendant qu’un autre thread fasse une certaine opération.

Parmi ces fonctions, j’ai utilisé les sections critiques car il a fallu protéger l’accès à certaines parties du code.

Explications sur les parties de code à « protéger »

Création du numéro de session :

Quand un opérateur initie une nouvelle session de mesures, l’application serveur va automatiquement générer un numéro de session unique. Il est très important que ce numéro de session soit unique, il va en effet distinguer chaque session de mesures.Plusieurs opérateurs peuvent vouloir créer une session de mesures de manière simultanée, obligeant donc la partie du code qui génère le numéro de session à être sous la protection d’une section critique de manière à ne pas créer de doublon. Le numéro de session est composé de la date du jour (AAAAMMJJ) suivi de l’heure (HHMMSS) au moment de la création du numéro, Exemple : 20070216-143423. La probabilité que deux opérateurs créés une session de mesures et donc que l’application serveur génère deux numéros de session unique dans la même seconde et faible, mais le risque existe, car chaque thread à besoin de


33

quelques millisecondes pour s’exécuter, et dans la même seconde, un thread serait capable de générer plusieurs fois ce même numéro. Mieux vaut être sûr de ne pas tomber sur ce cas de figure.Pour créer ce numéro, la solution est donc de réserver le début du code à un seul et unique thread, de créer le numéro de session (« AAAAMMJJ – HHMMSS »), de vérifier s’il n’existe pas déjà, auquel cas on incrémente le numéro d’une seconde jusqu’à créer un numéro qui n’existe pas. Le code est ensuite laissé libre d’accès au bénéfice d’un autre thread ayant les mêmes besoins. Concernant l’incrémentation du numéro de session, la boucle s’arrête si au bout de n incrémentations le traitement n’arrive toujours pas à créer un numéro de session unique. L’application serveur envoie alors un message au client (couplemètre) lui indiquant l’impossibilité de démarrer une session. Cette méthode évite au thread de s’exécuter indéfiniment et donc de libérer le plus rapidement possible la partie de code protégée.Un diagramme d’activité UML illustre les comportements attendus du mécanisme d’attribution des numéros de sessions.

Fig. 16 Diagramme d’activité : Création du N° de Session

Création des numéros de lot :


Attente requête de démarrage d’une session

Protection du code : Section critique début

Création du N° de Session

Le N° de Session est-il unique ?

Enregistrement du N° de Session dans la base de

données

Boucle > 20 ?

Attente Mesures

Protection du code : Section

critique fin

Envoi du N° de Session au client

Incrémentation du N° de Session

Requête Client de démarrage d’une Session

N° de Session

OUI

NON OUI

NON

34

Les numéros de lot, comme la plupart des autres données (nom produits, …), peuvent être au préalable saisis dans la base de données par les responsables qualité, soit directement sur le serveur soit via un PC connecté à la base de données de l’application serveur Qualitorq. Cette saisie se fait au moyen d’une interface spécifique servant à lire, écrire ou supprimer toutes les informations nécessaires à la mesure de couple (en fait il s’agit d’une application de gestion des données de la base). Quand un opérateur réalise une session de mesures, toutes les données relatives à la session (nom produit, numéro de lot, ligne, …) existe donc déjà dans la base de données. L’opérateur n’a alors plus qu’à sélectionner les informations nécessaires. Il n’a pas besoin de faire de saisie (gain de temps et minimisation des erreurs de saisie). Cependant, le numéro de lot peut, dans certains cas, être entré directement par l’opérateur au travers du clavier virtuel du couplemètre TMV5. En effet, les numéros de lot sont des informations en constante évolution, il arrive parfois qu’à la réalisation d’une session de mesures, le numéro de lot n’ait pas déjà été saisi au préalable dans la base de données par un responsable qualité.Quand un opérateur crée un numéro de lot, il faut alors que l’application serveur effectue des contrôles appropriés avant de l’enregistrer dans la base de données. Ces contrôles sont également protégés par une section critique.Les contrôles à effectuer sont les suivant :

- Test de non existence du numéro de lot : il arrive parfois que le numéro de lot soit créé entre le moment de l’affichage de la liste des numéros de lot sur l’écran du couplemètre TMV5, et le moment de la saisie sur le clavier virtuel du TMV5, par le biais d’un autre thread sur l’application serveur

- Le numéro de lot n’existe pas (sous le couvert du contrôle précédent), en plus d’être pris en compte pour la session de mesures, il est ajouté dans la base de données en précisant à quel produit il est rattaché. Un commentaire automatique précise également qu’il a été créé par un opérateur via son couplemètre TMV5.

- Si le numéro de lot existe déjà, des tests de cohérence sont alors réalisés par l’application serveur. Le contrôle porte notamment sur l’adéquation du produit sélectionné au numéro de lot. Si c’est le cas, ce dernier est conservé comme paramètre pour la session de mesures. Le cas échéant, un message d’erreur sera affiché sur l’écran du couplemètre TMV5.

Envoi d’E-Mail d’alerte :

Une procédure globale, accessible à tous les threads, a pour utilité l’envoi d’emails en cas d’alerte. A chaque envoi d’un email, il faut remplir les variables d’une structure de données spécifique (adresse de l’expéditeur et du destinataire, nombre de destinataires, objet, message). Cette structure est globale à tous les threads, et le code d’envoi d’un email est donc sous la protection d’une section critique afin d’éviter que les variables de la structure aient des valeurs anarchiques, enlevant tout sens possible au message d’alerte.

Gestion du tableau d’affichage des sessions de mesures en cours :

Sur la fenêtre principale de l’application serveur, se trouve un tableau de synthèse pour lequel, chaque ligne correspond à une session de mesures en cours de réalisation par un opérateur. Dès qu’une connexion est ouverte entre un client (couplemètre TMV5) et l’application serveur, une ligne est créée dans ce tableau. Cette ligne disparaît une fois la connexion


35

fermée. Chaque ligne du tableau possède plusieurs colonnes contenant des informations qui évoluent en fonction de ce qui se passe entre le couplemètre TMV5 et l’application serveur. Les informations retrouvées sont par exemple : l’identifiant unique du couplemètre TMV5, son adresse IP, la date, l’heure, le numéro de session (s’il a déjà été crée), le produit, le numéro de lot, la mesure maximum et minimum, la moyenne, …Ce tableau est accessible à tous les threads, chacun renseignant la ligne qui lui est associée.

Fig. 17 Tableau des sessions en cours sur la fenêtre principale de l’application serveurUne fonction appelée périodiquement par un « Timer » lit chaque ligne du tableau et teste si le thread associé à la ligne n’a pas été supprimé (après fermeture de la connexion par exemple), auquel cas la ligne concernée sera supprimée du tableau. Cette fonction teste aussi le temps pendant lequel chaque thread est resté inactif. Au bout d’un certain temps d’inactivité, le thread sera détruit et la ligne qui lui correspond sera supprimée du tableau.

Le contenu de chaque ligne peut être, seulement, créé ou modifié par son thread, ou bien, seulement, supprimé du tableau par la fonction appelée périodiquement par Timer. Cette seconde fonction de suppression, sert essentiellement à faire le « ménage » dans le tableau afin de ne pas afficher l’état de sessions de mesures qui ne sont plus en cours de réalisation. Le but étant d’afficher dans ce tableau uniquement les informations essentielles.

Une ligne du tableau est modifiée ou supprimée au travers de son indice (pointeur). Cet indice donne la position de la ligne dans le tableau. L’indice de chaque ligne change de valeur continuellement, puisque des lignes vont être fréquemment supprimées. Dès qu’une ligne doit être modifiée, il faut donc commencer par trouver son indice, et entre le moment ou l’indice est trouvé et le moment où la ligne est modifiée, il ne faut qu’aucun autre thread ne puisse venir en perturber la modification, l’indice serait alors incorrect. La partie du code qui sert à trouver l’indice et à modifier la ligne correspondante est donc également protégée par une section critique.

A titre informatif, pour trouver l’indice d’une ligne, la fonction utilise un champ de la ligne contenant une information unique servant à discriminer une ligne d’une autre. Ce champ unique et l’identifiant du canal de communication donnée par la fonction socket qui accepte la connexion. Chaque thread qui veut créer ou modifier la ligne qui lui correspond, connaît cet identifiant. Il suffit donc de faire une recherche dans le tableau sur cet identifiant et une fois trouvé, on en déduit l’indice de la ligne dans le tableau.

Gestion de blocage des sessions de mesures en cours

Pour protéger les données accessibles par tous les threads, les fonctions de blocage opérant sur les enregistrements de la base de données, sont également exploitées en complément des sections critiques.Prenons le cas de la sélection d’une session de mesures non clôturée, qui reste à clôturer. L’opérateur a la possibilité de demander à l’application serveur la liste de ces sessions qui restent à clôturer (pour rappel, une session non clôturée est une session dont le nombre de


36

mesures à réaliser n’a pas été atteint pour diverses raisons : bogues sur le serveur ou sur le couplemètre, coupure de courant, erreurs de manipulation par l’opérateur, …). Selon les droits de l’opérateur, ce dernier pourra demander soit la liste complète de toutes les sessions de mesures non clôturées, soit seulement la liste des sessions non clôturées qui sont sous sa responsabilité. Une fois la liste envoyée au couplemètre et rendue visible, l’opérateur va sélectionner une session afin justement de finir les mesures et de pouvoir alors la clôturer.

Il est très important, au moment où l’opérateur choisit une session de mesures non clôturée, que celle-ci ne soit plus disponible aux autres opérateurs, jusqu’à ce qu’elle soit clôturée. L’enregistrement associé est alors bloqué en lecture et en écriture aux autres opérateurs. La session de mesure n’apparaît alors plus dans la liste des sessions non clôturées. Ce mécanisme de blocage permet d’éviter la survenue d’incohérence sur les données.

3.2.4 Traitement des mesures

Dans l’application serveur Qualitorq, différentes fonctions importantes servent à traiter les mesures de couple.Les mesures arrivent au fur et à mesure qu’elles sont effectuées par l’opérateur et non en masse. De cette manière elles sont enregistrées, dans la base de données, au fur et à mesure de leur arrivée, évitant ainsi, en cas de problème, de les perdre.

Quand l’application serveur Qualitorq reçoit une mesure, elle effectue plusieurs traitements :

- Récupération de la mesure et de l’unité de la mesure (Kgf.cm, N.cm, …) dans la trame de données envoyée par le couplemètre.

- Vérification de la cohérence de l’unité de mesure du couple par rapport à l’unité spécifiée par le responsable qualité, dans le cas contraire l’application serveur envoie un message sur l’écran du couplemètre pour indiquer le problème à l’opérateur. On peut imaginer, dans une future amélioration du système, une fonction qui permettrait à l’application serveur de reprogrammer automatiquement l’unité du couplemètre.

- L’unité est correcte, l’application serveur vérifie maintenant si la mesure est plausible. En effet, des erreurs de manipulation peuvent survenir lors des mesures et peuvent fausser celles-ci, il faut invalider ces mesures erronées afin de ne pas fausser les calculs statistiques. Pour le moment, quand elle reçoit une mesure égale à zéro, l’application serveur se contente de la refuser et d’envoyer un message au couplemètre. Il existe d’autres méthodes pour vérifier la validité des mesures qui viennent d’être effectuées, mais ces méthodes ne sont, pour le moment, pas implémentées dans l’application serveur. Une future amélioration sera par exemple de contrôler que la mesure ne soit pas trop éloignée de la moyenne.

- La mesure est plausible, l’application serveur va enregistrer la mesure dans la base de données et ensuite calculer les statistiques de la session de mesures en cours en prenant en compte cette mesure qui vient d’être effectuée. Les calculs statistiques sont par exemple les mesures minimum et maximum, la moyenne, l’écart type et le pourcentage qualité de valeurs qui tombent entre un seuil minimum et un seuil maximum (ces seuils (ou bornes) sont paramétrés par le responsable qualité).


37

- L’application serveur va envoyer, au couplemètre, une trame d’acquittement contenant les informations suivantes : la mesure, l’unité, les calculs statistiques (pour que le couplemètre puisse les afficher et que l’opérateur puisse en prendre connaissance) et le numéro de la mesure ou encore l’indication « FIN » si il s’agit de la dernière mesure à effectuer.

Fig. 18 Diagramme d’activité : Réception des mesures

3.3 Protocole de communication

Dans la communication entre un serveur et des clients, comme dans toute communication en général, il est nécessaire de structurer les données échangées et donc de mettre en place un protocole de communication, compréhensible par tous les interlocuteurs.


Réception d’une Trame de mesure

Extraction de l’unité

L’unité de mesure est-elle

correcte ?

Extraction de la mesure

La mesure est-elle plausible ?

Envoi message d’erreur mesure

Envoi message d’erreur unité

Le nombre de mesures à effectuer a-t-il été

atteint ?

Incrémentation du nombre de mesures

reçues pour la session en cours

Envoi trame d’acquittement au client

Calculs statistiques avec les mesures

Enregistrement de la mesure dans la base de données

OUI

NON

OUI

NON

Trame de mesure

OUINON

38

Dans le cadre de ce travail, les composants du système (serveur, couplemètre et PC) ont besoin d’échanger des données, la création d’un protocole dédié à cet effet, s’est révélé nécessaire.

3.3.1 Objectifs d’un protocole dédié

Quand un opérateur effectue une session de mesure avec un couplemètre, il est loin d’imaginer toutes les informations qui peuvent être échangées entre le couplemètre et l’application serveur. Le couplemètre peut être comparé à un terminal qui ne contient aucune donnée en mémoire mais qui possède un minimum de fonctions pour être capable de réaliser des mesures de couple, afficher des données sur son écran, gérer l’écran tactile et communiquer avec l’application serveur. En effet, toutes les données relatives à la mesure de couple sont stockées dans la base de données de l’application serveur. La communication entre le couplemètre et l’application serveur sert, dans un sens, à transmettre toutes les données nécessaires à l’opérateur pour qu’il puisse prendre connaissance et choisir les éléments qui renseignent la session de mesures qu’il va effectuer, et dans l’autre, à transmettre d’une part les éléments choisis, par l’opérateur, pour la session de mesures, et donc en faire prendre connaissance à l’application serveur, et d’autre part les mesures de couple, éléments essentiels du système, que l’application serveur enregistrera au fur et à mesure.

Donc pour que toutes ces données puissent être échangées entre les couplemètres et l’application serveur, un protocole de communication spécifique à ce système (protocole pour la couche application, couche n° 7 du modèle OSI (Open System Interconnect) ou n° 5 du modèle Internet, mais aussi utilisé dans les réseaux locaux) va venir se rajouter aux protocoles déjà existants, Ethernet et TCP/IP.

Pour ce projet, hormis les protocoles des quatre premières couches (Ethernet, IP et TCP), il n’était pas possible d’utiliser un protocole déjà existant pour la couche application. En effet, les protocoles de la couche application servent de support aux applications pour échanger des données qui les concernent directement et chaque application possède son propre protocole, en quelque sorte privé, pour la couche application.

3.3.2 Positionnement par rapport au modèle OSI

Comme précisé dans le titre du sujet mémoire, les échanges de données, entre les couplemètres TMV5 et l’application serveur, se font sur un réseau via les protocoles Ethernet et TCP/IP. Au final, la communication se fait par l’emboîtement (ou l’encapsulation) de plusieurs protocoles les uns dans les autres.

Depuis la création des réseaux informatiques, ingénieurs et chercheurs ont étudié et mis au point différents protocoles de communication. Ces protocoles sont soit ouverts, soit propriétaires et présents dans une ou plusieurs applications. Les protocoles Ethernet et TCP/IP possèdent l’avantage d’être largement répandus, c’est la raison pour laquelle ils sont préférés, ici, à d’autres protocoles candidats.


39

Les différents modèles en couches, des protocoles considérés ici, sont illustrés dans la figure 19.

Fig. 19 Modèle en couches des protocoles

Chaque couche possède un rôle spécifique et chacune est indispensable pour faire transiter une donnée d’une application à une autre via le support physique du réseau.

Rappel sur la couche N°1 : « Physique »

Le rôle de la couche physique est la transmission des bits sur le support physique d’interconnexion.

Ces fonctions principales sont : - Fournir les caractéristiques électriques, mécaniques et fonctionnelles permettant

d’activer, maintenir et désactiver une transmission ;- Définir le mode d’exploitation (semi duplex, duplex intégral, parallèle, série, …) ;- Réaliser une connexion (permanente, dynamique, point à point ou multipoint) ;- Assurer la compatibilité des interfaces qui réalisent les fonctions de codage,

modulation et amplificateur du signal.

Exemples: V24, X21, RS232, Multiplexeur, Transceiver, MAU, HUB, Répéteur, Prise DB25, DB9, RJ45, RJ11, …

Rappel sur la couche N°2 : « Liaison »

La couche liaison est responsable de l’acheminement sans erreur de blocs d’informations sur la ligne physique.


Application

Présentation

Session

Transport

Réseau

Liaison

Physique

Application

Transport

Réseau

Liaison

Physique

Protocole conçu spécifiquement pour le système de mesures de

couple

TCP

IP

Ethernet

Ethernet

Modèle OSI Modèle Internet / réseau local

Modèle utilisé pour le système de mesures de couple

40

Ces fonctions principales sont :- Etablir et libérer les connexions ligne ;- Assurer la mise en trames et la synchronisation ;- Détecter et corriger les erreurs de transfert ;- Gérer le contrôle de flux.

Exemples de protocoles pour cette couche : Ethernet 802.3 CSMA/CD, Token Ring 802.5, Token Bus 802.4, …

Ethernet est une norme de protocole de réseau local (LAN) qui fut inventée dans les années 1970. Le standard Ethernet utilise la méthode CSMA/CD (Carrier Sense Multiple Access with Collision Detect) pour l’accès au support physique (norme IEEE 802.3). Les vitesses de transmission possibles sont 10 ou 100 Mbits/s ou 1 GBits/s et dépendent du support physique utilisé (câblage).

Rappel sur la couche N°3 : « Réseau »

La couche réseau a en charge le dialogue et la connexion avec des entités distantes, éventuellement situées sur des réseaux différents seulement accessibles par le franchissement de plusieurs interconnexions. Ces fonctions sont :

- Etablir et rompre une connexion ;- Contrôler les erreurs de transmission ;- Réaliser un contrôle de flux ;- Réaliser le routage.

Exemples de protocoles pour cette couche : IP (Internet Protocol), IPX (Internet Packet eXchange), …

Rappel sur la couche N°4 : « Transport »

La couche transport est responsable du transport des informations de bout en bout au travers du réseau. Au dessus de cette couche les caractéristiques physiques du réseau n’apparaissent plus.

Ces fonctions sont :- Gérer les adresses de transport ;- Gérer le transport en établissant et libérant une connexion ;- Gérer les messages : segmentation des données et réassemblage des données ;- Gérer la qualité de service : acquittement et retransmission sur absence

d’acquittement, multiplexage des données, contrôle de flux et détection des erreurs.

Exemples de protocoles pour cette couche : TCP (Transmission control Protocol), UDP (User Datagram Protocol), SPX (Sequenced Packet eXchange), …

Rappel sur la couche N°5 (N°7 sur le modèle OSI) : « Application »


41

La couche application réalise l’interface pour les fonctions de communication avec les applicatifs.

Exemples de protocoles pour cette couche : FTP (File Transfert Protocol) HTTP (HyperText Transfert Protocol), SMTP (Simple Mail Transfert Protocol), …

3.3.3 Détails sur le protocole « Application »

La création d’un protocole pour la couche application a été réalisée après étude de protocoles existants (SMTP, FTP, HTTP, …) en consultant les RFC et autres sites spécialisés.

La simplicité est une des qualités recherchées pour ce protocole (il faut penser au développement des applications clientes). Il est également essentiel de penser à alléger le trafic tout en préservant l’échange d’un maximum de données prenant un minimum de place (ou de longueur).Une réponse est attendue dès que l’application serveur reçoit une requête du client, soit directement à la requête, soit par envoi d’une trame d’acquittement comme par exemple : +OK.

Les deux premières requêtes créées servent à se connecter et se déconnecter :

LOG ; [Nom Utilisateur] ; [Mot de passe] ; [Id Couplemètre] ; <CR><LF>EtQUIT<CR><LF>

Toutes les requêtes, de commande, de demande ou de réponse, commence toujours avec une chaîne de caractère en majuscule (LOG, OBTENIR, SELECT, INIT, START, STOP, LIST, PARAM, MESURE, COMMENTAIRE, INFO). Ainsi quand la trame de caractères est reçue, il suffit de lire ce premier champ pour comprendre immédiatement l’ordre indiqué et donc orienter vers le traitement adéquat.Chaque champ, qui compose la requête, peut être de longueur variable, et est séparé de ses voisins par des points virgule « ; ». Un soin particulier est apporté au respect du rang de chaque champ afin d’avoir des trames pouvant transporter des données différentes mais ayant une structure à peu près similaire. Ainsi il fut aisé de développer une routine permettant une lecture rapide d’un champ d’une trame au rang n.Toutes les trames sont terminées par un « CRLF » (en anglais : Carriage Return - Line Feed ; en français : Retour chariot - saut de ligne), c'est-à-dire les caractères 13 et 10 du code ASCII. Ce « CRLF » sert à indiquer la fin de la trame. Ces deux caractères de fin de trame sont utilisés depuis très longtemps dans les protocoles de communication. Les fonctions socket utilisent ce « CRLF » pour savoir quand arrêter de lire le « buffer » (ou zone tampon en français) et rendre la main (lecture bloquante).

En réponse à la demande de déconnexion du client (commande : QUIT<CR><LF>), l’application serveur répond par : +OK ; QUIT ; <CR><LF>

Pour toute commande incorrecte, demande d’informations non autorisée ou message d’erreur, l’application serveur renvoie toujours une trame commençant par les caractères : -ERR ; … ; <CR><LF>


42

Exemples sur une demande de connexion avec un nom d’utilisateur inexistant ou un nom d’utilisateur associé à un mauvais mot de passe :Réponse de l’application serveur : -ERR ; LOG ; NULL ; Compte Utilisateur Inexistant ; <CR><LF>-ERR ; LOG ; MDPI ; Mot De Passe Incorrect ; <CR><LF>

L’intitulé de l’erreur dans la trame est dupliqué, c'est-à-dire présent de manière complète et abrégé (1ère lettre de chaque mot du message). Le message complet est très pratique car on peut l’afficher directement à l’écran du couplemètre par exemple, ou lors de tests de débogage avec « Telnet » ou « Hyperterminal » car on voit immédiatement à quelle erreur correspond le message. La version du message en abrégé peut être utile si dans le code de certaines routines des comparaisons sont réalisées avec d’autres chaînes de caractères, pour par exemple tester l’égalité de deux chaînes.Le nombre de messages d’erreur différents pour une même requête peut varier selon le type de la requête.

3.3.4 Détails des différentes demandes, commandes et réponses

Pour faire en sorte qu’un opérateur puisse réaliser une session de mesures avec tout ce que cela implique à partir d’un couplemètre, il a fallu concevoir de nombreuses trames de requête.

Les trames de requêtes du protocole peuvent se classer en plusieurs catégories :

- Les requêtes de connexion et de déconnexion à l’application serveur- Les requêtes d’obtention des listes d’éléments à choisir pour réaliser une session de

mesures- Les requêtes de sélection des éléments pour une session de mesures- Les requêtes d’initialisation de paramètres- Les requêtes de démarrage et de clôture d’une session de mesures- Les requêtes d’envoi de mesures et de commentaires à l’application serveur

Les requêtes de connexion et de déconnexion à l’application serveur :

Requêtes servant à se connecter à l’application serveur :

A titre informatif, il n’existe en réalité aucun espace entre les différents champs et les « ; » (point virgule), ils apparaissent seulement dans ce document pour des raisons de lisibilité.

Requête du client : LOG ; [Nom Utilisateur] ; [Mot de passe] ; [Id Couplemètre] ; <CR><LF>[Id Couplemètre] doit être remplacé par l’identifiant unique du couplemètre. L’application serveur utilise cet identifiant pour l’enregistrer dans les éléments d’une session de mesures. Il est parfois intéressant de pouvoir identifier l’appareil qui a servi à effectuer certaines sessions de mesures, car selon les résultats, l’appareil peut avoir besoin d’être étalonné.Réponse du serveur : USER ; [Nom Utilisateur] ; Statut=[X] ; SessionAuto=[Y] ; <CR><LF>


43

La valeur X du statut peut être égale à : 1, 2 ou 3 (1 = Utilisateur, 2 = Super Utilisateur, 3 = Administrateur).La valeur Y peut être égale à 0 ou 1 (0 = Faux et 1 = Vrai). Dans le cas où « session auto » est égal à 1 et que l’opérateur demande la liste des fiches mesures, l’application serveur envoie, dans sa réponse, une seule fiche, c'est-à-dire celle qui a été paramétrée par le responsable qualité par rapport à l’opérateur ainsi que par rapport à la date et à l’heure du départ de la session de mesures.Selon les paramètres de la requête, l’application serveur pourra aussi envoyer différentes réponses d’erreur spécifiques : le mot de passe est incorrect, le compte utilisateur est inactif ou vient d’être désactivé suite à plusieurs tentatives de connexion avec un mot de passe incorrect, le compte utilisateur est inexistant. Exemple de trame d’erreur :

-ERR ; LOG ; MDPI ; Mot De Passe Incorrect ; <CR><LF>

Requête servant à se déconnecter :

Requête du client : QUIT<CR><LF>

Réponse du serveur : +OK ; QUIT ; <CR><LF>

Les requêtes d’obtention des listes d’éléments :

Ces requêtes servent à obtenir la liste des éléments à choisir qui composent une session de mesures. Ces éléments sont : le nom du produit sur lequel l’opérateur va effectuer les mesures de couple, le numéro de lot qui correspond au produit choisi, le nom ou le numéro de la ligne sur laquelle sont prélevés les échantillons du produit à mesurer. On peut aussi demander la liste des fiches mesures (fiche qui auront été préparées au préalablement par un responsable qualité), ou la liste des sessions non clôturées (au cas où il y en aurai).

Ces requêtes sont composées de la manière suivante :

Requête du client : OBTENIR ; [Elément] ; <CR><LF>[Élément] doit être remplacé par : PRODUIT, LOT, LIGNE, FICHE ou SESSION_NC

Réponse du serveur : LIST ; PRODUIT ; [X] ; [Nom du Produit] ; <CR><LF>X compteur allant de 1 à n en fonction du nombre de produits envoyésCette première trame est envoyée autant de fois qu’il y a de produit…

LIST ; PRODUIT ; FIN ; [Y] ; <CR><LF>Cette seconde trame est envoyée quand l’envoi de tous les produits est terminéY nombre de produits envoyésSi il n’y a pas de produit dans la base de données, seul cette seconde trame de réponse sera envoyé avec Y égal à 0.


44

Exemple de requête envoyée à l’application serveur pour obtenir la liste des produits :Requête du client : OBTENIR ; PRODUIT ; <CR><LF>

Réponse du serveur : LIST ; PRODUIT ; 1 ; Bouch-Bleu-34 ; <CR><LF>LIST ; PRODUIT ; 2 ; Bouch-Vert-37 ; <CR><LF>LIST ; PRODUIT ; 3 ; Bouch-Rouge-44 ; <CR><LF>LIST ; PRODUIT ; FIN ; 3 ; <CR><LF>

Le processus est identique pour les autres éléments (numéro de lot, ligne, …).

Les requêtes de sélection des éléments :

Ces requêtes servent à sélectionner les éléments qui composent une session de mesures. Ces éléments sont les mêmes que ceux cités précédemment pour les requêtes d’obtention.

Ces requêtes sont composées de la manière suivante :

Requête du client : SELECT ; [Elément] : [Nom élément] ; <CR><LF>[Élément] doit être remplacé par : PRODUIT, LOT, LIGNE, FICHE ou SESSION_NC[Nom élément] doit être remplacé par le nom de l’élément à sélectionner (que l’opérateur aura choisi dans la liste) pour la session de mesures. Exemple d’un nom de produit : Bouch-Bleu-34

Réponse du serveur : PARAM ; [Elément] ; [Nom de l’élément] ; <CR><LF>La réponse envoyée par l’application serveur, indique bien que l’élément sélectionné a bien été paramétré pour la session en cours.

Exemple de requête envoyée à l’application serveur pour paramétrer le numéro de lot sur lequel est réalisée la session de mesures :

Requête du client : SELECT ; LOT ; Lot-0702-454 ; <CR><LF>

Réponse du serveur : PARAM ; LOT ; Lot-0702-454 ; <CR><LF>La réponse envoyée par l’application serveur, indique bien que le numéro de lot « Lot-0702-454 » a bien été paramétré pour la session en cours.


45

Autre réponse possible de l’application serveur si ce lot est inexistant dans la base de données :

-ERR ; SELECT ; LOT ; NULL ; Lot Inexistant ; <CR><LF>

Les requêtes d’initialisation de paramètres : Ces requêtes servent à initialiser pour la session en cours des éléments qui n’existent pas dans la base de données. Ces éléments peuvent être par exemple le numéro de lot ou le nombre de mesures à effectuer pendant la session de mesures.Ces requêtes sont composées de la manière suivante :

Requête du client : INIT ; LOT ; [N° de lot] ; <CR><LF>[N° de lot] doit être remplacé par le numéro de lot à créer dans la base de données et qui sera attaché à la session de mesures en coursRéponse du serveur : PARAM ; LOT ; [N° de lot] ; <CR><LF>La réponse de l’application serveur indique bien que ce nouveau numéro a bien été pris en compte pour la session et qu’il a bien été enregistré dans la base de données puisqu’il est nouveau.

Si les droits de l’opérateur ne l’autorisent pas à créer un nouveau numéro de lot, l’application serveur répondra par le message d’erreur suivant :

-ERR ; INIT ; LOT ; NA ; Non Autorisé ; <CR><LF>

Les requêtes de démarrage et de clôture d’une session de mesures :

Ces requêtes servent à démarrer et à clôturer une session de mesures. Une fois que l’opérateur a choisi tous les éléments qui composent et renseignent une session de mesures (produit, numéro de lot, ligne, …), il lui faut démarrer la session pour commencer les mesures.

La requête servant à démarrer la session de mesures et la suivante :

Requête du client : START ; SESSION ; <CR><LF>Quand l’application serveur reçoit cette requête, elle crée le numéro de session et enregistre la création de cette nouvelle session avec ses paramètres dans la base de données, ensuite elle se met en attente des mesures.

Réponse du serveur : START ; SESSION ; [N° de Session] ; [Nom Utilisateur] ; [Date] ; [Heure] ; [Nom Produit] ; [N° de Lot] ; [Nom Ligne] ; [Seuil 1] ; [Seuil 2] ; [Seuil 3] ; [Seuil 4] ; [Unité] ; [Nombre de Mesures à effectuer] ; <CR><LF>


46

L’application serveur envoie pour réponse, la requête ci-dessus contenant le numéro de session qui vient d’être généré et le récapitulatif de tous les éléments sélectionné par l’opérateur pour effectuer la session de mesures (ce qui est bien utile pour voir si l’opérateur ne s’est pas trompé dans le choix des éléments).

Si l’opérateur démarre la session alors qu’il n’a pas paramétré entièrement tous les éléments, l’application serveur envoie la réponse suivante :

-ERR ; START ; SESSION ; PM ; Paramètre Manquant ; <CR><LF>Ou bien en cas de problème de création du numéro de session par l’application serveur, cette dernière envoie la réponse suivante :

-ERR ; START ; SESSION ; CNSI ; Création du N° de Session Impossible ; <CR><LF>

Une fois les mesures terminées, le client envoie une requête de clôture de la session :

Requête du client : STOP ; SESSION ; <CR><LF>

Réponse du serveur : STOP ; SESSION ; OK ; <CR><LF>

Les requêtes d’envoi de mesures et de commentaires à l’application serveur :

Une fois la session démarrée (après un « START ; … »), l’application serveur se met en attente des nouvelles mesures. Quand un client envoie une mesure à l’application serveur, la requête est la suivante :

Requête du client : MESURE ; COUPLE ; [Valeur Mesurée] ; [Unité] ; <CR><LF>

Réponse du serveur : MESURE ; COUPLE ; [X] ; [Valeur Mesurée] ; [Unité] ; [Min] ; [Max] ; [Moyenne] ; [Ecart Type] ; [% Qualité de bonne mesures] ; <CR><LF> X Numéro de la mesure ou FIN si c’était la dernière mesure à effectuer

La réponse de l’application serveur est composée de plusieurs éléments qui sont : le numéro de la mesure (afin de savoir combien l’opérateur en a déjà fait), la valeur du couple mesurée, l’unité du couple et les calculs statistiques sur la session en cours (pour les afficher à l’écran du couplemètre TMV5 afin que l’opérateur puisse en prendre connaissance au fur et à mesure qu’il effectue ses mesures).

Si dans les trames on retrouve le champ « COUPLE », c’est qu’il est envisagé de pouvoir utiliser cette application serveur pour d’autres types de mesures (poids, CO2, …), et donc le but de ce champ est de comporter le nom du type de mesures.

En cas de refus de la mesure par l’application serveur, pour certaines raisons (mesure non plausible, …), la réponse envoyée sera la suivante :


47

-ERR ; MESURE ; COUPLE ; VMNP ; Valeur Mesurée Non Plausible ; <CR><LF>

Avant de clôturer la session de mesure (avec la requête : STOP ; …), l’opérateur peut, si nécessaire, ajouter un commentaire à la session de mesures. La requête envoyée par le client est alors la suivante :

Requête du client : COMMENTAIRE ; [Commentaire] ; <CR><LF>

[Commentaire] doit être remplacé par le commentaire de l’opérateur. Le nombre de caractères total peut varier en fonction du besoin des clients et donc des paramètres de l’application serveur.

Réponse du serveur : COMMENTAIRE ; OK ; [Nbr de caractères saisies / Nbr de caractères total disponible] ; <CR><LF>

L’application serveur indique dans la réponse, le nombre de caractères déjà saisis sur le nombre total disponible afin de faire savoir à l’opérateur si celui-ci peut encore compléter par d’autres commentaires si besoin. Si l’opérateur dépasse le nombre de caractères disponibles, le message sera réduit au nombre de caractères maximum. Si l’opérateur essaye d’envoyer un nouveau commentaire alors que la zone mémoire allouée à ces derniers est pleine, la réponse de l’application serveur sera la suivante :

-ERR ; COMMENTAIRE ; ZCP ; Zone Commentaire Pleine ; <CR><LF>

3.4 Organisation de la communication entre les couplemètres et l’application serveur

Pour qu’un client puisse communiquer avec l’application serveur, il lui est obligatoire de respecter le format des trames de données, mais il lui est aussi obligatoire de respecter un ordre d’envoi des requêtes.

3.4.1 Organisation des échanges de données entre les couplemètres et l’application serveur

Pour pouvoir réaliser une session de mesure, l’envoi des requêtes doit respecter un ordre particulier. La toute première chose à faire, dans tous les cas, est l’envoi de la requête de connexion au serveur. Sans identification il est impossible de se connecter à l’application serveur, cette dernière n’acceptant pas les connexions anonymes.

Une fois connecté à l’application serveur, il est possible, en dehors des sessions de mesures, d’envoyer une requête pour obtenir la liste des sessions en cours et ensuite se déconnecter.


48

Cette requête n’est pas utilisée par les couplemètres, mais est plutôt destinée à l’être à partir d’une application cliente sur PC.Quand un opérateur veut effectuer une session, et selon son statut (utilisateur, super utilisateur), un ordre d’envoi des requêtes est à respecter. Cet ordre est modélisé au travers de différents diagrammes de séquences.

3.4.2 Représentation des échanges par des diagrammes de séquences

Dans tous les cas, les premiers échanges servent à l’authentification de l’utilisateur ou de l’opérateur :

Fig. 20 Diagramme de séquences : connexion

Si pour l’opérateur connecté, l’option « Session Auto » est activée, quand celui-ci demandera la liste des fiches mesures, il ne recevra qu’une seule fiche en fonction de la date et de l’heure au moment de cette demande :

Fig. 21 Diagramme de séquences : demande de la liste des fiches en mode Session Auto

En revanche, si pour l’opérateur connecté, l’option « Session Auto » n’est pas activée, il recevra une liste avec toutes les fiches mesures qui lui sont attribuées :


: Application Serveur: Couplemètre

Connexion utilisateur

Connexion OK


Obtenir Fiches

Confirmation de la sélection de l’unique Fiche reçue

Sélection Fiche OK

Envoi de la Fiche

49

Fig. 22 Diagramme de séquences : demande de la liste des fiches en mode Session non auto

Dans le diagramme ci-dessous, on se trouve dans le cas ou le paramétrage des différents éléments de la session est réalisé séquentiellement et non pas automatiquement avec une fiche mesures comme ci-dessus :

Fig. 23 Diagramme de séquences : Choix des différents éléments d’une session de mesures

Concernant le numéro de lot, il est possible de le paramétrer de deux manières (d’où le OU) :



Obtenir Fiches

Liste des Fiches

Sélection d’une Fiche

Sélection Fiche OK


Obtenir Produits

Liste des Produits

Sélection d’un Produit

Sélection Fiche OK

Obtenir les N° de Lots

Liste des N° de Lots

Sélection d’un N° de Lot

Sélection du N° de Lot OK

Obtenir Lignes de Production

Liste des Lignes de Production

Sélection d’une Ligne

Sélection Ligne OK

Initialisation de Nbr de mesures à effectuer

Initialisation OK

Initialisation du N° de Lot

Initialisation OK

OU

50

- le numéro de lot des échantillons que l’on veut mesurer existe déjà dans la base de données, il suffit alors de demander la liste des numéros de lot à l’application serveur. Cette dernière envoie donc tous les numéros de lot (actif) qui correspondent au produit choisi précédemment (puisque chaque numéro de lot est rattaché à un produit). Il reste alors à en choisir un dans la liste.

- le numéro de lot n’existe pas dans la base de données (car trop récent pour avoir déjà été saisi), l’opérateur va directement le saisir sur le clavier virtuel du couplemètre et validera pour l’envoyer à l’application serveur qui, elle, fera une vérification (s’il est bien inexistant) et enverra un acquittement si la vérification s’est bien passée.

Ce diagramme montre la possibilité de reprendre une session de mesures non clôturée. L’opérateur demande la liste des sessions non clôturées et une fois la liste visible à l’écran du couplemètre il n’aura plus qu’à en choisir une :

Fig. 24 Diagramme de séquences : Reprendre une session de mesures pour la clôturer

Une fois que les éléments de la session de mesures ont été paramétrés, et pas avant, l’opérateur clique sur le bouton « START » à l’écran du couplemètre ce qui envoie à l’application serveur une requête de démarrage des mesures :

Fig. 25 Diagramme de séquences : Envoi des mesures à l’application serveur



Obtenir Session Non Clôturées

Liste des Sessions Non Clôturées

Sélection d’une Session Non Clôturées

Sélection Session Non Clôturées OK


START Session

START Session OK

Envoi d’une Mesure

Mesure OK

…

Envoi d’un Commentaire

Commentaire OK

STOP Session

STOP Session OK

51

Une fois que l’application serveur a reçu la requête « START », elle envoie un acquittement au couplemètre pour signaler que l’opérateur peut commencer les mesures de ses échantillons car elle est prête à les recevoir. Une fois la mesure, de chacun des échantillons, terminées, l’opérateur peut, si besoin, saisir un commentaire avec le clavier virtuel et l’envoyer à l’application serveur qui en prendra compte dans la session. L’opérateur clôturera ensuite la session de mesures en cliquant sur « STOP », à l’écran du couplemètre, ce qui aura pour effet d’envoyer la requête de clôture à l’application serveur qui en prendra compte et qui enverra un acquittement au couplemètre pour indiquer que tout c’est bien passé.

3.5 Détails sur la base de données de l’application serveur

Le gestionnaire de base de données exploité, en association avec l’application serveur Qualitorq, est fourni avec l’AGL (Atelier de Génie Logiciel) Windev. Le nom commercial de ce gestionnaire de base de données est « Hyper File ». « Hyper File » existe en deux versions, une version client/serveur et une version en mode fichiers partagés (comme Access de Microsoft). Ce projet s’appuie sur la version fichiers partagés. L’AGL Windev propose une interface de création du modèle de données. La création physique des fichiers de données se fait au moment de lancer pour la première fois l’application avec une commande qui crée les fichiers s’ils sont inexistants.

L’accès à « Hyper File » se fait au travers du langage de requêtes SQL (Structured Query Language) ou bien au travers de fonctions spécifiques au langage de développement de Windev. Ces fonctions spécifiques offrent toutes les possibilités que peut offrir le langage SQL (ajout, suppression, modification, …). Dans ce projet, les deux possibilités offertes sont exploitées. Les requêtes SQL, vont permettre de proposer à l’utilisateur de faire des recherches de sessions de mesures en fonction de critères comme : la date, l’heure, le nom du produit, le numéro de lot et le nom de la ligne.

3.5.1 Détails sur les données composant la base de données

La base de données est composée, physiquement, de onze tables. Cette base sera amenée à évoluer en fonction du besoin des clients et peut-être en fonction des nouvelles fonctionnalités, à apporter, dans l’avenir, à l’application serveur. A mon sens, il est plus judicieux de concevoir et implanter une base de données spécifiquement adaptée au besoin de chacun des clients et de ne pas chercher à forcément répondre aux besoins de tous les clients par un schéma de données unique. Chaque client a besoin de stocker des données différentes pour une même application. Pour donner un exemple, certains clients distinguent bouchon et bouteille, c'est-à-dire que chacun de ces deux éléments possède une référence bien à lui, d’autres utilisent une seule référence pour nommer le couple bouchon - bouteille. Certains travaillent avec des références produit, des numéros de lot, d’autres avec des numéros de sous lot et des numéros de sous-sous lot, ou encore avec des codes PF (Produit Fini) et SF (Semi Fini), …

Donc le but, à la conception, est de partir avec une base de données contenant le minimum d’informations tout en prévoyant des extensions possibles et donc une augmentation du nombre de tables et de champs.


52

La base telle qu’elle est aujourd’hui, contient le nombre minimum de tables et de champs de données nécessaires à la réalisation d’une session de mesures, c'est-à-dire : une table « Session » contenant les champs numéro de session, date et heure, l’identifiant du couplemètre qui sert à faire les mesures, l’identifiant de l’opérateur qui réalise la session et donc les mesures, le nom du produit et le numéro du lot auquel il appartient, le nom ou numéro de la ligne sur laquelle l’opérateur prend les échantillons du produit en question à mesurer, l’unité de mesure du couple, un champ booléen pour savoir si oui ou non la session a été clôturée et dans une autre table « Mesure » attaché à la table « Session », un champ mesure, l’heure de la mesure, son numéro et un identifiant pour savoir à quelle session se rattache la mesure.Ces deux tables sont les plus importantes de la base de données. Les autres tables contiennent les produits, les numéros de lot, les lignes, les seuils de comparaisons des mesures, les utilisateurs, les fiches mesures et une table dans laquelle sont enregistrés tous les évènements. Le choix de cette base de données avec les tables et les champs qui la composent, est un choix qui s’est affiné sur plusieurs années d’expériences. C'est-à-dire que cette base, si on enlève les tables et les champs ajoutés pour le fonctionnement de l’application serveur Qualitorq, est aussi utilisé dans la version du logiciel Qualitorq classique (voir explications précédentes sur les différentes versions de Qualitorq avec TMV4 et TM5). Au fur et à mesure des versions du couplemètre et donc des versions du logiciel Qualitorq, la base de données a évoluée, avec l’expérience du terrain et les retours clients.

Beaucoup de sociétés utilisent des PGI (Progiciel de Gestion Intégré ou ERP en anglais pour Enterprise Ressource Planning : SAP, PeopleSoft Enterprise, …), dans lesquels toutes les données de l’entreprise sont stockées (GRH, gestion comptable et financière, données commerciales, données de production, retour client, données de contrôle qualité, …) dans le but de fournir des analyses complexes d’aide à la décision. Donc concernant la base de données du système de mesures de couple (application serveur Qualitorq et couplemètres TMV5), il faut trouver un juste milieu entre efficacité et utilité, car au final les résultats fournis par le PGI primeront pour les analyses complexes des données de contrôle qualité sur les couples. L’application serveur et la base de données sont réservées pour les mesures et les activités simples menées au quotidien sur les chaînes de production. L’accent est donc plutôt mis sur la facilité de communication entre l’application serveur et les différents couplemètres ainsi que sur la sécurité et l’intégrité des données stockées.

Pour conclure sur les PGI, il est important, pour le système de mesures de couple, de pouvoir exporter les données de sa base vers le PGI de l’entreprise. C’est une fonction qui n’est pour le moment pas implémentée mais qui pourra l’être en fonction des demandes des clients et des spécificités techniques.


53

3.5.2 Représentation du modèle de données avec UML

Le modèle conceptuel de la base de données est donné ci-dessous au travers d’un diagramme de classes.


54

Fig. 26 Diagramme de classes : modèle de données du système de mesures de couple

3.6 Gestion des utilisateurs

Pour qu’un opérateur puisse faire une session de mesures avec un couplemètre ou qu’un responsable qualité puisse saisir des données dans la base avec l’interface de paramétrage et de gestion des données de l’application serveur, tous doivent s’identifier et donc avoir un compte utilisateur existant dans la base de données.


SESSION

NuméroDateHeureUnitéCommentairebol_Clôturée

LIGNE

Nombol_ActiveCommentaire

COUPLEMETRE

IdentifiantAdr_IPCommentaire

FICHE_MESURES

NomDate_CréationHeure_Créationbol_Fiche_ActiveNbr_Mes_A_EffectuerDate_utilisation_DebHeure_utilisation_DebDate_utilisation_FinHeure_utilisation_FinCommentaire

MESURE

NumeroValeur_MesHeure_Mes

SEUILS

NomSeuil_1Seuil_2Seuil_3Seuil_4Nbr_SeuilsUnitéCommentaire

PRODUIT

Nombol_ActifCommentaire

LOT

Numérobol_ActifCommentaire

EVENEMENT

DateHeureTypeIP_ClientID_CouplemètreDescriptionNum_Session

UTILISATEUR

NomStatutMot_de_Passebol_Fiche_Mes_Autobol_ActifCommentaire

Effectue

0..*

0..*

0..*

0..*

1..*

1..*

1..*

1

1..*

1

1

1

1

1 1..*

1

Rattaché à

Est réalisé sur

Fait l’objet de

0..*

0..*

0..*

1

1

1

Rattaché à

Rattaché à

Rattaché à

55

3.6.1 Pourquoi mettre en place une gestion des utilisateurs

Quand une usine de production commande un logiciel, il est souvent demandé que ce dernier soit protégé par un mot de passe. Il faut savoir que beaucoup de personnes circulent sur les lignes de production (opérateurs salariés, opérateurs intérimaires, techniciens de l’usine et techniciens extérieurs, personnes qui circulent sur des lignes sans autorisation, …), il faut donc que les responsables qualité ou les responsables de production soient très vigilants à la probabilité que des personnes non formées ou non autorisées puissent saisir de fausses informations dans le système informatique, ce qui pourrait poser de gros soucis de fiabilité sur les informations. L’obligation de s’identifier et les possibilités d’action en fonction des droits de chacun des utilisateurs, réduit considérablement le risque de se retrouver avec ce genre de problème.Les responsables aiment aussi savoir qui a fait quoi, où et à quelle heure, car il arrive que certains opérateurs, pour éviter d’éventuelles manipulations dû aux résultats des mesures, faussent volontairement ces derniers.Pour toutes ces raisons, un système d’identification est mis en place avec possibilité de donner des droits aux utilisateurs enregistrés.

3.6.2 Gestion des droits utilisateurs

Chaque utilisateur est enregistré dans la base de données avec un nom d’utilisateur, un mot de passe et un statut. Le statut confère les droits sur les activités permises.

Trois types de statut sont ainsi définis :1. Administrateur2. Super Utilisateur3. Utilisateur

Administrateur :

Ce statut procure à l’utilisateur tous les droits : saisie de données dans la base, paramétrage de l’application serveur, création des comptes utilisateur, création des fiches de mesures, ...

Super Utilisateur :

Ce statut procure seulement le droit d’effectuer des sessions de mesures avec la possibilité de choisir tous les éléments composant une session (produit, lot, …) et donc la possibilité de créer de nouveaux numéro de lot. L’opérateur avec ce statut pourra aussi demander la liste des fiches mesures afin d’en sélectionner une pour paramétrer en une fois tous les éléments de la session de mesures.Utilisateur :

Ce statut procure uniquement le droit d’effectuer des sessions de mesures avec seulement la possibilité de demander la liste et de sélectionner une fiche mesures pour paramétrer les éléments composant la session. Ainsi par cette méthode, l’opérateur ne se trompera pas en choisissant chacun des éléments les uns après les autres puisque avec les fiches mesures ce


56

n’est pas nécessaire. Pour cela l’administrateur (le responsable qualité) devra préparer, au préalable, les fiches mesures afin que les informations soient prêtes et que l’opérateur n’ait plus qu’à effectuer ses mesures et clôturer la session.

Quand un utilisateur fait plusieurs tentatives de connexion infructueuses, au bout d’un certain nombre, le compte est désactivé jusqu’à ce qu’un administrateur le réactive.

Un système plus sécurisé, offrant notamment un plus large panel de profils utilisateurs aurait pu être développé. L’application serveur Qualitorq ne comprend en effet pour l’instant que trois profils mais dans le principe, il est assez facile de rajouter de nouveaux profils en fonction des besoins.

Par exemple en pharmaceutique, le cahier des charges 21 CFR Part 11, impose : un changement de mot de passe tous les 120 jours ; un mot de passe de 8 caractères minimum ; un mot de passe différent des 10 derniers choisis ; un blocage de compte après 5 tentatives infructueuses et un déblocage qui ne peut se faire que sur manipulation d’un administrateur ; il ne peut pas y avoir 2 comptes identiques ; lorsqu’un mot de passe est défini par un administrateur, le système doit forcer son changement immédiatement lors de la première connexion de l’opérateur ; le mot de passe doit être crypté et n’être visualisable par quiconque ; les changements de mots de passe doivent être enregistrés dans le journal des évènements nommé « Audit Trail ».

4 Fonctionnalité de l’application serveur Qualitorq

Dans une application informatique, qu’elle soit cliente ou serveur, il est très important de consacrer une partie du temps de développement à soigner la création d’une interface graphique (IHM). L’objectif est alors de rendre l’interaction avec les utilisateurs la plus ergonomique et la plus intuitive possible. L’application serveur, du système de mesures,


57

n’échappe pas à cette règle et est dotée d’un certain nombre de fenêtres dont chacune possède un rôle bien défini.

Je tiens à préciser que l’application serveur Qualitorq est séparée en deux applications bien distinctes. La première est l’application serveur, qui gère les connexions avec les couplemètres et les mesures, comprenant une fenêtre principale dans laquelle un tableau affiche les sessions de mesures en cours. La seconde est l’application servant à la gestion des données de la base et leur exploitation (lecture, écriture, suppression). Ces deux applications partagent évidemment la même base de données.

Fig. 27 Application serveur et application de gestion des données

Dans l’absolu, une seule application aurait pu s’envisager. Il semblait cependant plus judicieux de séparer le système en deux composants applicatifs afin de le rendre modulaire et plus à même d’évoluer. En effet, il vaut mieux laisser l’application serveur s’exécuter sans qu’un utilisateur n’intervienne sur celle-ci, étant donné que la probabilité de provoquer une erreur inattendue serait plus importante. Si vous avez une autre application pour la gestion des données et que celle-ci provoque une erreur inattendue, elle n’entraînera pas dans « sa chute » les autres applications. Il subsiste, malgré tout, une faible probabilité pour que le système d’exploitation et toutes les applications en cours se mettent en erreur, et se bloquent, suite à un problème sur une application en particulier. On peut se rendre compte que certaines applications serveur très connues (serveur Web, …), comprennent en général deux composants applicatifs : une application qui est le serveur, et une autre qui sert à l’administrer.

Une première section portera sur les interfaces graphiques de l’application serveur et une seconde section portera sur les interfaces graphiques de l’application de gestion des données. Dans les deux sections, j’illustrerai mes propos par des copies d’écran.

4.1 Interfaces graphiques de l’application serveur

L’application serveur en elle-même, est composée d’une fenêtre principale sur laquelle on peut démarrer et arrêter le serveur et visualiser les sessions de mesures en cours, et d’une fenêtre qui sert à configurer certains paramètres du serveur.


Base de données

ApplicationServeur

Application de gestion des

données

58

4.1.1 Fenêtre principale

Cette fenêtre principale de l’application serveur est composée de plusieurs éléments essentiels. Deux boutons donnent la possibilité de démarrer et d’arrêter la fonction serveur, c'est-à-dire on démarre ou on arrête la procédure d’écoute des connexions entrantes. De cette manière les connexions de couplemètres sont rendues possibles ou impossibles.Ensuite on a un tableau dans lequel sont affichées les sessions de mesures en cours. Chaque ligne du tableau correspond à une session, et pour chaque session toutes les données relatives à chacune sont affichées (identifiant du couplemètre, nom du produit, numéro de lot, ligne, opérateur, …) :

Fig. 28 Fenêtre principale de l’application serveur

Au dessus du tableau, un champ affiche le nombre de sessions de mesures en cours.

C’est utile de savoir, avant d’arrêter le serveur, le nombre de sessions de mesures en cours, quels opérateurs effectuent les sessions et combien de temps ils leur restent avant de clôturer la session.

4.1.2 Fenêtre de configuration

Cette fenêtre sert à configurer des paramètres comme le numéro de port de l’application serveur, les seuils d’alertes à partir desquels des informations concernant ces alertes sont enregistrés dans le journal des évènements et envoyés par email, les personnes à qui envoyer


59

ces emails, les paramètres pour l’envoi des emails et une option d’impression d’un rapport sur la session de mesures dès que celle-ci est clôturée :

Fig. 29 Fenêtre de configuration de l’application serveur

La possibilité de choisir un numéro de port, autre que celui défini par défaut par le développeur, est justifiée par la probabilité non négligeable d’avoir ce numéro déjà utilisé par une autre application sur le même PC.

4.2 Interfaces graphiques de l’application de gestion des données

L’application de gestion des données est composée de plusieurs fenêtres, chacune ayant son utilité pour gérer (créer, modifier, visualiser et supprimer) les données relatives à la mesure de couple se trouvant dans la base de données.


60

4.2.1 Gestion des données relatives à la mesure de couple

L’administrateur de l’application (ou le responsable qualité) a donc, à sa disposition, une fenêtre qui va lui servir à visualiser, enregistrer, modifier ou effacer toutes les données relatives et nécessaires à la création d’une session de mesures. Ces données sont par exemple : les noms de produit, le numéro de lot, les lignes, les comptes utilisateur, les fiches mesures, …

Fig. 30 Fenêtre de gestion des données

Cette fenêtre est importante et sera très souvent utilisé par les responsables qualité. Toutes les données importantes et relatives aux sessions de mesures sont gérées dans cette fenêtre. J’ai donné la possibilité de désactiver des produits, des numéros de lot, des lignes, des utilisateurs et des fiches mesures. De cette manière, quand par exemple la liste des produits est demandée par un opérateur via son couplemètre et qu’elle est donc envoyée par l’application serveur, celle-ci est composée uniquement des produits utiles, puisque ceux inutiles ou obsolètes auront été désactivés. Cela fait gagner du temps au serveur (moins de données à envoyer) et il y a moins de données à traiter et à afficher, sur l’écran du couplemètre. On va à l’essentiel. Il en est de même pour les autres éléments qui peuvent eux aussi être désactivés.La désactivation des utilisateurs est utile pour empêcher quelqu’un de se connecter. L’utilisateur pourra aussi être désactivé, automatiquement, s’il fait trop de tentatives de connexion avec un mauvais mot de passe. Pour qu’il puisse faire ses mesures, il faudra qu’un responsable lui réactive son compte.


61

4.2.2 Préparation d’une session de mesures avec une « Fiche mesures »

Dans certains paragraphes de ce mémoire, j’ai parlé de la possibilité donnée aux responsables qualité de créer des fiches mesures. Une fiche mesures rassemble tous les éléments qu’un opérateur doit choisir pour créer une session de mesures, lui évitant ainsi de sélectionner un à un les tous ces éléments. Le but de ces fiches et de faire en sorte que l’opérateur, au moment d’effectuer une session de mesures, ait un minimum de manipulations à faire et qu’il ait juste à s’occuper des mesures de couple.Le responsable peut aussi faire en sorte que la bonne fiche soit automatiquement paramétrée en fonction de l’heure et de la date du jour (Session Auto), et donc de cette manière, l’opérateur n’a même plus besoin de choisir une fiche mesures parmi d’autres, cela réduisant encore plus les manipulations.

Pour la création de fiches mesures, un onglet spécifique de la fenêtre de gestion des données sert au responsable qualité à lier les différents éléments d’une session (produit, lot, …) à la fiche mesures. Il devra aussi lui donner un nom unique pour pouvoir la retrouver. Une fois les fiches mesures créées, il les rattache aux opérateurs.

Fig. 31 Fenêtre de création des fiches mesures

Une même fiche peut-être rattachée à plusieurs opérateurs et inversement.

4.2.3 Visualisation des sessions de mesures clôturées

Une fenêtre sert à visualiser toutes les sessions de mesures qui ont été effectuées et clôturées. Toutes les informations sont visibles pour chaque session (produit, lot, …) ainsi que toutes les valeurs de couple mesurées durant la session. Les statistiques (min, max, moyenne, écart type,


62

…) sont calculées (il n’y a pas de donnée calculée enregistrée dans la base de données). On peut aussi visualiser trois graphiques : le premier représente la courbe des mesures de couple avec en abscisse le numéro de la mesure et en ordonnée la valeur du couple mesurée, le second représente la courbe de Gauss et sur le troisième est dessiné un camembert qui représente les pourcentages des mesures de couple considérées comme bonne, faible, forte, très faible et très forte dans le cas où les mesures sont comparées à quatre seuils (ou bornes), ou alors bonne, faible et forte dans le cas où elles sont comparées à deux seuils.Cette fenêtre propose aussi d’imprimer des rapports (état) sur une session de mesures. Ce rapport rassemble aussi toutes les données et les graphiques de la session.

Fig. 32 Fenêtre de visualisation des sessions de mesures

4.2.4 Recherche de sessions sur critères et calculs statistiques

Une fenêtre offre la possibilité de faire des recherches de sessions de mesures clôturées, en fonction de critères de sélection. Ces critères sont la date (recherche entre deux dates), le nom du produit, le numéro de lot et le nom ou numéro de la ligne.Quand une recherche est lancée et que les sessions trouvées s’affichent à l’écran dans le tableau prévu à cet effet, des statistiques sont calculées sur l’ensemble des sessions de mesures. Ces statistiques sont les mesures minimum et maximum, la moyenne, l’écart type et le pourcentage qualité de bonne valeur (c'est-à-dire celles comprises entre une borne mini et une borne maxi). L’utilisateur a la possibilité d’exclure des calculs toutes les sessions de mesures qu’il veut, dans le cas par exemple où il estime que certaines sessions faussent les calculs statistiques. A l’instar de la fenêtre de visualisation des sessions de mesures, on peut aussi visualiser trois graphiques : le premier représente la courbes des moyennes avec en


63

abscisse les numéro de session trouvées et en ordonnée la moyenne des valeurs de couple mesurées pour chaque session, le second graphique représente une courbe de Gauss et le troisième un camembert représentant les pourcentages des valeurs de couple (bonne, faible, …) sur le même principe que dans la fenêtre de visualisation des sessions.L’utilisateur a la possibilité d’imprimer un rapport (état) dans lequel sont repris les résultats de la recherche avec calculs statistiques et graphiques.

Fig. 33 Fenêtre de recherche et d’analyse des sessions de mesures

Cette fenêtre est très utile pour observer, sur le long terme, les variations et les dérives des valeurs mesurées. C’est un outil de contrôle et de statistique que les responsables qualité apprécient beaucoup. Dans leur travail de tous les jours, il leur est très important d’avoir des indicateurs afin de savoir où et à quel moment agir en cas de futurs problèmes ou de non-conformité. Ou alors tout simplement des petits détails à rectifier pour ne pas dériver complètement dans l’erreur.Toutes ces informations, relatives aux mesures de couple, qui sont enregistrées dans la base de données, offre aux responsables qualité, une traçabilité sur ces données au fil du temps.

4.2.5 Visualisation des évènements

Quand l’application serveur est en cours d’exécution, elle enregistre dans une des tables de la base de données, prévue à cet effet, certains évènements. Les évènements sont partagés en quatre catégories :


64

1. Information2. Alerte3. Sécurité 4. Erreur

Information :

Les exemples d’évènements que l’on peut trouver dans cette catégorie sont : heure et date de démarrage et d’arrêt du serveur, impression d’un rapport, export des données, sauvegarde de la base de données (Backup), modifications des paramètres de l’application serveur et éventuellement certaines modifications dans la base de données.

Alerte :

Les évènements de cette catégorie apparaissent en fonction de ce qui a été paramétré sur l’application serveur par le responsable qualité. Par exemple, il peut paramétrer l’application serveur pour que selon les résultats des calculs statistiques, au moment de la clôture de la session, elle génère un évènement si un premier seuil d’alerte est dépassé (ce seuil peut-être, par exemple, une valeur de pourcentage qualité ou un écart type). Il existe un second seuil d’alerte, plus « grave », pour ces mêmes valeurs, qui lui, génère l’envoie d’un mail sur une adresse email paramétrable en cas de dépassement (dans une amélioration de l’application serveur, l’on peut imaginer la possibilité d’informer certaines personnes par le biais de SMS (message texte sur téléphone) ou d’appel téléphonique avec message vocal construit dynamiquement en fonction du message à faire passer).

Sécurité :

Les exemples d’évènements que l’on peut trouver dans cette catégorie sont : les tentatives de connexion avec un mauvais mot de passe ou bien une déconnexion du client exécuté par l’application serveur dans le cas où elle reçoit un trop grand nombre de mauvaises commandes ou de commandes inconnues.

Erreur :

Les exemples d’évènements que l’on peut trouver dans cette catégorie sont : l’impossibilité de créer un numéro de lot, le refus d’une valeur non plausible, l’impossibilité au serveur d’envoyer un email d’alerte car l’adresse du destinataire n’a pas été sélectionnée ou incorrecte, l’impossibilité de créer le numéro de session ou encore l’arrêt brutal d’une session sans avoir été clôturée.

La fenêtre suivante, sert à visualiser tous ces évènements. L’utilisateur a la possibilité de filtrer les évènements affichés en fonction des catégories (information, alerte, sécurité et erreur) :


65

Fig. 34 Fenêtre d’affichage des évènements

Chaque catégorie est représentée par un icône, ainsi l’utilisateur, en regardant l’icône, voit immédiatement avant de lire quoi que ce soit, à quelle catégorie appartient l’évènement.L’observateur proposé ici s’inspire de l’observateur d’évènements de Windows.

La gestion des évènements est très importante dans une application serveur. En effet, sur une application classique ou cliente, l’utilisateur échange des informations avec celle-ci et, en règle générale, si un problème ou un évènement particulier survient, l’utilisateur est tout de suite informé, avec par exemple l’apparition d’une fenêtre d’information ou d’erreur (boite de dialogue).En revanche, une application serveur qui s’exécute est autonome. En dehors d’être paramétrée quand il le faut, aucun utilisateur n’a besoin d’être devant pour qu’elle s’exécute correctement. Par contre, pendant son exécution, il peut se passer une multitude d’évènements, plus ou moins importants, qui justifient l’emploi d’un journal dans lequel seront stockés tous ces évènements, et qui servira à tenir informé les personnes concernées par l’application serveur.

4.2.6 Visualisation des sessions en cours

Il existe trois possibilités pour visualiser les sessions de mesures en cours. La première est d’utiliser la fenêtre principale de l’application serveur, sur laquelle se trouve un tableau contenant toutes les sessions en cours. La seconde possibilité est d’ouvrir la fenêtre de visualisation des évènements car une option propose l’affichage d’un tableau contenant les sessions en cours.Et la dernière possibilité consiste à utiliser n’importe quel navigateur Internet du marché (IE, FireFox, …) pour afficher, après une requête, dans une page HTML (HyperText Markup Language), un tableau dynamique contenant les sessions en cours. En effet, en plus de comprendre le protocole pour la couche application crée pour cette application, le serveur est aussi capable de répondre à une requête du protocole HTTP (HyperText Transfert Protocol) envoyé par un navigateur Internet.


66

Les possibilités d’accès sont différentes, mais le principe de visualisation des sessions de mesures et toujours le même, à savoir un tableau.

Visualisation des sessions en cours dans la fenêtre de visualisation des évènements

Dans cette fenêtre, on a donc un tableau dans lequel chaque ligne correspond à une session en cours. Toutes les données relatives à la session en cours sont présentes : opérateur qui réalise la session, l’identifiant du couplemètre, le nom du produit, le numero de lot, les calculs statistique, … L’utilisateur peut rafraîchir les données de ce tableau quand il le désire (cette partie n’est pas encore implémentée, mais on peut imaginer que le rafraîchissement soit réalisé périodiquement par un « Timer »).

Explication du principe de fonctionnement :quand l’utilisateur ouvre cette fenêtre ou qu’il appuie sur le bouton « Rafraîchir », une connexion est automatiquement créée avec l’application serveur Qualitorq avec l’envoi d’une requête de connexion : LOG ; [Nom utilisateur] ; [Mot de passe] ; ; <CR><LF>La fenêtre en cours connaît déjà le mot de passe et le nom de l’utilisateur puisque ce dernier les a déjà données au moment de s’identifier pour lancer l’application de gestion des données. Si dans la trame on a deux points virgules « ; » qui se suive c’est parce qu’on ignore le champ dans lequel est censé se trouver l’identifiant du couplemètre (inutile dans ce cas là).Une fois que la connexion a été acceptée par l’application serveur, la requête suivante lui est envoyée :INFO ; ETAT_SESSIONS ; <CR><LF>A la réception de cette requête, l’application serveur envoie, en réponse, la liste des sessions de mesures en cours avec toutes les données relatives pour chacune des sessions, ou alors s’il n’y a aucune session en cours, elle envoie une réponse le précisant.

Fig. 35 Fenêtre de visualisation des sessions de mesures en coursLa possibilité de visualiser les sessions de mesures en cours, peut potentiellement intéresser un responsable pour savoir, à un instant donné, qui fait quoi, où et sur quel produit. Le fait de pouvoir visualiser les sessions en cours à partir de l’application de gestion des données est


67

plus confortable pour le responsable qui s’évite ainsi de devoir aller consulter, sur le PC serveur, la fenêtre principale de l’application serveur. A savoir que le PC serveur n’est pas forcément dans le bureau des responsables qualité, et bien souvent il se trouve dans une salle informatique avec d’autres serveurs et y accéder n’est pas toujours aisé (clé, autorisation, digicode, …).

Visualisation des sessions en cours à partir d’un navigateur Internet

A partir d’un navigateur Internet, il est possible d’afficher une page HTML contenant un tableau créé dynamiquement en fonction des sessions en cours.Pour cela il suffit de taper dans la barre d’adresse ou URL (Uniform Resource Locator), l’adresse suivante :http://192.168.0.2:5010Il est possible, avec le paramétrage adéquat, de remplacer l’adresse IP par un nom plus parlant, comme on le fait, sur Internet, avec les adresses IP qui sont remplacées par les noms de domaine.

L’adresse IP correspond à l’adresse du PC serveur sur lequel s’exécute l’application serveur. « :5010 » force le navigateur à faire une demande de connexion sur le port n° 5010 (port d’écoute du serveur), car les navigateurs font leurs demandes de connexion sur le port n° 80 par défaut.Une fois que l’application serveur accepte et ouvre la connexion demandée par le navigateur, celle-ci reçoit la première requête suivante :GET / HTTP/1.1Ensuite l’application serveur renvoie une page HTML, créée dynamiquement, qui contient une demande d’identification, c'est-à-dire avec un champ nom utilisateur, un champ mot de passe et un bouton OK (formulaire HTML) :

Fig. 36 Identification à partir d’une page HTML

Une fois les identifiants saisis et validés avec le bouton OK, l’application serveur reçoit la requête suivante :GET /?nom=Fred&pass=passapplic HTTP/1.1


68

Avec cette requête, l’application serveur reçoit les identifiants de l’utilisateur et va les contrôler pour savoir s’il peut lui envoyer la liste des sessions en cours. La méthode « GET » utilisée ici n’est pas idéale pour la sécurité informatique puisque le nom de l’utilisateur et le mot de passe apparaissent en clair dans la barre d’adresse et dans les trames circulant sur le réseau. La méthode « POST » serait plus adaptée car elle résout ce problème. Pour le moment, c’est la méthode GET qui est cependant utilisée.Après identification, l’application serveur envoie une page HTML dans laquelle un tableau, créé dynamiquement, contient les sessions en cours, sur le même modèle que celui présent dans sa fenêtre principale.

Fig. 37 Visualisation des sessions de mesures en cours à partir d’une page HTML

Cette possibilité de contrôle des sessions de mesures en cours via un navigateur Internet, peut intéresser les responsables qualité qui peuvent, à n’importe quel endroit de l’entreprise ou de l’usine où il y a un PC connecté au réseau, contrôler qui fait quoi, où et sur quel produit.

Cette solution donnant la possibilité d’être informé via un navigateur, qui équipe, par défaut, n’importe quel PC de nos jours, demande à être creusée pour offrir plus de fonctionnalités. Si je ne l’ai pas fait, c’est qu’à un moment donné il devient plus judicieux de trouver d’autres solutions que celle que j’ai choisi sur l’application serveur à l’heure d’aujourd’hui. En effet, cette dernière est composée de diverses procédures qui servent à comprendre et traiter les requêtes HTTP pour ensuite créer dynamiquement des pages HTML contenant les informations demandées. Si je devais implémenter d’autres fonctions pour offrir plus de fonctionnalités aux utilisateurs, il me faudrait passer beaucoup de temps à les développer, alors que, par exemple, en créant un site Internet (en PHP ou autres), utilisé avec un serveur Web (Apache ou autres), qui irait piocher toutes les informations demandées et nécessaires dans la base de données de l’application serveur selon la requête reçue, prendrait


69

probablement beaucoup moins de temps à mettre en place et serait ouvert à toute évolution par la suite. Si on suit une logique économique, pourquoi passer des heures à créer des procédures, alors que des solutions moins coûteuses en temps et donc en argent existent déjà ?La mise en place de ces nouvelles méthodes ne rentrant pas dans le cadre de ce projet pour le moment, je ne m’étendrai donc pas plus sur le sujet.

5 Test de l’application serveur Qualitorq


70

Les tests, tout au long du développement de l’application serveur, ont été des phases très importantes, et pour cela j’ai utilisé plusieurs méthodes et outils de test.

Tester une application serveur est plus contraignant qu’une application cliente. Une application serveur fonctionne en autonome et est capable de gérer plusieurs connexions en parallèle et donc plusieurs traitements de procédure. Il faut donc prévoir cela en simulant plusieurs connexions en parallèle, soit avec l’aide de plusieurs personnes pour effectuer les tests, mais on a jamais un nombre de personnes suffisant sous la main pour effectuer les tests, soit en créant une application offrant la possibilité de simuler un certains nombre de connexions en parallèle où chacune a la capacité de réaliser des actions comme pourrait le faire un humain, c’est donc cette dernière option que j’ai choisie pour mes tests.

Une première section parlera des outils utilisés pour les tests de l’application serveur et dans une seconde section je donnerai plus de détails sur ces outils.

5.1 Comment et avec quoi tester

Pour tester l’application serveur Qualitorq tout au long de son développement, j’ai utilisé trois applications différentes, la première est disponible avec Windows alors que les deux autres ont été créées spécifiquement pour approfondir les tests.

Les premières phases de test ont été lancées au moment de la création de la partie socket, c'est-à-dire à l’ouverture d’une socket d’écoute sur le serveur, et à l’acceptation des connexions entrantes avec création de threads pour traiter ces connexions, et traitement des requêtes de connexion. Pour ces premiers tests j’ai commencé par utiliser « Telnet » et ensuite surtout « Hyper terminal ». Ces deux applications sont disponibles avec n’importe quelle version de Windows. Elles offrent la possibilité d’ouvrir une socket client en indiquant l’adresse IP et le numéro de port du serveur. Rien que d’ouvrir ou de fermer une connexion, sert déjà à savoir si la socket d’écoute sur le serveur accepte bien les connexions entrantes et que les threads de traitement de chaque connexion s’exécute bien.Une fois que cette partie importante de l’application serveur fut fonctionnelle et donc exempte de tout bogue, la partie traitement des requêtes (traitement des trames et envoie des réponses) fut elle aussi à tester, mais à partir de là, il était trop fastidieux de continuer à utiliser Hyper terminal, car à chaque test il fallait taper les requêtes au clavier et vu le nombre important de fois ou il faut tester la communication cela devenait une importante perte de temps. C’est donc pour cela que j’ai commencé à développer une première application de test, avec tout un jeu de requêtes préenregistrées, afin de réduire au maximum les temps de saisie des requêtes et donc l’apport d’un gain de temps pour les tests de l’application serveur non négligeable.

5.2 Détails sur les deux applications de test

Pour la suite des tests de l’application serveur, et comme Hyper terminal ne suffisait plus, j’ai développé deux autres applications de test ayant chacune des fonctions bien précises. La première application est une application qui simule un couplemètre TMV5 (la même interface est retrouvée). La seconde application n’est qu’une interface minimaliste et sert à simuler de un à plusieurs couplemètre TMV5 et ainsi tester la robustesse de l’application serveur face à une multitude de connexions simultanées (montées en charge).


71

5.2.1 Couplemètre TMV5 virtuel

Cette application, en plus de servir à tester l’application serveur, permet aussi de faire des démonstrations, de la même manière qu’on pourrait le faire avec un couplemètre TMV5, et peut aussi servir à la personne qui sera en charge de développer la brique logicielle à embarquer dans le TMV5 pour la construction de l’IHM. J’ai donc développé cette application pour qu’elle ressemble le plus possible à un TMV5, et pour illustrer mes propos, voici quelques copies d’écran :

Fig. 38 TMV5 virtuel

Dans la création de l’interface, j’ai pris en compte les propriétés tactiles de l’écran du TMV5, et de ce fait, les interactions possibles, entre l’écran du TMV5 et la main de l’opérateur, sont reprises dans cette simulation (le curseur de la souris est une main avec un doigt qui pointe).Quand on démarre ce TMV5 « virtuel », son écran propose, en un clic, une connexion avec l’application serveur, avec saisie du nom d’utilisateur et du mot de passe :


72

Fig. 39 Interface TMV5 : Identification

Une fois la connexion établie, on a la possibilité de commencer une nouvelle session de mesures ou de reprendre une session non clôturée. Si on choisit d’effectuer une nouvelle session, on verra apparaître à l’écran tous les éléments qui composent une session de mesures. A partir de là vient la phase du choix de chaque élément (produit, numéro de lot, ligne, …), il suffit de cliquer sur n’importe quel élément pour qu’automatiquement l’application envoie une requête au serveur demandant l’obtention de la liste de l’élément sur lequel on a cliqué, l’application serveur répond avec une liste et chacun des éléments de cette liste est affiché dans un tableau à l’écran du couplemètre :

Fig. 40 Interface TMV5 : Liste des produits

Il ne reste plus qu’à cliquer sur la ligne qui nous intéresse pour sélectionner l’élément qui sera attaché à la session. Pour tous les autres éléments, on procèdera de la même manière. Pour éviter d’avoir à choisir chaque élément un à un, on peut aussi demander la liste des fiches mesures :


73

Fig. 41 Interface TMV5 : Liste des fiches mesures

Une fois tous les éléments choisis, il suffira de cliquer sur le bouton « START » pour qu’une requête soit envoyée à l’application serveur afin que celle-ci crée le numéro de session et qu’elle se tienne prête à recevoir les mesures. Pour ces dernières, un bouton sert à simuler des valeurs de couple. A chaque mesure simulée, il faut appuyer sur « VALIDER » pour que chacune soit envoyée à l’application serveur. A chaque mesure envoyée, on affiche les calculs statistiques mis à jour et le numéro de la mesure. Une fois que le nombre de mesures à effectuer a été atteint, un message sonore retentira. Pour clôturer la session de mesures, il suffira de cliquer sur le bouton « STOP ».

Grâce à cette application et par simple clic de souris, je peux simuler l’envoi de n’importe quelle requête à l’application serveur, ce qui m’évite à chaque fois de devoir tout taper au clavier (comme avec Hyper terminal ou Telnet), surtout quand il faut tester certaines requêtes qui demandent, au préalable, d’en avoir envoyé d’autres avant.

Dans certains cas, comme par exemple la saisie des nouveaux numéros de lot directement à l’écran, le TMV5 est capable d’afficher un clavier virtuel :

Fig. 42 Interface TMV5 : clavier virtuel 5.2.2 Application pour simuler des montées en charge

Cette application sert à tester la robustesse et les erreurs éventuelles du serveur avec la possibilité de simuler une multitude de couplemètres simultanément. Quand un couplemètre


74

simulé est lancé, il effectue automatiquement : une connexion sur le serveur, une session de mesures qu’il clôture et une déconnexion. On peut paramétrer : le nombre de couplemètres à simuler simultanément ; le temps entre deux lancements de simulation (entre 10ms et 1sec) ; si les éléments de la session sont paramétrés avec une fiche mesures ou si chaque élément doit être paramétré les un après les autres. L’on peut arrêter brutalement une simulation en particulier ou toutes d’un coup pour tester comment réagit le serveur en cas de déconnexion brutale d’un client.

Fig. 43 Fenêtre principale de l’application de test pour l’application serveur

Quand un couplemètre simulé effectue une session avec paramétrage des éléments de celle-ci par une fiche mesures, il demande à l’application serveur l’obtention de la liste de ces fiches et une fois cette liste reçue, il va sélectionner une fiche au hasard pour ensuite effectuer la session.Quand un couplemètre simulé effectue une session avec paramétrage des éléments un à un, il va demander à l’application serveur la liste de chaque éléments (produit, lot, …) et à chaque réception des listes, il choisira un élément au hasard.Ces choix de fiches ou d’éléments au hasard, servent à avoir une multitude de sessions utilisant des éléments parfois identiques mais aussi et surtout des éléments différents, et de cette façon on essaye de solliciter le plus possible la base de données. Le but est aussi d’essayer de voir à quel moment, en fonction du nombre de simulations simultanées, le serveur n’arrive plus à répondre dans un laps de temps relativement correct.

Un tableau dans la fenêtre de cette application de test affiche tout ce qui se passe durant tout le temps de la connexion pour chaque couplemètre simulé, de cette manière je peux savoir, si jamais une simulation échoue, à quel endroit du code des procédures de l’application serveur la mise en échec a eu lieu.

Pour simuler des couplemètres, j’utilise ici aussi des threads. Chaque couplemètre simulé est traité dans un thread. Quand la simulation a lieu avec cette application de test, je contrôle aussi avec beaucoup d’attention le « gestionnaire des tâches » Windows et le pourcentage de l’utilisation de l’UC (Unité Centrale). Cette indication me sert à voir jusqu’à combien de couplemètres je peux avoir en simultané en ayant un pourcentage d’utilisation de l’UC raisonnable. Je contrôle


75

aussi l’utilisation de la mémoire vive. C’est important car on peut arriver, à peu près, à savoir si les threads se terminent correctement ou non, et donc s’ils libèrent correctement la mémoire. Ainsi le reste de mémoire disponible, que l’on peut observer dans le gestionnaire des tâches, ne diminue pas à vue d’œil sans arrêt. Si le code de l’application serveur comporte des erreurs de conception, comme par exemple une mauvaise libération des ressources quand les threads sont arrêtés ou une mauvais gestion des threads qui fait qu’ils restent en mémoire, quand on lance un test avec des centaines de sessions de mesures qui sont exécutées pendant plusieurs minutes, la mémoire vive disponible diminue à vue d’œil.Pour donner un exemple, avec ce contrôle du gestionnaire des tâches, pendant mes tests, je me suis rendu compte que même avec peu de couplemètres simulés en simultanés, j’avais un pourcentage d’utilisation de l’UC beaucoup trop important. Il a fallu que je cherche un moment pour me rendre compte que ça ne venait pas d’un problème de conception du code pour la partie sockets et threads, mais tout simplement de l’utilisation d’une ligne de code (dans un évènement d’affichage d’une ligne, dans le tableau affichant les sessions en cours sur la fenêtre principale de l’application serveur) qui servait à changer de couleur la police des caractères affichés.

Durant les tests, j’ai aussi utilisé la console de Windows « cmd.exe » afin d’utiliser la commande « Netstat » et ainsi contrôler l’ouverture et la fermeture des ports réseaux TCP.

Conclusion

Depuis ces dernières années, la mondialisation a forcé bon nombre d’entreprises à devenir compétitives, et à se lancer dans une course où le vainqueur est récompensé par une meilleure image de marque, plus de prestige, mais surtout, le nerf de la guerre, un chiffre d’affaires plus important que ses concurrents. Cependant, pour réussir dans cette compétition mondiale, il


76

s’agit, sans cesse, de se donner les moyens d’être le ou parmi les meilleurs en optimisant le travail et la production, dans une optique de réduction des coûts, et en poussant les salariés à eux aussi devenir compétitifs et ingénieux pour leur entreprise. Le culte du résultat quantitatif comme qualitatif est au centre des pratiques des entreprises et des industries. Grand nombre d’entreprises disposent aujourd’hui d’un ou plusieurs services dans lesquels la recherche qualité est poussée à son paroxysme. Pour que ces services, composés de chercheurs, d’ingénieurs et de techniciens, puissent obtenir une qualité optimum des produits fabriqués, ils font usage d’une pléthore d’outils qui serviront cette cause devenue universelle.La nécessité de fournir de bons outils, d’aide aux contrôles qualité, aux industries, est devenue la spécialité de certaines entreprises qui conçoivent et fabriquent ces outils. Les entreprises concernées par ce projet ont cette spécialité avec, dans l’optique, le défi continuel d’offrir des outils au plus près des besoins des industries et de leurs qualiticiens.

Pendant toutes les phases de travail de ce projet de création de l’application serveur, qui est au cœur du système de mesures du couple pour le contrôle qualité, une position d’ouverture et d’écoute a été adoptée, dans le sens où cet outil devait pouvoir offrir un maximum de services aux qualiticiens, le plus simplement possible avec des perspectives d’évolutivités. Un écueil concerne tout particulièrement la partie logicielle embarquée dans les couplemètres, sous la responsabilité de l’électronicien qui devra respecter les spécifications de « Qualitorq Serveur » afin de rendre optimum les échanges d’information entre le serveur et les couplemètres.

D’un point de vue personnel, le développement d’applications serveur est un travail qui m’intéresse fortement et j’ai pris un grand plaisir à travailler sur ce projet. Le développement de ce type d’application fait appel à des connaissances diverses et variées comme la connaissance des réseaux, des protocoles de communication, de la programmation pour la communication via les réseaux, des bases de données, de la gestion des utilisateurs et de la création des interfaces graphique, pilier de la communication entre l’humain et la machine. Ce type de projet demande un fort esprit d’équipe et de communication. Il aurait aussi très bien pu être scindé en trois parties, la partie développement du serveur, la partie gestion des données et la partie tests. L’application est aujourd’hui opérationnelle et permet de faire des démonstrations sur son fonctionnement et ses capacités. Chaque nouveau client, s’il le désire, pourra y apporter son lot de modifications et d’adaptations afin qu’elle soit encore plus proche de ses besoins.

Les aspects financiers de ce projet, sont difficilement chiffrables, ce travail a en effet été réalisé dans le cadre d’une optique « développement d’un produit nouveau », qui fait jour à des difficultés non rencontrées lors de développements associés par exemple à des révisions et des changements de version lors du cycle de vie d’une application.Du temps personnel a été également consacré à ce travail puisqu’il s’agissait d’en faire le sujet de mon mémoire CNAM. Le coût de revient d’un tel projet, pour une entreprise, est relatif à ce que lui coûte son personnel impliqué et peut varier en fonction de la politique salariale, de la capacité d’un ingénieur ou d’un technicien à trouver une solution ou à réaliser une tâche dans un laps de temps plus ou moins court, de la concurrence (qui fait qu’elle devra revoir sa politique de tarif de vente) et de son image de marque (une entreprise avec une bonne image de marque pourra vendre ses produits plus chers que ses concurrents offrant pourtant la même qualité de prestation). La disparité salariale des ingénieurs et techniciens supérieurs en informatique, selon les entreprises, est parfois importante et pour une même


77

étude les coûts pourront varier du simple au double. Pour toutes ces raisons, ce mémoire ne comprend pas d’estimatif des coûts engendrés par le projet.

Pour donner quelques perspectives d’avenir pour ce système de mesures et de contrôle de couple, je dirais qu’aujourd’hui, une partie du fonctionnement est automatisée, ce système fait toutefois encore appel à l’intervention humaine (prélèvement des échantillons sur ligne de production, placement de l’échantillon dans l’étau de maintien de la bouteille du couplemètre, dévissage manuel et validation de la mesure), et les valeurs de couple mesurées ont tendance à être parfois faussées en fonction des manipulations de l’opérateur chargé des mesures (force et vitesse de dévissage, position de la main de l’opérateur qui dévisse, serrage du fond de la bouteille dans l’étau, …). Il est imaginable pour le futur, de construire un système qui serait capable de prélever automatiquement les échantillons sur ligne, de faire les mesures sans aucune intervention humaine, notamment en intégrant un couplemètre automatique directement sur la ligne de production.

Au point de vue personnel ce projet m’a beaucoup apporté, même si dans le cadre de mes fonctions de gérant, j’ai l’habitude de gérer des projets et les relations avec les clients et les entreprises avec lesquelles je travaille.La perspective d’exploiter ce travail afin de soutenir mon mémoire d’ingénieur en informatique au CNAM, l’a rendu encore plus motivant.

Table des illustrations

Fig. 1 Couplemètre TMV4 8Fig. 2 Couplemètre TMV4 et logiciel Qualitorq : installation monoposte 11


78

Fig. 3 Couplemètre TMV4 et logiciel Qualitorq : installation multipostes 12Fig. 4 Hiérarchie partielle des acteurs 13Fig. 5 Diagramme de contexte statique 14Fig. 6 Cas d’utilisation : Conception – Fabrication 15Fig. 7 Exemples de bouchons 16Fig. 8 Cas d’utilisation : Vérification et mise en production chez l’acteur industriel 16Fig. 9 Bouchon et bague d’inviolabilité 17Fig. 10 « Sur-vissage » 17Fig. 11 Packaging Cosmétique 18Fig. 12 Couplemètre TMV5 20Fig. 13 Architecture du système de mesures avec application serveur et couplemètres TMV5 21Fig. 14 Processus et Threads 30Fig. 15 Code de la procédure d’écoute et d’acceptation des connexions entrantes 31Fig. 16 Diagramme d’activité : Création du N° de Session 34Fig. 17 Tableau des sessions en cours sur la fenêtre principale de l’application serveur 35Fig. 18 Diagramme d’activité : Réception des mesures 38Fig. 19 Modèle en couches des protocoles 40Fig. 20 Diagramme de séquences : connexion 49Fig. 21 Diagramme de séquences : demande de la liste des fiches en mode Session Auto 49Fig. 22 Diagramme de séquences : demande de la liste des fiches en mode Session non auto 49Fig. 23 Diagramme de séquences : Choix des différents éléments d’une session de mesures 50Fig. 24 Diagramme de séquences : Reprendre une session de mesures pour la clôturer 51Fig. 25 Diagramme de séquences : Envoi des mesures à l’application serveur 51Fig. 26 Diagramme de classes : modèle de données du système de mesures de couple 54Fig. 27 Application serveur et application de gestion des données 57Fig. 28 Fenêtre principale de l’application serveur 58Fig. 29 Fenêtre de configuration de l’application serveur 59Fig. 30 Fenêtre de gestion des données 60Fig. 31 Fenêtre de création des fiches mesures 61Fig. 32 Fenêtre de visualisation des sessions de mesures 62Fig. 33 Fenêtre de recherche et d’analyse des sessions de mesures 63Fig. 34 Fenêtre d’affichage des évènements 65Fig. 35 Fenêtre de visualisation des sessions de mesures en cours 66Fig. 36 Identification à partir d’une page HTML 67Fig. 37 Visualisation des sessions de mesures en cours à partir d’une page HTML 68Fig. 38 TMV5 virtuel 71Fig. 39 Interface TMV5 : Identification 72Fig. 40 Interface TMV5 : Liste des produits 72Fig. 41 Interface TMV5 : Liste des fiches mesures 73Fig. 42 Interface TMV5 : clavier virtuel 73Fig. 43 Fenêtre principale de l’application de test pour l’application serveur 74

Bibliographie

Documents techniques


79

SUN, Programmation Système UNIX, SI-220 RevG.1 (janvier 1999), Solaris 2.x

Programmation Système avec Windows 2000 et XP, Rev décembre 2001, Barbara Le Jan & Régis Lécu

METTLER TOLEDO, Standard Interface Command Set, MT-SICS 3 RemoteR V1.0xMETTLER TOLEDO, “FreeWeigh” Operating Instructions, V6.1

RFC, Post Office Protocole – Version 3RFC, HyperText Transfert protocol – http/1.0RFC, File Transfert ProtocolRFC, Simple Mail Transfert Protocol

Ouvrage

Guy Pujolle, Les Réseaux, Eyrolles, édition 2003 (ISBN : 2-212-11086-3)

Pierre-Alain Muller et Nathalie Gaertner, Modélisation objet avec UML, Eyrolles, édition 2000 (ISBN10 : 2-212-09122-2)

Sites Internet

http://www.iprelax.fr/ (documents sur les protocoles Internet : HTTP, SMTP, POP, …)

http://fr.wikipedia.org/wiki/Accueil (L’encyclopédie libre)

http://abcdrfc.free.fr/ (toutes les RFC traduites en Français)

Glossaire


80

http://abcdrfc.free.fr/

http://fr.wikipedia.org/wiki/Accueil

http://www.iprelax.fr/

Chipset : (littéralement ensemble de puces) est un jeu de composants électroniques intégré dans un circuit intégré préprogrammé.

Chipset socket : circuit intégré servant à gérer la partie physique du réseau et les différentes couches réseaux utilisées (TCP/IP).

CR : Carriage Return en anglais ou retour chariot en français, correspond au caractère 13 du code ASCII.

ERP : Enterprise Resources Planning. Voir PGI.

Fiche mesures : fiche contenant tous les éléments (nom produit, numéro de lot du produit, ligne sur laquelle les échantillons du produit concernés ont été prélevés) qu’il faut rattacher à une session de mesures.

HTML : HyperText Markup Language. Format de document du Web, défini par la RFC 1866.

HTTP : HyperText Transfer Protocol. Protocole de transmission dédié aux clients et au serveur du Web.

IHM : Interface Homme-Machine. En général, on désigne par ce terme les interfaces graphiques, mais une simple ligne de commande en fait aussi partie.

LF : Line Feed en anglais ou saut de ligne en français, correspond au caractère 10 du code ASCII.

PGI : Un Progiciel de Gestion Intégré (en anglais Enterprise Resource Planning ou ERP) est, selon le grand dictionnaire terminologique, un logiciel qui permet de gérer l’ensemble des processus d’une entreprise, en intégrant l’ensemble des fonctions de cette dernière comme la gestion des ressources humaines, la gestion comptable et financière, l’aide à la décision, mais aussi la vente, la distribution, l’approvisionnement, le commerce électronique.

Port série : port sur lequel on ne peut envoyer les données que bit par bit, les uns après les autres. Par opposition au port parallèle.

Port série RS232 : famille de standards d’interface de port de communication série. On y branche des souris, des modems, des imprimantes avec des connecteurs à 9 ou 25 broches.

Qualitorq : nom de l’application servant à traiter les mesures de couple faites avec un couplemètre TMV4 ou TMV5.

Qualitorq Serveur : nom de l’application, créée dans le cadre de ce mémoire, servant à traiter les mesures et la communication avec les couplemètre TMV5 qui y sont connectés via un réseau Ethernet et TCP/IP.

RFC : Request For Comment. Document au contenu variable sur l’Internet. Ce peut-être de la documentation générale, des standards, la description d’un protocole, …Session de mesures : c’est un ensemble de mesures auquel on rattache un numéro de session unique (pour pouvoir distinguer une session de mesures d’une autre) ainsi qu’un certain


81

nombre variable d’informations qui s’y rapporte (nom produit, numéro de lot du produit, ligne sur laquelle les échantillons du produit concernés ont été prélevés, date, heure, nombre de mesures effectuées durant la session de mesures, …)

TMV4 : Torque-Meter (couplemètre) version 4.

TMV5 : Torque-Meter (couplemètre) version 5.

UML : Unified Modeling Language. Langage de modélisation normalisé permettant de décrire une application en fonction des méthodes objet avec lesquelles elle a été construite.

URL : Uniform Resource Locator. Sur le Web, c’est la méthode d’accès à un document distant (exemple : http://www.google.fr).

Annexes


82

http://www.google.fr/

Protocole de la couche application pour le système de mesure de couple (couplemètre TMV5 et application serveur Qualitorq)


83

Les différents éléments contenus dans les différentes trames sont de taille variable, mis à part les commandes en majuscule. Tous ces éléments sont séparés par des « ; » (point virgule).

Il n’existe aucun espace entre les différents éléments et les « ; » (point virgule), ils apparaissent seulement dans ce document pour des raisons de lisibilité.

1/ Connexion

Cette commande sert à un utilisateur qui veut se connecter à l’application serveur pour effectuer une session de mesures ou obtenir des informations sur l’état des sessions :

Requête Cliente (Req C) :

LOG ; [Nom Utilisateur] ; [Mot de passe] ; [Id Cplm] ; CRLF

Réponses possibles du Serveur (Rep S) :

USER ; [Nom Utilisateur] ; Statut=[X] ; SessionAuto=[Y] ; CRLFX = 1 – 2 – 3 (1 = Utilisateur, 2 = Super Utilisateur, 3 = Administrateur)Y = 0 – 1

-ERR ; LOG ; CUI ; Compte Utilisateur Inactif ; CRLF-ERR ; LOG ; CUD ; Compte Utilisateur Désactivé ; CRLF-ERR ; LOG ; MDPI ; Mot De Passe Incorrect ; CRLF-ERR ; LOG ; NULL ; Compte Utilisateur Inexistant ; CRLF

-ERR ; CMD ; Commande Inconnue ; CRLF

2/ Quitter

Cette commande sert à se déconnecter du serveur :

Req C :

QUIT + CRLF ou Quit + CRLF ou quit + CRLF

Rep S :

+OK ; QUIT ; CRLF

3/ OBTENIR


84

PRODUIT

Cette commande sert à obtenir la liste des produits :

Req C :

OBTENIR ; PRODUIT ; CRLF

Rep S :

LIST ; PRODUIT ; [X] ; [Nom du Produit] ; CRLFX = compteur allant de 1 à n en fonction du nombre de produits envoyés…LIST ; PRODUIT ; FIN ; [Y] ; CRLF (Envoyé quand tous les produits ont été envoyés ou si aucun produit n’existe (avec Y = 0))Y = Nombre de produits envoyés

-ERR ; OBTENIR ; PRODUIT ; NA ; Non Autorisé ; CRLF

LOT

Cette commande sert à obtenir la liste des numéros de lot :

Req C :

OBTENIR ; LOT ; CRLF

Rep S :

LIST ; LOT ; [X] ; [N° de Lot] ; CRLFX = compteur allant de 1 à n en fonction du nombre de numéros de lot envoyés…LIST ; LOT ; FIN ; [Y] ; CRLF (Envoyé quand tous les numéros de lots ont été envoyés ou si aucun numéro de lot n’existe (avec Y = 0))Y = Nombre de numéros de lot envoyés

-ERR ; OBTENIR ; LOT ; PNS ; Produit Non Sélectionné ; CRLF-ERR ; OBTENIR ; LOT ; NA ; Non Autorisé ; CRLF

LIGNE


85

Cette commande sert à obtenir la liste des lignes :

Req C :

OBTENIR ; LIGNE ; CRLF

Rep S :

LIST ; LIGNE ; [X] ; [Nom de la Ligne] ; CRLFX = compteur allant de 1 à n en fonction du nombre de lignes envoyées…LIST ; LIGNE ; FIN ; [Y] ; CRLF (Envoyé quand toutes les lignes ont été envoyées ou si aucune ligne n’existe (avec Y = 0))Y = Nombre de lignes envoyées

-ERR ; OBTENIR ; LIGNE ; NA ; Non Autorisé ; CRLF

FICHE

Cette commande sert à obtenir la liste des fiches mesures qui correspondent à l’utilisateur connecté :

Req C :

OBTENIR ; FICHE ; CRLF

Rep S :

LIST ; FICHE ; [X] ; [Nom de la Fiche] ; [Nom Produit] ; [N° de Lot] ; [Nom de la Ligne] ; [Nombre de mesures à effectuer] ; CRLFX = compteur allant de 1 à n en fonction du nombre de fiches envoyées…LIST ; FICHE ; FIN ; [Y] ; CRLF (Envoyé quand toutes les fiches ont été envoyées ou si aucune fiche n’existe (avec Y = 0))Y = Nombre de fiches envoyées

FICHE_T


86

Cette commande sert à obtenir la liste de toutes les fiches mesures qui sont dans la base de données :

Req C :

OBTENIR ; FICHE_T ; CRLF

Rep S :

LIST ; FICHE_T ; [X] ; [Nom de la Fiche] ; [Nom Produit] ; [N° de Lot] ; [Nom de la Ligne] ; [Nombre de mesures à effectuer] ; CRLFX = compteur allant de 1 à n en fonction du nombre de fiches envoyées…LIST ; FICHE_T ; FIN ; [Y] ; CRLF (Envoyé quand toutes les fiches ont été envoyées ou si aucune fiche n’existe (avec Y = 0))Y = Nombre de fiches envoyées

-ERR ; OBTENIR ; FICHE_T ; NA ; Non Autorisé ; CRLF

SESSION_NC

Cette commande sert à obtenir la liste des sessions non clôturées qui correspondent à l’utilisateur connecté :

Req C :

OBTENIR ; SESSION_NC ; CRLF

Rep S :

LIST ; SESSION_NC ; [X] ; [N° de Session] ; [Nom Produit] ; [N° de Lot] ; [Nom de la Ligne] ; CRLFX = compteur allant de 1 à n en fonction du nombre de sessions non clôturées envoyées…LIST ; SESSION_NC ; FIN ; [Y] ; CRLF (Envoyé quand toutes les sessions non clôturées ont été envoyées ou si aucune session non clôturée n’existe (avec Y = 0))Y = Nombre de sessions non clôturées envoyées

SESSION_NC_T


87

Cette commande sert à obtenir la liste de toutes les sessions non clôturées :

Req C :

OBTENIR ; SESSION_NC_T ; CRLF

Rep S :

LIST ; SESSION_NC_T ; [X] ; [N° de Session] ; [Nom Produit] ; [N° de Lot] ; [Nom de la Ligne] ; CRLFX = compteur allant de 1 à n en fonction du nombre de session non clôturées envoyées…LIST ; SESSION_NC_T ; FIN ; [Y] ; CRLF (Envoyé quand toutes les sessions non clôturées ont été envoyées ou si aucune session non clôturée n’existe (avec Y = 0))Y = Nombre de sessions non clôturées envoyées

-ERR ; OBTENIR ; SESSION_NC_T ; NA ; Non Autorisé ; CRLF

4/ SELECT


88

PRODUIT

Cette commande sert à sélectionner un produit pour paramétrer la session :

Req C :

SELECT ; PRODUIT ; [Nom du Produit] ; CRLF

Rep S :

PARAM ; PRODUIT ; [Nom du Produit] ; [Seuil 1] ; [S2] ; [S3] ; [S4] ; [Unité] ; CRLF

-ERR ; SELECT ; PRODUIT ; NULL ; Produit Inexistant ; CRLF-ERR ; SELECT ; PRODUIT ; PI ; Produit Indisponible ; CRLF-ERR ; SELECT ; PRODUIT ; NA ; Non Autorisé ; CRLF

LOT

Cette commande sert à sélectionner un numéro de lot pour paramétrer la session :

Req C :

SELECT ; LOT ; [N° de Lot] ; CRLF

Rep S :

PARAM ; LOT ; [N° de Lot] ; CRLF

-ERR ; SELECT ; LOT ; NULL ; Lot Inexistant ; CRLF-ERR ; SELECT ; LOT ; LI ; Lot Indisponible ; CRLF-ERR ; SELECT ; LOT ; NA ; Non Autorisé ; CRLF-ERR ; SELECT ; LOT ; PNS ; Produit Non Sélectionné ; CRLF

LIGNE


89

Cette commande sert à sélectionner une ligne pour paramétrer la session :

Req C :

SELECT ; LIGNE ; [Nom de la Ligne] ; CRLF

Rep S :

PARAM ; LIGNE ; [Nom de la Ligne] ; CRLF

-ERR ; SELECT ; LIGNE ; NULL ; Ligne Inexistante ; CRLF-ERR ; SELECT ; LIGNE ; LI ; Ligne Indisponible ; CRLF-ERR ; SELECT ; LIGNE ; NA ; Non Autorisé ; CRLF

FICHE

Cette commande sert à sélectionner une fiche mesures pour paramétrer tous les éléments de la session :

Req C :

SELECT ; FICHE ; [Nom de la Fiche] ; CRLF

Rep S :

PARAM ; SESSION ; [Nom Produit] ; [N° Lot] ; [Nom Ligne] ; [Seuil 1] ; [Seuil 2] ; [Seuil 3] ; [Seuil 4] ; [Unité] ; [Nombre de mesures à effectuer] ; CRLF

-ERR ; SELECT ; FICHE ; NULL ; Fiche Inexistante ; CRLF-ERR ; SELECT ; FICHE ; FI ; Fiche Indisponible ; CRLF

SESSION_NC


90

Cette commande sert à sélectionner une session non clôturée pour reprendre la session là où elle a été interrompue (sans avoir pu être clôturée) :

Req C :

SELECT ; SESSION_NC ; [N° de Session] ; CRLF

Rep S :

PARAM ; SESSION_NC ; [N° de Session] ; [Nom Produit] ; [N° Lot] ; [Nom Ligne] ; [Seuil 1] ; [Seuil 2] ; [Seuil 3] ; [Seuil 4] ; [Unité] ; [Nbr de mesures déjà effectuées] ; [Nbr de mesures à effectuer au total] ; CRLF

-ERR ; SELECT ; SESSION_NC ; NULL ; N° de Session Inexistant ; CRLF-ERR ; SELECT ; SESSION_NC ; SC ; Session Clôturée ; CRLF-ERR ; SELECT ; SESSION_NC ; SEC ; Session En Cours ; CRLF

5/ INIT


91

LOT

Cette commande sert à initialiser un numéro de lot qui n’existe pas dans la base de données :

Req C :

INIT ; LOT ; [N° de Lot] ; CRLF

Rep S :

PARAM ; LOT ; [N° de Lot] ; CRLF

-ERR ; INIT ; LOT ; NA ; Non Autorise ; CRLF-ERR ; INIT ; LOT ; LNA ; Lot Non Approprié au Produit Paramétré ; CRLF

NBR_MES

Cette commande sert à initialiser un nombre de mesures à effectuer pour la session :

Req C :

INIT ; NBR_MES ; [Nombre de mesures à effectuer] ; CRLF

Rep S :

PARAM ; NBR_MES ; [Nombre de mesures à effectuer] ; CRLF

-ERR ; INIT ; NBR_MES ; NA ; Non Autorise ; CRLF-ERR ; INIT ; NBR_MES ; VNN ; Valeur Non Numérique ; CRLF-ERR ; INIT ; NBR_MES ; VTG ; Valeur Trop Grande [1-99] ; CRLF

6/ START


92

SESSION

Cette commande sert à démarrer la session de mesures (une fois celle-ci paramétrée) et donner l’ordre à l’application serveur de générer le numéro de session :

Req C :

START ; SESSION ; CRLF

Rep S :

START ; SESSION ; [N° de Session] ; [Nom Utilisateur] ; [Date] ; [Heure] ; [Nom Produit] ; [N° de Lot] ; [Nom Ligne] ; [Seuil1] ; [Seuil2] ; [Seuil3] ; [Seuil4] ; [Unité] ; [Nombre de Mesures à effectuer] ; CRLF

-ERR ; START ; SESSION ; PM ; Paramètre Manquant ; CRLF-ERR ; START ; SESSION ; CNSI ; Création N° de Session Impossible ; CRLF

7/ STOP

SESSION

Cette commande sert à stopper la session (une fois les mesures terminées) :Cette fonction fait aussi office d’un « QUIT » et débloque l’enregistrement suite à un blocage avec la fonction « SELECT ; SESSION_NC ; ».Si l’impression est active à la clôture de chaque session, un rapport est imprimé automatiquement.

Req C :

STOP ; SESSION ; CRLF

Rep S :

STOP ; SESSION ; OK ; CRLF

-ERR ; STOP ; SESSION ; MNF ; Mesures Non Fini ; CRLF-ERR ; STOP ; SESSION ; SND ; Session Non Démarrée ; CRLF (Si la commande « START » n’a pas encore été envoyée)

8/ MESURE


93

COUPLE

Cette commande sert à envoyer, à l’application serveur, la mesure de couple qui vient d’être effectuée par l’opérateur :

Req C :

MESURE ; COUPLE ; [Valeur mesurée] ; [Unité] ; CRLF

Rep S :

MESURE ; COUPLE ; [X] ; [Valeur mesurée] ; [Unité] ; [Min] ; [Max] ; [Moyenne] ; [Ecart-Type] ; [% Qualité de bonnes mesures] ; CRLFX = numéro de mesure ou FIN si c’était la dernière mesure.% Qualité de bonnes mesures = % des mesures comprises entre les 2 seuils de tolérance.

-ERR ; MESURE ; COUPLE ; SND ; Session Non Démarrée ; CRLF-ERR ; MESURE ; COUPLE ; MUR ; Mauvaise Unité Reçue ; CRLF-ERR ; MESURE ; COUPLE ; VMNP ; Valeur Mesurée Non Plausible ; CRLF

9/ COMMENTAIRE

Cette commande sert, à l’opérateur, s’il désire saisir dans la base de données un commentaire sur la session de mesures avant de la clôturer :

Req C :

COMMENTAIRE ; [Commentaire] ; CRLF

Rep S :

COMMENTAIRE ; OK ; [Nbr de caractères saisie et déjà saisie / Nbr de caractères total disponibles] ; CRLF

-ERR ; COMMENTAIRE ; ZCP ; Zone Commentaire Pleine ; CRLF

10/ INFO


94

SESSION

Cette commande sert à retourner certains paramètres de la session de mesures :

Req C :

INFO ; SESSION ; CRLF

Rep S :

INFO ; SESSION ; [N° de Session] ; [Nom Utilisateur] ; [Statut Utilisateur] ; [Session Auto] ; [Date] ; [Heure] ; [Nom Produit] ; [N° de Lot] ; [Nom Ligne] ; [Seuil1] ; [Seuil2] ; [Seuil3] ; [Seuil4] ; [Unité] ; [Nombre de Mesures à effectuer] ; CRLF

SESSION_T

Cette commande sert à retourner tous les paramètres de la session de mesures :

Req C :

INFO ; SESSION_T ; CRLF

Rep S :

INFO ; SESSION_T ; [N° de Session] ; [Id Utilisateur] ; [Nom Utilisateur] ; [Statut Utilisateur] ; [Session Auto] ; [Date] ; [Heure] ; [Id Cplm] ; [Id Nom Produit] ; [Nom Produit] ; [Id N° de Lot] ; [N° de Lot] ; [Id Nom Ligne] ; [Nom Ligne] ; [Id Seuils] ; [Seuil1] ; [Seuil2] ; [Seuil3] ; [Seuil4] ; [Unité] ; [Nombre de Mesures à effectuer] ; [Session Terminée (Vrai ou Faux)] ;CRLF

ETAT_SESSIONS


95

Cette commande sert à retourner l’état de toutes les sessions de mesures en cours :(On retourne toutes les informations concernant toutes les sessions de mesures en cours, contenues dans le tableau de la fenêtre principale du serveur)Cette commande sert uniquement à la console d’administration et non aux couplemètres.

Req C :

INFO ; ETAT_SESSIONS ; CRLF

Rep S :

LIST ; ETAT_SESSIONS ; [X] ; [Id Cplm] ; [Nom Utilisateur] ; [N° de Session] ; [Date] ; [Heure] ; [Nom Produit] ; [N° de Lot] ; [Nom Ligne] ; [Mes Min] ; [Mes Max] ; [Moyenne] ; [Ecart-Type] ; [% Qualité] ; [Nbr de Mesures déjà effectué / Nbr total de Mesures à effectuer] ; [Unité] ; CRLFX = compteur allant de 1 à n en fonction du nombre de sessions en cours à envoyer…LIST ; ETAT_SESSIONS ; FIN ; [Y] ; CRLF (Envoyé quand toutes les sessions en cours ont été envoyées ou si le tableau est vide (avec Y = 0))Y = Nombre de lignes du tableau envoyées

-ERR ; INFO ; ETAT_SESSIONS ; NA ; Non Autorisé ; CRLF

Résumé


96

Ce mémoire, d’ingénieur en informatique au CNAM, présente le développement d’une application serveur pour la publication et l’échange de données qualifiées provenant d’appareils de mesures de couple via les protocoles Ethernet et TCP/IP. Ce projet s’inscrit dans le cadre de l’informatique industrielle, car le système est destinée à l’industrie et plus précisément aux entreprises qui produisent ou qui utilisent, comme emballage, des bouchons et des bouteilles de diverses matières (plastique, aluminium, …). Qui dit serveur, dit aussi client, mais ici ces clients ne sont pas seulement des PC mais aussi des appareils de mesures, dans notre cas des couplemètres, possédant un système d’exploitation propriétaire avec un jeu de procédures et une carte réseau pour être connecté sur un réseau Ethernet et TCP/IP afin de communiquer avec l’application serveur.

Le but de ce système de mesures de couple (application serveur + couplemètres) est de faire du contrôle qualité sur le couple de serrage d’un bouchon sur une bouteille.

Ce projet part d’une analyse du besoin en passant par la conception et fini par une série de tests de bon fonctionnement.

Mots-clés : application serveur, serveur, réseau, Ethernet, TCP, IP, socket, thread, informatique industrielle, contrôle qualité, mesures de couple, base de données, protocoles de communications, protocole application, tests serveur.

Keywords : server software, server, network, Ethernet, TCP, IP, socket, thread, industrial computing, quality control, measures of torque, data base, protocols of communication, application layer, server test.


97