Un historian industrial es una base de datos de series temporales especializada en telemetría de proceso: almacena cada muestra como una tupla de etiqueta, valor, marca de tiempo y calidad, sostiene la escritura continua de decenas de miles de señales y responde a consultas por rango temporal sobre años de histórico comprimido.
Qué guarda exactamente
El registro elemental de un historian tiene cuatro campos y no más: etiqueta, valor, marca de tiempo y calidad. La etiqueta identifica la señal; el valor puede ser analógico, digital o, con menos frecuencia, una cadena; la marca de tiempo idealmente es la del origen del dato, no la de su llegada; y la calidad es el indicador heredado del modelo OPC (bueno, malo, incierto, con subestados) que dice si el número es fiable. Ese cuarto campo es el que más se ignora y el que más daño hace cuando se ignora: un valor con calidad mala no equivale a un hueco, y tratarlo como bueno contamina cualquier media posterior.
Alrededor de cada etiqueta hay una ficha de configuración: descripción, unidades de ingeniería, tipo de dato, rango, modo de interpolación (escalonada para señales digitales y de estado, lineal para las analógicas) y los parámetros de compresión. El flujo de escritura es de inserción continua y prácticamente sin actualizaciones: un dato ya archivado casi nunca se corrige. Los datos que llegan tarde, típicos cuando un gateway industrial vacía su almacenamiento local tras una caída de enlace, se admiten pero son la operación cara del sistema, porque obligan a reabrir un archivo que ya estaba cerrado y comprimido.
Frecuencias de muestreo, volumen y retención
La frecuencia se elige por la física del proceso, no por costumbre. Las variables lentas de proceso, como temperaturas de horno, niveles de depósito o presiones de línea, se cubren de sobra con un segundo. Las señales de estado de máquina y los contadores de piezas se registran por cambio, no por periodo. Los consumos energéticos se llevan con periodo cuarto-horario u horario, alineados con el intervalo de facturación, porque la media instantánea no sirve para contrastar con la factura. Y en el extremo opuesto están los fenómenos rápidos: la forma de onda de una vibración o un armónico eléctrico se muestrea en kilohercios y no cabe en un historian de proceso; lo que se archiva ahí son los indicadores derivados (valor eficaz, amplitud por banda de frecuencia) calculados en el equipo de medida o en la capa de edge computing.
El volumen se calcula, no se estima a ojo. Diez mil etiquetas muestreadas a un segundo son 864 millones de muestras al día; el mismo conjunto a un minuto son 14,4 millones. Ese factor de sesenta es la razón de que la frecuencia se discuta señal a señal. La retención se organiza por capas: el detalle fino durante el horizonte en que alguien va a mirarlo para diagnosticar, y agregados de menor resolución para los años siguientes. Antes de fijar el horizonte conviene preguntarse qué ciclos hay que poder comparar: una campaña de producto, una temporada completa, un cambio de proveedor de materia prima.
Compresión: banda muerta y swinging door
Un historian no guarda todas las muestras que recibe, y ahí está su mayor virtud y su mayor riesgo. La reducción se aplica en dos etapas. La primera es la banda muerta o filtro de excepción, que actúa en el colector: el valor solo se envía si se ha movido más de un umbral respecto al último enviado. La segunda es la compresión propiamente dicha en el archivo, habitualmente mediante el algoritmo conocido como swinging door o puerta oscilante: en lugar de decidir muestra a muestra, el motor comprueba si una recta trazada entre el último punto archivado y el candidato actual deja todas las muestras intermedias dentro de una desviación admisible; mientras la recta las cubra, no archiva nada, y en cuanto una se sale, archiva el punto anterior y abre un tramo nuevo. Sobre eso se superponen dos guardas temporales: un tiempo máximo, que fuerza a archivar aunque la señal esté plana, y uno mínimo, que evita ráfagas.
Lo que se pierde con ese esquema conviene tenerlo escrito. Primero, la forma de la curva entre dos puntos archivados no existe: se reconstruye por interpolación, y toda variación que quedara dentro de la banda desapareció de forma irreversible. Segundo, los picos cortos de amplitud menor que el umbral no se grabaron nunca, que es justo el detalle que se busca cuando hay que explicar un defecto de calidad. Tercero, la serie resultante es irregular en el tiempo, de modo que una media aritmética de los puntos almacenados está sesgada hacia los tramos con más actividad: el agregado correcto sobre una serie comprimida es la media ponderada por tiempo. Cuarto, los umbrales suelen quedarse en el valor por defecto que puso quien instaló el sistema, aplicado por igual a señales con dinámicas muy distintas. La regla práctica es que la banda muerta es una decisión de ingeniería que no admite marcha atrás: lo que no se grabó no se puede recuperar.
Por qué no basta una base relacional convencional
Un esquema relacional genérico de tres columnas (etiqueta, instante, valor) funciona hasta que deja de funcionar, y deja de funcionar por acumulación. Cada muestra ocupa una fila con su sobrecarga de cabecera y de índice, con frecuencia mayor que el propio dato útil. La inserción continua obliga a mantener índices en árbol que se fragmentan y encarecen la escritura a medida que la tabla crece. El borrado por antigüedad, que en este dominio es una tarea diaria, se convierte en una operación masiva de filas. Y las consultas típicas, una lista de etiquetas entre dos instantes agregada por hora, recorren miles de millones de filas sin ninguna estructura que aproveche que los datos llegan ordenados en el tiempo.
A eso se suma lo que un motor genérico no sabe hacer y el dominio necesita a diario: devolver una serie interpolada a intervalo fijo a partir de valores grabados por excepción, distinguir interpolación escalonada de lineal según el tipo de señal, calcular medias ponderadas por tiempo, totalizar un caudal o una potencia por integración, o aplicar políticas de retención distintas por resolución. La frontera real, por tanto, no es «relacional contra historian»: un motor relacional con extensión de series temporales (particionado por tiempo, compresión columnar, agregados continuos) cubre bien el patrón. La frontera es entre un esquema genérico orientado a filas y un motor que asume que el tiempo es la clave primaria.
Historian, base del SCADA y data lakehouse
En una planta española media lo habitual no es encontrar un historian, sino sus sustitutos: las tendencias del propio SCADA con retención de semanas, el registrador interno de un analizador de red, los ficheros que exporta la máquina de un fabricante concreto y una colección de hojas de cálculo con lecturas manuales. Cada isla conserva su propio horizonte y su propia nomenclatura, y por eso la pregunta que dispara el proyecto casi nunca es «necesitamos un historian», sino «por qué no podemos comparar el consumo de esta línea con el del año pasado».
La base de datos de un SCADA y un historian se parecen en que ambas guardan tendencias, y se diferencian en todo lo demás. La del SCADA existe para dar contexto a la pantalla de operación: retención corta, subconjunto de etiquetas dimensionado para la supervisión, esquema propietario acoplado al producto y un servidor que es equipamiento crítico de sala de control. El historian es un sistema dedicado, con años de horizonte, funciones de recuperación propias del dominio y capacidad de absorber consultas sin poner en riesgo la supervisión. Por eso el patrón habitual es que el historian se alimente del SCADA, o directamente de los PLCs, y no que sustituya su función.
Con un data lake o un data lakehouse la relación es de complemento. Un historian impone el esquema al escribir: cada valor entra atado a una etiqueta conocida, y ese compromiso previo es lo que le permite responder en milisegundos a la pregunta que domina la operación, dame esta variable entre estas dos horas. Un lakehouse hace lo contrario: almacena ficheros columnares sobre almacenamiento de objetos barato, con un formato de tabla que le añade transaccionalidad y versiones, decide buena parte del esquema al leer y está pensado para recorrer volúmenes grandes y cruzar dominios distintos (producción con calidad, con energía, con el ERP) en consultas que tardan segundos o minutos y no molestan a nadie. Si la pregunta es de proceso y de una señal concreta, el historian; si es analítica, agregada y multidominio, el lakehouse. La arquitectura sensata alimenta ambos desde el mismo flujo de captura y evita el error clásico de convertir el historian en almacén corporativo o el lago en visor de tendencias; el reparto completo está en la guía de plataforma de datos industriales.
Qué implica meter el dato y sacarlo hacia la capa de datos
La entrada define el techo de calidad. El dato llega por colectores desde el SCADA, por OPC-UA contra los controladores o por suscripción a un broker MQTT, casi siempre a través de un gateway industrial que sella el tiempo junto a la máquina y retiene localmente si el enlace cae. La latencia de esa cadena suma el ciclo de sondeo del origen, el umbral de excepción y el periodo de publicación; para tendencias e indicadores de turno sobra, y para correlacionar eventos con resolución de milisegundos hay que fechar en el origen y sincronizar relojes por NTP. Ninguna de estas operaciones toca la lógica de control: el historian vive del lado de los sistemas de información y la captura es pasiva, con la carga acotada agrupando señales y dimensionando el periodo.
El direccionamiento es el nombre de la etiqueta, y eso es un problema. El modelo semántico real de un historian es su lista de tags, heredada de la instrumentación y del criterio del integrador: nombres crípticos, incoherentes entre líneas equivalentes y sin noción de orden de fabricación, lote, producto ni turno. Poner ese contexto no es trabajo del historian sino de la capa de datos que lo rodea, y es lo que convierte una serie de números en algo que responde preguntas de negocio. Un Unified Namespace es una de las formas habituales de fijar esa nomenclatura antes de que el dato se archive.
La salida se pide por etiqueta y rango. Se consulta mediante interfaz SQL, API o el SDK del producto, y hay una decisión que altera los resultados sin avisar: pedir los valores tal como se archivaron o pedirlos interpolados a intervalo regular. El mismo turno puede dar medias distintas según el modo elegido, así que el criterio de recuperación y el de agregación se fijan antes de calcular ningún indicador, no después de discutir por qué dos informes no cuadran. En cuanto a carga, una exportación masiva compite con las consultas interactivas: las extracciones grandes se programan fuera de hora o contra una réplica, y siempre con credenciales de solo lectura.
Cómo se explota: consulta, agregados y modelos
El uso más inmediato es la consulta directa: reconstruir las horas previas a una avería, comparar dos campañas del mismo producto, verificar con datos si una modificación mejoró algo. Por encima está el cálculo de agregados, que en series de proceso tiene sus propias reglas: medias ponderadas por tiempo en vez de aritméticas, máximos y mínimos con su instante, tiempo acumulado en cada estado, y totalizados por integración cuando la señal es un caudal o una potencia y lo que interesa es el volumen o la energía. Esos agregados son la materia prima de los indicadores de planta, incluido el OEE, siempre que se les añada el contexto que el historian no guarda.
Alimentar modelos de analítica o de inteligencia artificial exige un paso más. Un modelo necesita una rejilla temporal regular y todas las señales alineadas en ella, así que la serie comprimida hay que remuestrearla, decidiendo por señal si la interpolación es escalonada o lineal; necesita un tratamiento explícito de los huecos y de las muestras con calidad mala; y necesita etiquetas de sucesos (averías, paradas, defectos, lotes) que no viven en el historian sino en el GMAO, en el MES o en el ERP. Hay además un límite que conviene comprobar antes de invertir en modelado: si el fenómeno que se quiere anticipar es de amplitud menor que la banda muerta con la que se archivó la señal, ningún modelo lo va a encontrar, porque esa variación no está en los datos. Con esa salvedad, el histórico es la base sobre la que se construye la detección de anomalías y el mantenimiento predictivo.
Relación con otros términos
El historian se sitúa aguas abajo de la captura: se alimenta del SCADA y de los PLCs por OPC-UA o por suscripción a MQTT, y aguas arriba entrega su serie al data lakehouse para la analítica multidominio. Construir ese recorrido de extremo a extremo es el objeto de la integración OT/IT, y explotar el histórico resultante, el de la analítica operacional.