Housekeeping System for Suborbital Vehicles: VIRIATO Mock-Up Vehicle Integration and Testing

Abstract

The work presented in this paper regards the improvement of a housekeeping system for data acquisition of a suborbital vehicle (VIRIATO rocket or launcher). The specifications regarding the vehicle are presented and hardware is chosen accordingly, considering commercial off-the-shelf components. Mechanical and thermal simulations are performed regarding the designed system and a physical prototype is manufactured, assembled and programmed. Functional and field test results resorting to unmanned aerial vehicles, as well as the system’s integration within VIRIATO project’s mock-up vehicle, are presented. These tests demonstrate the viability of this system as an independent data acquisition system, and simulation results show that commercial off-the-shelf components have the capability of surviving expected launch environments.

1. Introduction

This paper presents the continuous improvement, integration and testing of an independent miniaturized housekeeping system for suborbital vehicles, space launchers and rockets. The aim is to provide a system which transmits and stores relevant telemetry data during the vehicle’s launch, with the objective of providing data which can be used as reference for other launches.

The design of the housekeeping system, for instance, structural elements and electronic component placement, is performed resorting to programs such as Siemens NX and Altium. The former program allows for simulations to be executed as well, which are carried out to study the system’s response to launch environments. Commercial off-the-shelf (COTS) components are used, and software development is achieved resorting to a microprocessor’s integrated development environment.

There is a lack of available publications regarding dedicated housekeeping systems for launchers, even though suborbital vehicles have been extensively used in satellite launching missions. The use of COTS components is also a novelty, aiming to provide a system which performs as intended resorting to commercially available components whilst also allowing a quick prototyping phase and implementation and proving, through simulation, that such a system can be integrated as a space launcher’s payload and survive the expected load environments. The housekeeping system also allows for newly developed architectures for guidance and navigation by complementing or even implementing architectures such as the one presented in [1].

This paper is organized as follows: Section 2 provides an overview of the technology used and researched such as hardware with heritage in space applications, followed by the project’s context which inspired the creation of this system and its requirements. Section 3 presents the design of the system, its layout, and component selection. Section 4 introduces the results from the mechanical and thermal simulations, and a discussion is performed accordingly. Section 5 presents the physical prototype such as its parts placement and connector pinouts. It also provides insight in the implemented communication protocol, as well as the steps required for successfully assembling the entire system. Section 6 presents the performed functional and field tests and Section 7 summarizes the results and provides insight regarding future work.

2. Background

ESA’s initiative Light satellites Low-cost Launch service (LLL) aims to define, develop and qualify the required products, processes and management models to provide a standardized and low-cost launch service for satellites below 500 kg.

The housekeeping system emerged as a response to a project named VIRIATO, Portuguese for “Innovative Reusable Vehicle for Research and Leverage of Orbital Technology”; its initial conception can be found in [2]. The project aims to develop and operate a suborbital vehicle for technology testing and validation for the development of a future Portuguese microsatellite launcher. The long-term objective is to provide an ecological and robust vehicle for microsatellite launching for Portugal and Europe [3].

The suborbital launcher is based on the second stage of a large-scale microsatellite launcher, and should use liquid methane and oxygen as propellants, have an engine capable of producing at least 25 kN, possess carbon fiber structural tanks, attain a 230 kg load capacity and achieve an altitude of approximately 85 km. These specifications, as well as the project’s consortium, are presented in Figure 1.

The conception and launch of this suborbital vehicle should allow to test the assembly, integration and operation procedures as well as validate and verify the component’s performance such as engine performance, composite cryogenic tank compatibility for the propellants, structural integrity, telemetric control, and operational and experimental data collection.

2.1. State of the Art

Since systems for space applications are a sizeable subject, this paper refers mostly to some examples of applied electronic components for space missions, which perform the same roles as the housekeeping system, for instance, processing units, accelerometers and magnetometers. Studies which may aid in the implementation of this system are also referred to, such as cooling systems and data treatment algorithms.

A summary of the technology used for space exploration is provided in [4]. This document mentions several topics regarding launch vehicles such as their type, housekeeping functions, payloads and instruments, not forgetting the required ground support systems and project management.

With passing time, the number of launches—be it for satellite implementation, probe launching for space exploration or even space tourism—steadfastly increases, and so the desired specifications regarding launcher vehicle hardware and software increase in difficulty, which in turn develops the technology at a steady pace.

For instance, regarding hardware development and housekeeping functions such as thermal, attitude and other telemetry readings [4], an accelerometer is developed and tested in laboratory in [5]. This accelerometer provides exceptional results, being selected by the European Space Agency (ESA) as part of a suite of instruments to perform readings on Mercury’s geophysics through its gravitational field and rotation. The entire project is presented, from its conception and 3D design to test results. A study is performed in [6] regarding the application of another type of gyroscope for space applications. Results shown in the document prove that the differential Coriolis Vibratory Gyroscope (CVG) can be used in conjunction with the commonly used Micro Electro-Mechanical System (MEMS) gyroscope or other types of gyroscopes to fulfill their requirements for use in space applications.

Magnetometers are another type of sensor used in housekeeping systems. In [7], a review of magnetometers used in space missions is presented. Most are fluxgate magnetometers (FGMs), with only one presented mission using a vector/scalar helium magnetometer (V/SHM) in conjunction with FGM. Advances in magnetometer technology are also referred to as the most used magnetometer type, FGM, possesses severe limitations such as drifting scale factors and voltage offsets with time and temperature, requiring periodic recalibration, for instance. Consequently, new types of magnetometers are mentioned as possible replacements, such as MEMS and optomechanical magnetometers, as the requirements for magnetometers are increased.

Regarding microprocessors and their applicability in space missions, these components require fulfillment of the specifications as a failure in the processing capability of the housekeeping system significantly hinders the mission as much of the control and data transmission and allocation is performed by this hardware. Processors SAMV71 and STM32H7 are subjected to radiation tests in [8,9], respectively, with protective shielding, and their performance is verified. Both processors comprise an ARM Cortex M7, with some minor differences in flash memory and power consumption, and testing shows promising results regarding their applicability in space missions, since in the destruction test SAMV71 started to fail for radiation doses of 60 krad to 95 krad and STM32H7 started to fail for values of 47 krad. For perspective, a 10-year synchronous orbit around the sun at 800 km equates to around 10 krad, or $0.1$ kJ/kg, of radiation dosage.

