ARQUITECTURA DE TIEMPO REAL PARA EL CONTROLDE ACTITUD EN UN SATELITE EXPERIMENTAL⇤

Juan Zamorano, Angel Esquinas, Peter Bradley, Daniel Brosnan,Jorge Garrido, Emilio Salazar, Alejandro Alonso, Juan A. de la Puente

Grupo de Sistemas de Tiempo Real y Arquitectura de Servicios Telematicos (STRAST)Universidad Politecnica de Madrid (UPM)

Resumen

La mision UPMSat-2 tiene por objetivo la cons-truccion y el lanzamiento de un microsatelite ex-perimental que sirva como plataforma de educa-cion e investigacion en diversos aspectos de la in-genierıa de sistemas espaciales. En este artıculose describe la arquitectura y el diseno del softwarede tiempo real que realiza el control de actitud delsatelite. La arquitectura esta basada en modelos, ylas herramientas utilizadas permiten la validacionde las propiedades de tiempo real y la generacionde codigo de forma casi totalmente automatica.

Palabras clave: Sistemas de control por compu-tador, sistemas de tiempo real, diseno de softwarebasado en modelos.

1. INTRODUCCION

UPMSat-2 es un proyecto de la Universidad Po-litecnica de Madrid (UPM) que tiene como ob-jetivo la construccion, puesta en orbita y opera-cion de un satelite experimental que sirva comodemostrador tecnologico y plataforma educativaen el ambito de los sistemas espaciales. El proyec-to esta liderado por el Instituto Ignacio Da Ri-va(IDR/UPM), y se lleva a cabo con la colabora-cion del grupo STRAST/UPM,la empresa TEC-NOBIT,y otros grupos universitarios y empresas.

UPMSat-2 es un microsatelite de unos 50 kg demasa, con una envolvente geometrica de 0, 5 ⇥0, 5 ⇥ 0, 6 m. La orbita prevista es polar he-liosıncrona a unos 600 km de altura. El lanza-miento esta previsto para 2015, y la vida util dela mision se estima en unos dos anos.

El grupo de Sistemas de Tiempo Real y Arquitec-tura de Servicios Telematicos (STRAST) se ocupade desarrollar el software para el computador em-barcado y la estacion de tierra de la mision. Eneste artıculo se describen los aspectos relaciona-dos con el software de tiempo real que efectua el

⇤Trabajo financiado parcialmente por el Plan Na-cional de I+D+I, proyecto TIN2011-28567-C03-01(HI-PARTES).

control de actitud del satelite. En el apartado 2se resumen las principales caracterısticas de la ar-quitectura de hardware y software del computadorembarcado. Los elementos principales del sistemade control de actitud se describen en el aparta-do 3, y el software de tiempo real correspondientese describe en el apartado 4. Por ultimo, el apar-tado 5 resume las principales conclusiones del tra-bajo.

2. COMPUTADOREMBARCADO

El computador embarcado (OBC, on-board com-puter) del satelite realiza las siguientes funciones:

Control de actitud (ADCS, Attitude determi-nation and control);

supervision de la plataforma del satelite (hou-sekeeping);

gestion de mensajes de telemando (TC, tele-command) y telemedida (TM, telemetry);

gestion de los experimentos que constituyenla carga util del satelite.

La figura 1 muestra las interfaces del computadorcon los sensores de que se dispone para realizarestas funciones.

Computador!

actuadores ADCS!•  magnetopares"•  rueda de

inercia"

sensores ADCS!•  magnetómetros"•  células solares"

radio"

sensores plataforma!-  temperatura"-  tensión"-  intensidad"

experimentos"

Figura 1: Diagrama de contexto del computadorembarcado.

XXXIV Jornadas de Automática. Terrassa, 4 al 6 de Septiembre de 2013

780

UART SPI I2C GPIO GPIOUART

RTCCOMMUNICATION Reaction wheel

Interval timersI!Cache D!Cache

SPARC!V8 Scalar and FP Units

Watchdog timer

VoltagesTemperatures

Intensities

Magnetometers

Magnetotorques

Device status Device activations

SwitchesHeaters

RAM EEPROM/FLASH

ADC

UHF link to ground station

Mission elapsed time

FPGA Virtex 5

Figura 2: Computador embarcado.

2.1. ARQUITECTURA DEHARDWARE

