CROSS-REFERENCE TO RELATED APPLICATIONS

[0001] This application claims priority to United States Provisional Patent Application

Serial No. 62/749, 159, which was filed on October 23, 2018, and is incorporated herein by reference.

BACKGROUND

[0002] Various sensor devices and other network devices may be disposed throughout a drilling rig in order to collect information on the drilling rig. These devices may be connected to dedicated systems that control drilling equipment, monitor the performance of the drilling rig, and/or perform various maintenance operations with respect to the drilling rig. Traditionally, when data was collected for the drilling rig, a person was sent onsite to connect a physical device to the drilling rig network to manually download the data. This manual offloading process was problematic as drilling rigs are often located in remote locations. Likewise, traditional data upload mechanisms are ill-equipped to handle the volume of data collected at a modem drilling rig. Thus, data processing infrastructure in drilling rigs is desired that can enable automated offloading of drilling rig data and an accurate data representation of the drilling rig network using the drilling rig data.

SUMMARY

[0003] In general, in one aspect, embodiments relate to a method that includes obtaining, by a data uploader, processed rig data over a drilling management network. The processed rig data is a subset of rig equipment data that corresponds to a time period of the rig equipment data. The method further includes determining, by the data uploader, whether a data connection from the drilling management network to a remote location satisfies a predetermined criterion. The method further includes transmitting, by the data uploader, the processed rig data to the remote location in response to determining that the data connection satisfies the predetermined criterion.

[0004] In general, in one aspect, embodiments relate to a method that includes obtaining, by a cloud server, processed rig data from a drilling management network over a data connection. The processed rig data is a subset of rig equipment data that corresponds to a time period of the rig equipment data. The method further includes reconstructing, by the cloud server, the rig equipment data using the processed rig data. The method further includes determining, by the cloud server, a control system that generated the rig equipment data for producing the processed rig data. The control system is disposed in the drilling management network. The method further includes storing, by the cloud server, the rig equipment data in a data channel associated with the control system. The method further includes determining, by the cloud server and using the data channel, a data analysis of the control system.

[0005] In general, in one aspect, embodiments relate to a system that includes a drilling management network including various control systems and various network elements. The system further includes a data uploader coupled to the drilling management network. The data uploader transmits processed rig data to a remote location over a data connection in response to the data uploader determining that the data connection satisfies a predetermined criterion. The processed rig data is a subset of rig equipment data that corresponds to a time period of the rig equipment data. The rig equipment data is reconstructed using the processed rig data at the remote location. [0006] Other aspects of the disclosure will be apparent from the following description and the appended claims.

BRIEF DESCRIPTION OF DRAWINGS

[0007] FIGs. 1, 2, and 3 show systems in accordance with one or more embodiments of the technology.

[0008] FIG. 4 shows a flowchart in accordance with one or more embodiments of the technology.

[0009] FIG. 5 shows an example in accordance with one or more embodiments of the technology.

[0010] FIG. 6 shows a flowchart in accordance with one or more embodiments of the technology.

[0011] FIGs. 7.1 and 7.2 show a computing system in accordance with one or more embodiments of the technology.

DETAILED DESCRIPTION

[0012] Specific embodiments of the technology will now be described in detail with reference to the accompanying figures. Like elements in the various figures are denoted by like reference numerals for consistency.

[0013] In the following detailed description of embodiments of the technology, numerous specific details are set forth in order to provide a more thorough understanding of the technology. However, it will be apparent to one of ordinary skill in the art that the technology may be practiced without these specific details. In other instances, well-known features have not been described in detail to avoid unnecessarily complicating the description. [0014] Throughout the application, ordinal numbers (e.g., first, second, third, etc.) may be used as an adjective for an element (i.e., any noun in the application). The use of ordinal numbers is not to imply or create any particular ordering of the elements nor to limit any element to being only a single element unless expressly disclosed, such as by the use of the terms "before", "after", "single", and other such terminology. Rather, the use of ordinal numbers is to distinguish between the elements. By way of an example, a first element is distinct from a second element, and the first element may encompass more than one element and succeed (or precede) the second element in an ordering of elements.

[0015] Various embodiments are directed to an automated data upload mechanism that brings drilling management data to a remote device, such as a central cloud server. In particular, embodiments are directed to automating a data upload process by using a data upload mechanism over a data connection to a remote location, such as a satellite or cellular link. In some embodiments, for example, a data processing architecture on the drilling management network may transmit bulk data continuously over the remote connection a little bit at a time, i.e., as individual data subsets of a larger data transmission of rig equipment data. As such, the data processing architecture may convert data acquired by the drilling management network into l-minute compressed data files. Specifically, these compressed data files may contains l-minute worth of all data channels monitored by a historian.

[0016] In the data packaging system, for example, a historian may collect data, such as sensor data, from a drilling management network. The historian data may be broken into a series of small data chunks (e.g., timed snapshots) before each of the smaller datasets is transmitted to a data staging system for processing. For example, the historian may automatically export data corresponding to small time intervals (e.g. 1 minute) to the data staging system. Breaking the historian data into small data chunks before transmission may allow the network to transmit large amount of data over a high latency, low band width connection. Since historian data may be recorded at different frequencies, typically lhz, or even higher, the historian data may also be resampled (e.g., at 0.5 hz) before dividing it into small data chunks. At the data staging system, the small data chunks may be compressed into various files, e.g., into zip files. While lossless data compression may be used, in some embodiments, lossy data compression techniques may also be used.

