UNIVERSIDAD POLITÉCNICA DE MADRIDESCUELA TÉCNICA SUPERIOR DE INGENIEROS

DE TELECOMUNICACIÓN

TRABAJO DE FIN DE GRADO

Integración del software de lossubsistemas Manager, Plataforma yDeterminación y Control de Actitud

para el satélite UPMSat-2

VERÓNICA GÓMEZ MUÑOZ

Madrid, 2015

TRABAJO DE FIN DE GRADO

Título:Integración del software de los subsistemasManager, Plataforma y Determinación y Control deActitud para el satélite UPMSat-2

Autor:Verónica Gómez Muñoz

Tutor:Alejandro Antonio Alonso Muñoz

Tribunal:Presidente: D. Juan Antonio de la Puente AlfaroVocal: D. José María del Álamo RamiroSecretario: D. Alejandro Antonio Alonso MuñozSuplente: D. Miguel Ángel de Miguel Cabello

Fecha:

Calificación:

Copyright c© Verónica Gómez Muñoz y Alejandro Antonio Alonso Muñoz 2015

Este trabajo está bajo una licencia Creative Commons Reconocimiento-NoComercial-SinObraDerivada 3.0Unported. Ver http://creativecommons.org/licenses/by-nc-nd/3.0/.

This work is licensed under a Creative Commons Attribution-NonCommercial-NoDerivs 3.0 Unported li-cense. See http://creativecommons.org/licenses/by-nc-nd/3.0/.

Summary

The UPMSat-2 project aims at building a micro-satellite that can be used as an in-orbittechnology demonstration platform. The main part of the project is being carried out atthe "Ignacio da Riva" (IDR) Institute which is part of UPM, with the collaboration ofsome other University gropus and Spanish space companies. The role of the STRASTgroup is focused on developing software for the flight and ground segments.

The work reported in this document deals with the development of some componentsof the on-board satellite software. The developed subsystems are: Manager, Platformand ADCS. The Manager is in charge of driving satellite operation, and, in particular, theoperation mode. The main job of the Platform is satellite housekeeping, i.e. monitoringits state, in order to ensure that its hardware components are working properly. Finallythe ADCS (Attitude Determination and Control System) has to actuate for ensuring that aproper position of the satellite with respect to earth.

The development in this project started with an existing design of these components,performed by previous students. The work accomplished has been to improve them withadditional functionality and to integrate them. The result of this work is an operativeversion of these subsystems, including a preliminary testing. Future work will includethe definition of a complete set of tests, for validating the behaviour of the developedsubsystems.

Software development have relied on a set of technologies that are common for em-bedded high integrity systems. The design has been performed using the TASTE tool,which supports AADL. The Ada language has been used for source code development. Itis suitable for this type of systems. In particular, a safe subset of the language has beenused. for being able to perform static analysis and for improving system predictability.Tasking relies on the Ravenscar model, which is compliant with response time analysismethods.

Keywords: Real-time systems, embedded systems, on-board software.

i

Resumen

El proyecto UPMSat2 aborda el desarrollo de un micro-satélite que se usará como unaplataforma de demostración tecnológica. La mayor parte del proyecto se desarrolla en elInstituto Ignacio de la Riva de la Universidad Politécnica de Madrid, con la colaboraciónde empresas del sector del espacio. La labor del grupo STRAST se centra en el desarrollodel software de vuelo y del sector de tierra del satélite.

Este Trabajo Fin de Grado trata del desarrollo de algunos componentes del softwa-re embarcado en el satélite. Los componentes desarrollados son: Manager, Platform yADCS. El Manager está encargado de dirigir el funcionamiento del satélite y, en concre-to, de su modo de operación. El Platform se encarga de monitorizar el estado del satélite,para comprobar que el funcionamento de los componentes de hardware es el adecuado.Finalmente, el ADCS (Attitude Determination and Control System) trata de asegurar quela posición del satélite, respecto a la tierra, es la adecuada.

El desarrollo de este trabajo parte de un diseño existente, creado por alumnos pre-viamente. El trabajo realizado ha consistido en mejorarlos con funcionalidad adicional yrealizar una integración de estos subsistemas. El resultado es un sistema operativo, queincluye unas pruebas preliminares. Un trabajo futuro será la realización de pruebas ex-haustivas, para validar el funcionamiento de los subsistemas desarrollados.

El desarrollo de software se ha basado en un conjunto de tecnologías habituales enlos sistemas empotrados de alta integridad. El diseño se ha realizado con la herramientaTASTE, que permite el uso de AADL. El lenguaje Ada se ha utilizado para la implemen-tación, ya que es adecuado para este tipo de sistemas. En concreto, se ha empleado unsubconjunto seguro del lenguaje para poder realizar análisis estático y para incrementar lapredecibilidad de su comportamiento. La concurrencia se basa en el modelo de Ravenscar,que es conforme con los métodos de análisis de respuesta.

Palabras clave: Sistemas de tiempo real, sistemas empotrados, software embarcado.

ii

Índice general

Summary i

Resumen ii

1 Introducción 11.1 Antecedentes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.2 Motivación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.3 Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.4 Estructura del documento . . . . . . . . . . . . . . . . . . . . . . . . . . 2

2 Satélite universitario UPMSat-2 32.1 Descripción del UPMSat-2 . . . . . . . . . . . . . . . . . . . . . . . . . 32.2 Plataforma de ejecución . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2.2.1 Computador embarcado . . . . . . . . . . . . . . . . . . . . . . 52.2.2 Open Ravenscar Kernel (ORK +) . . . . . . . . . . . . . . . . . 5

2.3 Arquitectura software . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62.4 Modos de funcionamiento . . . . . . . . . . . . . . . . . . . . . . . . . 72.5 Diseño . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

3 Marco de desarrollo 113.1 Lenguaje de programación Ada . . . . . . . . . . . . . . . . . . . . . . . 113.2 Perfil de Ravenscar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123.3 Herramientas de desarrollo GNAT . . . . . . . . . . . . . . . . . . . . . 123.4 Subversion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123.5 Modelo de Ciclo de vida . . . . . . . . . . . . . . . . . . . . . . . . . . 13

4 Desarrollo del Manager 154.1 Diseño . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154.2 Implementación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

5 Desarrollo de la Plataforma 225.1 Diseño . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225.2 Implementación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 285.3 Validación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

iii

6 Desarrollo del ADCS 326.1 Diseño . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 326.2 Implementación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

7 Resultados y Conclusiones 35

iv

Índice de figuras

2.1 UPMSat-2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32.2 Órbita heliosíncrona . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42.3 Plataforma de ejecución . . . . . . . . . . . . . . . . . . . . . . . . . . . 42.4 Arquitectura software . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62.5 Modos del UPMSat-2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82.6 Diagrama de los subsistemas e interfaces . . . . . . . . . . . . . . . . . . 10

3.1 Ciclo de Vida en V . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

4.1 Diagrama del subsistema Manager . . . . . . . . . . . . . . . . . . . . . 164.2 Diagrama de la transición de estados para el caso de Inicialización . . . . 21

5.1 Diagrama del subsistema Plataforma . . . . . . . . . . . . . . . . . . . . 235.2 Diagrama de drivers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

6.1 Actitud del satélite . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 326.2 Diagrama del subsistema ADCS . . . . . . . . . . . . . . . . . . . . . . 33

v

Índice de tablas

4.1 Parámetros de eventos y errores . . . . . . . . . . . . . . . . . . . . . . 18

5.1 Periodos de muestreo de los sensores . . . . . . . . . . . . . . . . . . . . 235.2 Factor de ADC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 265.3 Calculos de rangos de validez de las diferentes magnitudes . . . . . . . . 265.4 Lista Señales y Rangos de Configuración . . . . . . . . . . . . . . . . . 27

vi

Capítulo 1

Introducción

El presente documento es la memoria final del Trabajo Fin de Grado de la alumna yen ella se recogen todas las tareas llevadas a cabo por ella durante el mismo, como sonla implementación, la integración, las pruebas de integración y la documentación de lossubsistemas objeto del trabajo.

1.1 AntecedentesComo antecedente del actual proyecto, hay que destacar el micro-satélite UPMSat-1/ROLEU4. En éste, un grupo de ingenieros y profesores del Laboratorio de Aerodinámica de laEscuela Técnica Superior de Ingenieros Aeronáuticos (ETSIA) de la Universidad Poli-técnica de Madrid (UPM) desarrollaron dicho satélite y el mismo fue lanzado en julio de1995. La misión fue un éxito y demostró la capacidad de los ingenieros por desplegar unproyecto de tal envergadura.

Como consecuencia de este primer proyecto surgió el UPMSat-2, que tiene por obje-tivo desarrollar un micro-satélite utilizable como plataforma de demostración tecnológicaen órbita (basada en la anterior) y cuya carga son diferentes experimentos científicos eindustriales para su operación en el espacio. En este proyecto se contemplan todas lasetapas de la vida del satélite: diseño, construcción, validación, lanzamiento y puesta enórbita.

