an intelligent database for engineering applications

ELSEVIER PII: SO954-1810(96)00033-7

Artificial Intelligence in Engineering 12 (1998) 1 - 14 0 1997 Elsevier Science Limited

Printed in Great Britain. All rights reserved 0954-1810/98/$19.00

An intelligent database for engineering applications

Yue Dong & A. Goh

Division of Software Systems, School of Applied Science, Nanyang Technological University, Nanyang Avenue, Singapore 639798

(Received 30 November 1995; revised version received 10 May 1996; accepted 23 August 1996)

Many engineering applications need to response to unpredictable events in a timely manner. Active database systems provide an event-driven rule processing capability to meet this requirement. In this paper, we present an intelligent database which integrates an object-oriented database (OODB) with an expert system, CLIPS. The paper describes the design and implementation of the rule manager of this intelligent database. In the rule manager, event-condition-action (ECA) rules are represented as first class objects of the OODB. A rule definition language (RDL) has been developed to manipulate ECA rules in a declarative way. A graphical user interface (GUI) also supplies a template to interactively define, delete, update and check ECA rules. Detection of time events, method events, absolute events and composite events is supported by the rule manager. The CLIPS inference engine is used to control condition evaluation and action execution after an ECA rule is triggered. Finally, a typical workflow application is used to illustrate the functionality of the system. 0 1997 Elsevier Science Limited.

Key words: object-oriented database, active database, expert systems, rules.

1 INTRODUCTION

Many engineering applications such as computer integrated manufacturing (CIM) and computer-aided design and manufacturing (CAD/CAM) are event-driven. Other typical applications include network management, com- modity trading, air-traffic control, hospital monitoring systems and real-time plant control. Common to all these applications is the need to respond in a timely manner to unpredictable or external events. Conventional database systems deal with such situations by polling the databases at fixed time intervals or by embedding the situation monitoring capabilities and the corresponding actions in the application code. In the first approach, it is very difficult to decide how long the interval should be. Depending on the application, polling could result in a degradation of the database performance. On the other hand, if the interval is too long, the event may be missed. The second approach violates the principles of modular- ity in software engineering. In large software systems, possible inconsistencies among the applications tend to arise as each programmer independently embeds functions into their code. Moreover, these applications tend to be hard to maintain, since code modification in one routine results in a need to update other related routines.

Active database systems overcome these shortcomings by efficiently supporting automatic situation monitoring.

In other words, the database system is able to monitor a situation represented by an event and one or more conditions. When the event occurs and the conditions evaluate to true, the corresponding actions are executed. Active database systems which are event-driven knowledge systems provide an event-driven rule capability to meet this requirement. The rules used for supporting active capability are expressed as an event-condition- action (ECA) paradigm’ which are termed production rules in expert systems. Active database systems can recognise specific situations and react to them without direct explicit user or application requests. The general form of an ECA rule is illustrated in Fig. 1.

In addition, many engineering applications benefit

from using object-oriented databases (OODB) as their database platforms.273 For example, the object concept of an OODB simplifies the task of designers as well as applications developers, and allows representation of an arbitrarily complex structure as a recursively nested object. Encapsulation, inheritance, polymorphism and extensibility enable the hierarchy semantics of database schema to be easily represented. Since it is necessary to control and co-ordinate the different tasks of a design process in a collaborative design environment, long multi-user transactions of an OODB play an important role in engineering database applications. Many OODBs also support schema evolution management which is

2 Y. Dong, A. Goh

on Event if Condition do Action

l The Event of an ECA rule determines when the rule should be evaluated.

l The Condition of an ECA rule determines whether the action should be executed.

l The Action of an ECA rule determines how to react if the condition is evaluated true.

Fig. 1. The general form of ECA rules.

specially useful in engineering environments. Non- traditional applications also require version management for comparison and optimisation. This requirement is supported by many OODBs.

Unfortunately, most commercial OODBs are passive; they only manipulate data responding to external requests from users or application programs. Hence, the current trend is to incorporate active features into OODB. Many researchers are working on the extension of conventional passive databases with features which support automatic response to particular circumstances. The result of making a database system active not only eases the implementation of time-constrained applications, but also readily extends the database with enchanced data modelling facilities.

Expert systems have the deductive capability to support production rule processing and to deduce new knowledge or new data from them. An expert system usually consists of the following three parts. First, there is a knowledge base which contains a representation of heuristic and factual information. Secondly, a set of deductive rules is made up of a representation of production rules. These consist of a condition part (called left hand side - LHS) and an action part (called right hand side - RHS), where the action is executed if the condition is satisfied. They are always expressed in the following form: if (LHS) then (RHS). Finally, there is an inference engine, which decides how and when to apply certain production rules, together with a working memory (termed Fuct_List) necessary for keeping track of data, goals and intermediate goals. With respect to the needs of rule support in databases, it appears that there is a scope to combine expert system technology with databases and to let both systems benefit from each other.

