Achieving benefits from knowledge-based engineering systems in the longer term as well as in the short term.

Transcription

1 Achieving benefits from knowledge-based engineering systems in the longer term as well as in the short term. Phillip Sainter, Keith Oldham, Andrew Larkin Knowledge Engineering & Management Centre, Coventry University, Priory Street, Coventry, West Midlands, CV1 5FB, UK. {phil.sainter, keith.oldham, Abstract The deployment of knowledge-based engineering systems is on the increase within engineering industries. Therefore, there is a need to ensure the technology is used correctly and to provide the user with all the possible benefits that the system can offer. This paper looks at how product knowledge can be managed within knowledge-based engineering systems to ensure that the knowledge retains its value and usefulness during the product lifecycle. The paper will provide a product knowledge management scheme for the development and management of product knowledge within knowledge-based engineering systems, thereby extending the benefits of these systems into the longer term. Keywords Product knowledge management, knowledge-based engineering, knowledge modelling. 1 Introduction In the age of international markets and increased worldwide competition, many enterprises are looking for new ways to gain and maintain competitive advantage. One such way is the use of their intellectual capital. Since most companies have access to the same processes, cost management techniques and material management systems, the only thing that separates them is the knowledge held within each company. Research conducted by Kock et al [Kock, McQueen, Corner, 1996] has shown that, in a typical company, approximately ninety per cent of all exchange processes involve the exchanging of data. Approximately seventy-five percent of this data is classed as information or knowledge. This percentage is set to rise, due to the advances in expert/knowledge-based technologies and an increase in their use. As part of this trend, the deployment of knowledge-based engineering (KBE) systems has been on the increase within engineering industries. A KBE system can be regarded as a type of knowledge-based system that performs tasks related to engineering. KBE systems do not express designs with specific data instances, as ordinary CAD systems do, but with sets of rules that enable the design to apply to large classes of similar parts. A typical rule may take the form of IF x THEN y, where x is the condition and y is the reaction to the condition. These rules are used to express various types of knowledge, information and data within a KBE application. These knowledge types include class and attribute definitions, part relationships between components, geometric specifications, configurations, mathematical expressions and application definitions. The functionality of these systems provides benefits during the design phase of many products, such as the reduction of product introduction leadtime, the introduction of DFx (Design for x) techniques into the design process, and automatic consideration of legislation and national/international standards. The reduced lead-

2 time encourages engineers to explore additional product options, which results in better designs. However, if we look at the traditional method of KBE application development, we see that it occurs largely in an ad hoc manner within a company. This ad hoc development gives the KBE application a limited life-span compared to the product lifecycle. Also with an ad hoc application development the management of the underlying knowledge is not fully considered, thereby allowing the design rationale of the product to be lost during the development process. So if a new product is developed using the existing application, this application may require re-coding, incurring cost and increased product introduction leadtime that could be avoided. So it can be said that this ad hoc KBE application development, although giving short-term benefits of using KBE, also generates longer-term problems. These longer-term problems include: Knowledge loss, due to poor modelling of the application; Knowledge loss, due to inadequacies in the development language used; Knowledge misuse, due to the wrong kind of applications being developed; Increased maintenance costs, due to non-standard development of applications; Knowledge under-utilisation, due to the inability to share and reuse the knowledge both at human and computer level. The authors of this paper believe that developing applications in an ad hoc manner is not an effective method of product knowledge management. There is a need for a structured methodology and framework to allow the short-term benefits of knowledge-based engineering to be extended to the longer-term. In order to achieve this, it is important to address a number of key issues, such as application development, assessing the value of knowledge, knowledge coverage, knowledge reuse and sharing, company culture and application management. These issues are discussed in greater detail in Sainter et al [Sainter, Oldham, Larkin, Murton, Brimble, 2000]. Both technology and human techniques used in the KBE application development and management are covered. From the investigation of these issues, a suggested product knowledge management scheme has been developed. The following two sections look at the scheme in greater detail. 2 Core solutions to longer-term KBE issues To manage product knowledge within a knowledge-based engineering system, it is necessary to address the issues that have been mentioned above. This will solve many of the longerterm problems of KBE systems. It is clear that these issues relate to and affect each other, such as application development and application management, where the choices made at the development phase affect the later management of the application. Thus one solution may solve or affect more than one issue. It is only natural to try to solve all of the issues at once and find the common links between issues. Table 1 lists all of the issues and places a possible solution or combination of solutions next to the issue. From Table 1 we can see that there are four solutions, which can be used in different combinations to solve any one of the issues. However, we can also use all four solutions simultaneously to solve all of the issues and problems that relate to the long-term use of KBE systems. The remainder of this section looks at each of the four core solutions in greater detail. These solutions form the basis of the proposed scheme for the management of the product knowledge that is discussed in greater detail in section 3.

3 2.1 Methodology Issues / Core solutions Methodology Language Management Framework Development Management Knowledge Coverage Product Knowledge Reuse and Sharing Human Environment Knowledge Value Table 1: Product Knowledge Management Issues and Solutions A methodology is a set of instructions and guidelines on how to perform a complex procedure. It details the different tasks, how they should be performed, in what order and how the work should be documented. It might take longer to develop an application using a methodology, however the benefits of using one outweigh the increased time required for development. A methodology is vital for quality, reusability and maintainability of an application. A knowledge engineer may also benefit from using a methodology [Lovett, Ingram, Bancroft, 1999]: Knowledge engineers can benefit from the knowledge of experts in the field; Knowledge engineers who are new to the field will not omit essential tasks; Standardised procedures mean that the work of an individual can be more easily followed by another; It may be possible to recruit staff trained in a required methodology; s, or parts of applications, can be more easily adapted and reused; Increased ease of maintenance. The time and effort devoted to the maintenance of most applications is greater than that needed for the original development; Project management is greatly facilitated, as recognised stages and activities can be identified and if necessary allocated to development team members. There are a number of different methodologies available for KBS systems, however, there are only a small number of methodologies for the development of Knowledge-Based Engineering systems. These methodologies include the MOKA and KOMPRESSA methodologies. The MOKA methodology is currently under development as part of the ESPRIT MOKA (Methodology and tools Oriented to Knowledge based engineering s) project. The MOKA project is developing a standard methodology for the development and maintenance of KBE applications. It is hoped that the MOKA project will allow the lead-time for the development of an application to be reduced by up to 25% [Callot, Kneebone, Oldham, 1998]. Also, once the product knowledge has been acquired, it will be stored in a manner that would allow product knowledge updates, reuse and sharing using the MOKA software tool, which is also being developed within the project. Further information about the MOKA project can be found at the MOKA website (

4 The KOMPRESSA (Knowledge-Oriented Methodology for the Planning and Rapid Engineering of Small-Scale s) methodology, as the name suggests, is designed for the development of small KBE systems, of the type that would benefit small organisations [Lovett, Bancroft, 2000], whereas the MOKA methodology is aimed more at larger scale KBE systems. So the nature of the company and scale of the application would decide on the methodology that is best suited for its needs. 2.2 Knowledge Representation Language Current KBE systems use a set of development languages that are based upon an objectoriented representation of products and processes. The development languages are normally a top-level language built upon the LISP programming language. Most engineers are not familiar with either object-oriented programming or the LISP language. So if a standard language could be developed with engineers in mind, there would be less chance of errors in interpretation (by the engineers) if the terms of the language matched more closely those with which engineers are familiar. An additional benefit resulting from the development of a neutral format/product knowledge representation language is that engineers will be only expected to learn and develop skills within one language. This is discussed further in section 3. This neutral format should also have the capability of representing a greater degree of product knowledge than the existing vendor-dependent representation languages e.g. design rationale, which is not presently modelled. The neutral language would also improve the management of the application, since one could have a framework that allows knowledge to be moved from system to system and be stored in a central neutral knowledge repository, where the company s applications would be stored together. The framework would then be used to distribute the applications throughout the company. The framework will be discussed in the following section. There are a number of different languages that could be used to represent product knowledge in a neutral form, such as EXPRESS (ISO ), PIF (Process Interchange Format) and KIF [Sainter, Oldham, Kneebone, 1998][Uschold, Jasper, Clark, 1999]. In work conducted at the Knowledge Engineering and Management Centre, EXPRESS has been used to represent product knowledge for reuse and sharing. The benefit of using STEP/EXPRESS as the basis for a Product Knowledge Representation Language is that both current KBE development systems and STEP use an object-oriented representation and they both allow a design object to be defined as a collection of attributes. The major difference between STEP and a current KBE representation language is that STEP is designed to represent design data, whereas a current KBE representation language is designed to represent design knowledge. It is believed that this gap between the two language types can be bridged to form a standard Product Knowledge Representation Language [Sainter, Oldham, Kneebone, 1998]. 2.3 Framework A framework is the structure or network of computers that allows the product knowledge to flow around a company or enterprise. The framework has also to provide a stable and standard interface to the neutral format and the target systems. The framework can be centred around a knowledge repository (Figure 1). There are a number of different levels of application deployment available, such as: 1. Standalone applications 2. Linked applications within a company 3. Linked applications within and between companies.

5 Knowledge Repository Figure 1: Basic Framework The use of a framework allows the applications to be linked within the company and between companies. Having all the knowledge and KBE applications at a central knowledge repository enables more effective knowledge management, such as application maintenance that can update the application in the repository knowing that whenever the next person uses the application, they would be using the updated version. The current trend towards integration of the supply chain will require the increase of data, information and knowledge sharing between different companies within the supply chain. Therefore an increase in the need for the reuse and sharing of product knowledge can be expected, the framework would naturally be expanded to include the supply chain. However, the sharing of knowledge raises issues, such as intellectual property and the intangible assets of the companies involved. Therefore it is important that agreements between companies are made before actual knowledge sharing can take place. The requirement for sharing product knowledge has been added to by the speed of the modern manufacturing world with advances, such as mass customisation, i.e. the process of allowing products to be configured for the customer, taking advantage of product modularity and part commonality. Mass customisation is the fastest growing segment of the manufacturing sector, in the UK it is worth approximately 22 billion a year. The positioning of the UK OEMs and their supply chains demands that the performance of internal and external engineering functions be greatly improved in this respect. [Kneebone and Oldham 1998]. 2.4 Management There are two aspects to management, namely management of the application and of the people involved (stakeholders). The management of the KBE application is improved through the use of a methodology, neutral language and framework. This combination allows maintenance to be carried out with relative ease, since the structure of the application would be the same, the language in which the application is expressed will be the same and there would be a framework in place that would allow easy access to the application. The management of the people that will be using or giving their knowledge to the application is a harder problem to solve, since no two organisations are the same, just as no two office environments are the same. It has been stated by Guptara [Guptara 1999] that most barriers to success with knowledge management are ingrained within the culture and structure of organisations. He also states that knowledge management needs to be accepted as a key success factor of the overall business strategy and it must therefore be institutionally recognised. It could then be developed into a fear of not sharing knowledge, rather than the current knowledge hoarding mentality. The phrase Knowledge is Power would be rewritten Sharing Knowledge is Power.

6 To achieve cultural change within an organisation is a complex long-term task and even then success is not guaranteed. However for the short-term there needs to be an informationsharing exercise, showing the benefits to the company of knowledge management and the benefits that everyday users would receive from the knowledge-intensive system. 3 Product Knowledge Management Scheme The product knowledge management scheme is the combination of the core solutions discussed above. This section assumes that the decisions about the core solutions have been completed and are in place. For example you would be using a methodology for the acquisition of knowledge. In order to achieve the most out of any product knowledge management scheme the underlying structure (core solutions) would need to be standard. This enables the development of Virtual Enterprises where knowledge can be controlled, reused and shared with partners and throughout the supply chain. The core solutions should be introduced in the following order: 1. Management 2. Methodology 3. Language 4. Framework The reason for introducing management first is that this is the core solution that would require the most time to produce any benefits. The methodology is introduced next so that knowledge can be acquired and documented in a standard way for future application development, thereby giving the knowledge engineer the benefit of the new product knowledge scheme as soon as possible. The introduction of a neutral language without the framework would allow knowledge to be shared and reused within different systems, but the transfer would require manual intervention. However this is not ideal, so the simultaneous introduction of the framework is recommended, which would allow ease of movement of the product knowledge around the enterprise. The structure of the framework is dependent upon the language chosen. The work conducted at the Knowledge Engineering & Management (KEM) Centre, Coventry University uses a neutral interchange format that is based upon a vendor-independent knowledge representation language, in this case, EXPRESS (ISO ) [Sainter, Oldham, Kneebone, 1998]. We have taken EXPRESS models from the STEP standard, adapting and adding to them to allow product knowledge to be represented in an unambiguous, stable and clear manner. When using a neutral interchange it is necessary to have an expressive neutral interchange format and have two-way translators between the neutral format and each target system. In the case of the work conducted to date at the KEM Centre, the knowledge to be shared between the various systems is written in the original KBE system, not in the neutral format. The neutral format is only used as an intermediate representation of the knowledge. Once the standard product knowledge handling system is in place, the lifecycle of an application would take the following steps. 1. Problem Identification 2. scoping, selection and feasibility assessment 3. Problem definition 4. Software selection 5. design and development of generic applications to solve the problem

7 6. Commissioning, testing and maintenance 7. Use, Reuse and Share the KBE application and the product knowledge held within it. Maintenance of the application and product knowledge will be conducted throughout the lifetime of the application. Once we have an application using the core solutions, we are able to use, reuse and share the product knowledge throughout the company and in some cases the supply chain. The ability to reuse and share product knowledge is seen as key to the integration of KBE into the wider activities of the company. Product knowledge reuse and sharing is different from data exchange. It is more complex in a number of ways, such as the wide variety of issues covered, the complex relationships between the issues and the dynamic nature of the knowledge. Currently, reuse and sharing activities have to be done by manually re-coding from source to target all the rules within the knowledge base. This is time consuming, error prone and the exact meaning of the knowledge may be lost during the translation process. At the moment, reuse and sharing of product knowledge activities would prove costly to implement within a company, since there is a lack of standardisation within KBE applications, platforms and systems. To enable automated product knowledge reuse and sharing within an enterprise there needs to be a standardisation of how the application is developed, structured, maintained and the ontology used. It should also be noted that KBE is not suitable for all types of applications, and it is easy to underestimate the amounts of knowledge needed for a simple task or product. The vast amounts of knowledge required for products has led to the changing structures of KBE applications to produce smaller generic sub-applications that can be taken and used in new product applications when needed, thereby reducing the lead-time required to develop new applications when a new product is being developed. This use of generic sub-applications also makes the maintenance of an application easier and allows the application to be reused and shared with ease. It should also be noted that the proposed neutral format is more expressive than the vendordependent knowledge representation languages, meaning that the rules are still represented but the rationale behind the rules and the product will also be represented. Work is being conducted at Coventry University that would allow access to this design rationale via a browser, permitting the user of the KBE application to understand fully what the application is doing and why. This would facilitate the reuse and sharing of product knowledge at a human level, rather than being locked in at the computer level. As already mentioned within this paper, there is also the possibility that KBE application development may be conducted in this neutral format. However the neutral format might not lend itself to manual coding, this is largely down to the human readability of the language. The neutral format is used for the interchange of knowledge between systems and does not lend itself to computer-human interactions. Therefore automatic code generation may offer the solution to neutral authoring of the KBE applications in the neutral format, such as the MOKA software tool. 4 Conclusions The future of knowledge-based engineering systems is promising. However, to ensure that this promise is fulfilled, there is a need to standardise the management of the product knowledge used. It may be seen that the standardisation of the KBE application and the product knowledge management could be more expensive than the current ad hoc application development, but it is believed that the longer term benefits will outweigh this extra investment at the development stage of the KBE application. These longer-term benefits include the ability to share and reuse product knowledge within an enterprise; the development of a company knowledge repository and the storage of intellectual capital of the company.

8 The knowledge repository is a benefit of having a neutral interchange format, this allows a framework similar to that shown in Figure 1 to be developed. The knowledge repository will give the company a wide range of benefits, since knowledge held within a repository would be able to be developed, secured, distributed and maintained throughout the company or through the supply chain, where the controlled sharing of knowledge could be used for the benefit of the company and the suppliers. Therefore when developing the KBE application we also need to consider the interaction between the knowledge repository and the target system. Once the KBE application is within the neutral format it will enable the development of a knowledge library of generic applications that would be used in the reduction of the application development lead-time. If KBE systems were developed in this manner, the ability to buy off-the-shelf generic applications might become possible. One of the KBE vendors has already produced two generic applications one related to the design of cars and the other to the design of aircraft. These are available for sale but require access to the vendor s system. However, if the applications were developed using the core solutions and the management scheme mentioned within this paper, the application would be accessible to different KBE development platforms and even different KBS development platforms. If a company uses the product knowledge management scheme as set out within this paper, it would enable the company to solve many of the problems associated with KBE systems. Although it is difficult to produce the right answer for everyone using the same scheme, the proposed scheme would form an ideal basis for most product knowledge management schemes for KBE systems. Acknowledgement Elements of this work have been sponsored by BAE SYSTEMS Advanced Technology Centre-Sowerby. The authors wish to acknowledge the assistance provided by the staff of BAE SYSTEMS during the research required for this paper. References Callot, M., Kneebone, S., Oldham, K., A user-driven project to develop a Methodology and Tools oriented to Knowledge Based Engineering s, Proceedings of the European Conference Product Data Technology Days, Watford UK, March Guptara, P., Why knowledge management fails, Knowledge Management Review, July/August 1999, pp Kock, N.F.; McQueen, R.J.; Corner, J.L., The nature of data, information and knowledge exchanges in business processes: implications for process improvement and organizational learning, The Learning Organisation, 1996, Volume 4, Number 2, pp Kneebone, S., Oldham, K., The integration of supply chain engineering using knowledge based engineering, TCT Rapid News, Volume 5, Number 6, 1997, pp Lovett, P., Bancroft, C., Knowledge Transfer for Knowledge-Based Engineering, To appear in Proceedings of TTI 2000 (Technology Transfer and Innovation Conference), Commonwealth Institute, London, July Lovett, P., Ingram, A., Bancroft, C., Knowledge Based Engineering for SMEs A Methodology, Proceedings of the 15 th Annual Conference on Computer-Aided Production Engineering (CAPE 99), Durham UK, Sainter, P.; Oldham, K.; Kneebone, S., The necessity for product knowledge reuse and sharing within knowledge-based engineering systems, Proceeding of the ASME Design Automation Conference 1998, DETC98/DAC-5569, Atlanta USA, September Sainter, P; Oldham, K; Larkin, A; Murton, A; Brimble, R., Product knowledge management within knowledgebased engineering systems, To appear in the proceedings of the ASME Design Automation Conference 2000, DETC00/DAC-14501, Baltimore USA, September Uschold, M.; Jasper, R.; Clark, P., Three approaches for knowledge sharing: A comparative analysis, Proceedings of the 12 th Banff Knowledge acquisition for knowledge based engineering systems workshop, Editors B.R.Gaines, R.Kremer & M.Musen, Banff, October 1999