Preliminary Design of Satellite Systems through the Integration of Model-Based System Engineering and Agile Methodologies: Application to the ³ColStar Mission

Abstract

This paper presents a case study on integrating Agile Systems Engineering methodologies in the preliminary design phase of satellite systems, focusing on the ³ColStar satellite mission. Through Model-Based Systems Engineering (MBSE), technical consistency was rigorously managed across various architectural documents, ensuring coherency and minimizing errors. Furthermore, the preliminary design was developed, with the implementation of the Arcadia Method, supported by the Capella modeling tool. This allowed the digitalization of the system, which was represented by models that contain requirements, architecture, and interfaces between the different parts of the system. At the same time, the preliminary design process was streamlined and completed within an accelerated time frame of 4 months, with weekly sprints driving progress based on the scrum methodology. This case study highlights the effectiveness of Agile Systems Engineering principles to improve the team communication accuracy, communication, and efficiency of satellite systems preliminary design, providing valuable insights for future missions.

1. Introduction

In the last decades, the field of small satellite engineering has undergone a transformative evolution, reshaping space science, communications, Earth observation, and education. This revolution has been facilitated by the widespread availability and miniaturization of low-cost electronics, coupled with increased launch opportunities [1]. What was once solely the domain of governments and large organizations has now been democratized, with small companies, universities, and even low- and middle-income countries actively participating in satellite development [2]. Despite this progress, many satellite missions continue to face challenges, including delays, budget overruns, and sub-optimal performance. In particular, university CubeSat teams, struggle with issues such as high turnover rates, knowledge management, and balancing academic coursework with project responsibilities [3,4].

In response to these challenges, there has been a growing interest in the adoption of Agile methodologies and Model-Based Systems Engineering (MBSE) techniques within the field of engineering and, more specifically, within the aerospace sector with small satellite design and development [5]. According to the International Council on Systems Engineering (INCOSE) [6,7,8], MBSE is the formalized application of modeling to support system requirements, design, analysis, verification and validation activities beginning in the conceptual design phase and continuing throughout development and later life cycle phases [9,10,11]. The impact and wide adoption of MBSE has led the community to even propose a roadmap that envisions that the “future of system engineering is model-based” to scale systems engineering by replacing document-oriented practices with models (see Figure 1). Some of the key concepts for Model-Based Systems Engineering are as follows [6,7,8,9]:

• Model-Centric Approach. This means that MBSE centralizes the development and documentation of systems around models, ensuring consistency and reducing redundancy.
• System Life Cycle Coverage. MBSE supports all phases of the system life cycle, from requirements analysis and design to verification, validation, and maintenance.
• Interdisciplinary Collaboration. Using MBSE facilitates a concurrent design process across different engineering disciplines by providing a common language and understanding of the system.
• Traceability. MBSE enhances traceability between requirements, design, implementation, and testing, ensuring that all aspects of the system are aligned.
• Analysis and Simulation. MBSE allows for early and continuous analysis and simulation, enabling engineers to identify and address issues early in the development process.

The aforementioned key concepts are substantiated by the findings in the existing literature [6,7,8,9,12,13] in this field, and have been integrated into well-established theoretical frameworks, such as those outlined by INCOSE [6,7]. Specifically, the frameworks utilized include Object-Process Methodology (OPM) [14], which combines graphical and textual representations of system processes and objects, Systems Modeling Language (SysML) [15], which provides various diagrams to represent different system aspects, and Arcadia/Capella, which focuses on the definition and validation of system architecture. Regarding the issues faced, previous authors encountered several significant challenges, including dynamic requirements, interdisciplinary collaboration, traceability and integration, and documentation overhead [16]. These issues were addressed by combining Agile approaches with MBSE techniques. Agile methodologies were chosen for their iterative development, stakeholder participation, improved collaboration, and rapid response to change [17]. These methods provide iterative and adaptable procedures that enable quick responses to changing requirements and stakeholder feedback. Agile methodologies operate on short, iterative development cycles, called sprints, allowing frequent reassessment and adjustment of the project. Regular meetings with stakeholders ensure continuous incorporation of feedback, while flexible planning and collaborative tools facilitate rapid responses to changes. Incremental delivery allows for continuous testing and validation, identifying and addressing issues early. By integrating these techniques, the study was able to overcome the challenges of traditional, document-oriented practices while also improving the effectiveness of system engineering processes. Our approach was compared to traditional Waterfall methodologies and other hybrid approaches, demonstrating greater flexibility and adaptability. Incorporating Agile approaches alongside MBSE not only facilitates iterative system development, but it also improves collaboration and traceability across interdisciplinary teams, as underlined by the INCOSE MBSE roadmap [6,7,8,12,13]. This integration means that all stages of the system life cycle benefit from ongoing improvement and adaptation to changing project requirements. We define the system life cycle according to the INCOSE Systems Engineering Handbook and ISO/IEC/IEEE 15288:2015 standards [18], acknowledging that this version has been withdrawn and superseded by the revision project of IEEE Standard 15288-2008 [19], encompassing stages from conceptual design, system design and development, implementation, integration and testing, deployment, and operation and maintenance to disposal. Verification and validation are integral activities conducted throughout these stages to ensure the system meets both design specifications and stakeholder requirements.

As shown in Figure 1, the transition to the future of systems engineering will predominantly rely on models, leveraging next-generation modeling, simulation, and visualization environments. Techniques in artificial intelligence and data science are expected to significantly enhance the efficiency and effectiveness of systems engineers. According to the INCOSE Vision 2035 [12,16], significant advancements are anticipated in digital transformation, flexible and resilient system architectures, and the integration of human systems. These trends encompass the shift from document-centric practices to model-centric approaches, which are deemed essential for scaling systems engineering. Digital transformation underscores the importance of digital ecosystems and collaborative virtual environments for real-time model updates and simulations. Furthermore, collaboration across different engineering disciplines will be enhanced through shared models and mutual understanding. Lastly, addressing the need for continuous education is crucial to meet the demand for technically proficient systems engineers with leadership capabilities.

Combining Agile methodologies and MBSE is consistent with industry trends in aerospace and other engineering fields, where systems’ complexity and safety-critical nature require Agile and model-centric techniques for effective development and management. Early systems engineering approaches in aerospace often involved extensive documentation and manual processes. However, the adoption of MBSE in aerospace has been bolstered by the development of standards and frameworks [20,21], such as the Object Management Group’s (OMG’s) Systems Modeling Language (SysML) [22,23,24], and the Department of Defense Architecture Framework (DoDAF) [25,26]. Nowadays, aerospace companies use MBSE to design, analyze, and manage complex systems, including aircraft, spacecraft, and avionics. MBSE helps ensure that the systems meet stringent performance, reliability, and safety requirements.

Concerning Agile methodologies, these were originally developed for software development [27], emphasizing the iterative and adaptive nature of software creation and enabling teams to respond rapidly to changing requirements and feedback from stakeholders. A careful review of the current state of the research field reveals a growing body of literature exploring the application of Agile methodologies and MBSE in various engineering domains, including aerospace and satellite systems. Key publications [28,29,30,31] have shown the benefits of adopting these approaches, highlighting their effectiveness in managing complexity, mitigating risks, and improving project outcomes. This shift towards agility in engineering processes is promising for streamlining workflows, optimizing resource allocation, and improving overall project outcomes, particularly within the dynamic context of small satellite development [1].

In this paper, we explore how an integrated approach to Agile Systems Engineering and Project Management can address the unique challenges faced by small satellite engineering teams, and in particular for the “³ColStar” mission. Through a detailed examination of the “³ColStar” mission, developed collaboratively by the Colombian Aerospace Force (COLAF), Colombian universities, and other international institutions, our study demonstrates the application of Agile methodologies and MBSE in the optimization of the development process. For instance, small satellite missions operate in dynamic contexts where it is crucial to adhere to “frozen specifications”. This ensures stability and consistency despite the quickly changing requirements due to technical breakthroughs and evolving user needs. Agile techniques enable adaptations to these changes through iterative development cycles and constant stakeholder interaction [32]. Additionally, small satellite projects are often limited in terms of funding, personnel resources, and timescale. Iterative planning, frequent deliverables, and prioritization are examples of Agile approaches that help to improve resource allocation and maximize efficiency in managing limited resources [33,34]. Furthermore, the complexity to integrate multiple subsystems in small satellites while maintaining compatibility, functionality, and reliability presents considerable technical obstacles. Agile Systems Engineering stresses incremental integration and continuous testing, therefore decreasing the risks involved with subsystem integration [35]. Moreover, many small satellite projects require geographically scattered teams from several locations, countries, and time zones. For this, Agile techniques encourage good communication, collaboration technologies, and remote work practices to guarantee smooth coordination and alignment among distributed teams [36,37].

The literature supports the efficacy of Agile Systems Engineering (SE) and Project Management (PM) in tackling these issues. Agile approaches improve flexibility, responsiveness, and adaptation in engineering projects, particularly in the aerospace and satellite sectors [5,38,39]. Teams can reduce risks, expedite development timeframes, and improve overall project outcomes by implementing Agile principles tailored to the unique needs of tiny satellite missions. For instance, Honoré-Livermore [5] reported that using Agile methods reduced the time between mission concept definition and launch, and in our case, Agile methods were useful to reduce the mission design time.

The use of these methodologies facilitates accelerated time-to-market time frames, reduces costs, and fosters innovation within the small satellite industry, paving the way for future advancements in CubeSat technology. The benefits of integrating Agile methodologies with MBSE are substantiated by both empirical evidence and theoretical insights from the existing literature. Smith et al. (2019) [40] documented a 25% reduction in development time for a small satellite project utilizing Agile practices compared to traditional methods. Similarly, another study [41] reported a 30% cost reduction in aerospace projects that implemented Agile and MBSE approaches. Furthermore, Garcia et al. (2020) [42] found that Agile methodologies significantly enhanced the rate of innovative solutions among project teams. These findings align with the theoretical foundations of Agile and MBSE, which emphasize iterative development cycles, continuous stakeholder engagement, and adaptive planning. These practices collectively contribute to the observed improvements in development speed, cost efficiency, and innovative capacity.

The requirements for the ³ColStar satellite mission changed dynamically throughout its development, reflecting its iterative and flexible nature and the need for an iterative approach such as the Arcadia methodology. This strategy enabled our team to respond quickly to evolving technological, operational, and stakeholder requirements. For example, the initial technical specifications were modified through subsystem tests and simulations, resulting in changes to payload configurations and communication protocols. The adaptability provided by the Arcadia technique was critical in successfully accepting these adjustments. By encouraging regular contact and collaboration among geographically distributed team members, Arcadia facilitated streamlined workflows and faster decision-making. This allowed us to maintain technical accuracy while reducing errors throughout mission development. In comparison, without an Agile methodology like Arcadia [11], the iterative nature of requirement changes and their implications for design, integration, and validation phases would have been significantly more difficult to manage within the recommended project planning durations outlined by the European Cooperation for Space Standardization (ECSS) [43], NASA [44], and JAXA [45] standards. The capacity to respond swiftly to changing needs highlights the value of Agile techniques in optimizing resource allocation and enhancing overall project outcomes in small satellite missions.

This article is organized as follows: Section 2 provides a description of the ³ColStar KiboCUBE Colombia mission and the Concept of Operations. Section 3 contains the concepts of MBSE, Arcadia Method, and Capella software (version 6.1). Section 4 explains the ³ColStar KiboCUBE Systems Engineering Structure by applying the Agile methodology with Arcadia Method and Capella modeling tool. Finally, Section 5 and Section 6 summarize the discussion and conclusions.

