Real-time testing: HIL simulation | Drilling Systems Modeling & Automation, Part 8

Hi, and welcome back to our video series on digital twins and testing and optimizing control logic. My name is Jonathan LeSage, and I'm an application engineer with MathWorks.

Now, today we're going to be talking about how we can continue to leverage this simulation that we've put together of the drawworks drilling system. As we kind of talked about in the very beginning, one of the other things that we can do and leverage these simulations for is hardware-in-the-loop testing.

And so in this case, what we're going to be focused on is taking this control logic here that we've put onto the PLC and testing the PLC using a real-time simulation of the rest of this system, the drawworks. So we're going to use a physical simulation and a real-time system, in this case a Speedgoat, to test our control logic.

Now, typically, a development path for this type of logic would be to hand-code or implement this in the PLC development environment. Then you'd have your industrial controller, and potentially go up and connect it to the test hardware, or to a test rig. This, of course, is dangerous, and requires downtime of that test rig.

In contrast, what we're going to be doing is leveraging a real-time simulation of the drilling equipment, which lets us kind of test this control hardware on the PLC directly in the lab, and lets us do a lot more testing upfront.

Now, when we talk about like a Speedgoat real-time system, you can actually do a couple of different things with it. And so in a sense, it's a flexible kind of environment to test and build your control systems.

Now, the first avenue that we see is what we call rapid control prototyping. This is where you take your model. So in our case, the drawworks system. And we've built a new control system.

If we have the actual hardware prototype or maybe a lab system, that's our actual plant. And so in our Simulink model what we would do is we would replace the actual model with in and out driver blocks to communicate with the actual hardware. And we'd be able to quickly test our control strategies by deploying that to our Speedgoat system.

So this is one approach. We see this often used for quickly testing new control strategies, especially if you have a lab-based testing system, and you're developing a lot of your controls in Simulink.

The focus of today is actually hardware in a loop, which is kind of the inverse of the problem I just presented. So we've taken and developed our controller. So in Simulink, maybe we've built something. We've used code generation, or maybe we've hand-coded something. That's on our PLC in this case.

So in our Simulink model, what we do is we replace the inputs and outputs to that control block or blocks with the corresponding driver blocks that will communicate over hardware channels. And that could be analog or digital IO, or some kind of industrial protocol. We'll talk about those in a little bit here.

And once you've done that, the remaining Simulink model will contain those driver blocks, the plant, and any kind of test vectors that you have. And all of that will then be deployed to a Speedgoat system for hardware-in-the-loop testing. And of course, once you've done that, the PLC can talk directly to the Speedgoat system. And it will communicate as if it's communicating with a real system.

Now, I mentioned driver blocks. Now, there's a lot of different driver blocks. And it will kind of depend on the inputs and output channels that you have available to you in your system. But commonly we see people interested in analog and digital IO. Other kind of common things would be encoder signatures, or PWM waveform generation and capture.

In addition to these low-level IOs, we also support a number of industry-focused protocols. This is by no means an exhaustive list, but these are some of the common ones. Things like EtherNet/IP, Modbus, EtherCAT. I see these quite heavily used in the industry all the time.

So you would have a block that represents that communication pathway. You can set that up in your Simulink model. And that will be part of the code generation process.

Now that we've discussed how we can actually use real-time testing and driver blocks, let's see how we can actually set that up in Simulink. Now, if you're starting from scratch and you're using Simulink real time to prototype with the Speedgoat, you can, of course, set this up from scratch. But in my case, I'm actually going to launch Simulink and do this using a template.

So you could, of course, use the blank model. But if you're going to do this for the first time, I actually recommend you scroll down and go to the Simulink real-time template. What this will actually do is it will create a blank Simulink model with a few blocks in it already, and also to have all the settings configured to target a Speedgoat system that's hooked up to your computer.

Now, the main things that it's done is it's set my solver to be a discrete-- or rather a fixed-step solver. And you can use continuous or discrete fixed-step solvers.

And the other thing it has done is if I go into my Model Settings here, and then go to my code generation target, you'll notice that the target file is the Simulink real-time system. Now if I generate code from this model, it'll go to the Speedgoat.

