Design engineering—a need to rethink the solution using knowledge ...

Knowledge-Based Systems 12 (1999) 257–267

Design engineering—a need to rethink the solution using knowledge based engineering C.B Chapman*, M. Pinfold Advanced Technology Centre, Warwick Manufacturing Group, University of Warwick, Coventry CV4 7AL, UK Received 8 December 1998; accepted 17 March 1999

Abstract This paper discusses the current limitations of Computer Aided Design (CAD) tools and reports on the use of knowledge Based Engineering (KBE) in the creation of a concept development tool, to organise information flow and as an architecture for the effective implementation of rapid design solutions. The KBE tool along with supporting analytical solutions has been applied to the Body-In-White area of automotive design. The present methods of using CAD and Finite Element Analysis (FEA) systems do not use a unified product/ process model representation and lead to the creation of separate non-relation data models that only capture the result of the engineering process. The KBE method unifies the engineering intent into a single model that allows for existing or novel design solutions to be assessed. These design solutions can then represent themselves in the correct form to the analysis systems. Automeshing is achieved using a rule-base that meshes the model with respect to the analysis solution required, materials and processes. q 1999 Elsevier Science B.V. All rights reserved. Keywords: Knowledge based engineering; Computer aided design; Object oriented; Body-in-white

1. Introduction: the designers dilemma Engineering design is a multi-disciplined environment, a highly integrated and integrating process. Designers juggle with many, and often conflicting, constraints to balance aesthetics, manufacturability and functional objectives within a marketable product specification. The designers must transcend their perceived view of the world, to shrug-off the narrow boundaries of specialisation, while exploiting specialised technical problem solving skills and be open to external information at all stages of the design cycle. This requires the integration and utilisation of information, supplied from many sources both internal and external and in many formats. The information is constantly refined by negotiations, clarifications, discussions and evaluations, until a optimised or compromised solution is agreed. The success of a traditional design project is determined in two stages, by the effective communication of information relevant to a productive solution and then the capturing of the resultant solution or solutions. This iterative communication cycle with the results captured has inherent limitations. Designs can be produced that cannot be manufactured. The manufacturing experiences, or the experience * Corresponding author. Tel.: 1 44-1203-524721. E-mail address: [email protected] (C.B. Chapman)

of the whole product cycle, are not readily made available or captured within the design model. Competitive business time-scales constrain designers to make critical decisions without exploring alternative strategies. The designer then constrains the manufacturing engineers, limiting their ability to improve the process. Decisions taken at the early design stages may not be evident as having a negative impact on the downstream process until the product model is complete. Design decisions are made continuously during the product development cycle. In fact it has been suggested that designers make million dollar decisions every minute without ever knowing it [1]. Early decisions can determine almost 80% of the product costs (determined costs), at a stage where knowledge about the product, customer and the processes involved is low or vague, and the actual development costs (incurred costs) are low [2] (Fig. 1). Making changes to early decisions may necessitate a great repetition of the design processes steps and incur costs that increase strongly as we step through the product development cycle [3] (Fig. 2). Concurrent Engineering (CE) allows the engineering team to utilise the varied inputs, knowledge and technology to speed up product development by integrating downstream concerns as early as possible in the design process, by performing simultaneously many activities that used to be performed in sequence. For CE to work the agents in the

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

258

C.B. Chapman, M. Pinfold / Knowledge-Based Systems 12 (1999) 257–267 100% Determined Cost

Percent of 75% Product Life Cycle Cost 50%

Knowledge of Design

Incurred Cost

25%

Concept Development

Detail Development

Verification Testing

Production

Concurrent Engineering Extends Concept Development

Fig. 1. Product cost related to the design process [2].

product cycle need to be integrated with respect to the appropriate information exchange. For the purpose of creating an integrated design environment, computer tools are used to complement and assist the multi-disciplinary team, giving the ability of each member to access a common product model data structure. Today’s Computer Aided Design (CAD) systems are limited in their inference abilities and it is the duty of the knowledgeable team member to interpret and assess the impact of any change to the product model. 1.1. A need to rethink the solution CAD has evolved from simple drafting and analysis tools. Our present systems automate small and often isolated tasks within the overall engineering process. The CAD systems have been extended by programmatic means to assist the engineer in localised application areas and in the optimisation of specialist part objects. To go further, we must take a holistic view of the design. To create a design system, the design process should be modelled. Our design systems should be flexible, and not constrain the designer to work in an unnatural manner. To automate design or to increase the role CAD systems play, we must increase the level of

