Nonlinear Model-Based Adaptive Robust Controller in an Oil and Gas Wireline Operation

Hello, this is a Fanping Bu from Schlumberger Industrial Internet Center. Today's, my presentation title is "Nonlinear Model-Based Adaptive Robots Controller Designed for Hydraulic Winch in Oil and Gas Wireline Operation, Model-Based Design with Docker containers".

This is today's presentation outline. First, I will introduce the background of our project, and I will brief introduce the model-based design and docker containers. Then, I will give you a brief introduction of winch controller-- how we're set up on our wireline truck. Then next, we'll-- I will present in detail about the winch system model development using the Simulink Simscape.

After that, I will briefly introduce the winch controller design and controller software architecture, its implementation, and testing. Finally, I will conclude the today's presentation.

Wireline logging is what they use in oil and gas industry to measure the property of formation using electronic instrument. In the last 90-plus years also with so many technology innovations, wireline operation in principle has not changed much since its inauguration. Basically, it involves using a drum or electric cable driven by the winch and with a tool string package with different kind of sensor attached to the free end of the cable.

When the winch drum is rotated by a different system, then that will move the tool string up and down through the well wall. And sensor inside tool string will measure conductive in environment and sending the acquired data through the canal cable to the surface.

So up to today, wireline operation is largely conducted through the manual operation. It typically involves winch men to operating the winch manually to convey to up and down the well and spool the cable carefully. It also involve a wellsite engineer to conduct the data logging and inspect the acquired data.

So the goal of this project is trying to transform a wellsite operation and user experience through the automation, which will improve the operational efficiency and job execution consistency. As we'll see from this picture, before the job at a cloud level, there will be a pre-job planning, generally a certain set of goals for the wellsite job. Those goal will be transmitted to wellsite planning.

Wellsite planning will-- plus a serious execution plan, according to a domain model generated by the expert, those plan will be executed by the acquisition automation, winch automation, spooling automation. Of course, the plan is dynamic. Whenever there is an incident happens, the plan will change accordingly, trying to achieve the same goal. So in today's presentation, we'll present mostly about the winch automation. Basically, the goal is trying to-- how to control the wind so that the tool will follow a desired motion profile generated by the wellsite planning within certain limits.

The controller development process follow a model-based design process. The advantage of model-based design process is well documented. It is a de facto standard for embedded system development in different industries such as automotive, aerospace, and medical electronics.

Here, I borrowed two figure from a lot of MathWorks presentation. Basically, model-based design process involves a model which could be a physical system model or a model of algorithm involved using different testing techniques such as Model-in-a-Loop, Software-in-a-Loop, Hardware-in-a-Loop to continue this test and verify the design and using the automatic code generation to facilitate the implementation of the development.

A microservice-based architecture has many advantages, and this is very popular for cloud and web development. Microservice and Docker container fits very well together. You can see a Docker container as a lightweight virtual machine. It provide additional layer of isolation between the service at the operations system level.

And each Docker container can have its own OS environment, including a memory, CPU, and a file system. Package and library dependency between a service will no longer be issue. And most important, a failure in one service won't propagate to another. and security also enhances. The container can be isolated as the network layer is required. And later, I will present how we combine the process of model-based design and Docker container together to implement our winch controller.

So this shows the current hardware setup for our winch control in our wireline truck. Basically, our wireline truck is already like a drive by wear winch. In the wireline truck, there's a DCU, which is sensing the joystick. And from the joystick command, it will send a subtle command to the variable displacement pump.

This will change hydraulic flow to the hydraulic circuitry, and-- driving the variable displacement motor. And the rotation of variable displacement motor will rotate the drums through a series of gear transmission. And the rotational drum will release or rewind a cable, which move the two up and down through the wellbore.

And also in the wireline operation, it involve the hydraulic pressure control equipment controlled by the PLC. So in a retrofit kind of scenario, we put an automation server on the wireline truck, which interface with the DCU. So ethernet connection.

And also, we can control the pressure control equipment through the PLC interface through the Modibus and Profibus. And it also acquires different kind of sensor information such as a cable tension, two position, and the speed through the serial connections.

Equipment simulator is a mathematical representation of the wireline equipment in the automation, including the winch, cable, tool, tractor, floating arm, pressure control equipment. It is used throughout the development process for software testing such a Model-in-a-Loop, Software-in-the-Loop testing. The process of building equipment and simulator also provide us with valuable insights for how we can conduct our winch controller design.

The equipment simulator is constructed using the MATLAB Simulink Simscape. This shows a basic architecture of our equipment simulator, including the winch hydraulics, winch mechanics, cable, tool, and pressure control equipment.

Though here shows the more detailed about our equipment simulator built in Simulink and Simscape. In a winch hydraulic, the central winch hydraulic is a pair of variable displacement pump and variable displacement motor. And the motor output connect to the drums through a bunch of transformation gears. And in the model, we detailed the model in how the cable is the winding around the drum, so when the drum rotate, the drum radius will change and also the drum inertia will change with the drum motion.

Wireline operation usually require a very long cable. When the cable is very long, the elasticity of the cable kind of shows dominant behavior. To model those kind of cable elasticity, we kind of broke cable into different, multiple nodes. This node can contain mass, spring, and damper connect together.

And we also model the force acting on a tool and the cable when the tool and cable moving through the wellbore, including gravity force, buoyancy force, friction force, and other cable weight. And we also modeled the behavior of the pressure control equipment such as the-- a hard salt at the top, and the tool trap, and tool catcher.

