An expert system for offshore structure inspection and maintenance

0045.7949191s3.00 + 0.00 8 1991 Civil-Camp Ltd and Pwgamon Press plc

Conputers & Structures Vol. 40, No. 1, pp. 143-I59, 1991 Printed in Gnat Britain.

AN EXPERT SYSTEM FOR OFFSHORE STRUCTURE INSPECTION AND MAINTENANCE K. AHMAD,~ A. LANGDON? and P. A. FRIEZES of Mathematical and Computing Sciences, University of Surrey, Guildford, Surrey, U.K. TAdvanced Mechanics & Engineering Ltd., Surrey Research Park, Guildford, Surrey GU2 5YJ, U.K.

tArtificia1 Intelligence Group, Department

Abstract-The inspection and maintenance of offshore structures is carried out by experts who have considerable experience, and are able to bring to bear a large body of knowledge, for solving a variety of problems. However, the full extent of knowledge required to completely rationally execute inspection and maintenan~ of offshore structures is beyond the scope of one individual without the assistance of a comprehensive system with access to the necessary databases and algorithms. The PLAIM (Platform Lifetime assessment through Analysis, Inspection and Maintenance) project has been established to provide such a system. ‘Knowledge-Based’ Expert Systems methods and techniques, particularly those related to the acquisition of experiential knowledge and representation of the knowledge for solving problems, have been used in the PLAIM project. The major deliverables of this project include the documentation of informal and qualitative knowledge together with a prototype expert system for eliciting details of defects in structures, empirically assessing the severity of the defect and recommending a series of remedial actions.

1. lNTRODUffION

The ins~tion and maintenan~ of offshore st~~tures requires an integrated multi-disciplina~ approach involving materials science, fracture mechanics, marine biology and corrosion chemistry to name but a few. This integrated approach requires a variety of data, e.g. time-series of strain measurements, data related to the various materials used in the structures, inventory data of the members comprising the structure and so on. Assuming that all the data required is available, can be screened and is ‘good’, the analysis of this data is by no means simple, involving as it does a variety of mathematical models, empirical equations, with coe~cients which are either adhoc or based on the experience of having ‘worked’ before. Once processed the onus is on the analyst to interpret the data and take appropriate action. Project PLAIM (Platform Lifetime Assessment through Analysis, Inspection and Maintenace) has two major objectives. First to collate, analyse and archive the inspection and maintenance-related data, and, secondly, to establish a computer program which will: (a) allow access, indeed guide the user to the appropriate data (or data files); (b) provide an ‘intelligent’ interface to mathematical models, indust~-standard simulation programs and empirical equations-this intelligence will help a (novice) end-user to run simulation programs and interpret output provided by the programs; and (c) acquire, formalize and disseminate the experiential and hitherto undocumented knowledge of inspecting and maintaining offshore structures. The computational paradigm to be used for achieving the first objective is based on database management

systems. The second objective can be achieved by o~ration~i~~g the knowledge en~n~~ng paradigm, that ‘experiential’ knowl~ge can be acquired, stored and retrieved in a systematic manner with the help of methods, tools and techniques used in the construction of (knowledge-based) expert systems. Figure 1 describes the architecture of the proposed PLAIM system. PLAIM architecture shows that the project is quite substantial and complex in nature. Therefore, it is important to determine the scope of PLAIM, identify its end-users, establish contact with experts who will provide ‘knowledge’, and specify the computing and human resources required to build such a system: in effect, a detailed functional s~~fi~tion has to be prepared. Such an exercise is made more meaningful by specifying, designing and testing a prototype system which deals with a typical set of problems ultimately to be solved by PLAIM. In this paper we report on the development of the knowledge-based approach to defect damage assessment which will highlight the costs and benefits of using such an approach and its knock-on effect on PLAIM. The current prototype is a task-ariented, rule-based system which: (i) gathers details about defects, site, location, farm, etc.; (ii) assesses the potential hazard caused by the defect; (iii) clcW@es the crack on an experience-based scoring system; (iv) compares the ‘severity’ against pre-stored historic case studies; (v) esrimates crack growth; and (vi) recommends a series of actions. 143

K. AHMAD

144

Data

Base

environmental parameters materials, joints, crack detection,

(X)

et

al.

Analysis

Algorithms

fracture mechanics, stiffness ant strength, joint behaviour, soils, reliability analysis

(F) Fig. 1. Possible PLAIM architecture.

