<img height="1" width="1" src="https://www.facebook.com/tr?id=1101141206686180&amp;ev=PageView &amp;noscript=1">

Blog

A Guide to Successful Multi-vendor MWD/LWD Implementation, Part 1

 

Introduction

Over the past 40+ years, MWD/LWD systems have proven their ability to deliver more timely and accurate formation, well, and drilling parameters than their wireline counterparts. However, not all measurement, telemetry, and other string options are available from every MWD/LWD vendor. Because of this, an MWD/LWD service provider may be unable to provide a service demanded by an operator, and will end up losing the bid for reasons other than price.

The solution is for the service provider to combine tools from multiple vendors to create an “integrated” string that meets operators’ requirements. This is achieved by drawing on the expertise of vendors experienced with multi-vendor integration projects.

This series of blog posts examines the major technical, project management, and operational challenges of successfully implementing multi-vendor MWD/LWD systems.

Background

A few years ago I noticed a significant uptick in the number of multi-vendor system integration projects I was managing/engineering for MWD/LWD service providers, largely due to the introduction of a new formation evaluation tool into the market. While each project was unique in some sense, they also shared many common traits which enabled us to routinize much of the work, particularly in the planning stage. Several “integration project templates” for planning, design & development, and testing evolved based on our service provider customers’ technical knowledge, resources, and desire to participate in the project.

Planning

The best model for each project becomes apparent early in the initial planning stage, where the vendors and the service provider present their proposed architectures and desired design outcomes, partition system functions, and assign development and project management tasks. At one extreme, the service provider simply provides a few BHA sketches and pays for a turnkey solution. At the other, the provider is their own equipment vendor (eg. a Tier 1 service company), the designer of the MWD/LWD system getting the upgrade, and a partner in the integration project. Specific “integration project checklists” for these two scenarios (and some in between) are beneficial at this stage.

In addition to design details and measurement performance requirements, operational requirements are also collected at this stage to ensure the service provider’s and operators’ acceptance of the integrated system.

At the conclusion of this stage, all vendors involved exchange “integration packets” (under a Non-disclosure Agreement, or NDA) containing all the technical documentation and software code needed to begin their respective development tasks. A common, secure web portal is set up to facilitate the exchange, and to keep information up-to-date for all parties.

Next, development and design qualification proceed until all subsystem requirements are met. Then comes system integration testing, followed by field testing.

This blog post series will show, largely through the use of high-level tables and diagrams, the architectural, operational, and project management views on multi-vendor MWD/LWD implementation, and will present some case studies as examples.

Design & Development

System Architecture: Blocks, Lines, Layers, and Planes

“Architecture” means defining the main components of the completed system, and the relationships between them. Depending on the complexity of the project, these components may include:

        • Mechanicals: Eg. Packaging; mounting; fasteners; seals; tubular adapters, including probe-to-collar transition assemblies
        • Electromechanicals: Eg. Cables, connectors, and shielding
        • Transducers, which convert physical phenomena to voltages or currents, or vice versa
        • Electronics: Eg. Circuit boards and discrete off-board components like batteries and large inductors and transformers
        • Intra- and inter-system communications: Typically broken-down into several “layers” of network protocols, and often requiring a translator circuit board. Data, Control, and Management “planes” broadly define the purpose of different types of messages used
        • Firmware: Eg. For enabling communication between downhole tools, or between a tool string and a rig floor box before and after a run. Also, for enabling different operating modes and telemetry messages depending on operating requirements and downlinked commands
        • Software: Eg. For tool configuration, data download/management, calibration, measurement corrections/transformations/inversions, log plotting, and communication with the Cloud
        • Data records: Eg. How individual measurements and sets of measurements are stored in a tool and in surface gear
        • Database: Eg. How sets of dissimilar measurements and “metadata” (data about the data) are grouped and related to one another
        • Mnemonics: Eg. The codes used to tag and identify individual measurements
        • Telemetry formats: Eg. Mud pulse and EM coding schemes, message formats, and message sequences

While not usually considered “architectural,” materials selection requirements like alloy compositions; platings, coatings, and treatments; composites; damping elements; and inter-material compatibilities are also an important piece of a successful integration project.

Well-annotated architectural block diagrams go a long way towards defining a multi-vendor system’s architecture. They are a tool for visualizing the project’s scope and its degree of design complexity, identifying risks up front, resolving those risks before they become issues, and quickly reaching agreement by all parties on the path forward.

In the next installment of this series we will look at some example block diagrams for a typical integration project involving all of the components listed above.

 

 

Recent Posts:

Filtering Basics: Importance of Linear Phase
Publish Date 20 Oct 2021 Jason ThaiJason Thai

Linear phase and computation/memory complexity are important characteristics to [..]

Revisiting OAuth 2 in LabVIEW
Publish Date 20 Oct 2021 John AmstadtJohn Amstadt

Recap In my previous blog, we took a look at how to implement OAuth2 in LabVIEW. [..]

Engineering a Better 3D Print (Part 1)
Publish Date 20 Oct 2021 Michael MaloneyMichael Maloney

3D Printing and its widespread use has been a long time coming and seems to have [..]

NVCC – Intro to Utilizing GPU Power to Offload the CPU Part 3
Publish Date 20 Oct 2021 Jack BakerJack Baker

Assumptions: Machine has a Nvidia CUDA Core GPU (such as a GeForce) with installed [..]

How I Learn New Skills for Personal Growth
Publish Date 20 Oct 2021 Bryce UrestiBryce Uresti

Learning new skills can be quite the task especially when there's already so much [..]

Controlling the Supply Chain Dream
Publish Date 20 Oct 2021 Thomas MathewThomas Mathew

You are out with your friends, bird watching, and nothing could be more peaceful. [..]

Aligning Data in WAVE
Publish Date 20 Oct 2021 Rohama KhadijaRohama Khadija

When analyzing data from multiple sources, we often find that the time series data [..]