Article Directory
The commonly used editors of OPNET Modeler mainly include project editor, node model editor and process model editor. Here is an example to introduce the use of these commonly used editors.
At the start of the simulation, the process model is invoked for the first time, entering the Initialization state. After initialization (setting the packet counter to 0), it will transition to the Idle state and wait for the first packet to arrive. When a packet arrives, the process model is activated again and transitions to the Arrival state. The Arrival state adds 1 to the packet counter variable, destroys the packet, and then immediately returns to the Idle state to wait for the arrival of the next packet. The sketch shown in the figure below can be drawn.
Next, create each model in order from small to large, that is, process model -> node model -> network model, which is also the order of custom model network modeling.
1. Create a process model
Open the OPNET software, select Process Model in the pop-up box in File->New, and click the OK button to create.
The process model after creation is shown in the figure below.
When creating a process model, there are several points that need attention:
①The first state created is automatically marked by OPNET as the initial state, which is the state with a large black arrow;
②Select the placed state, right click Set Name The name of the state can be changed;
③The green state is a mandatory state (also known as a non-stay state), and the transition to the green state will execute the entry execution code and exit execution code in turn, and then immediately transfer to other states. The red state is a non-mandatory state, and a newly created state is the red state by default. When transferring to this state, after the entry execution code is executed, the module will transfer the control of the program back to the simulation core, and the module will stagnate here, waiting for the next The event arrives at the activation module. Right-click the red state, select Make State Unforced in the pop-up menu to convert the non-forced state into a forced state (that is, red to green), right-click the green state, and select Make State Unforced in the pop-up menu to convert the forced state into Non-forced state (i.e. green to red).
④ Select the create transition button to connect the various states. If you need to be smooth, you need to click again to place a point between the two points. The unconditional transfer is a solid line, and the conditional transfer is a dotted line. The conditions next to the dotted line are attributes. Click to select the line that needs conditional transfer, right click on the line and select Edit Attributes to set its transfer conditions, as shown in the figure below.
⑤ Connect a self-transfer line to idle, and set its condition attribute to default. When the simulation is running, the simulation core will turn the event at the head of the event list into an interrupt and send it to the appropriate module. Assuming that the process model receives the interrupt and is in the idle state, if the ARRIVAL condition is met, it will smoothly transfer to Arrival state, but the process model may also receive abnormal interruption, and the ARRIVAL condition cannot be satisfied. At this time, if there is no other transfer that meets the condition, the module will not find the destination state and make an error. The default transfer is the last line of defense. .
⑥ define some conditions and variables.
Click the HB button to define the macro.
Enter the code below and save the file.
#define ARRIVAL (op_intrpt_type () == OPC_INTRPT_STRM)
In OPNET, macros are often used to replace complex transition conditions and state transition execution codes, which can make the finite state diagram look concise and clear.
When the interrupt arrives at the module, the emulation core calls the op_intrpt_type() function, and compares its return value with the OPNET constant OPC_INTRPT_STRM. If the values are equal, it means that the interrupt is caused by the packet arrival, and the ARRIVAL condition is met.
Next, two state variables need to be declared, one is used to store the value of the packet counter, and the other is the handle used to write the value of the counter to the statistics.
Click the SV button to set the state variable, as shown in the figure below.
Create a new local statistic under Interfaces->Local Statistics, and add a description, as shown in the figure below.
Next, create the execution code for each state.
For the forced state, the execution of the entry execution code and the exit execution code is coherent, so generally the program of the forced state is placed in its entry execution code.
Double-click the upper part of the init state, and write the following code in its entry execution code file.
pk_count = 0;
pk_cnt_stathandle = op_stat_reg ("packet count", OPC_STAT_INDEX_NONE, OPC_STAT_LOCAL);
The first sentence of code is to set the value of the packet counter to 0, and the second sentence of code registers the declared statistics and obtains the statistics handle pk_cnt_stathandle associated with it. The core function op_stat_reg() will be used here.
Double-click the upper half of the arrival state, and write the following code in its entry execution code file.
pk_count = pk_count + 1;
op_pk_destroy (op_pk_get (op_intrpt_strm()));
op_stat_write(pk_cnt_stathandle, pk_count);
The first sentence of code is to add 1 to the value of the packet counter. In the second sentence of code, first determine which packet flow the interrupt comes from op_intrpt_strm(), it returns the index number of the packet flow, and then get the packet op_pk_get() according to the index number, it returns a pointer to the packet data structure, and finally the The memory block pointed to by the package pointer is released, that is, the package is destroyed op_pk_destroy(). The third sentence of code writes the current counter value into the status statistics handle pk_cnt_stathandle through the core function op_stat_write().
Under Interfaces --> Process Interfaces, set as shown in the figure below.
begsim intrpt is the simulation start interrupt; endsim intrpt is the simulation end interrupt.
There are some attributes in the process interface of each process model: such as begsim intrpt, endsim intrpt, failure intrpt, regular intrpt, etc. When designing modules, the setting of these attributes is very important, which is the setting of begsim intrpt, which affects the state of init When the Enter code is executed, if it is enabled, the process can be initialized at the beginning of the simulation, that is, at the moment of simulation 0, and the Enter code of init will be executed after the process is triggered. If it is disabled, it will not be triggered by the kernel. If you need to do some work (such as variable collection, memory release, etc.) at the end of the simulation, you need to enable endsim intrpt. The regular intrpt can be used as a timer. After the process interface sets the intrpt interval, the emulation core triggers a regular interrupt every this amount of time.
The setting of the process model is over here. Click the compile process model button (the last button on the toolbar), and the following box will pop up, indicating that there is no problem with the compilation.
When compiling, it will first let you save the process model and name it packet_count.
2. Create a node model
Next create the node model.
In File -> New, select Node Model in the pop-up box, and click the OK button to create.
The created node model is shown in the figure below.
The creation of the node model only uses the button of the create process tool and the button of create package flow.
Set the properties of the three modules, and the properties of src1 are set as shown in the figure below.
The attribute setting of count is shown in the figure below. Note that the process model here selects the process model packet_count created earlier.
The attribute setting of src2 is shown in the figure below, right-click the packet delay time here to set it as promoted.
Both packet generators send packets to the count module at the same time. The first packet generator sends at a rate of one packet per second, while the second packet generator sends at a variable rate. You need to specify a distribution function for the Packet Interarrival Time property of the second packet generator to achieve this effect . The reason why this attribute was upgraded earlier is that we hope to adjust this attribute at the node level, which brings convenience to users, but this attribute belongs to the process level. By upgrading, this attribute can also be set at the node level . It can also be renamed in the node model after promotion.
After the above work is completed, save the node model, and the name is still packet_count, as shown in the figure below.
The process model and the node model can have the same name, and there will be no confusion between them, because the file suffixes are different. The suffix of the process model is *.pr.m, and the suffix of the node model is *.nd.m, as shown in the figure below.
Add the packet count statistics under Interfaces——>Node Statistics, and the operation steps are shown in the figure below.
After the addition is successful, as shown in the figure below, click OK.
3. Create a network model
In File—>New, select Project in the pop-up box, set the project name to packet_count, and the scene name to constant, as shown in the figure below, and click OK.
Click Quit in the pop-up startup wizard dialog box to skip the next steps.
Next, open the object panel, search for the packet_count node, place it in the workspace, and close the object panel.
Right-click the placed node, select Choose Individual DES Statistics, then check the following options, and click OK.
Next, you need to specify the Packet Interarrival Time attribute of the second packet generator in the node model, click the right mouse button on the node model, select Edit Attributes from the pop-up menu, select the distribution function dialog box of src2.Packet Interarrival Time, and set as follows picture.
Check the animation function under DES, so that you can view the animation effect after simulation.
4. Configuration and Simulation
Configure repositories before simulation, search for repositories under Edit—>Preferences, make sure it is empty, if not empty, delete it, otherwise subsequent simulation may be wrong.
Set the simulation parameters as shown in the figure below.
The simulation kernel here selects Optimized to speed up the simulation without generating ODB (OPNET Debugger) debugging information. If ODB debugging information is required, the simulation kernel here should be selected as Development, and OPNET Debugger should be selected under Execution on the left, and OPNET Debugger on the right If it is the Optimized simulation kernel, it will prompt that ODB is unavailable, as shown in the figure below.
Click Run, and the simulation can be completed if there are no errors, as shown in the figure below.
Right-click the node, select View Results, and check the packet count to see the final drawn curve, as shown in the figure below.
Select Play 2D Animation under DES to view the animation of sending packet flow!
The curve animation over time is as follows.
The packet flow animation is shown below.
Next, copy a scenario in Scenarios->Duplicate Scenario... and name it exponential, as shown in the figure below.
Edit the properties of the node, select the distribution function dialog box of src2.Packet Interarrival Time, and set as shown in the figure below.
You can run two simulations at a time, select Manage Scenarios under the Scenarios menu, and set the settings as shown in the figure below.
Click OK to start the simulation, as shown in the figure below after the simulation is completed.
Next look at the graph with src2.Packet Interarrival Time set to an exponential distribution function.
The curve in the figure shows how the value of the packet counter changes with the simulation time. It can be seen that the total number of packets increases monotonically with the passage of simulation time, and the glitch in the curve is caused by the burst arrival of packets (obeying the law of exponential distribution function). And the slope of the curve, that is, the throughput of the packet is consistent with the packet generation rate, can be verified by calculation. The two packet generation modules generate one packet per second on average, and the simulation takes 100 seconds. The actual packet generation interval is 90 seconds, so the number of packets received by the packet counting process module is about 180.
After clicking the Show button, a separate window will pop up. Select a certain area with the mouse to zoom in and view it, as shown in the figure below.
In this separate window, right-click the curve to set the color of the curve, add a grid, and make the linear display discrete, etc., as shown in the figure below.
Right-click outside the curve to set the display characteristics of the panel, such as scale in seconds, icon style and other properties, as shown in the figure below.
Different functions can be displayed together, as shown in the figure below.
Or draw two curves in one graph, as shown in the figure below.
If you encounter the error shown in the figure below during the simulation, you can refer to the article: LINK: fatal error LNK1181 in OPNET: The solution to the input file cannot be opened .
Mistake 1:
Mistake 2:
Summarize
The above is all the content of the comprehensive application examples of OPNET Modeler's commonly used editors. I hope this article will be helpful to you in learning OPNET Modeler software!
Bibliography of this article: OPNET Network Simulation/Edited by Chen Min. - Beijing: Tsinghua University Press, 2004