1501 - Introduction To Process Modeling Methodology

Session 1501
Introduction to
Process Modeling Methodology
R&D Solutions for Commercial and Defense Networks
CONFIDENTIAL RESTRICTED ACCESS: This information may not be disclosed, copied, or transmitted in any
CONFIDENTIAL format
RESTRICTED
ACCESS:
This information
may not Technologies,
be disclosed, copied,
or transmitted in any
without the
prior written
consent of OPNET
Inc.
format without
the
priorOPNET
written Technologies,
consent of OPNET
2007
Inc. Technologies, Inc.
2010 OPNET Technologies, Inc.
1501 Introduction to Process Modeling Methodology
What Are We Going To Learn?
CONFIDENTIAL RESTRICTED ACCESS: This information may not be disclosed, copied, or transmitted in any format without the prior written consent of OPNET Technologies, Inc. 2010 OPNET Technologies, Inc.
Agenda
Introduction / motivation
Process Modeling Methodology explained through an example
Lab for students to apply the methodology (lab 1)
Dynamic processes
Introduction
Process life cycle
Lab 2
Interrupt steering
Process communication
Lab 3
Debugging processes in ODB

Conclusion
Agenda
Dynamic processes
Introduction
Process life cycle
Lab 2
Interrupt steering
Lab 3

Conclusion
Introduction
What is the Process Modeling Methodology (PMM)?
A systematic approach to creating process models in OPNET Modeler

Quickest, most efficient method of development
Protection from some common pitfalls
Produces consistent results
Indispensable for larger models
But first
What is a Process Model?
OPNET Environment
Process
model is the
heart of
custom
simulation
development
Comparing Approaches
Flower Petal - tcp_manager_v3
PMM - tcp_conn_v3
Both of these are parts of the standard OPNET TCP model
Process Model Dynamics
init
msg1
INITIALIZED
MSG1
connect
CONNECTED
FAIL
RECOVER
register
REGISTERED
MSG2
wait
msg2
FAIL
FAIL
fail
MSG3
msg3
Beginners
avoid RED
states, but
they are very
important!
States, Events, and Actions

Important
definitions
State
Event
Alarm
Action
State
Wakeup
asleep
awake
Stimulus
to move
system
Condition
of system
0:00
Time progresses
6:00
Response of
system to
stimulus
Instantaneous
Condition
of system
6:00
Time progresses
8:00
9
Motivation
PMM helps the user over many common pitfalls
Gets you past the initial blank screen
Where do I even begin?
Reveals unexpected relationships
Oh yeah... I guess that CAN happen.
Avoids painting yourself into a corner
I have to start from scratch. There goes 40 hours of my life.

PMM is your roadmap
to process model
development success
10
Steps for Building a Process Model

Obtain protocol specification
Design using the methodology
Review the design
Implement in OPNET
11
Process Modeling Methodology Stages

First four stages: Design
Stage 1: Context definition

Stage 2: Process level decomposition
Stage 3: Enumeration of events (per process)
Stage 4: Event Response Table development (per process)
1
2
3
This is an iterative stage and is the meat of process model

methodology
Last stage: Implementation in OPNET
Stage 5: Specification of process actions (per process)
12
Agenda
Dynamic processes
Introduction
Process life cycle
Lab 2
Interrupt steering
Lab 3

Conclusion
13
Process Modeling Methodology Example 1:

Stop-and-Wait Retransmission Protocol
Protocol for the Data Link Layer at the sending side only
Basic functionality: Provide reliable communications over a lossy
channel
Accept frames from the upper layer and send them to the physical
layer
14
Process Modeling Methodology Example 1:

Protocol Requirements
Amalgamated Communications Kompany (ACK) C. R. Ash
SWaRe Protocol Version 1.3.X
Aug 23, 2005 Proprietary
Receive frames from higher layer
Transmit frame over physical layer
Must receive an acknowledgment before sending
the next frame
Queue frames arriving from the higher layer
if the process is waiting for acknowledgment
for a previous frame
Retransmit the frame if an acknowledgment is
not received before the end of a timeout
period
When the link fails, frames cannot be sent or
retransmitted until the link recovers
Marketing
Sales
Simulation
15
Just for Fun
How many lines of

