getting started with stateflow video -凯发k8网页登录

stateflow is a graphical environment that allows you to design and simulate decision logic for supervisor control, task scheduling, and fault management applications. this video will show you the basics of stateflow and give you an idea of how to use it to model decision logic. at the end, we'll show you where to go next to learn more about stateflow and start using it today. so let's get started.

mathworks has roof mounted solar panels at our headquarters in natick, massachusetts. these solar panels can help to reduce our electricity costs and dependence on fossil fuels. in fact, they provide about 8% of the mathworks energy needs.

pairing the solar panels with a battery lets us collect solar energy and then use it when we want. the energy produced by these solar panels varies throughout each day. this makes it difficult to find the best way to use the energy collected.

let's assume our building uses 200 kilowatts and the panels will charge a 3 megawatt hour battery. this acts as a buffer to power the building when it's not sunny. now we need to decide when to use the grid and when to use the battery so we can reduce the electricity bill. we need to represent all these operating modes and make decisions about when to transition between them.

fortunately, we have stateflow, which can do all of this and more. electricity is priced differently throughout the day. the battery will save us the most money if we can use it to avoid the highest prices.

based on what time it is, we want to be in one of the two operating modes. we can represent this as two separate states using a finite state machine. we'll either be using the grid or the battery if it has enough charge. if the battery gets drained, we'll fall back to using the grid. only one operating mode will be active at any time.

we're going to model our finite state machine with a state flow chart. the hardware is already modeled in simulink, so we can just load the model and add to it. the model's input data is the power in watts coming from the solar panels sampled every 15 minutes. we have a year's worth of data. so that's how long our simulation will be.

we'll use this data to determine if it's sunny with our weather detector. we also need to know the time of day. we'll make decisions based on the battery level. so we have a plan model for the battery, and we monitor the stored energy with a scope.

last, we've set the solver to a fixed step solver to match the sampling rate of our solar data. you can use stateflow with continuous systems. but for decision logic like this, it will usually be discrete time.

ok, so that covers everything that was already built. but we need to make decisions about when to use the battery and when to use the grid. how can we do that? we can do this by adding a stateflow chart to represent our decision logic.

we'll start by dragging a chart block from the stateflow library into our model. now let's connect our signals to the chart so we can use them inside. since our signals have names already, we can drag them onto the chart block. and the port names will be set to the signal names.

as we drag the other two signals onto the chart, two more ports will be added. it's starting to get a little crowded, so we'll resize the chart block. last, we'll rename this chart block to building manager. now we're ready to build our decision logic. and inside we can use all the signals we just connected.

the energy system within our building can switch between using the grid and the battery for power. we'll represent these two operation modes using two states called use grid and use battery. we also need to tell stateflow which state to enter at the start of our simulation by adding a default transition.

we'll start out by drawing power from the grid. so the default transmission will go into the use grid state. after we've collected some solar energy in the battery, we should then consider switching to the use battery state. so we'll allow transmissions between the use grid and the use battery states by connecting them.

in stateflow we can use square brackets to specify a condition and curly braces to specify an action. every 15 minutes, we need to decide whether to use the grid or the battery for the next 15 minutes. to reduce the total energy cost, let's try to use the battery first whenever possible.

to meet the power demand of 200 kilowatts for 15 minutes, the stored energy must be greater than 50 kilowatt hours. so we'll use this condition to guard the transition from the use grid state to the use battery state. if we're using the battery and its stored energy drops below 50 kilowatt hours, we'll use the grid again.

next, let's specify the state actions. in stateflow, states can have different action types, including entry, during, and exit actions. entry actions are performed if something happens on the way into a state. during actions are performed when remaining in a state. and exit actions are performed on the way out of a state.

when entering the use battery state, we will use an entry action to set the battery usage rate to 200 kilowatts. when leaving the use battery state, we'll use an exit action to set the usage rate to 0. later, we'll make the usage rate an output signal and use its value to adjust the battery level of charge in simulink.

there's no cost for using the battery since its energy comes from the sun. on the other hand, when using the grid, the energy price is $0.20 per kilowatt hour, meaning the energy cost will go up by $10 every 15 minutes. so we should increment the energy cost when entering or remaining in the use grid state with entry and during actions. also, let's not forget to specify a 0 initial value for the cost.

all right, that completes our first state transition diagram. we're off to a really good start, but there's something missing. the energy price of $0.20 per kilowatt hour is only valid for off-peak hours. for peak hours, the energy price is $0.30 per kilowatt hour.

so how can we accommodate for the time varying prices? well, to be able to track the time, all we need is another state transition diagram. and we already know how to build one in stateflow. with that, we can easily know what the energy price would be based on the time of use.

