02_20Framework

8/2/2019 02_20Framework

1/110

63-Fram

Modeling Framework

Chapter 2

8/2/2019 02_20Framework

2/110

64-Fram

Modeling Concepts

8/2/2019 02_20Framework

3/110

65-Fram

Modeling Concepts

Introduction

Fram.1 Introduction

The Modeling Overview

chapter

provides a high-level introduction to the entireOPNET modeling environment. It is a good starting point for understanding howthe different components of OPNET work together. This chapter begins to presentmore in-depth information on the tool. In particular, it addresses issues that arerelated to the modeling framework as a whole, rather than any particular

hierarchical level. This chapter should solidify your understanding of OPNETsarchitecture and the relationships between an OPNET model and the real-worldsystem that it represents. The chapter is divided into three main sections, asfollows:

This chapter is designed to allow reading at two levels: detailed

and

conceptual

. For more detailed information, merely read the paragraph text as youwould a traditional text. To cover the information more quickly, remain at aconceptual level by reviewing only tables, diagrams, bullet list headings, andspecial key concepts

boxes, as shown below. If you require more detail on aparticular topic, read only the paragraphs in the corresponding section.

Framework Chapter: Content Summary

Section Topic

Mapping Real Systemsto OPNET Models

Explains the basis for using distinct modelingdomains and briey restates the purpose of eachdomain. Discusses how various aspects of real-world systems map into the modeling domainsand into mode specic OPNET-supportedmodeling mechanisms.

Object-Based Modeling& Simulation

Provides a detailed explanation of the object andmodel hierarchies. Discusses the relationshipsbetween models, objects, and attributes, and theprecise behavior of each of these.

Event ScheduledSimulation

Lays the groundwork for discussing simulationdynamics by introducing low-level mechanicssupporting the interaction among objects.Provides a detailed explanation of the differenttypes of events, what they are used for, and howthey are typically processed.

Key Concepts

To quickly cover the material in this chapter, simply skip over para-graph text, reviewing only tables, diagrams, bullet list headings, andkey concepts boxes such as this one.

8/2/2019 02_20Framework

4/110

66-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 threeenvironments called modeling domains

. This differs from the approach taken bymost modeling frameworks, which use a single paradigm to specify all aspects of asystem. The contrast between the OPNET approach and the single-paradigmapproach 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 widerange of technologies ranging from low-level communications hardware to high-level decision-making software. A successful system modeling effort mustrepresent each of these subsystems and their interactions at a level of detail that issufcient to obtain valid predictions of performance and behavior. Because thenature of these subsystems varies signicantly from level to level (for example, acommunications protocols and real-time operating systems are fundamentallydifferent types of entities than communications links or packet buffers), single-paradigm frameworks must be stretched to develop adequate models. OPNETsapproach to modeling is based on three paradigms that specically target thedistinct levels identied in a communications network. The following is a brief summary of each of the modeling domains supporting these paradigms. Pleaserefer to the chapters in this manual covering each specic modeling domain formore information.

OPNET Modeling Domains

Domain Purpose

Network concerned with the specication of a system in terms of high-leveldevices called nodes

, and communication links between them.

Node concerned with the specication of node capability in terms ofapplications, processing, queueing, and communications interfaces.

Process concerned with the specication of behavior for the processes thatoperate within the nodes of the system. Fully general decisionmaking processes and algorithms may be specied.

Key Concepts

OPNET uses distinct modeling paradigms to represent the fundamen-tally different components of a network or distributed system. Eachparadigm has an associated modeling domain and editor. This allowsthe structure of models to closely resemble that of real-world systemsand to be more intuitive.

8/2/2019 02_20Framework

5/110

67-Fram

Modeling Concepts


Fram.2.2 Identifying Modeling Support for Actual System Features

With the power of having several modeling domains comes the requirement todecide which domain will be used to implement each characteristic of a modeledsystem. This breakdown is usually the rst step in designing a system model.While there are no strict rules, this section provides useful guidelines forestablishing a correspondence between an actual system and the OPNET modeling

domains.

The following table characterizes the OPNET modeling domains by statingwhich aspects of a system each domain may play a role in representing. In certaincases, more than one domain may be marked as appropriate for a particular systemaspect; this indicates either that a combination of domains is required in themodeling or that, depending on other aspects of the system, one of the markeddomains will provide the most appropriate support.

Fram.2.2.1 Hierarchical Topology

The topology of a system consists of both an inventory of its devices and thecommunications links between them. The network domain refers to these devices

Domain Applicability to Selected System Aspects

System Aspect Network Node ProcessHierarchical 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

8/2/2019 02_20Framework

6/110

68-Fram


Modeling Concepts

as nodes

, and has several types of links that can be dened to connect themtogether for the purpose of sending information between them. Groups of nodesand links can be used to form subnetworks, and subnetworks can in turn containlower-level subnetworks to form unlimited hierarchies. Some system topologiescan be entirely represented in the node domain by interconnecting the node levelbuilding blocks, called modules

. In such cases, the network domain model mayconsist of just one node. This occurs particularly for small systems with no realphysical layout requirements, or where the communication between devices ismostly of a logical nature (i.e., interfaces based on commands, requests,indications, or interrupts). However, in most cases the network domain is used torepresent high-level system topology because of its direct support for unlimited-depth hierarchies, sophisticated communication links, and measured physicallayout.

Fram.2.2.2 Communication Pathways

Most systems involving multiple subsystems or devices implement one ormore forms of communication between them. Some forms of communication mayrequire no physical connections to transfer information, such as interrupts issuedby an operating system to a process, for example. However, for many systems,

particularly systems with geographic separation, some physical resources are usedto connect the subsystems. OPNETs network domain provides several types of link objects that are generally used to model connections between devices that areseparated by some physical distance. These links transfer data in the form of user-dened messages called packets

. Network domain links model properties found inthe communication media of real systems, including interference, errors, anddelay.

Network domain links are rarely used to model device-connectivity of a purelylogical nature. These types of communication are generally supported by simplerconnections within the node domain, called packet streams

and statistic wires

.Packet streams are simple pipes that carry packets between modules in a node. Theinterface they provide typically corresponds to a need to transfer blocks of information or messages between local devices, cooperating software processes, orneighboring protocol layers. Statistic wires convey numeric values betweendevices or processes that are located in the same node. They are used for twoprimary purposes: to allow processes to monitor changes in state and performanceof the devices that make up a node; and to create a simple signaling mechanismbetween processes.

Key Concepts

Hierarchical network structure is accommodated by OPNETs subnet-work construct. Subnets can be placed in different geographical loca-tions and connected via links. In each subnet, a model may containarbitrary groupings of nodes and links, as well as additional nestedsubnetworks.

8/2/2019 02_20Framework

7/110

69-Fram

Modeling Concepts


Fram.2.2.3 Geographical Layout

