A method for converting SLIM models to XSAP models based on ATL

Abstract

This invention discloses an ATL-based method for converting SLIM models to XSAP models, comprising: designing a SLIM metamodel and an XSAP metamodel according to predefined model conversion rules, and obtaining the abstract syntactic structures of the SLIM metamodel and the XSAP metamodel; designing a model conversion algorithm based on ATL, utilizing the metamodel and abstract syntactic structures to convert the SLIM model to an XSAP model, obtaining a converted XML-formatted XSAP model; and designing a verification algorithm to verify the XSAP model, obtaining a complete SMV-formatted XSAP model. This invention can directly convert safety-critical systems from SLIM models to XSAP models and perform verification analysis on the converted XSAP models. The conversion algorithm and model verification algorithm proposed in this invention have universality.

Description

Technical Field

[0001] This invention belongs to the field of safety-critical system modeling and model conversion technology, specifically involving a method for converting an ATL-based SLIM model to an XSAP model. Background Technology

[0002] In model-driven engineering, ATL plays an increasingly important role in establishing model-to-model transformations and bridging language differences between models. ATL transformation languages ​​are domain-specific languages ​​specifically designed to solve common model transformation tasks. Currently, the research community has proposed many transformation languages; although their problem domains are fixed, they still differ in the programming paradigms they employ. Different methods are suitable for different types of tasks. One type of problem can be easily solved with declarative languages, while another is more suitable for imperative methods. ATL is a hybrid language, a combination of declarative and imperative structures, possessing strong problem-solving capabilities.

[0003] The SLIM language follows a component-based paradigm, where software (such as threads and processes) and hardware components (such as memory and processors) are referred to as first-level objects. Each component describes an interface through its type definition, and its implementation describes interactions through finite state automata. Sets of interacting components can be grouped into composite components, allowing modelers to manage system complexity by introducing a component hierarchy. Communication is achieved through message exchange on event ports. The hierarchical system model generated by this language, also known as a nominal model, describes the system behavior under normal operation. SLIM models represent systems based on components; in SLIM, software (represented by keywords process, thread, or thread group) and hardware (keywords processor, memory, bus, and device) components are used as first-level language structures. Sets of interacting components can be grouped into composite components indicated by the keyword system.

[0004] The XSAP model uses the SMV language as input, describing finite state machines through module and process declaration and instantiation mechanisms, corresponding to synchronous and asynchronous combinations, and representing a set of requirements using CTL and LTL. XSAP can perform batch processing or interactive work through a text-based interactive shell. SMV decomposes the system into modules, each of which can be instantiated multiple times. This provides users with a modular and hierarchical description and supports the definition of reusable components. Typically, an SMV file contains a main module and several custom modules.

[0005] MBSE is an engineering methodology that incorporates models as part of a technology baseline, encompassing the requirements, analysis, design, implementation, and validation of capabilities, systems, or products throughout their lifecycle. SLIM is a commonly used systems engineering modeling language for analyzing and modeling safety-critical systems. XSAP can use Model-Based Safety Analysis (MBSA) to perform safety analysis on systems. Therefore, proposing a method to convert SLIM models into XSAP models is significant for bridging the gap between MBSE and MBSA in system development. Summary of the Invention

[0006] The technical problem to be solved by the present invention is to provide a method for converting SLIM models to XSAP models based on ATL, which addresses the shortcomings of the prior art. This method enables safety-critical systems to be directly converted from SLIM models to XSAP models. The converted XSAP models can be formally analyzed using XSAP engine tools to check the functional consistency and completeness of the models and verify the correctness of the systems.

[0007] To achieve the above-mentioned technical objectives, the technical solution adopted by the present invention is as follows:

[0008] A method for converting an ATL-based SLIM model to an XSAP model includes:

[0009] Step S1: Design the SLIM metamodel and XSAP metamodel according to the predefined model transformation rules, and obtain the abstract syntax structure of the SLIM metamodel and XSAP metamodel.

[0010] Step S2: Based on ATL, design a model conversion algorithm. Using the meta-model and abstract syntax structure obtained in step S1, convert the SLIM model to the XSAP model to obtain the converted XML format XSAP model.

[0011] Step S3: Design a verification algorithm to verify the XSAP model obtained in step S2, and obtain a complete XSAP model in SMV format.

