Synchronous Integration Method of System and Simulation Models for Mechatronic Systems Based on SysML

Abstract

System architecture could be described clearly and unambiguously by a descriptive system model during the system-level design of mechatronic products. However, for system verification, it is necessary to integrate the system modeling tools and simulation tools for analysis. Most of the existing integration methods focus on the integration in the physical architecture phase of the system model. A model integration framework that can integrate simulation into the logical architecture phase of the entire model for synchronous model verification is proposed in this paper. In the integration process, a Model-to-Text method is employed for information extraction and model transformation from the SysML model to the simulation model. The system model can be transformed by reusing and updating the generated simulation model through the framework for model verification. A framework with the Simulink model as the transformation target is constructed as an example in this paper, and the capability of this framework is verified by a design process of a quadruped robot. The result shows that this framework can realize the system design paradigm of integrating system verification for the entire logical architecture, which can improve the design efficiency and provide a reference for other system design and integration work.

1. Introduction

A system can be regarded as an artificial product composed of components or modules made for the pursuit of a common goal that cannot be achieved by a single element [1]. Mechatronic systems (MTSs) are the collaborative integration of mechanical engineering, electronics, and intelligent control in industrial products, process design, and manufacturing [2]. Model-based systems engineering (MBSE) [3] has gradually become a recognized method for designing complex systems, which depict system engineering problems with a variety of views and transforms stakeholder needs into detailed design specifications through model evolution or transformation [4]. Various system engineering languages that realize different functions, such as Systems Modeling Language (SysML), automation markup language (AML), and lifecycle modeling language (LML), are emerging and applied in the process of product development [5]. SysML is widely employed in mechatronic system design [6,7] to provide a simple, sharable, and effective model for MTSs by requirements, structures, and system behaviors modeling based on its abundant semantics.

However, SysML is insufficient in the description of the continuous dynamic behavior of the system. System engineers usually utilize simulation tools to verify the system’s behavior. A large amount of research concentrates on seamlessly integrating the high-level abstract system description capability of SysML with the system performance simulation capability of simulation tools in behavior verification. Yves Vanderperren [8] proposed two methods to integrate the UML (Unified Modeling Language)/SysML model and MATLAB/Simulink model: co-simulation and combination based on a common underlying executable language. Bassim Chabibi [9] classified some of the most common simulation environments (i.e., Simulink, SystemC, VHDL, Modelica) and their capabilities. However, these studies focused on the simulation of physical components and their behaviors in the system model, which is applied mainly to verify the physical architecture of the system model. For the verification of the earlier system design phase such as the logical architecture, co-simulation and transformations for model portions are often utilized. These processes are cumbersome and require multiple calls to the simulation tool, which is time-consuming and error-prone.

A synchronous transformation framework for MTSs design that transforms the SysML model into the simulation model is proposed in this paper. Based on the architecture modeling capability of the simulation tool, this framework can transform the SysML model generated from the system modeling tool into the system architecture model in the simulation tool by establishing the mapping relationship between their model elements. Compared with the traditional simulation model transformation based on the extraction of the system model skeleton, the transformation to the system architecture model can describe the content in the early design phase of the system model more comprehensively. Therefore, it potentially brings forward the entire verification phase of the model. Meanwhile, due to the natural integration between the transformed system model elements and the simulation model elements in the simulation tool, the system architecture model can be developed into the executable simulation model that corresponds to the physical architecture in the process of synchronization for further verification. This process is more natural and convenient than other model transformation processes and further strengthens the communication between the design groups, reduces the design iteration, and reduces the learning cost.

The remainder of this paper is structured as follows: Section 2 introduces the related work. Section 3 establishes the mapping rules of model elements and the action mode of the transformation framework and takes the integration of Simulink as an example. Section 4 verifies the proposed model transformation method through an example of a quadruped robot. Section 5 discusses the advantages of this framework and the aspects that need to be improved. Section 6 summarizes the work of this paper.

2. Related Work

2.1. Integration Mode of SysML and the Simulation Environment

SysML enables the entire system model design, while the mature simulation modeling language provides the basis for the formal model representation of the system using mathematical expressions. The establishment of the SysML model and simulation model is usually completed by different personnel separately, which causes redundant work and information discrepancy [9]. To bridge the gap between SysML and simulation modeling, various integration methods have emerged.

Figure 1 shows a simplified overview of a widely employed integration procedure which consists of a SysML modeling tool on the left and one or more simulation environments on the right. The SysML modeling tool provides the SysML meta-model, simulation extension profiles, and model libraries to generate an enriched SysML model. Meanwhile, the simulation environment has unique modeling structures, which are usually provided in model libraries, and the simulation model is generated by instantiating or copying these structures. The simulation execution solver provides the function of running the simulation on the established model and generating the result set according to the given input parameters. Based on the interaction between SysML and various simulation models, different methods of model transformation, parameter transmission, and result feedback have been developed.