For certain network models, the actual physical disposition of nodes may affectthe results produced by a simulation. In particular, systems that include radio orbus type links can make use of the distances between nodes to compute link effectsincluding propagation delay, interference, and received power levels. OPNETsnetwork domain provides for precise descriptions of the physical aspects of anetwork within a congurable coordinate system. The units of the coordinatesystem can be degrees, arc seconds, kilometers, miles, meters, or feet to

accommodate both large and small-scale models. Cartographic backgrounds maybe loaded to provide models with a geographical context.

Fram.2.2.4 Device Mobility

Systems that include mobile communicating devices may require models thatexplicitly represent the devices motion histories in order to account for time-varying distances that will affect communication characteristics, including qualityof 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 anindependent trajectory that species its positions as a function of time.Trajectories, which are specied as a series of discrete positions and associatedtimes, are the most common mechanism used to model mobility; however, it is alsopossible for user-developed process models to dynamically update the positionattributes of node objects, thus allowing adaptive node mobility which can be afunction of the systems state and of its history.

Key Concepts

Links are used to transfer packets between physically separatednodes or subnetworks in the Network Domain. Within a node, modulesuse packet streams to transfer packet and numerical information orsignaling can be conveyed using statistic wires.

Key Concepts

Network models can be deployed within a physical context to matchthe actual system environment. Physical relationships between nodescan be used to accurately calculate delays for links, and propagationand interference effects for radio transmissions.

8/2/2019 02_20Framework

8/110

70-Fram


Modeling Concepts

Fram.2.2.5 Device Failure

Certain modeling efforts include a requirement to model the behavior of asystem when some of its components experience failures. Depending upon thesophistication of the system it may have built-in procedures for adapting to suchconditions; these capabilities may also need to be incorporated into the systemmodel in order to accurately simulate the systems behavior. OPNET offers severalcapabilities 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 thisattribute as the simulation progresses, user-dened processes can affect theoperability of selected nodes and links. Disabling a node or a link essentiallyprevents it from carrying out any operations; in the case of a node, this means thatsimulation 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 enabledany number of times during a single simulation run. An important aspect of using

condition

attributes to generate failures is that processes throughout the entirenetwork model may receive asynchronous notication of the changes in theattributes state. This notication mechanism, which causes a special interrupt tobe delivered to the process in question, is controlled by setting the failureintrpts

and the recovery

intrpts

attributes of processors and queues.

Additional capability to model failures within the modeled system can bederived from the general ability to program behavior into the models of systemcomponents. For example, OPNET provides no built-in support for implementingthe failure of a queue module; however each queue is a programmable object thatcan respond to commands or changes in its attributes. By sending the appropriatecommand to a queue module, its internal logic can respond by discarding thepackets that it contains and rejecting further attempts to enqueue packets. Similartypes of behaviors can be programmed for processors, links, or for nodes as awhole. The principle is that, if the built-in support for modeling failures andrecoveries of system components is insufcient, these may be treated as generalevents whose specic repercussions are implemented by user-dened logic.

Key Concepts

In OPNETs Radio version, mobile nodes can change position overtime in the Network Domain. Two mechanisms support node mobility:1) a node can be assigned a trajectory that specifies positions as afunction of time, and 2) processes can compute and update node po-sitions on an adaptive basis, to respond to changing conditions.

8/2/2019 02_20Framework

9/110

71-Fram

Modeling Concepts


Fram.2.2.6 Communication Delays

Delays affecting information transfer can occur at many levels in an actualdistributed system or communication network. OPNET provides a number of possibilities for modeling delay.

Signal propagation delays over links (due to distance) are an important causeof communication delays; network domain point-to-point and bus link objectsinclude a delay

attribute that is used by the default underlying link models. In thecase of point-to-point links, the delay is usually simply a constant, while in thecase of bus links, the delay is per unit-distance. The default model for radiocommunication computes delay based on distance separating the transmitter fromthe receiver. For all link types, the underlying link model used to computepropagation delay may be customized. In the node domain, each packet streamsupports 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 issent over a link, in addition to propagation delay. This delay is the amount of timeseparating the instant at which the rst bit begins transmission from the instant atwhich the last bit completes transmission. For all types of links, there is anunderlying model, or pipeline stage that computes this value, and can becustomized. The default model makes use of the data

rate

attribute of thetransmitting 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 becomeavailable, typically a communications link or a processor. This type of delay can insome cases account for the majority of a packets end-to-end delay from its point-of-origin to its nal destination. Most queuing delay in OPNET occurs within thenode domain, in either queue or transmitter modules. Transmitter modules (for allthree link types) incorporate a rst-in-rst-out queue for packets to wait whilepackets that arrived before them complete transmission; queue modules use a

process model (which may be user-dened) to determine when packets should bedequeued and forwarded. Thus, the process domain is also involved in determiningqueueing delays.

Key Concepts

Component failures for nodes and links can be modeled by modifyingtheir condition attribute when appropriate. Optionally, changes in thisattribute can automatically generate notification interrupts for process-es in any part of the network. Other component failures, or differentbehavior can be programmed as necessary in process model logic.

8/2/2019 02_20Framework

10/110

72-Fram


Modeling Concepts

Fram.2.2.7 Communication Errors

Many communication systems are subject to errors that affect the transmissionof data. Various causes are associated with these errors, ranging from faultyelectronics 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 collisionscaused by simultaneous transmissions. The default bus models cause collidedpackets to be lost. The radio link models dynamically determine errors based on

parameters of the transmission that affect link quality, including interference andsignal strength. Thus, most modeling of communication error phenomena isperformed in the network domain. However, it is possible to use process models tomodel errors that are internal to nodes. For example, a process that normallyforwards packets to another module may be programmed to destroy the packetsinstead with a certain probability, thus modeling a stochastic error mechanism. If such a process is deployed as the immediate neighbor of a receiver module withina node, then it may replace the links bit-oriented error characterization with apacket-oriented one (the links bit error rate can be set to zero).

Fram.2.2.8 Resource Management & Contention

Resources can generally be thought of as entities that are required in order tocomplete 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 asoftware program with a limited number of simultaneous users, or acommunications channel. Generally, resources enter into system modelingproblems because they are contended for by a number of clients. A client

is ananother entity or process that seeks to use the resource to progress in itscompletion of a task. Each system must have established policies to decide inwhich order and to what extent the various clients will be granted access to theresource. Because the number of clients and their need for resource access may be

Key Concepts

There are many sources of delays incurred by packets as they travelthrough 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 linkdata rate. Queuing delays are determined by process models.

Key Concepts

Communication errors can exist on all types of links and result in dam-aged or lost packets. Each link model has its own error mechanisms,including stochastic errors, collisions, and various types of interfer-ence. These are implemented, and can be customized, by the under-lying link models. Processes can also induce packet loss or change.

8/2/2019 02_20Framework

11/110

73-Fram

Modeling Concepts


