Decision support for conceptual bridge design

0 PII:

ELSEVIER

SO954-1810(96)00041-6

Artijicial Intelligence in Engineering 11 (1997) 259-272 1997 Published by Elsevier Science Limited. All rights reserved Printed in Great Britain 0954-1810/97/%17.00

Decision support for conceptual bridge design C. J. Moore, J. C. Miles & D. W. G. Rees Card$School

of Engineering, University of Wales, Cardlx, PO Box 917, Carder, UK, CF2 1XH (Accepted

30 October

1996)

A knowledge

based, decision support tool for the conceptual design of bridges is described. The system incorporates a restructured version of a knowledge base (KB) for conceptual bridge design. The restructuring results in a KB which can be

readily altered and extended by system users who are not expert knowledge engineers. This is achieved by using a novel form of KB in which the knowledge is fragmented into separate concepts associated with design solutions. The system also includes a new style of user interface which provides a critiquing style of interaction with the KB only interacting with the user when it detects a possible error or a more suitable design solution. The new system has been developed using object oriented programming techniques which result in a structured and robust style of KB. 0 1997 Published by Elsevier Science Limited.

represented best current design practice and that they were correct. Hence the knowledge base (KB) was built using intensive knowledge elicitation sessions with recognised experts. The acquired knowledge was then validated using a further set of independent experts.13 The system (BRIDGEl), was placed on extensive test in design offices with user opinions being obtained via a diary study.12 This provided a good assessment of the applicability of such systems to ‘real design’ and also it provided a wealth of further information on the needs and working practices of designers. The validation and evaluation showed that the KB of BRIDGE1 accurately represented the experts’ decision making strategies and the system performed reasonably well within its chosen domain. However it only gave acceptable answers for 87% of the cases on which it was tested. Most of the failures were due to ‘brittleness”4 and exceptions to the rule. The temptation is to try to overcome the latter problems by extending the rule base but as David et aLI point out, this tends to lead to increased brittleness. The designers who reviewed BRIDGE1 also had reservations about the following:

1 INTRODUCTION Over the past 15 years, there has been substantial research into the provision of advanced software tools for designers. Most of this work has concentrated on the application of artificial intelligence (AI) technology, building on the concepts of the ‘expert system’.’ Early AI systems were based on a diagnostic form of working where the user was a provider of information, which was then used by an inference engine coupled to a knowledge base to provide a design solution.2 During the last decade, different styles of system have started to appear. For example Fischer et ~1.~ produced a critiquing system, Gero4 a style of designing using prototypes and Coyne and Subrahmanian’ a flexible system for handling spatial layouts. More recently a much wider range of AI based techniques have been applied to design and especially conceptual design. There is the well known work of Kolodner6 on case based reasoning, various examples of adaptive learning algorithms7>’ and work on constraints.“” Also some very complex and sophisticated design systems have been developed, for example Schemebuilder.” Inevitably, much of this work has concentrated on the development and testing of techniques within a research environment. However, at some stage it becomes necessary to evaluate techniques and systems in real design environments to see how these research concepts survive in the real world. Moore12 developed a fairly conventional, first generation knowledge based system (KBS) for the conceptual design of bridges. However, rather than just being a research tool, great care was taken to ensure that the contents of the system

l

259

The fact that the system controlled the decision making process, asking questions until it had sufficient information and then providing a solution (in typical first generation KBS style). This style of interaction comes from the origin of KBSs which were largely intended for diagnostic type problems where the user consulted an ‘expert’. This is not how a designer usually works. In design, the designer has much to contribute such as experience, common sense and real world knowledge. It is

C. J. Moore et al.

l

l

difficult to incorporate most of this sort of information in a KB and therefore any system which merely asks questions of the user will prevent the designer from making a contribution. The designer has to be included in the decision making process. The style of the interface made substantial use of text rather than graphics (this was necessary due to the then current limitations of the version of PROLOG which was used). As later tests showed,16 this style of interface causes cognitive overload. Essentially this work showed what any system builder would intuitively guess, that simple, graphically oriented interfaces are much to be preferred. That designers wanted to be able to customise and maintain their own KBs. Design consultancies live on their expertise and are rightly proud of their specialist knowledge. They therefore could not accept standard KBs produced by others as anything other than a foundation on which they could build their own KB. Most UK design consultancies are too small to employ specialist knowledge engineers and so they would require a KB which was structured in a manner which non-specialists could maintain and enhance.

