# Robust and Reconfigurable On-Board Processing for a Hyperspectral Imaging Small Satellite
## 3 On-Board Processing Unit Design
### Design Goals  
The space environment imposes a number of challenges on spaceborne electronic systems. Corrupted or non-functional software on a satellite can be caused by a faulty software update, by flipped bits in memory as a result of a radiation event, or by the degraded quality of the memory device. Among the most predominant risks for the payload system's function identified is in the boot process due to the criticality of data corruption. Improper booting may result in a critical failure causing the mission to end. Scenarios, where a reboot is required, include the reset of a non-responding sub-system or system power-off to save energy or to protect circuitry in the event of a solar flare. In the CubeSat mission Aalto-1, a total of 38 boot events occurred during the first five months of the mission, out of which 35 were unplanned [28]. In the mission AAUSAT-II, 11 spontaneous reboots every 24 h are reported [61]. This illustrates the importance of a reliable and fault-tolerant boot sequence.  
The principles guiding the design of the OPU architecture are listed in Table 1. A description about how these principles were understood in the project follows.  
The first three principles (integrity, redundancy, locality) are related to the startup or booting procedure, whereas the following four (modularity, extensibility, configurability, low latency) are explored in applications for command handling, telemetry and on-board processing. _Integrity_ is the ability to detect faults in the system, both in terms of faults due to corrupted data and in terms of software bugs. This is important as the space environment is known for latch-ups and single-event upsets that can cause system faults and data corruption. In addition, part of the concept of operation is to update the HYPSO-1 payload software frequently, and thus there is a risk of faults caused by software bugs. Verifying data integrity and detecting corrupted data can be achieved using hashes and checksums. _Redundancy_ provides a backup solution in case of an integrity violation, to ensure continuous operation. _Locality_ refers to how physically close in hardware backup copies of software or data are stored. Low locality reduces the likelihood that a fault event affects multiple copies. _Modularity_ is a design property in which a system consists of independent components. High modularity reduces bugs, improves efficiency during development and is also beneficial for extensibility and simplicity. _Extensibility_ refers to the ability to extend the system by adding new functions via updates. This is necessary as software development was not finished by launch, as well as for the ability to function as a research platform that allows to test new on-board processing algorithms as they become implemented and ready. _Configurability_ refers to the ability to adjust a function or task to meet specific needs by altering parameters without performing a software update. The operator or user may use different parameters to optimize information extraction depending on target of interest. Finally, _Low latency_ is part of the mission concept of, e.g., HAB detection and communication with in situ agents for coordinated mapping and monitoring. These principles together aim for a high degree of fault tolerance. Additionally, the payload design was subject to constraints set by available time, knowledge, manpower and material resources.