Sistema de Control y Supervisión Industrial Multiplataforma Germán Mauricio Coral gcoral@unicauca.edu.co Oscar Amaury Rojas orojas@unicauca.edu.co Fernando A. Campos fcampos@unicauca.edu.co Grupo en Automática Industrial Universidad del Cauca Resumen Debido a la incursión de sistemas operativos de licencia libre y a su aceptación en los diferentes sectores industriales, surge la necesidad de integrar todos los sistemas de supervisión y control a esta nueva tendencia de una forma eficiente y totalmente interoperable. Por esta razón se desarrolló un estudio enfocado a crear una herramienta que permitiera controlar y supervisar dichos procesos en cualquier tipo de sistema operativo o plataforma, validándolo especialmente en sistemas Linux, al utilizarse conceptos de comunicaciones industriales y sistemas telemáticos, como son OPC (OLE for Process Control) y Servicios Web. Al utilizar estas herramientas se implementó un sistema de supervisión y control de procesos industriales con capacidad de ser ejecutado en cualquier tipo de plataforma y sistema operativo, con funciones de almacenamiento y acceso remoto para los usuarios del sistema por medio de Internet y dispositivos móviles, reduciendo así sustancialmente los costos de implementación y operación al utilizar herramientas de software libre. Palabras claves. Java for Process Control, Linux, Multiplataforma, OPC XML-DA, SCADA, Servicios Web. Abstract After the wide expansion of the open source operating systems and their acceptation in the industrial field, it emerges the necessity of integrate all the supervision and control systems into that new tendency, increasing their interoperabily and efficiency. Because of that it was done a study focused in the development of a tool that would allow controling and supervising industrial task in any kind of operation system or platform, especially, testing it in a Linux system by means of industrial networks, telematic applications, OPC (Ole for process control) and Web services. This paper shows that it is possible supervise and control an industrial tasks system without matters of the platforms or operating system, with storage services, remote access for the users of the system using internet and mobile devices, reducing substantially the implementation and operation costs by means of the open source software. Keywords. Java for Process Control, Linux, OPC XML-DA, SCADA, Web Services. 1. Introducción La necesidad de interoperabilidad entre los equipos, no solo en el ambiente de las redes telemáticas sino también en las soluciones de protocolos de redes industriales, ha obligado a las diferentes empresas desarrolladoras de software a crear nuevos productos que permitan la comunicación entre diferentes sistemas que fueron diseñados para ser totalmente incompatibles. Por ejemplo, en el ambiente industrial ha sido muy agresiva la batalla entre protocolos de redes de bus de campo (redes industriales especializadas para comunicar sensores, actuadores, controladores y otros dispositivos industriales); batalla que obligaba al usuario a ser fiel a una marca de dispositivos para toda su línea de producción por su incompatibilidad con los demás protocolos de comunicación. Sin embargo, en los últimos años se ha impulsado una unificación masiva de los sistemas industriales por parte de los principales desarrolladores de software del sector. La Fundación OPC [1] con su conjunto de especificaciones es una de las principales organizaciones preocupada por reducir estos problemas de compatibilidad. Estas especificaciones basan las soluciones de incompatibilidad en el manejo del modelo de objetos Windows COM/DCOM (Component Object Model / Distributed COM), el cual permite la adquisición de datos de los dispositivos y su
utilización en cualquier máquina Windows local o distribuida. A pesar de estos esfuerzos, aún existe un gran problema de compatibilidad para sistemas operativos diferentes a Windows, como Macintosh, UNIX, Solaris, y Linux, los cuales son grandes opciones con múltiples ventajas. Ante estas diferencias se presenta la necesidad de crear un sistema de comunicación industrial que sea ampliamente compatible con las demás plataformas y que además, proporcione las mismas o mejores respuestas comparativas con los sistemas actualmente existentes. Este artículo describe las diferentes tecnologías que se pueden utilizar para desarrollar una herramienta que permita una comunicación industrial entre diversas plataformas. También muestra el desarrollo de la herramienta utilizando la mejor opción de comunicación dentro del entorno de estudio particular presentando los resultados obtenidos y sus ventajas en términos de compatibilidad y rendimiento. 2. Conocimiento existente En el mercado actual los lenguajes de programación como Visual Basic.NET y Delphi, proporcionan un amplio soporte para el manejo de protocolos de redes industriales, debido a que la mayoría de los dispositivos disponen de controladores para entornos Windows y comunicaciones COM/DCOM. Sin embargo, cuando se quiere utilizar una plataforma diferente a Windows, los mejores lenguajes de desarrollo son C++ y JAVA; el primero con una complejidad un poco mayor a nivel de programación, y el segundo (basado en el primero) con gran portabilidad e interoperabilidad multiplataforma y gran variedad de herramientas para comunicaciones, aunque actualmente es poco utilizado en la industria por sus bajos tiempos de respuesta y por no disponer de la capacidad de acceder a memoria directamente, hecho que limita el acceso a información de dispositivos externos sin conocer su protocolo de comunicación. Por lo tanto, existen dos formas para acceder a las redes industriales y a los dispositivos de campo por medio de estos dos lenguajes: Puentes COM/DCOM y OPC-DA OPC y XML 2.1. Puentes COM/DCOM y OPC-DA OPC-DA (OPC Acceso a Datos), fue la primera especificación creada por la fundación OPC [1] para transferir datos en tiempo real desde dispositivos de control a HMIs (Interfaces Hombre- Máquina), la cual basa su comunicación en el modelo COM/DCOM. De esta forma los desarrolladores utilizan librerías nativas para comunicar aplicaciones.net o C++ con aplicaciones Java y los dos modelos de componentes COM/DCOM y RMI (Invocación de métodos remotos). 2.2. OPC y XML La Fundación OPC desarrolló un estándar XML (extensible Marked Lenguage) para las capacidades de interoperabilidad de los sistemas SCADA (Sistemas de Supervisión, Control y Adquisición de Datos) que se ejecutan sobre sistemas distribuidos COM/DCOM. PLCs (Controladores Lógicos Programables), DCSs (Sistemas de Control Distribuido), HMIs y varios programas usan los estándares OPC-COM para intercambiar datos en tiempo real entre dispositivos de campo, sistemas de control y otras aplicaciones de una manera estándar, proporcionando compatibilidad multi-vendedor e interoperabilidad basada en Servicios Web. Esta tecnología brinda fácil integración con las aplicaciones existentes OPC-COM a través de Internet, ya que éstas trabajan muy bien en el entorno típico de una LAN (Red de Área Local). Sin embargo, cuando se usa DCOM sobre Internet, se tienen muchos inconvenientes y limitaciones relacionados con la seguridad y el uso de puertos TCP/IP dinámicamente asignados (típicamente no permitido a través de firewalls corporativos). Otra gran ventaja es que XML es una especificación del W3C diseñada para facilitar su transporte con protocolos de Internet. Este es frecuentemente transportado vía HTTP (Protocolo de transferencia de Hipertexto) simplemente como páginas Web HTML (Lenguaje marcado de hipertexto) ordinarias, pero también se transporta fácilmente por medio de otros protocolos, como FTP (Protocolo de transferencia de archivos) y SMTP (Protocolo de transporte de mensajes simples). De las dos formas presentadas anteriormente, los puentes COM/DCOM han sido la opción más antigua y por lo tanto la más utilizada por las empresas para gestionar sus productos en sistemas operativos diferentes a Windows, especialmente en sistemas Linux y UNIX o para hacer sus desarrollos en lenguaje JAVA. La organización NetModule [2] ha sido los primera en hacer algún tipo de desarrollo industrial con miras
a utilizar herramientas totalmente interoperables bajo el concepto de JPC (Java for Process Control), herramienta que en la actualidad se encuentra disponible en el mercado. Posteriormente, otras empresas como Softing y Advosol [3] en Europa implementaron otras herramientas exclusivas para algunas versiones de sistemas Linux basadas en lenguaje C++. La segunda opción [4] es mucho más reciente y ha incursionado vertiginosamente permitiendo el desarrollo de una gran variedad de productos.net en entornos Windows, para ser compatible con cualquier otro sistema, pero no se tiene ninguna referencia de desarrollos totalmente interoperables en diferentes plataformas sin necesidad de crear versiones nuevas o con modificaciones estructurales que afecten el rendimiento de los dispositivos de campo. En nuestro caso particular, los Servicios Web son la tecnología que más se aproxima a lo requerido: Interoperabilidad multiplataforma para poder ejecutarlo en cualquier sistema operativo; ajustándose perfectamente a una de las especificaciones OPC: OPC XML-DA, que está dirigida a los procesos industriales y a su integración con las funcionalidades de los sistemas SCADA y los protocolos de redes industriales. 3. Metodología Para un desarrollo adecuado del proyecto y considerando que se basa fundamentalmente en el desarrollo de soluciones software se debe contar con una metodología que favorezca la construcción del sistema con características óptimas de calidad. Dentro de las diferentes opciones, se ha considerado el Modelo de Construcción de Soluciones (MCS), desarrollado dentro del grupo de ambientes de Desarrollo de la Facultad de Ingeniería Electrónica y Telecomunicaciones (FIET) de la Universidad del Cauca, y el cual se basa en el RUP (Rational Unified Process), proceso que cuenta con fases de planeación, descripción UML básica y detallada y sistemas de validación del sistema, permitiendo generar prototipos básicos que van evolucionando a medida que se desarrolla el proyecto. 4. Herramientas Utilizadas Para lograr los objetivos del proyecto se ha realizado una integración de la arquitectura propuesta por la Fundación OPC denominada Arquitectura Unificada y las herramientas brindadas por Java Sun Microsystems con sus diferentes soluciones para el manejo de: Servicios Web (J2EE), eventos y procesos normales en equipos comunes (J2SE), y aplicaciones para dispositivos móviles (J2ME). Debido a que la especificación viene orientada hacia herramientas de desarrollo de Microsoft y especialmente a Visual Studio.NET, no se han seguido estrictamente las especificaciones OPC sugeridas para entornos industriales, pero se lleva a cabo la mejor aproximación posible con el objetivo de no perder la estandarización deseada. 4.1. OPC XML-DA (XML acceso a datos) XML-DA es la última especificación que la fundación OPC generó para el servicio de la industria y está basada en algunas especificaciones anteriores, como OPC-DA. La razón es permitir operabilidad entre diferentes lenguajes y sistemas operativos al utilizar XML, un lenguaje que permite el intercambio de información estructurada entre aplicaciones. Los principales objetivos de OPC XML-DA son: Soportar el acceso a OPC DA versión 2.0 y 3.0 Manejar HTTP y SOAP. Brindar soporte para Servicios Web síncronos y asíncronos basados en suscripción. 4.1.1. Métodos asíncronos. Los servicios soportados por la especificación XML-DA son: Buscar, Obtener Propiedades, Obtener Estado, Leer y Escribir. Buscar, busca jerárquicamente los nombres de las variables del proceso (TAGs) que se encuentran en el servidor. Obtener Propiedades, retorna información asociada a una o mas TAGs. Obtener Estado, retorna información acerca del servidor, tal como: versión, modo actual, estado general, entre otros. Leer, devuelve el valor, calidad y tiempo de consulta de una TAG seleccionada con el método Buscar o dando un nombre específico y Write permite escribir en el servidor uno o más valores de las TAGs. 4.2. OPC AE El sistema de control y supervisión debe disponer de un módulo de gestión de alarmas del proceso, el cual debe generar un reporte a usuarios así estos se encuentren remotos, implementando de esta manera la generación de mensajes de novedades de alarmas y situaciones
críticas usando servicios de comunicaciones móviles. Para llevar a cabo estas funcionalidades se utiliza la especificación OPC AE (Alarmas y Eventos) propuesta por la Fundación OPC, haciendo uso de la versión estándar de Java J2SE, que es empleada especialmente para el manejo de eventos. Como se ha detallado anteriormente, todas las especificaciones de la Fundación OPC van enfocadas a desarrollos en entornos Windows y comunicaciones COM. Por esta razón, el desarrollo de la funcionalidad de un servidor de alarmas y eventos bajo un paradigma multiplataforma solo puede implementarse tomando los conceptos básicos y más relevantes de la especificación integrándolos a la Arquitectura Unificada de la Fundación OPC. En general, para implementar la especificación se tiene en cuenta un servidor de alarmas y eventos que posee la capacidad y los mecanismos para notificar a los clientes OPC cuando ocurre un determinado evento o condición de alarma, e igualmente debe proporcionar a los clientes los mecanismos necesarios para determinar los eventos y condiciones soportadas en el mismo servidor y obtener su estado. Una alarma es una condición anormal y por consiguiente es un caso especial de una condición [5]. Esta condición está directamente relacionada con algún objeto que proporcione información a un cliente OPC, por ejemplo una variable o TAG. 4.3. AXIS El kit de herramientas de Axis de Apache es una implementación de código abierto de SOAP (Protocolo para acceso de objetos Simples), que facilita el trabajo a los programadores al momento de desarrollar una herramienta software basada en Servicios Web y que tenga por lo tanto un documento WSDL (Web Service Description Language). Al utilizar esta herramienta y manejando un WSDL estándar se puede implementar un servicio Web de forma automática, casi instantánea y sin costo adicional. AXIS utiliza la API JAX-RPC (API de Java para llamada a procedimiento remoto basada en XML) [6] que a su vez utiliza un protocolo de mensajería XML como SOAP, para transmitir una llamada a procedimiento remoto a través de una red. 4.4. JDBC A pesar de que la Fundación OPC ha intentado crear una arquitectura abierta, ha basado todos sus desarrollos en tecnologías Windows, por lo tanto, al tratar de migrar a otros entornos como UNIX con Java, se deben hacer algunos cambios. En este caso, es imprescindible el manejo de bases de datos con conectores de diferentes tipos a los manejados por OPC-HDA, los cuales se basan en OLE-DB, un controlador orientado a objetos de tipo COM/DCOM. Normalmente cuando se quiere hacer una conexión a un motor de Bases de Datos se utiliza el API JDBC. JDBC es un estándar para acceder a cualquier motor de base de datos disponible en el mercado, ya sea de carácter libre o no. Esta API está formada por un conjunto de clases e interfaces desarrolladas en Java para ejecutar sentencias SQL, permitiendo obtener los datos de una forma fácil y segura en arquitecturas Cliente/Servidor a través de Internet o Intranet [7]. 4.5. WAP (Protocolo de acceso inalámbrico) Es un estándar para la presentación y envío de información y la utilización de servicios adicionales de telefonía sobre dispositivos móviles. A diferencia de las tecnologías de Internet para PCs, WAP está pensado para dispositivos que tienen algunas limitaciones técnicas inherentes a la tecnología actual, tales como menor capacidad de procesamiento y memoria, restricciones de suministro de potencia, despliegues pequeños, mecanismos de entrada diferentes, entre otras. Los componentes involucrados en las aplicaciones WAP son muy similares a los del World Wide Web (WWW), excepto por la incorporación de una pasarela utilizada para servir de intermediario entre el mundo inalámbrico e Internet. 4.6. SMS (Servicio de mensajería corta) El servicio de mensajería corta es un servicio inalámbrico aceptado globalmente que habilita la transmisión de mensajes alfanuméricos entre suscriptores móviles y sistemas externos (E-mail). 5. Resultados A continuación se presenta el desempeño e interoperabilidad de la herramienta desarrollada, en diversas plataformas, entre las cuales se incluyen Windows XP y 2000, Linux SUSE 9.0 y Mandrake 10.1, empleando como motor de Base de Datos Firebird y Emuladores de dispositivos móviles Ericsson.
Se utilizaron tres servidores OPC XML-DA: El primero, ubicado en una red LAN con un servidor de RsLinx de Rockwell Software, el segundo ubicado en USA publicado por Advosol [8], y el último ubicado en Suiza publicado por Technosoftware [9]. 5.1. Arquitectura de referencia En la figura 1 se puede apreciar que el servidor de Datos XML-DA tiene un servidor Windows IIS basado en.net, el cual utiliza un puente para comunicarse con objetos COM/DCOM y así poder obtener y modificar los datos que se encuentran en el dispositivo de campo. SERVIDOR OPC-DA XML-DA.NET IIS PUENTE DISPOSITIVO DE CAMPO INTERNET SOAP/HTTP CLIENTE WEB OPC XML-DA SERVIDOR OPC A&E BD CLIENTE MÓVIL OPC A&E Figura 1. Arquitectura de referencia para el servicio Del lado del cliente se encuentran dos tipos de usuarios: un dispositivo móvil que puede acceder a un servidor de Alarmas y Eventos OPC a través de Internet, por medio de WAP; y un cliente OPC DA- XML que accede a los datos a través de Internet, por medio de SOAP y HTTP, pero a su vez es un servidor de Alarmas y Eventos OPC, con acceso a datos históricos mediante JDBC. 5.2. Búsqueda de dispositivos En una red industrial, cada dispositivo debe estar en la capacidad de brindar información al sistema SCADA, convirtiéndose dentro de nuestra arquitectura en un servidor de datos OPC XML- DA, y por tanto tener asignada una dirección en Internet o en la red de área local (LAN). De esta forma, se hace indispensable el establecer un mecanismo eficiente para determinar los dispositivos que se encuentran activos en la red. A pesar de que la definición dada por la especificación OPC XML-DA para implementar este servicio se basa en repositorios UDDI (Integración, Descubrimiento y Descripción Universal), los cuales actúan como un directorio en Internet, publicando el servicio, su ubicación (pagina Web) y cómo implementarlo (WSDL); se realizó la búsqueda de una forma semi-estática, en la cual los servidores de datos se encuentran registrados en una base de datos con sus respectivas direcciones, y utilizando el método GetStatus (Obtener Estado) se determina si el dispositivo se encuentra activo o no. Los resultados de este servicio a pesar de ser validos y utilizables, son poco eficientes debido a que, teniendo en cuenta el poco volumen de tráfico que se genera, la velocidad de respuesta varía entre 1 y 15 segundos, dependiendo del tráfico de la red y se presentan en algunos casos cancelaciones del servicio debido a los altos tiempos de espera. La misma implementación del servicio se ejecutó con éxito en todas las plataformas mencionadas. Como se comentó anteriormente se presentaron tiempos de respuesta variables dependiendo de la plataforma a validar, siendo Linux Mandrake 10.1 el sistema que presentó la mayor limitación en cuanto al tiempo de respuesta. 5.3. Acceso a Datos Se utilizan los servidores anteriormente mencionados, realizando las transacciones Read y Write. Para comprobar el correcto funcionamiento se ha utilizado el software de programación de PLC s Rslogix500 de Rockwell Software como servidor OPC DA con un puente XML-DA para acceder a éste. Utilizando el servidor de prueba de Technosoftware con la herramienta Lixmo, se puede observar en la Figura 2, que en la búsqueda de elementos o TAGs, efectivamente el sistema desarrollado despliega los grupos y variables disponibles en el dispositivo al cual nos conectamos. Además, se validó en todas las plataformas propuestas la lectura y escritura de datos en los diferentes servidores, con muy buena velocidad de respuesta y con capacidad de actualizar múltiples datos simultáneamente, siendo mucho más eficaz que el servicio anteriormente presentado.
modifica para enviarse al RSLinx con el formato: [NombreDeProyecto]N7:6. De igual forma para utilizar la transacción Read, se recurrió a la misma función de cambio de formato para adoptar la notación del RSLinx mencionada anteriormente. Estos procedimientos son mostrados en la Figura 3, en la cual se puede observar el resultado de una transacción Read en la memoria de variables de datos existente en un PLC de Allen Bradley, al cual se ha configurado un tópico OPC en el servidor OPC DA de su software de comunicaciones RSLinx de Rockwell Software. Figura 2. Búsqueda de datos en servidor de prueba de Technosoftware publicado en Internet. En la Figura 3, se puede apreciar la respuesta al método GetProperties (Obtener Propiedades) del servidor mencionado anteriormente. Figura 4. Búsqueda y lectura de datos en servidor Local RSLinx. 5.4. Almacenamiento de Datos Figura 3. Obtención de propiedades de un TAG en el servidor de Technosoftware publicado en Internet. Cuando se realizaron las pruebas de interoperabilidad de estos servicios en el dispositivo local que funcionaba con el software de comunicaciones RSLinx de Rockwell Software se obtuvo un error de lectura. Este se refería a que no se encontraban elementos dentro del grupo de variables, debido a que el servidor OPC DA de RSLinx implementa de una forma propietaria y por tanto no estándar la manera de nombrar los grupos y TAGs del sistema, creando una incompatibilidad con las demás herramientas que manejan el estándar XML-DA, para lo cual fue necesaria la implementación de una función de cambio de formato en las TAGs a transmitir, solucionando el problema inicial. Por ejemplo si se quiere llegar al grupo de TAGs del registro de enteros, usualmente la notación para el nombre de la TAG sería: NombreDeProyecto.Online.N7.N7:6, el cual se Una vez obtenidos los datos de la forma mostrada en la sección anterior, el almacenamiento en la base de datos fue sencillo y efectivo. Se encontraron algunos problemas de compatibilidad al momento de publicar la base de datos en las plataformas Linux y ser accedidas desde Windows utilizando RMI, pero se pudo solucionar utilizando Servicios Web como medio de acceso y publicación. 5.5. Alarmas Para validar esta función del sistema, se tomaron cuatro variables de proceso y se definieron condiciones de alarma para cada una de ellas, de manera que cuando éstas se activen, generen el reporte de alarmas y desplieguen la información a los usuarios Web y Móvil. En la Figura 5, se observa que el cliente Web presenta el reporte de alarmas y eventos, relacionando la información correspondiente a la fecha y hora de activación y su estado actual (activa o inactiva).
6. Conclusiones Con el sistema desarrollado, se pueden generar todas las aplicaciones actualmente requeridas por un sistema de control y supervisión utilizando una plataforma Java y un servidor XML-DA desarrollado en cualquier lenguaje. Figura 5. Gestión de alarmas en cliente Web. El sistema implementa el manejo de las alarmas y reporte de eventos críticos en los dispositivos móviles y el despliegue de la información a través de los emuladores WAP como se observa en las Figuras 6 y 7. A través de la implementación de un Cliente Web de la especificación OPC XML-DA en J2EE, se puede tener acceso ilimitado a los datos de un dispositivo de campo y ejecutar la aplicación en cualquier plataforma, ya sea Linux, UNIX, Windows, o un dispositivo móvil. Utilizando la especificación OPC XML-DA se pueden integrar todos los servicios necesarios para el control y supervisión de dispositivos de campo en un proceso industrial, y usar los mismos desde cualquier sitio remoto con acceso a Internet, o dentro de una LAN. Se pueden reducir ostensiblemente los costos de desarrollo de una herramienta de control y supervisión al utilizar sistemas operativos de carácter libre y software de desarrollo de libre distribución, sin perjudicar su calidad y rendimiento. Figura 6. Acceso remoto por medio de la Aplicación WAP Para un sistema de control y supervisión en un proceso industrial, los tiempos de respuesta de la herramienta desarrollada en Java son muy buenos y no generan ningún retardo en el desempeño del mismo. Se puede decir que cumplen con la definición de tiempo real bajo condiciones de red específicas y limitadas. La adquisición de los datos por medio de la aplicación XML-DA puede generar errores y terminaciones de la conexión dependiendo del tráfico en la red. Algunos procesos, especialmente los relacionados con servicios que manejan poca información como ver el estado de un servidor, utilizan muchos recursos para una transacción simple y no son óptimos para un sistema de este tipo, debido a que pueden generar errores y aumentar el tráfico en la red. Figura 7. Activación de alarmas en cliente Móvil. Para desarrollar un servidor OPC XML-DA sobre lenguaje Java se necesita más que la simple especificación. Debe desarrollarse algún medio o utilizar uno ya desarrollado que
permita obtener los datos directamente desde la memoria o que haga una comunicación con los objetos COM. 2004. Sus líneas de interés son: Comunicaciones Industriales, Sistemas de información y Servicios Web. 7. Bibliografía [1] http://www.opcfoundation.org - The OPC Foundation. [2] http://www.netmodule.com/e/index.asp - Net Module [3] http://www.softing.com/en/index.htm - Softing AG. [4] OPC Fundation, OPC XML-DA Specification, 2003. [5] OPC Fundation, OPC Alarm and Event Specification, 2002 [6] Borland SW Corporation. Guía del desarrollador de servicios Web. EEUU. 2004 [7] Caicedo, O., López, D. Electiva Aplicaciones Web, Universidad del Cauca. 2004. [8]http://172.16.140.41/PLC1/OpcXmlDaServer.as mx - Servidor XML-DA de prueba de Advosol. [9]http://opcxml.dnsalias.org:8080/XmlDaSampleS erver/service.asmx Servidor Technosoftware. 8. Biografías Fernando Alejandro Campos. Ingeniero en Electrónica y Telecomunicaciones de la Universidad del Cauca 2005. Actualmente es estudiante de Master in Sciences de Administración de sistemas de información en L Ecole Nacional Superior des Telecomunicaciones et L Ecole nacionale des ponts et Chosses (Paris Francia) Germán Mauricio Coral H. Estudiante de último semestre de Ingeniería en Electrónica y Telecomunicaciones de la Universidad del Cauca. Actualmente desarrolla su proyecto de Grado Sistema de Supervisión y Control Multiplataforma. Investigador del grupo de I+D en Automática industrial de la Universidad del Cauca. Sus líneas de interés son: Sistemas SCADA e Integración Empresarial. Oscar Amaury Rojas. Ingeniero en Electrónica y Telecomunicaciones y Especialista en Informática Industrial de la Universidad del Cauca en 1996 y 2001 respectivamente. Actualmente cursa estudios de maestría de ingeniería con énfasis en automática en la Universidad del Cauca. Profesor asociado del Departamento de Electrónica, Instrumentación y Control e investigador del grupo de I+D en Automática industrial de la Universidad del Cauca. Sus líneas de interés son: Sistemas SCADA e Integración Empresarial. Investigador del grupo de I+D en Automática industrial de la Universidad del Cauca y fue presidente del grupo de investigación en sistemas empotrados de la Universidad del Cauca en el año