now we have two separate tasks, tracking whether it's off-peak time or peak time and managing the energy sources. to organize both, we'll introduce two superstates called time and energy manager. using state hierarchy helps us to better organize, structure, and manage our decision logic within stateflow.

by default, only one state can be active at any given level, which means the state flowchart has an exclusive decomposition. that's the reason why stateflow is warning us that we don't have a default transition. but actually, we don't need one at this level.

we want to track the time and manage the energy sources concurrently. so let's switch the chart decomposition to parallel. we call these parallel states. but in reality, things must happen in a particular order. stateflow lets us specify the execution order for each parallel state, which helps us to avoid ambiguities in our decision logic.

next, let's check the execution order for these two parallel states. to be able to calculate the energy cost, we need to know the current time first. so the execution order is already correct.

now that we're tracking time of use, we can simply follow a flowchart to determine the current energy cost. is it currently during peak hours? if yes, then the energy cost would be $15. if no, then the energy cost would be $10.

ok, back to our state flowchart. let's redo the energy cost calculation based on the time of day by adding a flowchart. this time the default transition takes us to a junction, and we'll branch out from there. we can use the in operator to detect the time of use.

if it's during peak hours, we'll take the first branch, and the action is to increment the cost by 15. otherwise, we'll take the second branch and increment the cost by 10. just like for parallel states, it's important to have the correct execution order for each transition. for example, if the execution order is backward here, the right branch would never be checked.

next, we can use the symbols pane to define our symbols being used in our chart. notice that we already have three input symbols, which correspond to the three input ports that we created from the top level model. let's click on resolve undefined symbols. this will automatically confirm the symbols we've used and define their data scope based on how they're being used. in particular, each of the input and output data symbols will become a port of the chart block.

since the energy cost is important to us, let's make it an output signal by changing its data scope to output data. going back to the top level model, now our state flowchart has output ports for the output data. now let's add a display block to capture the total energy cost and make all the connections. within stateflow, we can easily monitor the active state data for post-simulation analysis.

since we're interested in monitoring the energy usage at different times of the day, let's log the child activities for both superstates. we're ready to run the simulation by clicking the run button. the chart is fully animated during simulation, so we can see our states and transitions at runtime.

but how do we make sure our decision logic is working properly? let's pause the simulation and slow down the animation speed. we're using the grid at this time step. and we can see that we're in the off-peak state. our cost is $4,855 so far.

now we'll step forward one step and see that we were billed the off-peak price of $10. as we take another step, we transition to the peak state, and then we're billed the peak price of $15.01. one last step, and we've transitioned to the use battery state. as we would expect, our cost hasn't changed.

ok, it looks like our decision logic is working properly. let's turn off the animation and click continue to run the remaining steps. once the simulation has finished running, we can see the total energy cost from the display.

let's open the scope to see how the stored energy varies over time. we can observe strong oscillations in the stored energy from the varying sunlight conditions. using the battery as a buffering unit, we've managed to obtain a more stable energy source from the solar panels.

next, let's open the simulation data inspector. stateflow has saved the entire history of the active state data for us. the top display shows the current hour. is it peak or off-peak? the bottom display tells us the energy source being used, grid or battery.

after taking a closer look at these state activities, we noticed a problem with our decision logic. let's focus on this particular day. we can tell from the fact that it was switching back and forth that the battery could not accumulate much energy, so it must have been a cloudy day. as a result, we had to fall back to using the grid in the middle of the peak hours on a very steep price.

at this point, we regret using the battery when the energy price was low. to solve this problem, we can add some additional conditions. let's wait until we're in the peak state to use the battery. or if we're in the off-peak state, we can use the battery only when it's sunny outside.

this allows for more effective use of the limited solar energy that we've collected throughout the day. that's how easy it is to modify our decision logic within stateflow. in practice, we can iterate the whole design process as many times as needed until we have an optimized design.

now let's rerun the simulation. with this smart decision logic, the total energy cost went down by 2%. again, this is because now we're more conservative with the battery during bad weather.

meanwhile, the more conservative usage pattern can lead to higher peak values in the battery's stored energy. in reality, we should try to find the balance between using the battery too aggressively and too conservatively. in either case, stateflow can help us evaluate our decision logic and identify potential pitfalls.

we've used stateflow to model and simulate decision logic depending on the current state of our system. and you can, too. now that you have a feel for what working with stateflow is like, it's time to learn it.

the best way to learn stateflow is to work with it. so start up stateflow onramp, which will teach you the basics. it's free and it takes just a couple of hours. welcome to stateflow.