Operating wellbore equipment using data from mediator computing devices

A system includes a first wellbore operation controller for controlling a wellbore operation and generating a first broadcast indicating a first data topic desired for controlling the wellbore operation. The system also includes a second wellbore operation controller for generating a data stream associated with a wellbore and for generating a second broadcast indicating a second data topic that promotes the data stream. The system includes a mediator computing device that receives the first broadcast and the second broadcast and determines that the first wellbore operation controller is subscribed to the data stream by comparing the first data topic to the second data topic. In response to determining that the first wellbore operation controller is subscribed to the data stream, the mediator computing device creates a data link between the first wellbore operation controller and the second wellbore operation controller.

TECHNICAL FIELD

The present disclosure relates generally to devices for use in well systems. More specifically, but not by way of limitation, this disclosure relates to control of equipment used for well completion, well maintenance, and hydrocarbon production using data acquired from mediator computing devices.

BACKGROUND

A well system (e.g., an oil or gas well system) may include a wellbore drilled through a subterranean formation. The subterranean formation may include a rock matrix permeated by oil or gas that is to be extracted using the well system. Control of equipment used in wellbore operations, such as wellbore completion, well maintenance, and hydrocarbon production, is often provided by software tools that operate using algorithmic processes to estimate control settings of the equipment to achieve equipment efficiency. Controlling the equipment using the algorithmic processes results in a system that relies on an incomplete and potentially inaccurate representations of the well system and reservoir. Such reliance on incomplete representations may hinder performance of the equipment.

The software tools may rely on the algorithmic processes in isolation from other processes or data. That is, the software tools generate the control settings of the equipment based on data obtained by tools at a drilling site, but the software tools fail to utilize data generated by other tools or equipment. Moreover, the algorithmic processes fail to update based on other processes operating simultaneously or in conjunction with the algorithmic processes during the wellbore operation. Accordingly, the equipment control based on the isolated algorithmic processes relies on incomplete representations of the wellbore operation.

DETAILED DESCRIPTION

Certain aspects and features of the present disclosure relate to using data streams from wellbore creation, treatment, or production operations using a mediator computing device to generate equipment control parameter values. Sensors disposed within the wellbore that area associated with varying operations within the wellbore may be capable of detecting geological, geographical, and wellbore environmental attributes to generate equipment control parameter values. Separate wellbore creation, treatment, or production operations may generate data streams on separate computing systems at a wellsite. These separate computing systems may leverage information detected by other computing systems to enhance performance associated with the individual computing systems controlling the wellbore operations by creating data links between the separate computing systems using the mediator computing device (e.g., a framework of data stream sharing).

A method and system according to some examples can offer a framework of data stream sharing between separate wellbore operation controllers using a multiple domain data environment. The framework may enable an individual wellbore operation controller to broadcast data streams generated by a wellbore operation (e.g., wellbore creation, treatment, or production operations) of the individual wellbore operation controller, and for the individual wellbore operation controller to receive data streams generated by additional wellbore operations of additional wellbore operation controllers. In this manner, individual wellbore operation controllers are able to incorporate relevant data streams from other wellbore operation controllers to control the wellbore operations of the individual wellbore operation controllers.

By providing the framework to multiple wellbore operation controllers, additional wellbore operation controllers may arrive at a wellsite and “plug in” to relevant data streams already being generated by the multiple wellbore operation controllers. Upon plugging in the additional wellbore operation controllers, two-way communication between the newly plugged in wellbore operation controllers and prior established wellbore operation controllers may commence. This may enable the wellbore operation controllers to receive data feedback loops where actions in one wellbore operation domain (e.g., pumping) are combined with observations in another wellbore operation domain (e.g., microseismic monitoring). These feedback loops may result in changes to parameters in one of the wellbore operation domains. For example, a parameter of a pumping operation may change in response to observations from a microseismic monitoring operation.

FIG.1is a schematic illustration of a wellbore environment100including wellbore102, a pumping system104, and a microseismic monitoring system106. The wellbore102extends through various earth strata. The wellbore102has a substantially vertical section108and a substantially horizontal section110. The substantially vertical section108may include a casing string112cemented at an upper portion of the substantially vertical section108. The substantially horizontal section110extends through a hydrocarbon bearing subterranean formation114. A tubing string116extends from the surface118into the wellbore102. The tubing string116can provide a conduit for pumping a fracturing fluid into the wellbore102from the pumping system104to perform hydraulic fracturing operations on the wellbore102. The wellbore102includes a hydraulic fracture120(or induced fracture) that extends from the substantially horizontal section110. Proppant materials can be entrained in the fracturing fluid at the pumping system104and deposited in the hydraulic fracture120to maintain the hydraulic fracture120in an open state.

The wellbore environment100can include an observation wellbore122extending through various earth strata. The observation wellbore122has a substantially vertical section124. One or more geophones126are positioned on a tool128deployed within the observation wellbore122. In some aspects, transducers, tiltmeters or other suitable sensors may be used in place of the geophones126. The geophones126can monitor microseismic events in the formation114. For example, the geophones126can detect the arrival of primary waves and secondary waves of a microseismic event in the formation114during a hydraulic fracturing operation. In some aspects, tiltmeters may be positioned at the surface118proximate the horizontal location of the hydraulic fracture120or in shallow holes at the surface118.

The geophones126can be communicatively coupled to a computing device130(i.e., a wellbore operation controller). The computing device130can be positioned at the surface118or at a separate location. In some aspects, the tiltmeters can be communicatively coupled to the computing device130and can transmit data sufficient to determine a location of a microseismic event in the formation114.

The computing device130can include a processor interfaced with other hardware via a bus. A memory, which can include any suitable tangible (and non-transitory) computer-readable medium, such as random-access memory (“RAM”), ROM, electrically erasable and programmable read-only memory (“EEPROM”), or the like, can embody program components that configure operation of the computing device130. In some aspects, the computing device130can include input/output interface components (e.g., a display, keyboard, touch-sensitive surface, and mouse) and additional storage. The computing device130can transmit data to and receive data from the geophones126via a communication link132between the computing device130and the geophones126. The communication link132is wireless and can include wireless interfaces such as IEEE 802.11, Bluetooth, or radio interfaces for accessing cellular telephone networks (e.g., transceiver/antenna for accessing a CDMA, GSM, UMTS, or other mobile communications network). In other aspects, the communication link132can be wired and can include interfaces such as Ethernet, USB, IEEE 1394, or a fiber optic interface. While the computing device130is depicted as forming a part of a vehicle, the computing device130may also be located remotely from the vehicle as a stand-alone element.

