02 20framework

Chapter 2 Modeling Framework
63-Fram
Modeling Concepts
64-Fram
Modeling Concepts
Introduction
Fram.1
Introduction The Modeling Overview chapter provides a high-level introduction to the entire OPNET modeling environment. It is a good starting point for understanding how the different components of OPNET work together. This chapter begins to present more in-depth information on the tool. In particular, it addresses issues that are related to the modeling framework as a whole, rather than any particular hierarchical level. This chapter should solidify your understanding of OPNETs architecture and the relationships between an OPNET model and the real-world system that it represents. The chapter is divided into three main sections, as follows: Framework Chapter: Content Summary
Section Mapping Real Systems to OPNET Models Topic Explains the basis for using distinct modeling domains and briey restates the purpose of each domain. Discusses how various aspects of realworld systems map into the modeling domains and into mode specic OPNET-supported modeling mechanisms. Provides a detailed explanation of the object and model hierarchies. Discusses the relationships between models, objects, and attributes, and the precise behavior of each of these. Lays the groundwork for discussing simulation dynamics by introducing low-level mechanics supporting the interaction among objects. Provides a detailed explanation of the different types of events, what they are used for, and how they are typically processed.
Modeling Framework
Object-Based Modeling & Simulation
Event Scheduled Simulation
This chapter is designed to allow reading at two levels: detailed and conceptual. For more detailed information, merely read the paragraph text as you would a traditional text. To cover the information more quickly, remain at a conceptual level by reviewing only tables, diagrams, bullet list headings, and special key concepts boxes, as shown below. If you require more detail on a particular topic, read only the paragraphs in the corresponding section.
Key Concepts To quickly cover the material in this chapter, simply skip over paragraph text, reviewing only tables, diagrams, bullet list headings, and key concepts boxes such as this one.
65-Fram
Mapping Real Systems to OPNET Models
Modeling Concepts
Fram.2
Mapping Real Systems to OPNET Models OPNET divides the majority of model specication into a set of three environments called modeling domains. This differs from the approach taken by most modeling frameworks, which use a single paradigm to specify all aspects of a system. The contrast between the OPNET approach and the single-paradigm approach is most evident when considering the problem of modeling both a systems behavior and its structure.
Fram.2.1
Rationale for Multi-Paradigm Approach Communication networks and distributed systems typically encompass a wide range of technologies ranging from low-level communications hardware to highlevel decision-making software. A successful system modeling effort must represent each of these subsystems and their interactions at a level of detail that is sufcient to obtain valid predictions of performance and behavior. Because the nature of these subsystems varies signicantly from level to level (for example, a communications protocols and real-time operating systems are fundamentally different types of entities than communications links or packet buffers), singleparadigm frameworks must be stretched to develop adequate models. OPNETs approach to modeling is based on three paradigms that specically target the distinct levels identied in a communications network. The following is a brief summary of each of the modeling domains supporting these paradigms. Please refer to the chapters in this manual covering each specic modeling domain for more information. OPNET Modeling Domains
Domain Network Node Process Purpose concerned with the specication of a system in terms of high-level devices called nodes, and communication links between them. concerned with the specication of node capability in terms of applications, processing, queueing, and communications interfaces. concerned with the specication of behavior for the processes that operate within the nodes of the system. Fully general decision making processes and algorithms may be specied.
Key Concepts OPNET uses distinct modeling paradigms to represent the fundamentally different components of a network or distributed system. Each paradigm has an associated modeling domain and editor. This allows the structure of models to closely resemble that of real-world systems and to be more intuitive.
66-Fram
Modeling Concepts
Fram.2.2
Identifying Modeling Support for Actual System Features With the power of having several modeling domains comes the requirement to decide which domain will be used to implement each characteristic of a modeled system. This breakdown is usually the rst step in designing a system model. While there are no strict rules, this section provides useful guidelines for establishing a correspondence between an actual system and the OPNET modeling domains. The following table characterizes the OPNET modeling domains by stating which aspects of a system each domain may play a role in representing. In certain cases, more than one domain may be marked as appropriate for a particular system aspect; this indicates either that a combination of domains is required in the modeling or that, depending on other aspects of the system, one of the marked domains will provide the most appropriate support. Domain Applicability to Selected System Aspects
System Aspect Hierarchical Topology Communications Pathways Geographical Layout Device Mobility Device Failure Communications Delays Communications Errors Resource Management & Contention Packet/Transaction Queueing Packet/Transaction Generation Packet/Transaction Processing Remote Sensing and Control Interrupt Processing Behavioral Logic General Information Storage Network Node Process
Modeling Framework
Fram.2.2.1
Hierarchical Topology The topology of a system consists of both an inventory of its devices and the communications links between them. The network domain refers to these devices
67-Fram
Modeling Concepts
as nodes, and has several types of links that can be dened to connect them together for the purpose of sending information between them. Groups of nodes and links can be used to form subnetworks, and subnetworks can in turn contain lower-level subnetworks to form unlimited hierarchies. Some system topologies can be entirely represented in the node domain by interconnecting the node level building blocks, called modules. In such cases, the network domain model may consist of just one node. This occurs particularly for small systems with no real physical layout requirements, or where the communication between devices is mostly of a logical nature (i.e., interfaces based on commands, requests, indications, or interrupts). However, in most cases the network domain is used to represent high-level system topology because of its direct support for unlimiteddepth hierarchies, sophisticated communication links, and measured physical layout.
Key Concepts Hierarchical network structure is accommodated by OPNETs subnetwork construct. Subnets can be placed in different geographical locations and connected via links. In each subnet, a model may contain arbitrary groupings of nodes and links, as well as additional nested subnetworks.
Fram.2.2.2
Communication Pathways Most systems involving multiple subsystems or devices implement one or more forms of communication between them. Some forms of communication may require no physical connections to transfer information, such as interrupts issued by an operating system to a process, for example. However, for many systems, particularly systems with geographic separation, some physical resources are used to connect the subsystems. OPNETs network domain provides several types of link objects that are generally used to model connections between devices that are separated by some physical distance. These links transfer data in the form of userdened messages called packets. Network domain links model properties found in the communication media of real systems, including interference, errors, and delay. Network domain links are rarely used to model device-connectivity of a purely logical nature. These types of communication are generally supported by simpler connections within the node domain, called packet streams and statistic wires. Packet streams are simple pipes that carry packets between modules in a node. The interface they provide typically corresponds to a need to transfer blocks of information or messages between local devices, cooperating software processes, or neighboring protocol layers. Statistic wires convey numeric values between devices or processes that are located in the same node. They are used for two primary purposes: to allow processes to monitor changes in state and performance of the devices that make up a node; and to create a simple signaling mechanism between processes.
68-Fram
Modeling Concepts
Key Concepts Links are used to transfer packets between physically separated nodes or subnetworks in the Network Domain. Within a node, modules use packet streams to transfer packet and numerical information or signaling can be conveyed using statistic wires.
Modeling Framework
Fram.2.2.3
Geographical Layout For certain network models, the actual physical disposition of nodes may affect the results produced by a simulation. In particular, systems that include radio or bus type links can make use of the distances between nodes to compute link effects including propagation delay, interference, and received power levels. OPNETs network domain provides for precise descriptions of the physical aspects of a network within a congurable coordinate system. The units of the coordinate system can be degrees, arc seconds, kilometers, miles, meters, or feet to accommodate both large and small-scale models. Cartographic backgrounds may be loaded to provide models with a geographical context.
Key Concepts Network models can be deployed within a physical context to match the actual system environment. Physical relationships between nodes can be used to accurately calculate delays for links, and propagation and interference effects for radio transmissions.
Fram.2.2.4
Device Mobility Systems that include mobile communicating devices may require models that explicitly represent the devices motion histories in order to account for timevarying distances that will affect communication characteristics, including quality of transmission and connectivity. If this level of modeling is required, the network domain allows mobile nodes to be dened, each of which can be assigned an independent trajectory that species its positions as a function of time. Trajectories, which are specied as a series of discrete positions and associated times, are the most common mechanism used to model mobility; however, it is also possible for user-developed process models to dynamically update the position attributes of node objects, thus allowing adaptive node mobility which can be a function of the systems state and of its history.
69-Fram
Modeling Concepts
Key Concepts In OPNETs Radio version, mobile nodes can change position over time in the Network Domain. Two mechanisms support node mobility: 1) a node can be assigned a trajectory that specifies positions as a function of time, and 2) processes can compute and update node positions on an adaptive basis, to respond to changing conditions.
Fram.2.2.5
Device Failure Certain modeling efforts include a requirement to model the behavior of a system when some of its components experience failures. Depending upon the sophistication of the system it may have built-in procedures for adapting to such conditions; these capabilities may also need to be incorporated into the system model in order to accurately simulate the systems behavior. OPNET offers several capabilities in this area, spanning all three modeling domains. The feature that most directly supports modeling of failures is the condition attribute of node and link objects within the network domain. By modifying this attribute as the simulation progresses, user-dened processes can affect the operability of selected nodes and links. Disabling a node or a link essentially prevents it from carrying out any operations; in the case of a node, this means that simulation events that occur within the node are suppressed; in the case of a link, all transmitted packets are lost. Each node and link can be disabled and enabled any number of times during a single simulation run. An important aspect of using condition attributes to generate failures is that processes throughout the entire network model may receive asynchronous notication of the changes in the attributes state. This notication mechanism, which causes a special interrupt to be delivered to the process in question, is controlled by setting the failure intrpts and the recovery intrpts attributes of processors and queues. Additional capability to model failures within the modeled system can be derived from the general ability to program behavior into the models of system components. For example, OPNET provides no built-in support for implementing the failure of a queue module; however each queue is a programmable object that can respond to commands or changes in its attributes. By sending the appropriate command to a queue module, its internal logic can respond by discarding the packets that it contains and rejecting further attempts to enqueue packets. Similar types of behaviors can be programmed for processors, links, or for nodes as a whole. The principle is that, if the built-in support for modeling failures and recoveries of system components is insufcient, these may be treated as general events whose specic repercussions are implemented by user-dened logic.
70-Fram
Modeling Concepts
Key Concepts Component failures for nodes and links can be modeled by modifying their condition attribute when appropriate. Optionally, changes in this attribute can automatically generate notification interrupts for processes in any part of the network. Other component failures, or different behavior can be programmed as necessary in process model logic.
Modeling Framework
Fram.2.2.6
Communication Delays Delays affecting information transfer can occur at many levels in an actual distributed system or communication network. OPNET provides a number of possibilities for modeling delay. Signal propagation delays over links (due to distance) are an important cause of communication delays; network domain point-to-point and bus link objects include a delay attribute that is used by the default underlying link models. In the case of point-to-point links, the delay is usually simply a constant, while in the case of bus links, the delay is per unit-distance. The default model for radio communication computes delay based on distance separating the transmitter from the receiver. For all link types, the underlying link model used to compute propagation delay may be customized. In the node domain, each packet stream supports the assignment of a propagation delay for the packets that it transfers. Transmission delay is a second form of delay incurred by each packet as it is sent over a link, in addition to propagation delay. This delay is the amount of time separating the instant at which the rst bit begins transmission from the instant at which the last bit completes transmission. For all types of links, there is an underlying model, or pipeline stage that computes this value, and can be customized. The default model makes use of the data rate attribute of the transmitting channel (specied in the node domain via the transmitter module of interest) and the length of the transmitted packet. Queuing delays occur when data is made to wait for resources to become available, typically a communications link or a processor. This type of delay can in some cases account for the majority of a packets end-to-end delay from its pointof-origin to its nal destination. Most queuing delay in OPNET occurs within the node domain, in either queue or transmitter modules. Transmitter modules (for all three link types) incorporate a rst-in-rst-out queue for packets to wait while packets that arrived before them complete transmission; queue modules use a process model (which may be user-dened) to determine when packets should be dequeued and forwarded. Thus, the process domain is also involved in determining queueing delays.
71-Fram
Modeling Concepts
Key Concepts There are many sources of delays incurred by packets as they travel through a network, including propagation, transmission, and queuing. Propagation delay on links can be based on a fixed delay attribute, or on distance. Transmission delay depends on packet size and link data rate. Queuing delays are determined by process models.
Fram.2.2.7
Communication Errors Many communication systems are subject to errors that affect the transmission of data. Various causes are associated with these errors, ranging from faulty electronics to interference from other transmissions or noise sources. Typically, these errors are modeled in the network domain by assigning bit error rates (BERs) to link objects; also the underlying bus link models may account for collisions caused by simultaneous transmissions. The default bus models cause collided packets to be lost. The radio link models dynamically determine errors based on parameters of the transmission that affect link quality, including interference and signal strength. Thus, most modeling of communication error phenomena is performed in the network domain. However, it is possible to use process models to model errors that are internal to nodes. For example, a process that normally forwards packets to another module may be programmed to destroy the packets instead with a certain probability, thus modeling a stochastic error mechanism. If such a process is deployed as the immediate neighbor of a receiver module within a node, then it may replace the links bit-oriented error characterization with a packet-oriented one (the links bit error rate can be set to zero).
Key Concepts Communication errors can exist on all types of links and result in damaged or lost packets. Each link model has its own error mechanisms, including stochastic errors, collisions, and various types of interference. These are implemented, and can be customized, by the underlying link models. Processes can also induce packet loss or change.
Fram.2.2.8
Resource Management & Contention Resources can generally be thought of as entities that are required in order to complete tasks. Typically, resources are hardware devices such as CPUs, disks, memory, or computer busses; they may also be more abstract as in the case of a software program with a limited number of simultaneous users, or a communications channel. Generally, resources enter into system modeling problems because they are contended for by a number of clients. A client is an another entity or process that seeks to use the resource to progress in its completion of a task. Each system must have established policies to decide in which order and to what extent the various clients will be granted access to the resource. Because the number of clients and their need for resource access may be
72-Fram
Modeling Concepts
a function of many factors, and the resource allocation policy may also be complex and non-analytic, simulations are often the most effective means of forecasting the behavior of such systems. Indeed, many simulation packages focus on resourceoriented modeling exclusively. While OPNET does not have a paradigm dedicated to resource modeling, the power and generality of the node and process domains make it an excellent environment for modeling complex resource-based systems. The most commonly adopted strategy for modeling resources in OPNET is to create a queue module in the node domain to represent each resource. Because queues are fully programmable, each resource can be managed by its own allocation algorithm. A number of example policies are provided including a simple FIFO, processor sharing and preemptive-priority. The exibility of the process domains Proto-C language allows any new resource management policy to be dened. Models of the clients are usually implemented as processes that send access requests to the various system resources. They may choose to block while waiting for resources to become available, or to continue, depending upon their task denition. Resource access requests may be formulated as OPNET packets with specic parameters of the request encoded as packet elds; these parameters may factor in to the resource policys decisions on how to process requests.
Key Concepts Resources are often modeled as queues in the Node Domain. The process model of the queue implements the resources policy and accepts and processes requests which can be submitted in the form of packets. Fields of the packets can indicate parameters of the request. Arbitrary resource management policies may be defined.
Modeling Framework
Fram.2.2.9
Packet/Transaction Generation Most simulated systems involve at least one type of dynamic entity that circulates among the components of the system. Depending on the primary orientation of the development environment, these entities will have different names such as transaction, data-structure, or data-unit. OPNET supports several such dynamic objects, the most common of which is called a packet, due to the traditional application of OPNET to communication network modeling. Packets are general data structures that are organized into elds of information according to a user-dened format. A single system model may rely on multiple types of packets, each with its own format. Packets are considered dynamic simulation entities, because they are created and destroyed as a simulation progresses. Packets can be created in an OPNET simulation model through only a limited number of mechanisms: (1) generator modules, dened as part of node models, may issue new packets according to stochastically characterized patterns; (2) processes operating within processors or queues may create entirely new packets, as required by their process models
73-Fram
Modeling Concepts
specicationthis allows processes to model sophisticated packet-generating devices, in place of the simpler generator modules; (3) processes may create copies of already existing packets; (4) bus and radio communication links may create copies of packets in order to deliver them to multiple destinations as part of a broadcast transmission.
Key Concepts The primary information-carrying object in an OPNET simulation is a packet. Each packet has a format which defines which fields it contains. Packets can be generated spontaneously by generator modules, or by processes. They are then forwarded to other objects. Packets may also be copied by processes or for broadcasting.
Fram.2.2.10
Packet/Transaction Processing As packets circulate through the various components of a system, they trigger certain actions, which in many cases are based on information that the packets contain. Because OPNET packets are modeled as individual entities with specic data contents, the packet processing performed by an actual system can be modeled in full detail. Denition of packet processing in an OPNET model occurs within the process domain, where Proto-C process models make use of Simulation Kernel procedures to manipulate the packets that they create or receive from outside. Common operations that process models perform on packets include: creating new packets, receiving new packets, copying packets, extracting eld values, setting eld values, sending packets to other modules, enqueuing packets, dequeuing packets, and destroying packets. In addition, many packet-processing operations cause further non-packet-related actions to take place. For example, a routing-update packet may trigger a process to update the contents of a routing table, and an acknowledgment packet may cause a timer to be canceled, depending on its contents.
Key Concepts Packet fields carry actual values that can be assigned and extracted by processes. When a packet is received by a process, the information that it contains can be analyzed and used as the basis for decisions. Actions can include modifying, destroying, or relaying the packet, as well as creating other packets, or changing system state.
Fram.2.2.11
Remote Sensing and Control The design of certain systems may require that distinct components keep track of each others state in order to coordinate overall operations. Changes in the state of one system component may require another component to take specic actions. This coordination of activities implicitly involves some communication between
74-Fram
Modeling Concepts
the components. In some cases, packets are well-suited to modeling this type of communication, as in the case of telemetry data transmitted from a remote node via a radio link, for example. However, OPNET provides two simpler communication mechanisms that can often be more appropriate, particularly when the coordination between the components is based on the sharing of numerical values. For localized communication of numerical data, the node domain provides an object known as a statistic wire, which allows a module to export values that reect its state or performance as these vary over time. For example, a node may contain several queues and a processor that acts as a multiplexor for the queues output, having to select which queue to draw from next; as part of the system denition, the processor may need to be aware of the queue sizes on a synchronous basis, as well as receive an asynchronous warning when any of the queue sizes exceed a certain threshold. Statistic wires are an appropriate modeling construct to represent such a system because all of the coordinating objects are located within the same node, and because the communicated information consists only of simple numerical values. In addition, statistic wires have a set of attributes called triggers that specify criteria for changes in the source value that will generate interrupts at the remote module; this supports asynchronous notication of particular types of changes in order to model alarms. The role of statistic wires is restricted to communication within a single node and therefore does not always provide adequate support for remote sensing. An important alternative is provided by a mechanism called the remote interrupt, which can communicate information between processes without relying on the existence of any physical connections between them. A process operating in a processor or queue module can send a remote interrupt to any other processor or queue in the entire modeled system, regardless of location. The interrupt may be accompanied by some state information, either in the form of an integer value or of a formatted information structure, known as Interface Control Information, or ICI. Note that this mechanism does not support communication between remote objects other than processors or queues.
Key Concepts An object may rely on knowledge of another objects state. Packets may be appropriate for remote objects connected by links; but for modules within the same node, statistic wires are used to transfer numerical values and to provide interrupts for specific changes. Remote interrupts allow information to be sent to any process in the system.
Modeling Framework
Fram.2.2.12
Interrupt Processing Each event in an OPNET model is associated with a module within the node domain. Most events result in the module being interrupted in order to perform a series of actions. Two types of modules, processors and queues, allow a general set of actions to be dened by developing a process model using the Proto-C language of the process domain. The general approach to developing process models is to
75-Fram
Modeling Concepts
view them as procedures that respond to interrupts. A process model may use the various provided Simulation Kernel procedures to obtain information concerning the nature and source of the interrupt. In most cases, interrupts carry additional information that a process model may access and factor into the actions that it implements and the state-transitions that it traverses. For example, a stream interrupt represents the arrival of a packet, and usually causes a process to obtain the packet and decode its contents; and self interrupts have an associated userdened code that can be used to distinguish between multiple outstanding interrupts of the same type.
Key Concepts Processes are interrupt-driven. When a process is invoked, it can access data associated with the interrupt. The logic of the process uses the data, combined with state information to take appropriate actions and modify state.
Fram.2.2.13
Behavioral Logic The developer of an OPNET model may choose to simulate the behavior of the modeled system at many levels of detail, including all necessary interactions between subsystems. While data communication is often an important part of an OPNET model, the modeling framework provides equal depth in modeling the processing that takes place within each subsystem. In fact, it is typically the case that the communications layers of a model are viewed as support mechanisms for the higher level applications processes. In this sense, models of application behavior are actually those that drive an overall system model, and therefore these need to be accurately represented. The Proto-C language provides a rich set of operations for modeling the processing activities of applications, including: construction and transmission of packets and ICIs to represent commands, resource requests, or communications loads; scheduling of interrupts to perform future activities; queueing according to user-dened algorithms to provide access to communications, processing, and storage resources; object identication and topological discovery; dynamic model-attribute modication; stochastic value generation; programming support (for example, memory allocation, linked-lists, and le I/O); and the general computational capabilities of the C and C++ programming languages.
Key Concepts Applications and in general, any generation or processing of data, are represented with process models. Process models use the OPNET Kernel Procedures and general C/C++ code to allow specification of any system behavior.
76-Fram
Modeling Concepts
Fram.2.2.14
General Information Storage Both applications and communications protocols in distributed systems typically require that signicant amounts of state information be maintained. The word state is often used to represent the position of a Proto-C process model in its nite state machine graphical representation; however in the larger sense, a process models state additionally consists of an arbitrary set of variables of either built-in datatypes, or of datatypes specied by the modeler. A communication protocol may dene unique structures for storing information, such as routing tables, timer information, lists of packets to retransmit, data fragments held for reassembly, and so on. An application may store different types of information, such as variables for custom performance calculations, or lists of requests that are pending processing. Beyond attributes of network and node domain objects, the primary mechanisms dened for storing the state of a system are specied in the process domain. State variables are declared as part of each process models specication, and the Simulation Kernel maintains these separately for each instance of a process model in the system. This is the mechanism most often used to specify state information that is independently maintained by each process. Global variables are used when multiple processes need to implicitly share information without the use of an active communication mechanism to update each other. These variables may also have general data types and can be declared both in process models and in external source code les. Both state variables and global variables can provide statically allocated (allocated in advance), or dynamically allocated (allocated as needed) memory.
Key Concepts In addition to the attributes of objects, the state of the modeled system can be stored in a combination of: 1) the state variables of processes; and 2) model global variables. Both types of variables can support statically or dynamically allocated storage.
Modeling Framework
77-Fram
Modeling System Structure
Modeling Concepts
Fram.3
Modeling System Structure OPNET uses two fundamental methods of describing a system: objects, and procedures. Objects are used to represent system structure by decomposing a system into smaller pieces and expressing the relationships between those pieces. Procedures provide a way of expressing behavior that is dynamic and adaptive. Behavioral descriptions must account for a wide variety of conditions involving variable system state and events; furthermore, complex actions must be specied in response to these conditions. OPNETs modeling approach provides a natural way of integrating these two specications into a unied system model, as will become clear in the remaining sections of this chapter.
Key Concepts OPNET uses two fundamental methods for describing a system: objects and procedures. Objects represent system structure, and procedures are used to express system behavior.
Fram.3.1
Where System Structure Appears This section focuses on the description of system structure using objects. Objects provide a natural approach for constructing models of most systems, including communications networks. This is partially due to the fact that in the real world, systems actually include many physically distinct entities that we think of simply as objects. Examples of physical objects in a communications network are enumerated in the following table: Some Physical Objects in a Communication Network
Router, Gateway Switch, Bridge, Hub Workstation, PC, Terminal Disk Drive Link (cable) Antenna Telephone, PBX Aircraft, Satellite
78-Fram
Modeling Concepts
Note that these are all objects that you have probably seen before and that you can describe physically. More than their physical characteristics, for modeling purposes, we are interested in describing how they work, and how they interact with other objects. Here again, there is a structural aspect and a behavioral aspect of system specication. The structural aspect of how the object works internally deals primarily with further decomposition of the object into more objects. In other words, the object is a system in its own right, and can be modeled as a collection of smaller objects that cooperate in some manner to achieve the desired functionality. There is also structure supporting the interaction of the object with other objects. This primarily involves a description of the physical interfaces provided by the object and the pathways that are in place to allow it to communicate with other objects. Pathways are often (but not necessarily) other objects (such as links) whose purpose is to allow interconnection.
Key Concepts Objects provide a natural way of describing the structure of communications networks. In addition to capturing the physical characteristics of system components, they can be used to represent their internal decomposition and interconnection.
Modeling Framework
In a theoretical sense, the use of objects is not limited to representation of a systems physical entities. Abstract or logical entities can also qualify as objects. A few examples of non-physical objects are enumerated in the following table: Some Abstract or Logical Objects in a Communication Network
Process Packet Job, Request, or Task Timer Probability Distribution
OPNET generally attempts to represent system components in the most intuitive way possible. Thus, these non-physical objects do not have a visual representation. They are simply software constructs, but they are still considered objects because of the way in which they are treated, and the way in which they behave. Some of the important characteristics that make them objects are: they present a well dened interface with controlled access to internal state; they are mostly special cases of a class of entities that are not identical but have a similar form.
79-Fram
Modeling Concepts
An interesting observation can be made from the examples in the above table: none of the abstract or logical objects could be said to actually represent system structure. They are all dynamic entities and most are created for a certain period, and then disposed of. While examples to the contrary could probably be found, it is generally the case that non-physical objects correspond mostly to the changing aspects of the system. Thus, while they are objects in the larger sense, they are not relevant for this sections discussion of representing system structure. In the remainder of this section, the word object will be used to refer to physical objects, such as those previously enumerated.
Key Concepts Abstract or logical objects, such as processes and timers, exist in a communications network. However, they are generally dynamic objects, and not elements of system structure. In this chapter, we will focus on physical objects that represent system structure.
Fram.3.2
Objects and Models The relationship between an object and a model is fundamental to all specication work performed in OPNET. When an object is created, a certain number of characteristics (sometimes all characteristics) are assumed to belong to it. The characteristics may relate to internal structure of the object, its capabilities and purpose, its presentation, and its interfaces.This information must come from some prior specication that is implicitly referenced when the object is created. This specication is referred to as a model. The object is said to be an instance of its model, and each object can have only one model. Of course, the operation used to create the object (e.g., graphical) can be repeated, resulting in another object which is an instance of the same model. Thus, there is a many-to-one relationship between objects and models.What is important is to realize that though the objects depend on the same model to receive certain characteristics, they exist independently of each other. In other words, changes made to one of the model instances do not affect the other. This corresponds well to the real world situation that objects represent. Consider the following example. A particular make and model of automobile can be considered a model. The model is essentially the blueprints for the car, together with any additional information that may describe it, such as list price, available colors, etc. Then the actual cars that consumers can purchase would be considered objects that are instances of that model. Each car exists independently of the other. For example, if one car breaks down, this implies nothing about the state of other cars of the same type.
80-Fram
Modeling Concepts
Key Concepts Objects are instances of models. An object is a particular occurrence of a model. It exists independently from other objects and its characteristics conform to the models specifications. As an analogy, a particular car is an instance of the car model which is essentially the cars design.
Modeling Framework
The collection of objects that depend on a particular model form a class. It is quite simply the class of objects of that type. The model represents the class; it is the class denition. When the denition of the class changes, all of the objects that belong to it are affected. For example, embedding additional specication for internal structure into the model will result in all objects receiving that internal structure. Similarly, if the interface specication of the model is modied, then all the dependent objects must change the way in which they interface with other objects. Such a change may potentially result in invalid connections or interactions, unless appropriate adjustments are made to the objects. This mechanism provides a centralized method for applying changes to sets of objects. The power of this approach is particularly magnied by the fact that the changes apply to all objects, including those that are not currently present within the OPNET editors. In fact, the changes even apply to objects that have not yet been created, since these instances will adhere to the new model denition when they are created.
Key Concepts Models dictate object characteristics. Changing the definition of a model affects the characteristics of all of the objects that adhere to that model. This is a powerful mechanism for controlling large numbers of objects in a centralized manner.
A model includes information that is common to all of its instances. This includes specications for the objects interfaces, behavior, and internal structure. The models interface dictates how objects interact with each other. This can include specications related to physical interconnection. For example, a node models interface may include information about what types of links it can use to connect to other nodes. The models interface may also include the mechanics and the semantics of interaction with other objects. For complex objects, this may include timing of communication, mechanisms for transferring and sharing data, and the proper way to interpret that data. In addition to an objects interfaces, a model describes the behavior of the object. This means that the model denes the way in which an object will react to external stimulus, and the how and when it will spontaneously take action. A trafc source, for example, is an object that will spontaneously generate activity. For
81-Fram
Modeling Concepts
complex objects, behavior may be a function of many variables, including accumulated state information, external stimuli, time, and random variables. Finally, a model also species the internal structure of an object. This has to do with the decomposition of the object into further components. These components may themselves be objects with their own models. OPNET node models, for example are specied in terms of objects called modules and connections, as discussed in later sections of this manual.
Key Concepts An objects characteristics inherited from its model include: internal structure (what it contains), behavior (what it does spontaneously and how it reacts), and interfaces (how to interact with it).
While models specify a large part of object characteristics, further customization of the objects is usually still possible. If this were not supported, then all model instances would be identical. A model species which aspects of the instances is xed, and which can be modied on a per-instance basis. The model can be thought of as being parameterized, meaning that it supports conguration of certain variables that the model designer chooses to expose to users of the model. This topic will be discussed in more detail later. For now, these parameters can simply be viewed as part of the models interface.
Key Concepts All objects that share a model are not necessarily identical. The model can allow for certain differences in each of its instances, as determined by the model designer.
Fram.3.3
Attributes When representing an object, certain characteristics of the object are considered private and remain hidden within the object. Other characteristics are considered useful to expose to the user of the object, for various reasons. These characteristics are represented in the form of data items called attributes. Attributes are useful for two primary purposes: to inform users about selected characteristics of an object; and to allow these characteristics to be modied for specic applications. The type of information that can be specied with attributes is quite general. It includes general characteristics, object behavior, and internal structure.
82-Fram
Modeling Concepts
Attributes can be associated with classes of objects, as well as with particular objects. In other words, an attribute can be dened for a model. This topic is covered in section Fram.3.5 Model Attributes. For the purposes of this section, the term attribute is used generically to refer to both object attributes and model attributes.
Key Concepts Attributes store data that describes an object or model. They can be used to: provide information; specify general characteristics; select behavior; modify internal structure.
Modeling Framework
Each attribute provides storage for information that constitutes part of the specication of an object or a model. The contents of the attribute are referred to as its value. An object or model may of course have many attributes. Therefore, in order to gain access to the value, either to read (examine), or write (modify) it, the attribute must be identied uniquely. This is accomplished by designating a name for the attribute. No two attributes on the same object, or on the same model, may have the same name.
Key Concepts All attributes have a name and a value. The name is unique within the context that the attribute belongs to (e.g., object or model). It is used to refer to the attribute when reading or writing its value.
Attribute Data Types Attributes can store different types of information in order to support specication of a broad range of object and model characteristics. Most attributes have a simple value, meaning that they consist of just one element. These include familiar types such as numbers, text strings, and booleans. Even text strings containing multiple characters, words, and lines, are considered simple values because they do not encompass storage for any additional attributes. Support is also provided for a compound attribute which encompasses nested objects. These nested objects may have their own attributes, which in turn may be simple or compound. Thus the information stored within an attribute may have a at structure in the case of a simple attribute, or a hierarchical structure in the case of a compound attribute. The following table enumerates the attribute types that may be found within an OPNET model, provides an example of each, and indicates which datatype can be used in programs to hold the attributes values.
83-Fram
Modeling Concepts
Supported Object Attribute Types

