UNIVERSIDAD POLITÉCNICA DE MADRID. E.T.S. de Ingenieros Industriales

Transcripción

1 UNIVERSIDAD POLITÉCNICA DE MADRID E.T.S. de Ingenieros Industriales Plataforma de pruebas basada en CORBA de tiempo real para sistemas de control de procesos PROYECTO DE FIN DE CARRERA Rafael Chinchilla Cámara 2005

2

3 Índice general 1. Introducción Sistemas de control Introducción Sistemas de control industrial Características generales de los sistemas de control Confiabilidad Mantenibilidad Escalabilidad Configurabilidad Niveles de un sistema de control Transmisiones de datos Funciones características de un sistema de control Adquisición de datos Alarmas Control Seguridad Comunicación con otros sistemas Informes Elementos del control de procesos Sensores Actuadores Controladores Sistemas de comunicación Interfaces de usuario Bases de datos Sistemas de control distribuido Requisitos y características de los sistemas de control distribuido DCS en el ámbito industrial Distributed Object Computing (DOC) Middleware Middleware existentes Funcionamiento de un middleware Sistemas de control de tiempo real Aplicaciones de los sistemas de tiempo real Características de los sistemas de tiempo real

4 4 ÍNDICE GENERAL Tiempo real duro y blando Restricciones de tiempo Predecibilidad Planificación Soporte de tiempo real en Linux Sistemas operativos e interfaces de tiempo real CORBA El Object Management Group Descripción y objetivos Estructura y actividades Resumen de especificaciones Especificaciones del OMG Object Management Architecture (OMA) Especificaciones de CORBA/IIOP Lenguaje IDL Especificaciones especiales Servicios Facilidades Especificaciones de dominio Especificaciones de seguridad La Tecnología CORBA Common Object Request Broker Architecture (CORBA) Arquitectura general Interoprerabilidad entre ORBs CORBA IDL Bases de la construcción de aplicaciones CORBA UML CCM CORBA de tiempo real CORBA con tolerancia a fallos Protocolos de transporte extensibles Otras especificaciones Temporización extendida Transductores inteligentes CORBA en el bucle de control Controladores Restricciones de tiempo Retrasos introducidos por la red Diseño del sistema en base a los retardos Ejemplos de aplicación de CORBA a sistemas de control Bucle de control en red Bucles de control supervisados MMS basado en CORBA Componentización de comunicaciones Entornos de integración en fábrica CORBA para PLC

5 ÍNDICE GENERAL Arquitecturas orientadas a componentes Bloques de control Teleoperación de Robots Gestión de riesgos Vídeo de tiempo real para teleoperación Operación de plantas cementeras Automatización de subestaciones Process Control Testbed (PCT) Introducción Casos de uso del PCT Generación de secuencias de eventos Simulación distribuida Integración de sistemas comerciales Generación de fallos Bucle de control Tráfico intensivo de datos Interacción control-planta-simulación Acceso concurrente Requisitos y bases de diseño del PCT Consideraciones iniciales Descripción general de la plataforma Herramientas de monitorización Topología Hardware y Equipamiento Introducción Tabla de componentes hardware Plataforma de pruebas Proceso químico Planta Nodos de monitorización TTTech Descripción Configuración Detalles del hardware Supermicro SuperServer SYS 6012 P6 1U Dell Dimension Nodos TTTech TPS Sensor de ph Crison GLP Transmisor de temperatura Sonda PT Bombas Tarjetas DAQ y conectores Módulo calentador Cable serie

6 6 ÍNDICE GENERAL 6. Arquitectura Software Introducción Sistemas operativos y herramientas Distribuciones Linux Entorno de desarrollo y compiladores ICa Introducción Instalación de ICa Ejecución de aplicaciones Librerías de interfaz y drivers COMEDI ABACUSS Modbus MySQL La librería AMS Bases de diseño Componentes Diagrama de clases Librería de componentes del PCT Modelo de componentes Clases de la librería de componentes Código fuente de los componentes base Ejemplo de implementación Diagramas de secuencia principales Tabla de componentes software Interfaces IDL Sensor de ph Actuador Modbus Simulador ABACUSS Base de datos Regulador Diagrama de componentes del sistema Implementación de los componentes del PCT Sensor de ph Regulador Actuador Base de datos Wrapper modbus HMI Simulador Aspectos adicionales de la implementación Inicialización del ORB de tiempo real Obtención del manejador de un componente CORBA Uso del protocolo de tiempo real RTP Organización de archivos Arbol de directorios patrón

7 ÍNDICE GENERAL Interfaces gráficas Makefiles Protocolo de tiempo real TTP El protocolo TTP/C Extensiones para protocolos de transporte CORBA Implementación del RTP Experimentos Bucle de control CCS con la red Ethernet Hardware implicado Software implicado Realización del experimento Resultados Bucle de control CCS con la red TTP/C Hardware implicado Software implicado Realización del experimento Integración de sistemas comerciales Hardware implicado Software implicado Realización del experimento Resultados Gestión de eventos asíncronos (SOE) Interacción de planta simulada con agentes de control Hardware implicado Software implicado Realización del experimento Resultados Tráfico intensivo de datos Hardware implicado Software implicado Realización del experimento Resultados Acceso concurrente a recursos Resultados Redes heterogéneas Prueba del protocolo RTP para TTP/C Resultados Conclusiones CORBA para sistemas de control: conclusiones Resultados de los experimentos Bucles de control basados en Ethernet Integración de sistemas comerciales Interacción entre controlador y simulación Tráfico intensivo de datos Acceso concurrente

