1 Introduction

One of the most common trends in the space sector is the evolution of CubeSats, micro satellites measuring just a few tens of centimeters in size [1]. Besides the advantage given by the small dimensions and weight that guarantee a reduction of power consumption and costs, a CubeSat is also the perfect chance to sharpen the students’ abilities and knowledge of the space industry [2]. For that purpose, accurate and comprehensive research of a CubeSat mission can be done by students, with a special focus on the requirements definition, feasibility study and environmental analysis, starting from mission objectives. This kind of activity gives the opportunity to face and address the issues and challenges of a space mission design [3]. In the present work an alternative design of the 2U CubeSat mission of the students’ team Alba CubeSat of the University of Padova [4], currently participating in ESA “Fly Your Satellite! Design booster” program, is presented.

Students aimed to define the requirements based on which commercial off-the-shelf (COTS) components have been selected for a preliminary design while maintaining the original design of the four payloads. In addition, the student team identified and evaluated the risks and success criteria and conducted a wide variety of simulations to perform a complete feasibility analysis.

The paper is organized as follows. In the next section, an overview of the mission is presented and the main system engineering tasks are described. Section 3 describes the subsystem and components selection, while Sect. 4 introduced the preliminary analysis of the mission.

2 Mission Overview

Alba CubeSat is a project that aims to design, build, test, launch, and operate the first student-built 2U CubeSat of the University of Padova, which features four distinct payloads that aim to accomplish four independent objectives [4], which are:

  1. 1.

    in-situ space debris environment measurement;

  2. 2.

    satellite on-board micro-vibrations assessment;

  3. 3.

    precise orbit determination through laser ranging;

  4. 4.

    Test of laser carrier modulation through active retroreflectors

The first and principal mission objective is strictly related to the problem of space debris.

Nowadays, it has become a major issue and, according to the so-called “Kessler Syndrome”, it was theorized that the increase of the space debris density can lead to a self-sustaining chain reaction of collision. In this way, some orbits may become impractical for several years [5]. Objects bigger than some centimeters can be tracked from ground [6, 7] and therefore it is possible to predict an impact and perform avoidance maneuvers against catastrophic fragmentations [8, 9]. Nevertheless, even smaller fragments, down to a few millimeters or less in size, can still pose a risk to operational satellites and spacecraft. In fact, they can cause shock phenomena, mechanical damage, plasma effects and disturbance of spacecraft attitude control [10]. Therefore, it becomes mandatory to develop in-situ sensors capable of collecting data about the lower range of the space debris population and, as a consequence, increase the reliability of numerical analysis.

2.1 Requirements

Starting from the objectives stated in the previous list, the mission and system requirements were defined according to the process shown in Fig. 1.

Fig. 1
figure 1

Logical scheme followed to identify requirements

Mission requirements state what AlbaSat shall do to reach the objectives. System requirements specify how the mission requirements shall be implemented through:

  • functional requirements: define the requested function and/or operations that shall be performed to reach the objectives;

  • performance requirements: quantify the performance levels that shall be met by the functions defined by functional requirements;

  • design requirements: define the constraints that shall be satisfied by the system design. Often, they are not directly related to the objectives, but they depend on boundary conditions such as launch loads and the interfaces with the launch vehicle, the space environment, regulation and safety restrictions, schedule, and cost constraints;

  • operational requirements: define the procedures to be satisfied to use the system in a safe and reliable mode.

The identification of requirements is a milestone that is the basis of any design activity. To define the requirements, assumptions were made, such as the launch vehicle that will carry the CubeSat. The altitude, type of operative orbit and the launch date were constraints provided considering a higher probability of launch availability. The study of the micro-vibration environment and active retroreflectors is considered beyond the scope of this work. The relative payloads were treated as “black boxes” whose interfaces and resources budget were known [4].

Starting from the previously mentioned mission requirements, functional requirements were specified for each one to provide more detailed explanations of the functions the CubeSat should perform. Subsequently, performance requirements were introduced to quantify aspects that had previously been qualitative. Concurrently, design requirements were specified to articulate constraints, and operational requirements were established to delineate the procedures that the satellite must be capable of executing.

