Robust and modular on-board architecture for future robotic spacecraft

Abstract

This paper presents a novel approach for future robotic spacecraft by utilizing a modular and robust software architecture based on the time and space partitioning (TSP) concept. Classic satellites are characterized by a strict separation between platform and payload subsystems, both in hardware resources as well as in control software. Novel space-robotic applications such as on-orbit servicing (OOS) feature dexterous robotic devices attached onto the satellite that impose a direct physical feedback on their floating base. Through the high degree of interdependencies, the whole satellite turns into a space robot. Hence, the robot becomes an integral part of the spacecraft itself and needs to be integrated into the existing control and operations approach. The developed embedded on-board framework represents a modular and robust control and communication environment that allows both classic satellite as well as real-time and autonomous robotic operations. The framework features an integral fault detection, isolation and recovery (FDIR) concept in order to prevent overall system shutdown upon single-point failure. Single software components reside in separate logical modules, i.e. partitions, in order to avoid resource violations. Upon critical failure, partitions can be restarted without detracting the rest of the system. By applying explicit time scheduling of partitions, system resources can be optimally distributed and deterministic behavior be achieved. Core system functionality has been implemented by ECSS-tested components that are configurable and thus re-usable over multiple missions. As demonstrator, a realistic on-orbit servicing simulation was set up that comprises autonomous target satellite capture and fault management. The presented architecture follows an integrated approach that is required for safely operating future robotic spacecraft. Through re-usability of software components, fewer resources for the implementation and verification process are required as only additional, mission-specific components need to be taken care of. Application developers can use the core functionality and communication API and concentrate on their own task at hand.