WO2024031695A1 - Requirement description data reuse method and device, and storage medium - Google Patents

Abstract

Embodiments of the present application provide a requirement description data reuse method and device, and a storage medium. The method comprises: on the basis of a preset requirement behavior tree building grammar, building a current requirement behavior tree representing the current requirement description, wherein the requirement behavior tree comprises: a logic node representing an execution logic and an action node representing an execution operation; and in the process of building the current requirement behavior tree or after the current requirement behavior tree is built, comparing the similarity between the current requirement behavior tree and a plurality of stored built requirement behavior trees, and searching for a built requirement behavior tree having the largest common subtree with the current requirement behavior tree so as to reuse related requirement description data of the found built requirement behavior tree. The technical solution in embodiments of the present application can reuse requirement description data in requirements engineering, and improve the automation degree and the efficiency of implementation of requirements engineering.

Description

Requirements describe data reuse methods, devices and storage media Technical field

This application relates to the field of industrial technology, and in particular to a requirement description data reuse method, device and computer-readable storage medium.

Background of the invention

Requirements engineering is a method of engineering production systems at a more abstract level. The process of converting requirements into an executable production system requires a high degree of automation, which should at least make the conversion process significantly simpler.

Currently, the most popular requirements description tools use work instructions to describe requirements. However, work instructions are mostly in text format, and the text formats of different suppliers are very different. The main problem is that it is difficult to convert work instructions into structured data formats such as tree structures or graph structures, making it difficult to convert work instructions into Software or programs used to build production systems. Therefore, in order to implement requirements engineering, we first need a method to standardize the generation process of demand descriptions and improve the automation of demand descriptions.

Therefore, those skilled in the art are still working on finding other requirements engineering implementation solutions.

Contents of the invention

In view of this, embodiments of the present application provide, on the one hand, a method for reusing requirement description data, and on the other hand, provide a device for reusing requirement description data and a computer-readable storage medium, which can realize the reuse of requirement description data in requirements engineering, and It can improve the automation and efficiency of requirements engineering implementation.

In order to solve the above technical problems, the technical solution of this application is implemented as follows:

A method for reusing demand description data, including: building a current demand behavior tree representing the current demand description based on a preset demand behavior tree construction grammar; the demand behavior tree includes: logical nodes representing execution logic and actions representing execution operations Node; in the process of constructing the current demand behavior tree or after completing the construction of the current demand behavior tree, perform a similarity comparison between the current demand behavior tree and multiple stored demand behavior trees, and search for the similarity with the current demand behavior tree. It is stated that the current demand behavior tree has a built demand behavior tree with the largest common subtree, so as to reuse the relevant demand description data of the found built demand behavior tree.

A device for reusing demand description data, including at least one memory and at least one processor, wherein: the at least one memory is used to store a computer program; the at least one processor is used to call the computer program stored in the at least one memory, Execute the requirement description data reuse method as described in any of the above embodiments.

A computer-readable storage medium on which a computer program is stored; the computer program can be executed by a processor and implement the requirement description data reuse method as described in any of the above embodiments.

As can be seen from the above technical solution, in the embodiment of the present application, since the current demand behavior tree representing the current demand description is constructed based on the preset demand behavior tree construction grammar, in the process of constructing the current demand behavior tree or after the construction is completed, After creating the current demand behavior tree, compare the similarity between the current demand behavior tree and multiple stored demand behavior trees, search for the built demand behavior tree that has the largest common subtree with the current demand behavior tree, and Reuse the relevant requirement description data found in the established requirement behavior tree, thereby improving the efficiency of requirements engineering implementation.

Brief description of the drawings

In order to better understand the present application, the embodiments of the present application will be described in detail below with reference to the accompanying drawings, so that the above and other features and advantages of the present application will be clearer to those of ordinary skill in the art. In the accompanying drawings:

Figure 1 is an exemplary flow chart of a requirement description data reuse method in an embodiment of the present application.

Figure 2A is an assembly diagram in an example of this application.

Figure 2B is an exploded view and assembly topology diagram of the assembly diagram shown in Figure 2A.

Figure 2C is an exploded view of the assembly process of the assembly diagram shown in Figure 2A.

Figure 2D is a requirements behavior tree corresponding to a subassembly process in Figure 2C.

Figure 3A and Figure 3B are two requirement behavior trees of an example of this application.

Figures 3C and 3D are schematic diagrams after adding directional connections between the two action nodes in the demand behavior tree shown in Figures 3A and 3B respectively.

Figure 4A is a schematic diagram of an action node graph in an example of this application.

