Total Manufacturing Assurance; Chapter 5, System Definition (page 3)
PROCESS SIMULATION
          Let us assume that we have developed a tentative layout of our new factory, proposed changes to our old factory, or perhaps just a new control scheme for a physically unchanged factory.  Before implementing our new ideas, which could cost millions of dollars, it would be nice to have some evidence that our ideas are sound.  Ideally, we would like to conduct a scale-model experiment, a dry run of the new plan, before we commit ourselves.
          That is exactly what the concept of simulation allows us to do.  General purpose computer-based simulation is a programming technique which allows us to analyze systems with random variables in a manner which gives us fairly good estimates of the system's performance.
          The concept of random variables is a crucial one.  In most complex systems, we do not know exactly what the future holds.  Sales volumes, consumer demand; breakdown times, frequency, and severity; randomly varying production times, and many other system variables are not precisely known beforehand.  If they were known, we could develop mathematical relationships between these inputs and our system outputs, although these relationships may be extremely complex.
          However, with simulation techniques, we do not need the exact inputs.  All we need is a mathematical expression for the distribution of the inputs.  Typical distributions are:
          1. Normal - with known mean and standard deviation
          2. Exponential - with known mean
          3. Poisson - with known mean
          4. Triangular - with known minimum, maximum, and mode
          5. Uniform - with known minimum and maximum

          These distributions are described by fairly simple mathematical expressions, and can be derived from historical data of the process in question.  As long as no anticipated change is expected in the overall distribution of a random variable, the distribution developed from the historical data can be considered an excellent prediction, over time, of the future events.  These predictions become the inputs to our simulation.
          How do we develop our simulation?  First and foremost, be must precisely define our system.  That is, we must decide exactly what parts of our factory we wish to model.  We must draw a "dotted line" around that part of the factory which will be included in the model.  We must scrutinize this dotted line, and determine all inputs and outputs to the system.  These include everything that crosses the dotted line, either in or out.  We must identify material, personnel, products, energy, and information which travels in and out.  Anything which happens completely inside the dotted line will become part of the internal workings of the model; those things which cross the lines are modeled as inputs and outputs.
          What exactly is a model?  In a general sense, a model is an abstract description of some real system.  It is an analogy, whose behavior can be used to infer the behavior of the system which it models.  Many types of models exist in the world, some of which are used in computer simulation.  Scale models, such as miniature trains, cars, or army men, are useful to architects and generals.  Graphical models are useful in other situations; a classic example of a graphical model is a road map.
          The two types of model we will be using are math models and logical models.  An example of a math model is an equation, such as F=ma.  This model describes the behavior of the quantities of force, mass, and acceleration, and can be used to predict future events, if the inputs are correctly supplied.  Another example of a math model is a look-up table: given row and column values as inputs, the output can be looked up in the interior of a table of values.  This type of model is most applicable to functions which cannot be described by a simple equation.
          A logical model is a description of inputs and outputs in terms of logical statements.  For example, a simple IF-THEN rule could constitute a logical model.  A truth table would also fit the definition of a logical model.  A complex FORTRAN program, with many branching IF statements, is a large logical model of some decision process.  An expert system (see Chapter 4) is another example.
          Our system model will include both math and logical models in its attempt to mimic system behavior.  It will include those portions of the system which we consider to be important, and will describe them to a level of detail, or resolution, that we consider necessary.  It will expect to be supplied with those quantities we identified as system inputs, and will return us the system outputs.
          When the model has been completed, it will enable us to do four things that we could not have accomplished as easily, if at all, before:
          1. If the model can be made to perform exactly like the current system, it can be used to EXPLAIN the real system.  The math and logical models we selected must be actually functioning in the real system.

          2. The model can PREDICT how the system would react to a new set of inputs, or to a change in the system itself.
          3. This allows us to ANALYZE the system and its performance.
          4. Iterative analysis of progressive changes to the system model allow us to DESIGN a new system, or changes to the old system, in accordance with our new goals.


