Wellsite Information Transfer

Specification (WITS) for

Digital Rig-Site Data
R.E. Jantzen, BP Exploration Inc.; R.D Foreman, SPE, Amoco Production Co.; L. Keltner, EPISTAT;
and R.S. McCoy, * SPE, RSM Assocs.

Summary. Information of many kinds, including drilling and mud-logging parameters, is transmitted electronically from rigs to central
sites. The format of the transmitted information depends, at present, on the business entities involved in the information-transfer transac-
tion. Many different formats exist, decreasing the overall utility of information obtained at the rig site and increasing processing costs
for the industry. Standardization of formats for information content and telecommunication requirements was attempted by the Informa-
tion Transfer Committee (lTC), a subcommittee of the IntI. Assn. of Drilling Contractors' (IADC' s) Rig Instrumentation and Measure-
ment (RIM) Committee, which formulated a set of guidelines addressing the broad needs of the industry. This paper explains the rationale
for the standardization effort; outlines the process by which the specification was established; and describes the requirements, concept,
components, and benefits of the resulting WITS.

Introduction
Different service and operating companies have proprietary for-
mats for electronic data transmission-e.g., tape, direct line, micro-
wave, commercial telephone service, or satellite-that are used
depending on the companies involved and the agreements reached
between them. Many digital formats were created and are main-
tained, each at substantial cost, by service companies and opera-
tors. When a new relationship is established between a service
company and an operator, modifications and adaptations of formats
often must be made to allow the data collection and analysis sys-
tems of the two entities to "talk" to each other, again at signifi-
cant cost.
The result is that a great deal of rig data that might be useful
to operators in evaluating rig performance and in monitoring and
controlling drilling is often not collected or transmitted because of
the cost and complexity of format matching and modification. Costs
in dollars of this "failure to communicate" are difficult to meas-
ure; there is, however, no disagreement within the drilling indus-
try that they are quite large.
A solution to the information-transfer format and telecommuni-
cation standard problem has thus been the overriding goal of the
ITC. Creation of a standard that can be implemented easily by both
operating and service companies should allow information trans-
fer to be established quickly and economically between rig and cen-
tral sites. The lTC's work was divided between the Software
Standards Subcommittee (SSS), which was responsible for format-
ting of the digital data, and the Telecommunication Data Trans-
mission Subcommittee (TDTS), which was responsible for file
transfer, or telecommunication, of the data. Both subcommittees
followed the guidelines of the IntI. Standards Organization (ISO) 1
(Fig. 1). The ISO model creates a framework for defining stan-
dards for linking all communication and computing functions in an
"open-architecture" fashion. "Open" refers to the ability of an
end system of one company to connect with the end system of
another company that conforms to the reference model and associat-
ed protocols. This is particularly important for the drilling indus-
try, which is composed of large numbers of diverse operating and
service companies, each of which may need to exchange increas-
ingly more data in the future. The model is partitioned into seven
layers, each of which is composed of a group of logically connect-
ed functions.
The TDTS fundamentally addressed the physical and data link
functions (Layers 1 and 2, respectively, of Fig. 1), and the SSS
addressed the session, presentation, and application functions (Lay-
ers 5 through 7, respectively, of Fig. 1). The ISO's open-system
interconnection (OSI) standard, 1 which was used as a guideline to
develop a standard for the particular requirements of the drilling
environment, forms the underlying structure of the specifications
'Now at INFOSTAT Systems Inc.
Copyright 1989 Society of Petroleum Engineers
SPE Drilling Engineering, December 1989
discussed in this paper. The formatting and content of data and data
telecommunications are discussed separately.
Process
The SSS was initially formed by a group of representatives of service
and operating companies, primarily computer-software-system de-
velopers and drilling engineers, who had acute problems with the
profusion and mismatch of rig-data formats. Most were involved
in the process of either writing new formats or constructing sys-
tems to translate existing formats.
To ensure that any proposed standard was complete and accept-
able to the industry as a whole, an extreme effort was made to in-
volve representatives from as many operating and service companies
as possible. A great majority of major operators and service com-
panies, as well as many smaller specialty service companies, were
represented on the SSS. In addition, electronic-communication ex-
perts were recruited. The effort, which continued through the life
of the SSS, extended to Europe, Australia, and Asia. Liaison was
maintained with several European companies and organizations,
and progress of the SSS was reported regularly to several Asian
industry organizations.
The goal of the standardization effort was broad but concrete:
To define the information content and format of the data stream
transmitted from a rig to a central site either by telecommunica-
tions facilities or by hard media. To avoid omissions in the specifi-
cation, we needed an inventory of parameters currently in use in
the following areas: (1) geology and drilling, (2) operating, (3) meas-
urement while drilling (MWD), (4) wireline, (5) rig, (6) cementa-
tion, (7) drillstem testing, and (8) miscellaneous free-format forms
and two-way message transmission. Companies providing data col-
lection services in these areas were polled for descriptive lists of
the parameters currently in use.
We also conducted a seminar to familiarize the industry represen-
tatives op the SSS with the major existing formats and data-
transmission systems. The seminar presented information on general
methods of data transmission and formatting, different hard-
ware/software systems currently in use, and the nature and con-
tent of several specific formats. The seminar also included site visits
and presentations at the Amoco Production Co., Arco Oil & Gas
Co., Mobil E&P Services, and Tenneco Oil & Gas Co. data centers.
After the inventory of data parameters was accumulated and
representatives were familiar with the current status of formats,
the SSS produced a set of requirements that, when implemented
in the WITS, would satisfy the present and future needs of the serv-
ice and operating companies. The requirements were used to con-
struct a logical framework, or concept, for the specification. Once
the concept for WITS was complete, special work groups of ex-
perts formulated the specific components of the specification.
The specification is now complete, and WITS will be published
by the API as a recommended practice. This paper reviews and
summarizes the key points of the WITS. A review board under the
291
 TABLE 1-COMPATIBILITY BETWEEN LAYERS OF WITS
