Arquitectura de Software1

5/21/2018 Arquitectura de Software1

1/82

Universidad Politcnica de MadridEscuela Tcnica Superior de Ingenieros de Telecomunicacin

DISEO DE LA ARQUITECTURA SOFTWARE DELSISTEMA DE A BORDO DEL SATLITE UPMSAT-2

TRABAJO FIN DE MSTER

Jorge Garrido Balaguer

2013


2/82


3/82

Universidad Politcnica de MadridEscuela Tcnica Superior de Ingenieros de Telecomunicacin

Mster Universitario enIngeniera de Redes y Servicios Telemticos

TRABAJO FIN DE MSTER

DISEO DE LA ARQUITECTURA SOFTWARE DELSISTEMA DE A BORDO DEL SATLITE UPMSAT-2

AutorJorge Garrido Balaguer

DirectorAlejandro Alonso Muoz

Departamento de Ingeniera de Sistemas Telemticos

2013


4/82

i

!"#$%"&

A lo largo de la historia del software, tanto la industria como posteriormentetambin la comunidad cientfica han perseguido una metodologa definitiva para eldiseo e implementacin de los sistemas informticos. Sin embargo, mltiples son losejemplos de estas metodologas que durante estas ltimas dcadas han sidopropuestas, estandarizadas, desarrolladas herramientas para implementarlas yfinalmente abandonadas. Mltiples son tambin las causas del fracaso de cada una deellas, siendo el exponencial crecimiento de la industria y sus crecientes necesidadesfactor comn en el abandono de cada una de las propuestas.

Los sistemas de tiempo real y sistemas empotrados, si bien se caracterizan por losespeciales requisitos funcionales y no funcionales, tambin presentan necesidadesespeciales en su ciclo de vida. Ya sea por necesidades del servicio, o por mandato denormativas al respecto, tambin el diseo y el desarrollo de estos sistemas deben seguirun especial proceso para su validacin.

La Agencia Espacial Europea, como lder en este tipo de sistemas puso en marcha en2004 un proyecto denominado ASSERT (Automated proof-based System and SoftwareEngineering for Real-Time systems), cuyo principal propsito era el estudio ypropuesta de una metodologa especfica para el diseo y desarrollo de estos sistemas.

Posteriormente, este proyecto fue ampliado con el proyecto TASTE (The Assert Set ofTools for Engineering), cuyo objetivo era la implementacin de un entorno dedesarrollo que permitiera la puesta en prctica de la metodologa propuesta enASSERT.

La presente memoria recoge el trabajo realizado por el autor en el proceso de diseoe implementacin del software del satlite UPMSat-2 mediante el uso de lametodologa ASSERT/TASTE.

El proyecto UPMSat-2 es un proyecto de la Universidad Politcnica de Madrid quetiene por objetivo el diseo, implementacin, lanzamiento, operacin y mantenimiento

de un microsatlite que sirva de plataforma de demostracin y validacin de diversosdispositivos y experimentos.


5/82


6/82

iii

()#*+,-*

During the last three decades, methodologies for designing and developingsoftware have been proposed, implemented and abandoned endlessly. Time-to-marketrequirements, budgets constraints and a voracious industry have continuously led tonew methodologies, based on different paradigms without finding a final solution forgeneral software lifecycles.

Real-time and embedded systems are not only special in the functional and no-functional requirements of the final implementations of the systems. Furthermore,specific methodologies and thorough quality processes comprising the full systemlifecycle are many times required by standards and normative for these systems to bevalidated.

The European Space Agency, as a leader in this kind of systems, launched in 2004 anambitious project, called ASSERT (Automated proof-based System and SoftwareEngineering for Real-Time systems), aimed to propose a specific methodology fordeveloping real-time embedded systems. Furthermore, after the success of the former

project, a new project was launched to provide a developing environment where theASSERT process was easily followed. As a result, TASTE, The Assert Set of Tools forEngineering was developed.

This report reflects and summarizes the work done by the author in the design andimplementation of the UPMSat-2 software. The UPMSat-2 is a project of theUniversidad Politcnica de Madrid, leaded by the Ignacio da Riva Institute, aimed todesign, build, launch and operate an academic microsatellite. The Real-Time system

and Telematic Services Architecture group, of which the author is member, isresponsible of the design, implementation and maintenance of the software andtelecommunications system of the satellite.


7/82


8/82

v

.&/0-" 1"&"+,2

Resumen ................................................................................................................................... i

Abstract ................................................................................................................................. iii

ndice general ......................................................................................................................... v

ndice de figuras .................................................................................................................. vii

ndice de tablas ...................................................................................................................... ix

ndice de listados ................................................................................................................... x

Siglas ....................................................................................................................................... xi

1 Introduccin ..................................................................................................................... 1

1.1 Contexto del trabajo ................................................................................................ 1

1.2 Motivacin ............................................................................................................... 2

1.3 Objetivos del trabajo ............................................................................................... 2

1.4 Estructura del documento ..................................................................................... 3

2 Revisin tecnolgica ....................................................................................................... 4

2.1 Ingeniera basada en modelos ............................................................................... 4

2.1.1 ASSERT - TASTE ............................................................................................. 5

3 Caractersticas del satlite UPMSat-2 ......................................................................... 10

3.1 Misin ..................................................................................................................... 10

3.2 Caractersticas del hardware ............................................................................... 12

3.3 Caractersticas del software del satlite UPMSat-2 .......................................... 13

4 Modelado de datos ....................................................................................................... 16

4.1 ASN.1 ...................................................................................................................... 16

4.2 ACN ........................................................................................................................ 18

4.3 Modelado de datos aplicado al UPMSat-2 ........................................................ 19

4.3.1 Telemetra y Telecomando en el satlite UPMSat-2 ................................. 19

4.3.2 Definicin de servicios del UPMSat-2. Telemetra y telecomando denivel de aplicacin. ........................................................................................................... 24


9/82

vi

5 Modelado de interfaces ................................................................................................ 38

5.1 Orchestrator ........................................................................................................... 41

5.2 Platform Monitoring ............................................................................................. 43

5.3 Payload Manager .................................................................................................. 495.4 Attitude Determination and Control System .................................................... 51

5.5 Telemetry and Telecommand System ................................................................ 52

6 Modelado de despliegue .............................................................................................. 56

7 Implementacin ............................................................................................................. 58

7.1 Evaluacin de la generacin de ejecutables en TASTE ................................... 58

8 Validacin ...................................................................................................................... 60

9 Conclusiones .................................................................................................................. 62

9.1 Trabajo futuro ........................................................................................................ 63

Bibliografa ............................................................................................................................ 65


10/82

vii

.&/0-" /" 301$+,#

Figura 1 Arquitectura software del satlite UPMSat-2................................................ 14

Figura 2 Estructura de paquetes de telemetra estandarizado por ECSS. ................ 21

Figura 3 Detalle del Packet Data Fieldde los paquetes de telemetra. ........................ 21

Figura 4 Estructura de paquetes de telecomando estandarizado por ECSS. .......... 21

Figura 5 Detalle del Packet Data Fieldde los paquetes de telecomando. ................... 22

Figura 6 Campos del Housekeeping Parameter Report. ............................................ 26

Figura 7 Campos del Event Reporting Service. ............................................................ 29

Figura 8 Campos del subservicio Load Memory using Absolute Addreses. ........... 33Figura 9 Campos del subservicio Dump Memory using Absolute Addreses. ........ 33

Figura 10 Campos del subservicio Memory Dump using Absolute Addreses. ...... 34

Figura 11 Campos del servicio Function Management. .............................................. 35

Figura 12 Diagarama de estados de operacin del satlite UPMSat-2. ..................... 37

Figura 13 Modelo de Interfaces del software de alto nivel del satlite UPMSat-2 .. 40

Figura 14 Funciones e Interfaces Provistas por el sistema Orchestrator. ................. 41

Figura 15 Funciones e Interfaces Provistas por el sistema Platform Monitoring. ... 44

Figura 16 Funciones e Interfaces Provistas por el sistema Payload Manager. ........ 50

Figura 17 Funciones e Interfaces Provistas por el sistema Attitude Determinationand Control System. ................................................................................................................. 52

Figura 18 Funciones e Interfaces Provistas por el sistema Telemetry and

Telecomunications System. ..................................................................................................... 53

Figura 19 Modelo de despliegue de las funciones en la plataforma de ejecucin. . 57

Figura 20 Contenido del directorio principal del proyecto tras la generacin

automtica de cdigo. .............................................................................................................. 59

Figura 21 Herramienta de validacin del sistema. ...................................................... 61


11/82


12/82

ix

.&/0-" /" *,)2,#

Tabla 1 Servicios definidos en el estndar ECSS-E-70-41A. ....................................... 25

Tabla 2 Interfaces Provistas por obc_orchestrator. ...................................................... 41

Tabla 3 Variables internas de obc_orchestrator. ........................................................... 42

Tabla 4 Interfaces Provistas por event_manager. ........................................................ 42

Tabla 5 Interfaces Provistas por housekeeping_manager........................................... 45

Tabla 6 Interfaces Provistas por analog_sensors. ......................................................... 47

Tabla 7 Interfaces Provistas por watchdog_timer. ....................................................... 48

Tabla 8 Interfaces Provistas por rt_clock. ...................................................................... 49

Tabla 9 Interfaces Provistas por payload_manager_1. ................................................ 50Tabla 10 Interfaces Provistas por cada gestor de experimento. ................................. 51

Tabla 11 Variables internas de cada gestor de experimento. ..................................... 51

Tabla 12 Interfaces Provistas attitude_control. ............................................................. 52

Tabla 13 Interfaces Provistas por cada tm_manager. .................................................. 53

Tabla 14 Variables internas de cada gestor de tm_manager. ..................................... 54

Tabla 15 Interfaces Provistas por cada tc_manager. .................................................... 54

Tabla 16 Variables internas de cada gestor de tm_manager. ..................................... 54

Tabla 17 Interfaces Provistas por cada AX.25. .............................................................. 55

Tabla 18 Variables internas de cada gestor de AX.25 .................................................. 55


13/82

x

.&/0-" /" 20#*,/4#

