Building a knowledge-efficient sanding advisor

Knowledge-Based Systems 12 (1999) 145–158

Building a knowledge-efficient sanding advisor M. Kanj a,*, J.-C. Roegiers a,b, M. Zaman c a

Rock Mechanics Institute, The University of Oklahoma, 100 E. Boyd, SEC-P119, Norman, OK 73019-1014, USA School of Petroleum and Geological Engineering, The University of Oklahoma, 100 E. Boyd, SEC-T301, Norman, OK 73019-0628, USA c School of Civil Engineering and Environmental Science, The University of Oklahoma, 202 W. Boyd, Room 334, Norman, OK 73019-0613, USA b

Received 15 April 1998; received in revised form 15 March 1999; accepted 17 March 1999

Abstract Recently, more and more problems in the petroleum industry are being analyzed by the Knowledge-Based Systems (KBS) technology. However, the cost in terms of time and money remains high. To handle this problem smartly, an optimum combination of machine resources, programming skills and development tools has been used in the development of a petroleum-industry sanding advisor/expert-system. Starting with an overview of the system’s knowledge-base and knowledge engineering process, this paper proceeds to discuss its object-oriented programming aspects as well as its reasoning models and graphical user interface characteristics. In addition to the benefits of class inheritance for representing taxonomic knowledge, the message-passing aspect of object-oriented systems simplified the representation of the program’s various modules and interacting components, thus allowing the knowledge engineer to deal with the complexity of the simulation process. q 1999 Elsevier Science B.V. All rights reserved. Keywords: Sand control; Expert systems; Object oriented programming

1. Introduction The development process of any Knowledge-Based System (KBS) is often characterized by two major difficulties: (1) knowledge acquisition and (2) system efficiency [1]. The knowledge acquisition (KA) phase of development is one that can be very frustrating and time consuming. Usually, domain experts (DEs) are very reluctant to share their knowledge and reveal their tricks-of-the-trade [2]: “knowledge is power”; 1 knowledge is job security [3]. For the KA process to be successful, the knowledge engineer (KE) has to respect the domain expert’s knowledge at all times and try to win his trust and friendship [4]. A primary contributor to the success of any expert-system project is the productive interdependence of executives, developers, and users [5]. Efficiency is a major dimension for evaluating system knowledge representation. The selected Expert System Shell (ESS) should make the knowledge available to the computer and should assist in its organization [6]. Knowledge organization, in contrast, should be made to reflect the * Corresponding author. Tel.: 1 1-405-325-2900; fax: 1 1-405-3257511. E-mail address: [email protected] (M. Kanj) 1 Attributed to Francis Bacon.

natural class-instance structure of the domain. The selected knowledge representation language (or system shell) should support an inheritance mechanism that allows knowledge to be stored at the highest level of the class hierarchy. Inheritance facilitates the data representation along the class hierarchy and ensures that all objects of the class share some common properties and methods (meta-knowledge). An expert system not only should save and “memorize” domain-knowledge but also should know about it. Systems should be capable of explaining their problem-solving methodologies and of reasoning about their own decisions. This paper explores the knowledge engineering process used in the development of an industry-oriented expertsystem for sanding assessment and control in wells (SITEX [7]). A stress on the system efficiency (in terms of knowledge-base efficiency, program-structure efficiency, and user-interface efficiency) is also presented.

2. System knowledge-base Sanding is a problem in which formation solid particles are produced with reservoir fluids. The occurrence of sand influx into the wellbore has a great impact on the well completion design and needs to be identified and controlled as early in the life of the well as possible. The process is detrimental to the functionality of the borehole assembly

0950-7051/99/$ - see front matter q 1999 Elsevier Science B.V. All rights reserved. PII: S0950-705 1(99)00027-1

146

M. Kanj et al. / Knowledge-Based Systems 12 (1999) 145–158

Fig. 1. The system’s (broad-point) recommendation possibilities.

(equipment damage), the integrity of the well (casing collapse), and the structure of the reservoir (surface subsidence). Sanding costs the oil and gas industry millions of dollars each year. Sand inflow into the well leads to casing abrasion and failure, formation damage and distortion, and severe environmental problems at the surface. The Sand Inflow Treatment EXpert (SITEX) is a knowledge-based system aimed at providing “expert-quality” solutions to sanding problems in wells. Its knowledgebase is mostly extracted from human experts in the domain in an attempt to emulate their methodology and performance. As with skilled humans, the system tends to be specialist, focusing on a narrow set of problems, and involves theoretical as well as practical knowledge. Its knowledge-base is composed of four basic modules that give recommendations on (1) sanding assessment and likelihood in wells; (2) sand-control and exclusion treatments’ selection and identification; (3) gravel-pack gravel; and (4) screen selection and design. To a certain extent, this reflects the natural steps followed by experts in petroleum and related industries, which include: (1) identifying/quantifying the problem; (2) selecting an efficient/suitable treatment measure; (3) designing the sand-exclusion approach; (4) preparing the well and implementing the control process; and (5) evaluating the job and projecting its performance based on field case histories and known experience. The sanding assessment module of the system simulates experts’ heuristic reasoning approaches in predicting sand production. The module grades the examined well based on factors such as porosity, clay content, water breakthrough,

formation-cement water solubility, reservoir depletion, and formation depth and geological age. The grading is then used to assess the possibility of sanding and to determine its likelihood. The system’s method selection module evaluates the performance of 10 of the most commonly used sand-exclusion methods. Each method is evaluated based on sand fineness, interval length, permeability, type of fluid produced, productivity, longevity, rig availability, well trajectory, completion type, and economics. As a result of this evaluation a grade is assigned to each method. Method grades are then used to eliminate inapplicable, impractical, and economically infeasible treatments and to classify the recommendable ones. Two design methods form the basis of the gravel selection/design module of the program. A third, heuristic-based routine optimizes the design selection in case the end-user is undecided or has no preference between the other two gravel design methods. The gravel-pack gravel design module makes use of a database containing a list of standard gravel sizes and their characteristics. The accompanying database is a stand-alone file that is very independent of the main system. Accordingly it can be updated at any time without needing to modify any of the program’s codes. Seven different types of sand retention screens and liners are included in the screen selection module of the sanding advisor. The type of completion job that is being performed on the well constitutes the starting point for the selection process. The system also acknowledges (considers) the effect of well trajectory, interval length, type of acid (if

M. Kanj et al. / Knowledge-Based Systems 12 (1999) 145–158

147

Fig. 2. Architecture of the sanding advisor.

any), and velocity of the produced fluid on screening and classifying the different types of sand-exclusion screens. An in-depth analysis and review of the system’s knowledge-base is provided elsewhere [7]. Fig. 1 depicts the system’s basic modularity along with its major recommendation options and characteristics.