OPNET code are
needed to model
this protocol?
16
Stage 1: Context Definition

Fit this piece into the big picture:
Step 1: Identify interdependent modules
Step 2: Select communication mechanisms with
interdependent modules
Step 3: Develop diagram of system and interdependent
modules
1
2
3
17
Stage 1: Context Definition (cont.)

1
2
3
Higher Layer
Frames for Transmission
SWaRe Protocol
Transmitted Frames
Acknowledgements
Physical Layer
18
Stage 2: Process-Level Decomposition

Step 1: Determine which process model decomposition
technique is applicable to the system
Single process model

Multiple (parent-child) process models
Step 2: If a multi-process implementation is chosen, identify

the areas of responsibility assigned to each process
Step 3: For multi-process implementations, determine
circumstances of process creation and which process will be
the root
1
2
3
19
Stage 2: Process-Level Decomposition (cont.)

Use a single process for this example
1
2
3
20
Stage 3: Enumeration of Events

Step 1: Define logical events of each process
Step 2: Select event implementation methods
1
2
3
Frames for Transmission
Ack timeout
SWaRe Protocol
!
!
System Link Fail

System Link Up
Acknowledgements
21
Stage 3: Enumeration of Events (cont.)

Event Name
Event Description
Interrupt Type
1
2
3
22
Stage 3: Enumeration of Events (cont.)

Event Name
!
!
Event Description
Interrupt Type
Frame Arrival
A frame has arrived

from the higher level.
Stream
Timeout
The retransmission
timer has expired.
Self
1
2
3
Acknowledgement
Received
An acknowledgement Stream
for the last transmitted
frame has been
received.
Link Fail
The link has failed.
Failure
Link Up
The link has

recovered.
Recovery
Power Up
The process starts.
Begin Simulation
23
Stage 4: Event Response Table Development

The Event Response Table specifies how the model reacts to
various events, depending upon the state of the model
State
Event
Condition
Action
1
2
3
Final State
The events and actions are indicated in the specification

What are the conditions?
What are the states?
24
Conditions
State
Event
Condition
Action
State
25
Stage 4: Event Response Table

Development Identifying States
A state
Represents a blocking point of the process

Corresponds to particular sequences of events having occurred
Reacts to events in a specific manner
Is mutually exclusive of and complementary to other states
Problem:
Typically we do not know all possible states of the system at this
1
2
3
point in the design process
Solution:
Start with an initial state and walk through the model
26
Stage 4: Event Response Table Development:

Iteration Plan Start With Initial State
Step 1: Choose a state
Step 2: Choose an event
Step 3: Choose a condition under which the event occurs
Step 4: Determine all actions to perform
Step 5: Determine the final state
Loop Step 3 for all conditions
Loop Step 2 for all events
Loop Step 1 until all states are complete
State
Event
Condition Action
Final State
1
2
3
Init
27

Initial State
Using a BEGINSIM
interrupt assures that the
Init state will not have to
handle any other type of
event
State
Event
Init
Frame Arrival
1
2
3
Condition Action Final State

4
Timeout
Acknowledgement
Received
Link Fail
Link Up
Power Up
Always
None
Idle
28

Idle State
Specify actions
down to the KP
level
State
Event
Init
Power Up
Idle
Power Up
Frame Arrival
Condition
Found
Foundnew
newstates
states
Action
Final State
Always
None
Idle
Always
Copy frame
Send frame
Set timer
ACK Wait
1
2
3
Timeout
Acknowledgement
Received
Link Fail
Always
None
Link Down
Link Up
29

Two New States
State
Event
Init
Power Up
Condition
Action
Always
None
Idle
Always
Frame Arrival
Link Fail
Always
Final State
Idle
Copy frame ACK Wait