For every requirement identified, one or more of these verification methods were assigned: analysis, test, review of design and inspection. Throughout the analysis, each requirement was subjected to review, update and tailoring as the mission development progressed and different needs or constraints emerged.

2.2 Risk Management Plan

Every project has risks that might affect its success and thus shall be managed. In a study done about the CubeSat mission status from 1994 to 2017 it is shown that CubeSat missions complete the full mission or partial mission objectives in less than 50% cases [11]. Reasons for failure are due to several reasons, including the students’ levels of experience.

The team compiled a risk register, in which the level of risk was evaluated, and mitigation actions were proposed. To organize the risk management plan, the following steps were defined:

  1. a)

    Identify risks, classify them in categories;

  2. b)

    Evaluate the risk level for each identified risk;

  3. c)

    Determine mitigation techniques;

  4. d)

    Make a mitigation plan accordingly to the risk level and mitigation techniques considered, in order to lower the risk level.

For this analysis, three phases of the project were considered: pre-launch, during launch, and after launch. Risks in each phase were categorized in cost, schedule, technical/implementation, mission (level of operative performance), safety, personnel, and environment risk. At each identified risk, it was assigned a level of risk, defined as the product of its probability of occurrence and the severity of its consequences, as shown in Fig. 2. The chromatic scale was used to highlight the level of a risk: from green (very low) to red (high or very high). The level defined whether a risk was acceptable and whether mitigation measures should be implemented.

Fig. 2
figure 2

Chromatic scale for level of risk (P x S)

The team considered the following handling approaches [12]:

  • Accept—accept the risk and record the reasons and the logical basis;

  • Watch—watch, track, and monitor the behavior of risk over time, immediate action is not required at this time;

  • Research—collect more information and perform analysis to refine the levels of likelihood and the consequences, and sometimes to reduce risk probability when it is required;

  • Mitigate—mitigate the criticality level of risk by eliminating or reducing the likelihood or the consequences using the available methods to control it;

  • Transfer—transfer the risk to be assessed by another party;

  • Avoid—adjust the requirements to avoid the risk.

As a general rule, the team applied the handling approaches according to the level of risk as follows:

  • Very low risk level: accept;

  • Low risk level: accept and watch;

  • Medium risk level: mitigate, research and watch;

  • High risk level: avoid, mitigate, research and/or transfer;

  • Very high-risk level: avoid, mitigate, research and/or transfer.

2.3 Success Criteria

Since AlbaSat is a student-designed CubeSat project, the majority (55%) of the success criteria were linked to an educational purpose, like the student experience acquisition about Manufacturing, Assembly, Integration and Test (MAIT) procedures of the payloads and the CubeSat itself following the Fly Your Satellite! Design Booster guidelines and the production of official technical documentation for ESA. 25% of the success criteria concerned the successful launch and operation of the satellite. The remaining 20% of the success criteria was about the competition of the mission objectives. The graphical representation of the success criteria subdivision can be seen in Fig. 3.

Fig. 3
figure 3

Success criteria

3 Subsystems and Components Selection

Component selection is based on the necessity to meet specific requirements and ensure system-level compatibility. After conducting preliminary analyses, detailed below in Sect. 4, the team made the following design choices. The CAD model in Fig. 4 depicts the CubeSat internal components, with the solar panels removed for clarity. The x-axis is oriented along the direction of motion, the z-axis points at Nadir, and the y-axis is perpendicular to the orbital plane.

Fig. 4
figure 4

CubeSat internal components; the solar panels have been removed from this view

Body-mounted solar panels cover all the available surfaces: three lateral faces (− x, + y, −y) and the top face (- z) to handle the different values of Local Time of the Ascending Node (LTAN), while the impact sensor is housed on the + x lateral face (along the motion direction). The bottom is dedicated to the optical surfaces of the corner cube reflectors and the active retroreflectors. Apart from the impact sensor, micro-vibration sensor and active retroreflectors, which are developed in-house, the remaining components are all COTS items.

3.1 Payloads

The four payloads of the satellite are: an Impact Sensor (IS), a laser ranging payload based on Corner Cube Retroreflectors (CCR), a Micro-Vibration Sensor (MVS) and an active retroreflector (QPL).

