Temporal management using relative time in knowledge-based process control

Pergamon PII:S0952-1976(97)00003-1

Engng Applic. Anif. lntell. Vol. 10, No. 3, pp. 269-280, 1997 © 1997 Elsevier Science Ltd

Printed inGreat Britain. All rights reserved 0952-1976/97 $17.00+0.00

Contributed Paper

Temporal Management Using Relative Time in Knowledge-based Process Control

B R I A N K N I G H T

The University of Greenwich, London, U.K.

J IXIN M A

The University of Greenwich, London, U.K.

(Received July 1996; in revised form December 1996)

In this paper, a knowledge-based approach is proposed for the management of temporal information in process control. A common-sense theory of temporal constraints over processes/events, allowing relative temporal knowledge, is employed here as the temporal basis for the system. This theory supports duration reasoning and consistency checking, and accepts relative temporal knowledge which is in a form normally used by human operators. An architecture for process control is proposed which centres on an historical database consisting of events and processes, together with the qualitative temporal relationships between their occurrences. The dynamics of the system is expressed by means of three types of rule: database updating rules, process control rules, and data deletion rules. An example is provided in the form of a life scheduler, to illustrate the database and the rule sets. The example demonstrates the transitions of the database over time, and identifies the procedure in terms of a state transition model for the application. The dividing instant problem for logical inference is discussed with reference to this process control example, and it is shown how the temporal theory employed can be used to deal with the problem. © 1997 Elsevier Science Ltd. All rights reserved

Keywords: Processes/events, knowledge-based systems, relative time, temporal databases

I. INTRODUCTION

Temporal reasoning as an integral part of a knowledge- based system is essential for many artificial intelligence applications, where one is interested not only in the representation of a present state, but also in the history of earlier states or a prognosis of future states. In particular, an appropriate understanding and treatment of time is necessary in many process-control systems, where the history of processes is an important factor in deciding operational control. A problem with conventional historical databases is that the volume of historical data required can become very large, and can lead to unnecessary inefficiencies. Many approaches have been proposed to model the temporal aspects of time-dependent systems, such as those of Jones and Mason (1980), of Ahn and Snodgrass (Ahn, 1986; Snodgrass and Ahn, 1986; Snodgrass, 1987), of Sripada

Correspondence should be sent to: Dr Brian Knight, School of Computing and Information Technology, The University of Greenwich, Woolwich. London SE18 6PF, U.K.

(1988), and of Knight (1992), etc. It is interesting to note that the underlying time models employed in all these systems are time-point-based; hence it is required that absolute time points, or absolute point-based intervals, must be associated with the time-dependent objects being addressed. However, a modelled world in the field of artificial intelligence often contains relative temporal knowledge. For instance, it may just be known that process A executed before process B, without knowing the exact times when they executed. Relative temporal knowledge such as this is typically derived from humans, where precise times are often not available, but where relative temporal relationships are. Many of the early modelling formalisms mentioned above neglect to account for this properly, and the resultant models are correspondingly restrictive.

As the importance of the time domain has become apparent, many other modelling techniques have been introduced, attempting to accommodate the characteristics of relative temporal information. For example, as an early attempt at mechanizing part of the understanding of relative temporal relationships within an artificial intelligence

E~a110:~-c 269

270 BRIAN KNIGHT and JIXIN MA: TEMPORAL MANAGEMENT

content, Kahn and Gorry's time specialist was developed (Kahn and Gorry, 1977) endowed with the capacity to order temporal facts in three major ways: (1) relating events to dates; (2) relating events to special reference events; and (3) relating events together into before-after chains. However the most influential work dealing with incomplete relative temporal information in the field of artificial intelligencey is probably that of J. E Allen. In Allen's time theory (Allen, 1981, 1983) intervals are taken as primitive time elements, and between time intervals there are 13 possible temporal relations, Equal, Before, Meets, Overlaps, Starts, Started- by, Duration, Contains, Finishes, Finished-by, Overlapped-by, Met-by and After, which may be formally defined in terms of the single primitive relation "meets" (Allen and Hayes, 1989).

The objective of this paper is to present a general knowledge-based temporal system for the efficient management of temporal histories of process-control systems, which allows control rules in terms of natural human forms of time expression. The system allows relative temporal knowledge based on Allen's temporal relations over intervals (Allen, 1981). However, in Allen's temporal logic points are definitely excluded, while only intervals with positive length are taken as primitive time elements. In some applications, Allen's system is not general enough to model all the temporal aspects. For example, it seems more natural to think of the recording/updating times of data as points, rather than as "very short intervals", i.e. "moments" (see Allen and Hayes' terminology; Allen and Hayes, 1989), as would be necessary in a pure interval-based system. Some more compelling examples have been given in Galton's critical examination to Allen's interval based system (Galton, 1990) which illustrate some weakness in excluding the concept of points. This paper will make use of a general theory of temporal constraints over intervals and points, developed from Allen's interval based temporal logic by the authors (Ma and Knight, 1994) as the temporal basis for the system. In fact, recently, some approaches have been proposed for handling relative temporal knowledge in process control, such as that of Crespo et al. (1994) and of Parthasarathy (1990). However, in the approach of Crespo et al., only time points are addressed as primitives for time representation, while time intervals are constructed out of time points. As Allen has argued in his series of papers (Allen, 1981, 1983, 1984) this treatment may lead to the so- called Dividing Instant Problem (DIP) (Parthasarathy, 1990) that is the problem of addressing intervals' ending-points. Additionally, those metric (or quantitative) constraints proposed in the system of Crespo et al. can only be used to represent a limited subset of Allen's disjunctive constraints between time intervals without needing to use disjunctive constraints between time points (Crespo et al., 1994). As examined by the authors in a previous paper (Ma and Knight, 1995), Parthasarathy's approach to the classification of temporal relations between events/activities is indeed very similar to that of Vilain (1982) in which some critical relationships between intervals (activities) and points (events) have not been satisfactorily addressed.

