Green Elevator Scheduling Based on IoT Communications

In this paper, we propose an energy-saving elevator scheduling algorithm to reduce the car moving steps to achieve motor energy saving and green wireless communications. The proposed algorithm consisting of six procedures can attain fewer Internet of Things (IoT) message exchanges (i.e. communication transmissions) between the Scheduler subsystem and the Car subsystem via the core function <italic>AssignCar</italic>(<inline-formula> <tex-math notation="LaTeX">$r$ </tex-math></inline-formula>). The function <italic>AssignCar</italic>(<inline-formula> <tex-math notation="LaTeX">$r$ </tex-math></inline-formula>) is capable of assigning a request to the nearest car through car search globally. From the emulation results for four cars, this work shows that the proposed algorithm outperforms the previous work named as aggressive car scheduling with initial car distribution (ACSICD) algorithm with energy consumption reductions by 49.43%, 47.68%, 37.89%, and 47.65% for up-peak, inter-floor, down-peak, and all-day request patterns, respectively.


I. INTRODUCTION
Due to modern building construction methods and new government regulations of lifting equipment, the elevator technologies have been significantly advanced in the past decade, especially for the purpose of carrying the passengers.During technology revolution, energy saving for green buildings in smart cities is highly demanded.The modern elevators are the potential energy consumption source since the elevator cars carry many passengers every day under the commands exchanged through the exiting wired communication networks as a part of a smart building.Since the cars and the scheduler of the elevator system interact with each other for car moves, inefficient elevator scheduling will lead to redundant communication transmissions and unnecessary car moves such that more energy will be consumed.Herein, we design an energy-saving elevator scheduling that reduces the car moving steps to attain energy reduction and green communications under wireless communications.
There exist many elevator group control studies [1]- [20] including the single-car elevator [1], [7], [8], multi-car The associate editor coordinating the review of this manuscript and approving it for publication was Ilsun You .
Most elevator system studies focus on car scheduling to save waiting times or journey times of the passengers.Approaches based on genetic [12], neural network [3], [5], fuzzy [4], [11], and reinforcement learning scheduling (RLS) [15] attempt to minimize the waiting/journey times.Other approaches attempt to reduce the energy consumption from the viewpoints of circuit structure, circuit control, and scheduling control.Several of them [17]- [20] address the energy issue using the scheduling control algorithms.In [19], Zhang et al. proposed an ant colony optimization method considering energy and scheduling for the elevator group control system (the details will be described in the Appendix).However, these scheduling control algorithms cannot easily exercise online scheduling in practice due to batch request demand and iterative learning behavior.Furthermore, to our best knowledge, the Internet of Things (IoT) communications associated with green elevator scheduling have not yet been explored.In particular, existing elevator systems utilize wired communications.In an elevator system called ElevatorTalk [1], we have shown that IoT technologies can be used to implement distributed elevator scheduling, and wireless communication can also be used in the elevator systems without degrading the real-time performance of the cars.We have measured the wireless delay [1], where the expectation is 59.14 ms and the variance is 9.094.
ElevatorTalk has excellent passenger journey time performance as compared with the previous approaches [1].Another elevator performance measure is ''moving steps'' that determine energy consumption for car motor and wireless IoT communication.Specifically, reducing the car moves will result in fewer IoT message exchanges to achieve green wireless communications.Unfortunately, how to reduce the car moving steps in a systematic way is still open.An interesting question is: how to manage the cars as ''green elevators'' by saving moving steps under the acceptable journey time.
To achieve this goal, we propose an energy-saving elevator scheduling algorithm that assigns a request to the nearest car through car search globally.Therefore, the energy consumption of the elevator can be accordingly reduced due to fewer car moving steps and wireless IoT message exchanges.
The remainder of this paper is organized as follows.Section II demonstrates the proposed energy-saving elevator scheduling algorithm.Section III evaluates and compares energy saving of the developed system with other solutions.The last section summarizes our work.

