Kjell Kristian Ask
Aker BP
Stavanger
Carlo Caso
Cognite AS
Oslo
Jan Isaachsen
Keystone.no AS
Stavanger
Aker BP is implementing an open, standardized, and structured digital drilling ecosystem that exchanges plans between process areas while enforcing standardized plan structures for well construction, time estimation, and time planning.
For the past few years, oil and gas companies have invested in digital process and control of well construction and drilling operations with the goal of improving efficiency and reducing cost of reaching drilling targets. For many, such a goal is still to be achieved, with each drilling planning process step performed in separate spreadsheets and documents by disparate legacy applications requiring semi-manual point-to-point connections. The process often comprises frequent data importing, exporting, and manual typing and retyping of plan content. These inefficiencies make it difficult to enforce a standard and commonly understood plan structure. It also increases the likelihood of data entry errors and impedes the timely communication of accurate and up-to-date activity plans.
This article describes Aker BP’s Backbone service, a “smart hub” that receives and centrally masters updated plans, checks each plan’s conformance to the schema on which it is based, and distributes validated plans to registered consumers (Fig. 1). The service, serving as a single reference point across the entire well planning and execution lifecycle, enables all drilling and well data to be reused, improving future planning and drilling processes. Loosely coupling Backbone with its consumers and publishers, new plans can be added, or an existing plan replaced, without impacting other existing connections.
Background, issues
Within Aker BP, well construction planning and execution historically spans multiple disconnected systems. Currently, obsolete legacy software or manually completed documents and spreadsheets fulfill the overall process. The reliable and efficient passing of plans across multiple systems is a practical impossibility, and this semi-automated integration has increased the probability of human error. Manually rechecking plan content throughout the process to prevent loss or corruption of data during transfer has mitigated these problems but requires considerable resources and business expertise.
Macro-enabled spreadsheet templates have been used to document time plans. A spreadsheet is manually populated with data, typically with time estimates from drilling engineers’ previous experience and judgement. Monte Carlo simulation derives the P50 estimates for tasks and activities and the spreadsheet subsequently circulates the time plan to drilling engineers, rig operators, and service companies.
A separate rig action plan augments the time plan to describe additional information such as drilling guidelines, procedures for rig activities, checklists, potential risks and hazards, and lessons learned. This plan is also circulated to drilling engineers, rig operators, and service companies. The nomenclature and content of the time plan and rig action plan should fully align, but often do not. The manual copying and pasting of material from one document to the other is both time consuming and fraught with error.
Such documents receive little governance and vary greatly in structure and content; e.g., activity types and their properties are named inconsistently and therefore are open to interpretation. The lack of consistency between plans makes it impossible to re-use successful activity plans, share plans, consistently interpret plans, or to enforce an operator-mandated planning standard and approach.
A hidden and costly impact of inconsistently defined and described plan activities is failing to identify trends (such as common and repeated planning errors) across multiple plans.
Problems also exist in plan reporting, including daily drilling reports and the end-of-well reports. Each day several hours are spent filling out documents based on individual interpretation of plans. Reports are manually distributed by email to stakeholders and rig crews. Fig. 2 shows disparate parts of current spreadsheet-based state-of-well construction planning, execution, and reporting.
Backbone
To overcome such issues, Aker BP envisions well-governed, commonly understood activity plans shared between systems without the need for human intervention. Plans will conform to operator-defined schemas that define a permissible plan structure and permissible activity types and properties that can appear in a conformant plan. Plan activities are annotated with permitted artefacts such as known risks, best practices, or lessons learned from previous executions. Moreover, the framework results in better governance and production of consistent, commonly interpreted and unambiguous plans. Once such plans are proven in production, they become templates for future activity.
Aker BP worked with Keystone, a specialist Norwegian operational software provider, and Cognite Data Fusion (CDF), a global technology company that specializes in industrial digitalization, to develop its Backbone service, effectively a smart hub to mediate between plan producers and consumers.
The service is the central storage and routing platform that receives and centrally masters updated plans, checks each plan’s conformance to the schema on which it is based, and distributes schema-conformant plans to registered consumers that produce plan content and control the planning process (Fig. 3).
The distribution of a plan is like a journal or periodical. For each plan, Backbone maintains a list of subscribers (or registered consumers). Whenever a plan update is committed to the service, all subscribers on the list are notified and can load the revised version.
Applications that, for example, create time plans assigning equipment and create rig actions can only receive plans and commit updates to the smart hub. Secondary and tertiary consumers, such as procurement and transportation applications, also receive plans from the smart hub and use content to trigger and report their own progress.
Plan structure
Fig. 4 shows various components of the activity plan organized into a hierarchy. The desired outcomes are documented by the first four levels. Level 1 identifies the well and wellbore. Level 2 (L2) lists the events, typically drilling and completion. Level 3 (L3) represents phases which align with the physical elements of the well as defined in the casing design; e.g., the installation of a conductor casing or liner. Level 4 (L4) lists drilling, casing, and cementing components and includes time estimates in hours.
Planned outcomes go into greater detail depending on the guidelines and procedures that each operator adopts to create the drilling activity plan. For example, additional detail can be added to describe activities that must be performed to achieve these outcomes. These are Level 5 (L5) activities. Level 6 (L6) lists physical rig tasks (e.g. check mud pool). Level 7 (L7) further breaks down L6 steps into sub-steps or sequences, such as open elevator.
Plan distribution
Backbone offers multiple advantages over typical methods of plan exchange found at many E&P companies. These include replacing multiple point-to-point integrations between plan producers and consumers with a single hub-to-system integration for each connected system. Because plans are centrally mastered by Backbone, consumers are guaranteed to receive only the most recent release. Finally, when an update is committed to the service, its content must be successfully validated against its schema (i.e. its permissible content) before being centrally mastered and made available to registered consumers (Fig. 5). Erroneous plan updates are never distributed.
Each plan node (e.g. L5 activity) is uniquely identified with a system-generated universally unique identifier (UUID). This identifies the node in all applications that consume the plan.
Backbone makes the latest, validated version of a plan available to all registered consumers. In early stages of planning, consumers will include planning applications and enabling support applications such as personnel and logistics planning. Later, applications that manage the execution of the plan will also subscribe to and update the plan, e.g. the sequence application employed on-rig to manage rig operations. Such applications can annotate the plan’s activities with execution status, activity start and stop times, and other data relating to execution such as a lesson learned or a driller’s note.
Plan validation
The structure and content of each plan must conform to a specific schema for processing.
For a given plan, the schema describes and validates the structure and content of its activities. It defines the elements (known as a Type, e.g. an L5 Activity or a Risk) that can appear within a plan, the properties that can be used to describe these element types, and how element types can be related to each other within a plan’s hierarchy.
When a plan is committed to Backbone, the service identifies the schema the plan should conform to and uses it to validate the plan’s content. Content validation includes checking that:
- Each node in the plan conforms to a given type within its schema.
- Each field describing a node conforms to a property permitted for its corresponding type within its schema.
- Any relationship between two nodes in the plan conforms to a permitted relationship between their corresponding types as defined in the schema.
If confirmed, a committed plan persists and is available to registered consumers, otherwise the plan rejects the update and the committing application must either discard its changes or correct any issues and resubmit the update to Backbone.
Schemas can also be distributed to plan producers and consumers to constrain or validate plans in their systems.
Plan execution
A key function of the service is delivering plans to executable applications and accepting drilling execution status and outcome updates from these applications with actual times and depths reached. This is especially important for support of automated drilling where many of the service’s benefits will be realized.
Each plan is published by the Backbone service as a single schema-compliant JavaScript Object Notation (JSON) file. These plans can be decomposed to the executable, parameterized instructions needed to control manually, semi-automated, or fully automated on-rig tasks. Plans can also coordinate robotic equipment with rig execution tasks (Fig. 6).
Data contextualization
Aker BP aims to follow its own approach, methods, and guidelines to create a well from defined geological targets in compliance with relevant regulations. At the macro level this process typically includes trajectory validation, casing design, and preliminary time estimates for the entire well drilling and completion processes. By standardizing naming and definition of plan components and their properties, the future IT landscape will automatically unite wellbore activity with related artefacts such as wellbore trajectories, casing designs, and logs (Fig. 7).
Using Backbone to distribute and validate standardized and structured plans is beneficial in and of itself, but the service also supports the wider digitalization goal of harvesting, liberating, and contextualizing Aker BP’s subsurface and drilling data.
Automated plan reporting
Plan reporting by specialized rig personnel who manually create and email each report is time-consuming and repetitive. To help ease this burden, plans have been structured to align with reporting requirements rather than the other way around.
In the future, plan reporting will be fully automated. Traditional reporting codes will be removed, making their structures and content completely agnostic of historical plan reporting formats. Instead, Backbone will publish the standard plan to a structure that uses rules to generate regulatory and operational reports from the plan content.
Portals will expose plan data to internal users, partners, and reporting bodies. Ultimately, any party can define its own reporting requirements (using the rules-based reporting solution) and present activity plans in their own required encoding on demand. An important feature of Backbone is its ability to allow partners’ systems and services to be rapidly and inexpensively connected.
Estimated savings
Seamlessly connecting all systems (including automated equipment handling and drilling) in the activity planning and execution lifecycle will reduce drilling times by 15-25%. The time reduction will lead to substantial cost savings, increasing profit in smaller reservoirs. Other benefits include more accurate time estimates and resource planning, more efficient logistical services, and better data-driven decision-making.
The authors
Kjell Kristian Ask ([email protected]) is the crew lead for the digital well crew in EurekaX, AkerBPs digital lab, Stavanger, Norway. He has also served as a drilling and well engineer in AkerBP, Det norske oljeselskap, and Marathon Oil Co.
Carlo Caso ([email protected]) is the head of subsurface and drilling products at Cognite AS, Oslo. He has also served as a geoscientist at Schlumberger and Sorgenia. He holds a Ph.D in geology from University of Chieti,Italy, and an executive MBA from ESCP, Paris.
Jan Isaachsen ([email protected]) is founder and product owner at Keystone.no AS in Stavanger. He has also served as product manager in several companies in the past with focus on tracking solutions and operational software.