Enabling multi-application execution with ai-driven workflows for drilling operations

Abstract

A method for executing multiple applications related to a drilling operation. The method includes aggregating data related to a wellsite, the aggregated data being received from a plurality of sources including equipment disposed within the wellsite and outside systems communicated to the wellsite. The aggregated data is stored within a shared domain service layer of a database, and may be harmonized using a virtual channel. A recommendation or predictive insight based on the stored data may be generated in addition to a command being autonomously sent to the equipment disposed at the wellsite. A wellsite action may then be performed that is based on the stored data. The steps of aggregating the data, storing the aggregated data, generating a recommendation, autonomously sending a command, generating a predictive insight, and performing the wellsite action may be done on the same equipment or edge device disposed at the wellsite.

Description

PATENT Attorney Docket No.: IS24.1672-WOENABLING MULTI-APPLICATION EXECUTION WITH AI-DRIVEN WORKFLOWSFOR DRILLING OPERATIONSCross-Reference to Related Applications

[0001] This patent application claims priority to U.S. Provisional Patent Application No. 63 / 714320, filed on October 31, 2024, which is incorporated by reference.Background

[0002] The ongoing adoption of digitization in the oil and gas sector, especially within drilling operations, has accelerated the deployment of digital technologies in the field. With this rapid growth, an effective framework to proactively monitor field deployments and enhance operational resilience would be beneficial. Previously, an advanced monitoring system featuring Elastic Fleet Management was introduced, combining real-time performance tracking with incident alerting capabilities integrated with tools such as Software as a Service (SaaS) incident management platforms. This approach established new benchmarks for reducing Non-Productive Time (NPT) and improving service delivery by providing Site Reliability Engineering (SRE) teams with tools to maintain high standards amid continuous expansion.

[0003] In the evolving landscape of drilling technologies, automation has emerged as a driver for improving efficiency, safety, and operational performance. For nearly a decade, the oil and gas industry has focused on deploying advanced tools such as rig mechanization, robotics, and AI- driven automation to optimize drilling operations. However, the full potential of these systems is still being realized, as delivering consistent financial savings and efficiency gains remains a challenge. The complexities of drilling operations, especially in remote and offshore environments, could use a comprehensive approach to automation that goes beyond traditional methods. It is not just about deploying the right tools but about creating a system that enhances overall performance, reduces tool runs, and adds measurable value to the bottom line.

[0004] To achieve these goals, integrating edge computing has become useful. By bringing AI- powered analytics and advanced processing closer to the operational environment, edge computing addresses the unique challenges of drilling automation. However, this also introduces cybersecurity risks, particularly when solutions are deployed on Operational Technology (OT) networks with restrictive access. Ensuring the security of these deployments is relevant, as itPATENT Attorney Docket No.: IS24.1672-WO involves managing who accesses devices, detecting any unusual activities, and responding swiftly to incidents like reboots or suspicious network connections.

[0005] Observability, while a well-established concept in cloud computing, poses a different set of challenges when applied to edge environments. The complexity of rig networks, combined with bandwidth limitations, makes it difficult for centralized support teams to maintain a clear picture of what is happening at the edge. With support teams often located remotely and not at the rig site, it becomes useful to provide real-time visibility into the status of devices and operations. To address these challenges, a flexible fleet management system has been implemented that enables proactive monitoring of edge deployments. This approach may ensure that support teams may detect anomalies, track access and activity, and manage the performance of devices from a central location, setting the stage for a quick and effective response. However, even with fleet management providing proactive monitoring, network isolation still poses challenges, as it limits the ability of SRE support teams to connect directly to edge devices.

[0006] Energy exploration digital platforms tackle drilling challenges by connecting the rig to town and automating operations through Al-driven solutions. Real-time connectivity and data- driven insights enable collaboration and performance. With global commercial deployments, its innovative platform sets the standard in drilling efficiency and sustainability. The energy exploration platform leverages cutting-edge technology and an experimental mindset to revolutionize drilling operations. For example, cloud-edge integration enables seamless connectivity and real-time collaboration between the wellsite and the office across the MWD (Measurement While Drilling), DD (Directional Drilling), surface logging, fluids, procedural adherence, and drilling domains. Additionally, Al-driven drilling automation brings enhanced safety, performance, and consistency to the drilling operation while data-driven insights, empower operators to overcome the limitations of traditional drilling practices, unlocking new levels of efficiency, safety, and sustainability. Furthermore, the energy exploration platform provides a modular design, thereby enabling scaling and distributed development of the system using plugins.

[0007] The energy exploration platform solution adopts a goal-based automation methodology, using powerful data analysis and learning systems to assist and optimize every task, from setting rate of penetration to drilling a stand. Users may choose from a preset menu of automatable drilling tasks, and using data analysis and models, share a plan to achieve the specified goal, taking anyPATENT Attorney Docket No.: IS24.1672-WO measurements required to calibrate itself. Operators have the flexibility to modify and replan activities dynamically, based on a live appraisal of equipment, personnel, and supplies.

[0008] Automation enables reduced staffing levels on mechanized rigs and delivers unparalleled consistency of repetitive tasks, helping users reach the technical limit on every well. Alert and escalate procedures are built directly into the energy exploration platform solution — making it easier to resolve any potential conflicts and administer corrective action. Everything that happens is automatically documented within the digital well file to streamline reporting and drive continuous improvement.

[0009] The energy exploration platform solution may be used to monitor and capture a broad range of operational data to support operators during drilling with real-time advice and coaching to improve decision-making and reduce risk. Intelligent advisory systems guide crews to stay within operating windows and safety thresholds. Predictive analytics continuously identify drilling dysfunctions, alerting personnel before pre-defined limits are due to be exceeded to reduce nonproductive time (NPT).

[0010] Progress may be continually compared with targets defined in the drilling plan across a range of criteria, including operating costs and other key performance indicators, to deliver a live picture of performance. Any deviations from the plan are recorded in the digital well file, alongside all the relevant operational data. By capturing the full operational context across multiple domains, the energy exploration platform solution may increase the value of reporting and post-job analysis to improve every subsequent well.

[0011] The energy exploration platform solution may execute the digital drilling plan and ensure plan adherence. It may further improve collaboration and coordination by directing the relevant information to the right people, at the right time, and always in the right context. Since workflows are curated centrally by the system, step-by-step activity plans are automatically generated for individual operations teams to keep all teams aligned. With all well construction activities from tripping to cementing continually monitored and dynamically updated with the latest operational activity, the operations team is always up to date.

[0012] The integration of all data into one system by utilizing relevant downhole tool data and surface measurements combine to make the best use of the information available. Step-by-step simplified workflows, reduction of human dependencies, and transformation of how directional and data services are delivered, enable a consistent approach.PATENT Attorney Docket No.: IS24.1672-WO

[0013] These simplified workflows may include automation where Al-driven workflows take control of rig equipment, allowing autonomous execution of drilling tasks. The system may adapt to changing drilling conditions within predefined limits, ensuring consistent performance. Another workflow may include remote operation which delivers real-time optimized experience of what is happening in the rig in town. Advisory workflows deliver real-time optimized parameters to the driller, providing smart Al-driven recommendations for both drilling and tripping workflows. This improves decision-making and operational efficiency. Data aggregation workflows aggregate data from multiple sources (surface, downhole, equipment) into a single ecosystem, enabling real-time visualization and analysis. The system supports WITSML, OPC-UA, Modbus, and other standard protocols. Procedural adherence workflows ensure that well-construction plans are followed through a set of digital workflows, providing real-time updates on task completion and adherence to corporate guidelines. Predictive analytics workflows combine Al with domain models to deliver real-time monitoring, alerts, and recommendations to optimize drilling performance. The system flags out-of-spec conditions and recommends corrective actions. Neuro autonomous solution DD advisor workflows provide an Al-driven solution which may autonomously analyze real-time drilling data to provide optimized directional drilling decisions, enhancing operational efficiency and precision without human intervention.Summary

[0014] According to certain embodiments, an Al-powered framework is provided that goes beyond traditional observability. Leveraging autonomous capabilities, the system may intelligently analyze a wide range of logs — including software, system, and firewall activities — enabling proactive issue detection and self-management. Generative Al (GenAI) enhancements may be deployed, the generative Al capable of identifying anomalies and autonomously resolving detected issues without manual user intervention. This approach marks a shift towards fully selfmanaging operations, setting the stage for a transformative leap in operational efficiency, safety, and service quality across geographically distributed drilling sites. The current system may use a fleet management system to monitor system metrics such as CPU usage, memory usage, disk space, and network traffic in real-time. However, the need for manual remote connections to field devices or wellsite equipment for troubleshooting has resulted in slower ticket resolution times and operational inefficiencies.PATENT Attorney Docket No.: IS24.1672-WO

[0015] According to certain embodiments, a method is provided for simultaneously executing multiple workflows related to a drilling operation. The method includes aggregating data related to a wellsite at an edge device disposed at the wellsite, storing the data within a shared domain service layer of the edge device, and transmitting a composite channel based on the data to a shared domain service layer of a cloud device. The method further includes performing a first workflow based on the data in the shared domain service later of the edge device, performing a second workflow based on the composite channel in the shared domain service layer of the cloud device simultaneously as the first workflow is performed in the edge device, and performing a wellsite action based on the first workflow and the second workflow.

