Full-switching Electric Drive FPGA-based Hardware-in-the-Loop Simulation

Hi, everyone. This is Pablo Romero speaking. And I am going to present together with my colleague, Carlos from Speedgoat a webinar about Full-Switching Electric Drive FPGA-based for Hardware-in-the-Loop simulation. I am an application engineer at MathWorks for five years and a product specialist for Simulink Real Time in email. Before that, I have worked in the automotive and aerospace industry. And right now, I am very busy working a lot with customers doing electrification all over Europe. Carlos, do you want to introduce yourself?

Hi, I'm Carlos Villegas. I am the Electrification Industry Manager at Speedgoat. I have over 10 years of experience in power electronics, electrical machines, and automotive control systems, including in-vehicle rapid control prototyping at Daimler Research in Germany, as well as hardware-in-the-loop testing of electric generators with different renewable energy companies. Back to you, Pablo.

Thanks, Carlos. So let's get it started. So let's see what we are going to see today in this presentation. So we will start with a brief introduction from Carlos about why hardware-in-the-loop is important and how to achieve that with electric motor drives. Then I will discuss a bit more in detail what is the hardware setup for today's presentation. And then we'll do a full demo with the different steps that you can see in the agenda. Finally, we will wrap it up and also have at the end some time for discussion.

What is out of the scope of today's presentation is the detailed design of a field-oriented control algorithm and the prototyping of it. We are going to see, nevertheless, a few models with this control logic. But we won't dig in to much detail. Also, we will skip the details about doing automatic code generation for embedded platforms. And we will take our model, which is already configured for that. So with that, I'll hand it over to Carlos.

Thanks, Pablo. So there is a growing need to develop electric motor drives, especially driven by renewable energy sources and electric transportation. Being electric transportation the key driver for higher performance and higher efficiency motor drives. A trend is to use model-based design where you use models with different levels of fidelity at the whole development process, including rapid control prototyping-- but not only for the controller development, but also for testing electrical equipment.

And finally, combine this with test automation for both normal and fault operating conditions. So let's say that your team is responsible to develop an embedded controller for an electric powertrain and the first controller board has just been made available. Many teams would just start connecting with the actual hardware, like the prototype or the final product. But this may not be the best thing to do as you're involving electrical and mechanical power that could be hazardous and potentially damage your equipment or injury to personnel.

So you can test safely using hardware-in-the-loop testing, especially for early stage controllers. Furthermore, it's not always so easy to access our labs or dynamometers. So while you're waiting to access, you can use hardware-in-the-loop testing to save time and costs. And finally, things rarely align the way you plan. And with hardware-in-the-loop testing, you can decouple from hardware lead times and start testing earlier.

For these and other reasons, engineers have been using hardware-in-the-loop testing to develop embedded controllers to vet them thoroughly before connecting to the final hardware or prototype. So when developing an electric motor drive, there are certain benefits that come from using hardware-in-the-loop testing. For example, there's high-frequency switching involved in motor drives, typically, when you're seeing silicon carbide or gallium nitride or other wide bandgap semiconductors.

You can have switching frequencies from 10s, 100s, or even 1,000s of kilohertz. You can handle those with hardware-in-the-loop testing by combining optimized models in the FPGA that combine closed-loop sample times in the megahertz range with signal conditioning in the nanosecond range, as Pablo will be showing later today. And there's also the need to use high-fidelity electric motor models-- for example, with saturation or spatial harmonics, which you can do by using Finite Element Analysis models in the FPGA or also experimental-based lookup tables.

And when testing electric motor drives, you'll need to emulate sensors and also use different protocols. And with hardware-in-the-loop testing, this is available, typically, off-the-shelf. And finally, as you need to test under typical and false conditions, you're going to need fault insertion mechanisms, as well as simulations of other subsystems, such as the environment, mechanical, fluids, hydraulic, et cetera.

So once want to have a hardware-in-the-loop test bench, it's important to note that you're going to need mainly three components. First will be your equipment under test or system under test. In this case, it's going to be our embedded controllers for the motor drive. Then we'll connect it-- instead of to the real motor drive, we'll use exactly the same interfaces, but we'll connect it to a hardware-in-the-loop simulator that contains the models of the motor and drive models, as well as different I/O connectivity to emulate the interfaces, sensors, actuators, and other features.