In the context of this paper, the term, event, will be employed to represent an instantaneous phenomenon with a zero duration, and the term, process, to represent a temporal phenomenon which lasts for a positive duration. Generally, both processes and events may be called occurrences. Section 2 presents a brief outline of the theory of temporal constraints (relations) over intervals/points, which will be used as the temporal basis of the system. Section 3 presents the architecture of the system, and the approach to information management. An illustrative example of the system as applied to process control is presented in Section 4. Finally, Section 5 presents conclusions.

2. TEMPORAL CONSTRAINTS

In a previous paper (Ma and Knight, 1994) an extension of Allen and Hayes' interval-based time theory (Allen and Hayes, 1989) has been developed. The extended temporal theory takes both intervals and points as primitive time elements on the same footing. This section gives an outline of this general temporal theory.

T is used to denote a nonempty set of time elements, and "duration", a duration assignment function from T to R~, the set of non-negative real numbers. A time element, t, is called an interval if duration(t)>0; otherwise, t is called a point. In this paper, "now" is used to denote the current time.

The primitive order over intervals/points is a relation termed "meets", which is axiomatised by the following axioms:

(AI) Vtt,t2,t3,t4 ~ T(meets(fi,t2)Ameets(fi,t3)Ameets(t4,t2) = > meets(t4,t3))