Figure 4B is a schematic diagram of a conditional node graph in an example of the present application.

FIG. 5 is a schematic diagram of the demand map obtained corresponding to the demand behavior tree shown in FIG. 2D in this application.

6A to 6D are schematic diagrams of the graph edit distance algorithm in an example of this application.

FIG. 6E is a schematic diagram of the largest common subgraph in the demand map shown in FIG. 6A and the demand map shown in FIG. 6D.

Figure 7 is a schematic diagram comparing two action node graphs in an example of this application.

Figure 8 is an exemplary flow chart of a method for building a demand behavior tree in an embodiment of the present application.

Figures 9A to 9C show three compliant pairs obtained when pairing is established based on the assembly diagram shown in 2A in an example of this application.

Figure 9D and Figure 9E are two non-compliant pairs obtained when pairing is established based on the assembly diagram shown in 2A in an example of this application.

Figure 9F is a schematic diagram after adding assembly process information to a compliant pair in an example of this application.

FIG. 10 is a schematic diagram of compliance pairing involved in a sub-assembly process in FIG. 2C in an example of the present application.

Figure 11 is an exemplary structural diagram of a requirement description data reuse device in an embodiment of the present invention.

Figure 12 is an exemplary structural diagram of another requirement description data reuse device in an embodiment of the present application.

Among them, the reference signs are as follows:

label	meaning
101～103, 801～807	step
P1～P14	Component
SA1～SA10	components
A1～A6, A, 71, 73	action node
C1, C2, C	condition node
Se	sequence node
Pa	Parallel nodes
FB	selector node
P	Component
R	robot
M	move
Pi	pick up
Cx	Coaxial
T	touch
Pl	place
S	itself

TTO	to target object
TTP	to target location
TA, TB, TC, TD			type
72, 74	action node graph
1, 2, 3, 4	pair
1101	first module
1102	Second module
1103	The third module
1201	memory
1202	processor
1203	bus

How to implement this application

In the embodiment of this application, considering that the behavior tree is a structured data format, in order to enable the requirement description to be converted into software or programs for building a production system, a technical solution for using the behavior tree to represent the requirement description is considered. Accordingly, , the requirement description represented by a behavior tree can be called a requirement behavior tree (RBT, Requirement Behavior Tree). Further, in order to improve the speed of building demand behavior trees, the historically constructed demand behavior trees can be stored in a database to form a library of built demand behavior trees. Later, when building the current demand behavior tree, the already built demand behavior trees are recommended. Similar requirement behavior trees in the library, thereby realizing the reuse of requirement behavior trees. Or, in order to improve the workflow speed of creating a demand behavior tree, after the current demand behavior tree is built, the relevant workflow data corresponding to similar demand behavior trees in the established demand behavior tree library can be reused in the currently constructed demand behavior. In the workflow corresponding to the tree. The workflow in this embodiment refers to the executable program part that implements the corresponding operations in the required behavior tree.

In order to make the purpose, technical solutions and advantages of the present application more clear, the technical solutions of the present application will be described in detail below with reference to the accompanying drawings and examples.

Figure 1 is an exemplary flow chart of a requirement description data reuse method in an embodiment of the present application. As shown in Figure 1, the method may include the following processing:

Step 101: Construct the current demand behavior tree representing the current demand description based on the preset demand behavior tree construction grammar. The demand behavior tree includes: logical nodes representing execution logic and action nodes representing execution operations. In this embodiment, logical nodes may include various nodes used to control execution logic, such as sequential nodes, parallel nodes, and conditional nodes in traditional behavior trees.

