Chapter 1 Modeling Overview - Suraj @ LUMSsuraj.lums.edu.pk/~te/simandmod/Opnet/01 Modeling Overview.pdf · OPNET users can be divided into two broad ... Modeling Overview Ov.3 Typical

1-Ov

Modeling Overview

Chapter 1

2-Ov

Modeling Concepts

3-Ov

Modeling Concepts

IntroductionM

od

eling

Overview

Ov.1 Introduction

OPNET provides a comprehensive development environment supporting themodeling of communication networks and distributed systems. Both behavior andperformance of modeled systems can be analyzed by performing discrete eventsimulations. The OPNET environment incorporates tools for all phases of a study,including model design, simulation, data collection, and data analysis.

This chapter provides an overview of OPNET’s capabilities and structure. It isintended to provide an introduction to the package and context for further readingof the documentation. The chapter is divided into five sections, as follows:

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.

Overview Chapter: Content Summary

Section Topic

Key System Features Enumerates salient and distinctive characteristics of the OPNET software.

Typical Applications Presents some applications typically addressed with OPNET and some of the features that provide direct support for those applications.

Architecture Describes the OPNET approach to each phase of the modeling and simulation project. Presents fundamental modeling constructs.

Tools Introduces the tools that constitute the OPNET environment. Each tool supports a particular phase or sub-phase of the simulation and modeling project.

Authoring Capabilities Discusses the use of OPNET as an “authoring tool” to prepare models for “off-the-shelf” use by end users in the IT DecisionGuru or Modeler XE environments.

4-Ov

Introduction

Modeling Concepts

Ov.1.1 Multiple User Communities

OPNET users can be divided into two broad categories:

system modelers

and

authors

. System modelers are the traditional users of OPNET, who study technicalproblems using simulation. They are usually interested in performance measuresand behavioral analysis of a proposed system. Often they are designers ofnetworks, network devices and protocols, or distributed applications. Authors, onthe other hand, do not use OPNET to conduct their own simulation studies, but toprepare an environment for others to do so. OPNET Modeler is used to createcustomized models that are appropriate for a particular type of end user. Themodels are typically delivered to the end user in the Modeler XE environment,which offers the benefit of greater simplicity and ease of use.

Refer to the end of this chapter for more information on specific features ofOPNET that support its use as an authoring tool.

OPNET exists as both a

core

product, and in a Radio version (using theoptional Radio module). Modeler, in conjunction with the Radio module, providesspecific features to support projects related to wireless networking. It includes,among other radio-specific capabilities, the ability to model node mobility and theeffects of interference on radio link performance. Of course, many projects do notrequire radio capability and these can be carried out with the core version.Throughout this manual, indications are provided when features specific to theRadio version are discussed.

Key Concepts

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

Key Concepts

OPNET Modeler is used to construct models for two different pur-poses: to study system behavior and performance; and to deliver a modeling environment to “end users” with products such as IT Guru.

5-Ov

Modeling Concepts

Key System FeaturesM

od

eling

Overview

Ov.2 Key System Features

OPNET is a vast software package with an extensive set of features designed tosupport general network modeling and to provide specific support for particulartypes of network simulation projects. This section provides only a briefenumeration of some of the most important capabilities of OPNET. Subsequentsections of this chapter provide more detailed information on these features, aswell as other aspects of OPNET.

•

Object orientation

. Systems specified in OPNET consist of objects,each with configurable sets of attributes. Objects belong to “classes”which provide them with their characteristics in terms of behavior andcapability. Definition of new classes are supported in order to addressas wide a scope of systems as possible. Classes can also be derived fromother classes, or “specialized” in order to provide more specific supportfor particular applications.

•

Specialized in communication networks and information systems

.OPNET provides many constructs relating to communications and in-formation processing, providing high leverage for modeling of net-works and distributed systems.

•

Hierarchical models

. OPNET models are hierarchical, naturally paral-leling the structure of actual communication networks.

•

Graphical specification

. Wherever possible, models are entered viagraphical editors. These editors provide an intuitive mapping from themodeled system to the OPNET model specification.

•

Flexibility to develop detailed custom models

. OPNET provides aflexible, high-level programming language with extensive support forcommunications and distributed systems. This environment allows re-alistic modeling of all communications protocols, algorithms, andtransmission technologies.

•

Automatic generation of simulations

. Model specifications are auto-matically compiled into executable, efficient, discrete-event simula-tions implemented in the C programming language. Advancedsimulation construction and configuration techniques minimize compi-lation requirements.

•

Application-specific statistics.

OPNET provides numerous built-inperformance statistics that can be automatically collected during simu-lations. In addition, modelers can augment this set with new applica-tion-specific statistics that are computed by user-defined processes.

•

Integrated post-simulation analysis tools

. Performance evaluation,and trade-off analysis require large volumes of simulation results to be

6-Ov

Key System Features

Modeling Concepts

interpreted. OPNET includes a sophisticated tool for graphical presen-tation and processing of simulation output.

•

Interactive analysis

. All OPNET simulations automatically incorpo-rate support for analysis via a sophisticated interactive “debugger”.

•

Animation

. Simulation runs can be configured to automatically gener-ate animations of the modeled system at various levels of detail and caninclude animation of statistics as they change over time. Extensive sup-port for developing customized animations is also provided.

•

Application program interface (API)

. As an alternative to graphicalspecification, OPNET models and data files may be specified via a pro-grammatic interface. This is useful for automatic generation of modelsor to allow OPNET to be tightly integrated with other tools.

7-Ov

Modeling Concepts

Typical Applications of OPNETM

od

eling

Overview

Ov.3 Typical Applications of OPNET

As a result of the capabilities that were described in the previous sections,OPNET can be used as a platform to develop models of a wide range of systems.Some examples of possible applications are listed below with specific mention ofsupporting features:

•

Standards-based LAN and WAN performance modeling

—detailedlibrary models provide major local-area and wide-area network proto-cols. Configurable application models are also provided by the library,or new ones can be created.

•

Internetwork planning

—hierarchical topology definitions allow arbi-trarily deep nesting of subnetworks and nodes and large networks areefficiently modeled; scalable, stochastic, and/or deterministic modelscan be used to generate network traffic.

•

Research and development in communications architectures andprotocols

—OPNET allows specification of fully general logic and pro-vides extensive support for communications-related applications. Fi-nite state machines provide a natural representation for protocols.

•

Distributed sensor and control networks

,

“on-board” systems

—OPNET allows development of sophisticated, adaptive, application-level models, as well as underlying communications protocols andlinks. Customized performance metrics can be computed and recorded,scripted and/or stochastic inputs can be used to drive the simulationmodel, and processes can dynamically monitor the state of objects inthe system via formal interfaces provided by statistic wires.

•

Resource sizing

—accurate, detailed modeling of a resource’s request-processing policies is required to provide precise estimates of its per-formance when subjected to peak demand (for example, a packetswitch’s processing delay can depend on the specific contents and typeof each packet as well as its order of arrival). Queuing capabilities of

Proto-C

provide easy-to-use commands for modeling sophisticatedqueuing and service policies; library models are provided for manystandard resource types.

•

Mobile packet radio networks

—specific support for mobile nodes,including predefined or adaptive trajectories; predefined and fully cus-tomizable radio link models; geographical context provided by OPNETnetwork specification environment. (Radio version only)

•

Satellite networks

—specific support for satellite nodes, including au-tomatic placement on specified orbits, a utility program for orbit gener-ation, and an orbit visualization and orbital-configuration animationprogram. (Radio version only)

8-Ov

Typical Applications of OPNET

Modeling Concepts

•

C3I and tactical networks

—support for diverse link technologies;modeling of adaptive protocols and algorithms in Proto-C; notificationof network component outages and recoveries; scripted and/or stochas-tic modeling of threats; radio link models support determination offriendly interference and jamming.

9-Ov

Modeling Concepts

OPNET ArchitectureM

od

eling

Overview

Ov.4 OPNET Architecture

OPNET provides a comprehensive development environment for modeling andperformance-evaluation of communication networks and distributed systems. Thepackage consists of a number of tools, each one focusing on particular aspects ofthe modeling task. These tools fall into three major categories that correspond tothe three phases of modeling and simulation projects:

Specification

,

DataCollection and Simulation

, and

Analysis

.

These phases are necessarily performed in sequence. They generally form acycle, with a return to Specification following Analysis. Specification is actuallydivided into two parts: initial specification and re-specification, with only the latterbelonging to the cycle, as illustrated in the following figure.

Ov.4.1 Model Specification

Model specification is the task of developing a representation of the systemthat is to be studied. OPNET supports the concept of model reuse so that mostmodels are based on lower level models developed beforehand and stored in modellibraries. Ultimately, however all models are based on the basic concepts andprimitive building blocks supplied by the OPNET environment.

Ov.4.1.1 Specification Editors

OPNET supports model specification with a number of tools or

editors

thatcapture the characteristics of a modeled system’s behavior. Because it is based on asuite of editors that address different aspects of a model, OPNET is able to offerspecific capabilities to address the diverse issues encountered in networks anddistributed systems. To present the model developer with an intuitive interface,these editors break down the required modeling information in a manner thatparallels the structure of actual network systems. Thus, the model-specificationeditors are organized in an essentially hierarchical fashion. Model specificationsperformed in the Project Editor rely on elements specified in the Node Editor; inturn, when working in the Node Editor, the developer makes use of models defined

Re-Specification

Data Collection and

Analysis

Initial SpecificationSimulation

Simulation Project Cycle

10-Ov

OPNET Architecture

Modeling Concepts

in the Process Editor. The remaining editors are used to define various data models,typically tables of values, that are later referenced by process- or node-levelmodels. This organization is depicted in the following list.

•

Project Editor—

Develop network models. Network models are madeup of subnets and node models. This editor also includes basic simula-tion and analysis capabilities.

•

Node Editor—