This proposal has been pre-selected as a finalist for the 8th KiboCUBE round [46].

2. The ³ColStar Satellite Mission

The “³ColStar KiboCUBE Colombia” CubeSat (1U) mission emerged from the ambitious initiative to design a satellite manufactured up to 70% in Colombia. The ³ColStar mission aims to produce reliable solar weather data through its primary payload and demonstrate the functionality of an IoT payload in space. This mission stands out for its unique dual focus on solar weather monitoring and IoT integration on a small satellite platform. In contrast, existing missions in the literature often prioritize either scientific data collection or technical demonstration, rarely addressing both simultaneously. For instance, missions focused on scientific data collection include those described by Smith and Roberts (2018) [47], which emphasize methodologies and technologies for effective data gathering. On the other hand, missions centered on technical demonstration are detailed by Johnson and Martinez (2019) [48], who discuss the evaluation of new technologies. There are fewer examples of missions that integrate both scientific and technical goals. Brown and Lee (2020) [49] explore such missions, demonstrating the challenges and advantages of addressing both objectives within a single mission framework.

The dual-purpose approach of ³ColStar offers distinct advantages by leveraging satellite resources for a diverse range of scientific and technological objectives. One of the primary scientific objectives is the study and analysis of space weather phenomena. Space weather refers to the environmental conditions in space as influenced by the sun and the solar wind. These phenomena, including solar flares and cosmic rays, can have significant effects on satellite operations, GPS systems, and even terrestrial power grids. In Colombia, studying space weather is particularly crucial due to the country’s geographical location near the equator. This region is more susceptible to ionospheric phenomena such as the Appleton Anomaly or Equatorial Anomaly, which can significantly affect communication and navigation systems [50,51,52]. The Equatorial Anomaly, characterized by high electron density in the ionosfera approximately 15 degrees north and south of the magnetic equator, can cause ionospheric scintillation, potentially disrupting radio and GPS signals. While Colombia is not directly in the center of the South Atlantic Anomaly (SAA), the southern part of the country may experience some effects of this phenomenon, as it is located on the northern periphery of the SAA’s area of influence. The SAA is a region where the Earth’s magnetic field is weaker, primarily centered over Brazil and the South Atlantic Ocean. By advancing our understanding of space weather, the ³ColStar mission aims to improve the resilience and reliability of these critical systems in Colombia and similar regions [53]. Furthermore, the ³ColStar mission includes a secondary IoT payload aimed at providing internet access to remote areas where connectivity is scarce. This objective is critical for enhancing internet usage across the majority of regions in Colombia, promoting digital inclusion, and supporting the socio-economic development of underserved communities. Additionally, the mission seeks to develop and integrate locally manufactured space components and subsystems, such as the structure, EPS (Electrical Power System), OBC (On-Board Computer), ADCS (Attitude Determination and Control System), and electronics. These advancements not only contribute to scientific knowledge but also foster technological innovation and collaboration among Colombian academia, industry, and government.

This pioneering endeavor was made possible through the KiboCUBE call, organized jointly by the Japan Aerospace Exploration Agency (JAXA) and the United Nations Office for Outer Space Affairs (UNOOSA) [46]. This initiative provided an unvaluable opportunity to develop a CubeSat and deploy it from the Japanese module “Kibo” onboard the International Space Station (ISS), thereby contributing to the sustainability and advancement of future space activities.

Based on the KiboCUBE opportunity, the constraints for the mission are [46]:

• The satellite must be fully tested for the launch procedure according to the JAXA JEM Payload Accommodation Handbook [54].
• Deployment from the Kibo module in the ISS determines the mission orbit (semi-major axis, eccentricity, inclination, and argument of perigee). For the ³ColStar, the ground segment has been developed around multiple locations to fulfill the payload’s objectives and the orbit based on the ISS orbital elements. The ground segment is designed for academic purposes, allowing universities with these capabilities to participate actively by utilizing the ground stations. This method facilitates regular satellite connectivity for uploading communication codes, downloading data from the primary weather sensor payload, and managing the secondary IoT payload. The main monitoring and communication station will be centrally located in Bogotá to oversee these operations effectively.
  To ensure that the communications between the spacecraft and the different ground stations were correctly estimated, an orbital simulation of the mission profile was executed by using an astrodynamics propagator (NASA GMAT) [55]; to calculate the number of contacts, duration, range, and mission lifetime (re-entry) for the space debris simulation, we used the DRAMA (Debris Risk Assessment and Mitigation Analysis) ESA software (version 3.1.0) [56].
  To validate the mission, multiple orbital simulations were conducted based on possible future launch dates. These simulations were designed to compare the computational performance of ³ColStar with previous CubeSat missions and to evaluate its behavior under various space conditions. In the case of the ³ColStar CubeSat, using a simulated launch date, the duration until reaching the same End of Life (EoL) altitude was estimated to be 238 days, based on numerical integration errors from the propagator steps and computational models of atmospheric drag (initial satellite altitude (ISS) (km): 416.016; final satellite altitude (EoL) (km): 161.298). This estimation of perturbations is the result of a static MSISE90 model implemented in the simulation, the ideal spherical model for solar radiation pressure, and the J2 mathematical gravity perturbation (see Figure 2). These simulations not only validate the computational models against realistic scenarios but also ensure robust mission planning and execution.
  Since the mission operations will be located in Colombia (Colombian Air Force SpOC), and due to its proximity to the Equator (0° latitude), the number of contacts will be significantly reduced during mission operation. Based on our simulations for the expected lifetime of the ³ColStar mission (see Figure 2), the summary of the ground stations’ contacts are as follows: the number of contacts with the satellite is 572; the average contact time with the satellite is 284.745 [s].
• The size of the CubeSat must not exceed the 1U standard (Figure 3a,b).
• Hazardous materials must not be used on the satellite, since it will be deployed from a space crewed research facility such as the ISS.
• The expected profile of stakeholders is composed of government organizations, research institutes, universities, and other public organizations.

Equipped with two payloads, this CubeSat aims to advance both scientific understanding and technological capabilities. The primary payload is the MiniPIX TPX3 SPACE sensor device [58], a compact radiation camera engineered specifically for space missions. This device is designed to fit within the CubeSat’s 1U platform, offering advanced particle tracking capabilities with minimal power consumption and mass. Its main role is to monitor particles generated by solar storms, which is crucial for evaluating potential impacts on essential infrastructure such as power grids, communication networks, and satellites [58].

The MiniPIX TPX3 SPACE, provided by ADVACAM, excels in high-resolution particle characterization and real-time data analysis. These capabilities are central to meeting the mission’s scientific objectives. Specifically, the device enables detailed observations of particle behavior and dynamics during space weather events, which is vital for understanding the interactions between solar particles and the Earth’s magnetic environment. By delivering precise and timely data, the MiniPIX TPX3 SPACE not only ensures that the mission’s objectives are achieved but also enhances the mission’s effectiveness in addressing critical scientific questions and practical challenges associated with space weather [57]. In this context, “fulfilling the objectives” refers to achieving the specific goals of data collection and analysis, while “enhancing an objective” means improving the quality and impact of these efforts, thereby elevating the overall success and utility of the mission.

Additionally, the CubeSat will incorporate a secondary payload comprising an IoT device designed for data transmission to a mobile ground station. This facilitates analysis and risk control. Furthermore, the satellite features an in-house developed Fine Sun Sensor, and a proof-of-concept for the research and development of a reaction wheel and magnetorquers [57].

These in-house developments are the evidence of the proof of the collaboration between academia, industry and government. As the structure, IoT and magnetorquers stem from engineering models developed by SpaceTech AESS Uniandes and its start-up NovaOrigin and COCSA-SPACE acceleration scheme.

2.1. Concept of Operations (ConOps)

The ³ColStar mission encompasses several key elements essential for its success, outlined here to provide a comprehensive understanding [57] (Figure 4):

• Users and Technology Transfer: This aspect involves various participating institutions facilitating technology transfer. Additionally, end-users will benefit from data generated by the space weather sensor and IoT information, particularly in remote areas for precision agriculture.
• Primary and Secondary Payloads: The efficient operation entails the scheduled utilization of the space weather sensor as the primary payload, and the IoT module with store and forward process as the secondary payload.
• Satellite Platform: The mission includes a 1U satellite with all necessary systems (Structure and Mechanical, Power System, Communication, Command and Data Handling (C&DH), ADCS, Thermal Control, and Onboard Computer and Software).
• Ground Station: The communication infrastructure is established through a network of ground stations to facilitate efficient and continuous communication with the satellite.
• Orbital Parameters: The satellite is expected to be launched from Kibo port of ISS to perform a LEO.

  Table 1. Environment orbit parameters.

  Perigee height	400–460 Km
  Eccentricity (e)	0.0008103
  Inclination (i)	51.63°
  RAAN	174.97°
  Orbital period	91–94 min

  shows the environment orbit parameters.
• Mission Operations: The mission is structured into four distinct stages to ensure systematic execution (Figure 4):

Furthermore, the mission is structured into four distinct stages to ensure a systematic execution (Figure 5):

• Launch (Figure 5a) and Early Orbit Phase (LEOP) Operations (Figure 5b): Includes initial satellite operations post-launch, establishing contact with ground stations, and conducting Early Operation Tests. The ground stations of the participating universities and the COLAF located in different parts of Colombian territory are planned to be used for this mission. The first one is located at the Colombian Air Force Space Operations Center (Spoc) in the city of Cali. Additionally, the other points of contact between the satellite and the ground will be the ground stations of the universities participating in the project, which are located in the city of Bogotá (Universidad Distrital, Universidad Sergio Arboleda), Universidad de Antioquia (Medellin), and in the city of Sogamoso (Universidad Pedagógica y Tecnológica de Colombia).
• Initial Operations (IOP) (Figure 5c): Starts after satellite stabilization, focusing on the initial operations of payloads.
• Full Operations (FOP) (Figure 5d): The satellite enters in its nominal operational phase, executing payload activities and data download.
• Decommissioning (DECO) (Figure 5e): The satellite is safely passivated and manages the end of its useful life through systematic shutdown procedures.
  Each stage is further defined by specific operational modes tailored to various scenarios. For each stage established, some modes of operation have been established, which are mentioned below:

• Standby (Sb): Period before the satellite is turned on. All subsystems are inactive.
• Released (R): After the standby period, the satellite is turned on, with the EPS and OBC as the only active subsystems.
• Pre-detumbling (PD): UHF antennas are deployed, the EPS, OBC, COMMS and ADCS (only determination for telemetry) are active. The COMMS subsystem starts transmitting beacon.
• Detumbling (D): Same as the pre-detumbling state, with the magnetorquers operating.
• Detumbled (Dd): Once the satellite is detumbled, the ADCS is keeping the desired attitude. The COMMS subsystem is transmitting beacon.
• Basic (Ba): The satellite transmits telemetry exclusively.
• Nominal (N): Satellite is fully operational. The COMMS subsystem is transmitting scientific data in the following scenarios:

  –

  Nominal IoT Dowlink (Nid): IoT application data download.

  –

  Nominal IoT Uplink (Niu): Receiving data from the IoT ground sensors.

  –

  Nominal Space Weather (Ns): Nominal operation of the Space Weather payload (ON).

  –

  Nominal Space Weather Dowlink (Nsd): Space Weather payload data download.

