scieee AI-readable full text Open interactive document viewer

Reference Architecture for Autonomy and Adaptivity in Satellites - Replication Package

Brasil Rebelo dos Santos, Luciana; Basciani, Francesco; Pelliccione, Patrizio

Abstract

This repository contains the supporting material for the manuscript titled "Reference Architecture for Autonomy and Adaptivity in Satellites", currently under revision for the Journal of Systems and Software. Repository Content: File 1 - Protocol SLR - Reference Architecture for Autonomy and Adaptivity in Satellites - 1st round Review.xlsx: This data extraction worksheet presents the relevant data from the identified studies and provides the selection process in the systematic literature review, provided in the first stage of the research method: Problem Investigation. The main information reported in this worksheet summarizes the followed protocol, containing an identifier (id) for each returned study. The outcome of this SLR consists of 29 *selected studies* and information supporting the answers to three research questions: *RQ1*, *RQ2*, and *RQ3*. This catalog helped us in the data extraction and synthesis procedures and may be used by potentially interested, for example, for updating or replication. File 2 - Interview_Guide_Questionnaire.pdf: The questionnaire was developed to implement the third stage of the research method: Design Validation. This questionnaire was used to guide the interviews and also to ensure consistency between responses. It consists of 4 sections covering key aspects of the proposed reference architecture, namely: general applicability: aiming to analyse the generalization of the proposed architecture on different satellite platforms; autonomy and adaptability: aiming to assess if the RA embraces the characteristics required to provide autonomy and adaptability; technical robustness: aiming to assess the RA alignment with space industry standards and FDIR awareness; and practical use: scalability potential of the proposed RA. There is also space for interviewers to add comments in each section and at the end of the form. File 3 - Filled_Questionnaire_Interviewee_1.pdf: The questionnaire answered by interviewee 1, with the scores and comments. File 4 - Expert 1 Transcription.docx: The transcripts of the interviewee 1. The original language was not English, so we used OpenAI to generate the English version. File 5 - Filled_Questionnaire_Interviewee_2.pdf: The questionnaire answered by the interviewee 2, with the scores and comments. File 6 - Expert 2 Transcription.docx: The transcripts of the interviewee 2. The original language was not English, so we used OpenAI to generate the English version. File 7 - Filled_Questionnaire_Interviewee_3.pdf: The questionnaire answered by interviewee 3, with the scores and comments. Expert 3 did not authorize us to release the interviews, so we are not sending the transcripts.

Full text

