01 10 Ov

1—Modeling Overview
1 Modeling Overview
Modeler 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 Modeler environment incorporates tools for all phases of
a study, including model design, simulation, data collection, and data analysis.
This section provides an overview of Modeler’s capabilities and structure. It is

intended to provide an introduction to the package and context for further
reading of the documentation. The section is divided into the following topics:
• Multiple User Communities on page MC-1-2—Describes the types Modeler

users.
• Key System Features on page MC-1-2—Describes salient and distinctive

characteristics of Modeler software.
• Typical Applications of Modeler on page MC-1-4—Presents some

applications typically addressed with Modeler and some of the features that
provide direct support for those applications.
• Modeler Architecture on page MC-1-5—Describes the Modeler approach to

each phase of the modeling and simulation project. Presents fundamental
modeling constructs.
• Modeler Editors on page MC-1-35—Introduces the tools that constitute the

Modeler environment. Each tool supports a particular phase or sub-phase of
the simulation and modeling project.
• Modeler as an Authoring Tool on page MC-1-48—Describes how to use

Modeler as an “authoring tool” to prepare models for “off-the-shelf” use by
end users in other OPNET analysis software products.
This section 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
concept paragraphs, as shown below. If you require more detail on a particular
topic, read only the paragraphs in the corresponding section.
Key Concept—To quickly cover the material in this section, simply skip over
paragraph text, reviewing only tables, diagrams, bullet list headings, and key
concept sections such as this one.
Modeler/Release 14.0 MC-1-1

Multiple User Communities

Modeler users can be divided into two broad categories:
• System modelers—are the traditional users of Modeler, 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—do not use Modeler to conduct their own simulation studies, but to
prepare an environment for others to do so. Modeler is used to create
customized models that are correct for a particular type of end user.
See Modeler as an Authoring Tool on page MC-1-48 for more information on

specific features of Modeler that support its use as an authoring tool.
Modeler, in conjunction with the Wireless functionality, 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 basic version.
Key Concept—Modeler is used to construct models for two different purposes:

to study system behavior and performance; and to deliver a modeling
environment to “end users” with other OPNET analysis software products.
Key System Features

Modeler 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 Modeler. Subsequent
parts of this section contain detailed information about these and other features
of Modeler.
• Object orientation—Systems specified in Modeler consist of objects, each

with configurable sets of attributes. Objects belong to classes, which provide
them with their characteristics in terms of behavior and capability. Definition
of new classes are supported to address as wide a scope of systems as
possible. Classes can also be derived from other classes, or “specialized” to
provide more specific support for particular applications.
• Specialized in communication networks and information systems—Modeler

provides many constructs relating to communications and information
processing, providing high leverage for modeling of networks and distributed
systems.
• Hierarchical models—OPNET models are hierarchical, naturally paralleling

the structure of actual communication networks.
MC-1-2 Modeler/Release 14.0

• Graphical specification—Wherever possible, models are entered via

graphical editors. These editors provide an intuitive mapping from the
modeled system to the OPNET model specification.
• Flexibility to develop detailed custom models—Modeler provides a flexible,

high-level programming language with extensive support for
communications and distributed systems. This environment allows realistic
modeling of all communications protocols, algorithms, and transmission
technologies.
• Automatic generation of simulations—Model specifications are compiled

automatically into executable, efficient, discrete-event simulations
implemented in the C programming language. Advanced simulation
construction and configuration techniques minimize compilation
requirements.
• Application-specific statistics—Modeler provides built-in performance

statistics that can be collected automatically during simulations. Modelers
can also augment this set with new application-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
interpreted. Modeler includes sophisticated operations for graphical
presentation and processing of simulation output.
• Interactive analysis—All Modeler simulations automatically incorporate

support for analysis via a sophisticated interactive debugger.
• Animation—Simulation runs can be configured to automatically generate

animations of the modeled system at various levels of detail and can include
animation of statistics as they change over time. Extensive support for
developing customized animations is also provided.
• Cosimulation—You can connect Modeler with one or more other simulators

so that you can see how the models in those simulators interact with OPNET
models. The external models can represent anything from network hardware
to end-user behavior patterns.
• Application program interface (API)—As an alternative to graphical

specification, models and data files may be specified via a programmatic
interface. This is useful for automatic generation of models or to allow
Modeler to be tightly integrated with other tools.

Typical Applications of Modeler

As a result of the capabilities described in the previous sections, Modeler 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—detailed library

models provide major local-area and wide-area network protocols.
Configurable application models are also provided by the library, or new ones
can be created.
• Internetwork planning—hierarchical topology definitions allow arbitrarily

deep nesting of subnetworks and nodes and large networks are efficiently
modeled; scalable, stochastic, and/or deterministic models can be used to
generate network traffic.
• Research and development in communications architectures and

protocols—Modeler allows specification of fully general logic and provides
extensive support for communications-related applications. Finite state
machines provide a natural representation for protocols.
• Distributed sensor and control networks, on-board systems—Modeler allows

development of sophisticated, adaptive, application-level models, as well as
underlying communications protocols and links. Customized performance
metrics can be computed and recorded, scripted and/or stochastic inputs can
be used to drive the simulation model, and processes can dynamically
monitor the state of objects in the 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
performance when subjected to peak demand (for example, a packet
switch’s processing delay can depend on the specific contents and type of
each packet as well as its order of arrival). Queuing capabilities of Proto-C
provide easy-to-use commands for modeling sophisticated queuing and
service policies; library models are provided for many standard resource
types.
• Mobile packet radio networks—specific support for mobile nodes, including

