TECHNICAL FIELD

[1] This application is directed to a workflow for a wellsite controller and a remote server that enables self provisioning and self configuration of the wellsite controller at a wellsite for communication with the remote server.

BACKGROUND ART

[2] It is common for controllers employed at a wellsite to communicate with remote centralized servers to enable remote monitoring of the wellsite. In particular, many such known controllers employ Supervisory Control and Data Acquisition System (SCAD A) protocols, such as the “Modbus” communications protocol, for communications with their respective remote centralized servers. While this does enable remote monitoring of the wellsite, the nature of these protocols involves a lengthy manual configuration and provisioning process, utilizing a team of operators and administrators when new equipment (e.g., a wellsite controller) is added or modified at the wellsite or when changes to the well site are made (e.g., control set points moved).

[3] As an example, a typical process for configuration and provisioning of new equipment at a wellsite is now described with reference to the chart 5 of FIG. 1. In general, this process involves the installation of the equipment at the wellsite (10) by a field technician, the configuration of the SCADA system (20) by a SCADA administrator to enable remote collection of data and communications with the equipment at the wellsite, and then system integration by a server administrator to integrate the SCADA system with other systems (30).

[4] The installation of the equipment (10) involves the manual installation of a communications interface for the new equipment at the wellsite (11), and the manual performance of communications tests between the new equipment at the wellsite and the SCADA system (12). These communications tests involve cooperation between the field technician installing the equipment at the wellsite and an administrator of the SCADA system. Then, peripherals such as sensors are manually installed (if not yet installed), set up, and tested, with the settings used being recorded manually (13). At this point, manual reports are generated that capture location and equipment installation data (14). [5] The SCADA configuration (20) performed by the SCADA administrator includes the location and/or identification of the IP address of the communications interface of the new equipment at the wellsite (21), and then the cooperation with the field technician to perform communications tests between the communications interface and the SCADA system (22). Then, from the settings and installation data recorded by the field technician, the types of the peripherals are established and mapped into the SCADA system (23) by the SCADA administrator. Then, tests are performed by the SCADA administrator to verify that the SCADA system is in fact receiving data from the peripherals at the wellsite via the communications interface (24).

[6] The system integration (30) performed by the server administrator involves the configuration and mapping of the SCADA data (e.g., data received from the equipment at the wellsite via the SCADA system, such as information from the peripherals) to other enterprise systems (31), such as historian applications that track the SCADA data, software interfaces permitting interface between the SCADA data and Windows computers, and/or custom databases. In addition, the server administrator may manually integrate the SCADA data with inventory and reliability tracking systems, as well as analytics platforms (32).

SUMMARY OF THE INVENTION

[7] As can be appreciated, the above described conventional new equipment configuration and provisioning process is time consuming and prone to human error due to the various different tasks that are manually performed due to inefficient and insufficient data sharing between the various hardware and software systems used. As the configuration at the wellsite increases in complexity (e.g., by the addition of new peripherals), the complexity of this configuration and provisioning process only increases, becoming even more prone to human error. As can also be appreciated, due to the manual performance of these tasks, when changes are to be made to the configuration of the equipment, a field technician is required to visit the wellsite, driving up labor costs. Still further, the conventional SCADA systems typically used may not provide adequate data security, and may have a data throughput speed that is less than desired for real time remote monitoring and/or control of the equipment at the wellsite.

[8] For these reasons, further development in the area of wellsite controllers and workflows for provisioning and configuring such wellsite controllers is needed. [9] In general, disclosed herein are a wellsite controller and remove server executing a workflow that enables the wellsite controller to provision and configure itself and its peripherals for communication with the remote server over the internet in a way that reduces the number of tasks manually performed by technicians and administrators so as to decrease set up time and decrease downtime, while avoiding the potential for human errors such as data entry errors.

[10] The disclosed workflow allows the use of protocols other than SCADA and Modbus, such as Message Queuing Telemetry Transport (MQTT) push based messaging, for communication between the wellsite controller and remote server. Therefore, this disclosed workflow is based upon a “push” methodology rather than a “poll” methodology. In this workflow, the wellsite controller is loaded or preloaded with details about the production environment at the wellsite and then identifies itself to the remote server and communicates details of its configuration to the remote server. The remote server in turn provisions and configures itself for communications with the wellsite controller and can direct data flow from the wellsite controller to back-end enterprise systems.

[11] This way, much of the manual work previously performed by human technicians and administrators is eliminated, and changes to equipment at the wellsite can be easily effectuated. In addition, the MQTT protocol provides for quicker data transmission between the wellsite controller and the remote server. Still further, encryption may be applied on top of the MQTT protocol to enhance data security