Interviewee 1 Company Deleted for anonymity reasons Current Role Responsible for End-to-End Quality Assurance of Onboard Satellite Architectures Years of Experience 28 in this company and 20 In Software Quality Interview Date October 28, 2024 Interviewee 1 1 Reference Architecture for Autonomy and Adaptivity in the Space Domain The MAPEK cycle Monitor, Analyze, Plan, Execute, Knowledge) is a fundamental concept in our reference architecture for autonomous and adaptive space systems. In our context: Monitor:Continuously collects data from the satellite's sensors, subsystems, and the space environment. Analyze: Processes the collected data to identify anomalies, trends, or situations that require action. Plan: Develops strategies to address identified issues or optimize performance based on the mission objectives. Execute: Implements the planned actions, adjusting satellite operations or configurations as necessary. Knowledge: A central repository that stores historical data, mission parameters, and learned models to inform the decision-making process. This adaptation of the MAPEK cycle allows our space systems to autonomously respond to changing conditions, optimize resource usage, and maintain mission objectives with minimal ground intervention. Interviewee 1 2 Interviewee 1 3 Questionnaire for Validation of Reference Architecture for Autonomous and Adaptive Space Systems Instructions: We kindly request your feedback on the proposed reference architecture for autonomous and adaptive satellite systems. Please rate each statement on a scale of 1 to 5 1  Strongly Disagree, 5  Strongly Agree) and provide any additional comments or suggestions in the space provided. Section 1: General Applicability  The reference architecture applies to various satellite systems (e.g., GEO, LEO, MEO. 1  Strongly Disagree 2  Disagree 3  Neutral 5  Strongly Agree Comments: Assessment of criticality! It must be a mission that does not impact critical safety issues. In critical systems, safety-critical ML (Machine Learning) cannot be used!  The architecture is generic enough to be system-agnostic (not tied to a specific type of satellite system). 1  Strongly Disagree 2  Disagree 3  Neutral 4  Agree 4  Agree 5  Strongly Agree Interviewee 1 4 Comments: A generic and high-level architecture, which, until it is tailored to specific hardware, is agnostic.  The distinction between System Management and Services in the architecture is meaningful and useful. 1  Strongly Disagree 2  Disagree 3  Neutral 4  Agree Comments: If we give it a Critical  Non-Critical classification, then yes. The concept of dividing it into two categories is still useful. Section 2: Autonomy and Adaptability  The architecture's support for autonomous decision-making is welldeveloped. 1  Strongly Disagree 2  Disagree 3  Neutral 4  Agree Comments: Any suggestions to improve autonomy features?  The architecture effectively handles adaptability to changes in mission objectives or environmental conditions. 1  Strongly Disagree 2  Disagree 3  Neutral 4  Agree 5  Strongly Agree 5  Strongly Agree Interviewee 1 5 Comments: It needs to be understood in the context of services. If done well, it can be reused everywhere. A well-designed service component can be widely applied to different applications. Section 3: Technical Robustness  The reference architecture aligns with space industry standards (e.g., ECSS, SAVOIR. 1  Strongly Disagree 2  Disagree 3  Neutral 5  Strongly Agree Comments: If we add the critical - non-critical section, then yes. The management of ML Machine Learning) clearly defines this point. If placed in non-critical, it's fine.  The architecture can support the fault detection, isolation, and recovery FDIR mechanisms required for mission-critical operations. 1  Strongly Disagree 2  Disagree 3  Neutral 4  Agree Comments: Be careful with the use of ML in FDIR Fault Detection, Isolation, and Recovery); it is not prohibited, but it is only restricted if safety is involved or if there is the release of debris into space. There is actually an ESA regulation for this! 5  Strongly Agree 4  Agree 5  Strongly Agree Interviewee 1 6 See this link: https://technology.esa.int/page/space-debris-mitigation The presented architecture could also provide an enhancement in this sense with the use of ML (while complying with the regulations). Section 4: Practical Use and Future Improvements  The reference architecture provides a scalable solution for autonomous systems in satellite constellations. 1  Strongly Disagree 2  Disagree 3  Neutral 4  Agree Comments: How well would this architecture scale in large satellite constellations or multi-satellite missions?  The architecture uses the MAPEK feedback loop for monitoring, analyzing, planning, and execution, effectively handling real-time decision-making. 1  Strongly Disagree 2  Disagree 3  Neutral 5  Strongly Agree Comments: He/She didn't know it, but the understanding was easy.  The reference architecture is robust enough to serve as a standard for future autonomous and adaptive satellite missions. 1  Strongly Disagree 2  Disagree 3  Neutral 5  Strongly Agree 4  Agree Interviewee 1 7 4  Agree Comments: If the services section, the criticality, and the mechanism are properly analyzed, it's possible to adapt it to whatever we want, so yes. Additional Feedback: If you have any further thoughts or recommendations, please feel free to share them here. Comments after meeting: Based on the expert feedback, here's a summary of the main considerations: The distinction between critical and non-critical sections is crucial, replacing the existing division between System Management and Services. The architecture is generally applicable and sufficiently generic to be systemagnostic. The use of Machine Learning ML should be limited to non-critical parts of the system, especially regarding safety. The architecture aligns well with space industry standards but requires careful consideration when implementing ML in FDIR Fault Detection, Isolation, and Recovery) functions. The scalability of the architecture is considered a strength, especially for satellite constellations. The MAPEK model was well-received and considered effective for real-time decision-making. The architecture has the potential to become a standard for future autonomous and adaptive satellite missions, provided that the services component and criticality management are carefully analyzed. 5  Strongly Agree Interviewee 1 8 In conclusion, the main recommendation is to revise the architecture by clearly distinguishing between critical and non-critical components, ensuring that ML is used only in areas that are not critical to mission safety. Interviewee 1 9