IS is a CubeSat—size resistive detector for sub-millimeter space debris, based on the technology demonstrator DRAGONS [10, 13]. The sensor is composed of a sensitive element realized using the technology of the flexible PCB fixed on a PTFE support plate and mounted on the face of the satellite pointing towards the velocity direction. The sensitive element consists of a series of thin parallel conductive lines on a Kapton substrate connected to a control board. An impact is detected when one or multiple lines are severed [14].

The laser ranging technique is performed by a series of CCRs disposed on the satellite: 4 on the face pointing to nadir and 2 on the faces aligned with the out-of-orbit-plane direction. CCRs are completely passive devices, and they reflect a laser beam coming from a ground station, allowing for time-of-flight measurements to determine the satellite position [15].

MVS consists of a MEMS triaxial accelerometer integrated in a chip, capable of transmitting digital data to the on-board computer. The main purpose of this payload is to collect data about the vibrations generated on the satellite [15].

QPL is based on an active retroreflector with the aim to present an innovative method to test optical receivers intended for quantum communication setups [15].

3.2 Subsystems

The primary structure provided by NPC Spacemind is made of aluminum alloy (Al 6061), selected for its lightweight properties. It is also qualified for use by both JAXA and ESA, meeting specific requirements of the Alba CubeSat mission.

The design drivers for the Attitude Determination and Control System (ADCS) are derived from the payload requirements, including tri-axis stabilization, and pointing accuracy of ± 20°. Considering these requirements and the integration with other subsystems, the CubeADCS model from CUBESPACE was chosen. The on-board sensors include eight photodiode Sun presence sensors, three MEMS rate sensors, a deployable triaxial magnetometer, and a redundant magnetometer in case of deployment system malfunctions. The Y-momentum configuration, equipped with three magnetorquers and a reaction wheel (RW), allows for magnetic detumbling and subsequent stable spin motion around the Y-body axis, aligning with the normal of the orbital plane. The RW absorbs this rotation to achieve the desired orientation.

In support of the laser ranging system, a less accurate but reliable GPS system has been added. This system provides an initial estimation of orbital position and serves as a backup in case of laser ranging system failure.

The Electrical Power Subsystem (EPS) manages power generation and distribution. It features three input channels with independent maximum power tracking points and two power buses (3.3 V at 5 A and 5 V at 4 A). The EPS interfaces with the BP4 (8 V) battery pack with a 43 Wh capacity, ensuring power availability even when the solar panels cannot generate sufficient energy.

For the On-Board Computer (OBC), the NanoMind A3200 has been chosen. It offers 128 MB of on-board storage and supports various data interfaces, including I2C, UART, and CAN-Bus. Onboard sensors, such as temperature, magnetometer, and gyroscope, allow data collection and control. The software includes Free RTOS, CSP network protocol, and PUS service.

The communication system uses the NanoCom AX100, supporting GMSK/GFSK modulation and operating in the 430–440 MHz frequency range with a 25 kHz bandwidth. It maintains a low-power consumption of 3.3 W with an output power of 1 W. The OBC, TT&C boards and the GPS kit are mounted on NanoDock DMC-3.

Thermal management relies on passive conduction and radiation, except for the battery pack, which is equipped with a heater to maintain the optimal operational temperature range.

4 Preliminary Analyses

An analysis of the possible target orbits has been performed considering the European Code of Conduct for space debris mitigation [16] and the orbits commonly reached by other missions.

A 500 km Sun-Synchronous Orbit (SSO) with an eccentricity of 0.001 has been selected as the baseline for the mission to maximize launch availability, having previously performed an analysis of the most accessed orbits. For the nominal mission duration, 1 year has been chosen. To be compatible with as many launches as possible, the LTAN has not been fixed. Therefore, the two extreme cases have been considered in the analyses, namely a Worst Hot Case (WHC) scenario with an LTAN of 6AM (Dawn/Dusk), and a Worst Cold Case (WCC) scenario with an LTAN of 12AM (Noon/Midnight). These two orbits have been chosen as worst-case conditions because they represent, respectively, the orbits with the shortest and the longest eclipse durations. The launch date has been assumed to be 30/03/2027 and the following Table 1 resumes orbital parameters of each orbit.

