DESARROLLO DE UNA HERRAMIENTA WEBDE AUTOMATIZACIÓN DE PASES PARA

PEQUEÑOS SATÉLITES

Joel Pérez Pregal

Trabajo de Fin de GradoEscuela de Ingeniería de Telecomunicación

Grado en Ingeniería de Tecnologías de Telecomunicación

TutoresFernando Aguado Agelet

2019

Escola de

Enxeñaría de Telecomunicación

Grao en Enxeñaría de

Tecnoloxías de Telecomunicación

Mención:

Sistemas de Telecomunicación

DESARROLLO DE UNA HERRAMIENTA

WEB DE AUTOMATIZACIÓN DE PASES

PARA PEQUEÑOS SATÉLITES

Autor: Joel Pérez Pregal

Tutor: Fernando Aguado Agelet

Curso: 2018-2019

ÍNDICE

1. INTRODUCCIÓN 1

2. OBJETIVOS 2

3. DESARROLLO 4

3.1 Front-end 4

3.1.1 Creación de tareas 4

3.1.2 Creación de lotes de tareas 6

3.1.3 Visualización de resultados 6

3.2 Back-end 7

3.2.1 Docker 7

3.2.2 Acceso a datos 7

3.2.3 Base de datos 7

3.2.4 Celery 8

3.2.5 Lotes de Tareas 8

3.2.6 Cliente FTP 9

4. RESULTADOS 10

5. CONCLUSIONES 17

6. BIBLIOGRAFÍA 18

ANEXO I: CSP (CUBESAT SPACE PROTOCOL) 19

ANEXO II: ZMQPROXY 21

ANEXO III: DOCKER 22

ANEXO IV: FUNCIONAMIENTO DEL CLIENTE FTP 24

ANEXO V: TRANSFERENCIA DE ARCHIVOS 24

ANEXO VI: DOCKER COMPOSE 26

1

1. INTRODUCCIÓN

Este proyecto surge a raíz del lanzamiento del satélite LUME-I, de la Agrupación Aeroespacial de la Universidad de Vigo, lanzado al espacio el 27 de diciembre de 2018. Los ingenieros responsable s de las comunicaciones con el satélite han desarrollado una serie de herramientas que actualmente utilizan para la comunicación con este, así como el software utilizado, que ha sido desarrollado íntegramente en la UVigo. El estado actual del sistema de comunicaciones, se divide en:

● Space Segment: Consiste principalmente en el satélite en órbita y todas las funcionalidades, sistemas y subsistemas que le rodean, como controles de posición y velocidad, sensores de luz, de horizonte de la tierra, rastreadores de estrellas, propulsores, subsistemas de alimentación eléctricos, baterías o subsistemas termales.

● Ground Segment: Es la parte del sistema de comunicaciones que se encuentra en tierra. Está compuesto, además de por los subsistemas de adquisición mediante antenas y transpondedores, por lo siguiente:

○ Mission Control Server: En esta parte se encuentra toda la parte de servidores. Esta parte se compone, por un lado, de un router (ZMQProxy [1]), que se encarga de dar conexión y realizar las labores de enrutado entre el sistema con el que interactúa el usuario y el satélite. Por otra parte, aparecería la parte de servidores, en la cual se encuentran el Web Server, que será el encargado de provisionar la web que maneja el usuario para interactuar con el satélite); el GS Server, que utiliza el estándar PUS (Packet Utilisation Standard) de la CCSDS (Consultative Committee for Space Data Systems), que es un estándar que se extiende desde las aplicaciones a bordo, pasando por los sistemas en tierra, hasta los usuarios finales, cuya finalidad es que los servicios sean independientes del transporte y de la tecnología de codificación, así como provisionar una capa de abstracción de mensajes, llamada MAL (Message Abstraction Layer) para garantizar que el diseño sirva para ser utilizado en tierra, a bordo, y a través del enlace espacial. Es el subsistema en el cual el usuario puede monitorizar e interactuar con el satélite. La web utilizada para estas labores recibe el nombre de GS-Web.

○ User Segment: Esta sería la parte que utilizarían los usuarios a los que se destinan las funcionalidades finales del satélite. Para el caso del satélite LUME-I, cuyas funciones finales están destinadas a la detección de incendios. Un ejemplo de usuario final sería el cuerpo de bomberos.

Una parte importante de los datos del satélite son aquellos que se deben manejar mediante el protocolo FTP

(File Transfer Protocol), ya que se utiliza para la descarga de datos científicos de las payloads, como

paquetes ADS-B (Automatic Dependent Surveillance-Broadcast) utilizados para determinar la ubicación de

aviones comerciales, o datos de sensores contra incendios, entre otros. No obstante, a causa de la falta de una

herramienta dentro de la GS-Web que permita lanzar procesos FTP de forma automatizada, surge el

problema de que todos estos procesos actualmente requieran ser lanzados a mano desde la terminal de un

ordenador, conectándose directamente al ZMQProxy, de modo que se requeriría que una persona los lance a

mano durante cada pase del satélite, accesible varias veces al día (entre 3 y 4 pases) desde la estación en la

escuela durante unos 10-12 minutos por cada pase. Esto implica, además de la necesidad de tener un recurso

cada día ejecutando los comandos, una menor eficiencia a la hora de aprovechar al máximo el tiempo

disponible para realizar los procesos necesarios.

2

Figura 1: Esquema actual del sistema de comunicaciones con el satélite

En este trabajo se desarrollará una herramienta que permita realizar en cualquier momento la planificación de

tareas a realizar que requieran procesos FTP y se encargue de lanzar la ejecución de dichas tareas en el

momento oportuno, sin los retardos en tiempo que conllevaría lanzar los comandos a mano por una persona,

ya que estos se realizarían totalmente de manera automatizada.

2. OBJETIVOS

El principal objetivo de este trabajo es desarrollar una herramienta con la que sea posible abordar el

problema de automatización de operaciones FTP. De esta forma, se podrán realizar tareas como descarga,

subida de archivos o listado de ficheros de forma autónoma, con simplemente crear una tarea en la que se

