Histórico De Sucesos; Sucesos De Un Dispositivo; Sucesos Activos - Circutor EDS Guia De Inicio Rapido

El período de agrupación (period) podrá definirse por
diferentes criterios:
- valor en segundos (p.e. 900): valor en segundos en los que
se agrupan los datos
- ALL: los datos se agrupan en un único valor
- AUTO: la agrupación se realiza automáticamente con
intervalos predefinidos según "begin" y "end"
- FILE: no se agrupan los datos. Devuelve la información tal
y como se registra en la base de datos
- si el parámetro period no parece en la petición, se
considerará como valor 0 y no se agruparán los datos
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: campo que identifica al XML como respuesta
a la petición de registros de variables
- period: período de registro; tiempo entre registros
- record: identifica cada uno de los registros (dateTime:
fecha y hora de la muestra
- field: registro valor estándar (otros consultar manual PS)
- value: valor de la variable en el momento de la petición
4.3.6.- Histórico de sucesos
Tal y como se muestra en el presente manual de usuario,
mediante el Editor PowerStudio / Scada es posible configurar
eventos o alarmas, dentro del dispositivo EDS y registrarlos
en su memoria interna.
Con la siguiente petición, el usuario puede solicitar el
histórico de suceso entre dos fechas definidas. Cada suceso
que quiera pedirse con una petición de históricos se definirá
como ?id=nombre_suceso
Cuando se desee indicar solamente la fecha, el formato es
DDMMAAAA; cuando quiere especificarse la fecha y hora es
DDMMAAAAHHMMSS. Tanto la fecha como la hora, debe
estar expresado 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: campo que identifica al XML como petición
- recordGroup: campo que agrupa los registros de un suceso
- id: identificador del suceso
- record: identifica cada uno de los registros
- date: fecha y hora del suceso
- eventId: identificador del suceso
- annotation: anotación del suceso
- value: valor del suceso
ON: suceso activo
OFF: suceso inactivo
ACK: suceso reconocido
EDS

4.3.7.- Sucesos de un dispositivo

Devuelve la información de eventos registrados de uno o más
dispositivos entre las fechas "begin" y "end". Cada uno de los
dispositivos de los que se desea obtener información debe
incluirse como ?id=dispositivo
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?
Cuando se desee indicar solamente la fecha, el formato es
DDMMAAAA; cuando quiere especificarse la fecha y hora es
DDMMAAAAHHMMSS. Tanto la fecha como la hora, debe
estar expresado en UTC (Universal Coordinated Time).
<main>
<recordGroup>
<device> ... </device>
<record>
</record>
...
</recordGroup >
...
</main>
- main: campo que identifica al XML como petición
- recordGroup: campo que agrupa los registros de un suceso
- device: dispositivo al que hacen referencia los registros
- record: identifica cada uno de los registros
- dateTime: fecha y hora del suceso
- field: identifica cada uno de los campos
- id: identificador
- value: valor del evento

4.3.8.- Sucesos activos

EDS dispone de un servicio XML de sucesos activos cuyo
objetivo es que un agente o sistema de integración externo
pueda registrarse como oyente (listener) y registrar los
eventos o alarmas que se suceden en el equipo.
El equipo mantiene una lista de difusión con usuarios activos,
a los cuales envía los eventos que se producen de forma
local, a través de la creación de sucesos.
4.3.8.1.- Comandos de test
Antes de iniciar la implementación del sistema de sucesos
activos, y con el objetivo de comprobar la conectividad entre
ambos sistemas, existe una serie de peticiones de test tipo
PUT entre el listener (oyente) y producer (motor remoto) y
viceversa, cuyo objetivo es testear y asegurar la conectividad
entre ambos sistemas.
Para que el listener pueda comprobar la conectividad con el
motor remoto (producer), puede enviar dicha petición con el
siguiente cuerpo del mensaje:
http://ip_producer:port/services/user/testListener.xml
<listener>
<ip>ip_listener</ip>
<port>80</port>
</listener>
- ip_listener: define la IP del oyente, a la cual el producer
envía la petición de respuesta
- port: define el puerto del oyente, a través del cual el
producer envía la petición de respuesta
El producer (motor remoto) al recibir la petición de test por
parte del listener, devuelve la siguiente petición:
http://ip_listener:port/services/user/testProducer.xml
Petición a la que el oyente, debe contestar un "recibido"
(200).
4.3.8.2.- Registro de un listener (oyente)
Cualquier agente o listener que desee registrarse en un motor
remoto o producer, a fin de recibir los sucesos acontecidos
por dicho motor en tiempo real, debe realizar la siguiente
petición PUT al producer con dicho formato:
http://ip_producer:port/services/user/listener.xml
Dicha petición debe contener el siguiente cuerpo del mensaje,
en el cual se define el oyente y el tipo de datos a recibir:
<dateTime> ... </dateTime>
<field>
<id> ... </id>
<value> ... </value>
</field>
...
<listener>
<ip>ip_listener</ip>
<port>80</port>
<all>T</all>
</listener>
- ip_listener: se define la IP del oyente, a la cual el producer
envía los sucesos que se generan
- port: define el puerto del oyente, a través del cual el
producer envía los sucesos que se generan
El apartado all define el tipo de información al que se desea
acceder (True / False).
- True: indica al producer que envíe toda la lista de sucesos
activos de los que dispone
- False: indica al producer que envíe tan sólo los cambios
acontecidos desde la última petición
4.3.8.3.- Borrado o pérdida de la lista de oyentes
El producer puede perder o eliminar el listado de oyentes de
forma total o parcial, por diferentes motivos:
- El listener no contesta: cuando se suceden nuevos
eventos o cambios en dichos eventos, el producer informa
forma instantánea a toda su lista de oyentes. El producer,
ante un problema de comunicación con un oyente, realiza
hasta un total de cinco reintentos en el envío de la
información. En el caso que el oyente no atienda a dichas
peticiones, el producer lo da de baja de su lista de difusión.
- El producer se ha reiniciado o ha dejado de funcionar
temporalmente: si el producer recibe una actualización o
genera un reset por cualquier motivo (actualización de
firmware, pérdida de alimentación, etcétera), pierde toda la
lista de oyentes y desde ese momento deja de enviar
sucesos a los oyentes anteriormente asociados.
4.3.8.4.- Mantenimiento de las listas de oyentes (alive)
Dado que los motivos por lo cuales la lista de oyentes se
puede ver afectada de forma parcial, o total pueden ser
varios, es necesario que el sistema de integración externo
implemente un sistema de test (alive) contra el producer, para
asegurar que su IP se mantiene activa de forma duradera en
su listado de difusión.
Se recomienda que dicho sistema de test se realice de forma
automática y con una periodicidad no superior a 10 minutos
entre el envío de las tramas de test. El sistema de test (alive)
se basa en la actualización de la IP del oyente, nuevamente
contra el producer, aunque solicitando únicamente los
cambios en los eventos (False):
http://ip_producer:port/services/user/listener.xml
Dicha petición debe contener el siguiente cuerpo del mensaje,
en el cual se define nuevamente el oyente y el tipo de datos a
recibir:
<listener>
<ip>ip_listener</ip>
<port>80</port>
<all>F</all>
</listener>
- En el caso que la aplicación externa de integración se haya
mantenido inactiva por un período largo de tiempo, es
recomendable solicitar al producer el envío de todo el
listado de sucesos activos, mediante una petición True. De
este modo el oyente dispone nuevamente de toda la
información perdida durante el tiempo de inactividad.
4.3.8.5.- Recepción de sucesos
Cuando se produce algún cambio en los sucesos, la petición
que el producer genera contra la lista de difusión de los
oyentes, informando de los eventos será del tipo PUT con la
siguiente sintaxis:
http://ip_oyente:port/services/user/producer.xml
La petición contiene en el cuerpo del mensaje la siguiente
información en formato XML; información relativa a los
eventos producidos:
<producer>
<all>T/F</all>
<event>
<id>driverId.driverId.driverId...eventId</id>
<name>Evento 1</name>
<description>Descripción 1</description>
<annotation>Anotación 1</annotation>
<dateTime>25112010201034</dateTime>
<whyFired>ACTIVATION</whyFired>
</event>
<event>
<id>driverId.driverId.driverId...eventId</id>
<name>Evento 2</name>
<description>Descripción 2</description>
<annotation>Anotación 2</annotation>
M98237501-01-11C