Real-Time Simulation and Testing: Hardware-in-the-Loop

Hi everyone. My name is Pablo Romero. I am application engineer at MathWorks and a specialist in real-time simulation and testing. Today I would like to tell you about real-time simulation from within Simulink. As you may know, Simulink Real-Time is the product from MathWorks that allows you to create real time application from Simulink, so that you can run any model in hard real-time on Speedgoat target computers.

It is designed for real-time simulation and testing tasks, including Rapid Control Prototyping and Hardware-in-the-Loop simulation. With Simulink Real-Time you can extend your Simulink models with Speedgoat I/O driver blocks, automatically build real-time applications, create instrumentation balance and perform interactive or automated runs on a Speedgoat target computer. 

This target is equipped with a real-time kernel, multi-core CPU, I/O and protocol interfaces. Furthermore, for demanding closed-loop sample rates, you can target Speedgoat FPGAs using HDL coder. Simulink Real-Time and Speedgoat are expressly designed to work together to create real-time systems for desktop, lab and field environments. This is the only software and hardware solution that supports the latest version of MATLAB and Simulink as the official real-time solution from MathWorks.

In this slide, we see the traditional V development cycle, covering from system requirements on the top left to system integration and calibration on the top right. In blue, we highlighted the two main applications for real-time simulation. On the left side, we see rapid control prototyping. My colleague Sonja Krzok, who also works in this area together with me, has specifically done a video talking about rapid prototyping. Please don't forget to check it out. 

On the right side, we have Hardware-in-the-Loop. This is specific of the verification and validation part of the V-cycle. This is the part where I will focus today. Don't forget that Hardware-in-the-Loop is very important if you consider certification workflows. For example, find here a screenshot of the ISO26262, where we'll find that Hardware-in-the-Loop is key for many ASIL levels.

Now, I would like to show you how this concept works. For Hardware-in-the-Loop simulation our starting point is always a Simulink model. We have defined our test input, our controller and plant models with some scopes to monitor results. As we are performing Hardware-in-the-Loop simulation, we have already available our embedded controller hardware that we want to test. Therefore, we can replace our controller model with some I/O driver blocks that will allow us to interact with our real hardware. 

Thanks to Simulink Real-Time, clicking on Run on target, we will generate a real-time application on one single click from our Simulink model. This will be transferred via the ethernet connection to the target computer hardware. And finally, we can test our embedded control hardware in real-time.

Hardware-in-the-Loop is very important because real control systems can be very complex. We may need to test the production controller before the final system is built or even available, or because testing on the final design is not practical, safe, or is very expensive. Thus, we reduce risk and costs, and we ensure seamless integration of different hardware components. 

This is the hardware set-up I will use for today's Hardware-in-the-Loop demo. On the right side, I have a computer running MATLAB and Simulink, which is connected via an ethernet cable to the Speedgoat baseline on the left. The Speedgoat Baseline is one of the smallest Speedgoat computers that you can find.

The main difference with other bigger systems is the number and type of I/Os that are supported. In case you wonder which model you may need; our engineers will help you to figure out the suitable system for you. 

And finally, on the very left side, you see in green the embedded controller hardware that I am going to test. In this case, it's a Texas Instruments board where I have already deployed my field-oriented control algorithm. Let's switch to Simulink and see how this works.

This is the Simulink model I will use for today's demonstration. It has the same layout as the one that we saw in the previous slide. So, on the left side, I can mark here in blue the field-oriented control algorithm. On the right side, I have my plant model. In this case, it's a permanent magnet synchronous machine. 

We can run our simulation and see how this model behaves. So, I'm switching to simulation over here. I can open the instrument panels, which float over my Simulink model. This is a very nice feature that you can use to embed instrument panels into your Simulink model. So, we can run them and see how my model is going to start and accelerate up to this velocity in radians per second that I have over here. Now the model is being compiled and the simulation will start to run in a few seconds.

By the way, I'm using the velocity mode. So, it's running in closed loop, but I could use also some other inputs. So now we'll see how the model has accelerated, has started, and has reached this velocity. And now we can directly use this dial over here we can modify the velocity. We can even, for example, restart the motor and we see how the velocity comes back to zero. We can restart it. And we also have some feedback about the controller status and so on. 

