Table of contents
|
Sr.no.
|
Title
|
page no.
|
|
1
|
1
Introduction
1.1Introduction
of company
1.2What
is simulation?
1.3Time
oriented simulation and event oriented simulation
1.4Why
employ simulation?
|
|
|
2
|
Basic
simulation modeling
2.1 The
nature of simulation
2.2 Systems,
models and simulation
2.3 Experiment
with actual system Vs experiment with model of systems
2.4 Physical
model Vs mathematical model
2.5 Analylitical
solution Vs simulation
2.6 Static
Vs dynamic simulation
2.7 Deterministic
Vs stochastic simulation models
2.8 Continuous
Vs descrete simulation models
|
|
|
3
|
Descrete
event simulation
3.1 Time
advance mechanisms
3.2 Component
and organization of descrete event simulation
3.3 Steps
in sound simulation study
3.4 Continuous
simulation
3.5 Advantage
disadvantage and pitfalls of simulation
|
|
|
4
|
Literature
review
|
|
|
5
|
Problem
statements
|
|
|
6
|
Methodology
6.1
Implementation of simulation project
6.2
Material flow objects in brief
6.3
Material flow objects with description
6.4
Technomatics plant simulation tools
|
|
|
7
|
Model
|
|
|
8
|
Data
collection
|
|
|
9
|
Results
& Analysis
9.1 Scenario
1
9.2 Scenario
2
9.3 Scenario
3
9.4 Scenario
4
9.5 Engine
trolley quantity optimization
9.6 Hanger
speed Vs decking cycle time analysis
|
|
|
10
|
Conclusion
|
|
|
11
|
References
|
|
List
of Tables
|
No.
|
Caption
of table
|
Page no
|
|
1
|
Classification
of application of simulation in automotive industry
|
|
|
2
|
Results
from scenarios for material handling system
|
|
|
3
|
Scenario
1 : Decking cycle time , average JPH, average hanger waiting time at
different stations.
|
|
|
4
|
Scenario
2 : Decking cycle time , average JPH, average hanger waiting time at
different stations.
|
|
|
5
|
Scenario
3 : Decking cycle time , average JPH, average hanger waiting time at
different stations.
|
|
|
6
|
Scenario
4 : Decking cycle time , average JPH, average hanger waiting time at
different stations.
|
|
|
7
|
Engine
trolley quantity optimization.
|
|
|
8
|
Hanger
speed VS decking cycle time analysis
|
|
List
Of Figures
|
No
|
Description
|
Page no
|
|
1
|
Model
used for simulation
|
|
|
2
|
Sketch
of test stands layout for simulation experiment
|
|
List
of Graphs
|
No
|
Description
|
Page no.
|
|
1
|
scenario
1 : Average hanger waiting time at station 4 Vs engine decking cycle time for
|
|
|
2
|
scenario
1 : Average JPH Vs decking cycle time
for
|
|
|
3
|
scenario
2 : Average hanger waiting time at station 4 Vs engine decking cycle time for
|
|
|
4
|
scenario
2 : Average JPH Vs decking cycle time
for
|
|
|
5
|
scenario
3 : Average hanger waiting time at station 4 Vs engine decking cycle time for
|
|
|
6
|
scenario
3 : Average JPH Vs decking cycle time
for
|
|
|
7
|
scenario
4 : Average hanger waiting time at station 4 Vs engine decking cycle time for
|
|
|
8
|
scenario
4 : Average JPH Vs decking cycle time
for
|
|
|
9
|
Engine trolley
quantity optimization : no. of trolley Vs JPH
|
|
ABSTRACT
Engine decking process is one
of the most critical process in final assembly line of light transport vehicle
(LTV maxximo, 2Cylinder CRDe engine with DOHC technology 4Valve/cylinder
Power-25HP, 45NM torque ,850kg payload ,900CC engine) of Mahindra .
Painted bodies with chassis
passed to final assembly lines on conveyers where different vehicle components
are attached to it such as doors, cargo radiator, instrument panel , wind
shield glass ,engine, axle, steering gear box, wheels, batteries etc.
In
engine decking process, Engine is attached to the body of LTV. Engine placed on
self propelled engine trolley which moves on circular conveyer in closed loop
and attached to body of LTV which is hold by electro monorail sensor hanger
(EMS).earlier in this process assembly
workers moves with line process speed and do all assembly work of engine
attachment to the body i.e. positioning of engine on trolley, alignment of
engine, torquing of engine with chassis etc. This process is inconvenient for
assembly workers considering ergonomic point of view. Output in terms of JPH (jobs /hr) were not also achieved consistently. in this
paper new process for engine decking
has been designed by considering ergonomic point of view, with
changing EMS hanger speed at different stations on assembly line and providing
stop for engine assembly on vehicle body.Time for which engine on trolley is
stopped is known as engine decking cycle time.And that time is optimized using simulation techniques.
1. INTRODUCTION
1.1 company introduction:
About Mahindra group
|
The Mahindra Group’s
Automotive Sector is in the business of manufacturing and marketing utility
vehicles and light commercial vehicle, including three-wheelers. It is the
market leader in utility vehicles in India since inception, and currently
accounts for about half of India’s market for utility vehicles.
Although created in
1994 following an organizational restructuring, the Automotive Sector can
trace its antecedents back to 1954. The iconic Jeep that led American G.I’s
to victory in World War II is the very same vehicle that drove Mahindra group
to success in the Automotive sector. Mahindra & Mahindra Limited,
the flagship company of the Group, was
set up as a franchise for assembling general purpose utility vehicles from
Willys, USA.
Over the years, the
Group has developed a large product portfolio catering to a diverse customer
base spanning rural and semi-urban customers, defense requirements and
luxurious urban utility vehicles. In 2002, it launched the indigenously
engineered world-class sports utility vehicle-Scorpio, which bridges the gap
between style and adventure, luxury and ruggedness, performance and economy.
The Automotive
Sector continues to be a leader in the utility vehicle segment with a diverse
portfolio that includes mass transport as well as new generation vehicles
like Scorpio, Bolero and the recently launched Xylo.
Mahindra Navistar
(MNEPL) a second joint venture agreement with Mahindra & Mahindra, Ltd.
focuses on producing diesel engines for Medium and heavy Commercial vehicles
in India. Beginning in 2009, MNEPL’s advanced diesel engines will power the
full line of trucks and buses produced by MNAL.
|
|
PRODUCT IN MAHINDRA, PUNE
1)
Mahindra Maxximo (LTV-Light transport Vehicle)
(MPV-Multi
Passenger Vehicle)
2Cylinder CRDe engine with DOHC technology
4Valve/cylinder
Power-25HP, 45NM torque
850kg payload
900CC engine
2)
Mahindra Navistar truck MN25,MN31
Engine-
6Cylinder
inline engine
Volume-7200CC
210 HP- power
700NM torque
3)
MAHINDRA Bolero Pickup
MAHINDRA Xylo pickup
4) Mahindra W-201(Export SUV)
5) Mahindra S201(car)
1.2 What is Simulation?
VDI (Verein
Deutscher Ingenieure, Association of German Engineers) guideline 3633 defines
simulation as the emulation of a system, including its dynamic processes, in a
model one can experiment with. It aims at achieving results that can be
transferred to a real world installation. In addition, simulation defines the
preparation, execution and evaluation of carefully directed experiments within
a simulation model. [1]
·
You first check out the real-world installation
you want to model and gather the data you need for creating your simulation
model.
·
You then abstract this real-world installation
and create your simulation model according to the aims of the simulation
studies.
·
After this, you run experiments, i.e., execute
simulation runs, within the simulation model. This will produce a number of
results, such as how often machines fail, how often they are blocked, which
set-up times accrue for the individual types of station, which utilization the
machines have, etc.
·
Finally, management will use the results as a
base for its decisions about optimizing the real installation.
Developing your
simulation model is a cyclical and evolutionary process. You will start out
with a first draft of your model and then refine and modify it to make use of
the intermediary results the simulation runs provide. Eventually, after several
cycles, you will arrive at your final model.
 |