[0012] To optimize the above technical solution, the specific measures also include:

[0013] The above S1 analyzes the characteristics of the SLIM model and the XSAP model, and predefines the following conversion rules:

[0014] (1) The rules for mapping the type declarations and implementation definitions used in the SLIM model to describe the components in the physical system to the module declarations used in the XSAP model to describe the components in the physical system;

[0015] (2) Rules for mapping data ports in the SLIM model to state variables in the XSAP model;

[0016] The data ports in the SLIM model are used to describe the state of components and can be used to exchange data with other components.

[0017] The state variables in the XSAP model are used to describe the module state;

[0018] (3) The conversion rules between initial values ​​in the SLIM model and initial assignment constraints in the XSAP model;

[0019] In the SLIM model, the initial values ​​are specified through the data port definition and are used to represent the initial state of the components.

[0020] In the XSAP model, the initial assignment constraint is used to specify the initial values ​​of the state variables, thereby representing the initial state of the module;

[0021] (4) Rules for mapping component states in the SLIM model to state variables in the XSAP model;

[0022] In the SLIM model, component states are defined through component implementation, and transitions are achieved between states.

[0023] In the XSAP model, state variables are used to describe the module state;

[0024] (5) Rules for mapping sub-components in the SLIM model to instance variables of instantiated modules in the XSAP model;

[0025] In the SLIM model, sub-components are used to introduce a hierarchical structure, and the sub-components are defined in the implementation of the parent component;

[0026] In the XSAP model, instantiated module instance variables are used to represent the hierarchical structure between modules;

[0027] (6) The conversion rules between the connection in the SLIM model and the invariant assignment constraint in the XSAP model;

[0028] The SLIM model connects the source port and the target port for communication and operation between different components, transmitting the value of the source port to the target port without delay, so that the value of the target port is always equal to the value of the source port.

[0029] In the XSAP model, invariant assignment constraints are used to represent the identity relationships of state variables;

[0030] (7) Transformation rules in SLIM model and subsequent assignment constraints in XSAP model;

[0031] In the SLIM model, transformations are used to represent the dynamic behavior of the system;

[0032] In the XSAP model, subsequent assignment constraints are used to specify the next state value of the state variable, thereby representing the dynamic behavior of the module.

[0033] Based on predefined transformation rules, S1 designs and constructs the SLIM metamodel and XSAP metamodel, extracting common model feature structures, which are the abstract syntax structures of the SLIM metamodel and XSAP metamodel.

[0034] In S2 above, the model transformation algorithm based on ATL includes:

[0035] (1) Port conversion algorithm: For the port Port in the SLIM metamodel, the corresponding variable Var in the XSAP metamodel; if the port has an initial value, an initial assignment constraint statement is generated.

[0036] (2) State transition algorithm: For the State in the SLIM metamodel, the corresponding variable Var in the XSAP metamodel; if there is an initial state, an initial assignment constraint statement is generated.

[0037] (3) Sub-component conversion algorithm: Sub-components in the SLIM meta-model correspond to module instances in the XSAP meta-model;

[0038] (4) Connection conversion algorithm: For the Connection or Flow in the SLIM metamodel, it is mapped to the invariant assignment constraint statement in the XSAP metamodel.

[0039] (5) Transition algorithm: For the transition in the SLIM metamodel, extract the transition conditions and effects, and generate subsequent assignment constraint statements in the XSAP metamodel;

[0040] (6) Component conversion algorithm: The components in the SLIM metamodel correspond to the module definitions in the XSAP metamodel.

[0041] Step S3 above includes the following steps:

[0042] S31, Write a data structure to read the model into memory and build a model structure tree using the modules in the model as the basic unit;

[0043] S32, Design a verification algorithm to verify the model based on the model structure tree. The verification algorithm includes a connection redundancy check algorithm and a unique initial assignment constraint check algorithm.

[0044] S33. After completing the model verification, write the code template to obtain the final XSAP model file.

[0045] The connection redundancy check algorithm mentioned above is as follows:

[0046] Get a list of all nodes in the model's tree structure. Iterate through the list and check if each node is a leaf node. If it is, return the list. If it is an intermediate node, get the child component mapping `compMap`. Iterate through `compMap`. For each child component variable `compVarWrapper`, get its component variable type `type`. Find the corresponding component node `child` from the child nodes. Get all assignment maps for the child component variable `assignMap`. If `assignMap` is not empty, iterate through it to get the variable name `varName` of the child component's port variable. Find the port variable with the variable name `varName` in `child` and check if it has an `init` assignment constraint. If it does, delete it.

