1501_introduction to process modeling methodology

CONFIDENTIAL RESTRICTED ACCESS: This information may not be disclosed, copied, or transmitted in any format without the prior written consent of OPNET Technologies, Inc.

2007 OPNET Technologies, Inc.

Introduction to Process Modeling Methodology

R&D Solutions for Commercial and Defense Networks

Session 1501

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.

21501 Introduction to Process Modeling Methodology

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.

What Are We Going To Learn?



Agenda

Introduction / motivationProcess Modeling Methodology explained through an example

Lab for students to apply the methodology (lab 1)Dynamic processes

IntroductionProcess life cycle Lab 2

Interrupt steeringProcess communication Lab 3

Debugging processes in ODBConclusion



Agenda








Introduction

What is the Process Modeling Methodology (PMM)?A systematic approach to creating process models in OPNET ModelerQuickest, most efficient method of developmentProtection from some common pitfalls Produces consistent results Indispensable for larger models

What is a Process Model?

But first



OPNET Environment

Process model is the heart of custom simulation development



Comparing Approaches

Both of these are parts of the standard OPNET TCP model

Flower Petal - tcp_manager_v3 PMM - tcp_conn_v3



Process Model Dynamics

Beginners avoid RED states, but they are very important!

init

INITIALIZED

CONNECTEDconnect

MSG1

MSG2

MSG3

msg1

REGISTEREDregister wait

RECOVER

FAIL FAILFAIL

fail msg3

msg2



States, Events, and Actions

asleep awakeAlarm

Condition of system

Stimulus to move system

State Event Action State

Response of system to stimulus

Condition of system

Important definitions

/ Wakeup

0:00 6:00 Time progresses 6:00 8:00 Time progressesInstantaneous

10



PMM is your roadmap to process model development success

Motivation

PMM helps the user over many common pitfallsGets 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.

11



Steps for Building a Process Model

Obtain protocol specificationDesign using the methodologyReview the design Implement in OPNET

12



Process Modeling Methodology Stages

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

methodologyLast stage: Implementation in OPNET

Stage 5: Specification of process actions (per process)

123

4

5

13



Agenda






14



Process Modeling Methodology Example 1:Stop-and-Wait Retransmission Protocol

Protocol for the Data Link Layer at the sending side onlyBasic functionality: Provide reliable communications over a lossy

channelAccept frames from the upper layer and send them to the physical

layer

15



Receive frames from higher layerTransmit frame over physical layerMust receive an acknowledgment before sending the next frameQueue frames arriving from the higher layer if the process is waiting for acknowledgment for a previous frameRetransmit 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

Amalgamated Communications Kompany (ACK) C. R. Ash SWaRe Protocol Version 1.3.X Aug 23, 2005 Proprietary

Marketing Sales Simulation9 9

Process Modeling Methodology Example 1:Protocol Requirements

16



Just for Fun

How many lines of OPNET code are needed to model this protocol?

17



Stage 1: Context Definition

Fit this piece into the big picture:

Step 1: Identify interdependent modulesStep 2: Select communication mechanisms with

interdependent modulesStep 3: Develop diagram of system and interdependent

modules

123

4

5

18



Stage 1: Context Definition (cont.)

Higher Layer

SWaRe Protocol

Physical Layer

Frames for Transmission

Transmitted Frames Acknowledgements

123

4

5

19



Stage 2: Process-Level Decomposition

Step 1: Determine which process model decomposition technique is applicable to the systemSingle process modelMultiple (parent-child) process modelsStep 2: If a multi-process implementation is chosen, identify

the areas of responsibility assigned to each processStep 3: For multi-process implementations, determine

circumstances of process creation and which process will be the root

123

4

5

20



Stage 2: Process-Level Decomposition (cont.)

Use a single process for this example 123

4

5

21



Stage 3: Enumeration of Events

Step 1: Define logical events of each processStep 2: Select event implementation methods

SWaRe Protocol

Frames for Transmission

Acknowledgements

Ack timeout!!

System Link FailSystem Link Up

123

4

5

22



Stage 3: Enumeration of Events (cont.)

Interrupt TypeEvent DescriptionEvent Name123

4

5

23



The process starts.Power Up

The link has recovered.

Link Up

The link has failed.Link Fail

An acknowledgement for the last transmitted frame has been received.

Acknowledgement Received

The retransmission timer has expired.

Timeout

