Automate your drilling processes with Simulink | Drilling Systems Modeling & Automation, Part 1

Hi, my name is Jonathan LeSage, and I'm an application engineer with The MathWorks. In today's video, we're going to kick off a video series on using digital twins to test and validate software that we're developing for heavy equipment. And for this case study, we're going to actually be using a draw works drilling system, which is a piece of equipment that's commonly used in the drilling industry, as our example.

And really, what our goal is for this study is to optimize the performance of the software, and test it, and validated it priori to actually going out into the field and testing on the rig. And what this software is going to be doing is controlling the position and speed of raising and lowering of our top drive as we kind of add drill string into the drilling process or remove it out. And so this is going to be a process that repeats many, many times throughout the drilling process.

Now, this hoisting system is going to be carrying hundreds of thousands of pounds of drill string and additional loading, and so it's operating at a very high power. Additionally, there's going to be inertia on this thing as we raise and lower, and so we need to be able to ensure with our software that an operator doesn't allow this top drive to either continue and impact the top or smash into the bottom of our drilling platform during operation. OK? And so really what we want to do is optimize this software so that we can have this drilling process as fast as possible but also safe. OK?

So why would we want to use a digital twin for the development and testing of software? Well, really, there's many different reasons. And first and foremost, software that we develop for these types of applications is ultimately going to be interacting with hardware, and that hardware can be electromechanical or of other domains as well. And that type of hardware is going to have physical operating limits.

And so for variable frequency drives, like in the case of our drawworks system, there's going to be operational torque speed curves at which we can operate, and operation above this is going to either overheat or damage the equipment. And so we want to incorporate those limitations into the software that we've built. Now, one way of doing that is, of course, hard coding that into the software, but other ways is to use our simulations to kind of validate and test that the software limits that we've encoded are going to perform as expected in simulation.

Now, hardware, of course, is going to be coupled with the software, and so that software is either going to be implemented on PLCs or other embedded devices. And really, that software is going to be communicating to hardware over different channels, ethernet IP or profy.net, and so there's going to be communication delays. But also, the hard-- the software itself is going to have an implementation, and that implementation could have bugs or other issues that are inadvertently introduced either by poor requirements or just mistakes, and we're going to talk about how we can test and check for those. But the other aspect is, if we're able to couple our software model with our hardware model, we now have an integrated digital twin that has both a software component and a hardware component which lets us test even more in advance.

Now, finally, this equipment that we're going to be working with, as I mentioned before, is very expensive and very hazardous. And on top of that, if we're actually taking equipment down out of the field to do testing, that's going to be downtime that wasn't necessarily necessary for testing. If we can do a lot of this upfront in our lab, using hardware in the loop or even desktop simulation, this is time saved and a lot of safety that we're introducing into this design process as well. OK? And of course, all of these things are going to be coupled together. Right? If you're able to build a digital twin in software, you're going to be able to test and test this integrated workflow. OK?

Now, let's take a look at what a digital twin looks like in Simulink of the drawworks system. All right, hopping over to Simulink, what we have here is the digital twin of our system. And in this case, I'm going to go ahead and push the Run button to start this simulation, but what we actually have here is a coupled simulation of both the mechanical or the hardware aspect of this drawworks system-- so we have the hoisting system over here, pulleys, the top drive, the actual drill string load. We've got the drive train of the system, the gearbox through to the drum, and then we have the variable frequency drive that has our torque speed curves.

That's the hardware aspect of this digital twin, but coupled with that, we actually have the software aspect as well. And this is a representation of a state machine of the logic that would be implemented in our PLC, and this is using a tool in Simulink called Stateflow, it lets us visualize state machine-based logic and incorporate things like energy limits, and this energy limit we're going to touch on later is basically how we're able to ensure that we're not going to crown out or bottom out this system, and so it's going to take into account the limitations of the hardware and also the operational modes of the driller at this time. OK?

As this simulation has been running, you might have also seen that these charts here, or scopes, are showing us some of the insights into the operation. And so we can see the speed, the torque of the VFD, the power usage, and then we see the actual speed of the drawworks. So this is in RPM, and that energy limiter is actually giving us speed limits for operation in this case. And if you're actually curious to see what this looks like during operation, this is an animation of the drawworks rig drilling up and down, and I can actually control this.

