SCADA web: qué es y en qué se diferencia del SCADA tradicional

Un SCADA web es un sistema de supervisión industrial cuya interfaz se sirve desde un servidor y se usa desde el navegador, sin instalar cliente en cada puesto. Frente al SCADA tradicional de cliente pesado, cambia el modelo de despliegue (una instalación central en lugar de una por PC), el modelo de acceso (cualquier dispositivo con navegador y permisos) y el modelo de usuario (muchas personas con vistas por rol en lugar de un puesto de operador). En esta guía vemos qué aporta cada enfoque, cuándo conviene cada uno y cómo lo resuelve Captia.ai.

Qué es un SCADA web

SCADA significa supervisión, control y adquisición de datos: la herramienta con la que el operador ve el estado del proceso, recibe alarmas y actúa. Lo que distingue a un SCADA web no es lo que hace, sino cómo se entrega: sinópticos, tendencias, alarmas y mandos se sirven como una aplicación web y se consumen desde cualquier navegador moderno, en un PC de sala de control, en la tablet del jefe de turno o en el móvil del técnico de guardia.

La consecuencia práctica es que el SCADA deja de ser un puesto físico y pasa a ser un servicio. El servidor mantiene la lógica, las pantallas y los permisos; los clientes solo pintan. No hay versiones de cliente que actualizar máquina a máquina, no hay licencias por puesto que racionar entre turnos y no hay diferencia entre mirar la planta desde la sala de control o desde una visita a cliente, más allá de los permisos que cada rol tenga asignados.

El SCADA tradicional: cliente pesado y puesto único

El SCADA clásico nació en otra época y para otro problema: un puesto de operador fijo, en la misma red que los PLC, con un runtime instalado en un PC industrial dedicado. Ese modelo sigue siendo perfectamente válido para lo que fue diseñado, y conviene describirlo sin caricatura:

Instalación por puesto. Cada PC que necesita ver el proceso ejecuta un runtime propio, con su licencia, su versión y su mantenimiento. Añadir un puesto es un pequeño proyecto: hardware, licencia, instalación y pruebas.
Acoplamiento al sistema operativo. El runtime suele depender de versiones concretas de Windows y de drivers de comunicación instalados en la misma máquina. Las migraciones de sistema operativo se convierten en migraciones de SCADA.
Pensado para la red OT. El cliente vive en la misma red que el proceso. Sacar una vista fuera de esa red (a dirección, a mantenimiento en casa, a un proveedor) exige soluciones añadidas, desde escritorios remotos hasta réplicas de pantallas.
Un operador por puesto. El modelo de usuario es el del puesto de control: quien está sentado delante manda. Los conceptos de rol, sesión concurrente y vista personalizada por perfil son añadidos posteriores, no el diseño de partida.

HTML5 y navegador: qué cambia de verdad

La primera generación de "SCADA con acceso web" publicaba las pantallas del cliente pesado a través de tecnologías que hoy están retiradas de los navegadores, como los applets de Java o Flash, o directamente compartía el escritorio del puesto de control. Funcionaba, pero heredaba todas las limitaciones del modelo original y añadía las suyas.

Un SCADA web moderno se construye directamente sobre HTML5: las pantallas son aplicaciones web nativas, no una retransmisión de un cliente instalado en otra parte. Eso cambia tres cosas de fondo:

Cero instalación y cero mantenimiento por puesto. El navegador ya está en todos los dispositivos. Actualizar el SCADA es actualizar el servidor una vez; el siguiente refresco de página ya sirve la versión nueva a todo el mundo.
Independencia de dispositivo. La misma pantalla responde en un monitor de sala de control, una tablet a pie de máquina o un móvil. El diseño responsivo no es un extra: es la diferencia entre consultar una alarma desde donde estás o caminar hasta el puesto.
Integración natural con el resto del software. Una aplicación web convive con APIs, autenticación corporativa y enlaces profundos. Enlazar desde un aviso a la pantalla exacta del activo afectado es trivial en la web y artificioso en un cliente pesado.

Multiusuario y roles: de un puesto a toda la planta

El cambio más subestimado no es técnico sino organizativo. Cuando ver la planta deja de costar una licencia y una instalación, el círculo de personas que la ven se amplía: producción, mantenimiento, calidad, energía y dirección pueden trabajar sobre el mismo dato con vistas distintas.

Para que esa apertura no degenere en riesgo, el SCADA web necesita un modelo de usuarios y roles de primera clase: quién ve qué, quién reconoce alarmas, quién puede escribir consignas y quién solo consulta. La vista del operador de línea no es la del responsable de energía ni la del gerente, y las tres salen del mismo servidor sin duplicar ingeniería. El control de mando (que solo escriba quien debe, desde donde debe) pasa de ser una restricción física, la llave del puesto, a ser una política explícita y auditable.

Acceso remoto seguro

El acceso remoto es la razón más citada para pasar a SCADA web y también la que más respeto merece. Publicar pantallas de proceso en Internet sin más es un error grave; la forma correcta tiene tres ingredientes:

El proceso no se expone: se expone la aplicación. Los PLC y la red OT quedan detrás; el usuario remoto habla con el servidor web, con autenticación y cifrado, nunca con los equipos de control directamente.
Canales cifrados y autenticados. TLS para todo el tráfico y acceso a través de redes privadas o VPN modernas, de modo que la superficie pública sea mínima o nula.
Permisos que distinguen ver de actuar. La consulta remota de dashboards y alarmas es de bajo riesgo; la escritura remota de consignas exige roles restringidos y trazabilidad de cada acción. Un buen SCADA web permite dibujar esa línea con precisión.

Este planteamiento es el mismo que desarrollamos para el conjunto de la arquitectura en la guía de zero trust en OT industrial: la conectividad amplía valor solo cuando la seguridad forma parte del diseño, no del parche.

