Introduction to Intelligent Elevator Control Based on EVALPSN

Introduction to Intelligent Elevator Control Based on EVALPSN Kazumi Nakamatsu1 , Jair Minoro Abe2 , Seiki Akama3 , and Roumen Kountchev4 1

2

University of Hyogo, Himeji, Japan [email protected] Paulista University, University of Sao Paulo, Sao Paulo, Brazil [email protected] 3 University of Tsukuba, Tsukuba, Japan [email protected] 4 Technical University of Sofia, Sofia, Bulgaria [email protected]

Abstract. In this paper, we introduce the basic idea of single-car/singleshaft elevator control based on EVALPSN. Car operation in the elevator system is logically verified by the EVALPSN representing the car operation properties. Keywords: elevator control, defeasible deontic reasoning, logical verification, annotated logic program, EVALPSN.

1

Introduction

We have already developed a paraconsistent annotated logic program called Extended Vector Annotated Logic Program with Strong Negation(abbr. EVALPSN)[3,7] which can be applied to various real-time intelligent control and safety verification systems such as pipeline process control [4,5]. The features and advantages of EVALPSN based control are: (1) since EVALPSN can deal with deontic notions such as forbidance, control policy in deontic expression can be easily translated into EVALPSN; (2) logical verification of operation control can be easily carried out as logic programming; (3) since some restricted fragment of EVALPSN can be implemented on microchips as electronic circuits, real, suitable for real-time control. In this paper, we apply EVALPSN to elevator control and introduce the basic idea of EVALSN based elevator control. Recently, multi-car elevator systems in which more than two cars are operated in the same shaft have been implemented practically and started their services in some countries, however their control should be required verifying the safety for operation. Our work is aiming to provide an EVALPSN based control system for multi-car elevator systems. As the first step to our goal, we introduce the basic idea of EVALPSN based elevator control with taking a single-car/single-shaft elevator system as an object in this paper. The car operation in the elevator system is divided into two kinds R. Setchi et al. (Eds.): KES 2010, Part III, LNAI 6278, pp. 133–142, 2010. c Springer-Verlag Berlin Heidelberg 2010 

134

K. Nakamatsu et al.

of operation, one is preservice operation for picking up passengers waiting at floors and another one is passenger service operation for carrying passengers to their destinations. For each operation we suppose operation properties to be assured for safe operation. The properties are translated into EVALPSN and floor call and passenger request are verified for their safety based on the EVALPSN. We introduce the formalization of verifying the safety for elevator operation in EVALPSN and show a basic and essential example of the verification. This paper is organized in the following mannar: first, EVALPSN is reviewed briefly, and the outline of the single-car/single-shaft elevator and its service properties are introduced; next, the service properties are translated into an EVALPSN and a simple example of the EVALPSN based elevator control is provided; last,the future development of EVALPSN based elevator control to single-car/multi-shaft elevator systems and multi-car/multi-shaft elevator systems are introduced as the future work.

2

EVALPSN

We review EVALPSN briefly[3]. Generally, a truth value called an annotation is explicitly attached to each literal in annotated logic programs[1]. For example, let p be a literal, μ an annotation, then p : μ is called an annotated literal. The set of annotations constitutes a complete lattice. An annotation in EVALPSN has a form of [(i, j), μ] called an extended vector annotation. The first component (i, j) is called a vector annotation and the set of vector annotations constitutes the complete lattice, Tv (n) = { (x, y)|0 ≤ x ≤ n, 0 ≤ y ≤ n, x, y and n are integers } in Figure 1. The ordering(v ) of Tv (n) is defined as : let (x1 , y1 ), (x2 , y2 ) ∈ Tv (n), (x1 , y1 ) v (x2 , y2 ) iff x1 ≤ x2 and y1 ≤ y2 . For each extended vector annotated literal p : [(i, j), μ], the integer i denotes the amount of positive information to support the literal p and the integer j denotes that of negative one. The second component μ is an index of fact and deontic (2, 2)  q PP P @  PP ∗1 ∗ (1, 2) q 3 P  q(2, 1) @ P α  (1, 1) P P @ P @ @q ∗2 @q (2, 0) (0, 2) q @ @ @q γP @q β PP (0, 1) @ (1, 0) P P @q ⊥ (0, 0)

