¿Cómo funciona un remapeo de unit ID en un gateway Modbus?

Cómo el gateway usa el identificador de unidad para enrutar

En una línea multipunto RS-485, cada dispositivo tiene una dirección de esclavo - un número que lo distingue de los otros dispositivos que comparten los mismos cables - y un maestro serial direcciona un dispositivo específico poniendo su dirección de esclavo en la petición. Modbus TCP conserva un campo para el mismo propósito llamado identificador de unidad. En un dispositivo TCP puro el unit ID muchas veces se ignora o se pone en un valor de relleno, porque la dirección IP ya identifica al dispositivo. Pero detrás de un gateway, la IP identifica al gateway, no a los dispositivos seriales individuales tras él, así que el unit ID recupera su significado original: le dice al gateway a cuál esclavo serial se destina la petición.

El flujo de enrutamiento es sencillo una vez que usted ve el unit ID como el selector. El sondeador abre una conexión TCP a la IP del gateway y envía una petición Modbus TCP con el unit ID puesto, digamos, en 3. El gateway lee ese unit ID, convierte la petición en una trama Modbus serial direccionada al esclavo 3, la transmite en la línea RS-485, espera la respuesta del esclavo 3, envuelve esa respuesta de vuelta en una respuesta Modbus TCP, y la devuelve por la misma conexión. Desde la perspectiva del sondeador parece que le habla a muchos dispositivos en una IP, distinguidos solo por el unit ID; desde la perspectiva de los dispositivos seriales, un maestro serial normal los sondea por dirección de esclavo. El gateway es el traductor que se ubica entre los dos mundos, y el unit ID es la pieza de información que sobrevive a la traducción para mantener cada petición apuntada al dispositivo correcto.

El problema de colisión: dos dispositivos, el mismo ID de esclavo

El caso limpio uno a uno supone que cada dispositivo serial detrás del gateway tiene una dirección de esclavo distinta. La realidad muchas veces viola esto. Los dispositivos con frecuencia salen de fábrica con la misma dirección de esclavo por defecto, y en una planta ensamblada a lo largo de años usted puede terminar fácilmente con dos computadores de flujo o dos medidores que ambos responden a la dirección de esclavo 1. En líneas seriales separadas esto está bien, pero si usted intenta poner ambos detrás de un gateway en una línea RS-485, tiene una colisión: una petición para el esclavo 1 sería respondida por ambos dispositivos a la vez, corrompiendo la respuesta, y no hay ningún valor de unit ID que pueda distinguirlos porque comparten la misma dirección subyacente.

Hay dos formas estándar de salir. La más limpia es renumerar uno de los dispositivos para que los dos tengan direcciones de esclavo únicas en la línea compartida - entonces el gateway mapea el unit ID 1 a uno y el unit ID 2 al otro, y la colisión desaparece. Cuando renumerar no es posible, los dispositivos se colocan en puertos seriales separados o gateways separados, de modo que cada dispositivo en colisión viva en su propia línea donde su dirección es inequívoca, y el gateway los distingue por a qué puerto se mapea la petición en lugar de por el ID de esclavo compartido. Por eso existen los gateways con múltiples puertos seriales y por eso la documentación advierte contra poner dispositivos con la misma dirección en un bus: el unit ID solo puede enrutar a una dirección única, así que la unicidad tiene que establecerse en algún lado, sea renumerando el dispositivo o dándole a cada uno su propio puerto.

Configurar el enrutamiento de unit ID para un sondeador en la nube

Configurar el enrutamiento significa construir el mapa dentro del gateway y hacerlo coincidir en el sondeador. En el gateway usted define qué unit ID corresponde a qué esclavo serial en qué puerto - una tabla que dice que el unit ID 3 va al esclavo 3 en el puerto 1, el unit ID 7 va al esclavo 5 en el puerto 2, y así. En un gateway simple de un solo puerto esto suele ser un paso directo donde el unit ID es igual a la dirección de esclavo serial, pero los gateways de múltiples puertos y las situaciones con direcciones duplicadas requieren un remapeo explícito para que un unit ID que el sondeador usa aterrice en el dispositivo físico deseado aunque su dirección de esclavo nativa sea distinta. Acertar con esta tabla es el trabajo entero: una entrada equivocada envía su sondeo al dispositivo equivocado y devuelve datos plausibles pero incorrectos.

Para una plataforma SCADA en la nube como Merobix que sondea sitios remotos, la imagen práctica es que cada gateway de campo presenta una IP, o un nombre de host, detrás del cual se ubican varias RTU o medidores seriales, y la plataforma se configura con el unit ID correcto para cada dispositivo de modo que sus peticiones se enruten al hardware correcto. Esto permite alcanzar todo un grupo de dispositivos seriales en un sitio remoto a través de un solo extremo de red, lo que es eficiente sobre los enlaces celulares y compartidos típicos de la conectividad de campo. La disciplina de configuración esencial es la consistencia entre los dos extremos: el unit ID que el sondeador envía para un dispositivo debe coincidir con la entrada en el remapeo del gateway que apunta a la dirección de esclavo y puerto de ese dispositivo. Cuando los dos concuerdan, una IP se abre en abanico limpiamente a muchos dispositivos de campo; cuando difieren, las peticiones alcanzan en silencio la RTU equivocada, que es exactamente la clase de falla que el remapeo busca evitar cuando se configura correctamente.

Preguntas frecuentes