Gestión e implementación de una pasarela HTTP-OPC aplicado a una planta solar

GESTI ´ ON E IMPLEMENTACI ´ ON DE UNAPASARELA HTTP-OPC APLICADO AUNAPLANTASOLAR Beatriz Pontes Dto. Ingenier´ıa de Sistemas y Autom´atica, Universidad de Sevilla, bepon[email protected] Alfonso Cepeda Dto. Ingenier´ıa de Sistemas y Autom´atica, Universidad de Sevilla, cep[email protected] Eduardo F. Camacho Dto. Ingenier´ıa de Sistemas y Autom´atica, Universidad de Sevilla, [email protected] Resumen El prop´osito de este art´ıculo es detallar c´omo conseguir un acceso eficiente a datos provenientes de un dispositivo gen´erico o planta industrial situada dentro de una red local. Dicho dispositivo debe estar conectado a un servidor OPC que permita acceder a las distintas variables. La situaci´on que se intenta resolver es aquella en la que solamente es posible acceder a las variables de un dispositivo cualquiera desde un equipo que est´e necesariamente situado dentro de la misma red local. La soluci´on abordada en este art´ıculo se basa en la elaboraci´on de una aplicaci´on web que permita proporcionar el acceso a distintos usuarios tanto desde dentro como desde fuera de la red a la que pertenezca la planta. Esta soluci´on permite tambi´en el control remoto ya sea de una planta industrial o cualquier otro tipo de dispositivo haciendo uso de OPC. En concreto, se mostrar´a una Planta Solar sobre la que se explicar´an los aspectos de implementaci´on. Palabras clave: Pasarela HTTP-OPC, OPC, XML, Supervisi´on, Control remoto. 1. INTRODUCCI ´ ON El origen de este art´ıculonacedelanecesidadde la supervisi´on y control remoto de dispositivos a trav´es de Internet ([9]). La situaci´on de partida es aquella en la que el dispositivo a controlar y el equipo al que se encuentra f´ısicamente conectado est´en situados dentro de la misma red local, no teni´endose acceso desde un equipo exterior a dicha red. Para conseguir que el acceso desde una red externa sea posible se pueden tomar varias alternativas, teniendo todas un punto en com´un, exigen la existencia de un equipo intermedio que est´e situado dentro de la misma red local del dispositivo en cuesti´on y que sea accesible desde el exterior. Este equipo tiene una doble funcionalidad, por un lado act´ua como cliente a la hora de acceder a los datos del dispositivo y por otro act´ua como servidor de dichos datos hacia el exterior, constituyendo as´ı una pasarela. Es importante tener en cuenta que si el equipo conectado directamente a la planta dispone de una direcci´on IP p´ublica no es necesaria la instalaci´on de este otro equipo intermedio (la pasarela estar´ıa implementada en el mismo ordenador). La estructura de este art´ıculoeslasiguiente:en el apartado 2 se realiza un an´alisis de las posibles tecnolog´ıas a utilizar y de la situaci´on inicial de las plantas a las que se les puede aplicar este sistema de control. El apartado 3explica cu´al es el proceso del sistema de supervisi´on propuesto, sigui´endole en el apartado 4 la especificaci´on de c´omo realizar el control de una planta industrial general y en particular la Planta Solar situada en el Instituto de Autom´atica de Andaluc´ıa, que se muestra en la Figura 1. Por ´ultimo, el art´ıculo finaliza con una secci´on de conclusiones referidas a su contenido. 2. SITUACI ´ ON DE PARTIDA Dentro de la industria del control, varias tecnolog´ıas han tenido mucho auge en los ´ultimos tiempos. Cabe destacar los protocolos de comunicaciones CORBA, Java RMI, XML-RPC o SOAP y las soluciones basadas en web, entre las que se han analizado las posibles soluciones para afrontar el control remoto, teniendo en cuenta que la opci´on que se elija debe ser aquella que proporcione una mayor facilidad al usuario final XXVI Jornadas de Automática, 2005 A licante-Elche ISBN: 84-689-0730-8 377 Figura 1: Planta Solar situada en el Instituto de Autom´atica de Andaluc´ıa sin repercutir en la eficiencia. -Enprimer lugar, se podr´ıa optar por la utilizaci´on de CORBA, que es una arquitectura est´andar para el desarrollo de aplicaciones distribuidas, pero que tiene el inconveniente de ser muy compleja, presentando problemas de implementaci´on debido a la dificultad de sus especificaciones ([2]). -Tambi´en es importante mencionar el protocolo XML-RPC. ´ Este es un protocolo m´as sencillo de utilizar que CORBA que utiliza HTTP para la transmisi´on y est´a basado en XML para la codificaci´on de los datos ([3]). La caracter´ıstica que hace que no sea apropiado para el acceso remoto es que necesita de la instalaci´on de determinados m´odulos en el equipo del usuario. -SOAP(“Protocolo de acceso a objetos simple”) es un lenguaje de mensajer´ıa basado tambi´en en XML. La principal diferencia entre SOAP y XML-RPC es su complejidad. SOAP est´a creado para dar un soporte m´as completo y minucioso, lo que lo hace ser m´as complejoyalavezm´as potente ([15]). - Por otra parte, existe un mecanismo ofrecido en Java llamado RMI (“Remote Method Invocation”), que permite que un procedimiento pueda ser invocado remotamente ([4]). Presenta la gran ventaja de ser independiente de la arquitectura por la propia tecnolog´ıa Java, y adem´as es posible la elaboraci´on de un applet de Java que facilite su uso por parte del usuario. - Finalmente, es posible contar tan s´olo con el uso del protocolo HTTP. La soluci´on consiste en la creaci´on de una aplicaci´on web que permita la supervisi´on y el control de la planta, teniendo as´ı el usuario la posibilidad de realizar estas tareas mediante un navegador web, eliminando posibles problemas de interoperabilidad e incompatibilidad as´ıcomo la necesidad de instalar un software espec´ıfico para el acceso. Aunque estas ventajas son compartidas con la utilizaci´on de Java RMI junto con applets, resulta m´as sencilla la elaboraci´on de una aplicaci´on web. Esta ´ultimaopci´on, que es la que se ha elegidoparalaelaboraciondelproyectobase de este art´ıculo, tiene tambi´en la ventaja de que, al utilizar el protocolo HTTP, el acceso no estar´a restringido por ning´un cortafuegos convencional en Internet. El proceso de elaboraci´on es el siguiente, en un ordenador de la red local, que de ser accesible desde una red externa puede ser el mismo donde est´e la conexi´on f´ısica con la planta, se instala un servidor web que soporte alg´un lenguaje de programaci´on. En este servidor se realiza un programa que por un lado acceda a la planta que se quiera controlar y por otro proporcione una p´agina web din´amica que ser´ a enviada por el servidor web. As´ı se consigue poder realizar tareas tales comomostrar los valores reales de la planta, y a trav´es de peticiones GET o POST, modificar par´ametros de control de la planta. Para poder realizar todo esto es necesario disponer de los siguientes elementos: -Planta industrial real a controlar: En este caso se trata de una Planta Solar que se utiliza para climatizaci´on. Dicha planta estar´a conectada a un equipo con el hardware y software apropiado para adquirir datos directamente de ella. Tambi´en se debe disponer del software espec´ıfico de control avanzado y optimizaci´on multivariable ([12]). Se puede encontrar una descripci´on de la Planta Solar en ([8]). -Equipo conectado al dispositivo:Esel equipo que se encuentra conectado directamente al dispositivo que se va a supervisar y controlar, se encuentra situado dentro de la red local y debe tener instalado un servidor OPC para poder servir los datos provenientes de dicho dispositivo. En el caso de que su direcci´on IP sea privada, y por tanto solamente sea accesible desde dentro de la misma red local, ser´a necesario contar con otro XXVI Jornadas de Automática, Alicante-Elche, 2005 378 equipo que permita el acceso desde el exterior. -Equipo accesible desde el exterior:Equipo para el alojamiento de la aplicaci´on web, situado en la misma red local que el equipo conectado directamente al dispositivo. Este equipo debe tener instalado un servidor de Internet que de soporte a la aplicaci´on y debe disponer de una direcci´on IP p´ublica para poder acceder a ´el a trav´es de Internet con una direcci´on espec´ıfica. En caso de que no sea necesaria la instalaci´on de este equipo, todo su requisitos deber´an estar situados en el equipo conectado directamente a la planta a controlar. -Cliente OPC:Parapermitir que la aplicaci´on web acceda a los datos de la planta industrial es necesario diponer de un cliente OPC que est´eimplementado en formadeunActiveX.En el caso de la Planta Solar, se ha desarrollado dicho ActiveX a partir de un conjunto de librer´ıas enC++delasqueyasedispon´ıa con anterioridad. Una vez que se han analizado las distintas tecnolog´ıas que se podr´ıan haber utilizado y los elementos necesarios para poder llevar a cabo el acceso remoto a un dispositivo gen´erico, en los siguientes apartados se especificar´adequ´emanera es posible realizar la supervisi´on y el control de una planta industrial. 3. DESARROLLO En primer lugar, se presenta en la Figura 2 un esquema general de cu´ales son las tareas involucradas en el proceso de supervisi´on o control desde un equipo cualquiera que accede a trav´es de Internet. Figura 2: Esquema general de acceso En dicha figura se puede observar que el proceso comienza cuando un usuario realiza una petici´on a un servidor de p´aginas web mediante una direcci´on espec´ıfica por medio de Internet. En el servidor web se procesa la petici´on y se realiza un acceso mediante un cliente OPC a un servidor OPC situado en la mismaredlocal(n´otese que ambos procesos cliente y servidor OPC pueden residir en el mismo equipo). Una vez que el servidor OPC haya proporcionado los datos necesarios, el servidor web se encarga de enviar la respuesta al usuario que inici´o todo el proceso. De esta manera se realizan cada uno de los accesos ya sea para supervisi´on o control de la planta. 3.1. CLIENTE OPC El cliente OPC es un programa que debe desarrollarse en el equipo que es accesible desde el exterior. Su implementaci´on est´a ligada a un control ActiveX del que se debe ya disponer (en el caso particular de la Planta Solar ha sido creado expresamente para este fin). Es posible utilizar cualquier lenguaje de programaci´on que permita el uso de controles ActiveX, escribiendo las instrucciones necesarias para definir cu´al es el servidor OPC al que se quiere realizar la conexi´on y cual es su localizaci´on. Posteriormete es necesario invocar al m´etodo que realice la conexi´on al servidor OPC y a˜nadir los ´ıtemsque se vayan a utilizar ([5],[14]). Estos ´ıtems ser´an accedidos posteriormente ya sea para la petici´on de documentosXMLoparalasupervisi´on o control de la planta. 3.2. PETICI´ ON DE DOCUMENTOS XML Aprovechando que el protocolo HTTP permite realizar la transferencia de ficheros en cualquier formato, es posible realizar un programaenel servidor web que env´ıe los valores actualizados de las variables de la planta a controlar en tiempo real y codificados en XML. La petici´on de este tipo de ficheros se realizar´adelamismamanera en que se realiza la petici´on de una p´agina web, pero en este caso el c´odigo ejecutado en el equipo servidor detectar´alapetici´on devolviendo un archivo en formato XML, incluyendo los valores actuales de las variables, a las que accede mediante el cliente OPC ([11]). De esta manera cualquier programa local con capacidad para leer dicho formato puede elaborar an´alisis a partir de los datos obtenidos. La estructura del documento que se obtiene para el caso particular de la Planta Solar es el que se muestra a continuaci´on: Ingeniería de Control-CE A 379 <?xml version="1.0"?> <plant> <Variable name="SOLAR\RT13003_PV">108.632</Variable> <Variable name="SOLAR\TT10114_PV">58.8</Variable> <Variable name="SOLAR\PT11001_PV">4.246</Variable> <Variable name="SOLAR\TT10113_PV">60.5</Variable> <Variable name="SOLAR\TT10116_PV">58.3</Variable> <Variable name="SOLAR\PT11002_PV">1.102</Variable> </plant> 3.3. SUPERVISI ´ ON DE LA PLANTA SOLAR La supervisi´on de los datos de un dispositivo permite visualizar las variables de dicho dispositivo de manera que ´estas se actualicen constantemente, o una vez transcurrido un intervalo de tiempo determinado. La implementaci´on a realizar est´a basada en un objeto JavaScript, denominado XMLHttpRequest ([1]), que permite hacer llamadas al equipo servidor para obtener documentos XML que contengan los valores actualizados. De esta manera es posible interpretar y mostrar los datos obtenidos sin necesidad de refrescar la p´agina completa en cada acceso al servidor. Esta alternativa se ha escogido tanto por su sencillez como para reaprovechar recursos ya generados, ya que el documento XML que el servidor env´ıa como respuesta formaba ya parte de uno de los requisitos del sistema. El inconveniente de la utilizaci´on del objeto XMLHttpRequest es que ´este no est´aimplementado por todos los navegadores, aunque s´ı suelen incluirlo las ´ultimas versiones. Para evitar que usuarios que no dispongan de una versi´on actualizada de su navegador puedan realizar la supervisi´on es posible realizar la implementaci´on de otro modo, el cual se explica m´as adelante. El c´odigo ejecutado en el equipo servidor no var´ ıa de una implementaci´on a otra. La diferencia se encuentra en que en el caso de la utilizaci´on del objeto XMLHttpRequest,dicho c´odigo solamente se ejecutar´a en el primer acceso por parte del usuario. Para el resto de los accesos producidos para la actualizaci´on de los datos se realizar´an peticiones de ficheros XML que ser´an interpretados en el equipo del usuario, tal y como puede verse en la Figura 3.Elc´odigo ejecutado en el equipo servidor cuando se realizan peticiones de este tipo se especifica en el apartado 3.2: Petici´on de documentos XML. Por el contrario, cuando la supervisi´on se realiza por parte de un usuario que disponga de un navegador que no soporte estas caracter´ısticas, el c´odigo que se ejecuta en el servidor web es siempre el mismo en cada uno de los accesos, ya sea la Figura 3: Diagrama de supervisi´on con utilizando el objeto XMLHttpRequest primera vez o cualquier acceso de actualizaci´on. Adem´as de implementar el c´odigo necesario en el servidor web, es necesario escribir tambi´en algunas l´ıneasdec´odigo que sean ejecutadas en el equipo del usuario. Este c´odigo permitir´a realizar la petici´on e interpretar el documento XML que se recibe en cada actualizaci´on de los datos. El modo de operaci´on en cada una de estas peticiones es s´ıncrono, ´esto quiere decir que cuando el cliente realiza una petici´on queda en espera de una respuesta que seguidamente analizar´a. En primer lugar, cuando se carga la p´agina web en el equipo del cliente se realiza una llamada a un m´etodo inicial, que establece un periodo de tiempo para realizar una determinada acci´on cada vez que transcurra dicho periodo. En este caso, la acci´on a realizar es una petici´on del fichero XML que contiene los datos actualizados de la planta. Una vez que dicho fichero sea recibido, se invocar´aalm´etodo encargado de interpretar el documento y mostrar los nuevos valores por pantalla. Comosehacomentado antes, pueden existir algunas versiones de navegadores que no soporten estas caracter´ısticas, por lo que se ha realizado otra implementaci´on basada en la utilizaci´on del m´ etodo “meta refresh”,quepermite que una p´agina web se recargue cada vez que transcurra un cierto tiempo especificado. Esto significa que cada vez que se refresca la p´agina, el equipo del cliente realiza una nueva petici´on de la misma al equipo servidor. ´ Este m´etodovaincluidoenlacabecera del c´odigoHTMLdelap´agina en cuesti´on. XXVI Jornadas de Automática, Alicante-Elche, 2005 380 Al realizar una nueva petici´on de la p´agina, el servidor la reenv´ıa como si el acceso se hiciera por primera vez, con todos sus controles y componentes (ver Figura 4), lo que significa que no solamente se actualizan los datos de la planta en cada refresco como en el caso anterior, y que se pueden producir mayores tiemposderespuesta, dependiendo de la velocidad de conexi´on del equipo del usuario. Figura 4: Diagrama de supervisi´on sin la utilizaci´on de XMLHttpRequest Para el caso particular de la Planta Solar, se muestra a continuaci´on la apariencia final de la aplicaci´on web desarrollada en modo de supervisi´on. En la Figura 5 puede verse unas etiquetas de fondo azul en las que los valores de todas las variables se ir´an actualizando constantemente. 4. CONTROL DE LAPLANTA SOLAR Este sistema de control se ha aplicado a una Planta Solar gracias a que, a traves de una petici´on HTTP, se pueden modificar valores de variables de control ([6],[7],[10]). La modificaci´on de variables se lleva a cabo de una manera muy sencilla gracias al control ActiveX que se utiliza como cliente OPC, tan s´olo es necesario realizar una llamadaaun m´etodo espec´ıfico del control. Antes de proceder a la escritura del valor es necesario asegurarse que el cliente OPC se encuentra conectado al servidor OPC, as´ıcomo de que los ´ıtems est´en Figura 5: Supervisi´on de la Planta Solar correctamente a˜nadidos y tengan permiso de escritura en el servidor OPC. Es importante tener en cuenta que las caracter´ısticas de implementaci´on pueden variar seg´un los controles ActiveX que se utilicen. As´ı, mientras que con el quehasidodesarrolladoparaelcasodelaPlanta Solar es posible modificar el valor de una variable con una s´ola instrucci´on, si se utilizan otro tipo de controles ActiveX puede ser necesario tambi´en realizar alguna instrucci´on de actualizaci´on para que los cambios producidos sean permanentes. 5. CONCLUSIONES Alolargodeesteart´ıculosehaespecificado c´omo es posible realizar el acceso, ya sea para supervisi´on o control, a determinados valores pertenecientes a un dispositivo gen´erico,yen concreto a una Planta Solar. Comosehaexpuesto, dicho acceso puede producirse desde un equipo cualquiera con conexi´on a Internet. Esto supone un gran avance respecto a la situaci´on anterior en la que solamente se permit´ıa el acceso a la Planta Solar desde equipos situados dentro de la misma red local. Asimismo, el control ActiveX desarrollado en el entorno de este proyecto puede ser utilizado como cliente OPC para acceder a cualquier otro dispositivo con un servidor OPC asociado. Referencias [1]An´alisis del objeto XMLHttpRequest. XML Extras: Ingeniería de Control-CE A 381 http://webfx.eae.net/dhtml/xmlextras/xmle xtras.html. [2]CORBA Website. http://www.corba.org. [3] Definici´on y estudio del protocolo XML-RPC. http://www.xmlrpc.com. [4]The Java Remote Method Invocation system. http://java.sun.com/docs/books/tutorial/rmi/. [5]P´agina web oficial OPC Foundation. http://opcfoundation.org. [6] Mastascusa Aburdene, M.F. A proposal for a remotely shared control systems laboratory. pages 589–592. Proceedings of the ASEE 1991 Frontiers in Education Conference, Session 24A3, 1991. [7]C.A. Bohus Aktan, B. Distance learning applied to control engineering laboratories. volume39(3), pages 320–326.IEEE Transactions on Education, 1996. [8]E.F. Camacho and C. Bordons. Model Predictive Control. Springer, 2004. [9]Marcos D. Reguera P. Gonz´alez J.J. Blazquez L.F. Dom´ınguez, M. Connection pilot plant to the internet. IFACT Internet Based Control Education IBCE01, Madrid, Espa˜na., 2001. [10]S. Dormido. Control learning: present and future. 15th IFAC World Congress. Barcelona., 2002. [11]Michael Floyd. Building Web Sites with XML. Prentice Hall, 2000. [12]Daniel Gasa Fonollosa. Laboratorio remoto de autom´atica: plantas de variable discreta. XXIII Jornadas de Autom´atica, Leon. [13] J. Henry. Controls laboratory teaching via the world wide web. In proceedings of the ASEE Annual Conference. Washington, USA, Session 3513. [14]Marlon Mart´ınez. OPC: “OL´ E for process control”. 2003. [15]Aaron Skonnard. Understanding SOAP. 2003. [16] J. S´anchez, F. Morilla, and S. Dormido. Teleoperation of an inverted pendulum through the world wide web. pages 12–14. in workshop on internet based control education. IBCE’01, Madrid, Spain, 2001. XXVI Jornadas de Automática, Alicante-Elche, 2005 382