A major disadvantage of choosing a space-graded processor over COTS system-on-chip (SoC) is its much lower processing capabilities, as space-graded processors are less developed than commercially available processors by several generations. As such, in [10], a SoC is chosen for data acquisition, cloud-screening and compression for Jet Propulsion Laboratory’s (JPL) Next-Generation Imaging Spectrometers (NGISs). The chosen computing element is Xilinx Zynq Z7045Q, which contains a dual-core ARM Cortex-A9 processor, with a clock rate of up to 1 GHz. Although the processing capabilities of this processor are the equivalent of up to 10 RAD750 Power PCs, which are space graded processors, the COTS computing element lacks in its space-qualification. Consequently, it is being tested for radiation in the International Space Station (ISS) as well as in precursor CubeSats operating in low Earth orbit (LEO). This SoC can be fitted in a 120 mm by 190 mm by 40 mm assembly and possesses a maximum power consumption of 9 W.

An overall advantage of COTS hardware for housekeeping systems is their much lower cost, despite having a lower technology readiness level (TRL). The document presented in [11] mentions several advantages in implementing COTS hardware beyond the one mentioned above. Other advantages include the possibility of redundant sensors, ease of maintenance and its lower costs, easy replacement, and fast prototyping for emerging technologies. While the document does not provide any specific COTS hardware listing, some images are provided from the prototyping phase.

To guarantee that the sensors are operating within a desired temperature, a cooling system is used. As with any other hardware installation, this system should also possess small dimensions and low mass, whilst also fulfilling the desired system’s requirements. With the aim of providing such systems, the study performed in [12] provided a new cooling system with smaller size and reduced cooldown time. The developed compressor has a 32 mm diameter, a length of 90 mm and 190 g of mass, all just slightly lower than the desired specifications. From test results, it withstood a pressure of 1200 psi (approximately $8.274$ MPa) while operating at 90 Hz to 140 Hz. The results from cooling performance can be seen in Figure 11 and Figure 13 of [12] regarding the standard and high-power cold heads.

Data acquired from the installed sensors can be transmitted through several ways to the on-board computer (OBC). The commonly used interface for data transmission is the Controller Area Network (CAN) bus which allows for the hardware to communicate without the need for a host computer, with speeds up to 1 Mb/s, as defined in [13]. As the technology develops for the hardware, as previously mentioned, so does that for the interface communication. In the previously mentioned document, a study is performed for communication from CAN bus to universal asynchronous receiver/transmitter (UART) interface to present data in GUI delphi7 from a computer, which requires the implementation of microcontrollers [13]. These data come from CAN Imager SLIM4, which was installed in the main payload of satellite LAPAN-A4. The use of microcontrollers added 2 ms of delay between communication of the payload and the computer, from 403 ms to 405 ms. Due to the increasingly demanding smaller dimensions, UART can be used for communication, though micro-D ports are being considered as another viable option as well.

As the number of sensors increases, so does the size of data sets, the required non-volatile memory for data storage and missing values due to timing mismatch as the sensors’ sample rates differ. A study in [14] was performed, which involved the Japanese Aerospace Exploration Agency’s (JAXA) microsatellite SDS-4 and data acquired from the mentioned satellite, to test a new method of health monitoring through data-based algorithms such as machine learning or data mining instead of rule-based or model-based algorithms. This satellite’s main purpose is to demonstrate new devices, whose telemetry has a total of 1458 variables. To reduce the number of variables, the ones with low sampling rates, low variation, unrelated to health monitoring or available only when communication with ground station was established were excluded, leaving 89 continuous and 356 status variables for monitoring, as can be seen in Table II of [14]. The data transmitted from these variables were acquired from January 2013 until December 2014 and the method was applied as follows: three months of data were used as training, with the following month used as test; from the experimental results, applicability of data-based algorithms was verified as health monitoring systems, with future work defined as the development of a general-purpose system based on the algorithm developed in this work.

An additional consequence of the increase in number of sensors and sampling rates is the higher size of data packages which are transmitted and/or stored, demanding increasingly more powerful transmission hardware and memory storage. As the hardware development and space grading of the same components are expensive, a possible solution turns to software implementation in the form of data compression. With the aim of discovering a compression method which maximizes the amount of information transmitted while minimizing errors after reconstruction, a study was performed in [15], proposing an adaptable and transformation-based sensor data reduction scheme and testing its efficiency in actual spacecraft data in the form of ARIANE 5 and AISat data sets. Two transform-based data reduction schemes were proposed, Discrete Cosine Transform (DCT) and Discrete Wavelet Transform (DWT), and applied to data from three distinct sensors: an 8-bit temperature sensor, an 8-bit vibration sensor from ARIANE 5’s upper stage, and a 16-bit temperature sensor from AISat’s on-board camera. Two performance variables were determined to verify the performance of the compression schemes, the mean square error (MSE), and compression ratio (CR) of the sampled data. From the experimental results, it was observed that each scheme has its benefits and drawbacks. DCT performs better with lower CR and spreads the error evenly across the entire signal, while DWR outperforms DCT with higher values of CR and can seamlessly capture data points with high amplitude changes. However, smaller changes in the signal are poorly transmitted, which can be seen as a filter, being a desirable side effect for some signals. The document also provided the results of the compression performed to the data sets, achieving a compression factor of $96.5$% for rapidly oscillating vibration and $99.5$% for temperature sensor signals.

In summary, advances in the launcher’s hardware and software have in mind the costs from these components, i.e., the development aims to reduce the costs from prototyping, maintenance, and assembly of these vehicles. Thus, the interest in COTS components, without space grading, is increasing due to their ease in acquisition and replacement, with their costs being significantly lower than space-graded components. The drawback is that while in the vehicle’s operation, the COTS have a higher probability of failure due to their lack of radiation resistance as the altitude increases. Consequently, an effort must be performed to search for COTS components with space application heritage and newly tested components should be mentioned. Nevertheless, projects such as VIRIATO and MIURA 1 [16] emphasize the use of COTS components while maintaining the legacy avionics architecture of previous launchers such as Ariane 5 [17].

2.2. System Requirements

