Using Model Based Design to Implement the Motor Control Logic of an Electric Downhole Flow Control Valve

Hello. Welcome to today's presentation. My name is Michel Gardes. I work for Schlumberger. And my presentation will be about using model-based design to implement the motor control logic of a fully-electric downhole flow control valve. I will start by presenting the project.

We will then go through the Simulink model that we created to implement the motor control logic, the test harnesses that were used to test the model, the code generation procedure, and the CPU load concern that we had when you first started generating code, the improvements that were made to the model and to the generated code to address the CPU load concern, the results that we obtained, and I will finally conclude the presentation.

Downhole flow control valves are devices that control the flow of a producing zone in a well. They're typically designed for high-flow rates. Today, most of these devices are hydraulic. There are a few drawbacks related to this hydraulic technology. Installation is complex.

There is one hydraulic line per valve plus one optional return line. This limits the number of valves in a well to usually a maximum of five. And the several feedthroughs that are running through the completion might become potential leakage paths with time as a completion gets old.

There is a drawback related to the operation of the valve itself. Before fully opening the valve, we need first to fully close it. There is a cycle that needs to be respected when we move these indexing bulbs to the next position. It cannot move from any position to any position.

With the electric technology, we will have a simpler installation. There will be one single electrical line for all the valves in the well. And the number of valves in the well will not be limited. The only limiting factor will be the available electric power at surface. Reliability will be increased, as we will be minimizing the number of potential leakage paths in the installation. Finally, valve operation will be more versatile, as we will be able to actuate from any position to any position.

How do we actuate an electric downhole flow control valve? In our case, we use an electromechanical actuator, or EMA, which is made of a three-phase permanent magnet synchronous motor, a gearbox, and a roller screw, which is translating the rotation of the motor into a linear movement of a rod, that by pushing and pulling a piston will be closing and opening the valve.

We chose to implement a position measurement in the motor itself. That was achieved by having a resolver mounted on the motor shaft. The main reason behind this decision is that the EMA must be able to apply the maximum force as soon as it starts actuating. And a censored motor control is more suitable for applications requiring high torque at low-speed or zero speed.

The microcontroller that we're using on this project is the STM32L4 from ST. It's a low-power Cortex-M4 microprocessor with interesting functions for motor control applications such as complimentary PWM outputs with programmable dead-time, break inputs for safety purposes. It is also able to acquire two ADC channels simultaneously. And it has a floating point unit, which we'll be talking about later.

The reasons why we used model-based design on this project are several. One of the main reasons is that when we started working on the motor control logic, we did not have the motor itself. And we wanted to be able to progress on the development of the logic before having the motor.

We didn't want to wait until we received the motor to start working on that. Simulation allowed us to progress on this development without the motors. It also gave us the flexibility to test different types of motors without buying them. Troubleshooting is more effective as well, because when something goes wrong, we know that troubleshooting hardware in a motor control application can be very time-consuming. And it can be very hard.

We believe that with simulation, it will be easier to troubleshoot, to reproduce our errors and to correct them. Finally, Simulink gives us the ability to simulate corner cases that are hardly testable in real life, either because they are destructive or because they are dangerous, because there are safety concerns related to these tests.

The motor control method that we implemented on this project is field-oriented control. We need a robust control method with a high-dynamic performance. And field-oriented control gives us that. Given that we did not have previous experience with this control method, we approached MathWorks in order to develop this model in collaboration with their consulting team.

So the way we proceeded is that we have been working with them for the past one year and a 1/2. At the very beginning of the project, we gave them all our requirements, the inputs. We spent a lot of time with them explaining our needs, how the flow control valve operates. And they created the model for us.

The model that was created has three control loops. The innermost control loop is the current control loop with two PI controllers. The first controller is maximizing the Iq current, which is the current component that is actually generating torque.

The second PI controller is minimizing the Id current, which is the current component, which is not generating torque. Above that, we have the speed control loop, where we can set a speed as a point or a torque as a point. And above that, we have a position control loop, where we can set a position set point, which is the actual desired position of the flow control valve. And that will be our default operating mode.

Once the model was developed, we needed to test it. And the MathWorks consulting team suggested we implement test harnesses for our model. That's something we were not familiar with. And they showed us how to work with that. So we developed several harnesses, here I'm showing only one of them, with different test scenarios that cover all the functions of our flow control valve and all the control modes that are available in our control logic.

