Simulation software was developed in order to overcome the deficiencies associated with modeling complex systems based on a general purpose language such as Fortran, C, Pascal or Basic.

Following are some of the advantages associated with using simulation software [7]:

1. The programming time is significantly reduced as the software provides greater flexibility towards tasks like generating random numbers from a probability distribution, advancing simulation time, determining the next event, collecting and analyzing data, reporting the results and adding or deleting records.
2. The basic building blocks in the simulation software represent the simulation of the real system in a better format. The layout of the blocks represents the flow of entities in a clear fashion. The programming code in a language like FORTRAN is more difficult to understand.
3. Simulation models are generally easier to change when written in a simulation language because it involves changing code in a particular block, which can be easily detected by means of verification and debugging tools. A programming language needs changes to be made in a large number of lines, which are difficult to detect.
4. Error detection is better since fewer lines of code have to be written.

There are 53 different kinds of simulation software available in the market. Forty-two of these are useful in logistics and 39 provide animation. All software incorporate the basic features mentioned above. However, they are different from each other in the sense that they have a certain built-in feature, which is suitable for a particular logistics application. Hence the real system needs to be studied in all aspects and the result desired should be fully understood before the software can be selected [6].

The factors considered by the company while selecting simulation software for manufacturing systems must include the following points [5]:

1. There should not be any mismatch with the basic manufacturing processes. The major modes of manufacturing are:
   1. True job shop- make to order, little or no repetition.
   2. Job Lot- made to order with repetition.
   3. Continuous process- made to stock.
2. There should not be any mismatch with the cost accounting system. The company should evaluate the type of control procedures that would best serve the needs of the business. For example-There may be a need to convert a manual job cost system to a computerized combination of standard and job cost.
3. The software should provide alternate path for manufacturing. This is because in reality the process routing may vary a great deal whereas, the software may assume a fixed path.
4. While selecting standard software, the company should incorporate flexibility to change the manufacturing environment. This will make the software compatible with the manufacturing processes.
5. The software should consider the scarcity of resources and its direct treatment to a greater extent in the analytical models. This is because in most manufacturing facilities or material-handling functions, the influence of direct or indirect resource is often the major influence on manufacturing requirements and operations planning.
6. The software should have the ability to model in-process storage which is dependent on many factors like arrival rates, service times, types of material handling equipment, material handling methods, failures, limited manpower and many other elements of the integrated system.
7. Unpredictable behavior of the manufacturing systems like varying cycle times, varying activity times, highly unpredictable material handling and manufacturing components should be simulated.
8. Important concepts in modern material handling design like product dependent or flexible manufacturing systems are very difficult to analyze. The software should have the ability to simulate such systems without model decomposition.
9. The powerful capability of simulation software is to directly incorporate the effect of catastrophic or status-disturbing events into the systems model. The events may be the real-time failure of machines or product lines. When such events occur the analyst should dynamically change the operating procedures and parameters of the system when those events occur.
10. Inefficient and obsolete software to simulate the system should not be considered. Common examples of inefficient selections are:
    1. GPSS 1V/V: Since the host computer is IBM, or the analyst understands the language.
    2. SIMSCRIPT 2.5: Since the company has a SIMSCRIPT compiler and their analyst has used SIMSCRIPT before.
    3. FORTRAN IV, PL-I, COBOL: Since the analyst has had a course in simulation and he is an expert in that language.
11. In the vast majority of analytical models there is a need to reflect the problems of man machine interface and the direct influence of human decision making and control. The software should incorporate the features like forklift versus the operator, automated picking systems, automated numerically controlled machines, etc.
12. The majority of software in the industry supports "analytical models" also known as "throw away models". Once the results of the model are obtained it is seldom used again. The software should allow the user to change a model purely from an analytical perspective to that can be used for operational planning and scheduling. The software should completely bridge the gap between analytical and operational modeling and include:
    1. Integration with corporate databases
    2. Continued integration with CAD systems
    3. Scheduling
    4. 3-D animation
    5. Kinematic simulation of robots and m/c tools
    6. Business graphics
