SPE-195629-MS

OpenLab: Design and Applications of a Modern Drilling Digitalization

Infrastructure

Nejm Saadallah, Jan Einar Gravdal, Robert Ewald, Sonja Moi, Adrian Ambrus, and Benoit Daireaux, Norce; Stian
Sivertsen and Kristian Hellang, Miles; Roman Shor, University of Calgary; Dan Sui, University of Stavanger; Stefan
Ioan Sandor, Aker BP; Marek Chojnacki and Jacob Odgaard, Maersk Drilling

Copyright 2019, Society of Petroleum Engineers

This paper was prepared for presentation at the SPE Norway One Day Seminar held in Bergen, Norway, 14 May 2019.

This paper was selected for presentation by an SPE program committee following review of information contained in an abstract submitted by the author(s). Contents
of the paper have not been reviewed by the Society of Petroleum Engineers and are subject to correction by the author(s). The material does not necessarily reflect
any position of the Society of Petroleum Engineers, its officers, or members. Electronic reproduction, distribution, or storage of any part of this paper without the written
consent of the Society of Petroleum Engineers is prohibited. Permission to reproduce in print is restricted to an abstract of not more than 300 words; illustrations may
not be copied. The abstract must contain conspicuous acknowledgment of SPE copyright.

Abstract
The transition towards drilling automation in the oil and gas industry has increased the need for digital
infrastructures for development and testing of new technology. This includes infrastructures to facilitate
changes in work processes and technical competences. This paper describes the design and use of OpenLab
Drilling, a digital infrastructure with applications in education, technology development and testing.
OpenLab Drilling offers access to a high fidelity drilling process simulator capable of simulating
transient hydraulics, temperature, torque and drag, and cuttings transport. Since 2018, the infrastructure
has been publicly available for students, researchers and engineers who need realistic drilling data for
technology development, demonstration and education. The simulated drilling data can be accessed by
several means. First, through a user-friendly web application used as a tool for teaching the physics involved
in drilling operations. Secondly, drilling data can be accessed programmatically through a web API or
via programming language APIs written in MATLAB, Python and .NET. Thirdly, OpenLab offers a fast
communication interface that can be used for applications that are closer to hardware, and which require a
realistic Hardware in The Loop (HIL) infrastructure.
This paper describes the objectives of OpenLab as a project, its system architecture, its simulation
capabilities, the design of its web application, and its various communication interfaces. The paper also
presents projects that uses OpenLab in education, research on machine learning, semantical representation
of drilling data, and other industrial relevant activities. The paper is naturally divided in two parts: The
design of the infrastructure, and its applications.

Introduction
Drilling technology has seen great advances over the past three decades. Drilling long reaching wells and
narrow pressure margin wells has become more frequent than in the past. One of the enablers for this
evolvement is better understanding of the downhole physical processes. Control of the drilling process
requires accurate estimation of the mechanical state (torque and drag), the hydraulic state (multiphase flow),
the temperature state, and cuttings transport [1].
2 SPE-195629-MS

Although a better understanding of the physical processes in drilling has been achieved, many challenges
remain. One reason for this seems inherent to the complexity of the problem itself. Others are due to the costs
of developing and testing new technology. Testing on a full-scale rig remains the most realistic environment,
but not always cost efficient, especially at early stages of the development. For example, testing a control
algorithm at the site can only be done after the algorithm has passed a qualification phase in a simulator.
Another reason is the lack of drilling data with sufficient quality and metadata from the drilling operations.
The amount of information that can be retrieved from the data is often sparse, and the efforts to use the data
for analysis and process control purposes are very challenging [2] [3], even for experienced engineers.
To accelerate the readiness of new technology it must be tested and demonstrated in a simulated but
realistic environment up to a certain technology readiness level [1] before field trials. However, a common
feature of high fidelity models is that the user interface is designed for scientists and engineers skilled to
set up the cases (configure the model), run the software and analyze the results. This has the benefit that
the complexity of the models can be exploited to their full potential. However, this is at the expense of user
friendliness, and makes it difficult for non-experts to utilize such models.
Non-experts are mainly students, scientists and engineers who have not yet acquired enough field
experience, and who are often required to understand complex dynamics, or personnel that are new in the
field, and who want to gain knowledge. For these reasons, the OpenLab project [4] came to life with the aim
to provide a drilling infrastructure for education, research and innovation, and testing of new technology.
The infrastructure has been developed with a high focus on user friendliness. OpenLab targets students,
lecturers and researchers by providing a user-friendly graphical interface and an easy to use application
programming interface (API). The project also provides a hardware in the loop (HIL) system which is tightly
connected with a downhole simulator.
OpenLab Drilling is listed on the Norwegian Roadmap for Research Infrastructure (2016). It addresses
OG21’s strategy which states that "OG21 and industry organizations need to put special efforts into
increasing students’ interest for petroleum core subjects, and to attract professionals with digitalization,
automation and ICT competencies" [5].

System Design
Functional Overview
The OpenLab software architecture consists of several software modules that implement specific
functionalities within the overall system. In Figure 1, the functionalities at the bottom right are captured
in the web application in order to provide a visual guide and interaction mechanism to the end user. The
bottom left provides a set of software libraries that offer monitoring and control possibilities via application
programming interfaces (APIs).
SPE-195629-MS 3

