knowledge representation form in mechanical engineering

Knowledge representation form in mechanical engineering

Rafael Belio, D G/dvez, G Simchez, M M Garcia and G Benavides

The paper presents a knowledge representation form (KRF) oriented to knowledge based CAD systems development for variant design in mechanical engineering. It combines both declarative knowledge (frames and production rules) and procedural knowledge. From this KRF, a design problem solving method based on a data driven inference process has been developed. A way to automate the knowledge acquisition process according to this KRF is defined.

Keywords: knowledge representation, intelligent CAD systems, problem solving methods

Various studies on how artificial intelligence (AI) tools can be employed in CAD/CAM systems development have been carried out. In these studies, some authors, such as Crestin 1, Hatvany 2, Begg 3, Camacho 4, Rabins 5 and Smithers 6 have stated positive criteria and results relating to the use of AI techniques in design tasks. Dixon 7 and other authors have been more conservative.

For instance, the Design to Product project managed by GEC Electrical Projects, which involved nine other UK companies and universities, used AI techniques. This project covered all the steps of a product's lifecycle from the design up to its fabrication. Its objective was to eliminate the losses in the product generation cycle, leav- ing a smooth increase, and to solve the knowledge consistency and management problems inherent in exist- ing design and manufacturing methodologies 6.

Our project, an intelligent system to help the designer s , has been developed along the same lines, but it is directed at solving design problems in small or medium size companies, and so two of its main characteristics are simple

Facultad de Matenuitica Fisica y Computaci6n, Universidad Central de Las Villas, Carretera a Camajuani Km 5, Santa Clara, Villa Clara, Cuba Paper received 7 May 1991. Revised paper received 20 January 1994. Accepted 25 March 1994

design and easy operation. Robertson 9 analyzes the application of tools for the Design to Product project, and discusses the problem of the exploitation of the systems and the limitations on their use that this implies for engineers.

Conceptually, there are many similarities between the Edinburgh designer system and the Intelligent System to Help Designer in terms of the fact that both use knowledge in mathematical form, and in tabular, heuristic and graphics forms, and natural language in the sense of supporting communication with the user. They have a good interface with the user, and they manage knowledge on the basis of restrictions to maintain the integrity of the design object.

The differences are in terms of the objectives that the systems were defined for. For the sake of simplicity, our project, in place of modules, uses simpler knowledge units, in which the calculation expressions are main- mined, but there is a possibility of adding employment conditions, thus obtaining more flexibility. All the information about the object to be designed and its parameters, including the set of logical expressions to maintain the integrity of the design (the restrictions), are stored in a knowledge base, instead of their being several types of specialized database.

These studies and our own experience have been used here in order to develop a knowledge representation form for design tasks in mechanical engineering. Mainly, this KRF has been targeted at what has been defined as variant design by Vujosevic in Reference 10, in which a design task is carried out from a known physical model, and through which a new product can be attained by varying certain parameters of the physical model.

This KRF is defined in terms of both declarative and procedural knowledge. The advantage of taking both types of knowledge into account has been stated by other authors such as Muller I~ and Sugaya t2. Declarative knowledge is described by using frames and production rules (see References 13 and 14). Procedural knowledge

154 0950-7051194103/0154-07 © 1994 Butterworth-Heinemann Ltd Knowledge-Based Systems Volume 7 Number 3 September 1994

Knowledge representation form in mechanical engineering: R Bello et aL

is expressed by using subroutines written in a Pascal language dialect.

The relationship between the different methods of declarative knowledge representation has been analyzed in other papers. Friedland 15 has stated that systems based on rules can incorporate frames to facilitate the representation of a large amount of information. Similarly, systems based on frames can use rules to make infer- ences. According to Fikes ~3, the main deficiencies of production rules appear in areas where frames are very effective. In turn, Engelman ~6 evaluates this relation positively.

From the physical model representation of a product and by using this KRF, we have developed a problem solving method based on a data driven inference process. This inference engine can also provide for backtracking, when necessary.

Automatic knowledge acquisition can also be accom- plished by using this KRF.

K N O W L E D G E R E P R E S E N T A T I O N F O R M

Starting from the experience obtained from the application of computation in design tasks and from the analysis carried out by other authors such as Crestin j, Bertrand jr, Markus )s and Hatvany ~9, we have deter- mined the information that must be stored in the physical model in order to carry out the variant design.

