UNIVERSIDAD POLITECNICA DE MADRIDstr/proyectos/upmsat2/doc/PFC_dbrosnan.pdf · STRAST Sistemas de...

UNIVERSIDAD POLITECNICA DE MADRIDFACULTAD DE INFORMATICA

TRABAJO FIN DE CARRERAInfraestructura de desarrollo de aplicaciones para

sistemas IMA (Integated Modular Avionics)

Autor: Daniel Brosnan Blazquez

Tutor: Juan Zamorano Flores

12 de agosto de 2013

Indice general

Resumen ix

1. Introduccion 1

1.1. Motivacion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

1.2. Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

1.3. Estructura del documento . . . . . . . . . . . . . . . . . . . . . . . . 5

2. Antecedentes 7

2.1. Sistemas de tiempo real . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.1.1. Concurrencia . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.1.2. Planificacion . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

2.1.3. Programacion en Ada . . . . . . . . . . . . . . . . . . . . . . . 23

2.2. El procesador LEON . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

2.2.1. Arquitectura SPARC . . . . . . . . . . . . . . . . . . . . . . . 29

2.2.2. Las ventanas de registros . . . . . . . . . . . . . . . . . . . . . 30

2.3. ORK+ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

2.3.1. Arquitectura del nucleo ORK+ . . . . . . . . . . . . . . . . . 35

2.3.2. Integracion del nucleo en GNAT . . . . . . . . . . . . . . . . . 36

2.3.3. Sistema de compilacion cruzada . . . . . . . . . . . . . . . . . 37

2.4. Sistemas de particionado espacial y temporal . . . . . . . . . . . . . . 38

2.5. El hipervisor XtratuM . . . . . . . . . . . . . . . . . . . . . . . . . . 40

2.5.1. Virtualizacion . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

2.5.2. XtratuM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

2.6. ORK+/XtratuM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

2.6.1. Adaptacion del manejo de la CPU . . . . . . . . . . . . . . . . 51

2.6.2. Adaptacion del soporte de interrupciones . . . . . . . . . . . . 51

2.6.3. Adaptacion de los servicios de manejo de tiempo . . . . . . . . 52

2.7. El microsatelite UPMSat-2 . . . . . . . . . . . . . . . . . . . . . . . . 53

2.8. Simuladores. Matlab/Simulink . . . . . . . . . . . . . . . . . . . . . . 53

2.9. Comunicacion serie (UART) . . . . . . . . . . . . . . . . . . . . . . . 54

2.10. Hardware-In-The-Loop . . . . . . . . . . . . . . . . . . . . . . . . . . 55

i

3. Adaptacion de ORK+ a XtratuM 3 573.1. Version 3.3.3 de XtratuM . . . . . . . . . . . . . . . . . . . . . . . . . 58

3.1.1. Diferencias con la version anterior . . . . . . . . . . . . . . . . 583.1.2. Cambios realizados en ORK+ . . . . . . . . . . . . . . . . . . 593.1.3. Problemas encontrados . . . . . . . . . . . . . . . . . . . . . . 643.1.4. Bibliotecas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

3.2. Version 3.4.0 de XtratuM . . . . . . . . . . . . . . . . . . . . . . . . . 663.2.1. Diferencias con la version anterior . . . . . . . . . . . . . . . . 663.2.2. Cambios realizados en ORK+ . . . . . . . . . . . . . . . . . . 673.2.3. Problemas encontrados . . . . . . . . . . . . . . . . . . . . . . 683.2.4. Bibliotecas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70

3.3. Version 3.7.1 de XtratuM . . . . . . . . . . . . . . . . . . . . . . . . . 713.3.1. Diferencias con la version anterior . . . . . . . . . . . . . . . . 713.3.2. Cambios realizados en ORK+ . . . . . . . . . . . . . . . . . . 713.3.3. Problemas encontrados . . . . . . . . . . . . . . . . . . . . . . 723.3.4. Bibliotecas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

4. Verificacion 754.1. Ejemplos de uso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 764.2. Pruebas de validacion . . . . . . . . . . . . . . . . . . . . . . . . . . . 79

5. Aplicacion de demostracion 815.1. Modelo ADCS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 825.2. Generacion de codigo . . . . . . . . . . . . . . . . . . . . . . . . . . . 84

5.2.1. Proceso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 845.2.2. Descripcion . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87

5.3. Integracion en ORK+ . . . . . . . . . . . . . . . . . . . . . . . . . . 905.4. Hardware-in-the-loop . . . . . . . . . . . . . . . . . . . . . . . . . . . 91

5.4.1. Manejador del dispositivo UART . . . . . . . . . . . . . . . . 915.4.2. Prueba del dispositivo UART . . . . . . . . . . . . . . . . . . 935.4.3. HIL en Simulink . . . . . . . . . . . . . . . . . . . . . . . . . 955.4.4. Modificaciones en el modelo ADCS . . . . . . . . . . . . . . . 975.4.5. Infraestructura final . . . . . . . . . . . . . . . . . . . . . . . 98

5.5. Guıa de uso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1055.5.1. Configuracion y construccion de XtratuM . . . . . . . . . . . 1055.5.2. Compilacion de la aplicacion . . . . . . . . . . . . . . . . . . . 1075.5.3. Ejecucion de la aplicacion . . . . . . . . . . . . . . . . . . . . 1095.5.4. Depuracion de la aplicacion . . . . . . . . . . . . . . . . . . . 110

5.6. Resultados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111

6. Conclusiones, trabajo futuro y agradecimientos 115

Bibliografia y referencias 118

Indice de figuras

1.1. Estructura general de las aplicaciones para sistemas de tipo IMA . . . 1

2.1. Plan cıclico para el conjunto de tareas . . . . . . . . . . . . . . . . . 132.2. Inversion de prioridad . . . . . . . . . . . . . . . . . . . . . . . . . . 202.3. Ejemplo de herencia de prioridad . . . . . . . . . . . . . . . . . . . . 212.4. Ejemplo del protocolo de techo de prioridad . . . . . . . . . . . . . . 222.5. Ejemplo del protocolo de techo de prioridad inmediato . . . . . . . . 232.6. Ventanas de registros de la arquitectura SPARC V8 . . . . . . . . . . 312.7. Mapa circular de las ventanas de registros en el LEON3 . . . . . . . . 332.8. Arquitectura del kernel ORK+. . . . . . . . . . . . . . . . . . . . . . 362.9. Arquitectura Software. Integracion de ORK+ con el compilador. . . . 372.10. Proceso de compilacion de un ejecutable con ORK+. . . . . . . . . . 382.11. Arquitectura de planificacion jerarquica. . . . . . . . . . . . . . . . . 392.12. Arquitectura de Xtratum. . . . . . . . . . . . . . . . . . . . . . . . . 442.13. Estados de las particiones. . . . . . . . . . . . . . . . . . . . . . . . . 452.14. Ejemplo de planificacion. . . . . . . . . . . . . . . . . . . . . . . . . . 472.15. Proceso de creacion de un sistema con XtratuM. . . . . . . . . . . . . 502.16. Vista exterior del UPMSat-2. . . . . . . . . . . . . . . . . . . . . . . 532.17. Dispositivo UART. APB (Advanced Peripheral Bus) (Reproducido de

[9]). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 552.18. Modelo de ingenierıa del computador de a bordo GR-XC3S1500 Spar-

tan3. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

4.1. Mapa de memoria general para los ejemplos de uso y las pruebas deORK+ sobre XtratuM. . . . . . . . . . . . . . . . . . . . . . . . . . . 76

4.2. Estructura del ejemplo de manejo del puerto de tipo “sampling” porinterrupciones. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79

5.1. Estructura de la aplicacion de demostracion para su uso en vuelo . . 815.2. Modelo del control y determinacion de la actitud del satelite. . . . . . 835.3. Menu del modelo ADCS . . . . . . . . . . . . . . . . . . . . . . . . . 845.4. Configuracion de las opciones del paso de ejecucion . . . . . . . . . . 855.5. Configuracion de las opciones de optimizacion . . . . . . . . . . . . . 855.6. Seleccion del entorno donde va a ejecutar el codigo . . . . . . . . . . 855.7. Deshabilitar la opcion de compilacion del codigo generado . . . . . . 85

iii

5.8. Generacion de un programa principal de ejemplo . . . . . . . . . . . . 865.9. Habilitar informe de generacion de codigo . . . . . . . . . . . . . . . 865.10. Subsistema del modelo. ADCS del microsatelite . . . . . . . . . . . . 865.11. Generacion del codigo del subsistema . . . . . . . . . . . . . . . . . . 875.12. Bloque de configuracion del puerto serie . . . . . . . . . . . . . . . . 955.13. Bloque de envıo de datos serie . . . . . . . . . . . . . . . . . . . . . . 955.14. Bloque de recepcion de datos serie . . . . . . . . . . . . . . . . . . . . 955.15. Configuracion del dispositivo UART en Simulink . . . . . . . . . . . . 965.16. Bloques funcionales del subsistema de control del modelo . . . . . . . 975.17. Bloques funcionales de la capa de comunicacion que reemplazan los

originales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 985.18. Mapa de memoria de la aplicacion de demostracion . . . . . . . . . . 1055.19. Configuracion de la plataforma de ejecucion . . . . . . . . . . . . . . 1065.20. Configuracion del dispositivo UART . . . . . . . . . . . . . . . . . . . 1065.21. Configuracion del mapa de memoria . . . . . . . . . . . . . . . . . . . 1075.22. Configuracion de la duracion de la simulacion, establecida en 10 pasos

ya que el tiempo de muestreo es de 0.1 . . . . . . . . . . . . . . . . . 1105.23. Cuaterniones que representan la actitud del satelite con respecto a

un marco de referencia vertical . . . . . . . . . . . . . . . . . . . . . . 1125.24. Transformacion de los cuaterniones a los angulos de Euler . . . . . . 1125.25. Velocidad angular del satelite con respecto a un marco de referencia

vertical . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1125.26. Errores de estimacion calculados a partir de los cuaterniones con res-

pecto a un valor de referencia . . . . . . . . . . . . . . . . . . . . . . 112

Indice de cuadros

2.1. Conjunto de tareas del ejecutivo cıclico . . . . . . . . . . . . . . . . . 132.2. Notacion estandar para los modelos de planificacion . . . . . . . . . . 152.3. Secuencia de ejecucion para el caso de inversion de prioridad . . . . . 202.4. Hiperllamadas de XtratuM para la arquitectura SPARC V8. . . . . . 432.5. Configuracion del dispositivo UART dependiendo del procesador . . . 55

5.1. Variacion de los componentes del campo magnetico con respecto a losejes del satelite . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113

5.2. Variacion de los componentes del campo magnetico con respecto almarco de referencia del satelite, medida en Teslas . . . . . . . . . . . 113

5.3. La corriente requerida en los magnetopares, medida en Amperios . . . 1135.4. Momento de fuerza medido en Newton-metros . . . . . . . . . . . . . 113

v

Acronimos

APEX APplication EXecutive. 42, Glosario:

API Application Programming Interface. 45, 49

ARINC Avionics Applicaction Standard Software Interface. 42, 45, 47

CPP Ceiling Priority Protocol. 22, 23

EDF Earliest Deadline First. 14, 15, 18, 19

ELF Executable and Linkable Format. 108, 109, 111

ESA Agencia Espacial Europea. 2, 28, 33, 117

FentISS Fent Innovative Software Solutions. 116

FES Functional Engineering Simulator. 2

FIFO First In-First Out . 48

FPS Fixed Priority Scheduling. 14, 16, 18, 19

FVB Functional Validation Bench. 2

GCC GNU Compiler Collection. 37

GDB GNU Debugger . 38, 110, 111

GNAT GNU NYU Ada Translator . 36, Glosario: GNAT

GNU GNU’s Not Unix! . 37, 38

GPL licencia publica general, GNU General Public License. 37

HAL capa de abstraccion del hardware. 43

HIL Hardware-In-the-Loop. 5

ICPP Inmediate Ceiling Priority Protocol. 22

vii

IDR/UPM instituto Ignacio Da Riva. 4

IMA Avionica modular integrada. xi, 1, 3, 5, 39, 40, 42, 105, 115

LGPL licencia publica general reducida, GNU Lesser General Public License. 38

MMU unidad de gestion de memoria, Memory Management Unit . 41

MultiPARTES Multicores Partitioning for Trusted Embedded Systems. 2, 116

ORK+ Open Ravenscar Kernel. xi, 1–5, 11, 18, 28, 33, 34, 36–40, 51, 52, 59–61,67, 68, 71–73, 75, 79–82, 107, 115, 116

RISC Procesador con juego de instruccones reducidas. 29

RTA Response time analysis. 17

RTB The Real-time Test Bench. 2

SPARC Arquitectura de Procesador Escalable (Scalable Processor ARChitecture).29, 49, 51

SSF Space Systems Finland Ltd.. 3

STR Sistemas de Tiempo Real. 7

STRAST Sistemas de Tiempo Real y Arquitectura de Servicios Telematicos. xi, 4,33, 115, 116

SVF Software Validation Facility. 2

UPM Universidad Politecnica de Madrid. xi

UPV Universidad Politecnica de Valencia. 41

XAL XtratuM Abstraction Layer. 106

XEF XtratuM Executable Format. 108, 109

Resumen

En este documento se describe el proyecto fin de carrera realizado para propor-cionar una infraestructura de desarrollo de aplicaciones para sistemas orientados aejecutar en plataformas de Avionica modular integrada (IMA), es decir, sistemasmodulares orientados a funcionar en vuelo.

El trabajo esta enmarcado dentro de dos proyectos europeos: EagleEye y Multi-PARTES, los cuales cuentan con la colaboracion del grupo de Sistemas de TiempoReal y Arquitectura de Servicios Telematicos (STRAST) de la Universidad Politecni-ca de Madrid (UPM), del que formo parte. Tiene como principal objetivo el desarro-llo de una aplicacion de demostracion para su uso en vuelo. Para este desarrollo esnecesaria la adaptacion del nucleo de tiempo real Open Ravenscar Kernel (ORK+)a las distintas versiones del hipervisor XtratuM, que se distribuyen en el curso de losproyectos, su mantenimiento, y la ayuda a la aportacion de herramientas de desa-rrollo para su uso en sistemas de este tipo. La modularidad de la infraestructurase proporciona gracias al hipervisor XtratuM, que ofrece el aislamiento temporal yespacial necesario entre particiones. En el caso del proyecto MultiPARTES ademasse concibe el sistema para ser usado en plataformas multiprocesador, aunque esteaspecto queda transparente para el sistema operativo ORK+.

ix

Capıtulo 1

Introduccion

En este capıtulo se expone una descripcion breve de lo que se pretende conseguircomo resultado del trabajo y se amplıa el resumen incluido en el capıtulo anterior,para apuntar la motivacion y los objetivos del proyecto llevado a cabo. Tambien seincluye una descripcion de la estructura de la memoria, de manera que se puedatener una vision global del documento.

Este trabajo fin de carrera pretende ofrecer un marco para el desarrollo de apli-caciones que ejecuten sobre ORK+ en infraestructuras de tipo IMA, plataformasorientadas a funcionar en vuelo que soportan la ejecucion de aplicaciones de distintacriticidad. La estructura de estas aplicaciones se muestra en la figura 1.1.

ORK+

Aplicación de E/S

Tarea UARTTarea SPI

Tarea I2C

Partición 1

ORK+

Aplicación de Control

Tarea ADCSTarea Volante

Partición 2

RTEMS

Aplicación de análisis de datos

Tarea Análisis

Partición 3

LINUX

Aplicación de gestión de estados

Tarea Gestión

Partición 4

XtratuM

Figura 1.1: Estructura general de las aplicaciones para sistemas de tipo IMA

En la figura se muestra como las aplicaciones que ejecuten sobre ORK+ puedeninteractuar con aplicaciones que ejecuten en otros sistemas operativos en distintasparticiones, en un entorno donde se garantiza el aislamiento espacial y temporal.Esto permite que sobre un mismo sistema (monoprocesador o multiprocesador) sepuedan ejecutar aplicaciones con distintos niveles de criticidad con requisitos de

1

1.1. MOTIVACION

seguridad propios de sistemas de tiempo real. En este proyecto se expone el trabajorealizado para hacer posible que en la estructura puedan ejecutar particiones delsistema operativo ORK+.

1.1. Motivacion

Este proyecto fin de carrera esta enmarcado dentro de dos proyectos europeos:EagleEye y Multipartes.

El proyecto EagleEye es una mision de observacion de la Tierra desarrollada porla Agencia Espacial Europea (ESA), orientada a demostrar el potencial del bancode pruebas para avionica de la ESA.

El banco de pruebas esta compuesto por una nave y un simulador de mision.Esta orientado a proveer un entorno representativo para el desarrollo, demostraciony validacion de tecnologıa para avionica. Hay cuatro fases del banco de pruebas,cada una se corresponde con un nivel de fidelidad en la simulacion y cada unaesta asociada a un estado diferente del desarrollo de un proyecto o tecnologıa:

El simulador de ingenierıa funcional, Functional Engineering Simulator (FES):Contiene todos los modelos funcionales necesarios para la validacion de losalgoritmos requeridos en el sistema de uso en el espacio.

La validacion de la ingenierıa funcional, Functional Validation Bench (FVB):Valida los elementos fısicos disenados para ir embarcados, aunque esten en fasede prototipo. En esta se analiza el rendimiento de estos elementos y se validanen su contexto simulado.

El entorno de validacion del software, Software Validation Facility (SVF):Valida todo el software para ser embarcado, incluyendo software para los expe-rimentos, manejadores de los datos y los diferentes algoritmos del sistema. Enesta fase se realiza la simulacion de modo que el software embarcado ejecutedirectamente en el prototipo del hardware del sistema e interaccione para suvalidacion con el entorno de simulacion.

La validacion en terminos de tiempo real, The Real-time Test Bench (RTB):Validacion de todo el sistema interviniendo el hardware final del sistema, inter-accionando con el entorno de simulacion del espacio, de la nave y del segmentode tierra.

El proyecto Multicores Partitioning for Trusted Embedded Systems (MultiPAR-TES) es un proyecto del septimo marco europeo, orientado a proporcionar parti-cionado en plataformas multiprocesador para sistemas empotrados asegurando sufiabilidad. Con este tipo de infraestructuras se pretende abordar el crecimiento encomplejidad de las aplicaciones en muchos dominios en cuanto a sus requisitos deseguridad y de dependencia. Esto es porque con este tipo de infraestructuras se dasoporte a sistemas empotrados de criticidad mixta, en plataformas multiprocesador,

2

CAPITULO 1. INTRODUCCION

con lo que se consigue reducir el alto coste de desarrollo de estas aplicaciones, redu-ciendo la dependencia, y aprovechar las ventajas de los multiprocesadores actualespara sistemas empotrados con requisitos de tiempo real.

En estos dos proyectos colabora nuestro grupo, en el caso del proyecto EagleEyea traves de un acuerdo de colaboracion de la propuesta, dirigida por Space SystemsFinland Ltd. (SSF), para el uso de plataformas que proporcionan particionado espa-cial y temporal en sistemas realistas de uso en el espacio, y en el caso del proyectoMultiPARTES por ser uno de los participantes del mismo. El objetivo principal deestos dos en la participacion del grupo, es la adaptacion del kernel de tiempo realORK+ al hipervisor que proporciona el particionado y su soporte a lo largo delproyecto.

La aplicacion de demostracion que se incluye en el documento, y que confor-ma el objetivo principal del proyecto fin de carrera, constituye una representacionlimitada de una de las fases del banco de pruebas indicado. La fase es el entornode validacion software, puesto que se prueba el control de actitud del microsateli-te UPMSat-2 que ejecuta directamente en un posible prototipo de ordenador dea bordo interaccionando con un PC que se encarga de simular el entorno real delmismo. Todo este software de a bordo ejecutando en una plataforma particionada.Tambien se ha realizado para proporcionar una aplicacion como demostrador de lainfraestructura obtenida tras la adaptacion de ORK+ al hipervisor XtratuM, quees uno de los requisitos en la participacion en el proyecto MultiPARTES.

1.2. Objetivos

El objetivo principal es el desarrollo de una aplicacion de demostracion para suuso en vuelo.

Para la realizacion del objetivo principal, se dispone de los siguientes objetivossecundarios:

1. Adaptacion del kernel ORK+ a las distintas versiones del hipervisor XtratuMque se distribuyen en el curso de los proyectos.

2. Mantenimiento del kernel ORK+.

3. Ayuda a la aportacion de herramientas de desarrollo para la construccion desistemas de tipo IMA.

Para cumplir estos objetivos las tareas realizadas son:

Estudiar el kernel de tiempo real ORK+.

Estudiar el hipervisor XtratuM.

Adaptar ORK+ a las versiones 3.3.3, 3.4 y 3.7 del hipervisor XtratuM.

3

1.2. OBJETIVOS

Solucionar los distintos bugs y problemas que vayan surgiendo en la adaptaciona las distintas versiones indicadas.

Anadir soporte para la comunicacion entre particiones y su gestion para suuso en ORK+.

Adaptar las pruebas, que se disponen para ORK+ sobre maquina desnuda,para su ejecucion sobre XtratuM.

Anadir ejemplos de uso de ORK+ sobre XtratuM a los ya existentes.

Construir un demostrador del funcionamiento del sistema para aplicaciones deuso en el espacio.

Ayudar en la generacion automatica de un entorno de compilacion de parti-ciones.

El trabajo de adaptacion de ORK+ al hipervisor XtratuM, en su primera ver-sion para el procesador LEON2, se realizo en nuestro grupo [1]. Por tanto en estedocumento se recoge la continuacion de este trabajo para la adaptacion de ORK+a las posteriores versiones del hipervisor XtratuM.

La adaptacion de ORK+ ha llevado desde anadir paquetes al kernel para el usode nuevas funcionalidades hasta modificar funciones ya existentes para adaptarlo ala version concreta del hipervisor XtratuM o para anadir funcionalidades. En estaadaptacion a las distintas versiones, ademas, se han ido encontrando y solucionandobugs, en algunos casos de ORK+ y en otros de XtratuM.

El soporte para el uso de funcionalidades de las particiones se ha anadido reali-zando un envoltorio, escrito en Ada, de las funciones correspondientes de XtratuM,escritas en C.

Gracias a la colaboracion del grupo STRAST en el proyecto UPMSat-2 (ver sec-cion 2.7), se ha podido realizar un demostrador de uso del sistema en el espacioque es una de las exigencias de los proyectos en los que se enmarca el trabajo y elobjetivo principal de este trabajo de fin de carrera. El grupo STRAST se encargadel desarrollo y/o validacion del software embarcado del satelite. Partes de este soft-ware son desarrolladas por el personal de aeronauticos del instituto Ignacio Da Riva(IDR/UPM)1 con la herramienta de modelado Matlab/Simulink (ver seccion 2.8).Este es el caso del control de actitud2 del satelite, el cual es el sistema que se vaa usar para la demostracion. Sobre este sistema lo que se quiere es construir unainfraestructura que permita su ejecucion en el hardware real, lo que implica que lainfraestructura debe permitir la interaccion del hardware real con la herramientade simulacion puesto que el controlador debe recibir las entradas del entorno, quese encuentra simulado en Simulink. Por lo que el entorno de ejecucion sera por unlado ORK+/XtratuM ejecutando sobre el modelo de ingenierıa del satelite y por

1www.idr.upm.es.2http://es.wikipedia.org/wiki/Control de actitud

4

www.idr.upm.es.

http://es.wikipedia.org/wiki/Control_de_actitud

CAPITULO 1. INTRODUCCION

otro lado el simulador simulando el entorno del satelite, interaccionando estos enuna plataforma Hardware-In-the-Loop (HIL) (ver seccion 2.10).

La generacion automatica de un entorno de compilacion de particiones formaparte de uno de los paquetes de trabajo del proyecto MultiPARTES. La ayudarealizada en este trabajo ha sido la aportacion de los ejemplos y el demostradordesarrollados para tener una base desde la que partir, la correccion de errores en loscomponentes generados y la aportacion de guıas de actuacion segun las necesidadesde las aplicaciones de las distintas particiones.

1.3. Estructura del documento

El documento esta estructurado de tal forma que primero se presentan las tecni-cas, herramientas y conceptos que han sido necesarios para el desarrollo de esteproyecto fin de carrera, y son necesarios para la comprension del presente documen-to; a continuacion, se presenta la adaptacion de ORK+ a las versiones de XtratuMindicadas; despues, se indica la verificacion realizada para comprobar el correcto fun-cionamiento de esta adaptacion; posteriormente, se presenta la aplicacion de demos-tracion de la infraestructura construida; y, para terminar, se indican las conclusionesy los resultados del trabajo y los agradecimientos.

Por lo que por capıtulos el contenido es el siguiente:

Capıtulo 1: este capıtulo, donde se incluye una introduccion del presenteproyecto fin de carrera.

Capıtulo 2: incluye una presentacion de las tecnicas, herramientas y concep-tos necesarios para la compresion del contenido del documento.

Capıtulo 3: incluye el trabajo de adaptacion de ORK+ a la version 3 deXtratuM.

Capıtulo 4: incluye el trabajo de adaptacion del conjunto de verificacion delfuncionamiento de ORK+ para funcionar con XtratuM.

Capıtulo 5: incluye la descripcion de la aplicacion de demostracion de la in-fraestructura construida para el desarrollo de aplicaciones para sistemas IMA.

Capıtulo 6: incluye las conclusiones, el trabajo futuro y los agradecimientos.

Bibliografıa: incluye las referencias basicas que se han usado para realizar eltrabajo.

5

1.3. ESTRUCTURA DEL DOCUMENTO

6

Capıtulo 2

Antecedentes

En este capıtulo se presentan los conceptos necesarios para entrar en el contextodel proyecto fin de carrera y facilitar la comprension de su contenido. Tambiense incluyen descripciones de herramientas y tecnicas usadas para el desarrollo delmismo.

2.1. Sistemas de tiempo real

Los Sistemas de Tiempo Real (STR) [7] son sistemas informaticos que inter-actuan con el entorno en el que se encuentran con unos requisitos temporales es-pecıficos determinados por este entorno. Habitualmente se encuentran en sistemasde ingenierıa mas amplios, y son estos parte o la totalidad del entorno que controlan.La implantacion de estos sistemas en la vida diaria es cada vez mayor, encontrando-se en la mayorıa de dispositivos tanto de uso domestico como industrial: telefonosmoviles, coches, lavadoras, aviones, ingenierıa aeroespacial, o procesos de fabricacionindustrial.

La caracterıstica principal de estos sistemas es su dinamica temporal. En lossistemas de tiempo real no solo se requiere que las acciones sean correctas, sino quetienen que ejecutarse dentro de un intervalo determinado. Estas actividades, en lossistemas de tiempo real se denominan tareas y tienen un comportamiento temporaldefinido por su esquema de activacion (cuando se ejecutan) y su plazo de ejecucion(cuando ha de haberse concluido su ejecucion).

En cuanto al esquema de activacion, las tareas se clasifican segun este en pe-riodicas y esporadicas. Las tareas periodicas se determinan por tener un ciclo deejecucion fijado. Las tareas esporadicas son tareas que se ejecutan cada vez que seproduce un evento que tiene asociado.

En cuanto al plazo de ejecucion, si bien es deseable que todas las tareas secompleten dentro de su plazo de ejecucion, algunas tareas pueden tener requisitostemporales no estrictos. Dependiendo de esta caracterıstica en cuanto a los requisitostemporales se tienen los siguientes tipos de sistemas de tiempo real:

Sistemas de tiempo real flexible (soft real-time systems), en los que

7

2.1. SISTEMAS DE TIEMPO REAL

puede ocurrir que el tiempo de respuesta de las tareas no se cumpla como porejemplo en un sistema de tiempo real de adquisicion de datos.

Sistemas de tiempo real estricto (hard real-time systems), en los quees imperativo que las respuestas de las tareas se produzcan en el tiempo espe-cificado, ya que se puede producir una catastrofe si no ocurre de esta manera.Este puede ser el caso del control de vuelo de avion tripulado.

En ambos tipos de sistemas de tiempo real, normalmente el computador inter-actua directamente con algun componente fısico con el objetivo de monitorizar ocontrolar la operacion de este componente. En estos casos el computador tiene el rolde componente de procesado de informacion dentro de un sistema de ingenierıa masamplio. Por este motivo el computador en este tipo de aplicaciones se conoce comosistema empotrado. Este serıa el caso mayoritario para el que estarıan orienta-das las aplicaciones de las que este proyecto pretende ofrecer su infraestructura dedesarrollo.

Aunque estos tipos de sistemas de tiempo real de manera teorica se tenıan pen-sados para funcionar en separado, esto no es ası en todos los casos. De hecho, una delas caracterısticas de las aplicaciones, que se pueden disenar con la infraestructurapropuesta en este proyecto, es la de soportar en una misma arquitectura distintosniveles de criticidad. Ademas, este soporte se proporciona de manera que sea sencillade realizar la integracion de estos sistemas.

Generalmente, los sistemas de tiempo real, tambien, son mas rigurosos que otrotipo de sistemas en cuanto a los requisitos de fiabilidad y seguridad. Por ejemplo,una aplicacion de resolucion de algun problema matematico que falla puede serrazonable que se aborte su ejecucion. Esto en un sistema de tiempo real en generalno es algo aceptable. Por lo que el sistema de tiempo real tiene que ser tolerante afallos para asegurar estos requisitos. Esto no implica que se resuelvan todos los casosde error, que en la mayorıa de los sistemas es tarea imposible, sino que se abarqueen la medida de lo posible todas las soluciones que tiendan a aminorar los posiblesdanos derivados de un mal funcionamiento, que podrıan ser incluso perdida de vidashumanas. Por ejemplo, en el caso del fallo del sistema de control de vuelo de unavion militar que desemboque en que el avion se estrelle, el sistema de tiempo realdebe permitir al piloto poder eyectarse antes del choque.

Esta fiabilidad del sistema de tiempo real ha de ser la medida del exito con el queel sistema supera una especificacion autorizada de su comportamiento, para que sepueda certificar de manera cuantitativa. Esta especificacion, de manera ideal, deberıaser completa, consistente, comprensible y no ambigua, destacando en la misma paraeste tipo de sistemas la importancia de los tiempos de respuesta. Obviamente, comose ha podido intuir esta medida no asegurarıa que no va a haber fallos en el sistema.Pero si se puede asegurar que el sistema no va a tener fallos de comportamientodefinidos en la especificacion.

La fiabilidad, por lo tanto, se puede medir y asegurar que el sistema cumplelos requisitos de una cierta especificacion. Esto es un paso en garantizar esta ca-racterıstica en estos sistemas. Pero se puede seguir en este sentido de asegurar la

8

CAPITULO 2. ANTECEDENTES

fiabilidad mejorando la calidad del software, que lo compone, por construccion. Es-to se puede realizar mediante una serie de tecnicas que recogen la experiencia en eldesarrollo de sistemas de tiempo real, como son:

La especificacion rigurosa, si no formal, de requisitos

