upmsat-2 softwarestr/proyectos/upmsat2/documentac... · upmsat-2 software requirements ... rb-5...

UPMSAT-2 SoftwareRequirements Baseline

Software System SpecificationVersion 2.2

10 October 2014

UNIVERSIDAD POLITÉCNICA DE MADRID

GRUPO DE SISTEMAS DE TIEMPO REAL

Y ARQUITECTURA DE SERVICIOS TELEMÁTICOS

Revisión 674— October 10, 2014 12:36:53

Copyright c© DIT/UPM 2014

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/.

State: Review

Written by: Juan A. de la PuenteJuan Zamorano

Reviewed by: Alejandro AlonsoÁngel Sanz

Modificaciones

Version/Revision Date Purpose Author2.2 10-10-2014 V&V requirements added J.A. de la Puente2.1 15-07-2014 TTC requirements updated J.A. de la Puente2.0 17-03-2014 English version J.A. de la Puente1.8 16-12-2013 Versión revisada J.A. de la Puente1.7 21-01-2013 Versión revisada J.A. de la Puente, J. Zamorano1.6 05-09-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.4 24-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.2 09-02-2012 Versión revisada J.A. de la Puente, J. Zamorano1.1 20-01-2012 Versión para revisión J.A. de la Puente, J. Zamorano1.0 27-10-2011 Borrador inicial J.A. de la Puente, J. Zamorano

Members of the UPMSat2 project

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/

Contents

1 Introduction 11.1 Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.2 Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.3 Content . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

2 References 32.1 Applicable documents . . . . . . . . . . . . . . . . . . . . . . . . . . . 32.2 Reference documents . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32.3 Other documents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

3 Terms, definitions and abbreviated terms 53.1 Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53.2 Notation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53.3 Abbreviated terms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

4 General description 94.1 Product perspective . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94.2 General capabilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

4.2.1 On-board software . . . . . . . . . . . . . . . . . . . . . . . . . 104.2.2 Ground station software . . . . . . . . . . . . . . . . . . . . . . 104.2.3 Electronic ground support software . . . . . . . . . . . . . . . . 104.2.4 System modes . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

4.3 General constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114.4 Operational environment . . . . . . . . . . . . . . . . . . . . . . . . . . 11

4.4.1 Overall architecture . . . . . . . . . . . . . . . . . . . . . . . . . 114.4.2 On-board computer software . . . . . . . . . . . . . . . . . . . . 114.4.3 Ground station software . . . . . . . . . . . . . . . . . . . . . . 154.4.4 Electronic ground support equipment (EGSE) . . . . . . . . . . . 15

4.5 Assumptions and dependencies . . . . . . . . . . . . . . . . . . . . . . . 16

5 Specific requirements 175.1 General . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175.2 Capabilities requirements . . . . . . . . . . . . . . . . . . . . . . . . . . 17

5.2.1 Functions of the on-board software system . . . . . . . . . . . . 175.2.2 Operating modes . . . . . . . . . . . . . . . . . . . . . . . . . . 20

5.3 System interface requirements . . . . . . . . . . . . . . . . . . . . . . . 245.4 Adaptation and missionization requirements . . . . . . . . . . . . . . . . 245.5 Computer resource requirements . . . . . . . . . . . . . . . . . . . . . . 24

i

5.5.1 Computer hardware resource requirements . . . . . . . . . . . . 245.5.2 Computer hardware resource utilization requirements . . . . . . . 255.5.3 Computer software resource requirements . . . . . . . . . . . . . 25

5.6 Security requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . 265.7 Safety requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 265.8 Reliability and availability requirements . . . . . . . . . . . . . . . . . . 265.9 Quality requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . 265.10 Design requirements and constraints . . . . . . . . . . . . . . . . . . . . 265.11 Software operations requirements . . . . . . . . . . . . . . . . . . . . . 275.12 Software maintenance requirements . . . . . . . . . . . . . . . . . . . . 275.13 System and software observability requirements . . . . . . . . . . . . . . 27

6 Verification, validation and system integration 296.1 Verification and validation process requirements . . . . . . . . . . . . . . 29

6.1.1 On-board software . . . . . . . . . . . . . . . . . . . . . . . . . 296.1.2 Ground segment software . . . . . . . . . . . . . . . . . . . . . 30

6.2 Validation approach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 306.3 Validation requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . 316.4 Verification requirements . . . . . . . . . . . . . . . . . . . . . . . . . . 31

A Requirements validation matrix 33

ii

List of requirements