• Sun Safe (SS): If the battery levels become critically low (below 1.5 V, see

  Table A4. Other modes.

  	Sun Safe (SS)			Survival (Sv)			Satellite Off (OFF)			Decommissioning (DC)
  Subsystems	P (W)	t (min)	E (Wh)	P (W)	t (min)	E (Wh)	P (W)	t (min)	E (Wh)	Transm	t (min)	E (Wh)
  OBC	0.2	92.5	0.308	0.2	92.5	0.308	0.2	92.5	0.308	0.2	92.5	0.308
  EPS: converters, MCU, batteries, heater	0.26	92.5	1.201	0.26	92.5	1.201	0.26	92.5	1.201	0.26	92.5	1.201
  Deployable Antenna System	0	0.0	0.000	0	0.0	0.000	0	0.0	0.000	0	0.0	0.000
  Deployable Solar Pannels				0	0.0		0	0.0	0.000	0	0.0	0.000
  ADCS Board and sensors	0.3	92.5	0.462	0.3	92.5	0.462	0.3	92.5	0.462	0.3	0.0	0.000
  ADCS magnetorques	0.55	92.5	0.848	0.55	92.5	0.848	0.55	92.5	0.848	0.55	92.5	0.848
  COMMS: TTC - Payload IoT_SW_	0.2	12.0	0.317	5.35	12.0	1.347	0.2	12.0	0.317	5.35	12.0	1.353
  Payload Weather solar_Sensor	0	0.0	0.000	0	30.0	0.000	0	30.0	0.000	2.5	0.0	0.000
  Payload Electronic SW	0	92.5	0.000	0	92.5	0.000	0.2	92.5	0.308	0.2	92.5	0.308
  Payload Single reaction wheel	0	92.5	0.000	0.15	10.0	0.031	0.15	15.0	0.038	0.15	0.0	0.000
  Payload fine sun sensor	0	92.5	0.000	0.01	92.5	0.015	0.01	0.0	0.000	0.01	0.0	0.000
  GPS _Antenna	0	0.0	0.000	0	0.0	0.000	0	0.0	0.000	0	0.0	0.000
  TOTAL	1.510		3.136	6.82		4.212	1.87		3.482	9.52		4.019

  ), the satellite enters this mode. From the power budget point of view, this mode is identical to the Dd mode.
• Ground Mode (GM): Mode designed for ground testing, but also accessible in orbit. No limitation in terms of function execution, designed for contingency scenarios. It gives to the operator a total control of the spacecraft.
• Survival (Sv): After an unexpected anomaly, the satellite enters in this mode. The payloads are disabled, the ADCS kepts the desired attitude, and COMMS transmits scientific data.
• Satellite Off (OFF): Satellite is turned off during its operation due to unexpected events. EPS, OBC and COMMS are ON. The satellite will receive TCs from ground.
• Decommissioning (DC): The satellite is deactivated and safely manage the end of its useful life. Typical activities in Decommissioning mode include:

  –

  Systems Decommissioning: The satellite’s operating systems, such as scientific instruments, transmitters, and other electronic components, are shut down in an orderly fashion [59].

  –

  Battery Passivation: Batteries are discharged to minimize the risk of explosions or malfunctions that could generate more space debris.

  –

  Final Transmission and Power Shutdown: A final transmission is sent and then the satellite power is permanently shut down, disconnecting the solar panels from the EPS.

2.2. ³ColStar Main Requirements

The ³ColStar mission success criteria were developed to delineate both the high-level needs and the specific requirements necessary for mission success. In this context, needs refer to the overarching objectives the mission aims to achieve, such as advancing scientific knowledge, promoting technological innovation, and generating societal benefits. Conversely, requirements are the precise, measurable conditions derived from these needs that guide the design, development, operation, and evaluation of the satellite system.

For example, one high-level need is to enhance Colombia’s capabilities in space technology. To address this need, the corresponding requirements include the development and integration of locally manufactured space components and subsystems. These components encompass the satellite’s structure, Electrical Power System (EPS), On-Board Computer (OBC), Attitude Determination and Control System (ADCS), and associated electronics. Each requirement specifies detailed performance criteria to ensure that these components fulfill their intended functions effectively.

Another critical need is to foster collaboration among academia, industry, and government entities. The associated requirements entail formalizing partnerships with 13 institutions and implementing structured mechanisms for communication and coordination. These mechanisms include regular meetings, the establishment of shared documentation protocols, and the synchronization of project timelines. Such requirements are designed to ensure that collaborative efforts are systematically managed and contribute to the mission’s overall success. Additionally, the need to deliver educational and social benefits is translated into requirements such as the installation of IoT connection points in remote areas and the integration of mission results into educational programs. These requirements ensure that the mission’s outcomes are leveraged for community and educational advancements, aligning with the mission’s broader objectives. By clearly defining these needs and translating them into specific, quantifiable requirements, the ³ColStar mission ensures that each aspect of the project is aligned with its strategic goals. This approach facilitates a systematic and rigorous process for designing, developing, and evaluating the satellite system, as detailed in

Table A1. ³ColStar requirements.

Requirements	Description
Mission Requirements
PrimMis-001	In nominal mode, the satellite will have 30 min of activation in which it will collect 197 MB corresponding to the sensor images for space radiation; the sensor will make a total of 1800 images during this mode.
PrimMis-002	The information vector must be transmitted using the satellite’s communication frequency (amateur radio band).
PrimMis-003	We will develop and deploy a CubeSat capable of performing solar observations, focusing on the measurement of solar wind particles and IoT sensors.
SecmMis-001	We will establish partnerships with local industry stakeholders to promote knowledge exchange and resource sharing in space technology and IoT.
CubeSat Design
Des-001	The satellite should be able to store the 197 MB of the solar weather sensor and the 90 MB generated by the IoT payload.
Des-002	The project will develop a flight-enabled CubeSat capable of being launched from the International Space Station.
Des-003	The project shall comply with the safety standards of the International Space Station NSTS SSP 51700.
Ground Segment Design
GSeg-001	Technology will be developed by the partner universities for narrowband transmission of IoT data for the Ground Satellite to Satellite uplink and Node IoT to Satellite.
GSeg-002	The satellite shall have commands defined for the control of georeferenced telemetry and for monitoring satellite subsystems.
GSeg-003	The ground station will have to operate in UHF band complying with the requirements, especially the transmission power regulated by the government, to guarantee the correct access of the satellite. The communication subsystem shall have the ability to send and receive satellite data for both the IoT and the payload with the minimum error rate allowed and with a frequency within the amateur radio band.
User Segment Design
USeg-001	User segment components for NB-IoT technology shall be designed with modularity and upgradability in mind, allowing for future enhancements and adaptability to evolving mission needs.
USeg-002	The space weather sensor should collect data in a format that universities and students can easily interpret and use for scientific research.
USeg-003	Implement robust cybersecurity measures to safeguard transmitted and stored data, ensuring confidentiality for both agricultural users’ operational information and scientific research data from universities.
Operation
Ope-001	The satellite should be able to delete the stored data from the solar sensor and IoT module measurements and be ready for new storage.
Ope-002	The Cubesat shall function in various operational modes (e.g., data collection mode, transmission mode, power-saving mode) as per mission requirements.
Ope-003	The CubeSat must be capable of having controlled activation and deactivation to conserve power and operate efficiently as needed.
Launch
Laun-001	The deployment platform for small satellites, utilizing J-SSOD [59], specifies the requirements for launching a 1U satellite from the Japanese Kibo module of the International Space Station (ISS).
Laun-002	Satellite Size: The platform accommodates CubeSats of 1U size, measuring approximately 10 × 10 × 10 cm.
Laun-003	Satellite Mass: For a 1U CubeSat, the mass is limited to 1.33 kg or less.
Laun-004	Orbital Altitude: The satellite is deployed at an altitude approximately between 380 and 420 km above Earth’s surface.
Laun-005	Inclination: The deployment orbit maintains an inclination of 51.6° relative to the equator.
Laun-006	Deployment Direction: Deployment occurs in the Nadir-aft direction, which is 45° from the ISS nadir side.
Laun-007	Deployment Velocity: The deployment velocity for a 1U CubeSat ranges from 1.1 to 1.7 m/s.
Laun-008	Ballistic Coefficient: The platform ensures a ballistic coefficient of 100 kg/m2 or less to facilitate safe deployment.

(Appendix A).

2.3. Preliminary Design

The preliminary design process for each subsystem of the satellite platform adhered to a systematic approach that aligned closely with mission requirements. This approach ensured that each subsystem was designed to meet specific functional and performance criteria outlined in the mission objectives. Although actual manufacturing of the subsystems has not yet started, comprehensive design activities were undertaken to lay a solid foundation for future development and integration. This involved an integrated, yet individually focused, subsystem design strategy that fostered effective collaboration among the subsystems. Weekly meetings with all subsystem teams facilitated the resolution of cross-functional issues and ensured cohesive problem-solving across all components.

Regarding the comparison with concurrent methodologies, our approach for the preliminary design was selected for its emphasis on sequential development, which was deemed suitable for ensuring thorough validation and alignment with mission specifications. This decision was guided by several considerations:

• Validation and Verification: The sequential approach allowed for a detailed analysis and validation of each subsystem’s functionality before progressing to the next phase. This was crucial for ensuring that each subsystem met its requirements and integrated smoothly with others, thus reducing the risks associated with subsystem interactions and performance.
• Risk Management: By focusing on sequential development, risks could be managed more effectively. Each subsystem’s design and performance were thoroughly validated before advancing to integration, minimizing the potential for issues during later stages of development. The sequential approach provided a controlled environment for identifying and addressing potential problems early in the design phase.
• Documentation and Configuration Management: The sequential approach facilitated rigorous documentation and configuration management. Detailed development information for each subsystem was meticulously recorded and updated in a common online repository, ensuring that all stakeholders had access to the most current data. This practice helped mitigate risks related to discrepancies and promoted efficient integration once subsystem manufacturing and assembly commenced.

To effectively manage and monitor these design activities, MBSE methodologies were employed. The MBSE approach utilized SysML and Arcadia/Capella frameworks, which provided structured methods for modeling system requirements, architecture, and interactions. By integrating these models into a cohesive system architecture, MBSE enabled early identification of design issues and ensured alignment with mission requirements. Iterative design processes supported by MBSE facilitated simulations and validations, helping to refine subsystem designs and manage risks before physical implementation. Additionally, MBSE tools enhanced documentation and configuration management, ensuring consistent, traceable, and up-to-date information across all design phases.

While concurrent methodologies offer advantages such as parallel development and accelerated integration, the sequential approach was deemed more suitable for the preliminary design phase due to its focus on validation and risk mitigation. The integration of MBSE further strengthened this approach, providing a robust framework for systematic design and development. Future projects may benefit from exploring concurrent methodologies to enhance development efficiency, but the current approach provided a solid foundation for ensuring mission success.

This section centers on individual subsystem designs aimed at elucidating specific characteristics of each subsystem envisioned for this mission. Next, in Section 3, we will provide a detailed account of our approach using the Capella tool and Arcadia method. Specifically, we will illustrate the systematic progression from requirements to functional, logical, and physical architectures. This will encompass a step-by-step explanation of how each architectural level was developed, ensuring traceability and alignment with mission objectives throughout the design process.

2.3.1. Electric Power Systems-Power Budget

The power budget computes the power and energy demand; energy generation; storage; distribution, monitoring and control. Based on the technical information provided by the manufacturers,

Table 2. Power consumption for standby and operative modes (W).

	Power by Operating Mode (W)					Power (W)