[0016] Also provided is a computing system having one or more processors and a memory system. The memory system includes one or more non-transitory computer-readable media storing instructions that, when executed by at least one of the one or more processors, cause the computing system to perform operations. The operations include aggregating data related to a wellsite at an edge device disposed at the wellsite, storing the data within a shared domain service layer of the edge device, and transmitting a composite channel based on the data to a shared domain service layer of a cloud device. The operations further include performing a first workflow based on the data in the shared domain service later of the edge device, performing a second workflow based on the composite channel in the shared domain service layer of the cloud device simultaneously as the first workflow is performed in the edge device, and performing a wellsite action based on the first workflow and the second workflow.

[0017] Also provided is a non-transitory computer-readable medium storing instructions that, when executed by one or more processors of a computing system, cause the computing system to perform operations. The operations include aggregating data related to a wellsite at an edge device disposed at the wellsite, storing the data within a shared domain service layer of the edge device, and transmitting a composite channel based on the data to a shared domain service layer of a cloud device. The operations further include performing a first workflow based on the data in the shared domain service later of the edge device, performing a second workflow based on the composite channel in the shared domain service layer of the cloud device simultaneously as the first workflow is performed in the edge device, and performing a wellsite action based on the first workflow and the second workflow.PATENT Attorney Docket No.: IS24.1672-WO

[0018] Brief Description of the Drawings

[0019] The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments of the present teachings and together with the description, serve to explain the principles of the present teachings. In the figures:

[0020] Figure 1 illustrates an example of a system that includes various management components to manage various aspects of a geologic environment, according to an embodiment.

[0021] Figure 2 illustrates a schematic diagram representing edge and cloud infrastructures for implementing the current method, according to an embodiment.

[0022] Figure 3 illustrates a schematic diagram representing a ELK stack for implementing the current method, according to an embodiment.

[0023] Figure 4 illustrates a flowchart for detecting an anomaly using the current method, according to an embodiment.

[0024] Figure 5 illustrates a schematic diagram representing how a log is embedded into a 384- dimension vector, according to an embodiment.

[0025] Figure 6 illustrates a series of plots for a variety of different similarity metrics used by the current method, according to an embodiment.

[0026] Figure 7 illustrates a series of t-distributed Stochastic Neighbor Embedding (t-SNE) plots of the normal and abnormal logs, according to an embodiment.

[0027] Figure 8 illustrates a graphical interface displaying the results of an anomaly detection process performed by the current method, according to an embodiment.

[0028] Figure 9 illustrates a schematic diagram of an architecture of the autonomous anomaly detection and resolution process performed by the current method, according to an embodiment.

[0029] Figure 10 illustrates a flowchart for resolving a firewall anomaly used by the current method, according to an embodiment.

[0030] Figure 11 illustrates a graphical interface displaying a document generated by the current method which details the steps included for resolving a firewall anomaly, according to an embodiment.

[0031] Figure 12 illustrates a flowchart of a large language model used by the current method, according to an embodiment.

[0032] Figure 13 illustrates a schematic diagram of a large language model powered agent used by the current method, according to an embodiment.PATENT Attorney Docket No.: IS24.1672-WO

[0033] Figure 14 illustrates a schematic diagram of the architecture of the current method employing a large language model powered agent, according to an embodiment.

[0034] Figure 15 illustrates a graphical interface of an example of a generational Al agent executing the current method, according to an embodiment.

[0035] Figure 16 illustrates a graphical interface of an example of a generational Al adding a firewall, according to an embodiment.

[0036] Figure 17 illustrates a flowchart of the contextual data required to perform workflows related to a drilling operation, according to an embodiment.

[0037] Figure 18 illustrates a flowchart demonstrating product incompatibility, data duplication and streaming, complex network settings, mismatched data formats, and hardware duplication encountered when not implementing centralized or unified handling of data for multiple workflows, according to an embodiment.

[0038] Figure 19 illustrates a flowchart of the architecture used by the current method, according to an embodiment.

[0039] Figure 20 illustrates a diagram of a composite channel being composed of data from two raw channels, according to an embodiment.

[0040] Figure 21 illustrates a exemplary channel composite structure, according to an embodiment.

[0041] Figure 22 illustrates a flowchart of channel data flow used in the current method, according to an embodiment.

[0042] Figure 23 illustrates a flowchart of a method for executing multiple applications related to a drilling operation, according to an embodiment.

[0043] Figure 24 illustrates a schematic view of a computing system for performing at least a portion of the method(s) described herein, according to an embodiment.Detailed Description

[0044] Reference will now be made in detail to embodiments, examples of which are illustrated in the accompanying drawings and figures. However, it will be apparent to one of ordinary skill in the art that the invention may be practiced without these specific details. In other instances, well-known methods, procedures, components, circuits, and networks have not been described in detail so as not to unnecessarily obscure aspects of the embodiments.PATENT Attorney Docket No.: IS24.1672-WO

[0045] It will also be understood that, although the terms first, second, etc. may be used herein to describe various elements, these elements should not be limited by these terms. These terms are only used to distinguish one element from another. For example, a first object or step could be termed a second object or step, and, similarly, a second object or step could be termed a first object or step, without departing from the scope of the present disclosure. The first object or step, and the second object or step, are both, objects or steps, respectively, but they are not to be considered the same object or step.

[0046] The terminology used in the description herein is for the purpose of describing particular embodiments and is not intended to be limiting. As used in this description and the appended claims, the singular forms “a,” “an” and “the” are intended to include the plural forms as well, unless the context clearly indicates otherwise. It will also be understood that the term “and / or” as used herein refers to and encompasses any possible combinations of one or more of the associated listed items. It will be further understood that the terms “includes,” “including,” “comprises” and / or “comprising,” when used in this specification, specify the presence of stated features, integers, steps, operations, elements, and / or components, but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and / or groups thereof. Further, as used herein, the term “if’ may be construed to mean “when” or “upon” or “in response to determining” or “in response to detecting,” depending on the context.

[0047] Attention is now directed to processing procedures, methods, techniques, and workflows that are in accordance with some embodiments. Some operations in the processing procedures, methods, techniques, and workflows disclosed herein may be combined and / or the order of some operations may be changed.System OverviewPATENT Attorney Docket No.: IS24.1672-WO

[0048] Figure 1 illustrates an example of a system 100 that includes various management components 110 to manage various aspects of a geologic environment 150 (e.g., an environment that includes a sedimentary basin, a reservoir 151, one ormore faults 153-1, one or more geobodies 153-2, etc.). For example, the management components 110 may allow for direct or indirect management of sensing, drilling, injecting, extracting, etc., with respect to the geologic environment 150. In turn, further information about the geologic environment 150 may become available as feedback 160 (e.g., optionally as input to one or more of the management components 110).

[0049] In the example of Figure 1, the management components 110 include a seismic data component 112, an additional information component 114 (e.g., well / logging data), a processing component 116, a simulation component 120, an attribute component 130, an analysis / visualization component 142 and a workflow component 144. In operation, seismic data and other information provided per the components 112 and 114 may be input to the simulation component 120.

[0050] In an example embodiment, the simulation component 120 may rely on entities 122. Entities 122 may include earth entities or geological objects such as wells, surfaces, bodies, reservoirs, etc. In the system 100, the entities 122 may include virtual representations of actual physical entities that are reconstructed for purposes of simulation. The entities 122 may include entities based on data acquired via sensing, observation, etc. (e.g., the seismic data 112 and other information 114). An entity may be characterized by one or more properties (e.g., a geometrical pillar grid entity of an earth model may be characterized by a porosity property). Such properties may represent one or more measurements (e.g., acquired data), calculations, etc.

[0051] In an example embodiment, the simulation component 120 may operate in conjunction with a software framework such as an object-based framework. In such a framework, entities may include entities based on pre-defined classes to facilitate modeling and simulation. A commercially available example of an object-based framework is the MICROSOFT® .NET® framework (Redmond, Washington), which provides a set of extensible object classes. In the .NET® framework, an object class encapsulates a module of reusable code and associated data structures. Object classes may be used to instantiate object instances for use in by a program, script, etc. For example, borehole classes may define objects for representing boreholes based on well data.PATENT Attorney Docket No.: IS24.1672-WO

[0052] In the example of Figure 1, the simulation component 120 may process information to conform to one or more attributes specified by the attribute component 130, which may include a library of attributes. Such processing may occur prior to input to the simulation component 120 (e.g., consider the processing component 116). As an example, the simulation component 120 may perform operations on input information based on one or more attributes specified by the attribute component 130. In an example embodiment, the simulation component 120 may construct one or more models of the geologic environment 150, which may be relied on to simulate behavior of the geologic environment 150 (e.g., responsive to one or more acts, whether natural or artificial). In the example of Figure 1, the analysis / visualization component 142 may allow for interaction with a model or model-based results (e.g., simulation results, etc.). As an example, output from the simulation component 120 may be input to one or more other workflows, as indicated by a workflow component 144.

[0053] As an example, the simulation component 120 may include one or more features of a simulator such as the ECLIPSE™ reservoir simulator (SLB, Houston Texas), the INTERSECT™ reservoir simulator (SLB, Houston Texas), etc. As an example, a simulation component, a simulator, etc. may include features to implement one or more meshless techniques (e.g., to solve one or more equations, etc.). As an example, a reservoir or reservoirs may be simulated with respect to one or more enhanced recovery techniques (e.g., consider a thermal process such as SAGD, etc ).

[0054] As an example, the simulation component 120 may include one or more features of a simulator such as SYMMETRY™ software (SLB, Houston, Texas). More particularly, SYMMETRY™ may process workflows in a single integrated environment with accurate thermodynamic fluid representation and consistent modeling across multiple disciplines including process, production, and HSE. The simulator integrates steady-state and transient (e.g., dynamic) analyses that may be tailored for each domain. This approach enables users to optimize processes in upstream, midstream, and downstream sectors while maximizing profits and minimizing capital expenditures. It may also help reduce emissions, energy consumption, and waste.