Most SysML model extensions utilize the extension mechanism of UML-based languages (such as SysML) to provide additional semantics that do not appear in the standard SysML meta-model. Profiles such as SysML4Simulink [10], SysML4Arena [11], SysML4Modelica [12], and SysML4HLA [13] contain stereotypes with special semantics and attributes to allow for the representation of simulation language-specific architectural models in SysML. However, the existing semantic extensions still do not integrate all the required functions in the corresponding simulation environment. In this paper, the semantic extensions are further enriched to establish a mapping relationship with the architecture modeling functions in the simulation environment.

Generally, these studies propose extensions based on the block definition diagram (BDD) and the internal block diagram (IBD) to describe the system structure context. The parametric diagram is utilized to define the mathematical relationship between system portions and their characteristics, which would be calculated by the numerical solver. SysML behavior construction is applied mainly with discrete event-based simulation languages (such as SystemC or Arena) and utilizes existing semantic overlaps. Ola Batarseh [11] and Alonso Gutierrez [14] adopt the activity diagram to establish SysML behavior. Abbas Abdulhameed [15], Samir Berrani [16], Daniel C. Café [17], and Georgiana Caltais [18] adopt statemachine diagrams. Thomas Ruin [19] adopts sequence diagrams. Alessandra Bagnato [20], in the INTO-CPS project, extends the customized architecture and connection diagram from the existing view. Anargyros Tsadimas [21,22] extends the evaluation diagram of the grouping evaluation scenario. Since the logical architecture of MTSs often uses statemachine to describe the system behavior, Statemachine Diagram is adopted for the behavior construction and integration of the SysML model in this paper.

2.2. The Transformation between the System Model and the Simulation Model

The integration of the SysML model and simulation model includes co-simulation and model transformation. With the situation in which the SysML and simulation models are fully defined, parameters can be transferred between the SysML modeling tool and different simulation environments to analyze the described system, which is called co-simulation. Generally, the SysML model provides information about simulation setting parameters, initial values of system design parameters, and whether parameters are constrained. The information would be transmitted to the simulation environment. However, modeling the same system aspects separately in their respective modeling environments is prone to errors in many cases and causes a lot of redundant modeling work [9]. Therefore, many studies carried out model integration through model transformation. These studies utilize the target language to automatically generate the required design model copies and follow the Model-Driven Architecture (MDA) [23] as guidelines. MDA, presented by the Object Management Group (OMG), provides two kinds of transformation methods: Model-to-Model (M2M) and Model-to-Text (M2T).

In the M2T Transformation, shown on the left in Figure 2, the extended SysML model can generate the executable code directly for each simulation environment from the code template that inherits the source meta-model—for example, MATLAB code [10,24,25], AltaRica data flow code [19], SystemC code [26], and Aspen Plus code [27]. The M2M Transformation [28] in the middle of Figure 2 is another method to integrate the SysML modeling tool and the simulation environment. The M2M method establishes the mapping and transformation rules based on the meta-model of the source model and the target model to ensure the consistency of the system model in a more standard way. However, the premise of this method is that the meta-models of the source model and the target model are available. Additionally, the M2M transformation is often followed by the M2T transformation to create executable code.

In the implementation of the M2T method, integration tools such as Eclipse plugin Acceleo [29] and other external code generators are widely adopted. In the implementation of the M2M method, open-source standard transformation languages are mainly utilized, such as OMG Query/Visualization/Transformation (QVT) [30] or Atlas Transformation Language (ATL) [31]. In the application of the standard transformation language, the target and source meta-models based on the Meta Object Facility (MOF) must be provided. Due to the lack of standardization of MOF meta-model representation for specific simulation languages [32], many studies have developed meta-model representations for various simulation languages, such as Modelica [16,33], Simulink [33], SystemC AMS [17], and Discrete Event System Specification (DEVS) language [34].

Since most simulation environments own their unique executable code, the M2T method has a wide range of applications and is easy to implement. While the M2M transformation method can better ensure model consistency, it has a relatively small scope of application and a high difficulty in implementation due to the lack of standardization of the meta-model of various simulation models. Based on the consideration of universality and cost, the M2T method is chosen for model transformation in this paper. The XML file, corresponding to the system model and conforming to the standardized XML Metadata Interchange format (XMI), is adopted as the input of the model transformation framework to ensure the applicability to different system modeling tools. Based on the construction of element mapping rules, transformation templates specific to simulation tools are written in the transformation framework to extract and transform the model elements of the system model files. Meanwhile, the model comparison capability is embedded in the transformation framework. For the system model that is modified and improved after the exportation of the simulation model, the generated simulation model can be reused and updated. Finally, the executable code can build and modify the exported simulation model.

2.3. Integration of SysML and Simulink

