Prosim PDF

PROSIM BV
simulation - optimization - software - consultancy
PROSIM MODELLING LANGUAGE TUTORIAL
PROSIM BV
All rights reserved. Reproduction of any part of this manual in any form whatsoever without the express written permission of Prosim bv. is forbidden. The contents of this manual are subject to change without notice. All efforts have been made to ensure the accuracy of this manual. However, should any errors be detected, Prosim bv would greatly appreciate being informed of them. Notwithstanding the above, Prosim bv can assume no responsibility for any errors in this manual or their consequences. Copyright 1992 - 1999 Sierenberg & de Gans bv, Waddinxveen, The Netherlands. Copyright 1999 - 2005 Prosim bv, Zoetermeer, The Netherlands. Third edition [E3.01] (January 2005) This edition applies to PROSIM Release 5.05
PROSIM BV
Preface
is a software environment for combined discrete/continuous modelling and simulation. This manual concerns the PROSIM MODELLING LANGUAGE, assisting starting users to learn all facilities and features of the language. Modelling and simulation are involved with aspects concerning data handling, random processes, statistics, process control, differential equations and many others. However, each aspect learned, can directly be practised, enlarging the possibilities of the user in solving real world problems. Furthermore modelling and simulation makes fun! It is creative and makes things work.
PROSIM
The training examples used in this manual are supplied with the installation media, inviting the user to practise hands on exercises during the learning process. Those exercises are also meant to make the user familiar with various parts of the software. The six chapters of this tutorial fulfil special tasks in the learning process. Chapter 1 discusses the basic elements of model building needed to understand the PROSIM language. The world view demonstrated in this chapter is also known as the top down approach or even as system theory; it has become a widely accepted modelling methodology. Chapter 2 is a first stage in learning PROSIM. It can be regarded as the understanding phase in the learning process, where the use of the main features of the language is demonstrated. A very, perhaps most, important part of model building concerns the definition of the data structures to be used in a model. The reference concept and the use of sets are particularly important when defining such structures. Chapter 3 is a second stage to learn more precise the various possibilities of the statements. Each paragraph deals with a special group of PROSIM features.
PROSIM
Chapter 4 discusses the features of combined discrete/continuous modelling. It concerns the interaction of processes involving continuous and discrete values. With examples the various aspects of continuous state events are demonstrated. Chapter 5 discusses the use of windows for graphics, animation and the creation of user interfaces. Chapter 6 is devoted to the possibilities of communication with external functions contained in Dynamic Link Libraries. It should be noted here that both the PROSIM language and the PROSIM implementation are evolutionary in nature. So, future modifications and extensions cannot be included in this documentation. Therefore the release of any such enhancements will be accompanied by update material for the documentation. The inside title page will always state to which version of the PROSIM system the documentation applies.
PROSIM
tutorial
[E3.01]
preface -i-
PROSIM BV
Contents
Preface ............................................................................................................ i Contents ......................................................................................................... ii 1.
1.1. 1.2. 1.3. 1.4. 1.5. 1.6.
On the subject of modeling....................................................................... 1

The need for models....................................................................................................1 Components and attributes ..........................................................................................1 Activity and process descriptions.................................................................................3 Relations.....................................................................................................................3 Structure of a PROSIM model........................................................................................4 File management.........................................................................................................4
2.
2.1. 2.2. 2.3. 2.4. 2.5. 2.6. 2.7. 2.8.
Basic concepts of the language................................................................. 7

Generating components...............................................................................................7 The N_MACHINE model..............................................................................................11 Introduction of THIS ..................................................................................................13 Selection mechanism.................................................................................................14 Finishing touch .........................................................................................................16 Going complex..........................................................................................................17 More about sets .........................................................................................................21 Continuous state events.............................................................................................25
3.
Facilities of the language ........................................................................ 29
3.1. Introduction ..............................................................................................................29 3.2. Process control facilities............................................................................................29 3.2.1. States of a component.............................................................................................29 3.2.1.1. CURRENT component ...........................................................................................29 3.2.1.2. SUSPENDED ..........................................................................................................29 3.2.1.3. INTEGRATING .......................................................................................................29 3.2.1.4. PASSIVE ...............................................................................................................29 3.2.1.5. DATA component .................................................................................................30 3.2.1.6. ACTIVE ................................................................................................................30 3.2.2. Process control statements......................................................................................30 3.2.2.1. ACTIVATE, REACTIVATE ........................................................................................30 3.2.2.2. CANCEL ...............................................................................................................30 3.2.2.3. TERMINATE ..........................................................................................................30 3.2.3. Scheduling of activities ..........................................................................................32 3.2.4. System attributes of components and sets ...............................................................33 3.2.4.1. ARRIVALTIME .......................................................................................................33 3.2.4.2. NAME...................................................................................................................33 3.2.4.3. QUEUETIME ..........................................................................................................33 3.2.4.4. EVENTTIME ..........................................................................................................33 3.2.4.5. ACTIVE ................................................................................................................33 3.2.4.6. FIRST, LAST ..........................................................................................................33 3.2.4.7. SUCC, PRED ..........................................................................................................33 3.2.4.8. LENGTH ...............................................................................................................33 3.2.4.9. EMPTY .................................................................................................................33 3.2.4.10. MEAN .................................................................................................................33 3.2.4.11. BELONGS ............................................................................................................33 3.2.4.12. SORTINGPAR .......................................................................................................33 3.3. Programming Facilities.............................................................................................34 3.3.1. Introduction ...........................................................................................................34 3.3.1.1. TIME UNIT ............................................................................................................34 3.3.1.2. TRUE, FALSE.........................................................................................................34 3.3.1.3. =, IS, , IS NOT .....................................................................................................34 3.3.2. Characters and character strings.............................................................................34 3.3.3. WRITE and READ .....................................................................................................36 3.3.3.1. WRITE ..................................................................................................................36
PROSIM
tutorial
[E3.01]
contents - ii -
PROSIM BV
3.3.3.2. READ ...................................................................................................................38 3.3.4. Operators and built in Functions ............................................................................39 3.3.4.1. Operators ............................................................................................................39 3.3.4.2. Built in functions ................................................................................................39 3.3.5. Selection clauses ....................................................................................................40 3.3.5.1. FIRST/LAST clause ................................................................................................40 3.3.5.2. EACH clause.........................................................................................................40 3.4. Functions and Macros..............................................................................................41 3.4.1. Introduction ...........................................................................................................41 3.4.2. Functions ...............................................................................................................42 3.4.2.1. Introduction ........................................................................................................42 3.4.2.2. by value parameters.............................................................................................42 3.4.2.3. by name parameters.............................................................................................43 3.4.2.4. locals...................................................................................................................43 3.4.2.5. external functions................................................................................................43 3.4.3. Macros..................................................................................................................43 3.4.3.1. Introduction ........................................................................................................43 3.4.3.2. attributes of type macro .......................................................................................44 3.5. Pointstreams .............................................................................................................48 3.5.1. Introduction ...........................................................................................................48 3.5.2. User defined pointstreams ......................................................................................49 3.5.3. History of SET .........................................................................................................50 3.5.4. History of Continuous Attribute..............................................................................51 3.5.5. The Drunken Drivers Problem ...............................................................................51 3.6. Random number generation ......................................................................................52 3.6.1. Introduction ...........................................................................................................52 3.6.2. Sampling from discrete distributions ......................................................................53 3.6.3. Sampling from continuous distributions .................................................................54 3.6.3.1. The gamma distribution ......................................................................................54 3.6.3.2. The beta distribution ...........................................................................................55 3.6.3.3. Distribution from observations ............................................................................56 3.6.4. Predefined density functions...................................................................................58 3.6.4.1. UNIFORM..............................................................................................................58 3.6.4.2. EXPONENTIAL.......................................................................................................58 3.6.4.3. NORMAL ..............................................................................................................58 3.6.4.4. UNKNOWN............................................................................................................58
4.
4.1. 4.2. 4.3. 4.4. 4.5. 4.6. 4.7.
Combined discrete/continuous modeling................................................. 60

Introduction ..............................................................................................................60 Continuous attribute handling ...................................................................................60 VALUE of history........................................................................................................61 Accuracy of continuous state events ..........................................................................62 The method of finite elements ...................................................................................64 Repeated use of SPECIFY ............................................................................................66 Tracing components..................................................................................................69
5.
Window control..................................................................................... 73
5.1. Introduction ..............................................................................................................73 5.2. The output window ...................................................................................................73 5.3. Using chart windows.................................................................................................74 5.4. User windows............................................................................................................75 5.5. Using WOBs...............................................................................................................75 5.5.1. Introduction ...........................................................................................................75 5.5.2. Conversational aspects ...........................................................................................76 5.5.2.1. PROMPT ...............................................................................................................76 5.5.2.2. BUTTON ...............................................................................................................76 5.5.2.3. STRING ................................................................................................................77 5.5.2.4. COMBO ................................................................................................................77 5.5.3. Graphics ................................................................................................................79 5.5.3.1. GRAPH .................................................................................................................79
PROSIM
tutorial
[E3.01]
contents - iii -
PROSIM BV
5.5.4. Animation..............................................................................................................80 5.5.4.1. BITMAP ................................................................................................................80 5.5.4.2. POLYGON .............................................................................................................80 5.5.4.3. ELLIPSE ................................................................................................................80 5.5.4.4. RECTANGLE..........................................................................................................80
6. 7.
Calendar Data ........................................................................................ 84 Dynamic Link Library Interface.............................................................. 87
Appendix A .................................................................................................. 88
Compiler Messages .............................................................................................................88 Runtime Messages...............................................................................................................90
Index ............................................................................................................ 93
PROSIM
tutorial
[E3.01]
contents - iv -
PROSIM BV
1.
1.1.
On the subject of modeling

The need for models
Simulation is used to study a coherent part of the real world, called the system by means of experimentation with a model of that system. By means of simulation more understanding and knowledge will be obtained needed to control a system, improving the benefits of it. Obviously, the system is too complex to be sufficiently understood without models. An interesting question can be What makes a system complex? An exact answer is not available of course, but we know for sure that complexity is strongly related to parallelism. Human beings are not able to follow the behaviour of a system when more than four components are performing different activities simultaneously. In this sense, most systems are complex and therefore we need models as an aid for understanding the behaviour of systems, which is the main key for system control. In fact science is based on models. Using models, we are able to calculate the consequences of changes. Without models we can do no more than observing a system, gathering information, most of it without use.
1.2.
Components and attributes
So, let us start modelling and use the models to predict the consequences of changes, without directly affecting the real world. We will consider the system to be modelled as a set of components that are interrelated. The following examples will give some idea of what is meant by components: SYSTEM canal lock COMPONENT boat, lock keeper, lay-by, lock-chamber. machines, operators, stores, products. customers, clerks, letters, counters, queues. cars, lorries, traffic lights, cyclists, detectors. speakers, transistors. teachers, pupils, classrooms.
factory
post office
traffic junction
radio school
The general idea is to describe those components one at the time. So, if we model the canal-lock, we describe the behaviour of a ship passing the lock apart from the description of the lock-keepers activities and we leave the problems concerning parallelism to PROSIM.
PROSIM
tutorial
[E3.01]
chapter 1 -1-
PROSIM BV
These examples show that a component is just a part of a system that needs further specification. A component will never be a variable or a parameter, or indeed anything that will acquire a value. The decisions, concerning the parts of the system to be considered as components, may look easier than they really are. Two important features are involved: Aggregation In the case we decide that a car is a component of the system traffic junction and not the driver inside it nor the steering wheel, it means that the purpose of the investigation allows a description like the car turns to the left, instead of the driver turns the steering wheel anti-clockwise for some time and turns it back again at the moment the orientation of the car equals 90 degrees. The components in the model that are supposed to perform activities specify the so-called aggregation level of the model. That level depends on the kind of questions to be solved. Generally, we need more models of the same system at several levels of aggregation, to solve all questions concerning the system. Surroundings If we want to model a harbour, for instance, it will soon turn out that the ships and trucks involved are coming from other places in the world, that the goods to be transhipped are related to factories and trading-companies and so on. In other words, any system is, in some way, related to the whole world. So, we have to decide which components will be part of the model and which ones will be left out. Those decisions have to do with dropping relations, which again depends on the purpose of the investigation. Components that influence components belonging to the model but not the other way round, can (not must) be considered to belong to the surroundings of the system. But only if that incoming' relations can be evaluated in some way. The total of those evaluations forms the input of the model. In other words, a component can be considered to be a part of the surroundings of the system if its relations towards the system can be described as input and all other relations can be neglected. The next step in modelling concerns a further description of components in terms of values. We must be able to express that the production speed of a machine equals 6 ton/hour at a certain moment, which may be different from the production speed of another machine. So, the item production speed must be attached to each machine in the factory as a so called ATTRIBUTE. Depending on the purpose of the investigation, the attributes of some components of a factory model could be: COMPONENT ATTRIBUTES machine capacity, production speed, disturbance rate. operator timetable, job list, idle time.
Components with the same attributes belong to the same CLASS OF COMPONENTS. For instance, the class of components BOAT in the model of a canal lock system. Two components of the same class differ from each other because their corresponding attributes have different values (i.e. we recognize a friend because he has red hair, brown eyes, or a deep voice, etc.). Some attributes may have a constant value, e.g. birthday, arrival time, etc.; many attributes, however, will be time dependent, e.g. age, bank account, etc. The value of a time dependent attribute may change discretely, (which means that its value changes only when certain events occur) or it may change continuously during the simulation time. Each attribute will have a type and a dimension. The capacity of a machine can be of dimension zero and type REAL, expressing that its value will be one real number. The timetable of an operator could be a two dimensional array of type INTEGER.
PROSIM
tutorial
[E3.01]
chapter 1 -2-
PROSIM BV
We will call a component that belongs to a class a SINGLE COMPONENTs not belonging to a class.
CLASS COMPONENT
to distinguish it from
Single components are also permanent components; they are always present during the time when the system is being simulated. Class components may be temporary, e.g. the customers at a post office. They remain in the system for part of the simulation time. For this reason the number of components in a class may change during the simulation. A model consists of two major parts. The first part, called the definition section, shows the composition of the model; which components the model is based on, what names are used for attributes and how attributes are specified, etc. The second part of the model, called the dynamic section, describes the dynamic behaviour of the components, as will be explained below. In other words: the definition section of a model shows what the model looks like and the dynamic section of a model shows how the model will behave during the simulation time.
1.3.
Activity and process descriptions
The set of values of the time dependent attributes of the same component determines the state of the component. A change of any value will alter the state of that component. All successive changes in the state of a component show the process of that component. Every change in the state of a component is caused either by an activity of the component itself or by the activity of another component, due to the interactions between components. A component which does not perform any activity is a dead component. Such components are just carriers of information and are called data components, e.g. the parcels and letters in a post office. A component which is not a data component will be live during the simulation time. If we want to describe the dynamic behaviour of a system we first have to decide which components are data components and which are the live ones. We can describe the dynamic behaviour of a system by describing the activities of the live components. The set of activity descriptions of a component is called the process description of that component. The dynamic section of a model will contain a process description for every live single component. For instance, process descriptions for the lock keeper as well as one for the generator of boats in the model of a canal lock. The processes of the live components which belong to the same class can in most cases be described by one process description, because components of the same class normally will behave in a similar way; e.g. the process description for a boat passing through the canal lock. Thus, the dynamic section will contain a process description for each class of live components as well.
1.4.
Relations
Several times in the text above, we mentioned the fact that components are related to each other, leaving the question open how relations will be expressed in a model. If a component influences another component it always means that such a component performs an activity with the result that the state of the other component changes. Because the state of a component is defined as the set of values of its attributes, each influence has always to do with a change of the value of at least one attribute of that influenced component. Such a change can either be modelled directly by means of assignment statements or by means of facilities provided by the PROSIM language. If in reality an operator starts a machine, this will be modelled by changing the value of one or more attributes of that machine. For instance by assigning a value greater than zero to the attribute PRODUCTION_SPEED of that machine. It must be prevented that as a result of such an assignment, the PRODUCTION_SPEED of all machines in the factory would be changed. So, it must be possible for the operator to point out a special machine. For that purpose, the operator needs an attribute of the type REFERENCE, for instance denoted by the identification NEXT_ONE. The value of such an attribute will be a pointer to another component obtained by an assignment as for instance:
PROSIM
tutorial
[E3.01]
chapter 1 -3-
PROSIM BV
NEXT_ONE
FIRST MACHINE IN IDLE_MACHINES
Now, an assignment like:

PRODUCTION_SPEED OF NEXT_ONE 10
makes sure that only PRODUCTION_SPEED of the machine pointed out by the value of NEXT_ONE is changed. So, to express relations in a model, we need the concept of attributes of type REFERENCE. That concept is fundamental because it opens the way to handle parallelism.
1.5.
Structure of a PROSIM model
As explained above, each system is considered as a set of components which are interrelated. Modelling concerns two major features: DEFINITION FEATURE specifying the structure of the model in terms of components attributes and relations; simply said: the description of how the model looks like DYNAMIC FEATURE specifying the behaviour of the components; simply said: the description of how the model works. The PROSIM modelling language can handle those modelling features very precisely. For each PROSIM model there is a special section to handle the definitions. This section is directly available for inspection and updating. The dynamic section of a model, consists of process descriptions. These descriptions can be stored into as many modules as the PROSIM user requires. Each module can be handled separately. Several process descriptions can be combined into a single module, but a single process description can also be spread over more than one module. It is very important for the user to realize that every statement in a process description is considered as an activity of a component in the system to be simulated. Always ask yourself: who is doing what? Never try to decide what the computer has to do to simulate the system. Leave that problem to PROSIM. During run-time, of course, all the statements are carried out in some way by the computer, but this has nothing to do with modelling. Apart from the process description of the components of the system to be modelled, there remain a number of simulation technical matters, such as: initialisation run scheduling run termination. These technical matters should be carried out by the PROSIM system component MAIN. MAIN denotes a single component that has the same capabilities as all other single components. The differences are: MAIN is automatically defined as a single component MAIN will be activated automatically from the first statement in the module MAINMOD at simulation time zero. So the process description of MAIN will start from the first (possibly only) process description in the module called MAINMOD. As a consequence, each PROSIM model consists of at least two parts: the definition section module MAINMOD
1.6.
File management
After PROSIM is started up, a window appears offering the opening of an existing model or the creation of a new one. In case of creation the user has to specify: the name of the model; let us assume that name is NEW_ONE, a folder in which the resulting model file will be placed; the browser can be helpful making the choice.
PROSIM
tutorial
[E3.01]
chapter 1 -4-
PROSIM BV
After creation of the model that folder contains: the file: NEW_ONE.PMF (Prosim Model File) containing characteristics of the model and the definition section, a subfolder with the name: NEW_ONE. That new folder is used as default storage location for all files that are related with the model. So, if you create a new module and you dont specify a folder to store it, that folder is used. After opening a model a window appears like the one below.
There are two major parts. The left pane consists of tabs holding information about the several parts a model consists of. As shown, the Def tab holds the definition section of the model, showing MAIN as the only component of the model so far. The right part is meant for updating the source texts of modules, macros and functions. The menu Model gives access to the appear as shown below.
OPTIONS.
Using that item causes the option window to
The Folders tab shows that initially the folders meant to contain data files related to the model, are equal to NEW_ONE as discussed above. For the moment it is only important to understand that any file that is only addressed by its name is supposed to be found or to be created in one of the folders specified here. For instance: all module files that, at creation, are not fully qualified are stored in the model folder. On the other hand, a file containing a module of the model needs not to belong to the model folder. By using fully qualified names each file can be used for any model. This way of file management offers facilities to create software environments containing several models sharing modules and operating on common data collections.
PROSIM
tutorial
[E3.01]
chapter 1 -5-
PROSIM BV
The Miscellaneous tab contains 5 checkboxes to indicate whether the designated trees in the left-hand pane should be sorted.
PROSIM
tutorial
[E3.01]
chapter 1 -6-
PROSIM BV
2. Basic concepts of the language