And then all of these will be controlled from the workstation. From here, you'll handle the test automation. You'll be able to configure your instruments and log the experiment, adjust parameters on the fly, et cetera. So this is a generic hardware-in-the-loop test bench. And Pable will be showing you later the specific one that we'll be using for the demo today. So I'll go back to you, Pablo.

Thanks, Carlos, for this introduction into the main components that you require to do hardware-in-the-loop testing. Let's look now at the hardware that we have used for today's presentation. Here we will see a short video recording in the lab with the hardware I use for the demo. We have the laptop, the device under test, and the real time target machine.

This is the speed drill performance. You can see right now that on the screen is connected via an ethernet cable to the office network so that we have remote host-target connection from anywhere in the world. We have as well the FPGA connectors for the analog and the digital signals coming from the front panel, connected firmly to the interface board you can see on the screen.

This interface has connected the hardware under test, which is a TI launchpad kit, where we have the electric motor drive control logic running. And we instrumented this as well so that we can use this interface board to have comfortably an interface that we can connect with these standard connectors to the FPGA board. This has also a USB cable so that we can flash the control logic and do some debugging between the TI board and the laptop computer. On the laptop, I am running, as you see, the Simulink model that we will see in a few seconds.

So let's summarize the components that we have for hardware-in-the-loop testing. To be more specific and commenting on top of what Carlos explained, we have the development computer. And then we see the list of software of MathWorks toolboxes that are required to perform this kind of FPGA-based HIL simulation and deployment. Then in the middle, we have the target computer, which in this case is the Speedgoat performance, because it's leveraging multi-core CPU and a programmable FPGA with some of the sensors and I/Os that Carlos as well introduced. And the example of device under test is this TI launchpad kit connected to the Speedgoat LaunchPad Interface and using some of the interfaces that we see in the two arrows in the diagram.

With that, let's jump into the demonstration. Let's see in a bit more detail how we have done the different steps to do FPGA-based hardware-in-the-loop simulation of these electric drives. So for that, we will start with some real time simulation that we are transitioning from desktop simulation. We have the two main use cases displayed right now on the screen. We have the hardware-in-the-loop simulation, which is used for verification and validation purposes and rapid control prototyping, which is a bit out of the scope of today's presentation. But it's another relevant use case to mention.

As said, in every case, we start from a desktop simulation where we can perform a closed loop simulation, also called modeling the loop. And then using automatic code generation technologies, either for the hardware-in-the-loop, where we are using C and C+ code together with HDR code, as well as production code, if we are talking to targeting the embedded device. This is what we see in the bottom side of the screen. Of course, both devices are connected with real time communication, as we have seen in the previous video.

The deployment is going to follow the steps that we see on the right. Basically, we are creating the plan model using some Simulink based plant models from the motor control blockset. And we are generating an FPGA bitstream via HDL Coder. And then we are deploying everything together and instrumenting the application in real time with Simulink Real Time.

So let's now start in the first step in this test of simulation. This is something I said that we should do to perform early validation of both our control logic and our plot model. Let's have a look at this. So as you can see, I started Simulink Projects. So workspace is initialized. We have some folders already available in the MATLAB path.

I would like to initialize the parameters of the hardware that I'm using. We can see already the inverter, the motor parameters, which have been taken from the MCV from the motor control blockset database. I have to use these parameters to model this system model. This is something that we can simulate in accelerator mode to have some weaker simulation on desktop.

I am running a very short simulation of 1 second with a step response so that we can validate quickly if our results are suspected. This is the step response I am mentioning. And then we have here, in normalized units, the speed response of our system. We have some control that eventually might need to be tuned. But this is some early validation. We can later actually compare to real time results and see what is the difference.

Anyway, we see that the motor speed tracks well the command and we can have a closer look at the different parts of the model. So this is the model that we will eventually run on the FPGA. I can switch off the sample time legend so that we can see the different blocks a bit more clearly. We have, for early validation in real time, a possibility of creating the PWM signals within the FPGA. But in the real scenario, we will read them from the TTL inputs, as you can see on the left.

Then, this subsystem contains basically the plant model. It contains as well some sensor emulation. In this case, for the sake of completeness, we are using two different sort of sensors-- the quadrature encoder and the resolver. But in both cases, they can be parametrized externally without requiring to generate a new bitstream every time we modify some parameter. Then this is the inverter, which is modeled following the subcycle averaging approach that will give us these full switching dynamics that we require in real time simulation.

