JPH06168107A - Plan knowledge generation supporting device - Google Patents

Abstract

PURPOSE:To automatically generate an operation knowledge required for plan generation from models of actions which respective entities of a controlled system can take. CONSTITUTION:This device is provided with a storage means 11 where entity models MDL where actions of respective entities belonging to a controlled system world are described by various operators OP, where operation contents are defined, are held, an analysis means 12 which analyzes these models to check overs and shorts by mutual reference relations and requests supplement of deficient conditions, an input means 16 which supplements and inputs conditions, a candidate generating means 13 which adds the state change of each entity, the action causing the change, and dependence relations between entities obtained from the check result of the analysis means 12 to the pertinent OP as correction information based on supplemented condition information to generate an OP knowledge prototype, and a correcting means 14 which adds constraints to pertinent positions of the OP knowledge prototype obtained by the candidate generating means 13.

Description

Detailed Description of the Invention

[0001]

BACKGROUND OF THE INVENTION 1. Field of the Invention The present invention relates to a system for generating a plan for synthesizing a plan in which an action for transitioning from an initial state to a target state is synthesized, and in particular, it is possible to generate the underlying knowledge. A planning knowledge creation support device that can be used

[0002]

2. Description of the Related Art A plan generation system synthesizes a program source representing an action for making a transition from an initial state to a target state, and its knowledge representation form is the action or operation of an actor who carries out a plan. The unit operator format is standard. This operator is basically given by a set of a precondition, a resulting deletion condition, and an additional condition, and each condition is composed of a state description and an attribute of an entity in the target world.

Conventionally, as a method of obtaining such an operator from the target world as a problem (issue), an operator who gives a complete state transition of the target world and compares the differences between respective states to fill the difference is found. There is a method in which a plan itself composed of a plurality of basic operators is regarded as one operator by a method of generating it or by fusion with a learning system.

[0004]

As a method for obtaining an operator from the target world in question, there are the above-mentioned ones. However, many of the problems targeted by such conventional methods are small, and Since the modeling of the target world is easy, the operator could be easily derived only by analyzing the state transitions.

However, when the problem becomes complicated, it is not enough to analyze the state transition of each entity, and in order to consider the change of the state of each entity, the expression of operator knowledge in consideration of the inter-entity dependency is considered. Is required. Also, when the generated plan itself is used as an operator, a basic operator is required as a prerequisite.

The state transition of each entity is completed by incorporating the necessary basic operators in the entity model. However, each entity model cannot complete its operation independently, and other entity models cannot be completed. There is a entanglement with. For this reason, in a large-scale and complicated target world, these entanglements are mixed up, and in order to complete software that can perform the intended operation without waste, the operator of the physical model duplicates the entanglement with the operators of other physical models. It is necessary to remove the required description, define the missing description, add the order, etc., but the work is complicated, but the overall visibility deteriorates, and eventually the operation is verified one by one. However, it is necessary to verify and correct the operation of the whole system, which requires manpower and a huge amount of time, and productivity is poor. Moreover, the more complicated the work is, the more reliable it becomes, and the less reliable it is.

Therefore, the object of the present invention is to
It is used to plan the action for transitioning the controlled object from the initial state to the target state, and describes various operators in units of actions and operations of the object that carries out the plan in operator format. From each physical model prepared for each, analyze the excess or deficiency of conditions in the above various operators based on the reference relationship between each physical model and make necessary corrections to realize a large-scale and complex target controlled world It is to provide a software knowledge creation support device capable of converting into necessary contents.

[0008]

In order to achieve the above object, the present invention is constructed as follows. That is, the behavior of each entity that belongs to the controlled world is modeled as an entity model that is described by various operators that define the operation content, and the model storage means is stored, and each of these entity models is analyzed. Then, while checking the excess and deficiency by mutual reference relationship, analysis means for requesting supplementation of insufficient conditions, input means for supplementary input of conditions, and extracting each operator from the above-mentioned physical model, and investigating analysis means Candidate generation that creates operator knowledge prototype by adding state change of each entity obtained from the result, action that causes change, dependency relationship between entities as correction information to the relevant operator based on supplemented condition information And means for modifying the operator knowledge prototype obtained by the candidate generating means to add a constraint condition to the relevant part.