Let's stop this simulation, see what we have in this model. We can minimize the instrument panel by double clicking on them. And now let's see what we have here. First of all, let's have a look into my PMSM plant model.

So, in this subsystem, we can see the different components that make up my plant model. We see some emulators here, one for the transducer, another one for the encoder. And here on the left part, I see actually the PMSM plant model. 

I can open it. And then I see these three different variants. So, in Simulink, there are several ways to implement or to model a physical model. So, for example, we can use an approach based on ordinary differential equations. This is something that we would build with basic Simulink models. We can also use some toolboxes, like Motor Control Blockset or Powertrain Blockset, where we can find ready to use off-the-shelf blocks that we can use. Or also we can use Simscape, which is the physical library of Simulink.

In this case, instead of being based on an ordinary differential equation, we have different physical domains so that we can build diagrams or circuits that emulate or that make a visual representation of our plant model. 

In this video, I will focus on the Simscape implementation of the PMSM model. If you have more interest, you can find more videos about different ways to model plants, including electric machines on our MathWorks website.

Simscape is the physical modeling library from Simulink. So, on the one hand, we have Simulink, which works with ordinary differential equations. So, we have a time-based modelling. In this case, it’s domain specific. So, we have facility to represent electrical, mechanic, thermal domains. 

In this case, for example, if I look here in the PMSM model, I will see that my PMSM is not represented with an equation but with a Simulink block that I took from the Simscape library. So, it is all parameterized. This is very helpful to accelerate plant modeling.

By the way, this is not only intended for simulation. So, as you will see later, something which is 100% compatible with real-time simulation on Speedgoat target computers. We can go back to the main model, I am coming back here. And now we can see the controller model. In this case, it's a field-oriented control algorithm with encoder position. 

So basically, we have a Stateflow chart that represents the different states of my controller. And then I have here as an atomic subsystem the different parts of my controller. So, the field-oriented control is right here in this part. So, this is done, basically, with some Simulink blocks for the Clarke-Park transformations, the control loops, and so on.

We can also use Simulation Data Inspector, which shows up in yellow after we have some new results available to inspect the results of our simulation. So, for example, we can plot here our velocity command and rotor speed that we can see that out simulations are as expected. I can also, for example, display here the states of my model. And using some data labels, I can inspect the results. I can obviously zoom in, zoom out and so on. 

So, I did it wrong. Let me do it again. All right. This is the one that I wanted to show. For example, now we can inspect the transitions. Of course, if we want to export or save the results for further analysis, that is something that we can also do easily directly from the model.

Let me close this and get back to the model. So, now, we have ensured that our simulation results the behavior of our control is what we expect. So, now we want to go to Hardware and test our embedded controller, which has already implemented the software that we developed previously on desktop. 

Therefore, we don't need any more this part of my model. And now we have to replace it as we saw on the slide with the specific I/O driver blocks. This is something that I have done beforehand, and I have already available.

So, let me switch back to my HIL model. I can close that one. I use the HIL model in which I have already prepared these driver blocks. So, let me minimize this. And you see so the model looks basically the same as the other one. 

So, I am reusing the plant model because I am using a model reference. So, I have the same entity referenced in two different top models. So, I can reuse them with this complete freedom, so that they are linking content. But I have two different models for two different purposes, one for desktop simulation and another one for HIL.

This is the approach I chose. But eventually, we can also use variant subsystems to have one single main model in which we switch, in which we activate that subsystem that we need for every moment. Right now, we can check that the TI interface, the subsystem contains the Speedgoat driver blocks that we needed specifically for this application. 

So, for example, we can first take a look at the outputs. So, these are the outputs of the Speedgoat, the input for the controller. So, we have some digital lines, quadrature encoder, and analog input as well.

So. as you see, the Speedgoat driver blocks are completely integrated in the Speedgoat driver library. So. we can add then in our model per drag and drop as any other block. They have the same mask, so we can parameterize them as we want. We can even change physically the behavior of the interface, for example the output range directly from Simulink. So we don't need any separate software to do so. 

It's also quite interesting to highlight that the documentation. So, by clicking on Help, we can open the block documentation. And it has the same looks and feels that any other Simulink block. They are also available offline. So, they are installed together with the Speedgoat driver libraries so that you can consult them in any case, regardless of your internet connection.

