Systems and methods to facilitate a request for oilfield services using a data transfer protocol

Facilitating a request for oilfield services. At least some of the illustrative embodiments are systems including a data store to receive a services request from a services requestor through a data transfer protocol interface and update an entry in the data store to indicate one or more parameters associated with the services request. The system also includes a monitor tool and a configuration file creator. The monitor tool detects an update to the data store and, if an update is detected, verifies the correctness of the services request that corresponds to the detected update. The configuration file creator detects an update to the data store and, if an update is detected, identifies an affected receiving system, determines a configuration file format for the affected receiving system, and generates a configuration file for the services request having the determined format for the affected receiving system.

CROSS-REFERENCE TO RELATED APPLICATIONS

BACKGROUND

Oilfield equipment or services may need to be ordered for use at a hydrocarbon wellsite during various stages of hydrocarbon operations such as drilling, completion, production and the like. In such a situation, an order is placed with a vendor, for example, by a phone call to the vendor or by emailing a spreadsheet to the vendor. The vendor then manually enters the order in the receiving system for processing.

However, the above procedure for ordering services and processing orders for services is prone to errors. For example, the requestor may order a component or tool that is incompatible with other components or tools currently being used at the rig site (e.g., incorrect dimensions, incorrect tool for a particular task). In such a case, no reliable safeguard exists to correct the erroneous order prior to sending the order to a vendor or receiver. As another example, the requestor may send a component order to a receiver that is incapable of processing or filling at least a portion of the order (e.g., certain components have been ordered from a receiver that does not or cannot provide those components). In such a case, a delay may result before the requestor is made aware of the erroneous order and can reorder the components from the proper receiver. As yet another example, the receiver may require that orders be formatted in a specific way or that certain information be provided by the requestor for certain components. The requestor may mistakenly use the wrong format or not include all the required information regarding a particular component, further causing confusion and delays. In the above situations, various mistakes may not be discovered until after the receiver has supplied the requestor with the ordered services, resulting in increased costs and long delays to various operations as the order is corrected.

NOTATION AND NOMENCLATURE

As used herein, the terms “services” or “oilfield services” shall mean parts, services, or other purchasable items, particularly for use in oilfield operations such as drilling, completion, and production.

As used herein, the terms “requestor” or “requesting system” shall mean a party that requests oilfield services.

As used herein, the term “receiver” or “receiving system” shall mean a party that receives a request for oilfield services, regardless of whether that party actually processes and fills the request or passes the request onto a third party for processing and filling.

As used herein, the term “wellsite system” shall mean equipment installed or in use at a hydrocarbon wellsite, regardless of what stage of hydrocarbon extraction the equipment is used for. For example, drilling equipment, completion equipment, and production equipment are all part of the wellsite system.

Detailed Description

The various embodiments are directed to systems and related methods to facilitate a request for oilfield services using a data transfer protocol. More particularly, various embodiments are directed to receiving a services request from a services requestor that is transmitted using a data transfer protocol, such as the wellsite information transfer standard markup language (WITSML), which is a standard for transmitting technical data between organizations in the petroleum industry. The request is received at a data transfer protocol interface that passes the request to a data store, such as a database server, where the request is subsequently stored (e.g., as a new or updated database entry).

In some embodiments, a monitor tool monitors the data store for updates to existing entries and/or the addition of new entries, both of which may correspond to a request for services received from a services requestor. The monitor tool may review a new request for correctness using business rules that correspond to the particular data type of the request. For example, requests may enter the data store from different external systems, each of which may have a set data protocol. The monitor tool reviews the requests as they enter the data store to ensure that the requests conform to the data protocol of the associated external system. The monitor tool may then transform the request into a native format that a configuration file creator understands. This transformation may act as an audit for both the correctness and validity of the request, which is then processed and stored in the data store. Thus, regardless of the data format of requests when received, requests may be stored in the data store in a similar manner.