[0017] Moreover, various terms are used in the disclosure, such as“small data chunks,”“subsets,”“subset data,” and“smaller subsets.” These terms may be one and the same. For example, these terms may describe a small size of collected data, e.g., by a historian, that is extracted, processed and transmitted to a remote location individually at a time.

[0018] Furthermore, in some embodiments, the data processing architecture takes into account various limitations and constraints of a drilling management network and the data connection link that communicates outside the network. Thus, by processing the rig data in a way to move the data more efficiently through the rig network and to the cloud, large amounts of data may be offloaded from the drilling management network. For example, the data processing architecture may include different computer systems to do very specific tasks. For example, what happens if the cloud upload computer is offline. The computer system packaging and compressing the data files may stop, while operations are ongoing around the drilling management network. By providing a staging area for transmitting processed rig data, a data generation computer that produces rig equipment data may operate independently of a data uploader that transmits the processed rig data ln short, the data processing architecture may use the notion of separation of concerns to keep key functionalities isolated from each other. [0019] FIG. 1 shows a block diagram of a system in accordance with one or more embodiments. FIG. 1 shows a drilling system (10) according to one or more embodiments. Drill string (58) is shown within borehole (46). Borehole (46) may be located in the earth (40) having a surface (42). Borehole (46) is shown being cut by the action of drill bit (54). Drill bit (54) may be disposed at the far end of the bottom hole assembly (56) that is attached to and forms the lower portion of drill string (58). Bottom hole assembly (56) may include a number of devices including various subassemblies. Measurement-while-drilling (MWD) subassemblies may be included in subassemblies (62). Examples of MWD measurements may include survey data (direction information such as inclination and azimuth), downhole pressure (internal pressure, annular pressure), resistivity, density, and porosity. Subassemblies (62) may also include a subassembly for measuring torque and weight on the drill bit (54). The signals from the subassemblies (62) may be processed in a processor (66). After processing, the information from processor (66) may be communicated to pulser assembly (64). Pulser assembly (64) may convert the information from the processor (66) into pressure pulses in the drilling fluid. The pressure pulses may be generated in a particular pattern which represents the data from the subassemblies (62). The pressure pulses may travel upwards through the drilling fluid in the central opening in the drill string and towards the surface system. The subassemblies in the bottom hole assembly (56) may further include a turbine or motor for providing power for rotating and steering drill bit (54). Alternatively, the signals from subassembly 62 may be transmitted to the surface via other telemetry means, such as EM telemetry, or wired drillpipe, etc.

[0020] The drilling rig (12) may include a derrick (68) and hoisting system, a rotating system, and/or a mud circulation system, for example. The hoisting system may suspend the drill string (58) and may include drawworks (70), fast line (71), crown block (75), drilling line (79), traveling block and hook (72), swivel (74), and/or deadline (77). The rotating system may include a kelly (76), a rotary table (88), and/or engines (not shown). The rotating system may impart a rotational force on the drill string (58). Likewise, the embodiments shown in FIG. 1 may be applicable to top drive drilling arrangements as well. Although the drilling system (10) is shown being on land, those of skill in the art will recognize that the described embodiments are equally applicable to marine environments as well.

[0021] The mud circulation system may pump drilling fluid down an opening in the drill string. The drilling fluid may be called mud, which may be a mixture of water and/or diesel fuel, special clays, and/or other chemicals. The mud may be stored in mud pit (78). The mud may be drawn into mud pumps (not shown), which may pump the mud though stand pipe (86) and into the kelly (76) through swivel (74), which may include a rotating seal. Likewise, the described technologies may also be applicable to underbalanced drilling. If underbalanced drilling is used, at some point prior to entering the drill string, gas may be introduced into the mud using an injection system (not shown).

[0022] The mud may pass through drill string (58) and through drill bit (54). As the cutting elements of the drill bit (54) grind and gouge the earth formation into cuttings, the mud may be ejected out of openings or nozzles in the drill bit (54). These jets of mud may lift the cuttings off the bottom of the hole and away from the drill bit (54), and up towards the surface in the annular space between drill string (58) and the wall of borehole (46).

[0023] At the surface, the mud and cuttings may leave the well through a side outlet at bellnipper (not shown) above blowout preventer (99) and through mud return line (not shown). Blowout preventer (99) comprises a pressure control device and associated seal. The mud return line may feed the mud into one or more separator (not shown) which may separate the mud from the cuttings. From the separator, the mud may be returned to mud pit (78) for storage and re-use.

[0024] Various sensor devices may be placed on the drilling rig (12) to take measurements of the rig equipment. In particular, a hookload may be measured by strain gauge hookload sensors (94) mounted on deadline (77), block position and the related block velocity may be measured by a block sensor (95) which may be part of the drawworks (70). Surface torque may be measured by a sensor device on the rotary table (88). In another embodiment, surface torque may be measured through instrumentation on or below the top drive, or through measuring top drive current. Standpipe pressure may be measured by pressure sensor (92), located on standpipe (86). Signals from these measurements may be communicated to a surface processor (96) or other network elements (not shown) disposed around the drilling rig (12). In addition, mud pulses traveling up the drillstring may be detected by pressure sensor (92). For example, pressure sensor (92) may include a transducer that converts the mud pressure into electronic signals. The pressure sensor (92) may be connected to surface processor (96) that converts the signal from the pressure signal into digital form, stores and demodulates the digital signal into useable MWD data. According to various embodiments described above, surface processor (96) may be programmed to automatically detect one or more rig states based on the various input channels described. Surface processor (96) may be programmed, for example, to carry out an automated event detection as described above. Surface processor (96) may transmit a particular rig state and/or event detection information to user interface system (97) which may be designed to warn various drilling personnel of events occurring on the rig and/or suggest activity to the drilling personnel to avoid specific events.