A frame has arrived from the higher level.

Frame Arrival

Interrupt TypeEvent DescriptionEvent Name

Stage 3: Enumeration of Events (cont.)

!!

Stream

Self

Stream

Failure

Recovery

Begin Simulation

123

4

5

24



The Event Response Table specifies how the model reacts to various events, depending upon the state of the model

The events and actions are indicated in the specification What are the conditions?What are the states?

Final StateActionConditionEvent State

Stage 4: Event Response Table Development

123

4

5

25



State Event Action StateCondition

Conditions

26



Stage 4: Event Response Table Development Identifying States

A stateRepresents a blocking point of the processCorresponds to particular sequences of events having occurredReacts 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

point in the design process

Solution:Start with an initial state and walk through the model

123

4

5

27



Init


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 conditionsLoop Step 2 for all eventsLoop Step 1 until all states are complete

123

4

5

28



Power Up

Link Up

Link Fail


Timeout

Frame ArrivalInitFinal StateActionConditionEvent State

Using a BEGINSIM interrupt assures that the Init state will not have to handle any other type of event

Stage 4: Event Response Table Development Initial State

Always None Idle

123

4

5

29



IdleNoneAlwaysPower UpInit

Link Up

Link Fail


Timeout

Frame Arrival

Power UpIdle


Specify actions down to the KP level Found new statesFound new states

Stage 4: Event Response Table Development Idle State

Always

Always

Copy frameSend frameSet timer

None

ACK Wait

Link Down

123

4

5

30



Link Down


ACK Wait

Link DownNoneAlwaysLink Fail

ACK WaitCopy frameSend frameSet timer

AlwaysFrame ArrivalIdle


Stage 4: Event Response Table Development Two New States

123

4

5

31



Link Up

Link Fail


Timeout

Frame ArrivalACK Wait

Final StateActionConditionEventState

Stage 4: Event Response Table Development ACK Wait State

Always Queue frame ACK Wait

Always Copy frameSend frameSet timer

ACK Wait

Queue Empty

Cancel timerDestroy copy

Idle

Queue Occupied

Cancel timerDestroy copyPop queueCopy frameSend frameSet timer

ACK Wait

Always None ACK Wait and Link Down

123

4

5

32



Link UpLink Fail


Timeout

Frame ArrivalLinkDown


Stage 4: Event Response Table Development Link Down State

Always Queue frame Link Down

QueueEmpty

None Idle

Queue Occupied

Pop queueCopy frameSend frameSet timer

ACK Wait

123

4

5

33



Link Up

Link Fail


Timeout

Frame ArrivalACK Wait and Link Down


Often, designing the model helps flush out the design of the real system

Stage 4: Event Response Table Development ACK Wait and Link Down State

Retransmit Flag

Reset flagCopy frameSend frameSet timer

ACK Wait

No Retrans Flag

None ACK Wait

123

4

5

Always

Queue frame

Set retransmit flag

ACK Wait and Link Down


Always

34



Stage 5: Specification of Process Actions

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

123

4

5

35



123

4

5

state1 state2

Stage 5: Specification of Process ActionsStep 2 Implement STD in OPNETPlacing Actions in the STD

PK_ARRIVAL/sample_function_call();

Actions can be contained in three different placesLeaving the current state: Exit ExecutivesGoing from one state to the next: Transition ExecutivesEntering the new state: Enter Executives

36



state1

state2

state1 state2

Stage 5: Specification of Process ActionsStep 2 Implement STD in OPNETPlacing Actions in the STD (cont.)

Exit Executive contains actions common to all outgoing transitionsEnter Executive contains actions

common to all incoming transitionsTransition Executive contains actions

associated with a specific transition

Recommendation: Start by placing all actions in transition executivesLater, actions common to all outputs or

inputs can be placed in exit or enter executives

123

4

5

37



Stage 5: Specification of Process ActionsStep 2 Implement STD in OPNETPlacing Actions in the STD (cont.)

Green states as code holders

state1 state2trans

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

123

4

5

38



IdleNoneAlwaysPower UpInitFinal StateActionConditionEvent State

Stage 5: Specification of Process ActionsStep 2 Implement STD in OPNET (cont.)

123

4

5

39



Link DownNoneAlwaysLink Fail


AlwaysFrame ArrivalIdleFinal StateActionConditionEvent State


123

4

5

40




NoneAlwaysLink Fail

