Terminal para soluciones de control de acceso y control horario por tags RFID (tarjetas, pulseras y llaveros) y móvil.
Funcionamiento offline: el terminal funciona sin conexión a red.
Kapri es un terminal de funcionamiento offline que permite identificar a los usuarios mediante 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 gestiona todos los accesos desde el propio terminal y funciona sin conexión a red. Permite registrar hasta un máximo de 5.000 usuarios.
Las altas de los usuarios pueden realizarse en diferido, es decir, mediante la introducción de un número de identificación y un PIN el usuario puede completar el alta en el terminal sin necesidad de desplazarse hasta el administrador.
La identificación de los usuarios es a través de un lector RFID 125kHz o un lector de tarjetas RFID Mifare/Desfire (permite leer el UID y los sectores de memoria de la tarjeta).
Con la opción BLE, el usuario puede identificarse mediante una tarjeta virtual de alta seguridad alojada en el móvil.
Aplicaciones
Hemos diseñado Kapri para soluciones de:
El terminal Kapri dispone de un display gráfico IPS de 2.4» con excelente visibilidad desde todos los ángulos. Dispone de un teclado capacitivo de 4 teclas y un beeper.
El terminal Kapri 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 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 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 ofrece los siguientes protocolos de comunicación:
*Para más información, consultar la pestaña Protocolos de comunicación.
Kimaldi Kapri 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. |
| Relés | 3 relés, libres de potencia, 24V/1A |
| AntiTamper | 1 entrada de antitamper |
| Buzzer | 1 integrado en circuito |
| RTC | 1 integrado en circuito |
| Display | 2.4'', IPS, 320×240 |
| Teclado | Capacitivo táctil 4 teclas |
| Wifi | Opcional |
| Temperatura de operación | -20ºC a 50ºC |
| Tecnología RFID | |
| Ethernet | 10M/100M/1000M |
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.