The prototype was developed during the first half of 1989 on a SUN-3 workstation using a PROLOGbased expert system development environment MARVIN [l]. Steps (Q-o-(i) are accomplished by executing 11 different tasks which in turn involve over 100 rules. These rules manipulate 128 different objects (e.g. platform, braces, etc.). We begin with a brief introduction to expert systems illustrated with the help of systems which have been developed for structural design or mechanical engineers (Sec. 2). The next section deals with the available methods of knowledge acquisition, their relevance to problems which PLAIM is expected to solve and the techniques used to acquire knowledge from experts (Sec. 3). The representation issues are discussed in Sec. 4. Section 5 covers issues related to knowledge representation and inferencing strategies of relevance to PLAIM. Section 6 is an annotated (hard) copy of an interaction with PLAIM and Sec. 7 is the conclusion. A more detailed description of the project is available in Langdon and Ahmad [2].

2. BACKGROUND

below for solving problems typical of civil engineering design, water distribution and public health engineering [4,5]. (These systems were developed for the U.K. Water Industry and the Alvey Programme for Advanced Information Technology.) Expert systems which deal with problems of mechanical design, reliability and safety have not been extensively reported. However, there are two systems worthy of note here: SACON, (Structural Analysis CONsultant) and TESSA [Tolerance Expert System for Specification and Analysis]. SACON (Sec. 2.1) is a good example of a rule-based approach whereas TESSA (Sec. 2.2) is a task oriented system. SACON essentially manipulates a large number of production rules, essentially text strings, to ‘solve’ a given problem and conclude by outputting advice which is merely a string of characters. TESSA, on the other hand, creates a model of the real-world and is able to execute its own advice which helps in ascertaining the efficacy of such advice. Table 1. Tasks which prototype and industrial-strength expert sytems can perform Category

The principal artefacts of Knowledge Engineering are Knowledge-Based Expert Systems. These systems have a fairly recent history (c. 1975) and it is only in the last 5 years that industrial strength expert systems have been developed [3]. These systems can be classified according to the knowledge-based tasks they perform: diagnosis, advice, monitoring, interpretation and so on (see Table 1). The authors have developed expert systems which deal with a number of categories mentioned

Interpretation/analysis

Inferring system malfunctions fromfile-based sensor data

Diagnosis

Inferring system malfunctions from observables

Intelligent interface

Guidance in the use of models

Monitoring

Comparing observations to expected outcomes

Repair

Executing plans to administer prescribed remedies

Expert system for offshore structures

2.1. SACON: a consult~t for st~~t~ra~analysis Bennet and Engelmore [6] developed SACON “to advise non-expert engineers in the use of a generalpurpose computer program for 5tructuraI analysis”. The authors argue that “the purpose of a SACON consultation is to provide advice to a structural engineer regarding the use of a structural analysis program ‘MARC’ which uses finite-element analysis techniques to simulate the mechanical behaviour of objects, for example, the metal fatigue of an airplane wing” and that the “engineers typically know what they want the MARC program to dM.g. examine the behaviour of a specific structure under expected loading conditions-but do not know ftow the simulation program should be set up to do it. The MARC progam offers a large, and to the novice, bewildering choice of analysis methods, material properties, and geometries that may be used to model the structure of interest. From these options the user must learn to select an appropriate subset of methods that will simulate the correct physical behaviour, preserve the desired accuracy, and minimize the (typically large) computational cost. A year of experience with the program is required to learn how to use all of MARC’s options proficiently. The goal of the automated consultant is to bridge this twit-to-how’ gap, by recommending an analysis strategy. This advice can then be used to direct the MARC user in the choice of specific input data-eg. numerical methods and material properties. Typical structures that can be analysed by both SACON and MARC include

145

SACON’s analysis strategy consists of an analysis class and a number of associated ana2ysis recommen dations. Analysis classes characterize the complexity of modelling the structure and the ability to analyse the material behaviours of the structure. The SACON prototype could consider 36 analysis classes; among them are Nonlinear Geometry Crack Growth, Nonlinear Geometry Stress Margin, Bifurcation, Material Instability, Inelastic Stiffness Degradation, Linear Analysis and No Analysis. The analysis recommendations advise the engineer on specific features of the MARC program that should be activated when performing the actual structural analysis. SACON uses ‘if ‘ . . then. . . ’ type rule to ‘infer’ from its knowledge base the solution to the problems shown in Fig. 2. A typical rule is shown below for illustrative purposes. IF: (1) The material composing the substructure is one of: the metals, and (2) The analysis error (in per cent) that is tolerable is between 5 and 30, and (3) The non-dimensional stress of the substructure is greater than 9, and (4) The number of cycles the loading is to be applied is between 1000 and 10,000 THEN: It is definite (1 .O) that fatigue is one of the stress behaviour phenomena in the substructure

(SAND (SAME CNTXT MATERIAL

(LIST OF METALS))

(BETWEEN * CNTXT CYCLES 1000 10,000)) (CONCLUDE CNTXT %-STRESS FATIGUE TALLY 1.0).

aircraft wings, reactor pressure vessels, rocket motor casings, bridges and buildings”. Analysis Strategy of the Structure L

Worst-Case Stress and Deflection Behaviours of the Structure L Symbolic Stress and Deflection Behaviours of Each Substructure 1 Composite Numeric Stress and caption Estimations of Each Loading 4 Numeric Stress and Deflection Magnitudes of Each Load Component Fig. 2. Inference structure during a SACON consultation. The user specifies loading and substructure descriptions that the system uses to infer material behaviours and, finally, an analysis strategy. (From Bennet and Engelmore [6].)

2.2. TESSA and IX-TOLD: systems

me~h~i~al design expert

Tolerances are (unfortunately) a fact of life due to the inability of any machine or process to repeatedly produce components of identical size. This is the reason why a maximum and minimum permissible size must be chosen for each dimension of every part in an assembly. It takes years to gain the necessary know-how to allocate effective and economical tolerances. Currently available CAD/CAM packages have a limited capability for dealing with the question of tolerance. Ahmad and Macdonald [7,8] have produced the specification of a comprehensive knowledge based Expert system to advise on the specification and subsequent analysis of TOLerences in mechanical Design (EX-TOLD). This specification has led to the development of a prototype expert system which can advise on aspects of tolerance specification. The current prototype uses a predicate logic scheme to represent the bulk of the domain

146

K. AHMAD etai.

knowledge and uses procedure calls to interface to a PRIME ~EDUSA. The forward chaining inference strategy is used and the user-interface is based on the PRIME MEDUSA tablet. The current prototype is written in PROLOG and has been loosely interfaced to the CAD/CAM package and can select limits from the IS0 standard (BS4500) and place them and textual information on the selected dimension on the drawing. The initial EX-TOLD prototype was written in PROSE [9], a rule-based expert system shell. Although it was ideal for testing the interface with Medusa is proved inadequate to handle a complex problem of tolerancing. In essence PROSE uses its rules to animate text in the form of a decision tree with basic explanation and control facilities. However, the knowledge in the system was not represented using flexible and rich data structures to capture aspects of tolerance in an intelligent fashion. There is only one level at which the domain knowledge is represented in the system, that of rules. It was therefore not possible to explore low level details of knowledge, that is the objects (entities) which make up the rules, or higher level organization, that of rules clustered into identifiable tasks. EX-TOLD merely produced advice but was not capable of executing it. For this reason it was decided to develop TESSA

(Tolerance Expert System for Speci&ation and Analysis) using a comprehensive expert system support environment, developed at the University of Surrey [S], thus enabling MSto have an executive system rather than the purely advisory capabilities of PROSE. The discussions held with designers and draughtsmen have enabled us to identify the major tolerancing tasks and to formulate them into a hierarchical structure (see Fig. 3). This tree, when ‘walked through’, presents the user with a menu of options for each of the subtasks; for example, when specifying a tolerance the choice of linear, general and geometric will be presented. Each terminal node in the network is a task that invokes the rules that solve the problems related to that task. Residing on top of the tolerancing network is an outer control loop of tasks (see Fig. 4). These perform housekeeping tasks such as: view details of the currently loaded assembly; updating database information on materials, etc.; define a new assembly/part hierarchy (as in Fig. 5); saving of new information added to the assembly during the toleranclng routine; loading existing assembly details. The prototype currently contains 140 rnles distributed over 58 tasks. The rules manipulate 19

1

Fig. 3. TESSA tolerancing task hierarchy.

ISOLATED SINGLE

147

Expert system for offshore structures

TOLERANCING

c

J

4

Fig. 4. TESSA control loop tasks.

ment such knowledge for subsequent incorporation into an expert system. Essentially, the knowledge engineer performs four major tasks in sequence. Firstly, to understand the scope of the system to be designed and to develop a working knowledge of the problem domain particularly by mastering the terminology of the domain. Secondly, to identify the sources of knowledge in the domain: textbooks, papers, informal memoranda and sympathetic human experts. Thirdly, to interact with the (human) expert for acquiring his or her ‘knowledge’ and, once acquired, to get the knowledge verified and validated. Finally, the knowledge engineer produces a paper knowledge base which comprises the transcripts of the interviews with the expert and a full description of the domain entities (tasks, rules and objects). The knowledge essential for solving problems of a given domain can be structured in a (problem-solving) task-oriented fashion. Each task is executed sequentially and in turn involves the use of

different objects. TESSA knowledge base also contains 14 tables [lo]. The experience of building TESSA confirmed our strategy [4] that expert systems for use in engineering require a task-oriented system which allows a clear description of problem-solving tasks and helps in structuring the knowledge base. 3. KNOWLEDGE

ACQUISITION

OR ELICITATION

The important characteristics of knowledge are that it is experiential, descriptive, qualitative, largely undocumented and constantly changing. There are certain domains where all these properties are found, and some where one or more are found. The lack of documentation, the fact that ‘experts carry knowledge in their heads’, together with all the other properties mentioned above, make it difficulty to have access to knowledge so that it can be used without the expert’s presence. Therefore, knowledge engineers have devised techniques to elicit and docu-

Problem-Solving

Tasks

Task number

Rule number

Objects

1

1

2

2

3

3

4

5

6

1

3

6

Fig. 5. Task-oriented, problem-solving approach. CAS 40/I-K

K. AHMADer al.

148

IF.. . THEN type constructs-rules and rules of thumb. These rules test and manipulate a number of abstract and physical entities of the domain-~ferred to as domain objects. Note that tasks may refer to the same ru1es-e.g. tasks 1 and 3 in Fig. 5 both require execution of rules 1 and 3. As mentioned above, the knowledge engineer has to interview the expert for eliciting (a variety of) domain-specific and problem-solving knowledge. A number of interviewing techniques have been developed, and reported in the literature, see for instance Greenwell [I 11. Each technique emphasizes either the domain-specific or the problem-solving knowledge. In the following we discuss three inte~iewing techniques: focussed interview, ‘think-aloud protocols and the structured interview. The techniques help to obtain the genera1 knowledge of a domain; identify problem-solving tasks and rules governing these tasks; and design the computational structure of the domain objects. Each technique is described in terms of what it can help to achieve, what kind of questions and cues the knowledge engineer uses and what are the expected outcomes of the application of each of the techniques. 3.1. ~owledge

sources

A total of three knowledge e~ci~tion inte~iews were conducted during the first phase of the PLAIM project, lasting over 5 hr with experts on the various topics (see Table 2) using primarily the ‘think-aloud protocols and the focussed interview techniques. Structured interviews were not conducted per se but were very much a part of the (rapid-prototyping) evolutionary type development of the PLAIM prototype. All but one of the interviews were recorded using a video-cassette recorder; al1 were transcribed and, where considered useful, the transcripts were sent to, or discussed with, the (expert) interviewee. 3.2. The ove~iew inte~iew: the use of the focused interview technique with the principal domain expert

This is aimed at familiarizing the knowledge engineer with the domain and the particular problem which the expert system has to solve. This familiarization operation requires the collation and the under-

standing of the technical terminology of the domain before the interview and the revision of terminology ash-inte~iew. In order to conduct the focus& interview, the knowledge engineer prepares a list of questions aimed at obtaining the general knowledge of the domain essential to establish an overview. It is important to avoid detailed and specific answers. Focussed interviews are conducted almost as the first stage of the knowledge elicitation exercise, only preceded by the consultation of domain text books etc. by the knowledge engineer. The knowledge engineer controls the course of the interview and should expect the expert to reply reactively. The principal outcome of the focussed interviews is the domain terminology and a list of (problemsolving) tasks and their associated subtasks together with a brief description of the salient domain objects. The interviewee, the PLAIM project manager was videotaped and a transcript of his interview was produced. The interview began with a discussion of a ‘flow chart’ for conducting fatigue analysis of offshore structures (Fig. 6). The interviewer, who had already access to a variety of documents related to PLAIM, asked the expert to explain the flow chart. This led to the follo~n~ set of well focussed questions. Please outline algorithms, data input and output, data requirements. What happens to the results of the analysis of algorithms and models? What sort of knowledge and expertise is expected to be included in this prototype? Please give your view on judgements on accuracy and calibration with real data. How do you tell from residual strength and reliability index the lifetime of the structure or cracked joint? i.e. how long before the crack causes failure? In relation to the Jraw diagram, what is current practice and who currently carries out each of the jobs? What is the expertise involved?

Table 2. Expert sources Subjects covered

Interviewee

Interview technique

Overview and explanation of idea behind PLAIM. How an expert system is expected to fit in and what it was expected to do.

Focussed interview followed by structured interviews at prototype demonst~tions

R. W. Ebdon, Departmental Manager, AME Ltd

General intro to terminology, design practice, design for fatigue, classification of members nodes, joint types, construction pmCti@, welding and fabrication.

Think-aloud

Anonymous Senior Engineer, U.K. Offshore Operator

Current inspection, repair and maintenance practice-generally and specifically. Assessment of AME proposed approach to IRM. Opinion of where expert systems would be useful.

Think-aloud

Paul Friezel12, 131 Department AME Ltd

Manager,

149

Expert system for offshore structures

Fatigue Crack Growth Life Calculation I Elasllc Frame

Short term

I

D/b cracks in tenston 6 bendlng.

/

\ D/b materlals, toughness, Qmperature. pre-heat ‘/

I

INSPECT

I

I Nonlinear Frame Analysis

I Residual Strength I (_

1

Reliabilii

REPAIR

Index

STRATEGY

)

* Expert System Interface

1

Fig. 6. PLAIM (Phase 1). Fatigue life, residual strength and reliability calculations. *Expert system

interface. Who would be the target user of the prototype? What changes in data, apart from the loading conditions, should the user be interrogated on or should the system look for? Please suggest further information sources.

The result of the ‘focussed interview’

led to the identification of the broad scope of the project and in cataloguing important technical documentation (see Table 3). The preparation of the questionnaire for the interview helped the knowledge engineer to acquire

GRID SYSTEM Row5

Fig. 7.

K. AHMAOet al.

150

Table 3. Textual sources Name

Category

Knowledge content

Dynamics of Marine Structures, Report UR8, CIRIA, 1978

Tech. Report

Background, terminology and theory (analysis)

Design of Offshore Structures Den Norske Veritas, 1977

Code of Practice, Norway

In~oduction to fatigue and procedures

Recommended Practice for Planning, Designing and Constructing Fixed Offshore Platforms Am. Petrol Inst. RP2A, 17th Edn, 1987

Code of Practice, USA.

Wide view of design approach from U.S.A. point of view cursory reference to inspection, repair and maintenance

Introduction to the Welding of Structural Steelwork, Constrado, 1979

Tech. Design Guide

Introduction to welding and tetminology

Structural Design Brief (W. Ebdon, AME), 1984

Tech. Dot.

Fatigue analysis design approach and considerations

Design Premise Main jacket (W. Ebdon, AME), 1984

Tech. Dot.

Overall jacket design approach and considerations

Fabrication Specification (W. Ebdon, AME), 1984

Tech. Dot.

Probabilistic Inspection Planning, P. L. Busby and P. Carr (Atkins Oil and Gas Engineering Ltd)

Research Paper

Background to welding specification certification, design and practice Strategy for new approach to inspection planning of welded joints

The detection and assessment of subsurface weld defects with respect to the structural integrity of Ninian Southern Platform, J. S, Mitchell and X. R. Fels, Chevron Petroleum (U.K.) Ltd.

Research Paper

important terminology of the domain. This terminology was refined and updated during and after the interview. The focussed interview transcripts were sent to the domain expert and appropriate corrections were incorporated. The transcripts effectively became the first draft of the Requirements Specification for the PLAIM expert system. This specification was refined with the help of the second domain expert (R. W. Ebdon, Advanced Mechanics and Engineering Ltd), who had hands-on experience of designing offshore struct~~s, The conduct of this interview, in a ‘thinkaloud’ fashion, is discussed below. 3.3. Think-aloud protocols: interview with the second domain expert This technique has its origins in cognitive psychology, where it was used by the psy~holo~st to study a given subject’s reasoning strategies with which he or she solves a problem. Knowledge engineers use this technique for similar reasons except their subjects are generally the domain experts. These protocols require that either the expert thinks aloud while solving a given problem or thinks aloud about a case study. We prefer the case study based approach because the end results are known and thereby act as a reference point. The knowledge engineer is helped by the expert in selecting a case study of ‘medium complexity’: very complex studies

Defect growth prediction techniques, Case study on weld access windows

will provide inconclusive results particularly for building an expert system and ‘simple’ case studies will only enable the knowledge engineer to elicit ‘knowledge’ to solve ‘trivial’ problems of the domain. The expert, of course, is the best person to identify a ‘medium’ complexity problem. ‘Think-aloud’ protocols are the second stage of knowledge elicitation preceded by focussed interviews, to obtain an overview of the domain, and succeeded by ‘structured interviews’ etc. aimed at gaining deeper insight into the structure and function of objects and rules etc. The principle outcome of the ‘think-aloud’ protocols is the exact delineation of problem-solving tasks and the elaboration of reasoning strategies used by the experts. This in turn helps to define the sequence and the structure of subtasks which help the experts, while they solve problems. The second expert was asked two very broad questions: first, to describe a typical oil rig and second to outline repair practices. His reply was divided into the following topic areas: 000 Major Components of a Typical Rig {Example 1) 063 Example 2-A Barge Launched Jacket 125 Fatigue Problem Areas 140 pile Sleeves 157 Nodes 170 Importance of Various Members in a Jacket 222 Scour Problems

Expert system for offshore structures 254 273 313 357

Anodes and Corrosion Protection Defects Fatigue Analysis: Procedure and Calculations Wave Data.

The numbers on the left are the videotape recorder tape counter number: the intention here is to show duration and also to indicate that these numbers can be used for cross-referencing. In the following we will discuss some of the topics discussed by our expert and we quantify this discussion in terms of the tasks, rules and domain objects elicited from an except of the transcript. 000 The jacket supports the topside fixing it securely to the sea-bed above the level of the highest waves likely to be encountered in the North Sea. Piles are driven through guides in the legs of the jacket into the bedrock to ensure the rig position is solid. As the jacket structure is a group of frames made up of tubular steel sections and linked together by other frames, a method of identifying individual members and nodes at which groups of members coincide is required. The convention used on engineering drawings to identify the frame structure in plan view at each level or staging is shown in Fig. 8. This particular jacket was lifted into place using a crane. 015 The isometric view (Fig. 8) of the same jacket shows in more detail aspects of the frame structure, the type of loading experienced and typical trouble spots. The increasing diameter of the leg is such that it is strong enough to be able to take the increasing axial load at the lower levels. When a wave hits the platform it causes an overturning moment which in turn causes an axial load in the leg. This is resisted by the piles, but in this example the eccentricity of the load due to the leg shape causes flexure in the short stubby diagonal braces and causes fatigue problems in their corresponding

increasing leg diameter

f5I

node joints. Other crossed-diagonal members also experience fatigue due to this sort of flexure but not to the same degree. Domain objects, The following domain objects were identified from the first five minutes of the interview. Counter No 000 rig or platform. topside part of platform. ceIIa_deck part of platform. jacket part of platform. sea-bed. PiI@ part of jacket attached-to (leg 1,2,3,4) . . B number-of-guides sleeve-type. pile-group part of jacket num~r-of-pill eccentricity. grid rows faces levelframe part of jacket. part of level-frame. member part-of-jacket part of leveL_frame type of (leg, brace, diagonal, ho~zontal . . . ) load-type (trans~~ation, wave. . . ) in-splash-zone (true or false) length (in metres) diameter (in mm) thickness (in mm) stiffeners (yes, no) weld (single-sided, doubl~d~) Rules. The following rules were elicited from the transcript. Counter No. 000 rule i If: jacket is barge launched; then: jacket will have extra structural members included purely for transportion and launching which become redundant once it is placed on the sea-bed; because: it is a big structure and two different types of loading conditions need to be designed for if it is not going to fail for either.

Isometric view of the jacket. T’hecircled nodes are typical fatigue problem areas for this type of platform.

Fig. 8.

rule 2 if: a wave strikes the jacket; then: the diagonal members will take the load/shear force;

152

K. AHMAD et al.

because: the wave causes an overturning moment which will effectively tension one side of the jacket and compress the other side. In resisting this movement the diagonals take much of the load. More rules of the above type are shown in Appendix A. Corrections to the transcripts. The interview transcript was sent to the expert for comments and criticisms. It is not easy to classify the comments, except that the expert inserted contraints on his statements or expanded on others. Some examples below are presented to highlight the point we have just made. The expert’s amendments are in italics. 000 Major components of a typical rig (Example 1) Figure 7 shows the topside, consisting of the cellar deck to support the drilling rigs, accommodation module, helideck etc. Also shown is the flare boom and other crane booms. The jacket supports the topside fixing it securely to the sea-bed above the level of the highest waves likely to be encountered in the North Sea at the site. Piles are driven through guides attached to the legs of the jacket into the sea-bed to ensure the rig position is solid. 063 Example 2A barge launched jacket The main feature is two ‘legs’ and truss framework specifically employed for transportation to and launching from the barge. Once in place on the sea bed these trusses play little part in bearing any load. The outer legs support the majority of the vertical load with launch legs transferring load out from the central bays to the corner legs. 125 Fatigue problem areas

The diagram below shows the steelwork at level - 15 m: a plan view. The splash zone, a fatigue problem area, is approximately between - 3m to +6m for this platform but - 15m suffer from significant vertical wave loadings.

We believe that previously this knowledge was informal and undocumented; now it is available for inspection and verification. In the next section we discuss how we validated the knowledge collected so far by interviewing a third domain expert: the knowledge was not that of experts interviewed so far, but a ‘think-aloud’ session was conducted in which an independent expert gave his opinions about platform reliability. 3.4. Results of the knowledge elicitation exercise The above discussion shows that there is a considerable variety of knowledge which can be elicited from a number of sources. The think-aloud protocols are very effective in helping to identify domain objects and rules. The focussed interview was important in that it helped in establishing a rapport with the principal domain expert and formed the basis of his comments on the performance of the system. We have documented considerable amounts of knowl-

edge of this domain which was previously not available for comments or criticisms. It should be noted here that the rules of thumb and domain objects identified during the interviews cannot be incorporated directly into the knowledge base of the PLAIM expert system. The interviews and the transcripts form the basis of the knowledge base and also the basis of future discussion with the domain experts and also with other experts. We have found that the knowledge which could be useful to PLAIM has to be protected as commercially confidential information. Knowledge elicitation depends on experts giving their views free from commercial constraints and it is this problem which will become much more acute in the next phase of PLAIM development. The impression we have given above is that the three techniques are to be used in a sequence and that each elicits a particular kind of knowledge. As always the application of each of these techniques reveal overlaps with other techniques and also reveal shortcomings of the technique and that of the knowledge engineer. Therefore, the knowledge elicitation process is conducted in two phases: the initial phase when the engineer learns domain terminology; outlines scope of the problem and knowledge sources; specifies problem-solving tasks; and finally produces the paper knowledge base which includes the transcripts of the interviews. The subsequent phases involve the revision of domain terminology: constraints on the scope of the problem; verification of the tasks and objects; resulting in the validation of the (paper) knowledge base. The validation can again initiate the revise-constrain-verify-validate cycle.

4. KNOWLEDGE

REPRESENTATION REASONING

AND

We begin by defining the above terms in some detail. ‘Knowledge representation’ refers to the newly devel-

oped techniques of representing complex facts and descriptive rules using means other than those available to store simple data items. Once the representation problems are resolved and computational structures for representing the knowledge are tried and tested, the knowledge engineer builds the ‘knowledge base’ of an expert system. This is a repository of knowledge: facts, rules including rules of thumb (heuristics) and rules about rules (meta rules), and the information about various tasks is used to solve a particular class of problems. The ‘inference engine’ helps the expert system to deploy pre-stored items of knowledge: the correct term is ‘reasoning strategies’, inference being only one form of reasoning. We will now elaborate on aspects of representation, particularly tasks, rules and objects, and illustrate the discussion by drawing from examples in PLAIM.

Expert system for offshore structures

153

4.1. Problem -solving tasks

test-database

Tasks are facilities with which to describe the natural structure of a problem and to control the functioning of the system. Rule sets are attached to tasks so that they are only considered when a task is executed. The type of inferencing mechanism, of which there are several variations on the standard forward and backward engines, can be specified for each task. Once the task has been completed it will try the next task or tasks depending on the contents of its special list of successors. The list may be conjunctions or disjunctions of tasks but not a mixture of the two.

) else say with text of [‘>>The crack has been classified as minor’nl, ’ >>Continuing to recommend actions task’,nl,nl]

task with name of introduction and description of PLAIM Prototype Expert System for Defect Detection and Management UoS and AME Ltd. and entry-action of (There is a fatigue-crack also case-study with status or recordingcurrent-problem )’ and exit-action of (prompt-user with text of’ Press(Return) . . .’ and default of”) and successor of get-defect-details. Task with complex successor expression. This task attempts to classify the defect/crack using experiential knowledge; for example, location on the platform, extent of defect on the member, etc.

task with name of intuitive_crack_classification and description of Intuitive Crack Classification

). 4.2. Rules and rules of thumb Rules are the most common knowledge represenThey follow the standard tation structure. ‘if...then...’ structure. The main purpose of rules is to test, modify or deduce the values of the properties and relationships of the concepts to which it refers. rule with name of where-on-member and part of get-defect-details and body of ( if There is a fatigue-crack with located-on-platform of P and location_on_member_or_node of member and located_onmember of NAME and where-on-member of ATPOS then say with text of [‘>>Crack is’,ATPOS,nl,nl] ). 4.3. Domain objects Objects represent both the physical and abstract entities of the domain. The objects in the PLAIM domain are basically everything about and associated with a typical oil platform that has a bearing or an effect on a potential or recognized defect and to set up the background information which may be required: for example, Physical Objects: platform, topside, cellar-deck, fatigue crack. Abstract Objects: joints teat, shear loading. Explanation of how a jacket is described in PLAN.

