JP2009015493A - Action execution device and method - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To provide an event management device and method, for efficiently recognizing the intention of a user. <P>SOLUTION: This action execution device has: an event acquisition part acquiring an event; a belief DB 501 storing a confirmable fact and a non-confirmable fact; a normal-interrupt plan preparation part 508 preparing a plan according to the acquired event; a normal-interrupt action execution part 40 executing an action by use of the confirmable fact and the non-confirmable fact in each the prepared plan; and an action history DB 505 storing executed action information as a history. When the event acquisition part acquires an interrupt event requiring confirmation of the action, the normal-interrupt plan preparation part prepares an interrupt plan confirming, to the user, whether the confirmable fact used in the action information stored in the action history DB is proper or not, and the normal-interrupt action execution part executes the action according to the prepared interrupt plan, and updates the confirmable fact according to an execution result thereof. <P>COPYRIGHT: (C)2009,JPO&INPIT

Description

  The present invention relates to an action execution apparatus and method.

  2. Description of the Related Art Conventionally, with improvement of voice detection technology, various devices that perform processing triggered by interaction with a user have been proposed. In such a device, a user can recognize an instruction to the device by performing a process of recognizing a voice uttered by the user. Then, after recognizing the instruction from the user, the apparatus prompts the next instruction by voice output or presents the processing contents. In this way, a voice conversation plan is performed between the user and the device. However, since the speech recognition rate is not 100%, erroneous recognition occurs in the dialogue plan.

  When erroneous recognition occurs in the dialogue plan of such an apparatus, it is difficult to identify the location where the erroneous recognition has occurred and to correct the erroneous recognition location.

  For example, in the technique described in Patent Document 1, after a dialogue between the device and the user, if it is determined that the device is recognized incorrectly, a voice command is confirmed for each input or a voice command is started from the beginning. After determining whether to input, the error is corrected by performing any of the processes. In this way, efforts are made to reduce the labor required to correct a misrecognition.

JP 2004-271909 A

  However, when a device performs processing, it often performs processing using information stored in the device as well as instructions input by the user. When the technique described in Patent Document 1 is applied, all the information stored in the device is also confirmed with the user, and there is a problem that the burden of confirmation for the user increases.

  The present invention has been made in view of the above, and an object of the present invention is to provide an event management apparatus and method that can efficiently recognize a user's intention.

  In order to solve the above-described problems and achieve the object, the action execution device according to the present invention performs processing as intended by the user, and a normal target storage unit that stores normal target information indicating a user's request. Situation for storing variable status information indicating status information that can be changed according to a user's response to not being performed, and invariant status information indicating status information that is not changed according to the user's response Create a normal plan that indicates the execution order of normal actions that perform processing using one or more of the variable status information and the invariant status information, which are actions corresponding to the information storage unit and the normal target information A normal plan creation unit that executes the normal action according to the execution order for each created normal plan, and the normal action executed An action history storage unit that stores a history of actions, an action information storage unit that stores, for each of the normal actions, action correspondence information that associates the variable status information that the normal action uses at the time of execution, and the action history For each normal action stored in the storage unit, the variable situation information associated with the normal action is extracted from the action correspondence information storage unit, and whether the extracted variable situation information is appropriate is checked Used by an interrupt plan creation unit for creating a confirmation request action for requesting a user, a confirmation request action execution unit for interrupting and executing the confirmation request action in the normal action, and the confirmation request action executed When information indicating that the variable status information is not appropriate is input from a person Stored in the information storage unit, characterized by comprising a an update unit that updates the variable status information is to be confirmed the confirmation request action.

  The action execution method according to the present invention includes a normal target storage step for storing normal target information indicating a user's request in the normal target storage unit, and usage for processing not being performed as intended by the user. Status information storage that stores variable status information indicating status information that can be changed according to a user's reaction and invariant status information indicating status information that is not changed according to the user's response in a status information storage unit A normal plan for creating a normal plan indicating an execution order of normal actions for performing processing using any one or more of the variable status information and the invariant status information, which is an action corresponding to the step and the normal target information A plan creation step; a normal action execution step for executing the normal action in accordance with the execution order for each of the created normal plans; An action history storage step of storing the history of the normal action in an action history storage unit, and an action information storage unit that associates the variable situation information used at the time of execution of the normal action for each normal action by the action information storage unit For each of the normal actions stored in the action history storage unit, the variable situation information associated with the normal action is extracted from the action correspondence information storage unit and extracted. An interrupt plan creation step for creating a confirmation request action for requesting the user to confirm whether or not the variable status information is appropriate, and a confirmation request action execution for interrupting and executing the confirmation request action in the normal action Step and said confirmation request action performed When the information indicating that the variable status information is not appropriate is input from the user, the update for updating the variable status information that is stored in the status information storage unit and is the confirmation target of the confirmation request action And a step.

  According to the present invention, the user's intention can be efficiently recognized by creating a plan for confirming to the user whether or not the variable status information corresponding to the executed action is appropriate according to the normal target information. There is an effect that is possible.

  Embodiments of an action execution apparatus and method according to the present invention will be described below in detail with reference to the drawings. Note that the present invention is not limited to the embodiments. Hereinafter, an example in which the action execution apparatus is applied to a part of the plan execution system will be described.