BRIDGE1 was in effect a prototype which was used to evaluate the feasibility of using first generation KBS techniques for conceptual design. As with all prototypes, one learns from the faults and then moves on to design a more appropriate product. Hence BRIDGE1 has been followed by BRIDGE2 and it is the latter which forms the main subject of this paper. Both the systems are limited to the sub-domain of small to medium size road bridges crossing other roads. Inevitably this limits the structural form to beam bridges. Also both systems run on PCs to ensure maximum portability, an important factor when the systems are to be externally evaluated. BRIDGE2 contains some important new features, including a novel style of KB which it is hoped is sufficiently simple to allow maintenance by users who are not specialist knowledge engineers. The KB also allows users to add new knowledge provided that this fits within the restrictions imposed by the domain. These features are described below with emphasis on explaining how the system architecture is configured although the other components of the system are also briefly described. Full details of BRIDGE2 are given in Ref. 17. Examples of KBS which are specifically designed to allow uses easily to manipulate their KBs are rare. There are knowledge acquisition tools,18319 which have the facility to acquire knowledge from domain experts but such tools are best used by knowledge engineers2’ Intelligent graphical tools have also been developed to enable a domain expert to encode and refine knowledge without the assistance of a knowledge engineer21’22 but these tools are more knowledge encoders than knowVery few KBs combine the ledge manipulators2’

facilities of a knowledge acquisition tool with the capability of implementing the acquired knowledge. One of the few examples is described by Tranowski.24 The key feature of this work is the use of an intermediate representation of the KB which allows the user to manipulate the KB in a form in which it can readily be comprehended by users who are not expert knowledge engineers. This feature is also present in BRIDGE2.

2 BRIDGE2 -

DESIGN SPECIFICATION

It is well accepted that software, like any other engineering artefact, requires careful design.25 At the start of the project to create BRIDGE2, a variety of key decisions had to be taken regarding the style of the system, the programming language and the style of user interaction. Although inevitably these have been modified as work progresses, the overall characteristics of BRIDGE2 remained unchanged throughout the work. From the onset it was decided that the domain should be the same as BRIDGE1 and that to ensure maximum portability the system would run under Windows on a PC. Work on BRIDGE1 had shown that PROLOG was rather too limited, with much time being wasted trying to deal with the restrictions imposed by the language. Experience had already been gained in developing a decision support system (DSS) for another domain26 using ‘C’ and this had proved to be far more flexible, allowing the system to develop in the required manner rather than being constrained by the limitations of the software. A logical decision therefore was to follow a similar route for BRIDGE2 but to use C++. At the time, some reservations were being expressed about the use of object oriented (00) programming for KBS2’ in particular the need for rules to have unlimited access to the relevant KB, clashing with 00’s enforcement of data hiding and problems present in some software tools of rules existing as separate entities rather than objects.28 As will be shown below. BRIDGE2 has been structured so as to avoid these problems. The version of C++ used is Microsoft Visual C++. As described above, with BRIDGEl, the user evaluation highlighted the need for a high quality, graphical interface.r6 Visual C++ is ideal for this. Also, as identified from the evaluation of BRIDGEl, who was in control of the design process was a vital feature. For BRIDGE2 it was decided that the designer would take the decisions regarding the choice of components and the style of the structure. Hence the system had to allow the designer to create the design on screen rather than the system asking the designer questions and then providing a solution. BRIDGE2, rather than driving the design process would observe the designer and only intervene when a design decision violated the knowledge contained in the rule base. In effect this is a critiquing style of interaction as used by Fischer et a1.3effectively a decision support system style. Given the experience with

Decision support for conceptual bridge design

the previous system, the decision was also taken to allow the user to override any advice given by the knowledge base. This does run the risk of permitting human error but at the gain of the user being able to input common sense and allow for exceptions to the rule. Another important required feature was a form of knowledge base which would allow not only user maintenance but also the addition of new knowledge. The potential users would be designers with no specialist background in AI. This militated against the use of traditional rule bases where knowledge concerning a given solution can be scattered amongst many rules. Such structures are difficult enough for specialist knowledge engineers to maintain, so with the type of maintenance envisaged, it was vital that the KB structure was simple and any potential conflicts easy to detect. Therefore the requirement for a simple, easy to maintain KB coupled to a critiquing style of user interaction led to the concept of a KB which was highly fragmented, with each fragment looking after a portion of the design process and only interacting with the user when necessary. In effect there would, rather than being large complex KBs, be a collection of KBs, which are sufficiently small to allow easy maintenance. 3 THE KNOWLEDGE

BASE

The entire process of the restructuring of the original KB is quite a complex process. This section will only deal with the more salient features. Further details are given by Rees.17 The restructuring was dominated by two requirements: l l

The fragmentation of the KB. A critiquing style of interaction.