RB-1 Housekeeping data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17RB-2 Attitude control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17RB-3 Telemetry . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18RB-4 Telecommands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18RB-5 Time management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19RB-6 Fault detection, isolation, and recovery (FDIR) . . . . . . . . . . . . . . . 19RB-7 Payload data management . . . . . . . . . . . . . . . . . . . . . . . . . . 19RB-8 Event and data logging . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19RB-9 Off mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21RB-10 Test mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21RB-11 Await launch mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21RB-12 Launch mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21RB-13 Initialization mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21RB-14 Commissioning mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22RB-15 Safe mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22RB-16 Nominal mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22RB-17 Experiment mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23RB-18 Latency mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24RB-19 Beacon mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24RB-20 On-board computer (OBC) . . . . . . . . . . . . . . . . . . . . . . . . . . 24RB-21 Hardware clocks and timers . . . . . . . . . . . . . . . . . . . . . . . . . 25RB-22 Processor utilization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25RB-23 Storage utilization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25RB-24 Software platform . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25RB-25 Identification of the ground station . . . . . . . . . . . . . . . . . . . . . 26RB-26 Criticality level . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26RB-27 Reliability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26RB-28 Availability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26RB-29 Reusability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26RB-30 Software standards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26RB-31 Programming languages . . . . . . . . . . . . . . . . . . . . . . . . . . . 27RB-32 Ravenscar computational model . . . . . . . . . . . . . . . . . . . . . . . 27RB-33 Stand-alone operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27RB-34 No in-flight maintenance . . . . . . . . . . . . . . . . . . . . . . . . . . . 27RB-35 System state logging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27RB-36 Verification and validation processes . . . . . . . . . . . . . . . . . . . . 29RB-37 Testing environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29RB-38 Testing environment for ground segment software . . . . . . . . . . . . . 30

iii

RB-39 Validation methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30RB-40 On-board software testing configurations . . . . . . . . . . . . . . . . . . 30RB-41 Ground segment software testing configurations . . . . . . . . . . . . . . 30RB-42 Applicable validation methods . . . . . . . . . . . . . . . . . . . . . . . . 31RB-43 Verification support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

iv

List of Figures

4.1 General view of the UPMSat-2 satellite. . . . . . . . . . . . . . . . . . . 94.2 Top-level architecture of the UPMSat2 mission software. . . . . . . . . . 114.3 Attitude control reference. . . . . . . . . . . . . . . . . . . . . . . . . . 124.4 OBC context diagram. . . . . . . . . . . . . . . . . . . . . . . . . . . . 134.5 Ground station context diagram. . . . . . . . . . . . . . . . . . . . . . . 154.6 Software validation facility context diagram. . . . . . . . . . . . . . . . . 16

5.1 ACS functional diagram. . . . . . . . . . . . . . . . . . . . . . . . . . . 185.2 Operating modes of the UPMSat-2 on-board software. . . . . . . . . . . 20

v

Chapter 1

Introduction

1.1 PurposeThis the Software System Specification (SSS) document, as defined in ECSS-E-ST-40C [AD1],for the UPMSat2 software

1.2 ScopeThis document covers the following software systems:

• On-board computer (OBC) software.

• Ground station (GS) software

• Electronic ground support equipment (EGSE) software

1.3 ContentThis document is organised as follows, as per ECSS-E-ST-40C appendix D:

• Chapter 2 contains a list of the applicable and reference documents.

• Chapter 3 contains terms, definitions, and abbreviated terms.

• Chapter 4 contains a general description of the UPMSat2 system.

• Chapter 5 contains specific software requirements for the UPMSat2 system.

• Chapter 6 contains verification, validation, and integration requirements for theUPMSat2 software.

1

2 CHAPTER 1. INTRODUCTION

Chapter 2

References

2.1 Applicable documents[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 synchro-nization 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] ECSS-E-70-41A Space engineering — Ground systems and operations — Teleme-try and telecommand packet utilization. January 2003.

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

2.2 Reference documents[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.

3

4 CHAPTER 2. REFERENCES

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

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

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

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

[RD9] UPMSat2 — Communication Interface. EMX-UPS-TN-001. July 2014.

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

2009. Available at www.sae.org.

[D2] ITU. Specification and Design Language – Overview of SDL-2010, 2011. Recom-mendation ITU-T Z.100.

[D3] ITU. Abstract Syntax Notation One (ASN.1), 2008. Recommendations ITU-TX.680–683.

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

[D5] ISO/IEC TR 15942:2000 — Guide for the use of the Ada programming languagein high integrity systems, 2000.

[D6] 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).

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

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

[D9] Mathworks. Simulink, 2013.

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

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

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

www.sae.org

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

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

Chapter 3

Terms, definitions and abbreviatedterms

3.1 DefinitionsThe terms defined in [AD1] and [AD2] will be used as needed.

3.2 NotationA logical model of the system, capturing the most important aspects of the specification,has been built using AADL [D1].

