Memoire Online - Rapport de stage : Développement d'une supervision de démonstration

Je tiens à remercier dans un premier temps, toute l'équipe pédagogique de la faculté de St Jérôme et celle du lycée du Rempart, responsables de la licence professionnelle d'automatique et d'informatique industrielle, pour avoir assuré la partie théorique de celle-ci.
Je tiens à remercier tout particulièrement et à témoigner toute ma reconnaissance aux personnes suivantes, pour l'expérience enrichissante et pleine d'intérêt qu'elles m'ont fait vivre durant ces trois mois au sein de l'entreprise Simtronics SAS :

Monsieur LA PIANA, Manager général de Simtronics SAS, pour son accueil et la confiance qu'il m'a accordé dès mon arrivée dans l'entreprise.

Monsieur CACCIAGUERRA, chef de projet et chargé d'affaires chez Simtronics SAS, mon tuteur, pour m'avoir intégré rapidement au sein de l'entreprise et m'avoir accordé toute sa confiance; pour le temps qu'il m'a consacré tout au long de cette période, sachant répondre à toutes mes interrogations ; sans oublier sa participation au cheminement de ce rapport.

Messieurs PASCOU, BOUDOUDA, DE GENNARO ainsi que l'ensemble du personnel de Simtronics SAS pour leur accueil sympathique et leur coopération professionnelle tout au long de ces trois mois.

L'objectif du stage de fin d'études de la licence professionnelle chez SIMTRONICS SAS

ses supervisions simplement après mon passage, le but sera de créer des modèles informatiques des différents produits

Dans tous les cas, le système fonctionnant déjà correctement, l'enjeu sera de proposer une interface de qualité permettant d'exploiter en profondeur le système complexe SYNTEL.

SIMTRONICS SAS est une société spécialisée dans la conception, la fabrication, la commercialisation et la maintenance de produits de détection de gaz et de flammes.

Afin de renforcer sa position sur le marché mondial et de répondre de façon globale aux marchés du monde de l'offshore, l'entreprise a intégré le groupe Norvégien SIMRAD Optronics.

Sur ses sites de production situés à Aubagne et à Oslo, en Norvège, SIMTRONICS conçoit et réalise une gamme complète de produits destinés à couvrir l'ensemble des risques gaz et flamme.

Autour de son métier, la détection et l'analyse des gaz explosifs et toxiques, la supervision et les systèmes intégrés apportent une offre globale qui assure performances et homogénéité. Grâce à la qualité de ses produits et à son savoir-faire, SIMTRONICS réalise des projets importants, en France et à l'export, qui a contribué à son expansion et à l'évolution de sa structure.

Présentation générale de SIMTRONICS SAS