The computing device130can use the data received from the array of geophones126to determine microseismic monitoring results, for example a location of a microseismic event that occurs in the formation114during the hydraulic fracturing operation. In an example, the computing device130can receive from the geophones126raw signal data corresponding to the arrival times of the primary waves and secondary waves associated with the microseismic event. The computing device130can calculate the difference between the travel times of the primary waves and secondary waves using data associated with the formation114to determine the location of the microseismic event. The computing device130can determine the length (hereinafter “observed length”) of the hydraulic fracture120based on the location of the microseismic event. For example, the computing device can determine an observed length of the hydraulic fracture120based on the location of the microseismic event and the assumption that the event occurred at the tip of a hydraulic fracture with a growing length.

The computing device130can also determine an estimated or a predicted length of the hydraulic fracture120(hereinafter “predicted length”) based on a fracture model. In some aspects, the computing device130can determine a predicted height or other geometry of the hydraulic fracture based on the fracture model. The fracture model can be updated using microseismic monitoring results determined by the computing device130using the data received from the array of geophones126. Other characteristics of the hydraulic fracture120may also be calculated by the computing device130using the data received by the array of geophones126.

The wellbore environment100may also include the pumping system104including a pumping truck134or other pumping device, fracturing fluid storage tanks (not shown), and any other components or systems associated with a hydraulic fracturing or stimulation operation performed by the pumping system104. A pumping computing device136(i.e., an additional wellbore operation controller) may control operations of the pumping system104. The pumping computing device136can control an injection flow rate of the fracturing fluid that is introduced into the formation114during a hydraulic fracturing operation.

The pumping computing device136can include a processor interfaced with other hardware via a bus. A memory, which can include any suitable tangible (and non-transitory) computer-readable medium, such as random-access memory (“RAM”), ROM, electrically erasable and programmable read-only memory (“EEPROM”), or the like, can embody program components that configure operation of the pumping computing device136. In some aspects, the pumping computing device136can include input/output interface components (e.g., a display, keyboard, touch-sensitive surface, and mouse) and additional storage.

The pumping computing device136can transmit data to and receive data from a mediator computing device138via a communication link132between the pumping computing device136and the mediator computing device138. The communication link132is wireless and can include wireless interfaces such as IEEE 802.11, Bluetooth, or radio interfaces for accessing cellular telephone networks (e.g., transceiver/antenna for accessing a CDMA, GSM, UMTS, or other mobile communications network). In other aspects, the communication link132can be wired and can include interfaces such as Ethernet, USB, IEEE 1394, or a fiber optic interface. While the pumping computing device136is depicted as separate from other components of the pumping system104, the pumping computing device136may also be integral with another component of the pumping system104. For example, the pumping computing device136may form a part of pumping truck134.

The computing device130can also transmit data to and receive data from a mediator computing device138via a communication link132between the computing device130and the mediator computing device138. Other devices producing data, consuming data, or both (e.g., other wellbore operation controllers) may also communicate with the mediator computing device138using the communication link132. During operation, the computing device130, the pumping computing device136, or any other wellbore operation controllers may receive data streams from the mediator computing device138using the communication link132.

The mediator computing device138can include a processor interfaced with other hardware via a bus. A memory, which can include any suitable tangible (and non-transitory) computer-readable medium, such as random-access memory (“RAM”), ROM, electrically erasable and programmable read-only memory (“EEPROM”), or the like, can embody program components that configure operation of the mediator computing device138. In some aspects, the mediator computing device138can include input/output interface components (e.g., a display, keyboard, touch-sensitive surface, and mouse) and additional storage. The mediator computing device138can transmit data to and receive data from wellbore operation controllers via a communication link132between the mediator computing device138and the wellbore operation controllers. The communication link132is wireless and can include wireless interfaces such as IEEE 802.11, Bluetooth, or radio interfaces for accessing cellular telephone networks (e.g., transceiver/antenna for accessing a CDMA, GSM, UMTS, or other mobile communications network). In other aspects, the communication link132can be wired and can include interfaces such as Ethernet, USB, IEEE 1394, or a fiber optic interface. While the mediator computing device138is depicted as separate from other components of the wellbore environment100, the mediator computing device138may also be integral with any another components of the wellbore environment100.

The data streams received at the computing device130, the pumping computing device136, or any other wellbore operation controllers from the mediator computing device138may provide additional data in a usable form to the computing device130, the pumping computing device136, or any other wellbore operation controllers. For example, the data streams from the computing device130and the pumping computing device136may be transformed by the mediator computing device138to a format understood by other wellbore operation controllers also linked with the mediator computing device138. Thus, the mediator computing device138may be able to receive data in one format, transform the data to a common format, and provide the common format data to a number of wellbore operation controllers in communication with the mediator computing device138.

In communicating with the mediator computing device138, each wellbore operation controller (e.g., the computing device130and the pumping computing device136) may provide broadcasts to the mediator computing device138. The broadcasts provided to the mediator computing device138may provide an indication of a type of data each of the wellbore operation controllers are capable of channeling through the mediator computing device138. That is, the broadcasts may indicate that the wellbore operation controller is a data stream and a type of data that the wellbore operation controller is capable of streaming. Additionally, the broadcasts may include an indication of a type of data each of the wellbore operation controllers would like to receive from other wellbore operation controllers through the mediator computing device136. That is, the broadcasts may indicate that the wellbore operation controller is a data consumer and a type of data that the wellbore operation controller would like to receive.

In an example, the mediator computing device138may control visibility and access to data streams that are received by the mediator computing device138. For example, the mediator computing device138may secure the data streams such that only wellbore operation controllers privy to a password are able to access the streams. Additionally, the mediator computing device138may provide certain data streams to only a subset of wellbore operation controllers in communication with the mediator computing device138. Further, the data sources (e.g., the wellbore operation controllers generating the data streams) may control visibility and access to the data streams by providing instructions to the mediator computing device138.

In some examples, certain data may be available to wellbore operation controllers associated with a specific company in communication with the mediator computing device138that may not be available to wellbore operation controllers associated with a different company also in communication with the mediator computing device138. Moreover, each of the wellbore operation controllers in communication with the mediator computing device138may be able to assign trust values to data streams received from the mediator computing device138. For example, a model used by the pumping computing device136may assign greater weight to a data stream originating from the computing device130when the microseismic monitoring system106is associated with the same company as the pumping computing device136as opposed to the microseismic monitoring system106being associated with a competitor company that is also working at a wellsite.

Further, the mediator computing device138may perform transformation operations on data streams received from the wellbore operation controllers. For example, each of the wellbore operation controllers may generate the data streams in a format specific to a type or manufacturer of the wellbore operation controller. The mediator computing device138may receive the data streams in such a format, and transform the data streams into a higher level domain concept than the raw data. For example, the mediator computing device138may transform raw data associated with pumping pressure from the pumping system104into a numerical representation of the pumping pressure that is supported by the other wellbore operation controllers in communication with the mediator computing device138. The consumers of the data (i.e., the other wellbore operation controllers) may receive the data stream either in raw form (e.g., when the other wellbore operation controllers support such a format) or at the higher level domain concept.

