UPMSAT-2 Software Requirements Baseline. Software System Specification

Transcription

1 UPMSAT-2 Software Requirements Baseline Software System Specification Version October 2014 UNIVERSIDAD POLITÉCNICA DE MADRID GRUPO DE SISTEMAS DE TIEMPO REAL Y ARQUITECTURA DE SERVICIOS TELEMÁTICOS Revisión 674 October 10, :36:53

2 Copyright c DIT/UPM 2014 This work is licensed under a Creative Commons Attribution-NonCommercial-NoDerivs 3.0 Unported license. See State: Written by: Reviewed by: Review Juan A. de la Puente Juan Zamorano Alejandro Alonso Ángel Sanz Modificaciones Version/Revision Date Purpose Author V&V requirements added J.A. de la Puente TTC requirements updated J.A. de la Puente English version J.A. de la Puente Versión revisada J.A. de la Puente Versión revisada J.A. de la Puente, J. Zamorano Versión revisada J.A. de la Puente, J. Zamorano Versión revisada J.A. de la Puente, J. Zamorano Versión revisada J.A. de la Puente, J. Zamorano Versión revisada J.A. de la Puente, J. Zamorano Versión revisada J.A. de la Puente, J. Zamorano Versión para revisión J.A. de la Puente, J. Zamorano Borrador inicial J.A. de la Puente, J. Zamorano Members of the UPMSat2 project IDR STRAST TECNOBIT Instituto Universitario de Microgravedad Ignacio da Riva (UPM) Sistemas de Tiempo Real y Arquitectura de Servicios Telemáticos (UPM) Tecnobit, S.L.

3 Contents 1 Introduction Purpose Scope Content References Applicable documents Reference documents Other documents Terms, definitions and abbreviated terms Definitions Notation Abbreviated terms General description Product perspective General capabilities On-board software Ground station software Electronic ground support software System modes General constraints Operational environment Overall architecture On-board computer software Ground station software Electronic ground support equipment (EGSE) Assumptions and dependencies Specific requirements General Capabilities requirements Functions of the on-board software system Operating modes System interface requirements Adaptation and missionization requirements Computer resource requirements i

4 5.5.1 Computer hardware resource requirements Computer hardware resource utilization requirements Computer software resource requirements Security requirements Safety requirements Reliability and availability requirements Quality requirements Design requirements and constraints Software operations requirements Software maintenance requirements System and software observability requirements Verification, validation and system integration Verification and validation process requirements On-board software Ground segment software Validation approach Validation requirements Verification requirements A Requirements validation matrix 33 ii

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

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

7 List of Figures 4.1 General view of the UPMSat-2 satellite Top-level architecture of the UPMSat2 mission software Attitude control reference OBC context diagram Ground station context diagram Software validation facility context diagram ACS functional diagram Operating modes of the UPMSat-2 on-board software v

8 vi

9 Chapter 1 Introduction 1.1 Purpose This the Software System Specification (SSS) document, as defined in ECSS-E-ST-40C [AD1], for the UPMSat2 software 1.2 Scope This document covers the following software systems: On-board computer (OBC) software. Ground station (GS) software Electronic ground support equipment (EGSE) software 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 a general description of the UPMSat2 system. Chapter 5 contains specific software requirements for the UPMSat2 system. Chapter 6 contains verification, validation, and integration requirements for the UPMSat2 software. 1

10 2 CHAPTER 1. INTRODUCTION

11 Chapter 2 References 2.1 Applicable documents [AD1] ECCS-E-ST-40C Space Engineering Software. March [AD2] ECSS-Q-ST-80C Space Product Assurance Software Product Assurance. March [AD3] ECSS-E-ST-50C Space engineering Communications. July [AD4] ECSS-E-ST-50-01C Space engineering Space data links - Telemetry synchronization and channel coding. July [AD5] ECSS-E-ST-50-03C Space engineering Space data links - Telemetry transfer frame protocol. July [AD6] ECSS-E-ST-50-04C Space engineering Space data links - Telecommand protocols synchronization and channel coding. July [AD7] ECSS-E-ST-70C Space engineering Ground systems and operations. July [AD8] ECSS-E-70-41A Space engineering Ground systems and operations Telemetry and telecommand packet utilization. January [AD9] The International System of Units (SI). Bureau International des Poids et Mesures, Reference documents [RD1] UPMSAT2 Documento de requerimientos del Sistema (SRD). Enero [RD2] Concepto UPMSat-2. UPM-IDR US2-PM-PLN-002-R [RD3] Modos de funcionamiento. Mayo [RD4] UPMSat-2 Functional Block Diagrams (FBD)