Through the rising interest in microsatellite launching, several projects to study and create dedicated microsatellite launchers have appeared worldwide, with high investments at stake. With the problems defined by microsatellite clients and the gathering of information regarding expected environment conditions for the launcher’s operation, the vehicle’s requirements regarding hardware are presented in

Table 1. Vehicle requirements.

Requirements	Value
Operating pressure range	$[250,105,000]$ Pa
Operating temperature range	$[190,318]$ K
Mission duration	500 s
Operating humidity range	≤90%
Maximum positive longitudinal acceleration	≤50 m/s2
Maximum lateral acceleration	≤6 m/s2
Processor clock rate	≥800 MHz
Angular measurement rate range	±50°/s
Acceleration measurement range	±5 g
Angular rate accuracy	0.1°/s
Data storage for propulsion	≥416 kBytes
Storage capacity	≥$8.1$ MB

.

Other requirements include the ability of withstanding shock, sound pressure, and random vibration loads. Regarding the first mentioned requirement, the housekeeping system is protected, thus it should not be subjected to shock loads. The sound pressure level applies for large systems where this type of load is relevant. Since the housekeeping system possesses a very small envelope, this type of load can be neglected. Finally, regarding random vibrations, the values considered for this type of load arethe same as Ariane’s [18,19], VEGA’s [20], and Falcon’s [21] random vibration values. We note that Ariane 5 [18] and Ariane 6 [19] random vibration distributions are equal.

3. Prototype Design

The system’s envelope is lowered from the preliminary version in [2] to $124\times 88\times 30$ mm, and the main system’s exploded view is presented in Figure 2. This figure allows the visualization of the several different components that form the main system.

As can be seen from Figure 2, the main printed circuit board (PCB) design contemplates the required electronic components of the housekeeping system. The main components are:

• a temperature and pressure sensor BME280 [22];
• an accelerometer/gyroscope MPU-6050 [23];
• a magnetometer LIS3MDL [24];
• a wireless transmission module RFM96W [25];
• an ARM Cortex-M7 as the processing unit [26];
• a lithium-ion polymer battery;
• an ARM Cortex-M0+ as a bootloader [27];
• a CAN bus driver chip MAX3051ESA+ [28];
• a data storage unit XTSD04G SD NAND [29].

While the chosen wireless transmission method is radio frequency (RF), other formats are considered such as Wi-Fi and ZigBee. The option of RF transmission is implemented over the other mentioned methods due to Wi-Fi’s signal being more susceptible to obstacles such as deteriorating weathe rconditions and ZigBee having a very short range and being best used as a mesh grid for long distance transmissions [30]. Other components are present such as power supply unit (PSU) components and additional random access memory (RAM) capacity. The temperature and pressure sensor, BME280, appears twice, i.e., the main system possesses one and the exterior system uses the breakout board of the same sensor.

The entirety of the system is assembled through M3 cap screws, fasteners and nuts, allowing for easy disassembling when needed while also providing a solid joint. Both external and main systems are attached to a surface through four M4 screws each. The structural material is simulated as a space-graded aluminium alloy, AA6061 [2].

4. Mechanical and Thermal Simulations

All simulations are performed resorting to Siemens NX software (2020 version), as well as all CAD files.

4.1. Mechanical Simulations

The mechanical simulations refer to two situations: the acceleration loads due to the vehicle’s movement during launch, also known as Quasi-Static Loads (QSLs), and the related vibrations from the exhaust and combustion chamber, also known as Sine-Equivalent Dynamics (SEDs).

4.1.1. Quasi-Static Loads Simulations

The load values possess two components, the axial and lateral directions. The axial component refers to the acceleration’s direction perpendicular to the ground. This is the main contributor to QSL load types. The lateral component occurs due to the wind contribution, requiring a course correction from the vehicle, and vibration. This component is less significant than axial acceleration; nevertheless, the system’s reaction to QSL loads differs depending on which system plane is coincident with the vehicle’s axial plane. The QSL values are presented in

Table 2. QSL loads.

Load Type	Ariane 5	Ariane 6	VEGA	Falcon	VIRIATO
Lateral [g]	$0.25$	$1.8$	$0.9$	2	3
Axial [g]	$4.55$	6	7	6	10

.

Following the same procedure as in [2], both systems are subjected to acceleration loads, with values based on [18,19,20,21].

An example of such stress distribution of the exterior system is presented in Figure 3. The highest stress values are located where fasteners are installed to connect the different components, as expected. A similar stress distribution is present in the main system. For reference, the highest stress value in either system is $0.066$ MPa.

Thus, due to the low stress values, the deformation results are negligible. The highest deformation values are $9.745\times {10}^{-6}$ mm and $1.156\times {10}^{-6}$ mm for the main and exterior systems, respectively.

Recalling Table 2, the stress and deformation results are highest from VIRIATO’s expected QSL loads as it possesses an increase of approximately 50% of the highest QSL load of any other launcher. The entirety of the results can be found in

Table 3. Highest Von-Mises stress [MPa] from QSL loads.

Acceleration Loads		Main System		Exterior System
Spacecraft	Main Axis	PCB	Casing	PCB	Structure
Ariane 5	X	$0.010$	$0.025$	$0.009$	$0.002$
	−X	$0.010$	$0.025$	$0.009$	$0.002$
	Y	$0.011$	$0.024$	$0.008$	$0.002$
	−Y	$0.013$	$0.025$	$0.008$	$0.002$
	−Z	$0.003$	$0.030$	$0.001$	$0.003$
Ariane 6	X	$0.014$	$0.035$	$0.013$	$0.003$
	−X	$0.023$	$0.036$	$0.013$	$0.003$
	Y	$0.015$	$0.032$	$0.011$	$0.003$
	−Y	$0.017$	$0.036$	$0.011$	$0.003$
	−Z	$0.011$	$0.040$	$0.005$	$0.004$
VEGA	X	$0.029$	$0.039$	$0.015$	$0.003$
	−X	$0.025$	$0.039$	$0.014$	$0.003$
	Y	$0.037$	$0.037$	$0.012$	$0.003$
	−Y	$0.029$	$0.039$	$0.012$	$0.004$
	−Z	$0.007$	$0.044$	$0.003$	$0.004$