El hardware del computador embarcado esta ba-sado en un procesador LEON3 con arquitecturaSPARC v8 [8, 14], con memoria RAM y memoriano volatil tipo EEPROM para almacenar los datosde configuracion y de telemedida para su posteriorenvıo a la estacion de tierra. El computador inclu-ye tambien interfaces de entrada y salida analogi-ca y digital para la interaccion con los sensores,ası como interfaces RS-232 y RS-422 para la radio,las conexiones de depuracion y pruebas, y algunosde los experimentos [4].

La version de ingenierıa de la OBC se ha desa-rrollando a partir de la biblioteca de IP cores enVHDL GRLIB. Esta biblioteca contiene el mode-lo sintetizable del procesador de 32 bits LEON3junto con controladores de buses de sistema AM-BA, controladores de memoria ası como contro-ladores de buses auxiliares y dispositivos periferi-cos. La biblioteca esta disponible en codigo fuenteVHDL y se distribuye con licencia GNU GPL. Porlo tanto, es posible desarrollar (SOC, Systems Ona Chip) para su uso en computadores de a bordocon una adecuada configuracion y sıntesis sobredispositivos programables como FPGAs.

La figura 2 muestra la estructura del computadorembarcado que se ha sintetizado en una FPGA, laversion de ingenierıa del computador usa una tar-jeta de evaluacion ML507 de la FPGA de XilinxVirtex-5 FXT. Esta version de ingenierıa se usapara el desarrollo del software embarcado y sirvede base para la version de vuelo del computadorque contendra chips de memoria y FPGA resisten-tes a la radiacion. El coste de estos componentesy los requisitos de consumo de energıa limitan la

cantidad de memoria disponible a 4 MB de SRAMy 1 MB de EEPROM. Por motivos similares, lavelocidad del procesador LEON3 es de 50 MHz.

2.2. ARQUITECTURA DE SOFTWARE

El software del computador embarcado se ha di-senado siguiendo un enfoque basado en modelos(MDE) [1]. Los distintos subsistemas se modelanen lenguajes de alto nivel como Simulink R� o elperfil MARTE de UML [11, 12]. A partir de losmodelos de alto nivel se genera automaticamenteel codigo fuente en C o Ada utilizando herramien-tas asociadas a los lenguajes de modelado, juntocon otras desarrolladas por el grupo [13].

System model!

Analysis model!

MARTE to MAST!

Neutral model!

MARTEto neutral!

MASTto neutral!

Ada Ravenscarcode generator!

Real-time Ada code!

UML2 MARTE!

Figura 3: Proceso de desarrollo de software.

La figura 3 muestra de forma esquematica el pro-ceso de desarrollo utilizado para el software.

XXXIV Jornadas de Automática. Terrassa, 4 al 6 de Septiembre de 2013

781

El software embarcado tiene requisitos de tiemporeal y se hace necesario la realizacion de un analisisde planificabilidad para verificar que las accionesde los subsistemas se realizan en el momento co-rrecto [6]. Por lo tanto, las herramientas incluyenrestricciones para asegurar que los modelos seancompatibles con el perfil de Ravenscar [3]. El per-fil de Ravenscar se definio como un conjunto derestricciones a la parte concurrente del lenguajede programacion Ada, con el objetivo que la ar-quitectura de software resultante se pueda analizartemporalmente. Aunque el perfil se definio origi-nalmente para el lenguaje Ada, su modelo compu-tacional se puede extrapolar a otros paradigmas deprogramacion concurrente como POSIX. La pla-taforma de ejecucion esta basada en el nucleo detiempo real ORK+ [5], que da soporte al perfilde Ravenscar. Ası que tanto el compilador comoel nucleo de tiempo real realizan comprobacionesdel codigo generado para verificar que se cumplanlas restricciones.

3. CONTROL DE ACTITUD

La actitud del satelite esta representada por laorientacion de los ejes del satelite con respecto aun sistema de referencia local vertical. Esta orien-tacion viene dada por la matriz de transformacionentre ambos sistemas de referencia, construida apartir de los angulos de Euler, �, ✓ y . El obje-tivo del sistema de control de actitud es mante-ner el eje Z del satelite orientado hacia el centrode gravedad de la Tierra, mientras que su eje Yse orienta en una direccion normal al plano de laorbita. El satelite debe girar entorno al eje X conuna velocidad angular de 0, 01 rad/s con el obje-tivo de mantener una temperatura homogenea enlas caras del satelite.

La actitud del satelite se puede determinar a par-tir de las medidas obtenidas por tres magnetome-tros ortogonales, que permiten determinar el valory la direccion del campo magnetico terrestre en elsistema de referencia local del satelite. Para modi-ficar la actitud del satelite se dispone de tres mag-netopares, que generan un momento de rotacional interaccionar con el campo magnetico terrestre.