El proyecto UPMSat-2 está liderado por el Instituto “Ignacio de Riva” (IDR1) de laUPM. El Grupo de Sistemas en Tiempo Real y Arquitectura de Servicios Telemáticos(STRAST2) de la ETSIT de Telecomunicación está colaborando en este desarrollo. Estegrupo es el responsable de desarrollar el software de a bordo del satélite y del segmen-to de tierra de la misión. El desarrollo del computador de a bordo se está realizando encolaboración con empresas del sector aeroespacial español. El grupo STRAST ha cola-borado con la Agencia Europea del Espacio (ESA) en diferentes proyectos de softwarerelacionados con el desarrollo de software embarcado en satélites.

1http://www.idr.upm.es2http://www.dit.upm.es/~str/

1

1.2. MOTIVACIÓN 2

1.2 MotivaciónA día de hoy, el grupo STRAST ha realizado el análisis, validación e implementación devarios subsistemas que garantizan el funcionamiento del UPMSat-2.

El desarrollo de este Trabajo Fin de Grado parte de unos prototipos de los compo-nentes Manager, ADCS y Plataforma del micro-satélite, realizados con el lenguaje Ada2005. El objetivo de este trabajo es completar los prototipos mencionados, integrarlos enun sistema operativo y realizar un conjunto de pruebas, para comprobar su correcto fun-cionamiento. El resultado de este trabajo es una versión operativa del sistema, que incluyelos diferentes componentes interactuando, de acuerdo a la especificación y el diseño delsistema.

1.3 ObjetivosLos principales objetivos del Trabajo Fin de Grado son:

• Analizar los estándares de la Agencia Espacial Europea (ESA3) para el desarro-llo del software a bordo para un micro-satélite y los documentos generados porel grupo de profesores encargados del proyecto: SSS 4 y SRS 5, que contiene lasespecificaciones del UPMSat-2.

• Realizar un estudio sobre los prototipos disponibles de los componentes del soft-ware de a bordo del satélite.

• Integrar y completar los componentes, usando el lenguaje de programación Ada2005.

• Realizar pruebas de integración.

• Documentación del proyecto mediante LaTeX para el presente Trabajo Fin de Gra-do y para la continuación del proyecto UPMSat-2.

1.4 Estructura del documentoCon el fin de presentar los conceptos básicos y los detalles tecnológicos sobre el micro-satélite, el capítulo 2 describe de forma general el satélite universitario UPMSat-2.

El capítulo 3 realiza una revisión del marco de herramientas usado a lo largo de laimplementación del trabajo.

Posteriormente, se presenta el desarrollo elaborado de los subsistemas Manager, Pla-taforma y ADCS en los capítulos 5, 6 y 7 respectivamente.

Por último, en el capítulo 8 se explican las conclusiones del trabajo así como el trabajofuturo del proyecto.

3http://www.esa.int/ESA/4http://www.dit.upm.es/~str/proyectos/upmsat2/documentacion/UPMSat2-SSS-2.2.pdf5http://www.dit.upm.es/~str/proyectos/upmsat2/documentacion/UPMSat2-SRS-1.2.pdf

Capítulo 2

Satélite universitario UPMSat-2

2.1 Descripción del UPMSat-2El satélite UPMSat-2 es un micro-satélite cuya función es ser utilizado como plataformade demostración de tecnología de órbita, que tiene previsto su lanzamiento para el cuartotrimestre del año 2015.

Se trata de un cuboide de dimensiones 0,5x0,5x0,6 m (figura 2.1)y masa total alrede-dor de 50 kg, cuya vida útil esperada será de al menos 2 años.

Figura 2.1: UPMSat-2

Describirá una órbita heliosíncrona (figura 2.2) a una altura de 600 km, por lo quepasará por una latitud determinada siempre a la misma hora local dos veces al día, unapor el día y otra por la noche. Por esta razón, el satélite será visible durante 5-10 minutoscada vez que pase por un punto de visibilidad entre la estación de tierra y el UPMSat-2.

El objetivo del proyecto UPMSat-2 es el desarrollo de una misión de un micro-satéliteque puede ser utilizado como una plataforma de demostración de tecnología en órbita.El proyecto está siendo llevado a cabo por un equipo de investigadores, estudiantes, ypersonal auxiliar de la Universidad Politécnica de Madrid y está liderado por el Ignacioda Riva, instituto de investigación, con la participación del grupo STRAST, TECNOBIT, y

3

2.2. PLATAFORMA DE EJECUCIÓN 4

Figura 2.2: Órbita heliosíncrona

otros grupos de investigación y empresas industriales. STRAST está a cargo del desarrollode software, y TECNOBIT1 es el encargado de desarrollar el hardware en el ordenadorde a bordo y otros subsistemas electrónicos para la misión.

2.2 Plataforma de ejecuciónEl software del satélite se ejecutará sobre un computador On-Board Computer (OBC),que está basado en la familia de computadores LEON32.

El software compila con GNU NYU Ada Translator (apartado 3.3), que como se ex-plicará en los subapartados siguientes interactúa con el kernel ORK+. Además, tambiénhace uso del hardware mediante drivers programados para un empleo adecuado.

La plataforma de ejecución es:

Figura 2.3: Plataforma de ejecución

1http://www.tecnobit.es2http://www.gaisler.com/index.php/products/processors/leon3

2.2. PLATAFORMA DE EJECUCIÓN 5

2.2.1 Computador embarcadoEl software se ejecutará sobre un computador embarcado (OBC). El diseño fue elaboradopor el grupo STRAST y TECNOBIT. Se pusieron ciertas restricciones en los paráme-tros ambientales tales como la radiación, la temperatura, y la aceleración y potencia delsatélite.

Sus características principales son:

• Procesador LEON3. Está clasificado por la ESA para misiones de vuelo. Tiene unaarquitectura RISC (SPARC v8), un modelo VHDL abierto, por lo que se puedegrabar en FPGA y una potencia limitada (0,5W y 100 MHz).

• 4 MB de memoria estática de acceso aleatorio (SRAM).

• 1 MB de memoria EEPROM, es decir, ROM programable y posibilidad de ser bo-rrada eléctricamente.

• 64 entradas analógicas.

• 64 entradas y salidas digitales.

• Interfaces serie: RS422, RS232, y los buses de comunicaciones en serie I2C y SPI.

2.2.2 Open Ravenscar Kernel (ORK +)El ORK+3 es un kernel en tiempo real de código abierto. ORK fue desarrollado parala implementación de sistemas de alta integridad en tiempo real en un subconjunto dellenguaje Ada 2005 conocido como Perfil de Ravenscar. Impone unas restricciones a estelenguaje, por lo que las operaciones permitidas resultantes son consideradas seguras parasistemas de tiempo real.

ORK fue desarrollado originalmente bajo contrato de la ESA, con sede en Ada 95. Laversión actual ORK+ es compatible con el estándar Ada 2005 y se ha desarrollado comoparte del trabajo de la UPM en el proyecto ASSERT.

Las principales funciones que proporciona son:

• Concurrencia: Soporta hebras que se crean al comienzo de la ejecución del progra-ma y no pueden terminar. Se planifican mediante prioridades fijas con desalojo.

• Sincronización: Proporciona dos tipos de mecanismos para la sincronización. Unode ellos es el cerrojo, que asegura la exclusión mutua en las operaciones de losobjetos protegidos de Ada. Las variables de condición proporcionan un mecanismopara que una hebra se suspenda hasta que otra hebra avise de que ha cumplido unacondición.

• Tiempo: Proporciona un reloj de tiempo real.

3http://www.dit.upm.es/~ork/index.html/

2.3. ARQUITECTURA SOFTWARE 6

• Interrupciones: Da soporte de bajo nivel para las interrupciones, junto con una ope-ración que permite enlazar una interrupción con un procedimiento protegido deforma estática.

ORK está integrado con las herramientas de compilación de GNAT. Además con lasherramientas incluidas en la distribución de GNATforLEON es posible la compilacióncruzada para la ejecución sobre procesadores de la familia LEON.

2.3 Arquitectura softwareSiguiendo los requisitos y especificaciones contemplados en el SRS4 y SSS5, el sistemadel micro-satélite UPMSat-2 se subdivide principalmente en dos categorías: segmentosde vuelo y de tierra.

El segmento de tierra será el encargado de comunicarse con el satélite mediante elenvío de telecomandos y de recibir las mediciones, eventos y errores producidos en elespacio por telemetría.

Por otro lado, el segmento de vuelo se compone de distintos subsistemas que se mues-tran en el diagrama 2.4. A continuación se procederá a describirlos:

Figura 2.4: Arquitectura software

• Manager: Se encarga de la inicialización del sistema, la recepción de eventos y erro-res del resto de los módulos del software y de cambiar el modo de funcionamientodel satélite.

• Experimentos: Está a cargo de los diferentes experimentos. Gestionará el inicio yfin de éstos y tomará las medidas de interés para que sean interpretadas en tierra.

4http://www.dit.upm.es/~str/proyectos/upmsat2/documentacion/UPMSat2-SRS-1.2.pdf5http://www.dit.upm.es/~str/proyectos/upmsat2/documentacion/UPMSat2-SSS-2.2.pdf