3. System design The developed sanding rule-based system has three main and basic blocks constituting its structure: 1. A plug-and-play, modular knowledge-base; 2. A robust, object-oriented inference engine (part of the Nexpert Objecte 2 system shell); and 3. A familiar, consistent graphical user interface. Fig. 2 depicts the different structural components of the system. The heart of the system is its knowledge-base. It emulates the knowledge-engineer’s understanding of some experts’ “knowledge” about the particular problem domain (sanding assessment and control). Modularity of the knowledge-base plays an important role in the life of the expert system. The sanding advisor is characterized by a plug-and-play modularity. Thus, it can be easily upgraded as well as expanded. The selection of proper software tool remains an important part of any expert system development. Expert system building tools evolved from early research that recognized the importance of maintaining the separation between the knowledge-base and the inference engine. These, also known as expert-system shells, offer a generic environment for developing knowledge-based systems. Inference engines control knowledge processing and apply the knowledge to the solution of the actual problem. The explanation 2 Currently known as Elements Experte. A trademark of Neuron Data Inc., Mountain View, CA, USA.

subsystem provides the end-user with explanations of the why/how types to justify the system’s conclusions and clarify the reasoning processes. The knowledge editor accesses the explanation subsystem and helps the programmer locate bugs in the program’s performance. The graphical development environment helps the programmer in viewing and manipulating rules and objects of the system. The main objective behind a graphical user interface (GUI) is to allow developers to create interactive programs with a common feel and look and users to operate programs easily and without fear. The user interface bridges the gap between the complexity of the system and the comfort of the end-user. It also bridges the barrier between users and information and, to some extent, brake the one between graphics and text; thus, making nearly everything on the screen a graphic element.

4. Basic characteristics The developed sanding consultant has three basic characteristics highlighting the heuristic, knowledge-intensive nature of its expert-level problem solving: (1) open to inspection; (2) “upgradable” and expandable; and (3) heuristic. The system is open to inspection, both in presenting intermediate steps and in explaining the behind-the-scenes methodology of its recommendations. Humans by nature have inquisitive and curious minds and, generally, “the computer said so” is not a sufficient reason to follow its advice. During an interactive inference session, the system displays the graphical interface to solicit user input. If desired, the user can obtain a rationale for the requested input (why-type question) from the on-line explanation facility. This allows the user to browse the backward chaining links that lead to the slot (or variable) currently under evaluation. The user inspects the reasoning of the system by selecting the why/how options. When the user selects the why option,

148

M. Kanj et al. / Knowledge-Based Systems 12 (1999) 145–158

Table 1 Heuristic design of a heuristic rule for gravel-pack gravel selection and design RULE

Gravel Selection and Design

IF AND AND AND AND AND THEN

Gravel Design is Wanted; Gravel-Size Dbase is Retrieved; Formation Uniformity Coefficient is Calculated; Gravel Design Method is Selected; Gravel-Size is Calculated; Actual Gravel-Size is Selected. Gravel is Designed and Selected

the on-line help facility reflects the hypothesis and conditions of the next rule in the backward chaining links. When the user selects the how option, the on-line help facility reflects the hypothesis and conditions of the previous rule in the backward chaining links. The sanding advisor is based on good programming techniques that allow the system to be easily prototyped, tested, and changed. For example, the modification of a single rule nearly has no global syntactic side effects. Moreover, the removal or addition of rules, generally, does not require further changes to the main and larger program. The expert system was constructed as a series of modules [7]. Modularization was a natural consequence of the nature of the problem domain which can be easily divided into subdomains of sand production prediction, selection and design of sand-control methods, well preparation and job execution, and job evaluation. System modularity gives the user greater flexibility to tentatively access and evaluate different sanding scenarios and the knowledge engineer more freedom both in adding and in deleting skills from the knowledge-base. The third basic feature of this advisor is its use of heuristic problem solving methods. The system is heuristic in using imperfect-knowledge (“tricks of the trade” and “rules of thumb”) to obtain solutions. This kind of knowledge is often more important than the standard knowledge presented in classrooms or learned in textbooks and it even augments the theoretical knowledge. In addition to the content of the rules (generally heuristic in nature), the ordering of rules’ premises is also heuristic by design. The premises of a rule are ordered in a way so the premise that is most likely to fail or is easiest to confirm (depending on the use of the rule) will be tried first. This allows a rapid elimination of a portion of the search space as early in the search as possible. The rule of Table 1 further depicts and clarifies this statement. The rule’s premises naturally and logically complement each other.

5. System shell used Expert systems bridged the gap between the complexity

