UPMSAT-2 - DIT · Chapter 1 Introduction 1.1 Purpose This the Software Requirements Speciﬁcation...

UPMSAT-2On-Board Software

Software Requirements SpecificationVersion 1.2

3 March, 2014

UNIVERSIDAD POLITÉCNICA DE MADRID

GRUPO DE SISTEMAS DE TIEMPO REAL

Y ARQUITECTURA DE SERVICIOS TELEMÁTICOS

Revision # 460— March 3, 2014 10:31:04

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: Draft

Written by: Juan A. de la Puente

Revised by: Alejandro AlonsoJuan ZamoranoÁngel Sanz

Changes

Version/Revision Date Purpose Author1.0 10-01-2014 Initial draft J.A. de la Puente1.1 19-02-2014 Internal review J.A. de la Puente1.2 03-03-2014 Internal review J.A. de la Puente & others

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 Software overview 94.1 Function and purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94.2 Environmental considerations . . . . . . . . . . . . . . . . . . . . . . . . 9

4.2.1 Physical environment . . . . . . . . . . . . . . . . . . . . . . . . 94.2.2 Hardware environment . . . . . . . . . . . . . . . . . . . . . . . 124.2.3 Operating environment . . . . . . . . . . . . . . . . . . . . . . . 12

4.3 Relation to other systems . . . . . . . . . . . . . . . . . . . . . . . . . . 144.3.1 Top-level architecture . . . . . . . . . . . . . . . . . . . . . . . . 144.3.2 Ground station software . . . . . . . . . . . . . . . . . . . . . . 144.3.3 Electronic ground support software . . . . . . . . . . . . . . . . 15

4.4 Constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

5 Requirements 175.1 General . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175.2 Functional requirements . . . . . . . . . . . . . . . . . . . . . . . . . . 17

5.2.1 System requirements . . . . . . . . . . . . . . . . . . . . . . . . 175.2.2 Platform monitoring and control . . . . . . . . . . . . . . . . . . 185.2.3 Attitude control system (ACS) . . . . . . . . . . . . . . . . . . . 195.2.4 Communications (TTC) . . . . . . . . . . . . . . . . . . . . . . 205.2.5 Data and event logging . . . . . . . . . . . . . . . . . . . . . . . 22

5.3 Performance requirements . . . . . . . . . . . . . . . . . . . . . . . . . 225.4 Interface requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

i

5.5 Operational requirements . . . . . . . . . . . . . . . . . . . . . . . . . . 235.5.1 Ground operating modes . . . . . . . . . . . . . . . . . . . . . . 245.5.2 Flight operating modes . . . . . . . . . . . . . . . . . . . . . . . 25

5.6 Resource requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . 285.6.1 Storage requirements . . . . . . . . . . . . . . . . . . . . . . . . 285.6.2 Hardware timers . . . . . . . . . . . . . . . . . . . . . . . . . . 29

5.7 Design requirements and implementation constraints . . . . . . . . . . . 295.8 Security and privacy requirements requirements . . . . . . . . . . . . . . 305.9 Portability requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . 305.10 Software quality requirements . . . . . . . . . . . . . . . . . . . . . . . 305.11 Software reliability requirements . . . . . . . . . . . . . . . . . . . . . . 305.12 Software maintainability requirements . . . . . . . . . . . . . . . . . . . 305.13 Software configuration and delivery requirements . . . . . . . . . . . . . 305.14 Data definition requirements . . . . . . . . . . . . . . . . . . . . . . . . 315.15 Human factors-related requirements . . . . . . . . . . . . . . . . . . . . 315.16 Adaptation and installation requirements . . . . . . . . . . . . . . . . . . 31

6 Validation requirements 33

7 Traceability 35

8 Logical model description 37

ii

Chapter 1

Introduction

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

1.2 ScopeThis document covers the on-board computer (OBC) software of the UPMSat2 mission.

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 an overview of the UPMSat2 on-board software.

• Chapter 5 contains the details of the software requirements.

• Chapter 6 contains the validation requirements for the UPMSat2 on-board software.

• Chapter 7 contains the traceability matrix with respect to the SSS requirements.

• Chapter 8 contains a description of the logical model of the system.

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-70C Space engineering — Ground systems and operations. July 2008.

[AD5] 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.

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

