Software Design

TestOverview

Description

As introduced in the previous sections, the On-board Computer (OBC) is responsible for governing the entire spacecraft. Since only one microcontroller is used to control the various subsystems and ObjectivesGPIOs,

Descriptionit is crucial to ensure efficient and motivationrobust performance of the test:PocketQube.

What

The primary purpose of the OBC is to manage the housekeeping of the overall satellite, which includes timely data processing and storage while maintaining low power consumption.

In this context, the Flight Software (FSW) running on the OBC must be carefully designed to meet the timing requirements associated with the diverse tasks the satellite is expected to perform. A common technique used in embedded systems to address these timing constraints is the objectiveimplementation of Real-Time Operating Systems (RTOS). For the PocketQube, FreeRTOS has been selected as the open-source RTOS to manage the on-board FSW.

For a better understanding of this test?section, it is recommended to read and comprehend the "A Hands-On Tutorial Guide" provided by FreeRTOS beforehand, especially the sections on Task Management, Memory Management, Task Notifications, Event Groups, Queues, and Software Timers.

OBSW Architecture

The OBSW Architercure is designed with the purpose of performing the housekeeping of the overall satellite. In caseorder to meet the testtime requirements linked to the varied tasks that the satellite is performedexpected to perform, a Real time operating system (RTOS) is implemented. This RTOS allows task scheduling, crucial in Environmentalour Conditionssystem with only one core, as well as inter-task communication and other functionalities.

Considering the time and human limitations, as the Lektron team is comprised by students, the OBSW makes use of the Hardware Abstraction Layer provided by STM for their microcontrollers. This Hardware Abstraction Layer (VibrationsHAL) simplifies the control of the Microcontroller Unit (MCU) interfaces greatly, reducing the amount of lower-level coding requiered by the programming user. Do note that to make full use of such libraries parts of it have been modified slightly for them to be FreeRTOS compatible.

On the other hand drivers provided by Semtech are used to control the SX1262 Transciver. With the use of the aforementioned libraries, user functions and FreeRTOS tasks are designed and implemented in order to perform the specific mission requirements and tasks such as power management, telecommand processing and command, on-board data handling, payload data acquisition, attitude and orbit determination and control, between others.

All user code is embedded into FreeRTOS tasks. Such code will make use of HAL and other libraries as well as the basic functions and methods of the C language in order. A simple diagram of this architecture is provided next:

Figure 1: Software Architecture Block Diagram

Multitask environment

The FSW operates in a naturally multi-tasking environment, where each task serves a specific purpose and has a designated level of priority. The definition of the various tasks is based on the different sub-modules of the satellite, along with supplementary functions that need to be provided.

In this way, the FSW is structured around several key tasks, including OBC, OBDH, COMMS, AOCS, EPS, PAYLOAD, and FSS. Additionally, there will be a task dedicated to time management, as well as an existing daemon task.

The OBC Task serves as the central scheduler, coordinating the operation of all other tasks. It is responsible for managing transitions between different operational modes, task scheduling, power control, and essential satellite checkups.

The OBDH Task oversees the management of internal data within the spacecraft. Its primary focus includes housekeeping data, scientific data, and configurations, as well as managing access to flash memory.

The COMMS Task is responsible for managing the transmission and reception of data packets according to the LoRa protocol.

The AOCS Task handles satellite orientation and stabilization, along with polling data from the magnetometer, gyroscope, and photodiode sensors. It operates in four primary modes:

1. IDLE Mode: This serves as the default state, where the AOCS remains inactive and does not perform any operations.
2. Safe Mode: Employed to reset the sensors and algorithms in the event of an issue, ensuring system integrity.
3. Nadir Pointing: Essential for conducting payload measurements, allowing the satellite to accurately gather data.
4. Detumbling Mode: Activated to stabilize the satellite when it experiences undesired angular velocities.

The EPS Task is responsible for two primary functions:

1. Monitoring the voltage, current, capacity, and temperature of the power board.
2. Activating the battery heater if the temperature falls below a specified threshold, ensuring optimal operating conditions for the battery.

The PAYLOAD Task manages payload data acquisition.