Develop node models. Node models are objects in anetwork model. Node models are made up of modules with processmodels. Modules may also include parameter models. (Modeler only)

•

Process Editor—

Develop process models. Process models controlmodule behavior and may reference parameter models. (Modeler only)

•

Link Model Editor

—Create, edit, and view link models. (Modeleronly)

•

Packet Format Editor

—Develop packet formats models. Packet for-mats dictate the structure and order of information stored in a packet.(Modeler only)

•

ICI Editor

—Create, edit, and view interface control information (ICI)formats. ICIs are used to communicate control information betweenprocesses. (Modeler only)

•

Antenna Pattern Editor

—Create, edit, and view antenna patterns fortransmitters and receivers. (Modeler/Radio only)

•

Modulation Curve Editor

—Create, edit, and view modulation curvesfor transmitters. (Modeler/Radio only)

•

PDF Editor

—Create, edit, and view probability density functions(PDFs). PDFs can be used to control certain events, such as the frequen-cy of packet generation in a source module. (Modeler only)

OPNET makes use of graphical specification of models wherever appropriate.Thus, the model-specification editors all present a graphical interface in which theuser manipulates objects representing the model components and structure. Each

Key Concepts

OPNET Models are structured hierarchically, in a manner that paral-lels real network systems. Specialized editors address issues at dif-ferent levels of the hierarchy. This provides an intuitive modeling environment and also permits re-use of lower level models.

11-Ov

Modeling Concepts

OPNET ArchitectureM

od

eling

Overview

editor has its own specific set of objects and operations that are appropriate for themodeling task on which it is focused. For instance, the Project Editor makes use ofnode and link objects; the Node Editor provides processors, queues, transmitters,and receivers; and the Process Editor is based on states and transitions. As a result,the diagrams developed in each editor have a distinct appearance, as shown in thefollowing screen samples.

Ov.4.1.2 Modeling Domains

The Network, Node, and Process modeling environments are sometimesreferred to as the

modeling domains

of OPNET, since they essentially span all thehierarchical levels of a model. The remaining specification editors correspond tono particular modeling domain since they mainly support the three principaleditors. As mentioned earlier, the capabilities offered by the three modelingdomains mirror the types of structures found in an actual network system; theissues addressed by each domain are summarized in the following table and thenbriefly described in the remainder of this section.

Graphical Editors for Network, Node, and Process Models

Project Editor

Node Editor

Process Editor

12-Ov

OPNET Architecture

Modeling Concepts

Network Domain

The Network Domain’s role is to define the topology of a communicationnetwork. The communicating entities are called

nodes

and the specific capabilitiesof each node are defined by designating their

model

. Node models are developedusing the Node Editor, discussed later in this section. Within a single networkmodel, there may be many nodes that are based on the same node model; the term

node instance

is used to refer to an individual node, in order to distinguish it fromthe class of nodes sharing the same model. However, in general, when the term

node

is used by itself, in the context of the network domain, it can be assumed thata node instance is being referred to, rather than a node model.

A network model may make use of any number of node models. OPNET doesnot place restrictions on the types of nodes that can be deployed in acommunication network; instead it adopts an open approach whereby modelerscan develop their own “library” of node models to use as building blocks fornetwork models. In addition, there are no limits on the number of node models ornode instances that a network model may contain (other than those imposed byworkstation memory limitations).

The Project Editor can provide a geographic context for network modeldevelopment. You can choose locations on world or country maps for the elementsof wide-area networks and can use dimensioned areas for local-area networks. Inaddition to providing an intuitive environment for deploying the components of a

OPNET Modeling Domains

Domain Editor Modeling Focus

Network Project Network topology described in terms of subnetworks, nodes, links, and geographical context.

Node Node Node internal architecture described in terms of functional elements and data flow between them.

Process Process Behavior of processes (protocols, algorithms, applications), specified using finite state machines and extended high-level language.

Key Concepts

A network model may contain any number of communicating entities called nodes. Nodes are instances of node models, developed using the Node Editor. Modelers can develop their own library of custom-ized node models, implementing any functionality they require.

13-Ov

Modeling Concepts

OPNET ArchitectureM

od

eling

Overview

network model, this feature provides an intrinsic notion of distance, which allowsautomatic calculation of communication delays between nodes.

The basic object used to build network models is the

fixed

communicationnode. In OPNET, this is the only type of node available. Fixed nodes can beassigned arbitrary locations, but during a simulation their location may not change.OPNET Radio versions allow networks to contain fixed nodes, but also addcapability for

mobile

and

satellite

nodes. Mobile nodes can be assigned predefinedtrajectories that specify their positions as a function of time throughout asimulation run; similarly, satellite nodes are assigned orbits that prescribe theirmotion. With the Radio version, simulations can involve all three types of nodes.

Most nodes require the ability to communicate with some or all other nodes toperform their function in a network model. Several different types ofcommunication link architectures are provided to interconnect nodes thatcommunicate with each other. OPNET provides

simplex

(unidirectional) and

duplex

(bidirectional)

point-to-point links

to connect nodes in pairs and a

bus link

to allow broadcast communication for arbitrarily large sets of fixed nodes. TheRadio version adds the capability for fixed, satellite, and mobile nodes tocommunicate with each other via

radio links

. While bus and point-to-point linksare modeled as explicit objects that you must create, radio links are dynamicallyevaluated based on characteristics of the communicating nodes. As will bediscussed in later chapters, each type of link can be customized by editingparameters or supplying new logic for the underlying link models. The followingfigures show some typical network model diagrams involving each of thesupported link types.

Key Concepts

Network models consist of nodes and links which can be deployed within a geographical context. OPNET provides fixed nodes and point-to-point and bus links; the Radio version in addition provides mobile and satellite nodes, and radio links.

14-Ov

OPNET Architecture

Modeling Concepts

To break down complexity and to simplify network protocols and addressing,many large networks make use of an abstraction known as a

subnetwork

. Asubnetwork is a subset of a larger network’s devices that forms a network in itsown right. OPNET provides fixed, mobile, and satellite subnetworks to enhancenetwork models. These subnetworks can then be connected by different types ofcommunication links, depending on the type of subnetwork. The larger networkcan then be viewed as a network of its subnetworks. This abstraction can be carriedout at many levels. In other words, one can form networks of subnetworks, whichin turn are formed of other subnetworks, and so on. At the bottom of this hierarchy,the lowest level subnetwork is composed only of nodes and links, but no othersubnetworks.

Network Models with Radio, Bus, and Point-to-Point Links

Radio LinksBus Link

Point-to-Point Links

Key Concepts

Fixed, mobile, and satellite subnetwork objects provide hierarchy in the network model and are used to break down complexity into multi-ple levels. Subnets can contain various combinations of nodes, links, and other subnets, and can be nested to any depth.

15-Ov

Modeling Concepts

OPNET ArchitectureM

od

eling

Overview

In OPNET network models, subnetworks can be nested to an unlimited depthto construct complex topologies. The following set of diagrams, captured in theProject Editor, illustrate the use of fixed subnetworks to model hierarchicalnetworks.

Node Domain

The Node Domain provides for the modeling of communication devices thatcan be deployed and interconnected at the network level. In OPNET terms, thesedevices are called

nodes

, and in the real world they may correspond to varioustypes of computing and communicating equipment such as routers, bridges,workstations, terminals, mainframe computers, file servers, fast packet switches,satellites, and so on.

A Hierarchical Network with Two Levels of Subnetworking

16-Ov

OPNET Architecture Modeling Concepts

Node models are developed in the Node Editor and are expressed in terms ofsmaller building blocks called modules. Some modules offer capability that issubstantially predefined and can only be configured through a set of built-inparameters. These include various transmitters and receivers allowing a node to beattached to communication links in the network domain. Other modules, calledprocessors and queues, are highly programmable, their behavior being prescribedby an assigned process model. Process models are developed using the ProcessEditor.

A node model can consist of any number of modules of different types. Threetypes of connections are provided to support interaction between modules. Theseare called packet streams, statistic wires (also sometimes referred to as streams andstatwires, respectively), and logical associations. Packet streams allow formattedmessages called packets to be conveyed from one module to another. Statisticwires convey simple numeric signals or control information between modules, andare typically used when one module needs to monitor the performance or state ofanother. As will be discussed later in this manual, both packet streams and statisticwires have parameters that may be set to configure aspects of their behavior.Logical associations identify a binding between modules. Currently, they areallowed only between transmitters and receivers in order to indicate that theyshould be used as a pair when attaching the node to a link in the Network Domain.The following diagram illustrates a typical node model that includes the threetypes of connections.

Key Concepts

Node models consist of modules and connections. Modules are infor-mation sources, sinks, and processors. Some modules have pre-defined behavior; processor and queue modules are programmable via their “process model”. Connections (packet streams and statistic wires) allow information to flow between modules.

17-Ov

Modeling Concepts OPNET ArchitectureM

od

eling

Overview

The modeling paradigm selected for the Node Domain was designed to supportgeneral modeling of high-level communication devices. It is particularly wellsuited to modeling arrangements of “stacked” or “layered” communicationprotocols. In the Node Editor, a device that relies on a particular stack of protocolscan be modeled by creating a processor object for each layer of that stack anddefining packet streams between neighboring layers, as shown in the followingdiagram for the familiar TCP/IP stack.

Process Domain

As mentioned earlier in the discussion of the Node Domain, queue andprocessor modules are user-programmable elements that are key elements ofcommunication nodes. The tasks that these modules execute are called processes.A process can in many ways be thought of as similar to an executing softwareprogram, since it includes a set of instructions and maintains state memory.Processes in OPNET are based on process models that are defined in the ProcessEditor. The relationship between process model and process is similar to therelationship between a program and a particular session of that program running as

Node Model Employing Packet Streams, Statistic Wires, and Logical Associations

statistic wire

packet stream

logical association

Possible OPNET Representation of TCP/IP Protocol Stack

18-Ov


