FINAL DEGREE PROJECT

Title:UPMSat-2 Satellite’s Platform Management softwaresubsystem: Design, validation, implementation andverification

Author:Víctor Tomás Pérez

Tutor:Alejandro Alonso Muñoz

Tribunal:

President: D. Juan Antonio de la Puente AlfaroVocal: D. José Mª del Alamo RamiroSecretary: D. Alejandro Antonio Alonso MuñozSubstitute: D. Miguel Angel de Miguel Cabello

Date:

Calification:

UNIVERSIDAD POLITÉCNICA DE MADRIDESCUELA TÉCNICA SUPERIOR DE INGENIEROS

DE TELECOMUNICACIÓN

FINAL DEGREE PROJECT

UPMSat-2 Satellite’s Platform Managementsoftware subsystem: Design, validation,

implementation and verification

VÍCTOR TOMÁS PÉREZ

Madrid, 2014

Copyright © V. Tomás Pérez, A. Alonso Muñoz 2014All rights reserved

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

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

Quisiera dedicar este trabajo a todos aquellos que me han apoyado a lo largo de mi vida y carrera. Ami familia, en especial a mis padres, que siempre me han apoyado y ayudado en lo bueno y en lo malo. ACarol, por estar siempre a mi lado. A mi hermano, mis abuelas Margarita y Alfonsa, mi tía Mari, mi tío Raúl,mis tíos y mis primos. A mis compañeros de carrera y amigos, Edu, Diego, Imad, Sonia, David Rodríguez,Carlos, David y Dani, que han hecho de esta etapa la mejor de mi vida. A mis amigos de siempre. A laspersonas que forman parte del grupo de investigación STRAST, por haber sido de gran ayuda y hacer queaprenda mucho y disfrute de este trabajo con un ambiente muy agradable. Y por último pero no menosimportante, a dos personas que estarían orgullosas de compartir este momento conmigo, mi tío Dani y miabuelo Juan.

A todos, gracias.

"... No te dejes arrastrar por los dogmas, que es lo mismo que vivir con los resultados del pensamientode otras personas. No dejes que el ruido de las opiniones de otros ahoguen completamente tu voz interior.Y más importante, ten el valor de seguir a tu corazón y a tu intuición. Ellos, de algún modo, ya saben en loque verdaderamente te quieres convertir. Todo lo demás es secundario."

Steve Jobs

Summary

This Final Degree Project shows the development of the UPMSat-2 micro-satellite’sPlatform Management software subsystem. It is a project accomplished by researchers,professors and students from the Technical University of Madrid (UPM) aimed at deve-loping a micro-satellite which can be used as a technological demonstration platform inorbit.

Real-Time Systems and Telematic Services Architecture group (STRAST) is the re-search team in charge of developing the flight and ground segments software of the mis-sion. The purpose of this report is to develop the Platform Management software subsys-tem of the flight segment of the satellite.

Platform Management subsystem consists of the monitoring, validation, checking, andcommunication of the state of the different components (hardware and software) of thesatellite. Particularly, functions such as periodic sensor read (magnetic field, temperatureand voltage among others), sensor measurements validation, interesting measurementsstorage, and satellite subsystems check will be made.

Inside this context, the student has carried out the following steps:

Development of the UPMSat-2’s Platform Management flight segment softwarefunctions.

Fulfilment of the European Space Agency standards for software development.

Implementation of the high integrity system development techniques.

Project documentation generation.

According to the following methodology:

System specification analysis.

Study of high integrity systems development techniques.

Design of the software components to be developed.

Implementation of the components, using Ada and SPARK.

Software validation: tests and analysis of response time.

Keywords: UPMSat-2, satellite, space, platform manager, subsystem, module, software,real-time, high integrity, embedded systems, on-board software, STRAST, UPM.

I

Resumen

Este Trabajo de Fin de Grado presenta el desarrollo del subsistema de Gestión dela Plataforma del micro satélite universitario UPMSat-2. Es un proyecto realizado porinvestigadores y alumnos de la Universidad Politécnica de Madrid (UPM) cuyo objetivoes desarrollar un micro-satélite como plataforma de demostración tecnológica en órbita.

El grupo de Sistemas de tiempo real y arquitectura de servicios telemáticos (STRAST)es el equipo de investigación dentro del proyecto encargado de desarrollar el software delos segmentos de vuelo y de tierra de la misión. El propósito de este trabajo es desarrollarlos componentes del segmento de vuelo encargados de la gestión de la plataforma.

El subsistema de gestión de la plataforma consiste en la monitorización, validación,comprobación y comunicación del estado de los distintos componentes (hardware y soft-ware) que forman el satélite. En concreto, se realizarán funciones tales como la lecturaperiódica de sensores (campo magnético, temperatura y voltaje entre otros), validación dedichos sensores y sus medidas, almacenamiento de las medidas oportunas y la comproba-ción de los distintos subsistemas del satélite.

Dentro de este ámbito, el alumno ha trabajado los siguientes puntos:

Desarrollo de las funciones de la gestión de la plataforma del segmento de vuelo deUPMSat2.

Seguimiento de las normas de desarrollo de software de la European Space Agency.

Aplicación de las técnicas de desarrollo de sistemas de alta integridad.

Generación de la documentación del proyecto.

Siguiendo la siguiente metodología:

Análisis de la especificación del sistema.

Estudio de técnicas de desarrollo de sistemas de alta integridad.

Diseño de los componentes software a desarrollar.

Implementación de los componentes, empleando Ada y SPARK.

Validación del software: pruebas y análisis del tiempo de respuesta.

Palabras clave: UPMSat-2, satélite, espacio, gestor plataforma, subsistema, módulo,software, tiempo real, alta integridad, sistemas empotrados, software embarcado, STRAST,UPM.

II

Contents

Summary I

Resumen II

Acronyms VIII

1 Introduction 11.1 Background . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

1.2 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

1.3 Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

1.4 Document structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2 Technological basis 52.1 UPMSat-2 introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2.2 Real Time and High Integrity systems . . . . . . . . . . . . . . . . . . . 6

2.3 Processing software & hardware . . . . . . . . . . . . . . . . . . . . . . 9

2.3.1 Open Ravenscar Kernel . . . . . . . . . . . . . . . . . . . . . . . 9

2.3.2 LEON3 processor . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.3.3 On-Board Computer . . . . . . . . . . . . . . . . . . . . . . . . 10

3 UPMSat-2: Requirements Analysis 113.1 ESA Standards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

3.2 Software documents: SDD, SRS and SSS . . . . . . . . . . . . . . . . . 12

4 Platform Management subsystem: Design 134.1 Design methodology . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

4.1.1 SDL Diagrams . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

4.1.2 TASTE Tool . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

4.2 Designing the subsystem . . . . . . . . . . . . . . . . . . . . . . . . . . 15

4.2.1 Simplified model example of the Platform Manager module . . . 20

5 Platform Management subsystem: Validation 265.1 Validation methodology . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

5.2 Validating the subsytem . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

6 Platform Management subsystem: Implementation 34

III

6.1 Implementation methodology . . . . . . . . . . . . . . . . . . . . . . . . 34

6.1.1 Ada programming language . . . . . . . . . . . . . . . . . . . . 34

6.1.2 Ravenscar profile and SPARK programming language . . . . . . 35

6.1.3 GNAT and GPS . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

6.2 Implementing the subsytem . . . . . . . . . . . . . . . . . . . . . . . . . 36

7 Platform Management subsystem: Verification 387.1 Verification methodology . . . . . . . . . . . . . . . . . . . . . . . . . . 38

7.1.1 Software Validation Facility . . . . . . . . . . . . . . . . . . . . 38

7.1.2 Hardware In the Loop . . . . . . . . . . . . . . . . . . . . . . . 39

7.1.3 Rapita Verification Suite . . . . . . . . . . . . . . . . . . . . . . 40

7.2 Verifying the subsystem . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

8 Conclusions 428.1 Future Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

Bibliography 44

IV

List of Figures

1.1 Flight Segment Software Architecture . . . . . . . . . . . . . . . . . . . 2

2.1 UPMSat-2 launch vehicle, orbit and satellite. . . . . . . . . . . . . . . . 6

2.2 Task deadline structure. . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.3 Periodic task scheme. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.4 Sporadic task scheme. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2.5 UPMSat-2 Mode diagram. . . . . . . . . . . . . . . . . . . . . . . . . . 9

3.1 Software process according to ECSS-E-ST-40C standard. . . . . . . . . . 12