3.3 Abbreviated termsAADL Arquitecture Analysis Design Language.

AD Applicable document.

ADCS Attitude determination and control subsystem.

ADL Amateur band downlink.

AI Analog input.

AOCS Attitude and orbit control system.

AUL Amateur band uplink.

COTS Commercial-off-the-shelf.

CPU Central processing unit.

DDR2-SDRAM Double data rate synchronous dynamic random-access memory inter-face, version 2.

DHU Data handling unit.

5

6 CHAPTER 3. TERMS, DEFINITIONS AND ABBREVIATED TERMS

DI Digital input.

DO Digital output.

ECSS European Cooperation on Space Standardization.

EGSE Electronic Ground Support Equipment.

ESA European Space Agency.

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.

HMI Human-machine interface.

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

I/O Input-ouput.

LEO Low Earth orbit.

MAC Magnetic-field Attitude Control.

MGM Magnetometer(s).

MGT Magnetorquer(s).

MRAD Monitoring of the effects of radiation.

MTS Micro-Thermal Switch.

OBC On-board computer.

OBDH On-board data handling.

ORK Open Ravenscar Real-Time kernel.

RAM Random-access memory.

RD Reference document.

RDL Research band downlink.

ROM Read-only memory.

RW Reaction wheel.

ROLEU Registro de Objetos lanzados al espacio ultraterrestre (Spanish).

3.3. ABBREVIATED TERMS 7

SCT Solar Cell Technology.

SMA Shape Memory Alloys.

SPS Separation System.

SRS Software Requirements Specification.

SS Subsystem.

SS Solar sensor.

SSD Solid-state drive.

SSS Software System Specification.

TBC To be completed.

TBD To be defined.

TC Telecommand.

TM Telemetry.

TMC Thermal control.

TTC Telemetry and telecommand.

UPM Universidad Politécnica de Madrid.

VHDL VHSIC hardware description language.

VHSIC Very-high-speed integrated circuits.

8 CHAPTER 3. TERMS, DEFINITIONS AND ABBREVIATED TERMS

Chapter 4

General description

4.1 Product perspectiveThe aim of the UPMSat-2 project is to develop a micro-satellite mission that can be usedas an in-orbit technology demonstration platform. The project is being carried out by ateam of researchers, students, and auxiliary staff at Universidad Politécnica de Madrid(UPM).

The project is led by the “Ignacio da Riva” research institute (IDR), with the participa-tion of the STRAST research group, TECNOBIT, and other research groups and industrialcompanies. STRAST is in charge of software development, and TECNOBIT is in chargeof developing the on-board computer hardware and other electronic subsystems for themission.

Figure 4.1 shows a general view of the UPMSat-2 satellite design.

X+! Y+!

Z+!

Z-!

Figure 4.1: General view of the UPMSat-2 satellite.

9

10 CHAPTER 4. GENERAL DESCRIPTION

4.2 General capabilities

4.2.1 On-board softwareThe aim of the UPMSat2 on-board software is to monitor and control the operation of thesatellite platform. Its main functions are:

• Platform monitoring and control, including acquisition of housekeeping data (HK)

• Attitude control (ADC)

• Encoding and transmission of telemetry messages (TM)

• Reception, decoding and execution of telecommands (TC)

• Time management

• Fault detection, isolation, and recovery (FDIR)

• Payload data management

• Data and event logging

4.2.2 Ground station softwareThe aim of the ground station software is to monitor and control the operation of themission. Its main functions are:

• Determination of the satellite position

• Computation of orbit parameters and observation times

• Reception, decoding and processing of telemetry messages

• Operator interface management

• Composition, encoding and transmission of remote telecommands

4.2.3 Electronic ground support softwareThe EGSE (Electronic Ground Support Equipment) software is aimed at controlling andmonitoring all ground-based tests run on the satellite. It includes a software validationfacility (SVF) supporting the execution of software validation tests.

4.2.4 System modesThe system operates in different modes according to the overall conditions of the mission.The detailed specification of the system modes and the functions to be executed in eachmode can be found in section 5.2.2.

4.3. GENERAL CONSTRAINTS 11

4.3 General constraints1. The on-board software will be developed using a high-integrity subset of the Ada

language [D4, D5]. Tasking may be used as restricted by the Ada Ravenscar pro-file [D6].

2. Free software will be used whenever possible for the development tools.

3. All the tools used in the development of the UPMSat2 software must be availableat least until the end of 2018.

4. The International System of Units (SI) [AD9] will be used for all engineering val-ues.

4.4 Operational environment

4.4.1 Overall architectureFigure 4.2 shows the overall architecture of the UPMSat2 mission software. The on-boardsoftware system is related with the ground station system by means of telecommands andtelemetry messages exchanged over a radio link.

OBC GS TC!!