(First embodiment)
The plan execution system 1 according to the first embodiment creates a plan through interaction with a user, and manages the execution of the created plan. As shown in FIG. 1, the plan execution system 1 includes an external environment monitoring unit 10, an event handling unit 20, a planning agent 30, and a normal / interrupt action execution unit 40. The external monitoring unit 10, the event handling unit 20, and the planning agent 30 are stored in one apparatus in the present embodiment. In addition, it does not limit to storing in one apparatus in this way, You may mount on the some computer couple | bonded by the internet etc.

  The external environment monitoring unit 10 monitors the external environment. Specifically, information obtained from outside the outside monitoring unit 10 is monitored as the outside environment. Furthermore, the external environment monitoring unit 10 refers to information recorded in the external environment monitoring unit 10 itself. When the monitoring result satisfies a predetermined condition, an event is issued. Then, this event is notified to the event handling unit 20. Here, the event is information indicating that the monitoring result satisfies a predetermined condition.

  The external monitoring unit 10 also acquires a notification instruction from the event handling unit 20. The notification instruction is an instruction regarding event issuance in the external monitoring unit 10. For example, when a voice emitted from the user is detected and a predetermined voice command is detected from the user, it is determined that the condition is satisfied, and the event corresponding unit 20 is notified of the event. In addition to this, the notification instruction includes information such as on / off of the external monitoring unit 10, the type of necessary event, the condition for event issuance, and the frequency of event issuance.

  Note that examples of information obtained from the outside by the external monitoring unit 10 include audio information obtained from a microphone and image information obtained from a camera.

  The information recorded inside includes voice information necessary for voice recognition, command information necessary for voice command recognition, and the like.

  The event handling unit 20 specifies the processing content to be performed next based on the external event acquired from the external monitoring unit 10. Here, the processing contents include transmission of a notification instruction to the external monitoring unit 10, input of a goal to the planning agent 30 described later, and update of the belief DB 501 of the planning agent 30.

  Here, the belief is information indicating the current situation regarding the planning agent 30. The goal indicates a task desired to be completed or a state desired to be achieved.

  Further, the event handling unit 20 acquires an internal event indicating what execution state the plan execution by the planning agent 30 is in from the planning agent 30. In this case, the event handling unit 20 specifies the processing content based on the internal event.

  The planning agent 30 creates a plan group including a plurality of actions based on the goal input from the event handling unit 20. As shown in FIG. 2, it is assumed that the goal is achieved by executing one or more plans. Each plan holds the execution order of actions that are one or more processes for achieving the goal. That is, it is created according to the goal. The planning agent 30 notifies the normal / interrupt action execution unit 40 of an action execution instruction included in the plan. The planning agent 30 also receives the execution result of the action from the normal / interrupt action execution unit 40 and manages the execution of the action according to the execution result. Also, an internal event corresponding to the action execution state is notified to the event handling unit 20.

  The normal / interrupt action execution unit 40 executes or interrupts the action according to an instruction from the planning agent 30. Then, the execution result (success / failure / interruption) is notified to the planning agent 30. The action includes a normal action and an interrupt action. These actions will be described later.

  As shown in FIG. 3, the event handling unit 20 includes an event rule DB 301, an external event acquisition unit 302, an internal event acquisition unit 304, a condition determination unit 305, a processing content extraction unit 306, and a notification unit 307. Have. The external event acquisition unit 302 acquires an external event notified from the external world monitoring unit 10. The internal event acquisition unit 304 acquires an internal event from the planning agent 30. Specifically, the internal event includes a start event indicating the start of action execution and an end event indicating the end of action execution.

  The event rule DB 301 stores event rules. In the event rule, an event, an execution condition, and a processing content are associated with each other. Here, specifically, event identification information for identifying an external event issued by the external monitoring unit 10 or an internal event issued by the planning agent 30 is stored as an event. The execution condition is information regarding the facts in the belief DB 501 held by the planning agent 30 described later. The fact is data indicating the status of processing performed in the plan execution system 1 or the status of the external environment.

  In addition, examples of event rules that associate external events with processing contents include “when a voice is input from a user, navigation for moving to the destination indicated by the voice” is started. Stored as a condition for processing the external event. As an example of an event rule in which an internal event is associated with a processing content, for example, “when the navigation is completed, reception of input of a destination by voice from a user is started” is available.

Specifically, event rules are:
event (E, [C1,... Cn], [R1,... Rm])
It has the shape of Here, E indicates event identification information. C1,... Cn are execution conditions. R1,... Rm are processing contents.

  In this event rule, when the event indicated by the event identification information E is notified, if all of these execution conditions C1,... Cn are satisfied (that is, the ignition condition is satisfied), the event rules from R1 to Rm in order. This means that event processing is performed by sequentially performing the processing.

  Here, each of R1,... Rm is an operation of any one of the external monitoring unit 10, the event handling unit 20, or the planning agent 30. Specifically, the belief DB 501 of the planning agent 30 is updated, the interrupt goal input to the planning agent 30, the normal goal input to the planning agent 30, the interrupt plan check instruction to the planning agent 30, and the switch of the external monitoring unit 10 ON (with event issuance condition), switch-off of external monitoring unit 10, event request (with request event condition), etc. Note that an interrupt goal is a goal that should be achieved preferentially by interrupting a normal action that is being executed in order to request confirmation of the executed normal action, in other words, equivalent to interrupt target information. To do. The normal goal is a goal indicating a user's request and is a goal to be processed according to the order acquired by the planning agent 30. In other words, it corresponds to normal target information.

  In the example of the event rule shown in FIG. 4, event identification information is set in the part described in the event rule code 401, the execution condition is set in the part described in the code 402, and the part described in the code 403 is set in the event rule. Processing contents (for example, an action to be executed) are set. Since the execution condition is not set in the reference numeral 402, the processing content indicated by the reference numeral 403 is executed when the event set in the reference numeral 401 is acquired.

  Returning to FIG. 3, when the external event acquisition unit 302 acquires an external event or when the internal event acquisition unit 304 acquires an internal event, the condition determination unit 305 determines the event acquired in the event rule of the event rule DB 301. Extract the associated execution conditions. Then, a belief acquired from the belief DB 501 of the planning agent 30 described later is referred to and it is determined whether or not the current situation satisfies the execution condition.

  The event rule of the event rule DB 301 only needs to associate the event with the processing content, and the execution condition is not necessarily essential. When an event is issued regardless of the current situation, an execution condition is not necessary when a predetermined process is performed. In this case, the condition determination unit 305 may determine that the condition is satisfied.

  When the event to be processed satisfies the execution condition, the processing content extraction unit 306 extracts the processing content associated with the event in the event rule DB 301. The notification unit 307 performs processing according to the processing content. Here, examples of processing contents include notification of an instruction to the external monitoring unit 10 and notification of a goal input instruction to the planning agent 30.

  As shown in FIG. 5, the planning agent 30 includes a belief DB 501, a plan group stack 503, an action information DB 504, an action history DB 505, a normal / interrupt goal acquisition unit 506, a goal queue 507, and a normal / A plan creation unit 508, an action management unit 510, an internal event notification unit 511, and an update unit 509. The normal / interrupt goal acquisition unit 506 acquires a goal instruction from the event handling unit 20. The goal queue 507 stores the goal indicated by the goal instruction acquired by the normal / interrupt goal acquisition unit 506.

  The belief DB 501 stores facts used for executing actions. Since this fact is data indicating the status of processing or the like, the belief DB 501 corresponds to the status information storage unit in other words. There are two types of stored facts. One is the fact that no change is made according to the user's reaction to the fact that the processing is not performed as intended by the user, that is, it is not necessary to confirm with the user when a misrecognition occurs. In other words, it corresponds to invariant situation information. The other is the fact that it can be changed according to the reaction of the user, that is, it is possible to confirm with the user when a misrecognition occurs, in other words, it corresponds to variable status information.

  As shown in FIG. 6, the belief DB 501 holds facts that do not need to be confirmed for the user in the case of misrecognition in the brackets of belief, and confirms the user if misrecognition occurs. Keep facts that can be done within the brackets of askableBelief. Further, in the belief DB 501 according to this embodiment, facts that do not need to be confirmed and facts that can be confirmed are held together, but the facts that can be confirmed and the facts that do not need to be confirmed are different from each other. You may memorize | store in a memory | storage means. A process using the information will be described later.

  The normal / interrupt plan creation unit 508 refers to the belief DB 501 and creates a plan including the order of actions to be executed using the facts that can be confirmed and the facts that need not be confirmed stored in the belief DB 501. Of the plans generated by the normal / interrupt plan creation unit 508, the plan generated to achieve the interrupt goal is the interrupt plan, and the plan generated to achieve the normal goal is the normal plan. .

  The plan group stack 503 stores the plan created by the normal / interrupt plan creation unit 508. As shown in FIG. 7, the plan group stack 503 stores a plan group created for each goal. Then, the action management unit 510 to be described later instructs the normal / interrupt action execution unit 40 to execute the action according to the high priority plan group.

  Of the actions executed by the normal / interrupt action execution unit 40, an action executed according to the normal plan is set as a normal action, and an action executed according to the interrupt plan is set as an interrupt action. This interrupt action is an action executed by interrupting a normal action. This interrupt action includes a confirmation request action for confirming whether or not the fact that can be confirmed stored in the belief DB 501 is appropriate. In other words, the normal / interrupt action execution unit 40 also has a function as a confirmation request action execution unit.

  In the present embodiment, the normal / interrupt plan is created in the normal / interrupt plan creation unit 508 by storing the normal goal and the interrupt goal in one goal queue 507. The present embodiment is not limited to such a configuration, and a normal plan creation unit that creates a normal plan and an interrupt plan creation unit that creates an interrupt plan may be configured separately. In this case, the normal / interrupt action execution unit 40 may be configured differently from the normal action execution unit that executes the normal action and the interrupt action execution unit that executes the interrupt action.

  The action information DB 504 holds, for each action, an action rule that describes a precondition used when the action is executed and a process to be performed when the precondition is satisfied. One or more of facts that can be confirmed and facts that do not need to be confirmed are set in the action preconditions. When one or more of these facts that can be confirmed and facts that do not need to be confirmed are appropriately stored in the belief DB 501, it is determined that the precondition is satisfied. The action rule is described in the format of the programming language Prolog, but may be described in another format. In the action rule, an alphanumeric character string starting with an uppercase letter is regarded as a variable.