definan los parámetros de operación y la hora de ejecución.

Además de esto, se pretende también realizar una aplicación en Django, un framework de alto nivel de

Python Web, gratuito y de código abierto, el cual se encarga de gran parte de las molestias del desarrollo

Web y permite centrarse en escribir la aplicación, fomentando un desarrollo rápido y un diseño limpio y

pragmático, con el objetivo de desarrollar una interfaz web que pueda ser integrada en la GS-Web para

permitir el manejo de la herramienta desde la misma.

A esta aplicación en Django se le integraría Celery [2], una aplicación que nos permite crear tareas de trabajo

asíncronas gestionadas por un gestor de colas que está basada en el envío de mensajes de manera distribuida.

Celery soporta calendarización de tareas, lo que resultará útil para programar la ejecución de las tareas.

3

A través del ZMQProxy se podría interconectar y comunicar entre sí diferentes procesos (cada uno de los

cuales tiene asignada una dirección), que podrían estar corriendo en diferentes máquinas y conectados a

través de internet, de forma que a través de él se podría establecer la conexión con el satélite.

Figura 2: Esquema del sistema de comunicaciones con el satélite con la herramienta a desarrollar

Una vez dicha conexión ha sido establecida y está garantizada la comunicación fiable, gracias a un protocolo

llamado RDP (Reliable Datagram Protocol), el cliente tendrá la posibilidad de manejar los archivos presentes

en el ordenador del nanosatélite (cubesat en la Figura 2). Así el cliente podrá descargar archivos del satélite,

subir archivos desde el cliente a dicho satélite, o listar los archivos y carpetas presentes en él.

Figura 3: Pasos para la ejecución de una tarea

Todas estas funcionalidades pretenden ser ejecutadas dentro de un entorno Docker. El hecho de utilizar Docker permite visualizar la aplicación como un servicio, aislando cada parte de esta dentro de un container y evitando las complicaciones que supondría integrarla dentro una máquina virtual, además de facilitar el despliegue de la misma.

4

3. DESARROLLO

3.1 Front-end

3.1.1 Creación de tareas

En primer lugar, lo que se ha hecho es desarrollar una interfaz web en Django [3][4] que permita

crear una tarea de las mencionadas en el apartado anterior, o ver las tareas que han sido previamente creadas.

A esta aplicación, se podrá acceder desde la GS-Web seleccionando la opción Tasks en el desplegable de la

izquierda de la Figura 4.

Figura 4. Estado anterior y actual de la GS-Web

Previamente a la creación de una tarea, se deben definir una serie de ajustes genéricos que serán comunes

siempre que se cree una tarea (Figura 5).

Figura 5. Formulario para establecer ajustes genéricos

Cuando se selecciona la creación de una tarea, la aplicación de Django redirigirá al usuario a un formulario

para crear la tarea (Figura 6). En este formulario se deben indicar la dirección origen (es decir, la dirección

local entre 1 y 31) y la dirección destino (la dirección del ordenador del satélite sobre el cual se quiere

realizar la operación indicada, también entre 1 y 31). También se debe indicar la dirección del proxy ZMQ

(para la prueba en el entorno local el proxy estaría ejecutándose en el “localhost”, pero en el uso real se

utilizaría la dirección IP que tiene el ZMQProxy).

5

En el campo Path of satellite se indicarían las rutas del ordenador del satélite en las que se encuentran, bien

los archivos a descargar, o bien las carpetas en las que se quiere subir un archivo o listar su contenido. Por su

parte, en el Local Path se indicará la ruta del ordenador local del archivo a subir o de la carpeta en la que se

guardaría un archivo descargado, utilizando como ruta raíz la ruta indicada en los ajustes genéricos e

incluyendo en esta ruta el nombre que se le daría al archivo en el ordenador local. Lógicamente, para un “ls”,

sólo sería necesario el Path of satellite.

Figura 6. Ejemplo de formulario de creación de tarea

Si se marcase la casilla Schedule significaría que la tarea indicada se debe ejecutar en una fecha y hora

programadas, lo que redirigirá al usuario a un nuevo formulario (Figura 7) en el que indicaría la fecha y hora

deseadas para la ejecución del proceso. En caso de no marcarla, la acción se ejecutría inmediatamente.

Figura 7. Formulario para programar fecha de ejecución

En el campo Retry se selecciona la opción de indicar la política de reintentos a seguir, es decir, como

proceder en caso de un fallo en la ejecución. Se puede elegir entre no reintentar la ejecución (en este caso se

reportaría como resultado de la tarea el error), reintentarlo con un número máximo de reintentos o

reintentarlo hasta una hora determinada. En estos dos últimos casos, se redirige a un formulario para indicar,

6

dependiendo del caso, el número máximo de reintentos o la fecha y hora hasta la que estaría reintentando la

acción.

Figura 8. Formulario para reintentos con número máximo de reintentos

Por último, se decide cómo visualizar el resultado. Se puede elegir entre visualizar el proceso entero de transferencia del archivo (en caso de subida o descarga) o los archivos contenidos en la carpeta en caso de listar, o bien mostrar solamente si la ejecución se ha realizado con éxito o ha fallado.

3.1.2 Creación de lotes de tareas

La creación de tareas que se ejecuten de forma autónoma supone una gran ayuda para evitar la necesidad de un control humano. No obstante, en muchos casos la realización de alguna de las tareas programadas puede resultar fallida por diversos factores (pérdida de conexión con el satélite, timeout, pérdida del archivo, etc.). Dependiendo de la ejecución exitosa o fallida del proceso anterior, puede no tener sentido realizar alguna de las tareas posteriores. Por lo cual también resultará útil el hecho de poder generar lotes de tareas, en los cuales se definen una serie de tareas por lote, programando solamente la hora de la tarea inicial y ejecutando las siguientes consecutivamente si se ha realizado la anterior tarea del lote de forma exitosa, o parando la ejecución del lote en el momento que se detecta una ejecución errónea. De este modo se evita, por ejemplo, que si la subida de un archivo al satélite se realiza de forma errónea, se ejecute una tarea posterior de descarga de ese archivo que previamente ha fallado al ser subido.

