CIRCUTOR EDS Series - Manuel (Page 4)

EDS
M98237501-02-13A
http://x.x.x.x/services/user/records.xml?begin=010320110000
00?end=31032011000000?var=dispositivo.variable?period=9
00
http://nombre_dhcp/services/user/records.xml?begin=010320
11000000?end=31032011000000?var=dispositivo.variable?p
eriod=900
<recordGroup>
<period> … </period>
<record>
<dateTime> ... </ dateTime >
<field>
<id> ... </id>
<value> ... </value>
</field>
</record>
…
</recordGroup>
- recordGroup : champ qui identifie le XML comme réponse
à la demande de registres de variables
- period : période de registre ; temps entre registres
- record : identifie chacun des enregistrements (dateTime :
date et heure de l’échantillon
- field : registre valeur standard (pour d’autres valeurs,
consulter le manuel PS)
- value : valeur de la variable lors de la demande
Historique des événements
Comme montré dans le présent manuel d’utilisateur, à travers
l’Éditeur PowerStudio / Scada, il est possible de configurer
des événements ou alarmes, dans le dispositif EDS et de les
enregistrer dans sa mémoire interne.
Avec la demande suivante, l’utilisateur peut demander
l’historique d’événements entre deux dates définies.
Chaque
événement que l’on veut demander avec une demande
d’historiques, sera défini comme ?id=nom_événement
Lorsqu’on souhaite indiquer seulement la date, le format est
DDMMAAAA ; lorsqu’on veut spécifier la date et heure, c’est
DDMMAAAAHHMMSS. Tant la date que l’heure, doivent être
indiquées en UTC (Universal Coordinated Time).
http://x.x.x.x/services/user/events.xml?begin=0103201100000
0?end=31032011000000?id=nombre_suceso?
http://nombre_dhcp/services/user/events.xml?begin=0103201
1000000?end=31032011000000?id=nombre_suceso?
<main>
<recordGroup>
<id> ... </id>
<record>
<date> … </date>
<eventId> … </eventId>
<annotation> … </annotation>
<value> … </value>
</record>
..
</recordGroup >
…
<main>
- main : champ qui identifie le XML comme demande
- recordGroup : champ qui groupe les registres d’un
événement
- id : identificateur de l’événement
- record : identifie chacun des champs
- date : date et heure de l’événement
- eventId : identificateur de l’événement
- annotation : annotation de l’événement
- value : valeur de l’événement
ON : événement actif
OFF : événement inactif
ACK : événement reconnu
Événements d’un dispositif
Retourne l’information des événements enregistrés d’un ou
plusieurs dispositifs entre les dates « begin » et « end ».
Chacun des dispositifs dont on souhaite obtenir une
information doit être incluse comme ?id=dispositif
http://x.x.x.x/services/user/records.xml?begin=010320110000
00?end=31032011000000?id=dispositivo?
http://nombre_dhcp/services/user/records.xml?begin=010320
11000000?end=31032011000000?id=dispositivo?
Lorsqu’on souhaite indiquer seulement la date, le format est
DDMMAAAA ; lorsqu’on veut spécifier la date et heure, c’est
DDMMAAAAHHMMSS. Tant la date que l’heure, doivent être
indiquées en UTC (Universal Coordinated Time).
<main>
<recordGroup>
<device> ... </device>
<record>
<dateTime> … </dateTime>
<field>
<id> … </id>
<value> … </value>
</field>
…
</record>
..
</recordGroup >
…
</main>
- main : champ qui identifie le XML comme demande
- recordGroup : champ qui groupe les registres d’un
événement
- device : dispositif auquel se réfèrent les registres
- record : identifie chacun des champs
- dateTime : date et heure de l’événement
- field : identifie chacun des champs
- id : identificateur
- value : valeur de l’événement
Événements actifs
EDS dispose d’un service XML d’événements actifs dont
l’objectif est qu’un agent ou un système d’intégration externe
peut être enregistré comme auditeur (listener) et enregistrer
les événements ou alarmes qui se succèdent dans
l’équipement.
L’équipement maintient une liste de diffusion avec des
utilisateurs actifs, auxquels il envoie les événements qui se
produisent sous forme locale, à travers la création des
événements.
4.3.1.5.- Commandes de test
Avant de commencer la mise en oeuvre du système
d’événements actifs, et dans l’objet de vérifier la connectivité
entre les deux systèmes, il existe une série de demandes de
test type PUT entre le listener (auditeur) et producer (moteur
à distance) et vice-versa, dont l’objectif est de tester et
d’assurer la connectivité entre les deux systèmes.
Pour que le listener puisse vérifier la connectivité avec le
moteur à distance (producer), il peut envoyer cette demande
avec le corps suivant du message :
http://ip_producer:port/services/user/testListener.xml
<listener>
<ip>ip_listener</ip>
<port>80</port>
</listener>
- ip_listener : définit l’IP de l’auditeur, a laquelle le producer
envoie la demande de réponse
- port : définit le port de l’auditeur, à travers lequel le
producer envoie la demande de réponse
Le producer (moteur à distance) en recevant la demande de
test de la part du listener, retourne la demande suivante :
http://ip_listener:port/services/user/testProducer.xml
Demande à laquelle l’auditeur doit répondre avec un « reçu »
(200).
4.3.1.6.- Registre d’un listener (auditeur)
Tout agent ou listener qui souhaite s’enregistrer dans un
moteur à distance ou producer, afin de recevoir les
événements produits par ledit moteur en temps réel, doit
réaliser la demande suivante PUT au producer avec ledit
format :
http://ip_producer:port/services/user/listener.xml
Cette demande doit contenir le corps suivant du message,
dans lequel sont définis l’auditeur et le type de données à
recevoir :
<listener>
<ip>ip_listener</ip>
<port>80</port>
<all>T</all>
</listener>
- ip_listener : l’IP de l’auditeur est définie, à laquelle le
producer envoie les événements qui sont générés
- port : définit le port de l’auditeur, à travers lequel le
producer envoie les événements qui sont générés
La section all définit le type d’information auquel on souhaite
accéder (True / False).
- True : indique au producer d’envoyer toute la liste
d’événements actifs dont il dispose
- False : indique au producer qu’il envoie seulement les
changements survenus depuis la dernière demande
4.3.1.7.- Effacement ou perte de la liste des auditeurs
Le producer peut perdre ou éliminer la liste des auditeurs,
totalement ou partiellement, pour différentes raisons :
- Le listener ne répond pas : lorsque de nouveaux
événements se produisent, ou des changements dans
lesdits événements, le producer informe
instantanément toute sa liste d’auditeurs. Le producer,
devant un problème de communication avec un
auditeur, réalise jusqu’à un total de cinq tentatives dans
l’envoi de l’information. Dans le cas où l’auditeur ne
répondrait pas à ces demandes, le producer le radie de
sa liste de diffusion.
- Le producer a été réinitialisé ou a cessé de fonctionner
temporairement : si le producer reçoit une mise à jour
ou génère un reset pour toute raison (mise à jour de
firmware, perte d’alimentation, etcétéra), il perd toute la
liste d’auditeurset, dès cet instant, il cesse d’envoyer
des événements aux auditeurs antérieurement
associés.
4.3.1.8.- Maintenance des listes de auditeurs (alive)
Étant donné que les raisons pour lesquelles la liste des
auditeurs peut se voir affectée sous forme partielle, ou totale,
peuvent être plusieurs, il est nécessaire que le système
d’intégration externe mette en oeuvre un système de test
(alive) contre le producer, pour s’assurer que son IP se
maintient active sous une forme durable sur sa liste de
diffusion.
Il est recommandé que ce système de test soit réalisé sous
forme automatique et avec une périodicité non supérieure à
10 minutes entre l’envoi des trames de test. Le système de
test (alive) est basé sur la mise à jour de l’IP de l’auditeur, à
nouveau contre le producer, bien que demandant uniquement
les changements dans les événements (False) :
http://ip_producer:port/services/user/listener.xml
Cette demande doit contenir le corps suivant du message,
dans lequel est à nouveau défini l’auditeur et le type de
données à recevoir :
<listener>
<ip>ip_listener</ip>
<port>80</port>
<all>F</all>
</listener>
- Dans le cas où l’application externe d’intégration se serait
maintenue inactive durant une longue période de temps, il
est recommandable de demander au producer l’envoi de
tout la liste des événements actifs, à travers une demande
True. De cette façon, l’auditeur dispose à nouveau de toute
l’information perdue durant le temps d’inactivité.
4.3.1.9.- Réception de événements
Lorsqu’un changement se produit dans les événements, la
demande que le producer génère contre la liste de diffusion
des auditeurs, informant des événements sera du type PUT
avec la syntaxe suivante :
http://ip_oyente:port/services/user/producer.xml
La demande contient dans le corps du message l’information
suivante sous format XML ; information relative aux
événements produits :
<producer>
<all>T/F</all>
<event>
<id>driverId.driverId.driverId…eventId</id>
<name>Événement 1</name>
<description>Description 1</description>
<annotation>Annotation 1</annotation>
<dateTime>25112010201034</dateTime>
<whyFired>ACTIVATION</whyFired>
</event>
<event>
<id>driverId.driverId.driverId…eventId</id>
<name>Événement 2</name>
<description>Description 2</description>
<annotation>Annotation 2</annotation>
<dateTime>25112010201034</dateTime>
<disabledDateTime>25112010201103</
disabledDateTime >
<whyFired>DEACTIVATION</whyFired>
</event>
…
</producer>
- all : tous les événements (True) ou changements (False)
- event-Id : producer et identificateur de l’événement
- whyFired : ACTIVATION, DÉSACTIVATION
Notes relatives aux événements actifs :
- Note : si le producer a mis en œuvre une authentification
http par utilisateur et un mot de passe, celle-ci doit être mise
en œuvre dans l’auditeur de la part de l’utilisateur.
Forçage de variables