In BRIDGE 1, the KB represented the search strategy used by the experts to obtain a solution. Thus as well as containing knowledge about potential solutions, the KB also contained meta-knowledge about how to search the domain. With the chosen critiquing style of interaction the latter is redundant and effectively one is left with a KB which consists of knowledge relating to reasons for choosing and rejecting the various feasible types of components that exist within the domain.17 So far as the fragmentation is concerned, three possible methods were examined, these being: Dividing the KB into categories based on the major types of information involved in the design (in this case the topography of the site, ground conditions, etc.). Dividing the KB into the main areas of structural components (bridge deck knowledge, abutment knowledge, etc). Dividing the KB into the knowledge associated with each type of component which exists within the domain (e.g. M beams, fabricated steel girders, bank seat on piles, etc.).

261

The latter solution was chosen because it results in the smallest sensible form of KB and it provides a system which examines the solutions chosen by the user and critiques each component. Also, all the information regarding a given solution is stored in one place, thus facilitating KB maintenance. One possible disadvantage of fragmentation based on solutions could be that much of the information could be common to several solutions and hence there would be some repetition of information. In practice, it has been found that the amount of repetition is small and the memory requirements of the KB are trivial in relation to those needed for the graphics associated with the system. Also the removal of the search and control knowledge reduces the KB by a substantial amount. Further reflection indicates real advantages for a KB based on design solutions. For example, in design, when looking at the suitability of any given component, the designer examines reasons for choosing the component (positive knowledge) and reasons for rejecting the component (negative knowledge). It therefore seems logical to reflect this in the proposed KB structure. This fits in well with the concepts of negative and positive expertise put forward by Minsky29 who says that negative expertise marks the boundaries of common sense reasoning, establishing areas where safe and efficient problem solving can take place. As will be shown below, the concept of negative knowledge is beneficial in simplifying the inferencing mechanisms used within BRIDGE2. Utilising the concept of splitting the KB into negative and positive knowledge also has the additional advantage of further fragmenting and hence simplifying the KB so that the resulting form is as shown in Fig 1. This shows the knowledge associated with a component known as an M Beam (a precast, prestressed concrete beam commonly used in the UK). (Note there is no upper limit on the span because the system is only valid for small to medium size bridges.) Figure 1 gives an intermediate representation of the KB which is how the user views the knowledge when using the system. There is a similar representation for each component. Each solution KB is called a component instantiation structure. Note that in Fig. 1 the knowledge is expressed in the form of constraints and that there are two types of constraint, descriptive text (passive constraint, e.g. ‘aesthetic consideration’) which is ignored during the inferencing process and merely serves to make the KB more comprehensible, and the remaining, acting constraints, which represent the knowledge used to choose or reject a solution. Active constraints can be either qualitative (e.g. ‘continuous soffit required’) or quantitative (e.g. ‘skew angle > 40’). At this level of KB structure, the integrity of the KB can be ensured by a very simple algorithm which checks: (1) That each component constraint.

has at least one positive

262

C. J. Moore et al.

Negative Constraints

Solution

Positive Constraints --

Span range - between O-16m

- M beam -

-

-

Actual clearance e required clearance

Limited construction - depth

Aesthetic consideration-

-

Continuous soffit required

I- - Skew angle 5 40

Fig. 1. An intermediate representation

of the M-beam component instantiation

(2) That for each component the same constraint is not given as a positive and negative constraint. The above are sufficient for the sort of simple KB structure shown in Fig. 1 but given the complexity of many design problems, even for knowledge relating to single components, and also allowing for the fact that BRIDGE2 allows users to modify existing and add new solutions, it is obvious that constraint propagation and inconsistency problems could occur.10*27 At present there are no mechanisms within BRIDGE2 for dealing with this but a fully applicable, practical tool some mechanism to manage this phenomenon would be required.30

4 OVERALL

SYSTEM STRUCTURE

Having outlined the main features of the system in terms of user interaction and style of KB, it is now useful to describe the system itself. As stated above, BRIDGE2 is written in C++. The concept of discrete building blocks inherent in 00 programming is a key factor in the design of the KB. The ability to limit the impact of most changes to a single object, allows the development of a system which is not overtly sensitive to user modification. As user maintenance of the KB is a feature of BRIDGE2, the ability to restrict the influence of changes is of importance. When creating an 00 system, the problem always arises as to what type of objects and classes are required. What are the key abstractions? This process is critical if a meaningful and efficient software tool is to be developed. Generally the process involves a degree of trial and error as well as the initial design and this was certainly the case with BRIDGE2. The main components of the final system’s architecture are as shown in Fig. 2. The user interface provides tools which allow the user to input design parameters and make decisions regarding solutions as well as receiving information from the critiquing mechanism. The control manager initiates the

structure.

