El diseño MQTT debe definir la identidad del dispositivo, la jerarquía de temas, las marcas de tiempo, la calidad, la calidad de calidad y la reproducción offline. Un QoS más alto no es automáticamente más fiable porque el almacenamiento, las sesiones y la deduplicación de plataformas también importan.
Puntos clave
- Los temas deben ser estables y escalables
- La telemetría y los comandos deben estar separados
- Los datos offline deberían conservar el tiempo de adquisición original
Principio Técnico y Valor del Proyecto
El diseño MQTT debe definir la identidad del dispositivo, la jerarquía de temas, las marcas de tiempo, la calidad, la calidad de calidad y la reproducción offline. Un QoS más alto no es automáticamente más fiable porque el almacenamiento, las sesiones y la deduplicación de plataformas también importan. En un proyecto real, los temas deben ser estables y escalables, y la telemetría y los comandos deben estar separados deben considerarse en la misma arquitectura. Empieza por la carga de trabajo, los dispositivos de campo y el modelo operativo en lugar de una sola especificación de marketing.
Parámetros a confirmar durante la implementación
Una secuencia práctica consiste en confirmar el broker y la autenticación y la convención de tema, luego verificar la elección de la QoS y el tamaño/frecuencia del mensaje, y finalmente probar los datos offline que deberían conservar el tiempo de adquisición original con el equipo real. Registra los criterios de aprobación para que el diseño pueda repetirse entre los sitios.
Por qué es necesario el testing con carga de trabajo real
Las colas y reintentos ilimitados pueden crear una ráfaga de recuperación que retrasa los mensajes en tiempo real. Por tanto, el contenido público y los documentos de proyectos deben indicar el modelo, el firmware, la red regional, las opciones y las condiciones ambientales, y evitar afirmaciones no verificables como 'funciona para cada proyecto' o 'fiabilidad absoluta'.
Cómo encaja Tespro
Tespro TG-424 puede organizar datos de borde y publicar a través de protocolos de red relacionados con MQTT. Confirma TLS, QoS, sesiones persistentes y almacenamiento en búfer por versión del software.
Tabla de Decisión y Verificación
| Factor de decisión | Qué verificar |
| Los temas deben ser estables y escalables | Confirma contra el intermediario y la autenticación y documenta los criterios de aprobado/suspenso en la prueba piloto o en el sitio. |
| La telemetría y los comandos deben estar separados | Confirma contra la convención de temas y documenta los criterios de aprobado/suspenso en el examen piloto o en el sitio. |
| Los datos offline deberían conservar el tiempo de adquisición original | Confirma contra la elección de QoS y documenta los criterios de aprobado/suspenso en el piloto o en la prueba presencial. |
Lista de verificación de compatibilidad y selección
- ✓ Corredor y autenticación
- ✓ Convención temática
- ✓ Elección de QoS
- ✓ Tamaño/frecuencia del mensaje
- ✓ Ventana desconectada
- ✓ Seguridad de mando
Preguntas frecuentes
P: ¿Deberían todos los datos industriales usar QoS 2?
R: No. QoS 2 tiene una mayor sobrecarga y debería adaptarse a las necesidades de deduplicación y fiabilidad.
P: ¿Puede la reproducción offline crear datos duplicados?
R: Sí. La plataforma debe deduplicar usando el ID del dispositivo, la marca de tiempo y la secuencia.
P: ¿Pueden los comandos MQTT controlar directamente el equipo?
R: Necesitan autenticación, autorización, validación y lógica de seguridad local antes de cualquier acción peligrosa.
