ACS: acceso a través de Ethernet.
Todo el mundo habla y escribe sobre la revolución IP en los sistemas de gestión y control de acceso (ACS). ¿Qué es esto en la práctica?
¿Por qué Ethernet?
Empecemos por el hecho de que esto no es una revolución, sino más bien una evolución. El proceso ya lleva varios años, pero hasta el día de hoy la proporción de controladores ACS con interfaz Ethernet no es tan grande en el mercado. Al menos hasta hoy no son dominantes.
El propio deseo de utilizar redes Ethernet para combinar controladores ACS en un sistema integral tiene aspectos económicos bien fundamentados, a saber: la introducción generalizada de tecnologías de red. Quizás hoy sea muy difícil encontrar una empresa u oficina que no esté enredada en redes informáticas. Además, las empresas distribuidas geográficamente también suelen tener comunicaciones de red dedicadas para conectar la oficina central y numerosas sucursales. Por tanto, si las redes informáticas se utilizan para todo tipo de comunicaciones entre entidades comerciales, ¿por qué no utilizarlas para conectar los controladores ACS con el resto del sistema? Al fin y al cabo, los cables ya están tendidos y el aumento del tráfico procedente del sistema de control de acceso es simplemente insignificante.
Las soluciones Ethernet en el lado del hardware (controlador) se han vuelto rentables. Hoy en día, puede agregar nuevas funciones a un controlador de sistema de acceso tradicional desde el punto de vista del elemento base por solo $10. Naturalmente, la implementación del software de la pila TCP/IP en hardware también costará algo, pero estos son costos únicos, y si compra una pila ya preparada de una empresa especializada en esto para acoplarse con el software principal de los controladores , esto le costará a la empresa fabricante del equipo entre 2 y 5 mil dólares. Con la replicación normal de equipos, los costos se recuperarán más rápido que si usted mismo desarrollara software a nivel de red.
Así, la migración de los sistemas de acceso en esta dirección es bastante comprensible, mientras que la lentitud del proceso se explica no sólo y no tanto por la necesidad de un nuevo desarrollo, sino por el conservadurismo de la industria de la seguridad, e incluso el temor de que una Aparecerá un nuevo «agujero» a través de la red común, lo que aumentará la vulnerabilidad tanto de los atacantes externos como de varios tipos de fallas aleatorias en el funcionamiento de una red generalmente «ajena».
Soluciones
¿Cómo se puede ahorrar en cables y unirse a la “web” general? Hay varias maneras. La forma más sencilla, que los instaladores avanzados intentaron poner en práctica hace varios años, es utilizar gateways de hardware que permitan implementar un puerto COM virtual a través de Ethernet. Este tipo de dispositivos se fabrican desde hace tiempo por diversas empresas, en particular para sistemas de automatización industrial. La solución más eficaz puede considerarse un dispositivo llamado X-Port de Lantronix (Figura 1). Este dispositivo está completamente alojado en una carcasa de enchufe Ethernet, un conector que se instala en la placa de circuito impreso del dispositivo de destino. También hay muchos dispositivos externos, similares en apariencia a conmutadores de red estándar, que se pueden conectar entre el cable Ethernet y el controlador del sistema de acceso. En la literatura, todos los dispositivos de esta clase suelen denominarse servidores asíncronos. La Figura 2 muestra un diagrama de cómo conectar un controlador ACS estándar a través de dicho servidor.
Figura 1. Convertidor de Ethernet a COM — puerto.
¿Por qué esta solución más sencilla (y de muy bajo coste) no se utiliza mucho? Sí, porque no siempre es eficiente.
Figura 2. Conexión mediante un servidor asíncrono.
Los controladores ACS clásicos se conectan a través de la interfaz RS-485, con hasta varias docenas por línea de interfaz. Por su naturaleza, RS-485 es una interfaz «maestro-esclavo», donde la PC consulta alternativamente los controladores conectados a la línea. Se espera que cada solicitud tenga una respuesta, y si por algún motivo no hay respuesta, el controlador se considera defectuoso. El tiempo de espera de una respuesta puede no ser demasiado largo para garantizar que la velocidad de respuesta del sistema en presencia de un controlador que no responde siga siendo adecuada. Normalmente, el tiempo de espera no supera el doble de la duración de la respuesta del controlador, que es aproximadamente de 50 a 100 milisegundos. Si no hay respuesta durante más tiempo, significa que el controlador está defectuoso.
Al mismo tiempo, pueden producirse con bastante regularidad retrasos de hasta varias decenas de milisegundos en la cadena ordenador — controlador de puerto virtual — pila TCP/IP — red Ethernet — enrutador (conmutador) — servidor asíncrono — controlador, lo que conduce a una inoperatividad real de la solución en cuestión.
Por tanto, es difícil obtener un sistema que funcione sin modificar el software del propio controlador. Una solución calificada se ve diferente: se instala un controlador Ethernet en el controlador (análogo a una tarjeta de red en una PC), con el que interactúa directamente el microprocesador del controlador ACS. Naturalmente, el software del controlador en términos de intercambio con un PC está cambiando drásticamente. Por tanto, ACS con Ethernet es un nuevo desarrollo bastante complejo y la empresa fabricante debe estar motivada por la situación del mercado.
Protocolos Ethernet
Entonces, tenemos la oportunidad de conectar controladores ACS a una PC que ejecuta el software del sistema de acceso a través de una red Ethernet compartida (o tal vez dedicada). ¿Qué problemas nos pueden esperar en este camino? Estos problemas, por regla general, aparecen cuando se trabaja en una red compartida, que es administrada por un administrador de sistemas del departamento de TI, que tiene sus propios puntos de vista (y, por regla general, no infundados) sobre cómo debería funcionar una red corporativa, qué protocolos y los puertos deben permitirse o prohibirse en diferentes segmentos de la red. Veamos primero hasta qué punto el ACS puede utilizar determinados protocolos de red. No hay tantos: estos son UDP, TCP/IP y HTTP.
UDP
El protocolo más rápido y menos costoso. Le permite intercambiar paquetes que no superen una trama Ethernet (aproximadamente 1500 bytes). Pero esto es suficiente para nosotros: en un sistema de control de acceso, el controlador rara vez intercambia paquetes de más de 100 bytes con el PC. Por tanto, debido a su velocidad y simplicidad, UDP es un candidato ideal para su uso en un sistema en tiempo real. No es casualidad que muchos protocolos de red para sistemas de automatización industrial funcionen en él. La desventaja de UDP (la falta de entrega garantizada de mensajes) se puede superar fácilmente utilizando los mismos métodos que cuando se trabaja con RS-485: protocolo de enlace, es decir, envío de confirmación de recepción de cada paquete.
TCP/IP
Este protocolo proporciona entrega garantizada, puede «cortar» en el lado emisor y «pegar» paquetes de datos grandes en el lado receptor, pero realmente no lo necesitamos. Pero es menos eficiente y mucho más costoso en la implementación de software. Su única ventaja es que la mayoría de las veces pasa por conmutadores y enrutadores corporativos de forma predeterminada.
HTTP
Este es el más lento de los protocolos, está «construido sobre» TCP/IP y se utiliza como el principal en la WEB, es decir, es con su ayuda que recibimos información de Internet. De esto se deduce que es transitable a escala casi global, lo que constituye su clara ventaja. Pero en sistemas de tiempo real su uso es casi imposible debido a su lentitud.
¿Cuál es mejor?
A partir de una breve descripción, resulta obvio que para los sistemas en tiempo real, como los sistemas de control de acceso, es preferible utilizar el protocolo UDP. Si tiene una red simple, esto no causará ningún problema, todo funcionará muy bien y a una velocidad excelente. Si la red es un poco más compleja y el administrador del sistema ha «cerrado» puertos y protocolos innecesarios, el sistema no funcionará hasta que se levanten las restricciones especificadas destinadas a la seguridad de TI. De la misma manera, Internet no funcionará si se bloquea el paso de los paquetes dirigidos al puerto número 80.
Si la red consta de varias subredes, entonces es necesario asegurar el paso de paquetes UDP a través de enrutadores que separan las subredes. Entonces, si toda la red a la que están conectados los componentes ACS está bajo su control, no hay mejor solución que UDP.
Si la red no está completamente controlada, en algunos casos es posible que TCP/IP pase por donde se eliminará UDP, aunque nadie puede garantizarlo. El uso de HTTP, como se mencionó anteriormente, es simplemente imposible para los sistemas en tiempo real. Sin embargo, hay una salida: VPN.
Caballo de Troya VPN
VPN – Red Privada Virtual, o en ruso red privada virtual. Este es un buen invento que le permite transferir cualquier dato utilizando cualquier protocolo estándar a través de redes públicas. Si le dijeron que no puede usar un tubo azul en su jardín, pero realmente quiere hacerlo, entonces puede tomar un tubo rojo aprobado con un diámetro ligeramente mayor y colocar el tubo azul en él. Así funciona una VPN, en sentido figurado. Y dado que se trata de un estándar global, prácticamente no habrá problemas a la hora de organizar las comunicaciones en cualquier red; al menos estos problemas siempre tienen solución.
HTTP
Entonces, nosotros (o mejor dicho, la dura realidad) hemos rechazado el protocolo HTTP como medio de comunicación para sistemas en tiempo real. Al mismo tiempo, es sobre la base de este protocolo que ya se están implementando nuevas y bastante interesantes funciones en los sistemas de control de acceso. En primer lugar, hay tareas que no requieren una reacción en una fracción de segundo. Estas tareas incluyen, por ejemplo, la generación y visualización de informes sobre el funcionamiento del sistema (seguimiento de visitas, registro de jornada laboral, etc.). Y dado que el protocolo garantiza la permeabilidad en cualquier red a escala global, tenemos la oportunidad de ver informes desde cualquier parte del mundo. Lo único que se requiere para esto es «reequipar» el software del sistema de acceso con un pequeño servidor WEB, que proporcionará comunicación entre la base de datos de eventos del sistema y el cliente al otro lado de la World Wide Web.
Y ya se ha implementado otra solución progresiva basada en el protocolo HTTP: se trata de controladores independientes con interfaz WEB. Un controlador de este tipo se puede obtener si un controlador independiente normal se complementa en hardware con un controlador Ethernet y en software con un servidor WEB. En este caso, tenemos la oportunidad de controlar el controlador, cambiar su configuración e incluso ver informes de eventos utilizando un navegador WEB estándar, que siempre está disponible en cualquier PC moderna. En otras palabras, obtenemos un controlador independiente controlado por PC sin instalar ningún software adicional en la PC.
El único problema es que sin medidas adicionales no podremos combinar dichos controladores en una única red, es decir, garantizar el intercambio de información entre los controladores y la gestión y el seguimiento centralizados. Para solucionar este problema, es necesario complementar el software del controlador con una serie de funciones, lo que, sin embargo, no es una tarea insuperable.
Y si obtiene una dirección IP dedicada para su organización, entonces el acceso a dicho controlador será posible, nuevamente, desde cualquier parte del mundo. Por supuesto, surge la pregunta sobre la seguridad de dicha solución frente a los atacantes, pero esto también se puede resolver: puede usar la misma VPN de la que hablamos un poco más arriba. Por supuesto, implementar una VPN en el controlador no es una tarea fácil y es bastante costosa, pero proteger un canal de comunicación fuera de la organización utilizando medios VPN se puede realizar, por ejemplo, mediante un ordenador dedicado a este fin.
Así es como se ven las soluciones que le permiten obtener algún beneficio de la presencia de redes Ethernet en su organización, ciudad, país…