The physical model of the product is described by means of two types of frame. The first one enables us to store the knowledge about a product in an overall man- ner. We call it the object frame, whereas the second frame type is used to represent the knowledge relating to each product parameter (that is why we call it the parameter frame). Thus, a knowledge base storing the physical model of a certain product will consist of an object frame plus a parameter frame for each parameter of this product.

An object frame consists of the following slots:

• name of product (S-NP), • comment about product (S-CP), • imported design parameters (S-IDP), • design constraints (S-DC), • function to evaluate the solution (S-FES), • actions (S-ACT).

The S-IDP slot contains a list of parameter names with values calculated from another physical model. With this information the physical model of a complex product may be divided into several submodels, which can in turn be managed separately.

The S-DC slot contains a list of design constraints. On defining a physical model, it is necessary to determine the logic connections among parameters, since these define the conditions that the new product should satisfy. A

design constraint can be described by means of a single logical expression (like the logical expression in a high level procedural programming language, such as Pascal or C). A model logical expression implies connectives ((single logical expression) =~ (single logical expression)) or a subroutine written in a Pascal language dialect.

A design constraint is written by using the following syntax:

ExpL :: = ['not'] TerL ('or' TerL)*

TerL :: = FacL ('and' FacL)*

FacL :: = ExpR '['ExpL']'

ExpR :: ---- ExpA OpR ExpA

OpR :: = >1 <1 =1

>/I < > 1

ExpA :: = [' - '] Term ((' + '1' - ') Term)*

