UPMSAT-2 On-Board Software Software Requirements Specification Version 1.2 3 March, 2014
UNIVERSIDAD POLITÉCNICADE MADRID
GRUPODE SISTEMASDE TIEMPO REAL Y ARQUITECTURADE 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 Alonso Juan Zamorano Ángel Sanz
Changes
Version/Revision Date Purpose Author 1.0 10-01-2014 Initial draft J.A. de la Puente 1.1 19-02-2014 Internal review J.A. de la Puente 1.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. Contents
1 Introduction 1 1.1 Purpose ...... 1 1.2 Scope ...... 1 1.3 Content ...... 1
2 References 3 2.1 Applicable documents ...... 3 2.2 Reference documents ...... 3 2.3 Other documents ...... 4
3 Terms, definitions and abbreviated terms 5 3.1 Definitions ...... 5 3.2 Notation ...... 5 3.3 Abbreviated terms ...... 5
4 Software overview 9 4.1 Function and purpose ...... 9 4.2 Environmental considerations ...... 9 4.2.1 Physical environment ...... 9 4.2.2 Hardware environment ...... 12 4.2.3 Operating environment ...... 12 4.3 Relation to other systems ...... 14 4.3.1 Top-level architecture ...... 14 4.3.2 Ground station software ...... 14 4.3.3 Electronic ground support software ...... 15 4.4 Constraints ...... 16
5 Requirements 17 5.1 General ...... 17 5.2 Functional requirements ...... 17 5.2.1 System requirements ...... 17 5.2.2 Platform monitoring and control ...... 18 5.2.3 Attitude control system (ACS) ...... 19 5.2.4 Communications (TTC) ...... 20 5.2.5 Data and event logging ...... 22 5.3 Performance requirements ...... 22 5.4 Interface requirements ...... 23
i 5.5 Operational requirements ...... 23 5.5.1 Ground operating modes ...... 24 5.5.2 Flight operating modes ...... 25 5.6 Resource requirements ...... 28 5.6.1 Storage requirements ...... 28 5.6.2 Hardware timers ...... 29 5.7 Design requirements and implementation constraints ...... 29 5.8 Security and privacy requirements requirements ...... 30 5.9 Portability requirements ...... 30 5.10 Software quality requirements ...... 30 5.11 Software reliability requirements ...... 30 5.12 Software maintainability requirements ...... 30 5.13 Software configuration and delivery requirements ...... 30 5.14 Data definition requirements ...... 31 5.15 Human factors-related requirements ...... 31 5.16 Adaptation and installation requirements ...... 31
6 Validation requirements 33
7 Traceability 35
8 Logical model description 37
ii Chapter 1
Introduction
1.1 Purpose
This the Software Requirements Specification (SRS) document, as defined in ECSS-E- ST-40C [AD1], for the UPMSat2 on-board software
1.2 Scope
This document covers the on-board computer (OBC) software of the UPMSat2 mission.
1.3 Content
This 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. March 2009.
[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. December 2012.
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-T X.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 language in high integrity systems, 2000.
[D6] ISO. ISO/IEC TR 24718:2005 — Guide for the use of the Ada Ravenscar Profile in high integrity systems, 2005. Based on the University of York Technical Report YCS-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. Chapter 3
Terms, definitions and abbreviated terms
3.1 Definitions
The terms defined in [AD1] and [AD2] will be used as needed.
3.2 Notation
A logical model of the system, capturing the most important aspects of the specification, has been built using AADL [D1].
3.3 Abbreviated terms
AADL 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 purpose
The aim of the UPMSat2 on-board software is to monitor and control the operation of the satellite 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 around Z 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 is half 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 bps max – Uplink: UHF 400 MHz band (ISM/Amateur Radio Satellite), 2400 bps max 4.2. ENVIRONMENTAL CONSIDERATIONS 11
Z+!
X+! Y+!
Z-!
Figure 4.1: General view of the UPMSat-2 satellite.
Figure 4.2: Attitude control reference. 12 CHAPTER 4. SOFTWARE OVERVIEW
Payload The payload of the UPMSat2 satellite mission consists of a number of experiments, some of 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 environment The 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 environment The on-board software will run on bare hardware. Figure 4.4 shows the operating context of the on-board software. The hardware interfaces of the external devices are detailed in [RD5] 4.2. ENVIRONMENTAL CONSIDERATIONS 13
Figure 4.3: OBC hardware structure.
Figure 4.4: OBC context diagram. 14 CHAPTER 4. SOFTWARE OVERVIEW
4.3 Relation to other systems
4.3.1 Top-level architecture Figure 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.
GS_OBC! OBC ! GS TC! TM! ! !
Figure 4.5: Top-level architecture of the UPMSat2 mission software.
4.3.2 Ground station software Function and purpose The aim of the ground segment software is to monitor and control the operation of the mission 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 UPM IDR 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.6 shows the operating context of the ground station computer.
Radio! Operator GS! - uplink (TC) interface! - downlink (TM)
Internet
Figure 4.6: Ground station context diagram.
4.3.3 Electronic ground support software Function and purpose The EGSE (Electronic Ground Support Equipment) software is aimed at controlling and monitoring all ground-based tests run on the satellite. It includes a software validation facility (SVF) supporting the execution of software validation tests.
Physical environment The electronic ground support equipment (EGSE) shall include all test equipment that is required for the validation of the electronic subsystems of the satellite, including the OBC. 16 CHAPTER 4. SOFTWARE OVERVIEW
Hardware environment The software validation facility (SVF) shall be based on a dedicated computer with the following characteristics:
• PC/x86 architecture with graphical display
• Internet connection
• Serial interface for connection to radio equipment
• Serial interface for connection to the OBC
Operating environment The software validation facility shall run on a GNU/Linux operating system. Figure 4.7 shows the operating context of the ground station computer.
Operator SVF! OBC! interface!
Internet!
Figure 4.7: Software validation facility context diagram.
4.4 Constraints
1. 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 available at 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 General
The UPMSat2 software requirements are defined with relation to the logical model ar- chitecture described in chapter 8. Functional requirements are grouped according to the functional 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 requirements SYS-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 hardware mission 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 control PMC-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 in the next ground visibility interval is not exceeded.
Table 5.1: Housekeeping data.
Category Variable Sampling Temperature Satellite sides 60 s Battery 60 s Magnetometer 60 s Power Bus voltage 20 s Battery voltage 20 s Battery current 20 s Solar 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 in table 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 be executed.
• 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 control torque.
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 data that can be downloaded in the next ground coverage interval is not exceeded.
Table 5.2: ACS data.
Category Variable Sampling Input Magnetometer output 5 s Output 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). 20 CHAPTER 5. REQUIREMENTS
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 within reach of the ground station and can communicate with it. When the satellite is not visible, the radio equipment is in standby mode and can only receive messages. The transmitter is off in such situation. The start of the visibility interval is detected when a telecommand is received from the ground station. The radio equipment can be used both for receiving and transmitting messages 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 value is 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 only be sent when the satellite is visible from the ground station. Messages sent when there is no visibility are ignored.
Table 5.3: Telemetry messages.
Category Code Contents Events 000 Hello 001 Event message Housekeeping 100 Data message Experiments 300- TBD Test 800- TBD
Event messages include any kind of event that has been recordec in the logbook for transmission to ground. Errors are logged as events. Data messages include all data values that have been registered in the logbook for transmission 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 Description Control 000 Open link 001 Change mode 002 Change configuration parameter 003 Resend last message ACS 200 Change control parameter Experiments 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. 22 CHAPTER 5. REQUIREMENTS
• 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 without having 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 logging DLG-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 requirements
PFC-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 requirements
TBC
5.5 Operational requirements
OPR-1 System operating modes The system operating modes are shown in figure 5.1. The meaning of each mode is defined in the following paragraphs.
Ground!
Off Test
Await Launch
Flight!
Inactive! Normal_operation!
critical battery TC Launch Latency Nominal timer | TC Experiment
critical battery low separation latency TC battery | timer timer error | lost COMM watchdog TC timer
Checking! Degraded operation! TC
auto | timer lost COMM Initialization Commissioning Safe Beacon TC received
Figure 5.1: Operating modes of the UPMSat-2 on-board software. 24 CHAPTER 5. REQUIREMENTS
5.5.1 Ground operating modes OPR-2 Off mode When the satellite is in the off mode the OBC is switched off, with no power being supplied 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 SVF computer 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 in all the flight modes, for which purpose the appropriate environment has to be simulated on 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 power being supplied to it and consequently no software executing. The batteries are in trickle charge mode, and the radio equipment is off. From the point of view of software, this mode is functionally equivalent to the launch mode. The transition to the latter is implicitly executed when the launch starts. 5.5. OPERATIONAL REQUIREMENTS 25
5.5.2 Flight operating modes OPR-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 the OBC, is automatically started. When the timer expires the OBC is powered up, and the initialization 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 executed in 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 separation status 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 configured as 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 26 CHAPTER 5. REQUIREMENTS
• Perform initial control actions until the nominal attitude and rotation speed are reached. 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 to safe mode. When an error is detected in one or more commissioning operations, the error is recorded in the log book and then the system changes to safe mode. A maximum commissioning duration is defined as a configuration parameter. If the specified duration is exceeded, the system records the error in the log book, and then changes 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 the operation of the satellite with a low power consumption, in order to enable batteries to be charged. The safe mode can be entered:
• By a software action, after the completion of the initialization or commissioning mode operations.
• By a warning battery low (WBL) hardware event signalling a low charge level in the batteries.
• By a change mode telecommand.
The functions to be executed in safe mode are to be defined when a better knowledge of 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 level in the batteries. In this case the system changes to latency mode. • By software request after a communication loss has been detected (TTC-7). In this case 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 the software state.
OPR-9 Nominal mode When the system is in nominal mode, all the system functions are executed as defined in section 5.2. The nominal mode can be entered: • By a change mode telecommand. • By an experiment time expired (ETE) hardware event signalling the expiration of the 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 in the batteries. In this case the system changes to safe mode. • By a software request after a communication loss has been detected (TTC-7). In this case the system changes to beacon mode. 28 CHAPTER 5. REQUIREMENTS
OPR-10 Experiment mode The experiment mode is entered when a telecommand is executed. The telecommand shall specify 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 nominal mode. • By a timer signal indicating that the end time has been reached. In this case the system changes to nominal mode. • By a telecommand.
OPR-11 Latency mode The latency mode is entered when a warning battery critical (WBC) hardware event is signalled. 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 the software 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. The system transmits a signal periodically, and awaits a ground message to be received as a response. 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 requirements RES-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 enough for a 12 hour period of log data to be stored. 5.7. DESIGN REQUIREMENTS AND IMPLEMENTATION CONSTRAINTS 29
5.6.2 Hardware timers RES-2 Separation timer A hardware timer will be activated at the time when separation from the launcher takes place. When the timer expires, the OBC is powered on, and the software starts loading and 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 the timer expires, the OBC is powered on, and the software starts loading and executing in initialization mode. The duration of the latency timer interval is a system configuration parameter. It will be 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 hardware device.
RES-4 Watchdog timer A watchdog timer shall be available in hardware. The timer will be started periodically by software. If the timer expires, a hardware reset signal will be issued to the OBC in order 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 constraints
DIC-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 in high integrity systems [D5].
• ISO/IEC TR 24718:2005 Guide for the use of the Ada Ravenscar Profile in high integrity systems [D6]. 30 CHAPTER 5. REQUIREMENTS
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 the ORK+ real-time kernel.
5.8 Security and privacy requirements requirements
SEC-1 Identification of ground station Telecommands will carry a digital signature to ensure that they have been sent by a valid ground station.
5.9 Portability requirements
PTB-1 Encapsulation of hardware details Low-level hardware details shall be encapsulated so that the software can be ported to other satellite platforms.
5.10 Software quality requirements
SWQ-1 Ada quality and style Program code in Ada will follow the guidelines of the latest edition of the Ada Quality and Style Guide [D7]. It may better to refer to the GNAT/GPS style modes.
5.11 Software reliability requirements
TBC
5.12 Software maintainability requirements
TBC
5.13 Software configuration and delivery requirements
TBC 5.14. DATA DEFINITION REQUIREMENTS 31
5.14 Data definition requirements
TBC
5.15 Human factors-related requirements
TBC
5.16 Adaptation and installation requirements
TBC 32 CHAPTER 5. REQUIREMENTS 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