predefined or adaptive trajectories; predefined and fully customizable radio
link models; geographical context provided by Modeler network specification
environment. (requires Wireless functionality)

• Satellite networks—specific support for satellite nodes, including automatic

placement on specified orbits, a utility program for orbit generation, and an
orbit visualization and orbital-configuration animation program. (requires the
Wireless functionality)
• C3I and tactical networks—support for diverse link technologies; modeling of

adaptive protocols and algorithms in Proto-C; notification of network
component outages and recoveries; scripted and/or stochastic modeling of
threats; with the Wireless functionality, radio link models support
determination of friendly interference and jamming.
Modeler Architecture
Modeler provides a comprehensive development environment for modeling and
performance-evaluation of communication networks and distributed systems.
The package consists of a number of tools, each one focusing on particular
aspects of the modeling task. These tools fall into three major categories that
correspond to the three phases of modeling and simulation projects:
• Model Specification on page MC-1-6 and Modeling Communications with

Packets on page MC-1-24
• Data Collection and Simulation on page MC-1-27
• Analysis on page MC-1-32
These phases are necessarily performed in sequence. They generally form a

cycle, with a return to Specification following Analysis. Specification is actually
divided into two parts: initial specification and re-specification, with only the
latter belonging to the cycle, as illustrated in the following figure.
Figure 1-1 Simulation Project Cycle
Re-Specification
Initial Specification Data Collection and

Simulation
Analysis

Model Specification
Model specification is the task of developing a representation of the system that
is to be studied. Modeler supports the concept of model reuse so that most
models are based on lower level models developed beforehand and stored in
model libraries. Ultimately, however all models are based on the basic concepts
and primitive building blocks supplied by the Modeler environment.
For more information, see:
• Specification Editors on page MC-1-6
• Modeling Domains on page MC-1-8
• Models, Objects, and Attributes on page MC-1-19
Specification Editors
Modeler supports model specification with a number of tools, called editors,
which capture the characteristics of a modeled system’s behavior. Because it is
based on a suite of editors that address different aspects of a model, Modeler
is able to offer specific capabilities to address the diverse issues encountered in
networks and distributed systems. To present the model developer with an
intuitive interface, these editors handle the required modeling information in a
manner that is parallel to the structure of real network systems. Therefore, the
model-specification editors are organized hierarchically. Models built in the
Project Editor rely on elements specified in the Node Editor; in turn, when
working in the Node Editor, you use models defined in the Process Editor and
External System Editor. The remaining editors are used to define various data
models, typically tables of values, that are later referenced by process- or
node-level models. This organization is reflected in the following list.
• Project Editor—Develop network models. Network models are made up of

subnets and node models. This editor also includes basic simulation and
analysis capabilities.
• Node Editor—Develop node models. Node models are objects in a network

model. Node models are made up of modules with process models. Modules
may also include parameter models.
• Process Editor—Develop process models. Process models control module

behavior and may reference parameter models.
• External System Editor—Develop external system definitions. External

system definitions are necessary for cosimulation.
• Link Model Editor—Create, edit, and view link models.
• Packet Format Editor—Develop packet formats models. Packet formats

dictate the structure and order of information stored in a packet.

• ICI Editor—Create, edit, and view interface control information (ICI) formats.
ICIs are used to communicate control information between processes.
• PDF Editor—Create, edit, and view probability density functions (PDFs).

PDFs can be used to control certain events, such as the frequency of packet
generation in a source module.
Key Concept—OPNET models are structured hierarchically, in a manner that

parallels real network systems. Specialized editors address issues at different
levels of the hierarchy. This provides an intuitive modeling environment and also
permits re-use of lower level models.
Modeler makes use of graphical specification of models wherever appropriate.

Therefore, the model-specification editors all present a graphical interface in
which the user manipulates objects representing the model components and
structure. Each editor has its own specific set of objects and operations that are
correct for the modeling task on which it is focused. For instance, the Project
Editor uses 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.
Figure 1-2 Graphical Editors for Network, Node, and Process Models
Node Editor
Project Editor
Process Editor

Modeling Domains
The Network, Node, Process, and External System modeling environments are
sometimes referred to as the modeling domains of Modeler because they span
all the hierarchical levels of a model. The remaining specification editors
correspond to no particular modeling domain because they mainly support the
three principal editors. As mentioned earlier, the capabilities offered by the
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.
Table 1-1 Modeling Domains

Domain Editor Modeling Focus
Network Domain Project Network topology described in terms of subnetworks,

nodes, links, and geographical context.
Node Domain Node Node internal architecture described in terms of

functional elements and data flow between them.
Process Domain Process Behavior of processes (protocols, algorithms,

applications), specified using finite state machines
and extended high-level language.
External System External System Interfaces to models provided by other simulators

Domain running concurrently with a discrete event simulation
(a cosimulation).
End of Table 1-1
Network Domain The Network Domain’s 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 developed using the Node Editor, described later in this section.
Within one 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
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. Modeler 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 for
network models. There are no limits on the number of node models or node
instances that a network model can contain (other than those imposed by
workstation memory limitations).