In the integrated design of mechatronic systems, Simulink, with its comprehensive capabilities, is widely employed for simulation and verification. Therefore, many studies focus on the integration of SysML and Simulink; the transformation framework instance in this paper also uses Simulink as the target. Cao Yue [35] proposed a method for transforming SysML to Simscape and Stateflow based on Triple Graph Grammar (TGG). Mohd Azizi Abdul Rahman [4] proposed an approach for the synchronous integration of SysML to Simulink/Simscape based on Rhapsody-Simulink integration (RSI). Takashi Sakairi [36] developed an integration tool that transforms SysML models into S-functions and uses variable step solvers for simulation. Bassim Chabibi [10] established an automatic integration method from SysML tools to Simulink based on co-simulation. In addition, some SysML modeling tools also provide integration functions with Simulink.

Table 1. Simulink integration capabilities in common SysML modeling tools.

SysML Modeling Tools	Simulink Parts Involved
	S-Function	Simscape	Stateflow	System Composer
Rhapsody	√	√	√
Cameo System Modeler	√	√	√
Enterprise Architect		√	√

shows the Simulink integration functions of common SysML modeling tools and their comparison.

It is shown that the existing integration of SysML with Simulink focuses on the employment of the Simulink scientific computing module to express the arithmetic relations of design parameters in SysML models and the employment of Simscape and Stateflow to express the continuous dynamic behavior of the system. The construction of these correspondences relies on the constraint properties in the SysML block.

With the appearance of System Composer, Simulink can perform system architecture modeling. Christopher B. Watkins [37] proposes the eSAM method and uses System Composer to construct the functional and physical architecture of an avionics system. For mechatronic systems that involve multiple disciplines and a tedious design process, System Composer alone is currently not sufficient for an accurate description of the system. For example, it does not provide the generalization relationships definition function for components, which makes it difficult to reuse existing components in the modeling process, resulting in redundant modeling efforts. Therefore, mechatronic systems are more suitable for modeling by SysML and integrating with simulation environments such as Simulink.

In traditional SysML–Simulink integration processes, the parameters, constraints, ports, and statemachines of blocks are transformed. However, the architectural information of the model is transformed incompletely. SysML structures without constraint properties are difficult to represent visually in Simulink, and the information about stereotypes is lost. In addition, the high coupling between the parameters and modules model makes the transformed simulation difficult to debug, and it is hard to simulate multiple behaviors of the same structure in a single simulation model.

To solve the above problems, in this paper, the proposed integration framework instance integrates SysML with the System Composer, which can improve the capability of the simulation model in the expression of the SysML model structure and decouple the constraints and parameters. In addition, model integration allows System Composer to reuse historical models and extensions of SysML, which provide support and reference for the system architecture modeling efforts in System Composer. Since architecture modeling tools such as System Composer are homologous to its simulation environment, this integration can synergize with existing integrations. It makes the design process more flexible and the optimization process more uniform, which facilitates communication between designers and improves design efficiency.

3. Synchronous Transformation Method of the SysML Model

According to the M2T transformation method, specific mapping rules can be established between the system model and different simulation environments. Corresponding transformation templates can be derived to generate various executable codes. Based on the architecture modeling function of simulation environments and the model modification function of the executable simulation code, the system model can be transformed in its entirety, even when the system model is not completely constructed, and the corresponding simulation model could be modified synchronously with the modification and optimization of the system model. The process of model transformation and synchronization in this paper is shown in Figure 3. The large white arrows in the figure mean the direct communication of data, and the thin black arrows mean the provision of design references.

Since the architecture modeling function and the modeling API of Simulink are relatively complete and widely employed, Simulink is taken as the transformation target in this paper to construct the transformation framework instance. In this paper, System Composer, Simulink-Requirement, Simscape, and Stateflow in Simulink are employed to construct the mapped model. The logical architecture of the system model and its subsequent content is synchronously expressed to execute analysis and verification.

3.1. Extension of SysML

In the integration of the system modeling tool and simulation tool, the system model is usually transformed into the simulation model or connected with the simulation model for verification and optimization. The improvement of the architecture modeling capability in the simulation tool brings the possibility of further improving the integration for the entire logical architecture of the system model and simulation model, which can form a new design and integration pattern. The implementation of this new integration pattern needs to extend the semantics of the SysML. For different kinds of simulation models, semantics that needs transformation but lack a mapping relationship are required to be searched and taken as the expansion target. The basis of semantics searching is the model verification requirements of the system model. There are two extension methods in SysML: one is to define a new meta-model in SysML called heavyweight extension. It can build new model elements with its own unique attributes and methods, and the semantic expression is relatively accurate, but the development is relatively difficult. The other is the lightweight extension that customizes stereotypes and tagged values of existing model elements in SysML for the extension. It can refine the meaning of modeling elements and add new attributes to the meta-model. Based on the consideration that the lightweight extension has the advantages of flexibility and a low cost, it is applied to extend the semantics of the SysML in this paper. The extension mainly includes architecture identifications and specific discipline module libraries. In addition, the stereotype utilized to express the system model information in the functional architecture and logical architecture can be transformed into the specific structure of the simulation architecture model, such as the profile in System Composer.