[0047] The algorithm for verifying the unique initial assignment constraint mentioned above is as follows:

[0048] The algorithm employs a depth-first traversal of the model's tree structure. If a node is a leaf node, it returns; otherwise, it traverses the node's child component mapping (compMap). For each child component variable (compVarWrapper), it obtains the variable's type (type) and finds the corresponding child component node of that type. Then, it obtains the child's port variable mapping (portMap), traverses the portMap, and retrieves the port variable (portVarWrapper). If portVarWrapper has an initial assignment constraint (init) but no subsequent assignment constraint (next), it searches for the assignment constraint for that port variable (portVarWrapper) based on the port variable name (portName) through the child component variable (compVarWrapper). If compVarWrapper does not have a subsequent assignment constraint for the child component's port variable (portVarWrapper), it creates the next assignment constraint. Finally, the algorithm is recursively called on all child components to complete the traversal of the entire tree.

[0049] The present invention has the following beneficial effects:

[0050] This invention can directly convert safety-critical systems from SLIM models to XSAP models. The converted XSAP models can be formally validated and analyzed using XSAP engine tools to check the functional consistency and completeness of the models and verify the correctness of the systems. The conversion algorithm and model validation algorithm proposed in this invention have universality. Attached Figure Description

[0051] Figure 1 This is a flowchart of the conversion method of the present invention;

[0052] Figure 2 This is a conversion framework diagram of the conversion method of the present invention;

[0053] Figure 3 This is the SLIM meta-model diagram of the present invention;

[0054] Figure 4 This is the XSAP meta-model diagram of the present invention;

[0055] Figure 5 This is a diagram of the transformation rules for the Transition section of the ATL transformation algorithm.

[0056] Figure 6 This is a schematic diagram of the conversion process;

[0057] Figure 7 This is a pseudocode diagram of the connection redundancy check algorithm;

[0058] Figure 8 This is a pseudocode diagram of the unique initial assignment constraint verification algorithm. Detailed Implementation

[0059] To make the objectives, technical solutions, and advantages of this invention clearer, the invention will be further described in detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the invention.

[0060] Although the steps in this invention are arranged by reference numerals, this is not intended to limit the order of the steps. Unless the order of the steps is explicitly stated or the execution of a step requires other steps as a basis, the relative order of the steps can be adjusted. It is understood that the term "and / or" as used herein refers to and covers any and all possible combinations of one or more of the associated listed items.

[0061] Combination Figure 1 This invention provides a method for converting an ATL-based SLIM model to an XSAP model, the method comprising the following steps:

[0062] S1. Based on the predefined model transformation rules, design the SLIM metamodel and XSAP metamodel, and obtain the abstract syntax structure of the SLIM metamodel and XSAP metamodel.

[0063] S2, Based on ATL, design a model conversion algorithm. Using the meta-model and abstract syntax structure obtained in step S1, convert the SLIM model to the XSAP model and obtain the converted XML format XSAP model.

[0064] S3. Design a verification algorithm to verify the XSAP model obtained in step S2, and obtain a complete XSAP model in SMV format.

[0065] This invention primarily addresses the problem of converting SLIM models to XSAP models. The implementation process consists of three parts. Figure 2 This is the conversion framework designed by the invention. The technical solution of the invention will be described in detail below with reference to the accompanying drawings.

[0066] S11, analyzing the characteristics of the SLIM model and the XSAP model, and combining the syntactic and semantic correspondences of the two languages, the following conversion rules are predefined:

[0067] The specific conversion rules are as follows.

[0068] Rule 1: Component-Module Mapping: This is the rule that maps the type declarations and implementation definitions used in the SLIM model to describe the components in the physical system to the module declarations used in the XSAP model to describe the components in the physical system.

[0069] In the SLIM model, components in the physical system are described through type declarations and implementation definitions;

[0070] In the XSAP model, the components of the physical system are described through module declarations.

[0071] Therefore, there is a correspondence between the type declarations and implementation definitions in SLIM and the module declarations in XSAP.

