Archivo de categoría Conectividad

La fiabilidad de MQTT

Una pregunta más o menos recurrente cuando se habla de MQTT en un contexto industrial es, ¿Cuán fiable es la comunicación MQTT? ¿Será seguro implementarlo  en la industria? Aquí clarificamos cómo se concibe un tema tan importante en comunicaciones.

Fiabilidad MQTT: QoS

Antes de nada: cuando hablamos de fiabilidad, nos referimos al grado de confianza que tenemos en el protocolo para asegurarnos que el envío y recepción de mensajes entre emisores y receptores funcionan de manera éxitosa. ¿Es lo bastante fiable a nivel industrial?

Como ya te comentamos en post previos, MQTT puede aplicarse en la industria. Y se puede aplicar en la industria porque una parte esencial del protocolo es la definición de la fiabilidad. 

Niveles QoS

Una de las definiciones clave dentro del concepto de fiabilidad son las Calidades de Servicio. Las Calidades de Servicios (QoS, Quality of Service), son los niveles que contempla la propia tecnología para asegurar que los mensajes se envían y se entregan con la fiabilidad que se necesite.

En MQTT los mensajes se pueden entregar de acuerdo a “Quality of Service (QoS)”. Existen tres calidades de servicios diferentes: QoS 0, QoS 1 y QoS 2, ordenados de menos a más calidad.

QoS 0 significa que la entrega se realizará como mucho, una vez. En este caso, los mensajes se confían la red, y por lo tanto, el emisor sólo envía el mensaje una vez, confiando en que el receptor la reciba. No hay reintentos de envío, ni nada por el estilo.

QoS1 es el segundo nivel, y significa que la entrega se realizara, al menos una vez. En este envío, el emisor envía, un paquete “ACK”, que deberá ser tratado como “no reconocido” hasta que el cliente lo haya recibido.

QoS 2 significa, exactamente una entrega. En este caso, el receptor debe hacer una aceptación en un proceso de 2 pasos del paquete que recibe.

La implementación de la QoS depende en muchos casos de las necesidades, pero también de la disponibilidad (Que esté soportada por los diferentes interlocutores).

Gestión de mensajes y Sesiones

Otro aspecto interesante a tener en cuenta con las comunicaciones MQTT es la gestión que se realiza en cuanto a mensajes y sesiones.

En cuanto a sesiones, todo cliente MQTT abre una sesión cuando se comunica con un Broker. Si la sesión en algun momento se pierde, los clientes pueden iniciar automáticamente procesos para establecer sesiones nuevas. Cada sesión en MQTT además contiene información relevante de la comunicación.

Otro aspecto interesante está en la gestión de mensajes. En muchos casos, los publicadores retienen el último mensaje enviado. Esto lo hacen porque, si algún cliente se conecta o desconecta, pueda recibir el último mensaje. Por ejemplo, si un publicador está enviando el valor de una temperatura a múltiples clientes, un nuevo cliente podría recibir esa temperatura (Esto se puede hacer mediante el uso de flags y los LWT).

Entonces, ¿Es MQTT fiable para la industria?

Hay muy buenas razones para pensar que la fiabilidad MQTT es lo suficientemente alta para implementarse  a nivel industrial.  De hecho, cada vez hay más PLC’s, librerías y aplicaciones con este protocolo.

¿Estás pensando en implementar MQTT? Si es así o tienes cualquier otra duda, no dudes en contactarnos!

4 Herramientas MQTT imprescindibles

Quieres implementar MQTT.

Tienes elegida una arquitectura, pero te preguntas qué herramientas MQTT necesitas para implementar tu proyecto.

En este post te contamos 4 herramientas (probadas) que vas a necesitar para implementar MQTT con éxito.

Cliente MQTT

Lo primero que vas a necesitar es un cliente MQTT.

Un cliente MQTT es un software que te permite conectar a un broker y poder publicar y suscribirte a un tópico de forma cómoda.

Aunque hay muchos disponibles, una opción muy recomendable sin dudas es:

Este cliente MQTT está basado en Java y está disponible en Windows, MacOSX y Linux. Es intuitivo, fácil de usar y realmente funciona.

Broker MQTT 

Sin Broker no hay comunicación. Por lo tanto, esta es otra herramienta que sí o sí necesitas.

En este sentido, podemos recomendar dos Brokers:

Mosquitto es un broker MQTT libre y Open Source, que puedes correr sobre Windows y Linux. También existe unaa versión online.

