## 4 Results and Discussion
The values in the tables have been identified through an analogue system tested on Earth during the IGLUNA analogue mission. The details of the IGLUNA testing are provided in [60]. They can be used as reference values for a small rover (up to 30 kg), and they agree with the available literature on small planetary robotic platforms, as in [37; 38; 61]. The IGLUNA rover has two batteries, one dedicated to the mobility system and one for the payload. The rover base is a commercial platform called _Leo Rover_[62]. It has its own battery dedicated to navigation capabilities. The base is then enriched with a set of sensors (the payload), the robotic arm, a new onboard computer (connected to the bottom one) and a dedicated battery for the payload. After defining the MBSE model, the designer can define the variables that identify the system's state. The state should provide the system with all the needed information to decide on the best next step. For a planetary exploration system, this state has been defined as described in Table 4:  
* Waypoint to visit indicates which waypoints have been visited and which have not during the given simulated episode. * The last action performed poses a limit to which actions can be chosen at a lower level of the tree based on the provided flight rules. * The current waypoint is an indication of where the system is at a given moment. It is most useful during debugging. \begin{table}
\begin{tabular}{l c c c c c} \hline \hline
**System** & **Navigate [W]** & **Observe [W]** & **Recharge [W]** & **Sample [W]** & **Comm. [W]** \\ \hline OBC & 6 & 6 & 1 & 6 & 1 \\ \hline Mobility sensors & 3 & 0 & 0 & 0 & 0 \\ \hline Mobility hardware & 14 & 0 & 0 & 0 & 0 \\ \hline TTC & 7 & 7 & 7 & 7 & 9 \\ \hline Tracking camera & 2 & 0 & 0 & 0 & 0 \\ \hline Depth camera & 4 & 4 & 0 & 4 & 0 \\ \hline Robotic arm camera & 0 & 0 & 0 & 0.4 & 0 \\ \hline Robotic arm & 0 & 0 & 0 & 7 & 0 \\ \hline Total power & 36 & 17 & 8 & 24.4 & 10 \\ \hline \hline \end{tabular}
\end{table} 
Table 2: Power consumption per operational capability per component in [W] (Comm is the abbreviation for Communicate). \begin{table}
\begin{tabular}{l c c c c c} \hline \hline
**System** & **Navigate [kps]** & **Observe [kps]** & **Recharge [kps]** & **Sample [kps]** & **Comm. [kps]** \\ \hline Telemetry & 0.3 & 0.3 & 0.3 & 0.3 & 0.3 \\ \hline LiDAR & 80 & 80 & 0 & 0 & 0 \\ \hline Robotic arm camera & 0 & 25 & 0 & 25 & 0 \\ \hline Tracking camera & 150 & 0 & 0 & 0 & 0 \\ \hline Depth camera & 0 & 180 & 0 & 180 & 0 \\ \hline Total data & 230.3 & 285.3 & 0.3 & 205.3 & 0.3 \\ \hline \hline \end{tabular}
\end{table} 
Table 3: Data Generation per operational capability per component in [kbytes/s] (Comm is the abbreviation for Communicate). * The battery capacity, storage capacity and data volume capacity are linked to the constraints the system should not overshoot. * The number of recharges, number of communication, idle time, and mission time are metrics used to evaluate the performances of the given scenario: does the system have enough capacity to store the data, or does it need an almost continuous communication? All this information is written as a tuple that defines a specific scenario. At the end of the simulation, a reward characterizes each scenario. The reward defines how appropriate or suitable this scenario is with respect to others, helping the algorithm prune some branches of the tree. During the preliminary design phases, the objective is to study the feasibility of the proposed architecture and operational scenario. During the analysis, the systems' engineers may point toward a near-optimal or optimal solution. In this second case, some time should be allocated to defining the exploration parameter of the MCTS algorithm and the number of samples before deciding on the following best path. However, to test the feasibility of the design, a near-optimal solution can be satisfying.