UPMSAT-2 Especiﬁcación del sistema de...

UPMSAT-2

Especificación del sistema de softwareSoftware System Specification

Version 1.8

16 de diciembre de 2013

UNIVERSIDAD POLITÉCNICA DE MADRID

GRUPO DE SISTEMAS DE TIEMPO REAL

Y ARQUITECTURA DE SERVICIOS TELEMÁTICOS

Revisión 411— 16 de diciembre de 2013 18:16:47

Copyright c© DIT/UPM 2012–2013.

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

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

Estado: Revisión

Escrito por: Juan A. de la PuenteJuan Zamorano

Revisado por: Alejandro AlonsoAli RavanbakhshÁngel Sanz

Modificaciones

Versión/Revisión Fecha Propósito Autor1.0 27-10-2011 Borrador inicial J.A. de la Puente, J. Zamorano1.1 20-01-2012 Versión para revisión J.A. de la Puente, J. Zamorano1.2 09-02-2012 Versión revisada J.A. de la Puente, J. Zamorano1.3 15-02-2012 Versión revisada J.A. de la Puente, J. Zamorano1.4 24-02-2012 Versión revisada J.A. de la Puente, J. Zamorano1.5 02-03-2012 Versión revisada J.A. de la Puente, J. Zamorano1.6 05-09-2012 Versión revisada J.A. de la Puente, J. Zamorano1.7 21-01-2013 Versión revisada J.A. de la Puente, J. Zamorano1.8 16-12-2013 Versión revisada J.A. de la Puente

Grupos y organizaciones participantes en UPMSat2

IDR Instituto Universitario de Microgravedad “Ignacio da Riva” (UPM)STRAST Sistemas de Tiempo Real y Arquitectura de Servicios Telemáticos (UPM)TECNOBIT Tecnobit, S.L.

http://creativecommons.org/licenses/by-nc-nd/3.0/

http://creativecommons.org/licenses/by-nc-nd/3.0/

Índice general

1. Introducción 11.1. Objetivo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.2. Ámbito de aplicación . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.3. Resumen del documento . . . . . . . . . . . . . . . . . . . . . . . . . . 1

2. Referencias 32.1. Documentos aplicables . . . . . . . . . . . . . . . . . . . . . . . . . . . 32.2. Documentos de referencia . . . . . . . . . . . . . . . . . . . . . . . . . 32.3. Otros documentos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

3. Definiciones y abreviaturas 53.1. Definiciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

3.1.1. Definiciones de otros documentos . . . . . . . . . . . . . . . . . 53.2. Notación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53.3. Abreviaturas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

4. Descripción general 94.1. Perspectiva . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94.2. Funcionalidad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

4.2.1. Software embarcado . . . . . . . . . . . . . . . . . . . . . . . . 104.2.2. Software del segmento de tierra . . . . . . . . . . . . . . . . . . 104.2.3. Software del sistema de pruebas en tierra . . . . . . . . . . . . . 104.2.4. Modos de funcionamiento . . . . . . . . . . . . . . . . . . . . . 10

4.3. Restricciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114.4. Entorno de funcionamiento . . . . . . . . . . . . . . . . . . . . . . . . . 11

4.4.1. Características del satélite . . . . . . . . . . . . . . . . . . . . . 114.4.2. Computador embarcado . . . . . . . . . . . . . . . . . . . . . . 134.4.3. Interfaces de hardware . . . . . . . . . . . . . . . . . . . . . . . 14

4.5. Carga útil . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144.6. Segmento de tierra . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

4.6.1. Estación de tierra . . . . . . . . . . . . . . . . . . . . . . . . . . 154.6.2. Sistema de pruebas (EGSE) . . . . . . . . . . . . . . . . . . . . 16

4.7. Supuestos y dependencias . . . . . . . . . . . . . . . . . . . . . . . . . . 16

5. Requisitos específicos 175.1. Requisitos sobre el funcionamiento del sistema . . . . . . . . . . . . . . 17

5.1.1. Modos de funcionamiento del satélite . . . . . . . . . . . . . . . 17

I

5.1.2. Órdenes remotas (telecontrol, telecommands) . . . . . . . . . . . 245.1.3. Adquisición y procesado de telemetría . . . . . . . . . . . . . . . 255.1.4. Control de actitud . . . . . . . . . . . . . . . . . . . . . . . . . . 265.1.5. Supervisión y control de la plataforma . . . . . . . . . . . . . . . 285.1.6. Almacenamiento y registro de datos . . . . . . . . . . . . . . . . 295.1.7. Intercambio de datos con la carga útil . . . . . . . . . . . . . . . 295.1.8. Control térmico . . . . . . . . . . . . . . . . . . . . . . . . . . . 305.1.9. Control de energía . . . . . . . . . . . . . . . . . . . . . . . . . 30

5.2. Requisitos sobre las interfaces del sistema . . . . . . . . . . . . . . . . . 305.3. Requisitos de adaptación a la misión . . . . . . . . . . . . . . . . . . . . 305.4. Requisitos sobre recursos computacionales . . . . . . . . . . . . . . . . . 30

5.4.1. Computador embarcado (OBC) . . . . . . . . . . . . . . . . . . 305.4.2. Utilización de recursos de cómputo . . . . . . . . . . . . . . . . 315.4.3. Requisitos de software . . . . . . . . . . . . . . . . . . . . . . . 31

5.5. Requisitos de seguridad de acceso . . . . . . . . . . . . . . . . . . . . . 315.6. Requisitos de seguridad de funcionamiento . . . . . . . . . . . . . . . . 325.7. Requisitos de fiabilidad y disponibilidad . . . . . . . . . . . . . . . . . . 325.8. Requisitos de calidad . . . . . . . . . . . . . . . . . . . . . . . . . . . . 325.9. Requisitos y restricciones sobre el diseño . . . . . . . . . . . . . . . . . 32

5.9.1. Restricciones sobre la arquitectura del software . . . . . . . . . . 325.9.2. Uso de estándares . . . . . . . . . . . . . . . . . . . . . . . . . . 325.9.3. Uso de componentes existentes . . . . . . . . . . . . . . . . . . 325.9.4. Uso de componentes comerciales (COTS) . . . . . . . . . . . . . 325.9.5. Uso de estándares de diseño . . . . . . . . . . . . . . . . . . . . 325.9.6. Uso de estándares de datos . . . . . . . . . . . . . . . . . . . . . 325.9.7. Uso de lenguajes de programación . . . . . . . . . . . . . . . . . 335.9.8. Normas de estilo . . . . . . . . . . . . . . . . . . . . . . . . . . 335.9.9. Flexibilidad y expansión . . . . . . . . . . . . . . . . . . . . . . 335.9.10. Normas de interfaces persona-máquina (HMI) . . . . . . . . . . . 33

5.10. Requisitos sobre el funcionamiento del software . . . . . . . . . . . . . . 335.11. Requisitos sobre el mantenimiento del software . . . . . . . . . . . . . . 345.12. Requisitos sobre la observabilidad del sistema y del software . . . . . . . 34