II. ELEVATORTALK PROCEDURES AND ENERGY-SAVING ELEVATOR SCHEDULING ALGORITHM
In [1], we proposed the ElevatorTalk platform that allows one to implement a distributed car scheduling algorithm based on wireless IoT communication. Figure 1 illustrates how an 8-car elevator system is configured through the ElevatorTalk graphical user interface (GUI).In this figure, ElevatorTalk includes the Panel subsystem, the Scheduler subsystem, and the Car subsystem.Every subsystem except for the Panel subsystem consists of an input part (represented by an icon on the left-hand side in Figure 1) and an output part (represented by an icon on the right-hand side in Figure 1).The Panel subsystem (Figure 1  In our previous work [1], the aggressive car scheduling with initial car distribution (ACSICD) stores new arrival requests in the global structures.Then, the cars select the requests to serve independently.ElevatorTalk is an IoT platform where three subsystems are implemented as IoT devices that communicate with each other through wired or wireless communication.Although most elevator systems are centralized with wired communication, wireless communication allows the structure of distributed cars better.In a distributed car structure, it is essential to reduce the number of message exchanges for car moves.In other words, it is important to reduce car moves to achieve green wireless communication as well as car motor energy saving.This paper proposes the energy-saving elevator scheduling algorithm that reduces the car moving steps to achieve the goal of energy saving for IoT communication.Unlike the previous proposed solution ACSICD, as long as a new request is issued by Procedure Panel in the Panel subsystem, the energy-saving elevator scheduling algorithm immediately assigns the request to a ''carefully'' selected car n by Procedure ReqArrival in the Scheduler subsystem.Then Procedures SchCar(n), UpTaskCar(n), and DownTaskCar(n) in the Scheduler subsystem direct the n-th car to serve this request.When the n-th car reaches the floor that has a request with the same direction, the n-th car serves the request even if the request is not assigned to the n-th car.The system symbols used to describe the algorithm are listed in Table 1.

A. PROCEDURE Panel AND ReqArrival
Procedure Panel shown in Figure 2 interacts with the elevator car operating panels (ECO) that can be a traditional panel in the hall of each floor or a smart user interface (UI) interpreted by web browsers in cell phones, personal computers, and laptops.An ECO panel issues a request when a passenger pushes the button, and then the request is received by Procedure Panel.The format of the m-th request is r m = f s,r m , D r m , S r m , where f s,r m is the start floor from which r m is issued.D r m ∈ {Up, Down} is the moving direction of r m .S r m is the set of target floors of the m-th request r m .In the loop (Steps P.2-P.5), the procedure waits for request r m from the ECO panel at Step P.3, and then sends the request to the Scheduler subsystem at Step P.4.We assume that the elevator system is shut down for maintenance after it has served M requests.
Procedure ReqArrival illustrated in Figure 3 is responsible for receiving requests from Procedure Panel and dispatching the requests to proper cars.Step R.1 initializes the related variables.Step R.2 creates N threads of SchCar(n) to process the requests assigned to the n-th car, where 1 ≤ n ≤ N .The procedure maintains the global data structures Uplist L u and Downlist L d , where L u stores all unserved f s,r that are the start floors of the requests with D r = Up and L d stores all unserved f s,r with D r = Down (Steps R.4-R.6).At Step R.7, the core function AssignCar(r) is responsible for assigning each request to a proper car in the Scheduler subsystem, which is elaborated in the next subsection.

B. FUNCTION AssignCar(r )
Function AssignCar(r) searches for the car that takes minimum car moving steps to handle r.The flowchart is illustrated in Figure 4, where the symbols for Function AssignCar(r) are defined in Table 2. Two variables n and X * are initialized at Step A.1, where n is set to 1 to represent the first car and X * is set to INF.X * is used to store the temporary minimum moving steps to pick up request r.Steps A.2-A.14 are a loop to find the car to handle the request.Three local variables X , n * , and d * are used.The sign and absolute value of X denote the relative locations between request r and the n-th car and the actual moving steps for the n-th car to pick up request r, respectively.n * denotes the tentative nearest car to request r and d * is used to determine d n * (i.e. the moving direction of the n * -th car) when leaving Function AssignCar(r).Step A.9 uses the sign of X to determine the relative locations between request r and the n-th car.If X > 0, the n-th car moves up to handle the request, the flow proceeds to Step A.6 and sets d to Up.If X < 0, to the contrary, the flow proceeds to Step A.8 and sets d to Down.If X equals 0 at Step A.9, it implies that the n-th car is Idle on f s,r and no other car can be closer to f s,r than the n-th car.Thus, Step A.

C. FUNCTION MoveUp(r )
The X value calculated at Step A.3 of AssignCar(r) does not represent the number of floors that the n-th car moves if this car needs to change its direction to pick up request r. Figure 5 illustrates the relationship between a car and a request.Function MoveUp(r) recalculates X to obtain the actual moving steps between f s,r and f n according to four cases.Cases 1.1 & 1.2 (Figure 5 (a) and (b)) represent that f s,r of the request is higher than or equal to f n of the n-th move-up car (i.e.f s,r ≥ f n ).Cases 2.1 & 2.2 (Figure 5 (c) and (d)) represent that f s,r of the request is lower than f n of the n-th move-up car (i.e.f s,r < f n ).In Cases 1.1 & 2.2, the directions of the n-th car and the request are the same.Conversely, in Cases 1.2 & 2.1, the directions of the n-th car Step MU.
Step MU.5 checks if there exists any f s,r in C s,d .
Function MoveDown(r) is the same as Function MoveUp(r) except for the direction reverses.This part is omitted.

D. PROCEDURE SchCar(n)
Procedure SchCar(n) instructs the n-th car to pick up and deliver the passengers to the destinations.Figure 7 illustrates the flowchart using four global data structures.d n is the current moving direction of the n-th car, where d n ∈ {Up, Down, Idle}.The up-request set C s,u (n) indicates the set of all unhandled f s,r assigned to the n-th car with D r = Up.Similarly, the down-request set C s,d (n) contains all unhandled f s,r assigned to the n-th car with D r = Down.The set C t (n) includes the target floors that the n-th car has to stop in the current moving direction.Herein, C t (n) = f t,c (n, 1) ,f t,c (n, 2) , . . .,f t,c (n,j n ) , where f t,c (n, j) denotes the j-th target floor in the n-th car's stop  request r (i.e.passengers enter the n-th car and push the target floor buttons).At Step U.5, if C t (n) is not empty or there exists a request with f s,r that is higher than Otherwise, the procedure proceeds to Step U.2 and the loop goes on.At Step U.3, if f n belongs to neither C t (n) nor L u , the procedure proceeds to Step U.9.This step is the same as the first condition of Step U.5.If there exists a target floor or an unserved request whose f s,r is above the n-th car, the procedure proceeds to Step U.10 and sets o n to 0 since no passenger enters/leaves f n .Otherwise, the procedure proceeds to Step U.11 and checks if there exists any request in C s,d (n) whose f s,r is the same with f n or there still exists any request in either the sets C s,u (n) or C s,d (n) whose f s,r is below f n .If so, the direction d n is set to Down.Otherwise, the n-th car becomes an idle car and the procedure returns to Step S.2 of SchCar(n).Since Procedure DownTaskCar(n) is the same as Procedure UpTaskCar(n) except for the direction reverses, we do not detail this part herein.

F. PROCEDURE Car(n)
The car subsystem has N threads and each of them executes Procedure Car(n) in Figure 9.For example, for an 8-car system, the Car subsystem has such threads for 1 ≤ n ≤ 8. Procedures SchCar(n) and Car(n) synchronize the communication at Step C.1 by a handshaking.In the Car subsystem, Procedure Car(n) continues to wait for the message (o n ,d n ) from Procedure SchCar(n) in the Scheduler

III. PERFORMANCE EVALUATION
In this section, we show the detailed experimental results and performance evaluation.In Section III.A, we use an energy consumption model to evaluate the energy consumption of various scheduling algorithms.In Section III.B, we describe four request patterns used for performance evaluation.In Section III.C, performance comparisons of the energy-saving elevator scheduling algorithm and previous proposed algorithms are demonstrated.

A. ENERGY CONSUMPTION MODEL
We adopt the energy consumption model in [19] to evaluate the energy performance compared with other methods.The symbols used to describe the energy consumption model are listed in Table 3.The total energy consumption E of an elevator system during the observation period T is where E a is the total acceleration and deceleration energy during T , which is defined by In the above equation, E a (n) is the acceleration and deceleration energy of the n-th car during T , R n is the number of requests served by the n-th car during T , µ n,m is the number of stops between request r m and request r m , where r m is the previous request served by the n-th car on its moving path to the start floor of request r m , and e a is the energy consumed by one motor acceleration or deceleration (e a = 22.5kJ).E v is the total moving energy during T defined as follows: where θ (n, m, s) is the number of passengers in the n-th car on the moving path from the s-th stop to the start floor of request r m , h(n, m, s) is the distance between the s-th stop and its next stop when the n-th car is on the moving path to the start floor of request r m .q is the average mass of a passenger (q = 65kg), q is the difference between the counterweight mass and the mass of the n-th car (q = 100kg), and g is the acceleration of gravity (g = 9.8m/s 2 ).

B. GENERATION OF REQUEST PATTERNS
In order to evaluate the performance of the proposed energysaving elevator scheduling algorithm, we adopt three types of traffic including up-peak, inter-floor, and down-peak [2] for T = 60 minutes in a 16-floor building.The up-peak traffic occurs in the beginning of the workday while the down-peak traffic occurs at the end of the workday.Otherwise, the traffic type belongs to the inter-floor traffic.As shown in Table 4, three types of traffic are characterized by three parameters: peak arrival rate, peak interval, and base arrival rate.
According to the peak arrival rate in the peak interval (i.e. 15 minutes) and the base arrival rate in the remaining interval, the inter-arrival times (τ m ) of the requests are produced by where λ denotes the arrival rate in terms of the number of requests per second and U represents a random value in (0,1).We describe four types of generated request patterns according to three traffic types with different arrival rates λ as follows: Up-peak: The up-peak request indicates that the start floor is the base floor (i.e.1F in our emulation) and target floor is randomly selected from 2F-16F with the same probability.The peak interval ranges from the 20-th minute to the 35-th minute during the 60-minute observation period.Inter-floor: The inter-floor request indicates that the start floor and target floor are randomly selected from 1F-16F with the same probability, where the start floor and target floor are mutually exclusive.Down-peak: The down-peak request indicates that the target floor is the base floor and start floor is randomly 2F-16F with the same probability.The peak interval ranges from the 30-th minute to the 45-th minute during the 60-minute observation period.All-day: The all-day request indicates that the start floor and target floor are selected according to the Poisson distribution defined in [15], where the all-day traffic consists of up-peak, inter-floor, and down-peak traffic.The request in all-day request pattern arrives at the interval from 7:00 AM-9:00 PM.The up-peak, down-peak, and inter-floor request patterns have 522, 504, and 300 requests for 60 minutes, respectively, and all-day request pattern has 861 requests in our emulation experiment.Note that in our emulation, we assume each request r has only one target floor.

C. COMPARING ENERGY-SAVING ELEVATOR SCHEDULING ALGORITHM WITH THE PREVIOUSLY PROPOSED ALGORITHMS
We conduct timing emulation where Function sleep is utilized to emulate moving up/down one floor and door opening and closing in Procedure Car(n) in Section II.F.Based on the motor mechanical characteristics, the time for a car to move up/down one floor is not fixed [19].Three car moving times are summarized as follows: 1) When a car moves up/down only one floor, the car moving time is 3.46s.2) When a car moves up/down two floors, the car moving time is 4.9s.
3) When a car moves up/down more than two floors, the car moving time is set to 4.9s for the first two floors and 1.2s for each extra floor.
Through the above emulation setting, we emulate the proposed energy-saving elevator scheduling algorithm in VOLUME 8, 2020 Section II and ACSICD [1] using the request patterns described in Section III.B.In our emulation experiments, we evaluate the performance by the average waiting/journey time and the energy consumption.The average waiting time T w is defined by where T w (m, n) denotes the duration between the arrival time t m of the m-th request and the time that the n-th car picks up the m-th request.The average journey time T j is formulated by where T j (m, n) represents the duration between the arrival time t m of the m-th request and the time that the n-th car which handles the m-th request arrives at the target floor of the request.The energy consumption E is described in Section III.A. Table 5 shows the average journey times and the energy consumption of various algorithms with the uppeak, inter-floor, down-peak, and all-day request patterns for 4 cars.The proposed energy-saving elevator scheduling algorithm outperforms ACSICD with energy consumption reductions by 49.43%, 47.68%, 37.89%, and 47.65% in terms of up-peak, inter-floor, down-peak, and all-day request patterns, respectively.On the contrary, compared with the energy-saving elevator scheduling algorithm, ACSICD reduces the average journey times in terms of up-peak, interfloor, down-peak, and all-day request patterns by 23.99%, 1.07%, 5.89%, and -0.39%, respectively.Compared with the performance in [19], our approach outperforms the ant colony algorithm in terms of the energy consumption saving for uppeak and down-peak request patterns by 5.81% and 47.33%, respectively, where the detailed algorithm is described in Appendix.
For the emulations with 8 cars as shown in Table 6, the proposed energy-saving elevator scheduling algorithm outperforms ACSICD with energy consumption reduction by 48.34% for all-day request pattern.On the contrary, compared with energy-saving elevator scheduling algorithm, ACSICD reduces the average journey time for all-day request pattern by 0.19%.
The communication transmission in Tables 5 and 6 is the number of message exchanges between the Scheduler subsystem and the Car subsystem to control the cars' behavior.In terms of the communication transmissions, the energy-saving elevator scheduling algorithm can attain the reductions by 28.88%, 27.3%, 29.04%, and 20.18% for N = 4 for up-peak, inter-floor, down-peak, and all-day request patterns and 23.58% for N = 8 for all-day request pattern compared with ACSICD, respectively.Thus, the proposed algorithm can achieve green communications.
From Tables 5 and 6, compared with ACSICD, the energy-saving elevator scheduling algorithm has better energy saving in all request patterns because of the fewer car moving steps and communication transmissions with a small amount of increased average journey time.

