DATA EXCHANGE STANDARD SMOOTHS E&P INTEGRATION

Scott Guthery
Schlumberger Austin

Ken Landgren
GeoQuest Houston

Jim Breedlove
GeoQuest Corte
Madera, Calif.

The need for optimal reservoir characterization has been driving a trend towards integrated exploration and production activities.

However, the ability to achieve time- and cost-effective integration of E&P through the computer has been hampered by hardware and software constraints-unique computing systems abound.

Now, a way to arrive at an integrated E&P interpretation environment using existing computing tools is available.

Specifically, a common data exchange standard suited to all types of scientific data has been introduced to geoscientific software developers and a group of oil and gas operators (see table).

Subscribers will soon be able to transfer data and interpretations among their various data bases in support of integrated E&P techniques.

Specifics of the standard, which is fully hardware- and software-independent, are being widely published to encourage maximum industry participation.

WHY A STANDARD

In an ideal world, all corporate E&P data (both measured and interpreted) could be accessed by all authorized E&P personnel through any application on a common computing system. However, few companies can commit the time and funds necessary to:

• Create a uniform hardware environment (thus losing much of the existing hardware investment).

• Rewrite all existing E&P applications to a common interface (assuming one could be agreed upon).

• Link them to a common data base.

In light of this dilemma, Finder Graphics Systems Inc., GeoQuest, and Schlumberger joined forces in 1991 to create a fully open data exchange system that is now being distributed as the Geoshare standard.

The standard is hardware/software-independent and based on a uniform exchange model to which all geoscientific data analysis systems can easily comply, without rewriting or loss of efficiency.

Connecting to the exchange system has been made as easy and reliable as possible.

Tool kits to help software developers and end users (oil and gas companies) create their Geoshare connections (halflinks) are available.

Or anyone may create Geoshare-connections from scratch by referring to the published data exchange protocol.

It is a generalized data transfer scheme that requires minor software development.

The companies listed in the table are currently writing, or already have written, their own Geoshare halflinks.

A nonpartisan user's group has been organized to oversee future Geoshare product development, maintenance, and distribution. It will ensure logical growth of the Geoshare exchange method as new data types, E&P techniques, and computing tools become available. Most importantly, the user's group also will guarantee vendor neutrality.

DATA EXCHANGE HISTORY

There are several ways to achieve data exchange between software applications.

PAIRWISE INTEGRATION

The first of these is the "pairwise" exchange of data and results between two specific programs. This approach, in wide use today, typically uses translation programs purposefully written to move data between application groups (Fig. 1).

An example is moving logging information into a seismic program. The logs must first be rescaled from their typical data vs. depth presentation to data vs. time. Then they are translated into the format of a specific seismic interpretation system.

In this way, translation programs must be written for each pair of applications that will share data.

An advantage of this type of exchange scheme is that it works today. It demands only the exchange of data or results between applications, allowing each application to maintain the efficiencies of its specialized tasks. It also enables continued internal development or commercial purchase of specialized applications, without regard to exchange issues.

The most obvious disadvantage of pairwise exchange schemes is that they proliferate rapidly.

Each new application added to a system results in a growing number of application pairs requiring new translation programs.

Managing an arsenal of translation programs, keeping track of each data transfer, and properly archiving data under a pairwise exchange scheme quickly becomes an unwieldy burden. Further, translation programs require maintenance whenever either application in a pair undergoes change. Managing pairwise systems is difficult.

TIGHT INTEGRATION

A monolithic computing system supporting the storage of and uniform access to all E&P data types needed is another way to achieve integrated data access.

All elements are developed to a uniform format and thus are tightly integrated (Fig. 1).

Through a single interface, a user can access all data within the system as well as process and analyze them using any applications present. It clearly is easy to operate a monolithic system and to write new applications for it.

However, experience shows that developing a unified data model that permits multiple representations of all E&P data types is difficult.

For example, a fault must be represented not only as a curve but also as an element of a grid and as a polygon. Faults are only one of countless data types used in the petroleum industry, each having multiple representations. Thus, developing a data model fitting all possibilities and suiting a majority of companies in the petroleum industry is difficult.

Nevertheless, several efforts are under way to derive a universal petroleum data model. Completion of these projects remains in the future. Thus, an industry-wide, tightly integrated data exchange solution is not yet available.

LOOSE INTEGRATION

Certainly, the petroleum industry needs today the advantages to be gained from wide-spectrum, integrated analyses. It cannot wait for a consensus to emerge on a data model that will enable tight integration or for the resources necessary to implement it.

Meanwhile, many existing computing systems satisfactorily support standard data analysis, falling short mainly in data exchange or connectivity.

Many interpreters, therefore, have asked for what is essentially a compromise between today's existing pairwise solution and the ideal of tight integration; that is, the need today is for tight integration of existing programs within each discipline (such as petroleum engineering, geology, and geophysics) and loose integration between the disciplines for data exchange purposes.

The Geoshare system for geoscience data exchange answers this need by enabling the loose integration of existing, often tightly integrated systems and programs, without requiring that they be changed (Fig. 2).

In essence, it provides an easy way (no writing multiple transfer programs) to interconnect data analysis programs to a variety of computing components, such as multiple data bases, graphics systems, and more. It provides a standard method for open information exchange between today's geoscience interpretation systems. It also facilitates the resolution of conflicts among existing data models, which should lead to a more natural development of tight integration, where it is needed.

GEOSHARE DESIGN