[12] For example, disclosed herein is a system that includes a controller to be located at a wellsite. This controller is configured to receive workflow inputs, the workflow inputs including wellsite details and communications settings, and to generate a local configuration entry including the workflow inputs, sensor configuration information about wellsite sensors to be connected to the controller, and a unique identifier for the controller. The unique identifier for the controller is based upon the workflow inputs, the sensor configuration information, and location information about a location of the wellsite. The controller is further configured to generate a registration message based upon the local configuration entry. The system also includes a server that is configured to receive the registration message as pushed thereto by the controller, and compare the unique identifier to a store of known identifiers. If the unique identifier does not match one of the store of known identifiers, the server is configured to add the wellsite to a monitoring system of the server by creating an entry for the wellsite from the registration message, attempt to map the wellsite sensors to the entry for the wellsite in the monitoring system.

[13] If the wellsite sensors were successfully mapped to the entry for the wellsite in the monitoring system, the server may be configured to connect the controller to at least one external enterprise system such that data from the wellsite sensors is sent to the at least one external enterprise system.

[14] If the wellsite sensors were not successfully mapped to the entry for the wellsite in the monitoring system, the server may be configured to generate a verification message indicating that the wellsite sensors were not successfully mapped to the entry for the wellsite in the monitoring system.

[15] If the wellsite sensors were successfully mapped to the entry for the wellsite in the monitoring system, the server may be configured to generate a verification message indicating that the wellsite sensors were successfully mapped to the entry for the wellsite in the monitoring system.

[16] If the unique identifier does not match one of the store of known identifiers, the server may be configured to recognize the controller as being newly added and add the unique identifier and the wellsite details to the store of known identifiers.

[17] With the above described invention, much of the manual work previously performed by human technicians and administrators is eliminated, and changes to equipment at the wellsite can be easily effectuated. In addition, the MQTT protocol provides for quicker data transmission between the wellsite controller and the remote server. Still further, encryption may be applied on top of the MQTT protocol to enhance data security

BRIEF DESCRIPTION OF THE DRAWINGS

[18] FIG. 1 is a chart showing typical prior art process for configuration and provisioning of a wellsite controller at a wellsite.

[19] FIG. 2 is a block diagram showing the hardware upon which the workflow described herein may be performed.

[20] FIG. 3 is a flowchart of a workflow disclosed herein for self configuration and provisioning of a wellsite controller at a wellsite for communication with a remote server. DESCRIPTION OF EMBODIMENTS

[21] The following disclosure enables a person skilled in the art to make and use the subject matter disclosed herein. The general principles described herein may be applied to embodiments and applications other than those detailed above without departing from the spirit and scope of this disclosure. This disclosure is not intended to be limited to the embodiments shown, but is to be accorded the widest scope consistent with the principles and features disclosed or suggested herein.

[22] General details of the workflow disclosed herein have been given above. Specific details will be given below, but first, the hardware upon which the workflow is performed will be described with reference to FIG. 2. The hardware placed in the field includes a smart well controller 41 (which can be genetically referred to as a wellsite controller) placed at the wellsite 40, with multiple sensors 42-45 placed at the wellsite 40 and connected to the smart well controller 41. The smart well controller 41 has a network interface, such as a modem, integrated therein, and may permit easy installation of modular interfaces for additional network interfaces. The sensors 42-45 may be analog sensors that provide data about conditions of the production environment at the wellsite 40 to the smart well controller 41.

[23] The hardware remotely located from the field is comprised of monitoring system servers 50. A smart host 51, which is a server application executed on a server, is in communication with the smart well controller 41 over the internet and receives wellsite data from the smart well controller 41. The smart host 51, in turn, is in communication with multiple enterprise systems 61-63. These enterprise systems may be, for example, real-time historian applications, such as the Process Information (PI) application that tracks wellsite data communicated to it by the smart host 51, software interfaces, such as the Open Platform Communications interface (OPC) permitting interface between the smart host and Windows computers, and/or other custom databases.

[24] Although a limited number of sensors 42-45 and enterprise systems 61-63 are shown for brevity and ease of explanation, it should be understood that there may be any number of such sensors and enterprise systems, and that such sensors and enterprise systems may be of any suitable types.

[25] The workflow is now described with additional reference to FIG. 3. As will be explained below, the workflow is comprised of steps 100 performed at the wellsite, and steps 150 performed at the monitoring system server. Prior to installation of the smart well controller 41 at the wellsite, or in some cases after installation, inputs to the workflow are defined. These inputs include default well details 91, which may be pre-configured for the specific wellsite, or may be pre-set to an organization level default. Such organization level defaults may be a default well configuration (not specific to the wellsite), a configuration for wells in a specific field, or a configuration for wells in a specific region, for example. The default well details 91 may also include standard tags and sensor mapping templates.