[0055] As an example, the simulation component 120 may include one or more features of a simulator such as PIPESIM™ (SLB, Houston, Texas). More particularly, PIPESIM™ is steadystate multiphase flow simulator that incorporates the three areas of flow modeling: multiphase flow, heat transfer and fluid behavior.PATENT Attorney Docket No.: IS24.1672-WO

[0056] As an example, the simulation component 120 may include one or more features of a simulator such as OLGA™ (SLB, Houston, Texas). More particularly, OLGA™ is a dynamic multiphase flow simulator that models transient flow (e.g., time-dependent behaviors) to maximize production potential. Transient modeling is a component for feasibility studies and field development design. Dynamic simulation is useful in deep water and is used in both offshore and onshore developments to investigate transient behavior in pipelines and wellbores. Transient simulation with the OLGA™ simulator provides an added dimension to steady-state analysis by predicting system dynamics, such as time-varying changes in flow rates, fluid compositions, temperature, solids deposition, and operational changes.

[0057] In an example embodiment, the management components 110 may include features of a commercially available framework such as the PETREL® seismic to simulation software framework (SLB, Houston, Texas). The PETREL® framework provides components that allow for optimization of exploration and development operations. The PETREL® framework includes seismic to simulation software components that may output information for use in increasing reservoir performance, for example, by improving asset team productivity. Through use of such a framework, various professionals (e.g., geophysicists, geologists, and reservoir engineers) may develop collaborative workflows and integrate operations to streamline processes. Such a framework may be considered an application and may be considered a data-driven application (e.g., where data is input for purposes of modeling, simulating, etc.).

[0058] In an example embodiment, various aspects of the management components 110 may include add-ons or plug-ins that operate according to specifications of a framework environment. For example, a commercially available framework environment marketed as the OCEAN® framework environment (SLB, Houston, Texas) allows for integration of add-ons (or plug-ins) into a PETREL® framework workflow. The OCEAN® framework environment leverages .NET® tools (Microsoft Corporation, Redmond, Washington) and offers stable, user-friendly interfaces for efficient development. In an example embodiment, various components may be implemented as add-ons (or plug-ins) that conform to and operate according to specifications of a framework environment (e.g., according to application programming interface (API) specifications, etc.).

[0059] Figure 1 also shows an example of a framework 170 that includes a model simulation layer 180 along with a framework services layer 190, a framework core layer 195 and a modules layer 175. The framework 170 may include the commercially available OCEAN® frameworkPATENT Attorney Docket No.: IS24.1672-WO where the model simulation layer 180 is the commercially available PETREL® model-centric software package that hosts OCEAN® framework applications. In an example embodiment, the PETREL® software may be considered a data-driven application. The PETREL® software may include a framework for model building and visualization.

[0060] As an example, a framework may include features for implementing one or more mesh generation techniques. For example, a framework may include an input component for receipt of information from interpretation of seismic data, one or more attributes based at least in part on seismic data, log data, image data, etc. Such a framework may include a mesh generation component that processes input information, optionally in conjunction with other information, to generate a mesh.

[0061] In the example of Figure 1, the model simulation layer 180 may provide domain objects 182, act as a data source 184, provide for rendering 186 and provide for various user interfaces 188. Rendering 186 may provide a graphical environment in which applications may display their data while the user interfaces 188 may provide a common look and feel for application user interface components.

[0062] As an example, the domain objects 182 may include entity objects, property objects and optionally other objects. Entity objects may be used to geometrically represent wells, surfaces, bodies, reservoirs, etc., while property objects may be used to provide property values as well as data versions and display parameters. For example, an entity object may represent a well where a property object provides log information as well as version information and display information (e.g., to display the well as part of a model).

[0063] In the example of Figure 1, data may be stored in one or more data sources (or data stores, generally physical data storage devices), which may be at the same or different physical sites and accessible via one or more networks. The model simulation layer 180 may be configured to model projects. As such, a particular project may be stored where stored project information may include inputs, models, results and cases. Thus, upon completion of a modeling session, a user may store a project. At a later time, the project may be accessed and restored using the model simulation layer 180, which may recreate instances of the relevant domain objects.

[0064] In the example of Figure 1, the geologic environment 150 may include layers (e.g., stratification) that include a reservoir 151 and one or more other features such as the fault 153-1, the geobody 153-2, etc. As an example, the geologic environment 150 may be outfitted with anyPATENT Attorney Docket No.: IS24.1672-WO of a variety of sensors, detectors, actuators, etc. For example, equipment 152 may include communication circuitry to receive and to transmit information with respect to one or more networks 155. Such information may include information associated with downhole equipment 154, which may be equipment to acquire information, to assist with resource recovery, etc. Other equipment 156 may be located remote from a well site and include sensing, detecting, emitting or other circuitry. Such equipment may include storage and communication circuitry to store and to communicate data, instructions, etc. As an example, one or more satellites may be provided for purposes of communications, data acquisition, etc. For example, Figure 1 shows a satellite in communication with the network 155 that may be configured for communications, noting that the satellite may additionally or instead include circuitry for imagery (e.g., spatial, spectral, temporal, radiometric, etc.).

[0065] Figure 1 also shows the geologic environment 150 as optionally including equipment 157 and 158 associated with a well that includes a substantially horizontal portion that may intersect with one or more fractures 159. For example, consider a well in a shale formation that may include natural fractures, artificial fractures (e.g., hydraulic fractures) or a combination of natural and artificial fractures. As an example, a well may be drilled for a reservoir that is laterally extensive. In such an example, lateral variations in properties, stresses, etc. may exist where an assessment of such variations may assist with planning, operations, etc. to develop a laterally extensive reservoir (e.g., via fracturing, injecting, extracting, etc ). As an example, the equipment 157 and / or 158 may include components, a system, systems, etc. for fracturing, seismic sensing, analysis of seismic data, assessment of one or more fractures, etc.

[0066] As mentioned, the system 100 may be used to perform one or more workflows. A workflow may be a process that includes a number of worksteps. A workstep may operate on data, for example, to create new data, to update existing data, etc. As an example, a may operate on one or more inputs and create one or more results, for example, based on one or more algorithms. As an example, a system may include a workflow editor for creation, editing, executing, etc. of a workflow. In such an example, the workflow editor may provide for selection of one or more predefined worksteps, one or more customized worksteps, etc. As an example, a workflow may be a workflow implementable in the PETREL® software, for example, that operates on seismic data, seismic attribute(s), etc. As an example, a workflow may be a process implementable in thePATENT Attorney Docket No.: IS24.1672-WOOCEAN® framework. As an example, a workflow may include one or more worksteps that access a module such as a plug-in (e g., external executable code, etc.).

[0067] A network architecture 200 for drilling operations involves a multi-layered setup designed to handle the complexities of rig environments, as shown in Figure 2. The infrastructure may be segmented into distinct network zones, such as an information technology (IT) network 202, an operational technology (OT) network 204, and a rig network 206, to ensure security and manageability.

[0068] The IT network 202 may include centralized support and monitoring systems, such as the Service Provider Central Support Network 208, which interacts with the rig network 206 via secure communication channels. The OT network 204 may operate within a more restrictive environment, managing essential control systems and acquisition networks, including surface 210 and downhole 212 data acquisition devices. Each network segment is further isolated using firewalls 214 and hypervisor technologies, enabling network segmentation and perimeter security.

[0069] The rig network 206 connects edge devices 216, such as drilling control units, acquisition systems, and other wellsite equipment which perform various automation and data processing tasks. These edge devices 216 often operate with limited bandwidth, making it challenging to transmit large amounts of data in real time. Therefore, a robust strategy for monitoring and data collection is preferred to ensure efficient operation without overwhelming the network 200.

[0070] According to certain embodiments, to address the challenges associated with monitoring geographically distributed rigs and remote edge devices, a fleet management approach may be implemented. According to certain embodiments, the fleet management system may be an Elasticsearch-Logstash-Kibana (ELK)-based fleet management system, or other similar management system(s). An ELK stack, for example as seen in Figure 3, may enable comprehensive log and metric collection across all network layers. By integrating fleet management agents on edge devices, system and application logs, resource usage data, and network metrics may be gathered in real time. This setup allows the centralized support team or other users to proactively monitor the health and performance of the rigs.

[0071] The flexibility of a fleet management system is advantageous for operating in environments with constrained bandwidth. During field testing, metrics may be collected at carefully selected intervals to avoid excessive network load, ensuring compliance with Rig-to- Town latency requirements. For example, CPU metrics may be polled every 30 seconds, whilePATENT Attorney Docket No.: IS24.1672-WO memory and filesystem data were collected every 15 minutes, resulting in minimal traffic impact on the network.

[0072] The use of a fleet management system may also improve incident response capabilities by integrating alerting with tools like those provided by SaaS incident management platforms. This integration may enable the SRE team or other users to receive real-time alerts for anomalies or performance issues, allowing them to intervene proactively and prevent system downtime. The use of fleet monitoring tools in drilling operation and similar deployments indicates a shift towards more proactive support practices.

[0073] According to certain embodiments, logs are produced by software-driven applications running on various systems or devices to provide critical information that helps developers and system engineers analyze the system’s condition and status. They may also serve as an audit trail, documenting events in chronological order. Log analysis is often used to investigate incidents related to the system, such as defects or unauthorized access. By examining the logs, investigators may reconstruct the sequence of events leading to a particular incident or event. Through this analysis, system engineers or investigators aim to identify unusual or suspicious activities. However, detecting these anomalies requires time and expertise in spotting irregularities within the vast number of log entries.