The FSS Task is responsible for implementing the Federated Satellite System protocols.

The sTIM Task works alongside the daemon task to implement software timers for error handling purposes. To enhance the robustness of the flight software, timers will be employed to track task execution. Specifically, there will be one software timer for each FreeRTOS task. The software timers feature both active and suspended periods. If a task operation takes longer than its active period, that task will be suspended by the software timer during the suspended period. This ensures that no single task can consume processing time indefinitely, thereby preventing task starvation.

Satellite Operational Modes

The satellite can operate in five distinct modes: Init, Nominal, Contingency, Sunsafe, and Survival. These modes reflect the satellite’s operational conditions in relation to its battery power levels. Each mode establishes a set of rules that control which actions the satellite can perform, ensuring that power consumption is managed effectively.

Init: This mode is directly associated with the LEOP. The LEOP phase is the most critical, as it begins when the satellite is deployed and concludes when the COMMS antenna is deployed and contact with the ground segment is established. For the PoCat mission, it includes the following steps in this order:

1. Standby: To comply with the requirements, after injection in orbit, the spacecraft must wait a minimum of 30 minutes before beginning operations or Thermaldeploying Vacuum),appendages, specifically the COMMS and payload antenna. At the same time, no radio emissions are permitted after the spacecraft has been integrated into the PocketQube deployer, and this restriction remains in effect for 45 minutes following deployment. Therefore, no beacon transmissions are allowed. This precaution is necessary to prevent interference with other satellites being deployed or with other systems on the rocket. To meet these requirements, the satellite will wait 45 minutes before commencing operations and communications.

2. Deployment of the LoRa Antenna: As mentioned, it is necessary to definedeploy the loadsCOMMS antenna to begin transmitting beacons, which will facilitate the first contact with the GS.

3. First Contact with the Ground Station: The satellite will remain in this state until it receives confirmation from the GS that everything is functioning correctly, at which point nominal operations can begin.

Nominal: If all the performance criteria and profiles.actions of the init phase are successfully completed, the satellite enters nominal mode. This mode serves as the default operating state in the best-case scenario, and the satellite remains in this mode as long as the batteries are above a certain threshold value. While in nominal mode, payload-related operations can be conducted, including the mission experiments and the FSS.

Requirements

Contingency: Verification

The satellite enters this mode when the batteries fall below a certain value. In this mode, some functionalities of the flight software are disabled, including the experiments conducted by the payload and the FSS. Additionally, the AOCS subsystems stop performing nadir pointing to reduce power consumption.

ProjectSunsafe: requirementsThis mode is associated with a critical condition of the satellite and is activated when the batteries drop below an even lower threshold. More restrictions are applied in this mode to further conserve energy. The EPS and AOCS subsystems cease all activities, such as heating the batteries in the case of the EPS or dumping and detumbling in the case of the AOCS. These subsystems enter a passive state, during which they only collect HK information for telemetry messages.

Survival: This final state is the most critical, occurring when the satellite lacks sufficient energy to perform any vital actions. It may also arise if a significant error occurs in the code, making it safer to remain in this state until operators determine the best course of action. In this state, all subsystems remain active but are only polling information from the sensors. At the same time, transmissions are ceased, and no beacons are transmitted to prolong battery life; the COMMS subsystem is only in reception mode.

The figure below illustrates the transitions between the states. From the Init state, which is the first state the satellite enters after being released by the deployer or after a reboot, the satellite will transition to the Nominal state following the first contact with the ground segment. Once the satellite exits this state, it can only re-enter if a reboot event occurs.

All other states can transition up or down to the adjacent state. Transitioning to a state with more restrictions can occur automatically if the satellite does not have enough energy to remain in the current state, or it can be triggered by operators through the reception of a telecommand. Conversely, to transition to a less restrictive state, two conditions must be met: the battery level must be appropriate, and the satellite must receive a telecommand requesting the change of state.

To improve performance and reduce power consumption based on the current state of the satellite, high-power tasks are restricted. Additionally, other mechanisms are employed to optimize power usage, such as adjusting the CPU frequency of the microcontroller.