[0009]

In this configuration, the model storage means stores the behavior of each entity belonging to the target controlled world as a model of entity described by various operators. The analysis means analyzes each of these entity models and investigates the excess or deficiency based on the mutual reference relationship. Then, the candidate generating means extracts each operator from the entity model, and as the modification information based on the state change of each entity obtained from the analysis result of the analyzing means, the action causing the change, and the dependency relationship between the entities. Create an operator knowledge prototype by adding it to the corresponding operator. The correction means adds a constraint condition to the corresponding portion of the operator knowledge prototype obtained by the candidate generation means.

In the knowledge generation device of the present invention, the modeling of the target world is given by formalizing the entities forming the target world, and the contents are the entity name, the internal state definition of the entity, and the action that causes the state transition. It consists of definitions and attribute definitions that characterize the entity. When these are given, this device analyzes the conditions of each action in consideration of the reference relations (query relations and dependency relations) of the conditions of each entity model, and extracts overlapping conditions and unnecessary conditions due to the reference relations. ,
Moreover, in order to prompt the setting of insufficient conditions and to make corrections based on these, the description of condition capture is added.

As described above, the present apparatus analyzes the reference relation of the conditions of each physical model, analyzes the necessity of condition correction of each action from the condition reference relation, and the result is the action name, precondition, deletion condition, It is converted into plan generation knowledge consisting of additional conditions, sorts, constraints, etc. Then, by adding processing corresponding to these deletion condition, addition condition, sort, and constraint condition, knowledge (operator knowledge) necessary for generating a plan can be obtained.

Therefore, according to the present invention, if a behavior represented by each entity is modeled and expressed for a large-scale and complicated controlled object,
A plan knowledge creation support device capable of automatically creating operator knowledge necessary for plan creation can be provided.

[0013]

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS An embodiment of the present invention will be described below with reference to the drawings. FIG. 1 is a block diagram showing a functional configuration of a planning knowledge creation support device of the present invention capable of creating planning knowledge.

As shown in the figure, this apparatus uses a substance model storage unit 11 for storing a formalized substance model, and a condition reference relationship between the substance models from the substance model stored in the substance model storage unit 11. Parses the missing condition, picks up the missing condition, informs the user (programmer) to add the missing condition, and if the user inputs the definition of the missing condition, capture it and use it for analysis. In addition, when it is necessary to newly add the condition, additional description is added to the operator knowledge description as an additional condition, and unnecessary condition is deleted from the operator knowledge description in addition to the necessary condition addition processing. Substantial model analysis unit 12 that performs processing such as deleting unnecessary actions, estimates operator candidates from the selected substantive model, and substantiates the substantive model and operator knowledge. An operator candidate generation unit 13 that converts and outputs a prototype of operator knowledge by reflecting the processing result of the substance model analysis unit 12 from the substance model description according to the correspondence relationship between each item, and a constraint condition acquisition unit 14 that obtains a constraint condition An operator knowledge storage unit 15 for storing operator knowledge, and a man-machine interface for a user to input a command to the system, data, and the like. The above 12, 13, and 14 are functions of the control device 10, and are realized by software, for example.

In the entity model storage unit 11, knowledge information about each entity model that represents the entity of each object appearing in the controlled world defined by the user is represented by the entity name, the state definition that the entity model can take, It is stored in a descriptive format composed of action definitions that cause state transitions and attribute definitions that characterize the entity model.

