constructs for the development computer simulation
TRANSCRIPT
Constructs for the Development of a
Computer Simulation Language for
Bulk Material Transportation Systems
by
Bevlee A. Watford
Thesis submitted to the Faculty of the
Virginia Polytechnic Institute and State University
in partial fulfillment of the requirements for the degree of
MASTER OF SCIENCE
in
INDUSTRIAL ENGINEERING AND OPERATIONS RESEARCH
APPROVED:
Timothy J. Greene,Chairman
Robert P. Davis Aubrey E. Harvey
October, 1983 Blacksburg, Virginia
CONSTRUCTS FOR THE DEVELOPMENT OF A SIMULATION LANGUAGE FOR
BULK MATERIAL TRANSPORTATION SYSTEMS
by
Bevlee A. Watford
(ABSTRACT)
The overall objective of this research is the
development of a set of guidelines, or constructs, which
will assist in the formulation of a simulation language for
bulk material transportation systems. The formulation of
these guidelines necessitated a thorough analysis of two
particular areas; these being the simulation analysis
procedure and bulk material transportation systems. For
comprehension of the nature of simulation languages, Part II
presents each step of the analysis procedure as examined
from the language's perspective. Supporting this analysis,
Part III presents a detailed review of selected simulation
languages which are currently available to the systems
analyst.
Bulk material transportation systems are presented in
Part IV. These systems are discussed in detail from the
viewpoint of the mode of transportation, the transportation
medium, and the type of bulk materials transported.
The functional specifications, or constructs, for a
bulk material transportation simulation language are
presented in Part V. These specifications are categorized
according to the following areas; the system being
described, the language form, and computer considerations.
Utilizing these constructs a simulation language may be
developed for subsequent use by bulk material transportation
systems analysts which shall be a more appropriate choice
for simulating their systems than any language currently
available to them.
ACKNOWLEDGEMENTS
The author would like to thank Dr. Timothy J. Greene who,
in addition to being a major advisor, also provided an
extraordinary amount of support and guidance throughout this
masters program. Additional thanks are extended to Dr.
Robert P. Davis and Dr. Aubrey E. Harvey for their inputs
and assistance.
GLOSSARY
Activity - An operation or collection of operations which
act on the state of an entity, altering attribute values
thereby causing a change in the system.
Attribute - A characteristic or property of an entity.
Computer Language - Any language capable of being used to
write programs for computer interpretation.
Entity - Any real world object within the boundaries of a
system, the representation of any physical object in a
system model.
Event - The occurrence of a change in system state at an
isolated point in time reflecting decisions which are
made to start or end activities.
Macro A single statement within a computer program
representing a group of statements which will be executed
when the macro statement is encountered.
Model - A representation and/or set of transformation rules
which can be used to predict the behavior and
relationships between the set of entities composing the
system.
Modeling - The process of developing a model.
Process - A time ordered sequence of events which may
encompass several activities.
V
Simulation - The design and subsequent manipulation of a
computerized model of a system.
Simulation Clock - A mechanism for monitoring the passage of
time during the execution of a simulation program, · may
also be referred to as a simulation timing mechanism.
Simulation Language - A specific type of computer language
designed for use in the translation of a simuiation model
into a computer program.
Simulation Model - A specific type of model which has been
formulated for subsequent translation into a simulation
program for evaluation.
Simulation Program - A representation of a simulation model,
written in a computer language, and of a form amenable to
computer evaluation.
State of an entity - The instantaneous value ( s) of the
attribute(s) of an entity define its state.
System State The description of all entities, their
attributes, and activities of a system as they exist at
some point in time.
System - A collection of real world objects which, through
the occurrence of events and activities, act and interact
toge~her toward the accomplishment of some logical end.
vi
TABLE OF CONTENTS
ABSTRACT
ACKNOWLEDGEMENTS
GLOSSARY
PART I INTRODUCTION
Chapter
l.
2.
3.
4.
5.
INTRODUCTION TO SIMULATION ANALYSIS
BULK MATERIAL TRANSPORTATION SYSTEMS
PROBLEM DEVELOPMENT
RESEARCH OBJECTIVES
THESIS OUTLINE ...
PART II THE SIMULATION ANALYSIS PROCESS
Chapter
6.
7.
SIMULATION ANALYSIS
Advantages and Disadvantages of Simulation Analysis ....... .
Procedural Steps ...... . The Role of Simulation Languages
MODEL FORMULATION
Model Classifications Iconic, Analog, and Symbolic Models Static and Dynamic Models ....
Fixed Increment Time Advancement Next Event Time Advancement ...
Stochastic and Deterministic Models Discrete Models
Activity Scanning Event Scheduling
vii
iv
V
2
4
9
11
13
. 16
17 19 21
24
24 27 28 29 29 30 32 33 34
8.
9.
Process Interaction. Continuous Models
Block Form Models and Languages Expression Form Models and Languages
Combined Discrete/Continuous Models Concurrent Time Operation. Model Data Base Interaction. Control Flow Initiation Interaction Structural Interaction
Simulation Model Classifications Analog Simulation Models . Digital Simulation Models Hybrid Simulation Models
MODEL TRANSLATION
Computer Languages Simulation Languages
Design of Simulation Languages Programming Support. Language Portability Program Portability. Additional Considerations
Selection of a Language
MODEL VALIDATION AND PROGRAM VERIFICATION
Validation and Verification .. The Role of the Simulation Language
Model Validation .. Program Verification
10. PROGRAM EXPERIMENTATION
11. INTERPRETATION AND APPLICATION OF RESULTS
PART II I LANGUAGE REVIEWS
Chapter
12. LANGUAGE REVIEWS ..
Partial Differential Equation Languages Simulation Programs CSMP III DEMOS . DISCO . DYNAMO
viii
34 36 37 37 38 40 41 42 42 43 44 45 45
50
50 54 56 58 58 59 59 60
63
64 65 65 67
69
71
73
73 74 76 78 79 80
GASP IV. GPSS GSL ... REPLICAS SIMAN . . SIMSCRIPT II. 5 SIMULA SLAM SMOOTH Summary
PART IV BULK MATERIAL TRANSPORTATION SYSTEMS
Chapter
13. BULK MATERIAL TRANSPORTATION SYSTEMS
14. BULK MATERIALS ...... .
15. RAIL TRANSPORTATION SYSTEMS
16. INLAND WATER TRANSPORTATION SYSTEMS
17. OCEAN TRANSPORTATION SYSTEMS ....
18. INLAND WATER TRANSPORTATION SYSTEMS
19. OCEAN TRANSPORTATION SYSTEMS ..
20. PIPELINE TRANSPORTATION SYSTEMS
21. CONVEYOR TRANSPORTATION SYSTEMS
22. HIGHWAY TRANSPORTATION SYSTEMS
23. CONCLUSIONS
81 83 84 86 87 89 91 92 94 95
. 99
103
108
112
115
118
121
124
127
129
131
PART V SIMULATION LANGUAGE FUNCTIONAL SPECIFICATIONS
ix
Chapter
24. SYSTEM DESCRIPTION. 136
Random Number Generation 138 Random Variate Generation 142 Discrete, Continuous, or Combined Orientation 144
Discrete Orientation . 147 Continuous Perspectives 148
Continuous System Equations 149 Numerical Integration 150
Timing Mechanism 153
25. LANGUAGE FORM CONSIDERATIONS
Language Level Modular Construction Output Report Generation
26. COMPUTER CONSIDERATIONS
Data Structuring Documentation Debugging
27. SUMMARY
28. FUTURE DEVELOPMENT PLANS
BIBLIOGRAPHY
VITA. ••••• . . ' . . . . . . . . . . . . . . . . . . . . . . . .
X
155
156 158 159
164
165 166 167
170
171
174
182
LIST OF TABLES
Table
1. Transportation Facts and Figures •.•...•.....•.•.•.............•.•... 5
2. Advantages and Disadvantages of Simulation Analysis ................ 18
3. Advantages and Disadvantages of Contimlous Analog Simulation ....... 46
4. Advantages and Disadvantages of Digital Simulation ................. 47
5. Advantages and Disadvantages of Hybrid Simulation .................. 49
6. Advantages and Disadvantages of Simulation Languages .•.......•..... 57
7. 0:msiderations for Simulation Language Selection •.................. 62
8. lmi.gtla.ge OJrrlt:,arisons •.•.•.•.•... o ••••• o •••••••••••••••••••••••••••• 96
9. Examples of Bulk Solids and Their Properties .•.................... J.05
10. Examples of N:>n-bulk Solid Materials ...•.•.•.•...........•........ 107
11. System Parameter c.omparisons ...•...•.•...•...•.....•...•.......•.. 132
12. Statistical Tests for Randan Nunber Generators •...•.•.•...•...•... 140
13. Theoretical Probability Distributions .............•.•............. 145
14. Systan Etltities . ................................................. . 146
15. Output Report Te:rnis •...•.•...•.•...•.......•...•...........•...... 162
16. Output Report Types •.•...•.....•.•.•.....•.•.•.•.•.•.•.•.•...•...• 163
xi
LIST OF FIGURES
Figure
1. Hierarchy of Simulation Languages .•.•.•...•...•...•.....•........ 51
2 . Coal Sys tan Schana. tic • . • . • . . . . . . . . . • . . . . . . . . . . . • . • . • . . . . . • . . . . . .160
3. Future Develoµnent Plans .....•...........•.....•.•.............• 17 2
xii
PART I
INTRODUCTION
1
Chapter 1
INTRODUCTION TO SIMULATION ANALYSIS
A complex system's management and behavior control is a
topic of continuing research. This research has led to the
development of numerous methodologies and skills
facilitating the interactions which occur between the system
and the analyst. These interactions arise from the need of
the analyst to model the system in order to 1) observe the
system to understand its behavior, and 2) to manipulate the
system for examination of alternate forms of operation or
control [ 77 l .
Formulating a system model
conditions which inhibit
is generally required due to
real world examination or
experimen'tation, such as cost or inability to isolate the
system. Further, it may be desired to model a system which
either cannot be translated into a mathematical form
amenable to analytical or numerical solution techniques, or
which presents an infeasible problem to be solved after
translation [43]. These difficulties often arise from the
interactions required of model entities, or from the
excessive model size. The increasing usage of the computer
for system's analysis has opened new perspectives into the
solution of such problems.
Simulation is defined by Shannon to be [·86]
2
3
"the process of designing a computerized model
of a system (or process) and conducting
experiments with this model for the purpose
either of understanding the behavior of the system,
or for evaluating various strategies for the
operation of the system."
Simulation can therefore be viewed as a problem solving tool
comparable to integer programming, linear algebra, or
network tools such as PERT and CPM. As with these and other
methodologies, the performance of a simulation analysis
requires a system definition and the formulation of a model
which emulates the system behavior. Similarly, the model is
tested to ensure its validity prior to any manipulation and
interpretation of results. Simulation analysis requires the
formulation of a computerized model, and the use of a
language capable of translating the model into a form which
is acceptable to a computer. The importance of the language
is not restricted to this phase of simulation analysis. It
affects each step, from system definition to application of
results, and an inappropriately chosen language is a
definite hinderance in the performance of a simulation
analysis.
Chapter 2
BULK MATERIAL TRANSPORTATION SYSTEMS
The American Heritage Dictionary defines transportation
as the act of transporting or conveying from one place to
another [ 60] . A bulk material transportation system is
therefore a system which provides for movement of a bulk
material. A thorough discussion of what is meant by bulk
material is given in Chapter 15. At this time it should
suffice to say that a bulk material is any type of freight
which is transported in a cargo carrier
[ 46]. It may be of any physical form,
without packaging
solid, liquid, or
gas. Typical bulk commodities include coal, petroleum and
petroleum products, grain, chemicals, sand, and gravel. The
movement of these materials is distingushed from the
movement of containerized goods by their unique handling and
transportation characteristics. Examination of the various
transportation modes employed reveals similarities in many
aspects.
The principle modes of bulk material transportation are
given in Table 1 along with some current industry statistics
[14,54]. With the exception of highway transportation
systems, the dominant type of material transported is of
bulk form. Highway transportation provides a necessary link
4
5
TABLE 1
Transportation Facts and Figures
Railway Highway Inland Ocean Pipeline Conveyor Water Water
Average 533 1770* 392 3000 345 0.75 Distance -20000 (miles)
Average Speed 60 50 5.5 22 4 10 (mph)
Percent Bulk of 60 40 85.2 78 100 70 Cargo
Percent Cargo 36 24.3 6.7 27 25 of Bulk
Average Capacity 78.8 13.52 1350 40000 ... (tons)
Cost** Rating 5 6 3 2 1 4
*This is an average figure for long haul distances, 535 being the average short haul distance.
**The modes are ranked from the most inexpensive (1) to the most costly per quantity of material moved (6).
"-" This indicates that the data is unavailable.
11 -. 11 According to CEMA, currently available belt conveyors are capable of handling hourly capacities in excess of any practical requirement.
References [14,17,54,91)
6
between other transportation modes. This function is
commonly required due to the intermodal nature of most bulk
transportation systems.
included as they are
Air transportation systems are not
not generally associated with the
movement of bulk materials. Conveyor systems, which are
typically thought of as material handling systems are
included, reflecting the influence of a material oriented
perspective.
It is appropriate here to differentiate between what is
meant by the classifications material handling and
transportation systems. For the purpose of this research, a
bulk material transportation system shall be defined as
follows:
1. Beginning where the bulk material may be assembled
for subsequent movement to another facility.
2. Including the carrier, the transportation medium, and
any number of interim facilities.
3. Ending where the bulk material may be assembled for
subsequent use.
Employing these guidelines, bulk material handling
systems exist prior to 1 and following 3. Therefore, any
movement of bulk materials occurring within these limits is
defined as transportation. This may involve conveyor
movement at a coal port facility, or stacking/reclaiming
7
systems at a mine. The loading and unloading facilities may
be described in any level of detail desired. These
facilities are regarded as forms of intermodal transfer. A
time limit for intermodal or modal transfer has not been
specified. Certain transportation facilities, such as rail
terminals, may delay cargo for any amount of time required
and/or permitted. These may be simply described as delays
in the transportation system.
This definition does not preclude decomposition of a bulk
material transportation system. It merely serves to
restrict its growth. For example, by viewing an interim
terminal as the end of the system, the movement of the
material after it reaches the terminal is now considered to
be part of a material handling system. These definitions
and conclusions are presented in greater detail in Chapter
14.
Table 1 indicates some similarities between the systems,
for instance in terms of capacities and average milage
figures. These large figures are typical of bulk material
transportation systems. The characteristics associated with
bulk materials results in transportation systems which are
uniquely different from others, and which contain common
features in terms of entities, events, and other simulation
aspects. It is these common characteristics which, if
8
incorporated within a simulation language, will enable the
system's analyst to easily and efficiently simulate a bulk
material transportation system.
Chapter 3
PROBLEM DEVELOPMENT
It should be no1ed here that several currently available
simulation languages are capable of representing most types
of transportation systems, including those for bulk material
movement. This is evidenced by the availability of
simulation models of these systems [22,26,89]. It is not the
purpose of this research to show that current simulation
languages are not capable of doing this. Rather, this
research investigates the degree to which these languages
are capable of describing bulk material transportation
systems.
The qualities which characterize current simulation
languages have developed from the designer acknowledging the
analyst's need to efficiently represent a chosen system.
The restrictions which have, and still are, guiding language
development are both physical, referring to computer
hardware, and conceptual, reflecting the analytical
perspectives
these areas
of the analysis
are reflected
procedure. Innovations
in the various levels
in
of
sophistication easily recognizable when reviewing simulation
languages. Languages have evolved to a point where their
selection and use are important factors in the simulation
analysis procedure.
9
10
The availability of languages designed for specific types
of systems delineates yet another level of simulation
language sophistication. These languages are formulated
according to specifications imposed by simulation hardware
and the analysis procedure. The particular system to be
studied has been used to dictate language requirements,
providing a conceptual influence for the language's physical
form and abilities. Bulk material transportation systems
represent an area where limited research toward the
identification of functional specifications for the
development of a specialized simulation language has been
presented.
From one perspective, simulation language specifications
shall identify inadequacies of languages currently used to
describe bulk material transportation systems. It is from
this viewpoint that current languages are examined. An
alternate purpose of these specifications is to assist in
formulating a simulation language designed specifically for
the analysis of bulk material transportation systems. It is
proposed that a language which conforms to these
specifications will facilitate the systems analysis.
Chapter 4
RESEARCH OBJECTIVES
The primary objective of this research is the development
of a set of functional specifications which will assist in
the formulation of a simulation language for bulk material
transportation systems. These specifications evolve as the
result of two distinct research approaches. To understand
the nature of a simulation language, each step of the
the 1 anguage' s analysis procedure is examined from
perspective. A detailed review of available simulation
languages
research
provides
approach
incentive
through
and justification
presenting some
currently available to systems analysts.
for this
languages
The second research approach considers bulk material
transpor~ation systems. The systems are analyzed to
identify specific simulation language requirements which
would facilitate language use for systems analysis. The
simulation language reviews assist here, as before, by
identifying limitations and difficulties facing,
specifically, bulk material transportation systems'
analysts. The specifications resulting from this approach
represent the requirements of the transportation industry
for a language which will efficiently and easily model their
systems.
11
12
The underlying objective of this research is to utilize
the presented specifications to develop a simulation
language for bulk material transportation systems. The
simulation language development is the proposed topic of-the
author's doctoral dissertation, of which this research is an
integral part. The following is a summary of the specific
objectives of this research;
1. To understand the nature of simulation languages and
their role in the analysis procedure.
2. To review a selection of the currently available
simulation languages in the published literature.
3. To determine the needs of bulk material
4.
transportation systems
language.
To develop functional
regarding a
specifications
formulation of a simulation language
material transportation systems.
simulation
for the
for bulk
Part I is an
Chapter 5
THESIS OUTLINE
introductory section, presenting a
preliminary overview of the simulation analysis procedure.
Following a brief discussion of bulk material transportation
systems, the approach to problem development is examined.
The objectives and signifigance of this research are
presented and the Part concludes with a thesis outline.
Part II presents a detailed examination of the simulation
analysis procedure. Each step of the analysis procedure is
discussed with regard to available simulation software and
hardware if applicable. This Part investigates a
classification scheme for simulation languages and examines
their design and selection criteria.
Part III presents a selective review
available computer simulation languages in
of
the
currently
published
literature.
and use
Emphasis is placed upon language construction
particularly with respect to bulk material
transportation applications. A table is presented comparing
these languages on the basis of selected criteria.
Part IV investigates bulk material transportation systems
and models, examining the needs of these systems which will
affect simulation language requirements.
13
14
Part V presents the constructs,
specifications, for the development of a
or functional
transportation
simulation language. These constructs have been formulated
in previous chapters, and are gathered here as a logical set
of specifications.
PART II
THE SIMULATION ANALYSIS PROCESS
15
Chapter 6
SIMULATION ANALYSIS
Simulation analysis is a process by which a system is
modeled and studied for the accomplishment of experimental
objectives. There are several techniques currently
available for the analysis of complex systems. Simulation
analysis is most often the choice for the analytical
evaluation of real world systems which may have one or more
of the following characteristics [77];
1. If few fundamental laws governing system behavior are
available, or there are numerous procedural entities
affecting the system which are difficult to describe
and represent.
2. If it is desired to model and analyze human decision
making or policy inputs which are difficult to
quantify.
3. If random components are signifigant elements in the
system.
4. If the system is large and/or complex prohibiting
closed form solution techniques.
16
17
6.1 ADVANTAGES AND DISADVANTAGES OF SIMULATION ANALYSIS
The merits and demerits of simulation modeling and
analysis as an approach to problem solving have been studied
in detail, (2,21,32,33,43,52,88] and are presented in Table
2. It should be noted that the technique of modeling,
whether for simulation or other purposes, offers several
advantages over real world experimentation. These have been
included in Table 2 as the simulation analysis procedure
requires the use of a model.
Alternate uses of simulation models which have been
proposed include the use of the model as a training tool or
as a validity check of the assumptions to be used in a
non-mathematical model [ 86] . An overall advantage of
modeling in general is that it permits a greater degree of
control over experimental conditions than actual system
manipulation will permit.
There are many situations in which simulation modeling
techniques are not easily applied or prove impossible to
utilize. For example, a system of sufficiently large scale
would require a model which is in itself, large and complex.
Writing computer programs for such a model is a lengthy and
difficult task.
The majority of the complaints concerning simulation
modeling reflect the misinterpretation of the analytical
18
TABLE 2
Advantages and Disadvantages of Simulation Analysis
Advantages
1. The performance of a system under a projected set of operating conditions can be estimated.
2. Alternative proposed system designs or alternative operating procedures for a single system can be compared; sensitivity analysis of system parameters can be performed.
3. Actual experimentation with the system may be infeasible, cost ineffective, or disruptive of the current operation of the system. In addition analysis may be performed on a proposed system.
4. Systems may be studied over an expanded or compressed time frame.
5. The use of a computer permits use of complex mathematical procedures for solution of the model's defining equations.
6. Simulation may be used to solve problems for which analytical methods do not exist, or are too difficult for hand calculations.
Disadvantages
1. Development of an acceptable simulation model is usually expensive and time consuming.
2. Simulation is imprecise, the degree of which is difficult to ascertain, even with the use of sensitivity analysis.
3. The numerical form of output data results in users assumming that the data is "real."
4. Misinterpretation of output can lead to incorrect analysis.
19
results [86]. It should be noted that for each run,
simulation of a stochastic model will produce only estimates
of a system's true characteristics for a given set of input
parameters. Many analysts incorrectly perceive simulation
results as an "answer" to their problem. Drawing inferences
of this type leads to erroneous conclusions which are
neglectful of the true purpose of a simulation analysis,
that of understanding system behavior. The numerical form
of simulation results often creates a tendency to place
greater confidence in the program output than is warrented
by the technique.
6.2 PROCEDURAL STEPS
The accomplishment of a simulation analysis may be viewed
as a problem solving process. As with most processes, it
may be decomposed into various stages or steps which will
complete the process, or analysis. Procedural steps have
been presented by many researchers [2,21,32,33,43,52,93) in
the form of a methodology for simulation analysis. The
varj ous methodologies differ in exact wording and detail,
however the following list contains those steps which
consistently appear;
1. System Definition determination of system
boundaries and restrictions, and an identification of
analysis objectives.
20
2. Model Formulation construction of the system
representation or model.
3. Model Translation - alteration of the model into a
form (computer program) acceptable to the computer.
4. Model Validation and Program Verification
determination of the model's ability to correctly
represent the system, and the program's ability to
execute in the desired logical manner.
5. Model Experimentation the manipulation .and
execution of the computer program to obtain output
values.
6. Model Interpretation and Application drawing
inferences from the program output and applying these
to the real world system.
Although these steps are presented as a logical sequence
of events for performing a simulation analysis, it should be
realized that the analysis is not necessarily a sequential
process. For example, as subsequent steps are performed,
new insights about the system may be obtained which
necessitate reformulation of analysis objectives. This may
result in system redefinition, thus the entire procedure is
reini tiated. Each completed step can require a previous
step's re-evaluation in a similar manner.
21
The iterative nature of the process may not be beneficial
to the analysis. Each iteration, resulting in the
redefinition of the system at some step in the process,
could force an undesirable generalization of the analysis
objectives. Therefore, by limiting the number of
iterations, it is more likely that the original objectives
wi 11 be adhered to. The computer language utilized in the
analysis affects the number of iterations necessary through
its influence at each step of the process.
6.3 THE ROLE OF SIMULATION LANGUAGES
The accomplishment of a simulation analysis is achieved
within a wide variety of conceptual frameworks, and
utilizing any of a number of analysis tools. Examples of
the latter include computers, and computer languages, which
are necessary for the performance of a simulation analysis.
Decisions regarding the applicability of these tools will
affect the accomplishment of the various steps and should be
made with the intent of simplifying and facilitating the
analysis. One of the most important decisions to be maae,
in terms of overall influence throughout the simulation
analysis, is the computer language selection. The
language's primary function is to provide a vehicle by which
the model is translated into a form for computer evaluation.
22
The simulation program is constructed utilizing the selected
computer language, and then submitted to the computer for
execution.
The increasing use of simulation as a problem solving
tool has resulted in the identification of several
programming features which are common to most simulation
programs. Examples of these include random variable
generation, advancing simulated time, and data collection.
A simulation language is a computer language specifically
intended for use in the formulation of a simulation program,
and which usually contains built-in features for situations
commonly required in the simulation program's execution.
Simulation languages are capable of providing assistance
in accomplishing each of the steps involved in the
simulation analysis. For example, they provide a conceptual
framework which influences system definition and model
formulation. They also provide statistical assistance for
validation and offer convenient computational abilities.
Recognizing the importance of the language used, an analyst
should select the language that performs the desired
functions in an acceptable manner.
Simulation language design should be attempted from the
intended user's viewpoint. Specifically, the designer
should note the language's importance in the overall problem
23
solving process, and incorporate features which facilitate
it. The user's desire to select a language which performs
the required functions with minimum difficulty has been a
motivating factor in the improvement and specialization of
simulation languages. The interaction between the language
designer and the user is beneficial to the development of
improved languages and other analysis tools. In this
respect, the simulation analysis process is extremely
influential in the design process. The following chapters
present a more thorough examination of the analysis
procedure, emphasizing those aspects which affect the
formulation of simulation languages.
Chapter 7
MODEL FORMULATION
Once the system has been defined,
formulate a model which represents it.
of analysis objectives generally
it is necessary to
The accomplishment
requires system
experimentation for· observance of its resulting behavior:
It is often infeasible or impossible to directly manipulate
the system, which may not exist as yet. To satisfy the
experimental requirements of the simulation analysis, a
system model is formulated.
7.1 MODEL CLASSIFICATIONS
A model is a description or representation of a system,
usually developed for the purpose of studying and drawing
inferences about system. Pri tsker and Pegden state that
models are employed at four levels (77];
1. As explanatory devices for problem definition.
2. As an analysis vehicle for crucial components,
elements, or issues determination.
3. As design assessors for the synthesis and evaluation
of proposed solutions.
4. As predictors to forecast and aid in the planning of
future developments.
24
25
The variability of the desired objectives of a simulation
analysis is reflected in these levels, and models differ in
that they may offer information applicable to one or more of
them.
Models have been classified in a number of ways, and
these classifications have been loosely extended to
subdivide simulation models. Simulation models are those
which have been developed specifically for subsequent
translation
evaluation.
into a
A more
simulation
accurate
program for
classification
computer
would be
computer simulation models, as certain models are developed
for physical simulation purposes.
analysis objectives may dictate
Certain aspects of
the manner in which
the
the
system entities are modeled resulting in a model which may
be described by the following classifications~
1. Iconic versus analog versus symbolic models
2. Static versus dynamic models
3.
4.
Deterministic versus stochastic models
Discrete versus continuous versus
discrete/continuous models
combined
The computer simulation model classification is extremely
important when considering language selection. The fourth
classification, in particular, could be used to efficiently
classify simulation languages. It should be noted that the
26
system type is not considered; the model type being the more
influential language selection criteria. As an example, a
discrete system need not require a discrete simulation model
for a system description which will satisfy analysis
objectives. Similarly, many continuous systems have been
successfully analyzed using discrete simulation models.
As previously stated, simulation languages often provide
a modeling framework or perspective which is intended to
assist in both system definition and model formulation. The
selection of a simulation language and the development of a
simulation model are interactive processes. It is possible
for a model to dictate a language requirement, or the
language may provide constraints for model formulation.
Either of these may adversely, or favorably, affect the
analysis procedure. Successful treatment of
interactions will result in a model that is
these
easily
translated into a computer program. The importance of the
relationship between the model and the language is stressed
throughout the following sections which present descriptions
of each model classification.
27
7 .1.1 Iconic, Analog, and Symbolic Models
Iconic or physical models are facsimilies of the system
being studied [ 86] . They may or may not be scaled, and
examples include airplane replicas for wind tunnel studies,
and architectural mock-ups. Visual models generally display
graphical representations of some system aspect. Flowcharts
and schematic diagrams are examples of analog models which
depict the logical relationships and interactions between
system elements. Symbolic models utilize symbols to
represent system entities, and are the most abstract model
type. For example, mathematical models are symbolic models
which describe relationships among system entities utilizing
equations.
The majority of simulation models formulated are
symbolic, or more specifically, mathematical models. The
system behavior is described
expressions or
representation
functions.
of a system
A
by
utilizing mathematical
common
a set
example is the
of differential
equations. Certain simulation languages provide facilities
for constructing networks, also a symbolic model type.
Simulation utilizing an analog computer requires the
formulation of an analog model. This is a particular means
of simulating continuous systems which requires a unique
form of computer software and is discussed in Section 8.2.1.
28
7.1.2 Static and Dynamic Models
A static model represents the system's state at a
particular time. It depicts the relationships between
entities when equillibrium exists in the system. An
attribute' s value may change, however information is not
provided on the manner in which the changes occur. Static
models are created to solve certain stochastic and
deterministic problems in which the passage of time or the
means by which the system changes occur is irrelevant [52).
Examples of these include models which estimate critical
values or the power of a proposed hypothesis test, and
equillibrium models in economic theory.
Dynamic models are those in which the system's state is
permitted to change with time. Unlike a static model,
information is provided on the manner in which these changes
occur. The classification is applicable if one or more of
the model entities is time dependent in behavior, or if the
passage of time is crucial to the analysis.
Simulation models are typically dynamic
observance of the system as time passes being
with the
an overall
objective of the simulation analysis. For this reason
simulation languages incorporate a mechanism for timekeeping
throughout program execution. The two commonly used
mechanisms for advancing simulated time are the fixed
increment approach and the next event approach.
29
7.1.2.1 Fixed Increment Time Advancement
Simulation languages which utilize this approach require the
definition of a fixed, incremental time unit. The
simulation clock is always advanced by this incremental
amount and the system is examined for any events which may
have occurred during the interval. If events have occurred
they are executed, the clock is advanced another incremental
unit, and the process is repeated [43,77].
7.1.2.2 Next Event Time Advancement
This approach advances the simulation clock far enough to
initiate the occurrence of the next scheduled event. The
system is updated to show that this event has occurred, and
time is advanced to the next event. The time advance
intervals are therefore variable in length, permitting
intervals where events do not occur to be skipped. This
approach requires the use of an event list, or file for
maintaining the time order of event occurrence [43,77].
The next event approach is· generally preferred for large
simulation models, or as the mean time between events
increases as it tends to be more efficient with regard to
computer runtime. This is because calculations are
performed only when necessary, at event times. The
efficiency of the fixed increment approach depends on the
30
chosen increment size. The number of required calculations
increases with decreasing increment size, and as many of
these do not occur at event times they are often
unnecessary. This approach is easier to implement because
it does not utilize an event list or_ any of the associated
processing required by the next event approach [ 43, 70].
System information is lost because events are treated as if
they occurred simultaneously at the end of the interval,
ignoring the exact time of event occurrence. Simulation
languages may offer one, the other, or a choice of both time
advance mechanisms. A primary selection consideration is
the quality of output data required by the analyst.
7 .1. 3 Stochastic and Deterministic Models
Stochastic models are those in which one or more entities
possess a degree of randomness in its transition from one
state to another [52]. For example, it may not be possible
to assign a probability to the state that a model entity
will assume following an activity's occurrence. Even if
possible, the attributes of an entity, and consequently the
system's state, may not be predicted with certainty. The
output of a stochastic simulation is· in itself random
because specific input values cannot be forecasted. The
model analysis will provide estimates of the true stochastic
31
behavior of the system. A disadvantage of a stochastic
model is the necessity for long run lengths to achieve
steady state conditions.
A deterministic model describes a system as evolving in a
completely known or deterministic manner from one state to
another [ 52, 70]. Because all model entities behave in a
precisely predictable way, the simulation's output is unique
for a given set of inputs. Model debugging and validation
is usually easier for a deterministic model, and steady
state conditions are irrelevant as the system is not random.
Most systems possess some measure of interacting
stochastic and deterministic entities. The randomness of
any one
through
model entity tends to
its interactions with
permeate the entire model
other entities. Therefore
those models with one or more stochastic entities are
usually labelled stochastic.
Recently, a third model type has been isolated, termed
semi-stochastic, and embodying the concepts of both
stochastic and deterministic models. Analysis of these
models is achieved by isolating the model's stochastic
portions using pre-processor routines. The output of these
routines is utilized to supply the model's deterministic
portion. The advantage of this analysis method is a
reported reduction in computer runtime when compared to
32
analysis of the model performed as if it were purely
stochastic [31].
The majority of simulation languages are capable of
translating both stochastic and deterministic models. The
stochastic aspects are reflected in the use of probability
distributions for describing model behavior. Simulation
languages differ in the mechanisms utilized for random
variable generation as well as in the availability of
various distributions.
7.1.4 Discrete Models
Simulation models may be classified as discrete,
continuous, or combined discrete/continuous. This
categorization
viewpoint of
is perhaps the most important from the
the simulation language used. Certain
languages are capable of representing only discrete models,
others apply only to continuous models, and still more are
capable of representing either, both, and/or combined
discrete/continuous models. It should be stressed that
these terms are descriptive only of model entities. As
previously stated, many systems can be successfully modeled
using either orientation.
the study's objectives.
The choice depends primarily on
33
A discrete model is one in which the attributes of
dependent entities, representing the system's state, change
discretely at specified points in time known as event times
(77]. If a choice has been made to model a system
discretely, further decisions.regarding modeling perspective
must be made. Currently available simulation languages
utilize any or all of the three following approaches;
1. Activity scanning
2. Event scheduling
3. Process interaction
7.1.4.1 Activity Scanning
This approach is often regarded as being unimportant in that
few languages offer it as a modeling per spec ti ve [ 77] .
After the simulation clock is advanced, the system's state
is compared to a list of conditions that are descriptive of
all system states which require an activity to begin or end.
If the conditions require it, an activity is started (or
stopped) and the associated system changes are enacted. The
process is then repeated as often as necessary for the
simulation. The user is required to compose the list of
conditions, and its completeness is crucial to successful
simulation.
34
This is a relatively inefficient method for system
simulation compared to the remaining two approaches, and is
mentioned primarily for completeness. It is, however, an
extremely useful approach if activity durations cannot be
specified or are dependent upon the system state.
7.1.4.2 Event Scheduling
The event scheduling approach is consistent in concept with
the next event time advance mechanism in that the simulation
is performed through event processing in the order in which
the events have been scheduled to occur. For this purpose,
the modeler must develop a complete listing of all the
events which occur resulting in changes in the system's
state.
Of the three approaches, this is possibly the most
flexible, restricting the modeler only in terms of those
events that can be logically represented by the chosen
simulation language. Pritsker and Pegden state that this is
the most difficult approach to learn [ 77]. However, its
power and flexibility may offer compensation for the
difficulties in application.
7.1.4.3 Process Interaction
35
The process interaction approach to discrete event
simulation modeling utilizes a process concept when
describing a system [27]. The modeler percieves the system
as a set of processes which interact with each other, each
set representing the entity's path. Process routines are
created which tell the history of an entity within the
system, and which explici tiy contain the statements for
simulated time advancement.
This approach combines features of both the activity
scanning and event scheduling approaches. It is perceived
to be a simple and more natural approach to simulation
analysis because many manmade systems are easily described
as a set of simultaneous processes [ 2 7 l . Simulation
programs written with process oriented languages generally
require less lines of code due to the language statements'
macro structure. From an alternate perspective, the modeler
is often restricted to the use of a set of macro-statements.
This restriction affords limited flexibility in that these
statements are usually oriented toward queuing theories.
As is often the case with modeling perspectives, a system
may be viewed from any one of these three approaches,
although the analysis objectives may indicate a preference.
Simulation languages vary in the type of modeling
orientations offered and the facilities provided for their
36
representation. The chosen language should offer those
orientations consistent with the modeler's views.
7 .1. 5 Continuous Models
A continuous model is one in which the attributes, or
descriptive values of entities, change continuously with
time. The system. is characterized by smooth, continuous
state changes. These changes may be expressed by
differential and/or difference equations in which the
variables correspond to the attributes of entities, and the
functions represent activities. In a continuous model, the
time variable may be continuous or discrete, determined by
whether the state changes occur at any point in time or only
at specified time intervals [77]. Jacoby isolates two
assumptions which characterize continuous models [43].'
l. The time scale used in the model is such that
irregular fluctuations
averaged.
in variable behavior are
2. The variable behavior is smooth and continuous such
that it can be represented by mathematical
expressions.
Continuous models are the only model type which may be
simulated utilizing an analog computer. Analog, continuous
simulation models and techniques are discussed in Section
37
8. 2. 1. In general, continuous simulation models may be of
block or expression form and the associated simulation
languages may be similarly classified.
7.1.5.1 Block Form Models and Languages
Block form languages originated as an interconnection and
control language for a collection of subroutines
representing analog blocks. The model is initially
constructed in block diagram form, then implemented through
a set of connection statements provided by the language. In
this manner, the language emulates the analog computer's
behavior by permitting subroutine connection and control in
much the same way as an analog panel permits control of
electronic uni ts. These languages ( and models) are often
selected by those who prefer analog type diagrams rather
than equations,
information for
or as an aid in providing
a purely analog model [ 48] .
dynamic check
Examples of
block form simulation languages include MIDAS, PACTOLUS, and
GPSS.
7.1.5.2 Expression Form Models and Languages
Expression or equation form models combine the convenience
of algebraic and logical statements with the simplicity of
block form modeling techniques [65]. Languages of this type
38
permit direct representation of the model's mathematical
equations in a form similar to that permitted by general
purpose computer languages. Expression form languages are a
more recently developed class of continuous simulation
languages. The majority of these adhere to the
specifications of the Simulation Software Committee of
Simulations Councils Inc. for continuous system simulation
languages [ 48) . Examples of expression form simulation
languages are DSL/90, DISCO, and CSMP/360.
7 .1. 6
This
utilized
Combined Discrete/Continuous Models
model type combines the descriptive
in discrete and continuous models
qualitites
for the
formulation of a model incorporating both orientations. As
previously stated, it is possible to represent a continuous
system with a discrete model, however the model often
requires system definition modifications which are
undesirable. Combined discrete/continuous models permit
representation of system entities and events as either
continuous or discrete, providing a model which is capable
of describing the system more accurately than if the modeler
were limited to one orientation or the other.
The use of combined discrete/continuous modeling
capabilities has been motivated by an increasing need for
39
additional simulation modeling techniques (23]. The desire
to model a system in its most natural form, whether discrete
or continuous, is a strong inc en ti ve for the use of a
combined model. A more exact representation of the system,
requiring fewer approximations or modifications can be
achieved with a combined model. Additionally, a combined
simulation model facilitates use of a broader scope of
available modeling techniques, retaining the useful features
of both discrete and continuous models in addition to
specific
portions.
interaction capabilities between both model
The advantages of combined simulation result from the
availability of both discrete and continuous concepts for
applicability to a problem. The model, and subsequently the
language used, facilitates strong feedback or interaction
between the continuous and discrete portions of the model or
program [ 23]. The hierarchies of discrete and continuous
models which may be required to adequately describe a given
system may be analyzed using a combined simulation
philosophy. Use of combined simulation techniques
facilitates increased modeling efficiency and improved
standardization resulting in fewer system approximations
when compared to the use of purely discrete or continuous
modeling concepts.
40
Combined discrete/continuous simulation languages possess
the attributes of both discrete and continuous languages.
The discrete facilities may involve utilization of any
combination of the discrete event modeling approaches
discussed in Section 3.1.4. The continuous facilities may
be differential or difference equation oriented, or may
parallel the facilities offered by block form languages.
Possibly the most important feature of combined simulation
modeling techniques is the type and availability of
interaction between the discrete and continuous portions of
the model (23). These interactions may occur in any of the
following four ways;
1. Concurrent time operation
2. Model data base interaction
3. Control flow initiation interaction
4. Structural interaction
7.1.6.1 Concurrent Time Operation
The necessity to synchronize the model events requires
coordination of the simulation time clocks for the discrete
and continuous portions, resulting in a timing mechanism
which controls the overall model simulation (23). Utilizing
a next event time advance mechanism, the time of the most
imminent event is noted. An incremental time step advance
41
procedure is then used to advance the simulation clock.
Static block outputs are computed with each step in addition
to derivatives and the system states. When the incremental
time unit causes the time of the most imminent discrete
event to be passed (or reached), the timing mechanism alters
the step size such that the exact time of the event
occurrence is reached. The discrete event is executed~ the
system is updated, and the process continues repetitively.
7.1.6.2 Model Data Base Interaction
This form of interaction may be either passive or active,
referring to the type of relationship between the discrete
and continuous portions of the model (23]. State
referencing
facilitates
is a
access
passive form
to various
of interaction which
continuous or discrete
non-local data storage by either portion of the model. This
form of interaction does not usually require any special
language implementation measures, being generally available
within the data structuring of most procedural
State modification is an active form of model
languages.
data base
interaction which permits a discrete event to change the
value of a continuous process' output variable. This
interaction is similar to the resetting of an analog
computer integrator to a new initial value during
simulation.
42
7.1.6.3 Control Flow Initiation Interaction
This is a form of process activation whereby a continuous
model portion may initiate the occurrence of a discrete
event or process. As the value of a continuous variable
achieves a specified threshold,
activated or scheduled to occur.
a discrete process is
This form of interaction
facilitates the transformation of entities from a continuous
to a discrete event nature [23].
7.1.6.4 Structural Interaction
This form of interaction permits a discrete model portion to
change the functional description of a continuous variable
or process. In this manner, the structural definition of
the continuous model portion may be modified by the
occurrence of a discrete event. This is considered to be
the highest level of combined discrete/continuous model
interaction
[ 23] . For
and has
example,
interesting efficiency
the substitution of
applications
simplified
continuous subsystem models during known or steady-state
system durations is possible.
43
7.2 SIMULATION MODEL CLASSIFICATIONS
Simulation models are symbolic, dynamic representations
of a system which are stochastic or deterministic, and
either discrete, continuous, or combined
discrete/continuous. In this respect they do not differ
from models in general. However the requirement that a
computer must evaluate the model indicates that some
consideration should be given to computer hardware and how
it affects simulation model classification.
Computer simulation models may be classified by the type
of computer which will be utilized for their evaluation as
follows;
1. Analog simulation models
2. Digital simulation models
3. Hybrid simulation models
The importance of the computer type utilized in the
performance of a continuous simulation analysis is
emphasized by these classifications. The classifications
stress the fact that computer languages have developed
concurrently with computers, and the techniques available
for model translation (i.e. simulation languages) have often
been developed for particular computer types.
44
7.2.1 Analog Simulation Models
Initial attempts at continuous system simulation were
performed using an electronic differential analyzer, or
analog computer. This device consists of various electronic
units capable of performing mathematical operations based on
voltage differentials. Pure analog simulation does not
involve the use of a computer language. The simulation of
continuous systems is achieved by first converting the
mathematical model into a set of machine equations, altering
the original problem equations through a process of
reduction and scaling [ 65] . It should be noted that an
analog computer treats all dependent variables as being
continuous in nature.
The programmer then assigns specific units to the
equations and generates a scaled computer diagram showing
these units and their
include amplifiers,
interconnections.
potentiometers,
Examples of units
resistors, and
capacitors. The required units are physically connected by
a process known as patching, creating a panel [ 65] . The
panel is attached to the analog computer which generates
solutions to the equations through analysis of the behavior
of the uni ts in the panel when subjected to electrical
current flow. Thus actual physical conditions are
represented by the unit's scaled output voltages.
45
Table 3 lists the advantages and disadvantages of using
an analog computer, as opposed to digital or hybrid, for
continuous system simulation analysis.
7.2.2 Digital Simulation Models
A digital computer, for digital simulation, is
essentially a counting device, operating with numbers which
represent a finite digital sequence
purpose computing device which is
[ 36 l . It is a general
discrete in nature,
resulting in all model variables appearing in discrete form.
Digital computers permit model representation by any digital
computer language, and are capable of simulating models
without any classification restrictions. They utilize a
process of numerical approximation to perform integration
commonly required for continuous system simulation. Table 4
compares the use of digital versus analog and/or . hybrid
computers for system simulation.
7.2.3 Hybrid Simulation Models
Hybrid simulation requires a
combines the qualities of analog
hybrid computer which
computers with those of
digital logic computers. The reasoning behind the merger is
to increase the versatility of the analog computer by
combining its speed with the digital computer' s storage
46
TABLE 3
Advantages and Disadvantages of Continuous Analog Simulation
Advantages
1. Due to parallel performance of computations, execution is fast and independent of problem size (number of equations).
2. Analog computers permit a great deal of man/machine interaction.
3. Analog computers are extremely efficient integrators, capable of managing complicated, non-linear problem characteristics.
4. Actual hardware from the system being studied can be included in the execution of the program.
Disadvantages
1. Analysis requires variable scaling, and computational accuracy is somewhat limited.
2. An overall size constraint exists for the model due to the number and type of electronic units available.
3. The analog computer is a special purpose device employing a machine oriented language, and is designed for the particular task of integration. In addition, only one task can be efficiently performed at a time.
4. Analog computers cannot simulate discrete time systems.
47
TABLE 4
Advantages and Disadvantages of Digital Simulation
Advantages
1. Digital computers are capable of performing arithmetic and logic operations at very high speeds, and storing large amounts of data.
2. Digital programs are easier to debug, and offer greater reliability than analog.
3. There is no need to scale variables, and any degree of integration accuracy can be achieved utilizing a sufficiently small step size.
4. Digital computers offer more computational flexibility in expressing a model's complex, non-line~r characteristics.
5. Digital computers employ user oriented languages which are capable of limited interactive ability, and can operate from a stored program.
Disadvantages
1. The simulation program's execution is slow due to the iterative nature of the integration process.
2. As the model increases in size, so does the execution time.
3. Errors in solution are introduced due to the specified integration step size and the numerical approximation technique used for integration.
abilities, input/output
The digital components
48
facilities, and logic
perform computations,
functions.
such as
multi-variable function generation, which may be difficult
or impossible to execute on an analog computer [ 41] . In
addition they are also used for problem setup, control, and
checkout. The dynamic portion of the program, including
integration, is performed by the analog components. Table 5
presents the advantages and disadvantages of utilizing a
hybrid computer for model simulation.
Recent developments in the area of autopatch hybrid
computers permit expensive hybrid computers to be time
shared and facilitates programming [49]. These factors may
increase hybrid computer usage for simulation analysis.
49
TABLE 5
Advantages and Disadvantages of Hybrid Simulation
Advantages
1. A hybrid computer can offer cost savings over a digital for many dynamic problems, such as design optimization studies, which require a large number of runs.
2. A hybrid computer has much higher computational speed than a digital computer.
Disadvantages
1. A hybrid computer has low computational precision, similar to that for an analog.
2. The required interface between the computers may result in some sampled data errors.
3. Variable scaling is necessary, and required programming is sophisticated and time consuming.
4. Access is limited to a small number of users.
Chapter 8
MODEL TRANSLATION
Once the simulation model has been formulated, it must be
translated into a form which permits computer analysis. A
computer language is the vehicle by which the translation
occurs and it is used to write programs for computer
interpretation. The language consists of a group of symbols
which can be recognized by the computer as instructions for
the accomplishment of desired operations.
8.1 COMPUTER LANGUAGES
The type o{ symbols utilized for computer language
construction determines the level of language sophistication
[ 15, 86] . A hierarchy of computer languages is shown in
Figure 1.
The lowest or most basic level of computer language is
known as the machine language level [15,86]. Computer
languages of this form reflect the computer's command
structure and detailed design, and they are the only
language form which a computer can directly recognize. The
computer instructions are written in 'binary notation with
direct correspondence to machine functions. Formulating a
computer program utilizing a machine language is tedious and
50
51
Figure 1: Hierarchy of Simulation Languages
LEVEL ONE MACHINE LANGUAGES
LEVEL TWO SYMBOLIC LANGUAGES
(Assembly Languages)
LEVEL THREE
LEVEL FOUR
PROGRAMMING LANGUAGES
(Compiler and Interpreter
Languages)
(General Purpose Languages)
HIGH LEVEL PROGRAMMING LANGUAGES
(Special Purpose Languages)
(Simulation Languages)
52
difficult for any purpose. It is severely impractical for
simulation analysis.
The second level of computer languages are known as
symbolic languages. They provide convenient symbols and
mnemonics (memory aids) for use in formulating computer
programs [ 15, 86] . Also referred to as assembly languages,
they incorporate a string of mnemonic symbols which
correspond to machine language functions. The programs are
translated by an assembler, or assembly program into a
machine language program. Assembly languages are machine
oriented and are available for most commercial computers.
Simulation programs are rarely written in assembly language
because the programming effort required, ( though less than
for a machine language), is considerable.
Programming languages constitute the third ievel and are
considered to be the most important user oriented computer
programming aid [ 86] . These languages provide a standard
set of expressions and statements which facilitate the
construction of compact computer programs. Programming
languages are macro in structure which serves to reduce the
time and effort necessary to formulate a complex program,
and reduces the possibility of programming errors. They are
capable of formulating computer programs for most purposes
and are also known as general purpose programming languages.
53
Programming languages are machine independent and may be
categorized as either compiler or interpreter languages.
Compiler languages utilize compilers which translate the
entire application program into either assembly or machine
language form [ 15, 86] . Once compiling is complete, the
computer executes the resulting program. Examples include
FORTRAN, RPG I I, COBOL,· PL/1, BASIC, AND PASCAL.
Interpretive languages require conversion of each line of
the application program to machine language every time the
program is executed. For this reason, these languages
usually require more computation time than compiler
languages. An example of an interpreter language is APL.
The fourth, and most sophisticated level of computer
languages are termed high level programming languages
[ 15, 86] . These languages provide for program construction
of a more convenient form than is possible with general
purpose programming languages. They utilize syntax and
semantics not commonly found in level three languages. High
level programming languages generally employ a translator,
or interpreter program which will generate a third level
language program from the user written application program.
High level programming languages are usually formulated for
special purpose applications such as the solving of partial
differential equations, or for statistical computations.
54
The increasing use of simulation analysis techniques has
resulted in the development of a special class of fourth
level languages known as simulation languages.
8.2 SIMULATION LANGUAGES
Initially, the languages used to formulate simulation
programs were extremely machine dependent, or of a third
level, general purpose type [ 15, 86] . An example of the
former is the use of analog computer techniques for
continuous system simulation. As the need for a more
functional simulation programming aid
languages were created specifically
became apparent,
for formulating
simulation programs. These
simple assembly languages
languages have evolved from
with
features, to sophisticated, high
simulation languages. Currently
designed to aid the analyst in
incorporated special
level, special purpose
available languages are
practically any desired
manner. They range from simulation languages for general
use, to those which apply only to specific system or model
types.
Certain useful features are commonly found in languages
specifically designed for simulation purposes, these being
[ 45] ;
55
1. Data generation - this includes provisions for random
number and variate generation as well as features for
generating correlated data streams.
2. Advancing simulated time this provides for
3 .
4.
5.
coordination of parallel computations, and for time
organization of entity flow within a simulated
system.
Data structuring
efficient storage
the language provides for
and retrieval of very structured
system information.
maintenance system
Also
with
included
search
is
and
mechanisms, and capable of prioritization.
a file
removal
Data collection, analysis, and reporting this
includes statistical and/or graphic reporting
mechanisms.
Initial
permits
condition specifications the
specification of system values
language
and the
generation of initial random sequences for initiation
of the simulation.
6. Program monitoring the language is capable of
monitoring the simulation both for identification of
logical errors, and to permit detailed analysis of
the system's dynamic behavior.
56
From an over al 1 standpoint, a simulation language
generally provides a support routine, usually known as the
control program [45). This is used to insure that events
occur in their proper sequence and time. The means by which
these functions are accomplished, and the thoroughness with
which they are accomplished, varies from one simulation
language to another.
Languages designed specifically for computer simulation
offer several advantages when compared to the utilization of
a general purpose language for simulation model translation.
Table 6 presents the advantages and disadvantages of
simulation languages as opposed to general purpose languages
[21,32,33,52,70,77,86].
8.2.1 Design of Simulation Languages
The formulation of a simulation language, as with all
computer languages, must give extreme consideration to the
intended user, and language application. Lomow and Unger
have delineated three areas of primary concern when
designing a computer language [55]. They are;
1. Programming support
2. Language portability
3. Program portability
57
TABLE 6
Advantages and Disadvantages of Simulation Languages
Advantages
1. They provide a natural framework for system modeling.
2. The language aids in the definition of entities within the system and in distingushing between entities of the same type through the use of characteristic attributes or properties.
3. Dynamic ~torage allocation during execution facilitates the adjustment of the number of entities as conditions within the system vary.
4. Simulation models are typically easier to alter when the program is written in a simulation language.
5. Simulation languages generally provide better error detection because many of the more common user errors which occur during execution of the simulation program are automatically checked for.
6. Macro facilities allow extension of language features.
7. The use of substantially fewer lines of code (due to 2 and 6 above) will reduce error potential.
8. Simulation languages typically include the ability to handle simulation data structures such as linked lists and queues.
Disadvantages (or advantages of general purpose languages)
1. General purpose languages are often known by the programmer, the familiarity lending itself to coding ease.
2. General purpose languages often offer greater flexibility in programming.
3. An efficiently written general purpose language simulation program may require less execution time because it is specifically tailored to analyze a particular situation.
4. General purpose languages are available on virtually all computer hardware.
58
8.2.1.1 Programming Support
Each language emcompasses a basic set of programming tools
which provide continuing support for both program
development and maintenance [55]. A set of clearly defined
project management tools, software configuration tools, and
editors and debugging aids are extremely useful throughout
the coding, debugging, and software maintenance phases.
Emshoff and Sisson report that the time spent coding and
debugging a simulation program can be reduced by a factor of
ten when utilizing a language which has additional
facilities for the enhancement of the debugging process
[ 21] .
8.2.1.2 Language Portability
The second area of concern involves the language's
portability [55]. The language, and its complementary set
of programming tools, should be standardized among all the
environments in which it will be used. Thus programmers
required to alter the environment in which they utilize a
language, perhaps due to change of job or employer, wi 11
experience a smooth transition, and any necessary retraining
in language usage is minimal. Additional consideration
59
should be given to the range of systems or model types which
the language is capable of representing.
8.2.1.3 Program Portability
The final design category concerns program portability.
This involves ensuring that programs which are moved from
one computing system to another will compile and execute
without requiring major program modifications [ 55]. This
assumes that the software transfer is not limited by
computer hardware. A particular advantage of good program
portability is the ability to develop a program at one
facility for subsequent use at another facility. In
addition, any special purpose, user defined simulation tools
should also be portable.
8.2.1.4 Additional Considerations
Research has identified several additional areas which, if
properly approached, can facilitate simulation language use
[ 10] .
1. The language should be strongly typed ensuring that
each entity embodies a clearly defined set of values.
This prevents confusion between the formulation of
logically distinct concepts. As a result, the
compiler is able to detect many errors which, in
60
other languages, may have led to executable but
incorrect program logic.
2. The definition of modular program units is
facilitated with data abstraction. These modular
units can be used to encapsulate the data structures
and operations of a single abstract data type.
3. The use of generic units allows program unit
definition which is independent of the type of value
which it is to manipulate. As a result, a single
piece of code can serve as a template upon which
program uni ts can be based which perform similar
operations on various data types.
4. A well developed language library, as well as subunit
use which supports and simplifies the development of
medium to large scale software projects.
8.2.2 Selection of~ Language
Language selection for a system's simulation analysis is
a topic which deserves considerable attention. Improper
selection can result in an unnecessary increase iu the time
required for model formulation, coding, and analysis. Just
as the selection of the proper type of model (discrete,
continuous, etc .. ) can influence the validity of the
simulation analysis, the proper language selection will also
influence each s~ep.
61
In addition, consideration must be given to the
language's processing characteristics including statistical
capabilities, list processing capabilities, core-allocation
abilities, and ease of obtaining standardized or user
tailored output reports. The reliability of the compilers
and support systems is important as well as compilation and
execution time considerations.
The similarities between the language design criteria and
the language selection criteria is not coincidental. It
should be the goal of the designer to formulate the language
from the user's point of view, satisfying user requirements
whether for a wide variety or for a specific type of
simulation analysis. The design goals should be formulated
at the outset, and strictly adhered to, facilitating a
clearly defined and easily implemented language.
As stated by Law and Kelton, decisions regarding the
language choice occur at two levels; 1) a language for
general use on several, varying projects, and 2) a language
for use in a particular study [52]. Table 7 presents a list
of considerations for language selection at both levels.
62
TABLE 7
Considerations for Simulation Language Selection
Level One Considerations
1. The compatibility of the language and the computer to be used.
2. Language installation and maintenance cost.
3. The number and types of simulation studies to be performed.
4. The quality and availability of language documentation.
5. Language flexibility and power.
6. The ease of learning the language.
7. The computer storage requirements and availability.
8. Language efficiency.
Level Two Considerations
(The criteria from Level 1 plus the following)
1. Language availability - either in-house or on a time sharing network.
2. Languages known by the analyst and time available for the study.
3. The program's portability requirements and the language's ability to communicate the nature of the model to model to intended users.
Chapter 9
MODEL VALIDATION AND PROGRAM VERIFICATION
The validation and verification of a simulation model and
program are ongoing processes throughout the simulation
analysis procedure. It is these processes that constrain
the analysis procedure such that the resulting simulation
model and program will be useful to the analyst. The
applicability of the results of the analysis is directly
determined by the degree of both model validity and program
verification.
The importance of validation and verification must be
emphasized when performing a simulation analysis.
Simulation models tend to be extremely complex, representing
several interacting processes and entities. The assumptions
used to formulate the model are not always obvious to
program users. These assumptions, and therefore the model,
must be proven valid prior to becoming available to the
user. Additionally, the results of a simulation analysis is
usually in the form of data which many users assume to be
real. For these reasons, the model and program must be
proven accurate.
63
64
9.1 VALIDATION AND VERIFICATION
Validation is the process of determining whether a
simulation model is an accurate representation of the actual
system [52]. It should be performed with respect to a
specified set of criteria derived from the model's purpose
of development [ 90]. There are three categories of model
validity; technical, operational, and dynamic [29].
Technical validity refers to the identification of all model
assumptions and their divergence from reality. It is
additionally concerned with model input data, its accuracy,
impartiality, and representativeness. The importance of
errors and divergences from reality are assessed as
operational validity. This assists in placing the analysis
output in the proper perspective with the real world system.
Dynamic validity is concerned with the review and updating
of the model so that it continues to be an acceptable system
representation.
Verification is concerned with determining whether a
simulation program performs as expected [52]. Program
debugging is a prime consideration in verification, ensuring
that the program is error free. The degree to which program
output conforms to observed data may be verified utilizing
either historical or forecasted data.
65
9.2 THE ROLE OF THE SIMULATION LANGUAGE
The simulation language utilized
should be capable of reducing the
validation and verification of the
for model translation
effort required for
simulation model and
program, respectively. This is possible through the
features common to simulation languages which aid in model
formulation and program development.
9.2.1 Model Validation
The compatability of the chosen model type and the
simulation language will directly affect model validity. On
the basis of the analysis objectives, the analyst views the
system in a particular manner. The model then represents
the system as the analyst perceives it. Accordingly, the
language ·should provide a translation of the model which
maintains these perceptions.
a system modeled utilizing
interaction approach, and
An obvious example is that of
a discrete event, process
subsequent model translation
utilizing a process oriented, discrete event simulation
language.
The type and availability of probability distributions
may also affect model validation. When formulating a
stochastic model, the analyst attempts to represent the
behavior of the random variables utilizing probability
distributions
The 1 anguage
distribution,
66
to represent the
should provide
insuring that
corresponding
desired
input data.
probability any
the model input data is
accurately represented.
The accuracy of digital compµter continuous model
simulation is extremely dependent on the numerical
integration technique utilized by the simulation language.
The integration technique(s) provided by a simulation
language may pose restrictions upon the order and nature of
the model's defining equations, influencing model
validation.
will occur
limitations
These errors
Numerical approximation or truncation errors
during program
of the particular
execution due to inherent
configuration.
integration algorithm [ 49] .
of the computer's digital
occur due to the finite
arise regardless
Roundoff errors
precision arithmetic calculations, and increase in
seriousness with integration time, integration rule order,
and with decreasing step size [ 13, 49] . These errors will
affect the computer output data, thus influencing model
validity.
67
9.2.2 Program Verification
Simulation languages provide
assist in program verification.
several techniques which
Languages which facilitate
modular development are easier to debug as this may be done
on a step by step, modular basis (52]. Many languages offer
special debugging capabilities. These may be selective or
switchable, and may refer to a user written source program,
or a processor generated target program [66]. Additionally,
the debugging facilities may be operational during compile
time or execution time. The familiarity of the analyst with
the facilities offered by the language is a prime factor
when considering the time spent debugging a simulation
program.
The availability and communicability of diagnostic error
printouts or 'displays is also important to program
verification. Additional assistance is provided by the
production of translator and/or compiler output listings and
memory maps [ 49). These messages result from the illegal
use of symbols or expressions and may be generated by the
translator or subsequent language processors [49). The
production of translator and/or compiler output listings and
memory maps will assist in error identification.
Several researchers suggest that each path through the
program be executed to ensure that it terminates, and that
68
the expected path output is produced_[43,61]. Of particular
use to simulation program verification is the language's
ability to provide a system trace. Tracing is a procedure
by which the system state, as represented by the values of
state variables, the contents of the event list, statistical
counters, etc., is specified following the occurrence of
each event [ 62] . Certain languages provide a graphical
display of the simulation output as the simulation
progresses which will also assist in verifying correct
program operation.
Another important aspect of verification, and of
validation, is the performance of statistical tests on
program output. These tests include tests of means and
variances, analysis of variances, regression factor
analysis, auto correlation, chi square tests, and others
[85]. Several languages have corresponding packages for the
accomplishment of these statistical tests. The language
should provide outpu_t data which is required for the tests
that the analyst chooses to perform, facilitating
statistical verification of the program.
Chapter 10
PROGRAM EXPERIMENTATION
Once the simulation program has been verified, it may be
used to investigate system behavior through experimentation.
The design of computer simulation experiments has been
researched by various authors and the reader is referred to
these publications for an indepth examination
[13,19,33,52,61,77,86,88,93].
Several simulation language features are capable of
assisting the analyst in experimentation. The user- system
communication aspects of the simulation language may provide
for computer assisted or on-line experimentation [66].
Algorithmic manipulation of experimentation specifications
has been recently proposed.
The displaying of simulation results is also important to
experimentation. The ability of the language to easily and
efficiently provide user required data is crucial to the
analysis. This would include plotting, either contour or
va~iable shade plots, and the production of tabularized
output reports.
response curves
Graphics units are available for displaying
or surfaces with color and shading
capabilities [66]. Research is currently being conducted in
the areas of on-line plotting concerning perspective,
69
70
projection, zooming, and rotation of the response surface.
In addition holographic techniques are available in some
existing sophisticated simulation languages (53).
The incorporation of optimization techniques simplifies
the optimization of simulation results. These techniques
may also be provided through an associated language package.
Simulation languages offer a wide range of experimental
control capabilities including user specified initial
conditions, sampling procedures, run length, batch size, and
estimation procedures (77).
Chapter 11
INTERPRETATION AND APPLICATION OF RESULTS
The final phase of the simulation analysis procedure is
primarily concerned with the fullfillment of the analysis
objectives. The simulation model and program have been used
to investigate system behavior during the previous step.
The results of these experiments must now be interpreted by
the analyst. The conclusions, theories, and decisions
formulated by the analyst are then applied to the real world
system.
Most researchers feel that the simulation analysis
procedure is not complete until the results have been
successfully applied, and the analysis objectives have been
satisfied [33,43,77,86]. It is believed that the success of
the re.sul ts implementation is largely dependent upon the
accomplishment of the previous steps. This analysis step
emphasizes the need for an easily understandable output data
format. It should be of a form which facilitates
application to the real system acknowledging that the model
may be utilized by those other than the original analyst.
The use of terms and notations familiar to eventual users is
a means of facilitating interpretation and analysis.
Program documentation abilities are also important at this
step.
71
PART III
LANGUAGE REVIEWS
The following chapter contains brief summaries of
selected, currently available simulation languages. Where
possible, certain languages have been grouped together and
discussed due to their similarities' of purpose.
72
12.1
(43]
Chapter 12
LANGUAGE REVIEWS
PARTIAL DIFFERENTIAL EQUATION LANGUAGES
Certain scientific and engineering continuous models
utilize partial
description. The
differential
solution of
equations in their
these equations
system
requires
particular numerical techniques not found in all continuous
simulation languages, and the result is a subclass of these
languages which have been specifically developed for the
simulation of continuous models involving .partial
differential equations. These languages are capable of
solving equations which are elliptical, parabolic,
hyperbolic, and/or biharmonic equations in one, two, and
three space dimensions.
The majority of the partial differential equation
languages are fourth level languages, the associated third
level language being FORTRAN. The most common are:
1. PDEL
2. LEANS I I I
3. DSS/2
4. PDELAN
5. FORSIM IV
73
6. ITPACK
7. LINPACK
8. ELLPACK
12.2 SIMULATION PROGRAMS
(63,89]
74
System's simulation analysis has been facilitated by the
use of "canned" programs. In general, these programs
provide a methodology for the analysis. They require the
user to complete standardized forms providing specific items
of information regarding system operation. This data is
then processed by the canned program resulting in a
simulation analysis of the system. Therefore these programs
are not simulation languages. However, they are tool for
computer simulation analysis, and several are available
specifically for transportation systems. Examples are
described below.
TRANSIM
This is a general purpose method of approach for computer
simulation analysis of transportation systems. The user is
required to model a system in terms of traffic uni ts and
system operating elements. Traffic units are considered to
be anything that flows thru a system including vehicles,
freight, and people. System operating elements are any
75
facility that services or processes the traffic units. The
user provided input data is classified as follows;
1. System physical plant and process data describes the
identification and arrangement of system operating
elements.
2. System traffic data describes the arrival of traffic
units at system operating elements.
3. System operating rules describe the operating
rules, dispatch schedules, work schedules, routing
rules, and maintenance and repair rules.
4. Operating elements performance data is the specific
information regarding the performance characteristics
of the individual system operating elements.
The standard input forms require that this information be
presented in a particular manner. TRANSIM does not require
the user to learn any special vocabulary or definitions. It
facilitates a modular approach to model building. The
operational aspects include
mechanism, ana a Monte Carlo
an
type
event oriented timing
simulator. TRANSIM is
available for the IBM 7090/7094 series computers.
BELTSIM
BELTSIM is a digital computer program which was developed
to eliminate the necessity for estimates which are used to
determine the design data for belt conveyor systems. These
estimates relate to the
belt conveyor system,
76
operational characteristics
and include peak. loading
of a
and
probability of overloading variables. The program
mathematically dumps a shuttle carload of coal arid traces
its path thru a user described belt network. Interactions
between loads, spillage, belt stoppages, and transfers are
noted, providing a quantitative measure of the performance
of a belt network.
The program input data is classified as follows;
1. Shuttle car discharge data including time between
dumps, payloads, and dumptimes.
2. Belt network data including lengths, speeds, and
capacities.
3. Mining practice data including shift length,
travel-in and out times, and break policies.
12.3
[35)
CSMP II I
CSMP III is the most recent version of the original
Continuous ~ystem ~odeling frogram language developed by
IBM. It is a problem oriented language and is capable of
representing models which are either expression or block
oriented descriptions of systems.
available for program formulation,
Three statement types are
the actual input order
77
not affecting program execution. Structure statements are
ordinary differential equations which describe the
functional relations between model variables. The
specification of initial conditions and the assignment of
numerical values to parameters is achieved with data
statements. Control statements are used to specify data
output and program execution steps. The language allows
user defined macros and the development of user subprograms.
All variables are treated as real numbers and double
precision arithmetic is available.
CSMP I I I is a fourth level language with an associated
preprocessor which produces a FORTRAN program for
compilation and execution. All FORTRAN library functions
are available to the CSMP III programmer in addition to the
CSMP I I I library which contains standard analog computer
functions. A total of eight integration algorithms, both
fixed and variable step, are incorporated including
provisions for one that is user specified. A stiff
differential equation algorithm is also included. Output
reports may be tabular or printer plots, and a graphics
package is available for the IBM 2250. CSMP III is not
recommended for large models but it has been used to
simulate combinational and sequential logic circuits.
78
12. 4
[ 7]
DEMOS
DEMOS is a discrete event simulation package created as a
subset of SIMULA, the name reflecting that it is a system
for discrete event ~odeling on SIMULA. The actual statement
structure is consistent with the forms proposed by SIMULA.
DEMOS simplifies the simulation aspects of SIMULA by
providing a small set of blocks which facilitate a
standardized approach to a wide range of simulation models.
As such, DEMOS permits program formulation with SIMULA
without requiring detailed knowledge of the non-simulation
aspects of the parent language. The language describes
discrete event models using entities to represent major
model dynamic components. These entities may compete for
resources and interact with each other. The user must also
provide information pertaining to the life cycle of the
entities, indicating the activities they engage in.
DEMOS incorporates nine random sampling facilities in
addition to mechanisms for event scheduling, data
collection,
possible as
implemented
compiler.
systems.
and output report generation. Event tracing is
an aid in validation and debugging. DEMOS is
in a SIMULA context and utilizes a SIMULA
The language has been used to model industrial
12.5
[38]
DISCO
79
DISCO is a SIMULA based simulation language capable of
representing and analyzing models involving both discrete
and continuous processes. The language describes continuous
processes as those which experience active phases during
time intervals, causing continuous state changes. Discrete
processes experience events, which are instantaneous active
phases, causing discrete changes in state. The processes
are otherwise inactive. The model is therefore described as
a collection of processes which undergo active and inactive
phases, and which act and interact to represent the system
behavior. The actual statement structure is consistent with
the forms proposed by SIMULA. Continuous processes may be
described by differential or difference equations. Discrete
processes operate in quasi-parallel, meaning that
simultaneous, concurrent events are executed. in a user
specified order. DISCO permits dynamic starting and
stopping of continuous processes, thus the equations
describing them may be altered during the simulation.
DISCO offers six integration methods which may be chosen
from at any time during the simulation, the default being
the fourth-order Runge-Kutta-England variable step size
algorithm. Additional software features include facilities
80
for solving higher order differential equations, ideal and
exponential delays, and tabulated functions.
12. 6
[82]
DYNAMO
DYNAMO is a continuous simulation language developed to
formulate programs for a particular model type known· as a
system dynamics model. It is a compiler language which
utilizes three equation types to describe dynamic models,
with statement order being irrelevant to program
formulation. Level equations represent state variables and
describe the system state at any particular point in time.
Output variables are described by rate equations which
depict state changes as time passes. The functions of the
rate equations are completely described by the third
equation type known as auxilliary equations. These are
components of the rate equations and represent feedback
control, facilitating analysis of feedback systems. All of
the equations are nonlinear, first order difference
equations, and the simulation is accomplished through their
simultaneous solution.
DYNAMO has macro capabilities and provides special output
features for plotting and printing data. The language
incorporates special mathematical and statistical
81
computational facilities, and utilizes the Euhler, fixed
step integration mechanism. This makes it particularly
applicable for representing discrete time, continuous
models. Examples include large, disaggregated models in
health care management,
economic's.
corporate policy making, and
12.7 GASP IV
[52,73,75,76]
GASP IV, the general ~ctivity §imulation frogram IV is a
combined discrete/continuous simulation language developed
as an extension of the discrete simulation language GASP II.
The language consists of more than 30 subroutines and
functions for performing required simulation activities. A
simulation program utilizing this language consists of a
user written portion and a portion provided by the system.
The user must specify the conditions which require an event
occurrence and the associated system changes. Two types of
events are distingushed by the user. Time events are those
that occur at specified times. State events are those which
are not scheduled and occur when particular system
conditions are met. The attributes of system entities may
be classified as discrete or continuous, depending on the
manner in which their values change. Continuous attributes
82
may also be referred to as state variables. The system
behavior is simulated by computing the values of the state
variables at small time increments, and computing the values
of discrete attributes at event times.
GASP IV is FORTRAN based and incorporates
time advance mechanism. The language
Runge-Kutta-England integration algori thrn for
a next event
utilizes the
solving sets
of simultaneous, first order differential equations. Higher
order equations may be represented through conversion to
canonical form, and difference equations may be directly
utilized. The language incorporates subroutines for the
collection of system data, performance of statistical
computations, and output report generation. Random variable
generation is possible from eight common distributions
including one that is user specified. GASP IV requires
approximately 20K words of computer storage.
GASP IV/E is an interactive version of GASP IV,
permitting data to be displayed during program execution.
GASP V is an extension of GASP IV which incorporates
additional
solution of
integration algorithms,
partial differential
and procedures
equations, as well
additional memory, logic, and generator functions.
for
as
12.8 GPSS
(5,64,84,52,86]
83
There are several versions of GPSS currently available.
The language was originally developed by IBM Corporation and
their current versions are GPSS/360 and GPSS V. All
previous IBM versions are obsolete, and GPSS Vis a superset
of GPSS/360. This summary_ considers the mechanics of these
versions and may be applied only generally to other
versions, which include GPSS, GPSS/H, and GPSSTS.
GPSS V (Qeneral ~urpose Simulation §ystem V) is a
process oriented simulation language designed specifically
for simulating discrete event models. The language
incorporates over forty-five statements with · corresponding
pictorial representations called blocks. A logical
representation of the model is constructed by combining the
standard blocks into a block diagram representing the path
of a process. The sequence of activities describing model
behavior are simulated by the block to block movement of
transactions. The transactions represent entities which
move through the system, and a block to block move is
labelled an event. Individual transactions cannot be
numbered, thus the parameters of one transaction are not
readily available to others. Once the block diagram has
been formulated, it is translated into equivalent GPSS V
84
statements for interpretation and execution by the GPSS V
processor. The language utilizes a next event time advance
mechanism, and the basic unit of time is user specified for
an integer valued clock.
GPSS V is written in assembly language and is
particularly oriented toward queuing systems. Complicated
numerical calculations and special output reports require
the use of a general purpose language to construct user
subroutines which may be interfaced with the GPSS V program.
The language has no exact facilities for random variable
generation, requiring the user to approximate the inverse of
the distribution function by a sequence of straight line
segments. GPSS V contains
report generation, and
debugging.
standard subroutines for output
comprehensive diagnostics for
12.9 GSL
[30]
GSL the Generalized Simulation 1anguage
language discrete/continuous
representing either
simulation
discrete, continuous,
is a combined
capable of
or combined
models.
oriented,
The language permits construction of event
block diagram, or procedural language based
simulations comparable to GPSS, GASP IV, and SIMULA,
85
re spec ti vely. A GSL program consists of blocks which each
describe a basic process, and are composed of a process
description and a data description. The process description
characterizes either the differential or difference
equations which specify continuous system state changes.
Additionally, continuous descriptions may be imbedded within
a discrete block. An executable copy of the simulation
block is known as a process instance and is analogous to a
GPSS transaction. Several process instances may be
associated with each process description. A data
description specifies the entities' attributes for each
process instance of the associated process description.
Thus the sole function of each simulation block is the
definition of each data structure, providing a set of
instructions for operations on that structure. GSL utilizes
macro-oriented procedural sections for the representation of
special purpose operators. A GSL program simulates a system
through creation, execution, and manipulation of discrete
and continuous process instances.
GSL is a FORTRAN based simulation language. I ts
translator is constructed in ALGOL and generates FORTRAN
programs which facilitates use of optimizing FORTRAN
compilers. Dynamic storage allocation during simulation is
incorporated.
12 .10
[58]
REPLICAS
86
REPLICAS is a FORTRAN based continuous system simulation
language. The language structure permits the model to be
represented by first order differential equations utilizing
a predefined statement type. The arguments of these
equations specify the system state, and conventional FORTRAN
arithmetic expressions and trigonometric functions may be
used in their construction. Additional statement types are
available for describing discontinuous or discretely defined
functions. Conditional and alternative calculations of
certain variables which are part of the model description
are al°so represented by a preset statement type, and a
generalized limiting function is included. Keywords are
used to categorize the program statements in terms of the
mathematical model itself, its forcing functions or
disturbances, and its design specifications. For example,
the length of time required to observe an event is
considered a forcing function, and design specifications
can, for the occurrence of a given condition, require that a
certain parameter assume a particular value. The simulation
program is a model translation utilizing these specified
statement types. The statement input order is irrelevant.
87
REPLICAS incorporates the Gear algorithm for evaluation
of differential equations by either the integral or
differential method. The processor utilizes a fixed
increment time advance mechanism, and incorporates the use
of a nonlinear constrained optimization facility. At the
present time REPLICAS is relatively untested. However, it
has been proposed for the analysis of general engineering,
scientific, and econometric simulation model.s.
12.11
[ 71 l
SIMAN
SIMAN is a recently developed simulation language capable
of performing simulation analysis of discrete, continuous,
and combined discrete/continuous models. Discrete models
may be described utilizing either a process interaction
approach, and/or an event scheduling approach.
interaction approach permits the user to
The process
represent the
model's functional operations with a block diagram. The
diagram may be constructed using an interact·i ve or batch
mode. The interactive mode permits graphic diagram
construction on a computer and incorporates real time error
checking. The batch mode permits diagram construction as a
form of batch statement input. The event scheduling
orientation involves a set of user written FORTRAN
88
subroutines consisting of mathematical/logical expressions.
These subroutines are used to describe instantaneous state
changes which occur at event times. Continuous models may
be described by algebraic, difference, and/or differential
equations. Numerical integration is automatically performed
when required.
The system operation is represented by entities which
flow through the block diagram. The entities may be
individualized through the assignment of attributes which
characterize them. The pattern of entity flow may be
sequential or non-sequential as desired. Three distinct
event types are permitted. Block events occur due to the
arrival of an entity to a block. Time events are those
which have been scheduled to occur. State events occur when
a continuous variable crosses a prescribed threshold. The
language incorporates special features for modeling material
handling systems which include industrial trucks, cranes,
hoists, manipulators, and conveyors.
SIMAN is a FORTRAN based simulation language and is
designed for use on minicomputers, and sixteen bit
micro-computers as well as large computer mainframes. The
language incorporates a well developed subprogram library
for required simulation functions such as event scheduling,
file manipulation, and data collection. Data analysis and
89
display occur
facilitate the
separately from program execution and
generation of plots, tables, barcharts,
histograms, correlograms, and fi 1 tered data sets. It is
also possible to create output which is formatted for direct
input . to the Tektronix Plot 10 Easy Graphing Software.
Random sample generation is provided for from fourteen
distributions, both theoretical and user specified.
12.12 SIMSCRIPT II.5
(11,52,86)
SIMSCRIPT II.5 is the current version of a general
purpose language which incorporates specialized capabilities
that facilitate the development of discrete event simulation
programs. The language is primarily event oriented with
limited process interaction techniques. The system state is
completely described by the attribute values of system
entities. Changes in these values occur at discrete points
in time known as event times, and the language utilizes a
next event time advance mechanism. SIMSCRIPT II.5 is
statement oriented, utilizing free form input which can be
learned and used at varying levels of sophistication, these
being;
Level One: Language statements comparable to BASIC,
introduction of programming concepts of a
simple algorithmic language.
Level Two:
90
Comparable in power
capabilities include
to FORTRAN, additional
report generators and
increased data structure abilities.
Level Three: Inclusion of ALGOL type statements.
Level Four: Incorporation of a structure for representating
entities, attributes, and sets or collections
of entities.
Level Five: Inclusion of provisions for timekeeping, sample
generating organizing of subprograms for
representing of system activities, and data
accumulation and analysis.
SIMSCRIPT II.5 is one of the few languages with an
associated package for performing statistical analysis of
simulation output data. Either continuous or combined
discrete/continuous models may be analyzed utilizing an
extension of the language known as C-SIMSCRIPT. Routines
are provided for random sampling from eleven probability
distributions, and complete user control of statistics
collection is permitted.
12.13 SIMULA
[5,8,27,40]
91
SIMULA is a general purpose language with special
features which facilitate discrete simulation. It was
developed as
the language
an
as
extension of ALGOL 60,
a subset. SIMULA is
actually including
process oriented,
describing a process as a combination of a data structure
and an operation rule. A data structure defines the
properties of the process. The operation rule specifies the
actions to be taken and is composed of events which occur at
a particular point in time. SIMULA has the ability to
create, destroy, and modify all existing or new processes,
and incorporates a common data file which can be accessed by
all processes.
The language identifies a process class as a group of
processes with similar data structures and operation rules
but which differ in their attribute values relative to the
data structure.
achieved within
The definition of a process class is
a block, which is an independent,
self-contained struct~re,
unit. A block may be
aggregated data structure
and SIMULA's fundamental program
regarded as a description of an
and the actions which the block
statements define.
instance is created.
As each block is executed, a block
A SIMULA program consists of a set of
blocks which
sequence of
instances.
92
organize the overall program execution as a
active phases related to various block
Special statements are supplied for postponing
actions or for rendering the entire process inactive.
SIMULA permits random sampling from five common
distributions and incorporates routines for statistics
collection. Language extension capabilities allow
formulation of special, problem oriented language features,
and it is possible to edit standard output reports.
Computer availability for SIMULA is restricted within the
United States due to the limited usage of ALGOL 60 upon
which the SIMULA lamguage is based. SIMULA has been used to
analyze small material handling train circuits within
factories.
12.14 SLAM
[72,77]
SLAM, the ~imulation ~anguage for ~lternative ~odeling is
capable of representing a discrete event model utilizing an
event scheduling, process interaction, or activity scanning
approach, or any combination of these. The language can
also represent a continuous model using either differential
or difference equations. The discrete event and continuous
aspects of SLAM were derived from GASP IV in which the
93
analyst describes events and system changes resulting from
their occurrence, or specifies equations for the dynamic
behavior of state variables, respectively. The process
interaction (network) aspects were derived from Q-GERT.
Nodes and branches are employed to construct a network which
pictorially models the elements of a process such as queues,
servers, and decision points. The network is then
translated into an equivalent statement form for computer
execution. SLAM has the additional capability of combining
its discrete event and continuous aspects for the
representation of combined discrete/continuous models.
SLAM is FORTRAN based and is therefore available for all
computers with FORTRAN compilers. The processor requires
28k decimal words for storage. The language incorporates a
set of standard subroutines for common simulation functions
including event scheduling,
manipulation, and output
statistics collection, file
report generation, including
histograms. Event tracing is possible as an aid in
validation and debugging. Random sample generation is
possible from eight common distributions, including
provisions for sampling from one that is user specified.
The integration method utilized is the Runge-Kutta-Fehlberg
fourth order algorithm which is a variable step size routine
for ordinary differential equations with initial values. A
94
decision optimization module for SLAM has been developed and
on-line network graphical construction is currently being
investigated.
12 .15
[87]
SMOOTH
SMOOTH is a combined discrete/continuous simulation
language developed from extending GERT network philosophy
for application to combined models. Continuous simulation
concepts are embodied in state networks which consist of
nodes and branches. The nodes are used to represent the
values of continuous system variables, called node values.
Branches represent the node's input and output and are
described by branch rates which are a function affecting the
associated nodal values. Five equation forms are available
for defining the rate equation's coefficients and exponents.
SMOOTH has the capability for network modification as a
function of system state. GERT network concepts are
employed for discrete event models. The discrete aspects of
the model are described by a nodal system representing
intersections for starting and stopping activities, and
branches representing activities. The simulation of a
discrete/continuous model is thus described by a pair of
interrelated networks, specified by numerical information,
which the SMOOTH computer program analyzes using simulation.
SMOOTH
specified
automatically
nodes, and
95
obtains
histograms
statistical
may be
data for
obtained.
Statistical nodes gather activity related statistics. The
language is FORTRAN based and incorporates standard routines
for the generation of random numbers, and output reports.
12.16 SUMMARY
Table 8 is a comparison table. It permits several of the
simulation languages previously described to be compared on
the basis of various language parameters. Table 8 does not
provide any additional information which is not already
contained in the particular language
gathers pertinent data and presents
concise manner.
summary.
it in a
It merely
logical and
96
TABLE 8
Language Canparisons
Current CSMP III DISCO DYNAM) GASP N GPSS V Version
Object FORTRAN AI..C,OL Asse:nbly FORTRAN Asse:nbly Language PL/1
Discrete YES NO YES YES Facilities
Discrete Process Next Process Perspective Interaction Event Interaction
Continuous YES YES YES Facilities
Equation A C B C Type
Integration 8 6 Euhler Rtmge:-Algorithm '- Fixed Kutta-
Step England
Combined NO YES NO YES Facilities
Timing Fixed Combined Fixed Next Next Mechanism Incranent Incranent Event Event
Output YES YES YES YES Facilities
Rand.cm X X X 8 Variable Generation
A indicates differential equations B indicates difference equations C indicates both differential and difference equations X indicates that the information was not available
97
TABLE 8 con't
L:mguage O:,mparisons
Current REPLICAS SJMIJI.A Sil1SCRIPI' SIMAN SI.AM Version II.5
Object FORTRAN AI.roL 60 Assanbly FORTRAN FORTRAN Language
Discrete YES YES YES YES Facilities
Next Activity Activity Discrete Process Event and Scanning, Scanning, Perspective Interaction Process Next Next
Event and Event and Interaction Process Process Continuous Interaction Interaction Facilities YES N) YES YES
Equation B C C Type
Integration Gear Runge- Runge-Kutta- Kutta-Algorithm Algorithm England 5 England 4
Combined YES YES Facilities
Timing Fixed Next Next Combined Combined Mechanism Increment Event Event
Output X YES YES YES YES Facilities
Random X 5 11 14 8 Variable Generation
PART IV
BULK MATERIAL TRANSPORTATION SYSTEMS
98
Chapter 13
BULK MATERIAL TRANSPORTATION SYSTEMS
A bulk material transportation system is a system which
provides for the movement of a bulk material from one place
to another. For the purpose of this research the
distinction between transportation and material handling
systems for bulk materials shall be made as follows;
1. A bulk material transportation system begins at a
terminal or other facility where the material may be
accumulated into desired quantities for movement.
2. The material is loaded into a carrier ( s) by
facilities which may be described
from thorough mechanical detail
in terms ranging
to more simple
descriptions in terms of loading rates.
3. The material is transported within, or on the carrier
to its destination. It may encounter delays at
interim terminals or facilities for modal change,
accumulation, or separation of material(s).
4. The transportation system ends where the material may
be removed from the carrier for subsequent use.
Material handling systems may exist at the origin,
interim facilities, or destination facilities. They are
utilized for the movement of material prior to its original
99
100
loading and after it has been removed from a carrier at its
destination.
destination,
The use of the generic terms, origin and
permits the analyst to define the
transportation system as desired. For example an analyst
may define a coal transportation system as beginning at a
mine in the United States, and ending at an overseas
facility where the coal will serve as fuel. However it is
also possible to define the destination point as being any
of the numerous interim facilities through which the
material passes, such as a port facility, or a train
classification yard. In this manner, the operations at such
a facility are now considered to be material hapdling and
may be eliminated from the transportation system analysis.
Transportation systems may be decomposed in this manner
to any required size. They are limited only in growth
potential. A simple system will consist of a single
material being transported by a single carrier between two
terminals. However, it is possible for a bulk material
transportation system to incorporate more than one of any of
these features.
Bulk materials are a classification of materials which
possess many similar transportation-oriented
characteristics. Chapter 14 presents a detailed description
of bulk materials and their properties, as well as examples.
101
The bulk material is the object which the transportation
system moves.
The transportation medium is a term which describes how
the material travels. For thi~ research, the various
mediums include rails, water (both ocean and inland waters),
roads and other land surfaces, pipes, and the supporting
structures within conveyor systems. Generally speaking, the
material carrier utilizes the medium for movement, following
and being guided by, the pathway it creates. For example,
due to the nature of inland waterways, their traffic must
follow the fixed route which the waterways define. It is
also possible for the transportation medium to provide power
for movement as is with water or electrified rails. Certain
characteristics of the transportation medium will influence
carrier movement. These qualities are typically physical in
nature, and examples include road surface conditions, or
water levels.
The remaining physical features of a bulk material
transportation system are the carriers and the terminals.
The carriers within these systems are also the containers
for the bulk material. Examples include railcars, barges,
and conveyor surfaces. The power for carrier movement may
exist as part of the carrier, as is with ocean bulk
carriers, or the power may be provided by a separate unit as
is with locomotives, towboats, and pipeline system pumps.
102
Terminal facilities within bulk material transportation
systems exist at the origin, ~estination, and at any number
of points within the system. They may serve as
consolidation or separation facilities for the material, or
to provide power, fuel, and other system necessities. They
may also represent intermodal facilities where the material
may change transportation modes. The operation of the
terminal may be described in any detail desired, keeping in
mind that they are portions of the overall transportation
system.
Following a description of bulk materials, the remaining
chapters of Part IV present descriptions of bulk material
transportation systems. The descriptions are given with
respect to the particular system features presented in this
chapter, these being the material, the medium, the carriers
and terminals. The operational characteristics of each
system are examined, as well as any special features which
they may contain.
It should be noted that these system descriptions are not
detailed. It is not necessary or desired at this time to
describe them in any manner other than through a general
overview of their physical and operational characteristics.
The nature of the functional specifications presented in
Part V does not require system descriptions of any greater
depth than is given.
Chapter 14
BULK MATERIALS
According to Kneiling, bulk materials are any type of
freight which is transported without packaging [46).
Although this is true, there are many other unique
characteristics exhibited by bulk materials which distingush
them from other types of freight. It is more advantageous
to rely upon a description of these attributes rather than
any set definition as to what a bulk material is.
A bulk material may be of any physical form, either
solid, liquid, or gas. Regardless of this form, certain
features are commonly evident. A bulk material is
transported in a container into which it is loaded without
packaging. Examples of these containers include railcars,
tanker trailers, and barges. Additionally, bulk materials
tend to assume the shape of their carrier. The carriers
often require cleaning or inspection if it is desired to
transport varying material types.
A property normally associated with liquids or gases is
that they assume the shape of their container. However bulk
materials typically exhibit fluid-like properties. They
flow and can be poured as a means of loading or unloading.
Loading and unloading rates are usually expressed as volume
103
104
or wieght per unit time. The
referred to in terms of volume or
amassed
weight.
quantities are
Bulk materials
are generally transported in "large" quantities. For
example, a unit train may convey as much as 100,000 tons of
coal. This is an extremely large quantity particularly when
related to a small, individual lump of coal. Similarly,
many liquids are moved in thousands-of-gallons quantities.
In this manner, the term bulk material implies that the
material is transported in bulk, or large amounts.
Solid bulk materials, or bulk solids, have certain
distingushing characteristics which are not directly
applicable to liquids or gases. A bulk solid consists of
particles so small in comparison to the total amount that it
can be regarded as a continuous mass [17). They are
sub-classified in a number of ways, most usually in terms of
particle size which may range from a fine powder to a broken
solid. Commonly referred to properties of bulk solids
include; cohesiveness, adhesiveness, particle size, and
particle composition. Table 9 contains a listing of these
and other properties ( and definitions) which are used in
describing and classifying bulk solids. Examples of bulk
solid materials are also given in Table 9.
Non-solid bulk materials include liquids and gases which
typically possess fluid properties. These materials exhibit
105
TABLE 9
Examples of Bulk Solids and Their Properties
Bulk Solids
Broken stone Coal Coke Copra Fertilizers
Grain -barley -maize -rye -wheat
Bulk Solids Properties
Gravel Oil cakes Ores -barytes -bauxite
-chrome -copper -iron -manganese -zinc
Phosphates Salt Sand Sugar Sulfur
Adhesion-the tendency for the material to adhere or stick to other surfaces.
Angle of repose-the angle to horizontal which the free surface of the materiaL, formed in a heap and at rest, assumes.
Bulk density-the weight per unit volume of many material particles.
Cohesion-the tendency for the material particles tb stick to each other.
Friability-the ease with which the material may be broken into smaller particles.
Hardness-the amount of single particle resistance to scratching, cutting, wearing, abrading, etc ..
Moisture content-the ratio of water weight to material weight within a give~ amount of material.
Particle size analysis-the size of particles, the size distribution, and the particle shapes.
Specific gravity-the ratio of the weight in air of a given volume of material to the weight in air of an equal volume of water.
Additional Properties abrasiveness slide aeration surcharge angle of internal friction angle of external friction
References [6,9,28]
angle of segregation angle of specific weight compaction tackiness corrosiveness toxicity
106
common fluid characteristics such as viscosity, elasticity,
specific gravity, and surface tension [79]. A detailed
presentation of these and other properties may be found in
any fluid mechanics text. Non-solid bulk materials are
typically transported in homogeneous form. Examples of
these materials are given in Table 10.
Bulk materials are more often "natural"
opposed to being manufactured. Liberal use
products as
of the word
natural permits inclusion of refined or processed materials.
For example, certain grains may be subjected to various
harvesting and refining processes. However, they are still
a natural material as opposed to a manufactured product such
as bread or beer. Bulk materials are typically transported
by water, rail, and highway. They are seldom transported by
air. Additionally, transportation and material handling
costs usually represent a signifigant portion of their final
value [69].
107
TABLE 10
Examples of Non-solid Bulk Materials
Chemicals Latex Liquid natural gas Liquid petroleum gas
Bulk Liquids Properties
Oil -fuel
Petroleum Refined petroleum
-crude Wines -lubricating -diesel -vegetable
Elasticity - this property is related to the amount of deformation (expansion or compression) for a given pressure change.
Internal energy - the energy a substance possesses because of its state of molecular activity.
Mass density - the mass per unit volume. Specific heat - the amount of heat that must be transferred
to a unit mass of a substance to raise its temperature by one degree.
Specific weight - the gravitational force per unit volume. Surface tension - the magnitude·per unit length of the
"tension" exerted by the liquid surface upon adjacent portions of the surface or upon other objects which are in contact with the liquid.
Additional Properties critical velocity turbulent friction disposition velocity fluid drag friction velocity turbulent flow
References [79,91]
heterogeneous suspension transition velocity homogeneous suspension laminar flow laminar friction
Chapter 15
RAIL TRANSPORTATION SYSTEMS
A railway bulk material transportation system consists of
the train, the rails, and the terminal facilities. A train
may be further specified as being composed of a
locomotive(s) and any number of railcars for conveying bulk
materials.
There are over 190,000 miles of line-haul railways and
over 300,000 miles of track in the United States, not all of
which are traversed by bulk cargo. The tracks are
relatively fixed and often interact with other ground
supported transportation modes, resulting in limited route
flexibility. The rails signifigantly affect the movement of
the trains through terrain conditions which are reflected in
curves and grades, and through the physical condition of the
rails themselves [46].
A railcar is an unmanned cargo carrier which possesses no
mo.tive power. It exists as a unique entity, however several
may be coupled, end-to-end to form an entity which moves as
a single unit. Rai lcars vary in type, size, capacity, and
construction material, as well as in loading and unloading
characteristics. The average railcar has a capacity of 78.8
tons, resulting in typical train capacities of 2000 tons and
more [14].
108
109
More than sixty percent of the materials transported by
rai 1 are bulk in nature. For example, railroads transport
seventy-five percent of the total coal tonnage moved in the
United States, corresponding to nearly one-third of all rail
cargo. Additional materials such as metallic ores,
chemicals and allied products, and grain also totalled over
one million car loadings in 1979 [ 14). Rail transportation
typically dominates the market for transporting quantities
of 30,000 pounds or more, 300 miles or more.
Locomotives provide the power for railcar movement and do
not have cargo carrying capabilities. As with railcars,
locomotives vary in size and type, in addition to
horsepower. A train consists of one or more locomotives,
and one or more railcars coupled end to end. The
locomotives are typically attached to the front of a coupled
railcar unit, however they may be placed between railcars,
or at the end of a train as needed.
A train may typically carry several types of bulk
materials, the primary exception being a unit train. The
unit train service evolved from the rent-a-train concept for
the movement of goods [ 14] . Primarily introduced as a
service to the coal industry, these trains specialize in the
movement of a single material type from origin to
destination. Usually there are no in-transit stops, and
110
loading .and unloading may be accomplished while the train is
in motion. Regularly scheduled train movements are often
required. This feature coupled with the single material
characteristic results in empty backhauls. However this is
usually offset by the high revenue producing abilities of
the unit train.
A train moves as a single unit from one terminal to the
next, averaging fifty miles per hour travelling speed. The
line capacity of any particular track segment is dependent
primarily on the type of track and signalling system, and
the overall track configuration (46]. For example sidings
are utilized to permit traffic from opposing directions to
pass one another, or for one train to overtake another.
Terminal facilities vary, however the typical function
performed is the reorganization of incoming trains in
preparation for departure as outgoing trains, or the.
movement of a material from one transportation mode to
another. The terminal is usually composed of several yards
through which the rai lcars selectively pass. These yards
are characterized by a large number of tracks which cross
and switch within and between them. Railcars may be delayed
a variable length of time upon reaching the terminal
depending on when the material, or the carrier is required.
A typical example is the use of rail storage facilities at a
coal port facility.
111
Piggyback service was initiated in an attempt to increase
the level of service available to intermodal customers (14).
Piggyback is a general term which includes both
trailer-on-flatcar and container-on-flatcar (TOFC and COFC)
services. Piggybacking combines use of the line-haul
efficiencies of rail movement with the flexibility and
delivery speed of motor carriers.
TOFC service involves the movement, by rail, of fully
loaded highway trailers (54). Trucks are utilized to
locally pickup and deliver the trailers. COFC service
provides for movement of containers, also on railroad
flatcars (14]. Flatbed trucks are utilized for ramp to door
deliveries. COFC services are not typically utilized for
bulk material movement.
Chapter 16
INLAND WATER TRANSPORTATION SYSTEMS
The inland water system for bulk material transportation
consists of inland waterways, barges and towing vessels, and
terminal facilities.
The United States has nearly 25,000 miles of inland
waterways which are of sufficient depth for commercial
navigation [ 25 l . Although constantly changing due to
nature's forces, these waterways are, for the most part,
permanently fixed in location. Interacting with these
waterways is a system of locks, dams, and resevoirs. Dams
are utilized to maintain sufficient water depth by
regulating the flow of water in and out of resevoirs [42).
Locks permit passage of vessels from one pool of water to
another at a different water level. Inland water vessels
must utilize locks in their movement, incurring delays of
thirty minutes to one hour, or more. The dimensions of the
locks, and the waterways themselves, constrain the size of
carriers which may utilize them. These are generally
expressed in terms of length, width, and current depth.
Approximately eighty percent of the materials transported
by inland water carriers are bulk in nature. Examples
include coal, petroleum and petroleum products, grain, sand,
112
113
and gravel [42]. These materials are transported in
unmanned barges which are non-selfpropelled, and which vary
in size and type. As previously mentioned the barge
capacity is limited by the waterway depth, the standard
being approximately 1500 tons [24]. Barges are either
pushed or pulled by towboats, and move in groups or strings
[ 1 7 l .
A towboat coupled with one or more barges is called a tow
[ 42]. Towboats vary according to power provided and, as
with barges, the maximum size is restricted by both channel
depth and lock dimensions. Fleeting, or the creation of a
flotilla inv9lves lashing several barges together to form a
particular type of tow.
unit. Bulk material
involves time spent
The flotilla then moves as a single
inland water movement typically
loading and unloading barges,
assembling, breaking, and reassembling the tow, as well as
travel and local maneuvering time [34]. Fueling typically
occurs at midstream while the tow is underway. For passage
through locks the tow may require separation into groups of
sufficiently small size (usually 12 barges) to ensure safe
lock utilization. The average crew size for a flotilla is
from seven to fourteen persons who, for line-haul operation,
may only work six hours on prior to having six hours off.
114
Movement along inland waterways occurs between terminals
which are typically served by either rail or highway
systems. A terminal is a facility whose primary function is
the loading and unloading of inland water carriers. It may
be general or special purpose oriented with regard to
material type and loading/unloading facilities. Solid or
dry bulk materials are usually loaded utilizing conveyor or
spout type systems, resulting in flowrates of weight or
volume per unit time [42]. Clamshell cranes and clambuckets
are typically used for unloading resulting in rates of a
more discrete nature [ 24 l. Non-solid bulk materials
generally utilize a pipeline system for both loading and
unloading.
Terminals usually incorporate some type of storage I
facility due to the type of intermodal transfer which may
occur [ 56 l . This may involve large storage tanks,
sufficient rai 1 or other "parking" facilities, or open or
covered ground storage. The type and capacity directly
corresponds to the type and volume of material handled.
It should be noted that certain carriers described in
this chapter are also utilized to transport bulk materials
along intercoastal waterways. Additionally, certain inland
waterways permit passage of ocean-type bulk carriers. These
carriers are discussed in Chapter 17 as they exhibit
characteristics not unlike ocean vessels.
Chapter 17
OCEAN TRANSPORTATION SYSTEMS
The movement of bulk cargo by means of ocean
transportation is one of the most inexpensive bulk .carrier
modes available. This is primarily due to the extremely
large carriers utilized. Currently twenty-seven percent of
the world fleet serving the United States are designed for
the movement of bulk materials (14]. Ocean transportation
systems are composed of bulk carriers, oceans, and port or
land facilities.
Approximately
covered by
large bulk
oceans
seventy-five percent of the earth is
of sufficient depth to permit passage of
carriers [ 1 7 l .
between two ports is large,
at any time. In this
The number of available routes
and these may be easily altered
respect, ocean bulk material
transportation differs from the relatively fixed routes
characteristic of rail, pipe1ine, and highway systems.
The bulk carriers for ocean transportation are larger
than for any other mode presented, conveying between 10,000
and 100,000 tons. A bulk carrier is typically a single deck
vessel with from four to sixteen holds [ 6, 69] . It is a
vessel designed to carry various kinds of dry cargo in bulk
both efficiently and economically. They are classified
115
116
loosely according to material as they tend to be specialized
vessels. The primary classifications are ore, ore/oil,
ore/bulk/oil, and general purpose bulk carriers. The bulk
category includes sugar, salt, coal, grain, and copra.
Tankers are utilized for non-solid bulk movement and are
specially designed for quick loading and unloading [9]. A
300,000 ton tanker may have seven or more tanks for
conveying oil, petroleum, fuel oil, and other bulk liquids.
A port is a harbor which shelters marine terminal
facilities in addition to providing piers or wharves for
ship berthing during loading and unloading [92]. The
carrier may utilize port facilities, or it may discharge its
cargo onto smaller vessels or to an artificial island [17].
The port incorporates storage facilities for both incoming
and outgoing materials. Ports serve as transfer terminals,
permitting the switching of cargo to a land or inland
transportation mode. The loading and unloading facilities
are designed for the particular type of material handled.
Tankers typically utilize pipelines while dry bulks may use
a gantry/conveyor system [69]. Some bulk carriers have
self-unloading capabilities.
Ocean bulk carriers transport materials between ports at
speeds from thirteen to sixteen knots [ 6] . The di stance
moved may be thousands of miles, and may require several
117
weeks in travel time. Bulk carriers are also utilized for
the movement of barges. LASH (lighter-aboard-ship) is the
name given to those carriers that transport barges which
have been loaded at some inland point and moved to the ocean
port via inland water movement. These carriers may convey
up to 73 barges containing various bulk materials.
It should be noted that several inland waterways, for
example the Great Lakes, permit passage of the type of
carriers described in this chapter. Additionally, although
the intercoastal waterways are part of the oceans, the
carriers which utilize them are of the type utilized on
inland waterways, and have been presented in that chapter.
Chapter 18
INLAND WATER TRANSPORTATION SYSTEMS
The inland water system for bulk material transportation
consists of inland waterways, barges and towing vessels, and
terminal facilities.
The United States has nearly 25,000 miles of inland
waterways which are of sufficient depth for commercial
navigation [ 25 l . Although constantly changing due to
nature's forces, these waterways are, for the most part,
permanently fixed in location. Interacting with these
waterways is a system of locks, dams, and resevo.i rs. Dams
are utilized to maintain
regulating the flow of water
sufficient water depth by
in and out of resevoirs [42].
Locks permit passage of vessels from one pool of water to
another at a different water level. Inland water vessels
must utilize locks in their movement, incurring delays of
thirty minutes to one hour, or more. The dimensions of the
locks, and the waterways themselves, constrain the size of
carriers which may utilize them. These are generally
expressed in terms of length, width, and current depth.
Approximately eighty percent of the materials transported
by inland water carriers are bulk in nature. Examples
include coal, petroleum and petroleum products, grain, sand,
118
119
and gravel [42]. These materials are transported in
unmanned barges which are non-selfpropelled, and which vary
in size and type. As previously mentioned the barge
capacity is limited by the waterway depth, the standard
being approximately 1500 tons [24]. Barges are either
pushed or pulled by towboats, and move in groups or strings
l 1 7 l .
A towboat coupled with one or more barges is called a tow
[ 42) . Towboats vary according to power provided and, as
with barges, the maximum size is restricted by both channel
depth and lock dimensions. Fleeting, or the creation of a
flotilla involves lashing several barges together to form a
particular type of tow.
unit. Bulk material
involves time spent
The flotilla then moves as a single
inland water movement typically
loading and unloading barges,
assembling, breaking, and reassembling the tow, as well as
travel and local maneuvering time (34]. Fueling typically
occurs at midstream while the tow is underway. For passage
through locks the tow may require separation into groups of
sufficiently small size (usually 12 barges) to ensure safe
lock utilization. The average crew size for a flotilla is
from seven to fourteen persons who, for line-haul operation,
may only work six hours on prior to having six hours off.
120
Movement along inland waterways occurs between terminals
which are typically served by either rail or highway
systems. A terminal is a facility whose primary function is
the loading and unloading of inland water carriers. It may
be general or special purpose oriented with
material type and loading/unloading facilities.
regard to
Solid or
dry bulk materials are usually loaded utilizing conveyor or
spout type systems, resulting in flowrates of weight or
volume per unit time (42]. Clamshell cranes and clambuckets
are typically used for unloading resulting in rates of a
more discrete nature (24]. Non-solid bulk materials
generally utilize a pipeline system for both loading and
unloading.
Terminals usually incorporate some type of storage
facility due to the type of intermodal transfer which may
occur (56]. This may involve large storage tanks,
sufficient rail or other "parking" facilities, or open or
covered ground storage. The type and capacity directly
corresponds to the type and volume of material handled.
It should be noted that certain carriers described in
this chapter are also utilized to transport bulk materials
along intercoastal waterways. Additionally, certain inland
waterways permit passage of ocean-type bulk carriers. These
carriers are discussed in Chapter 17 as they exhibit
characteristics not unlike ocean vessels.
Chapter 19
OCEAN TRANSPORTATION SYSTEMS
The movement of bulk cargo by means of ocean
transportation is one of the most inexpensive bulk carrier
modes available. This is primarily due to the extremely
large carriers utilized. Currently twenty-seven percent of
the world fleet serving the United States are designed for
the movement of bulk materials (14). Ocean transportation
systems are composed of bulk carriers, oceans, and port or
land facilities.
Approximately
covered by
large bulk
oceans
seventy-five percent of the earth is
of sufficient depth to permit passage of
carriers [ 1 7 l .
between two ports is large,
at any time. In this
The number of available routes
and these may be easily altered
respect, ocean bulk material
transportation di£fers from the relatively fixed routes
characteristic of rail, pipeline, and highway systems.
The bulk carriers for ocean transportation are larger
than for any other mode presented, conveying between 10,000
and 100,000 tons. A bulk carrier is typically a single deck
vessel with from four to sixteen holds [ 6, 69] . It is a
vessel designed to carry various kinds of dry cargo in bulk
both efficiently and economically. They are classified
121
122
loosely according to material as they tend to be specialized
vessels. The primary classifications are ore, ore/oil,
ore/bulk/oil, and general purpose bulk carriers. The bulk
category includes sugar, salt, coal, grain, and copra.
Tankers are utilized for non-solid bulk movement and are
specially designed for quick loading and unloading (9]. A
300,000 ton tanker may have seven or more tanks for
conveying oil, petroleum, fuel oil, and other bulk liquids.
A port is a harbor which shelters marine terminal
facilities in addition to providing piers or wharves for
ship berthing during loading arid unloading (92]. The
carrier may utilize port facilities, or it may discharge its
cargo onto smaller vessels or to an artificial island (17].
The port incorporates storage facilities for both incoming
and outgoing materials. Ports serve as transfer terminals,
permitting the switching of cargo to a land or inland
transportation mode. The loading and unloading facilities
are designed for the particular type of material handled.
Tankers typically utilize pipelines while dry bulks may use
a gantry/conveyor system [69]. Some bulk carriers have
self-unloading capabilities.
Ocean bulk carriers transport materials between ports at
speeds from thirteen to sixteen knots [ 6]. The di stance
moved may be thousands of miles, and may require several
weeks in travel time.
the movement of barges.
123
Bulk carriers are also utilized for
LASH ( lighter-aboard-ship) is the
name given to those carriers that transport barges which
have been loaded at some inland point and moved to the ocean
port via inland water movement. These carriers may convey
up to 73 barges containing vario.us bulk materials.
It should be noted that several inland waterways, for
example the Great Lakes, permit passage of the type of
carriers described in this chapter. Additionally, although
the intercoastal waterways are part of the oceans, the
carriers which utilize them are of the type utilized on
inland waterways, and have been presented in that chapter.
Chapter 20
PIPELINE TRANSPORTATION SYSTEMS
Pipeline transportation systems have typically been
utilized for the movement of bulk liquid materials. Within
the last decade, the movement of bulk solids via pipeline
systems has recieved increasing attention. A pipeline
transportation system is composed of the pipe, pumping
stations, terminals, and the material.
The
400,000
United
miles
States currently
of pipelines [92].
utilizes approximately
A pipeline system may
transport material over distances which vary from less than
ten miles, to hundreds of miles. Pipelines provide a
transportation system, either under or above ground, which
is totally encased. The pipe diameter is fixed for a given
section of pipe, and it is chosen to be compatible with the
material type. The pipe provides a fixed route in much the
same manner as rails do for a rail transportation system.
Pumping stations are strategically located along the
pipeline [14,91]. They provide the power required to
transport the materials. The distance between stations is a
function of terrain, the pipeline size, the required
pressures, and the bulk material. The pumps utilized vary
in type and power, and provide power for movement of
124
125
non-compressible bulk materials. They may be replaced by
compressors for the movement of compressible materials such
as natural gas. Terminal facilities within a pipeline
system may include treatment plants and storage facilities.
Pipeline systems may be loosely classified as carrying
either liquids or solids. Liquid materials moved include
water, and crude and refined oil, in addition to gaseous
substances which possess fluid properties. Pipelines
typically convey a single material, however as is the case
with oi 1 movement, several grades of a material may be
simultaneously or sequentially transported.
There are three principal types of solid material
pipeline systems [ 92). Slurry pipelines transport solids
which have been suspended in a fluid medium, typically
water. Slurry lines are currently used for the movement of
coal, iron ore, sulfur, and potassium chloride. Pneumatic
pipelines move solids by means of air pressure or a vacuum,
utilizing air as the conveying medium. This is a system
commonly used for the unloading of bulk materials such as
grain or sugar [ 50] . Capsule pipeline systems transport
freight whose size approaches the pipe diameter.
Additionally, small particles may be aggregated to form
capsules which are conveyed by liquid or gas. Research has
been conducted on the use of capsule pipelines for the
126
movement of clean, graded rock aggregates over a six mile
distance (92).
Pipelines are typically designed to operate 24 hours per
day, 365 days per year (91). Although their speed is
real ti vely slow ( three to five miles per hour) they are
extremely dependable and have very good loss and damage
records [ 14). They are utilized to transport a limited
number of bulk materials over relatively fixed routes.
Chapter 21
CONVEYOR TRANSPORTATION SYSTEMS
Conveyor systems are generally considered to be material
handling rather than transportation systems. However
according to the previous definition, they are also utilized
for the transportation of bulk materials. Conveyors are
often used for loading and unloading bulk carriers,
representing a form of intermodal transfer. The major
components of a conveyor system are the transporting
surface, its foundation and supporting structures, and the
drive components.
Conveyors, for the movement of bulk materials, are
typically belt, chain, or screw type [ 16 l . These
classifications refer to the surface on which the material
is conveyed. In any case, the conveyor consists of an
endless, moving surface which is designed to transport a
single material at a given rate [ 1 7 l . They are
uni-directional and operate continuously without time loss
for loading and unloading. Conveyor systems are extremely
flexible in that they may recieve and discharge material
from one or more locations. The transporting surface may be
any desired, practical width and length. If necessary, the
entire system may be housed from external effects.
127
128
The amount of material transported is a function of the
width and speed of the conveyor surface, and the material
weight [ l). Conveyor capacities are usually expressed as
weight or volume per unit time. The size of the material is
primarily limited by the surface width. Bulk materials
transported through conveyor systems range from very fine,
dusty chemicals to large, lumpy ores.
Aerial tramways exhibit the same characteristics as land
conveyor systems. This is a form of transportation in which
the individual carrier is suspended above the terrain by
cables. The cables are themselves supported by towers
placed at intermediate points [ 17). Aerial tramways are
also designed to convey a single material at a given rate.
Typical materials include sand, gravel, crushed rock, clay,
and coal.
For both conveyor and aerial tramway systems, longer.
installations are often composed of individual units. Thus
transfer of either cargo or carrier between segments is
required [ 17].
Chapter 22
HIGHWAY TRANSPORTATION SYSTEMS
Highway transportation systems are not typically
associated with the movement of bulk materials. Their
relatively small carrying capacity is not economically
suitable for commonly low unit value bulk materials such as
coal and ores. Trucks are used for short haulage, either as
a form of intermodal transfer or as the transportation mode
for short distances.
Highway transportation is one of the most flexible modes
available for bulk material movement. This flexibility is
primarily attributed to the use of practically any land
surface for movement. Roads may be classified according to
functions, purpose, or importance and for the most part,
trucks are not restricted to any one type [ 92] . The road
type and topography are influential when considering vehicle
operation. The vehicles are not constrained by rails,
waterways, or any other additional physical
associated with other transportation modes.
entities
Bulk motor carriers are smaller than other bulk carriers,
averaging from five to twenty tons [ 1 7 l . They are
individually powered and controlled, each carrier requiring
a single operator. The cargo unit may or may not be
129
130
permanently attached to the power unit. There is typically
one cargo carrier per power unit. Recently, tandem trailers
are being utilized and may convey different materials. Both
liquid and solid materials may be transported including
coal, gypsum, gasoline, grain, and oil. · The cargo unit is
usually specialized for a particular material type or class.
There are three basic terminal classifications which are
found in longer distance highway transportation systems
[ 14]. Pick-up and deli very terminals permit freight to be
collected from shippers and consolidated with other loads
bound for the same direction or destination. Break bulk
terminals facilitate separation of consolidated shipments.
Relay terminals are required due to the maximum hours of
service regulations imposed upon carrier operators.
Part
Chapter 23
CONCLUSIONS
IV has presented overviews of bulk material
transportation systems. They have been classified according
to the mode of physical movement. Table 11 presents a
summary of these systems with reference to several easily
identifiable system parameters. Each transportation mode is
easily described utilizing these parameters, indicating that
they may be of use during formulation of simulation language
constructs. Table 11 emphasizes the perception that bulk
material transportation systems are extremely similar
regardless of the variations in transportation mode. It is
these similarities which facilitate the development of
functional specifications for a simulation language capable
of representing bulk material transportation systems.
131
132
TABLE 11
Syste:n Parameter Comparisons
Railway
Transp:,r- --tation Medium
Power Unit
Cargo Carrier
Average Capacity (tons)
Average
Rail
Loco-m:>tive
Railcar
78.8
Nunber 100 of Carriers
Average Distance 533 Travelled
Average Speed (mph)
so
Transp:,rtation System
Highwa: Inland Ocean PiEeline __ y t:rater Water
Road or Land Water Water Pipeline Surface
llitor Towboat Engine Punos' Engine Com-
pressers
Truck Bulk Trailer Barge Carriers Pipe
13.52 1350 40000
1 15-30 1 1
457 392-1770
60 5.5 22 4
C:Onveyor
llivi.ng Surface
llitor Engine
M,ving Surface
15-15000
1
320
10
PART V
SIMULATION LANGUAGE FUNCTIONAL SPECIFICATIONS
133
This part presents the functional
are developed from the information
specifications which
provided in previous
parts of this research. These specifications have been
presented in
description,
respectively.
overview of
three chapters
language form, and
The specifications
the development of
which emphasize system
computer considerations,
provide a very general
the proposed simulation
language for bulk material transportation
actual formulation of the language occurs,
systems. Until
the operational
characteristics cannot be described in any greater detail.
It is more reasonable to state that these specifications
address the manner in which the language is desired to
facilitate the simulation of bulk material transportation
systems.
The information detailed in Part Vis presented as three
chapters. The first of these describes the functional
specifications which are primarily concerned with the system
description. These specifications are based largely on the
information presented in Chapter 8 where the importance of
the system description, or model, within a simulation
analysis is stressed.
with language form
The following chapter is concerned
functional and format. These
specifications are derived from
Chapter 9. The final chapter
134
information presented in
of Part V details those
135
functional specifications which are computer hardware
oriented. This chapter utilizes information given in
Chapters 8 and 10. Additionally, each of the specifications
detailed in this part utilize the descriptions of bulk
material transportation systems which were presented in Part
IV.
In addition to the use of previously detailed information
in Chapters 8,9, and 10 and Part IV, the author's previous
experience in the simulation of bulk material transportation
systems was also utilized. This experience was gained as a
result of the author's graduate research performed for
Norfolk and Western Railway at their Lambert's Point Coal
Export Facility during 1981-82. The task was to develop a
simulation model of the facility which could be used as an
analysis tool by Norfolk and Western personnel. SLAM, an
extremely powerful simulation language, (see Section 12.14)
was used to develop the model. The difficulties encountered
in successfully modeling the system as desired resulted in
the author's decision to formulate a simulation language
specifically for bulk materials such as coal.
Chapter 24·
SYSTEM DESCRIPTION
This chapter is concerned with the general system ( or
model) characteristics which have been presented in Section
8.1. The functional specifications presented will classify
bulk material transportation systems' models as being of the
following types;
1. Iconic, analog, or symbolic
2. Static or dynamic
3. Stochastic or deterministic
4. Discrete, continuous, or combined discrete/continuous
As previously stated, the majority of simulation models
are symbolic representations of a system. These models
describe system behavior utilizing mathematical expressions
and functions. Expressions of this type are extremely
important for the representation of bulk material
transportation systems. Examples include rate equations for
carrier movement and the loading and unloading of the
material. Additionally, many analysts feel that a network
configuration provides an excellent pictorial view of a
transportation system [4]. With this perspective, the nodes
correspond to terminals and the branches represent both the
transportation medium and the route to be followed.
Networks are also a symbolic model type.
136
137
Bulk material transportation systems are dynamic. The
analyst is primarily concerned with the variations in system
state as time advances. It is not feasible to suggest that
the manner in which these changes occur is irrelevant as it
is in a static simulation. It is the responsibility of the
analyst to describe the means by which these changes occur,
typically utilizing mathematical and/or logical expressions.
From another per spec ti ve, several of the variables within
bulk material transportation systems exhibit time dependent
behavior. Examples include the movement of a conveyor and
the availability of operators within an inland water system.
Stochastic models are those in which one or more model
entities possesses a degree of randomness in its transition
from one state to the next. Bulk material transportation
systems are stochastic, as opposed to deterministic, in that
the model entities do not behave in a completely known
manner. The overviews presented in Part IV do not describe
all of the inputs which influence system behavior. It would
be an extremely difficult programming task to incorporate
them within the simulation language. A typical example is
the effect of the weather on both material and carrier . behavior. It would be much simpler to reflect these
"exogenous" influences in terms of random behavior of the
system entities. However, the language should incorporate
138
deterministic capabilities which wi 11 assist in debugging
and validation.
24.1 RANDOM NUMBER GENERATION
As the result of the previous statement that the language
should possess the ability to represent stochastic system
elements, a method is required for generating random
variables. The method shall provide values from both
empirical tables and from theoretical distributions. This
shall be accomplished in two distinct steps (86]. The first
step requires the generation of a sequence of uniformly
distributed random numbers. These numbers are then utilized
to generate random variables with the required
characteristics. Random variate generation is discussed in
the following section.
The accomplishment of the first step within a computer
simulation theoretical framework should satisfy the
following criteria (11];
1. The sequence of random numbers must be uniformly
distributed.
2. The sequence of random numbers must be statistically
independent.
3. The generator should involve a minimum number of
program lines for expedient execution.
139
4. The generator should require a minimum amount of
memory storage.
5. The sequence of random numbers should be of
sufficiently long period.
6. The sequence of random numbers should be
reproducible.
The execution of a stochastic simulation program
typically utilizes several random numbers which are created
by the random number generator as a sequence of values.
This sequence must be statistically tested for uniformity
and independence in addition to randomness. Table 12
presents a list of statistical tests commonly used for this
purpose. It is recommended that the first four tests be
performed plus any others which may be relevant to the
problem at hand. Additionally, several currently used
random number generators have
requiring only proper usage to
correctness [86].
been previously tested,
ensure their statistical
It is not possible to assure that any deterministic
process such as a computer implemented algorithm will
produce a sequence without any non-random characteri sties
[ 70 l . The values generated are in fact pseudorandom. They
are created using recursive mathematical relations and are
therefore completely deterministic. The repeated use of the
140
TABLE 12
Statistical Tests For Random Number Generators
Frequency Tests Gap Test Spectral Test Autocorrelation Test Order Statistic Tests Maximum Test
References [11,86]
Serial Test Runs Test Poker Test Distance Test Lagged Product Test
141
same input values will generate the same sequence of random
numbers as output, satisfying the reproducibility
requirement mentioned above. This also permits use of
correlated sampling techniques [86]. The period of the
sequence is the number of values which will be · generated
before the values begin to repeat [ 70]. The period of a
random number sequence must be of sufficient length to
provide a unique value whenever required for the duration of
the simulation.
The most commonly used method for generating random
numbers is one of three forms of a linear congruential
generator [ 11]. The most recommended of these [ 70, 86] is
the multiplicative generator which is of the form
X = (CX 1) :Mxlulus M n n-
The value of Mis usually set equal to the word size of the
computer to be used, permitting the modulus operation to be
accomplished by ignoring overflow. The initial value of X
and the value of Care then chosen so that a maximum period
value is obtained, and to ensure a maximum degree of
correlation between the values generated. The random
numbers will be between 0 and 1, however any desired range
may be created by dividing X by M.
142
The remaining forms of the linear congruential generator
are known as the mixed form and the additive form
(11,70,86]. These typically permit a larger period length
which is independent of the computer word size. However
they typically require greater computer storage space, and
they tend not to perform well with regards to the runs test.
Each of the linear congruential generators are extremely
sensitive to the selection of seeds and constants. Shannon
presents several references for other types of generators
which are currently available (86]. These have very little
advantage over the multiplicative generator which tends to
execute as fast or faster, and is not as likely to create
difficulties when used.
24.2 RANDOM VARIATE GENERATION
The stochastic behavior of system variables is typically
described by historic data. For example the length of time
required for an inland water carrier to pass through a lock
may be recorded for as many occurrences as desired,
resulting in a set of tabularized sampled data points. This
data is then utilized by the system's analyst to describe
variable behavior during the simulation execution.
The random numbers discussed in the previous section may
now be utilized to select a variable value in one of two
143
ways. A table look-up procedure is a means of actually
selecting one of the sampled data values from the table and
assigning it to the proper variable. Monte Carlo sampling
is one type of table look-up technique (86]. This method is
not generally very efficient in terms of computer storage,
in addition to being restricted in terms of the use of only
historic, sampled data.
As opposed to a table look-up method, theoretical
distributions may be used. A distribution is chosen such
that it represents the historic data but has the advantage
of representing the population rather than just a sample.
The use of theoretical distributions is facilitated by the
fact that through mathematical manipulation, a uniformly
distributed random number may be used to generate
practically any theoretical 'distribution (70]. The
distribution is described by parameters (mean, variance,
etc.) which are derived from the sampled data.
For most of the theoretical distributions several
algorithms are available which accomplish the transformation
of the random number to the desired form [ 47, 70]. Many
researchers recommend the use of the inverse transformation
method, descriptions of which may be found in [11,47,70,77].
The number and type of theoretical distributions which
shall be incorporated within the proposed simulation
144
language would be difficult to specify at this time. What
may be stated is that it will be a subset of those presented
in Table 13. A form of table look-up procedure shall be
incorporated for that sampled data which cannot be
adequately represented by a theoretical distribution.
Additionally, one or more transformation techniques shall be
available for the amenable data.
24.3 DISCRETE, CONTINUOUS, OR COMBINED ORIENTATION
Table 14 presents a listing of the various entities
contained within bulk material transportation systems. As
with the system descriptions, this listing is an overview
and is not intended to incorporate all entity types which
may exist. It is obvious that both discrete and continuous
entities may be found, often existing simultaneously. This
indicates a need for the language to be capable of
representing one, the other, and/or both entity types.
In many cases a single entity requires representation as
both discrete and continuous. For example, the unloading of
a carrier may be described as a discrete process if it is
or cranes. However if the accomplished utilizing buckets
material is discharged through a pipeline, a continuous
description of the process is more applicable.
145
TABLE 13
Theoretical Probability Distributions
Beta Binomial Chi-square Erlang Exponential Gamma Geometric Hypergeometric
Lognormal Multinominal Negative Binominal Normal Poisson Triangular Uniform Weibull
Barges Commodities Conveyors Locomotives Towboats Operators People
146
TABLE 14
System Entities
Pipelines Railcars Rails Roads Ships Trucks Water
147
24.3.1 Discrete Orientation
The modeling perspective utilized for the discrete model
portions is strongly influenced by the nature of bulk
material transportation systems. Of the currently utilized
perspectives, event scheduling, process interaction, and
activity scanning, the most appropriate is the process
interaction approach.
The process interaction approach emphasizes the movement
of entities through the system, rather than the
representation of system state changes which is the primary
consideration of the other per spec ti ves. It permits the
analyst to percieve the system as a set of interact~ng
processes representing the path followed by an entity. This
is precisely the manner in which a bulk material
transportation system should be represented. The processes
can represent the various activities which typically occur
affecting a bulk material between its origin and
destination. Examples include loading and unloading, the
utilization of carriers, and of transportation mediums.
Terminal facilities may also be represented in this manner.
The process interaction approach will facilitate simpler
programming thru its use of macro-structure language
statements. However, certain aspects of bulk material
transportation systems may be more accurately represented
148
utilizing the event scheduling approach.
is desired to preschedule occurrences
For example if it
such as system
operational periods, or if it is desired to model certain
processes in greater detail. The user· may then define
instantaneous state changes occurring at event times in
terms of mathematical and/or logical expressions. The
activity scanning approach is useful in situations where the
system state determines the occurrences of events or
activities. An example of this would be the requirement
that a train await the proper number of rai lcars prior to
its movement. This perspective also facilitates system
representation in situations where activity durations cannot
be specified due to their dependence on the system state.
The proposed simulation language should offer programming
abilities representing each of the three discrete
perspectives. The process interaction approach shall be the
primary perspective, however the use of other perspectives
should be easily accomplished as they too are extremely
useful.
24.3.2 Continuous Perspectives
The continuous portions of bulk material transportation
systems' models are capable of being represented with either
block or expression form languages. Block form languages
149
emulate analog computer behavior for continuous system
simulation. They permit subroutine connection and control
in much the same way as an analog patchboard permits control
of electronic units.
recently
offered
developed
by block
Expression form languages
class which combine the
form languages with the
convenience of algebraic and logical statements.
are a more
simplicity
power and
For this
reason, the proposed simulation language shall be expression
form. The language will therefore facilitate direct
representation of the mathematical equations which describe
the system. This shall provide for more convenient
programming for the language user. It is proposed that the
continuous system facilities will closely adhere to the
specifications of the Simulation Software Committee of
Simulations Councils Inc. for continuous system simulation
languages [ 41] .
24.3.2.1 Continuous System Equations
The simulation of continuous systems typically involves
the use of differential and/or difference equations for the
system description. The proposed simulation language shall
offer facilities for solution of both equation types,
providing the user with a choice as
representation. Examples of their
to continuous system
use includes the
150
description of material flow either by pipeline or conveyor,
and the representation of loading and unloading
characteristics.
24.3.2.2 Numerical Integration
The use
simulation
of a digital
requires that
computer for continuous system
the proposed simulation language
incorporate an algorithm for numeric integration. There are
a large number of currently utilized techniques for digital
computer evaluation of continuous systems (18,33,49,70].
The decision as to which to use is primarily determined by
the following;
1. Computer memory (both available and required)
2. Acceptability of errors due to:
a) Numerical approximations
b) Roundoff (finite word length) effects
3. Computational effic~ency (processing time)
4. Stability of the method
Currently available algorithms are typically restricted
to solving systems of first order differential equations
(33]. This requires the proposed language to facilitate the
representation of an arbitrary nth order differential
equation by
differential
an equivalent
equations. Korn
system of
and Wait
integration techniques as follows (49);
n first
classify
order
numeric
use
1.
2.
151
Multi-step rules These utilize past values to
approximate a solution value either implicitly or
explicitly, and require one derivative call per
integration step.
Predictor-corrector methods These combine a
predictor rule for estimating the solution with a
rule to corrector
typically require
integration step.
improve the estimate.
two derivative calls
They
per
3. Runge-Kutta methods - These methods are designed to
be exact for a polynomial of order n. They are
classified by order which corresponds to the number
of derivative calls per integration step, and they
utilize an averaging process to obtain improved
derivative approximations.
Multi-step rules present difficulties in their initial
and with discontinuous derivatives where the
approximation is inaccurate [ 49] . Predictor-corrector
methods offer an improvement in accuracy and stability.
They typically incorporate a technique for altering the step
size based on a difference in solution values. Runge-Kutta
algorithms are the most efficient and present fewer
programming difficulties [70]. They also tend to be less
sensitive to certain stability problems w.hich occur with
numeric integration.
152
It would be difficult at this time to determine which
method would be optimal with regard to bulk material
transportation
the language
system simulation. It
will incorporate more
providing the user with a selection.
is concievable that
than one algorithm,
Korn and Wait state
that no one rule is best for all purposes however most
researchers consider a fourth order Runge-Kutta-Fehlberg
algorithm to be suitable for most general purposes [ 49) .
Dickie presents thirteen commonly used techniques which are
compared on the basis of memory space, number of derivative
evaluations, total number of errors, and relative efficiency
to perform a similar [ 18 l • It would be advantageous
comparison utilizing the selected computer type prior to
selecting a particular method of numeric integration for the
proposed language.
In conclusion, bulk material transportation systems and
models require symbolic, dynamic, stochastic,
discrete/continuous representation for an acceptable
simulation analysis
necessary that the
these capabilities.
to be accomplished. It is therefore
proposed language possess, at least,
153
24.4 TIMING MECHANISM
Acknowledging the use of a combined discrete/continuous
simulation language perspective, the proposed language's
timing mechanism must offer the following capabilities;
1. The ability to manage the timing of a purely discrete
model.
2. The ability to manage the timing of a purely
continuous model.
3 . The ability to manage the timing of a combined
discrete/continuous model.
The possible occurrence of each of these model types
necessitates a timing mechanism which is capable of
efficiently monitoring the events and activities for each.
The concurrent timing mechanism described in Section 8.1.6.1
represents a synchronization of a next event and a fixed
increment time clock. The fixed increment timing mechanism
facilitates simulation of the continuous model portion by
permitting derivatives and system states to be calculated
with each incremental time advancement. The next event
timing mechanism permits identification of the time of the
most imminent event, updating the system state at that time.
The synchronization of these timing mechanisms forces the
"fixed" increment mechanism to alter the specified step size
such that the time of the most imminent event is exactly
154
reached, permitting it to be executed at the proper time.
The necessity of this timing operation is obvious from the
following example. Within a conveyor system, the conveyor
typically operates continuously with scheduled downtime for,
for example, · personnel shift changes or maintenance. The
fixed increment timing mechanism will continuously monitor
the conveyor (and material) movement. However the
occurrence of the prescheduled downtime must be recognized
and executed. The next event timing mechanism· facilitates
this and permits the system state to be updated accordingly.
Use of a concurrently operating fixed increment/next
event timing mechanism will permit the proposed simulation
language to most efficiently execute simulation programs
describing the operations of bulk material transportation
systems. In addition the language should offer the user a
choice of one, the other, or concurrent timing which wi 11
increase the executional efficiency of programs written in
the proposed language.
Chapter 25
LANGUAGE FORM CONSIDERATIONS
As previously stated in Section 9.2.2, it is the goal of
the language designer to formulate the language such that it
satisfies the requirements of the eventual user. The user's
decision· as to which language to utilize occurs at two
levels; l)a language for use on several varying projects,
and 2)a language for use in a particular study [52]. Table
7 presents a list of considerations for language selection
at both levels, and therefore they will not be repeated
here.
The proposed simulation language for bulk material
transportation systems exists in a region between these
levels. It shall be developed for use on several varying
projects within the very specific framework of bulk material
transportation. The proposed simulation language shall be
capable of representing the systems described in Part IV.
These systems vary in terms of bulk material type, carrier
type, and Lransportation medium, however each of these areas
are always included in the system definition. It is
therefore the intent of the author that the language be
useful to those who desire to simulate any type of bulk
material transportation system. It is also intended that
155
156
the proposed simulation language be a more appropriate
choice to those systems' analysts than any other simulation
language currently available.
25.1 LANGUAGE LEVEL
At this time it is not possible to precisely specify the
sophistication level of the language which will be utilized
to formulate the proposed simulation language. It is more
appropriate to state what level the language will not be.
The use of a machine language is not practical for several
reasons. Languages of this form reflect the command
structure and detailed design of a particular computer type.
Additionally the tediousness and complexity associated with
machine language use tends to make it impractical for the
formulation of the proposed simulation language.
Problems of the same type would arise if an assembly or
second level language was utilized. These languages
incorporate a string of mnemonic symbols which correspond to
machine language instructions. Assembly languages are also
more computer oriented than is desired and would require a
considerable programming effort for the formulation of the
proposed simulation language.
An additional disadvantage associated with the use of
either a machine or assembly language is that they are often
.. 157
unfamiliar to the intended users. It is intended that the
simulation language be as user friendly as possible,
permitting comprehension and possible alteration of
subroutines, for example, report generation facilities, as
desired. These considerations promote usage of, at the very
least, a third level language for the proposed simulation
language formulation.
Programming, or third level languages are machine
independent, and are utilized in the formulation of most
currently used simulation languages. It is probable that
the proposed simulation language will also be written
utilizing a programming language. These languages do not
present the comprehension difficulties of lower level
languages because their statements are either of artificial
English or mathematical form. Certain languages are of
modular form, such as PL/1. This facilitates translation of
programs written in the language ( source program) into a
machine code (object program) which must be accomplished for
computer execution. The use of a compiler rather than an
interpretive language typically requires less computational
time due to its method of source to object translation, and
is therefore a better choice.
Al though it is not known what language the proposed
simulation language will be written in, it will more than
158
likely be of a third level type. What can be stated at this
time is that the proposed simulation language will be a
fourth, or high level programming language. The 1 anguage
will be specially developed for simulation analysis of bulk
material transportation systems. It will employ an
interpreter program, written in a programming language,
which will generate a third level language program which
will then be compiled into machine code for computer
execution.
25.2 MODULAR CONSTRUCTION
The overall construction of the proposed simulation
language will be modular in nature. It is intended that
each mode of bulk material transportation will be
represented by one or more modules, ( or submodules) . The
level of detail of these modules cannot be specified at this
time. In accordance with the process interaction
perspective, the movement of the bulk material through a
system shall be described in terms of the following modules;
1. Rail
2. Highway
3. Conveyor
4. Inland water
5. Ocean
159
6. Pipeline
For example consider the movement of coal from a mine to an
overseas
extremely
mentioned,
described
port facility.
simplified form,
the loading and
This system is presented, in
in Figure 2. As previously
unloading operations may be
The conveyance of coal is as processes.
di stingushed according to the transportion mode. The user
is required only to specify the mode and provide the
necessary descriptive parameters such as speed, distance
travelled, amount of material, etc.
25.3 OUTPUT REPORT GENERATION
The primary requirement of the proposed simulation
language's output report generation facilities is that they
be easily understood by· the intended user. In addition,
these facilities shall be as complete as possible. This
requires that data be presented in terms familiar to bulk
material transportation systems' analysts. Table 15
presents examples of these terms. A survey of each
transportation mode with regard to terms such as these will
facilitate their inclusion within the proposed simulation
language. The language shall offer a variety of output
formats from which the user may choose for data
representation. Table 16 presents a listing of these. The
160
transport coal via conveyor
transport coal via railway
transport coal via
transport coal via ocean vessel
Figure 2. Coal System Schematic
conveyor
transport coal via highway
161
main objective of these facilities is to make the report
generation facilities as user specified as possible.
The term user specified implies that the user may select,
from. a list of available parameters, precisely the output
format desired. These lists shall be as complete as
possible, identifying the available language options for the
user.
The statistical aspects of the output reports shall also
be as user specified as possible. The programmer must be
able to specify what statistics are required for each type
of data requested. Additionally, the language shall possess
the capability of providing output reports at any time
during the simuiation program execution. Table 16 presents
a listing of statistics which may be provided for.
Statistical analysis of ou~put data is typically not
accomplished by currently available simulation languages.
Instead, a separate program is usually required, as is the
case with SIMSCRIPT I I. 5. Prior to the actual formulation
of the proposed simulation language, it cannot be determined
how difficult the incorporation of such a feature will be
from a programming perspective. However, if statistical
analysis is included, the user will be able to specify
whether or not the analysis should be performed. Examples
of statistical tests which can be made available are
presented in Table 16.
TIME seconds minutes hours days
162
TABLE 15
Output Report Terms
RATE tons/hour feet/second miles/hour pounds/minute gallons/day
QUANTITIES pounds tons gallons miles feet yards
GENERAL railcars barges ships holds trucks carloads capacities
163
TABLE 16
Output Report Types
Formats
tables bar graphs histograms plots trace correlograms graphics
Statistics
mean variance covariance current value cumulative value minimum value maximum value sample size
Statistal Tests
linear regression linear correlation analysis of variance tests of means tests of variance proportional tests non-parametric tests
Chapter 26
COMPUTER CONSIDERATIONS
The choice of computer type for which the proposed
simulation language will be formulated is restricted by the
type of computer available to the language developer.
Virginia Tech's mainframe computer is presently of the IBM
370/158 series which is a digital computer. The advantages
of utilizing a digital as opposed to a hybrid or analog
computer have been previously presented in Table 4 and
include high computational speed for both logic and
arithmetic operations, large storage avai labi li ty, and
greater flexibility. Although analog computers are
available through Virginia Tech's Electrical Engineering
Department, their restriction to the simulation of
continuous systems make them an impractical choice.
In addition, the following types of personal computers
are available to the language developer;
1. IBM PC
2. TRS 80 - Model II
3. Apple II PLUS
The proposed simulation language will be suitable for use
on Virginia Tech' s mainframe digital computer. It is not
possible to specify at this time which of the personal
164
165
computers will be the most appropriate. It is desired that
the proposed simulation language be operational for at least
one, if not all, of those mentioned above.
26.l DATA STRUCTURING
The data structuring abilities of the proposed simulation
language shall provide for efficient storage and retrieval
of very structured system information. This typically
involves the use of a file maintenance system with search
is capable of and removal mechanisms, and which
prioritization. The following sequence of events must be
facilitated by the proposed simulation language [15).
1. Information entering the computer system is analyzed
and subsequently classified.
2. The information is stored in an ordered fashion (not
necessarily according to the classifications in 1).
3. The user requests information by specifying its
classification or type.
4. The storage facilities are searched and the proper
information is located.
5. The information is provided to the user.
Techniques for information storage and retrieval are
plentiful and varied [15). The choice is dependent on the
amount and type of computer storage devices available, and
166
the type of information being dealt with. Several of the
currently available simulation languages ( SLAM, SIMSCRIPT
I I. 5, SIMAN) employ what is referred to as a linked list
form of information storage and retrieval;
A linked list system permits data to be stored in a
manner that depicts the data relationships in an ordered
fashion, and is ideal for queuing systems [ 33] . Detailed
descriptions of their operational characteristics may be
found in [ 11, 52, 70, 71, 77] and the reader is referred to
these publications. The various types of linked lists are
described in terms of density, dimension, and sequence.
They may be searched serially or may provide for direct
location of required data.
26.2 DOCUMENTATION
The importance of language documentation capabilities
cannot be overemphasized. It is considered necessary for
the following reasons;
1. For understanding program input.
2. For understanding the program processing.
3. For understanding program output.
Language documentation capabilities also serve the following
purposes;
1. Facilitating program updating.
167
2. Facilitating the transfer of programs from one
computing facility to another.
3. Facilitating the transfer of programs from one user
to another.
It is intended that the programs written in the proposed
simulation language be self documenting to as great a degree
as possible. This is a result of utilizing terms familiar
to bulk material transportation systems' analysts. In
addition, the language shall permit the user to incorporate
non-executable statements within a program. An example of
the use of a non-executable statement type is the FORTRAN
COMMENT statement. By properly identifying a program line
as a comment line, the user may insert any message, or other
form of documentation, at any point within a program.
languages incorporate a feature of this type.
26.3 DEBUGGING
Many
Debugging is the technique of detecting, identifying, and
rectifying errors, or "bugs" which may occur during the
execution of computer programs [ 15). As previously
mentioned in Chapter 10, debuggining facilities are capable
of assisting the simulation analyst in the validation and
verification of the model and program, respectively.
168
Logic errors may occur as a result of incorrect
appreciation of the language features while syntax errors
occur due to incorrect program coding. Errors are typically
detected from incorrect output (detected by the programmer)
or due to the failure of the program to execute (detected by
the computer). It is the computer detectable errors which
the proposed simulation language's debugging facilities will
address.
Computer detected errors are identified during
translation of the user program into machine language for
subsequent execution.
must be diagnosed.
Once found, the cause of the errbr
There are several ways in which the
proposed simuiation language may assist the user in
determining the cause of error. The provision of a computer
trace or diagnostic routine provides a printed record of the
action taken by each instruction.
all or selective instructions.
It may provide records of
Additional facilities
include prints: of selected internal storage at various
stages of program execution, or the contents of backing
store, for example magnetic tapes or disks [15). The
proposed simulation language shall be capable of identifying
commonly occurring errors, and of providing a printed
message of the error type and location.
169
The above mentioned facilities should be developed
concurrently with the proposed simulation language.
Therefore it is infeasible to discuss them in any greater
detail until the time of language development.
Chapter 27
SUMMARY
This thesis has detailed the development of functional
specifications for the formulation of a bulk material
transportation
introductory
system simulation
part, Part II has
language.
presented
discussion of the simulation analysis process.
Following an
a detailed
The process
is viewed as an iterative sequence of steps which guide the
analyst through the analysis procedure. Emphasis is given
to the relationship between the analysis procedure and the
simulation language utilized. Part III has presented
reviews of a selected number of simulation languages. This
results in a knowledge of the capabilities of currently
available simulation languages. Part IV introduced bulk
material transportation syste~s and their characteristics
from a simulation analysis perspective. The intent was to
present these systems so that they will assist in developing
the conclusions of this research. Part V has presented the
functional specifications for a bulk material transportation
system simulation language. The specifications have been
described according to system description, language form,
and computer or hardware considerations. This part has
presented the conclusions of this research.
170
Chapter 28
FUTURE DEVELOPMENT PLANS
Continuation of the research initiated in this master's
thesis will result in the actual language development which
will be described in future research. Figure 3 depicts the
logical succession of activities which shall culminate in
the presentation of the simulation language for use by bulk
material transportation systems' analysts. This list of
events is not all inclusive. Instead it presents what are
considered to be the more important milestones in the
language development.
The initial phase of the language development involves
the selection of the computer hardware on which the language
will be functional. This is dependent upon the type of
hardware which is readily available to the language
developer. In conjunction with this decision, a computer
language is selected which will be used to write the
simulation language.
consideration by the
This
language
phase
developer
requires careful
whose familiarity
with the hardware and software will directly influence the
efficiency of the language developed.
Once this phase has been accomplished, actual language
development may begin. The development consists of several
171
construction of users manual
of computer hardware
172
of computer language
selection of validation
Figure 3. Future Development Network
verificatio
173
tasks which may be performed in a wide variety of sequences.
These tasks include the selection and coding of various
programming aids such as random number and random variable
generators, and data storage and retrieval mechanisms.
Additionally, the system descriptions and activities are
formalized and coded. Validation and verification shall
occur concurrently with language development as well as the
initial construction of a user's manual.
The final phase involves the presentation of the language
for analysts
language is
user's guide.
use. Final testing of the fully operational
accomplished as well as formalization of the
BIBLI<X;RAPHY
1. American Institute of Mining Engineers, SME Mining Engineering Handbook, Ivan A. Given ed., New York, SME of AlM1PE, Inc., 1973.
2. Anina, Joseph S., and Edward C. Russell, ''The Ten M:>st Frequent Causes of Simulation. Analysis Failure-And How to Avoid Them," SIMULATION, vol 60, pp. 137-140, June 1979.
3. Annstrong, Jolm H., The Railroad-What it is and What it Does, Nebraska, Sinmms-Boardman Publishing Corp., 1979.
4. Assad, Arjang A., ''t-bdels for Railroad Transportation.," Transp:,rtation. Research, vol 14A, Winter 1980.
5. Atkins, Stella, "A ilinpari.son. of SIMULA and GPSS for Sirrn.llating Sparse Traffic," SIMULATION, pp. 93-100, March 1980.
6. Bes, J., Bulk Carriers, New York, W.S. Hei.mlan, 1972.
7. Birtwhistle, G.M., Discrete Event Modeling on SIMULA, Hong Kong, McMillan Press Ltd. , 1979 .
8. Birtwhistle, GoM., Dahl, O.J., Myhrhaug, Bo, and K. Nygard, SIMULA Begin, Philadelphia, Auerbach Publishers Inc., 1973.
9. Branch, Allen E., Elements of Shipping, New York, Chapnan and Hall, 1981.
10. Bryant, Rayroond M., ''Discrete System Simulation. in Ada," SIMULATION, vol 39, pp. 111-121, October 1982.
11. Bulgren, William G., Discrete System Simulation., Englewood Cliffs, Prentice-Hall, 1982.
12. Buxton, J .N., ed., Simulation. Programning Languages, Proceedings of the IFIP Working Conference on Simulation. Prograrrming languages, New York, Elsevier Publishing Company, Inc. , 1968.
13. Capehart, Barney L. , "Simulation. of Continuous System M:>dels in Industrial Engineering,'' C'.anputers and Industrial Engineering, vol 1, pp. 207-216, 1977.
174
175
14. Cavinato, Joseph L., Coyle, John J., and Edward J. Bardi, Transportation, St. Paul, West Publishing llinpany, 1982.
15. Chander, Anthony, Cit"aharn, John, and Robin Williamson, A Dictionary of C,anputers, England, Penguin Books Ltd. , 1970
16. Conveyor Equipnent Manufacturers Association, Belt Conveyors for Bulk Materials, Boston, CBI Publishing ilinpany, Inc. , 1979.
17. Colijn, H., ''Transportation MJdes," Bulle Material Handling, M. Hawke ed., vol 2, pp. 169-193, 1973.
18. Dickie, A.A., "A Canparison of Thirteen Nunerical Integration Routines," UKSC Conference~ C.anputer Simulation, Chester, England, Kingprint Limited, April 1978.
19 . Ei.mutis, E. C. , "APL/ 370: A Useful Simulation Tool, " SIMUI.ATION, vol 20, pp. 67-68, February 1973.
20. Eldin, Hamed K. , ''The Need for an Industrial Engineering Software Library," C.anputers and Industrial Engineering, vol 1, 199-206.
21. Emshoff, J .R., and R.L. Sisson, Design and Use of C-ornputer Simulation Models, New York, Mc.Millan, 1970.
22. Fair, Marvin L. , and E.W. Williams, Econanics of Transportation and Logistics, Dallas:Business Publications, 1975.
23. Fahrland, David Arthur, "Canbined Discrete Event Contirruous Systems Simulation," SIMUI.ATION, vol 14, no 2, February 1970.
24. Faig, Earle, ''Waterway Transportation of Coal," Bulk Materials Handling, M. Hawke ed., vol 4, pp. 315-322, 1977.
25. Fedeler, Jerry A. , Heady, Earl O., and Won W. Koo, An Interregional Analysis of U.S. Ibrnestic Grain Transportation, Iowa State University, February 1975.
26. Follc, Joseph, "Simulation Models of Railroad Operations :A Review of Major Efforts," Pittsburgh Sinulation Conf. , March 1980.
27. Franta, W.R., The Process View Of Simulation, New York, Elsevier furth-Holland, Inc., 1977.
176
28. Frisque, D.E., and L.C. 'Marraccini, ''Physical Properties of Bulk Materials," Bulk Materials Handling, M. Hawke ed., vol 1, pp. 364-380, 1971.
29. Gass, Saul I., ''Evaluation of OJmplex llidels," C.omputers and Operations Research, vol 4, pp. 27-35, 1977.
30. Golden, D . G. , and J . D . Shoeffler, "GSL-A Qxnbined Continuous Discrete Simulation Language," SIMUIATION, vol 20, pp. 1-8, February 1973.
31. Golovin, L.B., "Semi-stochastic Simulation and Other Tricks of the Trade," Proceedings of the Winter Simulation Conference, pp. 179-188, 1982.
32. Gordon, Geoffrey, Systan Simulation, Engle,;ood Cliffs, N .J. , Prentice-Hall, Inc. , 1969.
33 . Graybeal, W .J. , and U. W. Pooch, Simulation: Principles and Methods, Cambridge, Winthrop Publishers, Inc. , 1980.
34. Greb, Edward M. , " A Universal Design for the Construction of Simulations," Washington and Jefferson College, 1977.
35. Green. Walter L., and Frank H. Speckhart, "CSMP," SIMUIATION, vol 34, pp. 131-133, April 1980.
36. Hamrxmd, Robert H. , Rogers, William B. , and Byard Houch Jr. , Introduction to FORTRAN N, New York, McGraw-Hill, Inc., 1978.
37. Hay, William W., Railroad Engineering, vol 1, New York, Jolm Wiley and Sons, Inc., 1953.
38. Helsgaun, Keld, ''DISCO-A SIMUIA Based Language for Contirn.lous c.anbined and Discrete Simulation," SIMUIATION, vol 35, pp. 1-12, July 1980.
39. Hille, Stanley J., and Richard F. Poist, Jr., Transporation: Principles and Perspectives, Illinois, Interstate Printers and Publishers, Inc., 1974.
40. Houle, P.A., and W.R. Franta, "On the Structural Concepts of SIMUIA," The Australian Canputer Journal, PP. 39-45, 1975.
177
41. Howe, R.M., "Tools For Continuous System Simulation:Hardware and Software," Simulation of Systans, L. Dekker ed., furth Holland Publishing Canpany, 1976.
42. Hoxson, H.G., "CIASS-Canposite Language Approach For System Simulation," Proc. 4th C.on.f. On Applications, Dec 9-11, 1970.
43. Jacoby, Sarruel L. S., and Jarrusz S. Kowalik, Mathana.tical M:Jdelling With C.ornputers, Englewood Cliffs, N .J., Prentice-Hall, Inc., 1980.
44. Jansen, Dennis R., "Analysis of the Costs of Truckload Freight Operations," Transportation Res.earch Record 7 58, Washington D. C. , Transportation Research Board, 1980.
45. Kivi.at, Phillip J., ''Develoµnent of Discrete Sinulation Languages," SIMUI.ATION, vol 8, pp. 65-70, February 1967.
46. Kneiling, John G., Integral ·Tram Systans, Wisconsin, Kalmbach .Publishing Company, 1969.
47. Kohlas, J., "Toe Generation of Randan NLinbers," Simulation '75, M.H. Hamza ed., Zurich, ACTA Press, June 23-26, 1975.
48. Korn, Granino, "A Wish List For Simulation Language Specifications," SIMULATION, vol 40, p. 30, January 1983 .
49. Korn, Granino A., and John V. Wait, Digital Continuous Svstem Simulation, Englewood Cliffs, N .J. , Prentice-Hall, Inc. , 1978.
SO. Kraus, Milton N., Pneumatic Qmveying Of Bulk Materials, New York, McGraw-Hill, 1980.
51. Kresge, David T., and Paul O. Roberts, Techniques of Transportation, vols 1 and 2, Washington D.C., The Brookings Institute, 1971.
52. Law, Averill M., and W. David Kelton, Simulation MJdeling and Analysis, New York, McGraw-Hill, 1982.
178
53. 1&7andowski, F., ed., "Simula.tore and Simulation," Proceedings of- the SPIE, vol 59, Anaheim Calif. ,1975.
54. Lieb, Robert C., Transportation: The fumestic System, Virginia, Reston Publishing c.anpany, Inc., 1978.
55. l.arDw, C., and B. Unger, '"The Process Vi~ of Simulation in Ada," The Proceedings of the Winter Simulation Conference, San Diego, pp. 77-83, 1982.
56. Meyer, R.N., ''Barge Loading and Unloading Facilities, 11 Bulk Materials Handling, M. Hawke ed., vol 2, pp. 226-237, 1973.
57. Mitchell, Edward E.L., and Joseph S. Gauthier, "Advanced C-ontinuous Simulation Language (ACSL), '' SIMUJ.ATION, vol 26, pp. 72-78, March 1976.
58. McLaughlin, Peter, ''REPLICAS, AN~ C-ontinuous System Simulation Language," Proceedings of the Annual Simulation Sympositm, 1980.
59. MJrgan, D.L., ''Bulk Trailers and C-ontainers, 11 Bulk Materials Handling, M. Hawke ed., vol 2, pp. 203-207, 1973.
60. M::>rris, William, ed. , The American Heritage Dictionary of the English Language, Boston, American Heritage Publishing Q:mpany and Houghton Mifflin c.ompany, 1975.
61. Naylor, Thanas H., Balintfy, J .L. Burdock, D.S., and K. Chu, c.omputer Simulation Techniques, N~ York, Jolm Wiley and Sons, inc., 1968.
63. O'Ixmovan, Thomas M., GPSS Simulation Made Simple, New York, Jolm Wiley and Sons, Inc. , 1979.
62. Office of Coal Research, and Virginia Tech, BELTSJM, Virginia, 1968.
64. O'Grady, E.P., ''Digital CoolptlterMethods for C-ontinuous System Simulation," Pittsburgh Simulation Conference, March 1973.
65. Ord-Smith, R.J., and J. Stephenson, Ccmputer Simulation of C-ontinuous Systems, London, Cambridge University Press, 1975.
179
66. Oren, Tuncer I., "A Personal View on the Future of Simulation Languages," Proceedings of the 1978 UKSC Conference on C,omputer Simulation, Chester, pp. 294-306, April 1978.
67. Oren, Tuncer I., "Software for Simulation of C'.anbined Contim.Jous and Discrete Systans: A State of the Art Review, 11 Sil1UIATION,
. vol 28, pp. 33-45, February 1977.
68. Oren, Tuncer I., and Bernard P. Ziegler, "Concepts for Advanced Simulation Methodologies," Sil1UI.ATION, vol 32, pp. 69-82, Mar 1980.
69. Oyler, J .F., ''Handling Bulk Solids at Ocean Ports, 11 Bulk Materials Handling, M. Hawke ed., vol 2, pp. 317-322, 1973.
70. Payne, James A. , Introduction to Simulation, New York, McGraw-Hill, 1982.
71. Pegden, C. Dermis, Introduction to SIMAN, Permsylvania, Systans Modeling Corporation, 1982.
72. Pegden, C. Dermis, and Michael P. Gately, "A Decision Optimization M::>dule for SLAM,'' Sil1UIATION, vol 34, pp. 18-25, January 1980.
13. Phillips, fun T., Ravidran, A., and James J. Solberg, Operations Research:Principles and Practices, New York, Jolm Wiley and Sons Inc., 1976.
74. Pitts, C., ''Belt Qmveyor Versus Truck For Coal Transportation," Unit and Bulk Materials Handling, presented at the Material Handling Conference, pp. 47-52, August 19-21, 1980.
75. Pritsker, A. Alan B., Modeling and Analysis Using Nea-x,rks, New York, Jolm Wiley and Sons Inc., 1977.
76. Pritsker, A. Alan B., The GASP IV Simulation Language, New York, Jolm Wiley and Sons Inc., 1974.
77. Pritsker, A. Alan B., and C. Dermis Pegden, Introduction to Simulation and SI.AM, New York, Jolm Wiley and Sons Inc. , 1979.
78. Rieber, Michael, C,anparitive Transportation Costs, vols 1-8, Springfield VA., Nl'IS, 1977.
79. Roberson, Jolm A., and Clayton T. Crowe, Engineering Fluid Mechanics, Boston, Houghton-Mifflin Company, 1975.
180
79. Roberson, John A., and Clayton T. Crowe, Engineering Fluid Mechanics, Boston, Houghton-Mifflin c.ampany, 1975.
80. Sargent, Robert G., "Introduction to S:i.mJ.lation Languages," Proceedings of the 1978 Winter mn.tl.ation Conference, vol 1, pp. 15-17, 1978.
81. Sampson, Roy J. , and Martin T. Farris, L\Jrnestic Transportation, Boston, Houghton-Mifflin Canpany, 1979.
82. Schaffer, William A., ''DYNAM)," SIMJIATI0N, vol 34, PPo 134-136, April 1980.
83. Schnidt, J.W., and R.E. Taylor, S:i.mJ.lation Analysis of Industrial Systans, HOOleMJOd, Ill., Irwin Press, 19700
84. Schrieber, Thomas, S:i.mJ.lation Using GPSS, New York, John Wiley and Sons Inc., 1974.
85. Shannon, Robert E., "S:i.mJ.lation: A Survey With Research Suggestions," AIIE Transactions, vol 7, pp. 289-301, 1975.
86. Shannon, Robert E., Systems Simulation: The Art and Science, New York, Prentice-Hall, 1975.
87. Sigal, C. Elliot, and A.A.B. Pritsker, "SMXYIH: A c.ombined Discrete Continuous Network S:i.mJ.lation Language,'' SIMJIATION, vol 22, pp. 65-73, M:rrch 1974.
88. Spriet, Jan A., and Ghislain C. Vansteenkiste, c.omputer Aided M::>deling and Simulation, New York, Acadanic Press, 1982.
89. UCIA, TRANS~, Clearinghouse for Federal and Technical Information Report No. 66-6, May 1966.
90. van Horn, Richard L., ''Validation of S:i.mJ.lation Results," Managanent Science, vol 17, pp. 247-258, January 1971.
91. Wasp, Edward J., Kerm.ey, John P., and Ramesh L. Gandi., Solid-Liquid Flow Slurry Pipeline Transportation, Gennany, TransTech Publications, 1979.
The vita has been removed from the scanned document