Chapter 1 Modeling Overview

Transcription

1 Chapter 1 Modeling Overview 1-Ov

2 2-Ov Modeling Concepts

3 Modeling Concepts Introduction Ov.1 Introduction OPNET provides a comprehensive development environment supporting the modeling of communication networks and distributed systems. Both behavior and performance of modeled systems can be analyzed by performing discrete event simulations. The OPNET environment incorporates tools for all phases of a study, including model design, simulation, data collection, and data analysis. This chapter provides an overview of OPNET s capabilities and structure. It is intended to provide an introduction to the package and context for further reading of the documentation. The chapter is divided into five sections, as follows: Modeling Overview Overview Chapter: Content Summary Section Key System Features Typical Applications Architecture Tools Authoring Capabilities Topic Enumerates salient and distinctive characteristics of the OPNET software. Presents some applications typically addressed with OPNET and some of the features that provide direct support for those applications. Describes the OPNET approach to each phase of the modeling and simulation project. Presents fundamental modeling constructs. Introduces the tools that constitute the OPNET environment. Each tool supports a particular phase or sub-phase of the simulation and modeling project. Discusses the use of OPNET as an authoring tool to prepare models for off-the-shelf use by end users in the IT DecisionGuru or Modeler XE environments. This chapter is designed to allow reading at two levels: detailed and conceptual. For more detailed information, merely read the paragraph text, as you would a traditional text. To cover the information more quickly, remain at a conceptual level by reviewing only tables, diagrams, bullet list headings, and special key concepts boxes, as shown below. If you require more detail on a particular topic, read only the paragraphs in the corresponding section. 3-Ov

4 Introduction Modeling Concepts To quickly cover the material in this chapter, simply skip over paragraph text, reviewing only tables, diagrams, bullet list headings, and key concepts boxes such as this one. Ov.1.1 Multiple User Communities OPNET users can be divided into two broad categories: system modelers and authors. System modelers are the traditional users of OPNET, who study technical problems using simulation. They are usually interested in performance measures and behavioral analysis of a proposed system. Often they are designers of networks, network devices and protocols, or distributed applications. Authors, on the other hand, do not use OPNET to conduct their own simulation studies, but to prepare an environment for others to do so. OPNET Modeler is used to create customized models that are appropriate for a particular type of end user. The models are typically delivered to the end user in the Modeler XE environment, which offers the benefit of greater simplicity and ease of use. Refer to the end of this chapter for more information on specific features of OPNET that support its use as an authoring tool. OPNET exists as both a core product, and in a Radio version (using the optional Radio module). Modeler, in conjunction with the Radio module, provides specific features to support projects related to wireless networking. It includes, among other radio-specific capabilities, the ability to model node mobility and the effects of interference on radio link performance. Of course, many projects do not require radio capability and these can be carried out with the core version. Throughout this manual, indications are provided when features specific to the Radio version are discussed. OPNET 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 products such as IT Guru. 4-Ov

5 Modeling Concepts Key System Features Ov.2 Key System Features OPNET is a vast software package with an extensive set of features designed to support general network modeling and to provide specific support for particular types of network simulation projects. This section provides only a brief enumeration of some of the most important capabilities of OPNET. Subsequent sections of this chapter provide more detailed information on these features, as well as other aspects of OPNET. Modeling Overview Object orientation. Systems specified in OPNET consist of objects, each with configurable sets of attributes. Objects belong to classes which provide them with their characteristics in terms of behavior and capability. Definition of new classes are supported in order to address as wide a scope of systems as possible. Classes can also be derived from other classes, or specialized in order to provide more specific support for particular applications. Specialized in communication networks and information systems. OPNET 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. 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. OPNET 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 automatically compiled into executable, efficient, discrete-event simulations implemented in the C programming language. Advanced simulation construction and configuration techniques minimize compilation requirements. Application-specific statistics. OPNET provides numerous built-in performance statistics that can be automatically collected during simulations. In addition, modelers can 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 5-Ov

6 Key System Features Modeling Concepts interpreted. OPNET includes a sophisticated tool for graphical presentation and processing of simulation output. Interactive analysis. All OPNET 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. Application program interface (API). As an alternative to graphical specification, OPNET models and data files may be specified via a programmatic interface. This is useful for automatic generation of models or to allow OPNET to be tightly integrated with other tools. 6-Ov

7 Modeling Concepts Typical Applications of OPNET Ov.3 Typical Applications of OPNET As a result of the capabilities that were described in the previous sections, OPNET can be used as a platform to develop models of a wide range of systems. Some examples of possible applications are listed below with specific mention of supporting features: Standards-based LAN and WAN performance modeling 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. Modeling Overview 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 OPNET 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 OPNET allows development of sophisticated, adaptive, applicationlevel 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 requestprocessing 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 OPNET network specification environment. (Radio version only) 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. (Radio version only) 7-Ov

8 Typical Applications of OPNET Modeling Concepts 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; radio link models support determination of friendly interference and jamming. 8-Ov

9 Modeling Concepts OPNET Architecture Ov.4 OPNET Architecture OPNET 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: Specification, Data Collection and Simulation, and Analysis. Modeling Overview 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. Simulation Project Cycle Re-Specification Initial Specification Data Collection and Simulation Analysis Ov.4.1 Model Specification Model specification is the task of developing a representation of the system that is to be studied. OPNET 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 OPNET environment. Ov Specification Editors OPNET supports model specification with a number of tools or editors that 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, OPNET 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 break down the required modeling information in a manner that parallels the structure of actual network systems. Thus, the model-specification editors are organized in an essentially hierarchical fashion. Model specifications performed in the Project Editor rely on elements specified in the Node Editor; in turn, when working in the Node Editor, the developer makes use of models defined 9-Ov

