Indice general - UPMstr/proyectos/upmsat2/doc/Jorge_Garrido-TFG.pdf · ACRONIMOS Y S IMBOLOS ADC...

Indice general

1. RESUMEN 1

2. INTRODUCCION 3

2.1. Antecedentes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2.2. Motivacion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2.3. Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2.4. Estructura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

3. FUNDAMENTO TECNOLOGICO 6

3.1. UPMSat-2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

3.2. Open Ravenscar Kernel . . . . . . . . . . . . . . . . . . . . . . . . . . 9

3.3. Procesadores LEON y computador de abordo . . . . . . . . . . . . . 11

4. MANEJADORES DE DISPOSITIVOS 13

4.1. Metodologıa general . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

4.1.1. Comunicacion entre CPU y dispositivos perifericos . . . . . . 14

4.1.2. Arquitectura software . . . . . . . . . . . . . . . . . . . . . . . 15

4.1.3. Manejo mediante registros . . . . . . . . . . . . . . . . . . . . 16

4.1.4. Manejo de interrupciones . . . . . . . . . . . . . . . . . . . . . 20

4.2. UART . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

4.3. SPI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

i

Indice general

4.4. ADC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

5. MANEJO DE LA MEMORIA NO VOLATIL 29

5.1. Tecnologıa StrataFlash . . . . . . . . . . . . . . . . . . . . . . . . . . 30

5.2. Manejo de la memoria no volatil en el UPMSat-2 . . . . . . . . . . . 31

5.2.1. Buffer circular . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

5.2.2. Mecanismos de recuperacion . . . . . . . . . . . . . . . . . . . 36

6. SISTEMA DE VALIDACION DE SOFTWARE 41

6.1. Sistema de determinacion y control de actitud en el UPMSat-2 . . . . 42

6.2. Sistema de Validacion de Software para el ADCS del UPMSat-2 . . . 44

6.3. Resultados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

7. CONCLUSIONES Y TRABAJO FUTURO 49

ii

Indice de figuras

3.1. Diagrama de estados del UPMSat-2. . . . . . . . . . . . . . . . . . . 8

3.2. Vista exterior del UPMSat-2. . . . . . . . . . . . . . . . . . . . . . . 9

4.1. Arquitectura Von Neumann. . . . . . . . . . . . . . . . . . . . . . . . 14

4.2. Arquitectura software de los manejadores. . . . . . . . . . . . . . . . 16

4.3. Descripcion de un registro en el IP Core User’s Manual. . . . . . . . . 17

4.4. Arquitectura software de los manejadores con interrupciones. . . . . . 20

4.5. Estructura de las tramas sin y con paridad. En el manejador desarro-llado, el software de alto nivel puede configurar con cualquiera de lasdos modalidades (reproducido de [7]). . . . . . . . . . . . . . . . . . 22

4.6. Estructura de un dispositivo UART. APB, de Advanced PeripheralBus, es el bus del computador de abordo (Reproducido de [7]). . . . 23

4.7. Esquema de escrituras y lecturas por la lınea serie mediante rutinade interrupcion. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

5.1. Estructura de la metainformacion. . . . . . . . . . . . . . . . . . . . . 33

5.2. Mecanismo de escritura. . . . . . . . . . . . . . . . . . . . . . . . . . 35

6.1. Modelo del sistema de determinacion y control de actitud. . . . . . . 43

6.2. Configuracion del sistema de validacion del ADCS. . . . . . . . . . . 44

6.3. Etapas del analisis del peor tiempo de computo mediante Rapitime. . 46

6.4. Resultados del analisis del controlador mediante Rapitime. . . . . . . 47

iii

Indice de figuras

6.5. Distribucion de probabilidad de tiempo de computo del controlador. . 48

iv

Listings

3.1. Restricciones del perfil de Ravenscar. . . . . . . . . . . . . . . . . . . 10

4.1. Declaracion del registro de control de la UART. . . . . . . . . . . . . 18

4.2. Declaracion de la estructura del registro de control de la UART. . . . 19

4.3. Primitivas Suppress Initialization y Size en la declaracion de registros. 19

4.4. Declaracion de objetols a partir de los registros declarados. . . . . . . 19

4.5. Pseudocodigo del algoritmo de desplazamiento de periodo aplicado alas lecturas de housekeeping del UPMSat-2. . . . . . . . . . . . . . . 27

5.1. Mecanismo de deteccion de errores en las operaciones de escritura. . . 38

5.2. Mecanismo de deteccion de errores en las operaciones de borrado. . . 40

6.1. Implementacion de la funcion punto de interrupcion. . . . . . . . . . 45

v

ACRONIMOS Y SIMBOLOS

ADC Analog-to-Digital Converter, en espanol Conversor Analogico-Digital

ADCS Attitude Determination and Control System, en espanol Sistema de Deter-minacion y Contol de Actitud

APB Advanced Peripheral Bus, en espanol Bus Periferico Avanzado

Bps Bits Per Second, bits por segundo

CG Control Gate, en espanol Puerta de Control

CPU Central Processing Unit, en espanol Unidad Central de Proceso

DUART Dual Universal Asynchronous Receiver-Transmitter, en espanol Transmisor-Receptor Asıncrono Universal Dual

EEPROM Electrically Erasable Programmable Read-Only Memory, en espanol Me-moria Programable y Borrable Electricamente de Solo Lectura

ESA European Space Agency, Agencia Espacial Europea

FAMOS Floating Gate Avalanche-Injection Metal Oxide Semiconductor

FIFO First In First Out, Primero en Entrar, Primero en Salir

GPIO General Purpose Input/Output, en espanol Entrada Salida de Proposito Ge-neral

HIL Hardware In the Loop

Hz Herzio

I/O Input/Output, en espanol Entrada/Salida

I2C Inter-Integrated Circuit, en espanol Circuitos Inter-Integrados

vi

Listings

IDR Instituto Ignacio Da Riva

Kb Kilobits, 1024 bits

Kbyte Kilobyte

Kg Kilogramo

Mb Megabits, 1024 kilobits

MHz MegaHerzio

ORK Open Ravenscar Kernel

PC Personal Computer, u Ordenador Personal

RISC Reduced Instruction Set Computing, en espanol Juego de Instrucciones Re-ducidas o Computacion de Set de Instrucciones Reducidas

SDRAM Synchronous Dynamic Random Access Memory, en espanol Memoria Dinami-ca de Acceso Aleatorio

SOC System On Chip

SPARC Scalable Processor ARChitecture, en espanol Arquitectura de ProcesadorEscalable

SPI Serial Peripheral Interface, en espanol Interfaz Serie Periferica

STR Sistemas de Tiempo Real

STRAST Grupo de Sistemas de Tiempo Real y Arquitectura de Servicios Telemati-cos

SVF Software Validation Facility, en espanol Entorno de Validacion de Software

UART Universal Asynchronous Receiver-Transmitter, en espanol Transmisor-ReceptorAsıncrono Universal

UHF Ultra High Frequency, frecuencia ultraalta

UPM Universidad Politecnica de Madrid

VHDL Very High Speed Integrated Circuit, en espanol Circuito Integrado de AltaVelocidad

vii

Listings

WCET Worst Case Execution Time, en espanol Peor Caso de Tiempo de Ejecuciono Peor Caso de Tiempo de Computo

viii

Capıtulo 1

RESUMEN

Espanol

En el presente Trabajo de Fin de Grado se abordan diferentes aspectos del diseno,implementacion y verificacion de un sistema de tiempo real de caracterısticas espe-ciales, el satelite UPMSat-2. Este proyecto, llevado a cabo por un grupo de trabajoformado por profesores, alumnos y personal de la Universidad Politecnica de Madrid(UPM), tiene como objetivo el desarrollo de un microsatelite como plataforma dedemostracion tecnologica en orbita.

Parte de este grupo de trabajo es el Grupo de Sistemas de Tiempo Real y Ar-quitectura de Servicios Telematicos (STRAST), del cual el alumno forma parte yque tiene a cargo el diseno e implementacion tanto del software de abordo comodel software de tierra. Dentro de estas asignaciones, el alumno ha trabajado en tresaspectos principales: el diseno e implementacion de diferentes manejadores de dis-positivos, el diseno de un algoritmo para la gestion de la memoria no volatil y laconfiguracion y prueba de un sistema de validacion de software para un subsistemadel satelite.

Tanto la memoria de estas tareas como las bases y fundamentos tecnologicosaplicados se desarrollan en el documento.

1

English

Different aspects of the design, implementation and validation of an specific RealTime System, the UPMSat-2 satellite, are described in this final report. UPMSat-2project is aimed at developing an experimental microsatellite that can be used as atechnology demonstrator for several research groups at UPM.

The Real-Time Systems Group at UPM (STRAST) is responsible for designingand building all the on-board and ground-segment software for the satellite. Inrelation to this, three main task have been carried out and are described in thisdocument: the design and implementation of three different device drivers, the designof an algorithm to manage the nonvolatile memory and the configuration and testof a software validation facility to test the UPMSat-2 Attitude Determination andControl System (ADCS) subsystem.

Detailed information of these tasks and their technological basis are presentedin the rest of the document.

2

Capıtulo 2

INTRODUCCION

El presente documento es la memoria final del Trabajo de Fin de Grado delalumno y en ella se recogen tanto las tareas llevadas a cabo por el alumno duranteel mismo, ası como el estado del arte en aquellas cuestiones relacionadas con estastareas.

2.1. Antecedentes

Como antecedente de este proyecto cabe mencionar el satelite UPMSat-1, lanzadoel 7 de julio de 1995, que fue desarrollado por un grupo de profesores del Laboratoriode Aerodinamica de la Escuela Tecnica Superior de Ingenieros Aeronauticos de laUPM. La mision se realizo con exito, y demostro la capacidad del equipo promotorpara llevar a cabo un proyecto de esta naturaleza. El satelite se mantuvo operativodurante 213 dıas, y figura inscrito en el registro espanol ROLEU y en el de lasNaciones Unidas como UPM-Sat1/ROLEU 4.

Desde el punto de vista del software, el Grupo de Sistemas de Tiempo Realy Arquitectura de Servicios Telematicos (STRAST) ha venido colaborando con laAgencia Europea del Espacio (ESA/ESTEC) en proyectos relacionados con el desa-rrollo de software embarcado en satelites. En este marco se ha desarrollado el nucleode sistema operativo de tiempo real ORK+, orientado al desarrollo de sistemas de al-ta integridad en lenguaje Ada, que forma parte del entorno de desarrollo de softwareembarcado que se esta poniendo en marcha en ESA/ESTEC para futuras misionesespaciales.

Debido a esta experiencia previa del grupo, este fue seleccionado para formar

3

2.2. Motivacion

parte del proyecto UPMSat-2, del cual es encargado del software embarcado y detierra.

2.2. Motivacion

El computador de abordo del UPMSat-2 dispondra de un conjunto de dispositivosde entrada/salida entre los que se encuentran: lıneas series asıncronas (UART), busSerial Peripheral Interface (SPI), entradas y salidas digitales de proposito general(GPIO) y conversores de senal analogico/digitales (ADC). El trabajo ha consistidoen el desarrollo y adaptacion de estos manejadores al computador de abordo delmicrosatelite UPMSat-2.

Estos manejadores se han desarrollado para el nucleo de tiempo real para compu-tadores empotrados ORK (Open Ravenscar Real-Time Kernel). ORK es un sistemaoperativo libre de tiempo real realizado en Ada, que esta disponible para los procesa-dores tolerantes a la radiacion de la Agencia Espacial Europea (ESA). El computadorde abordo esta basado en un procesador LEON3.

