CN112262352B

CN112262352B - Multi-domain planning and execution

Info

Publication number: CN112262352B
Application number: CN201980038574.9A
Authority: CN
Inventors: M·福克斯; D·隆; R·伊桑古洛夫
Original assignee: Schlumberger Technology Corp
Current assignee: Schlumberger Technology Corp
Priority date: 2018-05-12
Filing date: 2019-05-10
Publication date: 2024-04-05
Anticipated expiration: 2039-05-10
Also published as: NO347899B1; GB2587956A; NO20201174A1; GB2587956B; CN112262352A; CA3100068A1; GB202017703D0; WO2019222033A1

Abstract

A computing device communicatively coupled to an apparatus includes a component having a planner component that generates a plan to be performed using the apparatus, and the component instructs the apparatus to perform the plan. The plan includes actions to be scheduled to be performed by the equipment. Each action can include a first ordered item of a respective action to be performed by the apparatus, wherein the first ordered item includes a start indication indicating that the respective action is starting, and a second ordered item of a respective action to be performed by the apparatus, wherein the second ordered item includes an end indication indicating that the respective action is ending.

Description

Multi-domain planning and execution

Cross Reference to Related Applications

The present application claims priority and benefit from U.S. patent application Ser. Nos. 62/670,737 and 62/670,803, filed on 5, month 12, and 13, and U.S. patent application Ser. No. 16/208,633, filed on 12, month 4, and 16/208,625, filed on 12, and 4, and filed on 12, 2018, the entire contents of which are incorporated herein by reference.

Background

This section is intended to introduce the reader to various aspects of art that may be related to various aspects of the present disclosure that are described and/or claimed below. This discussion is believed to be helpful in providing the reader with background information to facilitate a better understanding of the various aspects of the present disclosure. It should therefore be understood that these statements are to be read in this light, and not as admissions of prior art.

This disclosure relates generally to automated planning, examples of which are described in U.S. patent application publication No. 2018/0012310, the entire contents of which are incorporated herein by reference for all purposes. More particularly, the present disclosure relates to a scalable infrastructure for supporting multi-domain and multi-layer planning-based control of autonomous systems.

Automated planning may be used entirely on a single level in a single domain. For example, using an overall method for drilling a wellbore, the single domain model will cover both drilling and mud management activities (and/or other activities, such as casing and cementing). Such a model would become very impractical and difficult to maintain. Alternatively, automatic planning may use a non-integral approach in which a domain is broken down into multiple subcomponents. For example, drilling a wellbore using a non-integral method may automatically generate a drilling plan detailing various drilling actions to be performed. Similarly, when mud or drilling fluid is applied to the wellbore, a mud plan detailing the various mud application actions may be automatically generated. However, because the drilling plan and mud plan are not developed or coordinated together, the separately generated plans may be inefficient because the actions of each other are not taken into account. Moreover, the lack of coordination between the two plans may result in inflexibility of the plan and failure to react to changes in the other plan. Thus, there is a need for a flexible, efficient, robust, and manageable system for planning and coordinating activities (including real-time responses to changing actions) among multiple domains and/or sub-domains.

Disclosure of Invention

The following sets forth an overview of certain embodiments disclosed herein. It should be understood that these aspects are presented merely to provide the reader with a brief summary of these certain embodiments and that these aspects are not intended to limit the scope of this disclosure. Indeed, the disclosure may encompass a variety of aspects that may not be set forth below.

Embodiments of the present disclosure relate to automated planning and use of scalable infrastructure to support multi-domain and multi-layer planning-based control of autonomous and/or robotic systems. The automatic planning system may generate a concurrent sequence of actions, referred to as planning, to achieve a desired future state of the autonomous system. The plan may be automatically generated given an initial state, a goal, and a set of constraints associated with the task. In addition, the automatic planning system may perform a re-planning operation when an unexpected change occurs (e.g., relative to an expected state). Unlike script behavior, the ability to dynamically generate plans supports the robust execution of tasks to complete projects in the face of changes that were not anticipated in advance.

Embodiments of the present disclosure provide an efficient, logically structured modular design or architecture that enables communication through defined interfaces to coordinate operations between or among different automated planning systems and/or domains. The architecture includes components that can perform certain tasks (e.g., interrogation reasoning, planning scheduling, execution and monitoring, and interpretation of states via an inference system). The architecture also provides a unified design of components that can be replicated in a modular and scalable manner to reflect the breakdown of knowledge in any complex behavioral system. For example, the relationship between the first level and the second level (or parent-child level or director-subordinate level, etc.) may occur multiple times within the hierarchy, i.e., the hierarchy may repeat and propagate. For example, a second level itself relative to a first level may serve as the first level of another second level. That is, a first level and a second level may also be considered higher ordered levels in relation to a larger portion of the hierarchy or whole when the first level and the second level are considered locally with respect to each other. In other words, the architecture may include hierarchical (multi-domain and/or multi-level) modular components that include the same or similar structures, enabling any scale item to be robustly addressed.

In particular examples, a plan-based execution and control system or planning system may include a planner component that generates a plan (e.g., a sequence of tasks) and schedules the plan to an execution engine that implements the plan via a machine and/or one or more control systems, etc. The planner component can be highly flexible and can act on multiple levels or domains, enabling the planner component to formulate a broad strategy plan for an entire project or job, as well as a single tactical sub-plan that contributes to the project. The planning system may be responsive to a variety of operations, and in particular to situations where a variable amount of time may be required to complete a particular task. The planning system may also periodically and/or continuously check whether execution of the plan and/or sub-plan is in progress by comparing the expected state with the actual state based on one or more measurements received via an inference system, sensors, etc. The planning system may also initiate a plan and/or a re-plan of a sub-plan when the amount of deviation between the perceived and/or expected states of the plan or sub-plan exceeds a certain threshold. In some embodiments, the planning system may gradually relinquish more control to the user based on the amount of deviation or the expected state exceeding a threshold and re-participate in the planning and execution process when prompted by the user. Additional details regarding the operation of the planning system will be provided below with reference to fig. 1-25.

The above features may be variously refined for various aspects of the present disclosure. Additional features may also be incorporated into these various aspects as well. These refinements and additional features may occur individually or in any combination. For example, various features discussed below with respect to one or more of the illustrated embodiments can be incorporated into any of the above-described aspects of the present disclosure, alone or in any combination. The brief summary presented above is intended only to familiarize the reader with certain aspects and contexts of embodiments of the present disclosure without limitation to the claimed subject matter.

Drawings

The various features, aspects, and advantages of the present disclosure will become better understood when the following detailed description is read with reference to the accompanying drawings in which like characters represent like parts throughout the drawings, wherein:

FIG. 1 is a block diagram of a planning-based execution and control system or planning system according to one or more embodiments of the present disclosure;

FIG. 2 is a block diagram of the planning system of FIG. 1 according to one or more embodiments of the present disclosure;

FIG. 3 is a block diagram of example internal components of a first level component or a second level component of the planning system of FIG. 2 in accordance with one or more embodiments of the present disclosure;

FIG. 4 is a block diagram illustrating scalability of the planning system of FIG. 1 in accordance with one or more embodiments of the present disclosure;

FIG. 5 is a block diagram of the planning system of FIG. 1 operating in an estimation mode in accordance with one or more embodiments of the present disclosure;

FIG. 6 is a flow diagram of a method for operating the planning system of FIG. 5 in an estimation mode, in accordance with one or more embodiments of the present disclosure;

FIG. 7 is a flowchart of a method for operating the planning system of FIG. 2 in an execution mode in accordance with one or more embodiments of the present disclosure;

FIG. 8 is a timing diagram of a rough estimate or abstract plan refined by performing an overlay stack method in an estimation mode, according to one or more embodiments of the disclosure;

FIG. 9 is a diagram illustrating a series of stages involved in performing an overlay stack method on the rough estimate or abstract plan of FIG. 8 in an estimation mode, according to one or more embodiments of the disclosure;

FIG. 10 is a flow diagram of aspects of a method of overlay stack in estimation mode in accordance with one or more embodiments of the present disclosure;

FIG. 11 is a block diagram of a planning system performing an overlay stack method in an estimation mode in accordance with one or more embodiments of the present disclosure;

FIG. 12 is a flow diagram of activities in an execution mode that result in a return to an estimation mode for re-planning in accordance with one or more embodiments of the present disclosure;

FIG. 13 is a flow diagram of an overlay stack method performed by a second tier component in an execution mode in accordance with one or more embodiments of the present disclosure;

FIG. 14 is an example text rendition of a plan for single-leg drilling produced by an automated platform that performs staged drilling by automating driller's tasks in accordance with one or more embodiments of the present disclosure;

FIG. 15 is an example of a state branching diagram for states accessed in generating the plan of FIG. 14, in accordance with one or more embodiments of the present disclosure;

FIG. 16 is a block diagram of example internal components of an inference system of the planning system of FIG. 2 in accordance with one or more embodiments of the present disclosure;

FIG. 17 is a flow diagram of a method for determining which rules to activate with respect to a query in accordance with one or more embodiments of the present disclosure;

FIG. 18 is a flow diagram of a method for activating and/or deactivating rules based on updated information in accordance with one or more embodiments of the present disclosure;

FIG. 19 is a flow diagram of a method for determining whether a query is true in accordance with one or more embodiments of the present disclosure;

FIG. 20 is a block diagram of an example composition of an XML representation of a plan (e.g., XPlan structure or syntax) of the planning system of FIG. 2 in accordance with one or more embodiments of the present disclosure;

FIG. 21 is a block diagram of an example composition of an XML representation of the ordered matter of the XPlan of FIG. 20 in accordance with one or more embodiments of the present disclosure;

FIG. 22 is a block diagram of an example composition of an XML representation of a planning action start composition within the plan of FIG. 20 in accordance with one or more embodiments of the present disclosure;

FIG. 23 is a block diagram of example compositions of an indication of when an action ends, in accordance with one or more embodiments of the present disclosure;

FIG. 24 is a state diagram of a timed hybrid automaton tracking states of events representing the start of actions in the plan of the planning system of FIG. 2, in accordance with one or more embodiments of the present disclosure; and

fig. 25 is a state diagram of a timed hybrid automaton tracking states of events representing the end of actions in the plan of the planning system of fig. 2, in accordance with one or more embodiments of the present disclosure.

Detailed Description

One or more specific embodiments will be described below. In an effort to provide a concise description of these embodiments, not all features of an actual implementation are described in the specification. It should be appreciated that in the development of any such actual implementation, as in any engineering or design project, numerous implementation-specific decisions must be made to achieve the developers' specific goals, such as compliance with system-related and business-related constraints, which may vary from one implementation to another. Moreover, it should be appreciated that such a development effort might be complex and time consuming, but would nevertheless be a routine undertaking of design, fabrication, and manufacture for those of ordinary skill having the benefit of this disclosure.

The figures are not necessarily drawn to scale. Some features of the embodiments may be exaggerated in scale or in somewhat schematic form and some details of conventional elements may not be shown in the interest of clarity and conciseness. While one or more embodiments may be preferred, the disclosed embodiments should not be interpreted, or otherwise used, as limiting the scope of the disclosure, including the claims. It should be well recognized that the different teachings of the discussed embodiments may be employed separately or in any suitable combination to produce desired results. In addition, those skilled in the art will understand that the description has broad application, and the discussion of any embodiment is meant only to be exemplary of that embodiment, and not intended to intimate that the scope of the disclosure, including the claims, is limited to that embodiment.

When introducing elements of various embodiments of the present disclosure, the articles "a," "an," and "the" are intended to mean that there are one or more of the elements. The terms "comprising" and "having" are used in an open-ended fashion, and thus should be interpreted to mean "including, but not limited to …". Any use of the term "coupled" in any form, or any other term describing an interaction between elements, is intended to mean either an indirect or direct interaction between the elements so described. The directional terms "vertical," "horizontal," "upper," "lower," "upward," "downward," and the like are not intended to imply or relate to a particular physical direction, but are intended to provide relative conceptual relationships, e.g., "vertical" as opposed to "horizontal," and "upper" as opposed to "lower," in order to describe relative and/or different domains, levels, layers, process streams, etc.

Certain terms are used throughout the description and claims to refer to particular features or components. As will be appreciated by those of skill in the art, different persons may refer to the same features or components by different names. This document does not intend to distinguish between components or features that differ in name but not function unless otherwise indicated.

Embodiments of the present disclosure relate to an automatic planning system that uses a scalable infrastructure to support multi-domain and multi-layer planning-based control of an autonomous system. The automatic planning system and method may automatically generate a concurrent sequence of actions, referred to as a plan, to achieve a desired future state of the autonomous system from a current state of the autonomous system while adhering to certain constraints. Each automated planning system may control the operation of the equipment to perform a respective plan and/or sub-plan. The actions or activities performed by the equipment may include transitions between states, where a state may include a combination of facts describing the situation. These facts may include equipment patterns (e.g., whether equipment is operating, open, closed, etc.), relationships between objects, assignment of numerical variables, etc. For applicable actions, it may be detected via the sensor that certain preconditions are in the first state, and after application, the effect thereof may lead to the desired second state. The planning may include a concurrent sequence of actions beginning with an initial state and ending with a target or final state.

Example multi-domain planning and execution systems and methods are disclosed whereby each planning component in a decomposed architecture is associated with its own domain, each planning component can oversee the hierarchy below it, and manage dependencies between domains through coordination of goals and constraints. For example, a computing device may be communicatively coupled to equipment; including a first hierarchy component having a first hierarchy planner component that generates a first hierarchy plan associated with operations using the equipment; and a second hierarchy component, each second hierarchy component associated with a respective equipment, and each second hierarchy component comprising a second hierarchy planner component that generates a second hierarchy plan based on the first hierarchy plan, wherein the second hierarchy plan has instructions to perform a portion of the operations, and each second hierarchy component instructs each respective equipment to perform a respective second hierarchy plan.

The multi-domain, multi-level, automatic planning system and method of the present disclosure may be used in any number of industries and applications in which coordination between multiple domains of automation and control may be achieved, including, for example, logistics, transportation, automated manufacturing, automated design, medicine, robotic systems, energy distribution, oil and gas (e.g., well construction, well stimulation and production, exploration and oilfield development, remote monitoring), or any other industry or application.

For illustrative purposes only and not limitation, in examples related to drilling applications in the oil and gas industry, the autonomous planning system of the present disclosure may coordinate drilling wellbore activities and mud flow rates while drilling a wellbore. For example, an automatic planning system may specify a plan (e.g., a drilling operation plan) to perform a drilling operation when drilling a wellbore to a particular depth, and send instructions to other automatic planning systems to make the sub-plan. For other examples, the well operation may include building a well, operating a well (e.g., to generate a desired amount of hydrocarbons from a well for a desired amount of time), stopping the operation of a well, or any other suitable operation of a well. Thus, in the case of a well operation plan, the plan may include concurrent sequences of actions such as building a well, operating on an existing well, modifying the configuration of a well, stopping operating on a well, generating a desired amount of hydrocarbons from a well for a desired amount of time, and so forth. For other examples, the concurrent sequence of actions may include building the well from an initial state where the well is not yet present and the wellbore has not yet been drilled for a desired amount of time to a target state where the well has been built. In alternative or additional embodiments, the concurrent sequence of actions may include, for example, operating the well to generate a desired amount of hydrocarbons from the well for a desired amount of time.

In addition, the automated planning system may employ intelligent guided searches to explore a variety of alternative choices and action arrangements, and may generate a plan that optimizes one or more objective metrics (e.g., cost or total planning duration). The plan may be automatically generated given any state, object or domain description and a set of constraints. The goal may include a set of expected conditions in the final state of the plan. The domain may include a description of actions available within a particular application area. In some embodiments, the re-planning may be triggered when an unexpected change occurs during the execution of the planning. Unlike script behavior, the plans generated by the automatic planning system and method of the present disclosure fail and quickly regenerate when encountering unanticipated changes. Thus, the automated planning system and method of the present disclosure may provide a flexible and robust basis for intelligent automation of an autonomous system. In a multi-domain context, failures and re-planning may be isolated to subcomponents of the system, propagating to the supervisor level only when global constraints are violated.

The presently disclosed scalable infrastructure or planning-based execution and control system or architecture or planning system may support multiple domains and multiple layers of planning-based control of an autonomous system. The planner component of the planning system can automatically generate a plan given the domain, the initial state, the target, and the set of constraints. In some embodiments, the planner component may be implemented as a Partial Order Planning Extension (POPEX) component, which is a planning system based on a forward search heuristic planning system, such as a Partial Order Planning Forward (POPF) system. The planner component can plan based on time and numerical quantities to infer continuous changes in concurrent activity and time coordination. The planner component can determine when the set target cannot be reached and return an indication that the target cannot be reached. Otherwise, the planner component may search for plans until a plan is found, or until a time or memory limit is exceeded.

For example, the planner component may attempt to automatically determine a plan for drilling the wellbore based on a schedule (e.g., deadlines for drilling the wellbore and/or deadlines associated with phases for drilling the wellbore) and available resources (e.g., drilling equipment, mud injection equipment, mud flow rates of the mud injection equipment, availability of the drilling equipment and the mud injection equipment, etc.). The planner component can determine the plan within a given time and/or memory constraint, otherwise indicate that the plan cannot be determined under the time and/or memory constraint.

By way of introduction, FIG. 1 is a block diagram of a planning-based execution and control system 10 or planning system according to an embodiment of the present disclosure. Planning system 10 may include computing device 12 communicatively coupled to equipment 14 via data link 16, which data link 16 may be a wired link, a fiber optic link, any other suitable physical data link, or any suitable wireless data link. The equipment 14 may include one or more equipment components, control units, and/or actuator control units 18, 20. Specifically, the computing device 12 may be communicatively coupled to actuator control units 18, 20 for controlling operation of components in the equipment 14. The actuator control units 18, 20 may be in the form of, for example, physical components, software systems, software updates, engineering hardware, data manipulation systems, any combination thereof, etc., and may be co-located with the planning system 10, a distance apart, or remote from the planning system 10.