natural interaction and intelligence. The CAD system should play the part of a consultant, a valued team member, making decisions based on the design constraints, interacting with the free flow of the design process, suggesting alternative strategies and assisting in an optimised or compromised design solution. The system should allow for quicker design solutions, giving time to the human team member to do what they do best, be creative and search for new scenarios. The system should give back the time to be an engineer. A true CAD system should be able to draw from a company’s natural knowledge base, the accumulated experience of the workforce. The proposed system will demonstrate the ability to utilise knowledge from various disciplines at the design stage and present this in an intuitive working environment. It is interesting to note that Quinn suggests that, “In the post-industrial era, the success of a corporation lies more in its intellectual and systems capabilities than in its physical assets. The capability to manage human intellect and convert it into useful products and services is fast becoming the critical executive skill of this age” [4]. 2. Application domain: design analysis of hybrid structures Lightweight vehicle design is being driven by environmental and vehicle performance pressures. More stringent safety legislation tends to increase body weight. Customers are demanding increased non-structural content and weight for more comfort, luxury and power assistance, further increasing pressure towards lightweight body design. The decreasing ratio of the structural to non-structural mass requires higher specific stiffness, strength and energy absorption for the structural materials and the body, leading to the use of new higher-performance materials. To minimise body weight, material usage must be optimised, so that the best material combinations and construction methods are chosen for a particular purpose. This leads to the use of mixed materials structures. There is thus a need for design capability to enable efficient design development for hybrid body structures. 2.1. Body-in-white

Fig. 2. The cost of change [3].

Body-In-White (BIW) is an automotive term used to describe the structural body of a vehicle. The structural body is comprised of many sub-structures that come together to form a framework. This framework has a number of functions, to distribute the structural loads, as a mounting for the major components and sub-assemblies, to protect the vehicle occupants, providing a level of safety in the case of impact. The BIW contribution to the overall vehicle design represents the heaviest singular component and has the largest influence on many of the other vehicles characteristics. Automotive manufacturers and material suppliers see this area as a key in the battle to meet tougher environmental

C.B. Chapman, M. Pinfold / Knowledge-Based Systems 12 (1999) 257–267

259

Table 1 Structural performance Table ULSAB [6] Structural performance

Current average

Torsional rigidity (Nm/deg): 11,531 Bending rigidity (N/mm) 11,900 First BIW mode (Hz) 38 BIW mass (kg) 271 (All targets set for BIW with glass except mass target)

Future reference

ULSAB target

ULSAB result

13,000 12,200 40 250

13,000 12,200 40 200

19,056 12,529 51 205

and safety legalisation. The Partnership for a New Generation of Vehicles (PNGV) is an American government initiative that aims to provide the framework to create vehicles that have a target fuel consumption of 54.6 mpg. To achieve this the reduction of the overall vehicle weight by 40% is the key. [5]. Other initiatives such as the Ultra Lightweight Steel Auto Body (ULSAB) [6] project aim to improve vehicle characteristics, see Table 1, to compete with lighter weight materials such as aluminium and composites increasing in use within the automotive industry. Design analysis tools are needed for a much wider range of materials and constructions than hitherto. More design effort and time will be needed to ensure optimum design from this wider range of options (Fig. 3). This in turn requires a faster method for concept structure design in order to avoid the lengthening design and development programmes. The conventional concept design route must be cut short using more intelligent, automatic design development to take advantage of the established knowledge. The objectives of this research project are twofold: 1. To develop design analysis tools and methodologies for the structural simulation of new materials (specifically composites), manufacturing methods and assembly methods for stiffness, strength and impact (Fig. 4). 2. To develop a fast concept design tool which will use the existing knowledge to guide and facilitate the

development of a vehicle body structure using hybrid materials (Fig. 5). It is the second objective described within this paper, the creation of a Design Analysis Response Tool (DART) using a Knowledge based engineering system (KBE). The first objective will feed the second with rules and guidelines to fuel the KBE system. The DART system has been applied to the automotive BIW area.

