4
$\begingroup$

Most of the questions related to using linux is cubesat/space missions is for the flight computer. I understand that a RTOS is preferred over a full blown linux for a flight computer. However I am interested in knowing how would a linux based COTS payload like a Beaglebone Black or a Raspberry Pi perform in such harsh conditions.

  • What would be the best way to operate such payloads so that their life could be extended?
  • Can rebooting the payloads help in extending their life?
  • What is likely to fail when using such COTS modules as payloads?
$\endgroup$
1
  • 3
    $\begingroup$ RAM. Radiation causes random changes in the RAM. Linux can not handle them (and also not RTOS). You will have random segfaults in the processes, and sometimes kernel panics. You need a highly redundant system where the nodes can power off, power on and reboot each other. You need also error correcting, radiation hardened RAM chips. $\endgroup$ – peterh Apr 3 '20 at 2:56
3
$\begingroup$

Raspberry Pis have certainly been designed into cubesats but have not tracked down any overall listing of number actually launched, how well they operated or any lessons learned.

Related questions include this one on Pi's and this on code design.

The three questions overlap, and tie back to hardware design. Hardware side the first task is to ensure the the presumably COTS CPU board is not exposed to environments that degrade/destroy it - mostly by stabilizing temperature. The second part is to provide a a robust support service for the CPU board - stable power, input protection (better to kill an input buffer than whole CPU), watchdogs and redundant storage and of enough smarts to run things while main CPU is recovering.

Rebooting the CPU does not directly help reliability, but design must assume that CPU could reset at any time and include a recovery path for as many as possible failure states that get back to operating, so having automatic hardware driven resets are a one stop shop solution to bugs that lock the CPU rather than individually chasing down those bugs. Do need to avoid blindly going down this path if automatic resets will disrupt time critical operations like landing. Reset process also needs to be able to detect and recover from as many data corruption types as possible, both those from the environment and those left in old data when previous version crashed.

In terms of likely failure points there does not appear to be a summary available on things that killed COTS boards during testing. The anecdotal examples include electrolytic capacitors (being fluid filled burst or dry out), thermal flexing breaking solder joints, hardware assuming convection heating needing additional conduction cooling, vacuum allowing very large static charges to build up and then discharge across sensors and the radiation driven random faults and permanent failures in silicon.

$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.