and part of empirical-assessment and successor of

( if There is a fatigue-crack with (rating of severe or rating of serious) also X is a case-study then schedule-task with name of check-case_ study-database else

( if There is a fatigue-crack with (rating of severe or rating of serious) also not (X is a case-study) also say with text of [‘>>There are no case studies in the database.‘,nl, ‘>>Will try matching using Joint Database’,nl,nl] then schedule-task with name of check_joint_

Basically, the jacket is made up of members and nodes. Nodes are the structural element at the intersection point of two or more members. Therefore, members are the structural element linking the nodes together. Members can be of many kinds, e.g. horizontal brace, diagonal brace, conductor frame element, etc.; therefore, a property has been defined which can be used to define a members’ type. Legs are an important element of the jacket and may need to be reasoned about as a whole; therefore, members can be grouped to form a leg if they are of the type ‘leg-element’. Members have the properties length, diameter, thickness, material and also x, y and z coordinates to define where they are in space in relation to some datum. Nodes hold information about the position at which they occur in relation to other nodes in the jacket, e.g. level and grid row or column. They can

154

K. hiMAD

be subdivided further into chords and stubs as these are usually pre-fabricated structures allowing easy positioning and securing of the members in the jacket. A chord is usually the larger, thicker or more important member’s attachment point, e.g. the main leg, and the stubs are the attachment points of the minor members, e.g. braces. Both chords and stubs hold the information about which members they are attached to and the node of which they are a part. Therefore, an example jacket can be built up fairly easily, although it is a time consuming activity as there are many members and nodes in a typical structure, and gathering all the relevant values for the propertiesindeed distinguishing between them-will be an unavoidably long process without some automation. If connectivity can be inferred from a name then this may speed up the process. A simple system of nomenclature was devised for the PLAIM system where nodes are named according to their position and level in the grid that defines the plan and section views of the platform, e.g. a node on column 1, row A and at level 10 is named as ‘lAl0’ and a leg attached to this node (via a chord) from above will have the name ‘leglAl0’ as it is pointing to level 10. (The leg below will have the name ‘leglA20’ if the next level is at 20 m below sea level. NB levels are treated as positive below sea level for convenience.) Horizontal braces are named according to the level on the which they lie and in between which nodes they lie, e.g. a brace on level 10 between la10 and 2alO will be called ‘bracelo-lAdA’; a diagonal brace between two node will instead have the full node names, e.g. ‘brace1 AlO-lB10’. Careful naming is required. At some stage welded joint configurations existing at the nodes will need to be reasoned about and therefore an object definition describing how to link the stubs and chords in the different type of joint, e.g. K, T, K-T etc., will have to be created. This will be more relevant to finite element analysis but will also be useful in the joint test database tasks defined but not fully implemented in the current prototype. ‘Objects’ can also be classified as being generic entities or the specific instance of a particular class. In the early days of expert systems very little use was made of the generic-specific distinction which meant that all objects were on equal par and had to be stored, retrieved and maintained on an individual basis. This leads to considerable duplication of information and the attendant problems of errors, etc. Data structures currently used in expert systems and in PLAIM exploit the generic-specific distinction and related ‘objects’ can inherit properties: this helps in conserving information, avoids duplication and eases maintenance. One of the popular data structures is that of ‘frames’. Concepts are based on the frame schema and define the kinds of entities to be reasoned about in the application. Properties define the attributes that a

et al. concept can possess, including relationships. Relationships link together different types of concept, so that a ‘conductor’, for example, may be ‘part-of’ a ‘jacket’. Concepts linked in this way can also inherit properties if specified. Once the domain entities have been described then the existence of a real physical entity is represented by an instance of a concept, i.e. the property slots have values in them, for example: member with name of leg lb10 and member-type of leg-element and length of 8 and diameter of 2 and part of jktl. 4.4. PLAIM prototype implementation in MARVIN MARVIN is a frame-based system that can be used to augment PROLOG programs or as a programming system in its own right. MARVIN provide a rule-based expert system environment. There are three main levels of knowledge representation in MARVIN: objects, rules and tasks. Objects describe the entities or events about which a system is to reason-they describe the ‘what’. Rules describe how deductions about objects can be made, that is, given certain facts about objects it is valid to deduce further facts-they describe the ‘how’. Tasks describe the overall problem-solving strategy, what order things should be done and what rules are associated with solving a particular task-they describe the ‘when’. Typically, to construct a system in MARVIN one would specify: what tasks are required to perform the job; what rules are used in each task to solve the particular problem; and what objects will be manipulated by the rules. Hierarchies play an important role in MARVIN and can be found in tasks and objects. Tasks can be broken down into subtasks and objects can be classified into taxonomic structures. The illustrations used in Sec. 4 are in MARVIN programming syntax: a high-level English-like language. 5.

PLAIM: OPERATIONAL

FEATURES

We now discuss the salient features and the operational characteristics of each of the components of PLAIM, particularly with reference to the various abstractions used and tasks which comprise the problem-solving strategy of each of the components. 5.1. Task introduction This task introduces the user to the system and generates a fatigue crack object and a current case study object. A fatigue crack is generated because it is something that is not an integral part of a jacket structure but is a more transient entity. At the start of the consultation with PLAIM it is assumed that we

155

Expert system for offshore structures

Fig. 9a. Task hierarchy example.

j8245grs

)

(

e4568rd

)

inheritance

@iv88 “;“h’,;:;y

Fig. 9b. Object hierarchy example.

are dealing with a new problem each time. This is also the reason for generating a current case study object. 5.2. Task: get defect details

Empirical Assessment

Here basic information about the crack is gathered. Initially it is focussed on obtaining the precise location of the crack on the jacket structure. This is achieved by progressively ‘zooming in’ on the general information supplied. The user is asked whether the crack is on a node or on a member. After ~tab~~shing this fact the user is given a list of nodes or members to choose from. After this the position of the crack on the node or member, i.e. whether it is near or on a welded joint or an appurtenance, is requested. Levels and grid coordinates on the platform schematic are inherited from the structural element on which the defect resides. Details about the physical description of the defect, for example length, depth and form, are then requested so that characteristics such as aspect ratio and percentage extent can be calculated. 5.3. Task : empirics assemnennt

Fig. 10. Functional description of PLAIM.

This task provides the framework for an experience-based as~s~e~t of the severity of the defect.

156

K. .&MAD

The aim is to get a ‘ball park’ or ‘first pass’ estimate of the rate of defect growth before having to use (or instead of) complex finite element analysis methods. 5.3.1. Intuitive crack classification. A defect is classified on several aspects, most notably the importance of the member or node on which it is located, the extent of the defect and load zone in which it resides. For each of these aspects, depending on what their value is, a score or weighting is allocated and added to a total for the crack. Members have been classified by consequence of failure: leg elements are therefore the most important and conductor frame elements determined to be the least. An attempt has been made to categorize node types but this has not been verified or used in any great detail as yet. The more important the member the higher the score. Generally, the more crucial something is to the continued safe functioning of the platform the higher its score if it is in danger of failing, fracturing or becoming severed. The ‘extent’ of the crack deals with both through thickness and surface depth cracks and is concerned with how far around the footprint of the member or node the crack extends. For example, if it is through thickness but less than 10% of the way around the footprint the member will have more load bearing capacity than if it was 70% extent. Therefore, the weighting would be higher for the higher extent value. The aspect ratio and depth ratio are further qualifiers of extent and are used in the same way. Load zones are a way of classifying members further in relation to their local environmental loading. For simplicity, a platform is divided into three regions: upper, lower and splash zones. Fatigue loads are greatest in the splash zone members and least in the lower zone. Details of platform design may well feature this but the general case is the emphasis here-further rules can handle the individual variations. The final weighting is compared to score ranges (arbitrarily constructed) to indicate the seriousness of the crack. This attempts to mimic the way an engineer might classify how serious a defect is. For example, crack is long, through thickness and near a leg element (part of a leg implying if it failed it would cause the whole leg to fail) etc. Explicit rules like the above would have to cover every combination. This approach allows some flexibility in that if new aspects were to be included a new rule is simply added with a relevant score instead of having to alter the complete rule set. 53.2. Check case study database. As was mentioned above, the idea of the prototype is to use existing informtion and experiential knowledge where possible to produce a quick first pass assessment of the problem defect. Finite element analysis is regarded as inappropriate at this stage. Part of the overall PLAIM strategy was intended to embody the storage of all information about platforms under the control of the operator of oil or gas company. It was thought natural that all information on inspections, defect

et al.

detection and subsequent management, monitoring and handling (marine growth, repair, etc.) would be encapsulated in a report of some sort and could be included in the database as a ‘case study’. The idea of this is that with many platforms under the control of an operator or consortium and some being of similar design in similar areas, new problems could be compared with those in past case studies and results extrapolated using the information from the best matching case study. (N.B. We are fully aware that the answers are very subjective for even very subtle differences will give rise to enormous variations. Therefore, these answers are used only as a guideline for further action, e.g. more accurate analysis.) Also, there may have been a problem on the same platform as the current problem that can be used. Basically, this section looks at the characteristics of the current problem like crack location, environment, season etc. and matches the case studies in the database to it. They score a point for each correct characteristic and the case study with the highest total, i.e. the best match, is chosen. Its total is compared with the maximum possible score and converted to a percentage to act as a ‘confidence value’ for the later calculations. If there are two or more with the same high score then the properties that deal with crack location are compared and the one with the closest location to the current problem is chosen. Failing that, the user is asked to choose which crack he or she wishes to continue with. Further to this approach, a database for joint test results was also deemed to be useful. If there are no suitable case studies that match the problem then the system looks in its database of joint test data and looks for an investigation carried out on a joint or node of the type on which the defect is located. These are assessed in the same way as for the case studiesby a weighting factor. The information can then be used for crack growth extrapolation. This is currently at the task level of development. If no joint test results are relevant then the system will use the crack classification information it has already obtained. The intention is not to predict a crack growth rate, but to indicate the seriousness of the problem and the need for more information to continue. 5.3.3. Extrapolate crack growth. Once the best match case study (or joint test) has been selected then its rate of growth is used to calculate a time to complete failure or severance of the member. The confidence factor is retained for output with these values as in indication of the reliability of the result. At the paper knowledge base stage there are several extensions proposed, taking into account the differences between the current problem and the chosen case study such as environment, date of detection, season, loading regime etc. These extensions can be used to adjust the rate of growth or time to failure to be more appropriate to the current problem. The time to failure could be altered to be ‘time to 90% extent’ rather than complete severance; customization to

157

Expert system for offshore structures

individual requirements ible.

in this respect is quite poss-

5.4. Task: recommended actions Once the time to failure value has been calculated it is checked against a range of values in a table of ‘stock’ advice which is output to the user’s terminal. Among the possible extensions to PLAIM taking into account defect and platform details, environment and loading conditions to construct a series of ‘symptomaction’ statements such as when to repair if the predicted time of failure is in the winter season but the inspection data was in the summer season and precisely what repairs to carry out. The confidence value is carried through to this stage to again indicate the ‘reliability’ of the recommendations.

Enter an option number -+ 1 >&rack located on Node la0 Now it needs to find the exact location of the crack. Near which joint of node la0 is the crack? 1. stub-to-brace-joint 2. stub_to_chordjoint 3. chordto-member-joint Enter an option number or quit + 2 On which element, attached to, or part of, node la0, is the crack? 1. Stub 2. Chord Enter an option number or quit-2 Near which stub is the crack? 1. laOj1 2. laOj2 Enter an option number + 1

6. PLAIhl PROTOTYPE: AN ANNOTATED INTFXACMON

The following is an annotated consultation with PLAIM. PLAIM output is in the small type face and the user responses are in bold type. The user is expected to prompt the system to start up which will result in the system welcoming the user as follows: PLAIM Prototype UoS and AME Ltd. Press (Return): After the title introduction the first task the prototype attempts is to determine the location of the problem defect, the crack. Defect Details Here we gather basic information about the crack platform, location, size etc. . . Data collection. On which platform is the crack? 1. 2. 3. 4.

Forties Forties Forties Forties

Alpha Beta Delta Gamma

Enter an option number + 1 ~Crack located on Platform Forties Alpha Where is the crack located? 1. Member 2. Node Enter an option number or quit --) 2 ~Crack located on a node