[RD6] UPMSat2 — Software System Specification. Version 1.8. December 2013.

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

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

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

3

4 CHAPTER 2. REFERENCES

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.

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.

ACS Attitude control system.

AD Applicable document.

ADCS Attitude determination and control subsystem.

AI Analog input.

AOCS Attitude and orbit control system.

ASN Abstract Syntax Notation.

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.

DIC Design and implementation constraints.

DLG Data and event logging.

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

IFC Interface.

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.

OPR Operation.

ORK Open Ravenscar Real-Time kernel.

PFC Performance.

PMC Platform monitoring and control.

3.3. ABBREVIATED TERMS 7

PTB Portability.

RAM Random-access memory.

RD Reference document.

RES Resource(s).

ROM Read-only memory.

RW Reaction wheel.

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

RES Resource(s).

SCT Solar Cell Technology.

SDL Specification and Design Language.

SEC Security.

SMA Shape Memory Alloys.

SRS Software Requirements Specification.

SS Subsystem.

SS Solar sensor.

SSD Solid-state drive.

SSS Software System Specification.

SWQ Software quality.

SYS System.

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.

WBC Warning: battery level critical.

WBL Warning: battery level low.

8 CHAPTER 3. TERMS, DEFINITIONS AND ABBREVIATED TERMS

Chapter 4

Software overview

4.1 Function and purposeThe aim of the UPMSat2 on-board software is to monitor and control the operation of thesatellite platform. Its main functions are:

• Attitude determination and control (ADC)

• Reception, decoding and execution of telecommands (TC)

• Encoding and transmission of telemetry messages (TM)

• Collection and monitoring of housekeeping data (HK)

• Time management

• Fault detection, isolation, and recovery (FDIR)

• Payload data management

• Data and event logging

4.2 Environmental considerations

4.2.1 Physical environment• 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.

9

10 CHAPTER 4. SOFTWARE OVERVIEW

• Platform envelope

– 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.2).

– Sensors: magnetometers

– Actuators: magnetorquers

• 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

– Downlink: UHF 400 MHz band (ISM/Amateur Radio Satellite), 9600 bpsmax

– Uplink: UHF 400 MHz band (ISM/Amateur Radio Satellite), 2400 bps max

4.2. ENVIRONMENTAL CONSIDERATIONS 11

X+! Y+!

Z+!

Z-!

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

Figure 4.2: Attitude control reference.


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)

2. SCT (Solar Cell Technology)

3. MGM (Magnetometer)

4. MRAD (Radiation Effect Monitoring)

5. SMA (Shape Memory Alloys)

6. RW (Reaction Wheel)

7. SS6 (Solar Sensors)

8. CTM (Thermal Control Data)

9. BOOM (Extension boom)

10. MAC (Magnetic Attitude Control)

11. SSS (Separation System)

4.2.2 Hardware environmentThe software will run on a dedicated on-board computer (OBC) with the following char-acteristics:

• 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.3 shows the hardware structure of the on-board computer.

4.2.3 Operating environmentThe on-board software will run on bare hardware. Figure 4.4 shows the operating contextof the on-board software. The hardware interfaces of the external devices are detailedin [RD5]

4.2. ENVIRONMENTAL CONSIDERATIONS 13

Figure 4.3: OBC hardware structure.

Figure 4.4: OBC context diagram.


4.3 Relation to other systems

4.3.1 Top-level architectureFigure 4.5 shows the top-level architecture of the UPMSat2 mission software. The on-board software system is related with the ground station system by means of telecom-mands and telemetry messages exchanged over a radio link.

OBC GS TC!!

TM!!

GS_OBC!!

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

4.3.2 Ground station softwareFunction and purpose

The aim of the ground segment software is to monitor and control the operation of themission from the ground station. 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

Physical environment

The ground segment software shall run on a dedicated ground station located in the UPMIDR building. The approximate position of the ground station1 is 40.4063o N, 3.8320o W.

1Referred to the WGS84 datum.

4.3. RELATION TO OTHER SYSTEMS 15

Hardware environment

The ground station software shall run on a dedicated computer with the following charac-teristics:

• PC/x86 architecture with graphical display

• Internet connection

• Serial interface for connection to radio equipment

Operating environment

The ground station software shall run on a GNU/Linux operating system. Figure 4.6shows the operating context of the ground station computer.