Such precondition information is recorded in the action information DB 504. Specifically, the action rule shown in FIG. 21 is recorded. Here, the action rules are specifically:
action (Action, [C1,... Cn], [E1,... Em])
It has the shape of Here, Action indicates the action name. C1,... Cn are preconditions. E1,... Em is a fact change process associated with an action, and is a fact change process held in the belief DB 501. That is, when all the n preconditions (C1,..., Cn) of the action (Action) are satisfied, m factual relationships (E1,..., Em) are changed. Further, the change contents of the factual relationship indicated by E1,... Em have any format of initiates (F), initiates Askable (F), or terminates (F).

  Initiates (F) indicates that the fact F that does not need to be confirmed to the user is established, and belief (F) is registered in the belief DB 501. InitiatesAssable (F) indicates that a fact F that can be confirmed by the user is established, and askableBelief (F) is registered in the belief DB 501.

  “Terminates (F)” indicates that the fact “F” is not established, and “belief (F)” or “ableBelief (F)” is deleted from the belief DB 501.

  The action management unit 510 reads the plan stored in the plan group stack 503 and notifies the normal / interrupt action execution unit 40 of an execution instruction for the action included in the plan. Thereafter, the action management unit 510 receives the execution result from the normal / interrupt action execution unit 40. Furthermore, the action management unit 510 registers the executed action in the action history DB 505 as a history. Further, when the action management unit 510 achieves the goal, the action management unit 510 deletes the history of actions performed to achieve the goal from the action history DB 505.

  The action history DB 505 stores a history of actions executed by the normal / interrupt action execution unit 40. As shown in FIG. 8, the action history DB 505 stores action histories in the order of execution.

  Returning to FIG. 5, the internal event notification unit 511 notifies the event handling unit 20 of a start event indicating the start of an action when the action management unit 510 notifies the action execution instruction. Further, when the action management unit 510 receives an execution result indicating the successful execution of the action, it notifies an end event indicating the end of the action. An end event is also notified when an execution result indicating interruption of action execution is received.

  The update unit 509 updates the belief DB 501 and the plan group stack 503 in accordance with the instruction from the action management unit 510 and the belief update instruction from the event handling unit 20 and the normal / interrupt action execution unit 40. As a result of updating the plan group stack 503, when it is no longer necessary to execute the action being executed, the action management unit 510 notifies the normal / interrupt action execution unit 40 of the interruption of the action.

  Next, an example in which the above-described plan execution system 1 is applied to a car navigation system will be described. In the car navigation system, the destination is specified through dialogue with the user, and navigation is started.

  In the example shown in FIG. 9, the external monitoring unit 10 that recognizes a voice command interprets the destination as “Tateyama Station” on the Toyama District Railway Tateyama Line from the user “Tateyama Eki”. In addition, the external environment monitoring unit 10 interprets that the user wants to know the estimated arrival time from “Toyaku Kujikoku” to the destination.

  According to this interpretation, the plan execution system 1 sets a precondition (facts) necessary for creating a route. The plan execution system 1 sets “the destination (which can be confirmed) is Tateyama Station” in the belief DB 501. Further, the plan execution system 1 sets “I want to know the arrival time” in the belief DB 501.

  The route search condition (for example, whether general road priority or high-speed priority) is not specified by the user from the user, but the plan execution system 1 determines that high-speed priority is the default setting. Therefore, the plan execution system 1 sets “(high speed priority)” (which is a fact that can be confirmed).

  Thereafter, the plan execution system 1 “creates / displays a route” when the precondition is satisfied. The “route search condition” is “high speed priority” or not. Then, after the processing is performed, “the route has been created” (which is a fact that does not need to be confirmed) is set in the belief DB 501.

  Then, the plan execution system 1 “reads the predicted arrival time” together with the created “read the notice on the route”. If there is no particular problem, the plan execution system 1 starts guidance thereafter.