Fig. 1. Lattice Tv (2) and Lattice Td

Introduction to Intelligent Elevator Control Based on EVALPSN

135

notions such as obligation, and the set of the second components constitutes the complete lattice, Td = {⊥, α, β, γ, ∗1 , ∗2 , ∗3 , }. The ordering(d) of Td is described by the Hasse’s diagram in Figure 1. The intuitive meaning of each member of Td is ⊥(unknown), α(fact), β(obligation), γ(non-obligation), ∗1 (fact and obligation), ∗2 (obligation and non-obligation), ∗3 (fact and non-obligation), and (inconsistency). Then the complete lattice Te (n) of extended vector annotations is defined as the product Tv (n) × Td . The ordering(e ) of Te (n) is defined as : let [(i1 , j1 ), μ1 ] and [(i2 , j2 ), μ2 ] ∈ Te , [(i1 , j1 ), μ1 ] e [(i2 , j2 ), μ2 ] iff

(i1 , j1 ) v (i2 , j2 ) and μ1 d μ2 .

There are two kinds of epistemic negation (¬1 and ¬2 ) in EVALPSN, both of which are defined as mappings over Tv (n) and Td , respectively. Definition 1(epistemic negations ¬1 and ¬2 in EVALPSN) ¬1 ([(i, j), μ]) = [(j, i), μ], ∀μ ∈ Td , ¬2 ([(i, j), ⊥]) = [(i, j), ⊥], ¬2 ([(i, j), α]) = [(i, j), α], ¬2 ([(i, j), β]) = [(i, j), γ], ¬2 ([(i, j), γ]) = [(i, j), β], ¬2 ([(i, j), ∗1 ]) = [(i, j), ∗3 ], ¬2 ([(i, j), ∗2 ]) = [(i, j), ∗2 ], ¬2 ([(i, j), ∗3 ]) = [(i, j), ∗1 ],

¬2 ([(i, j), ]) = [(i, j), ].

If we regard the epistemic negations as syntactical operations, the epistemic negations followed by literals can be eliminated by the syntactical operations. For example, ¬1 (p : [(2, 0), α]) = p : [(0, 2), α] and ¬2 (q : [(1, 0), β]) = p : [(1, 0), γ]. There is another negation called strong negation (∼) in EVALPSN, and it is treated as well as classical negation. Definition 2(strong negation ∼) [2]. Let F be any formula and ¬ be ¬1 or ¬2 . ∼ F =def F → ((F → F ) ∧ ¬(F → F )). Definition 3 (well extended vector annotated literal). Let p be a literal. p : [(i, 0), μ]

and

p : [(0, j), μ]

are called weva(well extended vector annotated)-literals, where i, j ∈ {1, 2, · · · , n}, and μ ∈ { α, β, γ }. Defintion 4 (EVALPSN). If L0 , · · · , Ln are weva-literals, L1 ∧ · · · ∧ Li ∧ ∼ Li+1 ∧ · · · ∧ ∼ Ln → L0 is called an EVALPSN clause. An EVALPSN is a finite set of EVALPSN clauses. We note that if the annotations α and β represent fact and obligation, notions “fact”, “obligation”, “forbiddance” and “permission” can be represented by extended vector annotations, [(m, 0), α], [(m, 0), β], [(0, m), β], and [(0, m), γ], respectively in EVALPSN, where m is a positive integer.

136

3

K. Nakamatsu et al.

Single-car Elevator Control Based on EVALPSN

For simplicity, we suppose that (refer to Figure 2): the elevator system physically consists of single car/single shaft with ten floors, and each floor has its floor id; generally, there are two kinds of requests from passengers; one is a floor call issued by passengers waiting at floors, which contains two components, the request direction (up or down) and the floor id where the call has been issued; and another one is a passenger request issued by passengers in the car, which contains one factor, the destination floor id; moreover, a floor where a floor call is issued is called a passenger floor, a floor where the car is located is called the current floor, a route is logically defined as a series of floors, the current route is a route in which the car is serving at present, the terminal floor of the current route is called the destination floor, and a route from the destination floor to a passenger floor is called a preservice route, which is a service route for picking up passengers at the passenger floor.  

   



 

 