This paper outlines the ongoing work of making an OODB active by integrating expert system technology with an OODB. This work is carried out at the Nanyang Technological University to support CAD/CIM engineering environments. A prototype modelled after a layered active OODB has been developed based on the integration of ObjectStore OODB and CLIPS expert system. In this paper, we present the architecture of the prototype and highlight five issues related to the design and implementation of active databases. These are the specification of rules into RuleBase which is a collection of all rules, event detection, rule control, condition evaluation and action execution. Finally, an example application is used to illustrate the functionality of the

system. Our prototype is currently running on HP and Sun UNIX workstations.

2 RELATED WORK

There are different approaches aimed at the integration of active concepts with OODBs. They differ in the type of architecture adopted, the way rules are defined, the kinds of events supported, the expressive power of the event specification languages and the method of integrating the rule model with the underlying object oriented (00) model.

0dek6 was developed at AT&T Bell Laboratories. It is an integrated active OODB implemented using the O++ language, a database programming language based on C++. Ode presents three types of events: basic events, logical events and composite events. Basic events include object state events, method execution events, time events and transaction events. Rules in Ode are expressed as constraints and triggers. They are both expressed within a section of a class definition, and there is no way to change a rule definition at run time. Also, the order of rule firing is very difficult to implement. It has some facilities for constraint and trigger management. At the same time, rules cannot be shared or reused. For example, if a rule is applicable to two different classes, it has to be declared explicitly in both classes. The Ode rule language is very powerful and includes facilities for temporal information. Finite automata form the basis for detecting composite events. SAMOS7-9 is a layered active OODB at the University of Zurich, Switzerland. Active support is placed on top of the ObjectStore OODB. In SAMOS, events and rules are all expressed as first class objects. It supports primitive events and composite events. Primitive events include method events, time events, transaction events and abstract events. Two types of rules are defined within SAMOS: class-external and class-internal. Composite events are detected using petri nets. It uses a rule definition language (RDL) to define events and rules. The RDL requires pre-compiling into Cf+ code. Since condition objects and action objects are pointers to some C++ functions, the whole system requires recompilation after some condition objects or action objects are changed. REACH’oz1’ is a project at Technische Hochschule Darmstadt, Germany. One prototype uses O2 as a platform to implement the 00 rule concept. Another prototype uses open OODB as its underlying OODB. The latter is an integrated active database.

An intelligent database for engineering applications 3

In REACH, events and rules are treated as first class objects. It uses a graphical user interface (GUI) to define events and rules. The conditions and actions are C++ functions. T&s 12!13 is a layered active OODB project at the University of Vienna. It is implemented on top of a commercial OODB, Gemstone. The components of a rule are specified as follows: an event selector, a condition, and an action. Events and rules are expressed as first class objects. One of its main goals is to explore semantics of 00 concepts in the definition of triggers, such as inheritance, hierarchy and overriding. Currently, it only supports method events.

3 A PROTOTYPE OF AN ACTIVE DATABASE

3.1 The architecture of an active database

The architecture of our prototype is shown in Fig. 2. In the architecture, a rule manager which couples the ObjectStore OODB with the CLIPS expert system is used to implement the active concepts. The goal of our work is not to build a new OODB system. The aim is to supply an active environment within an existing OODB model. 0bjectStore*“i6 is a commercial OODBMS. It extends C++ with database functionalities, such as persistence, a query processor, indexing clustering and transaction mechanisms. Therefore, it can provide the rule manager with basic DBMS functionalities and 00 behaviour. In addition, it supplies mechanisms for long multi-user transactions, nested transactions, version and

evolution management. All of these make ObjectStore a suitable underlying database platform for engineering applications. On the other hand, CLIPS’7>18 is a forward chaining rule-based language and is a widely used expert system tool. In order to integrate expert system technology into ObjectStore, CLIPS was extended to form a CLIPS-ObjectStore interface library. CLIPS consists of three components: an interface engine, a set of production rules and a Fact-List. The inference engine has overall control of production rule execution based on the Fact-List. The second component contains all production rules which are constructed using CLIPS statements. Finally, the Fact-List is a knowledge base which contains global memory data. A fact in the Fact-List decides which rules should be executed and when.

There are three major advantages of integrating CLIPS into our prototype. First, a condition and an action of an ECA rule can be expressed via the CLIPS statements. If C?+ code is used to define all ECA rules, recompiling the whole system cannot be avoided even though only the condition or action parts have been changed. Since CLIPS supplies an interpreted environment, recompilation is not required. Secondly, the CLIPS inference engine can be used to control both condition evaluation and action execution after an event occurs and is detected. Finally, the CLIPS Fact-List can be used to transfer parameters from an event to the corresponding condition. In the composite event detector, the CLIPS Fact-List can also be used to pass parameters of a primitive event to a composite event.

/ \

Application Programs USN User Clock < ,..,.

Event -

CLIPS Inference Engine i -- ObjectStore OODBMS \ 2: \

I

Fact-List RuleBase : DataBase

Fig. 2. The architecture of an active database.

Y. Dong, A. Goh

Signal: Application The Rule Execution Model

Primitive Event Occurs and is Detected

Rule Controller

Composite Event

Action Executor Ruletransaction

Fig. 3. The rule execution model.

The rule execution model is based on event detection. cause any composite events to trigger. This is The steps enumerated in Fig. 3 are elaborated as follows: done by the rule controller component.