Next, the process described above will be described according to the configuration shown in FIG. First, the external monitoring unit 10 notifies the event handling unit 20 of various events and external events that trigger the start of navigation. This notified external event is
command (navigate destination ('Tateyama Station', 'Toyama Regional Railway Tateyama Line'), arrivalTime (necessary), routePreference (highway),)
And

  When the external event is notified, the event handling unit 20 performs processing according to the event rule. In the event rule shown in FIG. 4, since the input external event and the event 401 match, the processing content 403 is executed.

  The assetAskableFluent of the processing content 403 means that the fact set in the argument is registered as something that can be confirmed by the user. That is, when assertAssableFluent (Planning Agent, F) is executed, askableBeef (F) is registered in the belief DB 501 of the planning agent 30.

  It should be noted that assetFluent is used to register facts that are not confirmed by the user. That is, when assertFluent (Planning Agent, F) is executed, belief (F) is registered in the belief DB 501 of the planning agent 30. Thereby, the fact that can be confirmed in the belief DB 501 and the fact that the confirmation is not performed can be distinguished and registered.

  Then, by performing only the registration processing among the processing shown in the processing content 403 of FIG. 4, the belief DB 501 is stored in destination (“Tateyama Station”, “Toyama District Railway Tateyama Line”), arrivalTime (necessary), routePreference ( highway) is registered. The registered belief DB 501 is as shown in FIG. Thereby, the belief update from the event response unit 20 shown in FIG. 1 to the planning agent 30 is performed.

  Thereafter, among the processes shown in the process content 403 of FIG. 4, assertGoal (planning Agent, navigate) means that the event handling unit 20 inputs “navigate” to the planning agent 30 as a normal goal. Thereby, a goal indicating execution of navigation is input from the event handling unit 20 shown in FIG. 1 to the planning agent 30.

  Then, the planning agent 30 creates a normal plan that realizes the normal goal. Note that any plan creation method may be used. The created plan group is pushed onto the plan group stack 503 for each goal.

  Then, according to the normal plan created by the planning agent 30, the actions are set to be executed in the order shown in FIG. In this case, the planning agent 30 issues an execution instruction to the normal / interrupt action execution unit 40 in the order shown in FIG. As a result, a normal action execution instruction is issued from the planning agent 30 shown in FIG. 1 to the normal / interrupt action execution unit 40.

  As shown in FIG. 10, the planning agent 30 instructs the normal / interrupt action execution unit 40 to execute set destination ('Tateyama Station', 'Toyama Regional Railway Tateyama Line') unless there is a particular problem. (Step S1001), instruct execution of setRoutePreference (highway) (step S1002), instruct execution of searchAndShowRoute (step S1003), instruct execution of tellRouteInformation (step S1004), and instruct execution of tellArritimeTime S1005) Finally, by instructing execution of startNavigation (step S1006), navigation for the user is started and all plans are completed. It is scheduled.

  First, the normal / interrupt action execution unit 40 sets the destination to Tateyama station according to set destination ('Tateyama station', 'Toyama district railway Tateyama line') input from the planning agent 30.

  Next, the normal / interrupt action execution unit 40 sets the route search condition to high-speed priority in accordance with the setRoutePreference (highway) input from the planning agent 30.

  Further, the normal / interrupt action execution unit 40 creates and displays a route according to the searchAndShowRoute input from the planning agent 30.

  Furthermore, it is assumed that the normal / interrupt action execution unit 40 reads out the precautions on the route in accordance with the tellArrivalTime input from the planning agent 30. Then, it is assumed that the user indicates a rejection reaction by voice during the reading. In this case, the process is interrupted in step S1004 of FIG.

  That is, when the user shows a rejection response while reading the precautions on the route, the plan execution system 1 preferentially performs a process for identifying where the user is dissatisfied. . A processing procedure for this will be described.

  In addition, the user's rejection reaction is a rejection response to the fact that the processing is not performed as intended by the user by creating and executing the plan based on the erroneous fact stored in the belief DB 501. To do. The rejection reaction may be determined by voice recognition as described above, may be determined by analysis of a face image, or may be determined that the user has rejected when the reject button is pressed. .

  Next, a processing procedure when an interrupt occurs in the plan execution system 1 will be described with reference to FIG. The external monitoring unit 10 notifies the event handling unit 20 of an event (reject) indicating that the user has shown a rejection response ((1) in FIG. 11). In response to this notification, the event handling unit 20 inputs an interrupt goal for confirming the user's intention to the planning agent 30 ((2) in FIG. 11).

  In order to insert such an interrupt goal, it is necessary to store in advance an event for confirming the user's intention in the event rule DB 301 of the event handling unit 20, as shown in FIG. Thereby, when a rejection reaction is shown with respect to the plan of the conversation etc. which the user user is executing, the interruption goal for confirming a user's intention can be thrown in.

