Caso de éxito: Red Modbus RTU con en sector Aguas
Nuevo caso de éxito. En este caso, para contarte cómo hemos implementado una red de comunicación Modbus RTU con PLC’s en una estación de bombeo de aguas pluviales.
El caso inicial
Empecemos por el principio. Tenemos un cliente que necesitaba integrar datos de varios equipos dedicados a controlar sistemas de bombeo de agua.
En este caso, estos equipos se comercializan como máquinas que controlan las bombas de agua con un programa determinado, y dejan la posibilidad de ser comandados y comunicarse a través de Modbus RTU. Además, hay algunas válvulas y medidores que también usan este protocolo.
El caso es que nuestro cliente quería controlar estos equipos a través de un PLC con un programa un poco más complejo. Además, este PLC se tenía que comunicar con un sistema SCADA.
¿Qué pasos seguir para implementar una red Modbus RTU?
En resumen, que teníamos que comunicar varios equipos con el protocolo en cuestión, y para ello teníamos que implementar una red de comunicaciones.
Si tienes equipos Modbus RTU, y quieres comunicarlos con un PLC, debes seguir varios pasos:
- Hacer un listado de cada equipo y asignarle una dirección.
- Registrar el mapa de memoria de cada equipo y saber dónde están las variables que necesitas.
- Hacer una prueba de comunicación individual con cada equipo y el PLC.
- Probar la red con todos sus equipos.
- Implementar el código sobre el PLC y probar el funcionamiento.
- Finalmente, diseñar el sistema de visualización que necesitas.
Te puedes estar preguntando si hay que ser muy riguroso con cada una de las pruebas que necesitas hacer… La respuesta es sí. ¿Por qué? Porque cuanto más riguroso seas, menos probabilidades de fallo habrá en cada uno de los pasos, y más fácil será detectar donde puede estar el error en caso de problema.
¿Cómo funcionó todo?
Luego de haber diseñado y probado el sistema, podemos decir que la instalación quedó funcionando perfectamente. Por experiencia, sabemos que las comunicaciones Modbus, una vez se testean, son muy fiables.
De hecho, nuestro cliente va a seguir el mismo patrón de ingeniería en cada una de las instalaciones que van a seguir a esta. Vamos, todo un éxito.
Antes de irte…
Si necesitas implementar una red, no olvides que tenemos un curso de Modbus disponible. En cambio, si prefieres que te ayudemos en su implementación, no dudes en contactarnos. Ofrecemos soporte y asistencia.
¿Qué es una topología de red?
Si trabajas con redes, o intentas comunicar un dispositivo con otro, tarde o temprano te enfrentas al término topología. ¿Qué es?
La forma física en cómo se conectan nodos (ya sean pc’s, servidores, etc.) es lo que llamamos como topología de red. Existen diferentes topologías más o menos estandarizadas que tiene cada una sus propias características y que también son aplicables al protocolo TCP. En este post repasaremos algunas de las más comunes.
Topologías Estrella y Anillo
La del tipo estrella, es una de las configuraciones de red más comunes. En esta configuración, cada nodo se conecta a un dispositivo de red central, como un concentrador o un conmutador.
Esta topología tiene la principal característica que la comunicación de todos los nodos pasa por un nodo central. Esto significa que si se produce un fallo en el nodo central, todos los demás perderán la comunicación entre sí. Por lo tanto, en esta configuración es muy importante asegurar que las capacidades de este nodo serán las suficientes por el alto tráfico que deberá soportar.
Por otro lado, la topología ring (o anillo) es una configuración de red en la que las conexiones de dispositivos crean una ruta de datos circular
Por lo tanto, en esta configuración, cada nodo es transmisor y receptor al mismo tiempo, pasando las señales de una estación a otra. En estas configuraciones existe el conocido “paso de token” o testigo, porque se necesita saber si el tráfico ya ha pasado por un nodo determinado. Una derivación de esta topología es la red de doble anillo.
Bus y otras topologías
Es una configuración que tiene todos los nodos conectados a un circuito común. En este caso por lo tanto, toda la información viaja por un cable – el bus -.
Este tipo de configuración se caracteriza porque, si alguno de los nodos falla, la comunicación se va a mantener, puesto que la comunicación del bus es independiente del buen funcionamiento de un nodo determinado.
¿Otras topologías? ¿Cuál es la correcta?
Hay muchísimas topologías: algunas de ellas son las Line, Fully connected, Tree y Mesh, entre otras, cada una con sus propias características.
La elección de una u otra depende de múltiples factores. Por un lado, la disponibilidad, ya que no siempre están disponibles en todos los protocolos de comunicación o recursos disponibles. Por el otro, cada una tiene sus propias ventajas e inconvenientes, por lo que en función de tu caso, va a depender mucho del proyecto que tengas que implementar.
¿Quieres aprender más sobre redes?
Si estás buscando información clara y concisa, en forma de un curso online, te recomendamos sin duda nuestro Curso de Redes TCP.
OSI, la pirámide de las comunicaciones
Todos asumimos que los protocolos de comunicación funcionan y sirven para llevar datos de un punto a otro. Por detrás, existe una tecnología que puede variar en función del protocolo. Sin embargo, lo que se mantiene inalterable es el modelo que emplean todos: OSI.
¿En qué consiste?
El modelo OSI, del inglés Open System Interconnection, se desarrolló por la ISO (International Organization for Standarization) como una arquitectura para comunicaciones electrónicas y es una referencia para el desarrollo y comprensión de protocolos.
Dicho de otra forma, OSI presenta un modelo común para entender cómo funcionan los protocolos y también para diseñar nuevos, ya que los divide en capas funcionales.
La pirámide de 7 capas
Las pirámides tienen una punta y una base. Desde el punto de vista funcional, pasa lo mismo con la capa OSI, la punta es el funcionamiento, mientras que la base mantiene el funcionamiento.
En OSI, se especifican siete capas:
- Aplicación, 7
- Presentación, 6
- Sesión, 5
- Transporte, 4
- Red, 3
- Enlace de datos. 2
- Física, 1
Las capas en las que OSI divide los protocolos tienen funciones muy específicas. Las capas inferores (1 a 3), se dedican a transportar los datos a nivel físico, mientras que las superiores (4 a 7) se dedican a presentar la información a nivel de aplicación.
Ejemplos: OSI en TCP
Veamos el ejemplo del modelo TCP/IP (Protocolo para el Control de Transmisión/ Protocolo de Internet), está compuesto por cuatro capas (simplifica a OSI), en la que cada una se encarga de determinados aspectos en la comunicación y a su vez cada una brinda un servició especifico a la capa superior.
En la imagen vemos la pila OSI (izquierda) y su modelo TCP/IP (derecha)
Conclusión, ¿Para qué sirve OSI?
En resumidas cuentas, para estandarizar protocolos de comunicación en un modelo comprensible para todos. Esto hace que los protocolos se diseñen, mantengan, y configuren en un lenguaje común, lo que sin duda hace que tanto desarrolladores como usuarios puedan generar comunicaciones de forma mucho más efectiva.
¿Te gustaría seguir profundizando en el tema? Revisa entonces nuestro recurso digital sobre Redes TCP.
Buses de campo en Codesys
Una de las mejores funcionalidades que tiene Codesys es su capacidad para poder comunicarse con todo tipo de dispositivos mediante diferentes protocolos de comunicación y buses de campo. ¿Te interesa configurarlos en Codesys? Sigue leyendo.
¿Qué son?
Empecemos por lo esencial. Los buses de campo son medios de comunicación electrónicos e industriales para comunicar PLC’s con otros PLC’s o periferia descentralizada.
En su día, publicamos este post donde te ampliamos la información.
¿Cómo los usa Codesys?
Los buses de campo se integran en Codesys mediante librerías propias, lo que significa que podemos programar las comunicaciones mediante configuradores o mediante bloques.
Los configuradores están perfectamente integrados y se pueden usar para programar las comunicaciones de forma sencilla e intuitiva:
Por el otro lado, los bloques e instrucciones específicas permiten programar las comunicaciones de forma dinámica, lo que en algunas veces puede ser beneficioso para programar determinadas funciones.
¿Qué buses de campo soporta Codesys?
Codesys cada día se amplía, pero para resumir podríamos decir que tenemos disponibles:
- Modbus en sus diferentes variantes (TCP, RTU…)
- PROFIBUS y PROFINET
- EtherNet / IP
- EtherCAT
- BACnet
- J1939
- Sercos
- IO-Link
Unos cuántos, ¿Verdad?
Beneficios de usar Buses de Campo en Codesys
Además de las propias ventajas que tiene poder comunicarse con tantos tipos de dispositivos, hay otras ventajas implícitas, que las podríamos resumir en:
- Generar la configuración en el mismo entorno (sin tener que aprender e instalar cosas nuevas)
- Depurar errores en el mismo entorno que la lógica del PLC
- Elegir con más libertad el protocolo o bus que usaremos para la aplicación (tenemos tantos disponibles…)
Seguir aprendiendo
Este año hemos iniciado nuestros Workshops con buses de campo con Codesys, donde, entre otros, hablamos de Modbus, I/O Link, Ethercat y CANOpen.
Y tú, ¿Cuáles usas? ¿Te sientes cómodo con ellos?
Nuevo Evento I/O Link con Codesys
Desde hace unos años, I/O Link ha emergido como una prometedora tecnología dentro de la norma IEC 61131 (Sí, la misma de Codesys). Como especialistas en IEC61131, hemos decidido organizar un evento I/O Link donde se muestre como integrar Codesys con I/O Link.
¿Qué es Codesys?
Es un software de programación de PLC’s basado en la normativa IEC 61131-3, . Una de sus mayores particularidades es que es agnóstico al hardware, lo que posibilita que se puedan programar muchos controladores. Tienes más información en nuestra serie de artículos codesys.
¿Qué es I/O Link?
I/O Link es parte de la normativa IEC61131, de la que también forma parte Codesys. En particular, I/O Link es la sección IEC61131-9, que resuelve la interfaz de comunicación entre PLC’s con sensores y actuadores.
Por lo tanto, diríamos que se trata de un protocolo de comunicación orientado a la comunicación de sensores y dispositivos en la industria. Hay muchas ventajas en I/O Link, pero seguramente la más importante es la de formar parte del estándar -lo que genera la independencia de hardware, al igual que ocurría con Codesys-.
Puntos de la Jornada
Durante la jornada, haremos una demostración de las capacidades de I/O Link. En particular, veremos diferentes casos sobre cómo se usa la tecnología, y cómo combinarla con Codesys y OPC UA para tener una fábrica inteligente.
El enfoque de la jornada es muy práctica, y va a incluir tanto presentaciones técnicas como demostraciones para facilitar una rápida comprensión de la tecnología.
¿Cuándo y dónde?
El evento I/O Link será en Munro, Buenos Aires, el día 10 de Marzo de 2020. El evento lo organizaremos junto con la empresa Aumecon, representante de Turck en Argentina.
¿Cómo apuntarse?
Puedes solicitar tu vacante consultándonos aquí. Si eres un gerente, programador, integrador de sistemas, técnico de mantenimiento y en general estás interesado en conocer más de I/O Link, no deberías dejar pasar esta oportunidad.
Buses de campo
La imperiosa necesidad de integrar cada día más señales de control en la industria llevó a buscar alternativas al cableado habitual ¿Te interesa saber más sobre buses de campo? Sigue leyendo.
¿Qué es un bus de campo?
Empecemos por lo esencial. Los buses de campo son medios de comunicación electrónicos e industriales para comunicar PLC’s con otros PLC’s o periferia descentralizada.
Dicho de otra forma, un bus de campo es un bus que nos permite comunicar con otros dispositivos con un protocolo específico en campo, es decir, en una área de fabricación.
¿Por qué debería comunicarse un PLC con un bus de campo?
Bueno, ya sabrás que una de las características esenciales de los PLC es su capacidad de comunicarse con su entorno mediante Entradas y Salidas. Las Entradas y Salidas normalmente se comunican con el PLC mediante módulos específicos y cada una de ellas es cableada por separado.
El bus de campo integra muchas señales, reduciendo en gran medida los costes de instalación
Los buses de campo se caracterizan por hacer lo mismo pero simplificando la instalación, puesto que el cable permite integrar muchas más señales. Además, estos buses tienden a ser cada vez más inteligentes, lo que significa que permiten llevar señales adicionales como fechas de calibración etc.
Los beneficios de los buses de campo por lo tanto son muchos, pero resumiendo: instalación más rápida, mejor mantenimiento, más interoperabilidad y reducción de tiempos de parada.
¿Qué buses de campo existen hoy en día?
El desarrollo tecnológico ha hecho que surjan muchos y diferentes. Por ejemplo, AS-I, Profibus, Modbus, etc. Cada uno con sus diferentes particularidades y ventajas.
Seguramente, la evolución tecnológica de los últimos años ha venido acompañada por los pasos hacia delante en la electrónica, lo que ha permitido que los buses más nuevos tengan mayores capacidades de comunicación, más velocidad, etc.
¿Debería usar aprender a usar buses de campo?
Si estás trabajando en automatización industrial, más temprano que tarde vas a tener que aprender, así que sí… Por eso, te recomendamos que eches un vistazo a este curso sobre buses.
TCP y UDP, aplicaciones en la industria
Las aplicaciones que se comunican con Ethernet usan normalmente uno de estos dos protocolos, TCP o UDP. ¿Cuál es la diferencia entre ambos? ¿Para qué se usa cada uno? En esta entrada repasamos las propiedades y ventajas de cada una de estas tecnologías
¿Qué es TCP?
Las siglas son Transmission Control Protocol. La principal característica que diferencia a TCP es que este protocolo garantiza la entrega de los datos entre el emisor y el receptor de un mensaje.
¿Se usan en la industria? Por supuesto. Casos:
- Comunicaciones PLC a PLC
- Comunicaciones PLC a PC (Incluido OPC, etc.)
- Comuninicaciones PC a PC
- Comunicaciones PC a Cloud
Es decir, se usan para casi todo… Las comunicaciones TCP sin ir más lejos son las que usamos todo el tiempo para comunicarnos. Sobre tu navegador, en definitiva, haces una petición como cliente a algun servidor donde está alojada la web con TCP.
¿Qué es UDP?
Las siglas son User Datagram Protocol. Se trata de un protocolo que permite el envío de datos sin la necesidad que exista una conexión establecida.
Las propiedades de UDP hacen que sea un protocolo más ágil, aunque UDP no controla la entrega de la información.
¿Se usan en la industria? Sí, aunque en casos más específicos, pero igualmente útiles. Por ejemplo:
- Si vas a enviar una temperatura que está fluctuando, lo puedes hacer perfectamente con UDP. ¿Y si se pierde un paquete? Nada, la inercia de las temperaturas es tan lenta que no vas a notar cambios. Es decir, que si pierdes un “23.23” y recibes el siguiente paquete con un “23.223”, te dará igual.
- Si necesitas hacer un broadcast (envío a muchos) a varios servidores, sobre vídeo… ¿Qué pasa si se pierde un paquete? Nada, el emisor seguirá enviando imagen todo el tiempo..
UDP de hecho es usado para aplicaciones VoIP o DHCP, entre otras.
¿Qué se usa en la industria?
Pues de todo. Las comunicaciones TCP y las UDP tienen cada una sus propias particularidades, que las hacen beneficiosas en cada caso.
Sin entrar en formalismos, el resumen es que las comunicaciones TCP son más interesantes cuando se necesita establecer una comunicación segura, mientras que las UDP pueden ser más beneficiosas cuando se envían streams de datos que fluctuan todo el tiempo, además de broadcast.
Curso de comunicaciones TCP en la industria
Si eres de aquellos que lleva tiempo buscando algun curso de introducción para saber de una vez la diferencia entre TCP, UDP, FTP, etc. o buscas cómo abrir y cerrar puertos, te traemos buenas noticias, puesto que muy pronto lanzaremos un Curso Digital sobre comunicaciones TCP.
OPC UA: Conexiones y sesiones
Sesiones
Lo más importante, las comunicaciones en OPC UA se basan en sesiones. Las sesiones representan una conexión entre la aplicación cliente y la aplicación servidor. En este punto, es bueno diferenciar entre una conexión y una sesión. La conexión se produce cuando el cliente apunta a un endpoint – el del servidor -, y éste le devuelve la “conexión”. En el momento que esto pasa, se establece una sesión, que no es ni más menos que el flujo de información que fluye a través de la conexión generada (como si de una autopista se tratara). Aunque la diferencia a nivel práctico es poca, seguramente conviene recordar que la sesión está más ligada al flujo de datos.Timeouts y sesiones
¿Qué sentido tendría tener una conexiones y sesiones abiertas si en las mismas no fluyen datos? …Ninguna. Por lo tanto, las sesiones, en general, deben estar “vivas” todo el tiempo… Esto significa que, si una sesión se cierra por lo que sea, luego los clientes y servidores deben desconectarse entre sí. En la práctica, esto significa que cliente y servidor pueden monitorear el estado de la sesión para que noten los problemas con suficiente anticipación y, en caso de desconexión, puedan ser notificados y cerrar la conexión. Los timeouts son herramientas que tienen clientes y servidores para que, teniendo un tiempo predefinido, puedan consultarlo y, en su caso, cerrar la conexión. Por ejemplo, en OPC UA muchos clientes tienen el timeout especificado en una hora, lo que significa que, si no ha habido flujo de datos en ese tiempo, cierran el canal de la comunicación.Parámetros de sesión
Para generar comunicaciones fiables y seguras en el tiempo, es deseable parametrizar diferentes parámetros en una comunicación OPC UA basada en sesiones. ¿Ejemplos? La cantidad de sesiones abiertas, el timeout y la negociación de la reconexión y son sólo algunos de los parámetros a los que nos referimos.¿Dónde y cómo setear estos parámetros?
A pesar de la conveniencia de poder configurar estos parámetros, los mismos no siempre están disponibles en los GUI de clientes y servidores para configurarlos. En cualquier caso, eso no significa que no puedan ser manipulables. En Opiron contamos con varias herramientas para ello. ¿Tienes algún problema con la sesión o los timeouts? Aquí estamos para ayudar 😉Soluciones OPC UA
¿Quiénes somos?
Somos expertos en tecnología OPC UA y partners de ProsysOPC. Nuestros servicios incluyen desde consultoría, proyectos o Workshops regulares.
Y tú, ¿Cómo proteges tus comunicaciones Modbus?
Si eres un fiel lector del blog, ya habrás leído varias notas que hemos publicado sobre la tecnología Modbus. Un protocolo fiable, fácilmente implementable y que encontramos en muchísimas aplicaciones e industrias diferentes. Sin embargo, es ciertamente vulnerable, aqui te explicamos a proteger Modbus.
Antes de nada, si no sabes nada de Modbus, te recomiendo que leas nuestro índice de la serie.
Una perspectiva
Modbus es un protocolo simple, no fue diseñado para lidiar con ninguna cuestión relativa a seguridad. ¿Por qué? Bueno, Modbus existe desde hace muchos años y, en el momento en el que se desarrolló (ya hace varias décadas), nadie tenía una preocupación excesiva en la ciberseguridad. De hecho, Modbus ha estado normalmente comunicando datos de forma aislada y en un ambiente controlado, entre equipos de campo y software industrial.
Sin embargo, el panorama ha ido cambiando con el tiempo. Es evidente que existen virus y ciberataques cada vez más enfocados a la industria y, desde luego, Modbus es una presa fácil para los ciberdelincuentes.
Cómo funciona
Una aplicación puede acceder a MODBUS a través del puerto 502 en la pila TCP / IP. En Modbus, se utiliza un esquema simple de solicitud-respuesta para todas las transacciones MBAP. El cliente inicia una solicitud y el servidor responde.
Por ejemplo, cuando un SCADA requiere un valor de un PLC, envía un mensaje de solicitud para iniciar el proceso de transferencia de datos.
Riesgos de seguridad
La implementación del protocolo MODBUS / TCP contiene múltiples vulnerabilidades que podrían permitir a un atacante realizar una actividad de reconocimiento o emitir comandos arbitrarios.
- Falta de confidencialidad: Todos los mensajes MODBUS se transmiten en texto claro a través de los medios de transmisión.
- Falta de autenticación: no hay autenticación en ningún nivel del protocolo MODBUS.
- Falta de integridad: No hay controles de integridad integrados en el protocolo de aplicación MODBUS. Como resultado, depende de los protocolos de capa inferior para preservar la integridad
- Tramas simplistas: Las tramas MODBUS / TCP se envían a través de conexiones TCP establecidas.
- Falta de estructura de sesión: Al igual que muchos protocolos de solicitud / respuesta (es decir, SNMP, HTTP, etc.) MODBUS / TCP consiste en transacciones de corta duración. Esto, puede hacer que los atacantes pueden inyectar comandos sin conocimiento de la sesión existente.
La solución, OPC UA
La solución más rápida y sencilla es sin duda implementar OPC UA sobre Modbus. OPC UA es el protocolo de la industria 4.0 y está pensado para ser seguro. Si quieres saber más sobre OPC UA, te recomiendo leer nuestra serie.
OPC UA implementa seguridad en tres niveles diferentes para la autenticación, la firma y encriptación y el uso de certificados digitales.
En la práctica, implementar OPC UA sobre Modbus es fácil gracias a nuestro ProsysOPC UA Modbus Server, que además de Modbus TCP, también implementa OPC UA sobre Modbus RTU.
Más información
Si necesitas más información no dudes en contactarnos, estaremos disponibles!
Caso de éxito: De 0 a 1000 datos en tiempo record
Este es un caso de éxito, para una empresa dedicada al sector de la energía localizada en Tucumán, Argentina.
El Caso
El sector tiene diferentes PLC’s Allen Bradley. Ya hace varios años que las redes de control, donde residen los SCADA, PLC’s, etc, se encuentran en una red diferente al resto. Esto es así porque se quiere asegurar la integridad de las redes y no poner en riesgo la producción.
El sector tiene un responsable de asegurar que los sistemas de información de la planta funcionan correctamente. Ello incluye asegurar que las redes están configuradas correctamente, pero también que el software y el resto de la infraestructura se encuentran libres de riesgos.
El desafío
Al responsable del área se le encomienda la misión de llevar algunos datos críticos de su sistema de control al software ERP de la empresa. Los gerentes quieren además poder tener algunos datos en tiempo real en las oficinas centrales, localizadas a varios cientos de kilómetros.
El desafío es mayúsculo. Se precisa asegurar la integridad de las redes, y al mismo tiempo, llevar datos del sistema SCADA al ERP sin poner en riesgo la integridad de los sistemas.
La solución
¿Cómo hacerlo? ¿Con qué protocolo? ¿Cuántos puertos tendré que liberar? Las preguntas son muchas y las respuestas son más bien limitadas.
El responsable del área nos contactó después de leer varios de nuestros articulos en el blog. Después de intercambiar algunos correos, hicimos una videconferencia, donde revisamos el caso y explicamos la mejor solución.
En este caso, ni siquiera tuvimos que ir físicamente a la planta, con algunas sesiones remotas y algunas otras instrucciones, el problema quedó resuelto en menos de 8 días.
Resultado y conclusiones
Fantásticos. El ERP tiene datos. El SCADA quedó inmune de cualquier inconveniente. Se siguen respetando las políticas de seguridad de la empresa.
¿Te ha resultado interesante la historia? ¿Tienes un problema similar? No dudes en contactarnos.