drilling data hub

Drilling Data Hubfor Real-time Drilling Applications

NorTex Data Science Cluster Workshop, OTC 2018

Fionn Iversen, IRIS

Outline

1.IRIS background

2.Challenges for RT applications

3. Semantic Data Model

4. Example case

5. Signal types

6. DDHub development

7. Conclusions

IRIS

• Key R&D infrastructure• Full-scale test-rig

• OpenLab Drilling simulator (twin)

• History• Nearing two decades of development of

real-time drilling applications

• Automation

• Monitoring

• Advisory

Challenge for real-time applications

Drilling Control System

Measurements

Downhole Measurements

Mud logging

Wired Pipe ASM

Mud properties

✓ Ok for log display

Historian logging

X Difficult to use for realtime calculations

1. Need for dynamic capability - Hardware changes- Accessing the right data at the

right time

2. Correct data input and application

Current data communication• No time synchronization

• Unknown latency

• Data coming in chunks

• Different refresh rates

• Mnemonic jungle

• Unknown origin of measurement

• Unspecified corrections if any

• No information about accuracy

• No information about validity

9. mai 2018

Examples1. New data source available

• Scenario: a short time after the mud pumps are started, wired pipe telemetry is brought to life

• New traces are added to the WITSML log object, and it is necessary to perform a manual mapping of the WITSML signals for hydraulics applications to be aware

2. Extraordinary configuration

• Because there is not enough flow to clean the hole, the cement pump is also used to pump in the well• Manual configuration would be required to inform the a hydraulics application that the cement pump is pumping into the

well

3. Choosing the best relevant signal

• An application requires a hook-load measurement from a draw-works hoisting system

• The application shall perform in-slips detection based on hook-load• The application can interpret loads and forces

• If the best suited signal becomes invalid, the application shall switch automatically to using the next best signal

9. mai 2018

Data semantic model

▪ Describes the meaning of its instances. ▪ Defines how the stored data relate to the real world.▪ Enables parties to the information exchange to interpret meaning

(semantics) from the instances, without the need to know the meta-model.

• DDHub semantical data model:• Defines precisely the meaning of every signal such that a consumer

application can discover the significance of each signal and correctly choose between signals of similar nature with respect to application.

9. mai 2018

SP

E D

SA

TS

eff

ort

9. mai 2018

Rig Information Model

Acknowledgement Hans-Uwe Brackel, SPE DSATS and BHGE

Objectives

Aggregate real-time information from multiple sources:• To address problems at the “drilling process management level” (not at the detailed machine management level)• To allow consumer applications to perform inferences on drilling real-time signals that are semantically described in the aggregation

server

Machine DAQ#1

Machine DAQ#2

Machine DAQ#3

Machine DAQ#4

Machine DAQ#5

Drilling machine Service #1

Drilling fluid service#2

Downhole Service #3

DD-Hub

Individual machine control and management

Individual service control and management that do not need inter-communication

Drilling process control and management

Drilling process management #1

Drilling process management #2

Example use case

Use case #1• An application requires a hook-load measurement from a hoisting system based on a draw-works• The application is interested in getting the measurement that is taken as close as possible to the top

of drill-string when the string is not in-slips• The application wants to manage itself in-slips detection based on hook-load• The application can both interpret loads and forces• If the best suited signal gets invalid, the application can switch automatically to the next best signal

What kind of semantic model can support this type of inferences?

Value Real-time value

Le

ge

nd

TAG1234: 49800

Realtime value

Quantity: [M]

Meaningful: 10

Value: 49800

Instance of a classInstance of


Class Data class

Le

ge

nd

Quantity

Mass

Properties of a Quantity• Physical quantity: undefined• Meaningful precision: undefined• Value

Properties of Mass• Physical quantity: [M](kg)• Meaningful precision: 10

More specialized

More generalized

A class defines the characteristics and behavior of similar entities

An instance of a class is a specific entity

Instance of a classInstance of


Class Data class

Le

ge

nd

Quantity

Mass

Properties of a Signal• Time stamps: measured, acquired• Refresh rates: constant, variable• Physical quantity:

Signal

Measurement Estimated Value Set-point Command Reference Parameter

Additional properties of a Measurement• Uncertainty: accuracy and precision• Validity:

Time-Stamp Measured: 20180222 09:57:23.45

