- Email: [email protected]
Knowledge-base management system for mine design and evaluation
Engng Applic. Artif. Intell. Vol. 7, No. 4, pp. 415-425, 1994
Pergamon 0952-1976(94)00026-3
Copyright © 1994 Elsevier Science Ltd Printed in Great Britain. All rights reserved 0952-1976/94 $7.00 + 0.00
Contributed Paper
Knowledge-base Management System for Mine Design and Evaluation XIN HUANG McGill University, Montreal, Canada F. H A S S A N I McGill University, Montreal, Canada V. S. L A K S H M A N A N Concordia University, Montreal, Canada
(Received October 1993; in revised form April 1994) Traditional mining operation design is a multi-level data~information~knowledge intensive procedure. This paper presents a new approach to the efficient feasibility analysis of mining operations, based on a knowledge-base management system. Special attention is given to the design of the backfill mining operation and the main specifications involved. The basic techniques and concepts of the knowledgebase management system are discussed in the context of the Logical Date Language (LDL). In particular, the main issues of backfill design using L D L are illustrated by an example of a hydraulic transportation system design for a backfill operation. Finally, it was concluded that the knowledgebase management system is a useful tool to solve engineering problems like mine design, and the further extension of the technology to the full scope of the mining operation design is recommended. Keywords: Knowledge-base system application, artificial intelligence in mining.
1. INTRODUCTION Traditional mine design is a multi-level data/ information/knowledge-intensive procedure. A large amount of time and money is spent to bring a wide range of relevant data and knowledge together to support decision making, from the specification of the mining method, and stability estimates to quality control, and economic evaluation as well. The solution of most mining engineering problems requires, in addition to vast numerical calculations, substantial use of practical judgment and expertise based on experience.1 Generally speaking, the feasibility study of a particular project is based on general rules. The optimization issues, on the other hand, rely on such information and experience as the designers may have. So it would be more cost-effective to have a computer system that can: (1) Store knowledge about mine design, especially the previous experience of other, successfully designed mining operations; Correspondence should be sent to: Dr Xin Huang, Department of Mining and Metallurgy, McGill University, Montreal, Quebec, Canada H3A 2A7.
(2) Intelligently process knowledge and information related to certain design problems. Based on this information, designers can make decisions more efficiently and precisely. Various computer technologies have been proposed to improve the decision-making process, including expert systems, knowlege-base management systems, hypermedia systems, and object-oriented programming] In hypermedia database systems, the information or knowledge is stored and presented to users as passive data. The semantics of knowledge are generally ignored. The processing of knowledge is not addressed. Users are responsible for decision making. Therefore, a hypermedia database system provides only a partial solution. It is believed that certain knowledge included in the mine design rationale can be processed to support automated decision making for certain problems. The mining method selection expert system, for example, provides an automated approach to mining method selection. This paper presents another approach towards an efficient feasibility study of mining operations based on knowledge-base management system (KBMS) technology. Special attention is given to the
415
416
XIN HUANG et al,:
KNOWLEDGE-BASE MANAGEMENT SYSTEM User
UserInterface I Rulemanager I~
-•
Rul basee- I
,l
QueryprogramI [ R:Ethit°dg"' ! ~
=}TransfOnrmat~On I
Fig. 1. The architecture of the knowledge-base management system.
backfill mining operation design. The basic techniques and concepts of the knowledge-base management system are discussed in the context of the Logical Date Language (LDL). In particular, the main issues of backfill design using LDL are illustrated by an example of hydraulic transportation system design for a backfill operation. Finally, it is concluded that the knowledgebase management system is a useful tool to solve mine design problems, and it is recommended that the technology be further extended, to address the full scope of mining operation design. 2. THE BASIC CONCEPT OF A KNOWLEDGE-BASE SYSTEM The solution of problems in knowledge/dataintensive engineering applications depends on the characteristics of these problems which can be classified according to three attributes: (1) the completeness of the knowledge of data in the environment; (2) the accuracy of the knowledge or data available in the environment; and (3) the knowledge about the objective and/or specifications of the problem) Mine design is well defined, but is an inexact and incomplete data process. Heuristics must first be applied to find a restricted set of data/knowledge that can be used in
solving the problem. The knowledge-base management system approach is proposed here, to solve certain mine design problems. A knowledge-base management system is a programming system that has the capacities of both a database management system (DBMS) and a declarative language to serve the role played by a data manipulation language and host language. 4 A declarative language is a language in which one can express what one wants, without explaining exactly how the desired result is to be computed. A language that is not declarative is procedural (e.g. Pascal, C, Lisp). Like a DBMS, a KBMS supports efficient data access and manipulation. More than that, a KBMS provides expressive power by means of a declarative language based on logic, as has been successfully demonstrated in expert systems, production systems and logical programming languages. Figure i illustrates a primitive architecture of a KBMS. The combination of the database and a declarative language provides useful power for real applications, beyond that of a traditional DBMS and a logic rule system alone. The traditional database technology, relational databases for example, provides a limited capability to address inferences of reasonable complexity, transitive closure for instance. Therefore, the semantics of the knowledge about the application do-
XIN H U A N G et al.:
KNOWLEDGE-BASE MANAGEMENT SYSTEM
mains cannot be well understood or properly processed to provide meaningful solutions to end users. On the other hand, logical systems such as expert systems do provide the power of complex inference, but fail to address the need to manage and process data more extensive than the working memory. In most expert systems, domain knowledge has to be loaded to the working memory as a whole, or as a sequential file. No efficient secondary storage which is well supported by database technology is provided. The development of knowledge base management systems is aimed at addressing both these needs, and therefore provides a more-powerful expressive language for real applications. Over the last ten years, several models have been intensively investigated, J"8 concluding with a simple, powerful language, Datalog 9' 10which has led to the design and prototyping of the LDL knowledge base management system. The LDL system provides a declarative logic-based language and integrates the relational-database and logic-programming technologies so as to support advanced data- and knowledge-based applications. The LDL system is intended to develop the technology for a new generation of database systems that support the rapid development of sophisticated applications--such as expert systems and advanced scientific and engineering applications. 1~After about 10 years of research and development, the LDL sytem has been developed as an efficient and portable SALAD (System for Advanced Logical Application on Data), under the UNIX system. Shown in Fig. 2 is the conceptual architecture of the current LDL. There are six basic components or modules in the current system: (1) the user interface, (2) the fact manager, (3) the schema manager, (4) the rule manager, (5) the query form manager, and (6) the query manager. Since the underlying philosophy of LDL extends that of relational database systems, the facts are represented as relations. Above the facts, the rules are defined using Horn Clauses with limited extensions to allow function symbols and negation as part of the language. Meanwhile, the newly released version of LDL provides a convenient method of linking with external functions and relations, which has made possible the undertaking of massive numerical calculations. 12
User interface
]
Fig. 2. The conceptual architecture of LDL.
417
The LDL application programs consist of four components: (1) (2) (3) (4)
schema; data; rule set; query form.
Information about the schema, facts, rules and query forms is created and contained in ASCII text files, using any text editor. (1) A schema is a description of the stored data and its organization into stored facts. The schema specifies, among other things, the format in which the data is stored and the type of each constant. The schema itself is stored in a *.sch file. Complex terms are also defined within the schema, as shown later in the example. (2) The data consist of a set of facts. These facts must be consistent in structure and type with the relations declared in the schema and are stored in a *.fac file. (3) The rules component of the program contains a set of one or more rules that serve to define the derived predicates required for queries. Rules are stored in a *.rul file. (4) A query form is a generic query that specifies for the LDL compiler which of the arguments will be given and which are expected as output when a query of that type is issued. Query forms are stored in *.qf file. 3. KNOWLEDGE-BASE SYSTEM FOR MINE DESIGN Based on the power provided by LDL, certain mine design problems can be formalized and solved with the assistance of the knowledge-base management system. A formal representation of a hydraulic transportation system for a backfill design problem is presented next. The methodology and implementation are illustrated by the example of pump selection, which is a crucial decision facing backfill designers. 3.1. The general description of the design problems As an example, the hydraulic transportation system is taken for close analysis and implementation. Figure 3 illustrates the basic specifications and information flow concerned. One key issue in a hydraulic transportation system is the pump selection. As with most mining engineering problems, backfill design requires the substantial use of practical judgment and expertise, based on previous experience. Successfully designed mining operations are often used as a source of good examples, and certain decisions are made simply by drawing comparisons from one case to another. Since the conditions inherited for different deposits are never identical, an apparent drawback of this method is the burden
418
XIN HUANG et al.:
KNOWLEDGE-BASE MANAGEMENT SYSTEM
Solid concentration
~
~
k ~ hydraulic properties
' ~
~
~
transportation
t '
~
ru[''ps~c[~n
F
Hydraulic ransportation system and specification
~
( .....
~. Fill s i z e
distribution, fill properties, pipe size, productivity
(
\
Pressure lost
predict model or pressure lost test results
Fig. 3. The informationflowof hydraulictransportation systemdesign. of collecting related mining operations for comparison. Even though the general information is available, a close review of the information and a manual case-bycase analysis is also an expensive process. However, the knowledge-base management system approach provides the technology for efficient information storage and logic reasoning, and can be used as an automated or semi-automated tool for the decision making involved in backfill design. The following example uses L D L as a tool to implement a knowledge-based application requiring efficient access to a large collection of data related to hydraulic transportation system design in mining operations, which includes the following goals:
A statistical model of pressure loss is defined, in this context, as the average pressure loss previously presented in similar hydraulic transportation systems. Suppose that the information on previous hydraulic transportation operations is available and stored in the knowledge-base management system; the pump pressures applied previously can then be retrieved from the database to calculate the average pressure, and hence the pressure loss. The pressure losses predicted by both the analytical and statistical models may not agree with each other. If a conflict is encountered, a compromise pressure loss will be recommended. The details of the rules to define this domain knowledge will be given later.
(1) Provide quick access to similar mining operations for users. (2) Based on certain domain knowledge, the system can recommend some design options for users to verify. These are: (a) the pressure requirement justification; (b) pump recommendations; (c) economic overview of the mining project. (3) Provide certain procedural function calls to access a traditional language like C, for the numerical analysis which is important for the success of mine design.
3.2. Data representation A relational representation is essential in LDL. In the context of the relational representation, information is represented in terms of relations which consists of various attributes. Each relation groups together certain closely related information to represent a real-world object. Focusing specifically on the information needs of a hydraulic transportation system, the results of the modeling lead to a logical representation of information as relations. (Bear in mind that this modeling is intended to address the information needed only for the feasibility study.) Therefore, the data of interest may not be sufficient to address the other issues of backfill design, such as the detailed specification and the evaluation of backfill operation. Following the L D L conventions, relations and attributes have names. A relation name is represented as a lower-case string, and an attribute name is represented by a string starting with an upper-case letter. The formal representation of a relation is:
In particular, the implementation focuses on the issue of pump selection, which is crucial for a hydraulic transportation system. The key problem in determining the proper pump relies on the prediction of pressure loss along the pipe line when fill material is delivered. This is still an active research topic in hydraulic transportation. Several mathematical models have been proposed, with restrictions, and a loop test is almost inevitable. On the other hand, the practical operation of pumps is far from optimized. Previous experience may also lead to mistakes in pump selection. To overcome the unreliability of the pressure-loss prediction method mentioned above, this example proposes a multi-phase pressure-loss prediction model based on both analytical (empirical) pressure-loss prediction models and a statistical model of previous applications.
relation(Attributel, Attribute2, Attribute3 . . . . . AttributeN) Where "relation" is any name assigned to the relation, and Attribute 1, 2 . . . . . N are the names of the attributes. Each attribute belongs to a certain data type, such as real, integer, string, etc. Normally, relations and attributes are named in a self-explanatory fashion.
XIN HUANG et al.: KNOWLEDGE-BASEMANAGEMENTSYSTEM For example, the mine relation stands for a relation holding the information about the mine, which includes attributes such as "MinelD" for mine identification, "Production" for annual production of the mine, etc. A function symbol is presented as an upper-case string in LDL. Following the name of a function symbol are the arguements related to the function. The following information has been identified to be pertinent to the design of hydraulic transportation systems. In this specification, the relation is defined by a short description and a formal format. Following the definition is the type specification of each attribute. (1) pump relation: relation "pump" is defined to represent the information related to the real-world entity, pump. pump(Pumpid, Pumptype, Purpose, Capacity, Pressure, Manufacturer, Cost); Attributes (1) Pumpid (2) Pumptype (3) Purpose (4) Capacity (5) Pressure (6) Manufacturer
(7) Cost
Domain {string} {reciprocating, centrifugal} {string: water, slurry} {real: capacity of pump} {real: pressure of pump} {string: manufacturer ID} {real: cost of pump}
(7) (8) (9) (10) (11)
Fillid Dia Flow Pumpid Cost
419
{string: identity of backfill material} {real: pipe diameter} flow {real: flow velocity} {string: identity of pump} {real: cost of overall transportation operation}
(4) fill: relation "fill" is defined to represent the information related to certain fill material. It is intended to capture the information related to hydraulic transportation, rather than the mechanical properties. fill(Fillid, Filltype, Concent., Sgrav, Fgrav, Max, Avesize, Cratio, Cvelocity, Cost); Attributes (1) Fillid (2) Filltype (3) Concent (4) Sgrav. (5) Fgrav. (6) Max (7) Avesize (8) Cratio (9) Cvelocity (10) Cost
Domain {string: to identify backfill material} {string: Tailing, Sand, Rock} {real: backfill concentration} {real: slurry gravity} {real: dry material gravity} {real: maximum size of particle} {real: average size of fill material} {real: cement ratio; 0.0-1.0} {real: critical velocity} {real: cost of fill material per ton}
(2) manufacturer: relation "manufacturer" is defined to represent the information related to a manufacturer of pumps and other equipment.
(5) mine: relation "mine" is defined to represent the information related to mine operation, and captures the operating features of a mine.
manufacturer(Name, ADDRESS(City, State, Country, Telephone));
mine(Mineid, Production, Mineral, Method, Purpose, Rockcondition, Cost, Address);
Attributes (1) Name (2) ADDRESS(City, State, Country, Telephone)
Domain {string: name of manufacturer} {function symbol}
(3) transport: relation "transport" is defined to represent the information related to the hydraulic transportation system. It captures the operating features of the hydraulic transportation system, rather than its structure. transport(Tranid, Mineid, Type, Cap, LHratio, Height, Fillid, Dia, Flow, Pumpid, Cost); Attributes (1) Tranid (2) Mineid (3) Type (4) Capacity (5) LHratio (6) Height
Domain {string: transportation system identification} {string: mine identification} {string: hydraulic, pneumatic, conveyer, truck} {real: capacity of transportation system} {real: ratio of total length to vertical length} {real: vertical difference of transportation system}
Attributes (1) Mineid (2) Production (3) Mineral (4) Method (5) Purpose (6) Rockcondition (7) Cost (8) ADDRESS
Domain {string: to identify a mine} {real: annual production of a mine} {string: name of the major mineral} {string: mining method} {string: backfill purpose} {real: very stable, stable, good, poor, very poor} {real: cost of ore per tonne} {function symbol}
(6) modelfiil: relation "modelfill" is defined to represent information related to the classification of fill material. In essence, the fill material is classified by its pressure loss prediction model. The attribute Mfillid specifies the model to which the fill material belongs. The rest of the attributes specify the range that quantifies each fill material to fit a certain model. modeilill(Mfillid, Maxconcent, Minconcent, Maxsize, Minsize, Maxcratio, Mincratio); Attributes (1) MFillid
Domain {string: to identify backfill material model}
XIN HUANG et al.: KNOWLEDGE-BASEMANAGEMENTSYSTEM
420 (2) Maxconcent (3) Minconcent (4) Maxsize (5) Minsize (6) Maxcratio (7) Mincratio
{real: maximum solid concentration of slurry} {real: minimum solid concentration of slurry} {real: minimum size of particle} {real: minimum size of particle} {real: maximum cement ratio, 10.0-1.0%} (real: minimum cement ratio; 0.0-
1.0%} (7) costmodel: relation "costmodel" represents the information on a cost model of the real world. This relation captures the information needed to perform an evaluation based on that model. The attribute Rank stands for the rank classified for certain mining operations. It could be very good, good, acceptable, or unacceptable. The rest of the attributes stand for certain ranges that qualify certain backfill operations to belong to a rank. costmodel(Rank, Maslurry, Mislurry, Maxtran, Mintran, Masum, Minsum, Filltype); Attributes (I) Rank (2) Maslurry (3) Mislurry (4) Maxtran (5) Mintran (6) Masum (7) Minsum (8) Filltype
Domain {string: verygood, good, acceptable, poor, unacceptable} {real: maximum cost of slurry} {real: minimum cost of slurry} {real: maximum cost of slurry transportation} {real: minimum cost of slurry transportation} {real: maximum sum of backfill cost} {real: minimum sum of backfill cost} {string: fill type}
(8) ADDRESS: function symbol A D D R E S S is defined to represent the address of any organization. As an extension of Datalog, L D L allows the use of a function symbol as a term constructor of a complex term. It is not a relation. So the operations on A D D R E S S will be different from those on the relations.
ADDRESS(City: string, State: string, Country: string, Telephone: string) Attributes (1) City (2) State (3) Country (4) Telephone
Domain {string: name of city} {real: name of state} {string: name of country} {string: telephone number sented as string}
repre-
3.3 Definition of rules
Based on the relations defined above, the rule bases are defined by Horne Clauses to capture the logic features of the necessary information. The details of the rule implementation are accessible through the rule
file "mine.rul". In addition to the basic LDL facilities, some advanced techniques are also used, which will become clear in the following discussions.
(1) Definition of compatible mines' To be able to draw comparisons between different mines, three levels of similarity have to be defined: (1) very similar mine, (2) similar mine, and (3) compatible mine. The basic rules to define the three levels of similarity are: (A) If mines MINE1 and MINE2 have a 5% difference in production, and produce the same mineral using mining methods falling into the same category under the same rock conditions, then the two mines are considered very similar mines; (B) If mines MINEI and Z are very similar mines, and mines Z and MINE2 are very similar mines, then MINE1 and MINE2 are considered to be similar mines; (C) If mines MINE1 and Z are very similar mines and mines Z and MINE2 are similar mines, then MINE1 and MINE2 are considered to be compatible mines. These rules can be represented as the following Horn Clause by LDL syntax such as: (1) The predicate VerySimilarMine(Minel, MINE2) means that the mines MINE1 and MINE2 are very similar mines, defined by the following rules. Above the~--sign is the rule head (meaning the conclusion); the rest is the rule body (meaning the conjunctive conditions that make the head true). VerySimilarMine(MINE1, MINE2) mine(MINE1, Prodl, Minl, Methodl,_, Rockl), mine(MINE2, Prod2, Min2, Method2,_, Rock2), abs(Prodl, Prod2, Pdeviation), Pdeviation < = 0.05, Pdeviation > = 0.0, Method 1 = Method2, Mint = Min2, Rock 1 = Rock2. MINE1 - = MINE2, where the - sign negates the built-in predicate = , and means "not equal". The underscore refers to the arguments not concerned in the rule. (2) Predicate SimilarMine(MINE1, MINE2) means that mine MINE1 and MINE2 are similar. This can be defined by the following rule: SimlarMine(MINE1, MINE2) mine(Mine2 . . . . . .
)
XIN HUANG et al.:
KNOWLEDGE-BASE MANAGEMENT SYSTEM
if(VerySimilarMine(MINE1,MINE2)then true else SimilarMine(MINE1,MINE2), VerySimilarMine(MINE1,Z), MINE1 - = MINE2). (3) Predicate CompatibleMine(MINE1, MINE2) means that mine MINEI and MINE2 are comparable in the sense that they can be compared to each other to draw conclusions for a feasibility study. This can be defined as follows:
....
421
....... //
/ ' Compatible Sim ar
/ /
CompatibleMine(MINE1, MINE2) <-===
mine(MINE2 . . . . . . . . . . . . ), if(VerySimilarMine(MINEl, MINE2) then true else if (SimilarMine(MINE1, Z) then true else (VerySimilarMine(MINE1, Z), SimilarMine(Z, MINE2), MINEI - = MINE2)). In defining the CompatibleMine, an advanced IF-THEN-ELSE operator provided by LDL is used to express certain procedural constructs. The external call "abs" to calculate the relative difference between two attributes, such as production, is implemented as an external function imported to the LDL, which is used as a built-in predicate. Figure 4 illustrates a graphic representation of the relationships defined by these rules:
(2) Definition of the similarity of backfill material Two levels of similarity are defined by the following rules: (A) If fill FILL1 and FILL2 have a 5% difference in concentration, fine particle and gravity, and belong to the same type of backfill, then the two fill materials are considered to be similar; (B) If fill FILL1 and Z are similar, and Z and FILL2 are similar, then FILL1 and FILL2 are considered to be compatible; Figure 5 is the graphic representation of relationship between fill material, as defined by the above rules.
v~s~ / i ~"\ \
~-:~
//Con"~lJble ;......-
"~'--J'~ "~ x,~,~, ;,~,~. ! ~ "~ )'~'~°" ~ ~r
~,(~-~
Not compatible with any other
mines inthe universeof discourse
Fig. 4. Graphic representation of the relationship between the mines defined by the rules.
Fig. 5. Graphic representation of the relationship between the fills defined by the rules.
(3) Definition of compatible transportation systems Three levels of similarity of transportation systems need to be defined, based on the following rules: (A) If transportation systems TRANS1 and TRANS2 have a 5% difference in capacity, L/H ratio (the ratio of total length to height of the pipe line), and pipe diameter, regardless of the fill material handled, then the two systems are considered to be relevant. (B) If systems TRANS1 and TRANS2 are relevant and designed for compatible mines, to handle compatible fill material, then the two transportation systems are considered to be similar. Notice that in this rule, the two transportation systems are considered to be similar, provided that the related mining operation and fill material are compatible, which takes into account both the mining operation and the fill material as a whole. (C) If the systems TRANS1 and Z are similar, and Z and TRANS2 are similar, then TRANS1 and TRANS2 are considered to be compatible transportation systems (see Fig. 6).
(4) Definition of pressure loss prediction model Every fill material belongs to a category based on a certain pressure loss prediction model. The rules to define the material category are the following: (A) If fill FILL1 and model fill of category MFill have a 5% difference in concentration, size range, and cement ratio with the same fill type, then FILL1 is considered to belong to the MFill category, with the same pressureloss prediction model PM; (B) If fills FILL1 and Z are similar fill materials with the same backfill type, and Z belongs to the MFill category, then FILL1 belongs to MFill as well. Figure 7 is the graphic representation of the relationships between the fill and the fill model, as defined by the rules. It is noticed that the above rules defining the fill model involve a recursive definition which is not
422
XIN HUANG et al.: KNOWLEDGE-BASEMANAGEMENTSYSTEM
reliable, to capture the similarity of the fill material theoretically. If the inference chain is too long, the similarity defined by the first rule will no longer exist. In practice, however, the fill materials do fall naturally into certain categories, with some exceptions. Most of the fill models inferred by the above rules will closely meet the characteristics defined by certain models. Meanwhile, the pressure calculations which follow will be justified by a statistical model, which will certainly eliminate the influence of the factors unreliably inferred by the rules. The techniques involved in these rules in cases 2, 3 and 4 are similar to case 1.
S a ~ [~g
/
,,
:~"~'~--~ IIf'If ] ~ [ .,- ISim, r
iII,
Belong
Belong -- . . . . . .
//
Similar
•:'Y'"' Simila
(5) Definition of pressure loss rule As mentioned earlier, the pressure requirement of a hydraulic system can be estimated in two different ways: (1) numerical calculation, which is not always valid, (2) previous experience, which is not always reliable. The rules given below will generate the pressure requirements using both methods, and will verify one against the other. (1) In this case, an external predicate is used in the program. In LDL, an external predicate can be any kind of procedural program implemented by a conventional language such as C, F O R T R A N , etc. In this case, external predicates are initially implemented as functions to calculate the pressure loss based on the analytical model. These functions are stand-alone programs, and are executable under any operating system. Once imported to LDL, they are understood as external predicates in the context of the Datalog language. In doing this, the procedural programming is seamlessly merged into the logical programming, thereby
\
_/ Similar Similar~
;
~
//
//
o+,0,0
iii/I
Fig. 7. Graphic representation of the "belong" relationship I L Level 1 deduction;...... I~level 2 deduction; ........ ~ level 3 deduction. extending the symbolic calculation power of the L D L system to handle complex numerical calculations. The following is an example: pressure(Transid, P) <____
transport(Transid . . . . . LHratio, Height,_, Fillid, Dia, Vel,_), fill(Fillid,_, Concent, Sgrave, Fgrave . . . . . . ), belong(Fillid, Mfill), Mfill = pl, ppl(Concent, Vel, Fgrave, Dia, Sgrave, LHratio, Height, P). In this rule, the pressure requirement of transportation system "Transid" is specified by P which is the result of calling an external predicate ppl. (2) As in case 1, some aggregation operations are implemented as external predicates to calculate the pressure requirement based on the previous experience, as in the following rule: relevantpressure(Transid, P) <___
.~
/
Similar
transporation(Trans2 . . . . . . . . . . . . . Pumpid2), compatibletransystem(Transid, Trans2), pump(Pumpid2 . . . . . . . P . . . . ),
which generates all the pressure requirements P (a set) specified in the compatible transportation system. Because the L D L does not provide the aggregation function to calculate the average, maximum, minimum of the P set directly, the P set is output to a file called "inp" through the input/output facilities provided by the LDL. Then the following rules can use the intermediate information to generate the needed calculation through another external function call, aggregation Fig. 6. Graphic representation of similar transportation systems (inp, avg, max, min). defined by the rules.
XIN H U A N G et al.:
K N O W L E D G E - B A S E M A N A G E M E N T SYSTEM
(6) Definition of the qualified Pump rule In principle, the pump selected for the system should satisfy the following conditions: (1) the pressure of the selected pump must be greater than the pressure loss predicted; (2) the capacity of the pump should be greater than the capacity of the system; (3) the cost should be as low as possible; (4) the post-sales service for a reciprocating pump counts for about 5% of the total cost; (5) when slurry concentration is 75%, a reciprocal pump is the only choice. Based on these requirements, the pump selection rule could be expressed by rules with some external calls for numerical calculation, which turns out to be very efficient and powerful. The following is one of a group of rules defined to describe the qualifying pumps. By querying the database through the rules, several pumps might be presented as candidates. The users are allowed to make a choice based on the recommendation.
423
Then the file is executed using the shell command salad
7. Definition of cost estimation rules Because of the diversity of the mining operation, it is not feasible at the present time to adopt any universal cost model for backfill operations. Therefore, it is desirable to build up a regional cost model, based on statistical analysis. A province-wide survey of backfill operations has been conducted within the Quebec area and a Quebec regional backfill operation cost model has been established. In this model, the main contributions to the backfill cost come from the fill cost and the transportation cost, which account for about 85-90% of the total backfill cost. Accordingly, a backfill operation can be modelled by an average cost level in terms of statistics. Rules to estimate the cost levels are simply defined on the basis of the average cost level within the area. An operation can be estimated as a very good, good, acceptable, poor and unacceptable.
Qualifiedpump(Transl, PumpID) <..._
pump(PumpID, Type,_, Capacity, Pressure, , ), transporation(Trans2,_, Capacity2 . . . . . . . . . . . . . PumpID2), transportation(Transl . . . . . . . . . . . Filll . . . . ), pressure(Transl, Mp), Compatibletransystem(Transl, Trans2), aggregation(inp, Pavg, Pmax, Pmin), Pmin < Mp Mp < Pavg, Pumptype = 'centrifugal', MP = < pressure, pressure > = 1.05*MP, fill(Fill 1 ,_, Concent . . . . . . . _), Concent < = 0.75. Because this rule involves the external function call aggregation(inp, Pavg, Pmax, Pmin) which depends on the intermediate data file "inp", the query to qualifiedpump has to be performed in two steps: (1) generate "inp" file, (2) call the aggregation external function. The two-step query is completed by L D L scripts and piping techniques, using a redirection command. An L D L script file is an ASCII text file containing a collection of S A L A D commands, so several queries can be executed together to generate the desired results. The following is an example used to perform the aggregation (inp, Pavg, Pmax, Pmin) external call. First, a script file pressure.cmd has to be created as follows: ?relevantpressure(tranl, P) > mining.ldl/mining.cf.0/inp aggregation(inp, Pavg, Pmax, Pmin) exit
3.4. User interface
Above all of the discussions mentioned is the user interface, which is implemented as a stand-alone facility to access the defined queries. Figure 8 illustrates the basic functions implemented. The interface is menudriven, facilitated with help options. The main functions of the system are the following: Review: the option "Review" at the top level provides access to the database to review the previous applications from various perspectives. Users can access previous mining operations, transportation operations, and the characteristics of fill material as initially stored in the database. In addition, the query can access the rule-base first, and retrieve data based on a logic rule, as defined. For example, suppose a user wants to review other backfill operations closely related to his case, the submenu under the option "Mine" provides a "very similar mine" function to access the mining operations defined thus. The user may not be able to retrieve enough information about closely related mines. Then he may relinquish this condition, and try to look at the "similar" cases. As stated earlier, three levels of similarity have been defined by the rulebase. In the least favorable case, the user can refer to compatible mines for a solution. In this process, the users specify their requests, and inferencing and computation will take place automatically, directed by the system. Evaluation: the option "Evaluation" at the top-level menu provides an automated tool set to generate a cost report, and the technical adequacy of the pump's operation, if any. It serves as an entry to a submenu to evaluate hydraulic transportation system in terms of pump operation and overall economic performance.
424
XIN HUANGeta/.:
KNOWLEDGE-BASEMANAGEMENTSYSTEM
The option "cost evaluation" provides a function to evaluate the transportation operation, based on a regional model. In this case, a Quebec provincial regional model is applied. The /-elation "costmodel" and the cost estimation rules defined earlier will qualify certain hydraulic transportation systems into certain categories such as verygood, good, acceptable, poor and unacceptable. The option "pump evaluation" evaluates the pump's performance, based on both the analytical model and the statistical model of pump applications for certain transportation systems. The results of the evaluation are all pumps qualified for certain operations. If the actual operating pump of a transportation system is included in the recommended list, then the pump selected for that system is considered reasonable. Otherwise further investigation is recommended. Design: Finally, the option "Design" provides several data entry forms for specification. Under this option, backfill designers have a chance to access the "review" menu to retrieve information whenever it is needed. The major function implemented in this prototype system is the pump selection. The user inputs the basic information about the mine site, fill material, and layout of the transportation line as guided by the menu. At certain points, users have to determine whether a [
Mine
pump is needed to keep the system working safely, and if so, what the best choice is. The user should either specify an answer if he/she is certain of it, or else leave it for system to make a choice based on the inference rules defined. He/she is even allowed to specify randomly. The "evaluation" option will check whether the user specification is acceptable, and will recommend the best possible choice according to the knowledge available about the underlying system. 3.5. Performance of the system Since the LDL is implemented for the Unix operating system, the prototype of the hydraulic transportation design system works only in a UNIX environment. To test the usefulness of the system, sample data have been collected, with certain modifications based on the Quebec mining operation survey and a literature review. ~3 Sample data of 18 mining operations have been used for system testing. The original data do not provide all the information required by the conceptual model of hydraulic transportation. For example, most of the backfill operations in Quebec do not need pumps in their transportation systems. The horizontal extension is therefore extended proportionally so that the pump is apparently needed and the evaluation of pump operation is necessary. Other data are modified to draw 1~
[ Transport
[~
[
]"~--
Fill
Review
]~
] Cost report ] ~ ] Cost evaluation
[~ Pressure
[ Pump evaluation
[ ~-~
[ Evaluation ] ~ iV
[
Help
]~
Help
1-'~
7"
[~
Design
1~ t~
input form ] ~ ]
Quit
Help
]~ Review
]~ [
Quit
Evaluation ' ] ~
[
Quit
I--4--
Fig. 8. Thc basic functions of the system.
]~
XIN HUANG et al.: KNOWLEDGE-BASE MANAGEMENT SYSTEM the correlations a m o n g the different mining operations. The experimental tests displayed sensible results, and all outcomes m a k e perfect sense, as expected. The p u m p s r e c o m m e n d e d by the system closely agreed with the manual predictions in 86% of the cases. The remaining 14% of the recommendations could not be justified by the system, because of the incompleteness of the knowledge. The basic objectives of the project were fully achieved.
4. CONCLUSIONS AND FUTURE WORK Mine design is a data-intensive and time-consuming procedure. K B M S is providing the capability to greatly increase the efficiency of information process and analysis. This p a p e r presents the basic concepts of the KBMS, and its possible application in mine design. In particular, the L D L deductive database system is proposed as the basic machinery to implement a rule-based application for backfill design. As an example, the hydraulic transportation system was chosen for close analysis. A formal representation of the application of the knowledge base system is fully presented, within the L D L paradigm. Finally, the prototyping of the p u m p selection knowledge-base system was implemented, and its main features demonstrated. There is still considerable work to be done before the knowledge-base m a n a g e m e n t system can be fully applied to mine design. The collection of real operational knowledge at the centre of the application, and this is by no means an easy task. Expansion of the application to the full scope of backfill design is another issue worth exploring, which needs a profound under-
425
standing of the backfill design rationale. A complete specification of the functionality of the system requirements should be p e r f o r m e d prior to any further implementation. REFERENCES 1. Prasad K. et al. An assessment of expert system building tools for mining application. 21st APCOM Symposium, pp. 897-903 (1989). 2. Xin Huang and Hassani F. A new technological approach to backfill design. 94th Annual Meeting of the CIM, Montreal, Quebec (1992). 3. Ramamoorthy C. V. and Wah W. Knowledge and data engineering. IEEE Trans. Knowledge Data Engng 1, 9-16 (1989). 4. Ullman J. D. Principles of Database and Knowledge-base system, Vol. I, pp. 5-20. Computer Science Press, Rockville, Md (1988). 5. Gallaire H., Minker J. and Nicolas J. Logic and databases: a deductive approach. Comput. Surv. 16, 2, 23-29 (1984). 6. Ceri S., Gottiob G. and Tanca L. Logic Programming and Database, pp. 10-89. Springer, New York (1990). 7. Minker J. Perspectives in deductive database. Principles of Database Systems. Conference, San Diego, Calif., pp. 33-60 (1987). 8. Dik Lun Lee and Wenyu Lu. A framework for deductive database systems. IEEE Region 10 Conference on Computer and Communications Systems, Hong Kong, pp. 801-805 (1990). 9. Ceri S., Georg G. and Tanca L. What you always wanted to know about Datalog. IEEE Trans. Knowledge Data Engng 1, 146-166 (1989). 10. Danette C., Ruben G. and Ravi K. Towards an open architecture for LDL. Proceedings of the Fifteenth International Conference on Very Large Data Bases, Amsterdam, pp. 195-203 (1989). 11. Danette C. et aL The LDL system prototype. IEEE Trans. Knowledge Data Engng 2, 76-90 (1990). 12. Tsur S. et aL LDL User's Guide, pp. 33-41 (1991). 13. Hassani F. et al. Economic and technical feasibility for backfill design in Quebec underground mines. Internal report to the government of Quebec, Ministry of Energy and Resources (Mines), Mineral Research Centre (CRM) as well as the Canada Centre for Mineral and Energy Technology (CANMET) (1992).
AUTHORS' BIOGRAPHIES Xin Huang received his M.Sc and B.Sc in mining engineering in 1982 and 1985, China. After 2 year's study at Beijing University of Science and Technology as a Ph.D Candidate, Dr Huang was invited to The University of New South Wales, Sydney, Australia as a visiting scholar for 2 years. He received his Ph.D degree from the Department of Mining and Metallurgical Engineering, McGill University, Canada in 1994. His research interests focus on the application of computers in mine design, planning and operation. He is especially interested in data/knowledge intensive applications such as hypermedia systems, database systems, knowledge-base management systems, and expert systems. F. P. Hassani received a B.Sc. (honours) in mining engineering and a Ph.D. in rock mechanics from the Department of Mining Engineering, Nottingham University, England, in 1975 and 1981, respectively. Dr Hassani has worked in the mining industry in the Middle East, Europe and North America, and was technical director of Ray Mining Company. He has been involved in mining engineering research and development for the past 15 years. In 1983, he joined the Department of Mining and Metallurgical Engineering at McGill University, where he is currently director of its mining program. V. S. Lakshmanan obtained his Ph.D. in computer science at the Indian Institute of Science, Bangalore, India, in 1987. He was a postdoctoral fellow at the University of Toronto from 1987 to 1989. Since 1989 he has been an Assistant Professor of Computer Science at Concordia University, Montreal. He has published several articles in international conferences and jounrls. His research interests include database and knowledge-based systems, and their applications. He is currently directing several research projects aimed at extending the Deductive Database technology for supporting next-generation applications.
Pergamon 0952-1976(94)00026-3
Copyright © 1994 Elsevier Science Ltd Printed in Great Britain. All rights reserved 0952-1976/94 $7.00 + 0.00
Contributed Paper
Knowledge-base Management System for Mine Design and Evaluation XIN HUANG McGill University, Montreal, Canada F. H A S S A N I McGill University, Montreal, Canada V. S. L A K S H M A N A N Concordia University, Montreal, Canada
(Received October 1993; in revised form April 1994) Traditional mining operation design is a multi-level data~information~knowledge intensive procedure. This paper presents a new approach to the efficient feasibility analysis of mining operations, based on a knowledge-base management system. Special attention is given to the design of the backfill mining operation and the main specifications involved. The basic techniques and concepts of the knowledgebase management system are discussed in the context of the Logical Date Language (LDL). In particular, the main issues of backfill design using L D L are illustrated by an example of a hydraulic transportation system design for a backfill operation. Finally, it was concluded that the knowledgebase management system is a useful tool to solve engineering problems like mine design, and the further extension of the technology to the full scope of the mining operation design is recommended. Keywords: Knowledge-base system application, artificial intelligence in mining.
1. INTRODUCTION Traditional mine design is a multi-level data/ information/knowledge-intensive procedure. A large amount of time and money is spent to bring a wide range of relevant data and knowledge together to support decision making, from the specification of the mining method, and stability estimates to quality control, and economic evaluation as well. The solution of most mining engineering problems requires, in addition to vast numerical calculations, substantial use of practical judgment and expertise based on experience.1 Generally speaking, the feasibility study of a particular project is based on general rules. The optimization issues, on the other hand, rely on such information and experience as the designers may have. So it would be more cost-effective to have a computer system that can: (1) Store knowledge about mine design, especially the previous experience of other, successfully designed mining operations; Correspondence should be sent to: Dr Xin Huang, Department of Mining and Metallurgy, McGill University, Montreal, Quebec, Canada H3A 2A7.
(2) Intelligently process knowledge and information related to certain design problems. Based on this information, designers can make decisions more efficiently and precisely. Various computer technologies have been proposed to improve the decision-making process, including expert systems, knowlege-base management systems, hypermedia systems, and object-oriented programming] In hypermedia database systems, the information or knowledge is stored and presented to users as passive data. The semantics of knowledge are generally ignored. The processing of knowledge is not addressed. Users are responsible for decision making. Therefore, a hypermedia database system provides only a partial solution. It is believed that certain knowledge included in the mine design rationale can be processed to support automated decision making for certain problems. The mining method selection expert system, for example, provides an automated approach to mining method selection. This paper presents another approach towards an efficient feasibility study of mining operations based on knowledge-base management system (KBMS) technology. Special attention is given to the
415
416
XIN HUANG et al,:
KNOWLEDGE-BASE MANAGEMENT SYSTEM User
UserInterface I Rulemanager I~
-•
Rul basee- I
,l
QueryprogramI [ R:Ethit°dg"' ! ~
=}TransfOnrmat~On I
Fig. 1. The architecture of the knowledge-base management system.
backfill mining operation design. The basic techniques and concepts of the knowledge-base management system are discussed in the context of the Logical Date Language (LDL). In particular, the main issues of backfill design using LDL are illustrated by an example of hydraulic transportation system design for a backfill operation. Finally, it is concluded that the knowledgebase management system is a useful tool to solve mine design problems, and it is recommended that the technology be further extended, to address the full scope of mining operation design. 2. THE BASIC CONCEPT OF A KNOWLEDGE-BASE SYSTEM The solution of problems in knowledge/dataintensive engineering applications depends on the characteristics of these problems which can be classified according to three attributes: (1) the completeness of the knowledge of data in the environment; (2) the accuracy of the knowledge or data available in the environment; and (3) the knowledge about the objective and/or specifications of the problem) Mine design is well defined, but is an inexact and incomplete data process. Heuristics must first be applied to find a restricted set of data/knowledge that can be used in
solving the problem. The knowledge-base management system approach is proposed here, to solve certain mine design problems. A knowledge-base management system is a programming system that has the capacities of both a database management system (DBMS) and a declarative language to serve the role played by a data manipulation language and host language. 4 A declarative language is a language in which one can express what one wants, without explaining exactly how the desired result is to be computed. A language that is not declarative is procedural (e.g. Pascal, C, Lisp). Like a DBMS, a KBMS supports efficient data access and manipulation. More than that, a KBMS provides expressive power by means of a declarative language based on logic, as has been successfully demonstrated in expert systems, production systems and logical programming languages. Figure i illustrates a primitive architecture of a KBMS. The combination of the database and a declarative language provides useful power for real applications, beyond that of a traditional DBMS and a logic rule system alone. The traditional database technology, relational databases for example, provides a limited capability to address inferences of reasonable complexity, transitive closure for instance. Therefore, the semantics of the knowledge about the application do-
XIN H U A N G et al.:
KNOWLEDGE-BASE MANAGEMENT SYSTEM
mains cannot be well understood or properly processed to provide meaningful solutions to end users. On the other hand, logical systems such as expert systems do provide the power of complex inference, but fail to address the need to manage and process data more extensive than the working memory. In most expert systems, domain knowledge has to be loaded to the working memory as a whole, or as a sequential file. No efficient secondary storage which is well supported by database technology is provided. The development of knowledge base management systems is aimed at addressing both these needs, and therefore provides a more-powerful expressive language for real applications. Over the last ten years, several models have been intensively investigated, J"8 concluding with a simple, powerful language, Datalog 9' 10which has led to the design and prototyping of the LDL knowledge base management system. The LDL system provides a declarative logic-based language and integrates the relational-database and logic-programming technologies so as to support advanced data- and knowledge-based applications. The LDL system is intended to develop the technology for a new generation of database systems that support the rapid development of sophisticated applications--such as expert systems and advanced scientific and engineering applications. 1~After about 10 years of research and development, the LDL sytem has been developed as an efficient and portable SALAD (System for Advanced Logical Application on Data), under the UNIX system. Shown in Fig. 2 is the conceptual architecture of the current LDL. There are six basic components or modules in the current system: (1) the user interface, (2) the fact manager, (3) the schema manager, (4) the rule manager, (5) the query form manager, and (6) the query manager. Since the underlying philosophy of LDL extends that of relational database systems, the facts are represented as relations. Above the facts, the rules are defined using Horn Clauses with limited extensions to allow function symbols and negation as part of the language. Meanwhile, the newly released version of LDL provides a convenient method of linking with external functions and relations, which has made possible the undertaking of massive numerical calculations. 12
User interface
]
Fig. 2. The conceptual architecture of LDL.
417
The LDL application programs consist of four components: (1) (2) (3) (4)
schema; data; rule set; query form.
Information about the schema, facts, rules and query forms is created and contained in ASCII text files, using any text editor. (1) A schema is a description of the stored data and its organization into stored facts. The schema specifies, among other things, the format in which the data is stored and the type of each constant. The schema itself is stored in a *.sch file. Complex terms are also defined within the schema, as shown later in the example. (2) The data consist of a set of facts. These facts must be consistent in structure and type with the relations declared in the schema and are stored in a *.fac file. (3) The rules component of the program contains a set of one or more rules that serve to define the derived predicates required for queries. Rules are stored in a *.rul file. (4) A query form is a generic query that specifies for the LDL compiler which of the arguments will be given and which are expected as output when a query of that type is issued. Query forms are stored in *.qf file. 3. KNOWLEDGE-BASE SYSTEM FOR MINE DESIGN Based on the power provided by LDL, certain mine design problems can be formalized and solved with the assistance of the knowledge-base management system. A formal representation of a hydraulic transportation system for a backfill design problem is presented next. The methodology and implementation are illustrated by the example of pump selection, which is a crucial decision facing backfill designers. 3.1. The general description of the design problems As an example, the hydraulic transportation system is taken for close analysis and implementation. Figure 3 illustrates the basic specifications and information flow concerned. One key issue in a hydraulic transportation system is the pump selection. As with most mining engineering problems, backfill design requires the substantial use of practical judgment and expertise, based on previous experience. Successfully designed mining operations are often used as a source of good examples, and certain decisions are made simply by drawing comparisons from one case to another. Since the conditions inherited for different deposits are never identical, an apparent drawback of this method is the burden
418
XIN HUANG et al.:
KNOWLEDGE-BASE MANAGEMENT SYSTEM
Solid concentration
~
~
k ~ hydraulic properties
' ~
~
~
transportation
t '
~
ru[''ps~c[~n
F
Hydraulic ransportation system and specification
~
( .....
~. Fill s i z e
distribution, fill properties, pipe size, productivity
(
\
Pressure lost
predict model or pressure lost test results
Fig. 3. The informationflowof hydraulictransportation systemdesign. of collecting related mining operations for comparison. Even though the general information is available, a close review of the information and a manual case-bycase analysis is also an expensive process. However, the knowledge-base management system approach provides the technology for efficient information storage and logic reasoning, and can be used as an automated or semi-automated tool for the decision making involved in backfill design. The following example uses L D L as a tool to implement a knowledge-based application requiring efficient access to a large collection of data related to hydraulic transportation system design in mining operations, which includes the following goals:
A statistical model of pressure loss is defined, in this context, as the average pressure loss previously presented in similar hydraulic transportation systems. Suppose that the information on previous hydraulic transportation operations is available and stored in the knowledge-base management system; the pump pressures applied previously can then be retrieved from the database to calculate the average pressure, and hence the pressure loss. The pressure losses predicted by both the analytical and statistical models may not agree with each other. If a conflict is encountered, a compromise pressure loss will be recommended. The details of the rules to define this domain knowledge will be given later.
(1) Provide quick access to similar mining operations for users. (2) Based on certain domain knowledge, the system can recommend some design options for users to verify. These are: (a) the pressure requirement justification; (b) pump recommendations; (c) economic overview of the mining project. (3) Provide certain procedural function calls to access a traditional language like C, for the numerical analysis which is important for the success of mine design.
3.2. Data representation A relational representation is essential in LDL. In the context of the relational representation, information is represented in terms of relations which consists of various attributes. Each relation groups together certain closely related information to represent a real-world object. Focusing specifically on the information needs of a hydraulic transportation system, the results of the modeling lead to a logical representation of information as relations. (Bear in mind that this modeling is intended to address the information needed only for the feasibility study.) Therefore, the data of interest may not be sufficient to address the other issues of backfill design, such as the detailed specification and the evaluation of backfill operation. Following the L D L conventions, relations and attributes have names. A relation name is represented as a lower-case string, and an attribute name is represented by a string starting with an upper-case letter. The formal representation of a relation is:
In particular, the implementation focuses on the issue of pump selection, which is crucial for a hydraulic transportation system. The key problem in determining the proper pump relies on the prediction of pressure loss along the pipe line when fill material is delivered. This is still an active research topic in hydraulic transportation. Several mathematical models have been proposed, with restrictions, and a loop test is almost inevitable. On the other hand, the practical operation of pumps is far from optimized. Previous experience may also lead to mistakes in pump selection. To overcome the unreliability of the pressure-loss prediction method mentioned above, this example proposes a multi-phase pressure-loss prediction model based on both analytical (empirical) pressure-loss prediction models and a statistical model of previous applications.
relation(Attributel, Attribute2, Attribute3 . . . . . AttributeN) Where "relation" is any name assigned to the relation, and Attribute 1, 2 . . . . . N are the names of the attributes. Each attribute belongs to a certain data type, such as real, integer, string, etc. Normally, relations and attributes are named in a self-explanatory fashion.
XIN HUANG et al.: KNOWLEDGE-BASEMANAGEMENTSYSTEM For example, the mine relation stands for a relation holding the information about the mine, which includes attributes such as "MinelD" for mine identification, "Production" for annual production of the mine, etc. A function symbol is presented as an upper-case string in LDL. Following the name of a function symbol are the arguements related to the function. The following information has been identified to be pertinent to the design of hydraulic transportation systems. In this specification, the relation is defined by a short description and a formal format. Following the definition is the type specification of each attribute. (1) pump relation: relation "pump" is defined to represent the information related to the real-world entity, pump. pump(Pumpid, Pumptype, Purpose, Capacity, Pressure, Manufacturer, Cost); Attributes (1) Pumpid (2) Pumptype (3) Purpose (4) Capacity (5) Pressure (6) Manufacturer
(7) Cost
Domain {string} {reciprocating, centrifugal} {string: water, slurry} {real: capacity of pump} {real: pressure of pump} {string: manufacturer ID} {real: cost of pump}
(7) (8) (9) (10) (11)
Fillid Dia Flow Pumpid Cost
419
{string: identity of backfill material} {real: pipe diameter} flow {real: flow velocity} {string: identity of pump} {real: cost of overall transportation operation}
(4) fill: relation "fill" is defined to represent the information related to certain fill material. It is intended to capture the information related to hydraulic transportation, rather than the mechanical properties. fill(Fillid, Filltype, Concent., Sgrav, Fgrav, Max, Avesize, Cratio, Cvelocity, Cost); Attributes (1) Fillid (2) Filltype (3) Concent (4) Sgrav. (5) Fgrav. (6) Max (7) Avesize (8) Cratio (9) Cvelocity (10) Cost
Domain {string: to identify backfill material} {string: Tailing, Sand, Rock} {real: backfill concentration} {real: slurry gravity} {real: dry material gravity} {real: maximum size of particle} {real: average size of fill material} {real: cement ratio; 0.0-1.0} {real: critical velocity} {real: cost of fill material per ton}
(2) manufacturer: relation "manufacturer" is defined to represent the information related to a manufacturer of pumps and other equipment.
(5) mine: relation "mine" is defined to represent the information related to mine operation, and captures the operating features of a mine.
manufacturer(Name, ADDRESS(City, State, Country, Telephone));
mine(Mineid, Production, Mineral, Method, Purpose, Rockcondition, Cost, Address);
Attributes (1) Name (2) ADDRESS(City, State, Country, Telephone)
Domain {string: name of manufacturer} {function symbol}
(3) transport: relation "transport" is defined to represent the information related to the hydraulic transportation system. It captures the operating features of the hydraulic transportation system, rather than its structure. transport(Tranid, Mineid, Type, Cap, LHratio, Height, Fillid, Dia, Flow, Pumpid, Cost); Attributes (1) Tranid (2) Mineid (3) Type (4) Capacity (5) LHratio (6) Height
Domain {string: transportation system identification} {string: mine identification} {string: hydraulic, pneumatic, conveyer, truck} {real: capacity of transportation system} {real: ratio of total length to vertical length} {real: vertical difference of transportation system}
Attributes (1) Mineid (2) Production (3) Mineral (4) Method (5) Purpose (6) Rockcondition (7) Cost (8) ADDRESS
Domain {string: to identify a mine} {real: annual production of a mine} {string: name of the major mineral} {string: mining method} {string: backfill purpose} {real: very stable, stable, good, poor, very poor} {real: cost of ore per tonne} {function symbol}
(6) modelfiil: relation "modelfill" is defined to represent information related to the classification of fill material. In essence, the fill material is classified by its pressure loss prediction model. The attribute Mfillid specifies the model to which the fill material belongs. The rest of the attributes specify the range that quantifies each fill material to fit a certain model. modeilill(Mfillid, Maxconcent, Minconcent, Maxsize, Minsize, Maxcratio, Mincratio); Attributes (1) MFillid
Domain {string: to identify backfill material model}
XIN HUANG et al.: KNOWLEDGE-BASEMANAGEMENTSYSTEM
420 (2) Maxconcent (3) Minconcent (4) Maxsize (5) Minsize (6) Maxcratio (7) Mincratio
{real: maximum solid concentration of slurry} {real: minimum solid concentration of slurry} {real: minimum size of particle} {real: minimum size of particle} {real: maximum cement ratio, 10.0-1.0%} (real: minimum cement ratio; 0.0-
1.0%} (7) costmodel: relation "costmodel" represents the information on a cost model of the real world. This relation captures the information needed to perform an evaluation based on that model. The attribute Rank stands for the rank classified for certain mining operations. It could be very good, good, acceptable, or unacceptable. The rest of the attributes stand for certain ranges that qualify certain backfill operations to belong to a rank. costmodel(Rank, Maslurry, Mislurry, Maxtran, Mintran, Masum, Minsum, Filltype); Attributes (I) Rank (2) Maslurry (3) Mislurry (4) Maxtran (5) Mintran (6) Masum (7) Minsum (8) Filltype
Domain {string: verygood, good, acceptable, poor, unacceptable} {real: maximum cost of slurry} {real: minimum cost of slurry} {real: maximum cost of slurry transportation} {real: minimum cost of slurry transportation} {real: maximum sum of backfill cost} {real: minimum sum of backfill cost} {string: fill type}
(8) ADDRESS: function symbol A D D R E S S is defined to represent the address of any organization. As an extension of Datalog, L D L allows the use of a function symbol as a term constructor of a complex term. It is not a relation. So the operations on A D D R E S S will be different from those on the relations.
ADDRESS(City: string, State: string, Country: string, Telephone: string) Attributes (1) City (2) State (3) Country (4) Telephone
Domain {string: name of city} {real: name of state} {string: name of country} {string: telephone number sented as string}
repre-
3.3 Definition of rules
Based on the relations defined above, the rule bases are defined by Horne Clauses to capture the logic features of the necessary information. The details of the rule implementation are accessible through the rule
file "mine.rul". In addition to the basic LDL facilities, some advanced techniques are also used, which will become clear in the following discussions.
(1) Definition of compatible mines' To be able to draw comparisons between different mines, three levels of similarity have to be defined: (1) very similar mine, (2) similar mine, and (3) compatible mine. The basic rules to define the three levels of similarity are: (A) If mines MINE1 and MINE2 have a 5% difference in production, and produce the same mineral using mining methods falling into the same category under the same rock conditions, then the two mines are considered very similar mines; (B) If mines MINEI and Z are very similar mines, and mines Z and MINE2 are very similar mines, then MINE1 and MINE2 are considered to be similar mines; (C) If mines MINE1 and Z are very similar mines and mines Z and MINE2 are similar mines, then MINE1 and MINE2 are considered to be compatible mines. These rules can be represented as the following Horn Clause by LDL syntax such as: (1) The predicate VerySimilarMine(Minel, MINE2) means that the mines MINE1 and MINE2 are very similar mines, defined by the following rules. Above the~--sign is the rule head (meaning the conclusion); the rest is the rule body (meaning the conjunctive conditions that make the head true). VerySimilarMine(MINE1, MINE2) mine(MINE1, Prodl, Minl, Methodl,_, Rockl), mine(MINE2, Prod2, Min2, Method2,_, Rock2), abs(Prodl, Prod2, Pdeviation), Pdeviation < = 0.05, Pdeviation > = 0.0, Method 1 = Method2, Mint = Min2, Rock 1 = Rock2. MINE1 - = MINE2, where the - sign negates the built-in predicate = , and means "not equal". The underscore refers to the arguments not concerned in the rule. (2) Predicate SimilarMine(MINE1, MINE2) means that mine MINE1 and MINE2 are similar. This can be defined by the following rule: SimlarMine(MINE1, MINE2) mine(Mine2 . . . . . .
)
XIN HUANG et al.:
KNOWLEDGE-BASE MANAGEMENT SYSTEM
if(VerySimilarMine(MINE1,MINE2)then true else SimilarMine(MINE1,MINE2), VerySimilarMine(MINE1,Z), MINE1 - = MINE2). (3) Predicate CompatibleMine(MINE1, MINE2) means that mine MINEI and MINE2 are comparable in the sense that they can be compared to each other to draw conclusions for a feasibility study. This can be defined as follows:
....
421
....... //
/ ' Compatible Sim ar
/ /
CompatibleMine(MINE1, MINE2) <-===
mine(MINE2 . . . . . . . . . . . . ), if(VerySimilarMine(MINEl, MINE2) then true else if (SimilarMine(MINE1, Z) then true else (VerySimilarMine(MINE1, Z), SimilarMine(Z, MINE2), MINEI - = MINE2)). In defining the CompatibleMine, an advanced IF-THEN-ELSE operator provided by LDL is used to express certain procedural constructs. The external call "abs" to calculate the relative difference between two attributes, such as production, is implemented as an external function imported to the LDL, which is used as a built-in predicate. Figure 4 illustrates a graphic representation of the relationships defined by these rules:
(2) Definition of the similarity of backfill material Two levels of similarity are defined by the following rules: (A) If fill FILL1 and FILL2 have a 5% difference in concentration, fine particle and gravity, and belong to the same type of backfill, then the two fill materials are considered to be similar; (B) If fill FILL1 and Z are similar, and Z and FILL2 are similar, then FILL1 and FILL2 are considered to be compatible; Figure 5 is the graphic representation of relationship between fill material, as defined by the above rules.
v~s~ / i ~"\ \
~-:~
//Con"~lJble ;......-
"~'--J'~ "~ x,~,~, ;,~,~. ! ~ "~ )'~'~°" ~ ~r
~,(~-~
Not compatible with any other
mines inthe universeof discourse
Fig. 4. Graphic representation of the relationship between the mines defined by the rules.
Fig. 5. Graphic representation of the relationship between the fills defined by the rules.
(3) Definition of compatible transportation systems Three levels of similarity of transportation systems need to be defined, based on the following rules: (A) If transportation systems TRANS1 and TRANS2 have a 5% difference in capacity, L/H ratio (the ratio of total length to height of the pipe line), and pipe diameter, regardless of the fill material handled, then the two systems are considered to be relevant. (B) If systems TRANS1 and TRANS2 are relevant and designed for compatible mines, to handle compatible fill material, then the two transportation systems are considered to be similar. Notice that in this rule, the two transportation systems are considered to be similar, provided that the related mining operation and fill material are compatible, which takes into account both the mining operation and the fill material as a whole. (C) If the systems TRANS1 and Z are similar, and Z and TRANS2 are similar, then TRANS1 and TRANS2 are considered to be compatible transportation systems (see Fig. 6).
(4) Definition of pressure loss prediction model Every fill material belongs to a category based on a certain pressure loss prediction model. The rules to define the material category are the following: (A) If fill FILL1 and model fill of category MFill have a 5% difference in concentration, size range, and cement ratio with the same fill type, then FILL1 is considered to belong to the MFill category, with the same pressureloss prediction model PM; (B) If fills FILL1 and Z are similar fill materials with the same backfill type, and Z belongs to the MFill category, then FILL1 belongs to MFill as well. Figure 7 is the graphic representation of the relationships between the fill and the fill model, as defined by the rules. It is noticed that the above rules defining the fill model involve a recursive definition which is not
422
XIN HUANG et al.: KNOWLEDGE-BASEMANAGEMENTSYSTEM
reliable, to capture the similarity of the fill material theoretically. If the inference chain is too long, the similarity defined by the first rule will no longer exist. In practice, however, the fill materials do fall naturally into certain categories, with some exceptions. Most of the fill models inferred by the above rules will closely meet the characteristics defined by certain models. Meanwhile, the pressure calculations which follow will be justified by a statistical model, which will certainly eliminate the influence of the factors unreliably inferred by the rules. The techniques involved in these rules in cases 2, 3 and 4 are similar to case 1.
S a ~ [~g
/
,,
:~"~'~--~ IIf'If ] ~ [ .,- ISim, r
iII,
Belong
Belong -- . . . . . .
//
Similar
•:'Y'"' Simila
(5) Definition of pressure loss rule As mentioned earlier, the pressure requirement of a hydraulic system can be estimated in two different ways: (1) numerical calculation, which is not always valid, (2) previous experience, which is not always reliable. The rules given below will generate the pressure requirements using both methods, and will verify one against the other. (1) In this case, an external predicate is used in the program. In LDL, an external predicate can be any kind of procedural program implemented by a conventional language such as C, F O R T R A N , etc. In this case, external predicates are initially implemented as functions to calculate the pressure loss based on the analytical model. These functions are stand-alone programs, and are executable under any operating system. Once imported to LDL, they are understood as external predicates in the context of the Datalog language. In doing this, the procedural programming is seamlessly merged into the logical programming, thereby
\
_/ Similar Similar~
;
~
//
//
o+,0,0
iii/I
Fig. 7. Graphic representation of the "belong" relationship I L Level 1 deduction;...... I~level 2 deduction; ........ ~ level 3 deduction. extending the symbolic calculation power of the L D L system to handle complex numerical calculations. The following is an example: pressure(Transid, P) <____
transport(Transid . . . . . LHratio, Height,_, Fillid, Dia, Vel,_), fill(Fillid,_, Concent, Sgrave, Fgrave . . . . . . ), belong(Fillid, Mfill), Mfill = pl, ppl(Concent, Vel, Fgrave, Dia, Sgrave, LHratio, Height, P). In this rule, the pressure requirement of transportation system "Transid" is specified by P which is the result of calling an external predicate ppl. (2) As in case 1, some aggregation operations are implemented as external predicates to calculate the pressure requirement based on the previous experience, as in the following rule: relevantpressure(Transid, P) <___
.~
/
Similar
transporation(Trans2 . . . . . . . . . . . . . Pumpid2), compatibletransystem(Transid, Trans2), pump(Pumpid2 . . . . . . . P . . . . ),
which generates all the pressure requirements P (a set) specified in the compatible transportation system. Because the L D L does not provide the aggregation function to calculate the average, maximum, minimum of the P set directly, the P set is output to a file called "inp" through the input/output facilities provided by the LDL. Then the following rules can use the intermediate information to generate the needed calculation through another external function call, aggregation Fig. 6. Graphic representation of similar transportation systems (inp, avg, max, min). defined by the rules.
XIN H U A N G et al.:
K N O W L E D G E - B A S E M A N A G E M E N T SYSTEM
(6) Definition of the qualified Pump rule In principle, the pump selected for the system should satisfy the following conditions: (1) the pressure of the selected pump must be greater than the pressure loss predicted; (2) the capacity of the pump should be greater than the capacity of the system; (3) the cost should be as low as possible; (4) the post-sales service for a reciprocating pump counts for about 5% of the total cost; (5) when slurry concentration is 75%, a reciprocal pump is the only choice. Based on these requirements, the pump selection rule could be expressed by rules with some external calls for numerical calculation, which turns out to be very efficient and powerful. The following is one of a group of rules defined to describe the qualifying pumps. By querying the database through the rules, several pumps might be presented as candidates. The users are allowed to make a choice based on the recommendation.
423
Then the file is executed using the shell command salad
7. Definition of cost estimation rules Because of the diversity of the mining operation, it is not feasible at the present time to adopt any universal cost model for backfill operations. Therefore, it is desirable to build up a regional cost model, based on statistical analysis. A province-wide survey of backfill operations has been conducted within the Quebec area and a Quebec regional backfill operation cost model has been established. In this model, the main contributions to the backfill cost come from the fill cost and the transportation cost, which account for about 85-90% of the total backfill cost. Accordingly, a backfill operation can be modelled by an average cost level in terms of statistics. Rules to estimate the cost levels are simply defined on the basis of the average cost level within the area. An operation can be estimated as a very good, good, acceptable, poor and unacceptable.
Qualifiedpump(Transl, PumpID) <..._
pump(PumpID, Type,_, Capacity, Pressure, , ), transporation(Trans2,_, Capacity2 . . . . . . . . . . . . . PumpID2), transportation(Transl . . . . . . . . . . . Filll . . . . ), pressure(Transl, Mp), Compatibletransystem(Transl, Trans2), aggregation(inp, Pavg, Pmax, Pmin), Pmin < Mp Mp < Pavg, Pumptype = 'centrifugal', MP = < pressure, pressure > = 1.05*MP, fill(Fill 1 ,_, Concent . . . . . . . _), Concent < = 0.75. Because this rule involves the external function call aggregation(inp, Pavg, Pmax, Pmin) which depends on the intermediate data file "inp", the query to qualifiedpump has to be performed in two steps: (1) generate "inp" file, (2) call the aggregation external function. The two-step query is completed by L D L scripts and piping techniques, using a redirection command. An L D L script file is an ASCII text file containing a collection of S A L A D commands, so several queries can be executed together to generate the desired results. The following is an example used to perform the aggregation (inp, Pavg, Pmax, Pmin) external call. First, a script file pressure.cmd has to be created as follows: ?relevantpressure(tranl, P) > mining.ldl/mining.cf.0/inp aggregation(inp, Pavg, Pmax, Pmin) exit
3.4. User interface
Above all of the discussions mentioned is the user interface, which is implemented as a stand-alone facility to access the defined queries. Figure 8 illustrates the basic functions implemented. The interface is menudriven, facilitated with help options. The main functions of the system are the following: Review: the option "Review" at the top level provides access to the database to review the previous applications from various perspectives. Users can access previous mining operations, transportation operations, and the characteristics of fill material as initially stored in the database. In addition, the query can access the rule-base first, and retrieve data based on a logic rule, as defined. For example, suppose a user wants to review other backfill operations closely related to his case, the submenu under the option "Mine" provides a "very similar mine" function to access the mining operations defined thus. The user may not be able to retrieve enough information about closely related mines. Then he may relinquish this condition, and try to look at the "similar" cases. As stated earlier, three levels of similarity have been defined by the rulebase. In the least favorable case, the user can refer to compatible mines for a solution. In this process, the users specify their requests, and inferencing and computation will take place automatically, directed by the system. Evaluation: the option "Evaluation" at the top-level menu provides an automated tool set to generate a cost report, and the technical adequacy of the pump's operation, if any. It serves as an entry to a submenu to evaluate hydraulic transportation system in terms of pump operation and overall economic performance.
424
XIN HUANGeta/.:
KNOWLEDGE-BASEMANAGEMENTSYSTEM
The option "cost evaluation" provides a function to evaluate the transportation operation, based on a regional model. In this case, a Quebec provincial regional model is applied. The /-elation "costmodel" and the cost estimation rules defined earlier will qualify certain hydraulic transportation systems into certain categories such as verygood, good, acceptable, poor and unacceptable. The option "pump evaluation" evaluates the pump's performance, based on both the analytical model and the statistical model of pump applications for certain transportation systems. The results of the evaluation are all pumps qualified for certain operations. If the actual operating pump of a transportation system is included in the recommended list, then the pump selected for that system is considered reasonable. Otherwise further investigation is recommended. Design: Finally, the option "Design" provides several data entry forms for specification. Under this option, backfill designers have a chance to access the "review" menu to retrieve information whenever it is needed. The major function implemented in this prototype system is the pump selection. The user inputs the basic information about the mine site, fill material, and layout of the transportation line as guided by the menu. At certain points, users have to determine whether a [
Mine
pump is needed to keep the system working safely, and if so, what the best choice is. The user should either specify an answer if he/she is certain of it, or else leave it for system to make a choice based on the inference rules defined. He/she is even allowed to specify randomly. The "evaluation" option will check whether the user specification is acceptable, and will recommend the best possible choice according to the knowledge available about the underlying system. 3.5. Performance of the system Since the LDL is implemented for the Unix operating system, the prototype of the hydraulic transportation design system works only in a UNIX environment. To test the usefulness of the system, sample data have been collected, with certain modifications based on the Quebec mining operation survey and a literature review. ~3 Sample data of 18 mining operations have been used for system testing. The original data do not provide all the information required by the conceptual model of hydraulic transportation. For example, most of the backfill operations in Quebec do not need pumps in their transportation systems. The horizontal extension is therefore extended proportionally so that the pump is apparently needed and the evaluation of pump operation is necessary. Other data are modified to draw 1~
[ Transport
[~
[
]"~--
Fill
Review
]~
] Cost report ] ~ ] Cost evaluation
[~ Pressure
[ Pump evaluation
[ ~-~
[ Evaluation ] ~ iV
[
Help
]~
Help
1-'~
7"
[~
Design
1~ t~
input form ] ~ ]
Quit
Help
]~ Review
]~ [
Quit
Evaluation ' ] ~
[
Quit
I--4--
Fig. 8. Thc basic functions of the system.
]~
XIN HUANG et al.: KNOWLEDGE-BASE MANAGEMENT SYSTEM the correlations a m o n g the different mining operations. The experimental tests displayed sensible results, and all outcomes m a k e perfect sense, as expected. The p u m p s r e c o m m e n d e d by the system closely agreed with the manual predictions in 86% of the cases. The remaining 14% of the recommendations could not be justified by the system, because of the incompleteness of the knowledge. The basic objectives of the project were fully achieved.
4. CONCLUSIONS AND FUTURE WORK Mine design is a data-intensive and time-consuming procedure. K B M S is providing the capability to greatly increase the efficiency of information process and analysis. This p a p e r presents the basic concepts of the KBMS, and its possible application in mine design. In particular, the L D L deductive database system is proposed as the basic machinery to implement a rule-based application for backfill design. As an example, the hydraulic transportation system was chosen for close analysis. A formal representation of the application of the knowledge base system is fully presented, within the L D L paradigm. Finally, the prototyping of the p u m p selection knowledge-base system was implemented, and its main features demonstrated. There is still considerable work to be done before the knowledge-base m a n a g e m e n t system can be fully applied to mine design. The collection of real operational knowledge at the centre of the application, and this is by no means an easy task. Expansion of the application to the full scope of backfill design is another issue worth exploring, which needs a profound under-
425
standing of the backfill design rationale. A complete specification of the functionality of the system requirements should be p e r f o r m e d prior to any further implementation. REFERENCES 1. Prasad K. et al. An assessment of expert system building tools for mining application. 21st APCOM Symposium, pp. 897-903 (1989). 2. Xin Huang and Hassani F. A new technological approach to backfill design. 94th Annual Meeting of the CIM, Montreal, Quebec (1992). 3. Ramamoorthy C. V. and Wah W. Knowledge and data engineering. IEEE Trans. Knowledge Data Engng 1, 9-16 (1989). 4. Ullman J. D. Principles of Database and Knowledge-base system, Vol. I, pp. 5-20. Computer Science Press, Rockville, Md (1988). 5. Gallaire H., Minker J. and Nicolas J. Logic and databases: a deductive approach. Comput. Surv. 16, 2, 23-29 (1984). 6. Ceri S., Gottiob G. and Tanca L. Logic Programming and Database, pp. 10-89. Springer, New York (1990). 7. Minker J. Perspectives in deductive database. Principles of Database Systems. Conference, San Diego, Calif., pp. 33-60 (1987). 8. Dik Lun Lee and Wenyu Lu. A framework for deductive database systems. IEEE Region 10 Conference on Computer and Communications Systems, Hong Kong, pp. 801-805 (1990). 9. Ceri S., Georg G. and Tanca L. What you always wanted to know about Datalog. IEEE Trans. Knowledge Data Engng 1, 146-166 (1989). 10. Danette C., Ruben G. and Ravi K. Towards an open architecture for LDL. Proceedings of the Fifteenth International Conference on Very Large Data Bases, Amsterdam, pp. 195-203 (1989). 11. Danette C. et aL The LDL system prototype. IEEE Trans. Knowledge Data Engng 2, 76-90 (1990). 12. Tsur S. et aL LDL User's Guide, pp. 33-41 (1991). 13. Hassani F. et al. Economic and technical feasibility for backfill design in Quebec underground mines. Internal report to the government of Quebec, Ministry of Energy and Resources (Mines), Mineral Research Centre (CRM) as well as the Canada Centre for Mineral and Energy Technology (CANMET) (1992).
AUTHORS' BIOGRAPHIES Xin Huang received his M.Sc and B.Sc in mining engineering in 1982 and 1985, China. After 2 year's study at Beijing University of Science and Technology as a Ph.D Candidate, Dr Huang was invited to The University of New South Wales, Sydney, Australia as a visiting scholar for 2 years. He received his Ph.D degree from the Department of Mining and Metallurgical Engineering, McGill University, Canada in 1994. His research interests focus on the application of computers in mine design, planning and operation. He is especially interested in data/knowledge intensive applications such as hypermedia systems, database systems, knowledge-base management systems, and expert systems. F. P. Hassani received a B.Sc. (honours) in mining engineering and a Ph.D. in rock mechanics from the Department of Mining Engineering, Nottingham University, England, in 1975 and 1981, respectively. Dr Hassani has worked in the mining industry in the Middle East, Europe and North America, and was technical director of Ray Mining Company. He has been involved in mining engineering research and development for the past 15 years. In 1983, he joined the Department of Mining and Metallurgical Engineering at McGill University, where he is currently director of its mining program. V. S. Lakshmanan obtained his Ph.D. in computer science at the Indian Institute of Science, Bangalore, India, in 1987. He was a postdoctoral fellow at the University of Toronto from 1987 to 1989. Since 1989 he has been an Assistant Professor of Computer Science at Concordia University, Montreal. He has published several articles in international conferences and jounrls. His research interests include database and knowledge-based systems, and their applications. He is currently directing several research projects aimed at extending the Deductive Database technology for supporting next-generation applications.