1.3Time-Oriented Simulation and Event-Oriented Simulation
Plant Simulation is a discrete, event-oriented simulation
program, i.e., it only inspects those points in time, at which events take
place within the simulation model. [19]
In reality, on the other hand, time
passes continually. When watching a part move along a conveyor system, you will
detect no leaps in time. The curve for the distance covered, and the time it
takes to cover it, is continuous, it is a straight line.
A discrete, event-oriented simulation
program on the other hand only takes points in time (events) into consideration
that are of importance to the further course of the simulation. Such events
may, for example, be a part entering a station or leaving it or of it moving on
to another machine. Any movements in between are of little interest to the
simulation as such. It is only important that the entrance and the exit (Out) events are displayed correctly. When a part enters a
material flow object, Plant
Simulation calculates the time until it exits that object and
enters an exit event into the list of scheduled events of the EventController for this
point in time.
Thus, the simulation time that the EventController displays,
leaps from event to event. This happens as soon as an event is processed.
1.4Why Employ Simulation?
·
Detect and eliminate problems that otherwise
would require cost- and time-consuming correction measures during production
ramp-up.
·
Determine and optimize the times, such as
processing time, failure time, recovery time, etc., and the throughput of the
plant.
·
Determine the size of buffers and the number of
machines your intended throughput requires. When a single machine costs
hundreds of thousands of dollars, it certainly helps to know if you need one or
more machines of one type.
·
Optimize the performance of existing production
systems by implementing measures that have been verified in a simulation
environment prior to implementation
·
Optimize the sequence of orders that have to be
fulfilled to make as few tool changes necessary as possible.
·
Train the operators of the machines in the
different states, which machines and the facility can be in.
2. BASIC
SIMULATION MODELING
2.1 THE NATURE OF
SIMULATION
Simulation Techniques for using computers to imitate, or
simulate, the operations of various kinds of real-world facilities or
processes. The facility or process of
interest is usually called a system, and in order to study it scientifically we
often have to make a set of assumptions about how it works. These assumptions, which usually take the
form of mathematical or logical relationships, constitute a model that is used
to try to gain some understanding of how the corresponding system behaves.[1]
If the relationships that compose the model are simple
enough, it may be possible to use mathematical methods (such as algebra,
calculus, or probability theory) to obtain exact information on questions of
interest; this is called an analytic solution.
However, most real-world systems are too complex to allow realistic models
to be evaluated analytically, and these models must be studied by means of
simulation. In a simulation we use a
computer to evaluate a model numerically, and data are gathered in order to
estimate the desired true characteristics of the model.
Application areas for simulation are numerous and
diverse. Below is a list of some
particular kinds of problems for which simulation has been found to be a useful
and powerful tool :
·
Designing and analyzing
manufacturing systems
·
Evaluating military weapons
systems or their logistics requirements
·
Determine hardware
requirements or protocols for communications networks
·
Determining hardware and
software requirements for a computer system
·
Designing and operating
transportation systems such as airports, freeways, ports, and subways
·
Evaluating designs for
service organizations such as contact centers, fast-food restaurants,
hospitals, and post offices
·
Reengineering of business
processes
·
Analyzing supply chains
·
Determining ordering
policies for an inventory system
·
Analyzing mining operations.
2.2 SYSTEMS, MODELS,
AND SIMULATION
A system is defined to be a collection of entities, e.g.,
people or machines, that act and interact together toward the accomplishment of
some logical end. [This definition was
proposed by Schmidt and Taylor (1970).]
In practice, what is meant by “the system” depends on the objectives of
a particular study. The collection of
entitled that comprise a system for one study might be only a subset of the
overall system for another. For example,
if one wants to study a bank to determine the number of tellers needed to
provide adequate service for customers who want just to cash a check or make a
savings deposit, the system can be defined to be that portion of the bank
consisting of the tellers and the customers waiting in line or being served. If, on the other hand, the loan officer and
the safety deposit boxes are to be included, the definition of the system must
be expanded in an obvious way. We define
the state of a system to be that collection of variables necessary to describe
a system at a particular time, relative to the objectives of a study. In a study of a bank, examples of possible
state variables are the number of busy tellers, the number of customers in the
bank, and the time of arrival of each customer in the bank. [7]
We categorize systems to be of two types, discrete and
continuous. A discrete system is one for
which the state variables change instantaneously at separated points in
time. A bank is an example of a discrete
system, since state variables – e.g., the number of customers in the bank –
change only when a customer arrives or when a customer finishes being served
and departs. A continuous system is one
for which the state variables change continuously with respect to time. An airplane moving through the air is an
example of a continuous system, since state variables such as position and
velocity can change continuously with respect to time. Few systems in practice are wholly discrete
or wholly continuous; but since one type of change predominates for most
systems, it will usually be possible to classify a system as being either
discrete or continuous.
At
some point in the lives of most systems, there is a need to study them to try
to gain some insight into the relationship among various components, or to
predict performance under some new conditions being considered.
2.3 Experiment With The Actual
System Vs. Experiment With A Model Of The System.
If it is possible (and cost-effective) to alter the system
physically and then let it operate under the new conditions, it is probably
desirable to do so, for in this case there is no question about whether what we
study is valid. However, it is rarely feasible to do this, because such an
experiment would often be too costly or too disruptive to the system. For
example, a bank may be contemplating reducing the number of tellers to decrease
costs, but actually trying this could lead to long customer delays and
alienation. More graphically, the "system" might not even exist, but
we nevertheless want to study it in its various proposed alternative
configurations to see how it should be built in the first place; examples of
this situation might be a proposed communications network, or a strategic
nuclear weapons system. For these reasons, it is usually necessary to build a
model as a representation of the system and study it as a surrogate for the
actual system. When using a model, there is always the question of whether it
accurately reflects the system for the purposes of the decisions to be made..
2.4 Physical Model vs.
Mathematical Model.
To most people, the word "model" evokes images
of clay cars in wind tunnels, cockpits disconnected from their airplanes to be
used in pilot training, or miniature supertankers scurrying about in a swimming
pool. These are examples of physical
models (also called iconic models), and are not typical of the kinds of models
that are usually of interest in operations research and systems analysis. Occasionally, however, it has been found
useful to build physical models to study engineering or management systems;
examples include tabletop scale models of material-handling systems, and in at
least one case a full-scale physical model of a fast-food restaurant inside a
warehouse, complete with full-scale, real (and presumably hungry) humans [see
Swart and Donno (1981)]. But the vast majority of models built for such
purposes are mathematical, representing a system in terms of logical and
quantitative relationships that are then manipulated and changed to see how the
model reacts, and thus how the system would react—if the mathematical model is
a valid one. Perhaps the simplest example of a mathematical model is the
familiar relation d = rt, where r is the rate of travel, t is the time spent
traveling, and d is the distance traveled. This might provide a valid model in
one instance (e.g., a space probe to another planet after it has attained its
flight velocity) but a very poor model for other purposes (e.g., rush-hour
commuting on congested urban freeways).
2.5 Analytical Solution
vs. Simulation.
Once we have built a mathematical model, it must then be
examined to see how it can be used to answer the questions of interest about
the system it is supposed to represent. If the model is simple enough, it may
be possible to work with its relationships and quantities to get an exact,
analytical solution. In the d =rt example, if we know the distance to be
traveled and the velocity, then we can work with the model to get t = d/r as
the time that will be required. This is a very simple, closed-form solution
obtainable with just paper and pencil, but some analytical solutions can become
extraordinarily complex, requiring vast computing resources; inverting a large
non sparse matrix is a well-known example of a situation in which there is an
analytical formula known in principle, but obtaining it numerically in a given
instance is far from trivial. If an analytical solution to a mathematical model
is available and is computationally efficient, it is usually desirable to study
the model in this way rather than via a simulation. However, many systems are
highly complex, so that valid mathematical models of them are themselves
complex^ precluding any possibility of an analytical solution. In this case,
the model must be studied by means of simulation, i.e., numerically exercising the
model for the inputs in question to see how they affect the output measures of
performance.
While there may be a small element of truth to pejorative
old saws such as "method of last resort" sometimes used to describe
simulation, the fact is that we are very quickly led to simulation in most
situations, due to the sheer complexity of the systems of interest and of the
models necessary to represent them in a valid way.
Given, then, that we have a mathematical model to be
studied by means of simulation (henceforth referred to as a simulation model),
we must then look for particular tools to do this. It is useful for this
purpose to classify simulation models along three different dimensions:
2.6 Static Vs. Dynamic
Simulation Models.
A static simulation model is a representation of a system
at a particular time, or one that may be used to represent a system in which
time simply plays no role.. On the other hand, a dynamic simulation model
represents a system as it evolves over time, such as a conveyor system in a
factory.
2.7 Deterministic vs.
Stochastic Simulation Models.
If a simulation model does not contain any
probabilistic (i.e., random) components, it is called deterministic', a
complicated (and analytically intractable) system of differential equations
describing a chemical reaction might be such a model. In deterministic models,
the output is "determined" once the set of input quantities and
relationships in the model have been specified, even though it might take a lot
of computer time to evaluate what it is. Many systems, however, must be modeled
as having at least some random input components, and these give rise to
stochastic simulation models. (For an example of the danger of ignoring
randomness in modeling a system, Most queuing and inventory systems are modeled
stochastically. Stochastic simulation models produce output that is itself
random, and must therefore be treated as only an estimate of the true
characteristics of the model; this is one of the main disadvantages of
simulation
2.8 Continuous Vs.
Discrete Simulation Models.
Loosely speaking, we define discrete and continuous
simulation models analogously to the way discrete and continuous systems were
defined above. More precise definitions of discrete (event) simulation and
continuous simulation, respectively. It should be mentioned that a discrete
model is not always used to model a discrete system, and vice versa. The
decision whether to use a discrete or a continuous model for a particular
system depends on the specific objectives of the study. For example, a model of
traffic flow on a freeway would be discrete if the characteristics and movement
of individual cars are important. Alternatively, if the cars can be treated
"in the aggregate," the flow of traffic can be described by
differential equations in a continuous model.
3.DISCRETE-EVENT
SIMULATION
Discrete-event simulation concerns the modeling of a
system as it evolves over time by a representation in which the state variables
change instantaneously at separate points in time. (In more mathematical terms,
we might say that the system can change at only a countable number of points in
time.) These points in time are the ones at which an event occurs, where an
event is defined as an instantaneous occurrence that may change the state of
the system. Although discrete-event simulation could conceptually be done by
hand calculations, the amount of data that must be stored and manipulated for
most real-world systems dictates that discrete-event simulations be done on a
digital computer. [14]
3.1 Time Advance
Mechanisms
Historically, two principal approaches have been suggested
for advancing the simulation clock: next-event time advance and fixed-increment
time advance. Since the first approach is used by all major simulation software
and by most people programming their model in a general-purpose language, and
since the second is a special case of the first, we shall use the next-event
time-advance approach for all discrete-event simulation models. [1]
With
the next-event time-advance approach, the simulation clock is initialized to
zero and the times of occurrence of future events are determined. The
simulation clock is then advanced to the time of occurrence of the most
imminent (first) of these future events, at which point the state of the system
is updated to account for the fact that an event has occurred, and our
knowledge of the times of occurrence of future events is also updated. Then the
simulation clock is advanced to the time of the (new) most imminent event, the
state of the system is updated, and future event times are determined, etc.
This process of advancing the simulation clock from one event time to another
is continued until eventually some pre-specified stopping condition is
satisfied. Since all state changes occur only at event times for a discrete
event simulation model, periods of inactivity are skipped over by jumping the
clock from event time. (Fixed-increment
time advance does not skip over these inactive periods, which can eat up a lot
of computer time; It should be noted that the successive jumps of the
simulation clock are generally variable (or unequal) in size.
3.2 Components and
Organization of a Discrete-Event Simulation Model
Although simulation has been applied to a great diversity
of real-world systems, discrete- event simulation models all share a number of
common components and there is a logical organization for these components that
promotes the programming, debugging, and future changing of a simulation
model's computer program. In particular, the following components will be found
in most discrete-event simulation models using the next-event time-advance
approach programmed in a general-purpose language:
System state: The collection of state variables necessary to describe
the system at a particular time.
Simulation clock: A variable giving the current value of simulated time
Event list: A list containing the next time when each type of event will occur
Statistical counters: Variables used for storing statistical information about
system performance
Initialization routine: A subprogram to initialize the simulation model at time 0
Timing routine: A subprogram that determines the next event from the event list
and then advances the simulation clock to the time when that event is to occur
Event routine: A subprogram that updates the system state when a particular
type of event occurs (there is one event routine for each event type)
Library routines: A set of subprograms used to generate random observations
from probability distributions that were determined as part of the simulation
model.
Report generator: A subprogram that computes estimates (from the
statistical counters) of the desired measures of performance and produces a
report when the simulation ends
Main program: A subprogram that invokes the timing routine to determine
the next event and then transfers control to the corresponding event routine to
update the system state appropriately. The main program may also check for
termination and invoke the report generator when the simulation is over.
3.3 Steps In A Sound
Simulation Study
Now that we have looked in some detail at the inner
workings of a discrete-event simulation, we need to step back and realize that
model programming is just part of the overall effort to design or analyze a
complex system by simulation. Attention must be paid to a variety of other
concerns such as modeling system randomness, validation, statistical analysis
of simulation output data, and project management. [see also Banks et al.
(2005, pp. 14-18) and Law (2003)]. The number beside the symbol representing
each step refers to the more detailed description of that step below. Note that
a simulation study is not a simple sequential process. As one proceeds with the
study, it may be necessary to go back to a previous step.[15]
1. Formulate the problem and plan the study.
a. Problem of interest is stated by manager.
·
Problem may not be stated
correctly or in quantitative terms.
·
An iterative process is
often necessary.
b. One or more
kickoff meetings for the study are conducted, with the project manager, the
simulation analysts, and subject – matter experts (SMEs) in attendance. The following things are discussed :
·
Overall objectives of the
study.
·
Specific questions to be
answered by the study (required to decide level of model detail)
·
Performance measures that
will be used to evaluate the efficacy of different system configurations.
·
Scope of the model
·
System configurations to be
modeled (required to decide generality of simulation program)
·
Time frame for the study and
the required resources.
c. Select the software for the model
2. Collect data
and define a model.
a. Collect
information on the system structure and operating procedures.
·
No single person or document
is sufficient.
·
Some people may have
inaccurate information – make sure that true SMEs are identified.
·
Operating procedures may not
be formalized.
b.
Collect data (if possible)
to specify model parameters and input probability distributions Delineate above
information and data in a written assumptions document Collect data (if
possible) on the performance of the existing system (for validation purposes in
step 6).
c.
Choosing the level of model
detail, which is an art, should depend on the following:
·
Project objectives
·
Performance measures
·
Data availability
·
Credibility concerns
·
Computer constraints
·
Opinions of SMEs
·
Time and money constraints
d.
There should not be a
one-to-one correspondence between each element of the model and the
corresponding element of the system.
e.
Start with a
"simple" model and embellish it as needed. Modeling each aspect of
the system will seldom be required to make effective decisions, and might
result in excessive model execution time, in missed deadlines, or in obscuring
important system factors.
f.
Interact with the manager
(and other key project personnel) on a regular basis
3. Is the
assumption? document valid?
a. Perform a
structured walk-through of the assumptions document before an audience of
managers, analysts, and SMEs (. This will
·
Help ensure that the model's
assumptions are correct and complete
·
Promote interaction among
the project members
·
Promote ownership of the
model
·
Take place before
programming begins, to avoid significant reprogramming later
4. Construct a computer program and verify.
a. Program the
model in a programming language (e.g., C or C++) or in simulation software
(e.g., Arena, Extend, Flexsim, and ProModel). Benefits of using a programming
language are that one is often known, they offer greater program control, they
have a low purchase cost, and they may result in a smaller model-execution
time. The use of simulation software, on the other hand, reduces programming
time and results in a lower project cost.
b. Verify
(debug) the simulation computer program.
5. Make pilot
runs.
a. Make pilot runs for validation purposes in
step 6.
6. Is the
programmed model valid?
a. If there is
an existing system, then compare model and system (from step 2) performance
measures for the existing system.
b. Regardless
of whether there is an existing system, the simulation analysts and SMEs should
review the model results for correctness.
c. Use
sensitivity analyses to determine what
model factors have a significant impact on performance measures and, thus, have
to be modeled carefully.
7. Design
experiments.
a. Specify the following for each system
configuration of interest:
·
Length of each simulation
run
·
Length of the warm up
period, if one is appropriate
·
Number of independent
simulation runs using different random numbers—facilitates construction of
confidence intervals
8. Make
production runs.
a. Production runs are made for use in step
9.
9. Analyze
output data.
a. Two
major objectives in analyzing output data are to
·
Determine the absolute performance of certain system
configurations
·
Compare
alternative system configurations in a relative
sense
10. Document, present, and use results.
a. Document
assumptions, computer program, and study's results for use in the current and
future projects.
b. Present
study's results.
·
Use animation to communicate model to managers and other
people who are not familiar with all the model details.
·
Discuss model building and
validation process to promote credibility.
·
Results are used in
decision-making process if they are both valid and credible.
3.4 Continuous Simulation
Continuous simulation concerns the modeling over time of a
system by a representation in which the state variables change continuously
with respect to time. Typically, continuous simulation models involve
differential equations that give relationships for the rates of change of the
state variables with time. If the differential equations are particularly
simple, they can be solved analytically to give the values of the state
variables for all values of time as a function of the values of the state
variables at time 0. For most continuous models analytic solutions are not
possible, however, and numerical-analysis techniques, e.g., Runge-Kutta
integration, are used to integrate the differential equations numerically,
given specific values for the state variables at time 0.
Several simulation products such as SIMULINK, ACSL, and
Dymola have been specifically designed for building continuous simulation
models. In addition, the discrete-event simulation packages Arena [see Kelton
et al. (2004)] and Extend [Imagine (2006)] have continuous modeling
capabilities. These two simulation packages have the added advantage of
allowing both discrete and continuous components simultaneously in one
model. [11]
3.5 Advantages,
Disadvantages, And Pitfalls Of Simulation
Simulation is a widely used and increasingly popular
method for studying complex systems.
Some possible advantages of simulation that may account for its
widespread appeal are the following.
·
Most complex, real-world
systems with stochastic elements cannot be accurately described by a
mathematical model that can be evaluated analytically. Thus, a simulation is often the only type of
investigation possible.
·
Simulation allows one to
estimate the performance of an existing system under some projected set of
operating conditions.
·
Alternative proposed system
designs (or alternative operating policies for a single system) can be compared
via simulation to see which best meets a specified requirement.
·
In a simulation we can
maintain much better control over experimental conditions than would generally
be possible when experimenting with the system itself
·
Simulation allows us to
study a system with a long time frame—e.g., an economic system—in compressed
time, or alternatively to study the detailed workings of a system in expanded
time.
Simulation is not without its drawbacks. Some
disadvantages are as follows.
·
Each run of a stochastic
simulation model produces only estimates of a model's true characteristics for
a particular set of input parameters. Thus, several independent runs of the
model will probably be required for each set of input parameters to be studied.
For this reason, simulation models are generally, not as good at optimization
as they are at comparing a fixed number of specified alternative system
designs. On the other hand, an analytic model, if appropriate, can often easily
produce the exact true characteristics of that model for a variety of sets of
input parameters. Thus, if a "valid" analytic model is available or
can easily be developed, it will generally be preferable to a simulation model.
·
Simulation models are often
expensive and time-consuming to develop.
·
The large volume of numbers
produced by a simulation study or the persuasive impact of a realistic
animation often creates a tendency to place greater confidence in a study's
results than is justified. If a model is not a "valid" representation
of a system under study, the simulation results, no matter how impressive they
appear, will provide little useful information about the actual system.
When deciding whether or not a simulation study is
appropriate in a given situation, we can only advise that these advantages and
drawbacks be kept in mind and that all other relevant facets of one's
particular situation be brought to bear as well. Finally, note that in some
studies both simulation and analytic models might be useful. In particular,
simulation can be used to check the validity of assumptions needed in an
analytic model. On the other hand, an analytic model can suggest reasonable
alternatives to investigate in a simulation study.[18]
Assuming that a decision has been made to use simulation,
we have found the r following pitfalls to the successful completion of a
simulation study [see also Law and McComas (1989)]:
·
Failure to have a well-defined
set of objectives at the beginning of the simulation study
·
Failure to have the entire
project team involved at the beginning of the study appropriate level of model
detail
·
Failure to communicate with
management throughout the course of the simulation study
·
Misunderstanding of
simulation by management
·
Treating a simulation study
as if it were primarily an exercise in computer programming
·
Failure to have people with
a knowledge of simulation methodology and statistics on the modeling team
·
Failure to collect good
system data
·
Inappropriate simulation
software.
·
Obliviously using simulation
– software products whose complex macro statements may not be well documented
and may not implement the desired modeling logic.
·
Belief that easy-to-use
simulation packages, which require little or no programming, require a
significantly lower level of technical competence.
·
Misuse of animation
·
Failure to account correctly
for sources of randomness in the actual system.
·
Using arbitrary
distributions (e.g., normal, uniform, or triangular) as input to the simulation
·
Analyzing the output data
from one simulation run (replication) using formulas that assume independence.
·
Making a single replication
of a particular system design and treating the output statistics as the “true
answers”
·
Failure to have a warm up
period, if the steady-state behavior of a system is of interest.
·
Comparing alternative system
designs on the basis of one replication for each design.
· Using the wrong performance measures.
4.LITERATURE REVIEW
Simulation
is a powerful tool for the analysis of new system designs, retrofits to
existing systems and proposed changes to
operating rules. Conducting a valid simulation is both an art and a science. [John
S. Carson, II AutoMod Group]
Applications of discrete event
simulation in the design of Automotive
power train anufacturing systems by The need for and uses of discrete event simulation
in the design of test stands for powertrain assemblies and illustrates the
application using a simulation
experiment used to improve the design of a typical test stand configuration is stated [Arun Jayaraman Production
Modeling Corporation Dearborn, MI] The sketch shows a fairly common yet simple arrangement of
the test stands and repair area. This basic
structure is modified for further improvements or for handling greater
capacity. A few more clarifications can
be made about the operation and issues with a typical test loop, using
the sketch above. The direction of flow
has been shown using arrows. Henceforth
the term pallet refers to a pallet with an engine assembly on it.
Pallets are
routed to one of three test stands - T1, T2 or T3. Pallets are routed off-line to one of the stands using the spur conveyors connecting each test
stand to the main line. Pallets are tagged
as ‘good’ or ‘rejected’ based on the test.
At point B, good engines continue straight down the main
conveyor. Rejected pallets are routed to
point D using the conveyor leading to
D. The rejected pallets are then
repaired and routed by conveyor to point C and then to Point A. These repaired engines are then routed to one
of the test stands for re-testing.[3]
Two
modes of operation are possible. In the
first mode, engines are not allowed past point A unless
a test stand is available for engines to go to.
This leads to a backup of pallets at Point A. Pallets tagged to be repaired are routed to
the repair area. Once repaired, these pallets are routed back to point
A where they are given higher priority to be re-tested (to avoid back-ups at
the repair area). In the second
operation mode, the repair operation is done off-line.
|
The
four scenarios and the throughput capability of the sub-system in each case is discussed
in the following section. In each case,
the system performance was measured in average number
of Jobs Produced Per Hour (JPH). The
time taken by a test stand to repair an
engine was 57 seconds, across all four models.
The time to repair a rejected engine was assumed to be
triangularly distributed with a most likely value of 5 minutes (and the minimum
time was 2 minutes and the maximum time was 8 minutes). All conveyors
operated at a speed of 20 Feet Per Minute across all models. A total reject rate of 3% was used across all
three test stands. Rejects were
generated on a random basis. It was
assumed that all rejected engines could be repaired at the repair area. In other words,there is no scrap.
The same
random number streams were used across all four models in order to
ensure
unbiased comparison. Each model was
simulated for a period representing 100 hours of
production. In each simulation the first
two hours were designated as the warm- up period. No reliability issues were included in any
model. In other words, it was assumed that none of the test stands experienced
any breakdowns. The gross throughput capability
of the system (assuming no rejects) is 189.4 Jobs Per Hour.
SCENARIO 1 : In this scenario, Operation mode 1
was used. Thus engines to be tested are allowed past point A only if there is a
test stand available. As soon as one stand becomes available, an engine is
allowed to enter the loop.
Successfully tested engines continue
on the main line conveyor past point C.
If an engine is tagged as a reject, it
is routed down to point D and to the repair area. Repaired engines are routed back to the test
stands for re-testing. At point A,
priority is given for repaired engines to re-enter the loop when a stand
becomes available. From the simulation
run, the average throughput capability was determined to be 125.19 Jobs Per
Hour.[3]
SCENARIO 2 :
In this scenario, Operation mode 2 was used.
Thus pallets (loaded with engines)
were allowed past point A even if no test stand was available (currently
testing engines). If an untested engine
got to point B, it is routed down to point D and re-routed back to point A for
testing. Pallets continue re-circulating
until they are successfully tested. From
the simulation run, the average throughput capability of the system was
determined to be 178.05 Jobs Per Hour - a significant improvement over scenario 1.
This can be explained by the fact that for the most part, test
stands will not have to wait for engines to travel from point A after a stand
is freed. The reduced waiting leads to better utilization of the test stands. As evident, the savings in travel time leads
to an improvement of 60 Jobs Per Hour.
SCENARIO 3 :
This was a modification of scenario 1.
As shown in figure , three
additional
buffers were added, one across the main conveyor from each stand. These buffers have been denoted as B1, B2
& B3 in the figure. If the test
stands are busy, then engines can be routed to an empty buffer. Thus as soon as a test stand becomes
available, it can draw an engine from the buffer across
it. In the simulation model, it takes 5 seconds for an engine to be transferred from the
buffer to the stand. This reduces the
idle time of the stands due to lack of untested engines waiting to be
transferred immediately to the stand when it becomes available. From the simulation run, the average
throughput capability of the system was determined to be 171.4 Jobs Per Hour, a
significant
improvement
over Scenario 1.
SCENARIO 4 :
This scenario was a modification of scenario 2. Similar to scenario 3, in this case three buffers were added across the
test stands and the operation mode is the same as that in Scenario 2. Thus untested engines are re-circulating
continuously and enter a test stand or buffer if one becomes available. Also, priority is given for an engine waiting
in the buffer to be routed to the test stand as opposed to an engine from the
main conveyor. However, it takes five
seconds for an engine to be transferred from the buffer to the test
stand across it. From the simulation
run, the average throughput capability of the system was determined to be 172.3
Jobs Per Hour. This is a loss in
throughput compared to Scenario 2. The
increased transfer time from the buffer to the tests stand causes the loss in throughput. Thus in the case of operation mode 2,
addition of buffers across from the test stands leads to a loss in system
throughput. From the simulation experiments on the test stand sub-system, it
was determined that Scenario 2 was the
optimal scenario.
Classification of the Applications of
Simulation in the Automotive Industry
[Simulation in automobile industry – Onur
Ulgen(production modeling corporation & university of Michigan-Dearborn)
Ali Gunal (production modeling corporation]
|
Simulation model life-cycle approaches are
discussed next. In the final two sections of the chapter we review the emerging role of robotics simulation and discuss trends in the
future of simulation in the automotive industry [2]
In
what follows, we discuss mainly the applications of discrete-event simulation
in the automotive industry. Applications of discrete-event simulation in the design
and operation of vehicle manufacturing systems can be categorized in two
different ways. The first classification is based on the stage of the
development of the design of the system. Four categories are observed
in this
classification: conceptual design phase, detailed design phase, launching
phase, and fully operational phase. The conceptual phase refers to the
initial stage where new methods of manufacturing and material handling are
tested by the engineers. Discrete-event simulation packages with
three-dimensional animation capabilities are the popular simulation tools at
this phase. The detailed design phase refers to the stage where detailed
layout plans and equipment specifications are verified for the system. The
principal factors considered here include equipment justifications (e.g., the
number of hold tables, power and free carriers,
the size of
buffers), cycle-time verifications (e.g., conveyor speeds, line throughput),
and line operational and scheduling issues (e.g., logic for evacuating ovens
and paint booths, repairs, and product mix decisions). Discrete-event
simulation packages with built-in detailed equipment features and
three-dimensional animation features appear to be the most popular packages
used at this stage. The launching phase refers to the stage where the
plant operates below the designed operational conditions. In some cases it may
take up
to 6 months
for the plant to operate under maximum-capacity conditions. Simulation studies
performed at this stage are generally used to test operational policies (e.g.,
operate one of the two paint booths at a time, run each shop for one-half of
the total available time, use different product mixes). Discrete-event
simulation
packages used at this stage do not typically require the detailed equipment
features or the three-dimensional animation features. The simulation program
generators with user-friendly features are the most popular packages used at
this phase, as models tend to be at a macro level rather than a micro level.
An
explanation of macro and micro models, and an example of their interactions,
appears in ref. 9. The fully operational phase refers to the stage where
the plant is operating at its anticipated capacity. The simulation studies done
at this phase consider product mix decisions, new product introductions, new operational
policies, and line modifications. Simulation software used at this phase
generally require the same capabilities as those used at the launching phase.
The second
classification of the use of discrete-event simulation in automotive
manufacturing plants is based on the nature of the problem to be investigated.
Four major categories can also be identified in this classification: equipment
and layout design issues, issues related to variation management, product-mix
sequencing
issues, and other operational issues. The equipment and layout design issues
include typical problems such as number of machines required, cycle-time
verification, identification of buffer storage locations, buffer size (strip
conveyors and buffers for sequencing) analysis, and conveyor length and speed etermination.
Examples of typical problems in the variation management area are repair and
scrap policy analysis, order-size variation, and paint booth scheduling. The product-mix
sequencing issues typically include trim line and body shop sequencing,
shift scheduling, and trim and final assembly line balancing.
In the other
operational issues area, typical applications involve priority ssignment at
traffic intersections, assembly-line sequencing, and shift and break
scheduling. Table 15.1 summarizes various uses of simulation in vehicle
assembly plants. The x-marks indicate typical phases(s) where simulation can
play an
essential
role for the application area listed and where certain types of problems are
more likely to be attacked by the designers or managers. For example,
cycle-time verification problems are more likely to arise at earlier stages of
the design and operation cycle. However, shift-scheduling problems are likely
to be solved once all equipment and layout design issues are finalized. It
should be noted, however, that the table constitutes only a broad framework
since, in reality, each type of problem area can be attacked in any phase of
the design cycle.
In
the following sections of this chapter, we discuss applications of
discrete-event simulation in assembly plants, major-component plants, and small-components
plants. Then we consider the nonmanufacturing applications of discrete-event
simulation.
Case Study: Body Shop
Material Handling System Analysis
This
simulation study was performed during the conceptual design phase of a new
vehicle program for a major U.S. car manufacturer. The system studied consisted
of the following components: (1) a car track system with several sections, (2)
90˚ turn tables between various sections of the car track system, (3) several robotic
spot welding stations, (4) two load/unload stations for two different car
models, and (5) a variable number of carriers for each car model. [3]
The objectives of the study were threefold:
1. Determine the best equipment
configuration and the corresponding line throughput under a given set of
operating parameters.
2. Determine the maximum allowable cycle
time at the loading stations for either car model.
3. Determine the best number of carriers
for each car model.
TABLE Results of Four Scenarios
Table 2 : Results of Four Scenarios
5.PROBLEM STATEMENTS
Engine decking process consist
some of the following operations of engine assembly to the body of vehicle.
Engine Subassembly
·
Engine
Inspection
·
Fitment
of FIP main line
·
Fitment
of return line rubber hose on FIP return line
·
Clipping
of FIP main & return line
·
Insertion
of top rubber on cradle tube
·
Loading
of engine on decking trolley
Fitment of power train
·
Power
train Positioning
·
Engine
tightening
·
Fitment
of Transmission support bkt on chassis with propeller shaft guard
·
Fitment
of vacuum hose on vacuum reservior tank
·
Routing
of main fuel line , return fuel line & Negative cable
In existing process all these assembly
operations worker has to move with conveyer and fitting engine on body. For
whole shift it was difficult for worker to aligning of engine , torquing etc.
so existing process has to change.Task is to develop new method convenient to
assembly workers and achieve desired output in terms of JPH.(jobs per hour) .In
new method, engine on self propelled trolley will stop for assembling with
vehicle body at station with some time known as engine decking cycle time. We
have to optimize that time with the help of simulation. following are some of
task for that we have to use simulation techniques.
·
Validate Stop and Go Concept for Engine Decking
process
·
Validate/predict System throughput
·
Validate/optimize Engine Decking Operation cycle time
·
Optimize EMS Hanger Speed
·
Optimization Engine trolley
·
What-if analysis
6. METHODOLOGY
6.1Implement a Simulation Project
Before you start implementing your
simulation project, you will, more or less, proceed like this. You will:
Determine the goals, so that
the purpose of the simulation project becomes clear. Why are you examining a
problem? Which questions do you want answered? Put the definition of the
project in writing and consult it repeatedly during the course of the project,
as the purpose of the simulation study determines the efforts to be made.
Create a concept of your model,
with its initial values, its model elements, variables, logic of proceeding and
a preliminary description of the simulation experiments. Which parameters do
you have to change, which data do you have to collect and how do you interpret
this data? Make a list of all functional units that the installation you are
modeling will contain. Think about which functional units have identical or
similar functionality. Combine them and derive a list of application objects
you and your colleagues have to create. Consider re-using existing objects.
Specify and plan the remaining objects on paper. Define and describe the
interfaces for material and information flow. Outline reset and init Methods.
Ensure early on that the data
you need to run the simulation experiments is going to be available. Frequently
a lot of time and effort is involved to acquire the data. Make sure that you
have the name of a person who responsible for acquiring the data from your
client, which may, for example, be another department of your company.
Build a first version of the simulation model in its
simplest, most basic form. Build the application objects you need and test them
one by one. After you are sure that all objects work the way they are supposed
to do, put together the overall model. Document the model in a clearly arranged
manner, as six months or a year from the time you modeled you might not
remember how you accomplished a certain task or why you solved a specific
problem the way you did.
After you are finished building the simulation model, you
have to verify it, i.e., check if the components you modeled perform the tasks
you programmed them to do. Test each and every object you created. Check for
the correct functioning and for concurrence with the specifications. Test the objects
in combination with other objects and then in the overall model. Make sure that
all parameters are set to the correct values. Once you have verified the model,
check it for its validity: Make sure the functionality of the model is as
expected and conforms to the functionality of the planned or real installation
and see if the results are plausible and credible. Make an estimate of the most
important results and compare them with the results of the simulation.
Introduce your model to a production or planning expert and discuss the
results, the proceedings and your modeling approach with him.
Execute simulation experiments according to your final trial
plans to arrive at the desired data. Plan a number of simulation runs and
prepare for the variation of parameters and models to get reliable results.
Analyze and interpret the results of the simulation
experiments. Conduct a sensitivity analysis of the most important parameters,
data and results.
Once you are finished with the
simulation project, update the notes you made while modeling to create the
final documentation of the entire simulation project. This will help you, when
you have to update or extend your simulation model or any of its components.
Executing simulation experiments is a cyclical and evolutionary process. You
will modify and improve your initial simulation model a number of times as you
incorporate new insights from previous simulation runs. Thus you will arrive at
your final simulation model after several cycles after continuously changing
your initial draft of your simulation model.[15]
Tecnomatix
Plant Simulation
provides these objects for simulating the flow of materials through a plant: [14]
·
The EventController for coordinating and synchronizing the events taking place
during a simulation run.
·
The Frame
as the container for creating your simulation models. It might, for example,
represent a complex machine, a part of an installation, or the entire plant.
·
The FlowControl
for modeling common strategies for splitting-up and bringing together the flow
of materials.
·
The TwoLaneTrack
for modeling a part of a transport line with two lanes on which traffic moves
in opposing directions.
·
The Transporterfor
modeling self-propelled vehicles allowing it to drive on its own on a Track
and to transport parts.
·
The Broker
for brokering offered services and required services. You might model the
supervisor of an installation or the foreman of a shop with it.
·
The Exporter
for providing and exporting services. It represents a group of people, whose
individual members you cannot distinguish and whom you cannot address as
individuals.
6.3 MATERIAL FIOW OBJECTS
Buffer
The Buffer significantly improves performance, as compared to the PlaceBuffer, when you model a buffer that holds a large number of MUs. The Buffer does not provide a point-oriented structure, and thus does not have to divide the processing time, i.e., the time during which the MU remains in the buffer, into small steps.
 |
The
Buffer thus significantly improves performance, when you model a buffer
with a large Capacity,
which does not require the advanced functions of the PlaceBuffer.
The
Connector establishes material flow connections between two objects in
the same Frame on which the parts move from object to object. It also
connects an object with an exit or entrance—modeled with the Interface—of
a Frame. The Connector shows the direction of the connection with
an arrowhead in the middle of the connecting line.
The
object Cycle synchronizes the transfer of MUs from station to station.
You can use it to only move a part on to the next station within a balanced
line, when all stations have finished processing their parts and when none of
the stations are failed, paused or unplanned. In addition, the successor of the
balanced line has to be ready to receive the part.
To
define the balanced line, enter the name of the first station and of the
last station into the text boxes. All stations between the first and the
last station, which are connected with Connectors form the balanced
line. It has to have a predecessor and a successor.
You can insert as many Cycle
objects as you need into your model. They all work independent of each other.
When you use several Cycle objects, make sure to only assign each
station to a single Cycle object.
DismantleStation
The
DismantleStation removes mounting parts from the main MU or it creates
new MUs. Use it to model dismantle processes in your installation. To assemble
parts, you can use the Assembly Station.
The
Drain removes the parts and workpieces, which the Source
produced, from the plant after they have been
processed. You can use it to model the shipping department of your
installation.
produced, from the plant after they have been
processed. You can use it to model the shipping department of your
installation.
The
built-in properties of the Drain are the same as those of the SingleProc.
Like it, it has a single processing station. The only difference is that the Drain
destroys the processed MU instead of moving it on to a succeeding object in the
flow of materials.
EventController
The
EventController coordinates
and synchronizes the different events taking place during a simulation run.
Plant
Simulation is a
discrete event simulation system that shows the state changes of the model
components at certain points in time, not continually over time. When an MU
enters a processing station, for example a SingleProc,
Plant Simulation
computes the time it takes to process it and enters that event and that time
into the List of Scheduled Events of the EventController.
Plant Simulation
considers these events in a discrete way, step by step. The main advantage of
this approach is that it skips the time that elapses in real time between the
events. Imagine a time line where you insert markers at certain points.
The
EventController
moves along the time line like the play-back head of a video recorder, and
interprets messages relating to the events the objects execute. After the
processing time has elapsed, the EventController
passes on to the station that has to initiate an exit (Out) events, the SingleProc
in our case. The MU then moves on to the succeeding object in the flow of
materials. There again, Plant
Simulation calculates the exit time and passes it to the EventController. It then sets
a marker at the point in time the station has to move the MU to the next
station. Plant Simulation
repeats this process cyclically for all MUs located in the simulation model.
The
FlowControl allows to model common strategies for splitting-up and for
bringing together the flow of materials. Note that the FlowControl does
not process the MUs, it only distributes them among the objects that succeed it
in the sequence of stations in the simulation model.
Insert
the FlowControl between two other objects to control the flow of materials
between these objects. If need be, you can also combine several FlowControl
objects.
|
|
Create
your simulation models in the Frame located in the folder Models
in the Class Library. The Frame serves for grouping objects and
to build hierarchically structured models by inserting any of the built-in
objects or any objects you design. Model transitions from Frame to Frame
with the object Interface.
Connect objects within the Frame and Frames with the object Connector.
When
you connect Frames with Connectors, Plant Simulation opens
the dialog Select Interface in which you have to select an Interface,
which you inserted into the Frame.
Interface
You
can model transitions between Frames with the object Interface.
These interfaces are the places at which the MUs pass from one Frame
to another in your simulation model. You can position the Interface
anywhere in a Frame.
For
an Interface object, which you inserted into a Frame, Plant
Simulation shows if the Interface is connected to another object
with a Connector.
With
the object Line you can model a conveyor system or a part thereof. As
opposed to the other material flow objects, Plant Simulation uses the
actual Length,
which you enter, during your simulation run. The Line transports an MU
along its entire length with a constant speed. An MU cannot pass another MU
moving along in front of it. If you do not enter an exit control, the Line
divides the MUs equally among the successors it is connected to.
In
case the preceding MU cannot exit the Line, the check box Accumulating
sets if succeeding MUs may move up, so that they are located front to back to
each other, or if they will retain their distance to each other.
When
moving the MU from Line to Line, Plant Simulation passes it on continually,
i.e., it only moves the front of the MU on to the successor, while the
remainder of the MU follows with the speed you set as the Speed.
When the transport speeds differ, Plant Simulation uses the speed of the
Line, on which the Booking point width of the MU is located.
You
can also enter the MU distance
between parts on the Line. This is the distance between the end of the
part that is located on the Line and the beginning of the next part that
wants to enter. When no further parts are supplied, the Line stops once
the distance has been reached. As soon as the next part arrives, it starts to
transport parts again. The default value -1 means that the Line
does not use an MU distance.
The ParallelProc has several
stations for processing mobile objects (MUs) in parallel at the same time. The
built-in properties of the ParallelProc are the same as those of a SingleProc
with several processing stations.
When
you do not enter a special entrance control, the ParallelProc places an
incoming MU onto a random station. A set-up time always applies, when an MU has
a different name than the MU it processed before, i.e., its predecessor. Plant
Simulation always moves the MU as a whole not continually, i.e., as soon as
its front is located on the ParallelProc, the entire MU is located on
it.
|
|
The
pick-and-place robot picks a part up at one station and places it
onto another station. It moves a single part at any one time.
The
pick-and-place robot moves the part on to its successors within
the flow of materials like this:
·
The
part arrives at the exit of the predecessor. It notifies the pick-and-place
robot that it wants to be picked up.
·
Without
a pull control, the robot will be notified that a part wants to
be picked up and it accepts it.
·
When
you entered a Pull control,
the robot executes it, and when the part is selected, it will be picked up.
·
For
determining the target station, the robot either uses its default exit
strategies or the Target control.
Within this method you set the target station.
The
target control is called, when the robot picks up or when it places a
part. Within the method setDestination
the boolean argument controls, if the robot waits at the target station.
The PlaceBuffer has a number
of stations, arranged in a row, one behind the other. The MUs it processes have
to advance from station to station and can only leave the PlaceBuffer
after they passed the last station. This way, you can call each and every
station individually.
An
MU can move directly to an idle station in the PlaceBuffer. When you
create an MU on an idle station, it may pass on to the next station or the next
object.
·
To
make the MUs accumulate on the PlaceBuffer, select the check box Accumulating.
This allows the MUs to move front to end to each other, when the exit of the PlaceBuffer
is blocked.
·
To
make the MUs retain their distance to each other, i.e., make all succeeding MUs
stop moving when the preceding MU cannot exit, clear Accumulating.
You
can only define the processing time for the PlaceBuffer as whole, not
for each individual station. It divides the processing time equally among its
stations, i.e., when you set a processing time of 60 seconds for 3 stations,
each station processes the MU for 20 seconds.
|
|
The SingleProc has a single
station for processing an MU. The SingleProc receives an MU from its
predecessor, processes it and passes it on to the successor.
If the types of MU are not the same,
i.e., if they do not have the same name, the SingleProc has to set up to
process this new type of MU. While an MU is located on the SingleProc,
it does not receive any additional MU. An MU may only enter, when the SingleProc
is available, i.e., when no other MU is located on it. Plant Simulation
always moves the MU as a whole not continually, i.e., as soon as its front is
located on the SingleProc, the entire MU is located on it.
The
Sorter sorts the MUs located on it according to sort criteria, which you
define. The exit sequence of the MUs depends on the priorities you set. The Sorter
moves the MU with the highest priority first, regardless of the time at which
it entered. You can define the priority of the MU with the Sort criterion
and the sort Sort order.
The data type of the sort criterion must be real or convertible to real.
When you select a Descending
sort order, the Sorter moves the MU with the highest value, with respect
to the sort criterion, first.
When you want to sort the MUs
located on the Sorter only when an MU enters, it is assumed that the
sort criterion does not change during the MUs time in the Sorter. In
this case, Plant Simulation places new MUs into the existing order of
MUs located on it.
When the value of the sort criterion
depends on the time, for example the battery charge of a Transporter, Plant
Simulation sorts the MUs every time the contents changes, especially before
an MU moves.
When an MU does not have a sort
criterion, or its data type cannot be converted to real, the MU sequence
on the object is undefined, and Plant Simulation shows an error message
in the Console. When there are several MUs with the same value for the
sort criterion, the order of these MUs with respect to each other is not
defined.
The Source produces MUs in a
single station. It has a capacity of one and no processing time. It produces
the same or different types of MUs one after the other or in a mixed sequence.
It might, for example, represent the receiving department of your
installation that introduces parts produced at another location into the plant.
Or it can be a machine, which produces the parts that the other stations
process.
You can set a procedure to determine
the times at which it creates the parts as well as a procedure to determine the
types of MUs to be produced. As an active material flow object, the Source
attempts to move the MUs it produced to the objects to which it is connected.
You can also define how the Source proceeds when it cannot move an MU to
its succeeding object, by selecting or clearing Operating mode.
You will use the Source to
produce the parts and workpieces that move through your installation and which
are processed by the different stations.
You will use the Drain to
remove these parts from the factory to model, for example, the shipping department
of your facility.
The Store stores any number
of MUs you define. They remain in the Store until you remove them, for
example by using a Method. Enter the number of storage places in a net
of coordinates, using the attributes X-dimension
and Y-dimension.
When you decrease the size of the Store,
note that you will have to delete or move MUs that are located outside of these
new coordinates. If, for example, an MU is located at the position (3,4), the
new x-coordinate may not be less than 3, and the new y-coordinate less than 4.
The Store receives MUs as
long as storage places are available. The MU triggers a sensor, when it enters
the Store. The sensor then calls an entrance control, i.e., a Method
object that determines the storage place onto which the Store places the
MU. The entrance control can update the inventory list or execute any other
action you define. If you do not define an entrance control, the Store
places the MU onto the first unoccupied storage place in the net of
coordinates.
You can use the Track to
model a part of a transport line, with or without automatic routing. The Transporter
is the only moving material flow object that can use the Track in a
meaningful way. You might, for example, utilize both to model an AGV
(automatically guided vehicle) system.
The
distance, which the Transporter has to travel on the Track—defined
by the Track's Length,
the Transporter's Length,
and its speed, defined by the Speed—determine
the time, which the Transporter remains on the Track. As opposed
to the other material flow objects, Plant Simulation uses the actual Length,
which you enter, during your simulation run. One Transporter may not
pass another one moving in front of it. Transporters thus retain their
order of moving on and exiting of the Track.
When several Transporters
travel along the Track at a different speed, and a faster one collides
with a slower one, Plant Simulation activates the collision control
of the faster Transporter and automatically reduces its speed to the
speed of the slower Transporter.
The Transporter can drive
forwards and Backwards
on the Track, i.e., it drives onto the Track at its Exit
and exits it at its Entrance. Note that driving forwards and backwards
are not properties of the Track, but of the Transporters, which
drive on it.
The maximum capacity of the Track
is defined by its length and the lengths of the individual Transporters
moving on it, i.e., a Track that is three yards long accepts three Transporters
of one yard each at the most. Use the attribute Capacity
to further restrict the number of Transporters
located on the Track.
You can use the Turntable to
model a rotating platform, which moves the part onto one of several connected
material flow objects and/or turns it around. The Turntable accommodates
a single part at any one time.
·
The
part arrives at the exit of the predecessor. It notifies the turntable that it
wants to be rotated.
·
Without
a pull control, the turntable will be notified that a part wants to be
rotated and it accepts it.
·
When
you entered a Pull control,
the turntable executes it, and when the part is selected, it will be rotated.
·
The
turntable rotates to the respective predecessor, and the part moves onto the
turntable and drives onto it.
·
Once
one of the settings below is met, the turntable looks for the target station
and starts rotating towards it:
·
When
the part is located in the center of the turntable, i.e., when both ends
of the part have the same distance from the ends of the turntable.
·
When
you want the turntable to not turn automatically, but only when the part has
reached a user-defined sensor, select User-defined with Sensor. In the sensor
control, you have to tell the turntable to call the method setDestination.
·
For determining
the target station the turntable either uses its default exit strategies or the
Target control.
Within this method you set the target station.
|
|
·
Then
the turntable rotates to the target and the part moves on, once the turntable
has reached the final position of the rotation. Only then a new MU can move
onto the Turntable.
You can control the rotation
animation steps, with which the Turntable rotates, with the setting Animate on every xth pixel. When you inserted the Turntable
with its icon, the Number of Animation Events controls these steps.
You can use the TwoLaneTrack to
model a part of a transport line with two lanes on which traffic moves in
opposing directions.
The Transporter is the only moving material flow object that can use the TwoLaneTracks
in a meaningful way. You might, for example, utilize both to model an AGV
(automatically guided vehicle) system.
The distance, which the Transporter
has to travel on the TwoLaneTrack—defined by the Length
of lane A and the Length
of lane B of the TwoLaneTrack,
the Transporter's Length,
and its speed, defined by the Speed—determine
the time, which the Transporter remains on the TwoLaneTrack. As
opposed to the other material flow objects, Plant Simulation uses the
actual Length, which you enter, during your simulation run. One Transporter
may not pass another one moving in front of it. Transporters thus retain
their order of moving on and exiting of the TwoLaneTrack. Each lane of
the TwoLaneTrack may have its own length to realistically model the
length of the lanes, when the TwoLaneTrack turns the corner. In that
case the outside lane is longer than the inside lane.
When
several Transporters travel along the TwoLaneTrack at a different
speed, and a faster one collides with a slower one, Plant Simulation
activates the collision control of the faster Transporter and
automatically reduces its speed to the speed of the slower Transporter.
Mobile Objects
Plant Simulation provides these mobile objects to model
the flow of materials through a simulation model. Note that we call the mobile
objects MU or MUs in the program.
·
The Entity for modeling parts being produced and
transported, but not transporting other work pieces.
·
The Transporter for
modeling self-propelled vehicles allowing it to drive on its own Track and
transporting Entities,
Containers and
other Transporters.
You can hitch up several Transporters
to create Tugger Trains.
As opposed to the material flow objects proper, the mobile
objects are not bound to a fixed location. Initially a Source
object creates the MU from an MU class in the Class Library. They are then passed on to the
different stations in the model along the material flow connections. The
stations then process the MU. The MU remains at the final station of its
movement until it is removed from the installation, usually by a Drain
object.
During the simulation run the MU is either located on a
material flow object, or on an MU with loading capabilities, such as a Container
or a Transporter.
The material flow objects either pass the MU along the material flow
connections, symbolized by the Connector,
to the next object in line or the flow of material is controlled by Method
objects.
The length-oriented objects Line,
Turntable,
Track,
and TwoLaneTrack
use the actual MU length
of the mobile objects, while all other material flow objects ignore the length
of the MUs. The AngularConverter
uses the MU length
and the MU width.
The three MU classes share a number
of properties and features. The mainly differ in their loading capacity and
their way of moving:
·
The Transporter
and the Container
represent objects that load and transport parts, such as a forklift, a luggage
van, a pallet or a bin, etc. You will assign both a dimension, i.e., a
capacity, of your choice.
When
moving on the Track,
the Transporter moves along by itself, even powered by a battery, with
the speed you define, forward or in reverse.
·
The Entity
represents a single object, such as a cylinder head, a crankshaft, etc. that is
going to be processed.
The Container is a moving
material flow object for transporting other MUs. You can use it to model
pallets, bins, boxes, etc. Define the capacity of the loading space—which
refers to the number of MUs only, not to their physical size—along the x-axis
and the y-axis. During a simulation run Plant Simulation passes the Container
along from material flow object to material flow object along the Connectors.
The Entity is a moving
material flow object without loading capacity that moves through a plant on the
material flow objects proper. The Entity represents parts being produced
and transported, but not transporting other work pieces.
The Transporter is an active
mobile material flow object. It is self-propelled allowing it to move on its
own on the object Track
driving forward or in reverse. It also has loading capacity for transporting Entities,
Containers and other Transporters.
behaves like the object Track,
i.e.the Transporter drives on it, loads and unloads other MUs. Thus you
can also define Sensors. Note that the animation on the line-oriented
loading space requires an animation line. As Plant Simulation does not
create the animation line automatically, you have to assign it an appropriate
icon. The length of the line-oriented loading bay is independent of the length
of the Transporter itself. You can place other MUs onto the locations on
the loading space of the Transporter.
On point-oriented objects, such as
the SingleProc, ParallelProc, etc. and on the Line, the Transporter
behaves passively, i.e., the Set-up and Processing times of
these objects determine how long it is going to stay. These material flow
objects also determine the exit behavior of the MUs.
On objects of type Track however,
the Transporter itself behaves actively, i.e., it decides on which Track(s)
it will drive to get to its Destination
object. To do so, it uses the Forward destination list or the Backward destination list of the Track(s) en-route to
the destination.
Information Flow Objects
Tecnomatix Plant Simulation offers these objects for providing the
simulation with information during the simulation runs:
·
The AttributeExplorer for
managing the attributes defining the settings of the individual stations in
your simulation model.
The Material Flow Objects, which Plant Simulation
provides, usually suffice for quickly creating simple simulation models. For
more complex models you will employ lists and tables in addition. Lists manage
and administer information and data. The Class Library provides these
lists and tables:
·
The CardFile
accesses all cells randomly by their position. You can add new cells at any
location. When you remove a cell, all cells with a higher number move up one
position.
·
The
StackFile, compare QueueFile and StackFile, only accesses the cell you added
last. When you add a cell all existing cells move one position down. When you
remove a cell, the remaining cells each move up one cell.
·
The
QueueFile, compare QueueFile and StackFile, only accesses the cell you added
first. It adds new cells after the last existing cell.
·
The TableFile
accesses all cells randomly by their column and row number. Note that a new
contents will overwrite and replace any existing contents of the cell.
·
The TimeSequence
accesses all cells randomly by their column and row number. It adds new entries
in ascending order according to the time. Entries with a higher position move
up by one position when you remove a previous entry.
CardFile
The CardFile
is a list with one column providing random access to the contents of the
individual cells using their position, i.e., row number. Imagine the CardFile as a file-card box.
When you add an entry, Plant
Simulation moves all entries after this one position down. You can
delete an entry, and you can read an entry and add that entry back to the CardFile.
Note
the difference between the object CardFile,
which you can insert into a model, and the data type list. You can create
user-defined attributes and local and global variables of data type list that are part of another
object and thus are not an object of their own and do not have their own icon.
For this reason these variables and attributes do not
recognize the methods of the CardFile,
such as location or
existsIcon. All
other methods, especially for read and write access, apply to both the CardFile and to variables and
attributes.
QueueFile
and StackFile
The objects StackFile and QueueFile are lists with one
column. They share all methods and attributes, but differ in their built-in
properties.
The TableFile is a list with
two or more columns. You can access the individual cells by employing their
index, i.e.by their position designated by the number of the row and the number
of the column. You can compare a TableFile to a shelf. Enter values and
references to the cells and remove them again. As opposed to the CardFile,
the contents of the cells remain in the TableFile, the TableFile
can also have blank cells in a range. You can add and remove rows and columns
during a simulation run at will.
The TableFile shares its
built-in properties with the data type Table.
Note the difference between the object TableFile that you can insert
into models and the data type table. You can create user-defined
attributes and local and global variables of data type table that are part
of another object and thus are not an object of their own and do not have their
own icon.
For this reason these variables and
attributes do not recognize the methods of the TableFile, such as location
or existsIcon. All other methods, especially for read and write
access apply to both the TableFile and to variables and attributes.
The TimeSequence is a table
with two columns containing a point in time (column 1) and the value associated
with it (column 2). The TimeSequence records, controls and administers
time-related values, such as shift plans or machine maintenance schedule.
Plant Simulation sorts the contents in ascending
order. Note that the contents may change dynamically. When you delete a pair of
entries contained in a row, Plant Simulation moves the following rows
up, so that no blank cells remain.
The object AttributeExplorer
manages the attributes defining the settings of the individual stations in your
simulation model at a single location. Instead of opening the dialog of each
and every material flow object in your model and entering attribute values into
the text boxes, you can define which attributes of which object the AttributeExplorer
gets and shows in a list window, when you click Show Explorer.
You can then enter different values, for the capacities, the times, etc., which
Plant Simulation writes back to the objects and uses in the model. You
can Export
this settings table as a tab-delimited text file and Import
this file into the AttributeExplorer of another simulation model, thus
using identical settings in several of your simulation models.
The FileInterface is an
easy-to use interface to access data you create and store in other programs in
ASCII format. You can create data for a simulation run in text files and import
it into Plant Simulation during the simulation run with the FileInterface.
You can also write protocol files, statistics tables, etc. directly into a text
file, without having to take a detour by using tables or lists. You can then
visualize or manipulate this data in a spread sheet program or a word
processing application.
The FileLink places a link,
i.e., a shortcut to a file into a Frame. When you drag a file from the Desktop
or the Windows Explorer into a Plant Simulation Frame and
drop it there, the FileLink creates a link to the file in that Frame
using the icon of the originating application.
Plant Simulation opens a dialog asking if you would
like to embed the file into the Plant Simulation model or not. When you
select Yes, it copies the file into your Plant Simulation model
file when you save the model file. When you open the model file the next time, Plant
Simulation creates a temporary file, which is a copy of the original file.
When you are still editing an embedded file in its originating application
while you save the Plant Simulation model file, Plant Simulation
issues a message.
Generator
The Generator activates Method
objects from the time you enter under Start
in regular or statistically distributed intervals, for the time interval you
enter for the interval control.
After the time span, you enter for the duration,
has elapsed, Plant Simulation calls the Method object you entered
as duration control on the tab Controls.
Note that Interval and Duration controls always appear in
pairs.
You can enter times as a fixed
interval or as a statistical distribution. You can also limit the statistical
distributions to a segment of the entire range.
With the object Method you
can program controls that other objects start and which Plant Simulation
then executes during the simulation run. Here, we will only describe the object
Method itself, reserving the description of the programming language for
the chapter SimTalk.
You can build your own programs
using a combination of built-in methods, Keywords,
assignments and control structures in the Method. Also check if one of
the built-in templates
suit your needs. You can also write your own templates for your own use
and for sharing with your colleagues.
This construct combines productivity
and flexibility. You can modify the behavior of an object, so that it exactly
fits your modeling needs, by writing user-defined methods. The built-in
properties of the objects, the large number of built-in methods provided and
the inheritance strategies help constructing valid models in a short amount of
time.
The Trigger changes values of
attributes and global variables according to a custom pattern you define during
a simulation run. It can activate methods also, which then execute the actions
you programmed.
The Trigger maps times to the
values of a variable. User-defined attributes take values designated by the Trigger
during a simulation run. You can specify the values either in a single TimeSequence
object or by combining several time sequences of other Triggers. In
addition, a Trigger can control how and when a Source
object creates MUs.
The Variable is a global
variable that other objects and methods can access during a simulation run. A
variable represents an unknown quantity, it represents an element which stores
a quantity. The opposite of a variable is a constant, whose value is known and
does not change. You might, for example, use it to store data over an extended
period of time during your simulation run, to count values up and down, to
assign values, etc.
Display and User Interface Objects
|
|
6.4 Tools
- The Artificial Neural Network for analyzing simulation studies and for forecasting.
- The BottleneckAnalyzer and the SankeyDiagram for analyzing and displaying the flow of parts through a plant.
- The ExperimentManager for running experiments with your simulation model. You can also use it for Running a Distributed Simulation
- The GAWizard to optimize models with genetic algorithms.
- The PortalCrane for placing parts into storage and for removing them from storage.
- The TransferStation for loading, unloading, and reloading parts.
- The WorkerChart for showing statistics values of all workers in a single WorkerPool.
|
|
Fig.2
simulation model for engine decking
8. DATA COLLECTION
OPERATIONS ON CHASSIS LINE TILL ENGINE DECKING PROCESS
|
Opn. No.
|
Opn. Description
|
|
1000
|
Fitment of W bracket and transmission breather
pipe mtg bracket
|
|
|
Pre-fitting of W bkt & transmission breather
pipe mtg pipe on chassis
|
|
|
Routing of gear shifter & H/B cable through W
bkt
|
|
|
Tightening of W bkt & transmission breather pipe
mtg bkt on chassis
|
|
1010
|
Fitment of lower back panel beading
|
|
|
Fitment of lower back panel beading
|
|
1020
|
Fitment of 4 way Tee
|
|
|
Fitment of 4 way Tee
|
|
1030
|
Fitment of
LSPV
|
|
|
Fitment of LSPV
|
|
1040
|
Clipping of brake bundy
|
|
|
Fitment of brake bundy routing clips
|
|
|
Clipping of brake bundy on chassis
|
|
1050
|
Fitment of brake bundy
|
|
|
Fitment of TMC brake bundy to 4 way tee
|
|
|
Fitment of front wheel brake bundy to 4 way tee
|
|
|
Fitment of LSPV brake bundy to 4 way tee
|
|
|
Fitment of TMC brake bundy to union joint
|
|
|
Fitment of union brake bundy to LSPV
|
|
|
Fitment of 4 way tee Brake bundy to LSPV
|
|
1060
|
Fitment of Front brake hose
|
|
|
Fitment of front brake hose
|
|
|
Tightening of brake bundy
|
|
1070
|
Fitment of grommets on under body
|
|
|
Fitment of grommets on under body
|
|
1080
|
Routing of cables
|
|
|
Routing of control cable for selector
|
|
|
Routing of control cable for shifter &
parking brake cable
|
|
|
Routing of vacuum hose on cross member
|
|
|
Routing of vacuum hose on long member
|
|
1090
|
Fitment of vacuum tank
|
|
|
Insertion of hoses on vacuum tank
|
|
|
Fitment of vacuum tank on chassis
|
|
1100
|
Dirty side hoses subassembly
|
|
|
Fitment of extension hose on rear dirty side hose
|
|
|
Fitment of rear dirty side hose on dirty side
pipe
|
|
1110
|
Fitment of Dirty side hoses
|
|
|
Fitment of dirty side pipe on chassis and cargo
|
|
|
Fitment of extension hose on cargo
|
|
1120
|
Fitment of Top encapsulation
|
|
|
Fitment of Top encapsulation
|
|
1130
|
Fitment of Dummy clutch pedal on chassis
|
|
|
Fitment of Dummy clutch pedal
|
|
1140
|
Fitment of chassis wiring harness
|
|
|
Clipping of chassis wiring harness
|
|
|
Earthing connection on chassis
|
|
|
Connection of wiring harness for tail lamp
|
|
|
Connection of wiring harness for registration
plate lamp
|
|
|
Connection of wiring harness for side marker
|
|
1150
|
Fitment of Suspension cross member
|
|
|
Fitment of Suspension cross member
|
|
1160
|
Radiator & fan subassembly
|
|
|
Fitment of radiator and Fan
|
|
|
Fitment of thermoswitch on radiator
|
|
|
Fitment of radiator side deflector
|
|
|
Connection chassis wiring harness to radiator fan
& thermoswitch
|
|
1170
|
Fitment of Radiator assembly
|
|
|
Fitment of radiator assy along with top deflector
|
|
|
Fitment of side deflector
|
|
1180
|
Subassembly of intermediate shaft & steering
gear box
|
|
|
Fitment of intermediate shaft on steering gear box
|
|
1190
|
Fitment of steering gear box on chassis
|
|
|
Insertion of steering bellow in intermediate
shaft
|
|
|
Align & insert intermediate shaft with
steering column
|
|
|
Fitment of intermediate shaft on upper column
|
|
|
Fitment of steering gear box assy on chassis
|
|
1200
|
Engine Subassembly
|
|
|
Engine Inspection
|
|
|
Fitment of FIP main line
|
|
|
Fitment of return line rubber hose on FIP return
line
|
|
|
Clipping of FIP main & return line
|
|
|
Insertion of top rubber on cradle tube
|
|
|
Loading of engine on decking trolley
|
|
1210
|
Fitment of power train
|
|
|
Power train Positioning
|
|
|
Engine tightening
|
|
|
Fitment of Transmission support bkt on chassis
with propeller shaft guard
|
|
|
Fitment of vacuum hose on vacuum reservior tank
|
|
|
Routing of main fuel line , return fuel line
& Negative cable
|
|
1220
|
Fitment Engine wiring harness
|
|
|
Connection of engine wiring harness to chassis
wiring harness
|
|
|
Connection of chassis wiring harness to
transmission sensor
|
|
1230
|
Fitment of clutch cable on engine
|
|
|
Fitment of clutch cable grommet on chassis
|
|
|
Removing of barrel & dowel from clutch cable
|
|
|
Insertion of clutch cable from stopper assy bkt
|
|
|
Insertion of clutch cable from release arm
|
|
|
Fitment of clutch cable on engine
|
|
|
Fitment of clutch cable on suspension cross member
& body
|
RESULTS AND ANALYSIS
SCENARIO 1
SCENARIO 2
|
|
|
SCENARIO 3
|
|
|
SCENARIO 4
|
|
|
ENGINE TROLLEY QUANTITY OPTIMIZATION
|
|
Hanger Speed Vs decking cycle time analysis
|
CONCLUSION
Engine decking process is
the process in which engine of LTV is attached to the body of vehicle. With the
help of discrete event simulation we able to change process of engine decking.
In earlier process assembly workers has to move along self propelled engine
trolley and EMS (electro monorail
sensor) hanger and engine from engine trolley is assembled to the body of the
vehicle. But this process was inconvenient to workers ergonomic point of view. Using discrete event
simulation we able to make go and stop concept for engine decking so that
engine on self propelled trolley will stop for time equal to engine decking
cycle time at station five . Within that
decking cycle time worker will do all operation related to engine decking
process.
We have find following using discrete event
simulation
} The
optimum engine decking operation cycle time is 2 min 20 second with hanger
speed 12 m/min(station 4,5,6).
} Hanger
speed between station between 3 & 4 ,4 & 5 and 5 & 6 is 12m/min
} By
decreasing the hanger speed at station 4,5,6 the decking cycle time(at station
5) is decreasing
} At 6
m/min of hanger speed the best decking
cycle time is 1 min 55 sec at station 5
} Optimum
number of engine trolley is 3
REFERENCES
1. Averil
M. Law (2008)-Simulation modeling and analysis,TMH,ostan USA
2.
Onur Ulgen(production modeling corporation &
university of Michigan-Dearborn) Ali Gunal (production modeling corporation)-“Simulation
in automobile industry”
3.
Arun Jayaraman (production modeling corporation)-
“Applications of discrete event simulation in the design of automotive powertrain
manufacturing systems”
4.
Nils Boysen a, Malte Fliedner a, Armin Scholl- “Sequencing mixed-model
assembly lines: Survey, classification
a.
and model critique”
5.
Kevin J. Watson a, John H. Blackstone b,1, Stanley C. Gardiner c,2- “The
evolution of a management philosophy: The theory of constraints”
6.
Michael E. Bergen1, Peter Van Beek1, & Tom
Carchrae2 1 department of computing
science,university of Alberta edmontan, Alberta, Canada T6G 2H1- “Constraint –based vehicle assembly
line sequencing”
8. John S. Carson, (2003)“Introduction
To Modeling And Simulation” Proceedings of the 2003
Winter Simulation Conference
9. Peng Qu, Geoffrey E. Skinner,Scott J.
Mason,(2003) “Sizing A Pilot Production Line Using Simulation”
a. Proceedings
of the 2003 Winter Simulation Conference
10. B.
Johansson, S. Jain, J. Montoya-Torres, J. Hugan, and E. Yücesan, (2010)
a. “Increasing
Throughput In An Automated Packaging Line With
b. Irreducible
Complexity” Proceedings of the 2010 Winter Simulation
Conference
11. Ray J Paul, Jasna Kuljis,(2008) “Problem
Solving, Model Solving, Or What?”
a. Proceedings
of the 2008 Winter Simulation Conference
12.
Minh Dang Nguyen,Soemon Takakuwa (2008) “Emergence Of Simulations For Manufacturing
Line Designs
13.
Sankar Sengupta, Kanchan Das, Robert P. VanTil (2007) “A
New Method For Bottleneck Detection”
Proceedings of the 2007 Winter Simulation Conference
14.
Ricki G. Ingalls (2006)“Introduction
To Simulation” Proceedings of the 2006 Winter Simulation
Conference
15. Averill M. Law (2008) “How
To Build Valid And Credible Simulation Models” Proceedings
of the 2008 Winter Simulation Conference
16. Vishvas Patel(2002) “Throughput Analysis
& Simulations” Proceedings of the 2002 Winter Simulation
Conference
17. Felipe F. Baesler,Milton Moraga,Francisco
J. Ramis(2002) “Productivity Improvement In The Wood Industr Using Simulation And
Artificial Intelligence” Winter Simulation
Conference
18.
Michael C. Fu (2005) “Simulation Optimization: A Review, New Developments, And Applications”Winter
Simulation Conference
19.
Tutorial Tecnomatix Plant Simulation
An important class of computer operations on some computing platforms is the accepting of input from human operators and the output of results formatted for human consumption.A computer is a programmable machine designed to automatically carry out a sequence of arithmetic or logical operations. The particular sequence of operations can be changed readily, allowing the computer to solve more than one kind of problem. EDI VAN Provider
ReplyDeleteIt proved to be Very helpful to me and I am sure to all the commentators here! transportadora de veiculo
ReplyDelete