corba: una plataforma software para los sistemas de control del futuro

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 ·