[0072] Rule 2: Data Port -- State Variable Mapping: This is the rule for mapping data ports in the SLIM model to state variables in the XSAP model;

[0073] In the SLIM model, data ports can describe the state of a component and can be used to exchange data with other components.

[0074] In the XSAP model, the state of a module is described by state variables. By instantiating a module, the parent module can access the variables of the child module, thus enabling data interaction.

[0075] There is a corresponding relationship between the data port and the state variable.

[0076] Rule 3: Initial Values ​​-- Initial Assignment Constraints: This refers to the conversion rules between initial values ​​in the SLIM model and initial assignment constraints in the XSAP model.

[0077] In the SLIM model, the definition of a data port can specify an initial value to represent the initial state of the component.

[0078] In the XSAP model, the initial values ​​of state variables can be specified through initial assignment constraints, thereby representing the initial state of the module.

[0079] There is a corresponding relationship between the initial value and the initial assignment constraint.

[0080] Rule 4: State-State Variable Mapping: This is the rule for mapping component states in the SLIM model to state variables in the XSAP model;

[0081] In the SLIM model, component implementations can define the possible states of a component, and transitions are implemented between states.

[0082] In the XSAP model, the module state is still described by state variables.

[0083] There is a correspondence between the state and the state variable mapping.

[0084] Rule 5: Subcomponent-Module Instance Variable Mapping: This is the rule for mapping subcomponents in the SLIM model to instance variables of instantiated modules in the XSAP model;

[0085] In the SLIM model, a hierarchical structure is introduced by defining child components, which are defined within the implementation of the parent component.

[0086] In the XSAP model, the hierarchical structure between modules is represented by instantiating modules.

[0087] There is a corresponding relationship between the child component and the module instance variable.

[0088] Rule 6: Connectivity (Flow) - Invariant Assignment Constraint: This is the conversion rule between connectivity in the SLIM model and invariant assignment constraints in the XSAP model;

[0089] In the SLIM model, connections are mainly used for communication between different components, operating on source and destination ports, transmitting the value of the source port to the destination port without delay, so that the value of the destination port is always equal to the value of the source port.

[0090] If it is a flow, the source of the flow may be a port or an expression, and the semantics of the expression are the same as those of a connection.

[0091] In the XSAP model, the identity relationship of state variables is represented by invariant assignment constraints, such as a:=expr(b).

[0092] Therefore, there is a corresponding relationship between the connection (stream) and the invariant assignment constraint.

[0093] Rule 7: Transformation-Subsequent Assignment Constraints: This refers to the transformation rules between the transformation in the SLIM model and the subsequent assignment constraints in the XSAP model.

[0094] In the SLIM model, a transition represents the dynamic behavior of the system. It includes the event trigger e, the guard g, and the effect f. A transition from the source state to the target state occurs and produces an effect when a certain event is triggered and the guard condition is met, i.e., m - [e when g then f] -> m'. This effect is a delayed effect.

[0095] In the XSAP model, the next state value of a state variable can be specified through subsequent assignment constraints, i.e., next(a):=expr(m,e,g,f), thereby representing the dynamic behavior of the module.

[0096] The conversion and subsequent assignment constraints have a corresponding relationship.

[0097] S12. Based on predefined transformation rules, design and construct the SLIM metamodel and XSAP metamodel, and extract the common model feature structure, which is the abstract syntax structure of the SLIM metamodel and XSAP metamodel.

[0098] Based on the transformation rules defined above and considering the characteristics of the language, SLIM metamodel and XSAP metamodel were designed as follows: Figure 3 , Figure 4 As shown.

[0099] S2, Design a model conversion algorithm based on ATL. According to the meta-model obtained in step S1, use the ATL conversion language to write rules, match the classes in the SLIM meta-model and the classes in the XSAP meta-model, process the conversion of elements between models, and finally realize the conversion of the SLIM model to the XSAP model, and obtain the converted XML format XSAP model.

[0100] The model transformation algorithm based on ATL includes the following steps:

[0101] (1) Port conversion algorithm:

[0102] In the SLIM metamodel, the class Port corresponds to the class PortVar in the XSAP metamodel. The conversion algorithm first maps attributes to the PortVar class. The mapping of type attributes uses helper functions to compensate for differences in type definitions between the two languages. For example, in SLIM, the boolean type is bool, while in XSAP it is boolean. After constructing the basic PortVar class, it is necessary to determine whether the Port instance to be converted contains a default value. If it is not empty, an initial assignment constraint Init is generated, realizing the conversion from the initial port value to the initial assignment constraint.

