01 Modeling Overview
Transcript of 01 Modeling Overview
-
8/6/2019 01 Modeling Overview
1/62
1-Ov
Modeling OverviewChapter 1
-
8/6/2019 01 Modeling Overview
2/62
2-Ov
Modeling Concepts
-
8/6/2019 01 Modeling Overview
3/62
3-Ov
Modeling Concepts
Introduction
Ov.1 Introduction
OPNET provides a comprehensive development environment supporting the
modeling of communication networks and distributed systems. Both behavior and
performance of modeled systems can be analyzed by performing discrete event
simulations. 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 OPNETs capabilities and structure. It is
intended to provide an introduction to the package and context for further reading
of 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 you
would a traditional text. To cover the information more quickly, remain at a
conceptual level by reviewing only tables, diagrams, bullet list headings, and
special key concepts
boxes, as shown below. If you require more detail on a
particular topic, read only the paragraphs in the corresponding section.
Overview Chapter: Content Summary
Section Topic
Key System Features Enumerates salient and distinctivecharacteristics of the OPNET software.
Typical Applications Presents some applications typically addressedwith OPNET and some of the features thatprovide direct support for those applications.
Architecture Describes the OPNET approach to each phase
of the modeling and simulation project. Presentsfundamental modeling constructs.
Tools Introduces the tools that constitute the OPNET
environment. Each tool supports a particularphase or sub-phase of the simulation andmodeling project.
Authoring Capabilities Discusses the use of OPNET as an authoringtool to prepare models for off-the-shelf use byend users in the IT DecisionGuru or Modeler XE
environments.
-
8/6/2019 01 Modeling Overview
4/62
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 technical
problems using simulation. They are usually interested in performance measures
and behavioral analysis of a proposed system. Often they are designers of
networks, network devices and protocols, or distributed applications. Authors, on
the other hand, do not use OPNET to conduct their own simulation studies, but to
prepare an environment for others to do so. OPNET Modeler is used to create
customized 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 of
OPNET that support its use as an authoring tool.
OPNET exists as both a core
product, and in a Radio version (using the
optional Radio module). Modeler, in conjunction with the Radio module, provides
specific features to support projects related to wireless networking. It includes,
among other radio-specific capabilities, the ability to model node mobility and the
effects of interference on radio link performance. Of course, many projects do not
require radio capability and these can be carried out with the core version.Throughout this manual, indications are provided when features specific to the
Radio 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, andkey conceptsboxes 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 amodeling environment to end users with products such as IT Guru.
-
8/6/2019 01 Modeling Overview
5/62
5-Ov
Modeling Concepts
Key System Features
Ov.2 Key System Features
OPNET is a vast software package with an extensive set of features designed to
support general network modeling and to provide specific support for particular
types of network simulation projects. This section provides only a brief
enumeration of some of the most important capabilities of OPNET. Subsequent
sections of this chapter provide more detailed information on these features, as
well as other aspects of OPNET.
Object orientation
. Systems specified in OPNET consist of objects,each with configurable sets of attributes. Objects belong to classeswhich 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
-
8/6/2019 01 Modeling Overview
6/62
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.
-
8/6/2019 01 Modeling Overview
7/62
7-Ov
Modeling Concepts
Typical Applications of OPNET
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 of
supporting 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 and
protocols
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 resources request-processing policies is required to provide precise estimates of its per-formance when subjected to peak demand (for example, a packetswitchs 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/6/2019 01 Modeling Overview
8/62
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.
-
8/6/2019 01 Modeling Overview
9/62
-
8/6/2019 01 Modeling Overview
10/62
-
8/6/2019 01 Modeling Overview
11/62
11-Ov
Modeling Concepts
OPNET Architecture
editor has its own specific set of objects and operations that are appropriate for the
modeling task on which it is focused. For instance, the Project Editor makes use of
node 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 the
following screen samples.
Ov.4.1.2 Modeling Domains
The Network, Node, and Process modeling environments are sometimes
referred to as the modeling domains
of OPNET, since they essentially span all the
hierarchical levels of a model. The remaining specification editors correspond tono particular modeling domain since they mainly support the three principal
editors. As mentioned earlier, the capabilities offered by the three modeling
domains mirror the types of structures found in an actual network system; the
issues addressed by each domain are summarized in the following table and then
briefly described in the remainder of this section.
Graphical Editors for Network, Node, and Process Models
Project Editor
Node Editor
Process Editor
-
8/6/2019 01 Modeling Overview
12/62
12-Ov
OPNET Architecture
Modeling Concepts
Network Domain
The Network Domains role is to define the topology of a communication
network. The communicating entities are called nodes and the specific capabilities
of each node are defined by designating their model
. Node models are developedusing the Node Editor, discussed later in this section. Within a single network
model, 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 from
the 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 that
a node instance is being referred to, rather than a node model.
A network model may make use of any number of node models. OPNET does
not place restrictions on the types of nodes that can be deployed in a
communication network; instead it adopts an open approach whereby modelers
can 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 or
node instances that a network model may contain (other than those imposed by
workstation memory limitations).
The Project Editor can provide a geographic context for network model
development. You can choose locations on world or country maps for the elements
of wide-area networks and can use dimensioned areas for local-area networks. In
addition 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 ofsubnetworks, nodes, links, and geographical
context.
Node Node Node internal architecture described in terms offunctional elements and data flow between them.
Process Process Behavior of processes (protocols, algorithms,applications), specified using finite state machinesand extended high-level language.
Key Concepts
A network model may contain any number of communicating entitiescalled 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.
-
8/6/2019 01 Modeling Overview
13/62
13-Ov
Modeling Concepts
OPNET Architecture
network model, this feature provides an intrinsic notion of distance, which allows
automatic calculation of communication delays between nodes.
The basic object used to build network models is the fixed
communication
node. In OPNET, this is the only type of node available. Fixed nodes can be
assigned arbitrary locations, but during a simulation their location may not change.
OPNET Radio versions allow networks to contain fixed nodes, but also add
capability for mobile
and satellite
nodes. Mobile nodes can be assigned predefinedtrajectories that specify their positions as a function of time throughout a
simulation run; similarly, satellite nodes are assigned orbits that prescribe their
motion. 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 to
perform their function in a network model. Several different types of
communication link architectures are provided to interconnect nodes that
communicate 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. The
Radio version adds the capability for fixed, satellite, and mobile nodes tocommunicate with each other via radio links
. While bus and point-to-point links
are modeled as explicit objects that you must create, radio links are dynamically
evaluated based on characteristics of the communicating nodes. As will be
discussed in later chapters, each type of link can be customized by editing
parameters or supplying new logic for the underlying link models. The following
figures show some typical network model diagrams involving each of the
supported link types.
Key Concepts
Network models consist of nodes and links which can be deployedwithin a geographical context. OPNET provides fixed nodes andpoint-to-point and bus links; the Radio version in addition provides
mobile and satellite nodes, and radio links.
-
8/6/2019 01 Modeling Overview
14/62
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
. A
subnetwork is a subset of a larger networks devices that forms a network in its
own right. OPNET provides fixed, mobile, and satellite subnetworks to enhance
network models. These subnetworks can then be connected by different types of
communication links, depending on the type of subnetwork. The larger network
can then be viewed as a network of its subnetworks. This abstraction can be carried
out at many levels. In other words, one can form networks of subnetworks, which
in 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 other
subnetworks.
Network Models with Radio, Bus, and Point-to-Point Links
Radio Links
Bus Link
Point-to-Point Links
Key Concepts
Fixed, mobile, and satellite subnetwork objects provide hierarchy inthe 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.
-
8/6/2019 01 Modeling Overview
15/62
15-Ov
Modeling Concepts OPNET Architecture
In OPNET network models, subnetworks can be nested to an unlimited depth
to construct complex topologies. The following set of diagrams, captured in the
Project Editor, illustrate the use of fixed subnetworks to model hierarchical
networks.
Node Domain
The Node Domain provides for the modeling of communication devices thatcan be deployed and interconnected at the network level. In OPNET terms, these
devices are called nodes, and in the real world they may correspond to various
types 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
-
8/6/2019 01 Modeling Overview
16/62
16-Ov
OPNET Architecture Modeling Concepts
Node models are developed in the Node Editor and are expressed in terms of
smaller building blocks called modules. Some modules offer capability that is
substantially predefined and can only be configured through a set of built-in
parameters. These include various transmitters and receivers allowing a node to be
attached to communication links in the network domain. Other modules, called
processors and queues, are highly programmable, their behavior being prescribed
by an assigned process model. Process models are developed using the Process
Editor.
A node model can consist of any number of modules of different types. Three
types of connections are provided to support interaction between modules. These
are called packet streams, statistic wires (also sometimes referred to as streams and
statwires, respectively), and logical associations. Packet streams allow formatted
messages called packets to be conveyed from one module to another. Statistic
wires convey simple numeric signals or control information between modules, and
are typically used when one module needs to monitor the performance or state of
another. As will be discussed later in this manual, both packet streams and statistic
wires 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 they
should 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 three
types 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 statisticwires) allow information to flow between modules.
-
8/6/2019 01 Modeling Overview
17/62
17-Ov
Modeling Concepts OPNET Architecture
The modeling paradigm selected for the Node Domain was designed to support
general modeling of high-level communication devices. It is particularly wellsuited to modeling arrangements of stacked or layered communication
protocols. In the Node Editor, a device that relies on a particular stack of protocols
can be modeled by creating a processor object for each layer of that stack and
defining packet streams between neighboring layers, as shown in the following
diagram for the familiar TCP/IP stack.
Process Domain
As mentioned earlier in the discussion of the Node Domain, queue and
processor modules are user-programmable elements that are key elements of
communication nodes. The tasks that these modules execute are calledprocesses.
A process can in many ways be thought of as similar to an executing software
program, since it includes a set of instructions and maintains state memory.
Processes in OPNET are based on process models that are defined in the Process
Editor. The relationship between process model and process is similar to the
relationship 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
-
8/6/2019 01 Modeling Overview
18/62
18-Ov
OPNET Architecture Modeling Concepts
a task (in fact, the term process is used in many operating systems as well). Just
as nodes created in the Project Editor are instances of node models defined with
the Node Editor, each process that executes in a queue, processor, or esys module
is an instance of a particular process model.
The process modeling paradigm of OPNET supports the concepts ofprocess
groups. A process group consists of multiple processes that execute within the
same processor or queue. When a simulation begins, each module has only one
process, termed the root process. This process can later create new processes
which 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 childof the
process that created it. Processes that are created during the simulation are referred
to as dynamic processes.
OPNET places no limits on the number of processes that may be created in a
particular processor or queue. Processes may be created and destroyed based on
dynamic conditions that are analyzed by the logic of the executing processes. This
paradigm provides a very natural framework for modeling many common systems.
In particular, multitasking operating systems where the root process represents the
operating system itself and the dynamically created processes correspond to new
tasks; and multi-context protocols where the root process represents a sessionmanager, for example, and each new session that is requested is modeled by
creating a new process of the appropriate type.
Only one process may be executing at any time. A process is considered to be
executing when it is progressing through new instructions that are part of its
process model. When a process begins execution it is said to be invoked. A process
that is currently executing can invoke another process in its process group to cause
it to begin executing. When this happens, the invoking process is temporarily
suspended 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 processesdynamically.These can in turn create additional processes themselves. This para-
digm is well-suited to modeling systems with dynamically instantiatedcontexts, like certain protocols, or multi-tasking operating systems.
-
8/6/2019 01 Modeling Overview
19/62
19-Ov
Modeling Concepts OPNET Architecture
has completed its processing for its current invocation. Once the invoked process
has blocked, the invoking process resumes execution where it had left off, in a
manner similar to the procedure-call mechanism in a programming language such
as 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 members
of a process group, or by a process for itself. Interrupts typically correspond to
events such as messages arriving, timers expiring, resources being released, or
state changes in other modules. Once a process has been invoked due to an
interrupt, it may invoke other processes in the group and these may in turn invoke
other processes, etc. An interrupts processing is completed when the first process
that was invoked blocks.
OPNETs Process Editor expresses process models in a language called
Proto-C, which is specifically designed to support development of protocols and
algorithms. Proto-C is based on a combination of state transition diagrams (STDs),
a library of high-level commands known as Kernel Procedures, and the general
facilities of the C or C++ programming language. A process models STD defines aset of primary modes or states that the process can enter and, for each state, the
conditions that would cause the process to move to another state. The condition
needed for a particular change in state to occur and the associated destination state
are called a transition. The following example, taken from the Process Editor,
shows the relationship between states and transitions in a process models STD.
Key Concepts
Processes respond to interrupts, which indicate that events of interesthave occurred such as the arrival of a message or the expiration of atimer. When a process is interrupted, it takes actions in response andthen blocks, awaiting a new interrupt. It may also invoke another pro-
cess; its execution is suspended until the invoked process blocks.
-
8/6/2019 01 Modeling Overview
20/62
20-Ov
OPNET Architecture Modeling Concepts
Proto-C models allow actions to be specified at various points in the finite state
machine. The actions can be extremely general in nature since they are expressed
as C or C++ statements. In addition, because Proto-C is focused on modeling
protocols and algorithms, it provides an extensive library of over 300 Kernel
Procedures (also known as KPs) that can be invoked to perform commonly needed
actions. Kernel Procedures are grouped into packages of related functions. The
following 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 dataitems and statements, and a library of Kernel Procedures that providecommonly needed functionality for modeling communications and
information processing systems.
-
8/6/2019 01 Modeling Overview
21/62
21-Ov
Modeling Concepts OPNET Architecture
The state transition diagram representation of Proto-C is well suited to the
specification of an interrupt-driven system because it methodically decomposes the
states of the system and the processing that should take place at each interrupt.
STDs developed in OPNETs Process Editor have a number of extensions beyond
the 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 withinterrupts
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 channels 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
-
8/6/2019 01 Modeling Overview
22/62
22-Ov
OPNET Architecture Modeling Concepts
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 state
information, 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 it
is instantiated as a process to customize aspects of its behavior. This technique
fosters 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 it
is 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 independent
from particular modeling domains, except when focusing on examples.
Objects
Objects represent entities that are part of the system of interest. In general, an
object 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 of
a node model. An object generally plays one or more of the following roles in a
model:
Typical Roles of an Object in a Model
Specify behavior
Create information
Store and manage information
-
8/6/2019 01 Modeling Overview
23/62
23-Ov
Modeling Concepts OPNET Architecture
Objects are created by various mechanisms in OPNET models. Many result
from explicit specification by the user via graphical or programmatic methods. So
for example, a link object may be created in a network model by physically
dragging it from the Project Editors object palette. Other objects are created
automatically by the system. For example, subqueue objects are automatically
created for a queue object. Similarly, when a node object is created, the objects
within 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 by
another process in order to perform a task. Dynamic objects are different in many
ways 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 complex
many-object system, each object must offer a well-defined interface. The interface
of an OPNET object consists primarily of the attributes that it makes available and
the procedures that it supports to access its attributes or to cause it to perform
actions. Some procedures supported by objects are provided automatically by
OPNET; others are programmed by users for specialized needs. Most procedures
vary according to the object type, and so few general comments can be made about
them 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 eachof 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.
-
8/6/2019 01 Modeling Overview
24/62
-
8/6/2019 01 Modeling Overview
25/62
25-Ov
Modeling Concepts OPNET Architecture
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 that
confers upon them some or all of their characteristics. The object is said to be an
instance of the model, since there is a many-to-one relationship between a model
and the objects that refer to it. The model defines an object class that all of the
related objects belong to.
Some of OPNETs objects are fundamental and have an implicit model that
cannot 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 constitute
their model; however, their fundamental behavior and structure are always similar
and cannot be changed. Thus they offer no model attribute.
However, several key objects in OPNET offer a model attribute that allows
their fundamental behavior and structure to be controlled externally. In fact,
altering an objects model can even cause it to acquire a completely new interface.
Indeed, these objects are fundamentally quite generic, and most of their
characteristics are obtained from the model that they refer to. The following table
enumerates the OPNET objects that support a model attribute.
In each of the model types listed in the table above, a models interface is
specified. One of the characteristics transferred to an object from its model is its set
of attributes. The model dictates which new attributes will be acquired by the
object, and what their names and values will be. Similarly, it can specify values for
attributes 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 objects interface. Each attributehas a name, a value, and properties. Properties specify the rules gov-
erning the attributes use, including its data type, allowable values,suggested values, and documentation.
-
8/6/2019 01 Modeling Overview
26/62
26-Ov
OPNET Architecture Modeling Concepts
hidden from the user. Thus, the model can completely control the attribute
interfaces of the object.
Model Attributes and Attribute Promotion
With both models and attributes introduced as concepts, the notion of a model
attribute can be defined. In addition to describing objects, attributes can be
associated with models in order to represent a parameter of the model. This was
already briefly mentioned in the case of process models in a previous section. The
importance of providing a parameter for a model lies in increasing the generality ofthe model. By varying the values of the models parameter, a user can alter its
behavior in some well-defined manner, without having to actually modify the
model itself. This approach can be contrasted with hardwiring the value of the
attribute into the model itself, which exposes no control to the models user.
Obtaining the behavior corresponding to a new value of the attribute would then
require 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 parallel
manner over time, which is clearly undesirable. The model attributes mechanism
therefore supports increased reusability of models.
In concrete terms, model attributes are specified as part of a model, but they
appear on objects. They are acquired by an object at the moment when that objects
model is specified. The models attributes are simply added to those that are
intrinsic 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 objects interfaces.
Some objects have implicit models that cannot be changed; otherscan be assigned models via their model attribute, allowing extensivecustomization.
Key Concepts
Models can be parameterized using model attributes. This mecha-nism provides users of the model with a means of control over someaspect of model behavior without requiring changes to the model
internals. Model attributes generalize a model, making it more reus-able for diverse applications.
-
8/6/2019 01 Modeling Overview
27/62
27-Ov
Modeling Concepts OPNET Architecture
A mechanism similar to that provided for model attributes allows objectattributes to be passed upward in the modeling hierarchy. This mechanism is called
attribute promotion. Promotion causes an objects attribute to no longer have a
value; 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 attribute
into the node models attribute interface, meaning that it will then be inherited by
any node object in the network level that references the node model. In the case of
node objects in the network level, a promoted attribute is added to the attributes of
the subnet that it encompasses it. Attributes that promote all the way through the
model hierarchy become attributes of the overall system model, or equivalently
attributes of the simulation. These can be assigned values at simulation run time
via 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 function
of 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. Theybecome part of the objects attribute list.
-
8/6/2019 01 Modeling Overview
28/62
28-Ov
OPNET Architecture Modeling Concepts
Derived Models
In many cases, model developers have a need to customize a models interface
without actually changing the models internal structure or behavior. Node and link
model attribute interfaces can be modified using a mechanism called model
derivation. Model derivation operates upon an existing model and generates a
derived model that has attribute interfaces that differ in various ways.The resulting
model is called a derived model, and the model used as the basis for its derivation
is referred to as itsparent model. A model which is derived from no other model (a
very common case) is called abase 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 specialized
interfaces to be developed without having to duplicate or recreate core
functionality in a model. Since a model and a derived model are fundamentally the
same in terms of structure and behavior, it makes sense that specification of this
information should be shared. This provides economy of specification and enforces
long-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 representing
the structure of a network, including the elements that appear at different
hierarchical levels. Communication of data takes place at all levels of thishierarchy and most of the supported objects play some role in implementing this
communication: processes can be considered to be both the sources and sinks of
data and control information; the node domain is the context in which processes
communicate information with each other and with physical layer transmitters and
receivers; and the network domain allows nodes to exchange information with
each other via various types of communication links.
Key Concepts
Instead of having a value that is specified in advance, objectattributes can be promoted. A promoted attribute moves up to thenext 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 modelcan be created from it. The derived model shares the same structuraland behavioral specification as its parent model, but parts of the par-
ents interface may be altered. Successive derivations may be per-formed. A model that is not derived from any other is a base model.
-
8/6/2019 01 Modeling Overview
29/62
29-Ov
Modeling Concepts OPNET Architecture
There are many forms of communication that are supported by the OPNET
modeling environment. However, there is one fundamental structure, calledpacket,
that provides the most commonly used mechanism for information exchange.
Packets are objects that contain formatted information that can change
dynamically. They can be stored by and transferred between objects in each of the
modeling domains. In the Node Domain, packets typically travel over streams; in
the Network Domain, they are typically transferred over links. Packets are
essentially 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 of
predefined values that are used by the OPNET system for tracing and accounting
purposes; and the third area contains transmission data attributes that are used to
support customizable models for communication links.
Because OPNET simulations model each individual packet in a network
model, and the packet fields contain actual data values, fully accurate models of
protocol interactions can be implemented. Processes can modify and obtain values
of fields and base their actions upon their contents. Packet fields may contain data
of one of several supported data types. Integer and double (floating-point) fields
can 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 betransferred between objects in the Node and Network domains. Each
packet contains 3 areas: user-defined fields, pre-defined fields foraccounting, 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, butin 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
-
8/6/2019 01 Modeling Overview
30/62
30-Ov
OPNET Architecture Modeling Concepts
fundamental mechanism supporting layered protocol modeling, since higher-layer
protocols request that lower layer protocols transport packets to remote peers.
Structure fields provide general support for carrying user-defined C/C++ language
data structures within packets; this is sometimes useful for sophisticated
applications where complex information, such as routing tables, are transferred
across networks. The information field type is provided for convenient support of
bulk or filler data in a packet, which can be important to accurately model
packet size; information fields contain no values.
Packets fall into two broad categories:formattedand unformatted. A formatted
packet is one whose fields are defined according to a template called a packet
format. Packet formats are created in the Packet Format Editor and specify a list of
field names, data types, sizes (that is, field lengths specified in bits), and default
values. When formatted packets are created, they instantly acquire the fields
defined in their format and, when applicable, default values are installed in those
fields. Unformatted packets have no fields when they are created; fields are added
one 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 the
recommended 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, includingnumerical values, encapsulated packets, and general data structures.Field size is specified, allowing accurate modeling of processing
delays, transmission delays, buffer occupancy, etc.
-
8/6/2019 01 Modeling Overview
31/62
31-Ov
Modeling Concepts OPNET Architecture
Packets can be used to transfer data at all levels of an OPNET network model
via several communication mechanisms. Processors, queues, and other modules
forward packets within nodes via packet streams, which were introduced earlier in
this chapter. Packet streams may introduce delay and also queue packets until a
destination module is ready to accept them. At the network level, packets are sent
between nodes over communication links. Communication links use customizable
underlying models to model delays and errors in packet transmission. A third
packet transfer mechanism, called packet delivery, supports transfer of packets
between modules, regardless of their location in a network, without requiring any
physical connection to exist between them.
OPNET packets are intended to represent information-carrying structures of
various types that appear in communications and systems architectures, including
packets, messages, frames, cells, datagrams, and transactions. The term packethas
been chosen as a general term and should not be interpreted as restricting the types
of applications for which OPNET can be used.
For some communication networks, information transfer does not necessarily
occur in packet form. In particular, some devices communicate with streams of
data where information flow is continuous. In such cases, OPNET packets can be
treated as messages that carry only model-relevant information between the
communicating entities. This may include information such as the amount of data
transferred, or signaling data that is needed by the application models at either end
of the stream. Depending on what the goal of the modeling effort is, the data
streams can be adequately represented by modeling the important phases of their
operation (setup, tear-down, and control information transfer) with packets, or
even with other OPNET communication mechanisms that will be discussed later in
this manual.
Key Concepts
Packets may be made to conform to apacket format. Packet formatsare defined in the Packet Format Editor and specify a template for apackets 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 torepresent other forms of communication as well. In stream-orientedcommunications, for example, packets may be used to represent key
signalling information, allowing the connection to be modeled interms of its duration, bandwidth requirements, etc.
-
8/6/2019 01 Modeling Overview
32/62
32-Ov
OPNET Architecture Modeling Concepts
Ov.4.3 Data Collection and Simulation
The objective of most modeling efforts is to obtain measures of a systems
performance or to make observations concerning a systems behavior. OPNET
supports these activities by creating an executable model of the system. Provided
that the model is sufficiently representative of the actual system, OPNET allows
realistic estimates of performance and behavior to be obtained by executing
simulations. 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 data
directly supported by OPNET. These are output vectors, output scalars, and
animation. Each is briefly described in this section.
Output Vectors
The types of data that can be collected have several different forms. The most
common result extracted from a simulation is called an output vector, which is
simply a collection of pairs of real values, called entries. An output vector, often
called simply a vector, contains an arbitrarily-sized list of entries collected during a
single simulation run.The first value in the entries can be thought of as the
independent variable and the second as the dependent variable. In OPNET these
are referred to as the abscissa and the ordinate, respectively. In the majority of
cases, the independent variable of a vector is simulation time, which increases
monotonically as a simulations execution progresses. In other words, most vectors
represent the value of some quantity of interest as it varies over time. Under certain
conditions, it is interesting to create vectors that have abscissa variables other than
time; this topic is discussed later in this manual. The following diagram depicts a
typical data set contained in a vector. Note that it is possible for a vector to store
multiple 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 providedautomatically by OPNET simulations. These are: output vectors, out-
put scalars, and animations.
-
8/6/2019 01 Modeling Overview
33/62
33-Ov
Modeling Concepts OPNET Architecture
Output Scalars
In contrast to vectors, scalar statistics are individual values. Typically, scalar
statistics are averages, probabilities, or peak values derived from a collection of
measurements. Examples include the average or peak size of a queue, the mean
end-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 simply
properties or statistics of the set of value pairs obtained in an output vector. In
other words, given all of the values in an output vector, a number of interesting
scalars can be computed and recorded by a simulation. Note that it is not usually
necessary to record all the values in a vector in order to compute a scalar that
reflects the entire data set. For example, the mean ordinate value of a vector can be
obtained by maintaining a running sum of the vectors values as they become
available 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/O
than 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 simulations
to form a graph or curve that indicates how a system variable varies as a function
of other system parameters. Both the dependent and the independent system
variables, used to generate such a graph, are recorded as scalars. For example, a
typical 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 ofa list of entries, each of which is a time-value pair.
time Q Size
0.0 0.0
0.3301 1.0
1.0 2.0
1.0 1.0
1.3301 0.0
5.0 1.0
5.0 2.0
5.0 3.010.0 2.0
10.6602 3.0
...
998.0 54.0
Output Vector Contents
ordinate (Q size) valuesabscissa (time) values
-
8/6/2019 01 Modeling Overview
34/62
34-Ov
OPNET Architecture Modeling Concepts
deliver, as the amount of data increases. Here the Offered Load scalar is an
independent variable that is varied as an input to each simulation. Throughput is
then measured over the course of the simulation, and its final value (since it is
already an average) is recorded as another scalar.
OPNET simulations record scalar statistics in a special type of file called an
output scalar file. Unlike output vector files, these files contain the results
generated by multiple simulations. Within an output scalar file, the scalars from
each simulation run are kept in groups so that they can be related to each other. In
other words, when Throughput is graphed against Offered Load, each point inthe graph is formed by taking an abscissa and an ordinate value from the respective
scalar statistics within the same simulation run. Each point of the graph usually
corresponds to a new simulation run. The following diagram shows a typical plot
generated from scalar values.
Application-Specific Statistics
Both scalar and vector statistics can be computed and recorded automatically
for a set of predefined statistics. Predefined statistics in OPNET are related to
values that can be measured at specific objects within the model. This includes
statistics 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 eachscalar 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
-
8/6/2019 01 Modeling Overview
35/62
35-Ov
Modeling Concepts OPNET Architecture
addition, it is common for models to compute application-specific statistics during
a simulation and record them in scalar and/or vector output files. These statistics
may be computed in a completely general manner, taking into account events that
have occurred, the current state of the system, the content of packets, etc.
Custom statistics may be declared by process models, in which case OPNET
adds them to the set of built-in statistics of queues and processors that make use of
those process models. The custom statistics can have a scope which is local orglobal. A locally-scoped statistic is maintained separately for each processor or
queue that declares it. This is appropriate for recording information that relates
only to events at a particular location, such as the utilization of a CPU on a
particular server. In contrast, a global statistic is shared and contributed to by many
entities in the model, it is appropriate for recording information that relates to the
performance or behavior of the system as a whole. A typical example of a global
statistic 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 a
visual analysis of a network models behavior. An animation is a dynamic
graphical representation of selected events that occurred during a simulation. The
events may be depicted within a diagram from the Network, Node, or Process
domain, or simply in an empty window.
An OPNET simulation can be configured to generate certain types of
predefined animations automatically. In addition, the Animation Kernel Procedure
package provides the ability to program sophisticated animations that represent
simulation events in a customized manner. The kernel procedures of the Animation
package include general drawing as well as OPNET-specific graphics to provide a
flexible animation capability.
Both automatic and custom animations can be viewed interactively during asimulation run or afterwards in a playback mode. Refer to the documentation for
the Animation package Kernel Procedures in the Simulation Kernel manuals and
the op_vuanimprogram description in the Utility Programs manual for more
information 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 overallsystem) application-specific statistics.
-
8/6/2019 01 Modeling Overview
36/62
36-Ov
OPNET Architecture Modeling Concepts
Ov.4.3.2 Selecting Data for Collection
Because OPNET-developed models typically contain a very large number of
potential statistics and animations of interest, collection mechanisms are not active
by default when a simulation is executed. Instead, OPNET provides a mechanism
to explicitly activate particular statistics or animations so that they will be recorded
in appropriate output files. This is accomplished by specifying a list ofprobes
when running a simulation. Each probe indicates that a particular scalar statistic,
vector statistic, or form of animation should be collected. Probe lists are defined
using the Choose Results operation in the Project Editor. In addition, moreadvanced forms of probes can be defined in the Probe Editor, as described later in
this manual.
In addition to simply enabling a statistic or animation, a probe can specify
certain 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 allow
specification of window geometry, as well as particular options depending on the
type of animation being performed. Refer to the Simulation Design chapter of this
manual 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 simulation
runs is placed in output scalar and output vector files, as explained earlier in this
chapter. OPNET provides basic access to this data in the Project Editor and more
advanced capabilities in the Analysis Tool, which is essentially a graphing and
numerical processing environment.
Key Concepts
OPNET simulations can generate animations that are viewed duringthe run, or played back afterwards. Several forms of predefined orautomatic 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. Resultsfor collection are defined byprobes, which also specify options thataffect the manner in which results are collected or displayed.
http://01_31_simde.pdf/http://01_31_simde.pdf/ -
8/6/2019 01 Modeling Overview
37/62
37-Ov
Modeling Concepts OPNET Architecture
Numerical Data Analysis
Both the Project Editor and Analysis Tool allow output vector files to be
selected and individual or multiple vectors to be loaded and displayed as
traces.Traces are ordered sets of abscissa and ordinate pairs, called entries (traces
are similar in structure to vectors). In addition, scalar files can be selected and
scalars from the same file can be plotted against each other to view the results of
multi-simulation parametric studies. Once scalars are plotted in this manner, theirdata points have been grouped as ordered pairs, and the resulting data set is treated
as a trace. Two graphs, one generated from vector data, and the other from scalar
data, are shown below:
Traces are held and displayed in analysis panels, and the user can arrange any
number of panels from one or more simulations as part of an analysis
configuration, which can be saved as a single file. A number of display options are
available to help you customize the datas presentation. These include multi-level
zoom, background colors, trace colors, plotting style, and labeling.
Scalar and Vector Data in Analysis Panels
-
8/6/2019 01 Modeling Overview
38/62
38-Ov
OPNET Architecture Modeling Concepts
Analysis panels provide a number of numerical processing operations that can
be applied to traces or vectors to generate new data for plotting. These are
summarized in the following table:
The Analysis Tool is linked to the Filter Editor, which supports the use of
mathematical filters to process vector or trace data. Mathematical filters are
defined 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 panel
and 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 andoutput 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 analysispanels can be saved and recalled as an analysis configuration.
-
8/6/2019 01 Modeling Overview
39/62
39-Ov
Modeling Concepts OPNET Architecture
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 beinvoked. Resulting data is displayed in new analysis panels.
-
8/6/2019 01 Modeling Overview
40/62
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 related
OPNET functions within a window that is contained in the overall OPNET
graphical environment. The following table lists OPNETs editors and identifies
each ones purpose. The remainder of this section provides an overview of the
capabilities of each editor in summary form.
Editor Summary
Name Purpose Products
Project Editor Specify network topology and configure nodesand links. Choose results, run simulations, andview results.
All
Node Editor Create models of nodes by specifying internalstructure and capabilities.
Modeler
Process Editor Develop models of decision-making processesrepresenting protocols, algorithms, resourcemanagers, 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 thepacket.
Modeler
ICI Editor Create, edit, and view interface control
information (ICI) formats.
Modeler
Antenna PatternEditor
Create, edit, and view antenna patterns fortransmitters 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 densityfunctions (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, eachpotentially configured with different inputs and/or
outputs.
All
Analysis Tool Plot and process numerical data generated bysimulations.
All
Filter Editor Define numerical processing that can be appliedto data in analysis panels.
Modeler
-
8/6/2019 01 Modeling Overview
41/62
41-Ov
Modeling Concepts OPNET Editors
Ov.5.1 Project Editor Summary
The Project Editor is used to construct and edit the topology of a
communication network model. It also provides basic simulation and analysis
capabilities. The Network Domain in which the Project Editor works is the highest
modeling level in OPNET in the sense that it encompasses objects that are defined
in the other modeling domains. The network model therefore specifies the entire
system 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, each
offering different basic capabilities. In addition, each node or link is further
specialized by its model, which determines its behavior and functionality. The
following table summarizes the types of objects used to build OPNET network
models:
Network Model Objects
Object Type Definition Default Representation
Fixedsubnetwork
A container for additional network objects,including other subnetworks. Subnets can benested to any depth to model complex
hierarchical networks.
Mobilesubnetwork
Similar to a fixed subnetwork, except that it canphysically 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 assignedorbit. In Radio products only.
Fixed node A network terminal or device, usually with the
ability to communicate to other nodes. Can havea wide range of capabilities, as determined by its
model. Cannot change geographical positionsover 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, exceptthat it displaces itself automatically on an
assigned orbit. In Radio products only.
-
8/6/2019 01 Modeling Overview
42/62
42-Ov
OPNET Editors Modeling Concepts
Ov.5.1.2 Project Editor Operations
The Project Editor provides operations to support the creation, editing, and
verification of network models. Operations related to major capabilities are
summarized 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 Editor
Reference manual.
Simplexpoint-to-point
link
Supports uni-directional flow of packets betweentwo fixed nodes.
Duplex point-to-point link
Supports bi-directional flow of packets betweentwo fixed nodes.
Bus link Provides broadcast connectivity for a set of fixednodes. 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.)
Object Type Definition Default Representation
Project Editor Object Palette
http://../06_Editor_Ref/06_16_Pt.pdfhttp://../06_Editor_Ref/06_16_Pt.pdf -
8/6/2019 01 Modeling Overview
43/62
43-Ov
Modeling Concepts OPNET Editors
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 becreated 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 OpenViewNetwork Node Manager and NetMetrix to automatically
build a network model and set conversation pair trafficand link loads.
Rapid configuration Supports creation of common configurations of nodes
and links, including star, bus, ring, mesh, tree, andothers. Parameters control models of nodes and links,
graphical and geographical placement, number ofobjects, etc.
Edit object Right-click on an object to view or modify its attributes.Changes made to a single object can optionally beapplied to an entire set of selected objects.
Find object Certain operations, including editing attributes, moving,
copying, and deleting, can apply to a set of selectedobjects, instead of just one object at a time. Objectscan be selected manually by clicking on them,
automatically by searching on their names, or logicallybased 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 bymoving up or down in the network hierarchy.
Select map Displays the selected map, cropped to the borders of
the current subnetwork. Maps are provided withOPNET 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.
-
8/6/2019 01 Modeling Overview
44/62
44-Ov
OPNET Editors Modeling Concepts
Ov.5.2 Node Editor Summary
The Node Editor is used to specify the structure of device models. These
device models can be instantiated as node objects in the Network Domain (such as
computers, packet switches, and bridges). In addition to the structure, the node
model developer defines the interface of a node model, which determines what
aspects of the node model are visible to its user. This includes the attributes and
statistics 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 the
node level, modules are black boxes with attributes that can be configured to
control their behavior. Each one represents particular functions of the nodes
operation and they can be active concurrently. Several types ofconnections support
flow of data between the modules within a node. The objects used to build node
models are briefly described in the following table.
Node Model Objects
Object Type Definition Default
Representation
Processor General purpose, programmable object whosebehavior is specified by a process model.
Generator Simple packet source using probabilitydistributions to control time intervals separating
arrivals as well as size of packets.
Queue General-purpose and programmable like a
processor, but also provides internal packetqueuing facilities consisting of a bank ofsubqueues. Subqueues are ordered lists of
packets.
Transmitter Allows packets to be sent outside of the nodesboundary 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 nodesvia attached links. Same types as transmitters
above.
PacketStream
Connects an output stream of a source moduleto the input stream of a destination module,allowing packets to be communicated and
buffered between them.
-
8/6/2019 01 Modeling Overview
45/62
45-Ov
Modeling Concepts OPNET Editors
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 the
following table. For a complete listing of operations and an in-depth explanation of
their usage, please refer to the Node Editorchapter of the Editor Reference
manual.
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 viainterrupts 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 theybe kept together when attaching the node to a
link.
Node Editor Operations
Operationa Description
Create object Individual operations are provided to support thegraphical 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 (asopposed to a particular object within it) can be
associated with the node model. These attributesautomatically appear in the node models interface.
Node Model Objects (Cont.)
Object Type Definition DefaultRepresentation
http://../06_Editor_Ref/06_19_Nd.pdfhttp://../06_Editor_Ref/06_19_Nd.pdf -
8/6/2019 01 Modeling Overview
46/62
46-Ov
OPNET Editors Modeling Concepts
Ov.5.3 Process Editor Summary
The Process Editor is used to specify the behavior of process models. Process
models are instantiated as processes in the Node Domain and exist within
processor, queue, and esys modules. Processes can be independently executing
threads of control that perform general communications and data processing
functions. They can represent functionality that would be implemented both in
hardware and in software. In addition to the behavior of a process, the process
model developer defines the models interfaces, which determines what aspects of
the process model are visible to its user. This includes the attributes and statistics
of 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 behavior
that depends on current state and new stimuli. FSMs are represented using a state
transition diagram (STD) notation. The states of the process and the transitions
between them are depicted as graphical objects. The objects used to build process
models are briefly described in the following table.
Edit model attributeinterfaces
The attribute interface of a node model defines theattributes that a user of the node model has access to.
It also defines how they are presented, valueconstraints and choices, documentation, default
values, and several other properties. This operationallows you to hideattributes that should not appear inthe models interface.
Promote node statistics Statistics associated with modules can be promotedto the level of the node model, which means that theybecome associated with the node as a whole. This is
useful to rename statistics and to hide underlying nodemodel structure.
a. Operation names are not exact and may refer to several actual operations as
a group.
Node Editor Operations (Cont.)
Operationa Description
-
8/6/2019 01 Modeling Overview
47/62
47-Ov
Modeling Concepts OPNET Editors
Ov.5.3.2 Process Editor Operations
The Process Editor provides operations to support the creation and editing of
process models. Operations related to major capabilities are summarized in the
following table. For a complete listing of operations and an in-depth explanation of
their usage, please refer to the Process Editor chapter of the Editor Reference
manual.
Process Model Objects
Object Type Definition Representation
State Represents a mode of the process which hasbeen attained due to previous stimuli and
corresponding decisions. States contain code
expressing processing that is performedimmediately after they are entered, orimmediately before they are exited. A state can
be forced or unforced. A process blocksimmediately upon executing the enter code ofan unforced state, at which point it waits for a
new interrupt before continuing.
Transition Indicates a possible path that a process cantake from a source state to a destination state.
Each state can be the source and destination ofany number of transitions. A transition has a
condition statement which specifies the
requirements for the process to follow thetransition. An executive statement specifiesactions that are to be taken when the processdoes follow the transition.
Model-levelinformationblocks
Several blocks of text specify additionalcomponents of the process, including:declaration of state (persistent), and temporary
(scratch) variables; user-defined functions thatcan be called by the process states and
transitions; code to be executed upon processtermination; and declaration of globally-scoped
variables, data structures, etc.
http://../06_Editor_Ref/06_22_Pr.pdfhttp://../06_Editor_Ref/06_22_Pr.pdf -
8/6/2019 01 Modeling Overview
48/62
48-Ov
OPNET Editors Modeling Concepts
Process Editor Operations
Operation a Description
Create object Individual operations are provided to support thegraphical 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 beapplied to an entire set of selected objects. For
states, this operation provides access to enter and exitexecutive code blocks, as well as other attributes. For
transitions, it includes access to condition andexecutive 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 theprocess, allowing some aspects of its behavior to be
controlled externally. These attributes form part of the
models interface and are scoped locally to theprocess instance.
Edit simulation attributes Simulation attributes are parameters needed by theprocess, but scoped to the overall system model. That
is, the same attribute is shared by multiple processesand 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 controlattributes that are intrinsic to the processor or queue
that receives the process model. For example, the
process model can dictate how many subqueues thequeue should contain. This operation also hidesunnecessary attributes of the modules.
Edit statistics Process models declare statistics that they are
responsible for computing. These statistics can bescoped locally (contributed to only by this process) or
globally (shared across the entire system model).Declaring statistics makes them available in the NodeDomain for statistic wire connections and in the Probe