In system design, the logical architecture includes the decomposition of functions based on factors such as technology selection, scheme subcontracting, and component reuse. It logically describes specific contents of functions realized by the system. Logical architecture is the basis of physical architecture and the starting phase of model transformation in this paper. Stereotype <<LogicComp>> is obtained based on the meta-class <<block>> extension in this paper. As the structure obtained by the maximum subdivision of the system function for the logical architecture, it exists at the lowest level of the logical architecture. It also presents the realization of the functions allocated by the system and the basis of the physical architecture with its parameters. Moreover, it reflects the Component without Subcomponents in the System Composer architecture model in Simulink.

In the simulation environment, the simulation model is composed of specific discipline modules. The essence of the transformation is the process of obtaining these modules and their relations to verify the system. If the verified system is a physical system such as a mechatronic system, it is necessary to apply physical simulation tools to establish virtual physical systems. They are composed of actual physical elements and can map the corresponding physical architecture in the SysML model. Current research on the model transformation of the SysML model and simulation model mostly focuses on mapping SysML constraint expression with modules of the mathematical operation portion in the simulation model and making isomorphism between the SysML model and simulation model. Operators in constraint expression and their relationship with parameters are identified at first. Then, it is transformed into a model composed of mathematical operation modules. Physical variables are identified through stereotypes, and the simulation modeling language is called through the system modeling tool. Custom modules corresponding to the system model are created to carry out transformation.

In consideration of cost, the difficulty in implementation, accuracy, and intuitiveness, the method that expands the semantics of the system model by the establishment of physical elements and semantic system module libraries is adopted in this paper. It constructs attributes and identifications of corresponding simulation modules with the same semantics by creating stereotypes. These simulation modules can be identified and correspond to the usage of stereotypes. It is intuitive and easy to implement. In addition, it is extensible. The content and method can be modified as required, such as the creation of custom modules in Simulink with the application of the S-function.

Since Simulink is regarded as the transformation target, it is necessary to analyze the semantics of the modules for physical simulation in Simulink. In its simulation environment, physical simulation is carried out mainly by Simscape. It is the part for physical simulation in Simulink that can model physical entities and their connections to test system performance. The Simscape model is equipped with a specific solver and is solved by the physical network approach, which is different from the model composed of conventional Simulink modules. The connection of its modules does not specify the direction and runs simultaneously during the simulation. It is often utilized to simulate the physical architecture of the system model. According to the different physical domains corresponding to the functions of Simscape simulation modules, they can be divided into conventional modules, electronic modules, transmission modules, multibody modules, etc. Therefore, the same semantic SysML stereotype corresponding to the Simscape module and its related value types, units, and interfaces are established and stored in the package according to the characteristics of parameters, variables, and ports in the Simscape module. Figure 4 shows the profile package obtained by constructing and classifying the simulation modules commonly utilized in the mechatronic system design with the same semantic SysML blocks.

The same semantic block in the package has the same port as the corresponding Simscape module and contains the corresponding parameter, variable, and other information. The simple permanent magnet synchronous motor (PMSM) module is taken as an example, as follows. The appearance of its corresponding semantic SysML block (left) and Simscape block (right) is shown in Figure 5, and the mapping relationship between some internal parameters is shown in

Table 2. Mapping relationship of internal parameters in the PMSM block.

Parameter	SysML Block	Simscape Block	Related Ports
Current	i: Current	i	+, −
Voltage	u: Voltage	u	+, −
Angular Velocity	w: Rotor	w	W, R, C
Torque	t: Torque	t	Tr, R, C
Steady Speed	vv: Speed	vv	N/A
Steady Maximum Torque	tv: Torque	tv	N/A
Initial Speed	vi: Speed	vi	N/A

.

SysML extension profiles include the specific structure identifier and the same semantic block of the physical simulation module. The identification and transformation of model elements are on this foundation. Therefore, the model element in the SysML model would more accurately correspond to the model element of the simulation model in the specific simulation environment, and the efficiency and accuracy of transformation would be improved.

3.2. Model Elements Mapping Rules

3.2.1. Analysis and Extraction of SysML Model Elements

In the research of data exchange and model integration between different platforms, a capital problem is the incompatibility of metadata. The term metadata refers to the data that describe the structure and meaning of data through tools, databases, and middleware. It is the data of data. MOF provides metadata management specifications and corresponding metadata service sets to support the development of model-driven systems.

The MOF Model-to-Text (MOFM2T) standard in the MOF specification specifies that the method of transforming the model into various text files is to parameterize model elements through the method based on the text template. The information in the expression specified on the model element in the model file is extracted through the query method, and the expression language with the string operation library is applied to transform it into a text fragment and fill it into the corresponding placeholder in the text template.

