Equipos legacy SNMP y Modbus hacia MQTT: un límite seguro

Un gateway legacy hacia MQTT debe volver utilizables observaciones existentes sin inventar una nueva ruta de control. Su propósito es leer, validar y mapear, normalizar, asignar calidad y tiempo, y publicar. No prueba que un valor de protocolo sea verdad física, ni autoriza escaneos de descubrimiento, escrituras genéricas o cambios en un equipo de producción.

Empezá por el mapa real del equipo

Armá inventario as-found antes de hacer polling. Registrá device_id, responsable, zona, interfaz, firmware, dirección de red, revisión de OID o mapa de registros, tipo, unidad, escala, offset, orden de bytes y palabras, dueño del polling y propósito operativo. Un plano o planilla puede estar desactualizado; conciliá con registros aprobados y equipo instalado antes de usar una dirección.

El mapa necesita procedencia. Indicá si un valor viene directo de campo, de caché gateway o de cálculo derivado. Un tópico no arregla una fuente desconocida. Si una señal no está documentada, dejala fuera del primer rollout en vez de sondear toda la instalación.

Tratá SNMP como interfaz de gestión

Un OID SNMP tiene significado sólo con su MIB e implementación de dispositivo. Consultá OIDs escalares documentados a una tasa aceptada por el responsable, considerá contadores y conservá revisión de MIB en el mapa. No supongas que dos productos exponen el mismo OID enterprise ni el mismo comportamiento de contador.

Usá SNMPv3 USM en vez de tratar community strings como límite de seguridad. USM ofrece opciones de autenticación e integridad, y privacidad se usa junto con autenticación. Asigná identidades de servicio separadas, limitá vistas a OIDs requeridos, protegé credenciales y documentá algoritmos seleccionados según soporte actual. Una respuesta autenticada dice que respondió esa interfaz, no que el sensor es exacto ni que el proceso está sano.

Tratá Modbus como protocolo de aplicación

Modbus define cuatro tablas: coils, discrete inputs, input registers y holding registers. Lectura y escritura son operaciones diferentes con consecuencias distintas de autorización y proceso. Código de función, convención de dirección basada en cero, cantidad, mapa de proveedor, escala, signo y endianness deben conocerse antes de normalizar.

No existe mapa de registros universal. Una referencia como 40101 puede ser convención de presentación y no offset de cable. No uses escrituras de prueba ni escaneos amplios para resolver ambigüedad. Empezá con puntos aprobados de solo lectura y función documentada. Una respuesta válida en forma puede contener escala implausible, dato viejo o orden de palabras incorrecto.

Normalizá después de validar

Usá el camino exacto read → validate/map → normalize → quality/time → publish. Validá forma de respuesta, función, recuento de bytes, tipo esperado, rango configurado e identidad de fuente antes de convertir. Normalizá unidades y representaciones en una transformación con dueño, no en varios dashboards.

{
  "device_id": "boiler-07",
  "protocol": "modbus-tcp",
  "address": "holding:100",
  "value": 42.3,
  "unit": "Cel",
  "scale": 0.1,
  "quality": "valid",
  "measured_at": "2026-08-17T12:00:00Z",
  "received_at": "2026-08-17T12:00:01Z",
  "sequence": 1842
}

El tópico MQTT y schema identifican contrato gobernado, por ejemplo tópico de telemetría por equipo más schema versionado. Conservá dirección de protocolo en metadatos, no hagas depender jerarquía de tópico de convención de proveedor no documentada.

Publicá calidad y tiempo con honestidad

Como mínimo distinguí valid, stale, timeout, out-of-range, bad mapping, device fault y communication failure. No son equivalentes. Una respuesta de protocolo válida no es verdad física: un transmisor puede fallar, un valor cacheado puede estar viejo y un registro puede mapearse mal aunque los bytes decodifiquen.

Separá measured_at de received_at. Si el equipo legacy no entrega tiempo de fuente, declaralo y usá hora de recepción gateway sólo como recepción. Consumidores deben aplicar su regla de frescura; una entrega MQTT exitosa no vuelve actual una medición vieja.

Acotá polling y recuperación

Fijá límites por equipo de tasa, timeout de solicitud, concurrencia y backoff de reconexión. Protegé convertidores serie frágiles y agentes de gestión viejos de tormentas de polling. Un timeout debe producir calidad timeout o communication failure, no repetir un valor bueno viejo como si fuera actual.

Reintentá sólo lecturas idempotentes y acotadas. Reconectar no justifica reproducir comandos porque este gateway no posee comandos. Conservá mapeos rechazados y fallas de parseo en diagnóstico acotado con motivo y conteo, no en copia ilimitada de payloads o secretos.

Segmentá el bridge

Ubicá colector en zona OT aprobada o borde DMZ, no como atajo dual-homed irrestricto. Usá allowlists de destinos y puertos, identidades de mínimo privilegio, ACL de tópicos broker, TLS cuando soporte y rotación gestionada de credenciales. Guía NIST trata estas decisiones como arquitectura OT, no ajuste tardío de aplicación.

Separá acceso de gestión, publicación de telemetría y trabajo de ingeniería. Un consumidor cloud no debe ganar ruta a escrituras Modbus o administración SNMP porque recibe datos normalizados.

Hacé rollout en solo lectura y guardá rollback

Empezá con una fuente documentada de solo lectura durante ventana aprobada. Verificá identidad de tópico, schema, conversión, transiciones de calidad, timestamps, límites de tasa y salud. Probá timeout, bad mapping, valor stale, device fault y reconexión en entorno aislado o autorizado.

Tomá línea de base de configuración gateway, revisión de mapa, ACL, ubicación de credenciales y ruta de datos anterior antes del rollout. Rollback significa detener colección, restaurar configuración aprobada previa y confirmar que no se introdujo escritura ni escaneo amplio. No significa borrar evidencia necesaria para diagnosticar el cambio.