8 8 ÍNDICE GENERAL Experimentos en la red TTP Cumplimiento de los requisitos establecidos Arquitectura software de la plataforma Líneas futuras de trabajo Tolerancia a fallos Configurabilidad Mejoras de la arquitectura software Anexo: datos de los experimentos Experimento CSS con topología hub Experimento: CSS con topología switch Experimento: Tráfico intensivo con topología hub Experimento: Tráfico intensivo con topología switch Experimento: Acceso concurrente con topología hub Experimento: Acceso concurrente con topología switch Experimentos adicionales

9 Agradecimientos Este proyecto de fin de carrera marca el final de mi etapa de estudiante universitario, una de las mejores (si no la mejor) épocas de mi vida. Quiero expresar ante todo mi más profunda gratitud a mis padres y a mis hermanos, porque siempre han alimentado y fomentado mi curiosidad y mis ganas de aprender. Gracias a ellos por haberme apoyado en todo momento, por haber permanecido a mi lado de forma incondicional tanto en los mejores momentos como en los peores. Gracias a mis padres, en fin, por haberme brindado la oportunidad de estudiar y (espero) trabajar en lo que siempre me ha atraído. No me olvido de mis compañeros del ASlab, con los que he pasado grandes ratos de risas, con los que he mantenido conversaciones tan interesantes y con los que sí, también he tenido mis roces. Raquel, con una sonrisa siempre disponible y una broma preparada en el bolsillo; hemos pasado mucho, gracias por saber aguantarme. Carlos Martínez, con ese enorme interés por aprender y por ayudar a quién lo necesite; muchas gracias por echarme un cable en tantas ocasiones. Paco, linuxero donde los haya y fan de los juegos en red. También Carlos García, Julia, Adolfo, Mariano, Cristina, Ceci, Jose, Silvia, Santos, Manolo, David, Ignacio y otras muchas personas que han pasado por mi vida en este tiempo, y que no olvidaré. En especial quiero mostrar mi agradecimiento a mi tutor Ricardo Sanz por haberme dado la oportunidad de hacer este proyecto y de conocer y aprender tantas cosas; por esas conversaciones tan interesantes y divertidas (incluso desconcertantes :p), siempre al lado de un café; y en definitiva, por el apoyo que me ha dado siempre. Sin todas estas personas no me habría sido posible llegar hasta aquí. Muchas gracias a todos. 9

10 10 ÍNDICE GENERAL

11 Sobre el Proyecto y esta Memoria Este Proyecto de Fin de Carrera ha sido realizado en la División de Ingeniería Sistemas y Automática (DISAM), dentro del Departamento de Automática, Ingeniería Electrónica e Informática Industrial de la Escuela Técnica Superior de Ingenieros Industriales de Madrid. Las líneas de investigación del DISAM están orientadas al estudio y desarrollo de nuevas tecnologías en el campo del control, control de procesos, robótica, visión artificial, inteligencia artificial y otros. He realizado este proyecto en el Autonomous Systems Laboratory (ASlab), donde trabajamos en proyectos relacionados principalmente con la inteligencia artificial, los sistemas autónomos y la robótica. Nuestro principal objetivo es avanzar en la investigación y desarrollo de sistemas de control avanzado. Creemos en la posibilidad de desarrollar sistemas que dispongan de una autonomía de funcionamiento casi completa, que puedan afrontar situaciones imprevistas y, en definitiva, desarrollar tareas de control de sistemas complejos de forma inteligente y robusta. El contenido de este proyecto forma parte de otro de ámbito internacional llamado Hard Real time CORBA (HRTC) en el que participaron varias entidades y universidades europeas, entre ellas la Universidad Politécnica de Madrid. El proyecto HRTC se realizó en 2002/2003 y fue patrocinado por la Information Society Technologies (IST) de la Unión Europea. Fue un primer paso dentro de una línea de investigación que pretende conseguir un conjunto de especificaciones para CORBA que permita el diseño y construcción de sistemas de control distribuidos y de tiempo real estricto (hard real time). Sus objetivos incluyen el desarrollo de una teoría y una metodología de ayuda al desarrollo de este tipo de sistemas de control. La Universidad Politécnica lideró el proyecto HRTC, siendo una de las tareas a realizar el desarrollar una plataforma de pruebas consistente en un sistema de control en tiempo real basado en RT CORBA para controlar un proceso (una planta química). Esta parte en concreto, denominada PCT (Process Control Testbed), constituye este Proyecto de Fin de Carrera. Este documento se estructura de la siguiente forma. El capítulo 1 es una introducción en la que se exponen las últimas tendencias en el desarrollo de sistemas de control y las motivaciones para el uso de CORBA en dicho desarrollo. En el capítulo 2 se incluye una descripción del estado del arte y características de los sistemas de control de procesos, de los sistemas distribuidos y de los sistemas de tiempo real, haciendo hincapié en la necesidad que tiene la industria actual de usar arquitecturas sofisticadas para el desarrollo de sistemas complejos de control. El capítulo 3 presenta el Common Object Request Broquer Architecture (CORBA), incluyendo su especificación para tiempo real, como una posibilidad interesante para desarrollar éstos; este capítulo incluye ejemplos de aplicación de CORBA en el dominio del control industrial. En el capítulo 4 se describen las bases de diseño y casos de uso que son el punto de partida para la construcción del Process Control Testbed, objeto de este 11