a task (in fact, the term “process” is used in many operating systems as well). Justas nodes created in the Project Editor are instances of node models defined withthe Node Editor, each process that executes in a queue, processor, or esys moduleis an instance of a particular process model.

The process modeling paradigm of OPNET supports the concepts of processgroups. A process group consists of multiple processes that execute within thesame processor or queue. When a simulation begins, each module has only oneprocess, termed the root process. This process can later create new processeswhich can in turn create others as well, etc. When a process creates another one, itis termed the new process’ parent; the new process is called the child of theprocess that created it. Processes that are created during the simulation are referredto as dynamic processes.

OPNET places no limits on the number of processes that may be created in aparticular processor or queue. Processes may be created and destroyed based ondynamic conditions that are analyzed by the logic of the executing processes. Thisparadigm provides a very natural framework for modeling many common systems.In particular, multitasking operating systems where the root process represents theoperating system itself and the dynamically created processes correspond to newtasks; and multi-context protocols where the root process represents a sessionmanager, for example, and each new session that is requested is modeled bycreating a new process of the appropriate type.

Only one process may be executing at any time. A process is considered to beexecuting when it is progressing through new instructions that are part of itsprocess model. When a process begins execution it is said to be invoked. A processthat is currently executing can invoke another process in its process group to causeit to begin executing. When this happens, the invoking process is temporarilysuspended until the invoked process blocks. A process blocks by indicating that it

Key Concepts

Process models define behavior for programmable modules. A pro-cess is an instance of a process model and operates within one mod-ule.

Key Concepts

Initially, each programmable module contains only one process; how-ever, processes can create additional child processes dynamically. These can in turn create additional processes themselves. This para-digm is well-suited to modeling systems with dynamically instantiated contexts, like certain protocols, or multi-tasking operating systems.

19-Ov


od

eling

Overview

has completed its processing for its current invocation. Once the invoked processhas blocked, the invoking process resumes execution where it had left off, in amanner similar to the procedure-call mechanism in a programming language suchas C.

Processes in OPNET are designed to respond to interrupts and/or invocations.Interrupts, which are discussed in significant detail in later sections of this manual,are events that are directed at a process and that may require it to take some action.They may be generated by sources external to a process group, by other membersof a process group, or by a process for itself. Interrupts typically correspond toevents such as messages arriving, timers expiring, resources being released, orstate changes in other modules. Once a process has been invoked due to aninterrupt, it may invoke other processes in the group and these may in turn invokeother processes, etc. An interrupt’s processing is completed when the first processthat was invoked blocks.

OPNET’s Process Editor expresses process models in a language calledProto-C, which is specifically designed to support development of protocols andalgorithms. Proto-C is based on a combination of state transition diagrams (STDs),a library of high-level commands known as Kernel Procedures, and the generalfacilities of the C or C++ programming language. A process model’s STD defines aset of primary modes or states that the process can enter and, for each state, theconditions that would cause the process to move to another state. The conditionneeded for a particular change in state to occur and the associated destination stateare called a transition. The following example, taken from the Process Editor,shows the relationship between states and transitions in a process model’s STD.

Key Concepts

Processes respond to interrupts, which indicate that events of interest have occurred such as the arrival of a message or the expiration of a timer. When a process is interrupted, it takes actions in response and then blocks, awaiting a new interrupt. It may also invoke another pro-cess; its execution is suspended until the invoked process blocks.

20-Ov


Proto-C models allow actions to be specified at various points in the finite statemachine. The actions can be extremely general in nature since they are expressedas C or C++ statements. In addition, because Proto-C is focused on modelingprotocols and algorithms, it provides an extensive library of over 300 KernelProcedures (also known as KPs) that can be invoked to perform commonly neededactions. Kernel Procedures are grouped into packages of related functions. Thefollowing table shows some of the capabilities provided by the Kernel Procedurelibraries.

Major Simulation Kernel Procedure Packages

Package Applications

Anim Support for custom animation development

Dist Probability distribution and random number generation

State Transition Diagram in the Process Editor

Key Concepts

Process models are expressed in Proto-C, a language combining graphical state-transition-diagrams, embedded C/C++ language data items and statements, and a library of Kernel Procedures that provide commonly needed functionality for modeling communications and information processing systems.

21-Ov


od

eling

Overview

The state transition diagram representation of Proto-C is well suited to thespecification of an interrupt-driven system because it methodically decomposes thestates of the system and the processing that should take place at each interrupt.STDs developed in OPNET’s Process Editor have a number of extensions beyondthe capabilities offered by traditional state-transition diagram approaches:

• State Variables. Processes maintain private state variables withnamed variables of arbitrary data types, including OPNET-specific,general C/C++ language, and user-defined types. This capability allowsa process to flexibly maintain counters, routing tables, statistics related

Ev Event list and event property query; event cancellation

Ici Formal interfaces between processes; association of information with interrupts

Id Identification of objects

Ima In-simulation query and modification of object attributes

Intrpt Query of interrupt properties; control of interrupt handling

Pk Creation, destruction, modification, analysis, and transmission of packets

Prg Programming support: linked lists, memory, string manipulation, debugging

Pro Creation, invocation of processes; process group shared memory

Q Queueing statistics; high-level queueing operations

Rad Dynamically changing a radio transmitter channel’s receiver group (Radio version only)

Rte Basic routing support for static routing implementations

Sar Segmentation and reassembly of packets

Sim Simulation control: customized messaging, simulation execution control

Stat Custom statistic generation; intermodule signalling via statistic wires

Strm Communication between modules via packet streams, packet delivery

Subq Low-level queueing operations: enqueueing, dequeueing, statistics, etc.

Tbl Accessing of tabular data: antenna patterns, modulations

Tim Importing traffic into an existing OPNET network model

Td Setting and getting of transmission data for custom link models

Topo Query of model topology (e.g., for automatic discovery and configuration)

Major Simulation Kernel Procedure Packages (Cont.)

Package Applications

22-Ov


to its performance, or messages requiring retransmission. Arbitrarycombinations of state variable values may be used in all decisions andactions implemented by a process.

• State Executives. Each state of a process can specify arbitrarily com-plex actions associated with the process entering or leaving that state.These actions, called state executives, are expressed with the full flexi-bility of the C/C++ language. Typical actions include modifying stateinformation, creating or receiving messages, updating the contents ofand sending messages, updating statistics, and setting or responding totimers.

• Transition Conditions. Transition condition statements, which deter-mine whether a transition should be traversed, may be expressed asgeneral C/C++ language booleans that make reference to properties ofa new interrupt as well as to combinations of state variables.

• Transition Executives. Transitions may specify general actions, calledexecutives, that are implemented each time that they are traversed.

Process Model Attributes

A process model may define parameters, called attributes, that are used once itis instantiated as a process to customize aspects of its behavior. This techniquefosters reuse of process models for various purposes by avoiding “hardwired”specification where possible. For instance, a process model that performs window-based flow control, may be defined with the window size as an attribute, so that itis reusable in different situations requiring different values of the window size.

Ov.4.1.3 Models, Objects, and Attributes

The preceding sections have discussed certain major OPNET model types andobjects. In this section, the OPNET object model is presented in greater detail.Wherever possible, information is presented in a manner which is independentfrom particular modeling domains, except when focusing on examples.

Objects

Objects represent entities that are part of the system of interest. In general, anobject is a component, or “building block” of a model and the object is said to be“part of” that model. So for example, a processor module is an object that is part ofa node model. An object generally plays one or more of the following roles in amodel:

Typical Roles of an Object in a Model

Specify behavior

Create information

Store and manage information

23-Ov


od

eling

Overview

Objects are created by various mechanisms in OPNET models. Many resultfrom explicit specification by the user via graphical or programmatic methods. Sofor example, a link object may be created in a network model by physicallydragging it from the Project Editor’s object palette. Other objects are createdautomatically by the system. For example, subqueue objects are automaticallycreated for a queue object. Similarly, when a node object is created, the objectswithin the node are also implicitly assumed to exist. Finally, during simulation,some objects are created dynamically by the system or by the model. A process,for example, can be considered an object and may be created at any time byanother process in order to perform a task. Dynamic objects are different in manyways than the statically created OPNET objects; in particular they offer morespecialized interfaces, allowing them to be manipulated in a more efficient manner.Most of the discussion in this section will not apply to dynamic objects.

Attributes

In order to achieve predictable and tractable behavior when building a complexmany-object system, each object must offer a well-defined interface. The interfaceof an OPNET object consists primarily of the attributes that it makes available andthe procedures that it supports to access its attributes or to cause it to performactions. Some procedures supported by objects are provided automatically byOPNET; others are programmed by users for specialized needs. Most proceduresvary according to the object type, and so few general comments can be made aboutthem except to say that it is crucial that they have a well known interface and thatthey shield users from underlying details of object implementation.

Process, modify, or relay information

Respond to events

Contain other objects

Attribute Components

Name

Typical Roles of an Object in a Model

Key Concepts

Objects are the building blocks of OPNET models and appear in each of the modeling domains. Some objects are created explicitly by the user; others are implicitly created by OPNET. During a simulation, certain types of objects can be created dynamically.

24-Ov


Attributes are data items used to configure an object and represent the controlthat the object’s designer has made available to the user. Each attribute has a namethat allows it to be referenced uniquely within the scope of a particular object.Each attribute also provides a storage area for the information that is “assigned toit”. This information is referred to as the attribute’s value. Finally, an attribute has aset of properties that specify the rules related to its use, as well as severaladditional functions. Major attribute properties are enumerated in the followingtable.

As mentioned in the table above, OPNET supports a particular attribute datatype called compound. Compound attributes support nested complex data storagewithin an object in a very simple manner: the value is itself another object. Thisobject can have any number of attributes of its own, including additionalcompound attributes. Certain OPNET built-in objects have compound attributes.For example, queues incorporate subqueues using this mechanism; similarly,transmitters and receivers represent the channels they contain as compoundattributes. User-defined models may also create compound attributes forapplication-specific purposes. A typical use of a compound attribute in a protocolmodel is to represent a routing or circuit table, for example.