(A2) Vt~ T3t ' , t" ~ T(meets(t',t)Ameets(t,t")) (A3) Vt I,t2 ~ T(3t',t" ~ T(meets(t',tt)Ameets(fi,t"))

Ameets(t',t2) Ameets(tJ')) = > t~ = t2 (A4) Vfi ,tz ~ T(meets(fi ,t_,) = > (3t ~ TVt' ,t"

T(meets(t',fi)Ameets(t2,t") = > meets(t',t)Ameets(t,t'))

(A5) Vtt,t 2 ~ T(meets(tl,t2) = > duration(fi) > 0vduration(t_,) > 0)

(A6) Vtl,t2 e T(meets( ti,t2) = > duration( fi Gt2) = duration(t0 + duration(t2))

(A7) Vtl,t2,t3,t4 ~ T(meets(fi,t2)Ameets(t3,t4) = > meets(t,,t4) 7 3t ' ~ T(meets(fi,t')^meets(t',t4)) 7 3t" e T(meets(t3,f')Ameets(t",t2)))

where t~Ot2 denotes the ordered union of t~ and t2, and 7 represents "exclusive or".

The intuitive meaning of axiom (A1) is that the "place" where time elements meet is unique. (A2) preserves that every time element has at least one neighbouring time element preceding it, and another succeeding it. (A3) simply says that the time element between any two meeting places is unique. (A4) states that if two meeting places are separated by a sequence of time elements, then there is a time element which connects these two meeting places. Hence, by axioms (A3) and (A4), for any two adjacent time

BRIAN KNIGHT and JIXIN MA: TEMPORAL MANAGEMENT 271

elements, tL and t2, the ordered union of t I and t 2 may be written as t ~ t 2 . Axiom (A5) is based on the intuition that points will not meet other points, that is, between any two points, there is an interval. (A6) ensures that the addition operation, "G", over time elements is consistent with the duration assignment function, duration. Finally, axiom (A7} preserves the linearity of the time.

It has been shown in the previous paper (Ma and Knight, 1994) that all the other possible temporal relationships over intervals/points, analogous to those introduced by Allen for intervals (Allen, 1981), can be derived in terms of the "meets" relation. It is also proved that, under the above temporal axiomatisation, all the temporal constraints (relations) over intervals/points can be classified as in Table 1.

3. A R C H I T E C T U R E O F T H E S Y S T E M

The knowledge base of the system will be represented as a triad, (F, M, D), where F is a collection of occurrence

declarations, and M and D denote temporal and duration knowledge over the set of time elements related to K respectively. In particular, a historical database, suitable for process control will in general contain occurrence predicates representing events and processes, temporal predicates representing the "meets" relationships, and duration predicates representing the duration assignments, according to the following schema:

occurrences:

t empora l relation: duration assignment:

e v e n t i ( x l . i . . . . . x,,,i.i; ti)

processj(ytj . . . . . y,jj; tj) meets(t~,t2) duration(t, r).

N.B. In the above, M contains only the "meets" relation. Temporal knowledge may in fact exist in the form of any temporal relationship classified in Table 1. However, as mentioned in Section 2, each of those temporal relations can be derivatively defined in terms of the single "meets" relation.

Table 1. Classification of temporal constraints creation

Temporal Relation

equal

before

after

meets

met-by

overlaps

overlapped-by

starts

started-by

during

contains

finishes

Relating

point a to point b

a o

l ib

a o e b

a l l l i b

Not Applicable

Not Applicable

Not Applicable

Not Applicable

Not Applicable

Not Applicable

Not Applicable

Not Applicable

interval A to interval B

( ]A

[ IB

N A m B

i A i S

i A i B

E A i B

I I j, I IB

I I A I IB

B

I I A i S

m A

I JB

I I A ~ a

point a to interval A

Not Applicable

a l l

a o t n ~ } A

ae I

a@

( IA

Not Applicable

Not Applicable

all* I IA

Not Applicable

a o I I A

Not Applicable

interval A to point a

Not Applicable

~ A a o

a o ~ ) A

. . . . . LA a l l

! - - I A a l l

Not Applicable ~ A a • Not Applicable [ I B I I A

finished-by Not Applicable u k, Not Applicable I . . . . . . I A i s a t l

a ]A a l

Not Applicable

I IA a t l

IA a

Not Applicable

Not Applicable

Not Applicable


3.1. Inference on temporal knowledge

Deductive inference can be performed on the stored data, with reference to the underlying temporal theory as described in Section 2, so that any fact which can be proved from the axioms of the theory and the stored temporal database may be assumed true by inference. In this way, the axioms plus database may be viewed as a deductive system from which facts may be retrieved by inference.

In computer-based process control systems, information has to be stored as a discrete (finite) set making up the database. The consistency of the database is the key to the method of inference by resolution. The question may be asked: are the facts in the database temporally consistent according to the underlying theory, or not?

For simplicity of expression, the set of time elements related to a given collection of occurrence declarations, F, will be denoted as TF. An intuitive graphical representation of (Tv M, D) has been introduced by the authors (Knight and Ma, 1992) in terms of a directed and partially weighted graph. In this representation, time elements can be denoted as arcs of the graph, and the "meets" relation can be graphically shown by the node structure in the directed graph: meets(ti, tj) is represented by ti being in-arc and jt being out-arc to a common node. For the time elements with known duration, the corresponding arcs are weighted by their durations respectively.

The necessary and sufficient condition for the temporal consistency of (F, M, D) can be given as follows (Knight and Ma, 1992):

(F, M, D) is consistent if and only if there is a duration assignment over TF agreeing upon D, such that: for each simple circuit in the graph of (T~ M, D), the directed sum of weights is zero, and for any two adjacent time elements, the directed sum of weights is bigger than zero.

This consistency condition is similar to that given by Dechter et al. (1991) in their temporal constraint networks, where intervals are constructed out of points.

The key problem in evaluating a query over a database (F, M, D) is to test:

(a) For a given pair of time elements, t~ and tz, whether q(tt, t2) is satisfied, where q is one of the temporal constraints classified in Table 1.

(b) For a given time element, t, and a real number, r, whether duration(t, r) is satisfied.

N.B. In this paper, duration(t, r) will be used as identical to duration(t)=r. Hence, knowledge like "the duration of time (interval) t is greater than 10 sec" may be expressed by:

Similarly, "the duration of time (interval) t' is greater than 2 and less than 4" may be expressed by:

duration( t,r)Ar> 2Ar<4

o r

2 < duration(t) < 4.

In principle, to infer q(tj, tz) is true, it is only necessary to prove that, ~q(t~, t2), the converse constraint to q(t L, t2), is inconsistent with the database, by means of the consistency checker given above. It has been shown that the temporal relations given in Table 1 are mutually exclusive to each other (Ma and Knight, 1992, 1994). Hence, for example, if i represents an interval and p a point, it is known that precisely one of the temporal relations in the set:

Q = {before, meets, started-by, contains,

finished-by, met-by, after}

must apply for i and p. Hence for any q EQ:

-~q(i,p)c:~ql(i,p) V q2(i,p) v... V q6(i,p)

where {q~, q2 . . . . . q6} U {q}=Q. Hence, to show q(i,p) it is simply necessary to show that q'(i, p) is inconsistent for q' =q~, q2 . . . . . q6. For instance, started-by(/,p) may be shown by means of showing that before(/,p), meets(/,p), contains (i,p), finished-by(/,p), met-by(/,p) and after(/,p) are all inconsistent with the database.

For the testing of duration(t,r), of course, if duration(t,r) can be inferred from the database, it is definitely satisfied. However, it may be the case that it only be possible to infer that duration(t,r) is consistent with the database or not, by means of using the consistency checker. If it is consistent, it may be concluded that duration(t,r) is a possible instance of the duration assignment for time element t; otherwise, it is impossible for time element t to last the duration r.

The general treatment of the temporal constraints can then be handled by conventional logical operations, i.e. disjunction and conjunction, over the results of individual constraint evaluations.

It is interesting to note that knowledge about the duration assignment may imply further temporal relationships. For instance, with the following temporal knowledge:

during(t',t) Aduring(t',t)A-~overlaps(t',t')A-~ovedaps(t",t')

it cannot be inferred that t' and t" meet each other. However, given the additional duration assignment knowledge below:

duration(t,r)Ar> 10 duration(t, 10)^during(t',4)Aduring(t",10)

or simply by it may be inferred that

duration(t) > 10. meets(t',t")vmeets(t",t').


3.2. Process control based on the historical database

The control system may be divided into three parts:

(1) updating the database, as new events occur; (2) control of the process based on the current database;

and (3) management of the database so as to maintain effi-

ciency.

Each of these is discussed in turn below.

3.2.1. Updating the database The following rule syntax is used to express which

actions are to be performed on event occurrences under given conditions:

(U) On Event If Conditionj Then Action~.

In this case, the action is to update the database according to the new current event, e.g. asserting the event (or some other facts) into the database. This will involve adding the event predicate, and updating the temporal relations to reflect the new current situation. For example, if the system is currently undergoing process~(Y; T'), and an event, evenh(X; T), occurs, which does not affect the process, the updating rule will be:

On eventl(X; T) If processl(Y; T'),

during(now, T')

Then assert eventl(X; T), during(T, T'), after(now, T)

{i.e. processt is the currently undergoing process }

{i.e. evenh occurred "during" process~, and "before" the current time }

3.2.2. Control of the process Process control rules take the production rule format:

(C) If Condition 2 Then Action2

where the condition is defined over the temporal database, and the actions are process-control commands. For updates, however, the triggers are specified as the arrival events, process-control rules may be triggered at any time during process intervals. For example, they may be triggered after updates, or according to some polling scheme.

3.2.3. Management of the database For the logical control of processes, rules for updating the

database and for control actions are all that are needed. However, for real-time operation, the efficiency of evaluation of rule conditions is also of importance. An algorithm for the evaluation of temporal queries has been given in Knight and Ma (1992), and Vilain (1982), Vilain and Kautz (1986) and Van Beek (1989, 1992) have examined the complexity issues relating to interval/point algebra, show-

ing that the computational complexity of the constraint-evaluation algorithm may be prohibitive for practical systems involving large temporal databases.

Theoretically, since both intervals and points are addressed, the computational complexity of the inference mechanism will be the same as that given in Van Beek (1989, 1992). However, for process-control applications, the database does not have to be very large. In fact, for a particular application, data may be dynamically deleted from the database wherever the deletion does not affect the process-control rules. In a previous paper, Knight (1993) has examined the possibility of encoding rules to effect automatic data deletion, for a limited representation of historical data as time-stamped tuples. The same method may be used to encode a data-deletion strategy for a particular process-control application, as condition-action rules:

(D) If Condition 3 then Action3

where the action is to retract terms from the database. Once again, these rules will be activated during a process interval, with priority after update and process-control rules.

The objective of the deletion strategy embodied in rules of the form D, is to keep the size of the database small, without detriment to the control. In effect, if the database is in fact kept finite, this gives a finite state system. State- based control is a well-known technique for dealing with temporal aspects of process histories. However, these states are normally synthesised by the design engineer, whereas here they are the result of a data-deletion strategy derived from an examination of the control rules.

4. AN ILLUSTRATIVE EXAMPLE: KNOWLEDGE- BASED CONTROL OF A PASSENGER LIFT

The conceptual model illustrated in Fig. 1 shows a chain of time elements representing a simple scenario for part of the temporal history of an elevator in service: tt, t2, t3, t4, ts, t6, t7, t 8 and tg. Each of these elements meets the succeeding one. The chain expresses the fundamental belief that the motion of the lift can be described as a sequence of non- overlapping states: moving up over time t~, reaching floor 1 at time point t2, remaining stationary at floor 1 over time t3, starting again in the up direction at time t4, and so on. Some of these time elements in this example are time points (which are denoted as thick bar arrows), e.g. t2 and t4, and others are time intervals (which are denoted as thin bar arrows), e.g. t~ and t 3. Meanwhile, there are also asynchro- nous events occurring, such as summons and destination button presses. In the absence of any exact time stamps, these events may only be related to elements in the main chain, by means of qualitative relations outlined in Table 1. For example, h0 is "during" t~, and "before" t 2. The current time element, "now", is shown in the figure as "during" t 9 - an interval over which the lift is stationary.

It may be argued that the model presented in Fig. l does not in fact represent the lift process accurately, since the lift


tl

Up

tlO

1 ,up

Reach, floorl Reach floor2 Reach foor3 I t I

I

t21 t4 t6l t7 t8 k ~_ ,~ t3 t5

Stationary Start up Up Up

tll

2,down /

/

i ! /

summons button events

t12 t13

foor 3 . . . . floor 5

destination button event

Now

t9

Stationary

Fig. 1. Conceptual model of the passenger lift.

should be required to be going up or down, or stopped, at all points of time. However, e.g. in Fig. 1, the lift is not specified as going up or stopped at time t2. This is in fact the problematic dividing instant question (Parthasarathy, 1990). The problem derives from a need to apply inferential logic at any time. However, at time t2 it is neither "stopped" nor "not stopped", so logical inference does not apply.

There are two ways to resolve this problem. The first is to specify properties on time points according to some scheme, and the second is to abolish time points completely, as in Allen's system (Allen, 1981, 1983; Allen and Hayes, 1989). The temporal scheme outlined in this paper allows both of these solutions, and they are considered in turn here.

One simple method for assigning properties to the end- points is to take all intervals in the chain as meeting each other, with end points overlapping the later interval. Thus each interval is "open" at the right and closed at the left, as shown in Fig. 2(a). According to this, t2 would be counted as "stopped", t4 and t 6 as "moving up", etc. This will certainly work in some applications, although it seems arbitrary: more designed for the user's needs than as an essential property of time. Also, in places it seems rather counter- intuitive. For example, the scheme in Fig. 2(a) shows t4 as "moving up", when common sense indicates that at this point it is not moving at all.

Alternatively, properties may be assigned to end points according to a scheme relating to the application. For example it might be decided that all stopped intervals are closed at both ends, as in Fig. 2(b). This scheme is more in line with intuition about points such as t4.

The second alternative is to adopt Alien's solution, that is to abolish time points from the model completely. In this case, there is a problem as to how the concept of events such

as "arrival at floor 1" are modelled in the system. Since communication between the scheduler and external equip- ment (motor controller, floor sensors, summons and call buttons) is centered around these events, they are crucial to the modelling process. However, since all of the external sources operate on a fundamental clock cycle, they can at best communicate a message that a point event happened within a small interval of time. The system may accordingly be modeled as in Fig. 3.

Here, the arrival at floor 1 is modelled as a small interval t 2, which overlaps both tl and t 3. This diagram expresses exactly the knowledge of the system according to received information. It represents knowledge that the lift was travelling up during h, and that it was stationary over t3, and that this change of state took place sometime during t2.

The main objective of Allen's scheme is to bypass the question of modelling the open and closed nature of time intervals, and hence to overcome the dividing instant problem. Allen's contention is that nothing can be true at a point, for a point is not an entity at which things happen or are true (Allen, 1983). However, time-points are an integral part of human commonsense reasoning, and as Galton shows in his critical examination of Allen's interval logic (Galton, 1990) excluding time points may lead to inade- quacy in reasoning about continuous change. The problem involved with reference to time points is also illuminated by Knight and Ma (1992) in terms of the example of a ball thrown vertically into the air, and it is shown that the situation cannot be satisfactorily expressed in terms of Allen's interval-based logic.

In the temporal system outlined in Section 2, however, points and intervals are treated on an equal footing. One of the advantages of this is the freedom to interpret the elements t2, t4, etc. as points or small intervals as desired,


since the inference mechanisms are unaffected by this distinction in practice. Indeed, it is shown (Knight and Ma, 1992) that if inference by resolution is used, two points which meet each other will be regarded as inconsistent, whereas an interval meets/met-by another interval or a point will not. An example of two "meeting" points in the application studied here would be, for instance, that a summons event came immediately after a stop event. However "immediately after" for two time points is not meaningful for this application. If it were known that the two points are not the same, then it would also be known that there was an interval between them. Hence nothing is lost by maintaining that any two events are either the same, or if distinct then separated by a time interval.

For general treatment, all time objects are simply referred to as time elements, and the interpretation of t 2, t4 . . . . . etc. as points or intervals is left as an open question. Corre- sponding to the scenario illustrated in Fig. 2(b), the following descriptions are employed:

motor(starts-up/starts-down/stops/passes, floor-number, time) Representing the event that the lift starts to move up/

down from, or stops at, or passes the specified floor, at the given time;

summons(floor-number, up/down, time)

Reach floorl Sta~ up

X

tl t2~f t3 ~t4~

Up Stationary

Now

Reach floor2 Reach floor3 I I

I

t5 ~ t7 t8~ t9

Up Up Stationary

tl0 tll -1~

1 ,up 2,down

t12 t13

Des.floor 3 Des.floor 5

a) Intervals closed on left-end and open on right-end

floor I Start up Reach floor2 Reach -, /

t I t2~ t3 t7

Up Stationary r Up r Up

tl0

1 ,up t12

Des. floor 3

tll

2,down

t13

Des. floor 5

b) All "stopped" intervals closed on both ends

Fig. 2. Assignation of properties to end-points.

Reach floor3 I

t8'~+ t9

Stationary

t l

u p

a r r i v e d at f l o o r 1 d u r i n g t h i s i n t e r v a l

/ "

t 2 ,+"/

r

t3

v

s t o p

Fig. 3. t2 overlaps both t t and t3.


Representing the event that a summons is placed at the specified floor for the lift to go up or down, at the given time;

destination(floor-number, time) Representing the event that someone inside the lift has

pressed a button for a destination floor, at the given time;

motion(floor-numberl, floor-number2, up/down/stationary, time) Representing the process that the lift is moving up/

down between two adjacent floors, or stationary at the specified floor (with floor-numberl =floor-num- ber2), over the given time interval; N.B. For convenience of expression, we shall take that motion(F, F+ 1, up/down, T)=motion(F+ 1, F, up/ down, 7).

is made). The correspondingly general rule may be given in the following form:

U1. On event summons(F, up, 7) If during(now, Tt) Then Assert

summons(F, up, 7), during(T, Tl), after(now, 7).

Example 2. The lift is signalled as going up. In this case it is necessary to add another time interval, i~5, which comes immediately after the stationary time interval t9 and indicates that the motion is now up. The current time must also be updated to indicate that the lift is now going up. Hence, a general rule may be given in the following form:

The scheduler has no direct information about the description processes. Rather, this must be inferred from events and other processes. For instance, in Fig. 2(b):

motion(l, 1, s t a t i o n a r y , / 3 ) :

motion(l, 2, up, ts):

motion(2, 3, up, tT):

motion(0, 1, up, t~), motor(stops, 1, t2), meets(h, t2), meets(tl, t3) motor(starts-up, 1, t4), meets(t4, ts); motion(l, 2, up, ts), motor(passes, 2, t6), meets(ts, t6), meets(ts, t7)

In this way, the scenario illustrated in Fig. 2(b) can be represented by the database in Table 2, together with the temporal knowledge in Table 3.

4.1. Updating the database

As new sensor data comes in, the database must be changed to reflect it. In the above database, the current time is during an interval over which the lift is stationary. No knowledge yet exists as to what will happen to the lift next. But as new events happen, the knowledge represented in the database must be updated. Some examples of the updates required in response to different types of event are given below.

Example 1. A summons call for going up is received from floor 4 while the lift is stationary on floor 3. In this case, it is necessary to add a time point (h4) referring to this call, and to add the information that it occurred during the process that the lift was stationary. It is also necessary to update the current occurrence, "now", so that it is after the summons call event (which it will be by the time the update

U2. On event motor(starts-up, F, 7) If motion(stationary, F, T),

during(now, T) Then Assert

motion(F, F+ 1, up, T'), meets(T, T'), during(now, T').

Retract during(now, 7).

N.B. Symmetrically, if the lift is signalled as going down, the corresponding rule will be:

U21 .

On event motor(starts-down, F, T) If motion(stationary, f, 7),

during(now, T) Then Assert

motion(F, F-l, down, T'), meets(T, T'), during(now, T').

Retract during(now, 7).

Example 3. The lift closes the contact at floor 4, and then stops to serve the summons call. It is necessary to add a time, /16, for the "reaching foor" event. The current time

Table 2. Database representing Fig. 2(b)

motion(0, 1, up, t~) motion(l, 1, stationary, t3) motion(l, 2, up, t 5) motion(2, 3, up, tT) motion(3, 3, stationary, tg)

motor(stops, 1, t2) motor(starts-up, 1, t4)

motor(passes, 2, tr) motor(stops, 3, ts)

summons(2, down, tt0) summons(l, up, hi)

destination(3, t~2) destination(5, t o)


Table 3. Temporal knowledge representing Fig. 2(b)

meets(h, t2) during(ho, h) meets(h, t3) during(t., ts) meets(t~,/4) during(tl2, tJ meets(t 4, ts) before(t., tL~) meets(ts, tr) during(h3, tls) meets(ts,/7) before(h3, ill) meets(tT, ts) during(now, tg) meets(tT, tg)

unserviced_summons(F, D, T):- summons(F, D, L), {i.e. there was a summons

not(serviced(F, D, T2), before(L, T2), before(T> T))

call at time L}

{i.e. it has not been serviced at any time/'2 between Tt and T}.

may be updated by adding an interval/17, over which the lift is currently stationary, with tit succeeding tt5 immediately:

U3. On event motor(stops, F, T) If meets(L, T),

during(now, L) T h e n Assert

motion(F, F, stationary, T2) meets(L, T2), during(now, T2).

Retract during(now, L).

4.2. Properties on the temporal data base

The database represents a complete history of lift events in a qualitative manner (i.e. no absolute times are recorded). The knowledge is being continually updated, as new sensor events occur. The current state of the database is determined by knowledge of the relationship between the current time "now" and other time elements. For example, a predicate which indicates that there is an unserviced destination call outstanding for a floor F at time T may be defined by:

unserviced_destination(F, T):- destination(F, L)),

not(motion(F, F, stationary, Tg, before(L, T2), before(T2, T))

{ i.e. there was a call at time L}

{i.e. the lift has not stopped at floor F at any time/'2 between L and T}.

Also, one may define a predicate which indicates whether floor F has been serviced in the direction D (up or down) over a given time T as:

serviced(F, D, T):- motion(F, F, stationary, T)

motion(F, F+ 1, D, L), meets(T, L)

{i.e. the lift has stopped at the floor for time T}

{ i.e. the lift left floor F in the direction D}.

4.3. Process-control rules

For this example, it is assumed that there are two possible commands to be issued, to start moving in direction D, or to stop at a floor F:

start_move(D) stop_at(F).

Control logic for these decisions may be given by a set of condition-action rules whose condition is determined by the current database. For example, a strategy may be imple- mented whereby the lift goes up until no more outstanding calls are above it, whereupon it goes down until there are no more outstanding calls below it, as follows:

C1. If

Then C2. If

during(now, T), motion(F, F, stationary, T), not(motion(F, F+ 1, down, T1)

meet(L, T),), unserviced destination(G, T2) G>F

start_move(up).

during(now, T), motion(F, F, stationary, T), not(motion(F, F+ l, down,L)

meet(L, T),), unserviced_summons(G, _, r~)) G>F

Then start_move(up).

{the lift is currently stopped at floor F} {the lift was previously going up, or has just started}

{there is an un-serviced destination call for a higher floor}

{ the lift is currently stopped at floor F} {the lift was previously going up, or has just started }

{there is an un-serviced summons call from a higher floor}

Then, one can define a property indicating that there is an unserviced summons call outstanding for a floor F in direction D at time T by:

Similar rules may be given for start_move(down). As another example, rules can be expressed for deciding

when to stop at a floor:


C3. If

Then C4: If

Then

during(now, 73, lift(F, F+ 1, up, T),

unserviced_ destination(F+ 1, t)

stop_at(F+ 1).

during(now, 73, lift(F, F+ 1, up, 73,

unserviced_ summons(F+ 1, up, 73 stop_at(F+ 1).

{the lift is moving up between floor f and F + l } { an un-serviced destination call for floor F + I }

{ the lift is moving up between floor F and F + I } {an un-serviced up call from floor F+ 1 }

According to the above process-control rules, the development of the database corresponding to the scenario illustrated in Fig. 2(b) may be traced in Table 4.

4.4. Managing deletion from the database

To illustrate the idea of managing deletions from the database, some data-deletion rules for the lift problem are given as follows:

After floor F is serviced in direction D, it is no longer necessary to keep the corresponding summons calls:

D1. If

Then Retract

summons(F, D, 73, serviced(F, D, T0, after(T1, 73

summons(F, D, 73.

After the lift has stopped at a floor, the earlier destination calls for that floor can be forgotten about:

D2. I f destination(F, 73,

motion(F, F, stationary, T~), after(TI, 73

Then Retract destination(F, 73.

When the lift is moving up/down, all its previous motion processes and motor events can be ignored. This does not apply when the lift is stationary, since rules C 1 and C2 need two succeeding predicates--it makes a difference whether the lift stopped after going up, or after going down for the strategy embodied in these rules:

D3. I f

Then Retract D4. If

motion( . . . . . . T), motion(F, F+ 1, up/down, TI), after(Ti, T)

motion( . . . . . . T).

motor( . . . . 73, motion(_, _, up/down, T~), after(Ti, 73,

Then Retract motor( . . . . 73.

When the lift is stationary at a floor for a time longer than a given time duration R*, that is, there is no further destination or summons call within a given time, all its previous motion processes and motor events can be ignored:

D5. I f

Then Retract D6. If

motion( . . . . . . 73, motion(F, F, stationary, T 0, after(T, 73, duration(T, R), R>_R *

motion( . . . . . . 73.

motor( . . . . 73, motion(F, F, stationary, T 0, after(Tl, 73, duration(T I, R), R>_R *

Then Retract motor( . . . . . . 73.

A set of rules such as those given above can considerably reduce the size of the database. They ensure that the database will be bounded in size during typical operation.

Table 4. Further development of the database representing Fig. 2(b)

Process Motor events Call events Process control

motion(0, 1, up, h)

motion(l, 1, stopped, t 3)

motion(l, 2, up, t0

motion(2, 3, up, tT)

motion(3, 3, stopped, t~)

motor(stopped, 1, t2)

motor(started-up, 1, t4)

motor(passed, 2, t6)

motor(stopped, 3, ts)

summons(l, up, rio) C4=>stop_at(l)

destination(3, tl2) CI =>start(up)

destination(5,q3) summons(2, down, h~)

C3 =>stop_at(3)


Stopped-up State 1 l Stopped-down State

destination/summons call for/from

a higher floor

no more un-serviced

destination/summons calls for/from a higher floor

Idle

State

destination/summons call for/from

a higher floor

reach the required floor

Moving-up [.,,

State f"

no m o r e

un-serviced destination/summons calls for/from a lower floor

destination/summons call for/from a lower floor

reach th, requied floor

destination/summons call for/from a lower floor

Moving-down State I

Fig. 4. Transition model.

Hence, the system is in fact a finite state system. As discussed in the previous section, state-based control is a well-known technique for dealing with temporal histories, where the states are synthesised by the design engineer. It can be shown that the method applied in this paper results in the state transition model which would be expected from a more intuitive analysis, by identifying the following set of states:

"Idle" state:

motion(F, F, stationary, T), during(now, T), not(unserviced_destination(_, _)), not(unserviced_summons( . . . . . )).

"Stopped(up)" state:

motion(F- 1, F, up, TO, motion(F, F, stationary, T2), meets(Tl, T2), during(now, T2).

"Stopped(down)" state:

motion(F, F+ 1, down, T~), motion(F, F, stationary, T2), meets(T~, T2), during(now, T2).

"Moving-up" state:

motion(F, F+ 1, up, T), during(now, T)

"Moving-down" state:

motion(F, F+ 1, down, T) during(now, T).

With these state identifications, the events and actions described above give rise to the transition model illustrated in Fig. 4.

5. CONCLUSION

This paper presents the logical structure of a knowledge- based temporal system for process control and management using relative temporal relations. An extended time model based on both processes (intervals) and events (points) is employed as the temporal basis of the system. Control rules are defined over a temporal database representing the temporal history of the process. An approach to the efficient management of temporal history is proposed by means of rules embodying a strategy for the selective deletion and updating of the temporal database. A comprehensive example of the approach as applied to process control of a lift scheduler is provided, illustrating the logical structure and the development of a working model. As managed in other proposals, some structure about temporal states of data, such as transaction time, validity time, and user defined time, and so on (Knight and Ma, 1994) may be introduced. Of course, this would need some more complex temporal reasoning process.

REFERENCES

Ahn, I. (1986) Towards an Implementation of Database Management Systems with Temporal Support. IEEE, CH2261-61861000010374501.00, pp. 374--381.

Allen, J. E (1981) An interval-based representation of temporal knowledge. Proc. 7th Int. Joint Conf. on AI, pp. 221-226.


Allen, J, F. (1983) Maintaining knowledge about temporal intervals. Communication of ACM, 26, 123-154.

Allen, J. E (1984) Towards a general theory of action and time. Artificial Intelligence, 23, 123-154.

Allen, J. E and Hayes, P. J. (1989) Moments and points in an interval-based temporal-based logic. Comput. lntell. (Canada), 5(4), 225-238.

Crespo, A., Botti, V,, Barber, E, Gallardo, D. and Onaindia, E. A. (1994) Temporal blackboard for real-time process control. Engng Applic. Artif. Intell., 7(3), 255-266.

Dechter, R., Meiri, I. and Pearl, J. (1991) Temporal constraint networks. Artificial Intelligence, 49, 61-95.

Galton, A. A. (1990) Critical examination of Allen's theory of action and time. Artificial Intelligence, 42, 159-188.

Jones, S. and Mason, P. (1980) Handling the time dimension in databases. Proceedings of International Conference on Databases, Univ. of Aberdeen. British Computer Society, pp. 66-83.

Kahn, K. and Gorry, G. A. (1977) Mechanising temporal knowledge. Artificial Intelligence, 9, 87-108.

Knight, B. A. (1992) Deductive approach to temporal databases. The Computer Journal, 35, A395-A402.

Knight, B. (1993) Information loss in temporal knowledge representations. The Computer Journal, 36(2), 128-236.

Knight, B. and Ma, J. A. (1992) General temporal model supporting duration reasoning. AI Communication Journal, 5(2), 75-84.

Knight, B. and Ma, J. A. (1994) Temporal database model supporting relative and absolute time. The Computer Journal, 37(7), 588-597.

Ma, J. and Knight, B. A. (1994) A general temporal theory. The Computer Journal, 37(2), 114--123.

Ma, J. and Knight, B. (1995) Building temporal constraints into knowledge bases for process control--an examination. Engineering Applications of Artificial Intelligence, 8, 97-99.

Parthasarathy, S. (1990) Building temporal constraints into knowledge bases for process control. Engineering Applications of Artificial Intelligence, 3, 204--209.

Snodgrass, R. T. (1987) The temporal query language Tquel. ACM Transactions on Database Systems, 12(2), 247-298.

Snodgrass, R. T. and Ahn, I. (1986) Temporal Databases. IEEE, 0018-9162/86/0900-0035, pp. 35-42.

Sripada, S. M. A. (1988) Logical Framework for Temporal Deductive Database. Proceedings of the VLDB, Los Angles, pp. 171-182.

Van Beek, P. (1989)Approximation Algorithms For Temporal Reasoning. Proc. 11th IJCAI, pp. 1291-1296.

Van Beek, P. (1992) Reasoning about qualitative temporal information. Artificial Intelligence, 58, 297-326.

Vilain, M. B. (1982) A system for reasoning about time. Proceedings of AAAI, 1, 197-201.

Vilain, M. B. and Kautz, H. (1986) Constraint Propagation Algorithms for Temporal Reasoning. Proc. 5th AAAI, pp. 377-382.

Documents

Temporal management using relative time in knowledge-based process control