12 12 ÍNDICE GENERAL proyecto. En el capítulo 5 se detalla el harware y equipamiento utilizados, incluyendo las especificaciones técnicas, y en el capítulo 6, se describe la arquitectura software desarrollada para la plataforma de pruebas. En el capítulo 7, se presentan los experimentos realizados sobre para la plataforma, su diseño, objetivos y resultados. Los resultados de los experimentos y las conclusiones extraídas del desarrollo y funcionamiento de la plataforma de pruebas pueden encontrarse en el capítulo 8. En este mismo capítulo se termina exponiendo una serie de posibles líneas de trabajo que supondrían una extensión o una mejora del trabajo realizado en este proyecto. Por último, y en forma de anexos al documento, se adjuntan los datos de los experimentos y la bibliografía del proyecto.

13 Capítulo 1 Introducción Durante los últimos años, en la industria en general, y en concreto en el ámbito de la ingeniería de control, los sistemas de control han ido evolucionando de forma paulatina haciéndose cada vez más complejos, utilizando hardware y software de muy diferentes tipos, y empleando protocolos y medios de comunicación de mayores prestaciones. Se realizan tareas de mayor complejidad que necesitan grandes cálculos o que imponen requisitos de tiempo cada vez más estrictos, y a menudo es necesario integrar dentro de un mismo sistema elementos de muy diferente naturaleza, sistemas embebidos, hardware específico, etc. En resumen, la tendencia general de los sistemas de control actuales es hacia los sistemas heterogéneos distribuidos y, en muchos casos, con necesidades adicionales como tolerancia a fallos. La principal razón de la heterogeneidad que aparece en estos sistemas es que un equipamiento especializado, construido o comprado ad-hoc para controlar o actuar sobre un sistema en concreto, tiene en general un mayor rendimiento y es más eficaz que un equipamiento genérico. La adquisición de datos de los sensores, el control de actuadores, la gestión de procesos industriales, la planificación y otras muchas tareas son actividades muy diferentes y que se implementan a distintos niveles del sistema de control. En la figura 1.1 puede verse un esquema de un sistema de control complejo, que da idea de la variedad de dispositivos y redes que pueden aparecer en uno de estos sistemas. La razón para la distribución de los sistemas, esto es, la descentralización masiva del software y el hardware que los forman, reside en que en muchos casos el proceso y/o dispositivo controlador debe situarse en las cercanías del proceso a controlar, ya sea por requisitos de diseño, restricciones de tiempo (por ejemplo, latencias de las redes de comunicación), etc. Además, existen varias razones para elegir una arquitectura distribuida: Disponibilidad de hardware embebido específico para muchas aplicaciones, Restricciones de tiempo de carácter estricto, Necesidad de mayores niveles de rendimiento que los alcanzados por arquitecturas convencionales, Simplificación de la construcción y mantenimiento gracias a la modularidad, 13

14 14 CAPÍTULO 1. INTRODUCCIÓN Figura 1.1: Ejemplo de un sistema de control industrial Reducción de los costes y tiempo de fabricación e implantación gracias a la reutilización de componentes, Integración de sistemas fabricados por terceros, Uso de plataformas específicas de software. Un ejemplo muy común de sistema distribuido podemos encontrarlo en una planta de procesamiento o en un automóvil. En el caso de la planta, nos encontramos con un sistema complejo formado por dispositivos tan diversos como reguladores PID, válvulas, PLC s, terminales de supervisión y control, bases de datos, buses de campo, centros de cálculo, redes empresariales, etc. El conjunto de sistemas de control de un automóvil consiste también en una red de procesadores y elementos interconectados de gran complejidad, a pesar de su relativamente pequeño tamaño. Sin embargo, los sistemas distribuidos no se limitan únicamente a la industria de procesos o automovilística. Encontramos innumerables ejemplos de este tipo de sistemas dentro de la industria de comunicaciones, la industrial militar (sistemas de guiado, control de armamento), ingeniería civil (centros de control ferroviario o de tráfico urbano), domótica, transportes, etc. Todos estos sistemas tienen elementos en común. Son en general caros y difíciles de construir: mientras que el coste del hardware se ha ido reduciendo en los últimos tiempos gracias