a function of many factors, and the resource allocation policy may also be complexand non-analytic, simulations are often the most effective means of forecasting thebehavior of such systems. Indeed, many simulation packages focus on resource-oriented modeling exclusively.

While OPNET does not have a paradigm dedicated to resource modeling, thepower and generality of the node and process domains make it an excellent

environment for modeling complex resource-based systems. The most commonlyadopted strategy for modeling resources in OPNET is to create a queue module inthe node domain to represent each resource. Because queues are fullyprogrammable, each resource can be managed by its own allocation algorithm. Anumber of example policies are provided including a simple FIFO, processorsharing and preemptive-priority. The exibility of the process domains Proto-C

language allows any new resource management policy to be dened. Models of theclients are usually implemented as processes that send access requests to thevarious system resources. They may choose to block while waiting for resources tobecome available, or to continue, depending upon their task denition. Resourceaccess requests may be formulated as OPNET packets with specic parameters of

the request encoded as packet elds; these parameters may factor in to the resourcepolicys decisions on how to process requests.

Fram.2.2.9 Packet/Transaction Generation

Most simulated systems involve at least one type of dynamic entity thatcirculates among the components of the system. Depending on the primaryorientation of the development environment, these entities will have differentnames such as transaction

, data-structure

, or data-unit

. OPNET supports severalsuch dynamic objects, the most common of which is called a packet

, due to thetraditional application of OPNET to communication network modeling. Packetsare general data structures that are organized into elds of information accordingto 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 createdand destroyed as a simulation progresses. Packets can be created in an OPNETsimulation model through only a limited number of mechanisms: (1) generatormodules, dened as part of node models, may issue new packets according tostochastically characterized patterns; (2) processes operating within processors orqueues may create entirely new packets, as required by their process models

Key Concepts

Resources are often modeled as queues in the Node Domain. Theprocess model of the queue implements the resources policy andaccepts and processes requests which can be submitted in the formof packets. Fields of the packets can indicate parameters of the re-quest. Arbitrary resource management policies may be defined.

8/2/2019 02_20Framework

12/110

74-Fram


Modeling Concepts

specicationthis allows processes to model sophisticated packet-generatingdevices, in place of the simpler generator modules; (3) processes may create copiesof already existing packets; (4) bus and radio communication links may createcopies of packets in order to deliver them to multiple destinations as part of abroadcast transmission.

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 packetscontain. Because OPNET packets are modeled as individual entities with specicdata contents, the packet processing performed by an actual system can bemodeled in full detail. Denition of packet processing in an OPNET model occurswithin the process domain, where Proto-C

process models make use of SimulationKernel procedures to manipulate the packets that they create or receive fromoutside. Common operations that process models perform on packets include:creating new packets, receiving new packets, copying packets, extracting eldvalues, setting eld values, sending packets to other modules, enqueuing packets,dequeuing packets, and destroying packets. In addition, many packet-processingoperations 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 routingtable, and an acknowledgment packet may cause a timer to be canceled, dependingon its contents.

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 stateof one system component may require another component to take specic actions.This coordination of activities implicitly involves some communication between

Key Concepts

The primary information-carrying object in an OPNET simulation is apacket . Each packet has a format which defines which fields it con-tains. Packets can be generated spontaneously by generator mod-ules, or by processes. They are then forwarded to other objects.Packets may also be copied by processes or for broadcasting.

Key Concepts

Packet fields carry actual values that can be assigned and extractedby processes. When a packet is received by a process, the informa-tion that it contains can be analyzed and used as the basis for deci-sions. Actions can include modifying, destroying, or relaying thepacket, as well as creating other packets, or changing system state.

8/2/2019 02_20Framework

13/110

75-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 nodevia a radio link, for example. However, OPNET provides two simplercommunication mechanisms that can often be more appropriate, particularly whenthe coordination between the components is based on the sharing of numericalvalues. For localized communication of numerical data, the node domain providesan object known as a statistic wire, which allows a module to export values thatreect its state or performance as these vary over time. For example, a node maycontain several queues and a processor that acts as a multiplexor for the queuesoutput, having to select which queue to draw from next; as part of the systemdenition, the processor may need to be aware of the queue sizes on a synchronousbasis, as well as receive an asynchronous warning when any of the queue sizesexceed a certain threshold. Statistic wires are an appropriate modeling construct torepresent such a system because all of the coordinating objects are located withinthe same node, and because the communicated information consists only of simplenumerical 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 atthe 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 nodeand therefore does not always provide adequate support for remote sensing. Animportant alternative is provided by a mechanism called the remote interrupt

,which can communicate information between processes without relying on theexistence of any physical connections between them. A process operating in aprocessor or queue module can send a remote interrupt to any other processor orqueue in the entire modeled system, regardless of location. The interrupt may beaccompanied 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 objectsother than processors or queues.

Fram.2.2.12 Interrupt Processing

Each event in an OPNET model is associated with a module within the nodedomain. Most events result in the module being interrupted in order to perform aseries of actions. Two types of modules, processors and queues, allow a general setof actions to be dened by developing a process model using the Proto-C languageof the process domain. The general approach to developing process models is to

Key Concepts

An object may rely on knowledge of another objects state. Packetsmay be appropriate for remote objects connected by links; but formodules within the same node, statistic wires are used to transfer nu-merical values and to provide interrupts for specific changes. Remoteinterrupts allow information to be sent to any process in the system.

8/2/2019 02_20Framework

14/110

76-Fram

Mapping Real Systems to OPNET Models Modeling Concepts

view them as procedures that respond to interrupts. A process model may use thevarious provided Simulation Kernel procedures to obtain information concerningthe nature and source of the interrupt. In most cases, interrupts carry additionalinformation that a process model may access and factor into the actions that itimplements and the state-transitions that it traverses. For example, a streaminterrupt represents the arrival of a packet, and usually causes a process to obtainthe packet and decode its contents; and self interrupts have an associated user-dened code that can be used to distinguish between multiple outstandinginterrupts of the same type.

Fram.2.2.13 Behavioral Logic

The developer of an OPNET model may choose to simulate the behavior of themodeled system at many levels of detail, including all necessary interactionsbetween subsystems. While data communication is often an important part of anOPNET model, the modeling framework provides equal depth in modeling theprocessing that takes place within each subsystem. In fact, it is typically the casethat the communications layers of a model are viewed as support mechanismsfor the higher level applications processes. In this sense, models of applicationbehavior are actually those that drive an overall system model, and therefore

these need to be accurately represented. The Proto-C language provides a rich setof 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 performfuture activities; queueing according to user-dened algorithms to provide accessto communications, processing, and storage resources; object identication andtopological discovery; dynamic model-attribute modication; stochastic valuegeneration; 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

Processes are interrupt-driven. When a process is invoked, it can ac-cess data associated with the interrupt. The logic of the process usesthe data, combined with state information to take appropriate actionsand modify state.