Of these, the state definition is a description consisting of a domain of "state name # state". In addition, the action definition is "action name #" and "preconditions" for that action.
, And the “result” pair. The "preconditions" and "results" consist of descriptions of "state of substance" and "attributes".
Proper nouns with the symbol "#" are function names (operator names)
Is shown, and the definition contents are shown in "[]".

FIG. 5 shows an example in which a physical model of the robot in the action planning problem of the robot is described as the controlled world. In this example, there is a room A and a room B adjacent to it, there is a door between the rooms, and the robot moves the box in one room to the other room. This figure shows an example of the actual model description of a plan. In FIG. 5, the “type” of the robot is a robot, and the “state” includes “room” and “place”.

The range in which the robot can move is within a "room," which is a room 1 and a room 2 adjacent to it.
It is a structure called. Therefore, the definition content of the function name "Room #" that defines the range of rooms in the state definition is [Room 1,
Room 2], and the "location" that represents the robot position is the position of the door, the position where the box is placed, and the position where there is neither the door nor the box 3.
Since there is a state, the "place" covers three states: door, box, and none. Therefore, the definition content of the function name "location #" that defines the location in the state definition is [door,
Box, none].

There are the following four actions taken by the robot. That is, there are four: "being in the room", "moving the room", "approaching the door", and "approaching the box". Therefore, it is necessary to define a description of each of these actions. This is an action definition, and an operator is a module that gives each definition content a name and realizes this definition content.

A description example will be described in more detail. For example, if the room where the robot is is room X, the robot is near the door, the door connects room X and room Y, and if the door is open is a prerequisite. The behavior of the robot "moving a room" is based on the above-mentioned prerequisites, when the room in which the robot is located is room X [description example "(room (robot, room X))"] and the robot is near the door. [Description example “(place (robot, door))”], the door connects the room X and the room Y [Description example “structure (door, room X, room Y)”],
The door is open [Description example "Inquiry (door,
(Door (open)) ”], and according to this precondition, the description of the precondition for“ moving a room ”is [room (robot, room X) & place as shown in FIG. (Robot, door) & structure (door, room X, room Y) &
Inquiry (door, door (open))]. Here, “&” indicates an AND condition.

In the "result" portion, since the object of the action is the movement of the robot room, the robot moves to another room [description example "(room (robot, room Y)"].
It will be said that. Here, the room X and the room Y are variables, and the domain thereof is the same as the state variable "room" of the robot body model.

In this form, three kinds of actions of "being in a room", "approaching a door", and "approaching a box" are also defined and described. Each of the thus defined actions is "room". "I'm here", "Close to the door", "Close to the box"
It becomes each operator that realizes the action.

The physical model is used to describe various desired behaviors and states of the target world, prerequisites, etc., for example, in the case of a robot as described above, one behavior of the robot, for example, “I ’m close to the door” and…
As described above, for each object called a robot, the inside is configured by describing the actions to be performed with a minimum state as a unit, and prepared in advance as an actual model of the robot. is there. In the above-mentioned example, since the physical model includes a box in addition to the robot, a physical model related to the box is prepared separately.

The actions to be performed are described in operator form, but undefined operators are defined and prepared. Then, for basic operators and general-purpose operators, a library defining them is prepared, and if the operator name is described using this library, the definition contents can be referred to.

According to the present invention, after preparing the physical models describing the individual operation contents and the prerequisites regarding the behavior of the physical object as described above for the physical object, the unnecessary description is generated due to the entanglement between the physical models. It enables automatic processing of adjustments such as descriptions that must be added, matters that must be defined, and order relations.

The entity model analysis unit 12 performs processing such as correction of the condition portion of each action and deletion of unnecessary action by classifying the reference relation of the condition portion of the action definition in each entity model as described above. Is.

The operator candidate generation unit 13 creates a prototype of operator knowledge from the above described entity model description while following the correspondence relationship between each item of entity model and operator knowledge as shown in FIG. At this time, the operator candidate generation unit 13 also incorporates the result processed by the entity model analysis unit 12 into the corresponding operator candidate and incorporates it into the prototype of operator knowledge.

