Experiences with process interaction based simulation in education and research H.P.M. Veeke, J.A. Ottjes, G. Lodewijks Dep. of Marine and Transport Technology Faculty of Mechanical, Maritime and Materials Engineering, 3mE Delft University of Technology Mekelweg 2, 2628 CD Delft, the Netherlands E-mail: H.P.M.Veeke@tudelft.nl , J.A.Ottjes@tudelft.nl , G.Lodewijks@tudelft.nl Abstract - This paper describes the development of simulation education and research in an academic environment. From the start – mid 70’s - the real process interaction method has been used. It soon became clear that explaining the principles of simulation is a precarious task. Although the process oriented approach is the most natural way to describe system behavior, it is difficult to explain to students as well as to team members of a design project. Using commercial packages does not help to explain how the model is constructed internally, it merely makes a student an experienced user of the software. We decided to use a general programming platform (Delpi®) and implemented a self- developed simulation tool TOMAS. For communication about the model we developed a gradual translation method: the Process Description Language. This method also enables a student to verify his model and creates greater trust in the quality of a model Keywords: simulation, process interaction, education, research 1 Introduction In about 40 years of educating simulation experience, the way of explaining simulation principles dramatically changed. When we received the first simulation lectures ourselves, the lecturer gave the next introductory explanation of the basics of the process oriented approach. “Suppose we have some industrial system, then we can divide the system into dead and living elements. Only living elements have a process. Let me give you the next example”. And then we started programming examples. The course focused more on programming skills than simulation skills. Only half of the students understood immediately how to make models, the other half did not and would never do. Most simulation projects report on the possibilities of simulation software and successes in applying it to complex business cases. As a consequence of this, many packages are built around a limited number of cases and contain predefined components or objects in order to speed up the development of models in the same application field. Often beautiful visualization tools are emphasized to convince management of the necessity to buy a package. In a university environment however, the requirements on simulation software are quite different. For education purposes it is necessary to know in detail what is inside the package in order to explain the building elements of a model, the timing mechanism and the use of queues and distributions. Commercial packages tend to hide these internal constructs. For research, the requirements are even more different. A researcher requires that he/she is not restricted by the possibilities of a package. The essence of research is to investigate something new, a new conglomerate, which has not been constructed anywhere before. The used platform should offer all possibilities to support this kind of research. Nowadays most students have to master modelling, before they even start to think about simulation. It appears still very difficult to make a connection between the abstract view in modelling and the concrete process descriptions in simulation. The missing link appeared to be a tool that provides stepwise translation. This appeared to be also true during simulation projects in practice; it was often difficult to explain to other project team members how the simulation model is constructed. This is especially important when the system to be designed does not exist yet. The project management and team members are usually asked to trust the model based on animations and (positive) results. Apparently there is a gap between the programming language and natural language, in which we can perfectly explain what we mean with “the behaviour”. Therefore the simulation approach on which the software is based, should closely connect to the way students and project team members are used to build models of technological or logistical systems. It makes the threshold to use and understand simulation lower. And for educational reasons it is required that the teacher can easily verify the conceptual model that students have used for their simulation experiments. Experimenting with graphics and animations does not give the required results. Graphics and animations are in fact the results of the simulation activities, and how