Send frame
Set timer
None
Link Down
ACK
Wait
Link
Down
1
2
3
30

ACK Wait State
State
ACK
Wait
Event
Condition
Action
Final State
Frame Arrival
Always
Queue frame
ACK Wait
Timeout
Always
Copy frame
Send frame
Set timer
ACK Wait
Acknowledgement
Received
Queue
Empty
Queue
Occupied
Cancel timer
Destroy copy
Cancel timer
Destroy copy
Pop queue
Copy frame
Send frame
Set timer
Idle
Link Fail
Always
None
1
2
3
ACK Wait
ACK Wait and

Link Down
Link Up
31

Link Down State
State
Link
Down
Event
Frame Arrival
Condition
Always
Action
Final State
Queue frame Link Down
1
2
3
Timeout
Acknowledgement
Received
Link Fail
Link Up
Queue
Empty
None
Idle
Queue
Occupied
Pop queue
Copy frame
Send frame
Set timer
ACK Wait
32

ACK Wait and Link Down State
State
ACK
Wait and
Link
Down
Event
Frame Arrival
Timeout
Condition
Action
Final State
ACK Wait and
Link Down
Always
Queue frame
Always
Set retransmit ACK Wait and

flag
Link Down
Acknowledgement
Received
1
2
3
Link Fail
Link Up
Often, designing
the model helps
flush out the
design of the real
system
Retransmit
Flag
No Retrans
Flag
Reset flag
Copy frame
Send frame
Set timer
None
ACK Wait
ACK Wait
33
Stage 5: Specification of Process Actions

Step 1: Review specification of the process logical actions
for completeness
Step 2: Implement STD in OPNET
Step 3: Define or replace macros and pseudo-code
1
2
3
34

Step 2 Implement STD in OPNET
Placing Actions in the STD
Actions can be contained in three different places
Leaving the current state: Exit Executives

Going from one state to the next: Transition Executives
Entering the new state: Enter Executives
1
2
3
state1
PK_ARRIVAL/sample_function_call();
state2
35

Placing Actions in the STD (cont.)
Exit Executive contains actions

common to all outgoing transitions
Enter Executive contains actions
common to all incoming transitions
Transition Executive contains actions
associated with a specific transition
1
2
3
state1
4
state2
Recommendation: Start by placing all

actions in transition executives
Later, actions common to all outputs or

inputs can be placed in exit or enter
executives
state1
state2
5
36

Placing Actions in the STD (cont.)
1
2
3
Green states as code holders
state1
trans
state2
4
RED states are

true states of the
system.
GREEN states
are for coding
convenience
37

Step 2 Implement STD in OPNET (cont.)
1
2
3
State
Init
Event
Power Up
Condition
Always
Action
None
Final State
Idle
38

State
Idle
Event
Frame Arrival
Link Fail
Condition
Always
Always
Action
Copy frame
Send frame
Set timer
None
Final State
1
2
3
ACK Wait
Link Down
39

State
Event
ACK
Wait
Frame Arrival
Always
Queue frame
ACK Wait
Timeout
Always
Copy frame
Send frame
Set timer
ACK Wait
Acknowledgement
Received
Queue Empty
Cancel timer
Destroy copy
Idle
Queue Occupied
Cancel timer
Destroy copy
Pop queue
Copy frame
Send frame
Set timer
ACK Wait
None
ACK Wait and

Link Down
Link Fail
Condition
Always
Action
Final State
1
2
3
40

State
Link Down
ACK Wait and

Link Down
Event
Condition
Action
Queue frame
Final State
Frame
Arrival
Always
Link Down
Link Up
Queue Empty
None
Idle
Queue
Occupied
Pop queue
Copy frame
Send frame
Set timer
ACK Wait
Frame
Arrival
Always
Queue frame
ACK Wait and

Link Down
Timeout
Always
Set retransmit flag
ACK Wait and