The constraint condition acquisition unit 14 acquires constraint conditions between objects to which each operator knowledge is applied, with respect to this prototype of operator knowledge, and presents the user with items to be constraint conditions. Then, it prompts the setting of conditions, takes in the set constraints and adds them to the real model. The constraint conditions are set by the user. The constraint condition describes the relationship between sorts. That is, the constraint condition acquisition unit 14
Examines the sort description of the operator knowledge prototype and outputs it to the man-machine interface 16 to let the user identify whether the objects of the same type are the same or different,
The result is added as a constraint description in the description of the entity model. Furthermore, when attributes are included in the sort, the description of the constraint for each attribute is output to the man-machine interface 16 and presented to the user. Then, the user is made to input the description of the constraint, and it is taken in. The operator knowledge storage unit 15 stores the operator knowledge thus obtained. Next, the operation of the present apparatus configured as described above will be described.

Each entity model of each entity appearing in the world to be controlled is prepared in the entity model storage unit 11. The physical model analysis unit 12 reads the physical model prepared in the physical model storage unit 11, analyzes the physical model, and performs correction processing and the like.

The substantive model analysis unit 12 analyzes the reference relationship of conditions between substantive models from the substantive models stored in the substantive model storage unit 11 by performing the processing according to the flowcharts shown in FIGS. 3 and 4. Then, from the analysis result, a description of a function for adding a condition or deleting an unnecessary action is added. The reference relationship has two types of reference types, "inquiry type" and "request type", and the syntax is "reference type (reference entity, condition)". Here, FIG. 3 is a processing procedure for “request type”, and FIG. 4 is a processing procedure for “inquiry type”.

That is, the entity model analysis unit 12 first analyzes the reference relation of the conditions of each action definition in the entity model, and corrects the condition part in the action of each entity model from the reference relation.

The reference relationship has two types of reference types, "inquiry type" and "request type", and the syntax thereof is "reference type (reference entity, condition)".
The reference relation is checked, and if there is a reference relation, a process for deleting and adding an action is added according to which type of reference relation.

For that purpose, it is checked whether or not there is a request type condition AP, that is, "request (request destination substance RE, request condition RC)" in a certain target entity model EM1 (S1), and request type Request condition A if there is a condition AP
The action A1 including P in the result is extracted (S2), and it is checked whether or not the action A2 in the other entity model RE that is the request destination includes the request condition RC in the result (S3). A process for deleting the request type condition is performed (S4), the precondition of the action A2 is added to the precondition of the action A1, and the process of adding the result of the action A2 to the result of the action A1 is performed (S5). , Another processing for changing the substance model definition referring to the result of the action A2 and returning to step S1 is performed.

If it is determined in step S1 that there is no request-type condition, the presence or absence of an inquiry condition is checked (S21), and if there is no inquiry condition, the analysis and correction of the substance model ends.

In step S21, if the entity model has an inquiry type condition, the inquiry type condition QP, that is, "inquiry (inquiry destination entity Q
E, inquiry condition QC) "(S22), Q
It is checked whether or not C belongs to the content of the state definition of another entity model QE (S23). If it does not belong, it is further checked whether or not the inquiry condition QC belongs to the result of the action definition of the entity model EM (S24). ).

If it does not belong, the process returns to step S21. If it belongs, the entity model QE is edited and then the process returns to step S21 (S25). If it belongs in step S23, the entity model QE is edited. It returns to step S21 (S25). In this way, the correction process of the condition part in the action of each entity model is performed from the reference relationship.

Here, the above-mentioned "query type" refers to referencing the internal state of the subject physical model. "Inquiry type" appears in the precondition of each action,
This type of condition does not change the internal state of the entity model being manipulated.