Key Concepts

Applications and in general, any generation or processing of data, arerepresented with process models. Process models use the OPNETKernel Procedures and general C/C++ code to allow specification ofany system behavior.

8/2/2019 02_20Framework

15/110

77-Fram

Modeling Concepts Mapping Real Systems to OPNET Models

Fram.2.2.14 General Information Storage

Both applications and communications protocols in distributed systemstypically require that signicant amounts of state information be maintained. Theword state is often used to represent the position of a Proto-C process model in itsnite state machine graphical representation; however in the larger sense, a processmodels state additionally consists of an arbitrary set of variables of either built-in

datatypes, or of datatypes specied by the modeler. A communication protocolmay dene unique structures for storing information, such as routing tables, timerinformation, lists of packets to retransmit, data fragments held for reassembly, andso on. An application may store different types of information, such as variablesfor custom performance calculations, or lists of requests that are pendingprocessing. Beyond attributes of network and node domain objects, the primarymechanisms dened for storing the state of a system are specied in the processdomain. State variables are declared as part of each process models specication,and the Simulation Kernel maintains these separately for each instance of a processmodel in the system. This is the mechanism most often used to specify stateinformation that is independently maintained by each process. Global variables are

used when multiple processes need to implicitly share information without the useof an active communication mechanism to update each other. These variables mayalso have general data types and can be declared both in process models and inexternal source code les. Both state variables and global variables can providestatically allocated (allocated in advance), or dynamically allocated (allocated asneeded) memory.

Key Concepts

In addition to the attributes of objects, the state of the modeled systemcan be stored in a combination of: 1) the state variables of processes;

and 2) model global variables. Both types of variables can supportstatically or dynamically allocated storage.

8/2/2019 02_20Framework

16/110

78-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 asystem into smaller pieces and expressing the relationships between thosepieces. Procedures provide a way of expressing behavior that is dynamic andadaptive. Behavioral descriptions must account for a wide variety of conditions

involving variable system state and events; furthermore, complex actions must bespecied in response to these conditions. OPNETs modeling approach provides anatural way of integrating these two specications into a unied system model, aswill become clear in the remaining sections of this chapter.

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 realworld, systems actually include many physically distinct entities that we think of simply as objects. Examples of physical objects in a communications network areenumerated 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

Key Concepts

OPNET uses two fundamental methods for describing a system: objects and procedures . Objects represent system structure, and pro-cedures are used to express system behavior.

8/2/2019 02_20Framework

17/110

79-Fram

Modeling Concepts Modeling System Structure

Note that these are all objects that you have probably seen before and that youcan describe physically. More than their physical characteristics, for modelingpurposes, we are interested in describing how they work, and how they interactwith other objects. Here again, there is a structural aspect and a behavioral aspectof system specication. The structural aspect of how the object works internallydeals primarily with further decomposition of the object into more objects. In otherwords, 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 theobject and the pathways that are in place to allow it to communicate with otherobjects. Pathways are often (but not necessarily) other objects (such as links)whose purpose is to allow interconnection.

In a theoretical sense, the use of objects is not limited to representation of asystems physical entities. Abstract or logical entities can also qualify as objects. Afew examples of non-physical objects are enumerated in the following table:

OPNET generally attempts to represent system components in the mostintuitive way possible. Thus, these non-physical objects do not have a visualrepresentation. They are simply software constructs, but they are still consideredobjects because of the way in which they are treated, and the way in which theybehave. Some of the important characteristics that make them objects are: theypresent a well dened interface with controlled access to internal state; they aremostly special cases of a class of entities that are not identical but have a similarform.

Some Abstract or Logical Objects in a Communication

Network Process

Packet

Job, Request, or Task

Timer

Probability Distribution

Key Concepts

Objects provide a natural way of describing the structure of communi-cations networks. In addition to capturing the physical characteristicsof system components, they can be used to represent their internaldecomposition and interconnection.

8/2/2019 02_20Framework

18/110

80-Fram


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 systemstructure. 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 isgenerally the case that non-physical objects correspond mostly to the changingaspects of the system. Thus, while they are objects in the larger sense, they are notrelevant for this sections discussion of representing system structure. In theremainder of this section, the word object will be used to refer to physicalobjects, such as those previously enumerated.

Fram.3.2 Objects and Models

The relationship between an object and a model is fundamental to allspecication work performed in OPNET. When an object is created, a certainnumber of characteristics (sometimes all characteristics) are assumed to belong toit. The characteristics may relate to internal structure of the object, its capabilitiesand purpose, its presentation, and its interfaces.This information must come fromsome 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 onlyone model. Of course, the operation used to create the object (e.g., graphical) canbe 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 isimportant is to realize that though the objects depend on the same model to receivecertain characteristics, they exist independently of each other. In other words,changes made to one of the model instances do not affect the other. Thiscorresponds well to the real world situation that objects represent. Consider thefollowing example. A particular make and model of automobile can be considereda model. The model is essentially the blueprints for the car, together with anyadditional information that may describe it, such as list price, available colors, etc.Then the actual cars that consumers can purchase would be considered objects thatare instances of that model. Each car exists independently of the other. Forexample, if one car breaks down, this implies nothing about the state of other carsof the same type.

Key Concepts

Abstract or logical objects, such as processes and timers, exist in acommunications network. However, they are generally dynamic ob-

jects, and not elements of system structure. In this chapter, we will fo-cus on physical objects that represent system structure.

8/2/2019 02_20Framework

19/110

81-Fram


The collection of objects that depend on a particular model form a class . It isquite simply the class of objects of that type. The model represents the class; it isthe class denition. When the denition of the class changes, all of the objects thatbelong to it are affected. For example, embedding additional specication forinternal structure into the model will result in all objects receiving that internalstructure. Similarly, if the interface specication of the model is modied, then allthe dependent objects must change the way in which they interface with otherobjects. Such a change may potentially result in invalid connections orinteractions, 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 thechanges apply to all objects, including those that are not currently present withinthe OPNET editors. In fact, the changes even apply to objects that have not yetbeen created, since these instances will adhere to the new model denition whenthey are created.

A model includes information that is common to all of its instances. Thisincludes specications for the objects interfaces, behavior, and internal structure.The models interface dictates how objects interact with each other. This caninclude specications related to physical interconnection. For example, a nodemodels interface may include information about what types of links it can use toconnect to other nodes. The models interface may also include the mechanics andthe semantics of interaction with other objects. For complex objects, this mayinclude 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 theobject. This means that the model denes the way in which an object will react toexternal stimulus, and the how and when it will spontaneously take action. A trafcsource, for example, is an object that will spontaneously generate activity. For

Key Concepts

Objects are instances of models. An object is a particular occurrenceof a model. It exists independently from other objects and its charac-teristics conform to the models specifications. As an analogy, a par-ticular car is an instance of the car model which is essentially the carsdesign.