Simulation Example
          What does a typical simulation look like?  We can examine a simple example which contains many of the elements of a more complex simulation.  We will look at it merely in logical terms, and not worry about programming or implementation.
          A typical system with random variables can be demonstrated with by the operation of a fast food restaurant.  Let's assume our restaurant has one server, and customers wait in one line to be served.  This line is usually called a queue.
          First, we must define the state of our system.  The state is a set of variables which completely, yet without redundancy, describes the condition of the system.  Any variable not included in the state description can be derived from those which are included.  Many possible state descriptions exist for any given system.  For our fast-food system, the state can be described by two variables: The server status (either busy or idle) and the number of customers waiting in the queue, not counting the customer, if any, being served by the server.  We will assume that the server works diligently at serving any waiting customers, and will only become idle when the queue is empty.
          Next, we must identify the ways in which the state can change.  In our example, there are two ways: a new customer can arrive, or the server can finish serving a customer, who then leaves.  Identifying these state-changing activities is something of an art, and requires a bit of practice.
          Next we examine how these state-changing activities change the state.  Generally, the manner in which the state changes is dependent not only on the activity that occurs, but also on the state of the system just before it occurs.  Our first state-changing activity was that of a new customer arriving.  If the teller is idle, the new customer gets immediate service.  This means he does not get in the queue, so the queue length stays at zero.  The server status, however, changes to busy.  If the server had been busy when the new customer arrived, the customer would have to wait, increasing the queue length, but not effecting the server status.
          The other activity was the server completing service of a customer.  If there are no customers in the queue, server status changes to idle.  If there are customers in the queue, server status remains at busy, and queue length decreases by one.
          Now we have completely defined our system and identified how it will function.  To set it in motion, we must supply it with some inputs.  The inputs will be arrival times of each customer, and time required for service by each customer.  Each of these values will be supplied from some random distribution, supposedly derived from a study of past data concerning customer interarrival time and service time.
          Output statistics are completely up to us.  We can program our simulation to collect whatever statistics we are interested in, as long as they are based on variables in the model.  For our example, we would probably be interested in things like average time spent in the queue by the customers, average queue length, and percentage of the time that the server is idle.
          Now we are ready to let the simulation begin.  We give it an initial state (usually server=idle and queue=empty), and let the program run.  The program selects a customer arrival time from the appropriate random distribution, as well as a service time.  It selects the next arrival time, and if this is sooner that the first service is completed, it increases the queue length by one.  As each customer arrives and leaves, the state is noted, and statistics are recorded.  After sufficient "simulation time" has passed, we will have a full set of output statistics on the values that we requested.  These outputs, of course, will be statistical in nature, mostly averages and standard deviations.  But there is no way we could have merely calculated them from average input statistics; the relationships, in general, will have been far too complex.
          What about the actual coding of this model into a computer program?  Even for the relatively simple example of the single-server/single-queue system given above, we could be faced with a large programming task.  Fortunately, commercial packages are available which make this task fairly simple.  Most systems are composed of basic building blocks, which tend to look the same, from the viewpoint of a model, regardless of the physical system they are based on.  Simulation packages supply ready-made program chunks for each of these building blocks.  The user needs only to define the blocks he needs, define the interconnections between them, and supply actual values for the variables.
          Example of these building blocks, also known as "network elements," are:
          Arrival elements - these model customers, orders, workers, etc., as they enter the system.  Must be supplied with interarrival times for the arrivals.

          Queue elements - these model a queue in the system.  Must be supplied with an initial queue length, and possibly with a maximum allowable queue length.

          Activity elements - these model an activity which takes a certain amount of time.  Must be supplied with a duration, and how many customers can be served at the same time.

          Conditional elements - allow decisions to be made in the system, based on system state.

          Statistical elements - allow the program to collect statistics based on current model state.

          Departure elements - these model the departure of customers, orders, etc., from the system.

          Other, more complex elements also exist, but these tend to vary from one simulation package to another.  Many exist, and each has its own strengths and weaknesses.  Some are more geared toward specific situations or industries than others.  Some have built-in animation and graphics packages, which can display a schematic diagram of the system model on a computer screen as it operates, allowing the user to watch customers arrive, get serviced, wait in queues, etc.
          Without being considered an endorsement, two of the most popular simulation languages are SLAM II and Siman.  Further information about these products are found in [7] and [8].