Link Down
Link Up
Retransmit flag
Copy frame
Send frame
Set timer
ACK Wait
No Retrans flag
None
ACK Wait
1
2
3
41

Alternate solution: Using forced states
QFrame2
QFrame3
QFrame1
42

Step 3 Define/Replace Macros & Pseudo-Code
Define macros in header block:

#define PowerUp
(op_intrpt_type() == OPC_INTRPT_BEGSIM)
#define FrameArrival (op_intrpt_type() == OPC_INTRPT_STRM && \

op_intrpt_strm() == StreamFromApp)
#define Timeout
(op_intrpt_type() == OPC_INTRPT_SELF)
#define ACK
(op_intrpt_type() == OPC_INTRPT_STRM && \

op_intrpt_strm() == StreamFromLink)
#define LinkFail
(op_intrpt_type() == OPC_INTRPT_FAIL)
#define LinkUp
(op_intrpt_type() == OPC_INTRPT_RECOVER)
#define QEmpty
(op_subq_stat(0, OPC_QSTAT_PKSIZE) == 0.0)
Enable Begin Simulation Interrupt

Define state variables
Write functions
43
Step 3 Define/Replace Macros & Pseudo-Code (cont.)
Write functions in function block

void QFrame()
{
op_subq_pk_insert (0, op_pk_get(op_intrpt_strm()), OPC_QPOS_TAIL);
}
void SendFrame()
{
send (op_pk_get (op_intrpt_strm()));
}
void ResendFrame()
{
send (copyPkt);
}
void ProcAck()
{
op_ev_cancel (ackEvent);
op_pk_destroy (copyPkt);
}
44
Step 3 Define/Replace Macros & Pseudo-Code (cont.)

Write functions in function block
void SendNext()
{
send (op_subq_pk_remove (0, OPC_QPOS_HEAD));
}
void SetRetrans()
{
retransFlag = 1;
}
void RetransIfFlagSet()
{
if (retransFlag) ResendFrame();
retransFlag = 0;
}
Only
27
lines of code!
void send (Packet* aPkt)

{
copyPkt = op_pk_copy (aPkt);
op_pk_send (aPkt, StreamToLink);
ackEvent = op_intrpt_schedule_self (op_sim_time() + ackDelay, 0);
}
45
Agenda
Dynamic processes
Introduction
Process life cycle
Lab 2
Interrupt steering
Lab 3

Conclusion
46
Lab 1: Using the Methodology

You are provided with a specification for a protocol
Implement it using the Process Modeling Methodology
Blank forms are provided to assist you
There may be many correct solutions
Feel free to ask TAs for help
47
Solution for Lab 1

The following slides present one possible solution for all stages of the
methodology
48
Stage 1: Context Definition
Traffic Source
Packet Arrival
CSMA Protocol
Send Packet
Medium Busy/Not Busy
Physical Medium
49
Stage 2: Process-Level Decomposition

Use a single process for this example
50
Stage 3: Enumeration of Events
Event Name
Event Description
Interrupt Type
Power Up
Initialize CSMA
Begin Sim
Packet Arrival
A packet has arrived

from the source
Stream
Medium Free
The transmission
medium has changed
from busy to free
Stat
Backoff Over
Time to send a packet
Self
NOTE:
NOTE:We
Wedo
donot
notneed
needan
anevent
eventfor
forMedium
MediumBusy
Busy
51
Found
Foundnew
newstates
states
State
Event
Condition
Action
Final State
Init
Power Up
Always
None
Idle
Idle
Packet
Arrival
Medium not
Busy
Send packet
Idle
Medium
Busy
Queue
packet
MediumIsBusy
None
Idle
Medium Free Always

Backoff Over
NOTE:
NOTE:Medium
MediumFree
Freeisisan
anEVENT
EVENT
Medium
MediumBusy
Busyisisaastatus
statusthat
thatwe
wecheck
check
52