Î 

   





   



  

Fig. 2. Single Car Elevator System

Now we outline the elevator control with refering to Figure 3: if a floor call represented as an arrow symbol in Figure 3 has been issued, in order to respond to the floor call its preservice route represented as a dotted arrow in Figure 3 should be created, and whether the preservice route can be processed by the car or not is logically verified. We classified the relations between the current route and preservice routes into six cases shown in Figure 3: (floor call 1) the passenger floor is in the current route, and the request direction and the current route direction are the same, then its preservice route should be the route from the current floor to the passenger floor, and the current route direction and the preservice route direction should be the same; (floor call 2) the passenger floor is forward of the destination floor, and the request direction and the current route direction are the same, then the preservice route should be the route from the destination floor to the passenger floor, and the current route direction and the preservice route direction are the same;

Introduction to Intelligent Elevator Control Based on EVALPSN



 



 

   

 





 





 

   

137







  

Fig. 3. Elevator Control Principles

(floor call 3) the passenger floor is forward of the destination floor and the request direction and the current route direction are not the same, the preservice route should be the route from the destination floor to the passenger floor, and the current route direction and the preservice route direction are the same; (floor call 4) the passenger floor is in the current route, and the request direction and the current route direction are not the same, then the preservice route should be the route from the destination floor to the passenger floor, and the current route direction and the preservice route direction are not the same; (floor call 5) the passenger floor is backward of the current floor and the request direction and the current route direction are the same, then the preservice route should be the route from the destination floor to the passenger floor, and the current route direction and the preservice route direction are not the same; (floor call 6) the passenger floor is backward of the current floor and the request direction and the current route direction are not the same, then the preservice route should be the route from the destination floor to the passenger floor, and the current route direction and the preservice route direction are not the same. We suppose operation properties for the single-car elevator control as follows. SP-1. Floor calls whose preservice route has the same direction as the current route shoud be processed prior to other floor calls. Property SP-1 can be interpreted deontically that if the preservice route direction is not the same as the current route direction, the preservice route is not permitted to be migrated into the current route. Therefore, the preservice route direction of floor calls 4, 5 and 6 is not the same as the current route direction, and they must wait for being processed until the current route direction has

138

K. Nakamatsu et al.

turned. On the other hand, floor calls 1, 2 and 3 should be sequentially processed from the nearest passenger floor of the current floor. Another car operation policy is for passenger requests. SP-2. Passenger requests having the same direction as the current route shoud be served prior to other passenger requests. Property SP-2 can be interpreted deontically that if the passenger request direction is not the same as the current route direction, the passenger request route is not permitted to be migrated into the current route. We will translate the operation properties into EVALPSN to construct an EVALPSN based elevator control system in the following section.

4

EVALPSN for Singel-Car Elevator Control

First of all, We define some EVALP literals used in the knowledge representation of the elevator control system. Current Floor is formalized in the EVALP literal, f l(f lid , cid , t) : [μ1 , μ], where μ1 ∈ {⊥(0, 0), o(1, 0), v(0, 1), (1, 1)}, and μ ∈ Te , and annotations o and v show that floor f lid is occupied by car cid or not(vacant). For example, EVALP clause f l(f lid , cid , t) : [o, α] can be intuitively interpreted that car cid has occupied floor f lid since time t. Notes: if the elevator system has more than one shaft, floor id may be a pair of integers such as (n, m) or n − m in which n is the shaft id and m is the floor number, if the elevator system is single-car/single-shaft, the term cid representing car id in the EVALP literal is not necessary. Route Direction is formalized in the EVALP clause, dir(f li , f lj ) : [μ2 , μ], where μ2 ∈ {⊥(0, 0), up(2, 0), no(1, 1), dw(0, 2), (2, 2)},

and μ ∈ Te ,