6. Verificación, validación e integración del sistema 356.1. Requisitos sobre el proceso de verificación y validación . . . . . . . . . . 356.2. Enfoque de la validación . . . . . . . . . . . . . . . . . . . . . . . . . . 356.3. Requisitos de validación . . . . . . . . . . . . . . . . . . . . . . . . . . 356.4. Requisitos de verificación . . . . . . . . . . . . . . . . . . . . . . . . . . 35

II

Capítulo 1

Introducción

1.1. ObjetivoEste documento (SSS, Software System Specification) establece los requisitos del sis-

tema de software aplicables a la misión UPMSat2. Estos requisitos se derivan de los re-quisitos del sistema establecidos en el documento SRD [RD1].

El sistema UPMSat2 se describe brevemente en el capítulo 4, e incluye el satélite(plataforma y carga útil), el segmento de tierra, el lanzador, la órbita y las operaciones.

1.2. Ámbito de aplicaciónLos requisitos de software especificados en este documento se aplican a dos sistemas

de software:

El software del computador embarcado (OBC) en el satélite.

El software del segmento de tierra.

1.3. Resumen del documentoEl contenido del documento se ajusta a lo establecido en la norma ECSS-E-ST-40C [AD1].Este documento está organizado de la siguiente forma:

El capítulo 2 contiene la lista de documentos aplicables y de referencia para estedocumento.

El capítulo 3 contiene las definiciones, abreviaturas y convenios de notación utili-zados.

El capítulo 4 contiene una descripción general del sistema UPMSat2 y del softwarecorrespondiente.

El capítulo 5 desarrolla la especificación de requisitos del software.

El capítulo 6 contiene la especificación de los requisitos de verificación, validacióne integración del software.

1

2 CAPÍTULO 1. INTRODUCCIÓN

Capítulo 2

Referencias

2.1. Documentos aplicables[AD1] ECCS-E-ST-40C Space Engineering — Software. March 2009.

[AD2] ECSS-Q-ST-80C Space Product Assurance — Software Product Assurance. March2009.

[AD3] ECSS-E-ST-50C Space engineering — Communications. July 2008.

[AD4] ECSS-E-ST-50-01C Space engineering — Space data links - Telemetry synchroni-zation and channel coding. July 2008.

[AD5] ECSS-E-ST-50-03C Space engineering — Space data links - Telemetry transferframe protocol. July 2008.

[AD6] ECSS-E-ST-50-04C Space engineering — Space data links - Telecommand proto-cols synchronization and channel coding. July 2008.

[AD7] ECSS-E-ST-70C Space engineering — Ground systems and operations. July 2008.

[AD8] The International System of Units (SI). Bureau International des Poids et Mesures,2006.

2.2. Documentos de referencia[RD1] UPMSAT2 — Documento de requerimientos del Sistema (SRD). Enero 2011.

[RD2] Concepto UPMSat-2. UPM-IDR US2-PM-PLN-002-R1. 22-02-2011.

[RD3] Modos de funcionamiento. Mayo 2011.

[RD4] UPMSat-2 Functional Block Diagrams (FBD). 07-07-2011.

[RD5] UPMSat-2 Interface Control Document. UPMSAT2-SE-ICD-003 Draft. Diciem-bre 2012.

[RD6] UPMSAT2 — Resumen de especificaciones. V01D. Diciembre 2012.

3

4 CAPÍTULO 2. REFERENCIAS

[RD7] UPMSAT2 — Cargas útiles. Resumen. Noviembre 2012.

[RD8] UPMSAT2 — Requirement Matrix EBOX 2012-12-12 ISS-00 Draft. Diciembre2012.

2.3. Otros documentos[D1] SAE. SAE AS5506A Architecture Analysis and Design Language (AADL), January

2009. Available at www.sae.org.

[D2] ISO/IEC 8652:2012(E): Information Technology — Programming Languages —Ada, 2012.

[D3] ISO/IEC TR 15942:2000 — Guide for the use of the Ada programming language inhigh integrity systems, 2000.

[D4] ISO. ISO/IEC TR 24718:2005 — Guide for the use of the Ada Ravenscar Profilein high integrity systems, 2005. Based on the University of York Technical ReportYCS-2003-348 (2003).

[D5] Ada Quality and Style Guide, 2008. Available at http://en.wikibooks.org/wiki/Ada_Style_Guide.

[D6] John Barnes. SPARK - The Proven Approach to High Integrity Software. Altran,2013.

[D7] Ian Sommerville. Software Engineering. Pearson Education, 9 edition, 2010.

[D8] ISO. ISO/IEC 8652:1995(E)/TC1(2000)/AMD1(2007): Information Technology —Programming Languages — Ada, 2007.

[D9] LEON3 - High-performance SPARC V8 32-bit Processor. GRLIB IP Core User’sManual, 2012.

www.sae.org

http://en.wikibooks.org/wiki/Ada_Style_Guide

http://en.wikibooks.org/wiki/Ada_Style_Guide

Capítulo 3

Definiciones y abreviaturas

3.1. Definiciones

3.1.1. Definiciones de otros documentosSe emplearán los términos definidos en los documentos [AD1] y [AD2] traducidos al

español de la manera que se ha considerado más conveniente.

3.2. NotaciónSe usan los siguientes convenios para identificar los requisitos definidos en este docu-

mento:

Los requisitos de software definidos en este documento se denotan como:

REQ-s.g.n, donde

s es un número de sección, que corresponde con el apartado correspondiente delcapítulo5.

g es un número de grupo, que corresponde con el subapartado correspondiente delcapítulo5.

n es el número correlativo del requisito dentro de la sección y grupo correspon-diente.

3.3. AbreviaturasAADL Arquitecture Analysis Design Language.

AD Applicable document, documento aplicable.

ADCS Attitude determination and control subsystem, sistema de determinación y controlde actitud.

AI Analog input, entrada analógica.

5

6 CAPÍTULO 3. DEFINICIONES Y ABREVIATURAS

AOCS Attitude and orbit control system, sistema de control de actitud y órbita.

COTS Commercial-off-the-shelf, elementos comerciales.

CPU Central processing unit.

CTM Control térmico.

DDR2-SDRAM Double data rate synchronous dynamic random-access memory interfa-ce, version 2.

DHU Data handling unit, unidad de gestión de datos.

DI Digital input, entrada digital.

DO Digital output, salida digital.

ECSS European Cooperation on Space Standardization.

EGSE Electronic Ground Support Equipment.

ESA European Space Agency, Agencia Europea del Espacio.

ESTEC European Space Research and Technology Center.

FPGA Field-programmable gate array.

FDIR Fault detection, isolation and recovery.

FPU Floating-point unit.

GS Ground station, estación de tierra.

HMI Human-machine interface, interfaz persona-máquina.

IDR Instituto Universitario de Investigación “Ignacio da Riva”.