Key Concept—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 customized node
models, implementing any functionality they require.
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 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 Modeler, this is the only type of node available. Fixed nodes can be assigned
arbitrary locations, but during a simulation their location may not change. The
optional Wireless functionality adds capability for mobile and satellite nodes, as
described in Chapter 2 Modeling Wireless Networks on page WM-2-1. Mobile
nodes can be assigned predefined trajectories 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 Wireless functionality,
simulations can involve all three types of nodes.
Most nodes require the ability to communicate with other nodes to do their
function in a network model. Several different types of communication link
architectures are provided to interconnect nodes that communicate with each
other. Modeler 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 Wireless
functionality adds the capability for fixed, satellite, and mobile nodes to
communicate 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
described in later sections, each type of link can be customized by editing
parameters or supplying new logic for the underlying link models. The following
figure shows some typical network model diagrams involving each of the
supported link types.
Key Concept—Network models consist of nodes and links that can be deployed
within a geographical context. Modeler comes with fixed nodes and
point-to-point and bus links; the Wireless functionality adds mobile and satellite
nodes and radio links.

Figure 1-3 Network Models with Point-to-Point, Bus, and Radio Links
Point-to-Point Links
Bus Links
Radio Links
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 network’s devices that forms a network in its
own right. Modeler 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.
Key Concept—Fixed, mobile, and satellite subnetwork objects provide

hierarchy in the network model and are used to break down complexity into
multiple levels. Subnets can contain various combinations of nodes, links, and
other subnets, and can be nested to any depth.

In 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.
Figure 1-4 A Hierarchical Network with Two Levels of Subnetworking
Node Domain The Node Domain provides for the modeling of communication
devices that can be deployed and interconnected at the network level. In
Modeler 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.

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, queues, and external systems, 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 described 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 are allowed only between transmitters and
receivers to indicate that they should be used as a pair when attaching the node
to a link in the Network Domain. Figure 1-5 shows a typical node model that
includes the three types of connections.
Key Concept—Node models consist of modules and connections. Modules are

information 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.
Figure 1-5 Node Model Employing Packet Streams, Statistic Wires, and Logical
Associations
packet stream
statistic wire
logical association

The modeling paradigm selected for the Node Domain was designed to support
general modeling of high-level communication devices. It is particularly well
suited 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.
Figure 1-6 Possible Representation of TCP/IP Protocol Stack
Process Domain As indicated in the description 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 called
processes. Because it has a set of instructions and maintains state memory, a
process is similar to an executing software program. Processes in Modeler 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 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.
Key Concept—Process models define behavior for programmable modules. A

process is an instance of a process model and operates within one module.
The process modeling paradigm of Modeler supports the concepts of process

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, it is termed the new process’ parent; the new process is called the
child of the process that created it. Processes that are created during the
simulation are referred to as dynamic processes.

Modeler 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 session manager, for example, and each new session that
is requested is modeled by creating a new process of the correct type.
Key Concept—Initially, each programmable module contains only one process;

however, processes can create additional child processes dynamically. These
can in turn create additional processes themselves. This paradigm is well-suited
to modeling systems with dynamically instantiated contexts, like certain
protocols, or multi-tasking operating systems.
Only one process can 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 has completed its processing for its current invocation. After 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 Modeler are designed to respond to interrupts and/or invocations.

Interrupts, which are described in 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. After 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 interrupt’s processing is
completed when the first process that was invoked blocks.
Key Concept—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 process; its
execution is suspended until the invoked process blocks.

The 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 model’s
STD defines a set 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 model’s STD.
Figure 1-7 State Transition Diagram in the Process Editor
Proto-C models allow actions to be specified at various points in the finite state
machine. The actions can be general in nature because they are expressed as
C or C++ statements. Because Proto-C is focused on modeling protocols and
algorithms, it also provides an extensive library of over 300 Kernel Procedures
(also known as KPs) that can be invoked to do commonly needed actions.
Kernel Procedures are grouped into packages of related functions. The
following table shows some of the capabilities provided by the Kernel Procedure
libraries.

Key Concept—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.
Table 1-2 Major Simulation Kernel Procedure Packages

Package Applications
Anim Support for custom animation development
Dist Probability distribution and random number generation
Esys Read from and write to external system interfaces
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
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

Table 1-2 Major Simulation Kernel Procedure Packages (Continued)

Package Applications
Td Setting and getting of transmission data for custom link models
Topo Query of model topology (for example, automatic discovery and configuration)
Vvec Create and manipulate value vectors
End of Table 1-2
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 the Process Editor have a number of extensions
beyond the capabilities offered by traditional state-transition diagram
approaches:
• State Variables—Processes maintain private state variables with named

variables of arbitrary data types, including Modeler-specific, general C/C++
language, and user-defined types. This capability allows a process to flexibly
maintain counters, routing tables, statistics related to its performance, or
messages requiring retransmission. Arbitrary combinations of state variable
values may be used in all decisions and actions implemented by a process.
• State Executives—Each state of a process can specify arbitrarily complex

actions associated with the process entering or leaving that state. These
actions, called state executives, are expressed with the full flexibility of the
C/C++ language. Typical actions include modifying state information,
creating or receiving messages, updating the contents of and sending
messages, updating statistics, and setting or responding to timers.
• Transition Conditions— Transition condition statements, which determine

whether a transition should be traversed, may be expressed as general
C/C++ language booleans that make reference to properties of a new
interrupt as well as to combinations of state variables.
• Transition Executives—Transitions may specify general actions, called

executives, which are implemented each time that they are traversed.
A process model can define parameters, called attributes, that are used after 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.