Key Concepts

Models dictate object characteristics. Changing the definition of a

model affects the characteristics of all of the objects that adhere to thatmodel. This is a powerful mechanism for controlling large numbers ofobjects in a centralized manner.

8/2/2019 02_20Framework

20/110

82-Fram


complex objects, behavior may be a function of many variables, includingaccumulated state information, external stimuli, time, and random variables.

Finally, a model also species the internal structure of an object. This has to dowith the decomposition of the object into further components. These componentsmay themselves be objects with their own models. OPNET node models, forexample are specied in terms of objects called modules and connections , as

discussed in later sections of this manual.

While models specify a large part of object characteristics, furthercustomization 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 theinstances is xed, and which can be modied on a per-instance basis. The modelcan be thought of as being parameterized, meaning that it supports congurationof certain variables that the model designer chooses to expose to users of themodel. This topic will be discussed in more detail later. For now, these parameterscan simply be viewed as part of the models interface.

Fram.3.3 Attributes

When representing an object, certain characteristics of the object areconsidered private and remain hidden within the object. Other characteristics areconsidered useful to expose to the user of the object, for various reasons. Thesecharacteristics are represented in the form of data items called attributes .Attributes are useful for two primary purposes: to inform users about selectedcharacteristics of an object; and to allow these characteristics to be modied forspecic applications. The type of information that can be specied with attributesis quite general. It includes general characteristics, object behavior, and internalstructure.

Key Concepts

An objects characteristics inherited from its model include: internalstructure (what it contains), behavior (what it does spontaneously andhow it reacts), and interfaces (how to interact with it).

Key Concepts

All objects that share a model are not necessarily identical. The modelcan allow for certain differences in each of its instances, as deter-mined by the model designer.

8/2/2019 02_20Framework

21/110

83-Fram


Attributes can be associated with classes of objects, as well as with particularobjects. In other words, an attribute can be dened for a model. This topic iscovered in section Fram.3.5 Model Attributes . For the purposes of this section, theterm attribute is used generically to refer to both object attributes and modelattributes.

Each attribute provides storage for information that constitutes part of thespecication of an object or a model. The contents of the attribute are referred to asits 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, theattribute must be identied uniquely. This is accomplished by designating a namefor the attribute. No two attributes on the same object, or on the same model, mayhave the same name.

Attribute Data Types

Attributes can store different types of information in order to supportspecication of a broad range of object and model characteristics. Most attributeshave a simple value, meaning that they consist of just one element. Theseinclude familiar types such as numbers, text strings, and booleans. Even textstrings containing multiple characters, words, and lines, are considered simplevalues because they do not encompass storage for any additional attributes.Support is also provided for a compound attribute which encompasses nestedobjects. These nested objects may have their own attributes, which in turn may besimple or compound. Thus the information stored within an attribute may have aat structure in the case of a simple attribute, or a hierarchical structure in thecase of a compound attribute. The following table enumerates the attribute typesthat may be found within an OPNET model, provides an example of each, andindicates which datatype can be used in programs to hold the attributes values.

Key Concepts

Attributes store data that describes an object or model. They can beused to: provide information; specify general characteristics; selectbehavior; modify internal structure.

Key Concepts

All attributes have a name and a value. The name is unique within thecontext that the attribute belongs to (e.g., object or model). It is usedto refer to the attribute when reading or writing its value.

8/2/2019 02_20Framework

22/110

84-Fram


The following list describes the various attribute types.

Integer positive or negative whole numbers with magnitude less than231 64. These attributes typically represent small numerical valuessuch as counts, identifiers, connection indices, or priorities. Certain in-teger values beyond the allowed range are constants with special mean-ings: OPC_INT_UNDEF represents an undefined value resulting from acomputation that cannot be performed or insufficient information;OPC_INT_INVALID represents an invalid value, typically indicating anerror condition. OPC_INT_INFINITY represents an unbounded integervalue.

Double positive or negative double-precision floating point numberswith a magnitude less than 10 100 . These attributes typically representprecise 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 beused to indicate special values of this type of attribute: OPC_DBL_UNDEFrepresents an undefined value resulting from a computation that cannotbe performed or insufficient information; OPC_DBL_INVALID representsan invalid value, typically indicating an error condition.OPC_DBL_INFINITY represents an unbounded double value.

Supported Object Attribute Types

Attribute Type Example Attribute C Language orOPNET-provided Datatype

Integer priority of a processor int

Double data rate of a channel double

Compound channel of a transmitter Objid

Toggle begsim intrpt of a processor int

Toggle Double intrpt interval of a processor double

String name of a xed node char []

String List interarrival args of a generator char []

Typed File process model of a processor char []

Icon icon name of a mobile node object char []

Enumerated failure intrpts of a processor int / char [] (see below)

Color color of a simplex point-to-point link int

Textlist enter executives of a state List

8/2/2019 02_20Framework

23/110

85-Fram


Compound supports complex data storage consisting of a set of objects. The actual value of a compound attribute is a special object whichprovides access to two items: a count of underlying subordinate ob-

jects; and an array of subordinate objects. The subordinate objects canhave multiple attributes, including additional compound attributes, al-lowing further nesting of complex data. Compound attributes are oftenused 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 col-umn headings of the table correspond to the attributes of the subordi-nate objects.

Toggle bi-valued attribute capable of representing a true or falsestate. During specification, these values usually appear as enabled ordisabled , though certain bi-valued attributes can use specific namesfor these two values; during simulation they correspond to the constantsOPC_TRUE and OPC_FALSE , respectively. Toggle attributes are used torepresent properties of an object that can only have two possible set-tings, typically some sort of status of the object. Examples include thecondition of a node (its operational status), or the endsim intrpt at-tribute of a processor (selects whether or not the Kernel will deliver aspecial interrupt to the processor when the simulation completes).

Toggle Double may represent the same range of values as the above-described double attribute when placed in the enabled state. The dis-abled state indicates that the attributes value should not be considered.Thus a toggle double attributes value may appear either as disabledor as a number; the value enabled never appears. The special constantvalues that apply for ordinary double attributes also apply and have thesame meanings for toggle double attributes. In addition, the constantOPC_BOOLDBL_DISABLED is used to represent the disabled state. Tog-

gle double attributes are used to specify optional characteristics of anobject, and they have a numerical form when they are selected.

String a series of characters used to hold a single line of text. Typicalexamples include names, logic statements, or the name of an object orother general property.

String List also a series of characters holding a single line of text,string list attributes are intended to contain multiple textual elementswhich together form a value. The elements can be separated by com-mas, tabs, or spaces within the string. A typical use of this type of at-tribute is for the argument list (e.g., the interarrival args of agenerator) of a probability distribution, where both mean and variancemay be specified.

Typed File character string representing a file that is part of OP-NETs system of managed files. Typed file attributes refer to a specifictype of file corresponding to a suffix at the end of the file name. Thetyped file data type provides two services: 1) automatic path name con-struction allows the user to simply specify a file name and OPNET can

