CubeSat is a miniature spacecraft orbiting the Earth. The basic design of cubes is a cube that is 10 cm (4 in) long and has a mass of less than 1.33 kg (2.93 lb). Once in space, this can be used in a variety of applications. The cubes are economical and greatly reduce the cost of launching. Being lightweight, you don’t need a lot of fuel to install it. In most cases, they also share a rocket with a larger satellite, which makes it possible to reach space on the booms of a heavy payload. Initially, cubic satellites were used exclusively in low Earth orbit for applications such as remote sensing or communications. Nowadays it is even used in interplanetary missions. The importance of modeling lies in the fact that every task must be completed within deadlines. Detecting and analyzing faults at an early stage is essential to eliminate any error before integrating into real life systems. It saves cost, effort and time for the designer. Architectural exploration will give a comprehensive view of how the system works. Various trade-offs and performance analysis will allow us to arrive at the specific requirements. This paper will talk about different studies of the trade-off after the simulation of the Cubesat model. We will closely monitor the statistics and schematics of the model obtained by the designer after the simulation and the conclusions regarding it. Figure 1: CubeSat architecture model in VisualSim Architect Figure 1 depicts a CubeSat model developed using a modeling and simulation program called VisualSim Architect from Mirabilis Design Inc. The designer can perform various experiments and make many trade-offs in order to improve functional studies to meet the specific requirements before the actual implementation in real time. The designer gets a clear picture of performance and power optimization, to calculate trade-offs, eg failure and functional analysis, security, and a variety of other attributes. It helps in troubleshooting architecture and debugging fault areas at a very early stage. The console configures all the systems before the start of the task. Each task is associated with a schedule, processing time, and deadline. The Modular Spacecraft Scheduling Software (MSV) is responsible for scheduling missions. The scheduler uses the Application Sensor Interface Unit (ASIM) scheme to present the task to the corresponding hardware unit. ASIM is operated by the scheduler based on the orbit number and sequence specified in the schedule. In this dynamic system simulation, there is a processing unit that monitors and records response time, power consumption, and battery charging activities. The delay specified for each task is used as the time that the subsystem will take to complete the task. The subsystem planner is responsible for allocating the processes to the respective subsystems. ASIM Complete triggers the ASIM module to complete the task. Various observations were observed after simulating the model. The figures below show some related plots. During the simulation, the sensors analyzed the power consumed over time, the amount of battery charge and discharge, the subsystem activity diagram, the latency for each task, and the heat dissipation. In the reports and plots described in this paper, the tasks were performed on subsystems sequentially. There is another option to perform parallel execution of tasks. Since Cubesat’s battery capacity was limited, parallel execution was disabled. The maximum response time observed for the longest task was 485 seconds. The maximum instantaneous power level for sequential execution was observed to be 116.2 watts. Figure 2: Scheduled tasks of the MSV scheduler Figure 3: Subsequent simulation of the generated graphics (parallel execution disabled) Figure 4: Subsystem diagram The MSV schedule lists the orbitals that have no activity in Figure 2. From the simulation results, we can note that there is a break in the graphics Graphics between 0.6 and 0.8 million seconds. This is because there was no scheduled event between orbitals 1001 and 1459 as shown in Figure 2. We do not see a quiescent region during the other inactive orbitals. This is because the missions in the previous orbit were not completed within the deadline and were carried over. This is an indication that the deadline is too short, the processing capacity is insufficient or the power system needs to be increased. Additional analysis and use of the associated diagnostic engine can determine the exact configuration of the three ensuring that all deadlines are met. Figure 5: Statistics observed while enabling parallel execution of tasks In parallel execution, the simultaneous execution of the same task, divided into subtasks, on multiple processors for faster results. Whereas, in the case of sequential execution – even once, from start to finish, without further processing – as opposed to simultaneous or parallel execution. Figure 5 shows the statistics of parallel execution of tasks within an orbit. In this case, the tasks are completed by the deadline and the idle orbitals are shown idle. Execution of tasks from subsystems is completed with lower latency compared to the previous use case. The maximum response time observed while enabling parallel execution was 462.5 seconds. There have been few missions spilled onto nearby orbits. A significant improvement in performance was obtained at the expense of power consumption. Of course, parallel execution requires almost twice as much peak power and will require a much larger battery capacity. It is noted that the maximum power consumed at any moment during operation in parallel execution is 224.6 watts. The reason is that several subsystems are active at the same time. Additional commercial studies can be conducted on other use cases and the analysis of results can be completed in a short period of time. These types of dynamic system models are an asset to systems and hardware engineers. The subsystem painter displayed the active system by highlighting the corresponding color line. Figure 6: Subsystem Diagram We can also see that this trade-off study gives the engineer an idea of how well this design will perform. It also provides a condition for correcting any errors at an early stage of the design effort. Why was the study of trade-offs important? Each orbit is assigned a set of tasks such as special cameras that collect remotely sensed images, satellite-to-Earth communication known as downlink communication, and recording and transmission of instrument readings. The duration of a certain task and the locations are predefined. We noticed that some tasks took longer than expected to complete. For example, orbit 1000 completed in 5.4 million seconds but the actual mission was not completed until 6 million seconds. This indicates that the processor is slow or the battery capacity is insufficient. The ability to meet deadlines is critical to satellite success. This can be explained by an example. For example, a satellite needs to perform remote sensing of a certain area at a certain data time when there is no cloud cover. If the task of capturing the photo is not completed within the deadline, the actual area covered will be different from the target area. Error detection and analysis at an early stage in such cases becomes useful. Conclusion Architectural exploration is a very critical step for CubeSat’s success. CubeSat must comply with specific standards. The dominant factors are its shape, size and weight. Expected to be cheap. Various factors must be taken into consideration before actual implementation. For example, if the designer wants to increase the speed of the processors which in turn can raise the cost of the model. Or to increase power, larger solar panels can be installed. But it increases the weight of the model. Cubesat uses radiation-reinforced electronic components, which are expensive. Testing on these components is more expensive. It should only be used in ingredients whose use is justified. The designer must also ensure that the system runs within the given deadlines. A single environment is required that can finish the entire process and analysis. Each parameter must be analyzed before it can be executed in real time. This can reduce the cost implications to a great extent. Written by Deepak Shankar, founder of Mirabilis Design and Anupurba Mukherjee, Product Market Architect.