Contratos de datos industriales: esquemas, calidad y linaje

Un contrato de datos industriales es un acuerdo explícito y verificable sobre qué publica cada fuente de datos de planta: qué campos lleva, en qué unidades, con qué frecuencia y quién responde cuando algo cambia. Convierte el dato de planta en un producto con garantías, en lugar de un flujo que cada consumidor interpreta a su manera. A lo largo del texto desgranamos las cuatro piezas del contrato (esquema, calidad, linaje y versionado) y la pregunta que las sostiene todas: quién es dueño de cada dato.

Qué es un contrato de datos industriales

En software de datos corporativo, el término data contract designa un acuerdo formal entre quien produce un conjunto de datos y quienes lo consumen: estructura, semántica, calidad y condiciones de evolución quedan escritas y son verificables por máquina. La idea viene del mundo de los almacenes de datos y las arquitecturas tipo data mesh, pero encaja de forma natural en planta, donde el problema es todavía más agudo: los productores son PLCs, sensores y sistemas MES que nadie diseñó pensando en los analistas que consumirán sus señales diez años después.

La situación habitual sin contrato la reconoce cualquiera que haya integrado datos de fábrica. Un integrador configura un gateway que publica la temperatura de un horno en un tópico MQTT. Dos años más tarde, un equipo de mejora monta un dashboard que lee ese tópico. Nadie documentó si la temperatura va en grados Celsius o Fahrenheit, si el valor es instantáneo o una media móvil, ni qué significa que el campo llegue vacío. El dashboard funciona hasta que alguien recalibra el sensor, cambia el nombre del campo o ajusta el intervalo de muestreo. Entonces el panel muestra datos erróneos sin avisar, y la confianza en todo el sistema se resiente.

Un contrato de datos ataca ese problema por escrito. Para cada flujo relevante define cuatro cosas:

• Esquema: qué campos existen, de qué tipo son y qué significan.
• Calidad: qué garantías da el productor sobre completitud, frecuencia, rangos válidos y unidades.
• Linaje: de dónde viene cada valor y qué transformaciones ha sufrido antes de llegar al consumidor.
• Evolución: cómo se versiona el esquema y qué proceso sigue un cambio que rompe compatibilidad.

A lo largo del artículo usaremos un ejemplo único: el sensor de temperatura del horno de curado de una línea de pintura. Es un caso deliberadamente pequeño, porque la tesis central de los contratos de datos es que el rigor se aplica flujo a flujo, no con un big bang documental. Ese sensor publica cada cinco segundos en un tópico de un broker MQTT, dentro de una jerarquía de nombres organizada como unified namespace. Cada sección añadirá una capa de contrato sobre él.

El esquema: qué promete cada tópico y cada tabla

El esquema es la parte del contrato que describe la forma del dato. En un entorno industrial hay dos superficies típicas donde vive esa forma: los tópicos de mensajería (MQTT, Kafka) y las tablas o vistas donde el dato acaba persistido (historian, base de datos de series temporales, almacén analítico). Ambas necesitan esquema, y ambas necesitan que el esquema diga más que los tipos.

Para el horno de curado, un esquema útil del tópico no se limita a decir que value es un número. Dice, como mínimo:

topic: planta-valencia/pintura/horno-curado/temperatura
payload:
  value:      float      # temperatura en °C, resolución 0,1
  timestamp:  ISO 8601   # hora de muestreo en el sensor, zona UTC
  quality:    enum       # GOOD | UNCERTAIN | BAD (semántica OPC UA)
  source_id:  string     # tag del PLC de origen: TT-4012

Cada línea es una promesa. El productor promete que la unidad es el grado Celsius y no cambiará sin aviso. Promete que el timestamp es el del muestreo en origen, no el de llegada al broker, un matiz que decide si los análisis de proceso son fiables. Promete un indicador de calidad por mensaje, siguiendo la semántica de códigos de estado que popularizó OPC UA, de modo que el consumidor pueda distinguir un valor bueno de uno sospechoso sin adivinar.

El formato concreto importa menos que la existencia del acuerdo. En ecosistemas MQTT industriales, la especificación Sparkplug B de la Eclipse Foundation resuelve parte del problema de serie: define la estructura del payload, el tipado de métricas y los mensajes de nacimiento (birth certificates) en los que cada nodo declara qué métricas publica y de qué tipo. Ese birth certificate es, de hecho, un esquema autodeclarado. En pipelines sobre Kafka o en APIs REST, el papel lo cumplen Avro, Protobuf o JSON Schema junto a un registro de esquemas. Y en el extremo de las tablas, los tests de datos (del estilo de los que popularizó dbt) verifican que cada columna cumple lo pactado en cada carga.