Based on the XMI standard proposed by OMG, the SysML XML file is exported from the SysML modeling tool. Then, the model element information in the file is queried and extracted according to the characteristics of the model element expression and the SysML extension profile. The corresponding SysML model element set is obtained after sorting. The analysis of the SysML model and the extraction of model elements could be finally completed.

3.2.2. Mapping Relationship Construction for Model Elements

In the integrated design of mechatronic products, the mapping relationship between the system model and the simulation model is the key content of the model transformation method. Based on the description method of object features in the SysML model and simulation model, along with the SysML extension profile, the mapping relationship between SysML model elements and simulation model elements can be constructed. It can support the entirely synchronous transformation of SysML models from the logical architecture phase.

In the instance that Simulink is regarded as the target of transformation, the mapping relationship can be constructed based on the description function of SysML model elements, Simulink model elements, and the SysML extension profile. Current research on the mapping of SysML and Simulink focuses on mapping mathematical operation modules, Simscape and Stateflow in Simulink. The application scenarios are mostly for mapping the semantically more complete parts of the system model, while fewer studies are related to mapping the elements that only describe the model architecture in the phase before the system model design is completed. Based on the architecture modeling capability of System Composer in Simulink, the architecture of the SysML model and the information in its applied stereotypes can be mapped. The model architecture and stereotypes contain the information that needs verification before the completion of system modeling and the information that needs storage and calculation in some other stages of the product lifecycle. The application of this information can further improve the simulation model and reduce the communication cost between different phases.

The modeling progress in SysML is based on blocks. The features in the SysML model include structural features and behavioral features. The structural features of blocks are called properties, such as value property and part property. The behavioral features include activity, interaction, and statemachine. System Composer in Simulink is utilized to design and analyze system and software architecture, which supports the definition, analysis, and specification of the architecture and composition of MBSE.

The structural features of the SysML model correspond to Component in System Composer. The part property representing the nested structure in SysML blocks corresponds to the Subcomponent in System Composer. In the case that the association and interaction contents between blocks in the SysML model are all specified by the proxy port, the port in SysML can correspond to the port in System Composer after reallocation with the connection object according to the direction. The connector in SysML is a corresponding element with the same name as System Composer. The organizational form of model elements in SysML IBD has a mapping relationship with the architecture view of System Composer. The information representing the data interaction in the interfaceblock may establish a mapping relationship with the information in the interface included in the dictionary of System Composer. Attributes defined by the stereotype can be mapped with the stereotype contained in the profile of System Composer when the type of the attribute contained in stereotypes is integer, real, string, Boolean, and enumeration. The application relationship of the SysML block to the stereotype can also be mapped. Constraints in SysML or co-simulation model elements with the same function can be mapped to the analysis function in Analysis Architecture of System Composer.

Table 3. Mapping relationship between SysML and System Composer.

SysML Model Elements	System Composer Model Elements
Block	Component
Proxy port (Single Direction)	Port
Connector	Connect
Stereotype	Stereotype
InterfaceBlock	Interface
Constraint expression	Analysis function

shows the mapping relationship between SysML and System Composer model elements.

The element “Requirement” in the SysML model can establish a mapping relationship with the Simulink-Requirement in Simulink. The string attribute “text” describes the content of requirements stored in the Requirement of the SysML model. It has the same semantics and type as the string attribute “description” of the requirement in the Simulink-Requirement. Therefore, information about requirements can be transformed directly, and the traceability between requirements can also be transformed. The control logic of the block with the control function in the SysML model can be represented by a statemachine. Model elements in the statemachine such as state, behavior, and transition can correspond to model elements in Stateflow. The mapping relationship between SysML and these parts in Simulink is shown in

Table 4. The mapping relationship between SysML and Simulink parts.

SysML Model Elements	Simulink Model Elements	Parts of Simulink
ID	ID	Simulink-Requirement
Text	Description
State	State	Stateflow
Behavior	Action
Transition	Transition

. The representation of specific physical elements in the SysML model can correspond to the Simscape model with the application of extended profiles.

Since model elements such as activity and interaction in SysML are applied mainly for the functional architecture in the system design, and their mapping relationship with model elements in the simulation environment is relatively fuzzy, they are not mapped in this paper to avoid semantic redundancy and other problems. The extension of MATLAB script and Simulink function, applied originally for co-simulation in the SysML model, can be integrated and transformed as an analysis function during transformation, which reduces unnecessary communication between these platforms in the analysis. For other kinds of simulation models, the model element mapping relationship can also be established according to the semantic characteristics of SysML, simulation modeling elements, and the specific extension profile of SysML. SysML model elements can be transformed into simulation model elements corresponding in semantics and function based on the mapping relationship.

3.2.3. Mapping Relationship Construction for Model Architecture