This is quite helpful with a lot of samples, some tips, some usage notes that are always very helpful. Let me close this and get back to the model. We can also take a look at the inputs. 

For example, as we are doing a model control application. We have a PWM capture block, as you can see here. In this case, the pulses are captured on the FPGA we have in the system. And we give to the CPU the duty cycle, which is what we need for the plant model.

By the way, we are using the PWM capture block in this way because we are running an averaged model of our inverter and PMSM model. In the case that we needed a more detailed scenario because we are simulating some fault cases, or we need the transient behavior of the different switching elements of our inverter, we could run a more detailed model and even run the PMSM on the inverter on the FPGA to capture all the dynamics of our system at frequency rates up to the Megahertz. 

The next step would be to configure the model for Hardware-in-the-Loop simulation on Speedgoat. So ,there are basically two things that we have to bear in mind. If we go to Hardware settings, we have to ensure that we have selected SLRT. As you can see here, Simulink Real-Time as target file.

Also, it's mandatory to have a fixed-step solver. These are the two main requirements to run real-time simulation on Speedgoat hardware platforms. So once this is ready, we can select here our target computer. In this case, I have one, a baseline that I commented earlier. I can connect to it. So now we are connected to the target. And in one single click, let's run this model in real-time. 

I will maximize the instrument panel here, so in the same way that we use it for-- or to control desktops simulations, is something that we can use for Hardware-in-the-Loop. Now, we want to run the application on the target. So, clicking on this button, we will trigger this process in which we generate C code automatically from our Simulink model.

And then, Simulink Real-Time compiles and links the real-time application from this C code that we have generated, and also taking into consideration the driver configuration that we have set on the Simulink blocks. By the way, we can also open the diagnostic viewer to follow this process that I have just commented. 

First, we generate the C code automatically. And then, Simulink Real-Time calls the C compiler to create this real-time application. So, by the way, this is something that I trigger in one click. So, from a Simulink model to have the application running in real-time on the Speedgoat platform. But it's something that we can also do step by step from the graphical user interface or we can use also commands so that we can do it programmatically from the MATLAB command window or from a script.

So, we can see that the application is about to start. It's on the last step of the build process. This may take some seconds or minutes, depending on the complexity of the model. Of course, we can use some techniques like using, for example, model references to reduce the time that we require to build a new real-time application where we are rebuilding some parts of the model. 

It seems that the application has been loaded on the target. And now it's about to start simulation. As you can, see it's a process that starts automatically once the application is ready. Now Simulink checks that the application that is loaded on the Speedgoat platform is the same one that we have open. And it will start immediately to run in real-time.

I can close the diagnostic viewer, and now we see the application is running. I have to send an on command to the embedded controller. Now we see how we can control the velocity directly from the target. 

So right now, the controller, the TI board is getting the velocity command that I am setting here in Simulink via some digital inputs. And it's generating the PWM signal—three-phase PWM signal, in fact, that is controlling my plant model which is running in real-time on the Speedgoat platform. So, I can reproduce even the same behavior that I did earlier.

As you see, we can control, we can tune parameters directly in Simulink without having to rebuild our application, either with instrument panels or wherever these parameters are. Either in the MATLAB workspace, model workspace, Simulink Data Dictionaries... it doesn't matter. We can tune them in run-time. 

I will stop now the application. And we have also the results available in the Simulation Data Inspector. You can see it's again in yellow. So that means that new simulation results are available. And here you have, we can focus on their velocity. So, let me display the rotor velocity. We have the simulation results directly from the target.

So again, for example, this is the moment in which I switched off the model. So, it's something that we can inspect. This is the way that we can compare, we can analyze this simulation results regardless of the simulation platform, regardless if they are running in real-time or ondesktop as fast as possible from the same plotting tool, from the same data inspector. 

And in the same way, we can use the same export possibilities. And we can even automate the comparison by selecting compare block button. We can compare signal to signal, run to run for a more detailed analysis. Let me close the Simulation Data Inspector for now and come back to my main model.

So, in this first attempt, we have executed the application in real-time on the Speedgoat platform manually. So, we have triggered the execution with a random target button. And later on, we have interacted with the application during run-time tuning parameters directly from Simulink. 