Listado 1 Extracto de la definicin de la estructura de un paquete de telecomando

mediante ASN.1. ....................................................................................................................... 24

Listado 2 Extracto de la definicin de codificacin en ACN de algunos de los tipos

declarados en el documento ASN.1. ...................................................................................... 24


14/82

xi

5012,#

AADL - Architecture Analysis and Design Language

AAS - Anomala del Atlntico Sur

ACN - ASN.1 Control Notation

ADC - Analog-Digital Converter

ADCS - Attitude Determination and Control System

ASN.1 - Abstract Syntax Notation One

ASSERT - Automated proof-based System and Software Engineering for Real-Timesystems

BCD - Binary Coded Decimal

BER - Basic Encoding Rules

bps - Baudios por segundo

CASE - Computer-Aided Software Engineering

CCSDS - Consultative Committee for Space Data Systems

CTM - Control trmicoEEPROM - Electrically Erasable Programmable Read-Only Memory

ECSS - European Cooperation for Space Standardization

ESA - Agencia Espacial Europea

ESTEC - European Space Research and Technology Centre

FIFO - First In First Out

FPGA - Field Programmable Gate Array

FPU - Floating Point Unit

GUI - Graphic User Interface

I2C - Inter-Integrated Circuit

IDR - Instituto Ignacio da Riva

ITU-T - International Telecommunication Union, TelecommunicationStandardization Sector

MARTE - Modeling and Analysis of Real-Time and Embedded systems


15/82

xii

MDA - Model Driven Architechture

MDE - Model-driven engineering

MGM - Magnetmetro

MHz - Megaherzios

MM - Magnetmetros

MRAD - Monitorizacin del efecto de la radiacin

MT - Magnetopares

MTS - MicroThermal Switch

OBC - On-Board Computer

OMG - Object Management Group

ORK - Open Ravenscar Real-time Kernel

PER - Packet Encoding Rules

PIM - Platform Independent Model

PSM Platform Specific Model

PUS - Packet Utilization Standard

SAE - Sociedad de Ingenieros de Automocin

SCT - Solar Cell Technology

SDL - Specification Description Language

SID - Source Identificator

SMA - Shape Memory Alloys

SOC - System On a Chip

SPARC - Scalable Processor ARChitecture

SPI - Serial Peripheral Interface

SRAM - Static Random Access Memory

SSS - software system specification

STRAST - Grupo de Sistemas de Tiempo Real y Arquitectura de ServiciosTelemticos

TASTE - The Assert Set of Tools for Engineering


16/82

xiii

TBD - To Be Defined

TC - Telecomando

TM - Telemetra

TMTC - Telemetra y telecomando

UART - Universal Asynchronous Receiver-Transmitter

UHF - Ultra High Frequency

UI - Unnumbered Information frame

UML - Unified Modelling Language

UPM - Universidad Politcnica de Madrid

VHDL - Combinacin de VHSIC y HDL, donde VHSIC es el acrnimo de Very HighSpeed Integrated Circuit y HDL es a su vez el acrnimo de Hardware DescriptionLanguage.

WCET - Worst Case Execution Time


17/82

1

6 7&*+4/$--08&

696

:4&*";*4 /"2 *+,),


18/82

2

69=

>4*0?,-08&

El trabajo expuesto en la presente memoria recoge el proceso llevado a cabo por elautor, apoyado por el resto del grupo de investigacin, para complementar labor del

grupo en el proyecto, diseando e implementando el software de alto nivel del satlite.

El mismo se ha llevado a cabo siguiendo metodologas y haciendo uso de lasherramientas de actualidad en el mbito de este tipo de sistemas, sirviendo dedemostracin para las mismas.

69@

A)


19/82

3

69B

C#*+$-*$+, /"2 /4-$%"&*4

La presente memoria se estructura de la siguiente manera: la seccin 2 presenta elestado de la tcnica en el diseo basado en modelos, y se realiza un pequeo estudio dela metodologa y conjunto de herramientas ASSERT/TASTE. En la seccin 3 seintroduce el proyecto UPMSat-2.

Las siguientes secciones abordan las diferentes fases del trabajo: la seccin 4presenta el trabajo realizado en el modelado de datos del satlite, incluyendo laaplicacin de los estndares pertinentes y la definicin de los servicios de a bordo. Laseccin 5 presenta el modelo de alto nivel del software del satlite, desarrollado en laherramienta, sirviendo de documentacin tambin del mismo. La seccin 6 presenta elmodelo de despliegue sobre la plataforma, la seccin 7 aborda la implementacin departe del software del satlite y la seccin 8 presenta un til mtodo de validacin delsistema.

Finalmente la seccin 9 presenta las conclusiones del trabajo realizado, lasdificultades encontradas en durante el desarrollo del mismo, as como lneas de trabajofuturo.


20/82

4

= !"?0#08& *"-&42810-,

=96

7&1"&0"+D, ),#,/, "& %4/"24#

La ingeniera basada en modelos (o Model-driven engineering, MDE [2]) es unametodologa de desarrollo de software enfocada a la generacin de modelos como basedel diseo de software. Estos modelos son abstracciones de las actividades, objetos yentidades involucradas en un determinado mbito donde el software debe desarrollaruna funcin concreta.

El objetivo de esta metodologa es maximizar la compatibilidad entre sistemas y lareduccin de costes, al reusar modelos estandarizados, simplificar el proceso de diseo,aplicando patrones al dominio y generar un ambiente de colaboracin entredesarrolladores, dada la facilidad ofrecida para la reutilizacin.

La metodologa MDE est claramente influenciada por las herramientas conocidascomo CASE (Computer-Aided Software Engineering) desarrolladas en los 80s. En laactualidad existe una organizacin, el Object Management Group (OMG)4, que desde2001 trata de unificar procesos y lenguajes de esta nueva tendencia bajo la definicin deModel Driven Architechture (MDA).

MDA sigue el concepto de abstraccin del modelo a la plataforma tecnolgica quesoporte la solucin. Para ello se debe generar un modelo de dominio, tambin conocidocomo modelo independiente de plataforma o PIM (Platform Independent Model). Estemodelo debe representar nicamente lgica de negocio. Este modelo debe completarsecon un modelo especfico de la plataforma, o Platform Specific Model (PSM), en el cualse aplica el modelo de dominio a un modelo de plataforma concreto, obtenindose asun modelo completo a partir de diferentes abstracciones reutilizables.

A pesar de los esfuerzos por parte de la OMG de estandarizar y unificar lasmetodologas basadas en modelos, su enfoque, centrado en un nico lenguaje (UML,

Unified Modelling Language), no ha sido uniformemente adoptado en todos losmbitos de la industria del software y de la informtica en general. Uno de los mbitosen los cuales han surgido alternativas a esta metodologa es la industria de los sistemasempotrados y de tiempo real.

Los sistemas informticos empotrados son aquellos que operan como una parte deun sistema ingenieril ms grande al cual supervisan y controlan. Es el caso del sistemainformtico del satlite UPMSat-2, en el cual el valor no reside en el sistemainformtico sino en sistema ms amplio, el satlite. La interaccin entre ambos sistemas

4www.omg.org


21/82

5

se lleva a cabo por medio de sensores y actuadores, dispositivos de hardware quepermiten analizar el comportamiento del sistema y operar sobre l.

Los sistemas de tiempo real son sistemas que se caracterizan por sus requisitostemporales. En ellos, su correcto funcionamiento no slo depende de la correccin

lgica del resultado, sino tambin del instante de tiempo en el que se manifiesta. Deeste modo, un resultado lgicamente correcto obtenido fuera del plazo de respuesta noes vlido. Un ejemplo sencillo de un sistema de tiempo real es el ABS de un coche. Estesistema debe accionar y liberar el freno de cada rueda cuando se realiza un frenazo, yun retraso de centsimas de segundo puede hacer que la rueda patine y el vehculocolisione.

Estos tipos de sistemas tienen caractersticas y requisitos diferentes de los sistemasinformticos convencionales. A pesar de que UML ofrece una extensin para elmodelado de estos sistemas, MARTE (Modeling and Analysis of Real-Time and

Embedded systems) [3], determinados sectores de la industria decidieron desarrollarsus propias metodologas y herramientas para el facilitar el ciclo de vida de estossistemas. Un importante actor en el sector que tom esta iniciativa fue la AgenciaEspacial Europea (ESA).