External System Domain The esys module mentioned in the description of the
Node Domain encompasses the mechanism for communicating with other
simulators and allowing them to interact with a discrete event simulation. This
interaction, called a cosimulation, means that the two simulators can exchange
data while running synchronously. Part of the role typically played by a module
inside a node is instead played by a simulator external to Modeler. For esys
modules, the process model controls Modeler’s interaction with the external
system. Esys modules have all the capabilities of both processors and queues.
Figure 1-8 Relationship of Hierarchical Levels in Models
Network
Node
Module
External
Process System
Definition
To the simulation, an external system is a black box. While Modeler can feed
data to the external system and receive data from it, the other simulator has
complete control of the data after it arrives.
An esys module consists of two primary parts:
• External system—The external system definition specifies (via a simulation

description file) how the cosimulation should be built and defines the esys
interfaces that will exchange data with the external code. They can accept
data from external code, send data to external code, or do both. An esys
interface normally contains one value at any given time, and both Modeler
and the external code have access to that value.
An esys interface can contain only one value at a time, unless it is specifically
given more elements, in which case it is called a vector interface. A vector
interface can hold as many values as it has elements. The elements within a
vector interface are distinguished by index numbers, much as individual
positions in an array are referenced by index number.
• Process model—The process model of the esys module places values onto
esys interfaces and reads values placed onto the esys interfaces by the
external simulator. It serves as the interface between the external code and
the rest of the model.
Key Concept—When Modeler runs a cosimulation, its interface with the external
code is an external system definition (ESD), represented in the node model by
an esys module. ESDs use esys interfaces to send and receive data when
communicating with external code.

Models, Objects, and Attributes

The preceding sections describe major model types and objects; this section
presents the Modeler object model in more detail. Wherever possible,
information is presented independently of 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
• Process, modify, or relay information
• Respond to events
• Contain other objects
Objects are created by various mechanisms in 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 Editor’s 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 to do a task. Dynamic objects are different in many ways than
the statically created objects; in particular they offer more specialized interfaces,
allowing them to be manipulated in a more efficient manner. Most of the material
in this section does not apply to dynamic objects.
Key Concept—Objects are the building blocks of models and appear in each of
the modeling domains. Some objects are created explicitly by the user; others
are implicitly created by Modeler. During a simulation, certain types of objects
can be created dynamically.
Attributes To achieve predictable and tractable behavior when building a

complex many-object system, each object must have a well-defined interface.
The interface of an 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 do actions. Some procedures supported by objects are provided

automatically by Modeler; others are programmed by users for specialized
needs. Most procedures vary according to object type, so few general
comments can be made about them except to say that it is crucial that they have
a well-known interface and that they shield users from underlying details of
object implementation.
Table 1-3 Attribute Components

Name
Value
Properties
End of Table 1-3
Attributes are data items used to configure an object and represent the control
that the object’s designer has made available to the user. Each attribute has a
name that allows it to be referenced uniquely within an object. Each attribute
also provides a storage area for the information that is “assigned to it”. This
information is called the attribute’s value. Finally, an attribute has a set of
properties that specify the rules related to its use, as well as several additional
functions. Major attribute properties are enumerated in the following table.
Table 1-4 Attribute Properties

Property Description
Data Type Class of data storage. Modeler supports a 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 Lists 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 (how it behaves)
End of Table 1-4
As described in the table, Modeler supports an attribute data type called

compound. Compound attributes support nested complex data storage within
an object in a very simple way: the value is itself another object. This object can
have any number of attributes of its own, including additional compound
attributes. Certain built-in objects have compound attributes. For example,

queues incorporate subqueues using this mechanism; similarly, transmitters

and receivers represent the channels they contain as compound attributes.
User-defined models may also create compound attributes for
application-specific purposes. A typical use of a compound attribute in a
protocol model is to represent a routing or circuit table.
Key Concept—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 governing the
attribute’s use, including its data type, allowable values, suggested values, and
documentation.
Models Many 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 an instance of the model because there
is a many-to-one relationship between a model and the objects that refer to it.
The model defines an object class to which all related objects belong.
Some objects are fundamental and have an implicit model that cannot be
changed by the user. For example, state objects in process models are simple
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. Therefore they have no “model”
attribute.
However, several key objects offer a “model” attribute that allows their
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 their
characteristics are obtained from the model to which they refer. The following
table lists the objects that support a “model” attribute.
Table 1-5 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
External System Node Process, ESD
End of Table 1-5

In each of the model types listed in Table 1-5, a model 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 hidden from the user. Therefore, the model can completely control the
attribute interfaces of the object.
Key Concept—Each object has a 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.
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 to
represent a parameter of the model. This was mentioned previously with regard
to process models. The importance of providing a parameter for a model lies in
increasing the generality of the model. By varying the values of the model’s
parameter, a user can alter model behavior without modifying the model. This
approach is in contrast to hardwiring the value of the attribute into the model,
which gives the user no control over the model. In a “hardwired” model, the user
would need to duplicate the model and change the attribute value to achieve a
change in behavior. This means that multiple, specialized versions of the model
would need to be maintained, which is clearly undesirable. The model attributes
mechanism allows the same models to be “reused” without increasing the
model inventory.
Key Concept—Models can be parameterized using model attributes. This

mechanism 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 reusable for diverse applications.

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 that the
object’s model is specified. The model’s attributes are added to other attributes
that are intrinsic to the object, as shown in the following figure.
Figure 1-9 Inheritance of Model Attributes by an Object
Object “O”
object refers to model “M”
Model = “M”
A
Object Attributes B
C
D
X
Y
Z
Model “M”
object acquires attributes A
A,B, C, and D Model Attributes B
C
D
Other Model Data
Key Concept—Model attributes are inherited by objects that refer to the model.
They become part of the object’s attribute list.
A mechanism similar to that provided for model attributes allows object