Subsystem	Standby	Recharge	Reception	Transmission	P_Solar Wheater	Min_Standby	Typ.	Max.
OBC [60]	0.2	0.2	0.2	0.2	0.2	0.20	0.20	0.20
EPS [61]: converters, MCU, batteries, heater	0.26	0.26	0.26	0.26	0.26	0.26	0.26	3.26
Deployable Antenna System [62]	0.04	0.04	0.04	0.04	0.04	0.00	0.04	2.00
ADCS Board and sensors [63]	0.3	0.3	0.3	0.3	0.3	0.00	8.50	8.84
ADCS magnetorques [63]	0	0.55	0.55	0.55	0.55	0.30	0.30	0.30
COMMS_Payload IoT SW [64]	1.4	1.4	2.12	5.35	1.4	0.00	0.55	0.55
Payload Weather solar [58]	0	0	0	0	2.5	0.20	2.12	5.35
Payload Electronic WS [58]	0.2	0.2	0.2	0.2	0.2	0.00	1.50	2.50
Payload Single reaction wheel [65]	0.045	0.045	0.045	0.045	0.045	0.20	0.20	0.20
Payload fine sun sensor [66]	0.0025	0.01	0.01	0.01	0.01	0.05	0.15	3.25
GPS [67]	0	0	0	0	0	0.00	0.01	0.01
TOTAL	24.475	3.005	3.725	6.955	5.505	0.17	0.17	0.19
Energy per orbit Wh (IoT OFF/ON_12 min)	2.70	3.57			3.79
Energy per orbit Wh 30 min solar	4.59	5.46	3.71	4.36	6.71

Note: Standby: Receive only. Not oriented. Recharge: Receive only and oriented with magnetorquers. Reception and Transmission: In reception, 12 min (7 + 5), oriented with magnetorques and reaction wheels. TTC or IoT. Solar: solar particle sensing 30 min. Deployment: power-up, panel deployment and stabilization.

,

Table 3. Pmax (W) with Deplotable solar panels.

Configuration	Mode	Energy Per Orbit [Wh]	Pmax (W)	Efficiency (Wh) 90%
Using Depoyable Panels	Sun Pointing	6.47	6.84	5.82
	Nadir Pointing	2.72	3.54	2.45
No Deployable Panels	Sun Pointing	2.11	2.23	1.90
	Nadir Pointing	2.32	3.11	2.09

Note: Battery capacity: 1300 mAh, 7.4 V.

and

Table 4. Results of maximum power demand by subsystem and modes per time.

Mode	Power (W)	Energy (Wh)
Standby (Sb)	0	0
Released (R)	9.00	1.58
Pre-detumbling (PD)	6.11	3.04
Detumbling (D)	6.66	4.17
Detumbled (Dd)	6.66	4.17
Basic (Ba)	7.19	4.53
Nominal IoT DL (Nid)	7.19	4.08
Nominal IoT UL (Niu)	3.43	2.77
Nominal SW (Ns)	4.54	5.09
Nominal SW DL (Nsd)	7.19	4.08
Sun Safe (SS)	1.51	3.14
Ground Mode (GM)	7.02	3.25
Survival (Sv)	6.82	4.21
Satellite Off (OFF)	1.87	3.48
Decommissioning (D)	9.52	9.60

, and

Table A2. Launch and early orbit phase.

	Released (R)			Pre-Detumbling (PD)			Detumbling (D)			Detumbled (Dd)			Basic (Ba)
Subsystems	P (W)	t (min)	E (Wh)	P (W)	t (min)	E (Wh)	P (W)	t (min)	E (Wh)	Transm	t (min)	E (Wh)	P (W)	t (min)	E (Wh)
OBC	0.200	92.5	0.308	0.2	92.5	0.308	0.2	92.5	0.308	0.2	92.5	0.308	0.2	92.5	0.308
EPS: converters, MCU, batteries, heater	0.260	92.5	1.201	0.26	92.5	1.201	0.26	92.5	1.201	0.26	92.5	1.201	0.26	92.5	1.201
Deployable Antenna System	0.040	2.0	0.001	0	0.0	0.000	0	0.0	0.000	0	0.0	0.000	0	0.0	0.000
Deployable Solar Pannels	8.000	0.5	0.067	0	0.0	0.000	0	0.0					0	0.0
ADCS Board and sensors	0.000	0.0	0.000	0.3	92.5	0.462	0.3	92.5	0.462	0.3	92.5	0.462	0.3	92.5	0.462
ADCS magnetorques	0.000	0.0	0.000	0	0.0	0.000	0.55	92.5	0.848	0.55	92.5	0.848	0.55	92.5	0.848
COMMS: TTC - Payload IoT_SW_	0.000	0.0	0.000	5.35	12.0	1.070	5.35	12.0	1.347	5.35	12.0	1.347	5.35	12.0	1.347
Payload Weather solar_Sensor	0.000	0.0	0.000	0	0.0	0.000	0	0.0	0.000	0	0.0	0.000	0	30.0	0.000
Payload Electronic SW	0.000	0.0	0.000	0	0.0	0.000	0	0.0	0.000	0	92.5	0.000	0	92.5	0.000
Payload Single reaction wheel	0.000	0.0	0.000	0	0.0	0.000	0	0.0	0.000	0	92.5	0.000	0.15	10.0	0.031
Payload fine sun sensor	0.000	0.0	0.000	0	0.0	0.000	0	0.0	0.000	0	92.5	0.000	0.01	92.5	0.015
GPS_Antenna	0.000	0.0	0.000	0	0.0	0.000	0	0.0	0.000	0	0.0	0.000	0.171	5.0	0.014
TOTAL	8.500		1.577	6.11		3.041	6.66		4.166	6.66		4.166	6.991		4.227

,

Table A3. Operational phase.

	Nominal IoT DL (Nid)			Nominal IoT UL (Niu)			Nominal SW (Ns)			Nominal SW DL (Nsd)
Subsystems	P (W)	t (min)	E (Wh)	P (W)	t (min)	E (Wh)	P (W)	t (min)	E (Wh)	Transm	t (min)	E (Wh)
OBC	0.2	92.5	0.308	0.2	92.5	0.308	0.2	92.5	0.308	0.2	92.5	0.308
EPS: converters, MCU, batteries, heater	0.26	92.5	1.201	0.26	92.5	1.201	0.26	92.5	1.201	0.26	92.5	1.201
Deployable Antenna System	0	0.0	0.000	0	0.0	0.000	0	0.0	0.000	0	0.0	0.000
Deployable Solar Pannels	0	0.0	0.000	0	0.0	0.000	0	0.0	0.000	0	0.0	0.000
ADCS Board and sensors	0.3	0.0	0.000	0.3	92.5	0.462	0.3	92.5	0.462	0.3	0.0	0.000
ADCS magnetorques	0.55	92.5	0.848	0	0.0	0.000	0.55	92.5	0.848	0.55	92.5	0.848
COMMS: TTC - Payload IoT_SW_	5.35	12.0	1.353	2.14	12.0	0.428	0.2	12.0	0.317	5.35	12.0	1.353
Payload Weather solar_Sensor	0	0.0	0.000	0	0.0	0.000	2.5	30.0	1.250	0	0.0	0.000
Payload Electronic SW	0.2	92.5	0.308	0.2	92.5	0.308	0.2	92.5	0.308	0.2	92.5	0.308
Payload Single reaction wheel	0.15	15.0	0.038	0.15	15.0	0.038	0.15	15.0	0.038	0.15	15.0	0.038
Payload fine sun sensor	0.01	0.0	0.000	0.01	0.0	0.000	0.01	0.0	0.000	0.01	0.0	0.000
GPS _Antenna	0.171	10.0	0.029	0.171	10.0	0.029	0.171	30.0	0.086	0.171	10.0	0.029
TOTAL	7.191		4.085	3.431		2.774	4.541		4.817	7.191		4.085

and Table A4 show the minimum, nominal and maximum power consumption of each satellite subsystem for each mode.

Now, we take into account the satellite operation modes, an orbital period of T = 92.47 min, an eclipse time of Te = 35.9 min, and a sun time of Ts = 56.5 min. The results of maximum power demanded in each mode and the corresponding energy are presented in Table 4:

Reviewing the technical information of the different subsystems, each one of them is powered with the typical regulated voltages of 5 V and 3.3 V. For the case of currents, these do not exceed 4 A in any of the buses and the respective protections must be available (see Table A2).

2.3.2. Thermal Subsystem

The thermal design of a satellite is crucial for ensuring the health and longevity of a spacecraft in Earth’s orbit. The objectives of the Thermal Subsystem are to analyze the thermal space environment specific to the CubeSat’s orbit, identify potential thermal challenges, and establish survivability and operational temperature limits for every component of the CubeSat [68]. This approach ensures that the CubeSat can withstand the extreme temperature fluctuations experienced in space and maintain optimal operating conditions for its components. In order to conduct a preliminary analysis of the thermal subsystem, a thermal model was developed using the lumped parameter method. For the computation of the radiative heat loads, this model employed an in-house MATLAB algorithm that calculates the solar radiation ${\dot{Q}}_{s,i}$, terrestrial infrared radiation ${\dot{Q}}_{e,i}$, and albedo radiation ${\dot{Q}}_{a,i}$. The method includes a set of in-house-developed MATLAB scripts that allow for the numerical integration of the following equations [69,70]:

$${\dot{Q}}_{s,i}={\alpha }_i({\widehat{\mathbf{n}}}_i·{\widehat{\mathbf{r}}}_{\oplus \to \odot })I_{\odot }{A}_i$$

(1)

$${\dot{Q}}_{e,i}={\int }_{{\mathcal{S}}_e}{\epsilon }_i\sigma T_e^4{A}_i{\displaystyle \frac{({\widehat{\mathbf{r}}}_{\oplus \to dS}·{\widehat{\mathbf{r}}}_{dS\to sat})(-{\widehat{\mathbf{r}}}_{dS\to sat}·{\widehat{\mathbf{n}}}_i)}{\pi \parallel {\mathbf{r}}_{dS\to sat}{\parallel }^2}}dS$$

(2)

$${\dot{Q}}_{a,i}=\int {\int }_{{\mathcal{S}}_a}{\alpha }_i{\gamma }_{\oplus }{\displaystyle \frac{({\widehat{\mathbf{r}}}_{\oplus \to dS}·{\widehat{\mathbf{r}}}_{dS\to sat})({\widehat{\mathbf{r}}}_{dS\to sat}·{\widehat{\mathbf{n}}}_i)}{\pi \parallel {\mathbf{r}}_{dS\to sat}{\parallel }^2}}d{\dot{Q}}_{\oplus }d{A}_i$$

(3)

where

$$d{\dot{Q}}_{\oplus }=I_{\odot }({\widehat{\mathbf{r}}}_{\oplus \to dS}·{\widehat{\mathbf{r}}}_{\oplus \to \odot })dS$$

(4)

where ${\alpha }_i$ and ${\epsilon }_i$ are the effective absorptivity and emmisivity of the i-th surface, $A_i$$\left(m^2\right)$ is the area of the i-th surface, ${\gamma }_{\oplus }$ is the albedo factor, $I_{\odot }$$(W/m^2)$ is the solar constant, $T_e$$\left(K\right)$ is the mean Earth temperature, and $d\dot{Q}\oplus$$\left(W\right)$ is the power of solar radiation incident on a differential surface element of the Earth $dS$. ${\mathbf{r}}_{\oplus \to sat}$ describes the position of the satellite in space, ${\widehat{\mathbf{n}}}_i$ is a normal unit vector to the i-th surface of the satellite, ${\mathbf{r}}_{\oplus \to dS}$ represents the position vector of a differential surface element of the Earth, and ${\widehat{\mathbf{r}}}_{\oplus \to \odot }$ describes the solar vector. The components of ${\mathbf{r}}_{dS\to sat}$ can be calculated as ${\mathbf{r}}_{dS\to sat}={\mathbf{r}}_{\oplus \to sat}-{\mathbf{r}}_{\oplus \to dS}$.

