Circutor EDS Bedienungsanleitung Seite 4

4.3.4.2.- Momentaner Wert aller Variablen
Anforderung des momentanen Werts aller Variablen des
Geräts (wenn die Informationen mehrerer Geräte erforderlich
sind, die restlichen Anforderungen anschließend mit id=gerät?
verketten):
http://x.x.x.x/services/user/values.xml?id=Gerät?
v
http://Name_dhcp/services/user/ alues.xml?id=Gerät?
<values>
<variable>
<id> ... <id>
<value> ... </value>
</variable>
...
</values>
- id: Kennung der Variablen
- value: Wert der Variablen zum Zeitpunkt der Anforderung
4.3.5.- Historische Daten
Anforderung der Registers mit historischen Daten einer
inkrementalen Variablen. Als Antwort erhält man die
registrierten Informationen einer oder mehrerer Variablen
zwischen dem Datum „begin" (Anfang) und „end" (Ende). Die
einzelnen Variablen, über die Informationen angefordert
werden, müssen in der Anforderung als ?var=gerät.variable
enthalten sein.
Wenn nur das Datum angegeben werden soll, ist das Format
TTMMJJJJ; wenn Datum und Uhrzeit angegeben werden
sollen, ist das Format TTMMJJJJSSMMSS. Sowohl Datum
als auch Uhrzeit müssen in UTC (Universal Coordinated
Time, Weltzeit) angegeben werden.
Die Gruppierungsperiode (period) kann nach verschiedenen
Kriterien definiert werden:
- Wert in Sekunden (z. B. 900): Wert in Sekunden, in denen
die Daten gruppiert werden
- ALL: die Daten werden in einem einzigen Wert gruppiert
- AUTO: die Gruppierung erfolgt automatisch mit den
vordefinierten Intervallen gemäß „begin" und „end"
- FILE: die Daten werden nicht gruppiert. Die Daten werden
so zurückgemeldet, wie sie in der Datenbank registriert sind
- wenn der Parameter period in der Anforderung nicht
enthalten ist, wird er als Wert 0 betrachtet und die Daten
werden nicht gruppiert
http://x.x.x.x/services/user/records.xml?begin=010320110000
00?end=31032011000000?var=Gerät.variable?period=900
http://Name_dhcp/services/user/records.xml?begin=01032011
000000?end=31032011000000?var=Gerät.variable?period=9
00
<recordGroup>
<period> ... </period>
<record>
<dateTime> ... </ dateTime >
<field>
<id> ... </id>
<value> ... </value>
</field>
</record>
...
</recordGroup >
- recordGroup: Feld, mit dem der XMI als Antwort auf die
Anforderung von Variablenregistern gekennzeichnet wird
- period: Registerzeitraum; Zeitraum zwischen Registern
- record: Kennzeichnung der einzelnen Register (dateTime:
Datum und Uhrzeit der Ablesung
- field: Register Standardwert (sonstige siehe PS-Handbuch)
- value: Wert der Variablen zum Zeitpunkt der Anforderung
4.3.6.- Ereignishistorie
Wie dies in diesem Benutzerhandbuch beschrieben wird,
können mittels der Anwendung Editor PowerStudio / Scada
Ereignisse bzw. Alarme im EDS-Gerät konfiguriert werden,
um diese im internen Speicher zu speichern.
Mit der folgenden Anforderung kann der Benutzer die
Ereignishistorie zwischen zwei definierten Daten anfordern.
Jedes Ereignis, das mit einer Anforderung der Ereignishistorie
angefordert wird, wird als ?id=name_ereignis definiert.
Wenn nur das Datum angegeben werden soll, ist das Format
TTMMJJJJ; wenn Datum und Uhrzeit angegeben werden
sollen, ist das Format TTMMJJJJSSMMSS. Sowohl Datum
als auch Uhrzeit müssen in UTC (Universal Coordinated
Time, Weltzeit) angegeben werden.
http://x.x.x.x/services/user/events.xml?begin=0103201100000
0?end=31032011000000?id=Name_Ereignis?
http://Name_dhcp/services/user/events.xml?begin=01032011
000000?end=31032011000000? id=Name_Ereignis?
<main>
<recordGroup>
<id> ... </id>
<record>
<date> ... </date>
<eventId> ... </eventId>
<annotation> ... </annotation>
<value> ... </value>
</record>
...
</recordGroup >
...
<main>
- main: Feld, das den XML als Anforderung definiert
- recordGroup: Feld, wo die Ereignisse eines Ereignisses
gruppiert sind
- id: Kennung des Ereignisses
- record: Kennzeichnung der einzelnen Register
- date: Datum und Uhrzeit des Ereignisses
- eventId: Kennung des Ereignisses
- annotation: Notierung des Ereignisses
- value: Wert des Ereignisses
ON: Ereignis aktiv
OFF: Ereignis inaktiv
ACK: Ereignis quittiert
4.3.7.- Ereignis eines Geräts
Erhalten werden die registrierten Ereignisse eines oder
mehrerer Geräte zwischen den Daten „begin" (Anfang) und
„end" (Ende). Die einzelnen Geräte, von denen Informationen
erhalten werden sollen, müssen als ?id=gerät enthalten sein.
http://x.x.x.x/services/user/records.xml?begin=010320110000
00?end=31032011000000?id=Gerät?
http://Name_dhcp/services/user/records.xml?begin=01032011
000000?end=31032011000000? id=Gerät?
Wenn nur das Datum angegeben werden soll, ist das Format
TTMMJJJJ; wenn Datum und Uhrzeit angegeben werden
sollen, ist das Format TTMMJJJJSSMMSS. Sowohl Datum
als auch Uhrzeit müssen in UTC (Universal Coordinated
Time, Weltzeit) angegeben werden.
<main>
<recordGroup>
<device> ... </device>
<record>
<dateTime> ... </dateTime>
<field>
<id> ... </id>
<value> ... </value>
</field>
...
</record>
...
</recordGroup >
...
</main>
- main: Feld, das den XML als Anforderung definiert
- recordGroup: Feld, wo die Ereignisse eines Ereignisses
gruppiert sind
- device: Gerät, auf das sich die Register beziehen
- record: Kennzeichnung der einzelnen Register
- dateTime: Datum und Uhrzeit des Ereignisses
- field: Kennzeichnung der einzelnen Felder
- id: Kennung
- value: Wert des Ereignisses
4.3.8.- Aktive Ereignisse
Der EDS verfügt über einen XML-Dienst für aktive Ereignisse,
dessen Zweck es ist, dass sich ein Mittler oder ein externes
Integrationssystem als Zuhörer (listener) registrieren und die
Ereignisse oder Alarme, die am Gerät auftreten, aufzeichnen
kann.
Das Gerät pflegt eine Verteilerliste mit aktiven Benutzern, an
die die lokal auftretenden Ereignisse
Ereigniserstellung gesendet werden.
4.3.8.1.- Testbefehle
Vor Beginn der Implementierung des Systems für aktive
Ereignisse und um die Verbindung zwischen den beiden
Systemen überprüfen zu können, gibt es eine Reihe von
Testanforderungen Typ PUT zwischen dem listener (Zuhörer)
und dem producer (entfernten Erzeuger) und umgekehrt,
womit die Verbindung zwischen beiden Systemen getestet
und gewährleistet werden soll.
Damit der listener die Verbindung zum entfernten Erzeuger
(producer) überprüfen kann, kann diese Anforderung mit
folgendem Meldungskörper gesendet werden:
http://ip_producer:port/services/user/testListener.xml
<listener>
<ip>ip_listener</ip>
<port>80</port>
</listener>
- ip_listener: Definition der IP als Zuhörer, an den der
producer die Antwortanforderung sendet
- Port Definition des Zuhörer-Ports, über den der producer
die Antwortanforderung sendet
Der producer (entfernte Erzeuger) setzt bei Empfang der
Testanforderung durch den listener die folgende Anforderung
ab:
http://ip_producer:port/services/user/testListener.xml
Diese Anforderung muss der Zuhörer mit „empfangen" (200)
beantworten.
4.3.8.2.- Registrierung eines listener (Zuhörers)
Jeder Mittler bzw. listener, der bei einem entfernten Erzeuger
bzw. producer registriert werden soll, muss zum Erhalten der
beim entfernten Erzeuger aufgetretenen Ereignisse in Echtzeit
die folgende Anforderung PUT an den producer mit folgendem
Format senden:
http://ip_producer:port/services/user/listener.xml
Diese Anforderung muss den folgenden Meldungskörper
aufweisen, worin der Zuhörer und Datentyp, der erhalten
werden soll, definiert werden:
<listener>
<ip>ip_listener</ip>
<port>80</port>
<hasValue> T </hasValue>
</listener>
- ip_listener: Definition der IP als Zuhörer, an den der
producer die aufgetretenen Ereignisse sendet
- port: Definition des Zuhörer-Ports, über den der producer
die aufgetretenen Ereignisse sendet
Der Abschnitt all definiert den Informationstyp, auf den
zugegriffen werden soll (True / False).
- True: weist den producer an, die komplette Liste der
aktiven Ereignisse zu senden, über die er verfügt
- False: weist den producer an, dass er nur die seit der
letzten Anforderung aufgetretenen Änderungen sendet
4.3.8.3.- Löschen oder Verlust der Zuhörerliste
Der producer kann die Zuhörerliste aus verschiedenen
Gründen ganz oder teilweise verlieren oder eliminieren:
- Der listener antwortet nicht: Wenn neue Ereignisse oder
Änderungen an diesen Ereignissen auftreten, informiert der
producer sofort seine komplette Zuhörerliste. Bei einem
Kommunikationsproblem mit einem Zuhörer führt der
producer insgesamt fünf Neuversuche für das Senden der
Informationen durch. Wenn der Zuhörer nicht auf diese
Anforderungen reagiert, schließt ihn der producer aus
seiner Verteilerliste aus.
- Der producer
vorübergehend ausgefallen: Wenn der producer eine
Aktualisierung erhält oder aus irgendeinem Grund ein
Reset erfährt (Aktualisierung der Firmware, Ausfall der
Stromversorgung usw.), verliert er seine Zuhörerliste und
ab diesem Moment sendet er keine Ereignisse mehr an die
vorher verknüpften Zuhörer.
4.3.8.4.- Pflege der Zuhörerliste (alive)
Weil es verschiedene Ursachen dafür gibt, dass die
Zuhörerliste ganz oder teilweise beeinträchtigt werden kann,
muss das externe Integrationssystem ein Testsystem (alive) in
Bezug auf den producer implementieren, um sicherzustellen,
dass seine IP in der Verteilerliste dauerhaft aktiv bleibt.
Es wird empfohlen, dieses Testsystem automatisch und mit
einer Häufigkeit von nicht mehr als 10 Minuten zwischen dem
Senden der Testdatensätze einzurichten. Das Testsystem
(alive) beruht auf der Aktualisierung der IP des Zuhörers
wiederum gegen den producer, obwohl nur die Änderungen
an den Ereignissen (False) angefordert werden:
http://ip_producer:port/services/user/listener.xml
über die
Diese Anforderung muss den folgenden Meldungskörper
aufweisen, worin erneut der Zuhörer und Datentyp, der
erhalten werden soll, definiert werden:
<listener>
EDS
wurde zurückgesetzt oder ist
M98237501-06-13A