ORMSware entities

Discussion of entities in this chapter lingers at the abstract level a little longer than desirable, so be forewarned that a little patience will be required to get through this chapter. However, we have tried to relate concepts to specifics in our example model at the earliest opportunity.

You have probably noticed by now that we have used ORMSware, NMOD, and ORMSware NMOD as if they all mean the same thing. You must have also read elsewhere at this site that NMOD is just one of the components of ORMSware Suite; that it is in fact a limited version of ORMSware Suite's discrete event simulator component.

The reason why we use ORMSware, NMOD and ORMSware NMOD interchangeably is that the basic entities and network objects used in ORMSware Suite are common to all of its components. The crux of ORMSware is the traversal of ORMSware entities through ORMSware networks in some fashion.

Using this analogy, NMOD employs two types of entities to get the job done. They are Surrogate entities and Customer Token entities. Customer Tokens are often referred to as just Tokens. Click Figure 8 to see the nature (i.e. some of the properties) of these entities and how the entities are related to each other and to the Customer.

When we were discussing in the previous chapter how ORMSware weaves calculation/execution threads through a model network, we were actually describing how NMOD uses tokens and surrogates to execute computations specified in a model's logical network(s).

When NMOD starts execution of a model, it goes through the following initialization steps related to Customer, Customer Token and Surrogate entities:

• Creates a default Customer with numerical ID of zero.
  
  
• Creates a default Customer Token entity with a numerical token ID of zero and assigns/relates it to the default Customer ID of zero. Since a token, in essence, carries all information about a customer, we often refer to tokens as customers. It will be clear from the context as to what exactly we are referring to.
  
  
• Creates a surrogate entity that is used for certain housekeeping functions and assigns/relates it to the default Token.
  
  
• Creates another surrogate entity, assigns it to the default Token and sends it to the Start node of the top network in the model. This is the start of the calculation/execution thread.

Which of the services in a model's network(s) will be evoked, in what sequence, and what they will do depends on specific logic/instructions the analyst adds to default instruction content of each object. The content of each network object consists of instructions in terms of network object properties and/or Customer and Surrogate properties inserted by the analyst, as well as default instructions automatically executed for each object by NMOD. You will see the logic inserted by the analyst for our widget Cost per Piece problem shortly.

Some models will require only the default customer (0) and its surrogates to evoke all relevant sets of instructions. Others will require introduction of additional customers to complete all required computations as we explained briefly in Chapter 5 during a quick introduction of Arrival nodes while discussing how to build a CostPerPiece curve. The analyst instructs NMOD to create new customers by setting the Type property of a node to Arrival.

Instructions in a Network object are evoked when a surrogate, representing a customer, enters that object.

The question as to why we need surrogates instead of simply creating copies of Token entities still remains. We would like to stay on the current train of thought for a little longer before completing the answer to that question.

To see the how the Nwk.ObjID-map-seq property can have different values simultaneously as a customer traverses a network, let us explore further the model depicted in Figure 9 window.

When the model starts running, Customer 0 with a Token ID of 0 starts at n[6]. Upon finishing n[6], it has to travel along a[11], a[12], and a[13]. These traversals take place simultaneously. This means that customer's Nwk.ObjID-map-seq property simultaneously has three different values, which happen to be arc sequence values 5, 6 and 7 in this model (see Nwk.ObjID-map-seq values in the blow-up boxes showing properties of the three surrogates).

Since NMOD uses surrogates to traverse networks for the customers they represent, any given Customer property having multiple values simultaneously in different parts of a model is easily handled. In our current example, when n[6]Initializations is finished, ORMSware creates 3 surrogates, sets all of their Token ID property to 0 and their Nwk.ObjID-map-seq property to 5, 6 and 7 respectively, and sends them along a[11], a[13], and a[12] as shown in the illustration.

In most problems there are certain customer properties that will have the same values no matter how many different objects in the model's networks are involved in serving a given customer at any given instant. If we were to use copies of the customer's token instead of surrogates to handle multiple threads, we will be duplicating these same property values in all copies of that customer's token; when such a property value of a customer changes, we would have to go to some trouble to ensure that the new value is propagated through all copies of that customer's token.

For example, the Convergences vector property of a customer will have the same vector value at any given instant, regardless of how many different network objects are involved in serving that customer at that instant. Since the vector will have the same values, we should not have to deal with the issue of updating the vector in all copies of a customer token. Similar situations often arise in customer properties defined by the analyst (user-defined Token properties), too.

Surrogates make it possible for us to "normalize" data tables containing property values of customers, enabling us to update in just one place core customer properties applicable at many other places in the network. This must have been obvious from the entity relationship diagram in Figure 8 window.

Now that we have discussed network traversal in terms of surrogates, you can expect to see "surrogates" instead of "threads" during network traversal discussions from this point on.

Referring to entity relationship diagram in Figure 8 window, you will see that both entity types have a property called Name. The value of the Name property is automatically assigned to entities by NMOD. You can see examples of Name property values in the Figure 9 window.

Since Token 0 (bottom left in Figure 9 window) represents Customer 0, NMOD has named it T0-C0. Since Surrogate 4 (top left) represents Token 0, NMOD has named it S4-T0-C0.

If the Surrogate ID were 523, Token ID were 104 and Customer ID were 12796, the name of the token would be T104-C12796 and the name of the surrogate would be S523-T104-C12796.

The primary purpose of entity name property is communication. Analysts use it to debug models and track model execution. It is an invaluable device, helpful to all stakeholders during model validation and verification.

Now that we have explained customer and surrogate entities, there are two customer token properties worth discussing at this point. They are Surrogate Count and Convergence properties of tokens. Knowledge of Convergence properties will especially be helpful in the next chapter.

Whenever NMOD assigns a surrogate to a token, it increments the Surrogate count property of that token by 1. This is a read-only property to the user. It is used internally by NMOD to ensure that potential memory leak condition is not overlooked in case there are stray surrogates still assigned to a token when that token is taken out of circulation. How tokens get used will be discussed in the next chapter (Arrival and Departure nodes). 

Our example problem currently has two Convergence nodes, viz., n[3] and n[5]. These nodes are automatically identified as convergence nodes by NMOD, since they both have at least one AND (-->>|) arc terminating in them.

Since two convergence nodes are detected by NMOD, it attaches a vector property, with two elements, to each token. For any given token, this vector is used to track how many surrogates representing that token have arrived along AND arcs at each Convergence node in the model. This is a read-only property to the user.