So right now we're in the auto driller automatic mode. I can disable that. You'll notice that the rig has stopped, and now I can start to override those commands as well. And so in addition to this digital twin testing the software, I can actually use it as a training simulator and kind of mimic as if I'm a drilling operator. OK? Now, with that, I'm going to go ahead and stop.

Now that we've seen how we can do a simulation of this drill rig system, let's talk about the implementation of the software. Now, that state machine that I showed you that had the auto driller logic and the energy limiting algorithm, ultimately, if we wanted to take that out and put that onto an actual drilling system, we'd have to recode that into a PLC development environment if we're talking in a PLC or some other language, like C if we're targeting other devices. We'd have to push that onto a PLC, and then a traditional workflow would be connecting that PLC up to the actual drilling system, testing it to see if it's going to perform as expected.

Now, as we mentioned before, this is a dangerous workflow, prone to introduce issues. And if there are issues, if we're using actual hardware, it can have very expensive issues that arise if we have a crown out or bottoming out situation. So a alternative to this is to actually, instead of having an actual piece of equipment, use a digital simulation of that equipment. So take that model that we've already built for software, for its software testing, on my desktop and then actually push that to a real-time system. And for the PLC, we connect up to this real-time computer, using industry protocols like Modbus or in this case, we're going to use EtherNet/IP. And to the PLC, it's actually talking to, it'll appear as if it's talking to actual drilling equipment, but we're actually running a real-time simulation of that equipment, mimicking the dynamics of the actual equipment.

And so the workflow for this is to basically take that model that we've already built. We can use our C code generation technology. It'll convert the physical model of our drawworks system over to C code, and then that will actually be compiled and then pushed onto a real-time platform, in this case in particular, a Speedgoat. You can still hand develop the PLC software and push that onto the PLC, but another workflow actually is you can take work that you've done in Simulink, and you can actually convert that over to structured text as well. And that structured text can then be loaded into the PLC development environment and pushed to PLCs, kind of saving you a step of manually recoding that software if you've already implemented it.

Now that we've seen how we can do this testing on the desktop, let's see how we can implement this workflow and do hardware in the loop testing. What I have here now is a model that I've configured to do the harbo-in-the-loop testing, and so I've taken the same digital twin that I've created before of the hardware side, the drawworks, the VFD, the drum, hoisting, and now I've added interfaces, driver interfaces. And these interfaces are driver blocks that communicate over industry protocol, in this case ethernet IP. This model has already been converted to C and deployed to my Soeedgoat, and now what I can do is I can actually push Run.

This is going to start the hardware-in-the-loop simulation. And the way that you can tell that this is a hardware-in-the-loop simulation is this is an interface to my PLC. And you can see as this simulation is running on the hardware, we're actually seeing the values on the PLC update.

This is a physical PLC hardware. I'm connected to it over ethernet from my laptop, and I'm able to see these values update, and so I'm able to test this software and see how I'm performing on the actual PLC implementation. And we can see a lot of the same results that we saw before from the strictly desktop simulation, except now we're using a PLC for the controller and not a Stateflow machine that's doing the simulation of a controller. OK?

Now, this is just the first start of this video series. We're actually going to touch on a lot of the topics that I touched on today in more detail, and so some of the things like modeling and simulation, we're going to go into more detail about how you can build these digital twins. One of the things that we didn't touch on today is you build a simulation of a piece of equipment.

Oftentimes, if you have data or measurements from the real field equipment, you can actually use that to do what we call model calibration. That's going to make your digital twin replicate the response that you're going to see in the field, and this is a really good way to ensure that the simulations that you build are viable and very good to base your software design off of. We're going to also explore how we can actually use these digital twins to optimize performance, and in this particular case, we're going to be looking at how we can optimize the drilling speed of this drawworks drilling system, given the operational limits of the hardware. We'll also see how we can do some validation of our control strategies using formal methods to test the algorithms that we built in software so that when we do convert over to code, that we have a very strong degree of confidence of the safety of those algorithms.

Then we'll talk about converting over to code. We'll focus primarily on PLC code, but we'll touch on how you can do that for C as well. And then we'll finally wrap up with kind of using the models that we've built for hardware-in-the-loop testing like we just covered. I hope you will join us for the rest of these videos. I'm very excited that we get to cover so many topics in many different videos Thank you.