Great, so you decided to build a simulation model. For a client? For yourself? For research? No matter its purpose, there are a number of steps you should always conduct before even launching your simulation program. I recently discussed these with a colleague of mine and we came up with this list:
This is the writing room of the Simpsons creators. They knew you need good planning before starting out.
Empty space, drag to resize
First, clarify what you are aiming to model in order to decide which paradigm you should use. Will it be a top-level presentation of reality, not interested in detailed entities and concerned about big-picture strategic outlooks? Sounds like a system dynamics model. Or will it contain discrete entities that are being worked on like in a factory floor or transporting goods? Check out discrete-event simulation. Or are you interested in modelling entities that act autonomously and interact with each other? Agent-based modelling will be your best friend.
Ideally, you mix and match paradigms according to your requirements. Sometimes, it is ideal to have an agent-based model where agent behaviour is governed by system dynamics equations. Unfortunately, I know only one tool giving you that freedom (www.anylogic.com ).
Your paradigm decision will limit the tools in question. Each paradigm has a number of classic tools that usually differ only little. AnyLogic allows you to model all three paradigms which is quite a competitive advantage. However, the learning curve is somewhat steeper than with conventional “1 paradigm only” tools.
Remember that tool choice should not limit you. It is similar to programming: once you know the drill, it isn’t too hard to accustom to a new language.
This is a very important question to answer: What should be inside your model and what should stay outside. Get a clear understanding before starting out. Being clear on what stays out will help avoid scope creep, a modeler’s worst enemy.
What data will you load into your model? Do you have it already? It is never too early to ask stakeholders to provide sample data. The cost of model changes later due to data changes is much higher than you’d think. Get it right early.
Also, decide what should be your “parameters”, i.e. which things in the model will you want to play around with and change. It pays to define this early because model logic and charts often depend on this decision.
Many modern simulation models employ hierarchical object-oriented principles. Start to think about how you will structure your model, i.e. which elements will become separate items in your model. Then, group them into a useful hierarchy.
Consider modelling a traffic network: you will have roads that might embed cars. Each car might have passengers.
Next, take your model objects and sketch how and when they will interact. Will cars “talk” to pedestrians? Will roads provide information about their traffic level?
You can employ BPMN notation or other alternatives to support your understanding.
So far, you thought about your end product. Now, plan how you want to get there. Create the simplest possible model first. Then add functionality bit by bit, always ensuring everything still works as it should.
Plan this out explicitly so you do not get lost in “I am just going to add this cool feature now” mode.
Make sure you got your planning right...
Empty space, drag to resize
Most likely, you have done some or all of these steps implicitly but I do recommend to spell them out explicitly. If you work for a client, it makes a very good impression as you know what you are doing. If you work for yourself, it massively helps in structuring and organising your model, a task that should not be done while you build the model.