El uso de metodologıas de diseno probadas (por ejemplo, mediante metamo-delos)

El uso de herramientas de analisis para verificar las propiedades clave delsistema (tales como herramientas de medicion del peor tiempo de computo ode chequeo de los modelos)

El uso de lenguajes con facilidades para la abstraccion de datos y modularidad(por ejemplo, Ada o Java)

El uso de herramientas de ingenierıa del software que permitan el manejo delos componentes del sistema haciendo manejable su posible complejidad (porejemplo, herramientas de control de versiones o de control de cambios)

Este proceso asegurarıa ciertas especificaciones del sistema por construccion yse podrıan dar medidas de las mismas. Pero aun ası, este aspecto que es totalmentepreventivo en cuanto a los fallos que se podrıan eliminar es bastante limitado. Por loque se tiene que considerar tener en el sistema un robusto mecanismo de toleranciade fallos. En este sentido hay varios enfoques, entre los que destaca la redundanciade elementos en el sistema. Esta redundancia puede venir dada en los componentestanto hardware como software. Esto, obviamente, tiene un coste y en algunos casosno es solo el coste lo que imposibilita tener este tipo de nivel de tolerancia a fallos,por lo que en este sentido lo que se intenta en general es minimizar la redundanciamientras que se maximiza la fiabilidad. En cuanto a la redundancia software, quepueda ser menos obvia, se puede conseguir mediante tecnicas como la programacionde n-versiones de un mismo componente que ejecuten concurrentemente y el resul-tado de las diferentes versiones, comprendiendolas como un todo, se elija conformea unas reglas de decision del manejador del componente.

En las siguientes subsecciones se presentan otros aspectos a destacar de los siste-mas de tiempo real. Estos aspectos son la concurrencia, en cuanto a su programacion,y la planificacion en estos sistemas, la programacion de los mismos centrada en ellenguaje Ada y el perfil de Ravenscar [6], como soporte para proporcionar una seriede restricciones que da como resultado la reduccion a un subconjunto de operacionesque son permitidas.

2.1.1. Concurrencia

La concurrencia expresa el paralelismo que se da en la ejecucion de multiplestareas que pueden interactuar entre sı. Este aspecto es fundamental en los sistemas

9


de tiempo real, ya que deben dar mecanismos para poder llevar a cabo simultanea-mente operaciones que ejecutan en paralelo y que pueden tener dependencias entresı. Por ejemplo, un caso trivial de concurrencia serıa el acceso a un cierto dispo-sitivo, que maneje el sistema de tiempo real, por parte de una o mas tareas y alque solo puede tener acceso una unica tarea al mismo tiempo. Obviamente, en unaarquitectura monoprocesador solo se da la apariencia de este paralelismo puesto quesolo esta ejecutando una tarea al mismo tiempo. Pero en una arquitectura multipro-cesador este paralelismo se puede producir en la ejecucion si el sistema de tiemporeal ofrece mecanismos para esto.

La concurrencia en la construccion de un sistema es uno de los aspectos quehacen que su programacion sea compleja. Por tanto se ha de tener en cuenta esteaspecto para reducir lo maximo posible su uso, a casos en los que sea totalmentenecesario, buscando otras vıas de solucion para los problemas que se plantean.

En general hay tres principales motivaciones para tener que escribir programasconcurrentes:

Para modelar el paralelismo en el mundo real. En general, el sistema empotradotiene que interactuar con entidades del mundo real (robots, cintas transpor-tadoras, etc) que son inherentemente sistemas paralelos. Reflejar el caracterparalelo del sistema en las estructuras del sistema lo hace mas comprensible,mantenible y fiable.

Para utilizar al maximo el procesador. Los procesadores modernos ejecutana velocidades mucho mas altas que las velocidades de entrada/salida de losdispositivos con los que tienen que interactuar. Un programa secuencial queesta esperando por una operacion de entrada/salida no es capaz de realzarninguna otra operacion.

Para permitir a mas de un proceso resolver una operacion. Un programa se-cuencial solo puede ser ejecutado en un procesador (a menos que el compiladortransforme el programa en uno concurrente). Un programa concurrente es ca-paz de explotar el paralelismo real de las arquitecturas multiprocesador con elresultado de una ejecucion mucho mas rapida.

Desde el punto de vista de la concurrencia, la plataforma de ejecucion se puedeconsiderar irrelevante. Pero en algunos casos esta plataforma ha de ser consideradapara hacer un uso concurrente satisfactorio de la misma. Por ejemplo, es el casode aplicaciones para computacion de alto rendimiento en en el que es un requisitoobtener el maximo rendimiento de la plataforma. El objetivo ideal por tanto, enestos casos, es la creacion de tantas tareas como procesadores puesto que hay quetener en cuenta que la creacion de muchas mas tareas anade sobrecarga.

Desde un punto de vista teorico, la ley de Amdahl1 ofrece la relacion entreel speedup, o incremento de la velocidad, esperado en las implementaciones con

1Establece que ”la mejora obtenida en el rendimiento de un sistema debido a la alteracion deuno de sus componentes esta limitada por la fraccion de tiempo que se utiliza dicho componente”,http://es.wikipedia.org/wiki/Ley de Amdahl

10

http://es.wikipedia.org/wiki/Ley_de_Amdahl


paralelismo y secuenciales de un algoritmo. Si P es la proporcion del codigo delalgoritmo que se beneficia de la paralelizacion y N es el numero de procesadores, elmaximo speedup que se puede alcanzar usando estos N procesadores es:

1

(1− P) + PN

(2.1)

En el lımite, cuando el numero de procesadores, N, tiende a infinito, el speedupmaximo tiende a 1/(1 - P). En consecuencia, si unicamente el 50 % del sistema puedeser paralelizado, el maximo de speedup posible es solamente 2. Por lo que, no tienesentido tener 100 procesadores para realizar la ejecucion del sistema.

En cualquier caso, el speedup es un factor mas para decidir el uso de operacionesconcurrentes. Por lo tanto, aunque el numero de procesadores pueda ser limitado,hay todavıa ventajas en tener mas operaciones concurrentes que procesadores, comopuede ser la mantenibilidad del sistema por expresar el paralelismo del mundo realtal y como se interpreta.

Para la construccion de programas concurrentes se pueden destacar tres carac-terısticas que deben proveer los lenguajes de programacion (y el sistema operativo)usados. Estas son:

La expresion de operaciones concurrentes (mediante hilos, tareas2 o procesos)

Los mecanismos de sincronizacion entre operaciones concurrentes

Las primitivas de comunicacion entre operaciones concurrentes

En la interaccion entre tareas, es util distinguir entre tres tipos de comportamien-to: independiente, cooperativo y competitivo. En el comportamiento independientede las tareas, estas no se comunican o sincronizan entre ellas. En el comportamientocooperativo, estas se comunican y se sincronizan para realizar alguna operacion encomun. Y, por ultimo, en el comportamiento competitivo estas, aunque tambien secomunican y se sincronizan entre ellas con el objetivo de obtener acceso, en general,a los recursos limitados de la plataforma en la que ejecutan, son independientes entresı.

En la seccion 2.1.3 se continua describiendo el aspecto de la concurrencia en lossistemas de tiempo real, pero desde el caso concreto del lenguaje Ada. Esto es puestoque, hay mas generalidades en el aspecto de la concurrencia en las que se podrıaextender esta descripcion pero no es el objetivo y sı, en cambio, el describir estosaspectos desde el punto de vista de este lenguaje que es al que da soporte el kernelde tiempo real ORK+.

2Aunque, en el presente documento los terminos de hilo y tarea son usados indistintamente pararepresentar un unico hilo de ejecucion

11


2.1.2. Planificacion

En un programa concurrente, en principio, no es necesario especificar el ordenexacto en el que las tareas ejecutan. Esto es puesto que este orden se puede fijar,de manera que se mantenga la consistencia del programa concurrente, mediantelos mecanismos de sincronizacion, como puede ser la exclusion mutua. Pero estoimplica que el comportamiento del programa es no determinista en cuanto al aspectotemporal, aunque las salidas funcionales del programa sean correctas.

Un sistema de tiempo real necesita restringir el comportamiento no determinis-ta que se encuentra en los sistemas concurrentes. Esta actividad se conoce comoplanificacion y en general sus esquemas proporcionan dos caracterısticas:

Un algoritmo para ordenar el uso de los recursos del sistema

Un metodo para predecir el peor caso de comportamiento del sistema cuandose aplica el algoritmo de planificacion

Con lo que, estas predicciones se pueden usar para confirmar que se satisfacenlos requisitos temporales del sistema.

Los esquemas de planificacion se clasifican en estatico(si las decisiones son to-madas antes de la ejecucion) y dinamico(si las decisiones se toman en tiempo deejecucion). La descripcion de los mismos, en este documento, se centra en los es-quemas de tipo estatico y con mas atencion en el esquema de prioridades fijas condesalojo, que es el esquema usado mas extensamente.

El ejecutivo cıclico

Este es el esquema, de tipo estatico, tradicional de planificacion en los sistemasde tiempo real. En este esquema solo se permite ejecutar tareas periodicas, de modoque se dificulta la incorporacion de tareas esporadicas. El ejecutivo cıclico es esen-cialmente una tabla de llamadas a procedimientos, donde cada uno representa laparte del codigo que realiza una cierta tarea. Por lo tanto, el ejecutivo cıclico per-mite construir una planificacion, para una serie de tareas periodicas, que se repitepara que cada tarea ejecute con el periodo determinado. La tabla completa es co-nocida como el ciclo principal y se divide en un conjunto de ciclos secundarios,de modo que la duracion del ciclo principal es proporcional a la duracion de cadaciclo secundario. Para construir la planificacion es necesario conocer el tiempo decomputo requerido por cada procedimiento.

Para ilustrar el enfoque de esta planificacion, a continuacion, se expone un ejem-plo en el que se tienen cuatro ciclos secundarios de 25ms de duracion que implicanun ciclo principal de 100 ms. Durante la ejecucion, un reloj que interrumpe cada25 ms permite al planificador elejir el conjunto de procedimientos a ejecutar en elciclo correspondiente. En la tabla 2.1 se muestra el conjunto de tareas que debe serejecutado segun un plan, con una posible distribucion como la que se muestra en lafigura 2.1.

12


Tarea Periodo, T Tiempo de computo, Ca 25 10b 25 8c 50 5d 50 4e 100 2

Cuadro 2.1: Conjunto de tareas del ejecutivo cıclico

Interrupción Interrupción Interrupción Interrupción

Tiempo

a b c a b d e a b c a b d

Ciclo secundario

Ciclo principal

Ciclo secundario Ciclo secundario Ciclo secundario

Figura 2.1: Plan cıclico para el conjunto de tareas

Si es posible la construccion del plan aseguras que la planificacion es correctay no son necesarias mas pruebas de planificacion. Sin embargo, en algunos casos,como sistemas de gran utilizacion, la construccion de un plan es muy problematica.El problema es analogo al problema “bin packing” que es un problema NP-completo,con lo que no es factible computacionalmente. Por lo que de manera general se hade resolver mediante esquemas heurısticos.

Las caracterısticas importantes de este enfoque de planificacion, son:

En tiempo de ejecucion no existe el concepto de tarea actual; cada ciclo se-cundario es simplemente una secuencia de llamadas a procedimientos

Los procedimientos comparten un espacio de direcciones comun con lo quepueden compartir datos entre los mismos. Estos datos no necesitan ser pro-tegidos (vıa semaforos, por ejemplo) puesto que el acceso concurrente no esposible

Todos los periodos de las ‘tareas’ deben ser un multiplo del tiempo del ciclosecundario

Por otro lado, las desventajas de este enfoque son:

La dificultad de incorporar tareas esporadicas, que se tendrıa que realizar atraves de una tarea periodica que realice la consulta del evento que las activa

13


La dificultad de incorporar tareas con largos periodos de tiempo que sobrepa-sen el tiempo del ciclo principal; esto es ası porque o bien se divide la tarea,con la complicacion inherente, o bien se tiene una planificacion secundariacon la que cada N ciclos principales se realice la llamada al procedimientocorrespondiente

La dificultad de construir los planes de ejecucion cıclicos

Planificacion basada en tareas

A diferencia de la planificacion mediante el ejecutivo cıclico, en este caso, enejecucion si se tiene el concepto de tarea actual y se determina que tarea, entretodas, deberıa ejecutar segun uno o mas atributos de planificacion.

En este marco de planificacion, el estado de las tareas, asumiendo que no hayinteraccion entre ellas, puede ser ejecutable (la tarea puede ser ejecutada), suspen-dida esperando por un evento periodico (estado propio de las tareas periodicas) ysuspendida esperando un evento no periodico (estado propio de las tareas esporadi-cas).

En este sentido, se van a apuntar dos metodos de planificacion: uno estatico, comoes el metodo de planificacion con prioridades fijas (o Fixed Priority Scheduling(FPS)), y otro dinamico, como es el metodo de planificacion de el primero el masurgente (o Earliest Deadline First (EDF)).

Para la valoracion de dicho metodos hay un numero importante de caracterısti-cas, entre las que destacan la suficiencia y la necesidad:

Una condicion de planificacion se define como suficiente si un resultado po-sitivo garantiza que todos los plazos se cumplen

Una condicion puede ser tambien valorada como necesaria si el fallo de lacondicion implica una perdida del cumplimiento del plazo en algun puntodurante la ejecucion del sistema

Una condicion suficiente y necesaria es exacta y, por lo tanto, en algun sentidooptima. Una condicion suficiente pero no necesaria es pesimista, pero para muchassituaciones una condicion exacta no es posible llevarla a cabo. Desde un punto devista ingenieril una condicion que se pueda llevar a cabo y que sea suficiente aunquecon un poco de pesimismo es ideal.

Si la planificacion de las tareas se lleva a cabo mediante asignacion de priorida-des, puede ocurrir que durante la ejecucion una tarea con una prioridad alta se veadesalojada por una tarea de menor prioridad. Por eso a este esquema de planificacionse le une el esquema de planificacion con desalojo. En el esquema con desalojohay siempre un cambio inmediato a la tarea con mayor prioridad que este en estadode ejecutable. Ademas, entre el esquema de planificacion con desalojo y sin el hayalternativas en las que se permite ejecutar a la tarea de menor prioridad por un

14


tiempo limitado, pero no necesariamente hasta que termine, como puede ser el es-quema de planificacion con desalojo diferido. El esquema de planificacion EDF,tambien se puede dar con el esquema anadido del desalojo.

Estos esquemas de planificacion, al contrario que en el esquema del ejecutivocıclico, permiten la concurrencia en la ejecucion de los sistemas. Un programa conuna concurrencia compleja y arbitraria es un programa que no se puede analizar parapredecir su peor caso de comportamiento. Por lo tanto, en el diseno de programaspara sistemas de tiempo real es necesario imponer una serie de restricciones en suestructura. Para esto se dispone de modelos que describen los estandares de losesquemas de planificacion. En este sentido se presenta en este documento el modeloestandar simple de tareas para su planificacion, que se ampliara en cada esquemadescrito:

Se asume que la aplicacion consiste en un conjunto fijo de tareas

Todas las tareas son periodicas y sus periodos son conocidos

Las tareas son completamente independientes entre ellas

Todas las sobrecargas, tiempos de cambio de contexto y demas, son ignoradaso se asume que tienen un coste cero

Los plazos de respuesta de todas las tareas son iguales a sus periodos (quequiere decir que cada tarea debe completarse antes de la siguiente activacion)

El peor tiempo de computo de todas las tareas esta determinado

Ninguna tarea contiene puntos de suspension interno (es decir, por ejemplouna sentencia de bloqueo por una peticion de E/S)

Todas las tareas ejecutan en un unico procesador

La notacion estandar para los modelos de planificacion se incluye en la tabla 2.2:

Notacion DescripcionB Peor caso de tiempo de bloqueo para la tarea (si aplica)C Peor caso de tiempo de computoD Tiempo de respuesta de la tareaI Tiempo de interferencia de la tareaJ Tiempo de puesta en ejecucion de la tareaN Numero de tareas en el sistemaP Prioridad asignada a la tarea (si aplica)R Peor caso de tiempo de respuesta de la tareaT Periodo de la tareaU Utilizacion del procesador de la tarea (igual a C/T)

Cuadro 2.2: Notacion estandar para los modelos de planificacion

15


Como se puede ver el modelo basico de planificacion tiene restricciones que sonincluso irrazonables de considerar. Aun ası se incluye para que se pueda ver la basedesde la que se parte para los esquemas que se van a ir describiendo a continuacion.Y durante esta descripcion, que se centra mas en el esquema FPS, se ira modificandopara indicar los modelos de los que se hace uso en las distintas estrategias.

En la descripcion de los metodos de planificacion que se muestra a continuacion,los puntos clave son los criterios por los cuales se valida la planificacion paraun cierto sistema y los esquemas que ofrecen para la asignacion de prioridades.

Planificacion FPS

La planificacion con prioridades fijas es el enfoque mas utilizado e imple-mentado por los sistemas de tiempo real. Por esto es el metodo de planificacionque se describe con mas detalle en este documento. La asignacion de prioridadesse realiza en tiempo de diseno, por esto el metodo se describe como estatico. Estaasignacion se realiza de manera que las tareas, que estan en estado de ejecutables,se ejecutan en el orden determinado por las prioridades asignadas.

Para el modelo simple de tareas hay una asignacion de prioridades que es optima,que es el esquema conocido como asignacion de prioridades monotonas en frecuen-cia. Con este modelo se asigna mayor prioridad a las tareas de menor periodo (ratemonotonic scheduling); para dos tareas i y j, Ti < Tj ⇒ Pi > Pj) y es optimo en elsentido de que si una asignacion de prioridades existe y es factible para un conjuntode tareas, la asignacion de prioridades monotonas en frecuencia es tambien factiblepara ese mismo conjunto de tareas [12]. Por lo tanto se tiene una asignacion deprioridades que es optima para un modelo con algunas restricciones, ya que es paraun modelo simple de tareas, como que se ha de cumplir que T = D.

Este esquema de asignacion de prioridades, como se intuye, es limitado ya quees optimo unicamente para un modelo de tareas simple. En general el modelo detareas es mas complejo, permitiendo que los tiempos de respuesta sean menoresque el periodo de las tareas y que se puedan incluir tareas esporadicas en elmodelo. Por lo tanto, se tiene otro esquema, conocido como asignacion de prioridadesmonotonas en plazos, que establece, para un modelo general de tareas, que “cuandolos plazos de respuesta son menores o iguales a los periodos, la asignacion de mayorprioridad a las tareas de menor plazo de respuesta (deadline monotonic scheduling ;para dos tareas i y j, Di < Dj ⇒ Pi > Pj) es optima”.

Para validar la planificacion existen distintas condiciones que segun el modelopueden garantizar los plazos de las tareas.

De este modo, para un modelo simple de tareas, con una asignacion de prioridadesmonotonas en frecuencia, se garantizan los plazos, mediante la condicion basada

16


en la utilizacion, si:

U =N∑i=1

Ci

Tj≤ N(21/N − 1) [12] (2.2)

El valor U0(N) = N(21/N−1) es la utilizacion mınima garantizada. Este valorvarıa desde el 100 % hasta aproximadamente el 69.3 %, en el lımite limn→∞Uo(N) =log2. Por lo tanto cualquier conjunto de tareas, de este tipo, con una utilizacionmenor del 69,3 % siempre sera planificable por un esquema basado en prioridades condesalojo asignadas mediante el algoritmo de asignacion de prioridades monotonasen frecuencia.

El problema de este analisis, basado en el factor de utilizacion del procesador,es que su condicion no es exacta y como se ha comentado no se puede generalizar amodelos de tareas mas complejos. Pero, en cambio, es un analisis eficiente con unacomplejidad O(N).

Como se ha visto este metodo de analisis tiene su utilidad, pero a su vez tieneimportantes carencias. Por lo tanto se introduce otro metodo que sı proporciona unacondicion exacta, es decir, suficiente y necesaria, para garantizar los plazos y que,ademas, es facil de generalizar a otros modelos de tareas. Este metodo es el analisisdel tiempo de respuesta (o Response time analysis (RTA)). Otra ventaja es quepermite un analisis del comportamiento temporal del sistema mas exacto que laprueba del factor de utilizacion. Por otro lado, se tiene que tener en cuenta que hayun elemento crıtico. Este es el calculo del tiempo de computo de cada tarea, de modoque, si es optimista, los plazos pueden fallar aunque el analisis sea positivo, y si espesimista, el analisis puede ser negativo aunque los plazos no fallen en realidad.

Este metodo trata de calcular el tiempo de respuesta en el peor caso de cadatarea, Ri, y comprobar directamente que es menor que el plazo correspondiente(Ri ≤ Di). Si es ası para todas las tareas (∀iRi ≤ Di) se garantiza el cumplimientode los plazos.

El tiempo de respuesta de una tarea, de manera general, es la suma de su tiempode computo mas la interferencia que sufre por la ejecucion de tareas mas prioritarias.Por lo tanto, la formula general del calculo del tiempo de respuesta es:

Ri = Ci + Ii (2.3)

La interferencia que una tarea i puede sufrir depende del numero de veces quelas tareas de mayor prioridad se ejecutan durante el intervalo [0,Ri) y su tiempo decomputo.

Una tarea de prioridad superior j se ejecuta durante el intervalo [0,Ri) un numerode veces igual a: ⌈

Ri

Tj

⌉(2.4)

17


Por tanto, el valor de la interferencia de la tarea i sobre la tarea j es:

Iji =

⌈Ri

Tj

⌉Cj (2.5)

El valor de la interferencia total sobre una tarea i, sera la suma de las interfe-rencias de las tareas de mayor prioridad, como se expresa en la siguiente ecuacion:

Ii =∑

j∈hp(i)

⌈Ri

Tj

⌉Cj (2.6)

Donde hp(i) es el conjunto de tareas de mayor prioridad que i (higher-priority).Sustituyendo en la ecuacion de la formula general del calculo de tiempo de respuesta,se tiene:

Ri = Ci +∑

j∈hp(i)

⌈Ri

Tj

⌉Cj (2.7)

Pero como se puede observar, esta ecuacion no es lineal(El termino que se quierecalcular, es termino tambien para realizar el calculo) por lo que no se puede resolveranalıticamente. Aunque, es un ejemplo de ecuacion de punto fijo, por lo que unaforma sencilla de resolverla es mediante una relacion de recurrencia, de la siguientemanera [3]:

wn+1i = Ci +

∑j∈hp(i)

⌈wn

i

Tj

⌉Cj (2.8)

Esta sucesion w0i , w

1i , ..., w

ni , ... es monotona decreciente. Un valor inicial para la

misma aceptable es w0i = Ci y converge siempre que U < 100 %. Esta sucesion se

termina cuando:

wn+1i = wn

i , con lo que Ri = wni

wn+1i > Ti, con lo que se determina que no se cumple el plazo

Planificacion EDF

La planificacion de el primero el mas urgente o EDF es un tipo de planificaciondinamica. Esta planificacion, aunque tiene muchas caracterısticas que lo hacen casitan importante como la planificacion FPS, actualmente esta menos soportada porlos sistemas de tiempo real, como es el caso del sistema de tiempo real ORK+. Poresta razon esta planificacion se va describir de manera mas breve.

Con este esquema, las tareas que estan en estado de ejecutables se ejecutan en elorden determinado por sus tiempos de respuesta absolutos, de manera que ejecuteaquella con el tiempo mas corto. Aunque los tiempos de respuesta, normalmente, seconocen de antemano, los tiempos de respuesta absolutos se determinan en tiempo

18


de ejecucion. Por este motivo este mecanismo de planificacion se describe comodinamico.

En este caso el factor de utilizacion, para un modelo que permite tareas periodicasy esporadicas independientes entre sı y con Di = Ti, garantiza los plazos si y solo si:

U =N∑i=1

Ci

Tj≤ 1 (2.9)

Como se puede observar este analisis es mucho mas simple que el correspondientepara la planificacion FPS. Siempre y cuando la utilizacion del conjunto de tareassea menor que la capacidad total del procesador, todos los tiempos de respuestase garantizan (para el modelo de tareas indicado). En este sentido el metodo deplanificacion EDF es superior al metodo FPS, siempre que se pueda planificar unsistema con FPS se puede planificar con EDF, pero no al contrario. Por lo tanto cabepreguntarse cuales son las caracterısticas que lo situan en una posicion de desven-taja con respecto al metodo FPS. Entre otras, destacan que la planificacion es mascomplicada de realizar (el nucleo de multiprogramacion es mas complejo, ademas,se anade sobrecarga por la realizacion de los calculos en tiempo de ejecucion), sucomportamiento es imprevisible en caso de que se produzcan sobrecargas (con FPSfallan antes las tareas de menor prioridad) y requiere que todas las tareas tenganplazos asignados (FPS es mas flexible en este sentido).

Interaccion entre tareas con planificacion FPS

Hasta este punto en los modelos de tareas que se han presentado se asume que lastareas son independientes. Esto obviamente no es razonable, ya que en la mayorıade sistemas de interes practico las tareas interaccionan entre sı. Se proporcionanmecanismos de comunicacion ya sea mediante alguna forma de compartir datosprotegidos (como por ejemplo, semaforos, monitores u objetos protegidos) o direc-tamente (mediante paso de mensajes como por ejemplo usando rendezvous). Conestos mecanismos es posible que las tareas puedan ser suspendidas hasta que se pro-duzca algun evento que se produzca por la interaccion de otra tarea (por ejemplo,esperando por obtener acceso a un semaforo).

Como se ha apuntado una tarea, en un modelo de tareas en el que se permiteinteraccion entre ellas, puede quedarse suspendida a la espera de un evento. Sieste evento se produce por una tarea menos prioritaria se produce una situacionde bloqueo, que hasta este punto, contraviene el esquema de planificacion FPScon desalojo. En un esquema ideal de planificacion, mediante este metodo, estainversion de prioridad [13] no deberıa existir. Pero, puesto que puede suceder (yde hecho sucede) que se produzca una inversion de prioridad, hay que minimizar suimpacto ya que no es posible eliminarlo. Para asegurar que su impacto es el mınimo,se tiene que poder medir el bloqueo producido y limitarlo. En la figura 2.2 se muestraesta situacion indeseable de inversion de prioridad, con una secuencia de ejecucionque se muestra en la tabla 2.3.

19


Tarea Prioridad Secuencia de ejecucion Tiempo de comienzoa 1 EQQQQE 0b 2 EE 2c 3 EVVE 2d 4 EEQVE 4

Cuadro 2.3: Secuencia de ejecucion para el caso de inversion de prioridad

0 2 4 6 8 10 12 14 16 18

Desalojada

d

c

b

a

Tareabloqueo

Bloqueada

Ejecutando con acceso a Q

Ejecutando

Ejecutando con acceso a V

Figura 2.2: Inversion de prioridad

Como se puede ver en la figura 2.2 la tarea d, que es la tarea mas prioritaria,queda bloqueada por todas las demas tareas, por el acceso a la seccion de datoscompartida Q. Obviamente, no es posible evitar todo el bloqueo puesto que se debemantener la integridad del acceso a la seccion crıtica, que obtiene en primer lugar latarea a. Pero el bloqueo producido por las demas tareas no beneficia en nada y afectaa la planificacion del sistema de manera grave. La inversion de prioridades no es soloun problema teorico, sino que es un problema que ha ocurrido en sistemas realesocasionando su mal funcionamiento. Uno de los casos mas conocidos es el del vehıculorobotico de la NASA, Mars Pathfinder3. El error se soluciono activando la herenciade prioridad, que afortunadamente era soportada por el sistema operativo delvehıculo.

La herencia de prioridad es una forma de reducir la duracion de los bloqueos va-riando dinamicamente la prioridad de las tareas. Cuando una tarea esta bloqueandoa otra mas prioritaria hereda la prioridad de esta. Por lo que la prioridad dinamicade una tarea es el maximo de su prioridad basica y de las prioridades de todas lastareas bloqueadas por ella. La herencia de prioridad ademas es transitiva, de modoque, si la tarea d esta esperando por el bloqueo de la tarea c, pero la tarea c nopuede desbloquear la tarea d porque esta esperando por el bloqueo de la tarea b

3Ver http://research.microsoft.com/en-us/um/people/mbj/Mars Pathfinder/Mars Pathfinder.html

20

http://research.microsoft.com/en-us/um/people/mbj/Mars_Pathfinder/Mars_Pathfinder.html


entonces tanto la tarea b como la c obtienen la prioridad de la tarea d. Un ejemplode este comportamiento dinamico de la planificacion se muestra en la figura 2.3.

0 2 4 6 8 10 12 14 16 18

Desalojada

d

c

b

a

Tarea

Bloqueada


Ejecutando


Figura 2.3: Ejemplo de herencia de prioridad

Con este protocolo, una tarea se puede bloquear como maximo una vez por cadaseccion crıtica a la que accede una tarea de prioridad inferior [11]. Por lo tanto laduracion total maxima de los bloqueos es:

Bi =K∑k=1

u(k, i)C(k) (2.10)

Donde u es una funcion que toma el valor 1 si al menos una tarea con menorprioridad que Pi y al menos una tarea con una prioridad mayor o igual a Pi hacenuso del recurso k, sino toma el valor 0. C(k) es el peor caso de tiempo de computode la seccion crıtica por parte de la tarea i.

Teniendo en cuenta que se puede calcular el tiempo de bloqueo, se puede modi-ficar el algoritmo del calculo de tiempo de respuesta para anadir los bloqueos. Deesta manera la ecuacion queda como se muestra:

Ri = Ci +Bi +∑

j∈hp(i)

⌈Ri

Tj

⌉Cj (2.11)

Que se resuelve mediante la relacion de recurrencia siguiente:

wn+1i = Ci +Bi +

∑j∈hp(i)

⌈wn

i

Tj

⌉Cj (2.12)

Es de notar que este calculo puede ser ahora pesimista, puesto el maximo bloqueodepende del desfase de ejecucion de las tareas.

Por lo tanto, se proponen otros protocolos, conocidos como protocolos de techode prioridad, que intentan que el calculo sea menos pesimista evitando los bloqueostransitivos. En este documento se consideran dos de ellos: el protocolo del techo

21


de prioridad original (o Ceiling Priority Protocol (CPP)) y el protocolo deltecho de prioridad inmediato (o Inmediate Ceiling Priority Protocol (ICPP))

En el protocolo del techo de prioridad:

Cada recurso tiene un valor de techo definido, esto es la prioridad maxima delas tareas que pueden usarlo

Cada tarea tiene tiene una prioridad dinamica que es el maximo de su prioridadestatica y cualquiera que herede debido al bloqueo que produzca en una tareade mayor prioridad

Una tarea solo puede usar un recurso si su prioridad dinamica es mayor queel techo de todos los recursos en uso por otras tareas

Cuando se usa el protocolo del techo de prioridad en un sistema monoproce-sador:

Cada tarea se puede bloquear una vez, como maximo, en cada ciclo

No puede haber interbloqueos