[26] The inputs to the workflow also include default communications settings 92, such as preconfigured connection information for connection to the smart host 51, for example, the server address and log-in information for the server. Other preconfigured connection information may be network settings for use by the smart well controller 41, such as security and local network settings.

[27] The inputs to the workflow also include internal system variables 93, which may be automatically generated uneditable data such as unique identifiers for the smart well controller 41 and/or the sensors 42-45, as well as security and encryption tokens.

[28] After physical installation of the smart well controller 41 at the wellsite, it is activated (99), and the manual tasks to be performed by the field technician are begun (101). In particular, the field technician reviews the default well details 91 that have been set (102), and accepts or edits these values accordingly. In addition, at this step, the field technician confirms the well coordinates. The field technician also makes the connections between the smart well controller 41 and the sensors 42-45 (103) by physically and electrically connecting cables therebetween, may perform validation to see that data is being gathered correctly from the sensors 42-45, and may troubleshoot the connections if needed. The field technician additionally checks to verify that the connection between the smart well controller 41 and the remotely located smart host 51 is present and functioning properly (104), such as by testing communication within the MQTT client.

[29] This completes the tasks manually performed by the field technician. Note that, as compared to the prior art systems, much of the manually performed tasks have been eliminated, and that the remaining steps described below performed by the smart well controller 41 and smart host 51 can be considered to be a set of rules to be followed that enable the self provisioning and configuration of the smart well controller 41 and its sensors 42-45 without further user input, which was previously impossible and previously required numerous additional manual steps such as those described in the background section of this application.

[30] The smart well controller 41 saves the well details set by the technician (105) as well as details of the sensors (peripherals) 42-45, and from this configuration data, creates a registration message to be pushed to the smart host 51 (106). The registration message contains a unique identifier for the smart well controller 41 in its current configuration, is labeled with a specific registration flag, and contains the well details.

[31] The smart host 51 checks incoming messages for the registration flag to determine that it has received a registration messages (151), and compares the unique identifier contained in the received registration message to the unique identifiers stored in a store of device records 155 to determine whether the smart well controller 41 has previously been provisioned in its current configuration. If the smart well controller 41 has been previously provisioned in its current configuration (171), then re-provisioning is not necessary and provisioning can therefore be considered to be compete (162). If the smart well controller 41 has not been provisioned, or has not been provisioned in its current configuration (171), then the smart well controller 41 is added to the store of device records 155 by adding to the store of device records 155 the unique identifier as well as the well details contained in the registration message.

[32] In addition, the well is added to the monitoring system (153) in the smart host 51. This is performed by creating an entry for the well including the well name, data about the wellsite configuration contained in the registration message, and the location of the well contained in the registration message. Then, the sensors (peripherals) 42-45 are added to the well entry in the monitoring system (154) using the information about the sensors 42-45 contained in the registration message. In the case where a previous well entry existed but the configuration has been changed (and therefore re-provisioning is to be performed), the well entry is altered accordingly to include the data about the wellsite configuration contained in the registration message, and the sensors 42-45 are added as described.

[33] If this well entry was not successfully completed (156), then the field technician is advised of the failure by (158) by creating a verification message 159 containing this information and sending this verification message to the smart well controller 41. In this case of failure, the verification message 159 may contain details about the failure to assist the field technician with troubleshooting.

[34] If the sensors 42-45 were successfully added to the well entry in the monitoring system successfully competed (156), or if the well entry was successfully updated as described, then the well in its current configuration can be considered to be provisioned or registered and the field technician can be advised of the success and of the status of the well entry (158) by creating a verification message 159 containing this information and sending this verification message to the smart well controller 41. If the smart well controller 41 is not to be connected to one or more enterprise systems 61-63, then provisioning is at this point considered to be complete (162).

[35] If the smart well controller 41 is to be connected to one or more enterprise systems 61-63 such that data from the smart well controller 41 is to be routed to such enterprise systems (160), the smart host 51 retrieves stored system interface configuration information 161, which contains automated scripts used to automate setup between the smart well controller 41 and the enterprise systems, and executes the appropriate script to effectuate the setup. At this point, provisioning is then considered to be complete (162).

[36] Returning now to the verification message 159 sent to the smart well controller 41 to validate the registration 107, the smart well controller 41 displays the verification message 159 to the field technician. If the verification message 159 indicates success (108), then the field installation is complete (110). If the verification message 159 indicates failure (108), then the field technician is advised of the failure and provided with the details about the failure (109).