Dado que ya existıan algunos manejadores de dispositivos para procesadoresLEON2, estos se han adaptado para la nueva version del procesador. Tal es el casodel manejador de la lınea serie y de las entradas y salidas digitales. Sin embargopara el resto de dispositivos se ha realizado el desarrollo completo.

2.3. Objetivos

La lista de objetivos concretos del proyecto:

Estudio del nucleo ORK y las herramientas de desarrollo cruzado asociadas.Para ello se revisara informacion disponible en la pagina web del grupo deinvestigacion asociado.

Estudio del procesador LEON3: diferencias y similitudes con su predecesorLEON2. Los documentos de estudio seran los generados por sus desarrollado-res. Igualmente, se debera revisar la arquitectura SPARC, a la que pertenecenambos procesadores.

Estudio de los manejadores realizados para ORK/LEON2 y de la guıa paradesarrollar manejadores de dispositivos para ORK. Se debera realizar una

4

2.4. Estructura

comprension de la guıa incluyendo el analisis de las decisiones de diseno eimplementacion de los manejadores realizados previamente.

Eleccion de los manejadores existentes que se pueden adaptar a LEON3.

Desarrollo de los manejadores nuevos: SPI y ADC. Este desarrollo debe seguirel modelo expuesto en la guıa de desarrollo ası como ser coherente con suspredecesores.

Eleccion y configuracion de un sistema de validacion de software (SVF) parapruebas de hardware-in-the-loop.

Pruebas de los manejadores e integracion en el software de abordo del UPMSat-2.

2.4. Estructura

A fin de presentar los conceptos basicos y la tecnologıa usada para facilitar lacomprension del resto del documento, el capıtulo 3 presenta los fundamentos tec-nologicos del proyecto. Posteriormente, cada capıtulo describe concretamente cadauna de las tres tareas principales: el capıtulo 4 describe los manejadores de dispo-sitivos en general y las particularidades de aquellos sobre los que se ha trabajado,justificando su uso en el ambito del proyecto UPMSat-2 y sus decisiones de disenoen cada caso. El capıtulo 5 presenta un mecanismo de manejo de la memoria novolatil adaptado a las necesidades de integridad del satelite de estudio. Finalmente,el capıtulo 6 presenta un sistema de validacion basado en hardware-in-the-loop pa-ra uno de los principales subsistemas del UPMSat-2, el sistema de determinacion ycontrol de actitud.

5

Capıtulo 3

FUNDAMENTOTECNOLOGICO

En este capıtulo se desarollara el conocimiento tecnico basico requerido paraabordar el resto del documento. Este conocimiento se basa, principalmente en latecnologıa de los sistemas de tiempo real, entre los cuales se haya el UPMSat-2.

Los sistemas de tiempo real (STR) son sistemas informaticos que interactuancon el entorno en el que se encuentran con unos requisitos temporales especıficosdeterminados por este entorno. Habitualmente se encuentran en sistemas de inge-nierıa mas amplios, y son estos parte o la totalidad del entorno que controlan. Laimplantacion de estos sistemas en la vida diaria es cada vez mayor, encontrando-se en la mayorıa de dispositivos tanto de uso domestico como industrial: telefonosmoviles, coches, lavadoras, aviones, ingenierıa aeroespacial, o procesos de fabricacionindustrial.

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

Si bien es deseable que todas las tareas se completen dentro de su plazo deejecucion, algunas tareas pueden tener requisitos temporales no estrictos, dentro delas cuales podemos identificar:

Tareas en las cuales la respuesta pierde valor con el paso del tiempo (tarea de

6

tiempo real flexible o soft real-time) como por ejemplo en la adquisicion dedatos.

Tareas en las cuales la perdida de plazos ocasional es asumible para el conjuntodel sistema, pero la respuesta tardıa carece de valor (tiempo real firme). Estees el caso por ejemplo de la perdida de un cuadro de imagen en la reproduccionde vıdeo.

Dado que, como en los sistemas informaticos convencionales, las tareas de tiemporeal se ejecutan de forma concurrente, se requiere de algoritmos de planificacionpara acotar los tiempos de respuesta de estas tareas. En los sistemas mas sencilloslas tareas son todas periodicas e independientes entre sı, de modo que se puedenplanificar de manera estatica en ciclos que se repiten cada un periodo de tiempoigual al mınimo comun multiplo de los periodos de todas las tarea. Este periodo esuna caracterıstica del sistema y se conoce como hiperperiodo.

En sistemas mas complejos, con tareas esporadicas, que se ejecutan cuando ocu-rren determinados sucesos (en instantes distribuidos irregularmente), se requierenmecanismos de prioridades y desalojos para su planificacion. Las diferentes combi-naciones de estos mecanismos dan lugar a diferentes modelos de planificacion. Enel caso del kernel del computador de abordo objeto de estudio, ORK, se sigue unapolıtica de prioridades con desalojo. Esto quiere decir que ante la llegada de unatarea de mayor prioridad, esta pasa a estar en ejecucion quedando la de menor prio-ridad lista para ejecutar. Este enfoque es el mas implementado en los sistemas detiempo real ya que permite el analisis de los tiempos de respuesta de las tareas.

Igualmente, los sistemas de tiempo real tienen otras caracterısticas a tener encuenta. Dado que forman parte de sistemas ingenieriles mas amplios, se les exige ungrado de fiabilidad mayor. Este grado de fiabilidad depende de las consecuencias quepudiera acarrear su fallo. En algunos casos, estos fallos pueden acarrear la perdida devidas humanas, como en el caso de la avionica. En otros, como aquellos que controlanprocesos industriales, estos fallos pueden acarrear grandes perdidas economicas ymedioambientales.

Para ofrecer estas cualidades de fiabilidad y mantenibilidad, los sistemas de tiem-po real suelen tener diferentes modos de funcionamiento, en los cuales el conjuntode tareas que se ejecutan varıa de un modo a otro. De esta manera, dependiendodel estado del sistema se puede transitar a diferentes modos que aseguren su mejorfuncionamiento dado el estado actual. En algunos casos, estos modos estan enfoca-dos a la propia supervivencia del sistema. Un ejemplo de estos modos serıa el modode ahorro de energıa, en el cual el sistema reduce su operatividad pero aumenta su

7

3.1. UPMSat-2

tiempo de operacion en caso de que sus baterıas se encuentren en un nivel demasiadobajo. En el caso concreto del UPMSat-2 se han definido cuatro estados principalescon dos subestados cada uno, como muestra la figura 3.1.

Normal_operation!

Nominal! Experiment!TC!

timer | TC!

Inactive!

Launch! Latency!

low battery |error |!

TC!lost COMM!

separation timer!

TC!Checking!

Initialization! Commissioning!

latencytimer!

Degraded_operation!

lost COMM!

TC received!Safe! Beacon!

auto | timer!

watchdog timer!

critical battery!

TC!

Figura 3.1: Diagrama de estados del UPMSat-2.

3.1. UPMSat-2

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

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

El proyecto abarca todas las etapas de la vida de un satelite incluyendo sudiseno, construccion, validacion, lanzamiento y operacion en orbita sirviendo como

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

2www.idr.upm.es.

8

3.2. Open Ravenscar Kernel

plataforma espacial para la incorporacion de nuevas tecnologıas y siendo adaptable adiferentes servicios de lanzamiento. Su descripcion de base es la de un microsatelitede 50kg de peso. Su estructura es la de un cubo de 0,5m (figura 3.2) y su orbitaprevista sera heliosıncrona a una altura de 600km.

Figura 3.2: Vista exterior del UPMSat-2.

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


El kernel de tiempo real sobre el que correra el software de abordo es una versionde ORK+, el Open Ravenscar real-time Kernel [5] desarrollado por el grupo y queda soporte al perfil de Ravenscar segun esta definido en el estandar de Ada 2005.Este perfil impone unas restricciones al lenguaje Ada [1] de modo que las opera-ciones permitidas en el subconjunto resultante son consideradas seguras para lossistemas de tiempo real. Igualmente, es posible ejecutar programas en C mediantesu importacion.

El perfil de Ravenscar [4] es un conjunto de directivas al compilador para evitarel uso de ciertas estructuras de concurrencia que proporciona Ada y que dificultan la

3www.dit.upm.es/str

9


Listado 3.1: Restricciones del perfil de Ravenscar.

1 No Task Hierarchy2 No Abort Statements3 No Task Al locators4 No Dynamic Pr ior i t i e s5 No Asynchronous Control6 No Calendar7 No Relat ive Delay8 No Protected Type Al locators9 No Loca l Protec ted Object s

10 No Requeue11 No Se lect Statements12 No Task Attr ibutes13 No Task Termination14 No Dynamic Interrupt Handlers15 S i m p l e B a r r i e r V a r i a b l e s16 Max Task Entries => 017 Max Protected Entr ies => 118 Max Asynchronous Select Nest ing => 019 Max Entry Queue Depth => 1 −− in genera l , N

planificacion y el determinismo temporal del software producido. Con estas restric-ciones se obtienen programas que facilitan el analisis estatico temporal y funcionaldel mismo, a la vez que se logra obtener programas con una huella en memoriapredecible. Estas caracterısticas son necesarias, ademas, para poder certificar unsoftware para sistemas de tiempo real estricto.

Debido a que estas restricciones se aplican unicamente a la parte concurrente deAda, un programa completamente secuencial no se ve afectado por las restriccionesde este perfil.

El listado 3.1 muestra el conjunto de restricciones del perfil de Ravenscar alcompleto.

ORK esta integrado con las herramientas de compilacion de GNAT. De estemodo, mediante las herramientas incluidas en la distribucion de GNATforLEON [13]es posible la compilacion cruzada (en la cual el computador objetivo no es el mismoque el de desarrollo) para la ejecucion sobre procesadores de la familia LEON.

10

3.3. Procesadores LEON y computador de abordo

3.3. Procesadores LEON y computador de abor-

do

La familia de procesadores LEON abarca un conjunto de procesadores de 32 bitsbasados en la arquitectura SPARC4 desarrollados inicialmente por la Agencia Espa-cial Europea (ESA)5 y posteriormente por Gaisler Research 6. Se encuentra descritoen lenguaje VHDL para su configuracion y uso en los conocidos como sistemas sys-tem on a chip (SOC) en los cuales la mayorıa (o totalidad) de los componentes delsistema se encuentran en un mismo circuito integrado o chip.

El desarrollo de estos procesadores comenzo en el ano 1997 por parte de la ESAcon el fin de conseguir un diseno de procesador abierto, portable y no propietario,capaz de alcanzar los requisitos de rendimiento, compatibilidad y costes en los pro-yectos a llevar a cabo durante las siguientes decadas. Posteriormente, la empresaGaisler Research, renombrada como Aeroflex Gaisler, paso a ser la encargada deldesarrollo de nuevos modelos de procesadores LEON, entre ellos el LEON3[6], elprocesador seleccionado para su uso en el UPMSat-2.

El procesador LEON3 supuso un avance frente a sus predecesores. Entre los avan-ces mas destacados se halla el aumento en las etapas de su pipeline, que paso delas 5 etapas de su inmediato predecesor, el LEON2, a 7. Igualmente, la distribucionincorporo un gran numero de modulos sintetizables, que lo hacen, como se justifi-cara a lo largo del documento, de alto interes para el proyecto UPMSat-2. Entreestos modulos, los de mayor interes son el controlador de memoria SDRAM de 32bits, los controladores para SPI, I2C y UART con colas FIFO, ası como unidadesde reloj, controladores de interrupcion y puertos de entrada/salida.

Las caracterısticas mas relevantes del computador de abordo son:

Procesador LEON3 con FPU (unidad de coma flotante).

50 canales de entrada analogicos.