12 4 CHAPTER 2. REFERENCES [RD5] UPMSat-2 Interface Control Document. UPMSAT2-SE-ICD-003 Draft. Diciembre [RD6] UPMSAT2 Resumen de especificaciones. V01D. Diciembre [RD7] UPMSAT2 Cargas útiles. Resumen. Noviembre [RD8] UPMSAT2 Requirement Matrix EBOX ISS-00 Draft. December [RD9] UPMSat2 Communication Interface. EMX-UPS-TN-001. July Other documents [D1] SAE. SAE AS5506A Architecture Analysis and Design Language (AADL), January Available at [D2] ITU. Specification and Design Language Overview of SDL-2010, Recommendation ITU-T Z.100. [D3] ITU. Abstract Syntax Notation One (ASN.1), Recommendations ITU-T X [D4] ISO/IEC 8652:2012(E): Information Technology Programming Languages Ada, [D5] ISO/IEC TR 15942:2000 Guide for the use of the Ada programming language in high integrity systems, [D6] ISO. ISO/IEC TR 24718:2005 Guide for the use of the Ada Ravenscar Profile in high integrity systems, Based on the University of York Technical Report YCS (2003). [D7] Ada Quality and Style Guide, Available at wiki/ada_style_guide. [D8] John Barnes. SPARK - The Proven Approach to High Integrity Software. Altran, [D9] Mathworks. Simulink, [D10] Ian Sommerville. Software Engineering. Pearson Education, 9 edition, [D11] LEON3 - High-performance SPARC V8 32-bit Processor. GRLIB IP Core User s Manual, [D12] ISO. ISO/IEC 8652:1995(E)/TC1(2000)/AMD1(2007): Information Technology Programming Languages Ada, 2007.

13 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. AD Applicable document. ADCS Attitude determination and control subsystem. ADL Amateur band downlink. AI Analog input. AOCS Attitude and orbit control system. AUL Amateur band uplink. COTS Commercial-off-the-shelf. CPU Central processing unit. DDR2-SDRAM Double data rate synchronous dynamic random-access memory interface, version 2. DHU Data handling unit. 5

14 6 CHAPTER 3. TERMS, DEFINITIONS AND ABBREVIATED TERMS DI Digital input. DO Digital output. ECSS European Cooperation on Space Standardization. EGSE Electronic Ground Support Equipment. ESA European Space Agency. ESTEC European Space Research and Technology Center. FPGA Field-programmable gate array. FDIR Fault detection, isolation and recovery. FPU Floating-point unit. GS Ground station. HMI Human-machine interface. IDR Instituto Universitario de Investigación Ignacio da Riva. I/O Input-ouput. LEO Low Earth orbit. MAC Magnetic-field Attitude Control. MGM Magnetometer(s). MGT Magnetorquer(s). MRAD Monitoring of the effects of radiation. MTS Micro-Thermal Switch. OBC On-board computer. OBDH On-board data handling. ORK Open Ravenscar Real-Time kernel. RAM Random-access memory. RD Reference document. RDL Research band downlink. ROM Read-only memory. RW Reaction wheel. ROLEU Registro de Objetos lanzados al espacio ultraterrestre (Spanish).

15 3.3. ABBREVIATED TERMS 7 SCT Solar Cell Technology. SMA Shape Memory Alloys. SPS Separation System. SRS Software Requirements Specification. SS Subsystem. SS Solar sensor. SSD Solid-state drive. SSS Software System Specification. TBC To be completed. TBD To be defined. TC Telecommand. TM Telemetry. TMC Thermal control. TTC Telemetry and telecommand. UPM Universidad Politécnica de Madrid. VHDL VHSIC hardware description language. VHSIC Very-high-speed integrated circuits.

16 8 CHAPTER 3. TERMS, DEFINITIONS AND ABBREVIATED TERMS

17 Chapter 4 General description 4.1 Product perspective The aim of the UPMSat-2 project is to develop a micro-satellite mission that can be used as an in-orbit technology demonstration platform. The project is being carried out by a team of researchers, students, and auxiliary staff at Universidad Politécnica de Madrid (UPM). The project is led by the Ignacio da Riva research institute (IDR), with the participation of the STRAST research group, TECNOBIT, and other research groups and industrial companies. STRAST is in charge of software development, and TECNOBIT is in charge of developing the on-board computer hardware and other electronic subsystems for the mission. Figure 4.1 shows a general view of the UPMSat-2 satellite design. Z+! X+! Y+! Z-! Figure 4.1: General view of the UPMSat-2 satellite. 9

