Chapter 3 Process Domain

Transcription

1 Chapter 3 Process Domain 173-Prdef

2 174-Prdef Modeling Concepts

3 Modeling Concepts Introduction Prdef.1 Introduction Process models are used to specify the behavior of processor and queue modules which exist in the Node Domain. OPNET process models can be used to implement a wide variety of hardware and software subsystems, including communication protocols, algorithms, shared resources such as disks or memory, operating systems, queuing disciplines, specialized traffic generators, custom statistic collectors, and so on. This chapter is divided into two major sections. The first section, Prdef.2 Process Model Operation, defines the process modeling constructs provided by OPNET and describes their features and applications. The second section, Prdef.3 Process Model Development Methodology, presents a generally-applicable modeling methodology that guides you through the steps of creating a process model. Prdef.2 Process Model Operation OPNET node objects are used to represent devices that can be connected together to form networks. Devices may range from simple traffic sources to complex switches or computers running multiple applications. Nodes are created as instances of node models, meaning that a node model is the blueprint for all of the individual nodes of a particular type. Node models are defined as a collection of modules representing distinct functional areas of the node. Certain modules are limited in the types of behavior they can represent: generators are simple traffic sources provided for convenience; and the various transmitters and receivers represent interfaces to links defined in the network domain. Two types of modules, called processors and queues, support fully general behavioral modeling. Process Domain These modules offer essentially the same capabilities with regard to their general behavior and most of their physical resources. However, queue modules provide special support for organized packet storage by allowing users to define internal subqueues in which packets can be inserted and sorted, and from which packets can be extracted according to a general, user-defined method. For the purposes of most of the material in this chapter, queues and processors can be treated identically since they rely on the same process modeling technology to represent their behavior. Therefore, in order to simplify general discussion, the term QP will be used to represent these modules. Prdef.2.1 Process Environment Individual processes or groups of processes are defined to implement a particular task when placed within a QP. A process is an instance of a process model defined with the Process Editor. In other words, each process model may be assigned to many QPs within a single system. All individual process instances are defined to have similar characteristics but may operate in different environments. Process models perform one of two functions, depending on the QP. A process model typically represents a behavioral model of a process, as explained below. 175-Prdef

4 Process Model Operation Modeling Concepts This section describes in general terms the context in which processes perform their functions. Prdef Interrupt-Driven Execution Like all other subsystems in OPNET models, processes are driven by events. When an event is actually delivered to a process, it is termed an interrupt, as defined in the Modeling Framework chapter of this manual; the process is said to be interrupted which means that it is invoked to allow it to take some action in response to the interrupt. The reasons for which a process may be interrupted vary widely from process to process, and most processes themselves expect several types of interrupts signifying different conditions to which they must respond. Therefore, one of the first actions that is generally taken by a process upon being interrupted is to determine what type of interrupt has occurred. Subsequently, more detailed attributes of the interrupt might also need to be analyzed. Depending on the interrupt type, these attributes might be the input stream or statistic, the esys port that has a new value, the source module that caused the interrupt, or possibly application-specific information contained in an Interface Control Information (ICI). The Modeling Framework chapter presents a detailed discussion of interrupt processing. A process follows an alternating cycle of invocation and rest periods. Invocations may occur on an arbitrary basis depending on the timing of externally and internally generated events. A process always begins the simulation in a resting mode, waiting to be invoked; a process that is waiting in this conditions is said to be blocked. Invocation allows a process to resume execution and to perform new actions. Once these actions are completed, the process must again block, returning control to the Simulation Kernel so that other events in the system may be executed. Because these subsequent events may be scheduled for arbitrarily near future times, and even for the same time as the current event itself, the invocation must occur without allowing any time to elapse. In other words, the simulation time observed (e.g. by calling the KP op_sim_time()) at the start and at the end of an event, must always be identical. Note that this requirement does not imply that processes cannot model actions that consume time; only that modeling such actions can sometimes require multiple events. The requirement for zerodelay execution of events and techniques for delay modeling are explained in detail in the Modeling Framework chapter. The following diagram depicts the alternating sequence of blocking, invocation, activity, and back to blocking. 176-Prdef

5 Modeling Concepts Process Model Operation Process Blocking/Activity Cycle Interrupt causes invocation of process at time T Blocked Active Process performs actions when invoked Process becomes blocked again; time is still T Prdef Dynamic Processes At the moment when a simulation begins, each QP hosts only one process that is automatically created by the Simulation Kernel. This process, termed the root process, is an instance of the process model designated in the QPs process model attribute. The root process model can be designed to manage even very complex sets of tasks, and so depending on the application, the root process may be sufficient to provide the QP module with its intended functionality. However, in many modeling situations, it is possible to take advantage of the capability of a QP to host multiple processes in order to improve the modularity and reduce the complexity of a design. New processes become associated with a QP module when the processes that are already present within it request their creation via the KP op_pro_create(). A single QP may be the host to any number of processes that cooperate to implement its function within the surrounding node model. Processes that are created by other processes (as opposed to the root processes created by the Kernel) are referred to as dynamic processes. There are two principal cases in which a QP generally makes use of dynamic processes: Process Domain 1) At least part of the QPs functionality requires it to manage tasks that are generated on a dynamic basis (i.e., their exact timing or number are not known in advance). In such cases, a new process can be generated to correspond to each task as it arises. The process can then be destroyed when the task is complete. Because there is no upper limit on the number of processes allowed in a QP, any number of concurrent tasks can be handled in this manner. A typical example of this of application of dynamic processes is the implementation of a circuit-oriented protocol such as X.25, where new circuits are opened and closed based on incoming requests whose patterns are unpredictable. Each circuit can be managed by an independent OPNET process, and all circuits can flow through the same QP module, allowing a single module to represent the functionality of the protocol within the node. 177-Prdef

6 Process Model Operation Modeling Concepts Process Hierarchy 2) The activities of the QP are conveniently represented as multiple asynchronously running processes. The required processes may all be created when the QP configures in the beginning of the simulation and may remain the same throughout the simulation afterwards, each process implementing a subset of the overall QPs functionality and perhaps cooperating with other processes to support their activities as well. Generally this approach is used when a QP is required to manage several tasks in parallel, each of which is substantially independent of the others. Since dynamic processes are always created by other processes, the root process must be involved in originating them. The first generation dynamic processes (i.e., those generated by the root) may then in turn create new processes, which would be referred to as second generation. With respect to a process that creates it, a dynamic process is referred to as a child process; conversely, the creating process is referred to as the parent process. Since all processes have the capability to create others, the processes within a QP form a tree structure with the branches representing parent-to-child relationships. The root process is the ultimate grandparent of all processes. The following diagram illustrates the concept of a QPs process hierarchy: Typical Process Hierarchy within a QP Root Process Number of Generations is not limited First Generation Child Processes Second Generation Child Processes Third Generation Child Processes number of processes may scale dynamically as demand requires Since processes can be destroyed as well as created, the process hierarchy may shrink as well as grow. In addition, there is no requirement that a process children must all be destroyed before it can itself be destroyed; thus holes may appear at certain levels within in the process hierarchy, corresponding to the fact that certain processes have no active parent processes. Note however that the root process 178-Prdef

7 Modeling Concepts Process Model Operation plays a special role in handling interrupts for each QP, and that it is the only process that may not be destroyed. The role of the root process is addressed in a subsequent section on interrupt steering. Note that a process is capable of creating child processes of any type (i.e., based on any process model), including its own or the type of its parents; however, a complete list of child process models that it intends to instantiate must be declared prior to simulation as part of the process model definition. Attempting to create a process based on a process model that is not declared may result in an error during simulation. The Process Editor provides an operation called Declare Child Process Models that supports menu-based editing of the potential child process list. Refer to the System Menus chapter of the Editor Reference manual for more information on this operation. Promoted attributes of a child process are promoted along with those of the parent process, and therefore appear in the attribute lists of queues and processors at the node level. The child process s attributes are prefixed with the name of the process model in order to differentiate them from other similarly-named attributes. Shared Memory Architecture When a QP relies on multiple processes to implement its functionality, these processes often require some form of communication between them in order to cooperate in managing the QPs tasks. The Simulation Kernel therefore provides three communication mechanisms that allow multiple processes to share information. These mechanisms may be used individually or combined. QP-level shared memory: This form of memory, also referred to as module memory, allows all process in a QPs process hierarchy to communicate information to each other by placing this information in a common area. Each QP maintains a single memory address that processes can assign or obtain by calling the Kernel Procedures op_pro_modmem_install() and op_pro_modmem_access(). Process Domain The various processes that use this mechanism must agree on the format of the data that is pointed to by the shared memory pointer. In general this is done by defining a data structure that can be referenced by all processes. To make certain that all processes use a consistent form of the data structure, even when it is changed, the definition should be kept in an external definition file that is included in each process header block; in the C language, definitions files are named with a.h suffix. 179-Prdef

8 Process Model Operation Modeling Concepts Coordination of QP-Level Shared Memory Any of the processes in a QP, regardless of type, may communicate via a single shared memory area. QP Processes set/get the shared memory area s address via the KPs op_pro_modmem_install(), op_pro_modmem_access(). shared memory Shared memory block is organized according to structure definition in external definitions file. QP process hierarchy Process models that use shared QP-level memory reference common structure definition via #include statement in their header block. /* sharedmem.h */ typedef struct { int n; double x; char s [16]; } shared_mem; definitions file Initially, the Simulation Kernel provides no shared memory for a QP (the Kernel Procedure op_pro_modmem_access() returns a NIL value to indicate that this is the case); it is up to the processes within the QP to decide how much memory is necessary and when it should become available. The processes are therefore responsible for allocating the block of shared memory, after which it can be installed by calling op_pro_modmem_install(). Memory allocation is generally performed by calling op_prg_mem_alloc(). It is possible for a shared memory block that has been installed to be replaced by another. The KP that supports installation simply allows a new memory address to take the place of the existing one, without protecting against loss of the data that was previously installed. Therefore process architectures that perform multiple installations are responsible for any required memory deallocation. 180-Prdef

9 Modeling Concepts Process Model Operation In practice, a shared memory block is usually installed only once and this installation is performed by the root process when it is invoked for the first time. This allows other processes in the hierarchy to simply assume that the memory is available. Once QP-level shared memory has been installed, processes may communicate information to each other by writing data into the common memory space. This is generally done by assigning values to the members of the installed data structure. Other processes then examine the contents of the data structure and make use of this information as required. Communication between the processes using module memory can be on an active basis or on a passive basis. Active communication involves modifying the shared memory contents and then invoking the process that is to receive the new information (invocations between processes are performed with the KP op_pro_invoke()). Passive communication simply involves modifying the shared memory contents, but relies on the destination process to autonomously examine the shared memory, perhaps at a later simulation time. Parent-to-child shared memory: in many cases, the communication that must take place within a QPs process hierarchy is between processes and their parents. This is due to the fact that child processes are often created to handle parts of a parent process work and that results must be reported back to the parent. The Simulation Kernel provides specific support for this type of communication by allowing a private shared memory area to be set up at the time that a child process is created. Other processes do not have access to the memory, although they may reserve their own parent-to-child memory. The Kernel maintains an independent shared memory block for each parent-child pair in the system. Process Domain Parent-to-Child Shared Memory Organization Root Process The memory address NIL is installed when parent-child shared memory is not used NIL Each parent-child pair can establish an independent block of memory for twoway communication As is the case with all inter-process memory mechanisms, parent-tochild memory is optional and may exist only between certain parent- 181-Prdef

10 Process Model Operation Modeling Concepts child pairs. Unlike QP-level shared memory, however, parent-to-child memory may only be installed once for each parent-child pair, when the child process is created with the Kernel Procedure op_pro_create(). Replacement of the memory block is not possible, although it may be deallocated when it is no longer necessary. A process may obtain the address of the memory that it shares with its parent process by calling the KP op_pro_parmem_access(). However, since a parent process may have many child processes, and since it must supply the addresses of parent-child shared memory, it is responsible for keeping its own records of such addresses (e.g., by storing them in state variables). In general, parent-to-child shared memory is allocated by calling the KP op_prg_mem_alloc(). The format of the shared memory is transparent to the Simulation Kernel, which only manages the memory block s address. However, as in the case of QP-level shared memory, the parent and child processes must agree on the memory format and this is usually accomplished by referencing a common definition of a C or C++ data-structure to allocate and access the shared memory. Once the shared memory block is established (i.e., when the child process is created), both the parent and the child may communicate information with each other by modifying and/or examining the memory contents. If applicable, they may choose to actively invoke each other to provide notification of changes to the shared memory area by calling the Kernel Procedure op_pro_invoke(). Argument memory: communication between processes is often required at the time that one process transfers control to another by invoking it with the Kernel Procedure op_pro_invoke(). In order to support this type of information passing, op_pro_invoke() accepts a general memory address as an argument and makes this address available to the invoked process. As with the other two memory mechanisms, the memory address points to a block of memory whose format is user-defined and the two processes must be designed to agree on how its contents are organized. The invoked process obtains the memory address by calling the KP op_pro_argmem_access(). It may then use the memory to obtain parameters that affect its behavior, and/or modify the memory to return status information to the process that invoked it. Note that unlike the other two memory mechanisms, argument memory is not persistent. This means that each new invocation of a process requires that an argument memory address be passed again, even if it is the same as the address supplied for a previous invocation between the same two processes. Each of the mechanisms described above supports communication of information via an abstract data object in the sense that the Simulation Kernel does have knowledge of the structure or contents of the shared information. The 182-Prdef

11 Modeling Concepts Process Model Operation memory address is manipulated as a general pointer and the process logic is required to cast or coerce the type of the pointer so that it becomes a pointer to an appropriate data structure, as agreed upon by the various communicating processes. Also note that each memory mechanism supports two-way communication of information since all processes that have access to a memory block may both insert and extract information from it. For further information on process shared memory mechanisms, refer to the Process Package chapter of the Simulation Kernel manuals. Operations on Dynamic Processes All interactions between dynamic processes are performed via the Kernel Procedures (KPs) of the Process package. In addition, several KPs in the Interrupt package provide capabilities that indirectly affect the operation of processes. Complete information on these procedures is presented in the appropriate chapters of the Simulation Kernel manual. The general capabilities provided by these KPs and related process model design issues are reviewed in this section. As mentioned earlier, only one process initially exists in each QP, and this is the root process specified in the QPs process model attribute. Additional processes may be spawned when the root process (and subsequently other processes) calls the KP op_pro_create(). When a process model is created, it is implicitly incorporated into the process hierarchy of the process that created it. There is no way to create a process in another QP than that of the current process. In order to create a child process, its process model should be declared in the specification of at least one of the existing processes. Declaration is performed via the declare child process models operation in the Process Editor. While it is sufficient for the created process model to be declared in the models of any of the QPs processes, it is generally a good practice of modular design to declare as part of each process model, the names of all the processes that it is capable of creating. In this manner each process is responsible only for declaring the process that it directly creates, and new process models can always be included in a process hierarchy without concern for their own potential use of dynamic process creation. Process Domain When a process is created, a special data item called a process handle is returned by op_pro_create(). The data type used to declare a process handle variable is Prohandle. Process handles uniquely identify a process, not only within a process hierarchy, but within the entire modeled system (i.e., across all QPs). Process handles are required by most KPs in the Process package and so they are commonly used by models that employ dynamic processes. Generally, a process uses process handles declared as state variables to retain access to the process handles that it obtains when it creates child processes. This allows it to later perform fundamental operations on its children, such as invocation or destruction. Process handles may also be obtained by several other KPs including op_pro_self(), op_pro_parent(), and op_pro_root(). Two other forms of process identification are provided, but neither is necessary to use the Kernel Procedures that affect processes. Process IDs are unique integer 183-Prdef

12 Process Model Operation Modeling Concepts numbers that are automatically assigned to processes when they are created. A process ID may never be changed, nor can it recur within the same simulation. Process IDs are used to represent processes in informative output issued by the OPNET debugger (ODB) or by user-developed reporting statements. A process ID may be obtained by calling the KP op_pro_id(). A process tag is a user-supplied string that may be assigned to a process at any time. The content of the string is transparent to the Simulation Kernel and is currently used only to identify processes or report special information about them as part of the output of the ODB command promap. Certain dynamic processes are created to manage activities whose time-spans are limited, and their usefulness therefore expires when such activities complete. To avoid buildup of inactive processes, all dynamic processes (e.g., all processes but the root) may be removed from their QPs process hierarchy by application of the KP op_pro_destroy(). This KP may be applied to other dynamic processes or by a dynamic process to itself when it has determined that is no longer needed. Note that process self-destruction in this manner should generally be the final action that a process attempts to perform, since use of op_pro_destroy() strips a process of several important resources, including its state memory. In many cases, it is important for a parent process to be aware of the destruction of one of its child processes. This allows the parent to keep its knowledge of its child processes up to date and to deallocate any memory related to its relationship with the child, including parent-to-child shared memory installed when the child was created. If the child process performs its own destruction, the parent may be informed by modification of a flag in the parent-to-child shared memory. The parent may then check the flag when the child returns from invocation (if the parent invoked it). Alternatively, a child process may request that its parent destroy it via similar arrangement based on a semaphore within the shared memory area. Regardless of the method by which a dynamic process is destroyed, the Simulation Kernel always provides it with an opportunity to perform a sequence of final actions. This is done by executing a special section of the process model, called the termination block, prior to deallocating the process state memory. Typically the termination block contains statements that deallocate dynamically allocated memory that is referenced within the process state variables. Other operations that may be performed at termination include recording of final values of collected statistics and notification of other processes that may be affected. The contents of the termination block are placed into a specially created function by the Proto-C compiler; therefore no functions should be defined within it, nor should local variables be declared. However, the statements within the termination block do have access to state and temporary variables. In addition, prior to invoking the termination block of a process, the process is made active as if invoked, so that KPs that are context-dependent such as op_id_self() or op_stat_write() may be called. 184-Prdef

13 Modeling Concepts Process Model Operation If the occurrence of an interrupt does not directly invoke the process that is responsible for its handling, or if the interrupt requires that several of a QPs processes take action, then process-to-process invocation is required. This mechanism is supported by the KP op_pro_invoke() and allows one process that currently controls the thread of execution to cause another process to temporarily take control. An invoking process is suspended until the invoked process releases control by blocking (i.e., the invoked process must enter an unforced state). Processes invoked by means of op_pro_invoke() may in turn use the KP themselves to invoke other processes. The dynamic of this mechanism therefore resembles that of function calls in stack-oriented languages such as C or C++. Note however, that process invocation does not support recursion; this means that a process that is suspended, due to having called op_pro_invoke(), may not itself be invoked again until it has resumed control of the thread of execution and subsequently blocked. Another way of viewing this is that op_pro_invoke() may only be applied to fully blocked processes. This limitation on recursion applies only to process instances and not to process models. In other words, it is possible for distinct instances of the same process model to invoke each other. During an invocation, the invoked process can access any of the resources in the QP, including, for example, packets or statistic values that were received to cause the interrupt of the invoking process. Note however, that if the invoking process has already consumed or modified such resources (e.g., removed a packet waiting in an input stream), they will no longer be available to the invoked process. In other words, the invoked process should be thought of as performing a task on behalf of the invoking process. It can therefore can be considered an integral part of the invoking process thread of execution, as if its actions were directly specified among the actions of the invoking process. Process Domain A distinction must be made between a parent process and an invoking process, although in many cases these may be the same. A process parent is the process that created it and each process may therefore have only one parent (except the root process, which has none). On the other hand, each process (including the root) may be invoked by any other process in the same process hierarchy, and different processes may even invoke it during the same event. Note also that the two types of relationships between processes support different information sharing mechanisms. A process and its parent share memory on a persistent basis with parent-to-child shared memory, whereas invocation supports a temporary form of shared memory to pass arguments (i.e., parameters) from invoking process to invoked process. Interrupt Steering When an interrupt occurs for a QP, the Simulation Kernel must make a decision concerning which process will first be invoked to handle it. For most interrupt types, the Kernel has no knowledge concerning the tasks required by an interrupt, and therefore its selection must be based on information supplied by the QPs processes themselves. Self and process interrupts are an exception to this rule since they are implicitly directed toward particular processes. For other interrupt 185-Prdef

