## 4 Preliminary Design of the 3 ColStar KiboCUBE mission.
### \({}^{3}\)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 \({}^{3}\)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 \({}^{3}\)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 [104; 106; 11]. 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. Figure 17: MBSE Tool Ecosystem [106]. * 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 \({}^{3}\)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 44(b). Detailed satellite subsystems can be found in Appendix D, where the respective architectures are depicted (Figure 44(a)-d).