UNIVERSIDAD TÉCNICA FEDERICO SANTA MARÍA

DEPARTAMENTO DE ELECTRÓNICA

Alternativa Seleccionada a Desarrollar en Proyecto de Titulación

“Desarrollo de una interfaz gráfica de configuración, supervisión y adquisición de

datos para una herramienta de torque”

Presentado por: Stefan Christiansen ZúñigaROL USM: 2730007-3

Profesor guía: Manuel Olivares Salinas

Tutor en KRRC: Gonzalo Arroyo

Fecha: 06/06/14

Sistema en Matlab

HMI 1

Usuario

PC 1

HMI 2

PC 2

Usuario

Proyecto de Titulación

INTRODUCCIÓN

En el presente documento se seleccionará una de las tres alternativas de solución que se han expuesto para el Proyecto de Titulación en el documento Alternativas de Solución [1], utilizando para ello diversos criterios que permitirán determinar la conveniencia de una u otra alternativa. Luego de ello, se dará paso al detalle de la misma, donde se explicará cómo es que ella permite solucionar el problema planteado, el cual consiste en supervisar y controlar la simulación del sistema mediante una interfaz hombre máquina (HMI), en primera instancia cuando ambas aplicaciones se encuentran en un mismo PC, y luego cuando la HMI de supervisión y control es operada desde otro PC. La simulación se considerará entonces, como disponible en una aplicación Matlab, radicando el problema en cómo ingresar/exportar datos a este esquema desde/hacia otra aplicación que implemente la HMI, y como ésta última logra intercambiar datos con otra HMI ubicada en un PC diferente, según se muestra en la Figura 1.

Figura 1. Diagrama de Flujo de Datos Matlab – HMI 1 - HMI 2 - Usuario

CRITERIOS DE SELECCIÓN

De acuerdo a lo expuesto en el documento Alternativas de Solución, se encontraron tres opciones que permiten supervisar y controlar la simulación del sistema mediante una HMI en un mismo PC, sin centrarse aún en la comunicación entre las HMI de un PC a otro. Esto fue realizado de esa manera debido a que lograr la comunicación entre una simulación en Matlab y una aplicación HMI, representa un problema de mayor complejidad que comunicar 2 HMI en PC’s diferentes de acuerdo a los estudios que se realizaron. Es por esto que los criterios de selección también están basados en cómo se puede lograr la comunicación entre la simulación y la HMI. Los criterios a considerar son los siguientes:

1

Proyecto de Titulación

- Funcionamiento de la aplicación HMI en Windows: Puesto que se tiene gran accesibilidad, información y manejo de Windows, resulta conveniente desarrollar la aplicación en dicho Sistema Operativo.

- Simplicidad en la programación: Puesto que el tiempo para realizar el proyecto es limitado, una programación fácil ayuda a ocupar este recurso en forma óptima.

- Nivel de información del que se dispone: Contar con información abundante respecto de la aplicación HMI permite que la solución escogida pueda realizarse en forma rápida, impide que ocurran trabas en el desarrollo por desconocimiento y otorga mayor cantidad de opciones para enfrentar el problema desde distintos enfoques.

- Disponibilidad de la aplicación HMI: Aun cuando se cuente con toda la información necesaria para desarrollar una aplicación, si no se dispone de la plataforma que permite llevarla a cabo, entonces no es posible ejecutar la solución asociada.

- Redundancia de la plataforma de la aplicación: Una determinada plataforma, por ejemplo LabView, puede ofrecer más de una alternativa de solución. Eso da pie a que si una de las alternativas no funciona en la práctica, pueda recurrirse a otra alternativa sin necesidad de tener que cambiarse de plataforma.

La ponderación relativa que tienen cada uno de los criterios en la decisión final de la alternativa escogida, de acuerdo a las condiciones, recursos y tiempo del que se dispone son las siguientes:

Criterio de Selección Porcentaje de RelevanciaFuncionamiento de la aplicación HMI en Windows 25%Simplicidad en la programación 20%Nivel de información del que se dispone 15%Disponibilidad de la aplicación HMI 25%Redundancia de la plataforma de aplicación 15%Porcentaje Total 100%

Tabla 1. Ponderación de cada uno de los criterios de evaluación

Se ha dado un mayor porcentaje de relevancia a la disponibilidad de la aplicación y a su funcionamiento en Windows porque son aspectos críticos de la alternativa a escoger. Luego sigue

2

Proyecto de Titulación