(1)

(2)

(3)

(4)

(5)

When a signal (clock, application or user) causes a primitive event to trigger and the event is detected by the rule manager, a message is sent to the rule controller component. If the triggered event is a method event, its parameters are passed to the condition objects or its composite event objects by the CLIPS Fact-List. The corresponding condition and action are checked against the RuleBase by the rule controller component. If there are more than two rules to be fired, the rule controller uses their priorities to decide which of the rules should be fired. The corresponding condition and action are sent to the condition evaluator and action executor components respectively in the form of CLIPS facts. This work is done inside the rule controller component. The condition part of the rule is evaluated in the condition evaluator component. This is done inside the ruletransaction (Fig. 11, later) in order to implement the EC-Coupling modes. The evaluation of conditions on some objects may trigger other events. If the condition is satisfied, the action is fired by the action executor. This is also done inside the Ruletransaction in order to implement the CA-Coupling modes. The execution of actions on some objects may trigger other events. After the action execution, the composite event detector will be invoked to check if this event can

3.2 Rule specification

In our prototype, ECA rules and their components are considered as first-class objects. This means that they can be grouped in a class-hierarchy and can be inserted, deleted and modified like other objects. All these objects together constitute the RuleBase. Rules and their components are implemented as objects thereby allowing reuse of each object. For example, in the RuleBase, a rule object has three pointers which point to an associated event object, a condition object and an action object respectively. Thus, an event can be used for multiple rules. this is similarly true for a condition and an action. On the other hand, some events may be made up of composite events that are used by a rule. Thus, multiple events can be used for a single rule. The relationship between rule objects and event objects is therefore many-to-many.

Our prototype supplies two ways of specifying ECA rules. A graphical user interface (GUI) supplies a template to interactively define, delete, update and check ECA rules. A rule definition language (RDL) has also been developed to manipulate ECA rules in a declarative way. The RDL is a part of the CLIPS/ ObjectStore Interface.

The GUI is developed using Motif on UNIX. An example of using the GUI is shown in Fig. 4. Through the GUI, a user can define rules and associated events, conditions, actions into the RuleBase without needing to


know how the objects are stored in ObjectStore. Also, a user can dynamically update, delete and check these objects from the RuleBase at run time thereby avoiding heavy recompilation of the system.

The RDL is an extension of the CLIPS language and runs in an interpreted environment. A user can manipulate a rule object anytime without compiling. In contrast to the GUI, the RDL is a convenient way to process a large number of ECA rules in batch mode. In the prototype, each ECA rule object has three pointers pointing to its corresponding event object, condition object and action object. Therefore, the prototype treats an ECA rule as a complex object pointed by an event object, a condition object and an action object. Thus, some statements need to be developed to describe these objects.

For example, one typical statement, CreateRuleBase is used to create the RuleBase schema. The DeJneRule statement is used to create a rule object with attributes of RuleName, EventName, ConditionName, ActionName, Priority, EC Coupling and CA_coupling.

3.3 Event detection

In OODBs, all operations are carried out by sending a message to objects through methods. Any message sent to an object may be associated with a method event. Hence, method events can be defined on a class name and a method name. In order to detect method events, a technique called wrapping is employed. This technique consists of replacing the original method by a new one that contains a call to the operation raise event which is in charge of detection and a call to the original method. This new method is called a method wrapper. Its contains

a call to the original method, while the wrapped method is renamed. A translator (termed Wrapper) to translate an original class to a wrapped class has been developed. This is done after creating a method event. Another translator (termed De Wrapper) to translate a wrapped class back to an original class has also been developed. This is always done after deletion of a method event. For example, if we want to define a method event named Event1 before get-state method of machine class, the procedure shown in Fig. 5 can be used.

Time events are specified as an explicit point in time such as 1996.01.12:12:00:00. In order to detect a time event, an application program interface (API) enable- TimeDetection is run before each application program. It is responsible for retrieving all time events from the RuleBase and enabling them to monitor the system clock in parallel with the application programs. An example program that uses time events is shown in Fig. 6.

Absolute events, which are defined by users according to their specific semantics, need not be detected. These events notify the rule management component by explicitly raising a message in the application programs. An example application that uses an absolute event named Event1 is shown in Fig. 7.

A composite event is made up of two or more events and operators such as And, Or and Sequence. The detection of composite events is based on finite automata. It uses a step by step method to detect composite events. If an occurred event is used by a composite event, then mark the associated sub-primitive attribute of the composite event. The composite event will only occur when both sub-primitive attributes are marked. The composite event detector component is responsible

MethodName

Endl-ime

ActionClause

Fig. 4. A sample of a rule specification by the GUI.

e(char machine-states);

load_machine(char identifier);

Y. Dong, A. Goh

xtern enableRuleManager (char *EventName);

Wrapper =s3=B=s3 Translator

De Wrapper C=ctc=c= Translator

e(char machine-states);

L load_machine(char identifier); load_machine(char identifier);

