1 Introduction

Shorter development cycles along with the increasing complexity of mechatronic systems, such as wind turbines, as well as costly physical testing intensify the need for virtual product development with domain models [1]. Especially in the early phases of product development, virtual validation of product systems and their subsystems is needed, since fixing undetected failures in late development phases requires substantial time and additional costs [2]. In the case of wind turbines for example, the components require changes for adapting them to new requirements for local characteristics of different locations [3] such as changing the rotor diameter and the subsequent drive train components for e.g. higher yield. To ensure functionality, the same engineering tasks concerning e.g. strength, fatigue or efficiency have to be performed repeatedly by means of tests. With every change and in every test, all interactions between the components are checked to ensure operational reliability and safe operation.

Virtual product development using function-oriented model-based systems engineering (MBSE) is a promising approach to manage the system complexity and enable efficient virtual testing based on domain models [4, 5]. Central element of the MBSE approach is the development of so-called system models which are virtual multi-domain descriptions of the system of interest and its sub-systems [6] which promises significant efficiency improvements in product development [7]. The system model contains all formalized information of the system and its interactions as well as relations from requirements up to the domain models and the final product. As modeling language for system models, the standardized and graphical modeling language (SysML) is well-suited and widely used [8]. Both simple analytical and complex numerical domain models for virtual testing can be integrated into SysML system models and executed with the parameters or values from the system model [4].

To perform an engineering task using virtual testing workflows, a single domain model is usually not sufficient, but rather several models are required in a pre-defined sequence [9]. These models typically address different (sub-)system levels and their parameters in the system model (wind turbine, drive train, bearings, …). There are already approaches to describe virtual testing workflows over several hierarchy levels using function-oriented system models [10,11,12]. However, these are not modular, only valid for the specific use case and are therefore difficult to be efficiently reused. Consequently, the potential of virtual testing based on system models and virtual testing workflows is not exploited yet. To utilize the potential, this paper presents a new modelling technique for workflows in function-oriented system models. Using the modeling strategy, modular and reusable workflows can be developed for technical systems of any size. Larger workflows can be combined from sub-workflows in a modular way and virtual tests can be performed efficiently across different hierarchical levels.

The paper is structured as follows: In Sect. 2 an overview of the state of the art regarding workflows in system models is given. Section 3 describes the problem of the current workflow modelling approaches. In Sect. 4 the solution approach is presented. The application of the approach is presented in Sect. 5 and discussed in Sect. 6. Summary and outlook are given in Sect. 7.

2 State of the art

Virtual test procedures can be automated by connecting several domain models in so-called workflows. There is a variety of approaches to develop such workflows by interconnecting models and parameters, examples are given in ref. [13,14,15,16,17,18,19]. However, these approaches do not address the MBSE approach: There is no link to parameters of the functional architecture and therefore the data is not centrally organized. Furthermore, the workflows are usually limited to domain-specific tools and software interfaces.

The following section therefore focuses on approaches for modeling workflows in MBSE system models. By using, for example, Cameo systems modeler to create system models, a variety of domain models can be connected to the system models via interfaces, which means that the workflows are not limited to domain-specific tools. MBSE system models are often developed in the graphical modeling language Systems Modeling Language (SysML). In principle, workflows could be implemented in different workflow modeling languages in those system models. However, the use of SysML for both system model and workflows holds major advantages, since the parameters of the functional architecture can be accessed and thus both system model and the workflows can be modeled centrally on a consistent data basis. Therefore, first of all the necessary SysML basics are briefly explained and then the state-of-the-art methods are described [20].

In SysML, there are different diagram types (requirement, structure, behavior) to represent the properties of technical systems [21, 22]. Basically, in workflows one or more simulation tasks are executed in a sequence. To model such workflows in SysML system models, behavior diagrams are used. SysML provides four different behavior diagrams (activity, state machine, sequence, use case). In the following, the activity and sequence diagrams are briefly presented, since they are used in the solution approach (see Sect. 4) and are also used in the current modeling approaches for workflows in system models. Modelling details can be e.g. obtained from [21, 22].

