FACTORY SIMULATION ACROSS THE WORLD WIDE WEB USING ...

FACTORY SIMULATION ACROSS THE WORLD WIDE WEB USING JAVA Pauline Wilcox and Rob Pooley Department of Computer Science University of Edinburgh Kings Buildings, Edinburgh EH9 3JZ United Kingdom rjp or [email protected]

Abstract

This project is concerned with the development of a distributed, multi-user Internet based simulation environment for automated factories, written in Java. The motivating factor behind the work described is the rapid development in computer controlled automated production lines, which has led to increasing complexity of scheduling of these systems. To avoid the costs in moving expert modellers and Operational Research sta to factory sites, a means for working in a geographically distributed manner is desirable. The environment described here provides that. Its bene ts are shown through a case study and ideas for future work are explored.

MOTIVATION Simulation has been shown to be a successful means of expressing and investigating problems in a wide range of elds and recently interest in simulations of automated factories has grown. In particular the graphical presentation of a simulation model has advantages over a more basic trace output, since the results are immediately more expressive to those viewing the simulation. The construction of simulation models still requires a large degree of skill and specialist knowledge. It is therefore reasonable to assume the involvement of a team of simulation and modelling analysts. Since few companies will have such a team available on every site where they have factories, this team will usually need to be brought in either from the Operational Research Department, in a large organisation, or from an outside consultancy, in

the case of most small rms. The time of such experts is very valuable and wasting it in travelling to and from the site is a considerable overhead. There is no shortage of examples of simulation packages suitable for modelling factory operations. Some examples include SIMAN (Pegden et al 1990), SimFactory (Tumay 1987) and Hocus (Heppolette 1993). What distinguishes the work in this paper from these is the incorporation of simulation within a system that allows remote interaction of interested parties. Internet technology, through the Java language and the World Wide Web, provides a simulation system where users and analysts explore issues remotely, thereby avoiding the need for unnecessary travel and reducing costs, and hopefully time taken to reach a solution.

PROJECT AIMS

The principal aim of the project can be summarised as producing a system that would allow multiple users to interact remotely and solve issues relating to automated factories. The system is object-oriented in design, and implemented using the Java language, leading to a system that can be accessed via the Internet. The issues concerning the factory oor are expressed using a graphical simulation system, supporting animation. Work began by producing a prototype, to illustrate the ideas and functionality, though perhaps not in the nal polished and robust form that would be preferred in the nal system. The use of object oriented techniques allowed easy incorporation of existing work in simulation using Java, notably the simjava package, produced by

Fred Howell at Edinburgh (Howell 1996).

