Feature-Rich Software, Open by Design

Transcription

1 Feature-Rich Software, Open by Design 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. 1. For more: Application Programming Interface, Free On-Line Dictionary of Computing, 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. 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. In an ideal world a piece of software would contain 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 programming 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 elements or all the software to enable users or other developers to extend its capabilities with new features. This is beneficial to independent developers 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 original developer loses the ability to control the changes made to the primary software. Second, the proprietary intellectual property (IP) associated 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 programming 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, subtraction, multiplication and division procedures. These mathematic functions are supplemented by sine, cosine and tangent trigonometric functions later added by an independent programmer. 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 functions 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 comprehend. 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 developers who work to extend the core software 46 Oilfield Review

2 program. The ecosystem components deliver more functional value when combined than they do individually, 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 userfriendliness. 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 functionality while independent developers provide additional components in the form of plug-ins. New modules vary in complexity. A simple time-saving algorithm that automates a manual data-manipulation process can be created in minutes by anyone with basic programming skills. However, a plug-in providing more sophisticated capabilities such as electromagnetic modeling requires a greater commitment by a team of programmers and oilfield experts. Opening the software benefits both independent 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 industrystandard programming tools such as the Microsoft.NET framework and Visual C# language, 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 capabilities. The second study focuses on its use by an Autumn

3 Prestack seismic data processing Real-time geosteering Seismic inversion Reservoir simulation Poststack seismic interpretation Rock physics and synthetic seismic modeling Well planning Reservoir modeling Electromagnetic data interpretation > Example G&G workflow from screenshots. The process begins by importing and interpreting information including seismic data (top left) and electromagnetic 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. independent software vendor to create an electromagnetic 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 complete. Many geologists, geophysicists, engineers and stakeholders work on a project to plan one or more wells. The process relies heavily on software 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 packages 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 48 Oilfield Review

4 Goal: Add two numbers together and return the answer Independent programmer s code API code Target software code Create integer variables A, B and C Make A = 2 and B = 3 Call API code: C = Add (A and B) Function Add (integer X and Y) Create integer variable Answer Answer = Addition (X and Y) Return Answer Function Addition (integer i1 and i2) Create integer variable i3 i3 = i1 + i2 Return i3 Version 1 Create integer variables A, B and C Make A = 2 and B = 3 Call API code: C = Add (A and B) Function Add (integer X and Y) Create integer variable Answer AddTwoIntegers (X, Y and Answer) Return Answer Function AddTwoIntegers (integer i1, i2 and i3) i3 = i1 + i2 Version 2 Code unchanged Public code unchanged, private code changed to reflect change in target software code Private code changed Translation effect > 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. between the individual software programs. In this symbiotic approach intermediate data are shared across programs, making it easier to identify data migration issues. This method also reduces lost time during import and export routines 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 versions. Most software changes when a new version is released; consequently, links across applications might be completely broken or at least become problematic. Although some linked software 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 elements 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 maintaining a stable relationship among them all. Development guidelines for GUI design, data types and event states are provided with frameworks and can help to create and maintain relationships between plug-ins. While an API goes a long way toward providing a development environment that maintains stable links between software updates, it is still not a perfect solution. Not only do software programs change over time but programming technologies and computer hardware do as well. For example, multithreading has become a viable programming technology for workstation software 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. 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. Autumn

5 > 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. To protect the interests of independent developers, software owners can restrict any significant updates to longer development times, such as making 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 interpretation and a series of algorithmic transformations. Model parameters and their uncertainties may be subjective, and because of the range of uncertainties, 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 forwardmodeling 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. Case Study A Case Study B Acquired Synthetic Acquired Synthetic > 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. Shell uses the Petrel software suite as its primary platform for geologic reservoir modeling and has incorporated this new proprietary workflow as a module of its own modeling workflow. This approach has enabled its software developers to take advantage of existing modeling tools and concentrate on delivering new rock physics functionality. By making use of existing capabilities, Shell was able to reduce development time compared with that required to create a standalone 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 training 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 advantages. 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 50 Oilfield Review

6 model was built and on the uncertainties surrounding the seismic data used to constrain the model. Working within the same modeling environment 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 process 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 inversion technology. The new verification workflow demonstrated a mismatch between synthetic seismic and processed data in a number of models (previous page, bottom). By resolving these large-scale modeling issues earlier in the process than possible 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 The team s first project was in collaboration with a company that supplies electromagnetic services, Electromagnetic GeoServices. The new software product adds electromagnetic modeling (EM) capabilities to the Petrel suite and is commercially available as the BRIDGE EM Data Integrator plug-in. The new capabilities demonstrate the power of combining a technologyspecific 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 development 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 requirements 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 properties 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 electromagnetics (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 structures, 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 evaluated 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 reservoir model. The QC and interpretation processes are BRIDGE EM plug-in capabilities, designed to > Usefulness of EM data. When calibrated with seismic survey data (top right) and wellbore resistivity measurements (top left), surfaceacquired 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. streamline the time-consuming processes as much as possible. CSEM results are typically calibrated 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): Autumn

7 CSEM survey planning Receivers 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 provide 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 developers, who created a prototype. Two more developers joined the team to complete the commercialization 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. Quality control and interpretation Calibration > 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). 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 economic downturn, research faculties typically have more freedom than industry to perform fundamental 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 lowlevel 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 justify outside of academia. There are other ways this connection between a company and academia benefits both collaborators. 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 candidates 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 framework, which is based on API tech nology, enables universities to develop G&G software in the form of plug-ins that can interact with other plug-ins 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 programs. By using the framework tools and functionality provided by existing plug-ins 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 sciences and cognitive sciences. The program helps the industry to establish collaboration with universities for the development of specific Petrel plug-ins 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 commercially available, thereby entering competition with other developers. In such an environment competition can drive innovation, improve quality 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 software vendors. MJM 52 Oilfield Review