No puede haber bloqueos encadenados

Consecuentemente, la duracion maxima del bloqueo pasa a ser ahora:

Bi =K

maxk=1

u(k, i)C(k) (2.13)

La ventaja de este protocolo es que una tarea de prioridad alta puede ser blo-queada solamente una vez por activacion por cualquiera de las tareas de menorprioridad. La desventaja de esto es que habra mas tareas que se veran afectadas poreste bloqueo. En la figura 2.4 se muestra un ejemplo del comportamiento de esteprotocolo.

0 2 4 6 8 10 12 14 16 18

Desalojada

d

c

b

a

Tarea

Bloqueada


Ejecutando


Figura 2.4: Ejemplo del protocolo de techo de prioridad

22


Como se puede ver la tarea a obtiene acceso a la seccion crıtica Q. Esta tareaes desalojada por la tarea c, pero en este caso cuando intenta obtener acceso a laseccion crıtica V no puede puesto que su prioridad (3) es menor que el techo deprioridad en ese momento (que es 4, puesto que se ha obtenido acceso al recurso Qy este es usado por la tarea d). La ecuacion indica que las tareas pueden sufrir unmaximo de 4 en la duracion de los bloqueos, aunque como se muestra las tareas b yc sufren un bloqueo de 3 y la tarea d solo de 2.

Sobre este protocolo se realiza una modificacion para obtener el protocolo deltecho de prioridad inmediato. Se consigue un protocolo mas facil de realizar, ya queno hay que monitorizar las relaciones de bloqueo, y que produce menos cambioscambios de contexto, puesto que el bloqueo se produce antes de la ejecucion de latarea. En cambio se producen mas cambios de prioridad, debido a que se heredainmediatamente el techo de prioridad aunque no haya bloqueo, pero este hechoes practicamente irrelevante.

En este sentido en el protocolo la prioridad dinamica de una tarea es el maximode su prioridad basica y los techos de prioridad de los recursos que usa. Presenta lasmismas propiedades que el protocolo de techo de prioridad basico y anade una mas,si una tarea se bloquea lo hace al principio del ciclo.

La duracion maxima del bloqueo es la misma que para el protocolo CPP. En lafigura 2.5 se muestra un ejemplo del comportamiento de este protocolo.

0 2 4 6 8 10 12 14 16 18

Desalojada

d

c

b

a

Tarea

Bloqueada


Ejecutando


Figura 2.5: Ejemplo del protocolo de techo de prioridad inmediato

2.1.3. Programacion en Ada

Ada es un lenguaje de programacion de alto nivel especialmente orientado para eldesarrollo profesional de programas crıticos para los cuales la fiabilidad y la robustezson consideraciones fundamentales. Fue disenado bajo encargo del Departamento deDefensa de los Estados Unidos en el ano 1974. Con este proyecto se esperaba reducirlos costes de produccion de software que estaba siendo bastante alto especialmentepara el uso en sistemas empotrados.

23


El lenguaje esta enfocado a ser usado mediante metodos de ingenierıa del soft-ware, de este modo, resuelve dos problemas inherentes: la necesidad de reusar loscomponentes software desarrollados lo maximo posible y la necesidad de estable-cer tecnicas de trabajo disciplinadas. Por lo que se presenta como un lenguaje quepermite reducir el coste del desarrollo de software y su posterior mantenimiento.

La principal razon de su fiabilidad es su fuerte tipado y las caracterısticas rela-cionadas con este, que hacen que los programas escritos en Ada sean mas robustos.Esto es ası puesto que la mayorıa de los errores se detectan en tiempo de compilaciony del resto la mayorıa son detectados mediante restricciones en tiempo de ejecucion.

Desde el punto de vista de la programacion proporciona multiples facilidadesentre las que en este documento se destacan la concurrencia, la interaccion entretareas y la planificacion, en su anadido para sistemas de tiempo real. Estos aspectosse muestran dando una breve descripcion y poniendo ejemplos, cuando se considerenecesario para aclarar mejor los conceptos.

En Ada la unidad de paralelismo se denomina tarea. El lenguaje ofrece soportepara la declaracion, creacion y destruccion de tareas.

Las tareas pueden ser declaradas en cualquier nivel del programa, son creadasimplıcitamente a la entrada del ambito de su declaracion. A continuacion se muestraun ejemplo que ilustra la declaracion de una tarea contenida en un procedimiento:

1 procedure Ejemplo;task A;task body A is−− Declaraciones locales a la tarea A

begin6 −− Secuencia de acciones de la tarea A

end A;begin−− La tarea A comienza su ejecucion antes de la primera−− accion del procedimiento Ejemplo

11

−− Secuencia de acciones del procedimiento Ejemploend Ejemplo;

Las tareas como se muestra constan de una especificacion y de un cuerpo queimplementa dicha especificacion. De este modo se pueden crear tipos de tareas quepermitan crear facilmente numerosas instancias. Un ejemplo de la creacion de untipo de tareas y su instanciacion se muestra en este fragmento de codigo:

task type T;2 A, B : T;

task body T is ...

24


Por otro lado cualquier tarea puede abortar a otra tarea cuyo nombre este en suambito. Cuando una tarea es abortada, todas sus dependencias son tambien abor-tadas. Este mecanismo ofrece una forma de abortar tareas que esten teniendo uncomportamiento indeseable por el sistema pero a su vez, como es obvio, es un me-canismo muy peligroso que se deberıa usar cuando no hay otra alternativa.

Ada proporciona tambien mecanismos para la interaccion entre tareas, de maneraque la concurrencia del sistema quede asegurada. Entre estos mecanismos, parael ambito de los sistemas de tiempo real destacan los objetos protegidos. Adaes el unico lenguaje que provee este mecanismo que permite encapsular datos ypermitir acceso a los mismos a traves de subprogramas o puntos de entrada delobjeto protegido. El lenguaje garantiza que estos accesos se producen de maneraque se asegura que los datos son actualizados en condiciones de exclusion mutua.La condicion de sincronizacion se provee a traves de expresiones en los puntos deentrada (guardas que en Ada se denominan barreras) que deben evaluarse comoverdaderas antes de que una tarea acceda al objeto protegido. Al igual que las tareaslos objetos protegidos constan de una especificacion y un cuerpo que la implementa.Su especificacion puede contener funciones, procedimientos y entradas. De igualmanera se pueden declarar tipos de objetos protegidos e instanciar tantos como sequiera. En el siguiente fragmento de codigo se ilustra un ejemplo de la declaracionde un objeto protegido para proveer un mecanismo para compartir un dato de tipoentero entre tareas de manera que se garantice la exclusion mutua.

1 protected type Entero Compartido ( Valor Inicial : Integer ) isfunction Leer return Integer ;procedure Write (Nuevo Valor : Integer );procedure Incrementar (Incremento : Integer );

private6 Datos : Integer := Initial Value ;

end Entero Compartido;

Los procedimientos tienen el mismo comportamiento que las entradas, en cuantoa la exclusion mutua que ofrecen, pero no ofrecen sincronizacion. Las funciones pro-veen acceso solo de lectura a los datos del objeto protegido. Ada provee exclusionmutua para el acceso entre procedimientos y entradas, de modo que si se esta eje-cutando el codigo de una entrada o un procedimiento no puede ejecutarse ningunotro. Tambien se garantiza la exclusion mutua con las funciones. Esto es que unallamada a una funcion no puede comenzar hasta que se termine la ejecucion de unprocedimiento o entrada y la ejecucion de un procedimiento o entrada no puedecomenzar si hay una o mas llamadas concurrentes a una funcion.

Ada esta definido de tal manera que se tiene el lenguaje como un nucleo al quese le anaden una serie de anexos para adaptarlo a dominios de aplicacion especıficos.Este es el caso de los sistemas de tiempo real para los que se provee un anexo queno anade nuevas caracterısticas del lenguaje (en el sentido de nueva sintaxis) pero

25


donde se definen directivas al compilador y bibliotecas que deben implementarse sise quiere ofrecer el servicio y la funcionalidad requerida. Este anexo es el Anexo Ddel manual de referencia y en este se describen los servicios que se han de proveer yla funcionalidad que se ha mantener en los sistemas de tiempo real. A continuacionse describen estos anadidos, destacando el aspecto al que se refieren:

Prioridad de las tareas. El lenguaje proporciona la instruccion PragmaPriority y Pragma Interrupt Priority , que permite asignar un valor de priori-dad a las tareas, objetos protegidos y subprogramas. El valor de prioridadpor defecto ası como los rangos de prioridades permitidos por el sistema seencuentran en el paquete System.

Planificacion. Se puede determinar las reglas que seguira el sistema a la horade decidir que tarea se ejecutara, en el caso de que haya conflicto entre varias.La opcion activada por defecto es la de FIFO Within Priorities, se activara latarea mas prioritaria y si hay dos con la misma prioridad, la que ha llegadoen primer lugar.

Protocolo de techo de prioridad. Permite seleccionar entre los distintosprotocolos de tratamiento de la prioridad de una tarea cuando se acceda aun objeto protegido. El elegido por defecto es el protocolo Ceiling Locking, esdecir, el protocolo de techo de prioridad inmediato.

Protocolos de encolado. El programador esta facultado para cambiar elalgoritmo utilizado para ordenar las tareas que han quedado bloqueadas en labarrera de una entrada de un objeto protegido, pudiendo ordenarlas por ordende llegada o por prioridad.

Prioridades dinamicas. El lenguaje tambien proporciona una funcionalidadpara variar el valor de prioridad de las tareas mientras se esta ejecutando. Estoes muy util, sobre todo para la planificacion con prioridades dinamicas (EDF).

Prioridad de aborto. La instruccion de abortar la ejecucion de una tareapuede ser completada inmediatamente, o puede dejar que termine la instruc-cion que ha provocado dicha terminacion. El anexo de tiempo real permiteelegir entre las opciones.

Tiempo. Se dispone de un paquete con un reloj monotono y de alta resolucion,que sera el usado en los sistemas de tiempo real, ası como herramientas parasu manejo.

Precision de la instrucciones delay. Permite ajustar la finura con la quese ejecutan las instrucciones delay y delay until .

Transferencia sıncrona y asıncrona de control. Ofrece mecanismos parasuspender o reanudar tareas sıncrona o asıncronamente.

26


Tiempo de ejecucion Funcionalidades para controlar los tiempo de ejecu-cion de las tareas, permitiendo el uso de temporizadores. Tambien se ponendisponibles temporizadores de tiempo de ejecucion para los manejadores deinterrupcion. Otra caracterıstica importante es la de asignar una cuota detiempo de ejecucion ha un grupo de tareas para que lo compartan.

Eventos Temporizados Se pone a disposicion un paquete para permitir laejecucion de procedimientos protegidos definidos por el usuario en un instantede tiempo definido sin la necesidad de utilizar tareas o sentencias delay.

Restricciones al modelo de tareas. El modelo de tareas de Ada puede noresultar adecuado para ciertos sistemas de tiempo real, en caso que se necesiteun mayor grado de determinismo. Es por ello, que se pueden instaurar ciertasrestricciones en dicho modelo. Un claro ejemplo del uso de estas restriccioneses el Perfil de Ravenscar, del que hablaremos a continuacion.

El perfil de Ravenscar

Uno de los mas significativos logros del International Real-Time Ada Workshop(IRTAW) fue la definicion de un subconjunto del modelo de tareas del lenguajeAda para el uso en sistemas de tiempo real de alta integridad. Este modelo fuedenominado perfil de Ravenscar, ya que fue en el pequeno pueblo de Ravenscar(Yorkshire) donde se celebro la reunion. En las posteriores ediciones del IRTAW, sediscutio y se anadieron nuevas caracterısticas al modelo, hasta que en la 11a edicionse formulo la definicion formal.

El perfil de Ravenscar es una coleccion de restricciones dirigida al desarrollo deaplicaciones que requieren implementaciones muy eficientes o que tienen requisitosde alta integridad, o ambas. Provee las caracterısticas del lenguaje Ada mınimaspara el desarrollo de aplicaciones basadas en el esquema de prioridades fijas.

Este perfil ha de ser soportado por el nucleo de tiempo real que quiera proveer lasrestricciones que aporta. Obviamente, podrıa ser muy util tener para cada aplicacionun sistema que estuviese totalmente ajustado a sus necesidades. Puesto que esto, esuna tarea difıcil, por no decir imposible, el lenguaje define una serie de restriccionesque el sistema de tiempo real deberıa reconocer para ofrecer el soporte requerido.Sobre estas restricciones se basa este perfil, ajustando sus valores para proporcionarel ajuste necesario. Las restricciones se comprueban en la fase de compilacion.

El perfil de Ravenscar se puede forzar con la siguiente directiva al compilador:

pragma Profile (Ravenscar);

Esto es equivalente al siguiente conjunto de directivas al compilador:

pragma Task Dispatching Policy ( FIFO Within Priorities );pragma Locking Policy ( Ceiling Locking );pragma Detect Blocking;

4 pragma Restrictions (

27

2.2. EL PROCESADOR LEON

No Abort Statements,No Dynamic Attachment,No Dynamic Priorities ,No Implicit Heap Allocations ,

9 No Local Protected Objects,No Local Timing Events,No Protected Type Allocators ,No Relative Delay ,No Requeue Statements,

14 No Select Statements,No Specific Termination Handlers ,No Task Allocators ,No Task Hierarchy,No Task Termination,

19 Simple Barriers ,Max Entry Queue Length => 1,Max Protected Entries => 1,Max Task Entries => 0,No Dependence => Ada.Asynchronous Task Control,

24 No Dependence => Ada.Calendar,No Dependence => Ada.Execution Time.Group Budget,No Dependence => Ada.Execution Time.Timers,No Dependence => Ada.Task Attributes);

2.2. El procesador LEON

En esta seccion se describe el procesador LEON. Es de interes puesto que sedesarrollo por la ESA con el fin de conseguir un diseno de procesador abierto, por-table y no propietario para servir como arquitectura de los sistemas empotradosde los proyectos que llevase a cabo, de forma que se pudieran alcanzar los requisi-tos de rendimiento, compatibilidad y costes. Ademas, es el procesador para el queel sistema operativo de tiempo real ORK+ fue disenado en su primera version. Acontinuacion, se detalla su historia y sus caracterısticas.

El procesador LEON es un procesador RISC para sistemas empotrados, de 32-bits, basado en la arquitectura SPARC V8. Su nucleo es altamente configurable ymuy adecuado para disenos SOC (system-on-a-chip). Ha sido desarrollado en suorigen por la Agencia Espacial Europea y posteriormente por Gaisler Research.

En la actualidad se han desarrollado varias versiones o modelos de LEON:

LEON2. Su diseno en lenguaje VHDL es de libre distribucion por internetbajo la licencia GNU GPL. Ultimamente ha sido abandonado en favor delprocesador de nueva generacion LEON3. Cuenta con cinco etapas de pipeline,perifericos como UARTS o temporizadores integrados y cache de instrucciones

28


y datos separadas. Existen restricciones con respecto a las licencias de uso(distribuidas por la Agencia Espacial Europea) en este modelo.

LEON3. Es la siguiente revision del procesador LEON realizada por GaislerResearch. Cuenta con siete etapas de pipeline, anade una unidad de MMU,soporte para Symmetric Multi-processor (SMP) y una unidad de coma flotanteque cumple con el estandar IEEE-754.Ofrece un mayor rendimiento que el anterior procesador, el LEON2 y ademasmejora su adaptacion en disenos SOC.

LEON4. Evolucion logica del procesador LEON3. Desarrollado por GaislerResearch. Utiliza buses de comunicacion internos mas anchos, e incluye soportepara caches de nivel 2.

De todos los modelos existe una version FT (LEON2-FT, LEON3-FT, LEON4-FT). Esta es una version tolerante a la radiacion. Las cuales tienen correccion contrafallos de memoria utilizando bits de paridad. De estas versiones tambien se distribuyesu modelo VHDL, incluido en una librerıa tambien tolerante a fallos. Para estasversiones existen restricciones con respecto a las licencias de uso.

El procesador de referencia en el proyecto es el procesador LEON3.

2.2.1. Arquitectura SPARC

La base del procesador LEON3 es la Arquitectura de Procesador Escalable (Sca-lable Processor ARChitecture) (SPARC), concretamente SPARC v8 [18]. Es unaarquitectura Procesador con juego de instruccones reducidas (RISC).

Las principales caracterısticas son:

Utilizacion de un mecanismo llamado ventana de registros que permite mejorarel rendimiento de los compiladores.

Modos de direccionamiento:

• Inmediato

• Directo

• Indirecto

Utilizacion de instrucciones diferidas.

Registros valla para la proteccion de memoria. Solo en acceso de escritura.

El contador de programa

Existen dos registros de 32-bits para almacenar el contador de programa (PC ynPC). El registro de 32-bits PC contiene la direccion de la instruccion que esta siendo

29


ejecutada. El registro nPC contiene la direccion de la siguiente instruccion en serejecutada (mientras no ocurra un trap).

Si ocurre un trap, la direccion que contiene el PC es almacenada en el registrolocal l1 mientras que la direccion que contiene el registro nPC es almacenada en elregistro local l2. Cuando se vuelve del trap, el valor de l1 es copiado de nuevo alregistro PC y l2 al registro nPC.

La unidad aritmetico logica

La unidad aritmetico logica (ALU) opera en conexion directa con los 32 regis-tros de proposito general. Las operaciones aritmeticas entre registros de propositogeneral o entre un registro y una direccion inmediata de memoria se ejecutan enun unico ciclo de reloj. Tambien provee un multiplicador/divisor con soporte paramultiplicacion y division con y sin signo.

Se pueden realizar ademas operaciones de 64-bits mediante el uso del registro de32-bits Y, en el que se almacena la palabra mas significativa del producto de dobleprecision de una multiplicacion entre enteros o el dividendo de doble precision deuna division entre enteros.

Registro de estado

El registro de estado (PSR, State Register) contiene informacion global sobrela ventana actual usada, las interrupciones autorizadas y los perifericos presentes(como la FPU y el coprocesador).

Se provee un manejo global de las interrupciones a traves del registro de estado.Los traps y las interrupciones pueden ser habilitadas o deshabilitadas desde esteregistro. En el caso de las interrupciones, el control se realiza en base a niveles deprioridad.

El registro de estado tambien contiene informacion sobre el resultado de la ulti-ma operacion aritmetica ejecutada. Esta informacion puede ser usada para alterar elflujo de ejecucion del programa y realizar ası operaciones condicionales. En la arqui-tectura SPARC esta especificado que el registro de estado sea actualizado despuesde cada operacion de la ALU. Esto elimina en muchos casos la necesidad de usarinstrucciones dedicadas a comparar.

Por ultimo, se debe tener en cuenta que la escritura del registro de estado esposible unicamente cuando el procesador se encuentra en modo supervisor.

2.2.2. Las ventanas de registros

Los registros del procesador LEON tal y como se contempla en la definicion dela arquitectura SPARC V8 estan organizados en ventanas, como se muestra en lafigura 2.6.

30


entradas

ventana (CWP + 1)r[31]:

r[24]r[23]: locales

r[16] ventana (CWP)r[15] r[31]: salidas : entradas

r[8] r[24]r[23]: locales

r[16] CWP − 1)r[15] r[31]: salidas : entradas

r[8] r[24]r[23]: locales

r[16]r[15]: salida

r[8]

r[7]: globales

r[1]r[0] 031 0

