## 2 Related Work  
Operational scenarios are usually studied as a part of the Concept of Operations (ConOps) analysis, as investigated in [17]. ConOps describe how the system will be operated during all various life cycle phases to meet stakeholder expectations [18]. They include evaluations of mission phases, operation timelines, operational scenarios, end-to-end communications strategy, command and data architecture, operational facilities, integrated logistic support and critical events [17]. In [17; 19], ConOps are used to flow down requirements for complex aerospace products as habitable modules or transfer vehicles. Figure 1: MBSE to MDP theoretical workflow. Beyond the requirement definition, ConOps guarantees that the technical team thoroughly knows the stakeholders' expectations and how the product may meet them [20]. If there are gaps or ambiguities in the requirement definition, the ConOps study should identify them and lead to additional refining rounds of the initial list of stakeholder objectives [20]. In addition, thinking through ConOps and use cases frequently reveals requirements and design features that would otherwise go unnoticed, as investigated in [20]. ConOps analysis is the design step when the systems engineers define the level of autonomy that will characterize the mission [21]. The operational timelines related to the space segments, the operational scenarios, and the command and data architecture are the ConOps's evaluations mostly affected by autonomy. On the other hand:  
* The mission phases depend only on the external operational environment;
* The end-to-end communications strategy depends on the overall mission architecture, existing relay satellites and celestial bodies' positions;
* The operational facilities and the integrated logistic support depend on the mission context, stakeholders, and goals. The study of operational scenarios would include elements of logistic support. The focus would be on how the operator interacts with the system when autonomous. This interaction can be viewed as sharing responsibilities, as detailed in [21]. ConOps have established themselves as the analysis to help design autonomous systems during conceptual design, as highlighted in [1; 22; 23]. For example, the authors of [1; 22] employ operational analysis to pinpoint the requirements associated with different levels of autonomy and human-system interactions. Furthermore, different authors start looking for behavioural patterns and protocols to generalize the testing and early design definition of autonomous systems' operations [24; 25]. Moving toward a more model-based approach, ConOps' operational scenarios can be captured in the MBSE functional architecture highlighting operational capabilities, activities, or actions the system can perform. Different studies on autonomous cars have started leveraging ontologies and MBSE to define testing scenarios for operational capabilities of the autonomous AI agent [23; 26]. The objective is to avoid expensive re-design later in the system's life cycle by introducing operational tests during conceptual design [23]. All of these studies, model-based or not, leave the verification and validation of the ConOps to a board of experts instead of a set of operations-related simulations. By leveraging MBSE, it should be possible to relay information to other tools to test the ConOps and better define requirements and mission architecture. Authors such as [15] emphasize how simulations effectively detect possible defects at an early design stage when changes are less expensive. In [15; 27], executable MBSE models based on SysML are employed for requirement verification. The underlying idea of the executable systems' engineering method (ESEM) is to create an MBSE model that ties together different subsystem models and the output of domain-specific practices such as CAD or CFD modelling. As stated by [15], with executable models, it is possible to debug a described behaviour checking whether it matches what the designer meant to capture.