8/2/2019 02_20Framework

24/110

86-Fram


determine the actual location of the file in the filesystem; and 2) whenprompting for an assignment for a typed file attribute, OPNET con-structs a list of those files that are available. Examples of attributes of this data type: a mobile nodes trajectory, a satellites orbit, a proces-sors process model, a nodes node model, or a generators interarrivalPDF.

Icon character string representing an icon from one of the active icondatabases. Selected icon databases are loaded when OPNET is execut-ed, and the set of icon names that can be chosen from for these attributesis the union of all the icon names included therein. Icon attributes areused only to control graphical representation of an object, and are notpresent during simulation.

Enumerated these attributes appear as character strings during spec-ification, and as integers during simulation. In both contexts, a finite,and usually small set of values can be assigned to them. In this sensethey may be thought of as a generalization of toggle attributes. Thestring representation is provided for specification because it is general-ly more informative; during simulation, integers are a more efficientand useful datatype to manipulate. Examples of this data type includethe src stream and dest stream attribute of packet streams, and aprocessors failure intrpts attribute.

Color some OPNET objects allow the user to control the color usedto draw them. For example, satellite orbits and point-to-point links eachcan be assigned a color from a color palette. Like icon attributes, colorattributes are strictly used while specifying models, and play no roleduring simulation.

Textlist these attributes store a list of character strings to representgeneral textual information. Typical applications are sections of user-defined code, or documentation.

Attribute Properties

Though they appear to be relatively simple on the surface, attributes can becomplex entities. While an attribute is identied by a name, and its function is tostore a value, the way in which the attribute behaves is described by a thirdcomponent, called the attributes properties . In broad terms, attribute properties

Key Concepts

Attributes can store diverse types of data, depending on their purpose.Data types include several forms of logical, numerical, and text stor-age, as well as a special type called compound that holds nested ob-

jects.

8/2/2019 02_20Framework

25/110

87-Fram


specify: the type of data an attribute can store; how it can be manipulated; how it ispresented to the user; and the function it performs. The following table explainseach of the components of attribute properties:

Attribute Properties

Property Description

Data Type Species the type of information that the attribute canstore. This property is sometimes referred to simply as theattributes type.

Default Value The value that may be used by the system when anassignment is required, but none has been provided bythe user. Also used to suggest a value to a user whenprompting for an assignment.

Units Additional information that can assist users in enteringcertain numerical attribute values. For example for adistance 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.

Range A numerical interval that may restrict the set of values thatan attribute can store. The interval consists of a lower andan upper bound, each of which may have a value or beopen . An open bound means that the interval is open-ended toward negative or positive innity. A bounds valuemay be specied if the bound is exclusive or inclusive .An inclusive bound means that the bound value itself isallowed, whereas an exclusive bound means that allvalues within the bound are allowed, but not the bounditself.

Symbol Map A collection of user-dened symbolic names associatedwith specic attribute values. Symbol maps are used tosuggest reasonable values for an attribute and in somecases also to restrict the allowable values to a discreteset. The symbol map includes an allow other values component, which dictates whether values other thanthose enumerated in the symbol map can be held by theattribute.

8/2/2019 02_20Framework

26/110

88-Fram


As mentioned above, symbol maps allow a pre-dened word or phrase torepresent an underlying value for an attribute. The word or phrase is referred to asthe symbol, and can contain any general sequence of characters. However, thereare a few symbols that are reserved for numerical attributes. These symbolsrepresent special values supported by OPNET, and are therefore not permitted asuser-dened symbols. In addition, there are restricted forms that symbols are notallowed to match. These restrictions are shown in the following table.

Attribute Description Indicates whether the attributes properties are public orprivate. If the attribute description is private, then theproperty specications belong specically to a particularattribute denition. If the attribute description is public,then the properties specications can be shared withother attribute denitions in the same or other models.Public attribute descriptions provide a means of deningre-usable attribute classes and managing them in acentralized manner.

Comments Documentation that may provide any relevant informationabout the attribute, as a model designer sees t. Typicallythese include a description of the attributes meaning, andinstructions on how to use it.

Restrictions on Attribute Symbols

Restricted Form orSymbol Details

zero length Symbols must contain at least one character.

Other Reserved word. Used as a choice when Allow Othersoption is enabled.

(...) Reserved word. Used to represent a compoundattributes value.

promoted Reserved word. Used to represent the value of apromoted attribute.

Attribute Properties (Cont.)

Property Description

Key Concepts

An attributes data type is just one of its properties . Properties specifyinformation about how an attribute can be used, how it behaves, andhow it is presented.

8/2/2019 02_20Framework

27/110

89-Fram


Viewing Attribute Properties

You can view or change attribute properties in the Attribute Properties dialogbox. Because you can change properties only at certain times, however, there aretwo versions of this dialog box. A read-only version restricts you to viewing theattribute 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. Thisprocedure uses an Attributes dialog box.

2) Check the Advanced check box, then left-click an attribute name to select it.

contains Symbols cannot contain the double quote character ().

contains | Symbols cannot contain the vertical bar character (|).

TO Symbols may not contain this form, which is reservedto represent a range of values.

Restrictions on Attribute Symbols

Restricted Form orSymbol Details

8/2/2019 02_20Framework

28/110

90-Fram


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 consistentdenition for transmitter channels, receiver channels, and for links. It is of coursepossible to specify the attributes denition for each type of object or model thatrequires it. However, this approach has the disadvantage of being redundant andtherefore requiring more work. Even more importantly, separate and redundantspecications require signicantly more work to maintain as changes becomenecessary, and allow inconsistencies to develop between the denitions.

A much safer and more economical approach is to maintain a centralizeddenition of the attribute. OPNET supports this approach with a feature calledPublic Attribute Properties . Public attribute properties are normal attributeproperties specications that can be referred to by an attribute. By maintainingonly references to the properties, rather than the actual specications, multipleattributes automatically track any changes to the properties.

8/2/2019 02_20Framework

29/110

91-Fram


Compound Attributes

As mentioned earlier, OPNET supports both simple and compound attributes.Simple attributes contain data with a at structure, whereas compound attributes

As attrs.

Bs attrs.

Cs attrs.

This attributes description isPublic and shared to dene theproperties of attributes forobjects A, B, and C

Sharing of Public Attribute Descriptions

A

B

C

All properties are takenfrom attribute descriptioncalledip_address_index

Making Attribute Properties Public

Key Concepts

An attributes properties can be private or public. A private attributeproperty description is applicable only to the attribute that it is associ-ated with. A public attribute property description is shared by many at-tributes, potentially in different objects and different models. Changingthe public attribute properties affects all of the dependent attributes.

8/2/2019 02_20Framework

30/110

92-Fram


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 speciedby the compound attributes count .