We have also seen how we can inspect the results using the same tools, the same simulation data inspector, the same instrument panel that we used for desktop simulation. Eventually, we want to automate this. Especially for Hardware-in-the-Loop, we may have a lot of different test cases that we want to reuse. We may have even developed them for Model-in-the-loop simulation. We want to reuse then across the whole verification and validation process, including Model-in-the-loop, Software-in-the-Loop, and Hardware-in-the-Loop.

Now, we will see how we can use one single tool to automate the whole testing process, including linking with requirements and generating tests and reports as artifacts. To this end, we can go to the app tab, on the top bar, open Simulink Test, and then use the Simulink Test Manager. 

Test Manager is not exclusive of Hardware-in-the-Loop. But it offers us a single tool to manage all our test cases and test suites regardless of the platform they are running. In this case, I will use a test suite that I had created previously.

I can load the test. And then we see here how, in the left column, we see the different folders and the different test cases. For the demo, we'll use the MIL or Model-in-the-Loop test. As you see this is a simulation test. That means that it's going to be executed on my desktop. 

We go to New. We find a lot of different test cases that we can use for different purposes. Looking at the test case definition, there are different fields. We can add different tasks, descriptions, and requirements to our test case. By the way, if we open the requirement we can see that there is a bidirectional link between the requirement and its verification on a test case. On the same way, we can find a bidirectional linking and complete traceability between the requirement and its implementation in the Simulink model.

If we go to this grayed area, we can find the different fields that allow us to define our test case. We can select which model we want to test, the different test hardnesses where we have defined additional test inputs or verification assessments that our model has to fulfill. And on the test case, we have the possibility to define any configuration, any setting, or parameters that we want to overwrite below in our model. 

Let's go to the next section, here in parameters override we have the possibility to override any parameter of our Simulink model regardless of where they are stored. We can override them in the MATLAB workspace, in the model workspace, or as in this case, in the Simulink data dictionary.

In this scenario, we are overwriting one single parameter with three different values. But we could do the same for complete parameter sets. In this case, what we are doing is that we have a disc connected to the rotor axis of our model, which is spinning and whose inertia we want to modify. 

Instead of maintaining three different models or three different parameters sets, we can use the test manager and specifically this parameter override section to use all what we have done so far, the test definition, and also one single model. But combining or verifying what is our behavior with different parameter sets. So, this has the advantage that we have less models, less files, or artifacts to maintain but we still have the flexibility to test our system in different configurations easily and quickly from Test Manager.

In case there is something that I want to customize, we can always use callbacks to define MATLAB scripts or commands that we want to execute. In the same way, we can further define which inputs we want to use for the test case in case we haven't defined them on the model itself. 

We can use, also, additional signals that we want to log different configuration settings like overriding a complete configuration set, and finally define the iteration based on the previous data that we have defined in this page. In case we want to be a bit more detailed how we control how we check that the requirements are fulfilled, we can also use these logical and temporal assessments.

Here, we can translate or we can implement text-based requirements in a way that are easier to understand and to validate in our test case. We can define some symbols. These are references to our model and also numeric parameters. 

There are different assessments that we can add, so some basics in terms of logical assessment like bound checks and custom. But we can also use more complex temporal assessments. In this case, I have two logical and one temporal, as you can see here. Each of them is linked to a different requirement.

If we click on here, we have the same bi-directional traceability between requirement and its verification. We also see a visual representation of the requirement that we are validating. In case we need it, we can also add additional criteria that we want to execute. And we can use the same test case to collect coverage data. 

Now, I will run this on my desktop. As you have seen in this case, I am running three different test cases for this test definition. MATLAB is automatically creating three different execution as you see here. They are right now in the queue.

I could also use parallel execution by enabling this button over here. And we would execute in that case the three different executions simultaneously. Right now, they are going to be sequential. We will run one after the other. 

You can see always here in the middle of the screen, a feedback about the state of our test execution. The first execution takes a bit longer because the model has to be loaded and compiled. But we will see that thanks to the fast restart, the later executions will be much quicker.

The first execution has already started. We can see here that there are two in the queue and one is already running. This is not loaded yet. And now there we go. We can inspect the results manually, although we already see an immediate feedback about the results. We see here that they have passed, that they are populated from the detailed verification up to the global results. 

