Subject: RP66 Overview

From: [email-masked] (Scott Guthery)
Date: 16 Jun 1993 10:15:11 GMT

INTRODUCTION

The Digital Log Interchange Standard (DLIS) is an American Petroleum Institute
Recommended Practice (API RP 66 Version 1.00) for the interchange of digital
log data to meet the evolving needs of new measurement systems and
technologies.  It is superior to existing formats in three basic ways:

  o	It provides for better identification of data.
  o	It provides a general method for representing complex forms of data,
        including arrays and textual strings.
  o	It provides a method for representing channel data according to their
        dynamic requirements, including variable-length frames and multiple
        types of frames -- which differ by index, sampling rate, and channels
        -- intermixed in the same file.

DLIS is specified in two parts:

  o	A syntactic part, which describes the format of the data (i.e., how it
        is represented and organized).
  o	A semantic part, which describes the meaning of the data (i.e., its
        relation to the physical measurements taken and recorded).

The following sections summarize the history and the prominent features of the
API DLIS.

HISTORY

In 1985 a subcommittee was formed with members from the major oil and logging
service companies to update the API D9 Bulletin, which was a list of logging
tool and curve mnemonics and a description of a format for the exchange of
logging data.  The D9 exchange format was not being used by anyone.  A search
for alternative formats revealed that SchlumbergerUs Log Information Standard
(LIS) was deeply entrenched and there were no alternatives under consideration
by any other source except Schlumberger, who were designing a successor to the
LIS. The API proposed to Schlumberger that the new format be evaluated by the
subcommittee for release as an API document, to which Schlumberger agreed. 
Schlumberger completed its design in early 1987, and over the following two
years the subcommittee added its recommendations.  The final document, now
known as DLIS, was released for public comment in May, 1989, and was approved
by the API Production Department Executive committee as Recommended Practice
65 in April, 1990. Interestingly, the D9 tool and curve codes (known as RAPI
CodesS) were abandoned in favor of the structured names described below.

FEATURES

Extensibility

The API DLIS uses an "object-oriented" approach to data representation.  The
objects are represented with a uniform syntax, which permits the addition of
new object types without change to how an application writes or reads them. 
This provides a powerful way to extend the range of information recorded under
the API DLIS.

Data Identification

A method is provided for distinguishing similar or duplicate data elements
recorded in the same file.  Each distinct piece of data can be associated with
the circumstances and environment (i.e., origin) under which the data was
created. Data channels, parameters and certain other data items have
structured names that can be expanded into meaningful descriptions.  This
structure provides the possibility for applications to classify data and to
select data based on formalized queries.  Included in the structure is a
standard name defined by the API for common and well-known data elements.  For
new and less common data elements, the standard name part is absent. Finally,
all data elements have identifiers (similar to mnemonics) that can be used for
internal referencing and efficient access.  For some types of data, the
identifiers are managed in external dictionaries.  These dictionaries can be
distributed by the data producers to their clients in DLIS form so that client
applications can be developed for automatic loading of data from API DLIS
files into internal databases.

Complex Data

More complete and more standardized numeric representations are used,
including IEEE floating point, double precision floating point, complex
numbers (real plus imaginary parts), variable-length strings, and so on.
Arrays are supported, including the indexed array values and a full definition
of the array dimensionality.  The number, order, description, and size of the
set of dimensions can be represented.  In addition, the coordinate values of
successive positions along each coordinate axis can be represented for linear,
non-linear, and enumerated sets of coordinate values.  The size of an array
(e.g., the length of a waveform channel) can be varied within a file according
to the requirements of the data. Parameter values may be zoned, and the zoning
can be such that a parameter is undefined in certain regions.

Units of Measure

The API DLIS provides for a standard set of unit symbols for use by all data
producers and consumers.  These standard symbols are defined for a set of base
units and for a larger set of units that are derived from the base units.  The
units standard includes information needed to perform unit conversions.  Unit
expressions that appear in an API DLIS file may be either standard unit
symbols or may be expressed in terms of standard unit symbols. The method of
representing units is modeled after methods in common use, and is consistent
with the methods in standards published by SI, SPE, and ANSI/IEEE.