I/O Input.ouput, entrada-salida.

LEO Low Earth orbit, órbita terrestre baja.

MAC Magnetic-field Attitude Control.

MGM Magnetometers, magnetómetros.

MGT Magnetorquers, magnetopares.

MRAD Monitorización del efecto de la radiación.

MTS Micro-Thermal Switch, microinterruptor térmico.

OBC On-board computer, computador embarcado.

OBDH On-board data handling, gestión de datos a bordo.

3.3. ABREVIATURAS 7

ORK Open Ravenscar Real-Time kernel.

RAM Random-access memory, memoria de acceso aleatorio.

RD Reference document, documento de referencia.

ROM Read-only memory, memoria inalterable.

RW Reaction Wheel, rueda de reacción.

ROLEU Registro de Objetos lanzados al espacio ultraterrestre.

SCT Solar Cell Technology, tecnología de células solares.

SMA Shape Memory Alloys, aleaciones con memoria de forma.

SRD Software Requirements Document, documento de requisitos de sistema.

SS Subsystem, subsistema.

SS Solar sensor, sensor solar.

SSD Solid-state drive.

SSS Software System Specification, especificación del sistema de software.

TBC To be completed, pendiente de completar.

TBD To be defined, pendiente de definir.

TC Telecommand, telecontrol, órden remota.

TM Telemetry, telemedida, medida a distancia.

TTC Telemetry and telecommand, telemedida y telecontrol.

UPM Universidad Politécnica de Madrid.

VHDL VHSIC hardware description language.

VHSIC Very-high-speed integrated circuits.

8 CAPÍTULO 3. DEFINICIONES Y ABREVIATURAS

Capítulo 4

Descripción general

4.1. PerspectivaLa misión UPMSat-2 tiene por objetivo desarrollar un micro-satélite utilizable co-

mo plataforma de demostración tecnológica en órbita. El proyecto se lleva a cabo porun grupo trabajo formado por profesores, alumnos y personal auxiliar de la UniversidadPolitécnica de Madrid (UPM), en su mayor parte integrados en el Instituto Universitariode Investigación “Ignacio da Riva” (IDR), con la participación de otros grupos universi-tarios y de algunas personas y empresas del sector aeroespacial español. Se espera quela realización del proyecto contribuya a ampliar los conocimientos de las personas queparticipan en el proyecto, y que permita demostrar la capacidad de la UPM en el ámbitode la tecnología espacial.

Como antecedente de este proyecto cabe mencionar el satélite UPMSat-1, lanzado el7 de julio de 1995, que fue desarrollado por un grupo de profesores del Laboratorio deAerodinámica de la Escuela Técnica Superior de Ingenieros Aeronáuticos de la UPM. Lamisión se realizó con éxito, y demostró la capacidad del equipo promotor para llevar acabo un proyecto de esta naturaleza. El satélite se mantuvo operativo durante 213 días,y figura inscrito en el registro español ROLEU y en el de las Naciones Unidas comoUPM-Sat1/ROLEU 4.

Desde el punto de vista del software, el Grupo de Sistemas de Tiempo Real y Arquitec-tura de Servicios Telemáticos (STRAST) ha venido colaborando con la Agencia Europeadel Espacio (ESA/ESTEC) en proyectos relacionados con el desarrollo de software em-barcado en satélites. Es este marco se ha desarrollado el núcleo de sistema operativo detiempo real ORK+, orientado al desarrollo de sistemas de alta integridad en lenguaje Ada,que forma parte del entorno de desarrollo de software embarcado que se está poniendo enmarcha en ESA/ESTEC para futuras misiones espaciales.

Este documento tiene como objetivo definir los requisitos generales del software em-barcado y del software del segmento de tierra de la misión. Está dirigido a los responsablesde diseño y desarrollo de los subsistemas del satélite, y a los responsables del diseño ydesarrollo de la estación de control de la misión.

9

10 CAPÍTULO 4. DESCRIPCIÓN GENERAL

4.2. Funcionalidad

4.2.1. Software embarcadoLas funciones generales del software embarcado son las siguientes:

Control y determinación de actitud (ADCS).

Adquisición y procesado de telemetría (TM).

Descodificación y procesamiento de órdenes remotas (TC).

Supervisión y control de la plataforma.

Gestión del tiempo.

Detección, aislamiento y recuperación de fallos de los subsistemas de la plataforma(FDIR).

Adquisición de datos de mantenimiento (housekeeping).

Adquisición, gestión y almacenamiento de datos de la carga útil.

Registro de datos temporales.

4.2.2. Software del segmento de tierraLas funciones del software del segmento de tierra son:

Determinación de la posición del satélite.

Cálculos de parámetros orbitales y tiempos de paso.

Recepción, procesamiento y registro de datos de telemetría (TM).

Entrada de órdenes de operador y envío al satélite mediante mensajes de órdenesremotas (TC).

Gestión de la interfaz de operador.

4.2.3. Software del sistema de pruebas en tierraEl software del sistema de pruebas en tierra (EGSE, Electronic Ground Support Equip-

ment) realizará todas las funciones necesarias para las pruebas del satélite en tierra.

4.2.4. Modos de funcionamientoEl sistema se puede encontrar en diversos modos de funcionamiento [RD3], con dis-

tintas funciones asignadas a cada modo. La especificación detallada de los modos defuncionamiento y la funcionalidad asociada a cada uno de ellos se encuentra en el aparta-do 5.1.1.

4.3. RESTRICCIONES 11

4.3. RestriccionesEl desarrollo del software está sujeto a las siguientes restricciones:

Para el desarrollo del software embarcado se usará preferentemente un lenguajede alto nivel que permita analizar las propiedades temporales y de integridad delsoftware. Los lenguajes Ada [D2] y SPARK [D6] cumplen estas características.

Se usará preferentemente software libre, siempre que esté disponible, para las he-rramientas de desarrollo de software y para las bibliotecas externas que se incluyanen el sistema de software.

Se usarán técnicas de ingeniería de software adecuadas para facilitar la verificacióny validación del software, y para asegurar su mantenibilidad. Para ello se aplica-rán los principios de modularidad, jerarquía, y ocultamiento de información, entreotros [D7].

Se aplicarán los estándares ECSS-E-ST-40C [AD1] y ECSS-Q-ST-80C [AD2] aldesarrollo del software.

Las herramientas necesarias para la compilación y depuración de software debenestar disponibles durante un tiempo suficiente para poder efectuar el mantenimientodel mismo, y al menos hasta el final del año 2018.

Se usará el sistema internacional de unidades (SI) [AD8] para todas las unidades deingeniería del sistema.

4.4. Entorno de funcionamiento

4.4.1. Características del satéliteÓrbita: Polar heliosíncrona en torno a 700 km de altitud.

Inclinación de la órbita entre 96,5o y 102,5o.

Período: 100 min. El tiempo de eclipse es de 40 min.

