Knowledge acquisition for knowledge-based ...

Int. J. Information Technology and Management, Vol. 4, No. 1, 2005

Knowledge acquisition for knowledge-based engineering systems S. Preston* and C. Chapman Knowledge Based Product Development Lab, Warwick Manufacturing Group, University of Warwick, Coventry, England E-mail: [email protected] E-mail: [email protected] *Corresponding author

M. Pinfold and G. Smith Warwick Manufacturing Group, University of Warwick, Coventry, England E-mail: [email protected] E-mail: [email protected] Abstract: This paper is essentially concerned with the development of formal representations of knowledge required prior to the development of knowledge-based engineering systems (KBESs). Initially, the paper provides a brief introduction to knowledge-based systems (KBSs) and KBESs, stating the key commonalities and differences between the two, and presents the three main types of KBES. The paper then focuses upon knowledge acquisition, and specifically on the use of the MOKA methodology to support knowledge acquisition for KBES development. The paper critically considers the structure of MOKA with respect to workflow. This work concludes that the methodology has certain weaknesses which require addressing before it can reach its full potential as a knowledge acquisition methodology for the development of KBESs. Keywords: knowledge management; knowledge-based systems; knowledgebased engineering; knowledge acquisition; knowledge modelling; MOKA. Reference to this paper should be made as follows: Preston, S., Chapman, C., Pinfold, M. and Smith, G. (2005) ‘Knowledge acquisition for knowledge-based engineering systems’, Int. J. Information Technology and Management, Vol. 4, No. 1, pp.1–11. Biographical notes: Steven Preston is a research engineer undertaking an Engineering Doctorate at Warwick and is currently involved with research into rapid methods of knowledge acquisition, primarily concerning the KBES development process. Prior to joining Warwick, Steven obtained a BEng honours degree and a Masters degree, both from Loughborough University, and has spent a number of years working as a production engineer within the garment manufacturing industry. Craig Chapman is the Head of the Knowledge-Based Product Development Laboratory within the Warwick Manufacturing Group with a long industrial track record working within various industrial sectors providing design Copyright © 2005 Inderscience Enterprises Ltd.

1

2

S. Preston, C. Chapman, M. Pinfold and G. Smith engineering solutions in an international consulting environment. He joined WMG after working in the USA on KBE projects for companies such as Allied Signal, Boeing, Goodyear and Sangiorgio System Technology. Craig has actively participated in KBE research over a number of years and is now leading the KBE initiative at Warwick. Dr. Martyn Pinfold is a senior fellow who obtained his PhD in the area of the analysis of composite components, and has been involved in collaborative research for several years through EPSRC funded projects, and a European EUCAR funded project. Prior to joining the University, Martyn worked as Project Engineer for Mannesmann Demag Ltd. who manufacture cranes and conveyor systems. Dr. Gordon Smith is a principal fellow and director of Research Projects for the Advanced Technology Centre within the Warwick Manufacturing Group. Dr. Smith’s particular expertise is in the research of products usage with a particular emphasis on the design, manufacture and applications of advanced materials, originally developed for use in the aerospace and automotive industries. His commitment to retaining expert knowledge and its subsequent application has meant that many of the projects headed by Dr. Smith have included advanced Knowledge-Based Engineering techniques.

1

Introduction

1.1 Knowledge-based engineering In the modern manufacturing environment, increased customer expectations and greater levels of competition typically require that manufacturing organisations make significant improvements regarding the areas of the product lifecycle over which they have control. To support this requirement, the number of computer-based tools available has burgeoned, covering areas such as design, analysis, manufacturing, product data management and supply chain management. Penoyer et al. claim that it is inevitable that all the varying systems will evolve into some form of integrated system managing the entire product lifecycle (Penoyer et al., 2000). It is also suggested that Knowledge-Based Engineering Systems (KBESs) can play a key part in the development of such integrated systems, through their ability to coordinate applications, and through being able to evaluate engineering information depending upon the knowledge built into the system. KBESs can be considered as a specialised type of Knowledge-Based System (KBS). Jackson states: “A knowledge-based system is any system which performs a task by applying rules of thumb to a symbolic representation of knowledge, instead of employing more algorithmic or statistical methods.” (Jackson, 1992)