TM!!

GS_OBC!!

Figure 4.2: Top-level architecture of the UPMSat2 mission software.

4.4.2 On-board computer softwareSatellite platform characteristics

• Orbital parameters

– Noon sun-synchronous low Earth orbit (LEO)

– Altitude: 600 km

– Inclination: 98o

– Period: 97 min

– Eclipse time: 36 min

– Visibility from ground station: ≈ 10 min, 2 times a day.


• Platform envelope (see figure 4.1)

– Dimensions: 500 mm × 500 mm × 600 mm (figure 4.1).

– Mass: 50 kg.

• Attitude control

– Active control based on the Earth magnetic field

– Reference attitude: Z-axis normal to orbit plane, X and Y axes rotating aroundZ axis (figure 4.3).

– Sensors: magnetometers

– Actuators: magnetorquers

Figure 4.3: Attitude control reference.

• Thermal control

– Passive thermal control, based on isolating materials.

• Electric power

– Power generation: 5 GaAs solar panels. The panel on the upper (Z+) side ishalf the size of the panels on the lateral sides.

– Maximum generated power: 57 W

– Average generated power: 31.5 W

– Lithium-ion battery with a capacity of 18 Ah

– Nominal voltage of power bus: 18–24 V

– Stabilized voltage supply for subsystems: +5 V, ±15 V

• Telecommunications

– UHF U band (AMSAT): 435.00−438.00MHz

∗ Uplink (telecommands): max 4800 bps∗ Downlink (housekeeping data): max 9600 bps

– UHF space research band: 400.15−401.0MHz

∗ Downlink (experiment data): max 9600 bps

4.4. OPERATIONAL ENVIRONMENT 13

On-board computer hardware

There is a single on-board computer (OBC), with following characteristics:

• FPGA-based LEON3 CPU

• 4 MB SRAM

• 1 MB EEPROM

• Serial interfaces: RS-232, RS-422, SPI, I2C

• Device interfaces: 64 analog input channels, 64 digital I/O signals

Figure 4.4 summarizes the operating environment of the on-board computer.

OBC!ADC actuators!-  magnetorquers"-  reaction wheel"

ADC sensors!-  magnetometres"-  solar cells"

Radio!-  uplink (TC)"-  downlink (TM)"

Housekeeping sensors!-  temperatures"-  voltages"-  currents"

Experiments!

Figure 4.4: OBC context diagram.


Payload

The payload of the UPMSat2 satellite mission consists of a number of experiments, someof them including specific physical devices. The complete list of experiments follows:

1. MTS (Micro Thermal Switch). Test a MTS device, provided by IberEspacio.1 Thedevice conducts heat when enabled. The experiment consists in dissipating heatfrom some component to a radiator so as to keep the component temperature belowa limit.

2. SCT (Solar Cell Technology). Test a set of solar cells provided by ESA/ESTECTEC-EPG.2

3. MGM (Magnetometer). Test a magnetometer provided by Bartington3. The magne-tometer is used for nominal ADCS. The experiment consists in collecting additionalmeasurements for calibration.

4. MRAD (Radiation Effect Monitoring). Characterize the effect of radiation on hard-ware, by testing a range of memory cells. Proposed by TECNOBIT and STRAST/UPM.

5. SMA (Shape Memory Alloys). Test the use of SMA provided by Arquimea4 inactuators for the deployment of two booms.

6. RW (Reaction Wheel). Test the use of a reaction wheel provided by SSBV5 forattitude control.

7. SS6 (Solar Sensors). Test a set of solar cells provided by IES/UPM6 as attitudesensors.

8. TMC (Thermal Control Data). Get thermal data for thermal design of spacecraft atIDR/UPM.

9. BOOM (Extension boom). Test a boom designed by IDR/UPM.

10. MAC (Magnetic Attitude Control). Test alternative attitude control methods de-signed by IDR/UPM.

11. SPS (Separation System). Test a separation system developed by Astrium EADS.7

1www.iberespacio.es.2www.esa.int/estec.3www.bartington.com.4www.arquimea.com.5www.ssbv.com.6www.ies.upm.es.7www.astrium.eads.net.

www.iberespacio.es

www.esa.int/estec

www.bartington.com

www.arquimea.com

www.ssbv.com

www.ies.upm.es

www.astrium.eads.net

4.4. OPERATIONAL ENVIRONMENT 15

4.4.3 Ground station softwareThere is one ground station located in the IDR building. Is approximate position is40.4063o N, 3.8320o W.8

The ground station has a dedicated computer with the following characteristics:

• PC/x86 architecture with graphical display

• Internet connection

• Serial interface for connection to radio equipment

• GNU/Linux operating system.

Figure 4.5 shows the operating context of the ground station computer.