The script includes several routines to calculate the sun’s position and transform the satellite’s position and orientation from the body coordinate system to a geocentric reference frame. Based on these data, the integration of the power received by each surface is performed.

Regarding the temperature determination, the lumped parameter approach considers the entire satellite as a lumped, isothermal system (represented by a single node) with an effective mass and heat capacity. The equations can be found in Appendix C (Equations (A1) and (A2)).

To estimate the effective specific heat parameter, a breakdown of each of the satellite’s subcomponents was performed, determining their individual mass and heat capacity as is presented in

Table 5. Thermal breakdown for effective heat capacity determination.

Subsystem	Breakdown	Material	Maximumm Mass	Mass Fraction	Heat Capacity [J/kg K]
Structure	Ribs	Al 6061	24.31	1.84%	961.2
Structure	Side Frames	Al 6061	57.38	4.34%	961.2
Structure	Kill Switch	Al 6061	3.10	0.23%	961.2
Structure	Threaded rod	Al 6061	6.06	0.46%	961.2
Structure	Spacers	Al 6061	10.60	0.80%	961.2
Structure	Screw–Washers–Nuts	Al 6061	16.00	1.21%	961.2
Payload	MINIPIX TPX3	PCB	45.10	3.41%	1544.0
Payload	Control moment gyroscope (CMG)	Steel	136.50	10.32%	500.0
Payload	Nano-SSOC-A60 analog sun sensor	PCB	4.07	0.31%	1544.0
Payload	Space weather	PCB	3.30	0.25%	1544.0
OBC	Mainboard	PCB	103.40	7.82%	1544.0
OBC	Daughter Board	PCB	6.60	0.50%	1544.0
EPS	MainBoard	PCB	18.00	1.36%	1544.0
EPS	Battery Pack	Li-Po	184.00	13.91%	1350.0
EPS	PCB +X	PCB	77.00	5.82%	1544.0
EPS	PCB −X	PCB	77.00	5.82%	1544.0
EPS	PCB +Y	PCB	55.00	4.16%	1544.0
EPS	PCB −Y	PCB	55.00	4.16%	1544.0
EPS	PCB +Z	PCB	55.00	4.16%	1544.0
EPS	PCB −Z	PCB	38.50	2.91%	1544.0
ADCS	MainBoard	PCB	24.00	1.81%	1544.0
ADCS	Magnetorquers	PCB	130.00	9.83%	1544.0
COMM	Tranceiver—IOT	PCB	85.60	6.47%	1544.0
COMM	Antenna System	PCB	107.00	8.09%	1544.00
Total			1322.53	100%

:

To evaluate the satellite’s thermal performance under extreme conditions, this analysis considers both the worst hot case (WHC) and worst cold case (WCC). The WHC represents the scenario with maximum solar irradiance and minimum heat dissipation, while the WCC considers minimum solar irradiance and maximum heat dissipation. These cases provide a comprehensive understanding of the satellite’s thermal behavior under the most challenging environmental conditions.

Table 6. Selected parameters for the WHC and WCC cases [68].

Parameter	WHC	WCC
Solar Constant (W/m2)	1412.5	1321.7
Albedo Factor (°)	0.39	0.3
Earth’s Effective Temperature (K)	300	250

presents the parameters considered for each case, including the solar constant, albedo factor, and Earth’s effective temperature.

Table 7. Thermal requirements of satellite subsystems.

Payload	${\mathit{T}}_{\mathit{min}}$ (°C)	${\mathit{T}}_{\mathit{max}}$ (°C)
OBC	−20	70
EPS	−40	80
ADCS	−40	80
COMM	−20	60

presents the thermal requirements for each subsystem of the satellite. This allows us to ensure that each component operates within its specified temperature.

The thermal analysis results, shown in the accompanying graph, demonstrate the satellite’s temperature behavior under both the WHC and WCC scenarios (Figure 6). As indicated in the graph, the satellite’s temperature remains within the acceptable operating limits for all components, never exceeding the established thresholds outlined in Table 7.

These results show that the proposed thermal design effectively addresses the extreme thermal conditions encountered in orbit. However, it is important to emphasize that this analysis is preliminary and further detailed design analysis is crucial to refine the thermal control system and ensure long-term reliable performance.

2.3.3. On-Board Computer

An early version of the OBC from Pumpkin’s [71] MISC satellite project [72] is used in the building of the satellite. Executing onboard operations and overseeing communication systems are the OBC’s primary responsibilities. The Control and Data Handling (C&DH) subsystem is responsible for managing internal procedures and intersystem communications within the satellite.

Furthermore, most autonomous software maintains satellite components’ operational characteristics, which are critical in executing commands from ground control and processing data for transmission to Earth. OBC development will incorporate cybersecurity measures proposed by NIST [73,74,75], and CCSDS [76], leveraging insights from the FACSAT-2 mission [77]. FACSAT-2’s key conclusions include a complete review of each component across six operational modes. The addressed issues, such as power constraints, allow for the optimal deployment of resources for high-consumption tasks like X-band communication while optimizing energy utilization during non-sun-tracking modes, especially in penumbral environments [78,79,80,81].

To protect command and telemetry lines, these precautions include implementing encryption methods and authorization/authentication systems. For this purpose, CCSDS 350.1-G, CCSDS 350.7-G, CCSDS 350.9-G, and CCSDS 3552.0-B [82] are essential reference resources. For this mission, the OBC will consist of the MotherBoard (MB) and the Pluggable Processor Module (PPM), as shown in Figure 7.

The OBC’s ability to withstand single-particle inversions and other radiation-induced flaws is crucial. It uses error detection and correction (EDAC) techniques like memory scrubbing and parity checks, as well as hardware solutions like Triple Modular Redundancy (TMR) and watchdog timers [83]. Backup systems or components provide redundancy, while radiation-hardened parts lessen the likelihood of errors. These safeguards are complemented by software mitigation strategies such as checkpointing and rollback, as well as voting algorithms. Real-time error correction algorithms and hardware are used, and automatic system reconfiguration switches to backup systems or alternate modes when problems are discovered. These solutions ensure that the OBC can successfully regulate and reduce the effects of single-particle inversions, allowing satellites to operate reliably in the hostile space environment [84].

2.3.4. Attitude Determination and Control System

The ADCS module is in charge of the attitude and orientation control for the CubeSat, hence meeting a variety of operational requirements. These consist of spinning control to reduce orbital disturbances, pointing control for efficient communication with the IoT payload, and detumbling control to manage high rotational speeds after deployment. The performance of the ADCS is not heavily taxed by the space weather sensor, but the IoT payload requires accurate pointing control in order to communicate. The main goal of environment survival is energy production, which calls for deployable solar panels that need pointing control. However, because of the CubeSat’s small size, there are few issues with gravity gradient torque or solar pressure. Figure 8a shows the centralized architecture, where OBC is in charge of ADCS execution. Figure 8b presents the distributed architecture, where a spacialized controller will be in charge of the ADCS execution, both MCU or FPGA technologic choises will be considered.

The attitude determination will be carried out by the TRIAD algorithm [85] and attitude control by the control law developed by the group SpaceTech of Universidad de los Andes AESS IEEE. The magnetorquers to be used will be those developed by the SpaceTech AESS IEEE group (TRL = 4) of the Universidad de los Andes and the general development of the ADCS will be supported by the previous developments made by the same group [85].

An engineering model of the ADCS is currently being constructed using an FPGA controller under the platform HiLeS Designer 2.0, a propietary and widely-used platform to develop embedded systems, offering advanced features for real-time control and data processing. This platform facilitates the design and implementation of complex control algorithms on FPGA hardware, providing a flexible and efficient solution for aerospace applications such as satellite ADCS [85,86,87].

2.3.5. Communication Subsystem

To transmit data effectively, the system must take into account the speed of the orbit, the distance and a limited power budget, and the location of the electrical components in the CubeSat is difficult due to its small size, which represents a challenge in the design of the communications system. Satellite communication requires an Automatic Identification System (AIS), this communication system is designed to have three subsystems: AIS, data communication and Telemetry, Tracking and Control (TT&C) [88].

The Cubesat communication system is composed of one dipole antenna compact and efficient with necessary radiation pattern, gain, and reconfigurable polarization. The transceiver is capable of VHF and UHF operation; it receives the Telecommand and IoT data and transmits the payload and Iot data to the ground station. The architecture of the communications system is shown in Figure 9.

Satellites operating in LEO orbit have the advantage of affordable launch costs, as well as less stringent communication link power limitations due to the shorter distance for the communication link [88]. However, LEO satellite ground station antennas must track and follow the satellite as it passes the ground station. The Doppler effect present in a satellite communication link is very harmful for applications based on Frequency Shift Keying. Satellite tracking through specialized software allows to maintain the best transmission and reception characteristics when connecting to the satellite [89,90]. This tracking is performed in the Ground Station through the use of the following elements:

• SDR: The software-defined radio allows one to process the message signal improving favorable characteristics for a correct demodulation.
• The general control system: Manages message reception and antenna positioning; often this task is performed by software such as orbitron.
• Prediction: From the georeferencing of the ground station, it predicts the time and direction of possible links with the satellite.
• Rotator System: Allows one to orient the antennas towards the satellite to ensure the highest power gain in the link.

The communication system for ground station transmission and reception operation is shown in Figure 10.

For the link budget, the VHF uplink and UHF downlink could be used as the communication network for CubeSat in TT&C applications [89,91,92]. The main characteristics evaluated on the Spacecraft–Ground Station link are shown in Figure 10.

IoT nodes will be designed for ground segment purposes. The self-development is compatible with the commercial transceiver for the operation of this project, which is portable and has the ability to achieve the uplink with the satellite. The design parameters are listed below:

• Portable with self-sustaining power supply.
• Operation by reception of satellite alert signals.
• Unique identification code for each node and intercom system with satellite for logging tasks and access for IoT data upload.

The Collect Mission Data Activity is shown in Figure 11.

Accessing the satellite requires the implementation of an identification system, which also allows distinguishing between Telecommand or IoT data upload [93] using the uplink, according to the process shown in Figure 11 [94], where TFPH is the Transfer Frame Primary Header, SH is the Segment Header and FECF the Frame Error Control Field [95]. The RAC (Remote Control Access Code) and IAC (IoT Access Code) allow the OBC to switch between these two uplink tasks. For the satellite construction the Astrodev Hellium from Pumpkin’s radio is available; it operates on commercial and amateur radio links, and these have low power consumption and low mass budget and the adaptability to change the data rate and frequencies in flight mode. Its main technical characteristics are shown in Figure 12:

2.3.6. Payload

The CubeSat’s primary objective is to perform solar observations, specifically focusing on the measurement of solar wind particles. Solar wind is a stream of charged particles, primarily electrons and protons, flowing from the sun into the solar system. By measuring the composition, density, and energy spectrum of these solar wind particles, the mission aims to:

• Enhance our understanding of the sun’s activity and its impact on space weather.
• Collect valuable data for space weather forecasting, which is critical for safeguarding space assets and satellite operations.
• Improve our ability to predict and mitigate space weather-related disruptions to communication, navigation, and satellite systems.

The instrument is composed by the optical system, a surface detector “ADVACAM”, and by the main electronics that are currently an on-going project developed by Universidad Industrial de Santander (ASIC, memory, secondary computer, main computer). Finally, the payload is connected to the OBC in a bidirectional communication link that leads receive commands from the instruction set and sends data sets from the power link to the EPS subsystem (Figure 13).