Figure 1—Overview of the different functionalities that OpenLab offers

Every element that is conceptually situated at the bottom relies on data communication towards a REST
API to operate. The main functionalities behind the high-level communication interface are offered by a
transient downhole simulation module. This module relies on WeMod [5] to perform various simulations of
the drilling process, which can be grouped in hydraulic, temperature, torque and drag, and cutting transport
simulation capabilities. The simulation module also offers the possibility to communicate directly with
third party software using a User Datagram Protocol (UDP) communication interface. This communication
interface exists to address performance needs that are often required by Drilling Control Systems for more
realistic hardware simulation setup.
The data management system enables users to securely access the system and their data. The most
important user data are the set of configurations created by a user and the set of simulation that a user has
run. A more detailed representation of the system is explained in the next section.

System Architecture
The requirements to the infrastructure were to first and foremost support education, followed by research
and innovation. Classrooms are the most demanding usage for the infrastructure. Many students are running
simulations concurrently for a limited time. Ensuring the cost-effective availability of computational
resources is particularly challenging under this usage pattern.
The requirements.
Functional and non-functional requirements are:

• Enable multiple concurrent faster-than-real-time simulation runs.

• Cost effective use of computational resources.

• Usable in a heterogenous network environment.

• Secure handling of malicious inputs.

In order to address these challenges, the system is architecturally composed of multiple parts:

• Web API

• One watchdog service per simulation machine (a machine can run several simulations)
4 SPE-195629-MS

• Different types of watchdog services for different purposes, e.g., HIL simulation

• User clients running in the Web Browser

• Programmable user clients such as the Python or MATLAB client

Figure 2—Data Center Architecture

The Web API is implemented following REST [6] principles. Communication with the Web API is using
standard Web Protocols, more specifically http(s) and WebSocket. This ensures that the solution can be
used in heterogenous network environments with minimal support from IT departments. Using standard
encryption in the TLS layer of https ensures the integrity and confidentiality of communication. The Web
API facilitates communication and access control between different parts of the system. It uses a database
backend to store all relevant data.
The watchdog services connect to the Web API and query a simulation queue. When a new simulation
session is requested by the user, the watchdog checks simulation capacity and initializes a simulation
process. It watches these processes for crashes and other abnormal behavior and terminates them when
required. This can for example happen when a simulation runs into an unphysical regime as is common
in an educational context (try and fail). The isolation layer which the watchdog provides is essential to
the functioning of the infrastructure. The available capacity is configured and dependent on the machine
hosting the simulation process. The available capacity informs a delay in the acceptance of simulation
requests. A watchdog service with more available capacity would answer the request, and hence contribute
to achieve an even distribution of resource consumption, also called "stateless balancing mechanism". More
simulation capacity can be quickly and easily provided by starting the watchdog process on newly deployed
simulation machines. This addresses the challenge of adding computational capacity when many concurrent
simulations are demanded. Hardware in the Loop (HIL) simulation requests are specifically marked for this
purpose. This is independent of the configuration, which allows testing the configuration in a normal web
simulation session first and then starting a HIL simulation in the drilling control room.
During the work on the infrastructure the amount of data which must be processed by the Web API
has proven to be a challenge. The Web API can now be run in multiple instances which run behind a
local reverse proxy. The reverse proxy acts as a load balancer and distributes requests to the Web API.
SPE-195629-MS 5

Although the simulation results are not influenced by the latency of the communication, the user experience
is. The dominating factor is the topological distance between the user facing client and the Web API. By
cooperating with universities around the world we have secured computation resources close to the user. By
using a GeoDNS service we route the client to a Web API endpoint that is closest with the expectation that
this arrangement reduces latency. This setting can be overridden manually. The distributed databases are
synchronized using a message bus to provide access to the generated data when the user changes locations.

Figure 3—GeoDNS usage

Synchronization of data can be challenging, especially when there is a possibility of conflicts (difficult to
automatically merge), which need to be solved by the user. We avoid many of these challenges by following
an append-only approach. Results of a simulation can only be written once, where the first writer wins.
Merging results from multiple locations is then straight forward and free of conflicts. Configuration data
is marked read-only as soon as a simulation is started. These can then also be easily synchronized. Other
benefits are that a simulation can be easily understood by having the correct configuration available.
Communication API. Communication with the OpenLab system is done through a RESTful service that
can be located at https://live.openlab.app. The reference documentation for the API, which is based on a
Swagger/OpenAPI specification, can be found at https://live.openlab.app/swagger.
All communication with the API is done over HTTPS and encrypted using TLS. In order to communicate
with the API, a client must be authenticated and authorized. Authentication is implemented using industry-
standard protocols such as OAuth 2.0 and OpenID Connect. This also allows federated authentication
against third-party identity providers, like Google and Microsoft.
OpenID Connect metadata, such as token and authorization URLs, supported grant types and signing
algorithms is available at https://live.openlab.app/.well-known/openid-configuration. Reference clients
for .NET, Python and MATLAB have been implemented to make development as easy and painless as
possible. These provide out-of-the-box functions for authenticating, fetching and creating configurations
and simulations, sending simulation setpoints and collecting simulation results.
The API supports content negotiation using the so-called Accept Header. It supports three different
payload representations:

• JavaScript Object Notation (JSON) - a text-based format well suited for most clients. This is the
default format and is used for the Python and MATLAB clients.
• MessagePack - a compact binary format best suited for high-performance desktop and mobile
clients. This is only supported by the C# client and is used for back-end communication between
the simulator, watchdog and HTTP API.
6 SPE-195629-MS

• Transit, which is an encoding layer on top of either JSON or MessagePack that allows very efficient
representations of data structures in a programming language-agnostic way. This format is used
by the web-based client.
By using content negotiation, clients can pick the most efficient format that they support. In addition
to plain HTTP endpoints, the API also supports subscriptions for real-time notifications of setpoints and
simulation results. This is done through WebSocket connections. Because Python and MATLAB do not
support WebSocket connections, setpoints and results are fetched from the API using a polling mechanism.
Architecture summary. By using standard and well-known communication protocols and implementing
loosely coupled and focused components we were able to implement a system that successfully answers
the requirements.

OpenLab Web Application

Part of the OpenLab project is to provide access to a state-of-the-art drilling simulator that is easy to use,
can scale to a large number of simultaneous users (e.g., university lecture), and requires minimum software
installation efforts.
This section solely focuses on the web application as such. That is,

• The inputs from the users and what to expect from the drilling simulator

• The technology choices to provide a good user experience

The development of the web application targets a specific user group and aims at facilitating their usage
by means of intuitive interaction design and automated recommendations. The main user types are students,
lecturers and researchers that are interested in using or studying the dynamics of the drilling process.
For a quick start, the application provides configurations based on pre-defined templates. A configuration
is a description of the different elements that affect the circulation system and drill string mechanics. The
application facilitates all levels of expertise, from the absolute beginner to the knowledgeable industry user.
The beginner user can choose from one of many pre-made and optimized configurations before running
simulations. More experienced users can use our configuration editors to customize casing design, well
path, drilling fluid properties, drill string elements, formation properties, and special rig equipment.

Hole Section
In OpenLab, the hole section consists of a riser, a set of casings and liners, and a definition of the open
hole part.
SPE-195629-MS 7

Figure 4—An example of a hole section

Well Path
The well is defined by a sequence of survey stations, which can either be edited directly in the web
application or imported from an existing file. The color bar is part of the schematic to give an intuitive view
of the dogleg severity which very often affects the ability to drill a well. From a simulation perspective, the
well path mainly affects the drill string mechanics and the cuttings transport.

Figure 5—An example of a well path

Fluid
The fluid in OpenLab is defined by its density, rheology, gel strength and its oil water ratio. The fluid affects
all aspects of the simulation.
8 SPE-195629-MS

Figure 6—Example of a fluid description

Drill string
The drill-string in OpenLab consists of drill pipes, bottom hole assembly elements, and a drill bit. All the
elements (except the drill bit) are defined by their length, internal and external diameters, and weight. The
drill string affects all the simulation aspects (torque and drag, heat transfer, fluid flow and cuttings transport).

Figure 7—An example of a drill string

Geology
The geology is defined by the geo-pressure and geothermal gradients. The geo-pressure profiles will affect
the simulation in terms of fluid losses and influxes. The geo-thermal gradients are mainly used by the heat
transfer calculation which also exerts an influence on the fluid properties.
SPE-195629-MS 9

Figure 8—An example of geo-pressure and geo-thermal gradients

Rig
The rig parameters serve to guide towards a realistic drilling process dynamic. Typically, these include the
maximum pump acceleration or the rate at which a choke can open or close.

Figure 9—Rig configuration

Simulation
Once the configuration is defined and no errors are found by the automatic validation engine, it is possible to
start a simulation. A simulation is mainly a sequence of inputs that is supplied to a calculation module, which
in turn outputs the state of the well for every time step. The time step that the application uses corresponds
to 1 second of physical simulation.
It is possible to set the main pump flow rate, top-of-string velocity, rate of penetration (ROP), surface
rotational speed, Managed Pressure Drilling (MPD) choke opening, MPD pump flow rate, open or closed
blow-out preventer (BOP), active pit, return pit, and direct control of active pit fluid properties. The user
can choose to pause the simulation, to run the simulation at a real-time speed (1 second) or fast forward
to quickly simulate ahead. A user can even send a sequence of setpoints that cover the whole simulation
duration and simply gather the results when the simulation has finished.
10 SPE-195629-MS

The results of the simulation are of two types: time based or depth based. For example, the annulus
equivalent circulating density (ECD), annulus and drill string temperature plots on the figure are depth-
based plot, while the stand pipe pressure and bit depth plots are time based. The OpenLab web application
offers the possibility to plot 30 time-based and 9 depth-based plots. The user can also download all the
setpoints and simulation results at the end of a simulation.

Figure 10—Simulation page