Falcon	X	$0.026$	$0.036$	$0.013$	$0.003$
	−X	$0.026$	$0.037$	$0.013$	$0.003$
	Y	$0.008$	$0.020$	$0.011$	$0.003$
	−Y	$0.028$	$0.036$	$0.011$	$0.003$
	−Z	$0.012$	$0.040$	$0.005$	$0.004$
VIRIATO	X	$0.037$	$0.059$	$0.021$	$0.005$
	−X	$0.039$	$0.060$	$0.021$	$0.005$
	Y	$0.026$	$0.055$	$0.019$	$0.005$
	−Y	$0.038$	$0.060$	$0.018$	$0.005$
	−Z	$0.020$	$0.066$	$0.008$	$0.007$

.

4.1.2. Sine-Equivalent Dynamics Simulations

The other mechanical simulation present in this document refers to vibration loads. Firstly, the natural frequencies of both systems are determined, providing the critical vibration frequencies. These are presented in

Table 4. Systems’ natural frequencies [Hz].

Mode	Main System	Exterior System
1	281	$12,590$
2	607	$17,760$
3	750	$24,270$
4	1032	$26,450$
5	1198	$30,150$
6	1338	$31,870$
7	1440	$34,850$

.

The vibration loads used in this document to ascertain the survivability of the housekeeping system refer to low-frequency vibration loads from a launch environment, also known as Sine-Equivalent Dynamics (SEDs). These are presented in

Table 5. SED loads.

	Data
	Ariane
Frequency Band [Hz]	[2, 50]		[50, 100]
Sine Amplitude [g]	$1.0$		$0.8$
	VEGA
Frequency Band [Hz]	[1, 5]	[5, 45]	[45, 110]	[110, 125]
Sine Amplitude [g]	$0.4$	$0.8$	$1.0$	$0.2$
	Falcon
Frequency Band [Hz]	5	[20, 35]	[35, 75]	[85, 100]
Sine Amplitude [g]	$0.5$	$0.8$	$0.6$	$0.9$
	VIRIATO
Frequency Band [Hz]	[5, 20]		[20, 900]
Sine Amplitude [g]	$0.4$		$0.8$

.

The SED values are publicly available, with the exception of VIRIATO’s. We note that both Ariane 5 and Ariane 6 vehicles are referred to simply as Ariane, since they possess the same SED loads. VIRIATO’s values are based on expected loads from a new vehicle with engines similar to those of other vehicles, but slightly more powerful; hence, a larger frequency band is considered.

The stress results from Ariane SED loads, applied on the main system, are presented in Figure 4.

The highest stress values occur in the mechanical interfaces of the systems, similarly to QSL loads. In order not to overburden the figures, stress values below 20% of the maximum value are omitted from the image, which means that most of the structure undergoes a stress value below the threshold. The stress results for the exterior system are, once again, very similar to the main system’s, i.e., the largest stress values are located in the mechanical junctions.

The entirety of simulated results regarding SED loads are presented in

Table 6. Highest Von-Mises stress [MPa] from SED loads.

Spacecraft	Main System		Exterior System
	PCB	Casing	PCB	Structure
Ariane	$0.177$	$0.276$	$0.060$	$0.030$
VEGA	$0.101$	$0.156$	$0.035$	$0.018$
Falcon	$0.184$	$0.288$	$0.063$	$0.031$
VIRIATO	$0.175$	$0.273$	$0.060$	$0.030$

.

As can be seen, the SED loads are much more relevant than QSL loads regarding these systems. This is due to their small envelope and weight, thus being much less susceptible to acceleration loads.

4.2. Thermal Simulations

Thermal simulations are relatively more complex than mechanical simulations for this system, as there are conditions and assumptions that must be made in order for the software to provide proper results. Two thermal simulations are performed: transient and steady state simulations.

While the environmental constraints differ, the material constraints are as follows, for both simulations:

• radiative view factor is set at 1 for all elements and nodes;
• the emissivity of the components is $0.1$ for elements of aluminium alloy [31], $0.8$ for electronic components encased in epoxy, and $0.87$ for the PCB itself [32].

It is worth mentioning that the emissivity of AA6061 is determined with the mean value between AA24ST’s and AA75ST’s, and the radiative view factor’s value is established as a constant value to simplify the simulation and is the worst case scenario. In reality, the view factor’s value depends on each other’s projected area; as such, most of the actual values are below 1.

An additional constraint to be determined is the heat generated by the electronic components. There are two distinct situations to be considered. The first is that all the electronic components are at maximum power consumption, which means that they are in their highest heat generation mode: this mode is henceforth called the hot case. The other situation occurs when all components are on standby mode or equivalent, where their power consumption is lowest: this is the cold case.

In either case, the heat generation is given by

$$HG={\displaystyle \frac{P}{V}}$$

(1)

where P is the power consumption value in $\mathrm{W}$, V is the approximate component volume in ${\mathrm{mm}}^3$, and $HG$ is the heat generation value in $\mathrm{W}/{\mathrm{mm}}^3$. Both power consumption and volume of the components can be obtained through their respective datasheets.

4.2.1. Transient Simulations

Transient simulations attempt to replicate a launch environment. These are simulations with finite time, unlike those for the steady state. The following environment constraints are assumed, as prompted by the software:

• both systems are exposed to the vehicle’s aerothermal flux;
• radiation constraint is applied to all elements and nodes;
• convective and temperature constraints are applied to larger surfaces exposed to the environment;
• the pressure is constant;
• the gravitational acceleration is set at $9.81$ m/s²;
• the fluid and radiative temperature is set at 20 °C;
• the flight’s duration is set at 1500 s, or 25 min.

The aerothermal flux values are obtained through [18,19,20], since [21] provides the expected temperature evolution instead and VIRIATO’s aerothermal flux is not defined. An example of both cases, with Ariane 6’s aerothermal flux, is presented in Figure 5 with respect to the main system.

As can be seen in Figure 5a, there is clearly an area where the highest temperatures are condensed, indicated in the figure itself. The area corresponds to the region where most of the electronic components are located.

The cold case provides results for a real scenario for the system. It can occur if the processor fails to initialize but still provides the power required to activate the sensors. These call this state standby mode or low-power mode, where they are active although not performing any action.

Applying Ariane 6’s aerothermal flux to the main system’s cold case, the results can be seen in Figure 5b. All of aerothermal flux’s highest temperatures achieved by the housekeeping system are presented in

