Historian industrial: qué es, qué guarda y cuándo lo necesitas

Un historian industrial es una base de datos especializada en series temporales de proceso: registra millones de valores con marca de tiempo (temperaturas, caudales, contadores, estados) y los conserva durante años de forma que consultarlos siga siendo rápido. Es la memoria de la planta. En esta guía vemos en qué se diferencia de una base de datos convencional y de un data lake, qué guarda exactamente, dónde encaja dentro de una plataforma de datos industriales y cómo estimar su volumen con un ejemplo numérico.

Qué es un historian industrial

Toda planta genera un flujo continuo de valores: el PLC actualiza contadores cada ciclo, los sensores publican temperaturas y presiones, el SCADA registra alarmas y cambios de estado. Ese flujo es efímero por naturaleza; si nadie lo persiste, el valor de hace una hora ya no existe. El historian (también llamado historiador de planta o data historian) es el componente que convierte ese flujo en histórico: escribe cada valor con su marca de tiempo y su indicador de calidad, lo comprime y lo deja disponible para consulta durante años.

Su razón de ser es una asimetría técnica: el patrón de escritura de una planta (muchísimos valores pequeños, ordenados por tiempo, que nunca se modifican después) no se parece en nada al patrón para el que se diseñaron las bases de datos transaccionales. De esa asimetría nacen tanto los historians clásicos de los grandes fabricantes como las bases de datos de series temporales de código abierto, como InfluxDB, que cumplen el mismo papel con un modelo de licencia distinto. En esta guía usamos "historian" para toda la categoría: lo relevante es la función, no la marca.

Tres preguntas resume lo que un historian responde bien:

• ¿Qué valor tenía esta señal en este instante? Reconstruir el estado de la línea en el momento de un fallo, minuto a minuto.
• ¿Cómo ha evolucionado esta señal en este periodo? Tendencias de un mes de temperatura de un horno o del consumo de una línea.
• ¿Cuál es el agregado por intervalo? Medias horarias, máximos por turno, contadores por día: la materia prima de OEE, informes y modelos.

Historian frente a base de datos convencional

La objeción habitual es razonable: si la empresa ya tiene una base de datos relacional, ¿por qué no guardar ahí las señales? Se puede, y de hecho muchas plantas empiezan así, hasta que el volumen manda. Una base relacional trata cada valor como una fila genérica: índices pensados para actualizaciones, transacciones que aquí no aportan nada y un coste de almacenamiento por valor muy superior. Con unas decenas de señales funciona; con miles, las consultas de rangos largos degradan y el mantenimiento de índices y particiones se convierte en un trabajo en sí mismo.

El historian invierte las prioridades. Asume que el dato llega ordenado por tiempo y no se modifica jamás, y a cambio ofrece escritura masiva sostenida, compresión específica de series temporales y funciones de consulta que una base relacional no tiene de serie: remuestreo, agregados por ventana, interpolación, último valor conocido por señal. No sustituye a la base de datos de negocio (órdenes, maestros, usuarios siguen viviendo en el mundo relacional); la complementa en el terreno donde el modelo relacional rinde peor.

Qué guarda exactamente: tags, calidad y compresión

La unidad de trabajo del historian es el tag: una señal identificada por un nombre, con una serie de valores en el tiempo. Cada muestra almacena al menos tres cosas: la marca de tiempo (idealmente la de origen, la del equipo que midió, no la de llegada al servidor), el valor y un indicador de calidad que dice si la lectura era fiable en ese instante. Ese tercer campo es el que separa un histórico serio de una tabla de números: cuando el gateway pierde la conexión con el PLC, el hueco queda marcado como tal, y quien consulte dentro de dos años sabrá que ahí no hubo dato, no que el valor fue cero.

La compresión merece entenderse porque afecta a lo que verás después. Hay dos familias: la compresión sin pérdida, que aprovecha que los valores consecutivos se parecen para codificarlos en pocos bits, y el filtrado por banda muerta (deadband), que directamente descarta muestras cuando el valor no ha cambiado más que un umbral. La segunda ahorra mucho más espacio, pero es una decisión de ingeniería: un deadband mal elegido borra precisamente la microvariación que un análisis posterior necesitaba. La regla práctica es conservadora: banda muerta estrecha o nula en señales de proceso crítico, más agresiva en señales lentas y estables.

Historian vs data lake industrial

La comparación que hoy domina las conversaciones de arquitectura ya no es historian contra base relacional, sino historian contra data lake industrial: el almacén analítico, normalmente en la nube, donde el dato de planta se junta con el de negocio para análisis a gran escala. Se presentan a veces como alternativas, y no lo son: resuelven preguntas distintas sobre el mismo dato.