The table shown below, presents the various frequencies at which the OBC operates in each of the different operational modes. It is important to note that shallhigher befrequencies verifiedprovide withgreater thiscomputational test.power but also result in increased energy consumption. Conversely, lower frequencies reduce power consumption but limit computational speed.

RequirementOperational IDMode	DescriptionFrequency
Init	2 MHz

Nominal

Test80 Set-Up

MHz

Description of the required components to perform the test (be accurate)

• Subsystem and its components
• Tools and components
• Desktop objects (pencil, watch, etc.)
• Ground Segment equipment
• Clothe equipment

Table with the required material:

Contingency	26 MHz
Sunsafe	8 MHz
Survival	2 MHz

StepsTable to1: prepareOperational Modes and their frequencies

In addition, the setup:

actions

Diagram or picture representing the setup:

Pass/Fail Criteria

Description of which metric is used to perform the test and when it is considered that the test passed or not. If different metrics are used, it is important to define when the test passed or not (e.g. when all the metrics arepermitted in the passdifferent criteria,modes or when only one of them).are:

Test Plan

This section includes the test sequence necesary to do the test. The test sequence must include all the steps, from the set-up up to the conclusion of the test.

\[Y/N\]**

Action	Init	Nominal	Contingency	Sunsafe	Survival
**StepCOMMS ID**Tx beacon	**Description**Yes	**Pass/Fail Criteria**Yes	**Actual **Yes	**PassedYes	No
EPS heating	Yes	Yes	Yes	Yes	No
AOCS tumbling	Yes	Yes	Yes	No	No
AOCS Nadir Pointing	No	Yes	No	No	No
Payload experiment	No	Yes	No	No	No
FSS services	No	Yes	No	No	No

Table 2: Operational modes permitted actions

TestScheduling ResultsPolicy and Task Priorities

DescriptionThe scheduling policy is designed to ensure that tasks are executed in a manner that meets the timing and responsiveness requirements of the TestOBSW. resultsIn with supporting data.

• Test name, test execution dates,FreeRTOS, the testkernel facilityemploys useda preemptive scheduling algorithm, which allows higher-priority tasks to interrupt lower-priority tasks. This approach ensures that critical tasks receive immediate attention, thereby enhancing the system's overall responsiveness.

  Task priorities in FreeRTOS are assigned a value ranging from 0 (lowest priority) to a maximum value determined by the configuration settings. Each task is assigned a specific priority level, and the operators

FreeRTOS
• Testscheduler Logbooks
uses
• “As-run”these procedurespriorities (to determine the order in which tasks are executed. When a higher-priority task becomes ready to run, it preempts the currently running lower-priority task, allowing the system to respond quickly to time-sensitive operations.

  The priority of each task is:

  Task	Priority
  sTIM	9
  Daemon	8
  OBDH	7
  PAYLOAD	6
  FSS	5
  AOCS	4
  EPS	3
  OBC	2
  COMMS	1

  Table 3: Task priorities

  Timekeeping mechanism

  FreeRTOS employs a robust timekeeping mechanism that is essential for managing task scheduling and timing operations within the RTOS. At its core, FreeRTOS uses a tick timer, which generates periodic interrupts at a defined frequency.

  The tick timer is responsible for incrementing a global tick count, which serves as the basis for time management in the OBSW. Each tick represents a fixed time interval, allowing the system to keep track of elapsed time and manage task delays, timeouts, and scheduling. Tasks can be provideddelayed infor annex)

a
• Testspecified facilitynumber resultsof (ifticks, applicable)
and
• Photographsthe relevantsystem can also implement timeouts for various operations, ensuring that tasks do not block indefinitely.

  In addition to the set-up(s)basic tick count, FreeRTOS allows to query the current tick count, convert ticks to milliseconds, and inspection(s)manage (task timing effectively. To ensure satellite synchronization with the ground segment, the tick timer is utilized as a clock. However, this timer may alsoexperience bedelays addedor inaccuracies, particularly in the Conclusionsevent to clarifyof a close-outreboot. judgement,To e.g.address forthis, anthe inspection)