[0074] One objective of performing analysis on logs is to facilitate the detection of anomalous activities so that immediate or corresponding remediation may be done to contain or remediate the issue recorded in the logs. This is part of the attempt to enhance system resiliency against system faults, degradation and intentionally induced cyber physical attacks. It may also be used to facilitate the investigation or analysis of what may have induced the occurrence of such anomalous activities. Due to the characteristics of logs, namely being voluminous, varied, and contextual, regular log analysis is difficult, warranting the need for automation. While rule or signature-based automation solution helps, the contextual or semantic complexity of logs limits its efficacy.

[0075] There are many Al algorithms for log analysis. Traditional Al algorithms, such as Support Vector Machines (SVM), have been applied for anomaly detection tasks. However, these methods have several challenges and constraints to deal with before they contribute to their intended objectives of keeping system resilient. For supervised models, there is the challenge of acquiring sufficient anomalous data points to train such models. For unsupervised models, it will be the ability to detect the variety and variations of anomalies in logs.PATENT Attorney Docket No.: IS24.1672-WO

[0076] In contrast, embedding models may offer a more resource-efficient solution for log anomaly detection on edge devices. According to certain embodiments, embedded models may be able to transform unstructured log data into meaningful multi-dimensional vectors (embeddings) that capture semantic meanings within the logs, making it easier to detect deviations that indicate potential anomalies. One of the strengths of embedding models is their efficiency in real-time applications. Given the constrained computational resources, especially on edge devices with limited GPU capacity, embedding models offer a computationally lightweight solution that processes data with reduced overhead. This may enable real-time anomaly detection, which is crucial in industrial environments where immediate detection and response are required to maintain system reliability and prevent failures. Moreover, with transformer-based architectures, it maintains historical data with memory capability to enhance their understanding of contextual information within logs.

[0077] By directly utilizing embedding models at the edge or wellsite, systems may detect anomalies without the latency typically associated with cloud-based detection, allowing for faster responses and reducing operational risks. This approach is particularly valuable in resource- constrained environments, where bandwidth limitations make transferring large volumes of log data impractical. Instead of sending all logs to a central system, the anomaly detection process at the edge or wellsite filters out normal activity, allowing only abnormal logs to be transmitted for further analysis by the SRE team. This strategy may not only conserve network bandwidth but may also ensure that critical issues are prioritized and addressed promptly.

[0078] According to certain embodiments, the current system may be used for anomaly detection. As shown in Figure 4, a producer-consumer method 400 may be employed to decouple log input and processing tasks, enhancing both scalability and efficiency. According to certain embodiments, a detection service may acquire logs in real time at step 404 from various sources, including application logs, system logs, firewall logs, or an edge log server 402. The method 400 may continuously processes these logs, leveraging an embedding model to compare real-time log entries against a baseline of normal log embeddings stored in a vector database. If the calculated distance between a real-time log and its corresponding normal log exceeds a predefined threshold, the log is flagged as an anomaly.

[0079] In certain embodiments, the logs may be stored in a queue store 406. Log entries may then be populated from the queue store 406 as at 408 so that they may be converted intoPATENT Attorney Docket No.: IS24.1672-WO embeddings using a transformer as at 410. The method 400 may minimize the need for extensive data preprocessing or log parsing, allowing for efficient and robust detection. By filtering out normal logs locally and only sending identified anomalies to a remote health monitoring platform, the solution may reduce bandwidth consumption and ensures that notable events receive timely attention. The combination of embedding models and vector databases provides a powerful, scalable framework for real-time anomaly detection at the edge or wellsite.

[0080] According to certain embodiments, creating vector embeddings from logs as at 410 may include several steps including transforming the unstructured or semi -structured text in logs into meaningful vectors that may be stored and queried efficiently in a vector database 412. In certain embodiments, the process to create vector embeddings from logs as at 410 includes preprocessing the logs, choosing or training a text embedding model, storing embeddings in a vector database, and querying and using the embeddings.

[0081] Because software logs are often messy, containing timestamps, error codes, messages, stack traces, etc., preprocessing is helpful when removing unnecessary noise and focusing on useful information. Preprocessing may also include removing timestamps, special characters, and other irrelevant metadata. Logs typically contain timestamps, host details, etc., which may not be useful for embeddings. In certain embodiments, preprocessing includes tokenization or the splitting the logs into tokens such as words or phrases, and word removal so as to remove common words like "the", "is", etc., if they do not add meaning to the log content. In certain embodiments, preprocessing may also include lowercasing which is the conversion of all text within the logs to lowercase for uniformity.

[0082] According to certain embodiments, choosing or training a text embedding model includes choosing or training an embedding model that may convert the processed log data into vector embeddings as needed. In certain embodiments, the model encodes the log entries into vector embedding representations using a pre-trained embedding

[0083] Table 1 below shows the comparison between the models in the state of the art. Based on the performances of the models based on average performance, speed, and model size, it was found that using all-MiniLM-L6-v2 is suitable, according to an embodiment. Figure 5 further shows an example of embedding a log into 384-dimension vector according to an embodiment.Table 1PATENT Attorney Docket No.: IS24.1672-WO

[0084] Once embeddings are generated, a vector database 412 is required to store them for fast retrieval and similarity search.

[0085] Once the embeddings are in a vector database 412, a similarity search may be performed as at 414 using vector-based computation to find logs that are semantically similar to a given log, detect anomalous patterns by comparing log embeddings to expected behaviors, and categorize logs based on embedding proximity.

[0086] According to certain embodiments, the similarity search as at 414 may be used to detect log anomalies. In one embodiment, the queue store 406 may be a vector database which contains normal log entries. The input log is vectorized using an embedded model as at 410, which transforms it into 384-dimension embeddings that capture semantic relationships between log data.PATENT Attorney Docket No.: IS24.1672-WOAccording to certain embodiments, the embedded model may be any appropriate model including the models listed in Table 1. These vector representations are then compared with stored normal log vectors using similarity search techniques as at 414. If a queried log entry deviates from the stored normal entries, or is above a predefined threshold, it is detected as anomalous as at 416. To compare these embeddings, certain similarity metrics are used, depending on the nature of the data and the specific problem being solved. Figure 6 shows several examples of different similarity metrics. If the queried log entry is below the predetermined threshold, it may be added to an anomalous list and published to a LLM agent as at 418.

[0087] According to certain embodiments, the Euclidean distance similarity metric is preferably used. The similarity score may be computed through Euclidean distance between the incoming log embeddings against normal log embeddings stored in the vector database. When the similarity score matches the criteria such as highest similarity score or minimal threshold score, an anomalous log is detected. Figure 7 shows the t-distributed Stochastic Neighbor Embedding (t- SNE) plots of the normal and abnormal logs. The similarity score demonstrates the differences between normal logs and anomalies, according to an embodiment.

[0088] According to certain embodiments, a fleet management system among other monitoring tools may be used to monitor a system’s metrics such as CPU usage, memory usage, disk space, and network traffic in real-time. By visualizing these metrics in dashboards presented within a graphical interface, for example as seen in Figure 8, performance bottlenecks, resource constraints, and anomalies may be detected. In certain embodiments, the fleet management system may also enhance security by analyzing logs from firewalls, intrusion detection systems (IDS), and other security tools, and correlating real-time logs or alerts to identify potential security incidents, such as unauthorized access attempts, malware, and suspicious network activity.

[0089] According to certain embodiments, LLM GenAI agents may be used to generate actions to be sent through communication infrastructure to the edge devices. An example architecture 900 of the autonomous anomaly detection and resolution solution may be seen in Figure 9, according to an embodiment.

[0090] Procedures may serve as systematic, step-by-step instructions aimed at resolving specific errors in an efficient and structured manner. The creation of such procedures typically starts with the development of a flowchart, where each block may represent conditions, execution steps or results, providing a clear roadmap for decision-making and action sequences. Figure 10 shows anPATENT Attorney Docket No.: IS24.1672-WO example of a procedure flowchart 1000 generated to solve a firewall issue, according to an embodiment. Following the flowchart design 100, a detailed document may be crafted that outlines the objectives, such as the error types and step-by-step instructions. These steps may specify the condition statement and corresponding actions, which may be defined as function calls. Figure 11 shows an example of a procedure document 1100, according to an embodiment.

[0091] According to certain embodiments, the LLM agent may intelligently analyze the procedure’s condition, identify the necessary logic, and execute the correct steps. Instead of manually coding extensive logic for each scenario, the LLM may autonomously determine the appropriate logic pathways, reducing the need for complex, hardcoded solutions and software development time.

[0092] To enhance accessibility and streamline the retrieval of relevant procedures, a vector database in certain embodiments may be utilized to store these procedure documents, enabling fast and efficient retrieval. By leveraging similarity search algorithms, the system may identify and recommend the most relevant procedure by comparing the characteristics of the queried error with stored procedures. This not only improves the precision and speed of error resolution but also reduces system downtime and minimizes development complexity, as the LLM may efficiently deduce logic and execute the necessary steps without the need for extensive, manual intervention.

[0093] According to certain embodiments, LLMs are one type of Al model that may leverage deep learning techniques and transformer architectures to understand and generate human-like text. These models are trained on vast datasets, enabling them to grasp context, semantics, and intricate language patterns, which facilitates a wide range of applications, from text generation to conversational agents. According to certain embodiments, the LLM architecture may be as seen in Figure 12 where a LLM-powered agent may generate actions based on the insights. In certain embodiments, there may be several LLM-powered agents, each specialized in a specific field. For example, a LLM-powered agent may be included to detect operational issues (high latency, high load .. . etc.) and execute actions such as service restart and another LLM-powered agent to detect security threats and execute actions such blocking access and change the firewall configurations.