14 Process Model Operation Modeling Concepts types, the Kernel therefore provides several KPs that allow processes to specify how the selection should be made. If none of these KPs are used by the processes of a QP, then the Kernel makes a default decision, which is to invoke the root process. The most general way to manage situations where interrupts must receive initial handling by different processes is to create a dispatcher process that decides which process to invoke. Typically, the dispatcher process would be the root process, since it receives interrupts by default. Part of (or possibly all of) the logic of the root process would be devoted to analyzing the attributes of an incoming interrupt in order to decide which of the QPs processes should be invoked to actually perform the handling of the interrupt. The advantage of this general approach is that arbitrarily complex decisions can be made based on any number of properties of the interrupt. For example, attributes that might factor into process selection include values of packet fields, origin of interrupt, port of arrival, time of arrival, and even state information accumulated while responding to previous interrupts. Using the Root Process as a Dispatcher Simulation Kernel The Kernel provides all interrupts to the root process (except for self, process, and procedure types). Process A /* Based on interrupt properties, invoke appropriate child */ /* process. Start with packet-stream arrivals */ if (op_intrpt_type()== OP_INTRPT_STRM) { /* Obtain the packet and use packet class to determine */ /* which process should handle it. */ pk = op_pk_get (); op_pk_nfd_get (pk, "class", &class); switch (class) { case PACKET_CLASS_A: op_pro_invoke (process_a_handle, pk); break; case PACKET_CLASS_B: op_pro_invoke (process_b_handle, pk); break; case PACKET_CLASS_C: op_pro_invoke (process_c_handle, pk); break; } Process B Process C The root process invokes the process that is appropriate based on its analysis of the interrupt; in this case the class field of the received packet determines which process should be invoked. Complex steering of interrupts is best handled by an interrupt-dispatching process as described above. However, KPs provided by the Simulation Kernel s Interrupt package provide convenient and efficient support that is sufficient for 186-Prdef

15 Modeling Concepts Process Model Operation certain simple situations. By using the provided mechanisms, any process may register itself or another process as the direct recipient of appropriate interrupts. Specifically, two KPs are provided to request that the Kernel automatically invoke a particular process based on the type of interrupt or based on the input on which an interrupt arrives. Steering based on interrupt type is supported by the KP op_intrpt_type_register(), and all interrupt types except for self, process, and procedure are supported. For stream and statistic interrupts, the KP op_intrpt_port_register() provides additional specificity with regard to the input stream or input statistic associated with the interrupt. When both mechanisms are used and are applicable, port registration has precedence over type registration. Automatic interrupt steering is discussed in detail in the Modeling Framework chapter of this manual. Prdef Local Process Resources OPNET processes always operate within the context of a QP. The QP object provides the processes that it contains with certain resources that are implicitly part of each process environment. These resources are described in this section. Input and Output Streams Packet streams are objects that exist in the Node Editor and are used to connect modules together. The packet streams support error-free transfer of packets between modules, and can also delay the arrival of the packet at the destination module. Packet streams connect to constructs in the source and destination modules which are called output and input streams respectively. Process Domain An input stream of a QP is capable of receiving packets from external sources. The packets are automatically queued within the input stream in first-in-first-out order and are provided to any process within the QP upon request. Input streams accept packets from two sources: packet stream objects and the remote delivery service provided by op_pk_deliver() and related Kernel Procedures. A QP may have any number of input streams that are physically attached to packet stream objects. In addition, input streams are dynamically allocated as necessary to support packet deliveries, since the Simulation Kernel has no prior knowledge of the range of input streams that will be delivered to or accessed. 187-Prdef

16 Process Model Operation Modeling Concepts Queue/Processor Input Streams node boundary Input streams contain internal FIFOs that can hold packets until they are extracted. 0 1 Queue or Processor Boundary 4 10 Additional streams may be automatically allocated to receive packets that are delivered to the QP. These may originate anywhere, including outside this node. Processes are responsible for collecting packets from the input streams. Multiple processes can access the same input stream. When packets are received on an input stream, one of the processes in the receiving QP is usually invoked with a stream interrupt. The process may determine which input stream received the new packet by calling the KP op_intrpt_strm(). Input streams are referenced using non-negative integer indices. Processes may obtain the earliest arriving packet that remains in an input stream of their QP by calling the Kernel Procedure op_pk_get() and referencing the appropriate input stream index. The KP op_strm_pksize() can be used to determine the number of packets still remaining in the input stream. The opposite side of a packet stream attaches to an output stream construct. Output streams support communication of packets via the Kernel Procedures op_pk_send(), op_pk_send_delayed(), op_pk_send_forced(), and op_pk_send_quiet(). Like input streams, output streams are referenced by nonnegative indices; however only output streams that are actually physically connected to outgoing packet stream objects in the node domain are valid. Output and input streams may also be referenced when the stream accessing mechanism is used. A QP can use stream accessing in order to signal to another QP that it should forward a packet on one of its output streams. Assuming that module S is the source of a packet stream and D is its destination, the sequence of operations is typically as follows: 188-Prdef

17 Modeling Concepts Process Model Operation 1) D calls the KP op_strm_access(), in order to request that S send a packet to it over the stream that connects them. When calling the KP, D specifies the index of the input stream on which it wishes to receive the packet. 2) As soon as D calls op_strm_access (), a forced interrupt is generated for S. This means that D s execution is temporarily suspended to allow S to respond (see the Framework chapter of this manual for more information on forced interrupts). The type of this interrupt is an access interrupt. S calls op_intrpt_strm() to determine on which output stream the packet is being requested. S then responds to the access interrupt by sending a packet on that output stream, if it so chooses. In order to send the packet, S must use op_pk_send_quiet() because it has to avoid causing an interrupt for D which is in a suspended state. Note that S could take other actions if desired, as well. S blocks in an unforced state. 3) D regains control immediately when S blocks and resumes execution immediately after the point where it called op_strm_access(). D checks its input stream to determine if one or more packets have arrived, typically using the KP op_strm_pksize(). If any packets are present, it may retrieve them from its input stream using the KP op_pk_get (). Input Statistics and Local Output Statistics Input statistics are constructs that are internal to QPs and that accept numeric values sent by other modules (not necessarily QPs) in the same node. Input statistics are generally used to monitor performance metrics or status signals generated by other modules. The values are conveyed by statistic wire objects that connect the source and destination module. A destination module s input statistic is capable of retaining only the last value that it receives (i.e., no buffering of values is provided). This latest value is always available to any process in the QP by calling the KP op_stat_local_read(). Process Domain Each QP has exactly 100 input statistics, each of which can be connected to any number of statistic wires.the input statistics are referenced by integer indices in the range 0 to 99. These indices correspond to the dest stat attribute of the statistic wire object in the Node Domain. When multiple statistic wires are connected to a single input statistic, the latest value of the most recently updated statistic is the one that is stored in the input statistic at any given time (note that a statistic may be updated without necessarily changing its value). Changes in the statistics associated with the statistic wires always result in statistic events for the destination module. Each event may then result in the generation of a statistic interrupt for one of the processes in the receiving QP, depending on the interrupt-generation criteria imposed by the statistic wire (see the Node Domain chapter of this manual for more information on the operation of statistic wires). Upon receiving a statistic interrupt, a process may determine 189-Prdef

18 Process Model Operation Modeling Concepts which of the QPs input statistics has received a new value by calling the KP op_intrpt_stat(). Local output statistics and input statistics form opposite ends of a statistic wire that connects to QPs. The Local qualifier is used to distinguish these output statistics from global statistics that can be shared by multiple QPs across the system model. Local output statistics provide the ability to report user-defined statistics that are private for each QP. A local statistic can be tapped by statistic probes to contribute to a simulation s output file, as well as by a statistic animation probe to generate an animated view of the statistic as it changes over the course of the simulation. Local statistics can also be connected via statistic wires to the input statistics of other QP modules in the same node, allowing values to be dynamically communicated to the destination modules as they are updated. Processes can update local output statistics by calling the KPs op_stat_write() or op_stat_write_t (). Each local output statistic can feed multiple statistic wires and probes in any combination. As the statistic s value is updated, each destination separately receives appropriate notification. Each QP can maintain any number of local output statistics. If multiple processes coexist within the QP, the output statistics are shared by all of these processes. In other words, any of the processes may update any of the output statistics, if needed. Processes must declare the local output statistics they intend to use; the Process Editor provides the edit local statistics operation for this purpose. This operation is fully documented in the Editor Reference manual. Each local output statistic may be dimensioned or undimensioned. An undimensioned statistic is simply an individual statistic, which is the most common case. A dimensioned statistic is actually an array of statistics, containing any predetermined number of individual statistics. The individual statistics are distinguished by their index and can be updated and used independently. Dimensioned statistics provides a more convenient way of handling a large number of similar statistics and are typically used in cases where a process manages a scalable number of entities, such as connections or neighbors. Often, in cases where child processes are used, each child process is responsible for updating one of the output statistics in an array of local output statistics. In order to gain access to a statistic in order to update it, a process must first obtain a corresponding statistic handle. The KP op_stat_reg() allows the process to obtain this handle, which it may then retain (usually as a state variable) for subsequent use. Refer to the Simulation Kernel manual for more information on op_stat_reg() and op_stat_write(). Global Statistics Local statistics are ideal for reporting activity that is private to a particular QP at a given location in the system model. However, in many cases, modelers are interested in obtaining quantitative information about the system as a whole. For example, in a network model, we may wish to measure the average end-to-end delay experienced by all packets transmitted between applications, regardless of 190-Prdef

19 Modeling Concepts Process Model Operation the particular source or destination. Another common statistic of interest is network throughput, which is a measure of the total amount of data the network delivers during a chosen time interval. Often, global statistics are simply averages of local output statistics across many components in the system model. It is common to collect both types of statistics in the same simulation. Global statistics can be used to feed values to two types of statistics collection probes: global statistic probes and statistic animation probes. Global statistic probes transfer statistic values to the simulation s output files, allowing them to be analyzed in the Analysis Tool after simulation. Statistic animation probes allow dynamic viewing of the statistic during simulation. Subqueues OPNET provides similar, but separate support for local and global statistics. As with local output statistics, each process model is expected to declare the global statistics that it expects to update during simulation. This is done using the Process Editor s edit global statistics operation which is fully documented in the Editor Reference manual. Global statistics are accessed via a statistic handle which is obtained via the KP op_stat_reg(). In order to obtain the handle, the name and group of the statistic is specified; if different processes elsewhere in the system model specify the same name and group when calling op_stat_reg(), then they will obtain the same statistic handle, providing a rendez-vous mechanism based on the statistic name. The separate processes may then use the handle when calling op_stat_write(); the values provided by all of the processes are merged into a single series of values in the simulation s output file, or in the statistic s animation. Refer to the Simulation Kernel manual for more information on working with global statistics. Process Domain Attributes Queue modules may be configured within the node domain to contain any number of subqueues that allow packets to be stored in an organized manner. All processes within a queue module have equal access to the subqueues and may insert and extract packets as required to implement a particular queuing policy. The Q and Subq packages of Kernel Procedures support processes that operate on subqueues. See the Simulation Kernel manual for detailed information on these Kernel Procedures. Also refer to the Node Domain Definitions chapter of this manual for a detailed explanation of how queues and subqueues are structured. Like all OPNET objects, QPs have a set of attributes that specify some of their fundamental characteristics. All processes within a QP may modify and obtain the values of these attributes by calling the KPs op_ima_obj_attr_set() and op_ima_obj_attr_get(), respectively. Built-in attributes are predefined and similar for every QP, though their values are assigned independently on a per-qp basis. Model attributes can be declared by the modeler in order to support modeling of application-specific object 191-Prdef

20 Process Model Operation Modeling Concepts characteristics. The Process Editor s edit model attributes operation is provided for this purpose (refer to the Editor Reference manual for more information on this operation). Model attributes are inherited by QPs from their assigned process models. This set of attributes is formed from the process model attributes of the root process as well as from those of its child process models. To avoid attribute naming conflicts between the various processes, attribute names are prefixed with the name of the process models that define them (except in the case of the root process). Model attributes have a scope that is local to each QP. That is, for each QP that uses a process model, private copies of the process model s attribute are created for the QP and appended to its attribute list. They appear together with the QPs built-in attributes and can be treated in an identical manner. Changes to the attribute in one QP have no effect on the same attributes in any other QP. OPNET also provides process models with a globally scoped attribute mechanism. These attributes, called simulation attributes, are declared by each process model that requires them. Unlike process model attributes, simulation attributes are read-only. Their purpose is to provide a parameterization mechanism at the system level, rather than at the level of system building blocks. In other words, if the designer of a process model wishes to create a parameter which is to be shared by many entities in the system model, it can declare a corresponding simulation attribute. If multiple process models declare the same simulation attribute (i.e., using identical names), OPNET will detect this and create only one attribute which is implicitly shared by all the process models. Simulation attribute values can be set at simulation run time to complete the specification of the system model. Different values may be specified for each new simulation, providing a mechanism for automatically iterating the system model through a series of experiments. Declaration of simulation attributes is performed using the edit simulation attributes operation, which is described in detail in the Editor Reference manual. When processes wish to obtain the value of a simulation attribute, they must call the KP op_ima_sim_attr_get() and refer to the attribute using the appropriate declared name. If the simulation attribute s value has not yet been specified as part of the simulation s environment attributes, then op_ima_sim_attr_get() will cause the Simulation Kernel to prompt for an assignment from the user. Since simulation attribute values do not change once a simulation starts, processes usually obtain these values once and store them in state variables if they need to use them again at a later time. Refer to the Simulation Kernel manual for more information. Since simulation attributes, and attributes in general, are essentially inputs to the system model and the simulation, they are often of interest to record as part of a simulation s output file. This allows the simulation inputs and output (i.e., recorded statistics) to be viewed together and dependences between them to be analyzed. OPNET provides a special probe, called an attribute probe, for this 192-Prdef

21 Modeling Concepts Process Model Operation purpose. Attribute probes record attribute values as scalar statistics. Refer to the Simulation Design chapter of this manual for more information on attribute probes. Prdef.2.2 Process Model Components Process models are specifications for the dynamic behavior of processes. To be complete, a process model must describe the actions that a process will implement under all circumstances that it will potentially encounter. In many cases, processes that are executing within OPNET simulations represent a real-world equivalent protocol or algorithm; the formal specification of such a protocol or algorithm is a higher-level specification that stipulates the requirements that must be met by a process implementation in order to be used in a standardized fashion. To differentiate such a specification from a model specification developed in OPNET, the formal specification will be referred to as a standard. In other words, a standard describes the requirements that apply to real world processes, and therefore also to the models of those processes. Some examples of standards are the IEEE 802 local area network protocol standards, or the RFC documents for the TCP/IP protocol suite. The academic description of an algorithm such as Bellman- Ford Routing would also be considered a standard according to this definition. In fact, any set of requirements that apply to the actions and interactions of a process can be called a standard for the implementations of that process. OPNET process models are developed to represent real-world existing or planned systems and therefore may at some level be considered to be implementations, or partial implementations, of the same standards as their realworld counterparts. Strictly speaking, processes that are representing existing and known real-world counterparts, are models of those implementations, rather than implementations of the standard. Thus, a good model of an existing real-world process should replicate any flaws that the real-world process has relative to the standard that it implements. This would allow it to predict behavior that results from the flaw. Process Domain In some cases, process models are developed to represent hypothetical processes that could occur in the real world. The modeler may be interested, for example in predicting the performance of a proposed protocol for which no realworld implementations may yet exist. In these cases, process models can themselves be considered to be implementations of the standard from which they are derived. Similarly, a process model may be developed to provide a generic implementation of a standard for use as a basic library component. Such a process would also be considered a direct implementation of a standard, since it is not patterned off of any existing real-world implementations. Most example models provided with OPNET that have to do with standards, such as X.25, Ethernet, ATM, TCP/IP, etc., fall into this category. Regardless of whether a process model strives to represent a real-world implementation or a standard, the actions that it is required to implement and the timing that underlies these actions may be quite complex and may vary significantly from application to application. Thus, if a single representation convention, or language, is used to define all such process models, it must be 193-Prdef

22 Process Model Operation Modeling Concepts extremely versatile. Currently OPNET supports one language for developing models of processes. This language, called Proto-C, is supported by the Process Editor which is integrated into the OPNET application. Proto-C provides a powerful and efficient method for describing the behavior of discrete event systems; it offers the following major features: Based on state transition diagrams (STDs): also referred to as finite state machines (FSMs). This is the prevailing description method for discrete-event systems that maintain state information (i.e., information accumulated over the past). It is used in specifying and developing a wide range of software and hardware systems because of its simplicity, its propensity for intuitive graphical representation, and its ability to effectively break down complexity. Combined graphical/textual representation: Proto-C process models depict state-transitions in a graphical format to support visualization of top-level control flow. However, because graphical representations generally do not efficiently or intuitively describe detailed actions or decision-making, Proto-C supports textual specifications of these aspects of a process. Textual specification occurs within the states and on the transitions of the diagram and is based on a powerful library of simulation and distributed-system related procedures, described in the Simulation Kernel manual. In addition, the full general computational capability of the C and C++ languages is retained by Proto-C in order to guarantee sufficient flexibility for all discrete-event applications. Ability to represent general state information: the state information of a process is the set of data that has been generated by or provided to the process, and that the process has decided to retain. Traditional statetransition diagrams represent the complete state of a system by identifying which of a limited set of states is occupied at any given time; this is impractical for systems with complex state, and insufficient for systems with dynamically expanding state. Proto-C therefore uses state occupancy representation only to represent high-level modes of a system, and provides a more powerful mechanism to describe general state information. Models may declare any amount of state information as variables whose datatypes are provided by OPNET, the C and C++ languages, or custom definitions. The state variables may be given general names and referenced symbolically throughout the process model. In addition, variables can be assigned to dynamically allocated memory in order to store state information that grows over time. Dynamic process creation: processes may be created dynamically to partition interrupt handling or to provide additional independent contexts as new tasks arise. 194-Prdef

23 Modeling Concepts Process Model Operation Efficient execution: Proto-C diagrams and the logic contained within are translated to the C and C++ languages with minimal overhead, allowing them to execute extremely efficiently. In particular, state information access, and control-flow statements (e.g., if statements with conditional clauses, and for loops that sequence through multiple operations) are implemented in a direct manner to avoid any loss of performance. Prdef State Transition Diagrams Proto-C models consist of two basic component types: states and transitions, hence the name state transition diagram (STD). States are generally used to represent the top-level modes that a process can enter. Transitions specify the changes in state that are possible for the process. STDs are graphically depicted in the Process Editor. There are other important aspects of Proto-C process models that are not represented graphically. These include actions associated with each state, variable and attribute declarations, and common definitions of expressions and functions. This section provides detailed information on the capabilities and applications of these features. Forced and Unforced States In a general sense the word state refers to the information that a process may have accumulated over the time that it has existed. The process state may not include all information to which the process has had access, but only that which it has chosen to retain. State information may be continually updated as new events occur and data becomes available. In terms of a state transition diagram (STD), the word state refers to an object that corresponds to one of the primary modes or situations that a process may find itself in. States are mutually exclusive and complementary, meaning that a process is always in exactly one state: more than one state may never be occupied at a time. The process can move between states in response to the interrupts that it receives. The transitions that depart from a state indicate which states may be occupied next, and the condition that each change requires. Process Domain Specifications of actions may be associated with each Proto-C state. In Proto-C terminology, actions are called executives. The executives of a state are split into two sections, called enter executives and exit executives. As the names indicate, a state s enter executives are executed when a process enters the state, and its exit executives are executed when the process leaves to follow one of the outgoing transitions. Proto-C defines two types of states, called forced and unforced, that differ in execution-timing. In Proto-C diagrams, forced states are graphically represented as green circles, and unforced states are drawn as red circles. On monochrome displays and hard copy, forced states are dark and unforced states are light. 195-Prdef