and annotations up, dw and no show that the direction of the route from floor f li to floor f lj is upward, downward or no direction. For example, EVALP clause dir(f li , f lj ) : [up, α] can be intuitively interpreted that the direction of the route from floor f li to floor f lj is upward. Floor Call is formalized in the EVALP literal, f c(f lr , dir, t) : [μ3 , μ], where μ3 ∈ {⊥(0, 0), is(1, 0), ui(0, 1), (1, 1)},

and μ ∈ Te ,

and annotations is and ui show that the floor call has been issued or not, dir ∈ {up, dw}, and up and dw express ‘upward’ and ‘downward’ respectively. For example, EVALP clause f c(f lr , dir, t) : [is, α] is intuitively interpreted that the floor call with direction dir at floor f lr has been issued at time t. Passenger Request is formalized in an EVALP literal, pr(f lr , cid , t) : [μ4 , μ], where μ4 ∈ {⊥(0, 0), is(1, 0), ui(0, 1), (1, 1)}, and μ ∈ Te ,

Introduction to Intelligent Elevator Control Based on EVALPSN

139

and annotations is and ui show that the passenger request has been issued or not, For example, EVALP clause pr(f lr , cid , t) : [is, α] is intuitively interpreted that the passenger request bound for floor f lr has been issued at time t. Route is formalized in the EVALP literal, ro(f lc , f ld , cid , t) : [μ5 , μ], where μ5 ∈ {⊥(0, 0), s(1, 0), x(0, 1), (1, 1)},

and μ ∈ Te ,

and annotations s and x show that the route from floor f lc to floor f ld is set for car cid or not. Here ”a route is set” means the route is ready to be served by the car. For example, EVALP clause ro(f lc , f ld , cid , t) : [x, β] is intuitively interpreted that the route from floor f lc to floor f ld must not be set(s) for car cid at time t. Note: car id cid is not necessary if the elevator system is single-car/single-shaft. Car Stop is formalized in the EVALP literal, st(f l, cid , dir, t) : [μ6 , μ], where μ6 ∈ {⊥(0, 0), s(1, 0), x(0, 1), (1, 1)},

and μ ∈ Te ,

and annotations s and x show that a car stop bound for dir at floor f l is set for car cid or not, dir ∈ {up, te, dw}, and te expresses that the car stop floor is the terminal floor of the route. For example, EVALP clause st(f l, cid , dir, t) : [x, γ] is intuitively interpreted that the car stop for car cid with direction dir is permitted to be set(s) at floor f l at time t. Then, properties SP-1 and SP-2 are translated into the EVALPSN clauses, SP-1 f c(f lr , up/dw, t) : [is, α] ∧ ro(f lc , f lo , cid , t) : [s, α] ∧ f l(f lc , cid , t) : [o, α] ∧ (1) dir(f lc , f lo ) : [dw/up, α] ∧ dir(f lo , f lr ) : [up/dw, α] → ro(f lc , f lr , cid , t) : [x, β],

(2)

where the conjunction part (1) represents the condition that the current route direction and the preservice route direction are not the same, and the consequent EVALP clause (2) represents the forbiddance that the route from floor f lc to floor f lr must not be set, that is to say, the floor call must not be processed at time t. SP-2 pr(f lr , cid , t) : [is, α] ∧ ro(f lc , f ld , cid , t) : [s, α] ∧ f l(f lc , cid , t) : [o, α] ∧ (3) dir(f lc , f ld ) : [up/dw, α] ∧ dir(f lc , f lr ) : [dw/up, α] → ro(f lc , f lr , cid , t) : [x, β],

(4)

where the conjunction part (3) represents the condition that the current route direction and the passenger request route direction are not the same, and the consequent EVALP clause (4) represents the forbiddance that the route from floor f lc to floor f lr must not be set, that is to say, the passenger request must be ignored at time t.

140

K. Nakamatsu et al.

On the other hand, if forbiddance from setting routes cannot be derived, permission for setting routes should be derived. Therefore, we need the following EVALPSN clause DP for deriving permission. DP

