Control Logic Made Easy with Stateflow

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

Channel: MATLAB

Views: 37,320

Rating: 4.8883247 out of 5

Keywords: MATLAB, Simulink, MathWorks

Id: m4xT7PEz8eY

Length: 38min 31sec (2311 seconds)

Published: Sun May 21 2017