12th European Simulation Multiconference, Manchester, Uk, Discrete Event Simulation in Interactive Scientic and

Size: px

Start display at page:

Download "12th European Simulation Multiconference, Manchester, Uk, Discrete Event Simulation in Interactive Scientic and"

Kory Briggs
6 years ago
Views:

1 12th European Simulation Multiconference, Manchester, Uk, Discrete Event Simulation in Interactive Scientic and Technical Computing Environments T. Pawletta, Wismar University, Germany W. Drewelow, S. Pawletta, University of Rostock, Germany y Keywords: Discrete Event Simulation, Embedded Simulation, SCEs, MATLAB, GPSS Abstract The integration of discrete event simulation methods into Scientic and Technical Computing Environments (SCEs) extends their functionality and opens new ways for a convenient interactive modelling and simulation. Because of the wide range of algorithms provided by SCEs, it also oers lots of possibilities for solving complex problems with simulations in an uniform environment. The paper discusses general approaches and presents their realization by the example of a MATLAB-GPSS toolbox prototype. 1 Introduction Interactive Scientic and Technical Computing Environments (SCEs), like MATLAB [7], Octave [1], SciLAB [2] etc., become more and more important in many application areas and in education [5],[4]. While SCEs were only interactive front ends for numerical and visualisation libraries in the past, modern SCEs are complex computing and programming environments. They provide lots of dierent algorithms, an interactive way of working and a powerful programming language. These features are responsible for the rapid growth in use of SCEs, especially in engineering prototyping and education. In spite of the wide range of algorithms supported by SCEs, there is hardly any support for discrete event simulation methods till today. One reason may be the frequently used argument of higher runtime expenses in comparison to compiler based systems. But a much more critical point is the realization of a convenient modelling language in a SCE, because pawel@mb.hs-wismar.de y sven.pawletta@etechnik.uni-rostock.de, wolfgang.drewelow@etechnik.uni-rostock.de such languages are non-procedural and so their statements cannot be executed straight forward by a SCEinterpreter. For lack of discrete event simulation methods in recent SCEs, data couplings between external simulation systems and SCEs (mostly via ASCII les) are often used to make the abundance of SCE-algorithms available at least for data pre- and post processing. But this approach has major disadvantages. The user has to work in dierent environments and the combination of methods is strongly restricted. Therefore, solving sophisticated tasks, like for instance optimisation loops with embedded simulations, can be very dicult or even impossible. In the face of such problems, it seems to be reasonable to support discrete event simulation methods within SCEs directly. Especial for educational purposes and for applications which really require the combined usage of dierent methods, the resulting higher runtime expenses of SCE based simulations may be of secondary importance. In the following the paper analyses the architecture of SCEs and it discusses the realization of nonprocedural discrete event simulation approaches in general. By the example of the GPSS 1 language it is shown in more detail, how a non-procedural modelling description can be transformed to an executable representation for a SCE-interpreter, and how the simulation can be integrated as a method into more complex experiments. As reference systems the SCE MATLAB 2 and the transaction oriented GPSS language are used. GPSS is still one of the most popular modelling languages for discrete event systems,and many modern simulation tools are based on GPSS 1 GPSS (General Purpose Simulation System) was developed by Gordon at IBM. Today there are several of dierent GPSS implementations with partly dierent syntax and semantics. 2 MATLAB (Matrix Laboratory) is a product of The Math- Works, Inc. Its predecessor Classic MATLAB was developed by C. Moler from 1977 to 1984 and is the root of almost all modern SCEs.