Technology
From a software development perspective, the OpenLab application runs in a web browser as a web
application using the "Single Page Application" (SPA) approach [7] to provide a better user experience, by
behaving more like a traditional desktop application. This is different from a traditional web application as
it serves all needed content on initial load, and dynamically updates the content on the page using AJAX
and WebSockets to retrieve data asynchronously as the user navigates and performs actions on the page.
Since more user interaction requires more application logic and often a larger application state, the added
functionality of a SPA comes with the added cost of complexity. As the complexity grows it becomes
important to choose technologies and design patterns that help maintain and reason about the application,
as well as reduce the risk of the so-called accidental complexity [7]. The advantages of using a functional
programming style are many: having it as part of the language is even better as it reduces the risk of anti-
patterns, writing ineffective code as well as relying less on developer discipline. It also makes it easier to
handle concurrency issues and thread synchronization, and improves state management using immutable
data manipulation and controlled access to shared resources (critical section problem)
The OpenLab web application is written in ClojureScript [9]. ClojureScript is a lisp dialect that compiles
to JavaScript for use in the browser. It features a simple syntax, immutable data structures, functional
paradigms and a rich set of useful data structures. The web application uses the re-frame [9] framework,
which is a reactive framework for writing SPAs in ClojureScript. It uses reagent [10] to interact with react
[11] for writing the user interface. Re-frame utilizes a unidirectional flow pattern for transforming user
actions into changes in the user interface through dispatching events. Events can either be pure or effectful.
Pure events alter the application state directly, while effectful events trigger a side-effect that might change
the state later. Examples of pure events are e.g., writing text into an input field or selecting a checkbox.
Effectful events can be loading content from the server by navigating to an URL or clicking a button.
SPE-195629-MS 11

Figure 11—The steps above describe the entire data flow from a user interaction triggering an event to be dispatched,
thereby altering the application state directly or through an effect, resulting in a re-render of the view using reagent/react.

The application state on the client acts as a single source of truth, that describes what should be rendered
by reagent to generate the correct user interface. Whenever the user performs an action in the user interface,
a new event is dispatched that results in a new immutable state. Having this unidirectional update flow
provides a unique application state representation for each processed event and makes it easier to inspect
and reason about the state of the application at any given moment. This helps reduce complexity as the view
becomes in a sense a parser for the current application state, resulting in a "dumb" user interface waiting
for user interaction, instead of having complex state and logic stored directly in the view.
Reagent utilizes react to render the user interface as html, using hiccup [12] notation, which is a simple
parser that translates ClojureScript data structures into valid HTML to be run in the browser. The OpenLab
application uses bootstrap 4 and custom styles written in sass [13] to style the application. Leiningen [14] is
used as the build pipeline, providing third party dependencies, code compilation and optimization, as well
as separating the development and production environment, where figwheel [15] is used in development
for live code reloading for instant feedback and error reports.

Application to Education
University of Stavanger
Lecture Topics. University of Stavanger (UiS) has 40 years of experience in offshore oil and gas production.
UiS is closely linked to industry, business and the public sector in the Stavanger region and actively
participates or leads research and educational projects in drilling and well design, increased oil recovery,
environmental issues, risk and safety, etc.
UiS currently offers a Master course in Drilling Automation and Modeling to all students in the Energy
and Petroleum Engineering Department (IEP). The course provides detailed knowledge of dynamic drilling
models and related drilling applications, data handling, management and analysis, control techniques and
systems in automated drilling operations.
The course also demonstrates laboratory-scale automated drilling systems and real-time drilling
operations using OpenLab. One higher-level course about advanced drilling technologies and methods
12 SPE-195629-MS

is also offered to all Ph.D. students at IEP. The course addresses various modern topics within well
technologies and introduces model-based and data-driven methods in drilling processes. It helps students
to enhance their understanding and promote research and development activities in designing drilling
programs, analyzing drilling problems, understanding aspects of the underlying mathematical models and
their application to automate the drilling process. In this context, OpenLab plays a very important role in
the study program at UiS.

Figure 12—OpenLab simulation setup at UiS

Ongoing research. Drilling today aims at realizing more complex wells, while keeping the drilling
operation costs low without compromising safety. Automated drilling uses a bundle of interconnected
dynamic models and real-time data to estimate current wellbore conditions and suggest efficient operation
of drilling machineries in order to drill wells in a safe manner. Drilling optimization is motivated by the
need to increase drilling efficiency, for instance, by maximizing the drilling speed while maintaining good
hole cleaning conditions and wellbore integrity simultaneously, or by detecting drilling incidents in early
phases and taking actions to avoid drilling problems.
One ongoing research project at UiS IEP funded by the Equinor Academia program focuses on the
utilization of model-based algorithms and data driven technologies in digital drilling fields for a better
optimization of the drilling process. Thereby, OpenLab is a powerful research tool to learn system dynamics,
validate models, analyze historical data and design drilling control algorithms.
SPE-195629-MS 13

How to introduce such a tool in education. Understanding and implementing advanced drilling systems
require students to have multi-disciplinary engineering knowledge and skills. However, a possible barrier for
individual development and adaption is the insufficient education background and fit-for-purpose training.
To promote highly innovative and advanced drilling technologies in the oil and gas industry, UiS aims
at graduating future energy and petroleum engineers with interdisciplinary engineering background and
practical experiences. To reach that goal students today should acquire:

• A good understanding of the drilling process,

• The ability to interpret and diagnose abnormal drilling conditions,

• Knowledge of prediction models, and their mathematical formulation,

• Familiarity with different software and relevant IT systems.

In summary, OpenLab provides a good visualization solution in drilling for teaching, training and
demonstration. It enables students and teachers to engage better in the learning process through the digital
teaching environment.
How does it answer the expectations?. Modern technologies require extensive prototyping before early
testing can even start. Introducing a new system requires significant upgrades across the entire platform
and may thus only be partially implemented because limited data exist on the benefits of performing a full
transition. It is very important and essential to have such an educational environment so the developed
strategies, methodologies and procedures of real-time drilling operations, e.g., Managed Pressure Drilling,
Dual Gradient Drilling, kick management, cuttings transport, can be easily tested with drillers’ actions in the
loop. In addition, it will help students develop and test novel solutions to challenges faced in the industry.
Suggestions for improvements. In collaboration with relevant international and national companies and
R&D institutions, we aim to explore and develop fundamental principles in focused areas to make significant
advance in a multi-disciplinary study program. OpenLab will be used for new BSc/MSc drilling courses
development and current MSc courses. Improvements to the simulator would be to include benchmark
examples from relevant field cases, data analysis tools, and APIs with physical rigs.

OpenLab at the University of Calgary

In the winter 2018 semester at the University of Calgary, OpenLab was introduced as a core component
of ENCH 689, Drilling Advances, Modelling and Simulation, and was used during lectures and for the
course project. The course was taught in the new Taylor Institute for Teaching and Learning and made
use of the next-generation collaborative teaching spaces housed within it. Rather than a traditional lecture
hall, classrooms are designed for collaborative group work – seating is around tables and students and the
instructor can share material onto TVs distributed throughout the classroom space – and integrated well
with the web-based capabilities of the OpenLab software.
14 SPE-195629-MS

Figure 13—The Taylor Institute for Teaching and Learning was completed in 2016 and houses
a variety of reconfigurable classrooms which focus on active learning and student experience.

Use in Lectures
During lectures, concepts were trialed by students on OpenLab after being introduced, particularly in the
section of the course focusing on wellbore hydraulics.

• Drillstring design: OpenLab’s ability to build complex bottom hole assemblies allowed students to
visualize a BHA and then see effects on hydraulics. Rather than just introducing cuttings transport
and stuck pipe scenarios, the students were able to interact with OpenLab and directly see the effect
of BHAs, drilling speeds and hydraulics on cuttings bed movement.
• Path planning: by allowing complex well paths, effects on hydraulics and hole cleaning could be
directly quantified. The version used did not have a full drillstring dynamics module implemented,
but once implemented, the effects of distributed torque and drag can also be directly visualized
and explored.
• Well control: OpenLab’s key strength is the fidelity of the multiphase hydraulics model, and it can
be put to excellent use to demonstrate the effects of pump starts on equivalent circulating density
(ECD), bottom-hole pressure, well influxes and procedures to circulate kicks out of the hole.

Final Course Project

Students used OpenLab to design and implement a closed-loop well kick detection and circulation system
using the MATLAB toolbox included.

Figure 14—Individual course components are integrated through the combination of the web based simulator
and the MATLAB API to develop a closed loop kick detection and circulation system which is tested
SPE-195629-MS 15

They began by manually simulating a well kick and then circulating it out using the Driller’s Method
or the Wait and Weight Method and then proceeded to write a controller in MATLAB. This controller was
able to detect a kick and then immediately initiate a circulation of the kick using their preferred method.
This project allowed them to fully understand the course material and bring everything together to create
an interactive software as the final deliverable. Every student in the class succeeded in developing the final
software and many remarked that OpenLab was integral to their understanding of the material.

Figure 15—By implementing the material learned in class, first by hand in the web-based simulator and second as
a series of MATLAB scripts, students achieve a deeper understanding of the process than just through lectures.

Future Perspectives
OpenLab will be deployed for the undergraduate drilling course, ENPE 515, in the 2019/2020 academic
year as a teaching tool. The course will consist of 20 to 30 third year engineering students and will be an
interesting experiment since this will be a larger class with less technical background training.

Research Applications
Machine Learning Research
OpenLab also presents opportunities in building machine learning models used towards both classification
of drilling process anomalies and prediction of drilling time series data. In recent years, machine learning
techniques have become increasingly popular in various drilling automation and monitoring systems [16].
Most of these systems do not consider the underlying physics of the drilling process in the development
and training of machine learning models. Hybrid models which combine both physical knowledge and
machine learning algorithms (e.g., [2], [17]) can often outperform purely data-driven ("black-box") models.
More recently, advanced deep learning algorithms have been successfully used for building computationally
efficient models capable of representing intricate features in drilling time series [18]. Therefore, a mix of
deep machine learning with physics-based process modelling seems to be the path forward for intelligent
drilling advisory systems.
As a preliminary case towards development of a machine learning-based diagnostic tool enhanced by
physics-based drilling process models, we consider the problem of downlinking a Rotary Steerable System
(RSS). The downlinking operation can result in standpipe pressure (SPP) signatures which seem abnormal
at a first glance, particularly when a valve is used to divert part of the flow going into the drill string in order
to obtain a variable flow rate pattern above the RSS. In the latter case, the pump rate remains constant, with
SPP being the only surface indicator of downlinking. As a result of this discrepancy, data analytics software
could erroneously diagnose the downlinking as abnormal behavior, causing confusion among the drillers /
monitoring personnel, at the very least. Even worse consequences may follow if a machine control system
16 SPE-195629-MS