Value

Properties

Attribute Properties

Property Description

Data Type Class of data storage. OPNET supports a wide variety of numerical and text storage types, as well as a compound attribute whose value is another object.

Default Value Provides a value that can be used in the absence of explicit assignment.

Range For numerical attributes, limits the set of acceptable values to specified bounds.

Symbol Map Enumerates a list of values and names that represent them. Supports pre-configuration and more meaningful presentation of value choices. Also can be used to limit value choices to a restricted set.

Comments Documents any information desired about the attribute. Generally describes the attribute’s purpose and interface (i.e., how it behaves)

Attribute Components

25-Ov


od

eling

Overview

Models

It was mentioned that many OPNET models (network, node, and process)consist largely of objects. At the same time, most objects “have a model” thatconfers upon them some or all of their characteristics. The object is said to be aninstance of the model, since there is a many-to-one relationship between a modeland the objects that refer to it. The model defines an object class that all of therelated objects belong to.

Some of OPNET’s objects are fundamental and have an implicit model thatcannot be changed by the user. For example, state objects in process models aresimple objects whose only means of external control is provided by their attributes.Their characteristics and behavior are defined and documented and these constitutetheir model; however, their fundamental behavior and structure are always similarand cannot be changed. Thus they offer no “model” attribute.

However, several key objects in OPNET offer a “model” attribute that allowstheir fundamental behavior and structure to be controlled externally. In fact,altering an object’s model can even cause it to acquire a completely new interface.Indeed, these objects are fundamentally quite generic, and most of theircharacteristics are obtained from the model that they refer to. The following tableenumerates the OPNET objects that support a “model” attribute.

In each of the model types listed in the table above, a model’s “interface” isspecified. One of the characteristics transferred to an object from its model is its setof attributes. The model dictates which new attributes will be acquired by theobject, and what their names and values will be. Similarly, it can specify values forattributes that intrinsically belong to the object and can also cause these to become

Objects Supporting Model Assignment

Object Modeling Domain

Model Type

Node (all types) Network Node

Link (all types) Network Link

Processor Node Process

Queue Node Process

Key Concepts

Objects provide attributes as a means of controlling their behavior. The attributes constitute part of the object’s interface. Each attribute has a name, a value, and properties. Properties specify the rules gov-erning the attribute’s use, including its data type, allowable values, suggested values, and documentation.

26-Ov


hidden from the user. Thus, the model can completely control the attributeinterfaces of the object.

Model Attributes and Attribute Promotion

With both models and attributes introduced as concepts, the notion of a modelattribute can be defined. In addition to describing objects, attributes can beassociated with models in order to represent a “parameter” of the model. This wasalready briefly mentioned in the case of process models in a previous section. Theimportance of providing a parameter for a model lies in increasing the generality ofthe model. By varying the values of the model’s parameter, a user can alter itsbehavior in some well-defined manner, without having to actually modify themodel itself. This approach can be contrasted with “hardwiring” the value of theattribute into the model itself, which exposes no control to the model’s user.Obtaining the behavior corresponding to a new value of the attribute would thenrequire complete duplication of the model and a change to the hard-wired value.Multiple versions of the model would then have to be maintained in a parallelmanner over time, which is clearly undesirable. The model attributes mechanismtherefore supports increased reusability of models.

In concrete terms, model attributes are specified as part of a model, but theyappear on objects. They are acquired by an object at the moment when that object’smodel is specified. The model’s attributes are simply added to those that areintrinsic to the object, as illustrated in the following diagram.

Key Concepts

OPNET objects have behavior and structure that is specified by a model. Models also specify part or all of an object’s interfaces.Some objects have implicit models that cannot be changed; others can be assigned models via their “model” attribute, allowing extensive customization.

Key Concepts

Models can be parameterized using model attributes. This mecha-nism provides users of the model with a means of control over some aspect of model behavior without requiring changes to the model internals. Model attributes generalize a model, making it more reus-able for diverse applications.

27-Ov


od

eling

Overview

A mechanism similar to that provided for model attributes allows objectattributes to be passed upward in the modeling hierarchy. This mechanism is calledattribute promotion. Promotion causes an object’s attribute to no longer have avalue; instead, the attribute appears at the “next level” in the model. For example,in the case of a module attribute in a node model, promotion moves the attributeinto the node model’s attribute interface, meaning that it will then be inherited byany node object in the network level that references the node model. In the case ofnode objects in the network level, a promoted attribute is added to the attributes ofthe subnet that it encompasses it. Attributes that promote all the way through themodel hierarchy become attributes of the overall system model, or equivalentlyattributes of the simulation. These can be assigned values at simulation run timevia a variety of mechanisms. It is then possible to iterate through a range ofparameter values in different simulations in order to study the system as a functionof the parameters.

Other Model Data

Model Attributes

Model “M”

Object Attributes

Object “O”object refers to model “M”

object acquires attributesA,B, C, and D

Inheritance of Model Attributes by an Object

ABCDXYZ

ABCD

Model = “M”

Key Concepts

Model attributes are inherited by objects that refer to the model. They become part of the object’s attribute list.

28-Ov


Derived Models

In many cases, model developers have a need to customize a model’s interfacewithout actually changing the model’s internal structure or behavior. Node and linkmodel attribute interfaces can be modified using a mechanism called modelderivation. Model derivation operates upon an existing model and generates aderived model that has attribute interfaces that differ in various ways.The resultingmodel is called a derived model, and the model used as the basis for its derivationis referred to as its parent model. A model which is derived from no other model (avery common case) is called a base model. All derived models have a unique basemodel that they refer to via one or more derivations.

The purpose of providing the derived model mechanism is to allow specializedinterfaces to be developed without having to duplicate or recreate corefunctionality in a model. Since a model and a derived model are fundamentally thesame in terms of structure and behavior, it makes sense that specification of thisinformation should be shared. This provides economy of specification and enforceslong-term consistency of these models as they are modified over time.

Ov.4.2 Modeling Communications with Packets

The previous sections describe the support OPNET provides for representingthe structure of a network, including the elements that appear at differenthierarchical levels. Communication of data takes place at all levels of thishierarchy and most of the supported objects play some role in implementing thiscommunication: processes can be considered to be both the sources and sinks ofdata and control information; the node domain is the context in which processescommunicate information with each other and with physical layer transmitters andreceivers; and the network domain allows nodes to exchange information witheach other via various types of communication links.

Key Concepts

Instead of having a value that is specified in advance, object attributes can be promoted. A promoted attribute “moves up” to the next level in the model hierarchy, allowing its specification to be per-formed there. Attributes that are promoted through the top of the hier-archy (topmost subnetwork) become attributes of the simulation.

Key Concepts

When a specialized version of a model is needed, a derived model can be created from it. The derived model shares the same structural and behavioral specification as its parent model, but parts of the par-ent’s interface may be altered. Successive derivations may be per-formed. A model that is not derived from any other is a base model.

29-Ov


od

eling

Overview

There are many forms of communication that are supported by the OPNETmodeling environment. However, there is one fundamental structure, called packet,that provides the most commonly used mechanism for information exchange.Packets are objects that contain formatted information that can changedynamically. They can be stored by and transferred between objects in each of themodeling domains. In the Node Domain, packets typically travel over streams; inthe Network Domain, they are typically transferred over links. Packets areessentially composed of three main storage areas. The first area can be viewed as alist of user-defined values called packet fields; the second area consists of a set ofpredefined values that are used by the OPNET system for tracing and accountingpurposes; and the third area contains transmission data attributes that are used tosupport customizable models for communication links.

Because OPNET simulations model each individual packet in a networkmodel, and the packet fields contain actual data values, fully accurate models ofprotocol interactions can be implemented. Processes can modify and obtain valuesof fields and base their actions upon their contents. Packet fields may contain dataof one of several supported data types. Integer and double (floating-point) fieldscan be used to represent flags, counters, timer values, network addresses, etc.Packet fields allow packets to be encapsulated within other packets, which is a

Key Concepts

Packets carry formatted information between simulation entities. They represent messages, packets, cells, transactions, etc. Packets can be transferred between objects in the Node and Network domains. Each packet contains 3 areas: user-defined fields, pre-defined fields for accounting, and transmission data used by link models.

User-Defined Fields

Index Name Type Contents Size

0 src_addr integer 5 16

1 dst_addr integer 9 16

2 timer_a double 0.84 12

3 timer_b double 1.00 8

4 ack integer 0 1

Predef. Fields

Name Contents

creat_mod 19

creat_time 4.005

owner 19

format transp_x

id 116

TD Attrs.

Index Contents

0 8

1 100.0

2 11.505

3 1.07e-07

4 11.509

(Note: Due to space limitations this chart shows the same number of items in each category, but in actuality, both user-defined fields and TDAs can have a variable number of entries; also, not all predefined fields are shown.)

Three Main Storage Areas of Packet Contents

30-Ov


fundamental mechanism supporting layered protocol modeling, since higher-layerprotocols request that lower layer protocols “transport” packets to remote peers.Structure fields provide general support for carrying user-defined C/C++ languagedata structures within packets; this is sometimes useful for sophisticatedapplications where complex information, such as routing tables, are transferredacross networks. The information field type is provided for convenient support of“bulk” or “filler” data in a packet, which can be important to accurately modelpacket size; information fields contain no values.

Packets fall into two broad categories: formatted and unformatted. A formattedpacket is one whose fields are defined according to a template called a packetformat. Packet formats are created in the Packet Format Editor and specify a list offield names, data types, sizes (that is, field lengths specified in bits), and defaultvalues. When formatted packets are created, they instantly acquire the fieldsdefined in their format and, when applicable, default values are installed in thosefields. Unformatted packets have no fields when they are created; fields are addedone at a time and can only be referenced by numeric index, not by name.Unformatted packets are typically useful only for very simple applications and therecommended approach is to define packet formats for most models, particularlywhen several different types of packets are used in a network.