18 10 CHAPTER 4. GENERAL DESCRIPTION 4.2 General capabilities On-board software The aim of the UPMSat2 on-board software is to monitor and control the operation of the satellite platform. Its main functions are: Platform monitoring and control, including acquisition of housekeeping data (HK) Attitude control (ADC) Encoding and transmission of telemetry messages (TM) Reception, decoding and execution of telecommands (TC) Time management Fault detection, isolation, and recovery (FDIR) Payload data management Data and event logging Ground station software The aim of the ground station software is to monitor and control the operation of the mission. 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 Electronic ground support software 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 System modes The system operates in different modes according to the overall conditions of the mission. The detailed specification of the system modes and the functions to be executed in each mode can be found in section

19 4.3. GENERAL CONSTRAINTS General 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 profile [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 The International System of Units (SI) [AD9] will be used for all engineering values. 4.4 Operational environment Overall architecture Figure 4.2 shows the overall architecture of the UPMSat2 mission software. The on-board software system is related with the ground station system by means of telecommands and telemetry messages exchanged over a radio link. OBC TC!! GS_OBC!! TM!! GS Figure 4.2: Top-level architecture of the UPMSat2 mission software On-board computer software Satellite platform characteristics Orbital parameters Noon sun-synchronous low Earth orbit (LEO) Altitude: 600 km Inclination: 98 o Period: 97 min Eclipse time: 36 min Visibility from ground station: 10 min, 2 times a day.

20 12 CHAPTER 4. GENERAL DESCRIPTION Platform envelope (see figure 4.1) Dimensions: 500 mm 500 mm 600 mm (figure 4.1). Mass: 50 kg. Attitude control Active control based on the Earth magnetic field Reference attitude: Z-axis normal to orbit plane, X and Y axes rotating around Z axis (figure 4.3). Sensors: magnetometers Actuators: magnetorquers Figure 4.3: Attitude control reference. Thermal control Passive thermal control, based on isolating materials. Electric power Power generation: 5 GaAs solar panels. The panel on the upper (Z+) side 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: V Stabilized voltage supply for subsystems: +5 V, ±15 V Telecommunications UHF U band (AMSAT): MHz Uplink (telecommands): max 4800 bps Downlink (housekeeping data): max 9600 bps UHF space research band: MHz Downlink (experiment data): max 9600 bps

21 4.4. OPERATIONAL ENVIRONMENT 13 On-board computer hardware There is a single on-board computer (OBC), with following characteristics: FPGA-based LEON3 CPU 4 MB SRAM 1 MB EEPROM Serial interfaces: RS-232, RS-422, SPI, I2C Device interfaces: 64 analog input channels, 64 digital I/O signals Figure 4.4 summarizes the operating environment of the on-board computer. ADC sensors! - magnetometres" - solar cells" ADC actuators! - magnetorquers" - reaction wheel" OBC! Radio! - uplink (TC)" - downlink (TM)" Housekeeping sensors! - temperatures" - voltages" - currents" Experiments! Figure 4.4: OBC context diagram.

22 14 CHAPTER 4. GENERAL DESCRIPTION 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). Test a MTS device, provided by IberEspacio. 1 The device conducts heat when enabled. The experiment consists in dissipating heat from some component to a radiator so as to keep the component temperature below a limit. 2. SCT (Solar Cell Technology). Test a set of solar cells provided by ESA/ESTEC TEC-EPG MGM (Magnetometer). Test a magnetometer provided by Bartington 3. The magnetometer is used for nominal ADCS. The experiment consists in collecting additional measurements for calibration. 4. MRAD (Radiation Effect Monitoring). Characterize the effect of radiation on hardware, by testing a range of memory cells. Proposed by TECNOBIT and STRAST/UPM. 5. SMA (Shape Memory Alloys). Test the use of SMA provided by Arquimea 4 in actuators for the deployment of two booms. 6. RW (Reaction Wheel). Test the use of a reaction wheel provided by SSBV 5 for attitude control. 7. SS6 (Solar Sensors). Test a set of solar cells provided by IES/UPM 6 as attitude sensors. 8. TMC (Thermal Control Data). Get thermal data for thermal design of spacecraft at IDR/UPM. 9. BOOM (Extension boom). Test a boom designed by IDR/UPM. 10. MAC (Magnetic Attitude Control). Test alternative attitude control methods designed by IDR/UPM. 11. SPS (Separation System). Test a separation system developed by Astrium EADS

