top of page

system dynamic

The great majority of processes we observe in the world consist of continuous changes. However, when we try to analyze these processes it often makes sense to divide a continuous process into discrete parts to simplify the analysis. Discrete Event Modeling techniques approximate continuous real-world processes with non-continuous events that you define.

 

Here are some examples of events:

 

  • a customer arrives at a shop,

  • a truck finishes unloading,

  • a conveyor stops,

  • a new product is launched,

  • inventory levels reaches a certain threshold, etc.

 

 

In discrete event modeling the movement of a train from point A to point B would be modeled with two events, namely a departure event and an arrival event. The actual movement of the train would be modeled as a time delay (interval) between the departure and arrival events. This doesn't mean however that you can't model the train as moving. In fact, you can produce visually continuous animations for logically discrete events.

The term Discrete Event is however mainly used in the narrower sense to denote "Process-Centric" modeling that suggests representing the system being analyzed as a sequence of operations being performed on entities (transactions) of certain types such as customers, documents, parts, data packets, vehicles, or phone calls. The entities are passive, but can have attributes that affect the way they are handled or may change as the entity flows through the process. Process-centric modeling is a medium-low abstraction level modeling approach. Although each object is modeled individually as an entity, typically the modeler ignores many “physical level” details, such as exact geometry, accelerations, and decelerations. Process-centric modeling is used widely in the manufacturing, logistics, and healthcare fields.

 

Discrete event modeling techniques should be used only when the system under analysis can naturally be described as a sequence of operations. It is not always clear for any given modeling project which of the three modeling paradigms is best. For example, if it is easier to describe the behavior of each individual entity than trying to put together a global workflow, agent based modeling may be the way to go. Similarly, if you are interested in aggregates and not in individual unit interaction, system dynamics may be applied. Our logic tool solution supports all three modeling approaches, so you can experiment with the abstraction levels and modeling approach without needing multiple tools.

 

SD Modeling

supports the design and simulation of feedback structures (stock and flow diagrams and decision rules, including array variables AKA “subscripts”) in a way most SD modelers are used to.
 

You can:

  • Define stock and flow variables one by one or using a “flow tool”

  • Use automatic “code completion” in formulas

  • Define “shadow” variables for better readability of your model

  • Use table functions (look up tables) with step, linear, or spline interpolation

  • Define dimensions of both enumeration and range types

  • Define sub-dimensions and sub-ranges

  • Define array variables with an arbitrary number of dimensions

  • Use multiple formulas for different parts of an array variable

  • Use both SD-specific and standard Java mathematical functions

For more information...

bottom of page