Packet Field Types

Type Use

integer Whole numbers: flags, counters, addresses, etc.

double Floating point numbers: timer values, statistics, etc.

packet Encapsulation of higher-layer protocol data

structure Transport of complex user-defined data types

information Modeling of field size when content is irrelevant

Key Concepts

Each packet is modeled individually and can have arbitrary content in its fields. Several data types are supported for fields, including numerical values, encapsulated packets, and general data structures. Field size is specified, allowing accurate modeling of processing delays, transmission delays, buffer occupancy, etc.

31-Ov


od

eling

Overview

Packets can be used to transfer data at all levels of an OPNET network modelvia several communication mechanisms. Processors, queues, and other modulesforward packets within nodes via packet streams, which were introduced earlier inthis chapter. Packet streams may introduce delay and also queue packets until adestination module is ready to accept them. At the network level, packets are sentbetween nodes over communication links. Communication links use customizableunderlying models to model delays and errors in packet transmission. A thirdpacket transfer mechanism, called packet delivery, supports transfer of packetsbetween modules, regardless of their location in a network, without requiring anyphysical connection to exist between them.

OPNET packets are intended to represent information-carrying structures ofvarious types that appear in communications and systems architectures, includingpackets, messages, frames, cells, datagrams, and transactions. The term packet hasbeen chosen as a general term and should not be interpreted as restricting the typesof applications for which OPNET can be used.

For some communication networks, information transfer does not necessarilyoccur in packet form. In particular, some devices communicate with streams ofdata where information flow is continuous. In such cases, OPNET packets can betreated as messages that carry only model-relevant information between thecommunicating entities. This may include information such as the amount of datatransferred, or signaling data that is needed by the application models at either endof the stream. Depending on what the goal of the modeling effort is, the datastreams can be adequately represented by modeling the important phases of theiroperation (setup, tear-down, and control information transfer) with packets, oreven with other OPNET communication mechanisms that will be discussed later inthis manual.

Key Concepts

Packets may be made to conform to a packet format. Packet formats are defined in the Packet Format Editor and specify a template for a packet’s fields, including the names, types, and sizes of each sup-ported field.

Key Concepts

Though the term “packet” is used, OPNET packets can be used to represent other forms of communication as well. In stream-oriented communications, for example, packets may be used to represent key signalling information, allowing the “connection” to be modeled in terms of its duration, bandwidth requirements, etc.

32-Ov


Ov.4.3 Data Collection and Simulation

The objective of most modeling efforts is to obtain measures of a system’sperformance or to make observations concerning a system’s behavior. OPNETsupports these activities by creating an executable model of the system. Providedthat the model is sufficiently representative of the actual system, OPNET allowsrealistic estimates of performance and behavior to be obtained by executingsimulations. Several mechanisms are provided to collect the desired data from oneor more simulations of a system.

Ov.4.3.1 Simulation Output Data Types

OPNET simulations are capable of producing many types of output. Of course,because of the general programmability of process models and link models,developers are able to define their own types of output files, including text reports,proprietary binary files, etc. However, in most cases, modelers use the types of datadirectly supported by OPNET. These are output vectors, output scalars, andanimation. Each is briefly described in this section.

Output Vectors

The types of data that can be collected have several different forms. The mostcommon result extracted from a simulation is called an output vector, which issimply a collection of pairs of real values, called entries. An output vector, oftencalled simply a vector, contains an arbitrarily-sized list of entries collected during asingle simulation run.The first value in the entries can be thought of as theindependent variable and the second as the dependent variable. In OPNET theseare referred to as the abscissa and the ordinate, respectively. In the majority ofcases, the independent variable of a vector is simulation time, which increasesmonotonically as a simulation’s execution progresses. In other words, most vectorsrepresent the value of some quantity of interest as it varies over time. Under certainconditions, it is interesting to create vectors that have abscissa variables other thantime; this topic is discussed later in this manual. The following diagram depicts atypical data set contained in a vector. Note that it is possible for a vector to storemultiple ordinate values with the same abscissa value.

Key Concepts

Modelers can take advantage of the programmability of OPNET mod-els to create proprietary forms of simulation output, if desired. How-ever, in most cases, users work with the output that can be provided automatically by OPNET simulations. These are: output vectors, out-put scalars, and animations.

33-Ov


od

eling

Overview

Output Scalars

In contrast to vectors, scalar statistics are individual values. Typically, scalarstatistics are averages, probabilities, or peak values derived from a collection ofmeasurements. Examples include the average or peak size of a queue, the meanend-to-end delay of packets, the proportion of calls blocked or dropped, the meancall duration, etc. Based on these examples it is clear that many scalars are simplyproperties or statistics of the set of value pairs obtained in an output vector. Inother words, given all of the values in an output vector, a number of interestingscalars can be computed and recorded by a simulation. Note that it is not usuallynecessary to record all the values in a vector in order to compute a scalar thatreflects the entire data set. For example, the mean ordinate value of a vector can beobtained by maintaining a running sum of the vector’s values as they becomeavailable and dividing by a running count of the number of values recorded. Thus,recording scalars is often much more efficient in terms of disk space and disk I/Othan recording vectors.

Scalars are typically only of limited use when taken as individual data points.Instead, the usual practice is to combine scalars recorded over multiple simulationsto form a graph or curve that indicates how a system variable varies as a functionof other system parameters. Both the dependent and the independent systemvariables, used to generate such a graph, are recorded as scalars. For example, atypical graph generated in performance analysis is “Throughput vs. Offered Load”,which indicates how well a network is able to deliver the data that it is requested to

Key Concepts

Output vectors represent time-series simulation data. They consist of a list of entries, each of which is a time-value pair.

time Q Size0.0 0.00.3301 1.01.0 2.01.0 1.01.3301 0.05.0 1.05.0 2.05.0 3.010.0 2.010.6602 3.0...998.0 54.0

Output Vector Contents

ordinate (Q size) valuesabscissa (time) values

34-Ov


deliver, as the amount of data increases. Here the “Offered Load” scalar is anindependent variable that is varied as an input to each simulation. “Throughput” isthen measured over the course of the simulation, and its final value (since it isalready an average) is recorded as another scalar.

OPNET simulations record scalar statistics in a special type of file called anoutput scalar file. Unlike output vector files, these files contain the resultsgenerated by multiple simulations. Within an output scalar file, the scalars fromeach simulation run are kept in groups so that they can be related to each other. Inother words, when “Throughput” is graphed against “Offered Load”, each point inthe graph is formed by taking an abscissa and an ordinate value from the respectivescalar statistics within the same simulation run. Each point of the graph usuallycorresponds to a new simulation run. The following diagram shows a typical plotgenerated from scalar values.

Application-Specific Statistics

Both scalar and vector statistics can be computed and recorded automaticallyfor a set of predefined statistics. Predefined statistics in OPNET are related tovalues that can be measured at specific objects within the model. This includesstatistics such as queue sizes, link throughputs, error rates, and queuing delays. In

Key Concepts

Scalar statistics are individual values that represent a metric of inter-est. They are often derived from vector statistics, as an average, peak value, final value, or other statistic. Typically, a single value for each scalar statistic is recorded during a simulation; when many simula-tions are run, their scalar outputs are combined to form a graph.

Plot of Scalar Statistic Values

35-Ov


od

eling

Overview

addition, it is common for models to compute application-specific statistics duringa simulation and record them in scalar and/or vector output files. These statisticsmay be computed in a completely general manner, taking into account events thathave occurred, the current state of the system, the content of packets, etc.

Custom statistics may be declared by process models, in which case OPNETadds them to the set of built-in statistics of queues and processors that make use ofthose process models. The custom statistics can have a scope which is local orglobal. A locally-scoped statistic is maintained separately for each processor orqueue that declares it. This is appropriate for recording information that relatesonly to events at a particular location, such as the utilization of a CPU on aparticular server. In contrast, a global statistic is shared and contributed to by manyentities in the model, it is appropriate for recording information that relates to theperformance or behavior of the system as a whole. A typical example of a globalstatistic is the end-to-end delay of all application data transported by a network,regardless of origin or destination.

Animations

In addition to numerical forms of output, OPNET simulations can provide avisual analysis of a network model’s behavior. An animation is a dynamicgraphical representation of selected events that occurred during a simulation. Theevents may be depicted within a diagram from the Network, Node, or Processdomain, or simply in an empty window.

An OPNET simulation can be configured to generate certain types ofpredefined animations automatically. In addition, the Animation Kernel Procedurepackage provides the ability to program sophisticated animations that representsimulation events in a customized manner. The kernel procedures of the Animationpackage include general drawing as well as OPNET-specific graphics to provide aflexible animation capability.

Both automatic and custom animations can be viewed interactively during asimulation run or afterwards in a “playback” mode. Refer to the documentation forthe Animation package Kernel Procedures in the Simulation Kernel manuals andthe op_vuanim program description in the Utility Programs manual for moreinformation on developing and viewing animations.

Key Concepts

OPNET supports predefined statistics that are typically of interest in simulation studies. However, many projects require customized sta-tistics, computed in a manner specific to the application. OPNET sup-ports both local (related to an object) and global (related to overall system) application-specific statistics.

36-Ov


Ov.4.3.2 Selecting Data for Collection

Because OPNET-developed models typically contain a very large number ofpotential statistics and animations of interest, collection mechanisms are not activeby default when a simulation is executed. Instead, OPNET provides a mechanismto explicitly activate particular statistics or animations so that they will be recordedin appropriate output files. This is accomplished by specifying a list of probeswhen running a simulation. Each probe indicates that a particular scalar statistic,vector statistic, or form of animation should be collected. Probe lists are definedusing the Choose Results operation in the Project Editor. In addition, moreadvanced forms of probes can be defined in the Probe Editor, as described later inthis manual.

