Qontinuum
 Ingeniería Electrónica e Informática aplicadas mapa | contactar | registro | aviso legal | política
Inicio Productos Servicios Sop-Tec Empresa


Sop-Tec

Documentos
Actualizaciones
Base de Conocimientos
Consejos
Instalaciones completas
Renove electrónicas

info    Información complementaria     info

El sistema NeoFace

El sistema SIRAM

Plataforma Agora SMS

Los componentes de Software del subsistema SmaCPort formalizan claramente un modelo de capas

Terminal Portátil (Smartphone)

Acreditaciones 'NFC (Smartphone)'

Un grabador de imágenes que puede formar parte del Control de Intrusión

Subsistema HYDRA-II: la arquitectura de doble Cabezal para el Control de Accesos

El sistema KONE

El Control de Intrusión

Subsistema HYDRA: la arquitectura multi Cabezal para el Control de Accesos

Módulos "H": la arquitectura multi Cabezal para el Control de Accesos

Los diversos paradigmas en las comunicaciones basadas en TCP/IP/Ethernet

Los componentes de Software del sistema CONACC formalizan claramente un modelo de capas

 

 

 

El sistema NeoFace

El fabricante de sistemas de reconocimiento facial NEC dispone de un protocolo que nos permite comunicarle, desde el programa de aplicación QVigila, las fotografías de los Usuarios a ser identificados en los puntos de acceso (tornos o molinetes). El sistema NeoFace identifica a la persona que se acerca al punto de acceso y lo comunica al Servidor QOTF, el cual se encarga de validar la factibilidad del acceso y de comunicarlo al Terminal para que éste libere el torno o el molinete.

Para que tal capacidad de interacción pueda ser añadida al programa de aplicación QVigila, existe el Módulo funcional modelo Mf_CANF.

 

 

 

El sistema SIRAM

El fabricante de sistemas de lectura de matrículas Innova dispone de un protocolo que nos permite comunicarle, desde el programa de aplicación QVigila, los números de matrícula de los vehículos de cada Usuario, así como también desde los Terminales de Control de Accesos modelo DEF-3001 (situados en una barrera de 'entrada' o de 'salida' de un Parking) el NIS leido de la Acreditación presentada. A partir de esta información y de su propia gestión, el sistema SIRAM decide 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_CAM1.

 

 

 

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.

 

 

 

Los componentes de Software del subsistema SmaCPort 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 subsistema SmaCPort 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 subsistema SmaCPort 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.

 

 

 

Terminal Portátil (Smartphone)

Las condiciones necesarias para que un Smartphone pueda ser utilizado como Terminal Portátil son la de disponer de capacidad NFC integrada y la de operar bajo S.O. Android a partir de la Versión 4.4.2 (actualmente no es posible la utilización de otras plataformas), así como también es necesario haber cargado en el Smartphone la App Qtag_R para lograr comportarse frente a las Acreditaciones 'DESFire' y/o a las Acreditaciones 'NFC (Smartphone)' y/o a las Acreditaciones 'MIFARE' del sistema CONACC como si se tratara de un Cabezal estándard de Qontinuum, o haber cargado en el Smartphone la App Qtag_V para leer información de las Acreditaciones 'DESFire' y/o de las Acreditaciones 'NFC (Smartphone)' y/o de las Acreditaciones 'MIFARE' y poder validar en tiempo real (por medio del programa de aplicación QVigila) la identidad de las personas correspondientes.

Sin embargo, el uso de ambas App presenta algunas limitaciones.

 

 

 

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 S.O. Android a partir de la Versión 4.4.2 (actualmente no es posible la utilización de otras plataformas), 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 :
       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-3145/A : 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
  - 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

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

Los Terminales del subsistema Calypso que se pueden habilitar para la comunicación con las App Qtag_C son:
  - Terminales Modulares :
       DEF-2001 : Versión 9.14.0 y posteriores
       DEF-2045 : Versión 9.14.0 y posteriores
       DEF-2045/A : Versión 9.14.0 y posteriores
  - Terminales Compactos :
       DEF-TC4 : Versión 9.14.0 y posteriores

Las App Qtag_R, Qtag_V y QEvac pueden tratar las Acreditaciones emuladas por la 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 torno de paso), 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_CAA1.

 

 

 

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 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 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 K1 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 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 asume el Servidor VirGO, el cual interacciona directamente con la Base de Datos 'Fenix' sin necesidad, por tanto, de que el programa de aplicación esté funcionando.
En un equipo 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.

 

 
 

webmaster@qontinuum-plus.com
       T/. +34 932451628    M/. +34 610119235
c/. Ausiàs Marc, 71, entresol 2ª   08013 Barcelona
Página actualizada: 28-11-2018 Copyright © 1999-2018, Qontinuum Plus, S.L.
Todos los derechos reservados