IS~ H~DEL WELLSITE INFORMATION MULTILAYERED STANDARD
LAYERS TRANSFER SPECIFICATION (WITS]
Computer Reader
} PRE-DEFINED RECORDS
7 APPlICATI~N NNENONICS Layer Transmission Layers
1 and 2 (throw-away
6 PRESENTRTI~N customization)
} "'". '''',.,,''""'' . . .00 2 1 and 2
5 SESSION t SOfTWARE SlANDAI'D t 3 1 through 3 (will
read some E-Log
4 TRRNSP~RT
~ TELECONNUNICATUlNS' ~ tapes)
DATA TRANSNISSION STANDARD
4 1 through 4 (LIS
3 NETWORK ERROR DETECTION 1979/L1S 1)
ERROR CORRECTION 5 1 through 5 (LIS
"ENCRYPTION
2 DRTA LINK PHYSICAL SYNCHRONIZATION 1984/L1S 2)

1 PHYSICAL
·US.LOG INFORMATION STANDARD (FROM REF. 2).
"ENCRYPTION TO BE HANDLED BY INDIVIDUAL COMPANIES.
Fig. 1-Relatlonshlp between ISO OSI model for communi-
cations and WITS standard.
8. WITS should provide a good technological entry point for users
without existing data systems.
9. WITS should provide a good migration path for existing
systems.
10. Most rig-to-central-site data-communication needs should be
satisfied by WITS.
11. Existing standards (official or de/acto) should be used wher-
ever possible.
12. The specification should be international.

r ' ....- OPTIONAL Concept. Many alternatives, from establishment of a standard

HEADER specifying the exact content and format of each data item (which
would require continual updating and modification of the specifi-
cation) to adoption of some existing system in its entirety (which
APPROVED would make use difficult for some systems and would raise costs
BY BOTH considerably), were considered. The requirements, however, could
PARTIES be satisfied only by a specification encompassing the two extremes.
Thus, the WITS is layered. It has five levels, each more com-
plex and comprehensive than the preceding one (Fig. 2). Each lev-
el includes all the features of the preceding level. A system
_+-~""'---I- IADC-WITS implemented by the lowest level of WITS will be completely com-
patible with systems implemented by higher levels (Table 1).
Levell-Predefined Records. Rig information can be organized
into logical groups of parameters-e.g., depth-based drilling pa-
rameters, tripping information, cementing data, etc.-called
"records." These records contain relatively similar information
for all wells. The first level specifies the exact content and format
FUTURE IADC of each of the most common rig-data records.
STANDARD?
All data record formats are predefined to meet the requirements
of the WITS levels, which are based on Schlumberger's2 Log In-
Fig. 2-Multilayered concept of WITS standard. formation Standard (LIS), and are compatible with the proposed
API Digital Log Interchange Standard (DLIS). 3 No LIS header and
trailer records are required, and, because the data records are prede-
auspices of the API Petroleum Industry Data Exchange Standards fined, no data specification records are required.
Subcommittee will periodically monitor the implementation of WITS Implementing the first level is thus straightforward and inexpen-
and consider revisions. sive, because the specification serves as a "cookbook" with all the
details of implementation. More than 50 % of existing data require-
Description ments should be satisfied by systems implementing this level of
Requirements. Requirements for the specification were derived WITS. The Parameter and Record Definition section contains a com-
from the needs of service and operating companies and the nature plete description of the records included in Level 1.
of existing information-transfer systems. Level2-Modified Records. For greater flexibility, this level pro-
1. WITS should be adaptable to the needs of large and small data vides the mechanism for adding up to five additional parameters
systems. per record. The predefined records, as in the first level, are used
2. WITS should be easy to change within the scope of the speci- with the LIS header, trailer, and data-format specification (DFS)
fication as the needs of the industry and individual information sys- records. In addition, special bidirectional dialogue commands are
tems change. included that permit the receiver to control the records and the in-
3. The costs of implementing simple systems using WITS should terval being transmitted. Thus, a system implemented according
be low. to the first level of WITS would be completely compatible with
4. The long-term software costs for systems using WITS should the second level.
be as low as possible. Level 3- WITS-Compliant (Customized) LIS. The remaining lev-
5. Systems implementing WITS should be able to handle both els of the specification involve the use of components of Schlum-
real-time and batch data. berger's LIS and the API's proposed DLIS. Therefore, these data
6. Data transmission in standard format should be efficient. records can also be considered to be customized. Schlumberger de-
7. WITS should be capable of implementation on a full range fined LIS as an information-interchange format for well informa-
of computing hardware-e.g., from personal computers to main- tion that is designed to work with various types of computers to
frames. record different types of information in a taped or a real-time data-

292 SPE Drilling Engineering, December 1989

acquisition environment. The target information includes sensor
responses (i.e., logs) and any interpretation parameters.
The LIS format uses a hierarchy for storing and retrieving data.
This hierarchy separates the physical representation (i.e., the phys-
ical dimensions of the information or the space it occupies) from
the logical information (i.e., type and organization of the informa-
tion). This allows LIS to work with various types of media, such
as magnetic tape, disk, and communication lines.
Each LIS data set is kept logically complete by recording on that
data set all the information required to interpret the data. This al-
lows LIS to adapt to new concepts and technology while maintain-
ing compatibility with previously written LIS data sets.
The LIS format has become a de facto standard in the wireline
industry. It is currently used to exchange a wide spectrum of in-
formation, including wireline logs, core measurements, seismic re-
cordings, and vertical seismic profile (VSP) data.
LIS allows a great deal of flexibility in specifying the content
and format of data records and offers the ability to change format
and content easily. It is, however, more difficult to implement, and
thus more costly, than the first two layers of WITS. Full implemen-
tation of LIS can be very difficult and expensive, so a WITS-
compliant version was defined for the specification that is completely
compatible with the first two layers of WITS and with full implemen-
tation of LIS, except that it 'lacks some flexibility of full LIS im-
plementations. Restrictions for the implementation of LIS in Level
3 are noted later.
LeveI4-LIS 1979 (LIS 1). This level removes the restrictions,
but maintains the extension of WITS-compliant LIS. ,Full implemen-
tation of the original LIS offers much flexibility for virtually all
types of rig data. It is complex and expensive to implement, but
is an excellent solution for comprehensive data systems that acquire,
analyze, and store large amounts of rig data from many sources.
In keeping with the layered concept, any existing or future im-
plementation of LIS I will be able to read data transferred accord-
ing to Layers 1,2, or 3 of WITS.
LevelS-LIS 1984 (LIS 2). This is an extension, or superset,
of LIS 1 that allows increased abilities to handle information of
various types, but it is currently unpublished. It appears to include
all the extensions needed for WITS rig-site data communication;
the layered concept of WITS is thus maintained, allowing systems
implementing LIS 2 to read data transferred according to Layers
1, 2, 3, or 4 of the specification.
Parameter and Record Definition
With the adoption of the multilayered approach, there was a clear
need for the definition of a standard listing of parameter and unit
mnemonics for use in all layers, as well as a group of fixed, prede-
fined records to meet the requirements of Levell. Furthermore,
guidelines for future addition of records and expansion of parame-
ter and unit mnemonics needed to be specified.
Parameter Definition. Input was used from operators and vendors
with extensive experience in the setup and maintenance of real-time
drilling information data bases, at the wellsite and in regional data
centers, to establish a comprehensive listing of wellsite-generated
parameters. The number of parameters currently exceeds 400 and
includes sensor-derived measurements of drilling parameters and
fluid properties, computer-derived values (e.g., hydraulics and drill-
ing exponents), and manually entered data (e.g., lithological descrip-
tions and hydrocarbon-show evaluations). Both geological and
drilling engineering needs were addressed.
For each parameter, two unique mnemonics were assigned. One
mnemonic used a maximum of four characters for compatibility
with the current version of LIS (LIS 1), while the second expand-
ed to a maximum of eight characters for future application within
the LIS 2 environment (Table 2).
This listing serves as the basis for the parameter entries in the
predefined records and for the future construction of customized
records. A glossary containing a short description of each parame-
ter accompanies the record listing.
SPE Drilling Engineering, December 1989
Record Definition. The framework for the general structure of all
records-i.e., a fixed header, a main body, and a limited customiz-
ing trailer-was established. The header parameters remain fixed
from record to record, while the main body contains the specific
data items pertaining to each particular record type. The trailer per-
mits a small amount of flexibility to expand the main body with
operator-selected data items.
Record Header. The fixed-record header entry contains the (1)
well identification, (2) sidetrack/hole section number, (3) record
identification, (4) sequence number, (5) date, (6) time, and (7) ac-
tivity code. The well identification consists of 16 alphanumeric
characters identifying the well from which the data are derived.
The sidetrack/hole section number further defines this source. The
record identification contains the numerical code for the record type,
and the sequence number identifies the sequential position of that
partiCUlar record within the data stream with respect to other records
of the same type. Date and time serve as key fields to help identify
the record. The activity code is a numerical code identifying the
wellsite operation in progress at the time that the record was
generated.
Customizing Trailer. A limited number of entries are designed
to be "spares," which, contain null-value data if no modification
is made to the record. Each spare entry, however, may be replaced
by another parameter definition. In this way, if only one or two
extra parameters are required, they may be added to an existing
record instead of creating a new record.
Predefined Record Types. Levell of the multilayered WITS uses
fixed-format records. With the parameter listing serving as the ba-
sis for record content, a group of predefined records was speci-
fied. These record types were established by two criteria: rig activity
and the frequency of generation and/or required interval for moni-
toring of the parameters. All common rig activities were addressed,
and the parameters applicable to each activity were grouped
together. With these guidelines, 25 record types have been defined
to date.
1. General, time-based records serve as the basic records gener-
ated from the wellsite, regardless of rig activity. As such, they are
the most general as far as data content is concerned, though they
are heavily weighted toward sensor data rather than computed data.
The frequency of generation may range from a few seconds to sever-
al minutes, depending on the degree of detail required by the
operator.
2. Depth-based drilling records are generated on the basis of
changes in the total well depth. The frequency of generation might
typically be one record for each foot or each new hole drilled.
3. Drilling-connection records record information pertaining to
connections made during drilling-e.g., the addition of new drill-
pipe to the string. Data content includes maximum makeup and
breakout torque readings, average and maximum pulling and run-
ning speeds, and duration ofthe connection. Frequency of genera-
tion is one record per connection.
4. Hydraulics records contain predominantly computed hydraulics
information-i.e., fluid velocities and circulating-system pressure
losses. Frequency of generation is on a regular time basis while
drilling fluid is circulated.
5. Time-based tripping records contain information pertaining
to the tripping of the drill string or to the running of a casing/liner
string, including running/pulling speeds, block position, and hook-
load readings. These are more detailed records of the trip than the
connection-based tripping records. Frequency of generation depends
on the degree of detail required, but usually ranges from a few sec-
onds to one minute.
6. Connection-based tripping records contain summary informa-
tion pertaining to each connection of a trip or casing run. Included
in this record are maximum running/pulling speeds, maximum hook-
load, and time to pull and handle the stand. Frequency of genera-
tion is once per connection.
7. Survey/directional records contain directional survey data de-
rived from one of a number of sources-e.g., single-shot, multishot,
and MWD tools. Frequency of generation is one record per sur-
vey measurement.
293
 TABLE 2-EXAMPLE OF PREDEFINED WITS RECORD (RECORD 3: GENERAL TIME RECORD)

Frequency of Generation: Transmit one complete record at specified time interval

Mnemonic Parameter Rep Byte Mnemonic Units
Field Parameter Description LIS 1984 LIS 1979 Code Length SI Metric FPS
-- -- -- ---
1 Well identifier WELLID WID 65 16 - - -
2 Sidetrack number STKNUM SKNO 79 2 - - -
3 Record identifier RECID RID 79 2 - - -
4 Sequence number SEaNUM SaNO 79 2 - - -
5 Date DATE DATE 73 4 - - -
6 time TIME TIME 73 4 - - -
7 Activity code ACTCOD ACTC 79 2 - - -
8 Measured hole depth DRDEPTM DMEA 68 4 M M F
9 Vertical hole depth DRDEPTV DVER 68 4 M M F
10 Measured bit depth DRDEPTB DBIT 68 4 M M F
11 Block position BLKPOS BPOS 68 4 M M F
12 Penetration rate ROPA ROPA 68 4 M/S M/H F/H
13 Average hookload HKLDA HKLA 68 4 N T KLB
14 Maximum hookload HKLDX HKLX 68 4 N T KLB
15 Average surface WOB WOBSA WBSA 68 4 N T KLB
16 Maximum surface WOB WOBSX WBSX 68 4 N T KLB
17 Average surface rotary
torque TaSX TaSX 68 4 NM KDNM KFLB
18 Maximum surface rotary
torque TaSX TaSX 68 4 NM KDNM KFLB
19 Surface rotary speed RPMSA RSSA 79 2 - - -
20 Standpipe pressure SPP SPP 68 4 PA KPA PSI
21 Casing (choke) pressure CHKP CHKP 68 4 PA KPA PSI
22 Pump stroke, Rate 1 SPM1 SPM1 79 2 - - -
23 Pump stroke, Rate 2 SPM2 SPM2 79 2 - - -
24 Pump stroke, Rate 3 SPM3 SPM3 79 2 - - -
25 Total active mud-tank volume TVOLTACT TVTA 68 4 M3 L BBL
26 Active mud-volume gainlloss TVOLCACT TVCA 68 4 M3/S LIMN B/MN
27 Flow out MFOPC MFOP 79 2 - - -
28 Mud flow out MFOA MFOA 68 4 M3/S LIMN G/MN
29 Mud flow in MFIA MFIA 68 4 M3/S LIMN G/MN
30 Mud density out MDOA MDOA 68 4 KGM3 KGM3 LB/G
31 Mud density in MDIA MDIA 68 4 KGM3 KGM3 LB/G
32 Mud temperature out MTOA MTOA 68 4 DEGK DEGC DEGF
33 Mud temperature in MTIA MTIA 68 4 DEGK DEGC DEGF
34 Mud conductivity out MCOA MCOA 68 4 SliM MMHO MMHO
35 Mud conductivity in MCIA MCIA 68 4 SliM MMHO MMHO
36 Accumulated stroke count STKSC STKC 79 2 - - -
37 Lag strokes LAGSTKS LSTK 79 2 - - -
38 Return depth DRDEPTMP DMPS 68 4 M M F
39 Total gas TOTGASA GASA 68 4 % % %
40 Spare 1 SPARE1 SPR1 68 4 - - -
41 Spare 2 SPARE2 SPR2 68 4 - - -
42 Spare 3 SPARE3 SPR3 68 4 - - -
43 Spare 4 SPARE4 SPR4 68 4 - - -
44 Spare 5 SPARE5 SPR5 68 4 - - -

8. MYJV formation evaluation records contain the formation eval-
uation variables measured by MWD tools, including gamma ray,
formation-resistivity, and porosity-tool data. Frequency of gener-
ation is normally on a regular time basis, such as once per minute.
9. MYJV mechanical-property records contain mechanical param-
eters measured by MWD tools, including downhole weight on bit
(WOB) and downhole torque. Frequency of generation is on a regu-
lar time basis, such as once per minute.
10. Formation-pressure-evaluation records predominantly con-
tain computed information relating to the formation-pressure eval-
uation performed at the wellsite, including pore pressure, fracture
pressure, kick tolerance, and overburden pressure. Frequency of
generation is on either a depth or a time basis.
11. Mud-tank volume records permit detailed monitoring and re-
cording of the drilling-fluid tank system. Frequency of generation
is on a time basis, determined by the degree of detail required.
12. Cycle-based chromatographs contain the results of chromat-
ographic separation of the gas drawn from the returning mud stream.
Frequency of generation is one record per cycle of the chromat-
ograph.
13. Depth-based chromatographs serve as depth-based summaries
of chromatographic analyses, featuring average and maximum read-
ings for individual gas constituents over the depth intervals. Fre-
quency of generation is at regular intervals-e.g., each foot, and
is based on a change in the chromatograph sample depth.
294
14. Lagged, continuous mud-property records contain the sensor-
derived properties of the drilling fluid-e.g., density, temperature,
conductivity, and gas. The records are generated automatically with
an incremental change in depth of returns. To permit comp"lrison
of "in" and "out" properties of the drilling fluid, the "lagged in"
and "lagged out" values are also recorded. Frequency of genera-
tion corresponds to the frequency selected for the depth-based drill-
ing records.
15. Cuttings/lithology records contain details of the microscopic
examination of cuttings from the wellbore, including lithological
type and description, as well as test results from the cuttings, such
as bulk density and calcimetry. The records are generated for each
sample examined, as determined by the sampling requirements for
the well.
16. Hydrocarbon-show records serve as "addenda" to the cut-
tings/lithology records and are generated when hydrocarbon shows
are indicated. Record content includes such items as fluorescence,
solvent cut, and oil stain.
17. Cementing records contain data relating to cementing activi-
ty at the wellsite-e.g., pressures, flow rates, and volumes pumped.
They are generated on a time basis, with the interval determined
by the required degree of detail.
18. Drillstem-testing records contain data relating to well test-
ing activity and are generated on a time basis consistent with the
required degree of detail.
SPE Drilling Engineering, December 1989
 lADe TAPE FCIRHAT
DATA DATA
REEL TAPE fllE HIRMAT FORMAT FU TAPE
HERDE"R HERDER HERDER SPEC· SPEC. DATA TRAILER TRRILER
RECORD RECORD RECORD RECORD RECORD RECORD RECORD
tON

/
/
DATA FORHAT "-
"-
SPECIFlCATlON RECORD
,..-~
DRTUtI
ENTlIl SPEC.
BLOCKS BLOCK -I

-- -- ----
!l'ARA. -U -II

..........-

- ..........-
__ DATUM SPECIFICATION BLOCK (TYPE rI. SUBTYPE 11 (RECCAO 1. PARAH.
11 __

IVfEMQNIC
SERVICE
ID
SERVICE
IIRDER -
UNITS API
CCIOES .
FIlE
~ • -
SAMPLES
IW::...
gmf..
PRIICESS
INDICA-
TilliS
t t
I I

PA~EFlNEO "IECOAO
R CORD -.L

- . sm..
P'ANIIIETElI
I)ESCRPTJOII (EMClNlC UIIJT~ ''i''
REP. CIIOE
1
;z

II I t f I
Fig. 3-Example of DFS of predefined record.

19, Configuration records contain details of the drillstring ge-
ometry, wellbore geometry, pump specifications, vendor identifi-
cation, etc. These records are used to provide the data base with
descriptions of the environments in which other data are collected.
A new record is generated after one or more data items in the record
are changed.
20. Mud-report records contain information normally measured
and recorded at the well site on the drilling-fluid report. A record
is generated for each new report.
21. Bit-report records contain information pertaining to the drill
bit-e.g., type, manufacturer, size, and jets. Frequency of gener-
ation is once per trip in or trip out for a bit (i.e., two records per bit).
22. Comment records permit descriptive information to be in-
cluded within the data stream or data tape and can be generated
at any time.
23. Well-identification records contain such information as oper-
ator, well name, well location, and elevations. In addition, custom
field identifiers indicate where customization of spare fields in prede-
fined records was milde. The record is normally generated only
at the beginning and end of tapes or at the beginning of a data
transfer.
24. Vessel-motionlmooring-status records are used with floating
rigs and are generated at time intervals determined by prevalent
weather conditions and the degree of detail required by the operator.
25. Weatherlseastate records provide environmental information
to the operator. The frequency of generation is on a time basis,
determined by prevalent weather conditions and the degree of de-
tail required by the operator.
Documentation of Predefined Records. The content of predefined
records was established to facilitate a simple implementation into
the LIS format. Within LIS, each predefined reCord is described
by a DFS record. Each parameter block within the DFS describes
an item of the predefined record. A DFS parameter block (Fig.
3) has the following entries: data-item mnemonic, service identifi-
cation, service-order number, unit mnemonic, API codes, file num-
ber, size, null, number of samples, representation code, and process
indicators. Of these, the following are documented for each item
in the record: the data item and unit mnemonic (from the data dic-
tionary), the representation code (the binary format of the data),
and size (the number of bytes taken up by the data, as determined
by the representation code in the case of numerical data).
Table 2 shows the general layouts of a predefined record. In the
case of unit-mnemonic definition, two alternatives are supplied. The
first set of units is SI metric; the second is FPS (i.e., Imperial, or
English, units). For any particular application, the set of units to
be used should be decided in advance because no switching between
sets can occur.
As a further definition of a particular item, the service identifi-
cation entry of the DFS parameter block was adopted for identifY-
ing the sources of certain parameters. For example, if the data item
is fluid density, the service identification might contain the mud-
balance, differential-pressure, nuclear, or buoyancy measurement.
This may prove useful in later analysis, where the degree of data
accuracy may be questionable.
Standard Null-Value Usage. Two standard null values are used
within the records in the place of missing numerical data. (1) When

SPE Drilling Engineering, December 1989 295


TABLE 3-PARAMETER MNEMONIC SUFFIXES
Suffix Definition
A Average
C Cumulative
I Instantaneous
N Minimum
X Maximum
a sensor fails or when any condition causes an invalid data value
in a field, that field must contain the number -8888. (2) If a data
item is simply not available or is unrequested, it should contain
the number -9999. Note that this applies only to numerical data.
Fields defmed as text fields (Code 65) would contain a blank string
or "not available" message.
Guidelines for Further Parameter and Record Defmition. To
maintain consistency in the creation of new parameter mnemon-
ics, follow these guidelines.
1. Where a new parameter naturally falls within a group of ex-
isting parameters, the mnemonic should follow the general form
of the group. For example, bit parameter mnemonics have B as
a prefix, mud-report parameter mnemonics have MR as a prefix, etc.
2. When a parameter has several variations-e.g., minimum,
maximum, or average-the parameter mnemonic should have a
common root, with a suffix (see Table 3) indicating the type of read-
ing. For example, for hookload readings, the standard four-character
mnemonics are HKLI, HKLN, HKLX, and HKLA.
3. The eight-character mnemonic should be as similar to the four-
character mnemonic as possible, and the extra characters should
be used for easier interpretation of the variable.
4. Customized records must follow the general structure of the
predefined records.
5. The key entry of a record, other than date and time (which
appear in the header), should be on the first entry of the main body
of the record-i.e., Entry 8.
Final Documentation. The final documentation for the parameter
and record definition consists of a detailed layout for each of the
predefined records, with a glossary of definitions for each record
entry, a standard list of parameter mnemonics, a standard list of
unit mnemonics and conversions, and guidelines for future ex-
pansion.
WITS·Compliant LIS Format
Because LIS is a clearly defined format specification, we were able
to define a set of restrictions to the specification that satisfied the
requirements of WITS Layer 3.
File Header Records. The service sublevel name should be
"WITS" and the version number (e.g., WITSOI).
File Trailers. File, tape, and reel trailers are required.
Data Specification Records (Type 64). Entry Block 13 is not al-
lowed. This implies that only one way represents depth (e.g., as
a data channel). Only a Type 0, Subtype 1 data specification block
is allowed. All API curve codes may be set to zero. "Fast" chan-
nels (e.g., spectrum data) are allowed. Fields may be represented
by an Inst. of Electronic & Electrical Engineers 4-byte floating point
number (representation code ;::= 128).
Data Records. Only one data frame per data record is allowed.
The maximum number of data record types is 32, and the range
of data record types is from 0 to 31.
Physical Records. The maximum length is 1,024 bytes. Physi-
cal record trailers (file number, record number, and check sum)
must be present.
Logical Records. The maximum length is 64,000 bytes.
Bidirectional Format
In addition to the compliance to LIS, a set of five specifications
is included in the WITS Layer 3 so that bidirectional messages can
be sent within the context of the specification data stream.
296
1. Data sent in either direction will be self-contained LIS data sets.
2. Bidirectional commands are to be transmitted as LIS comment
records.
3. The bidirectional command syntax, Command
KEYWORD 1 = V ALUE,KEYWORD2 = VALUE, ... CR/LF,
command should be '$WITS$' linked with a mnemonic (e.g.,
$WITS$SETCLOCK TIME = 13:47:50 DATE=01l06/87).
4. Both the "sender" and "receiver" can send bidirectional
commands.
5. Higher-level WITS-LIS senders should have the ability to proc-
ess custom-format requests.
Intrarlg Transfer Protocol
This protocol allows various computers at the rig site to share in-
formation. In cases where several service companies gather data
at the wellsite but only one transmits the composite data stream
to town, the various other data sources pass the information to the
vendor. This particular method is intended for the transfer of data
in a real-time rather than a batch mode, but it can easily be adapted
to a batch-transfer method.
Physical Connection. For simplicity and ease of use, we recom-
mend use of an RS-2324 serial connection with 25 pin connectors,
a data communication equipment (DCE) connection at the collec-
tion port (i.e., receiver), and a data terminal equipment (DTE) con-
nection at the transmission port (i.e., transmitter). The communi-
cation rate is decided between parties (300 to 9,600 bits/sec). Un-
less otherwise specified, a rate of 1,200 bits/sec should be assumed.
Short-haul modems may be used where necessary.
Software Protocol. No error detection, correction, or retransmis-
sion of data is allowed. Flow control/pacing is handled by an
"XON/XOFF" method. Data are converted to ASCII, using only
seven bits (printable characters), before they are sent. Communi-
cation parameters are eight data bits, one stop bit, and no parity.
Transmission. A transmission session comprises a series of data
sets, each of which represents a group of related data items (e.g.,
several cementing data items from the same time interval). A data
set may be mad,e up of only one item, or it may comprise many
items. In fact, successive data sets may contain different numbers
of items. A data set begins with a pair of ampersand characters
(&&) (HEX 26) followed by a carriage return/line feed (CR/LF).
A data set is terminated by a pair of exclamation marks (!!) (HEX
21) and CR/LF. Again, each data set is made up of one or a num-
ber of data items that are separated by a CR/LF (HEX OD, OA).
Data Items
Each data item corresponds to a predefined record variable. Each
item consists of an "identifier" and a "value" portion.
The identifier consists of four characters. Characters 1 and 2 iden-
tify the predefined record. Characters 3 and 4 identify the item with-
in that record. For example, Resistivity 1 Depth (DRl) is Item 11
of Predefined Record 8 (MWD formation-evaluation record); thus
identifier = 0811.
The value portion of the data item is "free form" to a degree.
It may be a text string, or it may represent a number. A text string
must be the same length as specified in the record. It may contain
spaces, special characters, etc., but not && or !!. A numerical value
may be any length desired but must include at least one number.
Ifpresent, a negative sign must be the first character. There should
be no leading spaces or zeros. A decimal point, if present, may
fall anywhere before the CR/LF. For example, with the example
of Resistivity 1 Depth, the full data item might be 08113561.35
CR LF.
Example Transmission Session
The example transmission session consists of data sets containing
four data items (Resistivity 1 Depth, Resistivity 1 Reading, Gam-
ma Ray 1 Depth, Gamma Ray 1 Reading).
&& CR LF
08113561.35 CR LF
SPE Drilling Engineering, December 1989
 TABLE 4-RECOMMENDATION FOR ELECTRICAL INTERFACE (PHYSICAL LAYER)
FOR TRANSMISSIOft.l OF BIT STREAM DATA BETWEEN CONNECTED
PHYSICAL TRANSMISSION MEDIA

Baud Rate for CPU-to-CPU Connection

Function 300 1,200 Above 1,200
Character set Full ASCII Full ASCII Full ASCII
(alphabet)
Data flow DTR/DSR or DTR/DSR or DTR/DSR or
control (use XON/XOFF XON/XOFF XON/XOFF
either method)
Byte structure 7 data bits 8 data bits 8 data bits
1 parity bit

Mark parity, Mark parity, Mark parity,

RCVR need not RCVR need not RCVR need not
check receiver check receiver check receiver

1 start bit, 1 start bit, 1 start bit,

2 stop bits 1 stop bit 1 stop bit
Device interface RS232C Pins 1, RS232 Pins 1, RS232 Pins 1,
2,3, and 7 2,3, and 7 2,3, and 7

Use Pins 6 and 20 Use Pins 6 and 20 Use Pins 6 and 20

for DSR/DTR for DSRlDTR for DSRlDTR
flow control flow control flow control

ISO 2110-1980E ISO 2110-1980E ISO 2110-1980E

D Connector D Connector D Connector
Medium interface CCITT V.21 CCITT V.23 Not specified
(Bell 103) (Bell 212)
defines frequency defines frequency
and levels and levels
Restrictions Optional linefeed Optional linefeed Optional linefeed

0812.97 CR LF DATA SET 1
08173565. 13 CR LF
081897.1 CR LF
&& CR LF
08113561.61 CR LF
08121.02 CR LF DATA SET 1
08173565.39 CR LF
0818100.4 CR LF
!! CR LF
Telecommunications and Data Transmission
With the concept of a multilayered approach and the knowledge
of the data type and format, the telecommunication subcommittee
established the file-transfer pathway to move the digital data from
the rig site to a central site. Referring again to the model in Ref.
1 and Fig. I, the physical and data-link layers were related to a
drilling environment. When specifications are recommended in a
field as large and diverse as telecommunications, compromises are
necessary. The IADC's RIM committee developed these specifi-
cations in anticipation of industry requirements.
Physical Layer_ The physical layer provides for the transparent
transmission of the bit stream between the connected physical trans-
mission media. It can also be described as the electrical interface.
Although this layer includes communication between a computer
and a peripheral device, the RIM committee decided to deal with
computer-to-computer interface only.
Before the committee recommended the physical-layer standard,
three baud-rate scenarios were reviewed: 300, 1,200, and > 1,200.
Table 4 summarizes the recommendations, which call for use of
a subset of the Electronic Industries Assn.'s electrical interface. 4
This is by far the most popular standard for serial binary data in-
terchange in use today. This American standard has an international
equivalent known as CCITT V.21 produced by the Consultative
Committee for IntI. Telephone and Telegraph. 5
Technical Considerations_ Five technical areas were addressed in
the evaluation of the drilling industry's needs for the physical lay-
er (Table 4).
SPE Drilling Engineering, December 1989
Character Set. A full ASCII character set or alphabet is im-
plemented in WITS.
Data Flow Control. This method of controlling the flow of data
between equipment prevents one device from being overloaded with
data from another device. There are two ways of achieving this,
and both are supported in WITS. The hardware method uses Pins
6, "data set ready" (DSR), and 20, "data terminal ready" (DTR),
on the RS232C Connector D interface. 4 When the DTR pin has
a signal, data can be transferred. When this signal is turned off
by the receiver, however, the sender will stop sending data.
The second method uses software to control data flow. A special
XOFF character sequence is sent to the sending device, indicating
that the receiving system cannot accept more data. When the receiver
can accept more data, it sends an XON signal to the sender. This
method does not require the use of Pins 6 and 20 on Connector D.
Byte Structure. Bytes consist of seven data bits, two stop bits,
and one start bit for 300 baud, and eight data bits, one stop bit,
and one start bit for 1,200 baud and higher. Mark parity is used
on the transmitting end with no parity at the receiver.
Device Interface. The RIM committee recommendation also calls
for the standard use of the ISO 211 0-1980E connector, commonly
known as the 25-pin D connector. The following signal configura-
tion is specified:
Pin Signal
1 Frame ground
2 Transmit data
3 Receive data
7 Signal ground
For hardware flow control, Pins 6 (DSR) and 20 (DTR) may be
used. The RS232C standard has some shortcomings, most of which
are associated with electrical interference. It is a single-ended
interface-i.e., all signal changes are relative to a single ground
or reference point. Electrical conditioning problems or interference
can thus result in data errors, which can be minimized by observ-
ing the RS232C standard for cable length (15 m [49 ftD or by using
a shielded cable in an electrically noisy environment.
Medium Interface. WITS recommends the use of Bell 103 mo-
dems, which are equivalent to CCITT V.21 moderns, for a 300-baud
297
transmission rate and the use of Bell 212 modems, which are equiva-
lent to CCITT V.23 modems, for baud rates of 1,200. These stan-
dards are common in the telecommunication industry and account
for virtually all data-communication modems in use for baud rates
up to 1,200.
Data-Link Layer. The data-link layer of the ISO model handles
the transfer of a unit or fIle of information between the host devices
at either end of the physical link. This function can be accomplished
by either hardware or software systems. There was considerable
discussion about which approach would best suit the needs of the
drilling industry. Several committee members favored the use of
such hardware systems as modems or statistical multiplexors. These
are essentially off-the-shelf black-box devices that, when placed
at either end of a short- or long-haul communication link, will al-
low data transfer. Some models come with error-correction capa-
bilities, which ensure that corrupt data will not be received. Despite
the relative ease of implementation of this solution, this approach
has some serious shortcomings. First, a specific device will nor-
mally communicate only with a similar model at the other end of
the link. This could lead to a multiplicity of hardware in an opera-
tor's office. Second, for competitive reasons, the committee did
not recommend particular brands of hardware. Third, although
deregulated in the U.S., the use of communication hardware is tight-
ly regulated in almost every other country. This could lead to se-
vere operational problems in getting hardware approved for use
in certain countries. Because the goal of the ITC was to recom-
mend an international standard, the use of certain hardware that
is not internationally accepted is not appropriate. The ITC is aware
that certain operators may choose a hardware solution to the fIle-
transfer problem for domestic application. For an international stan-
dard, however, a software solution is recommended.
File-Transfer Protocol. A review of the potential software solu-
tions to this problem revealed the existence of several fIle-transfer
protocols (FTP's) designed to transfer data over a communication
link. An FTP is a formal set of conventions that governs the for-
matting and transferring of sequential information fIles over an asyn-
chronous communication link. This section addresses the data-link
layer (Layer 2) and the transport layer (Layer 4) (Fig. 1). The net-
work layer (Layer 3) is not applicable.
The purpose of this layer in the communication link is to trans-
fer a unit of data between host devices at either end of the physical
link, particularly to transfer rig-site data from a sender at the rig
site to a remote receiver. This function can be accomplished by
hardware, software, or combination systems.
The five requirements for the transmission of digital rig-site data
are bidirectional communication, error correction, the ability to han-
dle 8-bit binary data, hardware or software flow control, and the
ability to operate with no knowledge of data or data formats.
Several FTP's were evaluated. Many were specific to certain
hardware systems, but the one that most closely met the lTC's criter-
ia was called KERMIT. 6 The KERMIT FTP was developed at
Columbia U. to connect an ever-growing number of micro- and
personal-computer users with various large mainframes. Although
not in the public domain, use of KERMIT does not require a license,
and it is freely distributed by Columbia U., which requires that
anyone implementing the protocol follow their liberal policy on com-
mercial use. 7
The KERMIT FTP has many advantages.
1. It ensures error-free transfer of ASCII and binary data fIles.
2. The FTP is well-documented and includes protocol and users
manuals.
3. It is widely used and can be implemented on more than 200
different machines and operating systems, including personal com-
puters.
4. The system is well supported by Columbia U., which oper-
ates a users hotline.
5. KERMIT distribution centers are located in the U.S., the U.K.,
France, and Germany.
6. The FTP satisfies the efficiency requirements of the explora-
tion industry.
298
Although KERMIT fulfills many of the lTC's selection criteria
for an international standard, there are some negative aspects to
its use.
1. The KERMIT FTP requires a full duplex communication
channel.
2. It is not a true real-time, bidirectional protocol, but a protocol
that deals with discrete fIles.
3. It does not establish the communication link.
4. The FTP does not monitor the communication line.
5. Efficiency deteriorates when eight Big Binary fIles (e.g., the
WITS-restricted LIS format) are handled or when communication
is delayed (e.g., in single- and double-satellite hops).
Even though there are some negative aspects to this FTP, the
overall advantages outweigh the disadvantages. Thus, the ITC adopt-
ed the KERMIT FTP to fulfIll the requirements for the ISO OSI
data-link layer in a drilling environment.
Conclusions
The greatest and most easily visualized benefits of using WITS are
the cost and time savings. Most rig data can be handled adequately
by Layer I of the specification, and WITS documents can be used
to construct programs that easily implement the specification.
WITS provides a common language for information exchange
between service and operating companies. When service is to be-
gin, the two companies simply decide which layer of WITS is to
be used in information transfer (depending on the requirements and
limitations of the current situation), and transmission begins when
a communication link and an FTP are established. As long as the
two companies know that they have data formatting and reading
programs that correctly implement the WITS layer, no lengthy
reprogramming, testing, or debugging will have to occur.
We anticipate that as WITS is implemented by a wide range of
operating and service companies, third-party vendors will produce
implementations of all specification layers that will be available as
off-the-shelf software or hardware/software components, making
additional cost and time savings available. Many third-party soft-
ware vendors are eager to enter the market for rig-to-central-site
information-transfer systems, but have been reluctant to do so in
the past because of the large number of incompatible formats in
use. WITS should encourage competition between vendors.
The existence of standardized data formatting and reading pro-
grams not only makes rig-to-central-site data transfer easier, but
also makes possible the transfer of pertinent information between
service companies at a site or between operator central sites. The
capability for data transfer between service companies promotes
the use of advanced analysis methods that use data from diverse
sources to make inferences and decisions. The capability for trans-
fer between operators allows easy sharing of information in part-
nerships or in other joint efforts.
Additional issues that will be addressed in the final standards but
that are not presented in this paper are the standardization of oper-
ator drilling forms and the multiplexing of mUltiple rig-site con-
tractors' data to a communication operator, perhaps a data-logger
unit. This networking of independent data sources is necessary to
avoid excessive communication costs and complications.
Acknowledgments
L.H. Robinson, chairman of the RIM committee, was instrumen-
tal in establishing and coordinating the RIM subcommittees. L.
Fluornoy initiated the original ITC. R.L. Graff assisted in the or-
ganization and planning of committee activities. The IADC's RIM
committee is indebted to the many operating and service compa-
nies that provided staff and logistical support for this project: Amoco
Production Co., Anadrill/Schlumberger, Arco Oil & Gas Co., BP
Exploration Inc., Datalog Inc., Digitran, Exploration Logging
U.S.A. Inc., Exxon Production Research Co., Gearhart Industries
Inc., Geoservices Inc., Halliburton Services, Martin-Decker, Mobil
E&P Services Inc., NL Baroid Logging Systems, Petrolog, Schlum-
berger, Shell Oil Co., Sonat Exploration, Stratagraph, Teleco Oil-
field Services, and Tenneco Oil Co.
We are indebted to the many people who contributed their ef-
forts and skills to the information-transfer working subcommittees.
SPE Drilling Engineering, December 1989
In particular, J. Bland, T. Broussard, A. Citerne, T. Guidry, J.W.
Hebert II, Y.M. Jan, R. Kastor, P. Kelly, D. Kroger, C. Martin,
R. Rose, M. Schultz, P. Segrest, W. Simmons, L.A. Sinor, and
M. Taylor were instrumental in defining the records and parame-
ters and the restricted LIS model. E. Gass, J. W. Hebert II, D.J.
Lafferty, R. Lake, D. Lovenvirth, P.C. McGuff, V. Neathery Jr.,
E. Olstad, T. Sommer, and C. Sonnier aided in evaluating and lab-
oratory testing a file-transfer system. I. Brouwer, R. Isaacs, D.
Lafferty, M. Lawrence, E. Oistad, A. Orban, C. Sonnier, R. Wil-
liams, and R. Wolfe integrated the mnemonics and record formats.
G. Gaggero introduced the LIS format to the committee.
Additional special thanks are due R.L. Graff, D.J. Lafferty, P.C. 7. da Cruz, F.: "Policy on Commercial Use and Distribution of 'Kermit,'''
McGuff, V. Neathery Jr., E. Olstad, A. Orban, R. Rose, M. -
Schultz, W. Simmons, M. Taylor, and R. Veenkant, whose con-
tinuous support, dedication, and enthusiasm for the project made
this publication possible.
References
1. "Reference Model of Open System Interconnection," American Nat!.
Standards Inst., ISO/TC97/SCI6, Document No. 27 (June 1979).
SPE Drilling Engineering, December 1989
2. Log Information Standard, customer tape subset, Schlumberger, Houston
(Oct. 1976) 48. •
3. Froman, N.L.: "DLIS: API Digital Log Interchange Standard," The
Log Analyst (Sept.lOct. 1989) 30, No.5, 390-94.
4. "Interface Between Data Terminal Equipment and Data Communica-
tion Equipment Employing Serial Binary Data Interchange," Electron-
ic Industries Assn., EIA Standard RS-232-C (Aug. 1969).
5. "Data Communications over the Telephone Network," American Nat!.
Standards Inst., CCITT Yellow Book, CCITT V-Series Recommenda-
tions (1981) VITI.I.
6. da Cruz, F.: KERMIT, A File Transfer Protocol, Digital Press, Bedford,
MA (1986) 379.
Columbia U. Center for Computing Activities, New York City (Sept.
1985).
SPEDE
Original SPE manuscript received for review March 15, 1987. Paper accepted for publica·
tion June 29, 1989. Revised manuscript received June 9, 1989. Paper (SPE 16141) first
presented at the 1987 SPElIADC Drilling Conference held in New Orleans, March 15-18.
299