BACKGROUND

[0001] The disclosure generally relates to the field of hydrocarbon recovery operations, and more particularly to downhole tools diagnostics.

[0002] Various downhole tools are used for hydrocarbon exploration and production. Such tools can include rotary steerable system (RSS) tools, measurement while drilling (MWD) tools, logging while drilling (LWD), wirelines tools, etc. Such tools may operate in severe conditions including high downhole temperatures and pressures that may impact the tools and systems in which the tools operate.

BRIEF DESCRIPTION OF THE DRAWINGS

[0003] Embodiments of the disclosure may be better understood by referencing the accompanying drawings.

[0004] FIGS. 1A and IB are conceptual, partial cutaway diagrams depicting an example drilling system and an example wireline system that may implement aspects of a downhole tool diagnostics system, according to some embodiments.

[0005] FIGS. 2-3 are flowcharts illustrating operations and functions for implementing downhole tool diagnostics, according to some embodiments.

[0006] FIG. 4 is a flowchart depicting operations and functions for generating a System of Systems (SoS) dataset, according to some embodiments.

[0007] FIGS. 5-6 are flowcharts illustrating operations and functions for generating anomaly codes, according to some embodiments.

[0008] FIG. 7 is a flowchart depicting operations and functions for generating anomaly' codes based on tiered filtering, according to some embodiments.

[0009] FIG. 8 is a flowchart illustrating operations and function for flagging anomaly codes based on theoretical residuals, according to some embodiments.

[0010] FIG. 9 is a flowchart depicting operations and functions for implementing Rotary Steering System diagnostics, according to some embodiments.

[0011] FIG. 10 depicts a list of example anomaly codes, according to some embodiments.

[0012] FIG. 11 depicts an example Graphical User Interface (GUI) of failure/suspect isolation based on example anomaly codes of FIG. 10, according to some embodiments.

[0013] FIG. 12, depicts example plots based on the example anomaly codes of FIG. 10 and GUI of FIG. 11, according to some embodiments.

[0014] FIG. 13 depicts an example computer, according to some embodiments. DESCRIPTION

[0015] The description that follows includes example systems, methods, techniques, and program flows that embody aspects of the disclosure. However, it is understood that this disclosure may be practiced without these specific details. For instance, this disclosure describes diagnostics for a Rotary Steerable System (RSS) in some embodiments. Aspects of this disclosure may be also applied to any other type of downhole tool during or subsequent to drilling operations. For example, some embodiments may be used for diagnostics of Measurement While Drilling (MWD) tools. Logging While Drilling (LWD) tools, wireline tools, etc. In other instances, well-known instruction instances, protocols, structures, and techniques have not been shown in detail in order not to obfuscate the description.

[0016] A system of systems (SoS) is a set of two or more systems having respective individual operational profiles and that collectively may be generally characterized in terms of operational data associated with different operational modes and interoperability of a SoS. Some embodiments include a closed-loop automated diagnostic system using SoS data analytics, and fault model-based diagnostics to assess the operational condition of a RSS. A

SoS may comprise rig site surface elements, mud system, wellbore, drill pipe and bottom hole assembly (BHA) elements. Such embodiments enable (1) accurate decision to re-run the RSS tool in the field without maintenance; (2) fault model-based fail-site isolation and guided troubleshooting within the RSS for repair and maintenance which would aid in minimizing mean time to repair and repair cost; and (3) identify enabling systems and other element failures determined by the SoS data modeling and analy tics that can manifest as RSS functional failures to facilitate accurate root cause analysis at the BHA level. SoS data analytics can include rig site surface data, mud data, real time data, downhole recorded data from BHA elements, etc.

