-
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:
<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
5.-
Características técnicas
Circuito de alimentación :
- Monofásica (fase – neutro) A1 – A2 :
- Frecuencia :
- Consumo máximo :
- Temperatura de trabajo :
- Humedad (sin condensación) :
Características mecánicas:
- Material caja:
- Grado de protección del equipo:
- Dimensiones (mm):
- Peso:
- Altitud máxima de funcionamiento:
Características entradas:
- Tipo:
- Corriente máxima de activación:
- Aislamiento:
Interface de Red:
- Tipo:
- Conector :
- Protocolos de red:
Modem :
- Bandas de trabajo (Data only):
Interface Serie:
- Tipo:
- Velocidad de transmisión (configurable):
- Bits de datos:
- Paridad:
- Bit de stop
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>
Versión estándar
85...264 V
/ 120...300 V
ca
cc
50...60 Hz
6-10 VA (CA) / 3-4 W (CC)
-10 ...+ 60 ºC
5 ... 95 %
Plástico UL94 - V0 autoextinguible
IP 20
105 x 70 x 90 mm (6 módulos)
385 g
2.000 m
Libre de tensión opto aislada (contacto seco)
50 mA
1500 V
Ethernet 10BaseT / 100BaseTX autodetectable
RJ45
HTTP / Modbus/RTU en bus RS-485
UMTS/HSPA - 2100 / 900 Band
GSM - 850 / 900 / 1800 / 1900 Band
RS-485 tres hilos (A/B/S)
4800, 9600,19.200, 34.800, 57.600, 115.200 bps
8
Sin paridad, par, impar
1
<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>
<dateTime>25112010201034</dateTime>
<disabledDateTime>25112010201103</
disabledDateTime >
<whyFired>DEACTIVATION</whyFired>
</event>
...
</producer>
-
all: todos los eventos (True) o cambios (False)
-
event-id: producer e identificador del evento
-
whyFired: ACTIVATION, DEACTIVATION
Notas referentes a los sucesos activos:
-
Nota: si el producer tiene implementada autenticación http
por usuario y contraseña, debe ser implementada en el
oyente por parte del usuario.
4.3.9.- Forzado de variables
Mediante esta petición puede enviarse al sistema la orden de
forzado de variables (o escritura). En la petición debe
incluirse el nombre del dispositivo que desea realizarse la
petición. Es importante incorporar los datos de autenticación
en caso que sea necesario.
<forceVariables>
<forceVar>
<forceName> ... </forceName>
<forceValue> ... </forceValue>
</record>
</forceVar>
...
</forceVariables>
-
forceVariables: campo que identifica al XML como petición
-
forceVar: información de cada una de las variables desean
forzarse
-
forceName:
dispositivo.variable.
-
field: identifica cada uno de los campos
Características salidas:
- Tipo:
Relé
- Potencia máxima de maniobra:
750 VA
- Tensión máxima de maniobra:
250 V
- Intensidad máxima commutación:
5 A con carga resistiva
- Vida eléctrica (250 Vca / 5 A):
3 x 104 maniobras
- Vida mecánica:
2 x 107 maniobras
Simbología LED:
- Power :
Equipo alimentación y actividad de CPU
- Slaves:
Apagado equipos esclavos comunicando
- GPRS/3G link:
Conexión GPRS o 3G enlazada con el operador
- Led RJ45 izquierdo:
Verde: Full dúplex / Ambar: Half dúplex /
- Led RJ45 derecho:
Actividad
Verde: 100 Mb/s / Ambar: 10 Mb/s / Link
Display:
- Tipo :
Alfanumérico 2 líneas
- Caracteres:
20
- Retroiluminación:
Si
Seguridad:
Categoría de instalación Clase III / EN61010 Protección al choque eléctrico por doble
aislamiento clase II. El equipo debe conectarse a un circuito de alimentación protegido con
fusibles tipo gl según IEC 269 o tipo M, con valores comprendidos entre 0,5 y 1 A. Debe
estar provisto de un interruptor magnetotérmico, o equivalente, para poder desconectar el
equipo de la red de alimentación. La sección mínima del cable de alimentación será de
1mm
.
2
Normas :
CE, UL 94, EN61010-1, EN55011, EN 61000-4-2, EN 61000-4-3,
61000-4-11, EN 61000-6-4, EN 61000-6-2, EN 61000-6-1, EN 61000-6-3, EN 61000-4-5
EDS-3G
nombre
de
la
variable
con
formato
ca
M98240601-01-13B