Dimensiones de la plataforma: 500 mm × 500 mm × 600 mm (figura 4.1).

Masa: 50 kg.

Control de actitud: magnetómetros y magnetopares.

Control térmico: pasivo.

Perfil de potencia

• 5 paneles solares de GaAs montados en la plataforma. El panel de la carasuperior tiene la mitad de superficie que los laterales.

• Baterías de ion de litio.


• Tensión nominal en bus de alimentación 18–24 V.

• Potencia media en órbita 10 W (en régimen continuo).

• Potencia de pico en transmisor 10 W (15 minutos).

• Potencia de pico en carga útil 108 W (3 segundos)

• Tensión de alimentación de subsistemas: +5 V, ±15 V.

Comunicaciones

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

• Capacidad del enlace: 19200 bps.

Computador embarcado: basado en procesador LEON3 implementado en FPGA.

Lanzador: Vega.

Figura 4.1: Vista general de la plataforma del satélite UPMSat-2.

4.4. ENTORNO DE FUNCIONAMIENTO 13

4.4.2. Computador embarcadoEl satélite dispone de un único computador embarcado (OBC), en el cual se ejecutan

todas las funciones del software embarcado (apartado 4.2.1).La figura 4.2 muestra la estructura general del computador embarcado y sus conexio-

nes con sensores y actuadores.

SW system!

ADCS! TM!

actuadores!- magnetopares!

sensores!- magnetómetros!- sol!

TC!

OBC!

supervisión!

TMC!

carga de pago

(experimentos)!

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

gestión de carga de

pago!

Figura 4.2: Diagrama de contexto y funcionalidad del computador embarcado.


4.4.3. Interfaces de hardwareLas características de las interfaces de los sensores y otros subsistemas con el compu-

tador embarcado se detallan en el documento [RD5]. Estas interfaces son de varios tipos:

64 entradas analógicas (AI),

64 entradas digitales (DI),

64 salidas digitales (DO),

Interfaces serie RSR-232, RS-422, I2C y SPI.

4.5. Carga útilAl tratarse de una misión experimental, la carga útil del satélite consiste en un conjunto

de experimentos promovidos por distintas empresas y organizaciones.

Experimento 1 (MTS, micro-termal switch) Este experimento ha sido propuesto y estásiendo construido por IberEspacio. Su objetivo es comprobar el funcionamiento de uninterruptor térmico en versión miniaturizada. La función de este dispositivo consiste enevacuar el calor de un cierto componente hacia el espacio mediante un radiador, de formaque no se supere una cierta temperatura máxima, que se puede ajustar de antemano.

Experimento 2 (SCT, solar cell technology) El departamento TEC-EPG, Solar Gene-rator Section, de ESTEC ha propuesto un experimento consistente en instalar en una delas caras del UPMSat-2 un conjunto de cinco células solares de triple unión para suprueba en órbita (calibración, pruebas de degradación por rayos ultravioletas y oxígenoatómico).

Experimento 3 (MGM3, magnetómetro) Se ha llegado a un acuerdo con la empresaBartington para probar este magnetómetro en vuelo. Se trata de medir el campo magné-tico terrestre con este magnetómetro experimental y comparar los resultados con otrasmedidas tomadas con magnetómetros cualificados y con otros sensores del subsistema decontrol de actitud.

Experimento 4 (MRAD, monitorización del efecto de la radiación) Este experimentoha sido propuesto por la empresa TECNOBIT, y será diseñado conjuntamente con elgrupo STRAST/UPM. Su objetivo es observar el efecto de la dosis de radiación recibidaen órbita sobre el hardware del satélite. Para ello se hará una comprobación de errores enuna parte de la memoria del ordenador cada cierto intervalo de tiempo. Se mantendrá unregistro de las posiciones de memoria dañadas, y se realizará una estadística del númerode daños en función del tiempo y de la posición en la órbita. Se intentará ver el efecto dela denominada “anomalía del Atlántico Sur”.

Experimento 5 (SMA, actuadores) Este experimento ha sido diseñado por la empresaARQUIMEA. En el se combinarán actuadores (Pin-Puller y REACT) basados en alea-ciones con memoria de forma (SMA, Shape Memory Alloys), con el fin de demostrar enórbita su funcionamiento en el despliegue de dos booms.

4.6. SEGMENTO DE TIERRA 15

Experimento 6 (RW, rueda de reacción) Experimento propuesto por la empresa SSBV.Se trata de probar en órbita el funcionamiento de una rueda de reacción miniatura, deltamaño adecuado para su aplicación en el control de actitud de pequeños satélites.

Experimento 7 (SS6, sensores solares) El Instituto de Energía Solar (IES/UPM) estádesarrollando unas células solares especiales, de gran estabilidad, para emplearlas co-mo sensores de Sol sencillos y económicos. El experimento consiste en medir la corrientegenerada por las mencionadas células, dispuestas sobre cada una de las caras del saté-lite, para determinar el ángulo que forma cada cara del satélite con la dirección del Sol.Los resultados se compararán con las medidas realizadas por los magnetómetros.

Experimento 8 (CTM, control térmico) Este experimento forma parte de un programainterno del IDR/UPM. Se trata de obtener datos de funcionamiento del satélite y de sucomportamiento térmico, para refinar los métodos de cálculo y diseño térmico en los queIDR/UPM tiene una amplia experiencia.

Experimento 9 (BOOM) El IDR/UPM ha desarrollado un boom que se quiere calificary con el que se desea obtener experiencia en vuelo. El boom se usará, además, paraseparar un magnetómetro del cuerpo del satélite una distancia del orden de 0.2 m, conobjeto de reducir el posible efecto de contaminación magnética en las medidas.

Experimento 10 (MAC, control de actitud) Este experimento forma parte de un pro-grama interno del IDR/UPM para desarrollar esquemas robustos de control de actitudbasados en el campo magnético. Estos métodos se probarán en este vuelo como experi-mentos, con el fin de poderlos aplicar en próximos vuelos.

Experimento 11 (Sistema de separación.) El sistema de separación será desarrolladopor EADS CASA Espacio.

4.6. Segmento de tierra

4.6.1. Estación de tierraEl control del satélite en tierra se efectuará desde una estación de tierra (GS) con las

siguientes características:

Computador con arquitectura PC/ix86.

Sistema operativo GNU/Linux.

Interfaz gráfica.

Conexión a internet de alta velocidad.

Conexión a equipo transmisor/receptor de radio para TMTC.


4.6.2. Sistema de pruebas (EGSE)Para las pruebas en tierra se dispondrá de un sistema de pruebas (Electronic Ground

Support Equipment, EGSE) con las siguientes características:

Computador con arquitectura PC/ix86.

Sistema operativo GNU/Linux.

Interfaz gráfica.

Conexión a internet de alta velocidad.

Conexión serie para enlace con el OBC.

Conexión a equipo transmisor/receptor de radio para TMTC.

4.7. Supuestos y dependenciasEl desarrollo del software embarcado depende de la definición de la arquitectura de la