of problem domains and the capability of traditional tools, thus allowing developers to move from conventional data processing to knowledge processing (knowcess). System tools provide a natural way of handling tasks that require problem-solving or reasoning. Compared to other development tools, shells make it easier to model reality and to capture and reason with knowledge. Expert systems need not be developed using an expert system shell. Shells exist primarily to reduce the efforts put in defining expert rules and prototyping KB systems, as well as to enhance the ease-of-use. Knowing that many shells are written in AI language, it is possible to develop expert systems using programming languages like C, Pascal, Prolog, Clips, etc. However, system shells made it possible to solve problems that would have been very difficult with conventional programming languages; thus, providing faster and easier design, development, and maintenance. Any commercial/in-house shell can be used to develop the expert system under consideration. However, due to the fact that expert system shells often look, behave, and respond widely differently, it is very important to select an efficient and effective building tool for the targeted problem domain [8]. Cost, targeted users, interfacing capability, platforms compatibility, and ease-of-use, among others, are important factors to be considered in the selection and evaluation of any expert system shell. In addition, different problem domains often require different reasoning processes: backward rather than forward chaining, for instance. If the domain contains more conclusions than facts, the forward chaining reasoning is preferred. Whereas, if the problem involves more facts than conclusions, the backward chaining reasoning is more appropriate. Part of the responsibility of the knowledge engineer is to correctly characterize the reasoning processes required for a given problem domain and to properly select or design the shell (inference-engine) that implements the right type of reasoning structures. Some of the controlling points used in screening shells to be used in developing the sanding advisor included: 1. Shell’s capability to quickly deliver a working prototype and to easily expand one’s existing system; 2. Its ability to provide a comprehensive modeling of the problem domain; 3. Engine’s support for needed types of inference mechanisms; 4. Shell’s graphical and journaling (tracing/debugging) facilities; and 5. Its integration capabilities with external programs. Nexpert objecte (or Nexpert) was selected as the most suitable building and delivering tool for the sanding knowledge-based system. This C-based shell supports most windowing and networking standards and has contributed to the development of many petroleum-oriented consultation systems of proven field value and practicality [9–14]. The sanding development/processing shell provided the

M. Kanj et al. / Knowledge-Based Systems 12 (1999) 145–158

knowledge engineer with all needed representational structures. It provided objects and classes to describe various entities in the domain of sanding and sand control. Moreover, it provided properties that are characteristics of objects and classes; and slots that hold data about certain objects and classes. There are also meta-slots that describe how the slots behave. In the system, rules and objects work together: rules can reason about objects, and changes in objects can trigger reasoning. The inner-working “brain” of any expert system is its knowledge-processing (or inference) engine. The sanding advisor is provided with many types of inference mechanisms. The following search mechanisms are listed according to their inference priority in the system: Backward: This mechanism is based on an immediate evaluation of the rules pointing to an unknown hypothesis which is currently being investigated. The hypothesis could be a slot in the conditions or actions of a rule. Suggest: By suggesting a hypothesis one initiates a goaldriven search on that hypothesis. Hypothesis forward: This is a consequence of investigating subgoals as opposed to a terminal hypothesis. Semantic gates: Forward by gates are mechanisms generated during the evaluation of the conditions list of rules. Sharing a particular slot is a necessary condition for the gate mechanism to occur. Forward action effect: This mechanism occurs when the right-hand side (RHS) actions of the current rule modify the slot of an object which happens to be involved in the left-hand side (LHS) conditions list of another (or even, the same) rule. The forward propagation mechanism works at placing the latter on the system’s agenda pending evaluation. Volunteering: Forward or data-driven chaining starts from a given set of data and reasons forward to a possible conclusion. Context links: Contexts are “weak” forward links set between independent knowledge-islands. They are a unidirectional forward propagation mechanism. Each of these search mechanisms helps expanding the search for relevant conclusions about the problem without exhaustively testing all of the rules in the sanding knowledge-base. This coexistence between different mechanisms constantly works at increasing the system’s efficiency and robustness. Although the use of expert system shells reduces the design and implementation time of a consultation tool considerably, these do not solve all problems associated with building expert systems. Knowledge acquisition and knowledge organization remain difficult tasks that must be handled with great technicality and attentiveness.

149

6. Knowledge engineering The first activities carried out at the start of this project were basically aimed at the identification and delimitation of the problem domain, the identification of domain experts, and justification for the use of the expert systems technology. The system’s knowledge engineering process involved three types of people: (1) knowledge engineer, KE; (2) domain expert, DE; and (3) end-user. The main task of the knowledge engineer was to translate the “strategies” of the domain expert into something the system shell can work with. Primary duties involved selection of software tools for the project, and knowledge acquisition and implementation into an accurate and efficient knowledge-base. Knowledge engineers need not be experts in the application domain. In fact, the knowledge engineer of the sanding advisor was ignorant of the problem domain at the start. Domain experts provided the heuristic knowledge (knowhow) of the problem area to the knowledge engineer. Experts were carefully selected from within the industry based on their reputation and credentials in the domain of sand-control and based on many trusted referring “wordsof-mouth”. The Rock Mechanics Research Center (RMRC) 3 at the University of Oklahoma helped tremendously in this regard. The identified experts showed deep understanding of sanding and its “current” problem-solving techniques, such as using shortcuts and “tricks-of-trade”, handling imprecise data, and evaluating partial solutions. The program’s testing-users helped in pinpointing its early design limitations and constraints and assisted in the debugging process. End-users play a crucial and decisive role in the evaluation process of any industry-oriented software tool. Unless the program considers the skills, capabilities, and needs of its targeted users, it is, merely, a waste of efforts, time, and money [3]. The developed sanding advisor considers user’s need for real-time explanations and help facilities, user’s inability to provide correct information to some of the program’s solicited-questions, environmental/ hardware restrictions on program’s use (such conditions may prevent users from using the mouse and limit their interaction with the program to the keyboard), user’s need to solve the problem as soon as possible and in the most comfortable way. The system’s GUI design is covered last in this manuscript.

7. Knowledge acquisition Knowledge acquisition (KA) is the transfer of problemsolving knowledge from an expert source to a knowledgebase target. The process involves extracting, formularizing, and organizing the heuristic-knowledge so it can be used in 3 A National Science Foundation State/Industry University Cooperative Research Center.

150

M. Kanj et al. / Knowledge-Based Systems 12 (1999) 145–158

Fig. 3. The system’s knowledge-base development cycle.