la simplicidad en la programación, porque el tiempo que tarda lograr la comunicación entre la simulación y la HMI depende en gran medida de este punto. Finalmente, el nivel de información del que se dispone y la redundancia de la plataforma de la aplicación tienen cierto nivel de importancia, pero no son críticos.

EVALUACIÓN DE LAS ALTERNATIVAS

Para evaluar cada una de las alternativas se utilizará el siguiente sistema de puntuación:

Sistema de PuntuaciónMuy

Deficiente Deficiente Aceptable Bueno Óptimo0,1 - 0,2 0,3 - 0,4 0,5 - 0,6 0,7 - 0,8 0,9 - 1

Tabla 2. Sistema de Puntuación Utilizado para evaluar alternativas

Las alternativas a evaluar, que permiten realizar la comunicación entre el sistema en Matlab y la aplicación HMI son tres:

1. LabView mediante Simulation Interface Toolkit (SIT).

2. Fix Dmacs mediante conexión DDE.

3. LabView mediante conexión DDE.

La puntuación de cada alternativa se detalla a continuación.

1. LabView mediante Simulation Interface Toolkit (SIT)

- Funcionamiento de la aplicación HMI en Windows: Puntuación = 1 (LabView y Simulation Interface Toolkit funcionan en Windows).

3

Proyecto de Titulación

- Simplicidad en la Programación: Puntuación = 0,8 (La configuración de la HMI es simple. No se necesita ser experto en programación, sino que sólo se debe aprender a ocupar SIT).

- Nivel de Información del que se dispone: Puntuación = 0,9 (Existe bastante información en la WEB respecto de cómo se utiliza SIT para comunicar LabView con Matlab).

- Disponibilidad de la aplicación HMI: Puntuación = 0,5 (Se dispone de la versión de evaluación de LabView y Simulation Interface Toolkit).

- Redundancia de la plataforma de aplicación: Puntuación = 0,6 (Si por algún motivo falla SIT en la plataforma LabView, puede recurrirse a la opción 3: LabView mediante conexión DDE).

2. Fix Dmacs mediante conexión DDE

- Funcionamiento de la aplicación HMI en Windows: Puntuación = 1 (Fix Dmacs funciona en Windows).

- Simplicidad en la Programación: Puntuación = 0,6 (Los códigos que permiten comunicar la HMI con Matlab requieren de conocimientos de de ambos lenguajes de programación (Fix y Matlab), lo que podría ralentizar su implementación).

- Nivel de Información del que se dispone: Puntuación = 0,3 (La información que existe en la WEB respecto de cómo realizar una conexión DDE entre Matlab y Fix es reducida o difícil de encontrar).

- Disponibilidad de la aplicación HMI: Puntuación = 0,5 (Se dispone de la versión de evaluación de Fix Dmacs).

- Redundancia de la plataforma de aplicación: Puntuación = 0,6 (Si por algún motivo falla la implementación con la plataforma Fix Dmacs hay que cambiarla por LabView).

4

Proyecto de Titulación

3. LabView mediante conexión DDE

- Funcionamiento de la aplicación HMI en Windows: Puntuación = 1 (LabView funciona en Windows).

- Simplicidad en la Programación: Puntuación = 0,6 (La configuración de la comunicación se realiza mediante programación gráfica en LabView, pero además se requiere conocer los comandos para iniciar la conexión DDE, lo que podría ralentizar si implementación).

- Nivel de Información del que se dispone: Puntuación = 0,5 (Existe información suficiente en la WEB respecto de cómo utilizar las módulos DDE de LabView y de Matlab por separado, pero reducida en cuanto a la conexión específica entre ambos software).

- Disponibilidad de la aplicación HMI: Puntuación = 0,5 (Se dispone de la versión de evaluación de LabView).

- Redundancia de la plataforma de aplicación: Puntuación = 0,6 (Si por algún motivo falla la conexión DDE de LabView, puede recurrirse a la opción 1: LabView mediante SIT).

En la Tabla 3 se evalúa cada una de las alternativas, de acuerdo a la ponderación que tiene cada criterio. Ella muestra, que con una puntuación total del 76%, la opción más conveniente es la de LabView mediante SIT, luego con un 66% la de LabView mediante conexión DDE y finalmente con un 54% la de Fix Dmacs mediante conexión DDE. Con todo, la alternativa seleccionada para realizar la conexión entre el sistema en Matlab y la HMI es LabView mediante Simulation Interface Toolkit.

5

Proyecto de Titulación

Criterio de Selección PuntuaciónLabView SIT FIX DDE LabView DDE