[0025] Turning to FIG. 2, FIG. 2 shows a block diagram of a system in accordance with one or more embodiments. As shown in FIG. 2, a drilling management network (230) may include a human machine interface (HMI) (e.g., HMI (233)), a historian (e.g., historian (234)), and various network elements (e.g., network elements (231)). The drilling management network (230) may further include rig equipment (e.g., rig equipment (232)) such as drawworks (70), top drive, mud pumps and other components described above in FIG. 1 and the accompanying description).

[0026] In one or more embodiments, a drilling management network includes a data uploader (e.g., data uploader (260)). For example, a data uploader may include hardware and/or software that includes functionality for transmitting processed rig data over a data connection (e.g., data connection (275)) to a remote location (e.g., cloud server (270)). The data connection may correspond to one or more security protocols that manage network traffic between the drilling management network and the remote location. The data connection may include data compression, data encryption and/or data transmission, for example. Likewise, the data uploader may correspond to multiple computer devices around the drilling management network. The data uploader may use a communication protocol, such as a message queuing telemetry transport (MQTT) protocol, to transmit data to the remote location. Further, the data uploader may monitor network traffic being transmitted over the data connection to determine whether a predetermined criterion is satisfied for transmitting processed rig data outside the network. In some embodiments, the remote location may be an Internet of Things (IoT) Hub.

[0027] Moreover, processed rig data may correspond to individual portions of a larger rig equipment dataset. For example, a rig equipment dataset may be divided into individual subsets based on different time periods or other methods of dividing data. The total processed rig data may include a large amount of data, e.g., several gigabytes of data transmitted per day. Accordingly, transferring processed rig data over the data connection may interfere with other network traffic responsible for operating a drilling management network, e.g., human operators sending control system commands and activities for monitoring a drilling rig remotely. Thus, the data uploader may determine a particular time and upload duration for transmitting data to a cloud environment that does not interfere with other activities. In some embodiments, the data uploader transmits large amounts of data very fast over the data connection. In particular, this data transfer may allow data scientists, subject matter experts, maintenance engineers, remote support engineers, etc., to have better visibility of control systems and various operations on the drilling management network. Based on receipt of the processed rig data, remote entities may provide better applications and support to a drilling rig using the processed rig data. In some embodiments, a data connection between a drilling management network and a remote location is a high-latency low- bandwidth connection, e.g., a satellite link or cellular connection.

[0028] In some embodiments, a data uploader is coupled to a buffer. For example, the buffer may be a physical memory storage that stores processed rig data as well as other data. As such, the buffer may store processed rig data prior to transmission across a data connection to a cloud server. The buffer may also be a fixed memory location in hardware and/or a virtual data buffer on a network. In some embodiments, when a data connection is being used to transmit other besides processed rig data, the data uploader may wait until the data connection drops below a predetermined amount of throughput before transmitting processed rig data. In some embodiments, data transfers across the data connections are scheduled according to a predetermined criterion, e.g., in a queue, and processed rig data may reside in a buffer until the scheduled time for the data transfer.

[0029] In one or more embodiments, a server at a remote location (e.g., cloud server (270)) includes functionality for communicating with a drilling management network (e.g., drilling management network (230)). For example, the remote location may be an Internet location or merely a network location that is offsite from a drilling rig. In some embodiments, the data uploader communicates with a server at a remote location to coordinate data transfers of processed rig data. In some embodiments, the server is a cloud server. For example, a cloud server may be hardware and/or software that provides a logical server built, hosted and delivered through a cloud computing platform over the Internet.

[0030] The drilling management network (230) may further include various drilling operation control systems (e.g., drilling operation control systems (235)) and various maintenance control systems (e.g., maintenance control systems (236)). Drilling operation control systems and/or maintenance control systems may include, for example, programmable logic controllers (PLCs) that include hardware and/or software with functionality to control one or more processes performed by performed by the rig equipment (232), including, but not limited to the components described in FIG. 1. Specifically, a programmable logic controller may control valve states, fluid levels, pipe pressures, rotary speeds, and/or pressure releases throughout a drilling rig. In particular, a programmable logic controller may be a ruggedized computer system with functionality to withstand vibrations, extreme temperatures, wet conditions, and/or dusty conditions, for example, around a drilling rig. Without loss of generality, the term“control system” may refer to a drilling operation control system that is used to operate and control the rig equipment, a drilling data acquisition and monitoring system that is used to acquire drilling process and equipment data and to monitor the operation of the drilling process, or a drilling interpretation software system that is used to analyze and understand drilling events and progress.

[0031] Keeping with FIG. 2, sensors may include hardware and/or software that includes functionality to obtain one or more sensor measurements, e.g., a sensor measurement of an environment condition proximate the sensors (220). The sensors may process the sensor measurements into various types of sensor data. For example, the sensors may include functionality to convert sensor measurements obtained from sensor data into a communication protocol format for the drilling management network (230). The sensors may include pressure sensors, torque sensors, rotary switches, weight sensors, position sensors, microswitches, etc. The sensors may include smart sensors. In some embodiments, the sensors may include sensor circuitry without a communication interface or memory. For example, the sensors may be coupled with a computer device that transmits sensor data over a drilling management network.