24 Process Model Operation Modeling Concepts Graphical Representation of Forced States and Unforced States Unforced State (Red on color display) Forced State (Green on color display) Unforced states allow a pause between the enter executives and exit executives, and thus can model true states of a system. Once a process has completed the enter executives of an unforced state, it blocks and returns control to the previous context that invoked it. This context may be another process that invoked this one by calling the KP op_pro_invoke(); or if the process was invoked by the Simulation Kernel, blocking signifies the end of the current event and the Kernel may select a new event in order to begin its execution. At this point, the process remains suspended until a new invocation causes it to progress into the exit executives of its current state. The following diagram depicts the flow of execution through the unforced states of an STD as interrupts cause the process to advance. 196-Prdef

25 Modeling Concepts Process Model Operation Execution Flow through Unforced States The process completes the enter executives immediately upon entering an unforced state and then blocks until a new invocation occurs. Transitions guide the process to a new state or possibly back to the same one, depending upon the applicability of their conditions. Enter Executives Blocked (waiting for invocation) Exit Executives Enter Executives Blocked (waiting for interrupt) Exit Executives start of invocation Once an invocation occurs, the process executes the exit executives and proceeds immediately to the next state to also complete the enter executives there, and then blocks again. These actions comprise a complete process invocation and require no time delay. end of invocation start of invocation Process Domain Enter Executives Blocked (waiting for interrupt) end of invocation Exit Executives The diagram clearly shows the starting and stopping points of a process invocation. In all cases (except the initial invocation), when a process is invoked, it is poised to begin executing the exit executives of its current state. It then progresses until it completes the enter executives of an unforced state where it again blocks. Therefore if only unforced states are involved, the cycle is as follows: 197-Prdef

26 Process Model Operation Modeling Concepts 1) exit executives of current state 2) transition to next state 3) enter executives of next state Forced states are so called because they do not allow the process to wait. They therefore cannot be used to represent modes of the system that persist for any duration. In other words, the exit executives of a forced state are executed by a process immediately upon completion of the enter executives. Therefore the exit executives of a forced state are generally left blank, since they are equivalent to the same statements placed at the end of the enter executives. Because forced states cannot represent actual system states, they are not generally used as much as unforced states. However they are useful in certain cases to graphically separate actions or control flow decisions that are common to several unforced states; graphically separating out definitions of decisions and/or actions in this manner can sometimes provide better modularity of specification, as well a more visually informative state transition diagram. The introduction of forced states causes only a minor adjustment in the execution flow depicted in the above diagram. Unforced states still represent the starting and stopping points of invocations; however any number of forced states may be traversed between them. This is illustrated in the following figure. Execution Flow through Combination of Unforced and Forced States Invocation starts at top of exit executives of unforced state Any number of forced states may be traversed between unforced states during an invocation Invocation ends at bottom of enter executives of unforced state Initial State One special state, called the initial state, must be designated in each process model. An existing state may be assigned this role at any time by using the set initial state operation of the Process Editor. Graphically, the initial state is identified by a large arrow located at its immediate left, as shown below: 198-Prdef

27 Modeling Concepts Process Model Operation Graphical Representation of Initial State arrow indicating the initial state The initial state is the point at which execution begins on the first invocation of the process. It has no special significance for any subsequent invocations, and may otherwise play the role of a normal state. However, since this state usually contains executive statements performing initializations that should occur only once, most models do not include transitions that lead back to it. Upon receipt of the first interrupt, entry into the initial state takes place at the beginning of the enter executives. Some models devote this state only to initialization actions, and expect that a begin simulation interrupt will be provided exclusively for the purpose of completing these actions at time zero. The issue of whether or not such an interrupt is expected and the related issue of whether the initial state should be forced or unforced must be treated carefully to avoid mishandling the first interrupt. There are several possible approaches, which are discussed in this section. In describing these approaches, interrupts other than begin simulation interrupts are referred to as mainstream interrupts. 1) The initial state is forced, and a begin simulation interrupt is expected. Since the initial state is forced, the process necessarily proceeds to a second state as soon as initializations are complete. The enter executives of this second state must not perform actions related to the processing of mainstream interrupts since these actions would be (incorrectly) executed at initialization. Typically, the second state is an unforced state that acts as a ready position for the process to handle subsequent mainstream interrupts. This approach makes sense for cases where the first unforced state entered after initialization is also reentered for later mainstream processing. Were this not the case, the initial and second state could simply be collapsed into one unforced initial state. Process Domain 199-Prdef

28 Process Model Operation Modeling Concepts Initialization Strategy 1: Forced Initial State / Begin Sim. Interrupt no initialization code here other general mainstream processing all initializations here process flow eventually returns to first unforced state 2) The initial state is forced, and a begin simulation interrupt is not expected: As in the previous case, the process will proceed to a second state immediately after the initial state has completed; however, since the initial interrupt is a mainstream interrupt, it is correct to process this interrupt by performing additional actions. Thus, the conditional transitions out of the initial state may guide the process into several possible second states, where processing of the interrupt can take place. Note that the limitation presented by this scheme is that initializations are not performed until the first mainstream interrupt occurs, which may be well after time zero. Initialization Strategy 2: Forced Initial State / No Begin Sim. Interrupt no initialization code here initial invocation can lead to several states all initializations here other general mainstream processing 3) The initial state is unforced, and a begin simulation interrupt is expected: In this configuration, initialization statements placed in the enter executives will complete at time zero, after which the process will block until the arrival of the first mainstream interrupt. Therefore the exit executives of the initial state should be appropriately specified for handling of a mainstream interrupt; they may simply be empty in which case the interrupt handling code must be in the enter executives of the state that follows or in the transition executives. Like the previous ap- 200-Prdef

29 Modeling Concepts Process Model Operation proach, this organization makes sense when the first mainstream interrupt may lead the process into several different states; however note that it accomplishes initialization at time zero, rather than waiting for a mainstream interrupt. Note also, that this approach is usually not appropriate if the initial state is to be reentered during processing of later mainstream interrupts, since the initialization statements in the enter executives would be executed repeatedly. Initialization Strategy 3: Unforced Initial State / Begin Sim. Interrupt first mainstream interrupt can lead to several states all initializations here at time zero other general mainstream processing 4) The initial state is unforced, and a begin simulation interrupt is not expected: This is an unusual approach since it requires a mainstream interrupt to perform initializations, and yet has the process block without proceeding on to other states. Thus, any processing associated with the first mainstream interrupt must be embedded in the enter executives of the initial state; if this processing is generic and appears elsewhere in the model (i.e, for steady-state processing of the same sort of interrupt), then it may need to be redundantly specified. Process Domain Note that begin simulation interrupts are controlled within the node domain by assigning the appropriate value to the begsim intrpt attribute of processor and queue modules. Also, begin simulation interrupts cannot be enabled for dynamically created processes (i.e., the begsim intrpt attribute applies only to the root process of a QP); however, their effect can be emulated for such processes by having the parent process perform an invocation via op_pro_invoke() immediately after creation via op_pro_create(). Thus the above approaches to organizing a process initialization stages is applicable to dynamic processes as well. Improper configuration of the initialization stages can result in serious logical errors for a process. In particular, if a process that expects a begin simulation interrupt (or equivalent invocation) does not receive it (e.g., because the begsim intrpt attribute is not enabled), it may misinterpret the first mainstream interrupt as the interrupt it expected. Typically in such cases, initialization is still performed 201-Prdef

30 Process Model Operation Modeling Concepts Transitions correctly since the process simply assumes it has received the expected indication to perform initializations. However, the mainstream interrupt is likely to be ignored by the process, which can lead to loss of critical information and/or omission of critical early actions that should have been taken by the process. One particular example of this problem occurs when the first mainstream interrupt that occurs is a stream interrupt, indicating the arrival of a packet at one of the QPs input streams. If the process assumes a begin simulation interrupt has occurred instead, the arriving packet is likely to be ignored and will remain in the input stream. Subsequent stream interrupts that are correctly interpreted will cause the process to try to acquire the arriving packets from the input stream; however the ignored packet will be obtained instead, since streams queue packets in a firstin-first-out order. Thus, models that exhibit this error can be identified by a shift in the packet processing. Paradoxically, one of the effects of this shift is that processes that receive packets infrequently tend to forward them with greater delay, since each packet must wait for the following one to trigger its processing; this behavior is counterintuitive for some simulation studies that measure cumulative delay of packets through a system, since in general less frequent arrivals correspond to a lightly loaded system, which in turn implies lower delay through the system. Transitions describe the possible movement of a process from state to state and the conditions under which such changes may take place. There are four components to a transition s specification: a source state, a destination state, a condition expression, and an executive expression. The specification may be read as follows: when in the source state, if the condition is true, implement the executive expression and transfer control to the destination state. In the Process Editor, transitions are specified graphically. Each state may have any number of outgoing and incoming transitions depicted as directed arcs with the arrow pointing toward the destination state. The condition and executive expressions appear in a combined label next to the arc. The tool always places the condition expression within parentheses and precedes the executive expression by a forward slash ( / ) to separate the two components. Transitions that have nonempty condition expressions are depicted as dashed arcs; those without conditions are depicted as solid arcs, as shown in the following diagram. 202-Prdef

31 Modeling Concepts Process Model Operation Representation of Transitions non-empty conditions appear as dashed arcs transitions can return to same state empty conditions appear as solid arcs A transition s condition is evaluated as a boolean expression in order to decide whether or not the process should enter the transition s destination state. A process evaluates outgoing transitions once the exit executive statements of the source state have completed. For forced states, enter and exit executives are executed in immediate succession, and so both executive blocks and the transition evaluation can be viewed as a single logical series of actions (although exit executives are usually empty for forced states). For unforced states, a pause occurs between the enter and exit executives, and so only the latter can be grouped with the transitions. Transition condition expressions may be complex combinations of criteria that involve state variables of the process, attributes of the current interrupt, and other information stored in shared or global memory. It is also possible for conditions to be based on computations of any complexity by calling a user-defined procedure that returns a boolean value (typically, such a procedure would be placed in the function block of the process model). Alternatively, computations that support condition expressions may be placed at the end of the exit executives of a transition s source state, since these are executed immediately before the conditions are evaluated. Process Domain All transitions that depart from a state are evaluated before a process may progress to any transition destination. This allows the detection of two types of errors and assures that behavior is independent of the order in which the transition conditions are evaluated. If none of the conditions have a TRUE value (a nonzero value as a C or C++ language expression), then an error message to this effect will be generated by the process, since it is impossible for it to continue execution. Similarly, if more than one transition condition has a TRUE value, an error message will be issued. Both of these errors are considered sufficiently serious to cause the simulation to halt. It is therefore important that the transitions that emanate from a state should collectively be mutually exclusive at the time they are evaluated (no two can simultaneously be true), and complementary (at least one is necessarily true). The following equivalence between an STD fragment and a pseudo-code fragment illustrates the logic that is applied in order to evaluate multiple outgoing transitions. 203-Prdef

32 Process Model Operation Modeling Concepts Pseudo-Code Equivalent of Multiple Transition Configuration if (PACKET_IS_DATA) jump_to_state (S1) else if (PACKET_IS_ACK) jump_to_state (S2) else error (NO_TRUE_TRANSITION) A special condition called default is provided to represent the complement of the conditions associated with the defined transitions leaving a state. Each state should have at most one outgoing default transition. This is a useful mechanism to represent complementary conditions when they are complex, and ensures that the process will not encounter an error at the state of interest due to a missing TRUE transition. Default transitions succeed only if all other transitions conditions are false, as shown by the pseudo-code example below: Pseudo-Code Equivalent of Multiple Transition Configuration with Default if (PACKET_IS_DATA) jump_to_state (S1) else if (PACKET_IS_ACK) jump_to_state (S2) else jump_to_state (S3) As a final note on condition expressions, transitions that are configured with an empty condition attribute are equivalent to transitions whose conditions always evaluate true. These are referred to as unconditional transitions. It follows from the previous discussion that if a state has an unconditional transition departing from it, that it may support no other outgoing transitions. 204-Prdef

33 Modeling Concepts Process Model Operation Each transition incorporates an attribute that supports the specification of an executive statement. A transition s executive is carried out at the time that a process decides to traverse the transition. In other words, once all outgoing transitions have been evaluated, the process selects one of them, implements its executive statement if there is one, and advances to the enter executives of its destination state. This sequence is described below in the form of pseudo-code for a simple pair of transitions. Transition executives are useful in order to associate an action with a state, but only when it is entered or exited for a particular reason. Actually incorporating the action into the state s enter or exit executives instead would cause it to be executed regardless of the reason for which the state was entered/exited, which may be undesirable in some cases. Pseudo-Code Equivalent of Transitions with Executives if (QUEUE_EMPTY) { SET_TIMER jump_to_state (S1) } else if (QUEUE_NOT_EMPTY) { SEND_ONE_PACKET jump_to_state (S2) } Process Domain else error (NO_TRUE_TRANSITION) Prdef Using Macros to Define Complex or Recurring Expressions In the examples above, condition and executive expressions consist only of English-like text, and at first sight do not appear as C language programmatic expressions. The technique used in these examples, and typically used in most process models, is to define macros whose names represent underlying expressions. Proto-C simply passes through the macro definition capability of the C language to support this practice. Almost all macros used by a Proto-C model are defined in its header block. The header block is a free-form area for C or C++ language code, similar to the top portion of a C or C++ file. Macros are generally used to represent constants, transition conditions, transition executives, or commonly performed operations. Macros defined directly within the header block begin with the #define C and C++ preprocessor directive. Macros may also be defined in external definitions 205-Prdef

34 Process Model Operation Modeling Concepts files (files with a.h suffix in C and C++) and included through the header block by using the #include preprocessor directive. The external file inclusion method is useful when multiple process models must share a consistent set of definitions; this avoids having to enter and maintain identical definitions in each process header block. The following header block fragment provides an example of typical Proto-C macro definitions. 206-Prdef

35 Modeling Concepts Process Model Operation Macro Definitions within Process Model Header Block Process Domain conditional and executive expressions for transitions are defined in header block 207-Prdef

36 Process Model Operation Modeling Concepts Prdef Variables Proto-C processes have access to several forms of memory to store information. Each form of memory has different properties that make it appropriate for particular uses. Some of these memory forms allow information to be declared and manipulated directly as ordinary names; these forms of storage are referred to as variables. Proto-C processes can make use of three distinct categories of variables called state variables, temporary variables, and global variables. The following table shows these types of variables and the sections of code where they can be accessed. Type of Variable Visibility State executives Functions in function block Functions in external files (.ex.c files) temporary X state X X global (as defined in external header files or in the Header Block) X X X (as long as extern is used) Variable Components All variables, regardless of their category, have a name, a datatype, and a value. The name and datatype of a variable remain fixed throughout the life of a process; the value component is the only one that may change. Name: unlike attributes, variables can be accessed without the use of any Kernel Procedures. Instead, an ordinary reference to a variable s name implicitly signifies a reference to its value. Variable names are defined as part of a mechanism called declaration; each of the three variable categories uses a slightly different declaration mechanism in order to indicate to the process compiler what category applies. The names that are selected can be general alphanumeric character sequences respecting the following rules: 208-Prdef

37 Modeling Concepts Process Model Operation Rules for Variable Naming Names must consist of alphanumeric characters only; the underscore character ( _ ) is also allowed. Both upper and lower case are acceptable and are considered distinct. Names must begin with letter characters (i.e., not numbers or _ ). Each name must be used in only one declaration (i.e., the same variable name should not be used for more than one of the variable categories in a given process). Datatype: the datatype of a variable specifies the kind of information that it is capable of storing. OPNET provides a number of special datatypes that are predefined for common modeling purposes. Some of the essential datatypes are summarized in the following table. Refer to the Simulation Kernel manual for a complete listing of predefined datatypes and their usage. Essential OPNET Predefined Datatypes for Variables Datatype Distribution Evhandle Description Loaded Probability Density Function. Handle providing access to a scheduled event (e.g., supports cancellation). Process Domain Ici Objid Packet Compcode List Stathandle Group of attributes used to associate additional userdefined information with an event. Unique identifier of a simulation object; used in most operations on objects. Structured group of data fields representing a message that can flow over packet streams (node domain) and over links (network domain). Status value returned by many kernel procedures to indicate success or failure. Linked list construct provided by the Prg package of KPs. Useful for managing lists of general user-defined data structures. Handle provided when a local or global statistic is registered. Used to write updated values to the statistic. 209-Prdef

38 Process Model Operation Modeling Concepts In addition, Proto-C provides completely general data storage by supporting datatypes from the C and C++ languages. This includes not only built-in C and C++ datatypes such as int, double, and char, but also arrays and complex data structures formed from any combination of other datatypes. Custom data types are usually specified in the header block of a process or in an external definitions file that is included via a #include statement in the header block. In general the C typedef and struct mechanisms are used as shown in the examples below. Consult a C or C++ language reference for complete information on the use of these constructs. Definition of Custom Datatypes in Header Block User-defined structures can include OPNET predefined datatypes Variables are declared in slightly different formats depending upon their category, and each particular declaration mechanism will be explained in the sections on each category in this chapter. However, in all cases, declaration requires that the data type and name of a variable be specified. Additionally, a variable may be modified so that it is actually an array of one or more dimensions of its particular data type. In general, the declaration format is as follows: Evhandletimer_handle_table[10]; (Datatype)(Name)(optional array dimension) Value: this term refers to the actual contents of the memory that is associated with a variable. For simple variables this may be an individual 210-Prdef

39 Modeling Concepts Process Model Operation Operations on Variables number or string of characters; for compound data structures many such items could be involved. The specific nature and organization of a variable s contents are specified by its datatype. These contents may change over time in order to store new or updated information, as requires by the process model, hence the name variable. Proto-C variable values are manipulated within the condition and executive statements of states and transitions. The basic operations that can be performed on a variable, regardless of its type, are to obtain its value or to modify its value. Note that the datatype and name of a variable are immutable. Depending on how a variable name is used in a statement, its value can either be obtained or modified. In general, all variable manipulations follow the conventions of the C language; most C textbooks should therefore provide in-depth coverage of this topic. Briefly, there are two basic forms that support modification of a variable value. The first, and most common is an assignment using the equals ( = ) operator, several examples of which are shown below: Assignment of Variable Values with the = Operator assignment from return value of a procedure assignment from expression combining other variables shorthand notation var = var + increment time = op_sim_time(); next_trans_time = time + packet_size / data_rate; num_bits_sent += packet_size; Process Domain shorthand notation var = var + 1 num_packets++; A second method of assignment is designed to allow a procedure to modify a variable s value rather than modifying it in the local context. This is accomplished by informing the procedure of the memory location at which the variable s value is stored. Thus, the procedure can modify the contents of the memory locations and upon returning, the assignment has already been performed. A number of Kernel Procedures use such an interface in order to support modification of multiple variables in a single call (C and C++ functions cannot otherwise return multiple values), or to compute results of several different data types. In the C and C++ languages, the memory location of a variable s value is obtained by applying the & operator to the variable s name, as shown in the following examples. 211-Prdef