I'm going to go ahead and save this. Give it a name-- simple model. And let's make this simple model do something interesting. Instead of an input port, we'll get a pulse generator. Drag and drop that over. And I will make the period just 1 second. We'll start off with a pulse width of 50%. So we'll have some pulses on and off.

And to actually visualize the signal we're going to use the Simulink Data Inspector. So I'll go ahead and pull it up. And while that's going up-- push this off to the side-- we can highlight and log a signal.

So I'm going to name this signal PulseSig. And then I'm going to choose to log that signal.

Now, by logging that signal, I will have that stream into my Data Inspector during the real-time simulation. And I can actually observe values change on the Speedgoat.

Once we've done this, we can go ahead and build this application. And in fact, before I do that, I'm going to make the stop time a little bit longer. And I'll go ahead and build.

This is going to convert this model and anything that I have in here into C code. It will compile that up. And because I picked the Simulink real-time target, it will add some additional infrastructure to communicate with the real-time operating system on the Speedgoat system.

And while this is going we can take a look at the code generation process. There it is. It's just off my monitor. So it generated the code. We can see that the build process was successful.

Once we've done that, we can kind of go through the process. We can build it. We can deploy it. In my case, I'm good to go. So I'm going to go ahead and run it on the target.

So all this is going to do is this is going to take that code generation application, and now transfer it over to the Speedgoat. By default, we have what's called external mode. And external mode is going to let us visualize data as it's simulated on the Speedgoat. And so in this case, I'm just logging a single signal. But if I have many more signals, I could choose to display what I'm interested in.

Right now, in addition to being able to visualize things, I can actually interface with the model. Maybe scale that gain up. You'll notice now that my pulse is a lot bigger.

You can maybe shrink it back down. And then maybe we can adjust the pulse width, for example. Make this 25%, for example.

And I can zoom in. Take a look at that. Get a clearer view. And maybe you'll have a better idea if we get a little more signals in there. So you can see here's the 50% duty cycle, the 25% duty cycle. So we can interface directly with this real-time simulation using kind of the model as a canvas, and then using the data and structure to visualize the simulation.

Now that we've seen how we can kind of set this up and deploy it to a Speedgoat using code generation, now we can talk about how we can configure a larger simulation, like the drawworks, to run for real-time.

Let's hop back to MATLAB and take a look at how we can do this with the drawworks. Now, here I have the drawworks model. And as we mentioned before, we're doing-- we're using this model for hardware-in-the-loop testing. So we've preserved the plant portion of the model. The torque speed drive, the gearbox, the pulley system, the drum, the load, all of that's still the exact same model that we had before.

What we've done is we've gone to the settings for this model. We've made sure that, in this case, we're using a fixed-step solver. In this case, we're using a continuous solver, which is ode3, not a purely discrete solver. We could potentially try to make this model fully discrete if we wanted to. But in this case, this one is sufficient. The other aspect of this is we've selected the Simulink real-time target file, and have that setup as well.

The only other difference here now is we've gone to the block that originally had our state flowchart that implemented our drilling autodriller logic, and we've replaced that with interfaces to the Speedgoat. And because in this case, I'm using an Allen-Bradley PLC, we're using EtherNet/IP as our communication protocol. Depending on the PLC vendors, there may be specific protocols they support more easily. In this case, I selected this because Allen-Bradleys support EtherNet/IP out of the box.

These driver blocks, if we go into them, we can specify the sample time, and then also the length of data that's going in. In this case, it's the number of bytes configured here. And then we can set up the system. And I'm using a configuration file-based approach. But you can also use what we call a warm start, where you can specify an IP address to communicate to. And this would be the IP address that my PLC is on.

The final thing here is we can do the data type conversions on this side. So Simulink by default is going to use double precision and floating point. And so depending on the hardware you're communicating with, you might want to convert to different data types.

And so this case, PLC, they do support floating point precision, but just single, not double precision. So we're converting to single. Likewise, when we're bringing data back from the PLC, we're unpacking it, and then making sure we're bringing it back to a double data type for our simulation.

And that's really the setup process. Up here to the ToHost and the FromHost, I'm logging the signals to come back to my host machine. But as you can see, you can preserve this model as you had it in simulation for desktop and reuse it very easily and effectively for real-time simulation.