2.4. MODOS DE FUNCIONAMIENTO 7

• Plataforma: Se encarga de las funciones de adquisición de datos de mantenimiento(housekeeping) del satélite y de la gestión de la plataforma. Controla el estado delos diferentes dispositivos del satélite mediante chequeos periódicos.

• ADCS: Controla y determina la actitud del satélite. Se lleva a cabo mediante el pro-cesado de medidas del campo magnético de la Tierra a través de los magnetómetros.Los actuadores del subsistema son los magnetopares, electroimanes que generar uncampo magnético que interactúa con el de la Tierra haciendo girar al satélite.

• TTC: Descodifica y ejecuta órdenes desde tierra y procesa la telemetría. Interactúacon el equipo hardware de comunicaciones.

• Storage: Registra datos de eventos, errores, estados, medidas de la carga útil y tele-comandos.

• Hardware Communication: API para el protocolo de transmisión y recepción decomunicación.

• Hardware Access: API para el acceso a dispositivos hardware.

• BasicTypes: van registrados todos los tipos que serán utilizados por el software delsatélite.

2.4 Modos de funcionamientoLos modos de funcionamiento del UPMSat-2 también se recogen en los documentos SRSy SSS, que se muestran en la figura 2.5.

En el modo de funcionamiento en tierra se destaca que tras la finalización de la inte-gración de todos los subsistemas, se procederá a realizar pruebas con SVG en el modo deTest.

Se hará un análisis más exhaustivo del modo de funcionamiento de vuelo, debido aque el presente trabajo se centra en dicho funcionamiento.

En primer lugar, el OBC está inactivo hasta que recibe la señal de un temporizadordel hardware al expirar. En este momento se pasa a modo de comprobación, momentodonde se inicia el OBC, se copia el programa de la EEPROM a SRAM y se cargan ciertosparámetros de configuración (initialization mode). Además, el Manager comprueba sitodos los subsistemas están preparados para continuar (commisioning mode). Este pasosólo se realiza en caso de que sea la primera vez que se inicia el OBC.

Tras estas tareas, el satélite entra en modo degradado, en el que realizará las tareasesenciales mientras se cargan las baterías (safe mode).

Después de un telecomando desde tierra, se pasará al modo de operación normal, enel que las funciones del satélite se ejecutan en toda su extensión (nominal mode).

En este estado, pueden suceder diversos acontecimientos:

2.4. MODOS DE FUNCIONAMIENTO 8

Figura 2.5: Modos del UPMSat-2

2.5. DISEÑO 9

• Se recibe un telecomando de comenzar experimento (experiment mode). Tras aca-bar se vuelve a modo nominal.

• Se detecta una pérdida de comunicación y se pasa a modo Beacon. En este momentose emite una señal periódica hasta recibir cualquier tipo de telecomando. Se pasa amodo seguro.

• Se recibe eventos de warnings de la batería. En caso de que sea batería baja serealiza un cambio de modo a safe y si resulta batería crítica se pasa a modo latencia.Cuando se cambia a éste último, el sistema se apaga y se vuelve a inicializar al saltarun temporizador.

El cambio de estado del satélite se puede ordenar desde el segmento de tierra medianteun telecomando. Un requisito del sistema es que se deben tratar este tipo de telecomandoscambiando el modo de funcionamiento del satélite lo antes posible.

Partiendo del diseño general del satélite (apartado 2.3), el presente Trabajo Fin deGrado pretende integrar tres de los subsistemas. Éstos son el Manager, la Plataforma y elADCS. También existirá una versión operativa entre estos módulos.

2.5 DiseñoDeben de cumplirse las siguientes iteraciones entre los componentes que se quieren inte-grar:

• Plataforma:

– Opera valores reales de sensores (HWAccess).

– Comprueba si dichos valores se encuentran en el rango válido fijado en laespecificación (Storage).

– Debe comunicar al Manager eventos significativos o errores detectados.

• ADCS:

– Debe comunicar al Manager eventos significativos o errores detectados.

• Manager:

– Debe detectar y gestionar los eventos/errores recibidos y decidir las transicio-nes de estados pertinentes según establecen las especificaciones.

– Notificar el cambio de modo al resto de subsistemas.

Además, a lo largo del proceso, se irán realizando pruebas a través de ficheros ejecuta-bles en Ada donde se comprobará el correcto funcionamiento de la integración realizada.

En el diagrama 2.6, se muestra la arquitectura de los módulos definidos y las interfacesque existen entre ellos. En los siguientes apartados se explicará el desarrollo de éstos.

2.5. DISEÑO 10

Figura 2.6: Diagrama de los subsistemas e interfaces

Capítulo 3

Marco de desarrollo

En esta sección se explicará todos los conceptos y herramientas necesarias para la integra-ción de los subsistemas, así como la documentación externa que la estudiante ha seguidopara conseguir este propósito.

3.1 Lenguaje de programación AdaAda es un lenguaje de programación orientado a objetos y fuertemente tipado de formaestática. Se trata de un lenguaje multipropósito y concurrente.

Fue diseñado por un grupo liderado por Jean Ichbiah de CII Honeywell Bull, porencargo del Departamento de Defensa de los EEUU. Su prioridad era la seguridad (safety)y tenía una filosofía orientada a la reducción de errores, sobre todos aquellos que erancomunes y difíciles de descubrir. Para lograr esto, Ada se basa en un tipado fuerte y encomprobaciones en tiempos de ejecución.

Este lenguaje se usa principalmente en entornos que requieren una gran seguridad,como la aeronáutica, la gestión del tráfico aéreo y la industria aeroespacial. El lenguaje seconvirtió en un estándar de ANSI en 1983 (ANSI/MIL-STD 1815) y un estándar ISO en1987 (ISO-8652:1987).

Debido a estas características, ha sido elegido como lenguaje de programación para elproyecto y se utilizará la versión normalizada Ada 2005 (ISO 8652:1995/Amd 1:20071).

Un programa en Ada se compone de una o más unidades:

• Subprogramas: procedimientos, abstracciones básicas que representan una acción yfunciones, abstracciones que representan un valor.

• Paquetes: módulos donde se declaran datos, tipos de datos, operaciones, etc. Tienendos partes (que se compilan por separado):

1http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=45001

11

3.2. PERFIL DE RAVENSCAR 12

– Especificación: define la interfaz visible del paquete (declaraciones).

– Cuerpo: contiene los detalles de la implementación (tipos, objetos, subprogra-mas y los cuerpos de éstos declarados en la especificación). Es invisible parael resto del programa.

• Tareas y objetos protegidos: ejecución concurrente de las actividades.

3.2 Perfil de RavenscarEl perfil de Ravenscar es un subconjunto del lenguaje de programación Ada especial-mente pensado para los sistemas de tiempo real. Impone ciertas restricciones a la parteconcurrente del lenguaje para realizar análisis temporales y permitir una implementacióneficiente del núcleo de ejecución. Aunque se definió originalmente para el lenguaje deAda, su modelo de computaciones se puede extrapolar a otros paradigmas de programa-ción concurrente como POSIX.

La necesidad de este perfil surgió a la vista de la complejidad del modelo de concu-rrencia de Ada, que aunque está orientado a la programación de sistemas de tiempo real,no tiene en cuenta las necesidades de los sistemas críticos.

Los objetivos con los que se crearon este perfil son:

• Conseguir un modelo de ejecución concurrente determinista, de tal forma que seaapto para sistemas de tiempo real críticos.

• Permitir una implementación pequeña, eficiente y con poca sobrecarga, para quelas tareas puedan responder en plazos temporales pequeños.

3.3 Herramientas de desarrollo GNATGNAT es un conocido compilador del lenguaje de programación Ada, que está basado enla infraestructura de compilación de CCC.

Aunque fue desarrollada originalmente por la Universidad de Nueva York, actualmen-te se ocupa de su mantenimiento y desarrollo la empresa AdaCore. Esta compañía ofreceperiódicamente versiones públicas bajo la licencia GPL.

GNAT Programming Studio (GPS) es un entorno de desarrollo con interfaces en Ada.Se trata de un software libre y proporciona las herramientas necesarias para comprobar lasintaxis, la semántica, la construcción y la ejecución de aplicaciones.

3.4 SubversionSe trata de una herramienta de control de versiones open source basada en un repositorio.Es software libre bajo licencia de tipo Apache/BSD.

3.5. MODELO DE CICLO DE VIDA 13

Como se accede a través de redes, permite que pueda ser usada por personas que seencuentran en distintas computadoras.

El proyecto utiliza esta herramienta para guardar las sucesivas versiones del softwarey documentación del satélite UPMSat-2, de manera que todos los integrantes del grupoautorizados puedan acceder a ello.

3.5 Modelo de Ciclo de vidaEl ciclo de vida es el conjunto de fases por las que pasa el sistema que se está desarro-llando desde que nace la idea hasta que el software muere. En cada una de las etapas sepueden establecer una serie de objetivos, tareas y actividades que lo caracterizan. Existendistintos modelos de ciclo de vida.