The most prominent behavior diagram is the activity diagram (see Fig. 1a). With the activity diagram sequential behaviors within a system can be expressed. The activity diagram is built by combining one or multiple activities, linking them with object and control flows. With object flows parameters and values can be transferred from one activity to another. Control flows define the order of the activities. In an activity, in principle, any tasks can be performed. For example, parameters in the system model can be modified, domain models can be controlled, or simple calculations can be performed in the activity itself. Even complex sequences can be modeled by using loops and decisions.

Fig. 1
figure 1

Examples for a SysML activity diagram (a) and a sequence diagram (b)

Full size image

Activity diagrams do not indicate which system component executes an activity. This aspect can be modeled in sequence diagrams (see Fig. 1b).

In sequence diagrams, the system components (i.e. subsystem or model) are represented by so-called lifelines. Messages are used to control interactions between system components. This enables the exchange of information, but also controls which model of which system or subsystem needs to act. Therefore, compared to activity diagrams, sequence diagrams can be created and used at any hierarchical level of the system model. For function-oriented SysML system models, several approaches for modeling workflows with the integration of complex domain models exist [10,11,12, 23,24,25]. The approaches usually use activity diagrams to model the workflows in system models. In those approaches, domain models are triggered directly via the workflows and parameter relationships are modelled in the activity diagram. During this process, predefined parameters are read in from the system model, domain models are then executed and values are calculated. After that these new values are updated in the system model (see Fig. 2). This process is done in activity diagrams using object flows and pins.

Fig. 2
figure 2

Schematic illustration of current modelling approaches for workflows in system models. (According to [10])

Full size image

In [10] and [24], the parameters are modeled in the workflow across several system levels and the system hierarchy is not specifically addressed. The workflows are therefore explicitly valid for the specific system and for the specifically modeled activity. Changes in the system models’ components or in the parameters cause the workflows to no longer function as intended because the workflow does not update automatically and the relations are no longer valid.

3 Problem formulation and objective

The state of the art reveals that there are already some approaches to model workflows in function-oriented MBSE system models. However, several shortcomings emerge from these approaches. Workflows in the presented approaches are modeled at the top system level but refer to the underlying system levels’ domain models and their parameters. The workflows thereby combine several system levels and reference the parameters from all system levels in one single workflow. Due to the interwoven relationships in the overall system, the workflows then only keep valid in an identical system model. The workflow itself or sub-workflows cannot be reused in new system models without manual adaptation. The current workflows are not structured according to the functional architecture of the system model, which makes functional testing challenging.

Another problem arises from the situation that parameter relationships are explicitly modeled in the workflows via object flows rather than utilizing the existing parameter relationships that are already modeled in the system model. In consequence all relationships between all system components, models and parameters must be modeled manually in the workflow. This leads to the following challenges: On the one hand, this modelling process requires a lot of effort. On the other hand, it is prone to errors. Especially when changes are made to the system model, parameter relationships must be analyzed and modeled again.

In summary, there is currently no modeling method for reusable and modular workflows in function-oriented MBSE system models that can be integrated at different system levels and recombined and interconnected at higher system levels to form new workflows. Hence, modeling and using virtual testing based on system models are currently hindered. Therefore, the research questions addressed in this paper are:

  • How can (sub-)workflows in system models be modeled considering the aspect of reusability?

  • How can the (sub-)workflows in system models be connected over several hierarchy levels to create superordinate workflows and how can emergence effects be considered?

The overall goal of the paper is the development of a modeling methodology for modeling and organizing reusable and modular workflows in system models as shown in Fig. 3. Sub-workflows are created in each hierarchy level for their system element and reference only the parameters that are related to that system element. As a result, the workflows are structured according to the functional architecture and functional testing should easily be possible. The workflows can be reused independently of the surrounding system context and architecture of the system model. Workflows should be furthermore designed to use parameter relationships from the existing system model and do not require manual re-modeling of parameter relations. In addition, the sub-workflows should be able to be easily combined in larger systems without requiring additional effort.