IV. CONCLUSION
In this paper, the energy-saving elevator scheduling algorithm is proposed and verified to reduce the energy consumption in an elevator system with IoT communications.Four types of request patterns including up-peak, inter-floor, down-peak, and all-day are used to verify the performance comparisons for 4 cars and the all-day request pattern is used to evaluate the performance comparison for 8 cars.Through these comparisons, this study outperforms ACSICD [1] in all request patterns in terms of energy saving due to fewer car moving steps and communication transmissions (i.e.IoT message exchanges) with acceptable average waiting/journey time.Although making cars busier in the elevator system could achieve less average journey time, without carefully selecting a car for a request could incur more energy consumption.Furthermore, the evaluation of communication transmissions shows that the energy-saving elevator scheduling algorithm could achieve green communications in the ElevatorTalk system.

APPENDIX
In [19], the authors proposed an elevator scheduling using the ant colony optimization method to minimize energy consumption.Each elevator car and request are regarded as an ant and a target (i.e.food), respectively, where the requests and the cars are mutually connected to establish many paths.The path π n,m possessing the pheromone (ϕ k n,m ) represents the path from the n-th ant (i.e.car) to the m-th food (i.e.request).When the n-th car passes path π n,m to serve the m-th request, the pheromone is strengthened.That means that the n-th car with a larger pheromone value and a lower energy consumption on the path π n,m has a higher probability to serve the m-th request.This algorithm computes all pheromones iteratively.After k searching iterations, the car system has the converged scheduling.We use the configuration (4-car system with k = 200) in [19] to demonstrate the ant colony optimization for elevator scheduling.The algorithm periodically collects requests.In each period, the collected requests are divided into two categories that are move-up requests and move-down requests.After receiving the requests, the algorithm starts to optimize the scheduling iteratively.The algorithm executes the following steps to find an optimized solution: Step 1.After collecting the requests, set k to one, n to one, and E k to zero.E k is the total energy consumption for the N -car system in the k-th iteration.
Step 2. Sort the move-up requests of L u in an ascendingorder list and the move-down requests of L d in a descending-order list.Then, append the sorted list of the move-up requests to the sorted list of the move-down requests and construct a new request list Z .Set M to the number of requests in Z .     4,5 }.Therefore, after reaching the final iteration, each car has its exclusive sequence of requests, where r 1 , r 2 and r 6 are dispatched to Car 1 and r 3 , r 4 and r 5 are dispatched to Car 2.
Although the convergence of the ant colony algorithm for elevator scheduling is proven in [19], it is not a real-time scheduler because it must wait for a batch of request arrivals before it can conduct the scheduling optimization.Therefore, the ant colony algorithm may not be easily practiced in the real-time scenario with heavy passenger traffic.
(e)) issues requests to the output part of the Scheduler subsystem (Figure 1 (d)) and the input part of the Scheduler subsystem (Figure 1 (c)) sends instructions to the output part of the Car subsystem (Figure 1 (b)).After finishing the instruction from the Scheduler subsystem (Figure 1 (c)), the input part of the Car subsystem (Figure 1 (a)) sends current floor to the output part of the Scheduler subsystem (Figure 1 (d)).The instructions and the responses are implemented by IoT message exchanges.The proposed energy-saving elevator scheduling algorithm implemented in [1] consists of six procedures including Panel, ReqArrival, SchCar(n), UpTaskCar(n), DownTaskCar(n), and Car(n).Procedure ReqArrival has three functions which are AssignCar(r), MoveUp(r), and MoveDown(r).
10 sets d * to D r and then Step A.15 is executed to set n * to n and breaks the loop.If n > N at Step A.2, Step A.16 is executed to check whether D r is Up.If so, f s,r is included in C s,u (n * ).The set C s,u (n * ) stores the move-up requests to be handled by the n-th car.Otherwise, f s,r is included in C s,d (n * ) for the move-down requests.Step A.19 sets d n * to d * .Then we exit AssignCar(r) and go back to Step R.3 of Procedure ReqArrival.Note that if the n-th car is moving, d n * will remain unchanged after Step A.19.