10 OPNET Architecture Modeling Concepts in the Process Editor. The remaining editors are used to define various data models, typically tables of values, that are later referenced by process- or node-level models. This organization is depicted 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. (Modeler only) Process Editor Develop process models. Process models control module behavior and may reference parameter models. (Modeler only) Link Model Editor Create, edit, and view link models. (Modeler only) Packet Format Editor Develop packet formats models. Packet formats dictate the structure and order of information stored in a packet. (Modeler only) ICI Editor Create, edit, and view interface control information (ICI) formats. ICIs are used to communicate control information between processes. (Modeler only) Antenna Pattern Editor Create, edit, and view antenna patterns for transmitters and receivers. (Modeler/Radio only) Modulation Curve Editor Create, edit, and view modulation curves for transmitters. (Modeler/Radio only) PDF Editor Create, edit, and view probability density functions (PDFs). PDFs can be used to control certain events, such as the frequency of packet generation in a source module. (Modeler only) 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. OPNET makes use of graphical specification of models wherever appropriate. Thus, the model-specification editors all present a graphical interface in which the user manipulates objects representing the model components and structure. Each 10-Ov

11 Modeling Concepts OPNET Architecture editor has its own specific set of objects and operations that are appropriate for the modeling task on which it is focused. For instance, the Project Editor makes use of node and link objects; the Node Editor provides processors, queues, transmitters, and receivers; and the Process Editor is based on states and transitions. As a result, the diagrams developed in each editor have a distinct appearance, as shown in the following screen samples. Graphical Editors for Network, Node, and Process Models Modeling Overview Node Editor Project Editor Process Editor Ov Modeling Domains The Network, Node, and Process modeling environments are sometimes referred to as the modeling domains of OPNET, since they essentially span all the hierarchical levels of a model. The remaining specification editors correspond to no particular modeling domain since they mainly support the three principal editors. As mentioned earlier, the capabilities offered by the three modeling domains mirror the types of structures found in an actual network system; the issues addressed by each domain are summarized in the following table and then briefly described in the remainder of this section. 11-Ov

12 OPNET Architecture Modeling Concepts OPNET Modeling Domains Domain Editor Modeling Focus Network Project Network topology described in terms of subnetworks, nodes, links, and geographical context. Node Node Node internal architecture described in terms of functional elements and data flow between them. Process Process Behavior of processes (protocols, algorithms, applications), specified using finite state machines and extended high-level language. 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, discussed later in this section. Within a single network model, there may be many nodes that are based on the same node model; the term node instance is used to refer to an individual node, in order to distinguish it from the class of nodes sharing the same model. However, in general, when the term node is used by itself, in the context of the network domain, it can be assumed that a node instance is being referred to, rather than a node model. A network model may make use of any number of node models. OPNET does not place restrictions on the types of nodes that can be deployed in a communication network; instead it adopts an open approach whereby modelers can develop their own library of node models to use as building blocks for network models. In addition, there are no limits on the number of node models or node instances that a network model may contain (other than those imposed by workstation memory limitations). 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 12-Ov

13 Modeling Concepts OPNET Architecture network model, this feature provides an intrinsic notion of distance, which allows automatic calculation of communication delays between nodes. The basic object used to build network models is the fixed communication node. In OPNET, this is the only type of node available. Fixed nodes can be assigned arbitrary locations, but during a simulation their location may not change. OPNET Radio versions allow networks to contain fixed nodes, but also add capability for mobile and satellite nodes. Mobile nodes can be assigned 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 Radio version, simulations can involve all three types of nodes. Modeling Overview Most nodes require the ability to communicate with some or all other nodes to perform their function in a network model. Several different types of communication link architectures are provided to interconnect nodes that communicate with each other. OPNET provides simplex (unidirectional) and duplex (bidirectional) point-to-point links to connect nodes in pairs and a bus link to allow broadcast communication for arbitrarily large sets of fixed nodes. The Radio version adds the capability for fixed, satellite, and mobile nodes 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 discussed in later chapters, each type of link can be customized by editing parameters or supplying new logic for the underlying link models. The following figures show some typical network model diagrams involving each of the supported link types. Network models consist of nodes and links which can be deployed within a geographical context. OPNET provides fixed nodes and point-to-point and bus links; the Radio version in addition provides mobile and satellite nodes, and radio links. 13-Ov

14 OPNET Architecture Modeling Concepts Network Models with Radio, Bus, and Point-to-Point Links Radio Links Bus Link Point-to-Point 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. OPNET provides fixed, mobile, and satellite subnetworks to enhance network models. These subnetworks can then be connected by different types of communication links, depending on the type of subnetwork. The larger network can then be viewed as a network of its subnetworks. This abstraction can be carried out at many levels. In other words, one can form networks of subnetworks, which in turn are formed of other subnetworks, and so on. At the bottom of this hierarchy, the lowest level subnetwork is composed only of nodes and links, but no other subnetworks. 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. 14-Ov

15 Modeling Concepts OPNET Architecture In OPNET network models, subnetworks can be nested to an unlimited depth to construct complex topologies. The following set of diagrams, captured in the Project Editor, illustrate the use of fixed subnetworks to model hierarchical networks. A Hierarchical Network with Two Levels of Subnetworking Modeling Overview Node Domain The Node Domain provides for the modeling of communication devices that can be deployed and interconnected at the network level. In OPNET terms, these devices are called nodes, and in the real world they may correspond to various types of computing and communicating equipment such as routers, bridges, workstations, terminals, mainframe computers, file servers, fast packet switches, satellites, and so on. 15-Ov

16 OPNET Architecture Modeling Concepts Node models are developed in the Node Editor and are expressed in terms of smaller building blocks called modules. Some modules offer capability that is substantially predefined and can only be configured through a set of built-in parameters. These include various transmitters and receivers allowing a node to be attached to communication links in the network domain. Other modules, called processors and queues, are highly programmable, their behavior being prescribed by an assigned process model. Process models are developed using the Process Editor. A node model can consist of any number of modules of different types. Three types of connections are provided to support interaction between modules. These are called packet streams, statistic wires (also sometimes referred to as streams and statwires, respectively), and logical associations. Packet streams allow formatted messages called packets to be conveyed from one module to another. Statistic wires convey simple numeric signals or control information between modules, and are typically used when one module needs to monitor the performance or state of another. As will be discussed later in this manual, both packet streams and statistic wires have parameters that may be set to configure aspects of their behavior. Logical associations identify a binding between modules. Currently, they are allowed only between transmitters and receivers in order to indicate that they should be used as a pair when attaching the node to a link in the Network Domain. The following diagram illustrates a typical node model that includes the three types of connections. Node models consist of modules and connections. Modules are information sources, sinks, and processors. Some modules have predefined behavior; processor and queue modules are programmable via their process model. Connections (packet streams and statistic wires) allow information to flow between modules. 16-Ov