Fig. 3
figure 3

Goal of this paper for workflow modelling in system models. System model 1 and system model 2 indicate two different system architectures. Both system model architectures can utilize the same sub-workflow to build higher-level workflows

Full size image

4 Solution approach

The following section presents the solution approach for modular and reusable workflows. The solution approach is summarized in Fig. 4 and consists of four steps. In the first step, a function-oriented system model is according to the MBSE modeling method motego (previously known as “MSE Architecture”) is required (step 1). In the second step, modular sub-workflows are developed within the individual system levels. In these sub-workflows it is specified which domain models of the individual system component shall be executed by the sub-workflow. In the third step, modular sub-workflows are developed according to the same principle in all system levels by selecting which domain models to execute. In the fourth step, the modular sub-workflows are combined in a modular way to create higher-level workflows. The same procedure can be continued and thus new workflows can be combined in a modular way. Thus, the procedure can be applied at all system levels and the sub-workflows can be used in new system models without modification. The individual steps are explained in detail below.

Fig. 4
figure 4

Solution approach for creating modular and reusable workflows in system models

Full size image

Step 1: The new modeling approach for the workflows is based on the utilization of a function-oriented MBSE system model using the motego method. In contrast to other modeling approaches, this method offers the opportunity to systematically overcome the above-mentioned deficits. In principle, for structuring and building SysML system models different modeling methods exist. All approaches focus on the function-oriented product description within the system model via requirements, functions, and logic up to the product. However, major differences lie in the representation of the logic layer which is crucial for integrating domain models and building workflows. Only the motego method [4, 10, 26,27,28,29] offers the necessary degree of model depth in the logic layer. The motego method describes the logic layer on a parameter level and integrate both simple and complex domain models into this layer in a structured way and thereby enable virtual testing.

Motego system models are structured according to the RFLP architecture (Requirements, Functions, Logics, Product) (see Fig. 5). For each function, a technical solution (Solutions) is identified that fulfils it. For elementary functions this is a so-called SolutionElement and for higher-level functions it is a SystemSolution. The technical design and physical description of the solution are done in the logic layer which can also be called as the technical solution. Besides the physical effect and the active surfaces, the domain models are linked to the solutions. Furthermore, the workflows that belong to the respective solution are integrated directly into the respective solution elements. This is a key difference to other modelling approaches, in which the workflows are integrated into the higher system levels and not into the SolutionElements or SystemSolutions. Since the SystemSolutions and SolutionElements are the technical solutions for the corresponding (elementary) functions, the workflows are also organized according to the functional architecture. Finally, by combining the technical solutions for the functional structure, the resulting product is described.

Fig. 5
figure 5

Step 1: Motego method with its RFLP structure. (According to [30])

Full size image

Step 2: The main advantage of the motego method for workflows lies in the details of modeling the solution layer according to [28]. In the motego method parameter relations between the DomainModels are already modeled and the workflows only have to control the order of DomainModel-execution as well as the DomainModel selection. Typically, there are several DomainModels of different fidelities for one Purpose. The model fidelity describes the level of accuracy of the calculated physical quantities. For example, often analytical models have a lower fidelity than e.g. numerical models. Figure 6 shows an example of the modeling of a sub-workflow for a SolutionElement which includes two modelling Purposes with two DomainModels for each Purpose. A Purpose could be, for example, the bearing lifetime for which two DomainModels in different fidelities (i.e. analytical and numerical) are integrated. The exchange of parameters between the DomainModels is achieved by connecting the Purposes via standardized ports (see “ParameterPort” on the left). DomainModels of different fidelities usually require different input parameters. The standardized ports contain the union of all parameters of the DomainModels from one Purpose. In the DomainModels themselves, only the required parameters are connected.

Fig. 6
figure 6

Step 2: Implementation of sub-workflow modules on SolutionElement level in an activity diagram

Full size image

This results in two advantages: First, since the Purpose acts as an empty container for the DomainModels, the DomainModels for a Purpose can be exchanged without any problems and without having to perform parameter links again.