[0103] (2) State transition algorithm:

[0104] In the SLIM metamodel, the class StateMachine contains all states, corresponding to the class StateVar in the XSAP metamodel. The transformation algorithm constructs instances of StateVar and sets their corresponding attributes. The set of states in StateVar represents the state variables of StateMachine, assigning them possible values. Using the ATL parsing algorithm, the State class in SLIM is converted to the State class in XSAP. If an initial state exists, an initial assignment constraint statement Init is generated.

[0105] (3) Sub-component conversion algorithm:

[0106] In SLIM, the SubComponent class corresponds to a submodule variable in XSAP, and is defined as the ComponentVar class in the metamodel, belonging to the state scalar category. ComponentVar instances are constructed through direct mapping.

[0107] (4) Connection (stream) conversion algorithm:

[0108] The Connection class in the SLIM metamodel is matched to the XSAP Connection class and stored as a copy. The key to this conversion is generating invariant assignment constraints, which is essentially a conversion of the Connection class in the SLIM metamodel to the Assign class in the XSAP metamodel. First, an instance of the XSAP Connection class is constructed to store the connection information. An Assign class is then constructed to represent the assignment constraint, with the assignment object being the connection target port and the value being the connection source port. Since invariant assignment constraints are being generated, an Invar class instance is created and assigned to the Assign's invar variable.

[0109] (5) Transition algorithm:

[0110] The `transition` class in the SLIM metamodel is matched with the `Transition` class in XSAP and stored as a copy. The key is generating subsequent assignment constraints; the effect of the transformation is essentially a conversion of the `transition` class in the SLIM metamodel to the `Assign` class in the XSAP metamodel. First, an instance of the XSAP `Transition` class is constructed to store the transformation information. Before generating the `Assign` class instance, the transformation information needs to be processed. First, the complete transformation condition needs to be extracted as the condition for subsequent assignment constraints. It consists of the current state, trigger, and guard.

[0111] condition=val(state)+trigger+guard

[0112] After constructing the condition transformation, the Assign class instance is generated. Based on the effect, the affected port variable name (name) and value (value) are determined, thus generating the subsequent assignment constraint Next; the transformation algorithm is as follows... Figure 5 As shown;

[0113] (6) Component conversion algorithm:

[0114] In SLIM, a complete component consists of declarations and implementations, namely the System and SystemImpl classes in the SLIM metamodel, corresponding to the Module class in the XSAP metamodel. These are the fundamental building blocks of their respective models and also the top-level structure of the metamodel. A conversion algorithm transforms instances of the System and SystemImpl classes with the same name into instances of the Module class. Attribute values ​​are then set to generate the Module instance in XSAP.

[0115] The ATL transformation engine reads the meta-model and the input source model, runs the transformation algorithm, and obtains the transformed XSAP model. Examples are provided below. Figure 6 As shown.

[0116] S3. Design a verification algorithm to verify the XSAP model obtained in step S2, and obtain a complete XSAP model in SMV format.

[0117] S31, Write a data structure to read the model into memory and build a system model structure tree using the modules in the model as the basic unit;

[0118] S32, Design a verification algorithm to verify the model based on the model structure tree;

[0119] The XSAP model obtained through ATL transformation differs slightly from the original model. The issues are as follows:

[0120] Question 1: If SLIM only determines the initial value of the output port, the port value remains unchanged. XSAP, however, will randomly assign values ​​to variables if only the initial value is determined.

[0121] Question 2: In SLIM, the initial value of the Port is determined in the component definition, and it also serves as the connection target, receiving the value from the source. Therefore, the connection overrides the initial value of the Port. In the XSAP model, initial assignment constraints and invariant assignment constraints cannot coexist.

[0122] To address problem 1, a connection redundancy check algorithm is proposed, such as... Figure 7 As shown.

