SignalTargets/temporal arcs property of network objects
This is a special procedure property of nodes and arcs. This property allows the analyst to create a temporal connection from a node or arc to another node or arc. These connections will be invisible in network diagrams. As such, they should be used carefully. Because they will not be visible in network diagrams, stakeholders other than the analysts may not be able to help much in ensuring the validity of models unless they get involved beneath the visible exterior of models.
|
|
Compare Figure 13 (do not click) at left to Figure
12 in Chapter 13. Figure 13 is Figure 12 minus all of the Support
arcs. Since some of the stakeholders may only be interested in topical view of
models, analysts may want to use
temporal connections to hide from other stakeholders some of the details in networks (such as
the Support arcs in Figure 12). If our
current example problem were real, we may only want to show the factors
that contribute to CostPerPiece and their relationships, and hide everything related to curve
building. As you can see at left in the mini-diagram of the
new version, it looks more like Figure 1, the diagram with which we started this
primer. Close Chapter 13 window you may have opened by clicking the link above earlier, as well as Figure 12 (Figure12NMOD.TXT) window if it is open. Click Figure 13 at left to open a separate window to view a new version of our example model. |
|
Figure 13 |
| Note: When an object contains temporal arcs, and they are expressed in its SignalTarget property, NMOD's Visio interface automatically shows a ^ in the object's display (see end of the top line of n{[2],[5] and [6]} and a[12]). In fact, Visio interface displays a ^ if any logic is contained in the SignalTarget property of an object. |
| Caution: NMOD offers analysts the flexibility to insert temporal
connection instruction in any property of an object, but we strongly
recommend that you confine Signal instructions to SignalTarget property of
objects. Temporal connection to a target object is established when NMOD
encounters a Signal anywhere in a given object.
If you put a Signal in a Duration property or Branch property or any other property, NMOD will execute that temporal connection when it encounters that Signal instruction. There is no provision in NMOD's Visio interface to indicate the presence of Signals in network diagrams, except indirectly as described in the note above. ORMSware philosophy is to provide an infrastructure for rapid modeling without tying users' hands. The downside of that, of course, is that it also provides analysts with the opportunity to get into trouble if due care/precaution is not taken while deviating from proposed NMOD modeling practices. |
Click here if Figure 11a (PrimerVSD) window is not open. Click here if Figure 11b (Figure12NMOD.TXT) window is not open.
As mentioned earlier, we have deleted all of the Support arcs in the model and replaced them with temporal arcs in the nodes where they originated. We have also changed the Branch property on a[8] to Always. We will explain why shortly, again as a device for discussing "how to model it with NMOD."
Click here to open the NET file (PrimerSig.NET) for the current version of the model. Scan down to the code block for Object 5. Below the Trans property block is a block for the object's SignalTarget property. It should contain the logic that existed on a[15] in previous version (plus a few more lines of code we have added to store and retrieve curve points, explained later).
Switch to Figure 11b (PrimerNET.TXT) window for previous version. Compare the line mentioned above in n[5] of current version (Figure 13/PrimerSigNET.TXT window) to the first line in Branch property block of Object 15 in previous version. The only difference is that we have replaced {nop.L}Branch in the Branch property of a[15] in the previous version with the logical variable logBranch in n[5]'s SignalTarget property. If the value of logBranch is True, we execute the same logic from the Trans property block of the old a[15] and then establish a temporal link to [2] (using the {Signal.2} statement).
| Note: You may have noticed that logBranch is declared as a logical variable at the top of the code block for [5]. We will discuss declaration of variables inside network objects in Chapter 17 (User-defined scalars, arrays, derived types and procedures). |
To find out more about replacement of other arcs in previous version with signals in current version, look at the code block (in current version) for nodes in which the replaced arcs originated. What we have done in [6] to replace a[11] and in [2] to replace a[13] are straightforward, but we have used a different approach in [2] to replace a[16].
As mentioned earlier, we have made the flow along a[8] from [2] to [3] unconditional. Recall that the purpose of the condition we had placed on it previously was to prevent it from executing when Customer ID is > 1, because there would be no matching flow from [1] to [3] along a[9] when Customer ID is > 1. Now that we have removed that condition, surrogates reaching [3] through [8] will be held up in [3]'s convergence queue unless we do something to satisfy each customer's AND count at [3].
There are several ways this can be accomplished, three of which are the following:
- CALL ChangeConvergenceRequirement to change convergence
requirement at [3] to 1 when the first customer executes [3]. We can
put this call in any property of [3]. Let us say we chose [3]'s Trans
property. Then we the following code should appear somewhere in the
Trans property block of [3].
IF (CustomerID() == 1) CALL ChangeConvergenceRequirement ( {Object.3},1 ) The interface for the above subroutine wil be listed in Appendix A along with other NMOD procedures available to the user, but we will also list it here for a preview:
SUBROUTINE ChangeConvergenceRequirement(regObj,regAndTerm,regPage)
INTEGER(reg),INTENT(IN):: regObj,regAndTerm !Node obj number and new convergence reqmt
INTEGER(reg),OPTIONAL,INTENT(IN):: regPage !Page on which subject node is located
- Send a Signal from [2] to a[8] when Customer ID > 1. To do this,
we would add an ELSE section in [2]'s existing SignalTarget property
code:
+{SignalTarget}
IF(CustomerID() <= 1)THEN
{Signal.1} !Have to get WearParameters the first time around
ELSE
{Signal.8} !To satisfy convergence requirement at [3]
ENDIF
-{SignalTarget} -
Send a Signal from a[8] to a[9] when Customer ID > 1. This is the
logic you see implemented (Figure 13/PrimerSigNET.TXT window) in the
current version of our model. We chose this approach, because it was a
good place to show how temporal arcs can originate as well as
terminate in arcs, which is somewhat of an odd concept. But, you will
find this to be a very powerful capability of NMOD. For conceptual
comfort, it may be useful to think of a connection from an arc to
another arc as divergence of a flow from a flow, to join another flow.
Close Figure 11a (PrimerVSD) and Figure 11b (PrimerNET.TXT) windows.
|
Execution of SignalTarget relative to other network object properties |
NMOD executes SignalTarget procedure property of a node when the node event is finished. Execution of Branch properties of all successor arcs of the node and dispatching surrogates along them as required are performed after signals are dispatched.
In the case of arcs, NMOD executes SignalTarget procedure properties when arc events are finished. Checking of anything concerning their terminating nodes (such as AND conditions) are performed only after signals are dispatched.
| Note: The analyst can actually insert a signal dispatch in any property. If signal dispatch is inserted in any property other than a SignalTarget property, the dispatch will take place when NMOD executes that property. |
A signal surrogate inherits all of the properties of the surrogate that triggers that signal at the moment the signal surrogate is created.
|
Execution of signal target objects |
When a signal arrives at an arc (i.e. a surrogate arrives at an arc via a temporal arc), NMOD initiates execution of the target arc immediately and unconditionally. Therefore, checking of Branch conditions for execution of the target arc must be performed in the temporal arc's originating network object to decide whether to dispatch the signal. You have already seen how this is done in n[5] of the current version of our model.
When a signal arrives at a node (i.e. a surrogate arrives at a node via a temporal arc), NMOD initiates execution of that node immediately without checking for any convergence conditions even if it is a Convergence node. In other words, a temporal arc to a node behaves very much like an OR arc.
|
Signal Duration property |
Duration of a temporal arc (i.e. signal traversal time) is 0 by default. However, the analyst can delay the arrival of the signal at its target by changing the value of the system variable $D.SignalDuration to desired delay prior to a Signal statement. As you can see, it is a real/floating point expression of the dbl KIND,
$D.SignalDuration = dblExpr
where dblExpr may be any constant, variable, function or a combination of all three yielding a scalar number. If dblExpr is not of dbl KIND, its value will automatically be converted to dbl while being assigned to $D.SignalDuration.
Value of system property $D.SignalDuration is reset to 0 by NMOD right after a signal is dispatched with appropriate signal Duration. If we want to send another signal with the same duration, we have to assign that value to $D.SignalDuration again before sending that next signal. In other words, anytime a signal duration is > 0, $D.SignalDuration should be set to appropriate value prior to the Signal statement.
| Note: We will go through a feedback file a little later to illustrate further how signals are used and how they get executed. |