By way of illustration only and not limitation, the equipment 14 may be well construction equipment, such as or including drill string, mud equipment, and the like. Thus, in some embodiments, planning system 10 may be a well construction system. For example, the computing device 12 may be communicatively coupled to a drilling control unit 18, which drilling control unit 18 may control operation of the well construction equipment 14 (e.g., drilling equipment). For example, drilling control unit 18 may control motors to drive or stop drilling equipment, receive data from sensors that detect drilling actions, control pumps, and/or control any other suitable components used by well construction equipment 14. The computing device 12 may also be communicatively coupled to a mud control unit 20, which mud control unit 20 may control the operation of the mud flow in the well construction equipment 14. For example, the mud control unit 20 may control the flow rate of mud directed through and out of the well construction equipment 14.

Computing device 12 may include any suitable device capable of executing planning system 10, such as a desktop computer, a laptop computer, a mobile electronic device, a server, or the like. It should be noted, however, that computing device 12 may be specifically designed to enable different components to interact with each other to update a plan based on actions and/or data from other components. Computing device 12 may include an input/output interface 22 coupled to data link 16. Computing device 12 may also include any type or number of computer processors or microprocessors 24 capable of executing computer-executable code. The computing device 12 may also include one or more volatile memory (e.g., random access memory) devices 26 and/or one or more non-volatile memory (e.g., solid state disk or flash memory) devices 28 that may be used as machine-readable storage media to store processor-executable code, data, and the like. These articles of manufacture may represent machine-readable media (i.e., any suitable form of memory or storage) that may store, among other things, processor-executable code (such as execution and control programs or planning programs 30) that processor 24 uses to perform operations that may be used to execute planning system 10. Machine-readable storage media are different from, and exclude, machine-readable transmission media, including wireless signals, transmission waves, carrier signals, etc., but are intangible. A machine-readable medium may encompass both a machine-readable storage medium and a machine-readable transmission medium.

In general, the planning program 30 may receive a particular target/state (e.g., drilling a well in a target time), generate a plan (e.g., a well job plan) based on the target/state, and send actions of the generated plan (e.g., drilling to a target depth in the target time, injecting mud for a target duration beginning at the target time, etc.) for execution by equipment elements or control units 18, 20 (e.g., drilling control unit 18 and/or mud control unit 20 and/or any number of other control units (not shown)). In some cases, planning program 30 may reprogram or retime some actions of the generated plan based on data related to one or more control units 18, 20, targets/states, etc.

Fig. 2 is a block diagram of planning system 10 of fig. 1 in accordance with an embodiment of the present disclosure. Planning system 10 may include different modules or components that operate using processor 24. For example, planning system 10 may include instances of a first tier component 40 and a second tier component 42. Each of the first hierarchical level components 40 and the second hierarchical level components 42 may include a planner component 44, which planner component 44 can automatically generate a plan given a domain, an initial state, a goal, and a set of constraints. In some embodiments, the planner component 44 may be implemented as a copy of the POPEX, which may interact with some dedicated theme component (SSC) 46 (e.g., a physical model) through a unified interface 48. The various SSCs 46 can employ the same or different types of solutions to each other. The various planner components 44 may be the same as or different from each other.

In particular, a dedicated subject component (SSC) 46 can provide one or more properties 47 of the state (discussed further with reference to fig. 3) to the planner component 44. The status may include a combination of facts describing the situation, and each fact may include equipment patterns, relationships between objects, assignment of numerical variables, and so forth. Accordingly, the dedicated subject component 46 may include and/or provide dedicated data and/or patterns to assist the planner component 44 in performing operations. The unified interface 48 may provide a communication gateway between the planner component 44 and the dedicated theme component 46.

Although first tier components 40 and second tier components 42 are shown, the multi-domain planning system of the present disclosure may include components in any number of tiers, for example, three tiers, four tiers, five tiers, or about tens, hundreds, or more tiers. In other words, while the present disclosure illustrates planning system 10 as a two-level architecture (e.g., first-level component 40 and second-level component 42), it should be appreciated that any suitable number of levels (e.g., having multiple first-level components 40, multiple levels of second-level components 42, higher-level components, multiple levels of higher-level components, etc.) are contemplated. Additionally or alternatively, the relationship between the first level and the second level (or parent-child level or director-subordinate level, etc.) may occur multiple times within the hierarchy, i.e., the hierarchy may repeat and propagate. That is, the second level relative to the first level may itself serve as the first level of another (different) second level, i.e., the local first/second level may be considered a higher ordered level (e.g., level 27/28, 107/108, etc., at random) in the context of a larger or entire tree, structure, or hierarchy.

As shown, the first tier component 40 may communicate with each second tier component 42 through a constraint-based unified interface or constraint interface 50. Constraint interface 50 may provide a communication gateway between first tier component 40 and each second tier component 42, thereby providing coordination of actions or activities pertaining to different second tier components 42. The first hierarchical component 40 may plan and coordinate actions at a higher level than the second hierarchical component 42, while the second hierarchical component 42 may plan and coordinate actions in its particular expertise or expertise domain. As an illustrative and non-limiting example, the first tier component 40 may plan and coordinate actions with respect to drilling a wellbore, and the second tier component 42 may plan and coordinate actions with respect to drilling, mud injection, casing, cementing, etc., and/or any other planning component(s) (e.g., a plurality of peers) at the tier.

In embodiments, the first hierarchical components 40 may coordinate strategic planning and planning execution to achieve the goals of some applications (e.g., drilling wells to extract hydrocarbons, fracturing rock formations to improve extraction of hydrocarbons from wellbores, etc., by way of non-limiting illustration in the oil and gas industry), and each second hierarchical component 42 may include a tactical planning and execution system that performs a portion of the operations for the respective application. Each portion of the operation may correspond to a detailed development of how the first hierarchical component 40 provides a plan corresponding to its actions. When the planner component 44 of the first hierarchical component 40 communicates with the second hierarchical component 42 (e.g., sends a higher level plan to the second hierarchical component 42), the second hierarchical component 42 may respond with one or more plans.

The first hierarchical component 40 and the second hierarchical component 42 may each develop a domain description and a planning of a set of objectives specific to their own area of responsibility. The domain descriptions, state descriptions, and sets of targets may be written in a planning domain language (e.g., planning Domain Description Language (PDDL), e.g., PDDL 2.1). When the inputs to the planning component are written in a standard version of PDDL, there is no need for a hierarchical domain description as is required in Hierarchical Task Network (HTN) planning and/or method extensions, thus the use of such PDDL (or similar) languages enables management of the hierarchical coordination of the multi-level system by constraint delivery and asynchronous execution of activities, as presently disclosed.