At the stage at which the construction of the system model has not been completed, two kinds of models can be synchronously and entirely mapped based on the architecture modeling function of simulation tools, the similarity between the architecture, and the application mode of these tools. A group of regional elements with specific meanings or correlative functions is established in the simulation environment according to the relationship between functions and entity elements in the SysML model, the association relationship between simulation model elements, and the characteristics of the simulation solver. Parameters in model elements provide the conditions for operation simulation, achieving the verification in the early phase. With the further refinement and expansion of the SysML model, the simulation model can be modified synchronously and verified as required. When the SysML model is composed, the simulation model can also have complete content to support the overall verification.

With the establishment of the entirely synchronous transformation of simulation models from the logical architecture of the SysML model, multiple Simulink parts and their relationships can be mapped for simulation modeling based on the connection relationship of various Simulink parts. For example, Component in System Composer has functions of structural application; Requirement can trace Simulink modules; Simscape can connect the physical signal port with the conventional signal port of Simulink through the conversion connector. The specific mapping relationship between the architecture of the SysML model and Simulink is shown in Figure 6, and “*” in the figure indicates there are multiple instance modules on this side of the part. System Composer is utilized for the establishment of the architecture; Simulink-Requirement is utilized for tracing the requirements; Simscape is utilized for the establishment of the physical structure; Stateflow is utilized for the establishment of the control logic; the Simulink mathematical operation module is utilized for auxiliary calculation.

3.3. Construction of the Model Transformation Framework and Generation of the Simulation Model

3.3.1. Specific Mapping Method of the SysML Model and the Simulation Model

Based on MOFM2T specification, Object Constraint Language (OCL) can be applied to extract model elements from the SysML XML model file. OCL is a formal language adopted to describe the UML model expression maintained in the specification of the modeled system or model query. OCL can also be applied to query models established by language extensions of UML such as SysML. The code generator Acceleo is based on the integrated development environment Eclipse and the Eclipse Modeling Framework (EMF). It implements the MOFM2T specification and applies OCL to query the model. The operation of Acceleo is shown in Figure 7. The language adopted by Acceleo is MTL (MOFM2T language), which is composed of templates and queries. Its file extension is “mtl”. In Acceleo, the code snippets and query statements in the MTL file could be executed, and the execution results could be filled into the specified positions in the text template to generate a text file with the specified content.

To realize the synchronous transformation between the SysML model and simulation model, Acceleo is selected to build the transformation framework in this paper. Based on the consideration that the model transformation and synchronization mainly query the information of the model element in the SysML XML file but do not involve the configuration information, some kinds of simulation model files are difficult to parse, such as the Simulink SLX file. The intermediate model established by Java objects could be generated for comparison in the query and extraction of model information to facilitate inspection and transformation.

Figure 8 is the activity diagram of the information extraction and code generation process in the condition that the system model is exported for the first time. The model elements in the SysML model are extracted and sorted out in a traversal manner through query statements according to the composite relationship. The text template is written for code generation to establish or update the simulation model. It is based on the SysML extension profiles, the mapping relationship between the SysML model and simulation model, and the modeling API of the simulation tool. The modeling framework runs in Eclipse and can export executable simulation code based on the imported SysML model. The corresponding simulation model could be generated with the execution of the code in the simulation environment.

The construction process of the transformation framework instance for Simulink is shown in this paper. The modeling API provided by Simulink allows grammatical text files to execute as the MATLAB script. The Simulink model would be generated automatically according to the programming modeling method. Acceleo can query, extract, and sort model elements of the imported SysML XML file and then fill the corresponding model information into the template. The writing of the template is based on the SysML extension profiles, the mapping relationship between the model elements, the architecture in SysML and Simulink, and the Simulink modeling API. The corresponding modeling script is finally generated. The corresponding pseudo-code of part of the main code is shown in Figure 9. This part mainly involves the transformation of model elements of the logical architecture. The executable code fragments are included by “[/]”, and the others are template text.

For other Simulink parts not involved in the transformation in Figure 9 such as Simscape and Stateflow, their transformation principle is similar to System Composer. The traversal access can be also applied for these parts of Simulink. Therefore, other information required in the establishment of the Simulink model can also be extracted to fill in the template for realizing the transformation.

The transformation to other simulation environments can also be implemented by Acceleo. The modes of query, collation, and comparison for SysML model elements are the same. The only difference is that the code template finally filled in model elements and needs to be written according to the characteristics of different modeling APIs. In addition, transformation capabilities to different simulation models can be integrated into a unified framework.

3.3.2. Synchronous Updating Method of the Simulation Model

After the integration of the system logical architecture and the simulation model, the system design process changes from being dependent on a separate system modeling platform to being dependent on both the system modeling platform and the simulation platform. The common optimization method for the logical architecture of the system model is solving the model in the simulation environment by model transformation or co-simulation and then feeding back the results to the system model. The parameters and structure of the logical architecture are modified appropriately, and the physical architecture is designed on this basis.