=9696 (55C!E F E(5ECEl proyecto ASSERT[4,5](Automated proof-based System and Software Engineering

for Real-Time systems), liderado por la Agencia Espacial Europea y formado por un

consorcio de 28 socios del sector aeroespacial tuvo como principal objetivo eldesarrollo de mtodos ms fiables y robustos para el desarrollo de sistemas desoftware embarcado. Esta metodologa se conoce como ASSERT process, siendo unconjunto de mtodos y directrices con los que abordar el desarrollo, dirigido pormodelos, de software embarcado que asegure su validez respecto a la especificacin derequisitos.

TASTE es un conjunto de herramientas de cdigo abierto para el desarrollo desistemas empotrados y de tiempo real. Estos sistemas suelen tener requisitos de tiemporeal crtico y, como parte de su validacin, hay que realizar un anlisis deplanificabilidad para demostrar que tendrn un comportamiento temporal correcto.TASTE incluye un conjunto de restricciones que aseguran que los sistemasdesarrollados son compatibles con el perfil de Ravenscar [6,7]. El perfil de Ravenscar esun conjunto de restricciones a la parte concurrente del lenguaje de programacin Ada,a fin de que el cdigo generado sea analizable temporalmente y tenga uncomportamiento determinista. Aunque se defini originalmente para el lenguaje Ada,su modelo computacional se puede extrapolar a otros paradigmas de programacinconcurrente como POSIX.

El conjunto de herramientas TASTE est enfocado al desarrollo basado en modelos[2], siguiendo la metodologa desarrollada en el proyecto ASSERT. En ella se describenlas siguientes fases:


22/82

6

Modelado del sistema.

Transformacin del sistema modelado a una arquitectura software detiempo real.

Anlisis de factibilidad del sistema.

Generacin automtica de cdigo, implementacin y compilado Validacin de la implementacin del sistema.

En las siguientes subsecciones se presentan en mayor detalle cada una de estas fasesy las tecnologas implicadas en cada una de ellas.

!"#$ &$ '(&$)"&(

La primera fase del desarrollo propuesta por TASTE es el modelado del sistema. Elobjetivo de esta fase es generar un modelo homogneo para el sistema en su conjunto,

obviando la naturaleza heterognea del hardware y los artificios software necesariospara su implementacin. El proceso de modelado por tanto debe basarse nicamenteen una arquitectura software preliminar como la presentada en la figura 1, fruto delanlisis conjunto del sistema objetivo por parte de los ingenieros del sistema y expertosen software.

Esta fase del proceso es posiblemente la ms compleja. Por ello, se hace uso dediversos lenguajes como se presentar a continuacin.

El nexo de unin entre los diferentes lenguajes usados el desarrollo es AADL(Architecture Analysis and Design Language), un lenguaje de descripcin dearquitecturas estandarizado por la Sociedad de Ingenieros de Automocin (SAE).AADL est definido por un ncleo del lenguaje que define una notacin nica tantopara caractersticas de hardware, software y comportamiento del sistema. AADLpresenta una gran flexibilidad a la hora de modelar sistemas concretos, al podersedeclarar caractersticas especficas usando propiedades (properties en el lenguaje).Adems, AADL se puede extender mediante dos mtodos: extendiendo el conjunto depropiedades del sistema con propiedades definidas por el usuario y mediante laadicin de anexos al lenguaje. Por el momento existen cuatro anexos, todos ellosrelevantes en el mbito de los sistemas que se pretende desarrollar con TASTE:

Behaviour annex, que incluye soporte para mquinas de estados. Error-model annex, que especifica diversos aspectos sobre el tratamiento y

propagacin de errores.

ARINC653 annex, que define patrones de modelado para sistemas deavinica.

Data-Model annexpara el modelado de tipos de datos mediante AADL.

Sin embargo, el conocimiento del lenguaje AADL no es necesario para el usuario deTASTE, ya que, aunque es posible hacerlo, no es necesario manipularlo directamente.

Por contra, las diferentes herramientas de modelado transforman automticamente a


23/82

7

AADL las caractersticas del sistema especificadas por el usuario a medida que seeditan los diferentes modelos o vistas.

Las vistas son, en el conjunto de herramientas de TASTE, cada una de lasabstracciones para el modelado del sistema. Existen cuatro: Data view, Interface view,

Deployment view y Concurrency view.

Data view: en un primer paso se propone modelar los tipos de datos a usar enel sistema. Si bien slo se exige estrictamente el modelado de aquellos datosque se vayan a usar posteriormente como parmetros en las diferentesinterfaces, resulta altamente recomendable le especificacin temprana detodos aquellos tipos a usar relacionados con la lgica del sistema. Estaespecificacin es abstracta y no impide que cada mdulo de software use lostipos propios del lenguaje en el que finalmente se implemente.El lenguaje seleccionado en TASTE para llevar a cabo el proceso de

modelado fue ASN.1 [8]. ASN.1 es un lenguaje estandarizado por ISO y laITU-T que permite el modelado de tipos y estructuras de datos, tanto desdeel punto de vista semntico como de codificacin. Las especificacionesgeneradas mediante ASN.1 son independientes de los lenguajes deprogramacin, de las plataformas hardware e incluso de la codificacin delas estructuras de datos definidas. ASN.1 se encarga por defecto de generaruna codificacin ptima a los tipos especificados. Sin embargo, tambin esposible, mediante la extensin ACN, definir el formato de codificacin anivel de bit. Esta cualidad resulta de alto inters en este tipo de sistemas, enespecial para el manejo de las interfaces con sensores y actuadores.

Interface view: en un segundo paso se propone el modelado de las interfacessoftware mediante la vista de interfaz. Haciendo uso de una herramientagrfica, se definen las diferentes funciones del sistema. Estas funcionespueden ser agrupadas en contenedores, que si bien no representan ningunainformacin efectiva, hacen ms sencilla e intuitiva la edicin del modelo.Las interacciones entre funciones se modelan mediante interfaces provistas yrequeridas. Estas ltimas se caracterizan por un conjunto de propiedades nofuncionales (entre ellos los requisitos temporales de la tarea). Este conjuntode propiedades no funcionales depende del tipo de tarea que representen.

As, por ejemplo, en el caso de tareas cclicas se ha de definir su periodo,mientras que el caso de tareas espordicas se debe dar un valor de tiempomnimo entre llegadas.Del mismo modo que en el caso de la edicin del modelo de datos el modelose convierte a AADL siendo accesible para uso en el resto de herramientasdel entorno.

Deployment view: Una vez definidas las diferentes funciones de software ysus dependencias entre ellas se debe proceder a describir la arquitecturahardware del sistema. Mediante una herramienta grfica similar a lautilizada en el paso anterior se despliegan diferentes elementos sobre el

modelo. Los dos elementos bsicos de este modelo son los Processor Boardsylos busesque interconectan a los primeros entre s. Cadaprocessor board tiene


24/82

8

al menos un procesador (caracterizado por su arquitectura) y un mdulo dememoria principal. Adicionalmente, un processor board puede tener ms deun mdulo de procesador o memoria, adems de varios mdulos de Driversmediante los cuales se conecta a los diferentes buses. Dentro de cadaprocesador se define al menos una particin, caracterizada por el sistemaoperativo o ncleo que ejecutar sobre ella. Finalmente, el usuario asigna lasfunciones software declaradas en la Interface view a las particiones en lasque se desplegarn.

Concurrency view: analizando automticamente los modelos generados tantoen el Interface view como el Deployment view, TASTE genera una nuevaespecificacin AADL que recoge las caractersticas de concurrencia yrendimiento del sistema, pudiendo analizar al planificabilidad del mismomediante la herramienta integrada Cheddar5.

*$+$,"-./+ &$ -/&.0(

Una vez modelados los diferentes mdulos o funciones software del sistema en laInterface view, TASTE permite generar automticamente tanto los esqueletos de cdigode cada funcin como los scripts necesarios para su posterior compilacin. De igualmodo, genera las definiciones de los tipos declaradas en el Data viewpara cada uno delos diferentes lenguajes soportados por TASTE. Estos lenguajes son los siguientes:

SDL (Specification Description Language)[15], lenguaje de especificacin desistemas complejos mediante la comunicacin entre mdulos independientes

por medio de seales. SDL est estandarizado por la ITU-T en el estndarZ.100.

Simulink6, un entorno de modelado, simulacin y anlisis de sistemasdinmicos. TASTE permite la implementacin de funciones mediantemodelos generados con esta herramienta.

Ada [11], lenguaje de programacin orientado a objetos y fuertementetipado, usado principalmente en el entorno de los sistemas de tiempo real ysistemas empotrados.

C, lenguaje de programacin de propsito general.

SCADE7

, herramienta de diseo y modelado de aplicaciones de altacriticidad para sistemas empotrados.

Adems de estos lenguajes para la implementacin de software, las funciones de laInterface view pueden ser declaradas con otros lenguajes. Uno de ellos es VHDL,permitiendo dentro del propio entorno definir elementos hardware en este lenguaje,integrados con el resto del sistema.

5 http://beru.univ-brest.fr/~singhoff/cheddar/6http://www.mathworks.es/products/simulink/7 http://www.esterel-technologies.com/products/


25/82

9

1('2.)"-./+

Mediante los scripts generados automticamente por TASTE se puede compilar elcdigo de las diferentes funciones con los compiladores incluidos en la herramienta yenlazarlos para producir los ejecutables, uno por cada particin declarada en elDeployment view.

En esta fase, se hace uso de un middleware especfico, conocido como PolyORB-HIencargado de relacionar las diferentes primitivas del cdigo generado a aquellasofrecidas por el sistema operativo seleccionado para cada particin. Este middlewarese ofrece en dos variantes: una en Ada, que se implementa mediante un run-time systemque da soporte al perfil de Ravenscar y por tanto el compilador y el run-time realizancomprobaciones del cdigo generado para asegurar que se cumplen las restricciones, yotra variante en C/POSIX, en el cual las restricciones las comprueba el propioPolyORB-HI. El uso de una u otra variante depende de los requisitos especficos decada proyecto en trminos de uso de memoria, rendimiento, disponibilidad de drivers,

etc.

3").&"-./+

TASTE ofrece diferentes herramientas para la validacin del sistema generado. Enprimer lugar, TASTE puede generar automticamente pruebas de codificacin ydecodificacin de los diferentes tipos definidos. Dado que a lo largo del sistema unmismo valor puede pasar por elementos software desarrollados en diferenteslenguajes, y por elementos hardware con diferente representacin en memoria de

valores numricos, esta caracterstica resulta de gran utilidad.

Por su parte, en el mbito de la Interface viewse pueden declarar funciones del tipoGUI. Estas funciones generan un ejecutable extra, consistente en una interfaz grfica enla cual se pueden tanto mostrar los valores recibidos por las interfaces ofrecidas comoenviar diferentes valores por las interfaces requeridas. En esta interfaz grfica sepuede, adems almacenar las interacciones con el sistema, generando un conjunto depruebas automtico basado en las pruebas realizadas previamente de forma manual,caracterstica de utilidad para la realizacin de pruebas de regresin. El uso habitualque se hace de esta funcionalidad es la de simular la estacin de tierra, declarando una

interfaz ofrecida para recibir la telemetra del satlite, y una interfaz requerida paraenviar telecomandos al mismo. De esta manera se puede interactuar manualmente conel sistema en desarrollo y analizar su comportamiento. Un ejemplo de estafuncionalidad se presenta en la seccin 8.

Otra interesante caracterstica para la validacin del sistema es la disponibilidad dela herramienta PeekPoke. Mediante esta herramienta se puede monitorizar en tiempode ejecucin las diferentes variables del sistema. Esta herramienta, en conjuncin con lapresentada anteriormente, forman una potente combinacin para el anlisis delcomportamiento del sistema.


26/82

10

@ :,+,-*"+D#*0-,# /"2 #,*G20*" HI>5,*F=

@96

>0#08&

El UPMSat-2 es un proyecto de la Universidad Politcnica de Madrid que tiene elobjetivo de desarrollar un micro-satlite satlite experimental. Su funcin es la deservir como demostrador tecnolgico de las capacidades tcnicas de los diversosgrupos involucrados en el proyecto. El Instituto Universitario de MicrogravedadIgnacio da Riva lidera el proyecto. El Grupo de Sistemas de Tiempo Real yArquitectura de Servicios Telemticos (STRAST) es el encargado del diseo e

implementacin del software, tanto del segmento de tierra como del segmento devuelo. ste ltimo ejecutar sobre un nico OBC del tipo LEON3[13]. El software haruso de la cadena de compilacin GNATforLEON incluyendo Open Ravenscar Real-time Kernel (ORK)[10].

El proyecto cuenta con un antecedente natural, el satlite UPMSat-1 [11], lanzado el7 de julio de 1995, desarrollado por un grupo de profesores del Laboratorio deAerodinmica de la Escuela Tcnica Superior de Ingenieros Aeronuticos de la UPM.Con un objetivo similar al del actual satlite, si bien a un nivel de complejidad menortcnica y organizativamente, el proyecto fue un xito. El satlite fruto de este proyecto

fue puesto en rbita en el vuelo V75 de un lanzador Ariane IV-40, como cargasecundaria, y se mantuvo operativo durante 213 das, siguiendo una rbita de similarescaractersticas a la del UPMSat-2, inscrito en el registro espaol ROLEU y en el de lasNaciones Unidas como UPM-Sat1/ROLEU 4.

La carga de pago del satlite, o payload est compuesta por un conjunto deexperimentos propuestos por diversas empresas, as como por los diferentes grupos deinvestigacin de la UPM involucrados en el proyecto. Estos experimentos estn en sumayora enfocados al estudio del comportamiento de diferentes componentes en elespacio, para adquirir experiencia en vuelo en el caso de los productos ms maduros, y

obtener datos para el desarrollo de los menos evolucionados.A continuacin se describe brevemente cada uno de ellos, a fin de ilustrar la misin

del satlite, as como justificar su influencia en el diseo que se presentar acontinuacin:

MTS MicroThermal Switch: Este experimento, denominado MicroThermalSwitch (MTS), ha sido propuesto y est siendo construido por IberEspacio.Su objetivo es demostrar el funcionamiento de un interruptor trmico enversin miniaturizada. Su funcin es evacuar el calor del componente al quese adhiere, haciendo uso de un radiador. De esta forma, se trata de evitarque el componente supere una cierta temperatura mxima, ajustada deantemano.


27/82

11

SCT Solar Cell Technology: El departamento TEC-EPG Solar GeneratorSection del Centro de Tecnologa e Investigacin de la Agencia EspacialEuropea (ESTEC) ha propuesto un experimento consistente en instalar enuna de las caras del UPMSat-2 un conjunto de cinco clulas solares de nuevageneracin. Estas clulas solares de triple unin sern probadas en rbita(calibracin, pruebas de degradacin por rayos ultravioletas y oxgenoatmico) y formarn parte del subsistema de potencia del satlite.

MGM Magnetmetro: Se ha llegado a un acuerdo con la empresa Bartingtonpara probar este magnetmetro en vuelo. El experimento consistir en medirel campo magntico terrestre y comparar los resultados con otras medidastomadas con magnetmetros cualificados y clulas solares. Estos equiposforman parte del subsistema de control de actitud del satlite.

MRAD Monitorizacin del efecto de la radiacin: El experimento tiene porobjetivo observar el efecto de la dosis de radiacin recibida en rbita sobre el

hardware del satlite. Para ello se har un chequeo de errores en una partede la memoria del computador cada cierto intervalo de tiempo y semantendr un registro de las posiciones de memoria daadas, obtenindoseuna estadstica del nmero de daos en funcin del tiempo. Una vezprocesados los datos, y deducida la posicin del satlite en funcin deltiempo, se tratar de observar la conocida como anomala del Atlntico Sur(AAS). Esta anomala es consecuencia de la depresin del campo magnticoterrestre en la zona y su efecto ms notable es el aumento de la radiacin.Esta radiacin es variable segn la altura, presentado en la altitud previstapara el satlite una intensidad intermedia, inferior a la presentada en capas

inferiores. Como consecuencia de esta radiacin, los satlites coninclinaciones orbitales entre 35 y 60 han de estar especialmente protegidosfrente a esta radiacin, siendo el ejemplo ms notable la Estacin EspacialInternacional8.

SMA Actuadores: La empresa ARQUIMEA desea validar en vuelo una cargatil en la que combinar actuadores (Pin-Puller y REACT) basados enaleaciones con memoria de forma (SMA, Shape Memory Alloys) parademostracin en rbita su funcionamiento en la actuacin del despliegue dedos booms. Los booms son dispositivos encargados de desplegar diferentessegmentos de los satlites, una vez estos han sido expulsados del vehculolanzador (P.e. paneles solares en el caso de algunos satlites).

RW Rueda de reaccin: La empresa SSBV ha proporcionado al satlite, con elfin de ser validado en rbita, una rueda de reaccin en miniatura, deltamao adecuado para su aplicacin en el control de actitud de pequeossatlites.

SS6 Sensores solares: El Instituto de Energa Solar de la UniversidadPolitcnica de Madrid est desarrollando unas clulas solares especiales, degran estabilidad, para emplearlas como sensores de Sol sencillos yeconmicos. El experimento consiste en medir la corriente generada por las

mencionadas clulas, dispuestas sobre cada una de las caras del satlite, para8 http://en.wikipedia.org/wiki/International_Space_Station


28/82

12

determinar el ngulo que forma cada cara del satlite con la direccin delSol. Los resultados se compararn con las medidas realizadas por losmagnetmetros, a fin de comprobar su exactitud.

CTM Control trmico: Este experimento tambin forma parte de unprograma interno del IDR/UPM y consiste en obtener datos defuncionamiento del satlite y de su comportamiento trmico durante elperiodo de operacin. De este modo, el grupo de investigacin relacionadopodr refinar los mtodos de clculo y diseo trmico en los que el InstitutoIgnacio da Riva cuenta con una amplia experiencia.

BOOM: El IDR/UPM ha desarrollado un Boom, que se quiere calificar y darexperiencia de vuelo, adems de emplearlo para separar un magnetmetrodel cuerpo del satlite una distancia del orden de 0.2 m, y as reducir elposible efecto de contaminacin magntica en las medidas.

MAC Control de actitud: Este experimento forma parte de un programa

interno del IDR/UPM, para desarrollar esquemas robustos de control deactitud basados en el campo magntico, para aplicar en prximos vuelos. Enel caso del UPMSat-2, este experimento controlar la actitud del satlite enperiodos de tiempo reducidos y controlados, desactivndose el control deactitud nominal del satlite.

El satlite est previsto que est listo para ponerse en rbita en otoo de 2014 y sufecha de lanzamiento definitiva depender de la disponibilidad de espacio como cargasecundaria en lanzamientos comerciales o en lanzamientos de prueba de los nuevoslanzadores Vega de la Agencia Espacial Europea. Una vez puesto en rbita, el satlite

se espera que tenga un periodo operativo de dos aos.

Durante ese tiempo, el satlite describir una rbita heliosncrona a 700 kilmetrosde altitud, con una inclinacin entre 96,5 y 102,5. Dadas las caractersticas, el periodoorbital del satlite es de aproximadamente 100 minutos, sobrevolando lasproximidades de la estacin de tierra cada 12 horas.

@9=

:,+,-*"+D#*0-,# /"2 J,+/K,+"

Como se ha mencionado previamente, el software del satlite se ejecutar sobre unnico computador, conocido como On-Board Computer (OBC). El hardware del mismoest basado en la familia de computadores LEON3, de la arquitectura SPARC,incluyendo memoria del tipo SRAM, una EEPROM para almacenamiento persistente,as como diversos dispositivos perifricos para la interaccin con sensores yactuadores.

La familia LEON de procesadores implementa la arquitectura SPARC V8 [14]desarrollados inicialmente por la Agencia Espacial Europea (ESA) y posteriormente

por Gaisler Research. Estos procesadores se encuentran descritos en lenguaje VHDLpara su configuracin y uso en los conocidos como circuitos integrados o system on a


29/82

13

chip (SOC) en los cuales la mayora (o totalidad) de los componentes del sistema seencuentran en un mismo circuito integrado o chip.

El desarrollo de estos procesadores comenz en el ao 1997 por parte de la ESA conel fin de conseguir un diseo de procesador abierto, portable y no privativo, capaz de

alcanzar los requisitos de rendimiento, compatibilidad y costes en los proyectos allevar a cabo durante las siguientes dcadas. Posteriormente, la empresa GaislerResearch, renombrada como Aeroflex Gaisler, paso a ser la encargada del desarrollo denuevos modelos de procesadores LEON, entre ellos el LEON3, el procesadorseleccionado para su uso en el UPMSat-2.

El procesador LEON3 supuso un avance frente a sus predecesores. Entre susnovedades ms destacadas se halla el aumento en las etapas de su pipeline, que pasode las 5 etapas de su inmediato predecesor, el LEON2, a 7. Igualmente, la distribucinincorpor un gran nmero de mdulos sintetizables, que lo hacen de alto inters para

el proyecto UPMSat-2. Entre estos mdulos, los de mayor inters son el controlador dememoria SDRAM de 32 bits, los controladores para SPI, I2C y UART con colas FIFO,as como unidades de reloj, controladores de interrupcin y puertos de entrada/salida.

Las caractersticas ms relevantes del computador de a bordo son:

Procesador LEON3 con FPU (unidad de coma flotante). 41 canales de entrada analgicos.

Memoria SDRAM (tamao por definir). Memoria no voltil de tipo EEPROM

Comunicacin internao Bus SPI.o Bus I2C.o Lnea serie RS-232 a 115200 baudios

Comunicacin con tierrao Frecuencia: UHF banda 400 MHz, con potencia reducida.o Capacidad de enlace: 19200 bps.

A pesar de que la versin de vuelo del OBC descrita sigue en proceso de desarrollo,se dispone de una versin de ingeniera en la cual se estn probando los diferentes

elementos tanto software como hardware para el modelo de vuelo. Este modelo deingeniera est tambin compuesto de un procesador LEON3 sintetizado sobre unaFPGA VIRTEX 5 de XILINX. Al desarrollarse sobre una FPGA, la mayor parte de loscomponentes se pueden sintetizar de forma idntica a la versin de vuelo, con lasalvedad de que el modelo de ingeniera no est protegido externamente a la radiacincomo s lo estar el modelo de vuelo.

@9@

:,+,-*"+D#*0-,# /"2 #43*K,+" /"2 #,*G20*" HI>5,*F=


30/82

14

El software de a bordo est compuesto por los subsistemas que se muestran en laFigura 1. stos son:

Monitor de la plataforma: este subsistema se encarga de controlar el estado delos diferentes componentes del satlite mediante chequeos peridicos. stos

incluyen la medida de los voltajes y corriente de las bateras y paneles solares, latemperatura en diferentes puntos de la estructura y componentes del satlite,etc. El periodo de las medidas a tomar dependen tanto del estado de operacinen el que se encuentre el satlite, como del tipo de medida a tomar.

Telemetra y telecomando (TMTC): subsistema encargado de interactuar con elequipo hardware de telecomunicaciones para el envo de mensajes (telemetra) yrecepcin de rdenes (telecomandos) desde la estacin de tierra.

Sistema de determinacin y control de actitud: subsistema encargado de analizarla orientacin actual del satlite respecto a la tierra y calcular las posiblesmedidas a tomar para mantenerlo en los parmetros consignados. Este procesose lleva a cabo mediante el procesado de las medidas del campo magntico de laTierra en los tres ejes del satlite provistas por unos sensores especficosconocidos como magnetmetros (MM). Los correspondientes actuadores de estesubsistema son los magnetopares (MT), electroimanes que generan un campomagntico que interacta con el de la Tierra haciendo girar al satlite sobre supropio eje.

Figura 1 Arquitectura software del satlite UPMSat-2.


31/82

15

Controlador de experimentos: subsistema encargado de gestionar la puesta enmarcha, ejecucin, toma de datos y detencin de los diversos experimentos abordo del satlite, que constituyen su carga de pago payload, presentadopreviamente.


32/82

16

B >4/"2,/4 /" /,*4#

Como se describi anteriormente, la primera fase descrita en la metodologapropuesta en el proyecto ASSERT es el modelado de los datos. El principal objetivo de

esta fase es la definicin de los diferentes tipos de datos que se intercambiarn enfuturos modelos que representen otras abstracciones del software. Mediante lacombinacin de ASN.1 y su extensin ACN, esta fase de modelado puede subdividirseen dos etapas, siendo la segunda de ellas opcional.

B96

(5L96

En una primera fase, haciendo uso del lenguaje ASN.1 (Abstract Syntax Notation

One), brevemente presentado previamente, se definen los diferentes tipos de datosmediante su definicin semntica. De este modo, puede abstraerse toda la complejidadrelacionada con la codificacin de los datos, compatibilidad entre diferentes lenguajesy plataformas, etc.

En este lenguaje existen tres tipos de datos, a partir de los cuales se pueden definirtipos de la complejidad requerida por el usuario para modelar correctamente susistema. Estos tipos son:

Tipos primitivos: tipos que almacenan un nico valor, entre los cuales

encontramos:o El tipo INTEGER, usado para representar nmeros enteros.o El tipo REAL, que representa tipos de datos de nmeros decimales.o El tipo BOOLEAN, que representa datos que slo pueden tomar los

valores verdadero o falso.o El tipo OCTET STRING, consistente en una cadena de bytes.o El tipo BIT STRING, o cadena de bits.o El tipo NULL que representa la ausencia de valor.

Tipos compuestos: tipos generados a partir de composiciones de los tiposprimitivos y otros tipos compuestos. Los ms habituales son:

o

SEQUENCE: lista ordenada de tipos de datos primitivos heterogneos.En la prctica guarda gran similitud con estructuras de datos comostructdel lenguaje C.

o SEQUENCE OF: lista ordenada de datos del mismo tipo. Ofrece granfacilidad para declarar estructuras de gran tamao, al no tener quedeclarar uno por uno los tipos. Por ejemplo, si quisiramos declarar unatabla, mediante el tipo SEQUENCE declararamos el formato de unafila de la tabla y mediante SEQUENCE OF (tipo de la fila declarado conSEQUENCE) se declara la agrupacin de todas las filas para

representar la tabla.


33/82

17

o SET: es una lista no ordenada, en la que no se permiten tipos de datosrepetidos para evitar ambigedades.

o SET OF: lista no ordenada de tipos de datos iguales.o CHOICE: tipo de dato para el cual se declaran diferentes tipos que

puede adoptar en tiempo de ejecucin. Por lo general, este tipoadoptado en tiempo de ejecucin suele depender del valor que tomenotros campos de estructuras del tipo SEQUENCE.

Tipos definidos: el propio lenguaje incluye tipos definidos para facilitar elproceso de declaracin de los tipos. Estos tipos definidos en realidad no sonms que casos concretos de los tipos presentados anteriormente, con unnombre ms significativo. Dado que el lenguaje fue desarrollado yestandarizado por la ITU, estos tipos describen estructuras comunes en elmbito de las telecomunicaciones, como por ejemplo:

o IpAddres: representa una direccin IPv4. Por tanto su tamao es de 4

bytes y su definicin es un OCTET STRING de tamao 4.o Counter: tipo entero al que slo se le permite aumentar su valor, y una

vez alcanzado el valor mximo declarado, un posterior incrementodevuelve su valor a 0.

o TimeTicks: entero de 32 bits que representa las centsimas de segundotranscurridos desde un evento concreto.

Los tipos presentados aqu no son todos los recogidos por el estndar. La listacompleta de los mismos puede encontrarse en el estndar ITU-T X.680. [12].

El lenguaje ASN.1 es de fcil aprendizaje, dado que el conjunto de tipos quecomnmente se usan es reducido, y las reglas para la declaracin de tipos son bastantesencillas. Un documento de ASN.1 comienza con la declaracin del nombre delpaquete que representa, seguido del nmero de declaraciones de tipos requeridos,concluyendo con la palabra reservada END.

Para definir tipos de datos primitivos la sintaxis es la siguiente: en primer lugar sedeclara el nombre del tipo, que ha de comenzar por letra mayscula, seguido delsmbolo de asignacin ::= . A la derecha del smbolo de asignacin se declara el tipoprimitivo seguido si es necesario de informacin adicional sobre el mismo. Para lostipos primitivos presentados anteriormente se requiere la siguiente informacin

adicional: para los tipos INTEGER y REAL se requieren los valores mnimo y mximoque pueden tomar, escribindose entre parntesis y separados por dos puntos seguidos(P.e. (0..255) para INTEGER (0.0..255.0) para REAL). Para los tipos BIT STRING yOCTECT STRING, aunque el lenguaje no lo obliga, es recomendable, y en muchoscasos necesario el dar un tamao mximo, mediante SIZE (X) donde X es el tamao enbit o bytes dependiendo del tipo. Finalmente los tipos NULL y BOOLEAN norequieren de informacin adicional.

En el caso de la declaracin de tipos compuestos, se repite la estructura de los tiposprimitivos hasta el nombre del tipo incluido. En el caso de tipos compuestos de un

nico tipo, como SEQUENCE OF y SET OF, se ha de definir el tamao mximomediante la frmula SIZE (X), seguido del identificador del tipo del que estn


34/82

18

compuestos. Este tipo que compone la estructura puede ser tanto un tipo definido porel lenguaje, como un tipo definido por el usuario. Por su parte, si se est declarando untipo compuesto por elementos de varios tipos diferentes, como en el caso deSEQUENCE, SET o CHOICE, seguido de este identificador se abre corchetes, en cuyombito se declaran cada elemento contenido en la estructura mediante su nombre(comenzando en este caso por minscula) seguido por un espacio y el tipo delelemento. Nuevamente el tipo de cada elemento puede ser tanto un tipo definido por ellenguaje como por el usuario. Los diferentes elementos que componen la estructura seseparan entre s por comas, terminndose la definicin de la estructura con un cierre decorchetes.

El conjunto completo de normas que rigen el lenguaje ASN.1 se pueden encontrarigualmente en el estndar ITU-T X.680 [12].

B9=

(:L

Como se ha mencionado con antelacin, ASN.1 permite definir tipos y estructurasde datos abstrayendo cualquier tipo de informacin con respecto a cmo estos tiposson codificados. Por lo general, los compiladores para ASN.1, que convierten laespecificacin en cdigo fuente para diversos lenguajes, hacen uso de reglaspredefinidas para determinar la codificacin de los tipos definidos en ASN.1. As, loms comn es que estas herramientas permitan codificar bien siguiendo el estndar

BER (Basic Encoding Rules)[17] o el estndar PER (Packet Encoding Rules)[18]. Estasreglas predefinidas limitan la capacidad de modelado de datos. En muchas casos esnecesaria una codificacin concreta al transformar la especificacin a un lenguajeconcreto. Esto puede suceder cuando se desea comunicar un sistema nuevo con otroexistente, cuyos datos no han sido modelados con ASN.1, como por ejemplo unmanejador de dispositivo o driver. Otro caso bastante corriente del mbito de lastelecomunicaciones es el modelado de datos acorde a protocolos. En la siguientesubseccin se ilustrar esta utilidad con ms detalle, aplicado al mbito del satliteUPMSat-2.

Fruto de la necesidad de ofrecer tambin informacin sobre la codificacin de losdatos, se desarrolla en el mbito del proyecto TASTE el lenguaje ACN (ASN.1 ControlNotation). Este sencillo lenguaje permite al usuario la definicin de la codificacindeseada para cada tipo. As, un documento ACN consta de los tipos definidos enASN.1, uno por lnea, seguidos de corchetes cuadrados ([ ]) dentro de los cuales sedefinen las caractersticas deseadas, separadas por comas.

La informacin que ACN permite incluir sobre la codificacin es la siguiente:

Tamao: mediante el comando size seguido del tamao (las unidadesdependen del tipo en cuestin) se puede definir el tamao deseado para eltipo de dato. Es responsabilidad del compilador impedir tamaos inferioresal mnimo necesario para el tipo de dato.


35/82

19

Codificacin de enteros y reales: diferentes tipos de codificacin existen paravalores numricos. Para nmeros enteros, ACN permite elegir entre:pos-int,valor positivo representado por la codificacin binaria, twos-complement, ocomplemento a dos, ASCII, en el cual se codifica el valor en cuestinmediante el valor ASCII del smbolo positivo o negativo, seguido del valorde cada digito en ASCII o BCD (Binary Coded Decimal) en el cual cadadgito se codifica mediante 4 bits con su valor en binario. Para nmerosdecimales, se ofrecen las codificaciones estandarizadas IEEE754-1985-32 eIEEE754-1985-64.

Codificacin numrica a nivel de byte: aplicable a los enteros de tamao fijo,define el orden en el que se codificarn los correspondientes bytes. Como esnatural, las posibles opciones son Bigo Little endian.

Alineamiento: se puede forzar a que determinados valores se alineen alsiguiente byte (8 bits), palabra (16 bits, word) o doble palabra (32 bits,

dword). Codificacin de valores: para los tipos ENUMERATED se pude forzar a que

se codifique el valor del enumerado y no su ndice (opcin por defecto). Valores positivo y negativo: se puede forzar a que los valores positivo y

negativo de los tipos booleanos se codifiquen mediante cadenas de bits enlugar del valor 1 para truey 0 parafalse.

Indicador de presencia: para las estructuras CHOICE, permite definir lacondicin por la cual el tipo toma una u otra de las posibles especificaciones.

B9@

>4/"2,/4 /" /,*4# ,M20-,/4 ,2 HI>5,*F=

Haciendo uso de los lenguajes anteriormente descritos, y siguiendo con lasdirectrices de TASTE, se ha realizado el modelado de los datos para el satlite UPMSat-2. Este modelado se ha hecho en base a las siguientes fuentes:

Documento de especificacin de requisitos software (SSS)[20] del proyectoUMSat-2.

Manuales de referencia del hardware preseleccionado para el computadorde a bordo.

ECSS-E-70-41A, estndar sobre el software para misiones espaciales [16]. Propuesta del autor para los mensajes de telemetra y telecomando a nivel de

aplicacin.

B9@96 E"2"%"*+D, N E"2"-4%,&/4 "& "2 #,*G20*" HI>5,*F=Uno de los principales objetivos del proyecto es la mxima adopcin a lo largo del

mismo de metodologas, tcnicas, estndares y materiales de uso en el mbito de la

industria aeroespacial. El subsistema de telemetra y telecomando tanto del satlite


36/82

20

como de la estacin de tierra persiguen igualmente este objetivo. De este modo se hanseleccionado protocolos de amplio uso en el sector.

4.5$) &$ $+)"-$6 7,(8(-()( 9:6;

-&63).$ #&63).$#23$>

-&0)&1$-7..'.;'*-.'% #&0)&1$-7..'.;'*-.'%#23$

B

"" ?)-) @A$%+ =$)+$.

