Utilizar el protocolo de red adecuado

Cada tipo de comunicación involucra objetivos (generalmente sistema de adquisición de datos o controladores) y hosts (generalmente mostrando la HMI) que se pueden organizar en varias configuraciones. Usted puede tener comunicación entre un solo objetivo y un solo host (1: 1); entre múltiples objetivos y un solo host (N: 1), o comunicación entre un solo objetivo y múltiples hosts (1: N). La siguiente sección describe cada tipo de comunicación utilizado en aplicaciones de control de máquinas, sus configuraciones comunes de sistemas y sus requisitos de red y transferencia de datos.

Comunicación basada en comandos o mensajes

La comunicación basada en comandos o mensajes es una transferencia de información poco frecuente generada por un evento específico. Esto podría ser presionar un botón o una alarma, que activa una respuesta específica. En la arquitectura basada en comandos, hay dos tipos de sistemas involucrados: un sistema de comando (host) y un sistema de funcionamiento (objetivo). El comandante envía instrucciones que el sistema de funcionamiento debe ejecutar. Los comandos deben entregarse sin pérdidas y deben tener una latencia mínima. Por ejemplo, cuando un operador presiona un botón, esperan que la acción asociada se ejecute sin tener que presionar el botón nuevamente. También esperan que el sistema responda en un período de tiempo razonable. La configuración más común es 1:1, pero también son posibles N:1 y 1:N.

Comunicación de datos entre procesos

La comunicación de datos entre procesos consiste en la transferencia periódica de los últimos valores de las variables del proceso. Este tipo de comunicación es la comunicación más común y es útil para aplicaciones de control y para HMIs que se utilizan para mostrar los estados actuales del sistema.  Por ejemplo, esto se usaría para actualizaciones periódicas enviadas desde uno o varios controladores embebidos en una HMI, que monitorea el estado de la(s) máquina(s).  El operador necesita ver el estado actual de las máquinas, por lo que la transmisión sin pérdidas no es un requisito porque el controlador en tiempo real o HMI solamente actúa sobre el último valor.

Este tipo de transferencia de datos se puede utilizar entre controladores embebidos y es posible que deba ejecutarse a altas velocidades.  Sin embargo, el uso más común de la comunicación de datos de proceso es para actualizar una HMI.  Este tipo de comunicación implica velocidades de actualización más lentas porque los humanos están visualizando los datos. Las velocidades de actualización de 1 a 30 Hz suelen ser suficientes; cualquier cosa más rápida sobrecarga los recursos de la CPU y la memoria, y es más información de la que el operador humano puede procesar visualmente. Una buena regla general es que las pantallas numéricas deben actualizarse a velocidades no superiores a 1-2 Hz, y para las pantallas gráficas, 30 Hz proporciona actualizaciones sin problemas.

Comunicación por transmisión/en búfer

Cuando se transmiten datos, se envían grandes cantidades de información de forma continua, pero no necesariamente en tiempo real. Este tipo de comunicación es útil cuando usted desea enviar muchos datos y necesita capturar cada punto de datos. A menudo, aunque no siempre, la transmisión es unidireccional y tiene una configuración 1:1. Implica el almacenamiento continuo en búfer de los datos para que no se pierdan. Un uso común de la comunicación por transmisión es cuando un objetivo está realizando una adquisición de datos de alta velocidad y los datos deben transferirse al host para su registro o posprocesamiento.

Tabla 1.1. Resumen de los tipos de comunicación de control de máquinas

Al elegir un protocolo de red para su aplicación, hay varios factores que debe evaluar, que incluyen:

• Tipo de comunicación
• Configuración del sistema
• Rendimiento
• Facilidad de uso
• APIs de terceros compatibles

Los tipos de comunicación y las configuraciones del sistema mencionadas anteriormente serán el factor determinante más importante al elegir el protocolo de red para su aplicación. Los requisitos de rendimiento y la facilidad de uso dependerán de su aplicación específica y su experiencia en programación. Finalmente, si planea desarrollar su aplicación para comunicarse con aplicaciones de terceros, como las desarrolladas con C o VB, necesitará usar protocolos de red que puedan interactuar con APIs de terceros. Al examinar estos factores, usted podrá tomar la decisión correcta para su aplicación. Consulte la Tabla 1.2 para obtener un resumen de cada protocolo de red en relación a los factores anteriores.

Tabla 1.2. Resumen de protocolos de red (= Mejor, = Mejor, = Bueno, * = depende de la acción que se esté completando en el servicio web)

TCP y UDP

Los protocolos de internet TCP y UDP son bloques de construcción de bajo nivel utilizados por todos los protocolos de red que se discuten en este documento. Todos los demás protocolos proporcionan una abstracción fácil de usar además de estos protocolos; debido a esto, TCP y UDP ofrecen el mayor rendimiento y proporcionan un control de bajo nivel que permite la mayor flexibilidad. Se pueden usar TCP y UDP para construir su propio protocolo personalizado, como STM.

