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:
- Which paradigm?
- 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 ).
- Which tool?
- 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 modeller’s worst enemy.
- Inputs and parameters
- 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.
- Hierarchy and structure
- 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.
- How to grow your model
- 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.
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.
What methods, tools and steps do you use? How do you approach a modelling task?