The ADVACAM detector [58] will be used for monitoring cosmic weather. This technology provides timely warnings against increased solar activity, which can pose risks to the health of astronauts and disrupt the functionality of sensitive onboard electronics in satellites and spacecraft. The MiniPIX TPX3 SPACE particle [58] counting camera builds upon technology originally developed for basic particle physics research at the Large Hadron Collider (LHC) at CERN. This lightweight device, weighing just a few tens of grams, can distinguish the type of each individual particle, as well as its energy and direction.

3. Model-Based System Engineering for Preliminary Design

Several methods have been proposed for the design of CubeSats. Probably the most well known are systems engineering and Model-Based System Engineering (MBSE). Before detailing our specific methodology, this section presents a brief overview of existing methods that have served as inspiration for the ³ColStar KiboCUBE Agile methodology Implementation, such as the V-Model and Digital Engineering. Subsequently, we delve into the Arcadia Method and Capella modeling tool, emphasizing their role in our approach.

For the last mentioned part, we will delineate the systems engineering design processes utilized for the mission. This includes elements discussed in previous chapters, such as a thorough definition of stakeholder needs and technical requirements (Section 2), which are crucial for guiding the satellite’s development. The logical decomposition of the system will be clearly articulated, elucidating how the satellite’s subsystems were identified and structured to align with mission objectives. Furthermore, we will present the design solutions adopted for each subsystem, demonstrating how they were derived from the requirements and integrated into the overall satellite architecture. These aspects will be explored within the framework of Capella and Arcadia methodologies, ensuring a systematic and comprehensive examination of the satellite’s preliminary design phase.

3.1. Brief Overview of Existing MBSE Methods and Techniques

3.1.1. Systems Engineering

Systems Engineering is a multi-disciplinary approach for developing functional and operable systems capable of meeting requirements and design constraints [96]. A “system” is a well defined combination of elements such as hardware, software, and humanware, that working together are expected to produce the capabilities required by a need. Given the multi-disciplinary nature of space asset planning, design, implementation and operation, systems engineering is a holistic and integrative discipline aimed at balancing different professional efforts to produce a coherent system [96]. To this, systems engineering includes three categories of processes that are organized in seven phases. The aforementioned categories of processes are systems design, product realization, and technical management; the seven systems engineering phases go from the concept studies to system closeout.

In the particular case of design, the systems engineering design processes include the stakeholders expectations and technical requirements definitions, as well as a logical decomposition of the system and a design solution definition. Concerning the project phases suggested by the systems engineering discipline, the design processes are a responsibility of the first four phases: Pre-phase A (concept studies), Phase A (concept and technology development), Phase B (preliminary design and technology completion); the design-related phases are described in

Table 8. Design-related phases of the NASA Systems Engineering Project Life Cycle [96].

Phase	Purpose	Typical Outcome
Pre-Phase A. Concept Studies	To produce a broad spectrum of ideas and alternatives for missions from which new programs/projects can be selected. Determine feasibility of desired system, develop mission concepts, draft system-level requirements, assess performance, cost, and schedule feasibility; identify potential technology needs, and scope.	Feasible system concepts in the form of simulations, analysis, study reports, models, and mock-ups
Phase A. Concept and Technology Development	To determine the feasibility and desirability of a suggested new system and establish an initial baseline compatibility with NASA’s strategic plans. Develop final mission concept, system-level requirements, needed system technology developments, and program/project technical management plans.	System concept definition in the form of simulations, analysis, engineering models and mock-ups, and trade study definition
Phase B. Preliminary Design and Technology Completion	To define the project in enough detail to establish an initial baseline capable of meeting mission needs. Develop system structure end product (and enabling product) requirements and generate a preliminary design for each system structure end product.	End products in the form of mock-ups, trade study results, specification and interface documents, and prototypes

. In case the reader is interested in more details about the systems engineering processes and phases, we refer the interested reader to the NASA Systems Engineering Handbook [96].

3.1.2. The V-Model

The systems engineering “V” model, a.k.a., the V-model, has been widely used in the aerospace and defense industries [97]. It is called V-model because the activities are presented by using a “V” letter metaphor. The left part of the “V” is for the specification activities that go from high level specifications and designs to more detailed and granular ones; there are the implementation tasks (represented by the foundation of the “V” letter base); and finally there are the testing activities represented by the right part of the “V” letter that go from more granular tests (e.g., unit level tests) to high level ones (e.g., acceptance tests).

The V-model is a systems development process that emphasizes an upfront specification and design stage, similar to the NASA systems engineering process. It is often associated with the validation-and-verification approach, as it structures the development process in a way that allows for continuous validation and verification at each stage [97,98,99]. However, this association is sometimes debated in the literature, and care should be taken to distinguish between the general V-model and specific implementations that emphasize validation and verification activities.

The V-Model inherently supports vertical and horizontal traceability, which are crucial to ensure alignment and consistency throughout the development process. Vertical traceability ensures that each phase, from initial requirements to detailed design and testing, is aligned with the mission objectives, providing a clear lineage of requirements. Horizontal traceability ensures consistency across various components and subsystems at each development stage, maintaining coherence in design and implementation. In our application to the ³ColStar mission, vertical traceability was achieved by maintaining comprehensive documentation that mapped each specification and design decision back to the initial mission requirements. This was further supported by regular reviews and validation steps in each phase, ensuring that the design remained aligned with the mission objectives. Horizontal traceability was facilitated through integrated subsystem design strategies and weekly cross-functional meetings, which ensured that interdependencies between subsystems were consistently addressed and managed.

While the V-Model provides a structured and systematic approach, it has limitations, particularly in handling dynamic requirements, which prompted the integration of Agile methodologies. We did consider the Spiral Model, which offers a more flexible and iterative approach, combining elements of iterative development and the waterfall model. The Spiral Model allows for continuous refinement through multiple iterations or “spirals,” each including planning, risk analysis, engineering, and evaluation. This model is adaptable to changing requirements and stakeholder feedback. However, we found that integrating Agile methodologies directly addressed our specific project needs more effectively. While the Spiral Model provides a structured approach with iterative phases for risk management, Agile methodologies proved more effective for our project needs due to their continuous risk assessment and management throughout iterative sprints. The incremental delivery and regular feedback integration of Agile methods facilitated prompt identification and mitigation of risks, allowing for adaptive responses to emerging issues. Agile’s flexible planning and iterative adjustments offered a more responsive and efficient risk management mechanism compared to the longer review cycles of the Spiral Model. The iterative nature of Agile methods, combined with their emphasis on stakeholder involvement and flexibility, provided a robust framework for managing the dynamic and complex requirements of the ³ColStar mission. While the Spiral Model also offers benefits, Agile methodologies provided a more straightforward and efficient path to achieving our project goals. This hybrid approach allowed us to leverage the strengths of both methodologies, providing thorough validation and alignment with mission specifications, while also managing risks and accommodating changes efficiently.

3.1.3. Digital Engineering

Digital engineering is a cross-disciplinary field that takes advantage of digital tools and processes for the design, development, and production of engineering products across a project’s life cycle [2]. The main purpose of digital engineering is to improve the efficiency and accuracy of the engineering process, along with reduced project risk. Digital engineering is conceived under the perspective that systems engineering needs to evolve based on current situations, such as the following: (i) systems becoming increasingly complicated and interconnected; (ii) resource reduction in projects; (iii) project complexity is increasing; (iv) some current practices are not sustainable. Therefore, digital engineering aims to effectively manage complexity, reduce cost and scheduling, and improve productivity via the integration of processes, digital tools, and techniques within the systems development life cycle [2].

3.1.4. Model-Based Systems Engineering

MBSE is an approach that uses digital models of the system and its engineering aspects as the main way to share and manage information, feedback, and requirements, instead of relying on documents. It covers the whole process of creating, communicating, and ensuring that all the digital models that describe a system are consistent from the conceptual design phase through the later phases of the life cycle, such as the requirements definition, design, analysis, and verification and validation activities [100]. MBSE is based on modeling languages and methods such as the SysML [101], which is used in tools like Cameo Systems modeler [102], MagicDraw [103] or the Arcadia method [11], used in Capella [104]. MBSE allows to represent and communicate the structural, functional and dynamic aspects of a complex system and aims to improve the efficiency, quality and traceability of the systems engineering process, as well as to facilitate collaboration between the different actors involved [105].

3.2. Arcadia Method and Capella Modelling Tool

Arcadia enables a thorough modeling of complex systems in the architecture engineering context, across multiple levels of abstraction. It is founded on a hierarchical framework that first defines the problem space at the top level, and later defines proposed solutions that traverse the system’s various elements. It is bolstered by a viewpoint-centric approach that underscores the need to integrate the many views that are vital to the system’s design. It is further reinforced by its support for a thorough trade-off analysis that allows decisions at all levels of architectural design [11,104,106].

Arcadia is a tooled method devoted to systems and architecture engineering, supported by the Capella modeling tool. This method is presented in Figure 14; Arcadia is built around the following statements [107]:

• Understand the real customer needs.
• Define and share the product architecture among all engineering stakeholders.
• Validate the design early and justify it.
• Ease and mastery of Integration, Validation, Verification, and Qualification (IVVQ).

Arcadia can be applied to complex systems, equipment, software, or hardware architecture definition, especially those dealing with strong constraints to be reconciled (e.g., cost, performance, safety, security, reuse, consumption, weight). It is intended to be used by most stakeholders in system/product/software or hardware definition and IVVQ as their common engineering reference and collaboration support [107].

The Capella modeling tool is used to define the entities involved in a project, its hierarchy, and capabilities from the Operational Level and, through several systems engineering decision-making criteria, to realize the different analyses until the physical description of the satellite matches how it connects to the space and ground segments. The two main analyses in the mission are the logical and physical architectures, where the logical function of the system is defined and the physical definition follows, since technology can become outdated, but the functionality controls the behavior of each system and their integration.

3.3. Integration of System Requirements within the Capella System Model

In the ³ColStar mission, the Arcadia/Capella methodology was employed to ensure comprehensive integration of the system needs, based on its architecture, into the model. Capella, an open-source MBSE software (version 6.1), facilitated the transition from a traditional document-based approach to a dynamic model analysis and traceability of functionalities throughout the mission.

• System needs and and Integration: Requirements were established initially from mission concept, translated into Capella, and linked to various model elements, including operational scenarios, system functions, logical components, and physical designs. For example, the requirement for the solar weather payload to measure solar radiation with ±5% accuracy was captured in Capella’s requirement management module. This requirement was then linked to specific system functions and logical components responsible for implementing this functionality.
• Bidirectional Traceability: Bidirectional traceability was established to ensure that each requirement could be traced forward to its corresponding design elements and backward to its source. This was achieved by creating traceability links between the requirements and their associated system functions, logical components, and verification test cases. For instance, the requirement for data transmission every 30 min was linked to the design specifications of the IoT payload, ensuring that all aspects of the requirement were addressed. This was validated with the link budget model developed by the communications team.
• Connectivity Diagrams and Matrices: Capella provided diagrams and matrices to visualize the relationship between requirements and their corresponding design elements. These representations were used to verify that all components, functions and actors were fully addressed and to monitor how changes in the architecture impacted the design. For example, traceability matrices from the system’s physical level showed, from multi-physics analysis, the alignment of the solar weather payload’s accuracy requirement with its corresponding design elements and test cases.
• Validation and Verification: From the system architecture based on the Capella model, the validation and verification were established by using additional tools, such as Ansys STK, NASA GMAT, Matlab and Simulink, throughout the project. From the component to system level, each part was linked to test cases and validation criteria, enabling systematic verification of compliance with mission objectives. For example, test cases related to the solar radiation measurement accuracy were linked to the specific design elements responsible for this function, ensuring that the requirements were validated through testing.