Table 7. Transient simulation results.

Aerothermal Flux		Main System		Exterior System
		PCB	Casing	PCB	Structure
Hot Case	Ariane 5	68	39	64	65
	Ariane 6	64	31	46	46
	VEGA	68	39	62	62
Cold Case	Ariane 5	34	38	63	64
	Ariane 6	30	30	45	45
	VEGA	34	38	61	61

in °C.

As expected, the highest contrast of values between the hot and cold cases occurs on the main system’s PCB, as it possesses most of the electronic components.

4.2.2. Steady State Simulations

Regarding steady state simulations, these are meant to provide a reference value in order to verify whether the system would survive in an LEO environment for a long period of time. It is worth mentioning that these systems are not designed for such purposes; nevertheless, it is helpful to ascertain their survivability in such scenarios.

The following environmental constraints are assumed:

• the system is at an altitude of 500 km;
• the pressure is set at a value predetermined by the software, in this case, by Simcenter 3D Space Systems Thermal;
• the highest and lowest orbital temperatures are 125 °C and −65 °C [33], respectively;
• the gravitational acceleration is $8.45$ m/s²;
• the fluid’s temperature is set at the lowest temperature, −65 °C, and does not change as the atmosphere is very thin.

These assumptions are, once again, as prompted by the software. The material and system’s body assumptions, for instance, radiative view factor and emissivity, are the same as the transient simulation’s. Since the atmosphere is thin, the contribution of convection is ignored and the aerothermal flux is non-existent; thus, radiation is the prevalent form of heat transfer for the steady state simulations.

These simulations are performed contemplating the worst case scenarios. In case the system is exposed to the sun, the electronic components are assumed to be in maximum power consumption mode, generating the highest possible amount of heat. In contrast, in case the system is obscured from the sun, the electronic components are in minimum power consumption mode, generating the least amount of heat. These two cases provide the range of temperature which the system can achieve in LEO conditions.

The main system’s results are presented in Figure 6. The figure presents both cases and provides a visual understanding of the temperature distribution.

As expected, the PCB’s temperature distribution is very similar to the transient simulation results. In the hot case scenario (Figure 6a) and recalling the results presented in Figure 5a, the highest temperatures are achieved in the same area, although the temperature range in the steady state case is 127 °C to 155 °C. In the cold case (Figure 6b), the PCB temperature distribution is also very similar to transient’s simulation (Figure 5b), although in the absence of aerothermal flux and convection contributions, the casing does not increase its temperature, as expected. The temperature range for the cold case scenario is −63 °C to −56 °C.

Regarding the exterior system, the steady state results are presented in Figure 7 for both hot and cold cases.

Once again, in the absence of aerothermal flux and convection contributions, the structure acts as a heat sink for the exterior PCB. The system’s behavior regarding the overall temperature range is very similar to the transient simulation results, i.e., the temperature range is very small when compared to the main system’s range. The exterior system’s temperature is approximately constant, 128°C, for the hot case and −65 °C regarding the cold case.

4.3. Simulation Result Discussion

With the results presented in Section 4.1 and Section 4.2, some remarks can be offered regarding the housekeeping system’s survivability. Regarding the mechanical simulations results, the margin of safety (MOS) can be calculated, providing an empirical conclusion. Values for the MOS are determined with respect to the material’s ultimate and yield strengths and are given as follows [34]:

$$MO{S}_U={\displaystyle \frac{{\sigma }_U}{{\sigma }_V\times FOSU\times K_{LD}}}-1$$

(2)

$$MO{S}_Y={\displaystyle \frac{{\sigma }_Y}{{\sigma }_V\times FOSY\times K_{LD}}}-1$$

(3)

where

• ${\sigma }_V$ represents the Von-Mises stress value of the component;
• ${\sigma }_U$ and ${\sigma }_Y$ represent the material’s ultimate and yield strengths, respectively;
• $FOSU$ and $FOSY$ are the ultimate and yield factors of safety of the materials, respectively;
• $K_{LD}$ is the local design factor for each material.

The Von-Mises stress, ${\sigma }_V$, is given in Table 3 and Table 6 regarding QSL and SED loads, respectively. The casing and exterior structure material properties, as well as the assumed PCB material, are presented in

Table 8. Material properties for MOS calculations.

Property	Material
	AA6061	Polyimide PCB
$K_{LD}$	$1.0$	$1.2$
$FOSU$	$2.0$	$2.0$
$FOSY$	$1.25$	−
${\sigma }_U$ [MPa]	310	200
${\sigma }_Y$ [MPa]	276	−

. The first material refers to an aluminum alloy, AA6061, while the PCB material is assumed to be polyimide PCB [35]. Regarding the latter’s material properties, the worst case scenario is assumed, with its ultimate strength being assigned the lowest value of the polyimide’s tensile strength, 200 MPa.

The local design and safety factors, $K_{LD}$ and $FOS$, respectively, are assigned typical values. As for the thermal simulation results, each of the electronic components’ minimum and maximum temperature ratings must be examined to ascertain their survivability.

4.3.1. QSL Result Discussion

Recalling the Von-Mises stress values from Table 3, the MOS regarding QSL loads are given in

Table 9. MOS values regarding QSL results.

QSL Load		Main System			Exterior System
		Casing		PCB	Structure		PCB
Spacecraft	Axis	${\mathit{MOS}}_{\mathit{Y}}$	${\mathit{MOS}}_{\mathit{U}}$	${\mathit{MOS}}_{\mathit{U}}$	${\mathit{MOS}}_{\mathit{Y}}$	${\mathit{MOS}}_{\mathit{U}}$	${\mathit{MOS}}_{\mathit{U}}$
Ariane 5	X	8762	6151	8333	$110,455$	$77,539$	8836
	−X	8832	6200	8772	$103,759$	$72,839$	8878
	Y	9086	6379	7508	$100,409$	$70,487$	$10,616$
	−Y	9012	6327	6510	$99,415$	$69,788$	$10,551$
	−Z	7485	5254	$30,864$	$89,501$	$62,829$	$79,821$