[0032] In one or more embodiments, sensor data may be sent over the drilling management network (230) in data packets using a communication protocol. Sensor data may include sensor measurements, processed sensor data based on one or more underlying sensor measurements or parameters, metadata regarding the sensors such as timestamps and sensors identification information, content attributes, sensor configuration information such as offset, conversion factors, etc. As such, the sensors (220) may act as a network node and/or an endpoint on the drilling management network (230).

[0033] In one or more embodiments, the human machine interface (233) may be hardware and/or software coupled to the drilling management network (230). For example, the HMI (233) may allow the operator to interact with the drilling system, e.g., to send a command to operate an equipment, or to view sensor information from rig equipment. The human machine interface may include functionality for presenting data and/or receiving inputs from a user regarding various drilling operations and/or maintenance operations. For example, a human machine interface may include software to provide a graphical user interface (GUI) for presenting data and/or receiving control commands for operating a drilling rig. A network element may refer to various hardware components within a network, such as switches, routers, hubs or any other logical entities for uniting one or more physical devices on the network. In particular, a network element, the human machine interface, and/or the historian may be a computing system similar to the computing system (700) described in FIGs. 7.1 and 7.2, and the accompanying description.

[0034] Turning to FIG. 3, FIG. 3 shows a block diagram of a system in accordance with one or more embodiments. As shown in FIG. 3, a data uploader (e.g., data uploader A (360)) may be coupled to a historian (e.g., historian A (334)) and one or more control systems (e.g., control system N (335)). More specifically, rig equipment data (e.g., rig equipment data A (311)) may be generated by a control system (e.g., control system N (335)). The rig equipment data may include sensor measurements acquired by a sensor device (e.g., sensor device M (320)) that is further processed by the control system or relayed as raw sensor data over a drilling management network. Likewise, rig equipment data may also correspond to quality control data, drilling operation parameters, maintenance parameters, control system notifications, and other data generated by control systems that may not directly relate to drilling operations. The rig equipment data may be transmitted to one or more components within a drilling management network for further processing (e.g., historian A (334)). In some embodiments, prior to rig equipment data being transmitted off a drilling management network, the rig equipment data may be processed to produce various data subsets (e.g., subset A of rig equipment data A (312)). Thus, a data subset may provide a portion of a representation of one or more control system aspects without unduly burdening traffic on the drilling management network and/or data connections to remote locations outside the drilling management network.

[0035] Keeping with FIG. 3, the data uploader may include functionality for transmitting processed rig data to a cloud server (e.g., cloud server X (370)) remote from a drilling rig site. For example, once processed rig data is transmitted to a cloud server, the processed rig data may be relayed to a staging area, e.g., a virtual machine, for further processing. In the staging area, various pre-processing techniques may be applied to the processed rig data, such as parsing and data mapping, before the respective data is deposited in data storage. While processed rig data may undergo one or more additional processing techniques upon reaching the cloud server, for convenience, processed rig data may refer to either rig data processed on a drilling management network as well as data that has been further processed while in the cloud.

[0036] In one or more embodiments, processed rig data is stored in a cloud storage (e.g., cloud storage server (371)). Once in cloud storage, the data may be further processed according to a time trigger or event trigger. Once processed according to a time trigger, for example, the processed rig data may be stored and managed in a data ingestion automation device. For example, a data ingestion automation device may be a software platform that provides automated data integration and data management services for transforming raw data into data read for consumption by various applications, e.g., applications operated by user devices (e.g., user device (390)). From the data ingestion automation device, the data may be uploaded to a data warehouse for long term storage. In particular, computer devices and data analysis services (e.g., data analytics engine (372)) may access the data warehouse for various application, e.g., performing visualization operations and data analyses with respect to the data in the data warehouse.

[0037] While FIGs. 1, 2, and 3 show various configurations of components, other configurations may be used without departing from the scope of the disclosure. For example, various components in FIGs. 1 and 2 may be combined to create a single component. As another example, the functionality performed by a single component may be performed by two or more components. [0038] Turning to FIG. 4, FIG. 4 shows a flowchart in accordance with one or more embodiments. Specifically, FIG. 4 describes a general method for managing a data upload from a drilling management network. One or more blocks in FIG. 4 may be performed by one or more components (e.g., data uploader (260)) as described in FIGs. 1, 2, and/or 3. While the various blocks in FIG. 4 are presented and described sequentially, one of ordinary skill in the art will appreciate that some or all of the blocks may be executed in different orders, may be combined or omitted, and some or all of the blocks may be executed in parallel. Furthermore, the blocks may be performed actively or passively.

[0039] In Block 400, processed rig data is obtained over a drilling management network in accordance with one or more embodiments. For example, a drilling management network may implement a data processing architecture to relay rig equipment data from network devices and control systems to one or more locations for processing, such as at a historian. For example, a historian may collect various subsets or portions of the historian’s data and then transmit the data subsets to a data staging system for processing. For example, a data subset may include a range of rig equipment data from a particular time period. Accordingly, data from different time periods can be transmitted as smaller data chunks or data packages to be reassembled at a remote location outside the drilling management network. In some embodiments, for example, the historian may automatically export data subsets of rig equipment data corresponding to 1 minute time periods to the data staging system. The data staging system may be a data uploader or a different network device in a drilling management network. This data sampling of the historian’s data may reduce the data bulk to a more manageable size.

[0040] In some embodiments, the subset size of rig equipment data is dynamically adjusted for generating processed rig data. For example, a data uploader may determine one or more network performance levels, e.g., of the drilling management network or over a data connection to a remote location. Based on the network performance, the subset size may be increased or decreased accordingly. Likewise, the data uploader may analyze past network performance to determine one or more future subset sizes for the processed rig data.