Geoshare data exchange is designed around a common exchange format. It differs from cumbersome, pairwise data transfer in that only one exchange program must be written for each computing system (set of applications and their data base) that is to be Geoshare-compliant.

It can then connect with all other systems that are Geoshare-compliant, regardless of the diversity of their internal data formats.

All coding necessary to connect any computing system to the Geoshare environment is published on open record for use by operators or commercial software developers.

However, development software also is available that substantially reduces the time to Geoshare start-up. It steps programmers through the process of creating the one-time link, commonly called a halflink, from any geoscience computing program or system to the Geoshare exchange format.

These links are created to both read data from and write data to other Geoshare-compliant systems (see the two-way arrows in Fig. 2).

The Geoshare exchange format consists of a data protocol standard and a communication protocol standard. The data protocol standard defines the semantics and syntax, or correct "etiquette," for any data to be exchanged-what data can be included and how to refer to it.

It incorporates API's Recommended Practice 66 (RP66), established explicitly for the exchange of scientific data between all types of hardware. RP66 covers Digital Log Interchange (DLIS) specifications, SEGDEF for seismic data, and WITS Level 4 (Wellsite Information Transfer Specification) for drilling data. It is an extendible, flexible encoding environment, suited to the growth potential of the Geoshare approach.

Further, RP66 has been adopted by the Petrotechnical Open Software Corp. (POSC) as the basis of the POSC Exchange Format.

Meanwhile, the communication protocol standard governs the creation and maintenance of the communication channel, or databus, over which data are actually sent.

Its guidelines ensure that all implementations of the actual Geoshare data transfer mechanism can communicate with one another and coordinate communication between all halflinks on a network.

Geoshare-compliant data can be sent over commonly used communications channels, using common transport standards.

EXCHANGE SYSTEM

The Geoshare system enables data exchange through any loosely integrated computing environment.

Essentially, a data set is copied from one computing system to another. In simple systems, the users can manage the multiple copies of data generated. However, larger Geoshare environments will find it beneficial to include a master data base and a data base management system (relational or not) to keep track of all Geoshare transactions.

Geoshare environments can take on numerous configurations and levels of sophistication, depending on each user's needs, desires, and existing computing system.

Beginning with the simplest example, two halflinks connecting two project data bases and one user at a keyboard can constitute a Geoshare environment.

Fig. 3 shows the sending and receiving system, each having a couple of software applications, an application data interface (ADI), a local data model or data base, and its halflink. While only a sending and receiving halflink are shown activated on each system, accordingly, both systems do have a sending or receiving halflink available to them.

The Geoshare standard specifies how data are to be copied from the sending machine's local data model, sent through the databus, and received by a local data model on the receiving end. The advantage of copying data from one local data base to another is that applications do not have to be modified in order to work cooperatively.

As previously stated, the disadvantage is that there are multiple copies of a piece of data in use, and these must be synchronized and managed.

A typical data exchange between the sending and receiving systems shown in Fig. 3 might proceed as follows:

• User selects Geoshare-compliant sending and receiving s stems.

• User selects the data to be sent and activates a Geoshare send routine.

• sending system extracts the data to be sent from its local data base and uses the Geoshare data exchange protocol to encode the data for transmission.

• Sending system uses a communication channel to send the encapsulated data to the receiving system. . 0 Receiving system receives the Geoshare encoded data, decodes it, and places it in its local data base.

From these steps, it is apparent that the Geoshare system is based on data exporting only.

A receiving computer cannot initiate a Geoshare exchange. Other than this, however, the variety of configurations possible with the Geoshare system is endless.

The sender may transmit data to more than one receiving system, for example.

A sender also may opt to output Geoshare encoded data to tape, instead of transmitting it on line.

Fig. 4 illustrates a more complex Geoshare arrangement. In this case, an operating company has elected to loosely link several commercial applications to its tightly integrated system of proprietary applications, which are managed by a relational data base manager. A data base management system, in fact, is recommended in situations where multiple applications, and especially multiple platforms, will be sharing data. It is needed to verify, validate, manage multiple copies of, and secure a corporation's data assets.

In a multimachine, multiarchitecture, distributed computing situation, a user may opt to set up a sophisticated launcher machine to drive and manage data sending and receiving throughout the corporation and to long-distance partners (Fig. 5). This type of configuration, obviously, would involve more software development work than the simple Geoshare configurations previously mentioned. The degree of sophistication is the user's choice.

CONCLUSIONS

The major oil companies and petroleum industry vendors that have committed to the Geoshare exchange standard to date are participating with helpful suggestions for product evolution as they incorporate the Geoshare connectivity solution.

Such early industry support, combined with the fact that retrofitting existing computing systems with open Geoshare connectivity is time- and cost-effective, should enable the Geoshare technique to quickly proliferate. Unocal Corp.'s team leader for computing exploration worldwide believes this outlook is realistic and explains his company's reasons for choosing the Geoshare approach in the accompanying article.

Technical, organizational, and business considerations suggest that integrated geoscience interpretation is best accomplished today by connecting tightly and loosely integrated interpretation systems.

The published Geoshare standard provides a way to exchange data and results between any petroleum applications, regardless of their formats, configurations, or hardware platforms. It is a completely open, expandable standard whose future lines in the hands of the Geoshare User's Group.

ACKNOWLEDGMENTS

The following people contributed substantially to the Geoshare project, for which the authors offer their thanks and appreciation: John Gillespie of Finder Graphics, Stewart McAdoo of GeoQuest, Jim McMullen of Unocal, and Sam Pool of ARCO.

Copyright 1993 Oil & Gas Journal. All Rights Reserved.