In this chapter we will guide you step by step in understanding and learning the basic concepts of the language. The examples used in this tutorial process are supplied on the installation media. The hands on exercises are intended not only for learning the language but also to become acquainted with the facilities of the PROSIM system. During this process the windows operating system must be used for file transports. Any editor can be used to create and update data files. The PROSIM editor is meant to update the texts of modules, macros and functions. This editor has some special options to handle items used in the syntax of statements. These are: assignment symbol, obtained by Ctrl + Backspace. continuation symbol indicating the current line extends to the next line; Ctrl + Enter. involution symbol (A B means A to the power of B); Ctrl + |. not equal symbol; Ctrl + =. greater than or equal to symbol; Ctrl + >. less than or equal to symbol; Ctrl + <.
2.1.
Generating components
1 Inspect the data file called ORDERS.TXT. You will find out that this file looks like this:
HANDS ON
With the exception of comments which are placed between successive at signs (@), each record represents data about the production of an order on a machine. These data denote respectively: the moment the order arrives, a number specifying the type of the order, the time a machine normally needs to process the order. That data could be information about the manufacturing of orders in the past. In our first model we will be able to calculate how many machines are needed to process orders, as specified in the this file, without excessive waiting times. That model is called N_MACH. However, for the moment it is better you leave it alone and start a new model, say MACHINE, as described in paragraph 1.6. There will be orders in our model. In terms of modelling, that will be components with a similar structure. Therefore we create a class of components, which we call ORDER. Just double click CLASS in the Def tab and a window appears for this creation. Be aware that a class is, as a matter of speaking, a device to produce class components. That production, or instantiation, is caused by the function NEW. Every time the function NEW ORDER is invoked, the birth of a class component of the class ORDER takes place. That is the explanation in terms of modelling. In computer terms a dynamic memory allocation is caused by NEW, creating enough room to store the values of variables specified as attributes of ORDER in the definition section.
PROSIM
tutorial
[E3.01]
chapter 2 -7-
PROSIM BV
Each component of the class ORDER needs at least two attributes, say:
INTEGER REAL TYPE EXEC_TIME to contain the relevant information from the data list.
and REAL specify the type of these attributes to inform the computer how attribute values must be handled. For adding this attributes to the class ORDER, double click on ORDER in the Def tab and fill up the windows. If you want to delete an item from the definitions, click on its name and use the delete key.
INTEGER
So far we decided that there must be orders in our model and we constructed a class for that purpose. Because we learned, in the previous chapter, always to ask: who is doing what, our next question consequently will be: who will create those orders. One component will be enough to do this job; so we create a single component called GENERATOR. (Double click on COMPONENT and add the generator.) This component has a task to perform; therefore it needs a process description stipulating the activities to be processed in a specified order. Suppose the generator starts its simulated live at time 0 reading the first number from the file ORDER.TXT. That turns out to be 16.49 denoting the time the first order will arrive. So, before creating that order, the generator has to wait 16.49 minutes. Then it creates a new order and assigns the values of its attributes (TYPE and EXEC_TIME) according to the next two numbers in the file. The next number in the list denotes the arrival time of the next order. So, the same activities have to be repeated until the value 1 is reached. In PROSIM these activities can be described as follows:
NEXT_ARRT READ FROM LIST WHILE NEXT_ARRT > 0 WAIT (NEXT_ARRT - NOW) MINUTES NEXT_ORDER
NEW ORDER
TYPE OF NEXT_ORDER NEXT_ARRT END TERMINATE
READ FROM LIST
EXEC_TIME OF NEXT_ORDER
READ FROM LIST
READ FROM LIST
Obviously the reading activity is performed with function READ. Waiting is described by WAIT. The creation of a component is done with NEW ORDER as discussed above. NOW delivers the simulation time at execution of the WAIT statement. TERMINATE kills the simulated live of the generator. Recognising these items, however, is not enough. We have to spend more effort, to understand how things work. First of all you must add this process description in module MAINMOD. Therefore, open the Mod tab to find out that our model owns a module called MAINMOD. That is not so amazing, because any model gets a component MAIN and a module MAINMOD at creation. To update this module you must double click on MAINMOD. That will cause a warning telling that no file exists keeping the source text of module MAINMOD. Because you want such a file to be created, you confirm that situation and the file called MAINMOD.PSC is created to be stored in the folder specified in the options as described in 1.6. Furthermore the right hand pane of the window turns from grey to white, indicating an empty file for editing. Now you can type the text. The assignment operator is obtained by simultaneously pressing of the CTRL and the BACKSPACE keys. The toolbar has buttons to save the file ( Member).
HANDS ON 2
) and to compile (
) the source (Check
Press the button CHECK MEMBER. A whole series of error messages will be produced. They all have to do with the fact that the items: LIST, NEXT_ARRT and NEXT_ORDER are unknown to the compiler.
PROSIM
tutorial
[E3.01]
chapter 2 -8-
PROSIM BV
NEXT_ARRT
is needed to store the result of the READ function during the time the generator has to wait before creating the next order. So, we must add NEXT_ARRT as an attribute of the generator of type REAL. The term LIST looks erroneous. The generator should not read from LIST but from ORDERS.TXT, being the correct filename. However, file handling should not be that simple. contains a concept called DATASTREAM. With that concept we can create formal files being images of actual data files outside the model. To each DATASTREAM actual data files can be attached (one at the time) directly or indirectly. This concept makes it possible to attach data files to a model without changing the source text of the model as demonstrated below.
PROSIM
For the moment, we just have to accept the following procedure. must be defined as an attribute of the generator of type REFERENCE TO DATASTREAM. Furthermore, the process description of the generator must be extended to read:
LIST LIST NEW DATASTREAM ATTACH "ORDERS.TXT" TO LIST OPEN LIST FOR INPUT NEXT_ARRT
READ FROM LIST
etc. Remark that the function NEW is used again. Here together with the keyword DATASTREAM, offering the possibility creating any number of formal files that can be used simultaneously for input and output purposes. The string ORDERS.TXT in the ATTACH statement must contain a fully qualified path, in case that file ORDERS.TXT is not present in de data folder specified in the OPTIONS (see 1.6). The reference NEXT_ORDER is used to refer to the component of class ORDER just created. NEXT_ORDER has to be defined as an attribute of the generator of type REFERENCE. As discussed in paragraph 1.4 NEXT_ORDER enables a relation between the generator and the order last created. The generator can handle that order because it is pointed out by NEXT_ORDER. This is the modelling aspect of the reference concept. In computer terms: NEXT_ORDER contains the starting address in memory from where the values of the attributes of the last created order can be found, so that values can be addressed. Next question: who will make the generator alive? That question is simple. MAIN will. The question: who starts MAIN is out of order. We already know from the previous chapter, that MAIN is started by PROSIM to follow the process starting on the fist line of module MAINMOD. With this in mind we can complete module MAINMOD to obtain our very first complete PROSIM model:
makes the generator alive, using the ACTIVATE statement. The label stipulate the so called activation point of the generator.
MAIN PROSIM
CREATE
is used to chapter 2 -9-
tutorial
[E3.01]
PROSIM BV
Because the compiler does not produce error messages any more, we are able to run the model.
HANDS ON 3
Run the model by pressing the button TRACE MODEL ( ).The TRACE WINDOW appears showing the source text in the upper left pane. The statement that is about to be executed is marked. Clicking the top left button cause the execution of the marked statement. Depending on the kind of statement, additional information is given in the spy. In this way you can inspect how MAIN starts, giving live to the generator and how the generator creates one order after another according to the information in file ORDERS.TXT. Following that process will be rather boring after some time, so we interrupt it to inspect the status of the model so far by clicking the status button in the toolbar. Inspecting the class of orders you find out that all the orders disappeared! Only one remains: the last one. More specific, the one NEXT_ORDER of the generator is pointing to. In fact this is the only order which can be reached. NEXT_ORDER is only reference to order in the model, so only one order can be addressed. All the other orders are unreachable and therefore removed from memory by PROSIM. If we want to keep control over all orders, it is necessary to extend the model with the possibility to reach each one. Should we define a reference attribute for each order? That could be done using array facilities. Fortunately PROSIM offers a more convenient way with the SET concept. How does it work? Just like all the other concepts do. Again we define a reference attribute of the generator. This time of the type: SET:
REFERENCE TO SET: ORDERLIST REFERENCE TO
We modify our model to look like:
The set concept offers membership facilities. The JOIN statement makes the order that is pointed out by NEXT_ORDER a member of the set pointed out by ORDERLIST.
NOTE:
A sentence like the previous one describes exactly what is going on. Exactness is needed to make the reader realise that there is a difference between an order itself and the reference NEXT_ORDER addressing that order and similarly a difference between a set itself and the reference ORDERLIST addressing that set. However, it is not realistic to maintain this exactness to the end of the manual. Sooner or later we simply write: NEXT_ORDER is joined to ORDERLIST, trusting the reader to understand this to be shorthand. If not so, the reader will only suppose that he knows what is going on, and will stumble from tutorial [E3.01] chapter 2 - 10 -
PROSIM
PROSIM BV
one error into another trying to create a model. That is the danger of user friendly readable statements. If we again inspect the status of the model after a rerun, it turns out that all orders are still there, because they are all members of the set ORDERLIST refers to. Sets can be scanned, so the members can be reached. We will soon find out that PROSIM offers several convenient facilities to operate on sets.
2.2.
The N_MACHINE model
Our model is more fun when we add some machines to process the orders. Suppose a machine operates as follows: It waits while the order list is empty. It removes the first order from the order list to process it. If that order's type differs from the type of order last processed, the machine needs 10 minutes to switch. The machine processes the order, which will take EXEC_TIME minutes. Each machine needs two attributes : REFERENCE: JOB INTEGER: PREV_TYPE is used to indicate the order which the machine is working on, PREV_TYPE to contain the type of the order last processed.
JOB
The process description of a machine in PROSIM terms is:

START: WAIT WHILE ORDERLIST IS EMPTY JOB FIRST OF ORDERLIST REMOVE JOB FROM ORDERLIST WORK 10 MINUTES TF TYPE OF JOB PREV_TYPE TYPE OF JOB WORK EXEC_TIME OF JOB MINUTES REPEAT FROM START
PREV_TYPE
Readability was the designers' intention, because the readability of the process descriptions is most important in validating the model. However, to create models this level of understanding is not sufficient! We must discuss these statements one by one.
WAIT WHILE ORDERLIST IS EMPTY
is a state indicator; like system attributes they are automatically attached to components and sets to determine their state.
EMPTY
This is the second WAIT statement in our model. The first was in the process of the generator where the generator must wait some minutes before generating the next order. Here, a machine has to wait for some time. The similarity is that in both cases a component is postponed in its process for some time and will carry on again on his own behalf. During that time that component is in the suspended state. The difference is that in case of the generator the duration of the suspended state is known at the start of it. While waiting the generator is suspended, waiting for a time event. That state will end at the EVENTTIME (system attribute) of the generator. The duration of the suspended state of a machine, waiting WHILE ORDERLIST IS EMPTY, is not known beforehand. While waiting the machine is suspended, waiting for a state event. In this case the EVENTTIME of that machine is meaningless. It is important to know that all the components that are suspended and waiting for a state event, will check their state condition in the order they became suspended. With this in mind, we will determine what will happen if two machines are waiting WHILE ORDERLIST IS EMPTY and the generator joins an order to it. Will both machines start fighting for the order? Of course not! One of the two became suspended first. This one will be the first to check the condition after the order was joined to ORDERLIST. It immediately resumes its activities with the result that JOB, being the first and only ORDER in ORDERLIST, is removed from ORDERLIST at the same
PROSIM
tutorial
[E3.01]
chapter 2 - 11 -
PROSIM BV
time. So, when the other machine checks the state of empty.
ORDERLIST,
it will find the set to be
So, if the REMOVE statement is moved after the WORK statement then both machines will try to process the same order, which would cause a run time error. If you now fully understand the first statement, we can go the next one:
JOB FIRST
FIRST OF ORDERLIST
is a system attribute automatically attached to sets. Its value indicates the first member. When the set is empty the value will be NONE.
REMOVE JOB FROM ORDERLIST
seems to be superfluous; however, the syntax of the REMOVE statement requires it, because a component can be a member of several sets at the same time.
FROM ORDERLIST WORK 10 MINUTES IF TYPE OF JOB WAIT, WORK
PREV_TYPE
and HOLD are synonyms to make the statements more expressive.
The last two statements dont require further explanation. As a part of its initialisation task, MAIN has to create a number of machines and make that machines alive from the label (activation point) START.
N
READ FROM CASE
FOR I 1 TO N ACTIVATE NEW MACHINE FROM START END
The integers N and I must be defined as attributes of MAIN. refers to the case datastream of the model. This user data file, being the first (or only) file belonging to the cases of the model, is automatically attached to the model. The user can indicate any user data file as CASE FILE of a model. These files fulfil a relation between the model and the outside world.
CASE HANDS ON 4
Create a text file containing just the number 4 and save that file as CASE1.TXT in the model directory. Select the Case tab and double click the word CASE to add a case to attach the file just created. Extend module MAINMOD to read the number of machines and add the process description for the machines:
HANDS ON 5
Run the model and use the trace facilities to inspect the correctness of the model. It is very instructive to watch the order in which the statements are invoked. Here we see parallelism in progress. Realising what is going on here will be helpful to understand the next paragraph.
PROSIM
tutorial
[E3.01]
chapter 2 - 12 -
PROSIM BV
The goal of the model was to find out how many machines are needed to process the orders with reasonable waiting times. Therefore, it would be nice to make inspection of these waiting times possible. Some component must do this for us. For instance the generator could do that after the creation of all orders. Therefore we extend the process of the generator to read:
The set ORDERLIST refers to, is created as a set WITH HISTORY, causing the history of the use of that set to be kept. The history of a set involves two time series: the number of members in the set (also called the LENGTH of the set) during simulation time, the waiting times of components that left the set. is another concept of PROSIM, offering the facility to produce windows that can be used for several purposes as described in chapter 5.
WINDOW
The SHOW statement makes a window visible on screen. AT and SIZE specify the position and size of the window. The position will be 10 pixels from the left of the screen and 10 pixels from the top. The width of the window is 600 pixels and the height 400. When not using the SHOW statement, the window can still be shown using the graphics button in the toolbar of the run control window. In that case the appearance will be according default attribute settings.
2.3.
Introduction of THIS
We noticed several times before that readability can be tricky. So dont feel ashamed if you did not miss an essential explanation in the discussion of the process description of the machines. Every time an attribute of a component of the class ORDER (TYPE or EXEC_TIME) is used in the model we must use a qualifier (OF followed by a REFERENCE) to point out the class component that is involved. Therefore, if JOB and NEXT_ORDER point to different components, TYPE OF NEXT_ORDER will differ from TYPE OF JOB Nevertheless, in the process description of a machine we use the statement
JOB
FIRST OF ORDERLIST
without specifying which JOB of the n machines is involved! The other attribute of a machine PREV_TYPE is also used unqualified. It is obvious that in these cases, JOB and PREV_TYPE are meant to be qualified by the machine that is current (performing statements). Because we already proofed that the model works correctly, there must be some mechanism that automatically performs the correct qualifying. That most important mechanism is called THIS.
PROSIM
tutorial
[E3.01]
chapter 2 - 13 -
PROSIM BV
To each class, PROSIM will add one special variable called THIS classname. It is of the type REFERENCE and (if not NONE) points out a component of that class for which user defined attributes need not to be qualified. Even stronger, the compiler generates automatically OF qualified and consequently: OF THIS MACHINE after Therefore the statement
JOB THIS ORDER JOB
where
JOB
after TYPE, if TYPE is not is used unqualified.
FIRST OF ORDERLIST
actually means:
JOB OF THIS MACHINE
FIRST OF ORDERLIST
which, however, still not solves the question about correct qualifying. The PROSIM run control mechanism will do. This mechanism takes care that components become current at the correct moment. Before that mechanism makes a class component current, it causes THIS classname to point out that component. Therefore, the user defined attributes of the current component need not to be qualified.
NOTES:
This proposition only stands for user defined attributes because these names are uniquely defined. System attributes (e.g. ARRIVALTIME) are not uniquely attached to a class. As a consequence, system attributes can only be used qualified! It is allowed to assign a value to THIS classname in a process description. That can be most convenient when many attributes of the same component must be used instantly. However, be aware that the PROSIM run control mechanism will be able to change such a value at the moment the current component becomes suspended.
2.4.
Selection mechanism
The efficiency of the order processing could be improved by preventing unnecessary switching of the machines. Therefore we can change the process of a machine so that it only switches to another type if there is no order of the same type as PREV_TYPE in ORDERLIST. So, we replace the statement:
JOB
FIRST OF ORDERLIST
by
JOB JOB
FIRST ORDER IN ORDERLIST WITH TYPE FIRST OF ORDERLIST IF JOB IS NONE
PREV_TYPE
The item FIRST in FIRST OF ORDERLIST concerns a system attribute of the type REFERENCE. It merely indicates the first component in ORDERLIST and it does not matter whether this is an order or a machine or anything else; it is just the first. The selection clause: FIRST ORDER IN ORDERLIST starts a mechanism that returns a reference value indicating the first component in ORDERLIST that is an order. Where there are only orders in the set, the use of the more simple system attribute will produce the same result. This selection clause can be extended in several ways, as we will learn in section 3.3.5. Let us examine the extension WITH
WITH TYPE OF THIS ORDER TYPE
PREV_TYPE,
which actually means:
PREV_TYPE OF THIS MACHINE. ORDER
As explained above, the value of THIS MACHINE is correct (current component). THIS will have an appropriate value each time this test is evaluated. In other words the mechanism works as follows: step 1 Consider the next component in the set; go to step 5 if there is no such component step 2 Is that component an order? If not, repeat from step 1 step 3 Let THIS ORDER indicate that order step 4
PROSIM
tutorial
[E3.01]
chapter 2 - 14 -
PROSIM BV
Evaluate the test; if false, repeat from step 1 step 5 Let THIS ORDER indicate the order it referred to at the start of the statement step 6 Return the reference value that indicates the order found, or NONE if appropriate. Selection clauses are a very powerful tool for describing more complex features.
NOTE:
The term FIRST in the selection clause indicates the direction the set will be scanned. If FIRST is changed to LAST, the set will be scanned in reverse order.
PROSIM
tutorial
[E3.01]
chapter 2 - 15 -
PROSIM BV
HANDS ON 6
Add the statement:

FILE HISTORY OF ORDERLIST AS
"RUN1"
TERMINATE
to the process description of the generator before the model using 4 machines
HANDS ON 7
statement and run the
Change the process description of a machine as suggested above and replace the just added statement by:
FILE HISTORY OF ORDERLIST AS
"RUN1"
W_TIME_NEW NEW WINDOW ATTACH "RUN1" TO W_TIME_NEW SHOW W_TIME_NEW AT(20,20) SIZE(600,400)
Consequently, W_TIME_NEW must be defined as an attribute of the generator with type REFERENCE TO WINDOW. Run the model once more with 4 machines. Comparing the results in the two windows displayed may be interesting.
2.5.
Finishing touch
Now we have finished our first model, we can compare it with the model called N_MACH, supplied with the PROSIM software, to find out that there are differences. That does not imply that there is something wrong with our model. It is just a matter of professionalism. We will discuss the differences one by one: The process description of the machines is not a part of module MAINMOD, but kept separated in a module called MACHMOD. In this way we can use that process description in other models, without the need to copy the text. When creating a module, using the Mod tab, two items must be specified: the name of the module in the model, the file keeping the source text or to keep the source text in case of a new one. The only change in the model concerns the activation of the machines. That statement must read now:
ACTIVATE NEW MACHINE FROM START IN MACHMOD
specifying in which module the activation point can be found. Process descriptions will better fit for general use, if they are designed for a special purpose and nothing more. All supporting tasks as configuring the system, reading the case file, initialisations, simulation control and output belong to the task of MAIN. In that sense, our generator performs tasks that should be done by MAIN. So in model N_MACH, MAIN takes care for the creation of ORDERLIST and the datastream LIST. The attachment to the user data file ORDERS.TXT is performed indirectly with
ATTACH READ FROM CASE TO FILE
where the character string indicating the file is read from the case file. It permits the replacement of such a file without the need to change the model. Definitions of references in cases where the THIS concept can be used are normally avoided. Therefore, THIS ORDER is used in stead of NEXT_ORDER in the process description of the generator. Obeying the be aware notice' in paragraph 2.3 such a replacement should not be done to avoid the use of JOB in the process description of the machines! If you are not aware why that is wrong, please do that replacement and trace the model as long as needed to find out what is going wrong with the processing of the orders and why. The type of JOB is chosen to be REFERENCE TO ORDER instead of just REFERENCE. In this way the value of JOB is restricted to point out orders only. This is a matter of protection; if you try to address a machine with it, an error message will be produced. So, normally we only use the type REFERENCE in case we intend to indicate components of different classes in turn with the same attribute.
PROSIM
tutorial
[E3.01]
chapter 2 - 16 -
PROSIM BV
The WAIT statement following the activation of the machines contains no further information about the duration of the time MAIN has to wait. Therefore, MAIN will not be able to resume its process on its own behalf. So, MAIN will not be suspended during the waiting period but passive. Another component, here the generator, has to reactivate MAIN. Otherwise MAIN will remain passive forever.
2.6.
Going complex
To get acquainted with the concepts of PROSIM, we have to consider more complexity than can be found in the n_machine waiting line problem. However, the concepts we discussed creating the model for that problem, are far from simple. They handle parallelism and that is complex in nature! So, be sure that you understand what is going on, when 4 machines are following the same process description. If not, spend more time studying the previous paragraphs; finally that will save you time. Adding complexity is easy. As a start, just add the constraint: not every machine can handle each type of order. The case file will contain information about which machine can handle what kind of orders: @ @
INFORMATION ABOUT ORDERS IN FILE: @ ORDERS.TXT MACHINE NAME SUITABLE FOR TYPES @ MACH_1 1 3 5 -1 MACH_2 2 4 -1 MACH_3 1 2 -1 MACH_4 4 5 -1 END
The lists of suitabilitys are of different length. Therefore, the -1s are needed to indicate the end of that lists. Similarly end is used, supposing no machine is called end. As a consequence of the constraint, there should be an order list for each machine. If not, it may happen that mach_1 takes the last order with type 4 from the order list and mach_2 the last type 5 order. So, mach_4 becomes unnecessarily idle if there are still orders of type 1 and 2 waiting. With an order list for each machine, the generator can select a machine for each order on arrival, avoiding those nasty situations. So, we must replace the attribute ORDERLIST from MAIN to the class MACHINE. A rather simple selection rule for the generator can be: choose, at creation of an order, the machine, among the suitable machines, with the shortest order list. The way to extend the model must be found in the previous sentence. When asking: who is doing what, we must figure out that the extension only involves the generator. The machines have nothing to do with it. What information does the generator need to make his decision? He creates an order with a type and needs to know which machines can handle that type. So, the generator needs a set of suitable machines for each type and not some set of possible types for each machine! Why that exclamation? Most students first do and than think. They start directly providing the machines with information about the types each machine can handle. Figure out, how complex the extension of the generator process will be if that information is attached to the machines. We were heading for complexity, however, not for complexity that can easily be avoided! The generator needs one more attribute: an array of type REFERENCE TO SET. So we add the attribute SUITABLES[10] to the generator, assuming that there will be no need for more than 10 order types. As a part of its initialisation task MAIN will assign a set to each one and fill the set pointed out by SUITABLES[10] with machines that can handle type i. After the extension module MAINMOD looks like:
PROSIM
tutorial
[E3.01]
chapter 2 - 17 -
PROSIM BV
Some remarks: MACHINES must be a REFERENCE TO SET attribute of MAIN. MAIN needs this set at the end of the simulation to show results graphically. CHAR must be a CHARACTER attribute of MAIN (CHAR[10] will limit the number of characters to be kept in CHAR to 10). The CALLED option used with NEW replaces the default name of the component being created by the given name. Because we want graphics of the use of each order list, W_TIME must be an attribute of class MACHINE now. LENGTH is a system attribute of a set indicating the number of members of the set. Due to the THIS concept, the process description of the machines did not change at all (figure that out!). The statements in the FOR EACH loop will be repeated for each machine in MACHINES. THIS MACHINE will point out those machines in turn. Most attributes are used unqualified, so those attributes are automatically qualified with THIS classname. The reader is recommended to check that ORDERLIST (being an attribute of class MACHINE now) is correctly used unqualified in all occasions (for various reasons). The components in our models so far are only loosely interrelated. One activates another and that's all there is to it. So now we are going to change that. Therefore, suppose that each order concerns the production of an article made from synthetic material. That synthetic material is normally in a granular form. When it is to be used it is blown into a production tank and becomes fluid when the tank is heated. This production tank is connected to all the machines. During the production of an order the machine takes in fluid from the tank at a rate of 1 unit per minute. The output capacity is enough for all the machines to be able to work simultaneously.
PROSIM
tutorial
[E3.01]
chapter 2 - 18 -
PROSIM BV
Because of technological constraints the tank must be rather small. So, we need an orderer in our model to order trucks bringing the synthetic material from some central storage area to the tank in time to prevent production stoppages. However, we will construct our model in such a way that production stoppages can occur.
Figure 1 Figure 1 shows what the model looks like. It is called N_MACH_C in the exercise directory. The definition section is extended by addition of the components STORAGE and ORDERER and a class TRUCK. The ORDERER and the components of class TRUCK are living components. Therefore we must describe their behaviour. The process description of a truck will be troublesome, because a truck has more jobs to perform than bringing grains to our site. However, modelling the behaviour of a truck between ordering of a truckload and the moment it will arrive is outside the scope of our model. As usual in situations like this, we declare that process to be random. This means that we draw random numbers from a distribution function to obtain these driving times. offers the DISTRIBUTION concept and a function to draw numbers from distributions randomly. Similar to the other language concepts, a reference attribute must be defined. Here, a REFERENCE TO DISTRIBUTION attribute:
PROSIM REFERENCE TO DISTRIBUTION: DRIVE_TIME
as an attribute of MAIN. The statement:

DRIVE_TIME
NEW DISTRIBUTION
creates a distribution and DRIVE_TIME refers to it. That distribution is, default, the uniform distribution between 0 and 1. In our case we dont want that default. The driving times of the trucks are more likely to be normally distributed. If we add the mean and a standard deviation in the case file and define MN and DEV as attributes of MAIN, the distribution, DRIVE_TIME refers to, can be reshaped to be the normal distribution as follows:
MN
READ FROM CASE
DEV READ FROM CASE ATTACH NORMAL(MN, DEV) TO DRIVE_TIME
A random drawing from that distribution will be obtained with the function
SAMPLE FROM DRIVE_TIME
PROSIM
tutorial
[E3.01]
chapter 2 - 19 -
PROSIM BV
This is our first acquaintance with the concept of DISTRIBUTIONs. In section 3.6 more aspects will be discussed. According to the description above MAINMOD looks like:
The process descriptions of the orderer and the trucks are included in the module SUPPLY_MOD. The orderer checks whether to order a truck every hour. Attribute ORDERED_AMOUNT is used to store the total amount of ordered material that has not yet been delivered. Therefore, a truck must decrease that amount at delivery of its load. Apart from the concept of DISTRIBUTIONs there are no new concepts to be discussed in this module. The single component STORAGE has an attribute LEVEL of the type CONTINUOUS, specifying that its value can change continuously. Continuously means that its value not only changes due to actions of components at event-times but also between event-times according to the numerical integration of a differential equation that must be attached to it, specifying its continuous behaviour. That continuous behaviour must be attached to every continuous attribute with the SPECIFY statement. Before discussing that statement, we have to figure out what differential equation will describe the continuous level changes of the storage.
LEVEL'
denotes the first derivative of change. Generally:

LEVEL'
LEVEL,
in our case, the speed with which
LEVEL
will
input rate minus output rate
The input rate only deviates from 0 during the time that a truck is unloading, for which we introduce the attribute INTAKE. The output rate depends on the number of machines working, which is most easily expressed by LENGTH OF AT_WORK, where AT_WORK points to a set, containing the machines that are producing. The changes in the process of a machine involve the use of the set AT_WORK points to. Note that we use JOIN and REMOVE where one component joins another component to, or removes another component from a set. Where the component itself is affected, we use ENTER and LEAVE instead. Furthermore, a machine will not start the processing of an order when there is almost no material in the tank. The meaning of the SPECIFY statement, the STORAGE uses to specify the continuous behaviour of its LEVEL, will be clear now:
SPECIFY LEVEL PRECEPT(LEVEL'
INTAKE
LENGTH OF AT_WORK)
The behaviour of HISTORY OF LEVEL.

PROSIM
LEVEL
as a function of the simulation time is automatically kept as the
tutorial
[E3.01]
chapter 2 - 20 -
PROSIM BV
Just like the history of a set, the history of a continuous attribute can be attached to a window, providing graphics of that time series as shown at the bottom of the process description of MAIN. There are more facilities to discuss about SPECIFY statement. Chapter 4 describes all details. will only change continuously, according to this differential equation as long as the component STORAGE, it belongs to, is in the integrating state.
LEVEL
The STORAGE enters this state with the statement: INTEGRATE. Note that the concept of continuous attributes implies that components owning that kind of attributes must be living components, following a process description. In this way we can handle situation where components alternatively integrates or not integrates its continuous attributes. As for instance heating machines that turn on and off according to desired ranges of temperature. The following screen dumps of MACHMOD and SUPPLYMOD make the description complete:
2.7.
More about sets
In the previous examples sets are used to gather components in because: they are waiting to be handled (like the orders), they have some common property (machines that can handle a type). In terms of modelling, the set concept is convenient way to address something that is or can be multiple. Let, for instance, PERSON be a class. A component of that class may have a child being a member of class PERSON itself. So, child can be defined as an attribute of PERSON of the type REFERENCE. However, there will be persons with two children or even more. Of
PROSIM
tutorial
[E3.01]
chapter 2 - 21 -
PROSIM BV
course, an array of references can be used to address these children one by one. The use of the set concept instead is more convenient in all cases where we want to address the collection as a whole. Therefore we define CHILDREN as an attribute of person of type REFERENCE TO SET. That set will contain all persons (may be none) being children of that class component. The next example is meant to demonstrate modelling using sets and the benefits of addressing collections as a whole. The example is far from simple. The structure of the network of related components is complex. Choices must be made about: which components compose the model, where do we use sets, where do we use arrays, which references do we need to address attributes in a convenient way. So, the complexity in the first place concerns modelling. The PROSIM statements needed in the model are most elementary. Take your time for it. Study the example again when you have to model a system yourself. Consider two islands numbered 1 and 2. There are some towns and one harbour on each island. Each town produces crates to be transported to towns on the other island. There are also some transport firms; each of them has a depot in both harbours and a number of trucks. A ship will shuttle between the two harbours. A truck will make trips between the harbour and the towns on an island according to the following description: Starting in a given town it waits for a full load consisting of 24 crates. Then the truck drives to the export stack in the harbour and unloads its crates there. The empty truck drives to the import stack in the harbour and picks up a load to be transported by its firm. Then the truck brings that load to the firm's depot in the harbour where it sorts out the crates according to their various destinations. Finally, the truck picks up a load (as large as possible) for one town and takes it there. When it arrives at one of the harbours the ship will unload its cargo on the import stack. Then it will load the whole contents of the export stack. (If it would rather sink than leave something behind.) The model can be copied from the exercise directory. Its name is TWO_ISLANDS. This model needs the data file with the same name as case file. That file specifies the configuration of the transportation system:
The next screen dump shows how harbours:
MAIN
reads the data configuring the towns and the
PROSIM
tutorial
[E3.01]
chapter 2 - 22 -
PROSIM BV
Then MAIN creates the firms with their trucks:
The complexity and the length of the process descriptions largely depend on the choices made about the composition of data structures. If there are difficulties in describing the logic of a system, resulting in lots of IF statements, it usually means that those structures are badly composed. In which event it may be necessary to reconsider the contents of definition section. In our case an important modelling aspect is how to describe the contents of stacks and depots. Of course these stacks and depots contain crates, but a single crate is almost meaningless at that level. The crates in a stack or depot are grouped in sections indicating that they should be handled as a unit. To model these logistical elements we introduce the class COMPARTMENT. A component of class COMPARTMENT has two attributes both of the type REFERENCE. One called LABEL is used to describe the reason why the crates in the set CONTENTS are grouped together. The value of LABEL will refer to a transport firm when the compartment is part of a stack. That value will refer to a town if that compartment is in a depot. The stacks and the depots need not to be components; they are just references indicating sets of compartments. All other components and classes are easily described in terms of attributes. Here it is convenient to use arrays e.g. to designate that PORT[1] refers to the harbour on island 1 and PORT[2] refers to the harbour on the other island. This avoids the need for a class of islands as members of a set ocean, attractive though this may be!
PROSIM
tutorial
[E3.01]
chapter 2 - 23 -
PROSIM BV
A truck uses the REFERENCE attribute RESIDENCE to denote the town or harbour in which it stays or to which it drives. Because the towns and harbours form different classes, RESIDENCE is an unprotected REFERENCE attribute, just like LABEL discussed above. Let us now consider the process description of a truck collecting crates to be delivered in the export stack of the harbour.
After waiting a random number of hours the truck creates a new set and LOAD will refer to this new set. Twenty-four brand new crates destined for the other island are added to the set referred to by LOAD. As soon as the truck arrives at the export stack in the harbour it creates a COMPARTMENT stipulating that its LABEL indicates the same firm as BOSS indicates and that CONTENTS indicates the same set as LOAD indicates, as expressed by the statements:
LABEL
BOSS
CONTENTS
LOAD
And that will do! There is no need to create a special set for the compartment and put the crates into it one by one. (Remember that LOAD and CONTENTS are not sets, they are just set references.) Then the component indicated by THIS COMPARTMENT will be joined to the set which EXPORTSTACK OF RESIDENCE indicates. The same way of handling a collection as a whole is repeated at a higher aggregation level in the process description of the ship. Again there is no need to move the compartments one by one to the shipload, because the ship takes them all. The other way round is not as convenient:
PROSIM
tutorial
[E3.01]
chapter 2 - 24 -
PROSIM BV
The ship must be unloaded separately for each compartment because these compartments must be added to the remaining compartments in the import stack. When a truck distributes the crates among the compartments in the depot of its boss, again this has to be done one by one.
HANDS ON 8:
Work out what the consequences would be if we did not use the class compartment. The case file contains a percentage for each town. This number specifies the importance of that town for receiving crates from the other island. These percentages are cumulated in the order the towns are joined to the set TOWNS[I] as can be inspected in the process description of MAIN. The statements:
H
100 * SAMPLE FROM RAND
DELIVERY
FIRST TOWN IN TOWNS[3-SIDE] WITH PERCENTAGE > H
demonstrate a way to select randomly the destination of a crate according to the discrete distribution specified by these percentages. Other methods are discussed in section 3.6.
HANDS ON 9
Figure out what kind of tele transportation would be simulated if the third statement is skipped!
2.8.
Continuous state events
To learn more about continuous aspects, we will consider a model of a machine that processes metal bars. These bars must be at a certain temperature to be handled by the machine. On arrival in the system a bar is placed on a conveyor belt that runs in an environment at a temperature of 400 degrees. To prevent that bars are placed on the belt on top of each other, a warning light at the start of the belt shows red during 5 minutes following the moment a bar is placed on the belt. The transportation time on the belt is 20 minutes. So, on arrival at the machine a bar is already at a rather high temperature. During the waiting time, however, its temperature decreases. The machine operator uses an oven in which a bar can be re-heated until its temperature TEMP is high enough to be processed. In the model we suppose that the temperature of a bar will
PROSIM
tutorial
[E3.01]
chapter 2 - 25 -
PROSIM BV
change at a rate which is proportional to the difference between its temperature and the temperature of the surroundings. So TEMP' (the first derivative of TEMP) equals
FACT
* (SURROUNDINGS -
TEMP)
where the proportional factor FACT will differ from one bar to another and is assumed to be normally distributed. EXECTIME is the time the machine needs to process a bar. That completes the list of attributes describing a bar. Bars arrive at the belt with intervals that are exponentially distributed (Poisson process). Thus, after creation of a bar, the generator draws a number from that distribution to obtain the interval it waits before creating the next bar. Let us inspect the process description of the generator.
It creates a bar and attaches values to its attributes. Because the temperature of the bar has a continuous behaviour, the generator specifies the differential equation that must be used when integrating that attribute. The generator uses the reference NEXT_BAR to indicate the bar just created. As we know from the n_machine model, there is no need to introduce a reference attribute for that reason. THIS BAR could be used instead. We introduced NEXT_BAR here for a didactical reason. Because it shows that the attribute TEMP is used qualified and unqualified in the SPECIFY statement. That statement starts with: SPECIFY TEMP OF NEXT_BAR, indicating to which continuous attribute a differential equation must be attached. That differential equation is given as PRECEPT. It is not evaluated here; it will be evaluated during the time the bar, NEXT_BAR points to, is integrating. Than, the PROSIM runtime system will first point out that bar with THIS BAR before evaluating the differential equation. Therefore, the attributes of the bar involved are used unqualified in the differential equation. Finally you know all system functions of THIS: to indicate the current component, to indicate the component being scanned in a selection clause, to indicate the integrating component when evaluating its continuous attributes.
PROSIM
tutorial
[E3.01]
chapter 2 - 26 -
PROSIM BV
Please, be aware that those three rules form the key for correct qualifying! They concern class components only. Single components have unique user defined attributes; therefore those attributes need not to be qualified at all. As we mentioned several times before, the value of TEMP will change continuously during the time the bar, TEMP belongs to, is integrating. Therefore a bar needs a process description which enables it to control its own temperature. Inspecting the process description of a bar in the screen dump above, we see that the INTEGRATE statement is almost similar to the WAIT statement. INTEGRATE 5 MINUTES makes the bar suspended waiting for a time event. The difference with WORK 5 MINUTES is that during the integrate period its attribute TEMP is continuously updated. The same rules for the statement INTEGRATE (without ending specification). The bar integrates its TEMP forever; unless another component (the machine in our case) stops it using the CANCEL statement.
The machine has to wait until the temperature of a bar in the oven is at least 800 degrees. This is modelled by the statement:
WAIT WHILE TEMP OF JOB < 800
As we already know, during that wait the machine is suspended waiting for a state event. However, this state event differs considerably from the state events we discussed before. The difference is connected with the occurrence of that event. In a statement like:
WAIT WHILE ROW IS EMPTY
the occurrence of the state event is caused by another component; in this case by a bar entering the row. So, that moment is known precisely. However, when the temperature of the bar in the oven reaches 800 degrees, this is not indicated by any other component. Therefore, some other way of indicating that moment will have to be found. Figure 2 shows how this works.
PROSIM
tutorial
[E3.01]
chapter 2 - 27 -
PROSIM BV
Figure 2 The moment the temperature reaches 800 degrees must be surrounded by events (possibly generated by the integration mechanism) so that at the earlier event the condition is still TRUE and at the later event the condition will be FALSE. Thus, somewhere between these two events the state event should occur. The state event is approximated by repeatedly halving this time interval. The values of continuous attributes during this process are obtained by (non-linear) interpolation methods. This approximation process will stop when an interval smaller than 0.01 TIME UNIT is reached which contains the relevant moment. The moment at which the continuous state event occurs will be on the right-hand side of last halving. The user can specify the accuracy of the time at which such a state event occurs by adding WITH ACCURACY expr to the statement in which expr denotes a numerical expression that stipulates the maximum length of the interval in which the event occurs. Obviously the value 0.01 is the default value when the accuracy option is omitted.
PROSIM
tutorial
[E3.01]
chapter 2 - 28 -
PROSIM BV
3. Facilities of the language

3.1. Introduction
The basic concepts discussed in the previous chapter open the way to explain the facilities of the language as coherent groups of language items. Due to the experience obtained from the `hands on' exercises in chapter 2, the reader is supposed to practise the features described in this chapter without further guidance. The reader should be aware that the purpose of this tutorial is restricted to explain the context in which the various language features can be used. The PROSIM help file (F1) contains a complete overview of all PROSIM facilities. Each one is provided with a description of the syntax and the most relevant information for the user. Therefore all statements, functions, operators and system attributes that need no further explanation about the ways they can be used are not discussed in this tutorial. Furthermore it may happen that examples used in this tutorial contain statements or functions that will only be fully described in the help file.
3.2.
Process control facilities
3.2.1. States of a component

In this section the PROSIM facilities for controlling component processes are discussed. All the values of the attributes of a component together with those of the system attributes stipulate the state of that component. Especially the value of system attributes and verify functors control the way a component will proceed. They stipulate the following states of a component: 3.2.1.1. CURRENT component When a component is the current component it takes up the time of the processor in the computer performing actions that take no simulation time. That is why there is only one current component at a time. To simulate more components carrying out activities simultaneously, the components will become current one after another, without increasing simulation time. This can cause scheduling problems. The way to solve these problems is shown below. 3.2.1.2. SUSPENDED A component is suspended if it is waiting to become the current one. It does not need the intervention of some other component to become current. The moment a suspended component becomes current is determined either by an EVENTTIME or by a change in the state of the system. Examples:
WAIT 10 MINUTES
The current component is suspended, waiting for a time event. At the moment it becomes suspended, its EVENTTIME is put to NOW + 10 MINUTES
WAIT WHILE ROW IS EMPTY
The current component is suspended awaiting a state event. 3.2.1.3. INTEGRATING A component integrates its continuous attributes during the time it is in the integrating state. An integrating component can also be suspended:
INTEGRATE WHILE TEMP
<
100
3.2.1.4. PASSIVE A component is passive if it is not integrating and not suspended; it will only proceed its process according to an ACTIVATE or REACTIVATE statement in the process description of another component. Due to a statement like:
WORK
the current component becomes passive. Note that due to the statement:
PROSIM
tutorial
[E3.01]
chapter 3 - 29 -
PROSIM BV
INTEGRATE
the current component will be active but not suspended. Another component must cancel this component first (from integrating) and then (RE)ACTIVATE it to let it resume its process. 3.2.1.5. DATA component A component is called a data component when it has no activation point in a process description. A component is a data component: when it has never been activated from the moment it terminates itself to the moment it is reactivated (by another component, of course). The basic difference between a data component and a passive component is: a passive component has a reactivation point in a process description a data component has no reactivation point. 3.2.1.6. ACTIVE a component is active if it is in one of these states: the current component suspended integrating
3.2.2. Process control statements

3.2.2.1. ACTIVATE, REACTIVATE The current component can cause another component that is not active to become suspended with an ACTIVATE or REACTIVATE statement. If that -not active- component is a data component it is unknown which activity it should perform first when it becomes the current one. Therefore the (RE)ACTIVATE statement must be extended with a label indicating the so called activation point of the component involved. In case a passive component has to resume its process with the next statement in its process description, its activation point was already known, thus needs not to be specified. Examples:
REACTIVATE GENERATOR
suspends the generator (for 0 time units). It proceeds from its already known activation point when it becomes current.
REACTIVATE GENERATOR WITH DELAY 5 MINUTES
suspends the generator for 5 minutes. After which time it will become current to proceed from its activation point.
ACTIVATE GENERATOR WITH DELAY 5 MINUTES FROM CREATE
suspends the generator for 5 minutes and sets its activation point to the statement addressed with the label CREATE. 3.2.2.2. CANCEL With a CANCEL statement, the current component makes a suspended or integrating component passive. The statement
CANCEL GENERATOR
only affects the component GENERATOR, while the statement

CANCEL ALL
will cancel all suspended and integrating components. Only the current component remains active. 3.2.2.3. TERMINATE With the statement
TERMINATE
the current component becomes a data component. (It loses its activation point.) The sequence
PROSIM
tutorial
[E3.01]
chapter 3 - 30 -
PROSIM BV
CANCELL ALL TERMINATE
will cause the simulation to stop because the current state of the system will remain unchanged after those statements have been executed. The next example demonstrates how one component can redirect the process of another component. It deals with the rather common case of a machine (aggregate of a production device and an operator) delayed due to disruption. (In this example MACHINE is a single component and REPAIRTIME a distribution.)
The first activation of the machine (usually by MAIN) will be from the label RUN. If there was no DEVIL to cause disruption, the machine would repeat its activities normally. But the devil will change that normal behaviour according to its process description shown in the screen dump. If NEGEXP is an exponential distribution, the DEVIL will cause disruption according to a Poisson process based on the time the machine is producing. - NOW is the time the machine still needs to finish its job. After the disorder has been repaired, the machine will proceed again with that job but with a reduced EXECTIME.
EVENTTIME OF MACHINE
Be aware that the statement:

EXECTIME OF JOB
EVENTTIME OF MACHINE CANCEL
NOW CANCEL MACHINE
must be executed before the EVENTTIME of the machine!
statement. Because
destroys the
The current component can become passive or suspended with a WAIT, WORK, HOLD or PASSIVATE statement. Hence WAIT, WORK, HOLD and PASSIVATE are synonyms used to improve the readability of the model. The use of such a statement without an extension makes the current component passive. The extension determines whether the component is waiting for a time event or a state event. The state event concept is explained in paragraph 2.2 and section 2.8. Two aspects were discussed there: more components waiting for the same state event the matter of accuracy about the moment a continuous state event occurs. Those aspects should be known, so, reread those paragraphs in case of any doubt!
PROSIM
tutorial
[E3.01]
chapter 3 - 31 -
PROSIM BV
3.2.3. Scheduling of activities

As mentioned in section 3.2.1 all components which must be active at the same time (simulation time) will be scheduled to become current one after another without increasing the simulation time. The order in which the components become current can be important in preventing the occurrence of erroneous situations; as will be demonstrated in the next example:
Figure 3 Consider a simple traffic junction (all one way streets) controlled by a traffic light installation. The installation will alternately change the colour of lights 1 and 2 as long as there is still traffic coming from either side 1 or 2. During that time the installation is active according to a process description. During quiet periods (at night for instance) when the junction is completely empty, the installation will turn both traffic lights to red and make itself passive. When a car arrives at a detector and both lights are red, the car will reactivate the installation to produce a green light with the statement:
REACTIVATE INSTALLATION IF LIGHT[1]
LIGHT[2]
(if both lights are equal then they are red) According to Murphy's first law at some time two cars must arrive at exactly the same time; one at detector 1 and the other at detector 2. These cars will be current one after another (the car suspended first will be the first to be current) which will cause an attempt to reactivate the installation twice. PROSIM will produce a runtime error at the second reactivation because a component which is already suspended cannot be activated again. The erroneous situation will be cured if the installation becomes current between the two cars, because the installation will immediately turn one of the traffic lights to green, preventing the second reactivation when the second car becomes current. To achieve the required schedule of the three components, the REACTIVATE statement must be extended to:
REACTIVATE INSTALLATION AFTER THIS IF LIGHT[1]
LIGHT[2]
The extension AFTER THIS will schedule the installation to become the next current component directly after the current one, thus preventing the runtime error. As demonstrated above, AFTER and BEFORE used in addition to a (RE)ACTIVATE statement can schedule current events, but future events can be scheduled in an analogue way. For instance: if two cars crash into each other at the junction, despite the correct scheduling of components, a statement like:
ACTIVATE AMBULANCE BEFORE POLICE
ensures that the activities of the ambulance have priority over those of the police.
PROSIM
tutorial
[E3.01]
chapter 3 - 32 -
PROSIM BV
3.2.4. System attributes of components and sets

The values of all attributes of a component form the state of that component. System attributes are automatically attached to components and sets to be helpful in determining the state, especially where the PROSIM system itself causes changes. Run control depends considerably on correct information about the state of all components and sets. In the examples below, we assume that CMP refers to a (class) component and ROW refers to a set. Remind that all system attributes should be qualified. 3.2.4.1.
ARRIVALTIME ARRIVALTIME OF CMP
delivers the moment of creation by NEW. 3.2.4.2.

NAME NAME OF CMP / NAME OF ROW
delivers the character string of at most 10 characters that is attached to CMP/ROW at creation by NEW. That string is formed automatically by adding a serial number to the classname/SET or according to the CALLED option used. 3.2.4.3.
QUEUETIME QUEUETIME OF CMP IN ROW delivers the moment CMP became
a member of ROW.
3.2.4.4.
EVENTTIME EVENTTIME OF CMP
delivers the scheduled moment of the event the suspended component 1 otherwise. 3.2.4.5.
ACTIVE CMP IS ACTIVE delivers TRUE if CMP FALSE
CMP
is waiting for and
is the current component or
CMP
is suspended and/or integrating and
otherwise. where CMP

IS ACTIVE
CMP IS NOT ACTIVE returns TRUE in all cases
returns FALSE.
3.2.4.6.
FIRST, LAST FIRST OF ROW / LAST OF ROW
refers the first/last component situated in ROW. The first according to time can be obtained with the selection clause: CMP FIRST classname IN ROW WITH SMALLEST QUEUETIME OF THIS However, in case of first in first out that will be FIRST OF ROW. 3.2.4.7. SUCC, PRED SUCC / PRED OF CMP IN ROW refers the component that is situated in ROW after/before CMP. 3.2.4.8.
LENGTH LENGTH OF ROW
classname IN ROW
returns the number of components being members of ROW. 3.2.4.9.

ROW IS EMPTY
[NOT]
returns LENGTH 3.2.4.10.MEAN

MEAN OF ROW
EMPTY OF ROW
= []
0.
returns the mean of the times components stayed in the history interval specified at the creation of ROW.
ROW.
These components left
ROW
during
3.2.4.11.BELONGS CMP BELONGS [NOT] TO ROW returns TRUE [FALSE] if CMP is a member of ROW and FALSE [TRUE] otherwise. 3.2.4.12.SORTINGPAR
SORTINGPAR OF CMP IN ROW PROSIM
tutorial
[E3.01]
chapter 3 - 33 -
PROSIM BV
returns the ranking value according to which CMP is ranked in ROW.
3.3.
Programming Facilities
3.3.1. Introduction
This paragraph concerns programming facilities that are not directly related to modelling but are exclusive for PROSIM and need further explanation. In other words: we ask the user to learn all other programming facilities by trial and error and by studying the examples. That causes a grey area from which we take some items here. 3.3.1.1. TIME UNIT The TIME UNIT is specified in the definition section. It can be SECOND, MINUTE, HOUR, DAY, MONTH, or YEAR. All data (including output data) concerning time are in that time units and decimals of it. Thus, with MINUTE as TIME UNIT: 143.50 means 143 and a half-minute. If we want 143.50 to be hours, we just write: 143.50 HOURS and PROSIM will take care that the result will be hours, whatever TIME UNIT is specified. 143 MINUTES + 30 SECONDS results in 143.50 if the TIME UNIT is MINUTE and in 2.3916667 if the TIME UNIT is HOUR. Those conversions are straightforward; however, we have to know that 1 MONTH = 30 DAYS and 1 YEAR = 12 MONTHS. Thus 1 PROSIM YEAR has 360 DAYS. 3.3.1.2. TRUE, FALSE The result of a logical expression is TRUE or FALSE. These logical results can be used in arithmetical expressions. Assuming RAND is uniformly distributed between 0 and 1, the statement: DIRECTION SAMPLE FROM RAND < 0.4 causes the value of DIRECTION to be TRUE with probability 0.4 and FALSE with probability 0.6 if type of DIRECTION is logical. If that type is numerical the result is l respectively 0. 3.3.1.3. =, IS, , IS NOT Comparison of numerical values, characters and character strings is performed using the = and the symbol. IS and IS NOT clauses are used in all other cases: REF1 IS REF2 delivers TRUE if the references REF1 and REF2 point to the same component, METHOD IS CASE1 delivers TRUE if the macro attribute METHOD indicates the macro CASE1, ROW IS NOT EMPTY is TRUE if LENGTH OF ROW = 0.
3.3.2. Characters and character strings

If CHAR is defined as a single item of the type assigned to it
CHAR CHARACTER,
than only one character can be
"Y"
The statement:
CHAR
"YES"
is erroneous. If STRING is defined as a one-dimensional multiple item of type CHARACTER e.g.

CHARACTER: STRING[10]
than STRING (without brackets) is a zeros initially. The statement

STRING
CHARACTER STRING
containing 10 characters being binary
"YES"
will make the first three characters respectively Y, E and S. The other characters will be blanked.
STRING[7]
just indicates a character. So the statement:

CHAR
STRING[7]
PROSIM
tutorial
[E3.01]
chapter 3 - 34 -
PROSIM BV
only effects that character. If PAGE is defined as a multi dimensional multiple item e.g.
CHARACTER: PAGE[30, 80]
than PAGE[3] denotes a character string containing 80 characters. It is the third character string of the one-dimensional character string containing 30 strings. Still PAGE[5, 25] is just a character.
PAGE[5, 25]
225
is legal. It sets that character to , being the 225th symbol of the ASCII table. The value of the right hand side of such an assignment will be taken modulo 256. The CONVERT statement assigns a numerical value to a character string:
CONVERT SIN(10) TO STRING FIELDLENGTH 6 DECIMALS 2
In this case the string -0.54 is assigned to STRING. If no decimals are desired, DECIMALS can be deleted. If the value following DECIMALS is negative the result will be in scientific notation and the number of digits following the decimal point will be minus that value. The other way round is easier. If A is defined as an attribute with a numerical type, than A PAGE[2] will assign a value to A if the contents of PAGE[2] can be converted to a numerical value and produces an error message otherwise.
NOTE:
This conversion is only allowed if a character string forms the right hand side of an assignment statement. So, it cannot be used somewhere in an expression. The CONVERT statement offers another facility:
STRING CHREAD FROM CASE CONVERT STRING TO UPPERCASE GOTO FOUND IF STRING = "END"
This prevents that the test should be repeated for end End eND etc.
CONVERT STRING TO LOWERCASE
is also possible. Let, LONG and SHORT be character strings defined as:
CHARACTER: LONG[100] CHARACTER: SHORT[8]
After the statements:

LONG SHORT
" " =
ABCD" ABCD"
it sounds reasonable that the test:

LONG SHORT
produces TRUE. Thus, the comparison does not include the number of trailing blanks in a string. The string length of both strings is equal to 5. That number of characters preceding the trailing blanks can be obtained with LENGTH OF. After SHORT "ABCD"
LENGTH OF SHORT
delivers TRUE and

LONG
SHORT
will be false, because leading blanks do count in the comparison. The test:
LONG[35]
= "ABC" [E3.01] chapter 3 - 35 -
PROSIM
tutorial
PROSIM BV
is illegal, because a character cannot be compared with a character string. Tests like:
LONG[85] = SHORT[8] "P" = LONG[20]
are legal.
WARNING:
All characters of an unused character string have the value NONE which is not a blank. Thus, if a string is only used as a multiple character, assigning some individual characters, the remaining characters are still NONE. There are two consequences: LENGTH OF will not find any trailing blanks resulting in the full length of the string, writing a string like that will stop when finding the first NONE.
3.3.3. WRITE and READ

3.3.3.1. WRITE The WRITE statement has everything to do with character strings. Because it copies the contents of characters and character strings to a file or to the output window. The CONVERT statement must be used first to write a numerical value. That may look complicated at first sight, but it is most skilful when things become complex. With this concept, we can prepare a complete page, in a random access way, before writing it. With the statements
FOR I END
1 TO LENGTH OF STRING
PAGE[20, 40+I]
STRING[I]
the value of SIN(10) as formatted by the PAGE starting at position 41. The statement:
CONVERT
statement above is placed on line 20 of
WRITE STRING;LONG;CHAR;SHORT TO OUT WITH IMAGE A(10)X(3)A(7)|A(1),X(2),A(4)|
transfers characters to the datastream OUT according to the following rules: The objects: STRING, LONG, CHAR, SHORT form a list of strings and/or characters to be written, according to the specifications in the image list. There are three types of specifications: A(aexp) after evaluation, aexp denotes the field length (in characters) in which the next object in the list will be written (left adjusted and may be truncated), X(aexp) after evaluation, aexp denotes the number of spaces to be written, | denotes a new line instruction. For each item in the object string there must be an A(..) in the format list. The writing is controlled by all items in the format list successively. In our example the line containing the write pointer will be extended with 20 characters. The first 10 keeping the value of STRING, followed by 3 spaces and 7 characters to keep the first 7 characters of the contents of LONG. The value of CHAR takes the first position of the next line followed by two spaces and the value of SHORT in 4 positions. After the execution the write position will be the first position on the next line.
NOTES:
When a file is opened for output using the OPEN statement, the position of the write pointer is at the end of the file, saving the results of previous use. In case the file must be rewritten, use the REWIND statement before the execution of the first WRITE statement. Files can be alternately used for input and for output. Each time a file is opened for input the read pointer is at the start of the file. It is recommended to close a file with the CLOSE statement after use, preventing ambiguous situations in a multi task surroundings. tutorial [E3.01] chapter 3 - 36 -
PROSIM
PROSIM BV
The next example simulates the deal of a deck of playing cards over four players. The deal itself may be interesting, but the meaning of the model concerns the writing of the result as shown in the screen dump below.
In the next screen dump we can see how the card deck is filled with the 52 playing cards. Each card has a C_TYPE where 1 denotes spades, 2 hearts etcetera, and a C_VALUE where 1 denotes the ace, 2 the king etcetera. Then the players are created each with four sets HAND[4] to give room for the cards of equal C_TYPE.
The card deal is performed by selecting a card randomly from the deck for the four players in turn (demonstrating the use of the MODULO function). The RANKED option in the JOIN statement sorts the cards in the hand in order of increasing values. There is nothing really new so far. The following screen dump shows the remainder of the program concerning the writing job.
PROSIM
tutorial
[E3.01]
chapter 3 - 37 -
PROSIM BV
The general idea is to cover the area to be written with a character matrix PLAY of 14 by 28 characters. Firstly, the square in the middle is filled up. The hands of each player are displayed in a sub area of the matrix PLAY. The North West corner of each sub area is specified using the attributes POS_I and POS_J of each player. Due to these attributes the hands of the players can be positioned in PLAY using one for loop. After that the writing is almost trivial; only one WRITE statement will do. 3.3.3.2. READ The READ function copies part of the contents of an ASCII file (being characters) to a character string. The full syntax of the statement contains the specification of the number of characters to be copied starting from the read pointer. The statement
LONG
READ FROM FILE WITH FIELDLENGTH 50
takes the contents of the next 50 characters from file (or less if the end of file marker is reached) and assigns the result to LONG. It is a kind of reading with closed eyes. The characters are copied whatever they are, including blanks, comments, linefeeds etcetera. Most data files are produced automatically by computers or devices for measurements. Normally those files contain much more information than is needed for our applications. All records, however, have the same format. Therefore we can speed up the reading of those files considerably by copying records in stead of reading them item by item. See 3.5 for an example is this way of reading The statement:
A
READ FROM FILE
performs reading producing a character string that starts with the first character following the read pointer that is not a separator (blank, a linefeed or a carriage return symbol) and
PROSIM
tutorial
[E3.01]
chapter 3 - 38 -
PROSIM BV
ends with the last successive character that is not a separator or the end of file marker. Comment strings (between successive @ symbols) are skipped if they stand alone. This means that the starting @ must be preceded, and the ending @ must be followed by a blank or a separator: @ @ @
THIS IS A COMMENT@ THIS IS @ONLY ONE @COMMENT @ THESE ARE @ @TWO COMMENTS @
The result is assigned to A, which is always possible if A is a character string. If the type of A is numerical, the result of the reading will be converted as described in 3.3.2. Thus a READ function can form the right-hand side of an assignment statement. It is not allowed to appear as a part of an expression.
3.3.4. Operators and built in Functions

3.3.4.1. Operators Operators are (in order of prevalence): * / + - = < > & | B means A to the power of B. This operation is valid in all cases where the result will be a real number.
A
The minus sign - can be uses as minus operator as well as prefix operator. Real numbers are stored in quad words being 64 bits long. A = B with A and B being real is, theoretically, only true if all these bits are equal. Be aware that a number as, for instance, 0.01 is reciprocal in binary notation. So: after:
A
FOR J END
1 TO 100 A
0.01
is not exactly equal to 1. PROSIM has a smart solution to this numerical problem: When comparing two REAL values, they are assumed to be equal if the absolute value of there difference is smaller than 10-14 . So the result of the comparison
A A
1 INTEGER,
is FALSE because the right hand side is of type statement B 1, the two expressions
A A
not
REAL.
But, after executing the
= =
1.0 B
both return TRUE. If L1 and L2 are logical then L1 & If L1 and L2 are logical then L1 | N + (A > B) delivers N+1 if A > 3.3.4.2. Built in functions Arithmetical functions are: CEIL, FLOOR, MIN, MAX, ABS, and MODULO
CEIL(2.3) = 3 CEIL(-2.3) = -2 FLOOR(2.3) = 2 FLOOR(-2.3) = -3 MIN and MAX can have two 12 MODULO(5) = 2 -12 MODULO(5) = 3. L2 L2
delivers TRUE if and only if L1 and L2 are both TRUE. delivers FALSE if and only if L1 and L2 are both FALSE. B and N otherwise.
or more parameters.
Goniometrical functions are: SIN, COS, TAN, ARCSIN, ARCCOS and ARCTAN. Angles are supposed to be expressed in radians. Mathematical function are: EXP, LOG and SQRT. EXP and LOG are based on e. 10 LOG(A) can be calculated by: LOG(A)/LOG(10)
PROSIM
tutorial
[E3.01]
chapter 3 - 39 -
PROSIM BV
3.3.5. Selection clauses

Selection clauses are used to select one or more class components, which fulfil certain properties, from a set. 3.3.5.1.
FIRST/LAST
clause
A FIRST or LAST clause selects just one component (or returns the value NONE where no component can be found). The difference between FIRST and LAST is obvious, it refers only to the direction in which the set is scanned. Therefore we will limit ourselves to an explanation of the FIRST clause. The simplest form is:
NEXT
FIRST PERSON IN ROOM TO SET.
where PERSON denotes a CLASS and ROOM denotes an attribute of the type REFERENCE This statement selects the first component in ROOM belonging to the class PERSON. This statement can be expanded in three ways: WITH GREATEST aexp WITH SMALLEST aexp WITH lexp can be any expression which delivers a numerical value. which delivers a logical value.
aexp lexp
can be any expression
Remind that FIRST OF ROOM concerns the system attribute FIRST, that delivers the reference to the first component in ROOM whether it is a PERSON, a DOG or whatever without any selection. An unqualified user defined attribute used in aexp or lexp belongs to the class component involved if that attribute is attached to the class indicated after FIRST. All system attributes must be qualified with THIS classname if the class component being scanned is involved. Example:
NEXT FIRST PERSON IN ROOM WITH THIS PERSON BELONGS TO BRIDGECLUB & SEX = FEMALE
where BRIDGECLUB refers to a set and SEX is an attribute of PERSON. The FIRST and LAST clause can be used: as the right hand side of an assignment statement to denote the component in a (RE)ACTIVATE statement CANCEL statement JOIN statement REMOVE statement Warning: Consider the statements:
THIS PERSON BOY JOIN FIRST PERSON IN ROOM WITH AGE AGE
<
10 TO PLAYGROUND RANKED BY AGE
is used unqualified twice in the last statement; which means that both times the qualifier is assumed to be THIS PERSON. But the THIS PERSON designation changes during running. First, THIS PERSON is set to indicate each of the persons in room in turn to find the first one with AGE<10. Then, THIS PERSON is reset to its designation before the selection clause was invoked. So AGE used in the ranked option is the age of boy. When the selected person has to be ranked according to AGE, then the statement should be:
THIS PERSON FIRST PERSON IN ROOM WITH AGE JOIN THIS PERSON TO PLAYGROUND RANKED BY AGE THIS PERSON
<
10
BOY
3.3.5.2.
EACH
clause
The EACH clause selects a set of class components.

PROSIM
tutorial
[E3.01]
chapter 3 - 40 -
PROSIM BV
Example:
JOIN EACH PERSON IN ROOM WITH AGE < 16 TO BEDROOM REMOVE EACH PERSON IN BEDROOM FROM ROOM
The EACH clause can be used: in a FOR statement to select the components to be (re)activated with a (RE)ACTIVATE statement to select the components to be cancelled with a CANCEL statement. to select the components to be joined to or set with a JOIN statement to select the components to be removed from a set with a REMOVE statement
NOTES
The statements
FOR EACH PERSON IN ROOM JOIN NEW PERSON TO ROOM END
form not an endless loop because EACH the loop.
PERSON IN ROOM
is evaluated just once to initiate
A FOR EACH loop should not contain statements which could alter the number of times the loop has been set to repeat for, such as WAIT, TERMINATE, INTEGRATE, or JUMP to a label outside the loop. Because it will cause ambiguity about the designations of THIS and pollute the PROSIM system with unpredictable effects. An error message will be produced in case this rule is violated. Terminating the loop before all selected components are processed can be achieved using the BREAK statement.
A 0 FOR EACH PERSON IN ROOM A A + AGE BREAK IF A > 100 END
At the moment A becomes greater than 100, the loop is terminated. to its original value and the process continues after END. In a statement like
CANCEL EACH PERSON IN ROOM
THIS PERSON
is reset
no runtime error will be produced where there are no persons in the room. The same rule applies to REMOVE, JOIN and (RE)ACTIVATE.
3.4.
Functions and Macros
3.4.1. Introduction
Functions and macros have in common that the current component invokes the processing of a named series of statements placed outside its process description. All other facilities are completely different. Starting with the modelling concept: a macro must be considered as a part of a process description that for some reason is placed somewhere else. The current component jumps to it to perform outside described activities and returns back after completion. Those activities may take simulation time; so they may contain WORK and INTEGRATE statements. Like modules, macros are strongly connected to a model; every variable, used inside a macro, must be defined in the definition section. By invoking a function the current component let the computer do something for it instantly, not taking any simulation time. A function delivers a result that is considered to be a real value. Therefore, a function is invoked by the use of its name in an expression.
PROSIM
tutorial
[E3.01]
chapter 3 - 41 -
PROSIM BV
3.4.2. Functions
3.4.2.1. Introduction As mentioned: a function is used to let the computer do something for the current component. That something takes no simulation time. Forbidden statements in the description of a function are: WAIT and its synonyms, INTEGRATE, TERMINATE and JUMP. Functions are added to the model either as EXTERNAL functions in the definition section or by using the Fnc tab. Because functions can have parameters and locals, there will be many functions that do not need any item of the definition section. That makes those functions suitable for any model. Therefore, the name of a function is global: it has no special name within a model like modules and macros. The following screen dump shows an example of a function. In this case one to add characters in a string of characters.
There are 5 parameters that must be specified one by one, because the order is important. That order must be obeyed when specifying the corresponding arguments to invoke the function. The next screen dump shows an example of the use of the function.
Parameters and locals of a function are of the type CHARACTER.
INTEGER, LONG, REAL, LOGICAL
or
There are two ways to pass arguments to parameters: by value or by name. 3.4.2.2. by value parameters A by value parameter has its own address in memory. That makes it a variable the initial value of which is obtained by evaluation of the corresponding argument expression. So, to each by value parameter the result of the corresponding expression evaluation is assigned. A parameter is a single variable; only one value is passed to it. In our example the parameters T_START, N_CHARS and S_START are by value parameters.
PROSIM
tutorial
[E3.01]
chapter 3 - 42 -
PROSIM BV
3.4.2.3. by name parameters A by name parameter does not own an address in memory to keep a value. It makes use of the address of a user defined attribute. By a way of speaking: the parameter acts as if it is that attribute. So, using the name of the parameter and the name of the attribute effects the same address in memory. No values are passed at all. They just remain where they are. There are two most important consequences: An assignment to a by name parameter causes a change of the value of the corresponding attribute, because the parameter takes the place of that attribute. A multiple attribute has one address (name). So, by name parameters can address multiples. The parameters TARGET and SOURCE in our example are by name parameters. They must be, because both concern multiple items. Note that the markers < and > surrounding the type of the parameter indicate that parameter to be a by name parameter. For the same reason these markers must be used with the arguments, as shown in the last screen dump. The compiler has to check that in case of multiples the number of dimensions is properly used within the function. Therefore the number sign # must be used, one for each dimension, separated by a comma. 3.4.2.4. locals Variables that are only needed within a function can be attached to the function as locals. They have a type as described above and they can be multiple items. Those variables only exist during the time the function is executed. Every time the function is invoked the locals are created with an initial value of zero (characters contain initial NONES, not being blanks). They are existent until a RETURN is executed that belongs to that function. So, they are preserved during the execution time of another function that is invoked within the function. Apart from memory requirements there are no limits; even the function itself can be used in that way, offering most interesting recursion facilities. 3.4.2.5. external functions Within a function all items of the definition part of the model can be used. If only one of those items is used, the function can only be used with models where that item is known. If only locals and parameters are used, as is the case with our example, the function is suitable for any model. By clicking the external button the object code of a function like that, is created and stored as a file with the name of the function, but another extension (.pfo). From that moment on the function can be used in any model just by specifying its name in the definition section.
NOTE:
The use of functions is convenient in many cases. Therefore most of the examples in the following paragraphs will contain functions, taking away the need for more examples in this paragraph.
3.4.3. Macros
3.4.3.1. Introduction There are several reasons for using a macro: Complexity Readability and manageability of a process description will be improved when a series of complex activities are described elsewhere in the model. Repetition It may be that the same series of activities have to be described in different places. A macro can avoid repetition of activity descriptions in the text. Uniformity For this most important reason attributes of the type MACRO are introduced as explained in the trolley example below.
PROSIM
tutorial
[E3.01]
chapter 3 - 43 -
PROSIM BV
Macros are added to a model like modules. There is a special Mac tab to create and maintain macros. Like modules macros have a name, used to address the macro inside the model and a file containing the source of the macro. So, modules and macros can be used with different names in several models depending on the contents of the definition sections. If the file containing the source of a macro is not fully qualified, it is supposed to be a member of the module folder specified in he options. 3.4.3.2. attributes of type macro To demonstrate the importance of the concept of attributes of type MACRO, we have to enter the real world practice of modelling. The next example will be recognised by people familiar with problems about feeding an assembly line (of the production of cars for instance) with materials. The picture below shows a transportation network where trolleys are moving over (or hanging from) rail sections (one way clockwise) connected to each other by nodes. A series of sections is forming a loop: the main track. That is the octagon not containing any supplier or user. Suppliers are shows as supply1supply6; they frequently load a trolley to feed the users with corresponding numbers. Trolleys moving over the main track have priority over trolleys coming from side-tracks. Side-tracks can be platforms, where trolleys are unloaded and/or loaded, or can be short cuts of the main track, or waiting tracks for idle trolleys, or what so ever.
This picture is used to explain animation facilities in chapter 5. For a configuration problem like this, animation is a very useful output tool. As explained in chapter 5 the picture is created automatically from data as listed below. Every point in the picture has co-ordinates X and Y according to an origin somewhere in the bottom left corner. With this in mind you can figure out, from the data below, that node 1 is the entrance to user1, node2 the exit of user1 etceteras. The numbers in the column freq denotes the interval in minutes that a load should be send from the supplier to feed the user. n_tr denotes the number of trolleys that are supposed to be needed for the job. Routing, 1 5 16 for supplier1 for instance, specifies the nodes where a trolley must leave the main track to deliver a load and to return to the supplier.
PROSIM
tutorial
[E3.01]
chapter 3 - 44 -
PROSIM BV
Each trolley has an EXIT_NODE; referring the node in its route where it has to leave the main track to proceed on a side-track. Because there are different kinds of side-tracks, there are as many macros in the model describing the trolleys behaviour for each kind. So, each time a trolley arrives at its exit node it has to jump to one of those macros; in fact that macro indicated by SIDE_TRACK, an attribute of type MACRO of the exit node. These attributes prevent that there should be a different jump statement for each macro, introducing a series of test to find out which one. The following screen dumps show the behaviour of the trolleys on the main track (process description of a trolley in module MAIN_ROUTE) and the behaviour of a trolley on side-tracks being respectively a short cut and a handling station described as macros.
PROSIM
tutorial
[E3.01]
chapter 3 - 45 -
PROSIM BV
As a consequence of the priority rule, there will be no queuing on the main track, which keeps the description simple, because trolleys will not pile up on the main track. DISTANCE is the safety distance to be obeyed as minimum distance between trolleys. It also specifies the area around a node on the main track where a trolley must proceed with reduced speed. So, there can be at most two trolleys in such an area. That number is the value of CLAIMED. The safety rule will be obeyed on the main track by forbidding a trolley to enter the main track at a node with a positive CLAIMED. The description of the macro SHORT_CUT could be rather simple if we only calculate the time (driving + waiting) a trolley spends on a short cut. However, because animation will be important, the queuing up of trolleys must be modelled precisely. Therefore we need the following attributes: SEC_ROW: the set holding the trolleys in a section being a short cut. REACHABLE_POINT: the distance from the start to the point the trolley drives to without crashing the tail of the queue, or the position where the trolley already reached and is waiting. FREE_WAY: to calculate the next REACHABLE_POINT. DELAYED: true to indicate the trolley is waiting or moving up in the queue. HEADER: the predecessor according at the moment the reachable point is calculated.
The macro STATION described the behaviour of a trolley on a side-track containing a platform for loading or unloading. For a trolley there is no difference, because the loading or unloading activities are performed by suppliers or users. Be aware that the END_POINT of a section points to a PLATFORM if that section is the entrance section of that platform and points to NODE otherwise. That is why the reference is not class protected. If the animation shows that trolleys are moving over each other on the way out of a section of a platform, it can only mean that the main track is overcrowded. If so, the configuration of the system should be adapted. There will be many options to do so. The simulation has only to show what problems can be expected with which option. A model needs not to describe unwanted situations in full detail. Pointing out unwanted situation should be satisfactory.
PROSIM
tutorial
[E3.01]
chapter 3 - 46 -
PROSIM BV
The next screen dump shows a part of module OPERATION with the description of the process of a supplier. A supplier starts with calling its trolleys from the parking. De label NEXT_SUPPLY is the start of the loop in which the supplier tries to send a trolley to its user every INTERVAL minutes. If no trolley is present at that moment, the waiting time of the supplier is stored in a pointstream for output purposes.
The following screen dump shows the macro CREATE_PLATFORM as a part of the process description of MAIN. MAIN jumps to this macro two times when configuring the platforms. So this time a macro is used to avoid repetition of activity descriptions:
PROSIM
tutorial
[E3.01]
chapter 3 - 47 -
PROSIM BV
This macro shows how the attribute of type MACRO SIDE_TRACK is initiated. The length of each section must be calculated. Sections are created at several locations in the process description of MAIN. So, it is convenient to use a function for that calculation:
The trolley model is included with the installation together with the case and input file used in this example. The model is a typical example of a model that is needed to deal with complexity caused by the number of parallel processes. There are no complex calculations, no differential equations to be solved even any random elements.
3.5.
Pointstreams
3.5.1. Introduction
Normally, time series form the most important output of a simulation run. Time series keep the fluctuations of variables, allowing presentation of the characteristics graphically and/or as histograms. Therefore, PROSIM provides a special language concept to handle time series. That concept, called POINTSTREAM, also offers facilities to transport time series from one model to another model in a most efficient way. Complex real life systems usually need more models, to simulate aspects on different levels of aggregation. Time series can be an essential part of the interface connecting those models. There are three types of pointstreams: user defined POINTSTREAMS. Every point of it can be considered as point in an XOY plane. The STORE statement will join points to a pointstream. There are two options: ranked by their X-values, or joined to the tail.
PROSIM
tutorial
[E3.01]
chapter 3 - 48 -
PROSIM BV
In simulation studies, X mostly denotes simulation time. A POINTSTREAM can be considered to express a continuous function Y = f(X) given as a table. The VALUE function produces values of that function using linear interpolation between adjacent points. histories of sets are POINTSTREAMS. They have a special structure to contain both the length (number of members) of a set as time function and the series of the waiting times of components that left the set. histories of continuous attributes are POINTSTREAMS. Also with a special structure because each continuous attribute has (during integration intervals) a derivative. This derivative is kept in each point allowing third order interpolation between adjacent points. The VALUE function, when operating on a continuous attribute, uses that interpolation to produce historical values of that attributes with the similar accuracy as obtained by integration. This facility opens the way to simulate dynamical control systems as demonstrated below.
3.5.2. User defined pointstreams

Just like all language concepts, a pointstream is created by the NEW function and a REFERENCE TO POINTSTREAM is needed to address it. Let us suppose that for some car traffic model we need the intensity of cars passing a given road profile (one direction) as input. Road detectors provide the intensity in cars per minute every 10 minutes, resulting in an input data file like:
The file contains more information than we need for our model, which is a normal in cases like this. We just want to extract the time in minutes and the density from it. The model TRAFFIC_DATA, shown in the screen dump below, transfers an input data file containing intensities to a pointstream. That pointstream is shown graphically in INT_WINDOW and will be filed on disk with the FILE statement.
Due to the automatic data collection, all records have the same structure of 34 character bytes (including two linefeed characters). So, records can be read in stead of item by item. tutorial [E3.01] chapter 3 - 49 -
PROSIM
PROSIM BV
This model will speed up the traffic simulation considerably. Suppose the system to be simulated concerns a traffic junction where three roads are involved, each with traffic from both sides. As input for the model, 6 data files containing traffic intensities are needed with data covering a period for at least one week. Therefore, over 12000 numbers must be read from disk for every run with the model. Due to the conversion to pointstreams only 12 file accesses will do for copying the 6 pointstreams to memory. This will be achieved when executing the statements:
FOR I
1 TO 6
INTENS[I] NEW POINTSTREAM ATTACH READ FROM CASE TO INTENS[I] END
Supposing INTENS[6] is defined as multiple REFERENCE TO POINTSTREAM and the names of de files, containing the stored pointstreams are listed in the case file. Some remarks: the ranked option of the STORE statement was not needed here because the automatic data collection guarantees ranked records, with: VALUE OF INTENS[3] AT(T) the value of intensity number three at any time T is obtained by means of linear interpolation between adjacent points. If such a point is missing, the value of the nearest point is delivered, if the STORE statement concerns simulation time: STORE VAL TO INTENSITY AT NOW, than AT NOW can be omitted. In another traffic model the intensity of cars happens to be output. The simulation covers a month for instance. However, we are only interested to inspect the output every 6 hours. So, there is no need to keep points in the pointstream that are older than 360 minutes. In this case the pointstream can be created with
INTENSITY
NEW POINTSTREAM WITH HORIZON(360)
This allows the STORE statement to drop the oldest point in the pointstream in case the value of the independent of the oldest point differs more than 360 from the value of the newest one.
3.5.3. History of SET

In chapter 2 we used sets with history as a convenient way comparing results of simulation runs. Here, we discuss some more features. Let ROW be defined as a REFERENCE TO SET, than the statements:
ROW
NEW SET WITH HISTORY
PICTURE NEW WINDOW ATTACH HISTORY OF ROW TO PICTURE
will add a pointstream to the set ROW refers to. The history applies for the complete life of the set during the simulation and concerns two aspects: the number of members of the set as time function. That function changes only at discrete time events. Therefore, a barchart will be produced when the corresponding window is shown, each time a component leaves the set, the time that component has been a member of the set is stored in the pointstream. That data will be displayed as a histogram when using the histogram button in the corresponding window.
NOTES:
If the history of a set is attached to a window, it still belongs to the set. So every time the window is shown the graph and histogram will be updated. The VALUE function does not apply to set histories. With the statement:
ROW
NEW SET WITH HISTORY 100
the history of the set indicated by ROW will be limited to 100 time units. tutorial [E3.01] chapter 3 - 50 -
PROSIM
PROSIM BV
3.5.4. History of Continuous Attribute

The history of a continuous attribute (not of its derivatives) is automatically stored as pointstream, involving both its discrete and continuous behaviour. When specifying the differential equation for a continuous attribute, the SPECIFY statement can contain the facility HORIZON(aexp) , where aexp (arithmetic expression) denotes the limitation of the history of that attribute. If aexp = -1 the history will not be limited. The pointstream, containing that history, also keeps the first derivatives during integration intervals. The VALUE function (fully discussed in chapter 4) will return the value of the attribute, as it was at the moment specified by the argument. It uses third order interpolation, in case that moment belongs to an integration interval and returns the discrete value otherwise. The next paragraph demonstrates how the VALUE function can be used to model delays in a dynamic control model. Just like the history of a set, the history of a continuous attribute can be attached to a window, offering run time graphics facilities. The history of a continuous attribute can be attached to a distribution. As discussed in paragraph 4, samples from all kinds of continuous distribution can be easily obtained in this way. Such an attachment is special, because it involves a copy of the history which is inverted. Therefore, the pointstream must keep a non-decreasing function like a distribution function should be.
3.5.5. The Drunken Drivers Problem

The way a driver drives a car to keep it in the middle of a road can be very complex or may even be unknown. We will model the driver's behaviour as follows: At each moment in time the driver is steering his car towards an imaginary point in the middle of the road about 10 meters ahead. In other words: the driver is constantly determining the angle between the direction of the car and the X-axis of the XOY plane in which the whole model is represented. The value of that angle alters continuously. If the driver is sober, he will almost immediately undertake actions at the steering wheel to guarantee that the direction his car actually takes with respect to the X-axis is equal to that angle. But if the driver is under the influence of alcohol, some time, say DELAYTIME, will elapse before he actually reacts to what he observes. So the value of PHI (the actual direction of his car) at any moment equals the observed angle DELAYTIME time units before. In the model, the pointstream ROAD refers to, contains the shape of the middle of the road as a continuous function. The following screen dumps show how the model is composed.
PROSIM
tutorial
[E3.01]
chapter 3 - 51 -
PROSIM BV
Reading the case file, the pointstream ROAD refers to is filled, the attribute Z_MAX holds the ending point of the road (The car needs that to stop its process). The function PHI returns the value of the observed angle at it was DELAYED time units before CT (simulation time as a continuous variable). The next screen dump shows how that function uses the history of the continuous attributes X and Y of the car.
The last screen dump shows the module MAINMOD containing the remainder of the process description of MAIN. MAIN uses the pointstream COURSE refers to, to create a pointstream of the function Y of the car versus X of the car. Because that is the function we want to be shown in the window.
3.6.
Random number generation
3.6.1. Introduction
Random numbers are generated according to Lehmers method, guaranteeing all random numbers are taken from a cycle with length 231 -2 ( >109 ) of 32 bit long integers. Each integer from 1 to 231 -2 appears just once somewhere in the cycle. Each number in the cycle can be obtained as a function of its predecessor. Therefore any number in the range 1 to 231 -2 can be used as a starting point for a series of random numbers forming part of the cycle, without any chance of repetition. This starting number is called the seed of a series of random numbers.
NOTES:
If no seed is specified by the user, PROSIM will use 16807 as the seed of the first distribution, 16808 for the second one, etc. If a seed is specified as a real number PROSIM will convert it to a long integer number. A seed must not be zero.
In practice, we are not interested in random numbers being integers in the range 1 to 231 -2. We want those numbers representing random samples from some distribution function. Therefore PROSIM offers the distribution concept as demonstrated in the previous chapter. tutorial [E3.01] chapter 3 - 52 -
PROSIM
PROSIM BV
Let for instance UNIF be defined as an attribute of type REFERENCE TO DISTRIBUTION. The statement:
UNIF
NEW DISTRIBUTION
creates a distribution function that is shaped uniformly over the interval (0,1). The statement:
SEED OF UNIF
207689
will attach a seed to this distribution, causing the function SAMPLE FROM UNIF to start a series of random numbers according to that seed. If after 1000 samples the statement
SEED OF UNIF
207689
is repeated, the next 1000 samples from UNIF will be equal to the previous 1000. With the ATTACH statement the shape of a distribution can be altered.
3.6.2. Sampling from discrete distributions

Chapter 2 contains an example of sampling from a discrete distribution. In model TRNSPRT we used it to generate the destination of crates. The towns were joined to a set in the order of their cumulative probabilities.
Figure 4 The method explained below can be used as an alternative in cases where efficiency is important. The problem of sampling from discrete distributions can always be reduced to the roundabout problem (see Figure 4). A car coming from the South will go to: direction 1 with a 20% probability direction 2 with a 10% probability direction 3 with a 40% probability direction 4 with a 30% probability As all probabilities are given as multiples of 10, an array SELECT[10] will be defined (as an attribute of MAIN for instance). This array will be filled with: 20% 1nes which means 2 entries are filled with 1 10% twos which means 1 entry is filled with 2 40% threes which means 4 entries are filled with 3 30% fours which means 3 entries are filled with 4
PROSIM
tutorial
[E3.01]
chapter 3 - 53 -
PROSIM BV
So, SELECT contains the vector 1,1,2,3,3,3,3,4,4,4. The direction of the car will be found by:
DIRECTION
SELECT[CEIL(10*SAMPLE FROM UNIF)]
(UNIF as specified above). If the percentages had been given as multiples of 5, select would have been defined with 20 elements, each element representing 5%. The way of sampling from special discrete distributions is always obtained directly by the meaning of such a distribution. For instance, a sample from a binomial distribution can be reduced to the question how many successes will be obtained by trying something with a probability P, n times:
SUCCESS FOR I END
0 TO N
SUCCESS
SUCCESS
>
SAMPLE FROM UNIF
3.6.3. Sampling from continuous distributions

With the ATTACH statement the more frequently used density functions can be attached to a distribution as described in section 3.5.4. In the remaining cases the most general method of sampling from a continuous distribution is used. In theory, this is very easily formulated: for each sample just calculate F-1 (rand) where rand denotes a random number (uniformly distributed over (0,1)), and F-1 denotes the inverse of the desired cumulative distribution function. In practice, this inverse cumulative distribution function is generally unknown. Therefore we have to generate that function with simple models as shown in the next examples. 3.6.3.1. The gamma distribution The gamma distribution concerns the interval [0, ). It has two parameters: and r. Its mean = r/; its variance = r/ 2 This distribution is known as the ERLANG distribution when r is an integer > 1 and will be the EXPONENTIAL distribution if r = 1 In the second screen dump below, we see how the function GAMMASHAPE is composed. The first screen dump shows how the continuous attribute CUM is integrated. The history of CUM will hold the cumulative function of GAMMASHAPE. After integration the value of CUM will approximately be the constant r/. Because the integral of a density function ought to be 1, the density function of the gamma distribution should be GAMMASHAPE divided by that constant. However, we do not have to bother about constants. At the moment the history of CUM is attached to a distribution, the inverse of the function, kept in that history, is created and will be normalised with the last value stored in the history.
PROSIM
tutorial
[E3.01]
chapter 3 - 54 -
PROSIM BV
The model where the gamma distribution must be used, will contain statements like:
GAMMA
NEW DISTRIBUTION
SEED OF GAMMA READ FROM CASE ATTACH F_NAME TO GAMMA
assuming F_NAME contains the name of the file with the history obtained from the model CONT_DIST as shown above. The ATTACH statement is special when it is used with a distribution, because not the filed pointstream is attached but a copy holding the inverse of the function kept in the filed pointstream. 3.6.3.2. The beta distribution The beta distribution concerns the interval [0, 1]. It has two parameters: r and s. Its mean = r/(r + s); its variance = rs/(r + s)2 (r + s + 1) This distribution is frequently used in stochastic network planning; describing activity durations that are asymmetrical distributed over a finite interval. The values 3-2 for r and 3+2 for s are favourites. Samples can be transformed into other intervals afterwards. In the second screen dump below, we see how the function BETASHAPE is composed. The first screen dump shows how the continuous attribute CUM is integrated. The history of CUM will hold the cumulative function of BETASHAPE. The values for r and s are normally greater than 1, otherwise the shape of the distribution will be abnormal for modelling purposes. Even values of r and s that are close to 0 or 1 can cause troubles like strange local behaviour, because derivatives can become extremely big. After integration the value of CUM will approximately be the constant (r,s). Remember: at the moment the history of CUM is attached to a distribution, the inverse of the function, kept in that history, is created and will be normalised with the last value stored in the history.
PROSIM
tutorial
[E3.01]
chapter 3 - 55 -
PROSIM BV
The following screen dumps show how in model CONT_DIST2 the function BETASHAPE is integrated and the history of the integration is kept in a file. That file is used in a similar way as described above for the gamma distribution.
3.6.3.3. Distribution from observations In paragraph 3.5.2 is described how model TRAFFIC_DATA creates a file containing a pointstream. That pointstream keeps the observations about the numbers of cars per minute passing a road profile. That file can be attached again to a pointstream in another traffic model. Depending on the level of aggregation needed in that model, the pointstream will be used directly indicating a continuous traffic flow or as a source of information to generate individual cars starting from that profile (lower aggregation level). Here we are interested in the latter case. So, we want to generate cars over a time interval in which the density of the arrivals fluctuates. Mostly, that interval concerns a peak period; for instance between 7 and 10 on Wednesday morning (in minutes the interval between 420 and 600). Although, situations like this occur frequently in practice, most students have troubles modelling that generation process properly. Probably, because cars can not be generated in order of arrival without loosing control over the variance in the number of cars being created. Let us start with the assumption that we want to simulate the observed situation as close as possible. We will relax that assumption afterwards. Observing the screen dump of model CONT_DIST3, it will be clear that a part of the contents of a filed pointstream is integrated over a time interval of 3 hours. That pointstream is supposed to contain one of the traffic densities as discussed above. The history of CUM obviously contains the cumulated density function over that period. It is stored in the file pointed out by SHAPE.PNT.
PROSIM
tutorial
[E3.01]
chapter 3 - 56 -
PROSIM BV
In this model as well as in the next one the data folder chosen in the model options as default is set to TRAFFIC_DATA. So, the three models have a common data area, allowing the easiest way of file addressing. The following screen dump shows the generation of the cars of the traffic model under construction. Due to the common data area the file SHAPE.PNT equals the file created in the previous model. N_CARS gets the value 1123, being the value of CUM as a result of integration in the previous model. The generator starts with the creation of all cars, without taking any simulation time, giving each one a STARTINGTIME obtained by samples from the observed distribution. Then, the generator releases the cars one by one at the moments they are supposed to pass the profile. The number of cars that are generated matches exactly the number that was observed that Wednesday morning. We only used the observed density distribution to attach arrival times to each car. Be aware that the measurements say nothing about the distribution of the number of cars passing the profile some Wednesday morning.
If we want to use the same observed distribution with a random number of cars; we first have to measure that number over similar time intervals several Wednesday mornings. That will be the only honest way to find its mean and variance. It is reasonable assuming that number to be normally distributed. So, we start with a sample from that distribution,
PROSIM
tutorial
[E3.01]
chapter 3 - 57 -
PROSIM BV
obtaining a value for N_CARS. We should realise that about 95% of the cars be the same every Wednesday morning, causing the variance in N_CARS has nothing to do with (pseudo) Poisson processes or what so ever.
3.6.4. Predefined density functions

The ATTACH statement can attach the following predefined density functions to a distribution: UNIFORM, EXPONENTIAL, NORMAL or UNKNOWN 3.6.4.1.
UNIFORM
Random numbers that are uniformly distributed between a lower bound A and an upper bound B can be obtained by attaching the density function UNIFORM to an attribute of type REFERENCE TO DISTRIBUTION:
ATTACH UNIFORM(A, B) TO UNIF
3.6.4.2.
EXPONENTIAL
The exponential distribution is mostly used to model a Poisson arrival process, because the inter-arrival times of such a process are exponentially distributed. Therefore a Poisson arrival process is modelled by a generator that waits an exponentially distributed amount of time between successive generations. The distribution, EXPON refers to, obtains the exponential density function by:
ATTACH EXPONENTIAL(MN) TO EXPON
3.6.4.3.
NORMAL
There are several sophisticated ways of sampling from a normal distribution. For reasons of efficiency PROSIM samples normally distributed numbers from a standard normal distribution table. The domain of this table is the interval (-3.1, 3.1). With
ATTACH NORMAL(0,1) TO NORM
the density function normal is attached to the distribution pointed out by NORM. If r is a sample from this standard distribution, it can be transformed to be a sample of the normal distribution with mean m and deviation d by the formula: m + d * r. This information is useful for finding out whether a normal distribution will produce negative numbers or not. Example: A repair time is assumed to be normally distributed with mean 6 and deviation 2 hours. The range of that number is the interval 6 + (-6.2,6.2) = (-0.2,12.2). So negative repair times may occur, which will of course lead to runtime errors. Decreasing the deviation or selecting another distribution will cure this problem. Throwing away not wanted sampling results is the worst thing you can do. 3.6.4.4.
UNKNOWN
For any random process 3 parameters can easily be found: The lower bound, mostly caused by technical constraints; the mean, which is very easily calculated and the deviation, which is fairly easily calculated. Generally, the investigation needed to find the most likely distribution function to model a random process is rather expensive. In practice, there is little need for such an investigation, because most simulations are carried out to discover first order effects such as mean production times, mean delay times, efficiency, etc. From the waiting line theory it is known that these first order effects depend mainly on the mean and deviation of the random process. The average waiting time in a single server situation with a Poisson arrival process depends on the mean serving time and its deviation, and is independent of the shape of the distribution of serving times. In more complicated cases the influence of the deviation even decreases. So do not undertake an expensive investigation to find the most likely distribution function if there is no need for it, just use the distribution UNKNOWN instead. When attaching UNKNOWN to a distribution with lower bound 5 mean 8 and deviation 2
ATTACH UNKNOWN(5,8,2) TO SOME_DIST
PROSIM
tutorial
[E3.01]
chapter 3 - 58 -
PROSIM BV
tries to find a density function with a domain that is as small as possible according to the parameters. A small domain is favourable because fewer samples are needed to obtain an accurate estimate of the mean and deviation.
PROSIM
PROSIM
tutorial
[E3.01]
chapter 3 - 59 -
PROSIM BV
4. Combined discrete/continuous modeling

4.1. Introduction
It is rather queer that combined modelling is still an issue. If we only use models to study details of real world systems, it will be possible to define subsystems that can be modelled either continuously or discretely. Nowadays we use models to control systems or to predict the behaviour of a system as a whole. So, continuous as well as discrete aspects should be regarded and in future modelling just will mean combined modelling. Futurists even predict that a time will come where the modeller does not need to care whether an attribute changes discretely in time or continuously. May be software systems like that will come to existence, however, loosing generality and verification possibilities. For the time being PROSIM will not bend to that direction: the PROSIM user must still realise which aspects are continuous and which are discrete, starting with meaning of NOW and CT. indicates the simulation time as a discrete variable whose value only changes at the occurrence of time events. Therefore:
NOW WAIT WHILE NOW
<
128.5
makes the current component suspended waiting for a time event with an eventtime 128.5. In models without time events NOW has no meaning. However, one integration over a previous known fixed interval is enough to introduce an eventtime which makes the model combined. The statement:
WAIT WHILE CT
<
128.5 WITH ACCURACY 0.0003
makes the current component suspended waiting for a continuous state event, being the end of an interval not greater than 0.0003 in which the value of the expression CT < 128.5 changes from TRUE into FALSE. (If you got the impression that you learned something new here, please go back to the hot bars in chapter 2.) A model without integrating components makes CT meaningless unless CT is used explicitly. These examples of state events show the use of NOW and use of NOW and/or CT is hidden.
WAIT WHILE ROW IS EMPTY CT
directly. In most state events the
is a hidden use of NOW, so it is a discrete state event.

WAIT WHILE TEMPERATURE OF OVEN
<
400
is a discrete state event if TEMPERATURE is not a continuous attribute; it makes the current component suspended waiting for the event that some component assigns a value 400 to TEMPERATURE OF OVEN. It is a continuous state event if TEMPERATURE is a continuous attribute of OVEN and OVEN is integrating causing the occurrence of that state event. A component can only enter the integrating state if it has at least one continuous attribute and a differential equation is specified for each one. So, integration implies numerical integration of differential equations. All other continuous aspects are expressions or functions directly depending on CT. The concepts discussed in this paragraph are most relevant for understanding the rest of this chapter.
4.2.
Continuous attribute handling
Let Y be a continuous attribute of a component the attribute CMP refers to. Y OF CMP can be handled like any attribute of the type REAL. If no differential equation has been attached to Y OF CMP, the component CMP refers to is not allowed to enter the integrating state and that is all there is to tell. If a differential equation is attached to Y execution of a statement like:
SPECIFY Y OF CMP PRECEPT(Y'' PROSIM OF CMP,
there is a much more to discuss. Due to the
aexp) ABSERROR(aerr) RELERROR(rerr)
tutorial
[E3.01]
chapter 4 - 60 -
PROSIM BV
where aexp denotes some arithmetical expression, one continuous attribute Y' is added to the component (two, in case the order of the differential equation would be three; and so on). Just like Y, Y' can be handled like an attribute of type REAL. There even exists a Y''. However, Y'' is not an attribute; it just represents the expression given as aexp. So, when the statement:
A
Y''
OF CMP
is invoked, A will obtain the result of the evaluation of aexp, regardless whether the component CMP refers to is integrating or not. Note that aexp normally is a function of CT; directly or indirectly. Consequentially, the statement:
Y'' OF CMP
is erroneous. Furthermore, if all continuous attributes of the component CMP refers to, have been supplied with a differential equation, that component is allowed to enter the integrating state. If so, the differential equations attached to its continuous attributes are joined to the set of integrating differential equations of other integrating components. The optional specifications ABSERROR and RELERROR have to do with the accuracy of the integration mechanism. The default values for ABSERROR and RELERROR are both 0.001. The integration method guarantees that the values of Y and Y' will differ no more than
ABSERROR
RELERROR
ABS(calculated value)
from the exact value over each time unit. The SPECIFY statement can be repeated during the simulation, specifying other differential equations for Y OF CMP, even with different order. So, during the simulation higher order continuous attributes can be created or removed from a component. However, Y OF CMP will always be there; so it makes sense to keep the history of it. During integration Y OF CMP will have a first derivative that will be kept too in the history of Y OF CMP, allowing third order interpolation over integration intervals afterwards. The history concerns the discrete as well as the continuous behaviour of Y OF CMP.
4.3.
VALUE
of history
Due to the concept of numerical integration, history of continuous attributes is created automatically. So, keeping the history of a continuous attribute is not a matter of more effort. On the contrary, not keeping the history implies the effort of throwing old values away. If HORIZON(aexp) is added to a continuous attribute specification, it is guaranteed that values, of the attribute specified, not older than the result of aexp be kept. But not the other way round! The PROSIM RUNTIME SYSTEM is not obliged to keep the history as short as it can be. Even short as it can be will not be zero during integration periods. So, the use of HORIZON may reduce the memory occupation, but makes really sense when the history of a continuous attribute is attached to something or be listed. Let again Y be an attribute of the component CMP refers to and let the SPECIFY statement be
SPECIFY Y OF CMP PRECEPT(Y''
aexp) HORIZON(100)
Consider the statement:

A
VALUE OF Y OF CMP AT(T)
If the value of T is inside the past 100 time units, A will obtain the value Y as it was at time T respecting the state (integrating or not) of CMP at T. If the value of T is outside the history period A will obtain the nearest value kept. However, the history period may be longer than 100 but only shorter if the component CMP refers to did not exist 100 time units ago. Then the next statement:
B
VALUE OF Y' OF CMP AT(T)
The history option only applies for Y, so not for Y'. There may be some history but you can never be sure about is. Therefore, the value of B will have something to do with Y' but that is
PROSIM
tutorial
[E3.01]
chapter 4 - 61 -
PROSIM BV
all you know. With a statement like B Y', you are sure that B gets the most recent value of Y'. Remains the statement:
C C gets
VALUE OF Y'' OF CMP AT(T)
the result of the evaluation of aexp when CT is set to T (only during the evaluation). Has that result anything to do with history? May be, may be not. May be, at time T another differential equation was attached to Y. Or, a more devilish, aexp uses the value of another continuous attribute with a horizon shorter then T. In other cases it indeed will be history, even unrestricted history, because evaluating an expression has nothing to do with the restriction of the100 time units in the SPECIFY statement nor with the state of CMP at time T. As shown in the drunken driver example the first facility opens the way for modelling dynamic control systems. Possibly, you wonder why PROSIM offers the last two facilities. It is not a matter of offering. The PROSIM RUNTIME SYSTEM needs both facilities when integrating a set of differential equations. Those facilities are just there. Should they be disabled for the users? If you feel unhappy with them, dont use them. However, the last one can make things easier. In paragraph 3.6.3.1 we introduced the function GAMMASHAPE because the formula was needed more times in the model. With the third facility the use of the function GAMMASHAPE can be avoided at all as shown in the next screen dump.
There are no other continues attribute used in the differential equation and the equation is not overruled by another specify. Thus, VALUE OF CUM' AT(T) returns the same value as it did before, during the integration of CUM. It is up to you, what kind of modelling you prefer.
4.4.
Accuracy of continuous state events
Aspects concerning the accuracy of continuous state events have already been mentioned in section 2.8. Before the PROSIM RUNTIME SYSTEM is able to calculate the accuracy of the occurrence of a state event, it needs an integration step in which that event occurs at all. In the example of the hot bars that could not cause any problem. The bar is inside an oven where its temperature increases steadily. So, the integration comes automatically to a step with TEMPERATURE < 800 at the start and TEMPERATURE > 800 at the end. Unfortunately, there are more nasty situations. If two ships are sailing the sea (XOY-plane) and both have continuous attributes X and Y denoting their positions, is it easy to introduce a function DISTANCE that at any moment returns the distance between both ships. Suppose we want to figure out if the ships will collide. An attempt to detect a collision with a statement like WAIT UNTIL DISTANCE < EPS will most probably fail detecting a collision. The probability of failure will increase with smaller values for EPS. DISTANCE always returns a positive value. A small EPS will make it unlikely that there will ever be an integration step with DISTANCE > EPS at one side and DISTANCE < EPS at the other side. So, this detection should be done in another way. In the next example we deal with the matter in an easier situation where one of the objects does not move. Afterwards we continue this discussion.
PROSIM
tutorial
[E3.01]
chapter 4 - 62 -
PROSIM BV
Figure 5 Example: There is a very juicy looking apple hanging from the branch of an apple tree and a boy would like to eat it. Because the boy has been forbidden to climb trees, he tries to force the apple down by hitting it with his ball. Supposing, the boy is unlikely to miss it in the y direction only an XOZ plane has to be considered. The boy stands at position (0,0), the apple hangs at position (2,3). The boy throws his ball at an angle ALPHA and a speed SPEED from a height of 1.60 m. The screen dump below shows the simulation of an attempt hitting the apple
After the boy has thrown the ball, he follows it to find out whether a hit has been made or not. This is modelled by the statements:
WAIT WHILE X < 2 WITH ACCURACY 0.02 CANCEL BALL IF ABS(Z - 3) < 0.2
. . .
END
These statements show the correct way to perform the test, because it is sure that X is smaller than 2 at the beginning of the throw and will become greater than 2 after a few seconds. Thus the integration mechanism will always create an interval starting with X<2 being TRUE and ending with X<2 being FALSE, as starting interval for an iterative process finding the state event within an interval smaller than 0.02.
PROSIM
tutorial
[E3.01]
chapter 4 - 63 -
PROSIM BV
The difference with the ships situation is that in case of the boy and the ball the occurrence of the state event X<2 is end of story in determining whether there is hit or not. If both ships are sailing in straight lines, a similar way of testing will be sufficient too. But when the ships are moving in curves, we must introduce a watcher that at the start finds out that, for instance, X OF SHIP1 > X OF SHIP2. Waits while that condition is true, than tests whether there is a hit or not. If not, waits WHILE X OF SHIP1 < X OF SHIP2, etceteras. The watcher must be cancelled as soon one of the ships emerges from the XOY plane.
4.5.
The method of finite elements

PROSIM
When solving partial differential equations, finite elements.
is very suited for using the method of
Elements are modelled as a class of components. Each component can have one or more continuous attributes. The differential equations attached to those attributes can be different for each component, solving nasty problems about borders. The concept of references takes care for the description of the network of relations (borders) between those components. The use of sets can be helpful in cases where that network is linear. Furthermore, components need only to be in the integrating state during the time they take part in the movements to be simulated. And last but not least, discrete actions can be modelled discrete, eliminating time consuming detection of discontinuities during integration. The following example will demonstrate some aspects.
THE COFFEE POT PROBLEM
Some problems are rather famous in the field of simulation. Such is the problem of the percolator coffee pot, as it is used to compare several so-called continuous simulation languages. (F.P.M. Sopers & M.A. de Bruijn; Society for Computer Simulation USER1 conference proceedings 1988.) When the liquid in the reservoir is heated until it is just below boiling, the liquid will be pushed up rather regularly by the damp pressure. It is supposed to be uniformly distributed over the coffee bed, before it passes the bed taking up coffee extract as long as its coffee concentration CR is lower than the saturated concentration CS. CR depends on the coffee concentration in the coffee bed and the fraction of the powder in the bed that is not extracted yet. Those variables are ruled by partial differential equations, which will be simplified to be ordinary differential equations using finite elements. Therefore the coffee bed is divided in layers as shown in Figure 6. Each layer is supposed to be thin enough to neglect differences in extraction and concentration according to height. Due to some more assumptions about homogeneity in the bed the model can be described rather easily. In terms of PROSIM finite elements are modelled as class components. In this case the layers will be described by a class LAYER. Each layer has two continuous attributes: C denoting its coffee concentration E denoting its fraction of not yet extracted powder. The coffee bed itself is modelled by a set containing the layers. Besides those class components the model needs two single components: RESERVOIR with continuous attribute CR denoting the concentration of coffee in the reservoir LIQUID following the discrete percolator process.
PROSIM
tutorial
[E3.01]
chapter 4 - 64 -
PROSIM BV
Figure 6 The attribute START of LIQUID keeps the moment that the last push up started in its percolator process. CF1 to CF4 are coefficients used in the various differential equations. The screen dump below shows how MAIN initialises the model. MAIN creates the N layers and takes care for the specifications of their continuous attributes. The differential equation describing the powder extraction is equal for each layer. The extraction rate is proportional to the fraction of not yet extracted powder, where the proportional factor depends on the concentration of coffee in that layer. (The extraction stops when the concentration becomes saturated.) So, E' -CF1*(CS - C)*E The increment of the coffee concentration C in a layer is the sum of: what is coming from above and what is gained by extraction. The part gained by extraction will be CF3*(CS - C)*E. The part coming from above depends on the value of FLOW and the coffee concentration of the supplier above, which is either another layer or the reservoir. Therefore, the differential equation of C of the top layer differs from that of the other layers.
The concentration CR of the reservoir increases with a rate that is proportional to the difference between the concentration of the last layer and CR itself. The value of the proportional factor depends on FLOW. So,
CR'
(C OF LAST OF COFFEE_BED
CR)*CF4*FLOW
The value of FLOW remains constant during the time there is no push up. During a push up that value is increased by the top half' of a sinus function as shown in the next screen dump.
PROSIM
tutorial
[E3.01]
chapter 4 - 65 -
PROSIM BV
The process descriptions of the various components are so simple that they are gathered into module MAINMOD:
Every time a pulse starts and ends, there is a discontinuity in the set of differential equations. The discrete process of the liquid causes the integration system to stop and go again at those discrete event times, preventing those discontinuities to occur during integration steps. If not, the run time will increase considerably. The integration method has to guarantee the accuracy specified by the user, causing many adjustments of the step size when finding those discontinuities itself. The next screen dump shows the result of the run graphically. This only makes fun if the graphs of all concentration are shown in one picture. The way to produce a picture like this is discussed in chapter 5.
4.6.
Repeated use of SPECIFY
Discrete activities causing discontinuities in a set of differential equations are not rare in combined modelling. The worst discontinuity we can think of is a replacement of entire differential equations including the order. Such can happen at the moment a rocket lanced from a submarine passes the surface of the sea.
PROSIM
tutorial
[E3.01]
chapter 4 - 66 -
PROSIM BV
The next example does not go that far. At the moment a fire-engine starts extinguishing a fire, the differential equation describing the size of the fire will be totally different, but the order remains the same.
THE FIRE STATION
A small town has one fire station with N engines. Fire alarms are raised randomly throughout the town according to exponentially distributed time intervals. Each burning house has a certain amount of inflammable material. Once this is completely burned up the fire will stop but the house will be totally destroyed. By the time it is noticed that a house is on fire, the fire has already reached a certain size, which will increase at a rate proportional to its size, as long as no extinguishing activity is started. When the alarm is raised, the fire-chief will send an engine (if available) to the fire. When the fire-engine reaches the fire and discovers that its capacity is less than the rate of increase in the size of the fire, it will send another alarm message to get assistance.
MODELLING CONSIDERATIONS
Firstly, the modeller has to decide what will be meant by a house on fire in the model. Usually, there will be houses separate from fires. If both houses and fires are represented as classes in the model, the model will be able to handle fires, which spread from house to house. In which case the question arises: under what circumstances will a fire spread? This depends on whether a house stands alone or is one of a block of houses. If it looks reasonable that the fire brigade will at least be able to prevent fires spreading from block to block, then a house can be considered as an object that stands apart from others. This object can then be either a house standing alone or a block of houses. Therefore there is no strong reason to model objects and fires apart from each other. So, each component of the class FIRE is supposed to be an aggregate of an object and a fire together. The GENERATOR will create each FIRE. This means that the model will consist of the following components: The single component GENERATOR that creates houses on fire. The class of components FIRE The single component FIRE_CHIEF controlling the fire-engines. The class of components FIRE_ENGINE A class of components MESSAGE. A message concerns a fire. It will be created by a fire at the moment it is detected and by an engine when more capacity is needed. The most relevant attributes are those of FIRE: SIZE The size of the fire in terms of the rate it causes damage C The factor denoting the flammability of the house involved; 0 means: does not burn at all, 1 means: burns like hell DAMAGE The integral of SIZE MATERIAL The amount of inflammable material in the house TRAVEL_TIME The time an engine needs to reach the fire ON_FIRE An indicator to show that the fire is still burning DETECTION The time the fire burns unperceived N_SERVERS Number of engines attending to put off the fire During the time that there is no fire-engine present to extinguish the flames, the fire will increase in size according to the differential equation:
SIZE'
C*SIZE
As soon as the first engine starts to extinguish the fire the increase of the size (SIZE') is under control and assumed to be constant. Thus the further life of the fire will be governed by quite another differential equation, e.g.:
SIZE'
RATE
(1-C)*CAPACITY*N_SERVERS
PROSIM
tutorial
[E3.01]
chapter 4 - 67 -
PROSIM BV
where RATE equals SIZE' at the moment the first engine arrives and CAPACITY denotes the extinguish capacity of an engine. Engines are supposed to have the same capacity. The process description of MAIN is straightforward and needs no further comments. It is shown in the screen dump below.
The process description of the generator contains the SPECIFY statement for the size of a fire when it is expanding without restrictions. Note that the detection of the fire is DETECTION minutes later. A fire is so kind to produce an alarm by itself in the model at detection time.
PROSIM
tutorial
[E3.01]
chapter 4 - 68 -
PROSIM BV
The process description of a fire is straightforward too. The correction in the statement that totals the damages is needed because the damage can eventually be greater then 100% when the house is burned completely before the fire has been detected. It is assumed that the chief knows in some way that the fire involved is still burning at the moment he activates an engine. If a FIRE_ENGINE is the first one that arrives at the fire, it changes the continuous behaviour of the size of that fire. The attribute RATE of a fire is needed to keep the expansion rate of the size at the moment of arrival of the first engine. Remember that SIZE', being the highest order, is evaluated according to the current differential equation specified.
4.7.
Tracing components
When components are tracing each other continuously, it means that the position and/or direction of one component are coefficients in the differential equations of continuous attributes of other ones. Does this make things worse? Not at all, even in contrary: finding discrete state events mostly becomes easier. The next example will demonstrate this item.
THE FOUR DOGS
At each corner of a square lawn of 100 m2 , there is a dog facing another dog in the next corner in a clockwise direction. At time zero each dog starts to chase after the one in front of it. This will result in the trajectory traces given in the figure below.
PROSIM
tutorial
[E3.01]
chapter 4 - 69 -
PROSIM BV
The simulation model is straightforward:
The origin of the XOY-plane covering the lawn is at the bottom left of the lawn as can be figured out from the way MAIN arrange the dogs in the corners of the lawn. Each dog has a reference PREV, pointing out the dog to be traced. Those references connect the dogs clockwise in a circular way. In the process description of a dog, we notice that each dog takes care for the specification of its own continuous attributes. MAIN could have done that as part of the initialisation. However a dog is a living creature with its own will. The specifications of X and Y are more than just physical descriptions; they also specify the target the dog likes to chase. Note that the cosine function is not used in the differential equations avoiding nasty sign problems. A dog stops chasing when the continuous state event condition DIST > 1 becomes FALSE. This is correct modelling because the centre of the lawn will be reached asymptotically, which is a consequence of the tracing aspect.
DIST
is a function that calculates the distance from THIS
DOG
to its target.
PROSIM
tutorial
[E3.01]
chapter 4 - 70 -
PROSIM BV
The dogs look so nice, chasing each other. In reality, however, the dogs are devilish creatures. The dogs know that there is a rabbit in the middle of the lawn. They also know that their behaviour will confuse the rabbit. All the time the rabbit waits before it runs away, the dogs come closer, increasing the possibility to catch the rabbit. Knowing the rabbit will panic at some time; the dogs are not integrating They are integrating UNTIL RABBIT IS ACTIVE.
WHILE DIST
>
1.
With the help of information in the case file, MAIN activates the rabbit at the moment it panics and runs away in some direction with some speed. The replaced state event in: INTEGRATE UNTIL RABBIT IS ACTIVE, is not a continuous state event; so we have not to worry about the accuracy of the time it occurs. At the moment the rabbit starts running, each dog changes its differential equations to chase the rabbit, which is much more fun than chasing each other. Each dog will integrate its X and Y again until it catches the rabbit. If not, the dog will be cancelled; either by the rabbit when it escapes in the groves surrounding the lawn or by the dog that caught the rabbit. The state event describing a catch is a continuous one. There are dogs and a rabbit, moving in a plane. Does that mean we have to deal with the nasty situation of the two ships as described in 4.4? No, we dont! The test: while distance (to the rabbit) > 0.5, is save. A dog can never jump over the rabbit, because its differential equations describe that it first should turn 1800 . Assuming that the integration accuracy has normal values, a turn like that can not be achieved within one integration step. Thus there will never be an integration step with distance (to the rabbit) > 0.5 at both sides hiding a catch between! The difference with the ships (as well as with the apple and the ball) is that these components are not chasing each other. Their differential equations just describe their courses. So the ships are moving independently from each other. The integration mechanism has nothing to do with a collision and can therefore not be helpful in detecting one. The following screen dump shows the process descriptions of the dogs and the rabbit. At the moment the rabbit starts running, the dogs change the differential equations of their continuous X and Y attributes. The function DISTR is added to the model to calculate the distance between THIS DOG and RABBIT.
jumps to the macro CREATE PICTURE to combine the courses of the dogs and rabbit in the picture shown below. The content of that macro is explained in chapter 5. The whole
MAIN
PROSIM
tutorial
[E3.01]
chapter 4 - 71 -
PROSIM BV
picture is based on the ten pointstreams containing the complete history of the continuous behaviour of the model.
PROSIM
tutorial
[E3.01]
chapter 4 - 72 -
PROSIM BV
5. Window control
5.1. Introduction
When someone is working at a computer a question can rise like: Does the windows control the user or does the user control the windows? Well, let it be for what it is. This chapter concerns certainly the latter aspect: it is about the generation of windows and the use of those windows for displaying results graphically, for animation and as (parts of) interfaces. With windows we mean windows like those created by the operating system. As should be known, PROSIM provides the concept WINDOW. If attribute of the type REFERENCE TO WINDOW, the statement
PICTURE PICTURE
is defined as an
NEW WINDOW CALLED
"GRAPH_1"
makes PICTURE refers a WINDOW being a formal representation of something that, according to its system attributes, will appear on the screen as an actual window. One of those system attributes is its name with value "GRAPH_1" that will appear in the title bar of the actual window. Due to a SHOW statement in the model, PROSIM will cause the operating system to cause the appearance of a window on screen. From that moment on the window is in the visible state, whether you can see it or not. The execution of the HIDE statement will cause the termination of that state, which makes sure that you can not see the actual window. The appearance of a window depends on the values of the system attributes of its formal companion WINDOW. Appearance includes aspects such as position, size, and colours of the window itself and then we can start bothering about everything that should be in it. Just this is the heart of the matter. Which attributes should always be specified, which ones never (be fixed) and what to do with the large grey area between? One thing is certain: there will always be changes in this area. It is no way to come out with a new version of the compiler every time something has to be changed in that grey area. So at the level of specifying WOBS (Window OBjects) use is made of system functions instead of statements that must be compiled. A system function has a name that starts with an underscore _, making the names specific, because the user can not create such names. However, we dont start with WOBS in this chapter; we start as easy as possible: no specifications at all. That will be the quick and dirty solution for a question like show me the graph or histogram of this POINTSTREAM clearly, without bothering about colours or what so ever. For those reasons PROSIM offers the concept of CHART WINDOWS. As a matter of facts, most output windows used in the examples of the previous chapters are CHART WINDOWS. At the moment the SPECIFY statement is used for a WINDOW, specifying a metric for it, that WINDOW becomes a USER WINDOW. From that moment on, the contents of the WINDOW is considered to be a set of WOBS joined to the window. Each WOB represents a special appearance or icon to be shown at a position specified by coordinates in the metric of the WINDOW it belongs to. Therefore, for each type of WOB a position must be specified. The only exception is a WOB of the type graph, because the POINTSTREAM attached to it constitutes a series of positioning data itself.
5.2.
The output window
The output window is a part of both run control windows. It is used for system messages and to show the results of the execution of WRITE statements where no output file is specified. When representing the texts written, the same fixed spaced font is applied as used in the editing part of the modelling window. So, special symbols as for instance (Alt 206) will look alike in both windows. If you direct the write results to some file, you need an editor to inspect the results. The appearance of the result can differ dramatically depending on the font settings of that editor. However, the appearance of texts can be controlled in most cases. Using WOBS causing the appearance of texts in a USER WINDOW (as discussed below) the formatting is almost completely controlled by the operating system. So, big brother is taking over control. A similar story applies to the control over printers.
PROSIM
tutorial
[E3.01]
chapter 5 - 73 -
PROSIM BV
5.3.
Using chart windows
A chart window has no metric. So, everything that appears in the actual window the chart window represents, obeys default attribute settings. A chart window is constructed to show the contents of a pointstream graphically as a graph or as a histogram, depending on the type of pointstream attached. In cases that both possibilities apply, clicking the graph/histogram button makes the choice. Showing a chart window only makes sense after a pointstream has been attached to it. If so, every successive show of the window refreshes the display of the contents of that pointstream as it is at the moment of execution, making visible how the pointstream grows during the run. For other reasons, there is no compelling need to use a SHOW statement. By clicking the chart button in the tool bar of one of the run control windows, selections can be made out of a list of available chart windows to show each one in turn. This way of showing chart windows is recommended in cases that many chart windows are in use. Otherwise they are all displayed over each other, which of course makes no sense. The SHOW statement implies specification of the position of the actual window on screen and the size of it. The statement:
SHOW PICTURE AT(50,100) SIZE(400,300)
causes the actual window connected to the window referred by PICTURE to be visible. The top left corner will be 50 pixels form the left side of the screen and 100 pixels from the top of the screen. It will have a width of 400 pixels and a height of 300 pixels. Attaching a pointstream to a window can be done in several ways. In the next examples the following attribute definitions are assumed:
REFERENCE TO WINDOW REFERENCE TO POINTSTREAM REFERENCE TO SET CONTINUOUS CHARACTER PICTURE P_STRM ROW CONT FILENAME[20]
ATTACH P_STRM TO PICTURE SHOW PICTURE causes the appearance
of a window showing a graph being a polygon connecting the successive points in the pointstream P_STRM refers to. The histogram option is available showing a histogram with N classes of the dependent values, where N MAX(12, CEIL(SQRT(number of entries))).
ATTACH HISTORY OF ROW TO PICTURE SHOW PICTURE causes the appearance of
a window showing a graph being a forward bar chart denoting the number of members in the set as function of the time interval (specified in the HISTORY option of the NEW statement that created the set). The histogram option is available showing a histogram of the waiting times of components that left the set during the HISTORY interval. The number of classes is calculated in a similar way as described above.
ATTACH HISTORY OF CONT TO PICTURE SHOW PICTURE causes the appearance of
a window showing a graph of the history of CONT regarding periods the component, CONT belongs to, was integrating or not. The ending point of each integration step is a point in the history pointstream. For each integration step a point in the middle is added to the graph which value is obtained by means of third order interpolation. The histogram option is disabled.
ATTACH FILENAME TO PICTURE
This attach statement only makes sense if FILENAME indicates a file which contents was created by means of a FILE statement (in any model). That file contains information about the kind of pointstream that is kept in it. According to that information one of the three possibilities described above applies. It is possible to attach more than one pointstream to a chart window. They will be shown in a common set of axes that covers the common range and domain of the streams. In order to
PROSIM
tutorial
[E3.01]
chapter 5 - 74 -
PROSIM BV
distinguish between the different graphs an additional specification can be added to the ATTACH statement: COLOURED clr, to be inserted before the keyword TO, for example:
ATTACH P_STRM COLOURED 12 TO PICTURE
Because the minimum and maximum values displayed along the axes in a chart window are taken from the underlying set of points, they will generally not be very neatly. For that reason a system function is added that gives you the opportunity to overrule those automatic values: _WIN_PREFS(WIN,
XMINPREC, XMAXPREC, YMINPREC, YMAXPREC)
In this function WIN is a REFERENCE TO WINDOW that refers to a chart window; the minimum values are calculated as MINPREC * FLOOR(MINVAL / MINPREC) and the maximum values are calculated as MAXPREC * (FLOOR(MAXVAL / MAXPREC) + 1).
5.4.
User windows
PICTURE,
Obeying the condition that nothing is attached to it, the window referred by becomes a USER WINDOW with the statement:
SPECIFY PICTURE ORIGIN(P
,Q)
UNITS(P_X
,P_Y)
The specification concerns the definition of an XOY metric in the window. The origin is situated in the window at P pixels form the left side of the window and Q pixels from the top of it. P_X denotes the unit length in pixels of the X-axes, P_Y the number of pixels in the unit of the Y-axes. It is just a matter of specification; the axes will not be visible. There is no need that the origin belongs to the part of the window that ever will be visible. It only makes every point in the window addressable, whether it ever will be visible or not. A SHOW statement, as described above, is needed to make a user window visible. Everything that should be made visible as the contents of a user window must be expressed as WOB (window object). A WOB is a language concept like all other concepts. So, each WOB must be created with NEW and a REFERENCE TO WOB attribute is needed to address it. The types of WOBs described in the next paragraph are just the most fundamental ones. The description of these WOBs will be similar to any WOB type that will be added to PROSIM in the future. Addition of a new WOB type is just a matter of joining it to the system library of WOB types. There are two fundamentally different ways in which WOBs are used: a WOB can be used just to paint something in the window, or it can be intended to support interaction between the user and the program. For this reason we distinguish two classes of WOBs: static WOB and dialog WOB respectively. A user window should then be considered to be a rectangular area on screen with a blank interior. That blank area forms the background of the window and all static WOBs are painted on that area in the order they are joined to the window. So the user has fully control over the hiding or overlapping of object in the background. Dialog WOBs are placed in the foreground and actually are child windows in the sense of the operating system.
5.5.
Using WOBs
5.5.1. Introduction
Let OBJECT be defined as an attribute of the type REFERENCE TO WOB. The statement
OBJECT
NEW WOB WOB
causes the creation of a WOB and OBJECT will refer to it. To make a conditions must be fulfilled: the WOB must belong to a window the WOB must be fully specified the window involved must be in the visible state.
visible three
Using the JOIN statement a WOB becomes a member of a window. For instance:
JOIN OBJECT TO PICTURE
A WOB can only belong to one window at the same time. It can be removed from the window it belongs to by the statement:
PROSIM
tutorial
[E3.01]
chapter 5 - 75 -
PROSIM BV
REMOVE OBJECT FROM WINDOW
There can be two reasons to do so: to make it invisible to move it to another window As discussed in 5.1 specifications are added to a WOB by means of system functions. There is a function for each type because each type needs a different number of parameters and not all parameters have corresponding meanings. The various WOB types will be discussed in three sub paragraphs. The return value of a system function specifying a WOB has the following meaning: 0 everything is ok, -1 the WOB references none, -2 the REFERENCE used is not a REFERENCE TO WOB, -n (n > 2) type specific error.
NOTES:
If a WOB is transferred to another window its appearance may change, because that other window can have a different metric. Each time the specification function of a WOB is invoked, while the WOB is visible, the appearance of the WOB will change immediately according to changes of parameter values. In addition to respecifying a WOB just to move it to another location in the same window, two alternative system functions can be used: _MOVE_WOB(wob or _SHIFT_WOB(wob
reference, deltax, deltay) reference, newx, newy)
5.5.2. Conversational aspects

The PROMPT WOB is a static one, all other WOBs in this paragraph are dialog WOBs. 5.5.2.1. PROMPT _WOB_PROMPT (wob reference, x, y, color, text) A prompt is just a text to be shown at a specified position (x, y) in the actual window the WOB belongs to. Example: N _WOB_PROMPT (OBJECT, 3, 4, 1, "I am a PROMPT!") After execution the return value assigned to N is the completion code as specified above. If the window, OBJECT belongs to is visible, the text I am a PROMPT! will appear in the actual window at position (3, 4) according to the metric of that window. That position indicates the upper left corner of the imaginary rectangle surrounding the text. The fourth parameter denotes the colour number modulo 16 (1: indicates dark blue). 5.5.2.2. BUTTON _WOB_BUTTON (OBJECT, X, Y, WIDTH, HEIGHT, FG CLR, BG CLR, CODE, TEXT) In connection with the _WINDOW_RESPONSE function the BUTTON WOB forms the key for conversational applications. The model can provide information to the user with PROMPTs for instance. The user can react on that information by filling up STRINGs or selecting from COMBOs, but only during a response interrupt of the running model. Such an interrupt can be caused in the model by invoking a statement like:
N
_WINDOW_RESPONSE(PICTURE,
TRUE, NONE)
The actual window connected to PICTURE, becomes the active window and the model is interrupted. That window must contain at least one button. If not _WINDOW_RESPONSE acts like a dummy function preventing the interrupt would be forever. The interruption will last until the user clicks one of the buttons in the active window. The model will know which one, because each button has a CODE (of type INTEGER) that will be the return value of _WINDOW_RESPONSE. As already explained, the WOBs in the window are painted in the order they are joined to the window. This is also the order in which the WOBs will receive focus
PROSIM
tutorial
[E3.01]
chapter 5 - 76 -
PROSIM BV
when tabbing thru the window. Consequently the first WOB to receive focus is the first one added to the window. It is possible to override this behaviour by specifying a default WOB; if the third parameter in _WINDOW_RESPONSE refers to a WOB that one will have default focus. An alternative use of _WINDOW_RESPONSE is to check whether the user pressed a outside a conversational period. The statement
N BUTTON
_WINDOW_RESPONSE(PICTURE,
FALSE, NONE) BUTTON
returns 0 if no BUTTON was pressed, otherwise the code of the first last call of _WINDOW_RESPONSE, if any. With the statement
N
pressed after the
_WOB_BUTTON(BACK, 2,
10, 8, 1, 15, 1, 100,"RETURN")
the REFERENCE TO WOB attribute BACK is specified. (2,10) is the position of the top left corner of the BUTTON. The width of the BUTTON is 8 X-units. The height of the BUTTON is 1 Y-unit. The combination 15,1 denotes that the text in the BUTTON is written in white letters in a blue background. The CODE of the button is 100 (being returned by _WINDOW_RESPONSE when the BUTTON is clicked). The text RETURN will appear in the middle of the BUTTON as far as there is room for it. This function has an additional error code: -3 if the BUTTONs CODE value is less than or equal to 0. 5.5.2.3. STRING _WOB_STRING(OBJECT, X, Y, WIDTH, FG CLR, BG CLR, TEXT, MAX CHAR) A STRING WOB enables the user in providing information to the running model. It has the form of a rectangle in which a character string can be updated by the user during an interrupt. After the interrupt, the system function _WOB_STRING_VALUE assigns that string to a one-dimensional CHARACTER attribute. For example:
N
_WOB_STRING_VALUE(STR,<C_ATTR>)
in which C_ATTR is a one-dimensional CHARACTER attribute that will receive the value entered in the STRING WOB. Additional error codes for this function are: -3: the first argument does not refer to a STRING WOB; -4: the STRING WOB is not joined to a window; 5.5.2.4. COMBO _WOB_COMBO(WOB, X, Y, WIDTH, FCLR, BCLR, LISTSTART, ROWUSED, COLUSED) A COMBO WOB enables the user in providing a selection list to the running model. It has the form of a rectangle in which a character string is shown. Pressing the attached arrow shows a list from which an item can be selected. After the interrupt, the system function _WOB_COMBO_INDEX returns the index of the selected item. The list is specified as a 2dimensional CHARACTER attribute. For example: "LINE 1" "LINE 2" LIST[3] "LINE 3" LIST[4] "LINE 4" LIST[5] "LINE 5" N _WOB_COMBO(CMB,2,10,8,1,15,LIST[1],5,6) N _WINDOW_RESPONCE(UWIN, TRUE, NONE) N _WOB_COMBO_INDEX(CMB)
LIST[1] LIST[2]
With the WOBs discussed so far, we gathered enough tools for demonstrating the most basic conversational aspects. Let us reconsider the hotbars problem of chapter 2. The performance of the hotbar system is controlled by the values of three attributes: MN : the mean of the exponential distributed inter arrival times of the bars, MAX_CONTENTS : maximum number of bars in the oven, OVENTEMP : the temperature of the oven.
PROSIM
tutorial
[E3.01]
chapter 5 - 77 -
PROSIM BV
As a part of its initialisation task MAIN just assigns values to these attributes. We are going to improve that. Reading those values from a case file could be an improvement. However, only three values are easier updated in the model than in a case file. The next screen dump shows the first part of the contents of the macro CONVERSATION, jumps to it instead of assigning input values.
MAIN
It may look bulky, but it is just straightforward. The window, CONTROL refers to, is graduated to be a user window by the SPECIFY statement. Now it has a metric and it can accept WOBs. Offering conversation with the user, there must be a BUTTON. Therefore we use the WOB B_OK and make it a BUTTON with the _WOB_BUTTON function. The WOBs STR_MN, STR_MAXN and STR_TEMP are needed for the three STRING WOBs creating positions where the user can update values. Note that the specification function allows default settings for those values. Because the user has the right to know which string box is to be used for what attribute, we need another three WOBs: PRM_MN, PRM_MAXN and PRM_TEMP. The function _WOB_PROMPT specifies these WOBs as PROMPT WOBs. After taking care that all WOBs are joined to CONTROL, the actual companion of CONTROL is displayed with the SHOW statement. The window is displayed, but no conversation so far. The next screen dump shows the remainder of the macro:
The _WINDOW_RESPONSE function interrupts the model and makes the control window active.
PROSIM
tutorial
[E3.01]
chapter 5 - 78 -
PROSIM BV
The model will only resume if the user clicks the BUTTON reading OK, with or without altering values in the string boxes. We are not curious about the return value; it must be 100 because there is only one BUTTON in the window.
NOTE:
With some more effort we can offer the user a screen stuffed with windows containing string boxes and buttons. The user can alter all value of all string boxes. Each change will effect the result of the _WOB_STRING_VALUE of the specified WOB. Furthermore, the user may click any BUTTON, but only the first click on a BUTTON in the window specified in the _WINDOW_RESPONSE function will react. After the OK button is clicked, the string box value is assigned to the character CHAR9 for each string box. Those values should be numerical. However it is not friendly punishing the user with conversion errors for each typing error. So, we need the function NUMERIC_CONTROL that checks the value of char to be numeric. That function is shown in the next screen dump.
5.5.3. Graphics
This WOB is a static one, although its presentation can be rather dynamic. 5.5.3.1. GRAPH _WOB_GRAPH(OBJECT, COLOUR) With the GRAPH WOB, more graphs can be shown in one XOY plane of a user window. All graphs to be displayed in one window must be based on pointstreams. The points of all those pointstreams must be meaningful in that XOY plane. If we want to display the graph of a temperature (varying between 10 and 30 degrees) and the graph of a pressure (varying between 800 and 1200 bars) in one picture, we better do some preparations. From the history of the temperature a new pointstream can be created with values transformed from the range 10 - 30 to the range 0 1. A second pointstream can be constructed from the history of pressure: again in the range 0 1. Pointstreams are attached to GRAPH WOBs just like pointstreams are attached to chart windows. The next example shows how the trajectories of the four dogs are grouped together in one user window Each dog has the continuous attributes X and Y to specify its position at the lawn at time T. Displaying the history of Y, being a time function, is not interesting. Displaying Y as function
PROSIM
tutorial
[E3.01]
chapter 5 - 79 -
PROSIM BV
of X makes fun. Therefore we need an extra pointstream TRACE for each dog. The screen dump of the macro CREATE_PICTURE shows how these pointstreams are filled.
Note that the RANKED option is not used in the STORE statements, because the successive points should not be ranked by X (time has been eliminated). Furthermore, each dog needs a WOB TRAJECT to display its trajectory at the lawn.
5.5.4. Animation
All WOBs in this paragraph are static ones. 5.5.4.1. BITMAP _WOB_BITMAP(WOB REFERENCE, X, Y, FILE_NAME) Using a graphical designer, a windows bitmap (.bmp) must be constructed and be stored in a file. The character string FILE_NAME holds the name of that file and its full address if that file is not kept in the folder specified for data in the options. The X and Y of the position specify the centre of the bitmap (always being a rectangle) according to the metric of the user window. Bitmaps can be used as backgrounds for animations in the first place. Bitmaps can also be used to specify icons to be moved in the user window. Being bitmaps such icons have a fixed size and a fixed colour. So, they can only be translated in the window. However, most video games are based on replacements of series of bitmaps. 5.5.4.2. POLYGON _WOB_POLYGON(OBJECT, COLOUR, CLOSED, FILLED, <POINTS>, N_POINTS) A polygon is a collection of line segments. These segments are specified by the REAL attribute POINTS that must be an array with two columns and at least N_POINTS rows. Each row represents a point (x, y) of the polygon to be connected with a line segment to the next point. If CLOSED = TRUE the last point will be connected with the first one. If FILLED is also TRUE, internal contours will be filled up with the colour specified by argument COLOUR. There is no need that all points are different in the polygon, line segments will not disappear if they are drawn twice or more. If we use a POLYGON WOB to represent an icon, we can make the icon grow or turn according to matrix operation with respect to POINTS. 5.5.4.3. ELLIPSE _WOB_ELLIPSE(OBJECT, X, Y, X_RADIUS, Y_RADIUS, COLOUR, FILLED) The axes of the ellipse are parallel to the sides of the screen and (x, y) denotes the centre of the ellipse. 5.5.4.4. RECTANGLE _WOB_RECT(OBJECT, X1, Y1, X2, Y2, LW, COLOUR, FILLCOLOUR) This is a special case of the POLYGON WOB. (x1, y1) denotes one corner of the rectangle, (x2, y2) the opposite one. The line width is LW pixels and the colour of the rectangle is COLOUR. If FILLCOLOUR < 0 only the border is drawn, otherwise the rectangle is filled.
PROSIM
tutorial
[E3.01]
chapter 5 - 80 -
PROSIM BV
Animation is due to the facility that the appearance of a WOB changes every time the specifying system function is invoked. So, we are able to update a picture during the run of a model showing the status of a system during the simulation. This runtime animation is accurate in showing the order of activities of the systems components. The relation with real time can be set by the user by means of a SYNCHRONIZE statement or the SYNCHRONIZE button in the run window. As promised in chapter 3 we discuss model TROLLEY2, adding animation to model TROLLEY. We will use the picture of the configuration of the trolley system, shown in paragraph 3.4.3, as background for the animation. Because the picture consists completely of ellipses, prompts and polygons, we dont need bitmaps to create it. The next screen dump shows the contents of function CREATE_PICTURE that will do the job.
Creating the picture without bitmaps allows the facility that we can construct the picture directly according the input of the model. This is most important when the goal of the model is the creation of a suitable configuration. The first screen dump shows the part of the function that specifies the main route and the parking. The main route is easier because all data needed are available as the co-ordinates of the nodes that only must be gathered in array COORDS. For the parking we must invent points in the neighbourhood of the entrance node.
PROSIM
tutorial
[E3.01]
chapter 5 - 81 -
PROSIM BV
For each platform we need three WOBs: a POLYGON WOB for the entrance and the exit the ELLIPSE WOB HOME to denote its location a PROMPT WOB to show its name. Now we have a background picture, we proceed with the heart of the matter: the moving trolleys. As icon for a trolley we use a small circle. That is easy, of course, because its shape will do for all directions. Furthermore the colour of the circle will be the colour of the supplier the trolley works for. As shown in CREATE_PICTURE, platforms are supplied with colours for this purpose. However, that is the easiest model extension for animation. The more complex extension concerns the fact that we want to see the trolleys move over the sectors. This is just a matter of show; it has nothing to do with the performance of the model. In contrary it will slow down the simulation considerably! So, each trolley needs co-ordinates to express its position almost continuously. Here we have to make a decision about the way to calculate these values. Should T_X and T_Y really be continuous attributes or not? The position of each trolley must be displayed in steps, allowing the processor to do something else between. So, the answer of the question depends on the amount of statements needed in both cases. If we really consider the question properly we will find out that using continuous attributes is in favour. The problem is that we dont want to rebuild the complete model on behalf of the animation. However, if we do so the most complex part of the model, the short cut macro, can be described more straightforward. Reasonably or not, we follow the discrete way. Therefore we introduce an ANIMATOR in the model as a SINGLE COMPONENT. The animator displays stepwise the position of all moving trolleys, using the function SHOW_TROLLEY as shown below.
PROSIM
tutorial
[E3.01]
chapter 5 - 82 -
PROSIM BV
Each time a trolley is displayed the values of its attributes T_X, T_Y and T_LC must be updated. T_LC (last time calculated) is needed for this calculation. Note that these values are not equal for all trolleys, because at the moments a trolley changes speed this function is used too. The calculation needs the direction in which the trolley moves. This direction is kept in the attributes S_COS and S_SIN of the section the trolley is moving on. The values of these attributes are calculated once as an initialisation task of MAIN. The following screen dumps show the rather trivial process of the animator and the process of a trolley moving on the main route. The macros SHORT_CUT and STATION are updated in a similar way.
PROSIM
tutorial
[E3.01]
chapter 5 - 83 -
PROSIM BV
6. Calendar Data
To facilitate the handling of calendar data an attribute of type DATETIME is supplied. Its value is an encoded representation for any calendar date and time from midnight (00:00:00), January 1, 1970, coordinated universal time (UTC) until midnight (23:59:59), December 31, 3000, UTC. An attribute of type DATETIME cannot be used in arithmetic expressions. Only a comparison between two attributes of type DATETIME is valid. The following functions for manipulating DATETIME values are implemented. In the examples supplied the attributes used are supposed to be defined as follows:
DT1, DT2: DATETIME N: INTEGER S: CHAR[64]
Today Returns the current system date and time. Example:

DT1 TODAY
DateAndTime Returns the encoded representation of a date and time based on user input. Example:
DT1 DATEANDTIME(2005, 5, 23, 11, 45, 56)
RelativeDate Obtains the date that occurs a specified number of days after or before another date. Example:
DT1 DATEANDTIME(2005, 5, 23, 11, 45, 56) DT1 RELATIVEDATE(DT1, 4) @ SAME AS DATEANDTIME(2005, 5, 27, 11, 45, 56) DT1 RELATIVEDATE(DT1, -4) @ SAME AS DATEANDTIME(2005, 5, 19, 11, 45, 56)
RelativeTime Obtains the time that occurs a specified number of seconds after or before another time within a 24-hour period. Example:
DT1 DATEANDTIME(2005, 5, 23, 11, 45, 56) DT1 RELATIVETIME(DT1, 4) @ SAME AS DATEANDTIME(2005, 5, 23, 11, 46, 00) DT1 RELATIVETIME(DT1, -4) @ SAME AS DATEANDTIME(2005, 5, 23, 11, 45, 52)
DaysAfter Gets the number of days one date occurs after another Example:
DT1 DATEANDTIME(2005, 5, 23, 11, 45, 56) DT2 DATEANDTIME(2005, 5, 27, 12, 44, 51) N DAYSAFTER(DT1, DT2) @ RESULT IS 4 N DAYSAFTER(DT2, DT1) @ RESULT IS -4
SecondsAfter Gets the number of seconds one time occurs after another. Example:
DT1 DATEANDTIME(2005, 5, 23, 11, 45, 56) DT2 DATEANDTIME(2005, 5, 27, 11, 46, 51) N SECONDSAFTER(DT1, DT2) @ RESULT IS 55 N SECONDSAFTER(DT2, DT1) @ RESULT IS -55
PROSIM
tutorial
[E3.01]
chapter 6 - 84 -
PROSIM BV
YearOf Gets the year of a DATETIME value. Example:

DT1 DATEANDTIME(2005, 04, 14, 12, 31, 20) N YEAROF(DT1) @ RESULT IS 2005
MonthOf Gets the month of a DATETIME value. Example:

DT1 DATEANDTIME(2005, 04, 14, 12, 31, 20) N MONTHOF(DT1) @ RESULT IS 4
DayOf Gets the day of a DATETIME value Example:

DT1 DATEANDTIME(2005, 04, 14, 12, 31, 20) N DAYOF(DT1) @ RESULT IS 14
HoursOf Gets the hours of a DATETIME value. Example:

DT1 DATEANDTIME(2005, 04, 14, 12, 31, 20) N HOURSOF(DT1) @ RESULT IS 12
MinutesOf Gets the minutes of a DATETIME value. Example:

DT1 DATEANDTIME(2005, 04, 14, 12, 31, 20) N MINUTESOF(DT1) @ RESULT IS 31
SecondsOf Gets the seconds of a DATETIME value. Example:

DT1 DATEANDTIME(2005, 04, 14, 12, 31, 20) N SECONDSOF(DT1) @ RESULT IS 20
WeekOf Gets the year and weeknumber of a DATETIME value. Example:

DT1 DATEANDTIME(2005, 04, 14, 12, 31, 20) N WEEKOF(DT1) @ RESULT IS 200515
DayIndexOf Gets the day of the week of a DATETIME value and returns the number of the weekday. Example:
DT1 DATEANDTIME(2005, 04, 14, 12, 31, 20) N DAYINDEXOF(DT1) @ RESULT IS 4
DayNumberOf Gets the day of the year of a DATETIME value.

PROSIM
tutorial
[E3.01]
chapter 6 - 85 -
PROSIM BV
Example:
DT1 DATEANDTIME(2005, 04, 14, 12, 31, 20) N DAYNUMBEROF(DT1) @ RESULT IS 104
DayNameOf Gets the day of the week of a DATETIME value and returns the name of the weekday. Example:
DT1 DATEANDTIME(2005, 04, 14, 12, 31, 20) S DAYNAMEOF(DT1) @ RESULT IS "THURSDAY"
MonthNameOf Gets the day of the week of a DATETIME value and returns the name of the weekday. Example:
DT1 DATEANDTIME(2005, 04, 14, 12, 31, 20) S MONTHNAMEOF(DT1) @ RESULT IS "APRIL"
DateStringOf Gets the day of the week of a DATETIME value and returns the name of the weekday. Example:
DT1 DATEANDTIME(2005, 04, 14, 12, 31, 20) S DATESTRINGOF(DT1) @ RESULT IS "2005/04/14"
TimeStringOf Gets the day of the week of a DATETIME value and returns the name of the weekday. Example:
DT1 DATEANDTIME(2005, 04, 14, 12, 31, 20) S TIMESTRINGOF(DT1) @ RESULT IS "12:31:20"
In addition to this functions the value of an attribute of type DATETIME can be converted to a string using the syntax:
CONVERT DT1 TO S
The result of this conversion is a character string of exactly 24 characters that has the form "Wed Jan 02 02:03:55 1980".
PROSIM
tutorial
[E3.01]
chapter 6 - 86 -
PROSIM BV
7. Dynamic Link Library Interface

A Dynamic Link Library (DLL) is a library of run-time loaded functions written in a general purpose programming language, for instance C. PROSIM contains an interface for communication with such external functions. For that purpose you should use an attribute of type REFERENCE TO DLL. Once defined the attribute must be instantiated by means of NEW:
DLLREF
NEW DLL
The final preparation of the DLL links the PROSIM model to the DLL:
ATTACH fname TO dllref ENTRYPOINT epname
In this statement fname is a character string or attribute specifying the name of the DLL filename. If it is not fully qualified it is assumed to be located in the current data directory. epname is a character constant or attribute containing the name of the entry point in the DLL. The prototype of this function reads:
long epname(long option, long datatype, void * const data, long count, long *dims)
When the DLL is successfully attached to the REFERENCE TO DLL attribute communication with the DLL is established by the INVOKE statement. The syntax of this statement reads:
INVOKE dllref OPTION(aexp) RETURNCODE(la)
[USING(ua)]
in which dllref denotes the REFERENCE TO DLL attribute aexp is evaluated to a long value that should be used to identify the type of action that is requested from the entry point function of the DLL; it corresponds to the prototype argument option. la denotes a user attribute of type LONG that will receive the return value of the call to the entry point ua denotes a single or multiple user attribute of type INTEGER, LONG, LOGICAL, REAL or CHARACTER that can be used to transfer data from the PROSIM model to the DLL or vice versa. It is an optional element in the statement. If present, the storage location of the attribute corresponds to the prototype argument data, number of subscript is passed in count, the upper bound of each dimension is passed in dims and the type of the attribute is passed in datatype. Possible values for that are: 0 no USING present 1 INTEGER (16 bits integer) 2 LONG (32 bits integer) 3 LOGICAL (16 bits integer) 4 REAL (64 bits floating point value) 5 CHARACTER (8 bits characters)
PROSIM
tutorial
[E3.01]
chapter 7 - 87 -
PROSIM BV
Appendix A
Compiler Messages
01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36
PROSIM
Incomplete statement Improper item in expression: item Unbalanced brackets Invalid reference to pointstream Illegal order for attribute: attribute Missing queue/set specification for: clause Misplaced "IN" found Improper qualified: attribute Undefined identifier: name Unexpected subscript for: item Missing subscript for: item Improper qualifier for: attribute Misplaced qualifier: attribute No class correspondence for qualifier of: attribute Missing classname Missing or invalid datastream Improper use of "BELONG" Improper use of "IS" Improper use of "EMPTY" Improper use of "ACTIVE" Misplaced keyword: keyword Operand missing Unbalanced string quotes Expression too complex Invalid operand in expression Invalid item in function to be exported: item Unbalanced parenthesis Argument list missing for: function Invalid subscript list Subscript out of range Keyword "IN" not found Improper FIRST, LAST or EACH clause Improper condition Invalid queue/set specification Missing (reference to) component Missing or invalid distribution tutorial [E3.01] Appendix A - 88 -
PROSIM BV
37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 63 64 65 66 68 69 73 79 80 81 83 84 85 86 87 88
PROSIM
Invalid left-hand side Invalid type of right-hand side Invalid label: label Duplicate label: label Invalid statement Misplaced statement Statement cannot be conditional Unexpected end of source file Extra characters on line Invalid syntax Invalid module name: module Invalid transfer Left-hand side must be derivative Invalid COLOUR expression Invalid type of item in output list Missing format expression Invalid format list Invalid format expression Invalid component expression Invalid type of expression Unbalanced item/format list Improper set of parameters Invalid reference to DLL Entry point specification missing Undefined label: label Unsupported use of "NEW" Missing or invalid "PRECEPT" Previous statement contains invalid transfer to label Invalid type of argument Improper argument list Invalid value for FIELDLENGTH Invalid BY NAME argument: argument Misplaced continuous state event in discrete model Unbalanced braces Statement too complex Unexpected argument list for: function Errors generated Improper expression Unqualified system attribute Keyword TO not found tutorial [E3.01] Appendix A - 89 -
PROSIM BV
89 90 91 92
Missing source expression Keyword FIELDLENGTH not found Missing or invalid target expression No errors found
Runtime Messages
00 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33
PROSIM
End of simulation NONE cannot be joined to set component cannot be joined to NONE cref belongs not to sref cref already belongs to sref NONE cannot be removed from set component cannot be removed from NONE Error attaching DLL System attribute of component referencing NONE System attribute of set referencing NONE MEANWT for set sref without history Entry point in DLL not found set is NONE in FIRST/LAST/EACH-clause Dll handle referencing NONE Negative delay interval NONE cannot be activated cref not waiting for a time event cref already active cref has no activation point NONE cannot be cancelled cref is not active cref is current Negative time interval cref has no continuous attributes cref has a non-specified continuous attribute Strange local behaviour during integration No equation specified Order out of range Dll handle not attached Attach to NONE Attribute of NONE used Qualifier does not address class cls Invalid assignment to THIS of class cls Mean smaller than lower bound tutorial [E3.01] Appendix A - 90 -
PROSIM BV
34 35 36 37 38 39 40 41 42 51 52 53 54 55 56 57 60 61 62 63 64 65 66 67 68 69 70 71 73 75 80 81 82 83 84 85 86 87 88 89
PROSIM
Improper DATETIME value Pointstream referencing NONE Pointstream is empty Cannot attach NONE Attaching wrong type of pointstream History not produced by integration Decreasing distribution function Seed of NONE Distribution referencing NONE Floating point error: invalid operation Floating point error: denormalized operand Floating point error: zero divide Floating point error: overflow Floating point error: underflow Floating point error: precision Floating point error Improper argument for ARCCOS Improper argument for ARCSIN Improper argument for SQRT Error converting string to numeric Error converting string to logical Error converting string to macro No file attached to datastream Invalid type of file operation Error opening file File already open or in use Reference to function references NONE Datastream references NONE File not open Invalid number of parameters NONE cannot be joined to window Window references NONE Window is Chart window Wob belongs already to a window NONE cannot be removed from window Wob not in window Invalid subscript Conversion error NONE used as qualifier Improper argument for LOG tutorial [E3.01] Appendix A - 91 -
PROSIM BV
90 91 92
Unexpected end of Module/Macro/Function Invalid character comparison Improper type of argument arg
PROSIM
tutorial
[E3.01]
Appendix A - 92 -
PROSIM BV
Index
A
Abserror Accuracy Activate Activation point Active After Animation Arrivaltime Attach Attribute Character Continuous Macro Real Reference Reference to DATASTREAM Reference to DISTRIBUTION Reference to DLL Reference to SET Reference to WINDOW Reference to WOB System 61 28, 60, 61, 62, 66, 71 10, 29, 30, 32, 40, 41 10, 12, 16, 30 30, 33 32 44, 46, 73, 80, 82 33 9 1, 2, 29, 33 77 20, 28, 49, 51, 60, 82 34, 44 60 3 9 19, 53 87 17 16, 73 75 11, 14, 29, 33, 40, 73
B
Background Before Belongs 75, 80, 81 32 33
C
Calendar data Called Cancel Class of components Clause Each First Last Close Component Class Class Class Current Current Current Current Data Single
PROSIM
84 18 27, 30, 40, 41 2, 7 41 40 40 37 1, 2, 4, 7, 14, 29, 32, 33, 69 3, 7, 8, 16, 27, 40 41 64 29, 30, 31 14 41 60 3, 30 3, 8, 27 [E3.01] index - 93 -
tutorial
PROSIM BV
Continuous Distribution State event State event

CT
CT Current Component Component Component
i, 2, 20, 52, 60, 64 55 25 62 52 60, 62 13, 14, 32 29 14 41
D
Data component DateAndTime DateStringOf Datetime DayIndexOf DayNameOf DayNumberOf DayOf DaysAfter Definition section Delay Distribution Beta Continuous Discrete Exponential From observations Function Gamma Normal Uniform Unknown Dynamic Link Library Dynamic section 3, 30 84 86 84 85 86 85 85 84 3, 5, 23, 34, 41, 43, 44 30 19, 25, 51 56 55 53 58 56 19 55 58 58 59 87 3, 4
E
Each clause Empty Event Continuous state State Time Eventtime 41 11, 33 31, 33 25, 60, 62, 70 11, 27, 29, 60 11, 27, 29, 60 11, 20, 29, 33
F
First Clause For Each Loop Function
PROSIM
12, 14, 15, 33 40 41 18 38 39, 41, 42, 48 [E3.01] index - 94 -
tutorial
PROSIM BV
Arithmetical Built in Density External Goniometrical Mathematical Runtime loaded System
39 39 58 43 39 39 87 73
G
Graph Greatest 50, 73, 74, 79 40
H
History Continuous attribute Set Value of Hold Horizon HoursOf 56, 61, 74 20, 51 13, 33, 50 61 12, 31 50, 51, 61 85
I
Image Input Integrate Integrating Interpolation Is 36 9, 36 21, 27, 41, 42 21, 29, 61 28, 49, 51, 61, 74 34
J
Join Jump 10, 20, 37, 40, 41, 75 41, 42
L
Label Last Clause Local 10, 12, 30, 41 15, 33 40 42, 43
M
Macro Attribute Main Mainmod Mean MinutesOf Modelling
PROSIM
41, 43, 47 See Attribute 4, 8 4, 8 33 85 1, 4 [E3.01] index - 95 -
tutorial
PROSIM BV
Module File MonthNameOf MonthOf
4, 16 5 86 85
N
New Now Number Blanks Characters Digits Dimensions Pixels Random Serial Spaces 7, 9, 18 8, 60 2 35 38 35 43 75 53 33 36
P
Parameter By name By value Passivate Passive Poisson Arrival Process Precept Process Control Description 42 43 42 31 17, 29, 31 58 26, 31, 58 26 3 29, 30 3
R
Random number Ranked Reactivate Read Reference Relation RelativeDate RelativeTime Relerror Remove Return Rewind 19, 53, 58 37, 40 17, 29, 30, 32, 40, 41 8, 36, 38 See Attribute 3 84 84 61 12, 20, 40, 41 43 36
S
Sample Sampling Scheduling of activities SecondsAfter SecondsOf
PROSIM
19, 53, 54 53, 55 32 84 85 [E3.01] index - 96 -
tutorial
PROSIM BV
Seed Selection Clause Set Reference Show Simulation Smallest Specify Continuous attribute Window State Active Current Indicator Integrating Passive Suspended Suspended Window Store System attribute
53 14 14, 33, 40 10, 13 See Attribute 13 1 40 20, 66 73, 75 3, 29, 33 30 29 11 29 29 14, 17, 29 11 73 49, 50 See Attribute
T
Terminate
THIS
Time unit TimeStringOf Today
8, 30, 41, 42 13, 26, 40, 41 28, 34 86 84
V
Value of History 50 61
W
Wait WeekOf Window Size Work Write 8, 11, 12, 27, 31, 41, 42 85 13, 50, 51, 73 13, 74 12, 31, 41 36, 73
Y
YearOf 85
PROSIM
tutorial
[E3.01]
index - 97 -

Prosim PDF

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Prosim PDF

Uploaded by

Copyright:

Available Formats

PROSIM BV

simulation - optimization - software - consultancy

PROSIM MODELLING LANGUAGE TUTORIAL

On the subject of modeling....................................................................... 1

Basic concepts of the language................................................................. 7

Facilities of the language ........................................................................ 29

Combined discrete/continuous modeling................................................. 60

Calendar Data ........................................................................................ 84 Dynamic Link Library Interface.............................................................. 87

On the subject of modeling

Components and attributes

Activity and process descriptions

FIRST MACHINE IN IDLE_MACHINES

Now, an assignment like:

Structure of a PROSIM model

Using that item causes the option window to

2. Basic concepts of the language

TYPE OF NEXT_ORDER NEXT_ARRT END TERMINATE

READ FROM LIST

READ FROM LIST

READ FROM LIST

) the source (Check

READ FROM LIST

is used to chapter 2 -9-

We modify our model to look like:

The N_MACHINE model

The process description of a machine in PROSIM terms is:

it will find the set to be

and HOLD are synonyms to make the statements more expressive.

READ FROM CASE

FOR I 1 TO N ACTIVATE NEW MACHINE FROM START END

after TYPE, if TYPE is not is used unqualified.

FIRST ORDER IN ORDERLIST WITH TYPE FIRST OF ORDERLIST IF JOB IS NONE

which actually means:

PREV_TYPE OF THIS MACHINE. ORDER

Add the statement:

statement and run the

as an attribute of MAIN. The statement:

READ FROM CASE

DEV READ FROM CASE ATTACH NORMAL(MN, DEV) TO DRIVE_TIME

denotes the first derivative of change. Generally:

in our case, the speed with which

input rate minus output rate

The behaviour of HISTORY OF LEVEL.

as a function of the simulation time is automatically kept as the

More about sets

The next screen dump shows how harbours:

reads the data configuring the towns and the

Then MAIN creates the firms with their trucks:

100 * SAMPLE FROM RAND

FIRST TOWN IN TOWNS[3-SIDE] WITH PERCENTAGE > H

Continuous state events

3. Facilities of the language

Process control facilities

3.2.1. States of a component

3.2.2. Process control statements

only affects the component GENERATOR, while the statement

CANCELL ALL TERMINATE

Be aware that the statement:

EVENTTIME OF MACHINE CANCEL

NOW CANCEL MACHINE

must be executed before the EVENTTIME of the machine!

3.2.3. Scheduling of activities

3.2.4. System attributes of components and sets