03.26.08
Software Selection (part 2)
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.
03.14.08
Software Selection (part 1)
About 10 years ago I gave a presentation to the Michigan Simulation Users Group (MSUG) on the role of 2D versus 3D animation. Computers have gotten faster since then but we are still challenged by the ability of simulation modelers to build models that our computers can’t handle. That being said, the following question still holds true—
When should I use 2D versus 3D animation?
Traditionalists feel like 3D animation does not add value to the analysis of a project. The technophiles in the group often think that everything should be in 3D because its how we see and learn most naturally. I’ve always drawn the line in a different place.
If a simulation includes spatial characteristics, it should be modeled to-scale. Almost every to-scale software package that I have seen does not limit itself to 2D. For example if I am modeling the movement of forklifts to handle material on a dock, I would rather import a CAD file, place my objects at the appropriate location in the layout, and describe how fast the vehicle can drive. This is more natural than figuring out the time or distance required for a forklift to move between locations. If the simulation can derive input information by leveraging information entered about specific objects, by all means, model that way. I would not use a 3D (to-scale) package to model a call center. The distance between phones or the layout of the call center does not really matter unless I’m trying to figure out the effect of operators walking to a poorly located break room.
You should let the computer do the calculations whenever possible. The time to develop the models are nearly identical and the time to update a model is usually much lower when modeled to scale. Imagine I have my dock area modeled in 3D. If I need to move docks or move potential storage locations. I simply move them. I do not have to figure out how far the new travel distance is or what time different exists. In a 2D world I also lose the concept of congestion unless I model all potential stopping points as destinations.
So, how does this effect software selection? You need to consider the types of models you are building. Do not focus simply on the number of times you are going to use the software or a percieved ease-of-use. I have not seen an appreciable difference in ease of use when it comes to 2D versus 3D software products. Often 3D packages are used to solve more complicated problems. If you apply a 2D software package to a problem that should be solved in 3D (or simply to-scale), you will either make assumptions that can harm the accuracy of the model or you will spend more time wedging the problem in to the normally limited constructs available in a 2D package.
03.07.08
The Taurus in the Tree
Those of you who know me have probably heard this story but I thought it would entertaining for a Friday. My first trip after September 11th was to Nashville, TN for a simulation project review. I rented a car from Hertz (Ford Escape). I got about 30 miles from the airport and the engine basically blew-up. I think they forgot to put oil in the car or something. Anyway, I called Hertz and they said they would send a flatbed with a Taurus on the back. The driver would swap my Escape for the Taurus and I would be on my way.
So I relaxed with a copy of USA today and waited for the flatbed to show up. After about 45 minutes, I saw the flatbed crest the hill behind me with a white Taurus on the back. As I put away the newspaper, the flatbed started to pull past me. When the flatbed was directly next to me it was rear-ended by a semi-truck going about 70 miles per hour!! The noise was deafening.
Luckily, the flatbed narrowly missed the front of the Escape but that was just the beginning. While the flatbed was careening down an embankment, the semi-truck went left across several lanes of traffic and a grass median. The Semi ended up about 200 yards into a farmer’s field and miraculously, it did not hit another vehicle.
Back to the flatbed….. About 50 feet in front of my vehicle, the chains holding the Taurus on the back of the flatbed broke. This resulted in the Taurus launching into the air like a gymnast on a tumbling run. I would guess that it was about 20 feet in the air when it entered a stand of trees by the side of the road. The Taurus never hit the ground.
After several more calls, several more hours with the State police and another car from Hertz (driven down by an employee), I was back on the road to my meeting a mere four hours late. Later that night I had to fly to Toronto. While we were in the air space near Toronto, an F-16 was scrambled to talk to an Air Canada flight from LA that was not responding. Our flight had to clear the airspace around Toronto because as the pilot put it — ” There is an F-16 that really wants to talk with one of our colleagues….” This put a cap on quite a day. Whenever I feel like I’ve had a tough day on the road, this day puts things in perspective. I consider myself very lucky. In case you were wondering, I had one on of the first Handsprings (Palm Pilot Predecessor) with a camera. The photos from that day are below…..
The Appropriately Named “Ford Escape”
Semi Truck in the Farmer’s Field
The Flatbed Truck (the driver was shaken but not hurt)
The Taurus in the Tree