4.1 V development cycle. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

4.2 Computer drivers diagram. . . . . . . . . . . . . . . . . . . . . . . . . . 19

4.3 Simplified high level software architecture. . . . . . . . . . . . . . . . . 21

4.4 SDL PM Main operating thread runtime. . . . . . . . . . . . . . . . . . . 23

4.5 SDL PM Battery temperature sensors reading runtime. . . . . . . . . . . 24

5.1 GUI example. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

5.2 First Validation - Initial PM Operating Mode. . . . . . . . . . . . . . . . 28

5.3 First Validation - Modification of the PM Operating Mode from the Man-ager Module. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

5.4 Second Validation - Initial validation step. . . . . . . . . . . . . . . . . . 29

5.5 Second Validation - Second validation step. . . . . . . . . . . . . . . . . 30

5.6 Second Validation - Third validation step. . . . . . . . . . . . . . . . . . 30

5.7 Third Validation - Initial validation step. . . . . . . . . . . . . . . . . . . 31

5.8 Third Validation - Second validation step. . . . . . . . . . . . . . . . . . 32

5.9 Third Validation - Third validation step. . . . . . . . . . . . . . . . . . . 33

5.10 Third Validation - Fourth validation step. . . . . . . . . . . . . . . . . . . 33

6.1 Execution architecture of the UPMSat-2. . . . . . . . . . . . . . . . . . . 36

7.1 Software validation architecture. . . . . . . . . . . . . . . . . . . . . . . 39

V

7.2 HIL architecture. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

VI

List of Tables

4.1 Sensor sampling periods. . . . . . . . . . . . . . . . . . . . . . . . . . . 17

4.2 Sensor ranges example. . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

5.1 Second validation settings. . . . . . . . . . . . . . . . . . . . . . . . . . 29

5.2 Third validation settings. . . . . . . . . . . . . . . . . . . . . . . . . . . 31

VII

Acronyms

AADL Architecture Analysis and Design Language

ACN ASN.1 Control Notation

ADC AnalogDigital Converter

ADCS Attitude Determination and Control System

AI Analog Inputs

ASN.1 Abstract Syntax Notation One

DI Digital Inputs

DO Digital Outputs

EEPROM Electrically Erasable Programmable Read Only Memory

ECSS European Cooperation for Space Standardization

ESA European Space Agency

ESTEC European Space Research and Technology Centre

FPGA Field Programmable Gate Array

GNAT GNU NYU Ada Translator

GUI Graphic User Interface

HIL Hardware In the Loop

I2C InterIntegrated Circuit

IDR Instituto Ignacio da Riva

ITUT International Telecommunication Union, Telecommunication Standardization

VIII

Sector

MGM Magnetometer

MHz Megahertzs

MT Magnetorques

MTS MicroThermal Switch

OBC OnBoard Computer

ORK Open Ravenscar Realtime Kernel

OS Operating System

PM Platform Manager

SCT Solar Cell Technology

SDL Specification Description Language

SOC System On a Chip

SPARC Scalable Processor ARChitecture

SPI Serial Peripheral Interface

SRAM Static Random Access Memory

SSS software system specification

STRAST Grupo de Sistemas de Tiempo Real y Arquitectura de Servicios Telematicos

SVF Software Validation Facility

SW Softawre

HW Hardware

TASTE The Assert Set of Tools for Engineering xii

TBD To Be Defined

TC Telecommand

TM Telemetry

IX

TMTC Telemetry and Telecommand

UART Universal Asynchronous ReceiverTransmitter UHF Ultra High Frequency

UPM Universidad Politecnica de Madrid

VHDL Very High Speed Integrated Circuit Hardware Description Language.

W Watts

WCET Worst Case Execution Time

X

Chapter 1

Introduction

This document is the student’s Final Degree Project where the project background,technological basis and all tasks implemented by the student are contained.

1.1. Background

The UPMSat-2 project was conceived as a consequence of the success of the UPMSat-1 project, launched on June 7th, 1995, and developed by UPM aeronautical engineers. Thecurrent project was originally created in order to be used as a technological demonstrationplatform in orbit and with teaching goals.

Within this context, the STRAST1 research group is in charge of the flight and groundsegment software of the satellite since it has been working with the ESA2 in the develop-ment of onboard software for satellites projects. Specifically, the group has developed theORK+ real time operating system kernel oriented for developing high integrity systemsin Ada programming language. This is part of the development framework for onboardsoftware which ESA is using in future space missions.

1.2. Motivation

As mentioned before, the UPMSat-2 satellite software is mainly separated in twocategories: flight segment and ground segment. The ground segment will be in charge ofcommunicating with the artifact, sending commands and receiving measurements. On theother hand, the flight segment (figure 1.1) is composed of different subsystems:

1http://www.dit.upm.es/~str/2http://www.esa.int/ESA

1

CHAPTER 1. INTRODUCTION 1.2. MOTIVATION

Figure 1.1: Flight Segment Software Architecture

Manager

Subsystem in charge of the initialization of the system, receiving events and errors fromthe rest of the software modules and changing the operating mode.

Experiments

Module in charge of the different experiments on boards provided by several enterprisesand institutions for testing them in space.

ADCS

Software which controls the attitude of the satellite in space according to an algorithmand the magnetometers measurements.

Platform Management

Subsystem responsible for the satellite housekeeping functions*.

Storage

Registers important events, errors, measurements, state information, tele-commands andROM.

TTC

Telecommand reading and telemetry sending from/to the antenna.

Hardware Access

2

CHAPTER 1. INTRODUCTION 1.3. OBJECTIVES

API for the satellite’s hardware devices.

Hardware Communication

API for the transmission and reception protocol.

Among all critical software subsystems inside the UPMSat-2 satellite, this Final De-gree Project is focuses in the development of the platform Management module.

Concretely, it consists of monitoring, validating, communicating and checking thestate of the different components (hardware and software) of the satellite. Specifically,functions such as periodic sensor read (magnetic field, temperature and voltage amongothers), sensor measurements validation, interesting measurements storage, and satellitesubsystems check will be accomplished.

1.3. Objectives

This report covers the following main objectives:

Study and fulfilment of the European Space Agency standards for software devel-opment. For this purpose the related on-line information avaliable will be studied.

Study and implementation of the high integrity system development techniques. Inorder to achieve this point, the student will study and will be trained in these areas.

Design of the UPMSat-2’s Platform Management flight segment software functionsusing tools such as TASTE and SDL diagrams. These tools will be explained indetail in the design section later in this document.

Development of the mentioned software subsystem from the design and using theAda programming language. This language has had to be previously studied by thestudent.

Selection and configuration of a software validation system (SVF) for hardware-in-the-loop tests and if not possible, test plan for the module developed.

Testing and integration in the satellite onboard software and if not possible, integra-tion with the rest of the software modules.

Project documentation generation for future work in the project.

3

CHAPTER 1. INTRODUCTION 1.4. DOCUMENT STRUCTURE

1.4. Document structure

This paper is structure 8 main chapters: section 1 introduces the project and the mostimportant objectives of this Final Degree Project. In section 2, the UPMSat-2 project, thetheorical definitions this work is based on and other specific information about the projectare exposed. Next all the topics related to the requirments analysis can be found in section3.

Afterwards, begins the first stage of the Platform Management software sub-systemin section 4, explaining all the design methodology followed and the design made, thencomes section 5 where the module designed is validated and the methodology used forthis purpose, section 6 where the implementation techniques and tools and the properdevelopment of the software subsystem process is explained and the last stage in section7, where the techniques and the test plan of the Platform Manager module is exposed.

To close the document section 8 presents the conclusions of the work done, the diffi-culties and obstacles found during its realization and future work in the UPMSat-2 project.

4

Chapter 2

Technological basis

In this chapter all the technological basis required for the project are going to beexplained in some detail. However, the concepts and tools of each stage of the projectwill be explained in their own sections.

2.1. UPMSat-2 introduction

The UPMSat-2 project is aimed to develop a micro-satellite in order to be used as atechnological demonstration platform in orbit. Its launch is scheduled for 2014 (qualifiedfor flight with Ariane-4) and the mission is expected to last 2 years. The main objective ofthe project is to design, build, qualify, launch and operate in orbit a platform incorporatingproven and new technologies and adapting it to the current launchers requirements, anduse it for scientific and educational applications.