An interrupt goal is a goal in which when a plan is entered into the planning agent 30, the plan being executed is interrupted and the action being executed is interrupted if it can be interrupted, and the plan is created / executed preferentially. To do. This interrupt goal is insertedGoal (input destination, [condition], [
Interrupt goal name]).

  That is, the event rule shown in FIG. 12 means that when an event reject is notified, a user intention confirmation goal (checkIntent) that is an interrupt goal (insertGoal) is input to the planning agent 30 (planningAgent). is doing.

  Returning to FIG. 11, when an interruption goal for user intention confirmation is input, the planning agent 30 causes the normal / interrupt plan creation unit 508 to create an interruption plan for the interruption goal. The created interrupt plan is registered in the group stack 503.

  This interruption plan extracts, for each normal action stored in the action history storage DB 505, the fact that can be confirmed that is associated with the normal action by referring to the action information storage unit 504 and the belief DB 501 It consists of an interrupt action (confirmation request action) for requesting the user to confirm whether or not the fact that can be confirmed is appropriate.

  The interrupt plan created from the interrupt goal is stored in the plan group stack 503 with the highest priority, as indicated by reference numeral 1301 in FIG. As a result, the action management unit 510 of the planning agent 30 performs control so that the interrupt goal interrupt plan group is preferentially executed.

  Returning to FIG. 11, the action management unit 510 of the planning agent 30 stops the execution of the normal plan and instructs the normal / interrupt action execution unit 40 to interrupt the normal action ((3) in FIG. 11). . Thereafter, a normal action interruption report is received from the normal / interrupt action execution unit 40 ((4) in FIG. 11). As a result, the normal plan and normal action being executed are interrupted.

  Then, the action management unit 510 of the planning agent 30 starts executing the interrupt plan for the interrupt goal for user intention confirmation. Therefore, as shown in (5) of FIG. 11, the planning agent 30 confirms the intention to the user (output for question and waiting for input from the user), correction of intention by the user (output for prompting the user to correct) , Waiting for correction from the user). This intention confirmation and intention correction processing is performed a plurality of times according to the interrupt plan.

  Then, after the execution of the interrupt plan created from the interrupt goal is completed, the planning agent 30 resumes execution of the suspended normal plan. When the belief DB 501 is updated when an interrupt plan created from an interrupt goal for user intention confirmation is executed while the action execution in FIG. 1 is interrupted, the normal / interrupt The plan creation unit 508 updates not only the executing plan but also all the normal plan groups (including the suspended plan group) stored in the plan group stack 503.

  It is also conceivable that the result of the user's intention confirmation is notified to the external monitoring unit 10 directly or via the event handling unit 20 to improve the accuracy of voice input or the like.

  Next, processing performed by each component of the plan execution system 1 that performs the above-described processing will be described. First, the process performed by the event handling unit 20 will be described. As shown in FIG. 14, when the external event acquisition unit 302 of the event handling unit 20 acquires an external event (step S1401: Yes), or when the internal event acquisition unit 304 acquires an internal event (step S1402: Yes), the condition determination unit 305 refers to the event rule DB 301 and identifies an execution condition associated with the acquired external event or internal event (step S1403). Further, it is determined whether or not the facts stored in the belief DB 501 (including facts that can be confirmed and facts that need not be confirmed) satisfy the execution condition. When the fact in the belief DB 501 satisfies the execution condition (step S1404: Yes), the processing content extraction unit 306 extracts the processing content associated with the external event or the internal event in the event rule DB 301 (step S1405). .

  Next, according to the processing content, the notification unit 307 executes the processing content (step S1406). Specifically, in the case of an event instruction to the outside world monitoring unit 10, the notification unit 307 notifies the outside world monitoring unit 10 of the event instruction. When the processing content is a goal instruction or belief update to the planning agent 30, the notification unit 307 notifies the planning agent 30 of the goal instruction or belief update. A plurality of processing contents may be associated with the same external event or internal event. In this case, the processing content extraction unit 306 selects the processing content with the highest priority.

  As illustrated in FIG. 15, when the planning agent 30 acquires a normal goal from the notification unit 307 (step S1501), the planning agent 30 checks whether the goal is stored in the goal queue 507. If no goal is stored in the goal queue 507 (step S1502: No), a plan execution process for the normal goal is performed (step S1503). On the other hand, when the goal is stored in the goal queue 507 (step S1502: Yes), the acquired normal goal is stored at the end of the plan group stack 503 (step S1504), and the processing is completed.

  Next, when a goal exists in the plan group stack 503 (step S1505: Yes), plan execution processing is performed on the first goal of the plan group stack 503 (step S1506). When no goal exists in the plan group stack 503 in step S1505 (step S1505: No), the process is completed.

  In the plan execution process performed in steps S1503 and S1506 of FIG. 15, as shown in FIG. 16, the normal / interrupt plan creation unit 508 creates a plan corresponding to the goal to be processed (step S1601). Next, when there is a plan that has been created or updated (step S1602: Yes) and the execution of the plan has not ended (step S1603: Yes), the action management unit 510 executes the plan to be executed from the plan group stack 503. Is selected (step S1604). Thereby, the action to be performed is specified.

  Then, the internal event notification unit 511 notifies the event handling unit 20 of a start event indicating the start of the action to be executed (step S1605).

  Next, when the action management unit 510 refers to the action information DB 504 and the belief DB 501 and the fact stored in the belief DB 501 satisfies the action preconditions stored in the action information DB 504, The action execution instruction is notified to the embedded action execution unit 40 (step S1606). Next, the execution state indicating the end of the executed action is notified to the event handling unit 20 (step S1607). Next, the update unit 509 updates the belief DB 501 and the plan group stack 503 according to the action execution result (success / failure / interruption) (steps S1608 and S1609). Then, the action management unit 510 registers the executed action in the action history DB 505 as an execution history (step S1610). If the interrupt goal is notified, the process waits during the interrupt goal processing (step S1611). If the interrupt goal processing is completed, or if no interrupt goal notification is received, the process returns to step S1602.

  Note that the execution result of the action in step S1606 is interrupted when the belief is updated from the outside of another thread, or when an interrupt goal is input and the action being executed is interrupted. In this case, the process immediately proceeds from step S1606 to step S1607.

  When the plan execution is completed in step S1603 (step S1613: Yes), a process when the plan execution is successful is performed (step S1613). If the plan created or updated in step S1602 does not exist (step S1602: No), the process at the time of plan execution failure is performed (step S1612).

  Then, the action management unit 510 deletes the action execution history of the plan corresponding to the goal from the action history DB 505 (step S1614), and ends the process.

  As shown in FIG. 17, when the planning agent 30 acquires an interrupt goal (step S1701), it determines whether or not a plan execution process corresponding to another goal is being performed (step S1702). When it is determined that the plan execution process corresponding to another goal has not been performed (step S1702: No), the plan execution process corresponding to the interrupt goal is performed (step S1707).

  On the other hand, when the planning agent 30 determines that the plan execution process corresponding to another goal is being performed (step S1702: Yes), the currently executing action, that is, the action for achieving the other goal is interrupted. (Step S1703). When the action is interrupted in step S1703, the execution state indicating the end of the action execution is notified to the event handling unit 20 according to the execution result (interruption) of this action (step S1607 in FIG. 16). Next, in order to interrupt the plan being executed, the process waits until the processing of the executing plan of another thread shown in FIG. 16 reaches step S1611 (step S1704).

  Next, the planning agent 30 executes an interrupt plan corresponding to the interrupt goal (step S1705). When the plan execution process for the interrupt goal is completed, the execution of the plan interrupted in step S1704 is resumed (step S1706). At this time, the execution of the plan is resumed in another thread shown in FIG. 16, and the process proceeds from step S1611 to step S1602.

  As shown in FIG. 18, when the belief DB 501 is updated by an instruction from the outside (step S1801), the normal / interrupt plan creation unit 508 has a plan being executed or suspended in the plan group stack 503. It is determined whether or not (step S1802). If it is determined that there is no plan being executed or being interrupted (step S1802: No), the processing ends as it is.

  On the other hand, when the normal / interrupt plan creation unit 508 determines that there is a plan that is being executed or is interrupted (step S1802: Yes), the update of the belief DB 501 may affect these plans. Therefore, in this case, the normal / interrupt plan creation unit 508 corrects the currently executing and suspended plan groups at the time of the belief update based on the updated belief (step S1803).

  Further, when the action management unit 510 determines that it is meaningless to continue execution of the action being executed in the corrected execution plan, that is, the execution of the action being corrected after the belief update When there is no relation with the middle plan (step S1804: Yes), the action management unit 510 interrupts the execution of the executed action (step S1805) and ends the processing. Note that immediately after the execution of the action is interrupted in step S1805, the execution of the action in the plan execution process of another thread is interrupted, and the execution result of the action is interrupted. Further, if it does not make sense to continue the action being executed (step S1804: No), the process ends as it is.

  Next, in step S1705 or step S1707 in FIG. 17, when executing an interrupt plan for an interrupt goal for confirming the user's intention, the normal / interrupt plan creation unit 508 creates an interrupt plan The procedure will be described with reference to FIG.

  First, the normal / interrupt plan creation unit 508 starts creating an interrupt plan in accordance with the goal checkIntention stored in the goal queue 507.

  Then, the normal / interrupt plan creation unit 508 extracts the interrupted action managed by the action management unit 510 and the fact that is a precondition for each action described in the action history DB (step S1901). The fact that is the precondition can be extracted by referring to the precondition held in the action information DB 504 and the fact stored in the belief DB 501.

  Then, the normal / interrupt plan creation unit 508 extracts only the facts that can be confirmed by the user from the extracted facts (step S1902).

  Next, the normal / interrupt plan creation unit 508 creates, for each extracted fact, a plan group that is confirmed with respect to the user and corrected according to the confirmation result (step S1903).

  Then, the normal / interrupt plan creation unit 508 sets the priority order of each action constituting the plan in accordance with the action execution order using the extracted fact as a precondition (step S1904). In the present embodiment, the priority order of each action constituting the plan is set so that the facts used are confirmed in order from the newest.

  Next, the case where an interrupt goal is notified in step S1004 of the processing procedure shown in FIG. 10 will be described.

  First, as shown in step S1901, the normal / interrupt plan creation unit 508 checks the preconditions of the interrupted normal action tellRouteInformation from the action information DB 504. When the action information DB 504 stores information on the normal action shown in FIG. 20, the action is determined to be routeFound as a precondition. Then, the normal / interrupt plan creation unit 508 checks the routeFound in the belief DB 501. As shown in FIG. 6, belief (routeFound) is stored. For this reason, it is determined that confirmation is unnecessary, and is excluded from extraction targets in step S1902.

  Next, the normal / interrupt plan creation unit 508 acquires the normal action executed from the action history DB. From the action history DB shown in FIG. 8, a normal action searchAndShowRoute, a normal action setRoutePreference (highway), and a normal action setDestination ('Tateyama Station', 'Toyama Regional Railway Tateyama Line') can be acquired.

  Therefore, the normal / interrupt plan creation unit 508 confirms from the action history DB 505 the preconditions of the normal action searchAndShowRoute executed immediately before the normal action tellRouteInformation. When the normal action information shown in FIG. 21 is stored, it is determined that the action is a destinationSet and a routePreferenceSet as preconditions. Then, the normal / interrupt plan creation unit 508 confirms the destinationSet and the routePreferenceSet with the belief DB 501. In this case, belief (destinationSet) and belief (routePreferenceSet) are stored in belief DB 501. For this reason, it is determined that confirmation is unnecessary, and is excluded from extraction targets in step S1902.

  Next, the normal / interrupt plan creation unit 508 confirms from the action history DB 505 the precondition of the normal action setRoutePreference (highway) executed immediately before the normal action searchAndShowRoute. When the information on the normal action shown in FIG. 22 is stored, it is determined that the normal action is routePreference (Preference) as a precondition. Then, the normal / interrupt plan creation unit 508 confirms routePreference (Preference) in the belief DB 501. In this case, the belief DB 501 stores askableBelief (routePreference (highway)) as shown in FIG. For this reason, it is determined that confirmation is necessary, and extraction is performed in step S1902. As a result, the user confirms the fact, and if there is an error, correction is prompted.

  Then, the normal / interrupt plan creation unit 508 confirms the preconditions of the normal action setDestination ('Tateyama Station', 'Toyama District Railway Tateyama Line') executed immediately before the normal action setRoutePreference (highway) from the action history DB 505 To do. When the normal action information shown in FIG. 23 is stored, it is determined that the action is destination (POI, Description) as a precondition. Then, the normal / interrupt plan creation unit 508 confirms the destination (POI, Description) in the belief DB 501. In this case, the belief DB 501 stores an acceptableBelief (destination ('Tateyama Station', 'Toyama District Railway Tateyama Line')) as shown in FIG. For this reason, it is determined that confirmation is necessary, and extraction is performed in step S1902. As a result, the user confirms the fact, and if there is an error, correction is prompted.

  Next, the normal / interrupt plan creation unit 508 confirms and confirms with the user for each fact of routePreference (highway) and destination ('Tateyama Station', 'Toyama Regional Railway Tateyama Line') in step S1903. Create an interrupt plan group to correct according to the result. These interrupt plans are prepared in advance in a plan library (not shown).

  In step S1904, the normal / interrupt plan creation unit 508 executes the interrupt plan for confirming the routePreference (highway) as the execution order and correcting the result according to the confirmation result. Then, the destination ('Tateyama Station', Set the execution order to execute the interrupt plan that corrects according to the confirmation and confirmation result of 'Toyama District Railway Tateyama Line'). That is, the normal / interrupt plan creation unit 508 sets the priority for each interrupt plan so that the interrupt plans are executed in order from the facts used in the normal action executed recently (that is, (The priority for the interrupt plan for destination ('Tateyama Station', 'Toyama District Railway Tateyama Line') is set lower than the interrupt plan for routePreference (highway)). These created interrupt plan groups are collectively stored in the plan group stack 503.

  Then, the action management unit 510 executes the created interrupt plan. First, the action management unit 510 executes a routePreference (highway) confirmation from the stored interruption plan group and executes an interruption plan for correction according to the confirmation result.

  As shown in FIG. 24, the action management unit 510 instructs the normal / interrupt action execution unit 40 to execute a confirmation request action spike (“Is it OK with high-speed priority?”), Which is a kind of interrupt action. (Step S2401).

  As a result, the normal / interrupt action execution unit 40 outputs a voice message “Are you sure you want to prioritize high speed?” Thereafter, the action management unit 510 instructs the normal / interrupt action execution unit 40 to execute the interrupt action waitForEvent (no) (step S2402). Thus, the normal / interrupt action execution unit 40 executes a sensing action that waits for a voice input “No” from the user.

  In this case, as shown in FIG. 25, the normal / interrupt action execution unit 40 requests the external monitoring unit 10 that receives the voice input to monitor the voice input event “Yes” or “No”. When the user utters “Yes”, the Yes event is notified to the normal / interrupt action execution unit 40 when the user utters “No”.

  Returning to FIG. 24, when the No event is notified, the normal / interrupt action execution unit 40 determines that the execution of waitForEvent (no) is successful. On the other hand, when the Yes event is notified, it is determined that execution of waitForEvent (no) has failed.

If the normal / interrupt action execution unit 40 determines that it is successful, that is, if it is not fast priority, the following action is executed (step S2403).
changeGoal (getPreference (route, exception ([highway])))

  This change Goal (G) means an action for changing the goal to G. That is, when the change goal (G) is executed, the plan group created for the current goal is popped from the plan group stack 503 and discarded, and the execution history of each discarded plan is also stored in the action history DB 505. Discarded. Instead, the goal is changed to G, and the group of plans created to achieve G are combined and pushed onto the plan group stack 503.

  Therefore, when changeGoal (getPreference (route, exception ([highway]))) is executed, the goal is changed to getPreference (route, exception ([highway])), and the plan group is also changed accordingly.

  A case where the process shown in FIG. 24 is executed when the user intends “fast priority” as the route search condition will be described. In this case, it is assumed that the user responds “Yes” to the question “Are you sure you want high-speed priority?” Generated from the plan execution system 1. In this case, the process of step S2403 is not performed assuming that waitForEvent (no) of step S2402 has failed.

  Next, the action management unit 510 executes confirmation of the destination ('Tateyama Station', 'Toyama District Railway Tateyama Line') from the stored plan group and a plan for correction according to the confirmation result.

  As shown in FIG. 26, the action management unit 510 normally executes execution of a confirmation request action spike ('is your destination OK at Tateyama Station on the Toyama Regional Railway Tateyama Line?), Which is a kind of interrupt action. Instructs the interrupt action execution unit 40 (step S2601).

  As a result, the normal / interrupt action execution unit 40 outputs a voice message “Are you sure you want to arrive at Tateyama Station on the Toyama District Railway Tateyama Line?”. Thereafter, the action management unit 510 instructs the normal / interrupt action execution unit 40 to execute the interrupt action waitForEvent (no) (step S2602). Thus, the normal / interrupt action execution unit 40 executes a sensing action that waits for a voice input “No” from the user. In addition, the processing in this case is the same as that described above, and thus description thereof is omitted.

  If the No event is notified, the normal / interrupt action execution unit 40 determines that the execution of waitForEvent (no) is successful. On the other hand, when the Yes event is notified, it is determined that execution of waitForEvent (no) has failed.

When the normal / interrupt action execution unit 40 determines that it is successful, that is, when it is not Tateyama station on the Toyama district railway Tateyama line, the following interrupt action is executed (step S2603).
changeGoal (getDestination (except ([destination ('Tateyama Station', 'Toyama Regional Railway Tateyama Line')])))

  The case where the process shown in FIG. 26 is executed when the user intends “JR East Uchibo Line Tateyama Station” as the destination will be described. In this case, it is assumed that the user responds “No” to the question “Are you sure you want to go to Tateyama Station on the Toyama District Railway Tateyama Line?” Generated by the plan execution system 1. In this case, the process of step S2603 is performed assuming that waitForEvent (no) of step S2602 is successful.

  Next, by executing the interrupt action changeGoal (getDestination (exception ([destination ('Tateyama Station', 'Toyama Regional Railway Tateyama Line')])), the existing plan group is popped from the alternative plan group stack. The action execution history of each discarded plan is discarded from the action history DB 505.

  Then, the normal / interrupt plan creation unit 508 achieves the goal of asking the user about the destination (getDestination (except ([destination ('Tateyama Station', 'Toyama Regional Railway Tateyama Line')])))) An interrupt plan group is created and pushed onto the plan group stack 503.

  Thereby, the action management unit 510 executes the interrupt plan shown in FIG. As shown in FIG. 27, first, the action management unit 510 instructs the normal / interrupt action execution unit 40 to execute an action that speaks “Please re-enter the destination.” S2701).

  Thereafter, the action management unit 510 sends the interrupt action waitForEvent (destination (POI, Description), [exception ('Tateyama Station', 'Toyama Local Railway Tateyama Line')) to the normal / interrupt action execution unit 40. )]) Is instructed (step S2702).

  At this time, the action management unit 510 requests the outside world monitoring unit 10 to monitor the input event (destination (POI, Description)) of the destination POI and its description Description. However, the same misrecognition can be prevented by using a condition (except (destination ('Tateyama Station', 'Toyama Regional Railway Tateyama Line')) that indicates that it is not Tateyama Station on the Toyama Regional Railway Tateyama Line. To do. Processing in this case will be described later.

  Thereafter, the action management unit 510 executes the interrupt action retractFluent (destination (_, _)) (step S2703), and executes the interrupt action assertAskableFluent (destination (POI, Description)) (step S2704). Instruct the interrupt action execution unit 40.

  This executed interrupt action retractFluent (destination (_, _)) means that the fact destination (_, _) is deleted from the belief DB 501.

  Also, the interrupt action assertAscableFluent (destination (POI, Description)) to be executed means registration of askableBelief (POI, Description), which is a fact that can be confirmed in the belief DB 501.

  That is, the normal / interrupt action execution unit 40 requests the update unit 509 to update the belief according to the interrupt action. In accordance with this, the update unit 509 updates the belief DB 509.

  As a result, when the destination POI and its description Description are acquired from the outside world monitoring unit 10, the planning agent 30 and the normal / interrupt action execution unit 40 can execute the above-described action execution and the destination recorded in the belief DB 501. The description is replaced with the newly acquired POI and Description.

  Execution of these interrupt actions completes execution of the interrupt plan. Then, the plan including the plan group is popped from the plan group stack 503 and the action execution history of each discarded plan is discarded from the action history DB 505. And it returns to original plan execution again.

  Next, the processing of the external monitoring unit 10 requested in step S2702 of FIG. 27 will be described using FIG. First, the external environment monitoring unit 10 waits for user input (for example, voice input) (step S2801).

  Next, the external environment monitoring unit 10 receives user input (for example, voice input) (step S2802). Then, according to the condition (eg, exception ('destination (' Tateyama Station ',' Toyama District Railway Tateyama Line '))), the external environment monitoring unit 10 does not have the same content as the previously detected error (for example, (Speech input) is interpreted (step S2803).

  Then, the external environment monitoring unit 10 notifies the action management unit 510 of the interpreted content as a sensing result (step S2804).

  In other words, the outside world monitoring unit 10 interprets the Tateyama station on the Toyama district railway Tateyama line even if “Tateyama Eki” is input again by the user. In this processing procedure, it is assumed that it is interpreted as Tateyama Station on the JR East Uchibo Line. According to this interpretation, processing of the original plan that was interrupted is started.

  That is, the normal / interrupt plan creation unit 508 creates the plan shown in FIG. As shown in FIG. 29, the destination is reset by executing set destination ('Tateyama Station', 'JR East Uchibo Line'), but high-speed priority setting by executing setRoutePreference (highway) is not necessary.

  Then, the planning agent 30 instructs the normal / interrupt action execution unit 40 to execute the normal action set destination ('Tateyama Station', 'JR East Nihonbo Line') (step S2901), and execute the normal action searchAndShowRoute. (Step S2902), the execution of the normal action tellRouteInformation is instructed (step S2903), the execution of the normal action tellArrivalTime is instructed (step S2904), and finally the execution of the normal action startNavigation is instructed (step S2905).

  Note that any method may be used as a method for correcting an interrupted plan during execution of an interrupt plan, including a conventionally proposed method.

  According to the plan execution system 1 according to the above-described embodiment, by creating a plan for confirming to the user only for the facts that can be confirmed to the user of the belief DB 501, the intention of the user can be efficiently achieved. It becomes possible to recognize.

  As shown in FIG. 30, the plan execution system 1 according to the first exemplary embodiment includes a ROM 52 storing a plan execution program for performing the above-described processing as a hardware configuration, and plan execution according to the program in the ROM 52. A CPU 51 that controls each part of the system 1, a RAM 53 that stores various necessary data, a communication I / F 57 that communicates by connecting to a network, and a bus 62 that connects each part are provided.

  The plan execution program may be provided by being recorded in a computer-readable recording medium such as a CD-ROM, a floppy (registered trademark) disk (FD), or a DVD as an installable or executable file. .

  In this case, the program is loaded onto the main storage device by being read from the recording medium and executed by the plan execution system 1, and each unit described in the software configuration is generated on the main storage device. ing.

  Further, the program of the present embodiment may be configured to be stored by being stored on a computer connected to a network such as the Internet and downloaded via the network.

  As another example, the external environment monitoring unit 10, the event handling unit 20, and the planning agent 30 of the plan execution system 1 may be mounted on different computers. In this case, the hardware configuration of the external monitoring unit 10, the event handling unit 20, and the planning agent 30 is the same as the hardware configuration described above.

  As described above, the present invention has been described using the embodiment, but various changes or improvements can be added to the above embodiment.

It is a figure which shows the whole structure of the plan execution system concerning 1st Embodiment. It is a figure which shows the relationship between a goal, a plan, and an action. It is a block diagram which shows the function structure of an event corresponding | compatible part. It is the figure which showed an example of the event rule stored in event rule DB. It is a block diagram which shows the function structure of a planning agent. It is the figure which showed an example of the fact stored in belief DB. It is the figure explaining the concept of the plan group stored in the plan group stack. It is the figure which showed an example of the action execution log | history stored in action log | history DB. It is the figure which showed the concept of the process which a plan execution system performs by dialogue with a user. It is the flowchart which showed the process sequence by the plan created in order for the planning agent to perform navigation. It is explanatory drawing which showed the notification performed within a plan execution system, when a user's rejection reaction is detected. It is the figure which showed an example of the event rule in which the processing content performed when a user's rejection reaction is detected is defined. It is the figure explaining the concept which added the plan group of the interruption goal to the plan group stack. It is a flowchart which shows the process of an event corresponding | compatible part. It is a flowchart which shows the process of the planning agent with respect to a normal goal. It is a flowchart which shows a plan execution process. It is a flowchart which shows the process with respect to an interruption goal. It is a flowchart which shows the process of the planning agent when belief is updated from the outside. It is a flowchart which shows the process which produces the plan corresponding to the interruption goal which confirms a fact with respect to a user. It is a figure which shows the 1st example of action condition management DB which action condition management DB stores. It is a figure which shows the 2nd example of action condition management DB which action condition management DB stores. It is a figure which shows the 3rd example of action condition management DB which action condition management DB stores. It is a figure which shows the 4th example of action condition management DB which action condition management DB stores. It is a flowchart which shows the process sequence by the plan which confirms that route search conditions are high-speed priority, and corrects according to a confirmation result. It is the figure which showed the transmission / reception relationship of the event by an external field monitoring part and a normal and interruption action execution part. It is a flowchart which shows the process sequence by the plan which confirms that the destination is Tateyama station of the Toyama district railway Tateyama line, and corrects according to a confirmation result. It is a flowchart which shows the process sequence by the plan produced in order to re-input the destination. It is the flowchart which showed the processing procedure until an external world monitoring part notifies an event from a user input. It is a flowchart which shows the process sequence by the plan restarted after interruption was complete | finished from the interruption plan. It is a figure which shows the hardware constitutions of the plan execution system concerning 1st Embodiment.

Explanation of symbols

1 Plan Execution System 10 External Field Monitoring Unit 20 Event Response Unit 30 Planning Agent 40 Normal / Interrupt Action Execution Unit 51 CPU
52 ROM
53 RAM
57 Communication I / F
62 Bus 301 Event Rule DB
302 External event acquisition unit 304 Internal event acquisition unit 305 Condition determination unit 306 Processing content extraction unit 307 Notification unit 501 Belief DB
503 Plan group stack 504 Action condition management DB
505 Action history DB
506 Goal acquisition unit 507 Goal queue 508 Normal / interrupt plan creation unit 509 Update unit 510 Action management unit 511 Internal event notification unit

Claims (6)

A normal target storage unit for storing normal target information indicating a user's request;
Indicates variable status information indicating status information that can be changed according to a user's reaction to processing not being performed as intended by the user, and status information that is not changed according to the user's response A status information storage unit for storing invariant status information;
A normal plan creation unit that creates a normal plan indicating an execution order of normal actions for performing processing using one or more of the variable status information and the invariant status information, which is an action corresponding to the normal target information When,
A normal action execution unit that executes the normal action according to the execution order for each of the created normal plans;
An action history storage unit for storing a history of the executed normal actions;
An action information storage unit that stores action correspondence information in which the normal action is associated with the variable situation information used at the time of execution for each normal action;
For each normal action stored in the action history storage unit, the variable situation information associated with the normal action is extracted from the action correspondence information storage unit, and whether or not the extracted variable situation information is appropriate An interrupt plan creation unit for creating a confirmation request action for requesting confirmation from the user,
A confirmation request action execution unit that executes the confirmation request action by interrupting the normal action;
When information indicating that the variable status information is not appropriate is input from the user by the executed confirmation request action, the confirmation request action is a confirmation target stored in the status information storage unit An update unit for updating variable status information;
An action execution device comprising: The action history storage unit stores a history according to an order in which the execution of the normal action by the normal action execution unit is completed,
The interrupt plan creation unit further refers to the action information storage unit and executes the confirmation request action for requesting confirmation of the variable status information associated with the normal action in order from the new normal action. To set the execution order to
The action execution device according to claim 1. An external monitoring unit that monitors the external world, interprets information acquired from the external world, and acquires status information;
A notification unit for notifying the external monitoring unit of the variable status information held by the status information storage unit when the verification request action execution unit interrupts and executes the verification request action in the normal action; Further comprising
The status information storage unit holds the status information acquired by the external monitoring unit as the variable status information,
The outside world monitoring unit interprets the information acquired from the outside world so as to acquire the status information other than the notified variable status information when the variable status information is notified from the notification unit;
The action execution device according to claim 1 or 2, wherein The normal action execution unit, when the confirmation request action execution unit interrupts and executes the confirmation request action in the normal action, interrupts the execution of the normal action for each normal plan created,
The normal plan creation unit re-creates the normal plan including the normal action interrupted by the normal action execution unit after the variable status information is updated by the update unit,
The normal action execution unit executes the normal action for each of the recreated normal plans using the updated variable status information.
The action execution device according to any one of claims 1 to 3, wherein   When the execution of all the normal actions for each of the created normal plans is finished by the action execution unit, the action execution unit further includes a deletion unit that deletes the action information stored in the action history storage unit. The action execution device according to any one of claims 1 to 4. A normal target storage step of storing normal target information indicating a user's request in the normal target storage unit;
Indicates variable status information indicating status information that can be changed according to a user's reaction to processing not being performed as intended by the user, and status information that is not changed according to the user's response A situation information storage step for storing invariant situation information in the situation information storage unit;
A normal plan creation step of creating a normal plan indicating an execution order of normal actions for performing processing using one or more of the variable status information and the invariant status information, which is an action according to the normal target information When,
A normal action execution step of executing the normal action according to the execution order for each of the generated normal plans;
An action history storage step of storing a history of the executed normal actions in an action history storage unit;
An action information storage step for storing, in each action information storage unit, action correspondence information that associates the variable situation information used by the normal action at the time of execution for each normal action;
For each normal action stored in the action history storage unit, the variable situation information associated with the normal action is extracted from the action correspondence information storage unit, and whether or not the extracted variable situation information is appropriate An interrupt plan creation step for creating a confirmation request action for requesting confirmation from the user,
A confirmation request action execution step of interrupting and executing the confirmation request action in the normal action;
When information indicating that the variable status information is not appropriate is input from the user by the executed confirmation request action, the confirmation request action is a confirmation target stored in the status information storage unit An update step for updating variable status information;
An action execution method characterized by comprising:

Images