[0041] In some embodiments, rig equipment data is compressed. At a data staging system, which may be a data uploader or a different location in the drilling management network, data subsets may be compressed into various files, e.g., into zip files. While lossless data compression may be used, in some embodiments, lossy data compression techniques may be used as well. The compressed data files may be transmitted to another computer or a different storage area of the same computer for transmission to data storage in a remote device.

[0042] A software application, e.g., on a data uploader, may sort the compressed data files according to a predetermined upload queue. Over an MQTT transmission, the software may upload the oldest file in the upload queue to a blob container or other data storage in a remote device. Once a file is uploaded outside the drilling management network, the compressed data file may be moved to a“processed” area to identify that the file has been uploaded outside the drilling management network. In some embodiments, security rules are implemented by a security protocol with respect to the computer that transmits the data file to the remote device. Examples of security rules to ensure secure communication between the drilling management network and the remote device may include using various forms of authentication, such as unit client IDs, username and passwords, or x509 client certificates. Furthermore, the actual data files to be transmitted may be protected by using TLS security. [0043] In some embodiments, processed rig data corresponds to sampled data. For example, a historian may obtain various data points from the rig equipment data according to a sampling interval and discard the rest of the data. Thus, where sampling occurs, only a portion of the historian’s data may be used to generate processed rig data and subsequently transmitted outside the drilling management network. On the other hand, in many embodiments, the processed rig data transmitted by a data uploader to a cloud server may include all of the rig equipment data divided into small manageable data transmissions.

[0044] In Block 410, a determination is made whether a data connection to a remote location satisfies a predetermined criterion in accordance with one or more embodiments. While processed rig data is waiting in a buffer or other staging area to be uploaded to a remote location, a data uploader may analyze a data connection to determine whether to send the data outside the network. The data uploader’ s analysis may be based on one or more predetermined criteria.

[0045] In one embodiment, a predetermined criterion may correspond to whether there is sufficient connectivity to a remote location to transmit one or more data files. In another embodiment, the predetermined criterion may be a predetermined time, e.g., at 2:00 AM each Monday or after a drilling management network notifies the data uploader that communication over the data connection is no longer necessary for drilling operations. The predetermined time may also be when drilling operations and/or maintenance operations are detected as being complete for the day.

[0046] In another embodiment, the predetermined criterion corresponds to a priority queue, e.g., processed rig data may be assigned a priority level that is compared to priority levels of other types of data transmitted across a data connection. Thus, a priority identifier that may be found in metadata associated with processed rig data. The priority identifier may be used accordingly to determine when to transmit processed rig data over a data connection. As such, a data uploader may analyze data in a buffer and determine whether one priority level is greater than the priority levels of other data in the buffer. When the processed rig data has the highest priority, the data uploader may then transmit the processed rig data accordingly.

[0047] In Block 420, processed rig data is transmitted to a remote location in response to determining that a data connection satisfies a predetermined criterion in accordance with one or more embodiments. Once any predetermined criteria are satisfied, the data uploader may transmit the processed rig data to one or more remote locations, such as a data container at a remote location. At the remote location, the processed rig data may be used with other processed rig data to reconstruct the original rig equipment dataset. After the processed rig data is successfully streamed, the processed rig data may be moved to a processed area. For example, the processed area may be another staging area that stores compressed data files that have finished streaming.

[0048] Turning to FIG. 5, FIG. 5 provides an example of generating processed rig data X (580). The following example is for explanatory purposes only and not intended to limit the scope of the disclosure. In FIG. 5, a drawworks control system X (535) obtains various sensor measurements, i.e., weight on bit (WOB) measurements (501), rate of penetration (ROP) measurements (502), and top drive torque measurements (503). From the various rig equipment data collected by the drawworks control system X (535), a query function (530) for determining data of interest may be performed on the rig equipment data. In particular, the rig equipment data may be collected at a historian (not shown) that performs the query function (530). The query function (530) may also be performed in response to a data request from a user device located at a remote location from the drawworks control system X (535). In FIG. 5, the query function (530) identifies the ROP measurements (502) as the desired rig equipment data. [0049] Keeping with FIG. 5, the ROP measurements (535) are processed using a slicing function (540). For example, the slicing function may generate various smaller portions of the ROP measurements (535) based on the user device’s request or automatically by a historian or other network device. For example, the rig equipment data may be divided according a predetermined time period length, such as a full minute of measurements. These divided portions may be a series of smaller subsets that are eventually transferred from a drilling rig to a remote location. For example, the transfer of all the smaller subsets may occur after a complete historian dataset is sliced into a number of smaller subsets. By transmitting a smaller subset at a given time, network limitations (e.g., lack of bandwidth, unreliable connection, etc.) may be accommodated and the smaller subsets may be reliably sent over time.

[0050] In some embodiments, the slicing function (540) may generate subsets of different sizes over various ranges of time. For example, if network performance over a data connection has good throughput, the slicing function (540) may generate larger subsets. If the data connection is a poor connection, the slicing function (540) may generate smaller subsets. Likewise, in some embodiments process rig data is sampled, e.g., according to a sampling interval or only collect measurements at the same time as a notification was received that a failure occurred in the drawworks control system X (535).