Moreover, multiple levels of domain concept extraction may be provided before the data is shared as a source or sent to a destination wellbore operation controller by the mediator computing device138. For example, pumping pressure, temperature, and audio data may be combined by the mediator computing device138to form a pumping effectiveness layer. The pumping effectiveness layer may then be shared by the mediator computing device138to other wellbore operation controllers.

In an example, the mediator computing device138may include a stack data structure that includes basic program components that are similar across sources and destinations that operate on the same program stack. A base stack of the stack data structure may support pluggable components that add functionality. For example, the functionality of the pluggable components may include additions of protocols, supported destinations, protocol interpretation, data storage persistence calculations, other types of data analysis, transformation, or logic, or a combination thereof. Each of the pluggable components added to the mediator computing device138may be updated without recompiling the base stack of the stack data structure.

The mediator computing device138may also provide process management functionalities. For example, pluggable components may react to data emitted by other pluggable components running in the stack data structure and emit the reactions as data for other pluggable components to consume. Additionally, one or more pluggable components operating in the stack data structure may emit data that is not presently consumed by the other pluggable components operating in the stack data structure, but may be consumed by pluggable components installed at a future time. In this manner, changing pluggable components operating in the stack data structure, and changing the data streams that are provided or consumed by the pluggable components, may change the capabilities of the wellbore operation controllers operating in the wellbore environment100.

As mentioned above, the mediator computing device138communicates with the wellbore operation controllers and any other pluggable components through the links132. The wellbore operation controllers and other pluggable components that operate on different stacks (e.g., through a different mediator computing device) may be linked at the mediator computing device138through an automated handshake process resulting from identifying the wellbore operation controllers and other pluggable components as data sources and data destinations. The linking may be achieved through a generic component at the mediator computing device138that reads all available emitted data, applies filtering to the available emitted data based on access definitions for availability of the data, and forwards the data to a remote system (e.g., through a remote mediator computing device). The remote system then emits the received data into the local stack of the remote system such that pluggable components on the local stack have access to the received data.

In an example, the mediator computing device138may include any computing device capable of running a computing platform that provides a mechanism to broadcast data stream availability. Other computing devices that are not the mediator computing device138may interface with the mediator computing device138. For example, the other computing devices that do not function as the mediator computing device138may include a computing component of a sensor (e.g., the computing device130associated with the geophones126). Such a sensor may include its own computing device with a well-defined interface on how to obtain streams of data. In such an example, a sender, which operates on the mediator computing device138, can receive data from that sensor in a pull or push format supported by that sensor. The sender may convert the data to a programming language-neutral format (if beneficial), package the data into a platform message wrapper, and send the packaged data to the mediator computing device138. The sensor data can be processed by data receivers in communication with the mediator computing device138, or the sensor data can be forwarded to remote mediator computing devices that are linked to the mediator computing device138for a topic of the data.

Other computing devices not running the computing platform that provides the mechanism to broadcast the data stream availability may include a database server that stores incoming data. In such an example, the database on the computing device may have a well-defined interface that allows data to be inserted for storage. In this example, a receiver in communication with the mediator computing device138may receive data from the mediator computing device, and the receiver can process the data by storing it onto the database server using the well-defined interface of the database server. In either of these examples, the computing platform run by the mediator computing device138may facilitate an easily extendible and distributable real-time bus for harvesting and processing the data from external computing devices that do not include the computing platform run by the mediator computing device138.

FIG.2is a schematic diagram of a flow of data across the mediator computing device138. A data source side200may provide a data stream to a mediator computing device138, and a data consuming side202may receive the data stream from the mediator computing device138. In an example, the data source side200includes a wellbore operation controller204(e.g., the microseismic monitoring system106ofFIG.1) that generates a data stream with a data producer component206and sends the data stream to the mediator computing device138with a message sender component208. Additionally, the message sender component208of the wellbore operation controller204may receive feedback from the mediator computing device138indicating potential issues with the data stream or additional data that other wellbore operation controllers desire that the wellbore operation controller204may be able to generate.

Other examples of the wellbore operation controller204are user interface programs, data acquisition programs that read data from a physical device, math calculation programs, programs that react to receiving data from another source, or a combination thereof. The mediator computing device138may receive messages from any number of wellbore operation controllers204that generate data to allow any number of wellbore operation controllers210on the data consuming side202to receive the data streams and react to the data contained in the data streams. Further, with the wellbore operation controller204is described as a data producer and the wellbore operation controller210is described as a data consumer, both the wellbore operation controllers204and210may operate as both data producers and data consumers in one or more examples.

In an example, the data consuming side202includes the wellbore operation controller210(e.g., the pumping system104ofFIG.1) that receives a data stream from the mediator computing device138with a message receiver component212and consumes the data stream with a data consumer component214. Upon receipt of the data stream from the mediator computing device138, the message receiver component212may provide to the mediator computing device138an acknowledgement of successful receipt of the data stream or a non-acknowledgment indicating that the data stream was not received successfully. Other examples of the wellbore operation controller204are user interface programs, data acquisition programs that read data from a physical device, math calculation programs, programs that react to receiving data from another source, or a combination thereof. The mediator computing device138may provide data streams to any number of wellbore operation controllers210that consume data generated by any number of wellbore operation controllers204.

In an example, an additional wellbore operation controller216may include both a message sender component218and a message receiver component220. The wellbore operation controller216may receive the data stream from the mediator computing device138and provide feedback associated with the data stream to the mediator computing device138from the message receiver component220. Additionally, the wellbore operation controller216may execute a set of instructions on the data from the data stream, and provide a new data stream to the mediator computing device138from the message sender component218. The new data stream provided by the message sender component218may then be received and consumed by any other consuming wellbore operation controllers in communication with the mediator computing device138.

The mediator computing device138may function as a message agnostic message router. That is, the mediator computing device138provides a mechanism for the data streams from data producing wellbore operation controllers204and216to be delivered to any data consuming wellbore operation controllers210and216. Further, the mediator computing device138identifies a format of the data streams such that the data consuming wellbore operation controllers210and216only receive data in a format that that the data consuming wellbore operation controllers210and216are capable of handling.

FIG.3a schematic diagram of a system300including a flow of data between two mediator computing devices138aand138bacross a network302. In one or more examples, the mediator computing device138amay be positioned within a framework304that is local to wellbore operation controllers204a,210a, and216a, while the mediator computing device138bmay be positioned within a framework306that is local to wellbore operation controllers204b,210b, and216b. Each of the frameworks304and306may operate in a manner similar to the mediator computing device138and the wellbore operation controllers204,210, and216described above with respect toFIG.2.