Taking the assembly process as an example, Figure 2A shows an assembly diagram in an example, and Figure 2B is an exploded view and assembly topology diagram of the assembly diagram shown in Figure 2A. Figure 2C shows an exploded view of the assembly process of the assembly diagram shown in Figure 2A. Among them, P1 to P14 are the various parts (P, Part) that constitute the assembly diagram shown in Figure 2A, and SA1 to SA10 are the various components obtained during the assembly process. In this embodiment, when creating a demand behavior tree for the assembly process shown in Figure 2C, if the current demand behavior tree currently obtained is for a sub-assembly process in Figure 2C: component SA3 + part P5 = component SA4, the obtained result is as shown in Figure 2C The demand behavior tree shown in 2D. In Figure 2D, boxes A1 to A6 are six action nodes, which respectively represent: A1: robot (R, Robot) moves (M, Move) itself (S, Self) to part P5; A2: The robot picks up (Pi, Pick) part P5; A3: The robot coaxially (Cx, Coaxial) part P5 and part P2; A4: The robot touches (T, Touch) part P5 and part P4; A5: The robot places (Pl , Place) Part P5; A6: The robot moves itself to reset. The single arrow represents the sequence node Se in the behavior tree, the double arrow represents the parallel node Pa in the behavior tree, C1 and C2 are two condition nodes, respectively representing: C1: Part P5 Coaxial part P2? C2: Part P5 touches part P4? In Figure 2D, the question mark represents the selector (FB, Fallback) node. Its function is to execute each node mounted under the node in order. The execution of this node will not end until a node returns true. Take the example in the figure, the condition node C1 and the action node A3 are mounted under the selector node. As long as the condition of the condition node C1 is false, that is, the part P5 and the part P2 are not on the same axis, the action node A3 needs to be executed until the condition node C1 The condition of is true, that is, when part P5 and part P2 are coaxial, the selector node ends execution, that is, action node A3 is no longer executed.

In this step, as the demand behavior tree construction process progresses, the current demand behavior tree is constantly updated. For example, for the current demand behavior tree shown in Figure 2D, at the beginning, there are only sequential nodes in the first layer. Later, each node in the second layer will be constructed, and then each node in the third or even fourth layer will be obtained. node. After that, other nodes will be obtained until the requirements behavior tree corresponding to the entire assembly process shown in Figure 2C is obtained.

Step 102: During the process of constructing the current demand behavior tree or after the construction of the current demand behavior tree is completed, perform a similarity comparison between the current demand behavior tree and multiple stored demand behavior trees, and search and The current demand behavior tree has a built demand behavior tree with the largest common subtree.

In this embodiment, the historically constructed demand behavior tree can be stored in a database to form a built demand behavior tree library. Then in this step, the similarity of the current demand behavior tree and multiple stored demand behavior trees can be compared to find a demand behavior tree whose similarity reaches the set requirement, for example, search for a demand behavior tree that is similar to the current demand behavior tree. There is a built requirements behavior tree with a largest common subtree.

During specific implementation, it is considered that in some applications, when the similarity of two demand behavior trees is directly compared, the execution order of all child nodes of the sequence node is usually not considered. For example, for the two demand behavior trees shown in Figure 3A and Figure 3B, although Figure 3A shows that action node A2 is executed first and then action node A5, and Figure 3B shows that action node A5 is executed first and then action node A2, some applications When comparing the two requirement behavior trees shown in Figure 3A and Figure 3B, the two requirement behavior trees may be regarded as the same requirement behavior tree.

To this end, in this step, it is considered to convert the current demand behavior tree into a graph format to add directional links between the sub-nodes of the sequence nodes so that the hidden representation rules of the demand behavior tree are explicitly expressed using graph connections. , thereby obtaining the current demand map. Compare the similarity between the current demand map and each built demand map converted from each built demand behavior tree based on the same rules, and search for the built demand map whose similarity reaches the set requirements, for example, search for the current demand map There is a built demand map with the largest common submap; the built demand behavior tree corresponding to the found demand map that has the largest common submap with the current demand map is regarded as having the largest common submap with the current demand behavior tree. The built demand behavior tree of the subtree, that is, the demand behavior tree whose similarity reaches the set requirements. The demand map includes: map nodes representing each node in the corresponding demand behavior tree, and directional connections connecting each map node.

For example, for the two demand behavior trees shown in Figure 3A and Figure 3B, after converting them into demand graphs, there will be a directional connection between action node A2 and action node A5, as shown in Figure 3C and Figure 3D. It shows that when you compare the two at this time, you can find that they are different, which avoids the problem of equating the two when directly comparing the requirement behavior tree.

In addition, considering that behavior tree nodes such as action nodes and condition nodes in the behavior tree also contain various implicit information, especially when different behavior tree nodes are described using different semantic formats, it is difficult for some applications to describe them. classification, so they cannot be compared directly.

To this end, in this embodiment, it is considered that in the required behavior tree, the behavior tree nodes containing implicit information such as the action nodes and condition nodes are expressed according to the set semantic format, and the set semantic format can is split into multiple semantic fields. For example, in one example, the set semantic format may be: subject, predicate, object, context; wherein the context is optional. Correspondingly, the set semantic format can be split into a subject field, a predicate field, an object field, and a context field. During specific implementation, this embodiment may further provide a standard semantic library to standardize the semantics that may be involved. For example, predicates such as "move" and "coaxial" can be obtained from the standard semantic library.