plataforma de hardware.El desarrollo del software de tierra depende de las características de la plataforma de

la estación de tierra.

Capítulo 5

Requisitos específicos

5.1. Requisitos sobre el funcionamiento del sistema

5.1.1. Modos de funcionamiento del satéliteREQ-1.1.1 Modos de funcionamiento en tierra. Antes del lanzamiento el satélite puedeestar en los siguientes estados:

Apagado (off).

Conexión para ensayos (test).

Espera para lanzamiento (await launch).

REQ-1.1.2 Modo de conexión para ensayos. En este modo el computador estará enfuncionamiento, con comunicaciones por conexión umbilical para diagnóstico antes ydespués de los ensayos ambientales.

Comentario. Este modo de funcionamiento se selecciona desde un equipo auxiliar conec-tado al satélite.

REQ-1.1.3 Modo de espera para lanzamiento. El sistema mantiene la alimentaciónde carga de goteo para baterías, sin posibilidad de comunicaciones. El computador semantiene apagado.

TBC (según requisitos del lanzador).

Comentario. Después del lanzamiento el satélite pasa a estado lanzamiento.

17

18 CAPÍTULO 5. REQUISITOS ESPECÍFICOS

REQ-1.1.4 Modos de funcionamiento en vuelo. Después del lanzamiento el satélitepuede estar en los siguientes estados:

Lanzamiento (launch).

Inicio (initialization).

Puesta en servicio (commissioning).

Seguro (safe).

Nominal (nominal).

Experimento (experiment).

Latencia (latency).

Radiofaro (beacon).

La figura 5.1 muestra el diagrama de estados del satélite en vuelo.

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 5.1: Diagrama de estados en vuelo.

5.1. REQUISITOS SOBRE EL FUNCIONAMIENTO DEL SISTEMA 19

REQ-1.1.5 Cambios de modo. Las transiciones entre modos de funcionamiento seránde dos tipos:

Automática: el software realizará la transición de forma automática al cumplirse lascondiciones previstas.

Manual: el software realizará la transición al recibir una orden remota.

Al realizarse el cambio de modo se ejecutarán todas las acciones de configuración nece-sarias, en su caso, para el nuevo estado.

Modo de lanzamiento (launch)

REQ-1.1.6 Funciones del modo de lanzamiento. El sistema de separación mantiene labatería desconectada. El computador se mantiene apagado.

REQ-1.1.6-1 Transiciones del modo de lanzamiento. La transición al estado de lanza-miento se efectuará de forma automática al producirse el lanzamiento.

La salida del modo de lanzamiento se efectuará de forma automática cuando, trasproducirse la separación, haya transcurrido un cierto tiempo, medido mediante un tem-porizador. A continuación el sistema pasa al modo de inicio, proporcionando tensión alcomputador.

Modo de inicio (initialization)

REQ-1.1.7 Funciones del modo de inicio . En este modo se ejecutarán las funcionessiguientes:

Carga e inicio del software del satélite.

Configuración de los elementos del satélite.

Comprobación de la separación del lanzador.

REQ-1.1.7-1 Transiciones del modo de inicio. La transición al modo de inicio seefectuará por alguna las siguientes causas:

Vencimiento del temporizador de separación. Este temporizador se activa automá-ticamente al producirse la separación del lanzador.

Señal de inicio (reset) de hardware. Esta señal se activará si expira el temporizadorde guardia (watchdog) del sistema.

Telecontrol.

La salida del modo de inicio se efectuará de forma automática cuando se hayan com-probado todos los subsistemas. Se distinguen dos transiciones de salida posibles:

La primera vez que se inicia el sistema se pasa al modo de puesta en servicio.

En cualquier otro caso se pasa directamente al modo seguro.


Modo de puesta en servicio (commissioning)

REQ-1.1.8 Funciones del modo de puesta en servicio . En este modo se ejecutarán lassiguientes funciones:

a) Supervisión y control de la plataforma

Toma de medidas inicial y comprobación del estado de los subsistemas.

b) Control de actitud (ADCS)

Determinación de la velocidad de giro del satélite.

Reducción de la velocidad de giro hasta un valor aceptable.

Estabilización de la velocidad de giro.

c) Telemedida y telecontrol (TTC)

Comprobación del estado del subsistema TTC

Envío de mensajes de telemetría iniciales.

d) Almacenamiento y registro de datos

Inicio o reanudación del registro de datos.

e) Carga útil

TBD.

REQ-1.1.8-1 Transiciones del modo de puesta en servicio. La transición al estado depuesta en servicio se efectuará por alguna de las siguientes causas:

Automáticamente desde el estado de inicio, la primera vez que arranca el sistema.

Telecontrol desde el estado seguro.

La salida del modo de puesta en servicio se efectuará de forma automática cuandose hayan comprobado todos los subsistemas y se haya reducido la velocidad de giro delsatélite hasta un valor aceptable, o bien cuando haya transcurrido el tiempo máximo es-pecificado [S-5.1.1]. La transición tiene como destino el modo seguro, en cualquier caso.

REQ-1.1.8-2 Duración máxima del modo de puesta en servicio. El tiempo máximoen que el sistema puede permanecer en modo de puesta en servicio es un parámetro deconfiguración, que se definirá teniendo en cuenta el comportamiento dinámico del satélitey la configuración del subsistema de control de actitud.


Modo seguro (safe mode)

REQ-1.1.9 Funciones del modo seguro. En modo seguro se ejecutarán las siguientesfunciones:


Toma de medidas básica y comprobación del estado de los subsistemas.


Determinación de la actitud del satélite.

Control de actitud básico.


Comunicaciones con baja velocidad.

Telecontrol básico.


Registro de datos y sucesos.

e) Carga útil

No se realizan experimentos.

Comentario. En este modo se realizan las funciones mínimas para mantener el funciona-miento del satélite con bajo consumo, con el fin de ahorrar energía y permitir la carga delas baterías.

REQ-1.1.9-1 Transiciones del modo seguro. La transición al modo seguro se efectuarápor cualquiera de las siguientes causas:

Terminación correcta del inicio del sistema, si no es la primera vez que arrancadespués del lanzamiento.

Terminación correcta del modo de puesta en servicio.

Detección de algún problema en las funciones de puesta en servicio. Por ejemplo,si no se consigue reducir la velocidad de giro del satélite.

Vencimiento del tiempo máximo de puesta en servicio.

Detección de errores graves en alguno de los modos de funcionamiento normales(nominal o experimentación).

Detección de nivel bajo de tensión en las baterías.

Telecontrol.

La salida del modo seguro se efectuará por las siguientes causas:


Telecontrol.

Detección de nivel crítico de baterías, para pasar al modo de latencia.

Detección de pérdida de comunicaciones durante un tiempo crítico, para pasar almodo de radiofaro.

Modo de latencia (latency mode)