Para disenar el algoritmo de control se ha simula-do la dinamica del satelite y las fuerzas externasque actuan sobre el mediante un modelo en Simu-link (figura 4).

Las variables del modelo representan los distintosmomentos de fuerzas que actuan sobre el sateli-te, los cuaterniones que representan la actitud delsatelite respecto al sistema de referencia vertical,la matriz de rotacion desde el sistema de ejes delsatelite (CBV ), y los componentes de la velocidad

gravity gradient"torque"

perturbation"torque"

PM dipole"

Earth magnetic

field"

Spacecraft dynamics"

1

1

cross product" 1

controller!1

B_dot"

B_b_T"

T_pm"

T_perturbation"

quaternion"

T_Nm"

I_A"

pqr_rad/s"

omega_rad/s"

C_BV"

T_gg"

Figura 4: Modelo de la dinamica del satelite.

angular (pqr).

El bloque controller representa el algoritmo decontrol, que tiene como entradas las medidas delcampo magnetico proporcionadas por los mag-netometros (BbT ) y sus derivadas en el tiempo(B

dot

). Las salidas del controlador son las intensi-dades que se suministran a los magnetopares (IA)y los pares que ejercen estos (T

Nm

). Los sensoresy actuadores propiamente dichos estan incluidosen el bloque controlador.

Los detalles del algoritmo y su justificacion pue-den verse en el documento [7]. El periodo de mues-treo del algoritmo de control es de un segundo. Laadquisicion de los datos de los magnetometros serealiza mediante el conversor analogico digital delOBC (figura 2) con una resolucion de 12-bits y laactuacion sobre los magnetopares se hace median-te modulacion de ancho de impulso (PWM, PulseWidth Modulation) mediante salidas digitales delOBC.

4. SOFTWARE DE CONTROL

El software del sistema de control de actitud(ADCS) tiene varios componentes, que se repre-sentan en el diagrama MARTE-UML de la figu-ra 5.

El componente AttitudeControl se ejecuta periodi-camente e invoca la funcion ControlAlgorithm, cu-yo codigo fuente en C se genera automaticamentea partir del modelo de simulacion anterior. Losdemas componentes permiten ajustar los parame-tros del controlador, proporcionar medidas al sis-tema de telemetrıa, y ajustar el controlador enfuncion de los cambios de modos del sistema. Estoscomponentes se deben ejecutar concurrentementecon otros subsistemas de software.

El entorno de desarrollo dispone de herramientaspara calcular el peor caso de tiempo de compu-to (WCET, Worst Case Execution Time) [2] de

XXXIV Jornadas de Automática. Terrassa, 4 al 6 de Septiembre de 2013

782

«MutualExclusionResource»

AttitudeControlData

internal_configuration : ModeType

internal_change : Boolean

GetControlParameters ( )

SetControlParameters ( )

SetAttitudeReference ( )

«MutualExclusionResource»

LocalModeManager

internal_mode : ModeType

GetMode ( )

SetMode ( )

WaitModeChage ( )

«interface»

ADCSInterface

SetAttitudeReference ( )

NotifyModeChange ( )

SetControlParameters ( )

«GaWorkloadEvent, SchedulableResource»

AttitudeControl

ControlAlgorithm ( )

Use relation btw interface and

classes wants to me that part of

the interface is realized by the

class. This relation should be

refined, either by including a class

that realizes all operations or by

changing the type of relation

«component»

ADCS

ADCSInterface

SetAttitudeReference ( )

NotifyModeChange ( )

SetControlParameters ( )

«use»«use»

«use»«use»

Figura 5: Estructura del software del sistemaADCS.

las funciones del sistema. Entre estas funcionesesta el control de actitud, los detalles del calcu-lo del WCET pueden verse en el documento [9].Con la arquitectura de software y los WCET delas funciones del sistema se analizan los requisi-tos de tiempo real mediante herramientas especıfi-cas [10].

Una vez comprobado el comportamiento tempo-ral, se genera todo el esqueleto del codigo concu-rrente y de tiempo real en Ada a partir del mode-lo MARTE-UML [13]. La compilacion e implanta-cion en el computador embarcado se realizan deforma inmediata usando la cadena de compilacionGNAT/ORK [15].

5. CONCLUSIONES

El satelite UPMSat-2 (figura 6)es una plataformade gran interes para la experimentacion de nuevastecnicas por parte de los grupos de investigacionde la UPM.

Figura 6: Vista general del satelite UPMSat-2.