GS!Operator interface!

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

Internet"

Figure 4.6: Ground station context diagram.

4.3.3 Electronic ground support softwareFunction and purpose

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

Physical environment

The electronic ground support equipment (EGSE) shall include all test equipment thatis required for the validation of the electronic subsystems of the satellite, including theOBC.


Hardware environment

The software validation facility (SVF) shall be based on a dedicated computer with thefollowing characteristics:

• PC/x86 architecture with graphical display

• Internet connection

• Serial interface for connection to radio equipment

• Serial interface for connection to the OBC

Operating environment

The software validation facility shall run on a GNU/Linux operating system. Figure 4.7shows the operating context of the ground station computer.

SVF!Operator interface!

Internet!

OBC!

Figure 4.7: Software validation facility context diagram.

4.4 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) [AD5] will be used for all engineering val-ues.

Chapter 5

Requirements

5.1 GeneralThe UPMSat2 software requirements are defined with relation to the logical model ar-chitecture described in chapter 8. Functional requirements are grouped according to thefunctional division into subsystems in the logical model.

The languages used in the logical model are AADL [D1], SDL [D2] and, when appli-cable, ASN-1 [D3] and Simulink [D9].

5.2 Functional requirements

5.2.1 System requirementsSYS-1 Configuration parameters

The system configuration parameters include:

• Global configuration parameters TBD

• Housekeeping configuration parameters (PMC-2).

• Attitude control configuration parameters (ACS-2).

• TTC configuration parameters (TTC-8).

SYS-2 System state

The system state includes the following information:

• Current operating mode (SYS-3)

• Mission time (SYS-4)

• Last values of housekeeping data (PMC-1)

• Last values of ACS data (ACS-1)

17

18 CHAPTER 5. REQUIREMENTS

SYS-3 Operating modes

The system will manage the operating mode of the satellite as defined in section 5.5.Unless explicitly stated, the functional requirements defined in this section refer to

nominal mode.

SYS-4 Mission time

The time elapsed since the separation from the launcher will be recorded by a hardwaremission clock (RES-5). Mission time shall be read by software at request.

The mission clock shall have a resolution of at least 1 s.

5.2.2 Platform monitoring and controlPMC-1 Housekeeping data

The system shall acquire housekeeping data at regular intervals as defined in table 5.1.Housekeeping data will be checked against a validity range. Values out of range will

be signalled as errors.The last values of the housekeeping data will be stored in the system state.Historical values of the housekeeping data will be stored in the logbook. Only a subset

of the samples will be stored, so that the amount of stored data that can be downloaded inthe next ground visibility interval is not exceeded.

Table 5.1: Housekeeping data.

Category Variable SamplingTemperature Satellite sides 60 s

Battery 60 sMagnetometer 60 s

Power Bus voltage 20 sBattery voltage 20 sBattery current 20 sSolar panels current 20 s

WARNING: To be completed with OBC data.

PMC-2 Housekeeping configuration parameters

The following parameters shall be configurable:

• Sampling periods for each kind of variable. The nominal periods are defined intable 5.1.

• Validity range for each variable.

• Logging periods for each kind of variable (must be multiples of the sampling peri-ods).

5.2. FUNCTIONAL REQUIREMENTS 19

PMC-3 Housekeeping events

The following housekeeping events are significant:

• Variable out of range.

• Sensor error (as provided by the hardware).

5.2.3 Attitude control system (ACS)ACS-1 Attitude control

The attitude control function shall be run periodically. The following actions shall beexecuted.

• Read the magnetometers and compute the value of the Earth magnetic field.

• Compute the control torque for the magnetorquers.

• Output the required current to the magnetorquers in order to apply the controltorque.

The values of the magnetometers are checked for validity. Invalid readings are sig-nalled as errors.

The current in the magnetorquers shall be read and checked for validity.The last values of magnetometer and magnetorquer current readings are stored in the

system state.Historical values of the magnetometers and magnetorquers data will be stored in the

logbook. Only a subset of the samples will be stored, so that the amount of stored datathat can be downloaded in the next ground coverage interval is not exceeded.

Table 5.2: ACS data.

Category Variable SamplingInput Magnetometer output 5 sOutput Current in magnetorquers 20 s

ACS-2 ACS configuration parameters

The following parameters shall be configurable:

• Sampling period for each kind of variable. The nominal period is defined in ta-ble 5.2.

• Control parameters.TBD

• Validity range for each variable.

• Logging periods for each kind of variable (must be multiples of the sampling peri-ods).


ACS-3 ACS events

The following ACS events are significant:

• Variable out of range.

• Sensor error (as provided by the hardware).

• Actuator error (as provided by the hardware).

5.2.4 Communications (TTC)TTC-1 Visibility interval

The visibility interval is defined as the time frame during which the satellite is withinreach of the ground station and can communicate with it.

When the satellite is not visible, the radio equipment is in standby mode and can onlyreceive messages. The transmitter is off in such situation.

The start of the visibility interval is detected when a telecommand is received fromthe ground station. The radio equipment can be used both for receiving and transmittingmessages in such situation.

The visibility interval ends when the latest of the following events occurs:

• No signal has been received from ground in the last 60 s.

• The maximum estimated duration of the visibility interval has elapsed. This valueis a configuration parameter.

TTC-2 Telemetry messages

The system shall provide an interface for sending telemetry messages to the ground sta-tion. The list of telemetry messages is defined in table 5.3. Telemetry messages can onlybe sent when the satellite is visible from the ground station. Messages sent when there isno visibility are ignored.

Table 5.3: Telemetry messages.

Category Code ContentsEvents 000 Hello

001 Event messageHousekeeping 100 Data messageExperiments 300- TBDTest 800- TBD

Event messages include any kind of event that has been recordec in the logbook fortransmission to ground. Errors are logged as events.

Data messages include all data values that have been registered in the logbook fortransmission to ground.

5.2. FUNCTIONAL REQUIREMENTS 21

TTC-3 Telemetry format

Telemetry messages shall include the following fields:

• Spacecraft identity.

• TM code (see table 5.3).

• Sequence number.

• Mission time.

• Message contents.

• Error check code.

TM messages may be split into packets as required by the communication protocol.

TTC-4 Telecommands

The following telecommands are defined for the satellite system (table 5.4).

Table 5.4: Telecommands.

Category Code DescriptionControl 000 Open link

001 Change mode002 Change configuration parameter003 Resend last message

ACS 200 Change control parameterExperiments 300- TBD

TTC-5 Execution of telecommands

Telecommand messages shall be verified for feasibility before execution.Telecommands may be executed in the following ways:

• Immediate execution, as soon as it is feasible.

• Programmed execution, at a specified mission time.

TTC-6 Telecommand format

Telecommand messages shall include the following fields:

• Spacecraft identity.

• TC code (see table 5.4).

• Sequence number.

• Execution time.


• Command parameters.

• Error check code.

TC messages may be split into packets as required by the communication protocol.The spacecraft identity field must include some kind of digital signature that ensures

that the source of the TC is a valid ground station.

TTC-7 Communication loss

Communications are assumed to be lost when a defined time interval has elapsed withouthaving received any message from ground.

Suggested value is 1–2 days.

TTC-8 TTC configuration parameters

The following configuration parameters are defined for the TTC functions:

• Maximum duration of visibility interval.

• Time interval for communication loss.

5.2.5 Data and event loggingDLG-1 Data logging

Data log entries shall be recorded at request from the satellite subsystems.

DLG-2 Event logging

Event log entries shall be recorded at request from the satellite subsystems.Errors detected by the software system at any level will be recorded as events.

5.3 Performance requirementsPFC-1 Real-time behaviour

Real-time requirements for the following functional items shall be defined at design time.

• Event management and mode control

• Housekeeping data acquisition.

• Attitude control system.

• Telemetry and telecommand management

• Data logging

TBC

5.4. INTERFACE REQUIREMENTS 23

5.4 Interface requirementsTBC

5.5 Operational requirementsOPR-1 System operating modes

The system operating modes are shown in figure 5.1. 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!

critical battery!

Ground!

Off! Test!

Await Launch!

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


5.5.1 Ground operating modesOPR-2 Off mode

When the satellite is in the off mode the OBC is switched off, with no power beingsupplied to it and consequently no software executing.

When power is supplied to the OBC the system transitions to the test mode.

OPR-3 Test mode

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

The test mode has to be further refined. The SVF should be able to test the software inall the flight modes, for which purpose the appropriate environment has to be simulatedon the SVF.