a program [15,16]. Knowledge-acquisition has always been one of the most difficult and stressful steps in the creation of knowledge- and heuristic-based tools. The process is often described as the main hurdle that confronts the knowledgeengineer and is commonly referred to as the “bottleneck” that constraints the development of expert systems [8]. The KA’s expert source may be either a direct source such as a human domain-expert, or an indirect source such as textbooks, class notes, technical papers and articles, case studies, and databases. Three distinct approaches to KA exist: (1) one-on-one, (2) interactive, and (3) inductive. In the first approach, interviews are conducted to extract the knowledge and encode it into the expert system. The interactive approach to KA is a form of a computer-assisted acquisition that automates the process and eases the need for the knowledge mediator. Learning by induction is, however, an attempt at automating knowledge extraction from data, examples, and case histories via smart programming and neural network [17–19]. The sanding-system’s knowledge was compiled from three main sources: literature (self-learning), questionnaires (conventional/automated), and domain experts (one-on-one interviews). Self-teaching constituted a good starting point in the knowledge acquisition process. Problem-domain literature, journals, and relevant textbooks were considered cheap, accessible, and (commonly) reliable sources of the conventional domain knowledge. In the process of acquiring knowledge on sanding assessment and control in wells, a thorough screening and review of documented publications

and/or reported material was conducted to acquire familiarity with the problem and many of its terminologies and to uncover some of the problem-solving underlying principles. Field trips and site visits also assisted in better understanding the problem, its causes and side effects, and many of the applied treatment procedures. Accordingly, a good description of the problem was generated, many of its prediction approaches were envisioned; and basic information about current control and treatment techniques were compiled. Although it is possible to create expert systems that are merely based on conventional knowledge, these systems lack the heuristic quality and, by far, do not reflect the way experts would advise about the problem domain. “Solicited” questionnaires constituted the second step in the knowledge acquisition ladder. Based on the conducted literature search and review, a preliminary questionnaire (with questions seeming “vague” and “simple minded”, at first glance) was drafted. This provoked the respondents into thinking about why they do what they do and often into uncovering some of their own or borrowed flowcharted/ diagrammed knowledge as well as many of the supporting case histories. This was necessary from their part to backup their own ideas about and replies to some of the questions. In many other cases, however, the replies raised more questions than were answered. This necessitated more elaborate interviews, calls, additional literature searches, and revised questionnaires. Follow-up contacts usually clarified points that were initially unclear. Automated and interactive questionnaires also helped in the knowledge elicitation job. The automation included numerous synthetic field situations to be solved or recommend about. The embedded what–if strategy was able to devise “chunks” of the system’s knowledge tree that were later revised by the knowledge engineer and properly allocated within the KB structure. In essence, the questionnaire replies, on top of the literature, provided an excellent starting point for the construction of the knowledge-base and facilitated bridging the gap between conventional knowledge (literature) and heuristic know-how (domain experts). At the preliminary stage, unstructured interviews with experts helped obtaining a large amount of general information. However, when the acquisition on particular aspects of the domain started, structured interviews were deemed necessary. Structured interviews helped focusing on one subdomain at a time. In addition, semantic diagrams were often drawn during these interviews to codify and represent various reasoning paths of domain experts. Human experts can be notoriously unreliable in explaining exactly what goes on in solving a complex problem [6]. Often, they forget to mention the “obvious” and “automatic” steps involved in their solutions to the problem. Being a novice to the problem domain, the knowledge engineer was able to spot these conceptual jumps and asks for clarifications. The sanding advisor’s knowledge-base was grown rather than constructed. It was built using progressive approximations, with the program’s faults and drawbacks leading to

M. Kanj et al. / Knowledge-Based Systems 12 (1999) 145–158

151

representational paradigms: objects and rules. Its ability to support both rule-based reasoning and object-oriented representation makes it a true hybrid system and a powerful tool for knowledge simulation.

9. Rule structure Fig. 4. The system’s rule structure.

corrections and additions to its knowledge-base. The exploratory development cycle of the system’s knowledge-base is depicted in Fig. 3. 8. Knowledge implementation Object-Oriented Programming (OOP) involves organizing the knowledge into data structures or frames. Class (or object) hierarchy is an important feature of this process. The knowledge representation and organization language should be capable of describing the class hierarchy by relating objects to their classes and classes to their superclasses. Rule-based programming, in contrast, is based on representing knowledge as an: If…

Then…

and

Do…

or

Else…

set(s) of rules. Rules are knowledge structures (actually, they are “chunks of knowledge”) which allow the system to perform forward or backward chaining events along reasoning paths. They represent situations and their immediate consequences. The selected inference engine supports the two Table 2 A rule extracted from the control-methods selection module of the sanding advisor Shell version

English version

Iff .

Trajectory.Angle

458

#

Trajectory.Angle

758

Trajectory angle is greater than 458 Trajectory angle is less than or equal to 758

Then hen TrajectoryAngleConsidered.Hypo Actions ctions DO 7

Category.WF

DO

“C”

AP.Grade

DO

“A”

OHGP.Grade

DO

“E”

SC.Grade

DO

“E”

RC.Grade

.. .

.. .

.. .

Trajectory Angle effect is checked Weight factor of this category is set to 7 “Auger Pack” method is given a “C” “Open Hole GravelPack” method is given an “A” “Sand Consolidation” method is given an “E” “Resin Coated” method is .. given an “E” .

Rules represent the reasoning of the knowledge-based system. They capture the knowledge necessary to solve particular domain problems and reason over the object hierarchy. Rules describe all of the acquired knowledge in the domain, including heuristic and procedural information, relations, and temporal structures of knowledge. The used shell allows rules to be either processed in the forward direction (forward chaining) or in the backward direction (backward chaining). Thus, rules are completely symmetric in the program. The sanding rules have three basic components: • Left-hand side (LHS) conditions. • Boolean hypothesis that evaluates to true when the LHS conditions are met. • Right-hand side (RHS) actions to be undertaken as a result of a positive evaluation of all of the LHS conditions (DO actions part) or a negative evaluation of any of the rule’s premises (ELSE actions part). The RHS actions help retrieving data from and writing data to databases, creating/deleting dynamic objects, assigning/resetting values of slots, executing external programs, showing graphic/text files, and loading/unloading knowledge-bases. All the system’s hypotheses carry past-tense verbs in their names and can be easily identified by their “.Hypo” extension (ScreenPrefsDetermined.Hypo, JobTypeDetermined.Hypo, IntervalLengthConsidered.Hypo, etc.). This type of nomenclature was adopted to achieve a more organized knowledge implementation and much easier system debugging. Fig. 4 depicts the rule structure and identifies its component parts. The partial-rule of Table 2 is extracted from the ControlMethods Selection Module of the program. The rule’s main responsibility is to “grade” various sand-control methods based on their performance in highly deviated wells. A weight factor, Category.WF, is used in this rule to characterize the importance of the category currently being investigated by the system. In the sanding system, trajectory angle, permeability, sand fineness, interval length, productivity, rig availability, among others, are all categories affecting the selection process of sand-control methods. Table 3 depicts the frame format used by some domain experts in heuristically grading different sand-exclusion measures. Other steps in the process include: (1) “de-fuzzification” of assigned grades, (2) economical evaluation and pay-back considerations of each approach, and (3) methods