The monitor tool may also monitor the wellsite system to ensure that the new request corresponds to services that would actually be needed given the various components in use at the wellsite system. For example, the monitor tool compares units of measurement, sizes of components and the like to those which are in use at the wellsite system. In the event that the monitor tool determines that the new request is incorrect (e.g., for the reasons given above), the monitor tool generates a notification to the requestor that informs the requestor that one or more aspects of the request need to be corrected. The notification may be generated via, for example, a Short Message Service (SMS) text message, an e-mail, a voice mail or the like. The monitor tool may also generate an invoice for the requested services (or, alternately, cause an invoicing system to generate an invoice for the requested services) if the correctness of the new request is verified.

In accordance with various embodiments, a configuration file creator also monitors the data store for updates to existing entries and/or the addition of new entries, both of which may correspond to a request for services received from a requestor. Based on identifying a new request for services, the configuration file creator generates a configuration file for an appropriate vendor receiving system. Many receiving systems (e.g., oilfield service providers) may be associated with a single wellsite system, and thus the configuration file creator determines the appropriate receiving system(s) for a given new request. In some cases, configuration files for multiple receiving systems may be generated based on a single new request. The configuration file creator formats each configuration file to correspond to a format desired by the receiving system for that configuration file. For example, the configuration file creator maintains a lookup table that specifies a request format for each particular receiving system. Such a lookup table may be created or updated when new receiving systems are added. The configuration file creator may optionally review the configuration prior to being transmitted to the receiving system. In some embodiments, when the receiving system accesses the configuration file, the associated order is entered into an order processing system of the receiving system.

Additionally, as explained above, requests are stored in the data store in a similar manner regardless of the initial data format of the request, which enables the configuration file creator to create configuration files in the same manner regardless of the data format of the request. This allows for data aggregation to occur for all request formats, such that the data store is the main receiver of all requests, which simplifies processing these requests. The storage of data in the data store in an aggregated format allows for the system to become a request aggregator and receive data in many formats. This process is enabled by the monitor tool understand many different data formats and how to transform these formats into an aggregated format in which the data can be stored

Thus, in accordance with various embodiments, once a request for oilfield services is generated at a wellsite, the process of transmitting the request to the appropriate receiving service(s) is automated and the communication between a requestor and a receiver is simplified. Additionally, each request may be efficiently checked for correctness, which reduces expenditures and delays resulting from an incorrect service order.

Turning now toFIG. 1, a system100to facilitate a request for oilfield services is shown. A services requestor102couples to the system100, for example through a data transfer protocol interface104. The data transfer protocol interface104provides data from the services requestor102to a data store106, such as a database server. A monitor tool108monitors the data store106for new entries or updates to existing entries, either of which may correspond to a new request for services. Similarly, a configuration file creator110monitors the data store106for new entries or updates to existing entries, which may correspond to a new request for services. The monitor tool108may provide notifications of certain events (e.g., an error in a services request) to both the services requestor102and a vendor receiving system112. The configuration file creator110determines that a new request is associated with the vendor receiving system112and, as a result, provides a configuration file to the vendor receiving system112, which the vendor receiving system112may then process as a request for services.

The services requestor102may comprise a web browser, application, applet, mobile phone application or the like that a hydrocarbon wellsite operator (i.e., the requestor) accesses to request oilfield services. For example, the requestor may sign in to an application that allows them to fill in a form requesting various services. In some embodiments, the application form may limit the requestor to only services that are currently available from vendor receiving systems112that are coupled to the system100. However, as will be explained in more detail below, additional vendor receiving systems112may be coupled to the system100as needed. Thus, if a particular requested service is unavailable, the requestor is made aware of a need to add additional vendor receiving systems112so that the requestor's request may be fulfilled.

The data transfer protocol interface104serves as a communication interface between the services requestor102and the data store106. For example, data such as a services request may be transferred over the data transfer protocol interface104using WITSML, hypertext markup language (HTML), extensible markup language (XML) or the like. Further, various transfer protocols such as hypertext transfer protocol (HTTP) may be employed by the data transfer protocol interface104. One skilled in the art appreciates that the above interfaces are exemplary, and any communication interface that enables the transmission of a request for oilfield services is within the scope of the present disclosure.

The data store106may comprise a database server, or other data storage device, that allows data received through the data transfer protocol interface104to be stored for monitoring, access or retrieval. The data store106may include a number of entries that correspond to requests for oilfield services received through the data transfer protocol interface104. In some cases, when a new request is received through the data transfer protocol interface104, a new entry is generated in the data store106that corresponds to the new request. In other cases, an entry in the data store106is updated (e.g., various fields of the entry may be altered based on data of the new request or a particular field may be altered to indicate that the entry corresponds to a new request) to contain data that corresponds to the new request.