∼ ro(f lc , f lr , cid , t) : [x, β] → ro(f lc , f lr , cid , t) : [x, γ].

(5)

Car stops should be set according to route set permission. If the route is generated by floor call, the corresponding car stop has direction ‘up’ or ‘down(dw)’, and if the route is generated by passenger request, the corresponding one has direction ‘terminal(te)’, which can be formalized by the EVALP clauses, CS f c(f lr , up/dw, t) : [is, α] ∧ ro(f lc , f lr , cid , t) : [x, γ] → st(f lr , cid , up/dw, t) : [s, β],

(6)

pr(f lr , cid , t) : [is, α] ∧ ro(f lc , f lr , cid , t) : [x, γ] → st(f lr , cid , te, t) : [s, β].

(7)

Moreover, we need EVALP clauses for updating the current route, that is to say, for example, if the current route from 2nd floor to 5th floor has already been set, then if a route from the current floor 2nd floor to 7th floor is permitted to be set, the new current route from 2nd floor to 7th floor shoud be set. Such current route update can be formalized in the EVALP clauses, CRU ro(f lc , f ld , cid , t) : [s, α] ∧ ro(f lc , f ln , cid , t) : [x, γ] ∧ f l(cid , f lc , t) : [o, α] ∧ ∼ dir(f lc , f ld ) : [up/dw, α] ∧ dir(f ld , f ln ) : [dw/up, α] → ro(f lc , f ln , cid , t) : [s, β].

(8)

In practice, although release conditions for routes and car stops after they have been processed or migrated into other routes should be considered here, it is not essential, therefore we omit the release conditions for routes and stops. Here we present a simple example for EVALPSN elevator control. Example We suppose a single-car/single-shaft elevator system with 10 floors. For simplicity, we represent a floor call as an ordered pair, (call issued floor, request direction), a root as (origin floor =⇒ destination floor) and a passenger request (in the car) as (request issued floor =⇒ destination floor). We consider the elevator control senario, stage 1, stage 2, · · ·, stage 6, with two floor calls call A and B and one passenger request req B by the passenger of call B, which is summarized in Table 1. stage 1 suppose that call A (4,dw) is issued when the car is at 2nd floor with no request processing, EVALP SP-1 cannot derive the forbiddance from setting a new route (2 =⇒ 4), thus route (2 =⇒ 4) is permitted to be set by EVALPSN DP, and must be set by EVALPSN CRU, moreover downward car stop 4↓ is set at 4th floor by EVALPSN CS;

Introduction to Intelligent Elevator Control Based on EVALPSN

141

Table 1. Senario for Example Stage (floor) Stage 1 (2F) Stage 2 (3F) Stage 3 (4F) Stage 4 (5F) Stage 5 (6F) Stage 6 (5F)

\ EVALPSN Request \ call A (4,dw) call A call B (5,up) call A call B call A req B (5 =⇒ 6) call A call A

SP-1, SP-2, CS CRU DP DP (Car Stop) (Current Route) 2 =⇒ 4 — 4↓ 2 =⇒ 4 — — — — 3 =⇒ 5 — 5↑ 3 =⇒ 5 — — — — 4 =⇒ 5 — 5↑ 4 =⇒ 5 — — — — — 5 =⇒ 6 6 5 =⇒ 6 6 =⇒ 4 — 4↓ 6 =⇒ 4 5 =⇒ 4 — 4↓ 5 =⇒ 4