HiveMQ es un broker comercial, pero igualmente muy potente e interesante porque entre otras cosas tiene un broker online bastante popular dentro de entornos industriales.

Librerías MQTT

Ahora que tienes un cliente y un broker, seguramente quieres que un dispositivo pueda publicar datos de vez en cuando.

Osea, que la temperatura o mensaje de turno sean publicados automáticamente por tu dispositivo.

Para esto, necesitas disponer de librerías MQTT para poderse implementar sobre el dispositivo con el que vas a trabajar. En esto es más difícil dar una recomendación únicamente.

Por ejemplo, si vas a usar Codesys una muy buena opción son las librerías propias de 3S Smart Software.

Aplicaciones de red

¿Y si la red falla? ¿Cómo lo detectas?

Aunque es bastante obvio, vas a necesitar de herramientas que te permitan hacer un diagnóstico rápido de tu red para poder hacer un diagnóstico de tus comunicaciones.

Recomendaría básicamente dos:

MQTT Ping es una herramienta que te permite saber si un broker ha caído o no. Está escrita en Python y es realmente útil cuando la comunicación cae y poder hacer un diagnóstico rápido.

¿Quién no conoce Wireshark hoy en día? Cuando las cosas se ponen más feas, siempre es posible recurrir a él para hacer análisis más potentes. Imprescindible siempre.

¿Más ayuda?

Estamos buscando ayudarte y hemos lanzado recientemente nuestro portal de soporte para proyectos:

Como verás, estamos más que dispuestos a ayudarte para tu próximo proyecto!

En cualquier caso, no dudes en contactarnos!

¿Es MQTT industrial?

Si has llegado hasta aquí es porque te preguntas sobre el MQTT.

¿Es el MQTT industrial? ¿Es fiable? ¿Cómo se aplica? ¿Qué ventajas tiene?

¿Hay espacio en la industria para otro protocolo?

Buena pregunta.

Dentro del mar de protocolos que existen en la industria (Modbus, OPC UA, etc. ) uno se puede preguntar si existe espacio para otra tecnología. Y si existe este espacio, qué ventaja puede aportar.

Porque no nos engañemos, a nivel industrial hay una gran oferta de protocolos. Hay tantas empresas y fabricantes proveyendo tecnologías, y desde hace tantos años, que es normal que esto sea así.

Entonces, ¿Cómo puede ser que surja una nueva tecnología como MQTT que esté en la boca de todos?

Las necesidades en la industria

El mundo cambia. Constantemente. Y la industria también.

Y sino, échale un vistazo a tu álbum de fotos de hace 25 años… No me dirás que no has cambiado. Si le pegas una mirada rápida a la foto, verás los coches, los semáforos, los peinados… Qué nostalgia y qué recuerdos!

Pero esto es justamente signo del cambio. Todo evoluciona y en la industria también. Las necesidades son muchas veces las mismas, pero también se necesitan nuevas tecnologías que se adapten al futuro.

Y MQTT, en este sentido, es claramente una nueva tecnología que se adapta al futuro.

¿Dónde cabe el MQTT industrial?

MQTT es un protocolo de comunicación ligero.

Ligero porque se no necesita un gran ancho de banda para funcionar. Y ligero porque funciona en todo tipo de dispositivos, incluso en pequeños sensores con bajo poder computacional.

¿Te suena de algo el IoT? ¿E Industria 4.0? Pues como ya sabes, estos nuevos paradigmas vienen para quedarse, y en ellas es donde mejor se adapta el MQTT industrial. Porque esta tecnología es beneficiosa y porque se adapta perfectamente a la infraestructura industrial existente.

Por esto, el MQTT es industrial, porque va a resolver varios problemas que explicaremos en posts venideros.

¿Cómo puedo implementar MQTT industrial?

Si quieres acelerar e implementar tu proyecto, tenemos un plan de soporte que te interesa. Te esperamos 🙂

De Arduino a Codesys con Modbus

Si estás buscando una forma para comunicar Arduino y un PLC, este post te va a interesar. Te explicaremos como llevar datos de Arduino a Codesys, uno de los entornos de programación más dinámicos en el mundo de la automatización industrial.

¿Cómo ir de Arduino a Codesys?

Los habituales del blog ya saben que Modbus es uno de los protocolos más famosos en el mundo de la automatización industrial. Es un protocolo ideal porque se puede implementar en todo tipo de dispositivos, y es un protocolo muy fiable en cuanto a comunicaciones industriales.