Due to its weight of 50 kilograms, the satellite falls into the micro-satellite category.It has a cube shape structure of 0.5x0.5x0.6 meters (figure 2.1) with a maximum powerof 15 Watts. Its orbit is expected to be heliosynchronous at an altitude of 600 kilometers,with a periodic revolution around Earth of 97 minutes (2 times a day crosses over thesame geographical point).

The project management is lead by the Microgravity Universitary Institute "IgnacioDa Riva" (IDR) 1 from the UPM with the contribution of other universitary groups andspace sector enterprises. Several subsystem are developed by this group, such as thestructure, platform, electric supply, thermal control, space satellite attitude, onboard ex-periments, etc.

1www.idr.upm.es

5

CHAPTER 2. TECHNOLOGICAL BASIS 2.2. REAL TIME AND HIGH INTEGRITY SYSTEMS

Figure 2.1: UPMSat-2 launch vehicle, orbit and satellite.

Among these collaboration groups, STRAST2 job focuses on developing the flight andground segment software of the mission according to the ESA space software develop-ment standards for real time and high integrity systems. For that purpose, the technologypreviously developed for the ESA by this investigation group as well as the Real TimeOperating System kernel ORK+ (section 2.3.1) along with its associate and externaltechnology like the LEON3 processor (section 2.3.2) will be used.

This Final Degree Project aims to develop the Platform Managment module within thesoftware subsystem of the satellite so everything in the artifact is monitored. It is a highlevel software which uses lower level modules such as hardware drivers of the device orthe system memory and provides an API for the rest of the high level software modules.

2.2. Real Time and High Integrity systems

Real Time Systems (RTS) are computer systems which interact with the enviromentaccording to specific time requirements depending on the situation. Such systems can befound in spacecrafts, aircraft, vehicles, industrial processes, etc. The better descriptionfor these systems is that some actions have to execute within a specified time interval, tooearly or too late is wrong even though the functional behaviour is correct.

2www.dit.upm.es/str

6

CHAPTER 2. TECHNOLOGICAL BASIS 2.2. REAL TIME AND HIGH INTEGRITY SYSTEMS

A job has to be executed between its release time execution intervals. It uses processortime, possibly split into several and its deadline as we can see in figure 2.2 :

Figure 2.2: Task deadline structure.

In RTS, this jobs receive the name of task and have a time behaviour defined by theiractivation scheme (when they are activated) and execution deadline (when they wouldhave been executed). See again previous figure.

Some tasks do not have strict time requirements. There are different levels of critical-ity:

Hard RT requirements: have to be met always.

Soft RT requirements: may fail occasionally.

Firm RT requirements: if not met the result is useless.

An RTS is composed of a number of tasks. Each task executes a sequence of jobs, whichare released repeatedly according to an activation pattern:

Periodic: the jobs of a periodic task are released with a period T. A periodic task ischaracterised by three parameters T, C and D.

Figure 2.3: Periodic task scheme.

Sporadic: the jobs of a sporadic task are released whenever an event occurs. Usu-ally, a minimum separation T is imposed. These tasks are characterised by T, C andD.

Aperiodic: aperiodic tasks are event-driven, but have no real-time requirements(deadline, minimal separation, etc).

7

CHAPTER 2. TECHNOLOGICAL BASIS 2.2. REAL TIME AND HIGH INTEGRITY SYSTEMS

Figure 2.4: Sporadic task scheme.

Random, etc.

Due to the concurrent tasks execution in RTS, planning algorithms are required in orderto delimit the time response to this tasks. We can distinguish two main systems where wefind different planning alternatives:

Simple RTS: all tasks are periodic and independent of one another. Planning canbe static.

Complex RTS: some tasks can be sporadic, released when events occur. The plan-ning requires priority and eviction (a new task with higher priority interrupts theexecution of a lower priority task) mechanisms. This is the most used plannifica-tion method because it allows the response time analysis of the tasks.

Apart from these properties, RTS have another important one: reliability. It refers tothe consequences caused by a failure (from big economic loses to human lifes). Themost common solution for this requirement, is to set different functional modes, wheredepending on the current mode, different tasks are executed. In the UPMSat-2 project,4 main modes have been defined, each one with two sub-modes, as the following image2.5 shows

To ensure that all jobs and tasks satisfy these RTS requirements in all operating condi-tions, we need to validate them. In order to guarantee that worst-case (WCET) situationsare covered, analytical methods are commonly used in order to analyse timing behaviourssuch as response time, execution time, etc.

8

CHAPTER 2. TECHNOLOGICAL BASIS 2.3. PROCESSING SOFTWARE & HARDWARE

Figure 2.5: UPMSat-2 Mode diagram.

2.3. Processing software & hardware

2.3.1. Open Ravenscar Kernel

The onboard software will be executed over a version of the ORK+3, the Open Raven-scar real-time Kernel developed by the STRAST research group. This kernel supports theRavenscar profile as defined in the Ada 2005 standard. The Ravenscar profile (subset ofAda programming language) will be explained in the implementation section.

2.3.2. LEON3 processor

LEON processors family is a set of 32 bits processors based on the SPARC archi-tecture (RISC) developed by the European Space Agency (ESA)4 and Gaisler Research5

3http://www.dit.upm.es/~ork/index.html/4www.esa.int5www.gaisler.com

9

CHAPTER 2. TECHNOLOGICAL BASIS 2.3. PROCESSING SOFTWARE & HARDWARE

with the purpose of achieving an open design, capable of reaching the performance re-quirements, compability and costs of future space projects.

The LEON36 processor, one of the LEON family, is qualified for flight and has severalcharacteristics which make it of high interest for the UPMSat-2 project.

2.3.3. On-Board Computer

The OBC is the equipment used by the Platform Manager and the rest of the fligthsub-systems. The design was elaborated by the STRAST group and TECNOBIT7. Itsrestrictions are set by the environmental parameters such as the radiation and the temper-ature. Also, the acceleration and the power of the satellite condition his operation. It isformed by:

The LEON3 processor it is classified by the ESA for flight missions. It has a Re-duced Instructions Set Computing (RISC) arquitecture, supporting for open VHSICHardware Description Language (VHDL) and recording into a Field-ProgrammableGate Array (FPGA), and a limited power (100 MHz and 0.5 W)

4MB Static Random Access Memory (SRAM)

1MB Electrically Erasable Programmable ROM (EEPROM)

Analog Inputs (AIs): 64

Digital Inputs (DIs) and Digital Outputs (DOs): 64

Serial interfaces: RS422, RS232, Inter-Intergrated Circuit (I2C), Serial PhericalInterface (SPI)

6http://www.gaisler.com/index.php/products/processors/leon37http://www.tecnobit.es

10

Chapter 3

UPMSat-2: Requirements Analysis

3.1. ESA Standards

The European Space Agency (ESA) promotes the ECSS Standards intended to beapplied together for the management, engineering and product assurance in space projectsand applications. ECSS is a cooperative effort of the European Space Agency, nationalspace agencies and European industry associations for the purpose of developing andmaintaining common standards.

The software developing process of the UPMSat-2 project follows some of the ESAstandards such as:

ECSS-E-ST-40C - Space engineering: Software: this Standard defines the princi-ples and requirements applicable to space software engineering. This Standard cov-ers all aspects of space software engineering including requirements definition, de-sign, production, verification and validation, transfer, operations and maintenance(see figure 3.1).

ECSS-Q-ST-80C - Space product assurance: Software product assurance: thisStandard defines the principles and requirements applicable to space software prod-uct assurance. It stablishes 4 criticity categories for software systems if not ex-ecuted, or if not correctly executed, or whose anomalous behaviour can cause orcontribute to a system failure:

• Category A: resulting in: catastrophic consequences.• Category B: resulting in: critical consequences.• Category C: resulting in: major consequences.• Category D: resulting in: minor or negligible consequences.

ECSS-E-HB-40A - Space engineering: Software engineering handbook: ThisECSS-E-HB-40A handbook provides guidance on the use of the ECSS-E-ST-40C.

11

CHAPTER 3. UPMSAT-2: REQUIREMENTS ANALYSIS 3.2. SOFTWARE DOCUMENTS: SDD, SRS AND SSS

Figure 3.1: Software process according to ECSS-E-ST-40C standard.

ECSS-Q-HB-80-03A - Space product assurance: Software dependability andsafety: This handbook provides an overall description of the entire software de-pendability and safety workflow, considering the different development levels andphases and the customer-supplier relationships, with reference to the dependabilityand safety requirements defined in ECSS-Q-ST-80C.