The software can detect if it is in test mode by sensing the test connector.

OPR-4 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.

5.5. OPERATIONAL REQUIREMENTS 25

5.5.2 Flight operating modesOPR-5 Launch mode

When the system is in launch mode the OBC is switched off, with no power being sup-plied to it and consequently no software executing.

When separation is complete, a hardware separation timer, which is not part of theOBC, is automatically started. When the timer expires the OBC is powered up, and theinitialization mode is entered.

OPR-6 Initialization mode

This mode is entered when one of the following events occur:

• Separation timer expired

• Latency timer expired

• Hardware reset (including watchdog timer expired)

• Change mode telecommand

When the system enters the initialization mode, the following functions are executedin sequence:

• Load the on-board software and start execution.

• Configure all the hardware devices in the OBC boards.

Reference hardware design document.

• Check that the satellite is separated from the launcher, by reading the separationstatus signal.

If the separation signal is off, the satellite is on ground and test mode can be as-sumed. This condition is to be further analysed.

The first time that the system is initialised, the system enters the commissioning mode.On subsequent initializations, the system transitions to the safe mode.

OPR-7 Commissioning mode

When the system enters this mode, all the satellite subsystems are checked and configuredas needed. The functional components of the software will be configured as follows:

a) Platform management and control (PMC)

• Check that all housekeeping data sensors are working and provide valid values.

b) Attitude control system (ACS)

• Check that magnetometers are working and provide valid values


• Perform initial control actions until the nominal attitude and rotation speed arereached.

c) Communication system (TTC)

• Check that the radio equipment is working.

• Set the radio equipment in standby mode.

d) Data and event logging (DLG)

• Check configuration data for all subsystems.

• Start data and event log register.

e) Experiments

Commissioning operations have to be defined for all experiments.

When all the commissioning operations have been completed the system changes tosafe mode.

When an error is detected in one or more commissioning operations, the error isrecorded in the log book and then the system changes to safe mode.

A maximum commissioning duration is defined as a configuration parameter. If thespecified duration is exceeded, the system records the error in the log book, and thenchanges to safe mode.

Transition to beacon mode might also be possible.

OPR-8 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, in order to enable batteries to becharged.

The safe mode can be entered:

• By a software action, after the completion of the initialization or commissioningmode operations.

• By a warning battery low (WBL) hardware event signalling a low charge level inthe batteries.

• By a change mode telecommand.

The functions to be executed in safe mode are to be defined when a better knowledgeof power consumption by all equipment is available.

Possible functions:

• Housekeeping at a lower rate

• ACS as in nominal mode

• TTC in standby, ready to receive TCs. TM reduced to current state TBC.

5.5. OPERATIONAL REQUIREMENTS 27

• No experiments.

No experiments shall be carried out in safe mode.The safe mode can be exited:

• By the execution of a change mode telecommand.

• By a warning battery critical (WBC) hardware event signalling a low charge levelin the batteries. In this case the system changes to latency mode.

• By software request after a communication loss has been detected (TTC-7). In thiscase the system changes to beacon mode.

The WBC signal causes the OBC to be powered off automatically after a few seconds.The available time should be used to record the event on the logbook and clean up thesoftware state.

OPR-9 Nominal mode

When the system is in nominal mode, all the system functions are executed as defined insection 5.2.

The nominal mode can be entered:

• By a change mode telecommand.

• By an experiment time expired (ETE) hardware event signalling the expiration ofthe allowed time for an experiment.

The functions that are executed in nominal mode are as follows:

a) Platform management and control (PMC)

• Nominal housekeeping as defined in PMC-1.

b) Attitude control system (ACS)

• Nominal attitude control as defined in ACS-1.

c) Communication system (TTC)

• Normal operation as defined in TTC-1, TTC-2, TTC-4, and TTC-5.

d) Data and event logging (DLG)

• Normal operation as defined in DLG-1 and DLG-2.

e) Experiments

The nominal mode can be exited:

• By the execution of a change mode telecommand.

• By a warning battery low (WBL) hardware event signalling a low charge level inthe batteries. In this case the system changes to safe mode.

• By a software request after a communication loss has been detected (TTC-7). Inthis case the system changes to beacon mode.


OPR-10 Experiment mode

The experiment mode is entered when a telecommand is executed. The telecommand shallspecify the experiment to be executed, the parameters of the experiment, as applicable,and the start and end times of the experiment.