attributes to be passed upward in the modeling hierarchy. This mechanism is
called attribute promotion. Promotion causes an object’s attribute to no longer
have a value; instead, the attribute appears at the next level in the model. For
example, for a module attribute in a node model, promotion moves the attribute
into the node model’s attribute interface; this means that the attribute will be
inherited by any node object in the network level that references the node
model. In node objects in the network level, a promoted attribute is added to the
attributes of the subnet that 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 through a variety of mechanisms. It is then possible to iterate
through a range of parameter values in different simulations to study the system
as a function of the parameters.
Key Concept—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 performed there. Attributes
that are promoted through the top of the hierarchy (top subnetwork) become
attributes of the simulation.

Derived Models In many cases, model developers need to customize a model’s

interface without changing the model’s internal structure or behavior. Node and
link model attribute interfaces can be modified using a mechanism called model
derivation. Model derivation operates on an existing model and generates a new
model that has different attribute interfaces. The resulting model is called a
derived model, and the model from which it was created is called the parent
model. A model that is derived from no other model (a very common case) is
called a base model. All derived models have a unique base model 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. Because a parent model and its derived model are
fundamentally the same in structure and behavior, specification of this
information is shared. This provides economy of specification and enforces
long-term consistency of these models as they are modified over time.
Key Concept—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 parent’s interface
may be altered. Successive derivations may be performed. A model that is not
derived from any other is a base model.
Modeling Communications with Packets

The previous sections describe the support Modeler 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 this
hierarchy 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.
There are many forms of communication that are supported by the Modeler
modeling 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
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 a list of user-defined values called packet fields; the second
area consists of a set of predefined values that are used by the simulation
system for tracing and accounting purposes; and the third area contains
transmission data attributes that are used to support customizable models for
communication links.

Key Concept—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.
Figure 1-10 Three Main Storage Areas of Packet Contents
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
Predefined Fields TD Attrs.
Name Contents Index Contents

creat_mod 19 0 8
creat_time 4.005 1 100.0
owner 19 2 11.505
format transp_x 3 1.07e-07
id 116 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.)
Because discrete event 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 fundamental mechanism supporting layered protocol
modeling, because 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.
Table 1-6 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
End of Table 1-6
Key Concept—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.
Packets fall into the following three broad categories:
• Formatted packets have fields 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,
particularly when several different types of packets are used in a network.
• Value vector packets do not contain user-defined fields. Instead, they contain
a sequence of binary numbers representing data passed between
simulators. Value vector packets are used primarily with cosimulations.
Key Concept—Packets can 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 supported field.

Packets can be used to transfer data at all levels of a network model via several
communication mechanisms. Processors, queues, and other modules forward
packets within nodes via packet streams, which were introduced earlier in this
section. 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.
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
packet has been chosen as a general term and should not be interpreted as
restricting the types of applications for which Modeler 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, 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 communication mechanisms that will be
described later in this manual.
Key Concept—Although the generic term “packet” is used, Modeler can use
packets 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.
Data Collection and Simulation

The objective of most modeling efforts is to obtain measures of a system’s
performance or to make observations concerning a system’s behavior. Modeler
supports these activities by creating an executable model of the system.
Provided that the model is sufficiently representative of the actual system,
Modeler allows realistic estimates of performance and behavior to be obtained
by executing simulations. Several mechanisms are provided to collect the
desired data from one or more simulations of a system.

For more information, see
• Simulation Output Data Types
• Selecting Data for Collection
Simulation Output Data Types

Discrete event simulations are capable of producing many types of output. Of
course, because of the general programmability of process models and link
models, developers can 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 discrete event simulations:
• Output Vectors
• Output Scalars
• Animations
Key Concept—Modelers can take advantage of the programmability of OPNET

models to create proprietary forms of simulation output, if desired. However, in
most cases, users work with the output that can be provided automatically by
discrete event simulations. These are: output vectors, output scalars, and
animations.
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 one simulation run. The first value in the entries can be
thought of as the independent variable and the second as the dependent
variable. 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 simulation’s 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 described later in this manual.
The following figure 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 Concept—Output vectors represent time-series simulation data. They

consist of a list of entries, each of which is a time-value pair.

Figure 1-11 Output Vector Contents
time Q Size
0.0 0.0
abscissa (time) values 0.3301 1.0 ordinate (Q size) values
1.0 2.0
1.0 1.0
1.3301 0.0
5.0 1.0
5.0 2.0
5.0 3.0
10.0 2.0
10.6602 3.0
...
998.0 54.0
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 mean call 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 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 vector’s values as they become available and dividing by a running count
of the number of values recorded. Therefore, 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 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 measured over the course of the
simulation and its final value (because it is already an average) is recorded as
another scalar.
Key Concept—Scalar statistics are individual values that represent a metric of

interest. They are often derived from vector statistics, as an average, peak
value, final value, or other statistic. Typically, one value for each scalar statistic
is recorded during a simulation; when many simulations are run, their scalar
outputs are combined to form a graph.
When Throughput is graphed against Offered Load, each point in the 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 figure shows a typical plot
generated from scalar values.
Figure 1-12 Plot of Scalar Statistic Values
Application-Specific Statistics Both scalar and vector statistics can be

computed and recorded automatically for a set of predefined statistics.
Predefined statistics 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 addition, it is common for
models to compute application-specific statistics during a simulation and record
them in vector output files. These statistics can 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 Modeler

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 or global. 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.
Key Concept—Modeler supports predefined statistics that are typically of

interest in simulation studies. However, many projects require customized
statistics, computed in a manner specific to the application. Modeler supports
both local (related to an object) and global (related to overall system)
application-specific statistics.
Animations In addition to numerical forms of output, discrete event simulations