4SPARC, del ingles Scalable Processor ARChitecture es una arquitectura RISC (conjunto deinstrucciones reducidas) big-endian. Fue de hecho la primera arquitectura RISC abierta, lo cualla hizo de enorme interes para los propositos de la Agencia Espacial Europea de desarrollar unprocesador abierto y a bajo coste. Su principal avance tecnologico fue la ventana de registros, la cualfacilito el diseno de compiladores de alta eficiencia para esta arquitectura. Esta ventana consisteen un alto numero de registros, de los cuales solo 32 se presentan a la ventana en ejecucion,solapando los registros de salida de una ventana con los de entrada de la siguiente, reduciendoconsiderablemente la necesidad de las operaciones load y store.

5www.esa.int6www.gaisler.com

11

3.3. Procesadores LEON y computador de abordo

Memoria SDRAM (tamano por definir).

Memoria no volatil

• StrataFlash de 256 Mbit.

• 255 bloques de 126 Kbytes y 4 bloques de 32 Kbytes.

Comunicacion interna

• Bus SPI.

• Bus I2C.

• Lınea serie RS-232 a 115200 baudios.

Comunicacion con tierra

• Frecuencia: UHF banda 400 MHz, con potencia reducida.

• Capacidad de enlace: 19200 bps.

12

Capıtulo 4

MANEJADORES DEDISPOSITIVOS

Los manejadores de dispositivos (o drivers segun su denominacion en ingles)son programas cuya finalidad es permitir la comunicacion entre el software de masalto nivel y los dispositivos hardware. Su funcion es, por tanto, ofrecer una capade abstraccion a los niveles superiores, siendo dependientes tanto del hardware quecontrolan como del sistema operativo o kernel sobre el que ejecutan.

Los manejadores interactuan con el hardware comunmente mediante el bus delcomputador y tambien (si es el caso) mediante las lıneas de interrupcion. Esta in-teraccion suele, por lo general, ser iniciada por el manejador, el cual debe, en unaprimera fase, configurar el hardware para su adecuado funcionamiento. A partir deeste momento, dependiendo de la funcionalidad del hardware, la ejecucion del mane-jador puede ser solicitada por software al que da servicio (envıo de datos, cambio deconfiguracion, chequeo de datos disponibles), o bien por la solicitud de interrupcionpor parte del propio hardware (notificacion de eventos, principalmente recepcion dedatos y culminacion de acciones ordenadas previamente).

Para su desarrollo se requiere, como se ha dicho, un profundo conocimiento tantodel hardware a manejar como del sistema operativo o kernel para el que se desarro-lla, ası como el conocimiento del protocolo de comunicacion o proposito del propiohardware. En el caso desarrollado en el proyecto, todo el hardware manejado pro-viene del fabricante Aeroflex Gaisler, estando disponible en su IP Library1 toda lainformacion necesaria para el desarrollo de los drivers. El kernel usado (cuyo estudioformaba parte de las tareas del proyecto) ha sido el anteriormente descrito (seccion

1http://www.gaisler.com

13

4.1. Metodologıa general

3.2) ORK.


Previamente a la descripcion de cada uno de los tres dispositivos sobre los quese ha trabajado se aportan unas nociones basicas sobre la metodologıa empleada,ası como caracterısticas genericas de los drivers generados.

4.1.1. Comunicacion entre CPU y dispositivos perifericos

El primer aspecto a tener en cuenta en el diseno de un manejador de dispositivoes el metodo de acceso al mismo. Como es conocido, los computadores se componende tres subsistemas: la Unidad Central de Proceso (CPU por sus siglas en ingles),la memoria principal y el modulo de entrada-salida (I/O), en el cual se integran losdispositivos perifericos. Estos subsistemas se comunican mediante el bus de comuni-caciones(figura 4.1). Esta es la configuracion clasica presentada por la arquitecturaVon Neumann.

Figura 4.1: Arquitectura Von Neumann.

La comunicacion entre la CPU y el modulo de entrada-salida sigue una logicauniforme, siendo responsabilidad del modulo de entrada-salida el correcto manejo

14


de los diferentes dispositivos a el conectados. Esta comunicacion puede ser abordadamediante dos estrategias diferentes, dependientes del procesador:

Mediante el uso de instrucciones especiales (comunmente in y out) para elmodulo de I/O. Esta estrategia es conocida como isolated I/O map y tiene elinconveniente de requerir lıneas especiales en el bus de comunicaciones.

Mediante el uso de un mismo espacio de direcciones tanto para la memoriacomo para los dispositivos perifericos. Esta estrategia se conoce como entra-da salida mapeada en memoria y es la mas usada, ya que no presenta losinconvenientes de la anterior.

En el caso del procesador usado en el UPMSat-2, de la familia SPARC, la estrate-gia implementada es esta ultima, la entrada salida mapeada en memoria. Medianteeste mecanismo se puede acceder a los registros del dispositivo periferico para suconfiguracion y operacion.

4.1.2. Arquitectura software

Como se describe en el documento de referencia propuesto para el estudio [10],a nivel de software, el driver se descompone en los siguientes componentes logicos:

HLInterface: contiene la interfaz de alto nivel a las aplicaciones.

Parameter: contiene las definiciones de los parametros que pueden ser confi-gurados por el programador de la aplicacion.

Core: contiene el codigo con la logica para interactuar con los registros deldispositivos periferico para llevar a cabo las operaciones de entrada/salida.

Interrupt Handler: En el caso de que, como se explicara, el manejador hagauso del mecanismo de interrupciones, en el Interrupt Handler se declararanlos objetos protegidos (bufferes) a los cuales se asociaran estas interrupciones,ası como la logica interna de estos bufferes.

Registers: contiene las definiciones de los registros del dispositivo (el signifi-cado de cada uno de sus bits) ası como de otras estructuras que puedan serrequeridas.

15


Figura 4.2: Arquitectura software de los manejadores.

4.1.3. Manejo mediante registros

Una vez conocido el canal de comunicacion, el mecanismo de esta comunicacionentre la CPU y los dispositivos perifericos es mediante sus registros. Haciendo uso deesta interfaz de registros es como el dispositivo periferico es configurado y medianteel cual se realizan las operaciones de entrada/salida. De este modo, realizando unaoperacion de lectura sobre estos registros, se puede conocer el estado del perifericoo bien realizar la lectura de los datos de entrada. Por su parte, las operaciones deescritura permiten la configuracion del dispositivo y la escritura de los datos desalida.

Para llevar a cabo estas operaciones correctamente se ha de hacer uso de diversasfuncionalidades del lenguaje Ada (usado mayoritariamente en los sistemas de tiemporeal y por ende en el proyecto del UPMSat-2) que se iran describiendo a lo largo delcapıtulo.

La ordenacion y semantica de cada bit de estos registros dentro del espaciode memoria asignado al dispositivo debe ser ofrecida por el fabricante del mismo.Acorde a esta descripcion, se pueden generar estructuras de datos dentro del driverpara facilitar su manejo, como la mostrada en el listado 4.1, implementacion de

16


la descripcion del fabricante del registro de control del controlador de lınea serie(descrito en la seccion 4.2) mostrado en la figura 4.3.

Figura 4.3: Descripcion de un registro en el IP Core User’s Manual.

Para generar estas estructuras, se hace uso de la clausula record, que no solopermite el definir tipos compuestos, sino tambien la representacion fısica de estos(listado 4.2). Para definir esta representacion correctamente se ha de tener en cuentaque la arquitectura SPARC es big-endian, lo que quiere decir que el primer byte deuna palabra de 32 bits es el mas significativo. Por otra parte, la definicion de lanumeracion en Ada recogida en el [1] que:

If Word Size = Storage Unit, the default bit ordering is implementation

17


Listado 4.1: Declaracion del registro de control de la UART.

1 type UART Control Register i s2 record3 RE : Boolean ; −− Receiver enab l e4 TE : Boolean ; −− Transmitter enab l e5 RI : Boolean ; −− Receiver i n t e r r u p t enab l e6 TI : Boolean ; −− Transmitter i n t e r r u p t enab l e7 PS : Boolean ; −− Par i ty8 PE : Boolean ; −− Par i ty enab l e9 FL : Boolean ; −− Flow Contro l

10 LB : Boolean ; −− Loop back11 EC : Boolean ; −− Externa l c l o c k12 Reserved : Reserved 22 ;13 FA : Boolean ; −− FIFO a v a i l a b l e14 end record ;

defined. If Word Size >Storage Unit, the default bit ordering is the sameas the ordering of storage elements in a word, when interpreted as aninteger.

Ası, el bit numerado como 0 es el mas a la izquierda de aquellos presentados enla figura 4.3 (bit 31).

Igualmente, para cada registro del dispositivo debe hacerse uso de la clausulaSize, que garantiza que el numero de bits usados para la representacion es el indicadopor el programador (si este numero es suficiente).

Finalmente, dado que el compilador GNAT por defecto inicializa los arrays yrecords que contienen datos Booleanos, se ha de hacer uso del pragma especıfico aeste compilador para evitarlo. De este modo se asegura que no se realizan inicializa-ciones indeseadas que puedan llevar a error durante la programacion haciendo usode estas estructuras.

Una vez el registro ha sido completamente definido, puede ser usado como untipo del cual declarar objetos. Para ello, y dado que la estructura del registro y deltipo han sido adecuadamente disenadas, unicamente se requiere que el objeto creadouse la direccion base del registro en memoria para poder ser usado. Para ello empleala clausula Address.

Dado que el compilador puede tratar de optimizar el codigo creando copias lo-cales en lugar de usar la direccion indicada por Address, ademas se ha de anadir laanotacion Atomic al compilador (solucion especıfica para los controladores de me-

18


Listado 4.2: Declaracion de la estructura del registro de control de la UART.

1 for UART Control Register use2 record3 RE at 0 range 31 . . 31 ;4 TE at 0 range 30 . . 30 ;5 RI at 0 range 29 . . 29 ;6 TI at 0 range 28 . . 28 ;7 PS at 0 range 27 . . 27 ;8 PE at 0 range 26 . . 26 ;9 FL at 0 range 25 . . 25 ;

10 LB at 0 range 24 . . 24 ;11 EC at 0 range 23 . . 23 ;12 Reserved at 0 range 1 . . 22 ;13 FA at 0 range 0 . . 0 ;14 end record ;

Listado 4.3: Primitivas Suppress Initialization y Size en la declaracion de registros.

1 pragma S u p p r e s s I n i t i a l i z a t i o n ( UART Control Register ) ;23 for UART Control Register ’ S i z e use 32 ;

moria de la familia LEON). De este modo se hara uso de la direccion de memoriadonde se ha pedido alojar el objeto (la direccion fısica real del registro en el mapea-do de memoria). Ademas, forzara a que los accesos a esta direccion sean de palabracompleta. Ası, se asegura que las operaciones de lectura y escritura se realizan deforma consistente, pero obliga a hacer uso de una copia auxiliar del objeto para sumanipulacion previa.

Un ejemplo del uso de estas funcionalidades sobre el registro previamente descritopuede verse en el listado 4.4.

Listado 4.4: Declaracion de objetols a partir de los registros declarados.

1 UART Control : R e g i s t e r s . UART Control Register ;2 pragma Atomic ( UART Control ) ;3 for UART Control ’ Address use System ’ To Address4 ( Base Address5 + R e g i s t e r s . UART Control Register Offset ) ;67 Control Aux : R e g i s t e r s . UART Control Register ;

19


De este modo, se ha de realizar la lectura del registro del dispositivo UART Controlen la variable Control Aux, sobre la cual se pueden realizar las modificaciones ade-cuadas, para finalmente asignar al registro del dispositivo el valor de la variableControl Aux.

4.1.4. Manejo de interrupciones