El ciclo de vida del software del proyecto será el método en V (figura 3.1). Es unproceso que representa la secuencia de pasos en el desarrollo del ciclo de vida del proyectoy se describen las actividades y resultados que deben producirse durante el desarrollo delmismo.

El lado izquierdo de la V representa la descomposición de los requisitos y la creaciónde las especificaciones del sistema. El lado derecho representa la integración de todos loscomponentes y su verificación.

Actualmente, el objetivo de este trabajo es finalizar la integración de los subsistemasya mencionados. Para lograrlo, aún se deberán realizar algunas partes del diseño y laimplementación del mismo.

3.5. MODELO DE CICLO DE VIDA 14

Figura 3.1: Ciclo de Vida en V

Capítulo 4

Desarrollo del Manager

4.1 DiseñoLa responsabilidad principal del Manager es la gestión del estado del satélite. Para cum-plir con esta misión correctamente, se encargará de recibir y tratar los eventos y erroresoriginados en el resto los subsistemas, así como de ejecutar los telecomandos, que pro-vienen del módulo de TTC.

En primer lugar, el Manager tendrá tres interfaces que conectarán al Manager con elresto de subsistemas, que son NotifyEvent, ProcessTC y NotifyAllModeChange.

NotifyEvent se utiliza para que todos los subsistemas notifiquen eventos significativoso errores detectados al Manager.

ProcessTC es una interfaz entre los subsistemas Manager y TTC, y sirve para notificaral Manager que se ha recibido un telecomando desde tierra.

La última, NotifyAllModeChange, es una interfaz entre el Manager y el resto de sub-sistemas y se utiliza para notificar a todos que se ha producido un cambio de estado delsatélite.

Todos los eventos o errores y telecomandos recibidos, serán almacenados en dos ob-jetos protegidos para evitar problemas de concurrencia hasta que sean tratados.

A la llegada de un evento al Manager, éste guardará el evento en el objeto protegidocreado para estos casos y lo mismo ocurrirá a la llegada de un telecomando.

Además, se creará otro objeto protegido que guardará el modo en el que se encuentrael microsatélite. De esta manera, cuando ocurran eventos y telecomandos en momentosconsecutivos, el primero bloqueará el modo, realizándose el cambio de estado si existieray después el segundo, respetándose el orden de llegada.

Será necesario que existan dos tareas:

• Event Listener: Se encarga de escuchar si existe un evento o error en el objetoprotegido correspondiente a la recepción de eventos y errores.

• TC Listener: Se encarga de escuchar si existe un telecomando en el objeto protegidoque recibe los telecomandos.

15

4.1. DISEÑO 16

Estas tareas recogen la información necesaria para poder gestionar si existe un cambiode modo. Por último, si existiera un cambio de modo, se modifica el valor del modo enel objeto protegido y procede notificar al resto de subsistemas el cambio realizado. Semuestra en la figura 4.1 un diagrama explicativo.

Figura 4.1: Diagrama del subsistema Manager

Este trabajo está centrado en la gestión de eventos y errores. El tratamiento de los tele-comandos se ha pospuesto a una fase posterior, debido a su dependencia con el hardwarede comunicaciones y a que éste no se ha definido por completo en esta fase del desarrollo.

Durante el análisis de los requisitos del SRS, se han establecido los diferentes eventosy errores que se deben tratar y su influencia en el estado del satélite.

A continuación se muestran las diferentes posibilidades de eventos y errores y cuál esel significado de cada uno de ellos:

• ChangeMode: Informa que se ha realizado un cambio de estado en el satélite.

• SeparationTimerExpired: Se trata de un temporizador hardware que se activa auto-máticamente después de que la separación del lanzamiento se complete.

• WatchdogTimerExpired: Se utiliza un temporizador hardware de vigilancia paraasegurar que el software se está ejecutando. Un componente del software debe re-programar periodicamente este temporizador. Si expira, es porque el software de abordo no está funcionando correctamente. Entonces se debe emitir una señal parareiniciar el computador de a bordo.

• InitializationDone: Informa de que se han inicializado todos los componentes delsatélite correctamente.

• CommissioningDone: Informa que se ha realizado correctamente la validación delos sensores.

4.1. DISEÑO 17

• TelecommandTimedExecutionInvalid: Se trata de un evento que informa que eltiempo de ejecución de un determinado telecomando es inválido.

• InitializationError: Se utiliza para informar que se ha producido un error en la ini-cialización de algún subsistema o manejador de dispositivo.

• BatteryLowWarning: Se trata de un evento hardware que avisa cuando el nivel debatería es bajo.

• BatteryCriticalWarning: Se trata de un evento hardware que avisa cuando el nivelde batería es crítico.

• ValueOutOfRange: Informa que el valor de un sensor determinado está fuera de surango de validez.

• SensorError: Informa que un sensor no funciona correctamente.

• MagnetometerValueOutOfRange: Informa que el valor de un magnetómetro espe-cífico está fuera de su rango de validez.

• MagnetorquerValueOutOfRange: Informa que el valor de un par de magnetoparesestá fuera de su rango de validez.

• LostComm: Se activa cuando el subsistema de Telemetría y Telecomando detectaque se ha perdido la comunicación con el segmento de tierra.

• NonTrustedSource: Se activa cuando detecta que la fuente de transmisión no es deconfianza.

• RadioHWError: Error que se produce cuando existe un problema en el hardware dela radio.

• ExperimentStarted: Ocurre cuando el módulo Experimentos notifica que ya ha co-menzado a realizar un experimento determinado activado desde tierra.

• ExperimentDone: El módulo Experimentos informa que ha acabado de realizar unexperimento.

• ExperimentAborted: El módulo Experimentos informa que se ha procedido a abor-tar la ejecución de un experimento, debido a algún error sucedido.

• ActuatorError: Error que lanza el módulo Experimentos cuando detecta que existealgún error en un actuador propio de algún experimento.

• ChangeModeTC: Es el evento que manda el subsistema de TTC para que se realiceun cambio de modo. En realidad esta orden se manda desde el segmento de tierra.En sus parámetros se indica el nuevo modo.

Además, se ha elaborado la tabla 4.1 que explica los parámetros de cada uno de ellosy cuál es el módulo que la puede originar:

Analizando los valores de la tabla, se observa que se repiten varios elementos en laestructura de cada uno:

4.1. DISEÑO 18

Evento/Error ParámetrosChangeMode Timer Previous Mode Next Mode

SeparationTimerExpired TimerWatchdog Timer Expired Timer

Initialization Done TimerCommisioning Done Timer

Telecommand Timed ExecutionInvalid Timer TC ID Devised Execution TimeInitialization Error Timer Error ID

Battery Low Warning TimerBattery Critical Warning Timer

Value Out Of Range Timer Signal ID Detected ValueSensor Error Timer Sensor Information Value

Magnetometer Value Out Of Range Timer Signal ID Detected ValueMagnetorquer Value Out Of Range Timer Signal ID Detected Value

LostComm Timer Last Received TC TimeNon Trusted Source Timer Seqence Number

Radio HW Error Timer Error IDChangeModeTC Timer New Mode

Experimet Started Timer Experiment IDExperimet Done Timer Experiment ID

Experimet Aborted Timer Experiment ID Reason(Error, Mode Change, Time Expired)Actuator Error Timer Actuator Information Value

Tabla 4.1: Parámetros de eventos y errores

• El nombre del evento o error.

• El momento en el que sucede.

• Identificador.

Sin embargo, el tercer y cuarto parámetro no tienen una funcionalidad común en todosellos.

Se plantean dos soluciones posibles para su diseño:

• Crear un tipo de evento para cada uno de ellos, de manera que se no introduciríanparámetros innecesarios.

• Crear un único tipo de evento que fuera capaz representar todos los parámetros,aunque algunos estuvieran vacíos en algunos casos.

La primera alternativa tiene la ventaja de ajustar la definición del tipo a los parámetrosdel evento. Sin embargo, dado el carácter fuertemente tipado del lenguaje, se complica ladefinición de los interfaces. Por este motivo, se ha elegido la segunda opción para laimplementación de este componente.

Tras el análisis previo realizado, se hace evidente que los tres primeros datos debenser el nombre de los eventos, el momento en el que éstos se producen y el identificadorpara los que exista. Los otros dos parámetros podrán tener significado diferente, según eltipo de evento o error.

4.2. IMPLEMENTACIÓN 19

4.2 ImplementaciónDebido a que no se quiere que existan problemas de sincronización y que haya un accesosecuencial de datos, se decidió subdividir el subsistema en dos partes. Se suma el hechode que las referencias circulares no están permitidas en Ada y que el Manager debe tenerreferencia de todos los subsistemas y viceversa.

Por un lado, hay una parte pasiva que reúne la información de todos los subsistemas(repositorio). Hay un acceso protegido que permite realizar múltiples tareas para accedersimultáneamente a los datos. No tiene referencia a otros subsistemas, pero al revés sí. Elnombre del archivo de esta parte es manager-hlinterface.

Por el contrario, la parte activa del gestor actúa en función de la información propor-cionada por la parte pasiva. Realiza las operaciones necesarias una vez haya llegado unevento o telecomando. El nombre del archivo de la parte activa es manager-core.

