Captia Technology

Saltar al contenido principal
Captia Technology

Módulo de IA de Captia.ai

Forecasting: el módulo de proyección de variables de Captia.ai

Proyecta la evolución futura de una variable a partir de su comportamiento pasado. Se apoya en el histórico consolidado de la variable con sus timestamps de origen.

Qué es y para qué sirve

¿Qué es el módulo de forecasting de Captia.ai?

Forecasting es el módulo de Captia.ai que proyecta la evolución futura de una variable de proceso a partir de su comportamiento pasado. Trabaja sobre el histórico consolidado de esa variable con sus timestamps de origen, capturados en el edge por Captia Connect, y devuelve la serie proyectada dentro de los dashboards, reglas, alertas y reporting de la plataforma.

Cómo funciona Forecasting dentro de Captia.ai

El módulo hace una sola cosa y la hace sobre cualquier variable de proceso: proyecta su evolución futura a partir de su comportamiento pasado. La variable puede ser la temperatura de un horno, la potencia activa de una línea, el nivel de un silo, la presión de la red de aire comprimido o el caudal de un circuito. Lo que no cambia es el insumo: el histórico consolidado de esa variable con sus timestamps de origen.

Conviene precisar qué significa timestamp de origen, porque es la pieza que separa un forecast defendible de uno que solo lo parece. Es la marca de tiempo asociada al instante en que la señal fue leída en planta, no el instante en que el dato llegó al servidor. Captia Connect adquiere la señal 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), la normaliza en series temporales y la envía a la plataforma con buffering local. Ese buffering es justo el motivo por el que la distinción importa: cuando la conectividad se corta y se restablece, un bloque de datos de dos horas de antigüedad llega de golpe. Si el sistema lo fechara por hora de llegada, la serie quedaría comprimida y desordenada, y el modelo aprendería una dinámica que nunca ocurrió. Con el timestamp de origen, ese mismo bloque cae en su sitio y el histórico conserva la separación real entre muestras.

A partir de ahí el procesamiento tiene tres movimientos. Primero, la reconstrucción de la serie sobre una rejilla temporal regular: alinear muestras, tratar huecos y decidir cómo se agrega cuando el muestreo nativo es más fino que la granularidad de trabajo. Segundo, la extracción de estructura: nivel, tendencia, ciclos ligados al calendario industrial (turno, día de la semana, parada programada) y dependencia de la variable respecto a sus propios valores recientes. Tercero, la proyección hacia un horizonte definido, con una banda de incertidumbre que crece con la distancia, porque un forecast sin banda no es una predicción sino una afirmación.

La salida vive donde ya trabaja el equipo: series proyectadas junto a la serie real en los dashboards por activo, línea, rol o planta; reglas y alertas que se disparan cuando la proyección cruza un umbral antes de que la variable lo cruce de verdad; eventos trazables en el histórico; reporting periódico; y API hacia ERP, MES, CRM o SAP cuando la proyección tiene que alimentar un sistema de gestión.

Entrada, procesamiento y salida del módulo Forecasting
CapaQué aportaDónde vive
EntradaHistórico consolidado de la variable con sus timestamps de origen, más el contexto de calendario y operación disponible en la plataformaCaptia Connect (edge) y el histórico de Captia.ai
ProcesamientoReconstrucción de la serie sobre rejilla regular, extracción de nivel, tendencia y ciclos, y proyección al horizonte con banda de incertidumbreMódulo Forecasting sobre los modelos industriales de la plataforma
SalidaSerie proyectada en dashboards, reglas y alertas anticipadas, eventos, reporting y APIs hacia ERP, MES, CRM o SAPCaptia.ai, en las mismas vistas que ya usa la operación

Todo lo anterior es lo que hace el módulo. La discusión metodológica de fondo (qué familia de modelos conviene, cómo se mide el error, qué baseline hay que batir) pertenece al recurso guía de forecast industrial: demanda, energía y señales de suministro, y el trabajo de modelado a medida sobre datos de operación se describe en modelos avanzados de IA.

Requisitos de datos: horizonte, granularidad e histórico

Antes de activar el módulo hay que fijar dos parámetros, y en este orden: el horizonte (hasta dónde se quiere ver) y la granularidad (con qué resolución). Los dos salen de la decisión que se quiere tomar, no de la tecnología. Si la decisión es escalonar arranques dentro del turno, el horizonte son horas y la granularidad minutos. Si la decisión es programar una parada de mantenimiento, el horizonte son semanas y la granularidad puede ser diaria. Pedir la resolución más fina posible sobre el horizonte más largo posible es el error de encargo más común: multiplica el número de puntos a predecir sin que ninguna decisión los use.

De esos dos parámetros se deriva el tercero, que es el requisito duro: cuánto histórico hace falta. La regla práctica no es un número absoluto, sino una relación. El histórico tiene que cubrir varias repeticiones completas del ciclo más lento que se quiere reproducir. Una variable con patrón semanal necesita muchas semanas para que el modelo distinga el patrón de una coincidencia; una variable con estacionalidad anual necesita haber vivido esas estaciones. Y el horizonte no puede estirarse más allá de lo que el histórico respalda: proyectar a tres meses una serie que solo tiene tres meses de pasado es extrapolación, no forecasting.