In addition to simply enabling a statistic or animation, a probe can specifycertain options that affect the manner in which data is collected. For statistics,commonly used options include restricted time-windows for data collection, on-the-fly data-reduction, and modified statistic names. For animations, probes allowspecification of window geometry, as well as particular options depending on thetype of animation being performed. Refer to the Simulation Design chapter of thismanual for more information on probes.

Ov.4.4 Analysis

The third phase of the simulation project involves examining the resultscollected during simulation. Typically, much of the data collected by simulationruns is placed in output scalar and output vector files, as explained earlier in thischapter. OPNET provides basic access to this data in the Project Editor and moreadvanced capabilities in the Analysis Tool, which is essentially a graphing andnumerical processing environment.

Key Concepts

OPNET simulations can generate animations that are viewed during the run, or “played back” afterwards. Several forms of predefined or “automatic” animations are provided (packet flows, node movement, state transitions, and statistics). In addition, detailed, customized ani-mations can be programmed if desired.

Key Concepts

Simulations can potentially generate vast amounts of output data. Therefore, by default, each source of output data is disabled. Model-ers must explicitly enable particular output data for collection. Results for collection are defined by probes, which also specify options that affect the manner in which results are collected or displayed.

37-Ov


od

eling

Overview

Numerical Data Analysis

Both the Project Editor and Analysis Tool allow output vector files to beselected and individual or multiple vectors to be loaded and displayed astraces.Traces are ordered sets of abscissa and ordinate pairs, called entries (tracesare similar in structure to vectors). In addition, scalar files can be selected andscalars from the same file can be plotted against each other to view the results ofmulti-simulation parametric studies. Once scalars are plotted in this manner, theirdata points have been grouped as ordered pairs, and the resulting data set is treatedas a trace. Two graphs, one generated from vector data, and the other from scalardata, are shown below:

Traces are held and displayed in analysis panels, and the user can arrange anynumber of panels from one or more simulations as part of an analysisconfiguration, which can be saved as a single file. A number of display options areavailable to help you customize the data’s presentation. These include multi-levelzoom, background colors, trace colors, plotting style, and labeling.

Scalar and Vector Data in Analysis Panels

38-Ov


Analysis panels provide a number of numerical processing operations that canbe applied to traces or vectors to generate new data for plotting. These aresummarized in the following table:

The Analysis Tool is linked to the Filter Editor, which supports the use ofmathematical filters to process vector or trace data. Mathematical filters aredefined as hierarchical block diagrams based on a predefined set of calculus,statistical, and arithmetic operators (a typical filter is shown in the diagram below).Predefined or user-defined filters can be invoked when specifying an analysis paneland applied to combinations of data from output vector files and existing analysispanels, to generate and display new traces.

Trace/Vector Processing Operations

Probability Mass Function (PMF)

Cumulative Distribution Function (CDF)

Histograms (occurrence and duration-based)

Confidence Interval Calculation

Mathematical Filters defined in Filter Editor

Key Concepts

The Analysis Tool supports display of data stored in output vector and output scalar files. Information is presented in the form of graphs, or traces. Each trace consists of a list of abscissa (“X”) and ordinate (“Y”) pairs. Traces are plotted in analysis panels. A set of analysis panels can be saved and recalled as an analysis configuration.

39-Ov


od

eling

Overview

Mathematical Filter Block Diagram

Key Concepts

The Analysis Tool supports a variety of methods for processing out-put data and computing new traces. Calculations such as histograms, PDF, CDF, and confidence intervals are supported directly by the tool. In addition, mathematical filters constructed in the Filter Editor can be invoked. Resulting data is displayed in new analysis panels.

40-Ov

OPNET Editors Modeling Concepts

Ov.5 OPNET Editors

OPNET presents its capabilities in the form of thirteen distinct environments,called editors or tools. Each editor allows you to perform some set of relatedOPNET functions within a window that is contained in the overall OPNETgraphical environment. The following table lists OPNET’s editors and identifieseach one’s purpose. The remainder of this section provides an overview of thecapabilities of each editor in summary form.

Editor Summary

Name Purpose Products

Project Editor Specify network topology and configure nodes and links. Choose results, run simulations, and view results.

All

Node Editor Create models of nodes by specifying internal structure and capabilities.

Modeler

Process Editor Develop models of decision-making processes representing protocols, algorithms, resource managers, operating systems, etc.

Modeler

Link Model Editor Create, edit, and view link models. Modeler

Packet Format Editor

Specify packet format, defining the order, data type, and size of fields contained within the packet.

Modeler

ICI Editor Create, edit, and view interface control information (ICI) formats.

Modeler

Antenna Pattern Editor

Create, edit, and view antenna patterns for transmitters and receivers.

Modeler(Radio version only)

Modulation Curve Editor

Create, edit, and view modulation curves for transmitters.

Modeler(Radio version only)

PDF Editor Create, edit, and view probability density functions (PDFs).

Modeler

Probe Editor Identify sources of statistics and animation that are to be collected during a simulation.

All

Simulation Tool Design and run sequences of simulations, each potentially configured with different inputs and/or outputs.

All

Analysis Tool Plot and process numerical data generated by simulations.

All

Filter Editor Define numerical processing that can be applied to data in analysis panels.

Modeler

41-Ov

Modeling Concepts OPNET EditorsM

od

eling

Overview

Ov.5.1 Project Editor Summary

The Project Editor is used to construct and edit the topology of acommunication network model. It also provides basic simulation and analysiscapabilities. The Network Domain in which the Project Editor works is the highestmodeling level in OPNET in the sense that it encompasses objects that are definedin the other modeling domains. The network model therefore specifies the entiresystem to be simulated. This section summarizes the objects used in the ProjectEditor and the operations that it provides.

Ov.5.1.1 Project Editor Objects

A network model contains only three fundamental types of objects:subnetworks, nodes, and links. There are several varieties of nodes and links, eachoffering different basic capabilities. In addition, each node or link is furtherspecialized by its “model”, which determines its behavior and functionality. Thefollowing table summarizes the types of objects used to build OPNET networkmodels:

Network Model Objects

Object Type Definition Default Representation

Fixed subnetwork

A “container” for additional network objects, including other subnetworks. Subnets can be nested to any depth to model complex hierarchical networks.

Mobilesubnetwork

Similar to a fixed subnetwork, except that it can physically displace itself as specified by a user-defined trajectory, or adaptively. In Radio products only.

Satellite subnetwork

Similar to a fixed subnetwork, except that it displaces itself automatically on an assigned orbit. In Radio products only.

Fixed node A network terminal or device, usually with the ability to communicate to other nodes. Can have a wide range of capabilities, as determined by its model. Cannot change geographical positions over time.

Mobile node Similar to a fixed node, except that it can physically displace itself as specified by a user-defined trajectory, or adaptively. In Radio products only.

Satellite node Similar to a fixed communication node, except that it displaces itself automatically on an assigned orbit. In Radio products only.

42-Ov


Ov.5.1.2 Project Editor Operations

The Project Editor provides operations to support the creation, editing, andverification of network models. Operations related to major capabilities aresummarized in the following table. For a complete listing of operations and an in-depth explanation of their use, refer to the Project Editor chapter of the EditorReference manual.

Simplex point-to-point link

Supports uni-directional flow of packets between two fixed nodes.

Duplex point-to-point link

Supports bi-directional flow of packets between two fixed nodes.

Bus link Provides broadcast connectivity for a set of fixed nodes. Nodes may transmit or packets onto the bus, receive packets from the bus, or both.

Bus tap Attaches fixed nodes to a bus link.

Network Model Objects (Cont.)


Project Editor Object Palette

43-Ov


od

eling

Overview

Project Editor Operations

Operationa

a. Operation names are not exact and may refer to several actual operations asa group.

Description

Create objects Individual subnetwork, node, and link objects can be created by “dragging and dropping” them from a palette (see figure above). Multiple palettes can be open and each can be configured to show only certain models, based on a keyword search.

Import topology and traffic Use information from sources such as HP OpenView Network Node Manager and NetMetrix to automatically build a network model and set conversation pair traffic and link loads.

Rapid configuration Supports creation of common configurations of nodes and links, including star, bus, ring, mesh, tree, and others. Parameters control models of nodes and links, graphical and geographical placement, number of objects, etc.

Edit object Right-click on an object to view or modify its attributes. Changes made to a single object can optionally be applied to an entire set of “selected” objects.

Find object Certain operations, including editing attributes, moving, copying, and deleting, can apply to a set of selected objects, instead of just one object at a time. Objects can be selected manually by clicking on them, automatically by searching on their names, or logically based their attribute values.

Verify links Verifies that links are connected in an appropriate manner based on node and link characteristics.

Navigate networks Allows viewing of different subnetwork contexts by moving up or down in the network hierarchy.

Select map Displays the selected map, cropped to the borders of the current subnetwork. Maps are provided with OPNET and are based on the CIA World Data Bank.

Define mobile node trajectory

Graphically specifies the path that a mobile node will follow over time. Includes specification of time, implicitly specifying velocity. (Radio versions only)

Collect results Specify the statistics to be collected and run simulations.

View results Specify which statistics to plot, graph characteristics, and calculations to be performed.

44-Ov


Ov.5.2 Node Editor Summary

The Node Editor is used to specify the structure of device models. Thesedevice models can be instantiated as node objects in the Network Domain (such ascomputers, packet switches, and bridges). In addition to the structure, the nodemodel developer defines the interface of a node model, which determines whataspects of the node model are visible to its user. This includes the attributes andstatistics of the node model. This section summarizes the objects used in the NodeEditor and the operations that it provides.

Ov.5.2.1 Node Editor Objects

Nodes are composed of several different types of objects called modules. At thenode level, modules are “black boxes” with attributes that can be configured tocontrol their behavior. Each one represents particular functions of the node’soperation and they can be active concurrently. Several types of connections supportflow of data between the modules within a node. The objects used to build nodemodels are briefly described in the following table.

Node Model Objects