Attribute Type Integer Double Compound Toggle Toggle Double String String List Typed File Icon Enumerated Color Textlist Example Attribute priority of a processor data rate of a channel channel of a transmitter begsim intrpt of a processor intrpt interval of a processor name of a xed node interarrival args of a generator process model of a processor icon name of a mobile node object failure intrpts of a processor color of a simplex point-to-point link enter executives of a state C Language or OPNET-provided Datatype int double Objid int double char [] char [] char [] char [] int / char [] (see below) int List
The following list describes the various attribute types. Integerpositive or negative whole numbers with magnitude less than 231 64. These attributes typically represent small numerical values such as counts, identifiers, connection indices, or priorities. Certain integer values beyond the allowed range are constants with special meanings: OPC_INT_UNDEF represents an undefined value resulting from a computation that cannot be performed or insufficient information; OPC_INT_INVALID represents an invalid value, typically indicating an error condition. OPC_INT_INFINITY represents an unbounded integer value. Doublepositive or negative double-precision floating point numbers with a magnitude less than 10100. These attributes typically represent precise numerical quantities (e.g., the propagation delay of a link), or whole numbers with potentially very large values (e.g., the data rate of a channel). Several constants that are outside the allowed range may be used to indicate special values of this type of attribute: OPC_DBL_UNDEF represents an undefined value resulting from a computation that cannot be performed or insufficient information; OPC_DBL_INVALID represents an invalid value, typically indicating an error condition. OPC_DBL_INFINITY represents an unbounded double value.
84-Fram
Modeling Concepts
Compoundsupports complex data storage consisting of a set of objects. The actual value of a compound attribute is a special object which provides access to two items: a count of underlying subordinate objects; and an array of subordinate objects. The subordinate objects can have multiple attributes, including additional compound attributes, allowing further nesting of complex data. Compound attributes are often used to represent data that is stored in tabular format. Every row of the table can be though of as an additional subordinate object, and the column headings of the table correspond to the attributes of the subordinate objects. Togglebi-valued attribute capable of representing a true or false state. During specification, these values usually appear as enabled or disabled, though certain bi-valued attributes can use specific names for these two values; during simulation they correspond to the constants OPC_TRUE and OPC_FALSE, respectively. Toggle attributes are used to represent properties of an object that can only have two possible settings, typically some sort of status of the object. Examples include the condition of a node (its operational status), or the endsim intrpt attribute of a processor (selects whether or not the Kernel will deliver a special interrupt to the processor when the simulation completes). Toggle Doublemay represent the same range of values as the abovedescribed double attribute when placed in the enabled state. The disabled state indicates that the attributes value should not be considered. Thus a toggle double attributes value may appear either as disabled or as a number; the value enabled never appears. The special constant values that apply for ordinary double attributes also apply and have the same meanings for toggle double attributes. In addition, the constant OPC_BOOLDBL_DISABLED is used to represent the disabled state. Toggle double attributes are used to specify optional characteristics of an object, and they have a numerical form when they are selected. Stringa series of characters used to hold a single line of text. Typical examples include names, logic statements, or the name of an object or other general property. String Listalso a series of characters holding a single line of text, string list attributes are intended to contain multiple textual elements which together form a value. The elements can be separated by commas, tabs, or spaces within the string. A typical use of this type of attribute is for the argument list (e.g., the interarrival args of a generator) of a probability distribution, where both mean and variance may be specified. Typed Filecharacter string representing a file that is part of OPNETs system of managed files. Typed file attributes refer to a specific type of file corresponding to a suffix at the end of the file name. The typed file data type provides two services: 1) automatic path name construction allows the user to simply specify a file name and OPNET can
Modeling Framework
85-Fram
Modeling Concepts
determine the actual location of the file in the filesystem; and 2) when prompting for an assignment for a typed file attribute, OPNET constructs a list of those files that are available. Examples of attributes of this data type: a mobile nodes trajectory, a satellites orbit, a processors process model, a nodes node model, or a generators interarrival PDF. Iconcharacter string representing an icon from one of the active icon databases. Selected icon databases are loaded when OPNET is executed, and the set of icon names that can be chosen from for these attributes is the union of all the icon names included therein. Icon attributes are used only to control graphical representation of an object, and are not present during simulation. Enumeratedthese attributes appear as character strings during specification, and as integers during simulation. In both contexts, a finite, and usually small set of values can be assigned to them. In this sense they may be thought of as a generalization of toggle attributes. The string representation is provided for specification because it is generally more informative; during simulation, integers are a more efficient and useful datatype to manipulate. Examples of this data type include the src stream and dest stream attribute of packet streams, and a processors failure intrpts attribute. Colorsome OPNET objects allow the user to control the color used to draw them. For example, satellite orbits and point-to-point links each can be assigned a color from a color palette. Like icon attributes, color attributes are strictly used while specifying models, and play no role during simulation. Textlistthese attributes store a list of character strings to represent general textual information. Typical applications are sections of userdefined code, or documentation.
Key Concepts Attributes can store diverse types of data, depending on their purpose. Data types include several forms of logical, numerical, and text storage, as well as a special type called compound that holds nested objects.
Attribute Properties Though they appear to be relatively simple on the surface, attributes can be complex entities. While an attribute is identied by a name, and its function is to store a value, the way in which the attribute behaves is described by a third component, called the attributes properties. In broad terms, attribute properties
86-Fram
Modeling Concepts
specify: the type of data an attribute can store; how it can be manipulated; how it is presented to the user; and the function it performs. The following table explains each of the components of attribute properties: Attribute Properties
Property Data Type Description Species the type of information that the attribute can store. This property is sometimes referred to simply as the attributes type. The value that may be used by the system when an assignment is required, but none has been provided by the user. Also used to suggest a value to a user when prompting for an assignment. Additional information that can assist users in entering certain numerical attribute values. For example for a distance attribute, units are needed for a user to know if values should be given in meters, kilometers, miles, etc. Many attributes simply leave this property blank. A numerical interval that may restrict the set of values that an attribute can store. The interval consists of a lower and an upper bound, each of which may have a value or be open. An open bound means that the interval is openended toward negative or positive innity. A bounds value may be specied if the bound is exclusive or inclusive. An inclusive bound means that the bound value itself is allowed, whereas an exclusive bound means that all values within the bound are allowed, but not the bound itself. A collection of user-dened symbolic names associated with specic attribute values. Symbol maps are used to suggest reasonable values for an attribute and in some cases also to restrict the allowable values to a discrete set. The symbol map includes an allow other values component, which dictates whether values other than those enumerated in the symbol map can be held by the attribute.
Modeling Framework
Default Value
Units
Range
Symbol Map
87-Fram
Modeling Concepts
Attribute Properties (Cont.)

Property Attribute Description Description Indicates whether the attributes properties are public or private. If the attribute description is private, then the property specications belong specically to a particular attribute denition. If the attribute description is public, then the properties specications can be shared with other attribute denitions in the same or other models. Public attribute descriptions provide a means of dening re-usable attribute classes and managing them in a centralized manner. Documentation that may provide any relevant information about the attribute, as a model designer sees t. Typically these include a description of the attributes meaning, and instructions on how to use it.
Comments
Key Concepts An attributes data type is just one of its properties. Properties specify information about how an attribute can be used, how it behaves, and how it is presented.
As mentioned above, symbol maps allow a pre-dened word or phrase to represent an underlying value for an attribute. The word or phrase is referred to as the symbol, and can contain any general sequence of characters. However, there are a few symbols that are reserved for numerical attributes. These symbols represent special values supported by OPNET, and are therefore not permitted as user-dened symbols. In addition, there are restricted forms that symbols are not allowed to match. These restrictions are shown in the following table. Restrictions on Attribute Symbols
Restricted Form or Symbol zero length Other (...) promoted Details Symbols must contain at least one character. Reserved word. Used as a choice when Allow Others option is enabled. Reserved word. Used to represent a compound attributes value. Reserved word. Used to represent the value of a promoted attribute.
88-Fram
Modeling Concepts
Restrictions on Attribute Symbols