17 Modeling Concepts OPNET Architecture Node Model Employing Packet Streams, Statistic Wires, and Logical Associations packet stream Modeling Overview logical association statistic wire 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. Possible OPNET Representation of TCP/IP Protocol Stack Process Domain As mentioned earlier in the discussion of the Node Domain, queue and processor modules are user-programmable elements that are key elements of communication nodes. The tasks that these modules execute are called processes. A process can in many ways be thought of as similar to an executing software program, since it includes a set of instructions and maintains state memory. Processes in OPNET are based on process models that are defined in the Process Editor. The relationship between process model and process is similar to the relationship between a program and a particular session of that program running as 17-Ov

18 OPNET Architecture Modeling Concepts a task (in fact, the term process is used in many operating systems as well). Just as nodes created in the Project Editor are instances of node models defined with the Node Editor, each process that executes in a queue, processor, or esys module is an instance of a particular process model. 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 OPNET 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. OPNET places no limits on the number of processes that may be created in a particular processor or queue. Processes may be created and destroyed based on dynamic conditions that are analyzed by the logic of the executing processes. This paradigm provides a very natural framework for modeling many common systems. In particular, multitasking operating systems where the root process represents the operating system itself and the dynamically created processes correspond to new tasks; and multi-context protocols where the root process represents a session manager, for example, and each new session that is requested is modeled by creating a new process of the appropriate type. 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 may be executing at any time. A process is considered to be executing when it is progressing through new instructions that are part of its process model. When a process begins execution it is said to be invoked. A process that is currently executing can invoke another process in its process group to cause it to begin executing. When this happens, the invoking process is temporarily suspended until the invoked process blocks. A process blocks by indicating that it 18-Ov

19 Modeling Concepts OPNET Architecture has completed its processing for its current invocation. Once the invoked process has blocked, the invoking process resumes execution where it had left off, in a manner similar to the procedure-call mechanism in a programming language such as C. Processes in OPNET are designed to respond to interrupts and/or invocations. Interrupts, which are discussed in significant detail in later sections of this manual, are events that are directed at a process and that may require it to take some action. They may be generated by sources external to a process group, by other members of a process group, or by a process for itself. Interrupts typically correspond to events such as messages arriving, timers expiring, resources being released, or state changes in other modules. Once a process has been invoked due to an interrupt, it may invoke other processes in the group and these may in turn invoke other processes, etc. An interrupt s processing is completed when the first process that was invoked blocks. Modeling Overview 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. OPNET s 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. 19-Ov

20 OPNET Architecture Modeling Concepts 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 extremely general in nature since they are expressed as C or C++ statements. In addition, because Proto-C is focused on modeling protocols and algorithms, it provides an extensive library of over 300 Kernel Procedures (also known as KPs) that can be invoked to perform commonly needed actions. Kernel Procedures are grouped into packages of related functions. The following table shows some of the capabilities provided by the Kernel Procedure libraries. 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. Major Simulation Kernel Procedure Packages Package Anim Dist Applications Support for custom animation development Probability distribution and random number generation 20-Ov

21 Modeling Concepts OPNET Architecture Package Ev Ici Id Major Simulation Kernel Procedure Packages (Cont.) Applications Event list and event property query; event cancellation Formal interfaces between processes; association of information with interrupts Identification of objects Modeling Overview Ima Intrpt Pk Prg Pro Q Rad Rte Sar Sim Stat Strm Subq Tbl Tim Td Topo In-simulation query and modification of object attributes Query of interrupt properties; control of interrupt handling Creation, destruction, modification, analysis, and transmission of packets Programming support: linked lists, memory, string manipulation, debugging Creation, invocation of processes; process group shared memory Queueing statistics; high-level queueing operations Dynamically changing a radio transmitter channel s receiver group (Radio version only) Basic routing support for static routing implementations Segmentation and reassembly of packets Simulation control: customized messaging, simulation execution control Custom statistic generation; intermodule signalling via statistic wires Communication between modules via packet streams, packet delivery Low-level queueing operations: enqueueing, dequeueing, statistics, etc. Accessing of tabular data: antenna patterns, modulations Importing traffic into an existing OPNET network model Setting and getting of transmission data for custom link models Query of model topology (e.g., for automatic discovery and configuration) 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 OPNET s 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 OPNET-specific, general C/C++ language, and user-defined types. This capability allows a process to flexibly maintain counters, routing tables, statistics related 21-Ov

22 OPNET Architecture Modeling Concepts 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, that are implemented each time that they are traversed. Process Model Attributes A process model may define parameters, called attributes, that are used once it is instantiated as a process to customize aspects of its behavior. This technique fosters reuse of process models for various purposes by avoiding hardwired specification where possible. For instance, a process model that performs windowbased flow control, may be defined with the window size as an attribute, so that it is reusable in different situations requiring different values of the window size. Ov Models, Objects, and Attributes Objects The preceding sections have discussed certain major OPNET model types and objects. In this section, the OPNET object model is presented in greater detail. Wherever possible, information is presented in a manner which is independent from particular modeling domains, except when focusing on examples. Objects 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 22-Ov

23 Modeling Concepts OPNET Architecture Typical Roles of an Object in a Model Process, modify, or relay information Respond to events Contain other objects Objects are created by various mechanisms in OPNET models. Many result from explicit specification by the user via graphical or programmatic methods. So for example, a link object may be created in a network model by physically dragging it from the Project 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 in order to perform a task. Dynamic objects are different in many ways than the statically created OPNET objects; in particular they offer more specialized interfaces, allowing them to be manipulated in a more efficient manner. Most of the discussion in this section will not apply to dynamic objects. Modeling Overview Objects are the building blocks of OPNET models and appear in each of the modeling domains. Some objects are created explicitly by the user; others are implicitly created by OPNET. During a simulation, certain types of objects can be created dynamically. Attributes In order to achieve predictable and tractable behavior when building a complex many-object system, each object must offer a well-defined interface. The interface of an OPNET object consists primarily of the attributes that it makes available and the procedures that it supports to access its attributes or to cause it to perform actions. Some procedures supported by objects are provided automatically by OPNET; others are programmed by users for specialized needs. Most procedures vary according to the object type, and so few general comments can be made about them except to say that it is crucial that they have a well known interface and that they shield users from underlying details of object implementation. Attribute Components Name 23-Ov

