Resumen - En el presente trabajo se presenta el proceso realizado para lograr la comunicación de un granulómetro en una central hidrolelectrica , el proceso de descarte de la interfaz original y el diseño y construcción de un módulo para permitir la comunicación del granulómetro laser con el sistema Scada de la central haciendo uso de una plataforma Linux embebida denominada Pcduino.
Palabras clave: Comunicación, Gateway, Modbus, Protocolo, RS232, Servidor.
Abstract: In this work is presented the process performed to achieve Communication with a particle size analyzer on a hidropower plant , the process of discarding the original interface , and the design and construction of a new module to allow Communication between the laser particle size analyzer and the Scada System using a Linux embedded platform called Pcduino.
I. INTRODUCCION
A La planta Hidroeléctrica donde se desarrolló este trabajo realizó la adquisición de un granulómetro láser para el monitoreo de la concentración y tamaño de partícula de los sedimentos en el agua a turbinar. las centrales hidroeléctricas monitorean continuamente las variables de tamaño de partícula y concentración del sedimento en suspensión ya que dichas variables permiten soportar la toma de decisiones en entrada o salida de operación ante factores ambientales tales como crecientes en los embalses. También brindan información sobre la presencia de partículas abrasivas en el agua de alimentación, dichas partículas reducen la eficiencia de las unidades, incrementan los costos de mantenimiento , causan salidas de operación de las turbinas y la consecuente pérdida de productividad [1].
Este trabajo es presentado para optar por el titulo de Especialista en informática y automática industrial, Universidad Distrital Francisco José de Caldas , Bogotá D.C Colombia.
Garcia R. Alex ., Ingeniero en automatización de la universidad de la Salle, Técnico laboral en ensamble Redes y Seguridad Informática Bogotá comunity College – Fenalco - Politecnico Grancolombiano. (e-mail: ing.garciarodriguez@gmail.com).
Sandoval E. John A. Ingeniero electrónico de la escuela colombiana de carreras Industriales, Licenciado en Física de la Universidad Distrital Francisco José de Caldas (e-mail: johnalexander.eng@gmail.com).
Para el caso de la central hidroeléctrica en años anteriores se presentó una creciente que, debido a la los altos tamaños presentados por el sedimento y a las altas concentraciones ocasiono la salida de operación de la planta mientras se evaluaba la estabilidad de las galerías y se hacia la reposición de los equipos afectados por el efecto de sandblasting que desgasto las turbinas , las agujas y otras partes de la infraestructura de generación en casa de maquinas. La adquisición del granulómetro obedece a la necesidad de la planta de contar con una base de datos y de obtener el valor de medición de las variables en tiempo real de manera que soporten la toma de decisiones en entrada o salida de operación para evitar daños en la infraestructura física del la planta
El instrumento adquirido incluía una interfaz de comunicaciones Modbus TCP para la integración y gestión del instrumento al sistema SCADA de la hidroeléctrica. Dicha interfaz resultó ser incompatible con el Gateway existente en la central. Esta situación impidió la integración de los sistemas.
Surge la necesidad de encontrar una manera de integrar los resultados del granulómetro al SCADA de la planta sin realizar modificaciones a la infraestructura existente. Se hizo necesario conocer las causas de la incompatibilidad entre los dos sistemas, conocer el manual de funcionamiento de la interfaz existente El análisis realizado a la interfaz permitió determinar que la incompatibilidad presentada podía ser corregida , en paralelo se procedió a realizar una aplicación a la medida que gestionara las mediciones y organizará los datos de manera que fueran aceptados por el SCADA haciendo uso de un sistema embebido.
II. JUSTIFICACIÓN
El proceso de monitoreo y registro de concentración de sedimentos del agua a turbinar se llevaba a cabo de manera manual , para ello el personal responsable debía dirigirse a la caseta de instrumentación en rebosadero (un trayecto de aproximadamente 30 minutos) donde operaba una bomba para extraer muestras de agua de las bocatomas. Dichas muestras de agua eran vertidas en recipientes de volumen y masa conocidos para ser secados en un horno por cuatro horas y posteriormente evaluar el cambio en la masa de cada recipiente. Esta metodología además de ser dispendiosa no permite obtener resultados en tiempo real. Adicionalmente es altamente susceptible a errores de procedimiento, perdida de calibración de los instrumentos o
Diseño de un Módulo de Comunicación
Ethernet entre un granulómetro y un Scada
para una Hidroeléctrica
García R. Alex R. Ingeniero en automatización, Sandoval E. John A. Ingeniero electrónico.
a variables externas tales como la humedad relativa en el ambiente.
Es claro que la entrada en operación del granulómetro trajo consigo una serie de ventajas tales como: la automatización del proceso de monitoreo de concentración permitiendo el monitoreo en tiempo real , elimina la incertidumbre provocada por la operación y calibración de la instrumentación, así como la incertidumbre provocada por factores climáticos. adicionalmente provee los resultados de análisis de tamaño de partícula del material muestreado centraliza el almacenamiento de históricos y permite la reasignación de recursos (Personal, conductor, vehículos) a otras áreas.
El personal de la planta eligió como sitio de instalación del granulómetro La cámara de válvulas, aguas abajo de las bocatomas en la caseta de instrumentación dentro de la galería.
Tabla 1. Requerimientos básicos de instalación granulómetro. Fuente: manual de fabricante Sequoia Lisst Infinite.
Característica Valor asociado
Tensión de
operación
12 V
Tensión de
alimentación
110 V
Comunicaciones
1 puerto
RS232
1 puerto
Ethernet
modbus TCP
(opcional)
Presión máxima
de la muestra
5 Psi
Presión máxima
entrada agua
limpia
5 Psi.
Rango de
tamaño
1.9 um-381 um
Concentración
0-30.000 PPM
Para la instalación del granulómetro el personal de la planta asignó la caseta de instrumentación en la galería , cámara de válvulas, aguas abajo de las bocatomas. esta locación no cuenta con servicio de energía fiable, por tratarse de un lugar remoto, los equipos allí conectados son alimentados por un banco de baterías que provee un voltaje de 48 V DC. La interfaz Ethernet para comunicación modbus TCP consiste en un Gateway QuickSerser que tiene como objeto permitir la interconexión de dispositivos serial a ethernet y tiene la capacidad de soportar hasta 140 protocolos.
El fabricante del instrumento realiza la configuración del Gateway para que la comunicación con el instrumento se rija por un protocolo propietario.
Dicho protocolo se basa en la escritura o “set” de bobinas, para lo cual con cada set se recibe un token de 80 registros, esta rutina se repite 4 veces antes de obtener resultados del instrumento
Ejemplo Protocolo[2]
1. Set bobina 1 al valor uno 1, gatillando el comando 1 (colectar datos de muestra)
2. Set bobina 1 a 0. 3. Esperar 2 segundos.
4. revisar el valor del registro 7. Esperar a que el valor cambie a 2.1.
5. Set bobina 2 a 1, gatillar el comando 2 (obtener datos de partícula), reset bobina 2 (bobina 2 retorna a 0) .
6. Espera 2 segundos.
7. revisar registro de entrada 9 en busca de errores. 8. suministrar la concentración total del registro 13. 9. Set bobina 3 a 1, gatilla comando 3 (obtener datos de ) reset bonina 3.
10. Espera 2 Segundos.
11. revisar los registros 1 a 160, para datos de soporte y calidad
Debido a la incompatibilidad presentada entre el Gateway SMP16/CP y el procolo configurado por el fabricante en el módulo QuickServer (interfaz modbus TCP) fue requerida la instalación de un computador en esta locación aún en contravía de las políticas de IT de la compañía. El personal procedió a realizar el tendido del cable de red para ingresar dicho pc a la red del personal administrativo, debiendo instalar un terminal en la misma red en el cuarto de monitoreo para la visualización de los resultados.
Esta situación generó el aislamiento del instrumento, sin contar con el consumo energético que requiere el computador en el sitio de instalación.
Figura 1. Modelo de implementación requerido por la central. Fuente: Autores.
SNAP-ARL-ASDS-2
SNAP OEM I/O
Granulómetro
rs232
Gateway
QS Plc
Gateway Central
Estacion monitoreo
Existen varias limitantes en el desarrollo del proyecto, dichas limitantes se listan a continuación:
1. Políticas de IT la compañía requieren la desinstalación del computador en cámara de válvulas.
2. La compañía requiere integrar el granulómetro sin realizar modificaciones al hardware existente. 3. No es posible realizar modificaciones en el
instrumento .
4. Numero de variables reducidas en el SCADA , un número muy alto de variables o dificultades de comunicación causan demoras e interfieren en la actualización de otras variables de estudio en la planta.
Sistemas embebidos
El reciente desarrollo de los computadores embebidos como Raspberry pi ha desbloqueado un amplio potencial de computación para ser aplicado en un vasto número de áreas. Debido a las ventajas únicas del sistemas Raspberry pi esta tecnología mantiene la gran promesa de proveer soluciones y todo un mundo de desarrollos.[3]
El desarrollo de la Raspberry Pi ha traido consigo el desarrollo de otras plataformas de computadores embebidos del tamaño de una tarjeta entre las que se destacan:
a. Pcduino b. BeagleBoard c. Odroid d. Udoo e. Banana pi
Todos estos dispositivos cuentan con poderosos procesadores , multiples interfaces de comunicación y bajo consumo energético con básicamente las mismas capacidades de un pc de escritorio y haciendo especial énfasis en la importancia del software libre para este tipo de proyectos. Esto sin contar con la posibilidad de interactuar directamente con múltiples gamas de actuadores y sensores gracias a que cuenta con numerosos puertos GPIO. Si se suma a este fenómeno el papel de las redes sociales y plataformas como youtube que sirven como canal de comunicación para la socialización de aplicaciones que van desde lo convencional a novedades extraordinarias, se obtienen verdaderas comunidades globales de desarrollo que exploran las infinitas funcionalidades que solo pueden ser posible gracias al potencial ofrecido por dichas plataformas . En particular para el presente proyecto es posible desarrollar aplicaciones en java, Python y BASIC entre otros.
Pcduino en la literatura ha sido utilizado en aplicaciones de robótica móvil [4]. También ha sido utilizado en sistemas de medición automática de Oxigeno disuelto y PH, sirviendo como controlador por medio de una aplicación realizada en visual Basic cuya interfaz gráfica es similar a la obtenida en cualquier PC.[5]
III. MATERIALES Y MÉTODOS
El método a seguir para la integración del instrumento al Scada de la central se resumió tres pasos fundamentales que se enuncian a continuación:
Reconfiguración del módulo Quick Server:
Asesoría por parte de la compañía representante para Colombia del Gateway SMP para conocer el dispositivo y las limitantes concernientes al presente proyecto
Explorar otras opciones para la comunicación del módulo.
Para llevar a cabo el primer y segundo paso se definieron una serie de tareas puntuales como lo fueron:
Verificar las limitaciones del Gateway para realizar el protocolo configurado por el fabricante del instrumento.
Se realizaron dos visitas al sitio de instalación del instrumento para recopilar la información como: estado del instrumento, parámetros de configuración, ejemplo del modelo de salida de los datos del instrumento, dirección ip y parámetros de la red del SCADA, entrevista con el personal de la central para entender los requerimientos y limitantes.
Verificación de los parámetros y forma de configuración del Gateway Quickserver.
Asesoría por parte de la compañía distribuidora y representante del Gateway para Colombia.
El paso tres se inicia de manera posterior, en la medida en que se va analizando la información disponible y resultante de los pasos uno y dos.
Se presentan entonces las actividades que componen el paso tres :
Estudio las características de la tarjeta pcduino para reemplazar el computador que gestiona los resultados del instrumento.
Pruebas de desempeño y configuración de la tarjeta pcduino.
Evaluacion de las opciones que ofrece el Gateway para el acceso de datos. Este trabajo se realiza en compañía del personal encargado de la configuración y mantenimiento del Scada de la central.
IV. RESULTADOS Y ANÁLISIS
Si bien tanto el Gateway como el granulómetro cuentan con interfaces modbus TCP , no es posible integrarlos mediante conexión “ directa” por tal razón se hizo necesario conocer los principios de modbus y modbus TCP para determinar la razón que impide la comunicación del instrumento.
Modbus[6]
Modbus en un protocolo desarrollado por modicom en 1979 que se convirtió en el estándar para la transmisión de información I/O digitales / análogico entre el control industrial y los sistemas de monitoreo.
solo el cliente puede iniciar intercambios de información denominados Querys. El dispositivo esclavo responde al query con la información solicitada o realiza la acción indicada en el Query
Figura 2. Configuración maestro esclavo. fuente: FieldServer Configuration Manual. Revisión 2. Pag 8.
Si no se producen errores la respuesta del esclavo contiene los datos conforme a lo solicitado . Si se produce un error en la consulta o si el esclavo no es capaz de realizar la acción solicitada , el esclavo devolverá un mensaje de excepción como su respuesta. El campo de comprobación permite a las partes involucradas confirmar la integridad o validez del contenido del mensaje
Modbus TCP. [6]
Consiste básicamente en el protocolo modbus que posee una interfaz TCP que trabaja sobre Ethernet y permite el intercambio de datos binarios entre computadores, TCP/IP es básicamente un protocolo de transporte.
TCP: se asegura que los paquetes se reciban correctamente. IP: se asegura que los paquetes se direccionen correctamente. Gateway
Equipo direccional que permite comunicación entre varias redes.
El desarrollo del trabajo y el cumplimiento de las tareas planteadas permitió determinar que el instrumento requiere de una serie de comandos para su gestión y administración, de manera que actúa como esclavo siendo necesario una solicitud representada mediante un comando ascii dada desde el maestro conectado a su interfaz Serial RS232.
El personal de la central comunicó los limitantes del Gateway ante el protocolo configurado por el fabricante de instrumento:
El Gateway no permite personalizar una rutina de polls, Ante cada poll enviada por el maestro (Gateway smp) se espera una respuesta con los valores medidos.
El Gateway no mantiene abierto el poll, por cada poll se espera una respuesta inmediata.
Con cada set coil el significado de los registros del token cambia, es imposible indicarle al Gateway SMP cuáles son los valores que debe guardar. En la figura 3 se muestra un ejemplo del cambio de valores en el registro.
Figura 3. Ejemplo de cambio de significado y valor de registro para una medición. Fuente: autores
Esta información fue confirmada por el personal de la compañía que distribuye y soporta el Gateway SMP 16 en Colombia.
En el análisis de la aplicación y programación del módulo QuickServer se encontró : El driver soporta la configuración de escritura/control esto permitir enviar mensajes personalizados a un dispositivo remoto[7]. Adicionalmente el driver cuenta con la capacidad de realizar lecturas temporizadas por medio de la función RDBC [8] la cual posee una función de escritura periódica que permite configurar las solicitudes (polls) en intervalos de tiempo predefinidos y el número de veces que el mensaje de solicitud debe ser enviado[9]. También se encontró que las opciones de configuración de solicitud (Poll) pueden ser precargadas con valores específicos, el análisis del archivo de configuración del módulo Quick server permitió determinar que se hizo uso de esta característica( ver figura 4.) Donde se muestra la existencia de una configuración en leguaje script para Quick server o la existencia un archivo configuración adicional que contiene los parámetros y la información necesaria para la solicitud y gestión de medidas en el instrumento.
Se hizo la solicitud del archivo de configuración y procedimiento de precarga de los comandos al fabricante, dicha solicitud no fue atendida.
La negativa del fabricante a proporcionar la información requerida concerniente al Quick server cerró la posibilidad de reconfigurar y probar el módulo en el tiempo planteado en el proyecto.
Mientras se trabaja en el levantamiento de información para configuración del módulo QuickServer surge la necesidad de simular el instrumento de alguna manera, ya que el acceso al sitio de instalación es restringido y el desplazamiento a dicho sitio resulta dispendioso por el tiempo y los recursos económicos necesarios. Adicionalmente en el sitio de instalación las comunicaciones son restringidas, por lo cual adaptarse y solucionar los inconvenientes que van surgiendo durante las pruebas es sumamente complicado.
Para satisfacer la necesidad de realizar pruebas con el instrumento sin necesidad de realizar desplazamientos se desarrollo una aplicación que permitiera simular de manera precisa el comportamiento del instrumento y las cadenas de texto ASCII resultantes de sus procesos.
Para tal fin el fabricante respondió la solicitud de información mediante el suministro de la documentación concerniente a las variables de configuración para la comunicación serial y el formato de salida del instrumento cuando se realiza la comunicación mediante interfaz serial RS232 (ver tabla 2).
El personal de la central suministro archivos de texto con los resultados provistos por el instrumento. Dichos resultados fueron cargados en la aplicación y personalizados de acuerdo a las necesidades del método planteado para sortear las dificultades que se presentaban durante las pruebas.
Comunicación serial RS232
Es un protocolo muy extendido en el cual por medio de un puerto serial se envía y recibe información un bit a la vez, se utiliza normalmente para transmitir datos en formato ASCII, opera en tensiones que van de +3 a +15 para el cero lógico y de -3 a -15 para el 1 lógico , transmisión por dos hilos Tx transmitir y RX para recibir [10] esto, en su configuración más básica
Parámetros de configuración:
Velocidad de transmisión ( Baud rate) : bits por segundo. Bits de datos : número de bits en la transmisión, 7 bits si es ASCII estándar, 8 bits para ASCII extendido, el número de bits depende del protocolo seleccionado.
Bits de parada : indican el fin de comunicación de un solo paquete.
Paridad: verificación de errores en la transmisión serial. Threads(hilos de ejecución): que permiten ejecutar métodos métodos en un proceso aparte al de la interfaz gráfica. De esta forma, la interfaz puede seguir operando mientras se reciben datos o se hace una nueva conexión.
Comunicación por puertos serial y paralelo en java.
La comunicación serial en java requiere de 4 pasos básicos [11]
1. Enumerar los de CommPortIdentifiers llamando al
método estático getPortIdentifiers() y seleccione el puerto deseado.
2. Llamar al método abierto de CommPortIdentifier( ) ;
convertir el objeto resultante CommPort a un objeto o SerialPort ParallelPort según corresponda .
3. Ajustar los parámetros de comunicación (es decir , velocidad, paridad , bits de parada , y similares ) ,ya sea individualmente o todos a la vez , utilizando la conveniente rutina setSerialPortParams ( ). para un puerto serial o "modo " para un puerto paralelo.
4. Llamar a los métodos getInputStream() y
getOutputStream del objeto CommPort , y construir cualquier flujo adicional de objetos .
Esta configuración aplica en los dos casos: cuando se hace uso de API javax.comm, o cuando se hace uso de la librería RxTx, esta última más utilizada ya que desafortunadamente la implementación oficial de java no se encuentra fácilmente.
Mediante el uso de la librería RXTX y de sus APIS se programan las rutinas de que gestionan la comunicación por interfaz serial RS232 con el instrumento,
De esta manera fue posible emular correctamente las respuestas del instrumento cuando recibe el comando in que inicia el ciclo de medición.
Tabla 2. Configuración de variables. Fuente: output data format for lisst infinite and list hydro instruments. Pag 2.
gestión de medidas del instrumento. Esta aplicación tendría como base una parte del código existente y como requerimientos los parámetros anunciados a continuación:
Debe estar en capacidad de enviar el comando que inicia el ciclo o rutina de medición en intervalos de tiempo configurables en una GUI.
Guardar los resultados del instrumento en archivos de texto plano separado por comas, estos archivos serán cargados de manera automática al SCADA mediante un script realizado por ellos. De esta manera se eliminan los posibles problemas de compatibilidad con el sistema existente.
Con las directivas predefinidas se realiza la aplicación en java . tras la adaptación del código base y la escritura del código restante para cumplir con los requerimientos necesarios se realizaron las primeras pruebas cuyos resultados se resumen a continuación:
La comunicación se establece de manera correcta y Los comandos de medición se envían con la periodicidad estipulada sin embargo la aplicación no puede establecer si se pierde la comunicación con el instrumento quedándose en un bucle de espera infinito.
Dado que en cualquier momento o se pueden presentar errores en la medición no es posible trabajar con la posición de los campos en el stream ASCII.
De los resultados enunciados con anterioridad surgen nuevos requerimientos que deben ser solventados para que el proceso de adquisición de medidas sea estable y fiable:
a. Determinar e indicar si se ha perdido la comunicación entre la aplicación y el instrumento.
b. Establecer una señal que inicie el proceso de medición solo cuando procesos de medición anteriores hayan finalizado.
c. Determinar de manera dinámica e indicar la causa de errores en el procedimiento de medida mediante vigilancia de ciertos campos en la cadena de de texto ASCII .
d. Implementar temporizadores de seguridad para terminar las rutinas de escucha y adquisición.
e. Iniciar temporización y medición de manera automática tras presentarse un error.
Tabla 3 . códigos de error y su significado. . Fuente: output data format for lisst infinite and list hydro instruments. Pag 2.- adaptada y modificada por los autores.
-1 La cámara de dilución no se llenó.
-2 Error en el sensor de la cámara de dilución. El sensor puede requerir limpieza ..
-3 Nivel muy bajo en el tanque de agua limpia
-4 a -9 Reservado para uso futuro
-10 Alarma de baja presión de entrada de muestra
-11 Presión de entrada de muestra muy baja
-12 Alarma de alta presión de entrada de muestra
-13 Presión de entrada de muestra muy alta
-1024 Se ha perdido comunicación con el instrumento (adicionada en el proyecto).
Tras multiples pruebas se encontró la combinación de parámetros del stream ASCII que permite determinar de manera acertada el momento en el cual el instrumento termina la recepción de datos y el tratamiento de las distintas situaciones de error que se presentan en la comunicación dichas situaciones de erro o errores se muestra a continuación en la tabla 3:
La figura 5 resume el algoritmo utilizado en la aplicación para la gestión de las mediciones. En la aplicación se hace uso de la Clase CommPort de java , asi como de de dos temporizadores del clase javax.swing.Timer que corren en paralelo, uno para indicar la necesidad de desempeñar una nueva medición y otro de seguridad que indique cuando se ha superado el tiempo de espera de manera que se pueda generar una señal de alarma o error ante una posible pérdida de comunicación con el instrumento.
Figura 5. Diagrama de flujo de la aplicación desarrollada..Fuente: autores.
Inicio
Carga parámetros de
configuracin
datos Garnulómetro
Reset ocupado Organizar datos
Archivos texto plano Inicio de
temporizadores y conexión
Temporización de seguridad
Temporización de configuración
Datos error Tiempo cumplido?
Tiempo cumplido?
Inicia proceso medición, Set a ocupado
Proceso terminado? Envio y
recepción por interfaz serial
Datos de medición o
error Escritura de datos
Establecer conexión Comunicación
establecida? Si
No No
Si No
Ocupado?
No Si
Si
Fin
Tras realizar diferentes pruebas en S.O. Windows® se procedió a realizar la elección del sistema embebido Linux en el cual se implementara la aplicación:
En el mercado se ofrecen varios modelos de distintos fabricantes tales como:
Pcduino, odroid y la popular raspberry pi. A continuación en la tabla 4 se listan las características generales de cada uno de los modelos observados.
de doble núcleo de PCduino , la memoria es similar en las tres tarjetas, con la salvedad de que solo la Raspberry incorpora RAM DDR2.
También se observa que solo la tarjeta PCduino incorpora memoria flash, factor que puede incidir en la velocidad del dispositivo al tener mayor velocidad de acceso o escritura a los datos mientras que en las otras tarjetas la velocidad de acceso a los datos de la RAM dependerá en gran medida del modelo o clase de la micro SD insertada en el slot.
4. Tabla 4. Características de los modelos de sistemas embebidos.
Nombre
S.O Procesador Ram Flash
Odroid c1 Ubuntu 14.04
1.5 Ghz Quad core
1GB DDR3
microSD externa Raspberry
pi2 b
Raspbian debian
900 Mhz quad core
1 GB DDR2
Micro SD externa Pcduino 3
nano
Ubuntu 12.04 14.04
1 GHz dual core
1GB DDR3
4 GB
flash interna Se realizaron pruebas en las tres plataformas instalándose en cada una de ellas el JDK Oracle, se instalaron las librerías open source RXTX en las ubicaciones predefinidas y se procedió a probar la aplicación en cada una de las tarjetas. Adicionalmente se configuraron servidores X11vnc en cada una de las tarjetas para el acceso remoto mediante cualquier VNC Viewer y de esta manera eliminar la necesidad de trabajar con un monitor conectado a la tarjeta.
También se realizó la configuración de la suite open source Samba para compartir archivos. De las distintas pruebas los resultados obtenidos fueron:
Java: Todas las tarjetas permiten la ejecución de la aplicación en java.
Interfaz RS232: Las tarjetas reconocen el convertidor RS232/USB sin la necesidad de instalar drivers adicionales.
Acceso remoto : El acceso remoto mediante X11vnc fue configurado en las tres tarjetas.
PCDUINO el acceso a la tarjeta fue muy sencillo puesto que tiene el servidor instalado y configurado para iniciarse por defecto, solo requiere la configuración de password.
RASPBERRY fue necesario instalar el servidor X11vnc y configurarlo, labor que se llevó a cabo fácilmente gracias a la gran cantidad de información disponible en la red.
ODROID requirió la instalación del servidor X11vnc pero su configuración y puesta en marcha fue complicada, se cuenta con poca información al respecto en la red. Tras varias pruebas no se logro configurar servidor para que se inicie de manera automática.
Archivos compartidos: instalación de suite Samba : PCDUINO fue fácilmente configurada, es posible acceder a los archivos compartidos dentro y fuera de la tarjeta.
RASPBERRY fue fácilmente configurada. es posible acceder a los archivos compartidos dentro y fuera de la tarjeta
ODROID fue configurada pero no permite el acceso a los archivos compartidos solicita credenciales continuamente. la información disponible se queda corta para la resolución de problemas.
Debido a las dificultades presentadas durante la configuración de los servicios básicos la tarjeta Odroid C1 fue descartada para la implementación del presente proyecto. La facilidad de configuración del los servicios básicos y la capacidad de almacenamiento interno fueron características determinantes en la elección de la tarjeta PCduino como plataforma básica para la culminación del proyecto que siguió la configuración mostrada en la figura 6. Figura 6. Arquitectura básica de la aplicación. Fuente: autores.
El desarrollo del modulo requirió la adición de otros componentes de manera que su arquitectura final se muestra en la figura 7.
Figura 7. Arquitectura módulo de comunicaciones. Fuente: autores.
conectada directamente a la interfaz serial RS232 del instrumento, para poder realizar comunicación serial con el instrumento se hizo necesaria la instalación de convertidores RS232/USB
El uso de un relevo conectado a una salida digital de PLC obedece a la necesidad de cortar el suministro de energía a la tarjeta para reiniciarla en caso de ser requerido.
La aplicación fue correctamente instalada en el la plataforma Pcduino. La realización múltiples pruebas para forzar errores, perdidas de comunicación estabilidad ante distintos la recepción de datos distintos a los especificados, permitió corregir los bugs e inconsistencias presentadas, también confirmó la estabilidad de la plataforma seleccionada.
Figura 7. GUI de la aplicación de gestión y control. Fuente: autores.
Acceso a los datos:
Para dar acceso a los datos mediante una ubicación de red compartida se probaron dos opciones:
a. Compartir una carpeta en un pc con sistema operativo Windows : requiere ingresar el embebido Linux al dominio Windows; en cada una de las pruebas realizadas cuando se modifican los archivos generados requiere credenciales para la autenticación y permisos para modificar la carpeta, haciendo el proceso lento, la solicitud continua de credenciales demanda la atención y acción por parte del operador lo cual hace el proceso completamente ineficiente. b. Compartir la carpeta desde el embebido: para este proceso se realiza la configuración de Samba, que provee servicios de archivos e impresión a todo tipo de clientes SMB / CIFS de Microsoft, de esta manera se permitió el acceso a la capeta con los archivos generados por la aplicación java. A pesar de contar con las credenciales y proporcionarlas de manera automática el proceso de autenticación del cliente tomaba demasiado tiempo, como se evidencia en la tabla 5.
Tabla 5. Tiempos de carga de archivos de texto . Fuente: Autores.
Prueba N° Tiempo de subida (s)
1 46
2 49
3 56
4 50
Este tiempo se considera inaceptable ya que la lecturas y polls se hace de manera secuencial en el Gateway, la demora en el proceso detiene los querys a todos los demás dispositivos de la red.
Por tal razón se elimina el requisito de autenticación, y se aumentan los permisos de dicha carpeta. De esta manera se elimina el Delay en la carga de archivos y la actualización del SCADA con los datos más recientes se hace transparente e imperceptible para el sistema.( ver tabla 6.)
Tabla 6. Tiempos de carga de archivos de texto . Fuente: Autores.
Prueba N° Tiempo de subida (s)
1 <1
2 <1
3 <1
4 <1
Con la diminución de los tiempos de carga se realiza la integración de las medidas del instrumento a sistema SCADA de la hidroeléctrica.
Realizando las mediciones pertinentes con le multímetro se determino el consumo energético del módulo en desarrollado en 22 W, siendo esperado un consumo de 17 W, La diferencia presentada se presume causada por factores de disipación de los reguladores de tensión para bajar de 48 V a la tensión requerida. Se presenta una disminución considerable en el consumo de energía al compararse la medida obtenida con los 255 W que consume un computador de escritorio del mismo modelo del utilizado en el proyecto
Por último se realiza instalación y configuración del servidor b11vnc en el sistema embebido para permitir las tareas de mantenimiento y actualización del sistema por medio de la interfaz gráfica.
V. CONCLUSIONES
A pesar de que en el mercado se ofrecen múltiples plataformas de sistemas embebidos, todas ellas con sistemas operativos Linux, no todas cuentan con suficiente información y facilidad para la personalización y adecuación a las necesidades particulares de los proyectos, por tal razón es recomendable realizar pruebas en múltiples plataformas para seleccionar la más adecuada y de fácil configuración así, como tener en cuenta la disponibilidad de información en la red.
Mediante el uso de sistemas embebidos Linux , PCduino y Raspberry es posible resolver problemas en el ámbito industrial, el presente proyecto permitió mostrar la flexibilidad de los sistemas empleados. La resolución creativa de problemas cuando los métodos tradicionales no funcionan o se dispone de poca información por parte de los fabricantes de distintos sistemas, hizo posible proveer los resultados del Granulómetro láser al SCADA de la Central hidroeléctrica mediante comunicación Ethernet. El uso de sistemas embebidos de reducido tamaño y amplias capacidades de computación abre las posibilidades no solo a desarrollos académicos sino, también al desarrollo de aplicaciones industriales. La flexibilidad de estos sistemas permite solucionar problemas que surgen del uso de tecnologías de poca flexibilidad brindándoles de esta manera flexibilidad y compatibilidad ilimitadas siempre y cuando los problemas sean abordados desde ópticas distintas a las convencionales .
En la contratación de un proyecto ó adquisición de instrumentación es usual encontrar la solicitud expresa de interfaces modbus tcp para permitir la conectividad de los equipos. Si bien es cierto la mayoría de equipos a nivel industrial poseen estas interfaces se hace necesario destacar que dichos protocolos a pesar de ser ampliamente utilizados y aceptados permiten a los fabricantes implementar, desarrollar o personalizar sus propios protocolos basados en Modbus TCP. De esta manera se hace claro que no basta con cumplir el requisito de implementar una interfaz compatible con dicho protocolo si los fabricantes implementan variantes o rutinas propias de
dichos protocolos. Es necesario conocer las limitantes o requerimientos de la instrumentación existente aún cuando se posean interfaces que implementen los mismos protocolos.
REFERENCIAS
[1] Abgottspon et al, Monitoring Suspended Sediment and Turbine Efficiency. Disponible en internet [24-04-2016].
http://www.hydroworld.com/articles/print/volume-22/issue- 4/articles/operations-maintenance/monitoring-suspended-sediment-and-turbine-efficiency.html
[2] Sequoia Scientific inc. LISST‐Infinite and LISST‐Hydro Modbus Reference and Register Map. Application note. 11/20/2013. [3] Sarthak et al. Raspberry pi based interactive home automation system through email. 2014 international conference on Reliability. Optimization and information technology ICROIT 2014.India, Feb 6-8 de 2014. Pag 2.
[4] Disponible en internet [29-04-2016]
[5] Wiranto et al. Design of Online Data Measurement and Automatic Sampling System for Continuous Water Quality Monitoring. International Conference on Mechatronics and Automation. August 2 - 5, Beijing, China.. Proceedings of 2015 IEEE.
[6]INTRODUCTION TO MODBUS TCP/IP. Technical Reference – Modbus TCP/IP . ACROMAG INCORPORATED. Pag 4-5. [7] FieldServer Protocol Driver Sheet ASCII Driver (General Purpose). Version: 1.03 / Rev. 0. Pág 2
[8] FieldServer Configuration Manual. Revision 2.Pág.18.
[9] Driver Manual(Supplement to the FieldServer Instruction Manual). FS-8700-115 ASCII Driver (General Purpose), Driver version 1.03. Revision 2. Pág. 8 & 10
[10] Forero S. Nestor . Normas de Comunicación en Serie: RS-232, RS-422 y RS-485.Universidad Libre de Colombia Revista ingenio Libre. Junio de 2012. Pág 89.
[11] Darwin Ian. Java Cook book. 3rd edition. Ed. O’reilly . ISBN 978-1-449-33704-9. 2014 Pag. 354.
. .