40 Process Model Operation Modeling Concepts Assignment of Variable Values by Passing Addresses to Procedures same procedure assigns variables of several different datatypes. single procedure call modifies multiple variables (six in this case). arrays (such as strings which are character arrays) do not require & operator since their variable names already refer to their memory location. op_pk_nfd_get (pk, type, &pk_type); op_pk_nfd_get (pk, start_time, &time_sent); op_ima_obj_pos_get (objid, &la, &lo, &al, &x, &y, &z); op_ici_format (ici_ptr, format_name); Obtaining the value of a variable is very simple, since a variable s name actually is a symbol representing its value. In other words, by simply mentioning a variable, the C/C++ language automatically substitutes its current value in the surrounding expression. Note however, that this is true also for modification of a variable using the = operator, as shown above. What differentiates an assignment from an obtainment has therefore more to do with the placement of the variable names relative to the operators in an expression. When the = operator is used, the variable value on the left side of the operator is modified, whereas variable values on the right side are simply obtained (that is, their current values are substituted in the locations where their names appear). Other commonly performed operations on Proto-C variables include comparison operators such as == (is equal to),!= (not equal to), > (greater than), < (less than), >= (greater than or equal to), <= (less than or equal to). Note the difference between the equality test operator which has two side by side = characters and the assignment operator represented by just one such character. The confusion between the two is a source of common errors in process behavior. In addition, arithmetic operations such as +, -, *, and / are supported, as are all other C/C++ language features. Once again, please refer to a C or C++ language reference for an in-depth treatment of these and other operators. State Variables Variables that are used to represent the information accumulated and retained by a process are referred to as state variables. This name is due to the fact that these variables, together with the current position of a process within its state transition diagram, represent the complete state of a process at any time. Note that processes may generate or have access to much information over time that does not become encoded into their state; therefore state refers only to the information that the process itself decides to retain by recording it into state variables. State variables are declared in a dedicated area of a Proto-C model, referred to as the state variable block. New state variables can be declared, or old ones 212-Prdef

41 Modeling Concepts Process Model Operation modified by choosing State Variables from the Code Blocks menu of the Process Editor. For details on using this operation, refer to section Pr.6.4 State Variables in the Editor Reference manual. State variables are persistent, meaning that from the perspective of each process, they retain their value over time. They can only be modified by explicit assignment statements that are executed by the process itself. This implies that the values of the state variables of a process are frozen when it blocks (i.e., halts execution after completing the enter executives of an unforced state), and found unchanged by the process when it resumes execution at its next invocation (note that, although it is rarely used, the KP op_ima_obj_svar_get() allows this traditional property of state variables to be altered). An important property of state variables that is necessary for persistence is that they are maintained in a manner that is private for each process. This means that individual instances of the same process model, even if they exist within the same queue or processor, are able to independently store information in their variables without conflict, even while referring to them with the same names. In other words, changes made to state variables in one process do not affect the values of variables held by another. State variables have no particular initial values when a process is invoked for the first time. Since these variables constitute part of the state of a process, it is the responsibility of the process itself to assign consistent initial values to them during the first invocation. In fact, this is usually one of the principal activities conducted in the executive statements of the initial state. Note that in contrast to temporary and global variables, it is not possible to incorporate an automatic initialization of state variables into their declaration. Process Domain An important warning applies when selecting names for state variables due to the underlying method by which they are implemented. Although state variable names can be general, it is important to avoid naming conflicts with symbols used elsewhere in the process model. In particular, temporary and global variables, function names, function argument names, structure fields, and local variables of functions that appear elsewhere in the model must not be identical to the names used for state variables, or compilation errors will occur. Temporary Variables A process may declare temporary variables in order to store information that does not require persistence. Temporary variables are not guaranteed to have any particular set of values when a process model is invoked. In particular, the values that were assigned to these variables by the same process during its previous invocation may have been changed. Since they have no persistence, temporary variables are useful only as scratch storage to facilitate computation of complex expressions or to hold information within the time frame of a single process invocation. For example, an integer variable used as the index of a loop would generally be a temporary 213-Prdef

42 Process Model Operation Modeling Concepts variable; a packet that is obtained, examined, modified, and sent again all in one invocation, would also be a temporary variable. In order to decide if a process model should declare a variable under the state or temporary category, the developer should determine if there are cases in which the variable needs to retain its value from one invocation to the next. If this is the case, then a state variable must be used; otherwise a temporary variable may be used. If there is doubt concerning a variable s declaration, state variables may always safely be used; note however that a state variable requires a memory allocation of corresponding size that will last as long as the process exists, whereas a temporary variable requires no additional memory. Temporary variables are declared in an editor pad that appears as a result of using the edit temporary variables operation. An example of temporary variable declarations appears below. Declaration of any predefined C/C++ and OPNET datatypes as well as user-defined datatypes is possible. Note that the backslash character ( \ ) does not precede the variable name as it does in the case of state variables. Automatic initialization of temporary variables is possible by incorporating an assignment into the declaration, as shown in the example below. This initialization takes place each time that a process is invoked. Temporary Variable Declarations automatic initialization may be part of declaration Global Variables Global variables provide a means for multiple processes in different modules, including processes of different types, to store information in a common location. This is a feature provided directly by the C and C++ languages, which also refers to these types of variables as globals. 214-Prdef

43 Modeling Concepts Process Model Operation Global variables may make use of any C or OPNET predefined datatype as well as custom datatypes. Declarations should be entered into a process model s header block via the edit header block operation of the Process Editor. Each global variable should have one principal declaration within the header block of the process model with which it is most closely associated. If other process models also share access to the variable, their header blocks must include an external declaration. There may be any number of process models with external declarations to a global variable, but only one should include a principal declaration. External declarations are identified by the keyword extern, as shown below. Declaration of Global Variables in Two Process Header Blocks principal declarations of global variables are with one process Process Domain other processes must use external form of global declaration 215-Prdef

44 Process Model Operation Modeling Concepts As with temporary variables, global variable initializations can be performed by making assignments within the declaration statements. This is possible only within the principal declaration. Initialization takes place before the simulation begins. Additional initializations of globals that are a function of simulation input or model configuration are generally performed by designated processes during their initial invocations. Note that global variables should be used with care since their use creates dependencies among processes. In other words, when a process modifies a global variable, the change may have an impact on the operation of other processes. In addition, global variables that are shared across physical boundaries (e.g, across an entire network model) do not always correspond to realistic representations of actual systems. The same data that can be represented by globals in an OPNET model might be implemented as distributed storage in an actual system; or if centralized storage is used, delays would be incurred when accessing the data. The model developer must make a judgement regarding the appropriateness of the global variable approach and possibly make corrections for unrealistic effects it introduces. Prdef Process Model Attributes Process model designers frequently specify characteristics of a process that require the flexibility to adapt to a variety of situations. For example, communication protocols may provide various options to their users, such as timeout durations, maximum number of retransmissions, window sizes, etc. Similarly, a computer operating system model may offer multiple alternatives for virtual memory size, maximum number of concurrent tasks, etc. Rather than design similar process models that differ in just these features, it is preferable to design parameterized process models. Those characteristics of the process that require variability can be viewed as parameters of the model. As discussed in the Modeling Framework chapter of this manual, OPNET provides model attributes for the purpose of developing parameterized models. Process models are the models that typically make most use of this capability, since ultimately, it is user-defined code that must in some way interpret the values of customized attributes in order to implement variable behavior (in contrast, the variable behavior of standard OPNET objects is configured via built-in attributes). It is often most appropriate to define the model attributes in the same model as the code that uses them. Model attributes can be declared for a process model by using the edit model attributes operation of the Process Editor. Each model attribute is defined by specifying a unique name, and properties. The properties allow control over the attribute s default value, symbol map, numerical range if appropriate, and several other characteristics. Refer to the Modeling Framework chapter of this manual for more information on model attributes and attribute properties. 216-Prdef

45 Modeling Concepts Process Model Operation. Process Model Attribute Declaration During simulation, process model attributes appear simply as attributes of queues and processor modules. They may be accessed both to modify and to obtain their value by using the KPs op_ima_obj_attr_set() and op_ima_obj_attr_get(), respectively. However, in most cases, process model attributes are never changed during the simulation but instead serve only as parameters that the process uses to configure itself when the simulation begins. Typically, each process that uses model attributes performs these configurations in its initial state, where it loads the values of attributes into a corresponding set of state variables. The state variables are used thereafter since they are more convenient and efficient to access than attributes. A typical example of model attribute loading appears below. Process Domain 217-Prdef

46 Process Model Operation Modeling Concepts Loading of Process Model Attributes into State Variables at Initialization Attribute Interfaces Each process maintains a set of attribute interfaces which is distinct from its model attributes. As discussed in the Modeling Framework chapter, the attribute interfaces contain attributes promoted from objects within the model, as well as specifications for attributes of the object that will use the model. In the case of a process model, none of the objects within the model (e.g., states and transitions) are able to promote attributes, and the object that will use the model is a queue or processor. Therefore, the attribute interfaces consist simply of queue and processor attributes. By using the attribute interfaces, the process model developer can specify in advance the values and properties of a queue or processor that will use this model. 218-Prdef

47 Modeling Concepts Process Model Operation Specification of Process Model Attribute Interfaces Queue/Processor attributes whose values can be enforced by the process model developer are assigned a value and given the hidden status Process model attribute interfaces are frequently used to ensure that queues and processors are properly configured to act as hosts to a given process model. In general attributes that are not relevant to the process model are placed in the hidden status in order to simplify the QPs menu. In many cases, this includes attributes such as intrpt interval, failure intrpts, recovery intrpts, super priority. The process model designer generally knows whether or not the process requires a begin simulation interrupt and whether it supports and end simulation interrupt; the begsim intrpt and endsim intrpt attributes can be set accordingly and hidden. Process Domain Process model attribute interfaces also provide the capability to associate comments with the process model in order to provide guidance and background information to users of the process model. Refer to the Modeling Framework chapter of this manual for more information on model attribute interfaces. Prdef Modularizing Computations Certain process models make recurring use of an identical computation in support of a decision or action. Identical does not necessarily mean that the result is always the same, simply that the form of the computation (i.e., the steps into which it can be decomposed) is invariant. However, the data that the computation manipulates may change each time that it is executed. This data is called the input of the computation and each individual data item that comprises the input is referred to as a parameter of the computation. 219-Prdef

48 Process Model Operation Modeling Concepts The most straightforward approach to realizing a process model that has recurring use of the same computation is to simply repeat the specification of the computation in detail at each location where it occurs (i.e., in various executive blocks and on each transition that executes it). However, this approach presents several significant disadvantages: It requires redundant entry, lengthening the time required to complete a model s specification. It requires redundant maintenance, meaning that if the computation needs to be changed, in order to enhance or update the functionality of the model for example, then identical changes must be made in multiple parts of the process model. For complex computations, the size of the model may increase appreciably, in turn affecting the total memory requirements of a simulation. Process model logic is not streamlined, requiring someone studying the process model (e.g., to understand or upgrade its functionality) to examine or verify significantly more statements. There are two principal techniques used in Proto-C to streamline recurring specification of identical computations. In both cases, the objective is to encapsulate the specification of the computation into a form that can be reused whenever the result of the computation is needed. Proto-C dynamic processes and C/C++ functions both support this modular computation approach since they can contain general calculations that operate on variable inputs called arguments. Arguments are the parameters of a computation. Modularizing Computations with Dynamic Processes Dynamic processes are discussed in depth in earlier sections of this chapter, as well as in the Modeling Framework chapter of this manual. A brief description of their use for modularizing a computation is presented here. 1) A dynamic process that contains all the logic of the computation of interest must be specified. This process should make use of argument memory obtained via the KP op_pro_argmem_access(), to represent the computation s parameters. In addition, this process should be stateless; this means that it should define no state variables and include only one unforced state in order to assure that only the arguments of invocation affect each outcome. In other words, there should be no internally accumulated information that can create dependencies between separate invocations. 220-Prdef

49 Modeling Concepts Process Model Operation 2) A process requiring the computation to be performed on a recurring basis creates a dynamic process of the appropriate type, by calling the KP op_pro_create() and retaining the process handle that is returned. This must be done at some time prior to the computation s first use usually in the parent process initial state. 3) Each time that the parent process requires the computation to be performed, it must set up appropriate argument memory and invoke the child process using the KP op_pro_invoke() and the earlier obtained process handle. If required, the child process may return results by modifying the argument memory. Modularizing recurring computations is not the main application of dynamic processes. Processes are primarily designed for modeling ongoing threads of execution. These threads normally have state memory and therefore do not behave identically on each invocation. However, the dynamic process approach outlined above is followed in some cases as an alternative to using C or C++ functions (described later in this section), because it allows graphical decomposition of a computation's flow of control. Forced states represent simple actions, and decisions about which actions should be performed are encoded in the transitions between states. As shown below, representation of a computation in this manner strongly resembles the flowcharting approach used as a first step in some computer-program design methods. Control Flow of Dynamic Process Implementing Modular Computation Process Domain The process always returns to this state when computation completes. This is where the next invocation will begin. Multiple outgoing transitions depict the process decisions. 221-Prdef

50 Process Model Operation Modeling Concepts Modularizing Computations with Function Calls The most common and straightforward approach to modularizing recurring computations is to make use of the function call mechanism provided by the C and C++ languages. Functions (also referred to as procedures) are specifications of computations that may accept parameters, referred to as arguments. Arguments may be of any datatype provided by C, C++, OPNET, or the user s custom definitions. Depending on the service that is required of them, functions may provide return values that result from their computations or simply perform a series of actions and return no result. Please refer to a C or C++ reference text for more information on defining functions. In Proto-C, any number of functions may be specified within a section called the function block of a process model. The function block s contents can be edited by using the edit function block operation of the Process Editor. All normal syntactic rules of the C/C++ programming language apply within this section of the model. However, note that the text that is entered in the function block will appear after that of the header block, allowing the use of data types and macros that are defined therein. Each function represents a package of capability that the logic embedded within the state transition diagram (STD) may call upon. This simplifies the appearance of the STD and allows it to exercise the same functionality in multiple circumstances with minimal additional specifications. For example, an STD may require the same exact series of actions to be applied to a packet while in different states and upon traversing several transitions; by implementing these actions within a function in the function block, the required logic can be developed only once and invoked from each part of the model that requires its execution. Functions specified within the function block are generally for the use of the process model that they are associated with. However, a function defined in the function block of one process may be called from the STD or even from the function block of another. However, this practice creates dependencies between process models such that the process that actually contains the function s definition must always be present within a model that also includes the process that calls upon the function. If this rule is not followed, an error relating to the missing function will result when attempting to generate simulations. A simple solution to the dependencies created by cross-calling of functions is to ensure that each process model is self-sufficient by incorporating all function calls that it requires within its own function block. However, two important caveats apply to this technique: first, if a function appears in the function blocks of multiple process models, then it must have a different name in each one, or the function will be considered to be multiply defined, and a corresponding error will occur when attempting to create a simulation executable that includes the conflicting processes. One possible approach to avoiding this problem is to always prefix the names of functions defined within the function block with the name of the process itself. For example, a function that schedules a timeout event for a process called X25 could be called x25_schedule_timeout. Second, redundantly 222-Prdef

51 Modeling Concepts Process Model Operation specifying capability by replicating a function in the function blocks of several process models defeats one of the important purposes that suggests the use of functions in the first place; namely, the redundant maintenance and synchronization of the multiple instances can complicate development and maintenance efforts and lead to inconsistencies among the versions. External Object Files As an alternative to this approach, the model developer may wish to consider defining functions in external object files that are linked into the simulation executable. This allows each function to be developed and maintained in a centralized fashion and still be shared by all process models that require it. It does, however, create a dependency between the process models and the external files that contain the functions. This prevents the process model from being standalone, which can cause minor complications when sharing the model with other users, for example. OPNET allows the user to specify those external object files that a model requires at two separate modeling levels. The list of external object files may be specified as part of a network model if desired. However, this approach requires that the user have knowledge of the external files that are implicitly relied upon by the node models that are present. This is not always possible or desirable, particularly when the network level user is not the same individual who developed the embedded process models. This is particularly a problem for IT DecisionGuru and Modeler XE users, who merely manipulate node and link models and are not intended to have any knowledge concerning these models internal composition. In order to circumvent this problem, and also to provide a more solid association between the external files and the code that relies upon them, OPNET allows each process model to formally declare the external object files on which it depends. This can be done using the declare external object files operation of the Process Editor, which is documented in the Editor Reference manual. Declaring external object files allows OPNET to automatically construct the list of external files that are required to construct a complete simulation, thus providing transparency to network-level users. Please also refer to the Simulation Design chapter of this manual for more information on external object files. Process Domain Declaring Functions If functions return values that are not integers (i.e., are of datatypes other than int), these functions should be declared prior to their use. If they are used within the STDs executive and condition statements, corresponding function declarations should be placed in the header block, to ensure that they appear in the proper order. The purpose of a function declaration is to inform the compiler what type of value will be returned. Declaration syntax is illustrated by the following example. 223-Prdef

52 Process Model Operation Modeling Concepts Header-Block Declaration of Functions no arguments necessary here data types must agree Functions defined within the function block have access to variables on a slightly different basis than the process model with which they are associated. Global variables are available in an identical manner with declarations (either principal or external) required in the header block. Temporary variables of the process are not usable within the function block s functions. However, each function may of course declare its own local variables. State variables are available to a function block function, but use of direct references to these variables will preclude calls to the function from other processes. In other words, state variables may be accessed only if they belong to the associated process model (i.e., the one in which the function block is included) and in addition, that process model is the one currently executing. Misuse of state variables in the function block can lead to complex simulation errors and should therefore be considered very carefully. A simple way to avoid this issue is to pass the values of state variables to a function as arguments, rather than allowing it to access them directly; similarly, if a calling function would modify state variable values, then the state variables may be passed by address as arguments to the function, or assignments may be performed by higher level code, once the function has returned. Prdef Diagnostic Capabilities OPNET simulations automatically incorporate a sophisticated debugger called ODB that allows the user to interactively monitor the progress of a simulation and the state of its objects. ODB s capabilities are exercised from a 224-Prdef

53 Modeling Concepts Process Model Operation command line. Most of these capabilities are entirely provided by the Simulation Kernel and require no customization on the part of the developer. However, because processes are user-defined and can store information in proprietary data structures, and because the Simulation Kernel is not capable of knowing which particular information within a process is interesting to report, ODB provides two special commands that can be applied to processes. These commands, called prodiag and proldiag, allow useful reports to be printed about the current state of a user-defined process. The prodiag and proldiag commands require an argument, which is the process ID of the process of interest. Process IDs can easily be obtained via the promap command of ODB. Prodiag and proldiag then execute a series of userprovided statements that have been specified in a special section of the process model, called the diagnostic block. The diagnostic block of a process can be modified by using the edit diagnostic block operation of the Process Editor. Before executing the statements of a process diagnostic block, ODB temporarily makes the process active, as if it has been invoked, so that Kernel Procedures such as op_id_self() and op_pro_self() can be used. In addition, state variables of the process may be accessed normally. General Proto-C logic may be defined in the diagnostic block, although in general, the statements of the diagnostic block are quite simple, since their purpose is simply to report the information that constitutes the state of the process. In some cases, for or while loops are required in order to report the contents of lists; if statements are also sometimes used to report only information relevant to a given situation. An example of a process model s diagnostic block appears below. Process Domain 225-Prdef

