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. Practical guidelines for approaching the selection process 1 of 5
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 Practical guidelines for approaching the selection process 2 of 5
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 photorealistic, 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 Practical guidelines for approaching the selection process 3 of 5
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. Material Handling System 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. AutoMod from Brooks Automation 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. Rail Terminal Operations Trains of various lengths operate on schedules and encounter delays due to competition for grade crossings. Arena from Rockwell Automation 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. Pedestrian and passenger flow 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) AnyLogic from XJ Technologies 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 Practical guidelines for approaching the selection process 4 of 5
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. Call Center 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. Arena Contact Center from Rockwell Automation 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. Manufacturing and Assembly Line CAD-based layout of vinyl window manufacturing line. It starts with processing of raw stock, proceeds through fabrication, and ends after assembly. ProModel 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. Practical guidelines for approaching the selection process 5 of 5