uses the quickly oscillating SPP measurements as feedback (e.g., for an auto-driller or choke controller).
Therefore, having a machine learning-based tool for automatic recognition of downlinking from surface
data can be of high value to drilling automation and data analytics.
While automated downlinking sequences are quite repetitive, the amplitude and frequency of the resulting
pressure signatures can vary widely based on equipment specifications, mud properties (density, rheology,
compressibility), well depth, etc. Field data sets containing downlinking signatures covering a wide range
of shapes and durations may be difficult to obtain and, furthermore, processing this data for the purpose
of training machine learning models can be quite labor-intensive. On the other hand, OpenLab can be
quite effective at generating representative synthetic data sets for training machine learning models. The
training set should ideally include several downlinking events in addition to pump start / stop routines,
and other sources of partial pressure drops or build-ups (e.g., washout / pack-off events) which need to be
differentiated from actual downlinking signatures. Model training can take place off-line or in real-time
using the communication API.
In the present study, OpenLab was initialized with the configuration of a 2500 m MD offshore well with
an 8.5-inch (0.216 m) hole section. A 1.65 sg oil-based mud with yield-power law rheology was selected.
The simulation, defined programmatically through the Python client, starts by ramping up the pump from
zero to the set point flow rate of 2500 l/min. The pump is then ramped back to zero and the sequence is
repeated. Two identical downlink sequences are generated at 1000 s, and 2000 s, respectively, by quickly
ramping the pump up and down by 500 l/min at 20-second intervals. Towards the end of the simulation,
the pump set points are gradually reduced to allow for a wider range of normal operation SPP signatures.
Figure 16 below shows snapshots of the flow rate and SPP time series generated by the simulation.
The SPP time series is used to train the machine learning models. To optimize model training and reduce
overfitting, the SPP data is normalized to a 0-1 scale based on the maximum value (see Figure 17). A binary
label indicating whether downlinking is taking place (1) or not (0) is assigned to each data point, making
the data set suitable for supervised learning models. The training data set is then split into intervals of 30
consecutive time samples which are used as input to the machine learning models. The OpenLab simulation
outputs were generated assuming perfect data quality, however they can be easily manipulated outside of
the simulation to include measurement artifacts, such as random noise, data gaps, or transmission delays,
which would allow for more realistic representation of actual drilling data.
We have focused on three types of machine learning models: Support Vector Machine (SVM), Artificial
Neural Network (ANN), and Convolutional Neural Network (CNN). More details on the model architecture
are provided by [19]
SPE-195629-MS 17

Figure 16—Flow rate (top) and SPP (bottom) from the OpenLab simulation.
Downlinking sequences occur around 1000 and 2000 seconds in the simulation.

Figure 17—SPP training data (scaled by the maximum SPP from the simulation) and associated downlinking labels [19]

The field data set used for validation consists of 28 downlink sequences from the 12.25-inch (0.311 m)
hole section of a North Sea well drilled with a 1.35 sg oil-based mud. A flow diversion system was used
for downlink generation, which motivates the use of a model taking only SPP time series data as input. The
predictions of the machine learning models on the field data set are summarized in Table 1 below.

Table 1—Summary of downlinking prediction results on the field data set [19]. Precision and recall are computed as TP /
(TP + FP) and TP/(TP + FN), respectively, where TP are true positives, FP are false positives and FN are false negatives.

TP FP FN Precision Recall

SVM 28 4 0 0.875 1.0

ANN 28 2 0 0.933 1.0

CNN 28 0 0 1.0 1.0

While all models demonstrated high precision and recall on the field data set, several false positives were
reported. These could be attributed to unaccounted variations in fluid properties (e.g., drilling fluid density
and rheology) or the presence of hole restrictions / enlargements, drill string leaks, and unmodeled downhole
tools within the field data set [19]. These issues can be mitigated by augmenting the OpenLab-generated
data with field data to obtain more comprehensive training data sets. Input feature scaling is also critical
to the model’s ability to generalize, and more advanced scaling methodologies can be used, for instance
through physics-based dimensional analysis or statistical techniques.
18 SPE-195629-MS

Development and Testing: Drilling Data Hub