54 Process Model Operation Modeling Concepts Typical Process Model Diagnostic Block state and temporary variables are accessed directly code is entered directly no function should be set up no local variables are defined (use temporary variables instead) supported KPs are used for printing Note from the example that the KPs op_prg_odb_print_major() and op_prg_odb_print_minor() are used to print information rather than the C library function printf(). These two KPs standardize the format of the information that is printed in order to better integrate it with other output issued by ODB. The example also shows that the diagnostic block is not itself a function and therefore cannot declare local variables. However, it may make use of variables declared in the process model s temporary variable section. A more sophisticated version of the prodiag command, called proldiag, is also provided by ODB. Proldiag differs from prodiag in that it temporarily activates a debugger label, which can be used to selectively perform operations in the diagnostic block. For more information on this topic, please refer to ODB documentation in the External Interfaces manual and to the information provided on the KP op_prg_odb_ltrace_active() in the Simulation Kernel manual. 226-Prdef

55 Modeling Concepts Prdef.3 Process Model Development Methodology Process Model Development Methodology The previous sections of this chapter provide information about the capabilities of the Proto-C language and the specification features of the Process Editor. It should be clear from these sections that Proto-C provides a flexible platform that has the ability to model a wide range of systems. The language provides specific support by adopting a state-transition approach which is well-suited to discrete event systems, and by supplying a number of Kernel Procedures (KPs) that are oriented toward network and distributed systems modeling. At the same time however, Proto-C preserves generality by incorporating all the capabilities of the C/C++ programming language. Due to the generality of Proto-C and the flexibility of the state-transition paradigm, most systems can be accurately represented by many different Proto-C models. The diversity of possible implementations results from the power of the tool but can also present some disadvantages; namely, the model designer may experience hesitation at the start of a model s development effort, as the merits of each approach are considered. This is particularly true in the case of a beginning OPNET user. In addition, the models that a single developer creates over time may vary in approach rather than converge on a single consistent style; this adds difficulty to the future task of maintaining the models, particularly if different developers are involved. In order to reduce problems related to the variability of potential approaches, this section provides a single development methodology that is applicable to process models of all types. The goal of the methodology is not to limit the extent to which Proto-C s capabilities are used, but rather to lend structure to the development process so that the full set of capabilities are used in a consistent and appropriate manner. It is particularly recommended that beginning users follow this methodology in order to quickly advance to the point of developing complex models. Advanced users may wish to continue practicing this methodology so that development becomes a consistent and therefore routine process. Process Domain Note that use of the methodology presented here is not mandatory; the information in the first part of this chapter is sufficient to serve as the basis for development of process models in Proto-C. This methodology presented here is merely a suggested approach that developers may wish to consider. Prdef.3.1 Description of Example Systems Since this section of the chapter describes a methodology that applies to process model design in general, many of the procedures that are prescribed are stated in terms that may at times seem abstract. In order to give these procedures a more concrete form, several simple examples of processes will be used throughout the section. 227-Prdef

56 Process Model Development Methodology Modeling Concepts Pay Telephone System This example process is responsible for managing the usage of a simple coinoperated telephone. The process must respond to the actions of both the telephone user and the network to which it is connected. In particular, it is responsible for the following: 1) Providing a dial tone to the user once a minimum amount of money has been deposited and the network has acknowledged the request for use of the line. 2) Informing the network of the amount of money that has been deposited. 3) Relaying a dial tone signal from the network to the user. 4) Relaying the user s phone numbers into the network if a dial tone has been established (otherwise keystrokes are ignored). 5) Warning the user when money runs out and informing the user when they are finally disconnected (the network provides the process with a notification Warning_Time seconds before the user s time has run out). 6) Returning money to the user if the network indicates the call is toll-free or the user hangs up before the destination party answers. The process resides in the telephone unit itself and therefore manages at most one phone call at a time. Automatic Bank Teller System The process of interest manages the transactions requested by a single user via a keypad. The supported transactions are deposits, withdrawals, and balance verification. In all three cases, the user must insert a magnetic card and authenticate the card s usage by entering an identification number on the keypad. The bank teller process controls five physical devices: (1) the card reader; (2) the deposit door; (3) a text-oriented display to convey information to the user; (4) the cash dispenser; (5) the report printer. In addition, the process has the ability to communicate with another process representing the bank. This remote process supports the following set of transactions: 1) authenticate_request: expects the card s serial number and the user s personal ID number to be passed and either sends back a rejection indication, or an account handle that can be used for transactions. 228-Prdef

57 Modeling Concepts Process Model Development Methodology 2) withdrawal_request: the bank returns an authorization code if the withdrawal is allowed. 3) deposit_indicate: informs the bank that a deposit has taken place. 4) balance_request: the bank returns the user s current balance. Medium Access System A simple medium access method is used by the multiple transmitters that share a channel. Each transmitter must abide by the following rules when trying to transmit a message over the medium: 1) A transmission may not begin until the medium has been idle for Gap_Time seconds, where Gap_Time is a parameter whose value is to be defined. 2) If during a transmission, the transmitter unit detects that another message is present on the medium, then the transmission is immediately aborted and attempted again not before R seconds, where R is a uniformly distributed random number between zero and Backoff_Time. The same rules of transmission (e.g., idle-time restrictions) apply to repeat attempts as to initial transmissions. 3) If otherwise unrestricted, a transmission necessarily begins after the medium has been idle for Gap_Time seconds. Process Domain 4) There is no limit on the number of times a message may be retransmitted. 5) Transmission requests that are submitted to the process are transmitted in a first-in-first-out order. The process queue of messages that await service is considered infinite. Data Link Control System A single outgoing transmission line contains N logical channels, where N is a number that may change dynamically. Each logical channel is equipped with a data link layer protocol that ensures the proper reception of transmitted messages. Reception is guaranteed by using an acknowledgment-based scheme which operates according to the following: 1) Each message is transmitted repeatedly every Timeout seconds until an acknowledgment message that specifically identifies it is received from the destination. 229-Prdef

58 Process Model Development Methodology Modeling Concepts 2) If Max_Attempts transmissions have failed, the message is discarded. 3) Messages are processed in a first-in-first-out order and the message queue is considered to have infinite capacity. This data-link protocol operates independently for each logical channel. Prdef.3.2 Stage 1: Defining the System s Context In almost all cases, process models describe the behavior of a single component within a larger system model, consisting of many components. The role of the process model can then generally be described by the interactions that it has with the other components in the system. From the point of view of the remainder of the system, only the external black-box behavior of the process is of concern, not its internal implementation. It is therefore an important first step in the development of a process model to identify the other system components that it will interact with. Prdef Identifying Interdependent Modules Since processes operate within modules in the node domain, the term components refers to other modules. In order to refer to these components in general, the term interdependent modules is used. If the interdependent modules are processors or queues, then their behavior is also determined by a process model. Because processes are event-driven, all modules that generate events for the process of interest should be considered interdependent; in addition, all modules that receive information from or store information for the process of interest should also count as interdependent, since they play a role in the evolution of the process over time. Note that interdependent modules are not limited to physical neighbors of the process module. For example, modules that are not connected, or even those that are in different nodes, may communicate by delivering packets or sending remote interrupts to each other. See the Communication Mechanisms chapter in this manual for more information on these types of interaction. In some cases, interdependent modules are not all known in advance at the time that a process is designed. In fact, some processes may be designed to handle interactions with an unlimited number of other modules. In such cases one or more representative modules should be included in the design. Before beginning the actual design of the process of interest, all of the interdependent modules, including the module whose process is under design, should be placed together in a diagram. Modules need not be identified by their name, but rather by their function relative to the process of interest. For modules that may appear in variable numbers, ellipses can be used to represent a group. The following sketches depict the physical contexts of the four example systems. Note that at this stage of the design, such diagrams may be developed 230-Prdef

59 Modeling Concepts Process Model Development Methodology manually, or within the Node Editor. Ultimately, however, the physical context of the process is always defined by a node model diagram created with the Node Editor. Interdependent Modules of Pay-Telephone System Telephone User Pay-Telephone System Network Interdependent Modules of Bank Teller System Bank Customer Bank Teller System Account Manager System Interdependent Modules of Medium Access System Message source Medium Access System Physical Tx/Rx System Process Domain Message source Interdependent Modules of Data Link Control System Message source Data Link System Physical Tx/Rx System Prdef Selecting Communication Mechanisms Having established which other modules a process would interact with, the developer may proceed to decide the communication mechanism that will be used on each interface. A number of communication methods are available; the most commonly used ones are briefly reviewed here. Refer to the Communication 231-Prdef

60 Process Model Development Methodology Modeling Concepts Mechanisms chapter of this manual for more complete information on these options. Packet communication. Packets are messages whose contents are formatted into individual fields that carry information. This is the most common form of interface between modules since it naturally corresponds to the message-based communications that occurs in many networks and distributed systems. Packet communication is a sensible choice for any interfaces that transfer messages in the actual system being modeled. In addition, since packets can store arbitrary user-specified information, they can be used to represent general transactions such as commands between processors, requests for resources, tasks with associated parameters, etc. Note however, that other supported forms of communication may be more appropriate than packets, depending on the application. Packets may be sent to other modules in the same node via connecting packet stream objects, or they may be sent to modules anywhere in a model with packet delivery (see the documentation on op_pk_deliver() and related KPs in the Simulation Kernel manual. Remote interrupt. This is a lightweight form of communications since it does not necessarily transfer a data structure with it, as packet communication does. Remote interrupts may be sent to modules within the same node or in others to indicate simple information such as the status of a semaphore, or value of a variable. In addition, ICIs, which are formatted groups of values, can be associated with remote interrupts to allow them to convey general information to a destination process. This makes remote interrupts suitable for modeling transactions such as requests and indications, parameterized commands, etc. Packets can also be used for many of the same types of tasks as the remote interrupts / ICI combination since they can contain general data. However, ICIs incur less overhead and are generally more appropriate if the data that traverses the interface is confined to the two modules of interest (i.e., does not later progress to other destinations). Note, however, that packets have the additional flexibility of supporting transfer over physical packet streams which implicitly guide the data to a destination that is determined by the configuration of the surrounding node model; this allows the process model to be developed in a more abstract fashion where data is sent out via ports without specific knowledge of which modules will be the destination. Access interrupt: This communication mechanism is used in conjunction with packet communication since it requires the presence of a 232-Prdef

61 Modeling Concepts Process Model Development Methodology packet stream object. Like a packet being sent, an access interrupt is issued by specifying the index of a packet stream, without necessarily having specific knowledge about the object that is connected. However, access interrupts travel backwards on streams, generally to request that a stream s source request a packet. The interrupt is commonly used in configurations where a queue module is a stream source, and the stream s destination module requests packets from the queue; this is referred to as a passive queue configuration and should be used when a process is not able to asynchronously accept packets. Statistic communication: Statistic wires can be placed between module output statistic ports and the input statistic ports of processors and queues. They provide processes in the destination module with a capability to perform live monitoring of the output statistic value. In addition, statistic wires provide triggers which allow asynchronous interrupts to be generated for the destination module when certain patterns of change occur in the monitored statistic. Statistic wires are generally used to alert processes of situations that need attention (such as a queue approaching overflow), or to allow processes to make use of upto-date performance and behavioral information in adaptive algorithms. When designing a module s process models, any combination of the above communication mechanisms may be used with one or more other modules. Three of the four described interface types above make use of physical ports belonging to the module whose processes are under design. If any of these physical interfaces are employed, each port should be assigned a name for reference in later stages of the design. It is generally helpful to depict all interfaces to and from the module of interest, whether physical or abstract, in the node-level diagram that contains the interdependent modules. The names of the physical interfaces should be placed near the associated input and output ports. Process Domain Prdef Application to Examples This section uses each of the four example systems defined earlier in this chapter to illustrate the definition of the physical contexts of processes. Pay Telephone System In the case of the pay-telephone system, packets are the only necessary form of communicated data. ICIs with remote interrupts could be used, but this would require assumptions concerning the outgoing interface to the network, since the pay-telephone process would have to know where the network process is located in order to schedule interrupts for it. By using packets, the pay-telephone process may rely on the outgoing packet stream labeled Network_Transactions_Out to somehow guide the packet to the network process. This packet stream may lead to a process in the same node or to a transmitter that uses a link to reach the network 233-Prdef

62 Process Model Development Methodology Modeling Concepts process in another node; the details of this are not of concern to the pay-telephone process. In addition, the process can receive packets representing actions taken by the user (e.g., coin-deposit, phone number entry) over the packet stream labeled User_Transactions_In. The on-hook or off-hook status of the phone is represented instead by a statistic wire since it is a simple boolean variable; note however, that use of the statistic wire relies on the assumption that the user process is in the same node as the pay-telephone process and that this assumption could be avoided if the on-hook status information were simply incorporated into the packets arriving via User_transactions_In. Responses and status information from the network arrive over the packet stream Network_Transactions_In. The use of a stream here is symmetric with the outgoing interface to the network and preserves the flexibility of placing the network process anywhere. Finally, Line_Status is an outgoing statistic wire that indicates information to the user process such as whether the line is available, and the call-nearly-over warning. Physical Context of Pay Telephone System On_Hook_Status User_Transactions_In Network_Transactions_Out Telephone User Pay-Telephone System Network Line_Status Network_Transactions_In Bank Teller System For the bank teller process, it is assumed that the actions having to do with operation of the various physical devices can be communicated to the customer process via a single packet stream interface called Customer_Transactions_Out. Packets would contain information identifying the affected device and any associated parameters (e.g., device = DISPLAY, text = please enter transaction type ). All other incoming and outgoing interfaces are also based on packet communication to allow placing the processes in arbitrary locations that are selected when the modules are deployed (e.g., the processes could be in different nodes). 234-Prdef

63 Modeling Concepts Process Model Development Methodology Physical Context of Bank Teller System Customer_Transactions_In Bank_Transactions_Out Bank Customer Bank Teller System Account Manager System Customer_Transactions_Out Bank_Transactions_In Medium Access System The medium access system can receive packets submitted for transmission over any number of stream interfaces labeled Src_Traffic_In_0 through Src_Traffic_In_N. When the process decides to send a packet onto the medium it can do so via the outgoing packet stream interface labeled Phys_Traffic_Out. The process also needs to be apprised of two types of status information for the medium. The Medium_Busy_In statistic wire allows the process to determine if the medium is currently carrying any transmissions; the Collision_Status_In statistic wire informs the process if two or more transmissions are simultaneously occurring on the medium. Message source Physical Context of Medium Access System Src_Traffic_In_0 Medium_Busy_In Collision_Status_In Process Domain Medium Access System Physical Tx/Rx System Message source Src_Traffic_In_N Phys_Traffic_Out Data Link Control System The multiple channels of the data-link control system are logical channels so the assumption is made that the messages arrive over one physical interface labeled Src_Traffic_In in the form of packets. The packets must therefore carry some information allowing the process to determine which logical channel they belong to. The mechanism by which packets are actually placed on a particular logical channel is left to the transmission subsystem to which packets are sent by using the 235-Prdef

64 Process Model Development Methodology Modeling Concepts output stream labeled Link_Traffic_Out. Packets arriving from the link are expected on an incoming packet stream labeled Link_Traffic_In. Physical Context of Multi-Channel Data Link Control System Src_Traffic_In Link_Traffic_In Message source Data Link System Physical Tx/Rx System Link_Traffic_Out Prdef.3.3 Stage 2: Process Level Decomposition As described in previous sections of this chapter, each queue or processor module may contain multiple processes, and the number of processes may vary as a simulation progresses. The purpose of this stage of the design procedure is to determine if the behavior of the module of interest should be implemented by a single process model or by multiple process models, and in the latter case, what the function of and relationship between the process models would be. Prdef Decomposition Techniques It is always possible to implement the desired behavior of a module by means of a single process. However, there are many modeling situations that are greatly simplified and more intuitively approached by applying Proto-C s dynamic process paradigm. In general, multiple processes should be used when: 1) The number of processes in the module must scale in response to dynamic requirements. 2) The module must manage multiple tasks that operate asynchronously. 3) A top-down approach is required to reduce complexity or to defer detailed implementation. Replication of Identical Processes This is a common situation in communications systems where a single physical device may be involved in processing a large number of identical ongoing threads. A thread is an ongoing activity that maintains state. Common examples are a telephone call, a virtual circuit in a packet-switched network, or a session of a transport-layer protocol. In modeling computing systems, threads may appear as 236-Prdef

65 Modeling Concepts Process Model Development Methodology programs that are run under a multitasking operating system, or as sub-tasks of those programs. The requirement that a module should execute a dynamic number of processes of the same type is generally quite clear from the specification of a modeling problem. The key system feature associated with this type of scenario is the fact that a variable number of users of the module receive service on an essentially independent basis. A user is not necessarily another module, but should be a source of activities for the module. For example, a single traffic source could generate multiple packets representing initiated telephone calls and attribute them to different users by placing a user identification in a field of the packet. Each call would then be processed independently when it is received by the module of interest. Thus, even though there is only one source module, it acts as a model of multiple users that generate activity for the module being designed. The approach for this type of module is to create a process model that implements a single thread. A higher level process, usually the root, detects conditions that require the initiation of new threads (e.g., a new telephone call request is received) and uses the KP op_pro_create() to create processes to represent them. If a thread evolves to a point where it is no longer needed (e.g. the telephone call parties hang up), it can be terminated with the KP op_pro_destroy(), either by itself or by a master process. Asynchronous Cooperating Tasks Certain processes can be broken down into several smaller processes that operate asynchronously but cooperate to accomplish a common goal. Asynchronous operation refers to the fact that the processes have separate eventprocessing threads that are driven by differing sequences of events. The processes may depend on one another for information and may even generate events for each other; however to be considered asynchronous, at least part of the processes timing should be independent. If instead, all processes are executed in lock-step (i.e., at the exact same times), then they can easily be subsumed into a single process that manages all of their activities. Process Domain Using dynamic processes, Proto-C provides a very natural way to address the modeling of this type of system. The developer must divide the activities of the module of interest into separate functional areas, keeping in mind the guideline that each functional area should have not only different responsibilities, but distinct timing as well. Each functional area can then be implemented by a distinct dynamic process with its own state. The processes may also share information, using the various process hierarchy memory mechanisms described earlier in this chapter. This approach requires delimiting the functional areas by assigning names to them and listing the activities for which each one is responsible. In addition, the relationships between the processes should also be defined in a general fashion at this point to ensure that the functional boundaries that have been selected are feasible. 237-Prdef

66 Process Model Development Methodology Modeling Concepts Top-Down Implementation for Complexity Reduction In general, system designs begin specification with abstract components that represent more detailed functionality to be defined later. While the general purpose of an abstract component is characterized, the internal organization and mechanisms that it uses to accomplish its function is the subject of a later design phase. This design approach is referred to as top-down, and is a natural method because of the fact that system specifications generally begin with capability and performance requirements. Subsystems that operate together to implement these capabilities and meet these performance requirements can then be defined in order to subdivide the design problem. Each subsystem can then be designed individually to meet its own set of requirements. In contrast to design, the activity of modeling assumes that a detailed specification or a reference implementation already exists. The approach of proceeding in a top-down fashion is less critical since there is already knowledge of lower level parts of the system. In addition, if the system model is to be operational (i.e., a simulation of it can be executed) then even the lowest levels of the system must be represented in at least a simplified manner. This implies that the complete deferral of lower level implementation is not possible if meaningful simulations are to be executed. However, top-down implementation can often be an effective tool for reducing complexity by spreading the detail of the model over several levels. For processes based on state transition diagrams (STD), the top-down approach requires the ability to represent lower level STDs within the states of higher level STDs. In Proto-C this hierarchical structure can be supported by invoking a lower-level process model within the executives of an unforced state. The higher-level process must then block until it receives a signal from the lower-level process that the operation for which it was invoked has completed. Proto-C supports a dynamic hierarchy, meaning that the choice of whether a lower-level process or even which low-level process would be invoked can be determined as a function of information that changes over time. This is in contrast to a static hierarchy which would always implement a higher level state using the same lower-level STD. In the methodology presented in this chapter, the top-down approach is used in later steps having to do with decomposition of a process into states and definition of the actions associated with each state. The approach simply suggests that when defining the states of a process, that these states should represent high-level modes of the process and that within them, other processes should be used to implement more specific sub-modes. Prdef Application to Examples In order to illustrate the applicability of process decomposition, this section examines which techniques would best apply to each of the four example systems described earlier in this chapter. 238-Prdef