Ariane 6	X	6255	4391	6083	$71,226$	$50,000$	6510
	−X	6133	4306	3592	$69,000$	$48,438$	6667
	Y	6815	4784	5411	$73,698$	$51,736$	7481
	−Y	6168	4330	4873	$67,813$	$47,604$	7666
	−Z	5562	3904	7440	$51,637$	$36,249$	$17,133$
VEGA	X	5618	3944	2854	$69,000$	$48,438$	5708
	−X	5618	3944	3374	$64,941$	$45,588$	5787
	Y	5920	4155	2277	$64,941$	$45,588$	6831
	−Y	5720	4016	2904	$63,086$	$44,286$	6775
	−Z	5030	3531	$12,077$	$53,166$	$37,322$	$33,003$
Falcon	X	6185	4342	3169	$71,226$	$50,000$	6460
	−X	6049	4247	3157	$69,000$	$48,438$	6614
	Y	$11,095$	7789	$10,684$	$72,016$	$50,554$	7368
	−Y	6066	4258	2934	$66,267$	$46,519$	7603
	−Z	5465	3837	6720	$50,011$	$35,108$	$15,464$
VIRIATO	X	3751	2633	2252	$43,294$	$30,392$	3894
	−X	3680	2583	2131	$41,660$	$29,245$	3987
	Y	4037	2834	3205	$44,160$	$31,000$	4480
	−Y	3701	2598	2193	$40,889$	$28,704$	4604
	−Z	3338	2343	4167	$30,985$	$21,751$	$10,280$

.

Since all values are positive, the housekeeping system should be able to survive a launch environment, assuming that the loads do not differ substantially from the expected.

4.3.2. SED Results Discussion

Recollecting the Von-Mises stress values from Table 6, the MOSs regarding SED loads are given in

Table 10. MOS values regarding SED results.

SED Load	Main System			Exterior System
	Casing		PCB	Structure		PCB
	${\mathit{MOS}}_{\mathit{Y}}$	${\mathit{MOS}}_{\mathit{U}}$	${\mathit{MOS}}_{\mathit{U}}$	${\mathit{MOS}}_{\mathit{Y}}$	${\mathit{MOS}}_{\mathit{U}}$	${\mathit{MOS}}_{\mathit{U}}$
Ariane	472	562	800	7311	5132	1380
VEGA	825	994	1415	$12,475$	8757	2354
Falcon	453	538	767	7054	4952	1329
VIRIATO	476	568	809	7385	5184	1394

.

Once again, the MOS values are all positive, although significantly lower than the results from QSL.

4.3.3. Thermal Result Discussion

The minimum and maximum operating temperatures of each component, mentioned in Section 3, are given in

Table 11. Operating temperatures of electronic components.

Electronic Component	Temperature [°C]
	Minimum	Maximum
BME280 [22]	$-40$	85
MPU-6050 [23]	$-40$	85
LIS3MDL [24]	$-40$	85
RFM96W [25]	$-20$	70
Processor [26]	0	95
Bootloader [27]	$-40$	105
CAN driver chip [28]	$-40$	85
Data memory unit [29]	$-30$	85

.

Starting with the transient simulations’ results and recalling the temperatures given in Table 7, it is concluded that all electronic components are able to survive launch environments when subjected to an expected aerothermal flux. It is worth mentioning, once again, that the transient simulations expect a flight time of 1500 s. Any flight duration longer than the expected may cause the temperature to increase to values higher than the maximum operating temperature of the electronic components.

Regarding the steady state simulation results, it is concluded that direct and long exposure to LEO ambient conditions causes the system to fail, since both minimum and maximum operating temperatures are exceeded by a significant margin. Thus, if the systems are expected to operate in such environments, a cooling/heater subsystem must be installed to prevent their failure.

5. Prototype Implementation

The assembly and programming of the system follow the design stage. This section presents the placement of the parts, concerns the electronic components of the main system’s PCB, the software architecture and implementation, and lastly contains the steps required for the assembly of the housekeeping system.

It is worth mentioning that, since development takes place within the scope of project VIRIATO that does not require the highest possible TRL level, both the casing of the main system and the structure of the exterior systems are 3D printed with PETG instead of being manufactured with AA6061, thereby reducing the project’s budget.

5.1. Parts Placement

Unlike the design stage, the part placement of the main system’s PCB also includes all the required signal conditioning components of each electronic component. The simulations do not include these additional components, such as capacitors and resistors, as these are negligible due to their extremely small envelope when compared to the main electronic components.

The part placement is performed resorting to software Altium, and the main system’s PCB is presented in Figure 8.

The D-Sub DB9 connectors’ pinouts are presented in Figure 9 for CAN (Figure 9a) and I²C (Figure 9b) communication.

The board is capable of performing its own diagnostics, not requiring any type of program installation. This is executed by simply providing the required power for the processor’s initialization.

The status of the board is given through a set of light-emitting diodes (LEDs) whose locations are LMK, D13, PG, ST2, and ST1. These are represented by red squares in Figure 8. These LEDs allow the user to understand the condition of the power and initialization of the board.

5.2. Software Implementation

To obtain the wireless transmitted data, a ground station is required. This station also acts as the testing station in order to simulate messages transmitted to the main system as the OBC. The command list is given by

Table 12. Command list.

Command	Description	Return
10	Initialize sensors	1 = True
		2 = BME280 init failed
		(…)
		16 = All init failed
		17 = Unknown error
11	Start acquisition and storage	21 = True
		100 = False
12	Display data in storage	22 = True
		101 = Acquisition off
		200 = File not found
13	Display data instance	23 = True
		101 = Acquisition off
14	Stop acquisition	24 = True
		102 = Acquisition inactive
15	Delete data file	25 = True
		103 = Acquisition active
		200 = File not found
−	Other system status	202 = Fail to create/open file
		201 = Unknown input

.

The return value when the command “10” is given depends on which sensors fail to initialize. All failure combinations can be introduced.

With the command list defined, the system must identify the messages sent via CAN bus to the OBC, aiming to ease the on-board’s computer load. The identifiers are presented in

Table 13. Identifier list.