The system300also includes the network302that enables a flow of data at data streams308and310between the mediator computing devices138aand138b. In an example, the data streams308and310provide a network link between the frameworks304and306across the network302. In this manner, the mediator computing device138amay be able to receive data from the wellbore operation controllers204a,210a, and216aand the mediator computing device138b, and the mediator computing device138amay be able to distribute data to the wellbore operation controllers204a,210a, and216aand the mediator computing device138b. Likewise, the mediator computing device138bmay be able to receive data from the wellbore operation controllers204b,210b, and216band the mediator computing device138a, and the mediator computing device138bmay be able to distribute data to the wellbore operation controllers204b,210b, and216band the mediator computing device138a. In one or more examples, the wellbore operation controllers204aand204b,210aand210b, and216aand216bmay assign equal weight to the data received from the respective mediator computing device138aand138bregardless of which of the frameworks304or306originated the data.

FIG.4is a schematic diagram of a system400exchanging data across several mediator computing devices402,404a,404b,406a,406b,406c,408a,408b, and408c. A local mediator computing device402may be a local mediator computing device operating within the same framework as one or more wellbore operation controllers204,210, and216. To increase data available to the wellbore operation controllers204,210, and216in communication with the local mediator computing device402, several links with other mediator computing devices may be established.

For example, the local mediator computing device may establish bi-directional links with bi-directional mediator computing devices404aand404b. The bi-directional mediator computing devices404aand404bmay operate within frameworks remote from the local mediator computing device402, and the bi-directional mediator computing devices404aand404bmay receive data from wellbore operation controllers also operating within the remote frameworks from the local mediator computing device402. The bi-directional links established between the local mediator computing device402and the bi-directional mediator computing devices404aand404bmay enable transmission of data from the bi-directional mediator computing devices404aand404bto the local mediator computing device402and from the local mediator computing device402to the bi-directional mediator computing devices404aand404b.

The local mediator computing device402may also establish incoming links with incoming mediator computing devices406a,406b, and406c. Likewise, the local mediator computing device402may establish outgoing links with outgoing mediator computing devices408a,408b, and408c. In an example, the incoming mediator computing devices406a,406b, and406cmay provide data to the local mediator computing device402without also receiving any data from the local mediator computing device402. Additionally, the outgoing mediator computing devices408a,408b, and408cmay receive data from the local mediator computing device402without also providing any data to the local mediator computing device402.

While the local mediator computing device402is depicted as being linked to eight different remote mediator computing devices, more or fewer remote mediator computing devices may link with the local mediator computing devices402in other examples. Further, each of the remote mediator computing devices depicted inFIG.4(e.g., mediator computing devices404a,404b,406a,406b,406c,408a,408b, and408c) may each communicate with one or more of the other depicted remote mediator computing devices or with one or more remote mediator computing devices that are not depicted inFIG.4. As each remote mediator computing device links with other remote mediator computing devices, more data may be available for the local mediator computing device402to leverage into information usable for control of wellbore operations.

FIG.5is a schematic diagram of two data producers or consumers500aand500b(e.g., the computing device130and the pumping computing device136ofFIG.1) including integration frameworks502aand502b. The data producer or consumer500amay include the integration framework502athat provides a mechanism to supply data messages to various subcomponents of the data producer or consumer500aor to other data consumers or producers500b. In an example, the data producer or consumer500aincludes a data acquisition component504that provides raw data to the integration framework502athrough a raw data connection link506. The data producer or consumer500amay also include an operational configuration block508that provides operational configuration information through a configuration data connection link510. The operational configuration information from the operational configuration block508may be information from a controller of the data producer or consumer500athat controls parameters of how the data producer or consumer500aproduces or consumes data.

Upon receipt of the raw data from the data acquisition component504, the integration framework502amay provide the raw data to one or more transformation components512. The transformation components512may transform the raw data into one or more sets of transformed data that are usable as control inputs for wellbore operation controllers. The transformed data may be returned to the integration framework502ausing transformed data links514. In an example, both the raw data and the transformed data may be stored locally in a memory516of the data producer or consumer500avia the raw data connection link506and the transformed data connection link514, respectively. Moreover, the transformed data may be provided by the integration framework502ato a framework sender518using the transformed data link514before being transmitted to a message queue520via an additional transformed data link514. At the message queue520, the transformed data may await collection from another data producer or consumer. In an example, the transformed data may be provided to the message queue520when, for example, a message receiver component212establishes a link with the data broadcast.

To identify another data producer or consumer (e.g., the data consumer or producer500b) that may benefit from receiving the transformed data, the integration framework502amay provide configuration data of the data producer or consumer500ato a source broadcasting block522using the configuration data connection link510. The source broadcasting block522may interact with a mediator computing device524(e.g., the mediator computing device138ofFIG.1) to broadcast the type of transformed. For example, the source broadcasting block522may broadcast that the transformed data is microseismic acoustic data, hydraulic pumping telemetry, or other types of data. Further, the source broadcasting block522may broadcast information about the origination of the transformed data (e.g., a well identifiers, equipment serial numbers, probe identifiers, etc.).

The mediator computing device524may also provide configuration data across a configuration data connection link510to the framework sender518. The configuration data provided to the configuration data connection link510may provide information to the framework sender518on how to package the transformed data for transmission to the message queue520such that the transformed data is in a format usable by and linked to, for example, the data consumer or producer500b. In this manner, the transformed data may be transmitted to a message queue526of the data consumer or producer500busing an additional transformed data connection link514.

While the mediator computing device524is depicted as being located within the data consumer or producer500b, the mediator computing device524may also be located in the data producer or consumer500a, a standalone device, or a device located with a different non-illustrated data consumer or producer. Additionally, the mediator computing device524may provide and receive configuration data from a number of data consumers or producers to coordinate the transfer of data between the number of data consumers or producers.

FIG.6is a flowchart of an example process600for transmitting a message to the mediator computing device138. As discussed above, the wellbore operation controller204may include a data producer component206and a message sender component208. These components206and208of the wellbore operation controller204may generate and send a stream of data to the mediator computing device138according to the process600described below.

At block602, the process600involves starting the process600. Starting the process600may involve a trigger. For example, the wellbore operation controller204may receive an indication that another wellbore operation controller is looking for the data produced or otherwise generated by the wellbore operation controller204. In another example, the process600may initialize upon startup of the wellbore operation controller204.

At block604, the process600involves generating or reading data at the data producer component206. Reading the data at the data producer component206may involve receiving information from sensors or other data sources communicatively coupled with or integral to the data producer component206. Additionally, generating the data at the data producer component206may involve performing a transforming operation on raw data to generate a data stream that is in a format usable for wellbore operation control.

At block606, the process600involves making a determination as to whether the data is in a target binary format. The target binary format may include a serialized programming language-neutral format that is readable by other devices such as the wellbore operation controllers210and216depicted inFIG.1. If the data is already in the target binary format, the data may continue the process600at the message sender component208.

