John Shields - 31 Oct 2000
The DART (Drilling Automation Real Time) project sees the wellsite software environment as a tree structure with a number of different data records accessible by navigating through the tree. The basic structure is:
Data Source | Data sources (typically service company databases) | ||||||
Well | Well information | ||||||
Wellbore | Wellbore information | ||||||
Status | Individual live data values e.g. ROP, DEPTH, WOB, Gamma | ||||||
Path | Wellbore path coordinates (vert. depth, E-W, N-S) | ||||||
[Section] | Sections of the wellbore e.g. 13 3/8 Casing | ||||||
[Trip] | Trips within the wellbore | ||||||
Log | Logs of MWD and/or drilling data. A log is a collection of traces. | ||||||
Trace | Log traces e.g. Gamma, Porosity, ROP | ||||||
Trace Data | Individual data points | ||||||
Survey | Directional Surveys | ||||||
MWD Survey | Survey points from LWD/MWD tools. Raw downhole measurements, survey correction data and calculated wellbore positions w/vertical depth, N-S, E-W | ||||||
Angular Survey | Angular survey data points. Depth, inclination, azimuth |
In the above example, the Data Source entity is the root of the tree. A Data Source is maintained by a data provider, which may be a service company or it may be an existing database in an oil company environment. A Data Source contains wells, wells contain wellbores. Wellbores may contain sections or trips. Wellbores, sections or trips contain surveys and logs. Logs consist of log traces which are in turn made up of data points. Surveys may contain angular data in the form of depth, inclination and azimuth measurements and may also contain calculated wellbore position data with vertical depth, and the wellbore northing and easting locations.
DART is based around the idea of connecting to a data source via a CORBA connection. The data source may then be queried from the DART Client software to navigate through the tree of data structures described above. The Third Party data providers such as logging companies provide data to the DART CORBA Server through Java language interfaces.
A typical sequence of queries in DART would be as follows:
- List Wells in data source
- List Wellbores in a selected Well
- List Logs in a selected Wellbore
- List Traces in a selected Log
- Get Trace Header information
- Download range of data from selected Trace
In DART, each data entity is identified by a NameAndID object. This contains a readable ASCII name suitable for presenting to the user of the system and an internal unique identifier which is normally hidden from the user. All of the queries which return a list of items will acyually return a list of NameAndID objects to the calling method. These NameAndID items are then passed in as arguments to subsequent queries.
Most DART objects provide a method to obtain a header containing information about the object. For example the WellHeader object contains the Field Name, Country, County, Geographical Location, Current status, Water depth, Elevation datum. This is similar to the data which is found in the WITS Well Information record.
WITS, the Wellsite Information Transfer Standard is maintained by an oil-industry committee composed of oil company and service company representatives. Their charter is:
"To define the format and information content of the data stream transmitted from a wellsite to a central site by telecommunications facilities or hard media".
The WITS data records are more rigidly defined and do not have such a deep heirarchy of structure. In WITS, all records contain a well and a sidetrack identifier which may be linked back to WITS record 23, well information. WITS does not specify the transport mechanism for moving data from supplier to consumer. In practice, most WITS data are transmitted via serial interfaces, TCP/IP network sockets or as files on magnetic media. It is up to the sending and receiving companies to generate their own software for encoding and decoding the WITS data records. WITS is widely used in the oil industry and one of the main reasons for its success has been its simplicity.
There are 25 standard WITS data records which cover the following areas of rig operations:
Many of these records also contain "spare" slots for the addition of extra data items. It is also possible to define custom WITS records for data items which are not covered by the standard records. This is used by rig instrumentation companies to send detailed rig sensor data to other service companies and also by service companies to move custom data records between their own systems.
In addition to the WITS records, the WITS specification also defines a number of different levels by which the records may be transmitted. The simplest, level 0, is a one-way ASCII data stream usually sending a small sub-set of the total WITS records. Higher levels of transmission enable bi-directional communication for retransmission of data and the use of different formats to encode the data as LIS or RP66/DLIS data records. LIS, DLIS and RP66 are oilfield data standards, originally proposed by Schlumberger for wireline data, which have been in use for a number of years and are supported by many geological and petrophysical software applications.
The majority of WITS transmissions in common use in the oil industry use the lower, simpler levels of transmission, either WITS level 0 or 1.
WITS has been in use and accepted by the industry for over 20 years. WITS data may be provided in a choice of two different sets of measurement units, FPS (foot, pound, second), common U.S. oilfield units or WITS Metric units.
The following taable maps the WITS entities to DART records:
WITS |
DART |
Comments |
Record 1 - General Time Based Data | Could be implemented as DART Log Traces | Drilling and mud information collected on time samples |
Record 2 - Drilling Depth Based | Could be implemented as DART Log Traces | Drilling and mud information collected on depth samples |
Record 3 - Drilling Connections | Not Available | Information collected while making a connection or tripping pipe or casing |
Record 4 - Hydraulics | Could be implemented as DART Log Traces | Mud circulation and pressure loss data |
Record 5 - Time Based Tripping/Casing Run | Could be implemented as DART Log Traces | Rig engineering data collected while pulling and running pipe |
Record 6 - Connection Based Tripping/Casing Run | Not Available | Trip performance and safety data |
Record 7 - Directional Survey | Directional Survey | WITS version is less detailed than DART. DART can contain downhole raw data and correction parameters. |
Record 8 - Time/Depth based MWD Formation Evaluation | Could be implemented as DART Log Traces | WITS definition is rigidly defined. DART is very general. DART curves may be accessed via POSC classifications |
Record 9 - Time/Depth based MWD Mechanical Evaluation | Could be implemented as DART Log Traces | Downhole measurement of drilling parameters such as pressures, torque and weight on bit. |
Record 10 - Pressure Evaluation | Could be implemented as DART Log Traces | Formation pressure and gas parameters |
Record 11 - Mud Tank Volumes | Could be implemented as DART Log Traces | Volumes of the mud pits. |
Record 12 - Cycle based Chromatograph Data | Could be implemented as DART Log Traces | A record generated for each cycle of the mudlogger's gas chromatograph |
Record 13 - Depth based Chromatograph Data | Could be implemented as DART Log Traces | Chromatograph data logged against depth of mud returns |
Record 14 - Lagged Continuous Mud Data | Could be implemented as DART Log Traces | Mud physical properties and gas data |
Record 15 - Cuttings Lithology | Not Available | Descriptions of up to 5 lithology types for a depth sample interval. Would be difficult to implement as DART Log Traces. |
Record 16 - Hydrocarbon Show | Could be implemented as DART Log Traces | Cuttings sample description and hydrocarbon shows |
Record 17 - Cementing | Could be implemented as DART Log Traces | Data typically collected from a wellsite cementing unit. |
Record 18 - Drill Stem Testing | Could be implemented as DART Log Traces | Pressure, flow rates and fluid volumes from a well test |
Record 19 - Configuration | Not Available | Drill String, Casing, Rig Data |
Record 20 - Mud Report | Not Available | Manually entered report data, typically generated once or twice per day. |
Record 21 - Bit Report | Not Available | Summary data for a bit run, one entry per bit run. |
Record 22 - Remarks | Not Available | User entered comments tagged on depth and time. |
Record 23 - Well Identification | Well & Wellbore Headers | Information about the well and its location |
Record 24 - Vessel Motion/Mooring | Could be implemented as DART Log Traces | Mooring lines and thruster data for floating and dynamically positioned rigs. |
Record 25 - Weather/Sea State | Could be implemented as DART Log Traces | Wind and wave conditions |
Many of the WITS tables are sequences of parameters logged against intervals of depth and/or time. These could easily be implemented in the DART model by defining DART Logs which contain these parameters. The difference between WITS and DART for these data items is that WITS explicitly defines the items which are available whereas DART leaves the definition of the trace names to be flexible and thus relies on the receiving software to know what to do with the data. In DART, it is possible to determine the POSC classification for Log Traces so it can be determined if a Trace is a Gamma Ray or a Resistivity. Most of the drilling information however comes under the POSC classification of "auxilliary" and so does not define the type of data or units of measurements.
WITS returns data in a choice of two units systems, FPS or Metric. DART returns data in S.I. units.
In general, DART offers more options for retrieving data in different ways. For example it is possible to specify in DART what the depth reference point should be so that data may be retrieved relative to Mean Sea Level, Kelly Bushing, Ground Level or Rotary Table. Wellbore position coordinates may be referenced to the wellhead or to a grid coordinate system such as UTM or latitude and longitude.
DART is also more rigorous about how to specify well positions. DART specifies floating point numbers for latitude and longitude whereas WITS has an ASCII string which could lead to inconsistencies in how the information is formatted.
To retain the flexibility of the DART approach with the rigidity of the WITS specification, it would probably be necessary to define a dictionary of "standard" data item names which explained the type of data and measurement units. For example "GRBC" could be a borehole corrected gamma ray measurement measured in API units.