ID	Description
0x666	Orders given and replies from the main system
0x650	Used by the testing station to verify whether the data format is correctly implemented
0x601	External temperature reading
0x602	External pressure reading
0x603	External altitude reading
0x604	External humidity reading
0x605	Linear acceleration in X-axis
0x606	Linear acceleration in Y-axis
0x607	Linear acceleration in Z-axis
0x608	Angular velocity in X-axis
0x609	Angular velocity in Y-axis
0x610	Angular velocity in Z-axis
0x611	Accelerometer’s internal temperature reading
0x612	Magnetic field value in X-axis
0x613	Magnetic field value in Y-axis
0x614	Magnetic field value in Z-axis
0x615	Internal pressure reading
0x616	Internal temperature reading
0x617	Internal humidity reading

and allow for the OBC to focus in the desired parameters, ignoring the others.

5.3. Prototype Assembly

Before assembling the final prototype, a breadboard prototype is developed, resorting to breakout boards, or equivalent, of the same sensors installed on the main system’s PCB. The objective of this swift prototype is to perform at least the functional tests of the software. The prototype is shown in Figure 10.

Functional testing is performed with successful results.

6. Prototype Evaluation

This section mentions the performed functional and field tests with the prototype. This includes static testing, such as in laboratory and integration tests, and tests resorting to unmanned aerial vehicles (UAVs).

6.1. Static Tests

These tests are performed to determine the sensors’ characteristics as well as the prototype’s such as autonomy. Other static tests include communication protocol and transmission rates, for instance.

6.1.1. Sensor Testbench

Recalling the housekeeping system’s requirements in Table 1, the sensors’ performance can be compared as seen in

Table 14. Requirements and system performance comparison.

Requirement	Value	System Performance	Reference
Pressure range	[$2.5$, 1050] hPa	[300, 1100] hPa	[22]
Temperature range	[$-83$, 45] °C	[0, 65] °C	[22]
Mission duration	500 s	≥18 h	Section 6.1.3
Humidity range	≤90%	≤100%	[22]
Max long. accel.	≤50 m/s2	[±2, ±16] g	[23]
Max lat. accel.	≤6 m/s2
Processor clock rate	≥800 MHz	≤600 MHz	[26]
Ang. rate range	±50°/s	±250°/s	[23]
Accel. range	±5 g	[±2, ±16] g	[23]
Ang. rate acc.	0.1°/s	±20°/s	[23]
Storage for propulsion	≥416 kBytes	4 Gb	[29]
Storage capacity	≥8.1 MB

.

As expected from using COTS components, some requirements are met whilst others are not fulfilled. For instance, the angular rate’s accuracy is much higher than desired, although the linear acceleration’s requirements are all met. This may be due to resorting to a sensor which fulfills several roles instead of having a specialized sensor for each parameter.

6.1.2. Communication Protocol Test

The implementation of the communication protocol, as shown above in Table 12 and Table 13, yielded successful results. An example of such implementation is presented in Figure 11. The figure presents the testing station’s point of view, equivalent to the OBC. The first command sent to the main system was the numeric value of “10”, to which the main system replied “1”. The message is marked by the blue color, in which the identifier of the message, 666, is reserved to orders and replies exchanged between the main system and the OBC. Additionally, the length of the reply and data transmitted are also sent. These messages are in hex code due to the CAN bus communication protocol based on the American standard code for information interchange (ASCII).

Converting the first main system’s reply in characters provides the desired result of “1”, followed by the [NULL] character. The second reply, marked by the yellow color, is given in response to the command “11”, which initiates the data transmission and storage. Finally, all the desired parameters are in red.

6.1.3. Transmission Rate and Power Consumption Tests

The CAN bus communication protocol yields the fastest transmission rates, as expected, varying between 45 ms and 150 ms, depending on the number of active sensors; it seems to be independent of the number of parameters. The transmission rate of one parameter or more does not differ if they are from the same sensor.

The RF transmission rate is slower than that of the CAN bus, approximately requiring twice the time to transmit the same data size. The main difference is that RF data transmission depends on the number of parameters as well as the number of sensors. For instance, with four active sensors, each acquiring a single parameter, the CAN bus transmission rate is 100 ms, while that of RF is 125 ms.

With both communication methods active, the transmission rate varies between 125 ms, with one active sensor, and 435 ms, with all sensors active and acquiring the maximum number of parameters.

Regarding the system’s power consumption, a test was performed, where it was left to acquire all 17 parameters through itself, i.e., the required power was provided by its 2500 mAh battery. The battery provided an autonomy of over 18 h.

The housekeeping system apparently starts prioritizing certain components over others. For instance, the RF module’s transmission stopped first while the CAN bus connector continued transmitting data.

6.1.4. OBC Integration Test

An integration test was performed in which several subsystems were assembled. The housekeeping and the propulsion subsystems were connected to the OBC, which originated all commands. While the data were successfully transmitted and received by the OBC, due to the higher numeric value of the identifier, the housekeeping system’s data had lower priority over the other subsystem, and thus its telemetry data were stored in communication buffers. This had the unforeseen consequence of telemetry data loss due to the excessive amount of information being transmitted to the OBC, which could not be handled effectively.

6.2. Field Tests

Vehicles used in field testing described below are not representative of the intended target (launcher), but are nevertheless a stepping stone to study the housekeeping system’s performance, since if the system fails with an UAV it will not work in a launcher. Results obtained provide feedback for further design iterations.

6.2.1. Proof of Concept

A field test was performed resorting to a fixed wing UAV, within the scope of project Eye in the Sky [36]. This UAV was controlled through radio frequency commands, requiring a person on site in order for the UAV to remain in-flight.

This field test aimed to provide results regarding the viability of the housekeeping system’s installation as a vehicle’s payload. The exterior system of the housekeeping system was not implemented due to volume constraint. Thus, the external BME280 sensor was absent from this field test.

To determine the UAV’s flight time, the pressure reading was used. It is undoubtedly the easiest parameter to help ascertain the take off and landing instances of the UAV. The pressure reading is presented in Figure 12, where the take off, flight time, and landing are noticeable.

As can be seen from the figure, the pressure varies throughout the flight. This is due to the maneuvers performed by the UAV. These maneuvers, allied with unstable wind conditions of that day, provide different lift forces, which in turn affects the UAV’s altitude, modifying the pressure readings.

6.2.2. Hexacopter Test

The use of an autonomous hexacopter was introduced as additional field test. This hexacopter can be seen in Figure 13 and its flight path in Figure 14. The hexacopter was programmed resorting to a platform called Mission Planner from ArduPilot [37].