For example, in the case of the robot body model in FIG. 2, the condition "door (open)" in the "move room" action is an inquiry type condition for "door". On the other hand, “request type” is a condition that requires a change in the internal state of the target physical model.
The request-type condition appears in both “preconditions of action” and “result”.

For example, in the case of the robot entity model (entity name robot) in FIG. 5, the definition of the box entity model for the action of "approaching the box" is "(request (box, place (robot, box X)))". And the action of "approaching the box" is a request type condition for this box entity model,
As a result of this condition, the internal state of the box changes from any state to a state adjacent to the robot.

Therefore, since the definition must correspond to the change, the action is deleted and added according to the condition.
For example, for the request type condition AP of the entity model EM1, that is, for the action A1 including “request (requestee entity EM2, requestee condition RC)” in the result, the request condition RC is set in the entity model EM2 that is the requestee. Action A2 included in the result
Is included in behavior A1.

That is, the "request condition RC" is "action A2".
If it belongs to the result “of the result A”, the action A2 is deleted in the entity model analysis unit 12, and each condition of the action A2 is the action A.
1 is added to each condition. Then, all other entity models that refer to the request-type condition AP of the entity model EM2 are modified so that the reference destination is changed to the entity model EM1.

For example, in the robot body model of FIG. 2, a request type condition of "place (robot, box X)" of the action "approaching a box" causes similar results, "box is adjacent to robot". If there is a description of the "do" action, this action will overlap with the "close to the box" action and must be deleted. Therefore, in this case, the description about the behavior of "box is adjacent to robot" in the box body model is deleted. Such processing is performed for all request-type conditions by executing the procedure according to the flowchart of FIG.

Next, the processing of the inquiry type condition will be described with reference to FIG. First, the inquiry type condition QP, that is,
It is checked that "inquiry (inquiry entity QE, inquiry condition QC)" is defined as a result of the action of another entity model. If there is no behavioral description that produces such a result, the user is prompted to input that there is no such result in the target entity model, and input is prompted.

Further, when the state description related to QC is not in the state definition of the target physical model, the user is caused to newly create a state definition corresponding to it, and the physical model analysis unit 12
To give to. The description of the newly created state definition for such a target physical model may be given to the physical model analysis unit 12 by causing a user to perform an input operation via a man-machine interface 16 (not shown). The description of the newly created state definition for the target physical model is also stored in the physical model storage unit 11. As a result, a complete description of the substance model is obtained. Next, this entity model description is converted into an operator knowledge format. This conversion process is performed by the operator candidate generation unit 13.

This conversion process basically follows a correspondence table as shown in FIG. However, the "preconditions" and "results" are the operator's "precondi
Corresponds to the "action" and "and" parts, but the "delete" part is compared with the "precondition" and the "result", and the condition of the changed part is defined as "delete".

The changed part has the same condition name as the condition appearing in the "result" and the condition appearing in the "precondition". In addition, a part of the sort and the constraint condition are performed after the conversion is completed. The constraint description describes the relationship between sorts. In this way, the operator candidate generation unit 13 obtains the prototype of each operator knowledge, and the constraint condition acquisition unit 14 determines the constraint condition between the objects to which each operator knowledge is applied with respect to this prototype of operator knowledge. Make an acquisition.

That is, when the prototype of each operator knowledge is obtained in this apparatus, the constraint condition acquisition unit 14 checks the sort description of the operator knowledge prototype, and makes the user distinguish whether the objects of the same type are the same or different. , Add the result to the constraint description. Further, when attributes are included in the sort, the description of constraints for each attribute is presented to the user. Then, the user is made to input the description of the constraint, and it is taken in.

In the sort description part, the constraint condition acquisition part 14 asks the user for the specific content of the object whose third argument of the type declaration is "undefined", and changes the content according to the instruction from the user. To do.

From the above results, the operator knowledge necessary in the target world can be obtained. The obtained operator knowledge is stored in the operator knowledge storage unit 15 and used for later use.

