03.26.08

Software Selection (part 2)

Posted in Discrete Event, Methodology, Modeling Tips, Simulation, Software Products, applications, engineering, projects, throughput tagged , , , at 7:19 am by joehugan

My previous post talked about the role of animation on software selection.  Another key factor in software selection is level of use.  Over the years, the “home” for simulation within an organization has been debated. 

If an organization has enough simulations, often an expert is crowned and all simulations flow through that person or even group.  The benefits of this structure is that the models tend to be more standardize, the quality of the models is easier to control, the analysis is more rigorous, and the models tend to get done on schedule.   The downside to this centralized approach is that the modelers are often unfamiliar with what they are modeling.  Subject matter experts need to be involved to guide them through the nuances of the process and the models will often have too much detail since centralized groups do not know what is important and what is not important for a model (that is a whole another post!!!).  Centralized groups tend to select generic software with a lot of features.  These programs are usually more difficult to use but they produce models that are more elegant in terms of animation and/or logic.  These packages will often have a full programming language and users will tell you they have never built a simulation that did not involve some sort of custom programming.

If organizations integrate simulation into the job of the industrial engineer responsible for the a project or plant, simulation is no longer the prime focus of the individual.  In this case, the software by nature tends to be less driven by elegance and more driven by functions.  Models are less standardized and tend to look more like flow charts than plant layouts.  These are often single use models that only include the information required to answer a specific question or series of questions.  The analysis is often more common sense and usually take less time.  These models are often only built when other analysis techniques (spreadsheets, linear programming, or other decision methods) fail to produce a consensus.  While some programming is used in these models, users will tend to avoid it unless it is required.

So what does this mean?  Really some common sense conclusions.  If you are a full time simulation modeler, you should tend toward software that allows you to develop models that are standardized, reusable, and relatively complex.  Programs like AutoMod, FlexSim, QUEST, GPSS/H, and other language based software products excel.

If you are only going to use simulation occassionally, products like Simul8, Witness, ProModel, Extend, and other flowchart based tools whose programming tends to be broken up into smaller groups of statements are probably the best choice since their learning curves are easier.  These products make it easier to come back to modeling after several months working on other issues.

Now I know that these are not absolutes.  I can hear the comments already about how I called Product X a “programming based system” but its easy to use and how Product Y has all the features and capability of anything on the market.    The reality is that each of these products has found its niche in the market place.  Some products are great for building simple models very quickly (Simul8).  Other products are designed to create very large and complex models that can still execute fast enough for analysis on a basic computer (AutoMod). 

When looking for software you need to understand not only the features of the software but also the time you have to commit to the process.

Leave a Comment