ventana (

Figura 2.6: Ventanas de registros de la arquitectura SPARC V8

Cada ventana consiste en un conjunto de 24 registros. Cuando un programaesta ejecutandose, tiene acceso a 32 registros del procesador de 32-bits, lo que incluye8 registros globales mas 24 registros que pertenecen a la ventana de registros actual:

Los primeros 8 registros de la ventana son los registros de entrada (in regis-ters, i0- i7). Cuando se llama a una funcion, estos registros contendran losargumentos a usar.

Los siguientes 8 registros de la ventana son los registros locales (local registers,l0- l7). Estos registros pueden ser usados de forma libre mientras que ejecutala funcion.

Los ultimos 8 registros de la ventana son los registros de salida (out registers,o0-o7). Estos registros son usados para pasar los argumentos a la funcion a

31


llamar.

El LEON3 implementa 8 ventanas de registros como las descritas anteriormente.Sin embargo, no quiere decir que en conjunto tenga 192 registros (8 × 24), ya quelos registros de salida (out) de una ventana se solapan con los registros de entrada(in) de la contigua, por lo que en realidad el numero total de registros es 128 (8 ×16). De esta forma, los registros de salida de la ventana uno se corresponden conlos de entrada de la ventana cero, los registros de salida de la ventana dos son losde entrada de la numero tres... y ası sucesivamente hasta que llegamos a la ultimaventana. Los registros de entrada de la ultima ventana cierran el cırculo y se solapancon los de salida de la ventana cero. Esta disposicion recibe el nombre de pila circularde registros.

En un momento determinado de la ejecucion de un programa solo se tiene accesoa una ventana de registros: la indicada por el campo CWP (Current Window Pointer,indicador de la ventana actual) del registro de estado del procesador (PSR).

Cuando una funcion llama a otra, la funcion llamada ejecuta la instruccion save.Esta instruccion decrementa el CWP, desplazando ası hacia abajo la ventana deregistros. Los registros de salida en la funcion llamante se convierten en los registrosde entrada de la funcion llamada, y la funcion llamada obtiene un nuevo conjuntode registros locales y de salida para uso propio.

En la llamada a una funcion solo cambia el puntero CWP, ya que los argumentosde la funcion y la direccion de retorno no necesitan ser almacenados en la pila. Lainstruccion de retorno actua de forma inversa.

La mascara de ventana invalida (WIM, Window Invalid Mask) sirve para de-terminar si una instruccion save, restore o rett producira una excepcion de over-flow/underflow de ventana.

Ademas, como ya se comento antes, el procesador LEON3 cuenta con 8 registrosde proposito general (g0-g7). Estos registros, visibles siempre, son accesibles inde-pendientemente de la ventana a la que apunte el CWP, por lo que se puede accedera ellos en cualquier momento.

El registro g0 mantiene de forma constante el valor 0. En realidad, el registrog0 no suele existir como tal, sino que, por construccion del hardware, esta cableadodirectamente a tierra. Dado que el LEON2 es un procesador de tipo RISC, esteregistro resulta muy util para muchas operaciones.

En la figura 2.7 se muestra el mapa de las ventanas de registros y su funciona-miento.

32


w7entradas

w7locales

w7salidas

w6entradas

w6locales

w6salidas

w5entradas

w5locales

w5salidas

w4entradasw4

localesw4

salidas

w3entradas

w3locales

w3salidas

w2entradas

w2locales

w2salidas

w1entradas

w1 locales

w1 salidas

w0entradas

w0locales

w0salidas

CWP+1

CWP( )

CWP−1

WIM(Máscara de ventana

inválida)

RESTORE,RETT

SAVE,trap

Ventana actual

Figura 2.7: Mapa circular de las ventanas de registros en el LEON3

2.3. ORK+

ORK+ (Open Ravenscar real-time Kernel [8]) es un nucleo software desarrolladopor el grupo STRAST bajo un contrato con la ESA.

Los sistemas operativos convencionales no son aptos para el desarrollo de unsistema de tiempo real. Es necesario que su comportamiento sea determinista parapoder garantizar los plazos de respuesta. Ademas, muchos de los sistemas operati-vos existentes son poco fiables, como se explico en 2.1, esta es una cualidad muyimportante que deben cumplir los sistemas de tiempo real.

El nucleo ORK+ esta pensado para ser utilizado en sistemas de tiempo real

33

2.3. ORK+

crıtico. Es necesario asegurar que los programas desarrollados cumplen con estascaracterısticas, es decir, deben ser verificables.

Un sistema de tiempo real ha de soportar una serie de caracterısticas:

Concurrencia. Se deben utilizar procesos ligeros y con memoria comun atodos ellos.

Temporizacion. Es necesario disponer de un reloj del sistema monotono ycon suficiente precision para permitir comprobar si se cumplen los requisitostemporales de las acciones.

Planificacion determinista. Un sistema de tiempo real debe ser determi-nista, por lo que se debe utilizar un esquema de planificacion que evite laaleatoriedad del sistema, por ejemplo, el esquema de planificacion dinamicacon prioridades fijas (FPPS).

Acceso a dispositivos de entrada y salida. Como se vio en la descripcionde un sistema de tiempo real, una de las caracterısticas de los mismos es sugran iteracion con su entorno. Esta iteracion se suele realizar por medio dedispositivos, por lo que es muy importante tener acceso a los mismos.

ORK+ cumple con todas estas caracterısticas. Como se muestra posteriormenteproporciona todos estos servicios a traves de la librerıa de ejecucion de Ada. Aunquetambien es posible hacer uso de estos servicios que proporciona el sistema desde otroslenguajes como es el caso de C, al que se proporciona soporte para que interactuecon el nucleo software.

Las funciones o caracterısticas del kernel se pueden agrupar en:

Manejo de tareas: incluyendo la creacion, sincronizacion, y planificacion delas mismas.

Servicios de tiempo: incluyendo esperas absolutas (“absolute delay”), re-loj de tiempo real, relojes de tiempo de ejecucion, temporizadores y eventostemporales.

Manejo de interrupciones: incluyendo la0 asociacion de un procedimientoprotegido como manejador de una interrupcion hardware, tratamiento de inte-rrupciones por prioridades e inicializacion de los manejadores de interrupcioneshardware.

El uso de tareas ha sido considerado como “no seguro”para los sistemas de tiemporeal crıticos durante mucho tiempo. Aunque, un analisis posterior de los tiempos derespuesta de la planificacion con prioridades fijas con desalojo [4] permite su uso eneste tipo de sistemas.

El kernel ORK+ es conforme al perfil de Ravenscar, pero anade gestion de cuotasde tiempo para grupos de tareas y la inclusion de temporizadores de tiempo de

34


ejecucion. Estos fueron anadidos en la nueva declaracion de Ada, Ada 2005, pero noforman parte de la definicion del perfil de Ravenscar.

Este kernel ha sido cuidadosamente disenado para permitir a los desarrolladoresconstruir aplicaciones fiables para sistemas informaticos basados en el procesadorLEON2 [10]. Cabe destacar que el kernel ORK+ esta integrado en un sistema decompilacion cruzada, basado en GNAT.

2.3.1. Arquitectura del nucleo ORK+

El kernel consiste en los siguientes paquetes de Ada:

System.BB: Paquete principal (paquete vacio).

System.BB.Threads: Permite el manejo de threads. Incluye sincronizaciony funciones para controlar la planificacion.

System.BB.Threads.Queues: Implementa varias colas del nucleo, como lacola de alarmas y de procesos listos.

System.BB.Time: Ofrece el control sobre el reloj y las alarmas, incluyendosoporte para temporizadores de tiempo de ejecucion.

System.BB.Time.Execution Time Support: Ofrece soporte para los re-lojes de tiempo de ejecucion y cuotas colectivas de tiempo de ejecucion.

System.BB.Interrupts: Ofrece el soporte para el manejo de interrupciones.

System.BB.Parameters: Parametros de configuracion.

System.BB.CPU Primitives: Contiene operaciones y definiciones depen-dientes del procesador.

System.BB.Peripherals: Ofrece soporte para los perifericos de la placa.

System.BB.Peripherals.Registers: Definiciones relacionadas con los regis-tros de entrada/salida de los dispositivos perifericos.

System.BB.Serial Output: Ofrece soporte para la salida serie a una conso-la.

La figura 2.8 muestra la arquitectura de componentes del kernel ORK+.

35

2.3. ORK+

BB.Parameters:

BB.CPU_Primitives:

BB.Peripherals:

BB.Peripherals.Registers:

Bare Board Kernel

<<component>>

BB.Threads.Queues:

BB.Threads:

BB.Protection:

BB.Time:

BB.Time.Execution_Time:

BB.Interrupts:

BB.Serial_Output:

Protección

Manejo deThreads

Sincronización

Planificación

Manejo de interrupciones

Servicios de temporización

Salida serie

Figura 2.8: Arquitectura del kernel ORK+.

2.3.2. Integracion del nucleo en GNAT

El nucleo de tiempo real ORK+ se integra con el el compilador GNU NYU AdaTranslator (GNAT). La estructura de la integracion se muestra en la figura 2.9.

Para conseguir que GNAT sea portable las librerıas de tiempo de ejecucion(GNAT Run-Time System) que implementa para Ada estan escritas en Ada.

GNARL (GNU Ada Run Time Library) Esta es la capa que implementa labiblioteca para el tiempo de ejecucion de Ada. Contiene todo el modelo detareas del lenguaje: planificacion, sincronizacion, etc... Y es independiente, ensu mayorıa, del sistema operativo subyacente, lo cual facilita su adaptacion adistintos sistemas. Los programas Ada compilados con GNAT hacen llamadasa esta capa a traves de su interfaz, conocida como GNARLI.

GNULL (GNU Low-Level Library) Esta biblioteca se encarga de traducir lasllamadas a la biblioteca Ada (GNARL) en llamadas de bajo nivel al sistemaoperativo. GNARL accede a los servicios de esta capa a traves de su interfaz:GNULLI. Dicha interfaz no debe ser modificada, ya que esto requerirıa cambiartambien la capa superior (GNARL en este caso). Al tratarse GNULL de unacapa dependiente del sistema operativo, los paquetes incluidos en ella han sidoconvenientemente adaptados a ORK+.

Por debajo de GNULL se encuentra el sistema operativo, en nuestro caso ORK+.

36


Aplicación Ada

GNARL

GNULL Interfaz C

Aplicación C

GNARLI

GNULLI

Interfaz del Kernel

Kernel ORK+

Hardware Basado en Leon

Inte

rfaz

GD

B

Figura 2.9: Arquitectura Software. Integracion de ORK+ con el compilador.

El sistema operativo es el que ofrece los servicios al run-time de Ada a traves de lainterfaz de ORK+.

ORK+ esta escrito en su mayorıa en el propio lenguaje Ada. Las rutinas de bajonivel, que permiten la interaccion del nucleo software con el hardware, se encuentranescritas en lenguaje ensamblador.

2.3.3. Sistema de compilacion cruzada

ORK+ se distribuye junto con un conjunto de herramientas de compilacion. Esteconjunto, incluyendo el kernel ORK+, se denomina GNATforLEON. Este sistemaesta basado en las herramientas de compilacion de GNU’s Not Unix! (GNU) yesta compuesto por los siguientes elementos:

Binutils.Es una coleccion de utilidades que permite trabajar con binarios. Los masimportantes son el enlazador (ld) y el ensamblador (as). El conjunto estaformado por unas 8 herramientas distintas.

GCC.GNU Compiler Collection (GCC) es una coleccion de compiladores GNU dis-tribuidos bajo la licencia publica general, GNU General Public License (GPL).Con una arquitectura modular, posee varios front-end para distintos lenguajes,C (gcc), Ada (gnat), Fortran (gfortran) o C++ (g++).

Newlib.Es una implementacion de la librerıa estandar de C para sistemas embebidos.

37

2.4. SISTEMAS DE PARTICIONADO ESPACIAL Y TEMPORAL

Se distribuye bajo la licencia publica general reducida, GNU Lesser GeneralPublic License (LGPL).

GDB.GNU Debugger (GDB) es el depurador estandar en el sistema de compilacionGNU. Puede usarse facilmente para depurar aplicaciones desarrolladas conORK+. Permite tanto la depuracion en local (simulador), como la conexion auna plataforma real de desarrollo.

En la figura 2.10 se muestra un diagrama de los procesos que se realizan en elsistema de compilacion para obtener el ejecutable para la aplicacion desarrolladocon ORK+.

.ads

.adb

.ads

Compilador GNAT

.ali

.o

GNAT Montador

.ali

b~xxx.adsb~xxx.adb .a

Enlazador GNAT

f le

.exe

Unidades de compilación de la

aplicación

Archivo de conf guración de

GNAT

Especif caciones de ORK+ (GNARL

restringido)

Archivos de información de librería

de la aplicación

Archivos objeto de la aplicación

Archivos de librería de Ada de ORK+ (GNARL con

restricciones)

Ejecutable ELF-32 SPARC

Archivos de librería de Ada de ORK+ (GNARL

con restricciones)

Figura 2.10: Proceso de compilacion de un ejecutable con ORK+.

2.4. Sistemas de particionado espacial y temporal

En esta seccion se describen los sistemas de particionado espacial y temporal, sumotivacion y las caracterısticas que ofrecen para los sistemas de tiempo real.

Estos sistemas surgen por la necesidad de aportar una solucion para la cons-truccion de sistemas de avionica compuestos de aplicaciones con distintos niveles decriticidad, de modo que ejecuten todas las aplicaciones en una misma plataforma.Estas aplicaciones deben ser aisladas unas de las otras, de forma que la integri-dad de cada una no se vea afectada por el mal comportamiento de las demas. Elenfoque comun que se estaba aplicando es la ejecucion de las aplicaciones en dife-rentes computadores. Sin embargo, el crecimiento en el numero de aplicaciones yel incremento de la potencia de procesamiento de los computadores embebidos han

38


abierto la puerta a las arquitecturas integradas. En estas arquitecturas las aplica-ciones ejecutan en una unico computador. Obviamente, los mecanismos para aislarlas particiones difieren de los que se proporcionan en arquitecturas en las que lasaplicaciones ejecutan en diferentes computadores.

El enfoque comun que se ofrece en este nuevo modelo, de arquitectura integrada,se basa en proveer un numero de particiones logicas en cada computador, en el senti-do de que cada particion ejecute con un tiempo de procesador compartido, ası comoun espacio de memoria y otros recursos. Por lo tanto, las particiones son aisladasunas de las otras en los dominios espacial y temporal. El aislamiento temporal im-plica que una particion no usa mas tiempo del procesador que el que tiene asignado,y el aislamiento espacial implica que el software que ejecuta en una particion nopuede ni leer ni escribir en el espacio de memoria asignado a otras particiones.

Este nuevo enfoque se ha implementado ya con exito en el dominio aeronautico,acunando el concepto de avionica modular integrada (IMA). Esta arquitectura IMAse apoya en una capa software que provee el aislamiento indicado entre particiones. Elestandar ARINC 653 [2] define una arquitectura y una interfaz para la programacionde aplicaciones que componen la capa software.

El aislamiento temporal se consigue a traves de un esquema de planificacion dedos niveles o planificacion jerarquica (figura2.11). Un planificador de particionesglobal asigna el tiempo de proceso a las particiones segun una planificacion estaticacıclica, donde las particiones ejecutan en una rodaja de tiempo fija. En su rodaja detiempo cıclica las particiones aplican su planificacion local. Por lo tanto, el planifi-cador global es una variante del ejecutivo cıclico mientras que, en el caso de ORK+,el planificador local esta basado en el esquema de prioridades fijas.

Planificador global(ejecutivo cíclico)

Planificador local(FPPS)

Partición 1 Partición 2 Partición 3

Tarea x

P1 P2 P3 ···P1 P2 P3

Tarea yTarea z

Tarea aTarea b

Tarea 1Tarea 2

Tarea 3

Ciclo principal

Figura 2.11: Arquitectura de planificacion jerarquica.

39

2.5. EL HIPERVISOR XTRATUM

El aislamiento espacial entre particiones se provee implementando un espacio dedirecciones separado para cada particion, de una forma similar a la que se realizapara proteger el espacio de direcciones de los procesos en un sistema operativoconvencional.

Es de destacar que en la version Ada 2005 se permiten enfoques avanzados departicionado espacial y temporal para sistemas de tiempo real, que son mas simplesde implementar y que proveen mas flexibilidad en la planificacion de tareas [17, 19].Sin embargo, hay una fuerte demanda para el desarrollo de sistemas de tipo IMA enla industria y se debe proveer soporte para el desarrollo de aplicaciones que ejecutensobre ORK+ en estos sistemas.

2.5. El hipervisor XtratuM

En esta seccion se describe la capa software que provee el aislamiento temporaly espacial en la infraestructura que se proporciona para el desarrollo de aplicacionesde tipo IMA. De este modo se aborda el concepto de virtualizacion, apuntando susdistintos tipos, y a continuacion se muestra una descripcion del hipervisor XtratuM.Entre los tipos de virtualizacion se destaca especialmente la paravirtualizacion, quees el tipo de virtualizacion que implementa el hipervisor.

2.5.1. Virtualizacion

Virtualizacion4 es la creacion de una version virtual (normalmente distinta a laactual) de algun recurso tecnologico, como puede ser una plataforma de hardware,un dispositivo de almacenamiento u otros recursos.

Dicho de otra manera, se refiere a la abstraccion de los recursos de un compu-tador, que crea una capa de abstraccion entre el hardware de la maquina fısica (host)y el sistema operativo de la maquina virtual (guest), dividiendose el recurso en unoo mas entornos de ejecucion.

Existen varios tipos de virtualizacion, dependiendo de la plataforma objetivo avirtualizar: Hardware, Software, memoria, almacenamiento, etc.

Tecnicas de virtualizacion hardware

La virtualizacion hardware consiste en la virtualizacion de un computador o unsistema operativo. Se ocultan las caracterısticas fısicas del computador a los usuarios,dandoles una vision distinta.

Un hipervisor o monitor de maquina virtual es una plataforma que permite apli-car diversas tecnicas de control de virtualizacion para utilizar, al mismo tiempo,diferentes sistemas operativos (sin modificar o modificados en el caso de paravirtua-lizacion) en un mismo computador. Es una extension del termino “supervisor”, quese aplica a nucleos de sistemas operativos.

4Definicion obtenida de la Wikipedia http://es.wikipedia.org/wiki/Virtualizacion

40

http://es.wikipedia.org/wiki/Virtualizaci%C3%B3n


Una plataforma de virtualizacion esta compuesta por una plataforma hardwarecon el programa de control, que crea una version simulada del computador objetivo,lo que se denomina maquina virtual. La maquina virtual creada puede virtualizar laplataforma objetivo completamente (virtualizacion completa) o solo en parte (vir-tualizacion parcial o paravirtualizacion).

Virtualizacion Completa Una maquina virtual que sigue la tecnica de vir-tualizacion completa simula la plataforma objetivo completamente, de formaque una aplicacion compilada para la plataforma objetivo puede ejecutar sinmodificacion alguna sobre la maquina virtual. La aplicacion puede ser cual-quier pieza de software creada para la plataforma objetivo, incluido un sistemaoperativo.

Este tipo de virtualizacion permite virtualizar plataformas hardware distintasa la plataforma donde se esta ejecutando el virtualizador.

Virtualizacion parcial En la virtualizacion parcial, la maquina virtual si-mula unicamente parte del hardware sobre el que se ejecuta el virtualizador.Normalmente, muchos de los programas creados para esta plataforma no suelenejecutar en la maquina virtual sin realizar cambios.

Un tipo muy utilizado, de este tipo de virtualizacion, es la virtualizacion delespacio de direcciones, en la que a cada maquina virtual se le asigna un espaciode direcciones distinto. Esta caracterıstica, implementada en la mayorıa de lossistemas operativos modernos, necesita de hardware para la implementacion,como puede ser la unidad de gestion de memoria, Memory Management Unit(MMU).

Paravirtualizador En la paravirtualizacion, la maquina virtual no siemprevirtualiza el hardware, en general se ofrece una interfaz de programacion deaplicaciones (API) para interactuar con este. Esto implica que los programastengan que ser modificados para ejecutar en este tipo de maquinas virtuales,como ocurre en el caso de las aplicaciones orientadas a ejecutar en XtratuM.

El hardware subyacente no “cubierto” por la maquina virtual sigue siendo elde la plataforma donde ejecuta el hipervisor.

2.5.2. XtratuM

XtratuM [14] es un hipervisor, esto es, una capa software que provee uno, omas, entornos de ejecucion para particiones. Pensado para cumplir los requisitosde los sistemas de tiempo real estricto, uno de los primeros objetivos es garantizarlos requisitos temporales de las particiones. XtratuM ha sido desarrollado por laUniversidad Politecnica de Valencia (UPV). Y se encuentra bajo una licencia decodigo libre.

Inicialmente fue desarrollado para la arquitectura x86. En su segunda version,2.x, XtratuM fue reescrito desde cero y adaptado al procesador LEON2 con la version2.1.

41


En el caso de los sistemas empotrados (o embebidos), en particular en el en-torno aeroespacial, el estandar Avionics Applicaction Standard Software Interface(ARINC) define un tipo de sistema particionado (ver 2.4) para la ejecucion de apli-caciones de tipo IMA. Aunque ARINC no define la forma en la que tiene que operarun hipervisor, muchas caracterısticas del modelo APplication EXecutive (APEX) de-finidas en ARINC son muy parecidas a las proporcionadas por un hipervisor, comoXtratuM.

En un hipervisor que ejecuta directamente sobre el hardware, (bare hypervisor),y en particular en XtratuM, una particion es una maquina virtual mas, no tanto ungrupo de procesos que ejecutan aislados.

Es importante senalar que XtratuM es un hipervisor con un extenso abanicode caracterısticas para sistemas crıticos. XtratuM provee un entorno de ejecucionvirtual con una vision muy cercana al hardware sobre el que ejecuta, pero no identica.XtratuM, como se ha comentado, utiliza la tecnica de paravirtualizacion. Aunque,XtratuM no es compatible con el estandar ARINC, la filosofıa definida en ARINCha sido, siempre que se ha podido, seguida en el desarrollo de XtratuM.

Un resumen de las principales caracterısticas puede ser:

Paravirtualizador. La interfaz de la maquina virtual que provee es similaral hardware sobre el que ejecuta.

Dispositivos dedicados. Los dispositivos se asocian de forma exclusiva auna particion.

Aislamiento temporal fuerte. Utilizacion de un ejecutivo cıclico para con-trolar el tiempo de ejecucion de las distintas particiones.

Aislamiento espacial fuerte. Las particiones son alojadas en regiones dememoria a las que no pueden acceder otras particiones.

Ejecucion de particion segura. Las particiones ejecutan en modo no pri-vilegiado del procesador.

Comunicacion entre particiones. Sistema de comunicacion entre particio-nes basado en colas y en muestreo.

Niveles de ejecucion diferenciados. Muchos servicios estan restringidos alas particiones del sistema, las particiones normales no pueden hacer uso deellos.

XtratuM al tratarse de un paravirtualizador proporciona una interfaz muy cer-cana al hardware para el que esta creado. La interfaz de la maquina virtual permiteacceso a los recursos del sistema: registro del procesador, relojes, temporizadores,memoria, etc., por medio de llamadas. Estas llamadas en el ambito de XtratuM to-man el nombre de hiperllamadas (hypercalls). Muchos de estos servicios solo puedenser utilizados por las particiones del sistema.

42


XtratuM por lo tanto ofrece una serie de servicios que permiten acceder al hard-ware. Parte de estos servicios dependen de la arquitectura sobre la que se deseaejecutar. En la tabla 2.4 se muestran los servicios especıficos para la arquitecturaSPARCV8.

Cuadro 2.4: Hiperllamadas de XtratuM para la arquitectura SPARC V8.

Hiperllamadas para SPARC V8XM sparcv8 atomic addXM sparcv8 atomic andXM sparcv8 atomic orXM sparcv8 clear pilXM sparcv8 flush regwinXM sparcv8 flush tlbXM sparcv8 get psrXM sparcv8 inportXM sparcv8 outportXM sparcv8 set pilXM sparcv8 set psrXM sparcv8 ctrl winflow

En este documento, las referencias a XtratuM, son referencias a XtratuM 3.xpara el procesador LEON3.

Particiones

Un sistema que ejecute sobre XtratuM se compone de una o varias particiones(maquinas virtuales) que ejecutan segun un plan. El plan define ranuras o slots detiempo que son repartidas a cada particion, se trata de un sistema particionado (ver2.4).

Cada maquina virtual (particion) puede contener una aplicacion realizada ori-ginalmente para ejecutar sobre el procesador (maquina desnuda) o un sistema ope-rativo en el que pueden ejecutar una o varias aplicaciones. Tanto las aplicacionescomo el sistema operativo para la maquina desnuda tienen que ser modificados [2]para que hagan uso de los recursos proporcionados por el hipervisor. Estos cambios,en el caso del sistema operativo, implican modificar la mayorıa de las partes de lacapa de abstraccion del hardware (HAL), para hacer uso de las hiperllamadas queprovee XtratuM.

En la figura 2.12 se muestra la arquitectura de XtratuM. Se muestran variasparticiones conteniendo ORK+/XtratuM con aplicaciones escritas en Ada y unaparticion ejecutando RTEMS, otro sistema de tiempo real, con una aplicacion escritaen C. En la figura, tambien se observa como una de las particiones esta definida comoparticion del sistema (o privilegiada) (aunque podrıa haber mas de una particiondel sistema) y el resto como particiones de usuario.

43


Interfaz de Hiperllamadas

Xtra

tuM

Gestor de memoria Planif cador Comunicaciones IP Tracing

Relojes y temporizadores

Gestion de interrupciones Monitor de Estado

Aplicación Ada

ORK+

Servicios Virtualizados

Aplicación Ada

ORK+


Aplicación C

RTEMS


Aplicación Ada

ORK+


Partición supervisora Particiones normales

Mod

o S

uper

viso

rM

odo

Usu

ario

Figura 2.12: Arquitectura de Xtratum.

En el momento de la inicializacion del sistema todas las particiones se encuentranen el modo arranque. En este estado la particion debe preparar su entorno deejecucion. Dado que el hipervisor no diferencia entre el estado normal y el estadoarranque, la particion debe avisar a XtratuM de que ya ha sido inicializada.

El estado normal esta dividido en tres subestados:

Listo (ready). En el que la particion esta lista para ejecutar, pero no es suturno.

Ejecutando (running). La particion esta ejecutando.

Ocioso (Idle). La particion no hace uso del procesador durante su ranura detiempo.

Una particion puede estar en estado de parada (Halt). En este estado la particionno es elegida por el planificador, dejando sin utilizar el tiempo correspondiente ala ranura asociada a la particion. Una particion puede entrar en este modo porsı misma o porque una particion con privilegios cambie su estado. Una particiontambien puede pasar al estado suspendida (suspended). En este caso la particiontampoco sera elegida por el planificador. A diferencia del estado parada, cuando unaparticion se encuentra en estado suspendida, si llegan interrupciones se quedaranpendientes por si la particion vuelve al estado normal. Una particion puede volveral estado normal si una particion que tenga privilegios, distinta de sı misma, realizael cambio de estado utilizando la llamada correspondiente.

44


Suspendido Parado

Arranque

Normal

Figura 2.13: Estados de las particiones.

Particiones supervisoras

XtratuM define dos tipos de particiones: normal y supervisora (o con privilegios).Las particiones supervisoras pueden controlar y monitorizar el resto de particiones.Existen varios servicios o hiperllamadas ofrecidas por la interfaz de programacionde aplicaciones (Application Programming Interface (API)) de XtratuM que solopueden ser utilizados por una particion configurada como supervisora.

Una particion supervisora tiene derechos para controlar otras particiones: parar,suspender, despertar, etc. Esto no tiene que ser confundido con la capacidad de ac-ceder al hardware real o romper el aislamiento entre particiones. El acceso que tieneuna particion supervisora no es suficiente para modificar o violar estas restricciones.

Planificador de particiones

XtratuM utiliza tecnicas de planificacion apropiadas para asegurar el aislamientotemporal en sistemas donde existen varias aplicaciones ejecutando concurrentementeen la misma plataforma hardware. Estas polıticas aseguran que una particion nopueda utilizar mas tiempo del procesador que el que le corresponde, ya que afectarıaal resto de particiones.

La tecnica de particionado estatico es la que utiliza XtratuM para su planifi-cador, mas concretamente la utilizacion de un ejecutivo cıclico. Ası se asegurael aislamiento temporal entre particiones. Esta tecnica es la que se especifica enel estandar ARINC para el planificador principal. En las secciones 2.4 y 2.1.2 seexplican con mas detalle los sistemas particionados y los tipos de planificadores,respectivamente.

Dentro de cada ranura de tiempo definida en el ejecutivo cıclico, XtratuM ponea ejecutar a la particion correspondiente, haciendo disponible todos los recursosasignados a la particion. Algunos recursos tienen que especificarse en el archivo deconfiguracion para permitir el uso por parte de la particion.

45


El codigo ejecutado en la ranura puede repartir el tiempo disponible entre todaslas actividades concurrentes si existen (tareas, procesos o threads), utilizando paraello la tecnica de planificacion que se desee. Si existen actividades concurrentes y seutiliza algun planificador para organizar los recursos a nivel de particion, el sistemahace uso de una planificacion jerarquica (ver 2.4).

Cuando el tiempo asignado a una particion se agota, XtratuM realiza el corres-pondiente cambio de contexto, asignando los recursos a la particion asociada a lasiguiente ranura de tiempo definida en el plan.

El plan de ejecucion de todo el sistema, conjunto de particiones, debe ser definidoen el fichero de configuracion para el sistema. En dicho fichero se debe especificarlas ranuras de tiempo, su duracion y la particion asociada a la misma. En el listado2.1 se muestra un ejemplo de plan de ejecucion y en la figura 2.14 se muestra sudiagrama de ejecucion.

.......<HwDescription><Processor id=”0” frequency=”80Mhz”><Sched>

5 <CyclicPlan><Plan name=”init” majorFrame=”1s”><Slot id=”1” start=”0ms” duration=”20ms” partitionId=”1”/><Slot id=”2” start=”20ms” duration=”10ms” partitionId=”2”/><Slot id=”4” start=”30ms” duration=”10ms” partitionId=”1”/>

10 <Slot id=”3” start=”40ms” duration=”30ms” partitionId=”3”/><Slot id=”4” start=”70ms” duration=”10ms” partitionId=”2”/><Slot id=”1” start=”100ms” duration=”20ms” partitionId=”1”/><Slot id=”2” start=”120ms” duration=”10ms” partitionId=”2”/><Slot id=”4” start=”130ms” duration=”10ms” partitionId=”1”/>

15 <Slot id=”3” start=”140ms” duration=”30ms” partitionId=”3”/><Slot id=”4” start=”170ms” duration=”10ms” partitionId=”2”/><Slot id=”5” start=”180ms” duration=”20ms” partitionId=”1”/></Plan>

</CyclicPlan>20 </Sched>

</Processor><MemoryLayout><Region type=”STRAM” start=”0x40000000” size=”4MB”/><Region type=”SDRAM” start=”0x60000000” size=”128MB”/>

25 </MemoryLayout>

</HwDescription>.......

Listado 2.1: Ejemplo de configuracion de la planificacion de un sistema.

46


0 10 20 30 40 50 60 70 80 90 100 110 120 130 140 150 160 170 180 190

P1

P2

P4

P3

200

Idle

P5

P2

P1

P4 P4

P3

P4

Figura 2.14: Ejemplo de planificacion.

Una caracterıstica del planificador de XtratuM es que intenta ajustar lo maximoposible el punto de inicio especificado en el plan de ejecucion. Para conseguir esto,XtratuM programa un temporizador con la duracion del slot menos el tiempo totalque se consume en el proceso de cambio de contexto de una particion.

Comunicacion entre particiones

XtratuM implementa un modelo de paso de mensajes entre particiones que seajusta al definido en el estandar ARINC. Un mensaje es un bloque de datos quees enviado por una particion origen hasta una o varias particiones destino. El con-tenido de los mensajes es transparente para el mecanismo de paso de mensajesimplementado por XtratuM.

Un canal de comunicacion es un medio logico de comunicacion entre una parti-cion origen y una o varias particiones destino. Las particiones pueden acceder a loscanales de comunicacion a traves de puntos de acceso llamados puertos. El hipervi-sor es el responsable de empaquetar y transportar el mensaje, sin que en el trayectosufra modificaciones, hasta el/los destino/s. A nivel de particion los mensajes sonentidades atomicas, si una particion recibe el mensaje, entonces la recepcion es com-pleta. En caso de no completarse la recepcion el correspondiente error es devuelto,pero no es posible acceder a ninguna parte del mensaje.

Los canales de comunicacion, el tamano maximo y el numero maximo de men-sajes se definen en el fichero de configuracion del sistema.

Existen dos modos distintos de transferencia: muestreo (sampling) y encolado(queuing).

Muestreo (Sampling)

En este modo se ofrece soporte para comunicacion broadcast, multicast y unicast.En este modo no es posible encolar mensajes. Un mensaje es conservado en el puertode origen hasta que es transmitido por el canal o sobrescrito en caso de que llegueun nuevo mensaje, lo que ocurra primero. Cuando una copia del mensaje llega alpuerto destino, sobrescribe el mensaje actual, el mensaje se conserva hasta que es

47


sobrescrito. De esta manera es el ultimo mensaje el que esta disponible para laparticion destino.

Para la escritura de un mensaje se utiliza la hiperllamada XM write sampling -

message. Esta hiperllamada copia el mensaje en un buffer interno de XtratuM. Lasparticiones pueden leer el mensaje utilizando la hiperllamada XM read sampling -

message que devuelve el ultimo mensaje escrito en el buffer, copiandolo en el espaciode la particion.

Todas las operaciones sobre los puertos de comunicacion en modo muestreo sonno bloqueantes.

Encolado (Queueing)

Este modo ofrece soporte para comunicaciones unicast entre dos particiones.Cada puerto tiene asociado una cola donde los mensajes son guardados hasta queson entregados a las particiones de destino. Los mensajes son entregados en ordenFirst In-First Out (FIFO).

Para enviar y recibir mensajes se utilizan las hiperllamadas XM send queuing -

message y XM receive queuing message. xtratum implementa un buffer tıpico deproductor-consumidor con operaciones no bloqueantes. La operacion de envıo escribeel mensaje en el buffer circular y en la operacion de lectura se copia el mensaje desdeel buffer circular de XtratuM en el espacio de la particion receptora.

Si una de las operaciones requeridas no puede completarse, ya sea porque el bufferesta lleno en una operacion de escritura o esta vacio en una operacion de lectura,entonces la hypercall retorna inmediatamente indicando el error correspondienteproducido.

Acceso a perifericos

Una particion que haga uso exclusivo de un periferico, puede acceder al dispo-sitivo a traves del controlador implementado en la particion. La particion es la quetiene el deber de controlar el periferico. Para hacer uso del mismo es necesario es-pecificar el rango de direcciones del mapa de E/S, llamadas puertos en terminologıade XtratuM, y las lineas de interrupcion necesarias para controlar el dispositivo. Laespecificacion se realiza en el fichero de configuracion del sistema.

Una de las particularidades del manejo de perifericos en XtratuM es que dos par-ticiones no pueden utilizar las mismas lıneas de interrupcion o las mismas direccionesde puertos. Sin embargo, XtratuM implementa un mecanismo que permite tener uncontrol muy fino sobre los puertos de E/S. De modo que, distintas particiones puedenleer y escribir diferentes bits del mismo puerto.

En caso de querer compartir un dispositivo entre varias particiones se recomiendacrear una particion que se encargue de controlar el dispositivo y que ofrezca losservicios a otras particiones, por ejemplo, mediante comunicacion entre particiones.De esta manera se consigue compartir un dispositivo entre varias particiones.

48


Interrupciones y excepciones

En la arquitectura SPARC un trap es un mecanismo que permite la transferen-cia de control asıncronamente. Cuando un trap ocurre, el procesador pasa a modoprivilegiado y ejecuta el manejador asociado.

SPARC v8 define 256 traps, definiendo una tabla que contiene los manejadoresllamada trap table. La tabla puede estar en cualquier posicion de memoria y paraque el procesador la encuentre la direccion de inicio de la misma se guarda en unregistro especial del procesador, llamado tbr. Tanto la tabla como el registro especialson manejados unicamente por XtratuM, consiguiendo que cualquier trap nativo quese produzca termine ejecutando una rutina de XtratuM.

XtratuM define 32 fuentes de interrupcion, originalmente no definidas en la ar-quitectura SPARC, llamadas Interrupciones Extendidas. Estas nuevas interrupcionesson utilizadas para informar a las particiones sobre eventos que ocurren en XtratuM.Los nuevos manejadores necesarios para las interrupciones extendidas son anadidosa continuacion en la tabla de traps nativa que tiene cada particion.

Las particiones tienen prohibido el uso del registro tbr. XtratuM virtualiza un tbra cada particion, de manera que cada una puede instalar su tabla de traps en cual-quier direccion que tenga asociada. Es necesario hacer uso del API que proporcionaXtratuM para usar el virtual TBR.

En un sistema virtualizado completo, la maquina virtual no maneja ningunainterrupcion hardware, todas son virtualizadas por el hipervisor. Sin embargo, enXtratuM solo se virtualizan los dispositivos que pueden poner en peligro el aisla-miento, pero permite que las particiones puedan manejar el resto de dispositivos.Los temporizadores, entre otros dispositivos, solo son manejados por XtratuM, pro-porcionando servicios a traves de su API para suplir estas carencias.

Relojes y temporizadores

XtratuM proporciona los servicios de tiempo. Existen dos tipos de relojes paracada particion, el reloj de tiempo transcurrido y el reloj de tiempo de particion. Losdos relojes son monotonos crecientes.

El reloj de tiempo transcurrido (XM HW CLOCK) esta asociado al reloj nativodel procesador. Este reloj lleva la cuenta de tiempo desde que se inicio el sistema ytiene una resolucion de 1µs.

El reloj de tiempo de particion (XM EXEC CLOCK) esta asociado con el tiempode ejecucion de la particion. Este reloj solo avanza cuando la particion esta ejecu-tando. Puede ser usado por las particiones para detectar saltos de plazos. Este relojse basa en el reloj de tiempo transcurrido, tambien tiene un 1µs de resolucion.

Ademas se pone a disposicion de la particion un temporizador por cada tipo dereloj.

49


Construir

xmcparser

xmpack

Código fuente de XtratuM

Código fuentede la Partición 1

Construir el binario del ejecutable

Partition1.xef

Distribución binaria de XtratuMxmcparser

Partition2.xef

XM_CT.bin

.config

autoconfig.h

Configuración del código fuente(menucongif)

Construir elbinario delejecutable

Código fuentede la Partición 2

1

2

Distribución binaria de XtratuM

3

Custom_CT 2

Partition2.xef

Custom_CT 1

Partition1.xef

XM_CT.xef

xm_core.xef

xmefPackageHeader

4

XM_CF.xmlxmc.xsd

Distribución binaria de XtratuM

xmcparser

rswbuild

5

Figura 2.15: Proceso de creacion de un sistema con XtratuM.

Construccion de un sistema con XtratuM

La construccion de un sistema se basa en empaquetar las particiones creadas, enbase a las definiciones del fichero de configuracion del sistema, donde se especificael plan de ejecucion y las configuraciones especificas de cada particion (Rango dedirecciones del mapa de memoria, lineas de interrupcion asociadas y puertos decomunicacion).

El ensamblaje del sistema se puede realizar aparte del desarrollo de las distintasparticiones.

En la figura 2.15 se muestra un diagrama con el proceso de creacion de un sistemapara ejecutar sobre XtratuM.

El fichero de montaje para cada particion tiene que ser actualizado para queconcuerde con el mapa de memoria asociado a cada particion.

50


2.6. ORK+/XtratuM

En esta seccion se resume el trabajo realizado para la adaptacion de ORK+ aXtratuM [1]. El trabajo descrito en este proyecto fin de carrera retoma este trabajode adaptacion realizado para la version 2 de XtratuM. Por lo tanto, aquı se describeel estado en el que se retoma ORK+ para XtratuM.

Los cambios realizados en ORK+ para maquina desnuda en la adaptacion aXtratuM abarcan los aspectos de adaptacion del manejo de la CPU, del soporte deinterrupciones y de los servicios de manejo de tiempo. Es decir, la adaptacion delos componentes que dependen estrechamente de las caracterısticas del procesador,aunque en este caso sea un procesador virtual que provee XtratuM.

ORK+ esta escrito en su mayorıa en Ada, a excepcion de las rutinas de bajonivel que estan escritas en el lenguaje ensamblador para SPARC. Por otro lado,la interfaz nativa de XtratuM esta escrita en C, que es su principal lenguaje deimplementacion. Por lo que se ha de proveer una interfaz Ada para poder accederdesde codigo escrito en este lenguaje a la interfaz que provee XtratuM. De estemodo, desde codigo escrito en Ada se puede acceder a las hiperllamadas de XtratuM.Para hacer esto, es necesario hacer uso del paquete estandar Interfaces .C y de ladirectiva al compilador pragma Import. Las modificaciones se incluyen en un nuevopaquete, a traves del cual se interactua con la plataforma, que se ha denominadoSystem.BB.XtratuM.

2.6.1. Adaptacion del manejo de la CPU

En este aspecto se ha de tener en cuenta que para manejar la CPU ya no sedispone de acceso a los registros privilegiados del procesador que permiten estagestion. Esto es ası, puesto que, al contrario que para maquina desnuda, ORK+ sobreXtratuM ejecuta en modo usuario, al igual que todas las particiones, imposibilitandoel acceso a los registros del procesador.

El manejo de la CPU se realiza principalmente para las tareas de cambio decontexto. Esta operacion ha de ser modificada para la adaptacion del kernel a unanueva arquitectura, ya que es altamente dependiente del procesador. Por lo que, larutina de cambio de contexto se reescribio de manera que todas las instruccionesque hacıan referencia a registros del procesador privilegiados se sustituyeron por lascorrespondientes llamadas especificas de la arquitectura SPARC V8. Estas hiperlla-madas estan disenadas de tal manera que tengan un impacto reducido y ası podermantener la eficiencia requerida en las operaciones de bajo nivel.

2.6.2. Adaptacion del soporte de interrupciones

XtratuM virtualiza las 16 fuentes de interrupcion de la arquitectura SPARC, ydefine otras 32 adicionales para proporcionar la gestion de los servicios de Xtra-tuM por interrupciones. Toda esta configuracion se reflejo en el paquete del kernelSystem.BB.Interrupts, ası como en los paquetes estandar Ada. Interrupts y

51

2.6. ORK+/XTRATUM

Ada. Interrupt .Names, de modo que las aplicaciones pueden asociar procedimientosprotegidos a todas las fuentes de interrupcion, incluyendo las interrupciones exten-didas que provee XtratuM.

XtratuM no soporta la prioridad de las interrupciones. Por lo tanto, todas inte-rrupciones tienen el mismo nivel de prioridad, como es normal para los hipervisoresy los sistemas operativos. Este hecho se reflejo consecuentemente en el rango deprioridades definido para ORK+ (en el rango de System. Interrupt Priority ) paratener un unico valor posible.

2.6.3. Adaptacion de los servicios de manejo de tiempo

Es necesaria la adaptacion de los servicios de manejo de tiempo ya que ORK+,en su version original, se apoya en relojes hardware para dar este soporte. A estosrelojes no se puede tener acceso en modo usuario, por lo que se han de manejar atraves de XtratuM.

Despues de la adaptacion, se consigue que ORK+ mantenga el soporte de losservicios de tiempo del perfil de Ravenscar, es decir, los que provee el paque-te Ada.Real Time.Clock, como son la espera absoluta (absolute delay), los eventostemporizados globales (global timing events) y los relojes de tiempo de ejecucion(execution-time clocks). Ademas se mantiene, como extension al perfil de Ravens-car, el soporte para temporizadores de tiempo de ejecucion (execution-time timers)y las cuotas de grupo (group budgets).

Es de destacar que los temporizadores hardware son de hecho temporizadores deltiempo transcurrido (elapsed-time timers). Sin embargo, XtratuM, como ocurre engeneral en los sistemas particionados, tiene un concepto dual del tiempo: al conceptocomun de tiempo real transcurrido, se anade la nocion de tiempo de particion,que solo avanza cuando la particion esta ejecutando. Por lo que, de acuerdo con estoXtratuM provee dos tipos de temporizadores software, ası como dos tipos de relojes:el reloj y el temporizador de tiempo transcurrido y el reloj y el temporizador deltiempo de particion.

Los mecanismos de tiempo real, que se incluyen en el paquete Ada.Real Time.Clock,estan implementados de manera similar en ORK+ para XtratuM que en ORK+ pa-ra maquina desnuda, es decir, haciendo uso del reloj y el temporizador de tiempotranscurrido. Sin embargo, los relojes de tiempo de ejecucion no se pueden imple-mentar del mismo modo. Se ha de implementar de forma que no se cuente el tiempoen el que la particion no esta ejecutando. Por lo tanto, los mecanismos de tiempode ejecucion, es decir, relojes y temporizadores, ası como las cuotas de grupo, seimplementan mediante los temporizadores de tiempo de ejecucion.

52


2.7. El microsatelite UPMSat-2

El proyecto UPMSat-25 tiene por objetivo desarrollar un micro-satelite utilizablecomo plataforma de demostracion tecnologica en orbita. Su lanzamiento esta previstoprovisionalmente para 2014 y su mision se espera que dure dos anos.

El proyecto se lleva a cabo en su mayor parte en el Instituto Ignacio da Riva(IDR) de la UPM, con la participacion de otros grupos universitarios y empresasdel sector aeroespacial espanol.

El proyecto abarca todas las etapas de la vida de un satelite incluyendo sudiseno, construccion, validacion, lanzamiento y operacion en orbita sirviendo comoplataforma espacial para la incorporacion de nuevas tecnologıas y siendo adaptable adiferentes servicios de lanzamiento. Su descripcion de base es la de un microsatelitede 50kg de peso. Su estructura es la de un cubo de 0,5m (figura 2.16) y su orbitaprevista sera heliosıncrona a una altura de 600km.

Figura 2.16: Vista exterior del UPMSat-2.

El trabajo del grupo STRAST6 se centra en el desarrollo del software de lossegmentos de vuelo y tierra de la mision. Para ello se hara uso tanto de tecnologıadesarrollada por el grupo como el kernel para sistemas de tiempo real ORK y sutecnologıa asociada (seccion 2.3) como de tecnologıa externa, como lo son los com-ponentes del computador de abordo, para cuyo procesador, de la familia LEON sedesarrollo el citado kernel.

2.8. Simuladores. Matlab/Simulink

Los simuladores, como Simulink7, son una pieza clave, como ha determinado laexperiencia del proyecto, en la infraestructura de los sistemas de validacion, comoel que se ha construido en este sistema informatico, por varias razones:

5El proyecto ha sido parcialmente financiado por el Ministerio de Economia y Competitividad(MINECO) con el identificador TIN2011-28567-C03-01 (HI-PARTES).

6www.dit.upm.es/str7Marca registrada de The MathWorks Inc. http://www.mathworks.es/products/simulink/

53

2.9. COMUNICACION SERIE (UART)

Facilita la colaboracion entre personal del ambito software y personal de otrasramas de la ingenierıa, debido a la posibilidad que ofrece de generacion decodigo.

Ofrece un editor grafico y bibliotecas de bloques personalizables para modelary simular sistemas dinamicos.

Permite la simulacion hardware-in-the-loop (seccion 5.4), lo que facilita realizarpruebas del software ejecutando directamente en el computador de a bordo.

Ofrece una capa de abstraccion superior en la pila de los niveles de abstraccionde construccion de sistemas (por encima del lenguaje de alto nivel).

Facilita el analisis de resultados en este tipo de sistemas, ya que se puedenrealizar de forma grafica.

El proyecto UPMSat-2 constituye un buen marco de desarrollo para hacer uso deestos simuladores y demostrar que el trabajo desarrollado en el grupo, como el kernelde tiempo real, se puede combinar con estos para proporcionar una infraestructuraque garantice al maximo el correcto funcionamiento de los sistemas que se van aejecutar en sistemas crıticos.

2.9. Comunicacion serie (UART)

En esta seccion se presenta de forma general el dispositivo usado para la comuni-cacion entre el ordenador que simula el entorno del satelite y el hardware, que es unaplaca de ingenierıa del ordenador de a bordo, donde ejecuta el control de actitud.Este dispositivo es un dispositivo UART.

Un dispositivo UART (por sus siglas en ingles de Universal Asynchronous Receiver-Transmiter) es un dispositivo de comunicacion serie. Este dispositivo ha sido usadocomo primera aproximacion al problema que se ha tratado y sobre el que se haconstruido la infraestructura.

La comunicacion se realiza mediante tramas de 8 bits con un bit de parada yun bit de paridad opcional. Estas tramas se comunican a una velocidad marcadapor un divisor de reloj programable de 12 bits. Para almacenar los datos de estascomunicaciones existen dos colas FIFO (una para transmision y otra para recepcion).Esta es su estructura:

54


Figura 2.17: Dispositivo UART. APB (Advanced Peripheral Bus) (Reproducido de[9]).

Las operaciones de transmision y recepcion pueden ser numerosas y prolongadas,y se han de desarrollar de manera que bloqueen lo mınimo la ejecucion del softwa-re. Por lo que el manejador del dispositivo tiene que proveer un manejo medianteinterrupciones.

Para hacer efectivo este manejo de interrupciones, el manejador se debe configu-rar para especificar la lınea de interrupcion correspondiente y la direccion base deldispositivo, que son totalmente dependientes del hardware. Con lo que la siguientetabla especifica estos datos:

Procesador Lınea de interrupcion Uart 1 Direccion base Prioridad

LEON2 2 0x80000070 3LEON3 3 0x80000100 3

Cuadro 2.5: Configuracion del dispositivo UART dependiendo del procesador

Este dispositivo tiene mas detalles, pero que a efectos del presente sistema in-formatico son transparentes.

2.10. Hardware-In-The-Loop

Hardware-in-the-loop8 es una tecnica que se usa, en general, en el desarrollo ydepuracion de sistemas empotrados de tiempo real. Esta tecnica permite depurar elsistema de forma dinamica ya que mediante un simulador del entorno, que interactuacon el sistema, y el hardware real, donde ejecuta el sistema que interactua con el

8http://es.wikipedia.org/wiki/Hardware-in-the-loop

55

2.10. HARDWARE-IN-THE-LOOP

entorno, se construye una infraestructura de ejecucion que emula la ejecucion delsoftware en lo que serıa su entorno real.

En el caso del satelite que esta siendo desarrollado, esta tecnica es indispensablepara probar sistemas como el control de actitud, puesto que no es factible como esobvio hacer las pruebas en su entorno real. Este entorno se va a construir con unaplaca modelo GR-XC3S1500 Spartan3, en la que se han grabado los procesadoresLEON2, para una primera aproximacion, y LEON3, para la estructura final. Estaplaca se muestra a continuacion:

Figura 2.18: Modelo de ingenierıa del computador de a bordo GR-XC3S1500 Spar-tan3.

56

Capıtulo 3

Adaptacion de ORK+ aXtratuM 3

En este capıtulo se describe el trabajo realizado para la adaptacion del sistemaoperativo de tiempo real ORK+ a las distintas versiones de la distribucion 3 deXtratuM. Estas versiones son 3.3.3 y 3.4.0, para plataformas monoprocesador, y3.7.1, en la que se incluye XtratuM para su uso en plataformas multiprocesador.

La adaptacion se ha realizado en torno a tres tres lıneas generales:

1. Modificacion de codigo del kernel, ORK+, para solucionar fallos, en algunoscasos, y para adaptarlo a cambios de XtratuM en otros.

2. Adicion de paquetes, a nivel del kernel y a nivel de aplicacion, para dar soportea llamadas al sistema necesarias.

3. Determinacion de fallos en el funcionamiento del sistema y solucion de losmismos cuando ha sido posible.

En las siguientes secciones se muestran los componentes concretos de estas lıneasgenerales correspondientes a cada una de las versiones de XtratuM. La estructurade estas secciones de manera general es:

1. Diferencias con la version anterior:Donde se incluyen las diferencias conceptuales y, en caso de ser necesario, losficheros que difieren, los aspectos por los cuales difieren y los extractos decodigo para apuntar algun detalle concreto

2. Cambios realizados en el kernel de ORK+:Donde se hace referencia a los cambios entre las versiones del hipervisor Xtra-tuM que afectan a ORK+, se incluyen los ficheros que han sido modificados,los aspectos por los cuales han sido modificados y, si es necesario, el extractoo los extractos de codigo modificados para incluir la adaptacion. Tambien seincluyen los cambios realizados, si ha habido, para anadir funcionalidades alkernel ORK+.

57

3.1. VERSION 3.3.3 DE XTRATUM

3. Problemas encontrados con la adaptacion:Donde se incluyen los problemas que han surgido relativos a los cambios entrelas versiones del hipervisor XtratuM

4. Bibliotecas:Donde se incluyen los paquetes anadidos o modificados para su uso a nivel deaplicacion, en el caso de que haya

3.1. Version 3.3.3 de XtratuM

3.1.1. Diferencias con la version anterior

El listado de las diferencias es el siguiente:

1. Se incluye el procesador LEON2 como plataforma. Esto implica anadir modi-ficaciones en las configuraciones del procesador como temporizadores, relojes,memoria y gestion de cache

2. Se modifica la gestion de la MMU. En versiones previas, las particiones ma-nejaban la tabla de paginas en el espacio de usuario permitiendo cambiarsu contenido dinamicamente. En la implementacion de esta version, XtratuMconstruye la tabla de paginas usando el area de memoria mas apropiado deuna manera estatica. Por lo que las particiones no necesitan reservar paginasde memoria. Esto se refleja en los siguientes cambios:

- Se modifica la cabecera de las particiones (struct xmImageHdr)

- Se actualiza la herramienta xmcparser para dar soporte a este modelo

- Se modifica el codigo de generacion del ejecutable para dar soporte almodelo

- Se consideran algunas hiperllamadas como obsoletas (XM_sparc_flush_tlb()),XM_set_page_type() and XM_update_page32())