67 Modeling Concepts Process Model Development Methodology Pay Telephone System The pay telephone system has only one user at a time and interfaces to the network to service the requests of the user. The number of activities that it manages therefore does not vary over time and it does not meet the criteria of having to create dynamic contexts to meet a variable demand. The pay telephone system is also quite simple with regard to distinct activities that it manages. One possible decomposition into multiple processes would have a process managing interactions with the user and another managing interactions with the network. However, there is never any interaction with the network while a phone call is not in progress; in addition, most of the interaction with the network is tightly interwoven with the user interaction, since the pay telephone acts essentially as an intermediary between the two parties. A decomposition would be possible along these lines but would probably result in more coordination overhead than simplification of the system since the two processes would not really be asynchronous. Since no other asynchronous subsystems are readily identified, decomposition into several processes does not seem appropriate. Furthermore, since the system is extremely simple, no large subtasks can be encapsulated into lower-level processes. Therefore the best solution appears to be to represent this system as a single process. Bank Teller System As in the case of the pay telephone system, at most one thread is ongoing at a time. As a result, the use of a variable number of identical processes is not necessary. Also like the pay telephone, the system acts as a go-between two other systems and the interactions with each are closely related; therefore decomposition into two asynchronous processes on this basis would not be beneficial. Process Domain However, a natural breakdown does appear in this process for the three types of supported transactions; namely withdrawals, deposits, and balance verifications. Therefore a high-level process can be constructed that is responsible for authenticating use of the card, and determining the transaction type. Actual implementation of the individual transactions can then be done by invoking the appropriate subprocess. The diagram below shows the basic relationship between these processes. 239-Prdef

68 Process Model Development Methodology Modeling Concepts Hierarchical Process Decomposition for Bank Teller System Invocations performed once transaction type is selected Auth Process that manages authentication and determination of transaction type Withdrawal Deposit Verify Processes invoked to manage three types of transactions In this organization, the process labeled Auth is the most appropriate to act as the root process in the module, since it must always be present to begin new transactions. It would be possible to create the three child processes dynamically to manage transactions as they occur and then to destroy them; however, since only one transaction may occur at a time, there is no need to repeatedly incur the overhead associated with these mechanisms. The approach selected here is to have the Auth process create the three remaining processes as part of its own initialization and to continually reuse the same process instances as required to handle transactions requested by the user. Medium Access System Due to the fact that the system handles medium access for one packet at a time, there is no need for a variable number of identical processes to be created. However, several clearly distinct functional areas appear among the system s activities. 1) Acceptance and queueing of arriving messages. 2) Transmission management for the earliest enqueued message. 3) Monitoring the medium to determine appropriate times for transmission. These three activities have some relationship to each other and must therefore be determined to operate asynchronously in order to form an appropriate decomposition of the system. If the system is idle (i.e., no packet is waiting to access the medium) then the queue-management process must inform the 240-Prdef

69 Modeling Concepts Process Model Development Methodology transmission management process immediately when a packet arrives. The transmission management process must also receive information from the medium-monitoring process whenever a collision occurs so that it can abort its transmission. In addition, the status of the medium s usability must be available at all times to the transmission management process in order to decide when to initiate transmission attempts. Note that the medium-monitoring process must be running at all times, independently of the other processes, in order to be able to accurately determine the times at which the medium becomes usable. In addition, the queuemanagement process may be required to accept and enqueue many packets during the period required for the transmission process to successfully transmit just one packet; this queueing activity is a background task that has no effect on the transmission process except under one special circumstance noted above. The three activities therefore seem loosely coupled enough that they form a proper decomposition of the system into three asynchronously operating processes. This decomposition appears in the following diagram. Medium_Mon must determine at what times the medium becomes usable and unusable Asynchronous Cooperating Process Decomposition for Medium Access System Q_Mgr is responsible for enqueueing newly arriving messages Medium_Mon Q_Mgr Tx_Mgr Q_Mgr notifies Tx_Mgr when new packet arrives, if Tx_Mgr is idle Tx_Mgr is responsible for successfully completing the transmission of a message Process Domain Medium_Mon notifies Tx_Mgr when appropriate changes in medium status occur Any of the three processes could play the role of root. However, note that the Medium_Mon process must be present from the beginning in order to compute the usability of the medium which must be available at all times. If this process started later then it may not be known if the medium was busy in the early moments of the simulation, making it impossible to determine exactly at what time it should become usable for transmission. Also, the Q_Mgr process should be present at all times in order to handle the arrival of the first message. Only the Tx_Mgr process 241-Prdef

70 Process Model Development Methodology Modeling Concepts stands out as not being necessary in the initial moments since it can easily be created by the Q_Mgr once the first message arrives. Therefore, either Medium_Mon or Q_Mgr should be used as the module s root process. The approach selected here is to use the Q_Mgr process as root and to create the Medium_Mon process immediately. Subsequently, the Tx_Mgr process will be created by Q_Mgr upon receipt of the first message for transmission. Data Link Control System This system may involve the management of activities for a number of logical channels and this number may change over time. Furthermore, each logical channel can be considered to exist as a thread in the sense that it maintains state (e.g., the packet that has to be retransmitted) and requires activities to be continued over a period of time. Each logical channel can therefore be managed by an independent but identical process that is concerned only with the events that affect its channel. A process is also required to accept new messages that are submitted for transmission and to receive acknowledgments from the remote destination since there is not a priori reason to route these directly to any particular process. Since all of the channel-management processes play a symmetric role, and since a single process acts as a dispatcher of messages to the channel-management processes, it is a natural decision to appoint the dispatcher process as root. This process can in addition be responsible for creating the channel-management processes when a request is submitted for a channel that is not yet known. The organization of these processes is shown in the diagram below: Decomposition of Data Link Control System into a Scalable Number of Dynamic Processes Dispatcher invokes (and first creates if necessary) appropriate Channel_Mgr process to handle arriving messages and acknowledgments. Dispatcher Channel_Mgr Channel_Mgr Channel_Mgr Channel_Mgr processes perform the required protocol for packets assigned to their respective logical channels. They do not interact with each other. 242-Prdef

71 Modeling Concepts Process Model Development Methodology Prdef.3.4 Stage 3: Enumeration of Events This stage of the design methodology is performed for each process defined in the process decomposition stage, rather than for the system as a whole. Generally, a process assumes some or all of the functions of the system in which it is located by performing actions and modifying state information in response to logical events. A logical event (as opposed to an ordinary OPNET event) is an occurrence that requires the intervention of the process. The purpose of the event enumeration stage is to construct a complete list of the logical events that can affect the process of interest. The actual actions that are taken in response to these interrupts are the topic of a later stage in the methodology. Prdef Identifying Logical Events A process may be called upon to respond to an interrupt either directly by the Simulation Kernel or by another process within the same process hierarchy. In both cases, however, an event must first occur for the module that encompasses the process. The Simulation Kernel then chooses a process to receive the interrupt directly (the technique used to control which process is invoked directly is called interrupt steering and is described in detail the Modeling Framework chapter of this manual). This process may in turn cause other processes to be invoked by calling the Kernel Procedure (KP) op_pro_invoke(). The first goal of this stage is simply to determine which logical events a process must be prepared to receive. The actual type of the corresponding interrupts or the way in which they are communicated is not important at this time; rather the causes of the interrupts and the sources from which they came must be identified. Each logical event should be assigned a descriptive name and placed in a list. Process Domain Logical events may be generated from three types of sources: (1) modules outside the local system; (2) other processes within the same module; (3) the process itself. Unfortunately, there is no general method for determining the interrupts of a process; however, the activities of the encompassing system as a whole and the interactions of the system are a good starting point. Not all of the interrupts that affect the encompassing system will necessarily affect the process of interest, but the irrelevant interrupts can easily be sorted out. The developer should take into account interrupts that cause a direct invocation of other processes, provided that these processes directly or indirectly invoke the process of interest. In particular, other processes may generate interrupts for themselves and in handling those interrupts, invoke the process by calling op_pro_invoke(). Of course, self interrupts generated by the process for itself must also be identified, and the event of creation is also important for some processes (for root processes, this event occurs at the beginning of the simulation). 243-Prdef

72 Process Model Development Methodology Modeling Concepts Prdef Determining Event Implementation Methods The previous section identified the significance of the events; this section discusses the manner in which the logical events are actually implemented in the simulation model. The logical events that affect a process must manifest themselves as interrupts delivered to the process by the Simulation Kernel, or as invocations of the process by other processes within the same surrounding module. In both cases, an interrupt must have been delivered to one of the processes in the module for a logical event to occur. While the significance of events varies widely and is dependent on the modeling application, OPNET supports only a small, finite set of interrupt types with which to implement these events. As a result, it is generally quite simple to select an appropriate type of interrupt to represent each logical event expected by a process. In addition, certain decisions made in the initial stage of this modeling process provide information that is helpful here. Namely, the context definition stage suggests communication mechanisms that should be used for the interactions that the system has with other module and the choice of a communication mechanism usually implies a particular interrupt type (e.g., packet-based communication indicates stream interrupts are used). Also, certain types of logical events are usually represented using particular types of well-suited OPNET interrupts. The following table provides a general correspondence between some commonly encountered types of logical events and OPNET interrupt types. See the Modeling Framework chapter of this manual for a comprehensive description of each interrupt type and possible uses. Common Logical Events and Usual Corresponding Interrupt Types Logical Event Creation of process Expiration of timer Receipt of message Receipt of command to perform an action Change in status of other module Request to forward a packet to neighboring module Change in operability status of a network-level object (node or link) Interrupt Type begin simulation interrupt for root process; general for others self interrupt stream interrupt remote interrupt or stream interrupt, depending on how command is represented statistic interrupt or remote interrupt, depending on whether the other module is in the same node access interrupt failure interrupt, recovery interrupt 244-Prdef

73 Modeling Concepts Process Model Development Methodology Prdef Application to Examples This section discusses the application of the event enumeration stage to the four example systems described earlier in this chapter. Pay Telephone System Most events can be easily extracted from the system definition, since most of the action descriptions depend on the occurrence of particular conditions. In the case of the pay telephone system, the events that are apparent include indications of actions taken by the user and signals sent by the network. In addition, note that the network provides a warning some time before the call must be disconnected, but no final disconnect signal; this event must therefore be generated internally (e.g., as a self interrupt). All the anticipated events of the process appear in the following table together with the interrupt types selected for their implementation. Logical Events for Pay Telephone Process Event Name Event Description Interrupt Type User_Pickup User takes handset off hook statistic User_Hangup User replaces handset on hook statistic User_Add_Fare User deposits money stream User_Tel_Num User dials telephone number stream Net_Dial_Tone Network provides dial tone stream Process Domain Net_Connect Net_Fare_Low Disconnect Network indicates call has gone through and whether call is tollfree Network warns that money has nearly run out Money has completely run out and call must be terminated stream stream self Bank Teller System The description of the bank teller system does not make the set of events as clear as in the case of the previous example. However, some of the events are implicit in the activities that are described. For example, if the customer can select between three transaction types, there must be an event which corresponds to the customer completing a selection. Also, insertion of the bank card and identification number correspond to two separate events. The account manager also generates events for authentication of the card and ID number, and approval of each 245-Prdef

74 Process Model Development Methodology Modeling Concepts transaction. In addition, an event must be generated to allow a customer to cancel a transaction in progress. Since this system uses four processes, each process logical events must be enumerated separately. The following tables summarize the logical events expected by each process and the interrupt types that are used to implement them. Logical Events for Auth Process of Bank Teller System Event Name Event Description Interrupt Type Cust_Card_Ins Cust_ID_Entered Cust_Trans_Sel Cust_Trans_Cancel Bank_Auth Bank_Reject Cust_Trans_Over Card has been inserted by customer Customer has typed in personal identification number Customer has selected one of three transaction types Customer has decided to cancel transaction (may happen at any time) Bank has authorized use of card based on ID number Bank has denied use of card based on ID number Customer transaction has completed stream stream stream stream stream stream invocation by corresponding child process Logical Events for Withdrawal Process of Bank Teller System Event Name Event Description Interrupt Type Cust_Amount_Entered Bank_Trans_Approval Cust_Trans_Cancel Customer has entered an amount needed for withdrawal transaction Bank has authorized completion of transaction Customer has decided to cancel transaction (may happen at any time) stream stream stream 246-Prdef

75 Modeling Concepts Process Model Development Methodology Logical Events for Deposit Process of Bank Teller System Event Name Event Description Interrupt Type Cust_Amount_Entered Cust_Deposit_Inserted Cust_Trans_Cancel Customer has entered an amount needed for deposit transaction Customer has inserted deposit documents through deposit door Customer has decided to cancel transaction (may happen at any time) stream stream stream Logical Events for Verify Process of Bank Teller System Event Name Event Description Interrupt Type Bank_Balance_Rcvd Cust_Trans_Cancel Balance information has been received from bank Customer has decided to cancel transaction (may happen at any time) stream stream Process Domain Medium Access System This system relies on three processes, each of which is driven by a separate set of logical events. The root process is Q_Mgr, which is responsible for inserting newly arriving packets in the queue, where they will wait to be processed by the Tx_Mgr process. Q_Mgr s logical events appear in the table below. Logical Events for Q_Mgr Process of Medium Access System Event Name Event Description Interrupt Type Process_Create New_Message Initial event provided to allow initialization of process A message has been submitted to the module for transmission onto the medium begin simulation stream 247-Prdef

76 Process Model Development Methodology Modeling Concepts The Medium_Mon process is responsible for determining the usability of the medium based on the activity of the recent past. It must therefore be notified each time that a change in the medium s status occurs. In addition, the processes must be notified once the medium has been idle for Gap_Time seconds. Its logical events are shown below. Logical Events for Medium_Mon Process of Medium Access System Event Name Event Description Interrupt Type Process_Create Busy_High Busy_Low Gap_Elapsed Initial event provided to allow initialization of process The medium s status has changed from free to busy The medium s status has changed from busy to free The medium has been free for Gap_Time seconds, meaning that it has become usable for transmission invocation by Q_Mgr process statistic statistic self The third and most complex process in this system is the Tx_Mgr process, which must manage, across repeated attempts if necessary, the transmission of the message onto the medium. This process may be invoked to begin transmission of a new message, or for various events that may occur during the transmission of a current message. Note that the process must use a self interrupt to know when its own transmission has completed so that it can begin another, if required. The complete set of logical events for Tx_Mgr appear in the following table: Logical Events for Tx_Mgr Process of Medium Access System Event Name Event Description Interrupt Type Process_Create New_Message Medium_Usable Initial event provided to allow initialization of process New message has been submitted for transmission The medium has been free for at least the required gap time between messages, meaning that a transmission may begin invocation by Q_Mgr process invocation by Q_Mgr process invocation by Medium_Mon process 248-Prdef

77 Modeling Concepts Process Model Development Methodology Logical Events for Tx_Mgr Process of Medium Access System (Cont.) Event Name Event Description Interrupt Type Tx_Complete Tx_Collided Backoff_Elapsed Current transmission has completed without a collision Current transmission overlapped with another transmission on the medium The random backoff period following a collision has elapsed, allowing a new transmission attempt self statistic self Data Link Control System This system uses two processes, with the root acting essentially as a dispatcher by routing arriving messages to the appropriate Channel_Mgr child process. The root process uses the model Dispatcher and responds to message arrivals from the message source and to acknowledgment messages returned from the remote site via the link. No events are generated internally, since dispatching is assumed to take no time to perform and this is the only activity. The logical events of Dispatcher are shown below: Logical Events for Dispatcher Process of Data Link Control System Process Domain Event Name Event Description Interrupt Type Process_Create Src_Message_Arrival Link_Message_Arrival Initial event provided to allow initialization of process Message has arrived from traffic source to be queued for transmission with appropriate channel manager An acknowledgment has been received from one of the channels, to be handed to the appropriate channel manager begin simulation stream stream Because the Dispatcher process has no other function than to create and invoke channel manager processes, the events in the table above also appear in the event table of the Channel_Mgr process. In addition, each Channel_Mgr must internally generate timer events to initiate retransmissions of unacknowledged messages, as shown below. 249-Prdef

78 Process Model Development Methodology Modeling Concepts Logical Events for Channel_Mgr Process of Data Link Control System Event Name Event Description Interrupt Type Process_Create Src_Message_Arrival Link_Message_Arrival Ack_Timeout Initial event provided to allow initialization of process Message has arrived from traffic source to be queued for transmission An acknowledgment has been received from remote process Timer has expired while waiting for acknowledgment message from destination in order to support retransmission invocation by Dispatcher process invocation by Dispatcher process invocation by Dispatcher process self Prdef.3.5 Stage 4: State-Level Decomposition of Processes This stage of the methodology is performed for each process that has been defined within a system. State decomposition forms the basis of a state transition diagram (STD) that represents a Proto-C process. Prdef Criteria for Defining States The goal in this stage is to define a set of discrete states that will later be connected with transitions to form an STD. At this point only the states need be identified and if possible, the specific conditions for transitions should be examined in a later stage of development. The following guidelines should be used in selecting states: A state should correspond to a mode of the process in the sense that only particular sequences of events are able to bring the process into that state. A state is characterized by the fact that events are handled a particular way as a result of the process being located in that state. The combination of states should form a mutually exclusive, complementary set, such that the process always occupies exactly one of the states. A state should represent a resting place for a process, meaning that the process should be able to wait in the state for new interrupts to oc- 250-Prdef

79 Modeling Concepts Process Model Development Methodology cur. This implies that the states that are defined in this step of the methodology should not be used simply to specify actions, and therefore are not the forced states of the process. Forced states are a convenient feature for graphically representing control-flow and are considered at a later stage. Note that, as its name implies, a state represents part of the memory of a process since it reflects the path that the process has taken to reach it. However, not all of the memory of a process need be reflected by the state that it occupies, due to the fact that Proto-C provides state variables. Thus, states can be used to represent logical modes of the system that are distinguished primarily by differences in the events that are expected and the way events are processed. Prdef Application to Examples Other than the criteria for state definition provided in the previous section, there is no general method that always yields an efficient set of states of a process. In some modeling problems, processes are already described as STDs in the system specification, making the selection of states straightforward. However, if this is not the case, the developer must try to select a set of states by analyzing the activities of the process and the events that occur. When state selection is not obvious, one possible approach is to begin analysis with an initial state where the process would be located when it is created. Possible events that could occur while the process is in this state should then be considered one at a time; each event may lead to a new state that reflects its occurrence, unless a state already exists that represents an appropriate response to the event. In this way new states are defined, and event analysis can be performed again for the new states until there is no need to create additional states. Process Domain This section illustrates state decomposition by enumerating possible state sets for the processes of the four example systems defined earlier in this chapter. Pay Telephone System This system is implemented as a single process which must therefore respond to all possible events received by the system. These events were identified in the previous stage of the methodology. Examining the events suggests that the process follows a direct path through a predictable sequence of actions, as follows: (1) process is in idle state; (2) user picks up phone; (3) user deposits money; (4) network provides dial-tone; (5) user dials telephone number; (6) network establishes connection and indicates if fare is free; (7) conversation takes place; (8) user hangs up or money runs out; (9) call disconnected. This sequence of actions does not represent the states of the process but provides a good starting point for discovering them. The key is to recall that states should represent intervals of time for the process between actions; this leads to the following set of states based on the above sequence: 251-Prdef