APPROACH TO DESIGN AND IMPLEMENTATION The approach to design and implementation was to consider the system split into three components : Architecture which describes how the various modules would be connected and con gured; a client/server architecture was used, since this is the one best supported by the Java view of interaction; Communication/Dialogue which describes how users of the system interact to cooperate in reaching a decision; Simulation which de nes how the simulation models in the system are created and run. A survey of successful software on the Internet identi ed a common `game' theme amongst the majority of Java programs there. This analogy of viewing the system as a multi-user game tted the project well. An important part of the initial design focussed on identi cation of the valid player moves and describing sample scenarios to see how the game would react/unfold. The desired functionality of the proposed system was identi ed as follows: 1. allow users to load and view existing simulations, achieving a consistent view at dierent locations; 2. allow interaction with simulation through controlled execution and editing facilities; 3. allow users to interact with one another; 4. allow users to evaluate simulation and problem scenarios. It was accepted that fully graphical online editing of the model was out-with the scope of the prototype. Earlier work had shown that this could be achieved using tools written in Java (McNab 1997) and that it could be incorporated into a nal product. Editing in the prototype is restricted to altering system parameters rather than physical recon guration online. This was not considered a major setback, as it is still possible for one of the users to edit the model on their local machine and place the resulting executable model into the database of models visible to those using the environment. This new model can be loaded in place of the original, achieving the overall goal of experimenting with variations on the system being analysed.

The de nition of interaction between players and the simulation was given careful consideration. The decision was to have a main controlling player at any one time, acting as a kind of super user. This super user would take part in dialogue with other players to determine which simulation to load and execute (this is on the assumption that variations of a given model may exist). For simplicity and consistency the super user would retain control over the simulation component of the system, although some means of transferring this control to another designated player was necessary. In this way the system could ensure all players were seeing a consistent view of the game state. The identi cation of the super user determines the ow of the game control i.e. identifying whose turn it is at any given time.

CONSTRUCTION After investigating alternatives the Java Remote Method Invocation (RMI) approach was chosen as the basis for the required client-server architecture. The basis of the RMI framework was taken from code already developed by Fred Howell in the Department of Computer Science at Edinburgh University. This was adapted by adding the player dialogue and simulation interaction, and modifying the applet layout accordingly. The objects de ned remote are those that need to communicate with one another. There are two remote objects in the prototype architecture: Server Side : SimChatServer is an instance of the SimChatImpl class. Since the server is at the core of all communication it is de ned remote. Client Side : SimChatApplet has a remote object in the form of a component panel, SimChatPanel, which passes commands to the server. SimChatPanel and SimChatServer are therefore responsible for carrying out the necessary communication between client and server. The unit of communication is the command. A command is triggered via the applet and communicated by SimChatPanel to SimChatServer. The server maintains a list of connected players, and each player applet has an associated list of commands in the form of a CommandQueue object. Commands received by the server are placed in the CommandQueue object for each of the clients. This stream-lines the client-server interface; reducing the server responsibility to passing on commands.

SimChatApplet SimChatPanel CommandQueue

SimChatServer

SimChatApplet SimChatPanel CommandQueue

SimChatApplet SimChatPanel CommandQueue

Figure 1: Commands passing between Client and Server It is the responsibility of the client applet to pick up and process the command from the CommandQueue object. The full range of commands supported are as follows: Add : the client connecting to the server; carried out automatically when the applet is started. Load : the command to load a simulation; this loads the chosen simulation into its own browser window. Xfer : the command to transfer super user status between players. Chat : the submission of a chat command to the server Quit : a player leaving the game and terminating the server connection. The basis for the simulation was chosen to be the simanim package, the applet extension to simjava.

CASE STUDY

To validate both the working of the system and its usefulness in solving realistic problems, a case study was carried out. This took a published example of a real life problem which had been solved by Kiteck (Kiteck 1992) using conventional simulation and animation techniques. A trace

through a dialogue, using the distributed simulation system to solve the same problem as in Kiteck's report, was carried out, assuming that the simulation consultant is physically located at a dierent site from the production engineers. The initial phase of exchanging information and ideas via the chat system worked well for a small number of participants. It showed that an eective way of structuring the problem solving was to agree a decision tree, where nodes de ned alternative approaches to solving the problem. This allowed the participants to share a mental map of the task. This example showed that future enhancements could focus on allowing more ecient exchange of ideas, reducing typing. The building of some sort of decision making map, displayed graphically, seems an attractive enhancement to the system. The problem of keeping track of contributions in a multi-way discussion is well known and also needs further support. Thus, the case study reveals the potential for rapid decision making, but also opens up the need for a means of structuring and supporting the dialogue to reach sensible strategies quickly. In particular it rapidly became clear that the co-operative approach, where all participants remain fully involved in the discussion throughout, is po-

tentially very wasteful of time and resources. Two simple improvements are proposed and will be validated in further work. 1. In many cases it would be possible to divide up alternatives to be explored, either arbitrarily or on the basis of the skills of the participants, so that experiments could be conducted concurrently on dierent sites. This is easiest where only numerical parameters are being varied. 2. It is extremely wasteful for everyone to wait while models are created or edited by the modelling experts. Some way of allowing users to drop out of the dialogue or to continue with other useful work, during such interludes, is needed. Further ideas worthy of consideration include the development of competitive, rather than co-operative paradigms of interaction. These might allow something like competitive tendering, with dierent consultants trying to produce the most eective solution to a problem.

PROJECT ACHIEVEMENTS

At the conclusion of the project a number of achievements can be identi ed. Firstly, a working prototype of the required system has been realized. Although, as expected, the prototype has limited functionality, sucient of the core is present to demonstrate achievement of the initial aims. The system supports multiple players connecting to a central server. Players can join a session with any other players to resolve a problem they share. Players can communicate with one another via a chat dialogue, and view the list of available simulations. A simulation can be chosen and loaded on behalf of all players by the initial super user (the initial super user is determined to be the rst player to connect to the server). Once loaded, each player has a local copy of the simulation which is under their own local control. The facilities already present in simanim allow a degree of interaction, for example starting, stopping and pausing the simulation as well as modi cation of certain operating parameters. A mechanism to transfer super user control to other players is also incorporated.

Through a case study, both the potential for the use of such a system was proved and a number of ideas for improving its eectiveness were identi ed. Overall the project succeeded in the production of a prototype multi-user Internet based simulation system written in Java, to allow users and analysts to interact and explore the problem domain avoiding the need for all the parties involved to be in the same physical location. Although the initial focus of this project was based around a factory simulation the ideas presented could be argued to apply to many problem domains.

FUTURE WORK

Future developments of the system will centre on lessons learned from the prototype and its use. The key questions centre on how best to make use of the interaction of groups with dierent skills and knowledge. This involves both how to co-operate eectively and how to bene t from concurrent work on dierent sites. Minor questions concern integration of better browsing of model databases into the chat facility and full integration of online editing. It is imperative that better support be provided for structuring and recording the dialogue in preliminary stages, in order to generate a decision map. Ideally this could be updated and amended as the project proceeded, rather in the manner of a branch and bound optimisation in traditional operational research. A major question concerns the use of the decision map produced during preliminary discussion to control automatic exploration of alternatives and parameter spaces. This would seem to be a more eective means of exploring questions of optimisation of system throughput, whereas the present graphical orientation is more suited to understanding how to x single breakdowns in systems.

WORLD WIDE WEB REFERENCES

http://biz.onramp.net/javapages/games.htm, Java Game Programming http://www.dcs.ed.ac.uk/home/hase/simjava/simjava1.0/, Simulations in Java http://www.javasoft.com/docs/books/tutorial/index.html, The Java Tutorial http://chatsubo.javasoft.com/current/, Distributed Systems

Miller, D.J. 1990. \Simulation of a Semiconductor http://java.sun.com/docs/index.html, JDK 1.1.3 DocuManufacturing Line". In CACM 33, no. 10 (Oct.):98 108. mentation http://ms.ie.org/websim/survey/survey.html, A Survey Page, E.H.; R.L. Moose and S.P. Grien. \Webof Web Based Simulations based Simulation in SimJava using Remote Method Invocation". Submitted to 1997 Winter Simulation Conference, Atlanta, GA, 7-10 December

REFERENCES

Bartlett, N.; S. Simkin; and C. Stranc. 1996.

Pegden, C.D.; R.E. Shannon and R.P. Sad-

Cutting Edge - java Game Programming. Coriolis Group owsky. Simulation using SIMAN, McGraw-Hill, 1990 Books. Pooley, R.J. 1995. \Object Oriented Simulation Models Modelling". In Proceedings Dunham, N.R.; A.K. Kochhar. 1983. \Ap- UKPEWfor1995Performance . proaches to the Computer Simulation of Production Systems". In Simulation in Inventory and Production Tumay K. \Manufacturing Simulation with SimControl, ed Haluk Bekiroglu Factory". in Proceedings of Conference on Computer Integrated Manufacturing Systems and Robotics, SCS Heppolette, F. \Innovations in Simulation for Western Simulation Multiconference, January 1987 Improving Customer Service and Resource Management". in Pooley and Zobel eds. Proceedings UKSS `93, Supplement, UK Simulation Society

Howell, F.W.; and R. McNab. 1996. \Using Java for Discrete Event Simulation". In Proceedings UK Computer and Telecommunications Performance Engineering Workshop, University of Edinburgh, 219-228 Jain. S.; K. Barber and D. Osterfeld. 1990.

\Expert Simulation for On-line Scheduling". In CACM 33, no. 10 (Oct.):54 60.

Kiteck, P.J. 1992. \Analysis of Component Interaction in a Distribution Facility Using Simulation". In Proceedings EUROSIM 1992, North Holland McNab, R. 1997. A Graphical Construction Tool for Process Based Simulation Models, Honours project report, Department of Computer Science, University of Edinburgh. McNab, R. A Guide to the SimJava Package. Department of Computer Science, The University of Edinburgh. Available from http://www.dcs.ed.ac.uk/home/hase/simjava/ McNab, R. A Guide to the SimAnim Package. Department of Computer Science, The University of Edinburgh. Available from http://home/hase/simjava/

Figure 2: The user dialogue window

Figure 3: The simulation run window