ACK WaitCancel timerDestroy copyPop queueCopy frameSend frameSet timer

Queue Occupied

IdleCancel timerDestroy copy

Queue EmptyAcknowledgement Received


AlwaysTimeout

ACK WaitQueue frameAlwaysFrame ArrivalACK Wait



123

4

5

41



ACK WaitNoneNo Retrans flag


Retransmit flagLink Up


Set re-transmit flag

AlwaysTimeout


Queue frameAlwaysFrame Arrival


Link Up IdleNoneQueue Empty

ACK WaitPop queueCopy frameSend frameSet timer

QueueOccupied

Link DownQueue frameAlwaysFrame Arrival

Link Down Final StateActionConditionEvent State


123

4

5

42




Alternate solution: Using forced states

QFrame1

QFrame2

QFrame3

43



Stage 5: Specification of Process ActionsStep 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

44



Stage 5: Specification of Process ActionsStep 3 Define/Replace Macros & Pseudo-Code (cont.)

Write functions in function blockvoid 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);

}

45



Only

27lines of code!

Only

27lines of code!

Stage 5: Specification of Process ActionsStep 3 Define/Replace Macros & Pseudo-Code (cont.)

Write functions in function blockvoid SendNext(){

send (op_subq_pk_remove (0, OPC_QPOS_HEAD));}void SetRetrans(){

retransFlag = 1;}void RetransIfFlagSet(){

if (retransFlag) ResendFrame();retransFlag = 0;

}void send (Packet* aPkt){

copyPkt = op_pk_copy (aPkt);op_pk_send (aPkt, StreamToLink);ackEvent = op_intrpt_schedule_self (op_sim_time() + ackDelay, 0);

}

46



Agenda






47



You are provided with a specification for a protocol Implement it using the Process Modeling MethodologyBlank forms are provided to assist youThere may be many correct solutionsFeel free to ask TAs for help

Lab 1: Using the Methodology

48



Solution for Lab 1

The following slides present one possible solution for all stages of the methodology

49



Stage 1: Context Definition

Traffic Source

CSMA Protocol

Physical Medium

Packet Arrival

Send Packet Medium Busy/Not Busy

50



Stage 2: Process-Level Decomposition

Use a single process for this example

51



Begin SimInitialize CSMAPower Up

SelfTime to send a packetBackoff Over

StatThe transmission medium has changed from busy to free

Medium Free

StreamA packet has arrived from the source

Packet Arrival

Interrupt TypeEvent DescriptionEvent Name

Stage 3: Enumeration of Events

NOTE: We do not need an event for Medium BusyNOTE: We do not need an event for Medium Busy

52



Backoff OverIdleNoneAlwaysMedium Free

MediumIsBusyQueue packet

Medium Busy

IdleSend packetMedium not Busy

Packet Arrival

Idle



Found new statesFound new states

NOTE: Medium Free is an EVENTMedium Busy is a status that we check

NOTE: Medium Free is an EVENTMedium Busy is a status that we check

Stage 4: Event Response Table Development

53



Stage 4: Event Response Table Development (cont.)

Backoff Over

BackOffStart BackoffAlwaysMedium Free

MediumIsBusyQueue PacketAlwaysPacket Arrival

MediumIsBusy


Found new stateFound new state

54



BackOffSend first packet Start Backoff

Medium is not Busy & multiple packets

IdleSend PacketMedium is not Busy & only one packet

MediumIsBusyNoneMedium BusyBackoff Over

BackOffNoneAlwaysMedium Free

BackOffQueue PacketAlwaysPacket Arrival

BackOffFinal StateActionConditionEvent State

No more new states!No more new states!

Stage 4: Event Response Table Development (cont.)

55



Stage 5: Specification of Process ActionsStep 2 Implement STD in OPNET

56



Stage 5: Specification of Process ActionsStep 3 Define/Replace Macros & Pseudo-Code

57



Summary Process Modeling Methodology

What is a Process Modeling Methodology?Systematic approach to creating process models in OPNET ModelerQuickest, most efficient method of developmentProtection from some common pitfalls What are the advantages? Why use this methodology?

Universal approach eliminates hesitation in model designFront-end design effort will decrease implementation timePossible reduction in lines of codeUniformly designed process modelsBehavior easy to visualize

58



Agenda






59



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

Introduction

60



Example Process Models

Both of these are parts of the standard OPNET TCP modelPerfect example of dynamic processes at work