Por lo general, los dispositivos perifericos pueden ser configurados para generarpeticiones de interrupcion. De este modo, el procesador puede desentenderse delas operaciones de estos dispositivos hasta que un evento requiera su atencion. Portanto, si se desea usar este mecanismo, el manejador debe darle soporte. Dentrode la arquitectura software presentada el elemento que ha de soportar este tipo deoperaciones es el Interrupt Handler(figura 4.4).

Figura 4.4: Arquitectura software de los manejadores con interrupciones.

En Ada, las interrupciones se manejan asociando procedimientos protegidos alas fuentes de peticiones de interrupcion hardware. De este modo, estos objetosprotegidos se ejecutan cuando el hardware reporta la senal de interrupcion asociada.El manual de referencia de Ada [1] define del siguiente modo las interrupciones:

20


An interrupt represents a class of events that are detected by the hard-ware or the system software. Interrupts are said to occur. An occurrenceof an interrupt is separable into generation and delivery. Generation ofan interrupt is the event in the underlying hardware or system that ma-kes the interrupt available to the program. Delivery is the action thatinvokes part of the program as response to the interrupt occurrence.Between generation and delivery, the interrupt occurrence (or interrupt)is pending. Some or all interrupts may be blocked. When an interruptis blocked, all occurrences of that interrupt are prevented from beingdelivered. Certain interrupts are reserved. The set of reserved interruptsis implementation defined. A reserved interrupt is either an interruptfor which user-defined handlers are not supported, or one which alreadyhas an attached handler by some other implementation-defined means.Program units can be connected to non-reserved interrupts. While con-nected, the program unit is said to be attached to that interrupt. Theexecution of that program unit, the interrupt handler, is invoked upondelivery of the interrupt occurrence. While a handler is attached to aninterrupt, it is called once for each delivered occurrence of that interrupt.While the handler executes, the corresponding interrupt is blocked. Whi-le an interrupt is blocked, all occurrences of that interrupt are preventedfrom being delivered. Whether such occurrences remain pending or arelost is implementation defined. Each interrupt has a default treatmentwhich determines the system’s response to an occurrence of that in-terrupt when no user-defined handler is attached. The set of possibledefault treatments is implementation defined, as is the method (if oneexists) for configuring the default treatments for interrupts. An interruptis delivered to the handler (or default treatment) that is in effect for thatinterrupt at the time of delivery. An exception propagated from a hand-ler that is invoked by an interrupt has no effect. If the Ceiling Lockingpolicy (see D.3) is in effect, the interrupt handler executes with the ac-tive priority that is the ceiling priority of the corresponding protectedobject.

El manejo de las interrupciones en ORK+ esta restringido por la definicion delPerfil de Ravenscar. Ası, las interrupciones solo pueden ser asociadas a los objetosprotegidos de manera estatica. Esto se realiza en el tiempo de elaboracion medianteel pragma Attach Handler, siendo de esta manera analizables y evitando que poten-ciales programas asocien incorrectamente los manejadores de interrupcion en tiempode ejecucion.

21

4.2. UART

Las mencionadas fuentes de interrupcion estan definidas en el paquete Ada.Interrupts.Names, siendo estas dependientes de la plataforma para la cual ha sidodesarrollado el complilador. Igualmente, en este paquete se declaran los niveles deprioridad de estas interrupciones.

La polıtica de manejo de interrupciones por parte del kernel es de esquemaanidado. Esto quiere decir que una interrupcion de bajo nivel puede ser interrumpidapor otra de mas alto nivel. Las interrupciones de menor prioridad quedan bloqueadasmientras se este ejecutando en un nivel igual o superior al suyo. De este modo lalatencia de las interrupciones de alta prioridad se ven minimizadas.

En las sucesivas secciones se justificara el uso o no de las interrupciones y suconfiguracion en funcion de la finalidad de los dispositivos sobre los que se ha tra-bajado.

4.2. UART

Un dispositivo UART (por sus siglas en ingles de Universal Asynchronous Receiver-Transmiter) es un dispositivo de comunicacion en serie, con tramas de 8 bits conun bit de parada y un bit de paridad opcional. Estas tramas se comunican a unavelocidad marcada por un divisor de reloj programable de 12 bits. Para almacenarlos datos de estas comunicaciones existen dos colas FIFO (una para transmision yotra para recepcion).

Figura 4.5: Estructura de las tramas sin y con paridad. En el manejador desarrollado,el software de alto nivel puede configurar con cualquiera de las dos modalidades(reproducido de [7]).

Cuando existe algun dato en la cola de transmision y el dispositivo se encuentralisto, el primer dato de la cola se transfiere al shift register donde es convertido a latrama serie descrita y enviado por el pin de salida TXD. Despues del bit de inicio,el siguiente bit enviado es el menos significativo del byte a enviar.

22

4.2. UART

Figura 4.6: Estructura de un dispositivo UART. APB, de Advanced Peripheral Bus,es el bus del computador de abordo (Reproducido de [7]).

Cuando el bit de recepcion de datos esta activado, el receptor espera una tran-sicion del alto a bajo voltaje (bit de inicio) en el pin de recepcion (RXD) paracomenzar la recepcion de datos. De igual modo, el primer bit recibido se trata comoel menos significativo. Si durante la recepcion no ha habido errores, el bit data readyse activara. Sino, el bit correspondiente al error acaecido se activara para notificara la CPU este hecho.

Dado lo numerosas y prolongadas que pueden ser estas operaciones de transmi-sion y recepcion, el driver recibido como base para su adaptacion a las necesidadesdel UPMSat-2 llevaba a cabo la sincronizacion de estas operaciones con la CPUmediante interrupciones.

Como se expuso en la seccion dedicada al manejo mediante interrupciones de losdispositivos perifericos, las lıneas de interrupcion son determinadas por el hardwaresobre el que se ejecuta, debiendo el kernel realizar un correcto manejo de ellas.Dado que el procesador sobre el que se desarrollo el el driver fue el LEON2, parasu aplicacion en el UPMSat-2 (LEON3) se requirio la adaptacion de las lineas deinterrupcion asociadas a las interrupciones de las unidades UART.

Igualmente, a pesar de que los dispositivos UART estan orientados a byte, su usopor parte del software de alto nivel suele involucrar mensajes de mayor longitud.Es posible que esta longitud sea mayor que el tamano de las colas FIFO que el

23

4.2. UART

dispositivo ofrece. Por tanto, el manejador ha de disponer un mecanismo de bufferpara poder gestionar estos datos. Concretamente, se dispone de dos bufferes pordispositivo, uno de recepcion y otro de transmision, cada uno para dar soporte a lacola FIFO equivalente (figura 4.7). Los objetos protegidos formados por cada parde bufferes (y sus variables asociadas) son a los cuales se asocian las interrupcionesque han sido correctamente redirigidas adaptandolas al hardware del computadorde abordo. Dado que la interrupcion es la llamada al objeto protegido, este ha detener mecanismos para identificar el motivo de la solicitud de interrupcion y operarde acuerdo a ella. Para ello, en el caso de la UART, se ha de consultar el registro decontrol definido en la figura 4.3 para comprobar la causa de la interrupcion.

Figura 4.7: Esquema de escrituras y lecturas por la lınea serie mediante rutina deinterrupcion.

24

4.3. SPI

Finalmente, sobre los manejadores de UART se ha realizado un trabajo de indi-vidualizacion de estos. En versiones anteriores, el manejador se hacıa cargo de dosdispositivos UART. Esto es debido a que, si bien es habitual que estos dispositivos seencuentren por pares (conocidos como DUART), estos tambien pueden encontrarsepor separado o en numeros impares. Por tanto, la individualizacion del manejadorparece mas logica e intuitiva y evita la propagacion de errores en caso de fallo dealguno de los dispositivos.

Para llevar a cabo esta individualizacion se han identificado los valores propiosde cada dispositivo (direccion base, nombre y prioridad de la interrupcion asociada),ası como los potenciales valores propios (tamano de los bufferes) y se han eliminado(o adecuado) todas aquellas secciones de codigo en las cuales se operase un segundodispositivo en el manejador original. De este modo, cada dispositivo dispondra desu propio paquete con sus valores unicos.

4.3. SPI

Los buses SPI (por sus siglas en ingles de Serial Peripheral Interface) son busesserie sıncronos estandarizados que permiten la transmision full duplex entre los ex-tremos. Su uso es mayoritario en los circuitos integrados debido al reducido numerode conductores, pines y tamano de su circuito integrado propio, a pesar de su menorvelocidad frente a otros dispositivos de similar funcion. Este bus sigue una polıticade maestro/esclavo e incluye una lınea de reloj, una linea de datos de maestro aesclavo, una lınea de esclavo a maestro y en el maestro tantas lıneas de seleccion deesclavo como posibles esclavos haya. En el lado del esclavo esta lınea es unica y sufuncion es ser seleccionado por el maestro mediante transicion de voltaje.

En el ambito del proyecto del UPMSat-2, el bus SPI comunica el computadorde abordo con los conversores analogico-digital (descritos en la seccion 4.4) encar-gado de digitalizar las lecturas de los multiples dispositivos perifericos del sateliteque realizan lecturas analogicas (magnetometros, termometros, controladores de ex-perimentos, etc.). Debido al numero de estos dispositivos, se requiere de cuatroconversores y por tanto, dado que cada bus SPI solo tendra un esclavo, cuatro busesSPI.

Para el diseno y codificacion del manejador del bus SPI se ha seguido la estructurade herencia descrita en este capıtulo. Dado que estas lecturas se realizaran conuna frecuencia de un segundo y que el volumen de datos sera relativamente bajo,teoricamente se ha determinado que no se requiere un mecanismo de interrupciones,a diferencia de el caso de la UART. Por el contrario se ha decidido hacer uso del

25

4.4. ADC

mecanismo de polling, en el cual la CPU consulta el estado de los registros deldispositivo esperando la senalizacion en ellos del evento esperado.

4.4. ADC

Los conversores ADC (por sus siglas en ingles de Analog to Digital Converter)son dispositivos electronicos que convierten valores analogicos contınuos en valoresdiscretos digitales. Este proceso se realiza mediante la conversion del voltaje de en-trada al dispositivo en un valor digital proporcional, segun una determinada funcionde transferencia.

El conversor que sera usado en el satelite sera el ADC LTC2498 de Linear Te-chnology2. Este conversor posee 17 canales de entrada de los cuales puede calcularla diferencia de voltaje entre pares. De este modo, si el voltaje de referencia paratodos los dispositivos a controlar es el mismo, cada conversor puede soportar hasta16 dispositivos. Dado que existen 50 entradas analogicas se requerira un total decuatro conversores para realizar las conversiones pertinentes.

Estos dispositivos ofrecen una resolucion de 24 bits, mas que suficiente paralas medidas a tomar (entre 0 y 5 voltios). Igualmente, esta alta resolucion permiteasumir las posibles desviaciones del resultado provocados por la temperatura deldispositivo.

Al igual que en los manejadores descritos anteriormente, el diseno del mismo seha realizado siguiendo el patron expuesto en la seccion 4.1. Dado que este dispositivose comunica con la CPU mediante el bus SPI, depende de la implementacion de esteel uso o no de interrupciones para su manejo. Como se adelanto, debido al bajo flujode datos requerido y de la baja latencia de estos, no se ha considerado necesaria estaposibilidad.

El mecanismo de operacion de este modelo, el ADC LTC2498 es tal que, sacan-do partido a la funcionalidad full duplex del bus SPI, en el mismo ciclo en el cualdetecta la llegada de una nueva configuracion por la lınea maestro/esclavo, calcula yenvıa por la lınea esclavo/maestro una medida con la ultima configuracion recibida.Esto significa que para obtener la lectura de un canal que no es el ultimo seleccio-nado se requiere enviar la configuracion dos veces (la primera para configurar y lasegunda obtener como respuesta la medida) y desechar la primera de las respuestasdel conversor.