load_machine(char identifier) { enableRuleManager(“Event1”); ORIGINAL_load_machine(identifier);

Fig. 5. An example of using a method event by Wrapper/DeWrapper.

@include . . . 1. :xtem enableTimeDetection(); . main0

t enableTimeDetection(); . .

i

Fig. 6. An example of using time events.

#include . . . . . extem enableRuleManager(char *EventName); I.. main0

enableRuleManager(“Event1”);

Fig. 7. An example of using an absolute event.

0 Transient State

1

o--i3 0 so

E2

Or (El ,E2)

for this task. In Fig. 8, El and E2 represent time events, method events, absolute events or other composite events.

3.4 The rule controller

The rule controller is responsible for receiving the triggered event information, searching the corresponding condition and action, and passing them to the condition evaluator and the action executor, respectively. Finally, the composite event detector will be invoked by the rule controller in order to determine if the triggered event would result in a composite event. Figure 9 summarises the relationship between each component.

After an event is triggered and has been detected, a message is sent to the rule controller component via EnableRuleManager (char *EventName). Using the triggered EventName, the rule controller first checks the corresponding RuleName, ConditionClause, ActionClause and CA_Coupling from the RuleBase and inserts them into the CLIPS Fact-List in the form of facts. These

E2

El

Sequence(E1 ,E2)

Fig. 8. Detectiw of comnosite events.

o-


Composite Event

Detector

Rule Controlik * Component

_________.......______.._..~- i CLIPS _ _ _ _.__._ .

Condition Evaluator

Component d I

&SOL j

i Action Executor * Component

Fig. 9. The task of the rule controller.

Condilion_Facl < ( Condition cConditionClause> <RuleName>)

/-(Action 1 CActionClause , > <RuleName>)

Aclion_Fad (Action 2 <ActionClause

(......)

2> <RuleName>)

L(Action n <ActionClause n> <RuleName>)

CA_Coupling_Faci <(CA_Coupling <CA_Coupling> <RuleName>)

Fig. 10. The forms of three kinds of facts.

&em void CheckRuleBase(); lass Ruletransaction: public os_transaction {

lublic: static os_transaction *begin(os_int32 t-type) {

return(os_transaction::begin(t_type));

1 static void commit(os_transaction *trs) {

CheckRuleBaseO; os_transaction::commit(trs);

1 static void abort(os_transaction *trs){

CheckRuleBaseO; os_transaction::abort(trs);

I

Fig. 11. The Ruletransaction.

facts, which are termed Condition_Fact, ActionyFact and CA_Coupling_Fact (showing in Fig. 10) respectively, can invoke the Condition Evaluator.

In the rule manager, ECA rules can be evaluated or executed either immediately in a triggering transaction (in immediate coupling mode), or in a delayed mode at the end of a triggering transaction (in deferred coupling mode). A new class Ruletransaction is detined to implement the deferred coupling. The Ruletransaction class is derived from the ObjectStore os_transaction class. It defines the methods for the transaction operations begino, commit0 and abort0 by overriding the Object Store end-transaction statements: os_transaction:: begino, OS_ transaction::abort() and os_transaction:: commit(). These statements always check first to determine if there is a condition or an action from the RuleBase which has been marked. If there is, then the condition is evaluated, possibly followed by an action execution. After rule evaluation or execution, the corresponding condition or action will be unmarked again. An API named void CheckRuleBase(), shown in Fig. 11, is responsible for this task.

I Condiiion_Fad

CA_Coupling_Fect

I . .._......._._........ : Ruletransaction :

ACtii”~F.WIS :.....................

RUl&aSe DataBase

Fig. 12. The tasks of condition evaluator and action executor.

8 Y. Dong, A. Goh

Condilion_Tru_Facl -c

(Condition is true <RuleName>)

Fig. 13. The form of Condition_True_Fact.

3.5 The condition evaluator and action executor

The condition evaluator is responsible for receiving the Condition_Fact and CA-Coupling Fact from the rule controller component, and for sending Condition-True_ Fact to the action executor component (if the condition has been evaluated true). The relationship between the components is shown in Fig. 12.

The condition evaluator continuously monitors whether a Condition_Fuct has been inserted by the rule controller. If there is, the fact is executed. The result of evaluation depends on an ECA rule’s EC-Coupling mode and Condition_Fuct. If the EC-Coupling mode is not immediate, the work of inserting Condition-Pact, Action-Fact and CA_Coupling_Fact must wait until the end of triggering transaction. Therefore, the condition evaluator is invoked just before the end of triggering transaction. The condition evaluator always checks whether there a Condition_Fact and a corresponding CA_Coupling_ Fact (shown in Fig. 10) in the Fact-List. After a successful check, and if the Condition Fact is evaluated true, a Condition_True_Fuct (shown in Fig. 13) will be inserted into the CLIPS Fact-List. The Condition_True_Fact is used to invoke the action executor component. The insertion is done either immediately or at the end of the triggering transaction, depending on the CA_Coupling Fact. After the condition evaluation, the Condition_Fact% retracted.

The action executor is responsible for receiving the Action-Fact from the rule controller component and is triggered by Condition_True_Fact (shown in Fig. 13). It is also responsible for firing the action in CLIPS. The processes have been shown in Fig. 12.

The action execution of an ECA rule is carried out inside CLIPS. The process depends on its CA-Coupling mode and the Action-Fact inserted by the rule controller. If the CA_ Coupling mode is not immediate, the execution of Action_ Fact will wait until the end of the triggering transaction. The action executor checks for the Action_Facts inserted by the rule controller and its corresponding Condition_Tnce_Fact from the condition evaluator (Condition is true (RuleName)) in the Fact_ List. After a successful check, it will execute the Action-Fact statements. After each Action-Fact execution, the Action-Fact is retracted.

One issue in the rule execution is rule conflict. This arises because one event may trigger more than two rules. In the rule manager, the problem is solved using priorities. Since the rule manager always inserts the Action-Fact and Condition_Fact of the rule with highest priority into the CLIPS Fact-List, the highest priority rule is always fired. One point to note is that if either CA_Coupling or EC_Coupling of a higher priority rule is Defer, and both CA_Coupling and EC_Coupling of a lower priority rule are Immediate, the lower priority rule will be fired first.

4 ACTIVE DATABASE APPLICATION DOMAINS

Workllow management is an application domain of active databases that is rapidly gaining importance. A workflow application,” as shown in Fig. 14, is chosen as a typical application requiring rule management. It is assumed that there are three resources, namely Machine-A, Machine-B and a robot. In order to produce a final product, a part from the storage must be processed by Machine-A before Machine-B. The robot is responsible for loading and unloading both machines. A buffer area is used to store intermediate parts. Only two intermediate parts are allowed to be stored in the buffer. The machine cannot be interrupted once it starts work on a part.

The model can be presented by entities in ObjectStore C++ classes. In this model, there are four important entities: part, machine, buffer and Robot. Definitions of the four entities which contains six kinds of activities (or events) are given in the Appendix. These six activities are listed in Table 1.

A part from state ‘Unprocessedpart’ to state ‘Finalpart’ must undergo six activities in a sequential manner. Each activity constitutes a step in the model. The steps together with changes to each entity are depicted in Fig. 15.

In order to achieve a better performance, it is possible to identify three processes to run in a parallel fashion. There are Machine-A, Robot and Machine-B processes (illustrated in Fig. 16). The processes Machine-A or Machine-B continuously monitor the queues Q-Run-A or Q-Run-B respectively. If signals are recived, the corresponding activities Part.Run_Machine_A() or Part.Run_Machine_B() are invoked. At the end of each activity, a signal would be sent to the queues Q_UnLoad_A or Q_UnLoad_B to invoke the Robot.UnLoad CA-Part’, ‘Machine-A’) or Robot. UnLoad (‘A-Part’, ‘Machine-B’) activity. The process robot is made up of four kinds of activities: Load-A, UnLoad_A, Load-B and UnLoad_B. These activities will be invoked when there are signals in the queues Q-Load-A, Q_UnLoad_A, Q-Load-B, or

Unprocessed part Buffer Final part

Fig. 14. A typical workflow application.


Table 1. The description of events

Activities (events)

Part.Run_Machine_A() Part.Run_Machine_B() Robot.Load(‘A Part’, ‘Machine A’) Robot.UnLoadrA_Part’, ‘Machine A’) Robot.Load(‘A Part’, ‘Machine Bq Robot.UnLoadFA_Part’, ‘Mach&e-B’)

Description

The Machine-A is processing a part The Machine-B is processing a part The Robot loads a part to the Machine-A The Robot unloads a part from the Machine-A The Robot loads a part to the Machine-B The Robot unloads a part from the Machine-B

Robot.Laad(“A_Part”.“Macbine_A”) Part.Rttn_Macbinc_A() Robot.UnLoad(“A_Pan”,“MaEhinc_A”)

“Rest”->-Work’ The Part State : “Pre_Machine_A”->

The Put sur : The Part State : “Po,C_“uhl”e_*“-,‘B”rrcr‘

“Start”->“Pm_Mrhinc_A” ‘Post_Machine_A” - - - The Par, .%.a :

Machine-A State : Tbe Pan state : “*_Pm_Rocrnor->‘ReEt” “Rest”->‘A_Psn_UnproceJsed” “A_Put_Unprocessed”-> Bvrfcr Nwntw

Robot Stale : “A_Pm,_Processcd”

Robot.UnLoad(“A_Pan”.“Mochinc_A”) Pm.Run_Machinc_B() Robot.Load(“A_Part”.“Machinc_B”)

Fig. 15. Activities depicted as sequential steps.

I

Process Flow

BI-

Signal Flow

ShineA

UnLoad M

rl

Load Ma I ineB

ineB

ieB

Machine-A Process Robot Process Machine-B Process

Fig. 16. An illustration of three parallel processes.

10 Y. Dong, A. Goh

start

li i=l

(-1 Machine-A Process

1 Part.Run_Machine_B()

Q_Run_B = C?_Run_B -1 Q_UnLoad_B = Q_UnLoad_B + 1

i = 1+1

Robot.UnLoad(A_Part. “Machine_A”)

Machine-B Process Robot Process

Fig. 17. The algorithms of the three processes.

Q-&Load-B, respectively. At the end of each activity, signals would again be sent to corresponding queues. The processes Machine-A and Machine-B will be terminated after all parts have been processed. After the last part passes through the Machine-B process, a signal STOP will be raised to terminate the process Robot.

The scheduling algorithms of each process are given in Fig. 17. It is assumed that there are N parts to be processed.

There are some important characteristics in this model. Several activities need to be processed sequen- tially. Parts must be processed one at a time. Therefore,

for the same part; a serial process is required. However, for different parts, concurrency may exist. There are some resource conflicts in the model. If both of the machines are waiting to be loaded, then a conflict arises. After an activity Robot. UnLoad(‘A_Part’, ‘Machine-A’), the robot can load either Machine-A or Machine-B. In order to ensure a part that has been processed by Machine-A can be taken over by Machine-B, the activity Robot.Load(‘A_Part’, ‘Machine-B’) is accorded a higher priority than the activity Robot.Load(‘A_Part’, ‘Machine-A’). Therefore, in the Robot process, the Q-Load-B is always scanned first after an activity Robot.Unload(‘A_Part’, ‘Machine-A’). There are mutual


An Action Objecl

An Action Object

Fig. 18. The rules in the case study.

12 Y. Dong, A. Goh

ActionName

ActionClause

“A_UnLoad_A” “ChsngeQ Test Robot Q_UnLoadA (- (LoadQ Test Robot Q_UnloadA) I)) Change Tcsl Robot Q_UnLoadB (+ (LoadQ Test Robot Q_UnloadB) I,) ChangeQ Ten Robot Q_UnLosdB (+ (LoadQ Test Robot Q_UnloadB) I),”

ActionName

ActionClause

“A_UnLoad_A” “ChmgeQ Test Robot Q_UnLoadA (- (LosdQ Test Robot Q_UnloadA) I)) ChangeQ Test Robot Q_UnLoadB (+ (LoadQ Test Robot Q_UnloadB) 1))”

ActionName

ActionClause

“A_UnLoad_B” “ChmgeQ Test Robot Q_U”LoadB (- (LoadQ Teat Robot Q_UnlondB) I)) ChangeQ Test Robot Q_UnLoadA (+ (LoadQ Test Robor Q_UnlmdA) I)) ChangeQ Test Robot Q_UnLoadB (+ (LoadQ Test Robot Q_UnloadB) I,)”