The equipment model is parameterized with different parameters from the system specification. We also conduct a series test to identify certain characteristics of the model. For example, we conduct like a ramp test. Basically, we're sending a slow ramp of the throttle command and collecting the drum rotating speed and the pressure change inside hydraulic circuitry.

So we can find that between the throttle command and a pump displacement, there is a very large deadband and also a nonlinear flow mapping. After we calibrate all the model, we compare with the testing data and simulation data to verify that our model is actually approximately the behavior of the actual equipment.

In order to control-- conduct the controller design, we need to develop a system model, which grounds the parameter and that is hector plus to our control design tools. In this process, we conduct a winch controller-- winch systems model. So from the hydraulic system point of view, the variable displacement pump generate the hydraulic flow goes into the hydraulic disk-- hydraulic motor.

Hydraulic flow in the hydraulic circuitry will generate the pressure change. Those pressure change across the motor will generate a motor torque, and those motor torque will rotating the winch mechanic-- winch drum and also move the tool up and down through the wellbore.

So if we assume a load of pressure, which is the pressure difference across the hydraulic motor as one of the state variables together with the tool position and tools speed, we can transform those system dynamic equation into a state space representation. So we can use our controller design tool to design a controller to achieve our motion control purposes.

So if we look at the system dynamic equation on the right side, and we look at the first two equations, we know that the tool motion is generated by the load pressure inside the hydraulic system. So in the first step, what we want to do is we're trying to design a desired low pressure for the system load pressure such that tool motion will follow our desired motion trajectory.

The exact design methodology we're using is the backstepping design through the Lyapunov function. The resulting control-- virtual controller consisting both of model from the second part and feedback part. The feedback part can be further divided into the robust control part and the normal feedback control part.

So if we look at the third equation of the system equation, we know that the system load pressure is generated by the-- system hydraulics flow goes into the system. So in this step, we want to synthesize the controller for the actual pump displacement such that the load pressure will track the virtual control function we synthesized in the first step. And finally, the actual control command, the throttle command, can be calculated from the inverse nonlinear mapping between the throttle command and the pump displacement. The whole controller is implemented in Simulink.

And now, I'll give you an idea how we implement the winch controller design. The control software design is implement based on the microservice architecture. Each hexagon represent a microservice packed in a Docker container.

In this case, we have several control-- macro servers. For hardware interface, it's interface directly with the hardwares to acquire sensitive information for the cable speed, and tension, and the tool depth, and also interface with winch DCU to get a winch sensing information such as the drone speed, hydraulic pressure, and also sending out the control command directly to the hydraulic winch.

And there is also the controller service, which we synthesized-- we developed using Simulink in a previous presentation. And also the simulator service will provide the behavior of the equipment when we are running the whole system in the Software-in-the-Loop fashion. To share the data across the different microservice, RabbitMQ, a open-source message broker, we used to routing the message with data among different microservice.

To build container services from Simulink/Simscape diagram, we utilize the code generation capability of MATLAB Simulink/Simscape. But we generally see code from MATLAB Simulink/Simscape and compile those generated code into a Linux shared library. Outside of those shared library, we wrap around a Java wrapper. The function of those Java wrapper is trying to execute those shared library and in the same time communicate with other microservices through the RabbitMQ messages. So all this building is automatically executed in Jenkins or Azure DevOps pipeline whenever we push a new development of MATLAB Simulink.

Follow our model-based design process, we conduct Model-in-a-Loop testing in the Simulink level. Using the controller and equipment model we developed previously, we provide different inputs through the Simulink dashboard. Later, we're also using a Simulink test to automate those testing process.

Follow the model-based design process, after Model-in-a-Loop testing, we conduct Software-in-a-Loop testing. Basically, in a Software-in-a-Loop testing, the simulator is running in spite of the actual hardware. So at this time, the controller acquire all the necessary sensing information from the running simulator instead of actual hardware and also sending out the control command to the simulator. And all this Software-in-a-Loop can automatic conduct in the Azure DevOps or Jenkins pipeline, and we wrote a different test bench using the Python program.

And finally, we are conducting the truck testing in the real truck hardware. So this shows moving the tool, going into the hole. We set a target date in a different target depth level and with different desired tool speed. And on the right, you can see the tension measurement.

We want to control the tension also in-- within a certain limit. As you can see, when we're moving the tool inside the well, it encounters several certain heavy mud in certain situations. When the tool goes into the heavy mud, the dynamic damping force acting on the tool will increase. It will reduce the tension below it's required level. So at that time, the winch controller will automatically slow down the tool speed so that the tension will recover to its required limits.

So in conclusion, in this project we conduct the multi-domain physical system modeling using the Simscape/Simulink. We use the existing library to-- for different component of our system. We also customize component modeling using Simscape language. We conduct controller algorithm design using Simulink/Stateflow together with other tools such as the Control System Toolbox, Simulink Design Optimization to speed up the controller design.

We use Model-in-a-Loop simulation and testing to figure out what-if analysis and automated those Model-in-a-Loop testing using Simulink Test. We use code generation capability of Matlab Simulink for both controller and system model, so we eliminate manual coding and speed up implementation. And we containerized the controller and simulator, which will facilitate a continuous implementation and continuous delivery. Also, by containerized the equivalent simulator, we democratized the model simulation.

And before, to conduct model simulation in a Simulink MATLAB environment, it required a special knowledge of the MATLAB, and Simulink, and probably the physical system. By containerized the simulator, we allowed the software engineer without any knowledge of Simulink and MATLAB to conduct the Software-in-a-Loop simulation with the developed software and also build and test automatically using Jenkins and Azure DevOps pipeline. And we automatic conduct build and regression test. This concludes my presentation today. Thank you very much.