Utilizamos la herramienta Simulink de Matlab como soporte de nuestros modelos, debido a los siguientes motivos:

Transcripción

1 1. Introducción El resultado de la realización de este proyecto fue obtener un software capaz de comunicar de manera eficiente y en tiempo real la simulación de un modelo de cualquier sistema con algún programa SCADA, con el fin de poder realizar el control de este modelo de la misma manera que se podría controlar un sistema de producción real. Utilizamos la herramienta Simulink de Matlab como soporte de nuestros modelos, debido a los siguientes motivos: Matlab es un software matemático de gran potencia, lo que permite conseguir modelos altamente eficientes. Matlab es ampliamente conocido y utilizado en entornos universitarios y empresariales relacionados con la ingeniería. Simulink ofrece un interfaz grafico fácil a través de diagramas de bloques, que nos permite construir modelos de manera rápida. En resumen, cualquier usuario con los mínimos conocimientos será capaz de construir modelos realistas y útiles de manera relativamente sencilla sobre Matlab/Simulink. En cuanto a la comunicación con los sistemas de control SCADA, utilizaremos el estándar abierto OPC como medio. El estándar OPC es de dominio público y disponible para cualquiera que quiera usarlo. La mayoría de los sistemas SCADA ofrecen la posibilidad de cliente OPC para obtener y ofrecer datos, desde y hacia cualquier servidor OPC a las que tenga acceso. El objetivo, por lo tanto, fue el desarrollo de un servidor OPC capaz de comunicarse con Matlab/Simulink para obtener y actualizar valores en el propio modelo del proceso Qué beneficios nos trae este proyecto? Puede parecer poco útil la utilización de un sistema de control SCADA sobre un modelo simulado de un proceso, dado que el control es un sistema que nos permite obtener ciertos beneficios productivos y por lo tanto económicos; los cuales no tienen ningún sentido sobre un sistema irreal. Nos preguntamos entonces que nos puede aportar el resultado de este proyecto. Como elemento primordial, debemos tener en cuenta que no es fácil tener disponibilidad de cualquier proceso productivo en las fases de formación educativa. El aprendizaje del uso de sistemas SCADA será más eficaz si es posible realizar control sobre sistemas con ellos, este software nos permitirá poder simular nuestro proceso productivo en Matlab/Simulink y controlarlo desde el SCADA. 5

2 La posibilidad de probar un sistema de control y partes de este durante la fase de desarrollo del mismo. Éste puede ser a una ventaja grande si se detecta un error. Suele ser más fácil y menos costoso corregir errores si se detectan en una fase temprana del desarrollo. Permitirnos comprobar distintos comportamientos de nuestro sistema sobre el modelo, de manera que podamos analizar si es beneficioso aplicarlos sobre el proceso real. De esta manera no interrumpimos el sistema real con cambios que aun no sabemos si puede suponer un riesgo, a la vez que conseguimos optimizar de manera segura los parámetros de nuestro controlador. La simulación también puede permitir la visualización por parte del cliente de cómo un sistema de control podría funcionar con respecto al problema que este cliente presente. De esta manera el cliente puede convencerse mas fácilmente de que es ese el sistema de control que necesita. El control sobre el modelo nos permitirá ajustar los parámetros iniciales a aplicar sobre el sistema real, evitando así comportamientos peligrosos en el proceso de ajuste sobre el proceso El control sobre el modelo, finalmente, permitirá probar como se comportaría nuestro sistema ante condiciones límites, permitiéndonos preparar estrategias para mantener el sistema fuera de peligro Sistemas abiertos: OPC. Los SCADA realizan el interfaz con el operador de los sistemas de control, en las capas superiores (recolección de datos, supervisión, etc.). Puede ser específico de un fabricante para su propio hardware, o bien utilizable sobre hardwares compatibles de distintos fabricantes, y aquí podríamos empezar a hablar de apertura, de los que pueden utilizarse con distintos tipos de hardware, generalmente PLC s de, a su vez, distintos fabricantes. Tradicionalmente, los fabricantes de software para acceso de datos de proceso tenían que desarrollar drivers específicos para cada tipo de hardware al que querían acceder. Cada software requería un driver distinto para cada hardware, implicando un esfuerzo enorme, al que hay que añadir el de las actualizaciones continuas. Es decir, el problema surgía cuando nuestro hardware y nuestro software SCADA no pertenecen al mismo fabricante y por lo tanto pueden tener problemas de comunicaron. 6