stage 2 suppose that call B (5,up) is issued when 3rd floor is the current floor and the current route is (3 =⇒ 4), EVALP SP-1 cannot derive the forbiddance from setting the new route (3 =⇒ 5), thus route (3 =⇒ 5) is permitted to be set by EVALPSN DP, and it must be set by EVALPSN CRU, moreover car stop 5↑ is set at 5th floor by EVALPSN CS, on the other hand EVALP SP-1 derives the forbiddance from setting the new preservice route (3 =⇒ 4) for call A (4,dw), therefore car stop 4↓ has been canceled(unset); stage 3 suppose that both call A (4,dw) and call B (5,up) are tried to be processed again when 4th floor is the current floor and the current floor is (4 =⇒ 5), EVALP SP-1 still derives the forbiddance from setting the new preservice route (5 =⇒ 4), for call A, on the other hand the forbiddance from setting the new preservice route (4 =⇒ 5) for call B cannot be derived, therefore route (4 =⇒ 5) and car stop 5↑ must be set; stage 4 suppose that req B (5 =⇒ 6) is issued when the passenger gets on the car at the 5th floor and call A is tried again, call B and car stop 5↑ are released at 5th floor, 1 then the current route is (5 =⇒ 5), EVALP SP-1 still derives the forbiddance from setting the new preservice route (5 =⇒ 4), for call A, on the other hand EVALP SP-2 cannot derive the forbiddance from setting the new route (5 =⇒ 6) for req B, therefore rout (5 =⇒ 6) and car stop 6(terminal stop) are set; stage 5 suppose that call A (4,dw) is tried when the car has arrived at 6th floor and the passenger has got off the car, then req B and car stop 6 are released, and the current route is (6 =⇒ 6), EVALP SP-1 cannot derive the forbiddance from setting the new preservice route (6 =⇒ 4) for call A, therefore route (6 =⇒ 4) and car stop 4↓ are set; stage 6 suppose that the car is moving downward at 5th floor, the current route is (5 =⇒ 4), call A is tried again, EVALP SP-1 cannot derive the forbiddance from setting the new preservice route (5 =⇒ 4) for call A, therefore route (5 =⇒ 4) and car stop 4↓ are set again. 1

We do not address such release conditions in details.

142

5

K. Nakamatsu et al.

Conclusion and Future Work

In this paper, we have introduced the basic ides of an EVALPSN based elevator control system having single-car/single-shaft, which is based on the logical verification of elevator operation policies though, our goal is to extend and apply the idea to multi-car/multi-shaft elevator control systems and to obtain a flexible and logical verification based multi-car elevator control. Then the ideas of the safety verification for railway interlocking or pipline valve control seem to be applicable. Either way, we believe that the obtained elevator control system has high extendability such as two-car elevator system to three-car one because it is based on EVALPSN. As another future work, we need to consider optimization of the EVALPSN elevator control, then efficient shaft assignment may be required if the elevator system has more than one shaft. Therefore, we are planning to apply plausible reasoning based on EVALPSN [6] to the shaft assignment problem. 2

References 1. Blair, H.A., Subrahmanian, V.S.: Paraconsistent Logic Programming. Theoretical Computer Science 68, 135–154 (1989) 2. da Costa, N.C.A., Subrahmanian, V.S., Vago, C.: The Paraconsistent Logics PT . Zeitschrift f¨ ur Mathematische Logic und Grundlangen der Mathematik 37, 139–148 (1989) 3. Nakamatsu, K., Abe, J.M., Suzuki, A.: Annotated Semantics for Defeasible Deontic Reasoning. In: Ziarko, W.P., Yao, Y. (eds.) RSCTC 2000. LNCS (LNAI), vol. 2005, pp. 432–440. Springer, Heidelberg (2001) 4. Nakamatsu, K.: Pipeline Valve Control Based on EVALPSN Safety Verification. J. Advanced Computational Intelligence and Intelligent Informatics 10, 647–656 (2006) 5. Nakamatsu, K., Mita, Y., Shibata, T.: An Intelligent Action Control System Based on Extended Vector Annotated Logic Program and its Hardware Implementation. J. Intelligent Automation and Soft Computing 13, 289–304 (2007) 6. Nakamatsu, K., Imai, T., Abe, J.M., Akama, S.: An Introduction to Plausible Reasoning Based on EVALPSN. In: New Advances in Intelligent Decision Technologies. SCI, vol. 199, pp. 363–372. Springer, Heidelberg (2009) 7. Nakamatsu, K., Abe, J.M.: The development of Paraconsistent Annotated Logic Program. Int’l J. Reasoning-based Intelligent Systems 1, 92–112 (2009)

2

This work is financially supported by Japanese Scientific Research Grant (C) No. 20500074.