[0017] In some embodiments, a master SoS dataset in time and depth domain is generated. The SoS data can be analyzed by combining operational modes (e.g., pumps on/off, drilling activity', etc.) with tool modes (e.g., geostationary vs neutral, state machine, etc.) to generate anomaly codes or observations pre-defined for the system of interest and the SoS. Different or tiered filtering can be applied to the same signals to flag anomaly codes that help narrow fail-site isolation region. Different downhole measurements located within close proximity to each other can be used with theoretical models to compute operational parameters. Also, residuals of the theoretically computed operational parameters can be used to flag anomaly codes. Some embodiments can compare BHA bus master broadcast versus applied measurements to select signals to determine communication issues or identify logical errors.

[0018] Fault models can be developed based on cause and effect dependencies derived from tool architecture, design documents, test-bed experiments, accumulated information, physics-based/data-driven models, and SoS elements. Also, a library of anomaly codes corresponding to fault model observations can be defined. Anomaly codes are flagged when an anomaly is observed from the expected behavior under specified conditions. Algorithms can be developed to log the anomaly codes based on data from the tool of interest (e.g., RSS) and other parameters from the SoS dataset. The anomaly codes log can be used as input to the fault model to determine the possible suspects/failures within the system. In some embodiments, specific plots, charts, and statistics with relevant signals can be generated and displayed based on anomaly codes and suspects lists for guided troubleshooting. A library of plot templates for anomaly codes based on possible failure causes can be built

[0019] Templates can include specific signals to be analy zed and displayed in graphical form. Reference graphs can be provided to spot anomalies and disposition appropriately. Plot and statistic generation can be automated using a pre-defined mapping logic between anomaly codes and the plots listed in the plot libraries. Also, failures/suspects generated from fault model and anomaly code logs that require repair and maintenance of the downhole tool can be classified based on functions (e.g., power on different voltage levels, communication, sensors, etc.) and sub-systems/modules. In some embodiments, accurate health assessment and re-run criteria for a downhole tool can be determined at the rig site.

[0020] If no anomaly codes are flagged, preventive maintenance (PM) can be performed based on PM triggers. In some embodiments, if anomaly codes for secondary functions are flagged, the downhole tool may continue operation without repair if legacy based redundant tools are used for the secondary functions, or if service is delivered without the secondary functions, and if no preventive maintenance triggers are flagged for primary or critical functionality. If anomaly codes for primary or critical functionality are flagged, the fault model can be used with the anomaly code logs to provide fault isolation to the classified level along with troubleshooting guidelines. In addition, the anomaly codes list can be updated with post run shop level test observations. The downhole and shop observed fault codes and the fault model can be used to obtain the fault diagnostic results and provide troubleshooting guidelines to further isolate the failure.

[0021] Some embodiments combine operational and tool modes with tiered filtering of the SoS dataset to flag anomaly codes correctly, minimize false positives, and narrow down the failure suspects. For example, anomaly codes for valve toolface control (motor status, active rectification, and flow based) and power (flow and state machine based) use tiered filtering approach. Different downhole measurements located within close proximity along with test based/physics-based models can be used to compute operational parameters. Also, residuals of operational parameters can be used to flag anomaly codes and assess health of different sub-assemblies or components of the downhole tool. [0022] Anomaly codes can be analyzed and failure suspects classified by functions and/or modules. Additionally, some embodiments provide flexibility to re-run the tool in the field without repair if only noncritical or secondary functional anomaly codes are flagged. Suspects can be classified based on fimction (e.g., power generation (high voltage or low voltage), communications, downlink, valve tool face (TF), control sensors (e.g., gamma, directional, etc.), and/or modules like alternator assembly, sonde etc.

[0023] Some embodiments include SoS data analytics to accurately identify enabling or other systems defects that manifest as a failure of the tool of interest (e.g., RSS) for fast and accurate root cause analysis. An enabling system is an element in the SoS that enables primary or secondary functionality of a downhole tool. For example, if the RSS tool generates power using a turbine assembly, then a mud flow system utilized by the turbine assembly is an enabling system for the RSS tool. Some of the enabling system or BHA element failures that can appear as RSS failure include but are not limited to (1) intermittent or hard interconnect failures between BHA tools or elements resulting in lost communications, and (2) surface valve stuck open, wash out in one of the BHA elements, and/or reduced flow in a

Motor Assist Rotary Steerable System (MARSS) application resulting in turbine based power generation failures, etc.

[0024] Thus, some embodiments enable fast and accurate decisions at the rig and provide guided troubleshooting to reduce repair time and repair cost in the event of a failure for the downhole tools. Some embodiments can include automated diagnostics based on SoS data analytics and a fault model approach for a downhole tool to facilitate: (1) accurate decisions to re-run the downhole tool in the field without maintenance, resulting in reduced nonproductive time and improved asset utilization; (2) identification of SoS failures that manifest as downhole tool functional failure to facilitate accurate root cause analysis at the BHA level; and (3) guided troubleshooting to reduce repair time and repair cost associated with corrective maintenance. Additionally, some embodiments include use of automated diagnostics along with shop level checks for fast and accurate full tool check out pass/fail assessment prior to tool shipment to the rig. Also, some embodiments include an automated diagnostic approach that can be used for any downhole tool (MWD tools, LWD tools, wireline tools, etc.).

Example Drilling System

[0025] FIG. 1 depicts an example drilling system, according to some embodiments. In FIG. 1, a tool string 126 disposed in a borehole 116. The tool string 126 including a rotary steerable system (RSS) 128 in accordance with various embodiments. A drilling platform 102 supports a derrick 104 having a traveling block 106 for raising and lowering a drill string

108. A kelly 110 supports the drill string 108 as it is lowered through a rotary table 112. In some embodiments, a topdrive is used in place of the kelly 110 and the rotary table 112. A drill bit 114 is driven by a downhole motor or RSS, and/or rotation of the drill string 108. As bit 114 rotates, it creates the borehole 116 that passes through various downhole strata 118. A pump 120 circulates drilling fluid through a feed pipe 122 and downhole through the interior of drill string 108, through orifices in drill bit 114, back to the surface via the annulus around drill string 108, and into a retention pit 124. The drilling fluid transports cuttings from the borehole into the pit 124 and aids in maintaining the borehole integrity.

[0026] Tool string 126 includes RSS 128 and a compass unit 132. Compass unit 132 is a direction determination component that may be a sub or a component of sub (e.g., a MWD sub) disposed in the tool string 126 at a location that allows accurate directional determination such as by determining the angle between magnetic north and a reference location of the compass unit 132. In some embodiments, RSS 128 includes the direction control system that computes a target tool face or target position command based on the measurements provided by the RSS directional control sensors and compass unit 132. Tool string 126 may also include a logging-while-drilling (“LWD”)/measurement-while-drilling (“MWD”) tool 134 that collects measurements relating to various formation properties as well as the bit position and various other drilling conditions as bit 114 extends borehole 116 through the downhole strata 118. A telemetry system may be included to transfer tool measurements to and receive commands from a control/processing system located at the surface.

[0027] At various times during the drilling process, drill string 108 is removed from borehole 116 as shown in FIG. IB. Once the drill string has been removed, logging operations may be performed using a wireline logging tool 135, which in the depicted embodiment trey be a sensing instniment sonde suspended by a cable 142 hav ing conductors for transporting power to logging tool 135 and communications from logging tool 135 to the surface. For example logging tool 135 may comprise sensors for measuring downhole materials properties such as resistivity of and may have centralizing arms 136 that center logging tool 135 within borehole 116. A logging facility

144 collects measurements from the wireline logging tool 135 and includes computing facilities

145 for processing and storing the measurements gathered by wireline logging tool 135.

[0028] Example downhole tool diagnostics operations that may be implemented in association with the drilling system and wireline system components depicted in FIGS. 1 A and IB are now described. FIGS. 2-3 are flowcharts 200 and 300 illustrating operations and functions for implementing downhole tool diagnostics, according to some embodiments. The downhole tool diagnostics operations and functions continue from FIG. 2 to FIG. 3 through transition points A and B. The operations and functions depicted in flowcharts 200-300 may be performed by a combination of electrical, mechanical, and electromechanical components such as system sensors implemented in to measure operating parameters of surface and downhole drilling system components. Such sensors may be implemented locally downhole and may include sensors within LWD/MWD tool 134 or logging tool 135. The sensors may be implemented downhole, for example, to monitor various components within RSS 128 and drill bit 114. The sensors may also be implemented on surface components such as surface drill string control components and components that form part of the drilling fluid system such as pump 120.

[0029] Some of the operations as functions depicted in flowcharts 200 and 300 may also be performed by software, firmware, hardware or a combination thereof of a downhole data processing system and/or a surface data processing system. For example, with reference to FIG. 1, at least some of the operations can be performed by a processor downhole (e.g., integrated into the rotary steerable tool 128) and/or by a processor at the surface executing programmable code. The operations of the flowchart 200 start at block 202 at which an SoS dataset is generated. For example, a standalone application or programmed algorithms integrated with the surface system software can generate an SoS dataset for a downhole tool in time or depth reference at the rig site, and/or at other local or remote processing sites such as at manufacturing and/or repair and maintenance facilities. Tire SoS dataset may include rig site surface data, real time telemetry data, and downhole recorded data. Example operations for generating an SoS dataset are depicted in FIG. 4, which is further described below.

[0030] At block 204, anomaly codes are generated by obtaining and processing multisystem information. For example, a standalone application integrated such as by static or dy namic linking with the surface system software may generate the anomaly codes at rig site, manufacturing and/or repair and maintenance facilities. The generated anomaly codes may be multi-level codes that may indicate varying levels of failed or otherwise defective performance such as critical failure codes and non-critical failure codes. The anomaly codes may also include codes that indicate prospective performance issues such as preventive maintenance codes. Example operations for generating anomaly codes are depicted in FIGS. 5-6, which are further described below.

[0031] At block 206, a determination is made of whether one or more of the generated anomaly codes is/are critical failure codes. For example, a device with an integrated surface system software processor may identify a generated anomaly code as being a critical failure code by comparing the generated codes with a failure code criticality list 208. In response to determining that a critical failure code has been generated/triggered, operations of the flowchart 200 continue at block 218. In response to determining that a critical failure code has not been generated/triggered, operations of the flowchart 200 continue at block 210.

[0032] At block 210, a determination is made of whether one or more of the generated anomaly codes is/are preventive maintenance codes. For example, a device with an integrated surface system software processor can make this determination. For instance, preventive maintenance may be triggered in response to determining that total accumulated collar life has reached its limit based on measurement data within the SoS dataset In response to determining that a preventative maintenance code has been generated/triggered, operations of the flowchart 200 continue at block 218. In response to determining that a critical failure code has not been generated/triggered, operations of the flowchart 200 continue at block 212.

[0033] At block 212, status of the downhole tool is set as continue operation or re-start operation without maintenance. For example, a device with an integrated surface system software processor may set the status of the downhole tool as continuing or re-starting operation. At block 214, a determination is made of whether the downhole tool continues to operate or is re-started. For example, a programmed data processing system by perform this determination based on the failure codes log, tool inspection at surface and/or surface tests. In response to determining that the downhole tool continues or has re-started operation, the operations of the flowchart 200 return to block 202. In response to determining that the downhole tool is not operating, operations continue at block 216.

[0034] At block 216, a determination is made of whether one or more of the generated anomaly codes is/arc non-critical failure codes. For example, a device with an integrated surface system software processor may identify a generated anomaly code as being a non- critical failure code by comparing the generated codes with failure code criticality list 208. In response to determining that a non-critical failure code has not been generated/triggered, operations of the flowchart 200 continue at transition point A, which continues at transition point A in the flowchart 300 of FIG. 3. In response to determining that a non-critical failure code has been generated/triggered, operations of the flowchart 200 continue at block 218.

[0035] At block 218, a fault diagnostics result is generated based on the fault codes logs and a tool fault model. For example, a device with a standalone application or linked modules integrated with the surface system software can make this determinatkm. The tool fault model may be generated based on cause and effect dependencies with the failures (e.g., failures associated with the critical and non-critical failure codes) and the analysis of the failures. In some embodiments, tire cause and effect dependencies may be determined using the tool architecture, design documents, simulation, performance history information, etc. Relevant anomaly codes based on BHA and overall drilling system architecture can be defined and added to the fault model enabling the model to identify various systems failures that may result in service interruptions. This combined fault model can be represented as a cause and effect dependency matrix. The anomaly codes generated/triggered at block 204 can be input into the fault model and the device with diagnostic algorithms integrated with the surface system software may generate the diagnostic results. Additional anomaly codes generated during post-run tool testing and maintenance (block 220) can be input to the fault model or other application to generate the fault diagnostics result(s). Post maintenance, a tool level only fault model can be used to perform final qualify check to assess the operational condition of the tool before the tool is dispatched to the field to minimize immediate post- implementation failures. Operations of the flowchart 200 continue at transition point B, which continues at transition point B in the flowchart 300 of FIG. 3.

[0036] From transition point B, operations continue at block 302 at which anomaly codes and suspects-based specific plots are generated and analyzed. In some embodiments, generating the plots may comprise displaying anomaly information plots on a computer display. Some of the specific plots may display graphical information indicating the environmental and operational stresses experienced by the tool of interest during downhole operation. A library of plot templates for a pre-defined anomaly codes/suspect list and associated program code may be used to enable and automate this functionality. For example, if the anomaly codes include one or more failure codes that indicate overvoltage on a high- power line and the fault model confirms failure on a 400V line, the process may generate a specific plot of 400V measurements at different points, tool state, operational mode, etc. The generated plots may provide insight into the cause of the failure for cases in which multiple causes may potentially result in the same failure triggering the corresponding anomaly code(s). The generated plots may also depict, describe, or otherwise characterize test conditions to be used to replicate the downhole problem at surface, and furthermore may determine false positives due to data quality issues.

[0037] At block 304, a determination is made of whether the failures determined by the fault model or otherwise based on the anomaly codes are true or false positives. For example, the plots generated based on a log containing the anomaly codes and corresponding downhole tools associated with the anomaly codes are compared to reference specific plots for correct dispositioning. For instance, if one of more specific plots generated at block 302 depicts overvoltage during steady state drilling operation, and a module generating the overvoltage flag exhibits a fault state, then the logged failure/anomaly is confirmed positive. In response to determining that one or more of the failures/anomalies are false positives, operations of the flowchart 300 continue at block 306 at which level one preventive maintenance is performed. If the determined failures/anomalies are confirmed true positive, operations of the flowchart 300 continue at block 308.

[0038] At block 308, corrective maintenance based on guided troubleshooting is performed. For example, a device with standalone application or integrated surface system software can perform this operation For instance, the failure diagnostics may be a problem on a high-power signal line in the tool. A technician and/or automated repair system may be presented a set of troubleshooting operations that enable isolation of the failure to a replaceable component (e.g., connector at an instrumentation collar) level. In some embodiments, labor and repair costs, skill level, testing time, etc. are accounted for by the device in which a standalone application or integrated surface system software may provide such guided troubleshooting steps. [0039] Operations of the flowchart 300 continue at block 310 at which full tool assembly and checkout is performed. Tool build quality can be confirmed with system level test and diagnostic fault model. At block 312, an inventory is performed, completing the operations of the flowcharts 200 and 300.

[0040] In the foregoing manner, the operations depicted in FIGS. 2-3 are implemented to determine accurate operational condition and re-run criteria for one or more downhole tools.

If no anomaly codes are flagged, then preventive maintenance (PM) can be performed based on PM triggers. Additionally, if anomaly codes for secondary functions are flagged, the downhole tool could still be re-run without repair if legacy based redundant tools could be used for secondary functions or if service can be delivered without the secondary function, and if no preventive maintenance triggers are flagged for primary or critical functionality. Also, as part of these operations, if anomaly codes for primary or critical functionality are flagged, the tool fault diagnostic results can be updated with post run shop level test observations and troubleshooting guidelines provided.

[0041] FIG. 4 depicts a flow-chart of operations to generate a System of Systems (SoS) dataset, according to some embodiments. Operations of a flowchart 400 can be automated using algorithms that can be processed by software, hardware or a combination thereof. Operations of the flowchart 400 can be example operations of the operation at block 202 of the flowchart 200 for generating an SoS dataset. At block 402, field run data, tool read data, and tool read parsing files are obtained. The field run based data can include surface data, real time data from downhole tools, downhole tools recorded data, mud logs and other operational data. In addition, there can be memory read data (example: binary files) generated through separate downhole tools memory data read. Parsing files for memory data read are predefined based on tools used in the tool string.

[0042] At block 404, memory tool read datasets is parsed into a time series engineering dataset. For example, a device with standalone application or an integrated surface system software can parse the tool read data. Data recorded at the tool can be in a binary file format with sensor measurements, tool modes, diagnostic information etc. Such data can be parsed with proper scaling to generate a time series dataset with engineering values of the measurements. The parsed data can be integrated into field data file and/or it can be merged into a SoS dataset using programmable codes executed by the processor.

[0043] At block 406, data from different records is extracted from the field data file as different/individual datasets. The field data can contain data in different formats. For example, an algorithm or programmable code executed by the processor-can generate these individual datasets. A list with parameters to be extracted from the different records contained in the field data file (408) can be input for this operation. Surface data, downhole tools real time and recorded data, mud logs and other operational data can be stored as different records in the field data file. Individual dataset records can be generated by extracting defined parameters of interest maintained in a dynamic (editable) list of parameters or variables.

[0044] At block 410, the individual record datasets are converted to homogeneous format. For example, an algorithm or programmable code can convert the individual record datasets to a homogeneous format. At block 412, the discrete datasets are merged into time series SoS dataset. For example, programmable code executed by a processor can merge the discrete datasets into time series SoS dataseL At block 414, calculations are computed and added to time series based SoS dataset. For example, an algorithm or programmable code a prooesBor can perform these operations. Predefined calculations based on the

parameters/variables already present in the SoS dataset, data processing logic and/or test based, physics-based models at block 416 can be input for this operation. For example, the pressure differential can be calculated from annulus and bore pressure measurements and added to the SOS dataset. Another example can be to compute the downhole flow rate from turbine RPM, mud properties and test-based transfer functions.

[0045] At block 418, the time series based SoS datasets are truncated based on the start time and end time for the run of interest. For example, an algorithm or programmable code can perform this truncation. At block 420, a depth based SoS dataset is generated. For example, an algorithm or programmable code can be used to generate the depth based SoS dataset parameters and/or variables and corresponding bit to sensor distance measurements at block 422 can be input for this operation. The SoS dataset is now available in time-based or depth-based reference for analysis. For time-based data, the variables can be populated with their values in increasing chronological time based on the sampling rate. For depth-based data, the variables can be populated with values in increasing depth.

[0046] At block 424, an SoS dataset for anomaly code generation is determined. For example, user can determine the SoS dataset to be used for anomaly code generation. In some embodiments, anomaly code generation may require only a subset of the SoS dataset. In addition to SoS dataset, other data such as tool and BHA configuration, operational events etc. can also be extracted and used for performance evaluation, operational

procedure/sequencing or optimized state transitions for improved performance, and diagnostics. In the foregoing manner, the operations of flowchart 400 generate a SoS dataset in time and depth domains to be used for diagnostics of downhole tools.

[0047] FIGS. 5-6 depict flowcharts of operations to generate anomaly codes, according to some embodiments. Operations of flowcharts 500-600 of FIGS. 5-6 continue among each other through transition point C. Operations of the flowcharts 500-600 can be performed by combination of software and hardware. For example, with reference to FIG. 1, at least some of the operations can be performed by a processor downhole (e.g., integrated into the rotary steerable tool 128) and/or by a processor at the surface executing programmable code.

Operations of the flowcharts 500-600 can be example operations of the operation at block 204 of the flowchart 200 for generating anomaly codes. The operations of the flowchart 500 start at block 502.

[0048] At block 502, the SoS dataset is obtained. For example, programmable code executing on a processor may obtain the SoS dataset such as by a programmed request executed by a communication interface. At block 504, n number of tests for the anomaly codes are defined. For example, an algorithm or programmable code can define the n number of tests. Tests may entail pass/fail criteria for measurements, estimated parameters based on measurements and various changed detection algorithms suitable for each tests etc.

[0049] At block 506, thresholds and conditions for data preprocessing are defined based on downhole tools configuration, region, and formation based operational settings. For example, programmable code executing on a processor may define the thresholds based on operational mode and/or tool mode. Example of tool mode filtering could be passive or active rectification mode, neutral vs geostationary mode etc. Operational modes could entail pumps on/pumps off, drilling activity etc.

[0050] At block 508, missing values from the SoS dataset are processed. For example, programmable code executing on a processor may process the missing values. To illustrate, if certain variables have missing values, the processor can determine how to process including replacing with mean, previous values, interpolation, removing the entire sample, etc.

[0051] At block 510, tiered filters are applied to diagnostic data and measurements when applicable. For example, programmable code may apply the tiered filters in which there may be multiple layers of filtering. For example, a first filter may be based on flow rate being greater than a flow threshold. A second filter may follow the first filter and may be based on tool mode such as active versus passive rectification.

[0052] At block 512, calculations based on downhole measurements and/or test- based/physics-based models are performed and residuals are computed as applicable. For example, programmable code executing on a processor may perform these operations. To illustrate, flow rate can be estimated based on differential pressure, bit total flow area and physics-based model. The residuals can then be computed as applicable.

[0053] At block 514, an anomaly code specific dataset is generated based on relevant operational modes/phases and tool modes. For example, programmable code executing on a processor may generate the anomaly code specific dataset. For example, undervoltage fault flag on module 2 high voltage signal is only valid when (1) the module 1 is in active rectification, (2) tool modes downhole, and (3) tool state is hold tool face.

[0054] At block 516, the tests are initialized with k equaling one and t equaling start time of the downhole tool. For example, programmable code executing on a processor may initialize the tests by setting these variables to their appropriate values. Operations of the flowchart 500 continue at transition point C, which continues at transition point C of the flowchart 600. From transition point C, operations continue at block 602 in which a determination is made of whether test (k) fails at time(t) . For example, a programmable code may make this determination If the test (k) does not fail at time(t), operations of the flowchart 600 continue at block 606 (which is further described below).

[0055] If the test(k) does fail at time(t), operations of the flowchart 600 continue at block 604. At block 604, the anomaly code is recorded (the date and time of the failure is also logged). For example, programmable code executing on a processor may perform these operations. Anomaly code definitions 624 can be input for this operation.

[0056] At block 606, the variable k is incremented (k = k + 1) such as may be executed by programmable code executing on a processor. At block 608, a determination is made of whether the variable k is greater than the total number of tests, n. If the variable k is not greater than the total number of tests n, operations return to block 602. Otherwise, operations continue at block 610 at which time is incremented based on sampling (t = t+ 1).

[0057] At block 612, a determination is made of whether time t is greater than T (run or test end time), such as may be executed by programmable code executing on a processor. If time t is not greater than T, operations return to block 602. Otherwise, operations continue at block 614. At block 614, the test results are combined, such as may be executed by programmable code executing on a processor. There may be k tests for a given time instant and the tests can be performed for an entire time T. Therefore, these tests can be combined for the entire time T. Alternatively , the test k can be tested from start time to the end time T and then k can be incremented by k = k+1. The test results may be combined.

[0058] At block 616, anomaly codes flagged with timestamps are recorded, such as may be executed by programmable code executing on a processor. Thus, the anomaly codes are associated with a time of occurrence. At block 618, a pre -defined time delay for anomaly- code logs is applied w'hen multiple triggers of one test code occur in pre-defmed time window. For example, if a failure continues to occur, instead of recording every instant, the programmable code applies pre-defmed time delay. To illustrate, if failure happens every second, for 30 minutes there would be 1800 records of the same fault without any time delay. Instead of logging 1800 records, a time delay is applied. For example, if a fault is logged, logging is delayed over the next 5 minutes even if otherwise triggered within the 5 minute period.

[0059] At block 620, diagnostic codes generated for the test run are logged, such as may be executed by programmable code executing on a processor. At block 622, fault codes observed during the entire test time duration is logged. For example, an algorithm or programmable code can perform this operation. Along with anomaly codes log, end of run failure logs can be logged separately. An end of run failure log can be generated to provide a more precise characterization of the failure that caused a condition requiring withdrawal of drill string components from the borehole in addition to a more comprehensive

characterization of the entire run log. In the foregoing manner, flowcharts 500 and 600 include operations to generate anomaly codes and observations that can be pre-defined for a system of interest using an SoS dataset. The anomaly code log may then be leveraged for diagnostics and guided troubleshooting.

[0060] FIG. 7 depicts a flowchart of operations to generate anomaly codes based on tiered filtering, according to some embodiments. Operations of flowchart 700 can be a different example of operations at blocks 302, 510, and 514 of the flowcharts 300 and 500.

Operations of the flowchart 700 can be performed by software, firmware, hardware, or a combination thereof. For example, with reference to FIG. 1, at least some of the operations can be performed by a processor downhole (e.g., integrated into the rotary steerable tool 128) and/or by a processor at the surface executing programmable code.

[0061] The operations of tire flowchart 700 start at block 702 at which tire SoS dataset is obtained. For example, programmable code executing on a processor may obtain tire SoS dataset such as by a programmed request executed by a communication interface. At block 704, TF error average and standard deviation trends are analyzed while drilling, in active rectification, and with motor on state. An algorithm or programmable code can perform this operation. For example, the analysis can include how toolface error average and standard deviation are changing over time and how they compare to predefined control limits (increasing, remaining constant, decreasing, fluctuating between an increase and decrease, etc.). Anomaly codes 1, 2, and 3 in figure 7 are derived from the same set of measurements (TF error average and standard deviation) with different/tiered filtering applied.

[0062] At block 706, a determination is made of whether there are any outliers based on pass/fail criteria (specified upper and lower limits, number of events, and duration of outlier events), such as may be performed by programmable code executing on a processor. For example, based on design documents, operations, and testing, limits and ranges of different measurements for various tool modes and operational modes can be defined. Such limits, ranges, and thresholds can be used to determine whether a test has passed or failed. If there are not any outliers, operations of the flowchart 700 continue at block 710.

[0063] Otherwise, operations continue at block 708, at which anomaly code 1 is generated and outliers are investigated and disposed, such as may be performed by programmable code executing on a processor. The anomaly code 1 may be part of an input to the fault model for further analysis, and plots from the defined plot library or new plots can be automatically generated and used for dispositioning of the faults. A determination can be made of whether these are legitimate faults or false alarms. [0064] At block 710, TF error average and standard deviation and other relevant signals trends are analyzed while drilling and in active rectification mode only, such as may be performed by programmable code executing on a processor. At block 712, a determination is made whether there are any outliers observed (TF error average, TF error standard deviation, and other relevant signals), such as may be performed by programmable code executing on a processor. If there are not any outliers, operations of the flowchart 700 continue at block 716.

[0065] Otherwise, operations of the flowchart 700 continue at block 714 at which anomaly code 2 is generated and outliers are investigated and disposed, such as may be performed by programmable code executing on a processor. The anomaly code 2 may be included in an input to the fault model for further analysis, and plots from the defined plot library or new plots may be automatically generated and used for dispositioning of the faults.

[0066] At block 716, TF error average and standard deviation and other relevant signals are analyzed while drilling only. At block 718, a determination is made whether there are any outliers observed (TF error average, TF error standard deviation, and other relevant signals). For example, an algorithm or programmable code can make this determination. If there are no outliers, operations of the flow-chart 700 continue at block 722 (which is further described below). Otherwise, operations of the flowchart 700 continue at block 720.

[0067] At block 720, anomaly code 3 is generated and outliers are investigated and disposed. For example, an algorithm or programmable code can perform these operations. The anomaly code 3 can be part of an input to the fault model for further analysis, and plots from the defined plot library or new plots can be automatically generated and used for dispositioning of the faults. At block 722, valve TF control performance is marked as good. For example, an algorithm or programmable code can perform this operation. In the foregoing manner, flowchart 700 includes operations to flag anomaly codes using different or tiered filtering of the same signal to help narrow the fail site isolation region to be used for diagnosis of downhole tools.

[0068] FIG. 8 depicts a flowchart of operations to flag anomaly codes based on residuals, according to some embodiments. Operations of flowchart 800 can be a different example of operations at blocks 302, 512 and 514 of the flowcharts 300 and 500. Operations of the flowchart 800 can be performed by software, firmware, hardware or a combination thereof. For example, with reference to FIG. 1, at least some of the operations can be performed by a processor downhole (e.g., integrated into the rotary steerable tool 128) and/or by a processor at the surface executing programmable code.

[0069] At block 802, downhole flowrate to the turbine, bypass flowrate to the annulus, and bypass ratio are calculated based on turbine speed recorded data, surface flow rate data and a turbine model. The bypass flowrate depends on the BHA configuration and drill pipe integrity while drilling. At block 804, under steady state conditions a surface flowrate mean, a downhole flowrate mean, a bypass flowrate mean, and a bypass ratio mean are calculated for each pump cycle. Moving average calculations could also be used, such as may be performed by programmable code executing on a processor.

[0070] At block 806, surface system and BHA construct information is determined. For example, an algorithm or programmable code can make this determination. This information can include (1) whether this is a MARSS (motor assisted rotary steerable drilling) application, (2) type of mud motor (sealed or unsealed), (3) mud motor build sheet, (4) empirical bypass data (if available), (5) empirical pump efficiency (if available), and (6) mud pulse telemetry (MPT) or electromagnetic telemetry (EMT).

[0071] At block 808, a determination is made whether the surface system and BHA construct information are logically consistent with the calculated bypass ratio. If the surface system and BHA construct information is consistent with the calculated bypass ratio, operations of the flowchart 800 continue at block 814, which is further described below. Otherwise, operations of the flowchart 800 continue at block 810 at which downhole flowrate2 is computed based on differential pressure recorded data and a hydraulic model.

Also residual of flow rates (difference between measured flowrate at surface and estimated flowrate using turbine model along with downhole measurements of turbine speed

(revolutions per minute (RPM)) and differential pressure) is calculated.

[0072] At block 812, a determination is made of whether the residual is less than a threshold. If the residual is not less than a threshold, operations of the flowchart 800 continue at block 816, which is further described below. Otherwise, operations of the flowchart 800 continue at block 814 at which turbine performance is classified as acceptable. At block 816, a residual based anomaly code is logged and oudiers are investigated and disposed. In the foregoing manner, flowchart 800 includes operations to flag anomaly codes using residuals of theoretically estimated measurements, wherein the anomaly codes can be used for diagnostics of downhole tools.

[0073] FIG. 9 depicts a flowchart of operations for RSS diagnostics, according to some embodiments. Operations of a flowchart 900 can be performed by software, firmware, hardware or a combination thereof. For example, with reference to FIG. 1, at least some of the operations can be performed by a processor at the surface executing programmable code or an integrated surface software. At least a portion of the operations of the flowchart 900 can be example operations of the operation at block 218 of flowchart 200 for generating the tool fault model. The operations of flowchart 900 starts at block 902.

[0074] At block 902, cause and effect dependencies are determined based on observations and associated underlying failures. In some embodiments, this determination can be made when the system is designed and developed. During product development, a model of failures and their observations can be built using various design documents, experiments, data analysis, performance history information, dFMEA, BHA configurations based of field use cases, enabling systems used etc.

[0075] At block 904, anomaly codes are obtained based on the flowchart shown in FIG.

6 for a SoS dataset At block 906, anomaly codes, descriptions, and event times are logged in chronological order. The log can be queried for specific anomaly codes. An example of a display of such logging is depicted in FIG. 11, which is further described below. At block 908, anomaly code log and the fault model are used to infer the failure and/or suspects by function(s) or tool elements. The fault model developed at block 902 along with the anomaly codes log generated at block 904 can be used to infer and display the failure and/or suspects. The failure/suspects can be classified based on functions and/or by tool elements.

[0076] At block 910, the operational status or health status is displayed in a dashboard with predefined color schemes (red for confirmed failures, yellow for suspects, green for no failures and grey for unknown fault status) for different functions and/or tool elements. For example, a processor can perform this operation. Once the failure and/or suspects are inferred based on functions and/or tool elements, tire failures and/or suspects can be presented in a dashboard. An example of such a dashboard is depicted in FIG. 12 (which is further described below).

[0077] At block 912, instructions on further isolation are provided based on the current diagnostic results. Based on results from the cause and effect dependencies and tool fault model, further available tests (e.g., tests performed at a repair or maintenance facility) can be performed to isolate the failure to a lower level (e.g., component level). Such instructions include overall system schematics and fault location, further necessary tests to isolate/confirm the failure in suitable interactive form the user.

[0078] At block 914, schematics and/or interactive displays are provided for repair and maintenance to facilitate troubleshooting. For example, based on the diagnostic results generated by operations at block 910, a fault specific and tailored schematic and/or interactive display can be presented. At block 916, failure reports are generated based on user login records, failure category, geographic locations, etc. For example, information about user logins, failure category, geographic location, etc. may be combined for various jobs or runs to extract customized reports.

[0079] FIG. 10 depicts a list of example anomaly codes, according to some embodiments. In particular, FIG. 10 depicts a list 1000 with three columns - failure code identification, description, and time.

[0080] FIG. 11 depicts an example Graphical User Interface (GUI) of failure/suspect isolation based on example anomaly codes illustrated in FIG. 10, according to some embodiments. In particular, FIG. 11 depicts a GUI 1100 to that may facilitate isolation of failures and potential failure conditions. [0081] FIG. 12, depicts example plots based on the example anomaly codes illustrated in FIG. 10 and displayed in the GUI 100 of FIG. 11, according to some embodiments. In particular, FIG. 12 depicts plots 1200. The plots 1200 include relevant signals based on anomaly codes and suspect list for guided troubleshooting.

Example Computer

[0082] FIG. 13 depicts an example computer, according to some embodiments. The computer includes a processor 1301 (possibly including multiple processors, multiple cores, multiple nodes, and/or implementing multi-threading, etc.). The computer includes memory 1307. The memory 1307 may be system memory (e.g., one or more of cache, SRAM, DRAM, zero capacitor RAM, Twin Transistor RAM, eDRAM, EDO RAM, DDR RAM, EEPROM, NRAM, RRAM, SONOS, PRAM, etc.) or airy one or more of the above already described possible realizations of machine-readable media. The computer system also includes a bus 1303 (e.g., PCI, ISA, PCI-Express, HypeiTransport® bus, InfiniBand® bus, NuBus, etc.) and a network interface 1305 (e.g., a Fiber Channel interface, an Ethernet interface, an internet small computer system interface, SONET interface, wireless interface, etc.).

[0083] The computer also includes an analyzer 1311 and a controller 1315. The analyzer

1311 can perform diagnostic operations of a downhole tool (as described above). The controller 1312 can control the different operations that can occur in the response to results from the diagnostic operations. For example, the controller 1312 can communicate instructions to the appropriate equipment, devices, etc. to alter different hydrocarbon recovery operations. Any one of the previously described functionalities may be partially (or entirely) implemented in hardware and/or on the processor 1301. For example, the functionality may ^¬ be implemented with an application specific integrated circuit, in logic implemented in the processor 1301, in a co-processor on a peripheral device or card, etc. Further, realizations may include fewer or additional components not illustrated in Figure 13 (e.g., video cards, audio cards, additional network interfaces, peripheral devices, etc.). The processor 1301 and the network interface 1305 are coupled to the bus 1303. Although illustrated as being coupled to the bus 1303, the memory 1307 may be coupled to the processor 1301.

[0084] As will be appreciated, aspects of the disclosure may be embodied as a system, method, or program code/instructions stored in one or more machine-readable medium(s). Accordingly, aspects may take the form of hardware, software (including firmware, resident software, micro-code, etc.), or a combination of software and hardware aspects that may all generally be referred to herein as a“circuit,”“module,” or“system.” The functionality presented as individual modules/units in the example illustrations can be organized differently in accordance with any one of platform (operating system and/or hardware), application ecosystem, interfaces, programmer preferences, programming language, administrator preferences, etc.

[0085] Any combination of ore or more machine readable medium(s) may be utilized. The machine-readable medium may be a machine-readable signal medium or a machine- readable storage medium. A machine-readable storage medium may be, for example, but not limited to, a system, apparatus, or device that employs any ore of or combination of electronic, magnetic, optical, electromagnetic, infrared, or semiconductor technology to store program code. Mote specific examples (a non-exhaustive list) of the machine-readable storage medium would include the following: a portable computer diskette, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or Flash memory), a portable compact disc read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing. In the context of this document, a machine-readable storage medium may be any tangible medium that can contain or store a program for use by or in connection with an instruction execution system, apparatus, or device. A machine-readable storage medium is not a machine-readable signal medium.

[0086] A machine-readable signal medium may include a propagated data signal with machine readable program code embodied therein, for example, in baseband or as part of a carrier wave. Such a propagated signal may take any of a variety of forms, including, but not limited to, electro-magnetic, optical, or any suitable combination thereof. A machine- readable signal medium may be any machine-readable medium that is not a machine-readable storage medium and that can communicate, propagate, or transport a program for use by or in connection with an instruction execution system, apparatus, or device. Program code embodied on a machine-readable medium may be transmitted using any appropriate medium, including but not limited to wireless, wireline, optical fiber cable, RF, etc., or any suitable combination of the foregoing.

[0087] Computer program code for carrying out operations for aspects of the disclosure may be written in any combination of one or more programming languages, including an object oriented programming language such as the Java® programming language, C#, C++; or like a dynamic programming language such as Python; or like a high level programming language for technical computing such as MATLAB ^® ; a scripting language such as Perl programming language or PowerShell script language; and conventional procedural programming languages, such as the C programming language or similar programming languages. The program code may execute entirely on a standalone machine, may execute in a distributed manner across multiple machines, and may execute on one machine while providing results and or accepting input on another machine. The program code/instructions may also be stored in a machine-readable medium that can direct a machine to function in a particular manner, such that the instructions stored in the machine-readable medium produce an article of manufacture including instructions which implement tire function/act specified in the flowchart and/or block diagram block or blocks.

[0088] The flowcharts are provided to aid in understanding the illustrations and are not to be used to limit scope of the claims. The flowcharts depict example operations that can vary within the scope of the claims. Additional operations may be performed; fewer operations may be performed; the operations may be performed in parallel; and the operations may be performed in a different order. It will be understood that each block of the flowchart illustrations and/or block diagrams, and combinations of blocks in the flowchart illustrations and/or block diagrams, can be implemented by program code. The program code may be provided to a processor of a general-purpose computer, special purpose computer, or other programmable machine or apparatus. As used herein, the term“or” is inclusive unless otherwise explicitly noted. Thus, the phrase“at least one of A, B, or C” is satisfied by any element from the set {A, B, C} or any combination thereof, including multiples of any element.

Example Embodiments:

[0089] Embodiment 1 : A method comprising: generating a System of Systems (SoS) dataset in a time domain and a depth domain for a downhole tool, wherein the SoS dataset comprises operational data associated with operational modes, tool data associated with tool modes of the downhole tool, and operational data for one or more enabling systems;

generating one or more anomaly codes based on the SoS dataset, wherein the anomaly codes correspond to one or more anomalies associated with the downhole tool or an enabling system of the downhole tool; generating a tool fault model based on dependencies of conditions corresponding to the one or more anomaly codes to tool failures or enabling system failures; and determining one or more failures of the downhole tool and one or more causes of the failures based on the tool fault model and the one or more anomaly codes. Said generating the one or more anomaly codes may comprise generating the anomaly codes based on a tiered filtering of the SOS dataset. Said generating the one or more anomaly codes may comprise generating the anomaly codes based, at least in part, on residuals of predicted operational data. The method of Embodiment 1 may further comprise determining whether at least one anomaly of the one or more anomalies is due to the downhole tool or a system that includes the downhole tool; and isolating a cause of the at least one anomaly based, at least in part, on said determining whether the at least one anomaly is due to the downhole tool or a system that includes the downhole tool. Said isolating a cause of the at least one anomaly may comprise determining that at least one anomaly of the one or more anomalies is a critical failure, and confirming at least one of the generated anomaly codes based, at least in part, on one or more plots generated based on the generated anomaly codes and systems corresponding to the anomaly codes. The method of Embodiment 1 may further comprise using the anomaly codes and the determined one or more failures to determine an initial test to be conducted; and sequencing subsequent tests based on test outcomes and fault trees until one or more failing components are identified. The method of Embodiment 1 may further comprise, in response determining that at least one anomaly of the one or more anomalies is not a critical failure, continuing operation or re-starting operation of the downhole tool. The method of

Embodiment 1 may further comprise utilizing the SoS dataset and the generated anomaly codes to modify at least one of operational procedures and tool state transition logic.

[0090] Embodiment 2: A system comprising: a downhole tool configured to be positioned in a borehole, the downhole tool comprising a number of sensors configured to detect events related to operation of the downhole tool; and a diagnostics device configured to generate a System of Systems (SoS) dataset in a time domain and a depth domain for a downhole tool, wherein the SoS dataset comprises operational data associated with operational modes, tool data associated with tool modes of the downhole tool, and operational data for enabling systems; generate one or more anomaly codes based on the SoS dataset, wherein the anomaly codes correspond to one or more anomalies associated with the downhole tool or an enabling system of the downhole tool; generate a tool fault model based on dependencies of conditions corresponding to the one or more anomaly codes to tool failures or enabling system failures; and determine one or more failures of the downhole tool and one or more causes of the failures based on the tool fault model and the one or more anomaly codes. Said generating the one or more anomaly codes may comprise generating the anomaly codes based on a tiered filtering of the SoS data. Said diagnostic device may be configured to determine whether at least one anomaly of the one or more anomalies is due to the downhole tool or a system that includes the downhole tool; and isolate a cause of the at least one anomaly based, at least in part, on said determining whether the at least one anomaly is due to the downhole tool or a sy stem that includes the downhole tool. Said diagnostic device may be configured to determine whether the at least one anomaly is a critical failure; and confirm at least one of the generated anomaly codes based, at least in part, on one or more plots generated based on the generated anomaly codes and systems corresponding to the anomaly codes. Said diagnostic device may be configured to utilize combined data from the SoS dataset and from the generated anomaly codes to modify at least one of operational procedures and tool state transition logic.

[0091] Embodiment 3: A machine-readable medium having instructions stored thereon that are executable by a device to perform a method comprising: generating a System of Systems (SoS) dataset in a time domain and a depth domain for a downhole tool, wherein the SoS dataset comprises operational data associated with operational modes, tool data associated with tool modes of the downhole tool, and operational data for enabling systems; generating one or more anomaly codes based on the SoS dataset, wherein the anomaly codes correspond to one or more anomalies associated with the downhole tool or an enabling system of the downhole tool; generating a tool fault model based on dependencies of conditions corresponding to the one or more anomaly codes to tool failures and enabling system failures; and determining one or more failures of the downhole tool and one or more causes of the failures based on the tool fault model and the one or more anomaly codes. For Embodiment 3, the method may further comprise generating the one or more anomaly codes based on a tiered filtering of the SoS data. For Embodiment 3, the method may further comprise determining whether at least one anomaly of the one or more anomalies is due to the downhole tool or a system that includes the downhole tool; and isolating a cause of the at least one anomaly based, at least in part, on said determining whether the at least one anomaly is due to the downhole tool or a system that includes the downhole tool. Said isolating a cause of the at least ore anomaly may comprise determining that at least ore anomaly of the one or more anomalies is a critical failure; and confirming at least one of the generated anomaly codes based, at least in part, on one or more plots generated based on the generated anomaly codes and systems corresponding to the anomaly codes. Said generating the one or more anomaly codes may comprise generating the anomaly' codes based, at least in part, on residuals of predicted operational data. For Embodiment 3, the method may further comprise, in response determining that the failure is not a critical failure, continuing operation or re-starting operation of the downhole tool. For Embodiment 3, the method may further comprise utilizing combined data from the SoS dataset and from the generated anomaly codes to modify' at least one of operational procedures and tool state transition logic.