3.2. Software documents: SDD, SRS and SSS

The UPMSat-2 software system project is documented in the Software Design Doc-ument (SDD), Software Requirements Specification (SRS) and Software System Spec-ification System (SSS) documents. All these accomplish the ESA Standards for spaceprojects previously exposed.

The Software Design Document (SDD) and Software Requirements Specification(SRS) document covers the on-board computer (OBC) software of the UPMSat-2 mis-sion and follows the ECSS-E-ST-40C Standard for the project on-board software.

The Software System Specification (SSS) stablishes the software system requirementesfor the UPMSat-2 mission and follows the ECSS-E-ST-40C Standard. These require-ments derived from the SRS document.

Every requirement analysis or high level design choice is formally defined in thesedocuments in order to satisfy ESA policies and structure the project documentation.

12

Chapter 4

Platform Management subsystem:Design

4.1. Design methodology

In this section all the concepts and tools needed to design the platform manager sub-system will be mentioned and explained as well as the external documentation that thestudent has followed for this purpose.

4.1.1. SDL Diagrams

SDL1 comes from Specification and Description Language and is a specification lan-guage targeted at the unambiguous specification and description of the behaviour of reac-tive and distributed systems and defined by the ITU Telecommunication StandardizationSector2 (ITU-T).

SDL provides both a graphical as well as a textual representation, which are bothequivalent representations of the same underlying semantics. Models are usually shownin the graphical form. A system is specified as a set of interconnected abstract machineswhich are extensions of finite state machines. It covers five main aspects: structure, com-munication, behavior, data, and inheritance.

The language is formally complete, so it can be used for code generation for eithersimulation or final targets.

1http://sdl-forum.org/SDL/2http://www.itu.int/

13

CHAPTER 4. PLATFORM MANAGEMENT SUBSYSTEM: DESIGN 4.1. DESIGN METHODOLOGY

4.1.2. TASTE Tool

TASTE3 is a set of freely-available tools dedicated to the development of embedded,real-time systems. It was developed by the European Space Agency (ESA), together witha set of partners from the space industry. TASTE allows software designers to easilyintegrate heteregeneous pieces of code produced either manually (in C or Ada) or auto-matically by external modelling tools such as MATLAB Simulink, SCADE, or Real-TimeDeveloper Studio.

Consistency of the integration is ensured through the use of two formal modellinglanguages : AADL4 and ASN.15.

By using TASTE, a software system architect can easily produce a complete and ho-mogeneous system in three steps: modeling phase, code generation and compilance phaseand validation phase.

Modeling Phase

The target of this phase is to generate a homogeneous model of the system abstractingfor hardware and software details and only focusing on the high level software architecturemade from a careful and intensive requirement analysis. This stage is the most complexof the process because every detail must be considered so in future phases everythingaccomplishes the specifications.

For this purpose, various languages are used for capturing the functional architecture(AADL language) and modeling the data used in the system (ASN.1 language). TASTEisolate the user from these languages through several automated tools, so no specificknowledge of this languages is needed. Such tools are explained below:

Data View: TASTE provides this tool for modeling the data used in the system inorder to use this data in the following modeling tools. For describing the data, asmentioned before, ASN.1 language is used. ASN.1 is a language standardized bythe ISO and ITU-T allowing to model types and data structures.

Interface View: the next step of the modeling phase is to set the high level soft-ware architecture in terms of functions connected through their interfaces. This isa graphical tool where functions (i.e. periodic tasks, methods, etc.), software mod-ules and theirs connections can be drawn and automatically generates the AADLcode which describes the architecture and will be used by other TASTE tools in theincoming stages.

SDL editor: this tools provides a graphical enviroment to define the detailed be-haviour of all the functions or tasks defined in the Interface View tool. As the other

3http://taste.tuxfamily.org/wiki/index.php?title=Overview4http://www.aadl.info5http://www.itu.int/en/ITU-T/asn1/Pages/introduction.aspx

14

CHAPTER 4. PLATFORM MANAGEMENT SUBSYSTEM: DESIGN 4.2. DESIGNING THE SUBSYSTEM

tools, this generates AADL code used in future steps.

Deployment View: once the data, software functions and theirs dependencies andbehaviour are defined, comes the system hardware architecture description. Thisgraphical tools allows the user to deploy the different elements of the model. Thetwo main elements are the Processor Boards and the buses which interconect theformer ones. Each Processor Board has a processor (with a specific architecture)and a memory module.

Code Generation and Compilance Phase

Once the modeling phase is complete, TASTE allows the automatic generation of codeskeletons of the software components with the preferred programming language as wellas the type definitions declared in the Data View tool. Some of the languages available areAda, C, Simulink or SDL, so depending of the purpose of the system and its requirementsand the particular characteristics of each programming language, the user will be able tochoose an appropriate one.

After the code generation, from the auto-generated scripts of TASTE, the code can becompiled in order to produce the executable files of the complete system, one for eachpartition declared in the Deployment View Tool.

Validation Phase

From the model and code previously generated, validation can be done through dif-ferent tools offered by TASTE such as code tests or GUI. This phase will be explained inthe Validation chapter 5.

In the modeling phase, in the Interface View tool some functions can be defined asGUI type. TASTE auto-generate an executable file from this functions which consists ofa Graphical User Interface that shows the sent and received values from the interfacesdeclared in the Interface View between functions and SW modules making interaction.This GUI allows the automatization of this interactions for future tests.

4.2. Designing the subsystem

The design phase is the most important part of developing a software system becauseevery single change made in the requirements will affect all the stages of the process, thatis why all the system characteristics, possible situations and alternatives have to be previ-ously studied and contemplated. The way to check if all the things have been consideredand treated is through the validating phase, which we will discuss later on the document.

15

CHAPTER 4. PLATFORM MANAGEMENT SUBSYSTEM: DESIGN 4.2. DESIGNING THE SUBSYSTEM

In this project it has been decided to use a V-Model6 (figure 4.1) as a software devel-opment process. The V-model is a graphical representation of the systems developmentlifecycle. The V represents the sequence of steps in a project life cycle development. Theleft side of the "V" represents the decomposition of requirements, and creation of systemspecifications. The right side of the V represents integration of parts and their validation.However, requirements need to be validated first against the higher level requirements oruser needs.

Figure 4.1: V development cycle.

All the system requirements are contemplated in the SRS document, along with othercritical information collected in the SSS and SDD documents previously exposed. Con-cretely, we are going to specify the Platform Manager requirements below.

The Platform Manager is mainly in charge of general housekeeping functions. It getsstate of the satellite from the sensors, check that the values are in a valid range, handlessatellite faulty devices and stores the information in the Storage module, which representsthe satellite memory system.