Restricted Form or Symbol contains contains | <num> TO <num> Details Symbols cannot contain the double quote character (). Symbols cannot contain the vertical bar character (|). Symbols may not contain this form, which is reserved to represent a range of values.
Modeling Framework
Viewing Attribute Properties You can view or change attribute properties in the Attribute Properties dialog box. Because you can change properties only at certain times, however, there are two versions of this dialog box. A read-only version restricts you to viewing the attribute properties, whereas the standard version allows both viewing and editing. For viewing attribute properties, this dialog box can be accessed several ways: Via the Details button in the Attributes dialog box. Via the Details button in the Rename/Merge Attributes dialog box. Via the Edit Properties button in the Extended Attributes dialog box. Via the Edit Properties button in the Derive New Model dialog box.
The following procedure describes how to access the Attribute Properties dialog box using the Details button. To view attribute properties 1) Open an Attributes dialog box or a Rename/Merge Attributes dialog box. This procedure uses an Attributes dialog box. 2) Check the Advanced check box, then left-click an attribute name to select it.
89-Fram
Modeling Concepts
3) Left-click the Details button.
Note: The Details button is active only when an attribute is selected. The read-only version of the Attribute Properties dialog box pops up, displaying detailed information about the attribute.
Public Attribute Descriptions In many applications, attributes are dened which may appear on a variety of different objects and models. An attribute such as data rate may have a consistent denition for transmitter channels, receiver channels, and for links. It is of course possible to specify the attributes denition for each type of object or model that requires it. However, this approach has the disadvantage of being redundant and therefore requiring more work. Even more importantly, separate and redundant specications require signicantly more work to maintain as changes become necessary, and allow inconsistencies to develop between the denitions. A much safer and more economical approach is to maintain a centralized denition of the attribute. OPNET supports this approach with a feature called Public Attribute Properties. Public attribute properties are normal attribute properties specications that can be referred to by an attribute. By maintaining only references to the properties, rather than the actual specications, multiple attributes automatically track any changes to the properties.
90-Fram
Modeling Concepts
Sharing of Public Attribute Descriptions
Bs attrs.
Modeling Framework
As attrs. C This attributes description is Public and shared to dene the properties of attributes for objects A, B, and C
Cs attrs.
Making Attribute Properties Public
All properties are taken from attribute description called ip_address_index
Key Concepts An attributes properties can be private or public. A private attribute property description is applicable only to the attribute that it is associated with. A public attribute property description is shared by many attributes, potentially in different objects and different models. Changing the public attribute properties affects all of the dependent attributes.
Compound Attributes As mentioned earlier, OPNET supports both simple and compound attributes. Simple attributes contain data with a at structure, whereas compound attributes
91-Fram
Modeling Concepts
contain hierarchical data. The hierarchy of data is composed of objects. In fact, each compound attribute can contain an array of one or more objects, as specied by the compound attributes count. Each contained object has its own set of attributes. The attributes of the nested objects are full-featured, including a name, value, and properties. They can themselves be compound, allowing unlimited nesting of objects embedded via compound attributes.
Key Concepts The purpose of a compound attribute (CA) is to provide complex data in an object or model interface. CAs can be nested arbitrarily deep. A CAs properties define the objects that it will store. Each attribute of the nested objects is defined as a full attribute with a name, and properties. A count of nested objects is specified.
Some examples of compound attributes are provided by the built-in (predened) attributes of certain OPNET objects. For example, each queue object (used in the Node Domain) can contain one or more subqueues, which are themselves objects. The entire conguration of subqueues is modeled as a single compound attribute of the queue. By specifying the count for the subqueue attribute, the user can specify that any number of subqueues be instantiated within the queue object. Similarly, channels for transmitter and receiver objects are represented as compound attributes. User dened attributes for objects and models may be compound as well, and their attributes can be completely general. Typically, compound attributes are used to represent data that has the form of a table (such as a routing table) or a list of virtual circuits. In these examples, each route or circuit can be considered an object.
Key Concepts OPNET uses compound attributes (CAs) for some of its built-in object attributes. These include the subqueue attribute of queue objects, and the channel attribute of transmitter and receiver objects.
Like all attributes, compound attributes have a single value. The value of a compound attribute is a special object known as a compound attribute object The . compound attribute object (CA-object) has no attributes but serves merely as a placeholder to group a set of subordinate objects together. During specication (i.e., in the OPNET editors), the CA-object is represented as shown in the following illustration.
92-Fram
Modeling Concepts
Presentation of Compound Attributes Values
A compound attribute value appears as (...) to indicate underlying complex data
Modeling Framework
During simulation, each CA-object has an object ID. This object ID can be used to access the subordinate objects. The CA-object is considered to be the parent of the subordinate objects and these can be accessed using the Kernel Procedure op_topo_child(). (Refer to section Fram.3.9 The Object Hierarchy for more information on parent-child relationships.) Similarly, op_topo_parent() can be used to determine the object ID of the CA-object given knowledge of one of the subordinate objects. Refer to the Topology Package chapter of the Simulation Kernel manual for more information on these Kernel Procedures. In the case of built-in compound attributes, the subordinate objects have a specic type: for the subqueue compound attribute of a queue, the subordinate object is the pre-dened object called subqueue. Similarly, the channel attribute for a point-to-point transmitter contains point-to-point transmitter channel objects. Each transmitter and receiver channel compound attribute contains its own specic type of subordinate object. However, for user-dened compound attributes, a generic object type is dened. Generic objects have no built-in attributes, but are entirely determined by the attribute denitions that users provide. Like subqueues and other subordinate objects, generic objects are considered to be the children of compound attribute objects. The following diagram illustrates the relationships between objects, compound attributes, CAobjects, and generic or subordinate objects.
93-Fram
Modeling Concepts
Compound Attribute Structure
OBJ
CA
Each compound attribute (CA) contains one CA-object.
CA For OPNET-provided compound attributes, the CA-objects children are specic subordinate objects (e.g., channels, subqueues).
For user-dened CAs, the CA-objects children are generic objects which have their own attributes. CA Generic object attributes may also be compound, allowing unlimited nesting of generic objects.
Key Concepts A compound attributes (CAs) value is a special object called compound attribute object (CA-object). The CA-object acts as a concentrator for all of the subordinate objects. The subordinate objects are considered to be children of the CA-object.
Fram.3.4
Extended Attributes As described in section Fram.3.3 Attributes, all network objects (subnets, nodes, and links) have built-in attributes that provide basic information about them. Node and link objects also receive additional attributes from the models associated with them; these model attributes dene the objects behavior in a network model. Extended attributes are optional attributes that you can add to a network object, thus further customizing its behavior in a network model. Support for an extended attribute must be built into a model used by at least one of the objects in the network model. This support is provided by the model developer and should be described in the model documentation.
94-Fram
Modeling Concepts
Creating Extended Attributes When creating an extended attribute, you can add it to any network object that may need it. Extended attributes become primary attributes of an object and automatically appear in the objects Attributes dialog box. To create an extended attribute Modeling Framework 1) Select Edit Attributes from the object pop-up menu to display the objects Attributes dialog box, then check the Advanced check box. 2) Left-click the Extended Attrs. button
3) The Extended Attributes dialog box pops up with a data table for creating new attributes.
4) Enter the name of the attribute in the New Attribute text entry area and left-click the Add button. You can also type directly in the data table by left-clicking a cell in the Attribute Name column. Be sure the name meets the requirements described in the Attribute Properties table on page 87. The attribute is added to the table and automatically assigned a type and default value. 5) Under the Type column, select an appropriate data type from the pull-down menu. Possible data types are described in the following table.
95-Fram
Modeling Concepts
Attribute Data Types

Data Type Integer Double Description Positive or negative whole numbers with a magnitude less than 231-64. Positive or negative double-precision oating point numbers with a magnitude less than 10100. These attributes typically represent precise numerical quantities. Characters representing the name of an object or property. Value representing an enabled or disabled state. Character string representing a file that is part of Planner OPNETs system of managed files. These refer to a specific type of file identified by a .gdf suffix at the end of the file name, as seen in your model directories. For more information on typed files and their suffixes, refer to the System Environment chapter in the External Interfaces manual. A grouping of several attributes into a single attribute value. Compound attributes allow you to describe a complex set of characteristics for an object by dening typical values for a single compound attribute. For instructions on dening compound attributes, refer to Compound Attributes on page 91.
String Toggle Typed File
Compound
6) Type in the units to be associated with the attribute, if any. 7) Type in a default value for the attribute. 8) Left-click OK to save the information and close the dialog box.
96-Fram
Modeling Concepts
Modeling Framework
The new attribute appears as a primary attribute of the object.
Extended attribute
Deleting Extended Attributes The Extended Attributes dialog box also allows you to delete extended attributes. To delete an extended attribute, select it and click the Delete button. Editing Extended Attribute Properties You can edit the properties of extended attributes using the standard (editable) version of the Extended Attributes dialog box. To edit the properties of an extended attribute 1) Left-click the Edit Properties button in the Extended Attributes dialog box. An editable version of the Attribute Properties dialog box pops up.
97-Fram
Modeling Concepts
Note: Only private attribute properties can be edited. 2) Change the extended attributes properties as desired. Descriptions of the properties appear in the table Attribute Properties on page 87. Instructions for changing the range, symbol map, and comments properties appear in the following subsections. 3) Click OK when you are done editing the attributes properties. Range The range property allows you to specify a range of allowed values for the attribute. If you specify a range, only values within this range can be assigned to the attribute. Any value specied for the default value property must also be within this range. You can create symbols with values outside the specied range, but you will not be able to assign such symbols to the attribute. You can specify a range of values only for attributes with a data type property of integer or double. The range property is inactive for all other data types. To specify a range of values 1) In the pull-down menus following the From and To elds, specify whether the beginning and end of the range of values are inclusive, exclusive, or open: Inclusive indicates that the specified number is included with the range of values.
98-Fram
Modeling Concepts
Exclusive indicates that the specified number is excluded from the range of values. Open indicates that there is no limit for the corresponding field.
The default value for both elds of the range property is open, indicating that the attribute value has no lower or upper limits. 2) In the From eld, enter a number for the beginning of the range or leave the eld empty for a lower limit of negative innity. 3) In the To eld, enter a number for the end of the range or leave the eld empty for an upper limit of positive innity. Range Example
With these values of the range property, attribute values must be: greater than or equal to 10, and less than 20.
Modeling Framework
Symbol Map The symbol map property allows you to dene symbolic names for specic attribute values. The names used in symbol maps can represent common or frequently used values of the attribute described by this property. For example, you could dene a symbol called T1 for the data rate attribute of a model and assign the value 1.544 Mbps to that symbol. Users of the model could then specify the T1 data rate without having to remember its actual value. Symbol maps are particularly valuable when used with compound attributes (described in section Compound Attributes on page 91), where they allow you to specify an extensive conguration with a single symbolic value. In addition to serving as an enumerated list of common values, a symbol map can also restrict attribute values to only those values in the list. If the Allow Other Values check box is deselected (the default), only attribute values in the symbol map are permitted. The following restrictions apply to symbol maps: If you specify a range of allowed values with the range property, you can create symbols with values outside this range, but you will be unable to assign such symbols as attribute values.
99-Fram
Modeling Concepts
If you use the symbol map to restrict attribute values, the value of the default value property must be one of the symbolic values.
To create a symbol map 1) Type a name into the New Symbol text entry area of the Attribute Properties dialog box and click the Add button. (You can also enter new symbols to the table by typing directly in an empty cell of the Symbol column.) The symbolic name is added to the Symbol Map data table.
2) Enter a value for the symbol in the adjacent cell of the Value column. If a range is specied, this value must be within it. 3) Repeat steps 1 and 2 for each symbol desired. 4) Specify whether attribute values other than those in the symbol map are allowed.
100-Fram
Modeling Concepts
5) To allow the attribute to have assigned values other than those in the symbol map, select the Allow Other Values check box. The model user can assign attribute values that are defined by the symbol maps.
6) To restrict attribute values to only those in the symbol map, deselect the Allow Other Values check box. Modeling Framework The model user is now restricted to selecting those attribute values that are defined by the symbol maps.
7) If you restricted the attribute values in the preceding step and the current default value is not one of the allowed values, select a new default value from the Default Value pull-down menu. Any symbols that have been dened will appear on this menu. Comments The comments property provides a way to describe an attribute to users of a model. Information you type in the text entry area provided will be available to anyone viewing the attribute properties. The comments you provide in this property should include a denition of the attribute, how it is used by an object, and any other information that may be helpful to the model user. Fram.3.5 Model Attributes In many cases, processes or system components can be viewed as particular forms of more general models. Generalizations result from isolating fundamental properties of the model and determining which ones may be desirable to think of as congurable. One of the primary advantages of developing models in this way is that they become highly reusable and the modeler can benet to a greater extent from pre-existing models. The generalized models can be thought of as model classes that are maintained in libraries and that can be specialized at the time they are used. For example, a process model that implements a ow-control protocol may place a limit on the number of transmitted messages that can remain unacknowledged at any given time; this number is usually called the protocols window. When developing such a model, it is useful to view the window as a exible parameter of the protocol rather than as a constant, so that if appropriate, multiple ow-control processes can be deployed as part of a system model, each with its own window size value. The second benet is that future modeling efforts may reuse the model, even if a different window size is needed. This approach is in contrast to that of creating multiple process models, each with hardwired window size values.
101-Fram
Modeling Concepts
Key Concepts A model developer may use attributes in order to expose appropriate control to its external users. Exposing a characteristic or feature as an attribute extends the applicability of the model by allowing it to be adapted to more diverse situations. The model is therefore more general and reusable.
Model attributes are dened only by the model designer; OPNET accords no semantic value to them. The knowledge of what model attributes represent and how they are to be used must be embedded by the model designer within the models themselves. In general, this type of processing of attribute assignments must be performed by program logic. In OPNET, this is possible both in process models and in pipeline stages (models for link behavior). In the vast majority of cases, model attributes are analyzed and processed by process models.
Key Concepts Model attributes are developer-defined and unknown to the OPNET system. Their meaning and use are determined by the models themselves.
Model attributes exist in three types of models in OPNET: Process, Node, and Link. These types of models can all be assigned to the model attribute of appropriate objects. When this assignment occurs (usually as part of the object instantiation), new copies of the model attributes are physically created for the object. The attributes are integrated into the objects attribute list as though they were part of the object itself. Each object that is an instance of the model has its own private copies of the model attributes, and these can be accessed independently.
102-Fram
Modeling Concepts
Inheritance of Model Attributes by Objects

Objects O1, O2, and O3 are instances of model M
O1
O2
O3
Modeling Framework
Objects O1, O2, and O3 inherit attributes of model M
Key Concepts A models attributes are inherited by objects that depend on the model. They are added into the objects set of attributes and treated as if they belonged to the object.
Fram.3.6
Objects and Attributes Each object provides a list of attributes that offer control over various aspects of the objects functionality. These attributes can originate from a variety of sources in the OPNET system. Many of the attributes of common OPNET objects are simply intrinsic to the objects core denition. These are referred to as built-in attributes and are permanently associated with the object. All OPNET objects have some minimal set of built-in attributes that are considered fundamental for each type of object. The set of specic built-in attributes will vary depending on the type of object, in order to allow conguration of appropriate functionality. For example, a node object always possesses attributes describing its position, and requires a model attribute to designate the model that species its characteristics. A state in a process model possesses only built-in attributes, including the enter and exit executives, and its status. Virtually all OPNET objects have a built-in attribute called name which serves as a unique identied for the object within the model. Refer to the Modeling Reference manual for detailed information on the built-in attributes of each supported object.
103-Fram
Modeling Concepts
One particular attribute called model plays a special role in OPNET. As mentioned previously, this attribute species a large part of an objects characteristics. Among these characteristics are additional attributes may be acquired by an object when its model is designated. These additional attributes are dened within the model and relate to congurable functionality that is specic to the model. The functionality can be independently controlled for each model instance. Finally, certain OPNET objects support the ability to append attributes to their attribute list. These are called extended attributes and are created one at a time for each object that requires them. Because each extended attribute must be dened and assigned separately for each object, this mechanism is generally much weaker than placing the attributes within models, as discussed above. However, there are some objects that do not support a model attribute, and in some cases, model developers may have a need to associate new data with those objects. Underlying models can generally not rely on the existence of these attributes since they are created manually. Therefore, the existence of an extended attribute is generally veried using the Kernel Procedure op_ima_obj_attr_exists() before it is used. If the attribute is present, then its value can be extracted and processed. In fact, in certain scenarios, the existence of the attribute is all that is of interest; the attribute in effect serves as a tag, designating a particular object as special. For example, subnetwork objects in the Network Domain do not have a model attribute. If for some reason, a particular subnet needs to be designated as special, an extended attribute called special could be manually added to the corresponding object; logic in underlying process or link models could check for the existence of special on each subnetwork object, and take appropriate action based on this information. Aggregation of Attribute Sources into an Object Attribute List
OBJ
Built-In Attributes Model Attributes Extended Attributes
Built-in, model, and extended attributes are grouped into a single object s attribute list.
104-Fram
Modeling Concepts
Key Concepts Each object maintains a list of attributes that provide external control of the objects functions and behavior. Object attributes may come from several different sources: they may be built-in to the object; they may be inherited from the objects model; or they may be appended to the object as extended attributes.
Modeling Framework
Attribute Promotion Earlier in this section, it was mentioned that models are one of the sources of attributes for objects. The attributes that a model makes available to its instances can originate from two separate sources. The rst source, model attributes, represents an explicit denition of a newly created attribute that should be passed on to objects. Model attributes were discussed in a previous section of this chapter. The second source is referred to as object attribute promotion Attribute promotion . provides a mechanism for moving an attribute of an object at a lower level in the modeling hierarchy to the next higher level. The attribute is said to be promoted, and its value appears as shown below. Presentation of Promoted Attributes
Instead of having a value, the pattern attribute of this object is promoted.
Promoted object attributes actually promote to the attribute interfaces of the encompassing model. Thus, the promoted attributes of various objects may appear together in the models attributes. These attributes combined with those declared as model attributes form the models aggregate attribute interface.
105-Fram
Modeling Concepts
Key Concepts An object attribute may be assigned a value in order to specify desired functionality. Alternatively, the assignment may be deferred so that it becomes an attribute of the encompassing model. The object attribute becomes part of the models attribute interfaces. The attribute is said to be promoted.
When a promoted object attribute is added to the models attribute interfaces, it is prexed with the name of the object it belongs to. This ensures that no naming conicts occur between attributes with the same name but belonging to different objects. The prexing mechanism is illustrated in the following diagram. Prexed Naming of Promoted Attributes
The name of the Node Domain antenna object, Phased Array and its promoted attribute pattern combine to form the name of the attribute that appears on the Network Domain object.
Network Domain Node Domain
Promoted attributes may travel several levels through the model hierarchy. They simply continue to promote until they receive an assignment at one of the higher levels. Thus, a promoted attribute of a module within a node model can promote through the node models interfaces and appear on a node object in the network level. If the node object provides no assignment for that attribute, then it will promote to successively encompassing subnet objects. The highest object in the model hierarchy is the top subnet which may also receive the attribute. In this case, the attribute is considered an attribute of the overall system model and can be set at simulation run time. This provides a convenient mechanism for iterating through a range of system parameter values in different simulations. Because the
106-Fram
Modeling Concepts
promoted attribute is a parameter of the system itself, there is no need to reenter and edit the model in order to specify its value. Automated suites of simulations can therefore be set up. The following diagram illustrates the concept of promotion to the boundary of the system model. Promotion of an Attribute through the Hierarchy to the System Level
System Level Attributes System Boundary Because M3 is the system model, O3.O2.O1.P promotes across the boundary and becomes a system attribute.
Modeling Framework
M3
Level 3 (highest level) Model M3 includes Object O3 which depends on M2
O3
O2.O1.P appears in O3s attribute list and is promoted
M2 Level 2 Model M2 includes Object O2 which depends on M1 O2.O1.P appears in model M2s attribute list O2
O1.P appears in O2s attribute list and is promoted M1 Level 1 Model M1 includes Object O1 O1 O1.P appears in model M1s interfaces
Object O1 promotes attribute P
Key Concepts When an attribute is promoted, it travels upwards in the system model until it receives an assignment. If an attribute promotes through all levels of a model, it becomes an attribute of the overall system. Its value can then be set when running simulations, allowing you to evaluate the system for different values of the attribute, with no model changes.
107-Fram
Modeling Concepts
In-Simulation Attribute Assignment So far in this chapter, two mechanisms have been presented for assigning attributes. The rst is to assign them during model specication. This is done via the OPNET editors or via other external interfaces provided by OPNET. Frequently default values are simply left in place, but this still is considered an assignment that is part of specication. A second mechanism is to defer assignment, specifying instead that an attribute be promoted to the top level of the system model. The attributes value is then specied at the start of the systems simulation. In fact, one of these two mechanisms must be used for each attribute within a model because OPNET cannot allow the simulation to begin without every attribute having some denite value. Once a simulation begins, a third form of attribute assignment can be performed. This is dynamic attribute assignment which can be performed by processes running within the simulation. By allowing object attributes to be updated as a simulation progresses, OPNET supports the development of advanced system models where components adapt their behavior and their denition based on relevant events and system conditions. For example, an antenna object may be reoriented in a new direction as a result of a low signal-to-noise ratio (SNR) being measured; a queue module may reorganize storage limits on its subqueues in order to accommodate a higher rate of highpriority packets; and a radio transmitter may modify the power that it uses to transmit in order to achieve better link quality or reduce the interference it produces for other transmissions. In all of these cases, and for all other dynamic modication of attributes, the intelligence to decide when an attribute should be changed must be provided by user-dened logic. Typically, these types of decisions are taken by a process model, but occasionally it may be more appropriate to include them in a links pipeline stage. The choice of where to locate the decision-making logic should be based on the availability of the information required to make a determination. For example, the role of controlling an antenna to optimize the measured SNR may best be performed by a processor that is adjacent to the antenna and its receiver; this would allow convenient measurement of the SNR via a statistic wire. The following diagram depicts the arrangement.
Key Concepts Attributes can be set when specifying a model, before running a simulation, or dynamically during simulation. Dynamic attribute access provides important support for creating models of adaptive systems. In these systems, decision making components can control other components (or themselves) in response to changing conditions.
108-Fram
Modeling Concepts
Node Subsystem Allowing Antenna Control Based on Receiver SNR