ActionName

ActionClause

“A_UnLoad_B” “ChangeQ Test Robot Q_UnLoadB (- (LoadQ Test Robot Q_UnlosdB) I)) ChsngeQ Test Robot Q_UnLoadA (+ (LoadQ Test Robot Q_UnloadA) I,)”

Fig. 19. Changes to two ActionClauses.

exclusions in the model too. Activities Robot.Load (‘A-Part’, ‘Machine-A’), Robot.Load (‘A-Part’, ‘Machine-B’), Robot.UnLoad (‘A-Part’, ‘Machine-A’) and Robot.UnLoad (‘A-Part’, ‘Machine-B’) are mutually exclusive since the robot can service only one activity at a time. Moreover, since only one part can be processed on a machine at a time, Robot.Load (‘A-Part’, ‘Machine-A’), Part.Run_Machine_A() and Robot. UnLoad (‘A-Part’, ‘Machine-A’) are also mutually exclusive. This case is similar to that of Robot.Load (‘A-Part’, ‘Machine-B’), Part.Run_Machine_B() and Robot. UnLoad (‘A-Part’, ‘Machine-B’). Therefore, there are only five pairs of activities that can run in parallel. They are Part.Run_Machine_A() and Part.Run_ Machine-go, Part.Run_Machine_A() and Robot.Load (‘A-Part’, ‘Machine-B’), Part.Run_Machine_A () and Robot.UnLoad (‘A-Part’, ‘Machine-B’), Part. Run_ Machine-B{) and Robot.Load (‘A-Part’, ‘Machine-A’), Part.Rur_Machine_ B() and Robot.UnLoad (‘A-Part’, ‘Machine-A’). The three processes are event-driven. If the state of a machine is ‘Rest’, then the machine cannot run (the rules: ‘R_CheckA’ and ‘R_CheckB’ shown in Fig. 18).