3.1.3 Visualización de resultados

Si el usuario selecciona la opción de ver tareas, podrá ver un listado de todas las tareas creadas (realizadas o pendientes). Si selecciona ver detalles, la interfaz accederá a la base de datos mediante el identificador de la tarea y recuperará de ella los datos de hora de realización, ruta del satélite, ruta local, dirección origen y dirección destino, y se los mostrará al usuario en la interfaz web por medio de un html. En dicho html se le ofrecerá al usuario la opción de ver el estado de la tarea, de editar la tarea o de eliminarla. Si selecciona la opción mencionada, la interfaz accederá a la base de datos para recuperar el resultado de la ejecución de dicha tarea, junto con el estado SUCCESS, en caso de que esta haya sido ejecutada. Si es así, el resultado puede ser PROCESS OK (si se ejecutó con éxito) o FAILURE (si se produjo algún error), y tras ello, si se ha seleccionado la opción de ver resultado completo al crear la tarea, el proceso de cómo ha sido la transferencia en una descarga o subida, o el listado de los archivos y carpetas presentes en la ruta en el caso de listar. Para el caso de que no haya sido ejecutada, se mostrará el estado como PENDING, si todavía no se ha realizado, o como NOT VALID FIELDS, en caso de que se haya detectado algún error en los campos del formulario cubiertos, y el campo de resultado vacío.

7

3.2 Back-end

3.2.1 Docker

Como se ha comentado previamente, todos los diferentes servicios de la aplicación van a estar corriendo dentro de un entorno Docker, de tal forma que cada proceso va a ser ejecutado de forma aislada dentro de un contenedor. Docker es una herramienta que puede empaquetar una aplicación y sus dependencias en un contenedor virtual que se puede ejecutar en cualquier servidor Linux. Esto ayuda a permitir la flexibilidad y portabilidad respecto a donde la aplicación se puede ejecutar, Mediante el uso de contenedores, los recursos pueden ser aislados, los servicios restringidos, y se otorga a los procesos la capacidad de tener una visión casi completamente privada del sistema operativo con su propio identificador de espacio de proceso, la estructura del sistema de archivos, y las interfaces de red. Contenedores múltiples comparten el mismo núcleo, pero cada contenedor puede ser restringido a utilizar solo una cantidad definida de recursos.

Figura 9. Esquema del funcionamiento de la herramienta

3.2.2 Acceso a datos

Una vez creada y validada la tarea en el formulario, esta será almacenada en un modelo de Django. Un modelo es una clase que representa una tabla o colección en la base de datos y donde cada atributo de la clase es un campo de la tabla o colección.

3.2.3 Base de datos

Una vez creado el modelo, Python lo enviará a una base de datos de postgreSQL [5] (sería el tipo de base de datos en el caso de uso real, aunque en pruebas en entorno local se ha utilizado también una base de datos SQLite [6]). En dicha base de datos se guardarían las tareas con sus identificadores y con todos los campos, incluidas sus horas de ejecución, direcciones, rutas, políticas de reintentos y campos relacionados con el resultado (evidentemente, antes de la ejecución estos campos estarían vacíos).

8

3.2.4 Celery

Dicha base de datos estaría integrada con Celery, una aplicación que permite crear tareas de trabajo asíncronas gestionadas por un gestor de colas llamado worker, basado en el envío de mensajes de manera distribuida. El worker de Celery es el que se encargaría de ejecutar las tareas, ya sean al momento si no es una tarea programada, o a la hora indicada si sí lo es.

En caso de que sea una tarea programada, se utilizará Celery Beat [7], un “scheduler” al que se envían las tareas en cuanto se crean y que se encarga de enviar, a la hora determinada en el formulario, una orden al worker de Celery para que ejecute la tarea. El motivo de emplear Celery Beat, en lugar de otras formas de implementación de tareas programadas, es la gran precisión para realizar la ejecución, ya que no incorpora apenas retardo, a diferencia de otros métodos que pueden llegar a incorporar hasta un minuto de retardo dependiendo de los workers disponibles. Es necesario recordar que el tiempo de pase del satélite es aproximadamente de 12 minutos por pase, por lo que es fundamental utilizar un sistema con la mayor precisión posible para poder realizar el mayor número de operaciones en ese tiempo. Para integrarlo en Django se ha utilizado la librería django_celery_beat [8]. Cuando llegue el momento de la ejecución y Celery Beat envíe la tarea al worker, este envía la orden al cliente FTP de realizar la petición al satélite. La forma de enviar la orden desde Celery es mediante un subprocess [9], un módulo de Python que permite lanzar aplicaciones desde dentro del programa Python, de la misma forma que se haría ejecutándolas desde un terminal. Mediante este subprocess se envía un comando que ejecuta el cliente ftp dentro de un entorno docker, enviando como argumentos la tarea a realizar, las direcciones y rutas de destino y remotas, y el modo de visualización con el que el cliente devolverá en un determinado formato el resultado de la ejecución. En último lugar, en lo respectivo a Celery, se utiliza la librería django-celery-monitor [10]. Esta librería nos habilita la opción de acceder en tiempo real al estado de las tareas y los workers. Así sería posible recuperar el resultado de la ejecución de una tarea programada en el momento en el que se selecciona la opción de visualizar el resultado de una tarea, guardando en ese momento el resultado en la base de datos.

3.2.5 Lotes de Tareas

Para la implementación de los lotes de tareas ha sido necesario modificar el escenario con respecto al esquema de funcionamiento de la herramienta. Esto es debido a que la necesidad de chequear el resultado de una tarea y lanzar la siguiente al momento en caso de que la primera haya sido exitosa, no es factible con el primer escenario. A pesar de que para una tarea no programada sí podría serlo, no lo sería para el caso de una tarea programada, ya que el uso de django-celery-monitor solo accedería al resultado en el momento en el que se selecciona la opción de visualizar el resultado, pero no lo hace ni durante ni justo después de la finalización de la tarea.