Planning system 10 may enable the plurality of second-level components 42 to communicate with first-level components 40 via constraint interface 50 by way of an expressive constraint language. In an embodiment, constraint interface 50 may be a language capable of communicating XPlan and timeline constraints. In an embodiment, constraint interface 50 may be based on a logic-based communication layer, e.g., a standard Boolean logic-based communication layer used in SAT modulo theory (a method that enables variables in Boolean formulas to be evaluated using a specialized theory such as Peano arithmetical (Peano arithmetical).

Methods and systems of the present disclosure may include hierarchical coordination of a multi-level system managed by constraint delivery and asynchronous execution of activities, and/or decomposition into multi-domain models of local specialty domains with local constraints. Each planning component may have its own domain and its own constraints. The planning components may be independent of each other but capable of communicating with each other via their constraints. Such methods and systems may provide scalability and modularity, and through scalability and modularity provide the ability to address orphaned failures, for example, using locality expertise responsible for the failure.

Planning system 10 may include a modular hierarchy design in which first tier component 40 and second tier component 42 operate at different tiers, have the same or similar structures or components, and are capable of communicating via constraint interface 50. Planning system 10 may thus enable scalability and versatility of planning-based control without relying on domain-specific content.

Thus, while certain types of applications associated with the second-level component 42 are shown in this disclosure (e.g., applications related to hydrocarbon extraction, including but not limited to drilling, mud injection, hydraulic fracturing (e.g., pumping stages, sand or proppant transport), cementing, well construction, etc.), it should be understood that these types of applications are by way of example only, and any suitable type of application in any industry or field may be envisaged.

Moreover, the location of the functionality shown in planning system 10 (e.g., dedicated subject component 46 in each of first tier component 40 and second tier component 42) is also merely by way of example, and any suitable location for functionality is also contemplated. In practice, planning system 10 may be flexible enough for domain experts to use it in a plug and play manner for a variety of industries and domain and/or sub-domain applications.

In some embodiments, planning system 10 may incorporate both a trial and error reasoning system and a planning execution and control system involved in overall planning-based autonomous behavior, as will be discussed in further detail below. Inference system 52 can receive signals (e.g., including sensor information) from sensors (e.g., via data acquisition system 54) and interpret the associated states for transmission to first tier component 40 and second tier component 42. Interpretation may involve several layers of filtering and conditioning before the associated state is determined. Inference system 52 may facilitate the conversion of data (e.g., received via data acquisition system 54) to abstract patterns in a PDDL (planning domain description language) model. Plan execution system 56 may execute the plan output by each second tier component 42. In particular, the plan execution system 56 may send instructions to the equipment 14 and/or one or more actuator control units 18, 20 based on the plan or planned actions. For example, if the equipment 14 is well construction equipment, the plan execution system 56 may send instructions to the drilling control unit 18 to start, stop or adjust drilling, to the mud control unit 20 to start, stop or adjust mud injection, etc., based on the plan or planned actions. Thus, each planner component 44 of the second hierarchy component 42 may be communicatively coupled to a respective control system, unit, or equipment (e.g., drilling control unit 18, mud control unit 20, etc.).

Continuing with the example, the first-level component 40 may coordinate the activities of the second-level component 42 that assist in drilling the wellbore. For example, the first second-level component 42 may be a drilling platform that performs staged drilling by providing commands to the drilling control unit 18. The second-level component 42 may be a mud system (e.g., mud control unit 20) that coordinates the deposition and supply of mud during the drilling operation of the drilling control unit 18. In some embodiments, each second-level component 42 may reside within a rig-integrated well execution system, built on an acquisition, aggregation, and recording platform.

Fig. 3 is a block diagram of example internal components of one or more first tier components 40 or second tier components 42 of the planning system of fig. 2 in accordance with an embodiment of the present disclosure. Each internal component of the first hierarchical component 40 and the second hierarchical component 42 may be dedicated to performing a respective operation such that an ordered combination of operations enables the first hierarchical component 40 and the second hierarchical component 42 to efficiently coordinate machine (e.g., equipment 14) operations and planning generation. Each of the first hierarchical component 40 and the second hierarchical component 42 may include an operations manager 70, the operations manager 70 managing the operations of the respective first hierarchical component 40 or second hierarchical component 42. The operations manager 70 may include a review control layer 72, which review control layer 72 generates a plan 74 and coordinates the components that provide input to the review control layer 72. The operations manager 70 may also include a reactive planning execution layer 76 that may schedule actions 78 to an execution and monitoring component 80, which execution and monitoring component 80 may in turn send actions or commands 82 to a control system gateway 84. Control system gateway 84 may then control the operation of equipment 14 based on actions or commands 82. For the illustrative example, if the equipment 14 is well construction equipment, the plan execution system 56 may send commands 82 to the drilling control unit 18 to start, stop, or adjust (e.g., speed, torque) drilling, send commands to the mud control unit 20 to start, stop, or adjust mud injection (e.g., material, flow rate), etc.

Inference system 52, discussed in detail below, may receive data or signals 86 from sensors (e.g., of data acquisition system 54) and infer a status of planning system 10 based on the received data or signals 86. The sensors may record data (e.g., pressure, flow, temperature, or any suitable parameter that can be sensed) that may be associated with the operation of the respective machine.

A concierge (confinger) component 88, which may be disposed between the interrogation control layer 72 and the reactive plan enforcement layer 76, may receive input (e.g., status) 90 from the inference layer or system 52 and determine when to send a re-plan and re-schedule request 91 to the planner component 44. Concierge component 88 can ensure that planner component 44 has completed its current planning task before issuing a new planning request 91. In some embodiments, concierge component 88 may coordinate operations (e.g., passing requests) between the interrogation control layer 72 and the reactive plan enforcement layer 76. Layers 72 and 76 (and other layers) may or may not include active series or loops at different operating frequencies. For example, the interrogation control layer 72 may operate at a lower frequency (e.g., minutes or hours), while the reactive sensing and control by the control system gateway 84 may operate at a higher frequency (e.g., milliseconds), and the reactive planning execution layer 76 may monitor execution at an intermediate frequency (e.g., seconds).

The context gateway 93 may generate and/or provide planning related parameters 92 such as domain models, macros, initial states, constants, etc. to the planner component 44. The planner component 44 can also receive inputs (e.g., properties 47 of states, outputs from physical models, etc.) from the dedicated theme component 46. The planner component 44 can send the plan 74 back to the concierge component 88, and the concierge component 88 can forward the plan 94 to a plan dispatch component or dispatcher 96. The scheduler 96 may ensure that any plans 94 that are currently being scheduled are purged before starting to schedule the new plan 94, e.g., the scheduler 96 may not schedule the new plan 94 until the plans 94 that are currently being scheduled are completed. The planning scheduler 96 may output to the execution and monitoring component 80 an action 97 to be performed via the control system gateway 84.

The interrogation control layer 72 may also include an motivational component 98 that receives input from a human-machine interface 100 (e.g., a graphical user interface) and an interrogation inference component 102 of the inference system 52. The human-machine interface 100 may communicate input 101 from a user and output to the user. For example, a user may adjust, via the human-machine interface 100, a goal, priority, or any other suitable parameter associated with the first tier component 40 and/or the second tier component 42. The interrogation inference component 102 can generate the state 90 based on inferences based on data or signals 86 received from the data acquisition system 54, while the reactivity inference component 106 can generate the state 108 based on data or signals 86 received from the data acquisition system 54. In particular, the state 90 generated by the interrogation inference component 102 can be associated with interpreting and/or converting a signal (e.g., data or signal 86 from the data acquisition system 54) to an appropriate hierarchy (e.g., with the first hierarchy component 40, the second hierarchy component 42, etc.). The state 108 generated by the reactivity inference component 106 may be associated with a signal (e.g., data from the data acquisition system 54 or the signal 86) that is typically used in a direct form (e.g., without interpretation or conversion).

Thus, the motivational component 98 may output goal related parameters 104 (e.g., domain descriptions, state descriptions, sets of goals, priorities, etc.) to the concierge component 88 based on the input 101 received from the human-machine interface 100 and/or the status information 90 received from the interrogation inference component 102 of the inference system 52.

Concierge component 88 can generate goal 112 based on status 90 and/or goal-related parameters 104 generated by the interrogation inference component 102. The target 112 may be sent to a target arbitration component 114. The target arbitration component 114 can determine which target or targets are to be achieved (e.g., based on a determination by the planner component 44 that the targets are not achieved), or can achieve the targets in what order, and send the resulting targets 116 to the planner component 44. The planner component 44 can then generate the plan 74 based on the targets 116, the plan-related parameters 92, and/or the properties 47 of the states from the dedicated theme component 46. The planner component 44 can send the plan 74 to the concierge component 88, which in turn can send the plan 94 to the scheduler 96.

The execution and monitoring component 80 may report to the scheduler 96 whether and when the action 97 (scheduled by the scheduler 96 to be executed by the control system gateway 84) and/or the command 82 has been executed 118. In the event that action 97 and/or command 82 cannot be performed, scheduler 96 may report indication 120 of the miss to goal to concierge component 88.

With continued reference to fig. 3, the illustrated three-tier architecture (e.g., the interrogation control layer 72 and the reactive planning execution layer 76 of the operations manager 70, and the inference tier or system 52) may be implemented in each of the first tier component 40 and the second tier component 42. Implementing each of the first tier components 40 and the second tier components 42 using the same three tier architecture improves scalability in the planning system 10. Moreover, each of the first hierarchical component 40 and the second hierarchical component 42 may be focused on performing a respective operation such that a specific ordered combination of operations enables the first hierarchical component 40 and the second hierarchical component 42 to efficiently coordinate machine (e.g., equipment 14) operations and planning generation. The architecture shown may be based on any suitable three-tier architecture, such as the madbase three-tier architecture or another three-tier architecture used in planning-based robotic control (capable of building plans, refining actions into execution sequences, and re-planning when failures occur in execution).

Fig. 4 is a block diagram illustrating the scalability of planning system 10 of fig. 1 in accordance with an embodiment of the present disclosure. Each of the first hierarchical component 40 and the second hierarchical component 42 may include an operations manager 70, which operations manager 70 may include a interrogation control layer 72 (as shown in fig. 3), which interrogation control layer 72 may be programmed to achieve an objective or effect (e.g., 112, 116) associated with the respective first hierarchical component 40 or second hierarchical component 42. In some embodiments, each of the first tier component 40 and the second tier component 42 may include a POPEX planning system (e.g., as part of a planner component 44 as shown in fig. 2-3), and each may receive a PDDL domain model having its own predicates, functions, and actions associated with its particular region of responsibility. For each planner component 44, the respective planner component 44 may communicate with some dedicated topic component 46 (see fig. 2-4) associated with the respective first tier component 40 or second tier component 42 via a unified interface 48 (as shown in fig. 2). For example, a second tier component 42 representing a drilling application may communicate with the model to give rate of penetration optimization (ROPO) and steering advice for the drilling operation. More generally, the dedicated subject component 46 can include a model (e.g., a physical model) that can be consulted in generating a plan (e.g., 74, 94 (fig. 3)) and enable the planner component 44 to make informed selections regarding properties 47 (fig. 3) of states, equipment patterns, relationships between objects, assignments of numerical variables, and so forth.

With continued reference to fig. 4, the operations manager 70 may also include a reactive plan execution layer 76, as shown in fig. 3, enabling the respective first tier component 40 or second tier component 42 to schedule and monitor its own actions (e.g., 97). The action 97 in the plan 94 of the first tier component 40 may be a first tier action such that it may be refined by the more specialized second tier component 42 or a second tier (e.g., specific) action or command 82 that may be directly scheduled to the control system gateway 84 via the execution and monitoring component 80 (see fig. 3). Act 97 may be performed by equipment 14 and/or one or more actuator control units 18, 20 (fig. 1) (e.g., drilling control unit 18, mud control unit 20, additional equipment 99 and/or one or more control units 18, 20, etc.), and may include transitions between states. For applicable actions 97, it may be detected via sensors (e.g., of the data acquisition system 54) that certain preconditions are in a first state, and after application, their effect may result in a desired second state. The planning may include a concurrent sequence of actions beginning with an initial state and ending with a target or final state. In each of the one or more first tier components 40 and second tier components 42, the plans 74, 94 may be output as an XML document containing annotations describing the conditions under which the action 97 is authorized to be scheduled to the execution and monitoring component 80 and the constraints that may be observed during execution of the action 97.

Proper execution may depend on constraints, such as adhering to invariants related to scheduling or deadlines. The annotations may enable the execution of the plans 74, 94 to be monitored by the execution and monitoring component 80 to ensure that constraints are not violated. The XML document is referred to as an XPlan 125 and may be a form of communication between the first hierarchical component 40 and the one or more second hierarchical components 42. It should be appreciated that the programming of the present disclosure may be referred to by any one or more of a variety of reference numerals (e.g., 74, 94, 125, 200, 240, 248, 249, 242, 252, 282, etc.), each of which may refer to a programming or "XPlan.

In some embodiments, the constraints may include standard operating procedures or contractual agreements (SOPs) to be adhered to. SOP constraints may be captured, for example, in the PDDL, included in the initial state description of the planning system, and/or integrated with dynamic re-planning to ensure that dynamic procedures are complied with throughout the planning generation and execution. In the drilling context, SOP constraints may include, for example, methods for ensuring wellbore stability (e.g., flow checks and/or integrity tests at specified points in the wellbore), methods for handling unplanned events (e.g., kick, stuck, washout), and the like. The operations may be defined for performance, for example, by defining a label for the constraint at a specific point, such as a spatial label, a temporal label, a resource-related label (e.g., a volume label), or any other type of label. By way of illustration in the drilling context, examples include markings at the casing shoe, a range of depths over which operations must be performed, and/or operations to be performed with respect to a specified stage of the overall drilling process.

If an unplanned event occurs, the planning is performed failed and the initial state description is rewritten for re-planning (discussed in further detail below). The rewritten initial state description may include other SOP constraints related to the event diagnosed to ensure that upon re-planning, the planning system must construct a plan that meets all of the program requirements known at the time.

Each of the one or more first tier components 40 and second tier components 42 may be coupled to a control system gateway 84, and the second tier actions or commands 82 may be sent to a control system (e.g., one or more actuator control units 18, 20 and/or additional equipment 99) for execution through the control system gateway 84. The control system may then adjust the operation of equipment 14 to invoke the corresponding action. As with inference system 52, control system gateway 84 may be shared with the entire planning system 10.

Thus, each of the one or more first tier components 40 and second tier components 42 may plan, schedule, and monitor actions in their respective domains. The domain may include a description or list of available actions of the respective first tier component 40 or second tier component 42. As shown in fig. 4, each second tier component 42 may receive as input an XPlan 125 (e.g., referring to fig. 3, the XML document containing comments describing the conditions under which the action 97 is authorized to be scheduled to the execution and monitoring component 80 and the constraints that may be observed during execution of the action 97).

The XPlan 125 may include a desired time (e.g., a timing goal) at which the second tier component 42 may attempt to achieve the effect or goal 112, 116 and the constraints that it may attempt to satisfy. The timing targets may be associated with points in time or intervals at which the second tier component 42 should achieve the targets 112, 116. Constraints may include restrictions on when action 97 may occur, when plans 74, 94 may be achieved, or when goals 112, 116 may be achieved. The planner component 44 (fig. 2-3) of the operations manager 70 of each first tier component 40 and second tier component 42 may output an XPlan 125 (fig. 4), which XPlan 125 imposes its own constraints on the scheduling and execution of its respective actions 97. Thus, planning system 10 may implement a powerful modularity that enables it to scale to a large number of second-level components 42. Additional details regarding the XPlan 125 will be discussed below with reference to FIGS. 20-25.

In some embodiments, the generation of the plans and execution of the plans within planning system 10 can be based on rescheduling and/or validating the software. In the operations manager 70 (see fig. 3-4), the planned actions 97 may be rearranged within the existing time constraints of the plans 74, 94. Verification may include a step-wise simulation of the executing plan 74, 94. In the event that data-driven inferences are not available, verification of the plan generation and/or execution may be performed by fully simulating the steps of the plans 74, 94, for example, via a form of dead reckoning inference. In general, dead reckoning inference techniques can be used to verify that a system operating in open loop control (where there is no feedback from the sensor) is operating in the current state. Thus, verifying the plan 74, 94 by fully simulating the steps of the plan 74, 94 may not occur, for example, if the results of the steps of simulating the plan 74, 94 are not observed.

Mode of operation

In some embodiments, planning system 10 may operate in two different modes of operation (an estimation mode and an execution mode).

1. Estimating a pattern

a. General rule

The estimation mode includes a multi-level planning activity, such as the construction of a multi-level plan prior to performing anything. In the estimation mode, in the operations manager 70 (see, e.g., fig. 3-4), the first-tier goals may be achieved using coordinated efforts between the first-tier component 40 and the second-tier component 42 to generate the plans 74, 94 (see, e.g., fig. 3). The plans 74, 94 may include first-level actions that constitute the plans 74, 94, which may be refined by the second-level components 42 based on more detailed and application-based (e.g., drilling-based, mud-based, etc.) information associated with the respective second-level components 42, and actions that the first-level components 40 may schedule directly (as second-level actions or commands 82) to the control system gateway 84. In the execution mode, the first tier component 40 may schedule the plans 74, 94 to the second tier component 42, which may recall the second tier component 42 to refine the first tier action, and send the second tier action or command 82 directly to the control system gateway 84.

Fig. 5 is a block diagram of the planning system 10 of fig. 1 operating in an estimation mode in accordance with an embodiment of the present disclosure, and fig. 6 is a flowchart of a method 150 for operating the planning system 10 of fig. 5 in an estimation mode in accordance with an embodiment of the present disclosure. The method 150 may be performed by any suitable device or combination of devices that may generate a first hierarchical plan and a second hierarchical plan (e.g., at the first hierarchical component 40 level and the second hierarchical component 42 level, respectively) and determine whether the second hierarchical component 42 may achieve the goal of the first hierarchical plan. Although the method 150 is described using steps in a particular sequence, it should be understood that the present disclosure contemplates that the described steps may be performed in a different sequence than the illustrated sequence and that some of the described steps may be skipped or performed altogether. In some embodiments, at least some of the steps of method 150 may be implemented by a processor, such as processor 24 (fig. 1). In alternative or additional embodiments, at least some of the steps of the method 150 may be implemented by any other suitable processor or control logic (e.g., one or more actuator control units 18, 20 (e.g., a drilling control unit and/or a mud control unit)) and/or associated with additional equipment 99.

Referring to fig. 5, in an interrogation control layer 72 (see, e.g., fig. 3) of the operations manager 70 within each of the one or more first tier components 40 and second tier components 42, the planner component 44 may generate a plan 74 (see, e.g., fig. 3) using an action model associated with a particular region of responsibility of the respective first tier component 40 or second tier component 42 (e.g., derived from a PDDL domain model received from the upper and lower Wen Wangguan). For example, referring to fig. 5 and 6, processor 24 (see fig. 1) may generate (process block 152 of fig. 6) a first-tier plan 74 via planner component 44 of operations manager 70 of first-tier component 40, with associated actions 97 and targets 112, 116 (see, e.g., 3) of first-tier component 40. The planner component 44 (e.g., of the first hierarchical component 40) can confirm that the second hierarchical component 42 implementing the generated plan 74 can achieve the corresponding objective within the appropriate constraints. For example, processor 24 may determine (decision block 154 of fig. 6) via planner component 44 of first-level component 40 whether second-level component 42 associated with first-level plan 74 may achieve the effect or goal 112, 116 of the first-level plan. The first level component 40 may include a highest level domain model. The second level component 42 can generate a second level (e.g., detailed) plan 74 to complete the first level actions generated at the level of the first level component 40. For example, if the processor 24 determines that the second-level component 42 can achieve the goals 112, 116 of the first-level plan, the processor 24 may generate (process block 156 of FIG. 6) the second-level plan 74 via the planner component 44 of the second-level component 42 to achieve the goals or effects of the first-level actions of the first-level plan.

By way of the above non-limiting example, in a well construction context, the second-level component 42 associated with the well control unit 18 may generate a second-level plan 74 that achieves the objective or effect of the first-level actions associated with the first-level planned well. Similarly, the second-level component 42 associated with the mud control unit 20 may generate a second-level plan 74, the second-level plan 74 implementing the objective or effect of the first-level action associated with the mud of the first-level plan.

If the processor 24 determines that the second tier component 42 is unable to achieve the goals or effects 112, 116 of the first tier plan, the processor 24 may return to process block 152 (FIG. 6) to generate a new first tier plan based on the capabilities of the second tier component 42 to determine whether its goals 112, 116 are achievable by the second tier component 42.

Thus, referring to fig. 5, there is vertical communication 140, 142 between the first tier component 40 and the second tier component 42 in the planning system 10. In particular, the first tier component 40 may communicate the problem structure 140 to the second tier component 42, and the second tier component 42 may respond with feedback 142 or a set of violated constraints, where the feedback 142 may include a "proof of feasibility" (see, e.g., at 282 of fig. 11), where the feasibility proof may be or include the XPlan 125 of the second tier constraint or goal 112, 116 imposed by the first tier component 40 (in the form of plans 74, 94). The set of constraints may be empty, may not be exhaustive, and/or may include an out-of-memory and/or timeout error message from planner component 44.

The first tier component 40 can use the feedback 142 to identify constraints and resource requirements. The plan 74 and constraints of the hierarchy of the second-hierarchy component 42 may be considered as "estimates" of the resource requirements of the second-hierarchy component 42 to reach the targets 112, 116 communicated thereto. Thus, the planner component 44 of the first hierarchical component 40 may determine whether the second hierarchical components 42 are able to achieve the goals 112, 116 of the first hierarchical plan by determining whether each second hierarchical component 42 is able to achieve the goals 112, 116 of the first hierarchical plan within the constraints and resource requirements communicated to it. Once the plan 74 is generated by the second tier component 42, the plan 74 may be sent back to the first tier component 40 as an XPlan125, as described further below with respect to the overlay stack method (see, e.g., fig. 9 and 12), allowing its constraints to be absorbed into the first tier plan. When the respective second tier components 42 have returned their plans 74/125, the first tier component's planner component 44 (e.g., the first tier planner component) may continuously monitor the data from the data acquisition system 54 to determine if the first tier plan is still intact to reach its targets 112, 116.

While the present disclosure illustrates planning system 10 as a two-level architecture (e.g., first level component 40 and second level component 42), as described above, it should be understood that any suitable number of levels (e.g., having multiple first level components 40, multiple levels of second level components 42, higher level components, multiple levels of higher level components, etc.) are contemplated and that second level component 42 may serve as first level component 40 of another higher level (relative to second level) component.

In an embodiment, the estimation mode may include two hypotheses based on the domain model and the nature of the target. First, the hierarchy of planning system 10 may have a downward refinement property whereby if there is an executable plan for a given target group, then (with the possible exception of a fixed time limit) there is a first level plan for that target group, and the first level plan may be refined to a second level action without returning to first level component 40 for a plan adjustment (estimated schema assumption 1). Second, the first tier component 40 may not set a timing target that has a hard upper or lower limit on the duration of activity. That is, as the estimation mode proceeds, the time limit may be lengthened to the future, or shortened (estimation mode hypothesis 2). These two assumptions may be used in the estimation mode when constructing the plan before execution begins.

b. Method for stacking coverage

A modular scalable approach (referred to as an overlay stack approach) may combine constraints from multiple different second-level components 42 during planning in the estimation mode. The overlay stack method may generate a plan 74 that satisfies the given constraints and prepares for scheduling. The plan 74 may then be modified/re-planned during execution. In some cases, modifying the plan 74 may include rescheduling where minor timing modifications may be applied. The re-programming, which may be performed for more substantial modifications, may recall the estimation mode and the overlay stack method.

The multi-domain organization and orchestration of the overlay stack approach to support decomposition allows each planning component in the decomposed architecture to be associated with its own domain, with dependencies between domains managed through coordination of targets and constraints. This enables local monitoring of the execution situation and local repair. The method of the present disclosure hands over responsibility from different areas of expertise to different independent sub-domains. The method of the present disclosure also integrates different areas of responsibility into a hierarchy coordinated from the supervisor level. Each planning component at each level of the presently disclosed architecture may operate as a master component of the level below it. In this way, the method of the present disclosure is scalable to many levels and many component domains.

Referring also to fig. 3-5, the overlay stack method may define an interface (e.g., constraint interface 50) between the first tier component 40 and the second tier component 42, which may provide two functionalities in the estimation mode. The first functionality is a rough estimate request that requests a rough estimate of the time and resource requirements of act 97 from first tier component 40. The rough estimate of time may correspond to an expected time range in which the action 97 is expected to be performed or completed. The first tier component 40 may provide a rough estimate based on a priori knowledge or by communicating with the corresponding second tier component 42, depending on how the first tier component 40 is designed and whether the resource requirements of the act 97 depend on the context.

The second functionality is a detailed estimation request, which is obtained by passing a set of timing targets and timeline constraints to the second tier component 42. The second tier component 42 can return a plan 74 indicating that the timing targets can be achieved in the context provided by the current state and timeline constraints. If the plan 74 may not be constructed according to timeline constraints or other constraints, the second tier component 42 can return a message indicating that the goal has not been reached, which can include constraints that cannot be met (e.g., it is not possible to reach the goal g by time t). The first-level component 40 may then attempt to modify the first-level plan or generate a new first-level plan by, for example, changing the targets 112, 116, constraints, or any other suitable parameters.

The first tier component 40 may construct a outline or framework plan by using the rough estimation request to the second tier component 42 via the constraint interface 50. The framework plan may express the causal structure of the plan and identify the resource contention periods between the second tier components 42 (e.g., in the case of a request for the same resource). The causal structure may remain unchanged with refinement of the estimate and no second tier component 42 may use the resource for a period of time that the resource is used by another second tier component 42 (in which case the resource is "locked"). These causal structures and resource contention periods may be expressed as timeline constraints for the second-tier component 42 as part of a detailed estimation request.

The frame plan may include each action 97 for ensuring the correct causal structure of the complete plan 74, but the frame plan may be incorrectly or inaccurately organized in time because it is limited based on the predicted current state (rather than the sensed current state provided by the data acquisition system 54 in the execution mode). Thus, while the framework planning may be scheduled, due to lack of constraints, the corresponding targets may not be reachable, resulting in computationally expensive re-planning work. Even if the framework plan reaches its goal, scheduling the framework plan may result in inefficient and unproductive time because the rough time estimate in the framework plan is not notified. Thus, the detailed estimation request may be used to obtain a more efficient and productive plan prior to execution.

After the framework plan is constructed, details of the framework plan may be developed by requesting detailed estimates from each of the second hierarchical components 42 in turn. The detailed estimate may be obtained by calling the second-level components 42 in an order determined by the interdependencies of the second-level components 42 (e.g., while drilling the wellbore, the detailed drilling components 42 may be called before the detailed mud components 42), which may be obtained by performing a dependency analysis on a domain model of the second-level components 42. To invoke the second hierarchical component 42, the currently estimated timeline (originally the framework plan) may be sent to the second hierarchical component 42. The timeline may include a time window in which the state is maintained, points in time in which the goal may be achieved, and spacers (e.g., time window constraints in which gaps are enforced between actions 97 in the plan 74 of the second-level component in the event that particular resources are not available). The spacer is primarily used to convey resource constraints between components at the same level, while the horizontally conveyed spacer or the vertically conveyed timeline object is an example of a resource constraint. The time window, point in time, and interval may be timing targets expressed in PDDL and/or timeline constraints.

Starting from an initial state, the first tier component 40 and the second tier component 42 may build a plan 74 that prepares for scheduling. Development of the plan 74 may follow the forward direction: each second-level component 42 may decide which actions 97 to include in its respective plan 74, resulting in constraints being imposed on the second-level component 42 receiving the plan. When the second hierarchical component 42 has completed its planning process, the constraints imposed by the final plan 74 may be added to the set of constraints accumulated by the first hierarchical component 40. In other words, the first tier component 40 may build an overlaid stack, with each second tier component 42 contributing a single "transparency". When each second-level component 42 has been consulted, constraints present in the final overlay stack or final overlay plan can be used to stretch, shrink, and reschedule the first-level actions of the plan in the rough estimation phase. This is possible because the estimation mode assumes a downward refinement property (with the possible exception of a fixed time limit) so that the first level actions may not be subdivided and the unexpected first level objectives may be achieved without requiring further actions in the first level plan.

While operating in the estimation mode, planning system 10 attempts to determine a plan 74 that can address its corresponding objective, planning system 10 may not attempt to refine plan 74 prior to execution because the information used to generate plan 74 (e.g., sensor information 86, initial states 90, 108, etc.) may be refined and improved as execution proceeds. Additionally, the rearrangement may accommodate additional and/or later actions 97 of the second tier component 42. Thus, when re-planning can be used after each second-level component 42 call in the estimation mode, re-planning can be used in the execution mode.

Because of the downward refinement nature of the estimation mode (estimation mode hypothesis 1), if a first level plan is generated, an associated second level plan may be generated using an overlay stack method. And because the first tier component 40 may not set a timing target with a hard (e.g., fixed) deadline in the estimation mode (estimation mode hypothesis 2), an effective plan may be generated from the overlay stack when the deadline and resource bound are relaxed. If the hard deadline or resource constraint imposed on the plan 74 is not met (e.g., violating the estimated mode assumption 2), the targets 112, 116 to be solved during the overlay iteration may be over-constrained, resulting in the targets 112, 116 not being reachable. In the event that retiming the overlay stack is insufficient to address these constraints, the first-level component 40 may refine the first-level plan or generate a new first-level plan by, for example, changing the targets 112, 116, the constraints, or any other suitable parameters.

Fig. 8 is an exemplary timing trace of a rough estimation plan 200 for performing an overlay stack method (e.g., process block 304 of fig. 12) in an estimation mode, according to an embodiment of the present disclosure. Fig. 9 is a diagram illustrating an example 230 of an overlay stack method 304 implemented for application to the rough estimate plan 200 of fig. 8, in accordance with an embodiment of the present disclosure.

Referring to FIG. 9, for example, an overlay stack method 304 may be performed in which the rough estimate 200 of a first hierarchical component 40, 232 may represent a higher level plan that coordinates the operation of other components (e.g., the detailed estimate 240 of a first second hierarchical component 42, 234). The detailed estimate 240 of the first second-level component 234 may represent a first-packet-level plan (e.g., drilling "D" in the example drilling context timing trace of the rough estimate plan 200 of fig. 8), the detailed estimate 248 of the second-level component 42, 236 may represent a second-packet-level plan (e.g., mud management "M" in the example drilling context timing trace of the rough estimate plan 200 of fig. 8), and the detailed estimate 249 of the third second-level component 42, 237 may represent a further-packet-level plan of the other second-level component 42.

Referring to fig. 9, which is generally applicable, and as an example in the well construction context, the first tier components 40, 232 may determine or receive the targets 112, 116 (see fig. 3) of the well (e.g., where the initial state includes a location ready to begin drilling activities but where there is no wellbore). The first tier component 232 may generate a coarse estimation plan 200 of the well. The first hierarchical component 232 may then invoke 238 the first second hierarchical component 42 (i.e., the first second hierarchical component 234) in the dependency chain and send thereto timing targets and timeline constraints (e.g., 216) representing the drilling actions 97 (see fig. 3) in the rough estimate plan 200. In the example, the first second-level component 234 may be a first second-level component 42 in the dependency chain, as other second-level components 42 rely on the actions 97 of the first second-level component 234 (e.g., when performing and/or completing drilling activities). The first tier component 40, 232 may request the detailed estimate 240 from the first second tier component 42, 234, ultimately resulting in the development of the rough estimate plan 200 into a final level of detail 252 suitable for execution.

The rough estimate 200, detailed estimates 240, 248, 249, overlay stack 242, final detailed estimate 252, plans 74, 94, and XPlan 125 may be collectively, individually, and/or collectively referred to as a plan or XPlan.

In particular, the bracketed areas 202, 204, 206, 208 correspond to periods of activity or action of the second-level components 42 (e.g., the second-level components 236) other than the first second-level components 234 that may compete for one or more resources of an application (e.g., for casing, cementing, etc., if a well). As shown in fig. 8 and 9, time points t1 through t8 represent points at which the first tier component 232 expects these lock periods or actions 202, 204, 206, 208 to begin and end. For example, the period 206 is locked to a first second tier component 234 but not to a second tier component 236, the second tier component 236 having an activity period 210 in parallel with the first second tier component 234. The lock-in periods 202, 204, 206, 208 may be interpreted as spacers by the first second tier component 234. The lengths of these time periods 202, 204, 206, 208 may not change in the construction of the detailed estimate 240 of the first second tier component 234, but the time periods 202, 204, 206, 208 may be shifted over the coarse estimate plan 200 during the detailed estimate phase, as shown in the figure.

With continued reference to fig. 9, and as a non-limiting example, drilling or other activities may be planned in detail by the first second tier component 234. In particular, the first second-tier component 234 may move the beginning (e.g., 212) and ending (e.g., 214) of its active period (e.g., 216) as long as the spacers (e.g., 204 and 206) are placed between the active areas of the first second-tier component 234 and have a specified length (e.g., t4-t3 for 204 and t6-t5 for 206). In other words, in an embodiment, the respective second-level components 42 (e.g., 234, 236, 237) may move the start and end times (e.g., 212, 214) of the active periods (e.g., 216) of the first-level plan to generate the overlay plan or overlay stack 242, so long as the spacers (e.g., 204, 206) remain placed between the active areas of the respective second-level components 42 (e.g., see fig. 8, t4-t3 for 204 and t6-t5 for 206).

As shown, the length of rough estimate plan 200 is not limited. By overlaying 244 the detailed estimate plan 240 over the rough estimate plan 200, the detailed estimate plan 240 generated by the first second-level component 234 may become the first layer of the overlay stack 242 (see also process block 304 of fig. 12).

The first tier component 40, 232 may then generate 246 a timeline constraint for the next second tier component 42 (e.g., the second tier component 236) in the dependency chain. Specifically, for example, the first hierarchical component 232 may send 246 a timeline constraint to the second hierarchical component 236 requesting a detailed estimate 248 of the work involved in supplying mud for a drilling period (e.g., 216) from the second hierarchical component 236. The second tier component 236 may receive and/or view the rough estimate plan 200 to schedule efficient use of the mud system (e.g., via the mud control unit 20) to achieve the goals (e.g., 216) implied by the scheduling of drilling activities. When the second-level component 236 determines and details its targets 112, 116 in detail, the second-level component 236 can generate actions (e.g., 210) that are scattered or exploded on the rough estimate plan 200, meaning that not all detailed actions (e.g., 210) associated with the first-level actions (e.g., 206) can fit within the bounds marked by the first-level actions. Each period of activity or action 210 planned by the second-level component 236 may fit within the bounds of action 206 planned by the first-level component 232, but there may be flexibility as to which first-level actions 210 define which detailed actions 206.

The second-tier component 236 can return 250 a second-tier detailed estimate or plan 248 of each of its targets that is achieved under the given constraints. The second-level detailed estimate or plan 248 may be set or positioned on top of the overlay 242 generated by the first second-level component 234 and the rough estimate plan 200 (e.g., resulting in an overlay stack 242). If the second-level detailed estimate or plan 248 is not determined (e.g., due to excessive constraints), the second-level component 236 can return an indication of a set of unsatisfiable constraints that have not reached the target and/or that include timeline constraints. Under the estimation mode assumptions 1 and 2 discussed above, the first tier component 232 can rearrange to relax or narrow these constraints by moving the drilling action (e.g., 216) along the rough estimation plan 200.

When the second-level component 236 has completed a successful overlay 250, the first-level component 232 may then generate a timeline constraint for the next second-level component 42. Each second-level component 42 call may be an iteration in the estimation mode process. For example, a third second tier component 42, 237 may be invoked 247 to generate a further refined detailed estimate 249, to a next overlay 251 of the rough estimate plan 200, leading to another tier in the overlay stack 242. There may be any suitable number of iterations or calls to the second-level components 42 to produce a final detailed estimate or schedulable plan 252. That is, the number of second-level components 42 may not be a limiting factor on the number of iterations.

The overlay stack 242 may ensure that the second-level activity (e.g., 216) of the second-level component 42 (e.g., the first second-level component 234) is located within the bounds of the first-level activity belonging to the second-level component 42 on the timeline of the first-level component 40 (e.g., the first-level component 232). That is, while the activity of the second-level component 42 may be scattered or exploded across the timeline of the rough estimate plan 200 (where the second-level component 42 may plan to ensure that it is able to reach both immediate and future commitments), the second-level component 42 may do so within the bounds of what the first-level component 40 recognizes as a higher-level action. The first tier component 40 may be independent of the content within these boundaries, and is related to the constraints within which the second tier component 42 acts strictly. This may enable the first tier component 40 to confidently manage the coordination and locking of resources. That is, the overlay stack method 304 shown in example 230 enables the second tier component 42 to shift actions (e.g., 216) related to achieving future goals to be earlier or later on the timeline as long as the actions remain within the bounds imposed by the first tier component 40.

When a new second-level component 42 is introduced, the planning domain used by the first-level component 40 may be extended to include an abstraction of the activity of the second-level component 42. In addition, if abstractions already exist, they can be connected to new second level components 42. The first tier component 40 may generate a first tier action that accounts for the impact or impact of the new second tier component 42 on the first tier plan, timeline, etc. Similarly, a first tier component 40 may have a first tier representation of a resource lock that prevents two second tier components 42 from using the same resource at the same time.

After each iteration or second-level component call (e.g., 238, 246, 247), the first-level component 40 can confirm that each constraint introduced by the corresponding second-level component 42 on the iteration is satisfied by rearranging as much as possible to reduce non-productive time. After the last iteration, the overlay stack 242 represents a fully or fully tightened version of the entire constraint set 252.

Because the first tier component 40 may not set a timing target with a hard deadline in the estimation mode, a smaller retiming may accommodate the new constraint without having to reprogram. This is because any sub-preference of actions by the first hierarchical component 40 or the second hierarchical component 42 may be mitigated, possibly by introducing additional actions 97 in one or more second hierarchical component iterations, as long as there is no temporal restriction. When the overlay stack 242 is completed, for example, in the form of a final detailed estimate 252, the estimation mode is completed and the planning system 10 may execute the execution mode.

Fig. 10 is a flow diagram of aspects of an overlay stack method 260 (e.g., process block 304 of fig. 12) in an estimation mode according to an embodiment of the present disclosure. In particular, FIG. 10 illustrates the generation of a second level plan or an indication that a second level plan cannot be generated from the corresponding second level component 42 (see, e.g., feasibility certification 282 of FIG. 11 and process block 296 of FIG. 12 (each discussed below)). The method 260 may be performed by any suitable device or combination of devices that may receive the rough estimate plan and the detailed estimate plan. Although the method 260 is described using steps in a particular sequence, it should be understood that the present disclosure contemplates that the described steps may be performed in a different sequence than the illustrated sequence and that some of the described steps may be skipped or performed altogether. In some implementations, at least some steps of the method 260 may be implemented by the second tier component 42. In alternative or additional embodiments, at least some of the steps of the method 260 may be implemented by any other suitable component or control logic (e.g., the first tier component 40 or the processor 24).

The second tier component 42 may receive (process block 262 of fig. 10) a rough estimate plan 200, the rough estimate plan 200 including a second tier component activity start time, a second tier component activity end time, a start limit time, and/or an end limit time. For example, as shown in fig. 8 and 9, the first tier components 40, 232 generate a coarse estimation plan 200, the coarse estimation plan 200 including a second tier component 42 activity start time 212 and a second tier component activity end time 214. In an embodiment, the rough estimate plan 200 may also include timeline constraints in the form of a start limit time 218 and/or an end limit time 220 (e.g., fig. 8-9). (As described above, the downward refinement property of the estimated mode hypothesis 1 is subject to time boundaries that may be imposed, such as a start boundary time 218 and an end boundary time 220. Each second level component 42 may then receive the rough estimate plan 200. For example, as shown in fig. 9, a first second tier component 234 receives 238 a rough estimate plan 200 from a first tier component 232, a second tier component 236 receives 246 a rough estimate plan 200 from the first tier component 232, and a third second tier component 237 receives 247 a rough estimate plan 200 from the first tier component 232.

The second tier component 42 may then determine (decision block 266 of fig. 10) whether a detailed estimated plan (e.g., 240, 248, 249) may be generated in which the activity start time 212 of the second tier component 42 and the activity end time 214 of the second tier component 42 are within the start limit time 218 and the end limit time 220. For example, as shown in fig. 9, to generate the detailed estimated time 240, the first second tier component 234 may shift the second tier component activity start time 212 and/or the second tier component activity end time 214 to achieve its goals. The first second tier component 234 may determine whether the shifted second tier component activity start time 212 and/or second tier component activity end time 214 are within the start limit time 218 and the end limit time 220 (if any).

If the second tier component 42 determines that a detailed estimate plan can be generated within the timeline constraint, the second tier component 42 can generate (process block 268 of FIG. 10) the detailed estimate plan and return the detailed estimate plan to the first tier component 40. For example, as shown in FIG. 9, the first second tier component 234 generates a detailed estimate plan 240 and sends 244 the detailed estimate plan 240 back to the first tier component 232. If the second tier component 42 determines that a detailed estimate plan cannot be generated within the timeline constraint, the second tier component 42 can send (process block 270 of FIG. 10) an indication to the first tier component 40 that the goal was not reached. For example, as shown in FIG. 9, if a first second tier component 234 is unable to generate a detailed estimate plan 240 within the timeline constraint, the first second tier component 234 may send an indication to the first tier component 232 that the detailed estimate plan 240 cannot be generated. In some embodiments, the second tier component 42 may also send a set of constraints (including timeline constraints) to the first tier component 40 that are found to be unsatisfied.

As noted, steps 262-270 may be performed for each second-level component 42 (e.g., for each iteration), and any suitable number of iterations may be contemplated. Moreover, although one second-tier component activity is discussed in connection with a second-tier component activity start time, a second-tier component activity end time, and/or a start limit time and an end limit time (if any), it should be understood that any number of second-tier component activities are contemplated when performing the overlay stack method 304, including as described in the embodiments with reference to fig. 9 (e.g., overlay stacks 242, 252) and fig. 10 (e.g., method 260).

Fig. 11 is a block diagram of planning system 10 performing an overlay stack method in an estimation mode according to an embodiment of the present disclosure. In the estimation mode, each second tier component 42 may generate an initial state (e.g., at 238, 246, 247 of fig. 9) that captures the spacers, time windows, and timing targets associated with its activity when its timeline constraint 280 is received from the first tier component 40 through the constraint interface 50. The second tier component 42 can then determine its plan to achieve its timing goals within these constraints (e.g., at 240, 248, 249 of fig. 9). Feasibility certification 282 (e.g., XPlan 125 of fig. 4-5 and/or final detailed estimate XPlan 252 generated from the timeline constraint of fig. 9) is sent back 289 by the second tier component 42 to the first tier component 40 (e.g., at 244, 250, 251 of fig. 9), which complies with the timeline constraint 280, through the constraint interface 50 to the first tier component 40.

2. Execution mode

a. General rule

After the estimation mode is complete, planning system 10 may enter an execution mode. Fig. 7 is a flowchart (for example) of a method 170 for operating the planning system 10 of fig. 2 in an execution mode in accordance with an embodiment of the present disclosure. The method 170 may be performed by any suitable device or combination of devices that may extract timing targets and timeline constraints from a first hierarchical plan, generate a second hierarchical (e.g., detailed) plan based on the timing targets, the timeline constraints, and the current state, perform the second hierarchical plan, and send an indication to the first hierarchical component that the targets cannot be reached. Although the method 170 is described using steps in a particular sequence, it should be understood that the present disclosure contemplates that the described steps may be performed in a different sequence than the illustrated sequence and that some of the described steps may be skipped or performed altogether. In some embodiments, at least some steps of the method 170 may be implemented by the second tier component 42. In alternative or additional embodiments, at least some of the steps of the method 170 may be implemented by any other suitable component or control logic (e.g., the first tier component 40, the processor 24, the one or more actuator control units 18, 20, and/or the additional equipment 99).

In execution mode, referring to fig. 2-5, 7, and 9, a completed first-tier plan 74, 94, 252 (e.g., denoted XPlan 125) that may be the result of the estimation mode may be scheduled via the reactive plan execution layer 76 that is instantiated in the first-tier component 40. Accordingly, the second hierarchical component 42 may receive (process block 172 of fig. 7) the completed first hierarchical plan 74, 94, 252 including the action 97 from the first hierarchical component 40.

When the scheduler 96 schedules a first level action 97 (which may be identified by a corresponding software module of the action), if the action 97 is an abstract action corresponding to an activity corresponding to a second level component 42, the relevant second level component 42 may extract its set of timing targets and timeline constraints from the XPlan 125. For example, the second tier component 42 may extract (process block 174 of fig. 7) a set of timing targets and timeline constraints from the first tier actions. Thus, the second-level component 42 may restart planning, but is now at the second-level component level, focusing on solving the objective (e.g., objectives 112, 116) that is the responsibility of the second-level component 42.

There may be more constraints in the execution mode than in the estimation mode because each second-level component 42 may access more accurate sensor information 86 received from the data acquisition system 54 (as compared to the predicted state information received during the estimation mode), may receive start and end limits from the estimation mode (218 and 220), and/or may be invoked to satisfy more constraints than are possible in the abstraction level. In execution mode, constraints on the first-level actions (e.g., XPlan 125 of FIG. 4) may be consistent with those constraints imposed by the original plan 74 sent by the same second-level components 42 in estimation mode (e.g., final detailed estimate 252 of FIG. 9).

Alternatively, when the scheduler 96 schedules a first tier of actions 97 (which may be identified by the corresponding software module of the actions), if the actions 97 are not abstract actions corresponding to the activity corresponding to the second tier component 42, then the actions 97 will be scheduled directly to the control system gateway 84 (see, e.g., blocks 314-328 of FIG. 13 discussed below).

The current initial state of planning system 10 may be supplied by inference system 52 to second-level component 42 based on sensor information 86 received from data acquisition system 54, and thus may be more accurate than the predicted state used in the estimation mode. For example, the second tier component 42 may receive (process block 176 of fig. 7) the current state 90, 108. The second tier component 42 may attempt to construct the plan 74 using inferred initial states predicted during the estimation mode. For example, the second hierarchical component 42 may attempt (process block 178 of fig. 7) to generate a second hierarchical plan based on the set of timing targets and timeline constraints and the current state at the second hierarchical component 42. If successful, the second tier component 42 may send the corresponding XPlan 125 to its respective scheduler 96 for execution.

For example, the second tier component 42 may determine (decision block 180 of fig. 7) whether a second tier plan was generated. If so, the second tier component 42 may perform (process block 182 of FIG. 7) a second tier plan. If a plan cannot be constructed from the current state that satisfies these constraints, the second tier component 42 can pass an indication 120 of the unsatisfied target back to the first tier component 40 for reporting and, if possible, pass a set of unsatisfiable constraints that explain the unsatisfied target. For example, if the second hierarchical component 42 determines that the second hierarchical plan is not generated, the second hierarchical component 42 may send (process block 184) an indication to the first hierarchical component 40 that the goal is not reached. In some embodiments, the second hierarchical component 42 may send an indication to the first hierarchical component 40 that the second hierarchical plan cannot be generated. The first-level component 40 may then attempt to modify the first-level plan or generate a new first-level plan by, for example, changing the targets 112, 116, constraints, or any other suitable parameters.

The XPlan 125 (see fig. 4 and 5) may include annotations for use by the scheduler 96 to ensure that execution of the XPlan 125 may occur concurrently and asynchronously with scheduling of the first-level plan and/or other second-level plans. Thus, each scheduler 96 (e.g., of first tier component 40 and each second tier component 42) may schedule its own XPlan 125 (to its respective execution and monitoring component 80), use annotations in the respective XPlan 125 to constrain the timing of activities (to produce correct interleaving of execution across planning system 10) and/or establish monitors to ensure that local and global constraints are not violated.

As in the estimation mode, in the execution mode, constraints may be passed between the first tier component 40 and the second tier component 42 through the constraint interface 50 (see, e.g., fig. 2, 4-5, 11). Constraint interface 50 may support the transfer of timing targets and timeline constraints in a downward direction (e.g., from first hierarchical component 40 to second hierarchical component 42) (e.g., at 280 in fig. 11), and the transfer of planning or feasibility certification in an upward direction (e.g., from second hierarchical component 42 to first hierarchical component 40) (e.g., at 125 in fig. 4-5, at 282 in fig. 11).

The timeline constraint may express requirements that the second-level component 42 is to satisfy over the entire timeline of the first-level plan. The timing targets may include all targets to be achieved by the second tier component 42 across the timeline. If the timing objective is not viable, then indications and interpretations of the missed objective may be passed up through constraint interface 50. Each constraint may be expressed in a modal metric temporal logic language.

When an attempt to achieve a goal 112, 116 times out or inference system 52 reports violation of a monitored constraint, an undershoot may occur during execution mode. In these cases, the inference system 52 may receive and interpret the sensor data or signals 86 and determine the new (e.g., current) state 90, 108. In particular, sensor data or signals 86 may be received from one or more actuator control units 18, 20 (e.g., drilling control unit 18, mud control unit 20) and/or any additional equipment 99. Re-planning may then be initiated based on the new states 90, 108 determined via the sensor data or signals 86, first at the level of the second level component 42 responsible for the undershoot (e.g., the level that did not reach the objective), and then at the level of the first level component 40 if the second level component 42 cannot find the plan 74 (e.g., for re-planning).

The execution mode may include two hypotheses between the first tier component 40/second tier component 42 and the inference system 52. First, the undershoot may be triggered by detecting an invariant of violations specified in the XPlan 125 (e.g., by the corresponding execution and monitoring component 80), and identified and marked by the inference system 52 to the appropriate first tier component 40 or second tier component 42 (execution mode hypothesis 1). The violation may be detected as a failure cause (faildedby) condition (e.g., see at 598 of fig. 22, at 508 of fig. 23). Second, if a re-plan is triggered during the execution mode, inference system 52 may receive sensor information 86 from data acquisition system 54 and interpret one or more new initial states (e.g., at 90 of FIG. 3) for transmission to first tier component 40 and second tier component 42. First tier component 40 and second tier component 42 may then generate an action 97 for moving planning system 10 out of new plan 74 that did not reach the target state (performing mode hypothesis 2).

Referring to fig. 3 and 4, during execution of XPlan 125, the beginning and ending of actions 97 may be scheduled via scheduler 96 when they are authorized (e.g., by an authorization cause (r) condition, see at 496 of fig. 22, 560 of fig. 23), subject to an unrealized target condition monitor (e.g., housed in execution and monitoring component 80, see fig. 3) that may monitor and/or instruct 120 when actions and/or targets (e.g., fig. 9) of plan 252 are not executed and/or reached. The monitor may be set by the execution and monitoring component 80 and then activated subject to a confirmation (ConfirmedBy)/authorization cause indicator (e.g., at 496 of fig. 22 for the beginning of an action and at 560 and 562 of fig. 23 for the end of an action) indicating when the action 97 of the scheduled plan 94 is confirmed/authorized.

With continued reference to fig. 3-4, and as further discussed below with respect to fig. 13 (e.g., decision block 314 and process block 316), certain first tier actions 97, which may be embodied or directly performed "as is" by the control system gateway 84, may be unpacked and sent as second tier actions or commands 82 for execution by the control system gateway 84. When the action 97 is of a first hierarchy and has not been materialized, the action 97 may be sent to the corresponding second hierarchy component 42, completed with the associated XPlan 125, 252 (fig. 4-5, 9), so that the relevant timing targets and timeline constraints may be extracted at the second hierarchy component 42. The XPlan 125, 252 of the first tier component 40 (e.g., the first tier XPlan) may include an activity plan that achieves the first tier goals such that it includes information for extracting spacers, timing goals, and time windows in the planned timeline.

Referring to fig. 2 and 4, after planning in the estimation mode, the first-tier planning for execution in the execution mode (e.g., final detailed estimation 252 (fig. 9) of the first-tier components 40, 232) may be refinement of the framework planning (e.g., rough estimation 200 (fig. 9) of the first-tier components 40, 232), with the first-tier actions adhering to the constraints of each second-tier component 42, having the appropriate duration, and being in an approval position on the timeline.

In execution mode, referring to fig. 3-5 and 9, a plan 252/XPlan 125 has been constructed, each second tier component 42 may submit its XPlan 125 schedule through its own scheduler 96. The scheduling may occur in parallel with the first tier component 40 and the other second tier components 42 scheduling their own actions 97. Synchronization of scheduling may be achieved transparently via grant and validation of conditions. This may support asynchronous scheduling of actions by different second tier components 42. The planning may then be performed by the control system gateway 84 and/or by an execution system (e.g., the processor 24, one or more actuator control units 18, 20, additional equipment 99, etc.).

b. Miss-target and re-plan

As described above, in an embodiment, multi-domain planning may be performed in an estimation mode, and execution and monitoring of multi-domain planning may be performed in an execution mode. These estimation and execution modes may be interleaved via re-planning in the estimation mode, as described below.

During planned scheduling and execution, the goal may not be reached or achieved (see, e.g., indication 120 of not reaching the goal in fig. 3). The undershoot may be detected (e.g., as a failure cause condition, see at 498 of fig. 22, at 508 of fig. 23) as an action timeout, violation of a constant condition (e.g., an undershoot target condition) during an interval in which conditions are monitored via execution and monitoring component 80, etc. The XPlan annotation may ensure that any planning that is being performed is suspended once a miss of the target is detected. The first tier component 40 or the second tier component 42, which is then scheduled via the scheduler 96 for an action 97 that results in an unreachable target (e.g., the target that is found to be unreachable and returned by the execution and monitoring component 80), may be re-planned in the estimation mode. However, the execution system (e.g., the control system gateway 84, the processor 24, the one or more actuator control units 18, 20, the additional equipment 99, etc.) may first cease executing the current plan.

Referring to fig. 3, when a second-level action 97 is scheduled, the execution and monitoring component 80 of the corresponding second-level component 42 in which the target is not reached may send the unreachable target packet to the first-level component 40 along with the unpacked action. An unreachable target package may specify what the first tier component 40 should do if a secure state cannot be achieved, which the planning system 10 may maintain while the re-planning occurs. During a rescheduling activity within the first hierarchical component 40 or the second hierarchical component 42, all other actions within the first hierarchical component 40 and the second hierarchical component 42 may wait for authorization and/or validation before they can be scheduled.

For example, referring to FIG. 4, in execution mode, when a target condition (e.g., failure cause condition) becomes true, the second tier component 42 may schedule its planning. Thus, upon returning to the estimation mode, the second tier component 42 may attempt to reschedule from the state provided by the inference system 52 (e.g., the current state 90, 108). Each second hierarchical component 42 may be locally re-planned as long as the planning decisions do not affect the first hierarchical component 40 or are "invisible" to the first hierarchical component 40 (so that the corresponding second hierarchical plan may be adjusted without the first hierarchical component 40 having to adjust the first hierarchical plan). When the second hierarchical components 42 are being rescheduled, actions of other second hierarchical components 42 (or first hierarchical components 40) may not be scheduled depending on the authorization or validation of the conditions implemented by the second hierarchical components 42 (discussed further below with reference to fig. 22-25). Once the second hierarchical component 42 cannot complete the re-planning without changing what affects the first hierarchical component 40 or is "visible" to the first hierarchical component 40 (such that adjusting the corresponding second hierarchical plan results in the first hierarchical component 40 having to adjust the first hierarchical plan), the re-planning may be sent to the first hierarchical component 40. If the first level components 40 are rescheduled, the overlay stack method can be recalled and each of the second level components 42 can be rescheduled.

In some embodiments, the rearrangement may be used as part of the re-planning to shift or move the actions along the timeline (e.g., embodied in XPlan 252 (FIG. 9)) to improve the efficiency of the planning without violating constraints. Similar to rescheduling, the second tier component 42 may be rescheduled (or retimed) to repair local timing differences that are not visible to the first tier component 40. If the rearrangement affects the timeline constraint sent by the first tier component 40 to the second tier component 42, those changes are visible to the first tier component 40 and the rearrangement is performed at the first tier component 40 level. If the first hierarchical component 40 is rearranged in execution mode, each second hierarchical component 42 may be rearranged to ensure consistency with the new timeline generated by the first hierarchical component 40.

The present disclosure illustrates communications (e.g., via spacers and timeline targets) occurring in a vertical direction (e.g., between a first tier component 40 and its second tier component 42) and in a horizontal direction (e.g., between or among components within the same tier 40 and/or 42). However, such communication may occur in either direction and need not be limited to one or the other or both directions.

Because of the ability of the systems and methods of the present disclosure to asynchronously schedule planning, planning may be being scheduled and performed by the second tier component 42 when the first tier component 40 schedules a first tier action to the second tier component 42. In the event that the activities of the second tier component 42 may be spread or exploded across the timeline embodied in the XPlan 252 (such that not all of the second tier component activities may fit within the bounds marked by the first tier actions, as discussed above with reference to fig. 9), the first tier actions may have been partially performed by the second tier component 42. For example, when the second-level component 42 has scheduled a (partial) action corresponding to an early stage of a higher-level action via the scheduler 96, the first-level component 40 may schedule a start of the higher-level action to the second-level component 42. In this case, the second-level component 42 may: (a) Determining whether the executing plan can still achieve its timing goals based on constraints of the newly scheduled plan; and (b) if not, determining whether the executing plan can be adjusted by rearrangement to satisfy the new constraint. If the second hierarchical component 42 determines that either of these scenarios is not possible, the second hierarchical component 42 may locally reprogram. That is, the second hierarchical component 42 may be re-planned by taking into account actions that have been ongoing to affect the re-planning effort of the second hierarchical component 42. The second level component 42 can interpret the states based on the expected effects of the portions of the programming performed so far to expect actions that have been performed, record those actions in the initial state, and/or re-program to achieve new timing goals.

Fig. 13 is a flowchart of an overlay stack method 310 performed by the first tier component 40 in an execution mode in accordance with an embodiment of the present disclosure. The method 310 may be performed by any suitable device or combination of devices that may receive a first level plan (e.g., 252 in fig. 9), determine whether an action of the first level plan is abstract or concrete (i.e., capable of being performed directly by the control system gateway 84), extract timing targets and timeline constraints from the plan, generate a second level plan (e.g., see one or more plans 74, 94 of fig. 3 and 5), or retime an existing second level plan. Although method 310 is described using steps in a particular sequence, it should be understood that the present disclosure contemplates that the described steps may be performed in a different sequence than the illustrated sequence and that some of the described steps may be skipped or performed altogether. In some implementations, at least some steps of the method 310 may be implemented by the second hierarchical component 42, the second hierarchical component 42 acting as the first hierarchical component 40 at the root of its respective local hierarchy in the multi-level application. The two-level relationship may be replicated in multiple levels of the hierarchy. In alternative or additional embodiments, at least some of the steps of method 310 may be implemented by any other suitable processor or control logic (e.g., first tier component 40, processor 24, one or more control units 18 and/or 20, additional equipment 99, etc.).

Referring also to fig. 13, the first tier scheduler 96 (e.g., see fig. 3) may receive (process block 312 of fig. 13) a first tier plan (e.g., XPlan 125 or 252) that includes an action 97 (e.g., see fig. 3). The first tier component 40 may then determine (decision block 314) whether the scheduler 96 should schedule the action 97 directly to the control system gateway 84 for execution via the execution and monitoring component 80. That is, the first tier component 40 can determine whether an action is materialized. If so, the first tier component 40 may send (process block 316 of FIG. 13) the action 97 to the control system gateway 84 to be performed.

If the first tier component 40 determines that the action 97 may not be directly scheduled to the control system gateway 84 for execution, the first tier component 40 may send (process block 318 of fig. 13) the action 97 to the second tier component 42 associated with the action. For example, the first tier component 40 may send the action 97 to the second tier component 42. The second tier component 42 may then extract (process block 320 of fig. 13) the timing targets and timeline constraints from the action (similar to at 280 of fig. 11, but in execution mode). The second tier component 42 may also receive (process block 322 of fig. 13) current state information from the inference system 52.

The second tier component 42 may then determine (decision block 324 of fig. 13) whether a second tier plan may be generated based on the timing targets, the timeline constraints, and the current state information (e.g., see one or more plans 74, 94 of fig. 3 and 5). If so, the second tier component 42 may generate (process block 326 of FIG. 13) a second tier plan (e.g., see one or more plans 74, 94 of FIGS. 3 and 5) and schedule the plan for execution. If the second tier component 42 determines that the second tier plan cannot be generated and an indication sent (process block 184 of FIG. 7), the first tier component 40 may retime or reprogram (process block 328 of FIG. 13) the first tier plan 252.

Fig. 12 is a flow chart of activities in an execution mode that result in a return to an estimation mode for re-planning in accordance with an embodiment of the present disclosure. The method 290 may be performed by any suitable device or combination of devices that may generate a first hierarchical plan (in an estimation mode), send the first hierarchical plan to the second hierarchical component 42, receive the second hierarchical plan from the second hierarchical component 42, and either overlay the second hierarchical plan on the first hierarchical plan and continue to control the device (in an execution mode), or receive current state information (in an execution mode) from sensors coupled to the device 14, change constraints and/or goals of the first hierarchical plan based at least in part on the current state information, and return to the estimation mode for re-planning. Although the method 290 is described using steps in a particular sequence, it should be understood that the present disclosure contemplates that the described steps may be performed in a different sequence than the illustrated sequence and that some of the described steps may be skipped or performed altogether. In embodiments, at least some steps of method 290 may be implemented by first tier component 40 and/or any other suitable processor or control logic (e.g., one or more second tier components 42, processor 24, one or more actuator control units 18, 20 of equipment 14, and/or additional equipment 99).

The planning steps (process blocks 292, 294, 296, decision block 298, process block 304, and decision block 306) of the estimation mode 303 are the same as or similar to the steps previously described in more detail with respect to the estimation mode. In particular, the first-tier component 40 may generate (process block 292 of fig. 12) a first-tier coarse estimation plan having constraints and targets. For each second-level component 42 that may perform the actions of the first-level plan, the first-level component 40 may send (process block 294 of fig. 12) the first-level plan to the corresponding second-level component 42. The first hierarchical component 40 may then receive (process block 296 of fig. 12) the second hierarchical plan, or receive an indication that the second hierarchical plan cannot be generated from the corresponding second hierarchical component 42 (e.g., if constraints and target limits of the first hierarchical plan are too many).

Still in the estimation mode 303, the first tier component 40 may determine (decision block 298 of fig. 12) whether a second tier plan is received. If so, the first tier component 40 may overlay (process block 304 of FIG. 12) the second tier plan on the first tier plan to generate the overlay stack 242 as described in detail above with respect to the overlay stack method (see FIG. 8-9). The first hierarchical component 40 may then determine (decision block 306 of fig. 12) whether the second hierarchical component 42 has not yet sent the second hierarchical plan to the first hierarchical component 40. If so, i.e., the overlay stack 242 is incomplete, the first tier component 40 may return to process block 294 of the process estimation mode 303 and send the overlay stack 242 to the second tier component 42 that does not provide a layer to provide a new layer to the overlay stack 242. If not, i.e., the overlay stack 242 is a complete overlay stack or plan 252, the first tier component 40 may proceed to the execution mode 301 to indicate (process block 308 of FIG. 12) that each second tier component 42 controls the equipment 14 based on the plan 252, as described in detail above with respect to the execution mode. For example, the first tier component 40 may instruct the various second tier components 42 (e.g., representing different subcontractor types and/or tiers) to send respective actions and/or commands 97, 82 to be performed by the respective equipment 14 (e.g., by one or more equipment elements or control units 18, 20) to the plan execution system 56 and/or the control system gateway 84 to perform operations (e.g., turn on, turn off, operate at a particular speed, operate at a particular power, otherwise control and/or operate, etc.) based on the associated activities and times indicated in the complete coverage plan 252.

On the other hand, if in the estimation mode 303, an indication that the second level plan cannot be generated is received (process block 296 of fig. 12), and thus the second level plan is not received (decision block 298 of fig. 12), and thus proceed to the execution mode 301, the first level component 40 may receive (process block 300 of fig. 12) current state information from a sensor coupled to the equipment 14. In particular, sensor information 86 (e.g., acquired at a current time) may be received at the data acquisition system 54 from the equipment 14 (e.g., from one or more equipment elements and/or control units 18, 20 (etc.) of the equipment 14). The current state information may be received directly from the sensor information 86 and/or may be received indirectly from the sensor information 86 via processing, inference system 52, etc.

Upon receiving the current state information, the first tier component 40 may then change (process block 302 of fig. 12) constraints and/or goals of the first tier plan based at least in part on the current state information received, for example, from the inference system 52. For example, the first hierarchical component 40 may be ready to refine the first hierarchical plan or generate a new first hierarchical plan by changing constraints and/or goals of the first hierarchical plan based on changes between current state information obtained from sensors in the execution mode 301 and predicted or expected state information generated in the earlier estimation mode 303, because the current state information from the execution mode 301 reduces variables and/or likelihood of the current state compared to when the current state is predicted in the earlier estimation mode. In view of the changed constraints and/or goals of the first-level plan (block 302), the re-planning method 290 may then return 299 the planning system 10 from the execution mode 301 to the estimation mode 303, wherein the first-level component 40 may refine the previous first-level plan and/or generate a new first-level plan (block 292) and proceed accordingly.

Examples of second tier component planning

Fig. 14 shows a human-readable text representation 285 of XPlan 125 in accordance with an embodiment of the disclosure. Although XPlan 125 is in a machine-readable and machine-executable format (e.g., FIGS. 20-23 below), human-readable representation 285 is a simplified format that may lack the machine-readable and details necessary for machine execution. The example human-readable text representation 285 of fig. 14 is generated by the second-level component 42 for application in drilling a wellbore for a single-drill string in well construction. Text representation 285 is generated by an automated platform that performs staged drilling by automating driller's tasks. As shown, each line of text representation 285 may specify a planned start time 197, a name and parameters of planned action 97, and a calculated duration 297 (in minutes) of the planned action. Some actions have been planned to be performed concurrently. For example, the sending of the downhole steering request 283 and the drilling to the next connection point 284 are planned to be performed in parallel at the planned time of about 196 minutes. The shut down of pump 286 and access slips 288 are also planned to be performed concurrently at the planned time of approximately 243 minutes.

Generating the example text representation 285 involves an evaluation of only a small portion of the possible search space of the particular second-level component 42 planning drilling activity. Specifically, as shown in the example state branch diagram 340 of fig. 15, eighty-seven states are accessed when generating text representation 285, according to an embodiment of the present disclosure. In the example, the domain model defines approximately fifty propositional variables and four metric variables (including continuously varying variables representing wellbore depth). This means having about 10 ¹⁵ The state space of the states ignores the metric dimension, but only a small subset of the states are reachable. The domain model of this example second-level component 42 only considers drilling activity, and not the fluid management necessary to support drilling. Fluid management is the responsibility of another second-level component 42, which second-level component 42 must generate a plan that is coordinated with the drilling plan. The coordination is managed by a first hierarchical component 40, which first hierarchical component 40 determines the constraints that each second hierarchical component must satisfy in order to achieve the coordination. For example, in fig. 14, between the beginning of the action "resume circulation" 287 and the end of the action "shut-in pump" 286, the mud circulation system must provide fluid that the pump will circulate in the wellbore, which involves a different second level component 42 to plan for the necessary fluid preparation, rather than the second level component 42 to plan for the well bore represented in the text representation 285.

Logic inference

Embodiments of the present disclosure may include a recursive structure of inference rules, thereby enabling the conversion of sensed data into high-level predicates, for both the start and end of an authorization action, and for detecting violations of invariants, and thus enabling coordination of different domains in a multi-domain architecture. The recursive structured rules of the present disclosure may drive inferences at different levels and/or across different domains of the same level within a multi-domain architecture.

For example, the recursive structure of inference rules may enable the conversion of sensed data into high-level predicates, e.g., to authorize the beginning and ending of actions, and detect invariant violations, thereby enabling coordination at different levels and/or across different domains of the same level within a multi-domain architecture. In some embodiments, the processor receives a condition configured to: authorizing an action of the system with equipment; in response to determining that the rule is associated with the condition, identifying the rule as a potential support for the condition; inferring that an implication term of the rule is true when a precondition of the rule is determined to be true; in response to determining that the precondition is true, activating a rule, wherein validity of the condition is based on activation of the rule; and instructing the equipment to perform an action based on the validity of the condition.

Fig. 16 is a block diagram of example internal components of inference system 52 of planning system 10 of fig. 2, for example, in accordance with an embodiment of the present disclosure. Fig. 16 shows the architecture of the inference system 52, and how information is conveyed, relayed, and used in the inference system 52. Multiple domains in the architecture are connected by a set of inference rules 376, which inference rules 376 show how a proposition in one domain is inferred to be "true" as a result of the implementation of a proposition in another domain. These rules 376 may also be used to infer violations of invariants. In an embodiment, the set of inference rules 376 provide a means of transforming knowledge between domains. For a non-limiting example, inference rules 376 can be stepped up through the abstraction layer from a proposition that can be directly sensed to the most abstract proposition in a multi-domain application. The set of inference rules 376 are written as part of the multi-domain application of the present disclosure and are used in both the estimation mode (e.g., for generating timing targets and timeline constraints 280) and the execution mode (e.g., for generating timing targets and timeline constraints 280 and for interpreting data 360 (e.g., sensor data)).

Rules 376 may include a body (premise) and a header (implication). In particular, when the prerequisite in the preamble is true, then the implication item is inferred to be true. For non-limiting examples, the preconditions of the rules 376 may include preconditions such as whether the rig is operating, and whether the rig has been operating for more than a threshold period of time after the last injection of mud. The implication of rule 376 may include whether mud should be injected. If the precondition in the precondition is true, i.e. the drilling machine is operating and has been operating for more than a threshold period of time after the last injection of mud, then the implication term is inferred to be true, i.e. mud should be injected.

As discussed above (e.g., see fig. 3), the inference system 52 can receive signals or data 86, 360 (e.g., which can include sensor information) from the data acquisition system 54 (e.g., which can include sensors) and interpret the associated states 90, 108 for transmission to the first tier component 40 and the second tier component 42 via use of the logic inference rules 376. When actions are performed by planning system 10, knowledge of sensor data 86, 360 may be maintained as a consistent set of facts available to all schedulers 96 of first tier component 40 and second tier component 42.

As shown in FIG. 16, inference system 52 may include a literal (literal) state store 350, a query responder 352, a rule evaluator 354, a condition scheduler 356, and a state estimator 348. Literal state store 350 may store facts or literals (literal states) 370 interpreted by system state estimator 348 using data 360 acquired via data acquisition system 54 and/or by application of rules 376 using rule estimator 354.

In example operations, the condition scheduler 356 may receive a query from a scheduling process (e.g., see scheduler 96 and/or execution and monitoring component 80 of fig. 3) that is required to authorize, confirm, or fail a condition during execution of act 97. Sensed data 360 may be necessary to answer these queries, where the data may be sensed via one or more physical sensors of one or more various parameters and/or in a purely virtual manner (e.g., read from a database, obtained via human-machine interaction, etc.). The connection from the data 360 to the conditional dispatcher 356 may be made through chains 362, 371, 379 (e.g., using intermediaries such as state estimator 348, literal state store 350, query responder 352 as shown), or more directly or indirectly in other variations. In some embodiments, data acquisition system 54 may send data 360 to literal status store 350 periodically (e.g., at some time interval) or asynchronously (e.g., when data acquisition system 54 receives new sensor data 86, 360) (e.g., via status estimator 348 and communication channel, connection, or link 362). In addition, literal state store 350 may send request 363 for updated sensor data 360 to data acquisition system 54 (e.g., via state estimator 348 and communication channel, connection, or link 361), and data acquisition system 54 may then send 362 the requested sensor data 360 to literal state store 350 in response to the request (e.g., via state estimator 348 and channel 362). The system state 365 contained in the system state estimator 348 is the current estimated state of the system that is available to respond 362 to the request 363 from literal state store 350.

The information recording the persistence of literal 370 may be stored in literal state storage area 350, for example, within one or more literal state duration records 373. Data communicated along the communication channel (e.g., 366, 368) may be the result of consulting the contents of literal state store 350, including literal state 370 and/or duration 373 where literal state 370 is true.

As a non-limiting example in the well construction context, if the Bottom Hole Assembly (BHA) of the drill string cannot continue to be removed downhole of the well being drilled unless the mud flow has been measured at an appropriate flow rate for at least 10 seconds, it can be confirmed that the file (mud flow > required rate) must be true in the status storage area 350 and its duration 373 must have reached 10 seconds or more. Such a combination would allow for confirmation of the condition of the query responder 352.

In example operations of an embodiment, when a query 368 reaches the conditional scheduler 356, the query 368 is communicated to the query responder 352 via the communication link 364. Query responder 352 checks 372 text state storage area 350 to see if queries 368, 364 have been established and remain true. In some embodiments, the request may involve rule evaluator 354 evaluating one or more potential rules 376. For example, if the query 368 is abstract, the query responder 352 may request 374 the rule evaluator 354 to find rules 376 that suggest the query 368, 364 (hereinafter "368"). Such rules 376 are potential rules. For example, when query 368 is an implication term, rule 376 may be potential. When the premise of the potential rule 376 is true, the potential rule 376 may become active; on the other hand, if the precondition is false or unknown, the query 368 remains or reverts to potential. When a rule 376 is potential, the case where the query 368 is abstract (matches the head or implication of the rule) may result in the generation of a precondition query 378 from the rule evaluator 354 to the query responder 352. The premise queries 378 (e.g., preconditions or preconditions of rules in the body) may have a recursive hierarchy that is the same or similar to the relationships between the levels of the multi-domain architecture itself, but does not need to be directly linked in any way.

A precondition query 378 may be sent 372 from query responder 352 to literal state store 350. One or more literal states 370 may be found to be true in literal state store 350 and if so remain true for a desired duration 373. State estimator 348 may place literal 370 into literal state store 350 and notify query responder 352 that implication item query 368 is true when all required premise queries 378, 372 are in literal state store 350. Then, the potential rule 376 becomes active. However, once any precondition query 378 in the activity rules 376 is determined to be false by the state estimator 348, the rules 376 cease activity and become potential again. If there are no activity rules 376 supporting the implication item query 368, the query responder 352 may be notified that there is insufficient evidence to determine that the implication item query 368 is true.

To monitor the preconditioned state of rules 376, rule evaluator 354 may notify text state storage 350 of the text 377 that must be monitored, and text state storage 350 may then notify rule evaluator 354 of the state changes of these monitored text.

With continued reference to FIG. 16, and in more detail, in an embodiment, the implication term query 368 sent to the conditional dispatcher 356 is passed to the query responder 352 as a query 364. Query 364 may facilitate determining whether query 368 is currently present or true. To determine response 379 to query 364, query responder 352 may send a request 372 to literal state store 350 to see if the condition is true, false, or unknown. Query 364 may be primitive (may be sensed directly) or abstract (rule implication term). Where query 364 is a primitive, literal state store 350 may send request 363 to state estimator 348. Upon receiving the response 362, the literal status store 350 may send a corresponding response 371 to the query responder 352. In the case where query 364 is an implication term of rule 376, query responder 352 may also send a request 374 to rule evaluator 354 to evaluate one or more rules 376 in which query 364 is an implication term. For example, rule 376 may be evaluated to determine if query 364 is true.

Query responder 352 may then send a response 379 to conditional dispatcher 356 indicating whether query 364 is true. Based on the response 379, the condition dispatcher 356 may determine whether the query 368 is currently in the literal status store 350 and/or send a response 366 to a status and target generator (e.g., see at the motive element 98 of fig. 3) to generate the status 90, 108 and/or target 112, 116 based on the response 366. The response 366 may also be sent to the executive and monitoring component 80 and/or the concierge component 88.

As the response 378 changes, the query responder 352 may update the response 378 to the query 364. For example, if the response 378 to the query 364 is false or unknown and changes to true, the query responder 352 may update the response 378 with respect to such changes (e.g., by updating the response 378 to "true"). Similarly, if the response 378 to the query 364 is true and changes to false or unknown, the query responder 352 may update the response 378 for such changes (e.g., by updating the response 378 to "unknown"). The change in response 378 may occur due to, for example, a change in sensor data 360, rules 376, and the like.

The states 90, 108 and/or targets 112, 116 may be sent to any suitable component, such as the first tier component 40, the second tier component 42, etc. Although the flow of information in inference system 52 is disclosed in the form of requests (e.g., 374) and/or queries (e.g., 368), it should be understood that any suitable communication may be used, such as messages, registrations, notifications, value settings, etc.

As described above, rules 376 may be evaluated to determine if query 364 is true. To evaluate the rule 376, the rule 376 may be activated first. Fig. 17 is a flowchart of a method 390 for determining which rules 376 to activate with respect to query 364, according to an embodiment of the present disclosure. Method 390 may be performed by any suitable device or combination of devices that may determine whether a header (implication term) of rule 376 is associated with query 364, determine whether a body (premise) of rule 376 is true, and activate rule 376. As described above, rules 376 may include a body and a header (premise and implication terms, respectively). In particular, when a prerequisite in the subject/premise is true, then the broken head/implication item is true.

Although the method 390 is described using steps in a particular sequence, it should be understood that the present disclosure contemplates that the described steps may be performed in a different sequence than the illustrated sequence and that some of the described steps may be skipped or performed altogether. In some embodiments, at least some of the steps of method 390 may be implemented by rule evaluator 354. In alternative or additional embodiments, at least some of the steps of method 390 may be implemented by any other suitable component or control logic, such as query responder 352, conditional scheduler 356, or any other component of inference system 52.

Referring now to fig. 16 and 17, the rule evaluator 354 may receive (process block 392 of fig. 17) the query 374. The condition dispatcher 356 may send the query 368 as a query 364 to the query responder 352 in order to determine whether the condition or fact 368 is currently present or true, and the query responder 352 may send the query 364 as a query 374 to the rule evaluator 354 as shown, or more directly or indirectly in other variations.

As described above, rule evaluator 354 may store one or more rules 376 for determining whether query 364 is true. For each rule 376 stored in rule evaluator 354, rule evaluator 354 may determine (decision block 394 of fig. 17) whether the header/implication item of the corresponding rule 376 is associated with query 364. As described above, when a prerequisite in the body/premise of rule 376 is true, then the head/implication item of rule 376 is inferred to be true. In particular, rule evaluator 354 may determine whether each stored rule 376 includes query 364 in its respective header/implication term. If the head/implication item of the corresponding rule 376 is not associated with query 364, rule evaluator 354 may return to decision block 394 to evaluate the next rule 376 stored in rule evaluator 354.

If the head/implication item of the corresponding rule 376 is associated with query 364, rule evaluator 354 may identify the corresponding rule 376 as a potential support for query 364 (process block 396 of FIG. 17). Thus, a potential support is rule 376 with the header/implication item associated with query 364, and thus query 364 may be supported. Depending on whether the body/premise of the rule is true, the potential supporters may be active rules 376 or inactive rules 376. When the potential support is an active rule 376, it supports a query 364. When a potential supportor is inactive rule 376, it does not support query 364. For example, query 364 may include determining whether the temperature in the wellbore exceeds 100 degrees Fahrenheit. Potential supporters of query 364 may include any rule 376 with a header/implication term associated with a temperature. The activity rules 376 may include those having head/implication items associated with temperatures above 100 degrees Fahrenheit, while the inactivity rules 376 may include those having head/implication items associated with temperatures below 100 degrees Fahrenheit.

Rule evaluator 354 may identify corresponding rule 376 as a potential support for query 364 by any suitable technique (e.g., by storing corresponding rule 376 in a pool of potential supports, marking corresponding rule 376 as a potential support, etc.). In some embodiments, potential supporters may be instantiated in a pool of potential supporters.

The rule evaluator 354 may then determine (decision block 398 of fig. 17) whether the body/premise of the corresponding rule 376 is true. As described above, when a prerequisite in the body/premise of rule 376 is true, then the head/implication item of rule 376 is inferred to be true. In some embodiments, the stored sensor data 372 sent to the rule evaluator 354 may be used to determine whether the body/premise of the corresponding rule 376 is true.

If rule evaluator 354 determines that the subject/premise of the corresponding rule 376 is not true, rule evaluator 354 may return to decision block 394 to evaluate the next rule 376 stored in rule evaluator 354. Accordingly, the corresponding rule 376 is identified as a potential supportor, but the corresponding rule 376 is inactive and therefore does not support the query 364.

If rule evaluator 354 determines that the body of the corresponding rule 376 is true, the head/implication term of rule 376 is inferred to be true, and rule evaluator 354 may activate (process block 400 of FIG. 17) the corresponding rule 376. Accordingly, corresponding rule 376 supports query 364. In this way, rule evaluator 354 may determine which rules 376 to activate with respect to query 364. The activity rules 376 may then be evaluated to determine if the query 364 is true, which may facilitate determining if the condition or fact 366 is currently present or true. The conditions 366 may be sent to a state and goal generator (e.g., motive element 98 of fig. 3) to generate a state or goal for planning system 10.

As described above, query responder 352 may update response 378 to query 364 as response 378 changes. Response 378 may be updated when rules 376 no longer support query 364, or when at least one rule 376 supports query 364 without one previously supporting query 364 (e.g., when sensor data 86, 360 is updated and/or rules 376 are changed). Because rule 376 supports query 364 when rule 376 is activated, and rule 376 is activated when the body/premise of rule 376 is true, updates in response 378 to query 364 may depend on changes in the body/premise of rule 376. These changes in the body/premise of the rule 376 may be based on updated sensor data 360, changes in the rule 376, and the like.

In this regard, fig. 18 is a flow chart of a method 410 for activating and/or deactivating rules 376 based on updated information (such as sensor data 86, 360) in accordance with an embodiment of the present disclosure. The method 410 may be performed by any suitable device or combination of devices that may determine whether the rule 376 is identified as a potential support, determine whether the rule 376 is active, determine whether the subject/premise of the rule 376 is true, activate the rule, and deactivate the rule 376. Although the method 410 is described using steps in a particular sequence, it should be understood that the present disclosure contemplates that the described steps may be performed in a different sequence than the illustrated sequence and that some of the described steps may be skipped or performed altogether. In some embodiments, at least some of the steps of method 410 may be implemented by rule evaluator 354. In alternative or additional embodiments, at least some of the steps of method 410 may be implemented by any other suitable component or control logic, such as query responder 352, conditional scheduler 356, or any other component of inference system 52. Moreover, although the method 410 is based on updated sensor data 86, 360, any suitable information may be substituted to cause the activation and/or deactivation of the rules 376, as shown in FIG. 18, such as a change to the rules 376.

Referring now to fig. 18 (and with continued reference back to those previously described), rule evaluator 354 can receive (process block 412) sensor data 86, 360 and/or can receive or determine updated status information based thereon. For example, query responders 352 may send sensor data 86, 360 from data acquisition system 54 and/or stored sensor data 86, 360 stored as literal status 370 in literal status store 350 to rule evaluator 354.

For each rule 376 stored in rule evaluator 354, rule evaluator 354 may determine (decision block 414 of fig. 18) whether the corresponding rule 376 is a potential support. For example, rule evaluator 354 may determine whether to identify a respective rule 376 as a potential support by determining whether the respective rule 376 is stored in a pool of potential supports, marked as a potential support, or the like. If rule evaluator 354 determines that the corresponding rule 376 is not a potential support, rule evaluator 354 may return to decision block 394 (FIG. 17) to evaluate the next rule 376 stored in rule evaluator 354. In some implementations, such as a method for activating and/or deactivating rules 376 based on changes to rules 376, rule evaluator 354 can determine whether each respective rule 376 should be (e.g., remain) a potential support.

If rule evaluator 354 determines that corresponding rule 376 is a potential support, rule evaluator 354 can determine (decision block 416 of FIG. 18) whether corresponding rule 376 is active. If so, the corresponding rule 376 supports the associated query 364. Rule evaluator 354 then determines (decision block 418 of fig. 18) whether the sensor data (e.g., 360) results in the body of the corresponding rule 376 being not true. That is, the sensor data 360 may result in the body of the respective rule 376 being false or unknown (e.g., it is not possible to determine whether the body of the respective rule 376 is true or false). If so, the rule evaluator 354 may deactivate (process block 420 of FIG. 18) the corresponding rule 376 and return to decision block 394 (FIG. 17) to evaluate the next rule 376 stored in the rule evaluator 354.

If rule evaluator 354 determines (decision block 418 of fig. 18) that sensor data 360 stored as literal state 370 in literal state store 350 results in the subject/premise of corresponding rule 376 being true, then there is no change because corresponding rule 376 is already active, and rule evaluator 354 may return to decision block 394 (fig. 17) to evaluate the next rule 376 stored in rule evaluator 354.

If rule evaluator 354 determines (decision block 416 of FIG. 18) that corresponding rule 376 is not active, then corresponding rule 376 does not support associated query 364. The rule evaluator 354 may then determine (decision block 422 of fig. 18) whether the sensor data 360 results in the body of the corresponding rule 376 being true. If so, the rule evaluator 354 may activate (process block 424 of FIG. 18) the corresponding rule 376 and return to decision block 394 (FIG. 17) to evaluate the next rule 376 stored in the rule evaluator 354.

If rule evaluator 354 determines (decision block 422 of fig. 18) that sensor data 360 results in the body of corresponding rule 376 not being true, there is no change because corresponding rule 376 is already inactive, and rule evaluator 354 may return to decision block 394 (fig. 17) to evaluate the next rule 376 received by rule evaluator 354. In this manner, rule evaluator 354 can activate and/or deactivate rule 376 based on updated sensor data 360.

In view of method 390 (fig. 17) for determining which rules 376 to activate relative to query 364 and method 410 (fig. 18) for activating and/or deactivating rules 376 based on updated information, fig. 19 is a flow chart of method 440 for determining whether associated query 364 is true in accordance with an embodiment of the present disclosure. Method 440 may be performed by any suitable device or combination of devices that may determine whether activity rules 376 supporting query 364 exist and send an indication that query 364 is true or false or unknown. Although the method 440 is described using steps in a particular sequence, it should be understood that the present disclosure contemplates that the described steps may be performed in a different sequence than the illustrated sequence and that some of the described steps may be skipped or performed together. In some embodiments, at least some of the steps of method 440 may be implemented by rule evaluator 354. In further embodiments, at least some of the steps of the method 440 may be implemented by any other suitable component or control logic, such as the query responder 352, the conditional scheduler 356, or any other component of the inference system 52.

Referring now to FIG. 19, and with reference to FIG. 16, rule evaluator 354 may determine (decision block 442 of FIG. 19) whether there are active rules 376 that support query 364. In particular, if there is at least one activity rule 376 (e.g., of a potential supportor), then query 364 is supported and therefore true. Thus, if rule evaluator 354 determines that an activity rule 376 is present, rule evaluator 354 may send (process block 444 of fig. 19) an indication (e.g., response 378) to query responder 352 that query 364 is true. In some embodiments, rule evaluator 354 may send an indication to query responder 352 that activity rule 376 exists (e.g., response 378), and query responder 352 may in turn send an indication to conditional scheduler 356 that query 364 is true (e.g., response 379).

If at least one active rule 376 is not present (e.g., all potential supporters are inactive rules 376), then query 364 is not supported and is therefore either false or unknown (e.g., it is not possible to determine whether the body of the corresponding rule 376 is true or false). Thus, if rule evaluator 354 determines that there are no active rules 376, rule evaluator 354 may send (process block 446 of fig. 19) an indication (e.g., response 378) to query responder 352 that query 364 is not true. In some embodiments, rule evaluator 354 may send an indication to query responder 352 that no active rule 376 is present (e.g., response 378), and query responder 352 may in turn send an indication to conditional scheduler 356 that query 364 is not true (e.g., response 379).

Conditional dispatcher 356 may then send currently existing conditions 366 based on whether query 364 is true or not true and the target generator (e.g., motive element 98 of fig. 3). The state and target generator may generate states 90, 108 and/or targets 112, 116 to appropriate components (e.g., first tier component 40, second tier component 42, etc.). Suitable components may generate the plans 74, 94 based on the states 90, 108 and/or the targets 112, 116, and thus control the equipment 14 (e.g., fig. 1) based on the states 90, 108 and/or the targets 112, 116.

Each of the components of inference system 52 (including word state store 350, query responder 352, rule evaluator 354, condition scheduler 356, and state estimator 348) may be a particular specific component that performs a particular specific task for which the component is designed to perform. For example, text status storage area 350 is designed to store sensor data 86, 360 received from data acquisition system 54. By using these specific components rather than a general conventional structure, various benefits may be realized. For example, because such components are specifically designed to perform such specific tasks, hardware elements and/or software functions for performing acts that are unrelated to such specific tasks that may be present in a more general purpose conventional component may be reduced or eliminated from the components. Thus, the components may operate more efficiently, more quickly, and with less power consumption. Moreover, the components may operate with one another in a more efficient and cooperative manner, as the components may be designed to do so rather than being generally programmed to interact with components unrelated to the operation of the inference system 52.

XPlan and scheduling

As described above, the methods and systems of the present disclosure allow for multiple event systems to operate concurrently, each event system performing asynchronous scheduling of the start and end of its own planned actions, and each scheduler coordinating with other schedulers via logical inference. Concurrent coordination of multiple event systems is obtained by applying inference rules, and the planner within each decomposed component of the overlay stack can generate a structure that can schedule plans, with its own execution constraints, and manage the traversal of its local schedulers. Each such schedulable plan may implement, revoke, or rely on conditions that connect to other professionals via inference rules, and the schedulable plan may also manage its coordination with other schedulers under concurrent operation.

As described above, the plans 74, 94, 125, 252 (or ultimately the previous plans 200, 240, 248, 249, 242, etc.) generated by the planning system 10 may be output as an XML document or other machine-readable format, referred to herein as XPlan. XPlan may be created by a planner and may conform to criteria including comments describing the conditions under which action 97 is authorized to be scheduled and constraints that may be observed during execution of action 97. The XPlan may contain additional information about the expected context for execution in order to allow the plan scheduler 96 to identify whether and when to schedule individual actions in the plan to the execution and monitoring component 80, or when to fail the plan. The XPlan format may be a communication medium between the first tier component 40 and the second tier component 42.

The XPlan structure depicted in FIGS. 20-23 (starting from the top-level format or structure 130 in FIG. 20) may include a series of ordered items ("OrderedHapping"), which may include the composition or "sub-actions" of action 97 (e.g., transitions between states). Each ordered item may correspond to an event that is expected to occur as part of execution of the plan. Some of the ordered matters may be performed by, for example, equipment 14. Other ordered events may occur as a result of physical processes or human intervention in the environment and may be observed by sensors of the data acquisition system 54 and then confirmed via the logic inference system 52. Each ordered item may be identified as "action start" (ActionStart) which defines the condition that the action 97 should be initiated (or identified as failed), or as "action end" (ActionEnd) which defines when the action 97 ends (or fails). In one example, the ordered items may detail constraints that indicate when scheduling of act 97 may proceed and constraints that indicate when planning execution should not proceed.

Fig. 20 is a block diagram of an example structural composition of a plan 74 or XPlan structure 130 of the planning system 10 of fig. 2, in accordance with some embodiments of the present disclosure. The plan 74 or XPlan structure 130 may include one or more actions 97, each of which may be described by one or more orderings 460. In an embodiment, each action 97 may be described by at least two ordered items 460 (e.g., one for the action start and one for the action end). Each ordered item 460 may include a possibly unique identifier ("item ID") 462, one or more item IDs 464 of a later ordered item (referred to as "poste") 466 (ordered item 460 occurs before item 466 according to plan 74), one or more item IDs 468 of a previous ordered item (referred to as "poste") 470 (ordered item 460 occurs after item 470 according to plan 74), and an indication 472 of whether ordered item 460 is an action start 474 or an action end 476 (referred to as "item"). The post-order event 466 and the pre-order event 470 may also include times ("absolute times") 478, 480, which may be used to determine the limits of the absolute time that the corresponding event must occur in order to properly execute the plan. Such times may correspond to expected times of expected events (e.g., dusk, dawn, shipment arrival, or other events) that are outside the control of the planner but affect the execution of the plan.

In order to properly execute the plan, the post-ordering event 466 may not occur before the ordering event 460, but rather should correspond to an event at some point after the event indicated by the ordering event 460. In an embodiment, the success of the later ordered item 466 may depend on the performance of the ordered item 460. For example, the later ordered matter 466 may be related to the injection of mud, while ordered matter 460 may relate to the beginning of the wellbore (open hole). Thus, the post-event sequence 466 for mud injection should follow the sequence 460 of the wellbore opening. However, the post-ordering event 466 may not occur immediately following the ordering event 460, as other ordering events may occur between the two ordering events (e.g., stopping or starting drilling, moving a hose or pipe, etc.).

Using the example above, the order entry 460 for a wellbore opening may have an entry ID 462 of 1, the position to move the mud injection tubing above the wellbore may have an entry ID 462 of 2, and the order entry 466 for the injection mud may have an entry ID 462 of 3. For purposes of this example, it may be assumed that the beginning of the drilling of the wellbore occurs before the injection of mud (and thus the injection of mud occurs after the beginning of the drilling of the wellbore), and that the moving mud injection line occurs before the mud injection (and thus the mud injection occurs after the moving mud injection line). Thus, table 1 may apply:

TABLE 1

By specifying the item ID 462 relative to the corresponding post-order item 466 or pre-order item 470 as described above, the XPlan structure 130 may enable the planning system 10 to identify actions that may be taken into account at any point during the execution of the plan. An action corresponding to an order item 460 that should occur after a particular order item cannot begin (either by observation or by initiation) before the particular order item occurs. Moreover, because the XPlan 125 may be an XML document structured according to the XPlan structure 130, annotations, and in particular open and close annotations, may be used to represent the various elements shown in FIGS. 20-23. Thus, the code segments from XPlan 125 representing table 1 may be (partially) represented as follows:

fig. 21 is a block diagram of an example composition of an indication (item 472) of whether the ordered item 460 of fig. 20 is an action start 474 or an action end 476, according to some embodiments of the present disclosure. Action start 474 is an indication of when action 97 is initiated and action end 476 is an indication of when action 97 ends. The action start 474 may include an identifier ("action ID") 490, a name 492, a set of parameters 494 (e.g., associated with components, devices, and/or objects that may be affected by the action 97), a set of conditions 496 that may authorize the action start 474 (represented by an "authorization cause" indicator), a set of conditions 498 that may limit whether the action start 474 is complete (represented by a "failure cause" indicator), a time ("expected start time") 500 associated with when the action 97 starts, and a time period ("expected duration") 502 between the action 97 start time and the action 97 end time. Action end 476 may include an identifier ("action ID") 504, a validation indication ("validation") 506, and a set of conditions (represented by a "failure cause" indicator) 508 that may limit whether action end 476 is complete. The action IDs for the beginning and ending of the same action may be the same, e.g. to ensure that the two parts are linked correctly.

Fig. 22 is a block diagram of an example composition of an indication of when to initiate an action 97 (action start 474) according to some embodiments of the disclosure. Fig. 23 is a block diagram of example compositions of an indication of when action 97 ends (action end 476) according to some (same or different) embodiments of the present disclosure. As shown, the example compositions of fig. 22 (action start) and fig. 23 (action end) are similar in some aspects (e.g., see failure conditions) and different in relation to other aspects (e.g., see acknowledgements).

As shown in fig. 22, the authorization cause indicator 496 of the start of action 474 may include one or more conditions 520 and one or more preamble activity events ("preamble activity") 522. If one or more conditions 520 are met and one or more preamble activities 522 have been completed, an authorization cause indicator 496 may authorize an associated action to begin 474.

Inference system 52 is a mechanism for determining whether text is true or false or unknown. The conditions 520 may include one or more words 524 and one or more associated time windows ("timedsroups") 526. Text 524 is an expression that may be true or false or unknown depending on the state in which text 524 is evaluated. For example, during a drilling state, the text 524 representing that the drilling rig is operating is true. Similarly, during a mud injection state in which the rig is not operating, the text 524 is false.

Condition 520 (fig. 22; see also at 574 of fig. 23) may be satisfied if one or more words 524 (fig. 22; see also at 568 of fig. 23) of conditions 520, 564 are true for at least a minimum time ("minimum time (MinTime)") 528 (fig. 22; see also at 572 of fig. 23) of conditions 520, 564 and do not exceed a maximum time ("maximum time (MaxTime)") 530 (fig. 22; see also at 574 of fig. 23) of conditions 520, 564. The preamble activity 522 (fig. 22; see also at 566 of fig. 23) may be represented by an entry ID 532 (fig. 22; see also at 576 of fig. 23) and/or a minimum time 534 (fig. 22; see also at 578 of fig. 23). Timing group 526 (fig. 22; see also at 570 of fig. 23) may be, for example, some text or text state (at 370 of fig. 16) in a text state storage area (at 350 of fig. 16) associated with a time window (e.g., a minimum time window to a maximum time window (e.g., at 528, 530 of fig. 22; at 572, 574 of fig. 23)).

The failure cause indicator 498 (see also FIG. 22; at 508 of FIG. 23) may include one or more failure conditions 536 (FIG. 22; see also at 580 of FIG. 23). The fail condition 536, 580 becomes true when the condition 520, 564 on which the associated transaction 472 (fig. 20) depends becomes false. Conditions 520, 564 may become false due to an unexpected situation occurring during execution of the plan 74, the conditions 520, 564 exceeding a threshold time ("ExceededTime") 538 (fig. 22; see also at 582 of fig. 23), etc.

The failure condition 536 (fig. 22; see also at 580 of fig. 23) may include one or more words 540 (fig. 22; see also at 584 of fig. 23) and/or one or more associated timing groups 542 (fig. 22; see also at 586 of fig. 23). The failure condition 536, 580 may be satisfied if one or more of the words 540, 584 of the failure condition 536, 580 is true for at least a minimum time ("minimum time") 544 (fig. 22; see also at 588 of fig. 23) of the failure condition 536, 580. The limited timeout 538 (fig. 22; see also fig. 23 at 582) may include an event ID 546 (fig. 22; see also fig. 23 at 590) and/or a maximum time 548 (fig. 22; see also fig. 23 at 592).

Referring to fig. 23, the acknowledgement 506 of the action end 476 may include a set of conditions (represented by an "authority by" indicator) 560 that confirm the action end 476 if one or more conditions 564 are met and one or more preamble activities 566 occur. As described above, the structure/organization of the condition 564 of the action end 476 and the leading action 566 may be similar or identical to the structure/organization of the condition 520 of the action start 474 and the leading action 522 shown in FIG. 22. For example, the preamble activity 566 can include an entry ID 576 and/or a minimum time 578.

Additionally, the acknowledgement 506 may include a set of conditions (represented by a "acknowledgement cause" indicator) 562, which set of conditions 562 may confirm the end 476 of the action if one or more conditions 564 are met and one or more preamble activities 566 occur. As with the set of conditions represented by the authorization cause indicator 560, the confirmation cause indicator 562 may include one or more conditions 564, and the conditions 564 may include one or more words 568 and one or more associated timing groups 570. The condition 564 may be satisfied if one or more words 568 of the condition 564 are true for at least a minimum time 572 of the condition 564 and do not exceed a maximum time 574 of the condition 564. Word 568 is an expression that may be true or false or unknown depending on the state in which word 568 is evaluated.

The XPlan syntax 130 depicted in FIGS. 20-23 provides an accurate explanation of the execution of plans 74, 94 by planning system 10 (note generally that pointers to communication lines in the figures may also refer to plans along those communication lines, such as XPlan 125). XPlan syntax 130 may enable scheduler 96 (FIG. 3) to schedule software (e.g., plans 94, actions 97, etc.) that use components of planning system 10, and may be executed when authorized and when conditions are detected as true by logical inference system 52 described above. In particular, the XPlan syntax 130 is distinguished by being asynchronous or time independent when compared to conventional software languages. That is, event (e.g., transaction) occurrences as implemented by the XPlan syntax 130 are not driven or triggered based on clock values, but are driven or triggered by other event occurrences (e.g., meeting conditions). Thus, multiple schedulers 96 (associated with different applications (e.g., drilling, mud, or any other application)) may be executed in parallel with interactions between the states of each application. Planning system 10 may therefore interact asynchronously (e.g., event driven) rather than synchronously (which may cause timeouts, resulting in planning system 10 stalling or stopping operation as desired) using XPlan syntax 130. Planning system 10 may satisfy the efficiency gain by using XPlan syntax 130 because upon satisfaction of a condition (e.g., grant cause conditions 496, 560, validation cause condition 562, etc.), planning system 10 may immediately perform act 97 rather than waiting for a particular clock value or clock cycle to act.

A further description of the interrelationship between figures 20 to 23 follows. Referring to FIG. 20, an ordered item 460 of action 97 includes an item ID 462 that uniquely identifies the ordered item, a set of post elements 466, a set of pre elements 470, and an item itself 472. Each post element 466 identifies an item ID 464 or an absolute time 478. Each pre-element 470 also identifies an item ID 468 or absolute time 480. The structure conveys the intent of the planner component 44 that the item ID 462 is located after the prior element and before the subsequent element in the chronological order of the plan 74. As shown in fig. 20, entries 472 in the plan 74 may each appear as part of an ordered entry 460. As shown in fig. 21, item 472 may be, for example, action start 474 or action end 476.

In an embodiment, the ordering matters 460 (fig. 20) may include a set of authorization conditions 520, 564 (fig. 22-23), e.g., as indicated by the authorization margin that may authorize the action start 474 or the action end 476 by the indicators 496, 560. When the plan 74 including the ordered items 460 is implemented (e.g., by the execution and monitoring component 80), the execution and monitoring component 80 can determine whether a set of authorization conditions 520, 564 have been met, and in response to determining that the set of authorization conditions 520, 564 have been met, the execution and monitoring component 80 can execute the ordered items 460.

In an embodiment, the ordering issue 460 (fig. 20) may include a set of failure conditions 536, 580 (fig. 22-23), e.g., as indicated by the failure cause by the indicators 498, 508 that may limit whether the action start 474 or the action end 476 is complete. When the plan 74 including the ordered items 460 is implemented (e.g., by the execution and monitoring component 80), the execution and monitoring component 80 can determine whether a set of failure conditions 536, 580 have been met, and in response to determining that the set of failure conditions 536, 580 have been met, the execution and monitoring component 80 can cease executing the ordered items 460. Thus, in embodiments, the methods of the present disclosure may allow for isolation of failed regions while allowing other regions to continue operating while solving the failure problem.

Further, the ordering matters 460 (fig. 20) may include timing constraints, such as an expected time period, for example, as indicated by the expected duration 502 (fig. 22) that the action 97 should be performed. If act 97 does not complete before expiration of expected duration 502 (after act 97 begins execution), execution and monitoring component 80 may wait for it to complete until any specified failure cause 508 times out time 582 (FIG. 23) has been reached. This time limit out element 582 will specify a maximum time 592 associated with a transaction ID 590 corresponding to the transaction ID 462 corresponding to the action start 474 of the action 97 being performed.

The planner component 44 may also generate an order item element 460 (fig. 20) that includes an action end 476 (fig. 21), which action end 476 may include a confirmation 506 (fig. 23), which confirmation 506 may be a set of authorization conditions (authorization cause 560) or confirmation conditions (confirmation cause 562) that may authorize or confirm the action end 476. When implementing a plan 74, 94 that includes such an ordering item 460, the execution and monitoring component 80 may determine whether the validation cause 562 condition 564 of the validation 506 or a condition that appears in the authorization cause 560 (which similarly appears as the condition 520 in the authorization cause 496 of fig. 22) has been met, and in response, determine that the set of authorization or validation conditions has been met, and execute the ordering item 460. When implementing a plan 74, 94 that includes one or more action start 474 and/or action end 476 ordered items 460 (fig. 20-21), the execution and monitoring component 80 can determine whether a set of failure condition elements 536, 580 (fig. 22-23) have been met and, in response to determining that the set of failure conditions 580 have been met, stop executing the plan 74, 94. Further, if the timeout 582 (fig. 23) is exceeded, the execution and monitoring component 80 may stop executing the plan 74.

Referring to fig. 24 and 25, where ellipses represent states (commonly referred to as 622, 662) and lines (e.g., 629, 666) indicate transitions, finite State Machines (FSMs) and Timed Hybrid Automata (THAs) may be used to capture plan execution semantics and track and manage plan execution. THA is an example of an FSM that can track the state of an item 472 (see, e.g., fig. 21-23) in a plan 74, 94 by tracking the passage of time and the corresponding impact on state variable values that are impacted by the continuous process. When the event is the start of an action (e.g., 474 of fig. 22), it may experience THA as schematically shown in fig. 24. When the event is the end of an action (e.g., 476 of fig. 23), it may experience THA as schematically shown in fig. 25.

In a non-limiting well construction context, in an example operation, THA may track increasing well depths over time. For example, when the action start 474 of the "drilling" action is successfully scheduled, the corresponding item 472 enters the Done state 652 (FIG. 24). Then, item 472 of action end 476 enters an "In Scope" state 668 or 670 (FIG. 25) and remains so until logic inference system 52 (FIG. 16) declares that the target well depth of the drilling action is reached. The expected effect was observed. At this point, the validation margin of action end 476 is satisfied by 562 condition 564 (fig. 23) and item 472 enters validated state 676 (fig. 25). Advantageously, the illustrated THA enables planning system 10 to be driven by events (e.g., when conditions are met) rather than waiting for a particular clock value or clock cycle to act.

For execution of the plans 74, 94, both the amount of time spent in the state and the observed relevant state variable values may trigger transitions between states in THA. For example, if the observation is not made within a time threshold, or a value that falls outside of the expected envelope is observed, then transaction 472 may enter a failed state, namely fail 640 (fig. 24), 696 (fig. 25).

Referring to fig. 24, an item 472 (see also fig. 21-22) representing an action start 474 may experience a state corresponding to: items 472 are "entering scope" 628, 630 (e.g., waiting for satisfaction of authorization condition 520), "authorized" 636 (e.g., licensed schedules 644, 646), and "completed" 648, 652 (e.g., item 472 has been sent to an execution component, such as execution and monitoring component 80, planning execution system 56, etc.).

In an embodiment, THA 620 in fig. 24 may track whether the state was entered early or late relative to what was expected (e.g., for auditing purposes) via, for example, a time associated with event 472, such as time ("expected start time") 500 associated with when action 97 starts as shown in fig. 22, a time period ("expected duration") 502 between action 97 start time and action 97 end time, and so forth. (items 472 that enter the scope on time may be arbitrarily considered to enter the scope early or late). The states involved are "Early entry Scope (In Scope)" 628, "Late entry Scope (In Scope Late)" 630, "advanced dispatch (Early) 644," post-pushed dispatch (Late) "646," Early completion (Done Early) "648 and" Done "652 (fig. 24).

Referring to fig. 25, items 472 (see also fig. 21 and 23) representing the end 476 of an action are managed slightly differently because such items 472 fall into two categories: by observing the confirmed transaction 472 (e.g., transitions 686 and 690), and the transaction 472 in which there is an action required to terminate the action (the authorization condition is satisfied, and the actor terminates the authorization action), e.g., transitions 678 and 682.

In the examples of fig. 24 and 25, there are other differences between action start 474 and action end 476 events: action start 474 may be completed without a response from execution and monitoring component 80, while action end 476 is completed with a response from execution and monitoring component 80. This is because action onset 474 may be monitored during execution, so if no scheduling signal is received (e.g., from scheduler 96), the monitoring process may observe a lack of response. On the other hand, action end 476 transaction marks the end of monitoring the corresponding action 97, so it may be important to receive a reply or a timeout indication (if no reply is received within an appropriate interval).

Instantiation of the relevant conditions (which may be referred to as "jump conditions") that may be met to enter or exit states 622, 662, the conditions that must be maintained when occupying states 622, 662 (referred to as "state conditions"), and the contents of the operation file specifying conditions that may be used during execution, such as timeout conditions or properties, that may limit the duration that planning execution system 56 (fig. 2) should wait for a dispatch signal before indicating a failure may be automatically populated by the output of planner component 44 using the domain model and the contents of the operation file.

In this regard, and in more detail, fig. 24 is a state diagram of THA 620 tracking the state 622 of action onset 474 events in plan 74 according to embodiments of the present disclosure. In some embodiments, processor 24 and/or planner component 44 (e.g., see fig. 1-2) may implement THA 620. In further embodiments, THA 620 may be implemented by any other suitable component or control logic, such as the execution and monitoring component 80 or the target arbitration component 114 (see, e.g., fig. 3).

Referring to fig. 24, and also to fig. 21-22, each action start 474 event may start with a Dormant (dorman) state 624 in THA 620. Once each of the preamble activities 522 (if any) of the action start 474 events have been completed (e.g., entered into a completed state), the action start 474 event may enter a scope. By "enter scope" is meant, for example, that inference system 52 monitors conditions 520 associated with action start 474 items to authorize the action start 474 items.

As shown, when action start 474 event enters scope 626 early (e.g., relative to expectations), action start 474 event enters "early enter scope" state 628. When action start 474 event is pushed back into scope 629 (e.g., relative to expectations), action start 474 event enters "pushed back into scope" state 630. (the state of entering the scope on time may be arbitrarily considered as entering the scope early or late). In some cases, the action start 474 event in the "early enter scope" state 628 may be delayed beyond the expected execution time 632, and thus may enter the "push enter scope" state 630.

If the condition 634 associated with authorizing action start 474 events is met, action start 474 events may enter authorized state 636 from either early enter scope state 628 or late enter scope state 630. Regardless of whether the action start 474 event is in the sleep state 624, "early entry scope" state 628, "late entry scope" state 630, or the authorized state 636, if a failure condition is detected 638 (e.g., a timeout condition is met), the action start 474 event enters the failure state 640.

When action start 474 event is in authorized state 636, scheduler 96 (fig. 3) may schedule a corresponding action start 474. When action start 474 is scheduled and/or authorized early 642 (e.g., relative to an expected execution time), action start 474 event enters an "scheduled early" state 644. When action start 474 is post-scheduled and/or authorized 645 (e.g., relative to an expected execution time), action start 474 events enter a "post-scheduled" state 646. If action start 474 event enters "scheduled ahead" state 644 because it is granted ahead 642, but scheduled behind 653 (e.g., relative to the expected execution time), action start 474 event enters "scheduled behind" state 646.

With continued reference to fig. 24 and other figures above, the execution and monitoring component 80 (fig. 3) can then respond to the action start 474. If action start 474 event is in "scheduled ahead" state 644 and execution and monitoring component 80 responds to action start 474 early 647 (e.g., relative to an expected execution time), action start 474 event enters "complete ahead" state 648. Otherwise, if the execution and monitoring component 80 pushes back 650 (e.g., relative to the expected execution time) the action start 474, the action start 474 event enters a complete state 652. (if the execution and monitoring component 80 responds to the action end 474 on time, the action end 474 event may be arbitrarily considered as being an early or late response).

As another example, fig. 25 is a state diagram of THA 660 tracking state 662 of action end 476 events in plan 74 according to an embodiment of the present disclosure. In some embodiments, processor 24 and/or planner component 44 (e.g., see fig. 1-2) may implement THA 660. In further embodiments, THA 660 may be implemented by any other suitable component or control logic, such as the execution and monitoring component 80 or the target arbitration component 114 (see, e.g., fig. 3).

Referring now to fig. 25, and also to fig. 21 and 23, each action end 476 event may begin with a sleep state 664 in THA 660. Once the entry 472 representing the corresponding action start 474 has been completed (e.g., enter completion state 652), the action end 476 entry enters the scope. As shown, when an action end 476 event enters the scope 666 early (e.g., relative to expectations), the action end 476 event enters the "early enter scope" state 668. When action end 476 item is pushed back into scope 669 (e.g., relative to expected), action end 476 item enters "push into scope" state 670. (an action end 476 event that enters the scope on time may be arbitrarily considered to enter the scope early or late). In some cases, an action end 476 event in the "early enter scope" state 668 may be delayed beyond the expected execution time 672 and thus may enter the "push enter scope" state 670.

If an effect expected to occur as a result of an event 472 is observed 674, then an action end 476 event may enter a validated state 676 from an "early enter scope" state 668 or a "late enter scope" state 670. When action end 476 transaction is in acknowledged state 676, scheduler 96 (FIG. 3) may schedule a corresponding action end 476. When action end 476 is scheduled and/or authorized early 678 (e.g., relative to an expected execution time), the action end 476 event enters an "scheduled early" state 680. When action end 476 is post-scheduled and/or authorized 682 (e.g., relative to an expected execution time), the action end 476 transaction enters a "post-scheduled" state 684. If action end 476 transaction enters "early scheduled" state 680 because it is early authorized 678, but is post-scheduled 695 (e.g., relative to an expected execution time), then action end 476 transaction enters "post-scheduled" state 684.

Execution and monitoring component 80 may answer action end 476, for example, with respect to actions that planning system 10 does not interfere, but only observes completion. If action end 476 transaction is in either confirmed state 676 or "scheduled ahead" state 680, and execution and monitoring component 80 responds to action end 476 early 686 (e.g., relative to an expected execution time), then action end 476 transaction enters an "complete ahead" state 688. Otherwise, if execution and monitoring component 80 pushes back 690 (e.g., relative to the expected execution time) the answer action end 476, the action end 476 event enters a complete state 692. (if execution and monitoring component 80 responds to action end 476 on time, then action end 476 events may be arbitrarily considered to be either early or late responding).

Regardless of whether the action end 476 transaction is in the sleep state 664, the "early enter scope" state 668, the "push enter scope" state 670, the acknowledged state 676, the "early scheduled" state 680, or the "push scheduled" state 684, if a failure condition is detected 694 (e.g., a timeout condition is met), the action end 476 transaction enters the failure state 696.

In this way, THA 620 of fig. 24 and THA 660 of fig. 25 may track state 622 of action start 474 events and state 662 of action end 476 events in plan 74.

Reference throughout this specification to "one embodiment," "an embodiment," "embodiments," "some embodiments," "certain embodiments," or similar language means that a particular feature, structure, or characteristic described in connection with the embodiment may be included in at least one embodiment of the present disclosure. Thus, such phrases or similar language throughout this specification may, but do not necessarily, all refer to the same embodiment. Although the present disclosure has been described with respect to specific details, it is not intended that such details should be regarded as limitations upon the scope of the disclosure except insofar as and to the extent that they are included in the accompanying claims.

While the embodiments set forth in this disclosure may be susceptible to various modifications and alternative forms, specific embodiments have been shown by way of example in the drawings and have been described in detail herein. It should be understood, however, that the disclosure is not intended to be limited to the particular forms disclosed.

The techniques presented and claimed herein are referenced and applied to material objects and specific examples that may provably improve the actual properties of the art, and are therefore not abstract, intangible, or purely theoretical. Furthermore, equivalent constructions including functional "means-plus-function" or "step-plus-function clauses are intended to cover the structures described herein as performing the recited function, including structural equivalents that operate in a similar manner and equivalent structures providing the same function. Applicant expressly intends to neither claim nor claim additional functionality, steps, or other functionality, except for those wherein the words 'for..means' or 'for..steps' occur with related functionality.

Claims

1. A system, comprising:

a first set of equipment; and

a computing device communicatively coupled to the first set of equipment, wherein the computing device comprises:

one or more components configured to control the first set of equipment to perform planning based at least in part on a state of the system; and

an inference system configured to determine the status of the system based on sensor data received via one or more sensors disposed on the first set of equipment, wherein the inference system comprises:

a condition scheduler configured to receive a request for a condition of the system from a further component separate from the one or more components, wherein the further component is configured to control a second set of equipment;

a query responder configured to determine validity of the condition based at least in part on an evaluation of a rule associated with the condition, wherein the rule corresponds to the state of the system;

a rule evaluator configured to evaluate the rule to determine the validity of the condition based on whether one or more properties associated with the condition correspond to the state of the system, wherein the condition scheduler is configured to transmit an indication associated with the validity of the condition to the further component, and wherein the further component is configured to control the second set of equipment based on the validity of the condition; and

A literal state store configured to determine a state of a literal, wherein the literal includes a positive or negative atomic proposition expression.

2. The system of claim 1, wherein the computing device comprises a data acquisition system configured to acquire the sensor data from the one or more sensors disposed on the one or more pieces of equipment.

3. The system of claim 2, wherein the inference system comprises a system state estimator configured to receive the sensor data from the data acquisition system and determine the state of the system based at least in part on the sensor data.

4. The system of claim 1, wherein the query responder is configured to determine the validity of the condition based at least in part on the state of the literal.

5. The system of claim 1, wherein the literal status store is configured to determine a duration of the status of the literal.

6. The system of claim 5, wherein the query responder is configured to determine the validity of the condition based at least in part on the duration of the state of the literal.

7. The system of claim 1, wherein the query responder is configured to determine a duration of the validity of the condition.

8. The system of claim 7, wherein the condition scheduler is configured to authorize an action of the system based at least in part on the duration of the validity of the condition.

9. A method, comprising:

receiving, with a processor, a condition configured to authorize an action of a system including one or more pieces of equipment;

in response to determining that a rule is associated with the condition, identifying, by the processor, the rule as a potential support for the condition, wherein the rule includes a premise and an implication term, wherein when one or more preconditions of the premise of the rule are determined to be true, the implication term of the rule is inferred to be true, and wherein the one or more preconditions are associated with the condition;

activating, with the processor, the rule in response to determining that the premise of the rule is true, wherein validity of the condition is based at least in part on activation of the rule;

instructing, with the processor, the one or more apparatuses to perform the action based at least in part on the validity of the condition.

10. The method of claim 9, wherein identifying, with the processor, the rule as the potential support for the condition comprises determining that the implication item of the rule comprises the condition.

11. The method of claim 9, wherein the rule comprises a plurality of rules, wherein the method comprises indicating that the condition is true when at least one of the plurality of rules is active.

12. The method of claim 9, wherein the rule comprises a plurality of rules, wherein the method comprises indicating that the condition is not true when none of the plurality of rules is active.

13. A tangible machine-readable storage medium comprising machine-readable instructions for causing a processor to:

receiving status information of a system, wherein the status information is based at least in part on sensor data received from one or more sensors disposed on one or more pieces of equipment of the system;

disabling a rule in response to determining that the rule is active and that the state information indicates that a precondition for the rule is false, wherein the rule includes the precondition and an implication, wherein the implication of the rule is inferred to be true when one or more preconditions for the precondition for the rule are determined to be true;

Activating the rule in response to determining that the rule is inactive and that the state information causes the precondition of the rule to be true;

responsive to activating the rule, authorizing an action configured to be performed by the one or more pieces of equipment; and

in response to authorizing the action, controlling the one or more pieces of equipment to perform the action.

14. The machine-readable storage medium of claim 13, wherein the processor is configured to authorize the action based at least in part on validity of a condition.

15. The machine-readable storage medium of claim 14, wherein the processor is configured to determine that the rule is a potential supportor when the rule is associated with the condition.

16. The machine-readable storage medium of claim 15, wherein the processor is configured to determine that the rule is the potential supporters by determining that the implication item of the rule includes the condition.

17. The machine-readable storage medium of claim 16, wherein the processor is configured to deactivate the rule in response to determining that the rule is the potential support.

18. The machine-readable storage medium of claim 16, wherein the processor is configured to activate the rule in response to determining that the rule is the potential support.

19. The machine-readable storage medium of claim 14, wherein the rule comprises a plurality of rules, wherein the processor is configured to:

indicating that the condition is true when at least one of the plurality of rules is active; and

when none of the plurality of rules is active, it is indicated that the condition is not true.