Analyse fonctionnelle Gestion Technique Centralisée Plate

Transcription

Université de Strasbourg
Analyse fonctionnelle
Gestion Technique Centralisée
Université De Strasbourg
Plate-forme Archestra
HISTORIQUE DU DOCUMENT
Date
Rév.
16/11/09
00
19/07/10
01
Objet de la révision
Diffusé
Rédigé
Vérifié
Approuvé
Création
Non
YW
JLA
DB
Mise à jour des vues
OUI
JLA
JLA
JLA
671854_UDS_AF_GTC_Rev01.doc
Page 1/34
SOMMAIRE
1.
OBJET DU DOCUMENT................................................................................................... 4
1.1.
1.2.
1.3.
1.4.
2.
3.
ARCHITECTURE SYSTEME ............................................................................................ 5
GENERALITES ................................................................................................................. 6
3.1.
3.2.
3.2.1.
3.2.2.
3.3.
4.
4.1.1.
4.1.2.
Objets de base ..................................................................................................... 6
Instances.............................................................................................................. 8
ZONE DES VARIABLES ................................................................................................. 9
COMPTES UTILISATEURS ........................................................................................... 10
Login/Logout ...................................................................................................... 10
Niveau de conduite ............................................................................................ 10
ARCHITECTURE GRAPHIQUE...................................................................................... 11
5.1.
5.1.1.
5.1.2.
5.1.3.
5.1.4.
5.2.
5.3.
5.4.
5.4.1.
5.4.2.
6.
COMMUNICATION AVEC LES AUTOMATES ...................................................................... 6
ARCHITECTURE DES VARIABLES................................................................................... 6
GESTION DES UTILISATEURS ..................................................................................... 10
4.1.
5.
INTRODUCTION .......................................................................................................... 4
PRE REQUIS .............................................................................................................. 4
DOCUMENTS ASSOCIES .............................................................................................. 4
GLOSSAIRE ............................................................................................................... 4
OSSATURE DES SYNOPTIQUES .................................................................................. 11
Bandeau haut.....................................................................................................11
Vue..................................................................................................................... 12
BP ...................................................................................................................... 13
Bandeau Bas...................................................................................................... 13
CONVENTION DE DENOMINATION DES SYNOPTIQUES.................................................... 14
CHAINAGE DES VUES ................................................................................................ 16
DEFINITION DES TYPES DE SYNOPTIQUES ................................................................... 17
Vues de navigation............................................................................................. 17
Vues process ..................................................................................................... 18
LES MODELS D’OBJETS ............................................................................................... 19
6.1.
6.2.
6.3.
6.4.
6.5.
6.6.
6.7.
6.8.
6.9.
6.10.
6.11.
REGLE DE NOMMAGE DES MODELS ............................................................................ 19
BANDEAU HAUT ....................................................................................................... 20
BANDEAU BAS ......................................................................................................... 20
LOGIN ..................................................................................................................... 21
POMPE.................................................................................................................... 22
VENTILATEUR .......................................................................................................... 24
REGISTRE ............................................................................................................... 26
VANNE 2 VOIES ........................................................................................................ 28
VANNE 3 VOIES ........................................................................................................ 29
DISJONCTEUR .......................................................................................................... 30
MESURE.................................................................................................................. 31
Page 2/34
6.12.
6.13.
6.14.
SAISIE CONSIGNE ..................................................................................................... 32
REGULATEUR .......................................................................................................... 33
DIRIS ...................................................................................................................... 34
Page 3/34
1. OBJET DU DOCUMENT
1.1. INTRODUCTION
L’ Université De Strasbourg souhaite installer un système de supervision des installations techniques
des bâtiments qui sont sous sa responsabilité.
Le système de supervision est développé sur la plate-forme Archestra de Wonderware.
Le but de ce document est donc de définir les spécifications détaillées des principes de réalisation et
d’animation des synoptiques, ainsi que les organigrammes fonctionnels des principales fonctions
assurées par le système de supervision.
1.2. PRE REQUIS
Aucun.
1.3. DOCUMENTS ASSOCIES
Aucun.
1.4. GLOSSAIRE