REQ-1.1.10 Funciones del modo de latencia. En modo de latencia el computadorpermanecerá apagado para permitir la carga de las baterías.

REQ-1.1.10-1 Transiciones del modo de latencia. La transición al estado de latenciase efectuará por cualquiera de las siguientes causas:

Detección de nivel crítico de tensión en las baterías.

Telecontrol.

La salida del modo de latencia se efectuará por las siguientes causas:

Vencimiento de un temporizador de hardware.

REQ-1.1.10-2 Tiempo de permanencia en modo de latencia. El tiempo máximo enque el sistema permanece en modo de latencia es un parámetro de configuración, que sedefinirá teniendo en cuenta las características de las baterías y del subsistema de controlde potencia.

Modo de radiofaro (beacon mode)

REQ-1.1.11 Funciones del modo de radiofaro. En modo de radiofaro se ejecutarán lassiguientes funciones:


Toma de medidas básica y comprobación del estado de los subsistemas.


Control de actitud básico.


Comunicaciones con baja velocidad.

Emisión de un mensaje de localización (beep) periódico.

Telecontrol básico (escucha).




e) Carga útil


Comentario. Este modo es igual que el modo seguro, excepto en lo que se refiere a laemisión del mensaje de localización (beep).

REQ-1.1.11-1 Transiciones del modo de radiofaro. La transición al estado de radiofarose efectuará por las siguiente causas:

Vencimiento del tiempo máximo sin recibir mensajes de telecontrol.

Telecontrol.

La salida del modo de radiofaro se efectuará por la siguiente causa:

Recepción de un mensaje de telecontrol. A continuación se pasa al modo seguro.

Nivel crítico de la tensión de las baterías. EN este caso se pasa al modo de latencia.

REQ-1.1.11-2 Tiempo de paso al modo de radiofaro. El tiempo máximo en que elsistema puede estar sin recibir mensajes de telecontrol antes de pasar al modo de radiofaroes un parámetro de configuración.

Modo nominal (nominal mode)

REQ-1.1.12 Funciones del modo nominal. En modo nominal se ejecutarán las siguien-tes funciones:


Toma de medidas periódica y comprobación del estado de los subsistemas.


Control de actitud nominal.


Comunicaciones con velocidad normal.

Telecontrol completo.



e) Carga útil



Comentario. En este modo se realizan las funciones normales del satélite.

REQ-1.1.12-1 Transiciones del modo nominal. La transición al estado nominal seefectuará por la siguiente causa:

Telecontrol desde el modo seguro.

La salida del modo nominal se efectuará por las siguientes causas:

Telecontrol.

Detección de errores graves en alguno de los subsistemas.

Detección de nivel bajo de baterías, para pasar al modo seguro.

Detección de pérdida de comunicaciones durante un tiempo crítico, para pasar almodo de radiofaro.

Vencimiento del temporizador de guardia (watchdog timer), en cuyo caso se emiteuna señal de reset al computador, que arranca de nuevo en modo de inicio.

Modo de experimentos (experiment mode)

REQ-1.1.13 Funciones del modo de experimentos. TBD

REQ-1.1.13-1 Transiciones del modo de experimentos. La transición al modo deexperimentos se efectuará por la siguiente causa:

TBDLa salida del modo de experimentos se efectuará por las siguientes causas:TBD

5.1.2. Órdenes remotas (telecontrol, telecommands)REQ-1.2.1 Verificación de órdenes remotas. El software verificará que las órdenes

recibidas desde tierra son correctas, independientemente del modo de operación en quese encuentre.

REQ-1.2.2 Ejecución de órdenes remotas. El software producirá las órdenes internasnecesarias para la ejecución de las órdenes recibidas desde tierra. Sólo se ejecutarán lasórdenes que sean admisibles en el modo de funcionamiento actual.

Comentario. Las órdenes remotas que sean correctas en cuanto a su formato y paráme-tros pero no se puedan ejecutar en el modo de funcionamiento en que se encuentre elsoftware cuando se reciban serán ignoradas.


REQ-1.2.3 Órdenes remotas generales. Se consideran los tipos de mensajes de órdenesremotas que figuran en el cuadro 5.1.

Comentario. Pueden definirse órdenes adicionales para los diferentes subsistemas.

Cuadro 5.1: Órdenes remotas

Orden Parámetros DescripciónConfigure TBD Modificación de los parámetros de configura-

ción del software.Commission TBD Pasa a modo de puesta en servicio.OpenLink TBD Inicio de comunicación.Envía a tierra los datos:

- Estado de la plataforma (housekeeping)- Registro (logbook).- Estado de magnetopares (health table)- Reloj de misión (mission clock)

Nominal TBD Pasa a modo nominal.Safe TBD Pasa a modo seguro.Latency TBD Pasa a modo de latencia.Logbook TBD Envía a tierra del contenido del registro.Test TBD Verificación para ensayos en tierra.

5.1.3. Adquisición y procesado de telemetríaREQ-1.3.1 Adquisición de datos periódica. El software leerá periódicamente los sen-

sores de datos de mantenimiento de la plataforma (housekeeping) para supervisar su fun-cionamiento. Estos datos se relacionan en el cuadro 5.2.

Cuadro 5.2: Datos de mantenimiento (housekeeping).

Tipo Variable Número de sensoresTemperaturas Caras del satélite 6

Baterías 2Magnetómetro 3OBC 3Experimentos 9

Actitud Salida MGT 3Intensidad en MGT 1Células solares 6

Energía Tensión en bus 1Tensión en batería 1Intensidad en batería 1Intensidad en paneles solares 5

Total 41


REQ-1.3.2 Telemetría de estado del sistema y medidas periódicas. El software en-viará periódicamente un mensaje de telemetría de estado del sistema con las medidas delos datos de mantenimiento de la plataforma.

REQ-1.3.3 Telemetría de suceso. Cuando se produzca un suceso que dé lugar al envíode un mensaje de telemetría, el software incluirá en el mensaje los valores de datos queestén relacionados con el suceso en cuestión.

Comentario. Los cambios de modo y de estado de las baterías son ejemplos de este tipode sucesos.

REQ-1.3.4 Telemetría de petición. Cuando se reciba una orden de inicio de comunica-ción, el software generará mensajes de telemetría con el siguiente contenido:

Estado del sistema (datos de mantenimiento).

Registro del sistema.

Tabla de estado de los magnetopares.

Valor del reloj de la misión.

REQ-1.3.5 Telemetría sin cobertura. Cuando el satélite esté fuera de la cobertura de laestación de tierra, los mensajes de telemetría de estado, telemetría de suceso y telemetríade petición se sustituirán por informes que se almacenarán en el archivo de registro dedatos.

REQ-1.3.6 Telemetría con cobertura. Cuando el satélite esté dentro de la cobertu-ra de la estación de tierra, los mensajes de telemetría de estado, telemetría de suceso ytelemetría de petición podrán enviarse a la estación de tierra a medida que se generen.