Ant_Cntrl uses process model that dynamically modifies Antennas attributes statistic wire allows Ant_Cntrl to use values of Rxs SNR
Modeling Framework
antenna attributes that Ant_Cntrl can modify include pointing parameters
Certain attributes that are available during specication are not available during simulation, and vice-versa. In particular, attributes that control model display, such as icons and colors, are typically omitted during simulation. See the Modeling Reference manual for more information on the availability of particular attributes during simulation. the Kernel Procedures op_ima_obj_attr_set() and op_ima_obj_attr_get() to set and get attribute values, respectively. The values that are assigned or extracted are represented as C datatypes which the model developer may have declared as variables or directly specied as constants, as shown in the following examples. Processes use
109-Fram
Modeling Concepts
In-Simulation Attribute Assignment

/* Set the data rate of the channel to minimum value. */ op_ima_obj_attr_set (channel_objid, "data rate", 9600.0); /* Compute the packet-holding capacity of the queue */ /* and assign half of it to each subqueue. */ pk_cap = max_timeout * (data_rate / AVG_PK_LEN) * 0.5; op_ima_obj_attr_set (subq0_objid, "pk capacity", pk_cap); op_ima_obj_attr_set (subq1_objid, "pk capacity", pk_cap); /* Disable the regular interrupts for this processor. */ op_ima_obj_attr_set (proc_objid, "intrpt interval", OPC_BOOLDBL_DISABLED);
Modifying an attribute during simulation may trigger actions beyond the mere replacement of its value. Changes in attributes that specify behavior of objects may require that instant action be taken to maintain consistency of the objects denition and the state of the system. For example, changing the capacity of a subqueue object in such a manner as to cause the current contents of the subqueue to exceed the new limitation requires that part of the subqueue be drained. Another common case involves the in-simulation modication of a processors intrpt interval attribute, which requires that a new event be scheduled, or that a pending event be canceled, depending on the new assignment. See the attributespecic documentation in the Network Reference and Node Reference chapters of the Modeling Reference manual for more information on the actions triggered by changes in each attribute. Restrictions on Modifying Attributes The properties of attributes may be dened to perform checks on values that are assigned to them. These checks are designed to prevent inconsistent or nonsensical values from being inserted, and eventually used during simulation. For example, the data rate attribute of a transmitter channel should never be negative or zero, since this would it make it impossible to compute meaningful packet transmission times. Each attribute denes its own validity criteria, as documented in the Network Reference, Node Reference, and Process Reference chapters of the Modeling Reference manual. During specication, an attempt to assign an unacceptable value will simply cause an error message to be displayed and the assignment will not take hold. An improper assignment will generate a nonfatal error, and op_ima_obj_attr_set() will return an appropriate completion code. While some attributes allow themselves to be modied only according to certain rules, others allow no modications whatsoever. Typically, attributes relating to identication, or key structural attributes such as the model attribute of a node, do not allow their value to be changed during simulation. However, these
110-Fram
Modeling Concepts
attributes may be modied freely during specication. The write permissions property of each attribute may vary between specication and simulation activities; see the documentation in the Modeling Reference manual for more information on each particular object attributes write permissions.
Key Concepts Dynamic access during simulation is possible only for certain attributes, and must respect the properties of the attribute. Access is provided by official program interfaces called kernel procedures, or KPs. These ensure that only authorized operations are performed on the attributes.
Modeling Framework
Fram.3.7
Model Attribute Interfaces The concept of a models attribute interfaces has already been loosely referred to. Strictly speaking, a models attribute interfaces does not encompass those attributes declared as model attributes, though both sets of attributes do contribute to the interface of the model. Model attributes are considered separately because they are declared and fully dened in one place. In contrast the models attribute interfaces represent modications of other attribute denitions, as will be described in this section. The attribute interfaces of a model consist of several fairly different types of components and so the name attribute interfaces can be confusing. These components are summarized in the following table. Model Attribute Interface Components
Component Attribute Interface Descriptions Description Collects the promoted attributes originating in objects that are included in the model. This may include attributes that belong to local objects due to promotion from lower level domains. Allows various operations to be performed on these promoted attributes prior to their promotion to the models interface, including: changing attribute names; merging multiple attribute into a single attribute; modication of certain properties, such as range, comments, etc.; and hiding of attributes (preventing them from appearing in models interfaces). Stores developer-provided keywords in the model to allow OPNET editors to create a working set of models that match a users interest. Keywords generally describe major characteristics of a model that a user may think to search for.
Model Keywords
111-Fram
Modeling Concepts
Model Attribute Interface Components

Component Comments Description Descriptive text intended to aid a user in working with the model. Can contain any amount of general text. Typically describes a models functionality, major physical or logical interfaces, assumptions, and restrictions. Certain types of models may be applicable for multiple types of OPNET objects. However, the model developer can restrict the set of object types that the model can support using this attribute interface component. Also allows specication of an icon to be used to represent the model for each supported object type.
Supported Object Types
The unifying concept of attribute interfaces is that they play a role in shaping the external view of the model. That is, they help to determine what will be seen by a user who is working with the model as a class in order to create new objects.
Key Concepts Model attribute interfaces is a term used to group together a number of different definitions of a model. The common trait of these definitions is that they specify the external appearance of a model from a users point of view.
Attribute Interface Descriptions The most complex aspect of model attribute interfaces is the interface descriptions specication which relates to promoted object attributes. All attributes promoted from the models objects are regrouped in the attribute interfaces. The role of the interface descriptions is to allow a number of changes to be made to these attributes prior to their promotion to the next level. Attribute Renaming The most common use of the interface descriptions involves changing the name of a promoted attribute. The operation, called attribute renaming, establishes an equivalence between the attributes previous name and a new name. This is needed to provide meaningful attribute names to the model user. In particular because attribute names are prexed with object names when promoted, it is usually desirable to change the name to no longer include the prex in order to simplify presentation and to hide underlying model information (i.e., the name of the internal object is not meaningful to the model user). When renaming an attribute, the new name is the only one that is visible to users of the model via OPNETs user interface. In other words, when an object is
112-Fram
Modeling Concepts
created which is an instance of the model, the object acquires the attribute and presents it using the new name. However, internally to the model, the previous name of the attribute still applies. Thus, processes that refer to the object attribute in the context of the object itself must continue to use the previous name when op_ima_obj_attr_get() and calling Kernel Procedures such as op_ima_obj_attr_set(). During simulation, the Simulation Kernel cannot assume that all entities that have some need to access a renamed attribute are aware that the renaming has occurred. In fact, renaming usually occurs as a cosmetic operation long after process models have been dened when only the original attribute names were known. In order to support the continued use of the previous name by such entities as process models and pipeline stages, the Simulation Kernel supports both attribute names in the context of the model instance. Though the original name cannot be seen in any part of the user interface, the simulation itself can continue to operate correctly. The renaming mechanism is illustrated in the following diagram. Attribute Renaming
Modeling Framework
M O.P Q
Attribute appears as Q in model Ms interfaces Model Ms Interface Descriptions (IDs) change name from O.P to Q
ID
O.P->Q
O.P Object O promotes attribute P making it available for model Ms attribute interfaces
OPNET maintains a shadow of Q using the original name O.P in case processes refer to it as such. Q and O.P are merely different names for the same attribute
Key Concepts The most common use of model attribute interfaces is to change the name of an attribute as it promotes to the next level. This allows the attribute to appear more familiar or appropriate to the user of the model. This operation is called attribute renaming.
In addition to an attributes name, interface descriptions can also apply changes to attribute properties. Each of the properties of an attribute including its default value, numerical range, symbol map, and comments can be modied before being promoted to the models interface. It is very common for presentation-related
113-Fram
Modeling Concepts
properties such as comments and the symbol map to be changed, since node models are often prepared with specic types of users in mind, and appropriate text may be selected to match the users backgrounds. When property changes are made via the interface descriptions, the new changes must be compliant with specications set forth by the previous attribute properties. The changes are able to specialize the model further by constraining the choices that the user can make, but they cannot allow the model to violate any of the constraints that existed previously. Thus, the interface descriptions must not allow a model that would be invalid from the point of view of previous denitions. This rule affects only certain components of properties: numerical ranges, symbol maps, and default values. Constraints are documented in the following table: Constraints on Property Changes in Model Attribute Interfaces
Property Range Constraint If the range property is altered, then it must be included within the previous range. In other words, no value in the new range must lie outside the previous range. See below for possible constraint violations on other properties that may occur as a result of changing the range. If the previous symbol map does not allow other values, then no symbols with new values may be added. The values in the symbol map must be included in the previously specied range (but not necessarily the new one). In the particular case of attribute merging (see below), the symbols must be included in the new range. The default value must be included in the specied range.
Symbol Map
Default Value
Key Concepts Changes imposed by the attribute interfaces often have to do with altering the properties of the promoted attributes. Common changes involve the attributes range, symbol map, and comments. The new property configurations cannot allow violation of the constraints imposed by the previous properties.
114-Fram
Modeling Concepts
Inheritance of Attribute Properties When conguring an attributes properties as part of a models attribute interface, each property can be assigned an inheritance status. The inheritance status determines whether the property should be tied to the same property in the denition from which it originates, or whether it can be altered. Because each property maintains its own inheritance status, it is possible to have some properties inherit their conguration from the original attribute denition, and others be altered. The following dialog box from OPNETs Node Editor shows the controls that are used to select the inheritance status for certain attribute properties. Symbols maps have a slightly more complex behavior than other properties with respect to inheritance of their denition. Rather than require that a symbol map be entirely inherited or redened, OPNET allows inheritance to be controlled on a per-symbol basis. The allow other value component of the symbol map also can be inherited or changed. If other values are allowed, then additional symbols can be created and their corresponding values dened. These symbols have a status described as add, meaning that they are to be appended to the symbol map. A symbol that is included in the previous denition of the attribute can be removed from the symbol map by using the suppress status. If the symbol is to be kept, it can be given the inherit status, meaning that it will continue to track its original denition. And nally, the same symbol can be re-used but given a different value by using the replace status. The following illustration depicts a symbol map including symbols with each of these status values. Symbol Status Values
Modeling Framework
K_High is inherited from the previous symbol map and remains. K_Conserve will no longer appear in the symbol map
K_Error continues to appear but now represents a new value
K_Special is a new symbol
Attribute Merging Attribute interfaces support another useful mechanism for the transformation of attributes prior to promotion. This mechanism is called attribute merging and
115-Fram
Modeling Concepts
allows multiple promoted attributes to be combined into a single attribute. While the individual attributes still exist within the context of the model, from the perspective of a model user, one attribute appears. Besides information that may be presented in documentation there is no evidence in OPNETs user interface that the attribute represents multiple underlying object attributes. Attribute Merging
M P Attributes O1.P1, O2.P2, O3.P3, and O4.P4 are merged together and represented just by P in model Ms interfaces
O1
O2
O3
O4
ID
Merge
P1
P2
P3
P4
Attribute merging is generally used in situations where a model contains many similar objects and each of them promotes their attributes. For particular realworld applications, it may only make sense to have all of these attributes behave identically under all circumstances. To accomplish this, attribute merging is used to tie the attributes together. For example, consider a node model of a switch that contains 16 transmitter and receiver objects, each with their own transmission rate. Now, further assume that for the real world device that this node model represents, different transmission rates are available from the manufacturer, but that in all congurations, all 16 ports always use the same transmission rate. To prevent users from causing these transmission rates to diverge, it would be advisable to merge the attributes into a single attribute which could be called the switchs transmission rate. Using attribute merging then provides the important additional benet of reducing the specication effort required by the user of the model, since only one attribute value need be specied, rather than 16. The behavior of merged attributes as a set is dependent on the level from which they are accessed. From within the scope of the model, each can be individually modied and examined. Thus, they may be made to have differing values. From within the context of the model instance, the attributes are unied, and a change to the merged attribute is propagated to all of the individual underlying attributes. However, for the same reason that old attribute names are supported by the Simulation Kernel when attribute renaming occurs, individual attributes with original names are supported for the rename mechanism. Thus, even though the attributes do not appear on the model instance in the user interface, they can be addressed via the Simulation Kernels Ima package APIs. Note that the possibility of diverging underlying values for a merged attribute raises the special case of which value to return when the merged attributes value is queried using
116-Fram
Modeling Concepts op_ima_obj_attr_get(),
or the Simulation Kernels debugger, for example. If such a situation occurs, OPNET chooses not to return a value since the merged attributes value is ambiguous. Instead, a special code is returned that indicates that diverging values are present. Refer to the op_ima_obj_attr_get() section of the Simulation Kernel manual for information on this topic.
Key Concepts A models attribute interfaces can collapse a group of attributes at the local level into a single attribute seen by the models users. The attributes are said to be merged. This mechanism is useful when many objects promote the same attribute and it is known that all of these are logically tied together (i.e., they must always have the same value).
Modeling Framework
As an attribute promotes through a models interface and is inherited by a model instance, the attribute can be placed into one of several states. This state is referred to as the attributes status and offers an important control mechanism to the model developer. The status values and their effects are presented in the following table. Attribute Status Values
Status promoted Description The promoted attribute appears at the next modeling level and is initially promoted there as well. The promoted attribute appears at the next modeling level with a specied initial value. It does not promote beyond the next level, unless action is taken to explicitly promote it there. The promoted attribute exists at the next modeling level, but does not appear. A specied initial value is assigned to the attribute and cannot be changed at the next modeling level (no access is possible in the user interface). Because the attribute exists at the next level, it can be accessed during simulation. This mechanism is useful to reduce long lists of attributes when their values can be known in advance, or if their values are not relevant.
set
hidden
117-Fram
Modeling Concepts
Key Concepts When an attribute promotes through a models interfaces to an instance of the model, the interfaces select one of three possible status settings, determining whether: 1) the attribute appears promoted on the object; 2) the attribute appears with a particular initial assignment; 3) the attribute receives an assignment but doesnt appear.
Attribute property changes apply not only to promoted object attributes, but also to selected built-in attributes of model instances. For example, the altitude attribute of a node object can be controlled using the attribute interfaces of a node model. A user may want to constrain the altitude of the node to be above a certain height for example, in which case the range properties of the attribute would be edited. Like promoted attributes, the built-in instance attributes can be given a status. This capability is often used to hide unimportant attributes of the instances, in order to simplify the objects attribute lists. In general, this is a good practice since attribute lists can become unnecessarily long and confusing for the model user. Of course, attributes that are relevant, but must have a particular value for proper operation of the model, can be assigned and hidden to ensure no changes by the model user.
Key Concepts Model attribute interfaces also provide control over certain built-in attributes of objects that depend on the model. Like promoted attributes, the supported built-in object attributes can be promoted, pre-assigned, or hidden. This is an important mechanism, if the models proper operation relies on specific settings for these attributes.
Supported Object Types Several types of OPNET models (including node, link and path models) can be used to instantiate more than one type of object. For example, if Modeler/Radio is used, a node model can be applied to a xed, mobile, or satellite node. Similarly simplex point-to-point, duplex point-to-point, bus, and tap link objects all make use of link models. Because certain models make sense only for particular types of objects, OPNET provides the ability for certain types of models to distinguish between supported and unsupported object types. This allows OPNET to permit only proper instantiation of the model. Depending on the model type, additional information related to the supported objects may be specied via the same mechanism. In the particular case of node, link and path models, icons used to represent the objects in graphical network models are designated for each supported object type. These icons appear in the editors object palette as well as in the network diagrams. The gure below shows a dialog box section used to specify supported node object types for a node model.
118-Fram
Modeling Concepts
Supported Node Type Specication
Mobile and satellite nodes cannot make use of this node model.
Modeling Framework
Model Keywords At the time when models are instantiated, OPNET editors must offer the user a choice of the model that is to be used. In particular, the Project Editor makes use of an object palette to present available node and link models. Each model is represented by an icon, as described under Supported Object Types on page 118. Users drag the icons from the palette in order to create a new object which is an instance of the corresponding model. The models that are represented in the object palette are stored in the host machines lesystem and OPNET can be congured to search particular directories for models. Nevertheless, the list of link and node models present in these directories may be extremely long and probably contains many models that are not relevant to the work at hand. Unfortunately, this can cause the object palette to become large and cluttered. Consequently, it may become difcult for users to locate models of interest. In order to solve this problem, and in general to facilitate searches for models, OPNET provides a model keyword mechanism for certain types of models. Currently for node, link and path models only, OPNET allows a list of keywords to be specied. Any number of keywords are permitted and each acts independently. In the Project Editor, the object palette can be made to lter the model set against a list of desired keywords. In this way, the palette can be made to present only those node and link models that are relevant to the current project. The reserved keyword hidden is used to indicate to OPNET that the model should not be shown, even if other keywords match criteria specied by the user. Only if the keyword hidden is explicitly specied will the model be presented. This mechanism is useful when it is decided in advance that a model should rarely be shown due to the low likelihood that users would be interested in it. It is particularly useful in conjunction with the capability called Model Derivation, which is described in a subsequent section of this chapter. Model Comments The model attribute interfaces incorporate comments that can be used to provide users with general documentation about the model. Model comments consist of general unstructured text, allowing the model developer to specify information in an arbitrary format. The comments have no functional role and can
119-Fram
Modeling Concepts
be left blank if desired, but is a very good practice to document the models interfaces in a complete manner. This allows users to make use of the model properly and to understand its functionality without having to view the model internals. Of course, if the intended users work with IT DecisionGuru or Modeler XE, they generally cannot gain access to the model internals, and model comments or other supplied documentation are their only resource for understanding the model and how to use it.
Key Concepts Models can incorporate keywords in order to identify their characteristics or the types of applications for which they are relevant. OPNET can make use of the keywords to selectively present only those models that are of interest. Model comments allow developers to provide users with general documentation of model functionality.
Fram.3.8
Derived Models In previous sections we have seen how a models attribute interfaces could be used to shape the way that the model is used from an external view point. In particular specications could be made for promoted attributes as well as a variety of other model properties. Model attribute interfaces are edited within a model and are stored as part of the model. This section presents an important mechanism called model derivation which supports applying further transformations to a model that already exists. Frequently model developers may have a requirement to tailor a model to a users application. This is particularly the case for developers who are developing model libraries and customized modeling environments for their customers. In general, customization can involve development of fundamental capabilities as well as conguration of model interfaces. The goal is usually to provide a model to the user that not only performs as expected but has an external appearance and interface that appears familiar to the user. Customization of a model can be achieved in two ways. The traditional and straightforward method is simply to rebuild or copy a model and make appropriate modications. OPNET provides another method to perform certain types of customizations without having to modify a models internal specications. Model derivation allows you to start with an existing model and to create a new model that depends on it. The new model shares internal structure with the original; however, many aspects of the models interface can be replaced. The specications that are in a derived model therefore consist of a reference to the original model, and information about how to congure model interfaces. The following diagram illustrates the relationship between the original model and the derived model.
120-Fram
Modeling Concepts
Model Derivation
M' refers to M for its core model information. M M'
O1 O1 O1 O1
D
Interface I Interface I'
Modeling Framework
Model M is an ordinary model, containing objects and with interface I.
The derivation operation applies changes to I, yielding I'.
Model M' is a derived model and so can contain no objects. It has a different interface I'.
Key Concepts Developers may wish to provide alternative interfaces for a model in order to customize it for particular applications. For this purpose, OPNET supports model derivation of node and link models. A derived model and the model it is derived from share structure, but the derived models attribute interfaces can be changed.
If a model M' is derived from a model M, then the relationship between M and M' can be called an is a type of relationship. That is, we can say that M' is a type of M. In concrete examples, we can say that a PC is a particular type of computer, and that a high speed router is a particular type of router. In each case, the derived model is a specialized version of the original model. The original model essentially supersets the capabilities of the derived model and can represent a wider variety of entities. Because M' depends on M via a reference and obtains all of its internal structure from M, any changes made to M are automatically reected in the functionality of M'. M' is said to inherit its structure from M. This inheritance mechanism is powerful because it means that changes to both M and M' can be made in one place and at one time. This avoids redundant specication and maintenance of the two models which can dramatically increase development efforts. This effect is further multiplied if multiple derivations are performed from M. For example, imagine that we have a model of a router, and from that model we wish to derive low-speed, intermediate-speed, and high-speed router models. We now have 3 models all of which re-use the same core specication, and individually describe only those aspects that make them unique.
121-Fram
Modeling Concepts
Key Concepts Changes made to a model are automatically inherited by a model that is derived from it. Thus, the core of the model can be uniquely specified and maintained. Redundancy is eliminated, and reusability is enhanced.
The specializations that can be performed in model derivation relate to the same information that can be specied in a models attribute interfaces. In other words, if M' is derived from M, then M and M' can differ in the following aspects of their interfaces: Model Interface Changes During Model Derivation
Status of Attributes Properties of Attributes Attribute Renaming and Merging Model Keywords Supported Object Types Model Comments
There is an important difference between the changes that are possible during model derivation and those that occur in the original models attribute interfaces. Model derivation changes can apply to all attributes of the model, including those that are promoted from objects as well as those that are declared as model attributes. In other words the two sets of attributes are unied and handled together for the model derivation operation.
Key Concepts Attribute interface changes that can occur during derivation are the same that can occur when editing a models attribute interfaces. However, they apply not only to the models promoted attributes originating at objects, but to model attributes as well.
As mentioned before, each model can be used to create multiple derivations. The relationship between the models is described by referring to the original model as the parent model of each of the derived models. Each derived model can in turn be the parent of additional derived models, allowing the user to form an
122-Fram
Modeling Concepts
arbitrarily deep tree of derived models from a single original model. Each new level of the tree corresponds to additional specialization of the model relative to previous derivations. The root, or base of the derived model tree is referred to as a advanced model. In other words, an advanced model is a model that is derived from no other model. The advanced model is the one that contains the core information that is shared by all of the models in the derivation tree. These relationships are depicted in the following diagram. Modeling Framework Model Derivation Tree
M is an advanced model since it is not derived from any other model Model M is the root of this model derivation tree. It stores all core model information for the other models
M0
M1
All other models are recursively derived from M M00 M01 M10
Model M10 is the parent model for models M100 and M101
M100
M101
Key Concepts If model M1 is derived from model M0, then M0 is referred to as M1s parent model. A model that has no parents (e.g., a node model created in the Node Editor), is known as an advanced model. Derivations may be performed from advanced or derived models, forming a derivation tree. The root of each tree is an advanced model.
Fram.3.9
The Object Hierarchy OPNETs Network, Node, and Process modeling domains are hierarchically related to each other. Process models are instantiated in the Node Domain, and node models are instantiated in the Network Domain. Within each domain, objects used to dene models may also have hierarchical relationships to each other. The hierarchy of objects is specic to each domain in order to support appropriate decomposition of particular types of objects. Many object types do not support
123-Fram
Modeling Concepts
decomposition. A global view of OPNETs object hierarchy is presented in the following diagram. OPNET Object Hierarchy
subnet
Network Domain Nodes pt-pt links bus links & taps subnets
Node Domain modules

