Un nuevo capítulo en el IoT industrial: Aplicaciones integradas de sensores, PLCs y gateways/routers Modbus
Actualizado: 12 oct
Un sensor, un PLC y una pasarela Modbus pueden aparecer en el mismo diagrama de red sin compartir interfaz ni función. Un sensor puede conectarse a una entrada del PLC, el PLC puede exponer determinados valores por Modbus y una pasarela puede enlazar una red serie con una conexión IP. Hay que confirmar cada paso para los equipos concretos del proyecto.
Empiece por seguir un solo punto de datos desde su origen hasta el sistema que lo leerá. Así podrá distinguir el cableado, la lógica de control, la conversión de protocolos y el acceso remoto.
El papel de los sensores en el IoT industrial: La base de la recolección de datos
Los sensores convierten condiciones físicas en señales eléctricas o valores digitales. La temperatura, presión, humedad, vibración y caudal pueden orientar decisiones de mantenimiento y proceso, siempre que la medición sea adecuada. Una tendencia de vibración puede ayudar a investigar un rodamiento; por sí sola no diagnostica una avería ni evita una parada. Registre rango, precisión, condiciones de montaje y actualización necesaria.
Dibuje la ruta en orden:
Sensor → entrada o interfaz de comunicación → lógica/punto de datos del PLC → cliente o servidor Modbus → pasarela o ruta de red → aplicación SCADA o de supervisión
La ruta puede cambiar según el equipo. Algunos sensores entregan señales analógicas o discretas a una entrada del PLC; otros transmiten datos digitalmente. Consulte los manuales del sensor y del PLC para verificar la interfaz, el cableado, el escalado y el comportamiento de actualización. Un sensor no tiene necesariamente una dirección Modbus porque el PLC utilice Modbus en otra parte del sistema.
Tipo de sensor | Función de medida | Interfaz que verificar | Comprobación de aplicación |
|---|---|---|---|
Proximidad | Detección de objetos o posición | Salida discreta, nivel eléctrico y compatibilidad de entrada | Confirmar cambios de estado en el PLC con el objetivo y montaje previstos |
Temperatura | Temperatura de proceso o equipo | RTD, termopar, transmisor o interfaz digital especificada | Verificar rango, escala, unidad y medida de referencia |
Presión | Presión de líquido o gas | Transmisor analógico o protocolo digital documentado | Verificar rango, alimentación, conexión de proceso y presión conocida |
PLCs: El cerebro central de la automatización industrial
Definición y funciones de los PLCs
El PLC ejecuta el programa de control local y conecta módulos de entrada/salida con la maquinaria. Un programa típico lee entradas, evalúa la lógica y actualiza salidas; las tareas, el ciclo y la respuesta dependen del controlador, el programa y las E/S. El lenguaje de contactos es una opción de programación. Las protecciones y las funciones críticas en tiempo deben permanecer en el sistema diseñado para ellas; la supervisión remota no asume automáticamente esa responsabilidad.
El proyecto del PLC define qué medidas, estados y órdenes se comparten. Una entrada de temperatura puede escalarse a unidades físicas para regular una válvula localmente, mientras un valor mapeado por separado se expone para supervisión. Según los módulos, el firmware y la aplicación, el PLC puede ser cliente Modbus, servidor, ambos o ninguno. Confírmelo antes de elegir una pasarela.
Después, identifique dónde se guarda el valor y cómo puede consultarlo otro sistema. El PLC puede exponer un punto configurado mediante un servidor Modbus o actuar como cliente que lee otro dispositivo. Confirme el rol y el mapa de datos en el proyecto y el manual del PLC. El mapa de registros es una configuración deliberada, no un reflejo automático de todas las entradas de sensores.
Fabricantes de PLC: comprobaciones por modelo
La lista histórica de fabricantes sirve como lista de comprobación de compra, sin clasificación. Identifique CPU, módulos de comunicación, firmware y versión del software de ingeniería. Compruebe si la variante Modbus y el rol cliente/servidor son nativos, requieren una biblioteca o módulo, o necesitan una pasarela externa. Los servicios en la nube, OPC UA y MQTT son capacidades distintas. El nombre del fabricante no demuestra su disponibilidad ni el coste total del proyecto.
Fabricante | Identificación del proyecto | Evidencia de protocolo e integración | Entrada oficial |
|---|---|---|---|
Siemens | Ejemplos históricos; verificar la configuración actual: SIMATIC S7-1200/1500. Registrar CPU, módulos y firmware; no suponer comportamiento idéntico en toda una serie. | Comprobar variante Modbus, rol cliente/servidor, biblioteca o módulo requerido y mapa de datos. | |
Schneider Electric | Ejemplos históricos; verificar la configuración actual: Modicon M221/M340. Registrar CPU, módulos y firmware; no suponer comportamiento idéntico en toda una serie. | Comprobar variante Modbus, rol cliente/servidor, biblioteca o módulo requerido y mapa de datos. | |
Allen-Bradley (Rockwell Automation) | Ejemplos históricos; verificar la configuración actual: CompactLogix. Registrar CPU, módulos y firmware; no suponer comportamiento idéntico en toda una serie. | Comprobar variante Modbus, rol cliente/servidor, biblioteca o módulo requerido y mapa de datos. | |
Mitsubishi Electric | Ejemplos históricos; verificar la configuración actual: MELSEC iQ-R. Registrar CPU, módulos y firmware; no suponer comportamiento idéntico en toda una serie. | Comprobar variante Modbus, rol cliente/servidor, biblioteca o módulo requerido y mapa de datos. | |
Inovance | Ejemplos históricos; verificar la configuración actual: H3U/H5U. Registrar CPU, módulos y firmware; no suponer comportamiento idéntico en toda una serie. | Comprobar variante Modbus, rol cliente/servidor, biblioteca o módulo requerido y mapa de datos. | |
XINJE | Ejemplos históricos; verificar la configuración actual: XC/XD/XL. Registrar CPU, módulos y firmware; no suponer comportamiento idéntico en toda una serie. | Comprobar variante Modbus, rol cliente/servidor, biblioteca o módulo requerido y mapa de datos. | |
Delta | Ejemplos históricos; verificar la configuración actual: DVP-12SE/DVP28SV. Registrar CPU, módulos y firmware; no suponer comportamiento idéntico en toda una serie. | Comprobar variante Modbus, rol cliente/servidor, biblioteca o módulo requerido y mapa de datos. |
Protocolo Modbus: El puente de la comunicación industrial
Modbus ofrece un modelo de datos de aplicación con bobinas, entradas discretas, registros de entrada y registros de retención. Los códigos de función admitidos determinan qué puede leer o escribir un cliente. Sus variantes serie y TCP pueden conectar equipos antiguos a sistemas de supervisión, pero un nombre de protocolo común no garantiza la misma interpretación de registros, permisos o representación de datos.
Modbus RTU y ASCII usan tramas serie. Modbus TCP transporta datos de aplicación Modbus sobre TCP/IP con una cabecera MBAP. Las variantes comparten parte del modelo de datos de aplicación, pero difieren en sus mensajes y ajustes de conexión. RS-485 es una capa física habitual para Modbus serie; por sí sola no define el formato del mensaje.
Tramo de la conexión | Qué registrar antes de configurar |
|---|---|
Del sensor al PLC | Interfaz eléctrica o digital, cableado, escalado y dispositivo que proporciona el valor |
Del PLC al cliente Modbus | Rol del PLC, variante RTU/ASCII/TCP, extremo de comunicación, ajustes serie o IP/puerto y códigos de función admitidos |
De la pasarela a la aplicación superior | Modo de la pasarela, variantes de origen y destino, roles cliente/servidor, identificadores de dispositivos y mapa de registros |
La indicación «compatible con Modbus» no resuelve esos detalles. Un dispositivo puede admitir solo algunos códigos de función o una variante. Consulte la especificación del protocolo de aplicación Modbus, la guía del protocolo sobre línea serie y la guía de implementación TCP/IP para conocer el formato de los mensajes. Use el manual de cada equipo para determinar qué funciones implementa realmente.
En una instalación serie deben ser compatibles las interfaces eléctricas, el cableado, la terminación y los parámetros. En TCP, documente dirección del servidor, puerto configurado y política de conexión. Los tiempos de la línea serie, el tiempo de respuesta, el tamaño de la petición, el procesamiento y el programa de consultas determinan la actualización real. La velocidad del enlace Ethernet no es el rendimiento de las transacciones Modbus; el alcance depende del diseño físico concreto.
Aspecto | Modbus serie RTU/ASCII | Modbus TCP | Qué verificar |
|---|---|---|---|
Ruta física | Interfaz serie compatible y diseño del bus | Red TCP/IP diseñada para el proyecto | Cableado, aislamiento, extremo y accesibilidad |
Trama | RTU y ASCII utilizan tramas serie diferentes | Datos de aplicación Modbus con cabecera MBAP | Variante admitida y dirección de conversión |
Roles | Un cliente consulta dispositivos direccionados | Un cliente abre conexión con un servidor | Rol, concurrencia y tratamiento del identificador de unidad |
Datos y direcciones | Códigos de función y mapa acordado | Códigos de función y mapa acordado | Convención de dirección, tipo, orden de bytes, escala y permisos |
Tiempo y capacidad | Baudios, respuesta y uso compartido del bus afectan a la actualización | Procesamiento, peticiones y conexiones afectan a la actualización | Respuesta y carga medidas; sin promesa genérica de distancia o velocidad |
Protección | El acceso serie necesita controles físicos y operativos | Un servicio accesible necesita controles de red aprobados | Segmentación, extremos autorizados, permiso de escritura y recuperación |
Una ruta de red operativa no demuestra que una medida tenga dirección, unidad o significado correctos.
Gateway Modbus vs. Router Modbus: Diferencias y funciones
Definiciones de gateway y router Modbus
Una pasarela de protocolo termina e interpreta una variante y genera mensajes de otra variante admitida. Un servidor serie puede transportar simplemente un flujo de bytes sin modificar; un router IP reenvía paquetes entre redes. Un producto puede combinar funciones, pero la traducción de direcciones IP, el tratamiento del identificador de unidad Modbus y el remapeo de registros de aplicación siguen siendo operaciones diferentes.
Un router IP reenvía tráfico IP entre redes; la RFC 1812 describe los requisitos de los routers IPv4. Un servidor serie puede transportar bytes serie por una conexión IP manteniendo intacto el mensaje Modbus serie. Una pasarela Modbus puede terminar una variante y generar solicitudes en otra, pero debe admitir expresamente el modo y el mapeo necesarios.
Los nombres «pasarela» y «router» no bastan para establecer el comportamiento.
Revise en el manual del producto el sentido exacto de la conversión, los roles cliente/servidor admitidos y el tratamiento de los identificadores de dispositivos. Confirme si los datos pasan directamente o si la pasarela los consulta y los vuelve a mapear. Si faltan esos detalles, el comportamiento sigue sin verificar: consulte al proveedor antes de basar el diseño en esa función.
Comparación de funciones
Utilice la comparación de roles para asignar cada función de forma deliberada. Si ambos extremos ya admiten la misma variante y pueden comunicarse por la red autorizada, no hace falta una conversión adicional. A la inversa, añadir una ruta IP no convierte una trama serie en una petición Modbus TCP.
Rol del dispositivo | Qué hace | Qué no demuestra | Evidencia de selección |
|---|---|---|---|
Router IP | Reenvía paquetes IP entre redes | Conversión serie o remapeo automático de registros | Rutas, reglas de firewall, VPN y extremos aceptados |
Servidor serie | Transporta bytes serie por una ruta IP | Interpretación Modbus o conversión TCP sin función explícita | Modo de transporte, software de extremo y parámetros serie |
Pasarela de protocolo | Interpreta una variante de origen y genera una variante de destino admitidas | Compatibilidad universal con PLC o nube | Dirección de conversión, roles, identificadores de unidad y mapeo |
Por qué son esenciales los gateways/routers Modbus
Una pasarela resulta útil cuando el diseño aprobado necesita conversión serie/TCP, consultas y agregación documentadas o una interfaz admitida hacia la aplicación superior. El encaminamiento, las reglas de firewall y una VPN pueden proporcionar una ruta controlada entre sedes. La segmentación y la disponibilidad dependen del conjunto: una pasarela no aísla automáticamente todos los fallos ni protege un PLC expuesto por otras vías.
Selección y alcance de las soluciones Wavetel
Capacidades que verificar
En un proyecto Wavetel, separe primero la función de red de la adquisición. Revise modelo exacto, interfaces serie y Ethernet, opciones de firmware, roles cliente/servidor, dirección de conversión y límites del mapeo. Si se necesita MQTT, HTTP o un servicio en la nube, verifique formato de carga útil, credenciales, reconexión y compatibilidad de plataforma en esa configuración. La categoría de producto no basta como prueba.
Evalúe límites ambientales, alimentación, recuperación y operaciones de gestión remota según la instalación. Un firewall o una VPN compatibles deben configurarse conforme a la política del sitio y probarse; su presencia no garantiza una transmisión segura. Guarde la configuración aceptada y registre versión de software, procedimiento de recuperación y responsable de futuros cambios.
Escenarios de aplicación de los gateways Modbus de Wavetel IoT
Los siguientes ejemplos ayudan a seleccionar y probar una configuración Wavetel adecuada. Describen responsabilidades y evidencias de aceptación; no afirman que todos los routers Wavetel conviertan protocolos o agreguen datos hacia la nube.
Aplicación | Necesidad del proyecto | Posible rol configurado | Evidencia de aceptación |
|---|---|---|---|
Supervisión del agua | Leer caudal y presión distribuidos | Equipo de adquisición serie/TCP adecuado con ruta WAN autorizada | Valores conocidos, marcas de tiempo, recuperación y control local de bombas protegido |
Supervisión de fábrica | Recopilar puntos acordados de distintos PLC | Interfaces admitidas y mapeo explícito por controlador | Valores y unidades correctos, carga acotada y derechos documentados |
Medición energética | Recopilar lecturas para una aplicación de energía | Consultas y entrega superior si las implementa el modelo elegido | Mapa del contador, calendario, tratamiento de datos ausentes y recepción en aplicación |
Integración de gateways/routers Modbus en sistemas Sensores-PLC-IoT
La integración práctica distribuye cuatro responsabilidades: el sensor produce una señal; el PLC la valida, escala y utiliza; un cliente o pasarela configurado lee solo los puntos acordados; y la red transporta tráfico autorizado a SCADA u otra aplicación. El servidor Modbus puede exponer registros de retención, registros de entrada, bobinas o entradas discretas según el proyecto. No hay que forzar todo valor a un registro de retención ni añadir un router donde la topología no lo requiera.
Etapa | Tarea de configuración | Evidencia antes de ampliar |
|---|---|---|
Sensor y PLC | Verificar cableado, escala, lógica local y punto legible acordado | Vista del PLC coherente con una medida conocida y unidad documentada |
Extremo Modbus | Definir variante, rol cliente/servidor, convención de dirección y parámetros de red/serie | Una lectura documentada funciona con el código previsto |
Pasarela y red | Configurar solo conversión, mapeo, consultas y ruta remota necesarios | Valores de origen/destino correctos, carga acotada y recuperación tras corte |
Aplicación | Mapear el valor aceptado en SCADA o una interfaz superior admitida | Marca de tiempo, unidad, calidad, permisos y recepción de extremo a extremo |
Use la tabla de configuración como lista de entrega. Elija la frecuencia de consulta según los límites del equipo y la necesidad de la aplicación, y pruébela con una carga realista. Una suscripción en la nube o un panel es el último paso tras validar el protocolo y la interpretación; no demuestra por sí mismo que la medida del PLC sea correcta.
Prepare un mapa de puntos antes de consultar
Para cada valor, registre su origen y su interpretación antes de configurar la aplicación:
Campo | Qué registrar |
|---|---|
Origen | Identificador del sensor y entrada o punto de datos correspondiente en el PLC |
Extremo del protocolo | Modelo y firmware del dispositivo, rol cliente/servidor y variante RTU/ASCII/TCP |
Solicitud Modbus | Grupo de datos, código de función, referencia del manual y convención de dirección u offset del cliente |
Interpretación del valor | Tipo de dato, con o sin signo, orden de bytes y palabras, escala y unidad |
Acceso y tiempos | Permiso de solo lectura o escritura, actualización prevista e intervalo de consulta permitido por el diseño del dispositivo y la aplicación |
Una etiqueta como 40001 no tiene por qué ser la dirección numérica que debe enviar el cliente. Compruebe tanto el manual del dispositivo como la convención de direccionamiento del software cliente.
Empiece con un único punto documentado y una consulta de solo lectura. Compare la respuesta con un valor conocido y confirme las unidades y el escalado antes de añadir registros o permitir escrituras. Esto ayuda a distinguir un problema de transporte de un error de dirección o de formato de datos.
Deje claras las rutas de control y supervisión
Defina qué sistema realiza el control y cuál recopila o presenta datos. No suponga que una pasarela de supervisión o una plataforma remota asume la función de control del PLC. Especifique el tráfico permitido, quién puede escribir valores y qué debe ocurrir cuando no esté disponible la conexión hacia el sistema superior.
Para la supervisión remota, documente el límite de la red, los extremos autorizados, los permisos de las cuentas y la ruta de los registros. La guía de NIST sobre seguridad de la tecnología operativa ofrece recomendaciones generales para planificar segmentación, acceso y supervisión en redes OT. Aplique los requisitos de seguridad y control de cambios de la instalación a la topología real.
No incorpore consultas desde la nube a una ruta de control hasta que el responsable haya definido su finalidad, los accesos permitidos y el comportamiento durante una interrupción de red. La frecuencia de actualización debe proceder de las necesidades de la aplicación y de la documentación de los equipos, no de un valor de ejemplo genérico.
Al añadir recopilación remota, mantenga explícita la responsabilidad del control local.
Ponga en marcha el sistema en pasos pequeños y observables
Verifique la señal del sensor o la interfaz digital en el PLC y confirme el valor y la unidad en su proyecto.
Confirme en los manuales vigentes el extremo Modbus, la variante, los roles, la convención de direcciones y el código de función admitido.
Lea un punto conocido sin efectuar escrituras y compare la respuesta con el valor que muestra localmente el PLC.
Añada puntos en grupos pequeños y observe el tiempo de respuesta, los tiempos de espera agotados y la carga del dispositivo con el programa de consultas previsto.
Pruebe la ruta de red aprobada y la política de acceso, y registre qué ocurre cuando falla la conexión hacia el sistema superior.
Si un valor del PLC, un variador o el SCADA queda desactualizado o las consultas agotan el tiempo de espera, utilice la guía de diagnóstico de PLC/Modbus para distinguir un fallo del dispositivo de un problema en la ruta de comunicación. Guarde el mapa de puntos junto con el firmware y la configuración probados para poder comparar los cambios posteriores.
Escenarios de aplicación y un despliegue ilustrativo
Escenarios de aplicación
La fabricación puede utilizar tendencias de estado para apoyar el mantenimiento; la energía recopila contadores y generación; los edificios supervisan climatización; y el agua controla presión y caudal en varias sedes. Defina siempre magnitud, responsable del control local, actualidad requerida y comportamiento al perder la comunicación. Una alerta necesita datos validados y una regla o método analítico definido.
Una modernización de fábrica ilustrativa
Considere una modernización de fábrica ilustrativa, sin resultados medidos de un cliente. Un ingeniero verifica la interfaz del sensor de vibración y el valor del PLC, mapea un punto acordado de solo lectura y prueba un cliente o pasarela adecuado. La aplicación almacena después tendencias con marca de tiempo y señala una condición definida para revisión de mantenimiento. Una pérdida WAN no debe cambiar implícitamente el control del PLC. Contraste las alarmas con inspecciones antes de afirmar capacidad predictiva.
Juzgue el piloto por calidad de datos observada, peticiones fallidas, actualidad, recuperación y utilidad para mantenimiento. Cualquier reducción declarada de paradas, desplazamientos o costes requiere una base documentada y un periodo comparable. Al añadir máquinas, repita el mapeo y las pruebas de carga; no copie sin comprobar la primera configuración.
Conclusión
Un sistema IIoT integrado funciona cuando interfaz del sensor, programa del PLC, mapa Modbus, conversión y ruta IP tienen una tarea definida y un límite verificable. Empiece con un valor conocido, conserve la responsabilidad de control local y amplíe gradualmente el diseño probado. Mantenga juntos manuales, mapas de puntos, firmware y registros de aceptación para comprobar el siguiente cambio.
Preguntas frecuentes
¿Todos los sensores industriales utilizan Modbus?
No. Un sensor puede proporcionar una interfaz analógica, discreta, de impulsos o de comunicación digital. Consulte su manual y los módulos de entrada o comunicación admitidos por el PLC antes de elegir un protocolo de red.
¿El PLC expone automáticamente todos los valores de sensores como registros Modbus?
No. El proyecto del PLC y la configuración del dispositivo determinan qué valores se mapean, cómo se representan y qué códigos de función y roles cliente/servidor están disponibles. Verifique el mapa en la documentación del PLC.
¿Una pasarela Modbus es lo mismo que un router IP?
No. Un router IP reenvía paquetes IP. Un equipo de transporte serie puede llevar bytes sobre IP. La conversión de protocolos requiere una función de pasarela que admita expresamente las variantes de origen y destino.
¿Hay que introducir siempre 40001 como primera dirección en el cliente?
No. Es una referencia habitual al primer registro de retención (holding register), pero el manual y el software pueden requerir un offset que comienza en cero u otra convención. Compruebe ambos extremos y verifique el resultado con un punto documentado de solo lectura.
¿Debería una plataforma en la nube consultar directamente el PLC?
Depende de la arquitectura y la política de seguridad aprobadas. Defina el límite de la red, los permisos de acceso, la carga de las consultas y el comportamiento ante una interrupción antes de conectar un servicio remoto. No convierta al sistema remoto en parte de la ruta de control de forma implícita.