- Se elimina el fichero kernel/sparcv8/physmm.c

3. Se arregla el controlador de bloque de memoria, eliminando la instruccion“lduba” que no esta implementada en los simuladores, aunque funciona en elhardware.

4. Se anade soporte para modificar la direccion del mapa de memoria fısico deXtratuM. Esto es, la direccion de carga y la direccion virtual de XtratuM.

5. Se modifica la manera de reiniciar las particiones. En versiones anteriores alreiniciar no se restauraba completamente la imagen de las particiones. En estaversion la imagen de la particion se restaura con la imagen contenida en elcontenedor del ejecutable.

58

CAPITULO 3. ADAPTACION DE ORK+ A XTRATUM 3

6. Se clarifica el estado del puerto de tipo “Sampling” cuando los mensajes sonnuevos o se han consumido

7. Se especifica las condiciones de un reinicio en la tabla de control de la particion,indicando el tipo de reinicio en el campo resetStatus.

8. Se modifican las siguientes hiperllamadas para adecuar los valores de retorno:XM_set_cache_state(), XM_suspend_partition(), XM_resume_partition(),XM_reset_partition() and XM_get_gid_by_name()

9. Se sustituye la definicion normal de las hiperllamadas XM_clear_irqpend(),XM_set_irqmask() and XM_clear_irqmask() por su definicion en ensambla-dor, definiendolas como static inline, para mejorar su rendimiento.

10. Se modifica la hiperllamada XM_clear_irqpend() para borrar las interrupcio-nes hardware pendientes, aparte de las interrupciones virtuales y extendidas.Esto si el fichero de configuracion dispone de las modificaciones correspondien-tes a estas interrupciones

11. Se modifica la hiperllamada XM_set_irqpend() para forzar como pendientesinterrupciones hardware, aparte de interrupciones virtuales y extendidas. Estosi el fichero de configuracion dispone de las modificaciones correspondientes aestas interrupciones

12. Se da soporte para el uso del bit EF del registro psr, incluyendolo en el psrvirtual de la particion. El manejo del bit es posible solo si se dispone de lacorrespondiente modificacion en el fichero de configuracion

13. Se clarifica el comportamiento de las hiperllamadas XM_sparc_inport() andXM_sparc_outport() para determinar el comportamiento cuando se definenlas mascaras de los puertos en el fichero de configuracion

14. Se arregla un fallo en el manejo del atributo mappedAt

15. Se restringe el uso de la hiperllamada XM_get_gid_by_name() para su uso enparticiones de sistema

3.1.2. Cambios realizados en ORK+

Del listado anterior, los unicos puntos que deberıan afectar al funcionamientodel kernel ORK+ son los puntos 9 y 12. Pero, como se explica en la seccion 3.1.3,el cambio del punto 4 produce un fallo en el funcionamiento correcto de ORK+, delque se ha tenido que encontrar su causa y dar una solucion.

La modificacion que se recoge en el punto 9, sobre el cambio de definicion, astatic inline, de algunas hiperllamadas para mejorar su rendimiento, implicaque el codigo de las funciones se inserte directamente en los sitios en los que serealiza la llamada pertinente. Esto requiere modificar el codigo del kernel de ORK+

59


puesto que desde Ada no es posible compilar de manera que se inserte el codigodirectamente en cada llamada a estas funciones. Para solucionar esto se ha de crearun envoltorio de cada una de estas funciones, de manera que al compilar, el codigode la funcion se inserta en la llamada que se realiza en el envoltorio y desde Ada yaes posible realizar llamadas a este envoltorio, que contiene el codigo insertado.

Para esto se han incluido dos ficheros al kernel, hypercalls.c y hypercalls.h, queincluyen la definicion de dichos envoltorios con las pertinentes llamadas a las fun-ciones definidas como static inline.

El contenido del fichero de cabecera hypercalls.h es el siguiente:

#define XM_ASMHYPERCALL_TRAP 0xF1

#include <xm_inc/arch/arch_types.h>

#include <xm_inc/hypercalls.h>

5 #include <sparcv8/xmhypercalls.h>

xm_s32_t XM_clear_irqmask_wrapper(xm_u32_t hwIrqsMask, xm_u32_t extIrqsMask);

xm_s32_t XM_set_irqmask_wrapper(xm_u32_t hwIrqsMask, xm_u32_t extIrqsMask);

xm_s32_t XM_clear_irqpend_wrapper(xm_u32_t hwIrqsMask, xm_u32_t extIrqsMask);

Listado 3.1: Contenido del fichero de cabecera hypercalls.h.

Y el contenido del fichero hypercalls.c es el siguiente:

1 #include "hypercalls.h"

xm_s32_t XM_clear_irqmask_wrapper(xm_u32_t hwIrqsMask, xm_u32_t extIrqsMask) {

return XM_clear_irqmask (hwIrqsMask, extIrqsMask);

}

6

xm_s32_t XM_set_irqmask_wrapper(xm_u32_t hwIrqsMask, xm_u32_t extIrqsMask) {

return XM_set_irqmask (hwIrqsMask, extIrqsMask);

}

11 xm_s32_t XM_clear_irqpend_wrapper (xm_u32_t hwIrqsMask, xm_u32_t extIrqsMask) {

return XM_clear_irqpend (hwIrqsMask, extIrqsMask);

}

Listado 3.2: Contenido del fichero hypercalls.c.

Por lo tanto en el codigo del kernel ORK+ se han de sustituir las llamadas aXM_clear_irqmask(), XM_set_irqmask y XM_clear_irqpend por XM_clear_irqmask_wrapper(),XM_set_irqmask_wrapper() y XM_clear_irqpend_wrapper() respectivamente. Es-to implica modificar el fichero s-bbxtra.ads.

La otra modificacion que se recoge en el punto 12, sobre el cambio para darsoporte al uso del bit EF1 en el registro virtual Processor State Register (PSR),

1El bit EF (Enable Floating-point) establece si es posible realizar uso de la unidad de comaflotante.

60


implica que el comportamiento de XtratuM sea como el comportamiento del hard-ware. Por lo que, no solo es necesario indicar en el fichero de configuracion xml quese permite que la particion correspondiente use la unidad de coma flotante, comose hace para la anterior version, sino que ademas por parte del sistema operativose debe realizar el correspondiente manejo del bit para habilitar o deshabilitar eluso de coma flotante para las distintas tareas que ejecuten, como se realiza para laejecucion en hardware directamente.

Esto ademas permite que se pueda realizar una optimizacion en el cambio decontexto de las tareas en cuanto a los registros de la unidad de coma flotante. Cuandouna tarea va a realizar uso de la unidad de coma flotante y el bit EF contiene un valor‘0’, que se establece en cada cambio de contexto, indicando que no esta habilitado eluso de la coma flotante, XtratuM eleva la correspondiente excepcion. Esta excepcionse propaga al sistema operativo de la particion correspondiente, en este caso ORK+,si se indica apropiadamente en el fichero de configuracion. Cuando el manejadorcorrespondiente recibe esta excepcion el sistema operativo comprueba que la tareapor la que se ha provocado la excepcion no sea la primera tarea en usar la unidadde coma flotante y que sea distinta de la tarea que estaba usando anteriormentela unidad. Si se cumplen estas condiciones se realiza el cambio de contexto de losregistros de coma flotante y se habilita el uso de la unidad poniendo a ‘1’ el bit EFdel registro virtual psr.

Para esto se ha anadido el fichero floating_point-bb-xtratum.S al kernel y seha modificado el fichero context_switch-bb-sparc.S. En este ultimo se ha elimi-nado el codigo que realizaba el cambio de contexto de los registros de coma flotante,que se realizaba cada vez. El fichero floating_point-bb-xtratum.S incluye unarutina de inicializacion de la unidad de coma flotante, que instala el manejador de laexcepcion correspondiente que realiza el cambio de contexto, y el propio manejadorque implementa el cambio de contexto.

El codigo de la rutina de inicializacion de la unidad es el siguiente:

initialize floating point :2 /∗ Se obtiene la direcci on donde instalar el manejador aeıou∗/

sethi %hi( traptab), %l1add %l1, %lo( traptab), %l1add %l1, 4∗4∗4, %l1

7 /∗ Se instalan las cuatro instrucciones del manejadorde la excepcion en la tabla de traps ∗//∗ sethi %hi(fp context switch ), %l3 ∗/sethi %hi(0x27000000), %l2sethi %hi(fp context switch ), %l3

12 srl %l3, 10, %l3add %l2, %l3, %l2st %l2, [ %l1 + 0∗4]

/∗ jmpl %l3 + %lo(fp context switch), %g0 ∗/

61


17 sethi %hi(0x81C4E000), %l2add %l2, %lo(fp context switch), %l2st %l2, [ %l1 + 1∗4]

/∗ Instrucci on ”nop”. En ORK+ para maquina desnuda en esta instruccion22 se lleva el contenido del registro psr al registro l0 . Esto ya lo hace

XtratuM ∗/sethi %hi(0x01000000), %l2add %l2, %lo(0x01000000), %l2st %l2, [ %l1 + 2∗4]

27

/∗ Instrucci on ”nop” ∗/sethi %hi(0x01000000), %l2add %l2, %lo(0x01000000), %l2st %l2, [ %l1 + 3∗4]

32

/∗ Por ultimo , se pone el hilo que esta ejecutando actualmentecomo el ultimo que ha usado la unidad de coma flotante . ∗/sethi %hi(running thread), %l0

sethi %hi( latest user ), %l137 ld [ %l0 + %lo(running thread)], %l2

st %l2, [ %l1 + %lo(latest user)]retlnop

Listado 3.3: Rutina de inicializacion de la unidad de coma flotante.

El codigo del manejador de la excepcion correspondiente al uso de la unidad decoma flotante es el siguiente:

fp context switch :/∗ Se habilita el uso de la unidad de coma flotante . ∗/

sethi %hi(PSR EF MASK), %l3or %l3, %lo(PSR EF MASK), %l3

5 or %l0, %l3, %l0mov %l0, %o1set sparc set psr nr , %o0

XM AHC

10 /∗ Se comprueba si es necesario realizar el context switch .Si el hilo que esta ejecutando es el mismo que el ultimo queha usado la unidad de coma flotante no es necesario realizarninguna operacion ∗/sethi %hi( latest user ), %l3

15 sethi %hi(running thread), %l5ld [ %l3 + %lo(latest user )], %l4

62


ld [ %l5 + %lo(running thread)], %l6cmp %l4, %l6be fp context switch done

20 nop

/∗ Se salva el estado de la unidad en el area correspondiente de la anterior tarea ∗/st %fsr, [ %l4 + FSR OFFSET]std %f0, [ %l4 + F0 F1 OFFSET]

25 std %f2, [ %l4 + F2 F3 OFFSET]std %f4, [ %l4 + F4 F5 OFFSET]std %f6, [ %l4 + F6 F7 OFFSET]std %f8, [ %l4 + F8 F9 OFFSET]std %f10, [ %l4 + F10 F11 OFFSET]



40

/∗ Se restaura el nuevo estado de la unidad desde elarea correspondiente de la tarea actual ∗/ldd [ %l6 + F0 F1 OFFSET], %f0ldd [ %l6 + F2 F3 OFFSET], %f2

45 ldd [ %l6 + F4 F5 OFFSET], %f4ldd [ %l6 + F6 F7 OFFSET], %f6ldd [ %l6 + F8 F9 OFFSET], %f8ldd [ %l6 + F10 F11 OFFSET], %f10ldd [ %l6 + F12 F13 OFFSET], %f12

50 ldd [ %l6 + F14 F15 OFFSET], %f14ldd [ %l6 + F16 F17 OFFSET], %f16ldd [ %l6 + F18 F19 OFFSET], %f18ldd [ %l6 + F20 F21 OFFSET], %f20ldd [ %l6 + F22 F23 OFFSET], %f22

55 ldd [ %l6 + F24 F25 OFFSET], %f24ldd [ %l6 + F26 F27 OFFSET], %f26ldd [ %l6 + F28 F29 OFFSET], %f28ldd [ %l6 + F30 F31 OFFSET], %f30ld [ %l6 + FSR OFFSET], %fsr

60

63


/∗ Se establece la tarea que esta usando actualmentela unidad de coma flotante ∗/st %l6, [ %l3 + %lo(latest user)]

65 fp context switch done :

/∗ Restore the original psr and return from trap ∗/set sparc iret nr , %o0

XM AHC70 nop

retlnop

Listado 3.4: Manejador de la excepcion en el uso de la unidad de coma flotante quepropaga XtratuM.

Puesto que se anaden nuevos ficheros al kernel, es necesario realizar modifica-ciones en el proceso de compilacion del mismo para incluirlos. Para esto se modi-fico el fichero Makefile.hie con el objetivo de compilar los ficheros hypercalls.c,hypercalls.h y floating_point-bb-xtratum.S.

3.1.3. Problemas encontrados

Con respecto al punto 4, hay que destacar que esto produce un fallo en el com-portamiento si la direccion virtual del comienzo de XtratuM no esta por encima dela direccion donde se carga en memoria. Este fallo se soluciona a la hora de construirXtratuM, en el proceso de configuracion. En concreto hay que configurar la direccionvirtual del comienzo de XtratuM para que este se encuentre por encima de la zonade memoria donde se carga. La solucion para el fallo fue aportada por el personalde desarrollo de XtratuM.

El fallo que se produce con este cambio, si la direccion de carga de XtratuMen memoria esta por encima de la direccion virtual del comienzo de XtratuM, esque XtratuM en las comprobaciones que realiza sobre el puntero de pila, cuando seproducen overflows y underflows en la ventana de registros, determina que su valores erroneo. Esto, aunque el puntero de pila tenga un valor correcto.

3.1.4. Bibliotecas

En esta version se anadieron dos paquetes para ser usados a nivel de aplicacion,por requerimientos de los proyectos. Estos paquetes se designaron como Xtratum.Ipcy Xtratum.PM. Con estos se proporcionan algunas de las facilidades necesarias pararealizar el uso de llamadas al sistema que permiten la comunicacion entre parti-ciones (“Inter Partition Comunication”) y la gestion de las mismas (“’PartitionManagement ’).

El paquete Xtratum.Ipc ofrece la siguiente interfaz de procedimientos:

64


procedure XM Create Queuing Port2 (PortName: in String ;

MaxNoMsgs: in Unsigned;MaxMsgSize: in Unsigned;Direction : in ModePort;Ret: out Port );

7 procedure XM Get Queuing Port Status(portDesc: in Port;Status : access Xmqueuingportstatus T;Ret: out RetType);

procedure XM Receive Queuing Message12 (portDesc: in Port;

message: out Stream Element Array;Ret: out ReadType);

procedure XM Send Queuing Message(portDesc: in Port;

17 message: in Stream Element Array;Ret: out RetType);

procedure XM Create Sampling Port(PortName: in String ;MaxMsgSize: in Unsigned;

22 Direction : in ModePort;RefreshPeriod : in Long Long Integer;Ret: out Port );

procedure Xm Get Sampling Port Status(portDesc: in Port;

27 Status : access Xmsamplingportstatus T;Ret: out RetType);

procedure Xm Read Sampling Message(portDesc: in Port;message: out Stream Element Array;

32 Flags : access unsigned;Ret: out ReadType);

procedure Xm Write Sampling Message(portDesc: in Port;message: in Stream Element Array;

37 Ret: out RetType);

Listado 3.5: Interfaz de procedimientos del paquete Xtratum.Ipc.

Con la que se puede hacer uso de todas las hiperllamadas para realizar comunica-cion entre particiones excepto XM_get_queuing_port_info y XM_get_sampling_port_info.Por lo que se pueden crear puertos, enviar y recibir informacion por los puertos yobtener el estado de la comunicacion, con ambos tipos de puerto, mediante una

65


interfaz Ada.El paquete Xtratum.PM ofrece la siguiente interfaz de funciones:

function Halt Partition (ID : Interfaces .C.unsigned)return RetType;

3 function Idle Selfreturn RetType;function Set Partition Opmode (Op Mode : OpMode)return RetType;function Get Partition Id

8 return Interfaces .C.unsigned;function Get Partition HwIrqsPendreturn Interfaces .C.unsigned;function Get Partition ExtIrqsPendreturn Interfaces .C.unsigned;

13 function Get Partition SlotDurationreturn Interfaces .C.unsigned;function Get Partition Opmode (Id : Interfaces .C.Unsigned;

Op Mode : access OpMode)return Integer ;

Listado 3.6: Interfaz de funciones del paquete Xtratum.PM.

Con la que se puede hacer uso de las hiperllamadas XM_halt_partition,XM_idle_self, XM_set_partition_opmode y se pueden obtener algunos campos dela tabla de control de la particion (PCT), cuyo acceso se obtiene a traves de lahiperllamada XM_params_get_PCT. Por lo que se puede detener una particion, sus-pender su ejecucion, hasta que reciba una interrupcion o comience el siguiente ciclodel plan, informar del estado interno de la particion, obtener el identificador de laparticion, obtener las interrupciones hardware pendientes, obtener las interrupcio-nes extendidas pendientes, obtener la duracion de la rodaja de la planificacion de laparticion y obtener el estado interno de la particion mediante una interfaz Ada.



El listado de la descripcion de las diferencias es el siguiente:

1. Se establece alineamiento a memoria en el contenedor, que es un fichero quecontiene todo el codigo, los datos y la informacion de configuracion de lasparticiones, para reducir el tamano extra de la imagen de XtratuM

2. Se arregla el fallo en la comprobacion del puntero de pila. Se detecta cuandola direccion virtual del comienzo de XtratuM esta por debajo de su direccionde carga en memoria

66


3. Se anaden comprobaciones en la hiperllamada XM_sparc_set_psr

4. Se anade una opcion de configuracion en el hipervisor XtratuM para habilitaro deshabilitar la operacion de enmascarar las interrupciones despues de quesean elevadas al manejador de la particion


Del listado anterior, el unico punto que deberıa afectar al funcionamiento delkernel ORK+ es el punto 4. Pero, como se explica en la seccion 3.2.3, el cambio delpunto 2, que se anadio para solucionar un fallo en la version anterior, produce otrofallo en el funcionamiento correcto de ORK+.

La modificacion que se recoge en el punto 4, sobre el cambio del tratamientode las interrupciones por parte de XtratuM, implica que es posible modificar elkernel ORK+ para no tener que desenmascarar las interrupciones en el codigo deaplicacion, desenmascarando la interrupcion correspondiente cuando se asocia a unmanejador. El cambio necesario para llevar a cabo esta caracterıstica consiste enmodificar el procedimiento Attach Handler, para desenmascarar la interrupcion quese quiere manejar. La modificacion se muestra en el siguiente fragmento de codigo,perteneciente al fichero s-bbinte.adb:

procedure Attach Handler (Handler : Interrupt Handler ; Id : Interrupt ID ) isbegin

...

Unmask Int (Id);

5 end Attach Handler;

Listado 3.7: Modificacion en el procedimiento Attach Handler para desenmasca-rar la interrupcion directamente cuando se asocia a un manejador.

El procedimiento Unmask Int tambien se anadio, con el objetivo dar un soportemas comodo a nivel del kernel para desenmascarar interrupciones. La interfaz deeste procedimiento es la que se muestra a continuacion, contenida en el ficheros-bbinte.ads:

procedure Unmask Int (Id : Interrupt ID );