[0094] In certain embodiments, an LLM-powered agent may extend its capabilities by autonomously interacting with users and systems to perform complex tasks. This includes not only generating responses based on user inputs but also analyzing data, drawing inferences, and making decisions based on contextual understanding. The versatility of LLM agents may enable them toPATENT Attorney Docket No.: IS24.1672-WO enhance productivity and efficiency through automation and intelligent problem-solving. Figure 13 illustrates an overview of an example of a LLM powered agent 1300, according to an embodiment.

[0095] According to certain embodiments, in an LLM-powered autonomous agent system, the LLM-powered agent functions as the “brain”, complemented by several key components including self-organizing, memory, and tool use.

[0096] In certain embodiments, larger tasks may be systematically broken down into smaller, manageable subgoals (subgoal decomposition enabling more efficient execution by following user-defined procedures) with each step designed to address specific issues under predetermined conditions. A LLM agent possesses the capability to autonomously analyze task logic and make informed decisions for executing the appropriate steps. This approach may facilitate the efficient handling of intricate tasks, allowing agents to execute complex operations with greater precision. Furthermore, agents may engage in self-criticism and self-reflection regarding their past actions, enabling them to learn from mistakes and refine their strategies for subsequent steps. This reflection and refinement process may enhances the quality of results produced by the agent.

[0097] According to certain embodiments, an LLM-powered agent may employ in-context learning to utilize short-term memory, allowing for immediate adjustments based on recent experiences. In addition, the integration of long-term memory capabilities equips the agent with the ability to retain and recall vast amounts of information over extended periods. This is often achieved using external vector stores, facilitating rapid information retrieval and enhancing the agent's knowledge base.

[0098] According to certain embodiments, the LLM-powered agent may interact with external Application Programming Interfaces (APIs) to perform actions defined by the user. This functionality encompasses a wide range of tasks, including but not limited to retrieving current information, executing code, and performing external operations.

[0099] According to certain embodiments, an LLM-powered autonomous agent system 1400 may be included that incorporates a supervisor and specialized agents to optimize task execution. Figure 14 shows the architecture of the LLM-powered agent system, according to an embodiment. The system 1400 may include a supervisor 1402 which may be a type of LLM-powered agent that plays a critical role by analyzing incoming procedures and determining the most appropriate specialized agent to handle the tasks. Once the routing decision is made by the supervisor 1402, aPATENT Attorney Docket No.: IS24.1672-WO designated specialized agent 1404a, 1404b, 1404c receives the procedure, executes the corresponding actions in accordance with predefined steps, and generates the output. This result may then sent back to the supervisor, who compiles the response and delivers it to the end user.

[0100] Specifically, in certain embodiments, upon receiving an abnormal log 1406 from the log anomaly detection service, an LLM may be employed to extract key information as at 1408, such as exceptions, from the log in order to diagnose the issue. The appropriate resolution procedure may then be retrieved from a procedure database 1410 using a similarity search. In certain embodiments of the current LLM-based agent system 1400, a LangGraph may be utilized to manage the coordination, task assignment, and overall workflow among LLM agents 1402, 1404. More specifically, each LLM agent, such as the supervisor 1402, may be represented as a node within the graph structure, where task assignments are regulated by conditional edges linking the supervisor 1402 to the agents 1404. The supervisor 1402 may assign the retrieved procedure to the designated specialist agent 1404. Each agent 1404 may be equipped with a set of tools 1412 specific to the issue. For instance, in the case of a firewall issue, the agent 1404 may perform actions such as retrieving firewall configuration or checking connectivity status, which are implemented as Python functions. The agent 1404 may execute the procedure step by step to resolve the issue. Upon completion, the results may be reported back to the SRE team through the supervisor 1402, facilitating full automation of the issue resolution process, according to an embodiment. This hierarchical structure, combining a supervisory decision-making layer with specialized execution capabilities, ensures efficient task allocation and precise execution, thereby enhancing overall system performance and reliability.

[0101] Like any connected industrial system, automation brings many advantages and improvements in terms of efficiency and performances, however many industrial systems need to be operational all the time and risks of cyber-attacks increase. For example, many digital drilling systems require real-time operations with minimal latency. Implementing cybersecurity measures that introduce delays may be unacceptable, thus limiting the range of possible security solutions. Additionally, ensuring availability and reliability is paramount, sometimes leading to trade-offs where security measures are deprioritized. Increased remote access capabilities for maintenance and monitoring introduce new vectors for cyber-attacks. Secure remote access solutions are not always implemented, leading to potential vulnerabilities. Industrial environments (for instance drilling systems) often lack the advanced monitoring and detection capabilities found in modemPATENT Attorney Docket No.: IS24.1672-WOIT systems. Incident response may be slower due to the critical nature of industrial processes and the potential safety implications of shutting down operations. Furthermore, physical access to drilling systems may compromise cybersecurity. Protecting the physical infrastructure from tampering is crucial but may be challenging in dispersed or remote locations.

[0102] According to certain embodiments, the current disclosure may reduce the unnecessary presence of personnel, thereby reducing HSE risk exposure and optimizing operational costs. The current disclosure enables reduced staffing levels on mechanized rigs and delivers unparalleled consistency of repetitive tasks, helping users reach their technical limit on every well.

[0103] With the rise of edge computing services rising in the oil and gas industry, the demand for an effective monitoring and alerting system became critical. An enhancement in service delivery may be provided which enables SRE teams to monitor an edge fleet and be alerted in realtime. In certain embodiments, a reduction in the incidence of NPT may be provided. In certain embodiments, deploying, configuring, managing fleet monitoring agents, logging, and storing device telemetry may be eased. In certain embodiments, fast troubleshooting supported by intuitive visualizations may be provided. On top of this foundation, Al-powered enhancements may be introduced that take observable solution capabilities to the next level. For example, by analyzing firewall logs, the current system may autonomously detect abnormal network activities suggesting an intrusion attempt and automatically block the hacker's connection. Similarly, according to certain embodiments, an unexpected increase in the volume of data written to the system due to internal logs may trigger an anomaly alert, prompting proactive data management actions such as archiving or deleting old logs. These Al-driven innovations aim to further minimize future NPT by ensuring that operational anomalies are not just detected but resolved autonomously. In the following section, some use cases of the proposed solution are highlighted.

[0104] According to certain embodiments, a use in operational issue detection and resolution may be provided. For example, when an edge device or wellsite equipment is experiencing high latency and load and affecting drilling operations, an agent 1404, which may be a GenAI agent, specialized in operational issues may analyzes the performance metrics and identify the high latency and load. In certain embodiments, the GenAI agent 1404 may send a generated command or insight via a communication hub to the edge device or wellsite equipment to restart specific services with the aim of reducing the load and latency. According to certain embodiments, a means to adjust resource allocations or prioritize certain tasks to balance the load may be provided. InPATENT Attorney Docket No.: IS24.1672-WO certain embodiments, the system performance may be restored without manual intervention, ensuring minimal disruption to drilling operations at the wellsite.

[0105] According to certain embodiments, a means for security threat detection and mitigation may be provided. For example, when suspicious network activity is detected or when a potential security breach is suggested, an agent 1404, which may be a GenAI agent, that is specialized in security, analyzes firewall logs and IDS alerts to confirm suspicious activities. According to certain embodiments, the GenAI agent 1404 may send commands to block the malicious IP address and tighten firewall rules in order to prevent unauthorized access. The GenAI agent 1404 may also initiate a thorough network scan to identify any additional vulnerabilities or threats. In certain embodiments, the security threat is neutralized swiftly thereby protecting the integrity of the drilling operations and preventing data breaches.

[0106] According to certain embodiments, a means to address network connectivity issues may be provided. For example, when a rig-to-town connection is unstable which then causes data transmission delays and potential operational inefficiencies, an agent 1404, which may be a GenAI agent, may identify repeated connection errors and latency spikes from the logs. In certain embodiments, the GenAI agent 1404 may also test network and SSL connections to diagnose the root cause of the instability as seen in Figure 15. In certain embodiments, the GenAI agent 1404 may adjust network settings or open necessary firewall rules to stabilize the connection as seen in Figure 16. In certain embodiments, the network connectivity is restored, thereby ensuring continuous and reliable data transmission between the rig and the town operations center.

[0107] According to certain embodiments, a means for performing database cleanup may be provided. For example, when a database on an edge device is filling up rapidly, thereby risking data overflow and operational disruptions, an agent 1404, which may be a GenAI agent, may monitor the database size and identify a rapid increase in data volume. In certain embodiments, the GenAI agent 1404 may send a command via the loT or communications hub to the edge device or wellsite equipment to perform a cleanup operation. In certain embodiments, the GenAI agent 1404 may identify and archive old logs or unnecessary data to free up space in the database, and may also adjust data retention policies to prevent future overflows. In certain embodiments, the database space may be reclaimed, thereby preventing potential data loss or operational disruptions due to a full database.PATENT Attorney Docket No.: IS24.1672-WO