Donde sí se puede chequear el resultado de la ejecución es desde dentro del worker de Celery. Pero si se hiciese desde dentro del worker que se encarga de la ejecución de la tarea, aparecería otra problemática: el worker que ejecuta las tareas se encuentra en una red (la del Ground Segment, la cual tendría conexión con el satélite mediante el ZMQProxy) diferente a la del servidor donde estaría el servicio (aplicación de Django, base de datos y Celery), que sería la red del Mission Control Server. Esto implica que desde el worker del Ground Segment no se puede acceder a la base de datos (en el Mission Control Server), ya que con el único elemento de esta otra red con el que podría interactuar es con Celery. El hecho de poder acceder a la base de datos desde el worker resultaría muy útil a la hora de ejecutar lotes de tareas, ya que no sería necesario salir del worker para pasar a la ejecución de la siguiente tarea. En este punto, lo que se ha hecho es utilizar dos workers: uno en el Mission Control Server, que actuará de distribuidor y accederá a la base de datos para obtener todas las tareas del lote, y el worker del Ground Segment, que se encargará de lanzar los comandos de ejecución (el cliente FTP) para interactuar con el satélite a través del ZMQProxy. De este modo, en el momento en que se crea un lote de tareas, esta s erá enviada al worker distribuidor (al momento en caso de una tarea no programada, o a la hora programada a

9

través de Celery Beat en caso de sí serlo). El worker distribuidor, a través de Celery, enviará esa tarea al worker del Ground Segment, que será el encargado de lanzar la tarea a través del ZMQProxy. En el momento que el worker distribuidor, a través de Celery, detecta que se ha producido un evento en el otro worker, recuperará el resultado de la tarea, accederá a la base de datos para guardar el resu ltado de la tarea ejecutada y obtener las siguientes tareas del lote, comprobará si el resultado de la ejecución ha sido exitoso y, en caso de serlo, enviará la siguiente tarea del lote al worker del Ground Segment, mientras que en caso de haber sido fallido parará la ejecución. Este proceso se repetirá hasta llegar a la última tarea del lote.

Figura 10. Esquema del funcionamiento de la herramienta para el caso de lotes de tareas

3.2.6 Cliente FTP

Cuando el Cliente FTP recibe la orden de ejecución, establecerá la comunicación con el ordenador del satélite con la dirección indicada y comenzará a realizar la operación seleccionada. Todo este tráfico, tanto de ida como de vuelta, irá a través del ZMQProxy, que se encargará de realizar las tareas de routing entre el cliente y el satélite. Si la tarea se ejecuta correctamente, el identificador de dicha ejecución y su resultado se guardará en la base de datos. Por el contrario, Celery siempre comprobará antes de almacenar dicho resultado si se ha producido algún error, de forma que si esto es así, reintentará la ejecución al momento en caso de que alguna de las opciones de reintentar haya sido seleccionada, hasta el máximo número de reintentos o la hora límite dependiendo del caso y, llegado este momento, almacenará en la base de datos el identificador de la ejecución y, como resultado, el error producido en caso de haberse continuado

produciendo, o el de la ejecución realizada correctamente en caso de haberse solventado.

10

4. RESULTADOS

Para comprobar el correcto funcionamiento de la herramienta se utiliza un entorno dockerizado que

simulará el sistema de comunicaciones con el satélite, con la única diferencia de que en lugar de utilizar el

satélite real, se simulará un entorno tal como el que estaría corriendo en el ordenador del satélite, solo que

este se conectaría con el ZMQProxy directamente, omitiendo las partes de la adquisición mediante antenas y

del ZMQBridge (Figura 1). Para demostrar el correcto funcionamiento de la aplicación, estas dos partes del

sistema de comunicaciones serían transparentes, ya que el protocolo RDP gestiona la comunicación y se

encarga de hacer el sistema transparente a retardos, reintentos, etc.

Figura 11. Escenario real y de simulación

Se va a realizar la creación en la herramienta de 4 tipos de tarea:

1. Tarea de descarga sin programar (a realizar en el momento de la creación)

En primer lugar, se selecciona en la herramienta la opción de Create Task

Figura 12. Menú principal

Esto redirigirá a un formulario en el que se deben indicar los campos de la Figura 6. Se debe seleccionar una

tarea del tipo download en el campo Type of task. Dicha descarga se efectuará desde la dirección del satélite

(Direction of satellite, en este ejemplo es la dirección 3) y se almacenará en un nuevo fichero (llamado

new_script) que estará en la dirección 10 (el campo Local direction). Para este caso se ha indicado que no se

produzcan reintentos (Not retry), por lo que en caso de fallar no se reintentaría, y que el tipo de visualización

sea Result with data, lo que mostrará si la tarea se ha ejecutado correctamente o ha fallado, y en caso de

haberse ejecutado con éxito, cómo ha sido la transferencia del archivo. En este caso, al no haber activado el

11

campo Schedule, la tarea va a ser ejecutada en el mismo momento de su creación. En las siguientes

imágenes, se puede observar cómo instantáneamente el worker de Celery se encarga de ejecutar la tarea, y

como esta es descargada desde el ordenador del satélite con dirección 3, pasando por el ZMQProxy que se

encuentra en la dirección indicada (en este caso, sería localhost).

Figura 13. Ejecución de la tarea desde el worker de Celery

Figura 14. Descarga del archivo desde el terminal del satélite con dirección 3 a través del zmqproxy con

dirección localhost

Al guardar la tarea, se volverá a mostrar el menú principal. Si en él se selecciona la opción de Ver Tareas, se

mostrará un listado de todas las tareas creadas con sus fechas y horas de ejecución.

Figura 15. Vista de la lista de tareas creadas

La tarea creada sería la última de la imagen. La opción de ver detalles mostrará lo siguiente:

12

Figura 16. Vista de detalles de una tarea

Aquí, además de poder ver el estado actual de la tarea (View state), también se puede editar la tarea creada o

eliminarla. Al seleccionar la opción de ver estado, se mostrará si la tarea está pendiente de realizar

(Pending), si ha sido realizada, haya fallado o no (Success), o si alguno de los campos introducidos no fuese

válido (Not valid fields).