15 15 a las nuevas tecnologías de diseño y fabricación, el software que funciona sobre el mismo ha ido aumentando en complejidad, con el consecuente aumento de los costes de desarrollo del mismo. El problema del desarrollo de software consta de muchos factores, dos de los cuales son precisamente la heterogeneidad y la distribución [Aström and Wittenmark, 1997], [Coulouris et al., 2001]. La mejor forma de afrontar estos problemas es hacerlos desaparecer a nivel del desarrollo de software. Se trata de conseguir una abstracción común a todos estos sistemas; esto es, obtener un modelo de desarrollo común que por un lado permita prescindir de la heterogeneidad de los elementos del sistema a la hora de desarrollar el software (lo cual implica que el modelo proporcione independencia de la plataforma) y por otro lado, que haga posible el diseño y desarrollo del sistema como si fuera monolítico aún cuando en la realidad sea un sistema distribuido. Estas ideas son las que están detras de la Object Management Architecture (OMA), que pretende proporcionar una especificación y una metodología de desarrollo que haga el diseño y construcción de los sistemas independientes de la plataforma y transparentes a la distribución de sus elementos. En concreto, el modelo de objetos proporcionado por el Object Management Group (OMG) hace posible este tipo de desarrollo. Este modelo de objetos se detalla en la especificación denominada Common Object Request Broker Architecture (CORBA) [OMG, 2002a]. A pesar de todo, aunque la especificación CORBA tiene una utilidad ampliamente probada en varios dominios de aplicación, puede no ser suficiente en algunas situaciones. CORBA fue diseñado con objetivos como flexibilidad, interoperabilidad y reducción de complejidad, pero muchos sistemas de control imponen restricciones de tiempo real, de tolerancia a fallos o requieren tipos de sofware embebido que no son contemplados en la especificación clásica de CORBA. El objetivo del proyecto es la creación y evaluación de una arquitectura de control distribuida basada en CORBA que permita satisfacer una de estas necesidades adicionales: el funcionamiento de un bucle de control que presente restricciones de tiempo real estricto.

16 16 CAPÍTULO 1. INTRODUCCIÓN

17 Capítulo 2 Sistemas de control 2.1. Introducción Además de la productividad, flexibilidad, calidad y reducción de costes, uno de los objetivos principales hoy en día en la industria de la automatización y control es la integración vertical. Es decir, conseguir que la información esté disponible en tiempo real, a todos los niveles de la empresa, permitiendo a los usuarios y aplicaciones tener un conocimiento actualizado sobre la producción y situación, y así poder obrar en consecuencia. La información en tiempo real debe ser compartida entre diferentes plataformas de automatización, incluyendo sistemas de control, redes de transmisión, PLCs, sistemas de seguridad, sistemas SCADA, etc. El objetivo de la integración vertical es interconectar todos estos sistemas de la forma más eficaz, y para conseguirlo es necesario construir el sistema sobre unos cimientos sólidos proporcionados por una arquitectura software adecuada; los sistemas distribuidos surgen de esta idea Sistemas de control industrial Los sistemas de control modernos basados en DCS (Distributed Control System) o PLC (Programmable Logic Controller) son sistemas complejos y heterogéneos. Se organizan en jerarquías, y normalmente la cantidad de información que se intercambia entre los diferentes niveles (integración vertical) es pequeña en comparación con la cantidad de información que se intercambia dentro de un mismo nivel (integración horizontal). Sin embargo, en los últimos años la tendencia es la de aumentar la integración vertical en estos sistemas. La información que se maneja también está cambiando. En las capas cercanas al sistema o proceso controlado la información consiste básicamente en señales, como medidas y acciones de control. Al subir en la jerarquía la información es la misma que podemos encontrar en un sistema empresarial: estadísticas, previsiones, etc. Por otro lado, también cambian de un nivel a otro las características de tiempo real: en niveles cercanos al proceso, la información se actualiza periódicamente y a un ritmo relativamente rápido, y las restricciones de tiempo son más estrictas, mientras que en los niveles superiores el tráfico es más espaciado y sin demasiadas restricciones. Un ejemplo de una 17