FIGURE 5 .
FIGURE 5. Four cases in Function MoveUp(r) for the request assignment.

FIGURE 7 .
FIGURE 7. Flowchart for Procedure SchCar(n).listC t (n) for 1 ≤ j ≤j n and j n = |C t (n)|.At Step S.1, d n is set to Idle, and C s,u (n), C s,d (n), and C t (n) are set to empty.At Step S.1.5, the procedure waits to receive the updated status f n of the n-th car from Procedure Car(n) (to be elaborated in Section II.F).Procedure SchCar(n) of the Scheduler subsystem and Procedure Car(n) of the Car subsystem must be synchronized.Therefore, Step S.1.6sends message (0, Idle) to acknowledge Procedure Car(n) that the connection path is ready.After initialization, Procedure SchCar(n) enters a loop to handle the direction of the n-th car (Steps S.2-S.4).Step S.2 checks the direction of the n-th car.If d n is Up, the flow proceeds to Step S.4 and invokes Procedure UpTaskCar(n) to instruct the n-th car to serve the assigned requests (to be elaborated in Section II.E).If d n is Down, Procedure DownTaskCar(n) at Step S.3 is invoked.Otherwise, when d n is Idle, the procedure stays at Step S.2 until d n is updated due to a new assigned request to the n-th car in Function AssignCar(r) described in Section II.B.

