NETWORKT.MOD

From Support

Jump to: navigation, search

Back to Model Library

See also: How to read .MOD pages

Contents

Description

NETWORKT.MOD models a jobshop with MAXG groups of different types of machines and identify each machine group with a particular value of the index, G. This jobshop will process three types of jobs. Each type of job will have a different routing and a different processing time. We will indicate the type of job with the index, TYPE. In this system, the resident entities are the machines and queues associated with each machine group. The transient entities are the jobs flowing through the system. Job processing times are modeled here with an Erlang distribution with different means depending on machine group and job type involved. See the Functions section for more information.

NETWORK1.MOD and NETWORKR.MOD also model similar jobshop systems.

State Variables

State Variables in NETWORKT.MOD
Variable Name Abbreviation Variable Description Size Type
QUEUE Q[G] Number of jobs waiting for each group 6 Integer
SERVERS S[G] Number of idle machines in each group 6 Integer
MAXG MAXG Maximum number of machine groups in model 1 Integer
G G Index identifying a machine group 1 Integer
TYPE TYPE Index for job type 5 Integer
TASK TASK Index for task number 1 Integer
MTIME MTIME Mean processing times by job and task 3,6 Real
ROUTE ROUTE Machine routes by job type and task number 3,6 Integer
ARIV ARIV Total processing time for a job 1 Real
R R Random index to determine job type 1 Real
ENT ENT Buffer for putting job attributes in queues 15 Real
RNK RNK Ranking entity attribute for each queue 25 Integer
DELAY DELAY Total time in the system for a job 1 Real

Vertices

Vertices in NETWORKT.MOD
Vertex Name Vertex Description State Changes
RUN Start of the run MAXG=DISK{ROUTES.DAT;0}
INPUT Reading of routing and timing data ROUTE[TYPE;TASK]=DISK{ROUTES.DAT;0}, MTIME[TYPE;TASK]=DISK{MTIMES.DAT;0}
ENTER Arrival of a new job, determines the job type R=RND, TYPE=(R>.3)+(R>.8)
NEXTG Next machine on the route G=ROUTE[TYPE;TASK]
LEAVE Job leaving the shop DELAY=CLK-ARIV
START Start of this task at this machine group S[G]=S[G]-1
NEXTQ Selection of the next job in the queue Q[G]=Q[G]-GET{FST;G}
FINISH Finish of this task at this machine group S[G]=S[G]+1, TASK=TASK+1
JOINQ Job joining a queue for a machine group Q[G]=Q[G]+PUT{FIF;G}

Initialization Conditions

Initialization Conditions in NETWORKT.MOD
Variable Description
SERVERS[G] Number of idle machines in each group

Event Relationship Graph

Please open SIGMA for the event relationship graph.

NETWORKT.MOD as seen in SIGMA
NETWORKT.MOD as seen in SIGMA

English Translation

An English translation is a verbal description of a model, automatically generated by SIGMA.

The SIGMA Model, NETWORKT.MOD, is a discrete event simulation. 
It models A NETWORK OF QUEUES WITH TRANSIENT ENTITIES.
I. STATE VARIABLE DEFINITIONS.
For this simulation, the following state variables are defined:
MAXG: MAXIMUM NUMBER OF MACHINE GROUPS IN MODEL   (integer valued)
G: INDEX IDENTIFYING A MACHINE GROUP   (integer valued)
S[6]: NUMBER OF IDLE MACHINES IN EACH GROUP   (integer valued)
Q[6]: NUMBER OF JOBS WAITING FOR EACH GROUP   (integer valued)
TYPE: INDEX FOR JOB TYPE   (integer valued)
TASK: INDEX FOR TASK NUMBER   (integer valued)
MTIME[3,6]: MEAN PROCESSING TIMES BY JOB AND TASK  (real valued)
ROUTE[3,6]: MACHINE ROUTES BY JOB TYPE AND TASK NUMBER   (integer valued)
ARIV: TOTAL PROCESSING TIME FOR A JOB  (real valued)
R: RANDOM INDEX TO DETERMINE JOB TYPE  (real valued)
ENT[15]: BUFFER FOR PUTTING JOB ATTRIBUTES IN QUEUES   (real valued)
RNK[25]: RANKING ENTITY ATTRIBUTE FOR EACH QUEUE   (integer valued)
DELAY: TOTAL TIME IN THE SYSTEM FOR A JOB  (real valued)
II. EVENT DEFINITIONS.
Simulation state changes are represented by event vertices (nodes or balls) in a SIGMA graph.  
Event vertex parameters, if any, are given in parentheses. Logical and dynamic relationships 
between pairs of events are represented in a SIGMA graph by edges (arrows) between event vertices.  
Unless otherwise stated, vertex execution priorities, to break time ties, are equal to 5.
1. The RUN(S[0],S[1],S[2],S[3],S[4]) event occurs when START OF THE RUN.
   Initial values for, S[0],S[1],S[2],S[3],S[4], are needed for each run.
   This event causes the following state change(s):
   MAXG=DISK{ROUTES.DAT;0}
   After every occurrence of the RUN event:
   Unconditionally, READ THE INPUT DATA;
   that is, schedule the INPUT(TYPE,TASK) event to occur without delay...
   using the parameter value(s) of 0,0.