And finally, we have as well the PMSM plant model running at 1 microsecond, or closed loop, as you can see. And both are, of course, connected, and as well, using some ports so that we can parameterize some parameters, especially those related to the plant model from outside without requiring to recompile everything when we want to test a new set of parameters for the model. Then we have some signal conditioning as well, as you can see, where we are scaling the signals for the analog outputs.

We are also backing some data so that we can log data over the PCI interface on the CPU. And then some triggering as well. We are generating as well some interrupts so that we can synchronize DACs and eventually the execution on the CPU accordingly. As said, this is everything that is going to be deployed and working on the FPGA. Now we can see some of the blocks that I have already mentioned that are used to parameterize the model running on the FPGA without requiring to synthesize a bit string to generate HDL code every time. This gives us a lot of flexibility and also enables this quick testing that also we were discussing at the beginning of the presentation.

So that we can do some closed loop simulation, we have as well as some parameters that enable us to emulate the PWM inside the FPGA and eventually converting some commands which are being computed in this field-oriented control that we see in here. This is the control logic that eventually will be deployed to the embedded hardware. But right now, we are using it for modeling the loop. And we will use it as well for first validation of the results in real time. So this is the model that we have used for the closed-loop simulation and this is usually the first phase that we have to do when working with this kind of power electronics and electric drive models.

Let's review the different advantages of the most important highlights we have seen in this demo. First of all is that we can use Simulink to create a model, high-fidelity motors and inverters. And techniques such as subcycle averaging for the inverter will give us the possibility to sample PWM at frequencies up to 200 megahertz. This is recommended, as said, if we have some control logic we can use on the simulation, we can perform early validation on desktop before starting generate code, and so on, so that we make sure that the first time we get to the target, everything is going to work as expected. And of course, we can use some simulation and Simulink tools, such as the Data Inspector, to inspect, analyze, and compare results beforehand.

Eventually, once we have validated everything on desktop, we want to go to the next step. We want to generate HDL code automatically of those parts of the model that need to run at very fast frequencies. And also, we need to map the FPGA I/Os. So this is what we will see in the next part of the presentation.

So this is the model that I have shown a few moments ago. To generate the HDL code out of it, we can follow the following procedure. We can start opening the HDL coder up in the Simulink tool strip on the top side of the screen. And then go from left to right to generate HDL code and configure that. As you can see, this is already set. But we can also use the context menu to open the HDL Workflow Advisor for this specific subsystem. This will open an advisor that will guide us through the complete process from this source Simulink model down to the generated bitstream and the corresponding mask subsystem model.

In this case, we will go step by step so that you can get to know the different possibilities. We will start selecting the FPGA target that we want to use. In this case, we are using the IO334 from Speedgoat which is the most typical FPGA use for these kind of applications. And thanks to the full integrated Speedgoat environment into Simulink, we can map and target the FPGA directly from here. We have further customization options. For example, we can use the -21 plugin so that we have more TTL lines available. There are many possibilities to customize and to tweak a little bit the reference design that the Speedgoat provides as part of the HDL coder integration package.

In the next step, which is one of the most important of the HDL Workflow Advisor, Simulink will allow us to map the inputs and outputs of our model to the real FPGA interfaces. This is something as well enabled by this HDL coder integration package I was mentioning earlier. We have here the TTLs available that allow inputs, that allow outputs. We can also select what channel we want to use. And eventually, this configuration is safe with the model.

This is something that we have to do once. And then when we iterating on the design, these settings will be already saved and ready to use. This configuration will be set and mapped to the model. And now we can proceed with the next step, which is configuring the goal, the target frequencies. You saw this was 200 megahertz I was mentioning earlier.

Then these are some standard model checks. We can open the Model Advisor if we want for further tweaking of the system. And eventually, start with the HDL code generator itself. This process may take some time depending on your computer and depending on the complexity and size of the model.

For the sake of time, so that we can do this presentation in a reasonable time, I have sped up the process a little bit. But eventually, we will get the HDL code and some further details that we can check in this HDL code generation report. We can discuss and we can see about the interfacing, some estimation about the critical path, the FPGA resources that our design requires, and so forth.

This is very helpful in early phases so that we can know beforehand. We can know before the long synthesis process if our design is going to meet the FPGA requirements or not, and also give us a lot of flexibility in a few seconds or minutes, depending on the complexity of the design. Eventually, we will get more details as the process is finishing.