(...) (...)
statwires, streams & logical associations
Process Domain states transitions
subqueues
receiver/transmitter channels
The diagram shows that subnets can be recursively included within subnets in order to form multi-level hierarchies within the network domain. All three types of node objects within the network domain can contain the same types of node domain objects. There are six types of modules (nine in the Radio version), which can be combined with packet streams, statistic wires, and logical associations to form node models. Processor and queue module objects rely on the lower-level process domain to dene their behavior in detail. Queue objects include multiple subordinate objects known as subqueues; which store packets. Receiver and transmitter objects for all types of links (pointto-point, bus, and radio) contain multiple subordinate objects known as channels that store and transmit packets. Process domain models consist of states and transitions that dene a process response to interrupts.
124-Fram
Modeling Concepts
Key Concepts OPNET objects are hierarchically related. At the network level, subnetworks can be included within other subnetworks. Nodes and links also exist within subnets. Modules exist within node objects, and the states and transitions of a process exist within queue and processor modules. Subqueues and channels also exist within modules.
Modeling Framework
During simulation, relationships between objects are often utilized to analyze a systems topology and to discover the context of an object. This type of analysis is typically performed by a process, and also sometimes by a pipeline stage. This technique can allow models to be developed in a more generic manner without imposing requirements on the way in which they are connected or the types of objects that are in their environment. OPNET denes a number of relationships between objects in order to support this type of analysis. These are described in the following table. Object Relationships
Relationship parent Description Object A is the parent of object B if it encompasses or contains object B. For example a subnet is the parent of all the nodes, links, and subnets it contains; and a node is the parent of the modules that it contains. All objects have exactly one parent, except the topmost subnet, which has none. Reverse relation of a parent. i.e., if A is Bs parent, then B is a child of A. For example, a node is a child of the subnet in which it resides. An object may have zero, one, or multiple children. Object A is an input association of object B if A and B are connected and the connection supports information ow from A to B. Depending on the type of objects, the connection object may be an input association as well. Refer to the documentation for the KP op_topo_assoc() for details. Reverse relation of input association. i.e., Object A is an output association of object B if B is an input association of object A.
child
input association
output association
During simulation, processes and pipeline stages can query the Simulation Kernel for information on the objects in the system and the relationships that exist
125-Fram
Modeling Concepts
between them by means of the Kernel Procedures (KPs) in the Topology Package. These KPs are fully documented in the Simulation Kernel manual.
Key Concepts Certain objects that incorporate user-defined logic can be designed to be intelligent about their environment. By calling KPs of the Topology Package, they can issue queries to discover which objects exist around them, how they are connected, and how they are hierarchically related.
126-Fram
Modeling Concepts
Event-Scheduled Simulation
Fram.4
Event-Scheduled Simulation The tools provided by OPNET support the specication of models that are operational, meaning that they can dynamically simulate the behavior of the described system. When implementing a model, the developer may incorporate more or less of the actual systems behavioral detail, depending on the objectives of the modeling effort. The goal is not necessarily to mimic each individual action of the system, but only to implement those mechanisms that are required by the objectives of the study.
Modeling Framework
Fram.4.1
Simulation Events and Simulation Time From a general point of view, OPNET simulations generate a sequence of states for a system model. The model evolves through these states as a function of time, based on the specications of the behavior of model components and of their interactions. To the extent that model specications are accurate, this evolution is representative of the way in which the actual system functions over time. The notion of time in a simulation is not directly related to the actual time that it takes to run a simulation (as measured by a wall-clock or the computers own clock), but simply a variable maintained by the simulation program. This variable is more precisely referred to as simulation time to clearly distinguish it from real (wallclock) time. OPNET simulations are based on a discrete-event modeling approach, where the progression of the model over simulation time is decomposed into individual points where change can take place. The OPNET term for each such point in time is an event. Each event represents a need for the model to possibly effect some change in its state or to make some decision. Certain events may result in no change in the systems state due to the fact that the actions that would cause change are specied conditionally (that is, they depend on the current state of the system and possibly on properties of the event itself). The following table lists some common actions that are modeled as events. Common Simulation Actions and Mechanisms that Generate Events
receipt of a message (i.e., a packet) or a command by a process expiration of a timer (e.g., while waiting for an acknowledgment) indication of availability of a resource indication of completion (or partial completion) of a task by a resource change in a statistic that is monitored by a process start or end of a packets transmission/reception on a link generation of a new message, command, or task by an application process failure (or recovery from failure) of a device
127-Fram
Modeling Concepts
Key Concepts A simulation moves the system model through a sequence of states in order to mimic a real system. A variable called simulation time is maintained to model the progress of time as the model state changes. The points in time at which the state of the model can change are called events.
Each time that a new event occurs, it is said to be executed by the simulation. As new events are executed, simulation time increases monotonically. Because OPNET supports modeling of distributed systems, it must allow multiple events to occur simultaneously (in terms of simulation time), and to affect different components of the system. Thus, it is possible for any number of distinct events to occur at the exact same simulation time. The simulation times at which events are executed are expressed using the maximum-precision real number supported by the host computer (this is typically IEEE oating point notation with a minimum of 15 digits of precision). There is no requirement that events be spaced regularly in simulation time; in fact, it is common for the density of events to vary signicantly as a function of time while a simulation is progressing, as shown in the following diagram: Typical Event Distribution on a Simulation Time Line
simulation time
events may cluster at the same simulation time
event densities are variable
Since OPNET simulations allow multiple events to occur simultaneously, they must also impose the constraint that all events have a duration equal to zero. If this were not the case, then it would implicitly be possible to observe a different simulation time at the beginning and at the end of an event. However, the subsequent event may be specied to begin at the same simulation time, which would force time to regress. Thus, simulation time is not allowed to progress during an event, but only between events. In fact, the time model imposed by OPNET states that simulation time is always equal to the time at which the current event began. Therefore, simulation time can be viewed as a variable that jumps to track the time specied for each new event.
128-Fram
Modeling Concepts
Key Concepts Simulation time changes only when new events occur; during a single event, time cannot change. The current simulation time is defined to be the time of the currently executing event. The simulation time does not necessarily advance by equal amounts at each event, but jumps to the next events time.
Modeling Framework
Fram.4.2
Event Scheduling and the Event List A simulation in progress can be viewed both as a generator and a consumer of events. New events are generated by the components of the simulation model in order to schedule new future activities, based on their underlying behavioral models. Events are consumed as simulation time progresses and specied event times are overtaken. OPNET simulations manage events with an event list. The purpose of maintaining an event list is to make sure that all events are executed in the proper time order. Each event has an associated time at which it is specied to occur. The requesting of new events, which requires specication of the simulation time at which they must execute, is called event scheduling. Events are said to be scheduled at particular times. Events may be scheduled for any future time, or for the current time, but never for past times, since the simulation time variable can only progress forward. It is common for new events to be scheduled for the current simulation time because this corresponds to a chain of events that cause each other, using mechanisms that are modeled as having a delay of zero. For example, transfers of packets via packet streams, or values via statistic wires, are both often performed with no delay. The simulation event list maintains all of the events in time-order so that the next event may be readily determined when the current one has completed execution. The earliest remaining event is referred to as the head of the event list, and the latest event is called the tail. During the execution of each event, new events may be scheduled, including events for the current simulation time. Thus during execution of an event, the head or tail of the event list may be replaced with a new event. The conceptual structure of the event list is depicted below for a typical set of scheduled events.
Key Concepts Events are managed by the Simulation Kernel in an event list. New events are inserted into the list by the Kernel and by entities within the model. The Kernel extracts the events from the event list and executes them in time-order.
129-Fram
Modeling Concepts
Event List Organization by Execution Time Event Execution Time 105.0 105.0053 105.0053 106.0 107.0 110.0
Events scheduled for the same simulation time are grouped in the event list Event times increase Head of the event list (earliest pending event)
200.0 200.0 200.0 204.0 204.01 205.0

Tail of the event list
The term event list only refers to the conceptual structure of the list. While the events behave as if they are organized in the form of a sequential list, they in fact are stored in proprietary data structures that support very efcient insertion and extraction of events while maintaining the required ordering. The list-like abstraction is maintained for all user-visible interfaces to the event storage. In particular, the Ev package of Kernel Procedures, used to scan the event list and query the properties of events, hides the underlying organization from the user. Once a simulation has begun, the event list may continually grow and shrink as new events are scheduled and previously scheduled events are executed or canceled. Each simulation will have its own particular pattern of growth for the event list, depending on the activities that are modeled. Since all future events that are known are scheduled and placed in the event list, a simulation need only continue if the list contains new events to execute. Therefore, if the list becomes empty as a result of executing the last remaining event, a simulation will terminate as that event completes, unless it has in turn scheduled at least one new event. An empty event list will cause a simulation to end regardless of the simulation time elapsed so far.
130-Fram
Modeling Concepts
At the beginning of simulation, the event list must receive at least one event so that execution may begin. The initially scheduled events bootstrap the simulation by in turn causing other events. A special type of event called begin simulation may be scheduled automatically for processes by enabling the begsim intrpt attribute of processor and queue modules within the node domain. Also generator modules automatically choose a time at which to issue their rst packet, based on their assigned distributions. These are the types of events that usually appear in the event list when it is examined at the start of simulation. Modeling Framework
Key Concepts The event list grows and shrinks as new events are inserted and events are executed over the course of the simulation. At the start of the simulation certain pre-defined events are inserted in the event list to allow execution begin. If the event list becomes empty at any point, the simulation completes.
Fram.4.2.1
Event Attributes In the material presented in this chapter so far, events have simply been discussed as abstract items representing simulation activities and having an associated time. In fact, OPNET simulation events have a number of important attributes that provide detailed information about the place and manner in which the event should be executed. The following table provides a complete summary of an events attributes. Note: Depending on the event type, only certain attributes may be relevant.
Key Concepts Each event has a set of event attributes that store information describing it. Some of this information is used by the Simulation Kernel in order to execute the event. The information may also be used by userdefined logic in order to process the event in a manner that depends on its characteristics.
Event Attributes Summary

Attribute Name time execution ID schedule ID module Attribute Signicance / Use simulation time at which event should be executed unique identier related to events order of execution unique identier related to events order of scheduling module (node domain object) where event will occur
131-Fram
Modeling Concepts
Event Attributes Summary (Cont.)

Attribute Name process type code Attribute Signicance / Use unique process that will receive event one of 13 supported classications of activities integer value whose interpretation depends on events type; may be user-dened for some events, or represent an arrival port index for others packet whose transmission caused event Interface Control Information structure coupled to event address of user-dened data block Object ID of module of event during which this event was caused.
packet ICI state_ptr source object ID
The following list provides more information about the event attributes listed above. timeeach event has a simulation time at which it is specified to execute. This is a nonnegative double-precision floating-point number that is used to establish an order of execution among the scheduled events. Each event must execute before all events with higher values for the time attribute. execution IDthis identifier increases by one for each event as it is executed. Its value is difficult to predict for a given event in the event list, since new events can be inserted, altering the anticipated execution order. The primary use of execution IDs is to refer to events that have already occurred, primarily while analyzing simulations interactively with the OPNET debugger, ODB. schedule IDthis identifier follows the order in which new events are generated. Each time a new event is required, it is scheduled by inserting it into the Simulation Kernels event list. Since events may be scheduled for any future time (relative to the current simulation time), schedule IDs do not relate in any predictable way to execution IDs. moduleall simulation events have a designated locality within the node domain which provides a context for their execution. For example, an event may be scheduled to model the arrival of a packet at a particular transmitter; and a statistic change relayed by a statistic wire will cause an event at a particular processor or queue. processsince there may be multiple processes within each processor or queue module, certain events must be scheduled while designating
132-Fram
Modeling Concepts
the specific process of interest. In particular, self interrupts, used to indicate that an interval has elapsed, must be delivered to a particular process within the surrounding module (specifically, the process that scheduled the interrupt in the first place). typethis attribute plays a major role in determining how an event will be processed by the simulation kernel. Depending on an events type, the kernel will invoke particular handling mechanisms to execute it. The type of an event is designated when an event is scheduled and is a function of its cause and of the way in which it is intended to be handled. There are 13 types of events, designed to support different types of modeling activities. For instance, an event of type self is scheduled by a process and implicitly returns to that same processit is used for notification of the end of a time-interval; and an event of type stream is a result of a packet being sent between two modules. Each event type is discussed in greater detail in a later part of this section. codecertain events may carry an integer code whose value is specified at the time of scheduling. The interpretation of the code varies depending on the type of event. In the case of certain generic events that serve application-specific purposes, this code provides a mechanism for the user to associate additional information with the event and to retrieve in the context where the event is executed, possibly at a later time. For example, a process may maintain many simultaneous interval timers modeled as events of type self; it may use the code associated with each event as a method of distinguishing between them. The code attribute is reserved for system use in the case of stream and statistic events where it represents the input stream and input statistic on which packets and new statistic values arrive, respectively. packetseveral types of events are used to represent activities related to packets such as their arrival at a destination, or the completion of their transmission, for example. The packet attribute simply references the packet of interest for these types of events. ICIinterface control information structures (ICIs) are multi-member data items that may be associated with events scheduled by processes. ICIs contain formatted information defined by a user-supplied format. Their purpose is to allow application-specific information, in addition to that intrinsic in a scheduled event, to be communicated to the events destination. One common use of this mechanism is to support protocol layers that pass parameters (e.g., quality of service, destination, etc.) associated with a transferred packet, in order to avoid incorporating the parameter values in the packets themselves. state_ptrthis event attribute allows a pointer to an arbitrary area of memory to be associated with an event. The content and format of the memory block are user-defined and are not known to the Simulation Kernel. The purpose of this mechanism is to support the transfer of completely general forms of data between the context where the event
Modeling Framework
133-Fram
Modeling Concepts
is scheduled, and the context where it is executed. Currently only procedure call events support the use of the state_ptr attribute. source object IDmost events are generated by one object for another object, or for themselves. For example, a generator module sends packets to other modules, and schedules events to implement the packet arrivals; and a processor uses scheduling to generate future events for itself. For these cases where an events generation can be attributed to a particular module, the source object ID is simply the object ID of that module. In cases where events are scheduled by the Simulation Kernel, such as begin simulation events, or end simulation events, the source object ID will have a special value indicating this fact. The exact interpretation of this attribute therefore depends on the event type; for more information, see the discussion of event types in a later section of this chapter.
Event Types OPNET denes thirteen event types to support a variety of modeling activities. Some event types are used only to represent very specic types of activities, while others are intended for general user-dened purposes. The following table summarizes the function provided by each event type: Simulation Event Types and Their Applications
Event Type self stream statistic regular Application Timers and delayed actions. Communication of packets between modules within the same node. Asynchronous notication of changes in statistics, semaphores, numeric signals. Automatic, periodic activities such as polling of inputs, transmission of status messages, beginning of bus cycles, etc. Asynchronous notication that a node or link has failed (i.e., condition attribute has become disabled) within the network domain (e.g., allow reconguration of routing tables). Asynchronous notication that a node or link has recovered from failure. Notication of start of simulation, allowing processes to initialize their state. Notication of end of simulation, allowing processes to record nal information such as scalar statistics, custom reports.
failure
recovery begin simulation end simulation
134-Fram
Modeling Concepts
Simulation Event Types and Their Applications (Cont.)