[0051] After obtaining a data subset, the data subset may undergo a file generation stage (555). Here, the data subset may undergo a compression function (551) where the data subset undergoes lossy or lossless compression. In a metadata generation function (552), metadata is generated that maps the data subset with the drawworks control system X (535). Using the compressed data and the metadata, a data file generation function (553) may be performed that produces processed rig data X (580). [0052] Turning to FIG. 6, FIG. 6 shows a flowchart in accordance with one or more embodiments. Specifically, FIG. 6 describes a general method for processing rig data obtained from a drilling management network. One or more blocks in FIG. 6 may be performed by one or more components (e.g., cloud server (270)) as described in FIGs. 1, 2, and/or 3. While the various blocks in FIG. 6 are presented and described sequentially, one of ordinary skill in the art will appreciate that some or all of the blocks may be executed in different orders, may be combined or omitted, and some or all of the blocks may be executed in parallel. Furthermore, the blocks may be performed actively or passively.

[0053] In Block 600, processed rig data is obtained from a data uploader in a drilling management network in accordance with one or more embodiments. For example, the processed rig data may be obtained using a process similar to the one described above in FIG. 4 and the accompanying description.

[0054] In Block 605, rig equipment data is reconstructed using processed rig data in accordance with one or more embodiments. For example, different sets of processed rig data may be matched in order to be combined into a larger rig equipment dataset. Likewise, processed rig data may be decompressed from individual data files for insertion into a database or a larger dataset. Likewise, where the processed rig data corresponds to sampled data, one or more interpolation and/or extrapolation algorithms may be applied to the processed rig data to produce a representation of the original rig equipment data. In particular, the data files for processed rig data may be further processed at a remote location. For example, one or more cloud servers may perform data clean-up, preparation, and mapping of the processed rig data. In a cleaning area, the compressed data may undergo decompression, e.g., being unzipped if the processed rig data includes zip files. Accordingly, the decompressed data files may be aggregated according to various data channels. [0055] In Block 610, a control system is determined that is associated with reconstructed rig equipment data in accordance with one or more embodiments. For example, metadata associated with the processed rig data may be read by a server to map which control system or rig equipment generated the original rig equipment data prior to processing. Thus, the reconstructed rig equipment data may be matched with the corresponding control system or rig equipment for later analysis and/or storage. Likewise, the control system may be identified based on a time that the data uploader transmits the processed rig data. For example, the data uploader may transmit data subsets for different control systems at different times. Depending on the time of the data transfer, a cloud server may determine the corresponding control system for the processed rig data. In some embodiments, processed rig data is associated with other network devices on a drilling management network besides a particular control system.

[0056] In Block 620, reconstructed rig equipment data is stored in a data channel associated with a control system in accordance with one or more embodiments. For example, reconstructed rig equipment data may be assigned a data channel based on which control system is determined as the source of the original rig equipment data. Data channels may correspond to different tags, e.g., a tag for a blowout preventer, a tag for a bottom hole assembly, a tag for a MWD subassembly, etc. Data channels may also correspond to different folders and other methods of organizing data on a server or in a cloud computing environment. Thus, reconstructed data regarding different control systems operating in the drilling management network may be stored together in a data channel, e.g., a SQL data warehouse, and analyzed later.

[0057] In Block 630, one or more data analyses are performed using a data channel for a control system in accordance with one or more embodiments. For example, a server may access reconstructed rig equipment data in a data warehouse in order to perform one or more visualizations of a control system located in a drilling management network. Likewise, different types of diagnostic tests may be performed using the reconstructed rig equipment data, such as quality control analyses, cybersecurity analyses, as well as various drilling production analyses regarding a drilling rig. As such, the results of a data analysis may be transmitted by a cloud server to a user device.

[0058] Embodiments may be implemented on a computing system. Any combination of mobile, desktop, server, router, switch, embedded device, or other types of hardware may be used. For example, as shown in FIG. 7.1, the computing system (700) may include one or more computer processors (702), non-persistent storage (704) (e.g., volatile memory, such as random access memory (RAM), cache memory), persistent storage (706) (e.g., a hard disk, an optical drive such as a compact disk (CD) drive or digital versatile disk (DVD) drive, a flash memory, etc.), a communication interface (712) (e.g., Bluetooth interface, infrared interface, network interface, optical interface, etc.), and numerous other elements and functionalities.

[0059] The computer processor(s) (702) may be an integrated circuit for processing instructions. For example, the computer processor(s) may be one or more cores or micro-cores of a processor. The computing system (700) may also include one or more input devices (710), such as a touchscreen, keyboard, mouse, microphone, touchpad, electronic pen, or any other type of input device.

[0060] The communication interface (712) may include an integrated circuit for connecting the computing system (700) to a network (not shown) (e.g., a local area network (FAN), a wide area network (WAN) such as the Internet, mobile network, or any other type of network) and/or to another device, such as another computing device.

[0061] Further, the computing system (700) may include one or more output devices (708), such as a screen (e.g., a liquid crystal display (FCD), a plasma display, touchscreen, cathode ray tube (CRT) monitor, projector, or other display device), a printer, external storage, or any other output device. One or more of the output devices may be the same or different from the input device(s). The input and output device(s) may be locally or remotely connected to the computer processor(s) (702), non-persistent storage (704), and persistent storage (706). Many different types of computing systems exist, and the aforementioned input and output device(s) may take other forms.

[0062] Software instructions in the form of computer readable program code to perform embodiments of the disclosure may be stored, in whole or in part, temporarily or permanently, on a non-transitory computer readable medium such as a CD, DVD, storage device, a diskette, a tape, flash memory, physical memory, or any other computer readable storage medium. Specifically, the software instructions may correspond to computer readable program code that, when executed by a processor(s), is configured to perform one or more embodiments of the disclosure.