Figura 17. Vista de estado de una tarea de descarga con visualización de resultado con datos

Como se puede observar, indica que la tarea ha sido realizada y muestra cómo ha sido transferencia del

archivo, tal y como le había sido indicado al crear la tarea.

2. Tarea de subida de un archivo programada para una determinada hora

Al igual que en el anterior ejemplo, se va a crear una tarea en este caso de subida, con lo que se

selecciona upload en el campo Type of task, y cómo será programada para una determinada hora, se debe

marcar la casilla de Schedule. Además, en este caso se va a indicar que realice la subida del archivo la ruta

/data/ftp/ftp_client/new_waf del ordenador del cubesat con dirección 6. También se indica que en el modo

de visualización se quiere visualizar solamente el resultado final (esto mostrará únicamente Process OK en

caso de que la transferencia se haya realizado correctamente, o FAILURE en caso de que se haya producido

algún error).

13

Figura 18. Formulario para crear una tarea de upload programada

Al haber seleccionado la casilla Schedule se redirigirá a un nuevo formulario para seleccionar la hora y fecha

en la que se debe realizar la ejecución.

Figura 19. Selección de la hora de programación de la tarea

Es necesario remarcar que, para evitar problemas en cuanto a cambios horarios y zonas horarias, la hora de

ejecución se debe indicar en formato UTC.

En el momento en que se crea la tarea con la fecha y hora programadas, esta se envía instantáneamente a

Celery Beat, que será el encargado de enviarla al worker de Celery cuando llegue el momento de la

ejecución.

Figura 20. Recepción del Schedule en Celery Beat

Mientras la tarea no sea ejecutada, el estado de esta al acceder a la opción de ver estado (View State) de la

tarea aparecería como Pending.

14

Figura 21. Estado de una tarea programada que todavía no se ha ejecutado

Celery Beat tiene una precisión máxima de minutos, por lo cual cuando la fecha, hora y minuto coincidan

con los de la fecha y hora programadas, Celery Beat envía al worker la orden de ejecución. El worker de

Celery hará entonces un sleep durante los segundos indicados para llevar la precisión de la ejecución hasta

los segundos.

Figura 22. Ejecución de la tarea programada en Celery

Como se puede apreciar, devuelve el resultado en el segundo 26 de la hora indicada (se había indicado que se

realizase a los 23 segundos), debido a que la transferencia del archivo ha durado aproximadamente unos 3

segundos.

Si se selecciona entonces la opción de Ver estado nuevamente, nos aparecerá el resultado de la ejecución

junto con el estado Success.

Figura 23. Resultado de la ejecución de una tarea de subida de archivo con visualización del resultado final

Como se observa, en el resultado solo aparecería el certificado CRC (que nos certifica que el archivo

transferido coincide con el recibido) y Process OK.

3. Tarea de listado de un fichero inexistente programada y con reintentos de ejecución hasta una

determinada hora

En este caso, se va a crear una tarea para listar el contenido de un fichero que no existe en el

ordenador del satélite, para así comprobar cómo actuaría la herramienta en caso de detectar un error al

realizar la ejecución de la tarea.

En primer lugar, en el formulario de la Figura 6, se debe crear un tarea de listado (ls en Type of task). En

este caso, solo será necesario indicar la ruta del ordenador del satélite (Local Path). Para este caso, la ruta

15

indicada (/data/ftp/ftp_client/fichero_inexistente) no existirá, por lo cual debería producirse un error al

ejecutar la tarea. En el campo Retry se va a indicar que, en caso de fallar, se desea que la ejecución se

reintente constantemente hasta llegar una hora determinada. Además, se marcará el campo Schedule para

programar la tarea para un determinado momento.

Al guardar dicha tarea, primero se pedirá la fecha y hora hasta la que se debe reintentar la ejecución en caso

de fallo y posteriormente la hora a la que se debe ejecutar.

Figura 24. Programación de la hora máxima de reintentos y de planificación

De esta forma, la tarea comenzaría a ejecutarse a las 17:18:05 y se reintentaría contantemente hasta las

17:18:35.

Observando la ejecución en el worker de Celery, se ve como se reintenta la ejecución acorde a lo esperado.

Figura 25. Reintentos de ejecución fallida en el worker de Celery

El estado de la tarea se mantendría en Pending mientras se producen los reintentos de ejecución, y una vez

llegada la hora máxima de reintentos, se mostrará como Success y como resultado se muestra el error

detectado.

Figura 26. Resultado de una tarea de listado fallida

16

De esta forma, se tiene la seguridad de que, si durante la ejecución de la tarea hay un problema momentáneo

de conexión o una situación similar, se pueda reintentar la ejecución hasta una determinada hora para tener

así la posibilidad de obtener una ejecución exitosa si el problema se solventase durante esa franja de tiempo.

4. Creación de un lote de tareas

Si se selecciona la opción de generar lotes de tareas (Create Batch of Tasks), se podrán generar

planificaciones para cada pase. Lo que se consigue así es generar grupos de tareas, programados para la hora

a la que se produzca el pase, en los que la ejecución de las tareas dependerá de que la anterior se haya

realizado o no correctamente. En este caso, se generará un lote de tareas que contendrá la subida de un

archivo a una ruta del ordenador del satélite, el listado de dicha ruta y la descarga del archivo subido en la

primera tarea del lote.

Al seleccionar la opción de generar lote de tareas, esta redirigirá a un formulario en el que se irán cubriendo

las tareas de las que consta el lote. La única que da la opción de ser programada es la primera, puesto que el

resto se ejecutarán consecutivamente.

Figura 27. Creación de un lote de tareas

En el momento de la ejecución, la tarea será enviada a el worker distribuidor (que se encuentra en el Mission Control Server y, por tanto, tiene acceso a la base de datos), y será el que envíe la primera tarea al worker que debe ejecutarla (que se encontrará en el Ground Segment). Una vez este la realiza, devolverá el resultado al worker distribuidor, que comprobará el resultado de la misma y, en caso de que haya sido exitosa, accederá a la base de datos para ejecutar la siguiente tarea del lote.