can provide a visual analysis of a network model’s 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.
A discrete event simulation can be configured to generate certain types of

predefined animations automatically. The Animation Kernel Procedure package
also 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 Modeler-specific
graphics to provide a flexible animation capability.
Both automatic and custom animations can be viewed interactively during a

simulation run or afterwards in a “playback” mode. See the documentation for
the Animation package Kernel Procedures in Discrete Event Simulation API
Reference Manual and the animation program description in Animation Viewers
Reference Manual for more information about developing and viewing
animations.
Key Concept—Discrete event simulations can generate animations that you can
view during the run or afterwards. Several forms of predefined or automatic
animations are provided (packet flows, node movement, state transitions, and
statistics). You can also program your own detailed, customized animations.
Selecting Data for Collection

Because standard 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, Modeler 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 of

probes 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. You can also
define advanced forms of probes in the Probe Editor, which is described later in
this manual.
In addition to enabling a statistic or animation, a probe can specify options that

affect how 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 you to define window
geometry and several type-specific animation options. For more information
about probes, see Chapter 11 Simulation Design on page MC-11-1.
Key Concept—Simulations can potentially generate vast amounts of output

data. Therefore, by default, each source of output data is disabled. Modelers
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.
Analysis
The third phase of the simulation project involves examining the results
collected during simulation. Typically, much of the data collected by simulation
runs is placed in output vector files. Modeler provides a graphing and numerical
processing environment in the Results Browser of the Project Editor.
Numerical Data Analysis The Project Editor allows 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, scalars from the same file can be
plotted against each other to view the results of multi-simulation parametric

studies. After scalars are plotted this way, their data 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 in
Figure 1-13.
Figure 1-13 Scalar and Vector Data in Analysis Panels
Traces are held and displayed in analysis panels. A number of display options
are available to help you customize the data’s presentation. These include
multi-level zoom, background colors, trace colors, plotting style, and labeling.
Key Concept—The Results Browser supports display of data stored in output

vector 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.

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:
Table 1-7 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
End of Table 1-7
The Results Browser 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 analysis panels, to generate and display new traces.
Figure 1-14 Mathematical Filter Block Diagram
Key Concept—The Results Browser supports a variety of methods for

processing output data and computing new traces. Calculations such as
histograms, PDF, CDF, and confidence intervals are supported directly by the
tool. You can also build mathematical filters in the Filter Editor. Resulting data
is displayed in new analysis panels.

Modeler Editors
Modeler presents its capabilities in the form of distinct environments, called
editors. Each editor allows you to do some set of related functions within a
window that is contained in the overall Modeler graphical environment. The
following table lists Modeler’s editors and identifies the purpose of each.
Table 1-8 Editor Summary

Name Purpose
Project Editor Specify network topology and configure nodes and links.
Choose results, run simulations, and view results.
Node Editor Create models of nodes by specifying internal structure

and capabilities.
Process Editor Develop models of decision-making processes

representing protocols, algorithms, resource managers,
operating systems, and so on.
Link Editor Create, edit, and view link models.
Path Editor Create and edit path objects.
Demand Editor Create and edit demand objects.
Probe Editor Identify sources of statistics and animation that are to be

collected during a simulation.
Simulation Sequence Editor Design and run sequences of simulations, each

potentially configured with different inputs and/or
outputs.
External System Definition Editor Build interfaces between Modeler and external code for
use during cosimulation.
Filter Editor Define numerical processing that can be applied to data

in analysis panels.
Generic Data File Editor Create and edit .gdf text files.
ICI Editor Create, edit, and view interface control information (ICI)
formats.
Icon Database Editor Create or modify icons; edit icon databases.
Packet Format Editor Specify packet format, defining the order, data type, and
size of fields contained within the packet.

Table 1-8 Editor Summary (Continued)

Name Purpose
PDF Editor Create, edit, and view probability density functions

(PDFs).
Profile Library Editor Create and edit traffic profiles.
Network Whiteboard Editor Create and maintain drawings of your network.
End of Table 1-8
Project Editor
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 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 Project Editor and
the operations that it provides.
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 functions and behavior. The
following table lists the types of objects used to build network models.
Table 1-9 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.
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.
Simplex point-to-point link Supports a unidirectional flow of packets between two fixed
nodes.

Table 1-9 Network Model Objects (Continued)

Duplex point-to-point link Supports a bidirectional flow of packets between two fixed nodes.
Bus link Provides broadcast connectivity for a set of fixed nodes. Nodes
may transmit packets onto the bus, receive packets from the bus,
or both.
Bus tap Attaches fixed nodes to a bus link.
End of Table 1-9
Project Editor Operations

The Project Editor provides operations to support the creation, editing, and
verification of network models. Operations related to major capabilities are listed
in the following table.
For a complete listing of operations and an in-depth explanation of their use, see
Project Editor on page ER-3-1.
Figure 1-15 Project Editor Object Palette

Table 1-10 Project Editor Operations

Operation1 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 VNE Server 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 one 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 correctly for their 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 Modeler and are
based on the CIA World Data Bank.
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.
End of Table 1-10

1. Operation names are not exact and may refer to several actual operations as a group.
Node Editor
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
Node Editor and the operations that it provides.

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 node’s
operation and they can be active concurrently. Several types of connections
support flow of data between the modules within a node. The objects used to
build node models are listed in the following table.
Table 1-11 Node Model Objects

Processor General purpose, programmable object whose behavior is specified by