2http://www.linear.com/

26

4.4. ADC

Listado 4.5: Pseudocodigo del algoritmo de desplazamiento de periodo aplicado alas lecturas de housekeeping del UPMSat-2.

1 Device : i n t e g e r ;2 Channel : i n t e g e r ;3 for Device in 1 . . 4 loop4 ADC. Core . Conf ( Device , 0 ) ;5 ADC. Core . Read ( Device , Data ) ;6 for Channel in 1 . . 15 loop7 ADC. Core . ConfS ing le ( Device , Channel ) ;8 ADC. Core . Read ( Device , Data ) ;9 StoreResponse ( Device , Channel−1, Data ) ;

10 end loop ;11 ADC. Core . ConfS ing le ( Device , 0 ) ;12 ADC. Core . Read ( Device , Data ) ;13 StoreResponse ( Device , 15 , Data ) ;14 end loop ;

Esta caracterıstica, que en principio puede parecer negativa, resulta beneficiosapara disminuir la latencia de respuesta del dispositivo mientras se haga uso de losalgoritmos adecuados. Ya que la mayorıa de las medidas a tomar corresponden adatos de housekeeping que se recopilan al mismo tiempo, el uso del mecanismode desplazamiento de periodo permite optimizar la recopilacion de medidas paraeste modo de operacion del conversor. Este algoritmo de desplazamiento de periodoconsiste en la solicitud del dato futuro mientras se recibe el solicitado en el pasoprevio. Ası, en el primer paso se solicitarıa la medida del primer dispositivo y serechazarıa el resultado, en el segundo paso se solicitarıa la medida del segundodispositivo y se almacenarıa el resultado recibido como el del primer dispositivo, enel tercer paso se solicita el tercer dispositivo y se recibe el segundo, etc. En el ultimopaso (para recibir la medida del ultimo dispositivo conectado a cada conversor) esirrelevante la solicitud a realizar, ya que solo se desea recibir la medida solicitadaen el paso anterior. No resultarıa fiable confiar en que la ultima peticion realizadaen este procedimiento de desplazamiento de periodo sea realmente la configuracionexistente al comienzo de la siguiente iteracion. Esto es debido a que se puedenrequerir mediciones puntuales fuera de la tarea periodica de chequeo del sistema yque un reinicio del sistema requerirıa enviar de nuevo una configuracion valida.

Hay que tener en cuenta, ademas, que existen cuatro conversores con 16 dispo-sitivos asociados a cada uno. Por tanto no se puede ejecutar el algoritmo de despla-zamiento de periodo con todos los dispositivos en un solo bucle, sino que realmentese realizaran cuatro bucles diferentes, uno por cada conversor. Este procedimiento

27

4.4. ADC

se ilustra en el pseudocodigo mostrado en el listado 4.5.

28

Capıtulo 5

MANEJO DE LA MEMORIA NOVOLATIL

En este capıtulo se detalla la propuesta realizada por el alumno para el manejode la memoria no volatil en el proyecto del UPMSat-2 con el fin de asegurar suconsistencia. Esta propuesta se ha llevado a cabo mediante el analisis tanto de latecnologıa disponible en el ambito del proyecto como del estado del arte en este tipode dispositivos aplicados a los sistemas de tiempo real.

Como en la mayor parte de los sistemas informaticos, el satelite UPMSat-2 re-quiere de un mecanismo de almacenamiento de memoria persistente durante superiodo de operacion. Esta informacion almacenada contendra diversos datos de in-teres para los investigadores relacionados con el proyecto. Ası, los eventos sucedidosen el periodo de operacion, los datos obtenidos de los experimentos de abordo, lainformacion de las comprobaciones del sistema, la configuracion del satelite y laidentificacion de los dispositivos que se ha determinado que presentan errores sealmacenaran en un dispositivo especıfico del satelite para su posterior envıo a tierra.

Un satelite, por sus caracterısticas especıficas y entorno de operacion, se ve ex-puesto a diferentes riesgos por los cuales su memoria volatil puede perderse con ciertafacilidad o asiduidad. Las mas habituales son el reinicio inminente del computadorde abordo ante la expiracion del temporizador de guardia del sistema (watchdog ti-mer en la figura 3.1), el cambio a un estado de operacion degradado como medidade precaucion ante un estado crıtico de las baterıas, y en general cualquier situacionque cause un reinicio del sistema y por tanto del contenido de la memoria SDRAM.Es por esto que esta informacion, de gran utilidad para tanto los investigadorescomo para los desarrolladores del computador de abordo, se debe mantener con un

29

5.1. Tecnologıa StrataFlash

elevado nivel de proteccion.

Dada la relevancia de los datos almacenados, tanto para el estudio de los expe-rimentos de abordo, como para el analisis de las posibles causas y soluciones de lasdiferentes eventualidades que el satelite pueda tener que abordar durante su periodode operacion. Un correcto almacenaje y emision a Tierra de los diferentes eventosocurridos previamente a algunos de los riesgos descritos permiten a los ingenierosaumentar su conocimiento de la operacion del satelite y tener los datos suficien-tes para poder alterar esta mediante los mecanismos previstos (cambio manual delestado de operacion, envıo de parches software, etc.).

En el caso concreto del satelite objeto de estudio, la memoria no volatil es unaStrataFlash de Intel1 de 256 Mbits. Este tipo de tecnologıa tiene unas ventajas ydesventajas determinadas en su uso que han de ser objeto de estudio previo a lapresentacion como tal del manejo de la memoria a realizar en el satelite.

5.1. Tecnologıa StrataFlash

La tecnologıa StrataFlash es un tipo concreto de memoria flash de tipo NORdesarrollada por Intel desde comienzos de la decada de los noventa. En 2008 tras-paso esta tecnologıa a una nueva empresa, Numonyx, desarrollada de forma conjuntacon STMicroelectronics2 y adquirida en 2010 por Micron Technology3.

Como todas las memorias flash, es descendiente directo de la tecnologıa EE-PROM, permitiendo la lectura y escritura de multiples posiciones de memoria enla misma operacion, a diferencia de su predecesora. Sin embargo, el concepto sub-yacente a esta tecnologıa es el mismo: una matriz de celdas con un transistor condos puertas en cada interseccion, una de ellas de control (CG - Control Gate) y laotra conteniendo la fuente y el drenador (FG - Floating Gate), siguiendo la basetecnologica de los transistores FAMOS (Floating Gate Avalanche-Injection MetalOxide Semiconductor).

En el caso de las memorias flash de tipo NOR, el estado por defecto de la me-moria es con todos sus bits a “1”, debido a que en este estado no existe voltaje en lacelda. Para la programacion (escritura de “0’s”) se permite el paso de corriente des-de el terminal fuente al sumidero, generando un voltaje alto en la puerta de control(CG), reteniendo los electrones en el campo electrico del transistor. Este proceso

1http://www.intel.com2http://www.st.com3http://www.micron.com

30

5.2. Manejo de la memoria no volatil en el UPMSat-2

se conoce como hot-electron injection. Esta escritura, por tanto, puede hacerse dela granularidad deseada, incluyendo granularidad de bit. Para devolver al transis-tor a su estado original, se requiere expulsar estos electrones mediante la tecnicade Fowler-Nordheim tunnelling, un proceso de tunelado mecanico - cuantico. Estatecnica consiste en la aplicacion de un alto voltaje inverso, haciendo que los elec-trones abandonen el transistor por el sumidero. Este agresivo proceso, en el largoplazo, provoca un cierto deterioro en las celdas, haciendo que estas solo permitan en-tre 10.000 y 1.000.000 de borrados. Dado el esperado periodo de 2 anos de operaciondel satelite, esta degradacion no debe suponer un riesgo para su integridad.

Su naturaleza electrica confiere a las memorias flash notables ventajas frente alos discos duros mecanicos convencionales: gran resistencia a los golpes (frente alas fuertes vibraciones del lanzamiento), bajısima latencia de lectura (ideal para elalgoritmo a presentar), bajo consumo (dadas las limitaciones de los paneles solares)y un reducido tamano y peso (de gran relevancia en un microsatelite de 50kg de pesoy 0.15m3de volumen). Todas estas ventajas la hacen ideal para uso en del proyectodel UPMSat-2.

Sin embargo, esta tecnologıa tambien presenta una serie de inconvenientes rela-cionados con el proceso de borrado de la misma (requerido para su reprogramacion).Este proceso es, con diferencia, el mas lento de los que lleva a cabo. Para reducirsu latencia, los fabricantes dividen estas memorias en bloques de tamanos de ordende Kb o Mb, de manera que la operacion de borrado afecta al bloque completo.Teniendo en cuenta estas dos cuestiones, podemos suponer el alto coste que tienela modificacion de un dato, con el borrado de gran cantidad de informacion y sureescritura con las modificaciones pertinentes. Con el objetivo de minimizar la fre-cuencia y coste de estas operaciones, se propone un algoritmo de uso de la memoriano volatil en la seccion 5.2.

5.2. Manejo de la memoria no volatil en el UPMSat-

2

Como se ha avanzado, el computador de abordo del UPMSat-2 dispondra de unaStrataFlash de Intel de 256 Mbit dividida en 255 bloques de 128 Kbytes y 4 bloquesde 32 Kbytes. Esta division de bloques tan grande obliga a buscar un algoritmo quepermita su maximo aprovechamiento antes de cada borrado. Para ello se proponeun algoritmo de buffer circular para el uso de la memoria no volatil.

De este modo, los datos se almacenaran en sub-bloques logicos dentro de los

31


bloques fısicos siguiendo un orden secuencial, nunca modificando datos escritos pre-viamente. Dado que la mayor parte de los datos a almacenar son historicos (house-keeping, resultados de experimentos, eventos, etc.) esta posible solucion se adecuarazonablemente al problema presentado.

La solucion del buffer circular, a pesar de su eficiencia, requiere tener en cuentaun determinado numero de connotaciones para mantener su eficacia.

5.2.1. Buffer circular

Metainformacion

La primera de ellas es la evidente necesidad de el mantenimiento de una me-tainformacion de la memoria no volatil. Esta metainformacion, por la naturalezadescrita del sistema, ha de mantenerse, igualmente en la propia memoria no volatil,a fin de mantener su consistencia incluso tras eventuales reinicios del computador ocambios de modo, como se ha explicado previamente.

Clasicamente, esta metainformacion, al tratarse de un buffer, debe al menos con-tener un puntero que indique cual es el siguiente subbloque disponible para escribir.Igualmente, serıa de gran interes mantener otro puntero de borrado. Este punterode borrado, ya que solo tiene sentido a nivel de bloque (no es posible borrar a menorescala), tendra un tamano limitado. Sin embargo, el puntero de escritura, dado quetiene un sentido de subbloque requerira un tamano mayor. Recordemos que, dadoque solo hay una operacion “barata”, estos punteros no podran guiarse por el valorbinario del puntero, sino por el numero de bits programados (puestos a cero) quecontenga su campo en la memoria. Esto tiene dos desventajas. La primera, el grantamano que puede alcanzar el puntero de escritura. Sin embargo, el tamano mas quesuficiente de la memoria no volatil deberıa poder soportarlo sin problema. La segun-da desventaja es derivada de la primera. El gran tamano del puntero almacenadoen la memoria no volatil podrıa suponer un alto coste de lectura si cada vez que hade ser usado se ha de leer de la memoria no volatil. Sin embargo, como veremos,este puntero de la memoria no volatil es un mecanismo de seguridad y recuperacion(descrito en la seccion 5.2.2). El puntero que ha de usarse en esos casos se almace-nara en memoria principal y sera recalculado a partir del almacenado en la memoriano volatil unicamente si el anterior se pierde.

