From guthery@SLCS.SLB.COM Tue Jun 15 18:07:42 1993 Status: RO X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] ["10784" "Tue" "15" "June" "1993" "17:00:58" "-0500" "guthery@SLCS.SLB.COM" "guthery@SLCS.SLB.COM" nil "209" "API RP66" "^From:" nil nil "6"]) Return-Path: Received: from Austin.slcs.slb.com ([163.185.69.9]) by fits.cv.nrao.edu (4.1/DDN-DLB/1.5) id AA13140; Tue, 15 Jun 93 18:07:38 EDT Received: from fugu.SLCS.SLB.COM (FUGU.AUSTIN.NAM.SLB.COM) by Austin.slcs.slb.com (4.1/SLCS Mailhost 3.13) id AA00461; Tue, 15 Jun 93 17:06:02 CDT Received: by fugu.SLCS.SLB.COM (AIX 3.2/UCB 5.64/SLCS Subsidiary 1.10) id AA13469; Tue, 15 Jun 1993 17:00:58 -0500 Message-Id: <9306152200.AA13469.guthery@fugu.SLCS.SLB.COM> In-Reply-To: Don Wells's message of Mon, 14 Jun 93 13:34:26 EDT <9306141734.AA11141@fits.cv.nrao.edu> From: guthery@SLCS.SLB.COM To: dwells@fits.CV.NRAO.EDU Subject: API RP66 Date: Tue, 15 Jun 1993 17:00:58 -0500 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