Relación entre horizonte, granularidad y calidad del histórico exigida
Decisión que se quiere tomarHorizonte y granularidad coherentesQué exige del histórico
Anticipar una consigna o un cruce de umbral dentro del turnoHorizonte de horas, granularidad de minutosMuestreo nativo fino, sin huecos largos y con timestamps de origen fiables; los ciclos intradía deben estar bien representados
Preparar la operación del día siguiente o del fin de semanaHorizonte de días, granularidad horariaVarias semanas de histórico continuo que incluyan días laborables, festivos y paradas programadas
Programar una intervención o dimensionar un recursoHorizonte de semanas, granularidad diariaHistórico que cubra varios ciclos completos del patrón de operación y, si la hay, la estacionalidad de la planta

Hay además tres condiciones de calidad que no se negocian. La primera es la continuidad: los huecos no son neutros, un tramo perdido de una hora en una serie de minuto elimina la referencia inmediata sobre la que se apoya la proyección a corto. La segunda es la identificación de la señal: una serie llamada sensor 7 se puede proyectar, pero nadie sabrá qué decisión soporta; la asociación de la señal a un activo, una línea o una zona es el trabajo de normalización de Captia Connect. La tercera es la homogeneidad del pasado: si a mitad del histórico se cambió el sensor, se movió el punto de medida o se reescaló la unidad, el modelo está aprendiendo de dos variables distintas pegadas.

Finalmente, el contexto. Una variable que depende de decisiones externas (calendario de producción, mezcla de producto, temperatura ambiente) se proyecta mejor cuando ese contexto está disponible en la plataforma o integrado desde ERP y MES. Sin contexto el módulo sigue proyectando, pero solo puede apoyarse en la inercia de la propia serie.

Casos de aplicación industrial

El caso más directo es la anticipación de un umbral. Un nivel de silo que se acerca al mínimo, una temperatura de proceso que deriva hacia el límite de calidad, una presión de red de aire que cae hacia la consigna crítica. La alerta clásica avisa cuando el límite ya se ha cruzado; con la serie proyectada, la regla se puede definir sobre la proyección y el aviso llega con margen para actuar. Ese es el cambio de fondo: pasar de reaccionar a preparar.

El segundo caso es la proyección de consumo energético a corto plazo. Ver hacia dónde va la curva de carga de las próximas horas permite decidir secuencias de arranque y cargas desplazables antes de que el pico ocurra. Es la pareja natural del módulo de optimización energética, que mira el consumo pasado y su relación con la actividad; forecasting mira el tramo que todavía no ha ocurrido.

El tercero es la planificación de recursos ligados a una variable física: caudal de entrada a una depuradora, temperatura ambiente que condiciona la carga de frío, ocupación de un almacén intermedio. En todos ellos la variable no es una demanda comercial, es una magnitud de proceso, y por eso corresponde a este módulo.

El cuarto es el uso de la proyección como referencia. Cuando existe una serie esperada, la diferencia entre lo real y lo proyectado se convierte en una señal por derecho propio: una desviación sostenida respecto a lo que la variable debería estar haciendo. Ahí conviene leer este módulo junto al de detección de anomalías, que trabaja precisamente sobre desviaciones del comportamiento normal.

Y una delimitación que evita confusiones. Si lo que se quiere estimar es la demanda que la planta va a tener que atender, es decir pedidos, volumen a producir o material a aprovisionar, el módulo indicado no es este sino el de previsión de demanda, que combina los históricos de producción con datos integrados de ERP y MES para dimensionar producción y recursos. Forecasting proyecta cualquier variable de proceso a partir de su propio pasado; previsión de demanda estima la demanda a atender. Comparten familia matemática y no comparten pregunta.

Cómo se implanta por fases

La implantación sigue las fases del resto de la plataforma, descritas en el hub de plataforma de datos industriales, y no empieza por el módulo.

  1. Diagnóstico. Se identifica la decisión que hoy se toma sin anticipación, y de ella se derivan la variable a proyectar, el horizonte y la granularidad. También se comprueba qué muestreo nativo ofrece el equipo: la granularidad de trabajo nunca puede ser más fina que la del sensor.
  2. Despliegue del edge. Captia Connect en planta, conexión de la señal, normalización a serie temporal, timestamp de origen y buffering local. A partir de aquí empieza a existir histórico apto para modelar.
  3. Puesta en marcha de la plataforma. La variable aparece en los dashboards y se acumula histórico observado. Esta fase tiene una duración que la marca el calendario, no el proyecto: hay que esperar a que el patrón se repita lo suficiente.
  4. Operacionalización. Reglas, alertas, workflows y reporting sobre la variable real, e integración por API si el dato debe llegar a ERP o MES. El equipo ya usa la serie antes de que exista proyección.
  5. Inteligencia. Con histórico suficiente se activa Forecasting. La proyección se compara primero contra la referencia más simple posible durante un periodo de observación, y solo cuando aporta sobre ella se conectan reglas y alertas a la serie proyectada.