24 OPNET Architecture Modeling Concepts Attribute Components Value Properties 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 the scope of a particular object. Each attribute also provides a storage area for the information that is assigned to it. This information is referred to as 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. Attribute Properties Property Data Type Default Value Range Symbol Map Comments Description Class of data storage. OPNET supports a wide variety of numerical and text storage types, as well as a compound attribute whose value is another object. Provides a value that can be used in the absence of explicit assignment. For numerical attributes, limits the set of acceptable values to specified bounds. Enumerates a list of values and names that represent them. Supports pre-configuration and more meaningful presentation of value choices. Also can be used to limit value choices to a restricted set. Documents any information desired about the attribute. Generally describes the attribute s purpose and interface (i.e., how it behaves) As mentioned in the table above, OPNET supports a particular attribute data type called compound. Compound attributes support nested complex data storage within an object in a very simple manner: the value is itself another object. This object can have any number of attributes of its own, including additional compound attributes. Certain OPNET built-in objects have compound attributes. For example, queues incorporate subqueues using this mechanism; similarly, transmitters and receivers represent the channels they contain as 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, for example. 24-Ov

25 Modeling Concepts OPNET Architecture 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. Modeling Overview Models It was mentioned that many OPNET models (network, node, and process) consist largely of objects. At the same time, most objects have a model that confers upon them some or all of their characteristics. The object is said to be an instance of the model, since there is a many-to-one relationship between a model and the objects that refer to it. The model defines an object class that all of the related objects belong to. Some of OPNET s 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. Thus they offer no model attribute. However, several key objects in OPNET offer a model attribute that allows their fundamental behavior and structure to be controlled externally. In fact, altering an 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 that they refer to. The following table enumerates the OPNET objects that support a model attribute. 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 In each of the model types listed in the table above, a model s 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 25-Ov

26 OPNET Architecture Modeling Concepts hidden from the user. Thus, the model can completely control the attribute interfaces of the object. OPNET objects have behavior and structure that is specified by a model. Models also specify part or all of an object s interfaces. Some objects have implicit models that cannot be changed; others can be assigned models via their model attribute, allowing extensive customization. Model Attributes and Attribute Promotion With both models and attributes introduced as concepts, the notion of a model attribute can be defined. In addition to describing objects, attributes can be associated with models in order to represent a parameter of the model. This was already briefly mentioned in the case of process models in a previous section. The importance of providing a parameter for a model lies in increasing the generality of the model. By varying the values of the model s parameter, a user can alter its behavior in some well-defined manner, without having to actually modify the model itself. This approach can be contrasted with hardwiring the value of the attribute into the model itself, which exposes no control to the model s user. Obtaining the behavior corresponding to a new value of the attribute would then require complete duplication of the model and a change to the hard-wired value. Multiple versions of the model would then have to be maintained in a parallel manner over time, which is clearly undesirable. The model attributes mechanism therefore supports increased reusability of models. 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 more 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 when that object s model is specified. The model s attributes are simply added to those that are intrinsic to the object, as illustrated in the following diagram. 26-Ov

27 Modeling Concepts OPNET Architecture Object Attributes Inheritance of Model Attributes by an Object Object O Model = M A B C D XY object refers to model M Modeling Overview Z object acquires attributes A,B, C, and D Model Attributes Model M A B C D Other Model Data 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, in the case of a module attribute in a node model, promotion moves the attribute into the node model s attribute interface, meaning that it will then be inherited by any node object in the network level that references the node model. In the case of node objects in the network level, a promoted attribute is added to the attributes of the subnet that it encompasses it. Attributes that promote all the way through the model hierarchy become attributes of the overall system model, or equivalently attributes of the simulation. These can be assigned values at simulation run time via a variety of mechanisms. It is then possible to iterate through a range of parameter values in different simulations in order to study the system as a function of the parameters. 27-Ov

28 OPNET Architecture Modeling Concepts Instead of having a value that is specified in advance, object attributes can be promoted. A promoted attribute moves up to the next level in the model hierarchy, allowing its specification to be performed there. Attributes that are promoted through the top of the hierarchy (topmost subnetwork) become attributes of the simulation. Derived Models In many cases, model developers have a need to customize a model s interface without actually 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 upon an existing model and generates a derived model that has attribute interfaces that differ in various ways.the resulting model is called a derived model, and the model used as the basis for its derivation is referred to as its parent model. A model which 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. Since a model and a derived model are fundamentally the same in terms of structure and behavior, it makes sense that specification of this information should be shared. This provides economy of specification and enforces long-term consistency of these models as they are modified over time. 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. Ov.4.2 Modeling Communications with Packets The previous sections describe the support OPNET provides for representing the structure of a network, including the elements that appear at different hierarchical levels. Communication of data takes place at all levels of 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. 28-Ov