[0123] Retrieve a list of all nodes in the model's tree structure. Iterate through the list, checking if each node is a leaf node. If it is, return the list. If it is an intermediate node, retrieve the child component mapping `compMap`. Iterate through `compMap`. For each child component variable `compVarWrapper`, retrieve its component variable type `type`. Find the corresponding component node `child` from the child nodes. Retrieve all assignment maps for that child component variable. If `assignMap` is not empty, iterate through it to get the variable name `varName` of the child component's port variable. Find the port variable with the variable name `varName` in `child` and check if it has an `init` assignment constraint. If it does, delete it.

[0124] To solve problem 2, a unique initial assignment constraint verification algorithm is proposed, as follows: Figure 8 As shown.

[0125] The algorithm employs a depth-first traversal of the model's tree structure. If a node is a leaf node, it returns; otherwise, it traverses the node's child component mapping (compMap). For each child component variable (compVarWrapper), it obtains the variable's type (type) and finds the corresponding child component node of that type. Then, it obtains the child's port variable mapping (portMap), traverses the portMap, and retrieves the port variable (portVarWrapper). If portVarWrapper has an initial assignment constraint (init) but no subsequent assignment constraint (next), it searches for the assignment constraint for that port variable (portVarWrapper) based on the port variable name (portName) through the child component variable (compVarWrapper). If compVarWrapper does not have a subsequent assignment constraint for the child component's port variable (portVarWrapper), it creates the next assignment constraint. Finally, the algorithm is recursively called on all child components to complete the traversal of the entire tree.

[0126] S33. After completing the model verification, write the code module to obtain the final complete XSAP model.

[0127] The meanings of the English terms in this invention are as follows:

[0128] ATL: Atlas Transformation Language

[0129] SLIM: System-Level Integrated Language

[0130] XSAP: eXtended Safety Assessment Platform

[0131] MBSE: Model Based System Engineering

[0132] MBSA: Model Based Safety Analysis

[0133] CTL: Computing Tree Language

[0134] LTL: Linear Temporal Logic

[0135] It will be apparent to those skilled in the art that the present invention is not limited to the details of the exemplary embodiments described above, and that the invention can be implemented in other specific forms without departing from its spirit or essential characteristics. Therefore, the embodiments should be considered in all respects as exemplary and non-limiting, and the scope of the invention is defined by the appended claims rather than the foregoing description. Thus, all variations falling within the meaning and scope of equivalents of the claims are intended to be included within the present invention. No reference numerals in the claims should be construed as limiting the scope of the claims.

[0136] Furthermore, it should be understood that although this specification describes embodiments, not every embodiment contains only one independent technical solution. This narrative style is merely for clarity. Those skilled in the art should consider the specification as a whole, and the technical solutions in each embodiment can also be appropriately combined to form other embodiments that can be understood by those skilled in the art.

Claims

1. A method for converting an ATL-based SLIM model to an XSAP model, characterized in that, include: Step S1: Design the SLIM metamodel and XSAP metamodel according to the predefined model transformation rules, and obtain the abstract syntax structure of the SLIM metamodel and XSAP metamodel. Step S2: Based on ATL, design a model conversion algorithm. Using the meta-model and abstract syntax structure obtained in step S1, convert the SLIM model to the XSAP model to obtain the converted XML format XSAP model. Step S3: Design a verification algorithm to verify the XSAP model obtained in step S2, and obtain a complete XSAP model in SMV format. S1 analyzes the characteristics of SLIM and XSAP models and predefines the following transformation rules: (1) The rules for mapping the type declarations and implementation definitions used in the SLIM model to describe the components in the physical system to the module declarations used in the XSAP model to describe the components in the physical system; (2) Rules for mapping data ports in the SLIM model to state variables in the XSAP model; The data ports in the SLIM model are used to describe the state of components and to exchange data with other components. The state variables in the XSAP model are used to describe the module state; (3) The conversion rules between initial values ​​in the SLIM model and initial assignment constraints in the XSAP model; In the SLIM model, the initial values ​​are specified through data port definitions and are used to represent the initial state of the components; In the XSAP model, the initial assignment constraint is used to specify the initial values ​​of the state variables, thereby representing the initial state of the module; (4) Rules for mapping component states in the SLIM model to state variables in the XSAP model; In the SLIM model, component states are defined through components, and transitions are achieved between states. In the XSAP model, state variables are used to describe the module state; (5) Rules for mapping sub-components in the SLIM model to instance variables of instantiated modules in the XSAP model; In the SLIM model, sub-components are used to introduce a hierarchical structure, and the sub-components are defined in the implementation of the parent component; In the XSAP model, instantiated module instance variables are used to represent the hierarchical structure between modules; (6) The conversion rules between the connection in the SLIM model and the invariant assignment constraint in the XSAP model; The SLIM model connects the source port and the target port for communication and operation between different components, transmitting the value of the source port to the target port without delay, so that the value of the target port is always equal to the value of the source port. In the XSAP model, invariant assignment constraints are used to represent the identity relationships of state variables; (7) Transformation rules in SLIM model and subsequent assignment constraints in XSAP model; In the SLIM model, transformations are used to represent the dynamic behavior of the system; In the XSAP model, subsequent assignment constraints are used to specify the next state value of the state variable, thereby representing the dynamic behavior of the module.