Listado 3.8: Interfaz del procedimiento Unmask Int.

En esta version se anade una funcionalidad al kernel ORK+ para permitir forzaruna interrupcion. Tambien se completa la definicion de interrupciones extendidasque ofrece XtratuM.

La nueva funcionalidad ofrece la posibilidad de forzar una interrupcion tantohardware como extendida desde la aplicacion. En las versiones anteriores esto se

67


tenıa que realizar importando directamente la hiperllamada XM_set_irqpend desdeel codigo de aplicacion. Por lo que se ha modificado el paquete System.BB.Xtratum,que provee la interfaz necesaria para usar las funcionalidades de XtratuM. El cambiorealizado ha sido incluir el siguiente fragmento de codigo, que ofrece la interfaz a lafuncionalidad mencionada:

function Set IRQ (Hw Irq : Interfaces .C.unsigned;Ext Irq : Interfaces .C.unsigned) return Integer ;

pragma Import (C, Set IRQ, ”XM set irqpend”);

Listado 3.9: Interfaz al nuevo servicio anadido en el kernel ORK+ para forzaruna interrupcion.

La definicion de las interrupciones extendidas estaba incompleta. Por lo que se hacompletado anadiendo las que faltaban al fichero s-bbperi-xtratum.ads. El fragmentode codigo anadido es el siguiente:

Watchdog Timer : constant SBP.Interrupt ID := 34;2 Shutdown : constant SBP.Interrupt ID := 35;

Sampling Port : constant SBP.Interrupt ID := 36;Queuing Port : constant SBP.Interrupt ID := 37;Cyclic Slot Start : constant SBP.Interrupt ID := 40;

Mem Protect : constant SBP.Interrupt ID := 48;

Listado 3.10: Interrupciones extendidas que faltaban en la definicion que se en-cuentra en el fichero s-bbperi-xtratum.ads.

Estos cambios se propagan hasta la interfaz de Ada con la aplicacion, hasta lacapa GNARL. Este proceso se explica en la seccion 3.2.4.


En esta version se encontro un fallo que retraso bastante el trabajo ya que fueun error que por parte del personal de XtratuM no supieron determinar su causay resolverlo. El fallo tiene que ver con el cambio del punto 2 de la lista, que enprincipio es un cambio para solucionar un fallo anterior. Cuando se recibe estaversion de XtratuM lo primero que se hace es ver si hay algo que se ha de modificaren el kernel ORK+, despues ejecutar el conjunto de pruebas del que se dispone, paraverificar que el comportamiento sigue siendo correcto en cuanto a las funcionalidadesque se prueban, y por ultimo comprobar que los ejemplos que se tienen siguenfuncionando. Pues bien, despues de esto se comprobo que no habıa que hacer cambiosen el kernel de ORK+, que todos los ejemplos funcionaban correctamente, pero quehabıa algunas pruebas cuyo resultado no era el esperado. Una de estas era la pruebac_rf03_03.ada. La salida de esta prueba era:

68


---- c_rf03_03 Check that reads and updates of atomic and volatile

objects are performed directly to memory.

* c_rf03_03 assignment to atomic components of array affect

surrounding components.

=====================================================

*** ERROR: Test c_rf03_03 FAILED

=====================================================

En esta prueba se comprueba que todas las lecturas y modificaciones de objetosdeclarados como atomicos y volatiles se realizan directamente a memoria, que paraaquellos objetos declarados como atomicos las lecturas y modificaciones se realizande manera indivisible y se comprueba que las directivas al compilador pragma Packy pragma Atomic Components se pueden usar en conjunto.

Por esta descripcion de la prueba lo primero que se hizo es pensar que posiblescausas se podıan dar para que esto no estuviese funcionando. Pero tras discutirlo sellego a la conclusion de que no podıa ser un fallo en los accesos atomicos a memoria.Se corrompıa algun componente pero no era tema de accesos atomicos.

A continuacion, lo que se hizo es sustituir fichero a fichero, de la version 3.3.3a la version 3.4.0 hasta dar con el conjunto de ficheros que revertıan los cambiosnecesarios para que la prueba ejecutara correctamente. Este conjunto de ficheros seredujo a un unico fichero, el designado como entry.S y que se encuentra en la carpetaPATH_TO_XTRATUM/core/kernel/sparcv8. Por lo que se comunico este hecho alpersonal de XtratuM y se siguio en busca de la causa del error. Este fichero contenıael fallo en la comprobacion del valor del puntero de pila de la version 3.3.3, por loque habıa que configurar apropiadamente las direccion de carga de XtratuM y sudireccion virtual.

Para intentar acotar el error se intento depurar insertando mensajes para quese imprimieran por pantalla y ası determinar el flujo de ejecucion por el cual seproducıa el error. Pero con esto, curiosamente, se vio que el comportamiento delprograma se modificaba. Incluso se llegaba a conseguir que la prueba ejecutaradando un resultado satisfactorio.

Por lo que, puesto que no se podıa depurar de una manera rapida imprimiendomensajes, se siguio depurando con la herramienta gdb. Se determino que XtratuMmachacaba el valor del registro %g2, cuando se elevaba una excepcion de win-dow underflow o de window underflow. Por lo que se reviso el codigo que manejabaestas excepciones que se encontraba en el fichero entry.S y se dio con el error.

El siguiente codigo muestra las diferencias entre la version 3.3.3 y la version 3.4.0de uno de los fragmentos donde se encuentra el error introducido:

69


mov %g2, %l6 ! %g2 a %l6savemov %sp, %g2restore

5 wr %l5, %wimWR DELAYset CONFIG XM OFFSET, %l5cmp %g2, %l5

blu 1f10 nop

set 16*1024*1024, %l6 ! %l6 se sobreescribe

add %l5, %l6, %l5

cmp %g2, %l5

bgu 1f

15 mov %l6, %g2 ! %g2 se corrompe

Listado 3.11: Fragmento de codigo del ficheroentry.S de la version 3.4.0 de XtratuM.

mov %g2, %l6savemov %sp, %g2restore

5 wr %l5, %wimWR DELAYset CONFIG XM OFFSET, %l5cmp %g2, %l5bleu 1f

10

15 mov %l6, %g2

Listado 3.12: Fragmento de codi-go del fichero entry.S de la version3.3.3 de XtratuM.

Por lo que, como se muestra, como se realiza uso del registro %g2 se almacenasu valor en el registro %l6 para ser restaurado posteriormente. El problema esta enque tambien se realiza uso del registro %l6 antes de restaurar el valor en el registro%g2. Como consecuencia el valor del registro %g2 queda corrompido y deriva en uncomportamiento totalmente indeterminado del codigo que ejecuta sobre XtratuM.

Este problema se resolvio sustituyendo el registro %l6 por el registro %l4, quese comprobo que no se realizaba uso del mismo, en las siguientes instrucciones:

mov %g2, %l6...

mov %l6, %g2

Listado 3.13: Instrucciones del codigooriginal con el error de la version 3.4.0de XtratuM.

mov %g2, %l42 ...

mov %l4, %g2

Listado 3.14: Modificacion en las ins-trucciones que soluciona el error de laversion 3.4.0.

Con este cambio se soluciono el error y se consiguio que todas las pruebas tuvieranel resultado esperado.

3.2.4. Bibliotecas

Para esta version se completa la definicion de las interrupciones extendidas. Se hamostrado la modificacion que se ha realizado en el codigo del kernel, para completar

70


esta definicion. Aquı se muestran los cambios necesarios para propagar esta modifi-cacion hasta la interfaz de Ada con la aplicacion, hasta la capa GNARL. Ademas, seintroduce un nuevo paquete Ada en esta capa para proporcionar soporte, a nivel deaplicacion, a las operaciones de desenmascarar, enmascarar y forzar interrupcionesmediante las funciones Unmask IRQ, Mask IRQ y Set IRQ, respectivamente.

En primer lugar se ha de modificar el paquete System.OS Interface, que encapsulala interfaz a los servicios del sistema operativo, para propagar los cambios del kernel.Esta modificacion, por tanto, se realiza en el fichero s-osinte-bb-leon.ads.

A continuacion, se anadio el paquete Ada. Interrupts .Management, que ofrece lainterfaz de Ada a nivel de aplicacion de las funciones mencionadas. Este paquete seanade en los ficheros a-intman-xtratum.adb y a-intman-xtratum.ads. La interfazque ofrece es la siguiente:

function Unmask IRQ (Int Id : Interrupt ID ) return Integer ;function Set IRQ ( Int Id : Interrupt ID ) return Integer ;function Mask IRQ (Int Id : Interrupt ID ) return Integer ;

Listado 3.15: Interfaz del paquete Ada.Interrupts.Management.

Por ultimo, se completo la definicion de las interrupciones extendidas tambienen la interfaz de aplicacion de la capa GNARL, propagando los cambios del paqueteSystem.OS Interface. Para ello se realizo la correspondiente modificacion del paqueteAda. Interrupts .Names, contenido en el fichero a-intnam-xi-xtratum.ads.

Puesto que se anaden nuevos ficheros al kernel, como en la version del kernelORK+ para XtratuM 3.3.3, es necesario realizar modificaciones en el proceso de com-pilacion del mismo para incluirlos. Para esto se modifico el fichero Makefile.hie conel objetivo de compilar los ficheros a-intman-xtratum.adb y a-intman-xtratum.ads.



Esta version es la que incluye el soporte para arquitecturas multiprocesador.En un principio, se tenıa la idea puesto que no fue aclarado, de que la unica

diferencia con respecto a la ultima version para arquitecturas monoprocesador (ver-sion 3.4.0) era esta, el soporte para arquitecturas multiprocesador. Pero esta versionmultiprocesador no se desarrollo tomando como partida la ultima version monopro-cesador, si no la version 3.3.2. Por lo que se arrastra un listado de diferencias, quederivo en problemas que se comentan en la seccion 3.3.3.


Como se ha comentado, puesto que la unica novedad en el hipervisor de XtratuMera el soporte a arquitecturas multiprocesador, no se tuvo que modificar el codigo del

71


kernel ORK+, puesto que el soporte para arquitecturas multiprocesador quedabatransparente al sistema operativo, exceptuando hiperllamadas para uso a nivel deaplicacion.

Aunque no se indica en el apartado anterior, tambien hubo un pequeno cambio enla manera de compilar los fuentes de XtratuM. En esta version algunas declaraciones#include se cambiaron para hacer uso de una macro. Esta macro se pasa como unaopcion al compilador:-D"__XM_INCFLD(_fld)=<xm_inc/_fld>"

Por tanto, se tuvieron que realizar algunas modificaciones en el proceso de com-pilacion para incluir este cambio. Estas modificaciones se hicieron en el ficheroMakefile general y el fichero Makefile.hie.


Ya se ha comentado que el desarrollo de la version para arquitecturas multi-procesador no partio de la ultima version para arquitecturas monoprocesador. Estoademas no fue aclarado.

Por lo que, el principal problema fue que en la version 3.3.2, que es la versionque se ha usado para desarrollar la version 3.7.1, no hay soporte para el bit EF delregistro psr virtual de la particion. Este soporte se introdujo en la version 3.3.3,como se ha comentado. Esto implica que en la ejecucion de un programa, en el queejecutan varias tareas que hacen uso de la unidad de coma flotante, no se realice elcambio de contexto de los registros de esta unidad necesario para que el estado delas tareas sea consistente. Esto es porque se modifico el kernel ORK+ a partir de laversion 3.3.3, como se indica en la seccion 3.1.2, para que el cambio de contexto serealizase a traves del manejo de la excepcion correspondiente a la unidad. Para laversion 3.3.2 el comportamiento, en este respecto, de ORK+ era realizar el cambiode contexto de los registros de coma flotante cuando se realiza un cambio de contextogeneral.

Esto origino, obviamente, que algunos ejemplos no ejecutaran correctamente,pero se perdio bastante tiempo ya que no se sabıa donde podıa estar el problema.En un principio puesto que la unica diferencia que se tenıa en cuenta entre lasversiones de XtratuM era el soporte para arquitecturas multiprocesador, se penso queel problema podıa venir por este motivo. Igualmente se intento depurar imprimiendomensajes con el objetivo de obtener una traza de ejecucion que diese pistas del error,pero otra vez el comportamiento no era determinado. Por lo que se hizo uso de laherramienta de depuracion gdb y se determino que el error era precisamente que nose estaba realizando el cambio de contexto de los registros de coma flotante necesario.

Despues de encontrar el error se notifico del fallo al personal de desarrollo deXtratuM. Se realizo un parche sobre esta version para cambiar el comportamientoen cuanto al uso de la unidad de coma flotante tal y como se realiza en la ultimaversion para monoprocesador. Despues del cambio se determino que todo estabafuncionando correctamente.

72


3.3.4. Bibliotecas

En esta version se adapta el manejador para gestionar un dispositivo UART, yaque es con esta version con la que se quiere realizar el demostrador, que se pretendehaga uso de este dispositivo. Este manejador ya se disponıa para la version de ORK+para maquina desnuda. El trabajo preliminar realizado en este respecto, ha sido elestudio del dispositivo y del manejador.

Despues de este trabajo, se determinaron los cambios a realizar. Estos se deri-van de que con XtratuM cambia la manera en la que se realizan las operaciones deescritura y lectura de los registros del dispositivo y cambia el manejo de las inte-rrupciones. Ademas dado que en esta version XtratuM enmascara las interrupcionesdespues de que las maneje la particion, detalle que se cambio en la version 3.4.0,se cambia el modo en el que se obtienen los datos del buffer de recepcion con elobjetivo de no tener perdidas.

En cuanto a las operaciones de escritura y lectura, con XtratuM han de realizar-se mediante las hiperllamadas XM_sparc_outport y XM_sparc_inport respectivamente.Ademas, puesto que se quiere hacer uso de estas llamadas desde codigo Ada, se hade realizar una interfaz que importe estas funciones y que de tratamiento de excep-cion a los valores de error que notifiquen las operaciones. Un ejemplo del uso deestas llamadas en el manejador, comparandolo con el modo en el que se realiza paramaquina desnuda se puede ver a continuacion:

XM Sparc Inport (UART Control’Address,Control Aux);

Listado 3.16: Lectura del registro de control del dispositivo UART sobre Xtra-tuM.

Control Aux := UART Control;

Listado 3.17: Lectura del registro de control del dispositivo UART sobre maquinadesnuda.

Para activar la interrupcion correspondiente a la recepcion de datos a traves deldispositivo UART, se cambia la llamada Interrupt Mask por la llamada Unmask IRQ.Ademas puesto que XtratuM, en esta version, sigue teniendo el comportamiento deenmascarar la interrupcion cuando la maneja, cada vez que se ejecuta el manejadorde la interrupcion de la particion (RTI UART), este debe desenmascararla.

Por el motivo de tener que desenmascarar en cada ejecucion del manejador lainterrupcion correspondiente, se realiza una modificacion en el manejador para queen cada ejecucion lea todos los datos que tenga disponible el dispositivo en el buffer.Por tanto, con esta modificacion no se lee un dato en cada manejo de la interrupcion,como se hace para maquina desnuda, sino que en cada manejo se leen todos los datosposibles, con el objetivo de no tener perdidas. El numero de lecturas a realizar seobtiene del registro de estado, del campo RCTN, que indica el numero de tramas de

73


datos que hay en el buffer receptor. Con lo que, en el manejador se realiza un bucleque depende del valor de este campo.

74

Capıtulo 4

Verificacion

Para la comprobacion del correcto funcionamiento de los cambios realizados enla adaptacion de ORK+ se han ido disenando nuevos ejemplos de uso y adaptandolos ya existentes, en los casos en los que ha sido necesario. Tambien se ha adaptadoel conjunto de pruebas que se tiene para la ejecucion de ORK+ sobre maquinadesnuda.

Los ejemplos anadidos muestran el uso de los paquetes de gestion de particiones(Xtratum.PM) y de comunicacion entre particiones (Xtratum.Ipc). En los ejemplosya existentes, se han adaptado aquellos en los que los cambios en ORK+, debidos alas modificaciones en las distintas versiones de XtratuM, afectaban. Este es el casodel ejemplo “demo”, en el que se hace uso de las funcionalidades para el manejo deinterrupciones.

La adaptacion del conjunto de pruebas ha consistido, basicamente, en la mo-dificacion del proceso de compilacion para adaptarlo a ORK+ sobre XtratuM, delcodigo de soporte ofrecido para el uso de ciertas funcionalidades y del proceso deejecucion de las pruebas.

Para todos los ejemplos y las pruebas se ha elegido una region de memoria comun,dejando 3 MB para la memoria de las distintas particiones que contenga cada uno.Esto se realiza para simplificar su uso, ya que XtratuM ha de ser configurado ycompilado indicando estos valores, por lo que si no se hubiera establecido un esquemageneral por cada estructura de memoria diferente habrıa que tener una compilacionde XtratuM por cada configuracion correspondiente. El esquema general del mapade memoria de los ejemplos y pruebas se muestra en la figura 4.1.

75

4.1. EJEMPLOS DE USO

···

···

XtratuM512 KB

Espacio de memoriapara las particiones

3MB

Read-only 256 KB

Read-write 256 KB

0x40000000

0x40080000

0x40380000

0x403C0000

Figura 4.1: Mapa de memoria general para los ejemplos de uso y las pruebas deORK+ sobre XtratuM.

4.1. Ejemplos de uso

Se ha anadido un conjunto de ejemplos para mostrar el uso de las distintas fun-cionalidades que proveen los paquetes Xtratum.Ipc y Xtratum.PM.

Para el uso de este ultimo paquete se han realizado ejemplos muy sencillos, basa-dos en un programa que imprime un ”Hola mundo”por consola. Con estos se muestrael uso de las funcionalidades Halt Partition , para finalizar la ejecucion de una par-ticion, Idle Self , para suspender su ejecucion hasta que reciba una interrupcion ocomience el siguiente ciclo del plan y Set Partition Opmode, para informar del estadointerno de la particion.

En cuanto al uso del paquete Xtratum.Ipc, se han disenado ejemplos mas elabo-rados en los que se tienen hasta tres particiones comunicandose entre sı, a traves delos mecanismos provistos por el hipervisor XtratuM.

En los casos en los que se ha disenado el ejemplo con dos particiones, a cada unase le han asignado 1.5 MB. Para el diseno con tres particiones, a cada una se le haasignado 1 MB. Esto para conservar el mapa de memoria visto.

Se tienen ejemplos de uso tanto para los puertos de comunicacion de tipo “queuing”como para los de tipo “sampling”.

Para hacer uso de los puertos, estos han de ser declarados y asociados a las par-

76

CAPITULO 4. VERIFICACION

ticiones convenientemente en el fichero xml de configuracion. Se tienen que indicaren la tabla de puertos de la particion aquellos de los que va a hacer uso fijando sutipo y su direccion, es decir, estableciendo si la particion es origen o destino de lacomunicacion del puerto, como se muestra en el listado de codigo 4.1. A su vez, sedeclaran los puertos de los que hacen uso cada una de las particiones indicando eltamano maximo de mensaje, el nombre del puerto, la asociacion a cada una de lasparticiones indicando la direccion correspondiente y en el caso de los puertos de tipo“queuing” el numero maximo de mensajes que se pueden encolar, como se muestraen el listado de codigo 4.2.

<PartitionTable><Partition id=”0” name=”Partition0” flags=”system fp” console=”Uart”>

...<PortTable>

5 <Port name=”port1” type=”queuing” direction=”source” /></PortTable>

</Partition></PartitionTable>

Listado 4.1: Asociacion de puertos en la tabla de puertos de una particion en elfichero xml de configuracion.

<Channels>2 <QueuingChannel maxMessageLength=”64B” maxNoMessages=”30”>

<Source partitionId =”0” portName=”port1”/><Destination partitionId =”1” portName=”port1”/>

</QueuingChannel></Channels>

Listado 4.2: Declaracion de los puertos en el fichero xml de configuracion.

Para los de tipo “queuing” se han construido tres ejemplos. En uno, se tieneun emisor, que envıa dos bytes de informacion, y un receptor, que recibe dichosbytes. Con este ejemplo se prueba el envıo y recepcion de mensajes por el puerto detipo “queuing”. En otro, se tiene el mismo esquema emisor-receptor, pero el emisorencola un mensaje en el envıo, de dos bytes tambien, por lo que el receptor paraobtener todos los mensajes ha de realizar varias lecturas. Con este ejemplo se pruebael encolado de mensajes. En el que resta, se sigue teniendo el mismo esquema, perola escritura/lectura de mensajes se realiza en cada ciclo del plan cıclico. Esto se harealizado aportando a cada componente de la particion, al emisor y al receptor, unaplanificacion local de cada tarea con el mismo periodo que en la planificacion global.Con esto se prueba el conjunto en una ejecucion cıclica.

Los ejemplos de uso de las comunicaciones con puertos de tipo “sampling” sehan disenado con la misma estructura, con los mismos propositos excepto para el

77

4.1. EJEMPLOS DE USO

caso de la prueba de encolado, que en este caso se prueba la comunicacion entre masde 2 particiones, en concreto un emisor y dos receptores.

Ademas se ha disenado un ejemplo en el que se hace uso del manejo de la comu-nicacion mediante interrupciones. Para esto lo que se tiene que realizar es asociarla interrupcion correspondiente a un manejador mediante la directiva al compila-dor pragma Attach Handler. En Ada la forma de esperar por una interrupcion, esmediante objetos protegidos. Estos ofrecen, entre otros aspectos, mecanismos de es-pera por una condicion que se haga verdadera. Por lo que asociando la interrupciondel puerto correspondiente a un procedimiento que haga verdadera la guarda de laentrada en la que espera la tarea cada vez que se maneje la interrupcion se consigueel objetivo de operar mediante interrupciones.

Un ejemplo de codigo de un objeto protegido para llevar a cabo estas operacionesse muestra a continuacion:

protected Interrupt ispragma Priority (Ada. Interrupts .Names.Sampling Port Priority );entry Wait;

5 privateprocedure Signal ;pragma Attach Handler (Signal ,

Ada. Interrupts .Names.Sampling Port);Signaled : Boolean := False;

10 end Interrupt ;protected body Interrupt is

entry Wait when Signaled isbegin

Signaled := False ;15 end Wait;

procedure Signal isbegin

Signaled := True;end Signal ;

20 end Interrupt ;

Listado 4.3: Codigo de ejemplo de un objeto protegido para manejar la interrup-cion de un puerto de tipo “sampling”.

Como se muestra se tiene un procedimiento privado al objeto protegido, Signal ,que se asocia a la interrupcion correspondiente al puerto. Luego se tiene una entrada,Wait, a traves de la cual se tiene acceso cuando el procedimiento anterior haceverdadera la guarda. Una vez este acceso es obtenido, se vuelve hacer falsa la guarday se repite el proceso.

Con el objetivo de aclarar la estructura del ejemplo, esta se muestra en la figura4.2.

78

CAPITULO 4. VERIFICACION

Partición EmisoraAplicación Emisora

ORK+

Partición ReceptoraAplicación Receptora

ORK+

"samplingport"

XtratuM

Computador de a bordo

OP Interrupt

entry WaitSignal

Tarea Receptora

Es TareaEmisora

P

commonhandler

Es : EsporádicaOP : Objeto Protegido

P : PeriódicaT : Periodo T

T

Figura 4.2: Estructura del ejemplo de manejo del puerto de tipo “sampling” porinterrupciones.

Tambien se han realizado modificaciones en los ejemplos existentes para adecuarsu proceso de compilacion. Y en concreto en el ejemplo “demo” se han realizadomodificaciones adicionales, ya que muestra el uso de la gestion de interrupciones enAda, entre otras cosas, y este aspecto cambia entre ORK+ para maquina desnuda yORK+ para XtratuM. En el ejemplo se fuerza una interrupcion externa a traves dela cual se simula el comportamiento esporadico de una de las tareas. Para forzar unainterrupcion, como se indica en la seccion 3.2.4, se introdujo la funcion Set IRQ ypara la versiones en las que XtratuM sigue enmascarando las interrupciones despuesde manejarlas, se introdujo la funcion Unmask IRQ, cuyas interfaces son accesiblesa nivel de aplicacion a traves del paquete Ada. Interrupts .Management. Por lo que lamodificacion consiste en reemplazar las partes correspondientes.

4.2. Pruebas de validacion

Para ORK+, sobre maquina desnuda, se dispone de una serie de pruebas queverifican que las violaciones de las restricciones del perfil de ravenscar provoquen quela prueba correspondiente no compile, demuestran que se realizan correctamente lasrestricciones aplicadas por este perfil, demuestran que se puede realizar uso de lassemanticas dinamicas de este perfil y prueban las semanticas del lenguaje Ada 95.

Las pruebas en sı no se han modificado sino el soporte del que se valen parahacer uso de la virtualizacion de interrupciones externas, el proceso de compilacionde los mismos y el proceso de ejecucion.

En cuanto a la virtualizacion de interrupciones externas la modificacion es lamisma que se ha realizado para el ejemplo “demo”.

79

4.2. PRUEBAS DE VALIDACION

En cuanto al proceso de compilacion se han anadido el fichero de configuracionxml (xm_cf.sparcv8.xml) y el fichero de montaje (boot.S) correspondientes. Se haanadido un fichero Makefile que sirva para generar el ejecutable que se carga en elsimulador para verificar la prueba. Y por ultimo se han anadido una serie de scriptspython, a los existentes, para facilitar la ejecucion de todas las pruebas en conjunto.

Por ultimo, se ha modificado el proceso de ejecucion para anadir la opcion -mmu

en el mandato del simulador tsim-leon3, necesaria ya que se realiza uso de estaunidad, y para sustituir el nombre del ejecutable que de forma general en el procesode compilacion de una aplicacion para ORK+ sobre XtratuM se ha venido a llamarresident_sw.

80

Capıtulo 5

Aplicacion de demostracion

En este capıtulo se muestra la aplicacion de demostracion desarrollada para suuso en vuelo. Este desarrollo compone el principal objetivo del trabajo fin de carreracon el que se quiere tambien presentar la infraestructura que se ha utilizado parallevarlo acabo.

La aplicacion de demostracion tiene la estructura de la figura 5.1.

Partición ADCS

Aplicación ADCS

ORK+

Partición E/S

Aplicación E/S

ORK+

XtratuM

ManejadorUART

Simulador

Modelo ADCS

Simulink/Matlab

Computador de a bordo

MagnetoparesMagnetómetros

SistemaOperativo

Computador de simulación

"samplingport"

Tarea ADCS

P

TOP Interrupt

entry WaitActivate

Tarea E/S

Es

commonhandler

Es : EsporádicaOP : Objeto Protegido

P : PeriódicaT : Periodo T

Figura 5.1: Estructura de la aplicacion de demostracion para su uso en vuelo

Como se puede ver la aplicacion consta de dos particiones que ejecutan cada unasobre ORK+, que interacciona con el hardware a traves del hipervisor XtratuM.Por un lado se tiene la particion que contiene la logica del control de actitud delmicrosatelite UPMSat-2, que se describe con mas detalle en la seccion 5.1, y porotro lado se tiene la particion de entrada/salida. Esta ultima es la particion que seencarga de interaccionar con el entorno del microsatelite, a traves de los disposi-tivos correspondientes. En este caso, el entorno esta simulado con la herramientaSimulink/Matlab con la que la particion se comunica a traves de la lınea serie.

El control de actitud ha sido modelado en Simulink por el personal de aeronauti-cos del instituto Ignacio Da Riva. Por lo que, parte del trabajo se trata de generar el

81

5.1. MODELO ADCS

codigo de este subsistema del microsatelite e incluirlo en una tarea Ada que puedaejecutar sobre ORK+.

En las siguientes secciones se describe el modelo del control de actitud y se ex-plica el proceso de desarrollo seguido para construir la aplicacion de demostracion.Por tanto se muestra la fase de generacion de codigo del subsistema modelado enSimulink, la fase de integracion de este codigo en una tarea Ada, que pueda ejecu-tar en la particion de control sobre ORK+, y las modificaciones necesarias tantoen el modelo de Simulink como en la tarea Ada, que contiene la particion de en-trada/salida, para poder realizar una ejecucion de la infraestructura en un entornoHardware-in-the-loop. Ası mismo, en lo que se muestra de esta ultima fase se indi-can las configuraciones necesarias tanto en lo que respecta a las particiones, a travesde los ficheros xml de configuracion correspondientes, como a la configuracion deXtratuM a la hora de construirlo.

5.1. Modelo ADCS

El control y determinacion de la actitud del satelite es el componente principalde la aplicacion. La actitud de un satelite es la orientacion de este hacia el planetaTierra. Esta orientacion es basica para que la posicion de las antenas sea lo mas be-neficiosa posible con respecto a la comunicacion con tierra y para ofrecer la maximasuperficie de paneles solares a la luz solar para obtener la energıa necesaria con elobjetivo de operar correctamente.

Para mantener el satelite orientado correctamente se ha de, en primer lugar, cal-cular la orientacion de este y sobre esta computar y ejecutar una posible actuacionpara reorientar el satelite. Este proceso ha de ser llevado a cabo periodicamente(con una frecuencia de 1 Hz en el caso concreto del UPMSat-2) para contrarrestarlas diferentes perturbaciones que afectan a la dinamica del satelite, siendo las masimportantes el gradiente gravitatorio terrestre, la presion aerodinamica y de la ra-diacion solar, el campo magnetico terrestre, la emision de partıculas y radicaciondel satelite y los equipos moviles o lıquidos que pudiera haber abordo.

Para el calculo de la orientacion de un satelite en el espacio existen varios siste-mas:

Mediante la localizacion de un numero de estrellas tomadas como guıa.

Mediante el calculo del horizonte terrestre.

Mediante la medida del campo magnetico terrestre.

Las dos primeras opciones requieren informacion grafica para su uso y sus algo-ritmos son mas complejos. Sin embargo, en el caso del calculo del campo magneticoterrestre unicamente se requieren tres pares de magnetopares y un modelo del campomagnetico para su cotejo con las lecturas de los magnetopares. Estos tres pares ob-tienen una medida en tres ejes, suficiente para calcular de forma completa el angulode orientacion hacia la tierra. Este ultimo metodo es el usado en el UPMSat-2.

82

CAPITULO 5. APLICACION DE DEMOSTRACION

La computacion de los datos obtenidos se lleva a cabo por el codigo generado porla herramienta de diseno Simulink. Este codigo se ha generado a partir del bloquefuncional “controller” del modelo [5, 16, 15] mostrado en la figura 5.2, siguiendo lospasos que se indican en la seccion 5.2. Este codigo, generado en C, se importa alcodigo Ada mediante los mecanismos ofrecidos por el kernel. Mediante este codigose calcula la orientacion actual del satelite y si es necesario ejercer algun tipo deaccion para corregirla. En la seccion 6 se incluyen los resultados y el calculo deltiempo de ejecucion a modo de comprobacion del entorno de validacion software(SVF) construido.

gravitygradient"torque"

perturbation"torque"

PM dipole"

Earth magnetic

field"

Spacecraft dynamics"

1

