Search the Community

1) Start by representing your Pressure and Temp as States of type Level (see Definitions > States). These state values can continuously change based on the value of a rate. Setting that rate to +, - or 0 is something you can do wherever appropriate in your model. (Example: have a state named Pressure, and assign Pressure.Rate to its rate of change based on what causes it to rise or fall). 2) Create a Monitor for each State (Definitions > Elements) of Type CrossingStateChange with an appropriate Initial Threshold Value. When the value of the state being monitored crosses the threshol value, it automatically triggers an event named MonitorName.Event. (Example: have a Monitor named PressureExceeded and set its threshold at a maximum pressure allowed (e.g. 250)) 3) If you just had a single monitor, then on a Server you could specify reliability logic with a failure of type Event Count Based and use the event from that monitor (Example: Fail each time PressureExceeded.Event occurs). You don't say if you intend to use a Server or a custom machine. The basic approach above will work in either case. But to deal with multiple sensors might require some custom processes or a custom object because the Server is designed to deal with only one failure stream. There are several ways of approaching multiple failure streams depending on your objectives. Here is a simple model in 5.81 to illustrate:ServerFailsBasedOnSensor.spfx

I prefer “hack” to “cheat” That’s an interesting comment, though, about sub-models. I feel that in Simio the term ”sub-model” doesn’t really exist; or, rather it describes any model, so it doesn’t really mean anything. I understand the concept of a sub-model, but due to Simio’s object-oriented design any model is a sub-model. The standard library server, for example, is a sub-model. As is the default entity “ModelEntity” and the default model “Model”. So yes, in the sense that I created a custom object (or model) and then used it in another model, the Spinning Server is a sub-model. But then again so is the regular server The real "cheat" here is that the “server” is actually an entity and requires logic (i.e. processes) at the model level to assist with instantiation, (also, most of the parameters are hard-coded, which introduces scalability issues).

I haven't done routing using tables, but I have definitely done server based decisions where each server had a row in the table. And things from server properties to parameters used within the server logic were also in the same row. The search step in conjunction with logic that tells you what the parent object you are in is.... works wonders. It is a staple form of modelling for me now. It is far easier to control parameter values from a table, than via the UI. As to the usage of the API... as you might guess... the API is not advanced enough to create or even edit models. All of the model development is done via the GUI, and a single experiment is created (with relevant properties to drive it), as experiments can't be created via the API either. The API is then solely invoked to change the parameters in the experiment, and run the experiment. The CSVs written out from the experiment are then sucked into the program, and processed and displayed in graphs or available to be spat out into pre-made excel sheets. This reduces the requirement of running a model from needing knowledge of excel + simio (quite a bit of knowledge is required here), to solely needing to run the one custom app and understanding what all the parameters you change do (API can't pull out definition descriptions). The custom app obviously uses the Simio API, but at no time requires the user to open the Simio GUI or touch the model directly. It won't mean much, but attached are a few screenshots of what kind of data we put in and get out using the custom tool. As you can see, you can add multiple scenarios in, and do the same kind of scenario comparison, and even look at what is happening Gannt chart wise.

I am trying to model a server with several failures, where each failure may have a different explanation and thus, a different pattern. One obvious approach is subclassing a Server and defining additional elements, such as Failure, Timers, etc and modify the processes so that several failures can cause the downtime of the server. However, I do not feel very comfortable with the scalabitliy of this approach. I mean, if a server has three types of failures I will have to add two new Failure elements, 8 timers, 4 corresponding to each Failure and so on. If at some point in time I need to add an additional failure, I would need to do the adding all over again, an so on. I am considering two different approaches for this, but I do not know if these are feasible or if there is a far better approach. Approach 1. I would like to subclass the server and create a Repeat Group property so that the user, by means of adding rows, may characterize as many failures as desired. The thing is, is is possible to modify the processes so that they are general enough to reflect any number of failures (with their corresponding characterization)? Approach 2. I was thinking of creating a new object, let us call it objFailure, which contains definitions and processes to reproduce the behaviour of a failure type. The idea would be that this objFailure has a property which would contain the number of an element within the project, so that when objFailure fails, the corresponding object fails. This way, modelling a server with several types of failures woukd consist in creating that server and as many objFailure as required, which would cause the server to fail as they themselves fail. The issue with this approach is that it may not be that easy to represent interferences among failures. For example, if objFailure1 is a count based event failure and objFailure is a Processing Time based failure, when objFailure1 occurs, the server stops and the time during which is down should not be taken into account by objFailure2. This may very complex to program effectively and efficiently.

We are now sponsoring a blog to help each other become more successful in our simulation projects. We will be sharing information and initiating discussions that will prove interesting and helpful to both experienced and novice simulationists. If you are not experienced at "blogging" let me assure you that it is pretty easy to participate. 1) You can just check http://www.simio.com/blog from time to time and see what's new. 2) If you don't want to miss any content, you can sign up for the RSS feed. This will result in an email automatically sent to you with each new post (approximately weekly). To sign up, look for the RSS link at the very bottom of the blog pages or in your toolbar. Or simply go now to http://www.simio.com/blog/feed. 3) For the most enriching experience, participate! Look at the end of each posting for a link to enter your comments. Or if you want to suggest topics or even post your own topic, contact me - I'd love to have your participation. This blog is not about Simio or any particular product, nor is it intended to be in any way commercial or sales-oriented. Success in Simulation is available to all simulationists, as well as anyone who wants to become a simulationist or who just wants to learn more about simulation. While we expect to focus mainly on discrete event simulation, articles on the related fields of agent-based modeling, system dynamics, and emulation will also be included. The articles will be intentionally be kept short for a quick read, and will be written in an informal style for easy reading. I encourage you to subscribe to the RSS feed so that you will automatically receive new articles as soon as they are posted.