a process model.
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. Two types of transmitters correspond to supported link types:
point-to-point and bus.
Receiver Allows packets to be received from other nodes via attached links. Two
types of receivers correspond to supported link types: point-to-point and
bus.
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.
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 to specify that they be kept
together when attaching the node to a link.
Esys Module General-purpose and programmable like processors and queues, but
can also specify an ESD model that defines the behavior of the module.
Contains both a process model and an external system definition (ESD).
End of Table 1-11

Node Editor Operations

The Node Editor provides operations to support the creation and editing of node
models. Operations related to major capabilities are listed in the following table.
Table 1-12 Node Editor Operations

Operation1 Description
Create object Individual operations are provided to support the graphical

creation of each type of object listed in the previous table.

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.
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.
End of Table 1-12

For a complete listing of operations and an in-depth explanation of their usage,

see Chapter 5 Node Editor on page ER-5-1.
Process Editor
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 do 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 model’s 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 Process Editor and the operations that it
provides.

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 listed in the following table.
Table 1-13 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.
End of Table 1-13

Process Editor Operations

The Process Editor provides operations to support the creation and editing of
process models. Operations related to major capabilities are listed in the
following table.
Table 1-14 Process Editor Operations

Operation 1 Description
Create object Individual operations are provided to support the graphical

creation of states and transitions.

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 Process models contain no objects with promotable

interfaces 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.

Table 1-14 Process Editor Operations (Continued)

Operation 1 Description
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.
End of Table 1-14


see Process Editor on page ER-6-1.
Probe Editor
The Probe Editor is used to define data collection requirements prior to
executing a simulation. Because most simulation models would generate very
large volumes of data if all possible outputs were recorded, Modeler relies on
the user to explicitly designate what is of interest. Each desired output is
enabled by creating an object called a probe and configuring it appropriately.
Groups of probes are saved as probe lists so that they can be used collectively
when running simulations. Several types of probes are used to collect different
types of simulation results. This section describes each type of probe.

Probe Editor Objects

Each probe is represented as an individual object. The probe’s attributes
provide access to optional aspects of data collection, depending on the type of
data. The following table lists each type of probe.
Table 1-15 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 Modeler).
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.
Automatic animation 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.
Custom animation Enables custom animation programmed within process models and link
models.
Statistic animation 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 Results Browser. Axes
rescale automatically to track changes.
End of Table 1-15
For detailed information about probes, see Chapter 11 Simulation Design on

page MC-11-1.
Simulation Sequence Editor

Discrete event simulations are ordinary programs that may be executed from
the command line if desired. However, the Simulation Sequence Editor provides
an often more convenient environment for configuring and running a simulation
or group of simulations.
The Simulation Sequence Editor allows any number of separate simulation runs
of various models to be specified as simulation sets. The attributes for each
simulation set are specified in the Simulation Set dialog box.

Figure 1-16 Simulation Sequence Editor
The collection of simulation sets and associated configuration information is

referred to as a simulation sequence. The Simulation Sequence Editor allows
an entire sequence to be run unattended.
Key Concept—A simulation sequence consists of any number of simulation

sets. Each set specifies a network model that is to be simulated and values for
attributes. One or more simulation runs could result for each set, depending on
possible combinations of attribute values. The sequence of simulation runs can
be executed unattended.
For a complete description of this editor, see Chapter 16 Simulation Sequence

Editor on page ER-16-1.
External System Definition Editor

An external system is Modeler’s representation of a system whose behavior is
determined by other code during a cosimulation. External systems fit into
Modeler at the node level as modules. An esys module uses an external system
definition (ESD) in conjunction with a process model that tells Modeler how to
interact with the external model represented by the external system.
The External System Definition Editor enables you to create and modify external
system definitions. An external system definition (ESD) specifies (via a
simulator description file) how the cosimulation should be built and defines the
esys interfaces that will exchange data with the external simulator. Each esys
interface has a number of attributes you can set. The External System Definition
Editor enables you to create and edit ESDs.
For a complete description of this editor, see External System Editor on

page ER-7-1.

Packet Format Editor

The Packet Format Editor provides a way to specify the collection of fields
contained by a formatted packet. Each field has attributes specifying its name,
type, size, and default value. Modeling each field’s size allows the overall size
of 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 concern for
actual content.
• Packet fields model packet encapsulation by layered protocols.
Packet Format Editor Objects

The Packet Format Editor uses only one object: the packet field. Each field’s
color can be set, but the size of the field on the screen depends on the field’s
assigned length.
Table 1-16 Packet Format Objects

Object Type Definition Representation
Packet field The packet field object represents one field in a

packet format. You can specify such attributes as the
field’s name, data type, size in bits, default value, and
color.
End of Table 1-16
Packet Format Editor Operations

The Packet Format Editor provides operations to support the creation and
editing of packet fields. Operations related to major capabilities are summarized
in the following table.
Table 1-17 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 one field
can optionally be applied to an entire set of selected fields.
Edit packet attributes View or modify attributes pertaining to the entire packet.
End of Table 1-17

see Packet Format Editor on page ER-11-1.

Parameter Editors Summary

The Link Editor, ICI Editor, and PDF Editor are used to specify one type of
model. Collectively, these types of models are referred to as parameter models
because they are mainly used as assignments for complex attributes (that is,
parameters) of objects. There are three types of parameter models:
• Link model
• Interface Control Information (ICI) format
• Probability density function (PDF)
Most parameter models take the form of a functional relationship (in which case
they are edited graphically) or a table of information (in which case they are
edited in dialog boxes). This is depicted below using the PDF model type. This
section provides a brief description of each type of parameter model.
Figure 1-17 PDF Models
PDF of a continuous random variable, PDF of a discrete random variable,

