SPE 84066
Wellsite Information Transfer Standard Markup Language, WITSML, an Update
M.A Kirkman, SPE, BP; M.E. Symmonds, SPE, Schlumberger; S.W. Harbinson, SPE, Landmark Graphics; J.A. Shields,
SPE, Baker Hughes; M. Will, Schlumberger; A. Doniger, POSC
Copyright 2003, Society of Petroleum Engineers Inc.
This paper was prepared for presentation at the SPE Annual Technical Conference and
Exhibition held in Denver, Colorado, U.S.A., 5 – 8 October 2003.
This paper was selected for presentation by an SPE Program Committee following review of
information contained in an abstract submitted by the author(s). Contents of the paper, as
presented, have not been reviewed by the Society of Petroleum Engineers and are subject to
correction by the author(s). The material, as presented, does not necessarily reflect any
position of the Society of Petroleum Engineers, its officers, or members. Papers presented at
SPE meetings are subject to publication review by Editorial Committees of the Society of
Petroleum Engineers. Electronic reproduction, distribution, or storage of any part of this paper
for commercial purposes without the written consent of the Society of Petroleum Engineers is
prohibited. Permission to reproduce in print is restricted to an abstract of not more than 300
words; illustrations may not be copied. The abstract must contain conspicuous
acknowledgment of where and by whom the paper was presented. Write Librarian, SPE, P.O.
Box 833836, Richardson, TX 75083-3836, U.S.A., fax 01-972-952-9435.
Abstract
E&P companies are now putting more focus on collaborative
asset teamwork to speed and improve decision-making
involved with developing oil and gas fields. To facilitate such
collaboration, E&P companies are adopting shared, integrated,
IT technology to enable multi-disciplinary teams to engage in
improved workflow processes across all phases of the oil field
life cycle. Much of the data needed to feed these workflow
processes can be shared between Service Companies and E&P
companies during the planning and execution phases of the
wellbore construction process. The "right time" seamless flow
of this data between operators and service companies will
speed and enhance decision-making.
There have been a number of solutions tried over the past 20+
years, some more successful than others. The WITSML
initiative was started in 2000 to update the existing methods
for the 21st century and incorporate the lessons learned from
previous initiatives. It is sponsored by both E&P operators and
oilfield service companies, aimed at providing an industry-
wide solution for transfer of information between service
companies and E&P companies.
This paper will provide a brief review of the WITSML
initiative, its original charter and development effort. It will
then explore the current status of development for the standard
and its API, discuss the current commercial development and
the strategy, which aligns the initiative with POSC for the
support and enhancement of WITSML. In addition, the paper
will briefly discuss future potential areas of benefit for E&P
companies, such as WITSML use in the Production Phase of
the E&P life cycle.
Introduction
The aim of the WITSML (Wellsite Information Transfer
Standard Markup Language) project is to provide an improved
oil industry standard to enable the service company on the
wellsite to seamlessly exchange data with the software system
in the oil company office, regardless of it’s origin, during
wellbore construction, planning and execution phases. This
paper describes the scope, history and status of the project,
which in Phase 1 has been jointly sponsored by BP and Statoil
in cooperation with Baker Hughes, Halliburton/Landmark, and
Schlumberger/GeoQuest and NPSi. The WITSML standard
will facilitate improved “right time” collaboration between
Operator asset teams and the Service Companies.
In 2002, the introduction of commercial WITSML enabled
applications means that we now have access to a much richer
set of data from a variety of Service Companies at the well
site. Phase 1 of the WITSML project has been focused on the
movement of data from the wellsite during the wellbore
construction process. WITSML evolved during this process
from simply an XML schema to a functional implementation
of Web Services for drilling data. Later phases will continue to
improve this area and will expand the scope to include data
from the completion and workover processes.
Overview
E&P companies are now putting more focus on collaborative
asset teamwork to speed and improve the decision-making
involved with developing oil and gas fields. To facilitate such
collaboration, E&P companies are adopting shared, integrated
information technology (IT) to enable multi-disciplinary teams
to engage in improved workflow processes across all phases of
the oil field life cycle. Much of the data needed to feed these
workflow processes can be shared between Service
Companies and E&P Companies during the planning and
execution phases of the wellbore construction process. For this
to become viable, a new data exchange standard needed to be
defined and adopted by the oil and gas industry. McGinley2
states that the industry needs a new data definition standard
that will allow the efficient transfer of large data sets.
The goal of the WITSML project is to define, document, and
promote the implementation of such a standard.
During the wellbore construction process, a number of
different service companies provide data monitoring and
acquisition services at the wellsite, collecting engineering
2 SPE 84066
data, geological data, daily reporting data and well log data
from Logging While Drilling (LWD)/Measurement While
Drilling (MWD) tools. Oil company project groups have a
need to analyze this data in a timely fashion using a variety of
different processing software, running on Microsoft
WindowsTM and UNIXTM computers in widely distributed
network environments.
The scope of the first Phase of the WITSML project was to
cover the requirements of wellbore construction processes,
focusing initially on the drilling process. Later phases may
include completions, well servicing, well testing3 and well
production monitoring. The standard covers both the
definition of standard data items and the interfaces for access
to the data items. WITSML is intended for the transfer of data
in both real time and non-real time modes. The cooperation
between the operators and service companies working on this
project has been tremendous and a key element for its
ultimate success.
History
The name WITSML was chosen to acknowledge that the new
standard evolved from the existing WITS (Wellsite
Information Transfer Specification) standard, but
incorporating the modern data representation standard
Extensible Markup Language (XML).
WITS1 has been widely used since the early 1980’s to move
pre-defined data objects from point to point via serial lines or
Transmission Control Protocol (TCP)/Internet Protocol (IP)
network connections. It specifies 25 standard data records8 and
an additional 74 user defined records. The records handle time
and depth sequential drilling and formation evaluation data as
well as irregular data such as drill string and casing
configuration, drilling fluid details, well and rig information
and environmental data. Most service companies support the
generation of WITS data records and also usually provide a
WITS receiving application in an oil company office. The
WITS specification, in addition to defining the structure and
content of the data objects, also provides a number of different
ways of transferring the data from a sending system to a
receiving system. The most commonly used WITS
transmission system is WITS level 0, which transfers real time
data values as simple ASCII data streams.
While WITS was excellent for its time, it has not kept up with
the changes needed to support modern drilling practices. The
recognized limitations of the current WITS specification are:
• Outdated MWD data records
• Data is record driven, not object oriented
• Restrictions on number of drill string and
casing sections
• Inflexibility for handling data in different units of
measurement
• Limited capacity for handling static well information
• WITS records are extensible but not self-describing
• Use of binary data formats is not
platform independent
• Essentially a data “push” from the rig with little
capability to request specific information
• User defined records are all used and are not
easily exchanged
BP and Statoil initiated the WITSML project in October 2000
in cooperation with major service companies: Baker Hughes,
Halliburton/Landmark and Schlumberger/Geoquest. One of
the more interesting facets of this project is that it was
accomplished by the cooperation of these service companies,
who are normally direct competitors. This was handled by
drawing strict boundaries around the project. Inside the
boundaries, everyone cooperated fully to design and build the
standard without seeking any competitive advantage.
Anything outside of the boundaries was
considered competitive.
The first phase of the WITSML design was restricted to a
small team from the major service companies. It had a very
aggressive schedule, and it was believed that the only way to
meet this schedule was to keep the group small. For the same
reason, the scope was restricted to drilling, as that was deemed
to be the highest priority. In addition, the team decided to
concentrate on providing coverage that would handle the 90%
of cases and not to get lost in the details of trying to find a
100% solution to all cases. WITSML was well received by a
wider audience of service and oil companies at a seminar in
Austin, Texas in August 2001.
Since the Austin seminar, additional work was done to refine
and implement the standard in the second half of 2001 and
2002. The Application Programming Interface (API) was
fully implemented and commercial applications have been
written and field-tested using the standard. A second seminar
was held in Stavanger, Norway in November 2002. Version
1.2 was completed in February 2003 and a third seminar held
in Aberdeen, Scotland in June 2003.
Scope
The overall scope of the project is to define standard transfer
formats for data that covers the life of the well. Phase 1
focuses on the wellbore construction processes, specifically on
drilling. Data that has been defined and placed into standard
XML schemas for Phase 1 are:
Well Bottom Hole Assembly Ops
Wellbore Tubulars & Wellbore Geometry
Location (Casing Scheme, Open Hole)
Units Fluids Report
Logs Rig (Equipment, Pump, Bit Record)
Real Time Mud Logging
Trajectory Cement Job
Target Operations Report
The full definition of the schemas describing these data
objects can be found at http://www.witsml.org/ and are
available for download.
Later phases may address support for completions, well
servicing, well testing and well production monitoring. The
standard covers both the definition of standard data transfer
SPE 84066
formats and also the interfaces for access to the data formats.
WITSML is intended for the transfer of data in both real time
and non real time modes.
In addition to being a standard format for drilling data
transfer; WITSML also defines an API (Application
Programming Interface), which enables software programs
from different vendors to exchange data in the WITSML
format. This API will be briefly described in the technical
discussion of the Standard later in this paper.
Practical Implementations of WITSML
Referencing SPE 74480, participants in WITSML, up to the
publication date of this paper had specific ideas about some
good examples where operators would see significant benefit
from the use of WITSML. These use cases are still valid, and
other cases have become apparent. An interesting observation
from the use of WITSML over the last year is that
some implementations have become prominent among almost
all players involved, operators, service companies and
software vendors. The result has been increased efforts in
these areas.
In general terms the use cases can be defined as:
Operator to Government
Example: Filing of statutory documents relating to the well
permitting process.
Service Contractor to Service Contractor
Example: Sharing a BHA description at the rig between
different service vendors
Drilling Contractor to Operator
Example: Transferring elements of an electronic
IADC report.
Contractor to Operator
Example: Transfer of real time drilling data to corporate
data stores.
Operator to Operator
Example: Transfering daily report data to partners across
different reporting applications.
Application to Application
Example: Migrating data from one application’s
proprietary data format to another, using the
WITSML API as the mapping tool.
One of the immediate benefits that WITSML brings to
operators can be found in the use case of the real time feed of
WITSML data into the operator’s project databases.
This application has been the most common that companies
have implemented over the last 12 months. Typically,
operators update the log and trajectory data in their project
databases by using LAS formatted files, or perhaps some
proprietary source of data. Each of these provides a good
solution, but a solution that can be problematic. LAS
formatted files are strictly statically loaded data and require
3
‘manned operation’ as a batch process. The proprietary
methods can rely on standards such as WITS or others and
while data can come in real time, the service company’s
technology rarely can communicate with the operator’s chosen
solution without intervention, i.e. it isn’t plug ‘n play.
Operators benefit because they get their data much quicker
(near real time) and they can get it from multiple vendors
without integrating service company proprietary technology
into their chosen software solutions. WITSML data loading
technology connects, via the API, to a WITSML server and
loads the trajectory and MWD/LWD data directly into project
databases. The technology typically runs without human
intervention, and frequently can be administered by the data
acquisition vendor, rather than through data
management technicians.
The North Sea and Gulf of Mexico have seen significant
activity around this use case with WITSML. BP, Statoil, Shell
and several other operators are already using, or testing this
technology in these regions. The short-term focus has been to
update their project databases for real time decision-making.
The use of WITSML has reduced the need for manual data
loading and has significantly increased the accuracy of
their decisions.
Another application has been the request for WITSML time-
based drilling data. Technology now exists that provides the
‘black-box’ like capability to store and publish this
information to other WITSML subscribers, as well as
converting the information into a WITSML format from other
data types prior to storing or publishing the information. The
advantages to this type of technology are tremendous as all
data around critical drilling operations can be recorded and
published to numerous subscribers for analysis and decision-
making. The present manual process of Operator daily drilling
reporting can be considerably automated by linking drilling
contractor and service contractor reporting with the time based
drilling data.
Shell has been field-testing this ‘black-box’ technology for
their critical operations in the Gulf of Mexico and the North
Sea. Other operators also have been testing this type of
technology in the North Sea.
As the industry is viewing the success of this initiative, other
disciplines are considering the use of similar technology
employed through WITSML (XML, SOAP, WSDL) to
increase their productivity and real time decision-making
capabilities. A strong example of this is the interest in moving
the production discipline into an environment such as this.
As the WITSML standard progresses, other applications
already identified will become more widely used, and
new ones will be identified. One application that is being
tested, which wasn’t discussed in the original paper revolves
around making use of time-based WITSML data for
engineering calculations, on a more-or-less real time basis.
4 SPE 84066
BP Trinidad & Tobago are using WITSML to reduce cycle
time and alleviate problems with data integrity that come from
errors during data loading for subsurface
monitoring/steering/planning of new wells, from service
contractors, into the corporate data store. WITSML
technology will reduce time allocated to waiting on orders,
for responses from Port of Spain Office during critical
operational decisions. Direct loading of data with WITSML
allows BP to use less expertise on the rig, and more expertise
in the office for picking casing points and geosteering wells.
This contributes to safety by putting fewer people in harms
way offshore and is aligned with BP cost objectives.
The UK Department of Trade and Industry (DTI) are
evaluating the use of WITSML for well drilling data
submissions associated with Petroleum Operations Notices; to
further automate the current web based system.
WITSML Standard 1.2
Overview
The WITSML standard defines both a data format and a data
exchange protocol:
- The data format relates to the content of the
information being exchanged and its structure. The
format consists of the WITSML data objects.
- The protocol defines how two systems actually
communicate and exchange data. The high level
protocol defined by WITSML is the WITSML API.
WITSML objects have been defined based on existing and
emerging work like POSC WellLogML. Also, both the format
and the protocol have been driven by well-accepted standards
in the IT (Information Technology) industry maintained by the
W3C (World Wide Web Consortium)6. The use of such
standard technologies has been a key to the success of
WITSML so far. Most operating systems and programming
development environments now provide software
development kits that allow compliance with W3C standards
such as XML document processing and SOAP remote
access protocol.
The WITSML standard 1.2 was published in February 2003
and replaces the WITSML standard 1.1 published in 2002.
The changes consist of improvements in both the data objects
and the API. Most changes were motivated by issues found
during the first phase of implementations of WITSML 1.1
products, and the field test of WITSML-enabled workflows
that took place in 2002. The WITSML standard states that the
specifications of the data objects and the WITSML API may
evolve at a different pace and have different version numbers.
However, at the time of this paper the latest specifications for
both the objects and the API are both version 1.2.
WITSML Data Objects
XML (Extensible Markup Language) was chosen as the
representation for WITSML data objects. These objects define
a common vocabulary for oilfield data exchange, covering a
broad range of wellsite related data from location information
to real-time data. By nature, XML objects are self-describing.
That is to say, each piece of information is clearly tagged in
such a way that WITSML objects are easily readable and
understandable by both human beings and computers.
XML schemas are used to precisely define the content of each
object. They allow both the sender and receiver of WITSML
data to ensure that data objects conform to the WITSML
specifications. It ensures that all systems using WITSML can
understand objects originating from any other WITSML
system. Note that the WITSML object schemas can
accommodate custom extensions, allowing systems to add
pieces of information not yet supported by the standard, while
maintaining inter-operability between applications.
As mentioned earlier in this paper, the WITSML standard has
been focused on drilling data. The WITSML data objects have
been based on the major components and operations involved
in drilling operations. The initial WITSML 1.1
implementations are mostly use <well/>, <wellbore/>, <log/>
and <trajectory/> objects. And even with only these four
objects, many issues were quickly raised. Based on the
experience gained so far, all object schemas have been
reviewed from version 1.1 to 1.2.
The WITSML object model is rather simple. At the top of the
hierarchy is the <well/> object, containing general information
about a given well, its location and so on. A <well/> can
contain multiple <wellbore/> objects. All other WITSML
objects are under a <wellbore/>. All objects are physically
exchanged separately, and the hierarchical model is enforced
by including references to parent objects into each WITSML
object. Each object has a name and a unique identifier, and
contains the name and unique identifiers of its parents. For
instance a given <trajectory/> object would include the name
of the well and the name of the wellbore it relates to. Details
about the well or wellbore could then be found in the
corresponding <well/> and <wellbore/> objects
exchanged separately.
Considerable effort has been made so that any instance of a
WITSML object can be used as a standalone object. WITSML
objects are XML documents, which can be exchanged like any
text document. For instance a <log/> object saved in a file can
be used the same way as a LAS (Log ASCII Standard) file.
Self-describing <realtime/> objects can be streamed instead of
WITS records, and so on. But the real benefit of WITSML
comes with the objects for which no standard form existed
previously. Things as common as trajectories and bottom hole
assemblies can finally be exchanged in a standard and
understandable way.
WITSML API
The WITMSL API defines a high level protocol to exchange
data programmatically between computer systems. It has two
major types of interfaces: the Store interface following a
classic Client/Server model, and the Subscribe / Publish
interface working like a callback notification system. They are
both designed as web services and the interfaces are described
in WSDL files (Web Services Description Language). The
API is implemented using SOAP (Simple Object Access
SPE 84066
Protocol) and is deployed on top of HTTP (Hyper Text
Transfer Protocol) or HTTPS for secure systems.
Many changes have been made between WITSML API
versions 1.1 and 1.2, but these changes have been
evolutionary, aiming to improve the reliability, performance
and behaviour of the WITSML standard. In particular, the
specifications document has been greatly improved. It now not
only reflects the changes made to the interfaces, but also
clarifies the intent behind each interface, and "supplemental"
material not relevant to WITSML data exchange between
systems was removed. WITSML 1.1 implementations were
almost exclusively using the Store interface. With WITSML
API 1.2 the Store interface has become more mature, and the
Subscribe / Publish interface has been improved to correct a
few fundamental issues.
The WITSML 1.2 API Core Architecture and Reference
document6 covers, in detail, the interfaces and their behaviors,
which are defined in the standard. This is the main source of
information required for software developers to create an
implementation of the WITSML API. The following
paragraphs give a brief overview of the operation of the API.
A WITSML API server implements the Store interface. It
offers read and write functionalities in and out of its data store
to any client application. The functions covered in the Store
interface are get, add, update and delete. A server may support
all or only a subset of these for each of the defined WITSML
objects. This is conveyed by a dedicated "capability" object.
To read data from a server, a client application sends a request
containing a query for one or many WITSML objects. The
server then returns the WITSML object(s) matching the query,
with all supported attributes requested by the client. The query
language consists actually of partially filled WITSML
object(s) template(s). It is a "pull" model, the client
application initiating and controlling every WITSML
object exchange.
The Subscribe / Publish interfaces follow a completely
different approach. They can be seen as a notification service
and can almost be considered a new feature in WITSML API
1.2. It follows a "push" model: the data consumer application
(the subscriber) sends a subscription object to a server (the
publisher). The subscription defines the list of objects that the
subscriber wishes to receive from the publisher. The
subscriber then waits for the publisher to periodically send
him the requested objects, whenever the subscription trigger
criteria are met. The trigger to send data objects can be the
addition, update or deletion of the specified WITSML objects.
These web services can be used within a small LAN (Local
Area Network), a company intranet or even on the Internet.
Since they are based on W3C web communication standards,
information can easily flow from one system to another or be
managed, as needed using existing IT infrastructures.
Obviously, whenever data are exchanged over non-secure
networks like the Internet, encryption and authentication
become essential. WITSML API 1.2 relies on existing
technology: the encryption is taken care of by HTTPS, that is
5
to say HTTP over SSL (Secure Socket Layer), and
authentication information is conveyed in the HTTP header.
The management of user accounts and data access rules is left
entirely to the WITSML server discretion and is not specified
as part of the standard.
Additional detailed information on version 1.2 of the
WITSML standard can be found at http://www.witsml.org/.
Sample data and example API code are available for
download. The WITSML 1.2 specification document is also
located on the website.
Status
By early 2002, the WITSML project had completed Version
1.1 of the specifications and a series of pilot implementations.
Commercial development of products based on WITSML
followed, along with further testing and early deployments.
During the second half of 2002, feedback from the use of
WITSML was evaluated and enhancements to the
specifications were agreed upon. This resulted in Version 1.2,
published during the first quarter of 2003.
The planned transition of WITSML to custodianship in a
recognized industry standards organization took place at the
point of publication of Version 1.2.in early 2003. Agreement
for the transition to Petrotechnical Open Standards
Consortium, Inc. (POSC) was reached in June 2002 and
targeted for the time when the WITSML standard would be
demonstrably stable and able to support widespread
implementations and deployments.
POSC and the WITSML participants organized a public
workshop, XML in Drilling, in November 2002 in Stavanger,
Norway. More than sixty attendees at the workshop heard
from oil companies about the purpose and expectations for
WITSML, from service companies about the product
developments in progress, and from POSC about the plans for
managing WITSML after the transfer takes place.
With the transition to POSC, the WITSML Special Interest
Group (SIG) becomes the focal point for the WITSML user
community in the industry. Led by a Steering Committee,
technical work to define the future path for WITSML is
addressed by work teams. The Data Content and Infrastructure
Technical Team and the API Technical Team addresses
feedback from implementation and deployment experiences
and recommends changes to the specifications where needed.
The Use Case and Requirements Team considers opportunities
for future expansion of the scope of WITSML. Any concerted
development efforts to define detailed requirements, conduct
pilot testing, etc. will be conducted in focused, self-funded
work efforts by interested parties.
The overall future objectives for WITSML at this stage of its
evolution are: (1) to strengthen support for the initial scope of
use cases in the drilling area, (2) to expand the scope of
implementation to support remaining use cases in the drilling
area, (3) to extend the scope of WITSML itself to other
wellsite acquisition, transmission, and delivery work areas,
such as completions, well testing, and production operations,
6 SPE 84066