Knowing that the crack is on a node the system builds up a list of all the nodes it knows are attached to this platform and displays their name in a list of the user to choose the appropriate one. On which node is the crack? 1. la0 2. la10 3. la20

. ... 20. 2b40

>>Crack located on Chord la0 near Stub laOj1

Having located the crack position the prototype now gathers data on the physical characteristics of the defect. What is the form of the crack? 1. Intermittent-group-of-cracks 2. Single-crack Enter an option number or quit-2 >Xrack extent is single-crack What is the depth of the crack? 1. Through-thickness 2. Surface-depth 3. Unknown Enter an option number or quit -V 1 ~Crack depth is through-thickness What is the size of the crack from the inspection results? 0.5. >>Crack size is 0.5 >>Crack extent is 31% of footprint

Now PLAIM has enough information to assess the potential hazards caused by the defect. Empirical Assessment The crack is critical because it is through thickness depth. A full-blown analysis would take too long to carry out for this problem therefore we will carry out an Empirical Assessment using Case Study information held in a special database for just this purpose. An estimate of the crack growth time to fracture/severance will be made by comparing the aspect ratio, loading mode and time of year with their equivalent in the Case Studies. Using rules derived from knowledge elicitation meetings the crack is classified by a simple scoring mechanism. If a rule fires it adds to or subtracts from the