1

cross product" 1

controller!1

B_dot"

B_b_T"

T_pm"

T_perturbation"

quaternion"

T_Nm"

I_A"

pqr_rad/s"

omega_rad/s"

C_BV"

Figura 5.2: Modelo del control y determinacion de la actitud del satelite.

En el caso del UPMSat-2, para mantener una correcta orientacion se disponede dos mecanismos, uno pasivo y otro activo. El mecanismo pasivo consiste en unconjunto de imanes que, debido al campo magnetico terrestre, generan una fuerzasuficiente como para mantener, bajo determinadas circunstancias, en una orienta-cion adecuada al satelite. Ademas, son vitales para, tras el lanzamiento, detener laalta velocidad de giro que el satelite adquiere tras su liberacion de la capsula delanzamiento. Debido a esta alta velocidad, los sistemas activos no son adecuados,ya que no serıa posible adquirir los datos necesarios y operar los actuadores a talvelocidad.

Los mecanismos activos consisten en tres magnetopares (uno por eje, al igual quelos magnetometros). Estos magnetopares son pares de bobinas de cobre recubiertode kapton que generan un campo magnetico propio que interactua con el campo

83

5.2. GENERACION DE CODIGO

magnetico terrestre haciendo girar al satelite sobre su propio eje.

El campo magnetico, por su naturaleza, fluctua a lo largo de la trayectoria orbitaldel satelite, siendo esta fluctuacion maxima en las regiones polares, donde tanto laintensidad como el angulo del campo magnetico varıa rapidamente. De igual modo,ciertas fluctuaciones sobre el modelo teorico se producen sobre ciertas regiones delglobo, debido a la tectonica de placas y los materiales existentes en esas areas. Portanto, para que la aplicacion de demostracion ejecute bajo todas las posibles con-diciones del entorno, al menos, debe abarcar la simulacion de una orbita completa,que son cerca de 2 horas en la orbita que esta a la altura de 600 km.

5.2. Generacion de codigo

En esta seccion se introduce el proceso de generacion de codigo, su configuracionpara una correcta integracion en ORK+, posteriormente, y una descripcion de lasestructuras y componentes generados. Ya que la configuracion se hace a traves de laherramienta Simulink, se incluyen capturas de los pasos a seguir. Hay que destacarque hay multiples opciones de configuracion, por lo que se ha intentado determi-nar las opciones que permiten generar codigo que se pueda integrar como primeraaproximacion, pero se trabaja tambien en el estudio de ver del resto de opciones siinteresa anadirlas o no al proceso. Por lo que a continuacion se indican las opcionesbasicas de generacion de codigo.

5.2.1. Proceso

Primero se ha de realizar una configuracion de las necesidades para generar codi-go. Para esto se ha de abrir la ventana de configuracion de parametros (ConfigurationParameters) del modelo(Figura 5.2), a traves del menu de simulacion (Simulation)(Figura 5.3)

Figura 5.3: Menu del modelo ADCS

En esta ventana es necesario configurar el tipo de paso que se realiza en lasimulacion, para que sea un paso fijo ya que estamos en un entorno de simulaciondiscreto no continuo. Para esto se pincha en la pestana Solver y se configura como“Fixed-step” el campo “Type” de la seccion “Solver Options”, como se muestra enla siguiente figura:

84


Figura 5.4: Configuracion de las opciones del paso de ejecucion

Hay que asegurarse que en la configuracion de optimizacion no esta habilitadala opcion “Block Reduction”, puesto que si esta habilitada esta opcion Simulink nogenera codigo para acumuladores (bloques de constantes, bloques de suma, ...) entreotros aspectos. Por lo que en la seccion “Optimization” en el campo “Simulation andcode generation” se deshabilita esta opcion y se deja como se indica en la siguientefigura:

Figura 5.5: Configuracion de las opciones de optimizacion

Se pueden elegir distintos tipos de objetivos para la generacion de codigo, esdecir, Simulink ofrece la posibilidad de generar codigo ajustado a las necesidadesdel entorno donde se va a ejecutar ese codigo. En este caso se ha elegido el entorno“Embedded Coder”, para el que se genera codigo C. Para realizar este paso, en laseccion “Code Generation” se configura el campo “Target selection” buscando laopcion a traves del menu que ofrece al pinchar en “Browse...”, como se muestra enla siguiente figura:

Figura 5.6: Seleccion del entorno donde va a ejecutar el codigo

Si no interesa que compile el codigo generado, como es el caso, en esta mis-ma seccion se puede habilitar la opcion “Generate code only”, como se muestra acontinuacion:

Figura 5.7: Deshabilitar la opcion de compilacion del codigo generado

85


Si se quiere ver como usar el codigo generado, se puede indicar que Simulinkgenere un programa principal de ejemplo, para la ejecucion en una placa de ejemplo.Para esto en la seccion “Templates”, seleccionar en el campo “Custom templates” laopcion “Generate an example main program” y “BareBoardExample” como sistemaoperativo objetivo, como se muestra a continuacion:

Figura 5.8: Generacion de un programa principal de ejemplo

Por ultimo se puede indicar a Simulink que al finalizar la generacion de codigogenere tambien un informe de la misma. Para esto en la seccion “Report”, habilitarla opcion “Create code generation report”, como se muestra a continuacion:

Figura 5.9: Habilitar informe de generacion de codigo

Despues de la configuracion ya se puede generar el codigo del subsistema delmodelo que interesa, que se muestra en la siguiente figura:

Figura 5.10: Subsistema del modelo. ADCS del microsatelite

Para esto pinchar en el bloque con el boton derecho, seleccionar el menu “CodeGeneration” y a continuacion la opcion “Build Subsystem...”. Este inicializara elproceso de compilacion interno del modelo de Simulink para comprobar entre otrascosas, que no hay bloques desconectados, y mostrara una ventana con el resumenque incluye, entre otras cosas, las variables de las que se pueden configurar su modode almacenamiento (“inlined”, “importedExtern”, etc), como se muestra a conti-nuacion:

86


Figura 5.11: Generacion del codigo del subsistema

Pinchando en “Build” se generara el codigo.

5.2.2. Descripcion

Despues de haber visto el proceso de generacion de codigo, en esta seccion se vaa explicar su estructura y las partes principales.

El contenido de la carpeta (“control ert rtw” en este caso) donde se ha generadoel codigo, tiene que ser similar al siguiente:

$ ls

buildInfo.mat control.h control_types.h modelsources.txt

codeInfo.mat control.mk defines.txt rtw_proj.tmw

control.c control_private.h ert_main.c rtwtypeschksum.mat

control_data.c control_ref.rsp html rtwtypes.h

Simulink genera una serie de definiciones de estructuras en el fichero de cabe-cera(control.h en este caso), que constituyen las entradas y salidas del subsistema,los diferentes espacios de almacenamiento definidos en el modelo, como variablespara depuracion, visores de simulacion, etc, y los parametros del subsistema. Lasestructuras principales en este caso son (se puede ver de donde viene su definicionen el modelo por los comentarios que deja Simulink con sus etiquetas):

La estructura control U contiene todas las entradas de datos (B b T y B dot1).El siguiente codigo es la definicion de la interfaz abstracta de estructura con-trol U.

typedef struct {

real_T B_b_T[3]; /* ’<Root>/B_b_T’ */

real_T B_dot1[3]; /* ’<Root>/B_dot1’ */

} ExternalInputs_control;

5 extern ExternalInputs_control control_U;

La estructura control Y contiene todas las salidas de datos (T Nm y I A). Elsiguiente codigo es la definicion de la interfaz abstracta de estructura control Y.

87


typedef struct {

real_T B_b_T[3]; /* ’<Root>/B_b_T’ */

real_T B_dot1[3]; /* ’<Root>/B_dot1’ */

} ExternalInputs_control;

5 extern ExternalOutputs_control control_Y;

La estructura control P contiene todas todos los parametros del modelos(constantes, ganancias, valores iniciales, etc). El siguiente codigo es la defini-cion de la estructura control P.

Parameters_control control_P = {

0.0, /* Expression: 0

* Referenced by: ’<S3>/Constant’ */

-5.0E+6, /* Expression: -5e6

5 * Referenced by: ’<S3>/Gain’ */


* Referenced by: ’<S3>/Constant1’ */

100.0, /* Expression: n_mt

* Referenced by: ’<S7>/n’ */

10 0.25, /* Expression: A_mt

* Referenced by: ’<S7>/n1’ */


* Referenced by: ’<S4>/Saturation’ */

-5.0, /* Expression: -5

15 * Referenced by: ’<S4>/Saturation’ */

100.0, /* Expression: n_mt

* Referenced by: ’<S8>/n’ */

0.25 /* Expression: A_mt

* Referenced by: ’<S8>/n1’ */

20 };

Las estructuras de entradas y salidas del subsistema estan declaradas como ex-ternas. Esto es interesante desde el punto de vista de la integracion, porque permitedeclarar las variables desde un punto de acceso fuera del codigo generado y utilizarlasdentro del algoritmo de control exportandolas, como se vera mas adelante.

La siguiente funcion, declarada en el fichero control.c, es la funcion que realiza encada activacion el control y la determinacion de la actitud del satelite dependiendode las entradas del modelo recibidas:

/* Model step function */

void control_step(void)

{

/* local block i/o variables */

5 real_T rtb_Saturation[3];

real_T rtb_jxk;

real_T rtb_Sum_idx;

real_T rtb_Sum_idx_0;

10 rtb_jxk = control_P.n_Value * control_P.n1_Value;

88


rtb_Saturation[0] = control_P.Constant_Value / rtb_jxk;

rtb_Saturation[1] = control_P.Gain_Gain * control_U.B_dot1[1] / rtb_jxk;

rtb_Saturation[2] = control_P.Constant1_Value / rtb_jxk;

15

rtb_Saturation[0] = rtb_Saturation[0] >= control_P.Saturation_UpperSat ?

control_P.Saturation_UpperSat : rtb_Saturation[0] <=

control_P.Saturation_LowerSat ? control_P.Saturation_LowerSat :

rtb_Saturation[0];

20 rtb_Saturation[1] = rtb_Saturation[1] >= control_P.Saturation_UpperSat ?

control_P.Saturation_UpperSat : rtb_Saturation[1] <=


rtb_Saturation[1];

rtb_Saturation[2] = rtb_Saturation[2] >= control_P.Saturation_UpperSat ?

25 control_P.Saturation_UpperSat : rtb_Saturation[2] <=


rtb_Saturation[2];

rtb_jxk = control_P.n_Value_h * control_P.n1_Value_e;

30

rtb_Sum_idx_0 = rtb_Saturation[0] * rtb_jxk;

rtb_Sum_idx = rtb_Saturation[1] * rtb_jxk;

rtb_jxk *= rtb_Saturation[2];

35 control_Y.T_Nm[0] = rtb_Sum_idx * control_U.B_b_T[2] - rtb_jxk *

control_U.B_b_T[1];

control_Y.T_Nm[1] = rtb_jxk * control_U.B_b_T[0] - rtb_Sum_idx_0 *

control_U.B_b_T[2];

control_Y.T_Nm[2] = rtb_Sum_idx_0 * control_U.B_b_T[1] - rtb_Sum_idx *

40 control_U.B_b_T[0];

control_Y.I_A[0] = rtb_Saturation[0];



45 }

Por ultimo, tambien es interesante destacar que Simulink genera una funcionde inicializacion del estado del controlador, que se incluye a continuacion, dondese inicializan las entradas y salidas del subsistema y otras estructuras de control yestado:

/* Model initialize function */

void control_initialize(void)

{

/* Registration code */

5

/* initialize error status */

rtmSetErrorStatus(control_M, (NULL));

/* states (dwork) */

10 (void) memset((void *)&control_DWork, 0,

sizeof(D_Work_control));

89

5.3. INTEGRACION EN ORK+

/* external inputs */

(void) memset((void *)&control_U, 0,

15 sizeof(ExternalInputs_control));

/* external outputs */

(void) memset((void *)&control_Y, 0,

sizeof(ExternalOutputs_control));

20 }

5.3. Integracion en ORK+

En esta seccion se introduce el proceso de integracion del codigo generado porSimulink en el kernel de tiempo real ORK+. Este proceso abarca las fases de compi-lacion del codigo generado e integracion del modelo en la tarea Ada de la particionde control para ejecutar en ORK+ sobre XtratuM.

Para compilar el codigo generado por Simulink, como primera fase del proceso, setiene que disponer de la herramienta correspondiente sparc-elf-gcc. Si se disponede ella, la compilacion se realiza de la siguiente forma:

cd control_ert_rtw/

sparc-elf-gcc -c -g control.c

sparc-elf-gcc -c -g control_data.c

Para poder integrar el codigo generado en una tarea Ada que ejecute en laplataforma deseada, se han de importar las funciones de paso y de inicializaciongeneradas y exportar las variables de entrada/salida para poder manejarlas desdela tarea. Por este motivo es importante que Simulink genere estas estructuras decontrol como externas, porque permite gestionar esas estructuras desde un puntoexterno al codigo generado. Para poder realizar estas operaciones de importacion yexportacion de codigo C en Ada se hace uso de las directivas al compilador pragmaImport y pragma Export.

Entonces para importar las funciones mencionadas, este es el codigo Ada que lorealiza:

−− Procedimiento para inicializar el modeloprocedure initialize ;pragma Import (C, initialize , ” control initialize ”);−− Procedimiento de paso

5 procedure Control ;pragma Import (C, Control, ” control step ”);

Para exportar las variables indicadas, este es el codigo Ada que lo realiza:

90


−− Estructura control Utype ExternalInputs control is

record4 B b T : Vector Double;

B dot1 : Vector Double;end record ;−− Estructura control Ytype ExternalOutputs control is

9 recordT Nm : Vector Double;I A : Vector Double;

end record ;

Una vez se tiene acceso a las funciones del controlador y se pueden manejar lasentradas y salidas ya es posible construir completamente la tarea periodica Ada.En esta seccion solo se dan las indicaciones para integrar el codigo generado porSimulink en ORK+, pero obviamente lo que se quiere realizar finalmente es unaejecucion en la que intervenga el controlador del satelite ejecutando en la placa deingenierıa, el simulador que emule el entorno real del mismo y que intercambien losdatos necesarios.

5.4. Hardware-in-the-loop

En la seccion 5.4 se describe la tecnica que se ha usado para la ejecucion dela aplicacion de demostracion que se ha construido. Como se ha visto, esta tecnicarequiere una capa de comunicacion entre el simulador y el hardware que se quiereprobar. Pues bien como se ha comentado en la primera aproximacion del problemaesta capa de comunicacion se implementa sobre el dispositivo de comunicacion serieUART. En las secciones siguientes se van a detallar los anadidos y modificacionesnecesarias para llevar a cabo la implementacion de esta capa de comunicacion.

5.4.1. Manejador del dispositivo UART

Este componente software es esencial en la infraestructura construida, puestoque es el que da soporte a la capa de comunicacion. Ya se ha comentado en la sec-cion 2.9, de manera general, el comportamiento del dispositivo y las configuracionesdel manejador necesarias para poder usarlo en una plataforma con un procesadorLEON3. Tambien se ha apuntado, en la seccion 3.3.4, que se ha realizado una adap-tacion del mismo para poder ser usado sobre el hipervisor XtratuM. A continuacionse muestra la interfaz del manejador que se provee con el paquete Ada Generic Uart:

package Generic Uart is

Base Address : constant Interfaces .Unsigned 32 := 16#...#;

91


UART Interrupt ID : constant Ada. Interrupts . Interrupt ID := ...;5 UART Interrupt Level : constant System. Interrupt Priority := ...;

Block : constant Boolean := True;Receiver Buffer Size : constant Positive := 256;Transmit Buffer Size : constant Positive := 256;UART CPU : constant System.Multiprocessors.CPU := ...;

10 Clock Frequency : constant Positive := ...;type Parity Check is (None, Even, Odd);subtype Byte is Interfaces .Unsigned 8;

procedure Set15 (Rate : Integer := 9600;

Parity : Parity Check := None;Flow : Boolean := False );

procedure Write (Data : Ada.Streams.Stream Element Array;20 Success : out Boolean);

procedure Read (Data : out Ada.Streams.Stream Element Array;Last : out Ada.Streams.Stream Element Offset);

25 end Generic Uart ;

Se tienen distintas constantes para configurar la UART, en cuanto a parame-tros hardware, un procedimiento para configurar la UART, en cuanto a parametrosde funcionamiento, otro para escribir a traves del dispositivo y otro para leer. Elprocedimiento “Set” es necesario usarlo para abrir el puerto del dispositivo.

En cuanto a los parametros de configuracion hardware, se dispone de una cons-tante que especifica la CPU. Esto es porque el manejador se puede adaptar tambienpara arquitecturas multiprocesador, aunque como no es el caso simplemente se co-menta:

−− UART CPU : constant System.Multiprocessors.CPU := ...;

Por lo que primeramente hay que especificar los distintos parametros de confi-guracion de la arquitectura que se van a usar:

Base Address : constant Interfaces .Unsigned 32 := 16#80000100#;UART Interrupt ID : constant Ada. Interrupts . Interrupt ID :=Ada. Interrupts .Names.UART 2 RX TX;

4 UART Interrupt Level : constant System. Interrupt Priority :=Ada. Interrupts .Names.UART 2 RX TX Priority;

Listado 5.1: Valores de los parametros de configuracion del manejador del dis-positivo UART.

92


Por defecto el manejador configura la UART, en cuanto a los parametros defuncionamiento, con una velocidad de 9600 baudios, sin paridad y sin control deflujo. Estos parametros se han dejado con su valor por defecto para la aplicacion dedemostracion.

Una vez se tiene configurado el paquete, con el objetivo de hacer uso del dis-positivo hardware, se tienen que realizar una serie de configuraciones a nivel de laparticion de entrada/salida, a traves de los ficheros xml de configuracion, y a nivelde XtratuM, a traves de su menu de configuracion.

En la configuracion de las particiones, se tiene que especificar que se reservanlos recursos hardware correspondientes al uso del dispositivo. Esto se realiza con elsiguiente fragmento de codigo, para el caso de la UART:

<HwResources><IoPorts><Range base=”0x80000100” noPorts=”16”/>

</IoPorts>5 <Interrupts lines =”2”/></HwResources>

Listado 5.2: Fragmento del fichero de configuracion xml necesario para reservarlos recursos hardware requeridos.

Como se muestra, por un lado se reservan los puertos necesarios para manejarel dispositivo, es decir, sus registros de control y por otro lado se reserva la lınea deinterrupcion asociada.

Es necesario configurar XtratuM, ya que por defecto estos recursos hardware sereservan para el manejo por parte del hipervisor. Por lo que, en su configuracion se hade deshabilitar el uso del manejador del dispositivo y del puerto DSU asociado. Estose realiza a traves del menu de configuracion, en la seccion “Drivers”, deshabilitandolas opciones “Enable UART driver” y “DSU samples UART port”.

5.4.2. Prueba del dispositivo UART

Para probar que las configuraciones realizadas para el uso del dispositivo fun-cionan, se ha desarrollado un “Hola mundo”. Este programa implementa una tareaperiodica Ada que en cada activacion recibe un caracter por la lınea serie (a travesdel dispositivo UART) y lo reenvıa por la misma lınea serie. Por lo que escribiendo“Hola mundo” en el computador de simulacion por el puerto ttyUSB correspondien-te conectado al hardware que se quiere probar, en el lado de este hardware se debenrecibir cada uno de los caracteres en orden (secuencia “Hola mundo”). Y estos ca-racteres se han de volver a escribir por la misma lınea serie, segun se van recibiendo,de modo que se puedan leer en la entidad de simulacion.

El codigo de la tarea del programa es el siguiente:

93


task body Periodic isPeriod : constant Time Span := Milliseconds (100); −− 100msNext : Time := Clock;

4 −− Dato para intercambiarData : Stream Element Array (0..0);−− Variable para la operacion de lectura , no usadaLast : Stream Element Offset;−− Variable de estado para la operacion de escritura

9 Success : Boolean;begin−− Apertura del puerto serie configurado a 9600 baudiosSet (Rate => 9600);loop

14 Next := Next + Period;delay until Next;Read (Data, Last);Write (Data, Success);

end loop;19 end Periodic ;

Listado 5.3: Codigo de la tarea del programa “Hola Mundo”:

Como se puede ver cada 100 ms la tarea espera recibir un dato de la lınea serie,que son 8 bits, y cuando lo recibe lo escribe por la misma a una velocidad de 9600baudios.

Teniendo la configuracion necesaria para reservar el uso del harware, que se hacomentado, se compila el programa, dando como resultado un ejecutable que en estecaso se ha venido a llamar “resident sw”.

La ejecucion del programa de prueba serıa la siguiente:

− Se carga el programa en la placa de ejecucion, suponiendo que esta conectadaal puerto /dev/ttyUSB1 y que esta configurada a una velocidad de 115200baudios:

$ grmon-eval -uart /dev/ttyUSB1 -baud 115200

grlib> lo resident_sw

section: .text at 0x40000000, size 80684 bytes

section: .data at 0x40013b30, size 492 bytes

total size: 81176 bytes (93.4 kbit/s)

read 660 symbols

entry point: 0x40000000

grlib> g

resuming at 0x40000000

94


Como se puede ver el programa se pone a ejecutar y queda a la espera derecibir datos

− Se conecta el programa kermit a la lınea serie para observar los datos recibidosen el lado del simulador:

kermit -l /dev/ttyUSB0 -C "set flow-control none",

"set speed 9600","set carrier-watch off","show comm","connect"

− Se envıa un “Hola mundo” desde el computador de simulacion a traves de lalınea serie, que suponemos que esta conectada al puerto /dev/ttyUSB0:

echo "Hola mundo" > /dev/ttyUSB0

− En el lado simulador se vuelven a recibir los datos mandados:

Connecting to /dev/ttyUSB0, speed 9600

----------------------------------------------------

Hola mundo

5.4.3. HIL en Simulink

Todo lo anterior que se ha visto en este capıtulo era la parte de la capa decomunicaciones serie del lado del hardware. En esta seccion se incluye la parte dela capa de comunicaciones serie del lado del simulador, que abarca el estudio de lasbibliotecas a usar y las configuraciones necesarias sobre estas.

Para proveer a los modelos de la capa de comunicaciones serie, se ha de dispo-ner del toolbox correspondiente de Simulink . Este toolbox es Instrument ControlToolbox y estos son los componentes principales que interesan en este caso:

Figura 5.12: Bloque deconfiguracion del puertoserie

Figura 5.13: Bloque deenvıo de datos serie

Figura 5.14: Bloque derecepcion de datos serie

Por lo tanto, entre otros, se tienen bloques funcionales que permiten la con-figuracion del dispositivo y el envıo y recepcion de datos, que es lo que interesaprincipalmente. La configuracion que se realiza sobre el dispositivo es la misma quela que se ha hecho en la parte del hardware a probar, por lo que la configuracionquedarıa de la siguiente manera:

95


Figura 5.15: Configuracion del dispositivo UART en Simulink

Como se puede ver Simulink permite configurar el orden de los bytes a intercam-biar por la lınea serie (campo “Byte Order”), pero en pruebas se ha visto que dehecho aunque se cambie la opcion siempre esta en formato “Little Endian”. Por estemotivo ya que el hardware a probar usa “Big Endian” para el orden de los bytes,en el lado hardware hay que implementar este cambio. Este serıa el procedimiento,que es trivial, que realiza el cambio de orden para el caso del intercambio de datosde tipo double:

1 procedure Invert A Double (Data Input : in Packet;Data Output : out Packet) is

beginData Output(1) := Data Input(8);Data Output(2) := Data Input(7);

6 Data Output(3) := Data Input(6);Data Output(4) := Data Input(5);Data Output(5) := Data Input(4);Data Output(6) := Data Input(3);Data Output(7) := Data Input(2);

11 Data Output(8) := Data Input(1);end Invert A Double ;

Listado 5.4: Procedimiento para modificar el orden de los bytes de los datos quese intercambian.

96


5.4.4. Modificaciones en el modelo ADCS

En esta seccion se incluyen las modificaciones realizadas para preparar el modelopara la tecnica HIL de simulacion. Hay que destacar que se hicieron unas prime-ras modificaciones para hacer que el modelo fuese discreto, ya que se vio que eranecesario para usar esta tecnica. Se discretizo el modelo que preparo el grupo deIDR/UPM, se hicieron pruebas y se vio que los resultados eran aceptables y a partirde ese momento el grupo de IDR/UPM siguio trabajando pero teniendo en cuentaque el modelo ha de ser discreto.

Las modificaciones en el modelo son que se han eliminado los bloques funcionalesque implementan el algoritmo del controlador, ya que este va a ejecutar en la placahardware, se ha modificado el periodo de ejecucion para que tenga una frecuenciade 1 Hz discreta y se han incluido los bloques de comunicacion serie de recepcion,envıo y configuracion.

Por lo que se ha pasado de tener el controlador con el algoritmo, como se puedever en la siguiente figura:

Figura 5.16: Bloques funcionales del subsistema de control del modelo

A tener el controlador con la capa de comunicacion serie a traves del dispositivoUART, como se puede ver en la siguiente figura:

97


Figura 5.17: Bloques funcionales de la capa de comunicacion que reemplazan losoriginales

Con las variables “sent data/data to send” y “received data/data to receive”, secomprobaran los resultados comparandolas. Es decir, se comparan los resultados dela simulacion sin HIL y con HIL para validar la infraestructura.

5.4.5. Infraestructura final

Ya se tiene integrado el codigo del algoritmo del controlador en la tarea Adacorrespondiente a la particion de control y se tiene el modelo modificado para teneranadida la capa de comunicacion serie. En esta seccion se muestran las modifica-ciones necesarias para terminar la estructura de la aplicacion de demostracion, demodo que se pueda ejecutar en un entorno Hardware-in-the-loop.

Por un lado, falta anadir la capa de comunicacion serie en la tarea de la particionde entrada/salida, de una forma parecida a como se introduce en la seccion 5.4.2,y anadir la capa de comunicacion entre particiones, de modo que la particion deentrada/salida sirva de intermediaria entre el simulador y la particion de control.Y por otro lado, falta definir el plan cıclico de la ejecucion de las particiones y lasregiones de memoria en las cuales se cargan.

La comunicacion entre las particiones se realiza a traves de los mecanismos pro-porcionados por XtratuM, en este caso a traves de dos puertos de tipo sampling.Se podrıa haber elegido cualquier tipo de puerto, puesto que la comunicacion entrelas particiones no necesita encolado de mensajes, ya que por construccion en cadaintercambio solo hay maximo un mensaje. Aun ası conceptualmente, es preferible eltipo de puerto sampling ya que se asegura que el controlador siempre va a disponerde la ultima entrada. El soporte para esta comunicacion en Ada se introdujo en laversion 3.3.3 de XtratuM, a traves del paquete XtratuM.Ipc cuya interfaz se puedever en la seccion 3.1.4.

Para poder realizar uso de los puertos de comunicacion entre particiones, al igualque para el uso de los recursos hardware, se tiene que modificar adecuadamente elfichero de configuracion de las particiones. Esto con el objetivo de declarar los puertos

98


que van a ser usados, el tipo de los mismos y la longitud de los mensajes que se vana intercambiar. Por tanto, a continuacion, se muestra la configuracion necesaria enel fichero xml.

Para la particion de control, es necesario indicar que hace uso de dos puertos detipo “sampling”, uno en el que la particion es destino de los mensajes (” io source ”),por el cual recibira las entradas al algoritmo del control de actitud, y otro en el quela particion es origen de los mensajes(”adcs source”), por el cual enviara las salidasde dicho algoritmo. Esto se indica de la siguiente manera:

<PortTable><Port name=”io source” type=”sampling” direction=”destination” /><Port name=”adcs source” type=”sampling” direction=”source” />

</PortTable>

Listado 5.5: Asignacion de los puertos en la particion de control.

Para la particion de entrada/salida, es necesaria la misma configuracion pero conla direccion de los puertos justo al contrario, como se indica en este fragmento decodigo:

1 <PortTable><Port name=”io source” type=”sampling” direction=”source” /><Port name=”adcs source” type=”sampling” direction=”destination” />

</PortTable>

Listado 5.6: Asignacion de los puertos en la particion de entrada/salida.

Ası mismo, estos puertos se han de declarar, indicando el valor de los parametroscorrespondientes, de la siguiente manera:

1 <Channels><SamplingChannel maxMessageLength=”48B”><Source partitionId =”1” portName=”io source”/><Destination partitionId =”0” portName=”io source”/>

</SamplingChannel>6 <SamplingChannel maxMessageLength=”48B”>

<Source partitionId =”0” portName=”adcs source”/><Destination partitionId =”1” portName=”adcs source”/>

</SamplingChannel></Channels>

Listado 5.7: Declaracion de los puertos.

A continuacion, se muestra el codigo de la tarea de la particion de entrada/salida,que incluye las dos capas de comunicacion:

99


task body Io Task is−− Vector de datos a intercambiar con SimulinkVector : Vector Packet;

4 Last : Stream Element Offset;−− Puertos de tipo ‘‘Sampling’’Io PortId : Port;Adcs PortId : Port;−− Valires de retorno

9 Ret : ReadType;RetWrite : RetType;Data : aliased SEArray;RefreshPeriod : Long Long Integer := 0;Flags : aliased Unsigned := 0;

14 −− Tiempo extra para asegurar la inicializaci on del sistemaStart : constant Time := Clock + Offset;

begin−− Se crean los puertosXM create sampling port(io portname,

19 Msg Size,XM SOURCE PORT,RefreshPeriod ,Io PortId );

XM create sampling port(adcs portname,24 Msg Size,

XM DESTINATION PORT,RefreshPeriod ,Adcs PortId );

29 Interrupt . Activate ;Set (Rate => 9600);if ( Io PortId >= 0 or Adcs Portid >= 0) then

delay until Start ;loop

34 −− Se espera recibir el vector de datos del simuladorReceive Vector (Vector, Last );−− Se envıan los entradas del algoritmo a la partici on de controlXM write sampling message(Io PortId, Data, RetWrite);if (RetWrite = XM OK) then

39 −− Se espera por la interrupci on asociada al puertoInterrupt .Wait;XM read sampling message(Adcs PortId, Data, Flags’Access, Ret);−− Se envıan las salidas del algoritmo al simuladorSend Vector (Vector );

44 end if ;

100


end loop;end if ;

end Io Task ;

Listado 5.8: Cuerpo de la tarea de entrada/salida.

El procedimiento “Receive Vector” espera recibir un vector de 3 datos de tipodouble, “Send Vector” intenta enviar un vector con las mismas caracterısticas.

Y este es el codigo de la tarea de la particion de control, que incluye la capas decomunicacion con la particion de entrada/salida:

task body Adcs Task is−− Periodo de 1s

3 Period : constant Time Span := Offset; −− 1sNext : Time := Clock;−− Puertos de tipo ‘‘Sampling’’Io PortId : Port;Adcs PortId : Port;

