| |
 Información
complementaria
|
|
Terminales
HYDRA: la nueva arquitectura para el Control
de Accesos
Este tipo de Terminales
introduce una nueva arquitectura, formada
por elementos, en la que la placa electrónica
HYDRA
(CPU principal perteneciente a la Serie
700) interactúa con hasta cuatro
Módulos "H"
(o con hasta dos si son de las Familias
MIF o DEF) que se le conectan, colocados
todos ellos dentro de un mismo contenedor
físico.
Esta arquitectura permite que los programas
de aplicación "vean" a
cada conjunción < HYDRA + Módulo
"H" > como a un único
"Terminal", de manera que todas
las parametrizaciones para cada conjunto
son por completo independientes las unas
de las otras, razón por la cual,
y bajo el punto de vista tanto conceptual
como funcional, un Terminal HYDRA hay que
entenderlo como hasta cuatro "Terminales"
independientes que únicamente comparten
la fuente de alimentación y las comunicaciones
por red.
Cada uno de los Módulo "H"
que se conecta a HYDRA puede ser de Familia
y Clase distinta, por lo que se obtiene
más versatilidad en el diseño
de las Instalaciones.
La existencia de HYDRA elimina el concepto
(existente hasta el momento) de Terminales
bicéfalos, siendo la identificación
de los "Terminales" siempre la
misma (del ID = 3 al ID = 6), por lo que,
a efectos de la administración del
sistema, los programas de aplicación
identifican a cada "Terminal"
por el Puerto de comunicaciones 'socket'
establecido para el Terminal HYDRA más
el ID (del 3 al 6) de cada Módulo
"H".
Una explicación funcional pormenorizada
de HYDRA puede encontrarse en el documento
BTP038.
|
Módulos
"H": la nueva arquitectura para
el Control de Accesos
Cada Módulo"H"
básico consiste en una placa de electrónica
(CPU secundaria perteneciente a la Serie
100) que admite la conexión de un
Cabezal lector o lector-grabador, de manera
que, al conectar tal Módulo "H"
a un Terminal HYDRA, se
consigue un "Terminal" con prestaciones
similares a las obtenidas con una CPU de
la Serie 900 en combinación con un
Cabezal lector o lector-grabador.
Cada uno de los Módulos "H"
básicos dispone de hasta 4 Salidas
y 4 Entradas para maniobras, quedando asignados
a las diversas Familias existentes en el
sistema CONACC.
Los Módulos "H" básicos
actualmente existentes son los siguientes:
SEP-G101
SEP-F101
MIF-101
DEF-101
Existen Módulos "H" auxiliares
de utilización especial que controlan
un Cabezal pero que no disponen de capacidad
para controlar Salidas / Entradas de señal,
de manera que encuentran su utilidad en
aquellos puntos de control (normalmente
de muy alta seguridad) que requieren de
una doble intervención
simultánea para permitir el acceso.
Los Módulos "H" auxiliares
de utilización especial actualmente
existentes son los siguientes:
MIF-101/DIS
DEF-101/DIS
Existen Módulos "H" auxiliares
de utilización específica
que no controlan ningún tipo de Cabezal
sino funcionalidades atípicas como
la conexión de una báscula
para la biometría
"de peso", el desarmado/armado
de una zona en un Panel de Alarmas en función
del aforo, etc., actuando entonces en combinación
con otro(s) Módulo(s) "H"
(los modelos XX-101) que si que controlan
un Cabezal.
Los Módulos "H" auxiliares
de utilización específica
actualmente existentes son los siguientes:
GEN-103
|
El
subsistema VirGO aporta un nuevo paradigma
en las comunicaciones basadas en TCP/IP/Ethernet,
de manera que éstas se agilizan y
potencian
VirGO (Virtual
Gateway Operator / operador de pasarela
virtual) es un producto diseñado
para invertir el paradigma de comunicaciones
estándar de Qontinuum.
Hasta la aparición del subsistema
VirGO, el paradigma de
comunicaciones siempre ha sido (y lo sigue
siendo si así se quiere utilizar)
del tipo 'master / slave' desde el programa
de aplicación a los Terminales, tanto
si la comunicación es por medio de
un Convertidor de normas
(RS-485 <--> RS-232) modelo LPC-200/13
como si lo es por medio de un Adaptador
de protocolos (RS-485 <-->
Ethernet) tipo bypass modelo
G-200/13
o tipo gateway modelo G-700/10BT
o modelo G-700/100BT2.
Este "primer paradigma" obliga
al programa de aplicación a hacer
"polling" sobre los Terminales
para obtener de ellos información,
por lo que al utilizar Adaptadores
de protocolos éstos deben
disponer de una dirección IP fija
y visible dado que actuan como Servidores
(para obtener más información
sobre los gateways, hay
que ver la Revisión G y posteriores
del documento BTP030);
además, y en el caso de que la comunicación
deba ser a través de Internet, se
hace necesario crear una ruta específica
en la "tabla de rutas" del Router
ADSL, etc.
Con la implementación del subsistema
VirGO aparecen el "segundo
paradigma" y el "tercer paradigma",
en los cuales cada gateway
pasa a ser 'master' en las comunicaciones
con los Terminales que tiene conectados
a su Bus RS-485, y pasa a ser Cliente en
las conexiones TCP/IP. Por tanto, ahora
son los gateways (llamados
gateways virtuales en su
nueva misión) los que hacen “polling”
sobre sus Terminales, comportándose
de igual manera los Terminales
HYDRA y los Terminales Portátiles
(que se conectan utilizando TCP/IP) al disponer
todos ellos del componente capa
VirGO, el cual es el encargado
de detectar cualquier situación especial
en los Terminales y de informar de inmediato
al programa de aplicación.
En el PC se ejecuta un Servicio (aportado
por el Servidor
VirGO) que atiende las comunicaciones
con las capas VirGO y que
guarda el estado lógico de cada Terminal.
El servicio VirGO tiene
el cometido de actuar como Servidor para
cuatro tipos de Clientes:
- el 'driver' Q2_DRV32.DLL
(el cual atiende, vía API, al programa
de aplicación, por lo que éste
sigue operando como lo haría contra
un gateway real);
- los gateway virtuales
(así llamados los gateways
cuando disponen de la capa VirGO
y la tienen activada);
- los Terminales
HYDRA (si tienen activada la capa
VirGO) así como aquellos
Terminales Portátiles que
dispongan de tal prestación;
- los Terminales Portátiles
que se conectan utilizando TCP/IP (si tienen
activada la capa VirGO).
El servicio VirGO informa
al programa de aplicación de los
siguientes "status" de un Terminal:
• se produce una situación
de Alerta/Alarma en el Terminal (‘tamper’
de Terminal, ‘tamper’ de Cabezal,
‘puerta forzada’, ‘puerta
mantenida’, "desarmado virtual"
o "armado virtual" de una zona
o partición en la Central de Alarmas,
‘fallo alimentación’,
etc.)
• la LISTA_MARCAJES no está
vacía (hay nuevos marcajes pendientes
de ser recogidos)
• se ha perdido la comunicación
(a nivel RS-485) con el Terminal
• se ha perdido la comunicación
(a nivel TCP/IP) con la capa VirGO.
El servicio VirGO puede
avisar al programa de aplicación
de dos maneras:
• en el "segundo paradigma"
el programa de aplicación hace “polling”
sobre el Servidor VirGO
(en realidad, el programa hará lo
mismo que hace actualmente, sólo
que es el Servicio VirGO
quién captura la petición,
la analiza y responde el ultimo “status”
que ha obtenido del Terminal).
• en el "tercer paradigma"el
programa de aplicación recibe una
interrupción del Servicio VirGO
cuando se produce en un Terminal alguno
de los "status" anteriormente
indicados.
Los elementos implicados
en el funcionamiento del subsistema VirGO
son:
Q2_DRV32.DLL
: Versión 8.0.0 y posteriores
Q2_UTIL.EXE
: Versión 6.0.0 y posteriores
Q_VIRGO.EXE
: Versión 1.0.0 y posteriores
Q_VIRGO.DLL
: Versión 1.0.0 y posteriores
Q_VIRGOMON.EXE
: Versión 1.0.0 y posteriores
FW-G700-116.BIN
: Versión 5.0.0 y posteriores
FW-G700-117.BIN
: Versión 5.0.0 y posteriores
HYDRA
: Versión 8.0.0 y posteriores
MIF-PT040
: Versión 8.0.0 y posteriores
La explicación completa del subsistema
VirGO puede verse en el
documento BTP037.
|
| Los
componentes de Software del sistema CONACC
formalizan claramente un modelo de capas
En el entorno de la programación
orientada a objetos es formalmente correcto
y arquitectónicamente muy deseable
el uso de componentes Software previamente
existentes que traten capas inferiores a
la de aplicación, estando normalmente
tales capas estructuradas en forma de API.
El sistema CONACC no solamente
no es una excepción a tal modelo
sino que lo propone y potencia al aportar
hasta tres API públicas
(entendido en el sentido de que están
disponibles para nuestros OEM) que son dependientes
entre sí de manera jerárquica,
dejando al criterio de los OEM el nivel
de la capa de entrada a utilizar desde sus
programas de aplicación:
Q2_DRV32.DLL (nivel
bajo)
CONACC.DLL (nivel
medio)
WINCOM.DLL
(nivel alto)
Si bien los programas de aplicación
de Qontinuum englobadas en el llamado nivel
'Fenix' utilizan este modelo de capas
(y por tanto utilizan tales API
públicas), utilizan también
otras API privadas que
son comunes a tales programas. La actualización
conjunta de tales componentes se encuentra
en el paquete compo-'Fenix'.
|
| |
|
|
|