3. The DART system To understand DART, we shall look at KBE, stepping though the development cycle and then the implementation used in the creation of the DART KBE system. 3.1. Knowledge based engineering KBE is an engineering method that represents a merging of object oriented programming (OOP), Artificial Intelligence (AI) techniques and computer-aided design technologies, giving benefit to customised or variant design automation solutions. The KBE systems aim to capture product and process information in such a way as to allow businesses to model engineering design processes, and then use the model to automate all or part of the process. The emphasis is on providing, informational complete product representations, captured in a product model. The product model represents the engineering intent behind the

Fig. 3. More options.

260

C.B. Chapman, M. Pinfold / Knowledge-Based Systems 12 (1999) 257–267

Fig. 4. Design analysis tools.

product design, storing the how, why and what of a design. The product model is an internal computer representation of the product design process and can contain information on both the product and processes that go to create the part. Attributes can describe geometry, functional constraints, material type and processes such as the methods required to analyse, manufacture and cost a part. The KBE product model can also use information outside its product model environment such as databases and external company programs. The ultimate goal of the KBE system should be to capture the best design practices and engineering expertise into a corporate knowledge base (Fig. 6). The KBE methodology should provide an open framework for formally capturing and defining the process of design creation [7]. 3.2. Developing with KBE To develop a KBE system we need to first acquire, represent, reason and then communicate the intent of the design process, Developing a KBE system is similar in nature to developing a solution in the design environment. The problem is first understood at a conceptual level, then decomposed into understandable working objects, developed further through an iterative process until a satisfactory outcome has been reached.

There have been many development methodologies suggested for the Knowledge Based System (KBS) domain. The methodologies have been aimed at assisting the developers to define and model the problem in question. Methods such as Structured Analysis and Generation of Expert Systems (STAGES) and Knowledge Acquisition Documentation System (KADS) (an acronym that has been redefined many times, e.g. Knowledge Acquisition Documentation System and Knowledge-based system Analysis and Design Support) [8]. These methods have normally been applied to areas other than the engineering design area, and have not been commercially used for KBE development, where systems tend to follow a traditional design life cycle pattern. Mulvenna [9] suggest that the KBS needs to be objectoriented in nature to support an iterative prototyping area such as design, and that KADS does not support this type of environment. Church [10] at the keynote speech for the British Computer Societies Specialist Group on Expert Systems in 1993, recognised the fact that such methods proved difficult for the dedicated Expert System (ES) practitioner to use and that this would hinder development by non-dedicated personnel within companies using a multiskilled workforce. The authors concur with this statement about KBS and would add that the KBE technology has the ability for widespread growth within the design environment as the technology is developed along the methods

Fig. 5. Concept design tool.

C.B. Chapman, M. Pinfold / Knowledge-Based Systems 12 (1999) 257–267

261

additional resource, who are only specifically focused on one area of a systems development. Building the KBE systems within the iterative design environment has led to the use of Rapid Application Development (RAD) techniques being employed, by the KBE developers. A typical system will evolve over time. Akman [13] suggests that the strategy, in the development of an intelligent CAD system, should be to “Plan to throw one away. You will anyhow”. The nature of the design is an exploratory adventure within a set of possibly conflicting constraints. The techniques of RAD are complementary to the designer’s natural way of working, RAD is in fact exploratory programming. The techniques advocate iterative programme enhancement, leading to an evolutionary life cycle. The KBE system starts with a skeletal system, with new modules added until a review stage is entered into. From the rapid prototype demonstration, the strengths and weaknesses are assessed and the program developed further.

Fig. 6. Corporate knowledge base.

already used quite naturally by the designer. Crowther et al [11] has recognised that using a specialised knowledge engineer (KE) to gather and represent knowledge in an engineering domain can lead to frustration due to the possible ambiguity in the problem representation. Fig. 7 shows their suggested knowledge acquisition (KA) solution, using a shared representation as a development method. The ESPRIT CIME project [12] presents a methodological approach to design support by presenting a framework for system creation aimed at the design engineers themselves. The key to the natural integration of such systems, into traditional design areas, must lie in the fact that any system can be created, modified and used readily by the workforce in the domain area, and not necessitate the use of an

Fig. 7. KA and modelling using a shared representation [12].