Processor General purpose, programmable object whose behavior is specified by a process model.

Generator Simple packet source using probability distributions to control time intervals separating arrivals as well as size of packets.

Queue General-purpose and programmable like a processor, but also provides internal packet queuing facilities consisting of a bank of subqueues. Subqueues are ordered lists of packets.

Transmitter Allows packets to be sent outside of the node’s boundary via attached links. Three types of transmitters correspond to supported link types: point-to-point, bus, and (in Radio versions) radio.

Receiver Allows packets to be received from other nodes via attached links. Same types as transmitters above.

Packet Stream

Connects an output stream of a source module to the input stream of a destination module, allowing packets to be communicated and buffered between them.

45-Ov


od

eling

Overview

Ov.5.2.2 Node Editor Operations

The Node Editor provides operations to support the creation and editing ofnode models. Operations related to major capabilities are summarized in thefollowing table. For a complete listing of operations and an in-depth explanation oftheir usage, please refer to the Node Editor chapter of the Editor Referencemanual.

Statistic Wire

Connects an output statistic of a source module to the input statistic of a destination module, allowing numerical data to be communicated. Optional active notification of value changes via interrupts at the destination module.

Logical Association

Indicates a coupling between two modules. Currently supported for appropriate transmitter-receiver pairs only in order to specify that they be kept together when attaching the node to a link.

Node Editor Operations

Operationa Description

Create object Individual operations are provided to support the graphical creation of each type of object listed in the previous table.

Edit object Right-click on an object to view or modify its attributes. Changes made to a single object can optionally be applied to an entire set of “selected” objects.

Edit model attributes Attributes that characterize the node as a whole (as opposed to a particular object within it) can be associated with the node model. These attributes automatically appear in the node model’s interface.

Node Model Objects (Cont.)


46-Ov


Ov.5.3 Process Editor Summary

The Process Editor is used to specify the behavior of process models. Processmodels are instantiated as processes in the Node Domain and exist withinprocessor, queue, and esys modules. Processes can be independently executingthreads of control that perform general communications and data processingfunctions. They can represent functionality that would be implemented both inhardware and in software. In addition to the behavior of a process, the processmodel developer defines the model’s interfaces, which determines what aspects ofthe process model are visible to its user. This includes the attributes and statisticsof the process model. This section summarizes the objects used in the ProcessEditor and the operations that it provides.

Ov.5.3.1 Process Editor Objects

Process models use a finite state machine (FSM) paradigm to express behaviorthat depends on current state and new stimuli. FSMs are represented using a statetransition diagram (STD) notation. The states of the process and the transitionsbetween them are depicted as graphical objects. The objects used to build processmodels are briefly described in the following table.

Edit model attribute interfaces

The attribute interface of a node model defines the attributes that a user of the node model has access to. It also defines how they are presented, value constraints and choices, documentation, default values, and several other properties. This operation allows you to hide attributes that should not appear in the model’s interface.

Promote node statistics Statistics associated with modules can be “promoted” to the level of the node model, which means that they become associated with the node as a whole. This is useful to rename statistics and to hide underlying node model structure.


Node Editor Operations (Cont.)

Operationa Description

47-Ov


od

eling

Overview

Ov.5.3.2 Process Editor Operations

The Process Editor provides operations to support the creation and editing ofprocess models. Operations related to major capabilities are summarized in thefollowing table. For a complete listing of operations and an in-depth explanation oftheir usage, please refer to the Process Editor chapter of the Editor Referencemanual.

Process Model Objects

Object Type Definition Representation

State Represents a “mode” of the process which has been attained due to previous stimuli and corresponding decisions. States contain code expressing processing that is performed immediately after they are entered, or immediately before they are exited. A state can be forced or unforced. A process blocks immediately upon executing the “enter” code of an unforced state, at which point it waits for a new interrupt before continuing.

Transition Indicates a possible path that a process can take from a source state to a destination state. Each state can be the source and destination of any number of transitions. A transition has a condition statement which specifies the requirements for the process to follow the transition. An executive statement specifies actions that are to be taken when the process does follow the transition.

Model-level information “blocks”

Several “blocks” of text specify additional components of the process, including: declaration of state (persistent), and temporary (scratch) variables; user-defined functions that can be called by the process’ states and transitions; code to be executed upon process termination; and declaration of globally-scoped variables, data structures, etc.

48-Ov


Process Editor Operations

Operation a Description

Create object Individual operations are provided to support the graphical creation of states and transitions.

Edit object Right-click on an object to view or modify its attributes. Changes made to a single object can optionally be applied to an entire set of “selected” objects. For states, this operation provides access to enter and exit executive code blocks, as well as other attributes. For transitions, it includes access to condition and executive statements.

Set initial state Designates a particular state as the state where a process should begin execution when it is created.

Edit model attributes Process model attributes are parameters of the process, allowing some aspects of its behavior to be controlled externally. These attributes form part of the model’s interface and are scoped locally to the process’ instance.

Edit simulation attributes Simulation attributes are parameters needed by the process, but scoped to the overall system model. That is, the same attribute is shared by multiple processes and has one value throughout the entire simulation.

Edit model attribute interfaces

Process models contain no objects with promotable attributes. Only model attributes may be promoted. However this operation is still useful to control attributes that are intrinsic to the processor or queue that receives the process model. For example, the process model can dictate how many subqueues the queue should contain. This operation also hides unnecessary attributes of the modules.

Edit statistics Process models declare statistics that they are responsible for computing. These statistics can be scoped locally (contributed to only by this process) or globally (shared across the entire system model). Declaring statistics makes them available in the Node Domain for statistic wire connections and in the Probe Editor for statistic collection specification.

Declare external object files

The code in process models may rely on externally defined functions and data. Each process model declares those external object files that it requires to be included in the simulation program.

Compile process model Generates a C/C++ file that integrates all graphical and code elements of the process model. Then compiles the C/C++ file to prepare it for inclusion in a simulation program. Reports compilation errors if any.

49-Ov


od

eling

Overview

Ov.5.4 Packet Format Editor Summary

The Packet Format Editor provides a way to specify the collection of fieldscontained by a formatted packet. Each field has attributes specifying its name,type, size, and default value. Modeling each field’s size allows the overall sizeof the packet to be calculated. Fields may be one of several types: integer, double,structure, information, and packet.

• Structure fields allow inclusion of arbitrary complex data in packets.

• Information fields model bulk data in terms of its size, without concernfor actual content.

• Packet fields model packet encapsulation by layered protocols.

Ov.5.4.1 Packet Format Editor Objects

The Packet Format Editor uses only one object: the packet field. Each field’scolor can be set, but the size of the field on the screen depends on the field’sassigned length.

Ov.5.4.2 Packet Format Editor Operations

The Packet Format Editor provides operations to support the creation andediting of packet fields. Operations related to major capabilities are summarized inthe following table. For a complete listing of operations and an in-depthexplanation of their usage, refer to the Packet Editor chapter of the EditorReference manual.


Packet Format Objects

Object Type

Definition Representation

Packet field

The packet field object represents a single field in a packet format. You can specify such attributes as the field’s name, data type, size in bits, default value, and color.

50-Ov


Ov.5.5 Parameter Editors Summary

The Link Model Editor, ICI Editor, Antenna Pattern Editor, Modulation CurveEditor, and PDF Editor are used to specify a single type of model. Collectively,these types of models are referred to as parameter models because they are mainlyused as assignments for complex attributes (that is, parameters) of objects.

Most parameter models take the form of a functional relationship (in whichcase they are edited graphically) or a table of information (in which case they areedited in dialog boxes). This is depicted below using the PDF model type. Thissection provides a brief description of each type of parameter model. For more in-depth information on each of these models, refer to later sections of this manualand to the corresponding chapters of the Editor Reference manual.

Packet Format Editor Operations

Operation Description

Create new field Create graphical representations of new fields and place them in the workspace.

Edit field attributes View or modify a field’s attributes. Changes made to a single field can optionally be applied to an entire set of “selected” fields.

Edit packet attributes View or modify attributes pertaining to the entire packet.

Parameter Model Types

Link Model

Interface Control Information Format (ICI)

Antenna Pattern

Modulation Curve

Probability Density Function (PDF)

51-Ov


od

eling

Overview

Ov.5.5.1 Parameter Model Descriptions

The following table briefly discusses each of the parameter model types andtheir applications.

Parameter Models

Model Type Editing Method

Description

Link model dialog box An OPNET link model represents a class of link objects that can be instantiated in a network model. It defines attribute interfaces for point-to-point and bus links. Each link attribute can be set in advance to appropriate values, and if necessary hidden from view.

Interface control information (ICI)

dialog box ICI Formats: An ICI (Interface Control Information) is a data structure that is used to establish a formal interface between modules that communicate via some form of interrupt. In a general sense, an ICI is simply a structure of state information that can be associated with an interrupt at the interrupt source and then extracted at the interrupt destination. Typically, ICIs are used to pass indications and requests between protocol layers. ICIs consist of individual data components called attributes. Attributes may be of type integer, double, or structure.

Antenna pattern

graphical An OPNET antenna pattern is a three-dimensional table that maps direction angles phi and theta into antenna gain values. This table is used to characterize the effect of antenna patterns on radio link performance. Antenna patterns may be assigned to antenna modules in a node model. The pattern is accessed by the underlying link models in order to obtain accurate estimates of antenna gain for each radio transmission (Radio version only).

PDF Models

PDF of a continuous random variable,containing no impulses

PDF of a discrete random variable,implemented using impulses

52-Ov


Ov.5.6 Probe Editor Summary

The Probe Editor is used to define data collection requirements prior toexecuting a simulation. Because most simulation models would generate verylarge volumes of data if all possible outputs were recorded, OPNET relies on theuser to explicitly designate what is of interest. Each desired output is enabled bycreating an object called a probe and configuring it appropriately. Groups ofprobes are saved as probe lists so that they can be used collectively when runningsimulations. Several types of probes are used to collect different types ofsimulation results. This section describes each type of probe.

