Hello.
My name is Fred Banser.
I'm a software developer at MathWorks.
And today, I will be demonstrating
how to model input events within Simulink.
This will not only allow for your models
to be able to react to incoming data,
but it also will allow you to be able to detect faults
with source data if it's not getting updated appropriately.
And so with that, let's jump straight into the demo.
Starting with a model that has a import we would like
to trigger off of, we first have to define a partition
to execute when a port is written to.
To do this, we create a subsystem
and configure it to be an API partition named "Logic."
This will act as an entry point that
will get executed whenever its associated event is triggered.
Next, we will add some elements to execute
within the partition.
For this demo, we're simply forwarding the receive message
to outport 1.
Additionally, the partition will send the constant message
to outport 2.
This is so we can easily observe when
the Logic partition executes.
After defining the partition and wiring it to the outports,
we now need to configure our input port
to raise the event when data is written to it.
To do this, we could open the Input Port Blocks dialog
and navigate to the new Execution tab.
From here, we could add a Input Write trigger
and set the event we would like to raise.
For now, we will leave this as Auto,
which will generate a new event for us when
we update the model.
After updating the model, we can see the Schedule Connector
indicating that the new event In 1, Input Write is set
to execute the Logic partition.
This can also be observed in the Schedule Editor.
We can open the Schedule Editor window
by clicking on the subsystems partition badge.
In the Schedule view, we can then
see that the Logic partition will get
triggered by In1.InputWrite.
At this point, the model's partition
is now set up to execute whenever
data is written to input port one for the model.
To simulate the event-triggering behavior,
I have referenced the previous model
that we just created into a composition model
and named it "Sync."
This pair model will drive the Logic partition
by writing to the queue block from an aperiodic source.
The source is set up to sample a sine wave
and write to the Sync model's input at random intervals.
To make it even more interesting,
the source will also periodically sample the data
twice during a given step.
Let's run the model.
We could see from the two scopes in the model
that, each time the data was sampled,
indicated by the red data points,
the Logic partition was executed and produced
the expected output, shown by the blue-colored data.
We can also see how data is flowing through our model
via the Sequence viewer.
During the setup phase, we can see
that, as data is sent to the Sync model,
the Logic partition reacts within the same time step,
even though the sampling is varied.
However, there is a problem.
In the case where we're sampling multiple times
within a single time step, we can
see some data loss occurring.
This is because the message queue is overflowing.
There are several ways to resolve this.
One way is to update the queue to contain more samples.
Another way is to alter the scheduling
priority between the sensor and Logic partition.
To do this, we can open the Schedule
Editor in the composition and look at the execution order.
We could see that, when we previously ran these sensors,
partition was a higher priority than the Logic partition.
This prevented the Logic partition
from reading the samples immediately from the queue.
To fix the data loss issue, we can switch these two partitions
on the exact order list.
This will allow the Logic partition
to preempt or interrupt the sensor in order to process data
as it comes in.
Running this model again, we now see
that all the samples in the multi-send case
are handled immediately, leading to no data loss
within our system.
Addition to scheduling on Input Writes,
we can also schedule partitions to run
when there is a lack of input.
This can be useful for detecting things like stale signal
data or disconnected sensors and allow
for some corrective action to take place within our models.
These types of event triggers that detect faults in data flow
are sometimes referred to as "quality of service" or "QoS."
From our original model, we now added two new subsystems,
a switch and a new partition named "Corrective Action."
This will handle the output when there is a significant gap
between Input Writes.
The Logic partition was also updated,
so it's import is now a signal.
The reason for this change is to demonstrate how the input event
triggers can be applied to incoming data,
regardless of whether the input values are buffered,
as shown in this current model, or, as with the previous demo,
queued through Simulink messages.
When executed, the Corrective Action partition
will switch the output to a ground value
when the timeout occurs.
In practice, corrective measures can
vary depending on the use case, such as switching
to a backup sensor or extrapolating the output based
on previous data.
In this case, we're zeroing out the data.
Similar to the previous demo, we will also
publish a constant message.
This is so we can easily observe the times when
each partition is executed.
With our partitions defined, the next step
is to set up the timeout trigger on the import.
To do this, we can navigate back to the Imports Execution tab
and create a new trigger, Input Write Timeout.
In this case, we'll specify a timeout of one second.
For the timeout event, instead of using
the auto-generated event, we can instead
specify a user-defined event.
To do this, we could navigate to the Schedule Editor window
and create an event in the Events pane.
Once created, we now need to bind it to the Corrective
Action partition.
This can be done by simply dragging
the event onto the partition in the Schedule view.
With the custom event configured,
we can now select it in the Event dropdown for the Input
Write Timeout.
The model is now ready to be simulated for timeout events.
To simulate the timeout effects, we also
modified our composition model.
The sensor model now has an on/off switch and new sampling
logic.
Looking at the sampling logic, we
are still sampling at a variable rate,
but we now have a new off-state.
This new state prevents the sensor
from producing new samples and acts as if the sensor is
disconnected from the system.
This should lead to a timeout event
occurring in our Sync model.
We are now going to run the model in a paced mode.
While the sensor is on the on state,
we should see a sine wave amplitude two
in the right graph.
When we switch the sensor off, we
should see the signal go to zero after the one second timeout
duration is exceeded.
Looking at the hit time plot on the left,
we should also see the graph switch
from executing the Logic partition in blue
to the Corrective Action partition in orange.
Additionally, the Corrective Action partition
will repeatedly execute at the timeout interval
until the sensor starts to produce data again.
In summary, this has been a quick tutorial
on how you can easily use input events to schedule and simulate
data flow and Quality of Service within a Simulink model.
Thanks for watching.