As our devices get smaller and systems get embedded into everything, there is a greater need to properly model inter-system communication. Let's take a simple example: imagine a smart thermostat that is wirelessly connected to several temperature sensors distributed throughout a building. Those sensors report data at 100 Hz. The controller in the thermostat, however, runs at only 1 Hz to save costs. If we wanted to capture and analyze all of the temperature data received from the sensors (rather than downsampling), how could we model that in Simulink and Stateflow?

Incoming!

The answer, as of R2015b, is Messages.

That new funky line style between the Stateflow charts indicates that the connection is a message, a brand new object type. Like events, they are "sent", and transitions and state actions can be guarded by their receipt. But unlike events, they do not interrupt the execution of the sending chart, nor trigger the immediate waking of the receiving chart. They also carry data, of a type that you specify.

Messages extend the semantics of Stateflow to allow you to easily model distributed and multi-rate systems like the one in our example. The sending chart packs the temperature data into the message and sends it at 100 Hz. The message is queued at the receiving chart, which can decide whether to take messages out of the queue in FIFO, LIFO, or customized priority order.

Processing the queue

The method to process the entire queue in the receiving chart starts with a for-loop design pattern, like so:

But there's one more addition needed. When the receiving chart takes a message out of the queue, that message usually sticks around for the remainder of the time step. Thus in the pattern above, a new message would be read in only the first time through the loop - all the other iterations would just keep reading the same message.

So to discard a message you've already read, in order to be able to read the next one in the queue, you can forward that message to a "trash message" output:

Now it's your turn

Check out some of our examples in R2015b that use messages, like sf_msg_traffic_light and sf_msg_priority_queue_server, then let us know in the comments below how you plan to use messages to model your application.