Converting a Conceptual Model to a Simulation Model

The conceptual model is the result of the data-gathering effort and is a formula-tion in one’s mind (supplemented with notes and diagrams) of how a particular system operates. Building a simulation model requires that this conceptual model be converted to a simulation model. Making this translation requires two impor- tant transitions in one’s thinking. First, the modeler must be able to think of the system in terms of the modeling paradigm supported by the particular modeling software that is being used. Second, the different possible ways to model the sys- tem should be evaluated to determine the most efficient yet effective way to rep- resent the system.

7.2.1 Modeling Paradigms

A simulation model is a computer representation of how elements in a particular system behave and interact. The internal representation of a system may not be radically different between simulation products. However, the way that model in- formation is defined using a particular product may be quite different. How a user

defines a model using a particular simulation product is based on the modeling paradigm of the product. A modeling paradigm consists of the constructs and associated language that dictate how the modeler should think about the system being modeled. In this regard, a modeling paradigm determines the particular

“world view” that one should have when modeling a system. Learning a simula-tion product requires that one first learn the particular modeling paradigm used by the product.

Modeling paradigms differ among simulation products—although many dif-ferences are minor. Historically, simulation products required models to be de-fined line by line, specifying a list of instructions like a script for processing enti- ties. Most modern products have a process orientation and support object-based modeling. Some products view a process as an activity sequence, while others view it from the standpoint of an entity routing.

Conceptually, object-based modeling is quite simple. An object represents a real-world object such as a machine, an operator, a process part, or a customer.

An object is defined in terms of attributes and behaviors. Attributes are essentially variables that are associated with an object such as its size, condition, time in the system, and so on. Attributes are used to carry information about the object, either for decision making or for output reporting. Attributes may be modified during the simulation to reflect changing values. Behaviors define the operational logic as- sociated with the object. This logic gets executed either whenever certain events occur or when explicitly called in the model.

Examples of behavioral logic in- clude operations, machine setup, routing decisions, and material movement. Examples of events or conditions that may trigger a behavior might be the com- pletion of an operation, the elapse of a specified period of time, or the drop of a tank or inventory to a specified level.

Objects are organized into classes according to similarity of attributes and be- havior. In this way, all objects of the same class inherit the attributes and behav- iors defined for the class. This simplifies object definitions and allows changes to be quickly made to a set of similar objects. It also allows objects that are defined once to be reused in other models. In ProModel, predefined object classes include entities, resources, locations, and paths.

While object-based modeling is consistent with modern object-oriented pro-gramming (OOP) practices, OOP itself is quite complicated and requires a signif- icant amount of training to become proficient. The easiest simulation languages are object-based, but they are not pure OOP languages. Otherwise, a modeler might as well pick up an OOP language like Java and begin programming his or her models.

ProModel is object-based but also provides an intuitive entity-flow modeling paradigm. The natural way to think about most systems being modeled is to think of them from the perspective of the entity as it flows through each workstation, storage area, or some other location. In fact, it actually helps when building the model to put yourself in the place of the entity flowing through the system and de- scribe what you do and what resources you require as you move from place to place in the system. For modeling purposes, it is useful to think of a system in

terms of the same structural and operational elements that were described in Chapter 6. This is essentially how models are defined using ProModel.

7.2.2 Model Definition

A model is a simplified representation of reality, with emphasis on the word sim- plified. This means that the exact way in which an operation is performed is not so important as the way in which the operation impacts the rest of the system. An ac- tivity should always be viewed in terms of its effect on other system elements rather than in terms of the detailed way in which it is performed. Such detailed mechanics are inconsequential to the overall flow of entities and utilization of resources.

Most models, especially those built by beginners, tend to err on the side of being overly detailed rather than being too general. The tendency is to reproduce the precise way that the system operates (sometimes referred to as emulation).

Not only is it difficult to create extremely detailed models, but it is also difficult to debug and maintain them. Furthermore, all of the detail may obscure the key is- sues being analyzed so that it actually weakens the model.

The power of a model is more a function of its simplicity rather than its complexity. A point can be made more effectively when it is reduced to its simplest form rather than disguised in a morass of detail. Lou Keller of PROMODEL Corporation has suggested that the Laffer curve, borrowed from economics, effectively illustrates the relationship be- tween model complexity and model utility (see Figure 7.1). Notice that a certain degree of complexity is essential to capture the key cause-and-effect relationships in the system.

However, a system has many more cause-and-effect relationships than should be included in a model. There is an optimum amount of complexity for any given model beyond which additional utility begins to diminish.

The remaining sections in this chapter give recommendations on how to ef-fectively yet minimally represent system elements in a simulation model using a simulation language like ProModel.

FIGURE 7.1 Relationship between model complexity and model utility (also known as the Laffer curve).

Optimum level of model complexity

Utility

Complexity