Feature-Rich Software, Open by Design
Providing stable software on schedule requires strict adherence to a development
plan. Development teams decide upon a finite number of features for their products
based on customer requirements; inevitably, some enhancements are not included.
Opening the software development process to external programmers introduces
another avenue for the creation of additional features, one that doesn’t impact
production time or the quality of the primary product.
Richard Bennett Benjamin Cornelisse Robert Merkle
Shell International Exploration and Production B.V.
Rijswijk, The Netherlands
Jan Egil Fivelstad Paul Hovdenak
Blueback Reservoir AS Stavanger, Norway
Trygve Randen
Stavanger, Norway
Oilfield Review Autumn 2009: 21, no. 3. Copyright © 2009 Schlumberger.
For help in preparation of this article, thanks to Najib Abusalbi, Marcus Ganz, Susan Lundgren, Andrew Muddimer, Jeff Rubenstein and Eric Schoen, Houston; and David McCormick, Cambridge, Massachusetts, USA. Ocean and Petrel are marks of Schlumberger. BRIDGE EM is a mark of Blueback Reservoir.
.NET, Visual C# and Windows are marks of Microsoft Inc. Rock3D and Rock3D Synthetics are marks of Shell.
In an ideal world a piece of software would con-tain only the features a user needed, consume only the resources required for the task at hand and have an interface ergonomically focused on those features. In reality this is rarely the case and features are developed to meet the needs of a diverse audience. As a result, software may be overly complex for some people and lacking key components for others; however, a solution exists that is growing in popularity for both software developers and users.
Developers can create an application pro-gramming interface (API) providing access to the state and functions of a software program or operating system.1 Software developers may choose to create an API to unlock specific ele-ments or all the software to enable users or other developers to extend its capabilities with new features. This is beneficial to independent devel-opers for many reasons; they can add features that they choose, they can do this according to their own schedule and they can work freely of the original developer.2
Traditionally, adding new capabilities to a software program required modification of that program’s source code.3 Changing the source code has two major implications. First, the origi-nal developer loses the ability to control the changes made to the primary software. Second, the proprietary intellectual property (IP) associ-ated with the primary software is publicly available to anyone with access to the source code. When working with an API, developers create new capabilities using a high-level
pro-gramming language.4 Algorithms written by an independent developer interact with data and utilities from the primary program via the API.
A software program initially created by one developer and later extended by an independent programmer can be illustrated by the set of functions on a calculator. A developer creates a simple program comprising addition, subtrac-tion, multiplication and division procedures. These mathematic functions are supplemented by sine, cosine and tangent trigonometric functions later added by an independent pro-grammer. If the original developer provides access to necessary elements of the calculator software via an open API, the new functions can be plugged in to the simple calculator without changing the source code.5
A benefit of being able to add to software without changing its original makeup is that extra features, such as the trigonometric func-tions in the example, are not essential and can therefore be turned on and off. Users who require a simple calculator can enjoy a refined interface with fewer commands and concepts to compre-hend. When needed, the additional features can be accessed in a variety of ways, such as from the menu bar.
The concept of dually developed software goes even further. For example, an application with a large user base, such as a Web browser, can be combined with an extensibility API to create a software ecosystem made up of the original developer and a community of independent devel-opers who work to extend the core software 1. For more: Application Programming Interface, Free On-Line
Dictionary of Computing, http://foldoc.org/Application+ Program+Interface (accessed September 22, 2009). 2. An original developer is the owner of the software. An
independent developer, in this case, adds new features to the software or uses components of the software to create another program. Typically, a licensing agreement is made between the software owner and the independent developer; however, it may be a free license under written terms of agreement.
3. Software developers write lines of text called source code. These instructions, once converted to machine code, are carried out by the processing unit of a computer. 4. A high-level programming language has a level of
abstraction higher than that of an assembly language, which itself is a symbolic representation of the machine language of a specific CPU. Typically, higher level languages comprise spoken language statements, usually English, such as for, loop or return.
5. A plug-in is a common computer term that describes a small software program created to provide additional functionality to a larger software program. This term symbolizes the addition of modules to a central program. Generally, these modules cannot operate without the core software installed.
program. The ecosystem components deliver more functional value when combined than they do indi-vidually, providing mutual benefit to the original developer, independent developers and users.
In the oil and gas industry, many complex software packages address the multifaceted challenges of hydrocarbon recovery. For example, Petrel seismic-to-simulation software contains tools for many elements of geology and geophysics (G&G) workflows. With each new version the development team adds features to satisfy the technical demands of the industry and to address software efficiency, reliability and user-friendliness. Project managers make difficult decisions in determining which of the many proposed features will be developed and which will not.
To provide users with more G&G workflow capabilities, Schlumberger recently created an API to open the Petrel software to third-party software vendors. This enables the company’s developers to concentrate on primary functional-ity while independent developers provide additional components in the form of plug-ins. New modules vary in complexity. A simple time-saving algo-rithm that automates a manual data-manipulation process can be created in minutes by anyone with basic programming skills. However, a plug-in pro-viding more sophisticated capabilities such as electromagnetic modeling requires a greater commitment by a team of programmers and oil-field experts.
Opening the software benefits both indepen-dent developers and Schlumberger because it disconnects the plug-in development process from the Petrel release schedule. Therefore, new features can be created and used when they are available, and the IP of new features always remains in the hands of the owners. The freedom to build upon this software is provided through the Ocean application development framework.
The Ocean framework, based on industry-standard programming tools such as the Microsoft .NET framework and Visual C# lan-guage, provides a programming interface to the inner workings of the Petrel suite. Independent programmers can write their own algorithms to interact with existing components—such as property modeling or volume calculation—and then display the results of the interaction within the soft ware environment.
This article describes the concept of open software and how it is being used to enhance the capabilities of complex software. The first case study demonstrates a client’s use of the Ocean framework to develop new rock physics capabili-ties. The second study focuses on its use by an
independent software vendor to create an elec-tromagnetic modeling module. Also discussed is the adoption of the Ocean framework by the academic community.
G&G Software Options
A typical geology and geophysics workflow involves gathering data from a variety of sources, processing the data and then combining the results for interpretation. This workflow is not unidirectional or one-dimensional; discoveries late in one branch of the workflow can require past processes to be revisited or input data to be changed (above).
From start to finish, the work undertaken in a G&G project may take several months to com-plete. Many geologists, geophysicists, engineers and stakeholders work on a project to plan one or more wells. The process relies heavily on soft-ware to handle intensive tasks such as inverting for rock properties from borehole readings or picking horizons through seismic stacks. Because of the complex nature of each task, an E&P company may choose several software pack-ages to meet all its workflow requirements. In addition, some companies develop their own software or algorithms to deal specifically with challenges relating to conditions in a particular geographic area.
Using several different software programs to complete a project increases the risk of data migration–related errors, such as those that may occur when saving results from one program and importing them into the next. Training scientists to use several different programs is also not ideal. A simple solution is to have one software package that handles all elements of the G&G workflow. But it is unlikely that a single software package can meet the needs of every user; E&P companies have their own specific requirements based on their asset portfolios.
One way to make using several applications less complicated is to create real-time links >Example G&G workflow from screenshots. The process begins by importing and interpreting information including seismic data (top left) and
electro-magnetic data (bottom left). Seismic inversion may then be performed before the reservoir model is constructed. Some steps in the workflow affect others; for example, synthetic seismic data (center) are generated to confirm the accuracy of reservoir model properties. If a significant misalignment exists, the model can be updated and the checking process repeated. It is important to identify such problems early in the workflow. Reservoir simulation (right) is an expensive and time-consuming process; this step and several before it must be repeated if mistakes were made in building the reservoir model. With information on the planned wells (bottom right) available during the drilling phase, it is now possible to react to real-time LWD data (Real-time geosteering,
top). Communication among experts working in different domains on a shared data model is an effective means of avoiding, identifying and correcting errors. A centralized data model and unified software package, which can manage all workflow steps, help domain experts in tackling such problems. A familiar shared system also improves user efficiency when resolving any issues.
Prestack seismic data processing
Poststack seismic interpretation
Seismic inversion
Real-time geosteering
Rock physics and synthetic seismic modeling
Reservoir modeling
Reservoir simulation
Well planning
between the individual software programs. In this symbiotic approach intermediate data are shared across programs, making it easier to iden-tify data migration issues. This method also reduces lost time during import and export rou-tines since it is handled automatically by the applications. An extension of this concept allows each program to control some features in the next. This is especially helpful for algorithms that may have no graphical user interface (GUI). In this case one software package acts as the host, and its GUI can be used to control an algorithm with no interface, which is easier for some users than writing text-based commands.6 In addition, such algorithms can be created more rapidly without having to develop and debug a GUI.
A potential problem with the symbiotic approach is that proper functioning of links across programs may depend on their release ver-sions. Most software changes when a new version is released; consequently, links across applica-tions might be completely broken or at least become problematic. Although some linked soft-ware is made by just one company, many packages
are developed by more than one. It is difficult to align the development paths of software projects. If a planned update is postponed or altered, this will likely affect the interactions among all connected applications.
A response to this problem is to create an interface language that does not change very often and that enables communication with a software program. Application programming interfaces provide access to the functionality of software packages, and they are also good communication languages. Essentially they can be thought of as a translator: A publicly declared input language is converted into a private language, which is then used in a software program. The public elements of an API make up the communication interface, which changes infrequently, while the private ele-ments of an API can change as often as necessary. Private elements are frequently changed and new ones created to add functionality and improve software stability (above).
For workflows that require several software programs to work together, sharing data and controlling features, an API is well suited to
6. Text-based interfaces require users to memorize the name of each function or spend time looking up the name. A single mistyped command can cause an entire algorithm to either stop working or return an inaccurate result. Well-made GUIs eliminate or constrain syntax errors made by users; however, most GUIs lack features to stop users from making logic-based errors.
maintaining a stable relationship among them all. Development guidelines for GUI design, data types and event states are provided with frame-works and can help to create and maintain relationships between plug-ins.
While an API goes a long way toward provid-ing a development environment that maintains stable links between software updates, it is still not a perfect solution. Not only do software pro-grams change over time but programming technologies and computer hardware do as well. For example, multithreading has become a viable programming technology for workstation soft-ware because mainstream CPUs now contain several cores. Multithreading is a significant change to single-threaded applications. These changes may require an API to be rewritten, thus breaking any links with current software. >The job of an API. An independent programmer creating code (left) needs
to use a function in a target software program (right) but does not have permission. The owner of the target program creates an API (center) providing access to the private code. The API shares data, software event states and program functionality without compromising the target program. In this example the target software is updated from Version 1 to Version 2. The independent program is unaware of the changes and remains the same. Without the API this connection would break. With due diligence the target software developer updates the API to respect the change in function name
from Addition to AddTwoIntegers and the data variable parsing from X and Y to X, Y and Answer. However, these functions and data variables are masked to behave in the same way as in Version 1 and therefore are compatible with the independent program. As long as the independent program and the target software continue to conform to the API language, any changes made to these programs will not break the link between them. This is an important feature because software is often upgraded without synchronization among the developer companies.
• Function Add (integer X and Y) • Create integer variable Answer • Answer = Addition (X and Y)
• Return Answer Version
1
Target software code API code
Independent programmer’s code
Private code changed Public code unchanged, private code changed
to reflect change in target software code Code unchanged
Version
2
• Create integer variables A, B and C • Make A = 2 and B = 3
• Call API code: C = Add (A and B)
• Function Addition (integer i1 and i2)
• Create integer variable i3
• i3 = i1 + i2 • Return i3 • Function Add (integer X and Y)
• Create integer variable Answer
• AddTwoIntegers (X, Y and Answer)
• Return Answer • Create integer variables A, B and C
• Make A = 2 and B = 3
• Call API code: C = Add (A and B)
• Function AddTwoIntegers (integeri1, i2 and i3) • i3 = i1 + i2
Translation effect
To protect the interests of independent devel-opers, software owners can restrict any significant updates to longer development times, such as mak-ing these changes over a two- or five-year period. Reservoir Model Verification Using
Synthetic Seismic Data
The process of building reservoir models can be lengthy. Data from multiple sources are input to shape an electronic model by expert interpreta-tion and a series of algorithmic transformainterpreta-tions. Model parameters and their uncertainties may
be subjective, and because of the range of uncer-tainties, many geologic model realizations may not align closely with the original input data.
To ensure the quality of its geologic models, Shell has implemented a new model verification workflow. Modelers generate synthetic seismic data from geologic models using a forward- modeling process. The synthetic data can then be compared with the original seismic data to verify alignment and identify mismatches relating to reservoir geometry, reservoir thickness and property distribution.
Shell uses the Petrel software suite as its primary platform for geologic reservoir modeling and has incorporated this new proprietary work-flow as a module of its own modeling workwork-flow. This approach has enabled its software develop-ers to take advantage of existing modeling tools and concentrate on delivering new rock physics functionality. By making use of existing capabili-ties, Shell was able to reduce development time compared with that required to create a stand-alone application. Two new plug-ins were created: the Rock3D and Rock3D Synthetics modules.
The user interface was an important design criterion for the Rock3D plug-ins; conforming to existing interface behavior helps to reduce train-ing time and also improves user efficiency. The Ocean framework provided a set of design tools and guidelines to help Shell designers build an interface with the same appearance and response as the Petrel software, which their geologic modelers were already trained to use.
Generating synthetic seismic data is a two-step process using the new workflow. In the first step, a modeler inputs rock and fluid properties from the existing reservoir model into the Rock3D module. Acoustic properties and impedances are then generated using relationships between the model properties and the acoustic properties, such as velocity and bulk density. In the second step, the modeler uses the Rock3D Synthetics module to generate a synthetic seismic cube from these acoustic properties (above).
Executing this workflow directly within the Petrel modeling environment has many advan-tages. The reservoir geologist and geophysicist discuss the set of rock properties to be applied. This facilitates greater understanding between earth science disciplines on how the geologic >Closed loop process. The acquired seismic volume (left) is used to create the framework of the reservoir model (center). A synthetic seismic volume (right)
is generated from the reservoir model. It is then compared with the acquired version to calibrate assumptions made about model properties, and the process is repeated.
>Case studies. The Rock3D Synthetics module provided the synthetic seismic volumes for both case
studies. In each case geophysicists display acquired seismic data alongside synthetic data by modeling the properties on vertical slices. The highlighted regions (white circles) show a lack of alignment; in both cases the reservoir model properties were recalibrated and the process was repeated until they aligned.
Case Study A Case Study B
model was built and on the uncertainties sur-rounding the seismic data used to constrain the model. Working within the same modeling envi-ronment also facilitates discussion among the reservoir modeler, petrophysicist and seismic interpreter to identify where changes to the input interpretation may improve the model quality. Finally, a historical audit trail of each modeling step created by the Petrel software provides details of interpretation and modeling decisions taken at each stage of the project.
Typically, interpreters perform a seismically constrained quality assessment early in the pro-cess of building the reservoir model. This ensures that models built from measurements made at the high-resolution well log scale are consistent with the lower resolution seismic response prior to advancing to more detailed modeling within the G&G workflow. The quality assessment also informs decisions on the level of seismic inversion needed for any modeling project, optimizing application of Shell proprietary seismic inver-sion technology.
The new verification workflow demonstrated a mismatch between synthetic seismic and pro-cessed data in a number of models (previous page, bottom). By resolving these large-scale modeling issues earlier in the process than pos-sible using traditional approaches, Shell potentially saved a significant amount of time in project delivery.
Electromagnetic Modeling
Independent software developers can make use of the Ocean framework to deliver software products and take advantage of the large Petrel user base. Blueback Reservoir, a reservoir modeling consulting company, formed a software development team to capitalize on this market in 2007. The team’s first project was in collabora-tion with a company that supplies electromagnetic services, Electromagnetic GeoServices. The new software product adds electromagnetic modeling (EM) capabilities to the Petrel suite and is com-mercially available as the BRIDGE EM Data Integrator plug-in. The new capabilities demon-strate the power of combining a technology- specific application within a broad-use modeling package, as applied by a third-party developer.
When the project began, the Blueback Reservoir team had no EM experience; therefore, all domain knowledge was provided by the service company. Although the framework delivered the capabilities to create the new module without Schlumberger collaboration, the software develop-ment team used the Ocean support Web site throughout the project for technical questions.7
One of the project’s major challenges was that it needed an entirely new data type to represent the electromagnetic data. The two main require-ments were the visualization of the data in all supported displays such as the Petrel 2D and 3D canvases, and data handling between connected functions such as 3D grid property modeling and volume and orthographic slice probe creation.8
Electromagnetic data provide resistivity proper-ties throughout survey areas by detecting waves that have propagated through the subsurface of the Earth.9 Two basic methods for EM surveys are available: magnetotellurics, which uses naturally occurring EM waves caused by the interaction of the solar wind and the Earth’s magnetosphere, and a newer technique, controlled-source electromag-netics (CSEM), which incorporates an artificial source of EM waves. Using the new BRIDGE EM plug-in, modelers can combine CSEM inversion data efficiently with seismic and gravity surveys to enhance model calibration (right).
There are several main steps involved when executing a CSEM project using the new plug-in. First, a geoscientist undertakes a feasibility study to evaluate whether a CSEM survey is likely to provide data signals that are of sufficient quality to be interpreted. Considerations for the study include the presence of salt, large topographic variation of the seabed and highly faulted struc-tures, all of which interfere with the CSEM signal. The investigation is performed in the Petrel modeling environment: The geoscientist creates a resistivity model based on existing knowledge of subsurface structures and rock types that is obtained from seismic and geologic surveys and well logs. The model is then evalu-ated by a team of experts to determine whether to proceed with a CSEM survey.
The next phase is to plan the field operation. CSEM receivers are placed directly on the seabed. The BRIDGE EM module in the Petrel environment allows a survey planner to identify good locations for receivers: align with areas of geologic interest, avoid subsurface structures that attenuate CSEM signal and identify seabed locations that are unfit for receiver deployment. The planner also uses the plug-in to plot the optimal course for the source vessel, which will tow a CSEM transmitter over the survey area in a specific configuration.
Once a survey is completed, the data undergo QC and the CSEM attributes such as electric magnitude and phase are interpreted. It is during this stage that data are integrated with the reser-voir model. The QC and interpretation processes are BRIDGE EM plug-in capabilities, designed to
streamline the time-consuming processes as much as possible. CSEM results are typically cali-brated with existing information, such as seismic and well log data, within the Petrel workflow. 7. The BRIDGE EM product is independent of the EM plug-in
bundled with WesternGeco EM services.
8. Canvas, in computer graphics terms, describes a region that can be painted into with electronic content such as 2D well logs, charts, graphs or 3D objects. A 3D grid is a representation of the reservoir divided into an irregular grid of 3D cells. Each cell can contain multiple reservoir properties, such as porosity, permeability and resistivity. This discrete grid is designed to simplify computational algorithms and to work within current computing capabilities. An orthographic slice is a 2D flat plane that is locked to an axis; for example, vertical slices are parallel to the z-axis. A volume extends a plane in three dimensions visualized as stacked slices or a cloud of voxels—3D pixels. Slice and volume probes are textured with property values that represent the intersection of the probes with the reservoir structure.
9. Brady J, Campbell T, Fenwick A, Ganz M, Sandberg SK, Buonora MPP, Rodrigues LF, Campbell C, Combee L, Ferster A, Umbach KE, Labruzzo T, Zerilli A, Nichols EA, Patmore S and Stilling J: “Electromagnetic Sounding for Hydrocarbons,” Oilfield Review 21, no. 1 (Spring 2009): 4–19.
>Usefulness of EM data. When calibrated with
seismic survey data (top right) and wellbore resistivity measurements (top left), surface-acquired EM data are used to generate a model of resistivity zones over a large survey area. When EM inversion is performed, a resistivity volume is created. It can then be visualized using several modeling tools. These resistive formations (purple 3D object and red, orange and yellow colors overlaid on seismic slice, bottom) may be salt, basalt or hydrocarbon-bearing zones.
A volumetric cube of resistivity data can be created from inverted 3D CSEM data. Using Petrel modeling tools, a geoscientist can identify 3D resistivity compartments. When these are compared with seismic data, the results can pro vide an oil and gas company with the information it needs to move on to well planning (above).
The initial team working on the BRIDGE EM Data Integrator module comprised two devel opers, who created a prototype. Two more developers joined the team to complete the com mercialization process, which included software testing, document creation, user training and user support. The prototype development took four months; this reflects the length of time needed to create and properly integrate a new complex data type. Blueback Reservoir continues to provide new tools using the Ocean framework.
The Role of Academia in R&D
Many industries share the view that academic institutions can play an increasing role in their R&D programs. Especially during periods of eco nomic downturn, research faculties typically have more freedom than industry to perform fun damental studies and investigations into creative, new and abstract areas. Academic research has several entry points for companies to engage. Enlisting the skills of a college student is a low level entry point, and involving a professor, a postdoctoral researcher and a research assistant is an entry of much higher level. This flexibility enables sponsors to identify the level of research they require and narrow the level of investment needed for a project. This workflow might also be beneficial for companies exploring blue-sky research, which is becoming much harder to jus tify outside of academia.
There are other ways this connection between a company and academia benefits both col laborators. Universities become more aware of
the needs of employers and may choose to adjust their academic programs accordingly. Furthermore, students who are involved in company research projects become strong candi dates for future recruitment.
It is sometimes difficult for companies and academic institutions to reach acceptable terms of agreement for sharing information. For joint development of E&P software, safeguards must be emplaced to protect the sponsor’s IP while providing universities access to information they need to develop new ideas. The Ocean frame work, which is based on API tech nology, enables universities to develop G&G software in the form of plugins that can interact with other plugins provided by the sponsor company. With this model, companies can protect their IP with the framework and extend their G&G workflows through investment in university research pro grams. By using the framework tools and functionality provided by existing plugins and the Petrel suite, universities can build on top of them. This building block can save a great deal of development time when compared to writing all this functionality again each time.
In August 2009, Schlumberger launched an initiative to strengthen industry relations with academia. The Ocean for Academia Program, with support of oil and gas companies, engages universities in select R&D topics. These categories include information sciences and technologies, petroleum engineering, earth sci ences and cognitive sciences. The program helps the industry to establish collaboration with uni versities for the development of specific Petrel plugins to enhance G&G workflows.
Looking Ahead
Open frameworks based on API technology are building a development culture that is mutually beneficial to the original software owners, independent software vendors and users of the technologies produced. For example, frameworks can be used by companies to develop software functionality that may be unique to their needs. If those needs are not unique, the developer may choose to make the functionality commer cially available, thereby entering competition with other developers. In such an environment competition can drive innovation, improve qual ity and lower cost. Since the Ocean framework was introduced, it has been used to create more than 100 new modules. These modules have been created by Schlumberger, oil and gas companies, academic institutions and independent soft
ware vendors. —MJM
>BRIDGE EM workflow from screenshots. The module provides planning and QC tools specific to
CSEM operations within the Petrel suite. Surface resistivity measurements are normalized and used to identify the locations that provide good signal for CSEM receivers (bottom left). Chosen receiver locations are then used to plot towing paths for CSEM surveys (top left). After a survey, the application provides data formats for import of EM data, such as field strength and phase, allowing a QC check through a user interface that has been optimized to improve the efficiency of the process (top right). The BRIDGE EM plug-in provides a new EM data type for the Petrel data model, enabling the user to view the CSEM survey alongside well logs and seismic data (bottom right).
Calibration Quality control and interpretation CSEM survey planning