Como actualmente no está implementado el subsistema TTC, se ignorará las especi-ficaciones relativas a éste y se centrará en las interfaces relacionadas con la detección deeventos y errores, y la notificación de cambios de modo al resto de subsistemas.

BasicTypes.ads

El BasicTypes.ads es un artefacto donde se almacenan los distintos registros de losparámetros que se utilizan en la implementación del proyecto. Su finalidad es conseguiruna unidad común entre todos los subsistemas.

Para conseguir implementar los eventos, es necesario crear un registro en el BasicTy-pes.ads que contenga la estructura y los datos de un evento o error genérico.

Para lograrlo, se ha creado el tipo Event, que tendrá 5 parámetros:

• Name: Estará formado por un tipo enumerado que lista los nombres de todos loseventos y errores posibles. Será obligatorio.

• Time: Contendrá el momento en el que se produzca y será de tipo MissionClock(reloj de la misión). Será obligatorio.

• ParameterID: Se rellenará para aquellos casos de que exista. Para esto, se ha creadoun tipo EventParameterID, para el que se han reservado 8 bits.

• ParameterValue1: Se ha creado el tipo EventParameterValue, para el que se hanreservado 32 bits de memoria y se rellenará para los casos de que sea necesario.

• ParameterValue2: Será asignado al mismo tipo del parámetro anterior: EventPara-meterValue. Se rellenará para aquellos casos de que exista.

A continuación se muestra el código empleado:

4.2. IMPLEMENTACIÓN 20

type Ev en t s i s ( S e p a r a t i o n T i m e r E x p i r e d , ChangeMode , I n i t i a l i z a t i o n D o n e ,CommissioningDone , Bat teryLowWarning , B a t t e r y C r i t i c a l W a r n i n g , LostComm ,S e n s o r E r r o r , MagnetometerValueOutOfRange , MagnetorquerValueOutOfRange ,ValueOutOfRange , I n i t i a l i z a t i o n E r r o r , NonTrus tedSource , RadioHWError ,Te lecommandTimedExecu t ionInva l id , ChangeModeTC , WatchdogTimerExpired ,E x p e r i m e n t S t a r t e d , ExperimentDone , Exper imen tAbor ted , A c t u a t o r E r r o r ) ;

type E v e n t P a r a m e t e r I D i s mod 2 ∗∗ 8 ;f o r Even tPa rame te r ID ’ S i z e use 8 ;

type E v e n t P a r a m e t e r V a l u e i s mod 2 ∗∗ 3 2 ;f o r Even tPa rame te rVa lue ’ S i z e use 3 2 ;

type Event i s recordName : E ven t s ;Time : Miss ionClock ;Pa rame te r ID : E v e n t P a r a m e t e r I D ;P a r a m e t e r V a l u e 1 : E v e n t P a r a m e t e r V a l u e ;P a r a m e t e r V a l u e 2 : E v e n t P a r a m e t e r V a l u e ;

end record ;

Subsistema Manager

El Manager es quien se encarga de gestionar los eventos y errores y en como repercu-ten en los estados del satélite. Toma las decisiones sobre el modo en el que se encuentrael UPMSat-2 y lo transmite al resto de módulos.

A día de hoy, están implementados por el grupo STRAST las interfaces de la notifica-ción de eventos y la notificación de cambio de modo a todos los subsistemas: NotifyEventy NotifyAllModeChange. Se respetará esta implementación, variando solamente el tipode evento que recibirá (el definido en el BasicTypes) en las cabeceras de las funciones yprocedimientos.

Sin embargo, en el Core será necesario realizar modificaciones más relevantes paraque el Manager gestione los cambios de modo de manera adecuada según los criteriosestablecidos en el SRS.

Para la gestión de eventos y errores, se ha creado la tarea EventListener. Esta tarea seactiva cuando llega algún evento o error a la parte pasiva del Manager. En este paso, seinserta el parámetro del momento que es gestionado al evento, y llama a la función run-Transition con los parámetros de entrada del modo actual y el evento que se ha recibido.

ta sk body E v e n t L i s t e n e r i sA r r i v e d E v e n t : Bas i cTypes . Event ;Current_Mode : Bas i cTypes . Opera t ingModes ;New_Mode : Bas i cTypes . Opera t ingModes ;

beginloop

A r r i v e d E v e n t := Manager . H L I n t e r f a c e . GetEvent ;Current_Mode := Manager . Core . Current_Mode ;

A r r i v e d E v e n t . Time := HWAccess . H L I n t e r f a c e . Miss ionTime ;S t o r a g e . H L I n t e r f a c e . S t o r e E v e n t E r r o r ( A r r i v e d E v e n t ) ;

New_Mode := r u n T r a n s i t i o n ( Current_Mode , A r r i v e d E v e n t ) ;

i f New_Mode /= Current_Mode then

4.2. IMPLEMENTACIÓN 21

Current_Mode := New_Mode ;Not i fyAl lModeChange ( Mode => Current_Mode ) ;

end i f ;end loop ;

end E v e n t L i s t e n e r ;

La función runTransition se encarga de decidir cuál será el estado final del UPMSat-2, haciendo uso del modo en que se encuentra en ese momento el satélite y el eventorecibido.

Con esta finalidad, se ha realizado la transición entre estados teniendo en cuenta lasespecificaciones marcadas en el apartado 2.4.

Para ello, se han elaborado los diferentes casos posibles de eventos en función delestado actual. Cuando se cumple uno de esos casos, se asigna como modo final aquel quecumpla con las especificaciones. Se han implementado en esta función todas las transi-ciones aunque aún es posible que se añadan nuevas especificaciones al proyecto.

Se muestra un ejemplo a través del diagrama 4.2 para el caso en el que el modo seaInitialization. En este caso, existen tres eventos que modificarían el estado del satélite.

• InitializationDone: Comprueba si es la primera vez que inicializa. Si es así, se pa-sará a modo Comissioning y si no a modo Safe.

• InitializationError: Sigue en modo inicialización.

• ChangeModeTC: Mira el nombre del nuevo modo. Si éste es Safe cambia de modo,si no no.

Figura 4.2: Diagrama de la transición de estados para el caso de Inicialización

Capítulo 5

Desarrollo de la Plataforma

5.1 DiseñoLa Plataforma es el principal responsable de las funciones de mantenimiento físico delsatélite. Se encarga de verificar que los valores de los sensores, que provienen del subsis-tema HWAccess, se encuentran en un rango válido, maneja los dispositivos defectuosos yalmacena la información en el módulo Storage, que es la memoria del satélite.

Al ponerse en marcha el satélite, el Manager realizará un cambio de modo al resto desubsistemas a mediante la interfaz NotifyModeChange. La Plataforma deberá dar la ordende inicializar y activar todos los dispositivos hardware del satélite mediante el HWAccess.Además, debe cargar los parámetros de configuración propios, que están almacenados enel Storage.

Cuando se produzca un cambio de modo, el subsistema deberá guardar en un objetoprotegido el estado del satélite, de manera que trabajará en función de esta variable hastaque llegue un nuevo cambio de modo.

Por otro lado, de manera periódica controlará los valores de los sensores comprobandoque éstos se encuentran en perfecto estado. Para conseguir este objetivo, será necesariauna tarea periódica que se encargue de realizar esta función. Es importante mencionar quedependiendo del modo en el que se encuentre el satélite, la Plataforma realizará la lecturade unos sensores u otros, según los documentos SRS y SSS.

Por último, en caso de detectar eventos o errores significativos, debe notificárselo alManager haciendo uso de la interfaz que existe entre ellos (NotifyEvent).

En la figura 5.1 se muestra un diagrama explicativo del diseño.

Configuración de Parámetros de la Plataforma

Según los documentos SRS y SSS, los datos de configuración de la plataforma sedistinguen en dos grupos:

• Periodos de muestreo. Se asigna a cada grupo de señales el periodo de muestreodeterminado en las especificaciones. Se muestran en la tabla 5.1.

22

5.1. DISEÑO 23

Figura 5.1: Diagrama del subsistema Plataforma

Category Variable SamplingTemperature Satellite Sides 60s

Battery 60sMagnetometers 60sMagnetorquers 60s

Radio 60sMicro Thermal Switch 60sSolar Cell Technology 60sOn-Board Computer 60sPower Supply Unit 60s

Solar Panels 60sMagnetic Field Magnetometers 60s

Voltage Bus 20sBattery 20s

Solar Cell Technology 20sCurrent Battery 20s

Solar Panels 20sPower Distribution Unit 20s

Power Supply Unit 20sSolar Cells 20s

Solar Cell Technology 20sSolar Radiation Sensor 20s

Tabla 5.1: Periodos de muestreo de los sensores

5.1. DISEÑO 24

• Rangos de validez. Se asigna a cada señal dos variables, los umbrales superior einferior posibles durante el vuelo del satélite. En la tabla 5.4 se muestran los rangosposibles para cada señal.

Stub del HWAccess

Con el objetivo de tener una versión operativa del proyecto, es necesario poder tomarmedidas de los diferentes componentes hardware del satélite. Puesto que es imposible po-der tomar medidas reales desde tierra de lo que sucedería durante el vuelo en la actualidad,se ha realizado un stub de la interfaz del HWAccess.