For a given part, Machine-B can run only after Machine-A has fmished with it. Thus, each event can be achieved or triggered by an existing situation. In Fig. 18, the Rules ‘R_RunA’, ‘R_RunB’, ‘R_LoadA’, ‘R_LoadB’, ‘R UnLoadA’ and ‘R_UnloadB’ are defined as event- d&en. For example, ‘R_RunA’ may be triggered by event ‘E-Load’ which is defined before the method ‘Load’ of the class ‘Robot’. Some cases may cause deadlock. The system will be deadlocked if there are two intermediate parts in the buffer and the robot is unloading a part from Machine-A while Machine-B is running somewhat later than Machine A.

The policy-in this model is represented by six ECA rules: R_LoadA, R_RunA, R_UnLoadA, R_LoadB, R-Rung, and R_UnLoadB (shown in Fig. 18). The policy determines the order of each activity in the model. Since each condition and action is expressed in an RDL interpretative statement, the policy can be dynamically adjusted by changing the six ECA rules through the GUI or RDL. Therefore, our system is very flexible. For example, the ActionClauses of A_UnLoad_A and A_UnLoad_B are changed as shown in Fig. 19.

Load Machine A

I-““”

-) Process flow --* Control flow

Load Machme A 1 w

Run Machine A

I

UnLoad Machmc A 7 ,_.’ .‘.V

