Documentation

Modeling a Priority Queue Server Using Messages

This example models a priority queue server which processes user commands in a priority order rather than a first in first out (FIFO) or last in first out (LIFO) order. The operator provides commands which describe set points on a trajectory and the plant model follows that trajectory.

The "Operator" chart generates a new message every 0.6 seconds with a random message data.

The queue for the input message "addCmd" of the "Controller" chart is defined as a priority queue with messages sorted in the ascending order of their data.

The messages from "Operator" therefore get sorted automatically according to their data values in the input queue of the "Controller" chart.

Every time the "Controller" chart is ready to process the next message, it triggers a continuous time plant (represented by the "PLANT" region in the Simulink® canvas) and provides the next set point to reach.

   send(RESET);
   waypoint = addCmd.data;

Here "RESET" is an edge triggered output event. This illustrates how you can "convert" a message to an edge triggered output signal which can be used to reset continuous time components.

The "PLANT" region consists of an integrator which represents the continuous dynamics and a "Plant" chart which is used to detect the continuous time signal. When the "Plant" chart detects that the current set point is reached, it generates a message for the "Controller" acknowledging that it is ready to receive the next set point.

The "Plant" chart illustrates how you can convert an edge triggered input event (the "EVENT" input) to a message output (the "REACHED" message):

   EVENT { REACHED.data = target; send(REACHED); }

By using a priority queue instead of a FIFO or LIFO queue, the trajectory following is smoother because if the user provides set points such as 0, 5, 2 in quick succession while the plant is still at position 0, the plant can first reach the set point 2 and consider that set point reached and then reach set point 5. Otherwise, the plant would reach 5 and have to backtrack and reach 2 once again.

This model also illustrates how the "Operator" chart can be made asynchronous with the "Controller" chart without any loss of data. The "Operator" chart can send commands at fast as it desires and none of the messages are lost since they are queued in the "Controller" chart's input queue.

Was this topic helpful?