| |
 Información
complementaria
|
|
Los recursos LPR (License
Plate Recognition)
Varios fabricante de sistemas de lectura
de matrículas disponen de protocolos
de comunicación que nos permite interaccionar,
desde el programa
de aplicación QVigila,
para obtener los números de matrícula
de los vehículos de cada Usuario,
así como también es posible
efectuar el control desde los Terminales
de Control de Accesos modelo
DEF-3001
(situados en una barrera de 'entrada' o
de 'salida' de un Parking) del NIS leido
de la Acreditación presentada. A
partir de esta información y de su
propia gestión, los recursos
LPR deciden si la matrícula
leída en el vehículo corresponde
al Usuario cuya Acreditación éste
ha presentado, y lo comunica al Terminal
para que éste abra (o no) la barrera.
Para que tal capacidad de interacción
pueda ser añadida al programa de
aplicación QVigila,
existe el Módulo
funcional modelo Mf_LPR.
|
Plataforma Agora SMS
El fabricante de Middleware Agora dispone
de la plataforma Agora SMS
(Security Management Software), un producto
PSIM (Physical Security
Information Management) que integra equipos
de otros fabricantes (cámaras, grabadores
de imágenes, control de intrusión,
etc.) y que también obtiene información
del Control de Accesos
físicos de Qontinuum cuando al programa
de aplicación QVigila
se le añade el Módulo
funcional modelo Mf_PSIM
(todo ello forma parte del subsistema
ADA), de manera que los operadores de
la plataforma Agora SMS
obtienen una visión global de los
recursos de la Instalación así
como de la interacción entre tales
recursos, pudiendo ser tal interacción
programada según las propias conveniencias
de la Instalación.
|
Acreditaciones
'NFC (Smartphone)'
Las
condiciones necesarias para que un Smartphone
pueda ser utilizado como Acreditación
son la de disponer de capacidad NFC
integrada y la de operar bajo un S.O. compatible,
así como también es necesario
haber cargado en el Smartphone
del Usuario la App Qtag_C.
Dada la tipología de comunicación
impuesta por la tecnología NFC,
los Cabezales y/o Terminales que históricamente
haya suministrado Qontinuum (en los
que la parte de comunicación
RFID haya sido fabricada
por terceros) no pueden ser utilizados,
de manera que sólo pueden serlo
aquellos Cabezales y/o Terminales
fabricados por Qontinuum a los que
se haya actualizado su Firmware a
la Versión que les
habilita para la comunicación con
las App Qtag_C,
comunicación que se realiza vía
NFC y de manera totalmente
segura al ser la encriptación por
algoritmo AES-128 (tanto al emular 'DESFire'
como al emular 'MIFARE').
• Los
Cabezales de
la Serie 3000 que se pueden habilitar
para la comunicación con las App Qtag_C
son:
-
Cabezales lectores-grabadores y FW necesario:
DEF-3094 :
Versión 2.3.0 y posteriores
DEF-3095
: Versión 2.0.0 y posteriores
DEF-3096
: Versión 2.0.0 y posteriores
DEF-3195
: Versión 2.0.0 y posteriores
DEF-3196
: Versión 2.0.0 y posteriores
DEF-3105
: Versión 2.0.0 y posteriores
DEF-3145
: Versión 2.0.0 y posteriores
DEF-3180
: Versión 2.0.0 y posteriores
DEF-3185
: Versión 2.0.0 y posteriores
DEF-3205/N
: Versión 2.2.0 y posteriores
DEF-3240 :
Versión 2.3.0 y posteriores
DEF-3245 :
Versión 2.0.0 y posteriores
DEF-3280
: Versión 2.0.0 y posteriores
DEF-3285
: Versión 2.0.0 y posteriores
- Cabezales "en Kit"
:
DEF-KC097
: Versión 2.0.0 y posteriores
DEF-KC097B
: Versión 2.0.0 y posteriores
DEF-KC097BO
: Versión 2.0.0 y posteriores
DEF-KC097BO2
: Versión 2.0.0 y posteriores
• Los
Terminales de
la Serie 3000 que se pueden habilitar
para la comunicación con las App
Qtag_C son:
- Terminales de Sobremesa
:
DEF-3311
: Versión 2.0.0 y posteriores
DEF-3311/R2
: Versión 2.0.0 y posteriores
• Las
App Qtag_R
y Qtag_V
pueden tratar las Acreditaciones
emuladas por las App Qtag_C.
|
Un grabador
de imágenes que puede formar parte
del Control de Intrusión
Se trata del Terminal Especial
modelo QScope,
la misión del cual es la de ser utilizado
como grabador de imágenes en combinación
con una o varias cámaras digitales
y con un Panel y, opcionalmente,
con un Terminal Especial modelo
DEF-PCT1
o modelo DEF-PCT2.
La combinación operativa de todos
ellos (ver presentación)
configura un potente y versatil sistema
de Control de Intrusión,
Control de Accesos físicos
y Grabador de imágenes,
conectados todos ellos en LAN, existiendo
también la API-QSCOPE
para facilitar y securizar el acceso de
los programas OEM a las imágenes
almacenadas, estando tales programas situados,
por ejemplo, en el CCS (Centro de Control
y Seguridad) de la Instalación.
|
Subsistema HYDRA-II: la arquitectura de
doble Cabezal para el Control de Accesos
El subsistema HYDRA-II
utiliza como plataforma física la
mísma que utilizan los Terminales
Modulares modelo DEF-3002,
a la que se le han añadido prestaciones
lógicas.
Tal arquitectura permite que los programas
de aplicación "vean" a
cada conjunción < HYDRA-II + Cabezal
> 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 subsistema
HYDRA-II hay que entenderlo
como hasta dos Terminales independientes
que únicamente comparten la fuente
de alimentación y las comunicaciones.
Cada uno de los Cabezales que se conecta
a HYDRA-II puede ser de
Familia y Clase distinta, por lo que se
obtiene más versatilidad en el diseño
de las Instalaciones (dependiendo de las
características de los Cabezales
podría ser necesario el uso de adaptadores
modelo GEN-C1).
La existencia de HYDRA-II
reintroduce el concepto de Terminales 'Bicéfalos'
dado que admite el uso de la prestación
anti Pass-Back "local".
|
El sistema
KONE
El fabricante de
ascensores KONE dispone de un protocolo
que nos permite comunicar, desde los Terminales
de Control de Accesos modelo
DEF-3001
(situados en un torniquete, portillo, etc.),
información correspondiente a los
usuarios de los ascensores, como es el caso
de la planta a la que éstos deben
ser transportados. A partir de esta información
y de su propia gestión, el sistema
KONE decide (para optimizar el
tiempo de espera y minimizar el consumo
de recursos energéticos) cual de
los ascensores deberá tomar cada
usuario, informando de ello mediante un
visualizador situado en el torno de paso.
Exclusivamente para los integradores OEM,
la interacción con el sistema
KONE está documentada en
la Revisión
Y de las especificaciones del sistema
CONACC.
Para que tal capacidad de interacción
pueda ser añadida al programa de
aplicación QVigila,
existe el Módulo
funcional modelo Mf_CAA.
|
El
Control de Intrusión
Bajo este nombre
genérico se agrupan el conjunto de
elementos producidos por Qontinuum para
el control y la gestión de sensores
y de otros elementos y casuísticas
susceptibles de ser consideradas como generadoras
de situaciones que deban producir alarma,
así como de las correspondientes
reacciones, por lo que están involucrados
electrónicas (a las que llamamos
Paneles), programas
de aplicación y API para el mercado
OEM.
Aunque el potencial es muy notable, es condición
imperiosa para su uso el que no se requiera
de conectividad a una receptora pública
dado que no se utilizan protocolos estándar
de mercado (como “CONTACT ID”
o “SIA 2000") sino un protocolo
propio incluido en el sistema
CONACC de Qontinuum y, por tanto, fácilmente
incorporable en aquellos programas OEM que
integren los productos propios del sistema
CONACC.
Cumpliendo tales premisas, en 2012/2013
integramos en los Terminales Modulares
modelo MIF-709
y modelo DEF-3001
la funcionalidad de Control de Intrusión,
mientras que en 2014/2015 diseñamos
específicamente los Paneles
de Intrusión modelo DEF-3003
y DEF-3003/L,
todos ellos con la posibilidad de controlar
Entradas y Salidas agrupadas en diversas
Particiones.
Relacionados con el Control de Intrusión
(y también desde 2014) existen los
Terminales Especiales modelo DEF-PCT1
y modelo DEF-PCT2,
así como también existen los
Terminales Especiales modelo QScope.
Llamamos Paneles
de Intrusión a aquellos
elementos específicos para el Control
de Intrusión y de otras
situaciones de alarma (los modelos DEF-3003
y DEF-3003/L)
que disponen de Entradas Supervisadas (normativa
UNE-EN 50131 en Grado 3), pero que
también disponen de la capacidad
de Control de Accesos.
Además, tales Paneles
de Intrusión también
puede interaccionar con un grabador de imágenes
modelo QScope.
Llamamos Paneles
tipo interno (concepto comercialmente
obsoleto pero técnicamente vigente)
a aquellos Terminales Modulares
para el Control de Accesos
(los modelo DEF-3001)
que disponen de las prestaciones adecuadas
para el Control de Intrusión
y otras situaciones de alarma, pudiendo
disponer sólo de la Partición
#1 para la 'operativa local' (al operar
de manera habitual) o de hasta ocho Particiones
de 'operativa local' (al operar en combinación
con la prestación 'Incidencia "SxT"',
la cual permite Selección por Teclado
cuando el Cabezal
conectado dispone de teclado y de pantalla).
Además, tales Terminales Modulares
también puede interaccionar con un
grabador de imágenes modelo
QScope.
Llamamos Paneles
tipo mixto (concepto comercialmente
obsoleto pero técnicamente vigente)
a aquellos Terminales Modulares
para el Control de Accesos
(los modelos MIF-709
y DEF-3001)
que disponen de las prestaciones adecuadas
para el Control de Intrusión
y otras situaciones de alarma pero que presentan
las siguientes limitaciones:
- sólo permiten “armar”
o “desarmar” la Partición
#1 (la única que admite 'operativa
local');
- sólo permiten definir una Entrada
(E2, E5 o E6) como llave de “armado”
y solamente si no se requiere de “re-armado”
automático;
- la Salida para indicar “armado”
o “desarmado” sólo puede
ser asignada a S2, S3 o S4.
Integrado en el Módulo
funcional modelo Mf_CRA cuando éste
se añade al programa QVigila,
existe una opción para actuar
como Receptora de Alarmas, pudiendo igualmente
los programas OEM integrar el tratamiento
de tales Paneles.
Para el funcionamiento del Control
de Intrusión es necesario
que el programa de aplicación que
actúe como gestor de los Paneles
y/o como Receptora de Alarmas tenga conectado
un 'Kit' para el control y la seguridad
modelo G-SECUR.
|
Subsistema HYDRA: la arquitectura multi
Cabezal para el Control de Accesos
Este subsistema
(ver
presentación) formaliza
una arquitectura formada por elementos,
en la que el Terminal Modular HYDRA
(controladora perteneciente a la Serie 700)
interactúa con hasta cuatro Módulos
"H" que se le conectan, colocados
todos ellos dentro de un mismo contenedor
físico.
Tal arquitectura permite que los programas
de aplicación "vean" a
cada conjunción < HYDRA + Módulo
"H" + Cabezal > 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 subsistema
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 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
cada subsistema HYDRA más
el ID (del 3 al 6) de cada Módulo
"H".
Una explicación funcional pormenorizada
de HYDRA puede verse
en la Revisión E o posterior del
documento BTP038.
|
Módulos "H": la arquitectura
multi Cabezal para el Control de Accesos
Cada Módulo"H"
básico consiste en una placa de electrónica
(controladora secundaria perteneciente a
la Serie 100) que admite la conexión
de un Cabezal lector o lector-grabador,
de manera que, al incorporar tal Módulo
"H" a un subsistema HYDRA,
se consigue un Terminal con prestaciones
similares a las obtenidas con un Terminal
Modular 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
existentes son los siguientes:
SEP-G101
SEP-F101
MIF-101
DEF-101
MIF-105
DEF-105
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 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 Partición en un Panel
de Alarmas externo 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
|
Los diversos
paradigmas en las comunicaciones basadas
en la torre TCP-IP-Ethernet
"Primer paradigma"
Hasta la aparición del Servidor
VirGO, el paradigma de comunicaciones
(al que llamamos “primer paradigma”)
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 con comunicación nativa
por RS-485 pero que están conectados
por medio de un Adaptador de protocolos
(modelo G-200/13
o modelo G-700/10BT
o modelo G-700/100BT2
o modelo G-2K),
al igual que también es del tipo
‘master/slave’ con los Terminales
con comunicación nativa por Ethernet
(es decir, cuando ninguno de tales elementos
IP utiliza la capa VirGO
incorporada).
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 actúan como Servidores
(para obtener más información
sobre los elementos
IP, hay que ver la Revisión R
o posterior 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.
"Segundo paradigma"
(Atención:
el "segundo paradigma" de las
comunicaciones ha sido discontinuado en
1-6-2017 como recurso disponible para los
OEM).
VirGO (Virtual Gateway
Operator / operador de pasarela virtual)
aparece como "segundo paradigma"
de comunicaciones, en el cual cada Adaptador
de protocolos 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, en este paradigma son los Adaptadores
de protocolos (en realidad el componente
Software llamado capa VirGO)
los que hacen “polling” sobre
sus Terminales, y de la misma manera se
comportan todos los demás elementos
IP (tanto de la Serie 700 y de la Serie
3000 y tanto si son Modulares como
Compactos) al poder 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 para que éste tome
la iniciativa pertinente, para lo cual 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 Servidor
VirGO quién captura la petición,
la analiza y responde con el ultimo “status”
que ha obtenido del elemento
IP).
En un PC de la Instalación se ejecuta
un Servicio de Windows (aportado por el
Servidor VirGO)
que atiende las comunicaciones con las capas
VirGO y que gestiona el estado
lógico de cada Terminal.
La explicación completa del "segundo
paradigma" de las comunicaciones
puede verse en la Revisión K3
o posterior del documento BTP037.
"Tercer paradigma"
(Atención:
el "tercer paradigma" de comunicaciones
es de uso exclusivo de los programas de
aplicación de Qontinuum que forman
parte del ecosistema
Q-OnTheFly).
En el "tercer paradigma" de las
comunicaciones, el programa de aplicación
deja de comunicar con los elementos
IP para recojer marcajes o para
conocer su estado dado que tales funcionalidades
las asumen los Servidores
VirGO, los cuales interaccionan
directamente con la Base de Datos
'Fenix' sin necesidad, por tanto,
de que el programa de aplicación
esté funcionando.
En cualquiera de los equipos de la Instalación
se ejecuta un Servicio de Windows (aportado
por el Servidor
VirGO) que atiende las comunicaciones
con las capas VirGO y
que gestiona el estado lógico
de cada Terminal, pudiendo existir
hasta un máximo
de 255 Servidores
VirGO en la misma Instalación.
|
|
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 englobados en el llamado nivel
'Fenix' utilizan este modelo de capas
(y por tanto utilizan tales API
públicas), utilizan también
otras API privadas de Qontinuum
que son comunes a tales programas.
|
| |
|
|
|
