An Introduction to WITS
Partner – Engineer
What is WITS?
I get quite a few emails from people asking simple questions about WITS, so I thought it was time to write a simple introduction. WITS stands for “Wellsite Information Transfer Specification” and it’s a specification, however loose it may be, that allows for data transmission between Oil and Gas digital systems. Even though this specification has been succeeded, a lot of rigs and other oilfield equipment still use it. I personally enjoy it for it’s simplicity.
Want to get started quick?
Erdos Miller can help. If you need to implement a WITS based system our experienced engineers can assist you. Please call 1-888-337-0869 or email us. If you’re looking to accelerate your current team we have WITS libraries for Python, LabVIEW and C#. While not yet available for sale online, they are available by request.
Can you give us an example of a real-world use of WITS?
Most wells drilled today are directional, meaning they deviate from a vertical hole. To achieve this multiple systems and teams are required. A rig is required to drill the hole, an MWD tool is required to provide directional information, and an EDR system is deployed to monitor the drilling operation. An MWD tool (Measurement While Drilling) is a electronic down-hole tool that is capable of gathering telemetric and formation data and transmitting it up-hole during drilling operations, this allows the rig to steer in real-time. A modern EDR system (Electronic Data Recorder) is composed of sensors, data acquisition, computers, and a database. It’s job is to acquire data from a large number of rig sensors, display the data to the rig crew and other parties, and store it in a database. The EDR is typically provided from a 3rd party vendor to the drilling contractor for a particular rig. So the challenge is to acquire the MWD data and then transmit it to the EDR system so that the rig crew can easily see the real-time telemetric and formation data and make steering and drilling decisions. WITS meets this challenge superbly by providing a very simple link for the MWD systems to transmit data to the EDR system in real-time.
Example WITS Tranmission
Don’t be afraid.
If you get ahold of the WITS specification you might be a little scared at the complexity and all of the “levels” it mentions. So far we’ve interfaced to a dozen different WITS systems and everyone employs some form of WITS, which is the first level. This means the majority of the spec sometimes goes unused. At it’s simplest WITS defines very straightforward data packets that are exchanged over serial. Everyone does things a little different, but not different enough to worry about, and your code will work with most vendors if you do it right.
WITS over serial works by exchanging packets over a full-duplex serial bus. So far we’ve experienced two methods of transfer between systems, synchronous and asynchronous. In the synchronous method, one system will request transmission of a packet from another system by sending a “dummy” packet. For example some EDR systems require a dummy packet, or a data packet, to be received before they’ll transmit back a packet. Sometimes a system will accept an empty dummy packet, other times it’s best to transmit some data in the dummy packet. For your dummy packet choose a null value or something non-volatile like the vendor string. (Rec: 19 Item: 84) With the asynchronous method both systems will exchange data (usually at some specified interval) without any sort of request, basically just streaming. 1 packet per second is a typical rate for most systems using the time-trigger method. With the asynchronous method it is not necessary for both systems to exchange data, one may simple transmit to the other continuously while the other receives.
The WITS Packet.
A WITS packet is actually quite straightforward. It’s a series of serial characters that are sent together representing a collection of data. Here’s a simple packet structure.
The first line “&&” state that a packet is beginning. The following lines (zero or more) contain data. A data line has a simple structure, it starts of with two characters that represent the record number or the item. The next two characters represent the item number in the record. Together the record identifier and item identifier precisely identify a data type. You can see the record definitions here. Following identifiers is the data. This can be a string, an integer, a floating point number; anything goes. The specification lists that only certain data types of certain lengths can be transferred. This is pretty much ignored; be prepared for anything of any length in this section. The last line “!!” ends the packet.
The most common delimiter is “\r\n”, you’ll sometimes find other delimiters “\n” or others used.
A lot of companies like to use null values to represent a data item that isn’t present. A typical null value is -9999.9 or -9999.0. When you see a value like this you’re supposed to ignore it. It is not the current reading for that item. Make sure you talk to the vendor you’ll be interfacing with and understand what they consider to be null values or you might end up displaying some odd values.
TCP and Serial.
While this article focuses mostly on WITS over serial, another popular option is to transmit with WITS over TCP. This is essentially the same thing, you open a TCP stream and simply send packets as you would over serial.
What is this new WITSML thing I keep hearing about?
WITSML is the successor to WITS. It’s not intended to be covered by this article and is quite a bit more complicated than WITS (it uses SOAP and XML and is primary intended for IP communications.) There’s lots more info on it here.
If you’re looking for more detailed information please see here.
Partner – Engineer