The analysis of energy scenarios shows that wind energy will play an increasingly important role in the energy supply system in the future [1
]. A wind turbine (WT) is a multidisciplinary system including mechanical components (e.g., drivetrain), electrical components (e.g., generator), control components (e.g., controller), etc., that converts wind energy into electrical energy. These components are closely interconnected with each other to always ensure high-performance conditions for the WT system in different wind conditions [2
]. Therefore, in the process of multidisciplinary system (such as a WT system) development, engineers are required not only to focus on the design of their system within the specific discipline, but also to consider the dependencies with other disciplines in order to achieve a balanced system solution [4
]. However, with the increase in complexity in the later stage of system development, there are more and more implicit dependencies between designs. In the face of the rapid growth in the scale and complexity of multidisciplinary systems, being able to develop systems under ever-faster changing and more individual market requirements is becoming more and more challenging [5
]. In this case, when the engineers redesign in order to meet specific requirements or solve the occurrence of a failure risk, it often results in additional unknown failures caused by the design changes. As an example, developers need to redesign mechanical components (e.g., drivetrain) of WTs to be able to transfer more loads. An appropriate range of rotational speeds ensures the appropriate loading of the redesigned drivetrain. However, the design parameters in the aerodynamics and the control models also need to be considered in order to adjust the rotational speed of the WT rotor [6
]. This requires more efficient cooperation between engineers and timely communication of data changes. Therefore, it is becoming more and more important to find a communication method to maintain the seamlessness of data across the various disciplines involved to ensure that a cost-effective WT system is designed to best serve the needs of stakeholders.
In order to ensure the seamlessness of data in the development of multidisciplinary systems such as WTs, system development methods must continue to evolve. Model-based Systems Engineering (MBSE) provides an interdisciplinary collaborative approach for deriving, developing, and testing systems that meet customer expectations in a more efficient way [7
]. The term Model-based Systems Engineering (MBSE), as introduced by International Council on Systems Engineering (INCOSE), is focused on formalizing the use of models in the field of Systems Engineering to support system requirements, design, analysis, verification, and validation processes throughout a system’s lifecycle [9
]. The MBSE approach for addressing issues in a multidisciplinary system development process has the potential to guide WT projects to address the above-mentioned challenge. The value of MBSE is based on the fact that all system-related information is configured and linked in a central repository for management. This feature enables domain models, parameters, and related design information from a range of different disciplines to be connected to each other and provides transparency of information over all disciplines. This interconnection can support the automatic propagation of design changes, consistency checks, and failure identification.
The application of MBSE is based on three core pillars which are language, tools, and methods [10
]. One language for MBSE is SysML, which provides a general modeling language for its implementation and is commonly used by many developers [11
]. The OMG has developed the SysML as an extension of the Unified Modeling Language (UML) to support systems engineering activities by creating and managing models of systems using well-defined blocks, linkages, and other visual constructs. The system model as defined with SysML describes a complete view of the multidisciplinary system under development, including its requirements, behaviors, structures, parameters, and their interactions for the design and validation of systems [12
]. This system model is used as a centric platform to communicate with various stakeholders [15
]. SysML developed by the Object Management Group (OMG) is widely used for abstract modeling of systems engineering problems in the industrial field [16
]. A specific SysML modeler, called Cameo Systems Modeler (CSM) [17
], used in this work allows the designer to integrate with and execute an external evaluator (e.g., MATLAB), which provides the possibility of interaction between the existing domain simulation models in various simulation tools and the centric system model [18
]. Domain model-based modeling ensures that engineers can perform high-precision virtual testing in centric system models to support the virtual validation of WT system. The method describes the standardized system development process and how the language should be used to generate the system model. Several used methods for MBSE are summarized in [20
]. For instance, the Object-Oriented Systems Engineering Method (OOSEM) is a hybrid approach using object-oriented concepts combined with traditional systems engineering methods. It mirrors the classical “V” [21
] lifecycle development model of system design that enables the system engineer to define, specify, and analyze the system among various system views throughout the development process [22
]. The object-oriented techniques improve the traceability and extensibility of systems to adapt to evolving technologies and changing needs. In the case of complex mechatronic systems across multi-domain models, the Cyber MagicGrid approach was proposed by NoMagic [23
]. Cyber MagicGrid is an extension of MagicGrid [24
], which is defined with three layers of abstraction (Problem, Solution, Implementation) and four pillars (Requirements, Behavior, Structure, Parameters). Cyber MagicGrid allows every team member to share information about design parameters about their tasks during the development process at the detailed layer. In [25
], the need for functional system modeling and the necessity of defining hierarchical system functions through SysML elements was observed and the Functional Architecture for system (FAS) method was proposed. Model-based functional architecture description models a system independently of its target technology by transforming the functional elements of modeling information, signals, materials, force, or energy. However, these application methods of MBSE lack a detailed top-down modeling method of systems and there are no traceability links clearly established between system functions and components.
In this work, a practical MBSE method proposed by Jacobs [26
] for function-oriented system development is applied. The advantage of this method over other methods is that it allows for transparent traceability by building explicit interdependencies of system architecture between requirements, functions, and the solution layer on the parameter level. In addition, this method implements the integration between system models and domain models from various engineering disciplines, rather than staying at the conceptual design level. An executable system model integrated with the domain model provides the foundation for virtual validation. In the traditional system development process, validation usually is performed at the end of the development stage [27
]. However, it is hard to make changes in the later stages of development for complex systems, because this often means that they are unaffordable in terms of time or budget or require more effort than designing from the beginning all over again [28
]. Virtual testing provides a way to simulate the physical behavior early in development, which involves simulation of quantitative dynamic behavior of technical system models in a variety of environments and conditions to virtually validate that the system works properly. Virtual testing uses physical behavior models and methods such as finite element analysis (FEA) and multibody simulations (MBS) to create digital domain models of systems, before ever having to create physical prototypes. Some studies have introduced the virtual tests into the above MBSE method to support the system’s virtual validation process [26
However, although the failure identification and virtual validation process can be conducted as early as possible, an experienced engineer is still required to manually sequence the simulation’s activities in various virtual tests. This leads to two issues described in the following. At first, for complex technical systems (e.g.,: WT systems), a complete virtual test of the system always involves various domain models with different system scopes and model purposes, such as fatigue analysis models of mechanical components or short-circuit failure models of electrical components. The dependencies between system designs increase exponentially among a large number of domain models, it becomes more and more difficult to ensure that every relevant virtual test is conducted. Secondly, as the system is further developed, the fidelity of the simulation model will evolve during the development process. In other words, the further the WT development proceeds, the more product parameters will be set, and the higher the level of detail and fidelity the models have. Incoherent simulation activities often require engineers to manually update system parameters based on virtual testing results to ensure data consistency, which is also inefficient and requires tedious work for complex systems. Therefore, there is still a lack of a solution to build structured virtual testing workflows to support the automated virtual validation process. This work aims to provide a method to design structured workflows in system models based on function-oriented architecture, to ensure the detection of the potential failure risks of the system, improve the reusability of the virtual testing workflows, and the efficiency of the validation process.
In order to achieve the above objective, firstly, this work needs to develop a standardized system architecture for system modeling of WT systems. Formal system modeling bridges the gap between requirements, system functionality, and specific technical solutions, thereby supporting data consistency during virtual testing of systems. The domain models also need to be represented in the system architecture to further describe the solution and be linked to external simulation models to guarantee the accuracy of the test results. Subsequently, external simulation models need to be classified to improve the efficiency and reusability of the model in the virtual testing process. Then, this work needs to propose structured virtual testing workflows in the system architecture. The workflows should be able to sequence the simulation activities of the domain models according to the model classification to support the virtual validation of the redesigned system solutions. The workflows should also provide data for domain models, trigger simulations of domain models in sequence, and keep system data up-to-date. Finally, the workflow design method is implemented in the design and virtual validation process of a high-speed shaft (HSS) bearing inside the gearbox system of a WT to showcase the practicality of the proposed workflows. The contributions of this work aim to improve the reusability of the WT system models while ensuring data consistency and interdependencies between different system solutions, and to provide structured virtual testing workflows in the system architecture to support the virtual validation of the redesigned WT system easily. In addition, the work proposes an automated virtual testing workflow that can execute the appropriate models according to the specific test needs of the engineer to achieve the minimum necessary calculation work while obtaining sufficient results at the same time.
This work is organized as follows. Section 1
introduces the research background, the related works, and the blank spot in the state of the art in detail. Following, the studied WT as well as the models used for demonstration are described in Section 2
. Section 3
describes the function-oriented system architecture and domain model classification of the WT system. Section 4
introduces the virtual testing workflows in SysML based on the function-oriented system architecture. Section 5
evaluates the superiority of the proposed workflow with a demonstration of virtual validation processes of partial WT components. Section 6
discusses the findings, the superiority, as well as remaining challenges of the proposed method and prospects for future research. Finally, Section 7
concludes the work.
4. Design of Virtual Testing Workflows in SysML
As described in Section 3.1
, the function-oriented architecture starts by deriving system functions from functional requirements or use cases. These functions are implemented by solution elements. To virtually validate that a function is satisfied by the corresponding solution, multiple virtual testing workflows should be designed regarding different test needs, such as smearing analysis testing and fatigue analysis testing. The virtual testing workflows model and perform a series of simulation activities. In order to perform specific simulation activities, engineers usually need to select appropriate domain models and manually sequence the simulations of these domain models for creating virtual testing workflows. Therefore, to reduce manual efforts for sequencing the workflows, it is necessary to establish a general and standardized design method for multiple virtual testing workflows, which helps engineers to easily design and reuse the workflows with different test needs.
4.1. Nested Structure of Virtual Testing Workflows
The virtual testing workflows adopt a modular design [37
] that subdivides the workflows into smaller parts called modules. The simulation activity is regarded as a module for performing the corresponding simulations of the domain models. Modular simulation activities provide great flexibility in the design of virtual testing workflows. In addition, as mentioned in Section 3.2
, domain models are classified according to system scope, model purpose, and model fidelity. The simulation activities are nested based on the classification of the domain model. For example, a simulation activity regarding a specific model purpose includes sub-simulation activities that execute the models with different model fidelities.
As shown in Figure 5
, the proposed workflow employs a nested design framework, in which the system scopes should be considered at the top level in the nested structure. It ensures that effort and resources are not wasted on tasks that do not contribute to the current analysis work (i.e., validation of the solutions not in focus). Before the workflows start, engineers manually set a test need, such as “Smearing testing”
and “Fatigue testing”
. An activity called “Check test needs”
is created at the “System scope”
level of the workflow to capture test needs from engineers. A decision node needs to be created after the activity “Check test needs”
. In this work, the symbol of the decision node is a diamond that connects with one object flow as the input and two or more control flows as the output. The test needs are passed by the activity “Check test needs”
to the decision node through the object flow. The control flows model a transition between the decision node and virtual testing activities (i.e., “Fatigue testing”
and “Smearing testing”
). Control flows can define the guard condition. A guard condition is a Boolean condition that is evaluated when a transition is initiated. The Boolean expression is contained in the square bracket to evaluate the input (i.e., test needs) of the decision node. The transitions between the decision node and virtual testing activities only occur when the guard condition is evaluated to be true.
Each virtual test involves various related domain models from different system scopes with a specific purpose. Domain models for a specific purpose require parameters as input that may be determined in models for other purposes. Therefore, at the “Model purpose” level of the workflow, engineers should also consider the simulation sequence between each domain model. Once the sequence is established, the virtual testing workflow can be reused. For example, when conducting “Smearing testing”, the workflow always performs the “Load performance models” at first and then performs “Smearing analysis models” in sequence.
Furthermore, each domain model has a certain degree of fidelity. Therefore, the “Model purpose” level of the workflow needs to be further designed to determine the fidelity of the domain models in a workflow. Engineers can either directly execute workflows based on pre-set model fidelity or set the appropriate model fidelity before the workflow begins. Similar to “System scope” level design, the appropriate model fidelity is determined at the decision node while the workflow is running. For example, at the “Model fidelity” level of the workflow, the workflow executes a high-fidelity load performance model (e.g., “Lambda model”) to support motion analysis for smearing testing.
4.2. Virtual Testing Workflows for Handling Simulation Results
When the appropriate fidelity model is selected, the workflow will perform the corresponding simulation of the domain model. System data is continuously updated as the domain models are simulated. Engineers usually manually update the data based on the simulation results and used the data in the next simulation. Therefore, to reduce these manual efforts and improve the automation of the workflow, it is necessary to further design the workflow for handling simulation results, which support the up-to-date data during the running of the workflow.
As shown in Figure 6
, the simulation activities are used to trigger simulations of related domain models, which are executed in external modeling tools. The constraint block in SysML encapsulates the domain models as an expression with inputs and outputs, linking to external tools via programming languages such as MATLAB. The system parameters can be connected with each domain model through the ports of the constraint block, thus realizing the data synchronization with the external simulation models.
To keep the data up-to-date during testing, each simulation activity includes the following two actions:
Action 1 (“Parametric Simulation”): Obtaining the latest updated data and executing simulations based on those data;
Action 2 (“Saving Results”): Saving the simulation results and updating the data for the subsequent simulations or requirement verifications.
In this work, the system data are saved in the instances of SysML. In SysML, an instance is a specific occurrence of any object. The instance specifies an object (e.g., a domain model) in SysML with specific property values. In this work, these instances provide data for the system model and parameterize the solutions and domain models in the system model. These instances are used in the action “Parametric Simulation” and “Saving Results” as the target object to be executed and the target object of where to save the results. The instance can be passed as an argument to the actions as a whole object. By using the API scripting language of CSM, the action “Parametric Simulation” will invoke the given objects and execute the parametric simulation, while the action Saving Results will wait until the simulation is completed and save the simulation results to the given objects.
Take the “Lambda model” simulation activity as an example. When the simulation starts, a runtime object (i.e., “Input Instance”), wherein the input parameters are stored, will be passed as an argument to the action Parametric Simulation. Then, the action will execute the constraint blocks called “Lambda_MBS” in the internal block diagram (ibd) in SysML to perform the corresponding external simulation (i.e., “MBS model”) based on the input instance. Parameters in the system model are exchanged with external models through constraint blocks in the ibd. After executing the simulation of the domain model, the simulation results are returned to the runtime object of the system model through the constraint block interface. A runtime object (i.e., “Output Instance”), wherein the output parameters are temporarily stored, will be passed as an argument to the action “Saving Results”. The action “Saving Results” saves the outputs from the runtime object in a given instance, in which the saved values will be used for other simulations or the requirement verifications.
The following advantages are observed using instances in the system model. The instance can be used to define specific configurations of system solutions, including the values of their properties (e.g., parameters), and is therefore potentially executable and can be simulated. Multiple instances with different values of properties can be created for a system solution, which greatly improves the reusability of the system model. There is no dependence between all kinds of instances, therefore, engineers are able to deal with parallelization of the simulations between different solution instances.
4.3. Virtual Testing Workflows in the Function-Oriented Architecture
This work combines proposed virtual testing workflows with the function-oriented system architecture to ensure that different engineers can conduct specific virtual tests under the premise of using consistent data. The feasibility of a simple virtual testing workflow in a function-oriented system architecture has been demonstrated in [29
As shown in Figure 7
, the proposed virtual testing workflow consists of a series of pre-ordered activities for performing simulations regarding the domain models of the WT system in sequence. These domain models are distributed at different hierarchy levels of the system. The workflows (e.g., smearing and fatigue calculation of rolling bearings) can be defined in the function-oriented system architecture as the stereotype «workflow»
and represented in the activity diagrams of SysML. The function-oriented system model provides a set of diagrams (e.g., internal block diagrams) to represent system information and show the interaction between different system elements and connections between different parameters. For example, the equivalent radial force (“Equivalent F_rad”
) is one of the parameters of the physical domain. This parameter can be bound to constraint blocks in different domain models with a specific purpose and fidelity (e.g., “ISO 281 model”
and “Smearing Criterion model”
) through binding connectors. The binding connector specifies that properties at both ends of the connector have equal types and values, which ensures that the parameters used in the different domain models come from the same source. Same as described in Section 4.2
, the parameter values can be specified in the instances, and the constraint blocks can be triggered when workflows run.
In conclusion, compared to the traditional workflows stored in documents, the model-based workflows in SysML activity diagrams avoid the independent development and subsequent integration of each discipline. This greatly improves the efficiency while ensuring the accuracy of the system validation process, thereby reducing the risk of failure in the late development stage. In addition, the work proposes a design method for a standardized virtual testing workflow framework based on domain model classification, which improves the efficiency of the virtual testing process. Next, an executable workflow is achieved at the parameter level based on a system architecture in SysML. Virtual testing workflows make the data in the system model alive, create continuous process links between the partial domain models that enable data consistency during the virtual testing processes, and allow change propagation.
Case studies demonstrate that, for complex technical systems, the proposed virtual testing workflows have advantages over classical virtual testing processes. First of all, the virtual testing workflows based on the function-oriented system architecture are executable. It not only manages the sequence of simulations, but also interacts with physical behavior models, offering the possibility to easily detect failure risks through high-precision simulations. Secondly, the case studies show that changes (i.e., load case changes) can be propagated across the various domain simulation models through the central system model to ensure data consistency. When load case changes, the risk of bearing smearing failure can be detected in time. Therefore, using the workflows can prognose the failure risks of technical systems due to redesign between different domain simulation models. At last, a structured workflow is necessary because when systems become complex, it will improve the reusability of the virtual testing workflows and the efficiency of the validation process. These case studies demonstrate that this workflow ensures that testers can easily perform the appropriate virtual testing scenarios, thereby avoiding precision problems or waste of computing resources. While this work demonstrates how to select the appropriate workflow based on the testing needs, it should be noted that the proposed workflows also support adding more virtual testing processes to ensure that a solution satisfies the corresponding function.
However, the current workflow still has limitations. First of all, the introduction of newly proposed workflows in the industry requires broad understanding and acceptance within and across disciplines. Therefore, user-friendly operation interfaces and standards for data exchange between domain models need to be created. Secondly, a function always contains several sub-functions that need to be validated, and the corresponding solutions are also distributed in hierarchy levels. Therefore, it is necessary to further standardize workflows to implement virtual validation across all levels of the functional hierarchy. In addition, this virtual verification uses a pre-set simulation sequence. Once the solution is reused in a different system, the workflows have to be manually restructured and sequenced based on the system context to ensure that the tests can still be carried out correctly. This issue can be improved by modularizing the simulation activities in future work. At last, in this work, engineers need to check the validation results after one design iteration loop and decide whether the next iteration can start or not until the design converges toward a solution that fulfills the requirement. Given that these design loops can be implemented through optimization algorithms or cost functions, the degree of automation of the proposed workflow can be further increased.