JPH04127328A - Execution control method for system consisting of plural modules - Google Patents

Abstract

PURPOSE:To avoid the fixation of a flow of a processing by structuring each module so as to operate completely independently, and deciding the module to be executed in the next time and controlling dynamically the execution by a production system. CONSTITUTION:In an execution control module, a program of a sequential type is not described, a variable item which becomes a turning point for executing each module is described in a frame, a dispatch rule set (inference module) for defining a rule in which an execution condition of each module and a call of the module to be executed are described on the left side and the right side, respectively is described, and by actuating it, the module (processing) to be executed in the next time and its module is executed dynamically by a production system. Therefore, structure of each module becomes such structure as each module operates completely independently, and becomes such structure as a result of processing of the other module is not expected, and a variable in the other module is not referred to nor updated directly. In such a way, the whole system can be controlled dynamically.

Description

[Detailed Description of the Invention] [Industrial Application Field J] This invention relates to an inference processing module, a calculation processing module,
The present invention relates to an execution control method for a system, such as an expert system, which is composed of a plurality of modules such as an input/output processing module, and performs work by executing these modules in a chain.

``Prior Art'' Recently, there has been a remarkable development of expert systems that incorporate the knowledge of experts into electronic computers and allow the computers to perform inferences as if they were experts.

Expert systems usually use a frame that expresses (memorizes) factual knowledge and a rule that makes a conditional judgment based on comparison with the frame and performs a certain action. Furthermore, an expert system solves a problem by combining inference modules (rule sets) that partially solve the problem using a plurality of rules. In addition, many modules that perform calculation processing and input/output processing are also required, and a control module that controls the execution of various modules in order to combine these modules to perform a single job. FIG. 6 shows the module configuration of a conventional expert system.

In conventional expert systems, the execution control module that controls the execution of modules such as inference and calculation input/output is a sequential processing type, that is, it is written as a program, and each module is executed according to a predetermined flow. I am running it.

When using an expert system, it is first necessary to provide some information such as the situation of the target to be diagnosed and the design conditions.First of all, it is necessary to provide a message prompting for information input, a menu for selecting input items, and a table for bulk input of related information. An input module implementing an input means such as a format is executed. Once the necessary information is input, modules such as inference, calculation, and input of detailed information are executed in a predetermined order to reach a conclusion. To correct or add input information,
By inputting the selection of correction items, etc., to the corresponding module,
Alternatively, the flow of processing is returned to the starting point of the system and the series of steps is repeated again. However, predetermining the flow of module processing in this way has several problems as described below.

(a) The way experts who have tasks for which it is difficult to establish a fixed processing flow is working on many modules using unclear procedures due to thinking errors, can be summarized! May be difficult to model and program on-board. However, originally, an expert system was able to define expert knowledge declaratively and use a production system to build a system without being aware of the order of decisions; or between rulesets that are called from within that ruleset, and between other inference modules, input/output, and calculation modules, there is no production system involved, and there is some kind of function that controls execution. need to be given.

(b) When an input module is called by sequential processing programming in which the input order is fixed, the input order is fixed by the program.

When using an expert system, it is necessary to provide some information such as the situation of the target to be diagnosed and the design conditions.However, all the necessary input information is not provided at the beginning, and the need for that information is determined during the inference process. There are cases where it is necessary to make inferences and come to some kind of conclusion based on information that is ``unknown'' even if it is not entered.6 For example, when conducting an interview while listening to the story of the shrine maiden. , each person has a different way of thinking about important items and their thought process, and the order in which information is obtained differs depending on the shrine. Furthermore, the processing for calculating the judgment 1 differs depending on the information available at the time.