(4) to seek improved alignment with associated industry

standards, including various sets of reference values, key
identifiers, and other E&P XML standards, such as
WellHeaderML and WellLogML, and (5) to maintain contact
and awareness of the progress of the underlying technologies
used with WITSML, such as XML and SOAP/WSDL, to
ensure that WITSML remains in the mainstream of the overall
computing discipline.

Acknowledgements
We thank the other members of the Steering Committee
during Phase 1 of this project. The authors are also indebted to
the technical teams who made invaluable contributions to
defining the data objects, implementing the commercial
products and testing the prototypes.

We also thank the following companies for their support of

this joint industry project Baker Hughes, BP plc, Halliburton,
Landmark Graphics, NPSi, Schlumberger, and Statoil We also
express appreciation to these companies and POSC
for permission to publish this paper.

WITSML is a trademark of Petrotechnical Open Standards

Consortium, Inc. Unix is a registered trademark of Unix
System Laboratories. Windows NT is a trademark of
Microsoft Corporation.

References
1. Jantsen, H.E., Foreman, R. D., Keltner, L., and McCoy, R.S.:
“Format, Content, and Transfer Standards for Digital rigsite
data,” paper 16141 presented at the 1987 SPE/IADC Drilling
Conference, New Orleans, USA, March 15-18.
2. McGinley, P. J.: “Leveraging off Advances in Internet
Technology to bring data to the Expert User on-shore”, paper
56687 presented at the 1999 SPE Annual Technical Conference,
Houston, Texas, October 3-6.
3. Paymiyer, R., Flowers, A., Almanza, E., El Assal, H.:
“Implementation of Advanced Data Management and
Communications System adds Value and Efficiency to Well
testing Operations”, paper 71825 presented at the 2001 Offshore
Europe Conference, Aberdeen, Scotland, September 4-7.
4. http://www.witsml.org
5. http://www.posc.org
6. “<WITSML/> Core Application Program Interface Architecture
and Reference, Version 1.2”, accessible from
http://www.witsml.org.
7. http://www.w3c.org
8. http://home.sprynet.com/~carob/
9. Holt, J., Haarstad, I., Shields, J.A., James, J.P., Seiler, D.:
“WITSML: Technology to Business (T2B) for the Oilfield” paper
74480 presented at the 2002 IADC/SPE Drilling Conference held
in Dallas, Texas, February 26–28.