OTC-28805-MS

Big Data in the Digital Oilfield Requires Data Transfer Standards to Perform

Philip Neri, Energistics Inc

Copyright 2018, Offshore Technology Conference

This paper was prepared for presentation at the Offshore Technology Conference held in Houston, Texas, USA, 30 April–3 May 2018.

This paper was selected for presentation by an OTC 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 Offshore Technology Conference and are subject to correction by the author(s). The material does not necessarily reflect any
position of the Offshore Technology Conference, its officers, or members. Electronic reproduction, distribution, or storage of any part of this paper without the written
consent of the Offshore Technology Conference 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 OTC copyright.

Abstract
The digital oilfield is evolving with the number of sensors and measuring devices and the frequency of data
sampling both increasing dramatically, which is the onset of what is commonly referred to as Big Data.
These increases are needed as the motivation for the collection and transmittal of data has moved from the
remote observation of operations to the remote operation of increasingly automated systems, as well as the
goal of reliable prediction tools that improve efficiency.
A lot is written and discussed about how to handle Big Data in the context of data management and
analytics. However, the task of transferring the digital information from the field to the back office is critical.
This is built on advances in standards for data formats, metadata and transmission protocols that have
been published to support the digital oilfield of the future. The first advance has been the larger amount of
metadata, providing detailed information on the data source's characteristics, eventual transformations to the
data (by who, using what tools, etc.) and prior vetting. The second one is to replace transmission protocols
based on polling different servers with streaming processes that do away with inefficient interrogation,
handshake and packaging overheads.
The implementation of these improved standards allows operators to build solutions that involve different
vendors. A test was put in place involving an active North Sea drilling operation, with data being transferred
to onshore observers both at the operator's facilities and on the premises of a service provider. Data was
streaming on to the screens of both observing parties less than one second after the event took place on
the rig. This compares to lag times of 15 to 20 seconds using polling methods. The bandwidth usage was
approximately 1/10 compared to previous methods, such that more sensors could be added to the data
transmittal.
With more immediate access to a much broader and richer set of data both at the operator's facilities
and also at the premises of many contractors, service providers in particular could make more educated
assessments of developing situations on the rig, which in several cases avoided the need for a team to go to
the offshore rig, thus reducing the number helicopter flights to the offshore installations and accounting for
fewer people-on-board (POB), which contributed to lower HSE exposure and lower costs.
2 OTC-28805-MS

Introduction
There is no doubt that the oilfield of tomorrow will embrace digital technologies on a much larger scale
than is currently in place. In many ways, the upstream industry has been relatively slow in embracing the
concept of digital transformation, and even more cautious at deploying such technologies on a large scale.

Industry environment
The delay in digital adoption and deployment can to some degree be attributed to the dynamics of the
industry. In the years leading up to 2014, the focus of most upstream activity was geared to upscaling existing
and known technologies under the pressure of ever-larger projects, more of everything and a plentiful
availability of experienced staff knowledgeable of how things worked. Following the collapse of the oil price
in 2014 and the ensuing "low for longer" economic environment, a lot of interest has gone into designing
and strategizing new ways of performing more efficiently and at lower cost the many tasks from exploration
to production, but few resources have been available to fund and stage large-scale deployments. The crew
change that was in the air prior to 2014 is now in full swing (Ernst & Young 2016). It is compounded by
the early retirement of many in the workforce during the 2015 – 2017 downsizing. In hiring again, there is
reluctance to take back expensive expertise, and the momentum instead is focused on the hiring and training
of the new generation. While there is a lot of talk about digital transformation, there has therefore not been
much lead time or the capacity to invest in the tools, the infrastructure and the training that would underpin
such an ambitious project.

A trend towards more collaboration

The way forward towards a broad deployment of digital technologies from the drilling rigs, producing
assets and data acquisition crews to the offices of operators, service providers and government oversight
institutions will by necessity involve many actors. No single service company has a truly compelling cradle-
to-grave solution that the industry could embrace; no software development company has a platform and
suite of products that address all the industry's needs; operators need to work with a diversified software
portfolio and interact with a number of service companies for each project or asset.

Standardization
There is nothing radically new with this diversified and interconnected way of operating in upstream.
However, when digital technology is introduced into the mix, and the stated goal is to have digital replace
many staff positions while automating systems, moving monitoring and control functions to centralized
control rooms and providing new means of predicting and handling risk, there is an implicit requirement to
have a more rigorous handling of information flows.
This staff rationalization removes, among others, the resources previously dedicated to sending, receiving
and cross-checking information and data. The escalation in data volumes would preclude this activity
anyway, but in practice it has always been a very tedious, time-consuming and error-prone operating process
even before data quantities made it unrealistic. This underscores the need for data to flow rapidly, and also
an absolute necessity to ensure that data is not corrupted or stripped of critical descriptive information along
the way. Only well-defined and properly implemented data transfer standards offer the framework within
which such a goal becomes feasible.

The critical role of metadata