Event Type access remote Application Generation of a request by one process for another. Communication of commands, requests indications, or other general information between modules, without requiring any physical connections; modules may be in different nodes. User-dened purpose requiring a procedure call to occur at some future time. Simultaneous invocation of all processor and queue modules in entire modeled system. Direct invocation of a particular process within a module, rather than the root or other registered process.
Modeling Framework
procedure call multicast process
Events may be created by a number of mechanisms that may be driven by the Simulation Kernel, or by the logic that is part of user-provided models. The Kernel generally concerns itself with scheduling events that result simply from the conguration of object attributes, such as regular events that occur due to the assignment of the intrpt interval attribute of a processor or queue; another important example is the scheduling of begin simulation events for all processors and queues that have the begsim intrpt attribute enabled. User-dened processes, on the other hand, are the sources of events relating to general activities such as communication of information, accessing of resources, and handling of alarm conditions, for example. The following table summarizes the possible ways in which each event type can be generated. Event Generation Mechanisms
Event Type self stream statistic regular failure Generation Mechanism call the KP op_intrpt_schedule_self () forwarding of a packet using any of the KPs op_pk_send...(), or op_pk_deliver...() updating of a statistic, either automatically by the Kernel or by a call to the KP op_stat_write() automatically provided by the kernel if intrpt interval attribute of processor or queue is not disabled automatically provided by kernel to processors and queues that dont have the failure intrpts attribute disabled whenever a node or links condition attribute becomes disabled
135-Fram
Modeling Concepts
Event Generation Mechanisms (Cont.)

Event Type recovery Generation Mechanism automatically provided by kernel to processors and queues that dont have the recovery intrpts attribute disabled whenever a node or links condition attribute becomes enabled automatically provided by kernel at start of simulations for processors and queues that have the begsim intrpt attribute enabled automatically provided by kernel at end of simulations for processors and queues that have the endsim intrpt attribute enabled call to the KP op_strm_access() call to the KP op_intrpt_schedule_remote() or op_intrpt_force_remote() call to the KP op_intrpt_schedule_call() call to the KP op_intrpt_schedule_mcast_global() call to the KP op_intrpt_schedule_process()
begin simulation
end simulation
access remote procedure call multicast process
Depending upon the type of event, it will make use of certain event attributes described in the previous section. The event type is itself an attribute, but it is not always sufcient to describe the actual work that must be done in order to execute the event. The appropriate remaining attributes are set when an event is scheduled, and are stored with the event when it is placed in the event list. This information is then available for use in the events execution when its simulation time arrives. The following table summarizes the relevant attributes for each type of supported event. Note that standard attributes that have similar interpretation for all event types, such as time, execution ID, schedule ID, module, and type, are not presented in this table. Significance of Principal Event Attributes
Event Type self Attribute Signicance code: integer value with user-defined interpretation; typically used to identify self event among all those scheduled for a given process; accessed with op_ev_code(). ICI: optional, general info. provided when this event is scheduled. source object ID: same as module that is receiving the event. code: index of stream on which packet arrives and can be obtained; accessed via op_ev_strm(). ICI: optional, general info. provided when packet is sent. packet: packet whose reception caused event. source object ID: module that sent the packet, causing the event.
stream
136-Fram
Modeling Concepts
Significance of Principal Event Attributes (Cont.)

Event Type statistic Attribute Signicance code: index of input connected to statistic wire whose source value has changed; accessed via op_ev_stat(). ICI: optional, general info. provided when statistic is updated. source object ID: module that updated statistic, causing the event source object ID: equal to constant OPC_OBJID_KERNEL. source object ID: object ID of node or link that has failed. source object ID: object ID of node or link that has recovered. source object ID: equal to constant OPC_OBJID_KERNEL. source object ID: equal to constant OPC_OBJID_KERNEL. code: index of output stream on which access request is placed. This is the stream on which a packet would be sent to reach the requesting module; value can be obtained with op_ev_strm(). ICI: optional, general info. provided when access request is made. source object ID: object ID of processor or queue that is performing the access. code: integer value with user-defined interpretation; used to relay simple information, such as status values or command codes; accessed with op_ev_code(). ICI: optional, general info. provided when remote event is requested. source object ID: object ID of processor or queue that is requesting the event. code: integer value with user-defined interpretation; used to relay simple information, such as status values or command codes; accessed with op_ev_code(). ICI: optional, general info. provided when procedure call is requested. source object ID: object ID of processor or queue that is requesting the procedure call. state_ptr: optional pointer to area of user-allocated memory that has user-dened content; allows passing of arbitrary state to called procedure (appears as one of the procedures arguments).
regular failure recovery begin simulation end simulation access
Modeling Framework
remote
procedure call
137-Fram
Modeling Concepts
Significance of Principal Event Attributes (Cont.)

Event Type multicast Attribute Signicance code: integer value with user-defined interpretation; used to relay simple information, such as status values or command codes; accessed with op_ev_code(). ICI: optional, general info. provided when multicast event is requested. code: integer value with user-defined interpretation; used to relay simple information, such as status values or command codes; accessed with op_ev_code(). ICI: optional, general info. provided when process event is requested. process: handle of process that is invoked when the event is executed.; used by kernel to invoke the process.
process
Event Processing There are certain actions that are commonly performed when processing each type of event. These actions typically acquire information that accompanies the event in order to set up for application-specic execution actions and decisionmaking. These common actions are presented in this section, on a per event type basis, in order to familiarize the developer with the type of logic that is typically found in OPNET process models. Most processes, especially those that manage complex interactions, must be capable of handling the arrival of several different types of events while located in each state. Therefore, one of the basic actions that is performed as part of the logic on state executives and/or in transition conditions is to determine the type of event that has occurred. The Kernel Procedure (KP) used for this purpose is called op_intrpt_type() and its use is illustrated in the following example. The event type is just one of the event attributes that a process logic might analyze. In general, attributes of an event can be obtained using KPs from the Event (or Ev) Package of the Simulation Kernel. Certain KPs in the Interrupt (or Intrpt) package can also be used. The difference between Ev KPs and Intrpt KPs is that Ev KPs can be applied to any event, including future events that are still stored in the Event List. Intrpt KPs on the other hand, such as op_intrpt_type(), implicitly refer to the currently executing event.
Key Concepts When a process model handles an event, it usually needs to analyze certain attributes of the event, such as the events type, in order to determine the actions that it will take. The attributes can be obtained using KPs of the Ev and Intrpt packages.
138-Fram
Modeling Concepts
Common Process Model Forms for Processing Based on Event Type

Typical event-type processing within state executives
/* Determine the type of the event that has */ /* interrupted this process. */ event_type = op_intrpt_type (); /* Based on the event type, perform appropriate */ /* actions. Only self, stream, and stat are expected. */ switch (event_type) { case OPC_INTRPT_SELF: /* Process a self event */ . . break; case OPC_INTRPT_STRM: /* Process a packet stream arrival */ . . break; case OPC_INTRPT_STAT: /* Process a statistic event */ . . break; }
Modeling Framework
Typical event-type processing with state-transitions (assumes macros are dened for expressions STREAM, SELF, and STAT).
139-Fram
Modeling Concepts Selffor processes that may have multiple events of this type pending
at a time (e.g., a protocol that maintains multiple timers), the event code is usually of interest. How it is used is determined entirely by the process logic. Typically, the code is an identifier for an object maintained by the process, such as a particular timer, a counter to be modified, or a packet to be retransmitted. The following example illustrates the retrieval of the event code and its use: Typical Processing of an Event of Type Self
/* The event is of type 'self': obtain the event code */ /* representing the timer that has expired. */ timer_index = op_intrpt_code (); /* Depending on which timer has expired, increment the */ /* lateness counter, or make a retransmission */ if (timer_index == TIMER_ROTATION) lateness_counter++;
Streamwhen a packet arrives at a processor or queue, causing a stream interrupt, the Simulation Kernel places the packet in the input
streams FIFO queue. The process may choose to leave it there, or to accept it. Since a process may maintain several input streams (i.e., it may be connected to several sources of packets), it may need to determine the input stream via which the new packet has arrived. This determination, and the logic needed to obtain the new packet, are illustrated in the following Proto-C fragment: Typical Processing of an Event of Type Stream
/* The event is of type 'stream': obtain the index of */ /* the input stream on which the packet has arrived. */ input_stream_index = op_intrpt_strm (); /* If the packet has arrived on the stream coming from */ /* the network, accept it now. */ if (input_stream_index == STREAM_NETWORK) packet = op_pk_get (STREAM_NETWORK);
Statisticwhen a change occurs in a statistic that is the source of a sta-
tistic wire, this may generate an event for the statistic wires destination processor/queue, depending on the nature of the change and the configuration of the statistic wire object. Since the processor/queue may maintain multiple statistic inputs, the first step that is taken is usually to determine which input is associated with the event. A typical Proto-C processing sequence that reacts to a statistic event is shown below:
140-Fram
Modeling Concepts
Typical Processing of an Event of Type Statistic

/* The event is of type 'statistic': obtain the index of */ /* the input statistic connected to the active statistic. */ /* wire. */ input_stat_index = op_intrpt_stat (); /* /* /* if If the changed statistic represents the size of the */ packet queue, obtain the new value to test for a */ critical condition. */ (input_stat_index == STAT_QUEUE_SIZE) { current_q_size = op_stat_local_read (STAT_QUEUE_SIZE); if (current_q_size >= CRITICAL_LEVEL) { start_alarm (); } }
Modeling Framework
Regularthis type of event is provided by the system at periodic inter-
vals. There are no attributes of interest associated with regular events. The significance of the event varies from application to application, and so no typical example is provided here.
Failure
and Recoverythe system automatically provides these types of events to appropriately configured processors and queues when the condition attributes of nodes or links are changed to the values disabled and enabled, respectively. Typically, the processes that are affected need to determine the identity of the node or link that caused the event to occur. The following example shows how this is accomplished.
141-Fram
Modeling Concepts
Typical Processing of Event of Type Failure and Recovery

/* Determine if this is a failure or a recovery */ event_type = op_intrpt_type (); if (event_type == OPC_INTRPT_FAIL) status = DOWN; else status = UP; /* Determine the object ID of */ /* node or link whose status has been affected. */ object_id = op_intrpt_source (); /* Determine if the object is a node or a link. */ object_type = op_id_to_type (object_id); if (object_type == OPC_OBJTYPE_NDFIX) { /* Reconfigure routes as a result of node changes. */ routes_reconfig_node (object_id, status); } /* Otherwise, reconfigure to reflect link change. */ else routes_reconfig_link (object_id, status);
Begin simulationthis type of event is automatically provided by the kernel to each processor or queue that has the begsim intrpt attribute set to the value enabled. There are no special event attributes associated with begin-simulation events. In fact, many processes simply assume that their first event will be of this type, and do not even bother to determine the event type in their initial logic. This type of event is usually needed to allow processes to initialize their state variables. Since process state memory can be defined very generally by the user, initialization may involve a wide variety of actions. A typical operation performed at initialization involves learning values that have been assigned to process attributes. This is illustrated in the following Proto-C fragment.
142-Fram
Modeling Concepts
Typical Processing of an Event of Type Begin Simulation

/** This is the first invocation of this process. **/ /** Setup initial values of state variables. **/ /* Obtain the object ID of the processor in which this */ /* process is running. */ this_proc_id = op_id_self (); /* Obtain the values of the service rate and maximum */ /* packet size attributes of the processor and store */ /* these values in corresponding state variables. */ op_ima_obj_attr_get (this_proc_id, "service rate", &service_rate); op_ima_obj_attr_get (this_proc_id, "max packet size", &max_packet_size); /* Initialize other state variables. */ num_packets_processed = 0; busy = 0;
Modeling Framework
a simulation reaches termination, regardless of the reason, all processors and queues that have the endsim intrpt attribute set to the value enabled receive an event of this type. There are no special event attributes that provide additional information about the resulting invocation, and the processing that takes place can vary widely from application to application. Typically end-of-simulation tasks have to do with customized reporting based on information accumulated during an entire simulation run. The following Proto-C fragment provides an example of such processing. Typical Processing of an Event of Type End Simulation
/* The simulation has completed, except for end-simulation */ /* events. Perform final actions for this process. */ /* Compute final average performance statistics. */ total_time = op_sim_time (); average_throughput = num_packets_processed / total_time; average_utilization = total_busy_time / total_time; average_delay = total_delay / num_packets_processed; /* Write these values out as scalar statistics. */ op_stat_scalar_write ("average throughput", average_throughput); op_stat_scalar_write ("average utilization", average_utilization); op_stat_scalar_write ("average delay", average_delay);
End simulationwhen
143-Fram
Modeling Concepts
requests are issued by a module that is the destination of a packet stream. The source module receives an event and can determine which stream (an output stream from its perspective) was used to convey the request. This type of event usually (but not necessarily) indicates a request to have a packet forwarded by the source module on the specified stream. The following Proto-C fragment is an example of how a process might respond to the receipt of an event of type access: Typical Processing of an Event of Type Access
/* A request to forward a packet has been received. */ /* Determine which outgoing packet stream leads to the */ /* requesting module. */ out_stream = op_intrpt_strm (); /* If there are packets available in this modules queue, */ /* remove the highest priority one and send it. */ if (op_subq_empty (MAIN_SUBQ) == OPC_FALSE) { packet = op_subq_pk_remove (MAIN_SUBQ, OPC_QPOS_PRIO); op_pk_send (packet, out_stream); }
Accessaccess
events are generated by one processor or queue for another processor or queue. The same attributes are associated with these events as are with events of type self. However, since remote events can be communicated to other modules, and particularly, to modules that are not physically connected, they are often used to represent commands, requests, or indications. The following example shows a Proto-C specification that implements the receiving end of an interface based on remote events. Note that in this example, the event code is not used, since the more general ICI can superset the codes functionality.
Remoteremote
144-Fram
Modeling Concepts
Typical Processing of an Event of Type Remote

/* A remote event has been received; this represents a */ /* command from one of the remote nodes. */ /* Obtain the ICI associated with the event: it contains */ /* all the parameters of the command. */ ici = op_intrpt_ici ();
Modeling Framework
/* Obtain the command type parameter. */ op_ici_attr_get (ici, "command type", &command_type); if (command_type == COMMAND_FLOW_OPEN) { /* Open a new buffer for a new flow of data. */ /* Obtain relevant parameters of the command. */ op_ici_attr_get (ici, "peak rate", &peak_rate); op_ici_attr_get (ici, "flow src", &flow_src); op_ici_attr_get (ici, "flow dst", &flow_dst); /* Create the new flow. */ create_new_flow (flow_src, flow_dst, peak_rate); } else if (command_type == COMMAND_FLOW_RESIZE)
Procedure callthis is a special type of event that provides a very gen-
eral, open interface for integrating non-OPNET software into an OPNET simulation. The event results in the invocation of a procedure with a predetermined argument list. The context of the invocation is still the module where the event was originally scheduled. Several event attributes may apply, as explained earlier in this chapter, and illustrated in the following sample C language procedure definition.
145-Fram
Modeling Concepts
Typical Processing of an Event of Type Procedure Call
void discard_enqueued_packet (char* state_ptr; int code) { int subq_index; Packet* pk; /* This procedure is invoked as a scheduled event in */ /* order to remove a particular packet from a subqueue.*/ /* the subqueue is specified by the event code and the */ /* packet address is given by the 'state_ptr' arg. */ subq_index = code; pk = (Packet*) state_ptr; /* Find the packet in the subqueue, remove, destroy it. */ subq_size = op_subq_stat (subq_index, OPC_STAT_PKSIZE); for (i = 0; i < subq_size; i++) { if (op_subq_access (subq_index, i) == pk) { op_subq_pk_remove (subq_index, i); op_pk_destroy (pkptr); break; } } }
Multicastthese events are provided to all processors and queues in the
entire system model. They are typically used to support synchronized operations such as modeling a complete resetting of state throughout the system; or a delineation of epochs in the simulation, where objects are forced to reconfigure before simulation can continue. The application of the interrupt is user-defined and supports the use of an ICI and an event code. The following example shows a possible Proto-C specification for responding to a multicast event.
146-Fram
Modeling Concepts
Typical Processing of an Event of Type Multicast