#&?@=#23$ 445 67897:;7

3.'E.$,,I&1 UVVD7I:>

&'(3%$-A'*I&1 UVVD7I:

B

"" I33%A&)-A'* ?)-)

#&I33%A&)-A'*?)-)#23$ 445 ;=VC;7

7Y3$.A($*-;'(()*+ 7Y3$.A($*-;'(()*+#23$>

T


40/82

24

B

T

Listado 1Extracto de la definicin de la estructura de un paquete de telecomando mediante ASN.1.

Una vez definida la estructura del paquete, es conveniente completarla condirectrices sobre su codificacin. Dado que el protocolo define claramente el tamao decada campo, as como el significado de cada bit segn su posicin en el paquete,debemos asegurarnos que se codifican adecuadamente. En otros casos podemossimplemente confiar en la codificacin automtica del compilador de ASN.1, el culasegura que esta codificacin hace uso del tamao mnimo posible para cada tipo dedato declarado. Adems, el conjunto de herramientas TASTE posee mecanismos paraasegurar la consistencia de los valores que tomen cada tipo de datos,independientemente del lenguaje de programacin y plataforma en los que seinterpreten. Por tanto, en las situaciones en las que sea necesario, se pueden dardirectrices de codificacin para cada tipo de datos definido en el modelo ASN.1mediante ACN. Estas directrices indican los valores deseados para el tamao de losdatos, el tipo de representacin, o el tipo de representacin de valores numricos, entreotros. A continuacin podemos observar un extracto del cdigo ACN generado para elpaquete de telecomandos.

#&0=G$.,A'*:/(H$.#23$Z,A[$ \> $*&'+A*E 3',"A*-]

#&0=#23$#23$Z,A[$ Q> $*&'+A*E 3',"A*-]

#&0=?)-)@A$%=$)+$.@%)E#23$Z,A[$ Q> $*&'+A*E 3',"A*-]

#&0=I33%A&)-A'*0.'&$,,C?#23$Z,A[$ QQ> $*&'+A*E 3',"A*-]

T

Listado 2Extracto de la definicin de codificacin en ACN de algunos de los tipos declarados en eldocumento ASN.1.

B9@9=O"30&0-08& /" #"+?0-04# /"2 HI>5,*F=9 E"2"%"*+D, N *"2"-4%,&/4 /" &0?"2 /",M20-,-08&9

Adems de la estructura bsica de los paquetes de telemetra y telecomando, existengran cantidad de tipos a definir para el satlite. Un importante subconjunto de losmismos es la informacin que contendrn los mencionados paquetes de telemetra ytelecomando en el campo Application Data, referente a cada uno de los diferentesservicios del satlite.

Buena parte de los servicios requeridos en el proyecto se encuentran ya descritos enel citado estndar ECSS-E-70-41A (Tabla 1). En ese caso, como ya se mencion, seseguir la propuesta del estndar. En aquellos casos en los que los servicios requeridos


41/82

25

por el satlite no se correspondan directamente con un servicio definido por elestndar, o en su descripcin parte del mismo quede a decisin de diseo alguna desus partes, se presenta la propuesta del autor para dichos servicios.

Cabe mencionar que los servicios definidos en el estndar, por lo general, estn

compuestos por un conjunto mnimo de subservicios a implementar y un conjuntoopcional de funcionalidades avanzadas.

Tabla 1Servicios definidos en el estndar ECSS-E-70-41A.El nmero de Service Typese corresponde con los campos de mismo nombre tanto en los paquetes

de telemetra como de telecomando. Extrado de [16].

J(>#$K$$2.+0 L &."0+(#8.- &"8" ,$2(,8.+0 #$,5.-$

El primero de los servicios definidos en el estndar y de utilidad para el proyecto esel dedicado al envo de telemetra. Este servicio tiene el identificador de servicionmero 3, como se puede ver en la Tabla 1. Su principal utilidad (y subconjuntomnimo o bsico de implementacin) es la de definir la estructura y contenido de los

mensajes de telemetra referidos al housekeeping o monitorizacin del satlite.Adicionalmente se describe un nmero de subservicios para modificar parmetros de


42/82

26

la generacin de mensajes de telemetra, definir nuevos tipos de mensaje, etc. En elcaso del UPMSat-2 slo se har uso del subconjunto mnimo definido en el estndar,ampliado con dos subservicios propios para la peticin de telemetra especfica.

"#$%&'&&()*+ ,-.-/&0&. 1&(#.0

El mencionado subconjunto mnimo est compuesto por un nico subservicio:Housekeeping Parameter Report, con identificador de subservicio 25. En este subservicio,la composicin del Source Data (paquetes de telemetra por tanto) definida por elestndar es la mostrada en la Figura 6. En ella se describen tres campos:

Figura 6 Campos del Housekeeping Parameter Report.Extrado de [16].

SID: Campo enumerado que define el tipo de dato al que se refiere elpaquete de telemetra. Su contenido es especfico (y por tanto librementedefinible) en el mbito de cada misin. La propuesta del autor es mantener

los tipos de telemetra descritos en el documento de requisitos. nicamentetendra sentido subdividirlos en el caso de que el periodo de muestreo paradiferentes valores del mismo tipo sea diferente. Por tanto, se consideran lossiguientes valores:

o Valor = 0 : Todas las medidas (solo en peticin de telemetra entiempo real definida ms adelante).

o Valor = 1 : Medidas de temperatura.o Valor = 2 : Medidas de tensin elctrica.o Valor = 3 : Medidas de intensidad elctrica.o Valor = 4 : Medidas de actitud de los magnetmetros.o Valor = 5 : Medidas de actitud de las clulas solares.

Mode: Indica el modo en el que se ha generado el paquete de telemetra.Existen dos modos definidos en el estndar: peridico, en el cual los datos sealmacenan para su envo por telemetra peridicamente,independientemente de su valor, y filtrado, en el cual se definen rangos devalores considerados normales, de modo que si todas las medidas de unadeterminada toma se encuentran dentro de estos rangos, sta no es enviada atierra, salvo que se durante un largo periodo de tiempo no se haya enviadomedida alguna del tipo correspondiente. Los posibles valores son:

o

Valor = 0 : Modo peridico.o Valor = 1 : Modo filtrado. Valor fuera de rango.


43/82

27

o Valor = 2 : Modo filtrado. Se ha excedido el tiempo mnimo entremedidas reportadas.

Parameters: Campo en el cual se incluyen los valores de las medidas. Sucontenido es de libre definicin. Por tanto, la propuesta consiste en enviar undeterminado nmero de medidas consecutivas (por definir) del mismo tipo.Siendo as, se requiere una reinterpretacin del campo Mode previamentedescrito. En el caso en el que el modo de operacin sea peridico, el valorsigue siendo 0. Si se est operando en modo filtrado, el valor ser 1 en el casode que alguna de las medidas que se envan haya sido generada porencontrarse fuera del rango de valores previstos. Unicamente si todas y solotodas las medidas se hayan almacenado debido a que se ha cumplido eltiempo mnimo entre muestras almacenadas, el valor del campo Mode ser2.El contenido del campo ser por tanto una sucesin de pares de la longitud

(por definir) especificada de la siguiente estructura:o Time (32 bits): Valor del reloj de misin en el momento de toma de

los valores de telemetra.o Values (dependiente del tipo de datos): Conjunto de valores para

cada uno de los datos definidos en el documento de especificacin derequisitos software (SSS).

"#$%&'&&()*+ 2#+ 1&3$&%0

Subservicio aadido para la peticin de telemetra de un determinado tipo.

Siguiendo el estndar, el identificador de los subservicios especficos de misin debenestar comprendidos entre el 128 y el 255, proponiendo el autor el uso del identificador128 para este subservicio en concreto. Dado que es posible que por iniciativa propia delsoftware de a bordo no se enve la totalidad de la telemetra disponible (por decisinde diseo para la correcta administracin del tiempo de cobertura), se requiere podersolicitar el envo del log completo de datos de housekeeping de alguno de los tiposdefinidos previamente. Para ello se describe el contenido del campoApplication Datadelos mensajes de telecomando asociados a este subservicio:

SID: Campo enumerado que define el tipo de dato al que se refiere el

paquete de telemetra. Los posibles valores siguen aquellos definidos en elsubservicio Housekeeping Parameter Report, con la salvedad del valor 0,que en este caso incluye a todos los tipos, solicitndose por tanto el envo detoda la telemetra disponible.

o Valor = 0 : Todas las medidas.o Valor = 1 : Medidas de temperatura.o Valor = 2 : Medidas de tensin elctrica.o Valor = 3 : Medidas de intensidad elctrica.o Valor = 4 : Medidas de actitud de los magnetmetros.o

Valor = 5 : Medidas de actitud de las clulas solares.


44/82

28

Time (32 bits): Campo para solicitar la telemetra almacenada desde uninstante de tiempo concreto. Su valor se comparar con el registrado en cadapaquete de medidas de housekeeping y se enviarn aquellos con un valorposterior. En caso de que el campo Time tome el valor 0, se enviar toda latelemetra disponible.

1&-450)/& "#$%&'&&()*+ 1&3$&%0

Subservicio aadido para la peticin de telemetra en tiempo real. Se propone el usodel identificador 129. El contenido del campo Application Data de los mensajes detelecomando asociados a este subservicio:

SID: Campo enumerado que define el tipo de dato al que se refiere elpaquete de telemetra. Los posibles valores siguen aquellos definidos en elsubservicio Housekeeping Parameter Report, con la salvedad del valor 0,que en este caso incluye a todos los tipos, solicitndose por tanto el envo de

toda la telemetra disponible.o Valor = 0 : Todas las medidas.o Valor = 1 : Medidas de temperatura.o Valor = 2 : Medidas de tensin elctrica.o Valor = 3 : Medidas de intensidad elctrica.o Valor = 4 : Medidas de actitud de los magnetmetros.o Valor = 5 : Medidas de actitud de las clulas solares.

B5$+8 M$2(,8.+0 D$,5.-$Este servicio permite el envo de informacin sobre eventos que ocurren durante laoperacin del satlite. Su identificador de servicio es el 5 y su funcin es la de cubrir losrequisitos de notificacin de eventos que suponen la deteccin de una anomala o falloen algn elemento del satlite, as como de acciones autnomas del satlite (comopuede ser el cambio de modo de operacin). En el satlite UPMSat-2 se implementarel subconjunto bsico, que define cuatro subservicios:

Normal Progress Report: Subservicio con identificador 1, reporta accionesautnomas del satlite.

Error Anomaly Report Low/Medium/High Severity: Subservicios denotificacin de errores, con identificadores del 2 al 4. La diferente gradacinpermite ofrecer diferentes niveles de prioridad para su envo y tratamientoen tierra.

La estructura del campo Source Data de los paquetes de telemetra asociados es lasiguiente:


45/82

29

Figura 7 Campos del Event Reporting Service.Extrado de [16].

RID: Report ID, junto con el identificador de aplicacin y la severidadpermite la identificacin del evento en concreto.

Parameters: Valores que aaden informacin sobre el evento en cuestin:o Time (32 bits): Valor del reloj de misin en el momento que se

registra el evento.o Otros: dependiente de los tipos de evento descritos a continuacin.

Por tanto, se requiere la identificacin de los diferentes eventos que se pueden daren los diferentes subsistemas, as como categorizacin de severidad y la definicin deparmetros adecuados para su completa descripcin:

Orchestrator: para el orquestador de la plataforma se describen lossiguientes eventos:o Normales:

!

StatusChange: Cambio de estado de operacin del satlite RID: 0 Parameters:

o NewStatus (enumerado): Nuevo estado delsatlite. Los posibles estados son: launch,latency, initialization, commisioning, safe, beacon,

nominal y experiment.o Trigger (enumerado): Motivo por el cual se cambia

de estado:! TC(0) : ordenado por telecomando.!

LostCOMM(1) : Ha vencido el plazo mximoentre periodos de conexin.

! ExperimentTimer(2): Ha vencido el plazodado al experimento.

! LowBattery(3): Se ha detectado estado bajode bateras.

! CriticalBattery(4): Se ha detectado un nivelde bateras crtico.

! WatchdogTimer(5): El computador se hareiniciado al expirar el temporizador deguardia.


46/82

30

! LatencyTimer(6): Ha expirado eltemporizador de estado de latencia.

! SeparationTimer(7): Ha expirado eltemporizador tras la separacin dellanzador.

!

Other(8): Cualquier otra causa nocontemplada por el resto de indicadores.

o Medium Severity:! EventLogFull: Se he llenado la regin de memoria dedicada a

almacenar eventos pendientes de transmisin a tierra.

RID: 0 Parameters:

o EventSeverity (enumerado): Cola de envo que se hallenado:

!

Nomal (0)! LowSeverity (1)! MediumSeverity (2)! HighSeverity (3)

Housekeeping Manager: El monitor de plataforma puede registrar lossiguientes eventos:o Low Severity:

! LowBattery: Se ha detectado nivel de bateras bajo.

RID: 0 Parameters:

o BatteryLevel: valor concreto detectado.o Medium Severity:

! SensorError: Se ha detectado un sensor que presenta uncomportamiento errneo.

RID: 0

Parameters:o SensorID (enumerado): Sensor que presenta el

comportamiento anmalo.o ErrorID (enumerado): tipo de error.

! Timeout(0): Se ha excedido el tiempo deespera para conectar con el dispositivo.

! ValueOutOfRange(1): El dispositivo notificavalores fuera de rango de forma reiterada.

! HousekeepingLogFull: Se ha llenado la regin de memoriadedicada a un tipo de telemetra sin que sus datos hayan sidoenviados a tierra. Por tanto se perder informacin.

RID: 1

Parameters:


47/82

31

o SID: Valor del SID definido en el HousekeepingReport Service para el tipo de telemetra cuyo Logse ha llenado.

o High Severity:!

CriticalBattery: Se ha detectado un nivel de bateras crtico. Se hade cambiar de modo de operacin del satlite de formainmediata.

RID: 0 Parameters:

o BatteryLevel: valor concreto detectado.

ADCS: Experiment Manager: Gestor de los experimentos.

o Normales:

!

ExperimentBegins: Notificacin de inicio de experimento. RID: 0

Parameters:o ExperimentID(enumerado).

! ExperimentEnds: RID: 0 Parameters:

o ExperimentID(enumerado).o ResultValues: Valores resultado del experimento.

Contenido a definir por cada responsable deexperimento.

o Medium Severity:! ExperimentError: Se ha detectado un error en alguno de los

experimentos de a bordo.

RID: 0 Parameters:

o ExperimentID (enumerado).o ErrorID (enumerado): Error detectado.

! ConnectionError(0): No se puede conectar

con el experimento por la interfaz delmismo.

! ExperimentError(1): Se ha detectado unaanomala en el funcionamiento delexperimento.

o High Severity:! RWError: Dado que puede afectar gravemente al funcionamiento

del satlite, un error que impida la desactivacin/detencin de larueda de inercia del satlite se considera un error grave.

RID: 0

Parameters: Ninguno (aparte de Time).


48/82

32

TMTC: Subsistema de comunicaciones.o Medium Severity:

! LostCOMM: Ha expirado el tiempo mximo entre dos conexincon la estacin de tierra.

RID: 0 Parameters:

o LastConnection (32 bits): Valor del reloj de misincuando se estableci comunicacin con la estacinde tierra por ltima vez.

! NotTrustedSource: Se ha detectado la recepcin de untelecomando del cual no se ha podido comprobar su origen.

RID: 0

Parameters: Ninguno (aparte de Time).! ReceptionErrors: Se ha detectado un nmero de paquetes de

telecomando rechazados por ser considerados errneos (al nocorresponder con los cdigos de redundancia) superior almximo esperado (por definir):

RID: 0

Parameters:o Percentage: Porcentaje de paquetes descartados.

N$'(,A N"+"0$'$+8 D$,5.-$

Este servicio, con identificador 6, permite tanto la modificacin de reas de memoriadel computador de a bordo como el envo a tierra de reas de memoria del mismo. Enel estndar se describen dos posibles subconjuntos de implementacin mnima,diferencindose entre ellos en la forma en que estas reas de memoria sondireccionadas. Los posibles dos opciones son: mediante direcciones base previamentedefinidas y desplazamiento a partir de la direccin base o el uso de direccionesabsolutas. Dada la reducida capacidad de la memoria del satlite, as como la mayorsimplicidad de la implementacin, se har uso de las direcciones absolutas. Paraimplementar este subconjunto, se requieren los siguientes tres subservicios:

2#-6 7&/#.8 $%)*+ 9:%#4$0& 966.&%%&%Este subservicio (identificador 2) permite el envo desde la estacin de tierra delcontenido deseado para una o varias reas de memoria en el computador de a bordo.Por tanto, los campos descritos a continuacin sern el contenido del campoApplicationDatade los mensajes de telecomando referidos a este subservicio:


49/82

33

Figura 8 Campos del subservicio Load Memory using Absolute Addreses.Extrado de [16].

Memory ID: Campo para identificar la memoria (dispositivo fsico o lgico) a

la que se refiere el telecomando. Dado que es opcional y la arquitectura delcomputador de a bordo del satlite UPMSat-2 maneja la entrada salidamapeada en memoria (es decir, existe un nico espacio de memoria,compartida por la memoria principal y los diversos perifricos), este campose omitir, al no existir ambigedad posible.

N: indica el nmero de regiones de memoria a editar. Dado que es opcional,y este servicio debe usarse con extrema cautela, solo se contempla que sepueda enviar un nico bloque de memoria por telecomando, omitindosepor tanto este campo. Esto, adems, simplifica enormemente laimplementacin del servicio.

Start Addres: Direccin de memoria de comienzo de la zona de memoria aeditar. Dado la arquitectura del computador, esta direccin debe estaralineada a byte.

Length: Campo que describe la longitud (en bytes) del rea de memoria amodificar (y por tanto la longitud del campo Data).

Data: Contenido que debe insertarse en memoria. Checksum: Suma de comprobacin del campo data. Dado que es opcional,

que el paquete de telecomando en s ya tienen checksum que incluye elApplication Data, y que no se esperan regiones de memoria grandes en el

campo Data, el campo Checksum se omitir.

;$/( 7&/#.8 $%)*+ 9:%#4$0& 966.&%%&%

Subservicio (identificador 5) que permite solicitar desde la estacin de tierra el envode reas de memoria del computador de a bordo. Por tanto, los campos descritos acontinuacin sern el contenido del campo Application Data de los mensajes detelecomando referidos a este subservicio:

Figura 9 Campos del subservicio Dump Memory using Absolute Addreses.Extrado de [16].

Memory ID: Previamente se ha razonado la omisin de este campo.


50/82

34

N: Del mismo modo que en el caso del subservicio Load Memory, solo secontempla una solicitud por telecomando, y por tanto, este campo esomitido.

Start Address: Direccin de memoria base solicitada. Aplican lasconsideraciones previamente expuestas en el mismo campo del subservicioLoad Memory.

Lenght: Longitud (en bytes) de la peticin de volcado de memoria.

7&/#.8 ;$/( $%)*+ 9:%#4$0& 966.&%%&% 1&(#.0

Subservicio (identificador 6) que genera un mensaje de telemetra con el contenidode cierta rea de la memoria del computador de a bordo. Por lo general, este servicioejecuta como respuesta a una peticin del subservicio Dump Memory using AbsoluteAddresses, pero tambin puede realizarse espontneamente por el computador de a

bordo, si ha sido configurado para ello. Estos son los campos del Source Data de losmensajes telemetra referidos a este subservicio:

Figura 10 Campos del subservicio Memory Dump using Absolute Addreses.Extrado de [16].

Memory ID: Previamente se ha razonado la omisin de este campo. N: Previamente se ha razonado la omisin de este campo.

Start Address: Mismo significado que en los anteriores subservicios de esteservicio.

Length: Mismo significado que en los anteriores subservicios de esteservicio.

Data: Mismo significado que en los anteriores subservicios de este servicio.

Checksum: Previamente se ha razonado la omisin de este campo.

!>+-8.(+ N"+"0$'$+8 D$,5.-$

Servicio (con identificador 8) que permite enviar desde tierra rdenes para laejecucin de acciones concretas de una aplicacin determinada. En el mbito delproyecto, este servicio resulta de utilidad para el envo de telecomandos al subsistemade experimentos, a fin de que ponga en marcha, detenga o genere mensajes de

telemetra de un experimento.


51/82

35

El servicio solo define un subservicio, con el nombre de Perform Function eidentificador de subservicio 1. La definicin de los campos del Application Datade losmensajes de telecomando asociados a este servicio son los siguientes:

Figura 11 Campos del servicio Function Management.Extrado de [16].

Function ID: Campo que identifica la operacin a realizar. Dado que elestndar ofrece total libertad para su definicin, mediante este campo secomunicar!" $%& $'(%&)

o ExperimentID(enumerado): Identificador del experimento.o ExperimentOperation(enumerado): Operacin a realizar. Los

posibles valores son start, stopy reportResults.

N: Nmero de parmetros que siguen en el mensaje. Parameter#: Identificador de parmetro del valor que se enva a

continuaci*"+ ,'-./) ,'-%0 $/- 1'0!2/(0%+

Con la actual definicin de los diferentes experimentos, no se considera que vaya a

ser necesario el envo de parmetros. Sin embargo, se documenta la estructura por sifuera necesario dada la evolucin de la descripcin de los experimentos.

O2$+P.+K

Servicio con identificador 128 (el primero de los valores posibles para los serviciosespecficos de misin, no recogidos en el estndar.). Dada la rbita del satlite, el

subsistema de telecomunicaciones solo tendr cobertura con la estacin de tierradurante determinados periodos de tiempo. Por tanto, debe establecerse un protocolode adquisicin de seal y comienzo del intercambio de mensajes de aplicacin. Si bienla adquisicin de seal es responsabilidad del protocolo de bajo nivel, AX.25, queincorpora mecanismos para ello, ser la estacin de tierra la que tome la iniciativa anivel de aplicacin, mandando el telecomando definido en este servicio. Una vezcorrectamente recibido este telecomando, el satlite considera la comunicacincompletamente establecida y comienza el envo de la telemetra bsica definida en eldocumento de especificacin de requisitos software, salvo que el contenido deltelecomando indique lo contrario. Esto puede ser de utilidad en situaciones en las

cuales se requiera de gran cantidad de tiempo de conexin, como puede ser lamodificacin de grandes reas de memoria. Para ello, se define el campo del


52/82

36

Application Data de los mensajes de telecomando asociados a este servicio (elidentificador de subservicio ser el 1):

SendTM (Booleano): Valor booleano que indica si se debe enviar latelemetra bsica como respuesta al telecomando OpenLink.

7$8.-./+ &$ ,$$+5@( &$ '$+#"Q$#

Identificador de servicio 129. Debido a errores de transmisin en el mensaje, puedeque o bien se detecten saltos en el nmero de secuencia de un telecomando otelemetra, o bien puede detectarse un error en el contenido del mensaje en el procesode verificacin de su suma de comprobacin. En cualquiera de los casos, puedeconsiderarse necesario la solicitud de la retransmisin de dicho paquete. En ese caso,debe mandarse un mensaje de telecomando o telemetra (dependiendo de si se trata dela estacin de tierra o el satlite) con el siguiente contenido en el campo ApplicationData o Source Data(el identificador de subservicio ser el 1):

SequenceCount: Nmero de secuencia del mensaje perdido/deteriorado delcual se solicita su retransmisin.

N(&.R.-"-./+ &$ 5")(,$# &$ -(+R.0>,"-./+

Dada la especificacin de requisitos, el sistema requiere de un servicio encargado dela modificacin de valores de configuracin software. Entre ellos, por ejemplo, sepuede considerar el cambio de modo de operacin del satlite. Para ello se define elpresente servicio, que, siguiendo el estndar, debe tener un identificador entre el 128 yel 255 (se propone usar el 130, para dejar libres 128 y 129 a posibles servicios msgenricos).

Para la definicin del servicio se seguir la estructura de subservicios que presentael estndar, definindose los siguientes subservicios:

*

Dada la relevancia y especificidad de este parmetro de configuracin, se describeun subservicio para el mismo. Este tendr el indicador de subservicio 1. A continuacinse detalla la propuesta para el campoApplication Datade los mensajes de telecomandoasociados a este subservicio.

NewStatus (enumerado): Nuevo estado del satlite.

Ntese que se puede indicar el cambio de estado a cualquiera de los posiblesestados operacionales del satlite. El software de a bordo debe comprobar que esposible, siguiendo el diagrama de posibles estados de la Figura 12, la transicin deestados solicitada, descartndose esta si no es posible realizarse.


53/82

37

Figura 12 Diagarama de estados de operacin del satlite UPMSat-2.

*

Subservicio que permite el cambio de valor de un parmetro de configuracinsoftware distinto del estado de operacin del satlite. El identificador de estesubservicio es el n 2. A continuacin se detalla la propuesta para el campoApplicationDatade los mensajes de telecomando asociados a este subservicio.

ParameterID (enumerado): Identificador del parmetro de configuracin amodificar. Los posibles dependen del documento de especificacinsoftware.

Value (dependiente de ParameterID): Nuevo valor para el parmetro de

configuracin.


54/82

38

P >4/"2,/4 /" 0&*"+3,-"#

La segunda fase propuesta por la metodologa ASSERT-TASTE es el modelado delas interfaces del sistema. En esta fase se declaran las diferentes funciones del sistema.

En el modelado de interfaces de ASSERT/TASTE, las funciones son entidades softwareque interaccionan entre ellas ofreciendo diferentes servicios, asemejndose al conceptode componente de otras metodologas MDE. Estas funciones por tanto se caracterizanpor sus interfaces, as como el lenguaje de programacin o de modelado en el que seimplementar. Las interfaces pueden ser provistas, si la funcin las implementa, orequeridas, si representan la llamada a un procedimiento implementado por otrafuncin. Por lo tanto, las interfaces provistas son los puntos de activacin de lasdiferentes tareas. As, estas pueden ser:

Cclicas: Son funciones activadas por el vencimiento de un temporizador

con un tiempo de expiracin constante conocido como periodo. Espordicas: Se activan al ser llamadas por otras funciones. Si bien, a

diferencia de las cclicas, no se activan bajo un patrn de tiempo constante,s es posible asegurar un tiempo mnimo entre dos llamadas sucesivas, locual permite el anlisis temporal del sistema.

Protegidas: Se activan ante la llamada de otra funcin y sobre ellas no sepuede ofrecer ninguna suposicin sobre su esquema de activacin. Este tipode interfaz debe ejecutarse en exclusin mutua. Esto quiere decir que siexiste alguna otra tarea de la funcin en ejecucin, la llamada a la tarea

protegida deber esperar a que esta concluya para comenzar a ejecutar. Unavez esto suceda, cualquier activacin de tarea de la funcin deber esperar aque la tarea protegida concluya su ejecucin.

No protegidas: Se activan ante la llamada de otra funcin y sobre ellas no sepuede ofrecer ninguna suposicin sobre su esquema de activacin. Adems,no presentan ninguna res

Arquitectura de Software1

Documents

Transcript of Arquitectura de Software1