In the past metadata, "the data describing the data", was always nice to have, but not always indispensable.
With many human actors supervising a relatively small amount of data feeds from known sources, one
could often do without metadata because there were few changes in the nature of the data sources and
OTC-28805-MS 3

there was ample human resources, experience and time to analyze and verify specifics to qualify a block of
data measurements. Multiply the number of data sources by 10, 100 or more, increase the sampling rates
by orders of magnitude, assume that data is feeding in from multiple locations serviced most probably by
different companies using a diversity of equipment, and the paradigm shifts dramatically. The metadata
must convey enough information such that the measurements can be "consumed" without doubt and with
deterministic knowledge as to their inherent characteristics and reliability.

Specifying standard metadata items

An open process was followed, the same one used to evolve the data transfer standards for drilling
data (WITSML), production data (PRODML) and reservoir model and interpretation data (RESQML),
using the special interest groups for these formats to collegially develop the specifications for metadata
(Hollingsworth and Schey 2017). In addition to the obvious descriptive metadata items that provide
information on the measurements or device status, such as depth, datum, temperature(s), location, etc., other
more elaborate metadata groups were also included. One of them embodies a set of rules and associated
information on whether the data has met the criteria of a given set of rules. These rules could be industry-
mandated or company-specific. Another group of metadata allows for the inclusion of a record of all
the processing and editing activities that may have been performed on the data prior to its transfer, with
information on the timing, the nature and description of software tools used, and the person or persons who
performed these activities.

Big Data
One of the main benefits set forth in arguing for a broad adoption of big data is the potential to bring
together data from many different sources and apply analytics, artificial intelligence and machine learning
techniques to identify trends, correlations and ultimately predictions regarding many aspects of upstream
activity. Without a proper standardization of data entering the systems, one would be exposed to the risk of
mixing together data with different attributes, rendering the outcome of the process less trustworthy. The
addition of standardized metadata would further enhance the reliability of big data initiatives by allowing
for the weighting of datasets based on their adherence to specific norms, or not.
When addressing big data, the data volume aspect also comes into play. This in turn becomes a matter
of bandwidth and the ability to move a very large number of channels of data emanating from continuously
recording sensors or measurement devices towards a central facility, be it in the cloud or on designated
servers deployed by an operator or service company.

Transfer speed
Most remote data transfer systems rely on a very reliable and flexible process, Simple Object Access
Protocol (SOAP). It operates by polling on a regular basis a number of designated servers and requesting
any new data conforming to a specific type, such as the LWS reading that would have been recorded on a
rig-based server. SOAP has a lot of overhead such that the data bundles that are sent from the rig on request
arrive 10 to 15 seconds later at the central facility. That delay time assumes an excellent communication
connection such a fiber optic, a slower connection would add lag to that delay. In addition to the delay
handicap, a significant multiplication of channels of data being transferred concurrently would add a lot of
overhead to the transfer infrastructure.

Streaming data
A new protocol was designed and codified through an industry standard process. It operational process is
much more streamlined compared to SOAP, and can be compared to on-demand video streaming services.
4 OTC-28805-MS

Instead of a burdensome and repetitive request for data, it establishes a path for data to stream from the
point of origin (the measuring or sensing device) and the receiving server. Once the stream is initiated it will
continue to push data until the process is suspended or terminated, and during streaming no further action is
required from the receiving server to request further data. The stream can also be directed to more than one
end-user, for example a LWD data feed could be going simultaneously to the operator's real-time center, to
a partner in the acreage's own facilities, to the operational base of one or more of the contractors actively
engaged in the drilling activity, and even to a government agency's oversight team. Tests did not indicate
any loss of transfer speed related to the multiplication of receivers.
This new and different approach to transferring and sharing data is much more efficient in terms of
the use of available communication bandwidth. While some facilities may benefit from high-bandwidth
communications through sea-bottom fiber optic, further from shore or in areas with thin infrastructure the
data transmissions are effected over satellite communication systems where bandwidth is both limited and
very costly. Where a single data feed may have been all that was possible on a continuous basis during
drilling using SOAP, multiple feeds are possible using the streaming method. Tests have indicated that the
bandwidth usage of streaming is 1/10th of what is observed with the usage with SOAP.

Impact on task localization

Returning to the purpose of the transmission of data from an offshore rig to a centralized onshore location,
three factors drive this:
– The need to rapidly put a number of expert eyes in front of data as and when operational situations are
developing: it would not be realistic economically to have permanently on the rig expert engineers to
address events that occur only from time to time in the course of the months of drilling an offshore
well.
– There is an increased scarcity of experienced staff, and modern trends towards applied analytics, the
deployment of machine learning and artificial intelligence systems increases the spread of disciplines
needed to mine incoming data for insights into operational improvements and prediction.
– The broader goal of reducing the number of roles that require a human presence on the rig: with
headcounts close to 150 persons at any one time, the overheads of logistics to make them available
on the rig (training, clothing, helicopter transport, rotations) as well as the cost of being on the rig
(accommodation, food, safety equipment, etc..), totaling 2,650k for the drill crew and k$570 for
helicopter services for 100 days, see Figure 1. These costs escalate for offshore activity in locations
further from dense infrastructure and the staff's home base.