1948 : Fondation de la Société ICARE (Industrie de Construction d'Appareils Radio Electriques) pour répondre à une demande de la Marine Nationale.

1954 : Homologation OTAN et jusqu'à aujourd'hui équipement de tous les sous-marins construits sous code OTAN et des sous-marins nucléaires Français.

1969 : Ouverture des produits ICARE vers le monde industriel (maritime, pétrole, chimie...)

1971 : ICARE commence à fournir des ensembles de détection / analyse
de Gaz au travers des Sociétés d'Ingénieries.

1978 : ICARE commence à fournir des ensembles de détection / analyse de Gaz dans les centrales nucléaires civiles.

1980 : Création du concept Compact Capteur avec électronique embarquée : Explosimètres, Oxygénomètres et Toximètres.

1994 : L'actionnaire principal de la Société ICARE devient le Groupe CS (Compagnie des Signaux).

1995 : Création du Concept d'Intelligence Distribuée (Réseau SYNTEL)
dans la détection de gaz et de flamme.
Introduction du Microprocesseur dans chaque capteur.

2000 : ICARE innove encore avec la sortie d'un détecteur optique de flamme triple spectre, une détection dans l'ultra violet combinée à une double détection dans l'infra rouge.

Sortie de la ligne de produits ECHO destinée prioritairement aux sites semi industriels et tertiaires.

Afin de renforcer sa position sur le marché mondial et de répondre de façon globale aux marchés du monde de l'offshore, l'entreprise intègre le groupe Norvégien SIMRAD Optronics.

2007 : Séparation des deux départements du groupe SIMRAD Optronics : Militaire et Fire & Gas.

SIMTRONICS SAS travaille aujourd'hui sur plusieurs secteurs d'activités et avec des clients tels que :

v PLATEFORMES PETROLIERES des sites de forage et d'exploitation tels que North Alwyn (Mer du Nord), ou Frigg (Norvège)...

Tous les produits fabriqués par SIMTRONICS SAS sont certifiés ATEX, ils sont donc

Avant même de penser à l'étude du développement de l'interface homme machine,

la logique m'a poussé à m'imprégner des différents gaz détectables par les différents

Dans le cas spécifique de mon travail, j'ai étudié les explosimètres, les toximètres et les détecteurs de flamme.

Les explosimètres et catharomètres sont des appareils destinés à la mesure du risque d'explosion engendré par la présence de gaz ou de vapeurs inflammables.

Les toximètres sont destinés à la mesure du risque toxique engendré par la présence de gaz ou vapeurs toxiques.

o Permet d'établir une surveillance constante et stable du risque d'asphyxie par manque d'oxygène.

o Permet d'assurer d'autre part la sécurité des personnes en contrôlant la déficience du taux d'oxygène entraînée par des fuites de gaz tel que l l'azote(N₂) par exemple

Les détecteurs optiques de flamme sont équipés d'une cartouche intelligente et débrochable assurant la détection et le traitement du signal.

Afin de mieux répondre aux exigences du marché, le détecteur fonctionne sur les différents principes suivants :

V00 : UV / IR² La triple détection est basée sur le rayonnement de flamme dans l'Ultra Violet et dans deux bandes infra rouges.

T00 : IR3 La triple détection est basée sur le rayonnement de flamme dans trois bandes infra rouges distinctes.

Conçu pour atteindre une grande portée de détection tout en garantissant une excellente immunité contre les fausses alarmes, il est le détecteur le plus performant de sa catégorie. Du point de vue des fausses alarmes, l'exploitation de deux mesures en infra rouge par un algorithme original rend le V00, insensible aux conditions environnementales difficiles telles que pluie et vent combinés, les variations rapides d'ensoleillement, ainsi que les sources chaudes modulées, les éclairages industriels, ... L'utilisation d'une confirmation de détection au travers d'une voie de mesure en Ultraviolet permet de réduire encore le risque résiduel de fausses alarmes tout en disposant d'une information de mesure très rapide.

Cette configuration en UV seul de la cartouche de détection permet, principalement, d'exploiter l'appareil sur des feux non hydrocarbonés, du type feux d'hydrogène, d'ammoniac, ... Elle permet, par ailleurs, d'obtenir des temps de réponse extrêmement intéressants.

Cette déclinaison de la cartouche V00 en IR² seul permet de fonctionner dans des environnements pénalisant la propagation du rayonnement UV, du fait d'émanation de très fortes fumées en milieu confiné, par exemple.

La version de cartouche IR est la dernière née de cette gamme d'appareil. Un effort particulier a été fait sur l'algorithme de traitement du signal de manière à donner à cette version des performances uniques tout en maintenant un taux de fausses alarmes extrêmement faible. Pour parvenir à ce résultat, l'appareil exploite trois bandes infrarouges distinctes et un traitement mathématique complexe.

Connaissances nécessaires d'avant projet

SIMTRONICS SAS crée ses produits dans le but de sécuriser les installations de ses clients.

De ce fait, quand un événement dangereux peut se déclencher, le système de détection de gaz doit être la plus fiable possible.

La réglementation ATEX (ATmosphères EXplosibles) est issue de deux directives européennes (en 1994 pour les machines et en 1999 pour les utilisateurs).

La réglementation dite ATEX demande à tous les chefs d'établissement de maîtriser les risques relatifs à l'explosion de ces atmosphères au même titre que tous les autres risques professionnels.

Une ATEX, c'est une « Atmosphère Explosible » qui pourrait devenir explosive en raison des conditions locales ou/et opérationnelles. C'est un mélange d'air et de substances inflammables sous forme de gaz, vapeurs, brouillards ou poussières, dans lequel, après inflammation, la combustion se propage à l'ensemble du mélange non brûlé.

Quelles sont les conditions pour que l'on devienne en présence d'une atmosphère explosive ?

v Condition n°1 : Il faut la présence d'un comburant et d'un combustible. Dans un mélange formant une ATEX, l'oxygène de l'air est le comburant, les substances inflammables sous forme de gaz, de vapeurs ou de poussières sont le combustible.
Voici quelques exemples de combustibles pouvant former une ATEX dans un mélange avec l'air :

v Condition n°2 : Le mélange doit être explosif.
Une ATEX explose par l'apport d'une source d'inflammation, qui peut être une source d'énergie suffisamment importante (par exemple une étincelle d'origine mécanique ou électrique) ou une température suffisamment élevée (par exemple une surface chaude).

Toutes les entreprises utilisant des substances inflammables ont un risque d'explosion et sont concernées par la réglementation ATEX. Quelques exemples :

SIMTRONICS SAS est spécialisée dans la détection de gaz. Depuis plus de 50 ans, SIMTRONICS SAS a acquis et développé son expérience dans le domaine de la sécurité.

Les produits de SIMTRONICS SAS permettent de détecter efficacement tout risque de toxicité, explosivité mais aussi les départs de flamme.

Depuis peu, l'entreprise a crée un système de réseau, nommé SYNTEL, permettant de

Ce réseau, développé en interne, possède sa propre supervision, appelée SYNTEL CLASSIQUE.

Le logiciel Syntel Classique assure la gestion sur plate-forme PC de l'ensemble des informations. Il présente un IHM graphique permettant de visualiser l'ensemble de l'état de la détection en global, par zone ou par détecteur ainsi que l'état du système en terme de communication, d'alimentation et de disponibilité.

Il délivre sur demande des diagnostics complets sous forme de synoptiques animés.

Il archive les événements et les mesures dont plusieurs critères de tri permettent l'exploitation de ces historiques. La mesure de chaque détecteur est disponible sous forme de courbe temps réel. Et plusieurs niveaux d'accès permettent de gérer l'accès aux commandes de maintenance.

LE SYSTEME SYNTEL (CLASSIQUE)

Le SYSTEME-SYNTEL® est un système en réseau de terrain sécurisé à intelligence distribuée où chaque détecteur interagit directement sur les modules d'asservissement.

Une topologie en anneau où un câble unique permet d'alimenter les équipements et de constituer le média de communication. Les équipements peuvent être placés n'importe où sur le câble, sans aucune contrainte particulière.

Le système est résistant à une agression du câble, en terme d'ouverture ou de court-circuit. Il réalise la localisation de l'incident et le rétablissement automatique des communications et des alimentations. De par son architecture à intelligence distribuée, il n'existe pas de mode commun. Les alimentations du système sont redondées. Le câble est bouclé sur lui même via la SafeBox. Cet équipement rétabli les communications en cas d'ouverture du média (système breveté Simtronics). Le système est donc capable de maintenir sa disponibilité en cas de rupture ou court-circuit du média, de l'alimentation ou des deux à la fois.

Les abonnés du SYSTEME-SYNTEL® communiquent entre eux d'une manière spontanée grâce aux liens logiques définis par l'outil de configuration.

Ce principe repose sur le service producteur/consommateur du protocole Lonworks™. Il permet de définir deux classes d'abonnés. Celle qui regroupe tous les abonnés « produisant » des informations (capteurs). Celle qui regroupe les abonnés « consommant » ces informations (relais, superviseur Syntel, coupleur ...).

Lors de la configuration du réseau, des liens implicites au mode producteur/ consommateur sont ainsi créés entre les abonnés. Ainsi configuré, le producteur lors d'un changement d'état de sa détection, envoie spontanément un message au groupe consommateurs.

Chaque producteur d'informations possède deux accès au réseau : A et B totalement indépendants.

Quel que soit le message circulant sur le réseau, les producteurs fonctionnent en répéteur A vers B, ou B vers A.

Les messages transitent ainsi d'abonné en abonné. La boucle est refermée sur un équipement appelé Safebox. Cet équipement en mode nominal maintien la boucle ouverte (en ne répétant pas les messages de A vers B et de B vers A). La Safebox évite ainsi que les messages tournent inutilement à l'infini. Ce principe est breveté par SIMTRONICS. La Safebox, en cas de détection d'une rupture du média, assure la continuité de celui-ci en répétant les messages à travers elle.

Mécanisme automatique de reprise des messages en cas de rupture du média.

En mode nominal, la SafeBox ouvre la boucle entre A et B. Le message envoyé par le capteur côtés A et B, parvient au relais par A.

En mode dégradé, la Safebox ferme la boucle entre A et B. Le message envoyé par le capteur côtés A et B, parvient au relais par B.

LE SYSTEME SYNTEL XXI

SIMTRONICS SAS a développé une supervision nouvelle, permettant de tirer profits de la puissance de SYNTEL XXI. La supervision a été développée à l'aide du logiciel KEP INFILINK.

Cet IHM intègre maintenant les dernières versions des composants (détecteurs, relais, etc.) sortis depuis la création du système SYNTEL classique.

Cette application permet d'aller beaucoup plus loin que précédemment dans l'interaction homme machine car elle permet d'intégrer du code SCADA BASIC mais aussi le protocole OPC (Ole for Process Control).

Les variables OPC permettent de faire remonter et de signaler efficacement les informations propres au capteurs.

Grâce au configurateur SYNTEL développé en interne chez SIMTRONICS SAS, on régit une génération de capteurs et variables associées, et dans un second temps il ne reste qu'à les placer

Dans le but de permettre de générer du code SCADA BASIC facilement et donc de faciliter la création d'interfaces homme machines grâce au logiciel KEP INFILINK, SIMTRONICS SAS a

Le configurateur réseau SYNTEL permet de définir une base de données de type Access, regroupant tous les éléments réseau du système. Après avoir renseigné à la base de données le nombre d'éléments que l'on désire pour notre supervision, on génère les fichiers SCADA utilisables directement par les superviseurs compatibles. (KEP INFILINK et PcVue par exemple)

Cette maquette a pour but de présenter les produits qui existent chez Simtronics.

L'objectif de mon stage de mars à juin fut de proposer une alternative à la solution de supervision déjà existante, KEP INFILINK.

En effet, SIMTRONICS SAS, en proposant ce stage, cherche à proposer une autre interface pour leurs clients.

Le but est de proposer de nouvelles idées, essentiellement esthétiques, qui pourraient améliorer le travail qui existe déjà.

Pour m'aider dans ma démarche, SIMTRONICS SAS m'a proposé de participer au WONDERWARE TOUR, qui s'est présenté à Aix-En-Provence, dans le but de me permettre d'aborder au mieux les supervisions actuelles.

KEP INFILINK propose aujourd'hui une interface de démonstration, et le passage du mode démonstration vers le mode OPC réel se fait via une relance du logiciel.

De ce fait, j'ai du organiser ma stratégie de réflexion afin de répondre à mes besoins.

v Acquérir les connaissances nécessaires afin de réaliser une supervision stable

Cette étape préliminaire est importante pour pouvoir aborder le projet avec aisance.

Après avoir reconnu le degré de difficulté de la réalisation du projet, je me suis donc lancé dans le développement de la supervision sous PcVue en gardant à l'esprit que l'esthétique était la partie dans laquelle je devrai m'investir le plus possible.

Pour le développement, le choix s'est orienté vers PcVue car le stagiaire précédent avait déjà entrepris des réalisations pour SIMTRONICS SAS, notamment du capteur de type explosimètre.

Le stagiaire précèdent avait pour objectif de stage de réaliser un modèle d'explosimètre, le plus proche de la réalité possible, en laissant libre court à son esprit esthétique.

Pour m'imprégner de son travail, il m'a été suggéré de faire quelques propositions d'améliorations concernant son projet.

On remarque que sur la vue générale, les détecteurs sont représentés par des carrés, ce qui n'est pas envisageable lorsque l'on prend en compte l'aspect esthétique de la supervision.

La solution que j'ai alors proposé dans le but d'une possible amélioration de l'interface était de remplacer les carrés par une miniature de capteur de manière à comprendre directement que la zone concernée possède deux détecteurs.

Message d'erreur se présentant en cas de clic sur une zone ne comprenant pas de détecteurs

Les autres zones du premier écran ne sont pas judicieuses, car elles ne contiennent qu'un message d'erreur qui nous renvoie sur la page principale de plus, la phrase n'est pas correcte grammaticalement, il aurait été judicieux d'écrire : « Cette zone ne contient aucun détecteur actuellement ».

Solution proposée : ne pas supprimer les zones, mais insister sur un encadrement en surbrillance grisâtre (ou autre code couleur) pour insister sur le fait que l'endroit pointé n'est pas pertinent.

Un point étant à souligner par ailleurs, la résolution de la supervision étant assez faible (800*600),

sachant que les supervisions modernes doivent s'afficher sur un écran haute définition, configurer l'espace de travail en 1920*1080 de façon à être exploitable.

Le bouton quitter qui réalise une fonction de chaînage fermeture ne porte pas un nom pertinent, surtout dans le cas d'une supervision démonstrative.

Solution envisagée : proposer un autre label, comme par exemple : « Revenir à l'écran précèdent », « Précédent », « Revenir à la vue générale ».

L'ombre portée de part et d'autre du détecteur donne un effet d'amplitude de relief au capteur, ce qui est un excellent point pour une représentation de qualité. Le synoptique est globalement bien réalisé et correspond à un niveau passable de représentation. Le seul point impertinent du détecteur est la partie haute.

Solution envisagée : après avoir étudié et regardé sous différents angles de vue un détecteur lambda, prendre le temps d'élaborer un synoptique modèle qui respecte les critères suivants :

ESTHETIQUE, SIMPLE, REUTILISABLE, AISEMENT SUPERVISABLE, PERTINENT, REALISTE, BIEN PROPORTIONNE.

Dans le cas où plusieurs détecteurs seraient mis en jeu, une appellation pour chaque détecteur serai judicieuse.

Proposition d'amélioration : nommer les capteurs de façon à bien les différencier (classification par zone, type, position sur écran) par exemple pour un explosimètre placé dans la première zone d'une usine et placé en haut de l'écran du superviseur :

Globalement, pour un travail de qualité, il est nécessaire d'utiliser tous les outils mis à disposition par le superviseur durant le développement de la supervision.

Le but est de développer une console de supervision simple et intuitive pour être utilisée sans difficultés par un opérateur, même sans culture informatique.

L'heure et la date sont gadgets, la logique de développement propose plutôt de mettre ces informations dans un panel commun aux différentes vues, ou bien sur la vue générale.

La taille de la fenêtre de détails est trop importante, on ne peut pas voir si le deuxième capteur change de couleur (synonyme de défaut).

Le synoptique « Vue de détails » ne donne pas l'espace optimum aux différents composants (boutons, symbole détecteur).

Proposition : créer un synoptique de taille suffisante pour une vue de détails claire et intuitive. En outre, la disposition des éléments est une condition essentielle à une interface homme machine réussie.

Proposition d'amélioration : Un label comme « Revenir à la vue de zone » ou « Revenir à l'écran précèdent » serai plus intéressant.

A partir de ce moment là, le seul moyen de rentrer dans la vue de maintenance est de passer par la vue de détails.

Proposition de changement de structure : cet aspect n'est pas intuitif, il faut pouvoir accéder à l'écran de maintenance à tout moment, quelque soit la fenêtre active.

Je tiens à signaler par ailleurs que les variables de défauts sont les même sur les deux détecteurs, donc les défauts forcés se répercutent sur les deux détecteurs, il n'y a donc pas de supervision autonome pour les deux détecteurs.

On retrouve le même problème que précédemment, à savoir cette fois la vue de maintenance occupe tout l'écran, il est donc impossible d'observer un défaut sur un autre capteur.

Proposition d'amélioration : Changer le nom du bouton, il serai préférable de l'appeler « Quitter le menu de maintenance » ou bien « Annuler ».

Il faudrait aussi créer un bouton permettant de revenir à la vue générale sans repasser par la vue de détail. On pourra le placer par exemple à proximité du bouton actuel « Quitter Maintenance » qui permettra de revenir directement à l'écran principal.

Le switch électrique est mal représenté, il vaut mieux utiliser le symbole normalisé.

Stage 08/09 chez SIMTRONICS SAS

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.

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.

Par analogie, j'ai reproduit ce système de zone sur ma modélisation du capteur :

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.

On distingue à ce moment là que la partie réseau vire au dégradé jaune, ce qui indique qu'elle est en défaut.

car elle est en elle-même l'interface qui régit la communication entre le détecteur et le réseau SYNTEL.

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.

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

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.

Comme pour les détecteurs explosimètres et toximètres, le détecteur possède trois zones d'animation, pour plus de précision.

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.

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 la supervision KEP INFILINK, les alarmes déclenchent de la manière suivante :

Dans ce cas, la variable interne de mesure signale qu'il faut déclencher l'alarme de premier niveau

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 :

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.

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.

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 ».

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.

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.

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.

Le but de la supervision est de faire remonter l'information en cas de défaut sur une sortie.

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.

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.

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é.

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

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.

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

STRUCTURES DES VARIABLES OPC CHEZ SIMTRONICS SAS

Les items du serveur OPC d'ICARE se construisent comme suit : net[<netID>].node[<nodeID>].<netvar>.<SNVT_type>!<SNVT_comp> : ...

Dans laquelle <netID> est l'identifiant du réseau, <nodeID> celui du noeud, <netvar> le nom donné à la variable réseau dans l'application du noeud, <SNVT_type> est le type de la variable réseau, <SNVT_comp> est le nom pour un type structuré sur plusieurs niveaux.

Les types de données des détecteurs sur le serveur OPC sont décomposés en deux familles :

Dans chacune des deux familles, on retrouve les données sous plusieurs formes : en Bits et en Bytes.

	COMMUN

Suffixe spécifique de l'item OPC	Bytes		Bits
Commandes
CommCmd	0 : Commande mode alterné
commande communication	1 : Commande mode fixé côté A
	2 : Commande mode fixé côté B
	3 : Commande mode répéteur
SwitchCmd	0 : Commande fermeture switch
commande du switch	1 : Commande ouverture switch
	4 : Commande fermeture switch sécurisée
	5 : Commande ouverture switch sécurisée
TransModeCmd	Bit 0 : inhibition alarmes		TransAlarmsInhibit : 1
commande mode de fonctionnement	Bit 1 : mode test liens réseau		NetTest : 1
	Bit 2 : mode hors service		NetDisable : 1
	Bit 5 : switch persistant		NetSwitchPersistent : 1
	Bit 6 : mode émulation		NetEmultateDetector : 1
Défauts
TransFailure	Bit 0 : autotest carte échoué		TransTestFailure:Value : 1
défauts de la carte numérique	Bit 2 : Défaut comm SPI		TransSPIFailure:Value : 1
	Bit 3 : message réseau échoué		NetMessageFailed:Value : 1
	Bit 5.7 : cause du reset carte		NetResetInfo:Value
	0 : inconnu		0 : inconnu
	1 : power up		1 : power up
	2 : pint reset Neuron Chip		2 : pint reset Neuron Chip
	3 : software		3 : software
	4 : watchdog		4 : watchdog
Informations
Quality	<>192 : Absent
présence du détecteur	= 192 : Présent
SwitchComm	Bit 0.2 : état du switch	Switch Value :
état du switch et de la communication	0 : fermé	0 : fermé
	1 : ouvert	1 : ouvert
	3 : ouvert sur incident	3 : ouvert sur incident
	5 : ouvert en mode sécu	5 : ouvert en mode sécu
	7 : inconnu	7 : inconnu
	Bit 3 : comm mode repéteur	Repeater:Value : 1
	Bit 4 : comm côté B	CommB:Value : 1
	Bit 5 : comm côté A	CommA:Value : 1
	Bit 6 : pas de tension côté B	PowerFailureB:Value : 1
	Bit 7 : pas de tension côté A	PowerFailureA:Value 1

	ICARE_GAS

Suffixe spécifique de l'item OPC	Bytes	Bits
Alarmes
Alarms	Bit 0 : alarme gaz niveau 1	Alarm1:Value : 1
alarmes du détecteur	Bit 1 : alarme gaz niveau 2	Alarm2:Value : 1
	Bit 2 : alarme gaz niveau 3	Alarm3:Value : 1
	Bit 3 : alarme gaz niveau 4	Alarm4:Value : 1
	Bit 4 : protection sonde	SensorProtection:Value : 1
	Bit 6 : alarme interne n1	LocalRelay1:Value : 1
	Bit 7 : alarme interne n2	LocalRelay2 :Value : 1
Défauts
GasFailure	Bit 0 : défaut cellule gaz	SensorFailure:Value : 1
défauts de la cellule de détection	Bit 1 : dérive du zéro	ZeroShift:Value : 1
	Bit 2 : dépassement échelle	ScaleLimitsExceeded:Value : 1
	Bit 3 : défaut calibrage zéro	ZeroCalFailure:Value : 1
	Bit 4 : défaut calibrage gain	GainCalFailure:Value : 1
	Bit 5 : défaut compensation	CompensationFailure:Value : 1
Informations
Measure	Mesure du capteur sans facteur d'échelle appliqué
mesure du capteur
Class	21 : capteur gaz 2G
modèle du capteur	23 capteur gaz 3G
TransMode	Bit 0 : alarmes gaz inhibées	TransAlarmsInhibited:Value : 1
mode de fonctionnement du capteur	Bit 1 : mode test	NetModeTestMode:Value : 1
	Bit 2 : mode hors service	NetDisableMode:Value : 1
	Bit 3 : en configuration IR	TransRemoteConfid:Value : 1
	Bit 4 : cellule en chauffe	SensorWarmingUp:Value : 1
	Bit 5 : switch persistant	NetPersistentSwitch:Value : 1
	Bit 6 : mode émulation	NetEmulationMode:Value : 1
	Bit 7 : en maintenance	TransMaintenanceMode:Value: 1

	ICARE_UV2IR
	ICARE_UV2IR
Suffixe spécifique de l'item OPC	Bytes	Bits
Alarmes
Alarms	Bit 0 : alarme flamme	Alarm:Value : 1
alarmes du détecteur	Bit 1 : préalarme flamme	Prealarm:Value : 1
	Bit 6 : alarme interne n1	LocalRelay1:Value : 1
	Bit 7 : alarme interne n2	LocalRelay2 :Value : 1
Défauts
FlameFailure	Bit 0 : défaut detection UV	UVFailure:Value : 1
défauts de la cellule de détection	Bit 1 : défaut detection IR	IRFailure:Value : 1
	Bit 2 : défaut cellule detection	DetectorFailure:Value : 1
	Bit 6 : mode simulation flamme	FlameSimulationMode:Value : 1
	Bit 7 : mode test feu	FlameTestMode:Value : 1
Informations
Class	22 : uv2ir 3G
modèle du capteur
TransMode	Bit 0 : alarme flamme inhibée	TransAlarmsInhibited:Value : 1
mode de fonctionnement du capteur	Bit 1 : mode test	NetModeTestMode:Value : 1
	Bit 2 : mode hors service	NetDisableMode:Value : 1
	Bit 3 : en configuration IR	TransRemoteConfid:Value : 1
	Bit 5 : switch persistant	NetPersistentSwitch:Value : 1
	Bit 6 : mode émulation	NetEmulationMode:Value : 1
	Bit 7 : en maintenance	TransMaintenanceMode:Value: 1
FlameIR	FlameIR:Value : 1
détection de flamme par infrarouge
FlameUV	FlameUV:Value : 1
détection de flamme par ultraviolet

Dans le but de pouvoir permettre à SIMTRONICS SAS d'exploiter mon travail après la fin de mon stage, il m'a fallu, après avoir complètement réalisé le mode de démonstration, optimiser le mode OPC de façon à avoir le moins de variables externes possibles.

En effet, les variables dites « externes » sont en réalité les variables liées à des variables OPC du serveur OPC.

Par ailleurs, dans le cas de PCVUE, le prix du logiciel dépend du nombre de variables externes utilisées.

C'est pourquoi l'optimisation est une étape importante dans le but de réduire au maximum le coût financier de la supervision.

Pour le mode OPC de mon projet, nous avons donc décidé de travailler uniquement en bytes, permettant dans un premier temps de réduire le nombre de variables externes.

Par exemple, pour la variable qui permet de retourner la valeur de la mesure du capteur.

On crée la variable Measure qui sera associée à la variable externe OPC du serveur ICARE : net[255].node[4353].nvo_LifeSignal!ICARE_Gas!Bytes!Measure

Via le configurateur, on émule une mesure qui va se répercuter sur le serveur OPC

La valeur est repercutée sur le client OPC qui nous permet de vérifier si le serveur OPC a bien pris en compte la nouvelle valeur :

On a lié la variable measure au barre graphe sur la vue de détails du capteur sur PCVUE

Le serveur OPC répond bien à la supervision, le principe reste le même pour tout le reste du développement.

Conclusion

Ce stage pratique au sein de l'entreprise Simtronics SAS m'a permit de mettre en pratique les connaissances acquises au cours de la formation théorique à la faculté des sciences de St Jérôme.

J'ai pu approfondir ces compétences et en acquérir de nouvelles tant au niveau du développement sur d'autres superviseurs que dans la méthodologie de réalisation.

Le stage m'a offert la possibilité d'intégrer une équipe dynamique qui m'a guidé tout au long de la réalisation de mon projet. J'ai pu vérifier mes compétences au sein de cette équipe dans laquelle l'adaptation a été aisée et où j'ai pu évoluer tout au long de mon stage. Le développement des compétences a été possible grâce a un partage de savoir entre les différents membres de l'entreprise.

Le stage m'a offert une expérience intérressante tant au point de vue technique (développement, réalisation) qu'au point de vue humain (travail et coordination en équipe).

Les outils de développement convenaient parfaitement au contenu du programme qui nous a été proposé par les enseignants à la faculté des sciences de St Jérôme ainsi qu'au lycée du Rempart.