total score an amount matter of the rule.

determined

by the subject

Intuitive Crack Classification >Xrack weighting increased by 3 to 3 rule: extentweight >Xrack weighting increased by 4 to 7 rule: chorhbraceclass-weight4 >>Crack rating severe as weighting of 7 is greater than 5

1%

K. AHMAD et al.

The crack’s final total is cornPared to a table of scares which determine its severity. The higher the score the greater the severity.

loading regime etc., r~ommendations for further action are made and qualified using the confidence value predicted by the case study match score.

Case Study Database

Now the current problem details are compared with the case study entries in the database to see which is the best match. In the example shown all three case studies have the same match score. In addition, the precise location details are compared as this tends to be the crucial factor in believing later rate of defect growth calculations. None of them are a good match. Assess Matches in DB >>Case Study: case1 weighting check 1 >>Case Study: case2 weighting check1 >>Case Study: case3 weighting check1 >>Case Study: case1 location rule: loc_score2 z>Case Study: case2 location rule: lot-score2 x4ase Study: case3 location rule: lot-score2

increased by I to 1 rule: increased by 1 to 1 rule: increased by 1 to 1 rule: match rating is 17%match rating is 17%match rating is 17%-

Select Best Match in DB There are several case studies which match very closely on total score and crack location Which would you like to use to estimate crack growth? 1. Case1 2. Case2 3. Case3 Enter an option number1 >>Case Study: case1 selected as best match-by