And eventually, once all the HDL code has been generated, we can check the full report. In here, we've all the details may we want to recommend-- the process. And also inspect the HDL code. Even directly in the model side by side so that we can see that it's their code that has been generated. This is not the case, but may I activate the traceability report, we will know for every specific subsystem, for every block, the line of HDL code that matches or that belongs.

Once we have inspected the HDL code, if we want to know more, we can get back to the HDL Workflow Advisor. We will eventually complete the deployment and build process. Basically, this is calling the synthesis tool in the background where we don't need even to open it. It's fully automated. And MATLAB will take care of that in the background.

Also, once we have configured everything, we don't need to go step by step, but we can generate MATLAB scripts automatically from the HDL Workflow Advisor so that we can integrate this into our continuous integration pipeline or we generate a new bitstream, basically in one shortcut from the menu. Eventually, at the end of this process, after the synthesis has been completed, we will get a mass subsystem with specific details that contains our FBGA implementation. This is something that later you can customize. It gives you as well some additional options for the I/O interfaces.

So let's look once more about what we have just seen. We have seen that we can generate HDL code automatically out of the Simulink design. It's not just about C, C++ code. When we need very fast switching dynamics, we need very fast frequencies in real time simulation. And that's something achievable only on FPGAs and therefore, the HDL code generation.

To facilitate this process, we are also using the HDL Workflow Advisor so that not just the code but also the interface with the I/O mapping is as easy as possible, which is also enabled by the Speedgoat HDL coding integration package. Finally, we can wrap everything together to automate the generation, the synthesis of the FPGA bitstream and also create the corresponding wrapper subsystem in Simulink that will be eventually deployed to the FPGA. So after having created the FPGA bitstream and the representation in the subsystem, we can start deploying all together to the Speedgoat real time target and see how the hardware-in-the-loop simulation performs.

So let's continue where we left it in the previous section. So this is the model. It has been automatically generated by the HDL Workflow Advisor, replacing the HDL subsystem with the corresponding masked subsystem. Now to the real time simulation, we can follow the same procedure done before. We can open the Simulink real time up, where we will have, in the toolstrip, all these options related to code model build, similated in real time deployment and instrumentation.

We can connect to the Speedgoat that we want to use. In this case, I'm using the Speedgoat performance. And then use the Random Target button to fully automate the code generation, the build process, and the deployment to the real time system. This is a process that we can also inspect, that we can monitor in the Diagnostic Viewer.

Also, I will open an SSH client so that we can create an SSH connection for additional feedback about the status of the Speedgoat. This is something that we get in a parallel channel. On the right, we see that in the meanwhile, code has been generated, has been compiled, and now a binary file has been created that will be automatically wrapped and deployed to the Speedgoat via this ethernet connection. In this case, actually, I was also using a remote device to the lab.

We can see on the SSH line that the FPGA has been flushed accordingly with the bitstream that we have previously generated. And once the application has been deployed and is loaded on the Speedgoat, the simulation will start to run in external mode. In this part, for this initial test, I am repeating the same simulation that I did on desktop-- this step response for 1 second of simulation.

Also, thanks to the integration of a Speedgoat real time target into the Simulink environment, we can use the same tools to log, visualize, and analyze data. This is actually the results that we have just captured in the performance. Devices, you can see. And we can compare them to the previous simulation.

And we see the results if we use another color so that we can distinguish it a bit better. The results correlate quite well. This would be the next step in the process. We are validating that our FBA model matches the expected results after deployment to the real time device.

I'll summarize what we have seen. Simulink real time fully automates the built and deployment of models to real time targets. The Speedgoat will know, based on these inputs, what parts need to go on the CPU-- those that are generated from C code. And the rest of the FPGA subsystem will be mapped automatically. We don't have to care about that. It will follow what is defined in the moment.

Also, we can use external mode so that the Simulink model we have used as a source will behave as the user interface, so that we can set signals to log, inspect results and even tune parameters on the fly. And also, thanks to this integration I was mentioning earlier, we can use the same tools from Simulink to inspect, log, compare data, as we are used to.

Let's go now to the last step of the hardware-in-the-loop testing, which is adding the immediate control hardware in the loop. For that, I'd like to show you these steps. So this is, again, the project that we are using. And now I will open the model that I have used for deployment to the DI LaunchPad.

