"Workers" in an AutoMod simulation are filling orders. The feature Order Lists makes loads wait until specific criteria are met before they are released back to the system. In order-fulfillment simulations, the feature could hold orders unless adequate inventory is available. With a working model, users could change operating requirements to see what happens, for example, if a portion of stock runs out, equipment fails, or a snow storm keeps half the workers from getting to work.

 

Work lists can be set so the correct lift vehicle is loading or unloading the right truck. The lists are program statements that let vehicles and personnel find the next load that needs attention.

It also lets proposed operational logic control the system. AutoSched, on the other hand, lets users set up a series of simulations and then change system parameters. This lets users quickly analyze positive and negative effects on the system and determine a course of action to optimize the overall performance.

Several features in AutoMod take the work out of complicated tasks. Load Attributes, for one, lets users assign information to specific loads within the system. Loads can be anything that moves, such as boxes, stampings, or assemblies. An attribute stays with its load until the load is changed, updated by another process, or leaves the system. Order numbers, model types, processing times and part requirements, for example, can be assigned to each load throughout a manufacturing process. Programming logic at each machining cell determines what is to be processed. Process times are tracked and recorded to the loads for later analysis.

Without load attributes, load information at each work cell would have to be recorded and tracked in a large file or array, which would lead to additional compiling as orders finish.

Procedure Arrays allow using programming logic several times in a model. For example, one manufacturing simulation had eight drilling cells. Because all cells operated identically, the programming logic required was written only once. Each drilling cell referenced the same programming logic.

This may sound obvious, but other simulation packages make users copy the same code to each drilling cell. Granted, copying programming code is not much work, but as inevitable changes pile up, updating each cell one at a time leads to errors if an update is missed or incorrectly done.

Work Lists, or program statements, let vehicles and personnel find the next load that needs attention. This is a powerful feature for simulations with moving vehicles and personnel. Program statements can be as simple as "get the next load" or as complicated as necessary. We've set up work lists for lift vehicles based on the dock door to which they were assigned. This ensures the correct lift vehicle is loading or unloading the right truck. In another simulation, as selectors filled orders and finished tasks at one workstation, they were to "float" to the nearest of 11 other workstations with orders waiting. Instead of writing complicated logic to find the nearest station, work lists at each location gave greater priority to closer workstations. Therefore, selectors always chose the closest work first. If requirements were more first-in, first-out based, the work-search parameter could have been changed from "closest" to "oldest" to ensure orders didn't backup at other workstations.

Order lists, another feature, make loads in a system wait until specific criteria are met before being released into the system. This is a key feature in many order-fulfillment simulations where orders are held unless there is enough inventory to fill the entire order or the resource required to fill the order is available. Lists let users put loads together, which is invaluable in packaging simulations where several items must be grouped and staged before packed for shipment.

After assembling a simulation system, users won't have to wait long for answers. I have yet to build a simulation that runs significantly slower than real time. In most cases, I have to slow the simulation to see what is happening. In addition, turning animation off lets an 8-hour simulation complete in minutes.It takes time to learn the software and become comfortable with it. But even after a beginner's course, individuals have the basics to build simple models. The next couple of months should be spent building larger models, experimenting with the command structures, and getting accustomed to the more advanced modeling techniques. Overall, it takes about four months to become proficient enough to handle large, complicated systems. The developer offers several week-long training classes throughout the year for different expertise levels.

Excellent documentation is available online, in the software, and in manuals. Each command is well defined with syntax options charted in detail. This is usually followed by several examples of coding showing how commands may be used in different circumstances.

I'd suggest one improvement to an already useful feature. AutoMod can read in an AutoCAD drawing of a factory-floor plan, for instance, that can be a template on which to build a simulation model. This feature alone saves days of work that would be required to measure conveyor lengths and heights. Its only drawback is that to read AutoCAD files, they must be converted into IGES, and an old version at that. I would like to see the feature updated so drawings in DXF format can be read in.

The developer's customer service is one of the best I've encountered. I usually reach a tech-support person on the first call. If the issue is simple, the tech will have the answer. For more complex issues, such as runtime errors and crashes, they ask for the model to be zipped and emailed so they can replicate the issue and address the problem. Turnaround times on the last couple of tough issues I've raised have ranged from a matter of hours to a day or two.

AutoMod and AutoSched come from Brooks Automation, Planning & Logistic Solutions,15 Elizabeth Dr., Chelmsford, MA 01824, (978) 262-2400, www.brooks.com

-- Mark A. Heilman


Mr. Heilman is a project engineer and simulation specialist with York Consulting Group Inc., York, Pa., a developer of distribution and manufacturing operations. The company designs systems that handle material flow and related information throughout the supply chain.