2 12th European Simulation Multiconference, Manchester, Uk, language derivatives. On the other side, MATLAB is one of the most powerful SCEs. Besides the approach of integrating a transaction oriented simulation method into a SCE described in this paper, there are further projects to integrate other discrete simulation techniques, for instance discrete event methods based on extensions of Zeigler's DEVS-theory for variable structure systems [11], or event oriented modelling and simulation on nite state machines (STATEFLOW for MATLAB), see [8]. 2 Architecture of SCEs A modern SCE provides a large number of predened algorithms for numerical, graphical, statistical, symbolical and other analyses techniques, which can be used interactively in one uniform environment. Additionally, a SCE is extendable by user supplied algorithms, which are coded by means of a very powerful integrated programming language. Such a language is array oriented (in some cases extended by object oriented features), supports dynamic data type binding, and its syntax is very similar to mathematical notations. In contrast to classical programming languages (e.g. FORTRAN, C, C++) its primary aim is not to produce memory and runtime optimal code, but to support ecient implementations and tests of complex problems. Together with the ability to execute user dened routines immediately, a SCE constitutes an excellent bases for rapid prototyping. Some SCEs (e.g. MATLAB) introduce additional features to produce faster code for the production phase. One of these features is the compilation of SCE routines into faster meta-code or into an executable stand-alone program. Another way is the dynamic binding of external compiled code. This technique can also be used to couple SCEs with other applications. Figure 1 presents the general architecture of a SCE. Keyboard Input Module Keyboard Parser Interpreter Routine Module (numerical-, statistical-, symbolical-, visualization routines etc.) Dynamic Memory Management (Workspaces) Output Module Figure 1: Architecture of a SCE The core of a SCE are the parser and interpreter Text as well as the routine module. Fundamental and runtime critical system routines are integrated as builtin functions (object code). Other system and user supplied routines are mostly integrated as SCE- or meta-code. The interpreter and the output as well as the input module built the user interface. So instructions can be processed in an interactive mode from a command line or in batch mode from a script le. The output module prints or visualises the results on screen or writes them into a le. The dynamic memory management provides a permanent global workspace and function related temporary local workspaces. A more detailed analysis of SCEs can be found in [9]. 3 General Approaches SCEs are characterised by a sequential execution of instructions. A model specication by means of a non-procedural modelling language is done in a declarative manner. Therefore, such a specication cannot be executed straight forward by a SCE-interpreter. That means the model description has to be transformed into a SCE-internal model representation, called computing model. Then the computing model can be executed under control of a simulation engine, called scheduler. Therefore, an entire simulation consists of a model generation and execution process. The model execution process can be realized in a SCE without diculties. The scheduler algorithm can be implemented using the integrated programming language or { in case of very time critical problems { it can be linked as compiled code into the SCE. Then a simulation run can be started by a scheduler call with the appropriate simulation parameters and a pointer to the internal computing model. For the model generation process there are dierent approaches. One solution is to code a translator as a SCE-routine, which is able to read a model description from le and to generate the internal computing model. This solution is very similar to the conventional compiler based approaches. The disadvantage of this approach is that the SCE native short error correction cycle is lost during modelling. A second approach is to code all modelling commands as separate SCE-routines, which consist of a specic generation and simulation part. That means the model generation process is not concentrated into a single translator routine, but it is spreaded over all model functions. Then only a very simple general initialisation routine is necessary to initialise global data structures. This approach has some advantages during the modelling phase regarding to the interactive way of working.

3 12th European Simulation Multiconference, Manchester, Uk, In most cases experiments require more than a simple simulation run, i.e. the simulation is often an embedded experimentation method. That's why the model execution process should be callable from other methods very easily, and has to provide an interface for model parameter variation as well as for returning simulation results. These features should be called experiment control. The following section will investigate the discussed problems in more detail by examples. 4 Concepts for a MATLAB- GPSS Toolbox The SCE MATLAB and the GPSS language were chosen to prove the discussed approaches. Detailed information about MATLAB and GPSS can be found in [7] and [12]. At rst the mentioned and some additional requirements shall be summerized. The modelling language should be as conform as possible to GPSS and MATLAB, and it should be possible to integrate pure MATLAB statements into a model description. The latter is useful for modelling arithmetical or logical expressions, execution loops, or graphical outputs during the simulation. An easy integration of simulation runs into more complex MATLAB based experiments should be possible. A SCE native way of working should be supported during the modelling as well as simulation process. In the following an entire approach from model generation up to complex experiment control should be presented. After that alternatives will be discussed. 4.1 Model Generation by a Translator Routine The model description has to be specied in a special model le modelname.gps. This model le is read by a translator routine init that generates the internal model representation. In case of MATLAB the internal model can be stored in a string matrix or a structure array, where each row presents the structure of one model statement. If the runtime system implements for each model statement a separate MAT- LAB routine, then they can be evaluated easily by the MATLAB routine eval. Figure 2 presents the model description of a simple multi server system and gure 3 shows the generated internal model representation. The model generation can be performed by the following MATLAB command: >> init('modelname.gps') % multiserver.gps: Model of a multi server Denitions: Inputparameter ('servcap') Outputparameter ('sa') STORAGE ('Multiserver','servCap') % Def. of service time function FUNCTION ('Stime',RN1,'D',4,[.28,2.5;.70,3.5;.85,4.5;1,5.5]) Model: GENERATE (1.5,[],5) stem (AC,1) % MATLAB stem plot QUEUE ('ServerQ') ENTER ('Multiserver') DEPART ('ServerQ') ADVANCE (FN('Stime')) LEAVE ('Multiserver') LOGIC I ('Exit') GATE LS ('Exit','Exit2') % To 'Exit2', if LOGIC o TERMINATE(1) % System Exit1 LABEL ('Exit2') % Set a block label TERMINATE(1) % System Exit2 Outputs: sa = SA('Multiserver') % Set output parameter END Figure 2: Example of a MATLAB-GPSS Model Description Number Label Statement Current Total 1 [] 'GENERATE(1.5,0,5)' [] 'stem(ac,1)' [] 'QUEUE(1)' [] 'ENTER(1,1)' [] 'DEPART(1)' [] 'ADVANCE(FN('Stime',0))' [] 'LEAVE(1,1)' [] 'LOGIC I(1)' [] 'GATE LS(1,12)' [] 'TERMINATE(1)' 'Exit2' 'TERMINATE(1)' 0 0 Figure 3: Finale Structure of a Computing Model In principle the modelling language can dene an arbitrary syntax. In this case one requirement was the realization of a syntax similar to MATLAB and GPSS, which enables the inclusion of pure MATLAB statements like the stem command in the example for producing a graphical output during simulation. Another extension to the GPSS language is the introduction of input and output parameters. They are necessary for more complex experiments, where variable model parameters have to be adjusted or simulation results have to be analysed by a superior experiment method. Summarised, the model generation and initialisation process performs following steps: reading a model description from le; deleting empty lines and comments executing denition statements and initialisation of runtime data structures; re-organization of the internal model representation