23 4.4. OPERATIONAL ENVIRONMENT Ground station software There is one ground station located in the IDR building. Is approximate position is o N, o W. 8 The ground station has a dedicated computer with the following characteristics: PC/x86 architecture with graphical display Internet connection Serial interface for connection to radio equipment GNU/Linux operating system. Figure 4.5 shows the operating context of the ground station computer. Operator interface! GS! Radio! - uplink (TC)" - downlink (TM)" Internet" Figure 4.5: Ground station context diagram Electronic ground support equipment (EGSE) The electronic ground support equipment (EGSE) includes all the test equipment that is required for the validation of the electronic subsystems of the satellite, including the OBC. The components of the EGSE that support the validation of on-board software make up the software validation facility (SVF). The SVF is based on a dedicated computer with the following characteristics: PC/x86 architecture with graphical display Internet connection Serial interface for connection to radio equipment Serial interface for connection to the OBC GNU/Linux operating system. 8 Referred to the WGS84 datum.

24 16 CHAPTER 4. GENERAL DESCRIPTION Figure 4.6 shows the operating context of the SVF. Operator interface! SVF! OBC! Internet! Figure 4.6: Software validation facility context diagram. 4.5 Assumptions and dependencies The development of on-board software depends on the hardware architecture of the OBC and other satellite subsystems. The development of ground software depends on the hardware architecture of the ground station.

25 Chapter 5 Specific requirements 5.1 General The requirements specified in this section apply only to on-board software. Ground station software is covered separately. 5.2 Capabilities requirements Functions of the on-board software system RB-1 Housekeeping data The software system will monitor the following kinds of housekeeping data by periodic sampling of sensors: Temperature Power Satellite sides Battery Magnetometers Computer Experiments Battery voltage Bus voltage Current at battery Current at solar panels The housekeeping data measurements will be checked for validity. Values outside the valid range will be reported. 17

26 18 CHAPTER 5. SPECIFIC REQUIREMENTS RB-2 Attitude control The attitude of the spacecraft will be controlled using measurements of the Earth magnetic field provided by magnetometers. A control algorithm will be used to compute the required correcting actions provided by magnetorquers. The magnetometer readings and the output to magnetorquers will be checked for validity. Values outside the valid range will be reported. Figure 5.1 shows the functional configuration of the attitude control system. magnetic magnetometer! field! controller! torquers! estimation! satellite dynamics! disturbances! Figure 5.1: ACS functional diagram. RB-3 Telemetry Basic telemetry messages shall be broadcast periodically when the satellite is out of visibility of the ground station or when it is operating in beacon mode. Basic telemetry messages shall be sent on the amateur band downlink, and include the following data items: Identification of the satellite. Basic housekeeping data. Nominal telemetry messages may be sent to ground during the visibility interval. These messages shall be transmitted on the research band downlink, and may be of the following kinds: Identification of the satellite. Event messages, including errors detected since the previous visibility interval. Data messages, including an extract of telemetry data acquired since the previous visibility interval. Experiment messages, including result data for the experiments performed.

27 5.2. CAPABILITIES REQUIREMENTS 19 RB-4 Telecommands Telecommands may be received from the ground station during the visibility interval (see 4.4.2). Telecommands shall be transmitted on the amateur band uplink. Telecommands may be executed immediately, as soon as possible after reception, or be programmed to be executed at some future time. Telecommands will allow the ground station to perform at least the following functions: Change the mode of operation (see 5.2.2). Change the configuration parameters of the software. Change the configuration of sensors and actuators. This includes: Disable a sensor that is not operating correctly. Enable a previously disable sensor. Define the validity range of a sensor reading. Change the control parameters of the attitude control algorithm. Start and stop the execution of an experiment, possibly with execution parameters. Telecommands will be checked for validity upon reception. Only valid telecommands will be executed. Validity checks will include the identification of the sending station. RB-5 Time management Mission time, defined as the time elapsed from separation, will be used for stamping all events and data recording, and telemetry messages. RB-6 Fault detection, isolation, and recovery (FDIR) Faults detected during the operation of the system will be recorded as significant events. Subsequent actions may include mode changes or hardware resets of the OBC. A hardware watchdog timer will be used to detect possible failures of the computer system. If the timer expires, a hardware reset will be issued in order to restart the OBC. RB-7 Payload data management The system will record data from experiments and report them to the ground station by means of telemetry messages. The kind of data to be acquired for each experiment is to be further refined. RB-8 Event and data logging The system will record all significant events and report them to the ground station by menas of telemetry messages. The system will record a significant summary of the housekeeping, attitude control, and experiment data, and send them to the ground station by means of telemetry messages.