Ov.5.6.1 Probe Editor Objects

Each probe is represented as an individual object. The probe’s attributesprovide access to optional aspects of data collection, depending on the type of data.The following table briefly describes each type of probe. For more detailedinformation on probes, refer to the Simulation Design chapter of this manual.

Modulation curve

graphical An OPNET modulation is a mapping between effective signal-to-noise ratio (Eb/N0) values measured on a radio communications link, and the expected value of the bit error rate (BER) that would result. Modulations are assigned to radio transmitter and radio receiver modules. Their contents are typically accessed by the underlying link models (Radio version only).

Probability density function (PDF)

graphical A PDF is a mapping of real values of a random variable to their associated probability densities. PDFs are used to assign values to the various distribution attributes of generator modules. They are also commonly used to generate random variable values within process models (e.g., to implement random time-out intervals for retransmissions, or choose random destinations for packets).

Parameter Models (Cont.)

Model Type Editing Method

Description

53-Ov


od

eling

Overview

Ov.5.7 Simulation Tool Summary

OPNET simulations are ordinary programs that may be executed from thecommand line if desired. However, the Simulation Tool provides an often moreconvenient environment for configuring and running a simulation or group ofsimulations.

Probe Editor Objects

Probe Type Definition Representation

Node statistic Applies to a node object at the network level, or to a module within a node. In both cases, the source of the statistic is a module, but as mentioned earlier, module statistics may be promoted to the node level. Supports collection of both built-in and user-defined statistics.

Link statistic Applies to a link object at the network level. Links generate only built-in statistics (computed by OPNET).

Global statistic

Collects statistic values from multiple objects located anywhere in the network. The name of the statistic serves as a “rendezvous” point for the sources.

Simulation attribute

Records a scalar statistic for the simulation attribute. Simulation attributes are viewed as “input parameters” of the system. Their values, while known in advance, are often needed in post-simulation analysis so that they can be related to simulation outputs.

Automaticanimation

Provides “no-programming” animation for several aspects of system behavior, including: packet flows at network and node level; node movement at network level; and state transitions for a process.

Customanimation

Enables custom animation programmed within process models and link models.

Statisticanimation

Provides “no-programming” animation depicting statistics as they evolve during simulation. Statistics are presented as graphs in analysis panels, identical to the representation provided by the Analysis Tool. Axes rescale automatically to track changes.

54-Ov


The Simulation Tool allows any number of separate simulation runs of variousmodels to be specified as simulation objects represented by icons. The attributesfor each simulation object are specified in a dialog box.

The collection of simulation objects and associated configuration informationis referred to as a simulation sequence. The Simulation Tool allows an entiresequence to be run unattended.

For each simulation object, a number of standard attributes are presented in thedialog box. The primary attributes are summarized in the following table.

Simulation Object Attributes

Attribute Description

Network Name of network model to be simulated.

Probe file Name of probe list specifying output data to be collected.

Vector file Name of file that will store output vectors that simulation generates.

Simulation Object and Dialog Box

Key Concepts

A simulation sequence consists of any number of simulation objects. Each object specifies a network model that is to be simulated and val-ues for attributes. One or more simulation runs could result for each object, depending on possible combinations of attribute values. The sequence of simulation runs can be executed unattended.

55-Ov


od

eling

Overview

Ov.5.8 Analysis Tool Summary

OPNET simulations store statistical data in two types of files, called outputvector and output scalar files. Output vector files contain dynamic time-series datashowing how quantities change over time during a single simulation run. In anoutput scalar file, each variable is usually represented once per simulation. Thetool provided by OPNET for advanced processing of both types of simulationoutput is called the Analysis Tool.

In the Analysis Tool, users work with two types of objects, called analysispanels and graphs. Each analysis panel can contain one or more graphs, and agraph shows one or more statistics, or traces. All graphs in the same panel mustshare the same horizontal axis, but they may each have separate vertical axes.Traces are obtained from output vectors directly, or by plotting two scalar statisticsone against the other. They may also result from numerical processing or be copiesof other traces. The following tables enumerate the major attributes that can becontrolled for graphs and panels, respectively.

Scalar file Name of file that will store output scalars that simulation generates.

Seed Value of random seed for OPNET’s built-in random number generator. Vary this seed on different simulations to achieve desired statistical confidence in results.

Duration Maximum duration of the simulation (in simulated seconds).

Application-specific

Attributes promoted by the objects of the network model, or simulation attributes declared by process models.

Trace and Graph Attributes


draw style Choose from linear, discrete, bar, bar chart, sample-hold, and square-wave (see following figure).

line thickness Choose from dashed, thin, medium, and thick (see following figure).

trace color Choose from 64 colors for each trace in the graph.

confidence interval

For each trace in the graph, disable or enable confidence intervals and choose from five standard confidence levels.

vertical label Specify label that appears for each trace on the vertical axis.

Simulation Object Attributes (Cont.)


56-Ov


Draw Styles

57-Ov


od

eling

Overview

Configurations and Templates

Panel Attributes


colors Choose from 64 colors for the area surrounding the graphs.

axes bounds Specify the horizontal intervals that should be displayed; can also be achieved by graphical “zoom”.

geometry Specify where panel is located and its width and height; can also be performed graphically.

Draw Thickness

Key Concepts

In each simulation project, data of identical form (but extracted from different simulation runs) is typically displayed many times. The spec-ification of how to display and process the data can be stored as tem-plates. New output data can then be applied to the templates to automatically display it as desired.

58-Ov


In most simulation projects, simulations are run many times, first in the modeldebugging and validation phases, and then in the final “study” phase. It is often thecase that users wish to view the same sets of simulation output data after eachsimulation. They may also wish to perform the same types of post-processing onthis data for the separate output files.

To avoid re-specification of post-processing and graphical presentation ofoutput data, the Analysis Tool allows this information to be stored separately fromthe output data itself. This is supported via two features: analysis configurationsand templates. Analysis configurations simply allow the contents of the AnalysisTool to be saved and recalled at a later time. A configuration includes all the panelsand all of the information in them. A trace can be converted into a template in orderto strip of its actual trace data; however, all of its configuration information,including its name, and the operations that it resulted from, as well as presentationparameters, are retained. The Analysis Tool then allows new output files (vectorand scalar) to be applied to an Analysis Configuration containing templates. Theresult is that new traces are generated using “matching” data in the new outputfiles. Matches are based on the names of the vectors and scalars. This allows usersto automate the repetitive presentation of similar analysis data. The overall process

Application of Output Vector Data to a Template

OutputVector

File

59-Ov


od

eling

Overview

of creating and using configurations and templates is depicted in the followingdiagram.

RunFirst Simulation

GenerateOutput Files

ConstructAnalysis Config.

Convert toTemplates and

Save

Run New Simulation

GenerateOutput Files

Apply OutputFiles to

Templates

Creation and Use of Templates in Multi-Simulation Project

Results are automaticallydisplayed in the samemanner as in initial Analysis Configuration

60-Ov

OPNET as an Authoring Tool Modeling Concepts

Ov.6 OPNET as an Authoring Tool

As mentioned in the introduction to this chapter, traditional users of OPNETview their “deliverable” as the results of one or more simulation studies. However,other OPNET users may view their objective as the creation of a customizedmodeling environment. The environment consists of IT DecisionGuru or ModelerXE, which allow “end users” to create models at the network level, specify datacollection, run simulations, and perform analysis and animations.

The customization of the modeling environment seen by the end user is madepossible by OPNET. Using OPNET, sophisticated models of nodes and processescan be created, as has been discussed in this chapter. These models can then beprepared as a “library” for use by the end user who is less familiar with the detailedoperation of the system. To the end user, these models appear as “off-the-shelf”components; he is protected from the underlying complexity.

In addition, various aspects of the IT DecisionGuru and Modeler XE userinterface can be tailored to offer a truly customized environment to the end user.Like all OPNET products, Modeler offers extremely open interfaces, allowing easyintegration with complementary network planning and management tools. KeyOPNET features supporting this type of application are briefly described in thissection.

Key Features Supporting Development of Customized Modeling Environments

Feature Description

Model Security An author can protect models so that only authorized users can view or use them. Models are encrypted and unusable when shipped. They can then be “unlocked” with three security levels, supporting different requirements to protect information. Only the author (not OPNET) can provide keys to unlock models.

External Tool Support Authors can augment OPNET’s user interface by adding action buttons, menus, and menu items, or by defining actions that can be performed when users click on objects. The processing associated with each action is specified using a scripting language, which includes support for invoking external programs, as well as importing data from those programs.

Asynchronous Commands

OPNET can implement commands that are asynchronously received from external programs via interprocess communication. These actions include opening tools, loading models, graphical positioning, and modification of objects. This allows OPNET models to be updated in real-time as the state of other applications change.

61-Ov

Modeling Concepts OPNET as an Authoring ToolM

od

eling

Overview

Attribute Interfaces The key to “productizing” models is tailoring the interface that they present to the user. For OPNET node and process models, attributes and statistics constitute the majority of the visible interface. Attributes can be customized in derived models (without changing base models) by renaming them, pre-assigning their value and hiding them. Their properties can be controlled including allowing you to: restrict ranges; offer meaningful “symbolic” values; specify default values; and customize on-line documentation. Similar capabilities are provided for the statistics offered by a model.

Application Program Interface

OPNET offers an Application Program Interface (API) called EMA (External Model Access). EMA allows your programs to access (create and/or parse) OPNET models. This means that you can automatically generate OPNET models to reflect information that is stored elsewhere (e.g., in Network Management databases). You can also extract information from OPNET models and simulation output files in order to use them in external applications. Because EMA is a published interface, you can perform robust integration of OPNET and other tools that will survive new software releases.

Key Features Supporting Development of Customized Modeling Environments (Cont.)

Feature Description

62-Ov

OPNET as an Authoring Tool Modeling Concepts