2. The method for converting an ATL-based SLIM model to an XSAP model according to claim 1, characterized in that, Step S1 involves designing and constructing the SLIM metamodel and XSAP metamodel based on predefined transformation rules, and extracting the common model feature structure, which is the abstract syntax structure of the SLIM metamodel and XSAP metamodel.

3. The method for converting an ATL-based SLIM model to an XSAP model according to claim 1, characterized in that, In S2, the model transformation algorithm based on ATL includes: (1) Port conversion algorithm: For the port Port in the SLIM metamodel, the corresponding variable Var in the XSAP metamodel; if the port has an initial value, an initial assignment constraint statement is generated. (2) State transition algorithm: For the State in the SLIM metamodel, the corresponding variable Var in the XSAP metamodel; if there is an initial state, an initial assignment constraint statement is generated. (3) Sub-component conversion algorithm: Sub-components in the SLIM meta-model correspond to module instances in the XSAP meta-model; (4) Connection conversion algorithm: For the Connection or Flow in the SLIM metamodel, it is mapped to the invariant assignment constraint statement in the XSAP metamodel. (5) Transition algorithm: For the transition in the SLIM metamodel, extract the transition conditions and effects, and generate subsequent assignment constraint statements in the XSAP metamodel; (6) Component conversion algorithm: The components in the SLIM metamodel correspond to the module definitions in the XSAP metamodel.

4. The method for converting an ATL-based SLIM model to an XSAP model according to claim 1, characterized in that, Step S3 includes the following steps: S31, Write a data structure to read the model into memory and build a model structure tree using the modules in the model as the basic unit; S32, Design a verification algorithm to verify the model based on the model structure tree. The verification algorithm includes a connection redundancy check algorithm and a unique initial assignment constraint check algorithm. S33. After completing the model verification, write a complete SMV format XSAP model code template to obtain the final SMV format XSAP model file.

5. The method for converting an ATL-based SLIM model to an XSAP model according to claim 4, characterized in that, The connection redundancy check algorithm is specifically as follows: Get a list of all nodes in the model's tree structure. Iterate through the list and check if each node is a leaf node. If it is, return the list. If it is an intermediate node, get the child component mapping `compMap`. Iterate through `compMap`. For each child component variable `compVarWrapper`, get its component variable type `type`. Find the corresponding component node `child` from the child nodes. Get all assignment maps for the child component variable `assignMap`. If `assignMap` is not empty, iterate through it to get the variable name `varName` of the child component's port variable. Find the port variable with the variable name `varName` in `child` and check if it has an `init` assignment constraint. If it does, delete it.

6. The method for converting an ATL-based SLIM model to an XSAP model according to claim 4, characterized in that, The algorithm for verifying the unique initial assignment constraint is as follows: The algorithm employs a depth-first traversal of the model's tree structure. If a node is a leaf node, it returns; otherwise, it traverses the node's child component mapping (compMap). For each child component variable (compVarWrapper), it obtains the variable's type (type) and finds the corresponding child component node of that type. Then, it obtains the child's port variable mapping (portMap), traverses the portMap, and retrieves the port variable (portVarWrapper). If portVarWrapper has an initial assignment constraint (init) but no subsequent assignment constraint (next), it searches for the assignment constraint for that port variable (portVarWrapper) based on the port variable name (portName) through the child component variable (compVarWrapper). If compVarWrapper does not have a subsequent assignment constraint for the child component's port variable (portVarWrapper), it creates the next assignment constraint. Finally, the algorithm is recursively called on all child components to complete the traversal of the entire tree.

Images