TABLE 3 .
Symbols used in the performance evaluation.subsystem described in Sections II.D and E. If o n = 1 at Step C.3, the car opens and closes the door to load/unload the passengers at Step C.4.If d n is Up at Step C.5, the car moves up one floor and f n is incremented by 1 at Step C.6.If d n is Down at Step C.5, the car moves down one floor and f n is decremented by 1 at Step C.7.After f n is updated at Steps C.6 and C.7, through ElevatorTalk configuration in Figure 1, Step C.8 sends f n to either Procedure UpTaskCar(n) or Procedure DownTaskCar(n) in the Scheduler subsystem described in Section II.E.If d n is Idle at Step C.5, the flow proceeds to Step C.8 directly.

Step 3 . 4 . 4 . 1 .
For 1 ≤ n ≤ N and 1 ≤ m ≤ M , initialize ϕ k n,m to a positive constant A, and set p k n,m and E k n,m to zero.p k n,m is the probability for the n-th car to serve the m-th request in the k-th iteration and E k n,m is the energy consumption produced by the n-th car when serving the m-th request in the k-th iteration.Step Generate an N -car scheduling for the request list Z in the k-th iteration.Step Set m to 1 (traverse from the first element of the request list Z ).Step 4.2.For 1 ≤ n ≤ N , calculate the energy consumption of the k-th iteration E k n,m by E k n,m = 2 × µ n,m × e a + µ n,m s=1 [|θ (n, m, s) × q − q| × g × h(n, m, s)].