Funcionamiento de la aplicación HMI en Windows 1 1 1Simplicidad en la programación 0,8 0,6 0,6Nivel de información del que se dispone 0,9 0,3 0,5Disponibilidad de la aplicación HMI 0,5 0,5 0,5Redundancia de la plataforma de la aplicación 0,6 0 0,6Puntuación Total 76,00% 54,00% 66,00%

Tabla 3. Tabla de Evaluación de cada alternativa

ALTERNATIVA SELECCIONADA LABVIEW MEDIANTE SIMULATION INTERFACE TOOLKIT

En el documento Alternativas de Solución [1] se explica en detalle cómo es que se logra realizar la comunicación entre Matlab y LabView mediante SIT, razón por la cual se profundizará ahora en la comunicación entre dos HMI implementadas en LabView ubicadas en PC´s diferentes.

Luego de lograr la conexión entre Matlab y LabView con SIT, es posible comunicar dicha interfaz LabView con otra interfaz LabView ubicada en otro PC en red, mediante TCP/IP, donde una aplicación funciona como servidora y la otra como cliente respectivamente. La comunicación TCP/IP proporciona una interfaz de usuario simple que contiene a su vez toda la complejidad que garantiza una comunicación en red confiable [2], dando una alternativa fiable para la medición de datos en lugares remotos, y la oportunidad de ejercer el control de una planta de grandes dimensiones desde una ubicación central [3]. TCP/IP es un protocolo de internet (Internet Protocol – IP), cuyo nombre se refiere a protocolo de control de transmisión (Transmission Control Protocol). El envío de datos desde un lugar a otro, se realiza en una subdivisión de ellos en paquetes, cada uno de los cuales puede tomar diferentes rutas a través de la red para llegar a su destino. Así, puede ocurrir que estos paquetes lleguen en instantes diferentes, fuera de orden, o que no todos lleguen a su destino, sin embargo TCP/IP soluciona estos problemas, reordenando

6

Proyecto de Titulación

los paquetes o solicitando un reenvío de los datos en caso de pérdida de información, lo que le da confiabilidad a la comunicación.

El proceso de comunicación en sí, involucra una apertura de la conexión, lectura y escritura de información, y cierre de la conexión, mediante bloques a los cuales se accede a través de la paleta Functions >> Communication >> TCP. En TCP/IP, como en muchos protocolos de comunicación, el cliente es el que inicia la conexión con el servidor. En el diagrama de bloques de la figura 2, se muestra una aplicación cliente que inicia una conexión a un servidor remoto a través del bloque TCP Open Connection. El servidor escucha la conexión remota y responde apropiadamente.

Figura 2. Diagrama LabView que implementa un cliente TCP/IP

El bloque TCP Write escribe datos sobre el otro computador en red, para ello cuenta con al menos tres entradas: Connection ID, Error Signal, y el Dato a enviar. Connection ID y Error Signal también se utilizan para los bloques TCP Read y TCP Close Connection, mientras que el dato a enviar es del tipo string, por lo que si se quiere enviar un dato numérico, primero se debe cambiar el formato a string. También pueden modificarse el timeout y el número de bytes que contiene el dato. En la Figura 3 se muestra un ejemplo de uso del bloque TCP Write que escribe un string en un computador remoto. Considerando que se tiene un string de entrada y una open connection, el primer bloque toma como entrada el string a ser transmitido, y calcula su longitud, asumiendo que puede ser especificada por dos enteros. La longitud del string es un entero, por lo que se convierte en string para ser la entrada de uno de los bloques TCP Write, el cual asume que este tiene dos bytes de largo y lo envía al computador remoto. Luego el string es enviado, y eventualmente la conexión es cerrada. Note que esta configuración tiene 3 entradas: Connection ID, la señal Error Status y el string a ser enviado; y dos salidas: Connection ID y la señal Error Status.

7

Proyecto de Titulación

Figura 3. Ejemplo de configuración de TCP Write para escribir un String en un computador remoto

El bloque TCP Read en cambio, lee bytes desde el computador remoto, contando también con al menos tres entradas: Connection ID, Error Signal y una Entrada Entera, que especifica el número de bytes que se quieren leer. La salida de este bloque corresponde al string compuesto de los bytes que son leídos. En la Figura 4 se muestra un ejemplo de uso del bloque TCP Read, que permite recibir un string enviado desde un computador remoto. Asumiendo que se tiene un Open Connection, y considerando que la longitud del primer string recibido puede ser representada por dos enteros (2 en cuadro azul), el primer string contiene el dato de la longitud del string que se desea recibir (Por ejemplo si el string a recibir tiene 17 bytes de longitud, el primer string obtenido con TCP Read toma el valor 17). Como la longitud del string es un string, debe ser convertido a número para ser ingresado en el segundo TCP Read, el cual en su salida data out contiene el string recibido. Si se quieren ejecutar cálculos numéricos sobre este último, debe convertirse su formato de dato string a formato número. Note que esta configuración tiene 2 entradas: Connection ID y la Señal Error Status; y tres salidas: Connection Status, la señal Error Status y Data Out, desde donde se obtiene el dato recibido en formato string.