For example, when selling AV products, the initial information obtained will vary depending on the prince, such as, ``I want a J that I want to build a set with a budget of Oo, or I want a ΔΔ that has [xxll ability.''It's coming. In addition, they must analyze the requests of the shrine lord using only the information obtained, and select and sell products.

In such a case, first ask about the type of product you want, enter your budget, and check the requested I! Systems that have a fixed input order or calculation order, such as functions that must be entered in the correct order, and can only handle a unique flow, have a major problem in usability.

(C) If module execution is controlled by programming that makes it difficult to add/change modules, it is necessary to change the program in the execution control module as modules are added/changed, and the order of module execution may be affected. It requires a lot of time for consideration. moreover,
If the module structure is bad, adding or changing one module will affect other processes, and the structure (program) of that module may need to be changed even though the processing content is exactly the same. Sometimes it happens.

The purpose of this invention is to solve the above-mentioned problems by easily realizing a process in which experts perform multiple tasks through trial and error, for example, by using the Yukisvert system.
In addition, the order of input items is left to the system user's discretion, and the system user can make decisions using only known information, process the calculation module, and reach a conclusion, and can also freely select and input/change new information items. An object of the present invention is to provide a control method for a system in which a plurality of modules execute work in a chain manner, and which module can be dynamically determined to be executed or re-executed based on the information.

"Means for Solving the Problem" In order to achieve the above object, according to the present invention, r this work is performed when the following information is known. Perform this process when the value of this information changes. ”, the variable items that trigger the execution of each module (process) are written in the frame, the execution conditions of each module are written on the left side, and the calls of the modules to be executed are written on the right side. defined within the set (inference module),
The dispatch ruleset is activated on the production system, detects changes in the values of the variable items defined in the above frame, determines whether the execution conditions of the above rule are satisfied, and selects the module to be processed. The main feature of this system is that it allows the module to be executed and the entire system to be controlled dynamically.

Conventionally, the parts that control the execution of modules are written using sequential programming, which makes it difficult to faithfully implement the work process by experts, lacks flexibility in handling input items that change depending on the situation, and , addition/change of modules requires careful consideration of execution control, but this invention can solve these problems.

``Example'' This invention will be described with reference to an example that has been applied to an expert system. Figure 1 shows the module configuration of this embodiment. In this embodiment, a sequential program is not written in the execution control module, but variable items that trigger the execution of each module are written in the frame. A disburser that defines rules in which the execution conditions for each module are written on the left side and the module calls to be executed are written on the right side.

Write a chiller sent (inference module), start it, dynamically determine the next module (processing) to be performed in the production system, and execute that module.

For this reason, the structure of each module should be such that each module operates completely independently, and does not expect the processing results of other modules or directly reference or update variables in other modules. .

FIG. 2 shows divided modules and the exchange of information between them. The module lNPt1T1 that performs input processing regarding the circular and BB is the RE[1[IESTI
It references variables such as DATA4, and DATA1, D
Update variables such as ATA2. Similarly, a module that performs processing related to SS? In 1ODULE1, D
It refers to variables such as ATA7 and updates variables such as DATA4, and also updates variables DATA1 . D
ATA2, etc., and the updated variable DATA5. DAT
A6 and the like are also treated as variables that are referenced/updated by the module MODtlLE1. Variables that are referenced/updated by multiple modules are managed as a common data area using frames, etc.
It is not limited to one module.

Variables of module MODULEI [IATAl, DAT
Variables referenced by modules such as A2 require (re)execution of this module if their values change, so the information (variable item) that triggers execution is the trigger frame below frame c. However, it is not a special frame, and the existence of variables other than information that triggers execution is also allowed. Figure 3 shows an example of a trigger frame, and the front (direction) is described for each variable item (slot name). Also, the variables to be updated are defined (described) in the common data. It is managed as a frame, etc.

In this way, all the inference and calculation two-person output modules are made independent so as not to affect each other, and the information (variable items) that becomes the trigger for execution is extracted and defined in the trigger frame. .

Next, in the execution control module, the entire internal execution system is declaratively described using production rules. In these rules, the conditions for executing the corresponding module are written on the left side, and the invocation of that module is written on the right side.

Also, all these rules are contained in one ruleset (
Hereinafter, this rule set will be referred to as a dispatch rule set.

Define within. However, it is often the case that the execution control module is divided into complementary rulesets;
It has a hierarchical structure in which one rule set is called as child rule sets and grandchild rule sets. FIG. 4 shows an example of a dispatch rule set. Module MOD [ILEl has variables DATAI, D
ATA2. [1ATA7 etc. are referenced, so if these variables change, the module? A rule is written to activate l0DULE1. In other words, the variables DATAL and DATA are added as execution conditions on the left side of the rule.
2. The change in DATA7 is described, and the module MODULEI to be executed is written on the right side.

In addition, the input module INPIITI has a variable REQ[
1ESTIDATA4. Although it refers to DATA6, etc., it is defined that it is not activated by a change in variables DATA4, DATA6, etc., but only by a change in variable REQUESTl. Also, multiple rules may be defined for one module.
In that case, if the conditions of any rule are satisfied as the OR condition, the processing of that module is performed.

In this way, at least one rule describing execution conditions is defined for all inference, calculation, and input/output modules.

Here, the input/output module may be treated with a lower execution priority than other inference calculation modules. By doing so, processes such as inference and calculation are executed with priority, and after a series of flows are completed, the next task selection or information input is waiting, and unexpected problems occur during inference or calculation. There is no waiting for input.

In this way, the divided modules are executed one after another, with the production system determining the execution order by simply activating the dispatch ruleset. The production system consists of a frame that records factual knowledge and a slam matching clause on the left side that is compared with that frame to determine whether the condition is true or false or true/false, and all the slam matching clauses on the left side are true. This method determines the execution order using a rule that has an execution part on the right side that is executed at the same time, and was used in expert systems to determine the execution order of inference modules. In this embodiment, the execution control module includes a disper.

By writing a chiller set and providing a trigger frame, the production system determines the execution order of the modules, and the determined module is executed by the execution control module.

FIG. 5 shows an example of an execution flow seen from the entire system. When you start a dispatch ruleset, it first determines whether there is a rule (module to be executed) that satisfies the module's execution condition by referring to the trigger frame. This is done by reference to the production system (S,). Immediately after startup, there is no need for module processing in response to changes in information (variables); the input module with the lowest priority is selected, and manual processing is performed. A message prompting the user to perform is displayed (S,), and the user selects the desired task from a menu for selecting input items (S5).

Due to this selection, the value of the information (variable) of the input item changes, and the execution condition of the module is judged again (S,), so that the corresponding module satisfies the execution condition and becomes the execution target. (St).

Then, the execution control module executes the execution unit of the rule to properly execute the module to be executed, for example, the input module), and certain information is input (S,). When that module finishes running,
The module execution conditions are checked again (S,), and the input module automatically detects the module that must be executed based on the input information (variables).

If multiple modules are detected, the production system's conflict resolution function selects and processes only one module to be executed next (S2).
. The selected module is executed, and the information (variables) converted into i by the processing of the module is automatically detected when the execution conditions of the module are checked again.
Modules (modules to be executed) affected by changes in the information (variables) are automatically determined.

In this way, the production system's cycle of "execution condition matching/conflict resolution/module execution" is automatically repeated through a series of processes until there are no modules affected by changes in information (variables). A large amount of work will be done. When the module affected by the change in information (variables) no longer exists, it returns to the input waiting state as it did immediately after startup (S,, S5).
.

Here, when "terminating the system" is selected, the system exits from the dispatch ruleset and the system operation is completed.

Additionally, when the next task is selected, a series of modules related to it are executed sequentially.

Although the present invention is applied to an Exverter system in the above, the present invention can also be applied to a system that performs work by executing multiple other modules in a chain, and in that case,
If the Nostem originally uses a production system, you can use that production system to determine the next module to be executed.
For systems that do not use a production system, it is sufficient to install the production system.

"Effects of the Invention" As described above, in this invention, each module has a structure that operates completely independently, and the variable opening that triggers the execution of each module is written in the frame, and the execution conditions of the module and the module to be executed are , and calls are written in rules, and based on these rules, the production system determines the next module to be executed and dynamically controls execution, and the flow of processing is not fixed, so it has the following effects.

a. Compared to the past, when creating a module, there is no need to design a processing method with consideration to the detailed behavior of other modules.

b. Unlike conventional methods, there is no need to perform execution control that takes into account the order of opening of each module, and the entire system can be controlled simply by activating one ruleset.

C6 Compared to the conventional system, it is easier to construct a system in which the user can freely select input/output timing (when and what information should be input and output).

d. As a result of the above C, there is no need to consider realizing the timing of human output by a program as in the past.

e. It is possible to process tasks even when the procedure is not clear due to confusion, and even when the input order is not fixed.

f. Addition/modification of modules can be easily handled by adding/modifying variables in the trigger frame and adding/modifying rules in the dispatch rule set.

[Brief explanation of the drawing]

FIG. 1 is a block diagram showing the module configuration of an Exverton stem to which the present invention is applied, FIG. 2 is a diagram showing an example of the relationship between modules and information exchange, FIG. 3 is a diagram showing an example of a trigger frame, and FIG. Part 4 is a diagram showing an example of the relationship between dispatch rule sets, trigger frames, common data areas, and modules, Figure 5 is a diagram showing the flow of module execution control, and Figure 6 is the module configuration of a conventional expert system. FIG. Patent applicant Nippon Telegraph and Telephone Corporation

Claims (1)

[Claims] (1) In a system that consists of multiple modules such as an inference processing module, a calculation processing module, and an input/output processing module, and performs work by executing these modules in a chain, the variable items that trigger the execution of each of the above modules are A rule is written in a frame, and the execution conditions of each of the above modules are written on the left side, and the call of the module to be executed is written on the right side. A rule is defined in the dispatch ruleset, and the production system uses the dispatch ruleset and the above frame to Automatically detect changes in data generated/changed during the execution of the plurality of modules, select a module to be processed and execute that module, and centrally manage the execution of the modules; An execution control method for a system consisting of multiple modules, characterized by dynamic execution control.