Run Machme A 1

UnLoad Machme A i

r ,....’ Mak;; + . . . . . . . . . . . . . . . . . . . . . . . . . Load Machine B

Load Machine A B . . . . . . . .

r

. . Run Machine B

Run Machine A Run Machine B

. . . ..&l.n+md Mnchme B

r

1 . . . .

7

i ‘..,

UnLoad Machmc A Load : Y_,

I

UnLoad Machmc B ;.., Machmc ‘._,_ 1

A . . . . . . i...:::,. Load Macbinc A

I Run Machine A

r

: __

I ‘.‘...

Load 7

Load Machine .

I Machine ‘._ B Run Machine A

8:

I Load

Run Machine B 1

Machine : A

1

Policy (a) Policy (b)

Fig. 20. The comparison of two policies.


After the changes, each step in the activities of the workflow is exactly the same as the normal sequence (shown in Fig. 15). However, the disadvantage of this policy is that activities Part.Run_Machine_A() and Part.Run_Machine_B() cannot proceed in parallel. Nevertheless, deadlock can be avoided. The comparison of the two policies is shown in Fig. 20. Therefore, the best policy can be achieved by dynamically adjusting ECA rules repeatedly.

This illustrates that the policy governing an application can be very flexible. This is achieved by dynamically changing the rules through the GUI or RDL.

5 CONCLUSION

In this paper, expert system technology is integrated into an OODB to support ECA rules. A prototype of a layered active OODB which is built on top of an existing OODB is presented. Since ECA rules and their components are treated as first-class objects, they can be specified dynamically and independently of application programs. A user can specify ECA rules through a GUI or a RDL. The condition part and action part of each ECA rule are stored as CLIPS interpretation statements and this avoids recompilation after the ECA rule is changed. Detection of time events, method events, absolute events and composite events is supported. Our design seamlessly integrates rule inferences into the OODB to control the both condition evaluation and action execution.

A typical workflow example was chosen to show that the active OODB platform can have practical application in industry. Two policies (sequential and parallel), were compared to highlight the flexibility of the rule manager. In both policies, the activities are event-driven. The steps comprising these activities are defined by ECA rules. The workflow system benefits from the active OODB platform by allowing dynamic adjustment of policies in order to achieve the best performance.

We are investigating other ways to specify ECA rules through the use of the EXPRESS language, which is part of the STEP2’ effort. After ECA rules have been specified in EXPRESS, a translation to RuleBase will be carried out.

ACKNOWLEDGEMENTS

We wish to thank Mr Lim Seng-San from the Gintic Institute of Manufacturing Technology, Nanyang Tech- nological University for his many ideas which influenced our prototype design and implementation. We also thank Dr He Yibo from the School of Applied Science, Nanyang Technological University for his help during the testing stage.

REFERENCES

1. Dayal, U., Blaustein, B., Buchmann, A. et al., The HiPac Project: Combining Active Databases and Timing Constraints. ACM SIGMOD Records, 17(l), March 1988, pp. 51-70.