/* A multicast event has occurred; examine the code to */ /* determine what behavior is expected. */ event_code = op_intrpt_code (); if (event_code == GLOBAL_RESET) { /* this event represents a globalized resetting */ /* of all state throughout the system. This process */ /* need only reset its private state memory. */ /* eliminate packets in all the subqueues. */ op_q_flush (); /* reset the state variables kept for estimating */ /* timer values. */ total_packets = 0; total_delay = 0.0; round_trip_time = INTITAL_RTT; }
Modeling Framework
Processmost event types are directed at modules in general, but pro-
cess events are intended to invoke a particular process within a processor or queues context. Often a process event is scheduled by one process for another in its same processor or queue (e.g., its parent or child process). This can be viewed as a deferred invocation, providing an alternative to the immediate invocation that is commonly used between processes. Process interrupts make use of the same event attributes as self interrupts; an example of Proto-C code that responds to a process event is shown below: Typical Processing of an Event of Type Process
/* A process event has occurred and has caused */ /* this process to be invoked. */ /* Determine the reason for invocation, which is provided */ /* as the event code. */ invoke_code = op_intrpt_code (); /* /* /* if At this point, this process can be invoked for */ two reasons: to begin transmissions or to reset */ the connection that it manages. */ (invoke_code == XMIT_START) send_packets (); else reset_connection ();
147-Fram
Modeling Concepts
Fram.4.2.2
Interrupts In addition to events, OPNET denes the related notion of an interrupt. Events may be viewed as requests for activities to occur at particular times. In contrast, interrupts are dened as the actual invocations that result from events being executed by the Simulation Kernel. In other words, events that are in the event list become interrupts only when they are delivered to the modules that they are destined for. Interrupts never actually reside in the event list.
Interrupt Attributes Interrupts have the same attributes as the events that generate them. In particular, interrupt types use the same names (stream, statistic, self, and so on). Since an interrupt is simply the manifestation of an event that is currently executing, its attributes can be accessed by obtaining a handle for the current event and applying KPs of the Ev package, such as op_ev_code(), op_ev_ici(), and op_ev_src_id(). However, since these operations are quite common with regard to the current event (that is, a process tends to need information about its current invocation more often than about future ones), a number of KPs in the Intrpt package operate implicitly on the current event. The following table summarizes the KPs that provide access to interrupt attributes; see the Interrupt Package chapter of the Simulation Kernel manual for more information on these KPs. Kernel Procedures that Access Interrupt Attributes
KP op_intrpt_type() op_intrpt_code() op_intrpt_strm() op_intrpt_stat() op_intrpt_source() op_intrpt_ici() Type Code Input stream of packet arrival (actually code attr.) Input statistic (actually code attr.) Source object ID ICI (interface control information) Attribute
Key Concepts An interrupt occurs when an event reaches the earliest position in the event list and becomes executed. The interrupt is delivered to the events destination object and has most of the same attributes as the event.
148-Fram
Modeling Concepts
Interrupt Suppression Certain events may be executed and still not result in the generation of an interrupt. This may happen as a result of various suppression mechanisms that apply to some events at the time when they are executed. The most common form of interrupt suppression is established by a process to limit the arrival of unwanted interrupts, either during a particular interval, or for an indenite period. The process can accomplish this by calling the KP op_intrpt_disable(), as necessary to affect various combinations of interrupts. Each call species a type of interrupt, optionally combined with an interrupt code. The effect of calling op_intrpt_disable() is cumulative from call to call, meaning that several sequential calls may be used to disable multiple types of interrupts. Conceptually, one may view the process as maintaining a list of interrupt lters on a per process basis (not on a per processor or queue basis). Each interrupt lter, as long as it is present, prevents a particular interrupt type and code from reaching the process, as depicted in the following diagram: Suppression of Interrupts on a Per-Process Basis
Modeling Framework
disabled interrupts disabled interrupts Type Code disabled interrupts Type Code Stream Type 0 Code Stream 0 Stream 2 0 Stream Stream 2 Remote 1002 Stream Self 100 Statistic Remote 0 100 Statistic 00 Statistic
Incoming interrupts are screened against interrupt lters before they reach a process. A processor or queue module may host several processes, each one with its own independent set of interrupt lters.
Typically, the interrupt disabling mechanism is used when a process enters a phase during which certain interrupts cannot be processed, due to some sort of a busy condition. For example, a transmission management subsystem implemented by a processor may be unable to handle more than one transmission request at a time; rather than having to interrupt its processing of a packet transmission to deal with new asynchronous packet arrivals, it may choose simply to disable all stream interrupts until it has completed the one on which it is busy working. When the
149-Fram
Modeling Concepts
current transmission has completed, the packets that arrived in the interim, but failed to cause interrupts, will be queued in the processors input stream(s). Most disabled interrupts do not automatically queue to provide an indication that they occurred. Packets causing stream interrupts do queue during the time that they are disabled because each packet contains unique information and it is usually desirable to have no gaps in packet sequences. On the other hand, information lost due to suppression of statistic interrupts, remote interrupts, or other types, cannot be recovered by a process that had disabled them. The effect of interrupt-disabling is reversible by several mechanisms. One common form of reversal is built-in to the disabling request itself; calls to op_intrpt_disable() support the specication of a parameter called next that renders the interrupt-suppression valid only for one occurrence of the interrupt; interrupt controls specied in this manner are immediately removed once they have served to prevent the delivery of a single interrupt. When suppressing interrupts for a period of time, or until some logical condition has been reached, a process usually re-enables the interrupts via the KPs op_intrpt_enable() or op_intrpt_enable_all(). The former KP is used to enable a specic combination of interrupt type and interrupt code, while the latter KP removes all interrupt controls for the process (i.e., this KP returns the process to its default state where no interrupts are suppressed). See the Interrupt Package chapter of the Simulation Kernel manual for more information on the applicability and usage of these KPs.
Key Concepts A process may prevent certain events from being delivered to it as interrupts when it knows that it can safely ignore them. This is done to simplify the process model and to improve simulation speed. Interrupts may be disabled and re-enabled based on certain attributes using the KPs of the Intrpt package.
Fram.4.2.3
Modeling Actions that Involve Delays Whether models are designed with the objective of measuring performance or analyzing behavior, it is often important to accurately model delays associated with key actions in order to obtain representative results. Common performance metrics, such as resource utilization (of links or processors, for example) and endto-end delay of messages, are largely a function of various delays incurred by messages, transactions, or jobs, depending on the application. Also, metrics such as queue sizes and throughputs are indirectly dependent on processing delays, since the delays incurred at particular locations in a system may create bottlenecks. Behavior of the system is also tied to delays, since timing of communications between components may critically affect the order in which actions are taken, and even which ones are taken. For example, delays of acknowledgments expected by a ow control and error recovery subsystem may cause an unusually high number of retransmissions, or may cause the system to
150-Fram
Modeling Concepts
reach a deadlock state, depending on its specic design. The behavior that is actually observed always depends on how the various subsystems are dened, and the interaction between subsystems is often affected by delays in communication or processing. OPNET supports a number of techniques for incorporating delays into system models. The appropriateness of the various methods depend to a large extent on the type of action with which a delay is associated, and at what point in the system the delay is occurring. The following is a list of sample actions that commonly require delay modeling: Computations required to complete a task or sub-taskcomputations of many different types are generally necessary to implement decision-making subsystems; the computations that are required in the actual subsystem (not the modeled one) should be analyzed to determine the delays they require. If these time intervals are significant, the developer should consider including them in the model. Some typical tasks requiring delays when modeling network protocols are: evaluating intactness of received data (i.e., calculation of checksums); compression/decompression of transmitted/received data; construction of a packet given some general data and header information (e.g., destination address, service class, etc.); decoding and demultiplexing of a properly received packet. For general system modeling, tasks will depend heavily on the application and may fall in a broad range, from executing signal-processing algorithms to interpreting telemetry data, or refreshing a radar display. Transmission and propagation between two componentsdepending on the physical relationship between components, or the mechanism by which they communicate, delay may or may not be a significant factor in their interaction. In some cases, communication between two components may not rely on a physical connection, but instead be implemented in an abstract form, such as when a procedure call is executed within a software program. Communication delay between two components that are physically connected via some sort of channel, can usually be broken down into two components: propagation delay and transmission delay; the former is the time required for information to travel between the two components, and the latter is time required to actually insert the information into the communication channel. In some cases, one or the other, or both may be ignored. For more abstract forms of communication, delays may represent the inherent limitations of the information transfer mechanism; in the case of a procedure call, the primary delay may result from the execution of CPU instructions required to setup arguments and transfer control to a new location in a program, as well as the possible loading of new program instructions from disk (i.e., swapping of a program segment). Reading/writing information to/from storage devicesmost systems maintain state information, either as their primary function, or in support of other activities. Certain events provoke changes in, or make
Modeling Framework
151-Fram
Modeling Concepts
use of this information, or combinations of both. The information of interest may be maintained in one or more devices depending on the systems storage architecture; these devices are typically general semiconductor memory, cache or display memory, microprocessor registers, magnetic or optical disk, magnetic tape, or in a more abstract sense, even remote databases accessed via a network. Depending on which devices are used and the volumes of data that are accessed, read and write operations may introduce significant delays into the operations they support. Reaction to a major event, requiring reconfigurationcertain events may require a subsystem to reconfigure to adapt to a modified operating environment. Such situations often occur in modeling efforts that study a systems robustness to failure of one or more components. The failure of a key component may trigger significant activity, such as recomputation of routes to bypass the lost resource, or even complete initialization of other components state. The recovery of such a component may trigger similar activities as the system attempts to maximize its use of available resources. Since robustness studies frequently include as a goal the determination of the time required to adapt to a major system alteration, the delays encountered in each involved action may be significant aspects of the system model.
The examples above merely illustrate the need to model certain delays in order to develop accurate simulations that are capable of reliably forecasting system performance and behavior; there are, of course, many other situations where the activities that are modeled require incorporation of delay effects. These examples do support a number of important points however, with regard to modeling delays: Not all delays need to be modeledcertain delays are insignificant in relation to others. Yet these delays may require as much modeling effort as those that tangibly affect the systems performance or behavior. For example, obtaining information such as the number of retransmission attempts made by a protocol, may involve a simple memory register access, and therefore incur only a minute delay; on the other hand, performing an address mapping may rely on reading a file from disk, thus requiring a much greater delay. It would therefore probably be wise to model the address mapping operations delay rather than the variable access; avoiding the additional complexity of modeling the delay of very fast operations may impact the models overall accuracy in a negligible manner. This is particularly true if a slow and a fast operation happen together or if the slower operation occurs with greater frequency. It is worth noting, however, that even a very fast operation may have a noticeable cumulative effect if it happens very often. Delay values may be difficult to obtainmany delays are not precisely known at the time of model development. In some cases the required delay values are the result of complex interactions that are beyond the scope of the modeled system. For example, disk access delays may be
152-Fram
Modeling Concepts
the result of contention for a computer bus by devices that are not even part of the system model; or the disk itself may be busy on behalf of other processes. Such variable delays could be modeled as random variables, but probability distributions must then be specified. One possible method for obtaining required delay values is to perform benchmarking on an actual component if it exists, or to obtain estimates from the components manufacturer. If a component is hypothetical, the modeler must simply provide educated estimates for the delays, or treat them as system parameters that can be used as the basis for parametric evaluation (that is, as different delay values are considered, what is the effect on system performance?). In all cases it should be noted that OPNET has no prior knowledge of the components being modeled and is therefore not cognizant of the appropriate delay values; nor does it realize which actions are associated with significant delays, and which ones represent negligible delays. It is the responsibility of the model developer to supply these basic values; in turn, it is the role of the OPNET simulation to emulate the specified delays and to therefore implicitly produce representative behavior and performance with correct aggregate delays as well as other phenomena. Certain actions of the real system may be modeled exclusively by their delayin many cases, the operations of an actual system will not be modeled in complete detail, either for simplification, or because they would not impact the simulations operation. For example, the receipt of a packet by a data-link layer protocol may involve as a first step, the verification of data integrity by means of a checksum computation; the protocol may then proceed to obtain values of various fields in the packet to perform its data-link functions. A typical model of this protocol would not perform the checksum computation, since the mechanics of this computation are not directly relevant to the models emulation of the actual protocols behavior. However, aspects of the checksum operation that may matter for the models accuracy are the time required by the calculation, and possibly its result (i.e., determination of the datas validity or corruption). Thus, it is sometimes important to incorporate the delay effects of operations even though they are not explicitly represented for any other modeling purpose. As mentioned earlier, the converse of this principal is also truenamely that certain operations that are explicitly modeled in terms of their mechanics or behavior need not necessarily be modeled in terms of the delay they introduce. In particular, note that operations that are pure artifacts of simulation, such as calculation of statistics for reporting purposes, should generally be modeled as having no delay.
Key Concepts The modeler must decide which actions of a system should be modeled. In general, those delays that affect the desired system statistics in a measurable way should be accounted for. In certain cases, delays may be the only aspect of a system action that is actually modeled; also, some actions may be modeled as having no delay.
Modeling Framework
153-Fram
Modeling Concepts
Techniques for Representing Delays The simplest types of delays in OPNET models are associated with the transfer of information over links between nodes in a network, or between modules within a node. The types of delays encountered in these situations are propagation delay and transmission delay. In almost all models, both types of delays are set via the attributes of the corresponding link or connection object. In the case of link models, actual delay values are computed based on link properties by the underlying link models, known as transceiver pipeline stages. See the Communication Mechanisms chapter in this manual for more information on link models. Propagation Delay Specied as Attributes of Links and Connections
point-to-point link propagation delay is specified in seconds as an attribute of each link object.
propagation delay of a packet stream (in sec.) applies to all packets sent by the source module
This section concentrates on the delays inherent in the operations performed by OPNET process models, since these typically require more careful implementation. These delays can be implemented via a variety of techniques. The key difculty in modeling nite-time operations is that no single event can occupy a simulation time-span greater than zero. Thus more than one event is required to represent such an operation. There are two general forms of event-scheduling used to represent a nite-time operation. The rst form, referred to as external delay modeling, places the burden of delayed action on the Kernel; the second form, referred to as internal delay modeling relies on the component performing the , action to manage the timing as well as the execution. Both techniques use two events to implement a nite-time operation; one event starts the operation, and the second marks its completion.
154-Fram
Modeling Concepts
External delay modeling provides the simplest interface to the model developer. It is applicable whenever all information required to specify an action is available when it begins, and the component performing the action requires no notication that the action has completed. In other words, the effects of completing the action are entirely external to the component performing it. A common example of external delay modeling makes use of the Kernel Procedure op_pk_send_delayed() to send a packet out of a module via a packet stream. This procedure allows the specication of a delay time for which the Simulation Kernel should hold the packet prior to forwarding it. The specied delay can be used, for instance, to represent processing time or transmission time associated with the sending of the packet. From the perspective of the destination module all delays are correctly modeled, since the packet arrives at the correct time. The following diagram shows a packet transmission/reception sequence for external delay modeling of a xed processing delay. Example of External Delay Modeling: Processing Time Incorporated into Packet Forwarding
beginning of operation time line end of operation time line
Modeling Framework
externally modeled processing time
source
destination
The preceding example highlights one of the potential pitfalls of external delay modeling. Note that the processing time is greater than the time separating consecutive transmissions. This modeling is correct if the source processor is capable of simultaneously processing two packets; however, if instead the processor can only manage the processing and transmission of one packet at a time, then the model is inaccurate, because it allows the second packets processing and transmission to begin before the rst ones processing has ended. The intersecting horizontal and diagonal lines in the diagram highlight this error. One possible solution to the simultaneous processing problem presented by the external delay modeling technique involves accounting for the backlogged processing time within the component performing the action. In order to correct the error in the example above, the processor called source would incorporate
155-Fram
Modeling Concepts
additional delay into the forwarding of the second packet to account for the time that this packet would normally have waited while processing of the rst packet completed. Note that this even further increases the amount of time that the third packet must be delayed. The best way to implement this system correctly while still using external delay modeling is to use a variable in the source process to represent the next available processing and transmission time, and to adjust this variable as each transmission occurs. A Proto-C fragment that could be used to implement this technique is shown below, as well as the resulting packet transmission/reception sequence. Example Implementation of External Delay Modeling with Single-Threaded Processing
156-Fram
Modeling Concepts
Operation Start/End Timeline for External Delay Modeling with Single-Threaded Processing
beginning of operation time line end of operation time line
Modeling Framework
source
Gap between operation completion times and operation beginning times widens to account for backlog of previous operations
destination
As a nal note on external delay modeling, the following table enumerates the Kernel Procedures, similar to op_pk_send_delayed(), that support this technique. Kernel Procedures Supporting External Delay Modeling
op_pk_deliver_delayed() op_pk_send_delayed() op_intrpt_schedule_remote() op_intrpt_schedule_call() op_intrpt_schedule_process()
Internal delay modeling is a natural implementation of processing delay since it is performed entirely in the location where the operation itself takes place. The technique consists of recording state information that reects that an operation has begun, and of simultaneously starting a mechanism that will interrupt the process when the operation ends. If the duration of the operation is known when it begins, then this mechanism is typically a self-interrupt scheduled via the Kernel Procedure op_intrpt_schedule_self(). The recorded state information is typically
157-Fram
Modeling Concepts
used to prevent redundant use of the processing resource and/or to complete the operation when the later interrupt is received. In many cases, some sort of busy variable is used to account for the fact that a process is already engaged in completing a task. Internal delay modeling is the only recommended method when the delay of interest is associated with a local operation that does not result in some type of communication with other modules. It is a commonly used technique, since many processing delays are associated with entirely local actions. For example, a processor may receive a packet that contains a routing topology update, and require a certain processing time to recongure its routing table; or a queue may receive a command to ush its contents and prevent further actions until this operation has completed. The following fragment of a Proto-C model illustrates the implementation of internal delay modeling for such a queue. In this case the process does not leave the FLUSH state until the ushing operation is complete; all interrupts that occur in the interim are ignored, so no special state variables are needed to keep track of the fact that the process is busy performing this operation. The condition FLUSH_OPERATION_COMPLETE species both the interrupt type and code must correspond to the self interrupt requested earlier in the FLUSH state in order to allow the process to return to the IDLE state.
158-Fram
Modeling Concepts
Implementation of Internal Delay Modeling for a Simple Process
Modeling Framework
Note that a generally equivalent form of internal delay modeling is possible whereby the operation whose delay is modeled is performed at the end of the waiting period rather than at the beginning, as in the example above. This distinction may be important in cases where the operation results in a change in the systems state and the timing of such a change is relevant to the models behavior (e.g., the operation involves destroying a packet whose contents may still be accessed before completion). In addition to being used for local operations, internal delay modeling is used whenever any of the following conditions are met: The process that is performing the operation does not have knowledge of the delay interval at the time that it begins the operation. This lack of information prevents the process from being able to specify to the Simulation Kernel at what time it should complete the operation,
159-Fram
Modeling Concepts
which is required for external delay modeling. Typically, these types of situations arise when a process depends on an externally generated condition to complete a local operation (for example, a statistic interrupt indicating that an external resource is available). The process supports any type of preemption that would alter the delay time midway through the operation. For instance, consider a queue whose task it is to forward packets in order of priority and that can suspend service of a packet to accord precedence to another one of higher priority; it would be incorrect for the queues algorithm to use the external delay technique and to forward packets at any time before their service intervals completed, since anticipated delays may change due to the subsequent receipt of higher priority packets. The operation may affect state information that is not yet available or depend on state information that may change. For example, a process that receives commands, processes them and issues messages based on the command contents might normally be able use external delay modeling to represent the processing time for these commands; however, if in addition, the process may be asynchronously reconfigured by a management process in such a way that the processing times are modified, then the external delay modeling technique breaks down, since it schedules operations to complete at erroneous times (times that would have been valid if the process had not been reconfigured).
If, in a given modeling problem, both internal and external delay modeling are applicable, then the model developer should consider the following facts to decide on the nature of the implementation: (1) external delay modeling provides a simpler interface to the developer, allowing the delay to be fully specied in one place, whereas internal delay modeling may require several states of a process model to be knowledgeable about the operations completion event; (2) external delay modeling generates one less event per completed operation than internal delay modeling, which may result in simulation performance improvements; (3) external delay modeling may result in a large number of operations being represented in the event list at the same time, which in extreme cases may result in a simulation performance loss; (4) internal delay modeling is always possible and is therefore more extensible than external delay modeling, as a change in the way delay is computed is less likely to cause a signicant change in implementation.
Key Concepts Two general techniques are used to model delays associated with actions: Internal and External delay modeling. External delay modeling schedules the result of an action to take place after the delay elapses. Internal delay modeling schedules an event to mark the end of the delay and during that event, the result of the action is implemented, which may require an additional event.
160-Fram
Modeling Concepts
Fram.4.2.4
Event Cancellation The Simulation Kernel provides a number of interfaces that support processes scheduling future activities for themselves or for other processes. The discrete points of interest in a given activity are represented by interrupts that result from events being scheduled. State information may be associated with the interrupts so that when they actually occur, this information may be retrieved to distinguish them from one another. Interrupts are scheduled to model a number of system features, including processing delay, timer expirations, propagation and transmission delay, resource availability, polling of resources, trafc generation, etc. The earlier sections of this chapter provide more background on these types of applications and how they may be implemented. All event-scheduling interfaces are provided by the Simulation Kernel in the form of Kernel Procedures (KPs). Many of these procedures return a special value called an event handle. An event handle (also referred to as an Evhandle since this is their datatype for purposes of declaration) is actually a data structure whose purpose is to retain access to the event that has been requested. A list of the KPs that provide event handles as return values appears below. Kernel Procedures that Schedule Events and Return Event Handles
op_intrpt_schedule_call() op_intrpt_schedule_mcast_global() op_intrpt_schedule_process() op_intrpt_schedule_remote() op_intrpt_schedule_self() op_pk_deliver() op_pk_deliver_delayed() op_pk_send() op_pk_send_delayed()
Modeling Framework
The Simulation Kernel provides an entire package of KPs, called Ev, that operate on event handles. Many of these KPs are concerned with determining attributes of an event or using an event to nd other events in the event list. However, the primary application of event handles is the cancellation of scheduled events, using the KP op_ev_cancel(). Events that are scheduled may be canceled at any time prior to their execution. Cancellation is even possible during previous events that occur at the same simulation time that the event of interest is scheduled for. Events are canceled for various reasons depending on the application. The general cause of an event
161-Fram
Modeling Concepts
cancellation is that an anticipated action is no longer needed or would be inefcient. The most common use of op_ev_cancel() is to revoke the events that mark the expiration of timers; usually these events are scheduled via the KP op_intrpt_schedule_self().The following Proto-C model illustrates the application of this technique to a typical situation where the timer is used to trigger the retransmission of a packet in absence of an acknowledgment from a peer process. Cancellation of an Event Representing a Retransmission Timer
RCV
The event handle used to cancel the retransmission event is the return value obtained when the event was originally scheduled.
Note that when an event of type stream is canceled, the associated packet is automatically destroyed by the Simulation Kernel.
162-Fram
Modeling Concepts
Key Concepts When an event is scheduled, an event handle can be obtained. If the event handle is preserved, it may later be used to cancel the event using the KP op_ev_cancel(). Certain Ev package KPs also provide other ways of obtaining event handles. Events may be canceled at any time prior to their execution.
Modeling Framework
Fram.4.2.5
Interrupt Methods OPNETs Simulation Kernel provides several options with regard to the timing of interrupt deliveries to processes. These options are controlled either via the KPs used to schedule the events of interest, or via the attributes of objects used to facilitate the interrupt. The two broad classes of events are called scheduled and forced. Scheduled events are the most commonly used form, and are the basis of most of the examples that appear in this chapter. As their name implies, scheduled events rely on an event scheduling mechanism whereby they are inserted into an event list from which they are extracted in order of their designated simulation time. As explained earlier, an event in progress may schedule events for the same exact simulation time (i.e., the current time). However, these events may not be considered for execution until the current event has completed; instead they are simply inserted into the event list, and when the current event has completed all of its actions, the highest priority event scheduled for the same time is serviced. Forced events provide an alternative to the deferral of execution that is inherent in event-scheduling, by interrupting the receiving module immediately. This behavior is useful when the interrupt source must obtain some type of result or service from the interrupt destination before continuing its execution. A common example of this type of interaction is used to support extraction of packets from what are referred to as passive queue models. A passive queue waits to be accessed by an externally-generated interrupt before forwarding packets; it accepts packets that are sent to it by its upstream neighbors and enqueues them, but never autonomously forward packets to its downstream neighbors. The externallygenerated interrupt is usually an access interrupt resulting from a call by a downstream process to the KP op_strm_access(). This KP generates a forced interrupt for a process in the queue, which forwards a packet according to its own internal rules. The downstream process, which called op_strm_access() to obtain a packet, is blocked from executing until the queues process has released execution control (in Proto-C models this is done when a process enters an unforced state and completes the enter executive portion of that state). However, once it does resume execution, the downstream process can expect that the queue has responded to its request, and perhaps forwarded one or more packets. Depending on the system, it may check its inputs for the presence of a packet rather than simply assume that one has been provided. The following diagram illustrates the passive queue
163-Fram
Modeling Concepts
conguration and the execution sequence resulting from the forced nature of the access interrupt. Accessing Packets from a Queue using a Forced Access Interrupt
access interrupts travel this way
packets travel this way step 1: Downstream process issues access interrupt and instantly blocks.
Passive Queue Process Actions
Downstream Process Actions
step 2: Passive queue process receives forced access interrupt and checks to see if it has a packet available; if so, it forwards it but in such a manner as to arrive immediately, and to not cause an interrupt at the Downstream process
step 3: Downstream process resumes execution and is able to check if a packet has been forwarded by the passive queue.
164-Fram
Modeling Concepts
As shown in the preceding diagram, issuing a forced interrupt causes the process that issues it to be temporarily suspended so that the Simulation Kernel can begin executing the process receiving the interrupt. Once the work of the forced process is completed, the suspended process can resume at the statement following the one that originated the action. In other words, from the point of view of the process that generates the forced interrupt, the entire event and all the external actions that it causes are subsumed within a single KP call (in this case op_strm_access()). Modeling Framework
Key Concepts Two types of events may be submitted for execution. Scheduled events can execute at any future time, including the current time. The Simulation Kernel decides when to execute them based on time and priority. Forced events occur immediately, even if other events are pending for the current time.
The diagram also serves to illustrate another event mechanism implemented by the KP op_pk_send_quiet() and used by the process that responds to the forced interrupt. Because the passive queue process is invoked while the downstream process is suspended, and the downstream process will expect a packet to be present as soon as the call to op_strm_access() has returned, the packet must be forwarded in an immediate way. In other words, it would not be useful to use an event-scheduled mechanism (such as op_pk_send()) to forward the packet because the packets delivery would be deferred until sometime after both events had completed, and thus would not appear in the downstream processs input stream. In addition, the Simulation Kernel does not support the application of forced interrupts to processes that are already suspended as a result of issuing forced interrupts; this type of interaction may cause problems in terms of continual execution feedback loops as well as multi-threaded execution of a single process. Therefore, the packet must be forwarded without causing an interrupt for the suspended downstream process. The combined characteristics of immediate execution and lack of interrupt are provided by the class of events referred to as quiet. Currently the Simulation Kernel provides only two KPs that generate quiet events: op_pk_send_quiet() and op_pk_deliver_quiet(). In most cases, the interrupt method is selected by using a particular KP; however, packet streams and statistic wires, which connect modules in the node domain, support the designation of an interrupt method as one of their attributes. For statistic events, the interrupt method is always specied by the intrpt method attribute of the statistic wire of interest. For stream events, the selection of an interrupt method by a particular KP overrides any attribute assigned to the packet stream of interest; however, the packet streams intrpt method attribute may be used to control the interrupt method when the source module is not a queue or processor (i.e., the source module is a generator or a receiver).
165-Fram
Modeling Concepts
Note that not all event types support each interrupt method. The following table summarizes the methods supported by each event type. Note that any event that is specied for a future time (that is, delayed by more than zero seconds from the present time) is necessarily a scheduled event. The forced and quiet methods may only be used for events intended to execute immediately. Support for Interrupt Methods by Event Type
Event Type self stream statistic regular failure recovery begin simulation end simulation access remote procedure call multicast process Scheduled Forced Quiet
Key Concepts A third type of event, called Quiet, is similar to the forced event in that it is executed immediately. However, when it is executed, it does not generate an interrupt for the destination object. The forced event merely delivers data to the destination object. The data is processed later when the object receives a scheduled or forced event.
Fram.4.2.6
Interrupt Steering Processor and queue modules are the node domain elements that allow the modeler to implement customized behavior. Each processor or queue can execute multiple processes that respond to interrupts according to their corresponding process models. Initially, each module executes only one process, known as the root process, whose type is specied by the process model attribute of the module. However, because processes may create (and destroy) other processes that
166-Fram
Modeling Concepts
execute within the same module, the number of actual processes in a module may vary with time. Once interrupted, a process may choose to invoke any other process to perform part or all of the actions required by the interrupt. Therefore, one possible strategy is to have all interrupts arrive at a single process that acts as a dispatcher; based on the attributes of the interrupt, the manager process may invoke the appropriate process. However, in general it is more convenient, more efcient, and simpler to directly invoke the process that will perform the primary actions associated with an interrupt. By default, all interrupts arriving at a queue or processor module are directed toward the root process, with the exception of self interrupts and process interrupts which are always intended for particular processes; self interrupts always return to the process that scheduled them, and process interrupts incorporate a destination process in their specication. However, the Simulation Kernel provides two mechanisms to steer the interrupts towards processes other than the root process. These two mechanisms must be dynamically activated by a modules processes since the only interface they provide relies on Kernel Procedures; in other words, when the simulation begins, the default conditions always prevail, meaning that the root process is the implicit recipient of all interrupts. The mechanisms that are provided are called interrupt type registration and interrupt port registration. The term registration refers to the fact that the processes themselves inform the Simulation Kernel how their modules interrupts should be steered. Both interrupt-steering mechanisms select a process among those in the module based on certain attributes of the interrupt. When the properties overlap, interrupt-port registration is given higher priority. Interrupt type registration considers only the type of interrupt in order to select a process. A process may register itself or another process as the recipient for interrupts of a particular type arriving at the module of interest. The Kernel Procedure used to perform this registration is op_intrpt_type_register(), which is fully documented in the Interrupt Package chapter of the Simulation Kernel manual. The type-registration mechanism can be viewed as a bank of switches into which interrupts enter when they rst arrive at a module; the switches analyze the type of the interrupt and select a process within the module to receive the rst invocation. Initially, all switches point to the root process of the module, but the switches may be recongured by appropriate calls to op_intrpt_type_register(). This view of the interrupt type registration mechanism is depicted in the following diagram.
Modeling Framework
167-Fram
Modeling Concepts
Interrupt Type Registration Mechanism

