Versión RT-CORBA del servidor Pioneer 2AT-8.

Version RT-CORBA del servidorPioneer 2AT-8

Adolfo Hernando MarcosETSII — UPM

31 de octubre de 2005

III

Agradecimientos

A mi abuela Ursula, que desde que se ha ido me ha dejado un gran vacıo.A mi padre por su tenacidad. A mi madre y a mi hermana por su paciencia.A mi profesor Ricardo Sanz, por haber confiado en mı y por lo que meha ensenado como profesor y como persona. Y a todos los companeros deldepartamento, gracias por su amistad.

Indice general

I Introduccion y objetivos 1

1. Introduccion y objetivos 31.1. Introduccion . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31.2. Contexto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

1.2.1. Arquitectura de Control Integrado . . . . . . . . . . . 51.2.2. Caracterısticas . . . . . . . . . . . . . . . . . . . . . . 71.2.3. Disponibilidad . . . . . . . . . . . . . . . . . . . . . . . 81.2.4. Otros proyectos . . . . . . . . . . . . . . . . . . . . . . 8

1.3. Tecnologıas empleadas . . . . . . . . . . . . . . . . . . . . . . 91.4. Necesidades y requisitos . . . . . . . . . . . . . . . . . . . . . 91.5. Estructura de la memoria . . . . . . . . . . . . . . . . . . . . 9

II Sistemas de control 11

2. Sistemas de control industrial 132.1. Introduccion . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132.2. Evolucion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142.3. Descripcion de un sistema moderno . . . . . . . . . . . . . . . 142.4. Caracterısticas generales . . . . . . . . . . . . . . . . . . . . . 18

2.4.1. Confiabilidad . . . . . . . . . . . . . . . . . . . . . . . 182.4.2. Mantenibilidad . . . . . . . . . . . . . . . . . . . . . . 192.4.3. Escalabilidad . . . . . . . . . . . . . . . . . . . . . . . 192.4.4. Configurabilidad . . . . . . . . . . . . . . . . . . . . . 19

2.5. Niveles de un sistema de control . . . . . . . . . . . . . . . . . 192.6. Transmisiones de datos . . . . . . . . . . . . . . . . . . . . . . 202.7. Funciones caracterısticas . . . . . . . . . . . . . . . . . . . . . 21

2.7.1. Adquisicion de datos . . . . . . . . . . . . . . . . . . . 212.7.2. Alarmas . . . . . . . . . . . . . . . . . . . . . . . . . . 212.7.3. Control . . . . . . . . . . . . . . . . . . . . . . . . . . 222.7.4. Seguridad . . . . . . . . . . . . . . . . . . . . . . . . . 23

V

VI INDICE GENERAL

2.7.5. Comunicacion con otros sistemas . . . . . . . . . . . . 232.7.6. Generacion de informes . . . . . . . . . . . . . . . . . . 23

2.8. Elementos del control de procesos . . . . . . . . . . . . . . . . 242.8.1. Sensores . . . . . . . . . . . . . . . . . . . . . . . . . . 242.8.2. Actuadores . . . . . . . . . . . . . . . . . . . . . . . . 252.8.3. Controladores . . . . . . . . . . . . . . . . . . . . . . . 252.8.4. Sistemas de comunicacion . . . . . . . . . . . . . . . . 252.8.5. Interfaces de usuario . . . . . . . . . . . . . . . . . . . 262.8.6. Bases de datos . . . . . . . . . . . . . . . . . . . . . . 27

3. Sistemas de control distribuido 293.1. Requisitos y caracterısticas . . . . . . . . . . . . . . . . . . . . 313.2. DCS en el ambito industrial . . . . . . . . . . . . . . . . . . . 343.3. Distributed Object Computing(DOC) . . . . . . . . . . . . . . 36

3.3.1. Objetos locales y objetos distribuidos . . . . . . . . . . 363.3.2. Generalizacion del modelo cliente servidor . . . . . . . 363.3.3. Elementos de la DOC . . . . . . . . . . . . . . . . . . . 373.3.4. Beneficios de la DOC . . . . . . . . . . . . . . . . . . . 38

3.4. Definicion de Middleware . . . . . . . . . . . . . . . . . . . . . 393.5. Funcionamiento de un middleware . . . . . . . . . . . . . . . . 413.6. Taxonomıa del Middleware . . . . . . . . . . . . . . . . . . . . 43

3.6.1. Transaccion-Processing Monitor (TPM) Middleware . . 443.6.2. Llamadas a Procedimientos Remotos (RPC) . . . . . . 463.6.3. Middleware Orientado a Mensajes . . . . . . . . . . . . 483.6.4. Middleware Orientado a Objetos y Componentes . . . 503.6.5. COM y DCOM . . . . . . . . . . . . . . . . . . . . . . 533.6.6. RMI . . . . . . . . . . . . . . . . . . . . . . . . . . . . 553.6.7. CORBA . . . . . . . . . . . . . . . . . . . . . . . . . . 59

4. Sistemas de tiempo real 614.1. Aplicaciones de los sistemas de tiempo real . . . . . . . . . . . 62

4.1.1. Control de procesos . . . . . . . . . . . . . . . . . . . . 624.1.2. Fabricacion . . . . . . . . . . . . . . . . . . . . . . . . 634.1.3. Comunicaciones y control . . . . . . . . . . . . . . . . 63

4.2. Caracterısticas de los sistemas de tiempo real . . . . . . . . . 634.3. Tiempo real duro y blando . . . . . . . . . . . . . . . . . . . . 644.4. Restricciones de tiempo . . . . . . . . . . . . . . . . . . . . . . 654.5. Predecibilidad . . . . . . . . . . . . . . . . . . . . . . . . . . . 664.6. Planificacion . . . . . . . . . . . . . . . . . . . . . . . . . . . . 664.7. Sincronizacion . . . . . . . . . . . . . . . . . . . . . . . . . . . 674.8. Temporizadores . . . . . . . . . . . . . . . . . . . . . . . . . . 68

INDICE GENERAL VII

4.9. Bloqueo de memoria . . . . . . . . . . . . . . . . . . . . . . . 69

5. Sistemas de control de robots 715.1. Sensores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 715.2. Navegacion . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72

5.2.1. Odometrıa inherente a la plataforma . . . . . . . . . . 725.2.2. Encoders . . . . . . . . . . . . . . . . . . . . . . . . . . 73

5.3. Integracion . . . . . . . . . . . . . . . . . . . . . . . . . . . . 745.4. Multiples Robots . . . . . . . . . . . . . . . . . . . . . . . . . 755.5. Ejemplos de sistemas de control de robots . . . . . . . . . . . . 76

5.5.1. OROCOS . . . . . . . . . . . . . . . . . . . . . . . . . 765.5.2. CARMEN . . . . . . . . . . . . . . . . . . . . . . . . . 785.5.3. Scene . . . . . . . . . . . . . . . . . . . . . . . . . . . . 785.5.4. Pyro AI and Robotics System . . . . . . . . . . . . . . 785.5.5. Dave’s Robotic Operating System (DROS) . . . . . . . 805.5.6. FLEXnav . . . . . . . . . . . . . . . . . . . . . . . . . 815.5.7. Orca . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82

III CORBA 83

6. CORBA 856.1. El Object Management Group . . . . . . . . . . . . . . . . . . 85

6.1.1. Descripcion y objetivos . . . . . . . . . . . . . . . . . . 856.1.2. Estructura y actividades . . . . . . . . . . . . . . . . . 866.1.3. Resumen de especificaciones . . . . . . . . . . . . . . . 86

6.2. Especificaciones del OMG . . . . . . . . . . . . . . . . . . . . 886.2.1. Object Management Architecture (OMA) . . . . . . . 906.2.2. Especificaciones de CORBA/IIOP . . . . . . . . . . . . 916.2.3. Lenguaje IDL . . . . . . . . . . . . . . . . . . . . . . . 916.2.4. Especificaciones especiales . . . . . . . . . . . . . . . . 916.2.5. Servicios . . . . . . . . . . . . . . . . . . . . . . . . . . 926.2.6. Facilidades . . . . . . . . . . . . . . . . . . . . . . . . . 936.2.7. Especificaciones de dominio . . . . . . . . . . . . . . . 946.2.8. Especificaciones de seguridad . . . . . . . . . . . . . . 94

6.3. La tecnologıa CORBA . . . . . . . . . . . . . . . . . . . . . . 956.3.1. Common Object Request Broker Architecture (CORBA) 956.3.2. Arquitectura general . . . . . . . . . . . . . . . . . . . 966.3.3. Interoperabilidad entre ORBs . . . . . . . . . . . . . . 1006.3.4. CORBA IDL . . . . . . . . . . . . . . . . . . . . . . . 1026.3.5. Bases de la construccion de aplicaciones CORBA . . . 103

VIII INDICE GENERAL

6.4. CORBA de tiempo real . . . . . . . . . . . . . . . . . . . . . . 1046.5. CORBA con tolerancia a fallos . . . . . . . . . . . . . . . . . 1106.6. Protocolos de transporte extensibles . . . . . . . . . . . . . . . 1116.7. Otras especificaciones . . . . . . . . . . . . . . . . . . . . . . . 112

6.7.1. Temporizacion extendida . . . . . . . . . . . . . . . . . 1126.7.2. Transductores inteligentes . . . . . . . . . . . . . . . . 112

6.8. UML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113

7. Aplicaciones de CORBA en Control 1157.1. Introduccion . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1157.2. CORBA en el bucle de control . . . . . . . . . . . . . . . . . . 115

7.2.1. Controladores . . . . . . . . . . . . . . . . . . . . . . . 1157.2.2. Restricciones de tiempo . . . . . . . . . . . . . . . . . 1177.2.3. Retrasos introducidos por la red . . . . . . . . . . . . . 118

7.3. Aplicaciones de CORBA en sistemas de control . . . . . . . . 1197.3.1. Bucle de control en red . . . . . . . . . . . . . . . . . . 1197.3.2. Bucles de control supervisados . . . . . . . . . . . . . . 1217.3.3. MMS basado en CORBA . . . . . . . . . . . . . . . . . 1217.3.4. Componentizacion de comunicaciones . . . . . . . . . . 1217.3.5. Entornos de integracion en fabrica . . . . . . . . . . . . 1227.3.6. CORBA para PLC . . . . . . . . . . . . . . . . . . . . 1227.3.7. Arquitecturas orientadas a componentes . . . . . . . . 1227.3.8. Bloques de control . . . . . . . . . . . . . . . . . . . . 1237.3.9. Gestion de riesgos . . . . . . . . . . . . . . . . . . . . . 1247.3.10. Teleoperacion de Robots . . . . . . . . . . . . . . . . . 1267.3.11. Vıdeo de tiempo real para teleoperacion . . . . . . . . 1277.3.12. Operacion de plantas cementeras . . . . . . . . . . . . 1287.3.13. Automatizacion de subestaciones . . . . . . . . . . . . 129

8. CORBA de tiempo real 1318.1. Introduccion . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1318.2. CORBA de tiempo real de prioridad fija . . . . . . . . . . . . 1318.3. RT-ORB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1338.4. RT-POA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1338.5. Prioridades CORBA . . . . . . . . . . . . . . . . . . . . . . . 1348.6. Interfaz current de tiempo real . . . . . . . . . . . . . . . . . . 1348.7. Modelos y transformaciones de prioridades . . . . . . . . . . . 1358.8. Sincronizacion . . . . . . . . . . . . . . . . . . . . . . . . . . . 1378.9. Manejando la concurrencia . . . . . . . . . . . . . . . . . . . . 1388.10. Manejo de conexiones . . . . . . . . . . . . . . . . . . . . . . . 1398.11. Retardo de invocacion . . . . . . . . . . . . . . . . . . . . . . 141

INDICE GENERAL IX

8.12. Protocolo de configuracion . . . . . . . . . . . . . . . . . . . . 1438.13. Servicio de planificacion en tiempo real . . . . . . . . . . . . . 1448.14. Planificacion dinamica de tiempo real CORBA . . . . . . . . . 144

8.14.1. Hilo distribuible . . . . . . . . . . . . . . . . . . . . . . 1458.14.2. Bifurcacion de hilo distribuible . . . . . . . . . . . . . 1458.14.3. Segmentos planificables . . . . . . . . . . . . . . . . . . 1468.14.4. Planificador CORBA de tiempo real . . . . . . . . . . 1468.14.5. Puntos de planificacion . . . . . . . . . . . . . . . . . . 1478.14.6. Recurso enterado de la planificacion . . . . . . . . . . . 148

IV Desarrollo de HIGGS RT 149

9. Hardware y equipamiento 1519.1. Introduccion . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1519.2. Sistema Operativo AROS . . . . . . . . . . . . . . . . . . . . 156

9.2.1. Protocolo de comunicacion entre AROS y un cliente . . 1589.2.2. Paquetes de informacion del servidor AROS . . . . . . 1589.2.3. Comandos de un cliente . . . . . . . . . . . . . . . . . 159

9.3. Conexion cliente-servidor AROS . . . . . . . . . . . . . . . . . 1629.4. ARIA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162

9.4.1. Comunicacion con el robot . . . . . . . . . . . . . . . . 1639.4.2. ArRobot . . . . . . . . . . . . . . . . . . . . . . . . . . 1639.4.3. Comandos y acciones . . . . . . . . . . . . . . . . . . . 1649.4.4. Otras caracterısticas . . . . . . . . . . . . . . . . . . . 165

10.Sistemas operativos de tiempo real 16710.1. Introduccion . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16710.2. VxWorks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16710.3. OSE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16810.4. Linux de tiempo real . . . . . . . . . . . . . . . . . . . . . . . 17010.5. RTAI (Real-Time Application Interface) . . . . . . . . . . . . 17110.6. eCos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172

11.Sistema a desarrollar 17511.1. Introduccion . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17511.2. VxWorks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17511.3. RTAI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17711.4. Servidor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178

11.4.1. IDL . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17811.4.2. Descripcion . . . . . . . . . . . . . . . . . . . . . . . . 183

X INDICE GENERAL

11.4.3. Caracterısticas . . . . . . . . . . . . . . . . . . . . . . 18311.5. Simulador . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18411.6. Cliente . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184

11.6.1. IDL . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18411.6.2. Librerıa Qt . . . . . . . . . . . . . . . . . . . . . . . . 18411.6.3. Descripcion . . . . . . . . . . . . . . . . . . . . . . . . 188

V Apendices 191

A. Glosario de terminos y acronimos 193A.1. A . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193A.2. B . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193A.3. C . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193A.4. D . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195A.5. E . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195A.6. F . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195A.7. G . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197A.8. H . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199A.9. I . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 200A.10.J . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201A.11.K . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202A.12.L . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202A.13.M . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204A.14.N . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 206A.15.N . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 206A.16.O . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 206A.17.P . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207A.18.Q . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 210A.19.R . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 210A.20.S . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 210A.21.T . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213A.22.U . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213A.23.V . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 216A.24.W . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 216A.25.X . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 216A.26.Y . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 217A.27.Z . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 217

B. Otras herramientas 219

Indice de cuadros

1.1. Plataformas y sistemas operativos soportados por ICa . . . . . 8

3.1. Clasificacion del Middleware . . . . . . . . . . . . . . . . . . . 44

6.1. Tabla de lenguajes soportados . . . . . . . . . . . . . . . . . . 926.2. Tabla de conversion del lenguaje IDL a C++ . . . . . . . . . . 103

8.1. Tabla de modelos de prioridades . . . . . . . . . . . . . . . . . 135

9.1. Caracterısticas del microcontrolador y la placa . . . . . . . . . 1549.2. AROS - SIP . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1599.3. AROS - Comandos del cliente (1) . . . . . . . . . . . . . . . . 1609.4. AROS - Comandos del cliente (2) . . . . . . . . . . . . . . . . 161

10.1. Variantes Linux para tiempo real . . . . . . . . . . . . . . . . 170

11.1. Caracterısticas placa Gene-6330 . . . . . . . . . . . . . . . . . 176

A.1. Buses de campo. . . . . . . . . . . . . . . . . . . . . . . . . . 196A.2. Protocolos Ethernet de uso industrial mas habituales. . . . . . 201A.3. Compuestos empleados en la construccion de diodos LED. . . 203

XI

XII INDICE DE CUADROS

Indice de figuras

2.1. Sistema “Control IT” de ABB . . . . . . . . . . . . . . . . . 152.2. Sistema de control “IA Series” de Invensys . . . . . . . . . . 162.3. Sistema de control “Experion PKS” de Honeywell . . . . . . . 172.4. Resumen de alarmas . . . . . . . . . . . . . . . . . . . . . . . 222.5. Resumen de informes . . . . . . . . . . . . . . . . . . . . . . . 24

3.1. Representacion de un sistema distribuido de un automovil . . 293.2. Esquema basico de un sensor inteligente . . . . . . . . . . . . 313.3. Sistema de control “Simatic PCS 7 V6” de Siemens . . . . . . 343.4. Elementos de la DOC . . . . . . . . . . . . . . . . . . . . . . 383.5. Niveles de integracion . . . . . . . . . . . . . . . . . . . . . . 393.6. Integracion mediante middleware . . . . . . . . . . . . . . . . 403.7. Esquema basico de un middleware . . . . . . . . . . . . . . . 423.8. Transaction Processing Monitor (TPM) . . . . . . . . . . . . 453.9. Llamadas a Procedimientos Remotos (RPC) . . . . . . . . . . 463.10. Arquitectura del MOM . . . . . . . . . . . . . . . . . . . . . 483.11. Esquema de interfaz y VTable . . . . . . . . . . . . . . . . . 533.12. Arquitectura de un sistema DCOM . . . . . . . . . . . . . . . 543.13. Diagrama de la plataforma J2EE5 . . . . . . . . . . . . . . . 563.14. Diagrama de la plataforma J2SE5 . . . . . . . . . . . . . . . 563.15. Aplicacion distribuida RMI . . . . . . . . . . . . . . . . . . . 573.16. Relacion entre varias clases e interfaces del sistema RMI . . . 573.17. Arquitectura RMI. Modelo de 4 capas . . . . . . . . . . . . . 58

4.1. Ejemplo sencillo de control de procesos . . . . . . . . . . . . . 624.2. Deadlines duras y blandas . . . . . . . . . . . . . . . . . . . . 65

5.1. Estructura del Standard Control Kernel de OROCOS . . . . 775.2. Constructor de mapas de CARMEN . . . . . . . . . . . . . . 795.3. Planificador de ruta de CARMEN . . . . . . . . . . . . . . . 795.4. Arquitectura de DROS . . . . . . . . . . . . . . . . . . . . . 80

XIII

XIV INDICE DE FIGURAS

5.5. Plataforma de la University of Michigan y diagrama de blo-ques de FLEXnav . . . . . . . . . . . . . . . . . . . . . . . . 81

5.6. Diagrama de la distribucion Orca, sus modulos y las librerıasexternas. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82

6.1. Diagrama OMA clasico . . . . . . . . . . . . . . . . . . . . . . 87

6.2. Componentes de la arquitectura OMA . . . . . . . . . . . . . 89

6.3. Componentes de la arquitectura CORBA . . . . . . . . . . . 96

6.4. Esquema de la invocacion estatica . . . . . . . . . . . . . . . 97

6.5. Esquema de la invocacion dinamica . . . . . . . . . . . . . . . 98

6.6. El Interface Repository y el Implementation Repository . . . . 99

6.7. Interoperabilidad entre ORBs . . . . . . . . . . . . . . . . . . 101

6.8. Generacion, integracion y compilacion . . . . . . . . . . . . . 104

6.9. Extensiones CORBA de tiempo real . . . . . . . . . . . . . . 106

7.1. Bucle distribuido . . . . . . . . . . . . . . . . . . . . . . . . . 116

7.2. Bucle encapsulado . . . . . . . . . . . . . . . . . . . . . . . . 117

7.3. Restricciones de tiempo del bucle . . . . . . . . . . . . . . . . 118

7.4. Bucle de control basado en red . . . . . . . . . . . . . . . . . 120

7.5. Bucle de control supervisado . . . . . . . . . . . . . . . . . . 120

7.6. Gestion de riesgos: RiskMan (1) . . . . . . . . . . . . . . . . 125

7.7. Gestion de riesgos: RiskMan (2) . . . . . . . . . . . . . . . . 125

7.8. Evolucion de la posicion de los ejes del maestro y del robotdurante la prueba . . . . . . . . . . . . . . . . . . . . . . . . 126

7.9. Video en tiempo real: Hydravision . . . . . . . . . . . . . . . 127

7.10. Operacion de plantas cementeras: Pikmac . . . . . . . . . . . 128

7.11. Aplicacion de DOTS en automatizacion de subestaciones . . . 129

8.1. Extensiones CORBA-RT . . . . . . . . . . . . . . . . . . . . 132

8.2. Modelo de prioridad propagado por el cliente . . . . . . . . . 136

8.3. Modelo de prioridad declarada por el servidor . . . . . . . . . 137

8.4. Modelos de Threadpool, con y sin carriles . . . . . . . . . . . 139

8.5. Prioridad de bandas con conexion explıcita . . . . . . . . . . 141

8.6. Conexiones multiplexadas en CORBA de tiempo real . . . . . 142

8.7. Conexion privada en CORBA de tiempo real . . . . . . . . . 142

8.8. Hilo distribuible con segmentos de planificacion anidados . . . 146

9.1. Pioneer 2-AT8 . . . . . . . . . . . . . . . . . . . . . . . . . . . 152

9.2. Panel de control . . . . . . . . . . . . . . . . . . . . . . . . . . 153

9.3. Grupo de sonares . . . . . . . . . . . . . . . . . . . . . . . . . 155

9.4. Arquitectura de control cliente-servidor de ActivMedia Robotics157

INDICE DE FIGURAS XV

10.1. Software y documentacion de Tornado 2.0.2 / VxWorks 5.4 . . 16810.2. Kit de desarrollo OSE . . . . . . . . . . . . . . . . . . . . . . 169

11.1. Placa Gene-6330 . . . . . . . . . . . . . . . . . . . . . . . . . 17611.2. Tarjeta Wireless Compaq WL110 . . . . . . . . . . . . . . . . 17711.3. Punto de Acceso Wireless Compaq WL410 . . . . . . . . . . 17711.4. Simulador de robots MobileSim . . . . . . . . . . . . . . . . . 18511.5. Herramienta Qt Designer . . . . . . . . . . . . . . . . . . . . 18711.6. Programa cliente para Higgs . . . . . . . . . . . . . . . . . . 189

A.1. Representacion del periodo del jitter . . . . . . . . . . . . . . 202A.2. Representacion simbolica del diodo pn . . . . . . . . . . . . . 202A.3. Diodos verde, amarillo y rojo . . . . . . . . . . . . . . . . . . 203A.4. Evolucion de UNIX y de los sistemas operativos tipo UNIX . 214

XVI INDICE DE FIGURAS

Parte I

Introduccion y objetivos

1

Capıtulo 1

Introduccion y objetivos

1.1. Introduccion

El presente Proyecto de Fin de Carrera ha sido desarrollado en el Departa-mento de Automatica, Ingenierıa Electronica e Informatica Industrial de laEscuela Tecnica Superior de Ingenieros Industriales de Madrid. Sus lıneas deinvestigacion estan orientadas al estudio y el desarrollo de nuevas tecnologıasen los campos de control de procesos, inteligencia artificial, robotica y visionpor computador.

El trabajo en el Autonomous Systems Laboratory (ASlab) se centra princi-palmente en inteligencia artificial, robotica y sistemas autonomos. El objetivoprincipal es avanzar en el desarrollo de sistemas de control avanzado. En unfuturo no muy lejano veremos sistemas de una elevada autonomıa de funcio-namiento que podran afrontar situaciones imprevistas, realizando tareas decontrol de sistemas complejos de forma inteligente y robusta.

1.2. Contexto

Este trabajo se ubica dentro del proyecto de investigacion a largo plazoCS2 — Complex Software-intensive Control Systems. Un proyecto de inves-tigacion en tecnologıas software para sistemas de control complejos realizadopor el Autonomous System Laboratory (ASlab) dentro del departamento deAutomatica, Ingenierıa Electronica e Informatica Industrial de la Universi-dad Politecnica de Madrid.

El objetivo de este proyecto investigador es la definicion de arquitecturasde control integrado para la construccion de sistemas complejos de control y

3

4 CAPITULO 1. INTRODUCCION Y OBJETIVOS

el desarrollo de tecnologıas software para su construccion. Las guıas maestrasson simples y guıan todo el desarrollo del proyecto:

Modularidad.

Seguimiento de estandares.

Reutilizabilidad.

Diseno basado en patrones.

Independencia del dominio.

En este contexto, se ha definido una plataforma software generica deno-minada Integrated Control Architecture (ICa) [45] que proporciona losdisenos software centrales. La arquitectura ICa es una metaarquitectura sof-tware que ofrece una serie importante de ventajas frente a otros enfoques:

Coherente y unificada: La arquitectura ICa proporciona integracion ver-tical y horizontal, total y uniforme; por ejemplo permite emplear unaunica tecnologıa en todos los niveles en la verticalidad del sistema decontrol (desde la decision estrategica hasta los dispositivos empotradosde campo) ası como la integracion horizontal de unidades de negocio oempresas extendidas.

Clara: El modelo empleado en ella es un modelo preciso: el modelo de obje-tos distribuidos de tiempo real que constituye la base de las plataformasestado del arte en este campo.

Flexible y extensible: Permite su adaptacion a distintos contextos de eje-cucion y distintos dominios al realizar un mınimo de compromisos dediseno; lo que permite la reutilizacion modular de componentes y laincorporacion de nuevos componentes en dominios concretos.

Abierta: Permite la interoperabilidad con sistemas ajenos (tanto heredadoscomo futuros).

Portable: Gracias a basarse en estandares internacionales.

1.2. CONTEXTO 5

1.2.1. Arquitectura de Control Integrado

ICa (Integrated Control Architecture o Arquitectura de Control Integrado)es un marco de desarrollo de aplicaciones distribuidas construido alrededor deICaORB. ICaORB es el middleware de integracion de ICa. ICaORB siguelas especificaciones CORBA del Open Management Group. ICa e ICaORBhan sido desarrollados en proyectos anteriores del grupo y posteriormentepor SCILabs Ingenieros (Sistemas Control Integracion) [28], un spin-off dealumnos de nuestro grupo. Se sigue usando ICaORB porque permite explo-rar aspectos particulares de la implementacion.

ICaORB es un broker CORBA —con un entorno de desarrollo asociado—disenado para asistir la creacion de sistemas software de medio y alto nivelen entornos industriales, mas concretamente, sistemas de control integra-dos. Proporciona herramientas para el desarrollo de software distribuido, conprestaciones de tiempo real y tolerancia a fallos. ICaORB 1.0 fue el resulta-do del trabajo desarrollado por el Departamento de Automatica, IngenierıaElectronica e Informatica Industrial dentro del marco de un proyecto ESPRITDIXIT en colaboracion con varias empresas de toda Europa. ICaORB RT2.0 es la version actual propiedad de la empresa SCILabs con la que la UPMmantiene un acuerdo de colaboracion. Esta version cumple la especificacionCORBA de tiempo real 1.1 del OMG.

Esta arquitectura —o metaarquitectura, como debe ser considerada ICa enrealidad [44]— se ha venido desarrollando en nuestro departamento durantelos ultimos anos y, gracias a diferentes proyectos de I+D, se ha aplicado conexito en multiples ambitos de control:

Control estrategico de procesos de fabricacion de cemento [41].

Gestion de emergencias en plantas quımicas [43].

Sistemas de monitorizacion distribuida de tiempo real de produccion ydistribucion de energıa electrica [47].

Robots moviles cooperantes [59].

Bucles de control en red [128].

Proteccion de subestaciones electricas [127].

etc.


La caracterıstica primaria de ICa es su enfoque modular. Los sistemasse contruyen por medio de modulos reutilizables sobre frameworks de sis-temas distribuidos de objetos de tiempo real. La organizacion concreta delos modulos viene dada por su arquitectura de aplicacion, que se deriva dela metaarquitectura por medio del uso de patrones de diseno. Su desplieguese hace segun las necesidades y restricciones de la aplicacion, explotando lareubicabilidad de los componentes.

ICa implementa una metodologıa de orientacion a componentes: modulosde software que interaccionan entre sı a traves de una interfaz publica bienconocida. En el caso mas general estos componente se situan en un entornodistribuido y heterogeneo (tanto desde el punto de vista del hardware comode los sistemas operativos soportados) formado por una o varias plataformashardware conectadas a traves de una red, permitiendo la interaccion a travesde la misma.

En ICa 1.0 se desarrollaron extensiones para adaptarse a las necesidadesde los sistemas de control de procesos industriales, en los cuales aparecenrestricciones de tiempo real, los sistemas deben tener tolerancia a fallos yexisten limitaciones de velocidad importantes. Ejemplos de estas extensionesson los mecanismos de gestion de timeouts y de checkpointing. No renunciaa su aplicacion en entornos sin estas necesidades, por lo que es aplicableen los sistemas que no requieran alguna de estas prestaciones simplementerenunciando a ellas. Existen otros frameworks que han sido desarrolladospara aplicaciones de caracter mas ofimatico y se aplican de forma forzada enentornos que se encuentran mas alla de sus especificaciones de diseno.

Por ultimo, el termino integrado hace referencia a una de las caracterısti-cas principales de ICa: su orientacion hacia la integracion de tecnologıas decontrol, plataformas y lenguajes diversos. A la hora de integrar componentespara formar un sistema de control existen tecnicas diversas y los desarrollado-res deben conocer y controlar todas ellas para poder utilizar la mas adecuadaen cada caso.

Los sistemas de control se disenan generalmente por capas (ver seccion2.5), formando lo que se conoce con el nombre de piramide de control. En lascapas inferiores se intercambia informacion a altas velocidades y con un nivelde abstraccion bajo, mientras que, a medida que se va ascendiendo por lamisma, los flujos de datos disminuyen pero aumenta el nivel de abstraccion delos mismos. En las capas superiores tenemos control inteligente, en el que la

1.2. CONTEXTO 7

informacion que se intercambia es abstracta y esta desarrollada con diversasmetodologıas, para proporcionar principalmente soporte a la decision. Losobjetivos de ICa son la integracion de estas metodologıas de control, juntocon la integracion de diversas plataformas y sistemas operativos.

1.2.2. Caracterısticas

ICa existe para el lenguaje de desarrollo C++ y presenta caracterısticasque lo hacen idoneo para su uso en cualquier tipo de aplicacion industrial ode gestion. Entre sus caracterısticas destacan las siguientes:

Independencia de plataforma: A diferencia de otros brokers, ICaORBpresenta un API interno de programacion comun en todas las plata-formas que permite ofrecer el broker a nuestros clientes practicamentepara cualquier plataforma o sistema operativo.

Abstraccion del transporte: En ICa no se impone el transportede red a utilizar para realizar la integracion de los componentes dela aplicacion en la red. Es posible desarrollar y registrar”transportespropietarios y seleccionarlos para su utilizacion desde el codigo de laaplicacion.

Diseno Distribuido Tardıo: ICa permite realizar el desarrollo deaplicaciones de una manera local, creando aplicaciones monolıticas quemas tarde seran distribuidas por la red en forma de componentes. Paraello el compilador de IDL (Interface Definition Language) de ICa per-mite generar un transporte nulo que permite a los componentes de laaplicacion distribuida actuar como objetos locales en una aplicacion.

Granularidad variable: Uno de los objetivos de ICa es el sector in-dustrial (Telecomunicaciones, sector electrico, quımico, etc.). En entor-nos donde los recursos son limitados ICa presenta huellas en memoriamuy pequenas de manera que es posible empotrar el broker en practi-camente cualquier tipo de dispositivo.

Adaptacion al entorno industrial: El broker de ICa contiene ex-tensiones que le permiten soportar aplicaciones de tipo industrial conrequisitos temporales. Estimacion del tiempo de ejecucion de una in-vocacion, timeouts para invocaciones, gestion dinamica de prioridadesde ejecucion de invocaciones al servidor, o gestion de procesos y sub-procesos son algunas de las caracterısticas disenadas para el mundoindustrial.


1.2.3. Disponibilidad

En el apartado anterior se ha hecho hincapie en la posibilidad de emplearICa para integrar diversas plataformas. En la tabla 1.1 se enumeran las pla-taformas y los sistemas operativos en los que se encuentra disponible ICa.

Fabricante SOMicrosoft WindowsSun SolarisGNU LinuxCompaq Tru64SGI IrixIBM AIX

Cuadro 1.1: Plataformas y sistemas operativos soportados por ICa

1.2.4. Otros proyectos

En esta lınea de investigacion en sistemas de control y junto a este trabajose han desarrollado tambien los siguientes proyectos para obtener un sistemade control de robots modular:

Mapeo facial de emociones sinteticas [58]. Desarrollado por R.Conde,este proyecto permite visualizar el estado global del robot Pioneer me-diante una cara antropomorfica utilizando la expresion facial como me-dio de comunicacion.

Integracion de SOAR en ICa [49]. Realizado por S.Sanchez, permitecontrolar los estados del robot empleando la arquitectura general deconsciencia SOAR, desarrollando sistemas que presentan un comporta-miento inteligente.

Modulo de habla CORBA para SOUL [39]. Desarrollado por C.Panizo,anade un componente para permitir la comunicacion hablada del siste-ma.

Se estan desarrollando otros trabajos para:

Reconocimiento de voz.

Reconocimiento de caras.

1.3. TECNOLOGIAS EMPLEADAS 9

1.3. Tecnologıas empleadas

En la realizacion de este proyecto se han utilizado las tecnologıas enume-radas a continuacion:

Sistemas distribuidos, CORBA en particular.

Sistemas distribuidos en tiempo real, con CORBA-RT.

Sistemas Operativos Linux y VxWorks.

Programacion orientada a objetos en C++.

POSIX.

1.4. Necesidades y requisitos

En este apartado se exponen sumariamente los objetivos y las especifica-ciones del presente proyecto de fin de carrera.

El proposito del presente proyecto es desarrollar un servidor CORBA RTque funcione bajo un sistema operativo de tiempo real para controlar un robotPioneer 2-AT8. El servidor existente inicialmente no implementa caracterısti-cas de CORBA de tiempo real y no funciona bajo un Sistema Operativo detiempo real.

Entre los requisitos necesarios para dicho servidor figuran:

Funcionamiento bajo un sistema operativo de tiempo real blando. Enel capıtulo 4 se explica la diferencia entre tiempo real duro y blando.

Implementar caracterısticas de CORBA de tiempo real: Threadpoolscon carriles, bandas de prioridad, . . . que se explicaran en el capıtulo 8.

Comunicaciones inalambricas mediante el hardware existente.

1.5. Estructura de la memoria

La memoria de este proyecto se estructura en cuatro partes. La primeraparte es introductoria y establece los objetivos del proyecto. En la segundaparte se describe las caracterısticas y el estado del arte de los sistemas decontrol industrial, sistemas distribuidos, sistemas de tiempo real y sistemas


de control de robots. En una tercera parte hablamos de Common ObjectRequest Broker Arquitecture (CORBA), su especificacion de tiempo real ydiversos ejemplos de aplicacion de CORBA en el dominio del control indus-trial. En una cuarta y ultima parte realizamos una descripcion del sistemadesarrollado.

Parte II

Sistemas de control

11

Capıtulo 2

Sistemas de control industrial

2.1. Introduccion

Hoy en dıa uno de los objetivos principales en la industria de la automati-zacion y control, junto con la productividad, flexibilidad, calidad y reduccionde coste es la integracion vertical. La disponibilidad de la informacion entiempo real a todos los niveles de la empresa, permite a los usuarios y a lasaplicaciones tener un conocimiento actualizado sobre la produccion y situa-cion, para ası poder obrar en consecuencia.

La informacion en tiempo real debe ser compartida entre diferentes pla-taformas de automatizacion, incluyendo sistemas de control, redes de trans-mision, PLCs, IEDs, sistemas de seguridad, sistemas SCADA, etc. La inte-gracion vertical tiene como objetivo interconectar todos estos sistemas de laforma mas integrada y eficaz, y para conseguirlo es necesario construir el sis-tema sobre unos base solida proporcionada por una arquitectura de softwareadecuada; de esta manera surgen los sistemas distribuidos.

Esta parte de la memoria se divide en cuatro capıtulos que detallan lascaracterısticas de los sistemas de control industrial haciendo hincapie en lossistemas de control de procesos; las caracterısticas particulares de los sistemasde control distribuido; las caracterısticas de los sistemas de control de tiemporeal, y por ultimo, las caracterısticas de los sistemas de control de robots.. Elconocimiento de la estructura y naturaleza de estos sistemas es importantepara el desarrollo de este proyecto.

13

14 CAPITULO 2. SISTEMAS DE CONTROL INDUSTRIAL

2.2. Evolucion

A principios de 1960 el empleo de computadores con memorias de nucleomagnetico y tambores de almacenamiento solo era justificable si se emplea-ba el mismo ordenador para Control Directo Digital (Direct Digital ControlDDC) y control supervisor. En 1970 empezo a considerarse la posibilidad detener dos computadores en un mismo sistema, uno en estado de espera paraprevencion de fallos. La llegada del microprocesador en 1974 hizo economi-camente posible el empleo de Sistemas de Control Distribuido (DistributedControl System DCS) mediante ordenadores.

Los sistemas de control modernos basados en Sistemas de Control Distri-buidos o Controladores Logicos Programables (Programmable Logic Contro-ller PLC) son sistemas complejos y heterogeneos. Se organizan en jerarquıas,y la cantidad de informacion que se intercambia normalmente entre los dife-rentes niveles (integracion vertical) es pequena en comparacion con la canti-dad de informacion que se intercambia dentro de un mismo nivel (integracionhorizontal).

En los ultimos anos existe la tendencia de aumentar la integracion verticalen estos sistemas. La informacion que se maneja tambien esta cambiando.En las capas cercanas al sistema o proceso controlado la informacion consistebasicamente en senales, como medidas y acciones de control. Al subir en lajerarquıa la informacion es la misma que podemos encontrar en un sistemaempresarial: estadısticas, previsiones, etc.

Las caracterısticas de tiempo real tambien cambian de un nivel a otro:en niveles cercanos al proceso, la informacion se actualiza periodicamente ya un ritmo relativamente rapido, y siendo mas estrictas las restricciones detiempo, mientras que en los niveles superiores el trafico es mas espaciado ysin demasiadas restricciones.

2.3. Descripcion de un sistema moderno

Un ejemplo de una arquitectura de control moderna puede verse en la figura2.1, que muestra el sistema de control Control IT de la empresa ABB [36]. Elsistema dispone de varias redes de comunicacion: un bus de campo conectalos dispositivos en el nivel mas bajo; una red de control interconecta loscontroladores entre sı y con el control principal (Servidor de control). Dichoelemento principal es tambien el encargado de hacer llegar la informacion

2.3. DESCRIPCION DE UN SISTEMA MODERNO 15

Figura 2.1: Sistema “Control IT” de ABB

de planta a las capas superiores del sistema, y gestionar la instalacion delsoftware de control en los controladores de planta. Es posible cerrar buclesde control en esta red, pero no suele hacerse. El protocolo usado en la red decontrol es el ISO MMS (Manufacturing Message Specification) sobre TCP.

La red de control se divide en dos partes por razones de seguridad y eficacia:la parte que conecta los controladores (red de control propiamente dicha),y la parte que conecta las estaciones de trabajo, estaciones de ingenierıa uoperacion, etc. Esta ultima parte funciona como una red cliente/servidor,sobre TCP/IP. Por ultimo, la red de cliente/servidor se conecta a traves deun bridge a la intranet de la empresa, que a su vez tiene acceso a Internet.

Los modelos de objetos son componentes importantes de la arquitecturade estos sistemas. El sistema de ABB se basa en el modelo de objetos lla-mado Aspect Object, un modelo de multiples vistas (en el sentido de vista de


Figura 2.2: Sistema de control “IA Series” de Invensys

UML, ver seccion 6.8), en el cual cada objeto del sistema se describe desdediferentes perspectivas o aspectos. Los objetos del modelo pueden ser obje-tos reales como motores y valvulas, o pueden ser abstractos, representandoproductos, materiales, ordenes, etc. Las perspectivas o aspectos pueden serla interfaz de usuario, configuracion, simulacion, mantenimiento, diagramaelectrico, diagrama de control, informes de calidad e informes de producciony muchos otros. El cometido del modelo Aspect Object es modelar un as-pecto determinado de un objeto, de forma independiente de los demas, masque definir un objeto completo de una sola vez. Los aspectos se implementanen diferentes sistemas de software (llamados sistemas de aspecto, aspect sys-tems), los cuales almacenan y gestionan la informacion especıfica del aspectoen cuestion.

El resultado de este modelo es un sistema formado por multiples subsiste-mas de software poco integrados entre sı, que funcionan unidos gracias a unservicio especial que los interconecta. El modelo Aspect Object esta basadoen COM (ver seccion 3.6.5), y dispone de muchas caracterısticas avanzadas

2.3. DESCRIPCION DE UN SISTEMA MODERNO 17

Figura 2.3: Sistema de control “Experion PKS” de Honeywell

que no pueden encontrarse en CORBA o COM por sı solos.

Este sistema de control nos da una idea aproximada de la situacion actualen el campo del desarrollo de los sistemas de control distribuidos, aunquepor supuesto los modelos utilizados y las implementaciones de estos sistemasvarıan segun el fabricante (ver Honeywell [11], Emerson [9], Yokogawa [35] oInvensys [12]). Si bien algunas de las ideas en que se basan estos sistemas yciertos elementos que los componen son similares entre sı, la realidad es quecada sistema construido aporta en ultimo termino una solucion particular;no existe un estandar real o de facto que sigan los fabricantes de manera quesea posible reutilizar el trabajo empleado en el desarrollo. La especificacionCORBA puede ser una solucion adecuada que haga posible la homogeneiza-cion del desarrollo de estos sistemas de control al aportar un modelo basicode desarrollo de aplicaciones distribuidas.

En las siguientes secciones de este capıtulo se pretende dar una visiongeneral del estado del arte y de las caracterısticas mas destacables y comunesa los sistemas de control industrial actuales.


2.4. Caracterısticas generales

Hay dos caracterısticas fundamentales que debe tener un sistema de con-trol para funcionar de forma adecuada:

Confiabilidad

Mantenibilidad

Ademas existen otras caracterısticas que, si bien no son imprescindibles, sue-len ser tıpicas, como:

Escalabilidad

Configurabilidad

2.4.1. Confiabilidad

Se dice que un sistema es confiable si se puede garantizar que estara ope-rativo cuando sea necesario. Los principales factores que afectan a la confia-bilidad de un sistema son la fiabilidad, la seguridad, y la facilidad de uso.

Fiabilidad. Se refiere a la proporcion de tiempo durante el funcionamien-to del sistema, en el cual se comporta segun las especificaciones. Paraque sea posible, en primer lugar el sistema debe garantizar una mınimaintegridad de sus componentes, mediante mecanismos de autocompro-bacion, deteccion y correccion de fallos, y mecanismos de seguridadque aseguren el correcto funcionamiento del sistema. Los posibles fa-llos de partes del sistema no deberıan afectar al funcionamiento globaldel mismo, si bien algunas funciones pueden verse afectadas. En segun-do lugar, el sistema debe disponer de componentes redundantes: si uncomponente funciona indebidamente, pero existe otro igual o similarque puede sustituirle temporalmente en su funcion, el sistema no severa afectado por el fallo del primero. Por ultimo, la disponibilidad de-pende de un correcto mantenimiento del sistema, que incluya los anali-sis y diagnosticos periodicos, reemplazamientos, ajustes y reparacionesnecesarios.

Seguridad. No se debe permitir realizar cambios indebidos en el sistema ausuarios no autorizados, puesto que pueden dar lugar a datos incorrec-tos, provocar averıas en el sistema de control o la planta, o produciraccidentes. Para evitar estas situaciones, es conveniente crear un siste-ma de permisos adecuado.

2.5. NIVELES DE UN SISTEMA DE CONTROL 19

Facilidad de uso. El tiempo empleado en determinar como realizar unaoperacion determinada y aprender a manejar un sistema demasiadocomplejo es un tiempo no productivo.

2.4.2. Mantenibilidad

La mantenibilidad de un sistema se consigue mediante:

Empleo de hardware y software estandar.

Realizacion de diagnosticos automaticos.

Tests fuera de lınea cuando los diagnosticos no detectan un problemadeterminado.

Capacidad de reemplazamiento “en caliente” de los componentes delsistema, para ajustes o reparaciones.

2.4.3. Escalabilidad

Un sistema de control ideal deberıa ser capaz de adaptarse a una granvariedad de sistemas, desde el sistema de automatizacion mas simple basadoen PLCs o en un unico procesador, hasta los grandes sistemas empresariales.

2.4.4. Configurabilidad

Una caracterıstica que distingue los sistemas de control industrial de otrossistemas software es el hecho de que son programables (configurables) por elusuario final, ya sea mediante la programacion en lenguajes especıficos o me-diante la introduccion de los valores de una serie de parametros predefinidosen el sistema. El sistema esta dividido en dos capas: una capa de soporte,oculta al usuario, y una capa de aplicacion, que puede ser configurada poreste. En ocasiones los lenguajes de configuracion pueden ser graficos o ba-sados en otros modelos como los diagramas de flujo, etc. El estandar IEC61131-3 recoge cinco lenguajes de esta naturaleza.

2.5. Niveles de un sistema de control

La arquitectura en capas del sistema es util porque reduce la compleji-dad del mismo al poder desarrollarse por separado y agruparse juntas laspartes funcionales del sistema. Enumeramos a continuacion los niveles masfrecuentes, que podemos apreciar en las figuras 2.1 2.2 y 2.3.


1. Red de informacion. Es la red de maximo nivel, en la que se inter-cambia informacion relativa a la produccion, estrategias, estadısticas,e informes de la planta. Se comunica con la red de operacion.

2. Red de operacion. Interconecta las estaciones de operacion, proce-sadores, etc. Suele usarse TCP/IP sobre Ethernet. En esta red se en-cuentran modulos como interfaces HMI, sistemas de control avanzado,bases de datos e historicos, y puntos de acceso a las redes de los nivelesinferiores.

3. Red de control. Interconecta los controladores de bajo nivel del pro-ceso o sistema controlado.

4. Bus de campo. Es un enlace de comunicaciones digital y bidirec-cional entre los dispositivos inteligentes de la planta. Proporciona unatransmision de datos eficiente y precisa, permite el acceso multiple,configuracion y diagnostico remoto, etc. Conecta los controladores delproceso (red de control) con los instrumentos y dispositivos.

2.6. Transmisiones de datos

En un sistema de control tıpico podemos encontrar diferentes tipos detransmisiones de datos: senales, eventos y ordenes, y otros.

Senales de control y datos. Los datos de los sensores se envıan desde losdispositivos de campo a los controladores, y las senales de control sonenviadas en sentido contrario. Este es el trafico de datos mas importantedel sistema. En general, este tipo de trafico tiene pocas restricciones detiempo real duro.

Eventos y ordenes. Las alarmas o eventos son normalmente generadasdesde los controladores cuando se detecta alguna situacion anormalque requiere la intervencion de un operador. Las ordenes correspon-den a operaciones que se realizan en niveles superiores del sistema, queafectan a la operacion de los controladores. Los requisitos de tiemporeal suelen ser altos en ambos casos.

Codigo binario. Es frecuente que el codigo binario de los controladores yotros dispositivos sea cargado desde las estaciones de ingenierıa de lascapas superiores, cuando se realiza el mantenimiento o instalacion delsistema.

2.7. FUNCIONES CARACTERISTICAS 21

Trafico web. El uso de servidores web para el control y/o configuracion delos dispositivos viene siendo una practica bastante comun. Una aplica-cion muy tıpica es el diagnostico remoto o la generacion de informes.

2.7. Funciones caracterısticas

Algunas de las funciones tıpicas de los sistemas de control industrial sondescritas a continuacion.

2.7.1. Adquisicion de datos

El sistema de control obtiene datos desde los dispositivos conectados a laplanta. Cada dispositivo se comunica periodicamente con los instrumentosde la planta que tiene asociados, comprueba las senales de entrada conecta-das a dichos instrumentos, y las transforma a un formato adecuado para seralmacenadas en una base de datos local. En instantes predeterminados, unsoftware dentro de estos dispositivos se encarga de recoger los datos alma-cenados, manipularlos en caso necesario, y enviarlos a su destino final (porejemplo una base de datos central).

La informacion acerca de todo el proceso que es recogida por el sistemade control debe estructurarse de forma que pueda manejarse de forma eficaz(por ejemplo, agrupar los datos en varias colecciones, asociadas cada una aun lazo de control).

2.7.2. Alarmas

Los estados de alarma se generan mediante la comparacion de los valoresregistrados en la planta, con lımites, rangos u otras condiciones definidas porlos operadores del sistema. Los cambios en estos estados pueden afectar alfuncionamiento de varios modulos. Cuando se pasa a un estado de alarma,pueden llevarse a cabo diversas acciones; si la alarma es meramente informa-tiva el sistema no se ve afectado, pero si la alarma se refiere a una situacionde emergencia, puede lanzarse un procedimiento que lleve al sistema a unestado seguro de forma inmediata. Las alarmas se pueden hacer llegar a losoperadores ya sea mediante las interfaces de usuario (Human Machine In-terface, HMI) (como en el sistema PlantScape de Honeywell mostrado en lafigura 2.4), sirenas, mensajes impresos u otros mecanismos. Un estado dealarma requiere siempre que el operador haga un “acuse de recibo”.


Figura 2.4: Resumen de alarmas

2.7.3. Control

Las funciones basicas de control pueden clasificarse en dos grupos:

Continuas

Discontinuas

Los bucles o lazos de control son ejemplos de funciones continuas, es decir,son operaciones que se realizan de forma ininterrumpida ajustando una seriede senales de manera continuada. Las acciones de control esporadicas, encambio, son funciones discontinuas. Para cada unidad de control en el nivel decampo, se define un conjunto de funciones de control y posiblemente una seriede secuencias. Cada secuencia se divide en fases, las cuales contienen variospasos (comandos del lenguaje de programacion que se emplea para configurarlas unidades de control). Estos comandos se ejecutan secuencialmente y sonlos encargados de iniciar cualquier operacion logica requerida por el sistema:asignacion de valores, comprobacion de condiciones, envıo de senales, etc.Pueden ejecutarse en diferentes modos, ya sea de forma automatica, ya seabajo la supervision de un operador.

2.7. FUNCIONES CARACTERISTICAS 23

2.7.4. Seguridad

En respuesta a condiciones anomalas de la planta, se pueden lanzar proce-dimientos de seguridad que detienen el funcionamiento normal y ejecutan unaserie de instrucciones pensadas para esas situaciones. Las respuestas tıpicasson:

Retener el funcionamiento del sistema fijando los valores de todas lasvariables hasta nuevo aviso.

Ejecutar procedimientos de apagado y detener el proceso.

Llevar el proceso a un estado de funcionamiento o parada, estable yseguro, de la manera mas rapida posible.

2.7.5. Comunicacion con otros sistemas

Los sistemas de control deben interaccionar a menudo con otros subsiste-mas independientes, que se encuentran en la propia planta (e.g. laboratorios)o fuera de ella (e.g. sistemas de gestion de la informacion). Para que estainteraccion sea posible es necesario proporcionar infraestructuras e interfacesque permitan la comunicacion a diferentes niveles de red, y que dispongande funcionalidades como conversion de datos, procesamiento de los mismos,etc.

2.7.6. Generacion de informes

En muchos sistemas es necesario generar informes que reflejen la evoluciondel sistema controlado y su situacion actual. Dichos informes pueden serimpresos o mostrarse en alguna pantalla. En la figura 2.5 apreciamos variostipos de informes que puede generar el sistema PlantScape de Honeywell.Aunque existen muchas variantes, pueden clasificarse en tres tipos basicos:

Informes diarios: contienen una lista cronologica de los eventos o alar-mas ocurridos, cambios del operador sobre el proceso, etc.

Registros: contienen un listado o historico de los valores que tomandeterminadas variables del proceso durante un perıodo de tiempo.

Tendencias: previsiones y analisis graficos de la evolucion durante unperıodo de tiempo.


Figura 2.5: Resumen de informes

2.8. Elementos del control de procesos

Cualquier sistema de control de procesos en bucle cerrado dispone, al me-nos, de los siguientes elementos: sensor, actuador, controlador y sistema decomunicaciones.

2.8.1. Sensores

La tendencia actual es emplear sensores “inteligentes”. La funcionalidadadicional que permiten estos sensores respecto a un sensor clasico abarca:

Transmision de informacion variada acerca del propio dispositivo: rangode operacion, condiciones de mantenimiento, . . .

Operacion remota: el usuario puede controlar el dispositivo desde unsistema remoto a traves de un sistema de comunicaciones para cambiarel modo de operacion, realizar actualizaciones de software, . . .

Comunicacion simplificada: la comunicacion digital elimina la necesi-dad de emplear conversores analogico-digitales y digital-analogicos ex-ternos.

2.8. ELEMENTOS DEL CONTROL DE PROCESOS 25

Estas caracterısticas tambien suponen un aumento del costo y de la com-plejidad de estos elementos, con el consiguiente aumento del riesgo de fallode los mismos.

2.8.2. Actuadores

Estos elementos son fundamentalmente bombas y valvulas de control en laindustria de procesos. Existe la misma tendencia que en los sensores, es decir,instalar actuadores inteligentes, que ademas proporcionan una caracterısticaadicional a las mencionadas para los sensores: la posibilidad de realizar tareasde cierta complejidad como pueden ser los bucles basicos de control, algo-ritmos PID integrados, etc. Esta caracterıstica permite trasladar parte de lacarga de la tarea de control al propio actuador, haciendo al sistema menosdistribuido y mas local. Estos dispositivos conllevan el mismo aumento de lacomplejidad y del riesgo que ya hemos mencionado en el caso de los sensores.

2.8.3. Controladores

Los controladores son basicamente procesadores con algunos componentesde software y hardware adicionales:

Algoritmos de control

Programas de aplicacion

Puertos de E/S analogicos y digitales.

Interfaces de control y redes de campo.

Algunos fabricantes de controladores comerciales son Emmerson, Invensys,Yokowaga, etc.

2.8.4. Sistemas de comunicacion

El avance en los sistemas de comunicacion permite utilizar los dispositi-vos inteligentes mencionados anteriormente. Estos sistemas han evolucionadomucho desde el transporte de senalas analogicas (utilizando intensidades en-tre 4 y 20 mA) hasta llegar a los buses de campo (Profibus, FieldBUS, CAN,. . . ), y un gran numero de redes y protocolos de comunicacion diferentesEthernet, las familias IEEE 802, IEEE 1394 (FireWire), HART (HighwayAddressable Remote Transducer), TTP/C (Time Triggered Protocol classC), etc. La caracterıstica a destacar como mas importante ha sido el empleode senales digitales que permiten la comunicacion en dos sentidos, imposiblecon los anteriores sistemas analogicos.


En los sistemas de comunicacion digitales, la integracion de la informacionno se realiza unicamente a nivel de planta, sino a niveles de control superiores.Como veremos a continuacion, en cada nivel del sistema se emplean diferentesprotocolos y sistemas de comunicacion. 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 unenlace de comunicaciones digital multipunto bidireccional. Sus ventajas in-cluyen la precision y la confiabilidad de los datos transmitidos, el accesomultiple, la configuracion y diagnostico remotos, el ahorro de cableado y ladistribucion de los algoritmos de control. Una desventaja de los buses decampo es que los protocolos no suelen ser abiertos, lo cual puede dificultarla eleccion y/o instalacion de dispositivos de control. Los diferentes buses decampo pueden clasificarse en tres grupos:

Buses de sensor, utilizados para la comunicacion con y entre diferentestipos de sensores, pulsadores, etc. Ej: AS-I, Seriplex.

Buses de dispositivo, disenados para dispositivos mas complejos y quemanejan un mayor flujo de informacion. Ej: Profibus DP, LonWorks,Interbus.

Buses de campo propiamente dichos, los mas empleados para las plantasde proceso. Se emplean en sistemas de control y de diagnostico. Ej:FieldBUS, Profibus PA, Device Net, World FIP. En un futuro no muylejano se espera poder utilizar redes ethernet para la construccion deeste tipo de buses.

Nivel de control. Se emplean diferentes protocolos, generalmente basadosen Ethernet. Los mas utilizados son ControlNet, Profinet, FieldBUS HSE,Modbus. Tambien se usan otros protocolos no basados en Ethernet, comoCAN.

Nivel de negocio o red de informacion. Tıpicamente se emplea TCP/IPsobre Ethernet.

2.8.5. Interfaces de usuario

Los operadores supervisan y controlan el sistema a traves de las interfa-ces de usuario o HMI (Human-Machine Interfaces). En estas interfaces semuestran alarmas y se controlan los procedimientos para responder a ellas;

2.8. ELEMENTOS DEL CONTROL DE PROCESOS 27

se presentan informes, historicos del proceso, tendencias y valores medios; sepuede manipular el estado del proceso y cambiar los puntos de funcionamien-to; gestionar la instalacion y configuracion remota de software, y una granvariedad de operaciones adicionales.

El nivel de detalle de las interfaces de usuario es muy variable, existien-do tanto interfaces consistentes en displays LCD o leds de 7 segmentos yalgunos pulsadores como interfaces graficas de gran complejidad. El tiempode refresco de la informacion tambien varıa desde fracciones de segundo aminutos.

Suele recomendarse un mınimo de dos estaciones de operacion, por razo-nes de seguridad (una de ellas puede fallar) y de mantenimiento (una de ellaspuede dedicarse a mantenimiento mientras la otra opera el proceso). Se re-comiendan tres estaciones, las cuales se usan de la siguiente manera: en unael operador supervisa el funcionamiento general del sistema, en la segundase muestra una vista detallada del funcionamiento de algun componente osistema, y la tercera se usa para mostrar alarmas.

2.8.6. Bases de datos

El uso de una base de datos para almacenar datos historicos del proceso escasi obligado en la mayorıa de los sistemas de control actuales. La informacionde dicha base de datos es utilizada a varios niveles del sistema, tanto paracontrol, como para gestion y elaboracion de estrategias de produccion, porejemplo.

Ademas del soporte de almacenamiento necesario para los datos registra-dos, la base de datos suele contener tambien imagenes del sistema (configu-raciones del mismo en determinados instantes), informacion de diagnostico,software de usuario o de los dispositivos de la planta, etc.

Capıtulo 3

Sistemas de control distribuido

Podemos definir un sistema distribuido como un sistema formado pormultiples procesadores y recursos independientes, que cooperan para realizartareas, intercambiando informacion a traves de algun tipo de red de comu-nicacion. En la figura 3.1 puede verse una representacion de un sistema dis-tribuido generico, donde podemos encontrar ordenadores personales o termi-nales, servidores, clusters, memorias compartidas, y diferentes tipos de redesde comunicacion.

Figura 3.1: Representacion de un sistema distribuido de un automovil

29

30 CAPITULO 3. SISTEMAS DE CONTROL DISTRIBUIDO

En un sistema distribuido encontramos que los componentes que formanel sistema estan separados en vez de encontrarse agrupados en una unicaentidad. Estos elementos pueden estar separados entre sı fısicamente, y tam-bien pueden estar separados de forma logica, en cuyo caso dos elementos desoftware, por ejemplo, funcionan en la misma maquina pero son completa-mente independientes el uno del otro. Una caracterıstica destacable de estossistemas es que desde el punto de vista de la funcionalidad o de los usuarios,aparentan ser un unico sistema centralizado; es decir, la heterogeneidad yseparacion de los componentes del sistema permanece oculta.

Cuando un sistema distribuido se utiliza para controlar otro sistema, ha-blamos de un Sistema de Control Distribuido, o DCS (Distributed ControlSystem). Estos sistemas han supuesto el ultimo escalon de la evolucion de lossistemas de control. A diferencia de los sistemas de control centralizados, enellos el software y los dispositivos de control se encuentran repartidos entredistintos puntos de la planta o sistema a controlar, en vez de agruparse fısi-camente en una ubicacion unica. Generalmente existe una o mas interfaceshombre–maquina, tambien repartidas a lo largo de la planta, a traves de lascuales se pueden supervisar multiples bucles de control.

Con un Sistema de Control Distribuido (DCS) se consigue un funciona-miento distribuido tanto en el aspecto fısico, como en el aspecto funcional.La distribucion en el aspecto fısico en control distribuido supone una mayorsencillez de diseno del sistema, facilidad de cableado, etc. En el aspecto fun-cional o logico, se dispone de la “inteligencia” y potencia de calculo in situ,allı donde son necesarios, en vez de encontrarse centralizados en un uniconucleo de control. La toma de decisiones se distribuye entre los diferentesnodos del sistema. Esta arquitectura implica la posibilidad de disponer desistemas de control mas fiables y flexibles. El empleo de un unico ordenador(control centralizado) tiene el inconveniente de ser susceptible a los fallos enmodo comun; en caso de fallo de dicho control central, se ve afectado todoel sistema. Usando el DCS se distribuye el riesgo entre varios controladores,pudiendo hacer el sistema redundante y mas inmune a fallos localizados.

Un caso particular de los sistemas de control distribuido son los sistemasbasados en los llamados buses de campo. En estos sistemas se utilizan dispo-sitivos (sensores y actuadores) en cierta forma inteligentes (smart devices).Dichos dispositivos tienen cierta capacidad de procesamiento y comunicaciona traves de un bus de comunicaciones serie. En la figura 3.2 puede verse unesquema de un sensor inteligente. La estructura de estos dispositivos tiene

3.1. REQUISITOS Y CARACTERISTICAS 31

Figura 3.2: Esquema basico de un sensor inteligente

similitudes conceptuales con la utilizada para desarrollar los componentesCORBA de la plataforma de pruebas. En el capıtulo 6 se hace una descrip-cion en detalle de la arquitectura de estos componentes.

La introduccion de los buses de campo, supone la sustitucion de los tradicio-nales bucles de corriente de 4 a 20 mA por buses de comunicaciones digitalesestandarizados. Otros sistemas de control distribuidos emplean otros meca-nismos como las Redes de Area Local (LAN), con diferentes configuracionesy protocolos, y otros tipos mas especializados de redes de comunicacion. Entodos ellos se mantiene la misma estructura: un conjunto de nodos indepen-dientes que se comunican entre sı a traves de una red.

3.1. Requisitos y caracterısticas

La estructura que debe tener un sistema, y en concreto un sistema de con-trol, para poder ser llamado “distribuido”, se basa en los siguientes requisitos:

Sustituir el modelo clasico de controlador central, por un conjunto devarios controladores digitales capaces de controlar de forma individualun cierto numero de variables.

Cada controlador debe ser universal, en el sentido de disponer de al-goritmos seleccionables por software aumentando la versatilidad delsistema.


La velocidad de adquisicion de los datos y su salida hacia los actuadoresdebe realizarse en tiempo real de forma que el proceso de control no sevea afectado.

Para comunicar entre sı los distintos nodos del sistema (dispositivos,controladores e interfaces) se emplea una red de comunicaciones comuna todos ellos (FieldBus, LAN, etc.)

El sistema dispone de un conjunto de interfaces hombre-maquina quefacilitan y simplifican la supervision y control de la planta.

Tomando como punto de partida estas ideas se construyen los sistemas decontrol distribuido. A continuacion se presenta una serie de caracterısticasde estos sistemas que es importante resaltar:

Heterogeneidad. En el nivel fısico de estos sistemas podemos encontrar,como ya hemos mencionado, una gran variedad de redes, procesadores, dis-positivos de almacenamiento, memorias compartidas, dispositivos de campo,etc. A nivel logico tambien puede aparecer heterogeneidad: diferentes proto-colos de comunicacion, sistemas operativos y lenguajes de programacion. Lafigura 3.3 muestra un ejemplo en el que puede apreciarse la complejidad a laque pueden llegar estos sistemas.

Escalabilidad. Se define como la capacidad de un sistema para poderanadir al mismo nuevos recursos o dispositivos sin afectar a las prestacionesdel mismo. Un sistema distribuido bien disenado debe ser escalable en estesentido, porque la adicion de nuevos elementos al sistema siempre puedetener consecuencias sobre su funcionamiento: un aumento del coste de losrecursos, una perdida de rendimiento, y una posible saturacion de los recursosque utilizan los programas. Un sistema distribuido sera tanto mas escalable,cuanto mas facilmente pueda anadirse o eliminarse un elemento del mismo,sin tener repercusiones en el rendimiento o funcionamiento de los demaselementos del sistema.

Tolerancia a fallos. La redundancia de los componentes y la indepen-dencia entre los mismos permite evitar que un fallo en uno de los nodosde un sistema distribuido afecte al funcionamiento del resto del sistema. Elfallo puede limitarse a elementos concretos manteniendose la funcionalidaddel resto del sistema, aunque esto siempre depende de la relacion que existaentre los elementos.

3.1. REQUISITOS Y CARACTERISTICAS 33

Concurrencia. En un sistema distribuido es muy comun que aparezcansituaciones de acceso concurrente (simultaneo) a algun recurso del sistema.Algunos ejemplos de concurrencia pueden ser: acceso simultaneo de dos pro-cesos a una base de datos; escritura simultanea de dos threads en un areade memoria compartida; o peticion de un determinado servicio por parte dedos clientes a la vez. Como puede apreciarse en estos ejemplos, la concu-rrencia puede darse a diferentes niveles del sistema: a nivel de proceso (entrethreads), a nivel de host (entre procesos) o a nivel de red (entre elementosdistribuidos).

Transparencia. Un sistema distribuido es transparente cuando la estruc-tura, organizacion, funcionamiento y los elementos internos permanecen ocul-tos al usuario, para el cual el sistema funciona como si estuviera totalmentecentralizado. Existen tres tipos de transparencia: en localizacion, en escala-bilidad y en movilidad. La transparencia en localizacion consiste en que laentidad (usuario o proceso) que utiliza un recurso no tiene por que saber enque localizacion fısica se encuentra dicho recurso. La transparencia en esca-labilidad significa que el sistema facilita una infraestructura a traves de lacual puede ampliarse mediante la adicion de nuevos componentes, sin quesea necesario realizar operaciones de configuracion e instalacion complejas; yla transparencia en movilidad consiste en que un recurso determinado pue-de cambiar su localizacion fısica sin afectar al funcionamiento normal delsistema.

Tiempo. En un sistema distribuido el tiempo es una variable de la mayorimportancia, y mas si el cometido del sistema distribuido es controlar algo.En muchos casos es necesario establecer una base de tiempos comun a todoso varios de los componentes para sincronizarlos; tambien hay que considerarlas latencias, o tiempos que tardan los recursos o procesos en proporcionarun determinado servicio o informacion previamente requeridos. Las latenciasdemasiado altas pueden provocar perdidas de informacion o reducciones delrendimiento del sistema. El factor tiempo es mas importante si cabe en lossistemas de control distribuidos de tiempo real, en los cuales la temporizaciony la planificacion son esenciales. Existen soluciones de hardware y softwarepara resolver el problema de la sincronizacion temporal, por ejemplo, el sis-tema NTP (Network Time Protocol) o el protocolo TTP (Time TriggeredProtocol).

Existen otros muchos factores, ademas de los descritos, a tener en cuentacuando se utilizan estos sistemas, como pueden ser la variabilidad del ancho


de banda de un canal de comunicaciones, las colisiones o monopolizacionesde un canal, la interrupcion del mismo, funcionamientos imprevistos de alguncomponente, problemas de seguridad, calidad de servicio (QoS), etc.

3.2. DCS en el ambito industrial

Los sistemas de control distribuido tienen gran aplicacion en industriascomo la farmaceutica, fabricacion, industrias quımicas, e industrias de comu-nicaciones. Podemos citar algunas grandes companıas que apuestan en mu-chos de sus productos y sistemas por los sistemas distribuidos: Honeywell(ver [11]), ABB (ver [36]), Emerson (ver [9]), Invensys (ver [12]), Yokogawa(ver [35]), Allen-Bradley ([23] – comprada por Rockwell Automation), Na-tional Instruments ([17]), o Siemens ([29]), como el sistema representado enla figura 3.3. Las funciones basicas mas comunes de los DCS industrialesdesarrollados por dichas empresas, entre otras, son los bucles de control, laejecucion de logica programada, la monitorizacion de entradas, lanzamientode alarmas y registro e informe de datos de la planta.

Figura 3.3: Sistema de control “Simatic PCS 7 V6” de Siemens

3.2. DCS EN EL AMBITO INDUSTRIAL 35

Podemos observar los siguientes elementos habituales en la arquitecturabasica de DCS comerciales:

Interfaces de usuario. Tambien llamadas HMI (Human-Machine Inter-faces), son utilizadas para mostrar informacion sobre el sistema controlado ypermitir la ejecucion de operaciones por parte de los operadores humanos.

Instrumentos de proceso. Sensores a actuadores de la planta, controla-dos a traves de buses de campo o lıneas de comunicacion mas sencillas.

Modulos de entrada/salida. Constituyen la interfaz entre el DCS y elproceso o planta controlados. Convierten las senales obtenidas de la planta aformato digital, y realizan un acondicionamiento y filtrado adecuados de lassenales.

Modulos de control. Reciben datos desde el DCS y envıan las senalesadecuadas a los actuadores. Tienen capacidad para realizar ciertos calculos,filtrar senales, generar alarmas, etc.

Modulos de comunicaciones. Conectan los modulos a los buses decomunicaciones.

Bus de E/S local. Actua de puente entre los modulos de entrada y sali-da, y los modulos controladores. La comunicacion a traves de este bus pue-de basarse en muchos estandares y protocolos diferentes: CANopen(CAN),ControlNet, DeviceNet(CAN), Ethernet(TCP/IP), Fielbus(Token-passing),Interbus, Profibus, etc. Existen buses de comunicaciones para transmisionde datos en tiempo real, es decir, que permiten el envıo de datos de formasincronizada, con tiempos determinados y conocidos, con capacidades y ren-dimientos tales que sea posible un comportamiento determinista, esencial enun sistema de tiempo real.

Los elementos anteriormente descritos pueden ser de caracterısticas enor-memente diferentes, segun el sistema de control que elijamos. Pueden cons-truirse sistemas basados fundamentalmente en dispositivos hardware, o de-sarrollarse sistemas con una gran carga de software. Ambas alternativas sonvalidas y tienen sus ventajas y sus inconvenientes. Es cuando se elige la se-gunda opcion, los sistemas basados en software, cuando puede utilizarse unapotente filosofıa de desarrollo llamada computacion distribuida basada enobjetos o Distributed Object Computing(DOC).


3.3. Distributed Object Computing(DOC)

La computacion distribuida mediante objetos (DOC) es una filosofıa deprogramacion basada en la construccion de aplicaciones mediante compo-nentes llamados objetos distribuidos. Dichos objetos interactuan entre sı re-partidos a lo largo de una red posiblemente heterogenea, de forma que elconjunto adquiere unas capacidades y funcionalidad determinadas.

3.3.1. Objetos locales y objetos distribuidos

Desde el punto de vista del software, definimos un objeto u objeto local,como una entidad abstracta que contiene un conjunto de datos (atributos)determinado y que proporciona operaciones (metodos) que manipulan dichosdatos. A menudo los objetos son representaciones de objetos del mundo real;tienen una interfaz bien definida a traves de la cual pueden ser manipulados,y pueden ser identificados y localizados gracias a una referencia o direccion.El diseno y uso de objetos en software se rige por los principios de la progra-macion orientada a objetos (OOP), que recordamos a continuacion:

Encapsulamiento

Herencia

Polimorfismo

Instanciacion

Un “objeto distribuido” es un caso particular de un objeto, que esta inte-grado dentro de un sistema distribuido, y que puede ser utilizado por otrosobjetos desde nodos del sistema diferentes a aquel en el que reside dicho ob-jeto. De esta manera se permite el acceso a objetos remotos que no necesitanconocer la localizacion fısica del objeto sino unicamente disponer de una re-ferencia al mismo. Utilizando dicha referencia, un objeto distribuido puedeser utilizado en un programa, de la misma manera que si fuera un objetolocal. Los objetos distribuidos suelen ser componentes binarios (ejecutables)o librerıas, que se ejecutan en un procesador o espacio de direcciones distintoal de los clientes.

3.3.2. Generalizacion del modelo cliente servidor

La DOC es una gran generalizacion del modelo cliente-servidor, y cuandose emplean las palabras “cliente” y “servidor”, hay que entenderlas como con-ceptos diferentes de los utilizados en dicho modelo. Entendemos por cliente

3.3. DISTRIBUTED OBJECT COMPUTING(DOC) 37

cualquier entidad del sistema que realiza una peticion de un servicio a unobjeto determinado, al que se llama servidor en el transcurso de dicha pres-tacion de servicio. En otro momento cualquiera, el objeto distribuido queactuo de “servidor” puede pasar a ser el “cliente” de otro objeto, el cualsera entonces el “servidor”. En definitiva, en la DOC no existen elementosque puedan ser llamados siempre clientes, ni elementos que puedan ser iden-tificados unicamente como servidores, ya que cualquiera de ellos puede, eninstantes diferentes, tomar el rol de cliente o el de servidor, indistintamente.

Los objetos distribuidos, como objetos que son, disponen de un estado in-terno y de una interfaz, a traves de la cual sus servicios pueden ser utilizadospor otros objetos del sistema, y puede modificarse o consultarse el estadointerno del objeto. El diseno y construccion de esta interfaz puede hacersede muchas maneras, siendo una de ellas el lenguaje IDL (Interfaz DefinitionLanguage), que emplea CORBA, como veremos en la seccion 6.2.3. Los obje-tos distribuidos tambien suelen ser una representacion de objetos reales; uncaso claro es un objeto que hace de wrapper (literalmente envoltorio) paraun dispositivo fısico; esto es, un objeto software que actua de intermediarioentre la interfaz de entrada/salida del dispositivo (hardware) y el resto delsistema distribuido (software). En esta situacion, para el sistema de controldistribuido en cuestion representa al dispositivo fısico al que esta asociado.

3.3.3. Elementos de la DOC

Los elementos que fundamentan la computacion distribuida de objetos seesquematizan en la figura 3.4: modelos de objetos, integracion, transporte yservicios. Los modelos de objetos surgen de la teorıa de la programacionorientada a objetos (OOP), que es obviamente la base de la DOC, y todos susprincipios deben ser tenidos en cuenta durante el desarrollo. Existen modelosde diseno (generalmente emplean lenguajes de modelado como UML), mode-los de construccion (lenguajes de programacion) y modelos de ejecucion. Unaextension de los modelos de objetos son los modelos de componentes, centra-dos en el desarrollo de entidades reutilizables. La integracion es el elementoque aporta un medio logico de comunicacion efectivo y fiable, entre los dife-rentes elementos del sistema, y suele ser proporcionado por un middleware,del cual hablaremos mas adelante. El transporte es la parte encargada dela comunicacion a bajo nivel, que hace posible la conexion de unos elementoscon otros a nivel fısico. Puede ser por ejemplo, una red de comunicacionesEthernet. Por ultimo, los servicios son entidades preconstruidas, proporcio-nadas usualmente por el middleware, que aportan diferentes funcionalidades


Figura 3.4: Elementos de la DOC

y ayudas a los desarrolladores y a las aplicaciones desarrolladas, como puedenser infraestructuras de seguridad, gestion de eventos, registro de datos, etc.

3.3.4. Beneficios de la DOC

Los sistemas desarrollados siguiendo los paradigmas de la computaciondistribuida se benefician de las siguientes ventajas, entre otras:

Simplificacion del diseno y desarrollo gracias a las capacidades de losobjetos (en el sentido de la OOP)

Los elementos de los sistemas son practicamente instalables y modifi-cables “en caliente” (filosofıa plug-n-play)

El desarrollador puede instalar los objetos distribuidos en aquellasmaquinas mas adecuadas para el trabajo que llevan a cabo dichos ob-jetos.

La integracion de sistemas y dispositivos heterogeneos es maxima.

Es posible desarrollar componentes reutilizables.

El mantenimiento se simplifica enormemente.

Disponibilidad de mayor potencia de calculo gracias al proceso en pa-ralelo.

Los sistemas son flexibles, consistentes y mas fiables.

3.4. DEFINICION DE MIDDLEWARE 39

Figura 3.5: Niveles de integracion

Los sistemas son escalables, portables y extensibles.

Los costes se reducen conforme se desarrolla el sistema.

3.4. Definicion de Middleware

Existen diferentes soluciones para el problema de la integracion que sepresenta al desarrollar aplicaciones mediante DOC, y el middleware es unade ellas. La integracion en un sistema distribuido consiste en establecer unmedio de comunicacion entre diferentes elementos del sistema. La integracionpuede realizarse a diferentes niveles, como puede verse en la figura 3.5.

A nivel de thread: se realiza una llamada a un metodo de un objetolocal. No hay problemas de concurrencia y realmente no es necesarianinguna estructura especial para integrar el objeto en el sistema.

A nivel de proceso: se realiza una llamada entre dos threads dentro deun mismo proceso. La comunicacion es rapida y fiable; pueden aparecerproblemas de concurrencia si se utilizan zonas de memoria compartida,por ejemplo.

A nivel de host: se produce una llamada entre dos procesos, dentro deun mismo host. El modelo cliente/servidor es adecuado en este caso, y


Figura 3.6: Integracion mediante middleware

es necesaria cierta infraestructura de comunicacion, como por ejemplo,sockets. Tambien existen problemas de concurrencia, y la comunicacionno es tan rapida pero sigue siendo bastante fiable.

A nivel de red: se produce una llamada entre dos procesos que se ejecu-tan en hosts diferentes, dentro de una misma red. Tambien puede uti-lizarse el modelo cliente/servidor, y es posible utilizar infraestructurasmas complejas como Remote Procedure Call (RPC). La comunicacionpuede no ser fiable.

El middleware es una solucion software que hace posible la integraciona varios niveles de los cuatro mencionados, de forma simultanea. Es decir,facilita una infraestructura de comunicacion que puede ser utilizada sin dife-rencias en su utilizacion segun el nivel. El sistema es transparente al usuario:los objetos distribuidos pueden enviarse mensajes (realizar invocaciones) sinimportar a que nivel se produce la comunicacion. Un middleware que faci-lita una infraestructura comun a los cuatro niveles, se denomina brokeringmiddleware.

El brokering middleware (o broker) sustituye a los demas mecanismosutilizados para integrar a un nivel determinado, como son RPC, sockets(TCP/UDP), etc. Al proporcionar un soporte de comunicacion unico (ver

3.5. FUNCIONAMIENTO DE UN MIDDLEWARE 41

figura 3.6), enmascara la heterogeneidad y separacion entre los elementos delsistema, haciendo que este funcione como una entidad agrupada.

El objetivo del middleware es liberar a los desarrolladores de las tareascomunes, complejas, de bajo nivel o mundanas de interaccion entre modulosen un sistema distribuido. Todos los modulos del sistema distribuido debenseguir esta abstraccion con el fin de ser capaces de comunicarse. Por ello, elmiddleware se emplea para hacer que los procesos residentes en uno o masordenadores servidores interactuen entre sı. El middleware proporciona a lasaplicaciones un conjunto de servicios de mas gruesa granularidad que aquellosque son del Sistema Operativo en la forma de Interfaz de Programacionde Aplicaciones (API) que las proporciona las siguientes propiedades, entreotras:

Localizacion de servicios en red de una manera transparente. Esto sig-nifica que la distribucion es transparente para las aplicaciones. El siste-ma se comporta para las partes componentes del mismo como si fueramonolıtico.

Independencia de los servicios de red. Las aplicaciones no se percatande la existencia de la red; el middleware es el encargado de manejar loscomplejos detalles del acceso a red.

Eficacia y disponibilidad. La programacion de la red es una tarea com-pleja y el middleware proporciona una manera eficaz y probada de pegarjuntos los componentes de un aplicacion distribuida.

Escalabilidad en capacidad sin perdida de funciones. El middlewareproporciona servicios para controlar el ciclo de vida de los componentesde un sistema distribuido y de controlar los recursos disponibles paratodo el sistema.

Resolver la cuestion de la heterogeneidad, permitiendo la construccionde sistemas donde existe heterogeneidad de hardware, Sistemas Ope-rativos (SO), protocolos de red y lenguajes de programacion.

3.5. Funcionamiento de un middleware

Como ya se ha dicho al hablar de la computacion distribuida, cuando unelemento de un sistema distribuido requiere de otro, se asignan los nombresde cliente y servidor a dichos elementos, respectivamente. Para que un cliente


Figura 3.7: Esquema basico de un middleware

pueda realizar una peticion de servicio, que es al fin y al cabo una invocacionremota de un metodo del servidor, debe poder hacer llegar dicha peticion ala infraestructura de comunicacion, el middleware. Una vez este recibe estapeticion, debe encargarse de hacersela llegar al objeto servidor, realizando lastareas que sean necesarias para abrir un canal de comunicacion entre ambosobjetos.

Para que la interaccion con el middleware sea posible, ambos objetos, clien-te y servidor, deben utilizar “intermediarios” que hagan las veces de men-sajeros de las peticiones. Dichos intermediarios reciben el nombre de stubso client stubs, para el caso de los clientes, y skeletons, o server stubs, parael caso de los servidores. Estos elementos suelen ser fragmentos de codigofuente generados automaticamente por herramientas proporcionadas juntocon el middleware, y que deben ser integrados por el programador dentro delos programas de los objetos cliente y servidor. Los stubs facilitan metodosque pueden ser utilizados desde el cliente para enviar peticiones y utilizarlos servicios que proporcione el middleware, y los skeletons hacen lo analogopara los servidores.

Por tanto, el proceso que se sigue cuando un cliente realiza una peticionde servicio a un servidor, es el siguiente:

1. El objeto distribuido cliente realiza una invocacion, utilizando la refe-rencia del servidor, de la que dispone.

2. Dicha invocacion se traduce automaticamente en llamadas a metodos

3.6. TAXONOMIA DEL MIDDLEWARE 43

del stub, que traducen la peticion del cliente a un mensaje con la infor-macion necesaria, que es gestionado y enviado al middleware.

3. El middleware hace llegar el mensaje hasta el skeleton del objeto dis-tribuido servidor.

4. El proceso puede repetirse a la inversa si el servicio invocado debedevolver algun valor o informacion para el cliente.

En la figura 3.7 puede verse el esquema de un middleware que integra dosobjetos distribuidos, cliente y servidor. Hay que hacer notar que los stubsy skeletons forman parte integrante de los objetos distribuidos, y no sonelementos de software independientes. El middleware utiliza para la comu-nicacion de los mensajes un protocolo especıfico; en el caso de CORBA, porejemplo, es muy utilizado el protocolo Internet Inter-ORB Protocol (IIOP),basado en TCP/IP y desarrollado a partir de la especificacion basica para pro-tocolos interoperables de CORBA, el General Inter-ORB Protocol (GIOP).

3.6. Taxonomıa del Middleware

El middleware puede clasificarse de acuerdo a las siguientes cuatro formas:

Middleware Monitor de Procesao de Transacciones o Transaction Pro-cessing Monitor (TPM) Middleware.

Middleware de Llamadas a Procedimientos Remotos (RPC).

Middleware Orientado a Mensajes (MOM).

Middleware Orientado a Objetos (OOM).

Esta clasificacion distingue los diferentes tipos de middleware atendiendounicamente a los diferentes tipos de maquinaria de programacion involucradaen la comunicacion entre las distintas partes de un sistema distribuido. Esen-cialmente, el criterio se basa en que todos los tipos de middleware definenun esquema uniforme de acceso a otros componentes del sistema distribuidodisperso a traves de la red.


IBM CICSTransaction Processing Monitor TPM BEA Tuxedo

HP EncinaGradient RPC

Reverse Procedure Calling RPC DCE de Compaq (HP)RPC de SunIBM MQSeries

Message Oriented Middleware MOM Software AG EntireXTIBCO Enterprise Message Service,SmartSockets y RendezvousMicrosoft COM/DCOM

Object Oriented Middleware OOM RMI de SunCORBA del OMG

Cuadro 3.1: Clasificacion del Middleware

3.6.1. Transaccion-Processing Monitor (TPM) Midd-leware

TPM es un middleware cliente-servidor especıficamente disenado para apli-caciones de transaccion. Esta es una tecnologıa de software madura que seemplea en aplicaciones relacionadas con manejo de datos, acceso a bases dedatos, entrega de ordenes, etc. El middleware TPM esta disenado para pro-porcionar acceso a miles de clientes en un entorno cliente/servidor distribuidomediante el control y la traza de las peticiones de transacciones de los clien-tes en un conjunto de rutinas de servicios que multiplexan las transacciones.(Ver figura 3.8)

Las rutinas de servicios son crıticas para la arquitectura del sistema y sonlas unicas rutinas-cliente con las que el sistema servidor interactua, evitandola sobrecarga de manejar miles de clientes. La ventaja de esta tecnologıa esque el sistema servidor unicamente visualiza un reducido numero de interac-ciones a traves de un pequeno conjunto de rutinas y no la totalidad de losclientes. La prioridad de acceso de los clientes se establece en funcion del tipode servicio solicitado. Normalmente tambien se puede mover la logica de lasreglas de empresa del proceso de transacciones desde los clientes al monitorprocesador de transacciones, facilitando al administrador la actualizacion delsistema. La tecnologıa TPM escala bien cuando aumenta el numero de clien-tes, puesto que todas las peticiones son multiplexadas por el TPM. Cuandoel numero de clientes es demasiado grande es posible anadir mas TPMs paramanejar mejor el multiplexado de las peticiones.


Figura 3.8: Transaction Processing Monitor (TPM)

El mercado TPM esta dominado por unos pocos vendedores. Estos propor-cionan grandes sistemas que se integran con una gran variedad de procesosde empresa y ofrecen varias maneras de acceder a la funcionalidad del TPM.Por ejemplo, Tuxedo TPM de BEA tiene CORBA y un interfaz de Aplicaciona Monitor de Transacciones (ATMI) para acceder a la infraestructura TPM.

La mayorıa de estos productos TPM ofrecen caracterısticas avanzadascomo balanceo de cargas, caracterısticas de administracion o de tolerancia afallos. La mayorıa de los TPMs mas empleados son:

IBM CICS: CICS es abreviatura de Customer Interface Control Sys-tem. El nombre proviene de una familia de servidores de aplicaciones einfraestructura para el manejo de transacciones en lınea para aplicacio-nes crıticas. CICS tiene interfaces disponibles en COBOL,C,C++,Javao PL/I.

BEA Tuxedo: Este producto incluye un servidor de aplicaciones, unTPM, infraestructura de proceso de transacciones y dos interfaces deprogramacion de aplicaciones, uno para CORBA el lenguaje C++ y lainterfaz de Aplicacion a Monitos de Transacciones (ATMI).

HP Encina: Encina emplea el Entorno de Computacion Distribuida(DCE) como infraestructura basica RPC sobre la que se construye el


Figura 3.9: Llamadas a Procedimientos Remotos (RPC)

monitor procesador de transacciones. HP ha mejorada el mecanismoRPC para dotarle de semantica transacional, definiendo lo que ellosllaman RPC Transaccional.

3.6.2. Llamadas a Procedimientos Remotos (RPC)

RPC es una infraestructura cliente/servidor que permite a los desarro-lladores acceder a los componentes de un sistema distribuido por media dellamadas a funciones. En el caso de RPC no existe una capa de software de-finida que implemente el middleware, sino que el middleware esta empotradoen las aplicaciones cliente y servidor.

Para implementar Llamadas a Procedimiento Remoto, a la hora de com-pilar se crean stubs para los lados cliente y servidor que son compilados ylinkados(enlazados) con el resto de la aplicacion. Los stubs son invocadoscuando el programa cliente llama a una funcion que debe ser atendida por elprograma servidor RPC remoto. Este mecanismo se muestra en la figura 3.9.Las llamadas RPC son llamadas sıncronas entre clientes y servidores, aun-que algunos vendedores ofrecen funcionalidad asıncrona. Cuando una funcionremota es invocada, el procedimiento que llama (cliente) debe esperar al ser-vidor para que termine de procesar la funcion antes de que se devuelva elcontrol a la aplicacion cliente. Notese que la llamada a la funcion bloqueahasta que la aplicacion servidor responde. Este mecanismo puede encadenar-


se si el servidor es a la vez cliente de otra aplicacion e invoca otro servidorremoto cuando sirve la llamada original.

La ventaja del mecanismo RPC es que enmascara las llamadas a funcionescomo si fueran locales aunque el funcionamiento interno del servicio detras dela llamada enmascarada es bastante complejo. Los argumentos de la funciondeben ser procesados, se debe enviar un mensaje al servicio RPC remoto don-de se implementa la funcion, y debe devolverse una respuesta. Esto se realizageneralmente de una manera sıncrona, por lo que existe un alto acoplamientoentre los programas cliente y servidor siendo posible que un cliente perma-nezca largo tiempo bloqueado en una llamada a un procedimiento muy largo.Para mantener al sistema en funcionamiento con este tipo de infraestructurala unica solucion es la programacion concurrente, creando multiples hilos deejecucion concurrente en el sistema, y con ello aumentando la complejidad.

La mayor desventaja de RPC es que resulta un mecanismo de un nivel re-lativamente bajo. Los detalles del sistema de comunicaciones que subyacenteestan muy poco escondidos del desarrollador. Las llamadas a procedimientosremotos proporcionan soporte para una aproximacion procedimental al de-sarrollo de sistemas, y mientras que en algunos casos esto puede ser bueno,hay una gran cantidad de situaciones en las que una aproximacion basada enobjetos o componentes es significativamente mejor. Al ser sıncrono el modelode comunicaciones se incrementa la complejidad del desarrollo en el caso deque se deban realizar llamadas a procedimientos muy largos.

Existe una variedad de vendedores en el mercado que proporcionan sof-tware RPC tanto con funcionalidad sıncrona como asıncrona, encontrandoseentre ellos los siguientes productos:

Entegrity Solutions Gradient RPC. Entegrity proporciona solucio-nes B2B (de empresa a empresa) basadas en DCE RPC. La diferenciaentre Gradient RPC y productos RPC anteriores es que las comunica-ciones empleadas por RPC son seguras como requieren las comunica-ciones entre empresas.

DCE de Compaq (HP). Compaq vende productos RPC basadosen el RPC de Open Group para los Sistemas Operativos OpenVMS yTrue64 UNIX.

RPC de Sun. Puesto que hoy en dıa la companıa esta orientada allenguaje java, ofrece productos RPC que exponen un API Java para


Figura 3.10: Arquitectura del MOM

RPCs basados en XML (JAX-RPC). Los RPCs basados en XML sonllamadas a procedimiento remoto especıficamente disenados para serinvocados a traves de Internet. Por esta razon, el protocolo de trans-porte empleado es HTTP y la codificacion es XML. De ahı su nombreXML-RPC. El proposito de este producto es la interoperabilidad entreservicios web de diferentes plataformas y lenguajes.

3.6.3. Middleware Orientado a Mensajes

El MOM es una arquitectura cliente/servidor que soporta invocacionesasıncronas entre clientes y servidores. En un MOM los mensajes no se envıandirectamente al servidor, sino que existe una cola de mensajes en los lados delcliente y del servidor (Ver figura 3.10) El proposito de esta cola es almacenarlos mensajes en el caso de que la aplicacion o proceso receptor se encuentreocupado realizando otra tarea. Una vez que el emisor lanza el mensaje se pue-de continuar su proceso. La cola que almacena el mensaje intentara enviarloal proceso receptor hasta que el mensaje sea aceptado.

La ventaja del MOM reside en que desacopla los clientes de los servidorespor medio de colas. Esta arquitectura permite a las aplicaciones basadas enMOM procesar una gran cantidad de mensajes, puesto que estos seran al-macenados en colas y seran procesados cuando los recursos computacionalesesten disponibles. La mayorıa de MOMs aceptaran mas de un proceso le-yendo mensajes de la cola, siendo el sistema capaz de adaptar el proceso delos mensajes al numero de mensajes mantenidos en la cola. La mayorıa deimplementaciones tambien permiten en transporte de mensajes sıncrono.


Los MOMs se adaptan bien a sistemas orientados a objetos y a aplicacio-nes controladas por eventos. Para sistemas orientados a objetos, el paso demensajes implementado por los MOMs se ajusta bien al modelo de comu-nicaciones descentralizado entre objetos. En el caso de sistemas controladospor eventos, los mensajes se pueden pasar a la infraestructura MOM cuandoocurre el evento. La responsabilidad de entregar el mensaje reside ahora en elmiddleware, y el cliente puede continuar su proceso. Puesto que el proceso decomunicacion ya no bloquea, existe un peligro potencial de sobrecargar la redenviando miles de mensajes a un servidor que esta bloqueado o simplementeque no puede seguir el ritmo de mensajes de llegada. Esta situacion se corri-ge en la mayorıa de MOMs estableciendo un proceso de mensajes sıncronocuando tal situacion es detectada. A diferencia de los RPCs que siempre blo-quean (aunque como se ha mencionado existen vendedores que proporcionanimplementaciones asıncronas), los MOMs proporcionan una alternativa masflexible para el desarrollo de sistemas. Notese que los MOMs resultan espe-cialmente adecuados para aplicaciones cuyos modulos cooperan con un ciertogrado de independencia y donde el servidor puede no estar disponible en elmomento de entrega del mensaje. Por esta razon es una tecnologıa apreciadapara integracion de aplicaciones empresariales (EAI).

Entre los vendedores que dominan el mercado se encuentran los siguientes:

IBM MQSeries: Este MOM ha sido disenado para integrar entornosheterogeneos y soporta mas de 35 plataformas diferentes. El MOMofrece una API llamada Interfaz de Cola de Mensajes (MQI) que debeser usada por todas las aplicaciones que quieren comunicarse con otrossistemas. MQSeries soporta especificaciones como XML o el Serviciode Mensajes Java (JMS).

Software AG EntireX: EntireX es un producto de integracion deaplicaciones basadas en componentes en un software broker servidorde mensajes. Este MOM maneja informacion de seguridad y soportamodelos de comunicaciones sıncronas y asıncronas.

TIBCO Enterprise Message Service, SmartSockets y Rendez-vous: TIBCO manufactura software para mensajerıa y productos mul-ticast.


3.6.4. Middleware Orientado a Objetos y Componen-tes

El concepto clave del middleware orientado a objetos y a componenteses el de interfaz. En este middleware se accede a cada servicio a traves deinterfaces y las aplicaciones que acceden al servicio no necesitan conocer losdetalles de la implementacion. Naturalmente este concepto es establecido porel concepto de objeto. Hay varias razones que respaldan la promocion de estetipo de middleware:

La mayorıa de los lenguajes de programacion no soportan la construc-cion de sistemas distribuidos.

El modelo de componente u objeto por sı mismo no soporta la distri-bucion a traves de los contornos de una maquina.

Los grandes sistemas se construyen en multiples lenguajes de progra-macion, Sistemas Operativos y plataformas. Estan basados en entornosheterogeneos.

Las razones anteriores conducen a lo que se conoce como sistemas “stovi-pe”. Sistemas que se desarrollan ad-hoc, con soluciones de integracion pro-pietarias. En lugar de esto, el middleware orientado a objetos define los re-quisitos para construir sistemas donde hay una manera estandar de trabajaren red y donde hay interfaces estandar para acceder a los servicios comunesde la infraestructura. En el middleware orientado a objetos hay un soportepara el modelo de programacion orientado a objetos de forma que se puedeaplicar los mismos beneficios que tienen los sistemas de objetos a este tipode middleware. El mas importante es que los sistemas de objetos represen-tan adecuadamente las entidades del mundo real, que son distribuidas pornaturaleza. La figura muestra una arquitectura general para el middlewareorientado a objetos.

El Middleware orientado a Objetos emplea un Gestor Orientado a Objetos(OOM) o un Broker de Solicitudes a Objetos (ORB) como una capa de sof-tware mediadora entre los objetos locales y los remotos. Los objetos remotosexponen sus interfaces a las que se puede acceder como si fueran objetoslocales. Por ello se accede al interfaz de objetos remotos localmente a travesde un objeto “proxy”. El objeto proxy tiene la responsabilidad de enviar lapeticion de la invocacion a la capa de middleware para que pueda llegar alobjeto remoto. Se puede pensar en el Broker de Solicitudes a Objetos (ORB)


como si fuera un bus de software, que realizara las acciones necesarias parallevar a cabo correctamente la peticion realizada. El mecanismo basico parala comunicacion son las invocaciones de metodos remotos. Los objetos remo-tos se pueden identificar unicamente por medio de referencias a objetos. Elmiddleware orientado a objetos tiene varias diferencias respecto a otros tiposde middleware.

No se diferencia entre clientes y servidores. En el middlewareorientado a objetos unicamente existen objetos que proporcionan ser-vicios y que reciben servicios de otros objetos.

Transparencia de localizacion. El empleo de un proxy desacopla alusuario del servicio del proveedor del mismo. Cuando esta implemen-tado proporciona la ventaja de que la localizacion del servicio se puederealizar independientemente del usuario del servicio.

Se puede posponer el diseno del servicio distribuido. Los serviciosson proporcionados por los objetos y la transparencia de la localizaciones una de las propiedades del middleware, los usuarios de los serviciosdesconocen la localizacion de los recursos computacionales del servi-cio. El sistema se puede desarrollar localmente y se puede retrasar ladistribucion del sistema hasta la prueba del mismo. Este sistema espercibido como un todo por los objetos, de forma similar a un sistemamonolıtico.

Migracion de objetos. Los objetos del sistema se puede mover dinami-camente sin afectar a los usuarios de los servicios que proporcionan.Esto se logra por medio de los servicios comunes construidos en la ca-pa de middleware. Tomando como ejemplo el caso del broker CORBA,este es capaz de enviar un mensaje “locate forward” para senalar unanueva referencia a un objeto en el caso de que el objeto no se encuentreen su ubicacion anterior.

Concepto de servicios. El middleware orientado a objetos introduceel concepto de servicios comunes. Estos servicios pueden ser propor-cionados de la manera habitual (por ejemplo, los vendedores puedenempaquetar los servicios con sus productos). Ejemplos de estos servi-cios son el servidor de nombres, el servidor de eventos, el servidor delciclo de vida del objeto, etc.

La arquitectura del sistema es abierta y escalable. Los sistemas deobjetos distribuidos son capaces de escalar sin modificar la estructura


subyacente del sistema o su arquitectura. El sistema crece simplementeincrementando el numero de objetos.

Independencia de los lenguajes de programacion y las plata-formas de hardware. El concepto clave es la interfaz. El Middlewarede Objetos Distribuidos emplea el Lenguaje de Definicion de Interfa-ces (IDL) para definir interfaces de objetos. El concepto de interfazes util porque permite definir un modelo de objeto comun que es ex-presado mediante el Lenguaje de Definicion de Interfaces (IDL). IDLes independiente de los lenguajes de programacion y de los detalles dela implementacion. A nivel de programacion, IDL se traza a cualquiernumero de lenguajes de programacion por medio de compiladores IDL,haciendo al sistema independiente de los lenguajes y las implementacio-nes de hardware particulares. El codigo generado por los ficheros IDLcontiene un codigo proxy que es empleado para acceder localmente alos objetos remotos (stubs) y las plantillas (templates) de los serviciosde objetos remotos que se implementan (skeletons).

Hay tres aproximaciones diferentes para el middleware orientado a objetosque dominan el mercado: CORBA del OMG, Java/RMI de Sun y DCOMde Microsoft. Cada una de ellas presenta sus ventajas y sus inconvenientes,como veremos en las proximas secciones. En lıneas generales podemos decirque:

Microsoft: proporciona el middleware DCOM, que ahora forma partede la tecnologıa .NET. Este software propietario es utilizado en cercade 150 millones de sistemas en todo el mundo; tiene una especificacionbien definida y estable, y proporciona el mayor numero de servicios yherramientas de desarrollo.

OMG: proporciona la especificacion del middleware CORBA (Com-mon Object Request Broker Architecture). Es un estandar no propie-tario, basado en necesidades especıficas de la industria. Es una arqui-tectura extensible y compatible con una gran variedad de plataformas,independiente del lenguaje de implementacion, y proporciona multiplesservicios.

Sun: proporciona Java RMI (Remote Method Invocation). Se usa fun-damentalmente en aplicaciones relacionadas con el Web; emplea el len-guaje Java como lenguaje de implementacion, que esta ampliamenteextendido por todo el mundo.


3.6.5. COM y DCOM

El Component Object Model (COM), es la tecnologıa de componentes desoftware de Microsoft (ver [16]). Aunque inicialmente fue creado para resolverlos problemas causados por el uso de Dynamic Data Exchange (DDE) comomecanismo de comunicacion entre procesos (Inter Process CommunicationIPC) en la construccion de documentos con Object Linking and Embedding(OLE) en Windows 3.1, este modelo ha sido enriquecido con el proposito depermitir la construccion de aplicaciones a partir de componentes.

COM es esencialmente un esquema de integracion, de modo que los compo-nentes que se construyen para trabajar bajo este modelo, deben describir sucomportamiento bajo las consideraciones de este esquema, el cual es cono-cido popularmente como estandar binario. Este estandar permite que lasinterfaces de los componentes se presenten a los clientes como un conjuntode apuntadores a tablas en memoria, llamadas tablas virtuales de funciones,Virtual Function Tables o vtables, como muestra la figura 3.11. La llama-da de funciones entre componentes se realiza utilizando estos apuntadores,ocultandose ası detalles de la implementacion, lo cual permite que compo-nentes que esten escritos en diferentes lenguajes de programacion de los quese pueden incluir a C++, Small Talk, Ada, Visual Basic, Delphi o PowerBuilder, puedan comunicarse.

Figura 3.11: Esquema de interfaz y VTable

Dadas las caracterısticas de las vtables, las interfaces no pueden definirseutilizando herencia multiple, porque se debe considerar la posibilidad de tenervarias vtables y mas de un apuntador por interfaz.

Los interfaces COM se definen utilizando un lenguaje especial denominadoIDL. La compilacion de estas interfaces, produce una especie de librerıas quecontienen informacion sobre los metadescriptores del objeto, de sus interfaces,


de las estructuras definidas por el usuario y de los elementos referidos por elcomponente, ası como un mapa de memoria para las operaciones publicas.

Figura 3.12: Arquitectura de un sistema DCOM

Distributed COM, mejor conocido como DCOM, es una extension de COMque se implementa como respuesta a la necesidad de aplicaciones distribuidas,proporcionando capacidades para el trabajo con componentes que residen endiferentes computadoras. DCOM utiliza como mecanismo de transporte lasLlamadas a Procedimientos Remotos (RPC), los cuales son transparentespara el cliente. Podemos ver un esquema de la arquitectura DCOM en lafigura 3.12. La evolucion de COM y MTS (Microsoft Transaction Server)recibe el nombre de COM+.

Tanto COM como DCOM son modelos que inicialmente fueron implemen-tados para trabajar bajo entornos Windows y Windows NT, sin embargoexisten versiones para trabajar con Mac OS y UNIX. Como se menciono ini-cialmente el funcionamiento de COM y DCOM, se basa estrictamente en elestandar binario, por lo que los componente construidos para estos modelosno son del todo independientes de la plataforma, y en caso de migrar a otrosentornos, para poder utilizar los componentes, estos necesitan ser recompila-dos para la plataforma en que se van a utilizar, o bien se necesita disponerdel interprete del formato binario correspondiente.


3.6.6. RMI

Java / RMI es la infraestructura basica de la arquitectura de componentesdistribuidos de Sun. Java es un lenguaje orientado a objetos, interpretado, ydisenado desde sus orıgenes para ser usado en aplicaciones distribuidas y serportable entre plataformas (ver [32]). La portabilidad de Java se fundamentaen el concepto de maquina virtual. Todo el software Java se ejecuta, teori-camente, sobre la misma plataforma software, la maquina virtual de Java(JVM), que se asienta sobre el sistema operativo.

Inicialmente Sun llamo a las Librerıas de Clases y a la Maquina Virtualde Java (JVM) con el nombre Java Development Kit (JDK). En 1999, elJDK fue extendido y renombrado como Java 2 Platform. Existen diferen-tes versiones de la plataforma, dependiendo de la aplicacion, para clientes,servidores o dispositivos mobiles. La plataforma Java mas popular es J2EE,Java 2 Platform Entreprise Edition ver figura 3.13, que es una ampliacionde J2SE, Java 2 Platform Standard Edition figura 3.14.

RMI (Remote Method Invocation) es un mecanismo que permite realizarllamadas a metodos de objetos remotos situados en distintas (o la misma)maquinas virtuales Java, compartiendo ası recursos y carga de procesamientoa traves de varios sistemas.

RMI permite exportar objetos como objetos remotos, para que otro procesoremoto pueda acceder directamente como un objeto Java. Todos los objetosde una aplicacion distribuida basada en RMI deben ser implementados enJava. Esta es una de las principales ventajas de RMI, ya que RMI forma partedel API de Java, con lo que la integracion de objetos remotos en aplicacionesdistribuidas se realiza sin necesidad de usar recursos adicionales (como porejemplo un lenguaje de descripcion de interfaces o IDL). De hecho, se utilizala misma sintaxis para una llamada a un objeto remoto o un objeto local. Lafigura 3.15 ilustra los componentes implicados en un sistema RMI: un interfazremoto, un cliente, y uno o mas servidores (objetos remotos) residentes enun host.

El cliente invoca a los objetos remotos mediante la interfaz remota. Unservicio de nombres (registro RMI) reside en el host proporcionando el meca-nismo que el cliente usa para encontrar uno o mas servidores iniciales RMI.


Figura 3.13: Diagrama de la plataforma J2EE5

Figura 3.14: Diagrama de la plataforma J2SE5


Figura 3.15: Aplicacion distribuida RMI

La interaccion con el objeto remoto se lleva a cabo a traves de la interfazremota, ver figura 3.16. Esencialmente, esta describe los metodos que puedenser invocados de forma remota, y que el objeto remoto implementa. Cuandose obtiene una referencia a un objeto remoto, el objeto no se envıa a travesde la red al cliente que lo solicita. En su lugar se genera un objeto proxyo stub que constituye el proxy de la parte del cliente del objeto remoto.Todas las interacciones del cliente se realizaran con esta clase stub, la cual esresponsable de gestionar los datos entre el sistema local y el remoto. Muchosclientes pueden tener referencias a un unico objeto remoto. Cada cliente tienesu propio objeto stub que representa al objeto remoto, pero dicho objetoremoto no se replica.

Figura 3.16: Relacion entre varias clases e interfaces del sistema RMI

En la parte del servidor, una clase skeleton es la responsable de gestionarlas llamadas al metodo y los datos enviados al objeto real referenciado. Estees el proxy de la parte del servidor para el objeto remoto.

El sistema completo puede verse como un modelo de cuatro capas, tal ycomo se ilustra en la figura 3.17.


Figura 3.17: Arquitectura RMI. Modelo de 4 capas

La primera capa o capa 1 es la de aplicacion, y se corresponde con laimplementacion real de las aplicaciones cliente y servidor. Aquı tienen lugarlas llamadas a alto nivel para acceder y exportar objetos remotos. Cual-quier aplicacion que quiera que sus metodos esten disponibles para su accesopor clientes remotos debe declarar dichos metodos en una interfaz que ex-tienda java.rmi.Remote. Dicha interfaz se usa basicamente para marcarun objeto como remotamente accesible. Una vez que los metodos han sidoimplementados, el objeto debe ser exportado. Esto puede hacerse de formaimplıcita si el objeto extiende la clase UnicastRemoteObject (paquetejava.rmi.server), o puede hacerse de forma explıcita con una llamada almetodo exportObject() del mismo paquete. La capa 2 es la capa proxy,o capa stub-skeleton. Esta capa es la que interactua directamente con la ca-pa de aplicacion. Todas las llamadas a objetos remotos y acciones con susparametros y retorno de objetos tienen lugar en esta capa.

La capa 3 es la de referencia remota, y es responsable del manejo dela parte semantica de las invocaciones remotas. Tambien es responsable dela gestion de la replicacion de objetos y realizacion de tareas especıficasde la implementacion con los objetos remotos, como el establecimiento delas persistencias semanticas y estrategias adecuadas para la recuperacion deconexiones perdidas. En esta capa se espera una conexion de tipo stream(stream-oriented connection) desde la capa de transporte.

La capa 4 es la de transporte. Es la responsable de realizar las conexionesnecesarias y manejo del transporte de los datos de una maquina a otra.El protocolo de transporte subyacente para RMI es Java Remote MethodProtocol (JRMP), que solamente es “comprendido” por programas Java.


3.6.7. CORBA

CORBA, como middleware, tiene algunas ventajas respecto a sus compe-tidores:

COM es un software propietario, poco documentado, y difıcilmenteextensible.

RMI obliga a emplear Java como lenguaje de implementacion.

CORBA es facilmente extensible y portable.

CORBA permite utilizar muchos lenguajes de implementacion.

No se detalla mas esta tecnologıa en este capıtulo, ya que se dedica a ellotoda la parte III de esta memoria.

Capıtulo 4

Sistemas de tiempo real

El enorme aumento de la necesidad de considerar las caracterısticas detiempo real en los sistemas de control, especialmente crıtico en determinadossectores de la industria (por ejemplo la industria aeroespacial) ha sido unfactor crıtico en la evolucion de los mismos. En muchos sistemas de controllos tiempos de calculo y/o ejecucion de tareas no son solo importantes, sinocrıticos, de manera que si el sistema no consigue terminar una tarea en undeterminado lımite de tiempo, se considera un error grave de funcionamiento,y no simplemente un problema de bajo rendimiento.

El Diccionario de Computacion de Oxford define estos sistemas como cual-quier sistema en el cual el tiempo en que se produce cada salida del sistemaes significativo. Esto se debe normalmente a que las entradas corresponden aalgun cambio en el mundo fısico, y las salidas deben referirse a dicho cambio.Por ello, el tiempo transcurrido desde el instante en que se produce la entra-da, al instante en que se produce la salida, debe ser suficientemente ajustadopara que el funcionamiento del sistema pueda considerarse adecuado. Cuan-do decimos “suficientemente ajustado”, estamos hablando de un valor quedepende por completo de la aplicacion del sistema de tiempo real: por ejem-plo, si hablamos de un sistema de guıa de misiles, podrıamos pensar que lasalida del sistema debe producirse en un tiempo maximo de milisegundos;pero si en cambio nos referimos a un sistema de control en una fabrica demuebles, este tiempo puede ser de, por ejemplo, uno o dos segundos.

El hecho de que un sistema sea de tiempo real no implica que el sistemasea rapido, sino que debe ejecutar sus tareas en un determinado tiempo queha sido especificado previamente en relacion con la planta. Dicho de otraforma, un sistema de tiempo real es un sistema predecible, en el sentido deque somos capaces de calcular en todo momento el tiempo que tardara el

61

62 CAPITULO 4. SISTEMAS DE TIEMPO REAL

Figura 4.1: Ejemplo sencillo de control de procesos

sistema en realizar una determinada tarea (o al menos una cota superior dedicho tiempo). En resumen, en estos sistemas, no solo es importante que lasalida del sistema sea la esperada, sino tambien que dicha salida sea obtenidaen el instante esperado.

4.1. Aplicaciones de los sistemas de tiempo

real

Este tipo de sistemas se puede emplear en numerosas aplicaciones de ındolemuy variada, por lo que nos limitamos a comentar los tres sectores en los quetienen un uso mayor:

4.1.1. Control de procesos

Fue una de las primeras aplicaciones de los sistemas de tiempo real. Po-demos poner un ejemplo con un sistema de control que debe garantizar unflujo de lıquido lo mas estable posible a traves de una tuberıa que alimen-ta una determinada maquina, empleando un sensor de caudal y actuandosobre una valvula de regulacion. El sistema esta representado en la figura4.1. Cuando el controlador detecta una subida del caudal, debe respondercerrando la valvula, y esta respuesta debe ocurrir en un tiempo lımite deter-

4.2. CARACTERISTICAS DE LOS SISTEMAS DE TIEMPO REAL 63

minado para evitar que el equipo que es alimentado a traves de la tuberıano se vea sobrecargado. La respuesta del controlador puede requerir ciertoscalculos complejos para determinar el angulo que debe adoptar la valvula deregulacion.

4.1.2. Fabricacion

En este sector es importante garantizar una productividad alta y costesde produccion optimos mediante el uso de sistemas de tiempo real. General-mente se emplean procesadores para integrar el sistema de fabricacion, conalgoritmos y estrategias de planificacion de la produccion. Estas activida-des implican grandes tiempos de calculo y muchas veces requieren ordenese informaciones precisas y que deben llegar a su destino en un tiempo de-terminado. Un ejemplo de estos sistemas puede ser una cadena de montaje,alimentada con piezas que deben ser ensambladas. El control de producciondebe coordinar varias lıneas de ensamblado de manera que no se produzcanembotellamientos o que evite que alguna maquina quede sin alimentacion.

4.1.3. Comunicaciones y control

Existe un gran numero de sistemas que deben ser controlados garantizandoun funcionamiento preciso y eficaz: sistemas de vuelo, instalaciones medicas,control de trafico aereo, gestiones financieras, etc. Todos estos sistemas em-plean polıticas y estrategias complejas, y manejan grandes cantidades deinformacion.

4.2. Caracterısticas de los sistemas de tiempo

real

Ademas de la propiedad fundamental de los sistemas de tiempo real, lasrestricciones de tiempo ya comentadas, estos sistemas tienen algunas carac-terısticas que se enuncian a continuacion, si bien no todos tienen por que tenertodas ellas.

Tamano y complejidad. Debido a que estos sistemas deben interaccio-nar normalmente con entornos complejos y gestionar gran cantidad desenales e informacion, con frecuencia resultan ser sistemas grandes ycomplejos, que requieren ademas un gran esfuerzo de mantenimiento yadaptacion.


Potencia de calculo. Muchos sistemas de tiempo real implican el controlde alguna actividad de ingenierıa. Dependiendo del algoritmo y lasestrategias de control elegidas, puede ser necesaria una potencia relati-vamente grande.

Seguridad y fiabilidad. En determinadas aplicaciones es fundamental queel sistema garantice un funcionamiento correcto y seguro, ya que unfallo o una respuesta tardıa puede supone graves danos a personas odanos materiales. Estos sistemas deben estar disenados de manera quepuedan reaccionar en cierta medida a los imprevistos, y en caso de fallo,llevar el sistema controlado a una situacion segura.

Concurrencia. En los sistemas con varios procesadores es necesario con-trolar el acceso a los diferentes recursos y dispositivos del sistema decontrol y el sistema controlado. La dificultad para asegurar el accesocorrecto a los mismos, crece a medida que aumenta la complejidad delsistema.

Interaccion con hardware. Estos sistemas casi siempre deben interaccio-nar con dispositivos de hardware: monitorizacion de sensores, controlde actuadores, y una gran variedad de dispositivos.

4.3. Tiempo real duro y blando

Los sistemas de tiempo real se pueden clasificar en dos categorias: siste-mas de tiempo real duro (hard real-time), y sistemas de tiempo real blando(soft real-time). Los sistemas de tiempo real duro son aquellos en los quelos tiempos lımites de tiempo (deadlines) establecidos para las operacionesson imperativos y no pueden sobrepasarse bajo ningun concepto. Por contra,los tiempos lımites de respuesta de los sistemas de tiempo real blando, aunsiendo importantes, pueden sobrepasarse de vez en cuando (generalmentese especifica un porcentaje admisible del numero de veces que esto ocurre).En la figura 4.2 puede verse un diagrama en el cual las graficas indican dosrestricciones de tiempo o deadlines ; la primera corresponde a un sistema detiempo real duro, y por tanto indica un tiempo lımite fijo y concreto. La se-gunda en cambio, corresponde a un sistema de tiempo real blando y permitecierta variacion del tiempo lımite dentro de unos margenes establecidos.

En la figura treal es el lımite que tarda una tarea determinada en realizarse(color azul), mientras que tmax es el tiempo lımite establecido (color rojo) paradicha tarea. En el caso del sistema de tiempo real blando, no existe un unico

4.4. RESTRICCIONES DE TIEMPO 65

Figura 4.2: Deadlines duras y blandas

lımite de tiempo sino que se emplea el rango tmax,1−tmax,2. el funcionamientodel sistema sera considerado aceptable siempre y cuando treal se mantengadentro de dicho rango. La eficiencia de la tarea desciende conforme se alejade tmax,1 y se acerca a tmax,2. Es decir, en un sistema de tiempo real blandono hay un lımite de tiempo fijo pero sı hay una variacion de la “calidad” dela tarea, aunque esta se realice en un tiempo adecuado.

4.4. Restricciones de tiempo

En un caso general, las restricciones de tiempo en un sistema de tiemporeal se especifican de la siguiente forma:

1. Tiempo de inicio mas temprano: indica el tiempo absoluto antes delcual una actividad no deberıa comenzar.

2. Tiempo de inicio mas tardıo: indica el tiempo absoluto antes del cualdebe comenzar la actividad. Si no lo hace, se produce un error.

3. Tiempo lımite: tiempo absoluto antes del cual la actividad debe haberterminado.

El tiempo de inicio mas tardıo puede utilizarse para detectar posibles vio-laciones del tiempo lımite de una actividad, antes de que se produzcan.


Muy a menudo las restricciones de tiempo se expresan en forma de restric-ciones periodicas, es decir, especifican tiempos de inicio y tiempos lımite quese repiten a intervalos regulares en el tiempo.

4.5. Predecibilidad

En un sistema de tiempo real debe ser posible determinar los tiempos deejecucion de las actividades antes de que estas se realicen (usualmente du-rante la fase de diseno); es decir, el sistema debe ser predecible. Para analizarlos tiempos de ejecucion, se debe conocer el algoritmo de planificacion queemplea el sistema, y la cantidad de tiempo que requiere cada actividad paraser realizada; estos valores deben ser los correspondientes al “peor caso”, esdecir, valores pesimistas para garantizar la validez del analisis a pesar de lainevitable variabilidad de los tiempos previstos.

4.6. Planificacion

La planificacion en sistemas de tiempo real es importante ya que es labase para garantizar la ejecucion de las tareas en los tiempos adecuados. Elproblema de la planificacion en estos sistemas se trata como el llamado binpacking problem, el cual consiste en distribuir de forma optima, un conjuntode “objetos” o “cajas” de tamano variable, en un conjunto de receptaculosde tamano fijo. Es este caso las actividades, que requieren una cantidad derecursos conocida, hacen las veces de cajas y las restricciones de tiempo de-terminan el tamano de los receptaculos. La planificacion es un problema dela clase NP-duro, pero puede utilizarse algoritmos heurısticos para alcanzardistribuciones optimas de las actividades bajo ciertas condiciones, o distri-buciones casi optimas bajo condiciones menos restrictivas.

Normalmente un algoritmo de planificacion asigna prioridades a las acti-vidades de forma que se crea una ordenacion parcial de las mismas. Cuandova a tomar una decision el planificador selecciona las actividades con ma-yor prioridad en primer lugar. Podemos encontrar varias caracterısticas quediferencian los algoritmos de planificacion:

Reemplazables o No reemplazables: si el algoritmo es reemplazable, laactividad que esta utilizando un recurso en el instante actual puede serreemplazada por otra actividad de mayor prioridad.

4.7. SINCRONIZACION 67

Tiempo real duro o blando: si se emplea tiempo real duro, la predeci-bilidad de los tiempos es un factor fundamental en el algoritmo; en eltiempo real blando la predecibilidad es deseable pero no imprescindible.

Dinamicos o estaticos: en los algoritmos estaticos, todas las actividadesy sus caracterısticas son conocidas antes de comenzar a planificar. Enla planificacion dinamica, las prioridades y caracterısticas de las acti-vidades pueden cambiar durante la planificacion.

Recurso unico o multiples recursos: el uso de un unico recurso (CPUpor ejemplo) o de varios.

Para un conjunto de actividades independientes y periodicas con tiemposde ejecucion conocidos, se ha demostrado que el algoritmo de asignacionde prioridad de tasa monotonica es optimo. Este algoritmo es preventivo,estatico, disenado para un unico recurso (CPU) y puede ser utilizado paraaplicaciones de tiempo real duro. La prioridad es asignada de acuerdo con latasa de repeticion de cada actividad periodica: cuanto mayor es la tasa (menorel perıodo), mayor es la prioridad asignada. Tambien se ha demostrado quesi el porcentaje de uso de la CPU es menor de aproximadamente un 69%, lasactividades se terminan todas antes de alcanzar sus tiempos lımite. Existeun algoritmo derivado de la asignacion segun la tasa monotonica, llamadoplanificacion monotonica con tiempos lımite, en el cual la mayor prioridad seasigna al tiempo lımite mas cercano.

4.7. Sincronizacion

Existen multiples metodos para permitir la sincronizacion entre multiplesprocesos. Entre los metodos mas habituales de sincronizacion explıcita seencuentran los siguientes:

Semaforos

Mutexes

Locks de lectura/escritura

Se puede usar un semaforo para resguardar el acceso a un recurso, o alter-nativamente, para permitir a los procesos esperar la ocurrencia de un evento.Las operaciones sobre el semaforo incrementan y decrementan el valor enteroasociado con el semaforo. Cuando un proceso realiza la llamada sem wait()


a un semaforo cuyo valor es positivo, el proceso continua, decrementando elvalor del semaforo (posiblemente a cero). Si el valor del semaforo es cero,entonces el proceso es bloqueado y anadido a una pila de procesos que es-peran al semaforo, y no se le permite proceder hasta que otro proceso llamaa la funcionsem post(). Si un proceso llama a la funcion sem post() y nohay ningun proceso esperando al semaforo, entonces el valor del semaforo esincrementado.

Los mutexes proporcionan exclusion mutua para el acceso a una estruc-tura de datos en particulas. Los mutexes estan ıntimamente ligados a la ideade secciones crıticas de codigo.

Los bloqueos de lectura/escritura permiten cualquier numero de lectores(procesos mirando los datos compartidos, pero sin cambiarlos) en un momen-to dado, pero obliga a un proceso que quiera cambiar los datos (un escritor) aesperar hasta que no haya lectores. A la inversa, si hay un escritor cambiandolos datos, entonces todos los lectores que vienen despues estan bloqueadoshasta que el proceso escritor termina su trabajo. Existen por tanto dos cla-ses diferentes de bloqueos asociados con un bloqueo de lectura/escritura, unbloqueo de lectura y un bloqueo de escritura.

4.8. Temporizadores

Las facilidades setitimer() y getitimer() estandar de UNIX proporcio-nan acceso a tres temporizadores: ITIMER REAL, ITIMER VIRTUALe ITIMER PROF. Estas funciones carecen de algunas caracterısticas nece-sarias o deseables en Sistemas operativos de tiempo real. Para poder obtenerestas caracterısticas se pueden usar las facilidades POSIX de tiempo real,que tienen las siguientes ventajas:

Soporte de relojes adicionales, ademas de ITIMER REAL,ITIMER VIRTUAL e ITIMER PROF.

Permiten una mayor resolucion del tiempo (los temporizadores moder-nos son capaces de resoluciones de nanosegundos, el hardware debesoportarlo).

Habilidad para detectar overruns (lo que sucede cuando el temporiza-dor se dispara varias veces sin que el programa sea capaz de manejarla senal).

4.9. BLOQUEO DE MEMORIA 69

Posibilidad de usar otras senales ademas de SIGALRM para indicar lafinalizacion del plazo de tiempo.

Para ello se usan las funciones cuya declaracion se adjunta a continuacion:

#include <unistd.h>#ifdef _POSIX_TIMERS#include <signal.h>#include <time.h>

/* Getting and Setting Clocks */int clock_settime(clockid_t clock_id,const struct timerspec *current_time);int clock_gettime(clockid_t clock_id, struct timespec *current_time);int clock_getres(clockid_t clock_id, struct timespec *resolution);

/* One-Shot and Repeating Timers */int timer_create(clockid_t clock_id,const struct sigevent *signal_specification,timer_t *timer_id);int timer_settime(timer_t timer_id, int flags,const struct itimerspec *new_interval,struct itimerspec *old_interval);int timer_gettime(timer_id, struct itimerspec *cur_interval);int timer_getoverrun(timer_t timer_id);int timer_delete(timer_t timer_id);

/* High-Resolution sleep */int nanosleep(const struct timespec *requested_time_interval,struct timespec *time_remaining);

#endif /* _POSIX_TIMERS */

4.9. Bloqueo de memoria

Un obstaculo que se puede interponer en la correcta ejecucion de un pro-grama de tiempo real es la memoria virtual y el mecanismo de swapping.Este mecanismo permite ejecutar un numero de aplicaciones que requieremas memoria que la disponible fısicamente en el sistema. Para ello el Sis-tema operativo mueve paginas de memoria de las aplicaciones al disco durocuando estas no son usadas y reutiliza esta memoria para otros procesos quenecesitan mas memoria. Empleando las funciones mlock() y mlockall() po-demos evitar que la memoria de una aplicacion cuyo tiempo de respuesta seacrıtico se almacene en el disco, con los tiempos de acceso que ello implica,puesto que son muy superiores a los tiempos de acceso a memoria.

Capıtulo 5

Sistemas de control de robots

En este capıtulo se hace un repaso a la percepcion de los robots mediantesensores, los sistemas de navegacion que incorporan los robots moviles, y secomentan diversas soluciones para la integracion del software empleado paracontrolar robots, ası como la cooperacion entre multiples robots. El capıtulofinaliza con una enumeracion de varias soluciones existentes para control derobots.

5.1. Sensores

Los robots moviles estan equipados con diversos sensores (ultrasonidos, in-frarrojos) alrededor de su cuerpo para permitir una vision general de su en-torno. El comportamiento de este tipo de sensores y sus limitaciones esta am-pliamente descrito en la literatura [65], [55]. Cuando se emplean simultanea-mente varios sensores del mismo tipo se pueden producir errores en las medi-das, debido al hecho de que las senales sufren reflejos o que un sensor recibela senal de otro sensor.

Se han desarrollado diversos algoritmos y metodos para permitir selec-cionar la informacion fiable o para eliminar aquella que puede considerarseerronea. En [38] se propone el metodo Error Eliminating Rapid UltrasonicFiring (EERUF) [4] para eliminar las interferencias que se producen entresensores de ultrasonidos cuando se usan a la vez. [56] propone un metodopara solucionar el problema de los reflejos designado como “the specular re-flection probability method” o “El metodo de las probabilidades de los reflejosespeculares” y [53] propone el “distance measurement method” o “metodo demedida de distancias”. Cuando deseamos controlar varios robots en un mismoentorno, se hace necesario coordinar el uso de sensores activos (ultrasonidos

71

72 CAPITULO 5. SISTEMAS DE CONTROL DE ROBOTS

o infrarrojos) para evitar que haya interferencia entre senales de distintosrobots cercanos [145]. Esto supone coordinacion no solo local -un solo robot-sino distribuida.

5.2. Navegacion

La odometrıa es informacion relativa de navegacion que nos indica cuantonos hemos movido, pero no donde nos encontramos. Si conocemos nuestropunto de partida, podemos anadir el movimiento relativo a la posicion departida para obtener una estimacion de nuestra posicion actual.

5.2.1. Odometrıa inherente a la plataforma

Cuanto mejor sea la odometrıa de un vehıculo, mejor sera su capacidadpara navegar. La calidad de la odometrıa inherente a una plataforma movildepende de la configuracion de su sistema de impulsion. El eje mas crıticoes el de guiado y el sentido de la direccion, puesto que los errores en esteparametro se acumularan geometricamente al impulsar el vehıculo.

Cuanto menos acoplamiento exista entre el guiado y la impulsion, maspredecible sera su respuesta a una orden de guiado.

Los vehıculos que emplean “Synchro-drive” tienen motores independientespara la impulsion y la direccion. El motor de impulsion hace girar a todaslas ruedas a la misma velocidad, mientras que el motor de direccion hace quetodas las ruedas se orienten en la misma direccion. Puesto que la impulsiony el guiado estan desacoplados, el vehıculo responde de manera precisa a loscomandos de guiado, incluso en superficies muy deslizantes. Una plataforma“Synchro-drive” bien alineada raramente requerira sensores adicionales paracorregir la deriva de la odometrıa..

La peor configuracion para la odometrıa son los vehıculos “skid-steered”1 que tienen un alto grado de acoplamiento entre el impulso y el guiado, ytambien dependen del deslizamiento entre los puntos de contacto y el suelo.

1“Skid-steering” emplea dos o mas ruedas propulsadas, pero no directrices, en cadalado del vehıculo.

5.2. NAVEGACION 73

Un tanque, por ejemplo, no tiene guiado como tal, sino que depende de laimpulsion de sus dos cadenas a diferentes velocidades para lograr el guiado.Si una cadena tiene mayor eficacia que la otra, puede que no se obtenga elgiro previsto. Lo mismo ocurre para vehıculos de ruedas que emplean “skid-steering” y “differential drive”2.

Un vehıculo que emplea el guiado de Ackerman (e.g. un vehıculo corrientede pasajeros) tiene un mecanismo de guiado que es independiente del meca-nismo de impulsion, pero depende del movimiento del vehıculo hacia adelante(o hacia atras) mientras la direccion es desviada antes de que el volante ten-ga efecto en su orientacion. Si las ruedas del vehıculo deslizan, y este no semueve hacia adelante la distancia indicada por su odometrıa, entonces seproduce un error en su orientacion.

La eleccion de un sistema de guiado puede tener muchas otras conside-raciones ademas de la calidad de su odometria inherente. Si el sistema notiene una buena odometrıa inherente, entonces es esencial suplementar laodometrıa con los sensores apropiados. Uno de los sensores mas comunes pa-ra este proposito es el giroscopo. Ahora estan disponibles giroscopos opticosque pueden proporcionar al vehıculo un excelente sentido de la orientacion.Desafortunadamente, el coste de un giroscopo optico solo es razonable enaplicaciones de alto nivel. Otro sistema que se esta imponiendo es el uso dereceptores GPS.

5.2.2. Encoders

En su nivel mas bajo, la odometrıa es practicamente siempre obtenida pormedio de encoders en los sistemas de impulsion y/o guiado. Ocasionalmen-te, las plataformas emplearan encoders en las ruedas locas, no impulsadas,que hacen contacto con el suelo debajo del vehıculo. Estas configuracionesusualmente son un intento de eliminar los errores de odometrıa resultantesdel acoplamiento entre el guiado y la impulsion. Desafortunadamente, estasconfiguraciones tienden a ser extremadamente complejas y poco fiables, porlo que generalmente no han encontrado un extenso uso.

El paso (tick) de un encoder es el cambio de un encoder por su mınimo in-cremento. Un cambio de posicion menor que un paso (tick) no sera detectado,y el movimiento asociado con un paso (tick) normalmente sera aproximado

2“Differential drive” emplea dos ruedas propulsadas en cada lado del vehıculo, siendoruedas locas las demas ruedas del vehıculo.


como un vector de paso recto que se anadira a la posicion estimada de la pla-taforma. Cuanto mayor sea la resolucion del encoder, mas pequenos seran loserrores producidos por estas aproximaciones. Los encoders son usualmente denaturaleza binaria, por lo que sus resoluciones pueden ser cualquier potenciade dos. El rango tıpico de resoluciones varıa entre 32 y 4096. Las senalesasociadas con el acto de impulsion generalmente causan una tick interrupten el computador de navegacion.

Por ello, la cuestion importante para los encoder de traccion es la cantidadde movimiento representada por un unico tick. Si la “distancia tick” es de-masiado larga, los calculos de odometrıa seran inexactos porque sera incapazde seguir las fluctuaciones del curso del vehıculo durante el intervalo del tick.Por otro lado, si la resolucion es innecesariamente pequena, el encoder pro-ducira una sobrecarga excesiva sobre el computador que recibe las senales deinterrupcion. Como norma general, la “distancia tick” deberıa ser alrededorde la centesima parte de la distancia entre las ruedas o cadenas del vehıculo.

Para aquellos sistemas con encoders de direccion, el angulo de un tickvector sera truncado (no redondeado) a la resolucion del encoder. Es muydeseable que el encoder de direccion sea montado tan proximo a las ruedasde direccion como sea posible, para que no se vea afectado por la holguramecanica del mecanismo de direccion. La resolucion del encoder de direcciondeberıa ser alrededor de un factor de tres veces mas pequeno que la holguraentre el mismo y las ruedas. Las resoluciones tıpicas estaran en el rango de1024 hacia arriba.

5.3. Integracion

En esta seccion vamos a tratar la cuestion del diseno e implementacion delsoftware de intercomunicacion que permite integrar los diferentes modulos deuna aplicacion de software para robots.

El desarrollo de aplicaciones de software distribuido para sistemas roboti-cos tiene importantes caracterısticas que sirven para centrar nuestro trabajo:

La aplicacion esta expuesta a futuras modificaciones debidas a la ins-talacion de nuevos dispositivos de hardware o Sistemas operativos, mo-dificacion de la topologıa de red de los ordenadores y realizacion dediferentes pruebas y experimentos.

5.4. MULTIPLES ROBOTS 75

Una importante cantidad de trabajo, como es el sistema de comuni-caciones entre los diferentes componentes de la aplicacion, es comun adiferentes plataformas roboticas.

Esta involucrado el trabajo de mucha gente. Esto implica la necesidadde interfaces simples y bien definidos que permitan la intercomunicacionde los diferentes componentes usando un protocolo estandar

Podemos encontrar muchas aproximaciones al problema de disenar un fra-mework general para integrar software robotico en la literatura. Entre ellosfiguran Task Control Architecture (TCA) y CODGER, desarrollados en elCarnegie Mellon Robotics Institute [57], Sistemas operativos completos talescomo CHIMERA [129], la aplicacion para manufactura agil presentada en[122] que soluciona el problema en el area particular de sistemas de manufac-tura, o el software NEXUS [48], del departamento de Ingenierıa de Sistemas yAutomatizacion de la Universidad de Malaga, basado en un diseno de subs-cripcion/produccion. Tambien podemos emplear una solucion de caractermas general, como pueden ser las distintas clases de middleware que ana-lizamos en el capıtulo 3, especialmente aquellas orientadas a objetos, comoCORBA (analizada en los capıtulos 6–8), que ha sido la solucion empleadaen este proyecto.

5.4. Multiples Robots

La cooperacion entre robots permite mejorar la percepcion del mundo ycoordinar su movimiento para realizar tareas en un entorno comun o tareasque no pueden ser llevadas a cabo por un solo robot (ver [147]). En [132] sedistingue tres niveles de cooperacion: bajo, medio y alto nivel. Cuando losrobots se mueven en entornos independientes se dice que hay bajo nivel decooperacion. Una colision entre robots es imposible a este nivel de coopera-cion. Estan cooperando porque estan llevando a cabo diferentes misiones parael sistema. La cooperacion se realiza en el segundo nivel cuando los robotsmoviles tienen un entorno comun, pero realizan tareas independientes. Ahoralos robots deben evitar colisionar con el entorno y con otros robots moviles.El mayor grado de cooperacion implica un entorno comun y tareas que sonllevadas a cabo por mas de un robot al mismo tiempo. Este es el nivel mascomplejo puesto que cada robot debe evitar colisionar con el entorno y conun robot cercano que esta realizando la misma tarea. Podrıa ser incluso mascomplejo si existiera una union fısica entre dos robots con el fin de mover unobjeto pesado.


Esisten dos problemas basicos que hay que solucionar cuando se hace nece-saria la cooperacion entre robots : planificacion de ruta y asignacion de tareas,y ejecucion de tareas. La planificacion de ruta y la asignacion de tareas estanıntimamente relacionadas, puesto que para asignar una tarea se necesita uncriterio numerico relacionado con la longitud de la ruta. Evitar obstaculosdinamicamente y cualquier optimizacion de paametros, como la distancia oel tiempo empleado tienen que ser aseguradas para ejecutar las tareas.

Algunos investigadores han solucionado estos problemas con diferentestecnicas y han desarrollado sus propias arquitecturas. [63], [62] emplean unaarquitectura maestro-servidor para realizar la planificacion. El robot maestrotiene que reclutar y coordinar la evolucion del equipo servidor para realizarlas tareas. Otros investigadores, como [51], [52] o [37] recurren a la negocia-cion para lograr la cooperacion entre robots. Para ello emplean un protocolopre-establecido para asignar las tareas e indicar como se deben realizar lasmismas. Otros autores proponen para los agentes, o robots moviles, una auto-organizacion en la que cada robot tiene uno o mas comportamientos basicos,y cooperan sin comunicacion entre los robots.

5.5. Ejemplos de sistemas de control de ro-

bots

En esta seccion se enumeran distintas soluciones software para control derobots.

5.5.1. OROCOS

El proyecto OROCOS [120] es un proyecto de software libre para robotica.Se divide en dos subproyectos:

Open Realtime Control Services. Es un framework de software paratodas las posibles aplicaciones de control de maquinas, y completamen-te independiente del enfoque del proyecto original OROCOS. Esta di-senado para ejecutar tareas definidas por el usuario de forma paralelay segura, tanto en un kernel 2.6 basico como con RTAI de tiempo realduro. Dispone de un amplio soporte de configuracion basica.

Entre las caracterısticas disponibles podemos mencionar: abstrac-cion de hardware, abstraccion de Sistema operativo, manejo de eventos,

5.5. EJEMPLOS DE SISTEMAS DE CONTROL DE ROBOTS 77

maquinas jerarquicas y de estados paralelos, scripts “PLC” de tiemporeal, analisis de comandos, configuracion de propiedades en lınea, multi-ples hilos disparados por eventos o por tiempo, proteccion avanzada dedatos para flujo sıncrono/asıncrono de datos, flujo de datos fuertemen-te tipado, soporte de configuracion (en-lınea),...

La integracion entre RTAI, TAO y ACE es tambien parte del traba-jo que se esta haciendo para conseguir una infraestructura de controldistribuido en tiempo real basado en CORBA.

Open Robot Control Software. Es un conjunto de librerıas de clasesy un framework de aplicaciones que ofrece funcionalidad generica paramaquinas herramientas y robots : bucles de control en cascada y compo-nentes de control, generacion de movimiento e interpolacion, cinemati-ca y dinamica; algoritmos de control especıficos de robots, estimacion eidentificacion, etc.

Figura 5.1: Estructura del Standard Control Kernel de OROCOS

Las siguientes familias de aplicaciones tienen implementaciones enfuncionamiento: brazo manipulador 6R controlado por fuerza, maqui-


nas herramientas cartesianas XYZ. De momento carece de soporte paraaplicaciones de robots moviles y robots humanoides.

5.5.2. CARMEN

CARMEN [5] es el kit de herramientas para navegacion de Carnegie Me-llon. CARMEN es una coleccion de software abierto para control de robotsmoviles. CARMEN es un software modular disenado para proporcionar pri-mitivas basicas de navegacion, incluyendo control basico y de sensores, es-quivar obstaculos, localizacion, trazado de ruta, seguimiento de personas ymapeado.

La figura 5.2 muestra el programa constructor de mapas a partir de losregistros de los datos de los sensores y la odometrıa de un robot teleoperado.La figura 5.3 es una imagen del programa navigator panel empleado paranavegacion autonoma de robots. Este programa muestra la posicion del roboty su destino en un mapa pre-construido y permite seleccionar la posicion yorientacion actual del robot, ası como su destino.

5.5.3. Scene

Scene [27] es una librerıa de software abierto (open-source) escrita en C++que proporciona localizacion secuencial y construccion de mapas. Su disenoaltamente modular permite emplear esta librerıa en aplicaciones muy diver-sas: desde navegacion de robots en una, dos o tres dimensiones con distintascapacidades de percepcion de datos del entorno, hasta localizacion con unaunica camara.

5.5.4. Pyro AI and Robotics System

Pyro AI and Robotics System [19] es un conjunto de librerıa, entorno, inter-faz grafico de usuario (GUI), y drivers de bajo nivel para explorar inteligenciaartificial y robotica empleando el lenguaje Python. Soporta los robots de lafamilia Pioneer (Pioneer, Pioneer 2, PeopleBot), los de la familia Khepera(Khepera, Khepera 2 y Hemisson)y el robot AIBO de Sony. Pyro esta in-tegrado con varios simuladores, incluyendo Robocup Soccer, Player/Stage,Gazebo y el simulador Khepera.

Pyro ofrece la posibilidad de definir varios estilos diferentes de controla-dores. El sistema de control puede ser una red neuronal, un sistema basadoen comportamientos o un planificador simbolico. Una caracterıstica unica


Figura 5.2: Constructor de mapas de CARMEN

Figura 5.3: Planificador de ruta de CARMEN


de Pyro es la posibilidad de escribir controladores empleando abstraccionesde robots que permitan al mismo controlador operar robots de morfologıasbastante diferentes.

5.5.5. Dave’s Robotic Operating System (DROS)

Figura 5.4: Arquitectura de DROS

Dave’s Robotic Operating System (DROS) [7] es un conjunto de modulosbasicos para robotica. El framework consiste principalmente de funcionesde soporte para programacion modular y modulos para robots moviles. Laarquitectura del sistema consta de un servidor de nombres, una librerıa decomunicaciones llamada GeneralComms, un servicio para ejecutar programasen ordenadores remotos, una interfaz de programacion de aplicaciones (API),una base de datos distribuida que es accesible desde todos los robots y unadministrador de estados, que es un programa que inicia varios conjuntos deprocesos y permite alternar entre estos conjuntos de procesos bajo control deotro programa.


Figura 5.5: Plataforma de la University of Michigan y diagrama de bloquesde FLEXnav

5.5.6. FLEXnav

FLEXnav es el software de navegacion desarrollado para el Mars Rover porla University of Michigan. Combina lecturas de giroscopos y acelerometroscon la odometrıa de los seis encoders de las ruedas. Podemos ver una plata-forma cinematicamente equivalente al Mars Rover y el diagrama de bloquesen la figura 5.5.

El sistema de referencia inercial se compone de:

1×KVH E-core Giroscopo RA2100 de fibra optica

2×KVH E-core Giroscopo RA1100 de fibra optica

2×ICSensors acelerometros modelo 3140-002

A diferencia de muchos sistemas de sensores basados en un filtro de Kal-man, este sistema emplea logica Fuzzy y reglas expertas para la combinacionde las senales de los sensores. El sistema emplea un metodo innovador de odo-metrıa compensada para detectar y corregir el deslizamiento de las ruedascuando el Mars Rover se mueve en pendientes arenosas. Se ha demostradoque el sistema de navegacion FLEXnav produce errores de navegacion infe-riores al 1% de la distancia recorrida, incluso en condiciones de deslizamientoimportante de las ruedas. Los errores tıpicos estan en torno al 0.6 % de la


distancia recorrida. Se cree que este sistema es mas preciso y robusto queotros sistemas de navegacion demostrados hasta la fecha. Este sistema per-mite al Mars Rover recorrer largas distancias entre actualizaciones absolutasde la posicion. Esta es una ventaja importante, puesto que en Marte es difıcilobtener la posicion absoluta al no existir GPS, puesto que las medidas basa-das en marcas del terreno requieren largos periodos sin movimiento que notienen un 100% de fiabilidad.

5.5.7. Orca

Orca [18] es un framework de software abierto para desarrollar sistemasroboticos basados en componentes. Proporciona medios para definir y desa-rrollar la construccion de bloques que se pueden juntar para formar un sis-tema robotico arbitrariamente complejo, desde vehıculos simples hasta redesde sensores distribuidos. Tambien proporciona un repositorio de componen-tes ya desarrollados que se pueden ensamblar rapidamente para poner enfuncionamiento un sistema robotico.

Figura 5.6: Diagrama de la distribucion Orca, sus modulos y las librerıasexternas.

Parte III

CORBA

83

Capıtulo 6

CORBA

6.1. El Object Management Group

6.1.1. Descripcion y objetivos

El Object Management Group (OMG) es una organizacion de estandari-zacion de caracter neutral e internacional, ampliamente reconocida y con unfuncionamiento significativamente rapido en lo que se refiere a la creacion denuevos estandares. Fue creada en 1989 por ocho miembros: 3Com, AmericanAirlines, Canon, Data General, Hewlett-Packard, Philips TelecomunicationsN.V., Sun Microsystems y Unisys. Su objetivo es desarrollar especificacionesde software independientes que se basan en arquitecturas orientadas a obje-tos, creando un nicho de mercado para estas tecnologıas. El OMG pretendecon ello reducir la complejidad, costes y esfuerzos que implica la introduccionen el mercado y las empresas de nuevas aplicaciones de software. Cualquierorganizacion que utilice la tecnologıa orientada a objetos del OMG, esta redu-ciendo futuros costes de desarrollo e implementacion de nuevas aplicacionescomo pueden ser los sistemas de control.

Hoy en dıa son miembros del OMG alrededor de mil distribuidores desoftware, desarrolladores y usuarios que trabajan en diferentes campos, in-cluyendo universidades e instituciones gubernamentales. Ademas, el OMGmantiene estrechas relaciones con otras organizaciones como ISO, W3C, etc.Los estandares del OMG facilitan la interoperabilidad y portabilidad de apli-caciones orientadas a objetos distribuidos. El OMG no produce implementa-ciones de software, solo especificaciones de software que son fruto de la re-copilacion y elaboracion de las ideas propuestas por los miembros del OMGa traves de las respuestas planteadas a los RFI (Request For Information)y a los RFP (Request For Proposals), documentos mediante los cuales al-

85

86 CAPITULO 6. CORBA

guno de los miembros del grupo da a conocer su interes para desarrollar unaespecificacion para un campo de aplicacion determinado.

6.1.2. Estructura y actividades

Las actividades del OMG se organizan en torno a tres secciones principales:

Platform Technology Comitee (PTC): responsable de la tecnologıa delnucleo de CORBA.

Domain Technology Comitee (DTC): responsable de las especificacio-nes para dominios verticales.

Architecture Board (AB): responsable de la arquitectura OMA y laverificacion de especificaciones para comprobar que son compatiblescon ella.

Dentro del OMG, el trabajo es realizado por grupos de trabajos organiza-dos en diferentes areas, correspondientes a distintos temas: desde el nucleode CORBA (por ejemplo los protocolos de interoperabilidad) hasta las espe-cificaciones de dominios concretos como pueden ser la adquisicion de datoso la seguridad en las operaciones financieras. El proceso de elaboracion deespecificaciones no es realizado por un comite concreto, sino por un numerode miembros del OMG, guiados por sus propios criterios y experiencia. Sihay varias propuestas para realizar especificaciones, se trata de llegar a unconsenso y elaborar una version unificada y util para todos.

6.1.3. Resumen de especificaciones

La siguiente lista muestra las principales areas donde se realizan especifi-caciones:

Common Object Request Broker Architecture (CORBA). Espe-cificacion que se basa en la interoperabilidad de aplicaciones independiente-mente de la plataforma, sistema operativo, lenguaje de programacion y pro-tocolos de comunicacion. Contiene una serie de especificaciones particulares,incluyendo el lenguaje IDL, protocolos de red como GIOP e IIOP, infraes-tructura para el desarrollo de servidores escalables y portables (POA), y elmodelo de componentes CORBA (CCM).

6.1. EL OBJECT MANAGEMENT GROUP 87

Figura 6.1: Diagrama OMA clasico

Object Management Architecture (OMA). Define una serie de in-terfaces estandar, mediante el uso de IDL, para objetos que soportan aplica-ciones CORBA. Incluye los servicios proporcionados por CORBA (CORBA-Services, CORBAFacilities y Domain Facilities).

Unified Modelling Language (UML) [118]. Esta especificacion estan-dariza la representacion de objetos y el analisis y diseno de sistemas basadosen los mismos. Es un lenguaje grafico que incluye diagramas de casos de usoy actividades, diagramas de clases y objetos, diagramas de despliegue, etc.

MetaObjectFacility (MOF) [92]. Estandariza un metamodelo utilizadopara analisis y diseno de objetos.

Common Warehouse Metamodel (CWM) [100]. Estandariza una ba-se para modelado de datos dentro de una empresa, para su uso en bases yalmacenes de datos.

XML Metadata Interchange (XMI) [119]. Permite el intercambio dedatos a traves de XML, de modelos basados en MOF y CWM.

Model Driven Architecture (MDA). Unifica los espacios de modeladoy desarrollo de aplicaciones, abarcando todo su ciclo de vida, desde el analisisy diseno, pasando por la implementacion, hasta su despliegue, mantenimientoy evolucion.


Para el modelado de sistemas de control, que es lo que nos atane, son deespecial utilidad las especificaciones de CORBA, UML, MOF y MDA.

6.2. Especificaciones del OMG

Las especificaciones del OMG van mas alla de la especificacion de CORBA,pero casi todas ellas estan relacionadas de alguna manera con dicha especi-ficacion o con el modelo de objetos OMA. Algunas de estas especificacionesestan incluidas dentro del documento de especificacion de CORBA, “Com-mon Object Request Broker Architecture and Specification” [99] , que puedeencontrarse en la pagina web del OMG:http://www.omg.org

El OMG proporciona extensiones y perfiles adicionales en forma de docu-mentos separados. Son de especial importancia para la ingenierıa de sistemasde control las especificaciones de CORBA “mınimo” [93], CORBA de tiemporeal [106], y CORBA con tolerancia a fallos [102]. Las especificaciones puedenagruparse en las siguientes categorıas;

Modelado

CORBA/IIOP

Lenguaje IDL y mapeado del mismo a diferentes lenguajes de progra-macion

Especificaciones especiales

CORBA embebido

Servicios CORBA

Facilidades CORBA

Especificaciones de dominio+

Seguridad

http://www.omg.org

6.2. ESPECIFICACIONES DEL OMG 89

Figura 6.2: Componentes de la arquitectura OMA


6.2.1. Object Management Architecture (OMA)

La arquitectura para gestion de objetos (OMA) es una de las mayorescontribuciones del OMG. Esta orientada a la construccion de sistemas distri-buidos que utilizan un middleware y una serie de servicios comunes predefini-dos. Esta arquitectura consiste en cuatro componentes principales divididosen dos partes: los componentes orientados al sistema, y los componentesorientados a la aplicacion. En la figura 6.2 podemos ver un esquema de dichaarquitectura:

Object Request Broker (ORB): es el nucleo de la arquitectura y per-mite la integracion en tiempo de ejecucion de los objetos CORBA que com-ponen la aplicacion. Se encarga de gestionar los mensajes e invocaciones quese envıan entre dichos objetos.

Common Object Services (CORBAServices): proporciona una seriede servicios comunes y basicos, cercanos al nivel de sistema, como por ejemploun servicio de nombres o un servicio de notificacion de eventos.

CORBAFacilities: son servicios que no estan relacionados con un nichoespecıfico, pero que son de un nivel demasiado alto como para ser incluidosen los servicios anteriores. Por ejemplo, servicios de impresion o de seguridad.

Domain Facilities: proporcionan servicios estandar utilizados en camposde aplicacion particulares, como puede ser el transporte o la salud.

Application Objects: objetos de la aplicacion en desarrollo, que propor-cionan servicios concretos para usuarios concretos.

El ORB gestiona toda la comunicacion entre los componentes descritos.Permite que interaccionen en ambientes heterogeneos y distribuidos, con in-dependencia de la plataforma en la que cada uno de ellos se ejecuta y de laforma en que fueron desarrollados. Los servicios CORBA estan muy relacio-nados con el funcionamiento del ORB, dada su naturaleza; las facilidades ylos servicios de dominio, en cambio, estan mas proximos al nivel de usuarioque al de funcionamiento del sistema distribuido.


6.2.2. Especificaciones de CORBA/IIOP

CORBA/IIOP. Esta especificacion en concreto describe el middlewarellamado Object Request Broker (ORB) que es la base de la interoperabilidadde CORBA. Es el nucleo de la especificacion CORBA.

Interoperabilidad Segura (CSIv2) (Capıtulo 24 de [99]). Indica losrequerimientos necesarios para una interoperabilidad segura basada en laautentificacion, delegacion y privilegios.

Modelo de Componentes CORBA (CCM) [87]. Se especifica una ex-tension del lenguaje IDL llamada IDL3 y un lenguaje de definicion de imple-mentacion llamado Component Implementation Definition Language (CIDL);la semantica del modelo de componentes, un marco de integracion de com-ponentes; un modelo de programacion para contenedores; procedimientos deempaquetamiento y despliegue de componentes, etc. El modelo de componen-tes ligero (Lightweight CCM) elimina algunos de estos aspectos para poderusar CCM en sistemas empotrados.

Tolerancia a fallos [102]. Proporciona un soporte para tolerancia a fallosque sea requerido por aplicaciones crıticas.

Actualizacion en lınea [104]. Permite la actualizacion de los objetos deun sistema de manera portable, a traves de sistemas heterogeneos. De estaforma puede cambiarse la implementacion de objetos individuales sin que porello se vea afectada su interfaz externa; se puede detener la ejecucion de unobjeto para su actualizacion; retener el estado antes de la actualizacion; y lascapacidades necesarias para la gestion y mantenimiento de objetos sin quesea necesario afectar el funcionamiento global de los sistemas distribuidos.

6.2.3. Lenguaje IDL

El lenguaje IDL debe ser mapeado a diferentes lenguajes de programacionpara poder implementar los objetos CORBA en dichos lenguajes. Los len-guajes de programacion soportados en la actualidad los podemos ver en latabla 6.1:

6.2.4. Especificaciones especiales

Estas secciones aportan perfiles y extensiones orientadas a aplicaciones ynichos de tecnologıa particulares, siendo adecuadas para sistemas embebidos,


AdaCC++COBOLIDL to Java,Java to IDLLispPL/1PythonSmaltalkXML

Cuadro 6.1: Tabla de lenguajes soportados

sistemas de tiempo real, y otros sistemas con funcionalidades especiales.

Proceso de datos en paralelo [109]. Util para computacion que requie-ra un gran rendimiento, esta especificacion define una arquitectura para laprogramacion paralela en CORBA.

Planificacion dinamica [105]. Este tipo de planificacion se emplea amenudo en sistemas de tiempo real y sistemas distribuidos.

CORBA Mınimo [93]. Una especificacion de un subconjunto de CORBA,disenado para funcionar en sistemas con recursos limitados.

CORBA de tiempo real [106]. Interfaz estandar que satisface los requi-sitos de tiempo real, ya que proporciona un metodo para asegurar la predic-tibilidad de las operaciones en un sistema, ademas de soporte para la gestionde recursos. Esta especificacion se usa especialmente en este proyecto. Masinformacion en la seccion 6.4 y en el capıtulo 8.

6.2.5. Servicios

Los servicios proporcionan una serie de funcionalidades preconstruidas,utiles para el desarrollo y funcionamiento de las aplicaciones CORBA. Lamayorıa son utiles en el campo de los sistemas de control.

Colecciones [86]

Concurrencia [70]


Vision Avanzada del Tiempo [110]

Servicios de eventos [111]

Externalizacion [71]

Servicio de licencias [73]

Ciclo de vida [91]

Servicio de nombres [112]

Servicio de notificaciones [113]

Persistencia de estado [94]

Servicio de propiedades [76]

Servicio de consultas [77]

Servicio de relaciones [78]

Seguridad [96]

Servicio de tiempos [98]

Intercambio de objetos [79]

Servicio de transacciones [107]

6.2.6. Facilidades

Son funcionalidades similares a los servicios, pero describen infraestructu-ras orientadas a usos muy especıficos, y no de aplicacion general:

Internacionalizacion y Tiempo [72]

Agentes moviles [74]


6.2.7. Especificaciones de dominio

Hay muchas especificaciones de dominio que son mas o menos importantesen lo que a sistemas de control se refiere.

Control de trafico aereo [68]

Flujo de datos audiovisuales [69]

Consultas bibliograficas [85]

Analisis de secuencias biomoleculares [80]

Imagenes clınicas

Observaciones clınicas [81]

Sistemas CAD [115]

Adquisicion de datos en entornos industriales (DAIS) [116]

Simulacion distribuida [88]

Mapas geneticos [90]

Control de instrumentacion de laboratorio (LECIS) [103]

Identificacion de personas [82]

Gestion de datos de producto [75]

Gestion de claves publicas [95]

Acceso a recursos [83]

Servicios de comunicaciones [97]

6.2.8. Especificaciones de seguridad

Otro subconjunto de especificaciones de relativa importancia son aquellasrelativas a la seguridad de los sistemas de software:

Capa de autorizacion de servicios (ATLAS) [84]

Interoperabilidad segura (CSIv2) (Capıtulo 24 de [99])

Servicio de seguridad [96] y [114]

Acceso a recursos [83]

Gestion de miembros en dominios de seguridad (SDMM)

6.3. LA TECNOLOGIA CORBA 95

6.3. La tecnologıa CORBA

En esta seccion haremos una descripcion general de la arquitectura COR-BA y su funcionamiento, aunque para conocerlos en profundidad es reco-mendable estudiar los documentos de especificaciones del OMG que puedenencontrarse en el Catalogo de especificaciones CORBA/IIOP, en el enlacesiguiente:http://www.omg.org/technology/documents/corba spec catalog.htm

El documento utilizado en este proyecto corresponde a la version 3.02.

6.3.1. Common Object Request Broker Architecture(CORBA)

CORBA especifica un sistema que proporciona interoperabilidad entre sis-temas que funcionan en entornos heterogeneos y distribuidos, de forma trans-parente para el programador. Su diseno se basa en el modelo de objetos delOMG donde se definen las caracterısticas externas que deben poseer los ob-jetos para que puedan operar de forma independiente de la implementacion.

Las caracterısticas mas destacables de CORBA son las siguientes:

Es una tecnologıa no propietaria

Una base fundamental de la especificacion son los requisitos reales dela industria

Es una arquitectura extensible

Compatible con diversas plataformas

Independiente del lenguaje de programacion

Proporciona multiples servicios de aplicacion

Proveedores y usuarios de servicios (servidores y clientes) pueden de-sarrollarse de manera totalmente independiente.

En una aplicacion desarrollada en CORBA, los objetos distribuidos se uti-lizan de la misma forma en que serıan utilizados si fueran objetos locales, estoes, la distribucion de comunicacion entre objetos es totalmente transparente.

http://www.omg.org/technology/documents/corba_spec_catalog.htm


Figura 6.3: Componentes de la arquitectura CORBA

6.3.2. Arquitectura general

Un objeto CORBA es una entidad que proporciona uno o mas servicios atraves de una interfaz conocida por los clientes que requieren dichos servicios.No todas las entidades que integran un sistema basado en CORBA son obje-tos CORBA propiamente dichos, lo son tecnicamente cuando proporcionanalgun servicio determinado.

La figura 6.3 muestra los principales componentes de la arquitectura y supapel cuando se realiza una peticion de servicio desde un cliente a un obje-to servidor. El componente central de CORBA es el Object Request Broker(ORB), el cual proporciona la infraestructura necesaria para identificar y lo-calizar objetos, gestionar las conexiones y transportar los datos a traves de lared de comunicacion. En general el ORB esta formado por la union de varioscomponentes, aunque es posible interaccionar con el como si fuera una unicaentidad ponente, siendo el responsable de la gestion de las peticiones de ser-vicio. La funcionalidad basica del ORB consiste en transmitir las peticionesdesde los clientes hasta las implementaciones de los objetos servidores.


Figura 6.4: Esquema de la invocacion estatica

Los clientes realizan peticiones de servicio a los objetos, tambien llama-dos servidores, a traves de interfaces de comunicacion bien definidas. Laspeticiones de servicio son eventos que transportan informacion relativa a losobjetos o entidades implicadas en dicho servicio, informacion sobre la ope-racion a realizar, parametros, etc. En la informacion enviada se incluye unareferencia de objeto del objeto proveedor del servicio, esta referencia es unnombre complejo que identifica de forma unıvoca al objeto en cuestion dentrodel sistema.

Para realizar una peticion un cliente se comunica primero con el ORB atraves de uno de los dos mecanismos existentes a su disposicion: el stub, o lainterfaz de invocacion dinamica (DII, Dynamic Invocation Interface). El stubes un fragmento de codigo encargado de mapear o traducir las peticiones delcliente, que esta implementado en un lenguaje determinado, y transmitırselasal ORB. Es gracias a los stubs que los clientes pueden ser programados endiferentes lenguajes de programacion. El la figura 6.4 puede verse un esquemaempleando el primer mecanismo, llamado invocacion estatica.

La segunda forma de realizar una peticion, el mecanismo de invocaciondinamica, se basa en el uso de la DII. Permite realizar invocaciones sin nece-sidad de que el cliente sepa cierta informacion acerca del servidor, que serıanecesaria en caso de utilizar el stub. En la figura 6.5 puede verse el esquemade la invocacion dinamica.

Una vez llega la peticion al nucleo del ORB es transmitida hasta el lado delservidor, donde se sigue un proceso inverso de nuevo a traves de dos meca-


Figura 6.5: Esquema de la invocacion dinamica

nismos alternativos: el skeleton del servidor, analogo al stub del cliente, o laDynamic Skeleton Interface (DSI), contrapartida de la DII. Los servicios queproporciona un servidor CORBA residen en la implementacion del objeto,escrita en un lenguaje de programacion determinado. La comunicacion entreel ORB y dicha implementacion la realiza el adaptador de objetos (ObjectAdapter, OA), el cual proporciona servicios como los listados a continuacion:

Generacion e interpretacion de referencias a objetos

Invocacion de metodos de las implementaciones

Mantenimiento de la seguridad en las implementaciones

Activacion o desactivacion de objetos

Mapeo de referencias a objetos

Registro de implementaciones

Existen adaptadores de objetos mas complejos, que proporcionan serviciosadicionales, y que son utilizados para aplicaciones especıficas (por ejemplo,bases de datos). Dos adaptadores de objetos basicos son el Basic ObjectAdapter (BOA) y el Portable Object Adapter (POA). El primero ha quedado


Figura 6.6: El Interface Repository y el Implementation Repository

ya obsoleto, y suele utilizarse el segundo adaptador. El ORB proporcionaademas un POA preconfigurado que puede usarse si no se desea crear unPOA especıfico para una aplicacion, llamado RootPOA. El OMG especificatres polıticas de actuacion para los adaptadores de objetos:

Servidor compartido: multiples objetos pueden ser implementadosen el mismo programa de servidor.

Servidor privado: se ejecuta un nuevo servidor por cada peticion deservicio.

Servidor persistente: la implementacion del servicio permanece siem-pre activa.

El adaptador de objetos necesita conocer cierta informacion acerca de laimplementacion del objeto y del sistema operativo en el que se ejecuta. Existeuna base de datos que almacena esta informacion, llamada Interface Reposi-tory (IR), que es otro componente estandar de la arquitectura CORBA. ElIR puede contener otra informacion relativa a la implementacion como porejemplo datos de depurado, versiones, informacion administrativa, etc.

Las interfaces de los objetos servidores pueden especificarse de dos mane-ras: o bien utilizando el lenguaje IDL, o bien almacenando la informacion


necesaria en el IR. La interfaz DII que mencionamos anteriormente accedeal IR en busca de esta informacion en concreto cuando un cliente la utilizapara realizar una peticion. Este mecanismo de invocacion ya descrito haceposible que un cliente pueda invocar un servicio sin necesidad de conocer ladescripcion IDL de la interfaz del objeto servidor.

Para utilizar la DII el cliente debe construir una estructura de datos(comun a todas las implementaciones de la especificacion) que incluye la re-ferencia al objeto servidor, la operacion a realizar y una lista de parametros.La informacion acerca de los objetos disponibles y los servicios que propor-cionan se obtiene del IR. En el lado del servidor la DSI funciona de maneraanaloga; si se emplea el mecanismo DII/DSI para invocar un servicio, no sellama al metodo correspondiente de la implementacion a traves del skeleton,sino que se accede a el a traves de una estructura de datos que le identifica yque contiene los parametros necesarios. De nuevo, en caso necesario, puedeobtenerse informacion relativa al metodo desde el Interface Repository.

La potencia del mecanismo de invocacion DII/DSI reside en que no esnecesario tener conocimiento de la interfaz de un objeto determinado entiempo de compilacion (este es el caso del mecanismo stub/skeleton), sino quela informacion sobre dicha interfaz se obtiene en tiempo de ejecucion desdeel Interface Repository. Este mecanismo tambien puede ser utilizado paraconseguir la interoperabilidad entre diferentes implementaciones de ORBs.

Por ultimo, en el lado del servidor CORBA, los objetos que se encargan enultima instancia de atender a las peticiones de servicio son los servants. Es-tos objetos contienen la implementacion de las operaciones asociadas a cadaservicio o metodo de la interfaz del objeto. No son visibles desde el lado delcliente; este solo ve una entidad unica a la que conoce como servidor. Dentrodel servidor de objetos es el encargado de hacer llegar dichas peticiones a losservants, crearlos o destruirlos, etc. Cada servant lleva asociado un identifi-cador llamado object ID, valor que es utilizado por el adaptador de objetospara gestionar los servants.

6.3.3. Interoperabilidad entre ORBs

Existen muchas implementaciones diferentes de ORBs en la actualidad, locual es una ventaja ya que cada desarrollador puede emplear aquella quemejor satisface las necesidades de su proyecto. Pero esto crea tambien la


Figura 6.7: Interoperabilidad entre ORBs

necesidad de un mecanismo que permita a dos implementaciones diferen-tes comunicarse entre sı. Tambien es necesario en determinadas situacionesproporcionar una infraestructura que permita aplicaciones no basadas enCORBA comunicarse con aplicaciones sı basadas en esta arquitectura. Pa-ra satisfacer todos estos requisitos existe una especificacion para lograr lainteroperabilidad entre ORBs.

Las diferencias en la implementacion del broker no son la unica barreraque separa a objetos que funcionan en distintos ORBs, tambien existen otrasdificultades como infraestructuras de seguridad o requisitos especıficos de sis-temas en vıas de desarrollo. Debido a esto, los objetos que funcionan en di-ferentes dominios (ORBs y entornos de los mismos) necesitan un mecanismoque haga de puente entre ellos. Este mecanismo debe ser suficientemente fle-xible para que no sea necesaria una cantidad de operaciones de “traduccion”inmanejable, ya que la eficiencia es uno de los objetivos de la especificacionCORBA. Esta caracterıstica es crıtica en sistemas de control, donde suele sernecesario alcanzar unos niveles determinados de seguridad, predecibilidad yseguridad. En la figura 6.7 puede verse un esquema explicativo de la interope-rabilidad. En dicho esquema existen dos ORBs diferentes, que bien podrıanestar funcionando en dos sistemas de muy distinta naturaleza y localizacion.


La interoperabilidad puede alcanzarse a traves de muchos procedimientos,los cuales pueden clasificarse en dos tipos principales: inmediatos e interme-diados (immediated/mediated bridging). En los procedimientos intermediadoslos elementos de un dominio que interacciona con los de otro dominio dis-tinto, son transformados a un formato interno acordado por ambos dominiosde antemano, y bajo este formato la informacion pasa de un dominio al otro.Este formato interno de la informacion puede basarse en una especificacionestandar, como en el caso del IIOP del OMG, o bien puede ser un forma-to acordado de forma privada. Los procedimientos inmediatos se basan entraducir directamente la informacion desde el formato utilizado por un do-minio, al formato utilizado por el otro, sin pasar por estructuras intermediasde datos. Esta solucion es mucho mas rapida, pero es menos general.

6.3.4. CORBA IDL

Como ya hemos mencionado, el lenguaje Interface Definition Language(IDL) es un lenguaje utilizado para especificar interfaces CORBA. A travesde un compilador especıfico que procesa las definiciones escritas en IDL, segenera codigo fuente en el lenguaje de programacion deseado en cada caso,codigo que es utilizado en las aplicaciones para crear servidores CORBA yaque proporciona la infraestructura de skeletons y stubs necesaria para queestos objetos puedan comunicarse con el ORB. IDL es un estandar ISO, ytiene las siguientes caracterısticas principales:

Su sintaxis es muy similar a la de C++.

Soporta herencia multiple de interfaces.

Independiente de cualquier lenguaje de programacion y/o compilador;puede mapearse a muchos lenguajes de programacion.

Permite independizar el diseno de la interfaz de la implementacion delobjeto CORBA en cuestion. La implementacion puede cambiarse porotra distinta, manteniendo la misma interfaz, de forma que desde el “ex-terior” el objeto sigue siendo el mismo y continua ofreciendo identicosservicios.

IDL no es un lenguaje de programacion propiamente dicho, ya que conel no pueden implementarse estructuras de control ni variables. Es unica-mente un lenguaje declarativo. Tiene tres elementos principales: operaciones(metodos), interfaces (conjuntos de operaciones) y modulos (conjuntos deinterfaces).


Tipo de datos IDL Tipo de datos C++ typedefshort CORBA:short short intlong CORBA::Long long intunsigned short CORBA::UShort unsigned shortunsigned long CORBA::ULong unsigned longfloat CORBA:Float floatdouble CORBA::Double doublechar CORBA::Char charboolean CORBA::Boolean unsigned charoctet CORBA::Octet unsigned charenum enum enum

Cuadro 6.2: Tabla de conversion del lenguaje IDL a C++

Para el lenguaje C++, IDL sigue la tabla de conversion o mapping delcuadro 6.2.

6.3.5. Bases de la construccion de aplicaciones COR-BA

Para desarrollar un objeto CORBA se siguen, en general, los siguientespasos:

1. Diseno: determinacion de los servidores que debe proporcionar el ob-jeto, e implementacion de la/s interfaces IDL correspondientes.

2. Compilacion de IDL: mediante el compilador de IDL se procesan lasdefiniciones de interfaces y se generan los skeletons y stubs correspon-dientes, en un lenguaje de programacion determinado.

3. Implementacion de los servants: utilizando las clases generadaspor el compilador de IDL, se crean los servants de la aplicacion, quecontienen la implementacion de las operaciones del objeto CORBA.

4. Implementacion del servidor: el objeto CORBA debe proporcio-nar la infraestructura base para que la comunicacion con el ORB seaposible; debe crear un adaptador de objetos para sus servants, etc.

5. compilacion: se procede a la compilacion de los archivos de codigofuente. Debe incluirse el codigo generado automaticamente por el com-pilador de IDL (la parte correspondiente a los skeletons ).


Figura 6.8: Generacion, integracion y compilacion

El proceso se reduce basicamente a cuatro fases generacion e integracion decodigo correspondiente a las interfaces, implementacion de la funcionalidaddel objeto CORBA, compilacion y por ultimo, puesta en marcha. Estos pasosson los correspondientes para el desarrollo de un objeto CORBA, es decir, unservidor. Para el desarrollo de un cliente, el proceso se reduce a la integraciondel codigo fuente generado correspondiente a los stubs. En la figura 6.8 puedeverse un esquema del proceso.

6.4. CORBA de tiempo real

Historicamente las aplicaciones distribuidas de tiempo real y empotra-das no han sido adecuadamente soportadas por CORBA y por otros DOCmiddleware de uso comun. Para corregir este problema el OMG introdujo laespecificacion CORBA de tiempo real en CORBA 2.4 en Octubre del ano2000.

La especificacion de CORBA para tiempo real [106] proporciona mecanis-mos que permiten controlar los recursos que utiliza una aplicacion, haciendoa esta mas predecible. Incluye una infraestructura para el control de los recur-

6.4. CORBA DE TIEMPO REAL 105

sos del sistema (memoria, procesos, prioridades, threads, protocolos, anchode banda, etc.) y para la gestion de las prioridades. Mediante estos mecanis-mos, es posible desarrollar aplicaciones controlando los tiempos de respuestade peticiones de servicio, inversiones de prioridad, bloqueo de invocaciones,enrutado, etc.

Los componentes que forman la arquitectura de CORBA para tiempo realpueden verse en la figura 6.9

Existen dos modelos de planificacion de prioridad en las especificacionesde CORBA: el modelo de prioridad fija y el modelo de planificacion dinami-ca. Las especificaciones del OMG correspondientes a ambos modelos puedenencontrarse en [106].

La especificacion 1.0 de CORBA de tiempo real (con prioridad fija) defineun conjunto de caracterısticas estandar que hacen posible mejorar la prede-cibilidad de extremo a extremo en aplicaciones desarrolladas con CORBA.Las interfaces y las polıticas de calidad de servicio que se definen en estaespecificacion permiten a las aplicaciones configurar y controlar:

Los recursos de procesador, mediante thread pools, mecanismos de prio-ridad, mutexes entre procesos y planificacion global.

El proceso de comunicacion, mediante propiedades y polıticas de fun-cionamiento de los protocolos de transporte.

Los recursos de memoria, mediante colas para peticiones de servicio ycontrol del tamano de las thread pools.

El modelo correspondiente a esta especificacion consta de los siguienteselementos:

Un sistema operativo de tiempo real. Se asume que dicho sistema uti-liza una planificacion basada en prioridades, como la especificada en elestandar POSIX 1003.1c.

Un ORB de tiempo real, que proporciona las primitivas basicas para lainteraccion entre cliente y servidor en tiempo real.

Un servicio de planificacion opcional, que utiliza las primitivas anterio-res para realizar una planificacion global dentro de todo el sistema dela aplicacion.


Figura 6.9: Extensiones CORBA de tiempo real


Una red de comunicaciones.

Clientes y servidores.

Este modelo no hace referencia a las capacidades de temporizacion y tiem-po real de la red y el sistema de comunicaciones utilizado, cosa necesaria sise desea desarrollar una aplicacion en tiempo real duro. Las caracterısticasmas importantes de esta especificacion son:

Tipos de prioridades. Se definen dos tipos: prioridades CORBA y priori-dades nativas del sistema, Tambien se define un mapeo o regla de conversionentre unas y otras. Esto hace posible disponer de un sistema de prioridadesglobal para todo el sistema, aunque este incluya nodos con diferentes sistemasy diferentes rangos de prioridad.

Modelos de prioridad. Se definen dos modelos: prioridad declarada porel servidor, y prioridad propagada por el cliente. Con el primer modelo esel servidor el que decide con que prioridad se atiende la peticion de serviciorealizada por el cliente; es decir, con que prioridad se ejecutan las operacionesnecesarias en el lado del servidor. Con el modelo de prioridad propagadapor el cliente en cambio, es el cliente el que decide con que prioridad debeatenderse su peticion.

Transformacion de prioridad. La transformacion de prioridad permitepasar de prioridades CORBA a prioridades del Sistema operativo y viceversa.

Thread pools. Permiten reservar recursos de forma anticipada para laejecucion de threads, con unas determinadas prioridades preasignadas, etc.Cada POA esta asociado con un unico thread pool, pero un mismo threadpool puede estar asociada a varios POAs. Los thread pool pueden configurarsepara contener un determinado numero fijo de threads que existen desde lacreacion del pool (threads estaticos), y un determinado numero de threadsque se crearan en caso necesario para atender a nuevas peticiones de serviciosi no es suficiente con los anteriores (threads dinamicos). Estos ultimos sedestruyen una vez han realizado su tarea, no ası los threads estaticos, quepermanecen “latentes” esperando a atender una nueva peticion. Ası mismo,los threads pueden agruparse opcionalmente en pistas o lanes, de forma quepueden asignarse distintas prioridades, una por pista.


Mutex. Se proporcionan mutexes para evitar inversiones de prioridad yasegurar la consistencia de los mecanismos de sincronizacion correspondientesal propio ORB y los correspondientes a la aplicacion.

Servicio de planificacion global. Este servicio permite especificar re-quisitos de calidad de servicio determinada para las aplicaciones, de formaque se pueden planificar las operaciones en funcion de medidas como tiemposo perıodos de ejecucion de tareas. El servicio consiste en un objeto CORBAque es responsable de reservar los recursos necesarios para alcanzar la calidadde servicio deseada. Este servicio es opcional en la especificacion.

Propiedades de los protocolos. Se define una interfaz que permite alas aplicaciones especificar las propiedades y caracterısticas de los protocolosde comunicacion, mediante listas y polıticas de funcionamiento asociadas aestos.

Conexion explıcita cliente/servidor. En el CORBA estandar la cone-xion (binding) entre cliente y servidor se establece cuando es requerida y espersistente, es decir, permanece activa tras ser establecida. En CORBA detiempo real, es posible preestablecer conexiones entre clientes y servidoresantes de que se realice ninguna comunicacion entre ellos, pudiendo asociarprioridades a las diferentes conexiones.

Propiedades adicionales de CORBA 3.0. CORBA de tiempo realmantiene una serie de caracterısticas ya presentes en el CORBA estandarcomo las comunicaciones unidireccionales; invocacion asıncrona de metodos;el servicio Enhaced View of Time, que permite controlar y configurar relojesde precision; el servicio de notificaciones de tiempo real, que es una extensiondel servicio estandar; etc.

A pesar de todas estas caracterısticas, cuando se va a desarrollar una apli-cacion de tiempo real duro la especificacion de CORBA de tiempo real fallaen algunos aspectos como ya hemos mencionado al hablar de comunicacion.Caracterısticas necesarias para este tipo de aplicaciones, que la especificacionde RT-CORBA no proporciona, son las siguientes:

Transporte determinista. La mayor fuente de indeterminacion en COR-BA estandar y en CORBA de tiempo real, es el protocolo de transporte. Elprotocolo IIOP no da ninguna garantıa de tiempo entre extremo y extremo


del canal de comunicacion. Aunque CORBA permite el uso de otros pro-tocolos (ver seccion “Protocolos de transporte extendidos” mas adelante) lamayorıa de los desarrolladores de ORBs unicamente dan soporte para IIOP opara protocolos con temporizaciones similares a IIOP, como ATM. Para queCORBA sea realmente aplicable al desarrollo de aplicaciones de tiempo realduro, es necesario el soporte de protocolos de transporte deterministas. Almenos, debe ser posible determinar la latencia maxima de la comunicacionentre dos entidades, aunque tambien serıa recomendable poder determinarun lımite inferior de dicha latencia.

Actividades periodicas. Serıa necesario que CORBA proporcionara me-canismos para especificar y describir invocaciones periodicas entre un clientey un servidor: perıodo de la invocacion, tamano de los datos transferidos, yla latencia maxima permitida. CORBA de tiempo real hace referencia a lasactividades periodicas, pero centrada unicamente en la parte del cliente y notoma en consideracion la parte del servidor, lo cual es necesario para modelaradecuadamente la relacion entre ambas entidades.

Planificacion. Para poder garantizar restricciones de tiempo en una apli-cacion distribuida, es necesario planificar el acceso a la red de comunicacion.La planificacion global requiere que se conozcan todos los accesos a dicha red,y dependiendo del protocolo de comunicacion utilizado, sera necesaria mas omenos informacion para realizar una planificacion correcta. En CORBA detiempo real, no existe una infraestructura adecuada para conocer y gestionarlas invocaciones de servicio a nivel global.

Footprint de las aplicaciones. El tamano de una aplicacion y el con-junto de recursos del sistema que necesita se denomina huella o footprint dela aplicacion. Tanto CORBA estandar y CORBA de tiempo real hacen usoexcesivo de los recursos del sistema. Serıa necesario centrarse mas en la es-pecificacion de CORBA mınimo que en la de CORBA de tiempo real, a lahora de desarrollar un ORB destinado a ser utilizado en sistemas embebidoscon pocos recursos. En aplicaciones embebidas serıa de mayor importanciauna gestion adecuada de los recursos, que las infraestructuras como las threadpools o los threads dinamicos.

La segunda especificacion de CORBA de tiempo real con planificaciondinamica se desarrollo para ser utilizada en sistemas distribuidos dinamicos.Estos sistemas se caracterizan porque no se conoce a priori, antes de poneren funcionamiento el sistema, la carga de trabajo que soporta cada nodo del


mismo. Debido a ello no es posible realizar un analisis previo del sistema paradeterminar los recursos que seran utilizados en cada momento, ni especificartodas las restricciones temporales que seran necesarias. En el modelo de pla-nificacion dinamica se anaden las siguientes caracterısticas a la especificacionde CORBA para tiempo real:

Es posible utilizar cualquier metodo de planificacion, no solo el modelobasado en prioridades. Se proporcionan interfaces IDL para varios mo-delos adicionales, aunque es posible anadir cualquier tipo de modelo alsistema.

Los parametros de configuracion de la planificacion pueden cambiarseen tiempo de ejecucion.

Se introduce el thread distribuido, una entidad manejable por el plani-ficador. La planificacion con este tipo de threads se diferencia en queun thread que se ejecuta en un nodo determinado, es tenido en cuentapara la planificacion en otros nodos distintos del primero. Es decir, laplanificacion se realiza de forma conjunta, y las tareas que se desarro-llan en cada nodo pueden influir en la planificacion de las tareas que sellevan a cabo en nodos adyacentes.

6.5. CORBA con tolerancia a fallos

Existen varios tipos de aplicaciones en las que es necesario disponer deun mecanismo de tolerancia a fallos, desde grandes sistemas crıticos (porejemplo, sistemas de control de trafico aereo), hasta pequenos sistemas yaplicaciones embebidas (sistemas medicos, controles de fabricacion, etc.). ElOMG trata la necesidad de disponer de estas caracterısticas mediante laespecificacion [102].

La tolerancia a fallos se basa en tres conceptos: redundancia de disposi-tivos y mecanismos, deteccion de fallos en el sistema, y mecanismos parala recuperacion de dichos fallos. La redundancia en la especificacion COR-BA con tolerancia a fallos consiste en la replicacion de objetos, permitiendoespecificar en cada caso el numero y localizacion de las copias de objetosseleccionados. La replicacion de los objetos se disena de tal manera que noafecta en forma alguna a la invocacion de metodos. Ası mismo esta especifica-cion soporta varios mecanismos como reintentos en las peticiones de servicio,redireccionamiento de las mismas a otros servidores disponibles, copia de se-guridad de objetos, notificacion y supervision de la duplicacion de objetos,

6.6. PROTOCOLOS DE TRANSPORTE EXTENSIBLES 111

etc. Un objetivo prioritario es evitar la necesidad de realizar cambios impor-tantes en las aplicaciones, haciendo transparente toda la infraestructura a losprogramas y el ORB.

El modelo de CORBA con tolerancia a fallos proporciona dos categorıas ogrupos que constituyen la base de la infraestructura: los grupos de objetos, ylos dominios de tolerancia a fallos. La base de la infraestructura: los grupos deobjetos, y los dominios de tolerancia a fallos. Los grupos de objetos consistenen agrupaciones de copias o replicas de un determinado objeto CORBA. Ungrupo de objetos puede manejarse como una entidad unica identificada poruna referencia Interoperable Object Group Reference (IOGR), similar a lareferencia IOR de un objeto unico. Estas referencias son creadas dentro deun grupo de objetos que tiene su propia IOR, pero el uso de la referenciaIOGR tiene dos ventajas desde el punto de vista de los clientes:

Replicacion transparente: los clientes no tienen por que saber que elobjeto CORBA que estan utilizando dispone de varias copias de sı mis-mo, y no saben cual de dichas copias esta atendiendo a sus peticiones.

Transparencia ante posibles fallos: los clientes ignoran cuando seproduce un fallo en una de las replicas del objeto CORBA, y cuandose produce una recuperacion de dicho fallo.

Los dominios de tolerancia a fallos permiten organizar y agrupar los obje-tos y grupos de objetos del sistema, para dividir el sistema en subsistemasindependientes y gestionarlos de forma especıfica y diferenciada. Cada sub-sistema o dominio de tolerancia puede contener varios hosts y grupos deobjetos; por otro lado, cada host o grupo de objetos puede pertenecer a va-rios dominios de tolerancia. Cada dominio de tolerancia tiene un ReplicationManager asociado.

6.6. Protocolos de transporte extensibles

El protocolo GIOP de CORBA puede mapearse a protocolos desarrolla-dos siguiendo una de las dos arquitecturas disponibles en las especificacio-nes del OMG [101, 117]: Open Communication Interface (OCI) y ExtensibleTransport Framework (ETF). Dicha especificacion proporciona un modelo deconexion y comunicacion estandarizado entre el ORB y la capa de transpor-te, haciendo posible disenar un protocolo especıfico e integrarlo entre ambasentidades, sin necesidad de modificar el ORB. El modelo de protocolos ex-tensibles permite establecer, utilizar y cerrar conexiones. El entorno disenado


para un nuevo protocolo de transporte debe ser responsable de la creacion delos objetos necesarios para las conexiones (Acceptor y Connector) ası comopara las comunicaciones (Transport o Connection).

6.7. Otras especificaciones

6.7.1. Temporizacion extendida

Esta especificacion [89] define un formato especial para la representaciondel tiempo y conceptos relacionados como intervalos, para ser utilizados enCORBA. Tambien proporciona mecanismos de sincronizacion y ejecucionperiodica de tareas.

El formato basico soporta una granularidad de 100 ns y un rango de valo-res de ±30000 anos. El servicio de reloj (Clock Service) permite elegir entredistintos tipos de relojes o timers. Para cada uno de estos relojes se puedenespecificar algunas propiedades, como la resolucion, precision y estabilidad.Los relojes ademas pueden ser detenidos, reiniciados, etc. En aquellas apli-caciones que usan sincronizacion, puede especificarse una escala comun detiempo y un reloj de referencia.

Estas especificacion incluye diez formatos de tiempos diferentes (UTC,TAI, GPS, etc.), ası como funciones para la conversion y comparacion detiempos entre uno y otro formato.

Esta especificacion podrıa ser de utilidad en ingenierıa, si bien en sistemasembebidos donde los recursos son limitados podrıa traer problemas dada lavariedad de formatos y funciones que incluye.

6.7.2. Transductores inteligentes

Esta especificacion [102] define una interfaz abstracta para el uso de uncluster de transductores o dispositivos inteligentes, que permite encapsularlos detalles del funcionamiento especıfico, homogeneizar un sistema y reducirsu complejidad.

Define tres interfaces orientados a tres niveles de servicio: servicio de tiem-po real crıtico (interfaz RS), servicios de diagnostico y de gestion no crıticos(interfaz DM), y servicios de planificacion y configuracion (interfaz CP). Es-tas interfaces permiten acceder a una interfaz de sistema de ficheros (IFS)

6.8. UML 113

que contiene todos los valores que deberıan ser visibles desde el exterior deldispositivo. A traves del IFS se produce la comunicacion entre el dispositivoy su cliente. El acceso al dispositivo inteligente se realiza a traves de dichainterfaz.

Esta especificacion incluye tambien un formato para medidas o marcas detiempo preparadas para su uso en sistemas embebidos con pocos recursos,ya que consisten unicamente en un entero de 8 bytes con una granularidadde 2−24 y un campo de precision. Esto permite una granularidad de 60 ns yfacilita la sincronizacion con otros dispositivos.

Los pequenos sistemas embebidos son el objetivo principal de esta especi-ficacion; caracterısticas tıpicas de uno de estos sistemas serıan 4 kb de ROM,64 bytes de RAM, etc.; es decir, pequenos dispositivos que pueden ser equi-pados con software basado en CORBA.

6.8. UML

El lenguaje unificado de modelado UML (Unified Modelling Language),ver [67], [108] y [118], es un lenguaje grafico y textual que se utiliza paraformalizar y disenar todo tipo de sistemas. Puede usarse tanto para modelosde negocio, como para diseno de software, modelos de organizacion, y todotipo de aplicaciones.

El UML tiene sus orıgenes en una metodologıa denominada Object OrientedAnalysis and Design, utilizada en el desarrollo de software. Las ventajas deutilizar esta metodologıa (tanto para el diseno de software como para otrosdominios) son las siguientes:

Si hay que realizar algun cambio en un diseno, dicho cambio suele sermuy localizado y se evitan interacciones o modificaciones inesperadasen otras entidades del diseno distintas de la modificada.

La herencia y el polimorfismo hacen a los programas orientados a ob-jetos mas extensibles, permitiendo un desarrollo mas rapido.

El diseno basado en objetos es valido para el desarrollo de sistemasdistribuidos, sistemas de funcionamiento en paralelo o sistemas de fun-cionamiento secuencial.


Los objetos pueden ser asociados a conceptos del mundo real con ma-yor facilidad, permitiendo realizar disenos mas claros y entendibles porcualquiera.

Las estructuras de datos compartidas se encapsulan, evitando posiblesmodificaciones inesperadas u otras anomalıas.

Los autores de UML proponen un proceso de desarrollo incremental, basa-do en casos de uso y centrado en la arquitectura del sistema. Deben respetarselos dos principios fundamentales de la orientacion a objetos: encapsulamientoy herencia.

Para el modelado con UML se dispone de trece tipos de diagramas, tras laincorporacion de 4 tipos mas en UML2, que permiten disenar los diferentesaspectos de una aplicacion:

Diagrama de clases. Describen la estructura estatica del sistema, yorganizan los elementos en grupos (paquetes).

Diagramas de objetos. Describen la estructura estatica del sistemapara una instancia determinada del mismo.

Diagramas de casos de uso. Modelan las funcionalidades del sistemautilizando actores y casos de uso.

Diagramas de secuencia. Describen las interacciones entre las clasesen terminos de intercambio de mensajes a lo largo del tiempo.

Diagramas de colaboracion. Representan interacciones entre obje-tos como series ordenadas de mensajes, describiendo tanto la estructuraestatica del sistema como su comportamiento dinamico.

Diagramas de estado. Describen el comportamiento dinamico delsistema en respuesta a estımulos externos.

Una de las mayores ventajas de UML es que permite su extension con ele-mentos adicionales, en caso necesario. Las extensiones suelen hacerse disenan-do nuevos perfiles de UML, que proporcionan nuevos elementos especıficosde un dominio particular.

Capıtulo 7

Aplicaciones de CORBA enControl

7.1. Introduccion

En el capıtulo anterior hemos introducido las especificaciones del OpenManagement Group (OMG), la tecnologıa CORBA, UML. En este capıtu-lo vamos a ver aplicaciones practicas de CORBA para construir bucles decontrol y ejemplos reales del uso de CORBA.

7.2. CORBA en el bucle de control

En esta seccion se describe el uso de CORBA para construir bucles decontrol, las posibles restricciones de tiempo existentes, retardos, etc.

7.2.1. Controladores

Existen al menos dos formas basicas de construir un bucle de control ba-sado en CORBA:

Bucle distribuido

Los nodos del sensor, controlador y actuador disponen de ORBs (ver figura7.1). Los tres elementos del bucle se construyen como objetos CORBA. Haydiferentes posibilidades a la hora de elegir cuales de dichos elementos hande ser objetos activos: una posibilidad es que el sensor sea un objeto activoque, gracias a un reloj, tome una medida de forma periodica e invoque una

115

116 CAPITULO 7. APLICACIONES DE CORBA EN CONTROL

Figura 7.1: Bucle distribuido

operacion determinada en el objeto controlador, que es en este caso un ob-jeto pasivo. El controlador podrıa entonces realizar los calculos pertinentes,y dentro de esa invocacion, llamar a un metodo determinado del objeto ac-tuador. Otra alternativa serıa que el objeto controlador fuera el que hicieralas llamadas tanto al sensor como al actuador.

Bucle encapsulado

En este caso el controlador es el unico que debe ser necesariamente unobjeto CORBA, ya que implementa la comunicacion con el sensor y el ac-tuador utilizando algun mecanismo diferente, por ejemplo, un bus de campo.El controlador podrıa ser un objeto activo o podrıa ser invocado desde algunotro nodo del sistema, por ejemplo un nodo supervisor. Un esquema de estaalternativa puede verse en la figura 7.2

En ambos casos el bucle de realimentacion se cierra a traves de una redde comunicacion, por lo que la eficacia y estabilidad del control se ve di-rectamente afectada por la calidad del transporte. Una red con latenciasdemasiado grandes o con mucha variabilidad en los tiempos puede provocarque el sistema de control falle o funcione de forma incorrecta. Sin embargo,si se conocen bien las caracterısticas de la red empleada, es posible tenerlasen cuenta a la hora de disenar el sistema de control y compensar cualquierlatencia o retraso que pueda presentarse. Tanto las propiedades temporales

7.2. CORBA EN EL BUCLE DE CONTROL 117

Figura 7.2: Bucle encapsulado

de la red, como el transporte de red y el protocolo de comunicacion debentenerse en cuenta a la hora de disenar el sistema.

7.2.2. Restricciones de tiempo

Un bucle de control basico tiene dos restricciones de tiempo basicas: elperıodo de muestreo (h) que suele ser constante, y la latencia de entra-da/salida o retardo de control (τ), que es el tiempo desde el muestreo deuna medida hasta que se produce la accion correspondiente. En un buclede control distribuido este valor incluye retardos debidos a la comunicacionentre los nodos. En la figura 7.3 se muestran estas restricciones, asumiendoque el controlador se implementa como un unico proceso.

Desde el punto de vista del rendimiento del control, hay que tener en cuentalas siguientes especificaciones:

El perıodo de muestreo debe ser constante (sin variabilidad o jitter).

El retardo de control debe ser despreciable o constante (sin variabili-dad); si es despreciable puede obviarse para el diseno del sistema, y sies constante puede ser compensado estaticamente.

La mayorıa de los bucles de control son mas sensibles al retardo decontrol que al perıodo de muestreo.


Figura 7.3: Restricciones de tiempo del bucle

En la mayorıa de los casos es mejor tener un retardo de control pequenocon cierta variabilidad, que un retardo grande con muy poca o nulavariabilidad.

7.2.3. Retrasos introducidos por la red

Dentro de un mismo nodo del sistema, las tareas interfieren unas con otrasdebido a la planificacion de los procesos y a los accesos a recursos compar-tidos. Los tiempos de ejecucion de las tareas pueden ser dependientes de losdatos o sufrir variaciones debidas a aspectos del hardware, como la capacidadde la memoria cache del sistema, por ejemplo.

A nivel distribuido, la comunicacion entre nodos introduce retardos quepueden ser conocidos o no, dependiendo del protocolo utilizado. Algunascausas de retardo en la comunicacion son:

Retardo de proceso: es el tiempo requerido para procesar el mensaje(paquete de datos) dentro de los nodos del sistema (hosts, routers,bridges, etc.) a traves de los que pasa dicho mensaje. En los hosts emisory receptor del mensaje, este tiempo es el que necesita el mensaje parapasar a traves de las distintas capas OSI (enlace, red y transporte),mientras que en los nodos intermedios, corresponde al tiempo que esnecesario para decidir hacia donde dirigir el mensaje en circulacion.Este retardo puede incluir otros factores, como por ejemplo el tiemponecesario para comprobaciones de errores de la transmision.

Retardo de cola: es el tiempo que el mensaje permanece en la colade salida (buffer) de un host o un router, esperando a ser transmitido.

7.3. APLICACIONES DE CORBA EN SISTEMAS DE CONTROL 119

Retardo de transmision: es el tiempo necesario para transmitir todoslos bits del mensaje a traves del enlace. Para routers y bridges estetiempo se llama tambien retardo de almacenamiento y envıo.

Retardo de propagacion: es el tiempo requerido por los bits pararecorrer el enlace.

Retardo de transporte: en determinados protocolos como TCP seutilizan mensajes de reconocimiento (acknowledgement) y reenvıo (re-send) para garantizar una conexion eficaz a pesar de los posibles erroresde transmision y la perdida de paquetes. Estos mecanismos introducenretardos adicionales, aunque pueden eliminarse si se utilizan protoco-los como UDP, que no los emplean (en detrimento de la calidad de lacomunicacion).

Retardo de enlace: corresponde a los retrasos causados por la coli-sion de paquetes y los tiempos de espera en los protocolos de accesomultiple, como Ethernet (CSMA/CD, Carrier Sense Multiple Accesswith Collision Detection) o CAN (CSMA/CA, Carrier Sense MultipleAccess with Collision Avoidance). Pueden evitarse estos retrasos utili-zando multiplexacion en el tiempo o dividiendo la red en dominios decolision mediante switches.

7.3. Aplicaciones de CORBA en sistemas de

control

En esta seccion se exponen algunos ejemplos de aplicacion de CORBA parael desarrollo de sistemas de control.

7.3.1. Bucle de control en red

En este ejemplo CORBA se utiliza en los nodos de la red correspondientesal sensor, el controlador y el actuador. La figura 7.4 muestra un lazo de controlen el que los elementos se interconectan a traves de una red de comunicacionesconvencional. Las muestras del proceso recogidas por el sensor son enviadasal controlador, que calcula la senal de control adecuada y la transmite alactuador.


Figura 7.4: Bucle de control basado en red

Figura 7.5: Bucle de control supervisado


7.3.2. Bucles de control supervisados

En un sistema distribuido supervisado, el bucle de control al completo seencuentra localizado en un unico nodo, y la informacion transmitida por lared son las trayectorias de referencia y las ordenes de control. A menudo estetipo de sistema requiere restricciones de tiempo real duro. El inconvenientede este sistema es que su comportamiento puede ser incorrecto o peligroso sise transmite una trayectoria de referencia inadecuada, pero tiene la ventajade que el buen funcionamiento del sistema se independiza en gran partedel buen funcionamiento de la red de comunicaciones, ya que el bucle decontrol se encuentra localizado en un solo nodo y funciona de manera casiautonoma. Es posible ademas disponer el bucle de control para que continuefuncionando de manera independiente en caso de fallo del resto del sistema.Las trayectorias de referencia y las ordenes son enviadas desde otro nodo delsistema, llamado nodo supervisor. Puede verse un esquema en la figura 7.5

7.3.3. MMS basado en CORBA

En [146] se describe el proyecto COCA, en el cual se utiliza CORBA pararealizar una implementacion orientada a sistemas distribuidos del protocoloISO MMS (Manufacturing Message System). La idea clave del proyecto esmapear los dispositivos virtuales de fabricacion de MMS (Virtual Manufac-turing Devices, VMD) a objetos CORBA. Los servicios de MMS tambien serepresentan mediante objetos CORBA. La ventaja de esta implementacionreside en su modularidad. Debido a que se introducen nuevas capas interme-dias de software en el sistema, es necesario utilizar una implementacion delORB muy eficiente, en la cual, por ejemplo, las invocaciones entre objetos serealizan a muy bajo nivel, sin utilizar el protocolo TCP/IP.

7.3.4. Componentizacion de comunicaciones

En el sistema Control IT de ABB [36] se emplean componentes COR-BA para modularizar el software relacionado con las comunicaciones y en-tradas/salidas del sistema. Se utiliza una aplicacion llamada ABB ControlBuilder para especificar la configuracion de hardware del sistema de control,el cual contiene uno o mas controladores llamados ABB Controllers, y paraescribir los programas IEC 61131-3 que se ejecutan en dichos controlado-res. Cuando la aplicacion de control se instala en el sistema a traves de lared de control, el software de los controladores se encarga de interpretar lainformacion de configuracion y de ejecutar los programas de control.


Por razones de mercado el sistema de control de ABB debe soportar unagran variedad de sistemas de E/S, interfaces de comunicacion y protocolos.Si el sistema no fuera modular, la adicion de una nueva interfaz o de unnuevo protocolo supondrıa realizar innumerables modificaciones en el disenoy codigo fuente del sistema. Para simplificar el proceso de anadido de nue-vos mecanismos de E/S, se disenaron componentes formados por dos partes:una parte generica y comun a todos los componentes de comunicaciones, yuna parte especıfica especialmente disenada para el mecanismo en cuestion.Esta segunda parte se denomina protocol handler (manejador de protocolo).Utilizando esta arquitectura, la implementacion de un nuevo protocolo decomunicaciones implica unicamente la creacion de un nuevo manejador.

7.3.5. Entornos de integracion en fabrica

En [124] se describe un entorno de integracion en el que se usa CORBApara el desarrollo de aplicaciones de fabricacion, incluyendo sistemas de ges-tion de fabricacion y control de maquinas. El entorno de integracion se divideen tres niveles: nivel de fabrica, nivel de celula, y nivel de equipo. Se empleantres modelos de comunicacion diferentes: comunicacion sıncrona bidireccio-nal, paso de mensajes asıncronos (utilizando Java Messaging), e interaccionmediante eventos (utilizando el servicio de eventos de CORBA).

7.3.6. CORBA para PLC

En [144] se describe la implementacion de un ORB preparado para ser uti-lizado en un PLC. Este ORB se ejecuta en un ordenador personal conectadoa un PLC de Melsec estandar. Los objetos CORBA utilizados representan yencapsulan las funciones disponibles en el PLC.

7.3.7. Arquitecturas orientadas a componentes

Existen varias propuestas de arquitecturas de sistemas de control inter-operables, la mayorıa de ellos orientados a componentes. Algunos ejemplosson: OMAC (Open Modular Architecture Controllers) [66], OSACA (OpenSystems Architecture for Controls within Automation Systems) [121], y OCIOpen Control Architecture for Windows NT [64].

El proyecto Open Robot Control Software (OROCOS) [120] es un proyectoeuropeo de software libre cuyo objetivo es crear componentes altamente con-figurables basados en CORBA, para ser utilizados en sistemas de control derobots. Se utiliza CORBA en las interfaces IDL de los componentes internos


quedando al margen de dichas interfaces, por lo que no existe comunicacionentre los componentes en tiempo real duro.

7.3.8. Bloques de control

Existe una tendencia general a utilizar herramientas de analisis y simu-lacion basados en modelos, como Matlab/Simulink. Ademas de utilizar estatecnologıa off-line, es posible utilizar simulaciones en lınea, es decir, comoparte de un sistema de control basado en modelos. Esto podrıa conseguir-se encapsulando la funcionalidad de los controladores u otros dispositivosa la manera de Simulink o el estandar IEC 61131-3, en objetos CORBAcon interfaces bien definidas. Estos componentes podrıan utilizarse tanto ensimulaciones off-line como en el funcionamiento en lınea del sistema.


7.3.9. Gestion de riesgos

RiskMan (ver figuras 7.6 y 7.7) es una aplicacion que ejemplifica el uso deCORBA para la gestion de riesgos [43]. Es un sistema de gestion de emer-gencias utilizado en un complejo quımico con nueve plantas. El sistema in-cluye mecanismos para soportar el ciclo de vida completo de una emergencia:prevencion, deteccion, lanzamiento, diagnostico, gestion, seguimiento y can-celacion. RiskMan se compone de una coleccion de objetos CORBA que seejecutan en diversas plataformas heterogeneas (Alpha/UNIX, x86/WindowsNT, VAX/VMS). Estos objetos implementan una variedad de funciones: sis-temas expertos, interfaces de usuario, wrappers de bases de datos, filtros delogica difusa, redes neuronales para prediccion, etc. En la figura 7.6 puedenverse algunos de los objetos CORBA utilizados en la aplicacion.


Figura 7.6: Gestion de riesgos: RiskMan (1)

Figura 7.7: Gestion de riesgos: RiskMan (2)


7.3.10. Teleoperacion de Robots

En la Universidad Politecnica de Madrid se utilizo CORBA para construiruna aplicacion de teleoperacion de robots [42], ver figura 7.8. Dicha aplicacioncontiene tres objetos CORBA: un control maestro realimentado de seis gradosde libertad, un robot esclavo de siete grados de libertad, y un mapeador decoordenadas espaciales (que realiza transformaciones de coordenadas desdeel sistema de referencia del maestro, al sistema de referencia del esclavo).

Figura 7.8: Evolucion de la posicion de los ejes del maestro y del robot durantela prueba

Se obtiene un retraso mayor, aproximadamente de 250 ms, pero con unjitter menor. La prueba fue realizada empleando red de laboratorio 10baseTen estado normal (con una carga del 20


7.3.11. Vıdeo de tiempo real para teleoperacion

El sistema HydraVision [46] es un sistema de vıdeo en tiempo real utilizadopara la operacion remota de plantas de energıa hidraulica. Utiliza una redWAN de fibra optica de una companıa electrica para integrar una serie deobjetos CORBA que encapsulan componentes fısicos del sistema: camaras,compresores MPEG, microfonos, altavoces, monitores de vıdeo, etc. El sis-tema es utilizado por los operadores para obtener confirmacion visual de lasoperaciones en planta, video conferencia, diagnostico remoto, etc. La figura7.9 muestra una demostracion del sistema en funcionamiento.

Figura 7.9: Video en tiempo real: Hydravision


7.3.12. Operacion de plantas cementeras

PIKMAC es un sistema de ayuda al operario disenado para la toma dedecisiones estrategicas de produccion en una planta cementera. El sistemase usa fundamentalmente de noche y los fines de semana, cuando solo hayuna persona en la planta. El sistema se compone de objetos CORBA queproporcionan cuatro funcionalidades: estimacion de la calidad del dinquer(mediante redes neuronales), estimacion de costes instantanea, gestion dealarmas (mediante sistemas expertos), y comunicacion multimedia. La figura7.10 muestra el sistema en funcionamiento.

Figura 7.10: Operacion de plantas cementeras: Pikmac


7.3.13. Automatizacion de subestaciones

En el proyecto Distributed Object Telecontrol Systems and Networks (DOTS),ver [130], se utilizan objetos CORBA embebidos en dispositivos de campobasados en el estandar IEC 61850 (Utilidades electricas). Ejemplos de es-tos dispositivos son: camaras, botoneras, GPS, terminales de configuracion,alarmas, etc.

Figura 7.11: Aplicacion de DOTS en automatizacion de subestaciones

Capıtulo 8

CORBA de tiempo real

8.1. Introduccion

Existe un gran numero de sistemas distribuidos que son sistemas de tiemporeal. Estos sistemas tienen requisitos respecto a su predictibilidad de extremoa extremo y la calidad de servicio (QoS) de sus actividades. Ejemplos deeste tipo de sistemas se pueden encontrar en control de procesos, avionicao telecomunicaciones entre otros campos. Si se desea tomar ventaja de losbeneficios de usar un ORB para el desarrollo de aplicaciones de sistemasdistribuidos en tiempo real, los requisitos para este tipo de sistemas debenser tenidos en cuenta a nivel de middleware.

RT CORBA [143] especifica mecanismos adicionales a aquellos de CORBAque pueden emplearse para incrementar el control de recursos y la predeci-bilidad de extremo a extremo de las aplicaciones de objetos distribuidos. Lafigura 8.1 proporciona una vista de las extensiones comparadas con CORBAtradicional. Las siguientes secciones proporcionan una descripcion de las en-tidades clave y las caracterısticas de un broker CORBA de tiempo real segunestablecen las especificaciones CORBA de tiempo real. Actualmente hay dosespecificaciones para tiempo real: una establece planificacion con prioridadfija y la otra establece planificacion dinamica. Aunque se da una vista generalde ambas, en la practica la mayorıa de ORBs de tiempo real son conformesa la especificacion de planificacion de prioridad fija.

8.2. CORBA de tiempo real de prioridad fija

La primera especificacion CORBA de tiempo real no soluciona el problemade la planificacion dinamica. Solo soporta planificacion de prioridad fija. El

131

132 CAPITULO 8. CORBA DE TIEMPO REAL

Figura 8.1: Extensiones CORBA-RT

objetivo de la especificacion es controlar los recursos para mejorar la pre-dictibilidad de extremo a extremo de un sistema distribuido de tiempo real.Respecto a la predictibilidad de extremo a extremo, la especificacion esta de-finida para:

Respetar las prioridades de los hilos entre clientes y servidores parala resolucion de la contencion de recursos durante el proceso de lasinvocaciones CORBA.

Limitar las inversiones de prioridad de los hilos durante el proceso deextremo a extremo.

Limitar las latencias de las operaciones de invocacion.

La especificacion depende de una extension de las entidades CORBA fun-damentales (ORB, POA, Current, threading model, etc.) y de los serviciosproporcionados por estas entidades. La especificacion CORBA de tiempo realpermite manejar tres tipos de recursos en un sistema distribuido:

Recursos del procesador.

Recursos de comunicaciones.

Recursos de memoria.

8.3. RT-ORB 133

8.3. RT-ORB

Un broker de tiempo real maneja una extension de la interfaz COR-BA:ORB que proporciona operaciones para crear y destruir componentes deun broker de tiempo real. Un broker de tiempo real incorpora funcionalidadque permite a la aplicacion que se ejecuta sobre el mismo especificar infor-macion relacionada con la calidad de servicio (QoS) o los recursos necesariospara la correcta operacion del sistema. Por ejemplo, se puede configurar elrango de prioridades de los hilos que el broker puede emplear durante suejecucion.

8.4. RT-POA

De la misma manera que el broker de tiempo real debe ser capaz de procesarlos requisitos de tiempo real de los objetos sobre el mismo, los adaptadoresde objetos que se ejecutan en el lado del servidor deben tambien entendercomo procesar dichos requisitos. El Adaptador de Objetos Portable (POA)de CORBA en tiempo real esta definido en el modulo RTPortableServer.El POA de tiempo real es un subtipo del PortableServer:POA de CORBA.El POA de tiempo real tiene dos caracterısticas que lo diferencian respectoal de CORBA:

Debe comprender las polıticas de tiempo real especificadas en la exten-sion de tiempo real.

Proporciona un conjunto adicional de operaciones que soportan losajustes de prioridad a nivel de objeto. El POA de tiempo real agrupaun conjunto de operaciones designadas para invalidar las prioridadesdeclaradas por el servidor basandose en las referencias de los objetos.Ejemplos de estas operaciones son create reference with priorityque permite establecer una prioridad de ejecucion para objetos COR-BA o referencias interoperables.

Un comportamiento habitual de los POAs de tiempo real es la encap-sulacion de valores relacionados con las polıticas de tiempo real del ladodel servidor en referencias a objetos interoperables (IORs) de modo que losclientes puedan acceder a dichos objetos para que sigan el comportamientode tiempo real esperado de los mismos.


8.5. Prioridades CORBA

Diferentes Sistemas Operativos de tiempo real (RTOSs) muestran diferen-tes esquemas de prioridades de hilos nativas. Como resultado de esta he-terogeneidad entre Sistemas Operativos de tiempo real, existen diferentesprioridades nativas que representan un problema cuando se trata de esta-blecer un comportamiento comun es un sistema distribuido heterogeneo detiempo real. CORBA de tiempo real soluciona este obstaculo definiendo untipo de prioridad CORBA que sea valido para todo el sistema. Como enlos esquemas de prioridad nativa de los Sistemas Operativos de tiempo real(RTOSs), la prioridad CORBA es un conjunto de valores enteros que trazael esquema de prioridades nativo de un Sistema Operativo de tiempo real(RTOS) especıfico a un esquema uniforme que es aceptado a nivel de todo elsistema.

CORBA de tiempo real tambien define un objeto PriorityMapping quese define como un IDL de tipo nativo. Los tipos nativos son una defini-cion de tipo especial en CORBA de la que existen implementaciones es-pecıficas en cada lenguaje de programacion. Un PriorityMapping en unobjeto de un lenguaje de programacion (una instancia de la clase RTCOR-BA::PriorityMapping en C++) en lugar de un objeto CORBA. Conse-cuentemente, tambien se proveen trazas a los lenguajes de programacion enconcordancia con CORBA de tiempo real. La figura muestra un mapeo deprioridades entre CORBA de tiempo real y dos Sistemas Operativos parti-culares. Notese que no es necesario trazar todas las prioridades de CORBAal SO. El interfaz de trazado de prioridades permite realizar trazados desdelas prioridades CORBA a los valores nativos del Sistema Operativo y desdeel Sistema Operativo a CORBA.

Las prioridades CORBA se usan para permitir a los clientes y a los ob-jetos CORBA especificar las prioridades a las que deben ser ejecutadas laspeticiones. Esto permite aumentar la predecibilidad de extremo a extremoen un mecanismo de planificacion de extremo a extremo.

8.6. Interfaz current de tiempo real

CORBA de tiempo real deriva la interfaz Current de tiempo real de lainterfaz CORBA::Current. El objetivo especıfico de Current para tiemporeal es obtener la prioridad CORBA para el hilo actual. El objeto RTCOR-BA::Current contiene un atributo de prioridad que se puede establecer y

8.7. MODELOS Y TRANSFORMACIONES DE PRIORIDADES 135

Modelo de prioridad DescripcionLa prioridad es transportada junto con la

Modelo de prioridad invocacion CORBA y es usada para asegurarpropagada por el cliente que todos los hilos se ejecutan posteriormente

a la invocacion con la prioridad adecuada.En este modelo, los objetos publican susprioridades CORBA en sus referencias a

Modelo de prioridad objetos. Esto permite al cliente conocer ladeclarada por el servidor prioridad de ejecucion de invocaciones en el

codigo del servant. La prioridad CORBA detiempo real de una invocacion no necesita serpasada de cliente a servidor en una invocacion.

Cuadro 8.1: Tabla de modelos de prioridades

consultar. Como resultado de establecer el atributo de prioridad, el brokerestablece la prioridad nativa del hilo al valor devuelto por PriorityMap-ping::to native. Con esta caracterıstica el proceso bajo ejecucion puedeactuar dinamicamente sobre la prioridad del hilo que ha sido establecida porel broker.

8.7. Modelos y transformaciones de priorida-

des

En el contexto de un sistema distribuido de tiempo real debe haber re-cursos que permitan la infraestructura para hacer cumplir la elegibilidadde ejecucion de hilos en objetos remotos. Para este proposito, CORBA entiempo real soporta dos tipos de modelos de prioridad para coordinar lasprioridades entre sistemas (ver tabla 8.1). El modelo de prioridades, juntocon las prioridades CORBA estan disenados para minimizar la inversion deprioridades de extremo a extremo ası como para limitar la latencia y el jitterpara aplicaciones con requisitos de tiempo real.

Ademas, es posible invalidar la prioridad declarada por el servidor en ba-se a las referencias por objetos. La interfaz POA CORBA de tiempo realproporciona cuatro operaciones para hacer esto. La prioridad del servidor sepuede cambiar en el momento de la creacion de una referencia a un objeto oen el momento de la invocacion al objeto.


Figura 8.2: Modelo de prioridad propagado por el cliente

Las polıticas del modelo de prioridades se deben aplicar a los objetos POAen el momento de la creacion. Las polıticas son propagadas desde los servido-res a los clientes en las IORs para permitir a los clientes conocer los modelosde polıticas soportados por los objetos CORBA. El modelo de propagaciones definido en el framework de calidad de servicio (QoS) de la especificacionde mensajes de CORBA. Las figuras 8.2 y 8.3 muestran como funcionan losmodelos de prioridad del cliente y del servidor.

Las transformaciones son transformaciones de prioridad definidas por elusuario que modifican la prioridad CORBA asociada con una invocacion.Las transformaciones tienen lugar cuando la invocacion es procesada por elservidor. Las transformaciones de prioridad trazan los valores de priorida-des CORBA de tiempo real a otros valores de prioridad CORBA definidospor la aplicacion. Estos pueden ser usados para implementar protocolos deprioridad especıficos. Como PriorityTransform es un tipo nativo IDL, seproporcionan trazas para diferentes lenguajes de programacion (C,C++,Aday Java) en la especificacion CORBA de tiempo real. Hay dos tipos de trans-formaciones de prioridad: entrante y saliente. Las transformaciones entrantestienen lugar cuando se recibe una invocacion por el servidor pero antes deque sea procesada por el servant. Las transformaciones salientes se aplican alas peticiones salientes desde un servant a otros objetos CORBA.

Las transformaciones de prioridad son utiles porque hay situaciones enque los modelos de prioridad declarada por el servidor o el cliente no son

8.8. SINCRONIZACION 137

Figura 8.3: Modelo de prioridad declarada por el servidor

suficientes. La ventaja de las transformaciones de prioridad es que permitenla aplicacion de la prioridad de ejecucion teniendo en cuenta factores externos.Por ejemplo, la ocurrencia de un suceso crıtico externo o la carga de trabajodel ordenador servidor se pueden usar para decidir la prioridad de la peticion.

8.8. Sincronizacion

Una de las partes mas difıciles de la construccion de una aplicacion concu-rrente es el “reparto” de procesos o la interaccion entre hilos (threads). Loshilos o procesos no son independientes unos de otros y el comportamiento delsistema depende de su sincronizacion y comunicacion. Podemos entender lacomunicacion como el traspaso de informacion entre diferentes hilos (threads)o procesos. Esto se puede lograr por medio de paso de mensajes o variablescompartidas.

La especificacion de CORBA en tiempo real proporciona un interfaz demutex para permitir la ejecucion de hilos en regiones protegidas por objetosmutex. Los objetos de tipo mutex proporcionan el grado de sincronizacionnecesario para proteger las secciones crıticas. CORBA en tiempo real propor-ciona dos operaciones en la interfaz RTORB para crear y destruir mutexes,por lo tanto se pueden emplear los mismos mecanismos de sincronizacion queemplea el broker en la aplicacion que funciona sobre el ORB. Esto ayuda areducir las inversiones de prioridad puesto que todos los mutexes emplean el


mismo protocolo.

8.9. Manejando la concurrencia

En el mundo real las cosas ocurren en paralelo. El termino concurrencia serefiere a la expresion del paralelismo presente en el mundo. En computacionel paralelismo es alcanzado por medio de la programacion concurrente. Eltermino “concurrente” no significa paralelo sino “potencialmente paralelo”.Esto es porque los programas o aplicaciones concurrentes estan formados poruna secuencia de procesos que se ejecutan en paralelo. El paralelismo dependede como se ejecuta esta coleccion de procesos:

La ejecucion es multiplexada en un procesador.

La ejecucion es multiplexada en un sistema multiprocesador donde lamemoria es compartida (computacion paralela).

La ejecucion en multiplexada en varios procesadores y la memoria noes compartida (sistema distribuido).

Ademas de proporcionar paralelismo virtual se emplea concurrencia a ni-vel de hilos (multi-threading) para permitir a la aplicacion incrementar sucontrol sobre como se ejecutan diferentes tipos de servicios y para soportar“preemption” de hilos para evitar la inversion de prioridades durante pe-ticiones de invocaciones extensas. Las APIs del Sistema Operativo no sonsiempre uniformes y cuando se desarrolla para varias plataformas resulta utilun modelo de interfaz de hilos. Esto es lo que proporciona CORBA en tiemporeal: un modelo para hilos y grupos de hilos que permite a las aplicacionesdistribuidas heterogeneas ser multi-hilo de una manera simple y uniforme.

CORBA en tiempo real introduce el concepto de agrupacion de hilos (th-readpool). Hay dos estilos posibles para un threadpool: con y sin carriles(figura 8.4). Un carril es un subconjunto del threadpool en el que los hilostienen el mismo RTCORBA:Priority.

Las operaciones para la creacion de threadpools permiten configurar eltamano de la pila y del buffer de peticiones para el threadpool. El tamano depila es importante porque los argumentos de las operaciones se almacenanen la pila y se debe proporcionar suficiente memoria para evitar violacionesde acceso.

8.10. MANEJO DE CONEXIONES 139

Figura 8.4: Modelos de Threadpool, con y sin carriles

Se pueden fijar otras caracterısticas interesantes durante las operacionesde creacion del threadpool:

Hilos estaticos: Si no se usan carriles, es el numero de hilos que seasignan al threadpool. En un threadpool con carriles designa el numerode hilos en cada carril.

Hilos dinamicos: Es el numero de hilos que se pueden crear dinami-camente y que se asignan al threadpool o al carril.

Prioridad: Si no hay carriles es la prioridad CORBA asignada a loshilos estaticos de un threadpool. En este caso los hilos dinamicos sepueden crear con la prioridad requerida para manejar la invocacion parala que fueron creados. Si los carriles estan en uso la prioridad CORBAse asigna a todos los hilos (estaticos y asignados dinamicamente) delcarril.

Otra opcion que se puede especificar cuando existen carriles es el prestamode hilos desde los carriles de baja prioridad. Una vez que el hilo prestadotermina la peticion se devuelve al carril original.

8.10. Manejo de conexiones

La predecibilidad es una caracterıstica importante de los sistemas de tiem-po real. En un ORB convencional la conexion no se establece hasta que serealiza la primera invocacion a un objeto. Esta aproximacion se conoce enCORBA como conexion implıcita (implicit binding). En una aproximacionimplıcita, los recursos de comunicaciones a lo largo del camino solicitadose establecen a demanda (on demand), son solicitados cuando se necesitan.


El establecimiento de la conexion es una fuente de sobrecarga que imponeuna penalidad en la primera invocacion realizada por el cliente. CORBA entiempo real anticipa este problema permitiendo la conexion explıcita. Lasaplicaciones clientes pueden controlar el momento en el que se establece laconexion a una referencia a un objeto desatado por medio de la operacionvalidate connection.

Como ocurre con todos los modelos, la conexion explıcita e implıcita tienensus ventajas y sus limitaciones. La conexion implıcita ayuda al desarrolla-dor a conservar los recursos del sistema y a compartir las conexiones entrelos diferentes clientes o hilos de ejecucion. Naturalmente, este modelo no essuficiente para aplicaciones de control y tiempo real y se necesita una apro-ximacion mejor para manejar los recursos disponibles. Esto es lo que pro-porciona el modelo de conexion explıcita. En este modelo la conexion a losobjetos se puede diferir hasta la ejecucion de la peticion (como en la conexionimplıcita) o los recursos se pueden reservar con antelacion a las peticiones(pre-establecimiento de las conexiones a los objetos del servidor). Esto re-duce la latencia y el jitter para la primera invocacion. Ademas, es posibleusar conexiones privadas o asignar un rango de prioridades a la conexion,reduciendo tambien la posibilidad de inversion de prioridades que ocurre enla aproximacion de conexiones multiplexadas.

Para soportar el modelo de conexion explıcita, CORBA en tiempo realproporciona la caracterıstica de conexiones con bandas de prioridad. Unaconexion con bandas de prioridad es una conexion con un conjunto asignadode bandas de prioridad. Las bandas de prioridad asignadas a una conexion nose pueden reconfigurar durante el tiempo de vida de la conexion y ningunaprioridad se puede establecer mas de una vez. Como muestra la figura 8.5 esprevisible que se puedan formar rangos no contiguos y no es necesario cubrirtodas las prioridades CORBA.

La idea de las bandas de prioridad es permitir a los clientes comunicarsecon los servidores usando multiples conexiones reservadas para invocacionesrealizadas a diferentes prioridades CORBA. Si la prioridad de las invocacionesno es respetada por el transporte se convertira en una fuente de inversion deprioridad.

La conexion se establece dependiendo del modelo de prioridad del objetoobjetivo. En el caso del modelo de prioridad propagada por el cliente, labanda se elige usando la prioridad establecida por el cliente. Si se usa el

8.11. RETARDO DE INVOCACION 141

Figura 8.5: Prioridad de bandas con conexion explıcita

modelo de prioridad propagada por el servidor, su prioridad se publica en unIOR y su valor se usa para seleccionar la banda.

Las conexiones con bandas son configuradas por los clientes y las polıticasson aplicadas unicamente en el lado del cliente. Por defecto, el ORB propor-ciona conexiones multiplexadas para conexiones cliente/servidor (figura 8.6).Es posible solicitar una conexion de transporte privado por medio del ob-jeto PrivateConnectionPolicy (figura 8.7). La ventaja de las conexionesprivadas es que asegura que ningun cliente interferira con otras peticionesen el caso de que se necesite una respuesta del servidor. Reservar una cone-xion privada permite mantener un canal de comunicaciones libre de traficomientras el cliente espera la respuesta de la peticion.

8.11. Retardo de invocacion

Limitar el tiempo en el que se debe obtener una respuesta de un servidores una herramienta util para desarrollar un sistema predecible. La predecibi-lidad se puede mejorar si los desarrolladores del sistema conocen el lımite su-perior de tiempo que una invocacion estara bloqueada esperando la respuestadel servidor. Esta funcionalidad se logra estableciendo timeouts. CORBA entiempo real emplea Messaging::RelativeRoundTripTimeoutPolicy pa-ra establecer el timeout para la recepcion de una respuesta a una invocacion.


Figura 8.6: Conexiones multiplexadas en CORBA de tiempo real

Figura 8.7: Conexion privada en CORBA de tiempo real

8.12. PROTOCOLO DE CONFIGURACION 143

En el caso de CORBA en tiempo real la polıtica del timeout es una polıti-ca exclusivamente del lado del cliente. Se aplica a clientes que cancelaranla peticion si la respuesta no llega antes de que expire el tiempo. Si la res-puesta llega al cliente despues de que el timeout haya expirado, entonces essimplemente descartada por el ORB.

8.12. Protocolo de configuracion

Las aplicaciones CORBA en tiempo real pueden encontrar que los requi-sitos de calidad de servicio (QoS) de mejor esfuerzo no se ajustan a susnecesidades. En el caso CORBA general las aplicaciones no necesitan preo-cuparse por la transparencia de localizacion en lo que se refiere al protocolousado para comunicaciones. De cualquier modo, los sistemas de tiempo realcomo los sistemas de control necesitan un ajustado orden y seleccion de losprotocolos usados para comunicaciones con el fin de mejorar la predictibili-dad de extremo a extremo. CORBA en tiempo real especifica una interfaz deprogramacion para seleccionar y configurar el protocolo de transporte subya-cente. En CORBA, las instancias IOP (el objeto que representa el protocolode interoperabilidad) contiene un protocolo ORB y un mapeo a un protocolode transporte subyacente. Notese que se usan dos protocolos: el protocolo demensajes ORB (GIOP en el CORBA estandar) y el protocolo de transporte(TCP/IP, como prescribe CORBA). La combinacion de ambos protocolos re-sulta en el Internet Inter-ORB Protocol de CORBA o IIOP, el protocolo deinteroperabilidad estandar de CORBA. Para proporcionar control a los pro-tocolos usados por la aplicacion, CORBA en tiempo real define un interfazque permite a las aplicaciones el control de las propiedades del protocolo. Esposible configurar las propiedades del protocolo tanto en el lado del clientecomo en el lado del servidor en un RT ORB.

Los protocolos se especifican por medio de una lista de protocolos que sepuede aplicar a los POAs. La lista indica los protocolos soportados por uncierto POA y el orden de los protocolos en la lista de protocolos indica elorden de preferencia para el uso de los protocolos.

En el lado del cliente, CORBA en tiempo real define una interfaz similarpara la polıtica de protocolo del cliente. La diferencia esta en que la polıticaes aplicada en el momento de conexion a una referencia a un objeto. En ellado del servidor se aplica en el momento de creacion del POA y la polıticaes propagada del servidor al cliente en los IORs.


8.13. Servicio de planificacion en tiempo real

El servicio de planificacion en tiempo real es una herramienta que fuerzael uso de un apolıtica de planificacion a traves de todo el sistema CORBAde tiempo real. Es de utilidad porque especificar los parametros de configu-racion apropiados en todas las partes de un sistema de tiempo real puedeser una tarea compleja. El servicio de planificacion proporciona una formade repositorio central desde donde los objetos CORBA pueden obtener unapolıtica de planificacion uniforme para todo el sistema.

8.14. Planificacion dinamica de tiempo real

CORBA

Con el fin de generalizar la especificacion CORBA de tiempo real y ajus-tarla a los requisitos de una gran cantidad de aplicaciones de tiempo real seha creado otra especificacion. La especificacion de tiempo real CORBA 2.0intenta ajustarse a sistemas distribuidos estaticos y dinamicos. Los sistemasdistribuidos dinamicos son aquellos en los que la carga de trabajo de losprocesos del sistema no es bien conocida de antemano y no se puede ponerlımites a la misma por lo que no es posible realizar un analisis fuera de lıneadel sistema. La especificacion generaliza los conceptos de planificacion de sis-temas dinamicos e hilos distribuibles con el fin de permitir a la aplicacion oal ORB tomar el control de las siguientes caracterısticas:

Se puede emplear cualquier disciplina de planificacion.

Los elementos de los parametros de planificacion asociados con la dis-ciplina elegida pueden ser cambiados en cualquier momento durante laejecucion.

La entidad planificable es un hilo distribuible que puede rebasar loslımites de los nodos, transportando el contexto de planificacion entreinstancias del planificador en estos nodos.

Con el fin de proporcionar mayor control sobre el comportamiento tempo-ral de la aplicacion, esta interacciona con el planificador que puede usar unao mas disciplinas de planificacion tales como planificacion de prioridad fija(fixed priority scheduling), el primer plazo primero (Earliest deadline first),menor laxitud primero (Least Laxity First), maximizar la utilidad acumula-da...... (Maximize Accrued Utility), etc.

8.14. PLANIFICACION DINAMICA DE TIEMPO REAL CORBA 145

La especificacion proporciona interfaces IDL para todas las disciplinas deplanificacion anteriores pero es posible establecer cualquier otra disciplina deplanificacion. El objetivo del planificador es determinar el mejor modo deajustarse a la planificacion dado un uso predicho de los recursos del sistemapor la aplicacion en un cierto instante de tiempo. La especificacion propor-ciona un framework en la forma de interfaces IDL que permite el desarrollode planificadores portables.

8.14.1. Hilo distribuible

En CORBA de tiempo real dinamico, la nocion de actividad de CORBA detiempo real 1.0 ha sido reemplazada por la de hilo distribuible. Para sistemasdinamicos y con el fin de lograr la puntualidad de extremo a extremo sedebe regular el comportamiento de la aplicacion entre-nodos. Esto se puedehacer usando el tiempo y los parametros relacionados con los recursos deuna manera consistente que abarque todo el sistema para la asignacion derecursos. Se define la abstraccion de comportamiento entre nodos de unaaplicacion (el hilo distribuible) para este proposito. Un hilo distribuible esuna abstraccion del modelo de programacion. Es un hilo que puede ejecutaroperaciones en objetos sin los lımites de los nodos fısicos. El hilo distribuiblees la entidad planificable en esta especificacion.

Cada hilo distribuible puede tener varios parametros de ejecucion (prio-ridad, plazo, funciones de utilidad, etc.) para especificar la puntualidad deextremo a extremo con el fin de completar el conjunto de operaciones se-cuenciales en objetos que pueden residir en diferentes nodos fısicos. El hilodistribuible transporta informacion de planificacion a traves del sistema dis-tribuido.

8.14.2. Bifurcacion de hilo distribuible

Bifurcar es la parte del modelo de concurrencia que trata de la creacionde nuevos contextos de ejecucion. La especificacion permite la bifurcacionexplıcita de un hilo distribuible por medio de la operacion spawn. Un ejemplode bifurcacion es aquel de las invocaciones de un solo sentido mientras el hilodistribuible que realiza las invocaciones no es bloqueado por el servant pararealizar las invocaciones.


Figura 8.8: Hilo distribuible con segmentos de planificacion anidados

8.14.3. Segmentos planificables

Un hilo distribuible consiste en uno o mas segmentos planificables. Unsegmento de planificacion representa una secuencia de control de flujo re-lacionada con un conjunto de parametros de planificacion. Un segmento deplanificacion tiene un unico punto de partida y un punto de finalizacion quepuede rebasar los lımites del procesador.

La figura 8.8 muestra una ilustracion de un hilo distribuible con segmen-tos de planificacion anidados. Donde termina el segmento X, el contexto deplanificacion del segmento W es puesto a un lado y los parametros de plani-ficacion del segmento X se usan por el hilo distribuible. Cuando termina elsegmento X se usan los parametros de planificacion del segmento W hastaque este tambien termina.

8.14.4. Planificador CORBA de tiempo real

El planificador es una extension de CORBA de tiempo real que regulalos requisitos de planificacion y los parametros de las aplicaciones que seejecutan sobre el broker. El planificador decide el orden de ejecucion de la saplicaciones en los nodos distribuidos del sistema CORBA. El planificador se

8.14. PLANIFICACION DINAMICA DE TIEMPO REAL CORBA 147

basa en las siguientes caracterısticas para decidir la elegibilidad de ejecucionen los sistemas CORBA:

El planificador responde a las peticiones de las aplicaciones (para deci-dir los elementos de planificacion) y en respuesta a las acciones de lasaplicaciones (e.g. las invocaciones usando el interfaz Portable Intercep-tor).

El planificador usa la informacion proporcionada por la aplicacion paradecidir sobre la elegibilidad de los hilos.

La arquitectura del planificador esta basada sobre el concepto de queel sistema distribuido se puede considerar como un conjunto de hilosdistribuibles.

Se supone que la planificabilidad del sistema se puede direccionar ma-nejando la alocacion de recursos de los hilos distribuibles.

Los hilos distribuibles y el planificador interaccionan en puntos de pla-nificacion especıficos tales como las transiciones a nuevos procesadoresdonde la informacion de planificacion debe ser re-interpretada.

El planificador es un planificador modular. Si un ORB tiene un pla-nificador instalado, todas las aplicaciones que se ejecutan en ese ORBusan ese planificador.

8.14.5. Puntos de planificacion

Los puntos de planificacion son los puntos en el tiempo y/o en el codi-go donde se ejecuta el planificador. Esto puede resultar en un cambio dela planificacion actual. Los puntos de planificacion definidos se muestran acontinuacion:

Creacion de un hilo distribuible.

Termino o finalizacion de un hilo distribuible.

Comienzo de un segmento de planificacion.

Actualizacion de un segmento de planificacion.

Finalizacion de un segmento de planificacion.


Una operacion de invocacion CORBA, especıficamente los puntos deintercepcion de peticiones y respuestas proporcionados por la especifi-cacion Portable Interceptor.

Creacion de un administrador de recursos.

Bloqueo en una peticion por un recurso.

Desbloqueo como resultado de la liberalizacion de un recurso.

8.14.6. Recurso enterado de la planificacion

La especificacion permite la creacion de recursos enterados de la plani-ficacion a traves del administrador de recursos. Los recursos pueden tenerinformacion de planificacion asociada con ellos.

Parte IV

Desarrollo de HIGGS RT

149

Capıtulo 9

Hardware y equipamiento

9.1. Introduccion

El robot Pioneer 2-AT8 pertenece a la familia de robots moviles de Activ-Media [1]. Fue adquirido por ASLab en Febrero de 2003. ActivMedia disenay construye robots moviles inteligentes ası como sistemas de navegacion, con-trol y de soporte a la percepcion sensorial para los mismos. Esta empresa havendido mas de 1700 robots en todo el mundo, y estos han ganado varios yprestigiosos concursos.

Pioneer es una familia de robots moviles de dos ruedas y de cuatro ruedas,incluyendo los robots moviles Pioneer 1, Pioneer AT, Pioneer 2 -DX, -DXe,-DXf, -CE, -AT, -DX8, -AT8 y Pioneer 3 -AT y -DX. Estas pequenas platafor-mas de desarrollo e investigacion comparten una arquitectura comun y unabase de software con todos los robots ActivMedia. Todos ellos emplean unaarquitectura de control robotico cliente-servidor que fue originalmente desa-rrollada por el Dr. Kurt Konolige de SRI International Inc. y la Universidadde Standford.

El objetivo de la adquisicion de este robot es incorporar al laboratoriouna plataforma movil e implementar sistemas de control inteligentes para lamisma. Con la incorporacion del robot el laboratorio ASLab dispone de unanueva plataforma con la que comenzar a hacer pruebas de control inteligentey por tanto avanzar hacia la consecucion de su objetivo a largo plazo, querecordemos que es la creacion de sistemas de control capaces de aprender acontrolar cualquier sistema y de tener conciencia de sı mismos.

151

152 CAPITULO 9. HARDWARE Y EQUIPAMIENTO

Figura 9.1: Pioneer 2-AT8

Pioneer 2-AT8 es una robusta plataforma que incorpora todos los elementosnecesarios para la implementacion de un sistema de navegacion y control delrobot en una gran cantidad de entornos del mundo real.

El tamano del robot es pequeno en comparacion con sus prestaciones. Pesa14 kg. con una baterıa. Su estructura es de aluminio. Estas caracterısticas lepermiten poder transportar hasta 30 kg. sobre el mismo. El microcontroladorque gobierna los diversos dispositivos electronicos conectados es un HitachiH8S. Los principales componentes del robot son:

PanelEs la plataforma superior del robot. Esta destinado al montaje de nue-vos accesorios o elementos para el robot, como podrıan ser camaras,laser o brazos articulados. El panel esta dotado con diversos orificios atraves de los cuales podrıan ubicarse los cables de los posibles disposi-tivos a anadir. A traves de este panel se puede acceder al interior delrobot a traves de una ranura de acceso.

Panel de controlConsiste en un panel de acceso al microcontrolador del robot. Esta cons-tituido por varios botones de control, leds indicadores de estado y unpuerto serie RS-232 con un conector de 9 pines.El led rojo con la etiqueta PWR esta encendido siempre que se encien-da el robot. El led verde con la etiqueta STAT depende del modo de

9.1. INTRODUCCION 153

Figura 9.2: Panel de control

operacion (presenta una lenta intermitencia cuando el microcontrola-dor espera una conexion con un cliente y rapida cuando el cliente seha conectado). El led con la etiqueta BATTERY indica el estado denuestras baterıas (rojo si el voltaje esta por debajo de 11.5 voltios)El conector serie incorpora dos leds que indican la entrada (RX) y sa-lida (TX) de datos. A traves de este puerto serie se podra establecer lacomunicacion con el microcontrolador del robot desde un PC externoal mismo. Este puerto esta compartido internamente con el puerto serieal que se conecta el computador de abordo o bien una radio modem.Mediante un circuito electronico se deshabilita el puerto serie internosi no existe una conexion con el computador de a bordo o un radiomodem.RADIO y AUX son dos interruptores que habilitan o deshabilitan res-pectivamente los eventuales dispositivos radio modem o el puerto deserie auxiliar. Ambos motores incorporan un led que indica el estadode los mismos.El pulsador RESET resetea el microcontrolador, deshabilitando cual-quier conexion activa con este (sonares, motores, etc). Ası mismo existeotro pulsador que activa o desactiva los motores.

Cuerpo del robotEl cuerpo de aluminio del robot aloja las baterıas, los motores, loscircuitos electronicos y el resto de componentes. Ademas existe espaciopara alojar diversos accesorios, como un PC a bordo, un radio modemo radio ethernet o para incorporar sensores.


Componente Descripcion10 MHz Hitachi H8S/2357 con 32K RAM

128K FLASHOpcion para expansion 512K FLASH o SRAM3 puertos serie RS-232 configurables desde(4 conectores) 9.6 a 115.2 kbaudios2 grupos de 8 sonares cada uno2 conectores 8-bit para sensores de

choque/entrada digital1 P2-Gripper/Conector 8-bits de E/S digitalde E/S varias con 1 entrada analogica1 conector de expansion/bus con 5 entradas analogicas

2 salidas analogicasbus E/S de 8-bit con R/Wy 4 selecciones de chip

Puerto de joystick con 2 ejes2 botones

Panel de control del usuarioConector serie del controladorPotencia principal yLED bi-color indicadordel nivel de baterıaInterruptores de encendido AUX

RADIOy sus LED correspondientes

Timbre piezoelectricoInterfaz a la placa de lıneas de control para pulsosMotores/Potencia con de ancho modulado y

direccion del motor8-bits de entrada digital

Cuadro 9.1: Caracterısticas del microcontrolador y la placa

Grupo de sonaresEl robot esta dotado con dos grupos de 8 transductores (sonares) cadauno. Estos dispositivos permiten la deteccion de objetos y la determina-cion de la distancia a la que se encuentran los mismos. Esta informacionpuede ser utilizada para la elaboracion de sistemas de navegacion y con-trol. Los sonares estan situados en la parte frontal y trasera del robot.Cada grupo de transductores cubre un rango de 180o, de tal modo que

9.1. INTRODUCCION 155

Figura 9.3: Grupo de sonares

el conjunto de sonares cubre los 360o alrededor del robot.Cada grupo de sonares tiene su propia tarjeta electronica controlado-ra, lo que permite realizar un control independiente. Cada Grupo desonares esta multiplexado. La frecuencia de adquisicion de datos es de25 Hz (40 milisegundos) por sonar. El rango de deteccion se situa entrelos 10 cm y los 4 m. se puede controlar que sonar se dispara a travesde software. Por defecto se disparan del 0 al 7.Igualmente se puede ajustar la sensibilidad de los sonares y el rangodetectado mediante un potenciometro. Este hecho permite adaptar elrobot al ambiente que le rodea. La configuracion de los sonares conganancias bajas reduce sus capacidades de detectar pequenos objetos.Este hecho puede ser beneficioso en el caso de que el robot se mueva enambientes ruidosos o con superficies muy reflectantes. Por le contrario,aumentar la sensibilidad de los sonares estableciendo ganancias altasaumenta las posibilidades de detectar objetos pequenos y objetos queestan a gran distancia. Esto es beneficioso si el ambiente en el que operael robot es abierto y silencioso.

Motores y encodersEl robot esta dotado de 4 motores de corriente continua reversibles que


pueden desarrollar altas velocidades y par de torsion. Cada uno de ellosesta acompanado de un encoder optico de gran precision que permitendeterminar la velocidad y la posicion del robot.Naturalmente el robot incorpora diversos circuitos electronicos que go-biernan los anteriores elementos. La velocidad de los motores es regu-lada mediante senales de tipo PWM. Del mismo modo, este tipo desenales son las que dan los encoders al microcontrolador.

Microcontrolador Hitachi H8SLos dispositivos electronicos presentes en el robot son controlados poreste modelo de microcontrolador. Su cometido es manejar los actuado-res, disparar y recoger la senal de los sonares, controlar la electronicadel robot y realizar el resto de funciones de bajo nivel. Es capaz decomunicarse con otras maquinas a traves de una interfaz serie RS-232.

BaterıasEl robot esta alimentado con tres baterıas de 12 voltios y 7 amperios-hora cada una. Son intercambiables entre sı y accesibles a traves deuna mini-puerta en la parte trasera del robot. Por tanto disponemosen total de 252 vatios-hora, lo que asegura varias horas de autonomıapara la plataforma.

9.2. Sistema Operativo AROS

Ademas del software de sistema abierto ActivMedia Robotics OperatingSystem (AROS) incorporado a bordo del controlador del robot, cada robotActivMedia dispone de una gran cantidad de aplicaciones de software clien-te para control robotico avanzado. El desarrollo de software esta facilitadopor la base ActivMedia Robotics Interface for Applications (ARIA), hechapublica bajo licencia GNU, completada con librerıas de C++ completamen-te documentadas y codigo fuente.

Como se ha indicado en capıtulos anteriores, el robot Pioneer 2-AT8 escontrolado en primera instancia por un microprocesador Hitachi H8S. Pa-ra el desarrollo de la comunicacion de este con cualquier otra maquina espreciso utilizar una arquitectura cliente-servidor. Segun este modelo, sobre elmicrocontrolador del robot corren los procesos servidores que se encargan del

9.2. SISTEMA OPERATIVO AROS 157

Figura 9.4: Arquitectura de control cliente-servidor de ActivMedia Robotics

manejo y control de las tarjetas controladoras de los dispositivos electronicosy de realizar las funciones de bajo nivel del sistema.

ActivMedia Robotics Operating System (AROS) es el conjunto de estosprocesos servidores y constituye un sistema operativo que corre en el mi-croprocesador. Es un software de bajo nivel cuyo cometido es manejar laregulacion de velocidad de los motores, disparar y recoger la senal de lossonares, recoger las senales de los encoders y en general llevar a cabo todaslas funciones de bajo nivel. Ademas es el responsable de transmitir por mediode comandos esta informacion a otra aplicacion, la cual sera cliente de AROS.En nuestro caso, el cliente de AROS sera un programa que correra sobre laCPU de Higgs y que enviara comandos y recibira informacion del micropro-cesador Hitachi. Se aclara ya desde ahora que este proceso cliente de AROSsera a su vez servidor de eventuales programas clientes de la red local.

Una de las principales caracterısticas de AROS es que es actualizable ycompatible con otros robots del mismo fabricante.


9.2.1. Protocolo de comunicacion entre AROS y uncliente

AROS se comunicara con su cliente mediante una interfaz serie RS-232usando un protocolo especial de comunicaciones para la transmision de pa-quetes de datos, de un tipo desde el cliente al servidor y de otro distintodesde el servidor al cliente. Los paquetes de datos que envıa AROS se llamanServer Information Packets (SIPs). Los paquetes que recibe son comandos aejecutar en los actuadores (Client Commands).

Ambos protocolos son un flujo de bits de un maximo de 208 bytes cadauno que consisten en cinco elementos:

Una cabecera de dos bytes

Un contador de un byte de los siguientes paquetes

El comando del cliente o el SIP del servidor

Argumentos o bits de datos

Checksum (chequeo) de dos bytes

AROS ignora comandos o paquetes cuyo byte contador exceda de 252 o pre-sente un checksum erroneo. Sin embargo el interfaz cliente-servidor esta pro-visto de metodos para reconocer paquetes defectuosos, puesto que muchos delos comandos alteran variables de estado en el servidor. Examinando el valorde estas variables se pueden detectar y reutilizar comandos defectuosos.

Al disenar aplicaciones cliente se han de tener en cuenta las limitacionesde la comunicacion serie. En terminos generales, se enviara un comando o unpaquete de datos entre cada tres y cinco milisegundos.

9.2.2. Paquetes de informacion del servidor AROS

Los paquetes que envıa el servidor, SIP, informan al cliente sobre el estadodel robot y ofrecen diversas lecturas sensoriales. Estos paquetes tienen laestructura que se muestra en la tabla 9.2


NAME VALUE DESCRIPTIONHEADER int Exactly 0xFA, 0xFBBYTE COUNT byte Number of data bytes + 2 (checksum), not including header

or byte-count bytesSTATUS/ 0x3S Motor statusPACKET 2 Motors stoppedTYPE 3 Robot movingXPOS int Wheel-encoder integrated coordinates; platform-dependent

units; multiply byYPOS int DisConvFactor to convert to milimeters.THPOS Sint Orientation in platform-dependent units—multiply by An-

gleConvFactor for degrees.L VEL Sint Wheel velocities in mm/sec (VelConvFactor=1.0)R VEL SintBATTERY byte Battery charge in tenths of volts (101=10.1 volts, for exam-

ple)STALL AND int Motor stall and bumper indicators. Bit 0 is the left wheelBUMPERS stall indicator, set to 1 if stalled. Bits 1-7 correspond to the

first bumper I/O digital input states (accesory dependent).Bit 8 is the right wheel stall, and bits 9-15 correspond thesecond bumper I/O states, also accesory and applicationdependent.

CONTROL Sint Setpoint of the server’s angular position servo—multiply byAngleConvFactor for degrees

FLAGS Sint Bit 0 motor status; bits 1-4 sonar array status; bit 5 E-STOP button status.

COMPASS byte Electronic compass accesory heading in 2-degree unitsSONAR COUNT byte Number of new sonar readings included in SIP

NUMBER byte If Sonar Count¿0, is sonar disc number 0-31; reading followsRANGE int Sonar range value; multiplied by RangeConvFactor

... ...REST OF THE SONAR READINGS...GRIP STATE byte Gripper state byteANPORT byte Selected analog port number 1-5ANALOG byte User Analog input (0-255—0-5 VDC) reading on selected

portDIGIN byte Byte-encoded User I/O digital inputDIGOUT byte Byte-encoded User I/O digital outputCHECKSUM int Packet-integrity checksum

Cuadro 9.2: AROS - SIP

9.2.3. Comandos de un cliente

AROS posee un formato estructurado en comandos para recibir y respon-der a ordenes del cliente. Cada comando esta determinado unıvocamente porun numero. Los comandos son los que se muestran en las tablas 9.3 y 9.4.


COMMAND # ARGS DESCRIPTION AROSBefore Client Connection

SYNC0 0 none Start connection. Send in sequence. AROS echoes 1.0SYNC1 1 none syncronization commands back to client, andSYNC2 2 none robot-specific autosynchronization after SYNC2.

After Established ConnectionPULSE 0 none Resets server watchdog 1.0OPEN 1 none Starts the AROS servers 1.0CLOSE 2 none Close servers and client connection 1.0POLLING 3 string Change sonar polling sequence (see text) 1.0ENABLE 4 int 1=enable; o=disable the motors 1.0SETA 5 Sint Translational acceleration, if positive, or decele-

ration, if negative; mm/sec/sec1.0

SETV 6 int Sets maximum translational velocity; mm/sec 1.0SETO 7 none Resets local position to 0,0,0 origin 1.0MOVE 8 Sint Translate (+) forward or (-) back mm distance 1.0ROTATE 9 Sint Rotate (+) counter or (-) clockwise degrees/sec 1.0SETRV 10 int Sets maximum rotational velocity; degrees/sec 1.0VEL 11 Sint Translate at mm/sec forward (+) or backward (-) 1.0HEAD 12 Sint Turn to absolute heading; ±degrees(+=ccw) 1.0DHEAD 13 Sint Turn relative to current heading; (+) counter or

(-) clockwise degrees1.0

SAY 15 string As many as 20 pairs of duration (20 ms incre-ments)/tone (half-cycle) pairs

1.0

CONFIG 18 none Request configuration SIP 1.0ENCODER 19 int Request one (1), a continuous stream (>1), or

stop (0) encoders SIPs1.0

RVEL 21 Sint Rotate at (+) counter or (-) clockwise; de-grees/sec

1.0

DCHEAD 22 Sint Heading setpoint relative to last point;±degrees(+=ccw)

1.0

SETRA 23 Sint Rotational (+) acceleration or (-) decceleration,in degrees/sec/sec

1.0

SONAR 28 int 1=enable, 0=disable all sonar; otherwise, use bit0 to enable (1) or disable (0) a particular array1-4, as specified in argument bits 1-4

1.0

STOP 29 none Stops robot; motors remain enabled 1.0DIGOUT 30 2 bytes Bits 8-15 is a byte mask that selects the output

port(s); Bits 0-7 set (1) or reset (0) the selectedport(s)

1.0

VEL2 32 2 bytes Independent wheel velocities; Bits 0-7 for rightwheel, Bits 8-15 for left wheel; AROS in 20mm/sec increments

1.0

GRIPPER 33 int Gripper server commands. See the Pioneer 2Gripper or PeopleBot manual for details.

1.0

ADSEL 35 int Selects the A/D port number for reporting An-port value in standard SIP

1.0

Cuadro 9.3: AROS - Comandos del cliente (1)


COMMAND # ARGS DESCRIPTION AROSGRIPPERVAL 36 int Gripper server values. See Pioneer 2 Gripper or

PeopleBot manual for details1.0

GRIPREQUEST 37 none Request one (1), a continuous stream (>1), orstop (0) Gripper SIPs. See Pioneer 2 Gripper orPeopleBot manual for details

1.0

IOREQUEST 40 none Request one (1), acontinuous stream (>1), or stop(0) IO SIPs

1.0

PTUPOS 41 2 bytes Msbyte is port number (1-4), lsbyte is pulse widthin 100 µsec units P2OS

-

TTY2 42 string Sends string argument to serial device connectedto AUX (AUX1 on P2-H8S) port

1.0

GETAUX 43 int Request to retrieve 1-200 bytes from the AUX(AUX1 on P2-H8S) serial port; 0 flushes the buf-fer.

1.0

BUMP STALL 44 int Stall robot if front (1), rear (2) or either (3; AROSdefault) bumps contacted. Off is 0.

1.0

TCM2 45 int TCM2 Module commands; see TCM2 Manual fordetails.

1.0

DOCK 46 int Default is OFF; 1=enable docking signals; 2=ena-ble dosking signals and stop the robot when do-cking power sensed.

-

JOYDRIVE 47 int Default is 0=OFF; 1=allow joystick drive fromhardware port while also connected with a client

1.0

E STOP 55 none Emergency stop, overrides deceleration 1.0E STALL 56 int 1(AROS default)=Emergency stop button causes

stall;0=off1.0

STEP 64 none Single-step mode (simulator only) 1.0TTY3 66 string Send string argument to serial device connected

to AUX2 P2-H8S serial port1.0

GETAUX2 67 int Request to retrieve 1-200 bytes from the AUX2P2-H8S serial port; 0 flushes the buffer.

1.0

ROTKP 82 int Change working rotation Proportional PID value(not FLASH default)

1.0

ROTKV 83 int Change working rotation Derivative PID value(not FLASH default)

1.0

ROTKI 84 int Change working rotation Integral PID value (notFLASH default)

1.0

TRANSKP 85 int Change working translation Proportional PID(not FLASH default)

1.0

TRANSKV 86 int Change working translation Derivative PID value(not FLASH default)

1.0

TRANSKI 87 int Change working translation Integral PID value(not FLASH default)

1.0

REVCOUNT 88 int Change working revcount (not FLASH default) 1.1PLAYLIST 91 none Request AmigoBot sounds playlist packet 1.0SOUNDTOG 92 int 0=mute or 1=enable buzzer 1.0

Cuadro 9.4: AROS - Comandos del cliente (2)


9.3. Conexion cliente-servidor AROS

Para ejecutar cualquier tipo de programa de control sobre el robot (procesocliente) es preciso, como ya ha quedado claro, establecer una conexion con elservidor AROS a traves de una interfaz serie. Despues del establecimiento dela conexion el cliente enviara comandos y recibira informacion del servidor.

Cuando se enciende el robot o se pulsa reset, AROS espera en un modoespecial llamado de espera. En este proceso AROS escucha la posible llegadade paquetes de comunicacion para establecer una conexion cliente-servidor.Para establecer la misma, la aplicacion cliente debe enviar una serie de trespaquetes de sincronizacion (los comandos SYNC0, SYNC1 y SYNC2) y re-cuperar las respuestas del servidor.

Despues de recibir el paquete SYNC2, AROS enviara informacion sobrela configuracion del robot, con lo que se concluye el proceso de conexion.A continuacion el cliente debe enviar el comando OPEN, que ordena al mi-croprocesador Hitachi H8S la ejecucion de funciones de mantenimiento yautochequeo y de inicio de diversos procesos servidores como el control delos sonares y los motores.

Ademas AROS incorpora un watchdog o programa de seguridad que esperaque, una vez se ha conectado el cliente, se reciban al menos un paquete decomunicacion cada cierto periodo de tiempo (este periodo es configurable).

Para cerrar la conexion se debe enviar el comando CLOSE.

9.4. ARIA

ActivMedia Robotics Interface for Applications (ARIA) es un paquete desoftware orientado a objetos programado en C++ que constituye una API(Applications Programming interface) para el control de una variedad de sis-temas roboticos inteligentes, incluyendo el controlador del robot ActivMediay los sistemas accesorios.

Como se dijo anteriormente en 9.2, la comunicacion entre el micropro-cesador Hitachi H8S con cualquier maquina requiere de una arquitecturacliente-servidor. Hemos visto como los procesos servidores constituıan el sis-tema operativo llamado AROS. Estos se limitaban a la gestion de las tarjetaselectronicas y de las funciones de bajo nivel de la plataforma movil.

9.4. ARIA 163

Sin embargo en el lado del servidor AROS no se pueden llevar a cabo tareasinteligentes o de control. ARIA es el software del lado del cliente. Gracias aeste paquete de clases nos podremos comunicar y controlar el robot desdeaplicaciones cliente.

Mediante ARIA se podran construir aplicaciones para el control de alto ni-vel del robot: desde la ejecucion de simples comandos hasta la elaboracion decomportamientos inteligentes (detectar y evitar obstaculos, reconocimientode caracterısticas de objetos, exploracion, etc).

ARIA esta registrado bajo la GNU Public License, lo que significa quees un software de codigo abierto. Igualmente, todo software desarrollado apartir de ARIA debe ser distribuido proporcionando el codigo fuente.

9.4.1. Comunicacion con el robot

Una de las principales funciones de ARIA y el primer cometido de cualquieraplicacion de control para el robot es establecer y gestionar la comunicacioncliente-servidor AROS entre los dispositivos del robot y la aplicacion cliente.

ARIA suministra diversas clases para establecer esta conexion: ArDe-viceConnection y sus hijos ArTcpConnection y ArSerialConnectionpermiten la configuracion de los puertos del computador (puertos serie opuertos IP) para la conexion a traves de ellos con el robot (puerto serie) ocon un simulador del mismo (puertos IP).

Despues de establecer la conexion, las funciones principales que se reali-zan son la lectura y escritura de datos de los dispositivos. Estas operacio-nes se realizan a traves de las funciones ArDeviceConnection:write() yArDeviceConnection:read(). Sin embargo el programador no tiene porque utilizar estos metodos directamente, puesto que la clase ArRobot (sec-cion 9.4.2) incorpora metodos que se apoyan en los anteriores para separar yclasificar adecuadamente los paquetes del servidor AROs.

9.4.2. ArRobot

ArRobot es la clase que constituye el corazon de ARIA. Actua comopasarela de la comunicacion cliente-servidor y gestiona la sincronizacion delsistema y la recoleccion y distribucion de informacion referente al estado delmismo.


ArRobot gestiona los detalles de bajo nivel, al construir y enviar coman-dos al robot, y al recibir y decodificar los paquetes de informacion del servidor(SIPs).

Los SIPs (ver seccion 9.2.2) son enviados desde el robot cada 100 ms atraves de la conexion realizada. ArRobot provee el llamado SIP handler, loque permite gestionar la recepcion de estos paquetes de forma sıncrona.

Desde la parte del cliente se pueden enviar directamente comandos o usarlos diversos metodos y acciones de ARIA. Estas acciones y metodos se con-vierten posteriormente, de forma invisible al programador, en comandos di-rectos.

Por otra parte, cada vez que una aplicacion cliente basada en ARIA recibeun SIP ArRobot lleva a cabo una serie de cinco tareas automaticamente:

Gestion del SIP

Interpretacion de la informacion sensorial.

Gestion y resolucion de las acciones del cliente

Examen del estado del sistema

Desempeno de las tareas programadas

Ademas el programador puede anadir tareas a las anteriormente citadas.

9.4.3. Comandos y acciones

La aplicacion cliente puede controlar el robot a traves de comandos directosy comandos de movimiento a traves de acciones.

Si se desea, es posible enviar comandos directos al robot a traves de la claseArRobot. Los comandos directos consisten en un byte, que constituye elnumero de comandos a enviar. Puede estar seguido de uno o mas argumentos.Las funciones que se utilizan para enviar comandos directos son:

ArRobot::com()

ArRobot::comInt()

ArRobot::comStr()

ArRobot::comStrN().

9.4. ARIA 165

Se utilizaran una y otra en funcion del numero de argumentos del comando.

El nivel inmediatamente superior a los comandos directos son los comandosde movimiento. La clase ArRobot incorpora metodos para enviar comandosexplıcitos de movimiento al robot. Mediante estos metodos se puede, porejemplo, establecer la velocidad lineal y de rotacion del robot, provocar sumovimiento a una distancia determinada o detenerlo.

Por ultimo se puede controlar el robot desde un nivel de abstraccion su-perior. Es posible definir acciones o usar las ya construidas en Aria. Lasacciones serıan comportamientos o pautas que debe seguir el robot. Se de-ben establecer prioridades entre las diversas acciones que se han anadido alrobot, pues durante la ejecucion del programa pueden entrar en conflicto. Esdecir, dependiendo del estado del robot y de la prioridad de las acciones, sedebera ejecutar una u otra accion en cada momento. Las clases que permitenla definicion de acciones y la resolucion de prioridades se llaman ArActiony ArResolver.

Las acciones (alto nivel) y los comandos (bajo nivel) pueden entrar enconflicto y provocar errores en el control. Entre los objetivos del proyecto noesta el control inteligente del robot. Sin embargo, en futuros desarrollos elprogramador debera ser cuidadoso y tener en cuenta este hecho.

9.4.4. Otras caracterısticas

ARIA es un potente y robusto paquete compuesto por mas de cien clasesprogramadas en C++. Por tanto, ademas de las caracterısticas enunciadasanteriormente, posee otras muchas. Existen clases para el control de disposi-tivos como camaras, laser o pinzas, clases con utilidades matematicas o parael manejo de tiempos, etc. Dados los objetivos del presente proyecto (vercapıtulo 1) se destacan las siguientes clases:

ArKeyHandler y ArJoyHandler. Permiten el control del robot atraves del teclado o de un joystick respectivamente.

ArThread. Es una clase envolvente o wrapper de la librerıa pthreads.Permite la creacion de subprocesos o threads dentro de una aplicacion.

ArFunctor. Es una clase que permite la creacion de punteros a fun-ciones.


ArSocket. Es una clase envolvente o wrapper de las librerıas para elmanejo de sockets.

Capıtulo 10

Sistemas operativos de tiemporeal

10.1. Introduccion

Existen muchos sistemas operativos de tiempo real de diversos vendedorescomo: VxWorks, QNX, LynxOS, VRTX, pSOS, Nucleus RTOS, RTEMS,OSE y eCos. En este capıtulo se realiza una enumeracion de diversos SistemasOperativos de tiempo real que han sido analizados para la realizacion de esteproyecto.

10.2. VxWorks

VxWorks es un sistema operativo de tiempo real realizado y vendidopor Wind River Systems [34] de Alameda, California, USA. VxWorks tienesoporte de red y esta disenado para su uso en sistemas distribuidos. Se puedeejecutar en una gran variedad de hardware, incluyendo sistemas basados enARM, MC680x0, MC683xx, Intel i960, Intel i386, R3000, SPARC, FujitsuSPARClite, TRON Gmicro y PowerPC.

Debido a que VxWorks generalmente se usa en sistemas empotrados,requiere un host para desarrollo de programas; algunas plataformas hostsoportadas son Sun3, Sun4, HP9000, IBM RS-6000, DEC, SGI, MIPS, eIntel i386. El entorno de desarrollo esta basado en metodos de compilacioncruzada o desarrollo remoto.

Entre las caracterısticas principales de VxWorks podemos citar un rapidokernel multitarea, con planificacion de tareas pre-emptiva, rapida respuesta

167

168 CAPITULO 10. SISTEMAS OPERATIVOS DE TIEMPO REAL

Figura 10.1: Software y documentacion de Tornado 2.0.2 / VxWorks 5.4

a interrupciones, facilidades para sincronizacion y comunicacion entre tareas,administracion de memoria compatible con UNIX, facilidades multiprocesa-dor, un shell para interfaz de usuario, capacidades de depuracion simbolicasy a nivel de codigo, monitorizacion de rendimiento y un sistema de ficherosde E/S.

La idea inicial de este proyecto era realizar un sistema de control parala plataforma robot movil Pioneer 2-AT8 empleando VxWorks. Semejanteimplementacion es posible. El codigo del broker CORBA llamado ICa hapodido ser compilado empleando Tornado 2.0.2 / VxWorks 2.4 tras rea-lizar ciertas modificaciones. Pero en esta version no se puede comunicar laplataforma movil con otros equipos empleando una red wireless. Para estaprestacion es necesaria una version posterior de la plataforma Wind River ensus versiones para equipos de red, dispositivos de consumo o dispositivos in-dustriales. Estas versiones son mas caras que la version de proposito general,y dado su elevado coste hemos optado por emplear alguna de las variantesde Linux para tiempo real.

10.3. OSE

Operating System Embedded (OSE) [10] es un sistema operativo detiempo real vendido por Enea. Enea AB es una companıa Sueca del sector de

10.3. OSE 169

Figura 10.2: Kit de desarrollo OSE

tecnologıas de la informacion que trabaja en sistemas empotrados y en con-sultorıa. Fue fundada por cuatro ingenieros del Kungliga Tekniska Hogskolan(KTH) en Estocolmo.

Enea Embedded Technology ofrece tres sistemas operativos OSE que seajustan a varias arquitecturas de procesadores, usando un API comun yposibilidad de comunicarse usando la tecnologıa link handler :

OSE Delta para procesadores de 32bit como CPUs PowerPC CPUs.

OSE Epsilon para procesadores de 8 - 16 bit.

OSEck para DSPs como por ejemplo TigerSHARC DSP de AnalogDevices.

El kernel de tiempo real OSE combina funcionalidad con altas presta-ciones y comportamiento en tiempo real determinıstico. Disenado para suempleo sistemas distribuidos y tolerantes a fallos, es un kernel completamen-te pre-emptivo, optimizado para proporcionar baja latencia y altas tasas de


Acronimo Nombre RefART-Linux Another Real-Time [3]KURT Kansas University Real-Time [13]Linux-SRT Linux Soft Real-Time [14]Linux/RK Linux / Resource Kernel [15]QLinux QoS enhanced Linux Kernel [20]RedHawk Linux Concurrent Computer Corporation’s version [22]RED-Linux Real-Time Embedded Linux [21]RTAI Real-Time Application Interface [24]RTLinux Real-Time Linux [26]SMART-Linux Scheduling Multimedia Applications Real-Time [30]

Cuadro 10.1: Variantes Linux para tiempo real

transferencia de datos, siendo lo suficientemente compacto para usar en lamayorıa de sistemas empotrados.

10.4. Linux de tiempo real

Existen muchas variantes de Linux para tiempo real, tal y como podemosapreciar en el cuadro 10.1.

Algunas de estas implementaciones no se siguen manteniendo activas, comoes el caso de Linux-SRT. Linux-SRT, Linux/RK y QLinux se centran enproporcionar garantıas de calidad de servicio (QoS) de ciertos recursos delsistema (uso de CPU, memoria fısica, ancho de banda de red o de disco), a de-terminadas aplicaciones. Otras como RTLinux o RTAI se basan en ejecutarLinux como una tarea de baja prioridad de un pequeno sistema operativo detiempo real. Linux no sufre ningun cambio en su ejecucion desde el punto devista del usuario o del kernel de Linux, excepto que su ejecucion solo es per-mitida cuando no hay tareas de tiempo real ejecutandose. Funcionalmente,ambas arquitecturas proporcionan la capacidad de ejecutar tareas especialesde tiempo real y manejadores de interrupciones que se ejecutan cuando seanecesario a pesar de que otras tareas pueda estar ejecutando Linux. Ambasimplementaciones extienden el entorno de programacion habitual de Linuxa tareas de tiempo real, permitiendo a las tareas de tiempo real y a los ma-nejadores de interrupciones comunicarse con procesos de Linux ordinarios atraves de interfaces de dispositivos o de memoria compartida. En el caso deRTLinux existen dos versiones: una comercial, llamada RTLinuxPro, y otragratuita de menores prestaciones, llamada RTLinuxFree.

10.5. RTAI (REAL-TIME APPLICATION INTERFACE) 171

10.5. RTAI (Real-Time Application Interfa-

ce)

El Real-Time Application Interface (RTAI) [24] es una variante deLinux para tiempo real que utiliza el concepto de una capa de abstrac-cion de hardware de tiempo real y algunas ideas basicas para deshabilitarlas interrupciones duras. Se puede utilizar tanto en uniprocesadores comoen multiprocesadores simetricos. Ha sido desarrollado por el profesor PauloMantegazza en el Departamento de Ingenierıa Aeroespacial del Politecnicode Milan [25]. Con este software es posible escribir aplicaciones para Linuxcon requisitos estrictos de temporizacion.

Entre sus usos esta la adquisicion de datos en tiempo real con tarjetas deadquisicion de datos (DAQ - Digital Acquisition Cards) empleando Come-di [6], un proyecto que desarrolla herramientas, librerıas y controladores dedispositivo para varias formas de adquisicion de datos: lectura y escritura desenales analogicas, lectura y escritura de senales digitales, medida de pulsoy frecuencia, generacion de pulsos, lectura de encoders, . . .

RTAI esta disponible para las siguientes arquitecturas:

x86 (con y sin FPU y TSC)

PowerPC

ARM (StrongARM; ARM7: clps711x-family, Cirrus Logic EP7xxx, CS89712,PXA25x)

MIPS

RTAI proporciona respuesta determinıstica a interrupciones, conforme conPOSIX y tareas nativas RTAI de tiempo real. Consiste principalmente dedos partes:

Un parche al kernel de Linux que introduce una capa de abstraccionde hardware

Una gran variedad de servicios que facilitan la programacion en tiemporeal


Las ultimas versiones de RTAI utilizan Adeos [2] para proporcionar abs-traccion adicional y disminuir las dependencias del sistema operativo par-cheado. Adeos es el acronimo de Adaptive Domain Environment forOperating Systems. Adeos es una capa de virtualizacion de recursos pro-puesta por Karim Yaghmour en el ano 2001. El proposito de Adeos esproporcionar un entorno flexible para compartir recursos de hardware en-tre multiples sistemas operativos, o entre multiples instancias de un unicosistema operativo. El uso de Adeos ademas libera a RTAI de las restriccio-nes de patente causadas por el proyecto RTLinux.

RTAI incorpora una extension llamada LXRT que permite el control detareas de tiempo real, utilizando todas las llamadas del sistema de tiemporeal de RTAI, desde espacio de usuario con memoria protegida de Linux,proporcionando tiempo real blando con planificacion de tareas de grano fino.

Existen varias series de RTAI:

v1.x, ya abandonada.

24.1.x, orientada al kernel de Linux 2.4 y cerrada.

3.x, combinacion de RTAI original y el proyecto Xenomai. Anade so-porte al kernel de Linux 2.6. Es la version que se emplea en este pro-yecto.

fusion, basada en el nucleo Xenomai. Se separa totalmente del codigoRTAI original, pero implementa una evolucion del proyecto LXRT. Esuna serie experimental.

10.6. eCos

Desarrollado como un sistema operativo de tiempo real para aplicacio-nes empotradas, Embedded Configurable Operating System (eCos) [8]corre en diferentes plataformas, entre otras en ARM, Hitachi H8300, Intelx86, MIPS y PowerPC. En mayo 2002 Red Hat puso eCos bajo una versionmodificada de la GPL. Un ano despues ya vio la luz la release 2.0.

La naturaleza altamente configurable de eCos permite caracterizar el sis-tema operativo, tanto en terminos de funcionalidad como de implementacion,a los requisitos de la aplicacion, proporcionando las mejores prestaciones de

10.6. ECOS 173

tiempo de ejecucion y una optimizacion de los recursos de hardware del sis-tema. eCos ha sido disenado para soportar aplicaciones con requisitos detiempo real, proporcionando caracterısticas como preemptibilidad comple-ta, latencia de interrupciones mınima y todas las primitivas de sincroniza-cion, polıticas de planificacion, y mecanismos de manejo de interrupcionesnecesitados por este tipo de aplicaciones. eCos tambien proporciona todala funcionalidad requerida en general para soportar aplicaciones empotra-das, incluyendo controladores de dispositivos, administracion de memoria,manejo de excepciones, C, librerıas matematicas, etc. Ademas del soporte deejecucion, el sistema eCos incluye todas las herramientas necesarias para de-sarrollar aplicaciones empotradas, incluyendo el software de configuracion deeCos, las herramientas de construccion, los compiladores basados en GNU,ensambladores, linkadores, depuradores y simuladores.

No emplearemos este sistema operativo para controlar nuestro robot por-que carece de soporte para tarjetas wireless, aunque dicho soporte esta endesarrollo en el proyecto SOWOS [31] de Software Objects Inc.

Capıtulo 11

Sistema a desarrollar

11.1. Introduccion

Como ya hemos dicho en el primer capıtulo, el proposito del presente pro-yecto es desarrollar un servidor CORBA que funcione bajo un sistema opera-tivo de tiempo real para controlar un robot Pioneer 2-AT8. Este servidor seejecuta en un ordenador empotrado a bordo del robot. El ordenador del queya dispone el robot Pioneer es una solucion basada en una placa Gene-6330(figura 11.1) de reducidas dimensiones (146 mm x 101 mm), con un proce-sador Transmeta Crusoe TM5400 a una velocidad variable entre 300 y 600Mhz para ahorrar energıa cuando no esta trabajando a pleno rendimiento.

11.2. VxWorks

La idea de partida era realizar este servidor bajo VxWorks. Inicialmentese trabajo en esta lınea haciendo los ajustes necesarios al broker ICa paraque funcionara bajo la version de VxWorks de la que disponemos en el la-boratorio. Se puso en funcionamiento una maquina de pruebas en la que seinstalo VxWorks, se compilo ICa como una librerıa estatica y se linko (en-lazo) con algunos programas incluyendo el servidor de nombres de ICa yvarios programas de pruebas.

Esta lınea fue abandonada por no disponer de soporte para tarjetas inalambri-cas en la version de VxWorks disponible en el laboratorio. La actualiza-cion a una version de VxWorks mas reciente con soporte para dispositivosinalambricos, que no es la version basica, suponıa un desembolso de dineroconsiderable. Y se busco una lınea alternativa.

175

176 CAPITULO 11. SISTEMA A DESARROLLAR

Figura 11.1: Placa Gene-6330

Caracterıstica DescripcionDimensiones 146 mm x 101.6 mm x 26 mmPeso 0.4 KgCPU Transmeta Crusoe TM5400

600 MhzMemoria 48 Mb SDRAMBIOS Award 256 Kb Flash ROMEthernet 10-100 Mbyte/sMemoria Flash para Compact Flash tipo IIPCMCIA 2 tipo II o 1 tipo IIIAlimentacion +5V y +12V tipo ATDispositivos de E/S 1 IDE (UDMA33)

1 FDD1 PS/22 RS-2321 RS-232/422/4851 Paralelo4 USB 1.1

Controlador grafico SMI LynxEM + SM712con 4Mb memoria SGRAM

Controlador audio VIA VT82C868B yVT1612A Audio CODEC

Cuadro 11.1: Caracterısticas placa Gene-6330

11.3. RTAI 177

Figura 11.2: Tarjeta Wireless Compaq WL110

Figura 11.3: Punto de Acceso Wireless Compaq WL410

11.3. RTAI

Entre las opciones analizadas se examino eCos, OSE y multiples proyec-tos de Linux para tiempo real que ya hemos comentado en el capıtulo 10.Se acabo eligiendo RTAI y su extension LXRT para proporcionar tiemporeal blando a las tareas del servidor que posteriormente se desarrollo. En eldocumento [149] podemos encontrar mas informacion sobre esta eleccion ysus posibles alternativas.

Al ser RTAI una extension de Linux, el soporte para la tarjeta wirelessCompaq WL110 11.2 de la que se disponıa no era un problema. Medianteesta tarjeta y el punto de acceso inalambrico Compaq WL410 11.3 es posibleinterconectar el ordenador de a bordo con la red local del laboratorio, con elfin de poder ejecutar las aplicaciones clientes que hagan uso del robot en losordenadores y el cluster del laboratorio.


Para poder ejecutar con garantıas de calidad de servicio el servidor quevamos a emplear para controlar el robot Pioneer 2AT-8, ejecutaremos esteservidor bajo una version modificada de Linux empleando RTAI. Para elloemplearemos:

Kernel Linux 2.6.10

Parche Adeos 2.6.10-i386-r11

RTAI 3.2

Estos componentes han sido obtenidos de las siguientes direcciones:

ftp://ftp.rediris.es/mirror/kernel/linux/kernel/v2.6/

http://download.gna.org/adeos/

http://www.aero.polimi.it/RTAI/

11.4. Servidor

Este apartado describe el servidor realizado en este proyecto para controlarel robot Pioneer 2-AT8. Este programa esta realizado en C++, empleandoCORBA y las librerıas de ActivMedia para controlar el robot. Para compilarel servidor se emplean las siguientes herramientas:

GNU make 3.80

GCC 3.3.4

Compilador IDL de ICa

Librerıas de ICa 1.0.1

Librerıas de Aria 2.4.0

RTAI 3.2

11.4.1. IDL

Para la realizacion del programa cliente, y del propio servidor, debe serconocida la interfaz que proporciona el servidor para poder realizar peticionesempleando invocaciones estaticas. El proyecto ”Sistema de Comunicacionespara Pioneer 2AT-8”[54] diseno una aplicacion cliente/servidor basada enuna interfaz IDL que ha sido modificada posteriormente para adaptarla a lasnecesidades de las aplicaciones que se desarrollan en el grupo.

11.4. SERVIDOR 179

El modulo creado tiene el nombre de Pioneer y esta estructurado en dospartes. En la primera parte de la IDL se declaran los tipos de datos y sedefinen las estructuras que guardan la informacion sensorial, de movimiento,de posicion y de estado del robot movil. Tambien se define un tipo de datopara almacenar en un vector de numeros de coma flotante la informacion delos 16 sonares de los que dispone el robot. En la segunda parte se declara lainterfaz Pioneer2AT en la que se definen los diversos metodos disponiblespara el modulo Pioneer. El modulo solo posee una interfaz, pero podrıan de-finirse tantas como fueran necesarias. Los metodos disponibles en la interfazIDL permiten:

Obtener las 4 estructuras de informacion sensorial, movimiento, posi-cion y estado del robot movil.

Conectar y desconectar el robot.

Activar y desactivar los motores.

Establecer las velocidades y aceleraciones lineal y de rotacion maximascon las que se mueve el robot.

Manipular la velocidad y la posicion del robot.

Obtener el estado de la baterıa.

Controlar el servidor CORBA.

// Pioneer 2AT Interface// Adolfo Hernando Marcos// ASLab 2005

module Pioneer

/////////////////////////////////////////////// DATA TYPES

typedef sequence<long> SonarRangeSeq;typedef sequence<boolean> SonarNewReadingSeq;

/////////////////////////////////////////////// DATA STRUCTURES

struct TimeStamplong secs;long usecs;

;

struct Pioneer2AT_State


boolean motorsEnabled; // True if motors are enabledboolean sonarsEnabled; // True if sonars are enabledboolean emergencyStop; // True if ES button pushedboolean connected; // True if connected (TCP,Serial)boolean running; // True if executingboolean moving; // True if still movingboolean leftMotorStalled; // True if motors stalledboolean rightMotorStalled;boolean leftBreakTriggered; // True if breaks triggeredboolean rightBreakTriggered;float battery; // Battery voltageboolean newReadings; // True if there are new sonar readingsTimeStamp timeStamp;

;

struct Pioneer2AT_Movement float speed; // Translation speedfloat leftSpeed; // Translation speed, left wheelfloat rightSpeed; // Translation speed, right wheelfloat rotSpeed; // Rotation speedfloat maxSpeed; // Maximum translation speedfloat maxRotSpeed; // Maximum rotation speedfloat absMaxSpeed; // Absolute maximum translation speedfloat absMaxRotSpeed; // Absolute maximum rotation speedfloat accel; // Translation accelerationfloat rotAccel; // Rotation accelerationboolean headingDone; // True if rotation movement completeboolean movementDone; // True if translation movement completeTimeStamp timeStamp;

;

struct Pioneer2AT_Position float x; // X absolute coordinatefloat y; // Y absolute coordinatefloat t; // Theta absolute coordinatefloat heading; // Heading (degrees)float distanceDiff; // Distance remaining to complete movementfloat headingDiff; // Angle remaining to complete rotationTimeStamp timeStamp;

;

struct Pioneer2AT_Sensing boolean hasSonars; // True if sonars availableboolean hasBumpers; // True if bumpers availableunsigned short numSonars; // Number of sonars availableunsigned short numFBumpers; // Number of front bumpers availableunsigned short numRBumpers; // Number of rear bumpers availableunsigned short closestSonar; // Number of closest sonarunsigned long closestRange; // Closest sonar reading

11.4. SERVIDOR 181

SonarRangeSeq SonarRanges; // List of sonar readingsSonarNewReadingSeq SonarNews; // Bools, true if sonar has new readingTimeStamp timeStamp;

;

/////////////////////////////////////////////// INTERFACE

interface Pioneer2AT

// Data exchanging methods --------------------------------------------Pioneer2AT_State getRobotState ();Pioneer2AT_Movement getRobotMovement ();Pioneer2AT_Position getRobotPosition ();

void getRobotSensing ( out Pioneer2AT_Sensing sensing );

// Robot fast state checking ------------------------------------------boolean isReady (); // True if software loaded correctlyboolean isConnected (); // True if connection established+Readyboolean isRunning (); // True if ARrobot running+Connectedboolean isStalled (); // True if some motor stalledboolean isEmergency (); // True if emergency situationboolean isMoving (); // True if completing a movementboolean isEnabled (); // True if motors enabled+Runningboolean isBreaked (); // True if any break triggeredfloat getBattery (); // Battery voltageTimeStamp getTime();void setTimeToNow();

// CORBA object remote control ----------------------------------------void init ();long connect ();void start ();void stop ();void disconnect ();void finish ();void setCycleTime ( in unsigned long ms );unsigned long getCycleTime ();unsigned long getRefreshTime ();void setRefreshTime ( in unsigned long ms );

// Movement information -----------------------------------------------float getVelocity ();float getMaxVelocity ();float getAbsMaxVelocity ();float getLeftVelocity ();float getRightVelocity ();float getAcceleration ();


float getRotVelocity ();float getMaxRotVelocity ();float getAbsMaxRotVelocity();float getRotAcceleration ();boolean isHeadingDone ();boolean isMovementDone ();float getHeading ();float getHeadingDiff ();float getDistanceDiff ();

// Movement control ---------------------------------------------------void enableMotors ( );void disableMotors ( );boolean areMotorsEnabled ( );void setVelocity ( in float vel );boolean setMaxVelocity ( in float maxVel );boolean setAbsMaxVelocity ( in float maxVel );void setLRVelocity ( in float leftVel, in float rightVel );void setAcceleration ( in float accel );void setRotVelocity ( in float rotVel );boolean setMaxRotVelocity ( in float maxRotVel );boolean setAbsMaxRotVelocity( in float maxRotVel );void setRotAcceleration ( in float rotAccel );void moveDistance ( in float distance );void setHeading ( in float heading );void setDeltaHeading ( in float delta );

// Position information -----------------------------------------------float getX ();float getY ();float getTh ();float getCompass ();

// Sensing ------------------------------------------------------------boolean hasSonars ();boolean areSonarsEnabled ();void enableSonars ();void disableSonars ();boolean hasFrontBumpers ();boolean hasRearBumpers ();unsigned short getNumSonars ();unsigned short getNumFrontBumpers ();unsigned short getNumRearBumpers ();unsigned short getClosestSonar ();unsigned long getClosestSonarRange();unsigned long getSonarRange ( in unsigned short numSonar );boolean hasSonarNewReadings ( in unsigned short numSonar );

;//INTERFACE

11.4. SERVIDOR 183

;//MODULE

Listado 11.1: Codigo interfaz IDL Pioneer2AT.idl

Con el compilador IDL de ICa se pueden generar los stubs y los skeletonscorrespondientes a este modulo. Se utiliza el stub generado para implementarel cliente; los skeleton se emplean para implementar la parte del servidor. Alhablar de CORBA en el capıtulo 6 vimos un esquema general del proceso enla figura 6.8.

11.4.2. Descripcion

El servidor realizado comienza iniciando el planificador de tiempo realde Linux, bloqueando el proceso en memoria y realizando una llamada aRTAI para usar el planificador de RTAI en vez del planificador de Linux.A continuacion inicializa el broker de tiempo real ICaORB, crea un POAy un servant al que registra en el Servidor de Nombres de CORBA queestemos empleando, para que posteriormente los clientes puedan obtener unareferencia.

La implementacion del servant dispone de funciones que permiten iniciali-zar la librerıa Aria y establecer un enlace serie a traves de un puerto serie dela placa base del ordenador empotrado con un puerto serie de conexion al mi-crocontrolador del robot. Las diversas funciones del servant realizan llamadasa la librerıa Aria para controlar el robot, empleando mutexes cuando resultanecesario para evitar que varios hilos realicen modificaciones simultaneas delos datos de control del robot.

11.4.3. Caracterısticas

El servidor realizado incorpora las siguientes caracterısticas de CORBA detiempo real:

Establece la polıtica de prioridades declaradas por el servidor.

Emplea threadpools con carriles.

Realiza llamadas para reservar bandas de prioridad, aunque estas noestan implementadas en la version de ICaORB que esta instalada enel ordenador a bordo del robot.


Merece la pena destacar que aunque la version empleada en el desarrollode este proyecto no implementa bandas de prioridad, ya existe otra versionposterior que soporta esta caracterıstica, y puesto que el software realiza lasllamadas correspondientes, podrıa aprovechar esta caracterıstica de la nuevaversion.

11.5. Simulador

Con el fin de realizar pruebas, depurar y experimentar sin usar el robotreal se puede usar un simulador, como el simulador MobileSim, realizandouna conexion TCP en vez de una conexion serie. Esta basado en el simuladorStage, y puede simular la mayorıa de los robots tipo Pioneer u otros robots,en dos dimensiones con todos los comandos de movimiento y de los sensoresde sonar. Podemos ver una imagen de este simulador en la figura 11.4.

11.6. Cliente

La aplicacion cliente permite controlar el robot desde un ordenador remo-to, ası como obtener su estado. En este caso se emplea tambien ICa comobroker CORBA y C++ como lenguaje de programacion, aunque se puedeutilizar otro broker y/o lenguaje de programacion. Las librerıas Qt permitenimplementar la interfaz grafica.

11.6.1. IDL

Para poder realizar llamadas a los procedimientos implementados en elservidor empleando invocaciones estaticas necesitamos conocer la interfazIDL que ya se ha visto en el apartado 11.4.1, con la que se ha creado elservidor al que nos conectamos.

11.6.2. Librerıa Qt

La librerıa Qt es una herramienta de desarrollo para facilitar la creacionde interfaces graficas de usuario. Una interfaz grafica de usuario (GUI) esun metodo para facilitar la interaccion del usuario con el ordenador a travesde la utilizacion de imagenes y objetos (cursores, iconos, ventanas, botones,. . . ) ademas de texto. Es una evolucion de la lınea de comando de los prime-ros sistemas operativos que representa la pieza fundamental de un entornografico.

11.6. CLIENTE 185

Figura 11.4: Simulador de robots MobileSim


Esta librerıa fue desarrollada por Trolltech [33] en 1992, siendo un desarro-llo basado en el codigo, pero no libre. Se uso activamente en el desarrollo delescritorio KDE (a partir de 1996), con un notable exito y rapida expansion.Esto fomento el uso de Qt en programas comerciales para el escritorio.

Esta situacion fue vista por el proyecto GNU como una amenaza para elsoftware libre, al igual que anteriormente lo fue la librerıa OSF/Motif, por loque se plantearon dos iniciativas: Por un lado el equipo GNU inicio en 1997el desarrollo del escritorio GNOME (con GTK+) para GNU/Linux. Por otrolado se intenta construir una biblioteca compatible con Qt, pero totalmentelibre, llamada Harmony.

En la actualidad Qt cuenta con un sistema de doble licencia: por un ladodispone de una licencia GPL para el desarrollo de software abierto (opensource) y software libre gratuito y por otro lado una licencia de pago para eldesarrollo de aplicaciones comerciales.

La librerıa Qt permite el desarrollo de aplicaciones GUI en multiples pla-taformas. Empleando un unico codigo fuente y con una simple recompilacionse pueden escribir aplicaciones para Windows 95 a XP, Mac OS X, Linux,Solaris, HP-UX, AIX, IRIX, FreeBSD y OpenBSD. Qt tiene soporte paragraficos en 2D y 3D, internacionalizacion, XML, bases de datos, . . . La li-brerıa Qt esta descrita en profundidad en [133].

Designer

Como ayuda para la realizacion de una interfaz grafica empleando Qt seutiliza la herramienta “Designer” que podemos ver en la figura 11.5.

Designer permite la creacion de dialogos interactivos con distintos objetos(barras, displays, botones, leds, . . . ). Se definen las propiedades de cada ele-mento tales como el nombre, tamano, tipo de letra, etc. Cada elemento llevaasociada una clase en la aplicacion que estamos disenando. Posteriormente,en conformidad con el modelo de programacion por eventos habitual en laprogramacion de interfaces graficas, es necesario implementar la funciona-lidad mediante codigo que se debe ejecutar cuando se reciben los eventoscorrespondientes.

El resultado de este proceso es un archivo con extension “.ui”. Utilizan-do el compilador ui generamos la descripcion de la clase (un fichero “.h”),

11.6. CLIENTE 187

Figura 11.5: Herramienta Qt Designer


ası como su implementacion (un fichero “.cpp”). Como Qt emplea las pa-labras clase “SLOT” y “SIGNAL” que carecen de significado en C++, esnecesario utilizar el compilador de objetos de Qt MOC (Meta Object Compi-ler) que genera codigo adicional en C++ correspondiente a los mecanismos“SLOT-SIGNAL”.

Para implementar la funcionalidad caracterıstica de cada elemento de lainterfaz grafica disenada se crea una clase que hereda de la clase generada enla implementacion del interfaz, definiendo en esta clase los metodos virtualesde la clase base.

Una vez implementada la funcionalidad es necesario compilar de nuevocon MOC la descripcion de la clase (fichero “.h”), puesto que aparecen denuevo mecanismos de tipo “SLOT-SIGNAL”, para que el compilador de C++pueda entender dichos ficheros.

Por ultimo, en la aplicacion principal hace falta instanciar la clase derivadaen un entorno de aplicacion (QApplication) de Qt.

11.6.3. Descripcion

La aplicacion cliente comienza inicializando el broker CORBA. Utilizandoun servidor de nombres obtiene una referencia al servant del servidor parapoder llamar a los metodos de su implementacion. El programa muestra unainterfaz grafica y obtiene periodicamente la informacion del estado del robot,actualizando la interfaz grafica con esta informacion. Podemos apreciar elaspecto de la aplicacion en la figura 11.6.

La interfaz grafica muestra el estado de los 16 sonares del robot, ası comola informacion de la posicion y velocidad del mismo. Varios indicadores ledde colores muestran el estado de la conexion serie entre el ordenador a bordodel robot y el microcontrolador Hitachi H8S. Otro indicador led muestra elestado de las baterıas, variando de color entre el verde y el rojo en el intervalode 12.5V a 11.5V. Un pulsador (control de tipo button) permite conectar ydesconectar este enlace. Es posible regular la velocidad lineal y de rotaciondel robot mediante las flechas del cursor o mediante controles de tipo dial yslider, ası como conectar y desconectar los motores y los sonares mediantecontroles de tipo button.

11.6. CLIENTE 189

Figura 11.6: Programa cliente para Higgs

Parte V

Apendices

191

Apendice A

Glosario de terminos yacronimos

A.1. A

ASi : Actuator-Sensor interface. Bus de campo tambien conocido como SinecS1 o SiriusNet. Recogido en las especificaciones EN 50295, IEC 62026/2.

A.2. B

A.3. C

CAN : Controller Area Network. Es un estandar de bus serie comparti-do multicast, desarrollado inicialmente por Robert Bosch GmbH paraconectar Unidades de Control Electronico (ECUs). CAN fue especıfica-mente disenado para ser robusto en entornos ruidosos y puede utilizarlıneas de balance diferencial como RS-485. Puede llegar a ser mas robus-to contra el ruido empleando cable twisted pair. Aunque inicialmentefue creada para propositos automovilısticos (como el bus de un vehıcu-lo), hoy en dıa se puede encontrar en muchas aplicaciones de controlempotrado (e.g. industrial) que puedan estar sujetas a ruidos. Reco-gido en las especificaciones EN 50325/4 (CAN/Open protocol), ISO11898/1 (Datalink), ISO 11898/4 (Time-triggered CAN), ISO 16845(CAN Conformance Testing).

193

194 APENDICE A. GLOSARIO DE TERMINOS Y ACRONIMOS

Se pueden alcanzar velocidades de transferencia de 1 Mbit/s en redescon longitudes de hasta 40 m. Reduciendo la tasa de transferencia sepueden alcanzar longitudes mayores (e.g. 250 kbit/s a 250 m).

La capa de enlace de datos del protocolo CAN esta estandarizada enISO-11898-1(2003).

ControlNET : Capa de control de red en tiempo real que proporciona trans-porte de alta velocidad (5 Mbits/s) de mensajes y datos de E/S detiempo crıtico incluyendo carga/descarga de programas, datos de con-figuracion y mensajes entre nodos en un unico medio fısico. Recogidoen las especificaciones DD 241, EN 50170/A3, IEC 61158 Type 2

CORBA : Common Object Request Broker Arquitecture. Es una especifica-cion que se basa en la interoperabilidad de aplicaciones independiente-mente de la plataforma, sistema operativo, lenguaje de programacion yprotocolos de comunicacion. Contiene una serie de especificaciones par-ticulares, incluyendo el lenguaje IDL, protocolos de red como GIOP eIIOP, infraestructura para el desarrollo de servidores escalables y por-tables (POA), y el modelo de componentes CORBA (CCM). Permitela interoperacion de aplicaciones heterogeneas escritas en diversos len-guajes que se ejecutan en varias plataformas.

CPU : Se denomina Central Processing Unit (CPU) o Unidad Central deProceso (UCP) a la unidad donde se ejecutan las instrucciones de losprogramas y se controla el funcionamiento de los distintos componentesdel ordenador. Suele estar integrada en un chip denominado micropro-cesador.

Es el corazon de todo computador, y es un microchip o micropro-cesador con una alta escala de integracion que permite que millonesde transistores esten en su interior. Todos estos millones de transis-tores forman una serie de circuitos logicos que permite ejecutar unadeterminada variedad de instrucciones basicas.

Cada fabricante de microprocesadores tendra sus propias familiasde estos, y cada familia su propio conjunto de instrucciones. De hecho,cada modelo concreto tendra su propio conjunto, ya que en cada modelose tiende a aumentar el conjunto de las instrucciones que tuviera elmodelo anterior.

A.4. D 195

El microprocesador secciona en varias fases de ejecucion la realizacionde cada instruccion:

Fetch, lectura de la instruccion desde la memoria principal,

Descodificacion de la instruccion, es decir, determinar que instruc-cion es y por tanto que se debe hacer,

Fetch, lectura de los datos necesarios para la realizacion de laoperacion,

Ejecucion,

Escritura de los resultados en la memoria principal,

Estas fases se realizan en un ciclo de CPU. La duracion fısica de estosciclos viene determinada por la frecuencia de reloj. El microprocesadordispone de un oscilador de cuarzo capaz de generar pulsos a un ritmoconstante, de modo que genera varios ciclos (o pulsos) en un segundo.

A.4. D

DCE : Distributed Computing Environment (UNIX). Conjunto de serviciose interfaces desarrollados por la OSF, que definen la tecnologıa basepara que los fabricantes soporten la interoperabilidad de aplicacionesen entornos heterogeneos.

DeviceNET : Bus de campo tambien conocido como Compobus/D. Esta re-cogido en las especificaciones EN 50325/2, IEC 62026/3, SEMI E54.4

A.5. E

A.6. F

FieldBUS : FieldBUS es un sistema de red industrial para control distri-buido en tiempo real. Un sistema industrial automatizado complejo -como una lınea de ensamblaje de un a fabrica - necesita usualmentepara funcionar una jerarquıa organizada de sistemas controladores. Enla cima de esta jerarquıa existe usualmente un computador central des-de el que un operador puede monitorizar o programar todo el sistema.


Este esta tıpicamente conectado a una capa intermedia de Controla-dores Logicos Programables (PLCs) a traves de un bus del sistema(e.g. Ethernet). Al final de la cadena esta el bus de campo, que enla-za los PLCs con los componentes que realmente hacen el trabajo yasean sensores, actuadores, motores, luces de una consola, interruptoreso contactores.

ASiCANDeviceNetFOUNDATION fieldbusHARTIndustrial EthernetLonWorksmodbusNetbusProfibus

Cuadro A.1: Buses de campo.

FOUNDATION fieldbus : Sistema de comunicaciones todo-digital, seriey bidireccional que funciona como red de nivel basico en el entorno deautomatizacion de una planta o una factorıa.

Existen dos implementaciones relacionadas de FOUNDATION field-bus que han sido desarrolladas para satisfacer diferentes necesidades deautomatizacion de procesos. Estas implementaciones emplean mediosfısicos y velocidades de comunicacion distintas:

H1 funciona a 31.25 Kbit/s y conecta generalmente con dispo-sitivos de campo. Proporciona comunicaciones y alimentacion atraves de un cableado estandar twisted-pair. H1 es hoy en dıa laimplementacion mas comun.

HSE (High-speed Ethernet) funciona a 100 Mbit/s y habitual-mente conecta subsistemas de entradas y salidas, servidores, dis-positivos de enlace, gateways y dispositivos de campo empleandocableado estandar Ethernet. Actualmente no proporciona alimen-tacion a traves del cable, aunque hay trabajos en desarrollo paralograr este proposito.

A.7. G 197

A.7. G

Gateway : Dispositivo de interconexion de redes que soporta la pila com-pleta del protocolo en cuestion y puede convertir a un protocolo nodividido en 7 capas para transferencias asıncronas a traves de WideArea Networks (WAN).

Giroscopo : Un giroscopo es un dispositivo para medir o mantener la orien-tacion, basandose el principio de conservacion del momento angular.En fısica esto se conoce como inercia giroscopica.

La esencia del dispositivo es una masa con forma de rueda girandoalrededor de un eje. A su vez esta montado sobre un sistema que permiteque el eje pueda tomar cualquier orientacion. Una vez que esta girandotiende a resistirse a los cambios en la orientacion del eje de rotacion.El giroscopo fue inventado para un experimento relacionado con larotacion de la Tierra por Leon Foucault en 1852 que le dio el nombre.Sin embargo, ejemplos del fundamento del giroscopio pueden observarsea diario, como es el caso de las carreras de motos: El motorista solonecesita inclinarse para poder girar al tomar una curva.

Un giroscopo muestra diversos comportamientos que incluyen la pre-cesion y la nutacion. El efecto giroscopico puede utilizarse entre otrascosas, para construir una girobrujula que complementa o substituyela brujula magnetica (en barcos, aviones, naves espaciales y vehıculosen general), para ayudar a la estabilidad (bicicleta, telescopio espacialHubble, barcos, vehıculos en general) o ser usado como parte de un sis-tema de guıa inercial. Los efectos giroscopicos son usados en juguetescomo el yo-yo, la peonza o el dynabee. Muchos otros dispositivos rota-tivos como el volante de inercia se comportan como giroscopos aunqueel efecto giroscopico no se use.

La ecuacion fundamental que describe el comportamiento del girosco-po es:

~τ =d~L

dt=

d(I~ω)

dt= I~α (A.1)

donde:


el vector τ es el momento sobre el centro de masa del giroscopio

el vector L es su momento angular o cinetico

el vector ω es la velocidad angular

el vector α es la aceleracion angular

el escalar I es su momento de inercia

De aquı se deduce por las propiedades del producto vectorial queun momento τ aplicado perpendicularmemente al eje de rotacion, ypor tanto perpendicular a L, resulta en un movimiento perpendiculara ambos τ y L. Este movimiento se denomina precesion. La velocidadangular de precesion ΩP viene dada por:

~τ = ~ΩP ∧ ~L (A.2)

La precesion puede observarse colocando un giroscopo girando consu eje horizontalmente y apoyado por uno de sus extremos. En lugarde caerse como podrıa esperarse el giroscopo aparentemente desafıa lagravedad manteniendose con su eje horizontal, incluso teniendo uno delos extremos del eje sin apoyo. El extremo libre del eje describe lenta-mente un cırculo en un plano horizontal. Este efecto es explicado porlas ecuaciones anteriores. El momento que actua sobre el giroscopo pro-viene de un par de fuerzas: la gravedad actuando hacia abajo sobre elcentro de masa, y otra fuerza de igual magnitud actuando hacia arribapara soportar el peso total en uno de los extremos del artilugio. El mo-vimiento resultante de este momento no es hacia abajo como de formaintuitiva podrıa esperarse, provocando que se cayese del soporte, sinoperpendicular a ambos, tanto al momento gravitatorio (hacia abajo)como al momento cinetico sobre el eje de rotacion (hacia afuera desdeel punto de soporte), esto es, en direccion horizontal, causando que eldispositivo rote lentamente alrededor del punto de apoyo.

Como muestra la segunda ecuacion, bajo la accion de un momentoconstante debido a la gravedad, la velocidad de precesion del girosco-po es inversamente proporcional a su momento angular. Esto significaque como la friccion hace que el giroscopo pierda velocidad angular, lavelocidad de precesion se incrementa, y sigue haciendolo hasta que sevuelve inestable y ya es incapaz de girar suficientemente rapido paramantener su propio peso cuando para de preceder y se cae del soporte.

A.8. H 199

GPS : El Global Positioning System (GPS) o Sistema de Posicionamien-to Global originalmente llamado NAVSTAR, es un Sistema Global deNavegacion por Satelite (GNSS) el cual permite determinar en todo elmundo la posicion de una persona, un vehıculo o una nave, con unadesviacion de cuatro metros. El sistema fue desarrollado e instalado, yactualmente es operado, por el Departamento de Defensa de los EstadosUnidos.

El GPS funciona mediante una red de satelites que se encuentranorbitando alrededor de la tierra. Cuando se desea determinar la posi-cion, el aparato que se utiliza para ello localiza automaticamente comomınimo cuatro satelites de la red, de los que recibe unas senales in-dicando la posicion y el reloj de cada uno de ellos. En base a estassenales, el aparato sincroniza el reloj del GPS y calcula el retraso delas senales, es decir, la distancia al satelite. Por “triangulacion” calculala posicion en que este se encuentra. La triangulacion consiste en ave-riguar el angulo de cada una de las tres senales respecto al punto demedicion. Conocidos los tres angulos se determina facilmente la propiaposicion relativa respecto a los tres satelites. Conociendo ademas lascoordenadas o posicion de cada uno de ellos por la senal que emiten,se obtiene la posicion absoluta o coordenadas reales del punto de medi-cion. Tambien se consigue una exactitud extrema en el reloj del GPS,similar a la de los relojes atomicos que desde tierra sincronizan a lossatelites.

La antigua Union Sovietica tenıa un sistema similar llamado GLO-NASS, ahora gestionado por la Federacion Rusa. Actualmente la UnionEuropea intenta lanzar su propio sistema de posicionamiento por sateli-te, denominado ’Galileo’.

A.8. H

HART : Highway Addressable Remote Transducer. Es un bus de campo.

HMI : Human-Machine Interface o Interfaz de Usuario es el conjunto demedios mediante los cuales los usuarios interaccionan con una maqui-na, dispositivo, programa informatico u otra herramienta compleja. Elinterfaz de usuario proporciona medios para:


Entrada, permitiendo a los usuarios el control del sistema

Salida, permitiendo al sistema informar a los usuarios

HTML : Acronimo ingles de Hypertext Markup Language (lenguaje de mar-cacion de hipertexto), es un lenguaje de marcas disenado para estruc-turar textos y presentarlos en forma de hipertexto, que es el formatoestandar de las paginas web. Gracias a Internet y a los navegadores deltipo Explorer o Netscape, el HTML se ha convertido en uno de los for-matos mas populares que existen para la construccion de documentos.

HTML se basa en SGML, aunque hay unas versiones de XHTMLque son descendientes de XML y exigen que se escriba mucho maspara facilitar la vida a los navegadores, que son los programas que nosmuestran informacion en pantalla.

A.9. I

IED : Integrated Electronic Device o Dispositivo Electronico Integrado

Industrial Ethernet : Es el nombre que se da a un protocolo Ethernetempleado en un entorno industrial para automatizacion y control demaquinaria de produccion.

Hasta hace poco, un PLC se comunicaba con una maquina auxiliarempleando una de los diversos protocolos abiertos o propietarios talescomo Modbus, Profibus, DeviceNet o Foundation fieldbus. Existe uncreciente interes en el uso de Ethernet como protocolo de la capa deenlace con alguno de los anteriores protocolos en la capa de aplicacion.

Entre las ventajas de usar Ethernet industrial figuran:

Incremento de velocidad desde 9.6 kbit/s con RS232 hasta 100Mbit/s.

Incremento de las prestaciones generales.

Mejora la interoperabilidad.

Posibilidad de emplear hubs, switches y cables de uso comun, masbaratos que los equivalentes dispositivos para puertos serie.

A.10. J 201

Aumento de la distancia.

Posibilidad de tener mas de dos nodos en el enlace, que ya eraposible con RS485, pero no lo era con RS232. Arquitecturas denodo a nodo reemplazan a arquitecturas de maestro a auxiliar.

Las dificultades de usar Ethernet industrial son:

Migrar sistemas existentes a un nuevo protocolo (Naturalmenteexisten muchos adaptadores disponibles).

Administrar una pila TCP/IP completa es mas complejo que re-cibir datos en serie.

Version serie Version EthernetModbus-RTU Modbus-TCPProfibus Profinet-IODeviceNet Ethernet/IPFoundation Fieldbus H1 Foundation Fieldbus HSE

(High Speed Ethernet)

Cuadro A.2: Protocolos Ethernet de uso industrial mas habituales.

Interbus : Interbus-S, recogido en las normas DIN 19-258, EN 50254/1 eIEC 61158 Type 8, junto con Interbus-C (Bitbus) e Interbus-P (Pro-fibus) son nombres de productos suministrados por Phoenix Contact.Los dos ultimos ya no estan disponibles en venta.

A.10. J

jitter : El periodo del jitter se refiere a las variaciones en el tiempo queexperimenta una tarea cuando se ejecutade manera repetitiva. Podemosver una representacion grafica en la figura A.1.


Figura A.1: Representacion del periodo del jitter

A.11. K

A.12. L

LED : Light-Emitting Diode o Diodo Emisor de Luz. Es un dispositivo semi-conductor que emite luz monocromatica cuando se polariza en directay es atravesado por la corriente electrica. El color depende del materialsemiconductor empleado en la construccion del diodo pudiendo variardesde el ultravioleta, pasando por el espectro de luz visible, hasta elinfrarrojo, recibiendo estos ultimos la denominacion de diodos IRED (Infra-Red Emitting Diode ).

Figura A.2: Representacion simbolica del diodo pn

El dispositivo semiconductor esta comunmente encapsulado en unacubierta de plastico de mayor resistencia que las de cristal que usual-mente se emplean en las bombillas. Aunque el plastico puede estar

A.12. L 203

coloreado, es solo por razones esteticas, ya que ello no influye en elcolor de la luz emitida.

Figura A.3: Diodos verde, amarillo y rojo

Debe escogerse bien la corriente que atraviesa el LED para obteneruna buena intensidad luminosa; el voltaje de operacion va desde 1,5a 2,2 voltios aproximadamente y la gama de intensidades que debecircular por el va de 10 a 20 mA en los diodos de color rojo y de entre20 y 40 mA para los otros LEDs.

El primer diodo LED que emitıa en el espectro visible fue desarrolladopor el ingeniero de General Electric Nick Holonyak en 1962.

Compuesto Color Frec.Arseniuro de galio (GaAs) Infrarrojo 940nmArseniuro de galio y aluminio (AlGaAs) Rojo e infrarrojo 890nmArseniuro fosfuro de galio (GaAsP) Rojo, naranja y amarillo 630nmFosfuro de galio (GaP) Verde 555nmNitruro de galio (GaN) Verde 525nmSeleniuro de zinc (ZnSe) AzulNitruro de galio e indio (InGaN) Azul 450nmCarburo de silicio (SiC) Azul 480nmDiamante (C) UltravioletaSilicio (Si) En desarrollo

Cuadro A.3: Compuestos empleados en la construccion de diodos LED.


LonWorks : Plataforma de red creada para solucionar las necesidades deprestaciones, fiabilidad, instalacion y mantenimiento necesarias en apli-caciones de control. Esta construida sobre un protocolo de bajo anchode banda creado por Echelon Corporation para dispositivos en red em-pleando twisted pair, lıneas electricas, fibra optica y RF.

A.13. M

Matlab : Matlab es la abreviatura de Matrix Laboratory (laboratorio dematrices). Es un programa de matematicas creado por The MathWorksen 1984. Esta disponible para las plataformas Unix, Windows y MAC.

Se pueden ampliar sus capacidades con Toolboxes, algunas de ellasestan destinadas al procesado digital de senal, adquisicion de datos,economıa, inteligencia artificial, logica difusa, . . . Tambien cuenta conotras herramientas como Simulink, que sirve para simular sistemas.

Usa un lenguaje de programacion creado en 1970 para proporcionarun sencillo acceso al software de matrices LINPACK y EISPACK sintener que usar Fortran. Tambien tiene su propio compilador.

Es un software muy usado en universidades, centros de investigaciony por ingenieros. En los ultimos anos ha incluido muchas mas capa-cidades, como la de programar directamente procesadores digitales desenal, crear codigo VHDL y otras.

Middleware : En computacion el middleware consiste en agentes de softwa-re que actuan como intermediarios entre los diferentes componentes deuna aplicacion. Su uso mas frecuente es soportar aplicaciones comple-jas distribuidas. Los agentes de software involucrados pueden ser unoo muchos.

Modbus : Protocolo de comunicaciones disenado por Modicon para su em-pleo con PLCs. Es el medio mas comun para la conexion de dispo-sitivos electronicos industriales. La razon principal de su extenso usosobre otros protocolos de comunicaciones es el echo de que este publi-cado abiertamente. Modbus permite la administracion de una red dedispositivos, por ejemplo, un sistema para medir la temperatura y lahumedad y comunica los resultados a un ordenador. Modbus se emplea

A.13. M 205

con frecuencia para conectar un ordenador supervisor con una UnidadTerminal Remota (RTU) en control supervisado y Sistemas de Adqui-sicion de Datos (SCADA). Recogido en SEMI E54.9 (Modbus/TCP)

MPEG : Moving Picture Experts Group o Grupo de expertos en imagenesen movimiento. En sus orıgenes, el MPEG era, un pequeno grupo en-cargado del desarrollo de normas de codificacion para audio y vıdeo,formado en el Comite Tecnico para la Tecnologıa de la InformacionISO/IEC JTC 1, de la ISO.

Desde su primera reunion en 1988, el MPEG ha crecido hasta incluir350 miembros de distintas industrias y universidades. La designacionoficial del MPEG es ISO/IEC JTC1/SC29 WG11.

MPEG ha normalizado los siguientes formatos de compresion y nor-mas auxiliares:

MPEG-1: especificacion inicial de compresion de audio y vıdeo.Usado despues como la norma para CD de vıdeo, incluye el popularformato de compresion de audio Capa 3 (MP3).

MPEG-2: normas para audio y vıdeo para difusion de calidadde television. Utilizado para servicios de TV por satelite comoDirect TV (Cadena estadounidense de television vıa satelite dedifusion directa), senales de television digital por cable y (conligeras modificaciones) para los discos de vıdeo DVD.

MPEG-3: disenado originalmente para HDTV (Television de AltaDefinicion), pero abandonado posteriormente en favor de MPEG-2.

MPEG-4: expande MPEG-1 para soportar “objetos” audio/vıdeo,contenido 3D, codificacion de baja velocidad binaria y soportepara gestion de derechos digitales (proteccion de copyright).

MPEG-7: sistema formal para la descripcion de contenido multi-media

MPEG-21: MPEG describe esta norma futura como un “marcomultimedia”.

Multi-cast : Mensaje puesto en una red de comunicaciones dirigido a unconjunto limitado de destinatarios. Un mensaje Multi-cast contienetıpicamente la direccion de origen y un campo de direcion que con-tiene un conjunto limitado de direcciones de destinatarios.


A.14. N

Netbus : Bus de campo.

NTP : Network Time Protocol es un protocolo que se emplea para sincro-nizar los relojes de sistemas informaticos a traves de redes de paquetesconmutados de latencia variable. NTP emplea el puerto UDP 123 comocapa de transporte. Ha sido disenado especıficamente para resistir losefectos de la latencia variable.

A.15. N

A.16. O

Objeto : Es una combinacion de estados y de metodos que encapsula explıci-tamente una abstraccion caracterizada por su comportamiento o la im-portancia de sus peticiones. Un objeto es na instancia de una clase.Un objeto representa una entidad del mundo real y es implementadocomo una entidad computacional que encapsula estado y operaciones(internamente implementados como datos y metodos) y responde asolicitudes de servicio. Un objeto es un paquete de software autocon-tenido formado por su propia informacion privada (datos), sus propiosprocedimientos privados (metodos privados), que manipulan los datosprivados del objeto, y una interfaz publica (metodos publicos) paracomunicarse con otros objetos.

ORB : El Object Request Broker proporciona los medios mediante los cualeslos objetos hacen peticiones y reciben respuestas. Es el middleware deun sistema informatico de objetos distribuidos que proporciona a losobjetos medios para localizar y activar otros objetos en una red, conindependencia del procesador o del lenguaje de programacion empleadopara desarrollar e implementar dichos objetos.

OLE : Object Linking and Embedding (OLE) es un protocolo y un sistemade objetos distribuidos desarrollado por Microsoft. Fue desarrollado ini-cialmente para permitir copiar y pegar datos entre distintas aplicacio-nes, especialmente usando arrastrar y soltar, ası como para estructurardocumentos compuestos. Evoluciono posteriormente hasta una arqui-tectura de componentes de software conocida como Component ObjectModel (COM)

A.17. P 207

OS : Operating System, vease Sistema Operativo.

A.17. P

PID : Un controlador Proportional-integral-Derivativo o PID es un compo-nente estandar del lazo de regeneracion de una aplicacion de controlindustrial. Mide la salida de un proceso y controla su entrada con el finde mantener la salida en un valor objetivo que se llama “setpoint”. Unejemplo de aplicacion PID es el control de la temperatura de un proceso,aunque puede ser utilizado para controlar cualquier variable mensura-ble que pueda ser modificada manipulando otra variable del proceso. Sepuede usar para controlar presion, caudal, composicion quımica, fuerza,velocidad, . . . El control de crucero de un automovil es otro ejemplo deaplicacion en un area distinta de los procesos industriales.

La idea basica es que el controlador lee un sensor. Entonces resta la“medida” del “valor objetivo” para determinar el “error”. El error estratado de tres maneras diferentes simultaneamente:

Proporcional: Para manejar el presente, el error es multiplicadopor una constante proporcional negativa P y enviado a la salida.P representa la banda sobre la que la salida del controlador es pro-porcional al error del sistema. Por ejemplo, para un calentador, uncontrolador con una banda proporcional de 10oC y un valor obje-tivo de 20oC tendrıa un valor de salida del 100% a 10oC, 50% a15oC y 10% a 10oC. Anadir el cambio a la salida hace que esta seauto-regule, por ejemplo, si el calentador tuviera suciedad, redu-ciendo su eficiencia, la salida aumentarıa un poco, para despuesreestabilizarse.

Integral: Para manejar el pasado, el error es integrado (o prome-diado o sumado) a lo largo de un periodo de tiempo, y despueses multiplicado por la constante I y anadido a la salida propor-cional. I represente el error del sistema en un estado estacionario.Empleando unicamente el termino proporcional no es posible al-canzar una temperatura objetivo uniforme. Los procesos del mun-do real no son perfectos y estan sujetos a un numero de variablesambientales. Como frecuentemente estas variables son constantes,se pueden medir y compensar. Usando el ejemplo proporcional


anterior: a 19.9oC la salida del controlador es del 1%, a esta tem-peratura ambiental, las perdidas por transmision de calor son del3%. En este escenario, el sistema controlador nunca sera capaz dealcanzar la temperatura objetivo, naturalmente se puede corregirintroduciendo un termino integral, que intentara corregir los erro-res que se produjeron a lo largo de un intervalo de tiempo. En lapractica, el termino integral del controlador solo puede considerarun intervalo de tiempo relativamente corto.

Derivativo: Para manejar el futuro. Se calcula la primera derivadadel error con respecto al tiempo, y se multiplica por otra constanteD y se suma con los terminos proporcional e integral. El terminoderivativo es usado para gobernar la respuesta del controlador a uncambio en el sistema. Cuanto mas grande es el termino derivativo,mas rapidamente responde el controlador a cambios en el valordel proceso. Reduciendo, en cambio, este termino, reducimos larespuesta del controlador frente a cambios transitorios.

La funcion de transferencia generica para un controlador PID es:

H(s) =Ds2 + Ps + I

s + C(A.3)

Siendo C una constante (tıpicamente 0.01 o 0.001)

PLC : Un Programmable Logic Controller o Controlador Logico Programa-ble es un pequeno ordenador que se emplea para automatizacion deprocesos tales como el control de la maquinaria de las lıneas de ensam-blaje de una factorıa

POA : Un Portable Object Adapter o Adaptador de Objetos Protable es elmedio principal para que la implementacion de un objeto acceda a losservicios del ORB, tales como la generacion de referencias a objetos. UnAdaptador de Objetos exporta la interfaz publica a la implementaciondel objeto y la interfaz privada al skeleton. Esta construido a partir deuna interfaz privada dependiente del ORB. El Portable Object Adapter(POA) ofrece la funcionalidad suficiente para permitir la construccionde servidores portables.

POSIX : Nombre colectivo de la familia de especificaciones de la IEEEpara definir una Interfaz de Programacion de Aplicaciones (API) parasoftware disenado para ejecutarse en variantes del Sistema Operativo

A.17. P 209

UNIX. Son designadas formalmente como IEEE 1003 y el nombre dela especificacion internacional es ISO/IEC 9945. Esta especificacionsurgio a partir de un proyecto comenzado alrededor de 1985. El nombrePOSIX fue sugerido por Richard Stallman y es el acronimo de PortableOperating System Interface, con la X significando la herencia UNIX delAPI.

POSIX especifica los interfaces del usuario y del software para elSO en alrededor de 15 documentos diferentes. La lınea de comandosestandar y la interfaz de Scripting es el Korn Shell. Otros programas deusuario, servicios y utilidades incluyen awk, echo, ed y cientos mas. Losservicios de programacion requeridos incluyen E/S basicas (ficheros,terminal y servicios de red). POSIX tambien define una API para laslibrerıas de threading, la cual es muy popular y es usada en muchosSistemas Operativos.

Una serie de pruebas acompanan al estandar POSIX. Son llamadasPCTS y significa POSIX Conformance Test Suite.

Desde que la IEEE ha empezado a cobrar altos precios por la do-cumentacion de POSIX, no admitiendo ademas la publicacion en lıneade los estandares, ha existido una tendencia hacia el uso del modeloSingle UNIX Specification, el cual es abierto, acepta entradas de todoel mundo, y esta libremente disponible en internet. Ha sido creado porThe Open Group

Aunque es usado principalmente por sistemas UNIX, el estandar PO-SIX se puede aplicar a cualquier Sistema Operativo. Por ejemplo, lafamilia Microsoft Windows NT cumple con la parte de tiempo real dela especificacion POSIX. Windows tambien se puede mejorar para queincluya mayor compatibilidad instalando Windows Services for UNIXo Cygwin.

Para Sistemas Operativos basados en Linux, Linux Standard Baseproporciona varias extensiones comunes y estandares complementariosde hecho. Es improbable que sean seguidos por otros sistemas tipoUNIX que se adhieren a especificaciones establecidas con el tiempo,excepto en los casos en los que el Linux Standard Base ya se adhiere adichas especificaciones


Profibus : Process Field Bus es el tipo de bus de campo (fieldbus) mas popu-lar, con mas de 13 millones de nodos en uso. Profibus fue desarrolladopor Siemens en Alemania. La version Ethernet de Profibus se llamaProfinet. Especificaciones DIN 19-245, EN 13321-1 (Profibus/FMS),EN 50170/2, EN 50254/2, IEC 61158 Type 3.

Profibus DP : Profibus for Decentralized Periphericals. Es la especificacionde un bus de campo abierto recogida en IEC 61158 e IEC 61784, SEMIE54.8.

Profibus PA : Profibus for Process Automation. Es un perfil de aplicacionesbasado en Profibus DP e independiente del medio fısico (RS485, fibraoptica, MBP)

PWM : Pulse-Width Modulation o Modulacion por Anchura de Pulsos.

A.18. Q

QoS : La Quality of Service o Calidad de Servicio garantiza que se transmi-tira cierta cantidad de datos en un tiempo dado (throughput). Una delas grandes ventajas de sistemas de comunicaciones ATM (Asynchro-nous Transfer Mode — Modo de Transferencia Asıncrona) respecto detecnicas como el Frame Relay y Fast Ethernet, es que soporta nivelesde QoS. Esto permite que los proveedores de servicios ATM garanticena sus clientes que la latencia de extremo a extremo no excedera un nivelespecifico de tiempo.

A.19. R

RPC : Remote Procedure Call. Conjunto de herramientas software desarro-lladas por un consorcio de fabricantes y disenadas para asistir a losdisenadores en la creacion de aplicaciones distribuidas.

A.20. S

SCADA : Los Sistemas de Control de Supervision y Adquisicion de Datos(Supervisory Control and Data Acquisition) son sistemas utilizados en

A.20. S 211

aplicaciones industriales y de ingenierıa para monitorizar y controlarsistemas distribuidos desde una localizacion maestra.

Los tres componentes de un sistema SCADA son:

Multiples RTUs (Remote Terminal Units) de campo.

Habitacion de control central con ordenadores servidores.

Infraestructura de comunicaciones.

Seriplex : Recogido en las especificaciones IEC 62026/6, SEMI E54.7.

Sistema Operativo : Conjunto de programas o software destinado a per-mitir la comunicacion del usuario con el ordenador y gestionar sus re-cursos de manera comoda y eficiente. Comienza a trabajar cuando searranca el ordenador, y gestiona el hardware de la maquina desde losniveles mas basicos.

Otra definicion posible y bastante aceptada define un Sistema Opera-tivo como una capa compleja entre el hardware y el usuario, concebibletambien como una maquina virtual, que facilita al usuario o al progra-mador las herramientas e interfaces adecuadas para realizar sus tareasinformaticas, abstrayendole de los complicados procesos necesarios pa-ra llevarlas a cabo. Por ejemplo, un usuario normal simplemente abrelos ficheros grabados en un disco, sin preocuparse por la disposicion delos bits en el medio fısico, los tiempos de espera del motor del disco, laposicion de un cabezal, el acceso de otros usuarios, etc.

Aunque es un tema propenso a la discusion, algunos expertos estande acuerdo en que un sistema operativo debe constar de, por lo menos,un conjunto de programas similar al siguiente:

Un compilador de algun lenguaje de programacion, en Unix es deC.

Un enlazador.

Un ensamblador.

Un interprete de comandos.

Una amplia biblioteca del lenguaje de la plataforma.

Un kernel o nucleo.


socket : Mecanismo de comunicacion entre procesos empleado para estable-cer un extremo de un enlace de comunicaciones bidireccional entre dosaplicaciones, probablemente a traves de una red de computadoras, peropotencialmente tambien en el mismo ordenador. Existen dos clases desockets :

Internet sockets: En documentos RFC relacionados con TCP yUDP un socket en un cierto dispositivo se define como una combi-nacion de direccion IP, protocolo y numero de puerto. El SistemaOperativo BSD introdujo los sockets de red en 1983 (Berkeley so-ckets API). Cada socket se asocia a un determinado puerto, quepermite al protocolo de la capa de transporte (tıpicamente TCPo UDP) identificar a que aplicacion se envıan los datos.

Sockets locales: Empleados por sistemas POSIX, reciben el nom-bre de UNIX domain sockets o local sockets (El termino correctode la especificacion POSIX es POSIX Local IPC Sockets). Su fun-cion primaria es comunicar procesos en el mismo ordenador, envez de a traves de una red.

spin-off : Empresa secundaria o derivada de las actividades de una companıaprincipal.

switch : Es un dispositivo de redes de computadoras que interconecta seg-mentos de red. Emplea la logica de un bridge, pero permite una topo-logıa fısica y logica en estrella. Se emplea con frecuencia para reempla-zar a un hub. Es tambien conocido como un hub inteligente.

Un switch puede conectar segmentos de redes de paquetes conmuta-dos (Ethernet, Token Ring, Fibre Channel, . . . ) para formar una redheterogenea operando en OSI capa 2.

Cuando una trama llega al switch, este almacena la direccion MACde origen y el puerto de origen en una tabla de direcciones MAC. Elswitch entonces transmite selectivamente la trama desde puertos es-pecıficos, basandose en la direccion MAC de destino y en las entradasprevias de la tabla de direcciones MAC. Si la direccion MAC de destinoes desconocida o es una direccion de broadcast o de multicast, el swit-ch simplemente transmite la trama a todos los interfaces conectados,exceptuando el puerto de origen. Si la direccion MAC es conocida, latrama es enviada solamente al puerto correspondiente de la tabla de

A.21. T 213

direcciones MAC. Si el puerto de destino es el mismo que el puerto deorigen, la trama es filtrada y no es reenviada.

Los switches, a diferencia de los hubs, emplean microsegmentacionpara crear dominios de colision, uno por cada segmento conectado. Deesta manera, solo las tarjetas de red que estan conectadas directamentea traves de un enlace punto a punto o los hubs conectados directamenteestan compitiendo por el medio.

A.21. T

TAI : Temps Atomique International (TAI) o International Atomic Timees una escala de tiempo muy precisa y estable. Es la media ponderadade 200 relojes atomicos de cesio en alrededor de 50 laboratorios. Haestado disponible desde 1955, y es la especificacion internacional en laque se baso UTC el 1 de Enero de 1972.

La obtencion mas precisa de los tiempos TAI solo puede ser determi-nada retrospectivamente, puesto que la escala de tiempo esta definidapor comparaciones periodicas entre los relojes atomicos participantes,bajo el control del International Bureau of Weights and Measures. Na-turalmente, estas correcciones solo son necesitadas por aplicaciones querequieran una precision de nanosegundos. La mayorıa de los usuariosde los servicios de tiempo emplean las estimaciones del tiempo realproporcionadas por relojes atomicos que han sido referenciados previa-mente a la escala de tiempo compuesta. GPS es una fuente de tiempousada comunmente que se puede trazar a TAI.

A.22. U

UNIX : Sistema operativo portable, multitarea y multiusuario desarrolladoen principio por un grupo de empleados de los laboratorios Bell deAT&T, entre los que figuran Ken Thompson, Dennis Ritchie y DouglasMcIlroy.


Figura A.4: Evolucion de UNIX y de los sistemas operativos tipo UNIX

Hoy dıa, la palabra UNIX se utiliza para denotar diferentes concep-tos dependiendo del contexto en que es usada. Esto suele dar lugar aconfusiones:

UNIX - familia: desde el punto de vista tecnico, UNIX se refierea una familia de sistemas operativos que comparten unos criteriosde diseno e interoperabilidad en comun. Esta familia incluye masde 100 sistemas operativos desarrollados a lo largo de 20 anos.No obstante, es importante senalar que esta definicion no implicanecesariamente que dichos sistemas operativos compartan codigoo cualquier propiedad intelectual.

UNIX - el sistema operativo original: desde el punto de vistahistorico, UNIX se refiere a la subfamilia de sistemas operativosque descienden de la primera implementacion original de AT&T.El termino descendencia ha de interpretarse como trabajos deriva-tivos que comparten propiedad intelectual con la implementacionoriginal.

A.22. U 215

UNIX - la marca: desde el punto de vista legal, Unix es una mar-ca de mercado. Dicha marca es propiedad de “The Open Group”,una organizacion de estandarizacion que permite el uso de dichamarca a cualquier sistema operativo que cumpla con sus estanda-res publicados. Todo ello independientemente de que el sistemaoperativo en cuestion sea descendiente o clonico del Unix original.Resumiendo, la marca Unix no es propiedad de ninguna companıa.

UTC : Coordinated Universal Time es la realizacion atomica del tiempouniversal (Universal Time o UT) o Greenwich Mean Time, la baseastronomica para el tiempo civil. Las zonas horarias del resto del mundose calculan como diferencias positivas y negativas respecto al UT.

A diferencia del GMT, el UTC no se define por el sol o las estrellas,sino que se mide por medio de relojes atomicos. Debido a que la rotacionde la Tierra se ralentiza, se retrasa con respecto al tiempo atomico.UTC se sincroniza con el dıa y la noche de UT1, al que se le anaden oquitan segundos de salto (leap seconds) tanto a finales de junio comode diciembre, cuando resulta necesario. La puesta en circulacion de lossegundos de salto se determina por el Servicio Internacional de Rotacionde la Tierra, en base a sus medidas de la rotacion de la tierra.

“UTC” no es realmente una abreviatura; es una variante de tiempouniversal, (Universal Time, abreviadamente UT) y su modificador C(para “coordinado”), anadido para expresar que es una variante masde UT. Se puede considerar como un compromiso entre la abreviaturainglesa “CUT” y la francesa “TUC”.

Los tiempos UTC de verdadera alta precision solo pueden ser deter-minados tras conocer el hecho de que el tiempo atomico se establecemediante la reconciliacion de las diferencias observadas entre un con-junto de relojes atomicos mantenidos por un determinado numero deoficinas del tiempo nacionales. Esto se hace bajo los auspicios de laOficina Internacional de Pesas y Medidas (Bureau International desPoids et Mesures, BIPM). No obstante, los relojes atomicos son tanexactos que solo los mas precisos ordenadores de tiempo necesitan usarestas correcciones; y la mayorıa de los usuarios de servicios de tiempoutilizan los relojes atomicos que han sido previamente referenciados aUTC, para estimar la hora UTC.


UTC presenta problemas para los sistemas informaticos como Unixque guarda el tiempo como un numero de segundos a partir de untiempo de referencia. Debido a los segundos de salto, es imposible de-terminar que representacion va a tener una fecha futura, debido a queel numero de segundos de salto que se han de incluir en la fecha sonaun desconocidos.

UTC es el sistema de tiempo utilizado por muchos estandares deInternet y la World Wide Web. En particular, se ha disenado NetworkTime Protocol como una forma de distribuir el tiempo UTC en Internet.

A.23. V

A.24. W

WAN : Wide Area Network que en ingles significa red de area amplia. Unejemplo de este tipo de redes serıa rediris, la misma Internet o cualquierred en que no este en un mismo edificio todos sus miembros (sobre ladistancia hay discusion posible). Opera en la capa fısica y de enlace delmodelo de referencia OSI.

Muchas WAN son construidas por y para una organizacion o em-presa particular y son de uso privado, otras son construidas por losproveedores de Internet (ISP) para proveer de conexion a sus clientes.

Hoy en dıa Internet proporciona WAN de alta velocidad, y la necesi-dad de redes privadas WAN se ha reducido drasticamente mientras quelas redes privadas virtuales (VPN) que utilizan cifrado y otras tecnicaspara hacer esa red dedicada aumentan.

World FIP : Factory Information Protocol.

A.25. X

XML : Sigla del ingles eXtensible Markup Language (lenguaje de marcadoampliable o extensible) desarrollado por el World Wide Web Consor-tium (W3C).

A.26. Y 217

Es una version simple de SGML. Su objetivo principal es conseguiruna pagina web mas semantica. Aunque una de las principales funcio-nes con las que nace serıa suceder al HTML, separando la estructura delcontenido y permitiendo el desarrollo de vocabularios modulares, com-patibles con cierta unidad y simplicidad del lenguaje (objetivo que seviene desarrollando a traves de la especificacion XHTML), tiene otrasaplicaciones entre las que destaca su uso como estandar para el inter-cambio de datos entre diversas aplicaciones o software con lenguajesprivados como en el caso del SOAP.

Al igual que el HTML, se basa en documentos de texto plano en losque se utilizan etiquetas para delimitar los elementos de un documento.Sin embargo, XML define estas etiquetas en funcion del tipo de datosque esta describiendo y no de la apariencia final que tendran en pantallao en la copia impresa, ademas de permitir definir nuevas etiquetas yampliar las existentes.

Son varios los vocabularios desarrollados en XML con el fin de am-pliar sus aplicaciones. Podemos considerar fundamentales: XHTML,XSL-FO y XSLT, XLink, XPointer y Schema. Ademas, existen tambienversiones para usos especıficos, como MathML (formulas matematicas),SVG (graficos vectoriales), RSS (sindicacion de noticias), o XBRL (par-tes financieros).

A.26. Y

A.27. Z

Apendice B

Otras herramientas

En la utilizacion de este proyecto y de su correspondiente memoria se hanempleado las siguientes herramientas:

LATEX: es un conjunto de macros de TEX. La idea principal de LATEX esayudar a quien escribe un documento a centrarse en el contenido masque en la forma. La calidad tipografica de los documentos realizadoscon LATEXes comparable a la de una editorial cientıfica de primera lınea.LATEX es Software Libre bajo licencia LPPL y se ha empleado paragenerar esta memoria que describe el proyecto realizado.

Kile: es un editor de textos sencillo para TEX y LATEX. Se ha utilizado pararealizar esta memoria. Se utilizan las funciones integradas de las quedispone, haciendo mas sencilla la creacion de documentos (autocom-pleta comandos TEX / LATEX, posibilita generar y ver el documentode una forma mas sencilla, dispone de un asistente para introducir labibliografıa, . . . )

GIMP (GNU Image Manipulation Program): es el programa de ma-nipulacion de imagenes por excelencia del proyecto GNU. Es la alter-nativa del software libre mas firme al popular programa de retoquefotografico Photoshop de Adobe. En este proyecto se ha utilizado parahacer capturas de imagenes y retoque de las mismas.

OpenOffice.org: es un proyecto basado en codigo abierto para crear unasuite ofimatica. Es bastante compatible con los formatos de fichero deMicrosoft Office, ya que puede leer directamente los archivos creadoscon dicha suite ofimatica, aunque tiene su propio formato de archivosbasado en la especificacion XML.

219

220 APENDICE B. OTRAS HERRAMIENTAS

Bibliografıa

[1] Pagina web de ActivMedia Robotics. http://www.activmedia.com/,2005.

[2] Pagina web de Adeos. http://home.gna.org/adeos/, 2005.

[3] Pagina web de ART-Linux. http://www.movingeye.co.jp/ you1/art-linux/download.html, 2005.

[4] Pagina web de Borenstein sobre EERUF. http://www-personal.engin.umich.edu/ johannb/eeruf.htm, 2005.

[5] Pagina web de Carnegie Mellon Robot Navigation Toolkit.http://www.cs.cmu.edu/ carmen/, 2005.

[6] Pagina web de Comedi. http://www.comedi.org, 2005.

[7] Pagina web de Dave’s Robotic Operating System.http://www.dros.org/, 2005.

[8] Pagina web de eCos. http://sourceware.org/ecos/, 2005.

[9] Pagina web de Emerson Plantweb. http://plantweb.emerson-process.com, 2005.

[10] Pagina web de Enea. http://www.enea.com/, 2005.

[11] Pagina web de Honeywell Planscape.http://hpsweb.honeywell.com/Cultures/en-US/Products/Systems/PlantScape/default.htm, 2005.

[12] Pagina web de Invensys IA Series. http://www.foxboro.com/iaseries,2005.

[13] Pagina web de KURT. http://www.ittc.ukans.edu/kurt/, 2005.

221

222 BIBLIOGRAFIA

[14] Pagina web de Linux-SRT. http://www.srcf.ucam.org/ dmi1000/linux-srt/, 2005.

[15] Pagina web de Linux/RK. http://www.cs.cmu.edu/ rajkumar/linux-rk.html, 2005.

[16] Pagina web de Microsoft sobre tecnologıas COM/DCOM.http://www.microsoft.com/com, 2005.

[17] Pagina web de National Instruments.http://www.ni.com/industrial/resources.htm, 2005.

[18] Pagina web de Orca. http://orca-robotics.sourceforge.net/index.html,2005.

[19] Pagina web de Pyro AI and Robotics System.http://www.doc.ic.ac.uk/ ajd/Scene/index.html, 2005.

[20] Pagina web de QLinux. http://www.cs.umass.edu/ lass/software/qlinux/,2005.

[21] Pagina web de RED-Linux. http://linux.ece.uci.edu/RED-Linux/,2005.

[22] Pagina web de RedHawk Linux. http://www.ccur.com/realtime/index.htm,2005.

[23] Pagina web de Rockwell Automation. http://www.ab.com, 2005.

[24] Pagina web de RTAI. http://www.rtai.org/, 2005.

[25] Pagina web de RTAI del Politecnico di Milano.http://www.aero.polimi.it/ rtai/, 2005.

[26] Pagina web de RTLinux. http://www.rtlinux.org/, 2005.

[27] Pagina web de Scene. http://www.doc.ic.ac.uk/ ajd/Scene/index.html,2005.

[28] Pagina web de SCILabs Ingenieros. http://www.scilabs.es/, 2005.

[29] Pagina web de Simatic PCS 7 (Siemens).https://pcs.khe.siemens.com/index.asp?Nr=5217, 2005.

[30] Pagina web de SMART-Linux. http://www.ime.usp.br/ dilma, 2005.

BIBLIOGRAFIA 223

[31] Pagina web de SOWOS. http://www.thesoftwareobjects.com/Projects,2005.

[32] Pagina web de Sun sobre Java. http://java.sun.com/, 2005.

[33] Pagina web de Trolltech. http://www.trolltech.com/, 2005.

[34] Pagina web de Wind River Systems. http://www.windriver.com/, 2005.

[35] Pagina web de Yokogawa Stardom.http://www.yokogawa.com/stardom, 2005.

[36] Luders F.; Crnkovic I.; Sjogren A. Case study: Componentization ofindustrial control systems. IEEE COMPSAC, 2002.

[37] K. Azarm and G. Schmidt. Decentralized motion planning for multi-ple mobile robots. In Proceedings of Intelligent Autonomous Systems,volume 4, pages 302–309.

[38] J. Borenstein and Y. Koren. IEEE Transactions on Robotics and Au-tomation, volume II, chapter Error eliminating rapid ultrasonic firingfor mobile robot obstacle avoidance., pages 132–138. 1995.

[39] Cristina Panizo Cano. Modulo de habla corba para soul. Master’sthesis, ETSII-UPM, 2005.

[40] Rafael Chinchilla Camara. Ica 1.0.1 - installation and configuration.Technical report, Hard Real Time CORBA IST Project, 2004.

[41] R. Sanz; M.J. Segarra; A. de Antonio and I. Alarcon. A corba-basedarchitecture for strategic process-control. In Proceedings of IFAC Con-ference on New Technologies for Computer Control, Hong Kong, P.R.of China, 2001.

[42] C. Shafer; A. de Antonio; A. Clavijo; M. Segarra y R. Sanz. Teleo-peration of a virtual robot using and industrial corba-based controlarchitecture. Technical report, SPIE Telemanipulator and Telepresen-ce Technologies VI, 1999.

[43] R. Sanz; M.J. Segarra; A. de Antonio; I. Alarcon; F. Matia andA. Jimenez. Plant-wide risk management using distributed objects.Technical report, IFAC Symposium Fault Detection and Safety, Buda-pest, Hungary, 2000.

224 BIBLIOGRAFIA

[44] R. Sanz; I. Alarcon; M.J. Segarra; A. de Antonio; J.A. Clavijo. Pro-gressive domain focalization in intelligent control systems. Control En-gineering Practice, 1999.

[45] R. Sanz; M.J. Segarra; A. de Antonio; J.A. Clavijo. Ica: Middlewarefor intelligent process control. In IEEE International Symposium onIntelligent Control, Cambridge, USA. ISIC’1999.

[46] J. Clavijo; M. Segarra; R. Sanz; A. Jimenez; C. Baeza; C. Moreno;R. Vazquez; F. Diaz; A. Dıez. Real-time video for distributed controlsystems. Technical report, IFAC Workshop 2001, 2001.

[47] J. Clavijo; M. Segarra; R. Sanz; A. Jimenez; C. Baeza; C. Moreno; R.Vazquez; F. J. Diaz; A. Dıez. Real-time video for distributed controlsystems. In Proceedings of IFAC Workshop on Algorithms and Ar-chitectures for Real-time Control, AARTC’2000, Palma de Mallorca,Spain, 2000.

[48] Juan A. Fernandez; Javier Gonzalez and Antonio Martin. Communi-cating and integrating the modules of a robotic software application.In Distributed Autonomous Robotic Systems 3, number ISBN 3-540-64399-0. Department of System Engineering and Automation (ISA),University of Malaga, Espana, Springer-Verlag, 1998.

[49] Silvia Sanchez Herranz. Integracion de soar en ica. Master’s thesis,ETSII-UPM, 2005.

[50] John M. Holland. Designing Autonomous Mobile Robots. Number ISBN0-7506-7683-3. Newnes, 2004.

[51] R. Alami; F. Robert; F. Ingrand and S. Suzuki. A paradigm for plan-merging and its use for multirobot cooperation. In IEEE InternationalConference on Systems, Man and Cybernetics, pages 612–617, 1994.

[52] R. Alami; F. Robert; F. Ingrand and S. Suzuki. Multi-robot coopera-tion through incremental plan-merging. In IEEE International Confe-rence on Robotics and Automation, pages 2553–2579, 1995.

[53] K. Kawabata and et al. Distance measurement method under multipleultra sonic sensors environment. In Proc. IECON’96, volume II, page812.

[54] Ivan Pareja Larios. Sistema de comunicaciones para pioneer 2at-8.Master’s thesis, ETSII-UPM, 2004.

BIBLIOGRAFIA 225

[55] J.J. Leonard and H.F. Durrant-White. Directed sonar sensing for mo-bile robot navigation. Technical report, Kluwer Academic, 1992.

[56] Jong Hwan Lin and Dong Woo Choo. Physically based sensor modellingfor a sonar map in a specular environment. In IEEE InternationalConference on Robotics and Automation, 1992.

[57] R. Simmons; L-J Lin and C. Fedor. Autonomous task control for mo-bile robots (tca). In 5th IEEE international Symposium on IntelligentControl, Philadelphia PA, 1990.

[58] Raquel P. Conde Lopez. Mapeo facial de emociones sinteticas. Master’sthesis, ETSII-UPM, 2005.

[59] R. Sanz; F. Matıa and E.A. Puente. The ICa approach to intelligentautonomous systems. Advances in Autonomous Intelligent Systems,Microprocessor-Based and Intelligent Systems Engineering, chapter 4,pages 71–92. Kluwer Academic Publishers, Dordretch, NL, 1999.

[60] Richard M. Stallman; Roland McGrath. GNU Make - User’s Guide3.74. Free Software Foundation.

[61] Steve Vinoski Michi Henning. Advanced CORBA Programing wihC++. Number ISBN 0201379279. Addison Wesley Longman, 1999.

[62] P. Levi; M. Muscholl and Th. Braunl. Coperative mobile robots stutt-gart: Architecture and tasks. In Proceedings of Intelligent AutonomousSystems, volume 4, pages 310–317, 1995.

[63] F.A. Noreils. Toward a robot architecture integrating cooperation be-tween mobile robots: Application to indoor environment. The Interna-tional Journal of Robotics Research, 1993.

[64] OCI. IDA Group-Open Control Interface 1.4. http://www.ida-group.org. 1999.

[65] Akihisa Ohya; Takayubi Ohno and Shin’chi Yuta. Robotics and Autono-mous Systems 18, chapter Obstacle detectability of ultrasonic rangingsystem and sonar map understanding, pages 251–257. 1996.

[66] OMAC. Open Module Architecture Controls API SET 0.18. OMACAPI Workgroup 1998 - http://www.omac.org, 1998.

[67] OMG. UML Notation Guide. Object Management Group, 1997.

226 BIBLIOGRAFIA

[68] OMG. Air Traffic Control Version 1.0. Object Management Group,2000.

[69] OMG. Audio/Video Streams, Version 1.0. Object Management Group,2000.

[70] OMG. Concurrency Service, version 1.0. Object Management Group,2000.

[71] OMG. Externalization Service, version 1.0. Object ManagementGroup, 2000.

[72] OMG. Internationalization and Time, version 1.0. Object Manage-ment Group, 2000.

[73] OMG. Licensing Service, version 1.0. Object Management Group,2000.

[74] OMG. Mobile Agent Facility, version 1.0. Object Management Group,2000.

[75] OMG. Product Data Management Enablers Specification, version 1.3.Object Management Group, 2000.

[76] OMG. Property Service, version 1.0. Object Management Group, 2000.

[77] OMG. Query Service, version 1.0. Object Management Group, 2000.

[78] OMG. Relationship Service, version 1.0. Object Management Group,2000.

[79] OMG. Trading Object Service, version 1.0. Object Management Group,2000.

[80] OMG. Biomolecular Sequence Analysis, Version 1.0. Object Manage-ment Group, 2001.

[81] OMG. Clinical Observations Access Service, Version 1.0. Object Ma-nagement Group, 2001.

[82] OMG. Person Identification Service, version 1.1. Object ManagementGroup, 2001.

[83] OMG. Resource Access Decision, Version 1.0. Object ManagementGroup, 2001.

BIBLIOGRAFIA 227

[84] OMG. Authorization Token Layer Acquisition Service (ATLAS), V1.0. Object Management Group, 2002.

[85] OMG. Bibliographic Query Service, V 1.0. Object Management Group,2002.

[86] OMG. Collection Service, version 1.0.1. Object Management Group,2002.

[87] OMG. CORBA Component Model v3.0. Object Management Group,2002.

[88] OMG. Distributed Simulation Systems Specification, version 2.0. Ob-ject Management Group, 2002.

[89] OMG. Enhanced View of Time 1.1. Object Management Group, 2002.

[90] OMG. Genomic Maps, Version 1.0. Object Management Group, 2002.

[91] OMG. Life Cycle Service, version 1.2. Object Management Group,2002.

[92] OMG. Meta-Object Facility (MOFTM) Version 1.4. Object Manage-ment Group, 2002.

[93] OMG. Minimum CORBA. Object Management Group, 2002.

[94] OMG. Persistent State Service, version 2.0. Object ManagementGroup, 2002.

[95] OMG. Public Key Infrastructure, v 1.0. Object Management Group,2002.

[96] OMG. Security Service, version 1.8. Object Management Group, 2002.

[97] OMG. Telecom Service Access & Subscription (TSAS), version 1.0.Object Management Group, 2002.

[98] OMG. Time Service, version 1.1. Object Management Group, 2002.

[99] OMG. Common Object Request Broker Architecture: Core Specificationv3.0.3. Object Management Group, 2003.

[100] OMG. Common Warehouse MetamodelTM (CWMTM) Specification.Object Management Group, 2003.

228 BIBLIOGRAFIA

[101] OMG. Extensible Transport Framework Specification. Object Manage-ment Group, 2003.

[102] OMG. Fault Tolerant CORBA. Object Management Group, 2003.

[103] OMG. Laboratory Equipment Control Interface Specification (LECIS),v1.0. Object Management Group, 2003.

[104] OMG. Online Upgrade Proposed Available Specification. Object Ma-nagement Group, 2003.

[105] OMG. Real-time CORBA (Dynamic Scheduling). Object ManagementGroup, 2003.

[106] OMG. RealTime-CORBA Specification. Object Management Group,2003.

[107] OMG. Transaction Service, Version 1.4. Object Management Group,2003.

[108] OMG. Unified Modelling Languaje 1.5. Object Management Group,2003.

[109] OMG. Data Distribution Service for Real-time Systems, v1.0. ObjectManagement Group, 2004.

[110] OMG. Enhanced View of Time Service, version 1.2. Object Manage-ment Group, 2004.

[111] OMG. Event Service, version 1.2. Object Management Group, 2004.

[112] OMG. Naming Service, version 1.3. Object Management Group, 2004.

[113] OMG. Notification Service, version 1.1. Object Management Group,2004.

[114] OMG. Objective Interface Systems SECP revised submission. ObjectManagement Group, 2004.

[115] OMG. Computer Aided Design (CAD) Service, V 1.2. Object Mana-gement Group, 2005.

[116] OMG. Data Acquisition from Industrial Systems, version 1.1. ObjectManagement Group, 2005.

BIBLIOGRAFIA 229

[117] OMG. Open Comunication Interface Specification. Object Manage-ment Group, 2005.

[118] OMG. UML Superstructure Specification v2.0. Object ManagementGroup, 2005.

[119] OMG. XML Metadata Interchange (XMI) v2.1. Object ManagementGroup, 2005.

[120] OROCOS. Open Robot Control Software Open Realtime Control Ser-vices. http://www.orocos.org, 2002.

[121] OSACA. Open architecture for controls within automation systems.Number 6379,9115. 1996.

[122] Y. Kim; J-Y Jo; V.B. Velasco; N.A. Barendt; A. Podgurski; G. Ozso-yoglu and F.L. Merat. A flexible software architecture for agile manu-facturing. In Proceedings of the 1997 IEEE International Conferenceon Robotics and Automation, Alburquerque, New Mexico, 1997.

[123] Richard M. Stallman; Roland H. Pesch. GBD - User’s Guide 4.17. FreeSoftware Foundation.

[124] Yang Z.; Huang G.; Guan R. L. Y.; Gay R. Corba as object oriented in-fraestructure for factory communication and control. In APCC/OECC.

[125] A.C. Sanderson. Cooperative navigation among multiple mobile robots.In H. Asama et al., editor, Distributed Autonomous Robotics Systems2, number ISBN 3-540-64399-0, Tokyo, 1996. Springer-Verlag.

[126] A.C. Sanderson. Multirobot navigation using cooperative teams. InDistributed Autonomous Robotics Systems 3, number ISBN 3-540-64399-0. Institute for Process Control and Robotics, University of Kals-ruhe, Springer-Verlag, 1998.

[127] R. Sanz. Embedding interoperable objects in automation systems. InProceedings of 28th IECON, Annual Conference of the IEEE IndustrialElectronics Society, number IEEE Catalog: 02CH37363, pages 2261–2265, Sevilla, Spain, 2002.

[128] R. Sanz. The ist hrtc project. In OMG Real-Time and Embedded Dis-tributed Object Computing Workshop, Washington, USA, 2003. OMG.

230 BIBLIOGRAFIA

[129] D.B. Stewart; D.E. Schmitz and P.K. Khosla. IEEE Transactions onSystems, Man, and Cybernetics, volume 22, chapter The Chimera IIReal-Time Operating System for Advanced Sensor-Based Robotic Ap-plications, pages 1282–1295. 1992.

[130] Marie-Helene Doussin; Ricardo Sanz; Ignacio Gonzalez; Joao-Paulo Ba-rros; Miguel Segarra. Standardized interoperation in electrical substa-tion automation systems. In 3rd European Systems Engineering Con-ference, Toulouse, Francia, 21-24 de Mayo 2002.

[131] A. Stentz. Vision and Navigation. The Carnegie Mellon NavLab, chap-ter The CODGER System for Mobile Robot Navigation. Kluwer Aca-demic Publishers, 1990.

[132] A.H. Shirkhodaie; S. Taban and A.H. Soni. Ai assisted multiarm robo-tics. In IEEE International Conference on Robotics and Automation,pages 1672–1679, 1985.

[133] Trolltech. Qt 3.3 Whitepaper.

[134] Dimitri van Heesch. Aria Reference Manual 1.3.2.

[135] Andreas Vogel; Bhaskar Vasedevan; Maira Benjamin; Ted Villalba.C++ Programming with CORBA. Number ISBN 0-471-28306-1. JohnWiley & Sons, 1999.

[136] Wind River Systems. Tornado - User’s Guide 2.0.

[137] Wind River Systems. Tornado API - Programmer’s Guide 2.0.

[138] Wind River Systems. VxWorks - Programmer’s guide 5.4.

[139] Wind River Systems. VxWorks - Reference Manual 5.4.

[140] Wind River Systems. VxWorks Network - Programmer’s guide 5.4.

[141] Wind River Systems. WindView - User’s Guide 2.0.1.

[142] M.Rodrıguez; R.Sanz; S.Galan; C.Garcıa; R.Chinchilla y A.Yela. Cor-ba: Una plataforma software para los sistemas de control del futuro.Technical report, Autonomuos System Laboratory - Universidad Po-litecnica de Madrid, 2004.

[143] D. Schmidt y F. Kuhns. An overview of the real-time corba specifica-tion. IEEE Computer, 2000.

BIBLIOGRAFIA 231

[144] K. Kusunoki; I. Imai; H. Ohtani; T.Nakakawaji y M. Ohshima. Corbabased remote monitoring system for factory automation. In ISORC’98.

[145] Beatriz L. Boada; L.Moreno y M.A. Salichs. Sensor coordination formulti mobile robots systems. In Distributed Autonomous Robotic Sys-tems 3, number ISBN 3-540-64399-0. Universidad Carlos III, Espana,Springer-Verlag, 1998.

[146] GressierSoudan E.; Epivent M.; Laurewnt A.; Boisier R.; y Raddadi M.Component oriented control architecture: the coca project. Manufac-turing, Microprocessors and Microsystems journal, 1999.

[147] Yasumichi Aiyama; Mitsuhiro Hara; Takashi Yabuki; Jun Ota y Ta-mio Arai. Cooperative transportation by two 4-legged robots with im-plicit communication. In Distributed Autonomous Robotic Systems 3,number ISBN 3-540-64399-0. The University of Tokyo & Hitachi Ltd.,Japan, Springer-Verlag, 1998.

[148] Ron Zahavi. Enterprise Application Integration with CORBA - Com-ponent and Web-Based Solutions. Number ISBN 0-471-32720-4. JohnWiley & Sons, 2000.

[149] Diego Lopez Zamarron. Analisis de sistemas operativos de tiempo reallibres. Technical report, UPM, 2004.

Versión RT-CORBA del servidor Pioneer 2AT-8.

Documents

Transcript of Versión RT-CORBA del servidor Pioneer 2AT-8.