Figure 3 - uploaded by Christian M. Fuchs
Content may be subject to copyright.
A ride-share satellite launch with the Earth observation SmallSat DubaiSat-2 (top center) being the primary payload. Secondary payloads were 4 microsatellites (top left and right, 2 bottom center) and 26 other nanosatellites which are located in the blue deployer boxes. The CubeSat First-MOVE (see Section 2.1.4) is located in the top right deployer.
Source publication
Miniaturized satellites enable a variety space missions which were in the past infeasible, impractical or uneconomical with traditionally-designed heavier spacecraft. Especially CubeSats can be launched and manufactured rapidly at low cost from commercial components, even in academic environments. However, due to their low reliability and brief lif...
Contexts in source publication
Context 1
... reduce costs, organizations often either sell this excess capacity, or hand the entire launch process over to a "launch broker", which then can combine multiple satellite launches into one "ride-share" launch [29]. An example of a ride-share launch with multiple satellites of various classes is depicted in Figure 3. The main spacecraft launched on a launch vehicle is then referred to as "primary payload", with other, often smaller satellites becoming "secondary payloads". ...
Context 2
... setup simulates an MPSoC three compartments executing the described demo application, and measures performance of the application executing within a compartment. For each plot in Figure 32, 100 measurements were taken of the real-time necessary to process 600 1-Megapixel frames with subsequent processing runs. Data heavy modes indicate a high amount of post-processing runs, whereas compute-heavy modes indicate lower per-thread workload. ...
Context 3
... naive implementation of our approach at the application level on Linux shows median-best performance degradation of 9% and median-worst degradation of 26%, which are also indicated in Figure 32a and e in bold. Across all test runs, we measured on average 80% worst-case and 95% best-case performance compared to the unprotected reference runtime. ...
Context 4
... execution can be triggered in bulk, hence outgoing packets are being stored in a FIFO queue for transmission. A more detailed representation of the saving subsystem's program flow is provided in Figure 33. ...
Context 5
... current saving subsystem implementation consists of an ARM7TDMI MCU with an OBC-independent communication channel toward the CubeSats transceiver or saving subsystem as depicted in Figure 34. We chose to utilize an interrupt-driven bidirectional SPI-based interface to implement this channel due to its flexibility and simplicity. ...
Context 6
... depicted in Figure 36, the saving subsystem can not only control and reprogram an FPGA, it can also be used to implement more advanced usage scenarios: A continuous read-verify-repair cycle could be scripted and executed in a timed manner to enable scrubbing and reduce the impact of transient errors [234]. As most radiation effects within FPGAs are transients, thus temporary errors, their impact on the system can be reduced even if radiation-soft SRAM FPGAs were used. ...
Context 7
... saving subsystem can also reconfigure an OBC with several different FPGA configurations for reasons beyond FDIR. More complex space missions consist of several different phases with varying duration and requirements towards the OBC as depicted in color in Figure 37. Using traditional discrete processing components or write-once anti-fuse FPGAs, the properties of a system are static and can not be modified later on. ...
Context 8
... FPGA configuration management based on mission phase requirements could drastically improve overall performance and reliability of an OBC design. As shown in Figure 37, the saving subsystem could provision different SOC variants with a varying number of processing cores and TMR strength depending. Provisioning could be conducted automatically based on the requirements of different mission phases. ...
Context 9
... saving subsystem can also perform scrubbing on an FPGA configuration, which allows further classification into transient and permanent errors, refining testing results. Hence, fault analysis can then be conducted using high-quality information and the results obtained can also be fed-back into the testing cycle, see Figure 36. This information could ultimately also be introduced into an FPGA design's testbench and can help simulate the impact of changes to design based on realistic information without performing additional radiation tests. ...
Context 10
... Stages form a closed loop and implements FDIR in several steps as depicted in Figure 38. Additional information on Stage 1's thread-level coarse-grain lockstep, beyond what is briefly described in Section 6.5.1 are available in Chapters 4. ...
Context 11
... allows the system to recover defective compartments through reconfiguration, and enables it better handle permanent faults. Figure 38: Stage 1 (white) implements a continuous checking loop, which facilitates fault coverage through thread-level synchronization and migration between compartments. Stage 2 (blue) can recover faulty compartments using reconfiguration. ...
Context 12
... compartment's checkpoint-related information is stored in a dedicated on-chip dual-port BRAM memory (validation memory) and exposed to other compartments, to allow low-latency information exchange between compartments without requiring inter-compartment cache-coherence or access to main memory. Validation memory is Figure 39: A high-level topology diagram of our compartmentalized MPSoC architecture with memory controllers highlighted in yellow, and interconnect-logic in blue. A debug-bridge on each compartment allows supervisor access. ...
Context 13
... is implemented as sets of compartments running two or more copies of application threads (siblings) in lock step. Checkpoints interrupt execution, facilitating the lockstep and enforcing synchronization, allowing thread assignment within the system to be adjusted if required, as depicted in Figure 38. ...
Context 14
... enable meaningful fault tolerance, data consistency must be assured both within volatile and non-volatile memory, see Figure 43. Data is usually classified as either system data or payload data stored in volatile or non-volatile memory. ...
Context 15
... is certainly possible also for flash memory, however it would hinder the file system from performing block EDAC and wear leveling. While block abstraction would still be possible even on top of a block layer on-top of the FTL, other high-level filesystem functionality would be denied device access, depicted in red in Figure 53. These functions would then have to be implemented at a much lower level within the access hierarchy, introducing further code overhead and reducing EDAC efficiency. ...
Context 16
... this section, we describe a publicly reproducible MPSoC design variant implementing our architecture, which can be designed in full using Xilinx library IP and Microblaze processor cores. The architecture minimizes shared logic, compartmentalizes compartments, and offers a clearly defined access channel between compartments and the supervisor, and is depicted in Figure 63. ...
Context 17
... supervisor can access and modify each compartment's state memory through its debug interface on each compartment. Figure 63 depicts the MPSoC's high-level topology. Our MPSoC design utilizes an AXI interconnect in crossbar mode to allow compartments access to shared main and non-volatile memory controllers, though we are currently reworking our MPSoC to instead use a NoC [329]. ...
Citations
... Recent research work (Ph.D. thesis of C. Fuchs, December 2019 [19]) proposes a novel on-board-computer architecture for very small satellites (<100kg) capable of achieving high reliability without using radiation-hardened semiconductors, through the combined use of hardware and software-implemented fault tolerance techniques [19]. However, in spite of this promising research result from C. Fuchs, to the best of the author's knowledge, there are no fault-tolerant boards available for CubeSats, especially boards that can cope with transient faults that affect the processor, which are the major threat to the reliability of CubeSats. ...
... Recent research work (Ph.D. thesis of C. Fuchs, December 2019 [19]) proposes a novel on-board-computer architecture for very small satellites (<100kg) capable of achieving high reliability without using radiation-hardened semiconductors, through the combined use of hardware and software-implemented fault tolerance techniques [19]. However, in spite of this promising research result from C. Fuchs, to the best of the author's knowledge, there are no fault-tolerant boards available for CubeSats, especially boards that can cope with transient faults that affect the processor, which are the major threat to the reliability of CubeSats. ...
... On average, when the faults are injected in the 16 less significant bits of the registers, the target system behaves outside the expected behavior (i.e., failure modes showing abnormal behavior) in about 20% of the faults. On the other hand, when the fault was injected in the first 8 most significant bits group ( [17][18][19][20][21][22][23][24]), we observed that, on average, 87.55% of the faults have no impact on the target system. A similar result was observed for faults injected in the last 8 most significant bits group ( [25][26][27][28][29][30][31][32]), as 91.68% of the faults had no impact on the target system behavior. ...
CubeSats are small satellites built with up to 12 units of the shape of a cube of 10cm edge and weight of 10kg maximum and represent an emergent trend in the space industry. These satellites use commercial off-the-shelf (COTS) components to reduce cost and take advantage of the superior performance/power consumption ratio of COTS, which is an order of magnitude better than the equivalent radiation hardened space-grade-components. Unfortunately, COTS components are susceptible to Single Event Upsets (SEU), which are transient errors caused by space radiation. SEU makes the study of the impact of faults caused by space radiation a mandatory step in the development of CubeSats software, in order to carefully evaluate weak points that must be strengthened through the use of specific software fault tolerance techniques. The fact that the impact of faults is strongly dependent on the software running on the COTS hardware indicates that the study of the impact of radiation faults must be carried out every time the CubeSat software has a major change, or even a minor update.This thesis presents CubeSatFI, a fault injection platform for CubeSats meant to facilitate the incorporation of this extra step in the Verification and Validation of CubeSats software. CubeSatFI allows the easy definition of fault injection campaigns that emulate the effects of space radiation. SEU are emulated realistically through bit-flip faults injected in the processor registers and in other locations of the CubeSat boards that can be reached by boundary-scan, which is available in CubeSat boards through JTAG Test Access Port. The execution of the fault injection campaigns is controlled by the CubeSatFI platform in a fully automated mode.The effectiveness of CubeSatFI is demonstrated with the EDC (Environment Data Collection), a payload system that will be used in a constellation of satellites from the Brazilian National Institute for Space Research (Instituto Nacional de Pesquisas Espaciais - INPE), providing a realistic insight on the impact of faults in the EDC software.
... In this section, we will provide a brief summary of the base concept that we have now developed into a fully fledged hardware prototype. This section is meant only to provide a brief introduction to the concept, considerably more in-depth documentation, as well as testing and validation results can be found in [1] and [14]. ...
... To test our implementation, we conducted fault injection at different levels, which we documented in [16] and [14]. Next, we developed a multi-core model of our MPSoC also in ArchC/SystemC to conduct further faultinjection close-to-hardware, which is further described in [17]. ...
... Next, we developed a multi-core model of our MPSoC also in ArchC/SystemC to conduct further faultinjection close-to-hardware, which is further described in [17]. A more detailed description of these validation steps is described in detail in [14]. To achieve worstcase performance estimations, we measured the worstcase performance cost of this approach, which are also described further in [18]. ...
In this contribution we present practical experiences from realizing a prototype of the first truly fault-tolerant and autonomously operating avionics suite for miniaturized satellite down to the size of a 2U CubeSat.
Our initial demonstrator setup consists of a mix of COTS parts and FPGA development boards, which we gradually expanded in scope and capabilities.
After four iterations of PCB development and manufacturing, we have condensed this design to a fully integrated custom PCB-based prototype.
Our fourth architecture iteration is stackable and is designed to fit on an 80x80mm PCB footprint.
It is furthermore capable of operating as generic satellite subsystem node, functioning in a distributed, fault-tolerant, interconnected manner together with other subsystems.
Each node is fully replaceable by two or more neighboring subsystem-nodes.
In consequence, we achieve a satellite bus setup which is in spirit similar to integrated modular avionics and modern fault-tolerant avionics network architectures used in other fields.
We realize this setup through a high-speed chip-to-chip network in a compact CubeSat form factor.