So please notice that the field oriented control logic, since this is a reference subsystem, is identical. It's a reference of the same model I was using for closed loop simulation on desktop. The main difference is that now I have instrumented the model with a corresponding set of I/O blocks from the TI device. So that, for example, if we look at the inverter connections, I have the PWM generator.

I have also some other outputs. For example, the digital output. I misclicked there. Sorry for that. And now we have as well other signals, other connections for further debugging, some SCI communication. And of course, if we go to the other side, with the inputs to close the loop, we need to capture some analog inputs.

Of course, we need to capture as well the sensor position-- the quadrature sensor. And as you can see, it's something that we can as well fully parametricize from Simulink. To build and deploy this model to the hardware device, we can use the same Run On Hardware. This is already preconfigured with the hardware mode I'm using. I may use other ones if I have different.

We can use some kind of processor in the loop, external mode using that button over there. But since we have validated this control in advance, we can directly build or eventually build and deploy this model to the TI device. This will trigger a very similar process to the one before, but now it will generate code, including the I/O drivers, specifically for this hardware mode.

This process will generate the code in the background and eventually create the required binaries calling the corresponding compiler. Since I was doing this remotely, if I had, of course, the embedded target connected over USB-- which I did one time before-- then I could deploy that as well via USB directly from Simulink. This is what I had done beforehand.

Now, to do the final simulation, it's something that I can do not just from the external mode in Simulink, but I can also use some instrument panels I have created in App Designer. So for example, from this instrumentation, I will connect to the same Speedgoat device I was using before. I can also bring up the SSH client so that we can have this additional feedback channel. And then repeat the same steps, but now from this standalone instrumentation panel.

I am running this from within MATLAB, as you can see right now. But eventually, I can also deploy a standalone compile app so that we can run the same instrumentation directly from windows or from Linux without requiring to run MATLAB Simulink in the background. For the sake of simplicity, I'm using that one from within MATLAB right now.

I am following the same steps done before. I have loaded the application. And when it's loaded, I can run it. And I will get the feedback and I can tune the parameters that I have previously said. Again, this is between minus 1 and plus 1, because I am using normalized speed.

I can interact with the target in real time. I can also switch it off, switch on some parameters. And this is following the commands from this device, but using the real PWM signals generated. Of course, if I run this a bit slower, I can use some motor angles. For example, all the signals that I have previously set to streaming.

Once I am happy with the stimulation, I can stop it. And again, the target will get back to idle. Let's wrap up this part of the presentation. So we have talked about co-generation for the FPGAs, for prototyping, for hardware-in-the-loop. But we can also automatically generate production code for embedded hardware, for hardware boards like this TI LaunchPad kit.

We can deploy them quickly from Simulink directly to the board and also configure the I/O devices in a similar fashion. And eventually, we can create instrument panels so that the testing and automation of the real time hardware-in-the-loop system can be performed-- for example, by test engineers or by people in a very user friendly way, without requiring access to the Simulink models, neither to MATLAB and Simulink, if we are working with a compiler app.

So after this demo, let's wrap up today's content. So we have seen how we can use Simulink on automatic HDL code generation so that we can do very fast and easy FPGA-based hardware-in-the-loop simulation. With this, we can achieve the very fast frequencies that are required to capture fast switching dynamics in the device that Carlos was describing at the beginning. Also, Speedgoat provides state-of-the-art FPGA and I/IO modules so that we can leverage this fully-integrated Simulink workflow to perform real time testing of electric drives.

Finally, if you want to know more about this, please bear in mind that the application that I have used for this demo is available in File Exchange. You can reach to File Exchange and download and test it on your own. Also, please stay tuned for updates, because we are extending this application, this repository with more topologies and further examples. Also, reach out to any of us. Reach out to your MathWorks and Speedgoat colleagues, because they will help you to assess the feasibility, to decide the eventual hardware needs, the I/Os that you require-- and also provide some detailed technical support and consultancy whenever required.

And finally, if you want to know more, if you want to have all the resources available, please don't hesitate to visit the links in this slide. So with this, we are concluding today's presentation. We hope you have enjoyed and learned a few things. And we are looking forward to hearing from you soon and knowing about this very exciting hardware-in-the-loop test with power electronics and electric drives. Thank you very much, and have a nice day.