Manager spawns tcp_conn_v3 children for each TCP connection

tcp_manager_v3 tcp_conn_v3

spawn

invoke

61



Modular organization (decomposition)Each process performs a specific taskDesign several simple process models rather than one complex modelWith identical input/output requirements, child processes can be

interchangeableCore concept behind scalable modeling techniques Imitates real world system designsEasier to create and maintain

Motivation

62



Root processThe single process initially present within each module at the node levelChild process

Additional processes created within the module during simulationMay be created by the root process or other child processesParent process

The process that created a given child processThe root process has no parentProcess group

The collection of all processes within a module

Terminology

63



Root process

First-generationchild processes

Second-generationchild processes

The number of generations is not limited, but typically only one or two are used

The number of child processes at any level can scale dynamically as needed

Process Group

Illustration of Process Hierarchy

The entire process group runs within a single module

The models at any level do not all have to be the same

64



OPNET Configuration:Declaring Child Processes

Create the child process modelsOpen the parent process in the Process EditorChoose File > Declare Child Process ModelsSelect the child process models

65



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 nameAll instances of a child process model within a module have the same

attributes and valuesChild process model attributes are not used often

Usually the parent passes state to each child upon creation

Model Attributes of Child Processes

66



Agenda






67



Process Lifecycle

Process creationProcess invocationProcess destruction

68



EXAMPLE:

Prohandle aChildProc;MY_STRUCT* someData;

aChildProc = op_pro_create ("childProcModel", someData);

Dont put .pr.m

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 moduleAllows for the installation of parent-to-child shared memoryReturns a process handle

69



Process Creation (cont.)

Child process shares all module resourcesSubqueuesPacket streamsStatistic wiresStatistic declarationsRun-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 eventsMinor performance hit for great simulation flexibility and modularity

70



EXAMPLE:

Prohandle aChildProc;MY_STRUCT* someData;MY_OTHER_STRUCT* someOtherData;

aChildProc = op_pro_create ("childProcModel", someData);op_pro_invoke (aChildProc, someOtherData);

Process Invocation

op_pro_invoke (pro_handle, arg_mem_ptr) Invokes a process in the context of the current event and current moduleThe invoked process reacts as if it received an event Information can be passed in argument memoryThe 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

71



Process Invocation (cont.)

To the invoked process, an invocation is treated just like an interruptStarts at an unforced (red) stateExecution continues until the next unforced (red) stateControl is passed back to the invoking processCan ONLY be used to invoke a process in the same moduleCircular (recursive) invocations are not allowed

Trapped by Simulation Kernel

72



op_pro_destroy (pro_handle) op_pro_destroy_options (pro_handle, options)

OPC_PRO_DESTROY_OPT_KEEP_EVENTS or OPC_PRO_DESTROY_OPT_NONEProcess destruction

Deletes a dynamically created process Invokes the Termination Block

Good place to clean up dynamic memory allocated by child processGood place to destroy any child processesONLY time Termination Block is invoked (not used in root processes)

Process Destruction

73



Process Destruction (cont.)

Processes can destroy themselvesThe root process cannot be destroyedAny process in the current invocation stack cannot be destroyed

74



Children

Root

Lab 2: Using Child Processes

Module in node has multiple incoming packet streamsMonitor the multiple packet streams using process groups Initially all packets are handled by the root processCreate child processes to handle packets from streams

75



Agenda






76



Interrupt Steering

Specifying which process within a module receives a given interruptFour mechanisms:

ManualNormalType-basedPort-based

77



Root process receives control (by default) Invokes appropriate childBlocks till child returns

Root

SimulationKernel

Children

op_pro_invoke()

interrupt

Manual Steering

78



op_intrpt_schedule_self (time, code)

Simulation kernel automatically invokes correct child

Normal Steering

1) op_intrpt_schedule_self()

2)self interrupt

Root

SimulationKernel

Children

79



Normal Steering (cont.)

2)interrupt

Root

SimulationKernel

Children

1) op_intrpt_schedule_process()

Any process can schedule any other process using op_intrpt_schedule_process.

op_intrpt_schedule_process (pro_handle, time, code)

Simulation kernel automatically invokes correct child

80



op_intrpt_type_register(OPC_INTRPT_FAIL, ...)

all failure interrupts

Root

SimulationKernel

Children

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)

81