GS!Operator interface!

Radio!-  uplink (TC)"-  downlink (TM)"

Internet"

Figure 4.5: Ground station context diagram.

4.4.4 Electronic ground support equipment (EGSE)The electronic ground support equipment (EGSE) includes all the test equipment that isrequired for the validation of the electronic subsystems of the satellite, including the OBC.The components of the EGSE that support the validation of on-board software make upthe software validation facility (SVF).

The SVF is based on a dedicated computer with the following characteristics:

• PC/x86 architecture with graphical display

• Internet connection

• Serial interface for connection to radio equipment

• Serial interface for connection to the OBC

• GNU/Linux operating system.

8Referred to the WGS84 datum.


Figure 4.6 shows the operating context of the SVF.

SVF!Operator interface!

Internet!

OBC!

Figure 4.6: Software validation facility context diagram.

4.5 Assumptions and dependenciesThe development of on-board software depends on the hardware architecture of the OBCand other satellite subsystems.

The development of ground software depends on the hardware architecture of theground station.

Chapter 5

Specific requirements

5.1 GeneralThe requirements specified in this section apply only to on-board software. Ground stationsoftware is covered separately.

5.2 Capabilities requirements

5.2.1 Functions of the on-board software systemRB-1 Housekeeping data

The software system will monitor the following kinds of housekeeping data by periodicsampling of sensors:

• Temperature

– Satellite sides

– Battery

– Magnetometers

– Computer

– Experiments

• Power

– Battery voltage

– Bus voltage

– Current at battery

– Current at solar panels

The housekeeping data measurements will be checked for validity. Values outside thevalid range will be reported.

17

18 CHAPTER 5. SPECIFIC REQUIREMENTS

RB-2 Attitude control

The attitude of the spacecraft will be controlled using measurements of the Earth mag-netic field provided by magnetometers. A control algorithm will be used to compute therequired correcting actions provided by magnetorquers.

The magnetometer readings and the output to magnetorquers will be checked for va-lidity. Values outside the valid range will be reported.

Figure 5.1 shows the functional configuration of the attitude control system.

magnetometer! controller! torquers!

satellite dynamics!

disturbances!

magnetic field!

estimation!

Figure 5.1: ACS functional diagram.

RB-3 Telemetry

Basic telemetry messages shall be broadcast periodically when the satellite is out of vis-ibility of the ground station or when it is operating in beacon mode. Basic telemetrymessages shall be sent on the amateur band downlink, and include the following dataitems:

• Identification of the satellite.

• Basic housekeeping data.

Nominal telemetry messages may be sent to ground during the visibility interval.These messages shall be transmitted on the research band downlink, and may be of thefollowing kinds:

• Identification of the satellite.

• Event messages, including errors detected since the previous visibility interval.

• Data messages, including an extract of telemetry data acquired since the previousvisibility interval.

• Experiment messages, including result data for the experiments performed.

5.2. CAPABILITIES REQUIREMENTS 19

RB-4 Telecommands

Telecommands may be received from the ground station during the visibility interval(see 4.4.2). Telecommands shall be transmitted on the amateur band uplink.

Telecommands may be executed immediately, as soon as possible after reception, orbe programmed to be executed at some future time.

Telecommands will allow the ground station to perform at least the following func-tions:

• Change the mode of operation (see 5.2.2).

• Change the configuration parameters of the software.

• Change the configuration of sensors and actuators. This includes:

– Disable a sensor that is not operating correctly.

– Enable a previously disable sensor.

– Define the validity range of a sensor reading.

• Change the control parameters of the attitude control algorithm.

• Start and stop the execution of an experiment, possibly with execution parameters.

Telecommands will be checked for validity upon reception. Only valid telecommandswill be executed. Validity checks will include the identification of the sending station.

RB-5 Time management

Mission time, defined as the time elapsed from separation, will be used for stamping allevents and data recording, and telemetry messages.

RB-6 Fault detection, isolation, and recovery (FDIR)

Faults detected during the operation of the system will be recorded as significant events.Subsequent actions may include mode changes or hardware resets of the OBC.

A hardware watchdog timer will be used to detect possible failures of the computersystem. If the timer expires, a hardware reset will be issued in order to restart the OBC.

RB-7 Payload data management

The system will record data from experiments and report them to the ground station bymeans of telemetry messages.

The kind of data to be acquired for each experiment is to be further refined.

RB-8 Event and data logging

The system will record all significant events and report them to the ground station bymenas of telemetry messages.

The system will record a significant summary of the housekeeping, attitude control,and experiment data, and send them to the ground station by means of telemetry messages.


5.2.2 Operating modesThe system operating modes are depicted in figure 5.2. The meaning of each mode isdefined in the following paragraphs.

Flight!

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!

Ground!