Lo que ningún formato resuelve solo es la semántica. Que el campo se llame temperatura no dice si es la del aire del horno o la de la superficie de la pieza. Esa capa la aporta la descripción textual del contrato y, cuando existe, el modelo de información del dominio: las companion specifications de OPC UA para sectores concretos, o el modelo de equipos jerárquico de ISA-95 que suele dar estructura al propio unified namespace. La regla práctica: si dos ingenieros pueden leer el nombre de un campo y entender cosas distintas, el esquema todavía no está terminado.

Calidad del dato industrial: completitud, frecuencia y unidades

El esquema dice qué forma tiene el dato; la sección de calidad del contrato dice qué garantías operativas ofrece. En datos de planta, tres dimensiones concentran la mayoría de los problemas reales.

Completitud

¿Qué porcentaje de las muestras esperadas llega de verdad? Un sensor que publica cada cinco segundos debería generar 17.280 muestras al día; si llegan 15.000, hay un 13 % de huecos que cualquier media diaria arrastrará en silencio. El contrato debe fijar un umbral de completitud y, más importante, qué significa un hueco: ¿ausencia de mensaje, mensaje con valor nulo o último valor retenido? Las tres convenciones existen en planta y mezclan mal. Los protocolos con buffering en el edge (store and forward) reducen las pérdidas por cortes de red, pero introducen llegadas tardías que el consumidor debe saber tratar: de ahí que el timestamp de origen sea obligatorio en el esquema.

Frecuencia y puntualidad

No es lo mismo la frecuencia de muestreo (cada cuánto mide el sensor) que la de publicación (cada cuánto se envía) ni que la latencia extremo a extremo (cuánto tarda en estar disponible para el consumidor). El contrato debe distinguirlas. Para el horno de curado: muestreo cada 5 segundos, publicación por cambio de valor con banda muerta de 0,5 °C, latencia máxima de 30 segundos hasta el historian. Un dashboard de supervisión vive bien con esa latencia; un enclavamiento de seguridad, no, y por eso los enclavamientos no se construyen sobre esta capa. Explicitar el uso previsto evita que alguien construya sobre el flujo algo que el flujo no puede sostener.

Unidades y rangos

Las unidades son el error más barato de prevenir y el más caro de descubrir tarde. El contrato fija la unidad de cada campo y el rango físicamente plausible: el horno de curado opera entre 120 y 200 °C, de modo que un valor de 950 es con toda probabilidad un fallo de sensor o un cambio de escala aguas arriba, y debe marcarse como calidad BAD en lugar de entrar en las medias. Estas validaciones se ejecutan donde el dato entra al sistema, típicamente en el gateway o en la capa de integración OT/IT, que es el punto natural para hacer cumplir contratos porque es donde el dato cruza de un dominio organizativo a otro.

Una tabla resume las tres dimensiones aplicadas al ejemplo:

Linaje: del sensor al dashboard sin saltos de fe

El linaje responde a la pregunta que aparece siempre en la peor reunión posible: este número del dashboard, ¿de dónde sale exactamente? En un pipeline industrial típico, la temperatura del horno atraviesa cinco o seis etapas antes de llegar a un panel: el sensor físico, la entrada analógica del PLC con su escalado, el gateway que lee el tag y lo publica, el broker, el proceso de ingesta que lo escribe en la base de series temporales y las agregaciones que calculan medias por lote o por turno. Cada etapa puede transformar el valor, y cada transformación no documentada es un salto de fe.

Documentar el linaje no exige herramientas exóticas. La versión mínima es una cadena explícita en el propio contrato: tag TT-4012 del PLC del horno, escalado 4-20 mA a 0-300 °C en la tarjeta de entrada, publicado sin transformación por el gateway, media móvil de 1 minuto calculada en la ingesta, media por lote calculada en la capa analítica. Con esa cadena escrita, cuando el panel muestra un lote a 168 °C cualquiera puede recorrer el camino inverso y localizar en qué etapa buscar un problema. Sin ella, la investigación empieza por arqueología de configuraciones.

Dos prácticas hacen el linaje sostenible. La primera: conservar el dato crudo. Las agregaciones se recalculan; los valores originales del sensor, no. Si la media móvil resulta estar mal parametrizada, tener el crudo permite corregir la historia completa. La segunda: propagar el identificador de origen (source_id en nuestro esquema) por todas las etapas, de forma que cualquier registro agregado pueda rastrearse hasta los tags que lo alimentaron. En ecosistemas de datos generalistas, estándares abiertos como OpenLineage formalizan esta traza a nivel de jobs y datasets; en planta, la disciplina de identificadores estables dentro de un espacio de nombres jerárquico cumple gran parte de la misma función.

Versionado de esquemas: cambiar sin romper

Los esquemas cambian, y un contrato que no prevé el cambio se rompe con el primer proyecto de mejora. La distinción central viene de la ingeniería de APIs: hay cambios compatibles hacia atrás y cambios que rompen. Añadir un campo opcional (por ejemplo, la consigna del horno junto a la temperatura medida) es compatible: los consumidores existentes lo ignoran. Renombrar value, cambiar la unidad a Fahrenheit o convertir un campo opcional en obligatorio rompe a todo el que lee el flujo.