system
• Analysiscan be synchronized again through the reception of the testtelecommand dataUPDATE_TIME, andwhich relevantallows assessment.
for
• Synthesisthe correction of the overalltick testcount resultsand perensures verificationaccurate (e.g. Vibration, Inspection 1, Inspection 2, etc.).

timekeeping.

AnomaliesData extraction and hardware driving

ListData extraction from hardware mechanisms differ between the different subsystems. All I2C hardware data polling is blocking, meaning no further execution of deviationsthe code will be done until the operation is finished or certain time has passed. The same philosophy is applied to DAC/ADC intefaces.

Payload data extraction can make use of Direct Memory Access (DMA), in circular mode, as the amount of information to receive is of the order of kilobytes, yet blocking polling is also possible. Futher software development and testing will determine the final approach. The COMMS subsystem, interfaced through SPI, also uses blocking polls of data.

Figure 2: Blocking data polling diagram

Hardware driving is facilitated by the provided STM Hardware Abstraction Layer as well as Semtech provided drivers in case of the COMMS subsystem. Each interface requieres data to be formatted accordingly to the Testcomponents Specificationspecifications.

and

Data Procedureoverwriting

and

The non-conformancesflash witnessedmemory duringis divided into 2 kB pages. Once information is written on a page it cannot be overwritten unless the testpage campaign,is includingpreviously acompletely brieferased. description,This the close-out status and referenceleads to the relevantuse reports.of cyclical overwriting of data as pages are full. For example, if certain information has two pages dedicated to its storage it will full both pages before deleting the first one and start writing there again.

In cases where the information stored is not to fill a full page of itself, the page containing such and other information is to be copied, erased, and then rewritten with the new values.

ConclusionsSoftware Verification Strategy

At every stage of software development different strategies are employed in order to validate the progress done.The Conclusionsfirst shallsteps includein (wheredevelopment neededand asvalidation annex):

are

characterized
1. Testby results,the includinguse asof a minimum:Nucleo
   STM
   • RequirementL4746RG Development Board. As most subsystems only rely on the MCU and the power line, and this second can be easily emulated, the software corresponding to each of them will first be tried on a system composed by the Nucleo and the hardware to be tested.

     In the first iterations of the process a bare bone approach is employed, not implemeting the software into the FreeRTOS environment until the hardware is validated. Once the software is adapted and implemented into the RTOS, still using the development board, the unit to be verified

   • Subsectionswill consist on the prevoius hardware and the software as a single FreeRTOS task. Do note that some subsystems do requiere of testvalues campaignread from sensors in whichother thatto requirementbe wasverified. verifiedTo (e.g.solve Thermalthis Vacuumissue RFTnumerical 1,approaches Inspectionto 1,their Inspectionvalues 2,are ...)
   taken
   • Close-outso judgementas (complianceto status)keep andtesting rationale,straighforward.
     per

     Once subsectionthe subsystem to be validated is sure to not be a root of problem in of by itself it will be integrated with the actual OBC-COMMS board for further testing. This process may be done with the help of the test

   EGSE
   • Traceability(Electrical toGround usedSupport documentation
   Equipment)
   • Conformance(FlatSAT) or deviationmanually includingconnecting references
   both
   parts,
2. Overall conclusiondepending on the successsystem. During the next phases of the test,validation includingthe clearlyunit statedto test expands until it covers the full system, or as much as must be reasonably tested. This includes the integration of the rest of the subsystems both in hardware and describedin opensoftware issuesto the process. The modular approach of the system facilitates this more complete verification. FlatSAT testing is of vital importance during this phase as it provides a suitable platform for system level software tests.

   The last steps are to verify the software in the environmental conditions that the satellite will find itself in as much as possible. This process involves the whole system and possiblesimulation remediatingof actions.

said
3. Testconditions Readinessusing Reviewdifferent minutesfacilities and Posttools.
   Test

   As Reviewa minutes

final

note, to support communication with the external environment for control and debugging purposes, the satellite is equipped with two communication mechanisms. The first is an umbilical cable, which facilitates the transmission of output logs generated by the satellite and allows for command input via a wired connection. The second communication method utilizes RF (Radio Frequency) through the communications antenna, enabling command transmission in a manner consistent with real operational scenarios.