# Towards Hierarchical Workflows in SysML to Support Virtual Validation of Technical Systems
## 4 Method
### The Framework of Virtual Validation Workflows Based on the Functional Architecture
#### 4.1.3 Implementation of the Proposed Virtual Validation Workflows in SysML  
The virtual validation process consists of the continuous activities of engineers. The activity diagram provides the ability to model a process in SysML and represent it as a continuous flow of activities. Therefore, a virtual validation process can be modeled in the activity diagram (i.e., virtual validation workflow) in this work. Actions serve as the foundation for activities, outlining their execution process. In this research, a notable type of action is the \"Call Behavior Action\", which invokes a behavior (assumed to be an activity or state machine) when executed. The symbol for \"Call Behavior Action\" (see Figure 5) is a round-cornered box containing the action and invoked behavior name separated by a colon: \"Action name: Activity name\" [22].  
Figure 5: The framework of the hierarchical functional validation workflows in SysML.  
Input and output pins, represented by small rectangles surrounding the action, receive items containing relevant data information (e.g., validation results). Data consists of data name and data type, separated by colons. The square brackets after the data type contain the multiplicity of data values, and the asterisk indicates that the number of data values can be arbitrary. Object flows transfer items between pins and can be used to route items from the pin of an activity to the pins of its sub-actions or to connect pins of other actions directly. An object flow is shown as a solid line connecting the flow's source to its destination, with an arrow pointing toward the destination.  
Control flows, represented by dashed lines with arrows, convey the sequence and timing of actions executed within an activity. When a control flow connects two actions, the destination action cannot commence until the source action is complete. Control nodes, including join, fork, decision, merge, initial, and final nodes, can synchronize incoming concurrent flows and decide incoming alternative flows, thereby further specifying the order of actions.  
In Figure 5, the nested virtual validation workflows of the WT system are shown in the activity diagram. Each function in the system's functional architecture corresponds to a virtual validation workflow. As an example, the \"Virtual Validation Workflow\" activity of the function \"Convert wind energy to electrical energy\" contains two sub-virtual validation workflows for validation of the functions \"Convert wind energy to mechanical energy\" and \"Convert mechanical energy to electrical energy\", respectively. Each function corresponds to a standardized design virtual validation workflow. The standardized design ensures that the virtual validation workflow can be easily redesigned, with related functions being reused in different systems.  
Figure 6 shows that the virtual validation workflow framework can be semi-automatically extended and redesigned in SysML. Engineers can easily drag and drop existing \"Virtual testing workflow\" activity from the corresponding function SysML package into \"Action 1: Check if the function is fulfilled by corresponding solution\" to agilely add or replace any virtual testing process with a specific test need. In addition, engineers can also easily drag and drop the existing \"Virtual validation workflow\" activity from the corresponding virtual testing SysML package into \"Action 2: Sub Level Functions\" to agilely add or replace any virtual validation process for a specific function. It is worth noting that when a new workflow is added (either a virtual validation workflow or a virtual testing workflow), a new workflow result is generated correspondingly. These results should also participate in logic gate calculations and be checked.