¿Qué son los comandos DCMD y NCMD de Sparkplug?

Volver al glosario

La dirección de comando que las introducciones a Sparkplug suelen omitir

Los mensajes de datos de Sparkplug fluyen del campo hacia el host: un nodo de borde publica su certificado de nacimiento y luego un flujo de datos de nodo y datos de dispositivo a medida que los valores cambian. Ese flujo hacia arriba es lo que la mayoría de los tutoriales cubren, porque el monitoreo es el primer caso de uso común. Pero un sistema SCADA no es solo para observar - los operadores necesitan actuar, cambiar un setpoint, abrir o cerrar una válvula, arrancar o parar una bomba. Esas acciones requieren mensajes que viajen en el sentido opuesto, del host hacia el campo, y Sparkplug define tipos de mensaje específicos para exactamente eso.

Los dos tipos de comando son NCMD y DCMD, que reflejan los dos tipos de datos NDATA y DDATA. Donde NDATA y DDATA llevan valores hacia arriba desde un nodo y un dispositivo respectivamente, NCMD y DCMD llevan comandos hacia abajo a un nodo y a un dispositivo respectivamente. El nombramiento es deliberadamente paralelo: los tipos N conciernen al nodo de borde mismo, los tipos D conciernen a un dispositivo detrás de él, e intercambiar DATA por CMD intercambia la dirección de reportar a comandar. Esta simetría es lo que hace de Sparkplug un protocolo bidireccional completo en lugar de un canal de telemetría de un solo sentido.

Entender esta dirección de comando importa porque es donde vive la escritura de vuelta, y la escritura de vuelta es lo que separa un sistema de monitoreo de un sistema de control. Una plataforma que solo puede recibir puede mostrar a un operador que un tanque se está llenando pero no puede dejarlo regular el ingreso. NCMD y DCMD son los mensajes que cierran ese lazo, dando al host una forma definida y estructurada de empujar la intención hacia abajo al equipo. Que estén poco explicados en la mayoría de las introducciones no los hace opcionales - cualquier aplicación de control real sobre Sparkplug depende de ellos.

Direccionar el nodo frente al dispositivo detrás de él

La distinción entre NCMD y DCMD sigue la jerarquía de direccionamiento de Sparkplug. Un nodo de borde es el gateway o componente de software que se conecta al broker y habla Sparkplug a nombre de sí mismo y de cualquier dispositivo conectado detrás de él. Un dispositivo es una pieza de equipo - muchas veces un PLC o instrumento - que se ubica detrás del nodo de borde y no se conecta al broker por sí mismo; el nodo lo representa. Los comandos se direccionan a uno o al otro según lo que usted intente alcanzar.

Un NCMD apunta al nodo de borde mismo. Se usa para escribir métricas que pertenecen al nodo - configuración de nivel de nodo o métricas de control - la más notable siendo la métrica de control de renacimiento que un host escribe para hacer que un nodo reemita su certificado de nacimiento. Un NCMD se direcciona al nodo usando sus identificadores de grupo y de nodo, y el nodo es la entidad que lo recibe y actúa sobre él. Cuando la cosa que usted quiere cambiar vive a nivel de nodo, NCMD es el mensaje.

Un DCMD apunta a un dispositivo específico detrás del nodo. Lleva el identificador de dispositivo adicional para que el mensaje se apunte no solo al nodo sino al dispositivo particular al que el nodo da frente, y es como un host escribe un valor de campo real - una velocidad de bomba, un setpoint de temperatura, un estado de salida - a un PLC o instrumento dado. El nodo de borde recibe el DCMD, ve a cuál dispositivo y cuál métrica direcciona, y traduce la escritura a lo que sea que el protocolo nativo del dispositivo requiera. Este es el salto crucial donde un comando Sparkplug se vuelve una acción concreta en equipo real, con el nodo de borde actuando como el puente entre MQTT y el bus de campo.

El flujo de escritura de vuelta del operador al PLC en el SCADA en la nube

Seguir un solo comando de extremo a extremo muestra cómo encajan las piezas. Un operador en un tablero cambia un setpoint - digamos, subir la presión objetivo de un compresor. El host construye un DCMD direccionado al grupo, nodo de borde y dispositivo correctos, llevando la métrica a escribir y su nuevo valor, y lo publica. El broker lo entrega al nodo de borde que posee ese dispositivo. El nodo reconoce el dispositivo y la métrica objetivo, convierte la escritura Sparkplug al protocolo nativo del dispositivo, y escribe el nuevo valor al PLC. El setpoint ahora está vivo en el campo.

El lazo luego se confirma a sí mismo a través de la dirección de datos. Una vez que el valor del PLC en realidad cambia, el dispositivo reporta el nuevo valor de vuelta hacia arriba en un mensaje DDATA, y el host ve el valor reportado coincidir con lo que comandó. Esto cierra la escritura con confirmación real en lugar de esperanza ciega: el operador no solo dispara un comando a la oscuridad sino que ve al campo confirmar que el cambio surtió efecto. Ese reporte de vuelta es por qué las direcciones de comando y de datos funcionan como un par - una lleva la intención hacia abajo, la otra lleva la confirmación hacia arriba.

Para el SCADA en la nube sobre MQTT, esta ruta de escritura de vuelta es lo que convierte un tablero en la nube en control remoto genuino. Cuando una plataforma como Merobix actúa como el host Sparkplug, un operador puede cambiar un setpoint en un pad de pozo remoto desde un navegador, y la plataforma emite el DCMD que viaja a través del broker al nodo de borde del sitio y hacia abajo al PLC, con el valor resultante reportado de vuelta para que el operador vea el cambio confirmado. Como la ruta de comando está definida y estructurada, y como las escrituras se direccionan con precisión a un dispositivo y una métrica, este control remoto se puede gobernar con cuidado - cuáles comandos se permiten, quién los puede emitir - mientras aún da a las operaciones de campo alcance bidireccional real desde donde sea.

Preguntas frecuentes