Es tan versátil que se puede implementar sobre placas Arduino, y como no, cualquier dispositivo basado en Codesys (incluido un PLC). Por lo tanto, es el medio que usaremos para generar la comunicación entre ambos.

Vídeo

Sin entrar todavía en más detalles, y como un vídeo vale más que mil palabras, vamos a ver el vídeo donde veremos los detalles de la comunicación entre ambos:

¿Cómo funciona la comunicación entonces? Pues básicamente con un equipo Codesys que hace peticiones periódicas a nuestro dispositivo Arduino. Ambos hablan Modbus para comunicar datos.

Particularidades de la comunicación

Para aquellos que no están habituados a Modbus, seguramente han visto varias palabras que les pueden sonar a chino: Holding Registers, slave id, canal… Todos son conceptos importantes que definen una comunicación. En nuestro caso, usar 2 holdings es sólo un ejemplo para ilustrar cómo funciona la comunicación. Merece la pena mencionar que si necesitáis más información sobre Modbus, tenemos un curso disponible.

Por otro lado, el programa desarrollado en Codesys ha mantenido la llamada “jerarquía IEC 61131-3”. Para aquellos que no saben que es Codesys, aquí tenemos una serie de entradas.

Últimos detalles

Arduino y Codesys (o cualquier otro PLC) son perfectamente integrables. Y no sólo con Modbus. Hay muchas más alternativas posibles. ¿Estás trabajando con algún proyecto similar? ¿Dudas o consultas? Entonces no dudes en contactarnos!

Serie de articulos sobre Modbus
Serie de articulos sobre OPC UA

¿Que es un SDK?

Si has llegado hasta probablemente buscas información sobre los SDK

¿Qué es un SDK? ¿En qué consiste?

En este post tratamos de dar luz a tus consultas.

¿Qué es un SDK?

La primera consulta es válida.

Un SDK es un Kit de Desarrollo de Software.

Es decir, se trata de un conjunto de librerías que permiten que los programadores puedan desarrollar aplicaciones sin partir de cero, o, dicho de otra forma, con una sólida base ya construida.

Los SDK en definitiva son aplicaciones que ayudan a desarrollar otras aplicaciones.

Hay muchos tipos de SDK’s. En el ámbito que nos ocupa, por ejemplo, hay muchos SDK’s de comunicaciones OPC UA, para hacer otras aplicaciones OPC UA.

Si ya hay aplicaciones, ¿Para qué voy a hacer una?

Buena pregunta. El SDK te da la libertad de desarrollar tu propia aplicación y ser el dueño de la misma. Eso tiene dos ventajas fundamentales:

  • Te liberas del modelo de licenciamiento por máquina, tan típico en el mundo del software
  • Eres libre de desarrollar aplicaciones que se ajusten más a tu medida,y
  • Puedes distribuir tus desarrollos

Como ves, hay razones de peso para tener un SDK, ¿No crees?

Si al final tengo que desarrollar, ¿Por qué pagar por un SDK?

Esta es otra buena pregunta. Seguramente no lo has pensado pero, ¿Cuánto tardarías en desarrollar una tecnología desde la nada? ¿No sería mejor empezar con un esqueleto ya hecho?

Esto es como quien quiere construir una casa. Por supuesto que uno puede ingeniárselas para hacer sus propios ladrillos (juntando agua, tierra, paja y demás), y luego irse al bosque a por leña, etc. Pero, ¿Y la calidad de los materiales? ¿Y el tiempo que te va a llevar hacerlo todo?… ¿No tendría más sentido comprarte un kit de materiales de calidad?

Pues esto mismo es un SDK, un kit de herramientas de software para que puedas empezar a hacer tus aplicaciones fácilmente. Con menos tiempo de desarrollo, y con mayor calidad final.

SDK’s OPC UA

En Opiron ofrecemos SDK’s centrados en tecnología OPC UA, para que ingenieros y empresas puedan desarrollar nuevas aplicaciones OPC UA.

En concreto, tenemos disponibles los siguientes:

¿Más información?

Como siempre, estamos disponibles por cualquier consulta!

De OPC UA a Power BI

¿Usas Power BI para hacer análisis de datos?, ¿Estás pensando en incorporar fuentes de datos de equipos industriales a Power BI? ¿Has pensado en OPC UA como la tecnología para hacer este trabajo? Si la respuesta a las tres preguntas anteriores es que sí, sigue leyendo.