[0108] In summary, an Al-driven observability and security suite may be provided with a GenAI agent system 1400 for autonomous anomaly detection and resolution. The integration of a GenAI SRE agent 1404 directly at the edge or wellsite marks an innovation in proactive and intelligent monitoring solutions. According to certain embodiments, the GenAI agent 1404 may continuously analyzes system metrics — including CPU usage, memory utilization, disk space, and network traffic in real-time, enabling it to detect performance bottlenecks, resource constraints, and security threats by examining logs from firewalls, intrusion detection systems (IDS), and other security tools. Upon identifying anomalies, the GenAI agent 1404 may autonomously initiates corrective actions, such as blocking unauthorized access attempts and managing resource allocation, thereby ensuring continuous system integrity and security. As optimizing drilling operations to guarantee peak rig performance and productivity, the global expansion of edge or wellsite deployments has underscored the critical need for an intelligent monitoring and alerting system. According to certain embodiments, the GenAI SRE agent 1404 may effectively resolve complex issues, including firewall breaches, through autonomous analysis and mitigation of malicious network activities. Furthermore, the GenAI agent 1404 may proactively manage data anomalies, ensuring that operational disruptions were not only detected but also resolved without human intervention.Enabling Multi-Application Execution with AI-Driven Workflows for Drilling Operations

[0109] According to certain embodiments, in drilling edge operations, a data aggregation service may be provided that collects data from multiple sources, both internal and external. The system may aggregate data from internal software like DrillOps® and Maxwell®, which manage MWD (Measurement While Drilling) and LWD (Logging While Drilling) acquisition, as well as from client systems that provide data through industry-standard protocols such as WITSML (Wellsite Information Transfer Standard Markup Language), WITS, OPC (Open Platform Communications), and Modbus.

[0110] Once the data is aggregated, proprietary workflows may be run on separate devices, distinct from the aggregation system. This separation allows for the preservation of the original format of the aggregated data while processing it through other workflows, such as a Directional Drilling (DD) advisor workflow. The challenge arises from the need to maintain data integrity across multiple devices and workflows, without modifying the data during the aggregation process.PATENT Attorney Docket No.: IS24.1672-WO

[0111] Historically, to accommodate these workflows, dedicated devices for each type of workflow have been used to ensure that the aggregated data could be processed in the correct format required by each specific operation. This setup resulted in an overly complex network and hardware configuration, with each workflow requiring its own resources to ensure compatibility and data integrity.

[0112] Figure 17 illustrates this specific challenge by showing how data from various sources, such as wellbore information 1702, sections 1704, and bottom hole assembly (BHA) runs 1706, is aggregated and then processed on separate devices without altering the data. Managing these multiple workflows across different devices while ensuring the consistency and integrity of the aggregated data adds complexity to the system's overall design.

[0113] A challenge often encountered when aggregating data from multiple sources is hardware and software duplication. For example, to perform both the DD advisor and data aggregation workflows, the system requires multiple processing nodes (depicted as separate boxes in Figure 18). Each of the DD and data aggregation workflows require a distinct system to handle the data, leading to duplication of resources both in terms of hardware and software. This in turn may create inefficiencies in hardware usage and increases the system’s overall complexity, necessitating more network connections, increasing latency, and requiring additional management overhead.

[0114] Another challenge that may be encountered is network complexity. The network setup may be highly intricate, with data flowing between different systems like Maxwell® and DrillOps® through protocols such as WITSML and WITS. This network complexity not only creates challenges in ensuring seamless data flow but also raises the likelihood of network-related issues, especially when connecting the different components to form a unified data system.

[0115] A further challenge that may be encountered is cloud data publication to multiple wells, specifically the publication of data to different wells (for example Well A and Well B). Data from the wellsite and from off-site facilities may be transmitted and aggregated for each well separately. This creates issues in the cloud, where the data associated with different wells may be misaligned or lead to redundancy. This duplication of data leads to inefficiencies in processing, storage, and ultimately in the performance of the remote D&I and remote MWD systems, which are responsible for predictive analytics and monitoring tasks. Also, bandwidth is limited on the edge side, multiplying the data transmission has an impact on performance. As an example, some rig systems only have 500Kb available.PATENT Attorney Docket No.: IS24.1672-WO

[0116] In summary, the lack of centralized or unified handling of data for multiple workflows results in mismatched data formats, hardware duplication, data duplication in town and inefficiencies in both on-premises systems and cloud operations.

[0117] According to certain embodiments, Figure 19 illustrates how the current system 1900 operates through multiple layers, starting with a data aggregation layer 1902 that collects timedepth data and contextual drilling domain data from various sources. These sources may include, for example, third-party WITSML providers 1904, MWD (Measurement While Drilling) systems 1906, cementing data 1908, mud logging data 1910, and loT devices 1912 utilizing protocols like MQTT, OPC, and Modbus. In certain embodiments, the network interface system 1912 within an edge device 1920 handles this data aggregation process, which is extensible, allowing the integration of new data formats as the system evolves.

[0118] Once aggregated, the data may be stored within a shared edge domain service layer 1914 within the edge device 1920. In certain embodiments, the shared edge domain service layer 1914 utilizes a unified schema based on energy industry standards, specifically WITSML 1.4.1 and WITSML 2.0. This standardization ensures a common language for data storage and enables seamless synchronization between edge devices and the cloud. The shared schema supports interoperability across workflows and maintains data integrity during transmission between the edge and cloud systems.

[0119] In the shared edge domain service layer 1914, the aggregated data may be enhanced through extensibility mechanisms, such as using extension name-value pairs in WITSML, or the system may support custom data formats where needed. This flexibility allows for continuous adaptation to various workflows and data types, ensuring that the system 1900 may grow alongside new operational demands. Edge workflows 1922, which may include, for example, a directional drilling workflow 1924, an automation workflow 1926, an aggregation workflow 1928, and / or an orchestration workflow 1930, may consume data from the edge shared domain service layer 1914.

[0120] The data may then be published to the cloud 1916 using Avro ETP (Energistics Transfer Protocol), maintaining compliance with energy industry standards like WITSML over ETP. This enables secure, standardized data transfer to the cloud 1916. Once in the cloud 1916, data is stored in the shared cloud domain layer 1918 which may be identical to the shared edge domain layer 1914, ensuring consistent workflow execution between the edge device 1920 and the cloud 1916. Cloud workflows 1932 which may include, for example, a directional drilling workflow 1934, anPATENT Attorney Docket No.: IS24.1672-WO automate workflow 1936, an aggregation workflow 1938, and / or an orchestration workflow 1940, may consume data from the same shared domain service 1918 in the same format as the edge workflows 1922, providing unified data handling across all layers.

[0121] Different workflows, such as the directional drilling (DD) advisor workflow 1924, 1934, require data in specific units and formats, which often differ from the data used, for example, in the aggregation workflow 1926, 1936. For example, a time channel in the DD workflow 1924, 1934 may need to be in a different format or unit than the one used in the aggregation workflow 1926, 1936. To address these differing requirements without introducing data redundancy or the need for additional storage, a virtual channel, or channel composite may be provided.

[0122] According to certain embodiments, a composite channel may 2002 dynamically created by combining multiple raw channels, for example a first raw channel 2004 and a second raw channel 2006, originating from different sources as seen in Figure 20. These raw channels 2004, 2006 may represent various drilling-related data, such as time, depth, or sensor readings from multiple systems, each stored in its native format. The system allows for real-time processing, where at any given time t, the composite channel references a specific raw channel from an external source. For example, the first raw channel 2004 may may have a first data set 2008 between times to and t2, and a second data set 2010 from time t2 onward, while the second raw channel 2006 may have a third data set 2012 between times to and ti and a fourth data set 2014 from ti onward. The resulting composite channel 2002 may then reference the first data set 2008 from to and t2, the second data set 2010 from t2to ts, and then the fourth data set 2014 from t3 onward, according to an embodiment.

[0123] In certain embodiments, providing a composite channel 2002 avoids duplicating data in storage. Instead, the composite channel 2002 may act as a flexible abstraction that combines data on demand based on the specific requirements of the workflow. For instance, in a method 2100 as seen in Figure 21, data from a well or wellbore 2102 may be given appropriate context 2104 and then represented within a corresponding raw channel 2106. Data may be taken from the raw channel 2106 and then displayed or viewed by a user as at 2108. A composite channel 2110 may be provided which may extract interval data 2112 from the one or more raw channels 2110 and adapt them to the units of the composite channel 2110, ensuring that the relevant contextual information is maintained while satisfying the unique needs of each workflow. In other words, by a providing the composite channel 2110, the relevant data received from the well or wellbore 2102PATENT Attorney Docket No.: IS24.1672-WO may be used to perform the desired workflows without compromising or hindering the ability of the method 2100 to present the same data received from the well or wellbore 2102 to a user, simultaneously.

[0124] Figure 22 illustrates an example of channel data flow 2200, according to an embodiment. An efficient and consistent transmission of data may be provided between an edge device 2202, such as a rig, and a town device 2204, such as remote operations centers or cloud infrastructure. To maintain data integrity and adhere to energy industry standards while optimizing performance, a combination of protocols 2206 including, for example, WITSML, ETP, and Avro™ may be utilized.

[0125] According to certain embodiments, WITSML (Wellsite Information Transfer Standard Markup Language) may be used for transmitting contextual data including, for example, traj ectory , bottom hole assembly (BHA) details, and tubular information. WITSML is an industry-standard XML-based language specifically designed for the exchange of drilling data. It ensures that contextual information is consistently formatted and easily interpretable by various systems involved in drilling operations.

[0126] According to certain embodiments, for real-time data streaming, ETP (Energistics Transfer Protocol) may be employed which is optimized for transmitting channel data, metadata, channel data changes, and growing objects or data that accumulates over time. ETP facilitates efficient, low-latency communication between the rig and town, allowing for immediate access to critical drilling parameters and time-series data essential for real-time decision-making.

[0127] According to certain embodiments, both WITSML and ETP data may be serialized using, for example, Apache Avro™, a compact and fast binary serialization framework. In certain embodiments, Avro™ offers efficient fata compression wherein Avro's™ binary format reduces the size of data payloads compared to traditional XML or JSON formats, leading to reduced bandwidth usage and faster transmission speeds. Avro™ may also provide schema evolution support which allows for flexible schema evolution without impacting existing systems, enabling the integration of new data types and protocols as the system evolves.