Table 1 Orbital parameters

4.1 Debris Mitigation Analysis

With the chosen design (shown in the following section), mass budget and atmospheric reentry comply with ESA guidelines [16, 17]. The compliance with the request to atmospheric reentry within 25 years [17] is verified with dedicated numerical analysis performed considering the two orbital cases (Noon–Midnight and Dawn–Dusk) in the nominal case (with the satellite nadir pointing having the IS pointing towards velocity) in which the satellite maintains a cross section area of 0.02 m2 and in the worst case with the minimum cross Sect. (0.01 m2). The minimum cross section of 0.01 m2 is considered the worst-case since it is the minimum drag scenario and, therefore, it corresponds to the maximum orbital decay time. The results shown in Fig. 5 demonstrate that in the worst-case scenario the satellite re-enters within less than 12 years which satisfies the ESA guidelines.

Fig. 5
figure 5

The graph shows the atmospheric reentry for the different attitude and orbits considered: the nominal case with a cross section area of 0.02 m2 in Noon/Midnight orbit (light blue) and in Dawn/Dusk orbit (violet), and the worst case (minimum drag case) with a cross section area of 0.01 m2 in Noon/Midnight orbit (orange) and in Dawn/Dusk orbit (red). In every considered case, the decay time is less than 12 years

4.2 Mass Budget

To define the mass budget (see Table 2), margins have been applied according to the ESA document on margin policy [17], adding: 5% mass for COTS components, 20% for custom components, 5% of the total mass with margins to account for cables and fasteners, and 20% margin applied to the whole system. After doing the calculations, it turned out that the total mass in the worst case will be 2.65 kg, which does not exceed the imposed limit for a 2U CubeSat of 2.66 kg [18].

Table 2 Mass budget

4.3 Power Budget

For the power budget production, four operational modes have been defined: Safe mode, Idle mode, Communication mode and Payload mode.

Power consumption was considered with 5% margin for COTS and 20% for new systems. As shown in Table 3, the Communication mode has the highest power consumption. Considering the worst-case power consumption per orbit, which is 6 min in the Communication mode (as explained in the next section) and the remaining 88 min in Payload Mode, the energy consumption totals 5.22 Wh. In the Dawn–Dusk orbit, the mean power production per orbit is 5.1 W, resulting in an energy production of 7.99 Wh per orbit. This allows the EPS to fully recharge the batteries on every orbit. However, in the case of the Noon–Midnight orbit, power production decreases to 2.7 W, with an energy production of 4.23 Wh per orbit. In this scenario, the EPS cannot fully recharge the batteries. To address this issue, reducing the time in Payload Mode has been considered, with a switch to a less power-consuming mode like Idle Mode, enabling the full recharge of the battery pack. A complete simulation of the power generation and consumption during operation have been performed using Matlab, considering a baseline power consumption of 2.1 W plus the peak power consumption associated with transmission activities. The simulations have been performed for both the best and worst-case orbits (Fig. 6 and Fig. 7 respectively). The State Of Charge (SoC) of the on-board batteries shows that: the batteries are not required during sunlit time; the batteries are fully recharged after the completion of one orbital period, even when starting at 95% of SoC (Fig. 8 and Fig. 9).

Table 3 Power consumption by each subsystem with margins
Fig. 6
figure 6

Power generation and consumption profiles during one day for LTAN 6:00 orbit

Fig. 7
figure 7

Power generation and consumption profiles during one day for LTAN 12:00 orbit

Fig. 8
figure 8

Batteries’ state of charge profile during one day for LTAN 6:00 orbit

Fig. 9
figure 9

Batteries’ state of charge profile during one day for LTAN 12:00 orbit

4.4 Link and Data Budget

Regarding communication with the CubeSat, Padova (latitude 45.411°, longitude 11.892°) has been selected as the ground station for sending commands, with the antenna having a cutoff elevation angle set at 10°. The communication link is available on average twice a day for six minutes each, for both orbit cases (Fig. 10). The system will transfer data using radio amateur frequencies (435 MHz), and the daily volume of downloadable data will vary based on the minimum elevation considered and the sampling rate of the micro-vibration sensor (Fig. 11). The data download simulations have been performed by numerical analysis of various orbital revolutions using Matlab. To cover non-nominal scenarios, worst-case simulations with higher cutoff angles have been included in the analyses.