Schreiber et al. (1999) make the distinction between ‘normal’ software systems and KBSs, being that whilst all systems contain knowledge, KBSs have an explicit representation of the knowledge included within the system. In order to develop a KBS, expert knowledge considered to be relevant to the system is collected, formalised, and then usually incorporated within a computerised application. System users then can make use of this knowledge to solve problems within that particular field. A KBES essentially

Knowledge acquisition for knowledge-based engineering systems

3

is a KBS used for engineering purposes. However, KBESs contain elements making them particularly suitable for the solution of engineering problems. They have the ability to interact with other engineering applications or have engineering biased functionality built into the development software. A typical example of this is the solid geometry representation capability built into KBES development software such as the adaptive modelling language (AML) from Technosoft (http://www.technosoft.com). The ability to interact with third party software is especially important when using KBE as a support tool for concurrent engineering (CE). There are many computer-based applications supporting the product lifecycle process; however, these software packages and their users can often be considered to be independent elements within the process chain. Integration of the elements is usually through the manual transfer of data via some form of file transfer protocol, typically comprising such forms of data as CAD drawings, text files and spreadsheets. Nevertheless, there is often little appreciation within an element of issues affecting the others, so although each element may be considered as being efficient at carrying out its own task, the entire product lifecycle process is often far from being as efficient as it could be. The requirement for CE is to consider simultaneously (as far as is practicable) all elements of the product lifecycle in order to significantly compress the product development process; combining expertise from such areas as design, manufacturing, inspection, finance, and marketing. KBE has the potential to support this in two ways: firstly through direct integration with third party software applications and the automated management of the information flows between the applications, and secondly through the collection and linking of rules associated with the different product lifecycle disciplines. For example, rules regarding costing can be incorporated into a system, providing a designer with some immediate appreciation of how costs are influenced by their decisions (Technosoft Inc., http:// www.technosoft.com).

1.2 KBES classification Each KBE application is unique, a bespoke solution designed specifically to address a particular problem. Penoyer et al. (2000) have classified a number of different types of KBES depending upon the kind of problem solving approach they apply.

1.2.1 Generative systems These automatically create detailed geometry based upon embedded rules, constraints and user inputs. The system will have built in rules about how to construct the particular geometry depending upon the set constraints and required user input. As an example of this, Jaguar has developed a generative KBES for the automated design of vehicle bonnet stiffeners (Kochan, 1999). This part was chosen for KBES development because the design of the bonnet stiffener is largely rule driven and determined for the most part by the Jaguar’s manufacturing capabilities and the geometrical constraints set by the engine and the outer bonnet. Using the KBES entails the designer routing the underlying geometry of the stiffener around the constraints set by the engine and bonnet (Kochan, 1999). Detailed panel geometry is then automatically generated around the route plan specified by the designer. As manufacturing rules regarding the pressing of the stiffener panel are built into the system, the designer is fully confident in the manufacturability of the design.

4

S. Preston, C. Chapman, M. Pinfold and G. Smith

1.2.2 Advisory systems These are capable of design evaluation during the design process itself. Systems exist which evaluate the design of injection moulded plastic parts. For example, the system can compare the design against the knowledge base to assess it in terms of manufacturability, strength or cost. KBESs can be extended in this respect for use as a diagnostic tool. Liening and Blount (1998) discuss the use of KBE in such a way for the analysis of brake failure in the aircraft industry. The knowledge base can be interrogated in order to determine the source of any problems under investigation (Liening and Blount, 1998). The object-oriented nature of KBE allows easy expansion of the knowledge base as information about system failure is collected over the lifetime of the product.

1.2.3 Selection systems Selection systems use the knowledge contained within the system to assist the user in selecting from a number of similar options. This could be a material selection system, for example, or perhaps a method of selecting the correct off-the-shelf component from a large catalogue. Output generated from such a system may include items such as how the selection influences cost or lead times, and as such could be an invaluable tool for sales personnel, or engineers generating project quotations (Penoyer, 2000).

2

KBES development

Developing a KBES requires a significant amount of time and effort spent in capturing the required knowledge base used to underpin the system. However, once knowledge is captured within the KBES, it can be used repeatedly for the generation of new designs. For the most part, KBE applications developed to date have been concerned with the automation of routine and variant design. Essentially the system models a generic design solution, and the system user is able to create an instance of the design by entering the required input parameters (Pinfold and Chapman, 2001). So, once the system has been defined and implemented, the generic KBE model can be used repeatedly to rapidly develop design variants, either manually or as part of an automated loop. Benefits resulting from this are that designers are typically able to evaluate a greater number of design solutions, and can potentially achieve significant reductions in the amount of time taken to identify a solution. As an example of the potential offered by KBE, BAE Systems developed an aircraft nose design system (Kochan, 1999). This was used to evaluate over sixty nose variants in the same time taken to evaluate two designs using traditional methods (Kochan, 1999). Well designed systems will have elements of architecture, knowledge and code that can be transferred with little or no modification into new systems, thereby promoting the reuse of knowledge and helping to justify the original system development expense. However, the reuse of knowledge requires an effective knowledge management (KM) strategy. It is important that future system developers are able to access this knowledge rapidly, and that it is provided in a form that is readily understandable, otherwise the wheel continues to be re-created, which is often the case today.


5

2.1 Knowledge acquisition A key element in the development of any KBES is the knowledge acquisition process. The purpose of knowledge acquisition with respect to KBE is to develop an explicit model of the knowledge system in a form able to be built into a computer-based system. This process not only involves the collection of knowledge, but also its explication and formalisation (Cooke, 1994). Originally, it was popular to consider knowledge acquisition as a ‘data mining’ activity, trying to make explicit exactly that which is contained within the expert’s head. However, knowledge acquisition is now more commonly looked upon as a modelling exercise (Schreiber et al., 1999; Cooke, 1994), with the knowledge engineer attempting to develop a system, based upon expert knowledge, in order to satisfy the goals determined by the project stakeholders. This formal representation of the knowledge should also lend itself readily to inspection. This is in order to facilitate verification of the knowledge system, and to ensure that the knowledge is readily available for reuse in any future systems. As part of this, it is important that all the project stakeholders have a shared common understanding of the language used to describe the knowledge within the system; one that is unambiguous and hence not open to misinterpretation.

2.1.1 Knowledge collection The first stage in any knowledge acquisition process is the collection of knowledge. Initially this may be knowledge about the knowledge; the knowledge engineer developing the system is unlikely to be an expert in the area under development, and therefore needs to gain an appreciation of the knowledge domain, ideally from all the KBES project stakeholders. Bell and Hardiman (1989) state that it is of prime importance to include the system users in the knowledge collection phase. A common problem with knowledge collection is that the knowledge engineer becomes overwhelmed by the sheer amount of available information. Developing user participation at an early stage not only provides the engineer with goals around which to focus the knowledge collection effort, but also generates user buy-in to the KBES project, enhancing the prospect of successful implementation (Bell and Hardiman, 1989). Cooke (1994) classifies the collection of information from a human source as knowledge elicitation; the most common knowledge elicitation technique being interviewing. It is recommended to have open unstructured interviews to begin in order to get a feel for the project area, followed up by planned structured interviews in order to fill in detailed knowledge (Schreiber et al., 1999; Cooke, 1994; Bell and Hardiman, 1989; Cordingley, 1989). Other techniques for knowledge elicitation may be more suitable depending upon the type of knowledge being collected and the knowledge sources available. Cooke (1994) provides a thorough collection of available techniques, whilst Schreiber et al. (1999) provide a more compact list, focussing upon those techniques supported by the PCPACK knowledge engineering software package; in addition to interviewing these include: protocol analysis (observation of actions, with explanation by the expert), laddering, concept sorting, and the repertory grid. During knowledge elicitation, audio recording is highly recommended (Bell and Hardiman, 1989). This not only frees up the elicitor from note taking, thereby allowing them to concentrate upon leading the elicitation process; but it also ensures that the elicitor has a full record of the knowledge to refer back to. In addition, non-human sources are often a valuable source of

6


knowledge, particularly in situations where detailed records are kept, such as a laboratory. However, this type of knowledge still often requires validation by the experts before it can be included within the system (Cooke, 1994). In future, as KBE programming environments develop and become more intuitive to use, there is also potential for direct input of knowledge into the system, perhaps directly by the expert, or may be with the expert in tandem with a knowledge engineer. Such programming environments are desirable as they have the potential to significantly reduce system development time. However, such systems will still require documenting if they are required to conform to an organisational KM strategy, and as a result it is likely that the methods of documenting and modelling of the system knowledge will need to be developed further in order to support rapid system development.

2.1.2 Knowledge formalisation Upon collection, the raw knowledge requires organising into an appropriate form in order to facilitate the software development phase of the project. This enables the developer to identify the key elements of the knowledge, and to structure them in such a way that is suitable for coding. In addition to developing a structure for the knowledge, it is also important at the beginning of this stage to formalise and verify the language used to describe the knowledge system; perhaps to develop definitions of those knowledge concepts which may be open to misinterpretation. Essentially, Uschold (1998) defines a collection of such definitions, concerned with a particular knowledge area, as the ‘domain ontology’.

2.1.3 Knowledge acquisition methodologies A number of different knowledge acquisition methodologies for KBSs are available. Of these, MOKA (methodology for knowledge-based engineering applications) has been created specifically concerning KBES development. MOKA draws upon and complements a number of existing system development and representation methods, including the CommonKADS methodology, DEKLARE, and the unified modelling language (UML) amongst others. MOKA is primarily concerned with the organisation of engineering knowledge and the development of knowledge models prior to the system coding stage, developing initially an informal model around which the knowledge engineer can begin to structure the system knowledge, then refining this into a formal model from which the software code can be developed (Stokes, 2001).

2.1.4 MOKA knowledge models Figure 1 shows the three sub-models which make up the MOKA knowledge model. In addition to the informal and formal models is a neutral language knowledge model. This provides a link between the UML-based formal knowledge model and the final software code, the purpose being to develop a model which can readily be translated – perhaps with a high degree of automation – into the KBE development platform source code. MOKA recommends the use of Extensible Mark-up Language (XML) in order to build the neutral model, although it does not provide a detailed methodology as yet for developing such a model, because the direct import of XML-based models is not currently supported by the various KBE development system vendors (Stokes, 2001).

Knowledge acquisition for knowledge-based engineering systems Figure 1

7

MOKA knowledge models

2.1.4.1 The informal model The informal knowledge model is structured upon what MOKA terms ICARE forms. This acronym stands for Illustration, Constraints, Activities, Rules and Entities, and is a sub-methodology for the classification and linking of the knowledge gathered during the collection phase (see Figure 2 for an example of one of the forms) (Stokes, 2001). These forms provide a comprehensive and straightforward – if perhaps long-winded – approach to placing structure upon the raw knowledge. This is done by placing the knowledge into the appropriate form depending upon its type, then defining the links between the individual knowledge elements. Whilst they can be completed in paper format, some form of software tool would greatly speed up this process, particularly when checking the validity of the model. MOKA also considers the informal model as being particularly suitable for inclusion into an organisational knowledge management system. Figure 2

Example of a MOKA entity form (Stokes, 2001)

8


2.1.4.2 The formal model The next stage is to use the informal model to develop a formal knowledge model, which is made up from two parts, the product model, and the design process model (Figure 3). The MOKA Modelling Language (MML) has been developed in order to notate the formal model; MML being an extension of UML. UML is particularly suitable for this task as it has become a recognised standard for the design and analysis of object-oriented software; several of the dedicated KBESs being written using some form of object-oriented programming language. MML extends UML primarily through the use of stereotypes. These are generic classes of objects defined by MML in order to represent the different aspects of the knowledge stored in the informal model. Examples of stereotypes include a product class, an assembly class, a material class, and a manufacturing process class. MML also defines product (Figure 4) and design process meta-models, displaying the relationships between the stereotypes. As an extension of UML, the system developer is free to extend MML to suit their own purpose should the need arise (Bell and Hardiman, 1989). Figure 3

The MOKA formal model (Stokes, 2001)

Figure 4

Structure view from MOKA product meta-model (Stokes, 2001)


3

9

Discussion

MOKA provides what appears to be a solid foundation for the acquisition of knowledge required for the development of KBESs. The use of ICARE forms in the informal model, and the product and design process formal models, provides the user with templates specifically suited for the product design process, unlike more generic knowledge acquisition methodologies. Models created using MOKA are not only suited for the development of KBESs, but also for the archival of an organisation’s engineering knowledge, and they also provide an opportunity for rigorous design analysis. However, whilst MOKA may provide robust models from which KBESs can be developed, the methodology may not always be the most appropriate way of supporting the KBES development process. There is a constant drive to reduce product development times, and KBES developers are marketing their products as being suitable tools with which to achieve this aim. As a generally object-oriented technology, KBES development seems to be ideally suited to Rapid Application Development (RAD) methods, such as Rapid Prototyping (RP) and Extreme Programming (XP), often used to support the rapid development of object-oriented software (Dennis and Wixom, 2003). These methods typically take an iterative approach to software development, bringing a significant part of the software development process within the knowledge acquisition cycle, using the results to instigate further knowledge acquisition if necessary. This approach appears to be supported by Cordingley (1989), who considers knowledge acquisition to be pervasive throughout the KBS lifecycle, beginning when the KBS is first considered, and potentially continuing past the implementation stage as the KBS is refined through use. MOKA does promote an iterative approach to the development of the informal model, but overall MOKA appears to promote a waterfall approach to systems development, ideally requiring the completion of one stage prior to advancing to the next. Whilst the methodology provides a mechanism for the mapping of the informal knowledge model to the formal knowledge model, as a result of MOKA wishing to be a system independent methodology, there is no detailed mechanism for the mapping of the formal knowledge model to that built into the software itself. Overall, this does provide for a structured approach to KBESs development, and one that may be more suitable when considered from a project management perspective, although, in the author’s experience, leaving the bulk of the coding to the end of the project increases the risk of delay due to unforeseen programming and system integration problems. These issues could possibly be ironed out at an earlier stage, through the prototyping of elements of the software concurrent with the collection of knowledge. MOKA is a platform independent methodology, suitable for use with any of the KBE development systems currently on the market, and as an independent methodology this can be considered as a sensible strategy to take. However, it is arguable that the knowledge required to model aspects of the knowledge domain using a KBES development tool is an integral part of that same knowledge domain. Therefore, this should be combined with the product knowledge, perhaps as some extension to the design process model and product model shown in Figure 2. For example, the underlying methods used to create product geometry within the KBE development system may bear little or no resemblance to that used to create the geometry using an organisation’s traditional methods. To the end user, this may be of little or no concern as the output is the same, but to the system developer this knowledge is as important as any other aspect of the design process model. In addition, methods of best programming practice need to

10


be recorded in order to develop a library of methods that future developers can draw upon in order to build systems with a greater degree of confidence. Such knowledge may not be integral to the product knowledge model, so therefore should be kept apart from it. However, this knowledge should be available to the knowledge engineer during the development of the formal model in order to promote the use of best practice. In the author’s experience, the development of KBESs is generally a mapping process between the product knowledge base (the informal model) and the KBE development system knowledge base (which typically comprises the system developer’s own knowledge plus the help and advice from colleagues and the vendors of the KBE development systems). The development of the formal knowledge model is also influenced heavily by the KBE development tool used, because the use of a KBE development tool, and the capabilities it conveys, has to a certain extent redefined the product development process. To attempt to develop a system independent formal model potentially limits the benefits which may be achieved through developing a KBE application.

4

Conclusion

In its simplest form, the aim of KBES development is to create software, based upon an explicit representation of engineering knowledge, which achieves a pre-defined task. It is not primarily a knowledge management exercise, although the output from the project may well be used for that purpose as an added benefit. The development of the informal knowledge model should be purely to support the development of the formal model, alongside any other object-oriented software development tools being used, and should be considered to be complete when the system is working as specified by the project stakeholders. MOKA provides the KBES developer with a structured approach to the modelling of engineering knowledge. The development of the informal model in particular, provides a description of the product and design processes involved, which is particularly suitable for communicating the knowledge model due to it typically being written in a natural language format. Although currently the ICARE forms are limited to textual and 2D graphical information, the use of software tools for the compilation of the informal model in the future will open up the possibility of the inclusion of dynamic content such as navigable 3D solid models, audio data and video data. At this stage, it is also important to address the issue of coherence of information, especially when compiling information from a wide number of sources. Some form of ontological support is required at the informal modelling stage to ensure that the concepts defined by the model are unambiguous. Looking at increasing deployment speed, reducing the risk of project failure, and optimising the potential offered through the use of dedicated KBES development tools, it is suggested that an iterative approach may be more suitable to the development of the knowledge models. This way code can be prototyped and developed as the knowledge is collected, providing a dynamic feedback loop enabling the expert to check whether the software model fits well with their own understanding of the area. In addition to this, to assist in the rapid development of the model and the code, it is suggested that the knowledge engineers and software developers should have access to a knowledge base specific to the organisation and the development tools being used. This should promote


11

alignment between the knowledge models and the software code, and enable the adoption of best practice through the project. Also there may be no requirement to embark upon a formal UML-based modelling stage, especially for smaller scale KBESs which could be modelled directly from the informal model. Obviously this is a slightly less rigorous approach, which may not be applicable to some companies or industries, but which may lead to significant reduction in development time if employed.

References Bell, J. and Hardiman, R.J. (1989) ‘The third role – the naturalistic knowledge engineer’, in Diaper, D. (Ed.): Knowledge Elicitation: Principles, Techniques and Applications, Ellis Horwood Ltd., Chichester, UK. Cooke, N.J. (1994) ‘Varieties of knowledge elicitation techniques’, Int. J. Human-Computer Studies, Vol. 41, pp.801–849. Cordingley, E.S. (1989) ‘Knowledge elicitation techniques for knowledge-based systems’, in Diaper, D. (Ed.): Knowledge Elicitation: Principles, Techniques and Applications, Ellis Horwood Ltd., Chichester, UK. Cordingley, E.S. (1989) ‘Knowledge elicitation techniques for knowledge-based systems’, in Diaper, D. (Ed.): Knowledge Elicitation: Principles, Techniques and Applications, Ellis Horwood Ltd., Chichester, UK. Dennis, A. and Wixom, B.H. (2003) Systems Analysis Design, 2nd ed., John Wiley & Sons, New York. Jackson, P. (1992) Introduction to Expert Systems, 2nd ed., Addison-Wesley, Wokingham, UK. Kochan, A. (1999) ‘Jaguar uses knowledge based tools to reduce model development times’, Assembly Automation, Vol. 19, No. 2, pp.114–117. Liening, A. and Blount, G.N. (1998) ‘Influences of KBE on the aircraft brake industry’, Aircraft Engineering and Aerospace Technology, Vol. 70, No. 6, pp.439–444. Penoyer, J.A., Burnett, G., Fawcett, D.J. and Liou, S-Y. (2000) ‘Knowledge based product life cycle systems: principles of integration of KBE and C3P’, Computer-Aided Design, Vol. 32, pp.311–320. Pinfold, M. and Chapman, C.B. (2001) ‘The application of KBE techniques to the FE model creation of an automotive body structure’, Computers in Industry, Vol. 44, pp.1–10. Schreiber, G., Akkermans, H., Anjewierden, A., De Hoog, R., Shadbolt, N., Van de Velde, W. and Wielinga, B. (1999) Knowledge Engineering and Management: The CommonKADS Methodology, The MIT Press, Cambridge USA. Stokes, M. (Ed.) (2001) ‘MOKA: methodology for knowledge based engineering applications’, Bury St Edmunds, Professional Engineering Publishing, UK. Technosoft Inc. (2003) The Adaptive Modelling Language. A Technical Perspective, http://www.technosoft.com/docs/AML-Technical-Perspective.pdf Uschold, M. (Ed.) (1998) ‘Knowledge level modelling: concepts and terminology’, The Knowledge Engineering Review, Vol. 13, No. 1, pp.5–29.