The industry has gotten really good at capturing large amounts of data from the drilling operation, yet it has not been able to get nearly as good when it comes to using that data. A major improvement could be made by closing the loop for decision-making applications, achieving real-time optimization of drilling equipment control, said Jens Ornaes, National Oilwell Varco, during a presentation at the 2010 IADC/SPE Drilling Conference on 3 February in New Orleans.
In other words, he explained, new technologies could give an application or system, possibly in a remote location, the ability to give control input to the drilling control system on the rig.
The Integrated Operations in the High North (IOHN) joint industry project began in early 2008 with an objective of creating a digital platform for next-generation integrated operations. Under the IOHN umbrella, the AutoConRig project was organized with three focus areas:
• Development of a standard for communicating with the drilling machine.
• Identifying the framework and developing mechanisms to increase the level of automation in drilling control systems.
• Creation and maintenance of drilling-related ontologies.
“The main objective of this project is to come up with a way so that drilling centers, reservoir production centers, operational maintenance centers, environmental centers can all talk to each other in a uniform and standardized way through high-capacity network and infrastructure,” Mr Ornaes said.
A high level of automation would have to be intrinsically involved. Rather than having the service company engineer call the driller to tell him what to do, the service company’s decision-making systems should communicate directly with the control system on the rig and intervene directly.
Examples of uses for a drilling control communication standard would include down-linking to the bottomhole assembly, restricting tripping speed, deploying managed pressure drilling and deploying auto-drillers.
Among the nonfunctional requirements for such a standard would be a generic, standardized communication layer, Mr Ornaes said. “We need to come up with a level of standardization, a level of generalization, so that what we define as standard is not dependent on equipment, not dependent on the type of control system, not dependent on the vendor of the control system … it needs to be a generic definition.”
There would also be functional requirements, including control of physical entities on the rig and control discovery. “A client can ask the rig, What are your capabilities? Can I control RPM at your rig? He can get a reply and be able to initiate that communication” if there is a common standard for equipment to inter-operate, Mr Ornaes said.
Functions for physical entities is another requirement that would include envelope registration and envelope querying. “An envelope is a sort of sophisticated maximum value or limit, if you like. For example, if you have an envelope for tripping speed, it will contain the maximum tripping speed you’re allowed to have. But it also contains the acceleration ratio and the diesel ratio to get there.”
He continued to explain that the two main constructs that will define the standard will be meta language definitions, or web service definitions, and a reference library.
The meta language definitions contain the transfer mechanisms and should be as static as possible. “That part is about … how do you transfer an envelope? How do you transfer the set points? … We want the transfer mechanism to be as standard as possible so that we don’t have to run around to all the places where we deploy (the technology) and change the standard all the time.”
On the other hand, the reference library will have to be dynamic so physical entities can be easily added for control.
The AutoConRig project began in 2008 and will continue until May 2012. Additional information about the project can be found in IADC/SPE 126907, “Closed-Loop Control for Decision-Making Applications in Remote Operations.”