8 −− Valores de retornoRet : ReadType;RetWrite : RetType;−− Entradas al algoritmo de controlControl U : ExternalInputs control ;

13 pragma Export (C, Control U, ”control U”);−− Salidas del algoritmo de controlControl Y : ExternalOutputs control ;pragma Export (C, Control Y, ”control Y”);−− Tiempo extra para asegurar la inicializaci on del sistema

18 Start : constant Time := Clock + Offset;−− Vector de datos a intercambiar con la partici on de entrada/ salidaVector : Vector Packet;

begin−− Se inicializa el modulo de control

23 Initialize ;Interrupt . Activate ;−− Se crean los puertosXM create sampling port(io portname,

Msg Size,28 XM SOURCE PORT,

RefreshPeriod ,Io PortId );

XM create sampling port(adcs portname,Msg Size,

101


33 XM DESTINATION PORT,RefreshPeriod ,Adcs PortId );

if ( Io PortId >= 0 or Adcs Portid >= 0) thendelay until Start ;

38 loopNext := Next + Period;delay until Next;−− Se espera por la interrupci on asociada al puertoInterrupt .Wait;

43 −− Se reciben las entradas al algoritmo de la partici on de E/Sxm read sampling message(Io Portid , Data, Flags ’Access, Ret);−− Se desempaquetan los datos recibidos en las variables−− correspondientes a las entradas del algoritmo−− en formato BigEndian

48 UnPack (Vector, Control U.B Dot1, Control U.B b T);−− Se ejecuta el algoritmoControl Wrapper;−− Se empaquetan las salidas del algoritmo en formato LittleEndianPack (Control Y.I A, Control Y.T Nm, Vector);

53 −− Se reciben las salidas al algoritmo a la partici on de E/SXM write sampling message(Adcs Portid, Data, RetWrite);

end loop;end if ;

end Adcs Task;

Listado 5.9: Cuerpo de la tarea de control.

El procedimiento “Control Wrapper” se tiene como envoltorio del algoritmo decontrol para facilitar su medida de tiempo. El codigo del procedimiento “Con-trol Wrapper” es el siguiente:

procedure Control Wrapper isbegin

3 Control ;end Control Wrapper;

El plan cıclico de la tarea se ha obtenido ajustando al maximo el tiempo dela particion de control. Esto es ası porque, en la version en la que se ha desarro-llado el demostrador, XtratuM sigue enmascarando las interrupciones despues demanejarlas, con lo que en el intervalo entre que XtratuM enmascara la interrupcioncorrespondiente al dispositivo UART y que la particion de entrada/salida lo desen-mascara de nuevo, es posible que se pierdan algunos datos si se llena el buffer derecepcion. Por lo que se ha calculado el tiempo que tarda en llenarse el buffer, asig-nando este tiempo a la particion de control con un margen apropiado para asegurar

102


que no se llegue a llenar nunca. Ademas se ha comprobado que este tiempo es sufi-ciente para la ejecucion del algoritmo del control de actitud y los tiempos derivadosde los cambios de contexto correspondientes.

Puesto que se ha escogido una velocidad de transmision de 9600 Baudios/s, cadaBaudio es un bit, por cada byte de informacion se incluyen un bit de start y otro bitde stop y el buffer de recepcion del dispositivo es de un tamano de 32 bytes, el tiempo

hasta que se llena este buffer es de32Byte∗10Baudio

Byte

9600Baudios

= 0, 033s. Por lo que, se tiene un

tiempo maximo para la particion de control de 33 ms. Se han estudiado tanto elpeor tiempo de computo del algoritmo de control como la sobrecarga del cambiode contexto que son despreciables, del orden de microsegundos. Por todo esto se hadecidido dar un tiempo a esta particion, con una margen para posibles sobrecargasque pudieran suceder, de 25 ms. El hiperperiodo del plan se ha decidido que sea de1s, por lo que el resto del tiempo, 975 ms, ejecuta la particion de entrada/salida.

Este plan se especifica en el fichero xml de configuracion de la siguiente manera,donde la particion con el id 1 es la particion de entrada/salida y la otra, la particionde control:

1 <Plan id=”0” majorFrame=”1s”><Slot id=”0” start=”0ms” duration=”975ms” partitionId=”1”/><Slot id=”1” start=”975ms” duration= ”25ms” partitionId=”0”/>

</Plan>

Listado 5.10: Declaracion del plan cıclico de la aplicacion de demostracion.

En cuanto al mapa de memoria, se muestra en la figura 5.18 donde XtratuMtiene un tamano de 512 KB, que es lo que se recomienda, y las particiones cada unaun tamano de 1,5 MB. Igualmente este mapa de memoria se especifica en el ficheroxml de configuracion de la siguiente manera:

1 <Partition id=”0” name=”adcs” flags=””><PhysicalMemoryAreas>

<Area name=”B1” start=”0x40080000” size=”1536KB” /></PhysicalMemoryAreas>...

6 </Partition>

Listado 5.11: Declaracion del mapa de memoria de la particion de control en elfichero de configuracion.

<Partition id=”1” name=”io” flags=”system”><PhysicalMemoryAreas>

<Area name=”B2” start=”0x40200000” size=”1536KB” />4 </PhysicalMemoryAreas>

103


...</Partition>

Listado 5.12: Declaracion del mapa de memoria de la particion de entrada/salidaen el fichero de configuracion.

Aunque introduzca redundancia tambien es necesario establecer estos valores enel fichero de montaje (que por convencion se ha venido a llamar de manera generalxmsparcleon.x) de cada una de las particiones. Esto es para indicar el mapa dememoria correspondiente al enlazador (en futuras versiones se pretende reducir estecomportamiento redundante). Por lo que el contenido de los ficheros de montajepara cada una de las particiones ha de tener el siguiente aspecto:

ENTRY(start)

RAM SIZE = 1536K ;

RAM START = 0x40080000 ;4 RAM END = RAM START + RAM SIZE;

stack = RAM END;stack start = stack − STACK SIZE;

STACK SIZE = (100 * 1024) ;

MEMORY9 {

rom : ORIGIN = 0x00000000, LENGTH = 128K

ram : ORIGIN = 0x40080000 , LENGTH = 1536K}Listado 5.13: Declaracion del mapa de memoria de la particion de control en elfichero de montaje.

ENTRY(start)

RAM SIZE = 1536K ;

3 RAM START = 0x40200000 ;RAM END = RAM START + RAM SIZE;

stack = RAM END;stack start = stack − STACK SIZE;

STACK SIZE = (100 * 1024) ;

8 MEMORY{

rom : ORIGIN = 0x00000000, LENGTH = 128K

ram : ORIGIN = 0x40200000 , LENGTH = 1536K}Listado 5.14: Declaracion del mapa de memoria de la particion de entrada/salida enel fichero de montaje.

104


···

···

XtratuM512 KB

Partición ADCS1,5MB

Partición E/S1,5 MB

Read-only 256 KB

Read-write 256 KB

0x40000000

0x40080000

0x40200000

0x40380000

0x403C0000

Figura 5.18: Mapa de memoria de la aplicacion de demostracion

5.5. Guıa de uso

En esta seccion se muestra la guıa de uso de la infraestructura de desarrollo deaplicaciones para sistemas IMA, usando como ejemplo la aplicacion de demostracionconstruida.

Hasta este punto se ha descrito la construccion de una aplicacion que sirva co-mo demostracion del trabajo realizado. A continuacion se describe la configuracionnecesaria, el proceso de compilacion y los pasos para la ejecucion de la aplicacion.

5.5.1. Configuracion y construccion de XtratuM

Para la correcta ejecucion de las aplicaciones, XtratuM [14] ha de ser configuradoapropiadamente para ajustar la memoria de las particiones, entre otros aspectos. Laconfiguracion, obviamente, varıa dependiendo de los usos de la plataforma que hagala aplicacion.

La configuracion presentada en esta seccion es solo un ejemplo de la configura-cion necesaria del hipervisor para que la aplicacion de demostracion pueda ejecutarcorrectamente. Se parte de la configuracion por defecto sobre la que se realizan lasmodificaciones necesarias.

Para acceder a la configuracion se debe establecer un fichero de caracterısticaspor defecto y a continuacion se puede lanzar su ejecucion:

$ cp xmconfig.sparc xmconfig

105

5.5. GUIA DE USO

$ make menuconfig

La configuracion consta de los siguientes tres pasos:

1. Configuracion correspondiente a XtratuM

2. Configuracion correspondiente al software residente

3. Configuracion correspondiente a la capa de abstraccion de XtratuM (XtratuMAbstraction Layer (XAL))

La plataforma hardware o de simulacion sobre la que se quiere ejecutar la infra-estructura es uno de los aspectos que han de ser indicados en la configuracion paraque XtratuM se ajuste a su arquitectura. En este caso la plataforma es el modelode ingenierıa del computador de a bordo del microsatelite UPMSat-2 GR-XC3S1500Spartan3 (figura 2.18). Para realizar la configuracion en el primer paso de la con-figuracion, acceder a la seccion “Processor”, a continuacion a la seccion “Board” yseleccionar “GR-XC3S-1500” como se muestra en la siguiente imagen:

Figura 5.19: Configuracion de la plataforma de ejecucion

Para el caso concreto de la aplicacion de demostracion, se ha de deshabilitar elmanejo de la lınea serie por parte de XtratuM. Esto es ası, puesto que es la particionde E/S la que se ha de encargar de este manejo mediante el uso del manejador quese provee. Para realizar este cambio en el primer paso de la configuracion, accedera la seccion “Drivers” y deshabilitar la opcion “Enable UART driver” como semuestra a continuacion:

Figura 5.20: Configuracion del dispositivo UART

Y por ultimo, la distribucion del espacio de memoria es otro de los aspectos quehan de ser indicados en la configuracion. La aplicacion consta de dos particiones a

106


las cuales, como se ha indicado en la seccion 5.4.5, se les asigna a cada una 1,5 MBde espacio en memoria. La distribucion de memoria del ejemplo se muestra en lafigura 5.18. Para indicar este comportamiento en el segundo paso de la configuracion,acceder a la seccion “RSW memory layout” y establecer los valores de direccioncomo se muestra a continuacion:

Figura 5.21: Configuracion del mapa de memoria

Una vez se tiene configurado XtratuM ya se pueden compilar las fuentes deXtratuM:

$ make

Cuando XtratuM se ha compilado, los ficheros necesarios para la construccionde sistemas basados en XtratuM quedan esparcidos en el arbol de directorios de sucodigo fuente. Para poder compartir con los distintos desarrolladores de las particio-nes 1 la misma configuracion de XtratuM, se debe generar generar una distribucioncon la especificacion determinada. Esto se puede hacer de dos formas:

1. De manera que se genere un fichero comprimido con un fichero de instalacion

$ make distro-tar

2. De manera que se genere un unico fichero ejecutable que contiene la distribu-cion y el fichero de instalacion

$ make distro-run

En cualquier caso despues de generar la distribucion e instalarla ya estara dispo-nible todo lo necesario para hacer uso de los componentes de desarrollo de XtratuM.

5.5.2. Compilacion de la aplicacion

Para la compilacion de la aplicacion se han de especificar la ruta a la distribucionde XtratuM, la ruta a las herramientas de compilacion cruzada de ORK+, la rutaal manejador de la UART, la ruta al paquete de comunicacion entre particiones yla ruta al codigo generado por Simulink. Por lo que, en el fichero Makefile se han

1En este caso hay un unico desarrollador para todas las particiones, pero esto no tiene que serası. De hecho es una de las virtudes de la infraestructura que se aporta, poder trabajar de maneramodular de manera que se construya cada pieza por separado y se pueda integrar todo o por partessegun se vayan completando los componentes.

107

5.5. GUIA DE USO

de establecer las variables XTRATUM_PATH, GNATFORLEON_PATH, UART_DRIVER_PATH,IPC_PATH y MODULES_FOLDER, respectivamente.

A continuacion, ya es posible ejecutar la utilidad make para lanzar el proceso decompilacion del sistema.

Este proceso abarca los pasos de construccion del binario de cada particion ydel binario obtenido del fichero de configuracion xml y de empaquetar cada uno deestos binarios para generar el ejecutable final. De manera manual el proceso es elsiguiente:

1. Compilacion del fichero de arranque:

sparc-linux-gcc -Wall -O2 -D__ASSEMBLY__ -fno-builtin -Dsparcv8

-D"__XM_INCFLD(_fld)=<xm_inc/_fld>" -I$(XTRATUM_PATH)/include

-nostdlib -nostdinc --include xm_inc/config.h -o boot.o -c boot.S

2. Compilacion del codigo generado por Simulink:

sparc-elf-gcc -c -g -msoft-float $(MODULES_FOLDER)control.c

sparc-elf-gcc -c -g -msoft-float $(MODULES_FOLDER)control_data.c

Nota: la opcion msoft-float se incluye puesto que en la placa no hay unidadde coma flotante por lo tanto las operaciones relativas se realizan por software.

3. Compilacion de la particion de control (adcs):

sparc-elf-gnatmake -g -f adcs -I$(IPC_PATH) -o adcs -largs boot.o

control.o control_data.o -nostartfiles -T xmsparcleon1.x

-L$(XALLIB) -lxal -L$(XMLIB) -lxm -u xmImageHdr

Nota: la opcion -u fuerza al compilador a incluir en el ejecutable el sımboloespecificado en el proceso de enlace

4. Conversion del ejecutable de la particion de control, en formato Executableand Linkable Format (ELF), al ejecutable en formato XtratuM ExecutableFormat (XEF):

xmeformat build -c adcs -o adcs.xef

5. Compilacion de la particion de E/S (io):

sparc-elf-gnatmake -g -f io -I$(UART_DRIVER_PATH) -I$(IPC_PATH)

-o io -largs boot.o control.o control_data.o -nostartfiles

-T xmsparcleon2.x -L$(XALLIB) -lxal -L$(XMLIB) -lxm -u xmImageHdr

108


6. Conversion del ejecutable de la particion de E/S, en formato ELF, al ejecutableen formato XEF:

xmeformat build -c io -o io.xef

7. Comprobacion de las caracterısticas especificadas en el fichero de configuracionxml. Ademas se traduce a un formato binario intermedio:

xmcparser -o xm_cf.bin.xmc xm_cf.sparcv8.xml

8. Conversion del fichero de configuracion xml en el formato binario intermedioal formato XEF:

xmeformat build -c -m xm_cf.bin.xmc -o xm_cf.xef.xmc

9. Comprobacion del empaquetado de todos los binarios en formato XEF gene-rados:

xmpack check xm_cf.xef.xmc -h

$(XTRATUM_PATH)/lib/xm_core.xef:xm_cf.xef.xmc

-p 0:adcs.xef -p 1:io.xef

10. Empaquetado de todos los binarios:

xmpack build -h $(XTRATUM_PATH)/lib/xm_core.xef:xm_cf.xef.xmc

-p 0:adcs.xef -p 1:io.xef container.bin

11. Creacion de la imagen para la plataforma de ejecucion:

rswbuild container.bin resident_sw

5.5.3. Ejecucion de la aplicacion

Una vez se dispone del ejecutable, que en este caso por convencion se ha venidoa llamar “resident_sw”, ya se puede proceder a la ejecucion de la aplicacion. Comoya se ha explicado, la aplicacion implementa el control de actitud del microsateliteUPMSat-2 y, puesto que no es posible su ejecucion en el entorno real desde tierra,se simula en Simulink con el que la aplicacion interactua por la lınea serie. Todo elproceso de construccion de esta infraestructura se ha explicado en la seccion 5.

En primer lugar es necesario cargar el ejecutable en la plataforma hardwaredestino:

109

5.5. GUIA DE USO

$ grmon -uart /dev/ttyUSB1

grlib> lo resident_sw

section: .text at 0x40380000, size 17876 bytes

section: .rodata at 0x403845d8, size 579 bytes

section: .container at 0x40500000, size 202680 bytes

section: .data at 0x405317b8, size 4 bytes

section: .got at 0x405317bc, size 8 bytes

section: .eh_frame at 0x405317c4, size 64 bytes

total size: 221211 bytes (89.9 kbit/s)

read 30 symbols

entry point: 0x40381300

A continuacion, se puede poner a ejecutar el sistema. Las particiones quedaranbloqueadas. En el caso de la particion de control quedara bloqueada en espera derecibir datos por el puerto sampling asociado y en el caso de la particion de E/Squedara bloqueada en espera de recibir datos por el puerto serie:

grlib> g

resuming at 0x40381300

Por otro lado, se ha de ejecutar el modelo del entorno del satelite. El tiempo desimulacion se puede establecer en el menu de configuracion. Para esto seleccionar lapestana “Simulacion”, despues seleccionar la opcion “Configuration Parameters”y establecer en el cuadro “Simulation time”(figura 5.22) de la seccion “Solver”el valor para el campo “Stop time”.

Figura 5.22: Configuracion de la duracion de la simulacion, establecida en 10 pasosya que el tiempo de muestreo es de 0.1

Establecido este tiempo, se asegura el numero de pasos de la simulacion.Para ejecutar el modelo, simplemente, seleccionar la opcion “Start” en el menu

“Simulation”.

5.5.4. Depuracion de la aplicacion

Por construccion y requisitos de la plataforma no se dispone de mecanismos parapoder imprimir mensajes por consola. Por lo que para la correccion de errores nose puede monitorizar su comportamiento mediante una traza de mensajes, siendonecesaria una herramienta de depuracion. En las herramientas del entorno de desa-rrollo cruzado que se incluyen en GNATforLEON se incluye esta herramienta, quees GDB. En esta seccion no se pretende mostrar el uso de esta herramienta que se

110


encuentra en su manual2, sino que se incluyen algunas consideraciones a tener encuenta y detalles para su correcto funcionamiento.

En primer lugar, como se ha comentado es una herramienta del conjunto delsistema de desarrollo cruzado. Con esto, se ha de entender que la herramienta GDB,que se ejecuta en el computador de desarrollo, ha de acceder de manera remota a laejecucion del sistema en la plataforma hardware.

Para esto, por un lado, en la conexion con la placa a traves de la herramien-ta grmon, en vez de cargar el ejecutable ha de establecerse la conexion en mododepuracion:

$ grmon -uart /dev/ttyUSB1

grlib> gdb

gdb interface: using port 2222

connected to port 2222

Se establece la depuracion, por el puerto 2222, en el lado de la plataforma hard-ware.

A continuacion, se ejecuta la herramienta GDB y se conecta con la plataformade manera remota por el puerto 2222:

$ sparc-elf-gdb

(gdb) target extended-remote:2222

Remote debugging using :2222

0x00000000 in ?? ()

En segundo lugar, hay que tener en cuenta que no es posible poner puntos deruptura tradicionales, es decir, haciendo uso de la opcion break, puesto que estosconsisten en reemplazar la instruccion a ejecutar por una instruccion que cause unaexcepcion, pero XtratuM para cargarse en memoria realiza una serie de memcopycon lo que se eliminan estas instrucciones reemplazadas. Para poder poner puntosde ruptura es necesario asistirlos por hardware, haciendo uso de la opcion hbreak.

Y por ultimo, para que el depurador disponga de acceso a la tabla de sımbolos decada una de las particiones, es necesario hacer uso de la opcion add-symbol-file,indicando el fichero en formato ELF de la correspondiente particion y la direccionbase en memoria asignada. Por ejemplo, para anadir la tabla de sımbolos de laparticion de control, la sentencia serıa la siguiente:add-symbol-file adcs 0x40080000.

5.6. Resultados

En esta seccion se presentan los resultados de la ejecucion de la aplicacion dedemostracion construida para el algoritmo de control del microsatelite UPMSat-2.

2http://gcc.gnu.org/onlinedocs/gcc-4.1.2/gnat ugn unw.pdf

111

http://gcc.gnu.org/onlinedocs/gcc-4.1.2/gnat_ugn_unw.pdf

5.6. RESULTADOS

Estos resultados como se esperaba son exactamente iguales que los que genera laejecucion de la simulacion sin Hardware-in-the-loop. Por lo que la aplicacion, comoera de esperar, funciona correctamente.

Estos son los resultados graficos de la simulacion de una orbita del control deactitud del satelite:

Figura 5.23: Cuaterniones que repre-sentan la actitud del satelite con res-pecto a un marco de referencia vertical

Figura 5.24: Transformacion de los cua-terniones a los angulos de Euler

Figura 5.25: Velocidad angular delsatelite con respecto a un marco de re-ferencia vertical

Figura 5.26: Errores de estimacion cal-culados a partir de los cuaterniones conrespecto a un valor de referencia

Estos resultados se han validado comparando las entradas y salidas del algoritmode control que se producen en la simulacion, con HIL y sin este, verificando que seaniguales. Este es el resultado para ambos entornos, en una simulacion de 5 segundos:

112


B dot0 0.0002191411669 2.117582368·10−21

0.0000001095705763 -2.739264406·10−11 5.805445947·10−12

0.0000001095705453 -8.217792183·10−11 5.805445572·10−12

0.000000109570487 -0.0000000001369631736 5.805445208·10−12

0.0000001095704012 -0.0000000001917483858 5.805444815·10−12

Cuadro 5.1: Variacion de los componentes del campo magnetico con respecto a losejes del satelite

B b t0 0.00002191411669 2.117582368·10−22

0.00000001095705763 0.00002191411395 5.805445949·10−13

0.00000002191411216 0.00002191410573 1.161089152·10−12

0.00000003287116086 0.00002191409204 1.741633673·10−12

0.00000004382820098 0.00002191407286 2.322178154·10−12

Cuadro 5.2: Variacion de los componentes del campo magnetico con respecto almarco de referencia del satelite, medida en Teslas

I A0 -5.0 00 0.000005478528812 00 0.00001643558437 00 0.00002739263472 00 0.00003834967716 0

Cuadro 5.3: La corriente requerida en los magnetopares, medida en Amperios

T Nm-2.64697796·10−20 0 07.951325725·10−17 0 -1.500713898·10−12

4.770794679·10−16 0 -9.004280982·10−12

1.192698375·10−15 0 -2.251069256·10−11

2.226369563·10−15 0 -4.201993395·10−11

Cuadro 5.4: Momento de fuerza medido en Newton-metros

113

5.6. RESULTADOS

114

Capıtulo 6

Conclusiones, trabajo futuro yagradecimientos

El presente trabajo fin de carrera constituye un adelanto en el desarrollo deaplicaciones de tiempo real crıticas. En este se aporta la adaptacion del kernelORK+ a la ultima version del hipervisor XtratuM, ademas de mejoras en su fun-cionamiento (el cambio de contexto de los registros de coma flotante, entre otras)y de incluir nuevos paquetes (la comunicacion entre particiones, la gestion de lasmismas, el driver de la UART, ...), retomando el trabajo de adaptacion anterior.Con esto se consigue posicionar a ORK+, desarrollado en el grupo de investigacionSTRAST del que formo parte, entre los componentes a valorar para el desarrollo deeste tipo de aplicaciones y ser un referente en cuanto a los sistemas de tiempo realcrıticos actuales. Como se ha apuntado los sistemas de tipo IMA se estan usandocon profusion en la industria avionica, por las ventajas ya comentadas como la mo-dularidad en el desarrollo. Esto es otro aspecto por el cual este trabajo fin de carreraes un aporte a este sector, con soluciones y mejoras en ORK+ para XtratuM, paracubrir las necesidades que se plantean en el desarrollo de este tipo de sistemas.

Como demostracion del funcionamiento de la infraestructura se aporta una apli-cacion real, ya que implementa el control de actitud del microsatelite UPMSat-2,orientada a funcionar en vuelo. Con esta aplicacion ademas se muestra una manerade validar el software de la aplicacion mediante su interaccion con la simulacion delentorno real del sistema en Simulink.

Durante el trabajo se han realizado labores de mantenimiento para los desarrolla-dores de los distintos proyectos en los que esta enmarcado. Ademas se ha ayudado aresolver errores importantes en los componentes de la infraestructura ofrecida. Estoha servido tambien para la depuracion del sistema recibiendo sugerencias y reportesde errores en el funcionamiento de ORK+/XtratuM.

El sistema obtenido ofrece un comportamiento temporal analizable mediantemetodos de analisis del tiempo de respuesta, que es un requisito fundamental en lossistemas de tiempo real crıtico. Este se puede encontrar a traves de la pagina princi-pal del grupo de investigacion STRAST: http://web.dit.upm.es/ str/ork/index.html.

115

http://web.dit.upm.es/~str/ork/index.html

Despues del trabajo realizado, se pretende finalizar la construccion de herramien-tas de generacion automatica de un entorno de compilacion de particiones.Y posteriormente, incluso el desarrollo de herramientas de generacion automaticade codigo desde metamodelos.

Tambien se pretende seguir trabajando en la integracion del los fuentes delcompilador de ORK+ para XtratuM con los fuentes de ORK+ para maquina des-nuda, de modo que este todo en un mismo arbol de directorios y solo sea necesarioindicar para que plataforma se ha de generar el compilador.

Todo este trabajo ha sido posible por varios factores. Por la oportunidad ofrecidapor el grupo de investigacion STRAST, en el que estoy actualmente trabajando. Porsu dedicacion con mi aprendizaje de todo lo que me han podido ensenar y su ayuda entodo lo que me han podido ayudar. Por el interes que han tenido en nuestro grupo losdiferentes coordinadores de los proyectos: UPMSat-2, MultiPARTES y el proyectoEagleEye; para los cuales, entre otros desarrollos, se ha trabajado para alcanzarlos resultados expuestos en este documento. Por la ayuda ofrecida por parte de losdiferentes colaboradores, en concreto por parte de Assal Farrahi y Javier Cubas delinstituto “Ignacio Da Riva” (IDR/UPM), y Miguel Masmano y Javier Coronel dela empresa colaboradora Fent Innovative Software Solutions (FentISS). Por el apoyoque me ha dado mi familia.

116

Glosario

LEON2 Es un core de microprocesador de 32-bits basado en la arquitectura RISCy en el conjunto de instrucciones SPARC V8. Originalmente disenada por laESA, y posteriormente por Gaisler Research.. 4, 41

LEON3 Es un procesador de 32-bits sintetizable con VHDL basado en la arqui-tectura RISC y en el conjunto de instrucciones SPARC V8. El modelo tienebastantes diferencias con su predecesor, el procesador LEON2, entre otras in-cluye soporte SMP y un pipeline de siete etapas.. 29, 32, 43

117

Glosario

118

Bibliografıa

[1] Adaptacion del sistema de tiempo real ORK+ al hipervisor XtratuM. 2012.

[2] ARINC. Avionics Application Software Standard Interface — ARINC Specifi-cation 653-1, October 2003.

[3] N. C. Audsley, A. Burns, M. Richardson, K. Tindell, and A. Wellings. Applyingnew scheduling theory to static priority preemptive scheduling. Software Engi-neering Journal, 8(5):284–292, September 1993.

[4] Neil Audsley, Alan Burns, Rob Davis, Ken Tindell, and Andy J. Wellings. Fixedpriority preemptive scheduling: An historical perspective. Real-Time Systems,8(3):173–198, 1995.

[5] Matteo Bordin and Tullio Vardanega. Automated model-based generation ofRavenscar-compliant source code. In Proc. 17th Euromicro Conference on Real-Time System, ECRTS ’05, pages 59–67, Washington, DC, USA, 2005. IEEEComputer Society.

[6] Alan Burns. The Ravenscar profile. Technical report, University of York, 2000.Available at www.cs.york.ac.uk/~burns/ravenscar.ps.

[7] Alan Burns and Andy Wellings. Real-Time Systems and Programming Langua-ges. Addison-Wesley, 4th edition, 2009.

[8] Juan A. de la Puente, Jose F. Ruiz, and Juan Zamorano. An open Ravenscarreal-time kernel for GNAT. In Hubert B. Keller and Erhard Plodereder, editors,Reliable Software Technologies — Ada-Europe 2000, number 1845 in LNCS,pages 5–15. Springer-Verlag, 2000.

[9] Jiri Gaisler, Edvin Catovic, Marko Isom ki, Kritoffer Glembo, and Sandi Ha-binc. Grlib ip core user’s manual. Gaisler Research, 2007.

[10] Gaisler Research. LEON2 Processor User’s Manual, 2005.

[11] J. B. Goodenough and L. Sha. The priority ceiling protocol: a method forminimizing the blocking of high priority Ada tasks. In Second InternationalWorkshop on Real-Time Ada Issues. ACM SIGAda, 1988. Ada Letters, 8(7).

119

www.cs.york.ac.uk/~burns/ravenscar.ps

BIBLIOGRAFIA

[12] C. L. Liu and J. W. Layland. Scheduling algorithms for multiprogramming ina hard-real-time environment. Journal of the ACM, 20(1), 1973.

[13] C. D. Locke, Lui Sha, Ragunathan Rajkumar, John Lehoczky, and Greg Burns.Priority inversion and its control: An experimental investigation. In SecondInternational Workshop on Real-Time Ada Issues. ACM SIGAda, 1988. AdaLetters, (8)7.

[14] Miguel Masmano, Ismael Ripoll, Alfons Crespo, and Vicent Brocal. XtratuMHypervisor for LEON2, Volume 2: User Manual, 2009.

[15] Enrico Mezzetti, Marco M.Panunzio, and TullioVardanega. Preservation of ti-ming properties with the Ada Ravenscar profile. In Jorge Real and Tullio Var-danega, editors, Reliable Software Technologies — Ada-Europe 2010, number6106 in LNCS, pages 153–166. Springer-Verlag, 2010.

[16] Jose Pulido, Juan A. de la Puente, Matteo Bordin, Tullio Vardanega, andJerome Hugues. Ada 2005 code patterns for metamodel-based code genera-tion. Ada Letters, XXVII(2):53–58, August 2007. Proceedings of the 13thInternational Ada Real-Time Workshop (IRTAW13).

[17] Jose A. Pulido, Santiago Uruena, Juan Zamorano, Tullio Vardanega, andJuan A. de la Puente. Hierarchical scheduling with Ada 2005. In Luıs MiguelPinho and Michael Gonzalez-Harbour, editors, Reliable Software Technologies— Ada-Europe 2006, volume 4006 of LNCS. Springer Berlin/Heidelberg, 2006.

[18] SPARC International, Upper Saddle River, NJ, USA. The SPARC architecturemanual: Version 8, 1992.

[19] Santiago Uruena, Jose Antonio Pulido, Jorge Lopez, Juan Zamorano, andJuan Antonio de la Puente. A new approach to memory partitioning in on-board spacecraft software. In Fabrice Kordon and Tullio Vardanega, editors,Reliable Software Technologies — Ada-Europe 2008, volume 5026 of LNCS, pa-ges 1–14. Springer Berlin / Heidelberg, 2008. Best paper award.

120

UNIVERSIDAD POLITECNICA DE MADRIDstr/proyectos/upmsat2/doc/PFC_dbrosnan.pdf · STRAST Sistemas de...

Documents

Transcript of UNIVERSIDAD POLITECNICA DE MADRIDstr/proyectos/upmsat2/doc/PFC_dbrosnan.pdf · STRAST Sistemas de...