El subsistema HWAccess es el que se encarga de intermediar entre los drivers debajo nivel: EBOX, UART e I2C drivers (figura 5.2) y los subsistemas de alto nivel delsoftware: Plataforma, Manager, ADCS, además de otros que en la presente memoria nose especificarán.

Figura 5.2: Diagrama de drivers

Específicamente, será la Plataforma quien interactuará principalmente con esta inter-faz para encender, leer, comprobar y apagar los sensores. El ADCS también la usará parala lectura de los magnetómetros y la actuación de los magnetopares.

Generación de eventos y errores

5.1. DISEÑO 25

El último paso para integrar la Plataforma al resto de subsistemas, es el hecho de creareventos o errores según circunstancias específicas.

Estas circunstancias pueden ser:

• Errores de inicialización de hardware.

• Avisos de batería baja y crítica.

• Valores no válidos de señales.

• Errores en sensores.

Conversión de magnitudes analógicas a digital

El primer paso antes de comenzar con la integración de los subsistemas Plataforma,ADCS y Manager, es poder tener datos reales durante el vuelo y cómo los leerá el OBC.Se ha realizado una lista de los umbrales mínimo y máximo posible de cada señal en elespacio. Por lo que se partirá de esta lista para hallar los valores límite superior e inferiorque el software leerá y gestionará.

A la hora de realizar la toma de datos de las medidas a realizar, surge el problema detratar con diferentes magnitudes reales que son analógicas (temperatura, tensión, corrientey campo magnético). El fin es conseguir datos en formato digital en una secuencia de bitsde 0 a 4095. Para conseguir este objetivo, se usarán unos sensores determinados para cadamagnitud, que se dedicarán a cuantificarla dando un voltaje de salida proporcional a lamagnitud de la entrada.

A día de hoy, los integrantes del proyecto UPMSat-2 no tienen decidido todos lossensores específicos. Uno de los sensores escogidos es el sensor de temperatura que seusará para medir la temperatura de microswitches durante el experiemnto MTS. Se usaráel AD590K1. Se pueden leer sus especificaciones en su datasheet. Éste servirá como basepara realizar las funciones de transferencia adecuadas para todos los casos dando unosresultados razonables.

En primer lugar, se deben convertir aquellos rangos cuyos valores puedan ser nega-tivos o positivos. Para ello, al mínimo de la señal analógica se le debe restar el valormínimo que pueda medir el sensor (MínEntradaSensor). De esta manera, se consigue queel mínimo se convierta siempre en 0. A continuación, se realiza el cálculo del factor deconversión de los sensores para amoldarlos a la salida de los mismos. Para este caso, lafórmula es trivial:

FactorDeConversionSensor =MaxSalidaSensor −MinSalidaSensor

MaxEntradaSensor −MinEntradaSensor

En este punto, se ha conseguido cuantificar las diferentes magnitudes posibles a unasimple magnitud: el voltaje.

1http://pdf.datasheetcatalog.com/datasheet/analogdevices/AD590K.pdf

5.1. DISEÑO 26

Para conseguir la transformación de tensión a bits, se hará uso de un conversor analó-gico digital (ADC). Éste, produce una secuencia de bits proporcional a la diferencia entreel voltaje de entrada y el de referencia.

El conversor analógico digital será el ADC128S102QML2, de 12 bits por lo que habráun rango de precisión de 0 a 4095.

El voltaje de entrada será el mayor rango de entre las opciones de los diferentes sen-sores. De esta manera, todos serán válidos para ser convertidos por el ADC. El rango desalida será entre 0 y 4095. Por lo que, el factor de conversión del ADC será:

FactorDeConversionADC =MaxSalidaADC −MinSalidaADC

MaxEntradaADC −MinEntradaADC

Por tanto, para conseguir los rangos de validez de las señales esperadas desde la mag-nitud analógica al formato digital, se debe insertar el valor analógico en las siguientesfunciones de transferencia:

ValorMinDigital =(MinAnalogico−MinEntradaSensor)∗FactordeconversionSensor∗FactordeconversionADC

ValorMaxDigital =(MaxAnalogico−MinEntradaSensor)∗FactordeconversionSensor∗FactordeconversionADC

A continuación, se muestran dos tablas (tablas 5.2 y 5.3) de los rangos de validez delas diferentes magnitudes y de cada sensor, que servirá para calcular los rangos de validezfinales de cada una de las señales:

ADCRango Sensor Rango Salida Factor ADC

0-24 0-4095 170,625

Tabla 5.2: Factor de ADC

Rango Máximo Unit Rango Sensor Salida Sensor Unit Factor Sensor Factor ADC Rangos ValidezTipos Min Max Min Max Min Max Min Max

V 0 24 V 0 24 0 24 V 1 170,625 0 4095I -3 4 A -5 5 0 10 V 1 170,625 341 1535T -40 80 oC -50 150 0 16 V 0,08 170,625 136 1774

MG Tesla Tesla T Tesla Tesla 0 5 V 170,625I(SC) 0 0,008 A 0 0,01 0 0,1 V 10 170,625 0 13

T(TMGM) -40 80 oC -50 150 0 5 V 0,025 170,625 42 554T(MTS) -40 80 oC -55 150 4 30 V 0,126829268 170,625 324 2921

Tabla 5.3: Calculos de rangos de validez de las diferentes magnitudes

Todas las estimaciones de rangos que se han realizado en esta memoria, han sidopartiendo de los rangos preestablecidos que han proporcionado los Ingenieros de Aero-náutica.

Para finalizar, se muestra en la tabla 5.4 todos los rangos de validez de las señales amedir, tanto en formato analógico como digital.

2http://www.ti.com/lit/ds/symlink/adc128s102qml-sp.pdf

5.1. DISEÑO 27

Name Rango Salida ADCMin Max Min Max

Bus voltage 18 24 3071 4095Voltage of battery 18 24 3071 4095Current of battery -3 4 341 1535

Current of solar panel X+ 0 2 853 1194Current of solar panel X- 0 2 853 1194Current of solar panel Y+ 0 2 853 1194Current of solar panel Y- 0 2 853 1194Current of solar panel Z+ 0 1 853 1023

Current of string estec 0 0,5 853 938Temperature of X+ -20 50 409 1365Temperature of X- -20 50 409 1365Temperature of Y+ -20 50 409 1365Temperature of Y- -20 50 409 1365Temperature of Z+ -20 50 409 1365

Temperature battery 1 -10 50 546 1365Temperature battery 2 -10 50 546 1365Temperature battery 3 -10 50 546 1365

Magnetometer temp. (internal) -20 50 127 426Magnetometer temp. (external) -40 80 42 554

Solar cell output 0 0,008 0 13Solar cell output 0 0,008 0 13Solar cell output 0 0,008 0 13Solar cell output 0 0,008 0 13Solar cell output 0 0,008 0 13Solar cell output 0 0,008 0 13

Magnetorquers current sensor -0,07 0,07 841 865Temp. magnetorquer X -20 50 409 1365Temp. magnetorquer Y -20 50 409 1365Temp. magnetorquer Z -20 50 409 1365

Temperature of Z- -20 50 409 1365Temperature of transmitter -10 40 546 1228

Temperature of receiver -10 40 546 1228Temperature of OBC -10 40 546 2055

Temp. sensor 1 on hot base -40 80 136 2921Temp. sensor 2 on hot base -40 80 136 2921Temp. sensor 1 on cold base -40 80 136 2921Temp. sensor 2 on cold base -40 80 136 2921

Temp. sensor 1 on intermediate cylinder -40 80 136 2921Temp. sensor 2 on intermediate cylinder -40 80 136 2921

Temp. magnetometer 3 -20 50 409 1365Utiliza sensores de Ta adicionales -40 80 136 1774

Tabla 5.4: Lista Señales y Rangos de Configuración

5.2. IMPLEMENTACIÓN 28

5.2 ImplementaciónEn este momento, en el proyecto hay una versión de la Plataforma donde se cumplensus especificaciones a falta de la implementación de los eventos y errores según se ex-plicará en subapartados posteriores. La estructura lógica del subsistema se divide en doselementos:

• Platform-hlinterface: se encuentran las interfaces con el resto de subsistemas.

• Platform-core: se encuentra la lógica del subsistema (tarea de medidas periódicasde los sensores).

El Storage, módulo que no se trata en este trabajo, tiene una versión cuyas funcionesrelacionadas con la Plataforma funcionan de la manera deseada, es decir, es capaz dealmacenar los datos de configuración y enviarlos bajo petición.

Para acceder a los parámetros en el Storage, se ha creado el paquete ConfigurationPlat-formParameters en Ada. En él, se ha implementado el procedimiento ConfigurePlatform-Parameters, que se encarga de escribir los valores digitales calculados de los parámetrosde configuración de la Plataforma.

Para lograr este objetivo, se creó en el artefacto Basictypes.ads el registro Platform-ConfigurationParametersType, formado por dos arrays. El primero aloja el nombre detodas las señales y los umbrales superiores e inferiores por cada una de ellas. El segundocontiene los grupos de señales y el periodo de muestreo para cada grupo.

