Workstream Page: Reference Architecture

Click on the tabs below for more information or click here to return to all D-WIS Workstreams.

The reference architecture requirements cover the system organization, so that it is scalable to batch processing of wellbore construction. It is concerned with the hierarchy of procedures, the multiplayer advisor environment, authorization and authentication of components, and the state of the various activities on both surface and downhole. These requirements ensure an architecture that is relevant to batch processing and, in future, well construction orchestration.

RequirementConsiderations
Define approach for batch procedure development.The standards shall be capable of scaling to batch processing of a wellbore, where a batch is a borehole section, fluid for a borehole section, etc.  
Define approach for handling multiple advisors during a phase of drilling.There could be multiple advisors, from multiple players, running in parallel during any phase of the drilling operation  
Define approach for handling hierarchy of drilling phases and handling of advisors.Wellbore construction is a hierarchy of phases, as partially defined in IADC DDR Plus. The architecture shall be capable of handling multiple advisors across and between these phases.  
Define approach for contextualization of common data items.DWIS is primarily concerned with data exchange, and it is therefore important to define – and know – the context of the data.  
Define AuthN/Z for integrating into system.Advisors (applications) need to be fully authenticated and authorized before becoming members of the system  
Define methodology for communicating to Driller from Batch.As part of the architecture, it should be specified how the driller communicates with batch processes (and sub-processes) to develop a standard, reliable, interface  
Define method of registering Batch processes relative to a phase of Drilling.  A batch process may be valid and operational across multiple drilling phases, and this validity must be known to schedulers and third party advisors  
Identify and address cross cutting concerns including but not limited AuthN/Z, Logging, Batch Processing, Advisor Registration, Advisor State Management, Drill State, Rig State  Various concerns may apply to all components in DWIS. These need to be identified and addressed in a scalable fashion
Architecture integration with Drill State and Rig State inference.  Rig State (rig activity) and Drill State (borehole activity and condition) are relevant to registered advisors. They may prepare to run, execute, or terminate, depending on these states. Therefore, definitions should be agreed upon that are scalable across control and batch processing.  

The Drilling and Wells Interoperable Standard covers the simultaneous use of multiple advisors that may:

  • Monitor the drilling condition and equipment,
  • Advise on set points and limits for rig equipment to optimize the drilling process or protect the wellbore,
  • Control equipment in some fashion - an example is a downlink sequence for control of a rotary steerable downhole tool

Worth noting here is the separation of concerns: D-WIS only issues set points and limits for rig systems that are exposed in the ADCS. This leaves the machine automation and control of rig equipment strictly within the rig domain of the Driller. D-WIS is concerned only with slower automation of the drilling process (procedures, safety, well bore protection, optimization, etc.). However, third party advisors may have their own equipment that they control (for example MPD systems, MWD/LWD systems, etc.).

The selection of an advisor may depend on the current operation. For example, an advisor for "setting the bit on bottom" may be scheduled and used at a specific point in the well construction process. The reference architecture must provide a framework for scheduling, prioritizing and activating advisors. It must also deliver consolidated (and meaningful) advice from the multiple advisors that may be active at any time, and ensure that contextual (system) information flows to all advisors.

Obviously the step of coordinating advisors leads to "batch" processing possibilities, and ultimately the orchestration of a digital drilling plan.

The reference architecture covers this framework, ensuring that the advisors are sequenced correctly and deliver consolidated advice through the ADCS software interface.

The reference architecture for D-WIS is under development, but a broad overview is described here.

Architecture

  • System State: coordination of advisors, and the type of advisor that may be active at any point in time, depends on common knowledge of the state of the drilling system. This may be equipment state (starting, running, etc.), the state of the operation, known as rig activity (drilling, tripping, reaming, making a connection, circulating, rotating, etc.)., or state of the borehole (hole cleaning, sloughing, influx, etc.) 
  • Advisors: these are third party applications with some, such as MWD services, with associated equipment. In general, advisors issue set points and limits for equipment, and the selection of current advisors depends on systems state. Within any one state, there may be priority of advice and advisor.
  • Automation Sequencer: the automation sequencer manages the "gaggle"  of advisors, depending on system state and procedural information contained in the drilling plan.  The automation sequencer may be viewed as a batch controller that is capable of handling events and alarms.
  • Shared Contextual Data: this is data required by all components of the architecture for execution. It also contains the digital plan or section plan, and the procedures (recipes) used by the batch sequencer. This is also the interface with the offsite world, for example with the digital drilling plan.
  • D-WIS Automation System: this is where the advice from the advisors is collated and delivered via the D-WIS Software interface to the ADCS. 

Reference Architecture Contributors

  • Clinton Chapman - Schlumberger
  • Hans-Uwe Brackel - Baker Hughes
  • Dmitriy Dashevskiy - Baker Hughes
  • Fred Florence - Rig Operations, LLC
  • Loic Hoarau - Schlumberger
  • Dimitrios Pirovolou - Weatherford
  • Pradeep Annaiyappa - Nabors
  • Eric Cayeux - Norse
  • Darryl Fett - TotalEnergies
  • John Macpherson - Baker Hughes
  • Serafima Schaefer - Exebenus
Scroll to Top