If the data is not already in the target binary format, at block608, the process600involves packaging the data into a programming language-neutral format. The programming language-neutral format may be used to exchange data between the wellbore operation controllers204,210, and216independent of the language that each of the wellbore operation controllers204,210, and216use for performing operations independently.

At block610, the process600involves serializing the data in the programming language-neutral formal to generate the target binary format. The target binary format is used to transfer the data between the wellbore operation controllers204,210, and216. Accordingly, at block612, the data in the target binary format is ready for inclusion in a message to be transmitted to other wellbore operation controllers204,210, and216.

At block614, the process600involves identifying, at the message sender component208, header information for the data in the target binary format. The header information may describe, for example, what information the data represents (e.g., microseismic acoustic data, hydraulic pumping telemetry, etc.) and the origination of the data (e.g., the well identifier, the equipment serial number, the probe identifier, etc.).

At block616, the process600involves compiling a message envelope. The message envelope may include the header information combined with the data in the target binary format. Upon compiling the message envelope, the message envelope is ready, at block618, for publishing to the mediator computing device138. Thus, at block620, the process600involves publishing the message (i.e., the message envelope) to the mediator computing device138.

At block622, the process600involves receiving the message at the mediator computing device138. As discussed above, the mediator computing device138may be integral to the wellbore operation controller204, may be located within a separate wellbore operation controller210or216, or may be a standalone device. The message sender component208may transmit the message to the mediator computing device138through a wired or wireless connection.

At block624, the process600involves making a determination as to whether the message is valid. For example, the mediator computing device138may determine that the message is somehow corrupted or is missing necessary elements for transmission of the message to the other wellbore operation controllers210or216. If the message is not valid, the message transmission process ends at block626.

If the message received by the mediator computing device138is valid, at block628, the process600involves processing the message to be forwarded to each qualifying receiver. The qualifying receivers may be, for example, the wellbore operation controllers210or216that are subscribed to a type of data included within the message from the wellbore operation controller204. Further, processing the message may be an indication that the message was not discarded, and the message is available for forwarding to receivers in communication with the mediator computing device138.

At block630, the process600involves determining if each of the receivers in communication with the mediator computing device138is subscribed to the message's topic or subscribed to all messages from the mediator computing device138. If a receiver is not subscribed to the message's topic or to all messages from the mediator computing device138, the process600may end at block626.

If the receiver is subscribed to the message's topic or to all messages from the mediator computing device138, at block632, the process600involves forwarding the message to each of the subscribed receivers. Once the message is forwarded to the subscribed receivers, the process600may end at block626.

At block634, the process600involves determining if the message is targeted for remote transfer. For example, the message may be targeted for transmission to one or more remote mediator computing devices. If the message is not targeted for transfer to a remote mediator computing device, the process600may end at block626.

If the message is targeted for transfer to a remote mediator computing device, at block636, the process600involves processing the message to be forwarded to each qualifying link to other remote mediator computing devices. The remote mediator computing devices receiving the message may be, for example, the remote mediator computing devices in communication with remote wellbore controllers that are subscribed to a type of data included within the message from the wellbore operation controller204. Further, processing the message may be an indication that the message was not discarded, and the message is available for forwarding to remote mediator computing devices subscribed to the topic of the message.

At block638, the process600involves determining if the link is outgoing or bi-directional and subscribed to the message's topic. If the link is not outgoing or bi-directional or not subscribed to the message's topic, the process600may end at block626. If the link is outgoing or bi-directional and subscribed to the message's topic, at block640, the message is forwarded using each of the qualifying links to the remote mediator computing devices. Upon completion of forwarding the message to the qualifying links, the process600may end at block626.

FIG.7is a flowchart of an example process700for transmitting a remotely produced message from a source mediator computing device (e.g., the mediator computing device138a) to a target mediator computing device (e.g., the mediator computing device138b). At block702, the process700involves beginning the remote message transmission process700. For example, the source mediator computing device may receive an indication that the target mediator computing device is looking for data channeled through the source mediator computing device. In another example, the process700may initialize as soon as the source mediator computing device creates a communication link with the target mediator computing device.

At block704, the process700involves the source mediator computing device receiving a message that is ready for serialization and forwarding to the target mediator computing device. At block706, a determination is made as to whether the target mediator computing device is linked to the source mediator computing device for the topic of the message. If the target mediator computing device is not linked for the topic of the message, the process700may end at block708.

If the target mediator device is linked for the topic of the message, at block710, the process700involves the source mediator computing device serializing the message to binary data to prepare the message for transmission to the target mediator computing device. At block712, the serialized message is forwarded to the linked target mediator computing device along with a topic that describes a category of the message.

At block714, the process700involves the target mediator computing device receiving the serialized message from the source mediator computing device. Further, at block716, the target mediator computing device unpacks the message by deserializing the serialized message. Using the deserialized message, the target mediator computing device makes a determination, at block720, regarding whether the message is valid. For example, the target mediator computing device may determine that the message is somehow corrupted or is missing necessary elements for transmission of the message to the other wellbore operation controllers in communication with the target mediator computing device. If the message is not valid, the process700may end at block708.

If the message is valid, at block720, the process700involves processing the message to be forwarded to each qualifying receiver in communication with the target mediator computing device. The qualifying receivers may be, for example, the wellbore operation controllers210bor216bofFIG.2that are subscribed to a type of data included within the message from the source mediator computing device. Further, processing the message may be an indication that the message was not discarded, and the message is available for forwarding to receivers in communication with the mediator computing device138.

At block722, the process700involves determining if each of the receivers in communication with the target mediator computing device is subscribed to the message's topic or subscribed to all messages from the target mediator computing device. If a receiver is not subscribed to the message's topic or to all messages from the target mediator computing device, the process700may end at block708.

If the receiver is subscribed to the message's topic or to all messages from the mediator computing device138, at block724, the process700involves forwarding the message to each of the subscribed receivers. Once the message is forwarded to the subscribed receivers, the process700may end at block708.

FIG.8is a flowchart of an example process800for transmitting a message from a mediator computing device (e.g., the mediator computing device138) to a data consumer (e.g., the wellbore operation controller210including the message receiver component212and the data consumer component214). At block802, the process800involves beginning the message consumption process800. For example, the mediator computing device may receive an indication that the data consumer is looking for data channeled through the mediator computing device. In another example, the process800may initialize as soon as the mediator computing device creates a communication link with the data consumer.

At block804, the process800involves ensuring that the message is prepared for forwarding to the data consumer. Further, at block806, the process800involves forwarding the message to a data consumer local to the mediator computing device. In an example, the message is only forwarded to the data consumers that are subscribed to a topic of the message or subscribed to all of the messages channeled through the mediator computing device.