Off! Test!

Await Launch!

Figure 5.2: Operating modes of the UPMSat-2 on-board software.


Ground operating modes

Before launch, the OBC may be in the following modes:

• Off mode (no power is supplied to the OBC).

• Test mode.

• Await launch mode.

RB-9 Off mode

When the satellite is in the off mode the OBC is switched off.

RB-10 Test mode

While in this mode the OBC is connected to the SVF computer by means of a test link,and the SVF can load and execute software on the OBC.

RB-11 Await launch mode

When the system is in the await launch mode the OBC is switched off, with no powerbeing supplied to it and consequently no software executing. The batteries are in tricklecharge mode, and the radio equipment is off.

From the point of view of software, this mode is functionally equivalent to the launchmode. The transition to the latter is implicitly executed when the launch starts.

Flight operating modes

After launch, the OBC may be in the following modes:

• Launch mode.

• Initialization mode.

• Commissioning mode.

• Safe mode.

• Nominal mode.

• Experiment mode.

• Latency mode.

• Beacon mode.

RB-12 Launch mode

When the system is in launch mode the OBC is switched off. After separation is complete,a hardware separation timer is automatically started. When the timer expires the OBC ispowered up, and the initialization mode is entered.


RB-13 Initialization mode

Initialization mode is entered when the OBC is powered on after separation, or after alatency period following a critical battery condition. Alternatively, it can be entered as aconsequence of a hardware reset caused by the expiration of the watchdog timer, or as theresult of a telecommand.

The functions to be executed in initialization mode are:

• Load the on-board software and start execution.

• Configure all the hardware devices in the OBC boards.

• Configure the radio equipment.

• Configure all the software subsystems.

After the first initialization the system changes to commissioning mode. On subse-quent initializations, safe mode is entered.

RB-14 Commissioning mode

In commissioning mode all the satellite subsystems are checked and commissioned asneeded. This mode is entered after the first initialization of the system, or by a telecom-mand.

When the commissioning is complete, the system changes to safe mode. A maximumcommissioning time will be defined, after which the system changes to safe mode even ifcommissioning is not complete.

Any error detected during commissioning must be reported as a significant event.

RB-15 Safe mode

When the system is in safe mode, only the minimal functions that are required for theoperation of the satellite with a low power consumption are executed, in order to enablebatteries to be charged.

Safe mode is entered when a low battery warning signal is received, or when an er-ror is detected in nominal or experiment mode. Other situations that make the systemswitch to safe mode are the end of initialization or commissioning, or the reception of atelecommand requesting such change.

The functions that are executed in safe mode are a subset of the nominal mode func-tions, including at least the following capabilities:

• Housekeeping measurements, possibly at a reduced rate.

• Attitude control, possibly with a reduced accuracy.

• Telemetry messages with current state and event log (no backlog data).

• Telecommand reception.

No experiments are performed in safe mode.


RB-16 Nominal mode

When the system is nominal mode, all the satellite functions execute normally. This modeis normally entered upon reception of a telecommand or after the end of an experiment.

No experiments are executed in nominal mode. Performing an experiment requires atelecommand requiring a change to experiment mode.

The system leaves this mode when one of the following conditions occur:

• Telecommand requiring a mode change to another mode.

• Low battery warning signal causing a change to safe mode.

• Critical battery signal causing a change to latency mode.

• System error causing a change to safe mode.

• Communication loss, causing a change to beacon mode.

• Watchdog timer signal. A hardware reset signal is sent to the OBC, which restartsin initialization mode.

RB-17 Experiment mode

When the system is in experiment mode, one of the experiments is performed. This modeis entere when requested by a telecommand. A programmed telecommand can be used tostart an experiment when there is no visibility from the ground station.

The functions that are executed in this mode are:

1. MTS: measure temperature in component under test.

2. SCT: collect solar cell data.

3. MGM: collect magnetometer data.

4. MRAD: test a range of memory cell and store the results, marking the cells that aredamaged.

5. SMA: Report correct deployment of boom.

6. RW: use the reaction wheel as an actuator for attitude control.

7. SS6: use the solar cells as attitude sensors.

8. TMC: collect thermal data.

9. BOOM: Report correct deployment of boom.

10. MAC: use alternative attitude control algorithm.

11. SPS: no functions to be executed. The separation system is tested by the fact thatthe separation has been completed.


The system leaves the experiment mode when the experiment is completed, thus re-turning to nominal mode. An experiment can be terminated by a telecommand, or whena maximum time allowed to it has ended. Other termination conditions are the detectionof an error or a low battery signal, which make the system change to safe mode, or a lossof communication causing a change to beacon mode.

RB-18 Latency mode