The Platform Manager subsystem will monitor the following kinds of housekeepingdata by periodic sampling of sensors as seen in table and storing them into the Storage 4.1(explain why these values (According to Fortescue, sampling range between 30s to 2m):

The housekeeping data measurements will be checked for validity. Values outside thevalid range will be signaled as errors to the Manager subsystem. Both the upper validitythreshold and the lower one values are predefined in table 4.2 (explain why these values):

Although these ranges and sampling periods will be the usual values, they could bemodified through a TC send from the Ground Station if needed. Some optiones are avali-able for changing the former parameters:

6http://www.softwaretestingmentor.com/sdlc/vmodel/

16

CHAPTER 4. PLATFORM MANAGEMENT SUBSYSTEM: DESIGN 4.2. DESIGNING THE SUBSYSTEM

Category Variable SamplingTemperature Satellite Sides 60s

Battery 60sMagnetometers 60sMagnetorquers 60sRadio 60sMicro Thermal Switch 60sSolar Cell Technology 60sOn-Board Computer 60sPower Supply Unit 60sSolar Panels 60s

Magnetic Field Magnetometers 60sVoltage Bus 20s

Battery 20sSolar Cell Technology 20s

Current Battery 20sSolar Panels 20sPower Distribution Unit 20sPower Supply Unit 20sSolar Cells 20sSolar Cell Technology 20sSolar Radiation Sensor 20s

Table 4.1: Sensor sampling periods.

Sensor Category Name Lower threshold Upper ThresholdTemperature Satellite Sides -100ºC 100ºCMagnetic Field Magnetometers 0nT 42.5nTVoltage Bus -5V +5V

Battery -5V +5VCurrent Battery 3mA 6mA

Solar Panels 3mA 6mA

Table 4.2: Sensor ranges example.

17

CHAPTER 4. PLATFORM MANAGEMENT SUBSYSTEM: DESIGN 4.2. DESIGNING THE SUBSYSTEM

Validity Ranges: this thresholds will be modified by an specific sensor or by agroup of sensors (i.e.: battery temperature sensors, solar cells current sensors, etc).

Sampling Periods: this periods will be modified by a group of sensors (i.e.: batterytemperature sensors, solar cells current sensors, etc).

The last values of the housekeeping data will be stored in the system state. Historicalvalues of the housekeeping data will be stored in the Storage. The sampling periods willbe configurable from Earth through a TC as well as the validity thresholds so if the amountof stored data is larger than the data that can be downloaded in the next ground visibilityinterval this values could be modified to correct this behaviour.

After analyzing the state of the satellite and proceeding with the corresponding actionsthe data will be stored in the logbook in order to be sent through TM messages whileground direct visibility occurs. The storage module will store the data in a circular buffer(if the buffer is complete, it smashes the older information stored) with different zones foreach kind of information (i.e. a memory zone for the platform measurements, other forthe experiments results, etc.).

The execution process explained before is the nominal way of processing the state ofthe satellite. However, as we saw on chapter 2 in figure 2.5, the satellite has differentfunctional modes, where depending on the current one, different tasks are executed.

Here are the definitions of the different satellite software modes:

Initialization Mode: Entered after the OBC is powered on, after separation timer,latency period and watchdog timer expiration, and after a TC. Loads the on-boardSW and starts execution. Configure all HW devices and SW subsystems. After thefirst Initialization, Commision Mode is entered, but after sub-sequent ones, SafeMode is entered.

The Platform Manager must Initialize the Hardware Access module, which offersan interface for the EBOX, UART and I2C drivers. This drivers provides the uppersoftaware levels to access sensor readings, mission clock, radio system, etc (seefigure 4.2).

Commisioning Mode: entered after the first Initialization or after a TC. The satel-lite subsystems are checked and when completed, Safe Mode begins. Errors whilechecking are reported to the Manager.

The Platform Manager checks the correct operation of some HW devices (e.g.checks if temperature sensors supply is on).

Safe Mode: entered after end of Initialization, Commisioning Mode, received TC,low battery warning or error in Nominar or Experiment Modes. Minimal functionsfor the satellite operation (battery charging).

The Platform Manager does the same as in the Nominal Mode.

18

CHAPTER 4. PLATFORM MANAGEMENT SUBSYSTEM: DESIGN 4.2. DESIGNING THE SUBSYSTEM

Figure 4.2: Computer drivers diagram.

Nominal Mode: after a TC message from Safe Mode or end of experiment fromExperiment Mode (no experiments performed here, only when a TC is received forchanging). The system leaves this mode when a TC requires a mode chante, lowbattery warning (to Safe Mode), critical battery warning (to Latency Mode), systemerror (to Safe Mode), communication loss (to Beacon Mode) or watchdog timerreset (to Initialization Mode).

All satellite functions are executed normally (including the Platform Manager, aspreviously explained).

Experiment Mode: after a TC requesting an experiment. 11 possible experiments(one at a time). When completed, system changes to Nominal Mode. Experimentfinished by TC, experiment timer or low or critical battery warning.

The Platform Manager does the same as in the Nominal Mode.

Latency Mode: OBC is switched off (battery charging). Entered after a criticalbattery warning. Changes to Initialization Mode after latency timer expiration.

In this mode, the Platform Manager does not execute any function as the OBCis switched off.

Beacon Mode: after communication loss with the Ground Station. While here, thesystem transmits a periodic signal until a response from ground is detected, andchanges to Safe Mode.

19

CHAPTER 4. PLATFORM MANAGEMENT SUBSYSTEM: DESIGN 4.2. DESIGNING THE SUBSYSTEM

During this mode, the Platform Manager does the same as in the Nominal Mode.

Based on all these previous requirements, we can start by defining the high level ar-chitecture, which will help us describe the main software structure of the system and howeach subsystem interacts with each other by means of Application Programming Inter-faces (APIs).

After designing and defining the high level architecture comes the detailed design,which allows us to describe the behaviour of each component of the high level architecturethrough SDL diagrams or similar tools.

The following steps will be part of the implementation phase, where from all thedetailed design, the coding (in this project, in Ada programming language) begins. Butfirst, as explained before, the validation phase is needed to check if all the design fulfilall the project requirements so if any change is necessary at this point, it will be easy tocorrect, whereas a change after the coding will be a dificult and consuming time task.

4.2.1. Simplified model example of the Platform Manager module

As an example of the design made of the Platform Manager subsystem, we are going toshow a simplified model of its nominal operation assuming that there is a reduced numberof interfaces with the TM/TC module (in order to make it clearer) and simple operationsas we will see below. For this purpose we are going to follow the steps mentioned beforeby using the TASTE tool inside the modeling phase.

Data View: the Platform Manager will only need a few data types to work with.All the data from the sensor reads and theirs validity ranges will be treated as 12 bitbinary data type. In order to define time units, we are going to use the Integer typeusing milliseconds as the base unit.

We also need to define the different events and errors that the platform could gen-erate. Eventually, for the system operating mode, we are going to define a set ofdifferent operating modes which includes all possible modes.

All these data types probably will change in the implementation stage dependingon the programming language used.

Interface View: after all data types have been defined, the next step is settingthe high level architecture, including all the possible interfaces with other softwaremodules. An overall view of this aspect was seen in figure 1.1 in chapter 1. Fig-ure 4.3 shows a simplified software architecture for the Platform Manager module.Some interfaces with other modules have been omitted in order to easily explainthe basic system behaviour.

20

CHAPTER 4. PLATFORM MANAGEMENT SUBSYSTEM: DESIGN 4.2. DESIGNING THE SUBSYSTEM

Figure 4.3: Simplified high level software architecture.

As we can seen in figure 4.3, there are some interactions between the platform man-ager sub-system and some other ones:

• Manager: the platform module will be capable of notifying the managermodule any event or error occurred while executing. This will indicate theManager if any special system operation or operating mode change needs tobe done. Besides, if the Manager decides to change the operating mode, theplatform will receive this notification through one of these interfaces. In thecomplete model, an Initialize interface from the Manager will be necessary inorder to initialize the HWAccess module.

• Telecommand and telemetry: in this module we have simplified the interac-tions with the platform manager since the change of validity ranges for specificsignal is omitted. In this example, the TMTC module will be capable of set-ting a custom samplin period or validity range for a group of signal, such asbattery temperature sensors, solar cells current sensors, etc. This changes willbe made from Earth through a telecommand.

• Storage: this module represents the satellite memory system. Each samplingperiod of an specific group, the platform manager reads the correspondingsensors and stores this data in memory through the Storage module. In thisexample, it has been omitted the backup system in the Storage module forretrieving the platform manager configuration parameters (such as samplingperiods, validity ranges, etc). This backup is used in the initialization phase,

21

CHAPTER 4. PLATFORM MANAGEMENT SUBSYSTEM: DESIGN 4.2. DESIGNING THE SUBSYSTEM

where the platform manager loads the default values of the mentioned param-eters or the last values stored if a system reset was previously produced, so novital information is lost if anything happens.

• HWAccess: this module is the abstraction of the HW of the satellite (for moreinformation of the HW and drivers, see figure 4.2). From this module, the plat-form manager reads all the sensors needed for monitoring the satellite’s status.

• TESTER: in order to validate the correct operation of the model designed, atester module (which is simply a GUI) has been created. This module allowsto monitor some critic parameters from the platform manager or changingsome values of other modules such as the battery temperature read from theHWAccess sensors. In the validation stage we will use this tool to check ifeverything is correctly designed.

Every module in this diagram consists of a GUI with the exception of the plaformmanager module (which is defined through SDL diagrams as we will explain below)and the HWAccess. The latter is defined through a simple C programming languageclass due to the values of the sensors needs to be read (getters). This is only neededfor the modeling and validation phase, in order to have a working model generatedfrom the TASTE tool.

SDL editor: in this simplified example, only the task of reading the battery temper-ature values from the drivers will be detailed defined and since the other measureswill have the same structure, this will serve to explain the basic behaviour of theplatform manager sub-system.

The normal behaviour of this module was explained in section 4.2, where all de-tails were defined. This operating mode corresponds to the Nominal mode as weexplained before. However, to show in a graphic way for better understanding howthis module usually works, we are going to use SDL diagrams created from TASTEtool. Again, this will be a simplified example (using the assumptions mentionedabove) so the basic behaviour of the Platform Manager is clear.

The main execution thread (figure 4.4) contemplates diverse calls (interfaces) fromthe modules as explained before:

1. Periodic interrupt signal: after every second, the PM checks the currentoperating mode and if it matches the Nominal one, proceeds with the sensorreadings. Here, if the sampling periods match with the current interruption,the specific group of sensors will be read from the HWAccess module.This reading takes place in the SDL diagram in figure 4.5. In the diagramthere is an example of the reading of the battery temperature sensors. Foreach group or specific sensor, the HWAccess will provide an interface for thePM for reading. This way of reading data from the sensors is the same for allof them.

22

CHAPTER 4. PLATFORM MANAGEMENT SUBSYSTEM: DESIGN 4.2. DESIGNING THE SUBSYSTEM

Figure 4.4: SDL PM Main operating thread runtime.

23

CHAPTER 4. PLATFORM MANAGEMENT SUBSYSTEM: DESIGN 4.2. DESIGNING THE SUBSYSTEM

Figure 4.5: SDL PM Battery temperature sensors reading runtime.

24

CHAPTER 4. PLATFORM MANAGEMENT SUBSYSTEM: DESIGN 4.2. DESIGNING THE SUBSYSTEM

Concretely, after the HWAccess sends the raw data from its sensors, the PMfor each sensor measure, will compare the converted value against a valid-ity range previously set or modified by a TC. If any sensor value is out ofvalidity range, an error warning is sent to the Manager module. After all thisprocessing, the processed data is sent to the Storage module in order to store it.

2. TCTM: as described before, all the validation ranges and sampling periodscan be modified through a TC sent from the Ground Station. This can reducethe risks in case of memory overloads with the housekeeping data or wastingtoo many battery charge or bandwith. In this example, only the sampling pe-riod of the battery temperature sensors group and the upper threshold of thisgroup will be configurable for easier explanation.

3. Manager: as described before, if any subsystem detect any significant eventor error, will communicate it to the Manager module. If relevant, the Managerwill change the current operating mode and notify all the subsystems aboutthis change.

Deployment View: through this graphical TASTE tool, the definition of the hard-ware architecture begins. For this model, we define a partition of a Processor Boardwith the specific OS architecture and deploy the different elements of the model(funcions) on it. This will allow the auto-generation of code skeletons and exe-cutable files useful for the validation phase.

Once the design is made, the validation phase begins for testing that every requirementand functionality works as expected.

25

Chapter 5

Platform Management subsystem:Validation

5.1. Validation methodology

After the modeling phase, comes the validation phase, in which all design made willbe checked against all the requirement analysis and will be useful to test the system cre-ated.

For this purpose, TASTE provides a GUI tool created from the model designed. Con-cretely, in the Interface View tool used in the modeling phase, any function can be definedas GUI type. TASTE auto-generate an executable file from this functions which consistsof a Graphical User Interface that shows the sent and received values from the interfacesdeclared in the Interface View between functions and SW modules making interaction.This GUI allows the automatization of this interactions for future tests. As an example ofthese tools provided, see figure 5.1 1.

In this validation stage, we are going to use these GUI’s generated from the model toshow the high level behaviour of the PM sub-system and to check if there is something thatdoes not fulfill the agreed requiremnts collected in the specification documents (SSS,SRS& SDD).

1Source: Final Master Project - Diseno de la Arquitectura software del sistema a bordo del sateliteUPMSat-2 By Jorge Garrido

26

CHAPTER 5. PLATFORM MANAGEMENT SUBSYSTEM: VALIDATION 5.2. VALIDATING THE SUBSYTEM

Figure 5.1: GUI example.

5.2. Validating the subsytem

Due to the huge amount of possible interactions between all the modules define inthe model, only the most representative interactions of the system will be shown. Forthis purpose, we are going to trigger some changes in the system by sending through theGUI’s of each module information accross the interfaces defined in the modeling phase.In addition, we will be able to change some configuration parameters such as samplingperiods or validity ranges thanks to the TESTER GUI module created for this purpose.

To check the correct operation of the system we will observe if the changes provokedproduces the expected changes in the complete system.

1. Change of the Operating Mode of the Platform Manager moduleAt the beginning of the execution of the model, the default operating mode is ini-tialization. As seen in figure 4.4, unless the system is in nominal mode, no actionis performed inside the PM module. For changing this, we are going to send fromthe Manager sub-system through its GUI the new operating (figure 5.2).

After triggering this change, in the TESTER module GUI we must observe the newoperating mode received by the PM and instantly its nominal operation (figure 5.3).For illustrative purpose, in the TESTER we can see a module a 20 seconds moduleclock.

27

CHAPTER 5. PLATFORM MANAGEMENT SUBSYSTEM: VALIDATION 5.2. VALIDATING THE SUBSYTEM

Figure 5.2: First Validation - Initial PM Operating Mode.

Figure 5.3: First Validation - Modification of the PM Operating Mode from the ManagerModule.

28

CHAPTER 5. PLATFORM MANAGEMENT SUBSYSTEM: VALIDATION 5.2. VALIDATING THE SUBSYTEM

From figures 5.2 and 5.3 we can conclude that the model works correctly accordingto the specifications

2. Battery temperature group of sensors nominal readingIn this scenario, the PM module is initially set with the following configuration(this settings are for illustrative purpose, they are not representative of the spaceenviroment):

Parameter ValuesSampling period 5 segBattery Temperature sensors group validity range [0ºC , 250ºC]Event sent if values within validity range experimentDoneError sent if values outside validity range low/highBatteryTemperatureTemperature measured 200ºC

Table 5.1: Second validation settings.

With this settings, in the Storage module we must observe 3 values (one for eachtemperature sensore of the battery) of 200ºC which is the temperature read by theHWAccess module (figure 5.4). Besides, in the Manager we must see the eventreceived experimentDone because the temperature measured is within the validityrange. The 3 gauges in the images represent each battery temperature sensor foreasier visualization.

Figure 5.4: Second Validation - Initial validation step.

29

CHAPTER 5. PLATFORM MANAGEMENT SUBSYSTEM: VALIDATION 5.2. VALIDATING THE SUBSYTEM

Figure 5.5: Second Validation - Second validation step.

Figure 5.6: Second Validation - Third validation step.

For showing how the sampling period and the validity range work, we trigger achange in the temperature measured by the HWAccess module from 200ºC to 50ºC.Since it is still within the validity range, no error should sent to the manager. Inthe following images (figures 5.5 and 5.6) we can see that until the 5 seconds of the

30

CHAPTER 5. PLATFORM MANAGEMENT SUBSYSTEM: VALIDATION 5.2. VALIDATING THE SUBSYTEM

sampling periods, no change is stored in the Storage module, and after this period,the new measures are stored in Storage.

3. Battery temperature group of sensors modified readingIn this scenario, the PM module is initially set with the following configuration(this settings are for illustrative purpose, they are not representative of the spaceenviroment):

Parameter ValuesSampling period 10 segBattery Temperature sensors group validity range [0ºC , 280ºC]Event sent if values within validity range experimentDoneError sent if values outside validity range low/highBatteryTemperatureTemperature measured 260ºC

Table 5.2: Third validation settings.

With this settings, in the Storage module we must observe 3 values (one for eachtemperature sensore of the battery) of 260ºC which is the temperature read by theHWAccess module (figure 5.7). Besides, in the Manager we must see the eventreceived experimentDone because the temperature measured is within the validityrange. The 3 gauges in the images represent each battery temperature sensor foreasier visualization.

Figure 5.7: Third Validation - Initial validation step.

31

CHAPTER 5. PLATFORM MANAGEMENT SUBSYSTEM: VALIDATION 5.2. VALIDATING THE SUBSYTEM

For showing how the sampling period and the validity range work, we triggera change in the temperature measured by the HWAccess module from 260ºC to350ºC. Since it is above the upper threshold of the validity range, a highBattery-Temperature should be sent to the manager. In the following images (figures 5.8and 5.9) we can see that until the 10 seconds of the sampling periods, no change isstored in the Storage module, and after this period, the new measures are stored inStorage.

For showing another example, we trigger a change in the temperature measured bythe HWAccess module from 350ºC to -250ºC. Since it is below the lower thresholdof the validity range, a lowBatteryTemperature should be sent to the manager. Infigure 5.10 we can see that after the 10 seconds of the sampling periods, the newmeasures are stored in Storage.

Figure 5.8: Third Validation - Second validation step.

All these representative validation tests allow us to conclude that the model designedworks perfectly according to the requirementes specification. If any error or conflictwould have been found or detected, this phase enable us to isolate it and change ev-erything necessary in the design phase and redo this process instead of transfer it to thefollowing phases, which will make the fixing issue a tedious task to achieve. After thisstage comes the implementation phase, explained in the next chapter.

32

CHAPTER 5. PLATFORM MANAGEMENT SUBSYSTEM: VALIDATION 5.2. VALIDATING THE SUBSYTEM

Figure 5.9: Third Validation - Third validation step.

Figure 5.10: Third Validation - Fourth validation step.

33

Chapter 6

Platform Management subsystem:Implementation

In this section all the concepts and tools needed to implementing the platform managersubsystem will be mentioned and explained as well as the external documentation that thestudent has followed for this purpose.

6.1. Implementation methodology

6.1.1. Ada programming language

Ada is a programming language for reliable software systems since it is strongly typedand object-oriented. Furthermore, it is targeted at embedded Real-Time systems and pro-vides concurrency, low-level register access, interrupt support, etc.

It was first promoted by US DoD, and after years of changes and versions, is widelyused in aeronautics, space, railways and other high-integrity domains. GNAT is a free-software compiler used for compiling the Ada programming language which forms partof the GNU Compiler Collection.

An Ada program is made up of a number of program units:

Subprograms: procedures (provide no results) and functions (provide results).

Packages: program modules. Packages are the main compilation unit, encapsula-tion types, subprograms, etc.

Tasks: concurrent threads.

Protected objects: shared data (monitors).

In more detail, in Ada, program units have two differentiated parts:

34

CHAPTER 6. PLATFORM MANAGEMENT SUBSYSTEM: IMPLEMENTATION6.1. IMPLEMENTATION METHODOLOGY

Specification: what is visible from other program units.

Body: implementation of the program unit.

For developing the UPMSat-2 software, Ada programming language has been chosen dueto its properties.

6.1.2. Ravenscar profile and SPARK programming language

The Ravenscar profile is a subset of the Ada tasking features designed for safety-critical hard real-time computing. Ravenscar imposes certain restrictions on the concur-rent part of the language to perform temporal analysis and allow an efficient implementa-tion of the kernel.

The objectives here are two:

Getting a deterministic model of concurrent execution, so that it is suitable forstrict real-time systems.

Allow a small and efficient implementation, so that does not force to introduce alot of overhead so the tasks can respond in short deadlines.

The SPARK programming language consists of a highly restricted, well-defined sub-set of the Ada, intended to be secure and to support the development of high integritysoftware used in applications and systems where predictable and highly reliable operationis essential either for reasons of safety (such as avionics in aircraft or spacecraft, medicalsystems and process control software in nuclear powerplants) or for business integrity (forexample financial software for banking and insurance companies).

6.1.3. GNAT and GPS

GNAT (GNU NYU Ada Translator) is a free-software compiler for the Ada program-ming language which forms part of the GNU Compiler Collection. It supports all versionsof the language, i.e. Ada 2012, Ada 2005, Ada 95 and Ada 83. The front-end and run-timeare written in Ada.

GNAT Programming Studio (GPS) is an integrated development environment whichprovides an interface to program with Ada. It is free-licensed software and provides a setof tools for checking the semantic, building the application and some other useful optionssuch as showing the dependency files, reformatting or fixing the source code, searchingand replacing tools and many more.

A basic interaction between the software and the hardware of the satellite is shown inthe figure 6.1:

35

CHAPTER 6. PLATFORM MANAGEMENT SUBSYSTEM: IMPLEMENTATION6.2. IMPLEMENTING THE SUBSYTEM

Figure 6.1: Execution architecture of the UPMSat-2.

The software compiles with GNU NYU Ada Translator (GNAT), which in turn usesORK (see section 2.3.1). Finally, the software makes uses of the hardware using thedrivers that should be programmed too.

6.2. Implementing the subsytem

After the model is defined, comes the implementation phase. As we explained inprevious chapters, TASTE provides several tools which allows the auto-generation ofcode skeletons which implements the behaviour from the model designed. However, dueto its early development and lack of maturity, we do not trust in this auto-generated codefor a Real-Time and High Integrity system. This code contains many auxiliary variables,pointers and other things that makes it untrustworthy for a critical mission such as theUPMSat-2. Instead, the final Platform Manager module code is based on the structureof this skeletons so the module will be a clean and safe code which accomplishes all theReal-Time requirements.

The logic structure of the platform manager software is composed of three elements:

HLInterface: this component constitutes the high level interface of the PM mod-ule, that is, the interfaces with the other high level software modules.

Paramenter: contains the definition of the configurable parameters used in themodule.

Core: in this component all the logic of the module can be found. Interactions withthe rest of the sub-systems, periodic tasks, measurements and other operations arean example of this logic.

The logic structure of the module follows the same behaviour defined in the designphase. Other modules interfaces are required for interacting between each other (storedata, notify events, etc). As mentioned before, many of the high level software moduleshave been developed in parallel (Storage, ADCS, HWAccess, etc) so there has been a

36

CHAPTER 6. PLATFORM MANAGEMENT SUBSYSTEM: IMPLEMENTATION6.2. IMPLEMENTING THE SUBSYTEM

partial integration of the system which allows to see if everything glues and works finetogether.

It is worth mentioning that all the modules uses a basic types artifact which containsall the types used by all the sub-systems, from enumerated, primitive, to more complextypes (for storing data into Storage module, or the telemetry structure sent to the Groundstation, etc).

All the code generated by the student has been developed oriented to its reusabilityand future modifications due to changes in software or system requirements.

For the software development, the student has used the GPS framework explaiend inprevious sections. For the integration with other modules, the group uses a SVN serverwhere all the software modules are allocated and every developer updates its development.

No code is provided whithin this paper because independently of its sintax (dependanton the programming language, in this case, Ada) the behaviour of this sub-systems isequivalent to the design developed.

For validating the generated code, some Unit tests can be perfomed throughout theAUnit tool. It is a set of Ada packages based on the xUnit family of unit test frameworks.It’s intended as a developer’s tool to facilitate confident writing and evolution of Adasoftware. It is purposely lightweight, as one of its main goals is to make it easy to developand run unit tests, rather than to generate artifacts for process management. Although thistests are important for checking the code, due to deadline this Final Degree Project doesnot contain such tests. For more kind of tests, see section 7.1.

Once the implementation is done, it is time for the verification phase, where all tem-poral, structural and other requirements will be checked and tested. In the next chapter 7is gathered all the information about this final phase.

37

Chapter 7

Platform Management subsystem:Verification

All the methodology and techniques needed for verifying the system will be explainedin this chapter. However, due to the early stage of the project in terms of softare devel-opment and the incomplete development of the system, this paper only contains the testplan for the Platform Management software sub-system.

7.1. Verification methodology

One of the most crucial aspects of the development of Real Time and High Integritysystems is its logical and temporal validation. Among all Real Time systems, satellitesare the ones where the validation phase is the most critic stage because once they are intospace, they can hardly be modified.

In addition, satellites have another important difficulty: it is impossible to test themin their real environment conditions. Aspects such as gravity, radiation, temperatures ormagnetic field for example are difficult to simulate, so advanced simulation techniquesare required for reproducing physically this conditions.

In the sections below, some techniques used for the verification explained will beexposed.

7.1.1. Software Validation Facility

The main purpose of the tests is to detect any failure in the system under study. As aReal Time and High Integrity system, every possible aspect must be covered, so the testsshould have the widest possible coverage. As it is not possible to test in Earth the satellite

38

CHAPTER 7. PLATFORM MANAGEMENT SUBSYSTEM: VERIFICATION7.1. VERIFICATION METHODOLOGY

software in its real environment, a Software Validation Facility (SVF) including HardwareIn the Loop (HIL) should be built. The basic idea is to test the embedded system againsta simulation model instead of the real environment.

These tests are part from the V-Model explained in section ?? and the testing archi-tecture is shown in figure 7.1):