Figure 1—Costs for a 100 day offshore drilling project 2014 (EIA - IHS 2016)
OTC-28805-MS 5

Case study of comparative use of SOAP and streaming protocol

A North Sea operator that has been using SOAP-based remote drilling data transfer for many years worked
with their data collection, transmission and delivery contractors to put in place a comparison of the time lag
and continuity of data arrival between a conventional SOAP-based set-up, and one using the new streaming
protocol. The source, in this case a feed of LWD from active wells developing a field in the North Sea. The
transmission lines are very high bandwidth, so delays due to that infrastructure are not significant.
The process involves a drilling rig where the data is collected and fed into a server. A contractor base
onshore hosts a server that can hold data in transfer. Another contractor operated a drilling monitoring
system at the customer's premises on another city. To get data onto the screen at the customer, the monitoring
system issues an SOAP request to the contractor onshore server, which in turn makes a SOAP request to
the server onboard the drilling rig. All new data not previously transferred and buffered onto that server is
then passed to the onshore server, which in turn send the data package to the monitoring system, where it
is displayed by the software.
The viewing experience for this data is degraded by the fact the data arrives in packages, and by the
lag inherent to the SOAP protocol, resulting in 5 to 10-second-long blocks of data appearing periodically
with a lag of 15 to 20 seconds for the most recent measurement. The data itself in this case was sampled
once a second.

Test with the streaming protocol

The server on the rig was updated to operate using the new streaming protocol (McKenzie et al. 2016), and
a different onshore server was set up to receive the data and pass it on to the server at the customer site,
both onshore systems being installed with the new protocol as well. In this set-up, the software displaying
the data at the customer site is unchanged.
The new protocol is initiated with the request from the customer site server to connect via the onshore
contractor server to the server on the rig that is recording the LWD data. On receiving that instruction, the
rig-based server starts instantly passing on to the customer site every sample of data arriving from the LWD
device. Each data sample is displayed on the customer's screen as soon as it arrives. The process continues
until the receiving server issues a command to pause or terminate the process.
The viewing experience is greatly improved. The data is arriving continuously and displaying in a manner
practically identical to what an observer looking at the data on the rig would see. The lag time was in the
order of 1 second, very close to real-time and a vast improvement on the 10-20 second lag of the SOAP
process.

Beyond the comparative test

To ensure a fair comparison, the steaming test was also sampled at a rate of one sample per second. However
the protocol allows for sampling rates at least 50 times higher, while using a 1/10th of the bandwidth of
SOAP, delivering not just more data but more finely sampled data if needed.

Operational benefit
The role of the customer monitoring center is to analyze the data feeding in from the rig to detect anomalies
and trends in the data that could lead to either an escalating issue with safety or integrity for the well, or a
drift from the plan that could end up compromising achievement of the well's target. With the high cost and
bearing in mind the critical objectives of the wells being drilled, the operational model was to dispatch by
helicopter a contractor remediation crew if any doubt was raised relative to those concerns.
During the period that the new streaming protocol was deployed, the number of helicopter dispatches
was significantly lower, as the experts reported increased confidence in their analysis of the data streaming
6 OTC-28805-MS

in, allowing them to more assertively reach a conclusion about perceived issues identified in the incoming
data. This in turn resulted in operational savings and a reduced HSE exposure of contractor staff.

Conclusions
The case has been made that the relevance and success of Big Data initiatives in the upstream oil & gas
industry is predicated on a broad adoption of data transfer standards to ensure that analytics and automation
are using a uniform set of data that is properly formatted, scaled and referenced. The introduction of rich
metadata involves an initial effort to instrument software to collect the relevant information, but this effort
is more than compensated by the increased validation of the data being transferred and used, as well as
reducing the human effort involved in repetitively re-verifying data, as happens too much today.
A radically new data transfer protocol also affects the aggregation of data, allowing more detailed
sampling rates, faster and more continuous data transfer, multiple concurrent receivers and the possibility
of adding many more channels of data using a given transmission infrastructure.

References
Ernst & Young, 2016 Recruiting during a downturn: http://www.ey.com/Publication/vwLUAssets/ey-recruiting-during-
a-downturn/$FILE/ey-recruiting-during-a-downturn.pdf
EIA - HIS, 2016. Upstream Cost Study https://www.eia.gov/analysis/studies/drilling/pdf/upstream.pdf
Hollingsworth, J. and Schey, J., 2017, From Data Transfer to Data Assurance: Trusted Data is the Key for Good Decisions
http://www.energistics.org/Assets/pnec2017paperjayhollingworthenergistics.pdf
McKenzie, W., Schave R., Farnan M., Deny, L., Morrison P., Hollingsworth J., 2016. A New Communications Protocol
for Real-Time Decision Making, 181088-MS SPE Conference Paper 2016