When the system is in latency mode the OBC is switched off in order to enable batteriesto be charged. This mode is entered when a critical battery warning signal is received,after which the power board automatically disconnects the power supply to the computer.

The system stays in this mode for a fixed time interval. A hardware latency timer isused to signal the end of this time interval, after which the power supply is resumed andthe computer is switched on. The software then starts in initialization mode.

RB-19 Beacon mode

The beacon mode is entered when a loss of ground communications is detected by soft-ware. When the system is in this mode, it transmits a periodic telemetry message (see3) until a response is received from the ground station. The system then changes to safemode.

5.3 System interface requirementsThe external interfaces of the software system are defined in the interface requirementsdocument (IRD).

5.4 Adaptation and missionization requirementsN/A

5.5 Computer resource requirements

5.5.1 Computer hardware resource requirementsRB-20 On-board computer (OBC)

The flight software will run on a single on-board computer with the following hardwareresources:

• LEON3 processor with FPU at 266 MHz minimum clock frequency.

• 4 MB SRAM

• 1 MB EEPROM

• 64 analog input channels.

5.5. COMPUTER RESOURCE REQUIREMENTS 25

• 64 digital I/O ports.

• 4 RS-422 serial interface ports.

• 2 RS-232 serial interface ports.

• 2 I2C interface ports.

• 3 SPI interface ports.

RB-21 Hardware clocks and timers

The following hardware clocks and timers will be provided:

• Separation timer. This timer is armed at separation from launcher. When it expires,the OBC is powered on and the initialization mode is entered.

• Latency timer. This timer is started when the latency mode is entered, after the oc-currence of a critical battery warning signal. When it expires, the OBC is poweredon and the initialization mode is entered.

• Watchdog timer. This timer will be automatically started by the hardware when theOBC is powered on. The counter value will be reloaded periodically by software.If the timer expires, a hardware reset signal will be issued to the OBC in order torestart its operation.

• Mission clock. It shall keep track of the time elapsed since separation.

5.5.2 Computer hardware resource utilization requirementsRB-22 Processor utilization

The utilization factor of the processor will be kept below 70 %.

RB-23 Storage utilization

The utilization of RAM storage will be kept below 80 % of its capacity.

5.5.3 Computer software resource requirementsRB-24 Software platform

The software will run on the GNATforLEON3 runtime system and the ORK+ kernel.The GNATforLEON GPL 2011 compilation chain will be used to generate the exe-

cutable software image.


5.6 Security requirementsRB-25 Identification of the ground station

Telecommands will carry some kind of digital identification in order to ensure that theyhave been issued by a valid ground station.

5.7 Safety requirementsRB-26 Criticality level

The on-board computer subsystem, including the software system, is classified as criti-cality level B (mission critical), as per ECSS-Q-ST-80C [AD2].

The ground station software system is classified as criticality level C.

5.8 Reliability and availability requirementsRB-27 Reliability

The software system shall be designed so as to tolerate hardware and software faultsas long as the underlying hardware may support reconfiguration after faults have beendetected.

RB-28 Availability

The software system shall operate as required in this document for as long as the OBChardware is operating properly.

5.9 Quality requirementsRB-29 Reusability

The software will be designed using a modular approach, and low-level details will beencapsulated so as to enable reuse in similar satellite systems.

5.10 Design requirements and constraintsRB-30 Software standards

The following software standards will be used:

• ECCS-E-ST-40C Space Engineering — Software [AD1].

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

• ISO/IEC 8652:2012 Information Technology — Programming Languages — Ada[D4].

5.11. SOFTWARE OPERATIONS REQUIREMENTS 27

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

• ISO/IEC TR 24718:2005 Guide for the use of the Ada Ravenscar Profile in highintegrity systems [D6].

RB-31 Programming languages

The Ada programming language [D4] will be used for all software units, unless otherwiserequired.

A safe subset of the language will be used. The subset will be defined based on theISO/IEC TR 15942 and TR 24718 documents.

The attitude control algorithm and other functional components may be coded in C asrequired by automatic code generation tools.

RB-32 Ravenscar computational model

Tasking will be restricted as defined in the Ada Ravenscar profile [D4, ap. D]

5.11 Software operations requirementsRB-33 Stand-alone operation

The software will operate stand-alone on the satellite platform. The executable image willbe stored in non-volatile memory and copied to RAM on initialization.

5.12 Software maintenance requirementsRB-34 No in-flight maintenance

No in-flight reprogramming or any other kind of in-flight maintenance is required, asidefrom modifications of software parameters by telecommand.

5.13 System and software observability requirementsRB-35 System state logging

The event and data logging functionality will include all mode changes, errors detected,and the current operating mode, in telemetry messages.

Chapter 6

Verification, validation and systemintegration

6.1 Verification and validation process requirementsRB-36 Verification and validation processes