Esta metainformacion basica de los bufferes circulares, sin embargo, no serıasuficiente para el caso del satelite, pues, ademas, se requiere conocer otro tipo deinformacion sobre los datos contenidos. Esto nos lleva a pensar en una estructura

32


de metainformacion mas compleja que debe ser almacenada.

La primera de las informaciones que resulta razonable almacenar es que subblo-ques se encuentran escritos y cuales no. Para ello, y como mecanismo de seguridad,ademas del puntero, se gestionara un bit de escritura por subbloque.

Otra informacion de interes es que subbloques de informacion ya han sido en-viados a Tierra y por tanto pueden ser borrados de la memoria. Igualmente deberıapoder anotarse que un bloque es erroneo (bien por fallo de escritura, bien por datosobsoletos, etc.). Esta condicion, si bien es de un origen diferente, tiene un mis-mo significado a efectos del sistema que los bloques enviados (que un bloque estausado, pero su informacion carece ya de valor) y por ello se pueden tratar ambasinformaciones de la misma manera. De igual modo, hara falta almacenar en la me-tainformacion que un bloque ha sido realmente borrado, como se justificara en elapartado correspondiente (seccion 5.2.2). Existira, por tanto un apartado de me-tainformacion relativa a los bloques fısicos, no unicamente de los subbloques. Portanto, la metainformacion presentarıa la estructura mostrada en la figura 5.1.

1 1

¬Enviado/Erróneo

¬EscritoMetainformación de subbloque

1

¬Borrado

Metainformación de bloque

Metainformación de n subbloques

Metainformación de bloque

... ...

Figura 5.1: Estructura de la metainformacion.

33


Una vez justificada la necesidad de mantener una metainformacion, ha de tenerseen cuenta ciertas consideraciones al respecto. De todas ellas, la mas importante,o de mayor relevancia en el diseno es la necesidad de que los subbloques de lamemoria sean de un tamano fijo conocido. Esto, como se puede suponer, facilitaen gran medida el direccionamiento de estos subbloques y de su metainformacionasociada. Ası, habra una relacion directa entre la direccion del subbloque y la de sumetainformacion.

Nuevamente, esta solucion nos lleva a pensar en sus desventajas. La primerade ellas es la necesidad de mantener un cierto orden dentro del buffer. No serıarazonable que datos de diferente ındole y prioridad en su uso y envıo a Tierra se en-contrasen indiferentemente en las mismas regiones de memoria. Esto harıa del todoineficiente la busqueda de la informacion cuando fuese necesaria, debiendo poten-cialmente recorrer grandes regiones de memoria en busqueda del subbloque deseado.Ası, parece logico pensar en una subdivision del espacio de memoria disponible envarias regiones especıficas para cada uno de los tipos de informacion identificados.

Esta subdivision, ademas, resuelve la segunda desventaja del uso de subbloquesde tamano fijo: su posible ineficiencia debida al diferente tamano de los diferentestipos de informacion a almacenar. Para un evento posiblemente sea suficiente conalmacenar el valor del reloj de mision en el cual ocurrio el evento (4 bytes), elidentificador de tipo de evento (1 byte posiblemente sea suficiente) y algun otro valornumerico relevante si el tipo de evento lo requiere (4 bytes). Sin embargo, un chequeocompleto del satelite que incluya los datos de posicion, orientacion, temperatura delas diferentes partes del satelite, estado de las baterıas, etc. puede llegar a requerircientos de bytes. Por tanto, parece logico que cada region de la memoria asociadaa cada tipo de informacion tenga un tamano diferente de subbloque. Por tanto, serequeriran varios punteros de escritura y borrado, uno por cada uno de los diferentestipos de datos que se identifiquen.

Si bien la metainformacion por subbloque a almacenar es relativamente pequena,la cantidad potencial de subbloques es alta, por lo cual, se requerira de un razonableespacio de memoria para el almacenamiento de la metainformacion. Ademas y dadoque, como se vera, esta metainformacion tambien requerira de un mecanismo segurode borrado, lo mas eficiente resulta almacenar la metainformacion en los bloques demenor tamano, cuyo tiempo de borrado es proporcionalmente menor, y en los cualesen cada borrado una menor cantidad de datos se ven comprometidos.

34


Escritura y borrado

Una vez se dispone del conocimiento de la metainformacion necesaria se puedeabordar el mecanismo de escritura y lectura, siempre siguiendo la base teorica delbuffer circular.

Escritura

El mecanismo de escritura, como en todo buffer circular, se basa en la posicion delpuntero de escritura. Como se avanzo, cada tipo de informacion dispondra del suyo,ejecutandose la operacion de escritura sobre el subbloque apuntado por el puntero,que sera siempre el primero vacıo. Acto seguido se avanzara el puntero de escrituray finalmente se marcara el bloque como escrito en la metainformacion pertenecientea este subbloque. El ultimo byte del subbloque no contendra datos, sino que sera unbyte con todos sus bits a 0, para asegurar que la escritura se ha completado. Tantoeste byte como el orden de ejecucion se justificara con mayor detalle en el apartadode recuperacion (seccion 5.2.2).

Figura 5.2: Mecanismo de escritura.

Borrado

En el caso del borrado, ante todo, debe determinarse en que caso se ha de borrarla informacion almacenada en la memoria volatil. Es posible que, dependiendo del

35


tipo de informacion almacenada, sea de mayor interes mantener la informacion an-tigua no enviada a tierra que almacenar nueva informacion. En este caso, cuando elpuntero de escritura alcance al de borrado, mientras no se envıe el contenido de unbloque completo (o por telecomando se ordene lo contrario), las siguientes peticionesde escritura no tendran efecto y la informacion de esas peticiones se perderan.

Sin embargo, es mas habitual que se determine que la informacion antigua queno haya sido enviada no es relevante (o lo es menos que la futura). En este caso sedebera mantener un espacio mınimo de un bloque entre el puntero de escritura y el deborrado, a fin de asegurar que siempre la proxima peticion de escritura encontrara unbloque listo para escribir en el, borrando los bloques siguientes independientementedel estado de su contenido.

En cualquiera de los casos, una vez se determine que se ha de borrar (y quebloques) el mecanismo propuesto es el mismo. En primer lugar se copia en un bloqueauxiliar el estado de la metainformacion deseado (es decir, el estado en el que seencuentra la metainformacion en el momento del borrado salvo los subbloques aborrar, cuya metainformacion contendra todos sus bits a uno, es decir, retornanal estado original). Posteriormente se borra el bloque original donde se encontrabaesta metainformacion. Una vez se ha completado el borrado, se copia de nuevodel bloque auxiliar al original y se borra el auxiliar. Una vez la metainformacionesta correcta, se procede a borrar fısicamente en orden secuencial los bloques que sedesean borrar avanzando el puntero de borrado y poniendo a “0” el bit de borradoen la metainformacion del subbloque afectado. Una vez esto se ha realizado se dapor concluido el proceso de borrado para ese bloque concreto.

Este proceso puede parecer costoso y poco eficiente, pero con un correcto es-timado teorico y empırico se puede optimizar el numero de bloques borrados poroperacion. Ademas, este proceso es necesario para mantener la consistencia de lametainformacion, como sera explicado en la seccion de recuperacion.

5.2.2. Mecanismos de recuperacion

Como se ha explicado en este capıtulo, existen diversos riesgos en la operacion delsatelite que pueden alterarla y poner en peligro su memoria volatil. Hasta el momentose ha resuelto la ocurrencia de estos riesgos mientras no se esten llevando a cabooperaciones de memoria. Sin embargo, por su larga duracion, tambien es posible queestos riesgos ocurran durante las operaciones de memoria. Por tanto, para mantenerla coherencia de la metainformacion y evitar la perdida de informacion, se ha deimplementar un mecanismo de recuperacion de las operaciones de memoria en curso

36


(si las hubiera) tras los cambios de estado del satelite (tras reinicio, vuelta a estadode operacion nominal, etc.). En esta seccion se describe el mecanismo propuesto porel alumno acorde a los diferentes estados de la memoria dentro del algoritmo deescritura y borrado descrito previamente.

Recuperacion de escrituras

En el caso de la escritura, es posible que el proceso se interrumpa en tres mo-mentos diferentes:

El primero de ellos es durante la escritura en sı del subbloque. Puede deberseprincipalmente a un estado crıtico de las baterıas o a un error en la propiaescritura. En este caso no existe recuperacion posible y el subbloque afectadodebe marcarse como escrito y enviado/erroneo y avanzarse el puntero de es-critura. Para poder aseverarse este hecho, el ultimo byte de cada subbloquesera de comprobacion y su valor sera 0.

El segundo caso en el que se puede dar una interrupcion del proceso de escrituraes entre el final de la escritura y su marcado como escrito. Esto habra sucedidosi en el momento de activarse el mecanismo de recuperacion el puntero de es-critura apunta a un bloque marcado como no escrito, pero que si se encuentraescrito. Para comprobar esto, se ha de revisar el ultimo byte del subbloqueque como se adelanto tendra siempre el valor 0 (si se ha escrito completa-mente). La recuperacion por tanto consiste en el marcado como escrito en lametainformacion y avance del puntero de escritura.

El ultimo de ellos es entre el marcado como escrito y el avance del puntero.Para recuperar el estado coherente, ha de revisarse que el puntero de escrituraapunte a un subbloque no marcado como escrito. Si no es ası, debera avanzarseel puntero para completar la recuperacion.

Estos tres casos abarcan la posible casuıstica en las operaciones de escritura ypermiten ser perfectamente identificados para recuperar la operacion.

Recuperacion de borrados

En lo concerniente a las operaciones de borrado, dada su mayor complejidad, lasseis posibles anomalıas que pueden ser detectadas son:

37


Listado 5.1: Mecanismo de deteccion de errores en las operaciones de escritura.

1 for i in Number Of Subsystems loop2 begin3 po in t e r = g e t w r i t e p o i n t e r ( i ) ;4 l a s t w r i t t e n = g e t l a s t w r i t t e n a d d r e s s ( i ) ;5 i f po in t e r not equal l a s t w r i t t e n6 i f next b lock . ends w i th ze ro7 not marked b lock e r ro r ;8 else9 i f next b lock . s t a r t e d

10 n o t r e c o v e r a b l e e r r o r ;11 else12 OK;13 end i f ;14 end i f ;15 else16 p o i n t e r n o t i n c r e a s e d e r r o r ;17 end i f ;18 end loop ;

La primera de ellas podrıa suceder durante la copia de la metainformacion.Se detecta comprobando el estado del bloque auxiliar. Si esta no se encuentracompleta (asegurado mediante el mismo mecanismo de byte a 0 al final), nosencontramos en este caso concreto. Dado que la orden de borrado ha de serdeterminista, es decir, se ha de borrar siempre bajo las mismas circunstanciasy con el mismo efecto, se puede volver a calcular la orden original. Para ello,ademas se ha de borrar el bloque auxiliar por completo para volver a serescrito. A partir de este punto, se recomienza con el procedimiento estandarde borrado.

La segunda posibilidad es que se interrumpa el proceso entre la copia al bloqueauxiliar y el borrado o la reescritura al bloque original. En ambos casos elbloque auxiliar esta completamente escrito, con lo cual se puede directamentecontinuar con el procedimiento habitual borrando o copiando el contenido delbloque auxiliar al original.

La tercera posibilidad es que la interrupcion del proceso suceda durante lareescritura del bloque original, es decir, que esta no sea haya completado. Eneste caso la recuperacion consiste en el borrado de nuevo del bloque originaly copia en el del bloque auxiliar. A partir de esta copia se continua con elprocedimiento habitual.

