There are six basic classes of objects in Simio. These six classes of objects provide a starting point for creating intelligent objects within Simio. By default, all six of these classes of objects have very little native intelligence, but all have the ability to gain intelligence. You build intelligent versions of these objects by modeling their behavior as a collection of event driven processes.
The first class is the fixed object. This object has a fixed location in the model and is used to represent the things in your system that do not move from one location to another. Fixed objects are used to represent stationary equipment such as machines, fueling stations, etc.
Agents are objects that can freely move through 3dimensional space. Agents are also typically used for developing agent-based models. This modeling view is useful for studying systems that are composed of many independently acting intelligent objects that interact with each other and in so doing create the overall system behavior. Examples of applications include market acceptance of a new product or service, or population growth of competing species within an environment.
An entity is sub-classed from the Agent class and has one important added behavior. Entities can move through the system from object to object over a network of links and nodes. Examples of entities include customers in a service system, work pieces in a manufacturing system, ships in a transportation system, tanks in a combat system, and doctors, nurses, and patients in a health delivery system.
Note that in traditional modeling systems such as GPSS or Arena the entities are passive and are acted upon by the model processes. However in Simio the entities can have intelligence and control their own behavior.
Link and node objects are used to build networks over which entities may flow. A link defines a pathway for entity movement between objects. A node defines a starting or ending point for a link. Links and nodes can be combined together into complex networks. Although the base link has little intelligence we can add behavior to allow it to model unconstrained flow, congested traffic flow, or complex material handling systems such as accumulating conveyors or power and free systems.
The final class of object is a transporter and is sub- classed from the entity class. A transporter is an entity that has the added capability to pickup, carry, and drop off one or more other entities. By default transporters have none of this behavior, but by adding model logic to this class we can create a wide range of transporter behaviors. A transporter can model a taxi cab, bus, AGV, subway car, forklift truck, or any other object that has the ability to carry other entities from one location to another.
A key feature of Simio is the ability to create a wide range of object behaviors from these six basic classes. The Simio modeling framework is application domain neutral -- i.e. these six basic classes are not specific to manufacturing, service systems, healthcare, military, etc.. However it is easy to build application focused libraries comprised of intelligent objects from these six classes designed for specific application.. For example it is relatively simple to build an object (in this case a link) that represents a complex accumulating conveyor for use in manufacturing applications. The design philosophy of Simio directs that this type of domain specific logic belongs in the objects that are built by users, and not programmed into the core system.
Modeling in Simio begins with base objects -- it is the foundation on which higher level objects are built. A base object in Simio is a fixed object, agent, entity, link, node, or transporter that has intelligence added by one or more processes. Processes give an object its intelligence by defining the logic that is executed in response to events.
Each process is a sequence of process steps that is triggered by an event and is executed by a token.A process always begins with a single Begin step, and ends with a single End step. A token is released by the Begin step and is simply a thread of execution (similar to entities in Arena). A token may have properties (input parameters) and states (runtime changeable values) that control the execution of the process steps. You can define your own classes of tokens that have different combinations of properties and states.
The modeling power of Simio comes from the set of events that are automatically triggered for the six basic classes of objects, along with the process steps that are available to model state changes that occur in response to these events. Fully mastering the art of building intelligent objects involves learning the events and the collection of available process steps, along with the knowledge and experience of how to combine these steps to represent complex logic.
Each step in Simio models a simple process such as holding the token for a time delay, seizing/releasing of a resource, waiting for an event to occur, assigning a new value to a state, or deciding between alternate flow paths. Some steps (e.g. Delay) are general purpose steps that are useful in modeling objects, links, entities, transporters, agents, and groups. Other steps are only useful for specific objects. For example, the Pickup and Dropoff steps are only useful for adding intelligence to transporters and the Engage and Disengage steps are only useful in adding intelligence to Links.
Each object class has its own set of events. For example, a link provides events that fire when entities enter and leave the link, merge fully onto the link, collide with or separate from other entities that reside on the link, move within a specified range of another entity, etc. By providing model logic to respond to these events we can completely control the movement of entities across the link. For example, to add accumulation logic to the link we simply write a small process that its triggered when an entity collides with the entity it is following, and reassigns the speed of the entity to match the speed of the entity that it is following.
The process steps that are used to define the underlying logic for an object are stateless -- i.e. they have properties (input parameters) but no states (output responses). This is important because this means that a single copy of the process can be held by the object class definition, and shared by an arbitrary number of object instances. If the process logic is changed, this fact is automatically reflected by all instances of the object.
The states for an object instance are held in elements. Elements define the dynamic components of an object and may have both properties (input parameters) and states (runtime changeable values). Within an object the tokens may execute steps that change the states of the elements that are owned by the object.
An example of an element is the station that defines a location within an object. Stations are also used to define entry and exit points into and out of an object. Entities can transfer into and out of stations (using the Transfer step), and a station maintains a queue of entities currently in the station as well as entities waiting to transfer into the station. A station has a capacity that limits transfers into a station. Hence an entity arriving to an object over a link can only exit the link and enter the object if the entry station for the object has capacity available.
Although simulation has traditionally been applied to the design problem, it can also be used on an operational basis to generate production schedules for the factory floor. When used in this mode, simulation is a Finite Capacity Scheduler (FCS) and provides an alternative to other FCS methods such as optimization algorithms and job-at-atime sequencers. However simulation based FCS has a number of important advantages (e.g. speed of execution and flexible scheduling logic) that make it a powerful solution for scheduling applications
Simulation provides a simple yet flexible method for generating a finite capacity schedule for the factory floor. The basic approach with simulation-based scheduling is to run the factory model using the starting state of the factory and the set of planned orders to be produced. Decision rules are incorporated into the model to make job selection, resource selection, and routing decisions. The simulation constructs a schedule by simulating the flow of work through the facility and making "smart" decisions based on the scheduling rules specified. The simulation results are typically displayed as jobs loaded on interactive Gantt chart that can be further manipulated by the user. There are a large number of rules that can be applied within a simulation model to generate different types of schedules focused on measures such as maximizing throughput, maintaining high utilization on a bottleneck, minimizing changeovers, or meeting specified due dates.
Because of the special requirements imposed by scheduling applications (e.g. the need for specialized decision rules and the need to view the results in the form of an interactive Gantt chart), simulation-based scheduling applications have typically employed specialized simulators specifically designed for this application area. The problem with this approach is that the specialized simulators have built-in, data-driven factory models that cannot be altered or changed to fit the application. In many cases this built-in model is an overly simplified view of the complexities of the production floor. .This one model fits all approach severely limits the range of applications for these tools. Some production processes can be adequately represented by this fixed model, but many others cannot.
Simio takes a different approach by allowing the factory model to be defined using the full general-purpose modeling power of the tool. Hence the range of applications is no longer restricted by a fixed built-in model that cannot be altered or changed between applications. The complexities of the production process can be fully captured by the user-built Simio model. This not only includes the logic within each work center, but also the material handling required to move jobs between work centers.
The specialized requirements for FCS applications are addressed by incorporating features into Simio to specifically support the needs of FCS. These features include the support for externally defined job data sets along with very flexible modeling of resources and materials. Although these features are specifically designed to unleash the full modeling power of Simio for FCS applications, they are also useful in general modeling applications.
A Simio job data set allows a list of jobs to be externally defined for processing by the simulation model. The jobs are defined in a data set containing one or more tables, with relations defined between table columns. The specific schema for holding the job data is arbitrary and can be user defined to match the data schema for the manufacturing data (e.g. an ERP system). The job data typically includes release and due date, job routings, setup and processing times, material requirements, as well as other properties that are relevant to the system of interest.. The objects in Simio can directly reference values specified in the job data set (e.g. processing time) without knowing the schema that was implemented to store the data.
Any object in Simio can serve as a capacitated resource and can have its own independent behavior. Resources can be selected from a list based on flexible rules such as minimum changeover time or longest idle time. . Resources also support very flexible rules (earliest due date, least remaining slack, critical ratio, etc) for selecting between competing jobs that are waiting to seize the resource. Finally the job usage history for resources can be displayed on an interactive Gantt chart.
The Materials element in Simio provides direct support to model things that can be consumed and produced during the execution of the model. Materials can also be defined hierarchically to model a traditional Bill of Materials (BOM) for manufacturing applications. Hence a manufacturing step can be modeled as the consumption of a specific list of materials within the hierarchical BOM.
Simio is a new modeling framework based on the core principles of object oriented modeling. It is unique in the following ways:
Gordon, Geoffrey, 1960 October 25. A general purpose systems simulator. (Unpublished manual.) White Plains, N.Y.: IBM. Corp. ASDD Commercial Dept.
Henriksen, J. O. 1976. Building a better GPSS: a 3:1 enhancement. In Proceedings of the 1975 Winter Simulation Conference, 465-469. New Jersey: AFIPS Press
Markowitz, H., Hausner, B., and Karr, H. SIMSCRIPT: A simulation programming language, Prentice Hall, Englewood Cliffs, N. J. 1962
Nygaard, K and O-J Dahl, . SIMULA --An Extension of ALGOL to the Description of Discrete-Event Networks, presented at the Second International Conference on Information Processing (1962)
Pegden, C. D. and A. A. B. Pritsker (1979). SLAM: Simulation Language for Alternatives Modeling. Simulation, Vol. 33, No. 5.
Pegden, C. D. (1982). Introduction to SIMAN. Systems Modeling Corporation.
Pegden, C. D. and D. A. Davis (1992) Arena: a SIMAN/Cinema-based Hierarchical Modeling System; In Proceedings of the 1975 Winter Simulation Conference 390-399
Pritsker, A. A. B. 1967. GASP H User's Manual. Arizona State University.
C. Dennis Pegden is the founder and CEO of Simio LLC. He was the founder and CEO of Systems Modeling Corporation, now part of Rockwell Software, Inc. He has held faculty positions at the University of Alabama in Huntsville and The Pennsylvania State University. He led in the development of the SLAM, SIMAN, Arena, and Simio simulation tools. He is the author/co-author of three textbooks in simulation and has published papers in a number of fields including mathematical programming, queuing, computer arithmetic, scheduling, and simulation. His email is firstname.lastname@example.org. Additional company information can be found at www.simio.com.