Refresh interval: 0.050

Uncertainty: (200, 100)

Valid: True

Quantity: [M]

Meaningful: 10

Value: 49800

Notation simplificationInstance of


Class Data class

Le

ge

nd

Time-Stamp Measured: 20180222 09:57:23.45

Refresh interval: 0.050

Uncertainty: (200, 100)

Valid: True

Quantity: Mass

Quantity: [M]

Meaningful: 10

Value: 49800

Or even shorterClass: Measurement

Quantity: Mass

Value: 49800

Quantity

Mass

Signal

Measurement Estimated Value Set-point Command Reference Parameter

Transformation

Force To Load

Signal

Measurement

Transformed Measurement

Direct Measurement

Estimated Value Set-point Command Reference Parameter

Instance ofValue Real-time value

Class Data class

Le

ge

nd

Function Transformation

Transformed to

Input toTransformation

• A transformation specifies the inputs and the output

• A transformation does not do effectively the mathematical operation, instead it describes the relationship between inputs and the output

Quantity

Mass Force

Class: Force To Load

Class: Direct Measurement

Quantity: Force

Value: 488538

Class: Transformed Measurement

Quantity: Mass

Value: 49800

• Some measurements are direct, others are transformed from one or several signals

ParameterInstance of


Class Data class

Le

ge

nd


Transformed to

Input to

Depend upon

• Not all signals are measurements as there can be parameter, i.e. a value that can change but not so often

• A transformation may depend upon some configuration parameters

Signal

Measurement


Direct Measurement


Transformation

Force To Load

Quantity

Mass Force Acceleration



Quantity: Force

Value: 488538


Quantity: Mass

Value: 49800

Class: Parameter

Quantity:

Acceleration

Value: 9.81

Mechanical element

Top-drive

Top-drive Body

Active Element

ElevatorTop-drive

shaft

Drill-string

top of drill-string

Class: Top-drive body

Class: Top-drive shaft

Status: Connected

Position in a logical circuit


Class Data class

Le

ge

nd


Transformed to

Input to

Depend upon

Logical elementState

Connected to

Logically positioned at

• To infer what a signal is related to, we define its position in a logical circuit

• The logical circuit can be hydraulic, mechanical, heat transfer or machine oriented

• A logical position in a circuit can have a state

• When applicable, change of states are managed

• Now we can deduce the meaning of the two measurements

Signal

Measurement


Direct Measurement


Transformation

Force To Load

Quantity


Class: Elevator

Status: Not Connected

Class: top of string



Quantity: Force

Value: 488538


Quantity: Mass

Value: 49800

Class: Parameter

Quantity:

Acceleration

Value: 9.81

Mechanical element

Top-drive

Top-drive Body

Active Element

ElevatorTop-drive

shaft

Drill-string

top of drill-string

Class: Top-drive body

Class: Top-drive shaft

Status: Connected

Position in a logical circuit

Signal

Measurement


Direct Measurement


Transformation

Force To Load

Quantity


Class: Elevator

Status: Not Connected

Class: top of string



Quantity: Force

Value: 488538


Quantity: Mass

Value: 49800

Class: Parameter

Quantity:

Acceleration

Value: 9.81


Class Data class

Le

ge

nd


Transformed to

Input to

Depend upon

Logical elementState

Connected to

Logically positioned at

Logic op. Validity condition

Conditioned by

Is True

• The validity of a signal may be expressed by a Boolean operation (==, <, >, etc.) between a left and a right argument or a predicate

• The arguments can be any signal, i.e. measurement, parameter, the state of a logical position, etc.

Here, the tension in the top-drive shaft is only valid when the shaft is connected

Signal Types and Dimensions

• Signals can be of different nature:• Measurement: e.g., pump-rate measurement (measured by a sensor)• Set-point: e.g., pump-rate set-point (defined by the driller)• Command: e.g., pump-rate command (controlled by the pump drive)• Estimated value: e.g., maximum flow-rate to avoid fracturing the well• Parameter: e.g., stoke volume of the mud pump

Flow-rate set-point Pump-rate command Stroke volume parameter

Flow-rate measurement

t

Pump-rate Set-Point

Pump-rate command

Max Pump-rate estimated value

Pump-rate measured

Pump-ratePump-rate

Flow-rate

Stroke volume parameter