Figure 7.1: Software validation architecture.

Several kinds of tests can be performed:

Unit testing: where individual’s source code units are tested (white or black boxtesting).

Integration testing: the software modules are combined and tested as a group.

Regression testing: checking that the implementation of a module does not affectto another one.

System testing: test of the entire integrated system in order to check it against thespecified requirements.

Acceptance testing: run on a complete system to check if the specified require-ments are met.

7.1.2. Hardware In the Loop

The HIL technology connects the OBC with a computer, where the simulation is de-ployed. Its functionality is shown in the figure 7.2:

HIL is a technique used in the development and test of complex real-time embeddedsystems which provides a platform to simulate the behavior of, for example, the actua-tors and sensors for the ADCS module, allowing testing the subsystem with the SVF. Itincludes the spacecraft dynamics and its enviroment.

39

CHAPTER 7. PLATFORM MANAGEMENT SUBSYSTEM: VERIFICATION7.2. VERIFYING THE SUBSYSTEM

Figure 7.2: HIL architecture.

7.1.3. Rapita Verification Suite

RVS measures, optimizes and verifies the timing performance and test effectivenessof critical real-time embedded systems in industries such as aerospace and automotive.

In the field of th time analysis, the most important verification parameter is the calcu-lation of the Worst Case Execution Time (WCET). For this purpose, the tool Rapitime2of the RVS set of tools can be used. It analyses the source code structure and adds in-strumentation points to register the execution time in these points. Once the simulation isexecuted, the tools provides the results useful to find problems or temporal deficiencies inthe module under study.

