Search the Community

Hi, I have made an example model illustrating how to do what you are asking. In the attached model, I have 1 entity that requires a 40 hour delay & a Secondary resource for processing. I have a Day Shift worker and a Night Shift worker, each work 12 hour shifts, and the Entity seizes whichever is availabe from a list upon entering the Server. By default, if a secondary resource is seized, the worker will attempt to finish the current job before going off-shift. This is nice if there is something like 15 or 20 minutes left on a job, but not ideal if there is 28 hours left... What I did was created a process that gets Triggered by the Workers' OffShift Add-On process that Interrupts Processing > Releases the Worker > and Transfers the Entity back into the Server Object - which will then start the whole processing process all over again and seize whatever worker is available. Note that in the Interrupt Step, I set the Interupted Process Action to Resume Delay, and the Save Remaining Process Time property to Record ths remaining processing time to the ModelEntity.ProcessTime State (which is initially assigned to 40 in the Source and then gets updated upon every interrupt) For more examples of Interrupting processes see the SimBits: InterruptibleOperator, InterruptingAcrossMultipleServers, & InterruptingServerWithMultipleCapacity Thanks InterruptingProcessingToSwitchWorkers.spfx

Today I had to do a quick and dirty model in Arena. I just thought I would take this opportunity to do a quick post on my findings. By no means is this a comprehensive analysis of the two tools, but I just felt like sharing my opinion of the two. Being the predecessor to Simio, it is natural to compare the two tools, and even after using Arena for the short amount of time I did... the differences were astounding. I will admit that Simio was my first immersion into the world of using corporate modelling tools. It was a tough journey to get to the stage where I felt comfortable using Simio, but looking back... I wonder how I got by using the archaic tools I did. The learning curve to Simio was extremely steep (in my humble opinion that is), and I still don't believe I am anywhere near utilizing 100% of Simio's capabilities. That being said... Simio is a relatively new tool and is still under active development. After launching Arena for the first time, the first thing that struck me was how bland/simple it was. Putting that to one side, I was impressed with how intuitive it was to use. This may be a side effect of using Simio, but barring my inability to find the Connect button for linking the objects together, I simply dragged objects into the process view and linked them up. The objects all had names that made sense (workstation... server... what were you guys thinking? >_>), and ignoring the fact that most of the symbols looked like they were drawn by pre-schoolers... the process of getting a simple model running was child's play. Within 5minutes I had my first working model. (I can tell you that it took a lot longer than that for my first Simio experience) One of the features I would love to see the most in Simio... AVI export. It was right there, and it was easy. Come on Simio! After placing multiples of an object, there was a table at the bottom of the screen with every other object of the same type, allowing you to quickly locate and edit properties of said objects... Simio... adding something like this would immeasurably improve productivity (mine atleast) and increase my levels of sanity after working with large models. Another point to note was that Arena felt very responsive, and while this normally would not be an achievement for a piece of software... Arena did not crash or give cryptic errors. (Simio crashed multiple times during my first 30minute experience with it... and I didn't even know how to do anything more advanced with it at that stage). The last point to make in this section of the post, is how human readable the reports were. My eyes were not assaulted with a million numbers. You could argue this is a bad thing or a good thing, but at the end of the day, some of these reports matched what I typically look for in Simio, and have to waste time trying to get. They were also laid out clearly and concisely. I am sure Arena has a fairly similar learning curve to Simio once you get to the more advanced stuff, but I have got to say that Arena definitly has the edge of many years of polish and tweaking. I am not here though to plug Arena. Let's get to the meat of this post now. The things I saw in my short time using Arena in comparison to Simio, that Simio did better. Even though I feel Simio has a lot more work to do on getting their product to the kind of a level Arena sits at (polish and usability) in terms of: aesthetics, power, time-savings (gained from re-usability of objects in Simio, instead of hard coded processes in Arena), feature base, and on-going development... Simio wins hands down. The benefits of object based models in comparison to process based models are imeasureable, and while some of the more basic features you would expect (or take for granted) in a modelling tool are lacking or missing in Simio, a lot of thought and has gone into the development of this tool. You can really see how Simio is the next generation of tool. I guess the point I am really trying to convey is, Simio rocks. It may be buggy as hell, it may not have every bell and whistle to satisfy my unreasonable demands, and it may not be as smooth or intuitive as Arena, but it is actively developed and a lot of love and care went into its development. I dare say that given time and a bigger/more active community, Simio will truly come into its own. The Arena community may be larger, but it does not appear as if Arena itself is evolving to meet the ever changing demands of the market. I guess it won't be long until the remaining Arena modellers move on and embrace newer technologies like Simio. Sorry for the long post. TLDR: Keep up the good work guys!

You can use Simio at several levels. Here are a few: • You can build simple models entirely within a Process (limited or no use of library objects). • You can use the Standard Library. This was designed to make it easy to do the more common applications, but is not intended to do everything. This library will be enhanced and supplemented with other libraries in the future. • You can enhance the Standard Library Objects via add-on processes. This functionality is still under development, but processes will be easy to define to supplement the OnEntry and OnExit behavior. For example, you may want to collect and report custom statistics or have custom exit logic. • You can enhance/replace the Standard Library Objects by inheriting from them and modifying any of the predefined behavior. For example the Server currently only allows a single failure stream. You could create a new MyServer object that reproduces the included logic to support three failure streams. • You can create entirely new objects by inheriting from base class objects (like Fixed Object, Link, Node, and Intelligent Object). With this approach you can graphically define any combination of properties and behavior that you want using Steps and Elements inside Processes.

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.

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.

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.