3 Figura 1. Sistema de control tradicional. Para solucionar esto surge el concepto de sistemas de control abiertos, como por ejemplo el interfaz OPC. De esta manera podemos utilizar el hardware y el software más conveniente, sin tener en cuenta el fabricante de cada uno. Se trata de poder unir en una misma aplicación componentes hardware y software de distintos fabricantes, de manera que puedan intercambiar datos de manera transparente y flexible. Además debe de ofrecer pocas restricciones al diseño del usuario de sistemas, ofreciéndole por el contrario una amplia gama de opciones. Todo esto indica un gran nivel de estandarización. OPC (OLE for Process Control) es un estándar abierto que nos permitirá obtener un sistema abierto para comunicar, en nuestro caso, el sistema de control SCADA con el modelo de Simulink. Figura 2. Sistema de control abierto 7

4 1.3. Introducción a OPC El OLE para control de procesos (OPC) es un estándar abierto para compartir datos entre dispositivos de campo y aplicaciones de ordenador, basado en OLE de Microsoft. Permite a las aplicaciones leer y escribir valores de proceso y que los datos sean compartidos fácilmente en una red de ordenadores. libre. El estándar, gobernado por la Fundación OPC, es de dominio público y acceso Con OPC, los fabricantes de hardware sólo tendrán que preparar un conjunto de componentes de software para que los clientes los utilicen en sus aplicaciones. Los desarrolladores de software no tendrán que reescribir los drivers debido a nuevas versiones de hardware. Los usuarios finales tendrán muchas más alternativas de integrar distintos sistemas. Una aplicación OPC, como cualquier otra aplicación OLE (o DDE), constará de servidores y clientes OPC. Cada cliente, es decir, cada aplicación de usuario, SCADA, módulo histórico, o aplicación de usuario interroga al servidor que contiene los datos que necesita. Figura 3. Diagrama cliente-servidor OPC Los servidores están organizados en grupos y cada grupo puede contener distintos ítems. Las diferentes partes de la aplicación pueden usar distintos grupos, los cuales pueden tener distinta frecuencia de refresco y pueden ser de acceso secuencial o basado en excepciones (eventos). Los ítems representan conexiones a fuentes de datos dentro del servidor (variables de proceso). A cada ítem se asocia un valor (valor de la variable de proceso), un cualificador (estado de la variable, OK, bajo rango, etc.) y una marca de tiempo. 8

5 Figura 4. Organización de objetos en un servidor OPC Evolución histórica de OPC 1982 DOS: Los PC no podían realizar acciones simultáneas, por lo tanto el intercambio de datos entre aplicaciones no existía. Se necesitaba un driver específico para cada dispositivo Windows 3.0 y DDE (Intercambio de datos dinámicos). Permitía visualizar datos de procesos desde otras aplicaciones, sin embargo DDE no fue suficientemente robusto y tenía un ancho de banda limitado, además de no poder enviar información a través de redes Windows 3.1 y OLE 1.0 (Object Linking & Embedding). Era mucho más robusto, eficiente y flexible OLE 2.0 Comité WinSEM. Este grupo de desarrolladores se reunía regularmente con el objetivo de poder aplicar el PC a procesos industriales. Se interesaron en el intercambio de datos en tiempo real utilizando OLE. Aunque no consiguieron un estándar, un grupo menor de este comité formó OPC Task Force, que en poco tiempo sacaría un estándar OLE 2.1 (32 bit) OPC Task Force se hace pública mostrando sus objetivos. En diciembre saldría el borrador del primer estándar. Hacia finales de 1995 sale Windows Especificación OPC V Windows NT 4.0: Aparece en 1996, combina la fiabilidad del NT 3.5 con el interfaz de usuario del W 95. Incluye soporte de DCOM (Distributed 9

6 Common Object Model), que permite a las aplicaciones crear y trabajar con objetos residentes en otros ordenadores a través de la red Se crea la fundación OPC, en agosto, con el objetivo de desarrollar un estándar abierto, basado en los requerimientos funcionales de la tecnología OLE/COM y DCOM Comités Técnicos OPC 1998 Especificación OPC V1.01. o OPC-DA (Data Access).- El original, sirve para el intercambio de datos a tiempo real entre servidores y clientes Windows 98: sistema operativo multitarea con soporte para DCOM integrado y por lo tanto para tecnología de servidor de OPC barato y probado la fundación de OPC lanzó OPC Unified Architecture draft. Anteriormente ya se ha lanzado OPC HDA, OPC DX, OPC AE, OPC Commands, OPC Security. o OPC-AE (Alarms & Events).- Proporciona alarmas y notificaciones de eventos. o OPC B (Batch).- Útil en procesos discontinuos. o OPC DX (Data exchange).- Proporciona interoperabilidad entre varios servidores. o OPC HDA (Historical Data Access). - Acceso histórico a datos OPC. o OPC S (Security).- Especifica cómo controlar el acceso de los clientes a los servidores. o OPC XML-DA (XML Data Access). mensajes SOAP (sobre HTTP) con documentos en XML. o OPC CD (Complex Data).- Permite a los servidores exponer y describir tipos de datos más complicados en forma de estructuras binarias y documentos XML. 10