op_intrpt_port_register(OPC_PORT_TYPE_STRM, 0, ...)

stream 0 interrupts

Root

SimulationKernel

Children

other stream interrupts

Port-Based Steering

op_intrpt_port_register (type, index, pro_handle) stream and statistic interruptsTakes precedence over type registration

82



Interrupt Deregistration

Type-basedRe-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

83



Direct and Indirect Invocation

Incoming packets:Cause STREAM

interrupts

Identify the direct or indirect invocation using op_pro_invoker (pro_handle, invmode_ptr)Example (Case A):

Port-based steering to childOPC_PROINV_DIRECT returned (to *invmode_ptr)

RootSimulationKernel

Child

84



SimulationKernel

Direct and Indirect Invocation (cont.)

Incoming packets:Cause STREAM

interrupts

Example (Case B):Root process invokes child process after receiving packetsOPC_PROINV_INDIRECT returned from op_pro_invoker()

Root

Child

85



Agenda






86



Process Communication

Shared process memoryModule-wide memoryParent-to-child memoryArgument memory

87



Module-Wide Memory

Establish op_pro_modmem_install (mem_ptr)Access op_pro_modmem_access()

modmem

88



Parent-to-Child Memory

Establish op_pro_create (model_name, ptc_mem_ptr)Access op_pro_parmem_access()

You do not have to create Parent-Child memory

pmpm

pmpmpm

89



op_pro_invoke()

Argument Memory

Establish op_pro_invoke (pro_handle, argmem_ptr)Access op_pro_argmem_access()

am

90



Applicable in general not just to child processesGet state variables from another process

op_ima_obj_svar_get (Objid, Svar_Name) op_pro_svar_get (pro_handle, Svar_Name)

Global registry oms_pr_process_register () oms_pr_attr_set () oms_pr_process_discover () oms_pr_attr_get ()

ICIs op_ici_create () op_ici_attr_set () op_ici_attr_get ()

General scope options Header block variables Header file variables

May be slowMay be slow

For root processFor root process

Additional Data Sharing Concepts

91



Lab 3: Interrupt Steering and Process Communication

Stream interrupts steered to appropriate child processesPort-based steering is used:

Root process requires no processing to be done with incoming packetsTherefore packets can be directly steered to child processAll incoming packets generate stream interrupts, so type-based registering is

not sufficientCommunication between the root and child processesModule-wide memory holding dimensioned statistic handles

Use of oms_dim_stat package for statistic reporting

92



Summary Dynamic Processes

Modules can contain more than one processBenefits include scalability and modularityProcesses can be created and destroyed during runtime Interrupts can be steered to an appropriate process Processes communicate using shared memory

93



Agenda






94



Locating processesControlling processesTracing processesDisplaying process state

Debugging Processes in the OPNET Debugger (ODB)

95



Locating Processes in ODB

promap Displays a list of the processes associated with a specified module in ODBUse promap all to list all existing processesUse 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)

96



Controlling Processes in ODB

prostop Enables a breakpoint for all invocations of the specified processCan 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

controlLabeled breakpoint must also be enabled prolstop

Enables a labeled breakpoint in the specified process

97



Tracing Processes in ODB

protrace Enables full trace for the specified processCan 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

Enables a trace for the specified label restricted to the specified process

98



Displaying Process State

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

standard output device prodiag

Executes diagnostic block of the specified process proldiag

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

99



Homework Lab: Debugging Dynamic Processes

Use ODB commands to debug dynamic processesThe lab will use ODB to:

Observe the creation of the child processesObserve the child processes handling packetsObserve the state of a child process after it has handled 50 packets

100



Agenda






101



Documentation References

Modeling Concepts Reference ManualModeling 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 chapterProgramming Package chapter, ODB Sub-Package sectionProcess Package chapterExternal Interfaces Reference Manual

Simulation Execution chapter (ODB reference)

102



Related OPNETWORK Sessions

Session 1572: Introduction to OPNET ModelerSession 1502: Debugging Simulation Models IntroductionSession 1503: Debugging Simulation Models AdvancedSession 1530: Modeling Custom Wireless Effects Introduction Session 1550: Accelerating Simulations Using Efficient Modeling

Techniques

103



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!

1501_introduction to process modeling methodology

Documents

opnet modelerquickest

opnet environmentprocess

process models

methodology lab

v381501 introduction

first61501 introduction

debugging processes

v3 pmm tcp