Signal Types and Dimensions

• Signals can be of different nature:• Signals can have different dimensions:

• Scalar: e.g., pump pressure• Vector: e.g., triaxial acceleration• Interval:

• e.g., acceptable bounds for pump rate while drilling to ensure hole cleaning, avoid formation fracturing and minimize risk of formation washout

• E.g., maximum bounds for pump pressure to detect pipe washout, pack-off, bit nozzle plugged, etc.

• Spatially distributed: e.g. along string annulus pressure measurements• 1D: e.g. estimated tension along the drill-sting• 2D: e.g. resistivity image log• 3D: e.g. estimated temperature in borehole and vicinity

Scalar value: hook-load

Vectorial value: acceleration

Spatially distributed value: ASM Annulus pressure

Spatially 2D value: resisitivity log

Transferring data: Latency, sampling rate and consistency

• In some cases, we want the shortest latency possible, for instance because the signal is used to control a machine or to activate a safety trigger

• In other circumstances, we need signals that are resampled, for instance because the available sampling rate is incompatible with linearity constraints of a mathematical model (CFL condition for finite difference method)

• Furthermore, it may be necessary that several signals are synchronized, for instance because the group of signals define the boundary conditions of a set of partial differential equations.

• A consumer application may need both low latency for certain functionalities, a specific sampling rate with full consistency of a subset of different signals for other functions.

It is not possible to respect simultaneously a low latency and high consistency, therefore there is a need for at least two interfaces: a pure streaming interface that insure low latency, and a resampling interface that provides high consistency

5s samplingt0

2s samplingt0+1s

2s samplingt0+1s

5s samplingt0+2.5s

0,5s samplingt0+10s

0.5s samplingt0+10s

0.5s samplingt0+10s

0.5s samplingt0+10s

DDHub layers

DD-Hub

• OPC-UA

•Standard for data exchange

•Used in many industries for control

Data transfer protocol

•Developed by IRIS nowSemantical data representation

•Several interfaces for different priorities

•Based on 3rd party software libraries

• Internal developments (IRIS)

Data server / aggregation

OPC-UA: • provide a toolbox of tools to exchange information in real-time and build semantical models• However, there is a complete freedom on how to build a semantical model. • All semantical models are valid, but not all models will allow for advanced inferences

Methodology

• Define use cases • Check how signals can be described by the current semantical model

• Possibly extend the semantical model• Verify that a «consumer» application can uniquely interpret the meaning of the signals and make proper decisions

when there are possible choices• Repeat until no more use cases

Projects and activities9 May 2018

• The work on the drilling signal semantical data model is performed in the project: P1.3 «Drilling Process Optimization» that is financed by the DrillWell Centre for Research-based Innovation with the following partners: the Norwegian Research Council, Statoil, Wintershall, AkerBP, ConocoPhillips.• A first prototype (limited to the 4 use cases) has been demonstrated Oct 17• The work continue until Summer-2018 where a first complete semantical data model shall be available

• In parallel, a JIP is started for testing and validating the DDHub concept. This is a so-called Demo2000 project with funding from the Norwegian Research Council, Statoil, AkerBP, TOTAL, ENI, Halliburton• The objective is to develop a first reference implementation that also include two APIs (one for low latency and one for high

consistency)• And then, test whether seamless communication can be achieved when associating multiple drilling data sources and consumer

applications (without human involvement)• The participants to the JIP have a strong influence on which use cases will be used to validate the concept and first-hand to bring

improvements to the semantical data model• If the demonstration is successful, then the semantical data model and its associated API will be passed to a standardization

organism like Energistics (or others).• The standard will be open and vendors can implement it in their software solution. They can compete on performance and

additional features.

Conclusions

• Aggregation of multiple sources

• Importance of semantic in signal description

• Low latency vs High consistency

• Allow for continuous discovery

AcknowledgementsWe would like to thank the Research Council of Norway and DrillWell funding partners, Statoil, Wintershall, AkerBP, ConocoPhillips, and further DEMO2000 and additional partners in the Drilling Data Hub demonstration project, TOTAL, ENI and Halliburton.

I would finally like to acknowledge fellow Chief Scientist Eric Cayeux at IRIS and my colleagues in the IRIS DDHub development team.

9. mai 2018

Thank you

drilling data hub

Documents