Development (cont.)
Found
Foundnew
newstate
state
State
Event
MediumIsBusy Packet
Arrival
Medium
Free
Condition
Action
Final State
Always
Queue Packet MediumIsBusy
Always
Start Backoff BackOff
Backoff
Over
53

Development (cont.)
No
Nomore
morenew
newstates!
states!
State
Event
BackOff Packet
Arrival
Condition
Always
Medium Always
Free
Action
Final State
Queue Packet
BackOff
None
BackOff
Backoff Medium Busy

None
Over
Medium is not Busy Send Packet
& only one packet
MediumIsBusy
Idle
Medium is not Busy Send first packet BackOff

& multiple packets Start Backoff
54

55

Step 3 Define/Replace Macros & Pseudo-Code
56
Summary Process Modeling Methodology

What is a Process Modeling Methodology?
Systematic approach to creating process models in OPNET Modeler

Quickest, most efficient method of development
Protection from some common pitfalls
What are the advantages? Why use this methodology?
Universal approach eliminates hesitation in model design

Front-end design effort will decrease implementation time
Possible reduction in lines of code
Uniformly designed process models
Behavior easy to visualize
57
Agenda
Dynamic processes
Introduction
Process life cycle
Lab 2
Interrupt steering
Lab 3

Conclusion
58
Introduction
What is a Dynamic Process?
Process that can be dynamically created and destroyed

during the course of a simulation
When are they used?
Reducing complexity in a module

One module performs several distinct tasks
Different processing phases for information
Variable number of interactions
A module needs to monitor many queues
Server communicating with several clients at once
59
Example Process Models

Both of these are parts of the standard OPNET TCP model
Perfect example of dynamic processes at work
Manager spawns tcp_conn_v3 children for each TCP connection

spawn
invoke
tcp_manager_v3
tcp_conn_v3
60
Motivation
Modular organization (decomposition)
Each process performs a specific task

Design several simple process models rather than one complex model
With identical input/output requirements, child processes can be
interchangeable
Core concept behind scalable modeling techniques
Imitates real world system designs

Easier to create and maintain
61
Terminology
Root process
The single process initially present within each module at the node level
Child process
Additional processes created within the module during simulation

May be created by the root process or other child processes
Parent process
The process that created a given child process

The root process has no parent
Process group
The collection of all processes within a module
62
Illustration of Process Hierarchy

The entire process group
runs within a single
module
Process Group
Root process
The number
of generations
is not limited,
but typically
only one or
two are used
First-generation
child processes
Second-generation
child processes
The number of child processes

at any level can scale
dynamically as needed
The models at any level do not

all have to be the same
63
OPNET Configuration:
Declaring Child Processes
Create the child process models
Open the parent process in the Process Editor
Choose File > Declare Child Process Models
Select the child process models
64
Model Attributes of Child Processes

Parent and child process model attributes are merged together in the
module (viewed with Edit Attributes)
Child process attributes are prefixed by the child model name
All instances of a child process model within a module have the same
attributes and values
Child process model attributes are not used often
Usually the parent passes state to each child upon creation
65
Agenda
Dynamic processes
Introduction
Process life cycle
Lab 2
Interrupt steering
Lab 3

Conclusion
66
Process Lifecycle
Process creation
Process invocation
Process destruction
67
Process Creation
op_pro_create (model_name, ptc_mem_ptr)
Creates a new process as an instance of the specified process model,
associating it with a module
Allows for the installation of parent-to-child shared memory
Returns a process handle
Dont put .pr.m
EXAMPLE:
Prohandle aChildProc;
MY_STRUCT* someData;
aChildProc = op_pro_create ("childProcModel", someData);
68
Process Creation (cont.)

Child process shares all module resources
Subqueues
Packet streams
Statistic wires
Statistic declarations
Run-time efficiency
Logical simulation construct