La arquitectura sana no elige: encadena. El historian captura y sirve el detalle en planta; el data lake recibe, desde la plataforma, los agregados y extractos que la analítica necesita, publicados como conjuntos de datos con esquema y frecuencia pactados. Ese contrato entre ambos mundos es exactamente el tema de la guía de contratos de datos industriales. El error caro es el atajo inverso: volcar el dato crudo de planta al lake "para tenerlo todo" y descubrir después que sin contexto ni gobernanza nadie puede usarlo.

Su lugar en la plataforma de datos

En una plataforma de datos industriales por capas, el historian vive en la capa de datos y se comporta como un consumidor más: se suscribe al broker y persiste todo lo que circula por el namespace. Esa posición tiene dos consecuencias prácticas que conviene subrayar.

La primera: el historian no debe ser la fuente de integración. En muchas plantas el histórico acabó haciendo de distribuidor: cada aplicación nueva consultaba el historian porque era el único sitio donde estaba todo. Eso lo convierte en cuello de botella y acopla todas las aplicaciones a su esquema. En la plataforma, la distribución en tiempo real la hace el broker; el historian guarda y sirve histórico, que es lo que hace bien.

La segunda: la completitud del histórico se gana en el edge, no en el servidor. Si el gateway no tiene almacenamiento local persistente, cada corte de red abre un hueco que ningún historian puede rellenar después. El mecanismo de store-and-forward que lo evita está desarrollado en la guía de edge industrial con buffering y QoS, y el patrón de distribución al que el historian se suscribe, en la de unified namespace y MQTT Sparkplug B.

Dimensionamiento: un ejemplo numérico

Los números del historian asustan menos cuando se hacen las cuentas. Tomemos una planta mediana genérica: 4 líneas, 500 señales en total, con un muestreo medio de una lectura cada 5 segundos por señal.

• Escrituras por segundo: 500 señales / 5 s = 100 valores por segundo. Cualquier base de series temporales moderna sostiene esto en un servidor modesto; el orden de magnitud problemático empieza varios ceros más arriba.
• Muestras por año: 100 por segundo son 8,64 millones al día, unos 3.150 millones al año.
• Volumen en disco: con un coste bruto de 16 bytes por muestra serían unos 50 GB al año; con la compresión típica de series temporales (valores consecutivos parecidos) la cifra real suele quedar en una fracción de eso. Incluso sin compresión, cinco años de histórico caben en un disco corriente.
• Con deadband: si la mitad de las señales son lentas y un filtrado por banda muerta descarta el 80 por ciento de sus muestras, el volumen anual baja aproximadamente a la mitad. Es la palanca de ahorro más potente y también la más delicada, como vimos arriba.

Moraleja: para una planta mediana, el historian no es un problema de coste de almacenamiento; es un problema de diseño. Lo que determina su valor no son los gigabytes sino las decisiones previas: qué señales entran, con qué nombres, con qué resolución y con qué marca de tiempo.

Errores comunes con el historian

Historizar sin convención de nombres. Un histórico donde la misma magnitud se llama de tres formas según quién configuró el tag es un histórico que solo entiende su autor. La jerarquía de nombres se pacta antes de crear el segundo tag, igual que en el namespace de la plataforma.

Guardar la marca de tiempo de llegada. Si el valor se sella al entrar en el servidor y no en origen, cualquier retraso de red reordena la historia. Los análisis de causa raíz, que dependen de saber qué pasó antes y qué después, quedan comprometidos sin remedio.

Deadband agresivo por defecto. Configurar la misma banda muerta para todas las señales ahorra disco hoy y destruye análisis mañana. El filtrado se decide señal a señal, con criterio de proceso.

Usarlo como integrador universal. Diez aplicaciones consultando el historian en bucle para enterarse "de lo último" es el síntoma clásico de que falta una capa de distribución. Lo último viaja por el broker; el historian es para la historia.

No probar la restauración. Un histórico de años solo vale lo que valga su copia de seguridad, y una copia que nunca se ha restaurado es una hipótesis. La prueba de recuperación se calendariza como cualquier otro mantenimiento.

Preguntas frecuentes sobre el historian industrial

Si estás valorando cómo dotar a tu planta de un histórico de proceso fiable, en Captia Connect desplegamos la cadena completa: captura multiprotocolo en el edge, buffering local para que los cortes de red no abran huecos y persistencia en series temporales dentro de una plataforma de datos industriales que sirve el dato a operación y a negocio. El primer paso es un inventario de señales y protocolos.