Each contained object has its own set of attributes. The attributes of the nestedobjects are full-featured, including a name, value, and properties. They canthemselves be compound, allowing unlimited nesting of objects embedded via

compound attributes.

Some examples of compound attributes are provided by the built-in (pre-dened) attributes of certain OPNET objects. For example, each queue object(used in the Node Domain) can contain one or more subqueues, which arethemselves objects. The entire conguration of subqueues is modeled as a singlecompound attribute of the queue. By specifying the count for the subqueueattribute, the user can specify that any number of subqueues be instantiated withinthe queue object. Similarly, channels for transmitter and receiver objects arerepresented as compound attributes. User dened attributes for objects and modelsmay be compound as well, and their attributes can be completely general.Typically, compound attributes are used to represent data that has the form of atable (such as a routing table) or a list of virtual circuits. In these examples, each

route or circuit can be considered an object.

Like all attributes, compound attributes have a single value. The value of acompound attribute is a special object known as a compound attribute object . Thecompound attribute object (CA-object) has no attributes but serves merely as aplaceholder to group a set of subordinate objects together. During specication(i.e., in the OPNET editors), the CA-object is represented as shown in thefollowing illustration.

Key Concepts

The purpose of a compound attribute (CA) is to provide complex datain an object or model interface. CAs can be nested arbitrarily deep. ACAs properties define the objects that it will store. Each attribute of thenested objects is defined as a full attribute with a name, and proper-ties. A count of nested objects is specified.

Key Concepts

OPNET uses compound attributes (CAs) for some of its built-in objectattributes. These include the subqueue attribute of queue objects, andthe channel attribute of transmitter and receiver objects.

8/2/2019 02_20Framework

31/110

93-Fram


During simulation, each CA-object has an object ID. This object ID can beused to access the subordinate objects. The CA-object is considered to be theparent of the subordinate objects and these can be accessed using the KernelProcedure op_topo_child() . (Refer to section Fram.3.9 The Object Hierarchy formore information on parent-child relationships.) Similarly, op_topo_parent() canbe used to determine the object ID of the CA-object given knowledge of one of thesubordinate objects. Refer to the Topology Package chapter of the SimulationKernel manual for more information on these Kernel Procedures.

In the case of built-in compound attributes, the subordinate objects have aspecic type: for the subqueue compound attribute of a queue, the subordinateobject is the pre-dened object called subqueue. Similarly, the channelattribute for a point-to-point transmitter contains point-to-point transmitter channelobjects. Each transmitter and receiver channel compound attribute contains its ownspecic type of subordinate object. However, for user-dened compoundattributes, a generic object type is dened. Generic objects have no built-inattributes, but are entirely determined by the attribute denitions that usersprovide. Like subqueues and other subordinate objects, generic objects areconsidered to be the children of compound attribute objects. The following

diagram illustrates the relationships between objects, compound attributes, CA-objects, and generic or subordinate objects.

Presentation of Compound Attributes Values

A compound attribute value appears as (...)to indicate underlying complex data
http://../03_SimKern/03_76_Topo.pdfhttp://../03_SimKern/03_76_Topo.pdf

8/2/2019 02_20Framework

32/110

94-Fram


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 aboutthem. Node and link objects also receive additional attributes from the modelsassociated with them; these model attributes dene the objects behavior in anetwork 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 extendedattribute must be built into a model used by at least one of the objects in thenetwork model. This support is provided by the model developer and should bedescribed in the model documentation.

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

S

OBJ

CA

G

For OPNET-providedcompound attributes,the CA-objects childrenare specic subordinateobjects (e.g., channels,subqueues).

For user-denedCAs, the CA-ob-

jects children aregeneric objectswhich have theirown attributes.

CA

G

Generic object attributesmay also be compound,allowing unlimited nestingof generic objects.

Compound Attribute Structure

Key Concepts

A compound attributes (CAs) value is a special object called com-pound attribute object (CA-object). The CA-object acts as a concen-trator for all of the subordinate objects. The subordinate objects areconsidered to be children of the CA-object.

8/2/2019 02_20Framework

33/110

95-Fram


Creating Extended Attributes

When creating an extended attribute, you can add it to any network object thatmay need it. Extended attributes become primary attributes of an object andautomatically appear in the objects Attributes dialog box.

To create an extended attribute

1) Select Edit Attributes from the object pop-up menu to display the objectsAttributes 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 newattributes.

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 cellin 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 anddefault value.

5) Under the Type column, select an appropriate data type from the pull-downmenu. Possible data types are described in the following table.
http://-/?-http://-/?-

8/2/2019 02_20Framework

34/110

96-Fram


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.

Attribute Data Types

Data Type Description

Integer Positive or negative whole numbers witha magnitude less than 2 31 -64.

Double Positive or negative double-precisionoating point numbers with a magnitudeless than 10 100 . These attributes typi-cally represent precise numerical quan-tities.

String Characters representing the name of anobject or property.

Toggle Value representing an enabled or dis-abled state.

Typed File Character string representing a file thatis part of Planner OPNETs system ofmanaged files. These refer to a specifictype of file identified by a .gdf suffix atthe end of the file name, as seen in yourmodel directories. For more informationon typed files and their suffixes, refer tothe System Environment chapter in the

External Interfaces manual.

Compound A grouping of several attributes into asingle attribute value. Compoundattributes allow you to describe a com-

plex set of characteristics for an objectby dening typical values for a singlecompound attribute. For instructionson dening compound attributes, referto Compound Attributes on page 91.
http://../07_Ext_Int/07_10_Env.pdfhttp://../07_Ext_Int/07_10_Env.pdf

8/2/2019 02_20Framework

35/110

97-Fram


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

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.

Extendedattribute

8/2/2019 02_20Framework

36/110

98-Fram


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 forchanging the range , symbol map , and comments properties appear in thefollowing 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 theattribute. 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 bewithin 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 typeproperty of integer or double . The range property is inactive for all other datatypes.

To specify a range of values

1) In the pull-down menus following the From and To elds, specify whether thebeginning and end of the range of values are inclusive , exclusive , oropen :

Inclusive indicates that the specified number is included with therange of values.
http://-/?-http://-/?-http://-/?-

8/2/2019 02_20Framework

37/110

99-Fram


Exclusive indicates that the specified number is excluded from therange 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 , indicatingthat 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 theeld 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 emptyfor an upper limit of positive innity.

Symbol Map

The symbol map property allows you to dene symbolic names for specicattribute values. The names used in symbol maps can represent common orfrequently used values of the attribute described by this property. For example, youcould dene a symbol called T1 for the data rate attribute of a model andassign the value 1.544 Mbps to that symbol. Users of the model could then specifythe T1 data rate without having to remember its actual value. Symbol maps areparticularly valuable when used with compound attributes (described in sectionCompound Attributes on page 91 ), where they allow you to specify an extensiveconguration with a single symbolic value.