containing no impulses implemented using impulses

Parameter Model Descriptions

The following table lists each of the parameter model types and their
applications.
.
Table 1-18 Parameter Models
Model Type Editing Method Description
Link model dialog box A 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 correct 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.
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 packet sources. They are
also commonly used to generate random variable values within
process models (such as to implement random time-out intervals
for retransmissions or choose random destinations for packets).
End of Table 1-18
Modeler as an Authoring Tool

Traditional users of Modeler view their deliverable as the results of one or more
simulation studies. However, other users may view their objective as the
creation of a customized modeling environment. The environment consists of
Modeler, which allows end users to create models at the network level, specify
data collection, run simulations, and do analysis and animations.
The customization of the modeling environment seen by the end user is made
possible by Modeler. Using Modeler, sophisticated models of nodes and
processes can be created. These models can then be prepared as a library for
use by the end user who is less familiar with the detailed operation of the
system. To the end user, these models appear as off-the-shelf components; he
is protected from the underlying complexity.

In addition, the user interface can be tailored to offer a truly customized

environment to the end user. Modeler offers extremely open interfaces, allowing
easy integration with complementary network planning and management tools.
Key Modeler features supporting this type of application are listed in the
following table.
Table 1-19 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 can provide
keys to unlock models.
External Tool Support Authors can augment Modeler’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 Modeler 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 models to be
updated in real-time as the state of other applications change.
Attribute Interfaces The key to productizing models is tailoring the interface that they present to the user. For
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 documentation. Similar capabilities are provided for
the statistics offered by a model.
Application Program Interface Modeler offers an Application Program Interface (API) called EMA (External Model Access).
EMA allows your programs to access (create and/or parse) models. This means that you
can automatically generate models to reflect information that is stored elsewhere (for
example, in Network Management databases). You can also extract information from
models and simulation output files to use them in external applications. Because EMA is a
published interface, you can do robust integration of Modeler and other tools that will
survive new software releases.
End of Table 1-19


01 10 Ov

Încărcat de

Informații document

Descriere originală:

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

01 10 Ov

Încărcat de

Drepturi de autor:

Formate disponibile

1—Modeling Overview

This section provides an overview of Modeler’s capabilities and structure. It is

• Multiple User Communities on page MC-1-2—Describes the types Modeler

• Key System Features on page MC-1-2—Describes salient and distinctive

• Typical Applications of Modeler on page MC-1-4—Presents some

• Modeler Architecture on page MC-1-5—Describes the Modeler approach to

• Modeler Editors on page MC-1-35—Introduces the tools that constitute the

• Modeler as an Authoring Tool on page MC-1-48—Describes how to use

Modeler/Release 14.0 MC-1-1

Multiple User Communities

• System modelers—are the traditional users of Modeler, who study technical

See Modeler as an Authoring Tool on page MC-1-48 for more information on

Modeler, in conjunction with the Wireless functionality, provides specific

Key Concept—Modeler is used to construct models for two different purposes:

Key System Features

• Object orientation—Systems specified in Modeler consist of objects, each

• Specialized in communication networks and information systems—Modeler

• Hierarchical models—OPNET models are hierarchical, naturally paralleling

MC-1-2 Modeler/Release 14.0

• Graphical specification—Wherever possible, models are entered via

• Flexibility to develop detailed custom models—Modeler provides a flexible,

• Automatic generation of simulations—Model specifications are compiled

• Application-specific statistics—Modeler provides built-in performance

• Integrated post-simulation analysis tools—Performance evaluation, and

• Interactive analysis—All Modeler simulations automatically incorporate

• Animation—Simulation runs can be configured to automatically generate

• Cosimulation—You can connect Modeler with one or more other simulators

• Application program interface (API)—As an alternative to graphical

Modeler/Release 14.0 MC-1-3

Typical Applications of Modeler

• Standards-based LAN and WAN performance modeling—detailed library

• Internetwork planning—hierarchical topology definitions allow arbitrarily

• Research and development in communications architectures and

• Distributed sensor and control networks, on-board systems—Modeler allows

• Resource sizing—accurate, detailed modeling of a resource’s

• Mobile packet radio networks—specific support for mobile nodes, including

MC-1-4 Modeler/Release 14.0

• Satellite networks—specific support for satellite nodes, including automatic

• C3I and tactical networks—support for diverse link technologies; modeling of

• Model Specification on page MC-1-6 and Modeling Communications with

• Data Collection and Simulation on page MC-1-27

• Analysis on page MC-1-32

These phases are necessarily performed in sequence. They generally form a

Figure 1-1 Simulation Project Cycle

Initial Specification Data Collection and

Modeler/Release 14.0 MC-1-5

For more information, see:

• Specification Editors on page MC-1-6

• Modeling Domains on page MC-1-8

• Models, Objects, and Attributes on page MC-1-19

• Project Editor—Develop network models. Network models are made up of

• Node Editor—Develop node models. Node models are objects in a network

• Process Editor—Develop process models. Process models control module

• External System Editor—Develop external system definitions. External

• Link Model Editor—Create, edit, and view link models.

• Packet Format Editor—Develop packet formats models. Packet formats

MC-1-6 Modeler/Release 14.0

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

Key Concept—OPNET models are structured hierarchically, in a manner that

Modeler makes use of graphical specification of models wherever appropriate.

Modeler/Release 14.0 MC-1-7

Table 1-1 Modeling Domains