Cómo funciona la optimización de producción y consumo dentro de Captia.ai
El módulo parte de una constatación incómoda para cualquier planta: producción y energía se gestionan casi siempre por separado, con reuniones distintas y responsables distintos, aunque compartan las mismas máquinas y las mismas horas. Producir más rápido casi nunca es gratis en energía, y ahorrar energía casi nunca es gratis en ritmo. El módulo trabaja justo en ese cruce: busca el punto de operación que equilibra producción y consumo energético, apoyándose en el histórico consolidado de ambas dimensiones.
La materia prima llega por la misma vía que el resto de la plataforma. Captia Connect adquiere en el edge las señales disponibles en la instalación sobre 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 con buffering local, de modo que una caída de red no deja huecos en el histórico. Para este módulo hacen falta las dos familias de señales a la vez y con la misma marca de tiempo: las de producción (estado de máquina, contadores de piezas, rechazos, cambios de formato) y las de energía (potencia y consumo del activo o de la línea). Sin sincronía entre ambas, cualquier cociente entre energía y unidades es ruido.
Sobre ese histórico, el procesamiento sigue tres movimientos. Primero construye el consumo específico, es decir la energía por unidad producida buena, resuelto por línea, por producto y por franja de operación, no como media mensual de planta. Segundo, relaciona ese consumo específico con el ritmo real al que la línea estuvo trabajando en cada periodo, y con el resto de condiciones que la plataforma ya tiene registradas: producto, formato, turno, calendario, paradas. De ese cruce sale la forma de la curva de la planta, que rara vez coincide con la intuición del equipo. Tercero, con los modelos industriales y la simulación sobre el digital twin de la plataforma, evalúa configuraciones que no han ocurrido todavía: otro ritmo nominal, otra secuencia de arranques, otro reparto de carga entre líneas equivalentes, otra ventana horaria para el mismo lote.
Merece la pena detenerse en por qué la curva tiene esa forma, porque es la razón de ser del módulo. A ritmo bajo, la parte fija del consumo (compresores, extracción, iluminación, climatización, servicios auxiliares que no dependen de cuántas piezas salen) se reparte entre pocas unidades y el kWh por unidad se dispara. A ritmo alto aparecen las pérdidas del otro extremo: rechazos que suben al forzar la máquina, microparadas y rearranques que obligan a reponer condiciones de proceso, auxiliares que pasan a trabajar fuera de su zona eficiente. Entre ambos extremos existe un tramo donde la suma es mínima. Ese tramo es lo que el módulo entrega, y no es un número universal: depende del producto, del equipo y del contexto de cada instalación.
La salida vive dentro de la propia plataforma, no en un informe aparte: dashboards con el consumo específico por activo, línea, rol o planta; reglas y alertas cuando la operación se desplaza fuera del tramo definido; eventos trazables en el histórico para poder reconstruir después qué pasó; reporting periódico; y APIs hacia ERP, MES, CRM o SAP cuando el criterio debe llegar a planificación. La Operator Layer es el punto donde ese criterio se convierte en algo que el turno puede leer sin abrir una hoja de cálculo.
| Capa | Qué aporta | Dónde vive |
|---|---|---|
| Entrada | Histórico de producción (estado de máquina, contadores, rechazos, cambios) y de energía (potencia y consumo) con marca de tiempo común | Captia Connect en el edge y el histórico de Captia.ai |
| Procesamiento | Consumo específico por línea, producto y franja; relación con el ritmo real; simulación de configuraciones no ocurridas sobre el digital twin | Módulo de optimización sobre los modelos industriales y la simulación de la plataforma |
| Salida | Tramo de operación recomendado, dashboards de consumo específico, reglas, alertas, eventos, reporting y APIs hacia ERP, MES, CRM o SAP | Captia.ai, incluida la Operator Layer que ve el turno |
Conviene fijar la frontera con el módulo vecino. El de optimización energética mira el consumo y busca la parte que no responde a la actividad: base de carga nocturna, picos por simultaneidad, derivas de un equipo. Este módulo asume que ese consumo ya es legítimo y se pregunta otra cosa: dado que hay que producir un plan, ¿a qué ritmo y con qué reparto sale más barato en energía sin incumplirlo? Uno recorta lo evitable, el otro elige entre alternativas todas ellas válidas. Suelen implantarse en ese orden.
Requisitos de datos: qué hace falta antes de activarlo
El requisito que decide si el módulo tiene sentido es la simultaneidad. No basta con tener datos de producción y datos de energía: hacen falta ambos sobre el mismo perímetro físico y con la misma resolución temporal. Contadores de energía de planta frente a partes de producción por turno no permiten construir un consumo específico útil, porque el turno es demasiado grueso para separar el arranque del régimen estable y el perímetro de planta mezcla líneas que producen cosas distintas. El emparejamiento correcto es medida de energía y contador de piezas sobre la misma línea o el mismo activo.
El segundo requisito es un denominador limpio. Si el contador de piezas no distingue piezas buenas de rechazos, el consumo específico sale optimista de forma sistemática, porque atribuye energía a producto que nunca se vendió. Aquí el módulo depende de un dato que ya existe en la mayoría de líneas (expulsores con contador, registro de inspección) pero que a menudo no llega a la plataforma.
El tercero es el contexto de producto y formato. Comparar el consumo específico de dos periodos que fabricaron referencias distintas no dice nada. El módulo necesita saber qué se estaba haciendo para comparar contra lo comparable, y ese dato suele venir de la integración con ERP o MES, o del propio maestro que ya se usa para el cálculo de indicadores de planta.
El cuarto es el rango de operación observado. Un modelo no puede describir una curva en un tramo que nunca se ha visitado. Si la línea siempre ha funcionado al mismo ritmo nominal, el histórico contiene un punto, no una curva, y la simulación sobre el digital twin partirá de una base más pobre. En estos casos el diagnóstico suele proponer ensayos controlados de corta duración a ritmos distintos, algo que se decide con producción y no se improvisa.
El quinto es de calendario. Igual que en el resto de módulos analíticos, hace falta histórico suficiente para que estén representadas las condiciones habituales de la planta, incluida la estacionalidad de la parte térmica del consumo, que es la que más se mueve con la temperatura exterior.
Casos de aplicación industrial
El caso central es la elección de ritmo nominal en líneas donde la velocidad es configurable. La intuición dominante en planta es que ir más rápido siempre sale mejor porque diluye los costes fijos, y en muchas líneas es cierto hasta un punto a partir del cual los rechazos y las microparadas se comen la ganancia y el consumo por unidad buena repunta. Localizar ese punto con el histórico propio, en lugar de con una creencia, es una decisión de operación sin inversión asociada.
El segundo caso es el reparto de carga entre líneas o equipos equivalentes. Dos líneas que hacen el mismo producto casi nunca tienen el mismo consumo específico ni la misma sensibilidad al ritmo, por edad, por reformas o por instrumentación. Cuando hay un plan que se puede repartir, la asignación deja de ser una cuestión de disponibilidad y pasa a ser una decisión con consecuencia energética medible.
El tercero es la secuenciación de lotes y cambios de formato. Un cambio no cuesta solo el tiempo de la parada: cuesta el arranque posterior, con su merma y su consumo de puesta en condiciones. Ordenar los lotes para reducir el número de cambios afecta a la vez a producción y a energía, y es una de las pocas palancas que mejora las dos sin contrapartida.
El cuarto es el encaje del plan en la ventana horaria. Cuando el mismo volumen puede fabricarse en configuraciones distintas de turno, la elección tiene un efecto directo sobre la base de carga que se mantiene encendida y sobre el número de arranques desde frío. Este caso solo es accionable si planificación participa, porque no se decide en la línea.
El quinto es el seguimiento del consumo específico como indicador de deriva. Cuando una línea empieza a necesitar más energía por unidad para el mismo producto y el mismo ritmo, está diciendo algo sobre su estado. Esa señal se lee mejor junto al módulo de mantenimiento predictivo, que mira la misma degradación desde el lado del activo.
Todos estos casos tocan de lleno el terreno del OEE, porque el ritmo es exactamente la variable del factor de rendimiento y los rechazos lo son del de calidad. Aquí conviene ser explícito: este módulo no calcula ni explica el OEE, lo usa como restricción. La derivación de sus fórmulas, la cascada de tiempos, las seis grandes pérdidas y los errores de medición que inflan o hunden el indicador están tratados en la guía de OEE con la fórmula y un cálculo resuelto. Lo que aporta el módulo es la dimensión que el OEE deliberadamente no lleva dentro: el coste energético de cada punto de esa curva.
| Palanca | Efecto sobre el ritmo | Efecto sobre el consumo por unidad | Dónde se ve en Captia.ai |
|---|---|---|---|
| Subir el ritmo nominal | Más unidades por hora mientras la línea aguante | Baja al principio por reparto de la base fija, sube después por rechazos y microparadas | Dashboards de consumo específico por línea y producto |
| Repartir el plan entre líneas equivalentes | Sin cambio en el total, cambia el origen | Depende de la curva propia de cada línea, que rara vez coincide | Comparativa por activo y simulación sobre el digital twin |
| Agrupar lotes para reducir cambios | Más tiempo disponible para producir | Menos arranques desde frío y menos merma de puesta a punto | Eventos de cambio en el histórico y reporting periódico |
| Concentrar el plan en menos turnos | Mismo volumen, menos ventana | Menos horas de base de carga, más arranques y paradas | Curva de carga y reglas sobre la ventana de operación |
Cómo se implanta por fases
La implantación sigue las fases generales de la plataforma descritas en el hub de plataforma de datos industriales, con una particularidad: este módulo es de los últimos en activarse, porque necesita que las dos cadenas de dato, la de producción y la de energía, estén maduras a la vez.
- Diagnóstico. Inventario doble: puntos de medida eléctrica y señales de producción disponibles en cada línea. Aquí se detecta el desajuste habitual, que es tener buena medida de una de las dos cosas y ninguna de la otra sobre el mismo perímetro.
- Despliegue del edge. Captia Connect en planta, conexión de contadores, PLC y sensórica, normalización y buffering. A partir de aquí existe histórico con marca de tiempo común, que es la condición que hace posible el cociente.
- Puesta en marcha de la plataforma. SCADA web, dashboards por activo y línea, usuarios y roles, y las primeras reglas. La planta empieza a ver su consumo específico real, y esta fase ya cambia conversaciones sin necesidad de ningún modelo.
- Modelo y simulación. Construcción del digital twin de la línea o del conjunto relevante y validación contra periodos históricos conocidos. Un modelo que no reproduce el pasado no sirve para explorar el futuro.
- Optimización. Exploración del punto de operación con las restricciones reales de calidad, contrato y seguridad puestas por escrito, y traslado del resultado a reglas, alertas, workflows y a la Operator Layer para que llegue al turno.
Las fases cuarta y quinta son trabajo de ingeniería, no configuración: el modelo hay que construirlo y validarlo con quien conoce el proceso. Ese trabajo se describe en el servicio de gemelo digital industrial.
Límites y cuándo no aplica
Este módulo se puede vender mal con mucha facilidad, así que conviene decir dónde no aplica antes de que lo descubra un proyecto a medias.
- Cuando el ritmo no es una variable libre. En procesos donde la velocidad la fija una receta de calidad, una homologación de producto o un compromiso contractual, no hay punto de operación que buscar: hay uno solo y es obligatorio. El módulo puede documentar su coste energético, que sirve para negociar o para justificar una inversión, pero no para decidir la operación diaria.
- Cuando la línea está saturada por demanda. Si todo lo que se produce se vende y la restricción es la capacidad, la planta no tiene ningún incentivo para buscar el mínimo de kWh por unidad si eso implica producir menos. El módulo sigue siendo útil como observatorio del consumo específico, pero el compromiso que optimiza no está en juego.
- Cuando falta una de las dos mitades del dato. Medida de energía sin contador de piezas, o contador de piezas sin submedida eléctrica de esa línea, dejan al módulo sin cociente. Lo que falta entonces es instrumentación, y es más honesto decirlo en el diagnóstico que fabricar una estimación con un reparto proporcional inventado.
- Cuando el histórico solo contiene un punto de operación. Una línea que siempre ha ido al mismo ritmo no ha generado la información necesaria para describir la curva. Se puede completar con simulación y con ensayos acotados, pero el resultado tendrá una incertidumbre mayor y así hay que presentarlo.
- Cuando el consumo dominante no depende del ritmo. En instalaciones donde la mayor parte de la energía se va en servicios que funcionan igual haya o no producción, el margen de este módulo es pequeño y el problema pertenece a optimización energética o directamente a un rediseño de instalación, que es trabajo de Captia Energy.
- Cuando lo que se busca es un objetivo de OEE. Maximizar el OEE y minimizar el consumo específico no siempre apuntan al mismo sitio, y forzar el indicador puede empeorar la factura. Si la organización solo va a mirar el OEE, la recomendación del módulo va a perder todas las discusiones. Esa decisión es previa y es de gestión, no de plataforma.
Y el límite transversal, común a todos los módulos: el módulo evidencia, simula y propone, pero no cambia consignas por su cuenta. Las restricciones de calidad y de seguridad son entradas del problema, no variables a optimizar, y la acción sobre el proceso la ejecuta la operación con las reglas y los workflows que el equipo define y supervisa.