3.2.1. Implementation process The KBE tools are very flexible and do not dictate a particular implementation approach. However in the authors experience many applications follow a similar pattern. The aim of the KBE system being discussed is to produce an interactive application, tailored to the design of the BIW process. The DART application is designed to allow the engineer to interact through a set of menus and graphical interface tools, to specify the requirements of the desired product, (Fig. 8). Then, the knowledge base and design rules are used to construct the product within the imposed constraints. The object oriented nature of KBE development using RAD programming requires up-front work to understand the problem domain. However, implementation is accomplished by the process of incremental development, using Fig. 9 as a typical sequence of events in the development of a KBE system, we shall step through and describe the KBE development process. The first step is to state the problem. Full definition is not required as the prototype model is often used to “bring out” full and open discussions between all the personnel involved in the product life cycle. The DART initial specification and project requirements were gathered by using standard CE methods. Treating the project as a normal engineering problem solving exercise meant that all people involved in supplying rules and defining the system had the necessary skill sets. The CE team meetings were held over a period of time until a system requirement and initial layout was established. The requirement was agreed as: The concept design system will use the specified structural performance and overall dimensions to establish an appropriate stiffness distribution within the constraints of the initial style and package. It will then use relevant structural, manufacturing and material knowledge to create an initial concept body structure. The structural performance

262

C.B. Chapman, M. Pinfold / Knowledge-Based Systems 12 (1999) 257–267

User Interface

Part Libraries Conceptual Product Model Design Output Solid/Surface M odels Drawings M anufacturing Plan

FEA M esh / output Decks NC Code Product / Process Reports

Fig. 8. Architecture of a typical KBE application.

of this design will be assessed using finite element simulation, for which the system will generate appropriate finite element models and analysis input data. For the evaluation of the effects of modifications on the structural performance the system will revise the design in accordance with any geometric changes which the designer makes, and generate updated analysis input to re-evaluate its structural performance within a timescale needed to support the design decision processes. The tools will be developed for use by structural analysts and body concept engineers, see Fig. 10. After stating the problem and identifying the information required by the model, key objects were created, to form a parts library. As each of the part objects were defined they were individually tested, by creating an instance of the object. Part objects created within the KBE system form the building blocks of any model, often representing real world objects. The DART model, breaks down into six main

parts the style, packaging, structural members, joints and panels. These parts then decompose further, each stage of decomposition varying the intelligence of the objects. For example primitive objects might only know how to draw themselves, whereas higher level objects will use the knowledge base to make specific decisions regarding their shape, relationships, manufacturing process and cost. Part object terminology changes depending on the application domain. As most KBE systems are based on OOP methodology, they solve problems by defining, creating and manipulating collections of data and procedures called objects. The terminology and concepts behind OOP and KBE relate to how objects are defined, have properties assigned to them, how they interact and how they are combined to form more complex objects. The object encapsulates the data or properties, and the methods to manipulate that data into a single unit. The class is the template, and the object is specific case, (Fig. 11). An object with a particular set of values is called an instance, of a class definition. When values change that are used by the object to calculate properties or as parameters for method procedures, the object is re-evaluated. This is called demand driven computation and is a fundamental difference between OOP and conventional procedural programming. It is typical that any change made to a procedural language or CAD/CAM macro language, will result in re-computing everything, since the computations are performed in sequence. In a procedural language, a value is computed when the procedure for computing it is encountered in the sequence. In the KBE systems, values are computed only when required. This technique is called the dependency backtracking. For example if the topology changes, the model will not be recomputed until a request is made to draw the object on screen, or a calculation for the changed objects mass properties are made.

Fig. 9. KBE development cycle.

C.B. Chapman, M. Pinfold / Knowledge-Based Systems 12 (1999) 257–267

263

Fig. 10. Initial basic layout.

The method of creating objects is very similar in most commercial KBE systems. The Adaptive Modelling language (AML) from TechnoSoft [14] used within this project has the ability to create objects and write rules from templates that assist the designer in writing the programme. The object or define-class form is used to define new classes. In any define-class, the following may be specified: 1. Other classes which the new class should inherit from (superclasses). 2. The properties for the new class and their formulas (attributes). 3. The sub-objects of the new class (children). The next step was to create an initial conceptual product model. This is not a complete representation, but acted as a first draft, a blueprint of the implementation. The conceptual product model can be thought of as a schematic of the completed system. A particular design instance of a product model is described by a product model tree (Fig. 12). This structure describes the hierarchical relationships between the various components (parts and processes) of the model. The model also determines the methods of how the objects will obtain the correct information, in order to carry out their specific tasks and as to the information they will provide to other objects. This hierarchical abstraction

