Simulation Software:
Practical guidelines for approaching the selection process
Randall R. Gibson, Principal / Vice President Craig Dickson, Senior Analyst
TranSystems I Automation Associates, Inc.
Challenge
Selecting from the more than two dozen commercially available software products designed for general-purpose simulation modeling applications is not easy. No single product is best suited for every application. There are significant differences in how different products approach modeling problems -- and making the right choice will affect not just the chances of success but also how useful the product will be to you in the future.
Unfortunately, most comparisons that have been published address these differences by listing features, with little or no judgment about how the features relate to the goals and requirements of different modeling projects. With over 18 years of experience as an expert-level user of
simulation software products, we have developed internal guidelines that we follow when choosing the platform for a new project.
Solution
Our first recommendation for choosing a suitable simulation software package is, “Don’t choose yet!” That is, research, understand and document the type of modeling applications or problems that your organization will need to address before choosing a simulation package. What do your systems do, and why? What are the greatest risks to a systems success? What are the goals of the modeling process? Writing a narrative description of operations, including the types of experiments to be performed or to test for risks, is an important step in the modeling process - it forces you to focus on the important. Moreover, if you can translate the “real world” into a
concise written description, you can probably translate it in the chosen simulation language also.
When it is time to choose a package, don’t be too concerned with claims of “ease of use” – all the products claim this and it can be misleading. “Easy to use” may mean “easy to operate the software”, but does not mean “easy to build and validate detailed models of real problems”.
No matter which product is used, building a useful model requires training and experience – simulation modeling is an engineering discipline, not just software. Instead, be concerned with project success factors, such as:
• Accuracy – Can the product represent your problem(s) in enough detail? Being forced to make too many simplifications in the model is the first step toward a failed project.
• Logic – Can the product model complex decision logic? (Yes, that means “programming”
the logic.) Packages that do not allow you to code complex decision logic will quickly strand you in real-world modeling applications, no matter how attractive the features or graphics are.
• Support – Does the vendor have a good track record? Even experienced modelers need help.
• Applicability – Does the product lend itself to your specific problem(s)? Or will you have to create “workarounds” or approximations? Similarly, can it easily communicate the results to the intended audience (e.g., engineers vs. customers vs. end users vs.
management).
• Usability – Models can be used in many different fashions. The model developer may also run the scenarios and interpret the results, as in a turn-key simulation project. In this case, usability is limited to how efficiently the modeler can implement the scenarios.
However, in some cases someone not familiar with simulation may be modifying the model to develop the scenarios to be tested. Depending on the scenarios, these can be quite complex.
Capabilities to compare
Eventually, you will have to compare features, or more importantly – product capabilities.
Remember, features or capabilities are not important in and of themselves; they are important only to the extent that they support one of the project success factors listed above. Some of the product capabilities that we consider are:
Programming Language
As noted above, some logic development – programming - is going to be necessary for all but the most trivial of models. So it is important to understand how easily the underlying programming language (or logic development capability) can represent the detailed decision logic or “behavior”
of the system to be modeled. Simulation packages take a variety of different approaches to this.
Most of the packages have proprietary languages; most of those are somewhat similar to a particular general programming language (often C, but sometimes Basic or even Fortran). A few of the newer packages use extensions to standard languages (typically C or Java). Criteria for evaluating the programming language could include your familiarity with the language or its root;
variable types supported (e.g., not all support text (string) variables); the quality of the debugger (important but easily overlooked!); and whether the language supports good programming practices like structured programming.
Data Model
By Data Model, we mean how do you get data into the model for experiments? And how are results recorded? For all but the simplest models, you will want to have a centralized location for all of the data or numeric parameters that you will experiment with. Setting parameters via forms within the simulation package is awkward at best if there are more than a couple of parameters.
One way to avoid the multitude of separate forms is by reading all the data from one or a few simple text files. Most, but not all, packages allow data to be read as text files. Another common method is direct reading and writing to Microsoft Excel and/or Microsoft Access, which more
products are starting to support -- though often at a penalty in run speed which might preclude using this approach for log-file type outputs.
Simulation tools can vary in the way they handle the calculation of simulation metrics such as resource utilization, queue times and lengths and entity time in system is accomplished in varying methods. This data may be available during run-time or it may only be calculated once the model has run to completion. This standard data may also reside in files readily available to the user for post processing, or it may be housed in proprietary databases that limit access.
Animation
For most actual analyses, animation is not the most important feature – numeric results are. Still, animation can be very helpful during development and debugging of a model, and animation can be critical to the presentation of results to project personnel. The level of animation supported varies widely between packages. It can range from “virtual reality” (VR) -- detailed, almost photo- realistic, including lighting, textures, shadows, etc. to abstract representations made up of simple icons or graphs. The nature of the analysis should determine the required animation. For example, if you are analyzing the inventory levels across an entire supply chain, a “virtual-reality”
or detailed representation would not be appropriate, but graphs showing the level at each plant would. Note also that packages with more detailed VR-type animations often run relatively slowly, which can be an issue for large models or models which will track many “entities”.
Product Categorization
There are other differences between products that are not as obvious. These differences are in how a modeling package “describes” the “world”, or system to be modeled. We use two broad dimensions to categorize these differences:
• Worldview: Passive resource / active part vs. Active resource / passive part - In a passive resource / active part paradigm, code is generally written to follow an item (part / person / document / task / order etc.) through the system, interacting with, and competing for, passive resources (e.g. machines). By contrast, an active resource / passive part paradigm describes what happens in a particular place or machine – how it receives, processes, and passes on the objects flowing through the system. Most recent “drag-and-drop” packages fall into the active resource / passive part paradigm, but that paradigm is not always the simplest way to describe a system. Some recent packages allow for a hybrid “agent based” approach, which works in both modes at the same time.
• Graphical vs. iconic (geometry aware or not) – Some packages use the geometric information from the animation to calculate model behavior. For example, many packages use the length of a conveyor as drawn by the user to calculate the travel time along that conveyor. Taking it further, some packages can use the length of the package to calculate accumulation on a conveyor, or package height to determine the state of a photo-eye. Iconic packages leave it to the analyst to calculate the implications of physical dimensions, rather than including special constructs to represent material handling equipment; typically the animation uses symbols or icons rather than a detailed CAD-like view of the system.
Conclusion
We have compiled a complete list of the commercially available simulation software packages that would be appropriate to consider for general use, that is posted on the Knowledge section of our website. Additionally, we have prepared short summaries of several model development projects and the reasons for selecting the simulation tool for the implementation. This summary
is not meant to be comprehensive or limiting. There may be other excellent products not mentioned here that could have been used for the project.
If you are considering a simulation project, and would like a free consultation to help clarify any of this information, please call us.
Application: Material Handling System
Characteristics: Multi-level distribution center. Model based on CAD drawings of system includes conveyors, storage lanes, pallets, cartons, items, truck
unloading and loading, palletizing and depalletizing, floor storage and sorting.
Tool: AutoMod from Brooks Automation
Rationale: Since the system will operate at many different elevations on four levels in the new facility, a 3-D tool was preferred to ease the process of initial layout and modification. Although this could have been done with a 2-D package, the animation of each level would have been on different
“pages” in the model. The operational parameters of the conveyor systems, such as photo-eye placement and timing, were factors to be tested in scenarios. Not all simulation packages that handle conveyors model these components explicitly.
Application: Rail Terminal Operations
Characteristics: Trains of various lengths operate on schedules and encounter delays due to competition for grade crossings.
Tool: Arena from Rockwell Automation
Rationale: There are template-based simulation tools specifically designed to model rail networks, including RTC and RailSim. However, the level of detail required to model the network is sometimes too great for a higher level analysis. TranSystems has developed a custom application that is delivered as part of a consulting engagement called the Transportation Modeling Studio. The underlying simulation engine is Arena, and Visio is used to define the track configurations. Train parameters such as schedule, speed and decision variables are contained in an easy-to-use Excel interface. The end result is a model of a system that can be reconfigured by the casual user, without the need for an understanding of the simulation tool. Arena’s flexibility, along with the pre-built logic for handling transportation elements, helped develop the robust, yet very usable Transportation Modeling Studio.
Application: Pedestrian and passenger flow
Characteristics: Movement of passengers through airline and rail terminals. Free flow movement coupled with periodic processing through limited capacity resources (e.g., hallways that lead to security check stations) Tool: AnyLogic from XJ Technologies
Rationale: Using a traditional discrete event simulation tool to model pedestrian flow can be accomplished, but the logic needed to accurately handle varied walking speeds, breadth in hallways and passing is very difficult. Rather than a discrete event tool, an agent based tool was selected for this effort. Rather than defining all the possible paths in a discrete tool, an agent based tool models the passengers, allowing them to interact with their environment and have autonomous movement and decision
making. AnyLogic is also unique in that hybrid models can be developed
that combine discrete event and agent based modeling paradigms. So passengers traveling in a hallway are modeled using agent based functions and the passengers shift to a discrete event conveyor mode for escalators.
Application: Call Center
Characteristics: Calls arrive via a profile characterized by type of call, geographic location, time of day and are directed through the system using call routing scripts. Agents handle calls based on groups, super groups, skill level and location. Standard call center metrics such as service level, trunk line costs and agent utilization are used to measure the
performance of the system.
Tool: Arena Contact Center from Rockwell Automation
Rationale: Templates package typical tasks and variables for a specific industry or process into a tool that is much easier to use than if a model were built from scratch. They are usually the result of many projects in a particular industry, where lessons learned and reusable code are employed to speed the development of subsequent models. However, there is always a danger in using a template - if the system does not match the template, you can run into problems, where the limitations of the
simulation tool drive the project rather than the other way around. In this case, Contact Center was sufficient to capture the operational aspects of the system, with the exception of one metric, Custom code was needed to calculate service level the way the customer handled it as opposed to the approach used in the template. By using custom SIMAN code, the model was able to account for the unique statistics. The template helped frame the model development and reduce the development time.
Application: Manufacturing and Assembly Line
Characteristics: CAD-based layout of vinyl window manufacturing line. It starts with processing of raw stock, proceeds through fabrication, and ends after assembly.
Tool: ProModel
Rationale: ProModel uses a location-based paradigm for developing models that is well suited to manufacturing and cellular operations. Also, the distances between stations were important and needed to be easily modified. Path distances are automatically updated when changed in ProModel, as opposed to user fields in some other tools. Finally, the automated graphing features of the tool allow for an easy display of graphical results without the need for any programming or custom work.
