Using Message Polling and Message Triggered Subsystems

This example shows how Message Polling Subsystem and Message Triggered Subsystem blocks operate and demonstrates the differences between them. Both Message Polling Subsystem and Message Triggered Subsystem blocks contain a Trigger block. Based on the configuration of the Trigger block, you can create these behaviors:

• Message Polling Subsystem block — The subsystem pulls messages from a queue periodically based on the sample time of the subsystem.

• Message Triggered Subsystem block in immediate mode — The message sender and the Message Triggered Subsystem are synchronized. The message sender invokes the subsystem by pushing messages.

• Message Triggered Subsystem block in scheduled mode — The execution order of the subsystem can be scheduled in the Schedule Editor to model an asynchronous behavior.

This example shows differences between these three modes and explains use cases for each mode.

Overview

This model contains three identical message sources: Sender1, Sender2, and Sender3. Each source generates messages with payload values from two Repeating Stair Sequence blocks.

Sender1, Sender2, and Sender3 all have sample time of 1 and generate two messages at each time step. This figure shows the payload values of generated messages. The sequence repeats starting at time step 6.

Inside each message receiving subsystem, the message payload is read, multiplied by 2 using a Gain block, and used as the payload for a message.

Message Polling Subsystem

Use a Message Polling Subsystem block when you want to define the rate of the subsystem block when pulling messages. The block pulls a message from a queue based on its sample time, and the sample time can be specified on the subsystem block parameter. The block can pull only one message at each time step. You can configure the block to pull messages with a slower or faster rate.

In this example, the Message Polling Subsystem block has a sample time of 2. In each time step, the block checks for available messages at the Queue block. If a message is available, the Message Polling Subsystem block pulls one message and executes. A Queue block operating in FIFO mode with a capacity of 16 stands between the message sender and the Message Polling Subsystem block. This figure shows that the subsystem pulls messages with a slower rate using the sample times.

The scope output shows that the subsystem pulls and processes only one message every 2 time units, whereas two messages are sent to the Queue block at each time unit. During simulation, the Queue block fills up, and some messages are lost.

Message Triggered Subsystem in Immediate Mode

The first Message Triggered Subsystem block operates in immediate mode. That is, in the Trigger block inside the subsystem, the Schedule as aperiodic partition check box is not selected. Use this mode to represent the simple cases when you do not have to schedule the subsystem execution. In this configuration, the message sender invokes the Message Triggered Subsystem block for execution by pushing the available messages to the subsystem. The subsystem executes as soon as a message is pushed by the sender. If you use a Message Triggered Subsystem block in immediate mode, you do not have to use a Queue block between the message sender block and the subsystem. This mode supports code generation for the top model and its components. In the generated code, the subsystem acts as a function that takes the message payload as an argument and is called by the sender.

This figure shows that the sample times are synchronized because the sender invokes the subsystem.

The scope output shows that the subsystem receives and processes two messages at each time unit.

Message Triggered Subsystem in Scheduled Mode

The second Message Triggered Subsystem block operates in scheduled mode. That is, in the Trigger block inside the subsystem, the Schedule as aperiodic partition check box is selected, which is the default configuration. Aperiodic partitions are partitions that are not necessarily periodically triggered or bound to a periodic time trigger and can be bound to an event. This mode allows you to schedule the execution of the subsystem using the Schedule Editor. For more information, see Using the Schedule Editor. In this case, the top model does not support code generation because scheduling does not support code generation. However, you can move the Message Triggered Subsystem block inside a referenced model and connect to the root Inport and generate code for that component alone, which can then be integrated with the message middleware.

In this example, a Queue block operating in FIFO mode stands between the message source and the Message Triggered Subsystem block. When a message arrives at the Queue block, the message raises an event that triggers the Message Triggered Subsystem block to pull the message from the Queue block. Then, the subsystem pulls the message based on the message availability and the schedule. This figure shows the sample times of the message sender and the Message Triggered Subsystem block.

For example, this figure shows the Schedule Editor displaying the Message Triggered Subsystem block that is scheduled to execute first. In this case, a message arrives at the Queue block based on D1, and this event triggers the Message Triggered Subsystem to pull the message. The Message Triggered Subsystem pulls the message as soon as it arrives at the Queue block because it is scheduled first in the order. In this case, the Message Triggered Subsystem in scheduled mode behaves identically to a Message Triggered Subsystem in immediate mode. However, scheduled mode allows you change the order and schedule the execution of the subsystem based on your modeling requirements.

Simulate the model. The scope output shows that the Message Triggered Subsystem receives and processes two messages at each sample time hit.