UDS
GTC
Abyla
Archestra
: Université De Strasbourg
: Gestion Technique Centralisée
: Logiciel de gestion du patrimoine
: Plateforme de supervision Wonderware
Page 4/34
2. ARCHITECTURE SYSTEME
Le système de supervision est installé sur un serveur « WINDOWS 2003 server R2 ».
La visualisation de la supervision se fait via l’ouverture de sessions TS sur ce serveur.
Serveur 1 (SQL)
- Windows Server 2003 R2 English
- SQL Server 2005 English
- Wonderware System Plateform
- Bootstrap
- Historian Server 9.0 (12K)
- Archestra Global Repository (GR)
- FsGateway (passerelle pour Alert)
- Alert + Modem GSM
- IntraVue
Serveur 2 (TS via Web)
Serveur 3 (I/O / RT)
- Windows Server 2003 R2 English - Windows Server 2003 R2 English
- IIS + TS Web services
- Bootstrap
- Bootstrap
- Archestra App.Server (25K)
- Historian Server (Redondant)
- Device Integ.Server
- Archestra App.Server (Redondant) - Historian Server (Redondant)
- Device Integ.Server (Redondant)
- Prog-Time
- Intouch TS + 5 Licences Client TS
Redondance
histo
5 Postes TS en
simultanés
« client léger »
Poste Supervision
- Windows XP Service Pack 3
- Bootstrap
- Wonderware Development Studio
- Intouch Development (60K)
- Archestra Integrated Development Environnement
(IDE)
- Intouch 10+ (60K)
Redondance
I/O
Hors
fournitures
Ecran tactile
Réseau terrain par métiers automate
12 automates
WAGO
16 automates
SATCHWELL
Page 5/34
3. GENERALITES
3.1. COMMUNICATION AVEC LES AUTOMATES
Pour les équipements SATCHWELL, dont le protocole ne supporte pas le Modbus TCP, la
communication passe par un serveur OPC.
Pour les nouveaux équipements, le protocole de communication est le Modbus/TCP. Le driver natif
Wonderware est utilisé pour la connexion aux nouveaux équipements.
Ce driver se configure dans la console de management du Système (SMC)
.
3.2. ARCHITECTURE DES VARIABLES
La plateforme Archestra offre une architecture objet permettant une hiérarchisation des composants
de l’application. Chaque variable est une instance d’un objet standard.
3.2.1. Objets de base
Un objet standard peut être dérivé sur plusieurs niveaux et chaque niveau hérite des paramètres de
son père. De ce fait, tous les programmes, les variables, les alarmes sont définis au niveau le plus
haut.
Exemple : Les objets Actionneurs
Pour les objets Actionneurs l’objet de base est l’objet $aaActionneurs. Dans notre cas, l’application
comporte plusieurs types d’actionneurs, les Moteurs ($aaMoteurs) et les Vannes ($aaVannes). Ces
objets sont dérivés de $aaActionneurs.
Dans le groupe Moteurs, chaque type de moteur possible est dérivé de $aaMoteurs. Ce sont ces
objets qui sont instanciés et utilisés dans les Vues de supervision.
Lors d’une modification sur l’objet $aaActionneurs, tous les objets Fils sont mis à jour.
Page 6/34
Les objets de base sont les suivants :
-
$aaActionneurs
$aa OPCClient
$aaConsigne
$aaDivers
$aaDiversBits
$aaDiversMots
$aaDiversReels
$aaMesures
$aaRégulateurs
$aaAreaSyno_FdPStandard
$aaConfigApplication
Page 7/34
3.2.2. Instances
Chaque variable de l’application est une instance d’un objet de base. Le nom de l’instance ainsi que
ses propriétés tel que son index dans l’automate ou le type d’objet sont renseignées dans une base
de données de gestion de patrimoine ABYLA. La base de données peut être exportée afin de
permettre la création automatique des instances dans Archestra.
Renseignés
dans la base
de données
Page 8/34
3.3. ZONE DES VARIABLES
Les filtres sur les alarmes sont faits par rapport aux Zones (Area) dans lesquelles se trouvent les
variables.
A chaque zone correspond une vue de la supervision. Les alarmes s’affichant dans le bandeau
d’alarme proviennent uniquement des variables contenues dans la zone ou les sous-zones de celleci.
La structure en Zone permet :
Î Une navigation correspondant à la réalité.
Î Une définition des bâtiments telle que dans ABYLA.
Î Une application de filtre sur les alarmes en fonction de la localisation.
Page 9/34
4. GESTION DES UTILISATEURS
4.1. COMPTES UTILISATEURS
Les comptes utilisateurs utilisent la stratégie Windows pour la gestion des mots de passe. Un niveau
de conduite est associé à chaque profil utilisateur. Chaque profil utilisateur est attaché à un groupe
utilisateur Windows.
4.1.1. Login/Logout
Pour pouvoir utiliser l’application les utilisateurs doivent s’identifier avec le login et le mot de passe
du domaine Windows.
A chaque compte utilisateur est associé un niveau de conduite de l’application. Le niveau de conduite
est configuré par la sécurité ArchestrA via une interface de configuration. En plus du niveau de
conduite, les droits sur chaque élément de la plate forme sont configurés (accès en développement,
utilisation des objets, …). Cela permet de verrouiller ou non l’utilisation des objets en fonction des
droits utilisateur.
4.1.2. Niveau de conduite
Les niveaux de conduite sont utilisés pour hiérarchiser les droits des utilisateurs. 9999 niveaux de
conduite sont possibles. Les niveaux utilisés sont répartis de la façon suivante :
Niveau
0
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
…
…
9999
Visiteur
Détail
(Aucune action possible)
Superviseur
(Uniquement visu, - les paramètres)
GTC_ Superviseur
Technicien
(Uniquement visu)
GTC_ Technicien
Administrateur (Toutes actions)
Grp Windows
GTC_ Administrateur
Page 10/34
Le profil administrateur : donne accès à tous les éléments du superviseur : Caractéristiques
techniques de tous les bâtiments, visualisation de toutes les pages graphiques, paramétrage des
points. Ce profil sera accessible au personnel technique de la Division Logistique Immobilière.
Le profil Technicien : filtre une partie des informations du superviseur : Caractéristiques techniques
de tous les bâtiments, mais par contre aucune modification des paramétrages n’est possible. Accès à
toutes les vues graphique, courbes d’évolution des températures.
Le profil superviseur : donne accès uniquement aux pages graphiques du bâtiments qui le concerne.
Aucune modification de paramétrage n’est possible
5. ARCHITECTURE GRAPHIQUE
L’application est constituée de trois écrans pour le poste fixe et d’un écran pour les sessions TS.
5.1. OSSATURE DES SYNOPTIQUES
Les synoptiques sont constitués de Quatre zones telles que ci-dessous :
1680
Zone Bandeau haut
Zone
BP
Zone Vue
1050
Zone Bandeau Bas
5.1.1. Bandeau haut
Cette zone contient le Logo, le titre de la vue et permet aux utilisateurs d’imprimer la vue courante.
Page 11/34
5.1.2. Vue
Cette zone accueille l’ensemble des synoptiques process et plan de l’application.
Page 12/34
5.1.3. BP
Cette zone accueille les boutons d’appel du Menu, de retour à la vue précédente, d’appel des
logiciels Intravue, Alert, Prog’ Time, Abyla et d’une vue de synthèse des alarmes.
5.1.4. Bandeau Bas
Cette zone accueil le bandeau d’alarmes, un bouton d’acquit et un bouton de chaînage vers la vue
associée à l’alarme sélectionnée. Il permet aux utilisateurs de se logger avec leur compte Windows.
Page 13/34
5.2. CONVENTION DE DENOMINATION DES SYNOPTIQUES
Les synoptiques sont créés au niveau des zones (AREA). Les noms des area sont les mêmes que les
déclarations faites dans ABYLA. Pour des raisons d’homogénéité ces noms sont propagés dans toute
l’application.
Exemple de l’area « Université_de_Strasbourg » :
Au niveau de l’IDE, l’area et sa représentation graphique (Synoptique) porte le même nom.
Au niveau d’InTouch, les Windows portent le même nom que les area.
Seul un index est ajouté. Il indique le numéro de l’écran (1, 2 ou 3).
Les noms des objets
sont les mêmes.
Page 14/34
Pour l’area « Université_de_Strasbourg », les synoptiques à créer dans InTouch sont :
-
Université_de_Strasbourg_1
(Pour l’écran 1)
(Pour l’écran 2)
(Pour l’écran 3)
Page 15/34
5.3.
CHAINAGE DES VUES
Le chaînage des vues est fait via des boutons d’appel au niveau des objets ArchestrA.
Le bouton d’appel ouvre le synoptique InTouch. Lors de son ouverture, le synoptique scrute la
valeur de la variable InTouch « Vue_Ecran_x » (x = 1, 2 ou 3 en fonction de l’écran de travail).
Si la variable contient un nom de synoptique alors il ferme l’ancien synoptique est stock sont
propre nom dans la variable pour la prochaine ouverture.
Exemple pour un chaînage sur l’écran 1 :
ArchestrA
InTouch
Attente action
opérateur sur
écran 1
Clic Bp chaînage de vue
Ouverture vue
InTouch
Sur écran 1
Exécution du
Script sur
ouverture vue
Variable text
Fermeture de
l’ancienne vue
Vue_Ecran_1
Mémorisation nom
vue
Page 16/34
5.4. DEFINITION DES TYPES DE SYNOPTIQUES
Chaque synoptique bénéficie d’un bouton permettant l’impression directe sur l’imprimante par défaut.
5.4.1. Vues de navigation
Elles permettent d’aller de la vue d’ensemble jusqu'à une vue process. Il suffit de cliquer sur la bulle
de la zone souhaitée.
Retour à la
vue
précédente.
Retour à la vue de masse
« UNIVERSITE DE STRASBOURG »
Bouton de navigation dans
les vues. Clignote en
ROUGE si un défaut est
présent sur un des
équipements qu’il contient.
Ouverture
d’AbylaWeb
Ouverture
des autres
outils.
Ouverture
vue
d’Alarmes
Affiche les alarmes filtrées en
fonction de la zone
représentée par le synoptique.
Chaînage vers la vue
correspondant à
l’alarme sélectionnée.
Tulipe. Indique si une alarme
est présente dans l’université.
Cette information n’est pas
filtrée en fonction de la zone.
Permet aux utilisateurs de
s’identifier sur l’application à
partir de leurs comptes
utilisateur Windows.
Page 17/34
5.4.2. Vues process
Les vues process permettent la visualisation et le pilotage des installations de la supervision.
Acquit des alarmes de la
vue process. Ce bouton
s’affiche en fonction d’une
animation de visibilité.
La visibilité du bouton « Acquit » se configure sur l’area avec par la «Custom Propertie »
« Synoptique_Standard.Bandeau_bas.BP_Ack_Alarmes.BpVisible » = TRUE / FALSE.
Elles sont construites de la même façon que les vues de navigation.
Page 18/34
6. LES MODELS D’OBJETS
6.1. REGLE DE NOMMAGE DES MODELS
Les models sont nommés suivant le principe suivant :
$aa[Type Model]_[Orientation]
$[Type Model]_[Orientation]
Type Symbole
Orientation
Pour les model de bases
Pour les model dérivés
: définit le nom du model de l’objet (Exemple : Pompe, Régulateur)
: sur 2 caractères maxi (H/V, D/G), définit la position de l’objet dessiné