Second, the workflows can then be kept simple, because only the desired models have to be specified in the workflow in the desired order and no parameter relations have to be modeled again in the workflow. The model selection is performed using activity diagrams and the activity diagram is saved in the respective SolutionElement or SystemSolution. Activity diagrams can be used to assign values to system model elements. In this case, activity diagrams are used to assign the desired DomainModel to the Purpose. Figure 6 on the right shows an example of a sub-workflow which selects the DomainModel DM2.1 for purposeE2. With the identical procedure, different workflows can be created for a SolutionElement which specify different combinations of DomainModels in the different fidelities. Workflows can be easily created and stored for different phases of product development. The saved workflow can then be used to test the respective function, regardless of the system context in which the corresponding SystemSolution or SolutionElement is implemented.

Step 3: The sub-workflows are developed in Step 2 and stored in the respective solutions (SolutionElement or SystemSolution) using activity diagrams. These activity diagrams are only valid in their own system context (i.e. SolutionElement or SystemSolution) because the “readSelf” action specifies the system context. Sequence diagrams can clearly define the system context. To be able to use the sub-workflows in other system models and system levels, the activity diagrams are therefore converted into operations and sequence diagrams (see Fig. 7). These operations can then be used in any system level in any system model and the desired workflow can be executed independent of the system context.

Fig. 7
figure 7

Step 3: Creation of a workflow module by saving the sub-workflow in an operation and sequence diagram

Full size image

Step 4: In case only workflows for SolutionElements are developed, the modelling of workflows is finished at this point. At present, a SystemSolution cannot yet be completely described from SolutionElements and their DomainModels. Due to emergence effects, SystemSolutions also contain Purposes and the corresponding DomainModels which aggregate more complex physical behavior for the technical solution.

The development of higher-level workflows in SystemSolutions works as follows: The selection of DomainModels for SystemSolution Purposes is done exactly as in Step 2 in an activity diagram. In the same activity diagram, the operations from the lower-level SolutionElements can be integrated (see Fig. 8). In this way, the (sub-)workflows can be combined with each other in all system levels. The resulting workflow can then be part of a higher-level workflow of a higher-level SystemSolution. The procedure shown can then be repeated, to build higher-level workflows.

Fig. 8
figure 8

Step 4: Composition of higher-level Workflows in SystemSolutions

Full size image

5 Demonstration of the approach

In the following section, the modeling approach for workflows is demonstrated using two examples from the wind turbine development use case. A wind turbine system is a representative technical system that has components distributed across multiple structural levels and multiple domains [31, 32]. To demonstrate the approach, the focus lies on the mechanical drive train of the system. The focus lies on the mechanical drive train of the system, as the damages to the drive train are the main contributor to wind turbine downtime [33, 34]. For example, when the wind turbine system is redesigned (e.g. changing the rotor diameter), this results in a significant change in the loads acting on the rotor bearing arrangement, which leads to the failure of the wind turbine components and even the whole system. Therefore, for testing technical requirements of a wind turbine, in particular the verification of the utilization rate of the main shaft as well as the bearing lifetime are essential [34]. For these two use cases, workflows are developed as follows.

5.1 Wind turbine hierarchical system model

As described in Sect. 4 the motego system model is the foundation for developing workflows. The wind turbine system model applies the motego method for function-oriented system modeling and is created by using the modelling software Cameo Systems Modeler (CSM) [22]. The wind turbine system model integrates domain models from external engineering software into its solution layer, thus enabling high-accuracy virtual testing.