18 18 CAPÍTULO 2. SISTEMAS DE CONTROL arquitectura de control moderna puede verse en la figura 2.1, que muestra el sistema de control Control IT de la empresa ABB [Lüders et al., 2002]. El sistema contiene varias redes de comunicación: un bus que conecta los dispositivos de campo en el nivel más bajo; una red de control que interconecta los controladores entre sí y con el control principal (Servidor de control). Dicho elemento principal es también el encargado de hacer llegar la información de planta a las capas superiores del sistema, y de gestionar la instalación del software de control en los controladores de planta. Aunque es posible cerrar bucles de control en esta red, no suele hacerse. El protocolo usado en la red de control es el ISO MMS (Manufacturing Message Specification) sobre TCP. Por razones de seguridad y eficacia, la red de control se divide en dos partes; la parte que conecta los controladores, y la parte que conecta las estaciones de trabajo, estaciones de ingeniería u operación, etc. Esta última parte funciona como una red cliente/servidor, sobre TCP/IP. Por último, la red de control se conecta a través de un bridge a la intranet de la empresa, que a su vez tiene acceso a Internet. Los modelos de objetos son componentes arquitecturales importantes en estos sistemas. El sistema de ABB se basa en el modelo de objetos llamado Aspect Object, un modelo de múltiples vistas (en el sentido de vista de UML), en el cual cada objeto del sistema se describe desde diferentes perspectivas (aspectos). Los objetos del modelo pueden ser objetos reales como motores y válvulas, o pueden representar productos, materiales, órdenes, etc. Los aspectos o perspectivas pueden ser la interfaz de usuario, configuración, simulación, informes de calidad, informes de producción, mantenimiento, diagrama eléctrico, diagrama de control, y muchos otros. El cometido del modelo Aspect Object es modelar un aspecto determinado de un objeto, de forma independiente de los demás, más que definir un objeto completo de una sola vez. Los aspectos se implementan en diferentes sistemas de software (llamados sistemas de aspecto, aspect systems), los cuales almacenan y gestionan la información específica del aspecto en cuestión. El resultado de este modelo es un sistema de múltiples subsistemas de software, poco integrados entre sí, que funcionan unidos gracias a un servicio especial que los interconecta. El modelo Aspect Object está basado en el ORB COM, y dispone de muchas características avanzadas que no pueden encontrarse en CORBA o COM por sí solos. Este sistema de control nos da una idea aproximada de la situación actual en el campo del desarrollo de los sistemas de control distribuidos, aunque por supuesto los modelos utilizados y las implementaciones de estos sistemas varían según el fabricante (ver [Plantscape, 2005], [Yokogawa, 2005], [Plantweb, 2005], [IA Series, 2005]). Si bien algunas de las ideas en que se basan estos sistemas y ciertos elementos que los componen son similares entre sí, la realidad es que cada sistema construido aporta en último término una solución particular; no existe un estándar real o de facto que sigan los fabricantes de manera que sea posible reutilizar el trabajo empleado en el desarrollo. La especificación de CORBA puede ser una solución adecuada que haga posible la homogeneización del desarrollo de estos sistemas de control al aportar una modelo básico de desarrollo de aplicaciones distribuidas. En las siguientes secciones de este capítulo se pretende dar una visión general del estado del arte y las características más destacables y comunes a los sistemas de control industrial

19 2.3. CARACTERÍSTICAS GENERALES DE LOS SISTEMAS DE CONTROL 19 Figura 2.1: Sistema de control Control IT de ABB actuales. El capítulo se divide en tres partes principales: características de los sistemas de control industrial haciendo hincapié en los sistemas de control de procesos; características particulares de los sistemas de control distribuido; y características de los sistemas de control en tiempo real. El conocimiento de la estructura y naturaleza de estos sistemas es fundamental para el desarrollo de éste proyecto, que se basa en la implementación de una plataforma de pruebas de sistemas de control; los resultados de los ensayos deben poder ser trasladables a la industria y por ello la plataforma debe asemejarse en la medida de lo posible a los sistemas reales Características generales de los sistemas de control Hay dos características fundamentales que debe tener un sistema de control para funcionar de forma adecuada:

20 20 CAPÍTULO 2. SISTEMAS DE CONTROL Confiabilidad Mantenibilidad Otras características que, si bien no son imprescindibles, suelen ser típicas, son Escalabilidad Configurabilidad Confiabilidad Un sistema se dice confiable si se puede garantizar que estará operativo cuando sea necesario. Los principales factores que afectan a la confiabilidad de un sistema son la fiabilidad, la seguridad, y la facilidad de uso. Fiabilidad. Se refiere a la proporción de tiempo durante el funcionamiento del sistema, en el cual se comporta según las especificaciones. Para que esto sea posible, en primer lugar el sistema debe garantizar una mínima integridad de sus componentes, mediante mecanismos de autocomprobación, detección y corrección de fallos, y mecanismos de seguridad que aseguren el correcto funcionamiento del sistema. Los posibles fallos de partes del sistema no deberían afectar al funcionamiento global del mismo, si bien algunas funciones pueden verse afectadas. En segundo lugar, el sistema debe disponer de componentes redundantes: si un componente funciona indebidamente, pero existe otro igual o similar que puede sustituirle temporalmente en su función, el sistema no se verá afectado por el fallo del primero. Por último, la disponibilidad depende de un correcto mantenimiento del sistema, que incluya análisis y diagnósticos periódicos, reemplazamientos, ajustes y reparaciones cuando sean necesarios. Seguridad. No debe permitirse que usuarios no autorizados realicen cambios indebidos en el sistema, ya que pueden dar lugar a datos incorrectos, provocar averías en el sistema de control o la planta, o dar lugar a accidentes. Para evitar estas situaciones, es conveniente crear un sistema de permisos adecuado. Facilidad de uso. El tiempo empleado en determinar cómo realizar una operacion determinada y aprender a manejar un sistema demasiado complejo es un tiempo no productivo Mantenibilidad La mantenibilidad de un sistema se consigue mediante: Uso de hardware y software estándar Realización de diagnósticos automáticos Tests fuera de línea cuando los diagnósticos automáticos no detectan un problema determinado Capacidad de reemplazamiento en caliente de los componentes del sistema, para reparaciones o ajustes.