13. The software should have the ability to manage data flow. Just analyzing the material flow is ignoring the reality of networked computers on the shop floor. More attention should be directed toward analyzing the bottlenecks in data communications, traffic and transaction processing within the factory.
14. The software should assist organizations in managing their day-to-day operations. The software should be visual, interactive and use simulation technology to help users schedule their production orders. It should allow various scheduling options to be modeled and their ramifications viewed and analyzed.
15. The simulation product should offer an on demand analysis power to factory-floor personnel. Supervisors should be able to review quickly a number of alternatives manufacturing strategies and then select the best policy to satisfy their short interval production objectives. Production schedules should be the primary o/p.
16. The proper use of simulation software at an operational level requires:
    1. Effective methods for data import and export from production control or MRPII systems, data collection systems, order books, process plans and shop floor supervision.
    2. Standard communication interfaces
    3. Up-datable model of manufacturing operations
    4. Tools that capture a production expert’s knowledge relating to problem identification, reasoning and decision making in a manufacturing setting

Possible features to consider in software selection include the following [7, 8]:

1. GENERAL CONSIDERATIONS
   1. MODELING FLEXIBILITY: As no two systems are exactly the same, the software should incorporate basic features acting as building blocks which differentiate from one system to another. Entities should have their own attributes (due date, message length, etc.) which, differentiates them from one another.
   2. EASE OF MODEL DEVELOPMENT: Due to the short time frame of many projects the accuracy and speed of modeling process is an important consideration. Hence, the software should have verification and debugging tools, which aid in the smooth development of the model.
   3. FAST MODEL EXECUTION SPEED: This is very important in case of large models simulated from military applications, huge manufacturing plants, etc. Due to the complications involved in the flow it takes a very long time in running the model. For a 40-machine food-packaging plant, it took 7 hours to simulate 2 weeks of production on a 16-megahertz microcomputer.
   4. MAXIMUM MODEL SIZE: This comes into picture when the model is run on a microcomputer and the model size is less than 100 K bytes. When the number of entities generated exceeds 150 in software versions like ARENA3.0 the student version needs to be replaced by a professional version.

2. INPUT CONSIDERATIONS
   1. CAD TRANSLATION: A CAD translator will take a CAD drawing and convert it into the drawing system used in simulation. This feature saves time when laying out large or complex conveyor models or manufacturing processes.
   2. IMPORTING A FILE: This feature is used during the preliminary phase of model development when the data is collected. The data collected includes waiting time in queue, inter-arrival times and service times. The data is then fed into an application like Microsoft Excel and later imported into the software like ARENA3.0 to generate a distribution which is then entered into the building blocks to generate a random arrival of entities, random service times and random waiting times.
   3. EXPORTING A FILE: The output file can be used as an input to a spreadsheet for business graphics. This feature is used on running the program. The large amount of data generated is imported in an application like Microsoft Excel and then the calculations can be carried out to validate the model.
   4. SYNTAX: It should be easily understood, consistent and unambiguous. Sometimes, in-spite of the various debugging and verification tools available, it is extremely difficult for the designer to determine the mistake. Hence visual inspection of the syntax is the only means of correcting errors.
   5. INTERACTIVE RUN CONTROLLER: It should act as a debugger (finding and correcting errors). The program is stopped a particular duration of time when the error is generated. The program is then re-run in a step by step mode until the error caused by a particular event is determined. Other method is reading the error report generated by the computer when the program is stalled. Animation is also a useful tool in finding errors as any discrepancy in the flow suggests the same. Analyzing results at the end of the run is useful in correcting errors.
   6. INTERFACE TO OTHER LANGUAGE: This is the ability to drop into another language for additional detail. Software applications such as ARENA3.0 interface with front ends such as VISUAL BASIC in order to generate crystal reports and histograms.
   7. INPUT DATA ANALYSIS CAPABILITY: The I/p data should be described as a statistical or mathematical distribution. As mentioned earlier the distribution is entered into the blocks to generate random numbers.

3. PROCESSING CONSIDERATIONS
   1. POWERFUL CONSTRUCTS: Modeling bridge cranes without interference requires powerful constructs.
   2. RUN-TIME FLEXIBILITY: The program may be needed to run for a specified set of replications without interruptions in order to validate it. Thus, the software should store the results of the run, generate a report consisting of the data for each run and construct a powerful animation.
   3. RANDOM VARIATE GENERATOR: There are 12 statistical distributions in simulation. Some examples are Poisson, Erlang, Beta, Gamma, Uniform, Triangular, Lognormal, Weibull, etc. The software should have the ability to generate random variates using the 12 statistical distributions so that the random variates generated by the particular simulation block represent the system being modeled.
   4. RESET: The software should reset the statistics collected to zero at the end of each run. This is because in case of multiple runs each independent replication must start at time T=0 in order to create the same scenario.
   5. INDEPENDENT REPLICATIONS: Multiple replications using different sets of random numbers should be possible as each run generates numbers from a probability distribution which are entirely different from each other. The larger the number, the better as the average of a particular number of replications represents the real system.
   6. ATTRIBUTES AND GLOBAL VARIABLES: Attributes are local to an entity and global variables are available to all entities. The software should have the ability to handle a large no of attributes and variables. This feature becomes increasingly important to model complex supply chain systems when different type of entities each having a different service time or arrival rate enters the system.
   7. PROGRAMMING: This is also called as custom logic representation. It requires internal programming capability. The software should represent a problem to any desired level of detail or complexity. If it forces the user to choose canned representations or simplifications, then it cannot support complex systems.
   8. PORTABILITY: This feature enables the software to be run on various classes of computer without changes in the software. Software such as Simple++ runs on Windows95, Windows NT or Unix, SLAM runs on C or C++. This flexibility enables the user to reduce the cost and time involved in completing the project.