2. Kappel, G. & Vieweg, S., Database requirements for CIM applications. Journal of Integrated Manufacturing Systems, December 1994, 5(4/Q 48-62.

3. Kim, W., Banerjee, J., Chou, H. T. & Garza, J. F., Object oriented database support for CAD. Journal of Computer- Aided Design, October 1990, 22(8), 469-79.

4. Gehani, N. & Jagadish, H. V. Ode as an active database: constraints and triggers. Proc. of the 17th International Conference on Very Large Data Bases, Barcelona, September 1991, pp. 327-36.

6.

7.

8.

5. Gehani, N., Jagadish, H. V. & Smueli, O., Event specification in an active object-oriented database. Proc. of the 1992 ACM-SZGMOD International Conference on Management of Data, San Diego, California, June 1992, pp. 81-90. Gehani, N. & Jagadish, H. V., Active database facilities in Ode. IEEE Bulletin of the Technical Committee on Data Engineering, December 1992, 15( l-4), pp. 19-22. Gatziu, S., Geppert, A. & Dittrich, K. R. Integrating active concepts into an object-oriented database system. 3rd International Workshop on Database Programming Languages, Naflion, August 1991. Gatziu, S. & Dittrich, K. R. SAMOS: An active object- oriented database system. IEEE Quarterly Bulletin on Data Engineering, December 1992, 15(1-4) 23-6. Gatziu, S. & Dittrich, K. R. Events in an active object- oriented database system. In Rules in Database Systems, ed. N. Paton & M. Williams. Workshops in Computing, Springer-Verlag, September 1993, pp. 127-42. Buchmann, A. P., Zimmermann, J., Blakeley, J. A. & Wells, D. L., Building an integrated active oodbms: requirements, architecture, and design decision. Proc. of the 11th International Conference on Data Engineering, Taipei, Taiwan, IEEE Computer Society Press, March 1995.

9.

10.

11

12.

13.

14.

15.

16.

17.

18.

19.

Buchmann, A. P., Deutsch, A. & Zimmermann, J., The REACH Active OODBMS. Proc. of the 11th International Conference on Data Engineering, Taipei, Taiwan, IEEE Computer Society Press, March 1995. Kappel, G., Rausch-Schott, S., Retschitzegger, W. & Vieweg, S., TriGSs,,- active object-oriented workflow management. Proc. of the 27th Hawaiian International Conference on System Sciences, 1995. Kappel, G., Rausch-Schott, S., Retschitzegger, W. & Vieweg, S., TriGs: making a passive object-oriented database system active. Journal of Object-Oriented Pro- gramming, July/August 1994, 7(7/8), 40-5 1. Lamb, C., Landis, G., Orenstein, J. & Weinred, D., The ObjectStore database system. Communications of the ACM, October 1991, 34(10), 50-63. ObjectStore Design, Inc., ObjectStore User Guide V3.0. January 1994. ObjectStore Design, Inc., Programming with ObjectStore V3.0. February 1994. Software Technology Branch, Lyndon B. Johnson Space Center, CLIPS Reference Manual Volume Z, Basic Programming Guide, Version 6.0. June 2nd 1993. Software Technology Branch, Lyndon B. Johnson Space Center, CLIPS Reference Manual Volume ZZ, Advanced Programming Guide, Version 6.0. June 2nd 1993. Zhou, M. & Dicesare, F., Petri Net Synthesis for Discrete Event Control of Manufacturing System, Kluwer Academic Publishers, Dordrecht, 1993.

14 Y. Dong, A. Goh

20. National Institute of Standards on Technology, The Express Language Reference Manual. ISO-DIS 10303- 11, Production Data Representation and Exchange-part 11, 1992.

APPENDIX

(I) The Part class in the model

class Part{ char *Identifier; char *State;/* ‘Start’, ‘Unprocessed_A’,

‘Processed_A’, ‘Bulfer’, ‘Unprocessed-B’,

‘Processed-B’, ‘Final

public: Part(const char *Identifier, const char *State); void -PartO; char *Get_Identifier(); void Set_Identifier(const char *Identifier); char *Get-State@ void Set_State(const char *State); void Run_Machine_AO; /* Attached with Rules:

R_RunA and R_CheckA */ void Run_Mactie_B(); /* Attached with Rules:

R_RunB and R_CheckB */ 1;

(II) The Machine class in the model

class Machine { char *Identifier; I* ‘Machine-A’, ‘Machine-B’ */ char *State; /* ‘Rest’, ‘A_Part_Unprocessed’,

‘A_Part_Processed’, ‘Work’

*I public:

Machine(const char *Identifier, const char *State); void -Machine(); char *Get_Identifier(); void Set_Identifier(const char *Identifier); char *Get_State(); void Set_State(const char *State);

1;

(III) The Robot class in the model

class Robot { char * Sdte; /* ‘Work’, ‘Rest’ char * Start-Place; char * Final-Place; int Q-Load-A; int Q-Run-A; int Q_UnLoad_A; int Q-Load-B; int Q-Run-B; int Q_UnLoad_B;

*I

public: Robot(char *Statel, char *Start-Place, char

*Final-Place, int Q-Run-A; int Q-Load-A, int Q_UnLoad_A, int Q-Load-B, int Q_Run_B, int QUnLoad_B);

void NRobot(); char *Get-State@ void Set_State(const char *State);

char *Get_Q_Load_A(); void Set_QLoad_A(const int Q-Load-A); char *Get-Q-Run-A@ void Set_QRun_A(const int Q-Run-A); char *Get_Q_UnLoad_A(); void Set_Q_UnLoad_A(const int Q_UnLoad_A); char *Get_QLoad_B(); void Set_QLoad_B(const int Q-Load-B); char *Get_Q_Run_BO; void Set Q Run_B(const int QRun_B); char *Get_QUnLoad_B(); void Set_QUnLoad_B(const int Q_UnLoad_B);

char *Get_Start_Place(); void Set_Start_Place(const char *Start-Place); char *Get_Final_Place(); void Set_Final_Place(const char *Final-Place);

Load(char *Par_Identilier, char *Final_Place); /* Attached with Rules: R_LoadA and R_LoadB

*/ UnLoad(char *Part_Idenlilier, char *Start-Place);

/* Attached with rules: R_UnLoadA and R_UnloadB */

. . .

1;

(IV) The Bu$izr class in the model

class Buffer { char *Identifierl; /* The Identifier of the First Part

in the Buffer *I char *Identifier2; /* The Identifier of the Second

Part in the Buffer *I int Number; /* The current number of parts

in the Buffer /*O< =Number< =2

public: Buffer(const int Number, const char *Identifier 1,

const char *Identifier2); -Buffer(); char *Get-Identifier 10; void Set-Identifier 1 (const char *Identifier 1); char *Get_Identifier2(); void Set_Identified(const char *Identifier2); int Get_Number(); void Set_Number(const int Number);

1;

an intelligent database for engineering applications

Documents