The flight path was constructed resorting to waypoints and the desired altitude, programmed with [37]. The hexacopter’s control is completely autonomous while following the flight path.

The housekeeping system was installed as the UAV’s payload, replacing the camera seen in Figure 13. The UAV’s pressure and altitude parameters were acquired by two independent systems, its own telemetry and housekeeping system. Both parameters are presented in Figure 15.

As can be seen, the parameters possess similar plots. Due to the housekeeping system’s position as the hexacopter’s payload, a transmission loss occurs due to the antenna’s capabilities. This flight’s transmission loss began at the furthest distance from the ground station. The transmission loss can be seen in Figure 16.

There is clearly a communication loss between the housekeeping system and the ground station represented by red horizontal straight lines when compared with the blue line. There is a transmission loss taking place approximately from 3860 s to 3890 s, and another at 3930 s down to 3940 s. Other transmission losses are present, although shorter in duration. These transmission losses may be explained by the Doppler effect.

Nevertheless, up until the first moment of transmission loss, the distance between the hexacopter and ground station exceeded 900 m. This transmission range was obtained resorting to the Delta 22 RF antenna [38] instead of a patch antenna. It was decided to use an omnidirectional antenna, with higher gain than a patch antenna.

6.2.3. Fixed Wing UAV Test

An autonomous fixed wing UAV, presented in Figure 17, was used to test the housekeeping system’s capabilities as well. The flight path is illustrated in Figure 18.

Figure 19 presents the UAV’s in-flight pressure and altitude readings, and the same platform of the previous field test is used to program the desired waypoints and altitude.

The housekeeping system was installed in the UAV’s canopy, marked by the orange color, as seen in Figure 17. Due to the location, the housekeeping system’s antenna has to be placed above both housekeeping system and the UAV’s electronics. This placement, allied with the fact that the UAV performed a holding pattern, as seen in Figure 18, contributed to the transmission loss, clearly visible at 1800 to 1900 s of Figure 19b. This particular transmission loss was augmented with the Doppler effect.

There were five distinct instances where transmission loss occurred, which was consistent with the five cycles of the holding pattern. The last holding pattern was followed by the flight to the home position. The transmission range was approximately the same as before, i.e., around 900 m. The same antenna of the field test with the hexacopter was used in this case.

We notice that there was a discrepancy of the altitude level between the telemetry of both UAVs (the hexacopter and this fixed wing UAV) and the housekeeping system. This is due to the fact that the altitude provided by the sensor installed within the housekeeping system converts the pressure variation into altitude in meters. The conversion was performed using [39]

$$\mathrm{Altitude}=44330\left(1-{\left({\displaystyle \frac{p}{p_0}}\right)}^{{\displaystyle \frac{1}{5.255}}}\right)$$

(4)

where p is the measured pressure and $p_0$ is the defined pressure at sea level or initial pressure.

Since the latter requires a constant calibration, and most initial pressure values refer to a wide area, for instance, the metropolitan area of Lisbon, this is not the most accurate parameter. This initial pressure definition explains the 10% error between the UAVs’ telemetry altitude and the housekeeping system’s.

6.3. Prototype Launcher Integration

The results of project VIRIATO were presented together with a mock-up of the vehicle and its systems. Although the vehicle did not perform a flight test, a simulated flight and subsequent ditch of the vehicle was developed, as seen in Figure 20. The vehicle’s mock-up and housekeeping system integration within the launcher can be seen in Figure 21. In Figure 21b, System 1 and System 2 were not developed by the authors of this paper. System 3 is the launcher’s housekeeping system developed by the authors.

The OBC unit, and its subsystems, including the developed housekeeping system, are installed below the fairing. This location is not definitive, as the housekeeping system can be installed on any launcher’s component due to its transmission capabilities.

7. Conclusions

The housekeeping system is successfully developed and implemented, fulfilling most of project VIRIATO’s requirements while falling short in others. The system’s communication, RF and CAN bus, and data storage components perform effectively, with the correct implementation of the data format.

The integration test is also successful, with the OBC able to provide commands and receive data parameters. Although the communication is established with the OBC, most of the housekeeping system’s parameters may apparently be lost in the OBC’s communication buffer, most noticeable when other subsystems, such as the propulsion, are linked.

This is due to two factors. The first, as mentioned in Section 6.1.4, is the higher identifier numerical value when compared to the propulsion system’s parameters. The second is the OBC’s processing unit overload of information. The 17 parameters of the housekeeping system may be overburdening the communication buffer, thus losing some parameters.

From the field tests, it is concluded that the housekeeping system may be installed as a vehicle’s payload, acquiring its flight telemetry data. The embedded memory successfully stores all the data, while the wireless data transmission is still susceptible to loss due to failure in communication, although the transmitted data are accurate.

This work proves, in simulation, that COTS components could be used to lower the cost production of suborbital vehicles, allowing for a relatively quick prototype development and access to a wider range of components that was previously thought of as not viable. Of course, the true test of the COTS components is the ability to withstand radiation doses as the suborbital vehicle climbs to deliver the payload, as they are not certified for space-related applications. Only the collective use of COTS and their shared experience within the community dictate which COTS components are viable for space missions.

Future Work

For a full characterization of the housekeeping system, it is suggested that the sensor’s performance be determined in a controlled environment. This will provide the adequate data for determining the parameters’ natural standard deviation, resorting, for instance, to an oven to verify the temperature readings and a vacuum chamber for pressure.

The RF transmission range must be tested with higher-gain antennas. While the housekeeping system’s antenna is very limited due to size constraints, the ground station can possess a very-high-gain antenna without any constraint, significantly increasing the reception range.

To further test the performance of the housekeeping system using UAVs, a proposed VTOL capable UAV is considered, like the one in [40]. The possibility of the housekeeping system tracking a vehicle’s flight condition and performing decision-making actions is also an interesting concept. For instance, it could be installed as a backup telemetry system, with independent sensors, for redundancy, only activating when the vehicle’s main telemetry system fails; it could also act as an anti-jamming system, with the appropriate modifications.

Last but not least, the current housekeeping system, with the collaboration of Fénix Rocket Team, will perform a small-scale launch vehicle field testing. The system will be installed as the vehicle’s payload through development of a CanSat structure. An expected launch data is mid to late 2024.