The experiment mode can be exited:

• By a software event indicating the end of the experiment and the return to nominalmode.

• By a timer signal indicating that the end time has been reached. In this case thesystem changes to nominal mode.

• By a telecommand.

OPR-11 Latency mode

The latency mode is entered when a warning battery critical (WBC) hardware event issignalled.

In this mode the OBC is off in order to allow the batteries to be charged.The latency mode is exited when a hardware latency timer expires. The OBC is pow-

ered and the software starts in initialization mode.The duration of the latency interval is a system configuration parameter.The WBC signal causes the OBC to be powered off automatically after a few seconds.

The available time should be used to record the event on the logbook and clean up thesoftware state.

OPR-12 Beacon mode

The beacon mode is entered by a software action after a communication loss is detected(TTC-7).

While in this mode the radio equipment is configured to work in low bit rate. Thesystem transmits a signal periodically, and awaits a ground message to be received as aresponse.

The beacon mode is left:

• When a valid ground signal is received. The system then changes to safe mode.

• If a WBL is received the system immediately changes to safe mode.

5.6 Resource requirements

5.6.1 Storage requirementsRES-1 Persistent storage

The system shall provide persistent storage for configuration parameters, system state,and data and event log.

The amount of persistent storage available for data and event logging will be enoughfor a 12 hour period of log data to be stored.

5.7. DESIGN REQUIREMENTS AND IMPLEMENTATION CONSTRAINTS 29

5.6.2 Hardware timersRES-2 Separation timer

A hardware timer will be activated at the time when separation from the launcher takesplace. When the timer expires, the OBC is powered on, and the software starts loadingand executing in initialization mode.

The duration of the separation timer interval is a system configuration parameter.

RES-3 Latency timer

A hardware timer will be activated when the system enters latency mode. When thetimer expires, the OBC is powered on, and the software starts loading and executing ininitialization mode.

The duration of the latency timer interval is a system configuration parameter. It willbe sufficient to allow the batteries to be charged after a critical voltage event.

The latency timer and the separation timer may be implemented by the same hardwaredevice.

RES-4 Watchdog timer

A watchdog timer shall be available in hardware. The timer will be started periodicallyby software. If the timer expires, a hardware reset signal will be issued to the OBC inorder to restart its operation.

The watchdog timer interval and the start period are system configuration parameters.

RES-5 Mission clock

A hardware clock shall keep track of the time elapsed since separation.

5.7 Design requirements and implementation constraintsDIC-1 Software standards

The following software standards are applicable:

• 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].

• 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].


DIC-2 Software development tools

The following software development tools will be used for developing the on-board soft-ware:

• GNATforLEON Pro

DIC-3 Software platform

The software will run on the GNATforLEON Ravenscar run-time system, including theORK+ real-time kernel.

5.8 Security and privacy requirements requirementsSEC-1 Identification of ground station

Telecommands will carry a digital signature to ensure that they have been sent by a validground station.

5.9 Portability requirementsPTB-1 Encapsulation of hardware details

Low-level hardware details shall be encapsulated so that the software can be ported toother satellite platforms.

5.10 Software quality requirementsSWQ-1 Ada quality and style

Program code in Ada will follow the guidelines of the latest edition of the Ada Qualityand Style Guide [D7].

It may better to refer to the GNAT/GPS style modes.

5.11 Software reliability requirementsTBC

5.12 Software maintainability requirementsTBC

5.13 Software configuration and delivery requirementsTBC

5.14. DATA DEFINITION REQUIREMENTS 31

5.14 Data definition requirementsTBC

5.15 Human factors-related requirementsTBC

5.16 Adaptation and installation requirementsTBC

Chapter 6

Validation requirements

33

34 CHAPTER 6. VALIDATION REQUIREMENTS

Chapter 7

Traceability

35

36 CHAPTER 7. TRACEABILITY

Chapter 8

Logical model description

37

38 CHAPTER 8. LOGICAL MODEL DESCRIPTION

UPMSAT-2 - DIT · Chapter 1 Introduction 1.1 Purpose This the Software Requirements Speciﬁcation...

Documents

Transcript of UPMSAT-2 - DIT · Chapter 1 Introduction 1.1 Purpose This the Software Requirements Speciﬁcation...