Not a separate OS process or thread
Tests show creation of child process is about the same as 10 empty events
Minor performance hit for great simulation flexibility and modularity
69
Process Invocation
op_pro_invoke (pro_handle, arg_mem_ptr)
Invokes a process in the context of the current event and current module
The invoked process reacts as if it received an event
Information can be passed in argument memory
The originating process is suspended until this KP returns
Analogous to a C function call
Caller blocks until the callee finishes executing
Invoked process can further invoke other processes
EXAMPLE:
Prohandle aChildProc;
MY_STRUCT* someData;
MY_OTHER_STRUCT* someOtherData;
aChildProc = op_pro_create ("childProcModel", someData);
op_pro_invoke (aChildProc, someOtherData);
70
Process Invocation (cont.)

To the invoked process, an invocation is treated just like an interrupt
Starts at an unforced (red) state

Execution continues until the next unforced (red) state
Control is passed back to the invoking process
Can ONLY be used to invoke a process in the same module

Circular (recursive) invocations are not allowed
Trapped by Simulation Kernel
71
Process Destruction
op_pro_destroy (pro_handle)
op_pro_destroy_options (pro_handle, options)
OPC_PRO_DESTROY_OPT_KEEP_EVENTS or
OPC_PRO_DESTROY_OPT_NONE
Process destruction
Deletes a dynamically created process

Invokes the Termination Block
Good place to clean up dynamic memory allocated by child process

Good place to destroy any child processes
ONLY time Termination Block is invoked (not used in root processes)
72
Process Destruction (cont.)

Processes can destroy themselves
The root process cannot be destroyed
Any process in the current invocation stack cannot be destroyed
73
Lab 2: Using Child Processes

Module in node has multiple incoming packet streams
Monitor the multiple packet streams using process groups
Initially all packets are handled by the root process
Create child processes to handle packets from streams
Root
Children
74
Agenda
Dynamic processes
Introduction
Process life cycle
Lab 2
Interrupt steering
Lab 3

Conclusion
75
Interrupt Steering
Specifying which process within a module receives a given interrupt
Four mechanisms:
Manual
Normal
Type-based
Port-based
76
Manual Steering
Root process receives control (by default)
Invokes appropriate child
Blocks till child returns
Simulation
Kernel
interrupt
Root
op_pro_invoke()
Children
77
Normal Steering
op_intrpt_schedule_self (time, code)
Simulation
Kernel
2)self interrupt
Root
1) op_intrpt_schedule_self()
Children
Simulation kernel automatically invokes correct child

78
Normal Steering (cont.)

op_intrpt_schedule_process (pro_handle, time, code)
2)interrupt
Simulation
Kernel
Root
Any process can schedule

any other process using
op_intrpt_schedule_process.
1) op_intrpt_schedule_process()
Children
Simulation kernel automatically invokes correct child

79
Type-Based Steering
Causes all interrupts of a certain type that are sent to a module to be
received by the specified process
op_intrpt_type_register (type, pro_handle)
Simulation
Kernel
all failure interrupts
Root
Children
op_intrpt_type_register(OPC_INTRPT_FAIL, ...)
80
Port-Based Steering
op_intrpt_port_register (type, index, pro_handle)
stream and statistic interrupts

Takes precedence over type registration
stream 0 interrupts
Simulation
Kernel
other stream interrupts
Root
Children
op_intrpt_port_register(OPC_PORT_TYPE_STRM, 0, ...)
81
Interrupt Deregistration
Type-based
Re-register root process (or any other process)
Port-based
op_intrpt_port_deregister (port_type, port_index)
Calling op_intrpt_port_register() on a new process handle deregisters the old

handle and registers the new one
82
Direct and Indirect Invocation

Identify the direct or indirect invocation using
op_pro_invoker (pro_handle, invmode_ptr)
Example (Case A):
Port-based steering to child

OPC_PROINV_DIRECT returned (to *invmode_ptr)
Simulation
Kernel
Incoming packets:
Cause STREAM
interrupts
Root
Child
83
Direct and Indirect Invocation (cont.)

Example (Case B):
Root process invokes child process after receiving packets