Afterwards, when converted into a demand graph, the action nodes, condition nodes and other behavior tree nodes containing implicit information are converted into corresponding behavior tree node graphs, which include: tree node graph nodes that refer to the behavior tree nodes, A field map node that refers to each semantic field of the behavior tree node, and a directional connection between the tree node map node and each field map node.

For example, for the action node "A1: the robot moves itself to part P5", when it is converted into an action node graph, it can include a total of five nodes: action A, robot R, movement M, self S, and to the target object TTO. That is, the node ∈ {action, robot, move, itself, to the target object}, and includes: action → robot, action → move, action → itself, action → to the target object, a total of four directional connections, that is, directional connections ∈ {( action, robot), (action, move), (action, self), (action, to target object)}. The corresponding action node graph can be shown in Figure 4A. It can be seen that the action node graph converted by the action node includes: an action graph node that refers to the action node, a field graph node that refers to each semantic field of the action node, and a connection between the action graph node and each field graph node. directional connections between.

For another example, for the conditional node "C1: Part P5, Coaxial Part P2", when it is converted into a conditional node graph, it can include four nodes: condition C, part P, coaxial Cx, and part P, that is, node ∈ {condition, part, coaxial, part}, and includes: condition → part, condition → coaxial, condition → part, a total of three directional connections, that is, directional connection ∈ {(condition, part), (condition, coaxial) , (condition, part)}. The corresponding conditional node graph can be shown in Figure 4B. It can be seen that the condition node graph converted by the condition node includes: a condition graph node that refers to the condition node, a field graph node that refers to each semantic field of the condition node, and a condition graph node that is connected between the condition graph node and each field graph node. directional connections between.

In this embodiment, when the demand behavior tree is converted into a demand graph, for each action node and condition node and other behavior tree nodes that contain implicit information, in addition to the predicate, the meanings of the subject, object, and context in the semantic information are all To generalize, for example, "Part P5" and "Part P2" both need to be generalized to "Part (P, Part)", and "To Part P5" needs to be generalized to "To Target Object (TTO, To Target Object)" ", "To the initial position (or reset)" needs to be generalized to "To the target position (TTP, To Target Position)". In Figure 4A and Figure 4B, the part is the class of part P5 and part P2, so both Generalize to the corresponding class; in addition, predicates such as "move" and "coaxial" and contexts such as "to target object" and "to target position" can be selected from the predefined standard semantic library; "self" is action A placeholder object that can represent, for example, a robot moving on its own without performing any operations.

According to the above conversion method from demand behavior tree to demand map, the current demand behavior tree shown in Figure 2D can be converted into the current demand map shown in Figure 5. In Figure 5, different nodes can be distinguished by different colors, and different child nodes of the same node can also be represented by different colors.

When comparing the similarity between the current demand map and each established demand map, the Graph Edit Distance (GED) algorithm can be used to calculate the similarity. 6A to 6D show a schematic diagram of the graph edit distance algorithm in an example. As shown in Figure 6A to Figure 6D, all include Type A (TA, Type A), Type B (TB, Type B), Type B, Type C (TC, Type C) and Type D (TD, Type D) Five nodes, but the directed connections between nodes are different. Converting from the map of Figure 6A to the map of Figure 6D requires the process of deleting two directional connections as shown in Figure 6B and adding two directional connections as shown in Figure 6C, that is, the gap between the map of Figure 6A and the map of Figure 6D The graph edit distance GED is 4, which is the number of operations required to convert the graph in Figure 6A into the graph in Figure 6D. It can be seen that the smaller the GED, the higher the similarity between the two maps.

The most similar built demand map can be found by calculating GED, and then the maximum common subgraph (Maximum Common Sub-Graph, MCS) in the most similar built demand map and the current demand map can be used to obtain the most similar built demand map. extract reusable information. As shown in Figure 6E, the largest common subgraph in the current demand map of Figure 6A and the built demand map of Figure 6D can be shown as the part enclosed by the dotted line in Figure 6E, where the MCS size is 4, that is, type A→ Type B → Type B → Type C, a total of 4 identical nodes with the same edges (ie directional connections).