TCP

TCP es un protocolo de comunicación punto a punto confiable; los datos se entregan de forma ordenada y sin pérdidas. Es un protocolo basado en conexión, lo cual significa que debe establecerse una conexión entre el cliente y el servidor antes de transferir datos. Para garantizar la entrega de datos, TCP retransmite los datos hasta que recibe una confirmación. El cliente y el servidor TCP se comunican a través de un puerto específico.

UDP

UDP se diferencia de TCP en que publicará datos en un puerto específico, pero no requiere una conexión con un cliente antes de enviar los datos. Si no hay conexión para recibir los datos en su destino, los datos simplemente se descartan; no hay verificación para una entrega exitosa. Por lo tanto, UDP no debe usarse en aplicaciones donde es crítica la transferencia de datos sin pérdidas.

Las funciones UDP se pueden utilizar para comunicarse con un solo cliente, o los datos se pueden transmitir a varios clientes. La multidifusión UDP es un modo que se utiliza para comunicarse de manera eficiente entre un solo remitente y varios clientes en una red, sin requerir que el remitente mantenga una lista de clientes. UDP tiene las velocidades de transferencia más altas de todos los protocolos que se discuten aquí, pero no garantiza una transmisión de datos sin pérdidas.

TCP y UDP son protocolos de red de alto rendimiento, pero esto sacrifica la facilidad de implementación. La conexión de red requiere una gestión manual y cada conexión consume un puerto. TCP y UDP requieren que todos los datos se envíen en formato de secuencia. Esto significa que el remitente debe compactar todos los datos a una secuencia y el receptor debe restaurar los datos de la secuencia. Esto agrega una capa adicional de complejidad a la transmisión de datos sin secuencias.

TCP y UDP son buenas herramientas para la comunicación basada en mensajes y las aplicaciones de transmisión personalizadas. Soportan todo tipo de configuraciones y, dado que son estándares de la industria, se pueden utilizar con aplicaciones de terceros.

Variables Compartidas Publicadas en la Red

Las variables compartidas publicadas en la red son una herramienta de LabVIEW fácil de usar para compartir datos. Son fáciles de implementar y soportan la mayoría de los tipos de datos de LabVIEW y definiciones de tipo personalizadas.

La variable de red en LabVIEW se compone de tres partes: nodos de variables de red, el motor de variables compartidas y el protocolo de publicación-suscripción de NI (NI-PSP). Los nodos de variables de red se colocan en el diagrama de bloques para realizar las operaciones de lectura y escritura de la variable. El motor de variables compartidas es el componente de software que aloja los datos publicados. Esto se puede alojar en objetivos en tiempo real o en PCs con Windows, pero debe ejecutarse en al menos una máquina en red.  NI-PSP es un protocolo de red patentado que optimiza el transporte de variables compartidas en la red. Este protocolo está basado en TCP/IP, lo que le permite transmitir datos de manera eficiente y confiable a través de la red.

Usted puede habilitar el almacenamiento en búfer en variables compartidas publicadas en la red, lo cual es apropiado cuando necesita una manera fácil de implementar comunicaciones pseudo-sin pérdidas N: 1 y 1: N. El almacenamiento en búfer de variables compartidas ayuda a prevenir la pérdida de datos debido a retrasos temporales en la red, pero no garantiza la transferencia de datos sin pérdidas. Si un cliente escribe datos más rápido de lo que otro cliente lee los datos, eventualmente se producirá un desbordamiento y los datos se perderán; el flujo de datos no se gestiona para evitar el desbordamiento. Incluso si todos los clientes están leyendo a una velocidad lo suficientemente rápida, es posible que se pierdan datos si se transmiten mientras la conexión TCP subyacente se interrumpe debido a interrupciones en la red. Se recomiendan flujos de red cuando se desea una transferencia de datos punto a punto sin pérdidas. Las variables compartidas publicadas en la red son más adecuadas para la comunicación de datos de proceso cuando el último valor de una variable de proceso es importante.

Flujos de red

Los flujos de red son una característica de LabVIEW lanzada en LabVIEW 2010 diseñada para proporcionar una transmisión de datos eficiente.  Proporcionan abstracciones de alto nivel fáciles de usar para manejar conexiones, desconexiones y control del flujo de datos, y mantener un rendimiento similar de TCP/UDP sin procesar. Son un canal de comunicación sin pérdidas, unidireccional y uno a uno que consiste en un escritor y un punto final de lectura. Debido a su naturaleza sin pérdidas, también se pueden utilizar como base para comunicación basada en mensajes.

