Jump to content

Welcome to the Simio Forum

Welcome to the Simio Forum! Experience the full experience of the forum by becoming a Simio Insider!


New Software Release

Our latest release, Simio 10.174, will be live in July 2018!

Save the Date!

Simio Sync is May 14-15, 2018! More details coming next month.


  • Content count

  • Joined

  • Last visited

Community Reputation

0 Neutral

About cdpegden

  • Rank
    CEO, Founder
  • Birthday May 27


Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. We do not have any plans for the first release that go beyond basic decision rules. However you are correct in saying that Simio objects could encapsulate code from other applications that support these techniques. You will be able to integrate with any .NET compatible language.
  2. cdpegden

    Simio Objects / Models from Data

    Jon, Simio is a .NET product and so any of the 20+ .NET languages (c#, Basic, J#, Forth, etc.) can be used as a scripting language with the product. The exact features for the scripting interface have yet to be designed/implemented. We plan to expose as much functionality as possible through a scripting interface. I agree that this can have a huge impact on productivity for both building models from operational data files, and also supplying data to those models. Thanks for your feedback .... Dennis Pegden
  3. cdpegden

    Reserving Resources

    B, I have thought about the same issue that you raised. One idea that I had was to allow drag and drop in “approximate” or “actual” mode. In approximate mode we would update the setup/processing times using logic similar to Preactor/Tempo. In actual mode we would rerun the simulation from a previous saved “snapshot” point to get a true rescheduling based on the details of the model. The user would be able to switch between these modes. Obviously “actual” mode would require a few seconds to complete the drop operation.
  4. cdpegden

    Reserving Resources

    I have been thinking about the issue that has been raised on the reservation of backward sequences (thanks for your feedback). As I understand it the point is that when we reserve for Job X, we might not know the predecessor Job, and therefore cannot compute a sequence dependent setup time. In addition, as new insertions of reservations occur, the sequence dependent setup times keep changing. To resolve this it seems like we have to do the following: When examining a possible reservation for Job X, we must look at its successor Job Y (if any), as well as it’s predecessor (if one exists). If its successor Y has a sequence dependent setup time, we must adjust the reservation for Y (if necessary) to reflect the fact that it would be preceded by X. If the adjustment to Y and insertion of X is not possible given the insertion gap between X and Y, then the reservation is denied for this slot. If X is reserved in front of Y, it might create a new slot between X and Y for an additional reservation. If a new Job is assigned a reservation in this slot the setup time for Job Y is again recomputed. Note that we would need to do the same logic as above to support user drag-and-drop of jobs on the Gantt. Let me know if you think this addresses the issue. Thanks again for the feedback
  5. cdpegden

    Reserving Resources

    In some modeling applications we have a need to reserve a sequence of one or more resources to perform work at some future time. Hence we are at time T1 in the model, and we want to ensure that a sequence of resources is available at some later time to perform work. The actual work duration is adjusted based on the work schedule of the resource. Each resource in Simio maintains a list of future reservations. Future reservations are made by verifying and assigning available timeslots within the future reservation list. The following steps allow the user to work with resources to check, reserve, and cancel future availability. The check step is used to determine if a sequence of resources is available to perform work (adjusted by the work schedule for each resource) at some time in the future. The Reserve step is used to reserve a sequence of resources at some time in the future. The cancel step is used to cancel a single reservation or a reservation sequence. A typical process is: Check-Reserve --- some steps that span time (e.g. waiting for the reservation event to fire) --- Seize-Work-Release. A sequence of resources may be reserved in either a forward or backward reservation sequence. In a forward sequence the reservations are made starting with the first resource and ending with the last resource in the sequence. In a backward sequence the reservations are made beginning with the last resource, and working towards the first resource. The backward sequence is typically used to reserve resources for operations that complete at a specified target date (e.g. the due date). In this case the entity may wait for the reservation event to fire before seizing the resource. All reservations within a reservation sequence are linked together. The Seize step specifies a seize mode as follows: Normal: Seize without a reservation. This seize will give up the resource to a reserved seize. Reserved: Seizes using a reservation slot for the current time. This will preempt the resource from a normal seize (if necessary). Before doing a reserve, a user may check on resource availability using the Check step. The Check step is similar to the Reserve step except the reservations are not actually made. The Reserve and Check steps have two exit points: one for successful and one for unsuccessful. The only difference between the two steps is that the Reserve step actually reserves the resources. These steps have the following properties: SequenceType: specified as Forward or Backward. EarliestStartTime: the earliest start time for a forward reservation sequence. LatestStartTime: the latest start time for a forward reservation sequence. EarliestEndTime: the earliest end time for a backward reservation sequence. LatestEndTime: the latest end time for a backward reservation sequence. MaximumSpan: the maximum time span (start to end) for a complete reservations sequence. SequenceList: a repeating sequence of resources requirements. Each resource requirement in the sequence list has the following properties. ResourceID: the name of the resource to be reserved, or the name of the resource list from which the resource is to be selected, along with the selection rule. WorkTime: the amount of work that must be performed on this resource. MaximumSpan: the maximum span time to perform the work on this resource. Relation: the relation between this reservation and the predecessor/successor reservation. Note that the resource for a resource requirement may be specified as a specific resource or selected from a list of available resources. For example the required resource might be a tank, and three tanks might be defined within a resource list. The relation controls the reservation pattern within the sequence and can be specified as one of the following: Sequential: Each resource reservation in the sequence ends before the successor resource reservation starts. Overlap: The successor and previous reservation are unrestricted and may freely overlap. ParallelStart: The successor and previous reservation must start at the same time. ParallelEnd: The successor and previous reservation must end at the same time. The relation defines the relation between successive reservations within the reservation sequence. A reservation sequence may mix one or more relations to achieve the desired sequence.
  6. A common way to create object definitions in Simio is by combining other objects, for example combining machines and a robot to define a work cell object. This type of object is called a composed object because we create this object by combining two or more component objects. This object building approach is fully hierarchical, i.e. a composed object can be used as a component object in building higher level objects. A second, more basic method for creating objects in Simio is by defining the logical processes that alter their state in response to events. For example, a machine object might be built by defining the processes that alter the machine state as events occur such as part arrival, tool breakdown, etc. This type of modeling is similar to the process modeling done in traditional modeling systems in use today such as Arena or GPSS. An object that is defined by describing its native processes is called a base object. A base object can in turn be used as a component object for building higher level objects. The final method for building objects in Simio is based on the concept of inheritance. In this case we create an object from an existing object by overriding (i.e. replacing) one or more processes within the object, or adding additional processes to extend its behavior. In other words we start with an object that is almost what we want, and then we modify and extend it as necessary to make it serve our own purpose. For example we might build a specialized drill object from a generalized machine object by adding additional processes to handle the failure and replacement of the drill bit. An object that is built in this way is referred to as a derived object because it is sub-classed from an existing object. Regardless which method is used to create an object, once created it is used in exactly the same way. An object can be instantiated any number of times into a model. You simply select the object of interest and place it (instantiate it) into your model.
  7. The Simio object framework is built on the same basic principles as object oriented programming languages; however these principles are applied within a modeling framework and not a programming framework. For example the Microsoft development team that designed C# applied these basic principles in the design of that programming language. Although these same principles drive the design of Simio, the result is not a programming language, but rather a modeling system. This distinction is important in understanding the design of Simio. Simio is not simply a simulation modeling tool that is programmed in an OOP language (although it is programmed in C#). Likewise it is not simply a set of classes available in an OOP language such as Java or C++ that are useful for building simulation models. Simio is a graphical modeling framework to support the construction of simulation models that is designed around the basic object oriented principles. For example when you create an object such as a “machine” in Simio, the principle of inheritance allows you to create a new class of machines that inherits the base behavior of a “machine”, but this behavior can be modified (overridden) and extended. Whereas in a programming language we extend or override behavior by writing methods in a programming language, in Simio we extend or override behavior by adding and overriding graphically defined process models. This distinction between object oriented modeling and object oriented programming is crucial. With Simio the skills required to define and add new objects to the system are modeling skills, not programming skills.
  8. Simio is a simulation modeling framework based on intelligent objects. The intelligent objects are built by modelers and then may be reused in multiple modeling projects. Objects can be stored in libraries and easily shared. A beginning modeler may prefer to use pre-built objects from libraries; however the system is designed to make it easy for even beginning modelers to build their own intelligent objects for use in building hierarchical models. An object might be a machine, robot, airplane, customer, doctor, tank, bus, ship, or any other thing that you might encounter in your system. A model is built by combining objects that represent the physical components of the system. A Simio model looks like the real system. The model logic and animation is built as a single step. An object may be animated to reflect the changing state of the object. For example a forklift truck raises and lowers its lift, a robot opens and closes its gripper, and a battle tank turns its turret. The animated model provides a moving picture of the system in operation. Objects are built using the concepts of object orientation. However unlike other object oriented simulation systems, the process of building an object is very simple and completely graphical. There is no need to write programming code to create new objects. The activity of building an object in Simio is identical to the activity of building a model – in fact there is no difference between an object and a model. This concept is referred to as the equivalence principle and is central to the design of Simio. Whenever you build a model it is by definition an object that can be instantiated into another model. For example, if you combine two machines and a robot into a model of a work cell, the work cell model is itself an object that can then be instantiated any number of times into other models. The work cell is an object just like the machines and robot are objects. In Simio there is no way to separate the idea of building a model from the concept of building an object. Every model that is built in Simio is automatically a building block that can be used in building higher level models.