29 Modeling Concepts OPNET Architecture There are many forms of communication that are supported by the OPNET 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 OPNET system for tracing and accounting purposes; and the third area contains transmission data attributes that are used to support customizable models for communication links. Modeling Overview 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. Three Main Storage Areas of Packet Contents User-Defined Fields Predef. Fields TD Attrs. Index Name Type Contents Size Name Contents Index Contents 0 src_addr integer dst_addr integer timer_a double creat_mod 19 creat_time owner timer_b double format transp_x e-07 4 ack integer 0 1 id (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 OPNET simulations model each individual packet in a network model, and the packet fields contain actual data values, fully accurate models of protocol interactions can be implemented. Processes can modify and obtain values of fields and base their actions upon their contents. Packet fields may contain data of one of several supported data types. Integer and double (floating-point) fields can be used to represent flags, counters, timer values, network addresses, etc. Packet fields allow packets to be encapsulated within other packets, which is a 29-Ov

30 OPNET Architecture Modeling Concepts fundamental mechanism supporting layered protocol modeling, since higher-layer protocols request that lower layer protocols transport packets to remote peers. Structure fields provide general support for carrying user-defined C/C++ language data structures within packets; this is sometimes useful for sophisticated applications where complex information, such as routing tables, are transferred across networks. The information field type is provided for convenient support of bulk or filler data in a packet, which can be important to accurately model packet size; information fields contain no values. Packet Field Types Type integer double packet structure information Use Whole numbers: flags, counters, addresses, etc. Floating point numbers: timer values, statistics, etc. Encapsulation of higher-layer protocol data Transport of complex user-defined data types Modeling of field size when content is irrelevant 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 two broad categories: formatted and unformatted. A formatted packet is one whose fields are defined according to a template called a packet format. Packet formats are created in the Packet Format Editor and specify a list of field names, data types, sizes (that is, field lengths specified in bits), and default values. When formatted packets are created, they instantly acquire the fields defined in their format and, when applicable, default values are installed in those fields. Unformatted packets have no fields when they are created; fields are added one at a time and can only be referenced by numeric index, not by name. Unformatted packets are typically useful only for very simple applications and the recommended approach is to define packet formats for most models, particularly when several different types of packets are used in a network. 30-Ov

31 Modeling Concepts OPNET Architecture Packets may be made to conform to a packet format. Packet formats are defined in the Packet Format Editor and specify a template for a packet s fields, including the names, types, and sizes of each supported field. Modeling Overview Packets can be used to transfer data at all levels of an OPNET network model via several communication mechanisms. Processors, queues, and other modules forward packets within nodes via packet streams, which were introduced earlier in this chapter. Packet streams may introduce delay and also queue packets until a destination module is ready to accept them. At the network level, packets are sent between nodes over communication links. Communication links use customizable underlying models to model delays and errors in packet transmission. A third packet transfer mechanism, called packet delivery, supports transfer of packets between modules, regardless of their location in a network, without requiring any physical connection to exist between them. OPNET packets are intended to represent information-carrying structures of various types that appear in communications and systems architectures, including packets, messages, frames, cells, datagrams, and transactions. The term packet has been chosen as a general term and should not be interpreted as restricting the types of applications for which OPNET can be used. For some communication networks, information transfer does not necessarily occur in packet form. In particular, some devices communicate with streams of data where information flow is continuous. In such cases, OPNET packets can be treated as messages that carry only model-relevant information between the communicating entities. This may include information such as the amount of data transferred, or signaling data that is needed by the application models at either end of the stream. Depending on what the goal of the modeling effort is, the data streams can be adequately represented by modeling the important phases of their operation (setup, tear-down, and control information transfer) with packets, or even with other OPNET communication mechanisms that will be discussed later in this manual. Though the term packet is used, OPNET packets can be used to represent other forms of communication as well. In stream-oriented communications, for example, packets may be used to represent key signalling information, allowing the connection to be modeled in terms of its duration, bandwidth requirements, etc. 31-Ov

32 OPNET Architecture Modeling Concepts Ov.4.3 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. OPNET supports these activities by creating an executable model of the system. Provided that the model is sufficiently representative of the actual system, OPNET allows realistic estimates of performance and behavior to be obtained by executing simulations. Several mechanisms are provided to collect the desired data from one or more simulations of a system. Ov Simulation Output Data Types OPNET simulations are capable of producing many types of output. Of course, because of the general programmability of process models and link models, developers are able to define their own types of output files, including text reports, proprietary binary files, etc. However, in most cases, modelers use the types of data directly supported by OPNET. These are output vectors, output scalars, and animation. Each is briefly described in this section. 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 OPNET 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 a single simulation run.the first value in the entries can be thought of as the independent variable and the second as the dependent variable. In OPNET these are referred to as the abscissa and the ordinate, respectively. In the majority of cases, the independent variable of a vector is simulation time, which increases monotonically as a 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 discussed later in this manual. The following diagram depicts a typical data set contained in a vector. Note that it is possible for a vector to store multiple ordinate values with the same abscissa value. 32-Ov

33 Modeling Concepts OPNET Architecture Output vectors represent time-series simulation data. They consist of a list of entries, each of which is a time-value pair. Modeling Overview Output Vector Contents abscissa (time) values time Q Size ordinate (Q size) values 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 in order to compute a scalar that reflects the entire data set. For example, the mean ordinate value of a vector can be obtained by maintaining a running sum of the vector s values as they become available and dividing by a running count of the number of values recorded. Thus, recording scalars is often much more efficient in terms of disk space and disk I/O than recording vectors. Scalars are typically only of limited use when taken as individual data points. Instead, the usual practice is to combine scalars recorded over multiple simulations to form a graph or curve that indicates how a system variable varies as a function of other system parameters. Both the dependent and the independent system variables, used to generate such a graph, are recorded as scalars. For example, a typical graph generated in performance analysis is Throughput vs. Offered Load, which indicates how well a network is able to deliver the data that it is requested to 33-Ov

34 OPNET Architecture Modeling Concepts deliver, as the amount of data increases. Here the Offered Load scalar is an independent variable that is varied as an input to each simulation. Throughput is then measured over the course of the simulation, and its final value (since it is already an average) is recorded as another scalar. 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, a single value for each scalar statistic is recorded during a simulation; when many simulations are run, their scalar outputs are combined to form a graph. OPNET simulations record scalar statistics in a special type of file called an output scalar file. Unlike output vector files, these files contain the results generated by multiple simulations. Within an output scalar file, the scalars from each simulation run are kept in groups so that they can be related to each other. In other words, when Throughput is graphed against Offered Load, each point 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 diagram shows a typical plot generated from scalar values. 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 in OPNET are related to values that can be measured at specific objects within the model. This includes statistics such as queue sizes, link throughputs, error rates, and queuing delays. In 34-Ov

35 Modeling Concepts OPNET Architecture addition, it is common for models to compute application-specific statistics during a simulation and record them in scalar and/or vector output files. These statistics may be computed in a completely general manner, taking into account events that have occurred, the current state of the system, the content of packets, etc. Custom statistics may be declared by process models, in which case OPNET adds them to the set of built-in statistics of queues and processors that make use of those process models. The custom statistics can have a scope which is local 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. Modeling Overview OPNET 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. OPNET supports both local (related to an object) and global (related to overall system) application-specific statistics. Animations In addition to numerical forms of output, OPNET 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. An OPNET simulation can be configured to generate certain types of predefined animations automatically. In addition, the Animation Kernel Procedure package provides the ability to program sophisticated animations that represent simulation events in a customized manner. The kernel procedures of the Animation package include general drawing as well as OPNET-specific graphics to provide a flexible animation capability. Both automatic and custom animations can be viewed interactively during a simulation run or afterwards in a playback mode. Refer to the documentation for the Animation package Kernel Procedures in the Simulation Kernel manuals and the op_vuanim program description in the Utility Programs manual for more information on developing and viewing animations. 35-Ov

36 OPNET Architecture Modeling Concepts OPNET simulations can generate animations that are viewed during the run, or played back afterwards. Several forms of predefined or automatic animations are provided (packet flows, node movement, state transitions, and statistics). In addition, detailed, customized animations can be programmed if desired. Ov Selecting Data for Collection Because OPNET-developed models typically contain a very large number of potential statistics and animations of interest, collection mechanisms are not active by default when a simulation is executed. Instead, OPNET provides a mechanism to explicitly activate particular statistics or animations so that they will be recorded in appropriate output files. This is accomplished by specifying a list 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. In addition, more advanced forms of probes can be defined in the Probe Editor, as described later in this manual. In addition to simply enabling a statistic or animation, a probe can specify certain options that affect the manner in which data is collected. For statistics, commonly used options include restricted time-windows for data collection, onthe-fly data-reduction, and modified statistic names. For animations, probes allow specification of window geometry, as well as particular options depending on the type of animation being performed. Refer to the Simulation Design chapter of this manual for more information on probes. 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. Ov.4.4 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 scalar and output vector files, as explained earlier in this chapter. OPNET provides basic access to this data in the Project Editor and more advanced capabilities in the Analysis Tool, which is essentially a graphing and numerical processing environment. 36-Ov

37 Modeling Concepts OPNET Architecture Numerical Data Analysis Both the Project Editor and Analysis Tool allow output vector files to be selected and individual or multiple vectors to be loaded and displayed as traces.traces are ordered sets of abscissa and ordinate pairs, called entries (traces are similar in structure to vectors). In addition, scalar files can be selected and scalars from the same file can be plotted against each other to view the results of multi-simulation parametric studies. Once scalars are plotted in this manner, 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 below: Modeling Overview Scalar and Vector Data in Analysis Panels Traces are held and displayed in analysis panels, and the user can arrange any number of panels from one or more simulations as part of an analysis configuration, which can be saved as a single file. A number of display options are available to help you customize the data s presentation. These include multi-level zoom, background colors, trace colors, plotting style, and labeling. 37-Ov

38 OPNET Architecture Modeling Concepts The Analysis Tool supports display of data stored in output vector and output scalar files. Information is presented in the form of graphs, or traces. Each trace consists of a list of abscissa ( X ) and ordinate ( Y ) pairs. Traces are plotted in analysis panels. A set of analysis panels can be saved and recalled as an analysis configuration. 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: 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 The Analysis Tool is linked to the Filter Editor, which supports the use of mathematical filters to process vector or trace data. Mathematical filters are defined as hierarchical block diagrams based on a predefined set of calculus, statistical, and arithmetic operators (a typical filter is shown in the diagram below). Predefined or user-defined filters can be invoked when specifying an analysis panel and applied to combinations of data from output vector files and existing analysis panels, to generate and display new traces. 38-Ov

39 Modeling Concepts OPNET Architecture Mathematical Filter Block Diagram Modeling Overview The Analysis Tool 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. In addition, mathematical filters constructed in the Filter Editor can be invoked. Resulting data is displayed in new analysis panels. 39-Ov

40 OPNET Editors Modeling Concepts Ov.5 OPNET Editors OPNET presents its capabilities in the form of thirteen distinct environments, called editors or tools. Each editor allows you to perform some set of related OPNET functions within a window that is contained in the overall OPNET graphical environment. The following table lists OPNET s editors and identifies each one s purpose. The remainder of this section provides an overview of the capabilities of each editor in summary form. Editor Summary Name Purpose Products Project Editor Node Editor Process Editor Specify network topology and configure nodes and links. Choose results, run simulations, and view results. Create models of nodes by specifying internal structure and capabilities. Develop models of decision-making processes representing protocols, algorithms, resource managers, operating systems, etc. All Modeler Modeler Link Model Editor Create, edit, and view link models. Modeler Packet Format Editor ICI Editor Antenna Pattern Editor Modulation Curve Editor PDF Editor Probe Editor Simulation Tool Analysis Tool Filter Editor Specify packet format, defining the order, data type, and size of fields contained within the packet. Create, edit, and view interface control information (ICI) formats. Create, edit, and view antenna patterns for transmitters and receivers. Create, edit, and view modulation curves for transmitters. Create, edit, and view probability density functions (PDFs). Identify sources of statistics and animation that are to be collected during a simulation. Design and run sequences of simulations, each potentially configured with different inputs and/or outputs. Plot and process numerical data generated by simulations. Define numerical processing that can be applied to data in analysis panels. Modeler Modeler Modeler (Radio version only) Modeler (Radio version only) Modeler All All All Modeler 40-Ov

41 Modeling Concepts OPNET Editors Ov.5.1 Project Editor Summary The Project Editor is used to construct and edit the topology of a communication network model. It also provides basic simulation and analysis capabilities. The Network Domain in which the Project Editor works is the highest modeling level in OPNET in the sense that it encompasses objects that are defined in the other modeling domains. The network model therefore specifies the entire system to be simulated. This section summarizes the objects used in the Project Editor and the operations that it provides. Modeling Overview Ov Project Editor Objects A network model contains only three fundamental types of objects: subnetworks, nodes, and links. There are several varieties of nodes and links, each offering different basic capabilities. In addition, each node or link is further specialized by its model, which determines its behavior and functionality. The following table summarizes the types of objects used to build OPNET network models: Network Model Objects Object Type Definition Default Representation Fixed subnetwork Mobile subnetwork Satellite subnetwork Fixed node Mobile node Satellite node A container for additional network objects, including other subnetworks. Subnets can be nested to any depth to model complex hierarchical networks. Similar to a fixed subnetwork, except that it can physically displace itself as specified by a userdefined trajectory, or adaptively. In Radio products only. Similar to a fixed subnetwork, except that it displaces itself automatically on an assigned orbit. In Radio products only. 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. Similar to a fixed node, except that it can physically displace itself as specified by a userdefined trajectory, or adaptively. In Radio products only. Similar to a fixed communication node, except that it displaces itself automatically on an assigned orbit. In Radio products only. 41-Ov

42 OPNET Editors Modeling Concepts Network Model Objects (Cont.) Object Type Definition Default Representation Simplex point-to-point link Duplex pointto-point link Bus link Bus tap Supports uni-directional flow of packets between two fixed nodes. Supports bi-directional flow of packets between two fixed nodes. Provides broadcast connectivity for a set of fixed nodes. Nodes may transmit or packets onto the bus, receive packets from the bus, or both. Attaches fixed nodes to a bus link. Ov Project Editor Operations The Project Editor provides operations to support the creation, editing, and verification of network models. Operations related to major capabilities are summarized in the following table. For a complete listing of operations and an indepth explanation of their use, refer to the Project Editor chapter of the Editor Reference manual. Project Editor Object Palette 42-Ov

43 Modeling Concepts OPNET Editors Operation a Create objects Project Editor Operations Description 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. Modeling Overview Import topology and traffic Rapid configuration Edit object Find object Verify links Navigate networks Select map Define mobile node trajectory Collect results View results Use information from sources such as HP OpenView Network Node Manager and NetMetrix to automatically build a network model and set conversation pair traffic and link loads. 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. Right-click on an object to view or modify its attributes. Changes made to a single object can optionally be applied to an entire set of selected objects. 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. Verifies that links are connected in an appropriate manner based on node and link characteristics. Allows viewing of different subnetwork contexts by moving up or down in the network hierarchy. Displays the selected map, cropped to the borders of the current subnetwork. Maps are provided with OPNET and are based on the CIA World Data Bank. Graphically specifies the path that a mobile node will follow over time. Includes specification of time, implicitly specifying velocity. (Radio versions only) Specify the statistics to be collected and run simulations. Specify which statistics to plot, graph characteristics, and calculations to be performed. a. Operation names are not exact and may refer to several actual operations as a group. 43-Ov

44 OPNET Editors Modeling Concepts Ov.5.2 Node Editor Summary The Node Editor is used to specify the structure of device models. These device models can be instantiated as node objects in the Network Domain (such as computers, packet switches, and bridges). In addition to the structure, the node model developer defines the interface of a node model, which determines what aspects of the node model are visible to its user. This includes the attributes and statistics of the node model. This section summarizes the objects used in the Node Editor and the operations that it provides. Ov 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 briefly described in the following table. Node Model Objects Object Type Definition Default Representation Processor General purpose, programmable object whose behavior is specified by a process model. Generator Queue Transmitter Receiver Packet Stream Simple packet source using probability distributions to control time intervals separating arrivals as well as size of packets. 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. Allows packets to be sent outside of the node s boundary via attached links. Three types of transmitters correspond to supported link types: point-to-point, bus, and (in Radio versions) radio. Allows packets to be received from other nodes via attached links. Same types as transmitters above. 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. 44-Ov

45 Modeling Concepts OPNET Editors Statistic Wire Node Model Objects (Cont.) Object Type Definition Default Representation 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. Modeling Overview Logical Association Indicates a coupling between two modules. Currently supported for appropriate transmitterreceiver pairs only in order to specify that they be kept together when attaching the node to a link. Ov Node Editor Operations The Node Editor provides operations to support the creation and editing of node models. Operations related to major capabilities are summarized in the following table. For a complete listing of operations and an in-depth explanation of their usage, please refer to the Node Editor chapter of the Editor Reference manual. Node Editor Operations Operation a Create object Edit object Edit model attributes Description Individual operations are provided to support the graphical creation of each type of object listed in the previous table. Right-click on an object to view or modify its attributes. Changes made to a single object can optionally be applied to an entire set of selected objects. 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. 45-Ov

46 OPNET Editors Modeling Concepts Node Editor Operations (Cont.) Operation a Edit model attribute interfaces Promote node statistics Description 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. 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. a. Operation names are not exact and may refer to several actual operations as a group. Ov.5.3 Process Editor Summary The Process Editor is used to specify the behavior of process models. Process models are instantiated as processes in the Node Domain and exist within processor, queue, and esys modules. Processes can be independently executing threads of control that perform general communications and data processing functions. They can represent functionality that would be implemented both in hardware and in software. In addition to the behavior of a process, the process model developer defines the 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. Ov Process Editor Objects Process models use a finite state machine (FSM) paradigm to express behavior that depends on current state and new stimuli. FSMs are represented using a state transition diagram (STD) notation. The states of the process and the transitions between them are depicted as graphical objects. The objects used to build process models are briefly described in the following table. 46-Ov

47 Modeling Concepts OPNET Editors 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. Modeling Overview Transition Model-level information blocks 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. 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. Ov Process Editor Operations The Process Editor provides operations to support the creation and editing of process models. Operations related to major capabilities are summarized in the following table. For a complete listing of operations and an in-depth explanation of their usage, please refer to the Process Editor chapter of the Editor Reference manual. 47-Ov

48 OPNET Editors Modeling Concepts Process Editor Operations Operation a Create object Edit object Set initial state Edit model attributes Edit simulation attributes Edit model attribute interfaces Edit statistics Declare external object files Compile process model Description Individual operations are provided to support the graphical creation of states and transitions. Right-click on an object to view or modify its attributes. Changes made to a single object can optionally be applied to an entire set of selected objects. For states, this operation provides access to enter and exit executive code blocks, as well as other attributes. For transitions, it includes access to condition and executive statements. Designates a particular state as the state where a process should begin execution when it is created. 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. 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. Process models contain no objects with promotable attributes. Only model attributes may be promoted. However this operation is still useful to control attributes that are intrinsic to the processor or queue that receives the process model. For example, the process model can dictate how many subqueues the queue should contain. This operation also hides unnecessary attributes of the modules. 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. 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. 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. 48-Ov

49 Modeling Concepts OPNET Editors Ov.5.4 a. Operation names are not exact and may refer to several actual operations as a group. Packet Format Editor Summary 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. Modeling Overview Ov 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. Packet Format Objects Object Type Packet field Definition The packet field object represents a single field in a packet format. You can specify such attributes as the field s name, data type, size in bits, default value, and color. Representation Ov 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. For a complete listing of operations and an in-depth explanation of their usage, refer to the Packet Editor chapter of the Editor Reference manual. 49-Ov

50 OPNET Editors Modeling Concepts Packet Format Editor Operations Operation Create new field Edit field attributes Edit packet attributes Description Create graphical representations of new fields and place them in the workspace. View or modify a field s attributes. Changes made to a single field can optionally be applied to an entire set of selected fields. View or modify attributes pertaining to the entire packet. Ov.5.5 Parameter Editors Summary The Link Model Editor, ICI Editor, Antenna Pattern Editor, Modulation Curve Editor, and PDF Editor are used to specify a single type of model. Collectively, these types of models are referred to as parameter models because they are mainly used as assignments for complex attributes (that is, parameters) of objects. Parameter Model Types Link Model Interface Control Information Format (ICI) Antenna Pattern Modulation Curve 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. For more indepth information on each of these models, refer to later sections of this manual and to the corresponding chapters of the Editor Reference manual. 50-Ov

51 Modeling Concepts OPNET Editors PDF Models Modeling Overview PDF of a continuous random variable, containing no impulses PDF of a discrete random variable, implemented using impulses Ov Parameter Model Descriptions The following table briefly discusses each of the parameter model types and their applications. Parameter Models Model Type Editing Method Description Link model dialog box An OPNET link model represents a class of link objects that can be instantiated in a network model. It defines attribute interfaces for point-to-point and bus links. Each link attribute can be set in advance to appropriate values, and if necessary hidden from view. Interface control information (ICI) Antenna pattern dialog box graphical 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. An OPNET antenna pattern is a three-dimensional table that maps direction angles phi and theta into antenna gain values. This table is used to characterize the effect of antenna patterns on radio link performance. Antenna patterns may be assigned to antenna modules in a node model. The pattern is accessed by the underlying link models in order to obtain accurate estimates of antenna gain for each radio transmission (Radio version only). 51-Ov

52 OPNET Editors Modeling Concepts Model Type Modulation curve Probability density function (PDF) Editing Method graphical graphical Parameter Models (Cont.) Description An OPNET modulation is a mapping between effective signal-to-noise ratio (E b /N 0 ) values measured on a radio communications link, and the expected value of the bit error rate (BER) that would result. Modulations are assigned to radio transmitter and radio receiver modules. Their contents are typically accessed by the underlying link models (Radio version only). A PDF is a mapping of real values of a random variable to their associated probability densities. PDFs are used to assign values to the various distribution attributes of generator modules. They are also commonly used to generate random variable values within process models (e.g., to implement random time-out intervals for retransmissions, or choose random destinations for packets). Ov.5.6 Probe Editor Summary 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, OPNET 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. Ov 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 briefly describes each type of probe. For more detailed information on probes, refer to the Simulation Design chapter of this manual. 52-Ov

53 Modeling Concepts OPNET Editors 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. Modeling Overview Link statistic Global statistic Simulation attribute Automatic animation Custom animation Applies to a link object at the network level. Links generate only built-in statistics (computed by OPNET). Collects statistic values from multiple objects located anywhere in the network. The name of the statistic serves as a rendezvous point for the sources. 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. 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. 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 Analysis Tool. Axes rescale automatically to track changes. Ov.5.7 Simulation Tool Summary OPNET simulations are ordinary programs that may be executed from the command line if desired. However, the Simulation Tool provides an often more convenient environment for configuring and running a simulation or group of simulations. 53-Ov

54 OPNET Editors Modeling Concepts The Simulation Tool allows any number of separate simulation runs of various models to be specified as simulation objects represented by icons. The attributes for each simulation object are specified in a dialog box. Simulation Object and Dialog Box The collection of simulation objects and associated configuration information is referred to as a simulation sequence. The Simulation Tool allows an entire sequence to be run unattended. A simulation sequence consists of any number of simulation objects. Each object specifies a network model that is to be simulated and values for attributes. One or more simulation runs could result for each object, depending on possible combinations of attribute values. The sequence of simulation runs can be executed unattended. For each simulation object, a number of standard attributes are presented in the dialog box. The primary attributes are summarized in the following table. Simulation Object Attributes Attribute Network Probe file Vector file Description Name of network model to be simulated. Name of probe list specifying output data to be collected. Name of file that will store output vectors that simulation generates. 54-Ov

55 Modeling Concepts OPNET Editors Attribute Scalar file Seed Simulation Object Attributes (Cont.) Description Name of file that will store output scalars that simulation generates. Value of random seed for OPNET s built-in random number generator. Vary this seed on different simulations to achieve desired statistical confidence in results. Modeling Overview Duration Applicationspecific Maximum duration of the simulation (in simulated seconds). Attributes promoted by the objects of the network model, or simulation attributes declared by process models. Ov.5.8 Analysis Tool Summary OPNET simulations store statistical data in two types of files, called output vector and output scalar files. Output vector files contain dynamic time-series data showing how quantities change over time during a single simulation run. In an output scalar file, each variable is usually represented once per simulation. The tool provided by OPNET for advanced processing of both types of simulation output is called the Analysis Tool. In the Analysis Tool, users work with two types of objects, called analysis panels and graphs. Each analysis panel can contain one or more graphs, and a graph shows one or more statistics, or traces. All graphs in the same panel must share the same horizontal axis, but they may each have separate vertical axes. Traces are obtained from output vectors directly, or by plotting two scalar statistics one against the other. They may also result from numerical processing or be copies of other traces. The following tables enumerate the major attributes that can be controlled for graphs and panels, respectively. Trace and Graph Attributes Attribute draw style line thickness trace color confidence interval vertical label Description Choose from linear, discrete, bar, bar chart, sample-hold, and square-wave (see following figure). Choose from dashed, thin, medium, and thick (see following figure). Choose from 64 colors for each trace in the graph. For each trace in the graph, disable or enable confidence intervals and choose from five standard confidence levels. Specify label that appears for each trace on the vertical axis. 55-Ov

56 OPNET Editors Modeling Concepts Draw Styles 56-Ov