28 20 CHAPTER 5. SPECIFIC REQUIREMENTS Operating modes The system operating modes are depicted in figure 5.2. The meaning of each mode is defined in the following paragraphs. Ground! Off! Test! Await Launch! Flight! Inactive! Normal_operation! Launch! Latency! Nominal! TC! timer TC! Experiment! separation timer! latency timer! watchdog timer! critical battery! TC! low battery error! TC! lost COMM! Checking! TC! Degraded operation! Initialization! Commissioning! auto timer! Safe! lost COMM! TC received! Beacon! Figure 5.2: Operating modes of the UPMSat-2 on-board software.

29 5.2. CAPABILITIES REQUIREMENTS 21 Ground operating modes Before launch, the OBC may be in the following modes: Off mode (no power is supplied to the OBC). Test mode. Await launch mode. RB-9 Off mode When the satellite is in the off mode the OBC is switched off. RB-10 Test mode While in this mode the OBC is connected to the SVF computer by means of a test link, and the SVF can load and execute software on the OBC. RB-11 Await launch mode When the system is in the await launch mode the OBC is switched off, with no 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. Flight operating modes After launch, the OBC may be in the following modes: Launch mode. Initialization mode. Commissioning mode. Safe mode. Nominal mode. Experiment mode. Latency mode. Beacon mode. RB-12 Launch mode When the system is in launch mode the OBC is switched off. After separation is complete, a hardware separation timer is automatically started. When the timer expires the OBC is powered up, and the initialization mode is entered.

30 22 CHAPTER 5. SPECIFIC REQUIREMENTS RB-13 Initialization mode Initialization mode is entered when the OBC is powered on after separation, or after a latency period following a critical battery condition. Alternatively, it can be entered as a consequence of a hardware reset caused by the expiration of the watchdog timer, or as the result of a telecommand. The functions to be executed in initialization mode are: Load the on-board software and start execution. Configure all the hardware devices in the OBC boards. Configure the radio equipment. Configure all the software subsystems. After the first initialization the system changes to commissioning mode. On subsequent initializations, safe mode is entered. RB-14 Commissioning mode In commissioning mode all the satellite subsystems are checked and commissioned as needed. This mode is entered after the first initialization of the system, or by a telecommand. When the commissioning is complete, the system changes to safe mode. A maximum commissioning time will be defined, after which the system changes to safe mode even if commissioning is not complete. Any error detected during commissioning must be reported as a significant event. RB-15 Safe mode When the system is in safe mode, only the minimal functions that are required for the operation of the satellite with a low power consumption are executed, in order to enable batteries to be charged. Safe mode is entered when a low battery warning signal is received, or when an error is detected in nominal or experiment mode. Other situations that make the system switch to safe mode are the end of initialization or commissioning, or the reception of a telecommand requesting such change. The functions that are executed in safe mode are a subset of the nominal mode functions, including at least the following capabilities: Housekeeping measurements, possibly at a reduced rate. Attitude control, possibly with a reduced accuracy. Telemetry messages with current state and event log (no backlog data). Telecommand reception. No experiments are performed in safe mode.