En particular, las tecnicas de desarrollo de soft-ware de tiempo real en las que trabaja el grupo

STRAST se han aplicado al diseno del software decontrol del satelite. Los resultados obtenidos hastaahora son satisfactorios, y por tanto esta previstocontinuar con el desarrollo del resto del softwareembarcado utilizando estas mismas tecnicas en losproximos meses.

Agradecimientos

Los autores agradecen la colaboracion del restodel equipo del proyecto UPMSat2, especialmentela ayuda prestada pro Assal Farrahi, Javier Cubasy Angel Sanz.

Referencias

[1] Alejandro Alonso, Emilio Salazar, andJuan A. de la Puente. Design of on-boardsoftware for an experimental satellite. In Jor-nadas de Tiempo Real — JTR-2013, 2103.Available at www.dit.upm.es/

~

str/papers/

pdf/alonso&13a.pdf.

[2] Esteban Asensio, Jorge Lopez, Juan A. de laPuente, and Juan Zamorano. Herramientasde analisis temporal para el desarrollo de sis-temas de tiempo real crıticos. In Proc. CEDI2010, September 2010. (In Spanish). Submit-ted for publication.

[3] Alan Burns, Brian Dobbing, and Tullio Var-danega. Guide for the use of the Ada Ra-venscar profile in high integrity systems. Te-chnical Report YCS-2003-348, University ofYork, 2003.

[4] Juan A. de la Puente, Juan Zamorano, Ale-jandro Alonso, and Daniel Brosnan. Areal-time computer control platform for anexperimental satellite. In Jornadas deTiempo Real — JTR-2012, 2012. Availa-ble at http://www.ctr.unican.es/jtr12/

programme.html.

[5] Juan A. de la Puente, Juan Zamorano,Jose A. Pulido, and Santiago Uruena. TheASSERT Virtual Machine: A predictableplatform for real-time systems. In Myung JinChung and Pradeep Misra, editors, Procee-dings of the 17th IFAC World Congress.IFAC-PapersOnLine, 2008.

[6] European Cooperation for Space Standardi-zation. ECSS-E-ST-40C Space engineering— Software, March 2009. Available fromESA.

[7] Assal Farrahi, Javier Cubas, and Angel Sanz.Design of the attitude control subsystem ofthe upmsat-2 satellite. Technical report, Ins-tituto de Microgravedad Ignacio da Riva,2013.

XXXIV Jornadas de Automática. Terrassa, 4 al 6 de Septiembre de 2013

783

[8] Gaisler Research. LEON3 - High-performance SPARC V8 32-bit Processor.GRLIB IP Core User’s Manual, 2012.

[9] Jorge Garrido, Daniel Brosnan, Juan A. de laPuente, Alejandro Alonso, and Juan Zamo-rano. Analysis of WCET in an experimentalsatellite software development. In Tullio Var-danega, editor, 12th International Workshopon Worst-Case Execution Time Analysis, vo-lume 23 of OpenAccess Series in Informatics(OASIcs), pages 81–90. Schloss Dagstuhl–Leibniz-Zentrum fuer Informatik, 2012.

[10] Michael Gonzalez Harbour, J. Javier Gu-tierrez, J. Carlos Palencia, and Jose MarıaDrake. MAST modeling and analysis sui-te for real time applications. In Proceedingsof 13th Euromicro Conference on Real-TimeSystems, pages 125–134, Delft, The Nether-lands, June 2001. IEEE Computer SocietyPress.

[11] OMG Unified Modeling Language (UML),2011. Version 2.4.1.

[12] OMG UML Profile for MARTE: Modelingand Analysis of Real-Time Embedded Sys-tems, 2011. Version 1.1.

[13] Emilio Salazar, Alejandro Alonso, Miguel A.de Miguel, and Juan A. de la Puente. Amodel-based framework for developing real-time safety Ada systems. In Reliable Softwa-re Technologies - Ada-Europe 2013, LectureNotes in Computer Science. Springer BerlinHeidelberg, 2013.

[14] SPARC International, Upper Saddle River,NJ, USA. The SPARC architecture manual:Version 8, 1992.

[15] Juan Zamorano and Jose F. Ruiz.GNAT/ORK: An open cross-developmentenvironment for embedded Ravenscar-Adasoftware. In Eduardo F. Camacho, LuisBasanez, and Juan Antonio de la Puente,editors, Proceedings of the 15th IFAC WorldCongress. Elsevier Press, 2003.

XXXIV Jornadas de Automática. Terrassa, 4 al 6 de Septiembre de 2013

784