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.