El contrato fija reglas para ambos casos:

1. Los cambios compatibles se despliegan sin ceremonia, pero se registran: el esquema tiene un número de versión y un historial de cambios, igual que el código.
2. Los cambios que rompen exigen versión nueva y convivencia: el productor publica la versión 2 en paralelo a la 1 durante un periodo pactado, los consumidores migran a su ritmo y la versión antigua se retira con fecha anunciada. En un unified namespace esto se materializa de forma natural incluyendo la versión en la jerarquía del tópico o en los metadatos del payload.
3. Nunca se cambia el significado manteniendo el nombre. Es la regla más importante y la que más se viola: reaprovechar un campo existente para otra magnitud produce errores silenciosos que ningún validador de tipos detecta.

Los registros de esquemas (schema registry) automatizan la vigilancia de estas reglas en ecosistemas Kafka y similares: rechazan en origen una publicación cuyo esquema rompa la compatibilidad declarada. En entornos MQTT con Sparkplug B, el birth certificate cumple una función parecida al declarar las métricas de cada nodo, aunque la disciplina de convivencia de versiones sigue siendo organizativa. La tecnología vigila la forma; el proceso pactado protege el significado.

Quién es dueño de cada dato

Todo lo anterior se sostiene sobre una pregunta organizativa: ¿quién responde de cada flujo? Un contrato sin dueño es un documento; con dueño, es un compromiso. En el reparto habitual de una fábrica hay tres candidatos y los tres tienen parte de razón. Mantenimiento y automatización conocen el sensor y el PLC. El departamento de IT o de datos opera el broker, la ingesta y el almacén. Producción es quien entiende qué significa el dato y quien sufre sus errores.

El criterio que mejor funciona es el que el enfoque data mesh llama propiedad por dominio: el dueño del dato es quien puede responder por su significado y su corrección en origen, no quien opera las tuberías. Para la temperatura del horno de curado, el dueño natural es el responsable del proceso de pintura, apoyado por automatización para la parte física de la cadena. IT es dueño de la plataforma (broker, historian, disponibilidad de la infraestructura), que tiene su propio contrato de servicio, distinto del contrato del dato.

Separar los dos planos deshace la mayoría de las disputas:

En la práctica, cada contrato lleva el nombre de una persona o un rol, no de un departamento genérico. Y la prueba de que la propiedad es real es simple: cuando una validación de calidad falla, la alerta llega a alguien que puede arreglar la causa, no a un buzón compartido.

Cómo implantar contratos de datos sin parar la planta

El error clásico es intentar contratar toda la planta de golpe: un inventario de miles de tags, una plantilla exhaustiva y un proyecto documental que muere por agotamiento. El camino que funciona es incremental y va por valor, no por exhaustividad.

1. Empezar por los flujos que ya duelen. Los que alimentan decisiones (informes de producción, KPIs, modelos) y han fallado alguna vez son los primeros candidatos. Un contrato por flujo, de una o dos páginas.
2. Escribir el contrato del estado actual, no del ideal. Primero se documenta lo que el flujo hace hoy, con sus defectos; las mejoras (añadir calidad por mensaje, corregir timestamps) se convierten en cambios versionados sobre esa base.
3. Automatizar la verificación cuanto antes. Un contrato que solo vive en un documento se desactualiza en meses. Las garantías de completitud, rango y frecuencia deben ejecutarse como validaciones continuas en la capa de ingesta, con alertas al dueño del dato.
4. Anclar los contratos a la estructura de nombres. Si la planta tiene un unified namespace, cada nodo de la jerarquía es el lugar natural donde colgar su contrato. La estructura de nombres y los contratos se refuerzan mutuamente: una da direcciones estables, los otros dan garantías sobre lo que hay en cada dirección.
5. Tratar el contrato como parte de la entrega de cualquier proyecto. Cada integración nueva (una máquina, un sistema, una migración) entrega su contrato junto al trabajo técnico, igual que entrega planos o documentación eléctrica.

El resultado acumulado es lo que se suele llamar el dato como producto: cada flujo relevante de la planta tiene forma conocida, garantías medidas, historia trazable y un responsable con nombre. Sobre esa base, los dashboards, los informes y los modelos dejan de ser construcciones frágiles sobre arena y pasan a ser consumidores de un producto con condiciones de servicio.

Preguntas frecuentes

Los contratos de datos son la capa de confianza sobre la conectividad: primero el dato llega, después el dato promete. Si estás construyendo esa base en tu planta, desde la integración OT/IT hasta la estructura de nombres y las garantías por flujo, en Captia Connect cubrimos justo ese tramo: del sensor al dato del que te puedes fiar. Los contratos son una pieza más de una plataforma de datos industriales completa, donde encajan junto a la adquisición, el almacenamiento y la explotación del dato.