How much “simulation fundamentals” do you really need to build a simulation model?

As with many things in life: it depends.

This question really boils down to two considerations: how deep do you want your model to be and how deep do you want to go with your model (and future models).

The depth of your model concerns how closely its details match with reality (i.e., its abstraction level). There’s a natural tendency to feel that most details of an operation are critical to accurately model it and should thus be incorporated. To temporarily ignore the skills of the individual modeler, the more detailed (i.e., low abstraction level) a model is, the more time and data it takes to build it and the harder it is to maintain it.

The ‘data’ component shouldn’t be underestimated - the level of, amount of, and specific type of data required build a detailed model is oftentimes not readily on hand. This can range from needing to find distributions of patient visit times in a hospital to ascribing specific probabilities in routing that’s otherwise handled in the real world by a PLC (whose programmer left two decades ago and left no documentation).

Inversely, the more abstract your model is of reality, the less details it’s concerned with; the details are replaced with generalizations. This effectively makes it simpler and faster to model, at the cost of specific accuracy. Don’t confuse this as a “lesser” model though - it can still have overall accuracy. Provided that the inputs and outputs are correlated correctly, and to some acceptable margin of error, the model itself can be extremely useful!

As an example, take a model of an Emergency Room where patients arrive, stay for some time, then leave. If you know the frequency of arrivals and the distribution of times of a patient’s stay, this is an extremely quick and simple model to build. We’re not concerned about dependencies on staffing or equipment, patient priorities, or any other real-world specifics. Without much effort, we’d have a tool that could quickly inform us of how the arrival rates impact waiting times. This is why it’s always advised to start with the highest-level representation of the system and only make it more detailed when it’s necessary.

Then there’s how deep you want to go with modeling – i.e., the depth of your knowledge. Simulation modeling is like any other trade with a high ceiling capacity (let it be virtual, like programming, or physical, like woodworking); a few days of training is enough to get anyone started, but mastery takes thousands of hours. Complexities arise from knowing how to map real systems to the virtual environment and accruing enough experience to know what techniques to employ and when. This is exacerbated when the problem you’re modeling has more complexities than you can mentally keep track of at any given time. In this way, modeling is akin to larger scale programming projects where you need not just creative problem-solving skills, but robust organizational skills.

From the many years I taught AnyLogic’s three-day training course, something I frequently noticed is people jumping to model large scale problems, assuming they’d just learn on the way, and end up drowning in the details.

 As you start modeling larger and larger problems, you need to keep track of the assumptions you make along the way, the abstractions used to model specific parts of the system, and how different components interact and change over simulated time.

The abstractions part specifically is one of the hardest parts to have a full grasp on until you’re already decently experienced. Concepts that are easy to grasp intuitively don’t always translate to clean or obvious designs in the simulation space. A large part of professional-level simulation modeling is being able to see a problem and formulate an idea of how truly complex it would be to model it.

Taking inspiration from a recent model I built: consider a facility where trucks with pallets of assorted item types arrive, get unloaded, processed, and shipped back out.

The “real” version of this facility does not need to differentiate between incoming and outgoing pallets. However, in the simulation space, we need to create (instantiate) the pallets with some inputs - let it be the items in the initial object or the designation of item type to be put in each (initially empty) pallet. There are some shared attributes though, such as an initial location for this pallet. Is this modeled as two different data types or one with optional inputs for each type? One type may seem cleaner, but we’ll need to customize the reporting to ensure the correct sub-type is displayed. Two types may be more explicit, but what if an incoming pallet is flagged to get skipped over and gets immediately shipped back out – we’d need to additional logic to “convert” it to the other type. Another aspect is assigning items to pallets as part of orders to be shipped out and keeping access to them throughout the logic (e.g., for routing it through the facility). Many of these types of designations are implicit in the real world through shared knowledge or automated systems, but these have to be recreated in the virtual space. Having some ‘Order’ type that keeps a reference to the reserved items, even when they might be in separate parts of the facility at a given moment, add to the organizational complexity of modeling.

Note that these considerations are just one of many that went into the decision process (for the ‘one vs two’ problem, due to some specific rules and conditions that incoming vs outgoing pallets had to adhere to, I went with two types).

Considering the big question of the post, you should reflect on what your needs are and what time (and patience), money and data are available. The fact that simulation modeling has a nearly infinitely high upper ceiling for skill level makes it often difficult to gauge how much effort is involved in modeling a given scenario. For when the answers aren’t clear, you can always find trustworthy sources with enough modeling experience to help guide you in the right direction!