Drilling automation systems commonly rely on an extensive set of real-time signals: measurements are
typically used for continuous analysis of the drilling system state, while machinery information is used
for active control of the different drilling parameters. As per today, there exists no standard mean for the
distribution of the different signals: ad-hoc solutions need to be implemented for every single rig.
Standard solutions such as WITSML do not capture the full context of the measurements, which
unfortunately makes it difficult for automation systems to become self-configuring systems. The lack of
semantics proves in practice extremely difficult to properly identify and understand the various available
signals: advanced automation solutions require indeed a precise description of the different measurements.
For example, a hook-load should be interpreted differently depending on where it is measured: at the top-
drive, dead-line or crown block.
Finally, if one wishes to achieve interoperability between the different actors in the drilling process, every
data consumer should be able to automatically detect and identify the drilling data it needs to run properly,
without the need for human configuration. The goal of the Drilling Data Hub (DDHub) project [21] is to
enable seamless integration between automation components by introducing a semantical description of the
available drilling data. Since cooperation between various systems is at the heart of this project, a common
platform for data generation and exchange is of primary importance for both the development and testing of
the semantical model. The OpenLab Drilling infrastructure provides the adequate environment for this task.
From the DDHub project perspective, OpenLab acts as a simulator for drilling operations. It provides
a certain set of signals that vary based on certain control signal setpoints. This solution makes it possible
for a control algorithm to exploit the semantical model of DDHub to discover, acquire and update signals
of interests provided by an OpenLab simulation. A typical scenario would be to automatically discover the
stand pipe pressure signal, the maximum pressure and the set point signal to control the pump flow rate.

Figure 18—DDHub acts as a hub for information exchange between drilling data consumers and drilling data providers. The
information exchange is made possible by sharing a semantical representation of information that is relevant for real-time
SPE-195629-MS 19

Figure 19—A small part of a larger model (semantical network). A typical case would be to
link values such as Stand Pipe Pressure (SPP) and Flow rate set point (FlowRateInSetPoint)
to OpenLab drilling simulator to provide a realistic feedback control scenario

For future work, the project aims at representing the complete set of signals that OpenLab provides using
the DDHub semantical model.

Industrial Experience
Maersk Drilling Experience
Maersk Drilling sees excellent potential in running simulations of downhole behavior. The uses we have
identified are within:

• Testing and calibration of predictive algorithms

• Training of drill crews to understand the effects of changing parameters in various drilling scenarios

• Illustration of and preparation for well behavior before drilling a new section

• Providing "what does good look like" data and illustrations to the Driller before performing various
operations
• Presentation/learning tool of a drilling process for our colleagues without offshore practice

The use of the OpenLab Drilling solution will support our ambition to reduce ‘Operator Non-Productive
Time’ through a proactive approach to avoiding downhole problems such as insufficient hole cleaning and
well control incidents.
Our experiences with the web interface of the OpenLab Drilling are very positive. The solutions offered
so far are very user-friendly and easy to navigate. They allow for a broad configuration of simulations.
The results of simulations are presented as a vast selection of graphs covering the most important drilling
parameters. These graphs are easily adjusted to user-specific needs (e.g., scale, units), which we like very
much. Control of dynamic parameters in simulations (e.g., ROP) was also straightforward for us. We have
not had any significant problems with setting up and starting our first simulation thanks to the documentation
and some predefined configurations. What also has helped us is that the framework indicates mistakes in
20 SPE-195629-MS

a user configuration. During simulation runs, we have experienced that the log info of the crash of the
simulations has not provided a clear message on why that has happened. That made it harder for us to
improve our simulations.
We have also used the Python interface to connect with the OpenLab Drilling infrastructure to run
simulations. This solution allowed us to better interact with the simulations. This framework can be used
to run the software which controls the dynamic parameters of the simulation and adjust them during
the execution. We also used the Python interface to run a set of simulations with a pre-defined list of
configurations. We have not observed any significant changes in the speed of simulations between the web
client and the Python framework. In both solutions, we have experienced a speed of three simulation steps
per second. In our opinion, the Python framework would benefit from a better way of managing updates. We
see two potential solutions here, full integration with the pip package management system, or by opening
the Git repository. Those solutions would help users to better track changes and updates.

AkerBP Experience
OpenLab is a very valuable tool that can help Aker BP in its continuous pursuit for improvement. The
drilling industry is still quite conservative, and efforts are being made to increase efficiency through
digitalization.
The OpenLab simulation environment can be used for training and building the competence of the drilling
crew, especially when it comes to new automation layers being added in the drilling control system or
different applications adding new functionality to the drilling operations. Another valuable side of using
OpenLab is that it enables us to solve problems through the "trial and error" method, and at the same time
assess and improve our work processes.
Our plans are to use OpenLab for development of new products and technology. One example can be
the integration of an OPC-UA [22] server with the OpenLab simulator. In such case, OpenLab provides
simulation data, such as surface and downhole data related to the drilling process, and at the same time
it can receive set points like flow rate, rotational and axial velocity. This combination gives an excellent
testing environment for monitoring and control via an accepted industry standard (OPC-UA), and will be
beneficial to our development projects towards autonomous drilling.
In addition, what makes OpenLab very attractive is its accessibility through the web interface. The web
API facilitates the development of projects that Aker BP is running together with our alliance partners
that are located at different locations outside Norway, by offering remote access to a drilling simulation
environment. This could prove to be very cost efficient for our digitalization projects.
The flexible and configurable web interface offers the possibility to develop downhole models used
for well protection, proactive protection for drilling problems and optimization of drilling operations.
Having the possibility to test the new functionality at an early stage is crucial for the success of our
digitalization projects. And equally important is to be able to test our systems before moving to operations.
Both continuous and final testing can be performed in OpenLab.
Finally, OpenLab as a simulator allows us to assess the level of complexity of the wells before we drill
them. It makes it possible to understand the dynamic well behavior in difficult well sections and use that
knowledge to change the way we plan and drill our complex wells.