38


La cuarta posibilidad es que la interrupcion del proceso de borrado ocurra trasla copia del bloque auxiliar en el bloque original. Esta situacion se detectacomprobando que el bloque auxiliar y el original son identicos. En este caso seha de borrar el auxiliar y continuar con el procedimiento habitual.

La quinta posibilidad es que se produzca la interrupcion bien entre el borradodel bloque auxiliar y el borrado del primero de los bloques de datos, o bientras el borrado y avance del puntero de borrado de alguno de los bloquesde borrado. En ambos casos el mecanismo de deteccion y recuperacion es elmismo. La deteccion consiste en comprobar que el ultimo bloque marcado comoborrado en la metainformacion coincida con el puntero de borrado. Si no es ası,y ademas, el puntero apunta al primer bloque no borrado, nos encontramosen esta anomalıa. La recuperacion consiste en continuar el proceso habitual deborrado y avance de puntero a partir del primer bloque no borrado.

La ultima de las posibilidades es que se haya interrumpido el proceso entre elel borrado y el avance del puntero de borrado. Se detecta cuando se cumplenlas condiciones del caso anterior, pero el puntero de borrado apunta a unbloque que realmente si ha sido borrado. Por tanto, ha de avanzarse el punterode borrado y proseguir el mecanismo de borrado y avance en funcion de losbloques pendientes de borrar.

39


Listado 5.2: Mecanismo de deteccion de errores en las operaciones de borrado.

1 for i in Number Of Subsystems loop2 begin3 po in t e r = g e t e r a s e p o i n t e r ( i ) ;4 l a s t e r a s e d = g e t l a s t e r a s e d a d d r e s s ( i ) ;5 l a s t i n t e n d e d e r a s e = g e t l a s t i n t e n d e d e r a s e d a d d r e s s ( i ) ;6 i f metainf . not complete7 e r a s e o r i g i n a l b l o c k ;8 copy aux block ;9 else

10 i f aux . comp l e t e l y wr i t t en and metainf . c o r r e c t11 e rase aux ;12 else i f aux . comp l e t e l y wr i t t en and not metainf . c o r r e c t13 e r a s e o r i g i n a l b l o c k ;14 copy aux block ;15 else i f aux . e rased and metainf . c o r r e c t and l a s t e r a s e d equal po in t e r16 advance po inte r17 else i f aux . e rased and metainf . c o r r e c t and l a s t e r a s e d not equal po in t e r18 i f l a s t e r a s e d equal l a s t i n t e n d e d e r a s e19 OK;20 else21 e r a s e n e x t b l o c k ;22 end i f ;23 end i f ;24 end i f ;25 end loop ;

40

Capıtulo 6

SISTEMA DE VALIDACION DESOFTWARE

Uno de los aspectos cruciales en el desarrollo de sistemas de tiempo real es la va-lidacion temporal [8, 2] y logica de los mismos. Para llevarla a cabo han de analizarselos subsistemas por separado y el sistema en conjunto para asegurar su planificabi-lidad y correccion. Por las propias limitaciones de su naturaleza, los satelites son,dentro de los sistemas de tiempo real, en los que mayor relevancia si cabe adquiereeste proceso de validacion, debido a la gran dificultad de su modificacion una vezlanzados.

Igualmente, los satelites ofrecen una dificultad anadida: en el caso general resul-tan imposibles de testar en el ambiente de operacion. La disminucion de la atracciongravitatoria, la radiacion mas alla de la atmosfera o la influencia del campo magneti-co terrestre son algunos de los aspectos difıciles de emular fısicamente. Por tanto, serequiere del uso de tecnicas mas avanzadas que la propia reproduccion fısica de estascondiciones para la validacion de los subsistemas implicados por estas condicionesambientales. En este capıtulo se describe el sistema de validacion de software (SVF)configurado para la validacion de uno de los subsistemas basicos del satelite, el sis-tema de determinacion y control de actitud [9] (o ADCS por sus siglas en ingles deAttitude Determination and Control System) encargado de controlar la orientaciondel satelite respecto a la Tierra.

41

6.1. Sistema de determinacion y control de actitud en el UPMSat-2

6.1. Sistema de determinacion y control de acti-

tud en el UPMSat-2

Uno de los sistemas mas importantes para la operacion de un satelite es el controlde actitud del mismo. La actitud de un satelite es la orientacion de este haciael planeta Tierra. En cualquier satelite esta orientacion es basica para la correctaorientacion de las antenas para la comunicacion con tierra y tambien para ofrecer lamaxima superficie de paneles solares a la luz solar para obtener la energıa necesariapara su operacion.

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

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

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

Mediante el calculo del horizonte terrestre.

Mediante la medida del campo magnetico terrestre.

Las dos primeras opciones requieren el uso de informacion grafica para su usoy sus algoritmos son mas complejos. Sin embargo, en el caso del calculo del campomagnetico terrestre unicamente se requieren tres pares de magnetopares y un modelodel campo magnetico para su cotejo con las lecturas de los magnetometros. Estosmagnetometros obtienen una medida en tres ejes, suficiente para calcular de formacompleta el angulo de orientacion hacia la tierra. Este ultimo metodo es el usado enel UPMSat-2.

La computacion de los datos obtenidos se lleva a cabo por el codigo autogeneradopor la herramienta de diseno Simulink1. Este codigo se ha generado a partir delmodelo [3, 12, 11] mostrado en la figura 6.1. Este codigo, generado en C, se importa

1Simulink es una marca registrada de The MathWorks Inc.

42

6.1. Sistema de determinacion y control de actitud en el UPMSat-2

al codigo Ada mediante los mecanismos ofrecidos por el kernel. Mediante este codigose calcula la orientacion actual del satelite y si es necesario ejercer algun tipo deaccion para corregirla. El tiempo de ejecucion y la correccion de los datos de salidagenerados por este codigo son el objeto de validacion del sistema presentado en estecapıtulo.

gravitygradient"torque"

perturbation"torque"

PM dipole"

Earth magnetic

field"

Spacecraft dynamics"

1

1

cross product" 1

controller!1

B_dot"

B_b_T"

T_pm"

T_perturbation"

quaternion"

T_Nm"

I_A"

pqr_rad/s"

omega_rad/s"

C_BV"

Figura 6.1: Modelo del sistema de determinacion y control de actitud.

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

Los mecanismos activos consisten en tres magnetopares (uno por eje, al igual quelos magnetometros). Estos magnetopares son pares de bobinas de cobre recubierto

43

6.2. Sistema de Validacion de Software para el ADCS del UPMSat-2

de kapton que generan un campo magnetico propio que interactua con el campomagnetico terrestre haciendo girar al satelite sobre su propio eje.

El campo magnetico, por su naturaleza, fluctua a lo largo de la trayectoria orbitaldel satelite, siendo esta fluctuacion maxima en las regiones polares, donde tanto laintensidad como el angulo del campo magnetico varıan rapidamente. De igual modo,ciertas fluctuaciones sobre el modelo teorico se producen sobre ciertas regiones delglobo, debido a la tectonica de placas y los materiales existentes en esas regiones. Portanto, para que la validacion del software sea concluyente debe, al menos, abarcarla simulacion de una orbita completa.

6.2. Sistema de Validacion de Software para el

ADCS del UPMSat-2

Para la validacion del sistema de determinacion y control del sistema se ha hechouso de la tecnica de hardware-in-the-loop (HIL). Esta tecnica resulta de gran utilidadpara los sistemas empotrados de tiempo real y consiste en la validacion del sistemaa testear frente a un entorno fısico simulado en lugar del real en el que ejecutaran.

La figura 6.2 ilustra la configuracion del entorno de simulacion usado. En el, elcodigo autogenerado por Simulink se ejecuta en una version de desarrollo del compu-tador de abordo, mientras que el resto de parametros relativos al sistema de controlson simulados por Simulink en un PC. La interfaz entre ambos sistemas es la simu-lacion de los sensores y actuadores del sistema (magnetometros y magnetopares).De este modo, el sistema de control opera con valores lo mas verıdicos posible comosi estos proviniesen de los dispositivos reales y los actuadores operaran realmente.

Spacecraft model!

sensors!

actuators!

ADCS controller!

Simulation computer! On-board computer!interface!

Figura 6.2: Configuracion del sistema de validacion del ADCS.

44

6.2. Sistema de Validacion de Software para el ADCS del UPMSat-2

Listado 6.1: Implementacion de la funcion punto de interrupcion.

1 procedure Ipo in t ( Id : Natural ) i s2 begin3 t r a c e b u f f e r ( t r a c e i d x ) . ident := Id ;4 t r a c e b u f f e r ( t r a c e i d x ) . timestamp := Ada . Real Time . Clock ;5 t r a c e i d x := t r a c e i d x + 1 ;6 end Ipo in t ;

Para la comunicacion entre el computador de desarrollo y el PC se hace uso deuna lınea serie (el tiempo empleado en esta comunicacion no es tenido en cuentapara el analisis temporal).

En el ambito del analisis temporal, el dato de mayor interes para la validacion esel calculo de peor tiempo de computo o WCET (Worst Case Execution Time) [14].Para ello se ha hecho uso de la herramienta RVS de Rapitime2. Esta herramientaanaliza la estructura del codigo fuente y anade, en los lugares relevantes, puntos deinstrumentacion consistentes en llamadas a una funcion que registra la ejecucion deestos puntos. Para ello se almacena un identificador del punto de funcion y el relojdel sistema en el momento en el que este se ejecuto, como muestra el listado 6.1. Deeste modo se puede obtener el tiempo entre pasos por cada punto de instrumentacionpara analizar el comportamiento temporal del sistema. Para que esta informacionsea significativa, el codigo ha de ser ejecutado un alto numero de veces (dependientede la complejidad del sistema) a fin de que el mismo se testee bajo el mayor numerode entradas y estados posibles, a fin de recorrer todas los caminos posibles. En elcaso del satelite, como se ha adelantado, al menos una orbita completa ha de sersimulada para cubrir las diferentes situaciones posibles. Esto significa que, con unaorbita de 1.64 horas, al menos 5930 iteraciones del sistema de control se ejecutaranen el proceso de validacion.

Dado que la instrumentacion por defecto de Rapitime envıa la traza vıa lıneaserie, lo cual no es adecuado para nuestro entorno de validacion, se ha requeridomodificar esta funcion. En lugar de enviar los datos por la lınea serie, estos se alma-cenan en memoria y son extraıdos tras la finalizacion de la simulacion. Estos datosson posteriormente analizados por Rapitime para ofrecer el analisis temporal desea-do. Este contiene, ademas del peor tiempo de computo, otra informacion estadısticasobre la ejecucion, como los caminos recorridos, la distribucion de probabilidad deestos caminos, la distribucion de probabilidad sobre los tiempos de computo, etc.Toda esta informacion permite realizar un analisis detallado de la ejecucion quepermite la optimizacion del codigo.

2http://www.rapitasystems.com

45

6.3. Resultados

Figura 6.3: Etapas del analisis del peor tiempo de computo mediante Rapitime.

Con respecto a la validacion logica del sistema, Simulink almacena igualmenteun registro de los datos entrantes y salientes a los sensores y actuadores, cuyos datosson analizados por los ingenieros aeronauticos (disenadores del sistema de control)con el fin de comprobar su correccion.

6.3. Resultados

Una vez ejecutada la simulacion de una orbita completa3, con sus 5930 itera-ciones del codigo del controlador, se extrajo la traza de ejecucion de puntos deinstrumentacion de la memoria de la placa de desarrollo, obteniendo los resultadosmostrados en la figura 6.4 respecto al tiempo de computo del controlador. En lafigura se muestran los cuatro tiempos mas relevantes obtenidos: el mınimo tiempo de