Por tanto, el procedimiento creado está formado por una variable de este tipo en laque se van rellenando estos dos arrays según los datos ya expuestos.

Por último, se carga la variable en el Storage, donde finalmente se queda almacenadode forma permanente.

Este paquete no irá integrado en el software del satélite como tal, sino que ayudaráa cargar los parámetros de configuración en la memoria EEPROM antes de lanzar elsatélite al espacio. Es decir, se trata de un paquete auxiliar para el módulo Storage, peroimprescindible para que la Plataforma pueda realizar correctamente sus funciones.

Implementados todos los paquetes auxiliares necesarios para el funcionamiento delsubsistema, la Plataforma, en este momento, es capaz de validar los datos del hardwareque están siendo simulados por el stub del HWAccess y comparar que éstos están dentrodel rango establecido para cada una de las señales de los sensores dispuestos. Se debeahora implementar los eventos que surjan ante las irregularidades del housekeeping.

Estos eventos se generarán a raíz de la estructura creada en el registro del BasicTy-pes.ads y se mandarán al Manager a partir de la interfaz NotifyEvent existente en elmanager-hlinterface. Como se respetará la estructura definida en el registro, ambos subsis-temas podrán entenderse y este último podrá realizar las gestiones oportunas ya definidas.

Para insertar los eventos en el código, se deben rellenar los parámetros de cada uno deellos según lo definido en la tabla 4.1.

5.3. VALIDACIÓN 29

Se muestra un ejemplo del código para validar si el valor que proporciona el HWAc-cess está por encima del umbral superior establecido. Si fuera así, se genera un evento detipo ValueOutOfRange. Los parámetros de éste, son el ID de la señal y el valor medido.

i f PV_TPSZp_TM_Value < P a r a m e t e r s . P l a t f o r m C o n f i g u r a t i o n P a r a m e t e r s .V a l i d i t y R a n g e s ( Bas i cTypes . PV_TPSZp_TM ) . LowerThresho ld then

Event . Name := Bas icTypes . ValueOutOfRange ;Event . Pa rame te r ID := To_Even tParamete r ID ( Bas i cTypes . PV_TPSZp_TM ) ;Event . P a r a m e t e r V a l u e 1 := To_Even tPa rame te rVa lue ( PV_TPSZp_TM_Value ) ;Manager . H L I n t e r f a c e . N o t i f y E v e n t ( Event => Event ) ;

end i f ;

5.3 ValidaciónPara poder realizar pruebas de integración, es necesario manejar valores reales. Para con-seguirlo se creará un paquete del stub del HWAccess, que devolverá unos valores prefija-dos que estarán escritos directamente sobre el código. Dependiendo de la funcionalidadde los procedimientos o funciones de este paquete se ha realizado una implementación uotra.

Para aquellos procedimientos que se dedican a activar o desactivar ciertos componen-tes, se han creado variables booleanas que guardan la última información de la situaciónde estos componentes. Esta variable además servirá a los procedimientos que compruebanel estado de éstos.

−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− Deac t i va t e_MTS_Supp ly −−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−procedure Deact iva te_MTS_Supply i sbegin

Aux_Status_MTS_Supply := f a l s e ;end Deact iva te_MTS_Supply ;

−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− A c t i v a t e _M T S_ Su p p l y −−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−Aux_Status_MTS_Supply : Boolean := f a l s e ;procedure Activate_MTS_Supply i sbegin

Aux_Status_MTS_Supply := t r u e ;end Activate_MTS_Supply ;

−−−−−−−−−−−−−−−−−−−−−−−−−− Check_MTS_Supply −−−−−−−−−−−−−−−−−−−−−−−−−−procedure Check_MTS_Supply (MTS : out Boolean ) i sbegin

MTS := Aux_Status_MTS_Supply ;end Check_MTS_Supply ;

El resto de procedimientos se encargan de la toma de valores de los diferentes sen-sores de temperatura, tensión, corriente y campo magnético. Éstos devuelven el valor enformato digital y están prefijados en función de los rangos calculados en el anterior apar-tado. Se han asignado valores comprendidos entre los rangos establecidos, en particularpara cada señal.

5.3. VALIDACIÓN 30

procedure G e t _ T e m p e r a t u r e s _ S a t e l l i t e _ S i d e s( PV_TPSXp_TM_Value : out Bas icTypes . Ana logS igna lDa taType ;PV_TPSXn_TM_Value : out Bas icTypes . Ana logS igna lDa taType ;PV_TPSYp_TM_Value : out Bas icTypes . Ana logS igna lDa taType ;PV_TPSYn_TM_Value : out Bas icTypes . Ana logS igna lDa taType ;PV_TPSZp_TM_Value : out Bas icTypes . Ana logS igna lDa taType ;PV_TPSZn_TM_Value : out Bas icTypes . Ana logS igna lDa taType ) i s

begin

PV_TPSXp_TM_Value := 10#700#;PV_TPSXn_TM_Value := 10#700#;PV_TPSYp_TM_Value := 10#700#;PV_TPSYn_TM_Value := 10#700#;PV_TPSZp_TM_Value := 10#700#;PV_TPSZn_TM_Value := 10#700#;

end G e t _ T e m p e r a t u r e s _ S a t e l l i t e _ S i d e s ;

Existen dos funciones concretas diferentes al resto. Éstas son, el reloj de misión y elestado de warning de las baterías.

En el primer caso es evidente que interesa tener un orden cronológico de los acon-tecimientos, en vez de obtener siempre el mismo valor. Para lograrlo, se ha creado unavariable auxiliar que actúa como un contador de tipo MissionClock, que suma una unidadpor cada iteración.

−−−−−−−−−−−−−−−−−−−−−− M i s s i o n Time −−−−−−−−−−−−−−−−−−−−−−Aux_Mission_Time : Bas i cTypes . Mis s ionClock := 10#0# ;f u n c t i o n MissionTime re turn Bas icTypes . Mis s ionClock i sbegin

Aux_Mission_Time := Aux_Mission_Time + 1 ;re turn Aux_Mission_Time ;

end MissionTime ;

En el segundo caso, es deseable que los avisos del estado de la batería vayan variandopara poder comprobar el correcto funcionamiento del sistema. Esto es así debido a la granimportancia que tienen los avisos de batería baja y crítica, que supondría el cambio deestado del satélite. Con la ayuda de una variable auxiliar que actúa de contador, se hadispuesto que cuando la variable valga 10 y 15 se devuelva un aviso de batería baja ycrítica respectivamente.

−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− Check_Bat t_Warn ings −−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−Aux_Counte r_Bat t_Warn ings : I n t e g e r : = 0 ;A u x _ S t a t u s _ B a t t _ W a r n i n g s : Bas i cTypes . B a t t e r y W a r n i n g s := Bas i cTypes . None ;f u n c t i o n Check_Bat t_Warn ings re turn Bas icTypes . B a t t e r y W a r n i n g s i sbegin

i f Aux_Counte r_Bat t_Warn ings <1000 thenA u x _ S t a t u s _ B a t t _ W a r n i n g s := Bas i cTypes . None ;

e l s i f Aux_Counte r_Bat t_Warn ings <2000 thenA u x _ S t a t u s _ B a t t _ W a r n i n g s := Bas i cTypes .BATT_WBC;

e l s i f Aux_Counte r_Bat t_Warn ings <3000 thenA u x _ S t a t u s _ B a t t _ W a r n i n g s := Bas i cTypes .BATT_WBL;

e l s i f Aux_Counte r_Bat t_Warn ings < 4000 thenA u x _ S t a t u s _ B a t t _ W a r n i n g s := Bas i cTypes .BATT_WBH;

end i f ;

5.3. VALIDACIÓN 31

Aux_Counte r_Bat t_Warn ings := Aux_Counte r_Bat t_Warn ings +1;re turn A u x _ S t a t u s _ B a t t _ W a r n i n g s ;

end Check_Bat t_Warn ings ;

Este paquete sustituirá al implementado anteriormente (HWAccess) y será el utiliza-do para la integración. Se ha tenido especial cuidado en mantener las cabeceras de losprocedimientos y funciones de la versión real del HWAccess, de manera que no varíe laforma de llamar a éstos desde los otros subsistemas y no sea necesario volver a realizarotra implementación de los subsistemas a integrar.

Capítulo 6

Desarrollo del ADCS

6.1 DiseñoLa funcionalidad del subsistema ADCS (subsistema de determinación y control de acti-tud) se basa en la orientación del satélite. El eje Z está destinado a ser normal a la órbita,de modo que la antena sea siempre visible desde la Tierra (figura 6.1). El satélite debegirar lentamente alrededor de este eje para proporcionar estabilidad térmica entre todaslas caras del satélite.

Figura 6.1: Actitud del satélite

Para lograrlo, mide el campo magnético de la Tierra a través de magnetómetros ycorrige la actitud variando la intensidad en los magnetopares en función de la medida delcampo.

De forma adicional, podrá realizar experimentos que sustituyan este proceso, por loque existirá un modo interno del subsistema que indicará si se está procediendo en modo