[0128] According to certain embodiments, there are several potential benefits of using WITSML and ETP over Avro™. For example, by adhering to WITSML for contextual data and ETP for real-time data, compatibility with industry-standard formats may be ensured, thereby facilitating integration with other tools and systems used in the energy sector. Additionally, Avro™'s efficientPATENT Attorney Docket No.: IS24.1672-WO serialization improves data transmission speeds and reduces latency, which is crucial for real-time operations where timely data access may impact drilling efficiency and safety. Furthermore, using WITSML and ETP over Avro™ ensures that data remains consistent and unaltered during transmission. This integrity is beneficial for accurate analytics, decision-making, and maintaining a unified data environment across both edge and cloud systems. In certain embodiments, the combination of these technologies allows for scalable system architecture. As new data sources or types emerge, they may be integrated without overhauling the existing infrastructure, thanks to Avro™'s schema evolution capabilities.

[0129] According to certain embodiments, by leveraging WITSML and ETP over Avro™, the method 2200 may efficiently transmit both contextual and real-time drilling data between the rig or edge device 2202 and the town 2204 while maintaining adherence to industry standards. This approach optimizes performance, ensures data integrity, and provides the flexibility needed to adapt to evolving data requirements, ultimately enhancing operational efficiency and decisionmaking in drilling operations.

[0130] In certain embodiments, for an edge device 2202 with very low connectivity, an additional compression capability with different compression level using standards such as gzip and zstandard may be introduced.

[0131] According to certain embodiments, a means for multi -workflow execution for data aggregation and advisory workflows may be provided. For example, at a rig site, multiple workflows such as data aggregation and directional drilling (DD) advisory need to be run concurrently on a single edge device at the wellsite. The challenge is to manage and process diverse data formats from various sources such as WITSML, OPC, and MQTT without compromising data integrity or performance. Additionally, there is a need to aggregate and harmonize this data before feeding it into the advisory systems. In certain embodiments, the drilling operation multiproduct execution system aggregates data from multiple sources using its network interface and the concept of virtual channels, which allow different formats to coexist and be processed without conflict. By leveraging the composite channel model, data is dynamically aggregated and prepared for use in multiple workflows. This enables both data aggregation and real-time DD advisory workflows to run concurrently on the same device without needing additional hardware. This reduces network complexity, eliminates hardware redundancy, and ensures efficient data flowPATENT Attorney Docket No.: IS24.1672-WO between the edge device and the cloud. Operators may now seamlessly monitor and adjust operations while maintaining consistent data integrity across all workflows.

[0132] According to certain embodiments, a means for real-time autonomous advisory and workflow execution may be provided. For example, a drilling contractor may require real-time AI- driven recommendations to optimize directional drilling parameters while also needing the system to autonomously take control of rig equipment to execute predefined procedures. The contractor may be simultaneously performing MWD and surface acquisition tasks, with data being aggregated on the edge device from multiple sources. In certain embodiments, the data aggregation layer within the drilling operation application collects and stores data from the drilling contractor’ s operations in the shared domain service, preserving its original format. From this aggregated data, the advisory feature continuously analyzes real-time MWD data and surface parameters, offering optimized, Al-driven recommendations for key drilling parameters such as torque, RPM, and weight on bit. At the same time, an automation feature autonomously takes control of the rig's equipment, executing essential tasks like downhole tool adjustments and bit pressure control, ensuring compliance with procedural standards and reducing human error. The current system may enable a smooth interaction between real-time data aggregation, advisory, and automation, ensuring safety and performance optimization while keeping data harmonized.

[0133] According to certain embodiments, a means for predictive analytics for risk mitigation and procedural compliance may be provided. For example, a drilling operator may wish to minimize risks such as stuck-pipe incidents, wellbore instability, and equipment failures by utilizing real-time data monitoring. The operator may also want to ensure the system adheres to strict procedural standards while processing and aggregating real-time data from various sources. In certain embodiments, predictive analytics may aggregate data in real time, capturing torque, drag, vibrations, and pressure readings from both internal systems and external data feeds through protocols such as WITSML or MQTT. The system's Al-driven analytics may provide predictive insights by analyzing these aggregated data streams and flagging conditions that indicate impending risks like stuck-pipe incidents. Additionally, automation enforces procedural compliance by automatically adjusting operations based on predictive warnings, ensuring that corrective measures such as altering mud weight or rotational speed are executed safely and in line with operational protocols. This real-time combination of predictive analytics and proceduralPATENT Attorney Docket No.: IS24.1672-WO automation reduces non-productive time (NPT) while ensuring data consistency across multiple workflows.

[0134] According to certain embodiments, a means for cross-domain workflow coordination and data aggregation may be provided. For example, a major energy company may wish to execute multiple workflows that span across different domains, such as cementing, mud logging, and MWD acquisition, on a shared edge infrastructure. The company may wish to have seamless data aggregation and coordination between these workflows without introducing conflicts in data formats or workflow bottlenecks. In certain embodiments, a cross-domain integration layer is provided that aggregates data from various workflows — cementing, mud logging, MWD acquisition — and stores it in a unified schema. The virtual channel system ensures that the data from different domains is harmonized and may be consumed by cross-domain workflows without needing additional hardware or data transformation. As data from these workflows is aggregated in real time, the drilling operation application ensures that it remains compatible with domainspecific requirements and may be easily processed by other systems, both on the edge and in the cloud. This architecture may enable operators to coordinate workflows efficiently, ensuring data consistency and process synchronization across the entire operation, reducing operational complexity and improving real-time decision-making.

[0135] The current disclosure brings several key benefits that may improve the efficiency and effectiveness of drilling operations. By consolidating multiple workflows, such as data aggregation, automation, and advisory, onto a single edge device, the system may reduce the complexity and operational costs typically associated with managing multiple devices. This streamlined approach allows for real-time data aggregation and visualization, providing operators with actionable insights across various workflows without sacrificing performance or data integrity. The integration of Al-driven workflows enables automation, predictive analytics, and directional drilling (DD) advisory, all of which contribute to enhanced operational efficiency by minimizing human error and optimizing procedural adherence. This level of automation ensures that well-execution plans are precisely followed, reducing the risk of costly mistakes and improving overall safety.

[0136] Additionally, the system’s predictive analytics capabilities allow for the early detection of potential issues such as stuck-pipe incidents or wellbore instability. By flagging these risks in real time and recommending corrective actions, the system helps to reduce non-productive timePATENT Attorney Docket No.: IS24.1672-WO(NPT), ensuring continuous, smooth operation. The use of WITSML and ETP over Avro™ protocols further ensures that data transmission between the rig and town remains consistent and efficient, maintaining industry-standard formats while optimizing performance. Ultimately, both short-term operational performance and long-term decision-making capabilities may be enhanced by integrating real-time data and advanced analytics, all within a unified, scalable system architecture.Exemplary Method

[0137] Figure 23 illustrates a flowchart of a method 2300 for simultaneously executing multiple workflows related to a drilling operation. The method 2300 includes aggregating data related to a wellsite at an edge device disposed at the wellsite, as at 2302. In certain embodiments, aggregating data includes receiving data from a plurality of sources. The plurality of sources may include equipment disposed within the wellsite and outside systems that are communicated to the wellsite. The data related to the wellsite may include third party data, measurement while drilling data, mud logging data, cementing data, or loT device data. The data may be aggregated by a network interface system within the edge device. In certain embodiments, aggregating data related to the wellsite at the edge device includes aggregating data received from a plurality of raw channels of data and including at least one data sub-set from each of the plurality of raw channels of data within a composite channel. Each of the plurality of raw channels of data may correspond to a plurality of data sources disposed at the wellsite.

[0138] According to certain embodiments, the method 2300 may include standardizing the aggregated data into a unified schema, as at 2304.

[0139] According to certain embodiments, the method 2300 may include storing the data within a shared domain service layer of an edge device, as at 2306. The data may be stored in a unified schema within the database.

[0140] According to certain embodiments, the method 2300 may include transmitting a composite channel based on the data to a shared domain service layer of a cloud database, as at 2308.

[0141] According to certain embodiments, the method 2300 may include performing a first workflow based on the stored data in the shared domain service later of the edge device, as at 2310.PATENT Attorney Docket No.: IS24.1672-WOThe first workflow may include a directional drilling advisory workflow, an automation workflow, a data aggregation workflow, or an orchestration workflow.

[0142] According to certain embodiments, the method 2300 may include performing a second workflow based on the composite channel in the shared domain service layer of the cloud device simultaneously as the first workflow is performed in the edge device, as at 2312. The second workflow may be different than the first workflow performed at the edge device, however in certain embodiments, the second workflow may be similar or identical to the first workflow. The second workflow may include a directional drilling advisory workflow, an automation workflow, a data aggregation workflow, or an orchestration workflow. In certain embodiments performing the first or second workflows may include generating a recommendation based on the data, autonomously sending a command based on the data to the equipment disposed at the wellsite by the edge device, or generating a predictive insight based on the data and displaying the predictive insight to the user through the graphical interface on the edge device. In certain embodiments, generating the predictive insight may further include flagging an impending risk related to the predictive insight and automatically adjusting equipment disposed at the wellsite in response to the predictive insight by the edge device.

[0143] According to certain embodiments, the method 2300 may include displaying a result of the first workflow and a result of the second workflow on a graphical interface on the edge device, as at 2314.