Figura 28. Worker distribuidor Figura 29. Worker ejecutor

17

En la vista de lotes de tareas (View tasks batches) se puede comprobar el resultado de la ejecución del lote.

Figura 30. Vista lotes de tareas

Si se accede a la opción de ver detalles, y después a la de ver resultados, se puede comprobar que, para las tres tareas, la ejecución se ha realizado de forma exitosa.

Figura 31. Resultados de la ejecución de las distintas tareas de un lote

Como se puede observar, la tarea de subida se ha realizado correctamente, por tanto se ha ejecutado la

siguiente (de listado), y como se puede apreciar el archivo subido se encuentra en la ruta indicada. Al

haberse ejecutado con éxito esta, se puede realizar la última tarea del lote, de descarga del archivo subido

inicialmente, que también se produce de manera exitosa. Si alguna de las dos primeras hubiese fallado, no

tendría sentido ejecutar las demás (en el caso de fallo de la primera porque no se habría subido el archivo y,

en el caso de fallo de la segunda, porque no existiría la ruta a listar, por lo que, en caso de haberse realizado

la primera, no lo habría hecho en el directorio deseado). Esto permite generar la planificación entera de un

pase, asegurándose de no realizar tareas no deseadas en caso de fallo.

5. CONCLUSIONES

En función de los resultados obtenidos, se puede observar como el funcionamiento de la herramienta es acorde con lo esperado. Como se demuestra en los ejemplos del apartado anterior, además del objetivo inicial de poder crear tareas que sean ejecutadas de forma autónoma, también se ha implementado la posibilidad de poder generar lotes de tareas. De esta forma, se podrá programar prácticamente en su totalidad, las acciones a realizar durante el pase completo del satélite. Esto permitirá aprovechar al máximo el tiempo de pase del satélite, y realizar el máximo número de tareas posibles en ese tiempo.

Para poder concluir que todo funciona correctamente, se ha simulado un entorno prácticamente similar al del caso real, lo que permite asegurar en gran medida que el funcionamiento de la herramienta a la hora de integrarla en la GS-Web para utilizarla en las comunicaciones con el satélite real tiene una gran probabilidad de resultar exitoso. Las diferencias que podrían aparecer a la hora de integrar esto en el sistema real son mayormente relacionados con problemas que se están dando actualmente en el satélite LUME-I, ya que

18

actualmente están apareciendo problemas a la hora de realizar la subida de archivos mediante FTP, debido a las retransmisiones causadas por tener un canal con bastante interferencia. No obstante, a pesar de que es el protocolo RDP el que garantiza la fiabilidad del canal, el hecho de que la aplicación permita establecer políticas de reintentos, permite aprovechar al máximo el tiempo de pase para tratar de realizar la subida de un archivo de forma exitosa, aún en el supuesto caso de que se den problemas causados por el canal a la hora de realizar la subida. Además, la aplicación estaría abierta a posibles mejoras futuras, como podrían ser, entre otras, las siguientes: -Manejo del orden de las tareas una vez creadas. Esto sería para el caso de los lotes de tareas. Consistiría en que, una vez generado el lote de tareas a ejecutar durante el pase, se ofreciese la posibilidad de modificarlo de tal forma que se pudiese cambiar el orden en que se ejecutan dichas tareas, o añadir tareas a ese lote. -Aprovechar los workers en casos de fallo. En caso de que se produzca un fallo en un worker y este se caiga, automáticamente se detectaría esta caída y se lanzaría un nuevo worker, de tal forma que siempre se tendría el mayor número de workers posibles disponibles y corriendo. -Capacidad de lanzar tareas que se habían ejecutado previamente , sin necesidad de volver a ser creadas.

6. BIBLIOGRAFÍA

[1] Manual para la utilización de la librería ZMQ: http://zeromq.org/intro:read-the-manual

[2] Manual de instalación y configuración de Celery. En página Web oficial de Celery:

http://docs.celeryproject.org/en/master/getting-started/first-steps-with-celery.html#first-steps

[3] Página web del framework de Django: https://www.djangoproject.com/

[4] The Django Book, libro acerca de Django: https://djangobook.com/the-django-book/

[5] Página Web oficial de la base de datos PostgreSQL: https://www.postgresql.org/

[6] Página Web oficial de la base de datos SQLite: https://www.sqlite.org/index.html

[7] Implementación de tareas periódicas con Celery Beat. En página Web oficial de Celery:

http://docs.celeryproject.org/en/latest/userguide/periodic-tasks.html#crontab-schedules

[8] Django Celery Beat, licencia en repositorio git público. https://github.com/celery/django-celery-beat

[9] Uso de subprocess dentro de una aplicación en Python. En API oficial de Python:

https://docs.python.org/2/library/subprocess.html

[10] Django Celery Monitor, licencia en repositorio git público. https://github.com/jezdez/django-celery-

monitor

[11] Cubesat Space Protocol, licencia en repositorio git público: https://github.com/libcsp/libcsp

[12] Tutorial para el uso de containers dentro de Docker, por Eric Goebelbecker, Abril de 2018:

https://stackify.com/docker-tutorial/

[13] Página oficial de Docker: https://docs.docker.com/

[14] Página oficial de Docker Compose: https://docs.docker.com/compose/

19

ANEXO I: CSP (CUBESAT SPACE PROTOCOL)

CSP (Cubesat Space Protocol) [11] es un pequeño protocolo apilado escrito en C. CSP está diseñado para facilitar las comunicaciones entre sistemas empotrados distribuidos en pequeñas redes, tales como Cubesats. El diseño sigue el modelo TCP/IP e incluye un protocolo de transporte, un protocolo de enrutamiento y una gran variedad de interfaces de capas MAC. El núcleo de libcsp incluye un router, un buffer de socket, y una conexión orientada a la API de socket. El protocolo está basado en una cabecera de 32 bits que contiene información tanto de transporte como de la capa de red. Su implementación está diseñada para sistemas empotrados tales como microprocesadores AVR de 8 bits y ARM y AVR de Atmel de 32 bits, pero no está limitada a ellos. La implementación está escrita en GNU C y es actualmente portable a correr en FreeRTOS o sistemas operatios POSIX tales como Linux. La idea es dar a los desarrolladores de sub-sistemas de cubesats algunas características de TCP/IP, pero sin necesidad de la ayuda de la enorme cabecera IP. El pequeño impacto y simple implementación permite a un pequeño sistema de 8 bits con menos de 4kB de RAM estar completamente conectado a la red. Esto permite a todos los subsistemas proporcionar sus servicios en el mismo nivel de red, sin el requerimiento de ningún nodo maestro. Usar una arquitectura de servicios orientados tiene muchas ventajas en comparación con la tradicional topología maestro/esclavi usada en muchos cubesats.