Límites y cuándo no aplica

Este apartado ahorra proyectos mal planteados. Forecasting no aplica, o aporta poco, en estos escenarios:

  • Sin histórico, o con histórico más corto que el ciclo a reproducir. Una señal conectada la semana pasada no tiene pasado del que aprender. Y un histórico que no ha visto un ciclo completo no puede reproducirlo: proyectará el tramo que conoce y se equivocará justo en el punto de inflexión.
  • Cuando el proceso ha cambiado. Un cambio de receta, una máquina nueva, una modificación de la instalación o un cambio de régimen de turnos rompen la continuidad estadística del histórico. El pasado anterior al cambio deja de ser representativo, y a efectos prácticos el módulo vuelve al primer punto de esta lista.
  • Cuando la variable está dominada por decisiones humanas puntuales. Si el valor futuro depende de que alguien decida arrancar una línea o cambiar una consigna, no hay patrón que extrapolar. Lo que hace falta no es un modelo sino el dato de esa decisión, es decir integración con planificación.
  • Frente a eventos exógenos sin señal previa. Una avería súbita, un corte de suministro o una incidencia externa no están escritos en el pasado de la variable. Ningún forecast los anticipa, y prometer lo contrario es donde este tipo de proyectos se rompen.
  • Cuando se pide granularidad por debajo del muestreo real. Si el equipo entrega un valor cada quince minutos, no existe forma legítima de proyectar minuto a minuto. Lo que falta es instrumentación o configuración de adquisición, no analítica.
  • Cuando el horizonte pedido excede lo que el histórico respalda. Se puede calcular una proyección a un horizonte largo, pero la banda de incertidumbre se abre hasta dejar de ser accionable. Un intervalo tan ancho como el rango operativo de la variable no informa ninguna decisión.
  • Cuando la pregunta es otra. Si se quiere saber qué se va a tener que producir o aprovisionar, corresponde a previsión de demanda. Si se quiere detectar que algo va mal ahora, corresponde a detección de anomalías. Proyectar una variable no es la respuesta a todas las preguntas sobre el futuro.

Y un límite transversal, común a todos los módulos de la plataforma: Forecasting proyecta y evidencia, no ejecuta cambios de consigna por su cuenta. La acción sobre el proceso se decide con las reglas y los workflows que el equipo define y supervisa.

Preguntas frecuentes

Preguntas sobre forecasting en Captia.ai

¿Qué significa que el timestamp sea de origen y por qué importa?
El timestamp de origen es la marca de tiempo del instante en que la señal se leyó en planta, no la del instante en que el dato llegó al servidor. Importa porque Captia Connect hace buffering local: si se corta la conectividad, los datos retenidos llegan de golpe al restablecerse. Fechados por hora de llegada, la serie quedaría comprimida y el modelo aprendería una dinámica que nunca ocurrió.
¿Cuánto histórico hace falta para activar el módulo de forecasting?
No hay un número absoluto: la regla es relacional. El histórico debe cubrir varias repeticiones completas del ciclo más lento que se quiere reproducir, y ser bastante más largo que el horizonte de predicción. Una variable con patrón semanal necesita muchas semanas; una con estacionalidad anual necesita haber pasado por esas estaciones. El alcance concreto se fija en el diagnóstico.
¿En qué se diferencia forecasting de la previsión de demanda?
Forecasting proyecta cualquier variable de proceso (temperatura, potencia, nivel, presión, caudal) a partir de su propio pasado. Previsión de demanda estima la demanda que la planta tendrá que atender y combina los históricos de producción con datos integrados de ERP y MES para dimensionar producción y recursos. Comparten familia matemática, pero responden a preguntas distintas.
¿Hasta qué horizonte se puede predecir con fiabilidad?
Hasta donde el histórico lo respalde. El horizonte se fija a partir de la decisión que se quiere tomar (horas para actuar dentro del turno, días para preparar la operación, semanas para programar una intervención) y siempre por debajo de lo que el pasado disponible soporta. Más allá, la banda de incertidumbre se abre hasta que la proyección deja de ser accionable.
¿Puede el módulo predecir una avería o un corte de suministro?
No. Un evento exógeno sin señal previa en el histórico de la variable no es predecible por proyección: no está escrito en el pasado de la serie. Lo que sí ocurre es que muchos fallos vienen precedidos de una deriva lenta, y esa deriva sí es observable, aunque su terreno propio es la detección de anomalías y el mantenimiento predictivo.
¿El módulo actúa sobre el proceso cuando la proyección cruza un umbral?
El módulo proyecta y evidencia. La proyección puede alimentar reglas y alertas de Captia.ai que avisan con antelación, y esas reglas y workflows las define y supervisa el equipo. La actuación sobre consignas o equipos no la decide el módulo por su cuenta: esa separación entre análisis y actuación es deliberada en entornos industriales.

Enlaces relacionados

Seguir por aquí

Esta página describe la capacidad de producto. Si buscas la guía del tema o el servicio de ingeniería que lo implanta, están en otro sitio.

Los otros módulos de IA

Módulo de forecasting de series industriales | Captia.ai