Object Name Property 1 Property 2 ………… Property n Location Visualisation Class Definition

Value 1 Value 2 ……… Value n Vector Draw Method Object

Fig. 11. Class and object relationship.

means the decomposition of information into levels of increasing detail [15]. The decisions made by the system to create a model will be based on the user inputs and the knowledge bases. Using the initial part library and conceptual product model as a starting point, a subset of the overall system is defined, complete with user interfaces (UI). The system is extended by increasing the part library, UI and by expanding the object class definitions. The incremental development approach means that the system can be continuously evaluated and utilised, as it is always operational (Fig. 13).

4. Current status The DART project has currently been through three prototype models and is now in the final development stage after the prototype models were used to promote discussion and as a training aid to the developer. Fig. 14 shows the initial prototype and training aid, Fig. 15 shows the agreed UI layout containing a concept layout, sketched around the imported surface style model and the resulting basic structure definition. All the solid and surface geometry requirements for the structural members and panels have been coded into part objects. The next interactive requirements are the selection and application of the joint members into the overall structural model. The solid model has the ability to be altered through the graphical interface or through altering the non-geometrical properties that constrain the BIW process model. As this is a conceptual model any change is allowed, although if a working “Best Practice” rule is violated the system will inform the current user and audit the change. Taking the structural body model into the analysis phase has been proven by automeshing the solid model within the KBE system. The meshing is done with respect to heuristic, material and analysis solution rule bases at an object level. If a structure is altered, for example a beam section the mesh automatically updates itself. Prior to the mesh being created the rule bases are checked to see if the structures material and manufacturing process are still maintained (Fig. 16). If the part cannot be created in reality

264

C.B. Chapman, M. Pinfold / Knowledge-Based Systems 12 (1999) 257–267 C ar

B od y

S tru c tu re

F loor p a n

B on n et

P owertrain

C ras h m em b ers

D oors

E n g in e

.....

E lec tric al S ys tem s

......

......

......

......

......

Fig. 12. Product model tree.

then there is no point analysing it, unless we are trying something outside the current “Best Practices”, at this point the engineer can override the system.

5. Summary This paper looks at our present CAD tools with respect to the design process and reports on the first phase of a KBE tool for the creation of the BIW structures. The DART system aims to overcome the limitations imposed by the computer centred approach in today’s design analysis process by creating a concurrent unified modelling environment. The first stage in the DART development was to understanding the BIW process. The mapping of this process and subsequent acquisition of rules and relationships was achieved by the use of standard CE methods. By bringing all the people involved in the product life cycle together and utilising their specialist knowledge to come to a common solution, through negotiation and compromise. Costs, functionality, materials, manufacturing and processes are all considered. This result of the group knowledge was then captured as a formal specification on paper. To create an integrated solution where this knowledge can be automatically processed it was necessary to capture intent behind the results in a computer system.

Fig. 13. Incremental development of application.

The next stage was to create part objects in a conceptual model that satisfied the results of stage one. Sharing knowledge: KBE can utilise the stored knowledge, making it available at design time to anyone at any stage of the product cycle. We have already stated that incompatible systems exist throughout the design process, KBE can store knowledge within its own structured “smart parts” or can be used as an interface to bring together the incompatible data sets, transforming their representation into one that can be used in an automatic fashion. The DART system uses process knowledge within its object structure and also uses external information such as a target vehicle rule database to populate the structural model. The ability to populate the object model with external data was critical in this development as the rules resulting from other research sources were being conducted in parallel with the KBE system. Smart parts: The KBE systems allow the engineer to create what are sometimes termed as “smart parts”. These parts are created in the KBE system as objects. The parts can have rules and methods applied to them, rules such as costing rules, stress rules and process rules. With the advent of OOP the capability to build and manipulate parts within a KBE system is in tune with the real world situations. Objects with knowledge are manipulated in a non-procedural way that is particularly adept at modelling the design engineering process. Object Oriented (OO) technology is forgiving, accepting that we cannot get it correct the first time and provides an easy mechanism for quickly changing and modifying the conceptual product model. The object structure has been developed with reuse in mind, this way future systems can be built rapidly. The objects are built using a programming language supplied with the KBE system and require the engineer to learn programming techniques and the particular language syntax. Although creating this product/process model in a KBE system was relatively easy, this was due to the author’s background as a designer, where decomposition and relationships are understood. The KBE vendors should not just concentrate on their particular KBE software when training new users, but treat KBE as a methodology and also give an understanding of the philosophy of OO techniques. The creation of a system is normally done using evolutionary programming techniques, but before mass acceptance by the