3Debido a que la version de desarrollo del computador de abordo no disponıa en el momentode desarrollo de esta seccion, el sistema expuesto se implemento sobre un computador LEON2, desimilares caracterısticas a la especificacion preliminar del computador de abordo. El computadorLEON2 sintetizado a 40Hz sobre el que se desarrollaron las pruebas dispone de un pipeline de 5etapas en lugar de las 7 del LEON3 y no dispone de cache. En cualquier caso, el proceso presentadoy llevado a cabo en el test serıa identico en el caso del computador de abordo real.

46

6.3. Resultados

ejecucion del controlador (Min-SelfET), el tiempo medio de ejecucion (A-SelfET),el maximo tiempo tiempo de ejecucion observado (Max-SelfET) y el peor tiempode computo esperable (W-SelfET). Dado que el codigo del controlador no contienebucles o iteraciones, este peor tiempo de computo esperable coincide con el mayortiempo observado, al haberse obtenido el peor tiempo empırico en la ejecucion delpeor camino posible teorico. En el caso de que esto no hubiera sido ası, el peor tiem-po esperable se hubiera correspondido a la suma de los peores tiempos de computode cada segmento de codigo del peor camino detectado.

Figura 6.4: Resultados del analisis del controlador mediante Rapitime.

Observando la figura vemos que el mınimo tiempo de computo es de 201,3µs,mientras que el peor tiempo esperable es de 210,0µs, una diferencia bastante bajarelativa a la duracion de la ejecucion. Esto es debido a que en el test, para obtenerel peor tiempo propio unicamente del controlador, este se ejecuto unicamente enconcurrencia con el propio kernel, y por tanto, la unica variabilidad, a parte de losdatos de entrada, radica en la posibilidad de la llegada de una interrupcion de relojy que esta a su vez pueda provocar un fallo en la ventana de registros. A pesarde que en el sistema real podra tener las interrupciones y desalojos de otras tareasmas prioritarias, como se explico, con el peor tiempo de computo es suficiente paraanalizar la planificabilidad del sistema. En cualquier caso, esta planificacion (y lacorreccion logica) se verificaran en el sistema completo final.

Igualmente, Rapitime reporta una distribucion de probabilidades del tiempo decomputo del controlador. En ella, la probabilidad de ocurrencia del peor tiempoes realmente baja, apenas 1,69 · 10−4 siendo mucho mas probable las ocurrenciasentorno al tiempo medio de computo, 206,9µs. Si bien el sistema de control de actitudes basico para la operacion y supervivencia del satelite, dadas las implicaciones fısicasdel controlador y su frecuencia de ejecucion, es permisible que en algun caso aisladono se cumpla su plazo y por ello es interesante conocer la probabilidad de ocurrenciadel peor caso (que en cualquier caso deberıa ser mucho mayor de la probabilidadde perder un plazo, ya que para ello, con una planificacion adecuada, deberıan

47

6.3. Resultados

Figura 6.5: Distribucion de probabilidad de tiempo de computo del controlador.

combinarse otras situaciones poco probables, como la ocurrencia de peores tiemposde computo en tareas de mayor prioridad, eventos asıncronos, etc.).

48

Capıtulo 7

CONCLUSIONES Y TRABAJOFUTURO

El proyecto UPMSat-2 esta resultando de un altısimo interes a nivel investigadoren el ambito de la Universidad Politecnica de Madrid, y buena prueba de ello es elnumero de publicaciones, trabajos fin de carrera y tesis doctorales que de el estansurgiendo. En este entorno investigador del UPMSat-2 se enmarca la aportaciondescrita en la presente memoria. Esta queda resumida en los siguiente hitos:

Se ha adaptado el manejador para lınea serie existente al computador de abor-do del UPMSat-2, lo cual permitira el envıo de datos al modulador para lacomunicacion con tierra y con los experimentos de abordo.

Se ha disenado e implementado un manejador del bus SPI, que pasa a engrosarel numero de mecanismos de comunicacion que ofrece la plataforma ORK.Mediante este bus se podra comunicar con el conversor analogico-digital parael procesamiento de las senales analogicas del satelite.

Se ha disenado e implementado un manejador para el conversor analogico-digital LTC2498 de Linear Technology. Mediante este dispositivo se podrandigitalizar las senales analogicas del satelite para su posterior procesamiento.Tales senales pueden ser el estado de las baterıas, las medidas de temperaturas,medidas de los magnetopares, etc.

Se ha desarrollado un algoritmo para el mantenimiento de la consistencia dememoria no volatil en un sistema de tiempo real con requisitos de toleranciaa fallos para memorias de tipo flash.

49

Se ha adaptado el estado del arte en tecnicas de prueba de sistemas empo-trados a un entorno de validacion software para el codigo autogenerado porherramientas de diseno de sistemas de control. Se ha demostrado la validezdel enfoque hardware in the loop para su uso en la validacion del software delsatelite.

Durante el desarrollo de este trabajo se han encontrado diferentes dificultadesasociadas a la magnitud, interdisciplinaridad y complejidad del proyecto. Cambiosen la especificacion del software y hardware (del cual como se ha expuesto se de-pendıa altamente en las tareas realizadas), aparicion de nuevos requisitos asociadosa experimentos de abordo, desaparicion o modificacion de los ya existentes haciendoinfructuoso el trabajo ya realizado, etc. Del mismo modo, cabe la posibilidad de queen un futuro las especificaciones sobre el trabajo realizado varıen. Para minimizarlos efectos de estas variaciones se ha tenido muy en cuenta la posible reutilizaciondel material generado.

Es virtud del ingeniero el hacer uso del conocimiento previo para obtener unosuperior, ası como facilitar el acceso a este a futuros interesados. En el caso de losmanejadores de dispositivos, si bien estos son muy dependientes del hardware, tantola arquitectura software elegida como los algoritmos implementados son facilmentecomprensibles y mantenibles, a la vez que adaptables a las necesidades futuras.

Claro ejemplo es la reutilizacion del driver previo de la lınea serie, en el cuala parte de su individualizacion frente al esquema DUART precedente, las modi-ficaciones requeridas por el proyecto han consistido casi de forma exclusiva en laadecuacion de las interrupciones al nuevo procesador.

En el caso del driver para el bus SPI, al ser este un estandar de comunicaciones,para su reutilizacion solo serıa necesaria la modificacion de la estructura de losregistros, especıfica de cada fabricante de controladores.

En el caso del conversor analogico-digital, manteniendo el uso del mismo modelono serıa necesaria modificacion alguna, ya que hace uso de la interfaz de alto niveldel controlador del bus SPI, generica para estos dispositivos.

En relacion al algoritmo de gestion de la memoria no volatil del satelite, si bien sehan tenido en cuenta las necesidades especıficas del UPMSat-2, el algoritmo presen-tado es perfectamente adaptable para su uso en cualquier otro dispositivo de tiemporeal con las restricciones y requisitos de fiabilidad que estos presentan.

Finalmente, el entorno de validacion de software aplicado al sistema de controlde actitud del satelite supone un metodo eficiente y reproducible para la validacionde sistemas embebidos en los cuales no es posible su validacion en el propio entorno

50

real en el cual operaran. Este entorno servira de base para el definitivo, de mayorcomplejidad ya que debera abarcar el sistema completo.

Las proximas etapas del proyecto consistiran en el diseno y desarrollo de aquellosmanejadores aun no producidos. Igualmente se debera desarrollar el software de altonivel del satelite. Del mismo modo se debera evolucionar el entorno de validacionpara la validacion del sistema completo. Finalmente se debera llevar a cabo la inte-gracion y validacion de los resultados del trabajo presentado con el resto de sistemasdel satelite, una vez recibido el modelo de ingenierıa del computador de abordo.

51

Bibliografıa

[1] Ada Reference Manual ISO/IEC 8652:1995(E)/TC1(2000)/AMD1(2007),2007. Available at http://www.adaic.com/standards/ada05.html.

[2] Neil Audsley, Alan Burns, Rob Davis, Ken Tindell, and Andy J. Wellings. Fixedpriority preemptive scheduling: An historical perspective. Real-Time Systems,8(3):173–198, 1995.

[3] Matteo Bordin and Tullio Vardanega. Automated model-based generation ofRavenscar-compliant source code. In Proc. 17th Euromicro Conference on Real-Time System, ECRTS ’05, pages 59–67, Washington, DC, USA, 2005. IEEEComputer Society.

[4] Alan Burns, Brian Dobbing, and Tullio Vardanega. Guide for the use of theAda Ravenscar profile in high integrity systems. Ada Letters, XXIV:1–74, June2004.

[5] Juan A. de la Puente, Jose F. Ruiz, and Juan Zamorano. An open Ravenscarreal-time kernel for GNAT. In Hubert B. Keller and Erhard Plodereder, editors,Reliable Software Technologies — Ada-Europe 2000, number 1845 in LNCS,pages 5–15. Springer-Verlag, 2000.

[6] Gaisler Research. LEON3 Product Sheet, 2008.

[7] Marko Isom ki Kritoffer Glembo Sandi Habinc Jiri Gaisler, Edvin Catovic. Grlibip core user’s manual. Gaisler Research, 2007.

[8] Mathai Joseph and Paritosh K. Pandya. Finding response times in real-timesystems. BCS Computer Journal, 29(5):390–395, 1986.

[9] Alejandro Alonso Juan A. de la Puente, Juan Zamorano and Daniel Brosnan.A real-time computer control platform for an experimental satellite. Jornadasde Tiempo Real - JTR-2012, 2012. Available at http://www.ctr.unican.es/jtr12/programme.html.

52

http://www.adaic.com/standards/ada05.html

http://www.ctr.unican.es/jtr12/programme.html

http://www.ctr.unican.es/jtr12/programme.html

Bibliografıa

[10] Juan A. de la Puente Juan Zamorano, Jorge Lopez. Guidelines for integratingdevice drivers in the assert virtual machine. ESA/ESTEC, 2009.

[11] Enrico Mezzetti, Marco M.Panunzio, and TullioVardanega. Preservation of ti-ming properties with the Ada Ravenscar profile. In Jorge Real and Tullio Var-danega, editors, Reliable Software Technologies — Ada-Europe 2010, number6106 in LNCS, pages 153–166. Springer-Verlag, 2010.

[12] Jose Pulido, Juan A. de la Puente, Matteo Bordin, Tullio Vardanega, andJerome Hugues. Ada 2005 code patterns for metamodel-based code genera-tion. Ada Letters, XXVII(2):53–58, August 2007. Proceedings of the 13thInternational Ada Real-Time Workshop (IRTAW13).

[13] Jose F. Ruiz. GNAT Pro for on-board mission-critical space applications. InTullio Vardanega and Andy Wellings, editors, Reliable Software Technologies— Ada-Europe 2005, volume 3555 of LNCS. Springer-Verlag, 2005.

[14] Reinhard Wilhelm, Jakob Engblom, Andreas Ermedahl, Niklas Holsti, StephanThesing, David Whalley, Guillem Bernat, Christian Ferdinand, Reinhold Heck-mann, Tulika Mitra, Frank Mueller, Isabelle Puaut, Peter Puschner, Jan Stas-chulat, and Per Stenstrom. The worst-case execution-time problem—overviewof methods and survey of tools. ACM Trans. Embed. Comput. Syst., 7(3):1–53,2008.

53

Indice general - UPMstr/proyectos/upmsat2/doc/Jorge_Garrido-TFG.pdf · ACRONIMOS Y S IMBOLOS ADC...

Documents

Transcript of Indice general - UPMstr/proyectos/upmsat2/doc/Jorge_Garrido-TFG.pdf · ACRONIMOS Y S IMBOLOS ADC...