Step 4 . 3 .
For 1 ≤ n≤N , calculate probabilities p k n) α × (1/E k n,m ) β , where α and β are coefficients to control the influence of ϕ k n,m and 1/E k n,m , respectively.Step 4.4.For 1 ≤ n ≤ N , select the car with the highest probability p k n,m to serve the m-th request.Step 4.5.Calculate the waiting time of the m-th request served by the selected car.Step 4.6.Check if the waiting time exceeds the threshold.If so, go back to Step 4.4 and select the car with the next highest probability.Otherwise, go to Step 4.7.Step 4.7.Check if all the requests in Z are scheduled.If so (i.e.m = M ), go to Step 5. Otherwise, increase m by 1 and go back to Step 4.2.Step 5. Calculate total energy consumption E k of the scheduling derived from Step 4 by

[ 6 . 7 .
|θ (n, m, s)×q − q|×g ×h(n, m, s)], where R k n is the number of requests served by the n-th car in the k-th iteration.Step For 1 ≤ n ≤ N and 1 ≤ m ≤ M , update all the pheromones by ϕ k+1 n,m = ρϕ k n,m + ϕ k n,m , where ρ denotes the weight in (0, 1] and ϕ k n,m denotes the incremental difference of ϕ k n,m , which is defined as follows: if the car n passes π n,m 0, otherwise, where C is a constant.Step Check if k = 200.If so, terminate the process and dispatch the requests.If no, increase k by 1 and go back to Step 4. For example, as shown in Figure 10, in the final iteration (i.e.k = 200), all car-choosing probabilities are calculated as follows: p 200 1,1