[0063] The computing system (700) in FIG. 7.1 may be connected to or be a part of a network. For example, as shown in FIG. 7.2, the network (720) may include multiple nodes (e.g., node X (722), node Y (724)). Each node may correspond to a computing system, such as the computing system shown in FIG. 7.1, or a group of nodes combined may correspond to the computing system shown in FIG. 7.1. By way of an example, embodiments of the disclosure may be implemented on a node of a distributed system that is connected to other nodes. By way of another example, embodiments of the disclosure may be implemented on a distributed computing system having multiple nodes, where each portion of the disclosure may be located on a different node within the distributed computing system. Further, one or more elements of the aforementioned computing system (700) may be located at a remote location and connected to the other elements over a network. [0064] Although not shown in FIG. 7.2, the node may correspond to a blade in a server chassis that is connected to other nodes via a backplane. By way of another example, the node may correspond to a server in a data center. By way of another example, the node may correspond to a computer processor or micro core of a computer processor with shared memory and/or resources.

[0065] The nodes (e.g., node X (722), node Y (724)) in the network (720) may be configured to provide services for a client device (726). For example, the nodes may be part of a cloud computing system. The nodes may include functionality to receive requests from the client device (726) and transmit responses to the client device (726). The client device (726) may be a computing system, such as the computing system shown in FIG. 7.1. Further, the client device (726) may include and/or perform all or a portion of one or more embodiments of the disclosure.

[0066] The computing system or group of computing systems described in FIGs.

7.1 and 7.2 may include functionality to perform a variety of operations disclosed herein. For example, the computing system(s) may perform communication between processes on the same or different systems. A variety of mechanisms, employing some form of active or passive communication, may facilitate the exchange of data between processes on the same device. Examples representative of these inter-process communications include, but are not limited to, the implementation of a file, a signal, a socket, a message queue, a pipeline, a semaphore, shared memory, message passing, and a memory-mapped file. Further details pertaining to a couple of these non-limiting examples are provided below.

[0067] Based on the client-server networking model, sockets may serve as interfaces or communication channel end-points enabling bidirectional data transfer between processes on the same device. Foremost, following the client- server networking model, a server process (e.g., a process that provides data) may create a first socket object. Next, the server process binds the first socket object, thereby associating the first socket object with a unique name and/or address. After creating and binding the first socket object, the server process then waits and listens for incoming connection requests from one or more client processes (e.g., processes that seek data). At this point, when a client process wishes to obtain data from a server process, the client process starts by creating a second socket object. The client process then proceeds to generate a connection request that includes at least the second socket object and the unique name and/or address associated with the first socket object. The client process then transmits the connection request to the server process. Depending on availability, the server process may accept the connection request, establishing a communication channel with the client process, or the server process, busy in handling other operations, may queue the connection request in a buffer until the server process is ready. An established connection informs the client process that communications may commence ln response, the client process may generate a data request specifying the data that the client process wishes to obtain. The data request is subsequently transmitted to the server process. Upon receiving the data request, the server process analyzes the request and gathers the requested data. Finally, the server process then generates a reply including at least the requested data and transmits the reply to the client process. The data may be transferred, more commonly, as datagrams or a stream of characters (e.g., bytes).

[0068] Shared memory refers to the allocation of virtual memory space in order to substantiate a mechanism for which data may be communicated and/or accessed by multiple processes ln implementing shared memory, an initializing process first creates a shareable segment in persistent or non-persistent storage. Post creation, the initializing process then mounts the shareable segment, subsequently mapping the shareable segment into the address space associated with the initializing process. Following the mounting, the initializing process proceeds to identify and grant access permission to one or more authorized processes that may also write and read data to and from the shareable segment. Changes made to the data in the shareable segment by one process may immediately affect other processes, which are also linked to the shareable segment. Further, when one of the authorized processes accesses the shareable segment, the shareable segment maps to the address space of that authorized process. Often, one authorized process may mount the shareable segment, other than the initializing process, at any given time.

[0069] Other techniques may be used to share data, such as the various data described in the present application, between processes without departing from the scope of the disclosure. The processes may be part of the same or different application and may execute on the same or different computing system.

[0070] Rather than or in addition to sharing data between processes, the computing system performing one or more embodiments of the disclosure may include functionality to receive data from a user. For example, in one or more embodiments, a user may submit data via a graphical user interface (GUI) on the user device. Data may be submitted via the graphical user interface by a user selecting one or more graphical user interface widgets or inserting text and other data into graphical user interface widgets using a touchpad, a keyboard, a mouse, or any other input device. In response to selecting a particular item, information regarding the particular item may be obtained from persistent or non-persistent storage by the computer processor. Upon selection of the item by the user, the contents of the obtained data regarding the particular item may be displayed on the user device in response to the user’s selection.

[0071] By way of another example, a request to obtain data regarding the particular item may be sent to a server operatively connected to the user device through a network. For example, the user may select a uniform resource locator (URL) link within a web client of the user device, thereby initiating a Hypertext Transfer Protocol (HTTP) or other protocol request being sent to the network host associated with the URL. In response to the request, the server may extract the data regarding the particular selected item and send the data to the device that initiated the request. Once the user device has received the data regarding the particular item, the contents of the received data regarding the particular item may be displayed on the user device in response to the user’s selection. Further to the above example, the data received from the server after selecting the URL link may provide a web page in Hyper Text Markup Language (HTML) that may be rendered by the web client and displayed on the user device.

