Sección Española _________________________________________________________________________________________ CORBA: UNA PLATAFORMA SOFTWARE PARA LOS SISTEMAS DE CONTROL DEL FUTURO M. RODRÍGUEZ, R. SANZ, S. GALÁN, C. GARCÍA, R. CHINCHILLA Y A.YELA AUTONOMOUS SYSTEMS LABORATORY / UNIVERSIDAD POLITÉCNICA MADRID _________________________________________________________________________________________ RESUMEN Los sistemas de control industrial son, en su mayoría, aplicaciones software de elevada complejidad. Tradicionalmente un reducto de tecnologías propietarias, la ingeniería de sistemas de control está sufriendo una progresiva inmersión en el mundo de los sistemas abiertos y las tecnologías estandarizadas. Este artículo presenta la tecnología CORBA y muestra cómo ésta ofrece una plataforma adecuada para la construcción, integración y evolución de los sistemas de control actuales y futuros. El artículo describe también, sumariamente, algunas de las actividades actuales en I+D en este campo. 1. INTRODUCCIÓN La complejidad de los sistemas de control que podemos encontrar actualmente en una planta de proceso crece continuamente. De los sistemas monolíticos del pasado hemos pasado en poco tiempo a sistemas compuestos por miles de elementos hardware y software que interactúan de múltiples formas realizando funciones diversas mucho mas allá del simple bucle de control. Con la aparición de los sensores y actuadores inteligentes, los computadores alcanzan el nivel más bajo del sistema, haciendo de la planta un único sistema distribuido. Distribuido no en el sentido tradicional en el mundo del control de procesos, sino en el sentido de las redes informáticas, donde diferentes tareas individuales se ejecutan en diferentes procesadores —PLCs, interfaces, ordenadores, etc— para realizar una tarea global mediante el flujo de información través de las conexiones que los unen a diferentes niveles. Debido a los diferentes tipos de requisitos y a la escasa disponibilidad de tecnologías de amplio espectro, las redes de los sistemas de control se han dividido tradicionalmente en tres niveles: 1. 2. 3. Red de campo, donde se sitúan los sensores, actuadores y elementos del control regulatorio elemental. La red es aquí típicamente un bus de campo. Red de control de procesos, incluyendo el control avanzado, supervisión y optimización local. Hasta muy recientemente usando redes propietarias y en la actualidad sobre red Ethernet. Sistema de información de empresa, donde se encuentran la optimización global, planificación y scheduling. Empleando redes corporativas convencionales. Las implementaciones han ido evolucionando hacia un incremento de la distribución de las tareas en los múltiples agentes y al aumento de la disponibilidad y densidad del tráfico de datos, creciendo la versatilidad y las posibilidades de los sistemas de control que se han convertido en sistemas de gestión en tiempo real —en el más amplio sentido del término. La consecuencia, aún no del todo comprendida en algunos entornos del sector, es que los sistemas de control ya no son lo que eran —agrupaciones de subunidades hardware/software monolíticas— y que este cambio se va a acentuar en el futuro: ·1· Sección Española MIS Safety Enterprise Network Business Managem Data Storage Process Control Process Operation Control Network Process Managem Field Configuration Fieldbus Sensing and Acting Field Manageme Continuous Process Pla Figura 1: Los sistemas de control industrial son aplicaciones informáticas complejas sobre redes y plataformas de cómputo heterogéneas. Las redes y el software distribuido invaden y potencian la funcionalidad de todos los elementos de la plantas de proceso, Se estima que la tecnología Ethernet —posiblemente con algún cambio menor— y la tecnología de objetos software distribuidos serán capaces de cubrir prácticamente las necesidades de todos los niveles, desde el campo hasta el sistema de información, de forma económica. Los sistemas de control son, cada vez más, sistemas informáticos con las ventajas e inconvenientes que ello conlleva. El concepto de sistema abierto basado en estándares públicos es atractivo para las plantas, a la vez que despierta cautelas en un campo necesariamente conservador que requiere un servicio fiable de suministradores que tradicionalmente se han orientado a sistemas propietarios y encapsulados, en los que es mas fácil realizar procesos de prueba sistemáticos. Los cambios que se están produciendo en el control de aeronaves y la revolución que viene en los automóviles, repercutirán en poco tiempo en los sistemas de control de plantas de proceso. Uno de estos cambios procede de las tecnologías software de objetos distribuidos de tiempo real. 2. 2.1. CORBA EN SISTEMAS DE CONTROL ¿QUÉ ES CORBA? CORBA es un acrónimo que significa Common Object Request Broker Arquitecture. CORBA es la especificación de una arquitectura software basada en un mecanismo intermediario de comunicación: el broker., CORBA define una infraestructura que, una vez implementada, permite que diferentes componentes de una aplicación informática compleja, posiblemente realizados en diferentes lenguajes y ejecutados en distintas plataformas con diferentes sistemas operativos, se comuniquen y trabajen conjuntamente de forma transparente sobre redes de comunicación heterogéneas. CORBA permite homogeneizar lo heterogéneo de forma eficaz. Podemos tener sensores inteligentes con software empotrado sobre un sistema operativo de tiempo real, interaccionando con un control predictivo sobre UNIX , interfases de operador sobre Windows NT y bases de ·2· Sección Española datos corporativas sobre mainframes de IBM. Todo ello se realiza de forma transparente. Esto significa que al control no le importa si la base de datos es Sybase u Oracle, si corre sobre UNIX o S390, o si está escrita en C++ o Fortran. La transparencia que CORBA proporciona (localización. plataforma, lenguaje, protocolo) es una de las claves para romper el nudo de la complejidad de las aplicaciones. La arquitectura desarrollada por el OMG (Object Mangement Group) es abierta e independiente y fue diseñada con los siguientes objetivos: orientación a objetos, transparencia de localización, independiencia de un lenguaje de programación e interoperabilidad. El modelo OMA (Object Management Architecture) definido por el Object Management Group estructura los componentes de la aplicación en cuatro grandes categorías en función de el nivel de reusabilidad de los mismos (Ver Figura 2): • • • • Horizontal Facilities, utilizables como servicios completos en un amplio rango de aplicaciones. Common Object Services, utilizables como bloques elementales de construcción de aplicaciones ofrecen servicios preconstruidos garantizados que simplifican e desarrollo de aplicaciones complejas. Domain Facilities, que proporcionan componentes reutilizables en un dominio concreto de aplicación (por ejemplo procesos continuo, fabricación discreta, aviónica o sistemas médicos) Application Specific Objects: Objetos especialmente construidos para una aplicación concreta. CORBA proporciona a los desarrolladores un middleware flexible que permite integrar aplicaciones complejas en entornos heterogéneos. Originalmente diseñada para su empleo en aplicaciones de gestión y negocio, ha evolucionado para cumplir con los requisitos que demandan las aplicaciones de control, convirtiéndose en la especificación de referencia en el ámbito del software distribuido de tiempo real.. El continuo desarrollo de nuevas especificaciones hacen que, cada día más, CORBA pase a ser la herramienta mas útil para la integración de grandes sistemas de control distribuido. Application Specific Objects Horizontal Facilities Input Method MOF Vertical (domain) facilities Repositories Medical Internationalization Business Manufacturing E-Commerce Object Request Broker Naming Persistence Concurrency Transaction Query Security Trader Event Time Common Object Services Figura 2: El modelo OMA (Object Management Architecture) definido por el Object Management Group estructura los components de la aplicacion en tres grandes categories en función de el nivel de reutilizacion de los mismos: Horizontal Facilities, Common Object Services and Domain Facilities. ·3· Sección Española Una de las especificaciones mas necesarias para hacerla apta en el aplicaciones de control de procesos es la extensión a tiempo real. La especificaciones disponibles de Real-time CORBA proporcionan mecanismos para aumentar la predecibilidad temporal de las aplicaciones (prioridades similares a las prioridades nativas de los sistemas operativos, planificación dinámica, conexiones pre-establecidas, etc.). Estos recursos permiten desarrollar aplicaciones de tiempo real si los requisitos temporales son no-estrictos. Este tipo de sistemas plantea necesidades que son objeto de investigación, desarrollo y especificación; por ejemplo: • • • 2.2. Protocolos de comunicación de tiempo real Servicio de planificación con reconfiguración dinámica Especificación de aspectos temporales en la interfase de los objetos ¿QUE HACE UNA APLICACIÓN CORBA? En la aplicación CORBA mas elemental, un objeto —el cliente— demanda un servicio a otro objeto —el servidor. Tanto el cliente como el servidor pueden estar programados en cualquier lenguaje de programación1 y ser ejecutados en cualquier ordenador. El único requisito es la conectividad de ambos mediante uno de los protocolos de interoperabilidad de CORBA. Client Server Server Stub Client Stub ORB Figura 3: Interacción entre cliente y servidor en un ambiente CORBA. El ORB actúa de intermediario en todas las interacciones. Los stubs – adaptadores- de cliente y servidor realizan el formateo de los datos a una codificación neutral de red. La prestación del servicio en un ambiente CORBA —y de forma similar en cualquier ambiente basado en brokers— se produce por medio de la intermediación del pseudoobjeto denominado ORB (Object Request Broker). El proceso es relativamente simple: 1. 2. El cliente le comunica al broker su deseo de solicitar un determinado servicio de un determinado servidor El broker localiza al servidor y le hace llegar la petición de servicio del cliente 1 CORBA soporta en la actualidad mas de veinte lenguajes de programacion diferentes por medio de mapeos estandarizados y no estandarizados. ·4· Sección Española 3. 4. 5. El servidor atiende la petición (por ejemplo una consulta a una base de datos) El servidor le comunica al broker el resultado El broker hace llegar el resultado al cliente. Se produce un incremento de complejidad del sistema y del tiempo empleado en atender el servicio para obtener a cambio la transparencia deseada (localización, lenguaje, plataforma). Sin embargo, desde el punto de vista del cliente la interfaz con el servicio es tan simple como en un sistema co-ubicado. CORBA consigue que la petición de servicios remotos sea tan simple como la petición de servicios locales a la aplicación. CORBA se ha aplicado con éxito en múltiples aplicaciones de gestión y también en aplicaciones técnicas. Salvo en nichos homogéneos como son los entornos puramente Microsoft Windows y las aplicaciones web basadas en tecnologías como Java y XML, la tecnología de elección es CORBA. Es en el ámbito de los sistemas de control distribuido en particular donde CORBA ha obtenido más arraigo; este es el caso de los sistemas de telecomunicaciones o de los sistemas militares en los que esta tecnología es la más común. En el ámbito de las aplicaciones industriales, sin embargo, la tecnología CORBA todavía no ha arraigado debido al uso de tecnologías propietarias y a la doctrina básica en la industria de “si no está roto, no lo arregles”. Es nuestro propósito, con este artículo, el dar a conocer esta tecnología en este ámbito, porque consideramos que ofrece ventajas sustanciales frente a otras como Java o .NET. 2.3. CORBA EN CONTROL DE PROCESOS En el mundo del control de procesos CORBA se ha empleado de forma experimental en muchos proyectos de investigación y algunos fabricantes de sistemas de control distribuido lo han venido empleado en subsistemas (principalmente en sistemas de fabricación). En el ámbito del control de procesos continuos, la principal barrera existente a la introducción de CORBA es la reducida tasa de actualización tecnológica de estas industrias y al hecho de que los fabricantes de sistemas de automatización tratan de mantener mercados cautivos mediante el uso de tecnologías propietarias. Afortunadamente, esto está cambiando y, cada día más, los responsables de las plantas industriales plantean el sometimiento a estándares internacionales como uno de los requisitos básicos de los sistemas de nueva construcción. En la sección 4 de este artículo describiremos algunos de los desarrollos hechos por nuestro grupo de trabajo dentro de la línea de investigación en CORBA para control de procesos. 2.4. CORBA VS. OPC OPC (OLE for Process Control) es una tecnología que se ha aceptado como un estándar de hecho por los fabricantes de equipos de control en la industria. Se origina en el mundo de Windows NT y facilita la comunicación de datos de “tiempo real” de variables, alarmas y eventos, así como el acceso a registros históricos entre equipos de distintos fabricantes. En el mundo del control de procesos, por falta de conocimiento sobre ambas tecnologías, algunas personas piensan que CORBA es una posible alternativa a OPC. En realidad OPC es un servicio que históricamente ha estado ligado a COM (Component Object Model, de Microsoft), pero que puede ser implementado sobre CORBA, que es la tecnología middleware que compite con DCOM o Java/RMI. De hecho, la OMG ha desarrollado dos especificaciones (DAIS/HDAIS) que permiten sustituir, con mejoras, a servidores OPC. Desde este punto de vista, la comparación no se puede hacer entre CORBA y OPC, sino entre CORBA y COM. Y aquí CORBA presenta ventajas para los sistemas de control, ya que considera aspectos como la tolerancia a fallos o la operación en tiempo real, que no están presentes por ahora en COM. También hay especificaciones de CORBA para sensores inteligentes. ·5· Sección Española OPC supone una estructura de cliente/servidor (también ofrece servicios de suscripción) en la que los objetivos planteados han tenido y mantienen un alcance limitado. Por ejemplo, hasta no hace mucho, con la aparición de la especificación de Data eXchange, los servidores no podían configurarse remotamente con el mismo mecanismo con el que se accedía a los datos, debiendo cada fabricante suministrar su aplicación de configuración propietaria. Por otro lado, OPC está apostando por el uso de XML. En definitiva, si OPC supone un estándar abierto para la comunicación de datos en sistemas de control, lo que es ciertamente beneficioso, su campo de aplicación es muy reducido comparado con el abanico de tecnologías, sobre las que se monta OPC, que están configurando el futuro de los sistemas de control y sus posibilidades. 3. 3.1. TECNOLOGIA CORBA CORBA COMO PLATAFORMA DE DISTRIBUCION E INTEGRACION CORBA ofrece la posibilidad de construir mecanismos de integración de sistemas distribuidos por medio de dos especificaciones fundamentales: • • Interface Definition Language (IDL) General Inter-ORB Protocol (GIOP) El lenguaje de especificación de interfases (IDL) permite definir de una forma neutral los servicios que un servidor CORBA ofrece. A partir de la especificación IDL, los compiladores generan código en el lenguaje de programación elegido por los desarrolladores. Esto nos ha permitido, por ejemplo, el especificar la interfase de una base de datos de proceso de AspenTech mediante IDL y generar código en C y C++ para interaccionar con dicha base de datos cuando el fabricante solo proporciona un API local en C. De esta forma hemos podido acceder desde cualquier punto de la red del complejo químico de Repsol en Tarragona, a datos de la planta almacenados en la base de datos de proceso. El protocolo de interoperabilidad es el que permite que los servicios sean pedidos entra plataformas heterogéneas. Solo es necesario disponer del mismo protocolo en ambas plataformas para poder ofrecer la conectividad cliente-servidor necesaria. La implementación más común del protocolo general GIOP es la denominada Internet Inter-ORB Protocol (IIOP). Ésta es una implementación de GIOP sobre los protocolos básicos de Internet (TCP/IP). Aunque un servidor CORBA puede ser una aplicación muy compleja, la funcionalidad básica se reduce a ser capaza de hablar el protocolo de interoperabilidad. Existen implementaciones de librería de IIOP que requieren menos de 20KB de memoria, lo que permite distribuir objetos CORBA incluso en plataformas con recursos escasos (por ejemplo sensores inteligentes). 3.2. CORBA PARA SISTEMAS DE CONTROL La especificación de CORBA de tiempo real surge de las esfuerzos de la OMG por adaptar sus especificaciones para su uso en sistemas distribuidos de tiempo real. Algunas de las especificaciones de relevancia para este ámbito de aplicación son: Minimum CORBA Specification. Este es un perfil de la especificación CORBA básica para su uso en sistemas de bajos recursos. Básicamente, esta especificación elimina las partes de la especificación CORBA que tienen poca utilidad en sistemas que están perfectamente especificados en la etapa de ·6· Sección Española diseño. Todas las partes relativas a la invocación dinámica de servicios y los almacenes de información en caliente se eliminan (para ser mas precisos, no se requieren de implementaciones que reclamen ajustarse a la especificación de Minimum CORBA). Real-Time CORBA Specification. Esta especificación añade característica nuevas a la especificación CORBA estándar para aumentar el control de los recursos con el fin de mejorar la predecibilidad extremo-a-extremo2. Esta especificación reutiliza conceptos de otras especificaciones (por ejemplo el marco de calidad de servicio de la especificación de Messaging o el concepto de tiempo de la especificación Enhanced Time. Fault-Tolerant CORBA Specification. En el ámbito de los sistemas de tiempo real hay muchas aplicaciones que precisan de elevados niveles de tolerancia a fallos. Esta especificación define los servicios de la infraestructura CORBA básica que un aplicación puede necesitar para conseguir dicha tolerancia a fallos. La especificación soporta diversas estrategias de tolerancia a fallos como reintentos de peticiones, redirecciones a servidores alternativas o redundancia tanto pasiva como activa de los objetos servidores. Especificaciones de dominio: hay muchas especificaciones en dominios concretos que son de interés para los ingenieros de control. DAIS/HDAIS (Historical Data Access for Industrial Systems) permite implementar sistemas que ofrecen los mecanismos que OPC ofrece. DDS (Data Distribution Service for Real-Time Systems) permite optimizar el flujo masivo de datos entre sistemas de captura de datos y clientes distribuidos. CCM (CORBA Component Model) y Lightweigh CCM permiten simplificar el despliegue y la gestión de aplicaciones complejas basada en objetos CORBA. La especificación de Smart Transducers introduce mecanismos para la gestión de sensores y actuadores muy empotrados y también clusters de los mismos. 4. ACTIVIDADES DE INVESTIGACION Nuestro grupo de investigación (www.aslab.org) mantiene una línea de investigación sobre el uso de la tecnología CORBA en la construcción de aplicaciones complejas de control de procesos industriales continuos. La idea de usar esta tecnología surge de la necesidad de integrar aplicaciones heterogéneas en sistemas de control distribuido. La tecnología CORBA ha evolucionado durante estos años y en la actualidad ofrece soluciones para prácticamente todos los problemas de integración industrial. 4.1. CONTROL ESTRATÉGICO DE PLANTAS INDUSTRIALES Los sistemas PIKMAC y RISKMAN fueron desarrollados dentro del proyecto DIXIT financiado por la Comisión Europea. El objetivo del proyecto es el desarrollo de tecnología de integración de aplicaciones para el control estratégico de grandes procesos industriales. PIKMAC es un sistema de soporte a la operación estratégica de plantas de cemento. Fue desarrollado para la planta de Contes (Francia) de Lafarge Ciments. El objetivo del sistema es dar soporte al operador humano sobre todo durante los turnos nocturnos y de fin de semana en que era la única persona en la planta. 2 Esto quiere decir predecibilidad en toda la cadena de subsistemas desde el cliente hasta el servidor: Cliente—Middleware—SO—Red— SO—Middleware—Servidor. ·7· Sección Española Figura 4: Vision general del sistema PIKMAC mostrando los diferentes objetos CORBA que lo componen. El Broker ICa es un producto de la empresa española SCILabs (www.scilabs.es) El sistema PIKMAC integra: • • • • • • • • Sistema de control distribuido Base de datos de proceso Base de datos de control de incidentes Laboratorios robotizados Sistemas expertos en diagnosis y gestión de incidentes Modelos matemáticos de costes instantáneos Redes neuronales de predicción de calidad Interfases de usuario Todos ellos son objetos CORBA corriendo sobre una red de computadores con Digital UNIX y Windows NT. El sistema RISKMAN (Ver Figura 5) es un sistema similar en estructura. Su misión es dar soporte a la gestión de emergencias en el complejo químico de Repsol en Tarragona. En este caso los objetos corrían sobre Digital Figura 5: Parte principal de la interfase de usuario del sistema RISKMAN. ·8· Sección Española UNIX, VMS, Windows NT e incluso DOS. 4.2. CORBA EN CONTROL EMPOTRADO Nuestras actividades recientes se han centrado en conseguir aplicar la tecnología de forma integral (una sola tecnología de integración para toda la planta) dentro de un objetivo que denominamos TotalIntegration. Esto nos lleva a evaluar la tecnología y a colaborar en las propuestas de modificación de las especificaciones de la OMG para hacerlas adecuadas a nuestros necesidades. En dos proyectos recientes, DOTS (Distributed Objects Telecontrol Systems and Networks) y HRTC (Hard Real-time CORBA) se ha llevado la tecnología hasta el nivel de los sistemas empotrados. En DOTS se ha aplicado CORBA a la implementación de sistemas de protección de subestaciones de Red Eléctrica de España, demostrando que esta tecnología permite no solo la implementación de dichos sistemas (siguiendo el estándar emergente IEC 61850) sino que ofrece mecanismos para conseguir comportamiento sofisticados, como el reemplazo en caliente de RTUs (Remote Terminal Units) y la reconfiguración dinámica de los sistemas de objetos. En el proyecto HRTC se ha empleado CORBA en la implementación de dos sistemas de control: un proceso continuo y un robot. El objetivo del proyecto es estudiar la adecuación de la tecnología para cerrar bucles de control y no simplemente como mecanismo de manejo de datos en sistemas de monitorización. En este proyecto se han desarrollado además dos transportes nuevos de predecibilidad aumentada respecto al clásico IIOP: uno sobre redes TTP y otro sobre Ethernet con control de flujo. HMI Controller Database Ethernet Network GUS TPS Sensor Actuator Sensor Actuator PROCESS PLANT Figura 6: Uno de los experimentos del proyecto HRTC tenía como objetivo la evaluacion de la tecnología CORBA para implementar un sistema de control que encapsulaba un TDC 300 de Honeywell en un objeto CORBA. ·9· Sección Española 5. CONCLUSIONES CORBA es una tecnología adecuada para implementar sistemas distribuidos y en particular es muy adecuada para la implementación de sistemas distribuidos de control porque simplifica el proceso de diseño, construcción, despliegue y mantenimiento cuando las aplicaciones superan un nivel mínimo de complejidad. CORBA es una tecnología que aunque todavía no está completamente adecuada para resolver todas las necesidades que plantea el control de plantas de proceso, posee una serie de características que la hacen ya directamente aplicable en diversas partes de la pirámide de control. CORBA está evolucionando, principalmente gracias a las especificaciones de tiempo real, a ser una tecnología decisiva en cualquier proceso de automatización. CORBA no compite directamente con OPC (aunque posee sus propias especificaciones para el acceso a datos de proceso y datos históricos) sino con los servicios que están debajo de OPC (COM/DCOM). Se puede incluso tener un sistema con OPC funcionando sobre CORBA. En definitiva este artículo ha pretendido mostrar una tecnología, CORBA, en desarrollo y cómo esta puede ser aplicable y útil en el sector de procesos continuos en diferentes etapas de la vida de un proceso. REFERENCIAS [Adler 95] Richard M. Adler, Emerging Standards for Component Software. IEEE Computer, March 1995. [Brugali 98] David Brugali. From Objects to Agents: Software Reuse for Distributed Systems. PhD Thesis. Politecnico di Torino, 1998. [Davidson 1994] John B. Davidson and David K. Schmidt. Extended Cooperative Control Synthesis. NASA Technical Memorandum 4561. 1994. [Fischer 94] Fischer, G. Domain-Oriented Design Environments. Automated Software Engineering, Vol. 1 No. 2, pp. 177-203, 1994. [Jalote 94] Pankaj Jalote. Fault Tolerance in Distributed Systems. Prentice-Hall, 1994. [Jennings 94] N.R. Jennings. Cooperation in Industrial Multi-Agent Systems. World Scientific, 1994. [Maffeis 97] S. Maffeis and D.C. Schmidt. Constructing Reliable Distributed Communication Systems with CORBA. IEEE Comunications Magazine, Vol. 14, No.2. 1997. [OMG 96] An Overview of the OMA. Object management Group. [OMG 96] Realtime CORBA. A White Paper. OMG Realtime SIG. Object Management Group, 1996. [OMG 04] Common Object Request Broker Architecture and Specification, Ver. 3.0.3. OMG Document Number formal/04-03-01. Object Management Group, 2004. Esta es la especificación más reciente de CORBA. [OMG 02] Real-Time CORBA. OMG Document Number formal/02-08-02, Object Management Group, Needham, MA, U.S.A., 2002. [OMG02a] Enhanced View of Time V1.1. Available Specification Document Number formal/2002-0507, Object Management Group, Needham, MA, U.S.A., May 2002. Available at http://doc.omg.org/formal/2002-05-07. · 10 · Sección Española [OMG 02b] Fault Tolerant CORBA. Available Specification Document Number formal/2002-06-59, Object Management Group, Needham, MA, U.S.A., May 2002. Available at http://doc.omg.org/formal/2002-06-59. [OMG 03a] Extensible Transport Framework. Revised Submission Document Number mars/2003-02-01, Object Management Group, Needham, MA, U.S.A., March 3, 2003. Available at http://doc.omg.org/mars/2003-02-01. [OMG 03b] Data Distribution Service submission. Joint Submission Document Number mars/2003-0316, Object Management Group, Needham, MA, U.S.A., March, 2003. Available at http://doc.omg.org/mars/2003-03-16. [OMG 03c] Smart Transducers Interface V1.0. Available Specification Document Number formal/200301-01, Object Management Group, Needham, MA, U.S.A., January 2003. Available at http://doc.omg.org/formal/2003-01-01. [Otte 96] Randy Otte, Paul Patrick and Mark Roy. Understanding CORBA. Prentice Hall PTR. 1996. [Samad 00] Samad, Tariq and Weyrauch, John, Eds. (2000). Automation, Control, and Complexity: New Developments and Directions. John Wiley and Sons. Chichester, UK. [Samad 98] Samad, Tariq (1998). Complexity management: Multidisciplinary perspectives on automation and control. Technical Report CON-R98-001. Honeywell Technology Center. Minneapolis, USA. [Sanz 00] Sanz, Ricardo (2000). Agents for complex control systems. Chap. 10, pp. 171–190. In: Samad and Weyrauch (2000). [Sanz 91] Sanz, R., A.Jiménez, R.Galán, F.Matía and E.A.Puente. Intelligent Process Control: The CONEX Architecture. In Engineering Systems with Intelligence. S. Tzafestas (Ed.). Kluwer Academic Publishers, 1991. [Sanz 94] Sanz, R., R.Galán, A.Jiménez, F.Matía, J.Velasco and G.Martínez. Computational Intelligence in Process Control. ICNN'94, IEEE International Conference in Neural Networks. Orlando, USA, 1994. [Sanz 96] Sanz, R., F.Matía, R.Galán and A. Jiménez. Integration of Fuzzy Technology in Complex Process Control Systems. FLAMOC'96. Sydney, Australia, 1996. [Sanz 99a] Sanz, Ricardo, Idoia Alarcón, Miguel J. Segarra, Angel de Antonio and José A. Clavijo (1999a). Progressive domain focalization in intelligent control systems. Control Engineering Practice 7(5), 665–671. [Sanz 99b] Sanz, Ricardo, Miguel J. Segarra, Angel de Antonio and José A. Clavijo (1999b). ICa: Middleware for intelligent process control. In: IEEE International Symposium on Intelligent Control, ISIC’1999. Cambridge, USA. [Sanz 03] Sanz, Ricardo and Janusz Zalewsky. Control Engineering using Design Patterns. IEEE Control Systems Magazine, June 2003. [Selic 94] Bran Selic, Garth Gullekson and Paul T. Ward. Real-Time Object Oriented Modelling. Wiley, 1994. Todas las especificaciones del OMG son públicas y de pueden descargar desde la página web: http://www.omg.org/technology/documents/index.htm · 11 ·