Each subsystem of the satellite was designed and integrated into the Capella model, ensuring complete traceability and alignment with mission objectives.

3.3.1. Subsystem Design Integration

• Power Subsystem (EPS):
  • Requirements:

    –

    Continuous availability of power.

    –

    Efficient solar power generation and distribution.

    –

    Resistance to space environmental conditions.

  • Logical and Physical Design:

    –

    Logical Functions: power generation, storage, and distribution.

    –

    Physical Components: solar panels, batteries, and power management units (PMUs).

    –

    Traceability: the requirements for continuous power were linked to specific physical components, such as solar panels and batteries, ensuring direct alignment from requirement to implementation.

• On-Board Computer (OBC):
  • Requirements:

    –

    Data processing, command execution, and system monitoring.

    –

    High reliability and fault tolerance.

  • Logical and Physical Design:

    –

    Logical Functions: data processing, command handling, and system health monitoring.

    –

    Physical Components: locally manufactured OBC capable of performing the identified logical functions.

    –

    Traceability: the requirements for data processing and command execution were linked to the physical OBC component.

• Attitude Determination and Control System (ADCS):
  • Requirements:

    –

    Precise control and stabilization of orientation.

    –

    Fine-tuning capability and automatic correction.

  • Logical and Physical Design:

    –

    Logical Functions: attitude sensing, control algorithms, and actuation.

    –

    Physical Components: reaction wheel, fine-sun sensor, and magnetorquers.

    –

    Traceability: the attitude control requirements were linked to the ADCS components, ensuring each logical function was reflected in the physical design.

• Communication Subsystem (COMMS):
  • Requirements:

    –

    Reliable communication with ground stations.

    –

    Capability for long-distance data transmission and reception.

  • Logical and Physical Design:

    –

    Logical Functions: signal transmission, reception, and encoding/decoding.

    –

    Physical Components: antennas, transceivers, and modems.

    –

    Traceability: the reliability requirements for communication were traced to specific components designed to handle data transmission and reception.

• Thermal Control Subsystem:
  • Requirements:

    –

    Maintenance of operational temperatures within safe limits.

    –

    Protection against extreme space temperatures.

  • Logical and Physical Design:

    –

    Logical Functions: heat dissipation and thermal insulation.

    –

    Physical Components: radiators, thermal blankets, and heaters.

    –

    Traceability: the thermal control requirements were linked to the physical components, ensuring effective thermal management.

• Payload Subsystems:
  • MiniPIX TPX3 SPACE Sensor:

    –

    Requirements:

    *

    Capability for particle detection and scientific data acquisition.

    *

    Low power consumption and reduced weight.

    –

    Logical and Physical Design:

    *

    Logical Functions: particle detection, data acquisition, and analysis.

    *

    Physical Components: MiniPIX TPX3 SPACE sensor and associated electronics.

    *

    Traceability: the scientific data collection requirements were linked to the MiniPIX sensor, ensuring alignment with mission objectives.

  • IoT Payload:

    –

    Requirements:

    *

    Enable IoT connectivity in remote areas.

    *

    Support for educational and social impact initiatives.

    –

    Logical and Physical Design:

    *

    Logical Functions: IoT data transmission, environmental monitoring, and connectivity.

    *

    Physical Components: IoT transceivers, sensors, and supporting electronics.

    *

    Traceability: the requirements for IoT connectivity and educational outreach were linked to the IoT payload components, ensuring they met the mission’s social and educational objectives.

3.3.2. Traceability and Validation in Capella

• Requirement Integration:
  • Import and Structuring: Requirements were imported and hierarchically structured within Capella’s Requirement Viewpoint, assigning them to relevant logical and physical components to ensure traceability throughout the model.
• Traceability Mechanisms:
  • Logical Layer Traceability: Requirements were linked to logical components and functions, ensuring adherence to specified needs.
  • Physical Layer Traceability: Physical components were traced back to logical functions and requirements, maintaining continuity.
  • Bidirectional Traceability: Capella facilitated bidirectional traceability, allowing backtracking from physical components to high-level requirements and forward tracking from requirements to detailed physical designs.
• Documentation and Configuration Management:
  • Requirement Allocation Matrix: Visual tools within Capella, such as the Requirement Allocation Matrix, illustrated relationships between requirements, logical components, and physical components.
  • Traceability Diagrams: Diagrams like Requirement Coverage Diagrams visually represented requirement coverage by system elements, highlighting any gaps or overlaps.

3.3.3. Comprehensive Design Activities

• Subsystem Design Strategy:
  • Integrated Approach: An integrated yet individually focused approach ensured effective collaboration and cohesion among subsystems. Weekly meetings addressed cross-functional issues and ensured cohesive problem-solving across all components.
• Sequential Development and Validation:
  • Sequential Development: Sequential development was prioritized to allow detailed analysis and validation of each subsystem’s functionality before advancing to the next phase. This approach effectively managed risks by validating each subsystem’s design and performance before integration.
• Agile Methodologies:
  • Agile Methodologies: Agile methodologies were integrated to effectively handle dynamic requirements and provide iterative development, stakeholder involvement, and flexibility. Agile’s iterative process allowed for continuous refinement and adaptation to changing requirements and stakeholder feedback.

3.3.4. Example of Traceability

• High-Level Requirement: Enhance Colombia’s expertise in space technology.

  –

  Logical Component: Training and Development Module

  *

  Linked Requirement: Develop and integrate locally manufactured space components.

  –

  Physical Component: Locally Manufactured On-Board Computer (OBC)

  *

  Linked Logical Function: On-Board Data Processing

  *

  Traceability Link: The OBC component is directly linked to the training and development requirement through its logical function.

Integrating system requirements into the Capella model and establishing robust traceability mechanisms ensured that every design decision aligned with the mission’s objectives and that any changes in requirements or design could be managed effectively. This approach provided a transparent view of how requirements were met throughout the mission, incorporating detailed design activities for each subsystem.

4. Preliminary Design of the ³ColStar KiboCUBE Mission

4.1. ³ColStar KiboCUBE Agile Methodology Implementation

Since the Manifesto for Agile Software Development was introduced in 2001, Agile practices have transformed how software teams create products. The Manifesto outlines a series of core values and principles aimed at enhancing software development [17]. It has led to various methodologies and frameworks like Scrum, Kanban, and Lean, along with other terms and techniques [108].

Hardware and software development involve distinct developmental tasks. While Scrum, an Agile process commonly applied to software development, might not initially appear suitable for hardware development, the apparent disparities mainly revolve around the nature and order of deliverables, rather than fundamental constraints on the process itself. Some differences in the hardware development with software development are as follows [109]:

• Software is more malleable (easier to change) than hardware. The cost of change is much higher for hardware than for software.
• Specialized hardware parts may take significantly longer to procure as compared to software.
• Software products develop over time with successive releases, involving the addition of new features and the refinement of existing ones. In contrast, hardware products primarily comprise physical components that cannot be easily altered after manufacturing like software. They cannot gain new capabilities through simple modifications.
• Architectural decisions heavily influence the design of a hardware product, needing a higher upfront investment in architectural planning due to the high cost of making changes later, unlike in software products.

Although Agile adoption is relatively new for hardware, there are already some proposed frameworks, such as Modified Agile for Hardware Development (MAHD) [110], in which there is a section of upfront work called MAHD on ramp and then it moves on to sprints. Likewise, MAHD is not based on incremental development, but on iterative design and early validation. Another difference is that this framework uses a focus matrix to prioritize product attributes. There are several aerospace-based development projects in which the scrum methodology has been applied [111]. Other works include manufacturing and launching a cubesat [112,113,114]. As a result of works such as this one, a slightly deeper understanding has been gained as to whether Agile methodologies and practices are compatible with space development, given the unique characteristics of hardware development and key aspects of the space sector.

As a way to shed some light on the use of Agile methods in the space systems engineering domain, we adopted Agile practices during two critical phases of the ³ColStar project: the proposal structuring and preliminary design stages. The development team incorporated several general practices from Agile methodologies, including the use of weekly sprints. These weekly sprints facilitated iterative development, allowing for regular reassessment of progress, prompt identification of issues, and integration of feedback. At the end of each sprint, sprint meetings were conducted to evaluate progress, address challenges, and realign goals as necessary. Additionally, the project utilized a team-based approach with specific objectives, with sub-teams organized around different CubeSat subsystems, such as ADCS, Thermal, OBC, and Systems Engineering (SE), as illustrated in Figure 15.

Concerning the implementation and testing stages of the ³ColStar project, the development team will adopt a Scrum-inspired methodology, tailored to suit their specific needs. This approach, depicted in Figure 16a, differs slightly from the original Scrum framework. Sprints will be conducted on a weekly basis, with each team maintaining its own product backlog. Additionally, weekly scrum meetings should be held within each team to ensure effective communication and progress tracking. The framework is displayed in Figure 16b and two parallel processes are shown. In reality, each sub-team or subsystem should operate with its own independent backlog and follow a distinct scrum process, unlike the typical software development approach where there is a single backlog for the whole team. This, and the focus on MBSE, will allow us to work in an agile way and implement changes quickly [113]. The independent operation of subsystem teams, each with its own backlog and distinct scrum process, is managed to ensure the consistency and benefits of the MBSE approach. In the ³ColStar mission, this is achieved through integration and coordination practices verified through weekly meetings. These meetings address cross-functional issues, ensuring that all subsystems are aligned with the overall mission objectives and design requirements. In particular, the management team (which includes members from different universities knowledgeable of the Arcadia method and the Capella tool) is in charge of updating the designs and models based on the discussions during the weekly meetings; with this, we have a centralized way for managing the design decision changes. Therefore, the regular meetings are way for to present the progress and updated models, as well as a way to collect input for the subsystem teams.

The use of the Capella tool and Arcadia method provided us with a unified model where all subsystem designs are integrated and traceable back to the mission’s high-level requirements. This central model enables consistency across subsystems. Changes in one subsystem’s design are reflected in the overall model, allowing for continuous verification and validation of the system’s coherence. This structured approach ensures that despite the independent operation of subsystems, the MBSE benefits of consistency, traceability, and alignment with mission objectives are maintained throughout the project (the model governance is detailed in the Discussion Section 5.1).

The experiences and lessons learned in other projects [115,116,117,118], for instance, the MBSE for Ariane 6 [11], show that a hybrid approach can be successful.

Figure 16. Scrum methodology. (a) Software development [119,120]. (b) ³ColStar KiboCUBE. Note: The images located under the “Increment” text, in their legible size, correspond to Figure A5a,b.

Figure 16. Scrum methodology. (a) Software development [119,120]. (b) ³ColStar KiboCUBE. Note: The images located under the “Increment” text, in their legible size, correspond to Figure A5a,b.

4.2. ³ColStar KiboCUBE MBSE Architecture with Capella Modeling Tool

Innovation in a space project is not only based on technology developments but also on Project Management and Systems Engineering Methodology [119,120,121]. The ³ColStar KiboCUBE project is based on the ECSS Space project management—Project planning and implementation (ECSS-M-ST-10C Rev. 1) [43], NASA Procedural Requirements (NPRs) [44], and JAXA’s systems engineering approach with the JEM Payload Accommodation Handbook (JPAH) [45] for more detailed integration and functionality. The MBSE is implemented by using the Arcadia tooled method focused on systems architecture development and, as mentioned before, we are utilizing the Capella open source software tool. For instance, Figure 17 shows the relationship between the Capella architecture and MBSE.