Based on the model transformation framework proposed in this paper, the transformed simulation model can synchronize with the system model. The original cumbersome optimization steps are transformed into a unified and synchronous optimization process. It reduces information round trips between these platforms, increases the degree of model reuse, and improves design efficiency. The process of model transformation and synchronization is shown in Figure 10.

For the system model that has been exported, the transformation framework conducts the model comparison to confirm changed portions and generate a script for the update. The script contains command statements including addition, deletion, and change for model elements and their relationships in the simulation model according to the changed content. The intermediate model is also updated after code generation. The specific process is shown in Figure 11.

4. Case Study

In the system design of mechatronic products, the model synchronization transformation framework can start the entire model synchronization and verification for the simulation model in the logical architecture phase. It allows developers to analyze, weigh, and verify the system model more conveniently. In this paper, the design process of a quadruped robot is chosen as an example. Its system model is constructed in the SysML modeling tool Cameo System Modeler (CSM) and transformed into Simulink through the framework. Then, the model is simulated and analyzed in Simulink. Based on the transformation and analysis of the entire logical architecture and the feedback result, the role and feasibility of integrating the simulation tool in the logical architecture phase are verified. The function of simulation model synchronization in the model transformation framework is verified by synchronously updating the simulation model.

4.1. Construction of the System Model

The possible application scenarios of the quadruped robot include search and rescue, complex terrain transportation, and supporting the research of animal ground motion. The design requirements of the quadruped robot should be confirmed. It is assumed that the application scenario of the quadruped robot is to conduct activities in a small range of a complex terrain in a concealed, flexible, and high-speed manner. Its motion posture is similar to the trot gait of animals, and it should be suitable for a weight that can be lifted by two people. These design requirements are sorted preliminarily into the Requirements diagram in Figure 12. During the system design process, these requirements could be further refined. Structures, behaviors, and other elements in the system model could be traced.

Based on the requirements above, the quadruped robot system can be divided into five subsystems that assume different functions: the power subsystem, energy conversion subsystem, driving subsystem, support structure subsystem, and sensing and control subsystem. The energy subsystem provides the energy required by the robot’s operation, and its power is determined by the speed and load of the robot’s movement. The energy conversion system distributes the energy provided by the energy subsystem to each energy-consuming part after adjustment. The driving subsystem provides the torque and speed required by the robot’s movement and converts the energy from the energy subsystem into mechanical energy. The support structure provides accommodation and support for physical elements and also acts as an actuator to realize the robot’s movement. The sensing and control subsystem outputs control signals to the energy conversion component and the driving component and receives feedback signals of the position and force of the actuator.

To realize the functions of these subsystems, further functional subdivisions and combinations are required. The supporting structure subsystem can be divided into the body and legs connected with the body. Legs can be divided into the hip joint, the upper leg, the knee joint, and the lower leg. The driving subsystem can be divided into eight drivers distributed in the hip and knee. The energy conversion subsystem can be combined with the energy subsystem and each driver to become a power system capable of providing stable voltage and input power. The sensing and control subsystem can be divided into the center controller and the leg sensing and control system. The leg sensing and control system can be further divided into two leg controllers and eight drive controllers. Driver controllers are connected to each hip joint driver and knee joint driver. Since the posture of the leg in the diagonal direction is the same, contact sensors at the end of the two front legs are connected with the center controller. The supporting structure, driver, and controller of the joint can be combined into a joint actuator. The logical architecture and the preliminarily proposed structure of the quadruped robot, as shown in Figure 13, can finally be obtained. In addition, some parts of the structure in the logical architecture can correspond to the preliminary structure of the robot.

Due to the requirement that the quadruped robot should have the ability to move in a complex terrain, the support leg with a foldable knee joint is chosen to adapt to the complex terrain. According to the requirements of concealment, high speed, and small scale, the robot is driven by electric power, the high-power battery is chosen as the power supply, and the joint motor is chosen as the driver. In the corresponding logical architecture, the power block connects with the actuator block distributed at the joints of the legs, and the controller block connects with the structure block and the actuator block. With the further refinement of requirements and functions, the system model could be further expanded to establish the physical architecture.

4.2. Transformation and Analysis of the Architecture of the System Model

In the logical architecture phase, some design parameters and constraints have been preliminarily given. It is necessary to verify whether these parameters satisfy the constraints or can be optimized. The verification session can find defects in the early design phase, reduce the workload in the later phase, and improve design efficiency. Simulation tools are mostly applied to analyze and verify the parameters. The transformation framework proposed in this paper can transform the entire logical architecture of the system into a simulation model to support the analysis of the parameters in the architecture.

