Simio vs. SimPy: Choosing a Simulation Tool for Engineering Work
Picking a simulation tool is less about building on screen versus writing code. It’s more about who will use the model, how long it will last and what it must connect to.
Two different strengths
A simulation is a computer model of a working system, like a factory, clinic or help desk. You play out weeks of activity on the computer to test a change before you make it for real. Simio and SimPy are two common ways to build one. Simio is a commercial tool built for visual discrete-event simulation. That’s a kind of simulation that jumps from one event to the next, like a customer arriving or a job finishing. In Simio you build with ready-made blocks on screen, watch the model run as an animation, and set up experiments. That helps engineers test ideas and show them to the people who make the call. It can be especially good when watching the model run is how people check it and agree on a decision.
SimPy is a free, open-source Python library for the same kind of simulation. A library is a bundle of ready-made code you can use in your own programs. In SimPy, you write everything as code. That includes the machines and workers (resources), the steps work goes through (processes) and the events. It even includes the simulated world itself (the environment). That makes it easy to hook the simulation up to other Python tools. It can pull in data and feed a program that searches for the best option. It can also work with machine learning, run automatic tests or power a custom web page.
Where SimPy really pays off
Building the model in code is a big plus when a few things matter. You want the same results every time you rerun it (reproducibility). You want a full history of every change (version control). And you want it to plug into other tools. In code, you can test each piece of the model on its own. The computer can try a whole range of settings for you. And the results can go straight into optimization or statistics, without copying files from one program to another.
The catch is that you have to build the visuals yourself. You also have to build the handy shortcuts a dedicated tool already has for your kind of work. A sloppy SimPy project can turn into Python nobody else can follow. A tidy one keeps four things apart. There’s what the model knows right now (its state) and the rules for what happens at each event. Then there are the settings for each experiment and the way the results are shown.
How to choose
Choose based on who will use the model and how long it needs to last. Say engineers need to build models fast on screen and show animations to the people who have a say. Then a commercial visual tool for discrete-event simulation (DES) may be worth it. Now say the simulation is turning into one programmable part of a bigger analysis tool. Then SimPy can be a great fit.
The queue simulation in this site’s lab follows that second pattern. The simulation’s state is kept separate from how it’s drawn on screen. But the same stream of events drives both the moving picture and the numbers that measure it.