C.B. Chapman, M. Pinfold / Knowledge-Based Systems 12 (1999) 257–267

265

Fig. 14. Initial prototype model and training aid.

engineering community more research into the management and planning of the KBE systems should be encouraged. The main drawback of creating a KBE project is the extensive development time scales, due to the training of engineers to become users of a programming tool. The KBE vendors offer consultancy to assist at this stage, but this is expensive. If a software tool is aimed at the engineering

community it should offer Computer Aided Software Engineering (CASE) type visual programming aids. The engineers should be allowed to express themselves and not be bogged down in syntax. Modelling and representing the results (views of the world): The traditional way to create a model was to take a functional specification and give it to a design engineer

Fig. 15. UI with concept layout and initial frame.

266

C.B. Chapman, M. Pinfold / Knowledge-Based Systems 12 (1999) 257–267 Post verification is concerned with automatic model simplification to satisfy various analysis perspectives for example: • static •crash Creating meshed models directly from the concept model. Only one model exists for all variations, the unified model representation alters itself depending on the product perspective being looked at.

Add or alter target loads and conditions

Prepare the model for analysis input: •Mesh •Input decks

Fig. 16. Unified model represents all requirements.

who would draw the model in a CAD system using their experience to interpret the specification. As happens all too often within industry design models are duplicated, not due to integration issues, but due to the fact that the different engineering disciplines have a different yet valid view of the world. The KBE systems allow for easily customised UIs to be created and the product model created by the rule base to be presented to the user in various ways. There are two main “views” of the product process required in DART, a full product representation and a FEA representation supporting both stiffness/strength and impact modelling. The design model is a complete representation. The analyst normally needs to remodel the initial design. This will either be done by editing the designer’s CAD data or by creating a completely new model within the analysis software. Progressive CAD and analysis software companies have recognised the need for integration and have either integrated with other products or have modelling and analysis software within one system environment. This, however, does not go far enough and may well lead to rework. A design system must have within it the ability to represent a single product model as various alternative engineering views. There is a great deal of confusion in this area. As CAD systems create a geometric model and through data transfer or direct integration pass the model to other systems, the CAD vendors suggest that the design/analysis modelling route is automated. From understanding the design/analysis process we can see that there is a stage hardly discussed, that of simplification or model transformation. This step is critical for the engineering process and often creates extra models that have no associatively. The SANDIA Meshing Round Table 1996 [16] stated that automation of this design/analysis loop is hindered by the transformation process being a judgmental operation and that the

key issue was geometry processing, agreeing that data exchange using an international standard was not the solution. The DART system overcomes these limitations by having the model transform itself automatically depending upon on which process is required. This was possible because of the dynamic nature of the object-oriented representation of the design process. Thus a material change, such as a change from a steel member to aluminium, would entirely restructure the design and design process. This method of generative modelling allows the designer to use the KBE model and rapidly perform a series of “what-if” analyses during the concept phase, allowing a number of alternative design solutions to be considered. The preparation of the model for FEA has shown that a typical BIW structure of 250,000 elements can entail 15 man weeks of effort upon receipt of the CAD model. The time taken and cost incurred in this effort has meant that typically the analysis models are often used in a post design phase to evaluate a final design that will only be modified if the results are found to be unacceptable [17]. The DART system using an automatic analysis model based on an understanding of the processes and materials will deliver a prepared model in minutes to the analytical solution tools. This will allow the body engineers to try more structural combinations in a greatly shorter period of time, as the models are all created from a unified model description duplication and the subsequent management costs will be eliminated. Downstream processes will benefit from having available to them 3D solid geometry models and not meshed models as they have now. The models will also have the benefit of being known at concept time to be able to be made reducing costly downstream change orders. The final stages in the DART system will be completed at the end of the first quarter of 1999, where a technical system description and results will be made available.

C.B. Chapman, M. Pinfold / Knowledge-Based Systems 12 (1999) 257–267