31 5.2. CAPABILITIES REQUIREMENTS 23 RB-16 Nominal mode When the system is nominal mode, all the satellite functions execute normally. This mode is normally entered upon reception of a telecommand or after the end of an experiment. No experiments are executed in nominal mode. Performing an experiment requires a telecommand requiring a change to experiment mode. The system leaves this mode when one of the following conditions occur: Telecommand requiring a mode change to another mode. Low battery warning signal causing a change to safe mode. Critical battery signal causing a change to latency mode. System error causing a change to safe mode. Communication loss, causing a change to beacon mode. Watchdog timer signal. A hardware reset signal is sent to the OBC, which restarts in initialization mode. RB-17 Experiment mode When the system is in experiment mode, one of the experiments is performed. This mode is entere when requested by a telecommand. A programmed telecommand can be used to start an experiment when there is no visibility from the ground station. The functions that are executed in this mode are: 1. MTS: measure temperature in component under test. 2. SCT: collect solar cell data. 3. MGM: collect magnetometer data. 4. MRAD: test a range of memory cell and store the results, marking the cells that are damaged. 5. SMA: Report correct deployment of boom. 6. RW: use the reaction wheel as an actuator for attitude control. 7. SS6: use the solar cells as attitude sensors. 8. TMC: collect thermal data. 9. BOOM: Report correct deployment of boom. 10. MAC: use alternative attitude control algorithm. 11. SPS: no functions to be executed. The separation system is tested by the fact that the separation has been completed.

32 24 CHAPTER 5. SPECIFIC REQUIREMENTS The system leaves the experiment mode when the experiment is completed, thus returning to nominal mode. An experiment can be terminated by a telecommand, or when a maximum time allowed to it has ended. Other termination conditions are the detection of an error or a low battery signal, which make the system change to safe mode, or a loss of communication causing a change to beacon mode. RB-18 Latency mode When the system is in latency mode the OBC is switched off in order to enable batteries to be charged. This mode is entered when a critical battery warning signal is received, after which the power board automatically disconnects the power supply to the computer. The system stays in this mode for a fixed time interval. A hardware latency timer is used to signal the end of this time interval, after which the power supply is resumed and the computer is switched on. The software then starts in initialization mode. RB-19 Beacon mode The beacon mode is entered when a loss of ground communications is detected by software. When the system is in this mode, it transmits a periodic telemetry message (see 3) until a response is received from the ground station. The system then changes to safe mode. 5.3 System interface requirements The external interfaces of the software system are defined in the interface requirements document (IRD). 5.4 Adaptation and missionization requirements N/A 5.5 Computer resource requirements Computer hardware resource requirements RB-20 On-board computer (OBC) The flight software will run on a single on-board computer with the following hardware resources: LEON3 processor with FPU at 266 MHz minimum clock frequency. 4 MB SRAM 1 MB EEPROM 64 analog input channels.

33 5.5. COMPUTER RESOURCE REQUIREMENTS digital I/O ports. 4 RS-422 serial interface ports. 2 RS-232 serial interface ports. 2 I2C interface ports. 3 SPI interface ports. RB-21 Hardware clocks and timers The following hardware clocks and timers will be provided: Separation timer. This timer is armed at separation from launcher. When it expires, the OBC is powered on and the initialization mode is entered. Latency timer. This timer is started when the latency mode is entered, after the occurrence of a critical battery warning signal. When it expires, the OBC is powered on and the initialization mode is entered. Watchdog timer. This timer will be automatically started by the hardware when the OBC is powered on. The counter value will be reloaded periodically by software. If the timer expires, a hardware reset signal will be issued to the OBC in order to restart its operation. Mission clock. It shall keep track of the time elapsed since separation Computer hardware resource utilization requirements RB-22 Processor utilization The utilization factor of the processor will be kept below 70 %. RB-23 Storage utilization The utilization of RAM storage will be kept below 80 % of its capacity Computer software resource requirements RB-24 Software platform The software will run on the GNATforLEON3 runtime system and the ORK+ kernel. The GNATforLEON GPL 2011 compilation chain will be used to generate the executable software image.

34 26 CHAPTER 5. SPECIFIC REQUIREMENTS 5.6 Security requirements RB-25 Identification of the ground station Telecommands will carry some kind of digital identification in order to ensure that they have been issued by a valid ground station. 5.7 Safety requirements RB-26 Criticality level The on-board computer subsystem, including the software system, is classified as criticality level B (mission critical), as per ECSS-Q-ST-80C [AD2]. The ground station software system is classified as criticality level C. 5.8 Reliability and availability requirements RB-27 Reliability The software system shall be designed so as to tolerate hardware and software faults as long as the underlying hardware may support reconfiguration after faults have been detected. RB-28 Availability The software system shall operate as required in this document for as long as the OBC hardware is operating properly. 5.9 Quality requirements RB-29 Reusability The software will be designed using a modular approach, and low-level details will be encapsulated so as to enable reuse in similar satellite systems Design requirements and constraints RB-30 Software standards The following software standards will be used: ECCS-E-ST-40C Space Engineering Software [AD1]. ECSS-Q-ST-80C Space Product Assurance Software Product Assurance [AD2] ISO/IEC 8652:2012 Information Technology Programming Languages Ada [D4].