OPC_PROINV_INDIRECT returned from op_pro_invoker()
Incoming packets:
Cause STREAM
interrupts
Simulation
Kernel
Root
Child
84
Agenda
Dynamic processes
Introduction
Process life cycle
Lab 2
Interrupt steering
Lab 3

Conclusion
85
Process Communication
Shared process memory
Module-wide memory
Parent-to-child memory
Argument memory
86
Module-Wide Memory
Establish
Access
op_pro_modmem_install (mem_ptr)
op_pro_modmem_access()
modmem
87
Parent-to-Child Memory
Establish
Access
op_pro_create (model_name, ptc_mem_ptr)

op_pro_parmem_access()
pm
You do not have to

create Parent-Child
memory
pm
pm
pm
pm
88
Argument Memory
Establish
Access
op_pro_invoke (pro_handle, argmem_ptr)

op_pro_argmem_access()
op_pro_invoke()
am
89
Additional Data Sharing Concepts

Applicable in general not just to child processes
Get state variables from another process
op_ima_obj_svar_get (Objid, Svar_Name)

op_pro_svar_get (pro_handle, Svar_Name)
For root process
Global registry
oms_pr_process_register ()
oms_pr_attr_set ()
oms_pr_process_discover ()
oms_pr_attr_get ()
May be slow
ICIs
op_ici_create ()
op_ici_attr_set ()
op_ici_attr_get ()
General scope options
Header block variables

Header file variables
90
Lab 3: Interrupt Steering and Process

Communication
Stream interrupts steered to appropriate child processes
Port-based steering is used:
Root process requires no processing to be done with incoming packets

Therefore packets can be directly steered to child process
All incoming packets generate stream interrupts, so type-based registering is
not sufficient
Communication between the root and child processes

Module-wide memory holding dimensioned statistic handles
Use of oms_dim_stat package for statistic reporting
91
Summary Dynamic Processes

Modules can contain more than one process
Benefits include scalability and modularity
Processes can be created and destroyed during runtime
Interrupts can be steered to an appropriate process
Processes communicate using shared memory
92
Agenda
Dynamic processes
Introduction
Process life cycle
Lab 2
Interrupt steering
Lab 3

Conclusion
93
Debugging Processes in the OPNET

Debugger (ODB)
Locating processes
Controlling processes
Tracing processes
Displaying process state
94
Locating Processes in ODB

promap <objref>
Displays a list of the processes associated with a specified module in ODB

Use promap all to list all existing processes
Use hierarchical network tree view of ODB

Process tags
Strings used to distinguish one process from others of the same type within the
same module when using the promap command
Set with op_pro_tag_set (pro_handle, tag_string)
95
Controlling Processes in ODB

prostop <proc_id>
Enables a breakpoint for all invocations of the specified process

Can be also done in the graphical tree view by right-clicking on the process of
interest and selecting Break On Any Event For This Process
op_prg_odb_bkpt (label)
Defines a breakpoint that occurs if the simulation is running under ODB

control
Labeled breakpoint must also be enabled
prolstop <proc_id> <label>
Enables a labeled breakpoint in the specified process

96
Tracing Processes in ODB

protrace <proc_id>
Enables full trace for the specified process

Can be also done in the graphical tree view by right-clicking on the process of
interest and selecting Trace This Process
op_prg_odb_ltrace_active (label)
Used to determine if the specified labeled trace has been activated by an ODB
command
proltrace <proc_id> <label>
Enables a trace for the specified label restricted to the specified process
97
Displaying Process State

Diagnostic Block
Contains C or C++ language statements that send diagnostic information to the

standard output device
prodiag <proc_id>
Executes diagnostic block of the specified process
proldiag <proc_id> <label>
Executes diagnostic block of the specified process and sets a trace for the
specified label for that execution only
Use op_prg_odb_ltrace_active() to control output
98
Homework Lab: Debugging Dynamic

Processes
Use ODB commands to debug dynamic processes
The lab will use ODB to:
Observe the creation of the child processes

