Reservoir Characterisation Services are a growing activity, operating either within dedicated or integrated service companies, or as business units within oil and gas companies.
Performed on a consulting basis for clients (typically asset team end-users), reservoir characterisation services operate a suite of geoscience computer applications to provide a set of results at various stages of an asset life-cycle, from initial exploration assessment through appraisal programs, field development planning and secondary recovery projects.
These services are by definition a deadline-constrained activity, but beyond the deadline are periods of little or no work as the results are being used to steer a drilling program, or facilities are being built and put into production.
At the point in time when a final delivery has been made to the client, the service provider needs to collect all relevant data used or produced in the course of the project, to ensure safe keeping and potential access at a future date.
The client can indeed decide at any time in the future to request additional work in continuation of the last deliverables. It is therefore important for the service provider to be able to pick up the workflow where it was last suspended, and proceed as smoothly as possible to produce the newly-required results.
Very large integrated software and database suites are normally hosting a large per centage of RC data, with two products foremost in the industry: GeoQuest’s GeoFrame. suite, and Landmark’s OpenWorks?. Both use a complex data model managed by the Oracle. RDBMS, and address many data processing and interpretation capabilities through the use of tens of applications.
However, many other applications are used in RC services, originating from independent software providers, or developed by the service provider as a specific value proposition. These applications will run either on Unix or PC platforms. Reports are written using PC applications, and graphic packages will often be put to use to produce assemblies of visuals for project presentation purposes.
Data for a project will therefore comprise a diversity of data types, storage structures and groups of files, stored on Unix, PC or network storage filers.
The notion of project data must therefore encompass all these different sources and structures of data, so that the accrued knowledge relative to the project can be captured in its entirety.
Server A Server B Server C NAS Project data is frequently managed by different applications, and can be spread over many file systems and servers, populating databases and/or directories with many different data types and file formats.
The first task of a Data Management Solution (DMS) will be to allow for a comprehensive encapsulation of all data related to a service project into a single bundle, with appropriate labelling for future retrieval.
The encapsulation process must therefore be application-aware, ie understand how each application or family of applications stores data, how to trace and store the lists of physical files and their locations, as well as extract from the RDBMS all the descriptive and relational information necessary to snapshot the project, and enable future restoration.
Constructing an archive of a project will then consist in identifying, for each application used, the lists of data files that need to be associated to the project. This list will constitute the contents of the archive.
In addition, some descriptive information is required to label the bundle of data, some of it factual (user names, geographical location, dates, volumes of data, etc), some of it free-formatted, for comments and qualifiers relative to the archive.
It is perfectly conceivable to do all these tasks manually, or by the use of scripts. But when the long-term goals of the business are put in the equation, and one considers the scarcity of time and skills to manage effectively such a task, this is not realistic. Automation comes to the fore as the most efficient solution to satisfy project archiving needs.
Three levels of automation are necessary to fulfil the brief:
* Automate data collection: for each application or database, define the rules and mechanisms that make it possible to locate and list exhaustively all the files of a specific project, for inclusion in the archive.
* Automate metadata acquisition: use interactive interrogation windows to input, store and retrieve the information describing the project. This data is known as metadata, and is ideally managed by a relational database.
* Automate the archiving job: the process of allocating tape media for the archive, running the archive job, and verifying the outcome to ensure that all the data has been securely recorded on tape.
Whether as a contracted company working for a client, or as a department or business unit within a larger company, the activity related to reservoir characterisation is often on the critical path of a large asset development project. Delays in delivery affect massive investments and the timely deployment of considerable resources. This can go from weather windows to the time-constrained availability of a scarce commodity such as deep-water drilling equipment.
Terabytes of disks are being backed up daily, and make it possible to re-instate a defective disk drive should it malfunction. But how can one cover for a major loss of a facility (and its computer resources) in the event of a fire, a flooding or an electrical incident?
Setting up a temporary location to continue work as best possible on the most critical projects demands a specific approach. It will not be possible to procure at one or two days notice the equipment equivalent to that, which has been lost. Nor is it necessary, as all work and all data was probably not critical. What counts is to get back to work on the few (10 per cent to 30 per centy?) projects that can suffer no delay, and make sure that the geoscientists can resume work within 24 to 48 hours.
Regular snapshot archiving of these critical projects, with a copy going to a secure off-site location, will provide for the availability of the data. Further thought must be given to having in reserve some bare-bone computer systems capable of hosting the most necessary applications for the interim period, with valid licenses at all times. Finally, a configuration (tape drive plus server) capable of restoring the archive media to these systems will be needed.
Rehearsal is key to getting these components right, and ensuring that, should the unthinkable happen, all actors know what to do, and all equipment is ready to roll, to ensure successful operation during the emergency period.
Disaster Recovery is now a well-identified field of activity, and service companies can provide turn-key solutions including stand-by staff and equipment, consulting to establish the policies and procedures for disaster recovery, dry runs and much more. Costs are reasonable in comparison to the risk of missing deadlines and forfeiting critical project completion. Like insurance, thinking of Disaster Recovery before a disaster hits is the best way to minimise the impact. It is also a strong statement towards clients regarding responsible risk management.
A reservoir Characterisation project can include a large amount of data, with the main volumes of data comprising simulation and seismic information, but also graphic metafiles, images, etc. While this project is active, all data must be accessible with minimal latency, to facilitate rapid turn-around. On the other hand, once the deliverables have been shipped and accepted by the client, the gigabytes of disk space occupied by that project could be put to better use.
Experience shows that, in most instances, a project is never entirely finished. Clients can come back after a few weeks to challenge some assertions, or to request more insight into areas of interest. Assuming that action was taken following the results of a project, when new wells have been drilled or additional production information is acquired, this data should be integrated into the model and the impact on reserves or development planning should be quantified.
4D seismic, a cyclical activity to assess changes in reservoir depletion over time, introduces additional incentives to pick up old projects to perform further work.
The probability of a project returning to live status is therefore relatively high. The unknowns are when, and what for? Leaving all projects on magnetic disk media, no matter how cheap such media can be, and leaving their instances in the relational databases, burdens the overall service activity. It also means that the cost of disk storage must be factored into the project budget, as the resources will never be released for other uses.
The alternative is to ‘park’ the standby projects on a near-line storage system, with an index of all these projects, their contents and other information of interest. Once the integrity of the “parked” data has been verified, the project can be erased from disk, allowing other projects to use the disk resources.
A ‘parked’ project should be re-instated with relative ease, completely or selectively for the data of interest, typically on an application basis (eg re-instate the SeisWorks, Geolog and Eclipse files only).
It is obvious by now that this activity of parking projects is in essence exactly the same as producing and restoring an archive. In practice, an RC group that is making regular and complete use of a cross-application archiving solution has the means to make much better use of disk space, at little or no additional overhead in time or investments.
The particular nature of RC service activity can benefit widely from the implementation of structured archiving solutions operating on automated near-line systems. Such facilities address many specific issues such as the collection of data related to heterogeneous application platforms, the implementation of disaster recovery capabilities to ensure timely delivery, and the optimal use of disk resources in relation to the deactivation or activation of RC projects.
Such solutions can be implemented using existing near-line tape robots, if they are already in place within the company. Should that not be the case, or should it be desirable to have local control of the process, new tape cartridge formats and the associated robotics have become surprisingly accessible from a budgetary point of view, as well as robust and easy to use even in the context of small work groups with limited time and skills to devote to IT issues. Complete bundled solutions, including hardware, software, installation and media can be obtained for less than $100.000 on purchase, or less than $10.000 per month on rental schemes.
Enigma Data Systems is a software production company that specialises in large-scale data management solutions. Enigma has its origins in the upstream oil and gas industry, and uses technologies that are often derived from original research by, for example, major oil companies such as Mobil Oil (now part of ExxonMobil). As is usual for small technology companies, valuable partnerships are in place to provide end-users with a well-integrated product.
Jim Ashford is with Enigma Data Systems, Haywards Heath, West Sussex, UK. www.enigmadata.com
Tape cartridge systems
The integration of a tape library system into an existing IT environment is frequently perceived as a delicate and difficult task, the more so when hardware support skills are scarce. It is important to pay attention to the I/O layer of the archiving solution to ensure that it interacts transparently with the library, adapts to the throughput, manages exceptional situations in a sensible manner, and in general takes care of the intricacies of the hardware with little or no intervention from company staff.
Solutions exist nowadays involving modern tape management hardware and transparent I/O layers that in effect isolate the user and administration communities from any involvement in the daily operation of a tape library, beyond feeding and removing tapes as instructed by the software. These systems are cost effective, highly reliable and require little or no resident skills to provide durable and robust services.