Right now, at the point where we would like to design some supervisory logic, we're going to be testing, start getting really confident about our design. Let's get back to the tool. I prepared here a model which representing my operating mode and error logic.
So designing power converter software is not only about PI tuning, but just one part of it. There is an entire spectrum of software construct that you need to implement to get a very stable system, such as state machine supervisory logic. You need to deal with errors and what happen when errors are reported to your system. And a very powerful tools to do that is called Stateflow for state machine modeling and development.
Here, I prepare such a thing as an example. This sub-chart is called Operating Mode Management, and we can simulate and see in action live. So, at the beginning, we would like to have our system output nothing at all. And then, we have two parallel chart, which are taking care of the operating mode. We saw them highlighted briefly.
So you may want to work with open loop. You may want to work with a current voltage open loop but current closed loop or vise versa, closed loop for the voltage, open loop current, everything as closed loop, or in some kind of automatic operation, which, at first, you are open loop, and then, you're waiting for the voltage to settle. And when you're acting with the error of the voltage, you actually go into closed loop mode.
So this is something that may be very common technique to model state machine with power converter. Again, we have our checking fault subsystem, which runs parallel to the other one, so always check if our system is OK or not. In order to test this state machine, I've created, again, a unique test using Simulink Test.
I used one of the provided logic, and I'm not going to spend a lot of time on this because this is a topic mostly for Simulink Test interest. But I break my loop using a unit delay, and I can do that because this is a discrete system, not a continuous one.
As I said before, for discrete system, is OK to use a unit delay to break the loop. And I have a test sequence, which allows me to write fairly complex test sequences to stimulate my chart. So, for instance, I can have my input change, and then I can react to this change, with some kind of verify on or asset statement that I'm going to validate my design.
We can see it here. So we have our input, our output. I can specify transition, and I can add description of what I would like to do during this time step. And then I can always use this verify statement to see, OK, I would like to go in this desired operating mode after one second, I will verify that the two outputs are actually behaving as the requirement that I have for this operating mode.
So if I simulate here now, we'll see that there are some slowing down, and if I look at my diagnostic, I will see that I have already some kind of warning in it. And one of them will be that there was a slow down
because test verification failed at around 4.2 seconds and again at 5.3 and 6.4, 7.5. I have all these test verification failed because of this step.
So I could click here and go verify why this step actually failed. It failed to verify that the zero output enable should be false. But, in reality, it was probably still true. And if I look at my Data Inspector, I can retrieve directly the result of this verify statement here.
And I have, for instance, this one, and I see that when I try to do it fast, that's all fine. But in this case, some of them were actually wrong. And here can see that 4.2, I have this zero output enable should be false, but it was actually wrong. That means that my zero output enable stayed true instead of being false. I can automatically generate a report from my Data Inspector to document these kind of processes.
So let's go within my operating logic, and I see that actually, yes, my checking fault, it's always true, and it's never going to false. And this happens because I don't have an actual something that tells me to have a system which is OK. So I add now the transition when I should go to OK.
Well, I should go to OK when my flag fault exist is zero, so there is no fault. So here I'm writing this note, flag fault exist should be zero. Then I have, in a system, which enabled my OK, which disable my output. And this enables the zero, only zero as an output. So I would like to have something else, not zero.
And here again, I should put the condition that if the flag is back on, we could actually be like this because it's a Boolean. So I don't need to put any kind of transition. If it's true, is going to be on this fault. So I can repeat my test right now. And see what happens these times.
I can actually open up my step here, and I can see how it's doing everything at a different step of my test, very convenient, very similar to Stateflow itself. And if I now I have no diagnostic, if I look in my Data Inspector, I see that all my result, everything were either untested or passed. But I don't have any fail anymore, a lot of green. And I'm happy about that.
So let's go back to our presentation. What we saw is a third way to model graphically called Stateflow. You can use this to model state machine, and it's very powerful. And in the company and complement well, Simulink can Simscape are the three main platform for graphical modeling within the Simulink world, we can say.
Discovered as well that we provide Simulink Test that allows you to create this kind of unique testing. You see here something I didn't show, the Test Manager. You can then-- all these harnesses that you provide to different subsystem, can reduce that the model level or can be put together in a suite of test in order to be done automatically with automatic reporting.
You tun the test, you get your result, document it, and you provide an example that say, look, I did my job as an engineer. Here is the report that proves that I tested as much as I could. You can add coverage measurement and start really getting these verification and validation workflow going.