FIG. 6 is a description example of the operator "approaching the door" obtained from the robot body model of FIG. opna
me # is an identifier that indicates the operator name, and precondition
# Is an identifier indicating a precondition, delete # is an identifier indicating a delete condition, add # is an identifier indicating an addition condition, sort # is an identifier indicating a sort (type of state variable) condition, and That's how it was said. The definition content is described in [] following each identifier.

The contents of the operator described in such a form are de, if the preconditions are satisfied in the current state.
This is a condition indication that the content equivalent defined in lete # is deleted from the current state and the content equivalent defined in add # is added to that state. However,
The type of state variable appearing in these three condition definition parts must match the one defined in sort #.

The operator described in this way is
By giving an editing system having a command system that executes condition instructions and performing edit processing, the condition instruction part for deletion is deleted, and the additional instruction part is added, and the operator who has changed to an operator who is just enough for the purpose is changed. It will be the actual model used.

That is, the entity model is changed according to the described condition instruction, and the definition content of the operator is based on the state variable type defined by sort #,
The definition equivalent to delete # is deleted and add
A part corresponding to the definition content with # is added. And
It becomes the entity model of the optimized definition contents.

By using such an entity model, a basic operator for planning the flow of the action of the controlled object is created, and thereafter, by combining this basic operator, the optimum operator satisfying the given purpose can be obtained. You will be able to get a plan.

As described above, according to the present system, it is used to plan an action for transitioning the controlled object from the initial state to the target state, and the action or operation of the object performing the plan is used as a unit. Various operators are described in operator format, and from each physical model prepared for each target,
Make necessary corrections by analyzing the excess or deficiency of conditions in the above various operators based on the reference relationship between each entity model,
It becomes possible to convert to the optimum content necessary for realizing a large-scale and complex purpose controlled world. In addition,
The present invention is not limited to the embodiments described above and shown in the drawings, but can be appropriately modified and carried out within the scope of the invention.

[0056]

As described above in detail, according to the present invention,
Optimized operator knowledge for generating a plan can be automatically generated from the physical model of the world that is the target of the plan generation, and it is possible to handle even when targeting a large-scale, complicated controlled world. It is possible to provide a plan knowledge creation support device.

[Brief description of drawings]

FIG. 1 is a block diagram for explaining a functional configuration of a planning knowledge creation support device of the present invention.

FIG. 2 is a diagram showing a correspondence relationship between each item of a physical model and operator knowledge.

FIG. 3 is a flowchart showing a flow of processing for analyzing a substance model and obtaining a detailed description of the substance model by the present system.

FIG. 4 is a flowchart showing the flow of processing for analyzing a substantial model and obtaining a detailed description of the substantial model according to the present system.

FIG. 5 is a diagram showing a description example of a physical model that is an input to the present apparatus.

FIG. 6 is a diagram showing a description example of operator knowledge that is an output of this system.

[Explanation of symbols]

11 ... Entity model storage unit, 12 ... Entity model analysis unit 1
2, 13 ... Operator candidate generation unit, 14 ... Constraint condition acquisition unit, 15 ... Operator knowledge storage unit, 16 ... Man-machine interface.

Claims (1)

[Claims] 1. Model storage means for modeling and holding the behavior of each entity belonging to the controlled world as an entity model described by various operators that define the operation content, and each of these entities. Analyzing the model, investigating excess and deficiency by mutual reference relation, analyzing means for requesting supplementation of insufficient condition, input means for supplementary input of condition, extracting each operator from the above-mentioned physical model, and analyzing Create the operator knowledge prototype by adding the state change of each entity obtained from the survey result of the means, the action that causes the change, and the dependency relationship between the entities as correction information to the corresponding operator based on the supplemented condition information Candidate generating means for modifying the operator knowledge prototype and modifying means for adding a constraint condition to the relevant part of the operator knowledge prototype obtained by the candidate generating means. Planning knowledge creation support apparatus, characterized in that.