In addition to containing entries corresponding to requests for oilfield services, the data store106may also store audit logs that track various activities/events such that, if necessary, a detailed description of events may be recovered. For example, the audit logs may include information such as where the request originated from, the initial data format of the request, where the original data file of the request is stored, when the request was received, whether notifications were sent as a result of receiving the request, whether a configuration file was created, what data was in the configuration file, or whether the configuration file was sent to an external system. Various events may be marked with a time and date stamp and a user ID may be captured when a receiving system accesses a configuration file or when a requesting system generates a request. User IDs may also be captured if an update is made to the data store along with the data changes that were made. User IDs may include a system ID or an individual's user ID who is logged onto the system100and invoking a change. In accordance with various embodiments, the audit logs facilitate subsequent forensic analysis, if necessary, to rebuild the process of events that led to an incident. For example, it may be possible to show how a request was created, where the request originated from, and how the request was subsequently handled.

The monitor tool108monitors the data store106(e.g., through periodic or continuous queries) to detect updates to existing entries or the addition of new entries, both of which may correspond to a request for services generated by the services requestor102. When the monitor tool108detects a change to the data store106that corresponds with a new request for services, the monitor tool108reviews the new request for correctness using business rules that correspond to the particular data type of the request. For example, a new request may be received from the services requestor102in the data format that the services requestor102uses (e.g., a request for drilling services using a requestor's XML format). The request is then stored in the data store106, which causes the monitor tool108to examine the request and transform the request into a native format, such that the request can be stored and understood by, for example, the configuration file creator110. This transformation of the request from an external system format to a native request format enables all requests to be acted on in a similar manner. In some embodiments, the monitor tool108also monitors the wellsite system (not shown) to ensure that new requests are for services that would actually be needed considering the various components in use at the wellsite system. For example, in some embodiments, the monitor tool108compares units of measurement, sizes of components and the like to those which are in use at the wellsite system for correctness. If a requested component is incompatible with various components in use at the wellsite system, the new request may be erroneous.

In the event that the monitor tool108determines that the new request is incorrect or erroneous (e.g., for the reasons given above), the monitor tool108generates a notification to the services requestor102that informs the requestor102that one or more aspects of the request need to be corrected. The notification may be generated via, for example, a Short Message Service (SMS) text message, an e-mail, a voice mail or the like. In some cases, the monitor tool108also forwards the notification to the receiving system112or generates a different notification for the receiving system112. If the monitor tool108verifies the correctness of the new request, the monitor tool108may also generate an invoice for the requested services (or, alternately, cause an invoicing system (not shown) to generate an invoice for the requested services).

Similar to the monitor tool108, the configuration file creator110monitors the data store106(e.g., through periodic or continuous queries) to detect updates to existing entries or the addition of new entries, both of which may correspond to a request for services generated by the services requestor102. When the configuration file creator110detects a change to the data store106that corresponds with a new request for services, the configuration file creator110determines whether the vendor receiving system112is affected by the new request. For example, if the request is for services that the receiving system112does not provide, then the receiving system112is not affected by the new request. On the other hand, if the request is for services that the receiving system112provides, then the receiving system112is affected by the new request. In some embodiments, multiple receiving systems are coupled to the system100, and thus the configuration file creator110, and a particular request may affect more than one receiving system.

If the configuration file creator110determines that the receiving system112is affected by the new request, the configuration file creator110determines a configuration file format for the receiving system (e.g., by accessing a look up table containing a preferred configuration file format for each receiving system coupled to the configuration file creator110). The configuration file format specifies a request format that the receiving system112will be capable of processing as an order. The configuration file creator110formats the new request into an appropriate configuration file for the receiving system112. In some cases, the receiving system112accesses the configuration file creator110(e.g., periodically or continuously) to retrieve the configuration file, while in other embodiments, the configuration file creator110transmits the configuration file to the receiving system. In some embodiments, the receiving system112retrieves or receives the configuration file only after being authenticated, for example by logging into a web application and/or presenting appropriate credentials to the configuration file creator110. After receiving the configuration file, the receiving system112processes the order.

FIG. 2shows an exemplary embodiment of the configuration file creator110processing a new request202. The new request202is for services A, B, C, D and E. As explained above, in this context, services refer to parts, services, or other purchasable items for use in various wellsite systems. The configuration file creator110receives or retrieves the new request202from the data store106shown inFIG. 1. InFIG. 2, two vendor receiving systems112a,112bare shown. Each receiving system112a,112bprovides different services to the services requestor102. The configuration file creator110determines which of the services A-E of the new request202correspond to each receiving system112a,112b(e.g., by accessing a vendor reference table111athat specifies the services provided by each receiving system112a,112b). In this case, services A, B and D are provided by receiving system112aand services C and E are provided by receiving system112b.

When the configuration file creator110determines the receiving systems affected by the new request202, the configuration file creator110determines the appropriate configuration file format for each affected receiving system112a,112b. For example, the configuration file creator110accesses a configuration file format lookup table111bthat specifies the preferred configuration file format for each receiving system112a,112b. The configuration file creator110then creates an appropriately formatted configuration file204a,204bfor each receiving system112a,112b. In this case, the configuration file204ais formatted for the receiving system112aand contains formatted requests for services A, B and D (i.e., the services provided by the receiving system112a). Similarly, the configuration file204bis formatted for the receiving system112band contains formatted requests for services C and E (i.e., the services provided by the receiving system112b). In some embodiments, the receiving systems112a,112baccess the configuration files204a,204bby logging into an application (e.g., a webpage provided through a standard web browser) and providing credentials to authenticate the identity of the receiving system112a,112bto prevent unauthorized access to the system100. Subsequently, the receiving system112a,112bretrieving its associated configuration file204a,204bcauses the request associated with the configuration file204a,204bto be processed by the receiving system112a,112b(e.g., is automatically entered into the order processing system of the receiving system112a,112b). The receiving system112a,112bmay continually or periodically check the configuration file creator110for newly-generated configuration files for that receiving system.

Referring toFIGS. 1 and 2, and in accordance with various embodiments, when a new vendor receiving system is added or removed from the system100, the vendor reference table111aand the configuration file format lookup table111bmay be updated to reflect the addition or removal of a vendor and the services provided by that vendor and their configuration file format preferences. Thus, the system100is able to accommodate fluctuations in the needs of the services requestor102(e.g., a new vendor may be added if a need arises for services not provided by any current vendor). Further, if a vendor is no longer able to supply certain services, those services may be removed from that vendor's entry in the vendor reference table111aand, if necessary, a new vendor may be added to ensure supply of those services. Similar other modifications are within the scope of the present disclosure.

FIGS. 3aand 3bshow methods300,350for facilitating a request for oilfield services using a data transfer protocol in accordance with various embodiments. Turning first toFIG. 3a, the method300begins in block302with receiving a services request through a data transfer protocol interface. The request may originate from the services requestor102as shown inFIG. 1and be received by the data store106through the data transfer protocol interface104. In some embodiments, the data store106comprises a database server, which will be further explained below. The method300continues in block304with updating an entry in a data store, such as the data store106, to indicate one or more parameters that are associated with the services request. For example, an entry in the data store106may be updated to include parameters such as an identification of the wellsite, an identification of the service, a quantity requested, and the like. In some embodiments, a new entry is added to the data store106rather than updating an entry.

The method300continues in block306with verifying the correctness of the services request that corresponds to the detected update. In some embodiments, this step is carried out in response to detecting the update to the data store106(e.g., by the monitor tool108). As explained above, the monitor tool108may detect that a new request has been added to the data store106by periodically or continually querying the data store106. The monitor tool108may verify the correctness of the services request by using business rules that correspond to the particular data type of the request. For example, the services request is transformed from the data format that the services requestor102uses (e.g., a request for drilling services using a requestor's XML format) into a native format. This validates the request since, to correctly carry out the transformation, the data format of the original services request must be correct. Transforming the services request into the native format enables the request to be stored and understood by, for example, the data store106and the configuration file creator110. In some embodiments, the monitor tool108monitors the wellsite system and verifies the correctness of the services request by comparing the requested services with the various components in use at the wellsite system. For example, the services request may be further validated by, for example, determining whether a proposed depth in is less than a proposed depth out, determining whether there are mnemonics for every curve request, determining whether there are one or more tools with each tool services request, determining whether each tool has an outer diameter associated with it, and the like. This validation helps to ensure that the services request is correct for the wellsite system. Certain requested services may be incompatible with the components or tools currently being used at the rig site (e.g., incorrect dimensions, incorrect tool for a particular task), and thus the services request may be at least partially erroneous. If the services request is verified, the request may be stored to the data store106in the native format.

If the correctness of the services request is not verified (block308), the method300continues in block310with generating a notification indicating that the services request contains one or more errors. The monitor tool108that attempted to verify correctness may also generate the notification. The notification may be transmitted to the services requestor, potential receiving systems, or both. The monitor tool108may generate the notification via, for example, a Short Message Service (SMS) text message, an e-mail, a voice mail or the like.

If the correctness of the services request is verified (block308), the method300continues in block312with generating an invoice for the services request. The monitor tool108that verified the services request may also generate the invoice or, alternately, the monitor tool108may cause an invoicing system to generate the invoice for the services request.

Turning now toFIG. 3b, the method350begins in block352with receiving a services request through a data transfer protocol interface and continues in block354with updating an entry in a data store to indicate one or more parameters that are associated with the services request. These steps are similar blocks302and304described above with respect to the method300ofFIG. 3a. The method350continues in block356with identifying an affected receiving system. In some embodiments, this step is carried out in response to detecting the update to the data store106(e.g., by the configuration file creator110).

As explained above, the configuration file creator110may detect that a new request has been added to the data store106by periodically or continually querying the data store106. The configuration file creator110identifies the affected receiving system by, for example, accessing a vendor reference table (such as vendor reference table111aofFIG. 2) that specifies the services provided by each receiving system. If the request is for services that the receiving system does not provide, then the receiving system is not affected by the new request. On the other hand, if the request is for services that the receiving system provides, then the receiving system is affected by the new request. In some embodiments, multiple receiving systems are coupled to the system100, and thus the configuration file creator110, and a particular request may affect more than one receiving system.

When an affected receiving system has been identified, the method350continues in block358with determining a configuration file format for the affected receiving system. The configuration file creator110determines a configuration file format by, for example, accessing a configuration file format lookup table (such as configuration file format lookup table111bofFIG. 2) that specifies the preferred configuration file format for each receiving system coupled to the system100. The method350the continues in block360with generating a configuration file for the services request. The configuration file creator110generates the configuration file based on the determined format from the configuration file format lookup table for the affected receiving system.

The method350then continues in block362with enabling the affected receiving system to access the configuration file. In some embodiments, the affected receiving system accesses the configuration file creator110(e.g., periodically or continuously) to retrieve the configuration file, while in other embodiments, the configuration file creator110transmits the configuration file to the receiving system. Credentials may be passed between the affected receiving system and the configuration file creator110to authenticate the retrieval or access of the configuration file for the affected receiving system.

The methods300,350contain steps that may be performed in an order other than that which is shown inFIGS. 3aand 3b. Additionally, in some embodiments, some of the steps shown inFIGS. 3aand 3bmay not be performed or may be performed optionally. All such embodiments are within the scope of this disclosure.

FIG. 4illustrates a computer system400in accordance with at least some embodiments. Although not explicitly shown inFIG. 4, the computer system400may comprise the data transfer protocol interface104and the data store106ofFIG. 1and provide the functionality of the monitor tool108, the configuration file creator110, or both. Alternately, multiple such computer systems may be in communication with each other and serve as the data store106, the monitor tool108, and the configuration file creator110. Referring back toFIG. 4, computer system400comprises a main processor410coupled to a main memory array412, and various other peripheral computer system components, through integrated host bridge414. The main processor410may be a single processor core device, or a processor implementing multiple processor cores. Furthermore, computer system400may implement multiple main processors410. The main processor410couples to the host bridge414by way of a host bus416, or the host bridge414may be integrated into the main processor410. Thus, the computer system400may implement other bus configurations or bus-bridges in addition to, or in place of, those shown inFIG. 4.

The main memory412couples to the host bridge414through a memory bus418. Thus, the host bridge414comprises a memory control unit that controls transactions to the main memory412by asserting control signals for memory accesses. In other embodiments, the main processor410directly implements a memory control unit, and the main memory412may couple directly to the main processor410. The main memory412functions as the working memory for the main processor410and comprises a memory device or array of memory devices in which programs, instructions and data are stored. The main memory412may comprise any suitable type of memory such as dynamic random access memory (DRAM) or any of the various types of DRAM devices such as synchronous DRAM (SDRAM), extended data output DRAM (EDODRAM), or Rambus DRAM (RDRAM). The main memory412is an example of a non-transitory computer-readable medium storing programs and instructions, and other examples are disk drives and flash memory devices.

The illustrative computer system400also comprises a second bridge428that bridges the primary expansion bus426to various secondary expansion buses, such as a low pin count (LPC) bus430and peripheral components interconnect (PCI) bus432. Various other secondary expansion buses may be supported by the bridge device428. In accordance with some embodiments, the bridge device428comprises an Input/Output Controller Hub (ICH) manufactured by Intel Corporation, and thus the primary expansion bus426comprises a Hub-link bus, which is a proprietary bus of the Intel Corporation. However, computer system400is not limited to any particular chip set manufacturer, and thus bridge devices and expansion bus protocols from other manufacturers may be equivalently used.

Firmware hub436couples to the bridge device428by way of the LPC bus430. The firmware hub436comprises read-only memory (ROM) which contains software programs executable by the main processor410. The software programs comprise programs executed during and just after power on self tests (POST) procedures as well as memory reference code. The POST procedures and memory reference code perform various functions within the computer system before control of the computer system is turned over to the operating system.

The computer system400further comprises a network interface card (NIC)438illustratively coupled to the PCI bus432. The NIC438acts as to couple the computer system400to a communication network, such the Internet.

Still referring toFIG. 4, computer system400may further comprise a super input/output (I/O) controller440coupled to the bridge428by way of the LPC bus430. The Super I/O controller440controls many computer system functions, for example interfacing with various input and output devices such as a keyboard442, a pointing device444(e.g., mouse), game controller446, various serial ports, floppy drives and disk drives. The super I/O controller440is often referred to as “super” because of the many I/O functions it performs.

The computer system400further comprises a graphics processing unit (GPU)450coupled to the host bridge414by way of bus452, such as a PCI Express (PCI-E) bus or Advanced Graphics Processing (AGP) bus. Other bus systems, including after-developed bus systems, may be equivalently used. Moreover, the graphics processing unit450may alternatively couple to the primary expansion bus426, or one of the secondary expansion buses (e.g., PCI bus432). The graphics processing unit450couples to a display device454which may comprise any suitable electronic display device upon which any image or text can be displayed. The graphics processing unit450comprises an onboard processor456, as well as onboard memory458. The processor456may thus perform graphics processing, as commanded by the main processor410. Moreover, the memory458may be significant, on the order of several hundred megabytes or more. Thus, once commanded by the main processor410, the graphics processing unit450may perform significant calculations regarding graphics to be displayed on the display device, and ultimately display such graphics, without further input or assistance of the main processor410.

It is noted that while theoretically possible to perform some of the above-described data aggregation, monitoring, processing, verification and the like by a human using only pencil and paper, the time measurements for human-based performance of such tasks may range from man-days to man-years, if not more. Thus, this paragraph shall serve as support for any claim limitation now existing, or later added, setting forth that the period of time to perform any task described herein less than the time required to perform the task by hand, less than half the time to perform the task by hand, and less than one quarter of the time to perform the task by hand, where “by hand” shall refer to performing the work using exclusively pencil and paper.

From the description provided herein, those skilled in the art are readily able to combine software created as described with appropriate general-purpose or special-purpose computer hardware to create a computer system and/or computer sub-components in accordance with the various embodiments, to create a computer system and/or computer sub-components for carrying out the methods of the various embodiments, and/or to create a non-transitory computer-readable storage medium (i.e., other than an signal traveling along a conductor or carrier wave) for storing a software program to implement the method aspects of the various embodiments.