-Protocolo de red estandarizado: Todos los subsistemas pueden comunicarse unos con otros.

-Enganche de pérdidas de servicio: Los servicios mantienen una relación que minimiza las

dependencias entre subsistemas.

-Abstracción de servicios: Más allá de las descripciones en el contrato de servicio, los servicios

ocultan la lógica del mundo exterior.

-Reusabilidad de servicios: La lógica se divide en servicios, con la intención de promover su

reutilización.

-Autonomía de servicios: Los servicios tienen el control sobre la lógica con la que son

encapsulados. -Se reduce el punto único de fallo: La complejidad es movida de un único nodo maestro a varios

servicios en la red bien definidos. La implementación de LibCSP está escrita con la simplicidad en mente, pero es la configuración de tiempo de compilación la que nos permite también tener bastantes características avanzadas.

Características

-API de Socket con hilos seguros.

-Tarea de router con Quality of Services. -Operación de comunicación orientada a conexión (RFC 908 y 1151). -Operación de comunicación sin conexión (similar a UDP). -Peticiones ICMP (Internet Control Message Protocol) como ping y buffer status.

-Interfaz de loopback.

20

-Código de 48kB con impacto muy pequeño y menos de 1kB de RAM requerida en ARM.

-Buffer de copia cero y sistema de gestión de colas.

-Sistema de interfaz de redes modular.

-Interfaz de SO modular, portable a FreeRTOS, Windows (cygwin) y Linux.

-Tráfico broadcast.

-Modo promiscuo (permite capturar todo el tráfico).

-Paquetes encriptados con XTEA en modo CTR.

-Autenticación HMAC-SHA1 truncada (RFC 2104). Licencia LGPL Software

El código fuente está disponible bajo una licencia LGPL 2.1 .

21

ANEXO II: ZMQPROXY

ZeroMQ (también conocido como ØMQ, 0MQ o zmq), es similar a una biblioteca de red incorporable, pero actúa como un marco de concurrencia. Proporciona sockets que transportan mensajes a través de diversos métodos como en proceso, entre procesos, TCP y multicast. Se pueden conectar sockets N a N con patrones como fan-out, pub-sub, distribución de tareas y request-reply. Es lo suficientemente rápido para ser el tejido de productos agrupados. Su modelo es de E/S asíncrono, lo que proporciona aplicaciones de multinúcleo escalables, creadas como tareas asíncronas de procesamiento de mensajes. Tiene una puntuación de lenguaje de idioma y se ejecuta en la mayoría de los sistemas opertivos. ZeroMQ es de iMatix y es de código abierto LGPLv3. ZMQ es una librería para intercambio de mensajes entre procesos distribuidos, que permite diseñar sistemas de comunicaciones complejos sin el excesivo esfuerzo que tendría abrir sockets TCP o UDP en bruto. Es un software gratuito, usado por organizaciones como AT&T, Cisco, EA, NASA, Weta Digital, Zynga, Spotify, Samsung Electronics, Microsoft o CERN (Organización Europea para la Investigación Nuclear). ZMQ crea una API, muy similar la de los sockets, pero que proporciona el estilo de mensajería deseado. Al especificar el tipo de socket (al que se llama zmq_socket), se permite tener multidifusión, solicitud / respuesta, y muchos otros estilos. ZMQProxy es un router que permite interconectar y comunicar entre si diferentes procesos (cada uno de los cuales tiene asignada una dirección), que podrían estar corriendo en diferentes máquinas y conectados a través de internet. Esto permite encaminar paquetes de la misma forma que lo hace IP, es decir, por direcciones/máscaras y mediante saltos.

22

ANEXO III: DOCKER

Todo el software se ejecutará dentro de docker [13]. Docker permite aislar un proceso con todos sus archivos y dependencias necesarios, sin la necesidad de la instalación de una máquina virtual (con la pérdida de rendimiento que ello conllevaría).

CONCEPTOS DE DOCKER

Docker es una plataforma para desarrolladores y administradores de sistemas, para desarrollar, desplegar y ejecutar aplicaciones con containers[14]. El uso de containers de Linux para desplegar aplicaciones se llama containerización. Los containers no son nuevos, pero sus usos para facilitar el despliegue de aplicaciones sí lo son. La containerización es cada vez más popular porque los containers son:

● Flexibles: Incluso las aplicaciones más complejas pueden ser containerizadas. ● Ligero: Los containers nivelan y comparten el kernel del host. ● Intercambiable: Puedes lanzar updates y upgrades “en el aire”. ● Portable: Puedes construirlo localmente, desarrollarlo en la nube, y ejecutarlo en cualquier sitio.

● Escalable: Puedes incrementar y distribuir automáticamente réplicas del container. ● Apilable: Puedes apilar servicios verticalmente y “en el aire”.

IMÁGENES Y CONTAINERS

Un container es lanzado para ejecutar una imagen. Una imagen es un paquete ejecutable que incluye todo lo necesario para ejecutar una aplicación – el código, el tiempo de ejecución, librerías, variables del entorno, y archivos de configuración. Un container es la instancia de ejecución de una imagen – lo que la imagen convierte en memoria cuando es ejecutada (qué es, una imagen con estado, o un proceso de usuario). Se puede ver una lista de los containers corriendo con el comando docker ps , tal y como se haría en Linux.