Los flujos de red pueden transferir la mayoría de los tipos de datos de LabVIEW , incluyendo clústeres y arreglos por la red, pero los flujos son más eficientes con los siguientes tipos de datos:

• Escalares numéricos
• Booleanos
• Arreglos en 1D de escalares numéricos
• Arreglos en 1D de booleanos

Puede utilizar flujos de red para pasar datos de una PC a otra, de una PC a un objetivo en tiempo real o de un objetivo en tiempo real a un objetivo en tiempo real. Dado que los flujos de red son unidireccionales, si usted desea pasar datos en ambos sentidos entre sus puntos finales, deberá abrir dos flujos. Del mismo modo, si usted necesita pasar datos a varios objetivos, debe abrir varios flujos.

Servicios web

Los servicios web le permiten crear aplicaciones web que se comunican a través de la red con cualquier cliente web compatible con HTTP, incluyendo los navegadores web estándares. LabVIEW le permite publicar un VI como un servicio web del lado del servidor; este VI se conoce como un VI de método web. Este servicio web se implementa en un servidor web propio de ejecutables o en el servidor web de aplicaciones, y se puede alojar en PCs con Windows y en plataformas de cómputo de NI en tiempo real. Esta característica de LabVIEW tiene la ventaja de ser capaz de interactuar con numerosos dispositivos y aplicaciones con capacidad HTTP, que no están limitados a productos de National Instruments. Muchos usuarios pueden monitorear una o varias aplicaciones desde diferentes plataformas y ubicaciones. La facilidad de uso y la eficiencia dependerán del cliente web y de su familiaridad con la programación de aplicaciones web.

Los datos se intercambian con el VI de método web utilizando una URL y métodos HTTP estándares. Por ejemplo, puede proporcionar datos de entrada para los controles en el VI de método web desde un cliente Web utilizando métodos HTTP estándares, como POST. Los datos se devuelven al cliente HTTP a través de las terminales de salida del VI o mediante la transmisión de datos a través del servidor web.  Con el método de terminal, cuando el servidor web recibe una solicitud, devuelve cualquier dato conectado a una terminal de salida al cliente web como una secuencia de lenguaje de marcado extensible (XML). El servicio web también se puede configurar para devolver datos en lenguaje de marcado de hipertexto (HTML), notación de objetos JavaScript (JSON) o formato de texto. Un VI de método web también se puede configurar para usar el modo de salida de flujo. Este modo de salida le permite devolver datos en un formato personalizado; usted puede implementar el almacenamiento en búfer y utilizar encabezados HTML personalizados. Con estos dos modos de salida disponibles, los servicios web son adecuados para aplicaciones de monitoreo o transmisión.

A continuación se resume qué protocolo de red es el más adecuado para cada tipo de comunicación en aplicaciones de control de máquinas.

Comunicación basada en comandos o mensajes

La comunicación basada en mensajes requiere una transmisión confiable y velocidades de transferencia rápidas. La Tabla 1.3 enumera todas las opciones para la comunicación basada en mensajes. Esta aplicación es mejor con flujos de red; son confiables, fáciles de usar y pueden ofrecer velocidades de transferencia rápidas. Sin embargo, si necesita una configuración del sistema 1:N o N:1 o necesita transferir datos con aplicaciones de terceros, TCP/UDP son más apropiados. Para facilitar su uso, aún se pueden utilizar múltiples flujos de red si N es pequeño. Los servicios web se pueden usar con un rendimiento similar al de TCP con análisis, pero pueden ser más fáciles de usar.

Tabla 1.3 Protocolos de red adecuados para comunicación basada en mensajes

Comunicación de datos de proceso

La comunicación de datos de proceso solo está interesada en el valor más reciente. Por lo tanto, las velocidades de transferencia y envío garantizadas no son tan importantes. La Tabla 1.4 enumera todas las opciones para comunicación de datos de proceso. Las variables compartidas son la característica de LabVIEW recomendada para esta aplicación. Son fáciles de usar y permiten numerosas configuraciones del sistema. También gestionan automáticamente la conexión de la red. Los servicios web deben usarse cuando los datos deben monitorearse desde múltiples ubicaciones en PCs sin LabVIEW. De manera similar, se debe usar TCP/UDP si los datos serán monitoreados por aplicaciones de terceros.

Tabla 1.4 Protocolos de red adecuados para comunicación de datos de proceso

Comunicación por transmisión/en búfer

La comunicación por transmisión requiere velocidades de transferencia rápidas y una transmisión confiable. La Tabla 1.5 enumera todas las opciones para la comunicación por transmisión/en búfer Se recomiendan flujos de red para esta aplicación. TCP/UDP debe usarse para configuraciones N:1 o 1:N y si necesita transmitir datos a una aplicación de terceros.

Tabla 1.5 Protocolos de red adecuados para comunicación por transmisión/en búfer