(12) Completion type

(9) Longevity (10) No rig (11) Trajectory

(6) Productivity (7) Old well (8) Permeability

(5) Fluid produced

(4) Permeability variation

(3) Multiple packs

. 458 # 458 Horiz. Open Cased

$ 50 md , 50 md Not known

6 2 5 10 10 10 7 7 0 2 6 6 6 10 2 7 7 2 9 10 7 4 7 10 10

(1) Fine sand (2) Interval

# 10 ft 10–50 ft . 50 ft Top Bottom Heterog. Laminated None Not known Gas Oil Water

Weight

Factor

Table 3 Control-methods heuristic grading system

A B B A N/A A A B A B A A A B B A B B A N/A C A E A A

Auger Pack

Method

B A A B N/A A B A A B A A A A C A B B B N/A A A A A N/A

Open Hole GP C C C E N/A A C D A D B C C C C C D D B A C C D A A

Thru Tubing GP C C C C A A C C A C B C C C C C D D B N/A C C D A A

Conventional GP A B B C A A A A A A B B C A B B A B B A C A C A A

Consolidated Frac. A A A B A A A A A A A A A A A A A A A N/A A A C A A

Frac Pack D C E F A A D D A D C C C D F C D D C C E D F N/A A

Sand Consolidation E D D D A A D D A D D D D E E D C D D B D D D A A

Drawdown Reduction

A A A A A A A B A B A B B B A B B B A N/A A A A A A

Hi Rate Water Pack

D C C D A A D D A D D D D D D D D D C C E E F A A

Resin Coated

152 M. Kanj et al. / Knowledge-Based Systems 12 (1999) 145–158

M. Kanj et al. / Knowledge-Based Systems 12 (1999) 145–158

153

Fig. 5. A simplified semantic diagram for the system’s sand-control methods selection and classification module. The leftmost methods have the highest recommendation weight.

classification. A simplified diagnostic tree for control methods selection and classification is presented in Fig. 5. The tree considers only six (completion type, interval, trajectory, sand size, productivity, and longevity) of the 12 parameters listed in Table 3. As a reminder, an in-depth analysis of this module can be acquired from other sources [7,20]. The shell’s user-friendly knowledge-editor made entering, modifying, and deleting rules and objects very accessible and convenient. Its graphical networks, in contrast, helped visualizing the inference process and reasoning paths and facilitated debugging the program.

10. Object structure Objects are the smallest chunk of information representing the knowledge being reasoned on by the rules. An object

is an elementary unit of description. It is any tool used in, item of, or factor affecting the problem domain. A class is a grouping of objects behaving similarly or sharing common features and characteristics, called properties. As depicted in Fig. 6, AP, RC, OHGP and SC are all objects (sand-exclusion methods) of the same class called MethodTypes. The same figure also shows that MethodTypes and MethodGrades are two subclasses of the main class MethodData. A subclass is a specialization of the main class. Much like a class, an object can have subobjects. However, unlike class properties, object properties are not usually inherited downward to the subobjects. For instance, the object OHGP inherits all of the properties of the class MethodTypes (Grade, Mark, Point, TypeName, and WF); however, any subobject of OHGP (such as the gravel-packing gravel or the gravel-packing liner) does not necessarily inherit any of its properties. The program’s nomenclature is

154

M. Kanj et al. / Knowledge-Based Systems 12 (1999) 145–158

Fig. 6. Part of the object network associated with the Control-Methods selection/grading module of the sanding system.

based on plural class names (MethodTypes, MethodGrades, CompletionData, GravelDesignHypos,…) and singular property and object names (AP, Angle, Grade, Length,…). This helped differentiating between various elements of the hierarchy and facilitated the debugging process. Slots are used to store property values (data) for objects and classes. A particular property when associated with an object is called a slot. The slot format is: ObjectName:PropertyName (read as “object name dot property name”). Thus, A.Point is a slot holding the point value of the object A and the slot Category.WF tells about the weight factor (WF) assigned to the dummy-object Category. Table 4 A rule involving pattern matching Iff ,

11.1. Dynamic objects The selected shell permits creating (dynamic) objects in the course of knowledge processing (knowcess) by conditions or actions of rules or methods, rather than explicitly by the developer. However, their life is limited to the duration of the session in which they are created. Interpretations and pattern matching are two convenient features that assist during the creation and deletion of dynamic objects and specially when total number of objects to be manipulated is not known a priori or when objects cannot be explicitly stated [21]. Interpretations and pattern matching were used extensively in the knowledge-structure of the sanding advisor. 11.2. Interpretations

SandingTreatment.Budget – kuRecommendedMethodsul.Cost

0

Then hen ExpensiveMethodsRemoved.Hypo Actions ctions CreateObject DeleteObject

11. Object dynamics

kuRecommendedMethodsul kuRecommendedMethodsul

uExpensiveMethodsu uRecommendedMethodsu

Often it is more efficient to use slot values that could be interpreted to object or class names at knowcess. Interpretations make it possible to generate objects, classes, and their properties at runtime rather than explicitly naming them in the rules during program codification and implementation. The interpretation format consists of the name of the slot

M. Kanj et al. / Knowledge-Based Systems 12 (1999) 145–158

155