Once the test harnesses were ready to be executed, we used Simulink Test Manager to run them. That was a new approach for us, because we were used to simply running the simulation with some scopes in the model, likely some signals, and that's it.

And the Simulink Test Manager gave us a much easier way to launch tests, analyze the results, compare results, and keeping track of the results of different tests. So we really appreciated working with the Simulink Test Manager. But using Simulink Test Manager was a great improvement compared to what we were doing before.

Once the tests were providing the expected results, we decided to generate code and run it on our target. We used Embedded Coder to generate this code. And we used it for the control algorithm only, which means that all the drivers that are required to run our own electronics were actually hand-coded. So we are integrating the generated code into a handwritten code. And that's our final application.

We downloaded the STM32 support package for Simulink, which allowed us to specify that we were using the STM32 evaluation board, which was later used for processor in the loop tests. And we set among our primary objectives in Embedded Coder the execution efficiency, as our target is to have the lowest CPU load.

The first tests that we performed with the generated code were a processor in the loop mode with Simulink and the evaluation board of our microprocessor. The Simulink reports indicated a much higher CPU load required to run the controlled logic than what we had initially estimated.

So we had estimated around 1,300 cycles to implement a censored field-oriented control. And the Simulink reports were giving us 4,800 cycles. Our lab measurements confirmed that when we ran the generated code. With our own drivers on our own electronics, we had pretty much the same value. And that was achieved with compiler optimization on top of that. So the results were not satisfactory. And we had to find ways to improve that.

The first improvement that we have made to the model was to assign the correct data types to all Simulink parameters and signals. We noticed that they had initially been defined as auto. And Embedded Coder will convert all the auto values to 64-bit floating point values. As we have a 32-bit floating point unit, having a 32-bit FPU handling 64-bit values is extremely time-consuming. So we made sure that we had no 64-bit data types defined in our model.

The same thing applies to block outputs. Some block outputs had the auto data type when that was not needed, because auto was being converted to 64-bit floating point values. So we set single whenever that happened in order to make sure we had no 64-bit floating point values in the code.

There are Simulink blocks that are not 32-bit compatible either, which means that if you use them in your model, no matter what you do, whenever you generate code, there will be a 64-bit value or operation somewhere. So we replaced those blocks by equivalent blocks that were 32-bit compatible.

In order to do that, we used a single precision converter which, in our case, did not work for the conversion itself, because we had some errors that we cannot address. But it helped us identify the blocks that were not 32-bit compatible. And once they were identified, we replaced them manually.

Finally, we can also select an Embedded Coder, the C standard that we will use for code generation. So we can choose between C89 and C99. C99 implements floating point functions that are not available in C89. And that will have a considerable impact on your generated code. Now one might think that C99 will always be better than C89 because you have floating point functions. That is not always the case. And we will show you that.

So here we have an example where C99 is indeed better than C89. So the floating point functions here for absolute values or the floor function are actually running faster than the C89 versions with all the casting of these values here. Now if we take another function such as the fmaxf, which is defining the maximum value among several values, we notice that the C89 implementation with a sequence of if else's is actually performing better than the floating point function.

So if you are performing this operation several times in your code, that might have a considerable effect on your final CPU load. What we ended up doing in our project is that we generated code for both standards, C89 and C99. We took the best out of each. And we blended both in order to achieve the optimal CPU load. And it's this blend of C89 and C99 that we integrate into our final application.

The results that we obtained with that is that from the initial 4,800 cycles that we first had when we started generating code, we ended up having 1,500 cycles. So that's a threefold improvement, even better than that. And that was achieved without any compiler optimization. That allowed us to lower the clock frequency and to implement the CPU clock that we had initially targeted.

Our conclusion is that implementing model-based design with MathWorks consulting team not only allowed us to achieve challenging deadlines, but was also an opportunity to acquire new skills while saving time and reducing costs. Code generation is very useful. We are convinced that it's a very important step when it comes to being efficient. Now we also believe that optimal performance might require manual intervention, such as the actions that we have described here

I would like to thank Wided and Zakaria from MathWorks friends. They are the two people that we have been working with since last year. We have learned a lot with them. And it's been a great collaboration. And I also would like to thank Denis Heliot from Schlumberger. He's the one that let me know this conference and helped me register. Thank you for your attendance. And I will be more than glad to answer any question that you might have.