80 Process Model Development Methodology Modeling Concepts States for Pay Telephone Process State Name Idle Deposit_wait Tone_wait Dial_wait Connect_wait Connect_estab Disc_ct_down State Description Waiting for phone call to be initiated by a user. Waiting for deposit to be made. Waiting for dial-tone to be provided by network so that user can begin dialing. Waiting for user to complete dialing so that connection can be established. Waiting for a connection to be established and for indication of whether call is toll-free. Connections has been established and conversation is ongoing; waiting for the user to terminate by hanging up or for the network to notify that money has almost run out. The warning has been received that money has nearly run out. A count down towards a disconnect is occurring; the user may avert this by depositing more coins. Bank Teller System The bank teller system is composed of four processes for which states must be defined. The root process is called Auth and is responsible for the initial phases of a customer s transaction with the teller. Specifically, Auth must obtain the user s card and ID number and have them validated by the bank; then it must determine the type of transaction the user desires and start the appropriate child process to manage that transaction. These phases correspond to the states listed below. States for Auth Process of Bank Teller System State Name State Description Idle ID_wait Auth_wait Select_wait Trans_compl_wait Waiting for customer to engage automatic bank teller by inserting card. Waiting for customer to enter personal identification number. Waiting for authorization and account handle to return from bank. Waiting for user to select transaction type. Waiting for selected transaction to complete or to be canceled. 252-Prdef

81 Modeling Concepts Process Model Development Methodology The transaction management processes Deposit, Withdrawal, and Verify are simple processes that sequence a small number of events. Note that two approaches can be selected with regard to the creation of these processes: they may be created when the system initializes and be viewed as permanent resources, like subroutines in a program; or they may be created dynamically for each transaction and then destroyed when the transaction completes. In the former case, the processes would need an additional state which they would occupy while waiting for a transaction to begin. The second approach is selected in this case, thereby allowing the processes to assume that they are in the midst of handling a transaction. The states for the three processes appear in the following tables. States for Withdrawal Process of Bank Teller System State Name Amount_wait Auth_wait State Description Waiting for user to enter amount to be withdrawn from account. Waiting for bank to approve withdrawal of specified amount. State Name Amount_wait Insert_wait States for Deposit Process of Bank Teller System State Description Waiting for user to enter amount to be deposited to account. Waiting for customer to physically deposit envelope through deposit door. Process Domain States for Verify Process of Bank Teller System State Name Balance_wait State Description Waiting for bank to acknowledge transaction and simultaneously return balance information. Medium Access System The medium access system makes use of three asynchronously operating processes called Q_Mgr, Medium_Mon, and Tx_Mgr to control transmissions. Once created, the Q_Mgr process expects only one type of logical event representing a message arrival. Each arriving message is processed independently of the previous ones, so the process has only one mode, as shown in the following state table: 253-Prdef

82 Process Model Development Methodology Modeling Concepts States for Q_Mgr Process of Media Access System State Name Message_wait State Description Waiting for a message to be submitted to the media access system. The Medium_Mon process is responsible for determining when the medium becomes usable and when it ceases to be usable. In order to do this, the process must time the silent periods on the medium and when a fixed silent interval has occurred, the medium can be declared to be usable. The logical events used in this decision process are the medium going busy, the medium going idle, and the silence interval elapsing, as described in the event enumeration stage of the methodology. These three events suggest a natural decomposition into three states, as follows: States for Medium_Mon Process of Media Access System State Name Medium_usable Medium_busy Gap_elapse_wait State Description Medium is usable for new transmissions due to having been idle for at least Gap_Time seconds. Medium is currently busy (and therefore not usable for new transmission). Medium has changed from busy to free within last Gap_Time seconds and therefore is still not usable. Initially, the Tx_Mgr process has no messages to transmit and may later return to this condition after having completed transmissions if its input queue is empty. Thus, a state to represent this idle mode is required. Once a transmission begins, it can move through several phases: waiting for a usable medium; waiting to determine the status of a transmission; and if a collision has occurred, waiting for the random backoff timer to expire. These lead to the following state table: States for Tx_Mgr Process of Media Access System State Name State Description Idle Medium_wait No transmissions are in progress; input queue is empty. Waiting for medium to become available, at which point a transmission can be initiated. 254-Prdef

83 Modeling Concepts Process Model Development Methodology States for Tx_Mgr Process of Media Access System (Cont.) State Name Tx_status_wait Backoff_wait State Description Waiting to learn if transmission was successful or if a collision occurred. A collision occurred and the backoff interval is currently counting down; waiting for this interval to complete so that the transmission may be reattempted. Data Link Control System The multichannel data link control system uses a Dispatcher process to route arriving messages to the appropriate child process, which is of type Channel_Mgr. The routing is performed based on each message s logical channel ID, independently of previous messages. The Dispatcher process has only one mode which is to wait for the next arriving message, process it and wait again. Its state table appears below. States for Dispatcher Process of Data Link Control System State Name Message_wait State Description Waiting for a message to be submitted to the data link control system, either from the source or from the link. The Channel_Mgr process is more complex since each message that is handled follows a progression including a transmission phase, possible retransmissions, and an acknowledgment phase. In addition, queueing of new messages must be performed on an asynchronous basis (a second process might have been defined for this purpose as was done for the media access system; however, here this activity is simply performed as a background task in each state of the channel manager). A possible state table that supports these phases is shown below: Process Domain States for Channel_Mgr Process of Data Link Control System State Name State Description Idle Ack_wait No messages are available to transmit and no acknowledgments are pending; the process is waiting for a new message to arrive from the traffic source. A message has been transmitted and an acknowledgment is awaited; a timer may expire to indicate need for retransmission. 255-Prdef

84 Process Model Development Methodology Modeling Concepts Prdef.3.6 Stage 5: Developing the State Transition Diagram At this milestone, the states of each process have been defined. In addition, the set of logical events that require a response on the part of each process have been identified. The purpose of this stage is to combine these two sets of data in order to form the basic state transition diagram (STD). Prdef Determining the Feasible Events of a State For most process models, it is only possible for a subset of the logical events to occur while the process is located in a given state. This is generally due to the fact that the involvement of the process itself is required in the interactions that result in the event. For example, the authorization process of the Bank Teller System cannot expect the user to select a transaction type while it occupies the state where the card s insertion is awaited, because the menu of possible transactions has not been presented yet. To avoid including infeasible transitions in the STD, this methodology characterizes each event with respect to each state, using three categories: infeasible, suppressed, and feasible. Infeasible events are those that have no possibility of occurring due to the particular circumstance that the process finds itself in when occupying a given state, such as the Bank Teller System example mentioned above. Suppressed events are those that would have the physical possibility of occurring but that provide no useful information to the process. In the interest of efficiency and simplification, invocations of the process should be avoided for these state-event combinations. Various suppression mechanisms for interrupts are available and are discussed in other sections of this chapter. What is relevant at this stage in the methodology is not how to suppress these events, but simply to make the assumption that they will not occur. It is useful to sort them out now in order to support the work that will later be required in order actually implement their suppression. Feasible events are those that are not only possible to receive, but that the process may have a use for while occupying a particular state. These events form the basis for the definition of transitions in the STD. The first step of this stage consists in constructing a table that maps logical events against states of the process. By systematically listing each logical event for each state, the developer can ensure that no important events will be ignored in the design of the STD (ignoring an event can later lead to simulation errors). For each state-event combination, one of the three feasibility categories above should be assigned. The following table provides an example of such a table for the case of 256-Prdef

85 Modeling Concepts Process Model Development Methodology the media access system s Tx_Mgr process. The feasible events are highlighted since these are the principal ones of interest in the subsequent steps of this design stage. Feasible Events for States of Tx_Mgr Process State Name Logical Event Feasibility Idle New_Message feasible Medium_Usable Tx_Complete Tx_Collided Backoff_Elapsed suppressed infeasible suppressed infeasible Medium_wait New_Message suppressed Medium_Usable feasible Tx_Complete infeasible Tx_Collided suppressed Backoff_Elapsed infeasible Tx_status_wait New_Message suppressed Medium_Usable suppressed Process Domain Tx_Complete Tx_Collided Backoff_Elapsed feasible feasible infeasible Backoff_wait New_Message suppressed Medium_Usable Tx_Complete Tx_Collided Backoff_Elapsed suppressed infeasible suppressed feasible Prdef Constructing an Event Response Table Processes are driven by the occurrence of logical events. Once a logical event is received, the process has the opportunity to carry out a sequence of five steps as follows: 257-Prdef

86 Process Model Development Methodology Modeling Concepts 1) Actions may be performed by the exit executive statements of the unforced state that is currently occupied. 2) The condition statements are evaluated for all of the outgoing transitions of the currently occupied state. 3) Actions may be performed by the executive statement of the transition that is selected (i.e. the one that evaluates to a TRUE boolean value). 4) The process follows the transition and occupies a (possibly) new state. 5) Actions may be performed by the enter executives of the new state. At this stage of model development, only unforced states of the STD have been considered. Forced states can be introduced later to improve model appearance, or consolidate redundantly specified actions; however, they do not alter the fundamental structure and timing of the model, which are provided by the unforced states and their transitions. Since transitions from unforced states always correspond to the occurrence of an event, the state-event combinations serve as a good starting point for defining the STDs transitions. Only feasible events need be considered since other events are assumed never to occur while in particular states. The suggested approach to determining the STDs transitions is to generate a table, known as an event response table, that describes the process possible courses of action for each feasible state-event pair. The table lists every feasible state-event pair in the two left columns. For each such pair, at least one transition will be defined; in addition, it is possible that several transitions would be applicable provided that they are differentiated by additional requirements in their condition statements (recall that the conditions of all transitions departing from a state must be mutually exclusive). If the process must have the ability to transition differently or to perform substantially different actions, based on the fulfillment of certain conditions at the time the event occurs, then these conditions must be characterized in the table; general English-like statements of these conditions should be entered in the third column of the table, called condition. The next column, labeled Action, represents any activity that must be performed as a result of the transition taking place. Depending on the exact nature of the action, it could be implemented as part of the current state s exit executive statements, as part of the transition s executive, or in the next state s enter executives; this issue is addressed in later stages and does not need to be specified in the table. Finally, the Next State column specifies which state the process should occupy next due to the occurrence of the event and the condition being true. The resulting table for the Tx_Mgr process of the Media Access System appears below. 258-Prdef

87 Modeling Concepts Process Model Development Methodology Event Response Table for Tx_Mgr Process Current State Logical Event Condition Action Next State Idle New_Message medium is usable begin transmission medium is not usable Medium_wait Medium_Usable begin transmission Tx_status_wait Medium_wait Tx_status_wait Tx_status_wait Tx_Complete queue is empty Idle queue is not empty and medium is usable queue is not empty and medium is not usable begin transmission Tx_status_wait Medium_wait Tx_Collided abort transmission; begin backoff Backoff_wait Backoff_Elapsed medium is usable begin transmission medium is not usable Backoff_wait Tx_status_wait Medium_wait Process Domain Prdef Defining Transitions This section introduces methods for defining transitions that will be used in the subsequent section where construction of the STD begins. No diagrams or tables need be generated from the information presented here. As mentioned earlier, each logical event that is feasible in a given state must be handled by at least one outgoing transition of that state. One possible approach to defining the transitions of the STD is to consider each row of the event response table and to create a transition that matches its specifications. For example, consider a row defined as follows: Current State Logical Event Condition Action Next State S 0 E C S 1 Then a transition could be defined between two states to express the following: if the current state is S 0, and the logical event E occurs, and the condition C holds, 259-Prdef

88 Process Model Development Methodology Modeling Concepts then the process should move to occupy state S 1. In Proto-C, as in the C and C++ languages, the operators && (two ampersand characters) and (two vertical bars) are used to express the logical operations AND and OR, respectively. Therefore, the transition would appear as follows in a Proto-C diagram. Representation of a Generic Transition in an STD The expression E represents the occurrence of logical event E All transitions in an STD could be represented in this straightforward manner in order to encode all of the control-flow information in the event response table. However, there need not always be a one-to-one correspondence between logical events and transitions at a given state. There are two general forms that can be extracted from the event response table to express transition conditions: 1) A single transition may handle a union of multiple logical events. If in a given state of a process there are multiple feasible logical events, then it is possible for several of these events to cause a transfer to the same destination state. Proto-C supports the use of multiple transition objects to represent such situations; however, in order to reduce the complexity of STD, this methodology recommends using a single transition with a condition statement that represents a union of the individual logical events and conditions. Thus if three separate logical events E 0, E 1, and E 2 cause a transfer to the same state, and each one has an associated condition C 0, C 1, and C 2, respectively, then a single transition can be defined, triggered by the condition (E 0 && C 0 ) (E 1 && C 1 ) (E 2 && C 2 ). This example is depicted below. Transition Formed from the Union of Logical Events 260-Prdef

89 Modeling Concepts Process Model Development Methodology 2) Handling of a single logical event may be split between multiple transitions. The format of the table makes it clear that occurrences of the same logical event while in the same state may be differentiated by condition statements which are evaluated at the time of the event. For each condition statement, a different next state may be specified, thereby implicitly defining multiple transition objects. A situation of this type is depicted below for generic states, events, and conditions. Current State Logical Event Condition Action Next State S 0 E 0 C 0 None S 1 C 1 None S 2 C 2 None S 3 Logical Event Handled by Multiple Transitions with Differing Conditions Process Domain The Tx_Mgr process provides a good illustration of the use of conditions to subdivide the handling of a single logical event. For instance, the table shows that in the Tx_status_wait state, the process may handle the receipt of a Tx_Complete event in three different ways, depending on the emptiness of the queue and the status of the medium. Prdef Assembling the STD Once the event response table is defined, the STD can easily be assembled in OPNET s Process Editor. First, the states must be created and assigned names from the left column. The location of the states is not important, but depending on which transitions exist between them, certain arrangements can result in a cleaner looking diagram. Also, abbreviated state names are usually used because the states have only a small display window. 261-Prdef

90 Process Model Development Methodology Modeling Concepts Once the states have been placed, transitions may be drawn between them based on the methods presented in the previous section. When a transition is created, it has an empty condition statement, which is indicated graphically by a solid path (as opposed to a dashed path for transitions with non-empty conditions). Since variables have not been defined at this point and logical events are still treated conceptually (i.e., their specific method of implementation has not been decided), macros should be used to express the condition statements. The macros can be English-like text strings (no whitespace or special characters, except underscore) that provide descriptive labels for the transitions. The underlying definitions of the macros, which ultimately must implement the condition statements, can be provided in the process header block at a later time. The resulting STD for the Tx_Mgr process appears below. State Transition Diagram for Tx_Mgr Process 262-Prdef

91 Modeling Concepts Process Model Development Methodology Transition Condition Macros for Tx_Mgr STD Macro NEW_MSG MEDIUM_USABLE TX_OK Q_EMPTY TX_COLLIDED BKOFF_OVER Meaning A new message has arrived The medium is usable (i.e., it has been unused for Gap_Time sec.) A transmission has completed successfully (no collisions) There are no messages waiting to begin the transmission process The current transmission has experienced a collision The backoff period has elapsed Prdef Note that even when there is only one outgoing transition from a state, as in the case of the state MEDIUM, that transition still has an associated condition. This condition is not strictly necessary since the process could assume that the correct event always occurs; however, including the condition allows the simulation to provide a warning if for some reason an unanticipated event occurs and the condition is false. This is preferable to falsely interpreting such an event. Application to Examples This STD stage of the methodology was applied to the Tx_Mgr process of the Media Access System in the previous sections in order to illustrate the construction of an event response table and the derivation of the STD. This section presents complete tables and STDs for the remaining example models that were defined earlier in this chapter. Process Domain Pay Telephone System The STD for this process reflects the serial nature of the user s progression through the various phases of call establishment. There is a loop between the Call_Estab and Disc_Ct_Down state, due to the fact that the phone user can always add change to continue the call. Also, every state has a transition back to the Idle state, reflecting the fact that the user may hang up the phone at any time. Most transitions are based on simple logical events; only the transition back to Idle from Disc_Ct_Down is driven by the union of two events (i.e., either can occur to cause this transition to be traversed). 263-Prdef

92 Process Model Development Methodology Modeling Concepts Event Response Table for Pay Telephone Process Current State Logical Event Condition Action Next State Idle User_Pickup None None Deposit_wait Deposit_wait User_Hangup None None Idle User_Add_Fare None send indication of deposited amount to network Tone_wait Tone_wait User_Hangup None refund deposit Idle Net_Dial_Tone None None Dial_wait Dial_wait User_Hangup None refund deposit Idle User_Tel_Num None relay telephone number to network Connect_wait User_Hangup None refund deposit; relay cancellation to network Connect_wait Idle Net_Connect None None Connect_Estab Connect_Estab User_Hangup None relay cancellation to network Net_Fare_Low None start timer for disconnect Disc_Ct_Down User_Hangup None relay cancellation to network Disconnect None relay cancellation to network User_Add_fare None send indication of deposited amount to network Idle Disc_Ct_Down Idle Idle Connect_Estab 264-Prdef

93 Modeling Concepts Process Model Development Methodology State Transition Diagram for Pay Telephone Process Bank Teller System The Auth process of the Bank Teller System has a flow that strongly resembles that of the pay telephone system process described above. This could be expected since in both cases, the process guides the user through a series of data entries in order to get to a phase where a transaction is established. This process also offers the possibility of cancellation by the user at any time, which is reflected by the transitions to the Idle state from all other states Process Domain. Event Response Table for Auth Process of Bank Teller System Current State Logical Event Condition Action Next State Idle Cust_Card_Ins None prompt user for ID number ID_wait Cust_Id_Entered None send card info and ID to bank for authentication ID_wait Auth_wait Cust_Trans_Cancel None return card Idle Auth_wait Bank_Auth None prompt for transaction type Select_wait Bank_Reject None return card Idle Cust_Trans_Cancel None return card Idle 265-Prdef

94 Process Model Development Methodology Modeling Concepts Event Response Table for Auth Process of Bank Teller System (Cont.) Current State Logical Event Condition Action Next State Select_wait Cust_Trans_Sel None invoke appropriate transaction process Trans_compl_wait Cust_Trans_Cancel None return card Idle Trans_compl_wait Cust_Trans_Over None return card Idle Cust_Trans_Cancel None return card Idle State Transition Diagram for Auth Process The Withdrawal, Deposit, and Verify processes are very simple, requiring at most one action to be taken by the user to progress to their final state. Note that since these processes destroy themselves when receiving an event in their final state, departing transitions need not be defined. Also, the Cust_Trans_Cancel event always leads to destruction of the process, and therefore is not implemented by any transitions. Event Response Table for Withdrawal Process of Bank Teller System Current State Logical Event Condition Action Next State Amount_wait Cust_Amount_Entered None send request to bank Cust_Trans_Cancel None notify parent that transaction is over; destroy process Auth_wait none (process is destroyed) 266-Prdef

95 Modeling Concepts Process Model Development Methodology Event Response Table for Withdrawal Process of Bank Teller System (Cont.) Current State Logical Event Condition Action Next State Auth_wait Bank_Trans_Approval None disburse cash; notify parent that transaction is over; destroy process Cust_Trans_Cancel None notify parent that transaction is over; destroy process none (process is destroyed) none (process is destroyed) State Transition Diagram for Withdrawal Process Event Response Table for Deposit Process of Bank Teller System Process Domain Current State Logical Event Condition Action Next State Amount_wait Cust_Amount_Entered None open deposit door Insert_wait Cust_Trans_Cancel None notify parent that transaction is over; destroy process Insert_wait Cust_Deposit_Inserted None close deposit door; notify parent that transaction is over; destroy process Cust_Trans_Cancel None notify parent that transaction is over; destroy process none (process is destroyed) none (process is destroyed) none (process is destroyed) 267-Prdef