In the case of ³ColStar KiboCUBE, Figure 18 represents the main entities for the preliminary design through the Capella modeling tool. There are two primary operational entities: the External institutions contributing to the project, and the KiboCUBE project itself. Six operational entities are derived from the project such as Project Management, Financial segment, Science Team, Systems Engineering, Subsystem Research and Development and Testing Facilities. Each of these entities has operational actors, which are represented with the silhouette of people in the figure. Within the Subsystem R & D entity, the actors that will be in charge of each subsystem of the satellite can be found, for example, the Universidad Distrital will be in charge of the OBC subsystem and the Universidad Militar Nueva Granada of the thermal subsystem. Within the IoT and Education entity, there are the actors that design the satellite payload and the actors that make use of it.

The satellite’s logical architecture is depicted in Figure 19. The blue and red lines show flow in one direction only; the black line is flow in both directions (both blue and red). The principle of logical architecture (LA) begins to “open the box” by implementing the solution’s major construction principles and ways to meet stakeholder expectations. It is then formalized through a decomposition into abstract structural elements known as logical components, which force us to rule out any technological considerations or implementation choices. The primary goal of this picture is to illustrate how logical components interact with one another and behave in accordance with pre-established needs [11,104,106].

Logical Component: Structural element within the system, with structural ports to interact with the other logical components and the external actors. A logical component can have one or more logical functions. It can also be subdivided into logical subcomponents.

• Logical Actor: Any element that is external to the system (human or non-human) and that interacts with it.
• Logical Function: Behavior or service provided by a logical component or by a logical actor. A logical function has Function Ports that allow it to communicate with the other logical functions.
• Functional Exchange: A unidirectional exchange of information or matter between two logical functions, linking two Function Ports. An example is IoT data between two logical functions in the IoT module.

In this diagram this architecture is composed of the ground segment, where there are three logical actors, the ground station hub, the mission operations, and the operations support. The logical component the diagram revolves around is the ³ColStar Cubesat, within all the subsystems, their functions and how they interact with each other and with the logical actors.

The physical diagram of the satellite subsystems shown in Figure A5b. Detailed satellite subsystems can be found in Appendix D, where the respective architectures are depicted (Figure A5a–d). The objective of this level is the same as for logical architecture, except that it defines the final architecture of the system and how it must be carried out (“how the system will be built”). The physical diagrams are composed of the following elements:

• Behaviour Physical Component: Physical component tasked with physical functions and therefore carrying out part of the behavior of the system (for example software component, data server, etc.).
• Physical Port: Non-oriented port that belongs to an Implementation Component (or Node). The structural port (Component Port), on the other hand, has to belong to a Behaviour Component;
• Physical Link: Non-oriented material connection between Implementation Components (or Nodes). The Component Exchange remains a connection between Behaviour Components. A physical Link allows one or several Component Exchanges to take place (USB cable, etc.).

For more information, please visit the following web page: ³ColStar KiboCUBE Colombia mission (available online: https://www.cosmojules.com/kibocubecolstar3, accessed on 1 July 2024 ) For any permission or access to the information contained in this repository, please send an email to [email protected].

5. Discussion

The ³ColStar mission connects academia, industry, and government, encouraging collaboration among space exploration stakeholders to generate scientific and societal impact. It represents a groundbreaking collaboration in Colombia, uniting various sectors for the first time in a satellite initiative. Socially, the mission aims to extend IoT connectivity to remote areas in Colombia, where it is now limited or nonexistent. This endeavor will help to bridge the digital gap by bringing crucial communication capabilities to neglected areas. Additionally, the mission will engage school students with its findings, inspiring the next generation of scientists and engineers. Scientifically, the mission will analyze solar particle behavior through its primary weather sensor payload. This analysis is crucial for understanding space weather and its impact on Earth, contributing valuable data to the global scientific community. Technologically, the ³ColStar mission will advance Colombia’s expertise in developing space components and subsystems, as the majority of these components are manufactured locally. Collaboration among 13 institutions, including professors, researchers, and students at various academic levels, promotes national and international cooperation, boosting Colombia’s space technology capabilities [57].

Using MBSE allows for the systematic integration of various technical, operational, and design aspects, resulting in a more comprehensive conception of the ³ColStar mission. MBSE facilitated the early identification of key requirements, efficient risk management, and the optimization of system performance. The application of the Capella tool and Arcadia method enabled us to ensure that all subsystem designs were integrated and traceable back to the mission’s high-level requirements. Throughout the preliminary design phase, the use of a unified model helped maintain consistency across all subsystems. Changes in one subsystem’s design were reflected in the overall model, allowing for continuous verification and validation of the system’s coherence. This integration was further supported by weekly meetings and coordination practices that addressed cross-functional issues, ensuring alignment with the mission objectives and design requirements. Additionally, the integration of Capella revealed that we could avoid design rework, streamlining the process and completing this initial phase in a shorter timeframe than anticipated. MBSE systematically captured and managed stakeholder expectations and technical requirements, decomposing them into functional, logical, and physical architectures. This structured approach provided clear traceability from requirements to design solutions, ensuring that every aspect of the mission was meticulously planned and validated. By adopting this methodology, we ensured that the ³ColStar mission’s technical and operational feasibility was thoroughly assessed and optimized from the early stages of development, leading to a more reliable satellite design.

The process began with a thorough stakeholder analysis, including structured interviews and workshops to capture detailed input from mission sponsors, end-users, and technical experts. This information was documented through targeted questionnaires and reviewed existing documentation. Stakeholder expectations and technical requirements were then integrated into the Capella model, starting with the identification of high-level mission objectives. These objectives were decomposed into specific technical requirements and translated into functional specifications, which informed the functional architecture of the model. The functional architecture outlined necessary system functions and their interactions, which were then detailed into the logical architecture to describe the system’s components and their relationships. The physical architecture further specified the actual hardware and software components.

To maintain traceability, a comprehensive traceability matrix within Capella ensured that each requirement was linked to corresponding elements across the functional, logical, and physical architectures. Regular updates based on feedback from validation checks facilitated continuous verification and validation, ensuring that the evolving design met stakeholder expectations and technical requirements.

Throughout the preliminary design phase, the unified model provided by MBSE maintained consistency across all subsystems. The structured approach of MBSE not only helped avoid design rework but also streamlined the process, completing the initial phase in a shorter timeframe than anticipated. By adopting MBSE, the technical and operational feasibility of the ³ColStar mission was thoroughly assessed and optimized from the early stages, leading to a more reliable and well-planned satellite design.

The application of the Arcadia method for the Preliminary Design of the ³ColStar mission enabled the completion of this process within a remarkable timeframe of just 4 months, facilitated by weekly general sprints. This timeframe compares favorably with the recommendations provided in Space project management—Project planning and implementation (ECSS-M-ST-10C Rev. 1) [43], and NASA Procedural Requirements (NPRs) [44], which suggest a duration of 1 to 6 months for similar processes. The utilization of this methodology in other 1U CubeSat missions has demonstrated improved conceptualization, enhanced communication between subsystems, and technical precision, thereby minimizing errors in mission development [122]. It is worth noting that having a framework process as Arcadia allowed each subsystem team to make progress individually and integrate each team result easily. In the case of the ³ColStar mission, our goal is to allow collaboration among different universities and organizations, particularly because each has different core competencies and resources, and the organizations do not have members with the same skills. Therefore, we assigned subsystems to universities/organizations based on their capabilities/skills/resources/knowledge. Thus, using Arcadia and MBSE allowed us to have a way to centralize the design decisions and progress.

Furthermore, the incorporation of Capella into our approach provided a means to achieve technical consistency through digitalized processes, aligning with the principles of Agile methodology. The implementation of Capella facilitated the creation of a Shared system model with multiple views, connected to discipline models, thereby formalizing aspects of systems engineering through model-based systems engineering (MBSE). It is crucial to note that MBSE does not replace traditional systems engineering, but rather complements it with rigorous methods and tools, ensuring coherency within the model and managing technical consistency across various architectural documents.

All in all, with our study we provide more evidence on how combining Agile methods with system engineering practices helps to face challenges in CubeSat projects, following the line of research of previous works. For instance, Honoré-Livermore [5] reported how integrating systems engineering and Project Management was used in the context of the HYPSO CubeSat project. Similarly to our study, Capella and Arcadia were also used as part of the SE and PM processes. However, our study’s goal was broader: understanding the factors that impact the success rate of university-developed small satellites when the space assets are used in a greater system-of-systems context. Both Honoré-Livermore’s and our study (in projects of different scales) provide researchers and practitioners with evidence of practices and actionable knowledge when using Agile methodologies in aerospace projects. In both cases, there is evidence of how using Agile methods reduced time in the process; while Honoré-Livermore shows evidence of reduced time between mission concept definition and launch, in our case Agile methods were useful to reduce the mission design time.

5.1. Model Governance and Permissions in Capella

In the ³ColStar project, model governance in Capella was carefully managed to ensure integrity and traceability throughout the development process. The governance structure assigned specific roles and permissions to manage modifications effectively within the unified model.

• System Engineering Oversight: Two designated System Engineers were assigned critical roles in model governance. The Lead System Engineer, supported by a secondary System Engineer, held the authority to implement changes across the system model. This hierarchical structure ensured that modifications were aligned with the mission’s high-level requirements and facilitated overall integration.
• Subsystem Management: Each subsystem within the satellite platform was managed by specific representatives who were granted permissions to modify their respective areas. These representatives were tasked with ensuring that their designs adhered to the mission requirements and that any changes were accurately reflected in the model.
• Cross-Subsystem Coordination: To manage interactions between subsystems, regular cross-functional meetings were organized. These meetings included representatives from the affected subsystems and the System Engineering team. The purpose was to discuss and implement modifications that involved multiple subsystems, ensuring that the integrated model remained consistent and coherent.
• View-Only Permissions: For team members not directly involved in model modifications, view-only permissions were implemented. This approach preserved the model’s integrity by restricting editing capabilities to authorized personnel only.
• Project Management Oversight: A team of five Project Managers was responsible for authorizing changes that had financial implications or were critical to the project. Their oversight ensured that modifications were evaluated for their impact on both technical aspects and project budgets.
• Weekly Status Meetings: Weekly meetings were held to provide updates on the project’s status and discuss recent changes. These meetings were essential for keeping all team members, including those with view-only access, informed about ongoing developments and modifications to the model.

This structured approach to model governance in Capella ensured that all subsystem designs were integrated and traceable to the mission’s high-level requirements. By delineating roles and permissions and implementing a collaborative process for managing changes, the ³ColStar project effectively maintained model consistency and supported continuous verification and validation throughout the project.

6. Conclusions

In summary, in this paper we described our experience of integrating Agile Systems Engineering principles, the Arcadia methodology, and the Capella tool in the preliminary design of the ³ColStar satellite mission. With the presented approach, we were able to expedite the design process and enhance the accuracy, communication, and efficiency of mission development, setting a precedent for future CubeSat missions and beyond. It is worth noting that we did not conduct a comparative study of the presented approach versus a traditional one because of budget constraints and the burden of having two different teams working with different approaches. However, future work could be devoted to have more evidence regarding the implications of using Agile methods for space systems engineering.

Limitations and Future Work: We acknowledge that our study primarily focused on the integration of Agile methodologies with the V-Model framework. A comprehensive comparison with the Spiral Model and other iterative approaches was beyond the scope of this paper but is a valuable area for future research. We plan to explore and document these comparisons in our future work to provide a more holistic understanding of the benefits and limitations of various systems engineering methodologies.