Term :: = Factor ((%'1'/') Facto0*

Factor :: = EO I Decimal Number I Function I '('ExpA')'

Examples:

• Example 1: al > 3 and [/12 = 8 or bl = 7]. • Example 2: (al = 9) or [vB = 3 and bl ~< 67]. • Example 3: acos(bt + c0 < > pow (al, 3) or [sin (b0

= sin (c0]. • Example 4:a2 = b2 and b2 < 234.3 and c2 = 9 and

d ~ < 6 . • Example 5." a5 = b5 and h5 = 14 or z5 --- 4. • Example 6:a5 = b5 and [h5 = 14 or z5 = 4].

Examples 5 and 6 have different logical values, since, in Example 6, the square brackets disrupt the priority of the operator.

Restrictions may also be defined like this:

(logical expression) ~ (logical expression)

Example: T = 45 and WER < A i • Ci =~ Fl = 89.

In general the operands of the arithmetic and logical expressions can be EO names, numerical constants, character constants (strings of characters in quotation marks) and functions.

Knowledge-Based Systems Volume 7 Number 3 September 1994 155

Knowledge representation form in mechanical engineering: R Bello et al.

The functions that may be used are as follows:

• arithmetic functions such as sin (X), exp (a) and In (a),

• input functions (read (c) and db3 (c)), • others (rip(c), ne(c), max (c), min (c)).

where X is an arithmetic expression (angle in radians), a is an arithmetic expression (real number), and c is a string of characters.

The S-FES slot contains an arithmetic expression or subroutine. Generally, it is possible to calculate several variants for a new product starting from a physical model. Sometimes it is possible to evaluate each solution numerically by means of an arithmetic expression expressed in terms of the weight of significant parameters. This value characterizes the level of efficiency of the solution found.

The evaluation function (EF) is an arithmetic expression whose operands are EO names, numerical constants or functions. A subroutine to evaluate solutions can also be used. The EO names represent the weight of that parameter in the solution, that is, when evaluating the EF, the value of the EO is not used, but rather its weight. (The calculation of the weight of the EO is discussed later.)

The S-ACT slot contains a list of actions known as preactions (denoted by commands), which should be performed at the beginning or at the end (in which case they are postactions) of the process developed to calculate a design variant.

The syntax of the actions is

(type>[{(condition>}] (name of act ion)((body))

and the type is ' - ' (preaction) or ' + ' (postaction). Square brackets indicate that the condition is optional. The condition is a logical expression.

Among these actions, we have output into text file, loading of another physical model (knowledge base), modification of the physical model, and generation of geometric objects. Other operations can be described by subroutines.

Each parameter frame consists of the following slots:

The S-DOM slot contains a list of standard or fre- quently used values for this parameter.

The S-ID slot contains a list of parameter names. The values of these parameters somehow influence the value of the parameter represented in this frame, although it does not appear as the operand in the S-PC slot of this frame. (This knowledge is useful in order to control backtracking during the inference process.)

The S-PC slot contains a list of procedures (such as the if-needed procedure defined by Levesque 2°) which allows the calculation of a value for this parameter. These procedures can be defined as production rules in the following way:

Rule 1: if (logical expression) then (arithmetic expression>.

Rule 2: if <logical expression) then (string).

The logical expressions describe which conditions must be satisfied to use this rule. They can also be defined as subroutines.

The S-PCW slot contains a list of procedures that make the calculation of a weight possible for this parameter. PCWs are described in the same form as PCs.

The S-ACT slot is similar to the S-ACTs of object frames. Operations are carried out before or after (with a similar purpose to the if-added procedure); a value has been calculated for this parameter.

D E S C R I P T I O N O F F U N C T I O N S

Function (read)

(read) :: = read("(file name);(class)")

(class) :: = #,(integer> I @,(character>

The value of the EO is read from the file whose name has been specified. The value is read from the line number (integer) (empty lines are neglected) or from the one marked with the indicated character (which is discarded when reading the value). If the file name is STDIN, the class is neglected and read from the keyboard.

• name of parameter (S-NPAR), • comment about parameter (S-CPAR), • domain (S-DOM), • implicit dependence of other parameters (S-ID), • procedures to calculate parameter value (S-PC), • procedures to calculate parameter weight (S-PCW), • actions (S-ACT)

Example

read ("test.txt; # ,3")

'Read' is evaluated with the content of the third line of the textfile "test.txt".

The S-NPAR slot contains the name of the parameter whose information is stored in this frame.

The S-CPAR slot contains a description of the parameter.

read ("data;@, > ")

The returned value is the content of the line in the file 'data' whose first character is ' > '

156 Knowledge-Based Systems Volume 7 Number 3 September 1994


read ("stdin; # ,3")

The value is read from the keyboard.

Function (db3>

(db3> ::= db3("(argument>")

(argument> :: = [(driver>:][(path>](DB name>[.dbf], (access>[; (integer>]

(access) :: = (key> [ (number of article>

(key> :: = (integer> (options> [,(key>]

(options> :: = <option 1> [ (option 2>

( o p t i o n 1> :: = :(EO name)

(option 2> :: = = (constant>

The value of EO is searched for in a database created with the DBMS dBase III or dBase III Plus, whose name is given (the .dbf extension is assumed). Access to the database may be through a key or the number of the article from which the value is to be taken.

The key allows for the determination of the article in the database from which the EO value is taken. A key is a sequence of pairs in which (integer> indicates the field number (according to its position in the file structure). In the case of option 1 the name of the EO is used and its value is taken to form the search key. In option 2, the string of characters is the value to be used in the search. What is searched for is the first article in the database with all the indicated fields having the same values as those given.

If no article is found to comply with the key and the first specified field in the key is a numerical field then the article having the value closest to the search value is searched; otherwise, an error message is shown, the inde- finite value is returned, and the inference process is aborted.

The value assigned to the EO is the content of the field whose order number is given in < integer > ; if this field number is not given, the whole string that represents the content of the article is assigned instead.

Examples

db3 ("dimcad.dbf,23;3")

From the database dimcab.dbf (which is found in the current subdirectory) the value of the third field in article 23 is taken:

db3("dimcad, l:Rx, 3 = blue;2")

From the database dimcad.dbf the value is taken of the second field of the article whose first field has a value equal to the value of the EO Rx y in the third field of the value 'blue'; if in the database the character constant is delimited by quotation marks these must also be used in the demand (for example 3 = "blue").

The function db3 makes it possible to obtain all the articles which comply with the key (exactly or approxi- mately) if the access with the same key is repeated.

Function (np > (np> :: = np("<name of EO>")

The value returned is the number of the procedure which evaluated the EO whose code is given. An EO without a value has np = - 1 and if it is an initial datum, n p = O.

Function (he> (ne> :: = ne("(OE name>")

The value returned is the number of the step in which the value of the EO whose code is given was calculated. An EO without a value has ne = - 1, and, if it is an initial datum, ne = O.

Function (max>

(max> :: = max("(argument>")

(argument> :: = <EO name> [,<argument)]

From the elementary objects listed the one that has been evaluated with the highest value is searched for and this value is returned.

Example

maxCAl, DI, H3")

Function <rain>

(min> :: = min("(argument>")

(argument> :: = (EO name> [,(argument>]

From the elementary objects listed the one that has been evaluated with the lowest value is searched for and this value is returned by the function.

E X A M P L E

We will use a cylindrical gear in order to show the use of this KRF. Some of the parameters of this product are the



module (m), the distance between centers (not corrected) (ac), the distance between centers (standardized) (aw), the transmission rate (U), the number of teeth (z0, the angle (Beta), the rebushing factor (E_Alfa), the correction type (type), and the face width (b).

The object frame for the cylindrical gear is

S-NP: S-CP: S-IDP: S-DC:

gear physical model to calculate cylindrical gear (empty) E_Alfa > 1.2 swe~ >/ 0.25,m and swe2 f> 0.25,m type = "height" t> X~ ~< 0.5 type = "without correction" /> Zl >~ 12 and zt ~< 33

The parameter frame for parameter m is

S-NPAR: m S-CPAR: module S-DOM: 90

80 70 60 55 40

1.25 1

S-ID: (empty) S-PC: type < > "without correction" ~ mtemp

type = "without correction" ~ 20 m ~ < 2 0 a n d m / > 1 4 ~ m - 2 m~< 12andre ~> 7 ~ m - 1

The parameter frame for parameter z~ is

S-NPAR: S-CPAR: S-ID:

S-DOM: S-PC:

Zl

number of teeth m

Beta (empty) type < > "without correction" --, 12 type = "without correction" --,

int(Zsnm/(1 + U)) type < > "without correction" and zj ~< 33 ~ z l + l

P R O B L E M - S O L V I N G STRATEGY

A design variant is found by means of a data driven inference process. The designer can fix the initial value for some parameters in the new product and then he/she must use the inference process. The PCs are used in order

to calculate the value for the parameters; every time a value is found, the design constraints are tested. The ending of the inference process is reached when all the parameters have been calculated.

Once the designer has fixed the values for some parameters (if he/she did this), a nonevaluated parameter is searched. When trying to find a value for this parameter, it is possible to obtain three different results: (a) a value is found, (b) no value is found but one or more PCs with a nonevaluated parameter as operand exist in the S-PC slot, or (c) it is impossible to find a value although all the PCs have been used• In the first and second results, an inference process continues by searching other nonevaluated parameters; in the third case, it is necessary to carry out a backtracking in order to recalculate one or more parameters whose values have an influence on the value of this parameter.

This search strategy is repeated until (a) all the parameters have a value, (b) nonevaluated parameters exist, but it is necessary for the designer to fix a value for some parameters, or (c) consecutive backtrackings have been carried out and the designer has attempted to modify the values of some parameters.

In brief, this problem solving method is based on a forward reasoning (data driven) process using a depth first search to calculate a new product.

A U T O M A T I N G K N O W L E D G E A C Q U I S I T I O N

Knowledge engineers and experts are people who develop knowledge-based systems. They may or may not be the same person. In this conjunction, there are advan- tages and disadvantages, but there is no doubt about the necessity of leading or orienting experts when they work as knowledge engineers for the first time.

On the basis of this judgment and the facilities provided by the K R F presented in this paper, we define some principles in order to automate knowledge acquisition in the field of mechanical engineering.

These principles were implemented in an ICASIAD system. ICASIAD is designed to elicit knowledge about a particular product from mechanical engineers in order to build a knowledge base.

INTELLIGENT S Y S T E M TO H E L P D E S I G N E R S

By using this knowledge representation form, an intelligent system to help designer (SIAD) has been developed. SIAD is an intelligent environment with graphics facilities aimed at the creation of CAD systems. The natural complement to SIAD is a knowledge base, which is where the specific characteristics of the design object are defined. The combination of SIAD and a KB produces an intelligent CAD system with the specific purpose of designing a concrete class of objects•


Knowledge representation form in mechanical engineering: R Belle at el.

The first important decision is to determine whether we can use SIAD for the CAD system that we want. Just like any other CAD system built with SIAD for a specific design object, this is made up of

SIAD + (knowledge base about the design object)

The decision is limited to determining whether or not the knowledge required to carry out the design process for the kind of object desired can be described by the syntax and semantics of one KB in SIAD.

In general terms the conditions for a positive decision are as follows:

• The design of the specific object consists of the calculation of all the characterizing parameters.

• The restrictions on the design, if they exist, are expressed as logical expressions among the design parameters.

• Each design parameter is evaluated by the designer, or there are rules for its calculation.

SIAD integrates three main components: a syntactic editor to write the knowledge base, a graphics editor and an engine machine. The syntactic editor provides facilities to create, save and load knowledge bases. The graphics facilities of the integrated package are as follows. There is a simple graphics editor which (a) allows the creation, saving and graphics loading of the design object class, (b) generates geometric elements in the graphics editor using geometric semantics incorpor- ated in the knowledge base, and (c) generates text files with the necessary information to establish communication with professional graphics editors such as Auto- CAD. The engine machine implements the problem solving strategy described above.

SIAD uses an interactive environment based on windows and pop-up menus.

C A D S Y S T E M S G E N E R A T O R

Recently, a generator of CAD systems based on knowledge was developed. This generator, from a base of knowledge, can obtain an executable program which has all the information in the knowledge base. This means that we can obtain a program or a particular inference machine for a given knowledge base which is incorpor- ated in the program.

When we obtain the executable program we guarantee the protection o f the information contained in knowledge bases from arbitrary changes and unauthorized extraction by users. Users are totally excluded from learning SIAD, because the executable program obtained automatically carries out the calculation starting from the initial data and using the information stored

in the knowledge base, and it guarantees the system's use for a specific purpose.

C O N C L U S I O N S

So far, this knowledge representation form has been used successfully in the creation of the physical model for various products, for example

• a chain drive, • a belt drive, • a cylindrical gear, • a worm and wheel, • harmonic drivers, • the calculation of technologies for both manual and

submerged arc welding.

By using this K R F and the problem solving method previously described, an integrated package oriented to knowledge-based CAD systems implementation has been developed (see Reference 8). Moreover, a program to automate knowledge acquisition in the mechanical engineering area has been created. Recently, a SIAD- G EN program was developed. S IADGEN is a knowledge-based C A D system generator. This program creates an executable program from a particular knowledge base and a data driven engine machine, unlike SIAD, where there is no separation between the two components.

R E F E R E N C E S

1 Crestin, J P 'Syntax and semantics of programming languages versus CAD/CAM requirements: the role of artificial intelligence languages' in Ponomaryov, V M (Ed.) Artificial Intelligence 0983)

2 Hatvany, J 'An efficient use of deficient knowledge' in Ponomaryov, V M (Ed.) Artificial Intelligence 0983)

3 Begg, V Developing Expert CAD Systems Kogan Page 0984) 4 Camacho, J 'Evaluation of the effectiveness of Prolog for CAD

applications' IEEE Computer Graphics and Applications (Mar 1984) pp 67-75

5 Rabins, M 'Design theory and methodology - - a new discipline' Mechanical Engineering Vol 108 No 8 (1986) pp 23-27

6 Smithers, T 'The Alvey large scale demonstration project Design to Product' Artificial Intelligence in Manufacturing (1987)

7 Dixon, J 'Will mechanical engineers survive artificial intelligence?' Mechanical Engineering Vol 108 No 2 0986) pp 8-10

8 Belle, P R 'Integrated package oriented to intelligent CAD system implementation' Conference CAD~CAM Technology Transfer to Latin America (1990)

9 Robertson, A 'The Alvey Design to Product demonstrator project: a user view' Business Benefits of Expert Systems (1990)

l0 Vujosevic, R 'A knowledge based CAD application system' Pre- prints Prolamat 88 Dresden, Germany 0988)

I l Muller, C 'Modula-Prolog: a programming environment for build- ing knowledge systems' in Kriz, J (Ed.) Knowledge-Bused Expert Systems in Industry Ellis Horwood 0987)

12 Sugaya, H 'A Prolog frame system for knowledge-base design and diagnosis' in Kriz, J (Ed.) Knowledge-Based Expert Systems in Industry Ellis Horwood (1987)

13 Fikes, R and Kelder, T 'The role of frame-based representation in reasoning' Commun. A C M Vol 28 No 9 (1985)

14 Hayes-Roth, F 'Rule-based systems' Commun. A C M Vol 28 No 9 (1985)



15 Friedland, P 'Knowledge-based systems' Commun. ACMVo128 No 9 (1985)

16 Engelman, C and Stanton, W M 'An integrated frame/rule architec- ture' in Elithom, A and Banerji, R (Eds.) Artificial and Human In telligence Elsevier (1984)

17 Bertrand, D 'Main concepts of Ciao: an intelligent CAD system' Preprints Prolamat 88 Dresden, Germany (1988)

18 Markus, A and Hatvany, J 'Matching AI tools to engineering requirements' Annals CIRP Vol 36 No 1 (1987) pp 311-315

19 Hatvany, J 'Available and missing AI-tools' Annals CIRP Vol 35 No 2 (1986) pp 433-435

20 Levesque, H 'Expressiveness and tractability in knowledge representation and reasoning' Comput. Intell. Vol 3 (1987) pp 78-93

BIBLIOGRAPHY Poplestone, R et al. 'Engineering design support systems' Pres. 1st Int. Conference Applications of AI Southampton, UK (1986)


knowledge representation form in mechanical engineering

Documents