[0072] Once data is obtained, such as by using techniques described above or from storage, the computing system, in performing one or more embodiments of the disclosure, may extract one or more data items from the obtained data. For example, the extraction may be performed as follows by the computing system (700) in FIG. 7.1. First, the organizing pattern (e.g., grammar, schema, layout) of the data is determined, which may be based on one or more of the following: position (e.g., bit or column position, Nth token in a data stream, etc.), attribute (where the attribute is associated with one or more values), or a hierarchical/tree structure (consisting of layers of nodes at different levels of detail— such as in nested packet headers or nested document sections). Then, the raw, unprocessed stream of data symbols is parsed, in the context of the organizing pattern, into a stream (or layered structure) of tokens (where each token may have an associated token“type”).

[0073] Next, extraction criteria are used to extract one or more data items from the token stream or structure, where the extraction criteria are processed according to the organizing pattern to extract one or more tokens (or nodes from a layered structure). For position-based data, the token(s) at the position(s) identified by the extraction criteria are extracted. For attribute/value-based data, the token(s) and/or node(s) associated with the attribute(s) satisfying the extraction criteria are extracted. For hierarchical/layered data, the token(s) associated with the node(s) matching the extraction criteria are extracted. The extraction criteria may be as simple as an identifier string or may be a query presented to a structured data repository (where the data repository may be organized according to a database schema or data format, such as XML).

[0074] The extracted data may be used for further processing by the computing system. For example, the computing system of FIG. 7.1, while performing one or more embodiments of the disclosure, may perform data comparison. Data comparison may be used to compare two or more data values (e.g., A, B). For example, one or more embodiments may determine whether A > B, A = B, A != B, A < B, etc. The comparison may be performed by submitting A, B, and an opcode specifying an operation related to the comparison into an arithmetic logic unit (ALU) (i.e., circuitry that performs arithmetic and/or bitwise logical operations on the two data values). The ALU outputs the numerical result of the operation and/or one or more status flags related to the numerical result. For example, the status flags may indicate whether the numerical result is a positive number, a negative number, zero, etc. By selecting the proper opcode and then reading the numerical results and/or status flags, the comparison may be executed. For example, in order to determine if A > B, B may be subtracted from A (i.e., A - B), and the status flags may be read to determine if the result is positive (i.e., if A > B, then A - B > 0). In one or more embodiments, B may be considered a threshold, and A is deemed to satisfy the threshold if A = B or if A > B, as determined using the ALU. In one or more embodiments of the disclosure, A and B may be vectors, and comparing A with B includes comparing the first element of vector A with the first element of vector B, the second element of vector A with the second element of vector B, etc. In one or more embodiments, if A and B are strings, the binary values of the strings may be compared.

[0075] The computing system in FIG. 7.1 may implement and/or be connected to a data repository. For example, one type of data repository is a database. A database is a collection of information configured for ease of data retrieval, modification, re-organization, and deletion. Database Management System (DBMS) is a software application that provides an interface for users to define, create, query, update, or administer databases.

[0076] The user, or software application, may submit a statement or query into the DBMS. Then the DBMS interprets the statement. The statement may be a select statement to request information, update statement, create statement, delete statement, etc. Moreover, the statement may include parameters that specify data, or data container (database, table, record, column, view, etc.), identifier(s), conditions (comparison operators), functions (e.g. join, full join, count, average, etc.), sort (e.g. ascending, descending), or others. The DBMS may execute the statement. For example, the DBMS may access a memory buffer, a reference or index a file for read, write, deletion, or any combination thereof, for responding to the statement. The DBMS may load the data from persistent or non-persistent storage and perform computations to respond to the query. The DBMS may return the result(s) to the user or software application.

[0077] The computing system of FIG. 7.1 may include functionality to present raw and/or processed data, such as results of comparisons and other processing. For example, presenting data may be accomplished through various presenting methods. Specifically, data may be presented through a user interface provided by a computing device. The user interface may include a GUI that displays information on a display device, such as a computer monitor or a touchscreen on a handheld computer device. The GUI may include various GUI widgets that organize what data is shown as well as how data is presented to a user. Furthermore, the GUI may present data directly to the user, e.g., data presented as actual data values through text, or rendered by the computing device into a visual representation of the data, such as through visualizing a data model.

[0078] For example, a GUI may first obtain a notification from a software application requesting that a particular data object be presented within the GUI. Next, the GUI may determine a data object type associated with the particular data object, e.g., by obtaining data from a data attribute within the data object that identifies the data object type. Then, the GUI may determine any rules designated for displaying that data object type, e.g., rules specified by a software framework for a data object class or according to any local parameters defined by the GUI for presenting that data object type. Finally, the GUI may obtain data values from the particular data object and render a visual representation of the data values within a display device according to the designated rules for that data object type.

[0079] Data may also be presented through various audio methods. In particular, data may be rendered into an audio format and presented as sound through one or more speakers operably connected to a computing device.

[0080] Data may also be presented to a user through haptic methods. For example, haptic methods may include vibrations or other physical signals generated by the computing system. For example, data may be presented to a user using a vibration generated by a handheld computer device with a predefined duration and intensity of the vibration to communicate the data.

[0081] The above description of functions presents only a few examples of functions performed by the computing system of FIG. 7.1 and the nodes and/or client device in FIG. 7.2. Other functions may be performed using one or more embodiments of the disclosure. [0082] While the technology has been described with respect to a limited number of embodiments, those skilled in the art, having benefit of this disclosure, will appreciate that other embodiments can be devised which do not depart from the scope of the technology as disclosed herein. Accordingly, the scope of the technology should be limited only by the attached claims.