CONTAINERS Y MÁQUINAS VIRTUALES Un container corre nativamente en Linux y comparte el kernel de la máquina host con otros containers. Corre un proceso de forma discreta, no tomando una cantidad de memoria mayor que cualquier otro ejecutable, haciendo que sea ligero. En contraste, una máquina virtual (VM) corre un sistema operativo “guest” completo, con un acceso virtual a los recursos del host a través de un hypervisor. En general, las máquinas virtuales proporcionan un entorno con más recursos de los que la mayoría de las aplicaciones necesitan.

23

Figura 32. Esquema del entorno de un container de Docker vs Máquina Virtual

FUNCIONAMIENTO DE DOCKER El funcionamiento de Docker se basa en cargar una “imagen” (que sería el archivo que contiene el binario y dependencias necesarias) en un container: una región aislada de el equipo con acceso a los archivos y redes que se le indiquen, para ejecutar dicho binario dentro de ese container. Las imágenes de Docker se generan por compilación, mediante un archivo (Dockerfile) donde se describe qué archivos deben ser copiados dentro de la imagen (container), qué paquetes se deben instalar, y qué comandos se quiere que se ejecuten. El acceso a recursos tales como interfaces de red y unidades de disco se virtualiza dentro de este entorno, el cual está aislado del resto del sistema, por lo que es necesario “mapear” puertos al mundo exterior, y ser específico sobre qué archivos se quiere que se copien en el entorno. Sin embargo, una vez se define esto, puede esperarse que la construcción de la app definida en el Dockerfile se comporte exactamente como se quiere.

24

ANEXO IV: FUNCIONAMIENTO DEL CLIENTE FTP

En el caso de esta aplicación, al proxy se conecta un proceso (llamado csp-term), con una dirección determinada, y se conectará el cliente, con otra dirección distinta. Una vez se han establecido estas conexiones, se puede comunicar los dos procesos de forma bidireccional y eficiente. Para la comunicación entre procesos, se utiliza otro protocolo de red, llamado CSP. CSP es el protocolo que se utiliza para la comunicación entre subsistemas en los satélites, siendo IP, TCP y ZMQ capas extra que permiten encaminar el tráfico CSP proveniente del satélite hacia los ordenadores en tierra, y viceversa. Cuando se comunican 2 procesos entre ordenadores, TCP garantiza una comunicación fiable, pero en el caso real de uso para comunicaciones con el satélite, donde sólo hay un enlace de radio entre tierra y satélite, junto con CSP es necesario un protocolo extra que garantice el reenvío de paquetes en caso de que este se pierda, que será RDP (Reliable Datagram Protocol), intregrado dentro del propio protocolo CSP. CSP es por tanto una simplificación de IP diseñada para correr en ordenadores poco potentes, como los de un nanosatélite. En último lugar aparece el protocolo FTP (File Transfer Protocol), encargado de la transferencia de archivos, es decir, de fragmentarlos, reconstruirlos, y comprobar que el archivo enviado y recibido son iguales, etc. En el caso de este protocolo, se utiliza también un protocolo extra, llamado RDP (Reliable Datagram Protocol) que se encarga de garantizar la comunicación fiable anteriormente mencionada.

Todo este conjunto de procesos, serán ejecutados dentro de un container d e Docker (Anexo III), lo que proporcionará mayor comodidad. Si se utilizase una máquina virtual, un Hypervisor debería emular toda la parte hardware, con su consiguiente ralentización. Con Docker [4] se comparte la base del sistema entre procesos (el kernel), de forma que cada proceso se ejecuta aislado y dando acceso solamente a lo que el usuario le permita. De esta forma, el entorno de desarrollo sería algo similar a lo que se muestra en la siguiente figura.

Figura 33: Esquema del funcionamiento del cliente FTP

25

ANEXO V: TRANSFERENCIA DE ARCHIVOS

Como se puede ver en el ejemplo de la Figura 34, el cliente primeramente envía una petición de

conexión al terminal CSP. Una vez este la acepta, abre la conexión, la cual intercambiará constantemente

paquetes RDP (ack), para garantizar la fiabilidad de la comunicación. Se comienza entonces la transferencia

del archivo, dividido en paquetes, desde el terminal CSP para el caso de descarga, o desde el cliente FTP

para el caso de subida.

Para el caso de la descarga, el cliente FTP enviará cada cierto tiempo al terminal CSP un reset, con el fin de

que el CSP cierre la conexión cuando termine la transferencia del archivo. Si el terminal CSP recibe un rst y

no ha terminado todavía de transferir el archivo, lo considerará como fuera de secuencia y mantendrá la

comunicación abierta hasta terminar la transferencia.

En el caso de subida, es el propio cliente FTP el que envía el reset una vez ha terminado la transferencia del

archivo, indicando al CSP terminal que ha finalizado y que puede cerrar la conexión.

Por último, si lo que se quiere es listar, únicamente se abriría conexión (del mismo modo que los otros dos

casos), y el terminal CSP enviaría uno a uno el nombre de los archivos que contiene y su peso (cada uno en

un paquete). Una vez finalizado, enviaría el rst al cliente indicando que se ha finalizado, y una vez este

responde se cerraría la conexión.

Figura 34: Proceso de descarga de un archivo del satélite desde el cliente

26

ANEXO VI: DOCKER COMPOSE

Para facilitar la forma en la que el servicio es lanzado, se utiliza la herramienta Docker Compose [14]. Con esta herramienta se pueden definir y ejecutar aplicaciones Docker multicontenedores. Lo que se utiliza es un archivo YAML para configurar los servicios de la aplicación. Luego, con un solo comando, se crean e inician todos los servicios desde su configuración.

Gracias a esta herramienta, se permite que la aplicación sea fácilmente ejecutable, además de portable, ya que todas las dependencias, archivos y paquetes necesarios, se crean dentro de una imagen que posteriormente, mediante Docker Compose, se utiliza para generar cada servicio. Es decir, no es necesario que el usuario instale en su máquina una versión concreta de Celery, Django y demás, ya que todo esto se instalaría en la imagen al ser creada, y estarían disponibles en cada contenedor en el momento que Docker Compose utiliza la imagen para crear el servicio.