CA2689756A1 - Method and apparatus for decoding a signal sent from a measurement-while-drilling tool - Google Patents
Method and apparatus for decoding a signal sent from a measurement-while-drilling tool Download PDFInfo
- Publication number
- CA2689756A1 CA2689756A1 CA2689756A CA2689756A CA2689756A1 CA 2689756 A1 CA2689756 A1 CA 2689756A1 CA 2689756 A CA2689756 A CA 2689756A CA 2689756 A CA2689756 A CA 2689756A CA 2689756 A1 CA2689756 A1 CA 2689756A1
- Authority
- CA
- Canada
- Prior art keywords
- signal
- decoder
- processing unit
- signal processing
- decoding
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
- 238000000034 method Methods 0.000 title claims abstract description 77
- 238000005553 drilling Methods 0.000 title claims abstract description 27
- 238000013519 translation Methods 0.000 claims abstract description 19
- 230000005540 biological transmission Effects 0.000 claims abstract description 14
- 238000012545 processing Methods 0.000 claims description 112
- 238000011144 upstream manufacturing Methods 0.000 claims description 16
- 230000004044 response Effects 0.000 claims description 3
- 238000004891 communication Methods 0.000 description 8
- 238000005070 sampling Methods 0.000 description 5
- 238000010586 diagram Methods 0.000 description 3
- 230000005484 gravity Effects 0.000 description 2
- 239000011435 rock Substances 0.000 description 2
- 230000001143 conditioned effect Effects 0.000 description 1
- 230000003750 conditioning effect Effects 0.000 description 1
- 238000012937 correction Methods 0.000 description 1
- 230000003111 delayed effect Effects 0.000 description 1
- 238000013461 design Methods 0.000 description 1
- 238000001914 filtration Methods 0.000 description 1
- 239000012530 fluid Substances 0.000 description 1
- 230000005251 gamma ray Effects 0.000 description 1
- 238000005259 measurement Methods 0.000 description 1
- 238000012986 modification Methods 0.000 description 1
- 230000004048 modification Effects 0.000 description 1
- 230000005855 radiation Effects 0.000 description 1
- 238000011084 recovery Methods 0.000 description 1
- 239000004065 semiconductor Substances 0.000 description 1
Classifications
-
- E—FIXED CONSTRUCTIONS
- E21—EARTH DRILLING; MINING
- E21B—EARTH DRILLING, e.g. DEEP DRILLING; OBTAINING OIL, GAS, WATER, SOLUBLE OR MELTABLE MATERIALS OR A SLURRY OF MINERALS FROM WELLS
- E21B47/00—Survey of boreholes or wells
- E21B47/12—Means for transmitting measuring-signals or control signals from the well to the surface, or from the surface to the well, e.g. for logging while drilling
- E21B47/14—Means for transmitting measuring-signals or control signals from the well to the surface, or from the surface to the well, e.g. for logging while drilling using acoustic waves
- E21B47/18—Means for transmitting measuring-signals or control signals from the well to the surface, or from the surface to the well, e.g. for logging while drilling using acoustic waves through the well fluid, e.g. mud pressure pulse telemetry
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L1/00—Arrangements for detecting or preventing errors in the information received
- H04L1/004—Arrangements for detecting or preventing errors in the information received by using forward error control
- H04L1/0045—Arrangements at the receiver end
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L25/00—Baseband systems
- H04L25/38—Synchronous or start-stop systems, e.g. for Baudot code
- H04L25/40—Transmitting circuits; Receiving circuits
- H04L25/49—Transmitting circuits; Receiving circuits using code conversion at the transmitter; using predistortion; using insertion of idle bits for obtaining a desired frequency spectrum; using three or more amplitude levels ; Baseband coding techniques specific to data transmission systems
Abstract
Disclosed are a method and an apparatus for decoding a signal sent from a measurement-while-drilling tool. In order to decode the signal, a decoder implementation that is communicative according to a decoder implementation protocol and that is configured to decode the signal into a decoded signal is instantiated. The decoder implementation protocol is then conformed to a transmission protocol. The signal is sent to the decoder implementation according to the transmission protocol. Because the decoder implementation protocol has been conformed to the transmission protocol, the decoder implementation can receive the signal and can decode it. One way in which the decoder implementation protocol can be conformed to the transmission protocol is through the use of a translation layer between the module that sends the signal to be decoded and the decoder implementation.
Description
METHOD AND APPARATUS FOR DECODING A SIGNAL SENT FROM A
MEASUREMENT-WHILE-DRILLING TOOL
TECHNICAL FIELD
The present disclosure is directed at a method and apparatus for decoding a signal sent from a measurement-while-drilling tool. More particularly, the present disclosure is directed at a method and apparatus for facilitating use of multiple decoding units to decode differently encoded signals.
BACKGROUND
When drilling for oil or gas, accurately and precisely tracking the position of the borehole can be vitally important. For example, a directional driller may need to orient the borehole such that it either avoids or intersects one or more existing boreholes. Knowing the position of the borehole also allows the borehole to be drilled at an angle such that oil recovery from a reservoir can be increased by ensuring that the area of intersection between the borehole and the reservoir is relatively high. Furthermore, knowing the position of the borehole may be important to ensure that drilling does not occur in a prohibited area, such as an area in which only a competitor has rights to drill. Even when the borehole is intended to extend vertically, tracking the position of the borehole can be important to ensure that the borehole is, in fact, being drilled vertically.
To track borehole position, a measurement-while-drilling ("MWD") tool can be used. A MWD
tool contains measurement instruments that are located within a drill string and typically near a drill bit. The MWD tool typically measures a variety of parameters relevant in directional drilling, such as:
= drill string inclination;
= drill string azimuth;
= toolface;
= gamma rays;
= resistivity of surrounding rock; and = various diagnostic information (temperature, battery status, dip angle, total magnetic field strength, and total gravitational strength).
The MWD tool communicates measured parameters by sending a signal to the surface using any one of a variety of known transmission techniques, such as mud pulse telemetry, electromagnetic telemetry, and wired pipe. The transmitted information is then used by any one or more of the directional driller, a geologist, and a MWD technician to drill the borehole according to a predetermined trajectory.
The signal the MWD tool transmits can be encoded according to a cipher that is proprietary to the MWD tool manufacturer. Consequently, in order to decode the signal, a decoder that the MWD tool manufacturer provides is required. In other words, a one-to-one dependence typically exists between the MWD tool and the decoder used to decode signals that the MWD tool transmits. This setup can be cumbersome when a user wants to use a single piece of hardware to decode signals sent from a variety of different MWD tools.
Accordingly, there exists a need for at least one of a method and apparatus for decoding a signal sent from a MWD tool that improves on the prior art.
SUMMARY
According to a first aspect, there is provided an apparatus for decoding a signal sent from a measurement-while-drilling tool. The apparatus includes a signal processing unit communicatively coupled to the measurement-while-drilling tool. The signal processing unit has a downstream interface configured to communicate according to a signal processing unit protocol. The downstream interface is for sending the signal for decoding and for receiving a decoded signal. The apparatus also includes a decoding unit, which includes a decoder implementation and a translation layer. The decoder implementation is configured to decode the signal into the decoded signal and has an upstream interface that is configured to communicate according to a decoder implementation protocol. The upstream interface is for receiving the signal for decoding and for sending the decoded signal. The translation layer is communicatively coupled between the downstream interface of the signal processing unit and the
MEASUREMENT-WHILE-DRILLING TOOL
TECHNICAL FIELD
The present disclosure is directed at a method and apparatus for decoding a signal sent from a measurement-while-drilling tool. More particularly, the present disclosure is directed at a method and apparatus for facilitating use of multiple decoding units to decode differently encoded signals.
BACKGROUND
When drilling for oil or gas, accurately and precisely tracking the position of the borehole can be vitally important. For example, a directional driller may need to orient the borehole such that it either avoids or intersects one or more existing boreholes. Knowing the position of the borehole also allows the borehole to be drilled at an angle such that oil recovery from a reservoir can be increased by ensuring that the area of intersection between the borehole and the reservoir is relatively high. Furthermore, knowing the position of the borehole may be important to ensure that drilling does not occur in a prohibited area, such as an area in which only a competitor has rights to drill. Even when the borehole is intended to extend vertically, tracking the position of the borehole can be important to ensure that the borehole is, in fact, being drilled vertically.
To track borehole position, a measurement-while-drilling ("MWD") tool can be used. A MWD
tool contains measurement instruments that are located within a drill string and typically near a drill bit. The MWD tool typically measures a variety of parameters relevant in directional drilling, such as:
= drill string inclination;
= drill string azimuth;
= toolface;
= gamma rays;
= resistivity of surrounding rock; and = various diagnostic information (temperature, battery status, dip angle, total magnetic field strength, and total gravitational strength).
The MWD tool communicates measured parameters by sending a signal to the surface using any one of a variety of known transmission techniques, such as mud pulse telemetry, electromagnetic telemetry, and wired pipe. The transmitted information is then used by any one or more of the directional driller, a geologist, and a MWD technician to drill the borehole according to a predetermined trajectory.
The signal the MWD tool transmits can be encoded according to a cipher that is proprietary to the MWD tool manufacturer. Consequently, in order to decode the signal, a decoder that the MWD tool manufacturer provides is required. In other words, a one-to-one dependence typically exists between the MWD tool and the decoder used to decode signals that the MWD tool transmits. This setup can be cumbersome when a user wants to use a single piece of hardware to decode signals sent from a variety of different MWD tools.
Accordingly, there exists a need for at least one of a method and apparatus for decoding a signal sent from a MWD tool that improves on the prior art.
SUMMARY
According to a first aspect, there is provided an apparatus for decoding a signal sent from a measurement-while-drilling tool. The apparatus includes a signal processing unit communicatively coupled to the measurement-while-drilling tool. The signal processing unit has a downstream interface configured to communicate according to a signal processing unit protocol. The downstream interface is for sending the signal for decoding and for receiving a decoded signal. The apparatus also includes a decoding unit, which includes a decoder implementation and a translation layer. The decoder implementation is configured to decode the signal into the decoded signal and has an upstream interface that is configured to communicate according to a decoder implementation protocol. The upstream interface is for receiving the signal for decoding and for sending the decoded signal. The translation layer is communicatively coupled between the downstream interface of the signal processing unit and the
-2-upstream interface of the decoding unit and is configured to translate the signal processing unit protocol to the decoder implementation protocol such that the signal processing unit and the decoding unit are communicatively coupled.
The signal processing unit protocol can include method calls to an application programming interface.
The apparatus may include a plurality of decoding units, including first and second decoding units. The decoder implementation of the first decoding unit and the decoder implementation of the second decoding unit can be configured to decode differently encoded signals.
The apparatus can also include a decoder configuration manager communicatively coupled to the signal processing unit and configured to instantiate any one of the decoding units in response to a selection signal sent from the signal processing unit.
The apparatus can also include a decoder definition list file containing a listing of decoder definition files corresponding to the plurality of decoding units. The decoder configuration manager can instantiate any one of the decoding units by accessing the decoder definition list file and by executing one of the decoder definition files.
The translation layer may include a listener module configured to receive a parameter of the decoded signal from the upstream interface of the decoding unit and to asynchronously send the parameter of the decoded signal to the downstream interface of the signal processing unit.
According to another aspect, there is provided a method for decoding a signal sent from a measurement-while-drilling tool. The method includes instantiating a decoder implementation configured to decode the signal into a decoded signal and communicative according to a decoder implementation protocol; conforming the decoder implementation protocol to a transmission protocol; sending the signal according to the transmission protocol to the decoder implementation; and decoding the signal into the decoded signal using the decoder implementation.
The signal processing unit protocol can include method calls to an application programming interface.
The apparatus may include a plurality of decoding units, including first and second decoding units. The decoder implementation of the first decoding unit and the decoder implementation of the second decoding unit can be configured to decode differently encoded signals.
The apparatus can also include a decoder configuration manager communicatively coupled to the signal processing unit and configured to instantiate any one of the decoding units in response to a selection signal sent from the signal processing unit.
The apparatus can also include a decoder definition list file containing a listing of decoder definition files corresponding to the plurality of decoding units. The decoder configuration manager can instantiate any one of the decoding units by accessing the decoder definition list file and by executing one of the decoder definition files.
The translation layer may include a listener module configured to receive a parameter of the decoded signal from the upstream interface of the decoding unit and to asynchronously send the parameter of the decoded signal to the downstream interface of the signal processing unit.
According to another aspect, there is provided a method for decoding a signal sent from a measurement-while-drilling tool. The method includes instantiating a decoder implementation configured to decode the signal into a decoded signal and communicative according to a decoder implementation protocol; conforming the decoder implementation protocol to a transmission protocol; sending the signal according to the transmission protocol to the decoder implementation; and decoding the signal into the decoded signal using the decoder implementation.
-3-The transmission protocol can be a signal processing unit protocol according to which a signal processing unit is communicative. The signal processing unit can be for sending the signal to be translated from the signal processing unit protocol to the decoder implementation protocol.
The method can also include asynchronously sending the decoded signal to the signal processing unit via a listener module.
The signal processing unit protocol may include method calls to an application programming interface.
Instantiating the decoder implementation can include accessing a decoder definition list file containing a listing of decoder definition files corresponding to first and second decoder implementations, which can be configured to decode differently encoded signals, and instantiating the decoder implementation corresponding to the encoding of the signal.
According to another aspect, there is provided a computer readable medium having encoded thereon any of the above methods for execution by a processor.
According to another aspect, there is provided an apparatus for decoding a signal sent from a measurement-while-drilling tool. The apparatus includes a signal processing unit communicatively coupled to the measurement-while-drilling tool and comprising a downstream interface configured to communicate according to a signal processing unit protocol. The downstream interface is for sending the signal for decoding and for receiving a decoded signal.
The apparatus also includes a plurality of decoder implementations each configured to decode the signal into the decoded signal. Each of the decoder implementations comprises an upstream interface conformed to communicate according to the signal processing unit protocol.
BRIEF DESCRIPTION OF THE DRAWINGS
In the accompanying drawings, which illustrate one or more exemplary embodiments:
Figure 1 is a schematic view of a MWD tool being used to acquire a signal that is transmitted to an apparatus for decoding the signal, according to a first embodiment;
The method can also include asynchronously sending the decoded signal to the signal processing unit via a listener module.
The signal processing unit protocol may include method calls to an application programming interface.
Instantiating the decoder implementation can include accessing a decoder definition list file containing a listing of decoder definition files corresponding to first and second decoder implementations, which can be configured to decode differently encoded signals, and instantiating the decoder implementation corresponding to the encoding of the signal.
According to another aspect, there is provided a computer readable medium having encoded thereon any of the above methods for execution by a processor.
According to another aspect, there is provided an apparatus for decoding a signal sent from a measurement-while-drilling tool. The apparatus includes a signal processing unit communicatively coupled to the measurement-while-drilling tool and comprising a downstream interface configured to communicate according to a signal processing unit protocol. The downstream interface is for sending the signal for decoding and for receiving a decoded signal.
The apparatus also includes a plurality of decoder implementations each configured to decode the signal into the decoded signal. Each of the decoder implementations comprises an upstream interface conformed to communicate according to the signal processing unit protocol.
BRIEF DESCRIPTION OF THE DRAWINGS
In the accompanying drawings, which illustrate one or more exemplary embodiments:
Figure 1 is a schematic view of a MWD tool being used to acquire a signal that is transmitted to an apparatus for decoding the signal, according to a first embodiment;
-4-Figure 2 is a block diagram of the apparatus for decoding the signal sent from the MWD tool, according to the first embodiment;
Figure 3 is a block diagram illustrating modules that facilitate communication between a signal processing unit and a decoder implementation that form part of the apparatus for decoding the signal, according to the first embodiment; and Figure 4 is a flowchart describing how the signal sent from the MWD tool is decoded, according to a second embodiment.
DETAILED DESCRIPTION OF EXEMPLARY EMBODIMENTS
A MWD tool is commonly used to acquire data that is relevant in directional drilling. Referring now to Figure 1, there is depicted a drilling rig 34 that is being used in directional drilling.
Extending below the drilling rig 34 is a drill string 38 having a drill bit 42 at one end that is used to drill a borehole 52. The drill string 38 includes bent sections such that the borehole 52 that is drilled is non-vertical. Located near the drill bit 42 is the MWD tool 40. The MWD tool 40 is used to measure a variety of parameters that are relevant in directional drilling, such as drill string inclination, drill string azimuth, toolface, gamma ray intensity, the resistivity of the surrounding rock, and various other pieces of diagnostic information. The MWD
tool 40 then transmits the measured parameters back to the surface.
In Figure 1, the MWD tool 40 uses mud pulses to transmit the measured parameters to the surface. On the surface is a pump 36 that pumps drilling fluid ("mud") down through the interior of the drill string 38. At the drill bit 42, the mud exits the drill string and returns to the surface through the annular cavity between the drill string 38 and the interior surface of the borehole 52.
The flow of the mud from the pump 36, through the drill string 38 and back to the surface is indicated by the arrows that extend along the mud flow path. The flow of the mud through the MWD tool 40 is intermittently restricted by a mud pulser within the MWD tool 40 that creates pressure pulses in the mud flow input into the drill string 38 from the pump 36 ("input mud flow"). Communicating the signal using pressure pulses in the input mud flow is referred to as "mud pulse telemetry". While the present embodiment is utilized in conjunction with mud pulse
Figure 3 is a block diagram illustrating modules that facilitate communication between a signal processing unit and a decoder implementation that form part of the apparatus for decoding the signal, according to the first embodiment; and Figure 4 is a flowchart describing how the signal sent from the MWD tool is decoded, according to a second embodiment.
DETAILED DESCRIPTION OF EXEMPLARY EMBODIMENTS
A MWD tool is commonly used to acquire data that is relevant in directional drilling. Referring now to Figure 1, there is depicted a drilling rig 34 that is being used in directional drilling.
Extending below the drilling rig 34 is a drill string 38 having a drill bit 42 at one end that is used to drill a borehole 52. The drill string 38 includes bent sections such that the borehole 52 that is drilled is non-vertical. Located near the drill bit 42 is the MWD tool 40. The MWD tool 40 is used to measure a variety of parameters that are relevant in directional drilling, such as drill string inclination, drill string azimuth, toolface, gamma ray intensity, the resistivity of the surrounding rock, and various other pieces of diagnostic information. The MWD
tool 40 then transmits the measured parameters back to the surface.
In Figure 1, the MWD tool 40 uses mud pulses to transmit the measured parameters to the surface. On the surface is a pump 36 that pumps drilling fluid ("mud") down through the interior of the drill string 38. At the drill bit 42, the mud exits the drill string and returns to the surface through the annular cavity between the drill string 38 and the interior surface of the borehole 52.
The flow of the mud from the pump 36, through the drill string 38 and back to the surface is indicated by the arrows that extend along the mud flow path. The flow of the mud through the MWD tool 40 is intermittently restricted by a mud pulser within the MWD tool 40 that creates pressure pulses in the mud flow input into the drill string 38 from the pump 36 ("input mud flow"). Communicating the signal using pressure pulses in the input mud flow is referred to as "mud pulse telemetry". While the present embodiment is utilized in conjunction with mud pulse
-5-telemetry, in alternative embodiments other suitable forms of telemetry can be used. For example, electromagnetic telemetry and wired pipe can be used to communicate the signal.
The pressure pulses constitute a signal that represents the measured parameters that are measured by the MWD tool 40 and are encoded according to a cipher that is proprietary to the manufacturer of the MWD tool 40. The pressure pulses are transmitted up to the surface through the mud and are measured by a pressure sensor 44 that senses pressure changes in the input mud flow. The output of the pressure sensor 44 is a 4 mA to 20 mA electrical analog signal that is transmitted to and digitized by an analog-to-digital converter ("ADC") 46. The digitizes the analog signal at a rate of 50 Hz. The pressure sensor 44 and the ADC 46 form part of a system that is used to automatically record measured parameters sent by the MWD tool 40;
an example of such a system is the PasonTM Electronic Drilling Recorder. The digital signal that the ADC 46 outputs is then sent to a doghouse computer 48 over a RS422 connection. The doghouse computer 48 transmits the digital signal over a network 50 to an apparatus 10 for decoding the signal. The network 50 may be, for example, a packet-switched wide or local area network communicative using TCP/IP.
Referring now to Figure 2, there is depicted a block diagram of the apparatus 10 that is used to decode the signal. The signal enters the apparatus 10 through a communications port 54, which is any port suitable to receive the signal sent from the doghouse computer 48.
When the signal is sent from the doghouse computer 48 using TCP/IP, the communications port 54 may be an Ethernet port. Communicatively coupled to the communications port 54 is a signal processing unit 14 that receives the signal. Once the signal is decoded, the signal processing unit 14 is configured to use the measured parameters that are contained in the signal.
For example, the signal processing unit 14 may include a graphical user interface that displays measured parameters such as drill string inclination, drill string azimuth, and toolface to a directional driller such that the directional driller can ensure drilling proceeds according to a drilling plan.
The signal processing unit 14 includes a downstream interface 16 that is used to send the signal to a decoding unit 18 for decoding. The downstream interface 16 sends the signal according to a signal processing unit protocol, which includes method calls to an Application Programming Interface ("API"), as discussed in greater detail below.
The pressure pulses constitute a signal that represents the measured parameters that are measured by the MWD tool 40 and are encoded according to a cipher that is proprietary to the manufacturer of the MWD tool 40. The pressure pulses are transmitted up to the surface through the mud and are measured by a pressure sensor 44 that senses pressure changes in the input mud flow. The output of the pressure sensor 44 is a 4 mA to 20 mA electrical analog signal that is transmitted to and digitized by an analog-to-digital converter ("ADC") 46. The digitizes the analog signal at a rate of 50 Hz. The pressure sensor 44 and the ADC 46 form part of a system that is used to automatically record measured parameters sent by the MWD tool 40;
an example of such a system is the PasonTM Electronic Drilling Recorder. The digital signal that the ADC 46 outputs is then sent to a doghouse computer 48 over a RS422 connection. The doghouse computer 48 transmits the digital signal over a network 50 to an apparatus 10 for decoding the signal. The network 50 may be, for example, a packet-switched wide or local area network communicative using TCP/IP.
Referring now to Figure 2, there is depicted a block diagram of the apparatus 10 that is used to decode the signal. The signal enters the apparatus 10 through a communications port 54, which is any port suitable to receive the signal sent from the doghouse computer 48.
When the signal is sent from the doghouse computer 48 using TCP/IP, the communications port 54 may be an Ethernet port. Communicatively coupled to the communications port 54 is a signal processing unit 14 that receives the signal. Once the signal is decoded, the signal processing unit 14 is configured to use the measured parameters that are contained in the signal.
For example, the signal processing unit 14 may include a graphical user interface that displays measured parameters such as drill string inclination, drill string azimuth, and toolface to a directional driller such that the directional driller can ensure drilling proceeds according to a drilling plan.
The signal processing unit 14 includes a downstream interface 16 that is used to send the signal to a decoding unit 18 for decoding. The downstream interface 16 sends the signal according to a signal processing unit protocol, which includes method calls to an Application Programming Interface ("API"), as discussed in greater detail below.
-6-Each of the decoding units 18 includes a decoder implementation 20 that is used to decode the signal into a decoded signal. The decoder implementation 20 is typically supplied by the manufacturer of the MWD tool 40 and is consequently able to decode the signal sent by the MWD tool 40 that is encoded using the proprietary cipher. One example of the decoder implementation 20 is the GETM Tensor Tolteq decoder implementation available from Tolteq.
Each of the decoder implementations 20 has an upstream interface 22 that is used to receive the signal for decoding and to send the decoded signal. Just as each of the different decoder implementations 20 is able to decode a differently encoded signal, the upstream interfaces 22 of each of the decoder implementations 20 each communicate according to its own decoder implementation protocol. The decoder implementation protocol is not the same as the signal processing unit protocol. Consequently, the decoder implementations 20 and the signal processing unit 14 are not able to directly communicate.
In order to enable communication between the signal processing unit 14 and the decoder implementations 20, the upstream interface 22 of each of the decoder implementations 20 communicates with the downstream interface 16 of the signal processing unit 14 through a translation layer 24. Each of the decoding units 18 has one translation layer 24 configured specifically to facilitate communication with the decoder implementation 20 of that decoding unit 18. For each of the decoding units 18, the translation layer 24 conforms the decoder implementation protocol used by the upstream interface 22 of the decoder implementation 20 to the signal processing unit protocol used by the downstream interface 16 of the signal processing unit 14. In the present embodiment, when the signal processing unit protocol is an API, the translation layer 24 interfaces with the decoder implementation 20 according to the decoder implementation protocol and interfaces with the signal processing unit 14 according to the API.
The API includes different methods that the signal processing unit 14 calls in order to decode the signal, as follows (the "*" indicates a wildcard):
= add *Listener: the add*Listener family of methods is used to add listener modules 32 (illustrated in Figure 3) to the decoder implementation 20. Each of the listener modules 32 accepts as an input one of the decoded measured parameters from the
Each of the decoder implementations 20 has an upstream interface 22 that is used to receive the signal for decoding and to send the decoded signal. Just as each of the different decoder implementations 20 is able to decode a differently encoded signal, the upstream interfaces 22 of each of the decoder implementations 20 each communicate according to its own decoder implementation protocol. The decoder implementation protocol is not the same as the signal processing unit protocol. Consequently, the decoder implementations 20 and the signal processing unit 14 are not able to directly communicate.
In order to enable communication between the signal processing unit 14 and the decoder implementations 20, the upstream interface 22 of each of the decoder implementations 20 communicates with the downstream interface 16 of the signal processing unit 14 through a translation layer 24. Each of the decoding units 18 has one translation layer 24 configured specifically to facilitate communication with the decoder implementation 20 of that decoding unit 18. For each of the decoding units 18, the translation layer 24 conforms the decoder implementation protocol used by the upstream interface 22 of the decoder implementation 20 to the signal processing unit protocol used by the downstream interface 16 of the signal processing unit 14. In the present embodiment, when the signal processing unit protocol is an API, the translation layer 24 interfaces with the decoder implementation 20 according to the decoder implementation protocol and interfaces with the signal processing unit 14 according to the API.
The API includes different methods that the signal processing unit 14 calls in order to decode the signal, as follows (the "*" indicates a wildcard):
= add *Listener: the add*Listener family of methods is used to add listener modules 32 (illustrated in Figure 3) to the decoder implementation 20. Each of the listener modules 32 accepts as an input one of the decoded measured parameters from the
-7-decoder implementation 20 and asynchronously outputs the decoded measured parameter to the signal processing unit 14.
= remove *Listener: the remove*Listener family of methods is used to remove the listener modules 32 from the decoder implementation 20. When one of the listener modules 32 is removed, the signal processing unit 14 no longer receives the decoded measured parameter associated with the removed listener module 32.
= get*: the get* family of methods is used to request that the decoder implementation 20 send a specific one of the decoded measured parameters to the signal processing unit 14. Notably, when the get* family of methods is called, the decoded measured parameters are not sent asynchronously via one of the listener modules 32. Instead, the get* family of methods are each called synchronously, which means that the signal processing unit 14 waits until it receives a response from any called method prior to proceeding to its next task.
= set*Consumer: the set*Consumer family of methods is used to obtain information used to generate different graphical views of the pressure pulses that the MWD
tool 40 transmits.
= consumeSample: the consumeSample method is called each time the signal processing unit 14 sends a sample of the signal to the decoding unit 18 for decoding., Analogous to how each of the listener modules 32 is used to transmit decoded measured parameters from the decoder implementation 20 to the signal processing unit 14, the consumeSample method is used to transmit a sample of the signal from the MWD tool 40 to the decoder implementation 20 for decoding. As mentioned above, in the present embodiment the ADC 46 samples the signal from the MWD tool 40 at a rate of 50 Hz.
= sampleRateChanged: the sampleRateChanged method is called to instruct the decoder implementation 20 as to the sampling rate at which the ADC 46 digitizes the signal from the MWD tool 40. The decoder implementation 20 uses the sampling rate to determine how calls to the consumeSample method relate to real
= remove *Listener: the remove*Listener family of methods is used to remove the listener modules 32 from the decoder implementation 20. When one of the listener modules 32 is removed, the signal processing unit 14 no longer receives the decoded measured parameter associated with the removed listener module 32.
= get*: the get* family of methods is used to request that the decoder implementation 20 send a specific one of the decoded measured parameters to the signal processing unit 14. Notably, when the get* family of methods is called, the decoded measured parameters are not sent asynchronously via one of the listener modules 32. Instead, the get* family of methods are each called synchronously, which means that the signal processing unit 14 waits until it receives a response from any called method prior to proceeding to its next task.
= set*Consumer: the set*Consumer family of methods is used to obtain information used to generate different graphical views of the pressure pulses that the MWD
tool 40 transmits.
= consumeSample: the consumeSample method is called each time the signal processing unit 14 sends a sample of the signal to the decoding unit 18 for decoding., Analogous to how each of the listener modules 32 is used to transmit decoded measured parameters from the decoder implementation 20 to the signal processing unit 14, the consumeSample method is used to transmit a sample of the signal from the MWD tool 40 to the decoder implementation 20 for decoding. As mentioned above, in the present embodiment the ADC 46 samples the signal from the MWD tool 40 at a rate of 50 Hz.
= sampleRateChanged: the sampleRateChanged method is called to instruct the decoder implementation 20 as to the sampling rate at which the ADC 46 digitizes the signal from the MWD tool 40. The decoder implementation 20 uses the sampling rate to determine how calls to the consumeSample method relate to real
-8-time. For example, if consumeSample is called at a frequency of 100 Hz but the sampling rate of the signal is known to be 50 Hz, the decoder implementation knows that samples of the signal are being sent to it at twice the real time rate, and can decode the signal accordingly. Notably, as decoding is a processor intensive task but not a time critical task, the signal does not have to be decoded in real time; consequently, the rate at which the signal is sent to the decoder implementation 20 does not have to equal the rate at which the ADC 46 samples the signal.
= start and stop: the start method is sent to the decoder implementation 20 to commence signal decoding, while the stop method is sent to the decoder implementation 20 to cease signal decoding. When the start method is called, the decoder implementation 20 sends decoded measured parameters to the signal processing unit 14 via the listener modules 32. When the stop method is called, the decoder implementation ceases sending decoded measured parameters to the signal processing unit 14.
= sourceReset: the sourceReset method is called to reset the decoder implementation 20 as required.
= setToolMode: the setToolMode method is called to reconfigure the decoder implementation 20 according to a tool mode specified when setToolMode is called. As is known to skilled persons, certain MWD tools 40 are operable in different modes, as specified by the manufacturers of the MWD tools 40.
The methods that are included in the add*Listener, remove*Listener, get*, and set*Consumer family of methods are as follows:
Methods in the add *Listener family:
= addMWDDataListener: the addMWDDataListener method adds one of the listener modules 32 used to receive decoded measured parameters in the form of MWD words from the decoder implementation 20 and to send the MWD words to
= start and stop: the start method is sent to the decoder implementation 20 to commence signal decoding, while the stop method is sent to the decoder implementation 20 to cease signal decoding. When the start method is called, the decoder implementation 20 sends decoded measured parameters to the signal processing unit 14 via the listener modules 32. When the stop method is called, the decoder implementation ceases sending decoded measured parameters to the signal processing unit 14.
= sourceReset: the sourceReset method is called to reset the decoder implementation 20 as required.
= setToolMode: the setToolMode method is called to reconfigure the decoder implementation 20 according to a tool mode specified when setToolMode is called. As is known to skilled persons, certain MWD tools 40 are operable in different modes, as specified by the manufacturers of the MWD tools 40.
The methods that are included in the add*Listener, remove*Listener, get*, and set*Consumer family of methods are as follows:
Methods in the add *Listener family:
= addMWDDataListener: the addMWDDataListener method adds one of the listener modules 32 used to receive decoded measured parameters in the form of MWD words from the decoder implementation 20 and to send the MWD words to
-9-the signal processing unit 14. The listener modules 32 added using the addMWDDataListener method are each hereinafter referred to as a "MWD data listener". Each MWD word has the following attributes:
= Type of MWD word that the MWD data listener is configured to convey from the decoder implementation 20 to the signal processing unit 14:
available word types include automatic toolface; azimuth; battery voltage of the MWD tool 40; a flag indicating whether the battery of the MWD
tool 40 is low; a flag indicating whether the second battery in the MWD
tool 40 is on; a word identifying the configuration of the MWD tool 40;
dip angle; a flag indicating that the dip angle is outside accepted parameters; a conventional gamma radiation reading; a warning that the gravitational field is outside accepted parameters; gravity toolface;
inclination; a warning that the magnetic field is outside accepted parameters; magnetic toolface; a flag indicating that a word is to be sent in several parts; a survey sequence number; a flag warning that the measured temperature is outside accepted parameters; temperature; toolface sequence number; total gravity; total magnetic field; and an unknown word. Other types of words are possible in alternative embodiments and may depend on the type of MWD tool 40 used.
= Value: value of the MWD word as a floating point number.
= Checksum: checksum of the MWD word.
= Quality: quality of the MWD word as a percentage from 0 to 100.
= Time: time at which the MWD word was decoded.
= Type of error, if any, encountered when decoding the word: the attribute may indicate no error; an unknown error; that the duration of one of the pressure pulses sent by the MWD tool 40 was outside the range of acceptable pulse durations to properly map the pressure pulse to a value;
= Type of MWD word that the MWD data listener is configured to convey from the decoder implementation 20 to the signal processing unit 14:
available word types include automatic toolface; azimuth; battery voltage of the MWD tool 40; a flag indicating whether the battery of the MWD
tool 40 is low; a flag indicating whether the second battery in the MWD
tool 40 is on; a word identifying the configuration of the MWD tool 40;
dip angle; a flag indicating that the dip angle is outside accepted parameters; a conventional gamma radiation reading; a warning that the gravitational field is outside accepted parameters; gravity toolface;
inclination; a warning that the magnetic field is outside accepted parameters; magnetic toolface; a flag indicating that a word is to be sent in several parts; a survey sequence number; a flag warning that the measured temperature is outside accepted parameters; temperature; toolface sequence number; total gravity; total magnetic field; and an unknown word. Other types of words are possible in alternative embodiments and may depend on the type of MWD tool 40 used.
= Value: value of the MWD word as a floating point number.
= Checksum: checksum of the MWD word.
= Quality: quality of the MWD word as a percentage from 0 to 100.
= Time: time at which the MWD word was decoded.
= Type of error, if any, encountered when decoding the word: the attribute may indicate no error; an unknown error; that the duration of one of the pressure pulses sent by the MWD tool 40 was outside the range of acceptable pulse durations to properly map the pressure pulse to a value;
-10-that no MWD pulses were detected in the signal; that a bad parity bit was detected; or that a bad error correction code was detected.
= addPropertyChangeListener: the addPropertyChangeListener method adds one of the listener modules 32 used to monitor property states and to convey changes in property states to the signal processing unit 14. The listener module 32 added using the addPropertyChangeListener method is hereinafter referred to as a "property change listener". The property change listener sends the following information to the signal processing unit 14:
= The percentage of expected words from the MWD tool 40 that have been successfully decoded.
= The current quality rating of the signal as a percentage from 0 to 100.
= The current status of the decoder implementation 20. Expressed as decoding being complete; decoding of message headers occurring;
decoding survey information; decoding toolface information;
synchronization not possible (so decoding is not occurring); the pump 36 is off so no decoding is being performed; synchronization is delayed;
waiting for synchronization; and unknown.
= The height of the pressure pulses detected by the decoder implementation 20.
= The mode in which the MWD tool 40 is currently configured to operate.
= addPumpStateListener: the addPumpStateListener method adds one of the listener modules 32 used to monitor pump state and to convey changes in pump state to the signal processing unit 14. The listener module 32 added using the addPumpStateListener method is hereinafter referred to as a "pump state listener".
The pump state listener tells the signal processing unit 14 that the pumps are either on, off, or in an unknown state.
= addPropertyChangeListener: the addPropertyChangeListener method adds one of the listener modules 32 used to monitor property states and to convey changes in property states to the signal processing unit 14. The listener module 32 added using the addPropertyChangeListener method is hereinafter referred to as a "property change listener". The property change listener sends the following information to the signal processing unit 14:
= The percentage of expected words from the MWD tool 40 that have been successfully decoded.
= The current quality rating of the signal as a percentage from 0 to 100.
= The current status of the decoder implementation 20. Expressed as decoding being complete; decoding of message headers occurring;
decoding survey information; decoding toolface information;
synchronization not possible (so decoding is not occurring); the pump 36 is off so no decoding is being performed; synchronization is delayed;
waiting for synchronization; and unknown.
= The height of the pressure pulses detected by the decoder implementation 20.
= The mode in which the MWD tool 40 is currently configured to operate.
= addPumpStateListener: the addPumpStateListener method adds one of the listener modules 32 used to monitor pump state and to convey changes in pump state to the signal processing unit 14. The listener module 32 added using the addPumpStateListener method is hereinafter referred to as a "pump state listener".
The pump state listener tells the signal processing unit 14 that the pumps are either on, off, or in an unknown state.
-11-= addToolModeChangeListener: the addToolModeChangeListener adds one of the listener modules 32 used to monitor changes in tool mode and to convey changes in tool mode to the signal processing unit 14. The listener module 32 added using the addToolModeChangeListener method is hereinafter referred to as a "tool mode listener". The tool mode listener tells the signal processing unit 14 when the tool mode of the MWD tool 40 has been changed, and also communicates the new tool mode.
Methods in the remove *Listener family:
= removeMWDDataListener, removePropertyChangeListener, removePumpStateListener, removeToolModeChangeListener. Each of these methods when called by the signal processing unit 14 terminate the various listener modules that are created with the add*Listener family of methods described above. For example, if the signal processing unit 14 were obtaining decoded MWD words via the MWD data listener and then called removeMWDDataListener, the signal processing unit 14 would cease to receive the decoded MWD words.
Methods in the get* family:
= getDecodeStatus: sends the current status of the decoder implementation 20 from the decoding unit 18 to the signal processing unit 14.
= getPulseHeight: sends the current pulse height of the decoder implementation from the decoding unit 18 to the signal processing unit 14.
= getPumpState: sends the current pump state from the decoding unit 18 to the signal processing unit 14.
= getQuality: sends the current quality rating of the signal from the decoding unit 18 to the signal processing unit 14.
Methods in the remove *Listener family:
= removeMWDDataListener, removePropertyChangeListener, removePumpStateListener, removeToolModeChangeListener. Each of these methods when called by the signal processing unit 14 terminate the various listener modules that are created with the add*Listener family of methods described above. For example, if the signal processing unit 14 were obtaining decoded MWD words via the MWD data listener and then called removeMWDDataListener, the signal processing unit 14 would cease to receive the decoded MWD words.
Methods in the get* family:
= getDecodeStatus: sends the current status of the decoder implementation 20 from the decoding unit 18 to the signal processing unit 14.
= getPulseHeight: sends the current pulse height of the decoder implementation from the decoding unit 18 to the signal processing unit 14.
= getPumpState: sends the current pump state from the decoding unit 18 to the signal processing unit 14.
= getQuality: sends the current quality rating of the signal from the decoding unit 18 to the signal processing unit 14.
-12-= getSuccessPercent: sends the percentage of expected words from the MWD tool 40 that have been successfully decoded from the decoding unit 18 to the signal processing unit 14.
= getToolMode: sends the current tool mode of the MWD tool 40 from the decoding unit 18 to the signal processing unit 14.
Methods in the set*Consumer family:
= setPulseViewDownsampledConsumer: Sends to the signal processing unit 14 data that can be used to display pulses sent from the MWD tool 40 that are detected by the decoder implementation 20. Pulses represent the signal sent from the MWD
tool 40 following all filtering and other signal conditioning steps.
= setRawFilteredDownsampledConsumer: Sends to the signal processing unit 14 data that can be used to display data that has only partially been conditioned. This data is noisier than the pulses obtained using the setPulseViewDownsampledConsumer method.
Instantiating and Initializing One of the Decoding Units 18 Also depicted in Figure 2 is a decoder configuration manager 26 that is used to instantiate the decoding units 18. The decoder configuration manager 26 is communicatively coupled to the signal processing unit 14 and has access to a file system 29 of the apparatus 10. Stored within the file system 29 are a decoder definition list file 27 and various decoder definition files 28 that are referred to within the decoder definition list file 27. An exemplary decoder definition list file 27 in XML format follows:
<?xml version=" 1.0" encoding="UTF-8"?>
<tools>
<tool xml="conf/tool_modules/GETensorTolteq.xml"/>
<tool xml="conf/tool_modules/PasonTensorDecoder.xml"/>
</tools>
= getToolMode: sends the current tool mode of the MWD tool 40 from the decoding unit 18 to the signal processing unit 14.
Methods in the set*Consumer family:
= setPulseViewDownsampledConsumer: Sends to the signal processing unit 14 data that can be used to display pulses sent from the MWD tool 40 that are detected by the decoder implementation 20. Pulses represent the signal sent from the MWD
tool 40 following all filtering and other signal conditioning steps.
= setRawFilteredDownsampledConsumer: Sends to the signal processing unit 14 data that can be used to display data that has only partially been conditioned. This data is noisier than the pulses obtained using the setPulseViewDownsampledConsumer method.
Instantiating and Initializing One of the Decoding Units 18 Also depicted in Figure 2 is a decoder configuration manager 26 that is used to instantiate the decoding units 18. The decoder configuration manager 26 is communicatively coupled to the signal processing unit 14 and has access to a file system 29 of the apparatus 10. Stored within the file system 29 are a decoder definition list file 27 and various decoder definition files 28 that are referred to within the decoder definition list file 27. An exemplary decoder definition list file 27 in XML format follows:
<?xml version=" 1.0" encoding="UTF-8"?>
<tools>
<tool xml="conf/tool_modules/GETensorTolteq.xml"/>
<tool xml="conf/tool_modules/PasonTensorDecoder.xml"/>
</tools>
-13-The decoder definition list file 27 lists the decoder definition files 28 for the available decoder implementations 20. In this embodiment, two decoder implementations 20 are available: one GETM Tensor Tolteq decoder implementation, and one PasonTM Tensor decoder implementation.
An exemplary decoder definition file 28 written in XML for the GETM Tensor Tolteq decoder implementation 20 follows:
GETensorTolteq.xml:
<?xml version=" 1.0" encoding="UTF-8"?>
<tool>
<id>GETensorTolteq.mpl</id>
<description>GE Tensor compatible (Tolteq decoder)</description>
<factory>com.pason.mwd.decoder.toltegdecoder.TolteqMWDDecoderFactory</factory>
<defaultConfigurationFile>default.mwd</defaultConfigurationFile>
<configurationFileType>MWD</configurationFileType>
<parameters>
<parameter name="prefsPath">conf/tolteq/</parameter>
</parameters>
</tool>
An exemplary decoder definition file 28 written in XML for the PasonTM Tensor decoder implementation 20 follows:
PasonTensorDecoder.xml:
<?xml version=" 1.0" encoding="UTF-8"?>
<tool>
<id>PasonTensorDecoder</id>
<description>GE Tensor compatible</description>
<factory>com.pason.mwd.decoder.tensor.TensorDecoderFactory</factory>
<defaultConfigurationFile>default.mwd</defaultConfigurationFile>
<configurationFileType>MWD</configurationFileType>
<parameters>
</parameters>
</tool>
Regardless of the specific decoder implementation 20 used, the decoder definitions files 28 utilize a layout as follows:
<?xml version--" 1.0" encoding="UTF-8"?>
<tool>
<id>Decoderld</id>
<description>Decoder description</description>
An exemplary decoder definition file 28 written in XML for the GETM Tensor Tolteq decoder implementation 20 follows:
GETensorTolteq.xml:
<?xml version=" 1.0" encoding="UTF-8"?>
<tool>
<id>GETensorTolteq.mpl</id>
<description>GE Tensor compatible (Tolteq decoder)</description>
<factory>com.pason.mwd.decoder.toltegdecoder.TolteqMWDDecoderFactory</factory>
<defaultConfigurationFile>default.mwd</defaultConfigurationFile>
<configurationFileType>MWD</configurationFileType>
<parameters>
<parameter name="prefsPath">conf/tolteq/</parameter>
</parameters>
</tool>
An exemplary decoder definition file 28 written in XML for the PasonTM Tensor decoder implementation 20 follows:
PasonTensorDecoder.xml:
<?xml version=" 1.0" encoding="UTF-8"?>
<tool>
<id>PasonTensorDecoder</id>
<description>GE Tensor compatible</description>
<factory>com.pason.mwd.decoder.tensor.TensorDecoderFactory</factory>
<defaultConfigurationFile>default.mwd</defaultConfigurationFile>
<configurationFileType>MWD</configurationFileType>
<parameters>
</parameters>
</tool>
Regardless of the specific decoder implementation 20 used, the decoder definitions files 28 utilize a layout as follows:
<?xml version--" 1.0" encoding="UTF-8"?>
<tool>
<id>Decoderld</id>
<description>Decoder description</description>
-14-<factory>Decoder Implementation Factory</factory>
<defaultConfigurationFile> configuration file</defaultConfigurationFile>
<configurationFileType>File type</configurationFileType>
<parameters>
<parameter name="name">value</parameter>
</parameters>
</tool>
The "id" field is an identifier for the decoder implementation 20 that is used internally by the signal processing unit 14. The "description" field is a human readable description of the decoder implementation 20; the description field is presented to the user when the user is selecting which of the decoder implementations 20 to use. When the Java programming language is used to instantiate the decoding unit 18, the "factory" field is the name of a fully qualified Java class of the factory used to instantiate the decoding unit 18. The "defaultConfigurationFile" field is the name and location of the default configuration file to be used by the decoder implementation 20;
the configuration file is typically supplied by the manufacturer of the decoder implementation 20. The user may modify the configuration file if so desired. The "configurationFileType" field is the type of configuration file that is used to program the decoder implementation 20. The "parameters" field contains a list of parameters, if any, used by the decoder implementation 20.
In order to instantiate one of the decoder implementations 20, the decoder configuration manager 26 first accesses the decoder definition list file 27 and, in turn, each of the decoder definition files 28 to obtain the "description" field from each of the decoder definition files 28. The decoder configuration manager 26 sends the description fields to the signal processing unit 14, which displays them to the user in a drop-down list. The user is able to select which of the decoder implementations 20 is to be instantiated. This information is returned to the decoder configuration manager 26 via the signal processing unit 14. In the present embodiment, the GETM Tensor Tolteq decoder implementation 20 is selected, which forms part of a first decoding unit 18a in Figure 2.
The decoder configuration manager 26 then instantiates the first decoding unit 18a using the TensorDecoderFactory Java factory, as identified in the "factory" field in the decoder definition file 28 for the GEmI Tensor Tolteq decoder implementation 20. The decoder configuration manager 26 calls two methods included in the TensorDecoderFactory interface:
<defaultConfigurationFile> configuration file</defaultConfigurationFile>
<configurationFileType>File type</configurationFileType>
<parameters>
<parameter name="name">value</parameter>
</parameters>
</tool>
The "id" field is an identifier for the decoder implementation 20 that is used internally by the signal processing unit 14. The "description" field is a human readable description of the decoder implementation 20; the description field is presented to the user when the user is selecting which of the decoder implementations 20 to use. When the Java programming language is used to instantiate the decoding unit 18, the "factory" field is the name of a fully qualified Java class of the factory used to instantiate the decoding unit 18. The "defaultConfigurationFile" field is the name and location of the default configuration file to be used by the decoder implementation 20;
the configuration file is typically supplied by the manufacturer of the decoder implementation 20. The user may modify the configuration file if so desired. The "configurationFileType" field is the type of configuration file that is used to program the decoder implementation 20. The "parameters" field contains a list of parameters, if any, used by the decoder implementation 20.
In order to instantiate one of the decoder implementations 20, the decoder configuration manager 26 first accesses the decoder definition list file 27 and, in turn, each of the decoder definition files 28 to obtain the "description" field from each of the decoder definition files 28. The decoder configuration manager 26 sends the description fields to the signal processing unit 14, which displays them to the user in a drop-down list. The user is able to select which of the decoder implementations 20 is to be instantiated. This information is returned to the decoder configuration manager 26 via the signal processing unit 14. In the present embodiment, the GETM Tensor Tolteq decoder implementation 20 is selected, which forms part of a first decoding unit 18a in Figure 2.
The decoder configuration manager 26 then instantiates the first decoding unit 18a using the TensorDecoderFactory Java factory, as identified in the "factory" field in the decoder definition file 28 for the GEmI Tensor Tolteq decoder implementation 20. The decoder configuration manager 26 calls two methods included in the TensorDecoderFactory interface:
-15-setConfigurationlnputStreamFactory, which sets the input stream factory to be used for communicating configuration information specific to the decoder implementation 20; and setParams, which sets parameters defined for the TensorDecoderFactory that are specific to the GETM Tensor Tolteq decoder implementation 20, as specified in the decoder definition file 28 for the GETM Tensor Tolteq decoder implementation 20. The decoder configuration manager 26 then calls the getDecoder method that also forms part of the interface of the TensorDecoderFactory; this creates the translation layer 24 that conforms the upstream interface 22 of the decoder implementation 20 to the downstream interface 16 of the signal processing unit 14. In other words, following execution of the getDecoder method, the translation layer 24 is created and the signal processing unit 14 can communicate with the decoder implementation 20 by calling the methods that are included in the API. Following the calling of getDecoder, the first decoding unit 18a is considered instantiated. Referring to Figure 4, which depicts a method for decoding a signal sent from the MWD tool 40, following instantiation of the first decoding unit 18a the processes described in blocks 400 and 402 of Figure 4 are complete. That is, instantiating the first decoding unit 18a involves instantiating the GETM
Tensor Tolteq decoder implementation 20, which is configured to decode the signal into a decoded signal and which is communicative according to a protocol that differs from the API that the signal processing unit 14 is configured to use (block 400). Instantiating the first decoding unit 18a also results in the translation layer 24, which conforms the native protocol of the GETM Tensor Tolteq decoder implementation 20 to the API used by the signal processing unit 14 (block 402). Notably, block 402 in Figure 4 refers to a "transmission protocol"; while the present embodiment contemplates the "transmission protocol" being the same as the signal processing unit protocol, in alternative embodiments the first decoding unit 18a may communicate with a module, other than the signal processing unit 14, that communicates according to the transmission protocol.
Following instantiation of the first decoding unit 18a, the GETM Tensor Tolteq decoder implementation 20 is initialized. The signal processing unit 14 calls the sampleRateChanged method in the API to instruct the decoder implementation 20 that the sampling rate is 50 Hz; if the sampling rate of the ADC 46 changes, the sampleRateChanged method can be called again.
The signal processing unit 14 then calls each method in the add*Listener family of methods to instantiate the listener modules 32: the MWD data listener, the property change listener, the pump state listener, and the tool mode change listener. More than one of each of these listener
Tensor Tolteq decoder implementation 20, which is configured to decode the signal into a decoded signal and which is communicative according to a protocol that differs from the API that the signal processing unit 14 is configured to use (block 400). Instantiating the first decoding unit 18a also results in the translation layer 24, which conforms the native protocol of the GETM Tensor Tolteq decoder implementation 20 to the API used by the signal processing unit 14 (block 402). Notably, block 402 in Figure 4 refers to a "transmission protocol"; while the present embodiment contemplates the "transmission protocol" being the same as the signal processing unit protocol, in alternative embodiments the first decoding unit 18a may communicate with a module, other than the signal processing unit 14, that communicates according to the transmission protocol.
Following instantiation of the first decoding unit 18a, the GETM Tensor Tolteq decoder implementation 20 is initialized. The signal processing unit 14 calls the sampleRateChanged method in the API to instruct the decoder implementation 20 that the sampling rate is 50 Hz; if the sampling rate of the ADC 46 changes, the sampleRateChanged method can be called again.
The signal processing unit 14 then calls each method in the add*Listener family of methods to instantiate the listener modules 32: the MWD data listener, the property change listener, the pump state listener, and the tool mode change listener. More than one of each of these listener
-16-modules 32 can be instantiated if so desired. In the present embodiment in which the first decoding unit 18a sends the decoded signal only to the signal processing unit 14, only one of each of the listener modules 32 is instantiated. In alternative embodiments in which the decoder unit 18a sends the decoded signal to a variety of different destinations (e.g.: the signal processing unit 14 and a different device for recording the decoded signal, such as the PasonlM Electronic Data Recorder), another set of the listener modules 32 can be instantiated to asynchronously send the measured parameters to the different device. This is graphically depicted in Figure 3, which illustrates the various listener modules 32 that that facilitate communication between the signal processing unit 14 and the decoder implementation 20. In the present embodiment, each of the listener modules 32 added using the methods in the add*Listener family of methods is instantiated as part of the signal processing unit 14. However, in alternative embodiments, the listener modules 32 can form part of the first decoder unit 18a or be distinct from the first decoder unit 18a and the signal processing unit 14. One of the two methods in the set*Consumer family of methods is also called to obtain a desired graphical view of the signal. The signal processing unit 14 then calls each of the methods in the get* family of methods to obtain the initial state from each of the listener modules 32. The start method is then called, and decoding of the signal can begin.
Decoding the Signal Sent from the MWD Tool 40 Using One of the Decoding Units In order to decode the signal sent from the MWD tool 40 and following instantiation of the first decoding unit 18a, the signal processing unit 14 calls the consumeSample method and sends one sample of the signal to the first decoding unit 18a. Again referring to Figure 4, this completes the process described in block 404. The first decoding unit 18a accepts the sample through the translation layer 24 and decodes it using the decoder implementation 20, as described in the process described in block 406 of Figure 4. Multiple samples may have to be sent from the signal processing unit 14 to the first decoding unit 18a and decoded in order for a usable portion of the decoded signal to be generated. When the decoded signal is generated, the first decoding unit 18a sends it back to the signal processing unit 14 using one of the listener modules 32: if the decoded signal is a MWD word, it is sent via one of the MWD data listeners; if it contains pump state information, it is sent via one of the pump state listeners; if it contains property state information, it is sent via one of the property state listeners; and if it contains tool mode
Decoding the Signal Sent from the MWD Tool 40 Using One of the Decoding Units In order to decode the signal sent from the MWD tool 40 and following instantiation of the first decoding unit 18a, the signal processing unit 14 calls the consumeSample method and sends one sample of the signal to the first decoding unit 18a. Again referring to Figure 4, this completes the process described in block 404. The first decoding unit 18a accepts the sample through the translation layer 24 and decodes it using the decoder implementation 20, as described in the process described in block 406 of Figure 4. Multiple samples may have to be sent from the signal processing unit 14 to the first decoding unit 18a and decoded in order for a usable portion of the decoded signal to be generated. When the decoded signal is generated, the first decoding unit 18a sends it back to the signal processing unit 14 using one of the listener modules 32: if the decoded signal is a MWD word, it is sent via one of the MWD data listeners; if it contains pump state information, it is sent via one of the pump state listeners; if it contains property state information, it is sent via one of the property state listeners; and if it contains tool mode
-17-information, it is sent via one of the tool mode listeners. In this way, the encoded signal sent from the MWD tool 40 is decoded by the decoder implementation 20 and the decoded signal is returned to the signal processing unit 14 for, for example, display to the user.
Changing to a Different One of the Decoding Units 18 The stippled lines in which all of the decoding units 18 in Figure 2 are depicted apart from the first decoding unit 18a indicate that although the signal processing unit 14 of the present embodiment sends the signal from the MWD tool 40 to only one of the decoding units 18 at any given time, multiple of the decoding units 18 can be instantiated and used with the signal processing unit 14.
Instantiating a second decoding unit 18b is done analogously to instantiating the first decoding unit 18a, the process for which is described above. As with instantiating the first decoding unit 18a, the user first selects one of the decoder implementations 20 enumerated in the decoder definition list file 27. The user may, for example, select the PasonTM Tensor decoder implementation 20. As described above in respect of the first decoding unit 18a and blocks 400 and 402 of Figure 4, the second decoding unit 18b is instantiated and conformed to the signal processing unit 14 protocol. The second decoding unit 18b is also initialized as described above.
The signal can then be sent from the signal processing unit 14 to the second decoding unit 18b instead of the first decoding unit 18a for decoding.
Any multiple decoding units 18 that are instantiated can either all be resident in memory simultaneously, or alternatively the apparatus 10 can be configured such that only one of the decoding units 18 is resident in memory at any given time.
Enabling the use of multiple of the decoding units 18 as described above is advantageous for several reasons. First, it allows the apparatus 10 to be used to decode signals sent from several different MWD tools 40 simply by selecting a different one of the decoder implementations 20 in software. No hardware needs to be physically changed or swapped in order to decode signals sent from different MWD tools 40, which facilitates ease of use. Second, as the upstream interfaces 22 of all of the decoder implementations 20 are each conformed to the API used by the downstream interface 16 of the signal processing unit 14, the signal processing unit 14 can treat
Changing to a Different One of the Decoding Units 18 The stippled lines in which all of the decoding units 18 in Figure 2 are depicted apart from the first decoding unit 18a indicate that although the signal processing unit 14 of the present embodiment sends the signal from the MWD tool 40 to only one of the decoding units 18 at any given time, multiple of the decoding units 18 can be instantiated and used with the signal processing unit 14.
Instantiating a second decoding unit 18b is done analogously to instantiating the first decoding unit 18a, the process for which is described above. As with instantiating the first decoding unit 18a, the user first selects one of the decoder implementations 20 enumerated in the decoder definition list file 27. The user may, for example, select the PasonTM Tensor decoder implementation 20. As described above in respect of the first decoding unit 18a and blocks 400 and 402 of Figure 4, the second decoding unit 18b is instantiated and conformed to the signal processing unit 14 protocol. The second decoding unit 18b is also initialized as described above.
The signal can then be sent from the signal processing unit 14 to the second decoding unit 18b instead of the first decoding unit 18a for decoding.
Any multiple decoding units 18 that are instantiated can either all be resident in memory simultaneously, or alternatively the apparatus 10 can be configured such that only one of the decoding units 18 is resident in memory at any given time.
Enabling the use of multiple of the decoding units 18 as described above is advantageous for several reasons. First, it allows the apparatus 10 to be used to decode signals sent from several different MWD tools 40 simply by selecting a different one of the decoder implementations 20 in software. No hardware needs to be physically changed or swapped in order to decode signals sent from different MWD tools 40, which facilitates ease of use. Second, as the upstream interfaces 22 of all of the decoder implementations 20 are each conformed to the API used by the downstream interface 16 of the signal processing unit 14, the signal processing unit 14 can treat
-18-each of the decoding units 18 as a black box. This results in a modular design which allows changes to be made to any one of the decoding units 18 without affecting other modules within the apparatus 10.
In the present embodiment, the decoder configuration manager 26, translation layer 24, the signal processing unit 14 and the decoder implementation 20 are implemented as modules in the Java programming language, but in alternative embodiments any or all may be implemented according to any suitable programming language, such as C# and C++. In the present embodiment, the decoder configuration manager 26, translation layer 24, signal processing unit 14 and the decoder implementation 20 are all executed using a single processor (not shown) that forms part of the apparatus 10. The apparatus 10 also includes a computer readable medium (not shown) that is communicatively coupled to the processor and that stores information useful for implementation of the decoder configuration manager 26, translation layer 24, signal processing unit 14 and decoder implementation 20, such as software code. However, in alternative embodiments, any one or more of the decoder configuration manager 26, translation layer 24, signal processing unit 14 and decoder implementation 20 may be implemented using a standalone processor and computer readable medium physically removed from, yet still in communication with, the other modules of the apparatus 10 as depicted in Figure 2.
Furthermore, although the apparatus 10 of the present embodiment relies on a processor, other devices as known to skilled persons such as microcontrollers, programmable logic devices, and general purpose computers can be used to implement the modules of the apparatus 10. A
suitable computer readable medium includes any medium that is known to be suitable to skilled persons, such as suitable forms of disc-based and semiconductor-based media including RAM, ROM, flash memory, hard disk drives, CD-ROMs, and DVDs.
For the sake of convenience, the embodiments above are described as various interconnected functional blocks or distinct software modules. This is not necessary, however, and there may be cases where these functional blocks or modules are equivalently aggregated into a single logic device, program or operation with unclear boundaries. For example, the translation layer 24 and the decoder implementation 20 can be implemented separately such that they are able to be instantiated at different times in independent modules implemented on the same or different pieces of hardware, and such that they do not form a single decoding unit 18.
In any event, the
In the present embodiment, the decoder configuration manager 26, translation layer 24, the signal processing unit 14 and the decoder implementation 20 are implemented as modules in the Java programming language, but in alternative embodiments any or all may be implemented according to any suitable programming language, such as C# and C++. In the present embodiment, the decoder configuration manager 26, translation layer 24, signal processing unit 14 and the decoder implementation 20 are all executed using a single processor (not shown) that forms part of the apparatus 10. The apparatus 10 also includes a computer readable medium (not shown) that is communicatively coupled to the processor and that stores information useful for implementation of the decoder configuration manager 26, translation layer 24, signal processing unit 14 and decoder implementation 20, such as software code. However, in alternative embodiments, any one or more of the decoder configuration manager 26, translation layer 24, signal processing unit 14 and decoder implementation 20 may be implemented using a standalone processor and computer readable medium physically removed from, yet still in communication with, the other modules of the apparatus 10 as depicted in Figure 2.
Furthermore, although the apparatus 10 of the present embodiment relies on a processor, other devices as known to skilled persons such as microcontrollers, programmable logic devices, and general purpose computers can be used to implement the modules of the apparatus 10. A
suitable computer readable medium includes any medium that is known to be suitable to skilled persons, such as suitable forms of disc-based and semiconductor-based media including RAM, ROM, flash memory, hard disk drives, CD-ROMs, and DVDs.
For the sake of convenience, the embodiments above are described as various interconnected functional blocks or distinct software modules. This is not necessary, however, and there may be cases where these functional blocks or modules are equivalently aggregated into a single logic device, program or operation with unclear boundaries. For example, the translation layer 24 and the decoder implementation 20 can be implemented separately such that they are able to be instantiated at different times in independent modules implemented on the same or different pieces of hardware, and such that they do not form a single decoding unit 18.
In any event, the
-19-functional blocks and software modules or features of the flexible interface can be implemented by themselves, or in combination with other operations in either hardware or software.
While particular embodiments have been described in the foregoing, it is to be understood that other embodiments are possible and are intended to be included herein. It will be clear to any person skilled in the art that modifications of and adjustments to the foregoing embodiments, not shown, are possible.
While particular embodiments have been described in the foregoing, it is to be understood that other embodiments are possible and are intended to be included herein. It will be clear to any person skilled in the art that modifications of and adjustments to the foregoing embodiments, not shown, are possible.
-20-
Claims (13)
1. An apparatus for decoding a signal sent from a measurement-while-drilling tool, comprising:
(a) a signal processing unit communicatively coupled to the measurement-while-drilling tool and comprising a downstream interface configured to communicate according to a signal processing unit protocol, the downstream interface for sending the signal for decoding and for receiving a decoded signal; and (b) a decoding unit, comprising:
(i) a decoder implementation configured to decode the signal into the decoded signal and comprising an upstream interface configured to communicate according to a decoder implementation protocol, the upstream interface for receiving the signal for decoding and for sending the decoded signal; and (ii) a translation layer communicatively coupled between the downstream interface of the signal processing unit and the upstream interface of the decoding unit and configured to translate the signal processing unit protocol to the decoder implementation protocol such that the signal processing unit and the decoding unit are communicatively coupled.
(a) a signal processing unit communicatively coupled to the measurement-while-drilling tool and comprising a downstream interface configured to communicate according to a signal processing unit protocol, the downstream interface for sending the signal for decoding and for receiving a decoded signal; and (b) a decoding unit, comprising:
(i) a decoder implementation configured to decode the signal into the decoded signal and comprising an upstream interface configured to communicate according to a decoder implementation protocol, the upstream interface for receiving the signal for decoding and for sending the decoded signal; and (ii) a translation layer communicatively coupled between the downstream interface of the signal processing unit and the upstream interface of the decoding unit and configured to translate the signal processing unit protocol to the decoder implementation protocol such that the signal processing unit and the decoding unit are communicatively coupled.
2. An apparatus as claimed in claim 1 wherein the signal processing unit protocol comprises method calls to an application programming interface.
3. An apparatus as claimed in claim 1 comprising a plurality of decoding units including first and second decoding units, and wherein the decoder implementation of the first decoding unit and the decoder implementation of the second decoding unit are configured to decode differently encoded signals.
4. An apparatus as claimed in claim 3 further comprising a decoder configuration manager communicatively coupled to the signal processing unit and configured to instantiate any one of the decoding units in response to a selection signal sent from the signal processing unit.
5. An apparatus as claimed in claim 4 further comprising a decoder definition list file containing a listing of decoder definition files corresponding to the plurality of decoding units, and wherein the decoder configuration manager instantiates any one of the decoding units by accessing the decoder definition list file and by executing one of the decoder definition files.
6. An apparatus as claimed in claim 1 wherein the translation layer comprises a listener module configured to receive a parameter of the decoded signal from the upstream interface of the decoding unit and to asynchronously send the parameter of the decoded signal to the downstream interface of the signal processing unit.
7. A method for decoding a signal sent from a measurement-while-drilling tool, comprising:
(a) instantiating a decoder implementation configured to decode the signal into a decoded signal and communicative according to a decoder implementation protocol;
(b) conforming the decoder implementation protocol to a transmission protocol;
(c) sending the signal according to the transmission protocol to the decoder implementation; and (d) decoding the signal into the decoded signal using the decoder implementation.
(a) instantiating a decoder implementation configured to decode the signal into a decoded signal and communicative according to a decoder implementation protocol;
(b) conforming the decoder implementation protocol to a transmission protocol;
(c) sending the signal according to the transmission protocol to the decoder implementation; and (d) decoding the signal into the decoded signal using the decoder implementation.
8. A method as claimed in claim 7 wherein the transmission protocol is a signal processing unit protocol and further comprising a signal processing unit communicative according to the signal processing unit protocol, the signal processing unit for sending the signal to be translated from the signal processing unit protocol to the decoder implementation protocol.
9. A method as claimed in claim 8 further comprising asynchronously sending the decoded signal to the signal processing unit via a listener module.
10. A method as claimed in claim 8 wherein the signal processing unit protocol comprises method calls to an application programming interface.
11. A method as claimed in claim 8 wherein instantiating the decoder implementation comprises:
(a) accessing a decoder definition list file containing a listing of decoder definition files corresponding to first and second decoder implementations, the first and second decoder implementations configured to decode differently encoded signals; and (b) instantiating the decoder implementation corresponding to the encoding of the signal.
(a) accessing a decoder definition list file containing a listing of decoder definition files corresponding to first and second decoder implementations, the first and second decoder implementations configured to decode differently encoded signals; and (b) instantiating the decoder implementation corresponding to the encoding of the signal.
12. A computer readable medium having encoded thereon a method according to any one of claims 7 to 11 for execution by a processor.
13. An apparatus for decoding a signal sent from a measurement-while-drilling tool, comprising:
(a) a signal processing unit communicatively coupled to the measurement-while-drilling tool and comprising a downstream interface configured to communicate according to a signal processing unit protocol, the downstream interface for sending the signal for decoding and for receiving a decoded signal; and (b) a plurality of decoder implementations each configured to decode the signal into the decoded signal, each of the decoder implementations comprising an upstream interface conformed to communicate according to the signal processing unit protocol.
(a) a signal processing unit communicatively coupled to the measurement-while-drilling tool and comprising a downstream interface configured to communicate according to a signal processing unit protocol, the downstream interface for sending the signal for decoding and for receiving a decoded signal; and (b) a plurality of decoder implementations each configured to decode the signal into the decoded signal, each of the decoder implementations comprising an upstream interface conformed to communicate according to the signal processing unit protocol.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CA2689756A CA2689756C (en) | 2010-01-04 | 2010-01-04 | Method and apparatus for decoding a signal sent from a measurement-while-drilling tool |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CA2689756A CA2689756C (en) | 2010-01-04 | 2010-01-04 | Method and apparatus for decoding a signal sent from a measurement-while-drilling tool |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CA2689756A1 true CA2689756A1 (en) | 2011-07-04 |
| CA2689756C CA2689756C (en) | 2017-09-19 |
Family
ID=44256821
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CA2689756A Active CA2689756C (en) | 2010-01-04 | 2010-01-04 | Method and apparatus for decoding a signal sent from a measurement-while-drilling tool |
Country Status (1)
| Country | Link |
|---|---|
| CA (1) | CA2689756C (en) |
Cited By (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US9244047B2 (en) | 2012-04-17 | 2016-01-26 | Selman and Associates, Ltd. | Method for continuous gas analysis |
| US9442218B2 (en) | 2012-04-17 | 2016-09-13 | Selman and Associates, Ltd. | Gas trap with gas analyzer system for continuous gas analysis |
-
2010
- 2010-01-04 CA CA2689756A patent/CA2689756C/en active Active
Cited By (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US9244047B2 (en) | 2012-04-17 | 2016-01-26 | Selman and Associates, Ltd. | Method for continuous gas analysis |
| US9442218B2 (en) | 2012-04-17 | 2016-09-13 | Selman and Associates, Ltd. | Gas trap with gas analyzer system for continuous gas analysis |
Also Published As
| Publication number | Publication date |
|---|---|
| CA2689756C (en) | 2017-09-19 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US8095936B2 (en) | Remotely controlling and viewing of software applications | |
| CA2685290C (en) | System and method for performing a drilling operation in an oilfield | |
| CA2793811C (en) | System and method for performing oilfield drilling operations using visualization techniques | |
| CA2638566C (en) | Communications of downhole tools from different service providers | |
| US7861800B2 (en) | Combining belief networks to generate expected outcomes | |
| US11965416B2 (en) | Distributed remote logging | |
| US20140131099A1 (en) | System And Method For Managing And/Or Using Data For Tools In A Wellbore | |
| US20130282154A1 (en) | Remote dynamic message sign systems and methods of control | |
| CN105164370A (en) | Integrated downhole system with plural telemetry subsystems | |
| US20130083031A1 (en) | Customizable User Interface for Real-Time Oilfield Data Visualization | |
| US20050063251A1 (en) | Dynamic generation of vector graphics and animation of bottom hole assembly | |
| RU2648782C2 (en) | Integrated well survey management and planning tool | |
| US20160092482A1 (en) | Compiling drilling scenario data from disparate data sources | |
| CN104914745B (en) | Control the method and system of oscillograph | |
| CN105846857A (en) | Determining the signal quality of an electrical interconnect | |
| CA2689756C (en) | Method and apparatus for decoding a signal sent from a measurement-while-drilling tool | |
| US9618643B2 (en) | Method and apparatus for decoding a signal sent from a measurement-while-drilling tool | |
| US20190048715A1 (en) | Distributed remote logging | |
| US9911323B2 (en) | Toolstring topology mapping in cable telemetry | |
| EP2569603A1 (en) | Determining the order of devices in a downhole string | |
| US10347022B2 (en) | Perspective-based modeling of a subterranean space | |
| WO2021033110A1 (en) | System and method for programming devices | |
| US20150153917A1 (en) | Universal visualization component interface | |
| Krase et al. | A new measurement while drilling system designed specifically for drilling unconventional wells | |
| EP3026211A1 (en) | Down-hole permanent telemetry on mono-conductor |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| EEER | Examination request |
Effective date: 20140923 |