21 2.4. NIVELES DE UN SISTEMA DE CONTROL Escalabilidad Un sistema de control ideal debería ser capaz de adaptarse a una gran variedad de sistemas, desde el sistema de automatización más simple basado en PLCs o un único procesador, hasta los grandes sistemas empresariales Configurabilidad Una característica que distingue los sistemas de control industrial de otros sistemas software es el hecho de que son programables (configurables) por el usuario final, ya sea mediante lenguajes específicos, ya sea mediante la introducción de valores de una serie de parámetros predefinidos en el sistema. El sistema está dividido en dos capas: una capa de soporte, oculta al usuario, y una capa de aplicación, que puede ser configurada por éste. En ocasiones los lenguajes de configuración pueden ser gráficos o basados en otros modelos como diagramas de flujo, etc. El estandar IEC recoge cinco lenguajes de esta naturaleza Niveles de un sistema de control 1. Red de información. Es la red de máximo nivel, en la que se intercambia información relativa a la producción, estrategias, estadísticas, e informes de la planta. Se comunica con la red de operación. 2. Red de operación. Interconecta las estaciones de operación, procesadores, etc. Suele usarse TCP/IP sobre Ethernet. En esta red se encuentran módulos como interfaces HMI, bases de datos de históricos, sistemas de control avanzado, y puntos de acceso a las redes de los niveles inferiores. 3. Red de control. Interconecta los controladores de bajo nivel del proceso o sistema controlado. 4. Bus de campo. Es un enlace de comunicaciones digital y bidireccional entre dispositivos inteligentes de la planta. Proporciona una transmisión de datos eficiente y precisa, permite el acceso múltiple, configuración y diagnósticos remotos, etc. Conecta los controladores del proceso (red de control) con los instrumentos y dispositivos Transmisiones de datos En un sistema de control típico podemos encontrar diferentes tipos de transmisiones de datos: señales, eventos y órdenes, y otros. Señales de control y datos. Los datos de los sensores se envían desde los dispositivos de campo a los controladores, y las señales de control son enviadas en sentido contrario. Éste es el tráfico de datos más importante del sistema. En general, este tipo de tráfico tiene pocas restricciones de tiempo real duro. Eventos y órdenes. Las alarmas o eventos son normalmente generadas desde los controladores cuando se detecta alguna situación anormal que requiere la intervención de un

22 22 CAPÍTULO 2. SISTEMAS DE CONTROL operador. Las órdenes corresponden a operaciones que se realizan en niveles superiores del sistema, que afectan a la operación de los controladores. Los requisitos de tiempo real suelen ser altos en ambos casos. Código binario. Es frecuente que el código binario de los controladores y otros dispositivos sea cargado desde las estaciones de ingeniería de las capas superiores, cuando se realiza el mantenimiento o instalación del sistema. Tráfico web. El uso de servidores web para el control y/o configuración de los dispositivos viene siendo una práctica bastante commún. Una aplicación muy típica es el diagnóstico remoto o la generación de informes Funciones características de un sistema de control A continuación se describen algunas de las funciones más típicas de los sistemas de control industrial Adquisición de datos El sistema de control obtiene datos desde los dispositivos conectados a la planta. Cada dispositivo se comunica periódicamente con los instrumentos de la planta que tiene asociados, comprueba las señales de entrada conectadas a dichos instrumentos, y las transforma a un formato adecuado para ser almacenadas en una base de datos local. En instantes predeterminados, un software dentro de éstos dispositivos se encarga de recojer los datos almacenados, manipularlos en caso necesario, y enviarlos a su destino final (por ejemplo una base de datos central). Toda la información acerca del proceso que recoge el sistema de control debe estructurarse de forma que puedan manejarse de forma eficaz (por ejemplo, agrupar los datos en varias colecciones, asociadas cada una a un lazo de control) Alarmas Los estados de alarma se generan mediante la comparación de los valores registrados en la planta, con límites, rangos u otras condiciones definidas por los operadores del sistema. Los cambios en estos estados pueden afectar al funcionamiento de varios módulos. Cuando se pasa a un estado de alarma, pueden llevarse a cabo diversas acciones; si la alarma es meramente informativa el sistema no se ve afectado, pero si la alarma se refiere a una situación de emergencia, puede lanzarse un procedimiento que lleve al sistema a un estado seguro de forma inmediata. Las alarmas se pueden hacer llegar a los operadores ya sea mediante las interfaces de usuario (HMI), sirenas, mensajes imprimidos, etc. Un estado de alarma requiere siempre que el operador haga un acuse de recibo Control Las funciones básicas de control pueden clasificarse en dos grupos: Contínuas