the user

If none of the case studies can be distinguished from each other the user is requested to choose one with which the system can continue to make its estimations. Estimated Crack Growth ~Estimated rate of growth from easel is: 5 with a confidence of: 5% >>Initial estimate of time to failure is: 214.2 days with a confidence of: 5% The rate of growth from the chosen case study is used to estimate the rate of growth for the current problem and the confidence value if simply the comparison match score of the case study expressed as a percentage. The estimated time to failure if expressed in days by default.

Actions are ~mrnend~

on the basis of the ~~~n~

made in the previous task. >>RECOMMENDED

Leaving PLAIM

7. CONCLUSIONSAND

FUTURE OUTLOOK

7.1. Progress to date

The experience of building the PLAIM prototype clearly indicates that knowledge-based expert systems have a role to play in the assessment of platform lifetime for ins~tion and majntenance~ The major co~~butions of our work can be summarized as follows. (a) We have shown that knowledge of platform inspection and maintenance can be documented using Knowledge Acquisition techniques: this is of significant importance considering that offshore platform engineering has a fairly recent history, the subject is not well documented and requires a multi-disciplinary outlook. (b) We have shown that knowledge of the above mentioned domain can be represented by using an object-oriented rule-based schemata, and that the represented knowledge can be O~rationaIized using a task-based reasoning system. (c) The system currently has over 100 rules and is ready for demonstration and testing. 1.2. Future outlook The following are our recommendations for the future development of the current prototype. (i) There is an urgent need to provide a better user interface to the systems: we recommend a window-based system and more reliance on pointing devices rather than keyboard-o~e~t~ operation. The user interface requires 1 man-year of effort. (ii) The system can be released for field trials provided it has about 100 tasks comprising c. 1000 rules. On current performance this will require 2 man-years effort. (iii) More access is needed to experts in this field: the work is of vital importance to the European offshore operators and now is the time for them to take a more pro-active