Figure 9 shows an excerpt of the SystemSolutions for the different layers of a wind turbine system, including the WindTurbine, Drivetrain, RotorBearingArrangement, Bearing, and Shaft. In this case, the WindTurbine SystemSolution contains the “Purpose” named WindLoadAnalysis for simulating and analyzing the motion and loads of wind turbines under the wind loads. The “Purpose” named LoadCalculation4Shaft and LoadCalculation4Bearing are for the post-processing of simulation results, in order to calculate the equivalent loads on the bearings and shaft, which are transmitted by the rotor. The RotorBearingArrangement solution contains the “Purpose” named StressCalculation for the calculation of stresses in the shaft, which is assembled with bearings. The Bearing solution contains the “Purpose” named FatigueCalculation for failure analysis of bearing. The Shaft solution contains the “Purpose” named UtilizationRateCalculation for calculating the utilization rate of the shaft. These Purposes are realized by the domain models (here only engineering models) and specified in different degrees of fidelity. Taking the Purpose UtilizationRateCalculation as an example, the UtilizationRateCalculation can be inherited and specified by the domain model ModularCalculation which is created in engineering software KISSsoft, or the domain model NumericalAnalysis created in the software Excel with numerical analysis functions.

Fig. 9
figure 9

The solution architecture of the wind turbine in block definition diagram

Full size image

Relevant parameters are connected with specific constraints through connectors so that the parameters in the system model are passed to the external domain model for calculation. These domain models can participate in different virtual testing workflows, and the relevant calculation results can be used for requirement verification or used as inputs for subsequent domain models.

5.2 Cross-hierarchical workflow

This section demonstrates how to implement a cross-hierarchical workflow through a shaft utilization rate testing case of the wind turbine system. This section describes the utilization rate testing workflow for a shaft of the wind turbine system. In the cross-hierarchical workflow, the “ValidationWorkflow” is designed in the activity diagram to execute the “Workflows” corresponding to the domain models sequentially. The “ValidationSubSystemWorkflow” is designed in the sequence diagram to execute the “Workflows” of sub-solution and merged into the “ValidationWorkflow”, and the “Workflows” corresponding to the domain models are executed sequentially. These Purposes and therefore also the domain models are connected to each other through standardized ports in the internal block diagram to form a model chain, which enables the transfer of simulation parameters (see Fig. 10).

Fig. 10
figure 10

Model chain of the shaft utilization rate testing for transferring parameters

Full size image

As shown in Fig. 10, there are four Purposes of domain models which are linked with each other. At first, the simulation outputs of the WindLoadAnalysis are used for post-processing in LoadCalculation4Shaft to calculate the equivalent loads on the shaft. Meanwhile, the rotation speed from the WindLoadAnalysis and the loads from the LoadCalculation4Shaft are transferred as inputs to the StressCalculation to calculate the critical stresses on the shaft. At last, the stresses are transferred as inputs to the UtilizationRateCalculation to obtain the utilization rate of the shaft.

Figure 11 shows the designed workflows corresponding to the above-mentioned Purposes. When performing the “ValidationWorkflow”, engineers run the simulation in the context of the wind turbine system, which contains the model chains, so that the parameters can be transferred automatically during the simulation. The model Purposes need to be initialized at the first step. To perform “Workflow” across hierarchical context levels, a “ValidationSubSystemWorkflow” is created in a sequence diagram and combined with other “Workflows” in activity diagrams. In this case, when the “ValidationWorkflow” Shaft_UtilizationRate_SubTesting is executed during the workflow, the associated sequence diagram will be invoked. And then, the “Workflow” Shaft_UtilizationRate_Testing is executed as an operation in the sequence diagram. In the “Workflow” Shaft_UtilizationRate_Testing, engineers can select the appropriate fidelity domain model (i.e.: NumericalAnalysis (Excel) or ModularCalculation (KISSsoft)) by designing the decision node. And then, the domain models in the model chain can be executed while saving the simulation results by conducting the activity Parametic Simulation & Saving Results.

Fig. 11
figure 11

A cross-hierarchical workflow for shaft utilization rate testing

Full size image

5.3 Reusability of workflows

To demonstrate the reusability of the workflows, this section presents another virtual testing workflow in the wind turbine system, i.e.: bearing lifetime workflow. Similar to the testing workflow in Sect. 5.2, the corresponding “Workflows” are sequenced in the activity diagram to execute the domain models, where the “Purpose” WindLoadAnalysis of the wind turbine can be used not only for the shaft utilization rate testing but also for the bearing lifetime testing. And the modular designed “Workflow” WindTurbine_ WindLoadAnalysis_Testing can be reused in the different testing workflows in the same context (see Fig. 12).