7.2. Verifying the subsystem

This Final Degree Project should include at least the unitary tests for the PlatformManager module. However, due to lack of time and close deadline all the verificationprocess has been delegated to future stages of the project. As said before there has beena parallel development with the different high level software sub-systems, but as they arenot completely ready,integration and system tests will be defined and executed at nextstages.

Nevertheless, this section contains the tests plan conceived by the student for thismodule even though no tests will still be performed. Simple test plans will be exposedbelow:

Successful operating mode change

Some transitions can be tested, from entering the Initialization mode and checking thatall the tasks implemented are performed, to changing from and active mode to an inactiveone (i.e.: from Nominal to Latency mode) and check that the module stops executing itstasks.

40

CHAPTER 7. PLATFORM MANAGEMENT SUBSYSTEM: VERIFICATION7.2. VERIFYING THE SUBSYSTEM

With this tests all changes that the manager could do would be assured.

Successful activation of sensors supplies

Within the Initialization mode logic routine, all the sensors supplies are enabled. Agood test to perform is enabeling one supply, and after changing the mode (previouslytested) to Commisioning, check if the activated supply is already on.

This test allow us to check if the interfaces with the HWAccess work fine and at thesame time, to prove the HWAccess routines for integration purposes.

Successful sampling period

In any active mode, the Platform Manager reads the data measured by the satellitesensors every sampling period. A good test to performe is checking that every samplingperiod and only at this moment the corresponding data is measured.

