Foreword
This specification was originally prepared by the Subcommittee on
Standard Format for Digital Well data. In June 1996 it was
designated a recommended practice by the
American Petroleum Institute [API]
Exploration & Production Department's Executive Committee
on Drilling and Production Practices. In June 1998 stewardship
of the document was transfered from API to
Petroleum Open Standards Consortium [POSC].
A wide variety of digital data is acquired, exchanged, and stored
by petroleum industry
businesses using an equally wide variety of data formats. Most
of these formats have been
around for many years and were designed for very specific needs.
As a result, they reflect
the limitations of early computing hardware and are typically
oriented to one type of data.
Although relatively simple to implement, many formats lack the
flexibility or sufficient
self-descriptive features to accommodate evolving data exchange
needs.
Recommended Practice 66, Version 1
[RP66V1]
was introduced as
an enhanced exchange format for well data. It incorporated the
useful features of earlier
formats and extended them by removing some of their historical
limitations. The primary
features of RP66 V1 were machine independence, self-description,
semantic extensibility,
and efficient handling of bulk data. It has been implemented
and is used widely for
exchange of well data.
Following the introduction of RP66 by the API, a number of efforts
by other oil industry
groups to develop data exchange formats began to mature and
converge toward the adoption of RP66,
creating a major opportunity to have just one
standard exchange format for
all oilfield data. However, the strong bias of RP66 toward well
data was a stumbling
block. In addition, introduction of new high-capacity storage
devices created a need to
expand the RP66 physical binding mechanism, and experience in
using RP66 generated
ideas for improvements. Working closely with other industry
groups, the API Subcommittee on Recommended Format for
Well Data developed a set of modifications
to RP66,
which have resulted in the current RP66, Version 2 (RP66 V2),
which is described in this
document.
RP66 V2 retains the essential features of RP66 V1 and is completely
upward compatible.
That is, any data recorded under RP66 V1 can be translated
into RP66 V2 format.
The following list summarizes the differences between RP66 V1
and RP66 V2.
-
Separate well data object types from neutral data object
types.
Public object types from RP66 V1 are separated into two groups,
both administered by POSC.
One group consists of basic object types having no well data bias.
This is referred to as the basic schema, described in Part 6,
and is administered under organization code 0 (zero).
The second group consists of all the rest and is administered
under organization code 66.
This group, described in Part 8, is referred
to as the DLIS schema.
-
Add new attributes and symbolic codes.
The following are added: DIMENSION and AXIS attributes to
CALIBRATION-COEFFICIENT,
DATE attribute to CALIBRATION, KIND attribute to
CHANNEL, PARAMETER, and COMPUTATION, DESCRIPTION attribute to
all object types, EXTENDED-ATTRIBUTES attribute to all object
types except
FILE-HEADER and ORIGIN, new codes for TYPE attribute of EQUIPMENT,
and
new codes for PROPERTIES attribute (many object types).
-
Allow COORDINATES attribute of AXIS to reference a CHANNEL
object.
This permits dynamically changing coordinates.
-
Add new representation codes and representation code classes.
The following codes are new: RNORM, RLONG, ISNORM, ISLONG, IUNORM,
IULONG, IRNORM, IRLONG, TIDENT, TUNORM, TASCII, LOGICL,
BINARY, FRATIO, DRATIO. All representation codes are grouped
into classes of
related representations. A restriction in the definition of
an attribute to any member
of a class allows use of any other member of the class.
-
Extend ASCII to include ISO 8859-1, and allow string padding.
The set of allowable characters in an ASCII string is enlarged.
In addition,
character subfields in all representations may be padded by
using a terminating null
(zero) character. The string count may include characters past
the null, but such
characters are not considered part of the string data. This
supports in-place editing
of RP66 data.
-
Change copy number (in OBNAME) from USHORT to UVARI.
A maximum of 256 instances of a named object was seen as potentially
limiting for some applications.
-
Extend unit expression syntax and add new unit symbols.
The unit expression syntax supports additional types of units,
for example units
with fractional exponents, and use of multiple sets of parentheses
to improve meaning.
A more comprehensive set of SI unit symbols and a set of
monetary unit symbols are added to the unit dictionary.
-
Allow use of multiple unit models.
In addition to the unit model defined as part of RP66,
provision is made to identify and use other unit models
having different sets of unit symbols.
-
Uncontrol EQUIPMENT identifiers.
These identifiers are no longer required to be in a dictionary.
Attributes TYPE and
TRADEMARK-NAME suffice to identify equipment.
-
Require distinct object names in a logical file.
This rule, that no two object names can match all three subfields
(origin, copy number, identifier),
makes an object name a unique reference.
It is no longer necessary for a reader to know the object type
to resolve the reference.
-
Revise ORIGIN.
Well data attributes are removed and put into a new DLIS-CONTEXT
object type in the DLIS schema.
New attributes are added to identify schema and unit model.
-
Support use of multiple schemas.
The terms Private and Public are removed.
All schemas are implemented equally
with the only exception being mandatory (and exclusive) use
of FILE-HEADER
and ORIGIN object types from the basic schema.
Mechanics to make this work
include TIDENT representation of set types and attribute enumerations,
and removal of logical record type numbers.
-
Remove rule restricting ordering of EFLRs and IFLRs.
An attribute in one set (EFLR) may reference an object in another
set even if the two sets are separated by an IFLR.
-
Remove special constraints on representation of FILE-HEADER
attributes.
The attributes of a FILE-HEADER object are no longer constrained
regarding length and order.
-
Neutralize FRAME and CHANNEL and support multiple frames
per record.
Attributes of these objects are revised to remove the well data
bias.
In addition, multiple frames per record are supported.
This allows some applications to
increase performance for reading and writing bulk data.
In addition to dimensioned arrays,
channel values may now also be described as aggregates
(similar to "ragged arrays").
-
Replace channel dimension updates with explicitly-sized
channels.
Provisions are made to write explicitly-sized channels by optionally
recording channel dimensions directly in frames.
Correspondingly, the DIMENSION
attribute of CHANNEL is no longer updatable.
-
Add new information to storage unit label.
The following fields are added: binding version, producer code,
creation date, and serial number.
The size of maximum record length is increased.
-
Expand visible record header and logical record segment
header.
The maximum length of a visible record is increased from a 16-bit
quantity to a
32-bit quantity, and similarly for lengths in the logical record
segment.
This allows binding onto very large tape blocks (megabyte or more).
New fields file sequence
number and file section number are added to the visible record
header.
The visible record now also has a trailing length.
A new structure, FIXREC, is added to
indicate fixed-length visible records.
-
Fix encryption mechanism to handle blind passthrough.
The logical record segment encryption mechanism is modified
to allow readers to
copy and re-segment data for which the encryption method is
unknown.
-
Define a physical binding for files on random access disks.
A file on a random access disk is defined to be a storage unit
if the file has a byte
stream structure consisting of a storage unit label followed
by a sequence of visible
records.
RP66, V2 consists of Parts 1 through 9, plus Appendix A. These
parts are briefly described below:
-
PART 1: MODEL AND METHODOLOGY.
-
This part describes the data model upon which the format is
based and the methodology for specifying schemas -
namely, object types, attributes, and the rules about them.
-
PART 2: LOGICAL FORMAT.
-
This part describes the logical organization and representation
of data,
including the definitions and uses of storage sets, logical
files, visible
records, logical records, sets, objects, attributes, and values.
It also
describes naming and referencing rules as well as bindings between
logical records and visible records and includes specifications
of all representation codes used in the format.
-
PART 3: PHYSICAL BINDINGS.
-
This part describes how storage unit labels and visible records
are recorded on various common medium types,
including 9-track magnetic tape and random access disk files.
It also describes the use of filemarks and partitions
where applicable.
-
PART 4: THE API-SI UNIT MODEL.
-
This part describes a unit model based on
le Système International d'Unités (SI)
from which a wide variety of units can be expressed.
The unit model supports a general method for computing
unit conversion coefficients for dimensionally-related units.
-
PART 5: API-SI UNIT SYMBOLS.
-
This part lists and defines the unit symbols recognized under
the unit model described in Part 4.
-
PART 6: BASIC SCHEMA.
-
This part specifies the object types administered by
POSC using organization code 0 (zero).
This schema includes certain basic object types such
as FILE-HEADER and ORIGIN, which are required by all implementations,
as well as other object types such as FRAME and CHANNEL, which
are standard mechanisms for describing the storage of dynamic (or
bulk) data.
-
PART 7: BASIC SCHEMA DICTIONARY.
-
This part lists and describes reference values for attributes
belonging to the basic schema.
-
PART 8: DLIS SCHEMA.
-
This part specifies the Digital Log Interchange Standard (DLIS)
schema object types administered by POSC using organization code 66.
This schema includes object types particularly oriented toward
recording well log data.
-
PART 9: DLIS SCHEMA DICTIONARY.
-
This part lists and describes reference values for attributes
belonging to the DLIS schema.
-
APPENDIX A: ORGANIZATION CODES.
-
This appendix lists currently-assigned organization codes.
This document makes reference to the following entities
(documents or organizations):