2. The INPUT(TYPE,TASK) event occurs when READING OF ROUTING AND TIMING DATA.
   This event causes the following state change(s):
   ROUTE[TYPE;TASK]=DISK{ROUTES.DAT;0}
   MTIME[TYPE;TASK]=DISK{MTIMES.DAT;0}
   After every occurrence of the INPUT event:
   If TYPE<=2 and TASK<MAXG, then INCREMENT THE TASK NUMBER, CONTINUE READING INPUT;
   that is, schedule the INPUT(TYPE,TASK) event to occur without delay...
   using the parameter value(s) of TYPE,TASK+1.
   If TYPE<2 and TASK==MAXG, then INCREMENT THE JOB TYPE AND CONTINUE READING ;
   that is, schedule the INPUT(TYPE,TASK) event to occur without delay...
   using the parameter value(s) of TYPE+1,0.
   (Time ties are broken by an execution priority of 4.)
   If TYPE>=2 and TASK>=MAXG, then INPUT HAS BEEN READ AND THE FIRST JOB ENTERS;
   that is, schedule the ENTER() event to occur without delay.
3. The ENTER() event occurs when ARRIVAL OF A NEW JOB, DETERMINES THE JOB TYPE.
   This event causes the following state change(s):
   R=RND
   TYPE=(R>.3)+(R>.8)
   After every occurrence of the ENTER event:
   Unconditionally, SCHEDULE THE NEXT JOB ARRIVAL;
   that is, schedule the ENTER() event to occur in 0.25*ERL{1} time units.
   Unconditionally, DETERMINE NEXT MACHINE GROUP FOR THE JOB;
   that is, schedule the NEXTG(TYPE,TASK,ARIV) event to occur without delay...
   using the parameter value(s) of TYPE,0,CLK.
4. The NEXTG(TYPE,TASK,ARIV) event occurs when NEXT MACHINE GROUP ON THE ROUTE.
   This event causes the following state change(s):
   G=ROUTE[TYPE;TASK]
   After every occurrence of the NEXTG event:
   If G==MAXG, then THE JOB IS FINISHED AND CAN LEAVE THE SHOP;
   that is, schedule the LEAVE(TYPE,ARIV) event to occur without delay...
   using the parameter value(s) of TYPE,ARIV.
   (Time ties are broken by an execution priority of 2.)
   If G<MAXG and S[G]<=0, then THE JOB IS NOT DONE, BUT NO MACHINES ARE IDLE;
   that is, schedule the JOINQ(G,ENT[4],ENT[5],ENT[6]) event to occur without delay...
   using the parameter value(s) of G,TYPE,TASK,ARIV.
   (Time ties are broken by an execution priority of 2.)
   If G<MAXG and S[G]>0, then THE JOB IS NOT DONE AND A MACHINE IS AVAILABLE;
   that is, schedule the START(G,TYPE,TASK,ARIV) event to occur without delay...
   using the parameter value(s) of G,TYPE,TASK,ARIV.
5. The START(G,TYPE,TASK,ARIV) event occurs when START OF THIS TASK AT THIS MACHINE GROUP.
   This event causes the following state change(s):
   S[G]=S[G]-1
   After every occurrence of the START event:
   Unconditionally, START THE TASK WITH A MACHINE FROM GROUP G;
   that is, schedule the FINSH(G,TYPE,TASK,ARIV) event 
   to occur in MTIME[TYPE;TASK]*ERL{2} time units...
   using the parameter value(s) of G,TYPE,TASK,ARIV.
   (Time ties are broken by an execution priority of 4.)
6. The FINSH(G,TYPE,TASK,ARIV) event occurs when FINISH OF THIS TASK AT THIS MACHINE GROUP.
   This event causes the following state change(s):
   S[G]=S[G]+1
   TASK=TASK+1
   After every occurrence of the FINSH event:
   Unconditionally, DETERMINE THE NEXT MACHINE GROUP FOR THE JOB;
   that is, schedule the NEXTG(TYPE,TASK,ARIV) event to occur without delay...
   using the parameter value(s) of TYPE,TASK,ARIV.
   If Q[G]>0, then THE QUEUE IS NOT EMPTY, SELECT THE NEXT JOB;
   that is, schedule the NEXTQ(G) event to occur without delay...
   using the parameter value(s) of G.
   (Time ties are broken by an execution priority of 3.)
7. The JOINQ(G,ENT[4],ENT[5],ENT[6]) event occurs when JOB JOINING A QUEUE FOR A MACHINE GROUP.
   This event causes the following state change(s):
   Q[G]=Q[G]+PUT{FIF;G}
   No additional events are scheduled here.
8. The NEXTQ(G) event occurs when SELECTION OF THE NEXT JOB IN THE QUEUE.
   This event causes the following state change(s):
   Q[G]=Q[G]-GET{FST;G}
   After every occurrence of the NEXTQ event:
   Unconditionally, START PROCESSING THE JOB;
   that is, schedule the START(G,TYPE,TASK,ARIV) event to occur without delay...
   using the parameter value(s) of G,ENT[4],ENT[5],ENT[6].
   (Time ties are broken by an execution priority of 3.)
9. The LEAVE(TYPE,ARIV) event occurs when JOB LEAVING THE SHOP.
   This event causes the following state change(s):
   DELAY=CLK-ARIV
   No additional events are scheduled here.

Comments

If there were only one type of job in the system, we could get by with a model that includes only resident entities (the queues and machines). For each machine group, all machines are identical; therefore, we only need to keep track of the number of jobs waiting and the number of machines that are idle. Pure resident entity models tend to be much faster and easier to understand than models that include transient entities. We can model a single job type easily (see FLOWSHOP.MOD). When there are multiple types of jobs, we still would not have to introduce transient entities into our jobshop model, but this involves some fancy bookkeeping beyond our current purpose of illustrating the use of priority queues. For model flexibility and efficiency, it is good practice to avoid using transient entities as long as possible; this can be done here by not drawing unnecessary distinctions between the jobs, just keep counts of the jobs in different states.




Back to top

Back to Model Library

Personal tools
Navigation