4. OUTPUT CONSIDERATIONS
   1. STANDARDIZED REPORTS: The o/p measures, such as the average number in queue, average time in queue and utilization rates should be produced automatically upon request. This can be specified by means of programming expressions in the block diagram and can be viewed in the report generated at the end of execution. This feature is extremely important as actions are taken based upon the results of the simulation run.
   2. CUSTOMIZED REPORTS: These are tailored presentations that would be shown to a manager. It usually contains the summary of each replication, the average service time or waiting time of all the replications, utilization rate of each resource, etc.
   3. BUSINESS GRAPHICS: The software should have the ability to generate bar charts, pie charts and histograms. This is usually accomplished by interfacing the software with front ends like Visual Basic.
   4. CUSTOM PERFORMANCE MEASURES: The analyst shouldn’t be constrained to a predefined set of performance measures.
   5. WRITE TO A FILE: The software should allow data, events or system variables to be written to a file. This ability enables the user to generate distributions when importing the data from an application like Microsoft Excel or validate the model when exporting the results obtained at the end of independent replications.

5. ENVIRONMENTAL CONSIDERATIONS
   1. ANIMATION CAPABILITY: There should be the ease of development, the quality of picture, the smoothness of movement and the portability of remote viewing. The animation helps in trapping errors or gain considerable understanding of the system to the new user as well as the designer.
   2. EASE OF USE: It should be user friendly.
   3. RUN-ONLY VERSION: In addition to the execute only version there should there should be a stand-alone demonstration/animation of the model. Animation helps in trapping the errors during the run even though the program does not generate any errors. This is because the product may be routed to a wrong machine or the flow is irregular.

6. COST CONSIDERATIONS
   The cost of simulation software is quite variable, say from $500 to $50,000. The popular software has stabilized around the $15,500 mark. It is not advised to buy software on the basis of cost.

7. THE BOTTOM LINE
   1. Accuracy and detail are extremely important.
   2. Powerful capabilities can make for simulation analyst productivity increases.
   3. Get the greatest speed that you can afford because the greater expense is the analyst waiting.

Reason for Selecting Arena 3.0 Environment
After careful consideration the simulation team came up with the idea of selecting Arena 3.0 as the software for carrying out the project. Following are the reasons justified for the same:

1. Animation Capability
   1. Arena 3.0 supports animation and the material flow through the system can be explained in a clear fashion to members of other teams who are not familiar with simulation.
   2. It would help in understanding the interface of simulation with Manufacturing, Transportation, Information Systems and clear the basic concepts in those fields.
   3. Animation acts as a debugging tool and helps to detect any errors made during building the basic blocks.
2. Syntax
   Arena 3.0 provides a user-friendly environment without involving any programming statements. The function of every "block" and "element" is hard-coded in advance, while developing the software.
3. Arena verification and debugging tools
   The in-built features in ARENA 3.0 helps to examine in detail the movement of entities through the system. It provides a summary of the action taken at each block through which an entity has passed. It also helps to step through the execution of the model by exercising complete control from the keyboard or mouse.
4. Customized reports
   The availability of customized reports at the end of each run helps in analyzing the results and take remedial steps to further improve the model.
5. Greater familiarity
   3 out of 4 members are familiar with Arena 3.0 environment. They had taken an extensive and in-depth course on Simulation during the previous semester. Two of the team members had done a simulation project for Continental Airlines. The third member was selected by the University of Houston to give a final presentation at Oklahoma on her simulation project.
6. Probability Distribution
   The "Input Analyzer" feature helps in generating probability distributions which can be fed into the various blocks in the model for the random generation of entities.

Back to Table of Contents