- Email: [email protected]
Automatic simulation program synthesis using a knowledge-based approach
SIMULATION PRACTICE
ELSEVIER
aT#EORY
Simulation Practice and Theory 5 (1997) 473-488
Automatic simulation program synthesisusing a knowledge-basedapproach Hon Wai Chun’ Department
of Electronic
Engineering, City University of Hong Kong, Tat Chee Avenue, Kowloon, Hong Kong
Received 25 April 1995; revised 20 March 1996
Abstract This paper describesresearch and development in automatic simulation program synthesis using a knowledge-based approach. Simulation analysis can be a very important tool for people responsible for critical resource management in large organisations. Unfortunately, these management decisions must often be made quickly and on a daily basis. There may not be enough time to involve simulation software developers. The main objective of our system is to make simulation easily accessibleto non-technical management-level people who might not have a background in computer programming or simulation theory. Our knowledgebased simulation system automatically constructs a SIMAN simulation program through an object-oriented graphic user interface and a knowledge-base of domain-specific heuristics implemented in OPS5. The system then executes the simulation program and displays the results as animated graphics. Our research was performed in the domain of airport check-in counter scheduling. This paper describes an overview of the system design and provides examples of the results produced by our knowledge-based simulator. 0 1997 Elsevier ScienceB.V. Knowledge-based simulation; Automatic program synthesis; Object-oriented programming; Expert systems; Discrete-event systems
Keywords:
1. Introduction
The system presented in this paper is a knowledge-based simulation system (KBSS) designed to assist airport terminal managers in allocating check-in counter resources. KBSS are systems that combine expert system with simulation technology to make simulation studies easier to perform for non-technical people [23]. This type of system has been used successfully in many different domains [2-4,6,19]. One key advantage is that the user will not need any special training to experiment with simulation and benefit from simulation analysis. The KBSS described in this 1 email: [email protected] 0928-4869/97/$17.00 0 1997 Elsevier Science B.V. All rights reserved PII SO928-4869(96)00018-3
474
H. W. Chun / Simulation
Practice
and Theory
5 (1997)
473-488
paper is called the SPEEDCHECK Profile Simulator. It is an integrated component of a constraint-based [ 8,13,25,27] check-in counter allocation system [ 10,151 called SPEEDCHECK. The Profile Simulator is encoded with all the domain expertise and simulation knowledge needed to automatically generate, run, and animate simulation programs related to airport check-in counter allocation. Although the system was tested and used at the Hong Kong International Airport, the framework is general enough to be portable to other airports as well by simply updating the knowledge-base. Using Merkuryeva and Merkuryev’s classification scheme [ 171, our system is considered as a “hybrid” KBSS. Hybrid knowledge-based simulation systems will usually consist of intelligent graphic user interface (GUI) front-ends to existing simulation packages. They are domain dependent - designed to solve a very specific problem. Most often, the expert system technology used will be rule-based reasoning. Our Profile Simulator matches this description quite well. It is a Microsoft Windows application with an intelligent object-oriented GUI built with Common Lisp and CLOS [ 12,20,22,26]. This is a front-end to the SIMAN simulation package [9,14]. The Profile Simulator is designed to specifically solve check-in counter allocation problems. The expert system technology used by the Profile Simulator is a rulebased OPS5 system [7].
2. Airport check-in counter allocation The Profile Simulator is used by managers responsible for the daily allocation of check-in counters to airlines and handling agents. It predicts the number of check-in counter resources required in each time interval for each departing flight. This prediction serves as the input to a constraint-based scheduling system that then determines the exact location of each of the required counters. The Hong Kong International Airport is the third busiest international airport in the world, with around 150,000 flights per year and servicing around 75,000 passengers daily. However, due to the physical limitations of the airport terminal building, there is only a limited number of check-in counters available for each flight. These counters are owned and managed centrally by the local aviation authority which makes daily assignments of counters to airlines or their designated handling agents. The aviation authority is faced with a daily problem of deciding how many and which counters should be assigned to each departing flight in order to adequately service all the passengers. Currently, check-in counter allocation is performed manually by human schedulers. With the ever increasing traffic at this busy airport, the terminal facilities are being utilised to their maximum limits. The human schedulers find it increasingly more difficult and time consuming to develop a schedule that can satisfy all the airport constraints. Due to the computational complexity involved, factors such as variations in passenger arrival rates and check-in counter service rates due to different time of the day, destination, or airline, are usually ignored by the human schedulers. Hence the resource requirements used for manual scheduling are only generalisations
H. W. Chun J Simulation
Practice
and Theory
5 (1997)
473-488
475
and approximations. The resulting allocation schedule generated by a human may not necessarily reflect the true service requirements of each flight. The Profile Simulator KBSS was developed to provide a more accurate prediction of resource requirements without the need for the human schedulers to be trained in simulation theory. Encoded into the system is a knowledge base of the check-in counter domain and a knowledge of simulation analysis. Using this knowledge, the system can automatically produce a precise prediction of the actual amount of resources needed. Therefore, the schedule generated will utilise airport facilities more effectively. In the past, the human scheduler would assign counters based largely on airline requests. For example, an airline might arbitrarily request “5 counters over 3 hours” for a particular flight. The human scheduler has no way of determining whether this is reasonable or not, or how to trim this request if check-in counters are not enough. The Profile Simulator, on the other hand, will automatically determine the “minimum” number of counters needed that can adequately check in all the passengers within the committed service performance specified by the aviation authority. For example, the output of the Profile Simulator might be a proposal such as “open 3 counters for 15 minutes, then 4 for the next hour, 5 for the following hour and 3 for the remaining period”. This is much more precise and accurate than the human approach. 3. The profile simulator
The Profile Simulator is part of an airport check-in counter allocation system (see Fig. 1). It is used mainly to determine the minimal number of check-in counters that should be allocated while keeping within the committed service standards. This information is used in conjunction with the seasonal flight schedule to perform seasonal planning. The results from seasonal planning are then used as “templates” to guide the daily planning. The graphic user interface (GUI) to the Profile Simulator consists mainly of two parts (refer to Fig. 2). The right-hand side of the GUI displays the simulation result as an animation of passengers queuing in front of each check-in counter. Since there may be numerous flights to simulate, the animation must be fast. For speed, we selected two-dimensional graphics which is appropriate since the check-in counter problem is only two-dimensional. On top of the queuing simulation graphics is a running statistics of the number of travellers served, the average queue time, the average service time, and the maximum queue length [ 111. On top of this is an animated graph that shows how the queue length changes with the simulation time. In order to make the GUI easier to understand and relate to, it was designed to mimic the interface found on standard audio CD or cassette tape deck. The lefthand side of the GUI is where the user can provide information specific to the current flight being analysed and the check-in counter resource allocation to be tested. Most of the values can be quickly changed using pull-down menus. The lower left-hand portion of the GUI is used to define the resource allocation for this flight or what we call the check-in counter projile. The check-in counter projile
Airlines
Airlines
Simulalor System Parameter Files
Profile
Profile
Simulafor
Fig. 1. The check-in counter allocation system.
Minimial Check-in Counter Profile
Check-in Seasonal
Counter Plannina
Airlines
Check-in Coon/w Daily Planning
Airlines
H. W. Chun / Simulation
Practice
Fig. 2. The Profile
and Theory
5 (1997)
473-488
411
Simulator.
specifies the total duration that counters should be opened for this flight and the number of counters to be opened in each time interval. For example, the check-in counter profile displayed in Fig. 2 specifies that counters should be opened for 3 hours total - 2 counters should be opened in the first hour of operation, then 5 counters, and finally 8 counters in the third and last hour. Using the Profile Simulator GUI, the user can experiment with different check-in counter projiles and simulate the predicted queuing conditions for each projiie until he finds one that meets his goals. The simulation goals are usually defined as a maximum threshold for the queue length or queue waiting time. This mode of operating the Profile Simulator is called the allocation simulation mode. A second alternate approach is to have the Profile Simulator propose a check-in counter projile by automatically and recursively adjusting the counter allocation and running simulations until the simulation goals are met. This second mode of using the Profile Simulator is called the resource prediction mode. Both modes will be explained in detail in the following sections. The main facilities offered by the Profile Simulator can be summarised into the following three main points: l Provide modelling facility. To make simulation modelling easier for the resource manager, the Profile Simulator contains detailed knowledge of the problem domain
478
l
l
H. W. Chun / Simulation
Practice
and Theory
5 (1997)
473-4888
and simulation model. Part of the model is specified by the user through the Profile Simulator GUI. Design and run experiments. The experiments are designed automatically using a combination of the knowledge base and user provided parameter values. Standard default values are provided by the system. The graphic animation of experiments can be executed interactively. Changes in statistical parameters are also displayed according to the simulator clock. Perform analysis. The user can either visually analyse the simulation result manually or have the system automatically analyse the result to determine whether the simulation goals were met. It will detect what caused a goal failure and automatically make adjustments to the simulation experiment.
4. System architecture In a KBSS such as the Profile Simulator, the system contains detailed knowledge of not only the problem domain but also the simulation system. It knows about the simulation goals and how to modify the simulation parameters to achieve these goals. The user only needs to provide basic information and the Profile Simulator will automatically find the solution. The Profile Simulator actually does better by providing two different modes of operation - the allocation simulation mode and the resource prediction mode. 4.1. Allocation simulation mode
The components involved in the allocation simulation mode is illustrated in Fig. 3. The key components are the SIMAN simulation engine, the simulation parameters, and the intelligent front-end. The user provides the flight information and the resource allocation. Flight information includes the airline, destination, number of
Flight
Parameters
Fig. 3. The components
of SPEEDCHECK
Profile
Simulator
used in the allocation
simulation
mode.
H. W. Chun / Simulation
Practice
and Theory
5 (1997)
473-488
419
passengers boarding locally, time of the day, etc. Resource allocation is the check-in counter allocation projik; that is, how many counters should be opened and the total duration that counters are to be opened to service this flight. The Intelligent Front-end of the Profile Simulator consists of the Expert System Module and a Simulation Constructor Module. The Simulation Constructor Module takes results from the Expert System Module and the simulation parameters to construct a simulation model and experiment. This experiment is then processed by SIMAN. Parts of the simulation parameters are extracted and defined by the resource allocation information specified by the user. The other parts of the simulation parameters are the standard or average airport statistics. This includes the average service rate, average arrival profile, etc. Results from SIMAN processing are then displayed back to the user as animated graphics. The structure of the Profile Simulator is very similar to other KBSS where there is a separate data base, knowledge base, and control structure. In the Profile Simulator, the data base is the simulation parameters, the knowledge base is contained in the Expert System Module, and the control structure in embedded in the Simulation Constructor Module. The key artificial intelligence (AI) component in the Profile Simulator is the Expert System Module. This module contains of a set of rules or heuristics that captures subtle variations in the airport statistics based upon destination, airline, and time of day. Each piece of heuristics may affect either the predicted processing time or the passenger arrival profile. The Expert System Module makes the Profile Simulator portable among different airports by storing all site-specific knowledge in one place. To customise the Profile Simulator for a different airport, all that has to be done is to update the rules within the Expert System Module [ 1,161. 4.1.1. Rules that deal with check-in time The following are examples of the types of heuristics that can be encoded into the Profile Simulator. These examples are for illustration only and may not necessarily reflect the actual operation at any particular airport. Below are two examples of rules related to the amount of baggage and how it will affect the check-in time: Rule Dl: Result:
Travellers to Philippines and India may bring a lot of baggage. Use a higher value for the service rate during simulation.
and Rule D2: Result:
Travellers to Europe may bring more than average number of baggage. Use a slightly higher value for the service rate during simulation.
The above two rules are very similar except for the fuzzy quantifier of the amount of baggage to be checked in - “a lot of” versus “more than average number of”. The Profile Simulator does not use a full fuzzy logic system [28] but it allows rules to be defined with fuzzy quantifiers to make them easier to understand and maintain. Both of the previous two rules will affect the service rate used for the simulation.
480
H. W. Chun / Simulation
Practice
and Theory
5 (1997)
473-488
Internally, the actual value of the service rate used is computed based on a table of fuzzy quantifier mapping to percentage of change in service rate. The following is another type of rule related to destination which will also affect the service rate: Rule D3: Result:
Travellers heading to Canada and the United States of America will require more stringent passport and visa checking. Use a higher value for the service rate during simulation.
The specific airline or handling agent operating the counters may have an effect on the check-in time due to different levels of service or experience. An example heuristic related to an airline might look like: Rule Al: RMllt:
Cathay Pacific will take a slightly longer than average time to process a passenger. Use a slightly higher value for the service rate during simulation.
4.1.2. Rules that deal with arrival time
A second category of rules defines situations that will affect the passenger arrival rate or the arrival profile. For example, the time of departure, or the time of the day, of a flight will affect the passenger arrival profile. The following two rules illustrate this point: Rule Tl: RCdt:
Travellers tend to arrive much earlier for evening flights. Use a much earlier time for the mean passenger arrival time during simulation.
and Rule T2: ReSUlt:
Travellers tend to arrive slightly later for morning flights. Use a slightly later time for the mean passenger arrival time during simulation.
Another example of a heuristic that will affect the passenger arrival profile is if the flight departs around meal time. Passengers may decide to arrive early to check in and then take their meals at the airport while waiting for boarding time. Rule T3: R6SlltZ
Travellers will arrive slightly earlier around meal time. Use a slightly earlier time for the mean passenger arrival time during simulation.
A set of rules, as those described above, will be applied to the current problem as defined by the tlight information to produce a more accurate set of simulation parameters. The Simulation Constructor Module takes the results from the Expert System Module and automatically composes a simulation model and experiment file that can be processed by SIMAN. After viewing the simulation animation, the user may tme-tune his check-in counter projile and run a new simulation. Usually, the user will have a certain set of goals
H. W. Chun / Simulation
Practice
and Theory
5 (1997)
473-488
481
or criteria to meet, such as the maximum queue length at any one time cannot be too long or the average waiting time cannot be above a certain number. In the allocation simulation mode, the user can iteratively try different variations of counter projiles until his goals are met. Alternatively, he may use the allocation simulation mode to experiment with different counter projiles to test “what-if” scenarios. A second approach is to use the Profile Simulator’s resource prediction mode that will automatically determine an appropriate check-in counter projiZe given a set of simulation goals. This mode is described in the following section. 4.2, Resource prediction mode
The resource prediction mode is similar to the allocation simulation mode with the addition of an intelligent back-end (Fig. 4). The back-end consists of a Result Analyser Module that compares the results generated by SIMAN and the simulation goals as defined by the user. The results of the analysis will be used as feedback to adjust the simulation parameters. The affected parameters are those that define the resource allocation, that is, the check-in counter projile. The user may provide an initial proposal of resource allocation and then let the Profile Simulator fine-tune this profile until all the simulation goals are met. The end result is a “minimum” check-in counter profile that will satisfy the operational requirements. The algorithm that performs this search for minimum check-in counter projiile is similar to that of binary sort. We progressively divide the search space, by incrementing or decrementing the number of counters per time interval until the check-in counter projile with the minimum number of total counter-minutes that satisfies the simulation goals is found. 4.2.1. Simulation goals
The main purpose of the Profile Simulator is to use simulation combined with knowledge-based heuristics to determine how many check-in counters are required
Fig. 4. The components of SPEEDCHECK
Profile Simulator used in the resource prediction mode.
482
H. W. Chun / Simulation
Practice
and Theory
5 (1997)
473-488
for each flight. The number of check-in counters required can range from the minimum as defined by the counter profile to as much as requested or available. Any value within this range will satisfy the operational constraints of the airport that are defined by the simulation goals and constraints. The fundamental constraint is, of course, that there should be enough counters to process all the passengers before counter closing time. Other goals may be the target maximum waiting time and the target maximum queue length. These goals may be airport or airline dependent. For example, an airline may set a lower value for the waiting time to improve its level of service. In addition, the goals may be allocation dependent. For example, the maximum queue length allowed may be longer if the flight is to be allocated to check-in areas that have more physical space for queues. The goals may also be seasonal. During holidays, where there are many more flights than normal, a higher waiting time may be tolerated in order to accommodate all departures.
5. System implementation The key portion of the Profile Simulator was implemented using object-oriented programming techniques [5,18,21] provided by the Common Lisp Object System (CLOS) [12,24,26]. An object-oriented approach will allow us to define different classes of objects as centralised locations to store different types of information related to these objects. We can “view” Profile Simulator objects from three different perspectives: l Simulation Perspective - objects represent simulation entities such as queues, servers, customers, etc. l Expert System Perspective - objects represent objects in the real-world such as check-in counters, airline agents, passengers, etc. l Graphic Perspective - objects represent graphic entities such as circles for passengers, rectangles for counters, etc. A perspective may be defined by subclassing in an object-oriented programming language. Using an object-oriented approach allows us to organise different types of information in a nature and intuitive manner. The information becomes attribute values in class instances. Having information localised in class instances makes software maintenance and debugging much easier - information can be shared among the different perspectives and perspective-specific attribute values can be derived from the shared values if needed. The object instances in the Profile Simulator are created from the flight information and initial resource allocation. The interface to OPS5 is conveniently done by defining class methods or member functions to “assert” instance attribute values as OPS5 facts. Similarly, information needed to construct the SIMAN simulation model and experiments are extracted directly from the relevant class instances. After running SIMAN simulation, the data is read back into the Profile Simulator and animated in the GUI.
H. W. Chun 1 Simulation
Practice
and Theory
5 (1997)
473-488
483
6. Simulation examples
The following are simulation examples of flights with the same number of local boarding passengers and same duration of check-in, but with different destination or time of departure. The examples are used to illustrate how the heuristics in the knowledge-base can provide a better prediction of the resource requirements. 6.1. Case I: Typicalflight
The first example is a flight that does not have any specific information provided by the user except that it has 140 passengers boarding locally and that the check-in counters will be opened for a total of 3 hours. Since no specific airline, destination, or departure time are given, the Profile Simulator will assume airport-specific “default” values for the simulation parameters such as the passenger arrival profile, average service rate, etc. The resulting counter projile proposed by the Profile Simulator is 2-3-4 which means the 2 counters should be opened in the first hour of check-in, then 5 counters for the next hour, and finally 9 counters for the final third hour. For simplicity, the examples will only allow the number of counters to be changed after each hour of operation. Case 1. Flight information: Airline: any No. pax: 140 Counter profile: 2-3-4
Dest.: any Hours open: 3 hours
Dep. time: any
The simulation goal that is used in these examples is that the queue length for 95% of the serviced passengers should be less than 6 passengers long. This goal is an input provided by the user. The result of the simulation is summarised in Fig. 5. The labels Cl-C5 on the plot are the names of five example check-in counters. The time axis starts from 0 minutes to indicate the check-in start time. The vertical axis is the length of the queue at each counter at each minute. From the plot, we can see that the check-in counters are somewhat under-utilised during the first hour of operation. This is due to our simplifying the examples and restricting that counters numbers can only change on an hourly increment. If the number of counters were allowed to change every half hour or fifteen minutes, the counter profiles will utilise the check-in counters more effectively. 6.2. Case 2: Flight with heavy baggage loading
Case 2 is a flight similar to that of Case 1 except the destination is specified by the user as to a city in India. This triggers heuristic Rule Dl that indicates that the
484
H. W. Chun / Simulation
Practice
and Theory
5 (1997)
473-488
Counter Profile 2-3-4 for 3 Hours (typical)
Fig. 5. Profile Simulator results for test case 1.
processing time will be longer for flights to destinations such as India since travellers will usually check in more baggage. Case 2. Flight information: Airline: any No. pax: 140 Counter profile: 2-3-5
Dest. : India Hours open: 3 hours
Dep. time: any
The Expert System Module of the Profile Simulator will adjust a new value for the processing time. The final counter projile proposed by the Profile Simulator is 23-5; representing an approximate 10% increase in the total number of counterminutes available to the travellers (refer to Fig. 6). From the plot, we can see that only a small increase in the total counter-minutes is needed because the previously under-utilised first hour is being utilised more effectively. On the other hand, if the original counter projile of Case 1 was used for this Ilight, as it might have been if a manual approach was used, the total number of travellers that would have been processed by the end of the three hours will only be around 120, which is unacceptable since 20 travellers will still be in the queue or being processed.
H. W. Chun / Simulation
Practice
and Theory
5 (1997)
473-488
485
Counter Profile Z-3-5 for 3 Hours (India)
Fig. 6. Profile
Simulator
results
for test case 2.
6.3. Case 3: Flight with evening departure Case 3 is another flight also similar to that of Case 1 except the flight is scheduled to depart in the evening. This triggers heuristic Rule Tl that indicates that passengers will arrive much earlier for evening flights. Case 3. Flight information: Airline: any No. pax: 140 Counter Profile: 2-3-3
Dest.: any Hours open: 3 hours
Dep. time: pm
The Expert System Module will automatically adjust the passenger arrival profile. The final counter pro$Ze proposed by the Profile Simulator is 2-3-3; representing a reduction in check-in counters during the later part of the check-in period, since travellers will tend to arrive earlier. However, addition counters are not needed in the earlier part of the check-in period since this period was originally under-utilised. If the manual approach used the original counter proJile of Case 1 as resource requirements for this flight, the check-in counters during the third hour of operation will be greatly under-utilised; the queue length will, in many cases, be zero.
486
H. W. Chun
/ Simulation Practice
and Theory
5 (1997)
473-488
Counter Profile 2-3-3 for 3 Hours (evening)
Fig. 7. Profile Simulator results for test case 3.
7. Conclusions This paper documents research in developing a knowledge-based simulation module that can more accurately predict airport check-in counter resource requirements than the current “educated guess” approach used by human schedulers. Based upon testing of the Profile Simulator and its integration with the SPEEDCHECK allocation system using actual flight schedules and data, the allocation results generated are much more efficient than those produced by human schedulers while taking just a fraction of the normal time required. The Profile Simulator is totally portable to different airports by the simple update of the rules in the knowledge-base. Acknowledgements This research was supported in part by a research grant from the City University of Hong Kong. Commercialisation of this system was performed by CityU Consultants Limited. The author would like to thank the Hong Kong Civil Aviation Department for making statistical data on Kai Tak Airport available; Raymond Mak for his assistance in developing the SIMAN interface programs; and Otto Lee for his assistance in developing the OPS5 programs.
H. W. Chun / Simulation
Practice
and Theory
5 (1997)
473-488
487
References [l] H.H. Adelsberger, V.W. Pooch, R.E. Shannon and G.N. Williams, Rule based oriented simulation systems, in: P.A. Luker and H.H. Adelsberger, eds., Intelligent Simulation Environment (SCS, 1986) 107-117. [2] D. Balmer, D. Goodman and G. Doukidis, Integrating expert systems and simulation for decision support, in: Knowledge-based management support systems, G.I. Doukidis, L. Frank and G.1. Miller, eds. (John Wiley and Sons, 1989) 134-160. [3] R.E. Cooley and K. El-Hadad, Dragoman: An expert system to aid users of a simulation model, Simulation 57 (1991) 111-113. [4] A. De Swaan, Real-time expert scheduling in manufacturing, in: G.C. Vansteenkiste, E.J. Kerckhoffs, H. Muller (-Malek) and F. Broeck, eds., Proceedings of the European Simulation Symposium on Intelligent Process Control and Scheduling. Discrete Event Systems (Simulation Councils, Inc., 1990) 1155123. [5] D.L. Eldredge, J.D. McGregor and M.K. Summers, Applying of the object-oriented paradigm to discrete event simulation using the C + + language, Simulation 54 (1990) 83-91. [6] P.A. Fishwick and R.B. Modjeski, eds., Knowledge-Based Simulation: Methodology and Application (Springer, 1991). [7] C.L. Forgy, OPS-5 User’s Manual, Tech. Rept., CMU-CS-81-135, Carnegie-Mellon University, Pittsburgh, PA, 1981. [8] M.S. Fox and S.F. Smith, ISIS: A knowledge-based system for factory scheduling, Expert Systems 1 (1)(1984)25-49. [9] S.V. Hoover and R.F. Perry, Simulation: A Problem-Solving Approach (Addison-Wesley, 1990). [lo] S. Jam, K. Barber and D. Osterfeld, Expert simulation for on-line scheduling, Comm. ACM 33 (1990) 55-60. [ 1l] E.K. Juuso and K. Leiviska, An intelligent user interface for combined simulation and expert systems, in: Proceedings of the European Simulation Multiconference (1990) 300-305. [12] S.E. Keene, Object-Oriented Progrumming in COMMON LISP: A Programmer’s Guide to CLOS (Addison-Wesley, 1989). [13] V. Kumar, Algorithms for constraint satisfaction problems: A survey, AZ Magazine 13 (1) (1992) 32-44. [14] A.M. Law and W.D. Kelton, Simulation Modeling and Analysis (McGraw-Hill, 2nd ed., 1991). [ 151 C. Le Pape, Using object-oriented constraint programming tools to implement flexible “easy-to-use” scheduling systems, in: Proceedings of the NSF Workshop on Intelligent, Dynamic Scheduling for Manufacturing, Cocoa Beach, FL, 1993. [ 161 S. Manivannan and C.D. Pegden, A rule-based simulator for modeling just-in-time manufacturing systems, Simulation (August 1990) 109-117. [ 171 G.V. Merkuryeva and Y.A. Merkuryev, Knowledge based simulation systems - A review, Simulation 62 (2) (1994) 74-89. [ 181 J. Murray, Object-oriented programming in the development of real-time rotorcraft simulations, in: Proceedings of the European Simulation Symposium (1992) 215-219. [ 191 N.R. Nielsen, Applications of artificial intelligence techniques to simulation, in: P.A. Fishwick and R.B. Modjecki, eds., Knowledge-based Simulation. Methodology and Applications (Springer, 1990) 1-19. [20] D.A. Popken, An object-oriented simulation environment for airbase logistics, Simulation 59 (1992) 328-338. [21] F. Puget, Object-oriented constraint programming for transportation problems, in: ILOG Solver Collected Papers (ILOG SA, France, 1994). [22] R.K. Ragade, D. Rush, AS. Elmaghraby and A. Kumar, An object oriented simulation environment, in: Proceedings of the Simulation Multiconference on Artificial Intelligence and Simulation (1991) 4145. [23] T.A. Rathburn and G.J. Weinroth, Desktop simulation: Modeling for managers, Simulation 54 (1991) 316-320.
488
H. W. Chun / Simulation Practice and Theory 5 (1997) 473-488
[24] S. Sevinc and 0. Tanir, DEVS-CLOS: Discrete event modelling in Common LISP object system, in: Proceedings of the European Simulation Multiconference (1990) 306-314. [25] G.L. Steele Jr, The definition and implementation of a computer programming language based on constraints, Ph.D. Thesis, MIT, 1980. [26] G.L. Steele Jr, Common Lisp (Digital Equipment Corporation, 1990). [27] P. Van Hentenryck, Constraint Satisfaction in Logic Programming (MIT Press, 1989). [28] L.A. Zadeh, Commonsense knowledge representation based on fuzzy logic, ERL Memo M83/26, University of California, Berkeley, 1983.
ELSEVIER
aT#EORY
Simulation Practice and Theory 5 (1997) 473-488
Automatic simulation program synthesisusing a knowledge-basedapproach Hon Wai Chun’ Department
of Electronic
Engineering, City University of Hong Kong, Tat Chee Avenue, Kowloon, Hong Kong
Received 25 April 1995; revised 20 March 1996
Abstract This paper describesresearch and development in automatic simulation program synthesis using a knowledge-based approach. Simulation analysis can be a very important tool for people responsible for critical resource management in large organisations. Unfortunately, these management decisions must often be made quickly and on a daily basis. There may not be enough time to involve simulation software developers. The main objective of our system is to make simulation easily accessibleto non-technical management-level people who might not have a background in computer programming or simulation theory. Our knowledgebased simulation system automatically constructs a SIMAN simulation program through an object-oriented graphic user interface and a knowledge-base of domain-specific heuristics implemented in OPS5. The system then executes the simulation program and displays the results as animated graphics. Our research was performed in the domain of airport check-in counter scheduling. This paper describes an overview of the system design and provides examples of the results produced by our knowledge-based simulator. 0 1997 Elsevier ScienceB.V. Knowledge-based simulation; Automatic program synthesis; Object-oriented programming; Expert systems; Discrete-event systems
Keywords:
1. Introduction
The system presented in this paper is a knowledge-based simulation system (KBSS) designed to assist airport terminal managers in allocating check-in counter resources. KBSS are systems that combine expert system with simulation technology to make simulation studies easier to perform for non-technical people [23]. This type of system has been used successfully in many different domains [2-4,6,19]. One key advantage is that the user will not need any special training to experiment with simulation and benefit from simulation analysis. The KBSS described in this 1 email: [email protected] 0928-4869/97/$17.00 0 1997 Elsevier Science B.V. All rights reserved PII SO928-4869(96)00018-3
474
H. W. Chun / Simulation
Practice
and Theory
5 (1997)
473-488
paper is called the SPEEDCHECK Profile Simulator. It is an integrated component of a constraint-based [ 8,13,25,27] check-in counter allocation system [ 10,151 called SPEEDCHECK. The Profile Simulator is encoded with all the domain expertise and simulation knowledge needed to automatically generate, run, and animate simulation programs related to airport check-in counter allocation. Although the system was tested and used at the Hong Kong International Airport, the framework is general enough to be portable to other airports as well by simply updating the knowledge-base. Using Merkuryeva and Merkuryev’s classification scheme [ 171, our system is considered as a “hybrid” KBSS. Hybrid knowledge-based simulation systems will usually consist of intelligent graphic user interface (GUI) front-ends to existing simulation packages. They are domain dependent - designed to solve a very specific problem. Most often, the expert system technology used will be rule-based reasoning. Our Profile Simulator matches this description quite well. It is a Microsoft Windows application with an intelligent object-oriented GUI built with Common Lisp and CLOS [ 12,20,22,26]. This is a front-end to the SIMAN simulation package [9,14]. The Profile Simulator is designed to specifically solve check-in counter allocation problems. The expert system technology used by the Profile Simulator is a rulebased OPS5 system [7].
2. Airport check-in counter allocation The Profile Simulator is used by managers responsible for the daily allocation of check-in counters to airlines and handling agents. It predicts the number of check-in counter resources required in each time interval for each departing flight. This prediction serves as the input to a constraint-based scheduling system that then determines the exact location of each of the required counters. The Hong Kong International Airport is the third busiest international airport in the world, with around 150,000 flights per year and servicing around 75,000 passengers daily. However, due to the physical limitations of the airport terminal building, there is only a limited number of check-in counters available for each flight. These counters are owned and managed centrally by the local aviation authority which makes daily assignments of counters to airlines or their designated handling agents. The aviation authority is faced with a daily problem of deciding how many and which counters should be assigned to each departing flight in order to adequately service all the passengers. Currently, check-in counter allocation is performed manually by human schedulers. With the ever increasing traffic at this busy airport, the terminal facilities are being utilised to their maximum limits. The human schedulers find it increasingly more difficult and time consuming to develop a schedule that can satisfy all the airport constraints. Due to the computational complexity involved, factors such as variations in passenger arrival rates and check-in counter service rates due to different time of the day, destination, or airline, are usually ignored by the human schedulers. Hence the resource requirements used for manual scheduling are only generalisations
H. W. Chun J Simulation
Practice
and Theory
5 (1997)
473-488
475
and approximations. The resulting allocation schedule generated by a human may not necessarily reflect the true service requirements of each flight. The Profile Simulator KBSS was developed to provide a more accurate prediction of resource requirements without the need for the human schedulers to be trained in simulation theory. Encoded into the system is a knowledge base of the check-in counter domain and a knowledge of simulation analysis. Using this knowledge, the system can automatically produce a precise prediction of the actual amount of resources needed. Therefore, the schedule generated will utilise airport facilities more effectively. In the past, the human scheduler would assign counters based largely on airline requests. For example, an airline might arbitrarily request “5 counters over 3 hours” for a particular flight. The human scheduler has no way of determining whether this is reasonable or not, or how to trim this request if check-in counters are not enough. The Profile Simulator, on the other hand, will automatically determine the “minimum” number of counters needed that can adequately check in all the passengers within the committed service performance specified by the aviation authority. For example, the output of the Profile Simulator might be a proposal such as “open 3 counters for 15 minutes, then 4 for the next hour, 5 for the following hour and 3 for the remaining period”. This is much more precise and accurate than the human approach. 3. The profile simulator
The Profile Simulator is part of an airport check-in counter allocation system (see Fig. 1). It is used mainly to determine the minimal number of check-in counters that should be allocated while keeping within the committed service standards. This information is used in conjunction with the seasonal flight schedule to perform seasonal planning. The results from seasonal planning are then used as “templates” to guide the daily planning. The graphic user interface (GUI) to the Profile Simulator consists mainly of two parts (refer to Fig. 2). The right-hand side of the GUI displays the simulation result as an animation of passengers queuing in front of each check-in counter. Since there may be numerous flights to simulate, the animation must be fast. For speed, we selected two-dimensional graphics which is appropriate since the check-in counter problem is only two-dimensional. On top of the queuing simulation graphics is a running statistics of the number of travellers served, the average queue time, the average service time, and the maximum queue length [ 111. On top of this is an animated graph that shows how the queue length changes with the simulation time. In order to make the GUI easier to understand and relate to, it was designed to mimic the interface found on standard audio CD or cassette tape deck. The lefthand side of the GUI is where the user can provide information specific to the current flight being analysed and the check-in counter resource allocation to be tested. Most of the values can be quickly changed using pull-down menus. The lower left-hand portion of the GUI is used to define the resource allocation for this flight or what we call the check-in counter projile. The check-in counter projile
Airlines
Airlines
Simulalor System Parameter Files
Profile
Profile
Simulafor
Fig. 1. The check-in counter allocation system.
Minimial Check-in Counter Profile
Check-in Seasonal
Counter Plannina
Airlines
Check-in Coon/w Daily Planning
Airlines
H. W. Chun / Simulation
Practice
Fig. 2. The Profile
and Theory
5 (1997)
473-488
411
Simulator.
specifies the total duration that counters should be opened for this flight and the number of counters to be opened in each time interval. For example, the check-in counter profile displayed in Fig. 2 specifies that counters should be opened for 3 hours total - 2 counters should be opened in the first hour of operation, then 5 counters, and finally 8 counters in the third and last hour. Using the Profile Simulator GUI, the user can experiment with different check-in counter projiles and simulate the predicted queuing conditions for each projiie until he finds one that meets his goals. The simulation goals are usually defined as a maximum threshold for the queue length or queue waiting time. This mode of operating the Profile Simulator is called the allocation simulation mode. A second alternate approach is to have the Profile Simulator propose a check-in counter projile by automatically and recursively adjusting the counter allocation and running simulations until the simulation goals are met. This second mode of using the Profile Simulator is called the resource prediction mode. Both modes will be explained in detail in the following sections. The main facilities offered by the Profile Simulator can be summarised into the following three main points: l Provide modelling facility. To make simulation modelling easier for the resource manager, the Profile Simulator contains detailed knowledge of the problem domain
478
l
l
H. W. Chun / Simulation
Practice
and Theory
5 (1997)
473-4888
and simulation model. Part of the model is specified by the user through the Profile Simulator GUI. Design and run experiments. The experiments are designed automatically using a combination of the knowledge base and user provided parameter values. Standard default values are provided by the system. The graphic animation of experiments can be executed interactively. Changes in statistical parameters are also displayed according to the simulator clock. Perform analysis. The user can either visually analyse the simulation result manually or have the system automatically analyse the result to determine whether the simulation goals were met. It will detect what caused a goal failure and automatically make adjustments to the simulation experiment.
4. System architecture In a KBSS such as the Profile Simulator, the system contains detailed knowledge of not only the problem domain but also the simulation system. It knows about the simulation goals and how to modify the simulation parameters to achieve these goals. The user only needs to provide basic information and the Profile Simulator will automatically find the solution. The Profile Simulator actually does better by providing two different modes of operation - the allocation simulation mode and the resource prediction mode. 4.1. Allocation simulation mode
The components involved in the allocation simulation mode is illustrated in Fig. 3. The key components are the SIMAN simulation engine, the simulation parameters, and the intelligent front-end. The user provides the flight information and the resource allocation. Flight information includes the airline, destination, number of
Flight
Parameters
Fig. 3. The components
of SPEEDCHECK
Profile
Simulator
used in the allocation
simulation
mode.
H. W. Chun / Simulation
Practice
and Theory
5 (1997)
473-488
419
passengers boarding locally, time of the day, etc. Resource allocation is the check-in counter allocation projik; that is, how many counters should be opened and the total duration that counters are to be opened to service this flight. The Intelligent Front-end of the Profile Simulator consists of the Expert System Module and a Simulation Constructor Module. The Simulation Constructor Module takes results from the Expert System Module and the simulation parameters to construct a simulation model and experiment. This experiment is then processed by SIMAN. Parts of the simulation parameters are extracted and defined by the resource allocation information specified by the user. The other parts of the simulation parameters are the standard or average airport statistics. This includes the average service rate, average arrival profile, etc. Results from SIMAN processing are then displayed back to the user as animated graphics. The structure of the Profile Simulator is very similar to other KBSS where there is a separate data base, knowledge base, and control structure. In the Profile Simulator, the data base is the simulation parameters, the knowledge base is contained in the Expert System Module, and the control structure in embedded in the Simulation Constructor Module. The key artificial intelligence (AI) component in the Profile Simulator is the Expert System Module. This module contains of a set of rules or heuristics that captures subtle variations in the airport statistics based upon destination, airline, and time of day. Each piece of heuristics may affect either the predicted processing time or the passenger arrival profile. The Expert System Module makes the Profile Simulator portable among different airports by storing all site-specific knowledge in one place. To customise the Profile Simulator for a different airport, all that has to be done is to update the rules within the Expert System Module [ 1,161. 4.1.1. Rules that deal with check-in time The following are examples of the types of heuristics that can be encoded into the Profile Simulator. These examples are for illustration only and may not necessarily reflect the actual operation at any particular airport. Below are two examples of rules related to the amount of baggage and how it will affect the check-in time: Rule Dl: Result:
Travellers to Philippines and India may bring a lot of baggage. Use a higher value for the service rate during simulation.
and Rule D2: Result:
Travellers to Europe may bring more than average number of baggage. Use a slightly higher value for the service rate during simulation.
The above two rules are very similar except for the fuzzy quantifier of the amount of baggage to be checked in - “a lot of” versus “more than average number of”. The Profile Simulator does not use a full fuzzy logic system [28] but it allows rules to be defined with fuzzy quantifiers to make them easier to understand and maintain. Both of the previous two rules will affect the service rate used for the simulation.
480
H. W. Chun / Simulation
Practice
and Theory
5 (1997)
473-488
Internally, the actual value of the service rate used is computed based on a table of fuzzy quantifier mapping to percentage of change in service rate. The following is another type of rule related to destination which will also affect the service rate: Rule D3: Result:
Travellers heading to Canada and the United States of America will require more stringent passport and visa checking. Use a higher value for the service rate during simulation.
The specific airline or handling agent operating the counters may have an effect on the check-in time due to different levels of service or experience. An example heuristic related to an airline might look like: Rule Al: RMllt:
Cathay Pacific will take a slightly longer than average time to process a passenger. Use a slightly higher value for the service rate during simulation.
4.1.2. Rules that deal with arrival time
A second category of rules defines situations that will affect the passenger arrival rate or the arrival profile. For example, the time of departure, or the time of the day, of a flight will affect the passenger arrival profile. The following two rules illustrate this point: Rule Tl: RCdt:
Travellers tend to arrive much earlier for evening flights. Use a much earlier time for the mean passenger arrival time during simulation.
and Rule T2: ReSUlt:
Travellers tend to arrive slightly later for morning flights. Use a slightly later time for the mean passenger arrival time during simulation.
Another example of a heuristic that will affect the passenger arrival profile is if the flight departs around meal time. Passengers may decide to arrive early to check in and then take their meals at the airport while waiting for boarding time. Rule T3: R6SlltZ
Travellers will arrive slightly earlier around meal time. Use a slightly earlier time for the mean passenger arrival time during simulation.
A set of rules, as those described above, will be applied to the current problem as defined by the tlight information to produce a more accurate set of simulation parameters. The Simulation Constructor Module takes the results from the Expert System Module and automatically composes a simulation model and experiment file that can be processed by SIMAN. After viewing the simulation animation, the user may tme-tune his check-in counter projile and run a new simulation. Usually, the user will have a certain set of goals
H. W. Chun / Simulation
Practice
and Theory
5 (1997)
473-488
481
or criteria to meet, such as the maximum queue length at any one time cannot be too long or the average waiting time cannot be above a certain number. In the allocation simulation mode, the user can iteratively try different variations of counter projiles until his goals are met. Alternatively, he may use the allocation simulation mode to experiment with different counter projiles to test “what-if” scenarios. A second approach is to use the Profile Simulator’s resource prediction mode that will automatically determine an appropriate check-in counter projiZe given a set of simulation goals. This mode is described in the following section. 4.2, Resource prediction mode
The resource prediction mode is similar to the allocation simulation mode with the addition of an intelligent back-end (Fig. 4). The back-end consists of a Result Analyser Module that compares the results generated by SIMAN and the simulation goals as defined by the user. The results of the analysis will be used as feedback to adjust the simulation parameters. The affected parameters are those that define the resource allocation, that is, the check-in counter projile. The user may provide an initial proposal of resource allocation and then let the Profile Simulator fine-tune this profile until all the simulation goals are met. The end result is a “minimum” check-in counter profile that will satisfy the operational requirements. The algorithm that performs this search for minimum check-in counter projiile is similar to that of binary sort. We progressively divide the search space, by incrementing or decrementing the number of counters per time interval until the check-in counter projile with the minimum number of total counter-minutes that satisfies the simulation goals is found. 4.2.1. Simulation goals
The main purpose of the Profile Simulator is to use simulation combined with knowledge-based heuristics to determine how many check-in counters are required
Fig. 4. The components of SPEEDCHECK
Profile Simulator used in the resource prediction mode.
482
H. W. Chun / Simulation
Practice
and Theory
5 (1997)
473-488
for each flight. The number of check-in counters required can range from the minimum as defined by the counter profile to as much as requested or available. Any value within this range will satisfy the operational constraints of the airport that are defined by the simulation goals and constraints. The fundamental constraint is, of course, that there should be enough counters to process all the passengers before counter closing time. Other goals may be the target maximum waiting time and the target maximum queue length. These goals may be airport or airline dependent. For example, an airline may set a lower value for the waiting time to improve its level of service. In addition, the goals may be allocation dependent. For example, the maximum queue length allowed may be longer if the flight is to be allocated to check-in areas that have more physical space for queues. The goals may also be seasonal. During holidays, where there are many more flights than normal, a higher waiting time may be tolerated in order to accommodate all departures.
5. System implementation The key portion of the Profile Simulator was implemented using object-oriented programming techniques [5,18,21] provided by the Common Lisp Object System (CLOS) [12,24,26]. An object-oriented approach will allow us to define different classes of objects as centralised locations to store different types of information related to these objects. We can “view” Profile Simulator objects from three different perspectives: l Simulation Perspective - objects represent simulation entities such as queues, servers, customers, etc. l Expert System Perspective - objects represent objects in the real-world such as check-in counters, airline agents, passengers, etc. l Graphic Perspective - objects represent graphic entities such as circles for passengers, rectangles for counters, etc. A perspective may be defined by subclassing in an object-oriented programming language. Using an object-oriented approach allows us to organise different types of information in a nature and intuitive manner. The information becomes attribute values in class instances. Having information localised in class instances makes software maintenance and debugging much easier - information can be shared among the different perspectives and perspective-specific attribute values can be derived from the shared values if needed. The object instances in the Profile Simulator are created from the flight information and initial resource allocation. The interface to OPS5 is conveniently done by defining class methods or member functions to “assert” instance attribute values as OPS5 facts. Similarly, information needed to construct the SIMAN simulation model and experiments are extracted directly from the relevant class instances. After running SIMAN simulation, the data is read back into the Profile Simulator and animated in the GUI.
H. W. Chun 1 Simulation
Practice
and Theory
5 (1997)
473-488
483
6. Simulation examples
The following are simulation examples of flights with the same number of local boarding passengers and same duration of check-in, but with different destination or time of departure. The examples are used to illustrate how the heuristics in the knowledge-base can provide a better prediction of the resource requirements. 6.1. Case I: Typicalflight
The first example is a flight that does not have any specific information provided by the user except that it has 140 passengers boarding locally and that the check-in counters will be opened for a total of 3 hours. Since no specific airline, destination, or departure time are given, the Profile Simulator will assume airport-specific “default” values for the simulation parameters such as the passenger arrival profile, average service rate, etc. The resulting counter projile proposed by the Profile Simulator is 2-3-4 which means the 2 counters should be opened in the first hour of check-in, then 5 counters for the next hour, and finally 9 counters for the final third hour. For simplicity, the examples will only allow the number of counters to be changed after each hour of operation. Case 1. Flight information: Airline: any No. pax: 140 Counter profile: 2-3-4
Dest.: any Hours open: 3 hours
Dep. time: any
The simulation goal that is used in these examples is that the queue length for 95% of the serviced passengers should be less than 6 passengers long. This goal is an input provided by the user. The result of the simulation is summarised in Fig. 5. The labels Cl-C5 on the plot are the names of five example check-in counters. The time axis starts from 0 minutes to indicate the check-in start time. The vertical axis is the length of the queue at each counter at each minute. From the plot, we can see that the check-in counters are somewhat under-utilised during the first hour of operation. This is due to our simplifying the examples and restricting that counters numbers can only change on an hourly increment. If the number of counters were allowed to change every half hour or fifteen minutes, the counter profiles will utilise the check-in counters more effectively. 6.2. Case 2: Flight with heavy baggage loading
Case 2 is a flight similar to that of Case 1 except the destination is specified by the user as to a city in India. This triggers heuristic Rule Dl that indicates that the
484
H. W. Chun / Simulation
Practice
and Theory
5 (1997)
473-488
Counter Profile 2-3-4 for 3 Hours (typical)
Fig. 5. Profile Simulator results for test case 1.
processing time will be longer for flights to destinations such as India since travellers will usually check in more baggage. Case 2. Flight information: Airline: any No. pax: 140 Counter profile: 2-3-5
Dest. : India Hours open: 3 hours
Dep. time: any
The Expert System Module of the Profile Simulator will adjust a new value for the processing time. The final counter projile proposed by the Profile Simulator is 23-5; representing an approximate 10% increase in the total number of counterminutes available to the travellers (refer to Fig. 6). From the plot, we can see that only a small increase in the total counter-minutes is needed because the previously under-utilised first hour is being utilised more effectively. On the other hand, if the original counter projile of Case 1 was used for this Ilight, as it might have been if a manual approach was used, the total number of travellers that would have been processed by the end of the three hours will only be around 120, which is unacceptable since 20 travellers will still be in the queue or being processed.
H. W. Chun / Simulation
Practice
and Theory
5 (1997)
473-488
485
Counter Profile Z-3-5 for 3 Hours (India)
Fig. 6. Profile
Simulator
results
for test case 2.
6.3. Case 3: Flight with evening departure Case 3 is another flight also similar to that of Case 1 except the flight is scheduled to depart in the evening. This triggers heuristic Rule Tl that indicates that passengers will arrive much earlier for evening flights. Case 3. Flight information: Airline: any No. pax: 140 Counter Profile: 2-3-3
Dest.: any Hours open: 3 hours
Dep. time: pm
The Expert System Module will automatically adjust the passenger arrival profile. The final counter pro$Ze proposed by the Profile Simulator is 2-3-3; representing a reduction in check-in counters during the later part of the check-in period, since travellers will tend to arrive earlier. However, addition counters are not needed in the earlier part of the check-in period since this period was originally under-utilised. If the manual approach used the original counter proJile of Case 1 as resource requirements for this flight, the check-in counters during the third hour of operation will be greatly under-utilised; the queue length will, in many cases, be zero.
486
H. W. Chun
/ Simulation Practice
and Theory
5 (1997)
473-488
Counter Profile 2-3-3 for 3 Hours (evening)
Fig. 7. Profile Simulator results for test case 3.
7. Conclusions This paper documents research in developing a knowledge-based simulation module that can more accurately predict airport check-in counter resource requirements than the current “educated guess” approach used by human schedulers. Based upon testing of the Profile Simulator and its integration with the SPEEDCHECK allocation system using actual flight schedules and data, the allocation results generated are much more efficient than those produced by human schedulers while taking just a fraction of the normal time required. The Profile Simulator is totally portable to different airports by the simple update of the rules in the knowledge-base. Acknowledgements This research was supported in part by a research grant from the City University of Hong Kong. Commercialisation of this system was performed by CityU Consultants Limited. The author would like to thank the Hong Kong Civil Aviation Department for making statistical data on Kai Tak Airport available; Raymond Mak for his assistance in developing the SIMAN interface programs; and Otto Lee for his assistance in developing the OPS5 programs.
H. W. Chun / Simulation
Practice
and Theory
5 (1997)
473-488
487
References [l] H.H. Adelsberger, V.W. Pooch, R.E. Shannon and G.N. Williams, Rule based oriented simulation systems, in: P.A. Luker and H.H. Adelsberger, eds., Intelligent Simulation Environment (SCS, 1986) 107-117. [2] D. Balmer, D. Goodman and G. Doukidis, Integrating expert systems and simulation for decision support, in: Knowledge-based management support systems, G.I. Doukidis, L. Frank and G.1. Miller, eds. (John Wiley and Sons, 1989) 134-160. [3] R.E. Cooley and K. El-Hadad, Dragoman: An expert system to aid users of a simulation model, Simulation 57 (1991) 111-113. [4] A. De Swaan, Real-time expert scheduling in manufacturing, in: G.C. Vansteenkiste, E.J. Kerckhoffs, H. Muller (-Malek) and F. Broeck, eds., Proceedings of the European Simulation Symposium on Intelligent Process Control and Scheduling. Discrete Event Systems (Simulation Councils, Inc., 1990) 1155123. [5] D.L. Eldredge, J.D. McGregor and M.K. Summers, Applying of the object-oriented paradigm to discrete event simulation using the C + + language, Simulation 54 (1990) 83-91. [6] P.A. Fishwick and R.B. Modjeski, eds., Knowledge-Based Simulation: Methodology and Application (Springer, 1991). [7] C.L. Forgy, OPS-5 User’s Manual, Tech. Rept., CMU-CS-81-135, Carnegie-Mellon University, Pittsburgh, PA, 1981. [8] M.S. Fox and S.F. Smith, ISIS: A knowledge-based system for factory scheduling, Expert Systems 1 (1)(1984)25-49. [9] S.V. Hoover and R.F. Perry, Simulation: A Problem-Solving Approach (Addison-Wesley, 1990). [lo] S. Jam, K. Barber and D. Osterfeld, Expert simulation for on-line scheduling, Comm. ACM 33 (1990) 55-60. [ 1l] E.K. Juuso and K. Leiviska, An intelligent user interface for combined simulation and expert systems, in: Proceedings of the European Simulation Multiconference (1990) 300-305. [12] S.E. Keene, Object-Oriented Progrumming in COMMON LISP: A Programmer’s Guide to CLOS (Addison-Wesley, 1989). [13] V. Kumar, Algorithms for constraint satisfaction problems: A survey, AZ Magazine 13 (1) (1992) 32-44. [14] A.M. Law and W.D. Kelton, Simulation Modeling and Analysis (McGraw-Hill, 2nd ed., 1991). [ 151 C. Le Pape, Using object-oriented constraint programming tools to implement flexible “easy-to-use” scheduling systems, in: Proceedings of the NSF Workshop on Intelligent, Dynamic Scheduling for Manufacturing, Cocoa Beach, FL, 1993. [ 161 S. Manivannan and C.D. Pegden, A rule-based simulator for modeling just-in-time manufacturing systems, Simulation (August 1990) 109-117. [ 171 G.V. Merkuryeva and Y.A. Merkuryev, Knowledge based simulation systems - A review, Simulation 62 (2) (1994) 74-89. [ 181 J. Murray, Object-oriented programming in the development of real-time rotorcraft simulations, in: Proceedings of the European Simulation Symposium (1992) 215-219. [ 191 N.R. Nielsen, Applications of artificial intelligence techniques to simulation, in: P.A. Fishwick and R.B. Modjecki, eds., Knowledge-based Simulation. Methodology and Applications (Springer, 1990) 1-19. [20] D.A. Popken, An object-oriented simulation environment for airbase logistics, Simulation 59 (1992) 328-338. [21] F. Puget, Object-oriented constraint programming for transportation problems, in: ILOG Solver Collected Papers (ILOG SA, France, 1994). [22] R.K. Ragade, D. Rush, AS. Elmaghraby and A. Kumar, An object oriented simulation environment, in: Proceedings of the Simulation Multiconference on Artificial Intelligence and Simulation (1991) 4145. [23] T.A. Rathburn and G.J. Weinroth, Desktop simulation: Modeling for managers, Simulation 54 (1991) 316-320.
488
H. W. Chun / Simulation Practice and Theory 5 (1997) 473-488
[24] S. Sevinc and 0. Tanir, DEVS-CLOS: Discrete event modelling in Common LISP object system, in: Proceedings of the European Simulation Multiconference (1990) 306-314. [25] G.L. Steele Jr, The definition and implementation of a computer programming language based on constraints, Ph.D. Thesis, MIT, 1980. [26] G.L. Steele Jr, Common Lisp (Digital Equipment Corporation, 1990). [27] P. Van Hentenryck, Constraint Satisfaction in Logic Programming (MIT Press, 1989). [28] L.A. Zadeh, Commonsense knowledge representation based on fuzzy logic, ERL Memo M83/26, University of California, Berkeley, 1983.