reasoning system. Genesis, the system described in this paper contains large heterogeneous cases with metalevel knowledge. A multi-level indexing scheme with both preallocated and dynamically computed indexing capability has been implemented. A user interface allows dynamic creation of similarity measures based on modelling of the user\u2019s intentions. Both user aiding and problem solution facilities are supported, a novel feature is that risk estimates are also provided. Performance testing indicates that the case base produces on average, better predictions for new well developments than company experts. Early versions of the system have been deployed into oil companies in 6 countries around the world and research is continuing on re\ufb01ning the system in response to industry feedback.

Case Based Reasoning (CBR) systems store data and knowledge as a set of cases and reuse the prior knowl- edge to solve new problems. CBR systems can learn by storing the results of a new problem case for future use. Smythe [1] asserts that in the CBR literature it has become apparent that the \u201csingle shot\u201d CBR in which a single case is used to solve a problem, is not adequate for complex tasks. In design and planning tasks, mul- tiple cases are often needed to solve different parts of a complex real world problem. This paper documents a new approach to multiple case reuse involving pre- de\ufb01ned case decomposition and recomposition into a synthetic new case. Statistical methods have been in- corporated to provide both mean value and risk esti- mates for time and cost of the operations contained in the new case.

Optimal, safe drilling of oil and gas wells is a com- plex operation requiring knowledge across a range of disciplines. Wells can be 10 kilometres long or may be

drilled under thousands of metres of seawater. Well tra- jectories frequently must follow a tortuous path or track a thin horizontal reservoir column. An example of well trajectories drilled from a single platform is shown in Fig. 1. Sloughing of fragments of rock from the walls of the well after it has been drilled (borehole instabil- ity), can lead to trapping of downhole equipment or even loss of the well at a cost of millions of dollars. Zones containing \ufb02uid at unexpectedly high pressures can lead to a blowout and even loss of the rig. Drillers learn from each well drilled in an area but with high turnover of staff this knowledge is frequently lost to the company.

The case based software system developed, Genesis, was designed to capture expert drilling knowledge to support intelligent planning of new oil and gas wells. The core of the system is a world-wide case base of data, information and knowledge contributed by par- ticipating companies, in the belief that capturing and sharing experience will lead to better well designs in the future with signi\ufb01cant savings in time and cost.

Kolodner [2] believes that reasoning is more a pro- cess of \u201cremember and modify\u201d than \u201cdecompose and recompose\u201d. This system can be used to retrieve well instances and reuse them with modi\ufb01cation. Historical wells are stored with their operational sequences and durations mapped into prede\ufb01ned atomic components. These are then recomposed into a synthetic new well case using a number of analogous wells or sections of wells from the case base. The system functions both as an assistant and a problem solver.

Kitano [3] asserts that the vast majority of case based reasoning systems have been built as task-speci\ufb01c do- main problem solvers and are detached from the main- stream processes of a corporation. Issues that are not addressed in such systems include:

3.Scalability: Collected cases can increase dramati- cally over time and in real life applications, com- plex multimedia data may need to be stored. Index- ing will need to be constantly re\ufb01ned as the system grows and application needs evolve.

The four points noted above have been addressed in Genesis. Firstly, the case base is stored in a re- lational database system. While this is not ideally suited to a case based system, it can be integrated with existing company databases, and techniques to add the additional indexing required for case based retrieval. Different data access rights can be de\ufb01ned

for different classes of user to preserve data in- tegrity and con\ufb01dentiality. A two layer index sys- tem has been adopted for retrieval of cases based on text concepts. The index is created and stored in the database. If retrieval times degrade, further layers of the index can be added to increase the speed.

The following section describes the case base design process, case contents and structure. Section 3 covers details of methods used for retrieval of cases, including automated information extraction from text. Section 4, on adaptation, details how cases retrieved can be used for problem solution. Section 5 reports results of per- formance testing, followed by discussion of research directions.

