hello and welcome to the webinar on
control logic design made easy with
stateflow and Sidharth and the product
marketing manager for stake flow at the
math works I have a background in
mechanical engineering before we get
into our presentation today I'd like us
to have a brief look at the example that
we will try to build we will bird the
control logic for a cooling fan system
in-state flow today so the model
essentially consists of two parts first
is the engine second is the fan
both of these are turned off initially
once the device is turned on it
generates heat this raises the
temperature of the engine the cooling
fan switches on when the temperature of
the engine exceeds the threshold it then
switches amongst the modes of low and
high to regulate the temperature off the
engine within a desired range the fan
turns off when the engine is turned off
to build redundancy into the system we
will use two fans in case the first one
fails the backup fan should start in
case both the fans fail then the system
should just stop with a bird control
logic for this system in stateflow let's
have a quick look at what the model
looks like in Simulink and stateflow the
model in simulink has three parts the
first part is the logic of this control
fan system which is actually built in
state flow the logic looks at a high
level like this the second part of this
model is actually represents the fan it
uses the voltage of the fan as an input
and outputs the RPM of the cooling fan
so the input which is the voltage of the
fan will be different based on the mode
that it isn't whether it's in off low or
high and consequently the RPM of the fan
will also vary the third part of the
system actually models the engine so it
takes the power of the engine the input
power of the engine and then it takes
the RPM of the cooling fan as an input
and it takes the ambient temperature as
an input
to output the device of this engine I
have a couple of knobs over here one is
to actually control the input power of
this engine so this is this was
essentially to simulate a variety of
engines let's say that I had an engine
would use a different amount of power
and consequently generated a different
amount of heat I could represent that
too and then the second knob that I have
over here this is to change the ambient
temperature because that would affect
what the temperature of the device would
be - apart from that I have a couple of
switches over here on the left these
switches are to inject failures into the
system so right now both my fans are in
fail mode so if I turn this on which
means that my fan has not failed and
this is working if I turn the second one
on this means that even my backup fan is
working in both our in work current
working condition inputs into my state
flow portion consists of the temperature
of the device this manual switch which
is used to control whether the device is
just turned on or off by the user the
simulation time and the RPM of the
cooling fan state flow uses these four
inputs to compute whether the device
should be switched on and then what the
mode of the fan should be let's run this
model and see how it behaves as I run my
model I can see that my states and state
flow are changing the temperature rises
and then it gets regulated let's now add
injector failure into the system let's
brake cause the first fan to switch off
let's see how the system behaves now you
can see that the temperature initially
starts rising and then it gets regulated
by the second fan let's actually now
cause even the second fan to fail and
let's see how that behaves once you
start that you see that your device is
turned on the temperature rises but then
the device is turned off right after
that and the temperature of the device
doesn't increase because there it gets
turned off immediately so this is the
sort of redundancy and the conditions
that we will try to model today let me
now go back to my presentation as we
start out so overall in today's
presentation I will start by providing a
high-level summary of what control logic
is and the challenges that that are
involved in modeling it
we will then compare some alternative
approaches that I used to model control
logic in the end I will walk through an
example of how to model control logic
in-state flow
so let us start by talking about what is
control logic wikipedia defines control
logic as a part of the software program
that controls its execution control
logic in my mind has two main
characteristics first it tries to model
a sequence or modes of operation think
about an automobile in the automobile
the engine reacts to the throttle
differently based on the gear that the
vehicle is in or consider a rocket
launch it goes through a sequence of
stages as a rocket tries to take off
similarly robots though they move
continuously they have distinct modes of
operation the other characteristic of
control logic is that it needs to react
to commands from the user but it also
needs to perform automated tasks that
have been structured into the program
this logic is typically implemented in
programs using time-based conditions
boolean logic and events programs that
we have found to contain a lot of
control logic are those that model
supervisory logic task scheduling and
fault management so these are three
kinds of programs that are very heavy in
control logic so what are the main
challenges of designing control logic
one challenge is that modes of operation
are quite difficult to represent with
traditional approaches like handwritten
code these approaches typically require
the use of memory blocks persistent
variables switch case and if-else
statements to create more logic and this
adds unnecessary bookkeeping steps the
complete design process now add to it
the complexity of various events and
conditions that the system needs to
react to and the logic becomes very
complex because of this complexity
trying to understand how the logic
behaves and debugging it can be quite
difficult so now let us look at an
approach that we suggest you should use
for modeling control logic we recommend
that you use state machines and
flowcharts in state flow to model
control logic well I see this
because with these two approaches you
can represent the components of control
logic very well first let us look at
state machines state machines are a
natural representation of the modes of a
system in the image on your screen the
system actually has four modes 1st 2nd
3rd and 4th think about these as the
gears of your automobile or other modes
and the system moves between these modes
based on an input up or down next we
recommend flowcharts as these make it
very easy to model processes that
contain complex conditional or
combinatorial behavior these two
constructs put together can be used to
represent control logic in a clear and
concise way state flow is a tool that
can model state machines and flowcharts
in it you can create both graphical and
tabular representations of state
machines and flowcharts I will talk
about this in a few minutes as I walk
through state flow one more point that I
want to bring up in state flow apart
from being just being able to create the
logic you can also simulate it and view
its behavior using animation like in
this example you can see that the states
are actually getting highlighted as they
become active the capability to simulate
and animate along with an integrated
debugger makes it very easy to step
through your logic and understand it so
your question at this point would be why
can't I adjust you symlink or code this
up myself and see well you could do that
for simple systems let's look at an
example in my example over here
it's an actuator which has three modes
of operation this can be built up in
simile as this diagram and of course you
can also write this up in about 50 lines
of C code for a program as simple as
this either approach can be used and if
you're comfortable with these other
approaches then they can do the job but
very often logic for your system becomes
complex very quickly for example what if
you now need to detect if the system has
developed an error and you should switch
of then if attempts to recover it fail
the actuator should actually be isolated
your system now starts looking like this
and then what if there are two actuators
with backups for each and since there
are backups there needs to be logic for
controlling when to switch on the
backups
whenever the primary actuators are
isolated and so on and so forth so your
model now starts looking like this and
representing this system will probably
need a thousand lines with memory blocks
switches persistence etc and all that
stuff to be maintained and then if you
want to understand the relationship
between components and understand how
the logic behaves without visualization
that can be quite challenging but with
graphical representation of state
machines and flowcharts and state flow
this logic can be represented easily you
can not only represent this logic but
you can also animate it using simulation
to understand and debug it let us now
have a look at how state flow makes the
modeling of such logic easy this is a
slightly simpler version of the model
that I've shown you at the beginning of
this presentation so I removed the
couple of switches that we had for
redundancy or to inject failures into
the system and the other thing I removed
was the state flow block I removed this
block so that I could add it back and
tell you how it could be added so to add
actually the states will block to the
Similan character from the Simulink
library browser go to the state flow
block library in this library there are
blocks to represent your logic
graphically using state diagrams and
flowcharts that is these two blocks if
you would like to use tables to
represent your logic then you should use
state transition tables or the truth
table block the state transition tables
are just a tabular representation of
state machines and truth tables are
useful for representing combinatorial
logic in today's presentation I am going
to focus on the graphical
representations of logic which is state
diagrams and flowcharts so I will be
using these blocks and then why are
there two blocks well if you like to use
the C syntax and language
for defining conditions and actions in
your flowcharts then you should use the
first block if you would like to use the
MATLAB language and its syntax for
defining conditions and actions then you
should use the second block in this
presentation today I am going to use the
block that uses MATLAB to open the state
flow editor just double-click on this
block notice that you're now in the
state flow editor which has a graphical
palette on the left which contains
objects to create state machines if you
would like to have easy access to both
your Simulink model and your state flow
editor at the same time you can right
click and open state flow in a new tab
so now you have some link and state flow
in two tabs
representing mode logic is very easy
using state machines for example think
about your device the device has two
modes on and off this will be
represented with two states on and off
to create these States just click on the
state object from the graphical palette
and drop it into the state flow canvas
change the name of this state to off and
to create the other state on this right
click and drag this to create a copy now
you have two states off-and-on
representing the two modes of operation
of your device to specify which state
the system should start in select the
default transition object and drop it on
the state off now we need to create
logic for when the system should
transition from the off to the on state
talking about the device it should go
from off to on when the switch is turned
on in other words when the variables
switch on is equal to 1 similarly it
should go from the on to the off state
when switch on is equal to 0
so now you have two states and do
transitions which are guarded by the
value of the switch input variable so
far we haven't created any data for the
state machine in the off State
I would actually also like to send an
output device underscore on to symbol
Inc this value should be 0 in the offset
and it should be it should be 1 in the
on state let's run this model and see
how it behaves now this brings up the
symbol wizard which identifies that we
have two variables switch on and device
on which are undefined in the state
diagram
one should be an input whereas the other
should be an output based on its usage
this is all you need to do to create
these variables in the Similan canvas
you can see that the state flow block
now has a port for an input and an
output let's connect the device on
output to the right port and similarly
connect switch on to the input port
let's try to run this model now see that
goes into the off state since the switch
is already turned on it goes into the on
state good that works so now what I
would want to do next is to actually
contain this logic for my device within
another state called device logic the
logic for my fan is going to be similar
to the logic for my device so I could
actually create a copy of this state and
then start editing it creating a copy
again is easy right-click on that state
and drag and drop it let's change this
so that this represents now the logic
for my fan it should send a variable V
underscore fan
okay now let's try to run this I see
that is identified a new variable V fan
yes I would want that to be an output to
similan I say okay let's run this again
now it identifies that there are no
default paths to a particular state I
see so what is trying to say is that
there is no default transition on the
device logic or the fan logic state so
it doesn't know which one should we
start it should start with well an
interesting point to note here for the
device we should only be in either the
off or the on state at a time similarly
for the fan logic we should either be in
the off or the on state but the state
device logic and fan logic should
actually be executing simultaneously
because my device and my fan should both
be working parallel II to implement this
right click on the state flow diagram
and change the decomposition to and this
changes the borders of these states two
dashed lines which means that during
simulation these two states will now
execute in parallel let's run this model
now you can see that it gets into the
off state and beyond
and fan logic also goes into the on
state that's because I'm using the
variable switch on this isn't actually
correct because I don't want my fan to
switch on as soon as my device switch is
on so this should be based on some other
MIDI variable let's say that it's based
on a variable fan mode for now one
requirement for my design was that when
the device is switched off the fan
should also switch off so we will change
this to zero next when my fan is
switched on at that point
the fans are switch between off and on
to regulate the temperature of my device
so now I'm thinking of some condition
where if the temperature is below 65
then the define should be off whereas if
it's between 65 and 160 then the fan
should be on if it goes above 160 then I
should probably shut down my system this
can easily be represented using a flow
chart creating flow charts is very easy
in-state flow using the pattern wizard
so just go to the pattern wizard from
the file menu and select from a variety
of patterns that you can automatically
create so in my case I need an if-else
of structure so I open the pattern
wizard and in this star type in my
condition
let's say when my temperature is less
than 65 then the fan mode should be
equal to zero similarly when T is
between 65 and 160 then the fan mode
should be equal to one one thing to note
is I still have an accountant for the
condition when the temperature actually
goes above 160 we'll deal with that in a
couple of minutes so right now when I
click on that it creates a flow chart in
my side diagram I would like to call
this logic in the on state so to do that
I should actually create a graphical
function that actually contains this
logic and give the graphical function
name and pass it the input T this
function should actually get cored while
I'm in the on state at every time step
so I will say func underscore fan mode
and pass it the temperature of the
device I can either choose to look at
all these details under in the graphical
function or I can hide them by actually
going and sub charting them this will
save me real estate when I simulate
let's try to run this model now it
identifies two variables these three
device should be an input which is
correct to the temperature of the device
and the other is a fan mode that I have
locally used these are both correct
so that's switch okay let's go and
connect these
so let's run this to check again starts
goes into off device goes on fan goes on
the temperature is rising continues till
it begins to cool down but it still goes
past 160 now if you remember the
requirement initially was that the
device should not actually go beyond 160
so I need to have some logic where if
the device actually does go above 160
degrees then it actually switches off
and the fan still stays on so that it
can cool the device down and after the
temperature of the device has cooled or
it's gone below 65 that's when my fan
switches off so maybe I should have two
more states over here the first state
when let me draw this quickly so maybe I
should have another state
for cooling down in which the device
should turn off and then the fan should
still be on and this should happen when
T becomes greater than 160 and then same
way after it has cooled down which is
which means that after my temperature
has become less than 65 then I go into
standby my device has already been
turned off in the previous state so what
I care about is turning my fan off over
here and then if my device has already
switched off which is switch off button
has been clicked in that case it should
go to the off state so now I'm I have
logic for the device actually going from
the on to the go down state to the
standby state and only after it has code
it goes to the off State this is a
fairly crude model because I still don't
have the three modes that we wanted for
our fan that I just do modes the off and
the on so I'll quickly open up the model
that contains the three modes of
operation for the fan I'll walk through
it let's look at this model now in this
new model I've made a couple of changes
one the device logic I've got rid of the
transition going from device on device
off when the switch is turned off I
essentially always want the device to
first cool down and then go to device
off so I move that condition as a
compound condition to this to the state
going down the other thing is that I
have now added three states for the
three modes of the fan instead of having
just off and on there is off low
and hi if the fan mode is set to zero
the fans which is off the fan mode is
set to one it's goes to low if it is set
to two it goes too high and the fan
modes are set in this graphical function
instead of having to F else's now there
are three let's run this model and see
how it behaves the temperature has
started rising device goes on the fan
goes to the low mode and as the
temperature would pass the second
threshold would be interesting to see
what happens at 130 degrees so it's
already started cooling down okay so it
goes to fan high mode oh what's actually
switching between the high and the low
modes as it has reached 130 this is an
example of how animation made it very
easy for me to identify a problem this
behavior would actually damage my fan so
what I need to have is some time-based
logic which would be which is very easy
to do in state flow I can actually say
in case when fan goes 1 and after 30
seconds only then take this transition
so now the transition condition is
compound it says go here only when the
fan mode is 1 and I have been in the
high mode for 30 seconds so let's run
that and see if that works so
temperatures again get getting close to
30 within the low mode once it gets to
130 it should go to the high mode but
then it should stay in the high mode for
30 seconds and shouldn't oscillate the
way that we had seen it oscillating
earlier this is good ok because it goes
down stays in it for 30 seconds and only
after that comes up
okay good
stop the simulation now so so far we
have Bert logic with one fan having
three modes and the logic for the device
and then how the fan should cool the
device down when it is when there's a
stopping or when it becomes overheated
what if he had two fans to show that I
will open up the earlier model which had
two switches for injecting failures into
the system so let me open that
okay now let's have a quick look at the
model in simulink there's the same model
that I've shown you in the beginning of
the presentation it has a couple of
switches for injecting failures into the
system let's go back into state flow for
actually extending this model from one
fan to two fans I didn't have to do too
much work all I need to do was actually
change the V fan into a vector and index
into it using this fan ID the index fan
ID is initially set to one and then if a
failure occurs which I check at this
transition using the function then the
ID is changed to two and then we get
back into the same state and now we are
actually indexing into the second
element of the V fan vector now I do not
need to change any data in state flow
because it's being inherited from
similan as long as the dimensions of the
data are changed in Simulink the changes
will automatically reflecting state flow
another thing I wanted to point out that
is fine broken is a MATLAB function that
I used to calculate or compute if the
fan is actually broken similarly if you
wanted to process any data and call your
custom MATLAB functions at any built in
MATLAB functions you can just call them
anywhere in the state flow diagram and
they will just work so let's try to run
this model now you can see that the fans
which is on goes to the low mode and the
temperature is regulated good now let's
inject a failure and caused the first
fan to fail it starts in the off mode
then goes to the low mode there's a
failure it goes fine broken goes to oh
it's going into the same state again and
again well I would like to understand
why it is actually taking this
transition more than once I would
imagine that once it's only when the fan
is broken that it would try to take this
transition once so to look more closely
at what's happening at this transition I
can actually set a breakpoint at it so I
can set two kinds of breakpoints and
transitions one will check when the
transition is valid and another one
checks when it is being tested here I
want to check when the transition is
asked
valid and it's taken to let me run this
again so easily now I I can stop my
simulation at this point I can hover
over the breakpoint and see that the
breakpoint is set up for when it is
valid let me
hover over the function to see the data
using it I can see that fan ID is 1 let
me again step forward and see when it
stops again so it comes back and stops
at the same function now if I look at my
variables interestingly I note that my
fan ID is still 1 and now if I try to
look through this again when it gets
back into the state it takes a default
transition oh and my default transition
is actually defining finally to be 1
when it starts out so it again and again
sets the ID to 1 and it never and this
change is actually not affected so to
fix that let's stop this first what I
need is some mechanism for the system to
remember the fan to remember the mode in
which the older broken fan was and the
new fan should start start directly in
that it shouldn't actually go through
the same process well I can do that in
state 4 using the history Junction so
placing a history Junction within a
state means that next time when the
state is reentered it will directly go
into the state where in which it was
before it was being exited let me show
what I mean so so we run the system the
first time it's in the off goes to the
low goes to the transition here I see
fan mode ID is 1 let's run this again it
goes back and notice in the second time
it didn't actually take this process it
went directly into the fan low mode
because that's the state in which the
system or the fan was when it exited ok
by clicking on the breakpoint I can
bring up this menu where I can check if
I want to set the breakpoint or remove
it as we move the breakpoint and now try
to run the system again
good I can see that the temperature is
now being regulated now actually let's
try to break even this second fan and
see how that behaves so I run my system
goes into the off state low state takes
the transition comes back ha
at this point it's trying to break this
transition but it can't obviously
because fine IDs too and this condition
is not satisfied let's start the
simulation so I guess what has happened
here is that for the first time it takes
the transition starts indexing into the
second one but when the second fan is
broken we still haven't built any logic
requirements for that word that if both
the fans are broken then the device
should probably be isolated and the
whole clan system should stop so adding
modes as I've said is very easy in state
flow for the fan to stop just create
another state called stop and and here
we use functionality similar to a
flowchart to actually go to the stop
state in case the first transition is
not true
which means that finite is not equal to
1 which means that if it is 2 then it
should actually go into the stop state
but the other thing I wanted to do no
matter what state I'm in over here the
device should always go to an isolated
State well as we've seen earlier with
this state that's easy to do because you
can just surround this with a running
state and then place a new state called
isolated which is active whenever some
condition is true the condition is
essentially that this transition is
taken off so I would need to communicate
from this transition to this state that
it should now take this particular
transition to the isolated state I can
do that using an event so what I will do
is I will send an event the underscore
isolate to the device logic state
let's look at this command more closely
what I'm saying is when the second
transition is taken which means that I
know that the second fan is also fared
send an e isolate event to the device
logic state and then within this state I
should go to the isolated state when the
key isolate event has encountered okay I
have functionality for stopping the fan
and also isolating the device and when
the device is isolated it should
actually turn off okay
let's place a default transition on the
running State this is to signify that we
will by default always start in the
running State and will only go to the
isolated state if the event a isolate
has encountered let's try to run this
now okay the symbol wizard identifies
that there is an e isolate local event
that's good now let's try to run this
now as we run this we see it gets into
the device off on first second fan stops
goes into isolated and the temperature
profile I see that it starts rising but
soon after it drops off because the
device has actually switched off okay
good this was an example of how you
started to develop a simple system but
it becomes complex very quickly using
state machines we were able to easily
start and extend our design to represent
the modes of the components in the
system the device started out with two
modes but then went on to have about
four similarly the fan started with a
simple model with just two states on and
off but then we were able to easily
extend this to have three modes of
operation we use flow charts in state
flow to represent the decision logic for
the fan mode we also essentially used it
to represent the logic to stop the fan
system when the second fan has failed
during the design process simulation and
animation in state flow made it easy for
us to understand the behavior of the
system the animation also helped us
verify that the system was working
correctly but in some cases it also
helped us identify the specific issues
that were causing the problem at this
point I will go back to my presentation
in PowerPoint so we look so far at how
to verify your designs visually using
animation in state flow but you could
also verify your designs much more
formally using the verification and
validation products that are part of the
Similan product family using the Similan
verification and validation tool you can
map requirements to state flow objects
directly you can check for compliance
with standards and you can collect model
coverage metrics when using safe flow
with the design verifier you can detect
design errors and generate test vectors
using more formal methods after having
created your design you can also
generate C C++ code using the symbol
encoder or you can generate HDL code
using the HDL coder and PLC code using
the PLC code a product in the selling
product family so to recap we learn
today that state machines and flowcharts
are the best tool to model control logic
then we then looked at how to create
edit and debug your diagrams using the
visualization in-state flow in the end
we looked at the code generation and
verification and validation capabilities
briefly for more information I would
encourage you to go and look at the
other videos in the state flow product
pages the math books also offers formal
one-day trainings which are both online
and in-person I would encourage you to
go and look at the training website on
the matrix
age and there are other webinars that
might be of interest to you related to
fault management are getting started
with revised more details about the
construction state flow and there is
more advanced webinars about design
patterns and how to implement
large-scale modeling which state flow
this concludes this demonstration