Verification and validation activities shall be planned and executed as per ECCS-E-ST-40C [AD1]. Separate validation and verification plans will be set up for on-board softwareand ground segment software.

6.1.1 On-board softwareRB-37 Testing environment

On-board software shall be tested on a Software Validation Facility (SVF) including thefollowing components:

• An engineering model of the OBC. Validation tests will be executed on this modelbefore using the actual OBC.

• The flight version of the OBC will be required later in the validation process inorder to execute acceptance tests.

• Electronic ground support equipment (EGSE), as introduced in section 4.2.3. TheEGSE will be used as described in 6.2 below.

The EGSE will include a model of the satellite dynamics that will be used to testthe ADCS software, and a model of the radio equipment that will be used to test theTTC software.

• Host computer for controlling the execution of tests and analysing the results.

29

30 CHAPTER 6. VERIFICATION, VALIDATION AND SYSTEM INTEGRATION

6.1.2 Ground segment softwareRB-38 Testing environment for ground segment software

The ground segment software will be tested using software-in-the-loop simulator of thespacecraft for as long as possible. Real spacecraft hardware will be used for the final testphases.

6.2 Validation approachRB-39 Validation methods

Testing will be used to validate the system requirements whenever feasible. Otherwiseinspection or review by a validation team may be acceptable.

Regression testing will be exercised after any software modifications.

RB-40 On-board software testing configurations

The following configurations of the SVF will be used for validation at different thestphases:

• Unit and integration testing: physical processor or processor emulator, as well asdevice and spacecraft dynamic simulators if needed (software-in-the-loop).

• Software validation testing: computer board with physical processor and devicesimulators (processor-in-the-loop). Physical devices will be used for validation ofreal-time and hardware interface requirements. The spacecraft dynamics will besimulated.

• Software qualification testing: engineering model of OBC and physical devices(hardware-in-the-loop). The spacecraft dynamics may be simulated.

• Software acceptance and system testing: real hardware, with simulated environmentapproaching real operating conditions (hardware-in-the-loop).

• In-flight acceptance: real spacecraft with real acceptance conditions

RB-41 Ground segment software testing configurations

• A simulated spacecraft environment will be used for unit and integration testing,software validation, and software qualification.

• The real spacecraft and communications link will be used for acceptance and systemtesting.

6.3. VALIDATION REQUIREMENTS 31

6.3 Validation requirementsRB-42 Applicable validation methods

Appendix A contains a matrix with the validation methods to be used for each of therequirements defined in section 5.2.

6.4 Verification requirementsRB-43 Verification support

All documents related to the development of on-board software will be available in asystem database that can be accessed by all the members of the project.

A shared data repository supporting version control is an acceptable implementationof such a database.

32 CHAPTER 6. VERIFICATION, VALIDATION AND SYSTEM INTEGRATION

Appendix A

Requirements validation matrix

Requirement Validation methodRB-1 Housekeeping data TestingRB-2 Attitude control TestingRB-3 Telemetry TestingRB-4 Telecommands TestingRB-5 Time management TestingRB-6 Fault detection, isolation, and recovery (FDIR) TestingRB-7 Payload data management TestingRB-8 Event and data logging TestingRB-9 Off mode ReviewRB-10 Test mode ReviewRB-11 Await launch mode ReviewRB-12 Launch mode ReviewRB-13 Initialization mode TestingRB-14 Commissioning mode TestingRB-15 Safe mode TestingRB-16 Nominal mode TestingRB-17 Experiment mode TestingRB-18 Latency mode ReviewRB-19 Beacon mode TestingRB-20 On-board computer (OBC) ReviewRB-21 Hardware clocks and timers ReviewRB-22 Processor utilization AnalysisRB-23 Storage utilization AnalysisRB-24 Software platform ReviewRB-25 Identification of the ground station TestingRB-26 Criticality level ReviewRB-27 Reliability ReviewRB-28 Availability ReviewRB-29 Reusability ReviewRB-30 Software standards ReviewRB-31 Programming languages ReviewRB-32 Ravenscar computational model Review

33

34 APPENDIX A. REQUIREMENTS VALIDATION MATRIX

Requirement Validation methodRB-33 Stand-alone operation ReviewRB-34 No in-flight maintenance ReviewRB-35 System state logging TestingRB-36 Verification and validation processes ReviewRB-37 Testing environment ReviewRB-38 Testing environment for ground segment software ReviewRB-39 Validation methods ReviewRB-40 On-board software testing configurations ReviewRB-41 Ground segment software testing configurations ReviewRB-42 Applicable validation methods ReviewRB-43 Verification support Review

upmsat-2 softwarestr/proyectos/upmsat2/documentac... · upmsat-2 software requirements ... rb-5...

Documents