Observe the child processes handling packets
Observe the state of a child process after it has handled 50 packets
99
Agenda
Dynamic processes
Introduction
Process life cycle
Lab 2
Interrupt steering
Lab 3

Conclusion
100
Documentation References
Modeling Concepts Reference Manual
Modeling Overview chapter (overview)

Process Domain chapter (concepts)
~120 pages about the Process Domain that everyone in this class should
read
In particular, Process Model Development Methodology section
Good review and reference
Provides 4 examples
Discrete Event Simulation API Reference Manual (KP reference)
Interrupt Package chapter

Programming Package chapter, ODB Sub-Package section
Process Package chapter
External Interfaces Reference Manual
Simulation Execution chapter (ODB reference)
101
Related OPNETWORK Sessions

Session 1572: Introduction to OPNET Modeler
Session 1502: Debugging Simulation Models Introduction
Session 1503: Debugging Simulation Models Advanced
Session 1530: Modeling Custom Wireless Effects Introduction
Session 1550: Accelerating Simulations Using Efficient Modeling
Techniques
102
Take-Away Points
The Process Modeling Methodology can help organizing the
development of complex models
Dont be afraid of red states
Using dynamic child processes can be a natural way of representing
scalable systems
Next steps: use the methodology to create your own process models!
103

1501 - Introduction To Process Modeling Methodology

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

1501 - Introduction To Process Modeling Methodology

Enviado por

Direitos autorais:

Formatos disponíveis

Session 1501

1501 Introduction to Process Modeling Methodology

What Are We Going To Learn?

1501 Introduction to Process Modeling Methodology

Lab for students to apply the methodology (lab 1)

Debugging processes in ODB

1501 Introduction to Process Modeling Methodology

Lab for students to apply the methodology (lab 1)

Debugging processes in ODB

1501 Introduction to Process Modeling Methodology

A systematic approach to creating process models in OPNET Modeler

What is a Process Model?

1501 Introduction to Process Modeling Methodology

1501 Introduction to Process Modeling Methodology

Flower Petal - tcp_manager_v3

Both of these are parts of the standard OPNET TCP model

1501 Introduction to Process Modeling Methodology

Process Model Dynamics

1501 Introduction to Process Modeling Methodology

States, Events, and Actions

1501 Introduction to Process Modeling Methodology

Where do I even begin?

Reveals unexpected relationships

Oh yeah... I guess that CAN happen.

Avoids painting yourself into a corner

I have to start from scratch. There goes 40 hours of my life.

1501 Introduction to Process Modeling Methodology

Steps for Building a Process Model

1501 Introduction to Process Modeling Methodology

Process Modeling Methodology Stages

Stage 1: Context definition

This is an iterative stage and is the meat of process model

Last stage: Implementation in OPNET

Stage 5: Specification of process actions (per process)

1501 Introduction to Process Modeling Methodology

Lab for students to apply the methodology (lab 1)

Debugging processes in ODB

1501 Introduction to Process Modeling Methodology

Process Modeling Methodology Example 1:

1501 Introduction to Process Modeling Methodology

Process Modeling Methodology Example 1:

1501 Introduction to Process Modeling Methodology

Just for Fun

How many lines of

1501 Introduction to Process Modeling Methodology

Stage 1: Context Definition

1501 Introduction to Process Modeling Methodology

Stage 1: Context Definition (cont.)

1501 Introduction to Process Modeling Methodology

Stage 2: Process-Level Decomposition

Single process model

Step 2: If a multi-process implementation is chosen, identify

1501 Introduction to Process Modeling Methodology

Stage 2: Process-Level Decomposition (cont.)

1501 Introduction to Process Modeling Methodology

Stage 3: Enumeration of Events

Frames for Transmission

System Link Fail

1501 Introduction to Process Modeling Methodology

Stage 3: Enumeration of Events (cont.)

1501 Introduction to Process Modeling Methodology

Stage 3: Enumeration of Events (cont.)

A frame has arrived