5 Arquitecturas SCADA para el Escalamiento de Aplicaciones
Adaptándose al requerimiento de los sistemas SCADA
ADAPTÁNDOSE AL REQUERIMIENTO
Al implementar sistemas SCADA, una de las preguntas más frecuentes es ¿Qué arquitecturas existen y cómo puedo construir un sistema confiable? Esta pregunta surge ante la necesidad de sacar el mejor provecho de nuestro sistema, el cual representa una inversión alta para la empresa. Además, va de la mano con el crecimiento, nuestros requerimientos en el futuro pueden ser diferentes a los que inicialmente teníamos cuando empezamos.
En este artículo vamos a conversar acerca de 5 arquitecturas importantes para empezar a usar SCADA y para ir creciendo poco a poco hasta cubrir con los requerimientos más demandantes de la industria.
1. SERVIDOR DE SUPERVISIÓN ÚNICO
Esta arquitectura es una de las más usadas en la industria, y en esta utilizamos un único servidor donde reside nuestro software SCADA. Aquí se conectan todos los equipos de adquisición, los clientes de nuestra aplicación y el servidor de base de datos.
Utilizando un servidor único, podemos mantener los costos de adquisición bajos y logramos un software de supervisión exitoso. Esta arquitectura mantiene una solución muy sencilla y fácil de mantener, lo cual la hace más atractiva.
Aunque es una estructura interesante, el sistema de servidor único no es perfecto. Hay 4 situaciones típicas que podemos enfrentar con un sistema de este tipo:
- El servidor puede llegar a sobrecargarse debido a las demandas de los clientes y a la comunicación con dispositivos.
- Ante una infraestructura de red donde no se pueda garantizar la conexión constante de los equipos, la pérdida de datos puede ser un factor importante para mejorar nuestro sistema.
- Cuando tenemos una gran cantidad de software, el mantenimiento del mismo se empieza convertir en un problema
- Cuando otros sistemas quieren tener acceso directo a los datos, el software de supervisión se puede convertir en un embudo de datos
Para cada uno de estos problemas, existen las arquitecturas que mostraremos a continuación.
2. SERVIDORES ESCALABLES E INTERCONECTADOS
A través del uso de varios servidores que tengan la capacidad de interconectarse, un servidor único sobrecargado puede expandirse a un grupo de servidores asumiendo la carga entre sí. Para este tipo de arquitectura, uno o más servidores se encargan de todo lo relacionado con las Etiquetas y Señales, es decir, la información proveniente del campo. Podemos crecer indefinidamente, según sea la carga del sistema
Por otro lado, están los servidores Front End, los cuales manejan la carga de todas las demandas de los clientes. A través de estos se conectan todos los usuarios de la aplicación y se ejecutan todas las tareas indirectas de dichos usos, como algunas transacciones con bases de datos, algunos scripts, etc. De igual manera, utilizando un balanceador de cargas, podemos implementar la cantidad de servidores Front End que se requieran de acuerdo al requerimiento.
Con esto logramos resolver un problema de sobrecarga en nuestros servidores, pero aún así, todavía podríamos tener problemas con nuestra infraestructura de red.
3. CENTRAL CON EXTENSIONES
Una red de servidores nos permite mantener funcionalidades de SCADA en sitios estratégicos para mitigar los efectos de una desconexión. Podemos utilizar un servidor principal, o grupo de servidores principales, que tenga todas las funciones necesarias de nuestro sistema SCADA, y donde podemos conectar todos nuestros clientes y dispositivos, pero el sistema se apoya en los servidores distribuidos para mantener el sistema en línea.
En ciertos lugares, podemos colocar servidores con funciones más enfocadas y limitadas. Algunos ejemplos son mantener un registro histórico en caso de la pérdida de comunicación, o mantener datos importantes de una aplicación, como un horario de planificación de equipo ingresado por un usuario, o un formulario de ingreso de producto, podemos mantener la aplicación gráfica de monitoreo, para que el operador tenga todas las herramientas para operar correctamente su proceso, etc. Esta es una arquitectura muy flexible, y con una gran cantidad de combinaciones posibles.
Con esto resolvemos los problemas de infraestructura de red, pero nuestro crecimiento podría generar la necesidad de tener una mejor solución de mantenimiento y administración de software. Para esto, necesitamos implementar la solución mostrada en la siguiente sección.
4. EMPRESARIAL
La arquitectura empresarial busca implementar herramientas de centralización de sistemas que permiten el intercambio de información, monitoreo de sistemas, y gestión de recursos de una forma más sencilla para usuarios de muchos sistemas. Dicha arquitectura se puede usar para casos donde una arquitectura Central Con Expansiones ha crecido demasiado y se necesitan herramientas de centralización, o cuando una empresa simplemente tiene una gran cantidad de plantas que utilizan múltiples instancias de un mismo sistema SCADA.
Lo cierto es que cuando llegamos al punto donde la cantidad de software ha crecido mucho, las tareas de gestión se vuelven sumamente complejas. Mantener los sistemas actualizados, monitorear el uso de recursos de los servidores, mantener respaldos constantes de nuestras aplicaciones, gestionar el uso centralizado de recursos, monitorear la seguridad de cada servidor, etc, son tareas que pueden afectar negativamente el desempeño de los sistemas SCADA cuando no existe una solución viable.
El sistema empresarial es muy sencillo en realidad, se selecciona un servidor SCADA como el servidor central, a partir del cual se pueden gestionar todas las tareas del resto de servidores. Eso sí, todos deben estar conectados bajo la misma red para poder ejecutar dichas labores. Otra ventaja de la arquitectura empresarial es que podemos centralizar la información y enviarla a servicios en la nube de una forma muy sencilla y fácil de administrar.
Cuando los sistemas SCADA almacenan mucha información de operación, se vuelven un puente de información para altos volúmenes de datos con otros tipos de sistemas, y esto se vuelve poco viable. Esto sucede debido a que dicho intercambio de información implica:
- Crear métodos de intercambio a través de tecnologías como APIs Web, OPC UA u otros
- Transformar la información para que sea recibida por el otro sistema de acuerdo a sus estructura (ya sea en el SCADA o en el sistema que recibe la información)
Ciertamente esto no ocurre de forma nativa en la mayoría de los casos, lo cual pone a las empresas a desarrollar interfaces de conexión. Es por esto que cuando el volumen de datos incrementa sustancialmente, lo mejor es que las aplicaciones accedan directamente a la fuente de información, sin pasar necesariamente por el SCADA, y esto nos lleva a la siguiente arquitectura.
5. IIOT
Los softwares SCADA operan en los pisos de planta, muy cerca de la operación, y ayudan a optimizar los procesos de toda empresa. Es cierto que este tipo de soluciones son ampliamente usadas en toda la industria, pero no son el único software que existe en los ambientes industriales. Además de no ser la única solución en la cadena de software dentro de una empresa, no necesariamente es el único consumidor de datos de operación.
Otras herramientas como los MES, LIMS, ERPs, CRMs, Big Data, etc, pueden servirse de los datos para ayudar a sus usuarios a ejecutar sus labores. Al intentar adquirir estos datos, el primer acercamiento es conectar los sistemas al SCADA, para intercambiar información ya existente en dicho sistema. Y esto ocurre principalmente por una razón, los protocolos típicos de las tecnologías de operación no son los mismos de las tecnologías de información, muchas veces tienen dificultades para acceder a los datos que necesitan.
Para solucionar este problema, lo que se debe hacer es definir una sola interfaz de comunicación para todos los sistemas. La propuesta para esta arquitectura es MQTT, un protocolo que es ampliamente utilizado. El MQTT permite grandes beneficios, como la gestión de metadatos, el uso optimizado del ancho de banda, estándar abierto, etc.
El uso de una arquitectura IIoT funciona a través de la implementación de una infraestructura de datos basada en MQTT, en el cual el servidor o broker es el punto principal de interconexión para todo tipo de aplicaciones, sea SCADA, MES, ERP, CRM o cualquier otro. Este servidor puede estar ya sea en sitio o en la nube, y permite a todas las aplicaciones hablar un mismo idioma.
La arquitectura empresarial puede ser muy similar a la IIoT, pero la principal diferencia es la existencia de una infraestructura de datos IIoT, con la que es posible compartir datos con todos los sistemas sin tener un paso adicional de por medio.
REDUNDANCIA
Un punto que no hemos mencionado en el artículo es el uso de redundancia en los sistemas. A pesar de ser una característica crítica para las arquitecturas, su implementación es bastante sencilla. La redundancia trata acerca del uso de servidores de respaldo para todos los servidores SCADA, de manera que si existe un fallo, la aplicación se mantendrá en línea debido a que el servidor de respaldo retomará las funciones del principal.
La redundancia es fácilmente aplicable, si tenemos un problema de disponibilidad con un servidor SCADA o un equipo de computación en el borde, solamente tenemos que considerar el uso de un equipo de respaldo en ese punto, adicional al equipo que ya funciona activamente.
Con el uso de la redundancia, las posibles combinaciones de arquitecturas se vuelven muy amplias, y es aquí donde solo nuestro requerimiento específico nos puede dar la respuesta a cual de todas las arquitecturas es mejor.
CONSTRUYENDO UNA ARQUITECTURA PROPIA
La selección final de una solución puede inclusive hacer uso de una mezcla entre varias arquitecturas, podemos usar una arquitectura Escalable e Interconectada para mejorar la carga de los servidores, y al mismo tiempo hacer uso de una arquitectura empresarial que conecte varias plantas de nuestra empresa.
Como hemos comentado, la selección entre una arquitectura u otro es un asunto de análisis y estudio con base a las necesidades. En este artículo hemos expuesto de forma general acerca de los principales obstáculos que puede presentar un SCADA en su implementación o a través de su crecimiento, y las principales arquitecturas que resuelven estos problemas.
Lea también: Guía Introductoria para SCADA