role.

Acknowledgement-Part of the funding for the PLAIM project has been provided by the Co~i~ion of the European Communiti~, ~r~ora~~nerai for Energy, Technological Development Projects in the Hydrocarbons Sector, under Contract No. TH. 03.2SSjSS.

ACTION(S):

monitor defect and check result by detailed analysis with a confidence of: 5%

REFERENCES

Holmes-H&in, MARVIN Expert System Tool User Guide. Internal Document, CITRUS, University Surrey (1988).

1. P. R.

Taking into account the estimated rate of growth, time to failure difference in seasons, environment,

Expert system for offshore structures 2. A. J. Langdon and K. Ahmad, PLAIM: The Expert Systems Sub-project--Final Report. Advanced Mechanics and CITRUS, Guildford, Surrey (1989). 3. D. A. Waterman, A Guide to Expert System Research. Addison-Wesley, Reading, MA (1986). 4. K. Ahmad, P. Holmes-H&in, C. Homsby and A. Langdon, Expert systems for planning and controlling physical networks in the water industry. Knowledgebased Systems 153-165 (1988). 5. C. Homsby, P. Holmes-H&gin and K. Ahmad, The water industry expert system support environment. In Research

and Developments

in Expert

Systems

IV

(Edited by D. S. Moralee), Research and Development in Expert Systems, pp. 276-286. Cambridge University Press, Cambridge (1987). 6. J. S. Bennet and R. S. Englemore, Experience using EMYCIN. In Rule-based Expert Systems-The MYCIN Exueriments of the Stanford Heuristic Programming Project (Edited by B. G. Buchanan and E. H.

Shortliffe), pp. 314-328. Addison-Wesley, Reading, MA (1985). 7. K. Ahmad and A. Macdonald, An expert system on tolerance in Mechanical Design. In Expert Systems for Advanced Manufacturing Technology, pp. 309-326. Engineering Society of Detroit and the U.S. Society of Machine Intelligence, Detroit (1987). 8. K. Ahmad and A. Macdonald, A knowledge based approach to tolerances in mechanical design. IEEE Workshop on Design Automation, Phoenix, AZ. 9. I. G. Wells and K. Ahmad, PROSE: An Expert System Shell for Strategies Declarative and Factual Knowledge Representation and Deployment. University of Surrey