Acknowledgements This work is being undertaken as part of a UK Government EPSRC sponsored research programme under the IMI Land Transport programme entitled Structural Advanced Lightweight Vehicle Objective project 4 (SALVO 4). The partner companies to the University of Warwick in this part of the programme are Rover Group, British Steel and Ove Arup Ltd. TechnoSoft [14] supplied the Adaptive Modelling Language used for this project and the authors would like to thank them for their support throughout this project.

[9]

[10]

[11]

References [1] D.E. Whitney, Designing the Design Process. Research in Engineering Design, 2, Springer, New York, 1990 pp. 3–13, ISSN 09349839. [2] T.A. Salmone, What Every Engineer should know about Concurrent Engineering, Marcel Dekker, New York, 1995 ISSN 08247955784. [3] G. Evans, Time for change, rapid news Europe, Time Compression Engineering Solutions, Rapid News Publications Plc, TCT House, 2 Worley Court, Bolesworth Road, Tattenhall, Cheshire, CH3 9HL, UK, 1996. [4] J.B. Quinn, P. Anderson, S. Finkelstein, Managing professional intellect: making the most of the best, Harvard Business Review 74 (March–April) (1996) 2 ISSN 00178012. [5] T.C. Moore, A.B. Lovins, Vehicle design strategies to meet and exceed goals, SAE Transactions Paper 951906, 1995. [6] High strength steel bulletin, Ultralight Steel Auto Body Demonstrates Value of Steel in the Automobile’s Future, AISI Publications, American Iron and Steel Institute, 2000 Town Centre, Suite 1900, Southfield, Michigan, USA, 1996. [7] B.C. Chapman, The design process: A need to rethink the solution using knowledge based engineering, University of Warwick, MSc thesis, February 1997. [8] G.N. Blount, S. Kneebone, M.R. Kingston, Selection of knowledgebased engineering design applications, Journal of Engineering Design

[12]

[13]

[14] [15]

[16]

[17]

267

6 (1) (1995) 31–38 CARFAX International Periodical Publishers, ISSN 09954-4828. M.D. Mulvenna, J.G. Hughes, Expert agents in knowledge-based systems—applications and innovations in expert systems, Proceeding of Expert Systems 93, The Thirteenth Annual Conference of the British Computer Society Specialist Group on Expert Systems, Cambridge, December 1993, Information Press, UK, 1999 ISBN 1-85598-021-5. C.W. Church, A business plan for knowledge inclusive systems, research and development in expert systems X, Proceeding of Expert Systems 93, The Thirteenth Annual Conference of the British Computer Society Specialist Group on Expert Systems, Cambridge, December, Information Press, UK, 1993 ISBN 1-85598-020-7. W.J. Crowther, D.R. Bull, C.A. Burrows, et al., ISBN 1-899621-04-0, Knowledge acquisition for engineering systems using bond graphs. Research and development in expert systems, Proceeding of Expert Systems 95, The Fifteenth Annual Technical Conference of the British Computer Society Specialist Group on Expert Systems, Cambridge, December, SGES Publications, UK, 1995 pp. 41–56. J. Forster, P. Fothergill, J. Angel, et al., ISBN 1-899621-04-0, DEKLARE: Knowledge acquisition and support system for redesign—research and development in expert systems, Proceeding of Expert Systems 95, The Fifteenth Annual Technical Conference of the British Computer Society Specialist Group on Expert Systems, Cambridge, December, SGES Publications, 1995 pp 23–40. V. Ackman, P.J.W. Ten Hagen, T. Tomiyama, A fundamental and theoretical framework for an Intelligent CAD system, ComputerAided Design 22 (6) (1990) 52–367 ISSN 0010-4485. Adaptive Modelling Language version 2.1.1, TechnoSoft Inc, 4424 Carver Woods Drive, Cincinnati, Ohio 45242, USA. w. Zeiler, State of the art, object-oriented hybrid intelligent CAD system, Computers in Industry, 20(2), Elsevier, Amsterdam, 1992 pp. 1–9. Analysis Models. Bench Mark, The international magazine for engineering designers and analysts, NAFEMS April 1996, ISSN 09516859. M. Pinfold, C.B. Chapman, Linking knowledge based engineering techniques to the finite element analysis of structures, Fifth International conference on Computer Aided Optimum Design of Structures (OPTI 97).