Cómo funciona Energy Optimization dentro de Captia.ai
El módulo no es una caja aislada: es la última capa de una cadena que empieza en el contador y en el equipo de planta. Captia Connect adquiere las señales en el edge sobre los protocolos disponibles en la instalación (MQTT, OPC UA, Modbus TCP, Modbus RTU sobre RS-485, OpenWebNet, IEC 870-5-102, API REST, webhooks o ficheros CSV), las normaliza en series temporales y las envía a la plataforma con buffering local, de modo que una caída de conectividad no abre huecos en el histórico. Energy Optimization trabaja después, sobre ese histórico ya consolidado y con marca de tiempo homogénea.
El procesamiento tiene tres movimientos. Primero reconstruye la curva de carga: el consumo agregado y, cuando hay submedida, el consumo por línea, por sala técnica o por equipo. Segundo, relaciona esa curva con el contexto de operación disponible en la plataforma, porque un kWh solo es interpretable junto a lo que la planta estaba haciendo en ese momento: turno, calendario, estado de máquina, producción registrada. Tercero, sobre esa relación identifica dónde el consumo no responde a la actividad, que es la definición práctica de consumo evitable: bases de carga que no bajan cuando la planta para, arranques solapados que apilan picos, equipos auxiliares que siguen en marcha fuera de servicio, derivas lentas de un mismo equipo respecto a su propio pasado.
La salida no es un número aislado. Es material operativo dentro de la propia plataforma: dashboards de consumo por activo, línea, rol o planta; reglas y alertas cuando un patrón se repite; eventos trazables en el histórico; informes periódicos vía reporting; y, si el consumo debe llegar a los sistemas de gestión, integración por API con ERP, MES, CRM o SAP. Esa es la diferencia entre un análisis energético y un módulo: el resultado cae donde ya trabaja el equipo, no en un documento aparte.
| Capa | Qué aporta | Dónde vive |
|---|---|---|
| Entrada | Consumos eléctricos y curvas de carga normalizadas, más el contexto de operación disponible en la plataforma | Captia Connect (edge) y el histórico de Captia.ai |
| Procesamiento | Reconstrucción de la curva de carga, relación con la actividad y detección de consumo que no responde a esa actividad | Módulo Energy Optimization sobre los modelos industriales de la plataforma |
| Salida | Dashboards, reglas, alertas, eventos, reporting y APIs hacia ERP, MES, CRM o SAP | Captia.ai, en las mismas vistas que ya usa la operación |
Requisitos de datos: qué hace falta antes de activarlo
El requisito duro es un histórico de consumo con continuidad y con una granularidad coherente con la decisión que se quiere tomar. Un dato mensual de factura sirve para contabilidad energética, no para optimización: no distingue un pico de arranque de una base de carga. La granularidad útil es la que resuelve el fenómeno que se quiere ver, y eso se decide en el diagnóstico, no por defecto.
El segundo requisito es la identificación de lo que se mide. Una señal llamada contador 3 no permite ninguna conclusión operativa. La señal tiene que estar asociada a un activo, una línea o una zona, que es exactamente el trabajo de normalización y contextualización que hace Captia Connect al capturar el dato. Sin esa asociación el módulo puede describir la forma de la curva, pero no puede atribuirla.
El tercero es el contexto de actividad. Sin saber qué producía la planta, el consumo es una serie sin denominador. Ese contexto puede venir del propio dato de planta capturado por Connect o de la integración con ERP y MES. Cuanto más pobre sea el contexto, más se limita el módulo a detectar patrones anómalos y menos puede explicar su causa.
El cuarto es de calendario, no de tecnología: hace falta histórico suficiente para que el comportamiento normal esté representado. Una planta con estacionalidad marcada necesita haber vivido sus estaciones antes de que nadie, humano o modelo, pueda decir qué es normal en ella.
Casos de aplicación industrial
El caso más recurrente es la base de carga fuera de producción. Casi todas las plantas consumen de noche, en fin de semana o durante paradas programadas, y casi siempre parte de ese consumo es legítimo (frío, servidores, seguridad) y parte no lo es. Separar una cosa de la otra requiere ver la curva con la planta parada, que es justo cuando nadie mira. El módulo convierte esa ventana en algo observable y, con una regla, en algo vigilado de forma continua.
El segundo caso son los picos de demanda por simultaneidad. Cuando varios equipos arrancan a la vez tras una parada, el pico resultante no responde a ninguna necesidad de proceso: es una coincidencia de secuencia. Verlo en la curva de carga es la condición previa para escalonar arranques, y es una acción de operación, no una inversión.
El tercero es la deriva de un equipo respecto a su propio pasado. Un compresor o un grupo de frío que consume más que hace seis meses para el mismo servicio está contando algo, casi siempre mantenimiento. Aquí el módulo energético y el de mantenimiento predictivo miran la misma realidad desde dos ángulos y conviene leerlos juntos.
El cuarto es el consumo específico por unidad producida. Cruzar energía con producción convierte el consumo en un indicador comparable entre turnos, entre líneas y entre periodos, y es la puerta de entrada al módulo de optimización de producción y consumo, que ya no solo observa sino que busca el punto de operación.
Cómo se implanta por fases
La implantación sigue las mismas fases que el resto de la plataforma, descritas en el hub de plataforma de datos industriales, y no empieza por el módulo.
- Diagnóstico. Inventario de puntos de medida existentes, protocolos disponibles y arquitectura de red. Aquí se decide qué se mide, con qué granularidad y qué submedida falta.
- Despliegue del edge. Captia Connect en planta, conexión de contadores y equipos, normalización y buffering. A partir de este punto existe histórico.
- Puesta en marcha de la plataforma. Dashboards de consumo por activo, línea, rol o planta, usuarios y roles, y las primeras reglas y alertas. La planta empieza a ver su curva de carga.
- Operacionalización. Workflows, reporting periódico e integración por API con ERP o MES, para que el dato energético llegue a gestión sin pasos manuales.
- Inteligencia. Con histórico consolidado y contexto suficiente se activa Energy Optimization. Antes de este punto el módulo no tiene sobre qué trabajar.
Límites y cuándo no aplica
Conviene decirlo con claridad, porque ahorra proyectos mal planteados. Energy Optimization no aplica, o aporta poco, en estos escenarios:
- Sin medida o con medida solo agregada en cabecera. Si el único dato es el total de la planta, el módulo puede describir la curva global pero no atribuir el consumo. Lo que falta entonces es instrumentación, no analítica.
- Sin histórico. Recién conectada una señal no hay comportamiento normal contra el que comparar. El módulo necesita pasado.
- Cuando el problema es de diseño o de equipo. Un equipo sobredimensionado o una instalación mal diseñada no se corrigen leyendo su curva. El módulo lo hará visible, pero la solución es de ingeniería y pertenece a Captia Energy.
- Cuando no hay margen de operación. Si el proceso no admite variar secuencia, horario ni consigna por restricciones de calidad, seguridad o contrato, el consumo evitable identificado no es accionable. Sigue siendo útil para justificar inversión, pero no para optimizar la operación diaria.
- Cuando lo que se busca es un documento normativo. Una auditoría energética reglamentaria o una certificación tienen requisitos formales propios. El módulo aporta el dato continuo que las alimenta, no las sustituye.
Y un límite transversal: el módulo propone y evidencia, no ejecuta cambios de consigna por su cuenta. La acción sobre el proceso la decide la operación, con las reglas y los workflows que el equipo define y supervisa.