4 12th European Simulation Multiconference, Manchester, Uk, performing some optimisations e.g. strings to integers etc. conversion of initialisation of further runtime data structures e.g. for queues, for facilities etc., and the internal event chains generation of the initial transactions 4.2 Runtime System The runtime system consists of three parts: the scheduler algorithm, the state transition routines for the dierent model components, and the routines for collecting statistical data. As described in the previous section it is favourable to implement the behaviour of each model component by a separate MATLAB routine, which is activated by the scheduler. GPSS has introduced the transaction oriented scheduling. A fundamental description of this scheduling strategy can be found in [12]. The dierent possibilities to realize a scheduler algorithm in a SCE have been discussed in section 3. One possibility is its implementation by means of the integrated MATLAB programming language. This is the more runtime consuming variant, but the algorithm is easier to understand for beginners like students, and it is easier to modify the algorithm for further investigations. That's why this method has been used for the prototype implementation. 4.3 Experiment Control A simulation run can be performed after model generation and initialisation by calling the scheduler routine with a pointer to the internal computing model and a parameter that species the termination criterion. The scheduler routine points by default to the last generated internal computing model. A simple simulation run with the default model can be started by the following MATLAB statement: >> schedule(tc_start) The parameter tc start sets the GPSS specic termination criterion, called termination counter. GPSS denes dierent statistical parameters which are calculated after each simulation run. These parameters can be requested by the routine report in the following manner: >> [Q,F,S,...] = report A major requirement of this project is the realization of a convenient coupling of the simulation method with other MATLAB methods. Therefore, the model description has been extended by input and output parameters as described in section 4.1. The simulation execution method schedule performs an appropriate interface for data exchange. >> [outputparameterlist] = schedule(tc_start,... inputparameterlist) By this interface simulations can be coupled with other methods in a MATLAB native manner. Figure 4 presents as example an interactive parameter study with a three dimensional graphic output of the cost function. The called simulation model is similar to the multi server example from gure 2, but extended by a scalable waiting queue capacity. >> % Parameter study of a multi server with limited storage >> % Parameters: server and storage capacity >> % Calc.: costs=f(servercosts,storagecosts,joboutput) >> % >> init('multiserver.gps'); >> for servcap = 1:4, for storcap = 10:10:50, joboutput = schedule(1000,servcap,storcap); joboutputvec = [joboutputvec; joboutput]; end joboutputmat = [joboutputmat; joboutputvec]; end >> costs = -servcap.^2 - storcap.^2 + 5jobOutputMat; >> [servcap,storcap] = meshgrid(1:4,10:10:50); >> surf(servcap,storcap,costs); >> grid, title('cost Function'),... Figure 4: A Simple Interactive Experiment 4.4 Interactive Model Generation The primary aim of interactive model generation is to preserve the SCE native short error correction cycle, i.e. commands are processed immediately by the SCE-interpreter and in case of errors appropriate messages are generated. The discussed approach of model generation by a special translator routine does not support such a way of working. A second approach discussed in section 3 proposes to code all specic generation and calculation aspects of a model command in one MATLAB routine. Then a simple initialisation routine can switch the phase of the commands from generation to execution by a global ag. Furthermore, this routine can provide a modied user prompt by the MATLAB routine input to signal the current phase. Figure 5 presents an example of an interactive model generation and the interactive execution of a simple simulation run. The gpss>> prompt signals the model generation phase, which is switched on by the init command and switched o by the END command. Furthermore, it presents the interactive handling of modelling errors by the example of the QUEUE command. This approach provides a full interactive handling for all GPSS commands. An exception are pure MAT- LAB statements, because they do not own a specic

