¿Qué es un esquema de carga JSON para telemetría SCADA?

Valor, calidad y marca de tiempo en el centro

Cada lectura SCADA es en realidad tres cosas empaquetadas juntas, y un buen sobre JSON las vuelve explícitas a las tres. El valor es la medición en sí: un nivel, una presión, un estado de marcha. La marca de tiempo dice cuándo ese valor era cierto en la fuente, que no es lo mismo que cuándo se envió o recibió el mensaje, y debe ser un formato inequívoco y consciente de la zona horaria, como una cadena UTC en ISO 8601, para que ningún consumidor tenga que adivinar el desfase. La bandera de calidad registra si la fuente consideró confiable la lectura - buena, mala o incierta - porque un valor con calidad mala es peor que inútil si un consumidor lo trata como real.

Este trío de valor, calidad y marca de tiempo es el equivalente industrial de un hecho completo. Un tablero que grafica valores pero ignora la calidad felizmente dibujará una línea plana a través de un sensor que en realidad estaba desconectado, y una alerta que confía en una marca de tiempo obsoleta puede dispararse sobre datos de horas de antigüedad. Llevar los tres en el sobre deja que cada consumidor decida correctamente: sostener el último valor bueno, atenuar uno malo, o suprimir una alerta sobre datos inciertos. Dejar fuera cualquiera de los tres obliga a los consumidores a inventar suposiciones, y consumidores distintos inventan distintas.

Junto a estos, el mensaje necesita un identificador de tag estable para que la lectura pueda atarse al punto correcto en el activo correcto. Este debe ser una clave duradera que no cambie cuando se edita un nombre para mostrar, idealmente una ruta o código que codifique sitio y activo. Las marcas de tiempo deben enviarse con precisión consistente, y los valores deben conservar su tipo natural, un número como número y un booleano como booleano, en lugar de aplanarse a cadenas, para que los consumidores no tengan que analizar y re-tipar cada campo.

Disposición plana o anidada

La misma información puede acomodarse como un objeto plano con todos los campos en el nivel superior, o como una estructura anidada que agrupa campos relacionados bajo subobjetos. Una disposición plana, donde tag, valor, calidad, marca de tiempo y unidades se ubican todos lado a lado como claves de nivel superior, es la más amigable para cargarse directo a un almacén de datos o un almacén columnar, porque cada clave mapea limpiamente a una columna sin desempacar. Los mensajes planos también son los más fáciles para una lectura rápida a ojo y para procesadores de flujo simples que no quieren recorrer un árbol.

Las disposiciones anidadas se ganan su lugar cuando un mensaje lleva más de una lectura o un contexto más rico. Poner un arreglo de objetos de métrica bajo un encabezado compartido, para que un mensaje reporte varios tags del mismo dispositivo en el mismo instante con el sitio y el dispositivo identificados una vez, recorta la repetición y mantiene juntas las lecturas relacionadas. El anidamiento también separa limpiamente los metadatos del sobre - versión de esquema, fuente y marca de tiempo - de la carga de lecturas, lo que puede simplificar el enrutamiento y la validación. El costo es que los consumidores deben desempacar la estructura, y la carga al almacén de datos necesita un paso de aplanado.

Un camino intermedio común es una forma ligera de dos niveles: un encabezado pequeño que identifica la fuente y la versión de esquema, y un arreglo plano de lecturas que cada una lleva su propio valor, calidad, marca de tiempo y unidades. Esto mantiene los campos por lectura lo bastante planos para aplanarse con facilidad mientras evita repetir la fuente en cada fila. Como sea que se incline, lo importante es elegir una forma y sostenerla, porque los consumidores escriben analizadores contra la estructura que ven primero, y cambiar en silencio entre disposiciones plana y anidada es justo el tipo de cambio que los rompe.

Versionado y metadatos de unidades

Los esquemas cambian, y la manera de cambiarlos sin romper a todos aguas abajo es versionar el sobre de forma explícita. Un campo de versión en cada mensaje, o al menos en el encabezado, les dice a los consumidores cuál forma esperar y deja que un analizador maneje formatos viejos y nuevos lado a lado durante una transición. Los cambios más seguros son aditivos: agregar un campo opcional nuevo no perturba a un consumidor que lo ignora, así que subir la versión y agregar campos, en lugar de renombrar o reutilizar los existentes, mantiene funcionando a los lectores viejos. Renombrar o re-tipar un campo es un cambio rompedor y necesita un paso de versión coordinado.

Las unidades son los metadatos que la gente más a menudo olvida y más lamenta haber olvidado. Un valor de 42 no significa nada hasta que se sabe si son pies, metros, PSI o un porcentaje, y enterrar la unidad en un nombre de tag o en una búsqueda separada que no todo consumidor tiene es una receta para un incidente por desajuste de unidades. Llevar la unidad en el mensaje, junto al valor, vuelve autodescriptiva cada lectura, para que un consumidor pueda convertir, etiquetar un eje o rechazar una unidad inesperada sin contexto externo. La misma lógica aplica a otros metadatos descriptivos como una pista de tipo de dato o un rango de ingeniería.

Para una plataforma de SCADA en la nube como Merobix que ingiere telemetría de muchos dispositivos y pasarelas de campo distintos, un sobre JSON bien diseñado y versionado es lo que mantiene manejable esa variedad. Cuando cada lectura llega autodescriptiva, con valor, calidad, marca de tiempo, unidades y una versión de esquema, la plataforma puede validarla, enrutarla y almacenarla de forma consistente, agregar nuevos tipos de campo sin una migración de día fijo, y cargarla a la analítica sin un analizador a medida por fuente. La pequeña disciplina de diseñar el sobre por adelantado rinde a medida que la flota de fuentes crece y evoluciona.

Preguntas frecuentes