Fig. 12
figure 12

The model chain and the workflow for bearing lifetime testing

Full size image

As shown in Fig. 12, there are three Purposes of domain models which are linked with each other in the bearing lifetime testing. At first, the simulation outputs of the WindLoadAnalysis are used for post-processing in LoadCalculation4Bearing to calculate the equivalent loads on the bearing. Meanwhile, the rotation speed from the WindLoadAnalysis and the loads from the LoadCalculation4Bearing are transferred as inputs to the FatigueCalculation to calculate the lifetime of the bearing.

6 Discussion of the approach

The modeling approach presented in Sect. 4 was successfully demonstrated in Sect. 5 on a complex multi-level system (wind turbine drive train). The demonstration example highlights the advantage of this approach: The parameter relationships are already modeled in motego system models via the internal block diagrams and the activity diagrams only specify the model choice and the model fidelity. This approach ensures that the DomainModels outside of the system model can be executed without the need to manually model parameter relations in the workflow modeling process. Both simple (Excel, analytical Matlab models) and complex external simulation software (KISSsoft, Simpack) was successfully connected to the system model.

Due to the close cooperation between internal block diagrams and activity diagrams, workflows in the activity diagrams could be kept simple and compact. Sequencing in external simulation software is performed via the activity diagrams, and all parameters are orchestrated via the system model as a single source of truth. This not only saves modeling effort, but also ensures that subsequent workflows will not be affected when the system architecture (i.e. system elements, DomainModels, parameters, relations) is modified.

The approach shows that the sub-workflows can be easily reused in other workflows by storing them in operations and sequence diagrams. This enables combining different sub-workflows into higher-level workflows in order to perform virtual tests for different goals. By modeling and storing the sub-workflows in the SystemSolutions and SolutionElements, the (sub)workflows are organized according to the functional architecture. This gives the workflows a clear location within the system model.

Besides the benefits of the approach, potential for further improvement was identified. The workflow developer must have precise knowledge about the sequence of the DomainModels. If the fidelity changes, the order of the models might be affected or additional models might need to be added to the workflow. At last, from the architecture point of view, when the system and system model become complex, the simulation process becomes slow. When workflows run a simulation model in a large system, interfaces throughout the model architecture need to be reinitialized whenever model fidelity changes. This process can take some time and thus decreases the performance of the workflow. However, typically the workflow runtime is dominated by the computation time of the DomainModels, which is not influenced by the connection to the system model. This aspect might be addressed by the modeling software vendors.

7 Summary and outlook

Virtual tests based on function-oriented MBSE system models are well-suited for the efficient product development of increasingly complex technical systems. To execute the virtual tests, so-called workflows are modeled in the system model which combine the different domain models and sequence them.

Currently, the workflows for function-oriented MBSE system models are modelled in a way that reusing them is challenging. Therefore, the aim of this paper is to develop a modeling method for modular and reusable workflows. The approach is based on the utilization of the motego modeling method. By using the motego method, all parameter relationships between the models are already present in the system model. The workflows then only need to control the order and fidelity choice of the domain models in activity diagrams. As a result, the workflow structure can be kept simple. By storing the workflows as modules in operations with sequence diagrams, they can be integrated into any system level and system model. At the same time, the workflow modules can be combined to form higher-level workflows. The approach is demonstrated based on a small element of a wind turbine development use case (shaft utilization rate workflow and bearing lifetime workflow). In summary, the approach could be successfully applied to the wind turbine use case. The developed workflows could be easily combined to higher-level workflows and thus enable efficient function-oriented and hierarchical virtual testing in system models.

The drawbacks of the approach to achieve modular and reusable workflows are mainly that it requires system models in a high detail level that are built with the motego modeling method. The approach cannot be transferred to other modelling approaches yet. Currently, linear sequential workflows are studied, where the models are connected in a series. In future work, the approach will be extended in order to handle more complex workflows with e.g. loops and decisions. Furthermore, the approach will be extended to cover also optimization workflows.