¿Qué es un property set de Sparkplug y un property value?
Sparkplug permite que una métrica lleve más que un número: un property set adjunta descriptores con nombre y tipo que viajan con la métrica. Para el ingeniero que quiere que las unidades de ingeniería o un rango viajen con una lectura en lugar de vivir en una configuración aparte, el property set es el mecanismo. Esta página explica qué son un property set y un property value, cómo se adjuntan a una métrica y dónde ayudan sin inflar el payload.
Property set de Sparkplug en una línea: Un property set de Sparkplug es una colección de property values con nombre adjunta a una métrica, donde cada property value es una pieza de metadato tipada como una unidad de ingeniería, un límite de rango o un indicador de calidad. Permite que los atributos descriptivos viajen con la métrica en el payload, de modo que un consumidor recibe el contexto que hace significativo un valor crudo sin consultar una configuración externa.
Cómo se adjunta un property set a una métrica
Un property set es una colección estructurada de pares clave-valor ligada a una métrica, donde cada clave es un nombre y cada valor es un property value tipado. Los property values son a su vez tipados, así que un límite de rango numérico se lleva como número y una etiqueta de unidad como cadena, lo que mantiene el metadato tan libre de ambigüedad como el propio valor de la métrica. Este es el mecanismo que completa la naturaleza autodescriptiva de las métricas Sparkplug, extendiendo el tipo de dato y los metadatos básicos que una métrica ya lleva.
Lo natural para poner en un property set son los descriptores que hacen interpretable una lectura y que de otro modo guardaría en una base de datos de tags aparte. Las unidades de ingeniería son el ejemplo canónico: un valor de 42 dice poco hasta que sabe si son grados Celsius o bar. Los límites de rango o de escala permiten a un consumidor dibujar una barra o validar un valor. Un descriptor de calidad o de estado puede viajar junto al valor. Llevar esto como propiedades significa que el consumidor los recibe en el mismo mensaje que el valor, no desde una configuración que hay que mantener sincronizada.
Como las propiedades se declaran con la métrica, típicamente en el birth, un consumidor que construye un modelo de tags puede poblar unidades, rangos y descripciones automáticamente a partir de lo que recibe. Este es el mismo colapso de coordinación que hace atractivo a Sparkplug en general: en lugar de capturar a mano las unidades de cada tag del lado SCADA para que coincidan con el dispositivo, las unidades llegan con la métrica. Complementa la estructura reutilizable de un template, donde cada métrica miembro puede llevar su propio property set.
Usar property sets sin inflar el payload
La tensión práctica con los property sets es la misma que con cualquier metadato: agregan bytes, y esos bytes se reenvían cada vez que la métrica se redeclara en un birth o rebirth. En un enlace celular medido esto no es gratis, así que la meta es un conjunto de propiedades con propósito y no uno exhaustivo. Las unidades y un rango casi siempre valen la pena; una descripción larga de texto libre repetida para miles de métricas en cada rebirth quizá no. Elegir qué se gana su lugar es parte del buen diseño de payload.
El alivio es que las propiedades, como la descripción completa de la métrica, viven en el birth y no en cada mensaje de datos. Los mensajes de datos de régimen llevan los valores por alias y no repiten el property set, así que la telemetría continua se mantiene esbelta sin importar cuánto metadato descriptivo lleve una métrica. El costo de un property set rico se paga en el birth y el rebirth, que son infrecuentes comparados con el flujo de datos, así que un conjunto pensado de propiedades suele ser costeable.
El valor más profundo es arquitectónico. Cuando las unidades, los rangos y los descriptores de calidad viajan con los datos, desaparece toda una clase de errores de integración, esos donde el dispositivo cree que un valor está en una unidad y el SCADA lo presenta en otra porque dos configuraciones separadas se desalinearon. Por eso los property sets encajan tan bien en un enfoque de espacio de nombres unificado, donde se pretende que los datos sean autosuficientes y consumibles por muchas aplicaciones sin que cada una necesite una copia privada del diccionario de tags.
Preguntas frecuentes
¿Qué tipo de información va en un property set de Sparkplug?
Atributos descriptivos de la métrica que hacen interpretable su valor: unidades de ingeniería, límites de rango o de escala, y descriptores de calidad o de estado son los comunes. Cada uno es un property value tipado, así que una unidad se lleva como cadena y un límite numérico como número. La idea es adjuntar directamente a la métrica el contexto que de otro modo guardaría en una base de datos de tags aparte, de modo que un consumidor reciba unidades y rangos en el mismo mensaje que el valor y no desde una configuración que debe mantener sincronizada.
¿Los property sets hacen más lenta la telemetría de rutina?
No, porque se llevan en el birth y el rebirth, no en cada mensaje de datos. El property set de una métrica se declara cuando la métrica se introduce, y los mensajes de datos continuos referencian la métrica por alias y llevan solo su valor cambiante, así que el flujo constante de telemetría se mantiene esbelto sin importar qué tan rico sea el property set. El costo de los descriptores se paga en el birth y en el rebirth ocasional, que son infrecuentes comparados con el flujo de mensajes de datos que domina el uso del enlace.
Fuentes y lecturas
Referencias primarias de los organismos de normas y reguladores que definen este tema:
- Sparkplug Specification - Eclipse Foundation
Servicios de automatización
¿Necesita convertir esta información en un sistema que funcione?
Merobix integra SCADA, programa PLC Allen-Bradley y Siemens, y diseña y fabrica tableros de control industrial.
Las solicitudes de reunión se revisan antes de confirmarse.