Finite State Machine (FSM) in Network Simulation)

I recently read "omnet ++ user mannul" and learned about the working mechanism of the finite state machine. Compared with the FSM that I have read earlier in OPNET XXX, oment ++ user mannul provides a clearer and more concise description, and provides examples of code at the underlying layer, which is easier to understand.

 

FSM refers to a method to complete the module function (for example, whether the module function in omnet ++ can be completed by FSM). The FSM below refers to the FSM in the module.

 

The subjects that constitute the FSM are state and state transition. The states are classified into two types: 1) stable state; 2) temporary state. Each status has the enter and exit operations, corresponding to a piece of code, that is, the upper and lower half circles of the State circle in OPNET. Before introducing FSM, let's draw a conclusion that the stable status must be used when designing FSM, and the temporary status can also be used.

 

1) stable state: Execute the stable state enter code when entering the stable state. Then the FSM will interrupt the operation (hand over the code execution right to the Scheduler) until the next new event arrives at this module and execute the exit code in this stable state, after the execution is completed, the system jumps to another status (of course, you can also switch back to your own status ).

2) temporary status: Execute the Enter code, and then immediately execute the exit code to jump to another status (you can also switch back to your own status ).

 

We can see that the temporary status is only code execution and is not affected by the event, while the stable status is affected by the event. Considering that the workflow of the event-driven simulator is roughly: The scheduler extracts the event --> transmits the message to the module to which the event belongs --> the message processing function of the execution module --> after the execution is complete, returns the execution weight to the scheduler.

 

According to the workflow, the key and necessary features of each module are as follows: 1) The module is executed only when the event is scheduled; 2) the module must have an execution exit point, return the execution right to the scheduler. Because only the stable state can stop FSM operation and hand over the execution right, the FSM must contain a stable state, and the FSM stop (exit module) must occur after the stable state of enter; FSM wake-up (the module is scheduled) must occur before exit in the stable state (except in the init State ).

 

In the event-driven simulator, the event is the subject of the scheduling of the entire simulation operation. The execution of the simulation (the Code of the specific execution module) and the simulation time are completely controlled by the event. The lack of temporary States directly affected by events serves only as a piece of functional code. Its significance lies in simplifying the stable state and making FSM more flexible. The temporary status can bring the following benefits:

1) Some functions in the stable state can be moved to the temporary state;

2) hand over the duplicate function to the temporary state for implementation, reducing the code repetition in the stable state;

3) the number of States is increased to make the status jump design more flexible, and the jump condition design is simpler.

 

Status jump is easy to understand. It means that after the exit code is executed in the status, a status jump must be performed until a stable state is displayed. (After the Enter code is executed, FSM stops running, hand over the operation right ).

 

After understanding the above principles, how to avoid FSM traps will not be purely blind. The traps I know include: 1) infinite jump loops; 2) After FSM wakes up, the exit code in the current stable state cannot process MSG in the event. If you step on these two mines, you can imagine the operation of FSM and perform mine clearance.

 

When FSM is designed, OPNET has an interface and omnet ++ is written in pure code. The interface makes the status jump display in OPNET very intuitive. When the status or jump is very useful, omnet ++ has to draw a pen on the paper. In addition, the OPNET development process determines that FSM must be used for module development, while omnet ++ is not required. Is Philosophy different between the two?