Thanks to this test, we can affirm that the sampling behaviour is correct and respected.

Successful ranges validation

As said before, in any active mode, the Platform Manager reads the data measured bythe satellite sensors and compares it againts a validity range defined for every group ofsensors and if any measure is out of range, an event is sent to the Manager module. Forchecking this routine, a value out of range can be forced and we could see if an event isnotified to the Manager or not.

This test allows us to check if the main routine of the platform manager module workscorrectly and as expected.

Successful storage of measured data

In any active mode, the Platform Manager reads the data measured by the satellitesensors and stores it through the Storage module. One useful test is checking tha destored data is the data expected or simulated.

This test allow us to check if the interfaces with the Storage work fine and at the sametime, to prove the Storage routines for integration purposes.

These are some of the test plans thought for the Platform Manager sub-system for afuture stage of the project. If any software or system requirement changes, these tests willhave to be reviewed and modified if necessary.

This stage completes the set of different phases which compose the development ofthe Platform Manager high level software module described in this paper from the studentFinal Degree Project.

41

Chapter 8

Conclusions

The UPMSat-2 project is resulting in high interest for the different research group inUniversidad Politécnica de Madrid. Several aerospace industry techniques and tools arebeing put into practice such as TASTE tool developed by the European Space Agency andwith the colaboration of the STRAST research group, used in this Final Degree Project,which shows its utility.

Within this scope, this Final Degree Project has supposed an important progress in theUPMSat-2 project due to the attainment of diverse high-level software modules, mainly,the Platform Manager sub-system. The most relevant contributions to the UPMSat-2project have been:

Analysis of requirements and specifications documents and throughout the projectdevelopment, detection and correction of inconsistencies or new requirements.

Meetings with project members for reviewing and upgrading requirements and in-tegrating different software modules.

Complete definition of the Platform Manager flight module according to the ana-lyzed requirements. This point includes de design, validation, implementation andverification of this software sub-system.

Fulfilment of the European Space Agency standards for software development.

Use and test of the TASTE tool developed by the ESA for space software imple-mentation.

Documentation of the process and system developed.

During the accomplishment of this project the student has faced different dificultiesand obstacles. Among them stands out the ones associate with the magnitude, interdisci-plinariy and complexity of the UPMSat-2 project. Through the following of developmentmethodologies and standards the student has been able to overcome these problems.

42

CHAPTER 8. CONCLUSIONS 8.1. FUTURE WORK

All the changes or new additions in the software and hardware specifications, fromwhich this project highly depends, has supposed an increment in time and difficultieson the development of this work and occasionally spoiling the work done. Due to thedimension and the early stage of development of the UPMSat-2 project, all this issues areunderstandable. The methodology used to overcome these problems was making everymaterial developed reusable for future uses or changes.

Another difficulty to highlight is dealing with the TASTE set of tools. Whereas it isa very useful tool as shown in the body of this report, it presents some difficulties for itsuse due to its early development, lack of maturity and not much documentation. Afterworking with this tool, some incomplete functionalities or bugs have been detected.

Despite all these obstacles faced during this work, the student has achieved all theobjectives postulated in section 1.3 at the beginning of the document.

8.1. Future Work

This Final Degree Project is focused on developing the Platform Manager softwaresubsystem as mentioned throughout the whole document. This is only a small part of theentire UPMSat-2 project and there is still much work to be done although the project iswell advanced. Other peers in the research group have been developing other high levelsoftware modules in parallel so in this aspect, the work is close to be completed.

In the following project stages, modules such as the software scheduler, the experi-ment module or some drivers will be designed and developed. Likewise, the validationprocess and enviroment needs to be updated and all the integration and validation of theentire system must be accomplished.

43

Bibliography

[1] STRAST, Software System Specification UPMSat2. http://www.dit.upm.es/~str/

proyectos/upmsat2/documentacion/UPMSat2-SSS-1.5.pdf

[2] STRAST, Software Requirements Specification UPMSat2. http://www.dit.upm.es/

~str/proyectos/upmsat2/documentacion/UPMSat2-SRS-1.2.pdf

[3] STRAST, Software Design Document UPMSat2.

[4] European Space Agency, ECSS-E-ST-40C Space Engineering Software. http://www.dit.upm.es/~str/proyectos/upmsat2/documentacion/ECSS-E-ST-40C.pdf

[5] European Space Agency, ECSS-Q-ST-80C Space Product Assurance: SoftwareProduct Assurance. http://www.dit.upm.es/~str/proyectos/upmsat2/documentacion/

ECSS-Q-ST-80C.pdf

[6] European Space Agency, ECSS-E-HB-40A Space Engineering: Software En-gineering Handbook. http://www.dit.upm.es/~str/proyectos/upmsat2/documentacion/ECSS-E-HB-40A.pdf

[7] European Space Agency, ECSS-Q-HB-80-03A Space Product Assurance: Soft-ware Dependability and Safety. http://www.dit.upm.es/~str/proyectos/upmsat2/

documentacion/ECSS-Q-HB-80-03.pdf

[8] John Barnes, Programming in Ada 2005. Addison Wesley, Massachusetts, 2nd edi-tion, 2005.

[9] S. Tucker Taft, Robert A. Duff, Ada 2005 Language Reference Manual and Rationale.Springer, 2005 edition, 2005.

[10] European Space Agency, Guide for the use of the Ada programming lan-guage in high integrity systems. http://www.dit.upm.es/~str/proyectos/upmsat2/

documentacion/ISO-IEC-TR-15942-2000(E).pdf

[11] European Space Agency, Guide for the use of the Ada Ravenscar Pro-file in high integrity systems. http://www.dit.upm.es/~str/proyectos/upmsat2/

documentacion/YCS-2003-348.pdf

[12] European Space Agency, Real-Time Systems course by DIT from ETSIT UPM. http://www.dit.upm.es/~jpuente/strl/

44