After the content of the logical architecture is integrated into a general block, the model is exported as an XML file. The corresponding modeling script would be generated by the transformation framework. The corresponding simulation model is obtained by running the script file in MATLAB. In the condition that the transformation of the control subsystem is taken as an example, the transformation process, the corresponding model, and some code fragments are shown in Figure 14. The content of the logical architecture in the system model is represented by the System Composer architecture model, and parameters are contained in stereotypes of the architecture model.

If the transformation is carried out by the “Export to Simulink” transformation function in CSM, the SysML model skeleton is extracted, and the customized simulation modules with their connection are created in the M2M method. Although the steps seem convenient, the existing transformation function of CSM does not establish a mapping relationship with some Simulink parts such as System Composer. Therefore, the System Composer architecture model cannot be built, which would cause errors in the transformation. If the block does not contain constraint properties, the corresponding custom module library and the connection of blocks are unable to be generated, which also results in the loss of information about stereotypes. The situation of this transformation is shown in Figure 15. In addition, the parameters in the transformed simulation model are highly coupled with the simulation module, which is difficult to modify and debug in the analysis process.

Based on the analysis architecture function of System Composer, parameters in the configuration can be extracted and transferred to the analysis function for an architecture trade-off analysis. The equivalent stiffness analysis for the legs of the quadruped robot is taken as an example in this paper. The legs of the quadruped robot in the motion state can be equivalent to the spring-mass model, with the equivalent stiffness K, and the displacement y of its center of mass in the vertical direction can be regarded as the spring compression amount. Therefore, the magnitude of y cannot exceed the equivalent length L₀ of the leg in the unloaded state. When L₀ is given by other conditions as the design parameter and K is preliminarily given, motion analysis is required to confirm whether K meets the constraint. When L₀ = 1 m and K = 7.7 kN/m, the vertical displacement curve of the leg in the contact state, as shown in Figure 16, can be obtained. It can be found that the range of y does not exceed L₀, so K satisfies the constraint. Based on the results of such trade-off analysis, the design parameters can be verified to improve the logical architecture and establish the physical architecture on this basis.

4.3. Synchronization and Verification of the System Model and the Simulation Model

After the logical architecture of the quadruped robot is verified and optimized, the physical architecture can be further designed on this basis. This process is accompanied by the modification and expansion of the system model and requirements for verification.

In the process of the transformation for the modified system model, model elements are compared in the query stage with the saved intermediate model from the previous transformation. After the contents that need to be modified in the model information are sorted out, the modified intermediate model is saved, and an updating script is generated. These model elements could be modified based on the original simulation model by running the update script. After the physical architecture of the system model is composed, the physical simulation model of the quadruped robot can be obtained through synchronization.

According to the design requirements of the flexible motion of the quadruped robot, the hip joint motor needs the ability to provide fast-changing torque. After setting the monitoring module and executing, the torque change of the hip joint motor in the quadruped robot, as shown in Figure 17, can be obtained. The torque value has a relatively drastic change, which can satisfy the requirement of flexible movement. The parameters of the system model can be modified and adjusted to complete the verification and optimization of itself according to the simulation result.

5. Discussion

A model synchronous transformation framework integrating the system model and simulation model is proposed in this paper. This framework can transform the entire logical architecture of the system model into the simulation model. The optimization mode for the logical architecture of the system model can be integrated into the simulation environment for comprehensive and unified analysis, trade-off, simulation, and verification by this framework. The simulation and verification phase can also parallel with the logical architecture of the system model more efficiently and reduce the design iteration. It can reuse the simulation model generated in the same design process, update the generated simulation model synchronously with the modification of the system model, generate the simulation model corresponding to the physical architecture of the system model, and carry out complete model verification.

However, the function of this framework still requires improvements in integrated system modeling and simulation analysis—for example, the automatic feedback of results from the simulation model to the system model, the reverse synchronization from the modification in the simulation model to the system model, and the identification and synchronization of simulation models existing and not derived from transformation. The realization of these functions needs to analyze the simulation model further and establish the data interaction channel between these models. Co-simulation with the functional mock-up units (FMU) is a potential pathway. These measures can improve the transformation and synchronization function of this framework.

6. Conclusions

In this paper, a SysML model–simulation model synchronous transformation framework is constructed through the external code generator Acceleo, which is based on the MOFM2T specification. It handles the problems of the incomplete system model architecture transformation and the inefficiency in logical architecture verification in the mechatronic product system design. An instance taking Simulink as the transformation target is established. The transformation and synchronization process can be summarized as follows: at first, the mapping of model elements is built to define the rules of the transformation. Then, the structure, identification, requirements, and other information in the system model are extracted. An intermediate model is generated and compared with the original intermediate model for storage. Finally, a modeling template or script update is generated by filling in the transformation template. In Simulink, System Composer is utilized for carrying the information of the logical architecture and serves as the foundation of the simulation model. The synchronous transformation from the SysML model to the Simulink model is realized.