[37] It should be noted that the above described steps outside of the manual tasks 101 are performed without further user input and without human activity, and cannot be performed mentally because they are based in, and arise from, the physical hardware used. It should also be noted that since the above described steps arise from the use of the physical hardware used, namely the smart well controller 41, the sensors 42-45, and server device executing the smart host 51, the above disclosure uses technology to solve a problem arising from deficiencies of the technological field itself, and is a real, concrete, non-abstract solution to a real world technological problem. In fact, by performing the steps described above, the operation of the smart well controller 41 and server device executing the smart host 51 is improved because errors that previously occurred during configuration and provisioning are eliminated. Still further, note that the self configuration and provisioning described above allows the same smart well controller 41 and smart host 51 to be used with a variety of different sensors 42-45 and enterprise systems 61-63.

[38] Once provisioning is complete, the smart well controller 41 may proceed to normal operation in which the smart well controller 41 acquires data from the sensors 42- 45, and sends the data to the smart host 51. The smart host 51 may then send the data received from the smart well controller 41 to the enterprise systems 61-63. Note that, in some configurations, the data acquired from the sensors 42-45 may be pre-processed by the smart well controller 41 prior to sending the data to the smart host 51 so as to facilitate quick and accurate processing of the data by the smart host 51 and/or the enterprise systems 61-63.

[39] In addition, in some configurations, the smart well controller 41 may validate the quality of the data acquired from the sensors 42-45 prior to sending the data to the smart host 51. Each parameter or condition monitored by the sensors 42-45 has defined minimum and maximum values associated therewith, and values output by the sensors 42- 45 that are below the defined minimum value or above the defined maximum value may be considered out of the range of normal (or possible) operation. Therefore, to validate the quality of data, the smart well controller 41 may compare the acquired data to the defined minimum and maximum values, and flag acquired data values that are out of range and/or flag acquired data values that are in range. This way, the smart host 51 and enterprise systems 61-63 do not waste processing time on data values that are out of range.

[40] The defined minimum and maximum values for the parameters and conditions monitored by the sensors 42-45 may be received by the smart well controller 41 from the default well details 91, may be manually entered into the smart well controller 41 by the field technician at step 102, or may be determined by the smart well controller 41 by performing analysis on a series of values obtained from the sensors 42-45 over time.

[41] While the disclosure 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 envisioned that do not depart from the scope of the disclosure as disclosed herein. Accordingly, the scope of the disclosure shall be limited only by the attached claims.

REFERENCE SIGNS LIST

[42] 5 — Chart [43] 10 — Installation of equpiment as wellsite

[44] 11 — Installation of communications interface

[45] 12 — Manual performance of communiucations test between field and SCADA administrators

[46] 13 — Installation, setup, and testing of peripherals, manual recording of settings

[47] 14 — Capture of location and equipment installation data

[48] 20 — SCADA configuration

[49] 21 — Location of IP address of communications interface

[50] 22 — Cooperation with field technician to perform communications tests

[51] 23 — Establishing of peripheral types and mapplings from captured location and equipment installation data

[52] 24 — Confirmation of receipt of peripheral data

[53] 30 — Performance of system integration

[54] 31 — Configurtation and mapping of SCADA data to other enterprise systems

[55] 32 — Manual integration of SCADA data with inventory and reliability tracking systems and analytics platforms

[56] 40 - Wellsite

[57] 41 — Smart well controller

[58] 42 — Sensor 1

[59] 43 — Sensor 2

[60] 44 — Sensor 3

[61] 45 — Sensor 4

[62] 50 — Monitoring System Servers

[63] 51 — Smart host

[64] 61 — Enterprise system 1

[65] 62 — Enterprise System 2

[66] 63 — Enterprise system 3

[67] 91 — Default well details

[68] 92 — Default communications settings

[69] 93 — Internal system variables

[70] 99 — Activation of controller [71] 100 — Steps taken at wellsite

[72] 101 — Manually performed tasks at wellsite

[73] 102 — Setting of well details

[74] 103 — Making of connections to sensors

[75] 104 — Checking of remote connections

[76] 105 — Saving of configuration locally

[77] 106 — Creation of registration message

[78] 107 — Validation of registration

[79] 108 — Registration successfully validated

[80] 109 — Advsiing of field technician of errors in installation

[81] 110 — Field installation completed

[82] 150 — Actions taken at monitoring system server

[83] 151 — Receipt of registration message

[84] 152 — Recognition of new device or not

[85] 153 — Adding of well to monitoring system

[86] 154 — Adding of field devices to well in monitoring system

[87] 155 00 Store of device records 155

[88] 156 — Field devices successfully added to well in monitring system

[89] 158 — Advising of field technician of success or failure in adding of field devices to well in monitoring system

[90] 169 — Verification message

[91] 160 — Connection to enterprise system

[92] 161 — System intereface configuration

[93] 162 — Check of whether provisioning is complete

[94] 171 — Lack of reognition of new device and lack of complete provisioning