classification and evaluation mechanisms for the critiquing of the design. To achieve this the control manager uses the knowledge manager to access the KB. Only the latter is allowed access to the KB, hence ensuring a standard access protocol and minimising the risk of the knowledge having its integrity violated. The control manager also passes the user’s design information to the user design data base. This stores the data pertaining to the current design. The control manager additionally passes critiquing information to the user interface (N.B. The link between the control manager and the interface is shown as a shaded line in Fig. 2 to indicate that this is an external link, only allowing information passing). Within the user interface there are three components, viz. design, manager and editor. The former is used when the user is building up a design. The manager provides the user with direct access to the knowledge manager and hence links with the KB permitting the alteration of existing solutions within the KB. The editor also permits the user access to the KB through the knowledge editor and can be used for maintenance but its prime function is for the addition of new solutions and the constraints relating to them. The knowledge editor organises the solution information from both the KB and the interface and directly manipulates the images in the interface and through the knowledge manager, manipulates the solution information in the KB.

5 THE CLASS STRUCTURE

The above represents the architecture of BRIDGE2 at the module level. In this section the working of the system is described in terms of objects and classes. The user interface is not described as this uses the standard Windows 00 framework. Figure 3 shows the class structure (apart from the interface) for BRIDGE2. There are four main classes, these being manager, component, constraint (consisting

Decision support for conceptual bridge design

263

Fig. 2. The Bridge II system architecture. The black linesjoining the modules are internal links, whilst the grey lines indicate external

links. of constraint and full constraint) and designer, and the associated mapper and StringList classes. There are also some other classes whose purpose is explained below. The mapper class is split into its various subsections in Fig. 3 but is effectively a single class. Note that the class structure does not literally translate into the system architecture shown in Fig. 2. The reasons for this are explained below. The manager class represents both the KB and the knowledge manager, the latter being the external interface of the class and includes the operations and data that other classes can use. The KB part of the manager class is the collection of all the component instantiation structures collectively referred to as the component instantiation model (CIM). The manager uses the mapper class to store solution objects as indicated in Fig. 4. As shown there are two instances of the mapper class in the private interface, super-structure (i.e. bridge deck) and sub-structure (i.e. piers, abutments, etc) which correspond to the two main types of structural components. The mapper class controls the storage of objects and their associated names (respectively, pointers and string types in Fig. 4) and allows access to these object names by a variety of public operations such as adding new objects and retrieving stored objects. The manager class instantiates the mapper class with solution or component type objects which are instances of the component class. The component class is effectively the top level of the hierarchical knowledge structure which represents the CIM. This class also accesses the mapper class (referred to as the constrain mapper in Fig. 3) to provide a link between it and the constraints associated with a particular solution (Fig. 5). The constraint mapper is also instantiated by the manager class using constraint objects because the manager co-ordinates the flow of knowledge into and out of the KB. The constraint objects are instances of the constraint

class which, as shown in Fig. 6, uses a StringList class to store constraint details. These are represented as strings of text because this is the format in which they can be manipulated by the user. The class is similar to the mapper class, the only difference being the use of strings as opposed to object types. The StringList class is also instantiated by the manager class. At the top of the list of an instance of a StringList class is the active constraining knowledge (in Fig. 6 ‘span > 16m’). For this to be used in the inference process it has to be expanded to describe the actual semantics of the constraint (i.e. converted into either pure characters or mixtures of characters, logical operators and pure numbers). This is undertaken by the designer class (see below). The full semantics (i.e. the identification of the qualitative and quantitative aspects, not the passive constraints) of a constraint are represented by the full constraint class. The passive constraining knowledge in the StringList class, as shown in Fig. 6 (e.g. ‘beyond working range’), is not used in the inferencing process. The StringList class is effectively the bottom level of the hierarchical knowledge structure which represents the CIM. Thus the component instantiation structure representing the knowledge regarding an in-situ concrete deck would be shown as shown in Fig. 7. The designer class represents the control manager in Fig. 2. The designer is a sub-class of the manager and hence inherits many of the manager’s functions and abilities but it also has its own functionality which involves the evaluation and classification of designs (see below). The manager class instantiates and organises the problem solving knowledge. The designer class uses the knowledge as part of the problem solving process. Every time the user inputs new design information, chooses a solution or alters existing design data, this is passed to the designer class by the user interface. The way in which the designer class handles this is shown in Fig. 8. The determination of whether this type

C. J. Moore et al.

264

-_,--\____, / x label x C,

uses ( for interface

)

, label - - - >-

instantiates (new type)

x label x I

uses

( for implementation )

+

