Use of procedural programming languages for controlling production

Use of Procedural Programming Languages for Controlling Pro duct ion Systems Toru Ishida, Yiitaka Sasaki and Yoshimi Fukiihara NTT Communications and Information Processing Laboratories 1-2356, Take, Yokosuka-shi, 235-03, Japan Email: ishida/sasaki/fukuhara%nttkb.ntt.jpQrelay.cs.net

Abstract

119821 extended it to the Recursive Transition Network ‘(RTi). All these research efforts have attempted to introduce new control plon description languages. However, because of the dificulty of introducing a new language and the limitation of programming ability of proposed representations, their approaches have not been widely accepted. As a result, since the: method of describing procedural control is not, explicitly supported, programmers have to embed the control information into rules through various coding techniques [Brownston et al., 19851. Rather than creating a new language, this paper proposes a new approach called UPPL, which allows existing procedural programming languages to control production systems. Though recent practical tools provide a bridge between production systems and procedural programming languages, ti0 system exists in which a procedural program can interrupt a production system a t each execution cycle and select the next rule t,o be executed. As the key idea of implementing this, we view production systems as a collection of concurrent rule processes> each of which continuously monitors tlie global database, and executes actions when its conditions match database ent,ries. Thus, in order to bridge control plans and rule processes, we introduce the Procedural Control Macros (PCMs) to procedural languages. The PCMs are designed based on CSP’s conimunicat,ion commands [Hoar, 19781. Since PCMs include nondeterministic properties, the execution order of rules cannot be completely determined in advance, but is guided by the PCMs at run-time. The PCMs are functionally simple and easy to implement but they can effectively control production systems when combined with the original control facilities of procedural languages.

Production system applications recently experienced exceedingly difficult software maintenance problems, because control of rule firings is buried in the rules themselves. In this paper, we propose a new approach called UPPL, which uses procedural programming languages, such as Lisp and C, to explicitly describe tlie plans of controlling production systems. To achieve this goal, the procedural languages provide new facilities to interrupt production systems at each execution cycle and to select the rule to be executed. Procedural Control Macros (PCMs) are introduced into procedural languages to allow control plans to communicate with a collection of rules. Together with the original control facilities of procedural languages, the PCMs enable users to eifciently specify tlie control plans of production systems.

AI topics: Controlling production systems.

Language/Tool: Lisp / Production systems. Domain area: Not restricted. Status: Laboratory test. Effort: 2 person years. Impact: Experiment of rewriting 370 rules significantly improves the maintainalility of those rules without representation (file volumes) and the run-time (processing time) overheads.

1

Introduction

After a decade of experiments in production systems, a number of expert systems are now in their maintenance phases. While the performance improvement of production systems has often been studied [Forgy, 1982; Miranker, 1987; Ishida 19881, the maintainability of application prog r a m has not yet been well investigated. Soloway et al. [1987] has reportpd that 50% of XCON’s rules are updated every year. One of the major difficulties of maintaining such large scale expert systems is reported that the execution control of rule firings, either implicit or explicit, is buried in the rules themselves. The execution control of production systems can be classified into two categories: conflzct resolutzon, which determines the search strategies but does not affect the solution set, and procedural control, which constrains production invocation and thereby modifies the solution set [Georgeff, 19821. There is a little research reported on procedural control. Zisman [1978] proposed to control production rules with the Petrz Net. Stolfo [I9791 represented control plans by the State Transzizon Dzagrrrm, while Georgcff

CH2967-8/91/0000/0071$01.OO 0 1991 IEEE

2 2.1

Background Production Systems

A productzon system is defined as a set of rules or producttons, called the productzon memory (PM), together with a database of assertions, called the workzng memory (WM). Assertions in the WM are called workzng memory elements (WMEs). Each rule consists of a conjunction of condztzon elements, called the left-hand szde (LHS) of the rule, and a set of actions called the nght-hand szde (RHS). The RIIS specifies information which is to be added to or deleted from thp WM. The productzon system znterpreter repeatedly executes the Match, Confizct Resolutzon and Act cycle. In the Match phase, each rule determines whether the LIIS matches the current environment of WM. In the Conflict

71

Explicit control can be seen in pre-selection, which should be the first of the three rules to be fired. This is guaranteed because the special WME counter created by pre-selection is referenced by the other two rules, i.e., data dependency relationships are embedded into the rules. The counter is also used to control the loop in selection-heuristics in which the RIIS increments the counter,while the LHS checks the exit condition of the loop.

pre-selection (task "name select-goods) --> (make counter ^value 0 ) ) selection-heuristics (task ^name select-goods) ( (counter ^value ( < 1 0 0 ) ) ) ;selection heuristics are written here --> ;register selected goods (modify ^value (compute + 1 ) )

Implicit control can be seen in post-selection. This rule should not be fired until 100 goods are selected. To achieve this, the post-selection rule is writt.en so that it is the last rule to be selected, that is, the LHS of post-selection subsumes the LHS of selection-heuristics. Since OPS5 gives higher priority to more specific rules, post-selection is not fired until all goods have been selected.

)

post-selection (task ^name select-goods) ( (counter)) --> (remove ))

Figure 1: Sample Coding Techniques

Recent tools provide various control facilities for production systems. The facilities explicitly specify the priorities of rules, transfer the control between sets of rules, called rulesets, and enable users to define their own conflict resolution strategies. However, unguided utilization of various cont.rol techniques sometimes decreases the readability of production s y s t e m . A more direct approach should be taken to solve the control problem, that is, to develop an explicit way of describing the procedural control of production systems.

Resolution phase, exactly one of the matchziig znstaulzatzons of the rules is chosen through the conflzct resolutaon strategy. In the Act phase, all assertions are added to or deleted from WM.

2.2

Conventional Procedural Control

In product.ion systems, multiple rules communicate wit,li each other through the WM. While this model is well suited to represent independent chunks of declarative knowledge, various coding tricks are required when implementing procedural control transfers from rules to rules. The techniques can be classified into the following catcgories.

Procedural Control Language

3

We realized the UPPL approach, by introducing four PCMs into procedural programming languages: two rule invocation macros execute single rules; the rule selection macro selects one executable rule from multiple candidate rules; and the plan definition macro develops large scale rule-based systems. In the following examples, though we use Lisp as the procedural programming language.'

Explicil control describes the execution order of rules explicitly. The common method is to embed data dcpendencies into rules. A special WME is introduced so that one rule creates the WME and another rule refers to it. Since explicit control requircs additional contlitions and actions, the rules become more complex. Furthermore, since related descriptions are embedded into different rules, rules that seem independent at first glance may tightly depend on each other. Thrsc additional interrelationships decrease the readability of application programs.

3.1

Rule Invocation

?-Macro Since rules can be viewed as independent processes, the ?-macro, which is based on the CSP input command, is introduced to invoke a single rule. (? rule-name [variable-bindzng

I m p l i c i f control realizes procedural control through conflict resolution strategies. Note that conflict resolution was originally introduced to describe the search strategies. However, since a large part of applicat,ion programs do not require the state space search, coilflict resolution is often used for implicit procedural control. In this techniques, though rules can retain their simplicity, the control structure hidtlcn behind rules becomes hardly understood.

. . .]>

This macro executes the specified rule, and returns t when the conditions of the rule are satisfied. Otherwise the ?macro monitors the WM and waits for data changes until the conditions of the rule are satisfied. Thus, the ?-macro is capable of cont,rolling rule firings in dynamically changing situations. For example, data received from sensors in real-time expert systems or from students in interactive tutoring systems are easily handled by ?-macros. Data transfer between ?-macros and rules can be realized by specifying the variable-bzndings. Variables in rules arc called rule variables, while in plans they are plan variables. Two kinds of data transfer are possible:

Figure 1 shows OPS5 rules [Forgy, 19811 to select 100 goods from a number of candidates. This example is not exceedingly complex, but employs rat her standard coding techniques already described in textbooks [Brownston c t al., 19851. However, since explicit/implicit controls are involved as follows, one can ima.gine the difficulty of maintaining programs when the techniques are frequently applied.

From plans t o rules: Control plans can restrict variable binding in rules. For example, the following ?-macro 'Research is underway t o implement PCMs on t h e t o p of C.

72

the other hand, if there is no executable rule and if the otherwise clause is specified, then even though ?-macros are contained, the select-macro evaluates the otherwise clause, and returns the value of the form. The rule selection macro is simple, but can represent the conventional production system interpreters. For example, the interpreter for the rules in Figure 1 can be expressed as follows: Plan-&: (loop (select ( ( ? pre-selection)) ( ( ? selection-heuristics)) ( ( ? post-selection)) (otherwise (return)) 1) This control plan repeatedly executes the three rules until no rule can be fired. Since select-macros can appear a t any place in the control plans, and any Lisp forms can appear in select-macros, we can easily extend conventional production system interpreters and invoke them from anywhere in the control plans.

restricts the value of the rule variable last to the value of form. (? selection-heuristics :last f o r m )

As a result, only rule instantiations with the variable binding of l a s t = f o r m are allowed to be executed. Thus, ?-macros can filter instantiations by restricting the binding of rule variables. From rules t o plans: Rules can bind plan variables to the values of rule variables. This approach can keep rules independent of control plans: rules do not return values, but plans can access values held in rules. One example is as follows. (let ((plan-variable *U*)) (? selection-heuristics :last plan-variable))

In this case, after executing selection-heuristics, the value of the rule variable last is transferred to the plan-variable. This data transfer is performed only when the plan-variable is unbound. (We indicate “unbound” by the special variable *U*.)

3.3

$-Macro The $-macro is introduced to abandon rule invocation when the conditions of the specified rule cannot, be satisfied. In this case, the $-macro returns nil. Its syntax is the same as that of the ?-macro. Procedural control of rule executions can be easily realized by usiug $-macros in Lisp. The followiiig two examples represent sequential and conditional rule executions respectively. (progn $-macro . . . $-macro) (cond ($-macro f o r m ) . . . ($-macro f o n n ) ) Since $-macros allow users to ut.ilize the control facilities of Lisp, various coding tricks t o embed control information into rules are no longer required. For example, the program shown in Figure 1 can be dramatically simplified: the pre/post-selection rules and the counter operations in selection-heuristics are replaced by the following plan. Plan-]: (dotimes (i 100) ($ selection-heuristics))

3.2

Plan Definition

When the rule base grows, the control plan becomes larger. The defplan-macro is introduced to decompose a large control plan into several modules. (defplan plan-name (1 (use rulesei-name . . .) form . . . ) Each defplan-macro defines a plan module. The rule invocation/selection macros can appear in the plan modules, when the related rulesets are declared a t the beginning of the defplan. The control plans defined by the defplanmacros work like Lisp functions; control plans and Lisp functions can invoke each other. In conventional tools, rulesets are used as units for executing rules as well as for storing rules. After introducing defplan, we can clearly separate the two roles: ruleset now represents a unit for storing rules and defplan defines a control plan unit. Thus, in our approach, the ruleset can contain the rules that are not t o be executed. This new feature enables users not only to incrementally debug rules, but also to develop large scale shared rule bases. Users can select necessary rules from the shared rule bases by describing the control plans for each application. As a result, the shared rule bases and the application programs can be developed and maintained independently.

Rule Selection

The production system interpreter tests the LIISs of multiple rules simultaneously and selects one executable rule through conflict resolution. This fundamental mechanism cannot be expressed by any combination of rule invocation macros. For viewing control plans as a natural extension of conventional production system interpreters, we created the rule selection macro (select-macro), which is influenced by the CSP guarded command and ulternative command.

4

Procedural Control Mechanism

Procedural control is achieved through a combinat,ion of which evaluates control plans, the Lisp interpreter (U), and the production system interpreter (PSI), which fires rules. Figure 2 represents the architecture of the UPPL approach, where two interpreters communicate with each other and cooperatively execute plans and rules.’ It is important to note that the WM belongs t o the PSI, and thus control plans cannot access the WM directly. This restriction is introduced to clearly distinguish the roles of control plans and rules.

(select (rule-invocation-macro [form] )

(rule-invocation-macro Cforml) [(otherwise [form]11) The select-macro selects one executable rule from specified rule-invocation macros. When multiple rules are executable, the select-macro requested the production system interpreter to choose one rule through conflicl resolution. However, if there is no executable rule and if the sclecfm.acro contains ?-macros, it waits [or data changes. On

2110wever, this does not mean the UPPL approach requires a multi-process environment. In a n actual implementation, the PSI is simply called from the LI. The extension of this archi-

tecture to the multi-process environment is discussed in [Ishida, 19891.

73

Lisp Interpreter

Production System Interpreter

1 Rule Invocatio

:select

Request

Filtering Memory

I

- - - -*Data Flow

-

Figure 3: Effect on the Number of Rules

I Conuol Flow

Figure 2: Control Architecture

ing of materials is precisely planned before execution. The shortcoming of this method is that a substantial volume of tutoring plans are required for implementing private lessons. CAIRNEY adopts the rule-based method, in which tutoring plans are written in production rules that adaptively select the teaching materials based on the students' levels of understanding. The CAIRNEY project started in 1984. After refining the rule base for two years, a prototype system called MASTERS was completed in 1986. The effectiveness of this system was confirmed by 32 students [Morihara e2 al., 19871. The project was continued and the CAIRNEY rule base has been rebuilt twice using different tools. Since various coding tricks were embedded into rules, CAIRNEY currently faces serious maintenance problems.

When the control plans are first invoked, the declared rulesets are loaded from the shared rule bases and compiled into a RETE network [Forgy, 19821. When evaluating the PCMs, the L1 requests the PSI to fire the specified rules. The PSI then executes one production cycle. After creating the conflict set in the Match phase, comes the Instantiation Filtering phase, which further restricts instantiations according to the rules and their variable bindings specified in the PCMs. Then the Conflict Resolution phase chooses exactly one instantiation. After executing the chosen instantiation in the Act phase, the PSI reports to the LI what rule was executed. Finally, the LI evaluates the subsequent control plan. However, if no instantiation remains after the Instantiation Filtering phase, the PSI simply repeats the production cycles. When data changes occur, they may affect the Match phase and may cause a rule firing. In t.he above architecture, the LI interrupts the PSI at each production cycle, but the overhead is not significant. This is because the RETE network is preserved by the PSI, and thus there is no overhead in the Match phase, which consumes 90% of the total execution time. Relat,ively small overheads exist in the Instantiation Filtering phase and in the data transfers between the LI and tlie PSI. On the other hand, since rules have been simplified, the number of production cycles or at least the cost of the Match phase is reduced. For example, when applying Plan-2, tlie execution time increases by 20%. However, when applying Plan-1, since rules in Figure 1 are significantly simplified, the total execution time is reduced by 10%.

5 5.1

5.2

Evaluatioii Results

The CAIRNEY rule base contains approximately 500 rules. To enhance the maintainability of the CAIRNEY rule base, we redescribed 370 rules, which were frequently executed, using the UPPL approach. The major results obtained from this experiment are summarized as follows:

Represenlatzon Overheads: After the redescription, the rule volume decreased from l0Okb to 74kb, while the newly created control plans occupied 20kb. Since the total volume of the CAIRNEY rule base did not increase, we can say there zs no representatzon overheads zn the UPPL approach. From the maintenance point of view, the control information, which was embedded in the whole rule base, was gathered and took up 20kb. This concentration improves the readability of both control plans and rules. Ran-tzme Overheads: We have evaluated the run-time overhead associated with the most frequently executed route of the CAIRNEY rule base. The route selects the teaching material to be presented next. Before the redescription, the route contained an average of 21 rule firings. After the redescription, PCMs are called 20 times, and the number of the rule firings was reduced to 9. This reduction almost overcomes the overall overhead of the UPPL approach. In total, the redescribed rule base can select the next teach-

Experimental Evaluation Problem Domain

We faced the same problem as XCON during the dcvelopment of the intelligent tutoring system CAIRNEY [Fukuhara et al., 19901. CAIRNEY is currently i n operation at several tens of NTT offices, and is planned to be introduced t o more than one hundred ofices i n the future. In most of the commercial tutoring systems, the order-

14

of production systems. While getting a new paradigm, production system users have been forced to describe the procedural knowledge in a declarative representat,ion form. We believe that the proposed approach will enable users to enjoy the benefits of the production system paradigm without any significant costs.

1

WlthOUt UPPL

1

Acknowledgment

\V~~~UPPL

The authors wish to thank Tsukasa Kawaoka, Ryohei Nakano and Kiyoshi Yoshida for their support during this work at NTT Laboratories.

References [Brownston et al., 19851 L. Brownston, R. Farrell, E. Kant and N. Martin, Programming Expert System in OPS5: A n Introduction to Rule-based Programming, Addison-Wesley, 1985. 1

2

3

4

5

6

7

8

9

[Forgy, 19811 C. L. Forgy, OPS5 User’s Manual, CS-81135, Carnegie-Mellon Universiiy, 1981.

10ormore

Number of Condition Elements and Actions /Rule

[Forgy, 19821 C. L. Forgy, “A Fast Algorithm for the Many Pattern/Many Object Pattern Match Problem,” Artzficial Intelligence, Vol. 19, pp. 17-37, 1982.

Figure 4: Effect on Rule Complexity

[Fukuhara el al., 19901 Y. Fukuhara, K. Suzuki, M. Kiyama and H. Okamoto, “Educational Assistant Expert System,” N T T R&D, Vol. 39, No. 3, pp. 421-428, 1990. [Georgeff, 19821 M. P. Georgeff, “Procedural Control in Production Systems,” Artificial Intelligence, 18, pp. 175-201, 1982.

ing material with less than 3% overheads. Though the overhead depends on applications, this experiment supports our expectation: the UPPL approach has no significant run-time overhead.

Maintainability En.hancement: Figure 3 illustrates the effect of redescription on the number of rules. The original 370 rules were reduced to 310 rules: 71 rules were eliminated and 11 rules were created. BO of the 71 rules contained only control information, and thus were replaced by the control plans. Moreover, the remaining 11 rules were deleted, though they contain declarative knowledge. This is because redescription reveals that the declarative knowledge in the rules was redundant: since the rules were fired in different contexts, the different control information was embedded into the rules. Thus, we can say that the UPPL approach not only concentrates the embedded C O ~ L ~ T O2I7 2fornaation into control plans, but also eliminates duplicated rules that often cause maintenance problems. Figure 4 represents the effect, of the redescription 011 the complexity of each rule. The number of condition/action elements were reduced in 42% of the remaining rules. Since the UPPL approach sin1plifies the complexity of each rule, the maintnzilability ofproduction system programs is enhanced.

6

[Hoare, 19781 C. A . R. Hoare, “Communicating Sequential Processes,” CACM, Vol. 21, No. 8, pp. 666-677, 1978. [Ishida, 19881 T. Ishida, “Optimizing Rules in Production System Programs,” AAAI-88, pp. 699-704, 1988. [Ishida, 19891 T . Ishida, “Coco: A Multi-Agent System for Concurrent and Cooperative Operation Tasks,” 9th A A A I Distributed Artificial Intelligence Workshop, pp. 197-213, 1989. [Miranker, 19871 D. P. Miranker, “TREAT: A Better Match Algorithm for AI Production Systems,” AAAI-87, pp. 42-47, 1987. [Morihara et al., 19871 I. Morihara, T . Ishida and H . Furuya, “Rule-based Flexible Control of Tutoring Process in Scene-oriented CAI Systems,” 3rd CAIA, pp. 207-212, 1987. [Soloway et al., 19871 E. Soloway, J. Bachant and K. Jensen, “Assessing the Maintainability of XCON-inRIME: Coping with the Problem of a VERY Large Rule-base,’’ AAAI-87, pp. 824-829, 1987.

Conclusion

[Stolfo, 19791 S. J. Stolfo, Automatic Discovery of Heuristics for Nondeterministic Programs from Sample Execution Traces, PhD Thesis, New York University, 1979. [Zisman, 19781 M. D. Zisman, “Use of Production Systems far Modelling Asynchronous Concurrent Processes,” Pattern Directed Inference Systems, Academic Press, pp. 53-68, 1978.

We have proposed the UPPL approach that uses procedural programming languages to control production systems. By adding small code segment to the existing Lisp and production system interpreters, we can easily realize a powerful control plan description language. Since control information is concentrated into control plans, rules can be used only t o describe declarative knowledge. During our experience with production systems, we have heard many complaints about the representation ability

75