# Towards Hierarchical Workflows in SysML to Support Virtual Validation of Technical Systems
## 4 Method
### The Framework of Virtual Testing Workflows Based on the Functional Architecture
#### 4.2.2 Implementation of the Proposed Virtual Testing Workflows in SysML  
The previous chapter created a nested framework for virtual testing workflows based on modular simulation activities. This chapter describes how to use this framework to easily select different simulation activities and execute these simulation activities step by step in an iterative manner based on SysML. This enables engineers to automatically design and easily execute virtual test workflows that adapt to different test scenarios. As mentioned earlier, virtual testing workflows typically perform a series of simulation activities in a specific order. In order to automate the entire virtual testing process step by step, workflow designers usually need to provide the necessary model information for each step of the virtual testing process. Designers can pre-give the information of these domain models according to the classification of the domain models, such as the scope of the model, the purpose of the model, and the fidelity of the model, so that the workflow can automatically iteratively run according to the customized sequences. When the scope,  
Figure 8: The nested framework of virtual testing workflows based on the model classifications. purpose, and fidelity of the model are determined, the required simulation activity of the domain model is also determined. After the sequence has been set up, the virtual testing workflow becomes reusable. The model information can be pre-set in the instances of the system model so that the virtual testing workflows can be easily re-executed by engineers. Figure 9 shows how different virtual tests can be executed in SysML through an iterative process based on the architecture. An action named \"Workflow Steps Information\" is designed to read required domain model information and pass them through the pin to the framework that contains all the simulation activities. To avoid the repetitive creation of simulation activities, this study designs a unique corresponding simulation activity for each domain model in the framework. The workflow automatically finds and executes the corresponding simulation activity based on the model information, which is regarded as the completion of a simulation process. The above process is repeated by executing an iterative loop and the model information of each step is obtained in turn to sequentially execute the relevant simulation activities in the workflow. Figure 9: Execution of the simulation activities in the workflow through an iterative loop. Figure 10 shows how to implement the architecture in the SysML based on the model information to achieve automatic decision-making. Taking the bearing fatigue test as an example, when the virtual test starts, the model information to be executed in the first step (i.e., \"Wind Turbine\"; \"LoadAnalysis\") is passed to the framework. A conditional node action called \"Domain models of WT\" is created at the scope \"Wind Turbine\" of the nested framework to determine whether to execute the domain model in the Wind Turbine scope. A conditional node comprises a collection of clauses, each with a test and a body, functioning similarly to an \"if\" statement in programming languages, where the action is performed only under specific conditions. When the conditional node begins execution, the test portion of the clause is carried out; if the test conditions evaluate to \"True\", the clause's body segment is executed. Specifically, when the scope information is \"Wind Turbine\", the action \"Purposes\" will be executed, which encapsulates all domain model simulation activities within the \"Wind Turbine\" scope. Another conditional node action called \"Domain models of WT's sub scopes\" is also created in parallel in this scope to determine if the domain model that needs to be executed is in the sub-scope of the \"Wind Turbine\" scope (e.g., Nacelle). This goes on until the required model scope is found.