Los mensajes almacenados en el registro de datos podrán enviarse a la estación detierra si se recibe una orden remota solicitándolo.

Los datos enviados a partir del archivo de registro se distinguirán claramente de losdatos de telemetría.

REQ-1.3.7 Telemetría en modos de funcionamiento degradados . Cuando el saté-lite se encuentre en un modo de funcionamiento degradado (seguro o radiofaro) sólo seenviarán mensajes de telemetría básicos. TBC

REQ-1.3.8 Telemetría en modos de funcionamiento de comprobación. Cuando elsatélite se encuentre en un modo de funcionamiento de comprobación (inicio o puesta enservicios) sólo se enviarán mensajes de telemetría iniciales. TBC

REQ-1.3.9 Telemetría en modo radiofaro. Cuando el sistema se encuentre en modoradiofaro se enviará periódicamente una señal de aviso a tierra. El período de esta señales un parámetro de configuración.

5.1.4. Control de actitudREQ-1.4.1 ADCS. El subsistema de software ADCS realizará las funciones de determi-nación y control de actitud cuando el sistema se encuentre en modo nominal.


REQ-1.4.2 Sistema de referencia. El software de ADCS utilizará el sistema de referen-cia de coordenadas definido para el satélite.

REQ-1.4.3 Equipos del subsistema ADCS. El subsistema ADCS utilizará los siguien-tes sensores y actuadores:

Magnetómetros. Hay un magnetómetro activo, aunque puede haber otros dos adi-cionales, de distintos fabricantes. Cada uno de ellos proporciona medidas de la in-tensidad del campo magnético terrestre en las direcciones de los tres ejes de refe-rencia.

Para el control de actitud se usará únicamente el magnetómetro activo.

Sensores solares. Hay 6 sensores solares, uno en cada cara del satélite, que propor-cionan un indicación de la orientación del satélite con respecto al sol o, lo que esequivalente, la dirección aparente del sol con respecto al sistema de referencia delsatélite.

Magnetopares. Hay 3 pares de bobinas que generan un campo magnético en cadauna de las direcciones de los ejes de referencia, haciendo girar al satélite al interac-tuar con el campo magnético terrestre.

REQ-1.4.4 Funciones del ADCS. Cuando el ADCS esté activo, e realizará las siguientesfunciones:

1. Determinación de actitud a partir de los datos recogidos mediante el magnetómetroactivo.

2. Cálculo del algoritmo de control de actitud.

3. Emisión de las acciones correspondientes a los magnetopares.

La figura 5.2 muestra el esquema funcional del subsistema ADCS.

Comentario. El ADCS incluirá la supervisión del límite de intensidad de los magnetopa-res.

control de actitud!magnetómetro!

medidas!campo

magnético!campo magnético

terrestre!

sensores solares!

medidas sensores solares!

magnetopares!activación

magnetopares!actitud del

satélite!

límite de intensidad!

posición del Sol!

Figura 5.2: Diagrama funcional del subsistema de control de actitud.


REQ-1.4.5 Órdenes remotas del ADCS. Las órdenes remotas de telecontrol para elsubsistema ADCS serán las siguientes:

Sincronización del tiempo.

Recepción de la posición del satélite.

Órdenes para los sensores y actuadores.

• Configuración de magnetómetro.

• Configuración de sensores solares.

• Configuración de magnetopares.

Actualización de efemérides.

Actualización de parámetros de configuración del ADCS.

Lectura de parámetros de configuración del ADCS.

REQ-1.4.6 Mensajes del ADCS. Los mensajes de telemetría asociados al ADCS son:

Envío de medidas de los sensores

Datos orbitales: actitud y posición orbital del satélite.

Datos de estado del ADCS: campo magnético, posición solar, etc.

Parámetros de configuración del ADCS.

REQ-1.4.7 ADCS-períodos. Las funciones del sistema ADCS se ejecutarán con lossiguientes períodos:

Modo activo Modo pasivoLectura de magnetómetros 5 s TBDLectura de sensores solares 10 s TBDDeterminación de actitud TBD TBDControl y accionamiento de magnetopares TBD TBD

5.1.5. Supervisión y control de la plataformaREQ-1.5.1 Adquisición de datos. Según el modo de funcionamiento, se realizarán las

siguientes funciones:

Modo nominal

1. Adquisición de datos del sistema de control térmico.

2. Adquisición de datos del sistema de energía eléctrica.

3. Transición a modo seguro cuando la tensión de las baterías es inferior a TBD V.


Modo de seguridad

1. Adquisición de datos del sistema de control térmico.

2. Adquisición de datos del sistema de energía eléctrica.

3. Transición a modo de latencia cuando la tensión de las baterías es inferior aTBD V.

4. Transición a modo nominal cuando . . . TBD.

Modo de latencia

1. Transición a modo TBD.

Modo radiofaro

1. TBD.

REQ-1.5.2 Períodos de adquisición de datos.Las funciones de adquisición de datos se ejecutarán con los siguientes períodos:Tipo Modo nominal Modo seguro Modo latencia Modo radiofaroTemperatura 60 s TBD TBD TBDTensión 20 s TBD TBD TBDIntensidad 20 s TBD TBD TBDMagnetómetro 5 s TBD TBD TBDCélulas solares 10 s TBD TBD TBD

REQ-1.5.3 Supervisión de fallos. El sistema comprobará que todos los valores de lossensores tienen valores aceptables. Cuando se encuentren valores inaceptables se notifi-cará mediante un mensaje de telemetría y en caso necesario se cambiará a modo seguro ode latencia.

5.1.6. Almacenamiento y registro de datosREQ-1.6.1 Registro de datos de la plataforma. Los datos adquiridos según 5.1.5 se

almacenarán en un registro en memoria permanente, con indicación del tiempo en que seha efectuado la medida correspondiente.

REQ-1.6.2 Registro de telemetría. Los mensajes de telemetría enviados a tierra se alma-cenarán en un registro en memoria permanente, con indicación del número de secuenciay del tiempo de envío.

REQ-1.6.3 Registro de órdenes remotas. Los mensajes de órdenes remotas recibidosse almacenarán en un registro en memoria permanente, con indicación del número desecuencia y del tiempo de recepción.

5.1.7. Intercambio de datos con la carga útilComentario. Incluye almacenamiento temporal.

TBC


5.1.8. Control térmicoComentario. No hay control térmico, sólo medidas de temperatura.

5.1.9. Control de energíaComentario. Medidas y cambios de modo en función del nivel de las baterías.

TBC

5.2. Requisitos sobre las interfaces del sistemaTBC

5.3. Requisitos de adaptación a la misiónN/A

5.4. Requisitos sobre recursos computacionales

5.4.1. Computador embarcado (OBC)REQ-4.1.1 Computador. El software de vuelo se ejecutará en un computador embarca-do con las siguientes características:

Procesador LEON3 con FPU a 266 MHz [D9].

4 MB de memoria SRAM

1 MB de memoria EEPROM