35 5.11. SOFTWARE OPERATIONS REQUIREMENTS 27 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]. RB-31 Programming languages The Ada programming language [D4] will be used for all software units, unless otherwise required. A safe subset of the language will be used. The subset will be defined based on the ISO/IEC TR and TR documents. The attitude control algorithm and other functional components may be coded in C as required by automatic code generation tools. RB-32 Ravenscar computational model Tasking will be restricted as defined in the Ada Ravenscar profile [D4, ap. D] 5.11 Software operations requirements RB-33 Stand-alone operation The software will operate stand-alone on the satellite platform. The executable image will be stored in non-volatile memory and copied to RAM on initialization Software maintenance requirements RB-34 No in-flight maintenance No in-flight reprogramming or any other kind of in-flight maintenance is required, aside from modifications of software parameters by telecommand System and software observability requirements RB-35 System state logging The event and data logging functionality will include all mode changes, errors detected, and the current operating mode, in telemetry messages.

36 28 CHAPTER 5. SPECIFIC REQUIREMENTS

37 Chapter 6 Verification, validation and system integration 6.1 Verification and validation process requirements RB-36 Verification and validation processes Verification and validation activities shall be planned and executed as per ECCS-E-ST- 40C [AD1]. Separate validation and verification plans will be set up for on-board software and ground segment software On-board software RB-37 Testing environment On-board software shall be tested on a Software Validation Facility (SVF) including the following components: An engineering model of the OBC. Validation tests will be executed on this model before using the actual OBC. The flight version of the OBC will be required later in the validation process in order to execute acceptance tests. Electronic ground support equipment (EGSE), as introduced in section The EGSE will be used as described in 6.2 below. The EGSE will include a model of the satellite dynamics that will be used to test the ADCS software, and a model of the radio equipment that will be used to test the TTC software. Host computer for controlling the execution of tests and analysing the results. 29

38 30 CHAPTER 6. VERIFICATION, VALIDATION AND SYSTEM INTEGRATION Ground segment software RB-38 Testing environment for ground segment software The ground segment software will be tested using software-in-the-loop simulator of the spacecraft for as long as possible. Real spacecraft hardware will be used for the final test phases. 6.2 Validation approach RB-39 Validation methods Testing will be used to validate the system requirements whenever feasible. Otherwise inspection or review by a validation team may be acceptable. Regression testing will be exercised after any software modifications. RB-40 On-board software testing configurations The following configurations of the SVF will be used for validation at different thest phases: Unit and integration testing: physical processor or processor emulator, as well as device and spacecraft dynamic simulators if needed (software-in-the-loop). Software validation testing: computer board with physical processor and device simulators (processor-in-the-loop). Physical devices will be used for validation of real-time and hardware interface requirements. The spacecraft dynamics will be simulated. Software qualification testing: engineering model of OBC and physical devices (hardware-in-the-loop). The spacecraft dynamics may be simulated. Software acceptance and system testing: real hardware, with simulated environment approaching real operating conditions (hardware-in-the-loop). In-flight acceptance: real spacecraft with real acceptance conditions RB-41 Ground segment software testing configurations A simulated spacecraft environment will be used for unit and integration testing, software validation, and software qualification. The real spacecraft and communications link will be used for acceptance and system testing.

39 6.3. VALIDATION REQUIREMENTS Validation requirements RB-42 Applicable validation methods Appendix A contains a matrix with the validation methods to be used for each of the requirements defined in section Verification requirements RB-43 Verification support All documents related to the development of on-board software will be available in a system database that can be accessed by all the members of the project. A shared data repository supporting version control is an acceptable implementation of such a database.

40 32 CHAPTER 6. VERIFICATION, VALIDATION AND SYSTEM INTEGRATION

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

42 34 APPENDIX A. REQUIREMENTS VALIDATION MATRIX Requirement Validation method RB-33 Stand-alone operation Review RB-34 No in-flight maintenance Review RB-35 System state logging Testing RB-36 Verification and validation processes Review RB-37 Testing environment Review RB-38 Testing environment for ground segment software Review RB-39 Validation methods Review RB-40 On-board software testing configurations Review RB-41 Ground segment software testing configurations Review RB-42 Applicable validation methods Review RB-43 Verification support Review