## 4 Results and Discussion  
As highlighted in the previous section, the first step is to study and analyse the functional architecture related to the studied system. The tool used for the modelling is Papyrus, an open-source MBSE tool based on the system modelling language (SysML). In the study case, the rover should touch different waypoints, each with a scientific rating related to observing or sampling the site. The objective of the simulation is:  
* To verify whether the identified operational capabilities cover all the functions that the system should perform for a successful mission;  
Figure 5: Example of path evaluated with the “open vehicle routing problem with reward with a distance constraint”. The numbers at each waypoint indicate the associated scientific reward. The minimum covered distance is evaluated as Euclidean distance, and it is equal to 327 m.  
Figure 6: Example of path evaluated with the “open vehicle routing problem with reward with a distance constraint” routing problem. The numbers at each waypoint indicate the associated scientific reward. The distance between waypoints is evaluated with an A\({}^{\star}\) algorithm, and it is equal to 360 m.  
To check whether the rover has enough resources to complete its mission;
* To understand how the rover will plan its mission to touch the different waypoints if given the freedom to decide its own plan. The operational capabilities identified in Section 3.1 are the starting point for the functional architecture. Their relationships with physical elements can be visualized in a use case diagram, such as the one in Figure 7. At the same time, their interactions can be investigated, leveraging an activity diagram, as in Figure 8.  
The payload team provides a set of mission goals associated with observing or sampling a site of interest on the map. The mission team may provide the system with further directions, or they can initiate communication with the system. The system and its software or hardware components should take care of most of the operational capabilities, making the system highly autonomous. The subsystems are modelled as secondary actors. The primary actors invoke the use case, while the secondary actors participate in the use case by performing actions, as analysed in [59]. After the initial modelling of the functional architecture and identification of the main elements of the physical architecture, it is possible to parametrize the functional model. In this simple example, the different operational capabilities are directly linked to the different hardware that can perform them. The parametrization can be manual, or the XMI file in the backend of Papyrus can be extracted and converted into a tabulated and human-readable file with:  
* The list of functions performed by the system. * The physical components' parameters associated with the functions. * A time specification for the function. The time for the operational capability \"navigate to goal\" depends on the distance to be covered and the exploration system velocity (a parameter of the mobility system set to 0.1 m/s for the presented simulations). Similarly, the amount of data to communicate or time to recharge the battery drives the time allocated to these operational capabilities. The time specifications for the \"observe target\" and \"sample target\" are set to be around 10 min. While the \"check resources\" is an almost instantaneous loop evaluating whether the system has enough resources to perform a specific operation. This check also lowers the number of possible outcomes in the MCTS algorithm. Figure 7: Set of operational capabilities typical of exploration system. Figure 8: Activity diagram view of a generic exploration mission with a high degree of autonomy. Tables 2 and 3 show the results of the analysis on the parametrization with respect to the power consumption and data generation. The operational capabilities' names in the tables are shortened to just the verb, instead of the conventional verb plus noun that is typical of systems engineering.