At block808, the process800involves receiving the message at a message receiver component (e.g., the message receiver component212) of the data consumer. In an example, the mediator computing device may be integral to the data consumer, may be located within a separate wellbore operation controller, or may be a standalone device. In one or more examples, the mediator computing device may transmit the message to the data consumer through a wired or wireless connection.

At block810, the process800involves identifying details of a message header of the message received at the data consumer. The details of the message header may provide the data consumer with information usable to determine if the message is useful to the data consumer. For example, the data consumer may filter out messages that are unusable by the data consumer to improve performance of an operation of the data consumer.

At block812, the process800involves making a determination as to whether the message is filtered or accepted. If the message is not relevant to the data consumer, a determination is made to filter the message. When the message is filtered by the data consumer, the mediator computing device may receive a non-acknowledgement message, at block814, indicating that the message was not accepted by the data consumer. Upon receiving the non-acknowledgement message, the mediator computing device may make a note to cease future transmissions of messages with the same topic to the data consumer. Additionally, upon receiving the non-acknowledgement message at the mediator computing device, the process800may end at block816.

If, at block812, the message is accepted, then at block814, the process800involves extracting data from the message. For example, the header information may be removed from the message envelope such that only the data remains. Once the data is extracted, at block816, the process800involves establishing that the data is ready for consumption. Establishing that the data is ready for consumption may involve transitioning the data from the message receiver component212to the data consumer component214.

Accordingly, at block818, the process800involves determining whether the data extracted from the message is in raw binary form or serialized from a programming language-neutral format. Upon determining that the data is serialized, at block819, the process800involves deserializing the data prior to processing and consuming the data. After deserializing the data or after determining that the data is in raw binary form, at block820, the process800involves attempting to process and consume the data. The data may be processed differently depending on the format of the data. For example, the data in the raw binary form may need further processing to generate data usable to the data consumer. In some examples, the data consumer component214may not be able to process and consume data in the raw binary form. Additionally, the serialized data from a programming language-neutral format may generally rely on less processing for the data to be usable by the data consumer.

At block822, the process800involves making a determination as to whether the data was consumed successfully by the data consumer. In an example, the data consumer may provide an indication to the mediator computing device that the data was not consumed using a non-acknowledgement message at block814. If the data was consumed, the data consumer may provide an indication to the mediator computing device that the data was consumed using an acknowledgement message at block814. In either instance, the process800may end at block818upon providing the acknowledgement or non-acknowledgement message to the mediator computing device.

FIG.9is a flowchart of an example process for a transformation of a message at a data transformer (e.g., the wellbore operation controller216). At block902, the process900involves beginning the message transformation process900. For example, a mediator computing device (e.g., the mediator computing device138) may receive an indication that the data transformer is looking for data channeled through the mediator computing device. In another example, the process900may initialize as soon as the mediator computing device creates a communication link with the data transformer.

At block904, the process900involves ensuring that the message is prepared for forwarding to the data consumer. Further, at block906, the process900involves forwarding the message to the data transformer local to the mediator computing device. In an example, the message is only forwarded to the data consumers that are subscribed to a topic of the message or subscribed to all of the messages channeled through the mediator computing device.

At block908, the process900involves receiving the message at a message receiver component (e.g., the message receiver component220) of the data transformer (e.g., the wellbore operation controller216). In an example, the mediator computing device may be integral to the data transformer, may be located within a separate wellbore operation controller, or may be a standalone device. In one or more examples, the mediator computing device may transmit the message to the data transformer through a wired or wireless connection.

At block910, the process900involves identifying details of a message header of the message received at the data transformer. The details of the message header may provide the data transformer with information usable to determine if the message is useful to the operations of the data transformer. For example, the data transformer may filter out messages that are unusable by the data transformer to perform transformation operations on the data.

At block912, the process900involves making a determination as to whether the message is filtered or accepted. If the message is not relevant to the data transformer, a determination is made to filter the message. When the message is filtered by the data transformer, the mediator computing device may receive a non-acknowledgement message, at block914, indicating that the message was not accepted by the data transformer. Upon receiving the non-acknowledgement message, the mediator computing device may make a note to cease future transmissions of messages with the same topic to the data transformer. Additionally, upon receiving the non-acknowledgement message at the mediator computing device, the process900may end at block916.

If, at block912, the message is accepted by the data transformer, then, at block916, the process900involves extracting data from the message. For example, the header information may be removed from the message envelope such that only the data remains. Once the data is extracted, at block918, the process900involves establishing that the data is ready for consumption. Establishing that the data is ready for consumption may involve transitioning the data from the message receiver component220to a data transformer component.

Accordingly, at block920, the process900involves determining whether the data extracted from the message is in raw binary form or serialized from a programming language-neutral format. Upon determining that the data is serialized, at block921, the process900involves deserializing the data prior to processing and transforming the data. After deserializing the data, or after determining that the data is in raw binary form, at block922, the process900involves attempting to process and transform the data. The data may be processed differently depending on the format of the data. For example, the data in the raw binary form may need further processing to generate data usable to the data transformer. In some examples, the data transformer may not be able to process and consume data in the raw binary form. Additionally, the data from a programming language-neutral format may generally rely on less processing for the data to be usable by the data consumer due to the data being in the programming language-neutral format.

At block923, the process900involves making a determination as to whether the data was transformed successfully by the data transformer. In an example, the data transformer may provide an indication to the mediator computing device that the data was not transformed using a non-acknowledgement message at block914, and the process may end at block916upon receipt of the non-acknowledgement message. If the data was transformed, at block924, the process900involves providing an indication to the message sender component (e.g., the message sender component218) of the data transformer that the transformed data is prepared for inclusion in a new message.

At block926, the process900involves identifying, at the message sender component, header information for the transformed data. The header information may describe, for example, what information the transformed data represents (e.g., microseismic acoustic data, hydraulic pumping telemetry, etc.) and the origination of the data (e.g., the well identifier, the equipment serial number, the probe identifier, etc.).

At block928, the process900involves compiling a message envelope. The message envelope may include the header information combined with the transformed data. Upon compiling the message envelope, the message envelope is ready, at block930, for publishing to the mediator computing device. Thus, at block932, the process900involves publishing the message (i.e., the message envelope) to the mediator computing device.

At block934, the process900involves receiving the message at the mediator computing device (e.g., the mediator computing device138ofFIG.1). As discussed above, the mediator computing device may be integral to the wellbore operation controller216, may be located within a separate wellbore operation controller204or210, or may be a standalone device. The message sender component may transmit the message to the mediator computing device through a wired or wireless connection.

At block936, the process900involves making a determination as to whether the message is valid. For example, the mediator computing device may determine that the message is somehow corrupted or is missing necessary elements for transmission of the message to other wellbore operation controllers. If the message is not valid, the message transmission process ends at block916.

