La mayoría de las preguntas relacionadas con el uso de Linux son cubesat/space missions para la computadora de vuelo. Entiendo que se prefiere un RTOS a un Linux completo para una computadora de vuelo. Sin embargo, estoy interesado en saber cómo funcionaría una carga útil COTS basada en Linux como un Beaglebone Black o un Raspberry Pi en condiciones tan duras.
Los Raspberry Pi ciertamente se han diseñado en cubesats, pero no han rastreado ninguna lista general del número realmente lanzado, qué tan bien operaron o cualquier lección aprendida.
Las preguntas relacionadas incluyen esta sobre Pi y esta sobre diseño de código .
Las tres preguntas se superponen y se relacionan con el diseño de hardware. Del lado del hardware, la primera tarea es garantizar que la placa de CPU COTS presumiblemente no esté expuesta a entornos que la degraden/destruyan, principalmente al estabilizar la temperatura. La segunda parte es proporcionar un servicio de soporte sólido para la placa de la CPU: energía estable, protección de entrada (es mejor matar un búfer de entrada que toda la CPU), vigilancia y almacenamiento redundante y suficiente inteligencia para ejecutar las cosas mientras la CPU principal se está recuperando.
Reiniciar la CPU no ayuda directamente a la confiabilidad, pero el diseño debe asumir que la CPU podría reiniciarse en cualquier momento e incluir una ruta de recuperación para la mayor cantidad posible de estados de falla que vuelvan a funcionar, por lo que tener reinicios automáticos controlados por hardware es una solución integral. a los errores que bloquean la CPU en lugar de perseguir individualmente esos errores. Debe evitar seguir ciegamente este camino si los reinicios automáticos interrumpirán operaciones críticas como el aterrizaje . El proceso de reinicio también debe poder detectar y recuperarse de tantos tipos de corrupción de datos como sea posible, tanto los del entorno como los que quedaron en los datos antiguos cuando la versión anterior falló.
En términos de posibles puntos de falla, no parece haber un resumen disponible sobre las cosas que mataron a las placas COTS durante las pruebas. Los ejemplos anecdóticos incluyen capacitores electrolíticos (llenos de líquido que revientan o se secan), flexión térmica que rompe las uniones de soldadura, hardware que supone que el calentamiento por convección necesita enfriamiento por conducción adicional, vacío que permite que se acumulen cargas estáticas muy grandes y luego se descarguen a través de sensores y la radiación impulsada aleatoriamente fallas y fallas permanentes en el silicio.
Pedro