In order to extend GED and MCS to behavior trees, the integrity of MCS needs to be checked, that is, when comparing the current demand map with each built demand map converted from each built demand behavior tree, each action node in the demand map Compare the map with the condition node as a whole. When there is a complete action node or a complete condition node in the current demand map in the established demand map, the action node or the complete condition node in the current demand map The condition node is determined to exist in the built requirements graph. As shown in Figure 7, the first action node graph 72 obtained for the first action node 71 and the second action node graph 74 obtained for the second action node 73 in Figure 7, although most of the contents of the two (i.e., the dashed line enclosed are the same, but because they have a different field graph node, the two graphs are different.

After finding a built demand map that has the largest common submap with the current demand map based on the similarity comparison of the demand map, determine the relationship between the built demand behavior tree and the current demand behavior tree based on the largest common submap. The largest common subtree is the built demand behavior tree corresponding to the built demand map as the built demand behavior tree that has the largest common subtree with the current demand behavior tree.

Step 103: Reuse the found relevant requirement description data of the established requirement behavior tree.

In this embodiment, in step 102, during the process of constructing the current demand behavior tree, a similarity comparison is performed between the current demand behavior tree and multiple stored demand behavior trees. Correspondingly, this In step 103, the found established requirement behavior tree may be recommended as a candidate established requirement behavior tree to help build the current requirement behavior tree.

Alternatively, in step 102, after completing the construction of the current demand behavior tree, a similarity comparison between the current demand behavior tree and multiple stored demand behavior trees may be performed. Correspondingly, in step 103, The sub-workflow data corresponding to the largest common subtree can be obtained from the found workflow data corresponding to the built demand behavior tree; the sub-workflow data can be reused in the work corresponding to the current demand behavior tree. in streaming data.

For the requirements behavior tree constructed in the assembly diagram in step 101, one of the implementation methods is introduced below. Figure 8 is an exemplary flow chart of a method for building a demand behavior tree in an embodiment of the present application. As shown in Figure 8, the method may include the following steps:

Step 801: Establish each compliance pairing of the assembly relationship in advance based on the historical assembly drawing, and add assembly process information for each compliance pairing. Among them, each pre-established compliance pairing can be stored in a database to form a compliance matching library. Among them, compliance pairing refers to a pairing consisting of mechanical drawings of two parts with an assembly relationship. That is, in this step, each compliance pair consists of mechanical drawings of two parts with an assembly relationship. Having an assembly relationship here may, for example, mean that the two parts in each conforming pair are connected to each other via part surfaces, or it may be that the spatial relationship between the two parts in each conforming pair facilitates assembly. In contrast, a pair consisting of two parts that have no assembly relationship can be called a non-compliant pair. In the process of establishing compliant matching, non-compliant matching needs to be discarded.

For example, taking the historical assembly drawing including the assembly drawing shown in Figure 2A as an example, Figures 9A to 9C show three of the compliant pairings obtained when pairing is established based on the assembly drawing shown in 2A, that is, the first compliant pairing. 1. The second compliance pairing 2 and the third compliance pairing 3, that is, part P2 and part P4 form a compliance pairing, part P2 and part P6 form a compliance pairing, and part P2 and part P5 form a compliance pairing. As shown in Figures 9A-9C, the spatial relationship between the two parts in each conforming pair facilitates assembly. Although there is no close connection between the two parts P2 and P5 in the pairing shown in Figure 9C, because the part P5 has only one degree of freedom (DOF, Degree of Freedom) that can leave the part P2, or because the part P2 can be constrained The degree of freedom of part P5, so there is an assembly relationship between the two.

Figures 9D and 9E show two of the non-compliant pairs obtained when pairing is established based on the assembly diagram shown in 1A. As shown in Figures 9D and 9E, the spatial relationship between the two parts in each non-conforming pairing does not contribute to the assembly and therefore needs to be discarded.

In this step, when adding assembly process information for each compliance pairing, the assembly process information can be described in any suitable sentence format. For example, you can use standard statement format, asset management shell (AAS) statement format, OPC UA statement format, etc. In this embodiment, consider using the following statement format:

Statement = (subject, predicate, object, context). Wherein, the context is optional, that is, it can be null.

Taking the compliance pairing 2 shown in Figure 9B as an example, after adding the assembly process information according to the above statement format, it can be shown in Figure 9F, including the following information:

Fixing device fixes part P2;/where subject=fixing device, predicate=fixed, object=part P2

The robot picks up part P6;/where subject = robot, predicate = picking up, object = part P6

The robot tightens part P6 onto part P2. /Among them, subject = robot, predicate = tighten, object = part P6, context = to part P2

In addition to the assembly process information shown in Figure 9F, the assembly process information as described below can also be used:

Fixing device fixing parts P6;

The robot picks up the part P2;

The robot tightens part P2 onto part P6.

The above statement format makes it easy to build maps for various calculation purposes, and it is easy to attach all necessary assembly process information, such as auxiliary materials (such as fixtures) and tools/equipment (such as robots) used. In this way, a compliant pairing library with additional assembly process information is obtained.

Step 802: Receive a bill of materials including the names of various parts involved in the current assembly. The part name in this embodiment can be any name represented by any one or any combination of letters, numbers, characters and words that can distinguish each part.

In specific implementation, the bill of materials in this step can be a table, which lists the names of various parts. For example, taking the assembly diagram shown in Figure 1A corresponding to the current assembly as an example, the bill of materials can include: "P1" to "P14" represents the names of a total of 14 parts. There may be no matching relationship between the names of these 14 parts.

In addition, in other embodiments, the names of each part in the bill of materials may also be paired in advance based on the principle that there is an assembly relationship between the two corresponding parts. For example, "P2" and "P5" can be combined into a name pair, and "P4" and "P5" can be combined into a name pair.

Step 803: According to the bill of materials, obtain the mechanical drawing, such as a CAD drawing, of each part in the bill of materials. Among them, the mechanical drawing of each part can be obtained from a 3D product modeling system such as a PLM system.

In this step, the name of each part in the bill of materials can be used as an index to obtain the mechanical drawing of each part in the bill of materials.

Step 804: Establish multiple candidate pairings based on the obtained mechanical drawings, each candidate pairing consisting of mechanical drawings of two parts.

During specific implementation, in the case where there is no matching relationship between the names of various parts in the bill of materials, in this step, multiple candidate pairs can be obtained by combining them based on the obtained mechanical drawings. At this time, there will be both compliant candidate pairs and non-compliant candidate pairs among the multiple candidate pairs obtained. Alternatively, in this step, based on the obtained mechanical drawings, the mechanical drawings of every two parts that have an assembly relationship can also be combined to obtain multiple candidate pairs. At this time, the multiple candidate pairs obtained are all compliant candidate pairs.

For the case where the names of each part in the bill of materials are matched according to the principle of assembly relationship between the two corresponding parts, in this step, based on the obtained mechanical drawing, each name can be matched with the two corresponding parts. The mechanical drawings of the parts are combined to obtain multiple candidate pairs. At this time, the multiple candidate pairs obtained are all compliant candidate pairs.

Step 805: Match each candidate pairing in the plurality of candidate pairings with each compliant pairing in the pre-established compliant pairing library in turn, and use the candidate pairing that matches the compliant pairing as the target candidate pairing. Wherein, when the similarity between the compliant pair and the candidate pair meets the set threshold, the compliant pair is the compliant pair matched by the candidate pair.

In this step, if there are both compliant candidate pairs and non-compliant candidate pairs in multiple candidate pairs, the non-compliant candidate pairs will not be able to match the compliant pair whose similarity meets the set threshold. In the case where multiple candidate pairs are all compliant candidate pairs, basically each candidate pair can be matched to a compliant pair whose similarity meets the set threshold.

In this step, during specific implementation, a variety of matching algorithms can be used, for example, the grid comparison algorithm or the boundary representation method (BREP) comparison algorithm can be used. The specific calculation can use artificial intelligence methods, such as the neural network (GNN).

Step 806: For each target candidate pair, append the assembly process information of the matched compliant pair to the target candidate pair.

Step 807: Construct a requirement behavior tree corresponding to the current assembly based on the assembly process information of all target candidate pairs according to the behavior tree grammar.

In this embodiment, during specific implementation, an assembly process list corresponding to the entire assembly process can be extracted based on the assembly process information of all target candidate pairs, and then based on the assembly process list, requirements corresponding to the entire assembly process are constructed according to the behavior tree syntax. Behavior tree.

Taking the exploded view of the assembly process shown in FIG. 2C as an example, FIG. 10 shows a schematic diagram of the compliance pairing involved in a sub-assembly process in FIG. 2C. As shown in Figure 10, for the sub-assembly process: component SA3 + part P5 = component SA4, which involves two compliance pairs, one is compliance pair 3 located on the left side of Figure 10, that is, the combination composed of parts P2 and parts P5 Compliance pairing, one is the compliance pairing 4 located on the right side of Figure 10, that is, the compliance pairing composed of part P4 and part P5. Among them, the compliant paired assembly process information on the left side of Figure 10 includes: the robot moves itself to part P5; the robot picks up part P5; and the robot coaxial part P5 and part P2. The compliant paired assembly process information on the right side of Figure 10 includes: the robot touches part P5 and part P4; the robot places part P5; and the robot moves itself to reset.

Based on the above assembly process information of compliance pairing 3 and compliance pairing 4, the assembly process list corresponding to this sub-assembly process can be extracted and obtained, including: A1: the robot moves itself to part P5; A2: the robot picks up part P5; A3: The coaxial parts P5 and P2 of the robot; A4: The robot touches the part P5 and the part P4; A5: The robot places the part P5; A6: The robot moves and resets itself.

Afterwards, based on the assembly process list, a requirement behavior tree corresponding to the sub-assembly process as shown in Figure 2E can be constructed according to the behavior tree syntax.

Of course, during specific implementation, the required behavior tree may also involve other behavior tree syntax, such as conditional nodes and other decorator nodes.

The requirement description data reuse method in the embodiment of the present invention has been described in detail above, and the requirement description data reuse device in the embodiment of the present invention will be described in detail below. The requirement description data reuse device in the embodiment of the present invention can be used to implement the requirement description data reuse method in the embodiment of the present invention. For details not disclosed in detail in the device embodiment of the present invention, please refer to the corresponding description in the method embodiment of the present invention.

Figure 11 is an exemplary structural diagram of a requirement description data reuse device in an embodiment of the present invention. As shown in Figure 11, the device may include: a first module 1101, a second module 1102 and a third module 1103.

Among them, the first module 1101 is used to construct a current demand behavior tree representing the current demand description based on a preset demand behavior tree construction grammar; the demand behavior tree includes: logical nodes representing execution logic and action nodes representing execution operations.

The second module 1102 is configured to perform a similarity comparison between the current demand behavior tree and multiple stored demand behavior trees during the process of constructing the current demand behavior tree or after the construction of the current demand behavior tree is completed. , find the established requirement behavior tree that has the largest common subtree with the current requirement behavior tree.

The third module 1103 is used to reuse the found relevant requirement description data of the established requirement behavior tree.

In fact, the requirement description data reuse device provided by this embodiment of the present application can be implemented in various ways. For example, the requirement description data reuse device can be compiled into a plug-in installed in a smart terminal by using an application programming interface that conforms to specific rules, or it can be packaged into an application program for users to download and use.

When compiled as a plug-in, the requirement description data reuse device can be implemented in a variety of plug-in forms, such as ocx, dll and cab. The requirement description data reuse device provided by this implementation of the present application can also be implemented by using specific technologies, such as Flash plug-in technology, RealPlayer plug-in technology, MMS plug-in technology, MIDI personnel plug-in technology or ActiveX plug-in technology.

The requirement description data reuse method provided by this implementation of the present application can be stored in various storage media in an instruction storage mode or an instruction set storage mode. These storage media include but are not limited to: floppy disk, optical disk, DVD, hard disk, flash memory, USB flash memory, CF card, SD card, SDHC card, MMC card, SM card, memory stick and xD card.

It should be clear that the operating system operating in the computer can not only implement the program code read by the computer from the storage medium, but also implement part or all of the actual operations by using instructions based on the program code to implement the above embodiments. function of any embodiment.

For example, FIG. 12 is an exemplary structural diagram of another requirement description data reuse device in an embodiment of the present application. The device can be used to perform the method shown in Figure 1, or to implement the device in Figure 11. As shown in Figure 12, the device may include at least one memory 1201 and at least one processor 1202. In addition, some other components can be included, such as communication ports, input/output controllers, network communication interfaces, etc. These components communicate via bus 1203 and so on.

At least one memory 1201 is used to store computer programs. In one example, the computer program can be understood as including various modules of the device shown in Figure 11. In addition, at least one memory 1201 may store an operating system and the like. Operating systems include but are not limited to: Android operating system, Symbian operating system, windows operating system, Linux operating system, etc.

At least one processor 1202 is configured to call a computer program stored in at least one memory 1201 to execute the requirements description data reuse method described in the examples of this application. The processor 1202 can be a CPU, a processing unit/module, an ASIC, a logic module or a programmable gate array, etc., and it can receive and send data through a communication port.

The input/output controller has a display and an input device for inputting, outputting and displaying relevant data as a human-computer interaction module.

It will be understood that as used herein, "and/or" is intended to include any and all possible combinations of one or more of the associated listed items.

The number of embodiments in this application is for description only and does not represent the advantages of the embodiments.

The above are only preferred embodiments of the present application and are not intended to limit the present application. Any modifications, equivalent substitutions, improvements, etc. made within the spirit and principles of the present application shall be included in the present application. within the scope of protection.

Claims (10)

1. A method for reusing requirement description data, which is characterized by including:

   Based on the preset demand behavior tree construction grammar, the current demand behavior tree representing the current demand description is constructed; the demand behavior tree includes: logical nodes representing execution logic and action nodes representing execution operations;

   In the process of constructing the current demand behavior tree or after the construction of the current demand behavior tree is completed, the similarity between the current demand behavior tree and multiple stored demand behavior trees is compared to find the similarity with the current demand behavior tree. The demand behavior tree has a built demand behavior tree with the largest common subtree, so as to reuse the relevant demand description data of the found built demand behavior tree.
2. The demand description data reuse method according to claim 1, characterized in that, in the process of constructing the current demand behavior tree or after the construction of the current demand behavior tree is completed, the current demand behavior tree is compared with the existing demand behavior tree. The similarity comparison of multiple stored demand behavior trees is as follows: in the process of constructing the current demand behavior tree, similarity comparison between the current demand behavior tree and multiple stored demand behavior trees is performed. Compare;

   The requirement description data is the requirement behavior tree itself;

   The reuse of the relevant demand description data of the found demand behavior tree is to recommend the found demand behavior tree as a candidate demand behavior tree to help complete the construction of the current demand behavior tree.
3. The demand description data reuse method according to claim 1, characterized in that, in the process of constructing the current demand behavior tree or after the construction of the current demand behavior tree is completed, the current demand behavior tree is compared with the existing demand behavior tree. Comparing the similarity of multiple stored demand behavior trees is: after completing the construction of the current demand behavior tree, performing a similarity comparison between the current demand behavior tree and the multiple stored demand behavior trees;

   The demand description data is the workflow data corresponding to the demand behavior tree;

   The reuse of the relevant demand description data of the found demand behavior tree is: obtaining the sub-workflow data corresponding to the largest common subtree from the workflow data corresponding to the found demand behavior tree; The sub-workflow data is reused in the workflow data corresponding to the current demand behavior tree.
4. The demand description data reuse method according to any one of claims 1 to 3, characterized in that the similarity comparison between the current demand behavior tree and a plurality of stored demand behavior trees is performed, and the search and the The current demand behavior tree has an established demand behavior tree with the largest common subtree, including:

   Convert the current demand behavior tree into a graph format to obtain a current demand graph;

   Compare the similarity between the current demand map and each built demand map converted from each built demand behavior tree, and search for the built demand map that has the largest common submap with the current demand map;

   Use the built demand behavior tree corresponding to the found built demand map as the built demand behavior tree that has the largest common subtree with the current demand behavior tree;

   Wherein, the demand map includes: map nodes representing each node in the corresponding demand behavior tree, and directional connections connecting each map node.
5. The demand description data reuse method according to claim 4, characterized in that, in the demand behavior tree, the action nodes are expressed according to a set semantic format, and the set semantic format can be split into multiple semantic fields;

   In the requirements graph, the action node is converted into an action node graph, which includes: an action graph node that refers to the action node, a field graph node that refers to each semantic field of the action node, and a node connected to the action node. Describe the directional connections between action graph nodes and each field graph node.
6. The demand description data reuse method according to claim 4, characterized in that the logical node includes a condition node; in the demand behavior tree, the condition node is expressed according to the set semantic format, and the Set semantic format can be split into multiple semantic fields;

   In the requirement map, the condition node is converted into a condition node graph, which includes: a condition graph node that refers to the condition node, a field graph node that refers to each semantic field of the condition node, and a node connected to the condition node. Directed connections between the condition map node and each field map node.
7. The demand description data reuse method according to claim 5 or 6, characterized in that the set semantic format is: subject, predicate, object, context; and the set semantic format can be split into a subject field, Predicate field, object field, context field;

   The context is optional.
8. The demand description data reuse method according to claim 6, wherein comparing the current demand map with each built demand map obtained by converting each built demand behavior tree includes:

   Each action node map and each condition node map in the demand map are compared as a whole. When there is a complete action node map or a complete condition node map in the current demand map in the established demand map, The action node graph or the condition node graph in the current demand graph is determined to exist in the built demand graph.
9. A requirement description data reuse device, characterized by including at least one memory (1201) and at least one processor (1202), wherein:

   The at least one memory (1201) is used to store computer programs;

   The at least one processor (1202) is configured to call a computer program stored in the at least one memory (1201) to execute the requirement description data reuse method according to any one of claims 1 to 8.
10. A computer-readable storage medium on which a computer program is stored; characterized in that the computer program can be executed by a processor and implement the requirement description data reuse method as claimed in any one of claims 1 to 8.

Images