Contextualización de datos industriales: del valor crudo al dato con significado

La contextualización de datos industriales es el proceso de enriquecer los valores crudos que producen máquinas y sensores con el significado que les falta: qué activo los generó, en qué unidad están, a qué orden de fabricación pertenecen, en qué turno y en qué estado estaba la línea. Sin ese contexto, un histórico de planta es una colección de números; con él, es la base de indicadores, trazabilidad y modelos. En esta guía vemos qué capas de contexto existen, dónde se añaden y cómo se gobierna el modelo de datos que las sostiene.

Qué es la contextualización de datos industriales

Un PLC no sabe qué está fabricando. Cuando publica el registro 40012 con el valor 1.847, esa cifra es verdad, pero es una verdad muda: no dice si son piezas o milímetros, ni de qué máquina viene, ni si la línea estaba produciendo el artículo A o el artículo B. Todo eso lo sabe alguien (el programador que mapeó el registro, el encargado que lanzó la orden), pero no viaja con el dato. La contextualización es la disciplina de adjuntar ese conocimiento al valor de forma sistemática, de modo que cualquier consumidor (un dashboard, un cálculo de OEE, un modelo) pueda usarlo sin preguntar a nadie.

Conviene distinguirla de la normalización, con la que suele confundirse. La normalización resuelve la forma: unidades coherentes, escalas correctas, marcas de tiempo de origen. La contextualización resuelve el significado: qué es este dato dentro del negocio. Una plataforma necesita las dos, y en ese orden: primero un valor bien formado, después un valor bien situado.

Por qué el dato crudo no sirve al negocio

La consecuencia práctica de la falta de contexto es que cada consumidor tiene que reconstruirlo por su cuenta. El analista que quiere calcular el rendimiento por referencia cruza a mano el histórico de contadores con el listado de órdenes del ERP; el ingeniero que investiga un lote defectuoso persigue en tres sistemas qué máquina, qué parámetros y qué turno coincidieron; el dashboard de dirección muestra un consumo eléctrico total que nadie puede repartir por línea. El coste no está en capturar el dato, que ya se capturó: está en interpretarlo una y otra vez, con criterios distintos cada vez.

Esa reconstrucción repetida es, además, la fuente principal de discrepancias entre informes: dos personas que cruzan las mismas señales con reglas ligeramente distintas producen dos verdades. La contextualización ataca la raíz: el cruce se hace una vez, con una regla pactada, y el resultado se publica para todos.

Las cinco capas de contexto

No todo el contexto es igual ni se añade en el mismo sitio. Ayuda pensarlo en cinco capas, de la más física a la más de negocio:

• Contexto de señal. Qué magnitud es, en qué unidad, con qué rango válido y con qué calidad de lectura. Es la capa que convierte el registro 40012 en "contador de piezas buenas, unidades, entero acumulativo".
• Contexto de activo. Qué máquina, línea, área y planta generaron el valor. Se expresa como posición en una jerarquía de activos, y es lo que permite agregar por línea o comparar máquinas equivalentes.
• Contexto de producción. Qué orden de fabricación, qué referencia de producto y qué lote estaban en curso cuando se produjo el valor. Es la capa que hace posible la trazabilidad y el análisis por referencia.
• Contexto operativo. Qué turno, qué equipo de personas y en qué estado estaba la línea (produciendo, parada, cambio de formato). Sin él, una media de velocidad mezcla producción real con paradas y no significa nada.
• Contexto de negocio. Las dimensiones que importan aguas arriba: cliente, pedido, coste energético del periodo. Suele añadirse en la capa de datos, cruzando con el ERP, y es el que convierte indicadores técnicos en información de gestión.

El modelo canónico: nombres y jerarquía

Todas las capas anteriores necesitan un esqueleto común: un modelo canónico de datos que defina cómo se llaman las cosas y cómo se organizan. En la práctica tiene dos piezas. La primera es la jerarquía de activos (planta, área, línea, máquina, señal), que en una arquitectura moderna se materializa como el árbol de topics del unified namespace: la posición de un dato en el árbol ya es contexto de activo. La segunda es el diccionario de señales: para cada tipo de señal, su nombre de negocio, su unidad y su semántica, iguales en todas las máquinas equivalentes. Si la temperatura de husillo se llama igual en las cuatro inyectoras, comparar máquinas es una consulta; si se llama de cuatro formas, es un proyecto.