We can plot, for example, the rotor velocity and we can see the double step that I have configured as this input for my model. For example, I see here the three assessments that I defined earlier that I showed. And we can see for example that they have been fulfilled.

In case there is something which is not passed, a criteria that has failed, we would see that immediately on the status icon. And we can also inspect this model. So, for some example, this encoder calibration requirement hasn't been fulfilled. And we see here the reason why it's not. 

In this case, I have executed the results and inspected them manually. But we can also generate a report from those results. So for example, using this standard configuration, we can use different formats in which we would like to export the results

I will take PDF as an example. And now we will create a PDF document automatically from our Simulink results. This is an operation that we can also automate upon the end of test execution, so that we can later inspect the results of our test case without having to open MATLAB or the test manager. 

We can, for example, let this test execution run automatically. For example, we are running this on a continuous integration environment. And then at the end of the simulation, the day after we can open our folder where our results are and just consult, for example, this PDF document with so many of our results as you see here.

As I have just said, Simulink test is a testing framework that you can use also within your continuous integration workflow. In this case, I have implemented this job to validate my HIL test case, my PMSM scenario in my Jenkins server. For example, this is how the job looks like. I have direct access to the test report I was showing earlier. 

I can also use the Test Anything Protocol to see my results very quickly. So for example, if I open one of my last jobs, I have a summary directly on Jenkins without having to open MATLAB or Simulink test of the test cases that have passed or failed or even looking into the error log, as you can see here.

If I go back to my main job website, I now go to my configure website. I can see that, for example, we have available a MATLAB plug-in so that we can run MATLAB test cases or MATLAB commands directly from Jenkins. This MATLAB plug-in for Jenkins can automatically open a MATLAB installation as given here in the path and run the test cases as desired. We can couple our testing framework on Simulink very easily with some automation or continuous integration workflow. 

If we go back to our test browser, we can see that we have other test cases. For example, this was a Model-in-the-Loop test. But it would be very easy to convert this for Software-in-the-Loop for example, which would be the next step in the verification process. We could open the simulation mode and override it so that we can use Software-in-the-Loop automatically.

For Hardware-in-the-Loop, we need to specify a test case that is called Real-Time Test. We don't need to duplicate our test case. We can copy it and then convert it to a real-time test easily on the test panel. This is what I have done so that I have created another test case which is going to run on the Speedgoat platform that I call HIL. 

I am using that same test definition. I am checking or verifying the same requirements and using the same test iteration, the same parameter override. But the main difference is that I will use the HIL model where I have configured my Speedgoat I/O driver blocks. And, the test case will run on the Speedgoat instead of on the desktop.

If I click on Run, now Simulink Test Manager will do the same test that I did earlier manually. As you can see now, it's building the model. It will generally again the C code, compile and create this real-time application that will be transferred to the target so that we don't have to do it manually, opening the model, click and run on target, and waiting until the execution is completed. 

Again, the first iteration will take a bit longer because it has to build the model. But Test Manager can automatically detect when a build is required. The second and third iterations will start immediately after the first one because we are using the advantage that tunable parameters don't require a new build.

One advantage that we can execute the test cases separately, as I'm doing here. Or once we have defined our complete test suite, we can open or click on the root definition of our test case and execute everything, combining all sorts of test cases-- Model-in-the-Loop, Software-in-the-Loop, Processor-in-the-Loop, tests that run in real-time on a Speedgoat with different models and with different requirements to validate. 

We can see how the application has been built, transferred to the Speedgoat. And now the first iteration is running. Results will pop up immediately, again, on this left column. And further iteration will be executed immediately afterwards.

We can open the results and we have the same execution, the same results as we had earlier in this scenario. The case was executed in a real-time on the Speedgoat platform. Our Hardware-in-the-Loop test cases have already been executed. And we have all the results available, together with the previous execution that we have done on our desktop. 

And thus, we have brought our models, our test cases, our verification statements in a few clicks from desktop simulation to Hardware-in-the-Loop thanks to Simulink Real-Time and Speedgoat target computers.

Thanks for watching. And please don't hesitate to reach out, may you have further interest in our solution for real-time simulation. And again, please let me remind you watching the video my colleague Sonja created for Rapid Control Prototyping.