[0144] According to certain embodiments, the method 2300 may include performing a wellsite action based on the first workflow and the second workflow, as at 2316. Performing the wellsite action includes generating or transmitting a signal that instructs or causes an action to occur. The action may include a physical action. The physical action may include selecting where to drill a wellbore in the subsurface formation, drilling the wellbore, varying a trajectory of the wellbore, varying a weight or torque on a drill bit that is drilling the wellbore, varying a rate or concentration of a fluid being pumped into the wellbore, or a combination thereof.Exemplary Computing System

[0145] In some embodiments, the methods of the present disclosure may be executed by a computing system. Figure 24 illustrates an example of such a computing system 2400, in accordance with some embodiments. The computing system 2400 may include a computer orPATENT Attorney Docket No.: IS24.1672-WO computer system 2401 A, which may be an individual computer system 2401 A or an arrangement of distributed computer systems. The computer system 2401A includes one or more analysis modules 2402 that are configured to perform various tasks according to some embodiments, such as one or more methods disclosed herein. To perform these various tasks, the analysis module 2402 executes independently, or in coordination with, one or more processors 2404, which is (or are) connected to one or more storage media 2406. The processor(s) 2404 is (or are) also connected to a network interface 2407 to allow the computer system 2401 A to communicate over a data network 2409 with one or more additional computer systems and / or computing systems, such as 2401B, 2401C, and / or 2401D (note that computer systems 2401B, 2401C and / or 2401D may or may not share the same architecture as computer system 2401 A, and may be located in different physical locations, e.g., computer systems 2401A and 2401B may be located in a processing facility, while in communication with one or more computer systems such as 2401C and / or 2401D that are located in one or more data centers, and / or located in varying countries on different continents).

[0146] A processor may include a microprocessor, microcontroller, processor module or subsystem, programmable integrated circuit, programmable gate array, or another control or computing device.

[0147] The storage media 2406 may be implemented as one or more computer-readable or machine-readable storage media. Note that while in the example embodiment of Figure 24 storage media 2406 is depicted as within computer system 2401 A, in some embodiments, storage media 2406 may be distributed within and / or across multiple internal and / or external enclosures of computing system 2401 A and / or additional computing systems. Storage media 2406 may include one or more different forms of memory including semiconductor memory devices such as dynamic or static random access memories (DRAMs or SRAMs), erasable and programmable read-only memories (EPROMs), electrically erasable and programmable read-only memories (EEPROMs) and flash memories, magnetic disks such as fixed, floppy and removable disks, other magnetic media including tape, optical media such as compact disks (CDs) or digital video disks (DVDs), BLURAY® disks, or other types of optical storage, or other types of storage devices. Note that the instructions discussed above may be provided on one computer-readable or machine-readable storage medium, or may be provided on multiple computer-readable or machine-readable storage media distributed in a large system having possibly plural nodes. Such computer-readable orPATENT Attorney Docket No.: IS24.1672-WO machine-readable storage medium or media is (are) considered to be part of an article (or article of manufacture). An article or article of manufacture may refer to any manufactured single component or multiple components. The storage medium or media may be located either in the machine running the machine-readable instructions, or located at a remote site from which machine-readable instructions may be downloaded over a network for execution.

[0148] It should be appreciated that computing system 2400 is merely one example of a computing system, and that computing system 2400 may have more or fewer components than shown, may combine additional components not depicted in the example embodiment of Figure 24, and / or computing system 2400 may have a different configuration or arrangement of the components depicted in Figure 24. The various components shown in Figure 24 may be implemented in hardware, software, or a combination of both hardware and software, including one or more signal processing and / or application specific integrated circuits.

[0149] Further, the steps in the processing methods described herein may be implemented by running one or more functional modules in information processing apparatus such as general purpose processors or application specific chips, such as ASICs, FPGAs, PLDs, or other appropriate devices. These modules, combinations of these modules, and / or their combination with general hardware are included within the scope of the present disclosure.

[0150] Computational interpretations, models, and / or other interpretation aids may be refined in an iterative fashion; this concept is applicable to the methods discussed herein. This may include use of feedback loops executed on an algorithmic basis, such as at a computing device (e.g., computing system 2400, Figure 24), and / or through manual control by a user who may make determinations regarding whether a given step, action, template, model, or set of curves has become sufficiently accurate for the evaluation of the risk index.

[0151] The foregoing description, for purpose of explanation, has been described with reference to specific embodiments. However, the illustrative discussions above are not intended to be exhaustive or limiting to the precise forms disclosed. Many modifications and variations are possible in view of the above teachings. Moreover, the order in which the elements of the methods described herein are illustrated and described may be re-arranged, and / or two or more elements may occur simultaneously. The embodiments were chosen and described in order to best explain the principles of the disclosure and its practical applications, to thereby enable others skilled in thePATENT Attorney Docket No.: IS24.1672-WO art to best utilize the disclosed embodiments and various embodiments with various modifications as are suited to the particular use contemplated.

Claims

PATENT Attorney Docket No.: IS24.1672-WOCLAIMSWhat is claimed is:

1. A method for simultaneously executing multiple workflows related to a drilling operation, the method comprising: aggregating data related to a wellsite at an edge device disposed at the wellsite; storing the data within a shared domain service layer of the edge device; transmitting a composite channel based on the data to a shared domain service layer of a cloud device; performing a first workflow based on the data in the shared domain service layer of the edge device; performing a second workflow based on the composite channel in the shared domain service layer of the cloud device simultaneously as the first workflow is performed in the edge device; and performing a wellsite action based on the first workflow and the second workflow.

2. The method of claim 1, further comprising standardizing the aggregated data into a unified schema.

3. The method of claim 2, wherein storing the data within the shared domain service layer of the edge device comprises storing the unified schema on the shared domain service layer of the edge device.

4. The method of claim 1, wherein aggregating data related to the wellsite at the edge device comprises aggregating data received from a plurality of raw channels of data and including at least one data sub-set from each of the plurality of raw channels of data within the composite channel.

5. The method of claim 4, wherein each of the plurality of raw channels of data correspond to a plurality of data sources disposed at the wellsite.PATENT Attorney Docket No.: IS24.1672-WO6. The method of claim 5, wherein the plurality of data sources comprises equipment disposed within the wellsite and outside systems communicated to the wellsite.

7. The method of claim 1, wherein aggregating data related to the wellsite comprises aggregating third party data, measurement while drilling data, mud logging data, cementing data, or internet of things (loT) device data.

8. The method of claim 1, wherein aggregating data related to the wellsite comprises aggregating the data by a network interface system within the edge device.

9. The method of claim 1, wherein either the first workflow or the second workflow comprises a directional drilling advisory workflow, an automation workflow, a data aggregation workflow, or an orchestration workflow.

10. The method of claim 1, further comprising displaying a result of the first workflow and a result of the second workflow on a graphical interface on the edge device.

11. A computing system, comprising: one or more processors; and a memory system comprising one or more non-transitory computer-readable media storing instructions that, when executed by at least one of the one or more processors, cause the computing system to perform operations, the operations comprising: aggregating data related to a wellsite at an edge device disposed at the wellsite; storing the data within a shared domain service layer of the edge device; transmitting a composite channel based on the data to a shared domain service layer of a cloud device; performing a first workflow based on the stored data in the shared domain service later of the edge device; performing a second workflow based on the composite channel in the shared domain service layer of the cloud device simultaneously as the first workflow is performed in the edge device; andPATENT Attorney Docket No.: IS24.1672-WO performing a wellsite action based on the first workflow and the second workflow.

12. The computing system of claim 11, wherein performing the first or second workflows comprises generating a recommendation based on the data, wherein the recommendation is displayed to a user through a graphical interface on the edge device.

13. The computing system of claim 11, wherein performing the first or second workflows comprises autonomously sending a command based on the data to equipment disposed at the wellsite by the edge device.

14. The computing system of claim 11, wherein performing the first or second workflows comprises generating a predictive insight based on the data and displaying the predictive insight to a user through a graphical interface on the edge device.

15. The computing system of claim 14, wherein performing the first or second workflows further comprises flagging an impending risk related to the predictive insight.

16. The computing system of claim 13, wherein performing the first or second workflows further comprises automatically adjusting equipment disposed at the wellsite in response to the predictive insight by the edge device.

17. The computing system of claim 11, further comprising: an edge device disposed at a wellsite connected to the one or more processors; and a plurality of raw data channels connected to the edge device.

18. The computing system of claim 17, wherein each of the plurality of raw data channels corresponds to at least one operation performed by equipment disposed at the wellsite.

19. The computing system of claim 11, wherein performing the wellsite action based on the first workflow and the second workflow comprises generating or transmitting a signal that instructs or causes an action to occur, wherein the action comprises a physical action, and wherein thePATENT Attorney Docket No.: IS24.1672-WO physical action comprises selecting where to drill a wellbore in a subsurface formation, drilling the wellbore, varying a trajectory of the wellbore, varying a weight or torque on a drill bit that is drilling the wellbore, varying a rate or concentration of a fluid being pumped into the wellbore, or a combination thereof.

20. A non-transitory computer-readable medium storing instructions that, when executed by one or more processors of a computing system, cause the computing system to perform operations, the operations comprising: aggregating data related to a wellsite at an edge device disposed at the wellsite; storing the data within a shared domain service layer of the edge device; transmitting a composite channel based on the data to a shared domain service layer of a cloud device; performing a first workflow based on the stored data in the shared domain service later of the edge device; performing a second workflow based on the composite channel in the shared domain service layer of the cloud device simultaneously as the first workflow is performed in the edge device; and performing a wellsite action based on the first workflow and the second workflow.

Images