Figura 4. Ejemplo de configuración de TCP Read para recibir un String desde un computador remoto

El bloque TCP/IP Close Connection, cierra la conexión entre los dos computadores en red.

En la Figura 5, se muestra un diagrama de bloques de una aplicación servidora. También cuenta con los bloque TCP Read, TCP Write y TCP Close Connection, pero se diferencia por el

8

Proyecto de Titulación

bloque TCP Listen. Este último escucha en la red a otros computadores que intentan conectarse al puerto especificado por el número entero que se ingresa a su entrada, que no debe estar siendo usado por otra aplicación del sistema (En el ejemplo el puerto 5020). Cuando TCP/IP Listen escucha a otro computador intentando conectarse al puerto correcto, establece una Connection ID y un Error Signal en sus salidas, las cuales son usadas después por los otros bloques. Es importante no tener otro bloque TCP/IP Listen con el mismo número de puerto una vez que la conexión ha sido establecida. Una vez que la Connection ID está disponible, se está en condiciones de enviar y recibir datos a través de la red, dando una conexión confiable entre los dos computadores involucrados.

Figura 5. Diagrama LabView que implementa un servidor TCP/IP

CONCLUSIONES

Luego de revisar el documento Alternativas de Solución, en el cual se presentan tres opciones que permiten establecer una comunicación entre un sistema modelado en Matlab y una aplicación que implemente una HMI, se ha escogido la alternativa que presenta las mejores condiciones para su desarrollo en base a una serie de criterios previamente establecidos. Dicha alternativa corresponde a implementar la aplicación HMI en la plataforma LabView mediante Simulation Interface Toolkit, la cual es una herramienta creada por National Instruments, dedicada especialmente a la comunicación LabView/Simulink.

Posteriormente, se profundizó en cómo lograr la comunicación entre dos PC’s en red mediante TCP/IP en LabView, con el fin de poder supervisar y controlar la simulación desde un PC remoto. Esta forma de comunicación ofrece transferencia de datos en tiempo real, interfaz simple y comunicación bidireccional en base a una estructura cliente-servidor. Con esto se da fin al estudio previo de los tópicos que involucra el Proyecto de Titulación “Simulación y Diagrama 3D de Control y Supervisión de un Sistema Diesel-Generador-Motor-Hélice”, con lo que se puede dar inicio a la planificación del trabajo de memoria asociado, a desarrollar durante el segundo semestre del presente año.

9

Proyecto de Titulación

REFERENCIAS

[1] Michael Silva M., “ Alternativas de Solución de Proyecto de Titulación: Simulación y Diagrama 3D de Control y Supervisión de un Sistema Diesel-Generador-Motor-Hélice”, Departamento de Electrónica, Universidad Técnica Federico Santa María.

[2] http://w3.usa.siemens.com/us/SiteCollectionDocuments/WSSResources/Internet/Products/ModbusInformation.pdf

Un detalle importante con respecto a los protocolos de comunicación en la herramienta Handy 2000, es que en el controlador de la herramienta el puerto de los buses de campo correspondientes a DeviceNet, Profibus-DP, CC-link y Ethernet/IP, es opcional. Esto significa que para implementar cualquiera de esos protocolos, se debe incurrir en un costo extra. Únicamente el protocolo Modbus se puede implementar gratuitamente a través del puerto Serial o Ethernet ya incluidos. También según el software donde se cree la interfaz manejando los I/O, se puede encontrar que para implementar los primeros protocolos se deben adquirir controladores determinados, mientras que en Modbus se puede acceder a librerías gratuitas de bajo nivel que permiten realizar la implementación de manera flexible.

Un detalle importante con respecto a la elección del software en el caso de este proyecto, es que Komatsu Reman Center Chile tiene una relación de proveedor-cliente con National Instruments, disponiendo de licencias para LabVIEW, soporte y capacitaciones. Es por ello que el costo de esta alternativa es considerablemente menor que el resto.

http://www.ni.com/white-paper/7675/en/

HTTP://WWW.NI.COM/WHITE-PAPER/5761/EN/

HTTP://WWW.NI.COM/WHITE-PAPER/4917/EN/

10