If the message received by the mediator computing device is valid, at block938, the process900involves processing the message to be forwarded to each qualifying receiver. The qualifying receivers may be, for example, the wellbore operation controllers204or210that are subscribed to a type of data included within the message from the data transformer. Further, processing the message may be an indication that the message was not discarded, and the message is available for forwarding to receivers in communication with the mediator computing device138.

At block940, the process900involves determining if each of the receivers in communication with the mediator computing device is subscribed to the message's topic or subscribed to all messages from the mediator computing device. If a receiver is not subscribed to the message's topic or to all messages from the mediator computing device, the process900may end at block916.

If the receiver is subscribed to the message's topic or to all messages from the mediator computing device, at block942, the process900involves forwarding the message to each of the subscribed receivers. Once the message is forwarded to the subscribed receivers, the process900may end at block916.

At block944, the process900involves determining if the message is targeted for remote transfer. For example, the message may be targeted for transmission to one or more remote mediator computing devices. If the message is not targeted for transfer to a remote mediator computing device, the process900may end at block916.

If the message is targeted for transfer to a remote mediator computing device, at block946, the process900involves processing the message to be forwarded to each qualifying link to other remote mediator computing devices. The remote mediator computing devices receiving the message may be, for example, the remote mediator computing devices in communication with remote wellbore controllers that are subscribed to a type of data included within the message from the data transformer. Further, processing the message may be an indication that the message was not discarded, and the message is available for forwarding to remote mediator computing devices subscribed to the topic of the message.

At block948, the process900involves determining if the link is outgoing or bi-directional and subscribed to the message's topic. If the link is not outgoing or bi-directional or not subscribed to the message's topic, the process900may end at block916. If the link is outgoing or bi-directional and subscribed to the message's topic, at block950, the message is forwarded using each of the qualifying links to the remote mediator computing devices. Upon completion of forwarding the message to the qualifying links, the process900may end at block916.

FIG.10is a flowchart of an example process1000for broadcasting a message from a local mediator computing device (e.g., the mediator computing device138a) to other remote mediator computing devices (e.g., the mediator computing device138b). Initially, at blocks1002a,1002b, and1002c, the process1000involves the wellbore operation controllers204,216, and210each beginning the deployment and broadcasting process1000. In the process1000, each of the wellbore operation controllers204(e.g., a data producer),216(e.g., a data transformer), and210(e.g., a data consumer) provides indications to a local mediator computing device (e.g., the mediator computing device138) of a type of topics transmitted or consumed by the wellbore operation controllers204,216, and210.

At blocks1004a,1004b, and1004c, the process1000involves the wellbore operation controllers204,216, and210deploying onto the infrastructure of the mediator computing device138. For example, the wellbore operation controllers204,216, and210provide indications of intent to transmit data to other devices as mediator applications through the mediator computing device138. At block1006, the process1000involves the mediator computing device138accepting the mediator application deployments of the wellbore operation controllers204,216, and210.

At blocks1008aand1008b, the process1000involves the wellbore operation controllers204and216transmitting indications of topics for publication at the mediator computing device138. In an example, the topics for publication provided by the wellbore operation controllers204and216provide an indication of the type of data produced or transformed by the wellbore operation controllers204and216. This information may be used to generate links between mediator computing devices. At block1010, the process1000involves the mediator computing device138accepting the transmission topics from the wellbore operation controllers204and216.

At blocks1012a, the process1000involves the wellbore operation controller216transmitting indications of topics of data that the wellbore operation controller216is able to transform. Similarly, at block1012b, the process1000involves the wellbore operation controller210transmitting indications of topics of data that the wellbore operation controller210is able to consume. At block1014, the process1000involves the mediator computing device138accepting the transformation and consumption topics from the wellbore operation controllers216and210.

At block1016, the process1000involves the mediator computing device broadcasting the mediator applications and topics for publication, transformation, and consumption to remote mediator computing devices across a local area network. Based on the broadcast mediator applications and topics, at block1018, the process1000involves creating incoming, outgoing, and bi-directional links to and from the remote mediator computing devices that are bound to the topics transmitted by the mediator computing device138. Upon creating the links between the mediator computing device138and the remote mediator computing devices, the process1000may end at block1020.

FIG.11is a flowchart of an example process1100for generating a link between a local mediator computing device138aand a remote mediator computing device138b. At blocks1102a,1102b, and1102c, the process1100involves the wellbore operation controllers204,210, and216starting the process1100for creating links with the remote mediator computing device138b. The links created by the process1100with the remote mediator computing device138bmay provide a path for data exchange between the local mediator computing device138aand the remote mediator computing device138b.

At blocks1104a,1104b, and1104c, the process1100involves the wellbore operation controllers204,210, and216requesting information on data topics that the wellbore operation controllers204,210, and216are able to generate, consume, or transform. For example, the wellbore operation controller204(e.g., a data producer) may request information about topics that are requested for consumption from the remote mediator computing device138b. The wellbore operation controller210(e.g., a data consumer) may request information about topics that the wellbore operation controller210would like to consume from the remote mediator computing device138b. Further, the wellbore operation controller216(e.g., a data transformer) may request information about topics that are requested for consumption from the remote mediator computing device138band the topics that the wellbore operation controller216would like to consume from the remote mediator computing device138b.

At block1106, the process1100involves accepting requests for the remote topics that are published, requested, or both to and from the remote mediator computing device or devices138b. Based on these accepted requests, at block1108, the process1100involves the remote mediator computing device138aresponding with the requested topic information from the remote mediator computing devices138b, and, at blocks1110a,1110b, and1110c, the process1100involves receiving the requested topic information at the wellbore operation controllers204,210, and216. The requested topic information may include topics of data that the remote mediator computing devices138bwould like to receive from the local mediator computing device138aand topics of data that the remote mediator computing devices138bare able to provide the local mediator computing device138a.

Based on the requested topic information received at the wellbore operation controller204, at block1112a, the process1100involves requesting an outbound link to the remote mediator computing device138b. Based on the requested topic information received at the wellbore operation controller210, at block1112b, the process1100involves requesting an inbound link from the remote mediator computing device138b. Further, based on the requested topic information received at the wellbore operation controller216, at block1112c, the process1100involves requesting an inbound link, an outbound link, or a bi-directional link with the remote mediator computing device138b. The requested links between the local mediator computing device138aand the remote mediator computing device138bmay facilitate the data transmission, data consumption, and data transformation processes of the wellbore operation controllers204,210, and216by providing access to additional streams of data from the remote mediator computing device138b. At block1114, the process1100involves receiving, at the local mediator computing device138a, the requests for the links to the remote mediator computing device or devices138bfrom the wellbore operation controllers204,210, and216.