Nube, híbrido o local: dónde vive el SCADA web

Que la interfaz sea web no dicta dónde corre el servidor. Hay tres patrones, y la elección depende de la criticidad del control y de la conectividad de la planta:

Local (on-premise). El servidor vive en la planta, en la misma infraestructura que hoy alberga el SCADA clásico. Se gana la interfaz web y el multiusuario sin depender de la WAN para operar.
Nube. El servidor vive fuera de la planta y recibe los datos a través de una capa de adquisición local. Máxima comodidad de acceso y de mantenimiento, con una regla de oro: la supervisión puede vivir en la nube; el control en tiempo real y la seguridad de máquina permanecen en planta, en PLC y sistemas de seguridad que no dependen de ninguna WAN.
Híbrido. El patrón más común en la práctica: adquisición y buffering locales para que un corte de red no pierda datos ni detenga la operación, y capa de supervisión, análisis e histórico accesible desde cualquier sitio.

En cualquiera de los tres, el SCADA web funciona mejor cuanto mejor es la capa de datos que lo alimenta: adquisición multiprotocolo, normalización en origen y buffering ante cortes. Esa capa es exactamente el papel de una plataforma de datos industriales, y su pieza de entrada, el gateway edge, la tratamos en la guía de edge industrial con buffering y QoS.

Tabla comparativa: SCADA web frente a SCADA tradicional

Criterio	SCADA tradicional (cliente pesado)	SCADA web
Instalación	Runtime instalado en cada puesto	Servidor central; los puestos solo necesitan navegador
Actualizaciones	Puesto a puesto, coordinadas con el sistema operativo	Una vez en el servidor, para todos los usuarios
Dispositivos	PC industrial dedicado	PC, tablet y móvil con la misma aplicación
Usuarios	Operador por puesto; multiusuario limitado	Multiusuario concurrente con vistas y permisos por rol
Acceso remoto	Añadido (escritorio remoto, réplicas de pantallas)	Nativo, con autenticación, TLS y permisos por rol
Despliegue	Local, en la red OT	Local, nube o híbrido según criticidad
Integración IT	Drivers y conectores específicos por puesto	APIs y autenticación corporativa desde el diseño
Punto fuerte	Control determinista de proceso en el puesto de operador	Supervisión compartida por toda la organización

Cuándo el SCADA tradicional sigue siendo la respuesta

Una comparativa honesta admite que la respuesta no siempre es la web. El puesto de operador de un proceso crítico, con mando en tiempo real, pantallas de gran formato y disponibilidad garantizada aunque falle todo lo demás, sigue estando bien servido por el modelo clásico, y muchas plantas lo mantendrán durante años. Tampoco tiene sentido migrar por migrar un sistema amortizado que cumple su función y no necesita más usuarios.

El patrón que vemos funcionar no es sustituir sino complementar: el control de proceso permanece donde está, y la capa web añade lo que el modelo clásico no da, supervisión multiusuario, acceso remoto seguro, histórico consultable y conexión con el resto del negocio. Con el tiempo, cada planta decide si la capa web acaba absorbiendo también la supervisión de puesto o si ambas conviven de forma estable.

Cómo lo resuelve Captia.ai

Captia.ai es la capa de operación e inteligencia de nuestra plataforma, y su SCADA web es exactamente el modelo descrito en esta guía: supervisión desde el navegador, con dashboards por activo, línea, rol o planta, históricos, reglas, alertas, eventos y workflows, gestión de usuarios y roles, reporting y APIs para conectar con ERP o MES. Sobre esa base operan sus módulos de inteligencia artificial, de la detección de anomalías al forecasting.

El dato que lo alimenta llega por Captia Connect, la capa edge de adquisición: lectura multiprotocolo de PLC, sensores, contadores y SCADA existentes, normalización en origen y buffering local para que un corte de red no abra huecos en el histórico. El despliegue puede ser local, híbrido o cloud, y el SCADA existente no se sustituye: se integra como una fuente más. El conjunto es la arquitectura que describimos en plataforma de datos industriales.

Preguntas frecuentes sobre SCADA web

¿Un SCADA web sustituye a mi SCADA tradicional?

No necesariamente. El patrón habitual es complementario: el puesto de control de proceso permanece, y la capa web añade supervisión multiusuario, acceso remoto seguro e integración con el resto del negocio. La sustitución completa es una decisión posterior, si llega, y se toma cuando la capa web ya ha demostrado su valor en paralelo.

¿Es seguro acceder al SCADA desde fuera de la planta?

Lo es cuando se hace bien: el usuario remoto habla con la aplicación web, nunca directamente con los PLC; todo el tráfico va cifrado y autenticado; y los permisos distinguen entre consultar y actuar. La red OT queda detrás, y la escritura remota de consignas se limita a roles restringidos con trazabilidad de cada acción.

¿Qué pasa con el SCADA web si se corta Internet en la planta?

Depende de la arquitectura. Con un despliegue local o híbrido, la adquisición y el buffering viven en planta: la operación continúa y el histórico se completa al volver la conexión. El control en tiempo real nunca debe depender de la WAN; esa es la regla de diseño, no una propiedad del producto.

¿Necesito cambiar mis PLC para tener un SCADA web?

No. La capa de adquisición lee los equipos con los protocolos que ya hablan (Modbus, OPC UA, MQTT y otros) y sirve el dato normalizado a la capa web. Las máquinas y el control existente no se tocan; el SCADA web se construye encima del parque que ya tienes.

Si estás valorando llevar la supervisión de tu planta al navegador sin sustituir lo que ya funciona, en Captia.ai construimos esa capa sobre el dato que captura Captia Connect. El punto de partida es la arquitectura completa que describimos en plataforma de datos industriales.