23 2.6. FUNCIONES CARACTERÍSTICAS DE UN SISTEMA DE CONTROL 23 Discontínuas Las funciones contínuas son por ejemplo los bucles o lazos de control, es decir, son operaciones que se realizan de forma ininterrumpida ajustando de manera continuada una serie de señales. Las funciones discontínuas se referen a acciones de control esporádicas. Para cada unidad de control en el nivel de campo, se define un conjunto de funciones de control y posiblemente una serie de secuencias. Cada secuencia se divide en fases, las cuales contienen varios pasos (comandos del lenguaje de programación que se emplea para configurar las unidades de control). Estos comandos se ejecutan secuencialmente y son los encargados de iniciar cualquier operación lógica requerida por el sistema: asignación de valores, comprobación de condiciones, envío de señales, etc. Pueden ejecutarse en diferentes modos, ya sea de forma automática, ya sea bajo la supervisión de un operador Seguridad En respuesta a condiciones anómalas de la planta, se pueden lanzar procedimientos de seguridad que detienen el funcionamiento normal y ejecutan una serie de instrucciones pensadas para esas situaciones. Las respuestas típicas son: Retener el funcionamiento del sistema fijando los valores de todas las variables hasta nuevo aviso. Ejecutar procedimientos de apagado y detener el proceso. Llevar el proceso a un estado de funcionamiento o parada, estable y seguro, de la manera más rápida posible Comunicación con otros sistemas Los sistemas de control deben interaccionar a menudo con otros subsistemas independientes, que se encuentran en la propia planta (laboratorios) o fuera de ella (sistemas de gestión de la información). Para que esta interaccíón sea posible es necesario proporcionar infraestructuras e interfaces que permitan la comunicación a diferentes niveles de red, y que dispongan de funcionalidades como conversión de datos, procesamiento de los mismos, etc Informes En muchos sistemas es necesario generar informes que reflejen la evolución del sistema controlado y su situación actual. Dichos informes pueden ser impresos o mostrarse en alguna pantalla. Aunque existen muchas variantes, pueden clasificarse en tres tipos básicos: Informes diarios: contienen una lista cronológica de los eventos o alarmas ocurridos, cambios del operador sobre el proceso, etc. Registros: contienen un listado o histórico de los valores que toman determinadas variables del proceso durante un período de tiempo. Tendencias: previsiones y análisis gráficos de la evolución de las variables durante un período de tiempo.

24 24 CAPÍTULO 2. SISTEMAS DE CONTROL 2.7. Elementos del control de procesos Cualquier sistema de control de procesos en bucle cerrado dispone, al menos, de los siguientes elementos: sensor, actuador, controlador y sistema de comunicación entre los anteriores Sensores La tendencia actual es emplear sensores inteligentes. Estos dispositivos ofrecen funcionalidades adicionales respecto a los sensores que podríamos llamar clásicos, como pueden ser: Transmisión de variada información sobre el dispositivo: rango de operación, condiciones de mantenimiento, etc. Operación remota: el usuario puede controlar el dispositivo remotamente a través del sistema de comunicación, siendo posible cambiar modos de operación, realizar actualizaciones de software, etc. Comunicación simplificada: la comunicación digital elimina la necesidad de utilizar convertidores ADC y DAC remotos. Sea como fuere estas características suponen un aumento del coste de estos dispositivos y un incremento de la complejidad del sistema, con el consiguiente aumento del riesgo de fallo, lo cual es un aspecto a considerar Actuadores En la industria de procesos estos elementos son fundamentalmente válvulas de control y bombas. La tendencia es la misma que en los sensores, es decir, instalar actuadores inteligentes, que además proporcionan una característica adicional a las descritas arriba, que es la capacidad de llevar a cabo tareas de cierta complejidad como pueden ser bucles básicos de control, algoritmos PID integrados, etc. Esto permite trasladar parte de la carga de la tarea control al propio actuador, haciendo el sistema menos distribuido y más local. Estos dispositivos implican el mismo aumento de complejidad y riesgo que en el caso de los sensores inteligentes Controladores Los controladores son básicamente procesadores con algunos componentes de software y hardware adicionales: Algoritmos de control Programas de aplicación Puertos E/S analógicos y digitales Interfaces de control y redes de campo Algunos fabricantes de controladores comerciales ampliamente utilizados son Emmerson, Invensys, Yokogawa, etc.