inherits (compatible typo

Class Relationships and Cardinality Notation

,,‘r--\_

I \_.-_ __ _’

Class Representation Notation

Fig. 3. The class hierarchy structure for Bridge II. The hierarchy describes three basis relationships

between the classes, inheritance, using and instantiation. The cardinality of a relationship indicates the number of instances of each class. For example between the Designer and the Component Mapper class, the numbers next to the classes indicate that for every instance of the Designer class there are two instances of the Component Mapper class. The two instances of the Component Mapper class correspond to the fundamental distinction between deck and abutment components. The notation used is borrowed from Booth.

Class: Manager

CMapper super-structure, sub-s’ucture;

Fig. 4. The Manager class and its relationship

Class: CMapper public: void Add&ring, Object?; Object* Retrieve(string);

with the Component

Mapper class.

Decision support for conceptual bridge design

265

Object: positive

Class: Component

1 Fig. 5. The Component class and its relationship with the Constraint mapper class.

of input has been previously entered is done by the design-data mapper class which references previous inputs (design-data class) with an associated name (Fig. 9). If there is a match (i.e. previous input) then the 12value of the design-data object is changed to the new value (the check is to avoid creating the same type of object more than once). This only works for quantitative parameters and hence the designer class has to know if a parameter is qualitative or quantitative. For the latter, the check for modification is undertaken using a domain parameter class. This is a static data structure class which holds the entire list of parameters used by the system and is referenced using the StringList mapper class. The final phase of this process is to determine whether or not the current user input is a component type. The designer achieves this using the manager class access functions to compare current input with the names of all the components stored in the KB. If no match occurs (Fig. 8) the classification process is carried out. If a match does occur then the evaluation procedure takes place (see below). The general object hierarchy is as shown in Fig. 10, which shows the interaction of objects and their relationships with regard to the BRIDGE2 KB. The designer is an active object (i.e. it can control its actions and instigate some behaviour without external prompting). The other objects are passive and only exhibit some Class: CStringList public: void Add(string, string): String’ Retrteve(string);

Object

String

: list

string

span > 16m beyond working rang

Fig. 6. The Constraint

class and its relationship StringList class.

with

the

functionality when prompted. The manager class is not actually initiated in the KB hierarchy unless the user wishes to change the knowledge in the system. The manager provides the static structure for the KB which is not required during the design process because the designer class is a sub-class of the manager.17 The editor module has not yet been discussed. This actually exists as part of the editor interface which provides a different type of interface to the manager class. The editor links to the component mapper class whereas the manager interface links to the constraint mapper class, thus reflecting the two different types of modification which can be made to the KB, the manager allowing the alteration of constraints whereas the editor allows the user to modify component knowledge. In terms of the system architecture, changing the knowledge involves two major actions; modifying knowledge about existing solutions or adding knowledge about new solutions. The mechanisms used are very simple. A given constraint can be deleted by removing the object-string reference from the appropriate mapper object. Changes are made by accessing the appropriate StringList object. To add new knowledge, new component objects are created which are then associated with the relevant constraint maps. Thus, as can be seen, by carefully arranging the classes and associated objects, a system which facilitates user maintenance and knowledge addition results. There are some limitations on the extent to which knowledge in the system can be altered. So far as passive constraints are concerned, these, in effect, are the designer’s own notes about the working of the KB and any information can be input. The active constraints are fixed by the limitations of what the design user interface allows and so the system has a fixed vocabulary in terms such as urban location, span range, skew angle, clearance height, etc., and can only reason using these terms. Also the logical operators that can be used are limited to >, <, = and ‘between’. The user is allowed to alter any numerical value relating to constraints (e.g. skew angle > 40 can be altered to skew angle > 45) and for a given solution constraints can be added and deleted as required, provided they fit in with the above limitations. So far as new knowledge is concerned, any new component has to be capable of having its

C. J. Moore et

266

al.

ReJationshipsbetween constraints and components are represented using the mapping classes (e.g. the positii, negative and list objects shown below). e_, . I , ./-__

,’

’ ‘,

,’

Negative Constraints

-_ ___ --.

‘.

‘~,.Solution

\

,’

-----

._ _ Positive Constraints

.\

-m --__

I’

\

‘\.

\

,’ Span > 16m -

‘.

no tetTipoW _

greenfield

works constraints

site

insitu concrete

beyond working range

bridge

workingrange i

‘\

I

height< 10

-

The lnsitu Concrete Component Instantiation Structure

-_

--

-

\

’

\

Object: super-structure

String

Object*

insitu

CComponent! /

/Object

: lnsitu Deck Component

I /

Object : Greenfield Constraint {Object

: list

>

L&&t:

negative

1 Object’ 1 CConstraint’

String span

/ works constraints \ Object : Bridge Height Constraint

[[

d Object : Span Constraint

Fig. 7. An example of the objects and the values required to represent an in-situ concrete component

behaviour described in terms of the existing constraints. So if one wishes to add a new sort of reinforced concrete abutment, BRIDGE2 should be able to cope with this. If however one wanted to use the system to design a river bridge and asked it to reason about scour, the system would not cope. The limitations imposed by the user interface mean that BRIDGE2 has no way for the user to input any information outside its domain.

instantiation

structure.

Hence the user is currently restricted to the constraints provided within the system.

6 THE INFERENCING

PROCEDURE

The inferencing strategy used within BRIDGE2 involves

267

Decision support for conceptual bridge design

by the user. Thus if all the components have been chosen and the user then alters a design parameter, the list will be updated. Essentially classification involves comparing the contents of the constraint mapper objects with the design-data mapper objects.

User Input

5

Comparenew inputwithold inputobjects

The evaluation procedure is as follows: Get old inputobjectand changeto new inputvalues

Createnew input objectv&h specific valueor condition

I

Evaluationprocess

Classificationprocess

Fig. 8. The flow of control in the Designer object during the

initial examination phase. two basis actions,

classifying and evaluating components. Classifying involves the following actions: into Whenever the user enters information BRIDGE2, the inferencing procedure undertakes an exhaustive search of the whole CIM for each component. The first task is to determine whether any negative constraints have been satisfied. If this occurs, that component is deemed to be unsuitable and the inferencing process passes on to the next component. Next the CIM is searched again but only for those components who did not register a negative result in the first pass. If any positive constraints are satisfied then the component is deemed to be suitable. BRIDGE2 keeps a list of which components have received positive and negative ratings from the inferencing procedure. Classification takes place every time that information is added and changed

When the design is sufficiently far advanced for the designer to start choosing design solutions, the user’s decisions are compared against the component list object obtained from the classification. If an unsuitable component choice is detected then the critiquing procedure is invoked. This warns the user of the problem and suggests all those components whose positive constraints have been satisfied as possible alternatives. If however the user’s choice does not violate a negative constraint but no positive constraints have been satisfied, the system notifies the user that insufficient design information has been added. If the user’s solution does not violate any negative constraints and satisfies the relevant positive constraint then the evaluation process is terminated without any need for the KB to interact with the user. Dividing the inferencing into two reflects the two types of user input to the system design parameters and design solutions. The classification process uses the design parameters entered by the user to identify suitable components. The evaluation process uses the results of the classification to evaluate the designer’s chosen components. The inferencing process works so quickly that there is no noticeable delay in the response of the system.

7 THE USER INTERFACE The following gives an indication of the style of the user interface of BRIDGE2. A complete description is given by Rees.” Figure 11 shows a typical design interface. Across the top of the screen are a variety of buttons including those for accessing the designer, the manager and the editor. As the user is currently designing, this button is slightly shaded out. Across the bottom of the screen are buttons

Fig. 9. The Designer class and its relationship with the Design-Data

mapper and the Design-Data

classes.

C. J. Moore et al.

268

Deck Component Map

Abutment Component

F-----d

’

I

I;“-“_8

I

/“~~;‘ !/ -’

\

/

\

\ II

Crete nsl Component

’

Positive Constraint Map Negative Constraint Map

’ a

\ Object

___

bi-directional relationship

Composite object @ \

Object Structure Notation

/

Fig. 10. The object structure for the KB during the design phase. The structure indicates two basic types of relationship between the objects and containing relationships. (i.e. services, pier position, environment, bearing position, exit) which allow the user to change design parameters which are relevant to this stage of the design process, which in the example given is pier design. The style of interaction of the critiquing mechanism is as shown in Fig. 12. As can be seen the system not only states that it thinks the designer has made an error but it also recommends a solution which it believes to be the most suitable for the given design problem. Considerable thought was given to the style of interaction for the critiquing. For example should the system require the user to amend the design and satisfy the information in the KB. Such a procedure would effectively mean that the KB was in control of the design process and as stated above, it is not possible given current technology to create a KB which can cope with every situation. Thus, as implemented in BRIDGE2 the KB prompts the user, detecting the majority of basic design errors, providing a source of alternative ideas and hopefully

detecting most of the violations of previous design assumptions when design parameters are changed. Design solutions which are present in the CIM are, when requested by the user, presented on the screen in a pictorial format (Fig. 13). Each drawing of a solution is actually a device independent bitmap (.dib) which BRIDGE2 uses as a button and therefore to choose a particular solution the user merely clicks on the appropriate part of the screen with the mouse. To add new solutions, first it is necessary to provide a suitable drawing as a .dib file. This is then added into the KB, given a name and the relevant constraints and subsequently appears in the Design interface with the other solutions. Note that any new solution has currently to fit within the format of either being a deck solution or an abutment/bank seat (i.e. sub-structure) solution. BRIDGE2 could not for example cope with arch or suspension bridges. When the user accesses the manager, the CIM is displayed as in Fig. 14. The solution (in this case M

Decision support for conceptual bridge design

Fig. 11.

269

A typical design screen: the Piers stage screen.

beams) appears in the centre and the negative and positive constraints are given on either side. Modification of the KB is achieved by accessing a variety of dialog boxes. As the actual processes involve a number of dialog boxes they will not be shown here but full details are available.17

8 EVALUATION

One of the strengths of the work on BRIDGE1 was the practical evaluation. BRIDGE2 has undergone preliminary external evaluation, partially with the people used for BRIDGE1 and also with some new designers. Unfortunately due to time and financial constraints, it has not been possible to evaluate BRIDGE2 with the same rigour as used for BRIDGEl. The evaluation has consisted of short sessions using groups of designers. Each session lasted for about 2 h. The results of the evaluation are encouraging. No major criticisms of the system have been received. The bulk of the comments made were concerned with future developments. For example the designers would like to see ‘clearance envelopes’ built into the system (i.e. the clear space beneath the bridge required by the highways authority) and links with CAD systems. Designers

seemed to like the style of the user interface and particularly the graphics but most of all they appreciated the facility to change the knowledge in the system. One particularly gratifying feature was the comments received from those who had previously evaluated BRIDGEl. These were particularly positive and included statements of which showed that they viewed BRIDGE2 as potentially being of far more practical use than BRIDGE 1.

9 CONCLUSIONS Based on the results of an evaluation of a previous system by practising designers, a new style of design KBS has been derived. The system uses a critiquing style of interaction with the user which provides decision support as opposed to controlling the design process. The system therefore allows the user to control the design process and only interacts when it detects something which clashes with its KB. The user then can decide whether or not to take notice of the information provided by the system. The system also allows the user access to the KB either to modify existing information or to add new information. To facilitate this, the style of the KB has

270

C. J. Moore et al.

Fig. 12. The critiquing style: notifying the user of a potential conflict.

been made as simple as possible by fragmenting the knowledge into separate knowledge bases for each potential design solution. The knowledge is then fragmented further by splitting it into negative and positive constraints. As currently configured this results in very simple, easy to understand structures and the removal of the need for control and search knowledge within the KB has been beneficial. As with all new systems, there are some unanswered questions and one of the major ones relates to the KB. The ability of users to add to the constraints associated with each solution could result in

Fig. 13. A typical component

constraint propagation dithculties. This is an area which needs to be addressed if such a style of KB is to be of real, practical use. The system has been implemented for the domain of small to medium size road bridges. Currently the addition of new knowledge is limited to structural forms which are of similar function to those contained within the system. A far more powerful system would result if the user were able to add completely new structural forms but as yet this problem has not been successfully tackled.

choice screen: the bankseat-type

dialog box.

Decision support for conceptual

bridge design

271

Fig. 14. The M beam design knowledge displayed in the manager module of the Bridge II system. ACKNOWLEDGEMENTS This work has been undertaken with the assistance of Sir William Halcrows and Ptnrs (Swindon), Mott Macdonald and Ptnrs, Cass Hayward and Ptnrs and Sir Alexander Gibb & Ptnrs.

REFERENCES 1. Shortliffe, E. H. Computer Based Medical Consultations: MYCIN. Elsevier, New York, 1976. 2. Soh, C. K. An approach to automate the design of steel off shore structures. PhD thesis, University of Wales, Cardiff, 1990, pp. 350. 3. Fischer, G., Lemke, A. C., Mastaglio, T. & March, A. I. Using critics to empower users. In Human Factors in Computing Systems, CHI ‘90, Washington State University, ACM, 1990, pp. 337-47. 4. Gero, J. S. Design prototypes: a knowledge representation schema for design. AZ Magazine, 1990. 5. Coyne, R. F. & Subrahmanian, E. Computer supported creative design: a pragmatic approach, In ModelZing Creativity and Knowledge-Based Creative Design, ed. J. S. Gero & M. L. Maher. Lawrence Erlbaum; NJ, 1993, pp. 300. 6. Kolodner, J. Case-Based Reasoning. Morgan-Kaufman, San Mateo, CA, 1993, pp. 668. 7. Hudson, M. G. & Parmee, I. C. The application of genetic algorithms to conceptual design. In AZ System Support for Conceptual Design, ed. J. Sharpe. Springer-Verlag, London, 1995, pp. 17-36.

8. Pham, D. T. & Yang, Y. A genetic algorithm based preliminary design system. Proc. Inst. Mech Engrs (London), 1993, 207, 127-33. 9. Smith, I. F. C. & Faltings, B. V. Implementing qualitative reasoning for Structural design using constraint propagation. In Computing in Civil & Building Engineering, ed. L. F. Cohn. Prov V-ICCCBE, ASCE, New York, 1993, pp. 1251-8. 10. Haroud, D., Boulanger, S., Gelle, E. & Smith, I. Management of conflict for preliminary engineering design tasks. AIEDAM, 1995, 9, 313-23. 1I. Bracewell, R. H., Bradley, D. A., Chaplin, R. V., Langdon, P. M. & Sharpe, J. E. E. Schemebuilder: a design aid for the conceptual stages of product design. ZCED’93, The Hague, 1993, pp. 131 l-18. 12. Moore, C. J. An expert system for the conceptual design of bridges, PHD, thesis, Cardiff School of Engineering, University of Wales, Card% 1991, pp. 350. 13. Moore, C. J. & Miles, J. C. The importance of detailed KBS evaluation for systems intended for implementation in industry. Comput. Syst. Engng, 1991, 2 (4) 365-78. 14. Price, C. & Lee, M. Applications of deep knowledge. AI in Engineering, 1987, 3 (I), 12-17. 15. David, J-M, Krivine, J-P. & Simmons, R. Second generation expert systems: A step forward in knowledge engineering. In Second Generation Expert Systems, ed. J M. David, J-P. Krivine & R. Simmons, SpringerVerlag, Berlin, 1993, pp. 3-23. 16. Philbey, B. T., Miles, C. & Miles, J. C. Empirical evaluation of engineers’ requirements for the user interface of a conceptual bridge design expert system. Knowledge Based Systems for Civil and Structural Engineering. Civil-Comp Press, Edinburgh, 1993, pp. 297-302.

272

C. J. Moore et al.

17. Rees, D. W. G. A non-prescriptive KBS for the conceptual design of bridges. Submitted PhD thesis, Cardiff, School of Engineering. University of Cardiff, 1995, pp. 220. 18. Marcus, S. Automating Knowledge Acquisition for Expert Systems. Kluwer, Boston, MA, 1988, pp. 350. 19. McDermott, J. Preliminary steps towards a taxonomy of problem-solving methods. In Automating Knowledge Acquisition for Expert Systems, ed. S. Marcus, Kluwer, Boston, MA, 1988, pp. 225-56. 20. Musen, M. A. Conceptual models of interactive knowledge-acquisition tools. Knowledge Acquisition, 1989, 1, 73-88. 21. Lee, N. S. Graphical knowledge programming with KNAPS. Znt. J. Man Machine Studies, 1989,31, 611-41. 22. Musen, M. A. An editor for the conceptual models of interactive knowledge acquisition tools. Znt. J. Man Machine Studies, 1989, 31, 673-98. 23. Edmonds, E. A., O’Brien, S. M., Bayley, T. & McDaid, E. Constructing end user knowledge manipulation systems. Znt. J. Man Machine Studies, 1993, 38, 51-70. 24. Tranoswki, D. A knowledge acquisition environment for scene analysis, Znt. J. Man Machine Studies, 1988,29, 197-213. 25. Sommerville, I. Software Engineering. Addison-Wesley, Reading, MA, 1989, pp. 300.

26. Hooper, J. N. A KBS for strategic sludge disposal planning. PhD thesis, Cardiff School of Engineering, University of Wales, Cardiff, 1993, pp. 310. 27. Ward, A. C., Lozano-Perez, T. & Seering, W. P. Extending the constant propagation of intervals, AZEDAM, 1990, 4(l), 47-54. 28. Mulvenna, M. D. &zHughes, J. G. Expert agents in KBS. In Applications and Innovations in Expert Systems, Proc. ES ‘93, ed. I. Graham. BCS, Cambridge, 1992, pp. 5 l-60. 29. Minsky, M. Negative expertise. Znt. Expert Syst., 1994, 7(l), 13-18. 30. Mackworth, A. K. Consistency in networks of relations, AZ, 1977,8, 99-118. 31. Maher, M. L. A knowledge based expert system for the preliminary design of high rise buildings. PhD thesis, Department of Engineering, Carnegie Mellon University, 1984. 32. Miles, J. C. & Moore, C. J. Practical KBS in Conceptual Design. Springer-Verlag, London, 1994, pp. 250. 33. Rittel, H. W. J. & Webber, M. M. Dilemmas in a general theory of planning. Policy Sciences, 1973, 4. 34. Moore, C. J. & Miles, J. C. Applying innovative design systems in practical engineering. Znt. J. Construct. Inform. Tech., 1993, 1, (4).