5 12th European Simulation Multiconference, Manchester, Uk, generation part. That's why they have to be read by a special routine M('commandString'), which generates their internal representation. The current state of model generation can be reported in a separate gure window by writing each generated model statement line by line. Besides the interactive model generation this approach allows le oriented model descriptions, too. Then the model commands have to be arranged in a regular MATLAB script. >> init('multiserver') % Model generation on gpss >> Inputparameter('servCap'); gpss >> Outputparameter('sa'); gpss >> %... further denition statements gpss >> GENERATE(1.5,[],5); gpss >> M('stem(AC,1)'); gpss >> QUEUE; % a wrong command??? Error using =) QUEUE Not enough input arguments gpss >> help QUEUE QUEUE QUEUE from GPSS TB QUEUE(STR) denes the entry in a waiting queue with name STR. See also DEPART. gpss >> QUEUE('ServerQ'); gpss >> %... further model statements gpss >> Outputs('sa = SA('Multiserver')'); gpss >> END; % Model generation o >> % Simple simulation run >> sa = schedule(1000,5); % tc start= 1000, servcap= 5 >> [Q,F,S,...] = report; >>...; Figure 5: Example of an Interactive Model Generation and Execution 5 Conclusions, Further Works The paper turned out that discrete event simulation methods and non-procedural model descriptions can be realized in interactive SCEs. General approaches are discussed and their principial realization is pointed out by the SCE MATLAB and the simulation language GPSS. Further works are the extension to hybrid systems, i.e. systems with combined discrete event and continuous behaviour [3]. Another thread of investigations focuses on distributed and parallel simulation of discrete event systems in SCEs based on the presented MATLAB-GPSS prototype and the DP- Toolbox (distributed and parallel processing based on multiple MATLAB instances [9], [10]). References [1] Octave Homepage. University of Wisconsin, [2] Scilab Homepage. Inria France, [3] W. Drewelow. Investigations to Simulation of Hybrid Systems with MATLAB-GPSS. Internal report, University of Rostock, (in publishing). [4] D. Etter. Engineering Problem Solving with MATLAB. Prentice Hall, Englewood Clis, New Jersey 07632, [5] Gruenwald, Kossow, Pawletta, and Tiedt. Cross discipline cooperation in engineering using numeric and computer algebra systems. In Proc. of Anniversary Seminar on Education in Engineering. Wismar University, Germany, UICEE, May [6] M. Kirchho. Development of a Mini-GPSS Toolbox. Master thesis, University of Rostock, February (in German). [7] MathWorks. MATLAB Users Guide { Vers. 5. The MathWorks Inc., Natick, MA, USA, [8] MathWorks. STATEFLOW-TB Data Sheet. The MathWorks Inc., Natick, MA, USA, [9] S. Pawletta. Extension of a Scientic and Technical Computing System to a Prototyping Environment for Parallel Applications. Phd thesis, University of Rostock, June (in German). [10] S. Pawletta, T. Pawletta, and W. Drewelow. Distributed and parallel simulation in an interactive environment. In F. Breitenecker and I. Husinsky, editors, Proc. of the 1995 EUROSIM Conference, Vienna, Austria, pages 345{350. Elsevier Science Publisher B.V., September [11] T. Pawletta. Investigations to DEVS-based Simulation of Variable Structure Systems with MATLAB. Internal report, Wismar University, (in publishing). [12] T. J. Schriber. An Introduction to Simulation using GPSS/H. John Wiley and Sons, About the Authors The authors are working in a joint modelling and simulation research group. Some more information about the authors can be found in the WWW: wd/rg mosi/

A MATLAB Toolbox for Distributed and Parallel Processing

A MATLAB Toolbox for Distributed and Parallel Processing S. Pawletta a, W. Drewelow a, P. Duenow a, T. Pawletta b and M. Suesse a a Institute of Automatic Control, Department of Electrical Engineering,