FIGURE 10 .
FIGURE 10.The optimized scheduling proceeded by the ant colony optimization.

TABLE 2 .
Symbols for Function AssignCar (r ). a car n, Step A.3 sets X to f s,r − f n , where f s,r is the start floor of request r and f n is the current floor of the n-th car.Step A.4 uses the current moving direction of the n-th car d n to check if the n-th car is moving.If d n is Up, Function MoveUp(r) at Step A.5 is invoked to update X (to be elaborated in Section II.C).Step A.6 sets d to Up. Step A.11 checks if X is 0. If so, Step A.15 sets n * to n and breaks the loop.If X is not 0 at Step A.11, Step A.12 checks whether the absolute value of X is smaller than X * .If so, Step A.13 sets X * to |X |, n * to n, and d * to d.At Step A.14, n is incremented by 1.If d n is Down at Step A.4, then Step A.7 is executed to update X .Step A.8 sets d to Down and the procedure proceeds to Step A.11.If d n is Idle at Step A.4, Case 1.2.(f s,r of request r with D r = Down is above or equal to f n ).Step MU.3 sets f l to F. Then, the function proceeds to compute the f h value.Step MU.8 checks if there exists any f s,r in C s,u (n) that is higher than f n .If so, f h is set to F at Step MU.9.Otherwise, f h is set to max f s,r , max C t (n), max C s,d (n) at Step MU.10.At Step MU.11, since f l is F, the function goes to Step MU.12 to recalculate X as ). Step MU.2 checks if D r = Down.In this case, D r is Up.We exit MoveUp(r) and go back to Step A.6 of AssignCar(r) (i.e.X = f s,r − f n , which has been set at Step A.3 of AssignCar(r) already).
and C t (n) are empty, d n is set to Idle.Step U.6 sends message (o n ,d n ) to the n-th car of the Car subsystem and Step U.7.1 waits for f from the n-th car.Note that Steps U.7.2 and U.7.3 are designed to prevent redundant door open operations [1].At Step U.8, if d n is not Up, the procedure returns to Step S.2 of SchCar(n).

TABLE 4 .
The parameters of traffic types.