Terminal para soluciones de control de acceso y control de presencia por huella dactilar, tags RFID (tarjetas, pulseras y llaveros) y móvil.
Sensor biométrico de huella con capacidad de 25.000 templates y 12.500 usuarios con un solo dedo.
Kapri Bio es un terminal de funcionamiento online que permite identificar a los usuarios mediante huella dactilar, RFID (tarjetas, llaveros, pulseras y tags) y opcionalmente con el teléfono móvil. Pensado para soluciones de control de acceso y control horario.
Kapri Bio identifica por huella dactilar. El terminal dispone de tecnología LFD (Live Finger Detection) para una mayor precisión en la detección de huellas dactilares falsas.
Tiene un excelente reconocimiento de las huellas dactilares bajo cualquier condición, sequedad y/o humedad.
El sensor óptico de huella SFM tiene una capacidad de 25.000 templates y 12.500 usuarios con un solo dedo. Con superficie frontal resistente al agua (IP65).
Aplicaciones
Hemos diseñado Kapri Bio para soluciones de:
El terminal Kapri Bio dispone de un display gráfico IPS de 2.4» con excelente visibilidad desde todos los ángulos de la pantalla. Dispone de un teclado capacitivo de 16 teclas que facilita la introducción de órdenes de trabajo y códigos y un beeper.
El terminal Kapri Bio incluye 3 relés que permiten activar cerraduras eléctricas, tornos, barreras, alarmas u otro tipo de dispositivos.
Las 4 entradas digitales del terminal se pueden emplear para monitorizar el estado de sensores de puerta, sensores de final de carrera, etc. El equipo dispone de un sensor Anti-Tamper que permite detectar la manipulación del terminal.
El equipo se conecta por su puerto Ethernet y la comunicación con la aplicación se realiza siempre mediante el intercambio de objetos JSON. La integración del dispositivo resulta sencilla con independencia del lenguaje de programación o sistema operativo.
Kapri Bio está disponible en versión Wifi.
Esta opción es la más adecuada para las aplicaciones Web extranet, ya que en estos entornos por razones de seguridad no se suele permitir que la aplicación de la nube inicie las comunicaciones con los dispositivos, sino que los terminales son los únicos que pueden hacerlo. Kapri Bio inicia las comunicaciones y cuando se produce un evento, como por ejemplo la lectura de una tarjeta, envía un comando POST a la aplicación/Servidor API de la nube. Como respuesta la aplicación envía un set de comandos a ejecutar por el terminal, como por ejemplo mostrar mensajes por pantalla y activar relés para permitir el acceso.
El protocolo Cloud se caracteriza por:
– El terminal Kapri inicia todas las comunicaciones.
– Las comunicaciones son seguras cuando la nube usa el protocolo https.
– No requiere la instalación de drivers, .DLLs, servicios,…
El terminal Kapri Bio ofrece los siguientes protocolos de comunicación:
*Para más información, consultar la pestaña Protocolos de comunicación.
Como opción se puede añadir un lector RFID 125kHz o un lector de tarjetas Mifare/Desfire (permite leer el UID y los sectores de memoria de la tarjeta).
Con la opción Bluetooth (BLE), el usuario puede identificarse mediante una tarjeta virtual de alta seguridad alojada en el móvil.
Kimaldi Kapri Bio está disponible en acabado módulo de integración para instalarlo en tornos, barreras y puertas.
| Alimentación | 5 VDC +/-10% |
|---|---|
| Consumo máximo | 1500 mA |
| RS-232 | 2 puertos internos: |
| TTL | 2 puertos internos: |
| Entradas digitales | 4 entradas digitales activas a masa, inactivas en O.C. |
| Ethernet | 10M/100M/1000M |
| Relés | 3 relés, libres de potencia, 24V/1A (24/1A: 500.000 conmutaciones) |
| AntiTamper | 1 entrada de antitamper |
| Buzzer | 1 integrado en circuito |
| RTC | 1 integrado en circuito |
| Dimensiones | 134x143x41 mm |
El terminal Kapri comunica por TCP/IP (cable Ethernet o WiFi). La comunicación con la aplicación se realiza siempre mediante el intercambio de objetos JSON.
Para facilitar la configuración del terminal se puede realizar a través del navegador conectándose al WebServer incorporado al Kapri y, desde allí, seleccionar el protocolo de comunicación.
El equipo ofrece los siguientes protocolos:
JSON-TCP/IP
El terminal ofrece un puerto de comunicación TCP/IP por el que enviará y recibirá objetos JSON. Este puerto puede trabajar como Server o Client según como se configure.
Esta opción es la más adecuada para las aplicaciones desarrolladas en lenguajes que no permiten el uso de protocolos web, pero pueden manejar sockets TCP/IP estandar.
KTP
Es un protocolo propietario de Kimaldi que dispone de un controlador de la red KTP y realiza las siguientes funciones:
– Localiza automáticamente los terminales de la LAN.
– Proporciona una interfaz API con el software
– Ofrece un canal SocketIO para la gestión de eventos.
– Encripta las comunicaciones con AES256.
Esta opción es la más adecuada para las aplicaciones intranet que deben manejar varios equipos de los que desconoce su dirección IP. La aplicación interactúa exclusivamente con el diver/controlador de la red KTP. Además, permite agrupar terminales sobre la misma LAN para que sean controlados por diferentes aplicaciones.
HTTP
El terminal ofrece una interfaz API Server que admite comandos POST y GET. Existe la opción que el terminal envíe los eventos vía SocketIO para evitar el polling de la aplicación. No requiere la instalación de drivers. La aplicación necesita conocer la IP del terminal.
Esta opción es la más adecuada para las aplicaciones web intranet, ya que en estos entornos las aplicaciones pueden acceder libremente a los dispositivos.
CLOUD
El terminal siempre inicia las comunicaciones. Cuando se produce un evento, como por ejemplo la lectura de una tarjeta, envía un comando POST a la aplicación/Servidor API de la nube. Como respuesta la aplicación envía un lote de comandos a ejecutar por el terminal, como por ejemplo mostrar mensajes por pantalla y activar relés para permitir el acceso.
El protocolo Cloud se caracteriza por:
– El terminal Kapri inicia todas las comunicaciones.
– Las comunicaciones son seguras cuando la nube usa el protocolo https.
– No requiere la instalación de drivers.
– La aplicación no necesita conocer la IP del terminal.
Esta opción es la más adecuada para las aplicaciones web extranet, ya que en estos entornos por razones de seguridad no se suele permitir que la aplicación de la nube inicie las comunicaciones con los dispositivos, sino que los terminales son los únicos que pueden hacerlo.