¿Por qué de OPC UA a Power BI?

OPC UA es la tecnología de comunicación industrial por excelencia para conectar dispositivos de planta, como PLC’s, sensores, etc., con todo tipo de aplicaciones, ya sean Windows, Android, etc. Sin duda, usar OPC UA es garantizar el éxito en materia de comunicaciones. Si te interesa saber más sobre OPC UA, no deberías dejar de leer:

Power BI  es una herramienta que permite hacer análisis de datos empresariales mediante dashboards que pueden compartirse y visualizarse de forma amigable.

La conexión de ambos sin duda puede traer grandes beneficios, puesto que en muchos casos, los datos que generan los equipos de planta se necesitan analizar en la empresa.

¿Por dónde empezar?

Lo primero que tienes que tener claro es que OPC UA es una arquitectura cliente – servidor. Esto significa que vas a necesitar al menos dos aplicaciones para generar la comunicación:

    • Un servidor OPC UA que te genere el mapeado con el equipo o equipos a los que quieras conectarte
    • Un cliente OPC UA que vincule la información en Power BI

De clientes y servidores hay muchos, pero seguramente lo más interesante para empezar es revisar si tienes alguno ya disponible.

Un ejemplo y otros datos a tener en cuenta

Un servidor OPC UA es un software que expone datos de un equipo ligado a él. Esto significa que, debajo del propio servidor OPC UA, el equipo y su comunicación no son propios del servidor.

La traducción práctica a lo anterior es que deberás asegurarte que tu servidor implementa una comunicación con tu equipo de forma fiable. Por ejemplo, si tu equipo es Modbus, probablemente necesitarás un OPC UA Server para Modbus.

Un buen ejemplo de esto es una estación metereológica para conectar datos de OPC UA con Power Bi, en una web de Azure de nuestro partner Prosys OPC.

¿Cómo implementarlo?

Si estás evaluando integrar y conectar OPC UA a Power Bi no dejes de escribirnos, será un placer tener noticias tuyas 🙂

Somos expertos en tecnología OPC UA e integración de sistemas 🙂

¿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.

Webinar: OPC UA Java SDK

A menudo, cuando los usuarios se preguntan en qué lenguaje están desarrolladas las aplicaciones OPC UA, desconocen de la existencia de los SDK. Nuestro OPC UA Java SDK es una plataforma ideal para desarrollar aplicaciones OPC UA interoperables y sólidas.

¿Por qué OPC UA?

Quién busca desarrollar aplicaciones a prueba a futuro, capaces de comunicarse con todo tipo de aplicaciones satisfaciendo los requisitos de comunicación más exigentes (en cuanto a arquitecturas complejas, seguridad, etc.), encuentra en OPC UA a su aliado ideal.

OPC UA es una tecnología que mantiene la OPC Foundation, y que lleva más de 25 años siendo sinónimo de fiabilidad y comunicaciones en la industria. Puedes leer más aquí. OPC UA es la evolución de OPC Clásico, y se distingue de ésta, entre otros, por ser una tecnología muliplataforma, adaptable, rica en el modelo de información y adaptada a las necesidades de comunicación del siglo XXI.

¿Por qué Java?

Si OPC UA nació para ser multiplataforma, pasa exactamente lo mismo con Java. Un programa hecho en Java puede ejecutarse sobre cualquier máquina, sin importar el hardware.

Pero no sólo eso. OPC UA busca ser flexible y rico en cuanto al modelado de información. Y Java encaja perfectamente con estos objetivos, puesto que se trata de un lenguaje orientado a objetos.

¿OPC UA Java SDK?

Para los que buscan desarrollar aplicaciones OPC UA, nuestro OPC UA Java SDK es una elección excelente.

Se trata de  una opción sólida para desarrollar aplicaciones clientes, servidores y sistemas OPC UA multiplataforma. El SDK es un kit de desarrollo de software que contiene las funciones que se encargan de todos los detalles de comunicación de OPC UA, lo que significa que el programador se puede centrar sólo en lo que importa: la aplicación.  La interfaz de programación de alto nivel permite el desarrollo rápido de aplicaciones y acelerar su proceso de desarrollo.

Webinar y acceso

Si quieres probar el SDK para empezar a desarrollar aplicaciones, hemos publicado hace apenas unos días un Webinar dónde explicamos cómo empezar con él.

¿Te gustaría empezar a desarrollar aplicaciones OPC UA? Entonces contáctarnos para darte acceso.

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?