25 2.7. ELEMENTOS DEL CONTROL DE PROCESOS Sistemas de comunicación Los avances en las redes de comunicación son los que hacen posible utilizar los dispositivos inteligentes mencionados anteriormente. Desde el transporte de señales analógico (utilizando variaciones de intensidad de entre 4 y 20 ma) se ha ido evolucionando hasta alcanzar los modernos buses de campo (Profibus, FieldBUS, CAN, etc.), y un gran número de redes y protocolos de comunicación diferentes: Ethernet, la familia IEEE 802, IEEE 1394 (firewire), HART (Highway Addressable Remote Transducer), TTP/C (Time Priggered Protocol class C), etc. La característica más importante a destacar en la evolución de los sistemas de comunicación es que el empleo de señales digitales permite la comunicación en dos sentidos, cosa que no era posible con los sistemas analógicos. En los sistemas de comunicación digitales, la integración de la información se realiza no solo a nivel de planta, sino a niveles de control superiores. En cada nivel del sistema de control, suelen usarse diferentes protocolos y sistemas de comunicación, como veremos a continuación. Ver figura 1.1. Existen tres niveles característicos: nivel de planta, nivel de control y nivel de negocio. Nivel de planta. Se emplean buses de campo. Un bus de campo es un enlace de comunicaciones digital y multipunto en el que la información viaja en ambos sentidos. Sus ventajas incluyen: precisión y confiabilidad de los datos transmitidos, acceso múltiple, configuración y diagnósticos remotos, ahorro de cableado, y distribución de los algoritmos de control. Una desventaja de los buses de campo es que los protocolos no suelen ser abiertos, lo cual puede dificultar la elección y/o instalación de dispositivos de control. Los diferentes buses de campo pueden clasificarse en tres grupos: (1) buses de sensor, utilizados para la comunicación con y entre diferentes tipos de sensores, pulsadores, etc. (Ej: AS-I, Seriplex). (2) buses de dispositivo, diseñados para dispositivos más complejos, y que manejan un mayor flujo de información. (Ej: Profibus DP, LonWorks, Interbus). (3) buses de campo propiamente dichos, los más apropiados para las plantas de proceso. Se emplean en sistemas control y diagnóstico. (Ej: FieldBUS, Profibus PA, Device Net, World FIP). En un futuro no demasiado lejano se espera poder utilizar redes Ethernet para la construcción de este tipo de buses. La información relativa a estos y otros sistemas puede encontrarse en [ProfiBUS, 2005], [AS Interface, 2005], [Seriplex, 2005], [LonWorks, 2005], [InterBUS, 2005], [FieldBUS, 2005], [DeviceNet, 2005], [World FIP, 2005], [ControlNet, 2005] y [CAN, 2005]. Nivel de control. Se emplean diferentes protocolos, generalmente basados en Ethernet. Los más utilizados son ControlNet, Profinet, FielBUS HSE, Modbus. También se usan otros protocolos no basados en Ethernet, como CAN. Nivel de negocio o red de información. Típicamente se emplea TCP/IP sobre Ethernet Interfaces de usuario Los operadores supervisan y controlan el sistema a través de las interfaces de usuario o HMI (Human Machine Interfaces). En estas interfaces se muestran alarmas y se controlan los procedimientos para responder a ellas; se presentan informes, históricos del proceso, tendencias y valores medios; se puede manipular el estado del proceso y cambiar los puntos

26 26 CAPÍTULO 2. SISTEMAS DE CONTROL de funcionamiento; gestionar la instalación y configuración remota de software, y una gran variedad de operaciones más. El nivel de detalle de las interfaces de usuario es muy variable, existiendo tanto interfaces consistentes únicamente en displays LCD o leds de 7 segmentos y algunos pulsadores, como interfaces gráficas de gran complejidad. El tiempo de refresco de la información en estas interfaces también varía desde fracciones de segundo, a minutos. Suele recomendarse un mínimo de dos estaciones de operación, por razones de seguridad (una de ellas puede fallar) y de mantenimiento (una de ellas puede dedicarse a mantenimiento mientras la otra opera sobre el proceso). Se recomiendan tres estaciones, las cuales se usan de la siguiente manera: en una el operador supervisa el funcionamiento general del sistema, en la segunda se muestra una vista detallada del funcionamiento de algún componente o subsistema, y la tercera se usa para mostrar alarmas Bases de datos El uso de una base de datos para almacenar datos históricos del proceso es casi obligado en la mayoría de los sistemas de control actuales. La información de dicha base de datos es utilizada a varios niveles del sistema, tanto para control, como para gestión y elaboración de estrategias de producción, por ejemplo. Además del soporte de almacenamiento necesario para los datos registrados, la base de datos suele contener también imágenes del sistema (configuraciones del mismo en determinados instantes), información de diagnósticos, software de usuario o de los dispositivos de la planta, etc Sistemas de control distribuido Un sistema distribuido puede definirse como un sistema formado por múltiples procesadores y recursos independientes, que cooperan para realizar tareas, intercambiando información a través de algún tipo de red de comunicación. En la figura 2.2 puede verse una representación de un sistema distribuido general, en el cual podemos encontrar ordenadores personales o terminales, servidores, clústers, memorias compartidas, y diferentes tipos de redes de comunicación. En un sistema distribuido encontramos que los componentes que lo forman están separados en vez de encontrarse agrupados en una única entidad. Estos elementos pueden estar separados físicamente, es decir, que están instalados en ubicaciones más o menos distantes entre sí, y también pueden estar separados de forma lógica, en cuyo caso dos elementos de software por ejemplo, funcionan en la misma máquina pero son completamente independientes el uno del otro. Una característica destacable de estos sistemas es que desde el punto de vista de la funcionalidad o de los usuarios, aparentan ser un único sistema centralizado; es decir, la heterogeneidad y separación de los componentes del sistema permanece oculta. Cuando un sistema distribuido se utiliza para controlar otro sistema, hablamos de un sistema de control distribuido, o DCS (Distributed Control System). Estos sistemas han supuesto