|
Rapport de stage : Développement d'une supervision de démonstration( Télécharger le fichier original )par Anthony MESROPIAN Faculté des sciences et techniques de St Jérôme à Marseille - Licence d'automatique et d'informatique industrielle 2008 |
Stage 08/09 chez SIMTRONICS SASMéthodologie de développement de la supervision L'étape d'imprégnation du travail précédent mon arrivée m'a permis de me concentrer sur la réalisation en gardant des objectifs clairs et des erreurs à ne pas commettre. Le choix d'utilisation du superviseur PcVue m'a été imposé, du fait d'être en adéquation avec les travaux précédents. Fin mars, j'ai donc entrepris le développement de la supervision de la maquette. Je me suis concentré premièrement à l'élaboration des différent modèles que propose SIMTRONICS SAS. Pour l'explosimètre et le toximètre, je me suis servi de ce qui existait déjà avec KEP INFILINK avant mon arrivée, ainsi que le modèle élaboré des travaux antécédents. Version KEP Version du stage précédent
Ma version De part l'étude de KEP qui m'a été confiée, j'ai essayé de récupérer les points les plus pertinents à mon goût, de façon a créer le modèle le plus proche de la réalité possible, mais aussi de pouvoir permettre aux développeurs qui me succèderont de faire remonter l'information de défaut. La particularité de PcVue est de pouvoir créer un modèle lambda en y intégrant directement les variables associées au modèle en question. De ce fait, les variables pertinentes sont liées, ce qui évite de renseigner le logiciel sur les variables accouplées au modèle. Le détecteur modélisé par KEP fonctionne parfaitement, et se base sur trois zones d'animations. Partie réseau
Corps du détecteur Cartouche Par analogie, j'ai reproduit ce système de zone sur ma modélisation du capteur :
Partie haute (partie réseau) Corps du détecteur Cartouche Ces zones d'animations permettent une meilleure précision quant à la visualisation de l'endroit du défaut... Pendant mon stage, j'ai appris que certains défauts peuvent se répercuter sur des points particuliers du détecteurs.
Par exemple, si un défaut apparaît sur la carte réseau :
On distingue à ce moment là que la partie réseau vire au dégradé jaune, ce qui indique qu'elle est en défaut. Il était très important de solutionner la supervision de la partie réseau, car elle est en elle-même l'interface qui régit la communication entre le détecteur et le réseau SYNTEL. Si un défaut apparaît autour du corps du détecteur :
Cette fois, c'est le corps entier du détecteur qui vire au dégradé jaune. De manière générale, l'opérateur doit savoir immédiatement que le système est en défaut, de manière à contacter le service de maintenance du réseau SYNTEL. Dans le cas d'un défaut cartouche :
Dans ce cas là, la cartouche entière elle-même vire au jaune. Ce défaut est très important et doit être réglé rapidement, car la cartouche est l'élément permettant la mesure du gaz concerné.
Dans le cas d'une alarme ou d'un lever de doute, le détecteur prend la couleur rouge avec un dégradé excentré. La couleur rouge a été choisie car elle attire l'oeil, et une alarme sur un détecteur signifie un danger imminent, c'est-à-dire que soit l'alarme de niveau 1 s'est déclenchée, soit celle de niveau 2, soit il faut pratiquer un lever de doute sur le détecteur.
En ce qui concerne le détecteur de flamme, j'ai pris le soin de recréer entièrement un modèle indépendant.
Après avoir demandé quelques conseils aux différentes personnes pouvant m'aider, il s'est avéré que le détecteur de flamme ne devait être placé cartouche vers le bas, mais dans une direction choisie. De plus, le détecteur de flamme doit être dans une position haute. Comme pour les détecteurs explosimètres et toximètres, le détecteur possède trois zones d'animation, pour plus de précision.
Partie réseau Corps du détecteur Cartouche du détecteur Il s'anime aussi de la même façon :
Pour un défaut cartouche
Pour un autotest par exemple
Défaut réseau
Dans le cas d'une pré alarme ou d'une alarme, le corps et la partie haute du détecteur devienne rouge. La méthodologie de développement de la supervision que j'ai utilisée est d'utiliser les mêmes codes couleurs pour tous les éléments du réseau SYNTEL. (Explosimètre, Toximètre, Détecteur de flamme, Safebox, Relais...) Pour les vues de détails, l'objectif était de s'inspirer de KEP, de garder le même esprit, en apportant une touche de nouveauté, et en tenant compte des travaux de mon prédécesseur dans le même temps.
Vue de détails de l'explosimètre par KEP INFILINK
Vue de détails de l'explosimètre réalisée par le stagiaire précédent
Voici donc la vue que j'ai proposée. Tout d'abord, j'ai réuni pour moi les éléments les plus pertinents qui devaient figurer sur une vue de détail. J'ai opté pour une vue de détails compacte et structurée, avec plusieurs types d'espaces permettant de faire remonter l'information à l'opérateur sous plusieurs formes. Plusieurs espaces ont été mis en jeu pour permettre à l'opérateur de voir, d'un simple clic de souris les détails de son détecteur. v L'espace courbe, sur la partie haute de la vue, qui permet de voir évoluer les mesures en temps réel. v Une autre représentation du détecteur, avec un barre graphe incrusté qui varie en temps réel via la mesure du détecteur. v La signalisation est représentée par des voyants encadrés ce qui permet de les différencier des commandes qui elles, sont hachurées. v Les commandes, représentées par des boutons, sont encadrées et l'espace qui leur est dédié est hachuré. Le bouton « émulation » permet de lancer une boite à boutons permettant de tester les défauts et de les simuler. Le bouton « Vers le menu maintenance » permet de naviguer dans la maintenance du produit. Le bouton « Vers l'écran d'accueil » permet de fermer la vue de détails et de revenir sur l'écran d'accueil. Dans un second temps, j'ai dû aussi m'occuper des alarmes. Dans la supervision KEP INFILINK, les alarmes déclenchent de la manière suivante : v L'alarme de niveau 1 se déclenche quand le détecteur dépasse les 25% LIE v L'alarme de niveau 2 se déclenche quand le détecteur dépasse les 50% LIE
Dans ce cas, la variable interne de mesure signale qu'il faut déclencher l'alarme de premier niveau car on atteint 25% LIE.
Maintenant, étant donné que la mesure a atteint 50%, l'alarme 2 doit être déclenchée En ce qui concerne la vue de maintenance, j'ai essayé, comme jusqu'à maintenant, de retenir les aspects positifs de KEP et des travaux antécédents. J'ai donc réuni, et réutilisé les points que j'ai trouvés intéressants, à savoir : v Les commandes à la volée v La signalisation par zone pour mieux cibler les défauts.
Sur cette vue de maintenance developpée sous Kep, on distingue bien les commandes des voyants, c'est un aspect que j'ai voulu reproduire. Il était important pour moi de bien analyser la taille des voyants, des boutons, de la représentation de capteur car cet interface homme machine a été contrôlée et critiquée par des personnes compétentes dans le métier de l'automation.
Cette vue m'a donné une idée quant à la représentation de ma vue pour les différentes commandes à créer, ainsi que les différentes signalisations. Par analyse de ces anciens travaux, j'ai pu rapidement avoir une vue globale sur ma vue de maintenance et les idées me sont venues. Sur cette vue, il était impossible de revenir à l'écran d'accueil, et par ailleurs, elle prenait entièrement l'écran du superviseur. La couleur (ici violet) est mal choisie pour l'inactivité. C'est avec de l'aide et des conseils, en lisant les rapports de critiques que j'ai pu savoir que la couleur normalisée était verte. La couleur verte se justifie par le fait de la normalité, du bon fonctionnement du système.
Voici donc la vue que j'ai proposée pour l'alternative de KEP Chaque défaut possède son voyant de signalisation, et l'opérateur possède des commandes à la volée. De la vue de maintenance, on peut revenir via un clic vers la vue de détails ou bien retourner sur la vue générale via un clic sur le bouton « Retour vers l'écran d'accueil ». Les parties sont distinctes (voyants encadrés, commandes hachurées)
Si on déclenche un défaut La partie concernée se met en défaut et le voyant le signale. J'ai élaboré la supervision de telle sorte que l'on puisse revenir à l'écran d'accueil à partir de n'importe quelle vue. Chaque vue est indépendante, et il est possible de les ouvrir et de les fermer sans interrompre le bon fonctionnement de la supervision.
Pour les deux derniers éléments du réseau, c'est-à-dire la safebox et le relais, il m'a été conseillé de créer un autre espace de maintenance, dans lesquels ils se situeront. C'est dans cette espace que l'on pourra constater l'état des safebox et relais. Dans la supervision KEP INFILINK, la safebox était représentée par un modèle rectangulaire.
Dans le cas d'un défaut média
La safebox se colore en jaune, et un libellé « défaut présent » s'affiche. Après étude de la safebox réelle, j'ai opté pour un modèle rond, et qui donnera d'emblée une précision supérieure au modèle KEP dans le cas d'un défaut.
Dans le cadre d'un fonctionnement normal, la safebox affiche Système : en service et une disponibilité intégrale. Dans le cas d'un défaut média :
Cette fois, le système détecte un défaut média et l'opérateur connaît directement la nature de son défaut. Plusieurs types de défauts peuvent apparaître sur une safebox (défaut élément, défaut détecteur, défaut alimentation, switch sécurisé...) et dans tous les cas, la supervision remontera l'information directement en affichant un libellé précis. Dans le cas du relais, j'ai opté sur un modèle équivalent à celui de KEP
Représentation KEP INFILINK Représentation PCVUE Le but de la supervision est de faire remonter l'information en cas de défaut sur une sortie.
J'ai opté pour un défaut signalisé en rouge pour chaque sortie défaillante. Stage 08/09 chez SIMTRONICS SAS Les critères importants d'une supervision industrielle Durant tout le développement de ma supervision, j'ai tenu à garder une uniformité dans la différenciation des commandes et des voyants. J'ai opté pour un style sobre et clair, qui pour moi me semblait le plus justifié pour une supervision de type industriel. Le but de mon stage étant de proposer une alternative à la solution déjà existante de KEP, il m'a fallu travailler sur des idées d'amélioration de niveau esthétique ainsi que pratique. Je me suis donc concentré sur deux axes de difficultés : v ESTHETIQUE :
Stage 08/09 chez SIMTRONICS SAS L'aspect esthétique Pour satisfaire au critère esthétique, qui représentait 50% de mon objectif pour ma réalisation de projet, j'ai du élaborer et améliorer au fur et à mesure ma supervision. Tout d'abord, concernant les modèles, ceux-ci ont suivis plusieurs passes.
La version 1 du capteur, dessinée à mon arrivée, a rapidement trouvé ses limites en terme d'esthétique, il a donc fallu évolué sur la base du travail précédent.
J'ai donc élaboré la version 2 du capteur, en partie basée sur le travail du stagiaire qui m'a précédé. Ici, j'utilise une couleur bleue avec un dégradé excentré.
Pour ma version définitive, j'ai donné un effet de dégradé sur la cartouche pour augmenter l'impression de rondeur. J'ai aussi appliqué un dégradé. La couleur verte m'a été imposée, synonyme de bon fonctionnement du détecteur.
La version finale que j'ai proposée pour fournir une alternative à KEP est celle-ci. J'ai élaboré les différents menus afin de proposer à l'opérateur une navigation facile : v MODE OPC : ce bouton permet de passer du mode démonstration au mode OPC d'un seul clic v Maintenance : ce bouton permet d'accéder à la vue maintenance du système syntel v L'heure v Login : pour s'identifier v Log out : pour clore une session d'identification v Info : pour avoir des informations sur l'utilisateur courant Stage 08/09 chez SIMTRONICS SAS L'aspect pratique Le problème qui a été rencontré durant le développement sur KEP INFILINK était le passage du mode démonstration au mode OPC réel. J'ai donc du rechercher des solutions à ce problème pour le proposer dans mon alternative sur PCVUE. J'ai donc utilisé le système de branche sous PCVUE, de façon à pouvoir passer du mode réel au mode demonstration d'un seul clic. Mode démonstration
Clic sur mode OPC Mode réel Stage 08/09 chez SIMTRONICS SAS Le protocole OPC : OLE for Process Control La technologie OPC est apparue en 1995. Cette technologie dédiée à l'interopérabilité des systèmes industriels signifiait initialement OLE for Process Control. OPC n'est pas un protocole de communication mais une technologie basée sur les technologies OLE, COM, et DCOM développées par Microsoft pour sa famille de systèmes d'exploitation. OPC a été conçu pour relier les applications Windows et les matériels et logiciels du contrôle de processus. La norme définit une méthode cohérente pour accéder aux données de terrain de dispositifs d'usine. Cette méthode reste la même quel que soit le type et la source de données. Les serveurs OPC fournissent une méthode permettant à différents logiciels d'accéder aux données de dispositifs de contrôle de processus, comme par exemple un automate. Traditionnellement, chaque fois qu'un programme nécessitait l'accès aux données d'un périphérique, une interface personnalisée, un pilote ou driver, devait être écrit. L'objectif de l'OPC est de définir une interface commune écrite une fois puis réutilisées par n'importe quel logiciel d'entreprise, SCADA, IHM. Une fois qu'un serveur OPC est écrit pour un périphérique particulier, il peut être réutilisé par n'importe quelle application qui est capable d'agir en tant que client OPC. Un serveur OPC utilise la technologie Microsoft OLE (aussi connu sous le nom de Component Object Model ou COM) pour communiquer avec les clients
Stage 08/09 chez SIMTRONICS SAS |
|