96 Process Model Development Methodology Modeling Concepts State Transition Diagram for Deposit Process Event Response Table for Verify Process of Bank Teller System Current State Logical Event Condition Action Next State Balance_wait Bank_Balance_Rcvd None display balance; notify parent that transaction is over; destroy process Cust_Trans_Cancel None notify parent that transaction is over; destroy process none (process is destroyed) none (process is destroyed) State Transition Diagram for Verify Process Medium Access System The Q_Mgr process is exceedingly simple, operating in a continuous one-state loop driven by message arrivals. At each arrival, a decision is made about whether to enqueue the message, or invoke the Tx_Mgr process; however the transition is always back to the same state. Event Response Table for Q_Mgr Process of Medium Access System Current State Logical Event Condition Action Next State Message_wait New_Message Tx_Mgr is handling a message Enqueue message Message_wait New_Message Tx_Mgr is idle Invoke Tx_Mgr to process message Message_wait 268-Prdef

97 Modeling Concepts Process Model Development Methodology State Transition Diagram for Q_Mgr Process All transitions of the Medium_Mon process correspond to simple logical events. The Gap_Elapsed event has two separate conditions associated with it when the process is in the Gap_elapse_wait state, but in both cases, the next state is Medium_usable; therefore only one transition is necessary. The fact that different actions that are to be performed for each condition should not necessarily lead to the definition of multiple transitions. Even if transition executive statements are used to implement these actions, a single statement can include conditional clauses (i.e., if statements) within it to handle each case appropriately. Event Response Table for Medium_Mon Process of Media Access System Current State Logical Event Condition Action Next State Medium_usable Busy_High None None Medium_busy Process Domain Medium_busy Busy_Low None start timer to measure gap Gap_elapse_wait Gap_elapse_wait Busy_High None reset gap timer Medium_busy Gap_Elapsed Tx_Mgr is waiting for medium to become usable notify Tx_Mgr of new status of medium Medium_usable Tx_Mgr is not waiting for medium to become usable None Medium_usable 269-Prdef

98 Process Model Development Methodology Modeling Concepts State Transition Diagram for Medium_Mon Process The Tx_Mgr process is not described in this section since it already appears as an example in the previous section. Data Link Control System The Dispatcher process receives messages from the link and from the traffic source. Messages from the link are acknowledgments sent by a destination process. Regardless of the received message type, the process always returns to the same state; this process is therefore another one-state loop, like the Q_Mgr of the Media Access System. Event Response Table for Dispatcher Process of Data Link Control System Current State Logical Event Condition Action Next State Message_wait Src_Message_Arrival channel manager exists for this channel channel manager does not exist for this channel invoke channel manager process and pass message create channel manager and invoke with message Message_wait Message_wait Ack_Arrival channel manager exists for this channel invoke channel manager process and pass acknowledgment Message_wait channel manager does not exist for this channel discard acknowledgment Message_wait 270-Prdef

99 Modeling Concepts Process Model Development Methodology State Transition Diagram for Dispatcher Process The Channel_Mgr process is simple in the sense that it has only two states; however there are six possible event-condition pairs departing from the Ack_wait state. The transition to the Idle state represents the logical union of two conditions, and the transition to the Ack_wait state represents four conditions. These conditions are not explicitly entered in the transition statements because they would be too long; instead a macro is used, as shown in the following diagram. Note that one of the transition s condition statements could be replaced with the expression default since it is the complement of the other. However, this expression should only be used after thorough verification that all transition conditions are complementary; otherwise a missing transition that may have been overlooked in completing the event response table could be masked during simulation (i.e., no error can be reported). Process Domain 271-Prdef

100 Process Model Development Methodology Modeling Concepts Event Response Table for Channel_Mgr Process of Data Link Control System Current State Logical Event Condition Action Next State Idle Src_Message_Arrival None start acknowledgment timer; begin transmission Ack_wait Src_Message_Arrival None enqueue message for later transmission Ack_wait Ack_wait Ack_Arrival no messages enqueued reset timer Idle at least one message enqueued start acknowledgment timer; begin transmission Ack_wait Ack_Timeout fewer than Max_Attempts transmissions have been made retransmit Ack_wait Max_Attempts transmissions have been made and at least one message enqueued discard current message; start acknowledgment timer; transmit next message Ack_wait Max_Attempts transmissions have been made and no messages enqueued discard current message Idle 272-Prdef

101 Modeling Concepts Process Model Development Methodology State Transition Diagram for Channel_Mgr Process defined as: SRC_MESSAGE_ARRIVAL (ACK_ARRIVAL &&!Q_EMPTY) (ACK_TIMEOUT &&!LAST_ATTEMPT) (ACK_TIMEOUT && LAST_ATTEMPT &&!Q_EMPTY) defined as: (ACK_ARRIVAL && Q_EMPTY) (ACK_TIMEOUT && LAST_ATTEMPT && Q_EMPTY) Prdef.3.7 Stage 6: Specifying Process Actions Prdef Process models perform actions to modify their state memory, communicate with other modules, control their own timing, gather statistics, etc. Actions are performed by statements called executives, which respect a C syntax. Executives can make use of any C language operators and constructs, the process state, temporary, and global variables, and may include function calls to Simulation Kernel procedures. Selecting Locations for Executive Statements to Represent Actions Process Domain Executive statements may be associated with states and with transitions. There are three types of locations in which executive statements can be placed to define the actions of a process: Exit executives. Any number of Proto-C statements may be inserted in this section of a state in order to model actions that take place immediately after receiving a new event, and before evaluating transitions. Transition executive. A single line of Proto-C code may be associated with each transition in order to associate an action with a particular transfer of control from one state to another. Note that this executive can be a compound statement or a macro if a complex action is required. Also, function calls may be included within this statement. Enter executives. Any number of Proto-C statements may be inserted in this section of a state in order to model actions that take place after a transition, upon entering a new state. 273-Prdef

102 Process Model Development Methodology Modeling Concepts These three sets of executives are executed without interruption in the order presented above whenever a process traverses a transition. The following diagram depicts this execution flow: Executive Statements The following set of guidelines can be used in deciding which type of executive statements should implement actions: Transition support. Complex transition requirements sometimes make it difficult to develop boolean expressions for the associated conditions. This is particularly true if transition conditions depend upon results of a multistep algorithm. Since transition conditions are evaluated after the completion of the exit executives of a transition s source state, these executives provide an appropriate location to place computations that support the evaluation of outgoing transitions. A typical example of transition support in the exit executives is shown below. In this case, a stream interrupt has been received due to the arrival of a packet, and several outgoing transitions are possible. The conditions of the transition depend on values to be extracted from the packet. To evaluate the transition conditions without using the exit executives of the source state would require that the condition statement be a procedure call where values would be extracted from the packet and computations would be performed to return a boolean result. This type of solution can be cumbersome and may require coordination between procedures representing alternative conditions. Using the exit executives generally provides a simpler solution, with manipulation of the packet occurring in only one location. 274-Prdef

103 Modeling Concepts Process Model Development Methodology Transition Support Statements in Exit Executives /* Pkt has just been received: get it from input strm. */ pk = op_pk_get (op_intrpt_strm ()); /* Assume pkt will be rejected, then test to override. */ pk_accepted = OPC_FALSE; /* Test if the packet has the expected protocol type. */ op_pk_nfd_get (pk, protocol type, &pro_type); if (pro_type == expected_protocol_type) { /* Extract the encapsulated data packet. */ op_pk_nfd_get (pk, data packet, &data_pk); /* Test that it is not too old to be accepted. */ op_pk_nfd_get (pk, orig_time, &orig_time); if (op_sim_time () - orig_time <= MAX_DATA_AGE) pk_accepted = OPC_TRUE; } Process Domain Actions not directly related to transition conditions. When an event occurs, the process may be required to perform a number of actions that are either unconditional, or that depend upon conditions that are not identical to those of any of the outgoing transitions of the current state. In such cases, the transition executives are not an appropriate location to implement these actions. In addition, since the actions are not related to the destination state that will eventually be chosen, the enter executives of the destination states are not appropriate either. The exit executives of the current state do provide the proper context for these actions since they are executed prior to the evaluation of transitions. As an example of this type of situation, consider a process that allocates jobs to servers. The process has two states, one representing the case where servers are available, and the other the case where all servers are 275-Prdef

104 Process Model Development Methodology Modeling Concepts busy. When a new job arrives, say in the form of a packet, the process must enqueue the job with all other jobs that are waiting for service; then if a server is available, it may invoke the server to begin processing the job. If the invoked server happens to be the last one available, then the process must move to the state that indicates saturation of servers; otherwise it can self-transition back to the state that indicates servers are still available. However, the action of queueing the packet that represents the job is independent of which transition will be followed. Therefore, this action should be performed in the exit executives of the servers_available state. Relevant parts of this example process appear below: Use of Exit Executives to Implement Actions Independent of Transitions /* Test if the event is a new job pkt that has arrived. */ /* This logical event is the only one implemented as a */ /* interrupt, so simply test the interrupt type. */ if (op_intrpt_type () == OPC_INTRPT_SELF) { /* Place the job pkt in the job queue; this is done */ /* whether or not the system becomes saturated. */ new_job = op_pk_get (JOB_STREAM); op_subq_pk_insert (JOB_QUEUE, new_job, OPC_QPOS_TAIL); /* Increment the number of busy servers. */ num_busy_servers++; /* Invoke a server to begin processing the job. */ start_new_job (); } Note that conditional actions may be implemented within the exit executives as well by making use of C language if statements. For example, if the queue had a limited job-holding capacity, the process could test within the exit executives that there is sufficient room in the queue, prior to attempting to insert the job packet. 276-Prdef

105 Modeling Concepts Process Model Development Methodology Actions and transitions dependent on identical conditions. Certain actions performed in response to an event are conditional on additional prerequisites, as explained earlier. This is also true of transitions. In cases where exactly the same conditions are required for a transition and for an action, the action may be implemented in the executive statement of the transition, provided that: (1) the action is not required to complete before the transitions are evaluated; and (2) the action is not also performed for all other transitions sharing the same destination state; and (3) the action is conveniently represented in the single line provided for a transition executive. Note, with regard to the third restriction, that by using macros or procedure calls, any set of actions can be represented in a transition s executives; however it may be more convenient to implement certain complex actions in the exit executives of the current state. The principal advantage of implementing actions in transition executives, when possible, is that the action and the transition are closely associated and that this association is visible in the process model diagram. The tight coupling of the action and the transition show clearly that the action is not associated solely with the source state or with the destination state, but with the specific transfer of control between the two. A second advantage, though less important, is that the condition shared by the action and the transition need not be evaluated twice; depending on the complexity of the condition, this could result in significant performance differences. Finally, a third advantage of this technique is that expressing the condition in only one location simplifies maintenance of the process logic. Process Domain Consider as an example the Tx_Mgr process defined in an earlier section of this chapter. Suppose that as part of its performance monitoring requirements, the process must keep track of the number of occasions on which arriving messages are immediately processed, rather than having to wait for the medium to become available. The submission of a new message corresponds to the two transitions departing from the Idle state. However, only the transition leading to the Tx_status_wait state corresponds to the specific condition of interest, which is the immediate usability of the medium. Since there is no requirement for the counter to be updated prior to evaluation of transition conditions, this action may be performed in the transition s executive statement, as shown in the following STD fragment. 277-Prdef

106 Process Model Development Methodology Modeling Concepts Use of Transition Executive to Implement an Action The number of unblocked packets is incremented only if this transition takes place Actions associated with entry into a state. Actions that are performed each time that a state is entered, regardless of which transition was traversed to arrive there, should be associated directly with that state rather than any of the transitions or source states. The appropriate location for such actions to be implemented is the enter executives of the state of interest. The Tx_Mgr model provides a good example for this case as well. The Tx_status_wait state is responsible for determining if an ongoing transmission is successful or affected by a collision. Suppose that in order to detect the end of its own transmission, the process sets a timer when the transmission begins; the duration of the timer is exactly equal to the transmission time of the packet. The Tx_status_wait state is entered via transitions from several states, including a transition from itself. However, regardless of the reason for entering this state (e.g., retransmission, first-time transmission without waiting, first-time transmission having waited, etc.), the action of setting the transmission timer must always be performed. Therefore, the enter executives of the Tx_status_wait state provide an appropriate location for this action. The following diagram depicts use of the enter executives in this example. 278-Prdef

107 Modeling Concepts Process Model Development Methodology Use of Enter Executives for Actions Associated Exclusively with State Entry /* A new transmission is beginning; time */ /* it with a self interrupt. */ start_transmission_timer (); Note that there are ambiguous cases, where a single transition leads into a state and there is an action to be performed that can be associated with arrival into that state. In such cases, the transition executive and the enter executives of the state provide equally valid locations for this action to be implemented. Process Domain Actions associated with a non-singular subset of transitions. If an action is to be performed subject to the union of the conditions of more than one outgoing transition, but not the complete set of outgoing transitions, then the exit executives do not provide a good location to implement the action. This is due to the fact that the exit executives contain logic that is common to all outgoing transitions. Similarly, if a subset (of more than one) of the transitions arriving at a state correspond to the performance of an action, the enter executives of that state should not be used to implement the action. However, there are two other appropriate options for each of these cases: (1) if the action can be represented in a compact form and there are a relatively small number of transitions, then the executive statements of these transitions can be used to represent the action; (2) a forced state can be created to implement the action in its enter executives and the applicable transitions can be rerouted to pass through that state. Implementing the actions in the transitions executives is the most straightforward solution to this problem. In addition, this has the advan- 279-Prdef

108 Process Model Development Methodology Modeling Concepts tages of introducing no additional unforced states. However, since the action is implemented in several locations (i.e., on each transition in the subset), maintaining it may require additional effort. Thus, if this solution is chosen, the action should always be implemented by means of a macro or function call, so that all changes that may need to be made can be made in one place. The following diagrams illustrate the use of the transition executive approach for both outgoing and incoming transitions. Subset of Outgoing Transitions Performing the Same Action Implemented with Transition Executives The executive E does not occur if this transition is taken Subset of Incoming Transitions Performing the Same Action Implemented with Transition Executives The executive E does not occur if this transition is taken 280-Prdef

109 Modeling Concepts Process Model Development Methodology Using a forced state to contain the action can be useful if the action s implementation is complex. This approach presents the advantage that the executive statements are located in only one place. However, it has the disadvantage that it requires an additional element in the STD. Also, in the outgoing transition case, the condition statements must be duplicated, first in order to form their union on the transition to the forced state, and then to separate control flow to the multiple destination states. The following diagrams illustrate use of a forced state for both cases: Subset of Outgoing Transitions Performing the Same Action Implemented by Redirecting through a Forced State Action does not occur if this transition is taken Action is implemented in forced state Process Domain Subset of Incoming Transitions Performing the Same Action Implemented by Redirecting through a Forced State Action does not occur if this transition is taken Action is implemented in forced state 281-Prdef

110 Process Model Development Methodology Modeling Concepts Prdef Developing Action Statements In order to perform simulations of a process, actions must ultimately be specified in a form that can be executed within the OPNET simulation environment. Specifying actions on a level that can be executed is referred to as implementation of the actions. Executive statements that constitute an action s implementation are required to obey the syntax of the C language, and may make use of any of its operators and constructs. In addition, executive statements are often based on a library of C functions known as OPNET Kernel Procedures or KPs. Before proceeding to actual implementation, it is useful to develop a logical specification for a process actions. A logical specification is concerned with the behavior, timing, and effects of an action, but not with the details of how the action is actually carried out. By first developing the process actions on an abstract level, the developer may more easily manipulate the action statements, notice commonality between them, and apply the placement guidelines formulated in the previous section. Determining the Logical Actions of a Process In an earlier section pertaining to this development methodology, an eventresponse table was generated. One of the columns of this table contained actions that would be performed as a result of a logical event taking place and a condition being met. These actions are logical actions of the process since they presented in an abstract manner without implementation details. During the development stage where the event-response table is constructed, the main objective is to outline the control flow of the process by specifying the transitions between states. Actions are included in the table because they often depend on the same events and conditions as transitions and therefore can easily be captured simultaneously. Thus, at this stage of development, the event response table should be revisited as a useful starting point for determining the process logical actions. Actions taken from the table should be given consistent high-level names and placed within the process model according to the guidelines of the previous section. Note that the structure of the table facilitates the application of these guidelines as summarized by the following set of statements: An action should be placed in the exit executives of a state if it appears in all rows for which that state occupies the Current State column, since it therefore applies to all transitions. An action should be placed in the enter executives of a state if it appears in each row that identifies the state as the destination of a transition (i.e., the Next State column contains the state s name). 282-Prdef

111 Modeling Concepts Process Model Development Methodology An action should be placed in the executive statements of the transitions that share the same rows, if neither of the two previous criteria are satisfied. It is appropriate that the process event response table should serve as a basis for specifying actions since actions are performed in reaction to the occurrence of logical events. However, the event-response table may not always include a complete specification of all actions that a process is required to perform. A discrepancy may arise from the fact that the combinations of events and conditions that appear in the table do not correspond directly to the conditions under which certain actions are performed. As a result, certain action specifications may be overlooked. Note however, that since the transitions departing from each state are required to form a complementary set (at least one must be true), it should be possible to associate all actions with one or more of the conditions; in the case where a condition supersedes the condition required for an action, the action can be considered to incorporate an additional restrictive clause (e.g., an if statement); in the case where an action is dependent on a condition that overlaps several conditions associated with transitions, the action can simply appear in multiple rows. Therefore all actions can and should be represented within the event-response table. The following subsection of an event-response table illustrates the specification of actions that are subject to conditions that do not identically match those of the transitions. The action A partially overlaps two transitions and is subject to the condition (E 0 && C 0 && C 0 ) (E 1 && C 1 && C 1 ); the action A 2 is supersetted by the third transition and depends on the condition (E 2 && C 2 && C 2 ). Process Domain Current State Logical Event Condition Action Next State S 0 E 0 C 0 if C 0 then A S 1 E 1 C 1 if C 1 then A S 1 E 2 C 2 if C 2 then A 2 S 1 Logical actions should be entered into the process model executive areas simply as high-level names. Later, during the implementation phase, these macros can be fully defined within the header block, or replaced in-line by actual implementation statements. The action statements of the Tx_Mgr process (described as part of the Media Access System example) are shown below as an example. 283-Prdef

112 Process Model Development Methodology Modeling Concepts Logical Actions of the Tx_Mgr Process Begin_Message_Transmission occurs for every transition into the Tx_Status_Wait state and therefore appears in enter executives. Abort_Transmission action occurs whenever the Backoff_wait state is entered, but since there is only one incoming transition it can appear on the transition. (It could also have been placed in enter executives.) Begin_Backoff action occurs each time that Backoff_wait is entered and so appears in enter executives; could also have appeared on incoming transition since there is only one. Implementation of Actions In order for a process to become executable as part of a simulation, each of the logical actions associated with its states and transitions must be expressed in a form that can be understood by the OPNET simulation environment. Generally, each logical action is decomposed into a series of statements. The statements may appear directly in the location where the action was placed originally; they may constitute a macro defined in the process header block; or they may be placed in a function that is called from the location of the action. Regardless of their placement, implementation statements must respect the syntax of the C language. Many implementation statements consist of calls to KPs defined in the Simulation Kernel. Other common statements are ordinary C language operations such as variable assignments, if statements, or for loops. There are no general guidelines for designing the content of implementation statements since this depends to a significant extent on the nature of the application. Some common examples of the implementation of actions are provided in the Framework chapter of this manual, organized according to the type 284-Prdef