self interrupt process interrupt self and process interrupts cannot be steered
Interrupt Type
Stream Statistic Regular Failure Recovery Begin-simulation End-simulation
Registered Process
root process
interrupts rst enter the switch table at an appropriate row based on their type
Access Remote Procedure Call Multicast
The Kernel directly invokes the process indicated in the table.
Interrupt port registration can affect only stream and statistic interrupts. For both of these types, steering is based not only on the type but on the arrival port. The port of an interrupt is simply the input stream on which a packet is arriving in the case of a stream interrupt, and the input statistic attached to the active statistic wire in the case of a statistic interrupt. In both cases, the port is a positive integer index. Interrupt port registration is performed by calling the Kernel Procedure op_intrpt_port_register(). Refer to the Interrupt Package chapter of the Simulation Kernel manual for more information on the use of this procedure. The application of interrupt port registration is to separate processing of different physical arrivals based on some prior knowledge of their signicance. For instance, if its known that packets from a higher level application arrive on input stream number 0 and packets from a physical channel arrive on input stream number 1, a separate process can be created to handle each, rather than creating one process that is capable of handling both source of interrupts on an asynchronous basis. This technique can substantially simplify process model design.
Key Concepts Because multiple processes can exist within a single module, the Simulation Kernel must decide to which process each event for that module should be delivered. By default the root process receives all events. However, specific processes can request to receive particular events directly based on the event type and in some cases, the event port (i.e., the input stream or statistic).
168-Fram
Modeling Concepts
Since port registration applies to stream and statistic interrupts and type registration can apply to these interrupts as well, the Simulation Kernel must accord priority to one mechanism over the other. The port registration mechanism is more specic since different interrupts of the same type may be affected differently; therefore by allowing port registration to override type registration the Kernel can support combinations of the two mechanisms. In other words, stream and statistic interrupts in general may be steered toward a particular process due to the type-registration mechanism, while particular interrupts of these types may be steered differently. The diagram below illustrates the Kernels selection mechanism when both type and port registration are employed. Steering Based on Port Registration is Given Precedence
Modeling Framework
Yes incoming interrupt

Port registration exists for this interrupt?
No
Type registration mechanism
The effects of interrupt type registration are easily undone by re-registering the root process of a module, since initially the root process is registered for all interrupt types. However, a special KP, op_intrpt_port_deregister() is required to reestablish prior conditions after op_intrpt_type_register() has been used, since simply installing the root process for a particular interrupt type and port may override a simultaneous type registration. See the descriptions of these KPs in the Interrupt Package chapter of the Simulation Kernel manual for more information on reversing the effects of the interrupt steering mechanisms. Interrupt steering is a powerful technique for implementing complex processes that deal with a large number of interrupts of different types and that arrive on different ports. The effective use of the two mechanisms described in this chapter can allow the modeler to decompose a processs functionality and implement instead as a group of smaller processes, each of which is more easily represented. Refer to the Process Domain chapter of this manual for more information on the application of interrupt steering. Fram.4.2.7 Event Prioritization for Simultaneous Event Execution As mentioned earlier in this chapter, the Simulation Kernels event management policies support the execution of multiple events at the same simulation time. Simultaneous event scheduling may occur as a result of several phenomena:
169-Fram
Modeling Concepts
1) A model may contain synchronously operating components. Different components in the same node or even in different nodes may perform activities in a concurrent manner due to regular timing being imposed throughout the system. This is commonly the case in digital hardware systems where many components are driven by the same clock. Many communication systems operate in a similar fashion, using pre-designated slot times to transmit and receive messages. 2) Unrelated events may coincide on an irregular basis. Events occurring in different nodes, or even at the same module may be scheduled at the same time, even if these events are issued by different sources that are independent of one another. This is commonly the case when only a small number of timing increments are used in a simulation (i.e., fixed transmission times, propagation delays, interarrival times, timer intervals, etc.), since it is likely that different combinations of these increments will add up to yield the same simulation time for a new event. 3) Actions taken during an event may generate new events at the same simulation time. This occurs frequently due to idealization of communication or invocation mechanisms which are modeled as requiring no time to complete. For example, a packet sent over a packet stream with delay equal to zero will result in a new event at the receiving module at the exact same time as the event during which the packet was sent. Note that due to simultaneous events of this type, the number of events at a given time cannot be known until the last event at that time has completed execution (i.e., new events at the same time can be introduced). OPNET simulations are designed to execute on a serial computer, and therefore can only implement one event at a time. Therefore the concurrency of simultaneous events must be emulated by maintaining the simulation time at a constant value until all of the events at a given time have executed. In certain cases, the behavior of a model may be signicantly affected by the order in which the simultaneous events are executed. For example, consider once again a process that sends packets and expects acknowledgments in return; a timer is set using a self interrupt to indicate that a retransmission is necessary after a certain period. Now consider the case where the acknowledgment and the timer expire at the same simulation time. If the self interrupt representing the timers expiration is received by the process rst, a retransmission may be issued; on the other hand, if the stream interrupt associated with the acknowledgment packet is received rst, the acknowledgment will be judged to have arrived within the required time limit, and the retransmission will not be issued. While this type of behavioral ambiguity may be tolerable for certain simulations, for other models only one of the possible behaviors may be correct. In addition, the unpredictability of the models operation can hinder simulation tracing efforts during model validation or debugging. In order to provide for deterministic control of the order in which events are executed, the Simulation Kernel provides two ordering mechanisms called object prioritization and interrupt prioritization.
170-Fram
Modeling Concepts
Object prioritization is useful to provide a deterministic ordering for events that occur at the same time, but at different modules. The Simulation Kernel determines precedence based on a priority rating assigned to each module. The priority rating of a module is a function of its own priority attribute, as well as that of the node and immediate subnetwork objects that encompass it (the priorities of higher-level subnetworks, beyond the one that immediately encompasses a module, are not considered). Priority is evaluated on a hierarchical basis with greater importance attributed to the higher level object attributes. Thus, a module may have a higher priority attribute than another, and yet have a lower aggregate priority rating if the second module is encompassed within a subnet with a higher priority attribute than the rst modules subnet. Only one exception is made to this hierarchical priority scheme: a boolean attribute called super priority is provided on queue and processor modules only, and a module with an enabled value for this attribute always has an overall priority rating than one whose value is disabled. The general rule for comparing event priority is summarized in the following table. The notation is as follows: Subnet (X) is the most immediate subnet of X (i.e., the immediate parent of Xs node); Node (X) is the node in which A is included; X.priority is the value of the priority attribute of X. Criteria for Module A having Higher Priority Rating than Module B
A.super priority = enabled and B.super priority = disabled Subnet (A).priority > Subnet (B).priority Subnet (A).priority = Subnet (B).priority and Node (A).priority > Node (B).priority Subnet (A).priority = Subnet (B).priority and Node (A).priority = Node (B).priority and A.priority > B.priority
Modeling Framework
If any two events are simultaneously present in the event list and scheduled for exactly the same simulation time, then if the events are scheduled for two different modules, the event scheduled for the module with higher aggregate priority rating will be executed rst. Note that it is an important condition that both events be present together in the event list since it is usually impossible to anticipate the arrival of simultaneous events of type (3) above. For instance, it is possible for a low priority module to execute, then schedule an event for a higher priority module with no delay. The execution sequence interrupts the lower priority module rst, and this may seem paradoxical to a user tracing through the events of the simulation; however this is normal behavior since the higher priority modules event was not known to the Simulation Kernel until after the lower priority event had already begun execution. Interrupt priorities are used to establish an order for events that occur at the same time as well as at the same process (not the same module). Classication of interrupts is based on an integer priority value assigned to a combination of
171-Fram
Modeling Concepts
interrupt type and interrupt code. Each process can adjust its own priorities (but not those of other processes) by calling the KPs op_intrpt_priority_set() and op_intrpt_priority_set_next(). Each of these KPs allows the specication of an interrupt type and an interrupt code as well as an integer priority value. Higher numerical priority values correspond to higher precedence of execution for the specied interrupt type and code; negative and positive priority values are allowed. The default priority value for all interrupt type and code combinations is zero. For both object and interrupt priority mechanisms, if two events have the same simulation time and the same priority rating, precedence is given to the event that was inserted into the event list rst. This ordering of event execution is termed natural order. Natural ordering is also the default ordering policy which is applied when neither priority mechanism is used.
Key Concepts When two events are scheduled for identical simulation times, the Simulation Kernel must decide which one to execute first. Several priority mechanisms can be used to establish precedence when needed. Object priority separates events occurring at different objects. Interrupt priority separates events occurring at the same object. When priorities are equal or unused, the natural order of scheduling is followed.
172-Fram

02 20framework

Загружено:

Сведения о документе

Исходное описание:

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

02 20framework

Загружено:

Авторское право:

Доступные форматы

Chapter 2 Modeling Framework

Object-Based Modeling & Simulation

Event Scheduled Simulation

Mapping Real Systems to OPNET Models

Mapping Real Systems to OPNET Models

Mapping Real Systems to OPNET Models

Mapping Real Systems to OPNET Models

Mapping Real Systems to OPNET Models

Mapping Real Systems to OPNET Models

Mapping Real Systems to OPNET Models

Mapping Real Systems to OPNET Models

Mapping Real Systems to OPNET Models

Mapping Real Systems to OPNET Models

Mapping Real Systems to OPNET Models

Mapping Real Systems to OPNET Models

Modeling System Structure

Modeling System Structure

Modeling System Structure

Modeling System Structure

Modeling System Structure

Modeling System Structure

Modeling System Structure

Supported Object Attribute Types

Modeling System Structure

Modeling System Structure

Modeling System Structure

Modeling System Structure

Attribute Properties (Cont.)

Modeling System Structure

Restrictions on Attribute Symbols

Modeling System Structure

3) Left-click the Details button.

Modeling System Structure

Sharing of Public Attribute Descriptions

Making Attribute Properties Public

All properties are taken from attribute description called ip_address_index

Modeling System Structure

Modeling System Structure

Presentation of Compound Attributes Values

A compound attribute value appears as (...) to indicate underlying complex data

Modeling System Structure

Compound Attribute Structure

Each compound attribute (CA) contains one CA-object.

Modeling System Structure

Modeling System Structure

Attribute Data Types

String Toggle Typed File

Modeling System Structure

The new attribute appears as a primary attribute of the object.

Modeling System Structure

Modeling System Structure

Modeling System Structure

Modeling System Structure

Modeling System Structure

Modeling System Structure

Inheritance of Model Attributes by Objects

Objects O1, O2, and O3 inherit attributes of model M

Modeling System Structure

Built-In Attributes Model Attributes Extended Attributes

Modeling System Structure

Instead of having a value, the pattern attribute of this object is promoted.

Modeling System Structure