Encryption

Under the API DLIS, any logical record may be encrypted.  Because of this,
proprietary information need not be purged from a file before it is delivered
to a client.  The information remains in the file in case it is needed for
later processing by the producer.

Logical to Physical Layout

The API DLIS defines logical files that are made up of logical records, each
of which is recorded as one or more logical segments.  There are no logical
reels or tapes.   Either files or logical records may span physical reels and
physical records, but logical record segments may not. The length of a logical
record segment is recorded but not the length of a logical record.  This
permits logical records to be indefinitely long and allows the DLIS to
accommodate any future data size requirements.   The specification of a length
in the logical record segment permits an efficient packing of logical records
in physical records.  In particular, logical records may begin in the middle
of physical records. Logical record segments also contain "pad bytes", which
are provided to stretch segments when they need to conform to certain byte
alignment or minimum size requirement, imposed for example by encryption. The
binding of the API DLIS logical record segments to physical records is
specified for 9-track magnetic tapes and for disk files that have a
variable-length, sequential record structure.  Bindings of logical record
segments to the physical elements of other media (e.g., byte stream files)
will be specified.  As a sequence of logical record segments, the DLIS format
is independent of any physical medium.  The dependence on the physical medium
is in how logical record segments are written to the medium and how they are
read back.

Updatable Parameters

A set of updatable parameters is defined, and a means is provided for
recording updates to them.  Items that can be updated include tool and process
status, parameter values, calibration coefficients, equipment position,
channel splice points, and channel size and dimensionality.

Multiple Frame Types

Channel data under the API DLIS are recorded in frame sequences.  The API DLIS
supports any number of different frame types in the same file.  Each frame
type is characterized by its index, its sampling rate, and the channels it
contains.  Channels may change size from frame to frame and may even become
absent for an arbitrary number of frames.

Calibration Information

A full set of calibration information may be recorded, including information
about the measurements and methods by which calibration coefficients are
determined, and about the use of uncalibrated data, calibration methods, and
calibration coefficients used to compute calibrated data.

Splices

The API DLIS provides a flexible mechanism for representing spliced data. 
Information can be represented describing which segments of which channels
constitute the spliced channel.  The spliced channel may be recorded or may be
inferred from the splice information and the original channels.

Location and Configuration

A spatial coordinate system is defined for specifying positions in and about
the borehole.  This consists of dual depth coordinates (vertical depth and
borehole depth are explicitly distinguished) plus radial and angular drift
about a vertical line.  A time coordinate may be joined with the other
coordinates so that points along a time-varying path can be represented.  This
information can be associated individually with channels and with other
objects, thus enhancing the process of making depth and speed corrections.
Information about tool string configurations is improved by recording detailed
information about the component pieces of equipment that make up a tool,
including attachments and slip-ons.  Equipment out of the borehole, e.g.,
geophones, may be described along with its location relative to the well.

Source of Data

Channel and process data objects can specify their immediate sources, making
it possible for the complete source history of an object to be recovered.  For
example, a channel can specify the tool from which it was acquired or the
process or calibration from which it was derived.  Process objects specify
their input and output channels as well as the parameters that are used in the
process.

Textual Data

There is general provision for recording textual data in much the same way
that numeric data is recorded.  For example, a text channel can be recorded,
or a formatted ASCII document.  In addition, the usual operator interaction
with the system can be recorded as it happens.  Such interaction messages are
also time-tagged and can be tagged with depth or other relevant indices
corresponding to frame data.

Private Data

Provision is made for producers to define "private data" for interchange among
their own systems or organizations.  Private data is not necessarily
encrypted, but its definition and use are at the discretion of the producer. 
Private data is defined so as not to interfere with the definition and use of
Rpublic dataS objects, namely those objects that are defined through a
standardization process administered by the API.

                                  oo0oo

                   Copies of API RP 66 are available from
                        AMERICAN PETROLEUM INSTITUTE
                    Publications and Distribution Section
                              1220 L Street NW
                            Washington, DC 20005
                               (202) 682-8375

                            Order No. 811-09306