32

6.1. DISEÑO 33

nominal o si por el contrario se debe realizar algún experimento.

Por tanto, será necesario que existan dos objetos protegidos que registren el estado delsatélite y el modo interno del subsistema. Además, para no perder el orden de las medidasy de los valores de los actuadores, también se crearán otros dos objetos protegidos queregistren el valor de ambos.

Con esta motivación será necesario realizar tres tareas:

• Tomar medidas de los magnetómetros o de los componentes necesarios en funcióndel modo interno del ADCS. Al detectarlo lo guarda en el objeto protegido.

• Tarea que proporciona el control llamando al método externo creado con Simulinkofreciendo las medidas almacenadas en el objeto protegido para ello. Finalmentealmacena en el objeto protegido del actuador el valor final del Simulink.

• Recoge el dato del objeto protegido del actuador para corregir la actitud del satélite.

En la figura 6.2 se muestra un diagrama explicativo.

Figura 6.2: Diagrama del subsistema ADCS

Los parámetros de configuración del subsistema ADCS:

• Periodos de muestreo: Se asigna a cada grupo de señales los periodos de muestreocorrespondientes.

• Periodo de registro en memoria: Indica el periodo para el almacenamiento de losvalores más relevantes.

• Parámetros de control de los experimentos: NominalAngularVelocity, Nominal-ControllerGain y NominalMagneticFieldDerivative.

6.2. IMPLEMENTACIÓN 34

• Magnetómetros disponibles: array que indica el estado de los magnetómetros, siestán operativos o no.

Además, el ADCS debe generar eventos y errores cuando detecte las siguientes cir-cunstancias:

• Error en la inicialización de los magnetopares o magnetómetros.

• Valores fuera del rango de los sensores que proceden de los magnetómetros o mag-netopares.

• Errores en sensores.

6.2 ImplementaciónComo en los otros subsistemas, la estructura del ADCS en Ada se divide en la parte pasivay parte activa, por lo que existen dos ficheros: adcs-core y adcs-hlinterface.

Por otro lado, el algoritmo de control que decide como debe variar la intensidad delos magnetopares, se desarrolló en Simulink.

La lógica de la lectura de los sensores, el algoritmo de control y actuación de losmagnetopares se ha desarrollado previamente por el grupo STRAST, por lo que la alumnasólo debe implementar la lógica de la generación de eventos y errores en el subsistema.

Para conseguirlo, se han imitado los eventos y errores implementados en la Platafor-ma, manteniendo la misma estructura del registro del BasicTypes.ads.

Capítulo 7

Resultados y Conclusiones

A lo largo de la integración de los subsistemas, la alumna ha ido realizando una serie deejecutables que iban demostrando el adecuado funcionamiento entre ellos.

En primer lugar, se realizó uno que probara el funcionamiento básico de la Plataforma,de manera que guardara los parámetros de configuración en el Storage y comprobara quelos valores que provenían del stub del HWAccess cumplían las condiciones impuestas porlos parámetros.

Posteriormente, al añadirse el desarrollo del Manager y los correspondientes eventosen la Plataforma, se creó otro ejecutable que generaba el evento SeparationTimerExpi-red, simulando la separación del lanzamiento. Además, se generaban eventos de bateríabaja y crítica, de cambios de modo, pérdidas de comunicación e inicios y abortos de ex-perimentos para comprobar la gestión de eventos y los cambios de modo en función deéstos.

Por último, con la integración del subsistema ADCS al proyecto, se ha comprobado lainteroperabilidad entre los tres subsistemas y el funcionamiento exitoso de todos.

Partiendo de estos resultados se concluye:

El proyecto UPMSat-2 está avanzando de manera exitosa y supone una buena opor-tunidad para los grupos de investigación de la Universidad Politécnica de Madrid. Inves-tigadores de distintas escuelas, entre las que destaca el grupo STRAST, colaboran paralograr la elaboración del microsatélite.

A lo largo del documento, se han presentado las principales características del UPMSat-2. El diseño se ha realizado siguiendo los requisitos de alta integridad y tiempo real, y sehan implementado las funciones de los subsistemas con Ada 2005, lenguaje apropiadopara este tipo de misiones.

El trabajo se ha centrado en la integración de los subsistemas Manager, Plataformay ADCS, implementados parcialmente por miembros del grupo STRAST, por lo que haconstituído una línea de trabajo más en el desarrollo del software del microsatélite.

35

36

El proyecto ha aportado experiencia grupal para la alumna gracias a las reuniones se-manales que se tuvieron. Cada miembro exponía las dificultades con las que se encontrabay se anunciaban las novedades del proyecto.

Ha comprendido el funcionamiento y la complejidad del satélite. Para ello, ha apren-dido la importancia de la ESA como reguladora de los proyectos aeroespaciales. Además,ha comprendido que la estandarización es clave para cubrir todas las necesidades de unproyecto tan complejo. Previamente tuvo que documentarse sobre el funcionamiento delUPMSat-2 y los subsistemas que lo componen a través de los documentos donde se deta-llan las especificaciones del proyecto (SRS y SSS). Tuvo también que entender el códigorealizado de los subsistemas ya implementados para proceder a la integración de los mis-mos.

Por otro lado, cabe destacar que ninguna de las herramientas del proyecto eran co-nocidas por la alumna y ha debido aprender a usarlas durante su elaboración. Aunque,gracias a la formación en otros lenguajes de programación adquirida durante el grado coneste trabajo se completa, ha resultado asequible su aprendizaje.

Actualmente, ya existe una versión operativa de estos subsistemas que demuestra lainteroperabilidad entre éstos, por lo que, se puede concluir que los objetivos propuestosal principio del trabajo han sido cumplidos.

Finalmente, se ha dejado para trabajo futuro el proceso de integración del resto desubsistemas. Asimismo y tratándose de una línea de trabajo que opera en paralelo con losotros subsistemas de los que se compone el segmento de vuelo, se definirán y ejecutaránen las próximas etapas las pruebas de integración y a nivel de sistema.

Bibliografía

[1] STRAST, Software System Specification UPMSat2.http://www.dit.upm.es/~str/proyectos/upmsat2/documentacion/UPMSat2-SSS-2.2.pdf

[2] STRAST, Software Requirements Specification UPMSat2.http://www.dit.upm.es/~str/proyectos/upmsat2/documentacion/UPMSat2-SRS-1.2.pdf

[3] STRAST, Software Design Document UPMSat2.

[4] ESA, ECSS-E-ST-40C Space Engineering Software.http://www.dit.upm.es/~str/proyectos/upmsat2/documentacion/ECSS-E-ST-40C.pdf

[5] ESA, ECSS-Q-ST-80C Space Product Assurance: Software Product Assurance.http://www.dit.upm.es/~str/proyectos/upmsat2/documentacion/ECSS-Q-ST-80C.pdf

[6] ESA, ECSS-E-HB-40A Space Engineering: Software Engineering Handbook.http://www.dit.upm.es/~str/proyectos/upmsat2/documentacion/ECSS-E-HB-40A.pdf

[7] ESA, ECSS-Q-HB-80-03A Space Product Assurance: Software Dependability andSafety.www.dit.upm.es/~str/proyectos/upmsat2/documentacion/ECSS-Q-HB-80-03.pdf

[8] John Barnes, Programming in Ada 2005. Addison Wesley, Massachusetts, 2nd edi-tion, 2005.

[9] John Barnes, Ada 2005 Language Reference Manual and Rationale. Springer, 2005edition, 2005.

[10] ESA, Guide for the use of the Ada programming language in high integrity systems.http://www.dit.upm.es/~str/proyectos/upmsat2/documentacion/ISO_IEC_TR_15942_2000(E).pdf

[11] ESA, Guide for the use of the Ada Ravenscar Profile in high integrity systems.http://www.dit.upm.es/~str/proyectos/upmsat2/documentacion/YCS-2003-348.pdf

37

BIBLIOGRAFÍA 38

[12] Jorge Garrido Balaguer, Trabajo Fin de Máster. Diseño de la ar-quitectura software del sistema de abordo del satélite UPMSat-2.www.dit.upm.es/~str/proyectos/upmsat2/doc/TFM_JorgeGarrido.pdf

[13] Gonzalo Pérez-Tomé Estévez, End-of-degree-project. UPMSat-2 satellite’s Ma-nager software subsistem: Design, validation, implementation and verification.http://www.dit.upm.es/~str/proyectos/upmsat2/doc/TFG_Gonzalo_Perez-Tome.pdf

[14] Víctor Tomás Pérez, End-of-degree-project. UPMSat-2 satellite’s Platform Ma-nagement software subsistem: Design, validation, implementation and verification.http://www.dit.upm.es/~str/proyectos/upmsat2/doc/TFG_Victor_Tomas.pdf

[15] Pablo del Hoyo Rodríguez, Trabajo Fin de Grado. Diseño im-plementación y validación del software del subsistema de de-terminación y control de actitud para el satélite UPMSat-2.http://www.dit.upm.es/~str/proyectos/upmsat2/doc/TFG_Pablo_del_Hoyo.pdf