February 12, 2010

Introduction to Simio

At the Winter Simulation Conference 2008, together with my colleague, I met the Simio team, as they were having an exposition at the conference about their new simulation software. Back then, Simio was not yet released, but the guys were able to impress the audience with some interesting features already. Including me and my colleague. Since then, Simio got further developed and in late summer 2009 they went to market with Version 1.0.

Hybrid Object-Oriented / Process-Oriented Modeling Paradigm

Simio incorporates a modeling paradigm that is a hybrid of two paradigms that have long been around in simulation. The way it works – and I think this approach is brilliant – is that anything in a model is an object (and the model itself as well). We know that in OOP, objects have methods. In Simio, methods are replaced by processes. A process in Simio can be thought of as a process in Arena, which is not surprising, as the founder of Simio LLC is Dennis Pegden, the founder of Systems Modeling. The main difference to an Arena process is that it is not the entity that executes the process (i.e. passes through the process), but instead it is a so called token. A token is therefore the smallest unit in Simio (and it is not an object). A token always has an associated object, and in most cases this is the entity.

Godd extensibilty without programming

This point has two perspectives: On the one hand, it is possible to extend Simio without ever touching code, and create new objects, inherit from other objects, and so forth. But it is not as easy and straighforward as Simio like to make us believe. There is no way a non-experienced user, who has no deep knowledge of discrete simulation, can ever create new objects, whose functionality goes beyond that of simple server where we just add a new state variable. Extending Simio and creating new objects is convenient once you are familiar with the Simio modeling framework, but getting there is not.

By the way, the statement that it is possible to extend Simio without coding is wrong: Coding does not necessarily mean wrtiting code in c# or any other programming language. Clicking together process steps, elements, adding properties, states, events, etc is also coding, but with different symbols. That coding this way is any easier than coding c# is not true by default, but depends on the user's experience.

Automatic 3D Support

When building a model in Simio, the user automatically creates a 2D and a 3D version of the model. The modeler can quickly switch between both views and change an object's look with few clicks. Simio integrates seamlessly with the Google 3D Warehouse, which means the modeler can download 3D images from there and apply them to his objects in the model. A truly impressing feature for any potential customer, including me ;-)

Application Programming Interface (API) for C#

Im my opinion, one of the most interesting aspects of a simulation tool is its openness to custom extensions. Simio does already provide a decent API for writing your own components, and the team promised to extend this API further in upcoming sprints. This is what is currently possible via the API (sprint 33)

  • Write Design-Add-Ins: This is an add-in that can be invoked from within the Simio tool and which has access to the currently opened model. Objects can be added and removed programmatically, their locations can be set, as well as their property values. It is currently not possible to programmatically access an object's elements, that is for example data tables or sequences. In my opinion this is a major drawback and must be added ASAP.

    The design-add in lets you for example generate the facility view of the model from external data. In a project we wrote a design-add-in to load information about workstations, order types, sequences etc. from an MS Access database (if we want to call it that). This very helpful if the model has many workstations and you cannot add them all via drag & drop. The downside that we uncovered was that Simio runs into serious memory problems if too many objects are present in the model. And for my taste this happens a bit too early (100 workstations in a model shouldn't be a problem). It was said by the Simio team, though, that performance issues will be handled in future sprints.
  • Write custom elements and steps: This is one of the easiest and probably most common ways to extend Simio. If you are familiar with Arena, you already know what steps are. Steps are a piece of functionality that can be used in a process. Steps in a process are aligned in sequence, and executed one after the other. Simio already comes with a broad set of steps; for some applications the right step is not included, though. Then, the API helps you out by providing an interface that can be implemented to create a custom step in c#. The same goes for elements. At this point I will not dive any deeper into creating custom steps or elements, as this post is to give an overview of the Simio tool.
  • Generate experiments and scenarios programmatically: Very cool and brand new feature (sprint 33); allows you to create experiments programatically and populate the experiments with scenarios. Very powerful if your experimentation plan includes a large number of parameter constellations, which would take forever to type in manually.