Facilitated industry workshops were held with oil com- panies to design a system to suit their needs. A case based system was favoured by the participants, as most appropriate for the capture and reuse of drilling knowl- edge and data. A common theme was that people be- lieve that a case store must be active. That is, it must contain problem solving processes in order to reuse the knowledge for a new design. Engineers wanted ad- ditional knowledge added to their normal design pro- cesses, for example displayed on plots used for plan- ning, or used for risk assessment. Genesis attempts to capture and preserve company knowledge and to make it available in an active, easy to use form. Some innova- tive techniques designed to achieve these goals include:

An important aspect of the design was that engi- neers want to feel in control. They are not prepared to allow a black box system to design their new wells

with complete autonomy. Access to the original stored information for checking is required together with the ability to select or remove cases and add and delete operations at any stage.

Each oil well represents one case instance. A well has attributes such as location, geology, maximum depth and trajectory type (e.g. vertical or deviated), some deviated well trajectories are shown in Fig. 1. Data and knowledge about each well is captured and stored in a database. Wells that have been already drilled are stored as historic data, new designs as planned wells. Large volumes of numeric data are stored. For example, multiple channel electronic log data from down-hole instruments may be recorded every centime- tre for a 10,000 metre well. Log data is used in calcu- lation of variables important in indexing and similarity matching, such as rock strength and rate of penetration.

Text reports may include con\ufb01dential company end of well reports, spreadsheets, hazard checklists and investigations into speci\ufb01c problems, lessons learned and specialised reports from service companies. Pub- lic information from government sources may also be used in new areas of operation, journal and conference papers may provide speci\ufb01c regional information or technological assessments and experience. Images may also be included in a case store. For example, images of worn drilling bits are recorded for further analysis and classi\ufb01cation. Where information relates to a particu- lar rock layer, or formation, this can be keyed directly to the formation name for automatic display whenever the formation name appears on a well plan.

Because access to oil industry experts for knowl- edge acquisition is limited, Genesis uses automated tools to extract knowledge and indexes for the case base from text data. Concept de\ufb01nitions are stored sep- arately from the case base indexes and are read in by the software as part of an index creation run. Com- panies can have concept de\ufb01nitions tailored to their own requirements or can use the Genesis de\ufb01nitions. This feature proved worthwhile when the system was deployed into a Portuguese speaking company, as con- cept de\ufb01nitions in the local language could be used to generate new Portuguese indexes without any change to the software.

When a new planned well has been designed, the new case is incorporated into the system as a planned case. After drilling, the actual data is stored as a new

historic well and can be compared to the planned well for evaluation of the new design case. Post-analysis graphics features are provided to highlight strengths and weaknesses of the new case synthesis. Figure 15 compares the planned and actual depth for a well as a function of time.

Three levels of case structure are implemented at present. Level 1 is a metalevel covering groups of cases. Knowledge relevant to a region or to a formation is stored at this level. One index includes all wells with borehole instability problems, and another stores the main problems and solutions common to each region, with links to the original wells from which the meta- data was extracted. Level 2 indexes well attributes (e.g. location) or groups of attributes. Level 3 indexes on a decomposition of each well into a set of de\ufb01ned drilling phases and operations.

Selection of the best cases for adaptation has been found to depend on the planned user application. For the purposes of planning a new well, the most useful cases generally come from the same geological region, with similar trajectories and using similar hole sizes. However if use of a new technology is planned it may be better to use wells with the new technology even if they are from a remote location. Users can input de- tails of their proposed new well such as location, \ufb01nal hole size and approximate planned trajectory. Similar- ity measures are then built dynamically using a weight- ing derived from the user selection.

The most common retrieval method in Genesis is based on a similarity match between the user\u2019s new planned well and well cases in the database. Users can specify which features of each case are most relevant to the new well plan or system defaults can be used. An example is shown in Fig. 2, where the user has speci\ufb01ed that he would like to use cases from similar locations and with similar well trajectories. This is done by \ufb01rst clicking on the location image, then selecting an area de\ufb01ned by a latitude and longitude rectangle, location is accorded a priority of 1 in this example. Clicking the trajectory image selects trajectory as the second most relevant factor. A similarity metric using only the two user selected attributes and weighted for priority