Table 5 A loop example Iff . ˆ Then hen

Sentinel.Value kkuMethodTypesull.Mark -MAX(kuMethodTypesul.Mark)

0 0

MethodsClassified.Hypo Actions ctions CreateObject DO DeleteObject DO Reset

‘PrefMethod’\Sentinel.Value\ kkuMethodTypesull.TypeName kkuMethodTypesull (Sentinel.Value 1 1) MethodsClassified.Hypo

uClassifiedMethodsu ‘PrefMethod’\Sentinel.Value\.TypeName uMethodTypesu Sentinel.Value

enclosed in backslashes, i.e.

11.4. Methods

\ObjectName:PropertyName\

Methods consist primarily of a set of actions to be executed under predefined circumstances during knowcess. These are attributes associated with individual objects, sets of objects, slots, or properties describing their behavior. Methods defined at the level of the class are usually inherited and used by its objects. The acquired system shell provides two types of system methods: Order-of-Sources (OS) and If Change (IC). System methods defined for a slot consist of actions (set by the developer) that the system triggers when the value of the same slot is needed (OS methods) or changed (IC methods). For instance, the OS method associated with the slot AP.TypeName of Fig. 6 (InitValue ˆ “AugerPack”) initializes its value to “AugerPack”. In a method, the special name SELF can be used to refer to the current class or object executing it. To designate an object slot, SELF should be associated with a property name under the following format:

At runtime the whole expression (\…\) is replaced by the value of the enclosed slot. Thus, if the value of the slot AP.Grade is C and of C.Point is 75; then, the interpretation \A.Grade\.Point holds a value of 75. Interpretations and pattern matching assist in classifying the program’s preliminary recommendations. For instance, the following RHS action statement: CreateObject ‘PrefScreen’\Sentinel:Value\ uPrefScreensu when placed in a loop (rule repeating itself) helps creating a set of orderly classified dynamic objects identifying the recommended sand-exclusion screens and liners. The Sentinel.Value slot is an integer sentinel pointing to the order of recommendation and the number of loops performed. Accordingly, if the value of Sentinel.Value is 5, the above statement creates a dynamic object called PrefScreen5 belonging to the class of preferred screens: PrefScreens. 11.3. Pattern matching Pattern matching allows one to test values of slots without explicitly naming them. Pattern matching of the form: kuClassNameul:PropertyName when placed in a conditional context generates a list of objects (kuClassNameul) within the ClassName class meeting the condition(s) imposed. Existence of this list is limited to the LHS and the RHS parts of the rule that created it in the first place. For example, assume that the class RecommendedMethods contains all the sand-exclusion Methods recommended by the expert-system; however, without taking the cost factor and economics into consideration. Table 4 describes a simple rule that can be used to link all expensive system recommendations to the class ExpensiveMethods and unlink them from the class RecommendedMethods.

SELF:PropertyName When executed, the RHS actions of the rule described in Table 2 work on assigning grades to various sanding treatment methods based on their performance under the specified LHS circumstances. For instance, a “C” grade is assigned to the Auger Pack technique as depicted with the action statement: DO “C” AP:Grade In addition, a category weight factor is set (between 1 and 10) to describe the importance of the LHS conditions in the classification process (Category.WF ˆ 7). As soon as the value of AP.Grade is set or changed, the system triggers the two IC methods associated with this slot (Fig. 6). These IC methods are inherited from the slot MethodTypes.Grade and defined at the level of the class MethodTypes. One IC method is concerned with totalling the weighted grades assigned to the subject sand-exclusion approach. The second method simply works on summing all the weightfactors used by the first.

156

M. Kanj et al. / Knowledge-Based Systems 12 (1999) 145–158

System’s classification of sand-exclusion methods is based on comparing their grade point averages as depicted by the slots relevant to their Mark properties. As such, the single OS method affiliated with MethodTypes.Mark (Fig. 6) does the trick of calculating the final average mark for each of the objects of the class MethodTypes. Moreover, the activation of the exhaustive evaluation strategy in the shell’s inference engine allowed an individual consideration of each and every factor and helped, tremendously, in reducing the size of the control-method selection module of the program. In this strategy, the system continues to evaluate all the remaining rules leading to MethodsGraded.Hypo (i.e. the knowcess jumps from one category to the next), even though the state of the hypothesis (true, false, or not known) has already been determined. 12. Loops/nested-loops of rules A heuristic loop is a single rule or a set of rules firing over and over until a certain terminating condition is met. The use of loops in the sanding expert-system is not aimed at performing factual-based calculations (an indisputable strength of conventional programming) but rather at carrying out some repetitive heuristic-based tasks and/or ObjectOriented Programming (OOP) routines. The program’s loops helped creating dynamic objects whose total number is not known a priori and assisted in classifying recommended control methods and exclusion screens. In general, the loop structure involves three fundamental elements: 1. A terminating LHS condition(s) to avoid an indefinite repetition of the loop. 2. A counter or sentinel (slot container) that keeps track of the loop. 3. A Reset RHS operator that resets the value of the hypothesis back to unknown. The action of incrementing/decrementing the loop sentinel, in conjunction with resetting the hypothesis, forces the rule back onto the system Agenda (pending investigation) via Forward Action Effects. Table 5 presents a rule implementing a loop. The rule is used in classifying the sand-control methods based on their accumulated marks. The first premise of the rule’s LHS part is a “dummy” statement used only to permit the Forward Action Effect. The second premise is the actual terminatingcondition of the loop. The rule’s actions, in contrast, deal with the classification of recommended control methods and with the repetition of the rule itself. 13. The system’s graphical user interface The system’s interface was developed using a Windowse-based software construction kit that offers an Object-Oriented framework for processing customized