10. 1I. 12.

13.

Technical Report IKBS 87.1, Guildford, Surrey (1987). A. Macdonald, A. J. Langdon and K. Ahmad, TESSA Status Report. IKBS Group, Computing Unit, University of Surrey, Guildford, Surrey (1988). M. Greenwell, Knowledge Engineering for Expert Systems. Ellis Horwood, Chichester (1988). P. A. Frieze, Some implications for offshore design code development of loading, strength and reliability modelling. In Integrity of Offshore Structure-3 (Edited by D. Faulkner, M. J. Cowling and A. Incecik), pp. 1699193. Elsevier, Amsterdam (1988). P. A. Frieze, Probability based assessment of existing and future offshore structures. Proc. 5th Int. Conf on Offshore Mechanics and Arctic Engineering

(OMAE).

ASME, The Hague (1989).

APPENDIX A: RULE EXTRACTION INTERVIEW TRANSCRImS

FROM

159

Transcript Analysis of PLAIM/KE/VT/Z Bill Ebdon (AME Ltd) Interview Rule Extraction A. J. Langdon uos Counter No 000 rule I if: jacket is barge launched;

then: jacket will have extra structural members included purely for transportation and launching which become redundant once it is placed on the sea-bed; because: it is a big structure and two different types of loading conditions need to be designed for if it is not going to fail for either. rule 2 if: a wave strikes the jacket; then: the diagonal members will take the load/shear force; because: the wave causes an overturning moment which will effectively tension one side of the jacket and compress the other side. In resisting this movement the diagonals take much of the load. rule 3

if: a jacket has sloping legs; then: any crossed diagonal members at the lowest level with flex and cause fatigue in their corresponding node joints; because: sloping legs will effectively give eccentric loading conditions. rule 4

if: a jacket has sloping legs; then: any crossed diagonal members not at the lowest level will flex and cause fatigue in their node joints but not to the same degree as those at the lowest level; because: eccentricity of loading exists but is not as marked as at the lower level. rule 5

if: a jacket has node joints made up of diagonal wave load carrying members; then: these nodes will be fatigue problem areas; because: either eccentricity and/or the way the wave load is transferred through the structure will cause flexure and stress the joints (see above rule explanations). rule 6

if: a jacket has conductor frames which are not centrally supported; then: the conductor frame will suffer fatigue problems; because: wave loading will cause the frame to flex thus straining the joints attaching it to the main structure. rule 7

The following is a set of rules obtained from a ‘thinkaloud’ protocol interview conducted with the second domain expert. The ‘counter number’ refers to the tape. counter number of the video recording of the interview (see Sec. 3.3). The 90 min interview yielded over 45 rules including rules of thumb.

if: a jacket is struck by a wave and the diagonal members are intact; then: the corresponding horizontal members will not take much load; because: the diagonals provide the principal resistance to the overturning moment caused by the wave.