El modelo canónico no es un documento decorativo: es un contrato. Cuando los conjuntos de datos contextualizados se publican a los consumidores de negocio, ese contrato se formaliza con esquema, unidades y frecuencia explícitos, como desarrollamos en la guía de contratos de datos industriales.

Dónde contextualizar: edge o plataforma

La pregunta de arquitectura es dónde se adjunta cada capa. La respuesta corta: cada contexto se añade en el punto más cercano a donde se conoce, y lo antes posible.

La regla que ordena la tabla: lo que describe el hecho físico se congela con el dato en el edge; lo que lo interpreta se cruza después en la capa de datos de la plataforma de datos industriales, donde el historian conserva el detalle y las transformaciones producen los conjuntos contextualizados. Adjuntar la orden de fabricación en el edge parece eficiente, pero acopla el gateway al MES y convierte cada cambio de sistema de negocio en un cambio de planta.

Ejemplo práctico: de la señal al indicador

Veamos el recorrido completo con un caso genérico. Una línea de envasado tiene un contador de ciclos en el PLC que crece de 0 a 65.535 y desborda. El objetivo de negocio: unidades buenas por referencia y por turno.

• Captura y contexto de señal (edge). El gateway lee el contador cada 2 segundos por Modbus, resuelve el desbordamiento, marca la calidad y sella con marca de tiempo de origen. El valor ya es "ciclos acumulados, unidades, fiable".
• Contexto de activo (edge). Se publica en el árbol bajo la rama de su línea y máquina. Cualquier consumidor sabe de dónde viene sin tabla auxiliar.
• Contexto de producción (capa de datos). Un cruce con las órdenes del ERP asigna cada intervalo de ciclos a la orden y referencia en curso. Los 43.200 valores diarios del contador se convierten en tramos por orden.
• Contexto operativo (capa de datos). El calendario de turnos y la señal de estado de línea separan producción real de paradas. Un turno de 8 horas con 90 minutos de parada aporta 6,5 horas de denominador, no 8.
• Resultado. Una tabla contextualizada con fecha, turno, línea, orden, referencia, unidades buenas y tiempo productivo. Sobre ella, el indicador por referencia es una consulta trivial, y la misma tabla alimenta dashboards, informes y modelos sin volver a interpretar nada.

Errores comunes al contextualizar

Dejar la contextualización para la analítica. "Ya lo cruzará el analista" significa que cada análisis paga el cruce de nuevo y con reglas propias. El contexto compartido se construye una vez, en la plataforma, no en cada cuaderno de análisis.

Codificar contexto de negocio en nombres de señal. Incluir la referencia del producto o el nombre del cliente en el nombre del tag congela en la planta algo que cambia cada semana. Los nombres codifican lo estable (activo y magnitud); lo variable se cruza como dato.

Jerarquía de activos improvisada. Si cada integrador inventa su rama del árbol, el contexto de activo degenera en el mismo caos que había antes, solo que mejor transportado. La jerarquía se pacta por escrito antes de conectar la segunda máquina.

Estados de línea sin definición pactada. Si "parada" significa cosas distintas para producción y para mantenimiento, todos los indicadores derivados heredan la ambigüedad. La lógica de estados es una decisión de negocio que se documenta, no un ajuste técnico.

Contextualizar sin conservar el crudo. El dato enriquecido responde las preguntas de hoy; el crudo con su marca de tiempo responde las de mañana. Se publican los conjuntos contextualizados y se conserva el detalle original en el historian: nunca es una sustitución.

Preguntas frecuentes sobre contextualización

Si tu planta ya captura datos pero cada informe exige volver a cruzarlos a mano, en Captia Connect construimos la cadena que lo resuelve: captura y normalización en el edge, jerarquía de activos pactada y una plataforma de datos industriales donde el contexto se añade una vez y sirve a todos. El primer paso es definir el modelo canónico sobre un caso de uso concreto.