GUI applications. Graphical objects are presented in the common “parent–child” hierarchy. The parent for all objects is the software system itself. Next on the hierarchy is the system book: the parent for the application book(s). A page (within the current window) is the parent for objects and groups of objects that reside on it, the background is the parent for the page, and the application book is the parent for the background. The front-end development process started with design and ended with codes. The developer had to learn not only the GUI environment and development tools but also the good GUI design principles. Instead of spending time “prototyping” the GUI, the developer hand-drew two or three versions of each and every screen of the interface. Both users and experts enjoyed examining the “whiteboard” screens; since this gave them the ability to circleout things they did not like and write down their own remarks and suggestions. GUI design is a difficult task requiring a combination of art, communication,… and psychology; on top of programming and engineering skills. It is always easy to learn how to create a button on the screen. But learning when to use a button, where to put the button, or even what kind of button to use is something that has never been that obvious to GUI programming starters. The GUI design should support “business” needs, which means sometimes foregoing many of the attractive graphics. Simplicity should be a byword [22]. The developed GUI incorporates the following features of quality: Consistent: Consistency is an important requirement by users and is by far the most significant rule of GUI programming. If standards are not followed within an application, it will become very difficult for users to become accustomed to the software. GUI experts and design-executives contend that a GUI standard will cut the number of support service calls because the standard will improve software usability. The system front-end interface uses the same fonts and font sizes for related buttons, fields, and records. The actions of related buttons are kept the same throughout the interface. The developer avoided the use of elaborate menu trees, gave objects consistent meanings, required double clicking on all icons, provided menu items that change to reflect the system’s current mode, and, generally, was consistent in placing common elements according to the users’ expectations. Generic: A GUI standard would mean that a template could exist for programmers for how a screen should appear and operate, supported by reusable code [23]. The large majority of the interface scripting was performed at the level of the application book; thus, all objects of the interface are

M. Kanj et al. / Knowledge-Based Systems 12 (1999) 145–158

subject to the same programming codes. This technique is by far more professional and much more efficient than scripting at the level of the object. Accordingly, adding pages and background to the interface is a simple process requiring no more than basic knowledge of the development tool and the (shell-interface) link’s structure and design. The code is reusable in the sense that upgrading the GUI, or even creating a new one, is limited to designing the new screens for the application, and then attaching the input/output interface fields to the proper knowledge-base slots. Controlled by the shell: An expert system GUI is properly designed only if it is being controlled by the expert system itself. The sanding advisor controls its user interface. During knowcess, the system calls the proper pages for input solicitation and makes sure no redundant question is being asked. The system’s pages of input hold only complementary questions. One question per page is very idealistic; however, impractical. In case the list of mutually exclusive options, on a question, is expected to grow in later versions of the program, a single-select list box was used instead of the usual radio-buttons format. The content of the single-select list box is controlled by the expert system. Whenever the knowledgebase is changed or upgraded the list changes automatically without any need to modify the codes of the interface. Another characteristic of this interface is its awareness of upgraders’ expectations and needs. Each module of the GUI involves a set of documentation that explains what the program does, the I/O functions, the related handlers/panels and a modification log, if any. The documentation is kept in the working program itself (i.e. part of the program codes) to preserve it with the software. In addition, the shell–interface dialogue process can be reviewed from within a scrollable hidden-field at the very first page of the interface. This field logs the runtime interaction process between the shell and the interface and, thus, offers valuable assistance to developers, debuggers, and upgraders. 14. Conclusions An expert-system for sand control can be evolved by using the appropriate and best available “experts” not only to provide knowledge but also to aid in developing the overall structure of the program. Meeting and interviewing human experts provide the system developer with an opportunity to extract the systematic and “smart” knowledge process and to provide several analysis techniques that will contribute to different logical paths on the knowledge tree. A structurally efficient knowledge-based system aimed at

157

advising on the sanding problem in wells and at alleviating some of its many serious consequences has been devised. The system’s knowledge-base is grown by progressive approximations rather than constructed. This advisor is based on two important programming methodologies: (1) object-oriented and (2) rule-based. The interaction between the two techniques is prevalent, as well as prominent, in the structure of the system. Object oriented programming (OOP) is a practical and useful design methodology that facilitated the creation and the implementation of the program’s knowledge-base components through support for knowledge organization, object-instance structuring, data abstraction, generic operations and inheritance. The system shell’s Object-Dynamics allow testing values of slots without a need to explicitly naming them (interpretations and pattern matching). Via Object-Dynamics the knowledge-engineer was able to tell the system how to get a value for a slot (OS methods) and what to do in case the slot’s value is changed or set (IC methods). In the sanding advisor, loops/nested-loops of rules are used to carry out the repetitive (heuristic-based) tasks involved in the process of classifying recommended sand control methods and exclusion-screens. Loops are based on a terminating LHS condition, a sentinel, and the forward action effect strategy. The system’s GUI is a multi-viewer and mouse/keyboard driven, true Windowse, application with menus provided on each and every viewer. In addition, each screen is equipped with a status bar that displays a system/interface warning or error message and describes to the end-user a button’s action, a menu-item’s operation, a field’s type and range of the solicited input, or the interaction process between the interface and the inference engine. At the end of a consultation, a report can be reviewed, printed or saved to a file and the session can be saved to a case-file and/or masters-file to re-run and/or debug the design anytime in the future.

15. Further developments and future plans In recent months, the sanding advisor has grown to become the sand-inflow treatment, expert, predictor, and analyser (SITEX-pa). This new approach to sanding is primary concerned with the amalgamation of the many tools of AI and soft computing; namely, expert-systems, fuzzy-logic, artificial neural-networks, and genetic algorithms. Some conventional (analytical and numerical) models are also planned and being gradually implemented into the hybridity and modularity of the new system. In addition, an Inflow Performance Relationship (IPR) equations and pressure drop sensitivity analysis module has been added as a part of the system’s Knowledge-base. This module includes the radial, linear, and tubular IPR equations for both liquid and gas phases and is capable of performing

158

M. Kanj et al. / Knowledge-Based Systems 12 (1999) 145–158