At block1116, the process1100involves the local mediator computing device138acreating a data feed to the remote mediator computing device or devices138band binding the data feed to the topics to be sent to the remote mediator computing devices138b. Such a link may be generated when the requested link from one or more of the wellbore operation controllers (e.g., a data producer, a data transformer, or both) is an outbound or bi-directional link.

At block1118, the process1100involves the local mediator computing device138acontacting the remote mediator computing device or devices138bto request a data feed bound to the topics to be sent to the local mediator computing devices138a. Such a link may be requested when the requested link from one or more of the wellbore operation controllers (e.g., a data consumer, a data transformer, or both) is an inbound or bi-directional link.

At block1120, the process1100involves creating, at the remote mediator computing device138ba data feed link to the local mediator computing device138a. The remote mediator computing device138bmay also bind the data feed to the topics to be sent to the local mediator computing device138a. At block1122, the process1100involves informing the local mediator computing device138aof the successful data feed creation.

At block1124, the process1100involves the local mediator computing device138ainforming the wellbore operation controllers204,210, and216(e.g., the requesting applications) of the successful data feed link creation with the remote mediator computing device138b. At blocks1126a,1126b, and1126c, the process1100involves receiving the data feed link confirmation at the wellbore operation controllers204,210, and216. Upon receiving the data feed link confirmation at the wellbore operation controllers204,210, and216, the process1100may end at block1128a,1128b, and1128c.

The use of “based on” is meant to be open and inclusive, in that a process, step, calculation, or other action “based on” one or more recited conditions or values may, in practice, be based on additional conditions or values beyond those recited. Headings, lists, and numbering included herein are for ease of explanation only and are not meant to be limiting.

In some aspects, systems, devices, and methods for operating wellbore equipment using a data-driven physics-based process are provided according to one or more of the following examples:

Example 1 is a system comprising: a first wellbore operation controller for controlling a wellbore operation and for generating a first broadcast indicating a first data topic desired for controlling the wellbore operation; a second wellbore operation controller for generating a data stream of data associated with a wellbore and for generating a second broadcast indicating a second data topic that promotes the data of the data stream; and a mediator computing device positionable to: receive the first broadcast from the first wellbore operation controller and the second broadcast from the second wellbore operation controller; determine that the first wellbore operation controller is subscribed to the data stream of the second wellbore operation controller by comparing the first data topic to the second data topic; and in response to determining that the first wellbore operation controller is subscribed to the data stream of the second wellbore operation controller, create a data link between the first wellbore operation controller and the second wellbore operation controller to provide the data associated with the wellbore to the first wellbore operation controller.

Example 2 is the system of example 1, wherein the first wellbore operation controller adjusts the wellbore operation based on the data associated with the wellbore received from the second wellbore operation controller.

Example 3 is the system of examples 1-2, wherein the wellbore operation comprises forming a wellbore, stimulating the wellbore, or producing fluid from the wellbore.

Example 4 is the system of examples 1-3, wherein the data associated with the wellbore is transformed into a programming language-neutral format prior to providing the data associated with the wellbore to the first wellbore operation controller.

Example 5 is the system of example 4, wherein the data associated with the wellbore comprises microseismic acoustic data and the wellbore operation comprises a hydraulic fracturing operation.

Example 6 is the system of examples 1-5, wherein the mediator computing device is further positionable to: create an additional data link between the second wellbore operation controller and a third wellbore operation controller, wherein the data associated with the wellbore comprises transformed data, and wherein the second wellbore operation controller transforms source data originating from the third wellbore operation controller to generate the transformed data.

Example 7 is the system of examples 1-6, wherein the mediator computing device is further positionable to connect with additional wellbore operation controllers in a pluggable manner without recompiling a base stack of a stack data structure of the mediator computing device.

Example 8 is the system of examples 1-7, wherein the mediator computing device is further positionable to connect with remote mediator computing devices by creating remote data links between the mediator computing device and the remote mediator computing devices to provide additional data streams from the remote mediator computing device to the first wellbore operation controller or the second wellbore operation controller.

Example 9 is a method comprising: transmitting, to a mediator computing device, a first broadcast indicating a first data topic desired for controlling an operation associated with forming a well, stimulating a wellbore, or producing fluid from the wellbore; receiving a message from the mediator computing device originating from a data producer; determining that the message is filtered or accepted; in response to determining that the message is filtered, discarding the message; in response to determining that the message is accepted: extracting data from the message; processing and consuming the data; and adjusting an equipment control process using the data.

Example 10 is the method of example 9, wherein the equipment control process comprises forming the wellbore, stimulating the wellbore, or producing the fluid from the wellbore.

Example 11 is the method of examples 9-10, wherein the data of the message is transformed into a programming language-neutral format prior to receiving the message from the mediator computing device.

Example 12 is the method of example 9-11, wherein the data extracted from the message comprises microseismic acoustic data and the equipment control process comprises a hydraulic fracturing operation.

Example 13 is the method of examples 9-12, further comprising: receiving an additional message from the mediator computing device originating from an additional data producer; determining if the additional message is filtered or accepted; if the additional message is accepted, extracting additional data from the additional message; processing and consuming the additional data; and adjusting the equipment control process using the data and the additional data.

Example 14 is the method of examples 9-13, further comprising: communicatively connecting with the mediator computing device in a pluggable manner without recompiling a base stack of a stack data structure of the mediator computing device.

Example 15 is a non-transitory computer-readable medium that includes instructions that are executable by a processing device to perform operations controlling equipment associated with a wellbore, the operations comprising: transmitting, to a mediator computing device, a first broadcast indicating a first data topic desired for controlling an operation associated with forming a well, stimulating a wellbore, or producing fluid from the wellbore; receiving a message from the mediator computing device originating from a data producer; determining that the message is filtered or accepted; in response to determining that the message is accepted, extracting data from the message; processing and consuming the data; and adjusting an equipment control process using the data.

Example 16 is the non-transitory computer-readable medium of example 15, wherein the equipment control process comprises forming the wellbore, stimulating the wellbore, or producing the fluid from the wellbore.

Example 17 is the non-transitory computer-readable medium of examples 15-16, wherein the data producer comprises a remote mediator computing device linked with the mediator computing device.

Example 18 is the non-transitory computer-readable medium of examples 15-17, the operations further comprising: filtering the message when a second data topic from a message header of the message does not match the first data topic of the first broadcast.

Example 19 is the non-transitory computer-readable medium of example 15-18, the operations further comprising: communicatively connecting with the mediator computing device in a pluggable manner without recompiling a base stack of a stack data structure of the mediator computing device.

Example 20 is the non-transitory computer-readable medium of example 15-19, the operations further comprising: receiving an additional message from the mediator computing device originating from an additional data producer; determining if the additional message is filtered or accepted; if the additional message is accepted, extracting additional data from the additional message; processing and consuming the additional data; and adjusting the equipment control process using the data and the additional data.