This model shows the basic semantics and syntax of sending and receiving messages by contrasting them with data and events. Prior to messages, Stateflow® charts could communicate with each other using either data or events. This example shows how messages differ from these other modes of communication.
There are three "sender" charts in the model, a "DataSender" chart, an "EventSender" chart and a "MessageSender" chart. All three charts behave in a similar way. The "DataSender" chart writes a value to its data output at t=0, the "EventSender" chart generates a function call output at t = 0, and the "MessageSender" chart sends a message at t=0. Note that the basic syntax for sending events and messages is similar between events and messages.
Figure 1: DataSender chart
Figure 2: EventSender and MessageSender charts
All these Sender charts communicate with corresponding "Receiver" charts, which also behave similarly. All charts remain in a state "A0" for 3 seconds and then take transitions to successive states at successive time steps depending on the value of the data or whether an event or message is valid. The "DataReceiver" chart uses an input condition on the transitions "[M == 1]".
Figure 3: DataReceiver chart
The "EventReceiver" and "MessageReceiver" charts use a trigger condition on the transitions. Notice that with both events and messages, the syntax for checking the validity of an event or message is identical.
Figure 4: EventReceiver and MessageReceiver charts
When we simulate the model, we notice the following behavior in the various receiver charts:
The DataReceiver chart transitions from A0 to A1 at t = 3 seconds and then in subsequent time steps transitions all the way from A1 to A2 to A3. This happens because even though the DataSender chart writes "M = 1" at t = 0, this value persists for the length of the simulation. Thus the condition "M == 1" is valid for the entire simulation.
The EventReceiver chart stays in A0 and never takes a transition. This is because the EventReceiver chart only executes at t = 0 in response to the function call generated at t = 0 by the EventSender chart. Even if we were to add an additional periodic trigger input to this chart to force it to wake up every 1 second, this chart would only transition from A0 to A1 at t = 3 when the condition "after(3, sec)" becomes true. The transition from "A1" to "A2" would never be taken since the event "M" is only valid at t = 0.
The MessageReceiver chart on the other hand takes a transition from A0 to A1 at time t = 3, then takes a transition from A1 to A2 at t = 4 and then remains in A2. This is because the message sent by the MessageSender chart at t = 0 remains in the input queue of the MessageReceiver chart till the MessageReceiver chart checks for the message at t = 4. Once the MessageReceiver chart checks for the message, it is marked as "consumed" and removed from the input queue. Subsequent checks for the presence of a message will return false since only a single message was sent at t = 0.
To summarize, this example shows the fundamental semantic differences between data, events and messages:
Unlike data, messages do not persist indefinitely. They have a finite lifetime and are destroyed once the receiver chart checks for the presence of a message.
Unlike events, messages remain in the queue till they are checked. They are not immediately discarded.