Due to the high degree of diversity in which real-time operations and production data are stored and distributed within BP PLC-indeed, within almost any large oil company today-E&P professionals who carry out similar activities in different assets or business units must access data in distinctly different ways.
Therefore, any attempt to implement a “standard” application requires IT personnel to have intimate know-ledge of the underlying data sources in every asset. Scale up and rapid adoption across multiple assets of either new or proven digital technologies is extremely difficult as well due to disparate IT architectures.
The challenges and complexities caused by lack of standardization have fostered rampant development of local, costly, and time-consuming “point solutions”-typically “hard-wired” point-to-point connections between each data source and each application, whether proprietary or commercial.
This familiar approach to integration seriously compromises the organization’s technical flexibility in the face of ongoing business changes. As a result, BP business units have increasingly requested standardized digital solutions that would enable seamless data flow among different classes of E&P applications and business processes.
The Real-Time Architecture Project (RTAP), begun in 2003, now provides a common approach for all assets to access real-time production operations data. It is built around a simple connection technology capable of integrating a wide range of tools such as production reporting, real-time visualization, and active alerting with new or existing data sources of many kinds. RTAP utilizes “Web Service” technologies, which create highly flexible interfaces based on established and emerging internet standards.
BP’s ultimate goal is to implement a common, standards-based architecture for data access and integration, replacing the large number of custom, proprietary interfaces currently in use.
Since the launch of RTAP, significant progress has been made toward this goal, with the intent of expanding the current implementation to a next-generation “Service Oriented Architecture” (SOA) in the near future.
This article provides a review of the RTAP project’s origins and development efforts, BP’s rationale for this approach, a high-level, nontechnical description of the solution, an overview of associated business benefits, and a case study that validates the approach. The potential for SOAs in E&P-which represent a paradigm shift in how IT is developed and deployed-and the need for industry standards in this exciting new area, will also be discussed.
Rationale for RTAP
Like many global oil and gas companies, BP has been aggressively pursuing ways to access, analyze, and act more rapidly on digital information in order to manage producing assets around the world more efficiently and cost-effectively.
To capture “real-time” or “high frequency” data from the field, many assets have installed a variety of SCADA (Supervisory Control and Data Acquisition) and other automated production/operations monitoring systems over the years.
Typically, these systems gather well or facilities data through electronic meters or gauges, transmit those data via satellite, microwave, or fiber optics to remote servers and “data historians,” which are subsequently linked via standard wide-area networks to users with advanced analysis, visualization, and process control tools (Fig. 1).
Real-time data volumes can be enormous. For example, a typical production platform with 25 to 30 wells could generate tens of thousands of real-time data points of interest-wellhead pressures, temperatures, well test information, choke valve settings, compressor readings, flare meters, tank depth levels, and so on.
Some assets update real-time information every 15 sec, others every 15 min, depending on the need. Those lacking real-time access have to rely on information that may be up to 24 hr old, which hinders efficient asset surveillance and timely intervention when problems arise.
Over time, as technical applications improve, business processes evolve, or assets change hands through mergers and acquisitions, it often becomes necessary to swap out or upgrade aging software or data capture systems for more advanced, hopefully more standardized solutions. In the case of assets that have not yet installed real-time monitoring systems, the challenge involves deciding which of many potential solutions to adopt and at what cost (in terms of time, human, and financial resources).
Historically, operating units have invested large amounts of capital to solve urgent technical problems by buying or building systems specifically for the need at hand. Unfortunately, as much as a third of the effort and cost invested in these local, one-off solutions involves custom coding of point-to-point connection between data and application.
The next time the same data source is linked to a different application, that hard-wired connection has to be rebuilt from scratch. If it is linked to multiple applications, every one requires a custom interface, which, over time, can consume millions of dollars and thousands of man-hours. What’s more, almost every asset has a unique combination of systems and data formats that must be maintained and supported at additional cost.
For these reasons, introducing new or standard technology into an existing architecture can be a slow, frustrating, and needlessly expensive process. Sometimes business units maintain the status quo simply because change is too difficult.
With the pace and chaos of business today-both within and beyond the E&P industry-IT departments are finding it difficult to respond in a timely manner with truly sustainable solutions. Whatever approach is adopted must accommodate both emerging technologies and heterogeneous legacy systems, which can never be replaced all at once.
As BP sought ways to integrate real-time well, production, and facilities data from the field with applications and E&P expertise in the office, it quickly became apparent that a new, simpler, more flexible architecture was needed for data capture, publication, and distribution. Indeed, numerous assets worldwide still lacked any access to true real-time data and needed a simple, flexible solution.
Traditional, point-to-point integration would never work on a global scale. Therefore, in 2003, the E&P Digital and Communications Technology (E&P DCT)-BP’s upstream IT organization-took on the challenge of designing a new, web-based architecture that could quickly and easily reuse standard IT connections as common real-time solutions were deployed throughout the company. The initiative was called the Real-Time Architecture Project (RTAP).
Web service standard
Beginning March 2003, the initial stage of RTAP development involved definition of a proposed solution. Several months were spent exploring technical options and building the business case for a new approach.
The RTAP team (comprised of E&P BP and SAIC staff) visited numerous business units, determining how many currently had some form of real-time data access, what types of automation systems were used, how many and what type of applications were or needed to be connected, and what the potential benefits of a standard interface might be-to individual assets or business units and to the corporation as a whole.
Eventually, the decision was made to implement “Web Services” as the standard means of connecting disparate systems. Web Services were, at the time, gaining momentum and visibility in the IT world and seemed to offer precisely what BP was looking for in E&P. In fact, the company had already piloted Web Services in other parts of the organization, such as finance and procurement.
What, exactly, are Web Services? Leaving aside the technical details for the time being, the term refers to a specific set of code that uses widely-adopted internet protocols to create common, robust connections between diverse components within a new or existing IT infrastructure. Web Services have been called “the connection technology of the future”1 due to increasing dependence on the internet for virtually all aspects of modern business.
Familiar Web browsers utilize a similar but somewhat different set of internet protocols to enable seamless access to information and services anywhere on the World Wide Web without having to know where a particular server is located or anything about the underlying architecture. With Web Services, an E&P user’s technical application (not just a Web browser) directly accesses critical information without any need to know how underlying data sources are structured.
A simple analogy helps to explain why standard Web Service connections are so attractive.2 Imagine a typical consumer who has assembled a home audio-video (AV) system from various components purchased over a period of years. Being conservative by nature, this individual has an older stereo receiver plugged into his television; a VCR, cable TV box, and CD player connected to the receiver; and separate high-quality speakers.
Succumbing to market pressure and technological advancement, he decides to add a DVD player to the existing AV “infrastructure.” Unfortunately, as one of the oldest components, his receiver lacks the newer s-video and optical connections found on DVD players. However, both systems have standard RCA plugs, which he uses to connect the two units.
He also decides to upgrade all connections in his AV system to RCA so he will have a common interface method. Web Services are pieces of software analogous to those RCA connectors. Once all components have standard connections, they can be rearranged or replaced by newer systems with much greater speed and flexibility.
In the upstream E&P industry, Web Services will allow energy companies to mix and match new and legacy applications and database systems to fit rapidly changing needs.
Once the business case for Web Services had been prepared and the project officially authorized, the prototype RTAP system was built using a commercial Web Service development platform. Initially, there were two core capabilities: real-time data transfer and automated user notification.
The data transfer service actually moves data from the source to the relevant user application; the notification mechanism provides a common service to alert users via e-mail, SMS-enabled phone, etc., that certain operating conditions under real-time surveillance have reached a predetermined threshold and require their immediate attention.
RTAP’s real-time data transfer capability was pilot-tested in late 2003 and early 2004 on a project in the US Onshore business unit (described in more detail below); the automated alerting service was tested in the North Sea. These two projects were chosen because they were discrete enough to be manageable and experiencing enough pain to warrant a new approach. RTAP promised to yield immediate benefits that would demonstrate proof-of-concept prior to further development or widespread rollout.
The initial development of the real-time data interface exhibited performance issues when compared with traditional point-to-point connection methodologies. Through a number of iterations, the XML data transfer format was optimized and the core service code tuned so that the final production version of RTAP now delivers no more than a 10% performance degradation over existing point-to-point connections. A slight residual trade-off between performance and IT flexibility is likely to remain; however, for most applications, this trade-off is acceptable.
Due to the need to provide a robust data structure and the ability to link heterogeneous systems over the network, the standard technologies used in Web Services-just like the RCA connectors widely used in AV systems today-are not necessarily the highest performing option available.
As this technology undergoes further standardization, it is likely to become as ubiquitous as RCA connectors in the AV world, ensuring distinct advantages over any proprietary method of integration in the future. Additionally, new tools are emerging that can accelerate XML-based applications beyond the limits of today’s technologies.
By spring 2004, sufficient pilot testing and benchmarking had been accomplished to justify the value of moving forward and productizing an RTAP solution for use in BP assets worldwide. The rest of the year was spent creating specs for the initial product, packaging the various components, creating documentation, release notes, and installation guidelines, enhancing performance, continuing to support the pilot implementations, and beginning to roll out the solution to other assets.
As of mid-2005, RTAP had been implemented in 30 locations in a number of business units from onshore North America to the Deepwater Gulf of Mexico, the North Sea, and Azerbaijan. Standard Web Service connections were providing more than 12 common applications with access to information from a dozen commercial and proprietary data sources (Fig. 2).
US onshore case study
Before exploring the technical solution in a bit more detail, the following case study of the US onshore RTAP implementation helps illustrate both the need for and the value of standard Web Services in E&P.
BP’s US Onshore Business Unit has been built largely through mergers and acquisitions. Between 1998 and 2000, for example, the company acquired a wide range of Amoco, ARCO, and Vastar assets and associated legacy systems throughout North America.
As a result, the business unit had seven different production/operations data capture and storage systems-some decades old-including systems for automated real-time data collection and process control.
Upon acquisition by BP, each of these unique data sources had to be connected to one or more applications used by operations personnel, such as production accounting and ad hoc reporting. Development work had actually begun on a number of traditional point-to-point connections prior to the RTAP initiative (Fig. 3).
Meanwhile, one of BP’s onshore operating centers had developed an innovative, Web-based, real-time production surveillance and reporting tool that offered more effective functionality and greater flexibility than existing applications. It was capable of consolidating data and standardizing well/production data reporting across a single asset.
The business unit decided to productize it for more widespread adoption. However, to swap out existing applications for the new one, it would have been necessary to rewrite all of the custom interfaces and create new ones where they did not yet exist-a potentially massive IT effort.
Each data source, even when it collects similar information from the field, has a unique way of storing, formatting, or presenting it. Thus, each custom connection requires significant expertise and time to investigate, design, code, test, and deploy. The usual result is long lead times before any business value is realized, and higher rollout, maintenance, and support costs.
Fortunately, the RTAP team was just then looking for a pilot project in which to test Web Services technology. In late 2003, the RTAP prototype was implemented in one of the US onshore assets to connect the new Web-based reporting application with several different legacy data sources.
Due to the age of the existing technologies in the asset, this new approach to accessing data was in some cases faster than it had been before. Also, because the software operated in a Web environment, it expanded the range of technical users who could easily access it from any geographic location.
With Web Services, only one interface had to be written linking the application to RTAP, and one interface from RTAP to each data source (Fig. 4). The interfaces between RTAP and the application were relatively simple to build and test because there was no need to address the underlying idiosyncrasies of each system. This greatly reduced the complexity, cost, and speed of deploying the new production application in subsequent operating centers.
For example, RTAP reduced the cost of implementation (compared with the traditional approach) by 25%/asset. Also, whereas a custom point-to-point connection to this particular application typically took 2-3 weeks to build, a new RTAP interface could be created in 2-3 days, and reusing that interface with the same data source in another asset required mere hours to get up and running.
By mid-2005, RTAP was providing consistent, hassle-free access to real-time production data in 13 assets across North America.
Having a standard interface has not only accelerated the pace of new application deployment throughout the business unit, but future software upgrades will also require less time. If a better, faster or cheaper data-store or analysis tool comes along, replacing an existing one will be almost painless.
What’s more, Web Services have effectively extended the lifetime of some of the legacy data capture systems by perhaps 3-5 years. Replacing one or more such systems with a new standard would cost hundreds of thousands if not millions of dollars.
When the appropriate time comes to do so, having a Web service interface will streamline that change as well, without any negative impact on whatever applications are currently in use.
Next: Identifying the key components and technologies involved and some potential barriers to more widespread adoption. ✦
This was originally presented as SPE 96441 at the 2005 SPE Annual Technical Conference and Exhibition, Oct. 9-12, 2005, in Dallas.
The authors
Russell D. Foreman ([email protected]) is program manager, service oriented architecture, for E&P digital and communications technology, BP’s upstream IT organization. He has more than 25 years of experience in upstream oil and gas working for operators and service companies in technical, managerial, and R&D positions. He has a BS in petroleum engineering from the University of Tulsa.
Radmilo M. Gregovic ([email protected]) is business information manager for BP’s deepwater development business unit. He was the original program lead for the Real-Time Architecture Project (RTAP) described in this article. Before joining BP, he was a geoscience workflow consultant for Landmark and a geophysicist for Western Atlas. He holds a BS in geophysics from the University of Belgrade and an MS in geophysics from the University of Houston.
Dean Forrester ([email protected]) is senior technical architect for SAIC Consulting. He has 13 years of experience with companies including EDS, Halliburton, and SAIC in the design and implementation of IT systems, including major “Next-Generation Oilfield” programs. He earned degrees in physics and instrumentation, systems analysis and design, an MBA from Napier University, and a post-graduate certificate in eBusiness from Robert Gordon University.