an optimization on the required number of shots perforation per linear foot (SPF). Formation strength analysis, acidizing design and scheduling, perforation design, gravel-packing procedure, hardware selection and operations guide, among others, are some important elements that could be considered for future implementations into the expert-system’s modularity. Other plans for the program include: (1) developing an extensive on-line help facility and sand-control manual and (2) investigating the appropriateness and advantageousness of the KADS methodology for knowledge-acquisition into the sanding domain of oil and gas. It is the latter item on the agenda that deserves some additional comments at this stage. KADS stands for Knowledge Acquisition and Documentation Structuring, but also described as Knowledge Analysis and Design System. In its simplest form, it is considered an established approach to documenting the KBS development process. When used in “full”, though, KADS depicts a top–down, product-driven, well structured methodology for the development of KBSs. The central theme in the KADS methodology is modeling [24–26]. KADS provides a library of generic models, supported by diagrammatic representations, that enables effective KBS construction and maintenance; thus, promotes reuse and standardization of expertise components. Selected model(s), however, requires additional (and attentive) tailoring and refinement to meet the requirements of the expertise. Overall, KADS has various components [27]: (1) a methodology for managing knowledge engineering, (2) a knowledge engineering workbench, and (3) a methodology of performing knowledge elicitation. While the adopted cyclical approach to knowledge engineering in the sanding advisor allowed the KE to show early progress (rapid prototyping) and provoked the DE’s enthusiasm; the KADS pragmatic approach will be investigated in this domain of the oil industry in an attempt to store the DE’s knowledge in its final form, as an intermediate representation, 4 and make the knowledge elicitation process less problematic and of predictable length.

Acknowledgements This research study was supported by funds from the Rock Mechanics Consortium (RMC) at the University of Oklahoma, the Oklahoma Center for Advancement of Science and Technology (OCAST), and the National Science Foundation (NSF). The management of ARCO E&PT is gratefully acknowledged for its permission to explore two of its in-house expert systems (“AcidMan” and “Sand-Control Advisor”) at an early stage of this project. 4 In this format, the knowledge will be final, complete, and re-usable. Thus, the same DE becomes less of a key player in rebuilding the system.

References [1] T. Murphy, An expert by the rules, AI Expert 8 (1) (1993) 19–21. [2] J.P. Ignizio, Introduction to Expert Systems, McGraw-Hill, New York, 1990. [3] J.K. Liker, A.A. Sindi, User acceptance of expert systems: a test of the theory of reasoned action, Journal of Engineering and Technology Management 14 (2) (1997) 147–173. [4] P.E. Dessert, The process of heuristic development, AI Expert 6 (12) (1991) 36–39. [5] J. Nash, Expert systems: a new partnership, AI Expert 7 (12) (1992) 36–39. [6] G. Luger, W. Stubblefield, Artificial Intelligence: Structures and Strategies for Complex Problem Solving, Benjamin/Cummings, Redwood City, CA, 1993. [7] M. Kanj, M. Zaman, J.-C. Roegiers, Sanding: an expert-system approach for assessment and control in wells, Journal of Energy Resources Technology, ASME 119 (4) (1997) 223–235. [8] A. Badiru, Expert Systems Applications in Engineering and Manufacturing, Prentice Hall, New Jersey, 1992. [9] S. Webber, An expert system for hydraulic fracturing, PhD dissertation, The University of Oklahoma, Norman, OK, 1994. [10] S. Khan, G. Pope, K. Sepehrnoori, An expert system for miscible gasflooding, SPE-24431/SPECA, in: Proceedings of the Seventh SPE Petroleum Conference, Houston, TX, 1993, pp. 11–17. [11] D. Kulakofsky, F.-L. Wu, D. Onan, J. Wohleb, Development and application of a knowledge-based expert system for cement slurry design, SPE-24431/SPECA, in: Proceedings of the Seventh SPE Petroleum Conference, Houston, TX, 1993, pp. 21–25. [12] H. Xiong, S. Holditch, Stimulation expert, in: Proceedings of Artificial Intelligence in Petroleum Exploration and Production Conference, College Station, TX, 1991, pp. 71–80. [13] C.R. Blackburn, J.C. Abel, R. Day, An expert system to design and evaluate matrix acidizing, SPE-20337, in: Proceedings of the Fifth SPE Petroleum Computer Conference, Denver, CO, 1990, pp. 103– 108. [14] D.J. MacAllister, R. Day, M.D. McCormack, Expert systems: a 5-year perspective, SPE Computer Applications 8 (1) (1996) 10–14. [15] D. Waterman, A Guide to Expert Systems, Addison-Wesley, New York, 1986. [16] P.E. Slatter, Building Expert Systems: Cognitive Emulation, Wiley, London, 1987. [17] K.G. Coleman, S. Watenpool, Neural networks in knowledge acquisition, AI Expert 7 (1) (1992) 36–39. [18] R. Knaus, Knowledge acquisition with nets, AI Expert 7 (9) (1992) 17–21. [19] L.B. Eliot, Ruling neural networks, AI Expert 10 (2) (1995) 8–10. [20] M. Kanj, SITEX: The Sand-Inflow Treatment EXpert, PhD dissertation, The University of Oklahoma, Norman, OK, 1995. [21] Nexpert Objecte: Functional Description Manual, Neuron Data Inc., Palo Alto, CA, 1993. [22] T. Lynch, Avoiding another tower of Babel, ComputerWorld 28 (10) (1994) 73. [23] M. Betts, Standard GUIs make sense, ComputerWorld 28 (11) (1994) 75–76. [24] B.J. Wielinga, A.Th. Schreiber, J.A. Breuker, KADS: a modelling approach to knowledge engineering, Knowledge Acquisition 4 (1) (1992) 5–53. [25] B.J. Wielinga, W. Van de Velde, A.Th. Schreiber, J.M. Akkermans, The KADS knowledge modelling approach, in: Proceedings of the Second Japanese Knowledge Acquisition for Knowledge Based Systems Workshop, Hatoyama, Saitama, Japan, 1992, pp. 23–42. [26] J. Kingston, Applying KADS to KADS: knowledge based guidance for knowledge engineering, Expert Systems 12 (1) (1995) 15–26. [27] D.S.W. Tansley, C.C. Hayball, Knowledge-Based Systems Analysis and Design: A KADS Developer’s Handbook, Prentice Hall, Englewood Cliffs, NJ, 1993.