In addition to serving as an enumerated list of common values, a symbol mapcan also restrict attribute values to only those values in the list. If the Allow OtherValues check box is deselected (the default), only attribute values in the symbolmap are permitted.

The following restrictions apply to symbol maps:

If you specify a range of allowed values with the range property, youcan create symbols with values outside this range, but you will be un-able to assign such symbols as attribute values.

Range Example

With these values of the range property,

attribute values must be: greater than or equal to 10, and

less than 20.

8/2/2019 02_20Framework

38/110

100-Fram


If you use the symbol map to restrict attribute values, the value of thedefault 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 dia-log box and click the Add button. (You can also enter new symbols to the tableby 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 theValue

column. If a rangeis 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 areallowed.

8/2/2019 02_20Framework

39/110

101-Fram


5) To allow the attribute to have assigned values other than those in the symbolmap, select the Allow Other Values check box.

The model user can assign attribute values that are defined by the sym-bol maps.

6) To restrict attribute values to only those in the symbol map, deselect the AllowOther Values check box.

The model user is now restricted to selecting those attribute values thatare defined by the symbol maps.

7) If you restricted the attribute values in the preceding step and the currentdefault value is not one of the allowed values, select a new default value fromthe Default Value pull-down menu. Any symbols that have been dened willappear on this menu.

Comments

The comments property provides a way to describe an attribute to users of amodel. Information you type in the text entry area provided will be available toanyone viewing the attribute properties. The comments you provide in thisproperty 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 particularforms of more general models. Generalizations result from isolating fundamentalproperties 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 isthat they become highly reusable and the modeler can benet to a greater extentfrom pre-existing models. The generalized models can be thought of as modelclasses that are maintained in libraries and that can be specialized at the timethey are used.

For example, a process model that implements a ow-control protocol mayplace a limit on the number of transmitted messages that can remainunacknowledged at any given time; this number is usually called the protocolswindow . When developing such a model, it is useful to view the window as aexible 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, eachwith its own window size value. The second benet is that future modeling effortsmay reuse the model, even if a different window size is needed. This approach is incontrast to that of creating multiple process models, each with hardwiredwindow size values.

8/2/2019 02_20Framework

40/110

102-Fram


Model attributes are dened only by the model designer; OPNET accords nosemantic value to them. The knowledge of what model attributes represent andhow they are to be used must be embedded by the model designer within themodels themselves. In general, this type of processing of attribute assignmentsmust be performed by program logic. In OPNET, this is possible both in processmodels and in pipeline stages (models for link behavior). In the vast majority of cases, model attributes are analyzed and processed by process models.

Model attributes exist in three types of models in OPNET: Process, Node, andLink. 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 theobject. The attributes are integrated into the objects attribute list as though theywere part of the object itself. Each object that is an instance of the model has itsown private copies of the model attributes, and these can be accessedindependently.

Key Concepts

A model developer may use attributes in order to expose appropriatecontrol to its external users. Exposing a characteristic or feature asan attribute extends the applicability of the model by allowing it to beadapted to more diverse situations. The model is therefore more gen-eral and reusable.

Key Concepts

Model attributes are developer-defined and unknown to the OPNETsystem. Their meaning and use are determined by the models them-selves.

8/2/2019 02_20Framework

41/110

103-Fram


Fram.3.6 Objects and AttributesEach 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 objectsare simply intrinsic to the objects core denition. These are referred to as built-inattributes and are permanently associated with the object. All OPNET objects havesome minimal set of built-in attributes that are considered fundamental for eachtype of object. The set of specic built-in attributes will vary depending on the typeof 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 ina process model possesses only built-in attributes, including the enter and exitexecutives, and its status. Virtually all OPNET objects have a built-in attributecalled 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-inattributes of each supported object.

M

O3O1 O2

Objects O1, O2, and O3 are instances of model M

Objects O1, O2, and O3 inheritattributes of model M

Inheritance of Model Attributes by Objects

Key Concepts

A models attributes are inherited by objects that depend on the mod-el. They are added into the objects set of attributes and treated as ifthey belonged to the object.

8/2/2019 02_20Framework

42/110

104-Fram


One particular attribute called model plays a special role in OPNET. Asmentioned previously, this attribute species a large part of an objectscharacteristics. Among these characteristics are additional attributes may beacquired by an object when its model is designated. These additional attributes aredened within the model and relate to congurable functionality that is specic tothe model. The functionality can be independently controlled for each modelinstance.

Finally, certain OPNET objects support the ability to append attributes to theirattribute list. These are called extended attributes and are created one at a time foreach object that requires them. Because each extended attribute must be denedand assigned separately for each object, this mechanism is generally much weakerthan placing the attributes within models, as discussed above. However, there aresome objects that do not support a model attribute, and in some cases, modeldevelopers may have a need to associate new data with those objects. Underlyingmodels can generally not rely on the existence of these attributes since they arecreated manually. Therefore, the existence of an extended attribute is generallyveried 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, incertain scenarios, the existence of the attribute is all that is of interest; the attributein 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 forsome reason, a particular subnet needs to be designated as special, an extendedattribute 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 thisinformation.

Extended Attributes

OBJ

Model Attributes

Built-In AttributesBuilt-in, model, and extendedattributes are grouped into asingle object s attribute list.

Aggregation of Attribute Sources into an Object Attribute List

8/2/2019 02_20Framework

43/110

105-Fram


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 instancescan originate from two separate sources. The rst source, model attributes,represents an explicit denition of a newly created attribute that should be passedon to objects. Model attributes were discussed in a previous section of this chapter.The second source is referred to as object attribute promotion . Attribute promotionprovides 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.

Promoted object attributes actually promote to the attribute interfaces of theencompassing model. Thus, the promoted attributes of various objects may appeartogether in the models attributes. These attributes combined with those declared asmodel attributes form the models aggregate attribute interface.

Key Concepts

Each object maintains a list of attributes that provide external controlof the objects functions and behavior. Object attributes may comefrom several different sources: they may be built-in to the object; theymay be inherited from the objects model; or they may be appended tothe object as extended attributes .

Presentation of Promoted Attributes

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

8/2/2019 02_20Framework

44/110

106-Fram


When a promoted object attribute is added to the models attribute interfaces, itis prexed with the name of the object it belongs to. This ensures that no namingconicts occur between attributes with the same name but belonging to differentobjects. The prexing mechanism is illustrated in the following diagram.

Promoted attributes may travel several levels through the model hierarchy.They simply continue to promote until they receive an assignment at one of thehigher levels. Thus, a promoted attribute of a module within a node model canpromote through the node models interfaces and appear on a node object in thenetwork level. If the node object provides no assignment for that attribute, then itwill promote to successively encompassing subnet objects. The highest object inthe model hierarchy is the top subnet which may also receive the attribute. In th

02_20Framework

Documents

Transcript of 02_20Framework