H : Horizontale
V : Verticale
G : Gauche
D : Droite
Page 19/34
6.2. BANDEAU HAUT
Le bandeau affiche le nom de la vue en cours.
6.3. BANDEAU BAS
Le Bandeau affiche La liste des alarmes filtrées en fonction de la zone en cours d’affichage. Les
alarmes sont classées par priorité.
Classement des priorités :

Zone d’affichage
des alarmes
Priorité 1 (Forte)
Priorité 2 (Moyenne)
Priorité 3 (Faible)
: ROUGE (Priorités de 0 à 299)
: JAUNE (Priorités de 300 à 599)
: VERT (Priorités de 600 à 899)
Chainage vers la
vue de l’alarme
sélectionnée.
Acquit des alarmes de la
vue process. Ce bouton
n’est visible que dans les
vues process.
Tulipe : indique si
une alarme de
priorité 1, 2 ou 3
est présente au
minimum
Affiche le nom de l’utilisateur
en cours, la date et l’heure.
Les boutons permettent la
connexion déconnexion des
utilisateurs.
Page 20/34
6.4. LOGIN
Se symbole permet aux utilisateur de s’identifier sur l’application pour.
Sur clique sue le bouton
droits de conduite.
Sur clique sue le bouton
l’utilisateur courant est déconnecté de l’application est perd ses
une popup de login s’ouvre.
Page 21/34
6.5. POMPE
Le symbole pompe existe dans les quatre directions. Ce symbole permet de visualiser l’état de
fonctionnement des pompes.
Description du symbole :
Pompe à l’arrêt.
Pompe en marche.
Pompe en défaut (Rouge Clignotant).
Pompe à l’arrêt et en mode MANU (Représenté par le carré Bleu).
Page 22/34
L’action clic sur une pompe ouvre la fenêtre de diagnostique suivante :
Infos :
Informations
moteur
sur
Historique :
Courbe pompe
Page 23/34
le
6.6. VENTILATEUR
Ce symbole permet de visualiser l’état de fonctionnement des ventilateurs
Ventilateur à l’arrêt.
Ventilateur en marche.
Ventilateur en défaut (Rouge Clignotant)
Ventilateur à l’arrêt et en mode MANU (Représenté par le carré Bleu).
Sur Clic sur le ventilateur une fenêtre de diagnostique s’ouvre (Fenêtre identique aux pompes).
Page 24/34
Infos :
Informations
moteur
sur
Historique :
Courbe pompe
Page 25/34
le
6.7. REGISTRE
Ce symbole permet de visualiser l’état d’un registre.
Registre à l’arrêt.
Registre en marche.
Registre en défaut (Rouge Clignotant)
Registre à l’arrêt et en mode MANU (Représenté par le carré Bleu).
Page 26/34
Si le mode manu est
interdit pour l’actionneur,
il est barré en rouge.
Page 27/34
6.8. VANNE 2 VOIES
Le symbole vanne existe en verticale et horizontale Ce symbole permet de visualiser l’état de
fonctionnement des vannes.
Vanne fermée.
Vanne ouverte.
Vanne en défaut (Rouge fixe).
Vanne à l’arrêt et en mode MANU (Représenté par le carré Bleu).
Sur Clic sur la vanne une fenêtre de diagnostique s’ouvre (Fenêtre identique aux registres).
Page 28/34
6.9. VANNE 3 VOIES
Idem vanne 2 voies.
Page 29/34
6.10. DISJONCTEUR
Ce symbole permet de visualiser l’état de fonctionnement des disjoncteurs. L’état normal d’un
disjoncteur est contacte fermé.
Disjoncteur fermée (Pas de défaut).
Disjoncteur ouvert (en défaut).
Sur Clic sur la vanne une fenêtre de diagnostique s’ouvre.
Page 30/34
6.11. MESURE
Ce symbole permet de visualiser la valeur d’une mesure d’un automate.
: Affichage de la mesure avec sont unité sur font BLEU
Sur Clic sur la vanne une fenêtre de diagnostique s’ouvre.
Valeurs des seuils
d’alarmes.
Si les cases sont
cochées, alors l’alarme
seuil est activée.
Page 31/34
6.12. SAISIE CONSIGNE
Unit
Ce symbole permet de visualiser et se saisir des consignes ou paramètres analogiques d’une
installation.
Unit
: Affichage de la valeur de la consigne avec sont unité sur font JAUNE.
Sur Clic sur la consigne un clavier de saisie s’ouvre.
Page 32/34
6.13. REGULATEUR
Ce symbole permet de visualiser l’état d’une régulation. Lorsque les informations automate sont
disponibles il permet également de modifier le mode de fonctionnement régulateur.
Régulateur en Automatique
Régulateur en Manu
La valeur indique le pourcentage de la sortie du régulateur.
Sur Clic sur le régulateur une fenêtre de diagnostique s’ouvre :
Boutons de
modification du
mode de marche
Consigne du
mode
automatique
Saisie de la sortie
utilisée pour le mode
manuel
Saisie des
actions du
régulateur
Page 33/34
6.14. DIRIS
Ce symbole permet d’appeler une vue de diagnostic Diris.
Page 34/34