64 canales de entrada analógicos de 12 bits (algunos de 16 bits).

64 líneas de entrada/salida digital.

4 líneas de E/S serie RS-422

2 líneas de E/S serie RS-232

2 interfaces I2C

3 interfaces SPI

REQ-4.1.2 Condiciones de arranque del computador embarcado. El computadorejecutará el código de arranque en los siguientes casos:

Estando apagado, al recibir alimentación.

Estando encendido, al recibir una señal de reinicio (reset) por hardware.

5.5. REQUISITOS DE SEGURIDAD DE ACCESO 31

REQ-4.1.3 Arranque del computador embarcado. Al arrancar el computador embar-cado se ejecutará la siguiente secuencia de acciones:

1. Copia del software embarcado desde la unidad de almacenamiento secundario (SSD)a la memoria RAM.

2. Comprobación del estado de los dispositivos.

3. Paso al software embarcado en estado de inicio.

REQ-4.1.4 Temporizador de separación (separation timer). El sistema tendrá un tem-porizador de hardware, que se activará cuando se produzca la separación del lanzador.Al vencer este temporizador se activará la alimentación del computador embarcado. Laduración de la temporización es un parámetro de configuración del sistema.

REQ-4.1.5 Temporizador de latencia (separation timer). El sistema tendrá un tem-porizador de hardware, que se activará cuando se produzca el paso al estado de latencia.Al vencer este temporizador se activará la alimentación del computador embarcado. Laduración de la temporización es un parámetro de configuración del sistema y debe sersuficiente para restaurar la carga de las baterías.

REQ-4.1.6 Temporizador de guardia (watchdog timer). El sistema tendrá un tempo-rizador de guardia (watchdog timer) realizado en hardware, que se actualizará periódica-mente desde el software para evitar su vencimiento. En caso de que que el temporizadorvenza se generará una señal de reinicio (reset) del computador.

REQ-4.1.7 Reloj de misión (mission clock). El sistema tendrá un reloj de hardware quecontará el tiempo transcurrido desde la separación.

5.4.2. Utilización de recursos de cómputoREQ-4.2.1 Utilización-procesador. El factor de utilización del procesador no sobrepa-sará el 50% del tiempo de cómputo.

REQ-4.2.2 Utilización-RAM. La utilización de la memoria RAM no sobrepasará el50% de su capacidad.

5.4.3. Requisitos de softwareREQ-4.3.1 Cadena de compilación. El software se compilará con la cadena de compi-lación GNATforLEON, versión TBD.

REQ-4.3.2 Plataforma de software. El software se ejecutará sobre el entorno de eje-cución de GNAT para LEON3, versión TBD, y el núcleo de tiempo real ORK+, ver-sión TBD.

5.5. Requisitos de seguridad de accesoN/A


5.6. Requisitos de seguridad de funcionamientoTBC

5.7. Requisitos de fiabilidad y disponibilidadTBC

5.8. Requisitos de calidadTBC

5.9. Requisitos y restricciones sobre el diseño

5.9.1. Restricciones sobre la arquitectura del softwareREQ-9.1.1 RCM. El uso de tareas concurrentes estará restringido de acuerdo con el

modelo computacional de Ravenscar [D4].

5.9.2. Uso de estándaresREQ-9.2.1 ECSS-E-ST-40. El software se desarrollará de acuerdo con lo prescrito en

la norma ECSS-E-ST-40C [AD1].

5.9.3. Uso de componentes existentesTBD

5.9.4. Uso de componentes comerciales (COTS)TBD

5.9.5. Uso de estándares de diseñoREQ-9.5.1 ADDL. El diseño del software se describirá mediante el lenguaje AADL,

versión 2 [D1].

5.9.6. Uso de estándares de datosTBD

5.10. REQUISITOS SOBRE EL FUNCIONAMIENTO DEL SOFTWARE 33

5.9.7. Uso de lenguajes de programaciónREQ-9.7.1 Ada. El software embarcado se desarrollará preferentemente en Ada 2005 [D8]

REQ-9.7.2 Subconjunto seguro. Se definirá un subconjunto seguro del lenguaje Adade acuerdo con la guía para el uso de este lenguaje en sistemas de alta integridad [D3],que incluirá el perfil de Ravenscar [D4] para el uso de tareas concurrentes.

REQ-9.7.3 Otros lenguajes. En los casos en que sea necesario se podrán implementaralgunos módulos funcionales en lenguaje C.

5.9.8. Normas de estiloREQ-9.8.1 Estilo de programas en Ada. Para el lenguaje Ada se seguirán las normas

del documento Ada Quality and Style Guide [D5].

TBC

5.9.9. Flexibilidad y expansiónTBD

5.9.10. Normas de interfaces persona-máquina (HMI)TBD

5.10. Requisitos sobre el funcionamiento del softwareREQ-10.1 Parámetros de configuración. Los parámetros de configuración del softwaretendrán unos valores iniciales.

REQ-10.2 Inicio de valores de software. Cuando se arranque el software se iniciaránlos siguientes elementos:

Variables y objetos;

estado de las funciones de control;

estado del satélite;

estado de los dispositivos de entrada y salida.

Cada vez que se inicie el software se establecerá la configuración inicial en todos lossubsistemas del satélite,


5.11. Requisitos sobre el mantenimiento del softwareREQ-11.1 Modificación de parámetros de software. Será posible modificar los pará-

metros del software mediante teleórdenes.

Comentario. Los parámetros del software pueden ser valores de constantes, valores ini-ciales de variables, o incluso código de subprogramas.

REQ-11.2 Modificación del contenido de la memoria. Será posible modificar el con-tenido de una zona de la memoria RAM mediante teleórdenes. La orden indicará la direc-ción de memoria inicial, la longitud de la zona de memoria que se modifica, y el contenidode la misma.

REQ-11.3 Volcado del contenido de la memoria. Será posible copiar a tierra el con-tenido de una zona de la memoria RAM mediante telemetría. La orden correspondienteindicará la dirección de memoria inicial y la longitud de la zona de memoria. El envío delcontenido de la memoria a la estación de tierra se podrá realizar en más de un paquete detelemetría.

5.12. Requisitos sobre la observabilidad del sistema y delsoftware

REQ-12.1 Información sobre acciones del software. El sistema de software informarámediante paquetes de telemetría de todas las acciones significativas que efectúe, de formacompleta, no ambigua, y marcada temporalmente.

Capítulo 6

Verificación, validación e integracióndel sistema

6.1. Requisitos sobre el proceso de verificación y valida-ción

TBC

6.2. Enfoque de la validaciónTBC

6.3. Requisitos de validaciónTBC

6.4. Requisitos de verificaciónTBC

35

36 CAPÍTULO 6. VERIFICACIÓN, VALIDACIÓN E INTEGRACIÓN DEL SISTEMA

UPMSAT-2 Especiﬁcación del sistema de...

Documents

Transcript of UPMSAT-2 Especiﬁcación del sistema de...