Wellsite Information Transfer Standard level 0 (WITS0) is a communications protocol used to transfer drilling and geology data between computer systems at a wellsite, developed in the mid-80s. It involves the serial streaming of pre-defined record, channels and values. It is a simple protocol for streaming real-time sensor data, unchanged for the past 30 years.
Wellsite Information Transfer Standard Markup Language (WITSML) is a predecessor to WITS0 built on the W3C Internet standards XML, SOAP and WSDL in the early 2000s. Influenced by some of the industry's largest operators (BP, Statoil, etc.) and now managed by Special Interest Group, Energistics, the protocol was designed to take advantage of newer technologies such as Ethernet and TCP/IP while supporting much larger sets of data and data types.
So when aggregating (or transferring) real-time data between systems and companies at a rig, is WITSML the go-to standard for transmitting data? Think again.
According to Energistics:
Some implementations of WITS may still exist, but all new development should be done using WITSML."Some" is an understatement. I've lived and breathed WITS0 and WITSML at dozens of rigs domestically and internationally, working with service companies large and small. It is true that many of them (typically the larger companies) have systems with the capability to transmit WITSML with each other at the wellsite, but it is a minority. The de facto standard for transmitting real-time data between systems and companies at the wellsite is still good ol' fashioned WITS0.
Unlike an oil production facility or platform, where an operator typically owns and operates all aspects of the operation (down to the sensor level), a drilling rig has many counterparts. The operator that oversees the operation, you have the rig contractor which owns and operates the drilling rig, you have the mud logger, the MWD/LWD provider, the cementer, and so on. Sensor data and information is collected by each of these companies, stored in disparate systems often on isolated networks.
WITSML has clearly become a viable standard for drilling data storage, transmission between sites and interoperability with other applications used to process or display data. It is also a viable mechanism for data delivery off the wellsite to onshore datacenters, over unreliable satellite communications (although many companies utilize proprietary protocols for this). However, it still outdone by WITS0 for intra-rig data streaming for a variety of reasons:
- If it ain't broke, don't fix. The oilfield is sometimes a place where change is slow. It's better to stick with what works, since time is money and it's better to have rig personnel focused on what matters most: finding oil safely. Instead of leveraging WITSML, companies instead have made WITS0 fit to newer requirements.
- Designed before TCP/IP, WITS0 is serially streamed using protocols such as RS-232. Today, many companies have software that streams WITS0 directly out their PC's serial (COM) port or to an IP address on their Local Area Network.
- Originally defined with just 25 records in the standard (with various channels in each), WITS0 can theoretically support any two-digit record and two-digit channel. That means records 26-99 are essentially unused and free for additional data the operation requires, with up to 99 channels in each. If using RS-232 serial, be careful about that baud rate though. The more data you stream, the higher the baud rate required.
- Security is everything. Because a drilling rig has multiple companies that need to share real-time data, each with their own PCs on separate networks, it is often against IT policy to bridge networks to have a direct TCP/IP connection. Drilling rigs are in some of the most remote locations in the world where there aren't an abundance of IT professionals to install secured networks and firewalls that allow this type of communications. A PC's RS-232 serial port (with WITS0) is usually the method for streaming data between company systems. A virus or malicious software cannot traverse a serial port, so this type of physical connectivity is deemed secure. Don't have a serial port available on the receiving end or need to cover a large distance between systems? No problem, inexpensive serial-to-Ethernet adapters can make this happen and still offer the same level of security.
- Low overhead. WITSML transfers between two systems involves a query and response, sharing information within structured XML. This results in a large amount of header and metadata information encapsulating the actual real-time data that is redundant and inefficient for fast data streaming. This is fine for inter-datacenter data transfers, but it can eat away at bandwidth and processing power. At a drilling operation, data must be transferred with high frequency and low latency, often at 1-second interval. WITS0 accomplishes this by simply sending records, channels and values in a continuous stream at high frequency. All header and metadata information is mapped on both ends, removed from the feed itself.
- More control. WITS0 is still the king for transmitting data at a wellsite, but most systems will ultimately convert and store the data feed into a WITSML Store for accessibility to other applications and viewers. The WITSML Store structures the raw WITS0 records and channels into a series of time- or depth-indexed objects called logs. It also stores other well data not found in WITS0 such as the trajectory, message and mudlog objects. Depending on the software package used to do this conversion to the WITSML Store, you may only have control inbound WITS0 data and not WITSML. In this case, you have complete control over the mnemonic name, log name, description, well, wellbore, even timestamp that you use to store the data in your WITSML Store. This can enable an operator to, for example, standardize naming and organization conventions for similar data received across multiple service companies. WITSML transfers between systems usually means that the source of the data dictates all header and metadata information, which the receiving end must preserve unless tools are leveraged to manipulate/change this information.
The future is bright however, as Energistics has announced WITSML 2.0 with Energistics Transfer Protocol (ETP - due sometime in 2015). The protocol promises more efficient data transfer, leveraging WebSockets, Avro and JSON. This will likely be a big change for transmitting WITSML data between datacenters or from the wellsite to onshore, but it remains to be seen how much it will influence the intra-rig data communications that use WITS0 today.