Conclusions
This paper has presented OpenLab as being a modern infrastructure for education, research, development,
and testing of new drilling technology. The key features of the OpenLab infrastructure are user friendliness
and high-fidelity simulation models. OpenLab is easy to use because it was designed and developed with
user friendliness as part of the development process. The high-fidelity simulation models are the result of
several years of physical modelling, development and testing.
SPE-195629-MS 21

Targeting education has been achieved and tested with the University of Stavanger and the University
of Calgary with very satisfactory results. Research and innovation using OpenLab are ongoing activities as
witnessed by the Drilling Data Hub project which is already using the infrastructure for real-time drilling
process automations. Another research activity is witnessed by an early study in machine learning methods
and their applications in anomaly detection. OpenLab has also shown to be very close to industry visions
and can serve as a tool for early testing of new drilling automation systems.
The next phase of the project will be to extend OpenLab to field data integration. Recorded drilling data
made available for education and research can then be uploaded and distributed through OpenLab in a safe
and efficient manner.

References
1. E. Cayeux, B. Daireaux, E. Dvergsnes, A. Leulseged, B. Bruun and M. Herbert, "Advanced
Drilling Simulation Environment for Testing New Drilling Automation Techniques," in IADC/
SPE Drilling Conference and Exhibition, Amsterdam, 2013.
2. P. Pournazari, P. Ashok, E. van Oort, S. Unrau and S. Lai, "Enhanced Kick Detection with Low-
Cost Rig Sensors Through Automated Pattern Recognition and Real-Time Sensor Calibration," in
SPE Middle East Intelligent Oil & Gas Conference & Exhibition, Abu Dhabi, UAE, 2015.
3. E. Cayeux, B. Daireaux, E. W. Dvergsnes and F. Florence, "Toward Drilling Automation: On the
Necessity of Using Sensors That Relate to Physical Models," in SPE 163440. SPE/IADC Drilling
Conference, Amsterdam, 2013.
4. NORCE, "OpenLab," NORCE, 2018. [Online]. Available: https://openlab.app/.
5. R. Lorentzen, Higher Order Numerical Methods and Use of Estimation Techniques to Improve
Modeling of Two-Phase Flow in Pipelines and Wells, Doctor thesis, University of Bergen, 2002.
6. R. T. Fielding, Architectural Styles and the Design of Network-based Software Architectures,
University of California, Irvine, 2000.
7. [Online]. Available: https://en.wikipedia.org/wiki/Single-pageapplication.
8. F. P. Brooks, "No Silver Bullet Essence and Accidents of Software Engineering," Computer, pp.
10–19, 1986.
9. U. J. F. Aarsnes, F. Di Meglio, O. M. Aamo and G.-O. Kaasa, "Fit-for-purpose Modeling for
Automation of Underbalanced Drilling Operations," in SPE/IADC Managed Pressure Drilling &
Underbalanced Operations Conference & Exhibition, 8-9 April, Madrid, Spain, 2014. [9]
10. [Online]. Available: https://github.com/Day8/re-frame.
11. [Online]. Available: https://github.com/reagent-project/reagent.
12. [Online]. Available: https://reactjs.org/.
13. [Online]. Available: https://github.com/weavejester/hiccup.
14. [Online]. Available: https://sass-lang.com/.
15. [Online]. Available: https://leiningen.org/.
16. [Online]. Available: https://figwheel.org/.
17. C. Noshi and J. Schubert, "The Role of Machine Learning in Drilling Operations; A Review," in
SPE Eastern Regional Meeting, Pittsburgh, Pennsylvania, 2018.
18. P. Andia and R. R. Israel, "A Cyber-Physical Approach to Early Kick Detection," 2018.
19. Y. Yu, S. Chambon, Q. Liu and J. Belaskie, "Recorded Well Data Enriches the Testing of
Automation Systems by Using a Deep Neural Network Approach," in SPE/IADC Drilling
Conference and Exhibition, Fort Worth, Texas, 2018.
20. A. Ambrus, N. Saadallah, S. Alyaev and F. Iversen, "Automatic Detection of Anomalous Drilling
Operations Using Machine Learning Methods and Drilling Process Simulations," Oil Gas
European Magazine, 2019.
22 SPE-195629-MS

21. E. Cayeux, B. Daireaux, N. Saadallah and S. Alyaev, "Toward Seamless Interoperability Between
Real-time Drilling Management and Control Applications," in SPE/IADC Drilling Conference
and Exhibition, Hague, 2019.
22. OPC Foundation. [Online]. Available: https://opcfoundation.org/.
23. R. Rommetveit and E. Veffing, "Comparison of Results from and Advanced Gas Kick Simulator
with Surface and Downhole Data From Full Scale Gas Kick Experiments in an Inclined Well," in
SPE Annual Technical Conference and Exhibition, Dalla, 1991.