Fig. 10
figure 10

Link availability

Fig. 11
figure 11

Daily data production (dashed lines) and daily downloadable data by cutoff angle

4.5 Thermal Analysis

For the thermal analysis two extreme cases for on-board activities have been considered: the Safe Mode during a Noon-Midnight orbit as the WCC, due to the presence of the maximum eclipse time, and the Communication mode during a Dawn–Dusk orbit as the WHC. These extreme cases were selected to evaluate the thermal behavior of the system under different conditions. Furthermore, it has been assumed that thermal conductivity and specific heat are constant, all materials are isotropic, and the heat power dissipated by the active components is equal to the electrical power consumption. This hypothesis was formulated due to the challenge of accurately calculating the heat dissipated by the component. By assuming that all the required power is converted into heat, it is possible to obtain an overestimation that provides a safety factor for the analysis. The thermal software Systema-Thermica, developed by Airbus, has been specifically used for these analyses.

Using the Systema internal modeler, the CubeSat was modeled as shown in Fig. 12 below. Every PCB was depicted as a singular board, the IS payload was represented by a single copper layer and the ADCS wheel, the battery pack, and the antenna are modeled as empty boxes. Finally, the QPL MRR is represented by a cylinder.

Fig. 12
figure 12

Geometrical thermal model used for thermal analysis of the entire satellite (left) and the view of internal components (right)

The table below (Table 4) collects the materials used for the analysis, consistently with the consulted datasheets and the provided information about payloads.

Table 4 List of materials used in thermal analysis

During the Communication mode, it has been observed that the OBC and TTC subsystems reach a peak temperature of 89 °C. To address this, a thermal strap has been planned between the OBC and TCC plate and one of the shaded solar panels. For the internal component, the WHC has been studied in a Dawn–Dusk orbit during the Communication mode, where the temperature ranges between 39 °C and 45 °C. On the other hand, for the WCC, it has been assumed a Noon–Midnight orbit in Safe mode, and it was found that the CubeSat reaches a minimum temperature of -10 °C, which is problematic as it does not comply with the temperature range for the battery. To resolve this, it was suggested to switch on the battery integrated heater. Regarding the external components, in the WHC, the spacecraft reaches a maximum temperature of 65 °C and a minimum temperature of 25 °C. In the WCC, the external temperature varies from a minimum of -20 °C, during the eclipse time, to a maximum of 50 °C.

Figure 13 shows temperature distributions in the WHC and in the WCC.

Fig. 13
figure 13

Temperatures in the WHC (left) and WCC (right)

The results comply with the required thermal ranges of each component. This is achieved by switching the heater of the battery pack during the WCC and using the thermal strap located between the OBC and TTC subsystems plate and one of the solar panels in the WHC.

4.6 Radiation

Environmental analyses have been performed using the Dosrad module of Systema. The results of the radiation analysis indicate that the maximum dose of radiation accumulated in a year for the external components is approximately 119 krad, while for the internal components it is 5 krad. The radiation analysis results are shown in Fig. 14.

Fig. 14
figure 14

One-year cumulative radiation

The analysis shows that the dose of radiation absorbed by the CubeSat falls well within the expected values for a polar LEO orbit and can be withstood by the selected COTS components.

5 Conclusions

In this study, the feasibility analysis of the AlbaSat mission was executed. System requirements were systematically derived from the mission objectives, guiding the selection of the most suitable COTS components for the satellite, and defining the parameters and the designs for the payloads. The performed analysis encompassed a comprehensive evaluation of critical aspects of space missions, including the simulation of thermal, radiation, debris, and general environmental conditions. In addition, considerations extended to end of life reentry, available power, and data link requirements.

The results obtained through this analysis played a pivotal role in verifying system requirements and resolving trade-off challenges associated with component selection. The results presented in this work demonstrate adherence to specified requirements, effective debris mitigation strategies, and alignment with established FYS! guidelines. Finally, the study culminated in the definition of the preliminary design for the satellite subsystems.