WITS (Wellsite Information Transfer Specification) Fundamentals
The WELLSITE INFORMATION TRANSFER SPECIFICATION (WITS) is a communications format used for the transfer of a wide variety of wellsite data from one computer system to another. It is a recommended format by which Operating and Service companies involved in the Exploration and Production areas of the Petroleum Industry may exchange data in either an online or batch transfer mode.
WITS is a multi-level format which offers an easily achieved entry point with increasingly flexible higher levels. At the lower levels, a fixed format ASCII data stream is employed, while, at the highest level, a self-defining customizable data stream is available.
A WITS data stream consists of discrete data records. Each data record type is generated independently of other data record types and each has a unique trigger variable and sampling interval. The rig activity usually determines which records are applicable at any given time such that only appropriate data is transmitted.
WITS also incorporates the means for a remote computer system to send instructions to the sending system in order to set or change certain parameters, including the type of data transmitted and the interval for transmission.
As well as specifying a format for data transmission, WITS also defines a basic set of pre-defined records to which user-defined record types may be added.
WITS has been used extensively for a number of years by working for many operators around the world to facilitate information-sharing and to provide data to remote monitoring facilities.
Over the years many Operating and Service companies developed proprietary formats for electronic data exchange. When a new working relationship was established between a Service company and an Operator, new software often had to be written, followed by extensive testing and debugging before the data collection and analysis systems of the two entities could communicate with one another correctly. This often led to problem start-ups with the resulting loss of time and data. The ongoing development and maintenance of these formats represented a significant expenditure.
The cost and complexity of format matching and modification often led to a reluctance on the part of some Operators to get involved in this type of service, and a great deal of rig data, which might have been extremely useful in rig performance evaluation, drilling monitoring and control, and formation evaluation while drilling, was often not collected or was not readily available to decision makers.
In an attempt to resolve this information transfer problem, the Wellsite Information Transfer Specification was established .
A number of Operating and Service company representatives with wide experience in the areas of computer software system development, geology and drilling engineering formed the first workgroup to look into the needs of the industry in this area. All were familiar with the problems associated with the profusion and mismatch of rig data formats.
To ensure that any format proposed was both complete and acceptable to the industry as a whole, a vigorous effort was made to involve representatives from as many Operating and Service companies as possible. This effort included correspondence with companies operating in Europe and Asia as well as the United States.
The goal of the work group was broad but concrete:"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".
To minimize omissions in the format, a major effort was made to obtain an inventory of data items monitored or collected at the wellsite in the following areas:
- Drilling Engineering
- Measurement While Drilling (MWD)
- Rig Parameters
- Drill Stem Testing
Companies providing data collection services in these areas were polled for data items and formats currently in use. Concurrent with the effort, the group's members familiarized themselves with the major existing formats and data transmission systems in use in the industry. With a comprehensive data dictionary established and with representatives on the subcommittee familiar with existing formats, careful consideration led to a set of requirements which, it was hoped, would satisfy the present and future needs of both Operating and Service companies.
Among these requirements were:
- achievable by both small and large companies
- adaptable to the needs of the industry over the course of time as technology changes
- offer a simple, low cost entry point
- limit long term software support costs
- employ an efficient mode of transmission
- be capable of use in both online and in batch modes
- be capable of implementation on a wide range of computer platforms
- meet the needs of both the single remote user and the multi-rig data center
- encompass existing standards (official or "de facto") where possible
- address international as well as domestic needs
With these requirements in mind, the subcommittee adopted the Log Information Standard (LIS) as the basic framework for WITS and set about formulating the specific components of the format. LIS was chosen since it met many of the requirements set out for WITS and was a well established and familiar method of data exchange (a "de facto" standard in the wireline industry).
The WITS Steering Group is also a member of the API Petroleum Information Data Exchange (PIDX). The API-PIDX WITS User Group exists to promote the format, respond to questions of interpretation, and to investigate ways of enhancing the format to meet new requirements in the future.
WITS Transmission Levels
The following summarizes the various levels of WITS:
- Also known as "Intra Rig Transfer Specification", this involves a very basic ASCII transfer format intended primarily for sharing of information between service companies, though lending itself well as a simple entry point into wellsite data transfer. Data items are identified by a numeric string tying the value to a particular location within a Pre-Defined Record, or to an agreed upon addition to the Data Dictionary.
- In Level 1 and above, the data stream takes on a binary (LIS) format. Values are expressed in LIS-defined representations (e.g. floating point, integer, string, etc) The data items are packaged into a WITS Data Record and then sandwiched between LIS Physical and Logical Record Headers and Trailers, to make up a LIS Data Record.
Twenty five Pre-Defined Records have been identified, covering, among other areas, drilling, geology, directional work, MWD, cementing and testing. At Level 1, these data records, generated at varying times and under varying rig conditions, are constructed and placed in the data communications channel.
No LIS record types besides Data Records are used at this level. Each of the 25 Pre-Defined Records has a fixed size in bytes. However, each contains designated 'spare' channels for limited customization.
The Pre-Defined Records are:
WITS Pre-Defined Record Types
Rec Name Description 1 General Time-Based Drilling data gathered at regular time intervals 2 Drilling - Depth Based Drilling data gathered at regular depth intervals 3 Drilling - Connections Data gathered at drilling connections 4 Hydraulics Hydraulics data gathered while circulating 5 Trip - Time Tripping data gathered while running in/pulling out 6 Trip - Connections Tripping data gathered at tripping connections 7 Survey/Directional Directional/Survey data 8 MWD Formation Evaluation MWD Formation Evaluation data 9 MWD Mechanical MWD Mechanical data 10 Pressure Evaluation Pressure Evaluation data 11 Mud Tank Volumes Mud Tank (Pit) Volume data 12 Chromatograph Cycle-Based Chromatograph Cycle data 13 Chromatograph Depth-Based Chromatograph data averaged over depth intervals 14 Lagged Mud Properties Mud Property data based returns depth increments 15 Cuttings / Lithology Cuttings Lithology and related data 16 Hydrocarbon Show Hydrocarbon Show related data 17 Cementing Well Cementing operations data 18 Drill Stem Testing Well Testing operations data 19 Configuration Drillstring and Rig Configuration data 20 Mud Report Mud Report data 21 Bit Report Bit Report data 22 Comments Freeform Comments 23 Well Identification Well Identification data 24 Vessel Motion / Mooring Status Vessel Motion and Mooring Status data 25 Weather / Sea State Weather and Sea State data
- WITS Level 2 builds on Level 1 through addition of WITS bidirectional dialogue through the use of LIS Comment records. This dialogue is used in synchronization at start up and after a communications line interruption, as well as permitting two-way messaging between the sender and receiver. Such messages might include requests for change in transmission intervals for certain records, for example.
- WITS Level 2b adds the option to buffer data that has been transmitted, making it available for re-transmission in the event of non-receipt of data by the receiver.
- WITS Level 4 employs a completely different format than the previous levels since it is based on the emerging data transfer standard of API RP66. The concepts of Pre-Defined Records and Bi-Directional Dialogue remain, but using RP66 as the formatting mechanism.
Participants in the steering group include:
- Baker Hughes INTEQ
- Schlumberger Anadrill
- Sperry Sun
Operating companies for wells on which WITS services have been provided:
Amoco McMoran Occidental Arco ELF Shell Norsk Hydro Gupco BHP Chevron PNG Phillips Conoco Statoil Soekor DuPont Maersk Maraven Amerada Hess Corpoven Saga Mobil JNOC Exxon/Esso BP Kuffprc Woodside
Service companies with experience providing WITS services
Baker Hughes INTEQ Anadrill Sperry Sun Martin Decker TOTCO Halliburton Dowell Schlumberger Otis Datalog
Countries/areas where WITS services have been provided
United Kingdom Norway Denmark Holland Canada Trinidad India Myanmar Tunisia United States Congo Malaysia Australia Papua New Guinea Indonesia Venezuela South Africa Egypt Nigeria Japan Namibia
The WELLSITE INFORMATION TRANSFER SPECIFICATION (WITS) is a communications format [..]
This is Circle of LabVIEW: Validation, the final blog post that describes different [..]
This is Circle of LabVIEW: Acceptance Testing, the fifth of a series of blog posts [..]
This is Circle of LabVIEW: Development, the fourth of a series of blog posts that [..]
This is Circle of LabVIEW: Requirements, the third of a series of blog posts that [..]