Abstract-The complexity of the avionic systems in satellites is rising as space missions become increasingly more sophisticated. This complexity emphasizes the need for more dependable systems with minimal anomalies. As satellite manufactures seek to convert many hardware implemented functionalities into software, the On-Board Software (OBSW) is becoming a major component in every satellite. Noticeably, more tasks for Fault Detection, Isolation and Recovery (FDIR) are being implemented in software, where the need comes for a well-defined software architecture that supports a cost-effective implementation of the FDIR functions. FDIR was already explained as key functionality of the OBSW. Obviously not all failures are subject to onboard identification and not all failures are subject to onboard recovery. The FDIR concept to be worked out for the spacecraft during the engineering phase follows some basic requirements and principles, implements a certain failure hierarchy-specifying furthermore on which level the failure is to be fixed-and finally it implements a consistent approach for the functionality transferring the spacecraft to Safe Mode and how to recover from there. Since a FDIR concept usually follows a hierarchical approach, in this paper we will indicate a FDIR and safeguarding hierarchy example in the paper. In this structure we will indicate the levels of failures which handled by unit internal, subsystem software, satellite system software, onboard computer hardware reconfiguration unit and ground. Also we will explain the FDIR hierarchy in safe mode implementation in a bit more detail. In this paper we will consider FDIR technologies in the On-board software in a satellite. Today, there are several proposed methodologies and frameworks which try to solve this problem. We will analyze the functionalities in FDIR Module implemented in an OBSW Framework. Also we have a survey on the FDIR hierarchies and their relationship to the Packet Utilization Standard (PUS) Services.
Fault tolerance is one of the critical issues in developing mission-critical software. Adding software fault tolerance (SFT) introduces additional complexity to software. In this paper we are going to evaluate Aspect Oriented Programming (AOP) for implementing SFT. AOP claims to facilitate its implementation by separating cross-cutting concerns such as fault tolerance. A few fault tolerance mechanisms were considered and implemented using AOP. Preliminary evaluation result of our experiences in using AOP for implementing SFT is offered in this paper.
scite is a Brooklyn-based organization that helps researchers better discover and understand research articles through Smart Citations–citations that display the context of the citation and describe whether the article provides supporting or contrasting evidence. scite is used by students and researchers from around the world and is funded in part by the National Science Foundation and the National Institute on Drug Abuse of the National Institutes of Health.
customersupport@researchsolutions.com
10624 S. Eastern Ave., Ste. A-614
Henderson, NV 89052, USA
This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.
Copyright © 2024 scite LLC. All rights reserved.
Made with 💙 for researchers
Part of the Research Solutions Family.