We present MADAM, a methodology which allows the elicitation, capture, analysis and management of redesign knowledge. This area is characterised by the high reusability of problem solutions and is represented using three views: physical, functional and process. The methodology supports the analysis of the knowledge elicited and, therefore, the inconsistencies are detected. In addition, the knowledge is normalised so unnecessary (subsumed) parts and technical solutions can be removed with the aid of the expert. MADAM thus contributes towards better and faster redesign

Ahriz, Hatem

Arana, Inés

English

Arana, In�s

Open Access Institutional Repository at Robert Gordon University

OpenAIR@RGUThe Open Access Institutional Repositoryat The Robert Gordon Universityhttp://openair.rgu.ac.ukThis is an author produced version of a paper published inKnowledge-based intelligent information engineering systems and alliedtechnologies: Proceedings of KES 2002 (ISBN 9781586032807)This version may not include final proof corrections and does not includepublished layout or pagination.Citation DetailsCitation for the version of the work held in ‘OpenAIR@RGU’:AHRIZ, H. and ARANA, I. 2002. A methodology for the elicitation ofredesign knowledge. Available from OpenAIR@RGU. [online].Available from: http://openair.rgu.ac.ukCitation for the publisher’s version:AHRIZ, H. and ARANA, I. 2002. A methodology for the elicitation ofredesign knowledge. In: E. DAMIANI, R. J. HOWLETT, L. C. JAINand N. ICHALKARANJE, eds. Knowledge-based intelligentinformation engineering systems and allied technologies.Proceedings of KES 2002. 16-18 September 2002, Crema, Italy.Pp. 156-160.CopyrightItems in ‘OpenAIR@RGU’, The Robert Gordon University Open Access InstitutionalRepository, are protected by copyright and intellectual property law. If you believe thatany material held in ‘OpenAIR@RGU’ infringes copyright, please contactopenair-help@rgu.ac.uk with details. The item will be removed from the repository whilethe claim is investigated.A Methodology for the Elicitation ofRedesign KnowledgeHatem AHRIZ Inés ARANAThe Robert Gordon University, School of Computing,Aberdeen, AB25 1HG, UKAbstract. We present MADAM, a methodology which allows the elicitation, capture,analysis and management of redesign knowledge. This area is characterised by the highreusability of problem solutions and is represented using three views: physical,functional and process. The methodology supports the analysis of the knowledgeelicited and, therefore, the inconsistencies are detected. In addition, the knowledge isnormalised so unnecessary (subsumed) parts and technical solutions can be removedwith the aid of the expert. MADAM thus contributes towards better and faster redesign.1. IntroductionDesign is a very important stage in the manufacturing of a product. Redesign is a type ofdesign where the aim is to produce a new variant of a product family in order to satisfy aslightly different specification. The same expertise is used by the designers to produceproduct variants. Hence, it is an area that lends itself to knowledge reuse. In this paper, wereport on our experience in acquiring redesign knowledge using MAKUR [1], amethodology, which supports engineering redesign. It consists of three tools:- Design Analysis Methodology (MADAM) to elicit, and analyse knowledge.- Design Description Language (MADD) to represent the knowledge analysed above.- Design Advisory System (MADAS): an interactive problem-solving tool that providesparticular design solutions for a product, given a set of requirements.This paper concentrates on MAKUR’s Design Analysis Methodology (MADAM).2. RedesignRedesign is a very time-consuming task to which companies devote lots of resources.For example, oil companies require the design of thousands of pipe supports, which areused in order to restrain the pipes running along offshore platforms (existing steel). Whendesigning a pipe support, it is important to determine where the existing steel is located,whether there are other supports nearby or not, pipe loads and stresses and whether there isanything on the way that may make the support difficult to attach. The designer also needsto consider the client's preferences and policies when several alternatives are available.Figure 1 (a) illustrates a simplified example of a pipe requiring support where the closestexisting steel runs vertically and to the west of the pipe. Figure 1 (b) shows the solution tothis problem using a frame, pipe shoes and restraints. For details of pipe support redesignwe refer the reader to [2].3. Elicitation of Redesign KnowledgeDesigners look at products from different perspectives: physical, functional and process.Although other knowledge elicitation and representation methodologies were considered(e.g., Brown’s [5], STEP [6, 7] and CommonKADS [8]), these were rejected because theyeither provided little adaptation to redesign problems, were too costly to apply or did notelicit all the knowledge required. The three-views model that MADAM aims to build is asfollows (Figure 2):- Physical model: represents the product in terms of the parts it is composed of and theirdesign features. Figure 1.b shows a pipe support composed of a frame, a pipe shoe anda couple of restraints.- Functional model: describes the various functions that a product satisfies and thetechnical solutions that implement a function. The design features used in a technicalsolution relate this model with the physical one. For example, the pipe support in figure1.b fulfils a "guide and rest" function.- Process model: describes the tasks which need to be carried out in order to obtain adesign and the methods which can be used in order to perform a task.Figure 1: (a) Pipe support environment, (b) Pipe support built in the environment.All the model entities are described in terms of parameters and their domains.Constraints are used to express the relationships between parameters. In order to producethe design of a particular product, the designer would select the model entities from one ormore model views.Figure 2: The three model views (from top to bottom): Physical, Functional and Process model.MADAM (figure 3) first studies the design of a product family in order to gain ageneral understanding of the product and its design. The application of this phase results ina set of design entities (e.g. functions, parts). Next, the relationships between these entitiesPipeExisting Steel(a)FramePipe ShoeRestraintsPipeSupport(b)HasAssociated withImplemented by0..*1..*MultiplicityArticle Part0..*1..* DesignFeature0..*Function 1..*1..*0..*TechnicalSolution0..*Task 1..* Method1..*are identified by looking at the design and its process in more detail. Hence, the knowledgeelicitation starts with a top-down approach that extracts the main entities in the domain(analysis) and is followed by a bottom-up approach where the relationships between theentities are elicited (synthesis).The result of applying MADAM is a three-view model (trees) representing thecompany's “know how” for the redesign of a particular product family. The three-viewproduct model is represented using a Graphic Editor (GE) which allows the knowledgeengineer and designers to browse through this model, and insures the structural consistencyof that model (e.g., insure that each function is related to at least one technical solution).Figure 3: Major steps in applying the MADAM.In addition to structure checking, the model is analysed to ensure its consistency [7].The GE uses the constraints associated with the entities in model for checking its validity.The core of the validation tools is a constraint satisfaction engine [4], which ensures that allthe model alternatives offered are feasible (i.e. there is at least one valid design solutionwhich uses that alternative). The GE is able to find various types of anomalies in the model(e.g. incoherence, partial conflict, incompatible entities) and assists the knowledge engineerin refining the existing knowledge or eliciting new knowledge. For example, aninconsistency is detected when the parameter pipe1.diameter can take values in[10mm..2000 mm], and there is a constraint pipe1.diameter > 1500, the GE suggests thatthe domain of values may be reduced to [1501mm..2000 mm]. This suggestion is passedonto the knowledge engineer for approval.. For a complete discussion of model validationin MAKUR we refer the reader to [3]. The methodology uses a variety of knowledgeelicitation methods [9]:- Unstructured interviews are used to gain an initial understanding of the problem.- Structured interviewsare used to obtain more detailed knowledge which lends itself tostructuring and analysis.- Protocol analysis, where the expert’s problem-solving is studied. The designer/engineeris recorded and the tape is then used to extract the general design process which hefollows.- The role shift approach, where the knowledge engineer takes the role of the expert, andthe latter validates the knowledge acquired. For example, in one instance, a designerstated that an article had five functions and any combination of these (i.e. 32 functionsin total). But when the knowledge engineer looked at hundreds of design drawings,only 13 functions were identified.Preliminary Study& Definitionof RequirementsIdentifyFunctionsDetermineTechnicalSolutionsfor each FunctionDefine PartsRelated to eachTechnicalDefine DesignFeatures for eachPartDefineParameters &Constraintsfor each EntityDetermine Tech.-Solution-LevelDesign ProcessObtain Function -LevelDesign ProcessMerge Top-Level &Low-Level DesignProcessDesignManualsValidatethe ModelAnalysisSynthesis- Watching the designer while performing his job: some designers recognise that theymay contradict themselves during interviews! Thus the importance of this technique.The knowledge elicitation process used a variety of sources:- Discussions with various experts at different levels of the company’s hierarchy. Theaim was to gain an overall understanding of how the different departments co-operatein the realisation of the article. The methodology, then, focused on discussions withone designer, given that each designer in the company has his own designing style andthat finding a consensus amongst all designers is difficult, unless the company is veryprescriptive in the way in which designs are realised. The lack of consensus betweendesigners may be the reason why a company’s design process is not documented.- Company documentation: standards and regulations, catalogues of components.- Design drawings: they constitute a mine of information and can provide the knowledgeengineer with many issues to discuss with the designer.MADAM offers the ability to capture various sorts of knowledge:- Type-subtype knowledge: since we have observed that designers use this kind ofknowledge. Hence, there are two types of hierarchies: (a) Type/subtype hierarchy: Forexample, “Welded Shoe” is a type of “Shoe”. (b) Part/subpart hierarchy: This is adecomposition of the article into parts and design features. The use of such typingenables the inheritance of parameters and constraints from types, thus avoidingredundancy, facilitating reuse and ensuring consistency.- Default Values: Designers often use default parameter values wherever possible, sincethis encourages standardisation.- Optimisation criteria: Designers use a driver (e.g., cost, ease of installation,manufacturing time) in order to select a design solution.- Prioritised design options: Designers prioritise design solutions. The most desirabletechnical solution is the option that the designer would try first. For example, aninverted goal post can be the frame default option, and only if this option is notappropriate (e.g. a constraint is violated) that another alternative is tried.- The various constraints between the model entities are categorised as follows: (i) levelof desirability: from desirable to compulsory constraints; (ii) scope: from genericconstraints which apply to a type and all its sub-types to local constraints which onlyapply to a particular entity.4. ResultsThe MAKUR knowledge acquisition methodology has been used in various testcases. Thefollowing benefits have been reported:- Reduced variance (standardisation) in the various technical solutions since themethodology encourages the analysis and normalisation of knowledge.- Prioritisation of these solutions by considering various criteria (e.g., cost, ease ofinstallation, company policies) so that given a set of requirements, different designerswill reach the same solution.- Documentation and retention of the design process. Thus, redesign expertise can beshared amongst designers and is available to novices.5. ConclusionsRedesign problems are characterised by a well understood domain and the high reusabilityof their solutions. Hence, it is a very appropriate area for the construction of advisory toolswhich can help reduce the problem solving time. A first step in the construction of such asystem is the development of a methodology for the acquisition (and analysis) of redesignknowledge, so that it can be used in a support system. This is a key issue, since the qualityof an advisory system is highly dependent on the knowledge it uses. We have presentedMADAM, an analysis methodology for the redesign of product families. It is a two-steptask where: (i) the design of a product is first analysed in order to gain a generalunderstanding of the design; (ii) the relationships between entities are identified. MADAMis part of MAKUR, a methodology for the development of redesign support systems whichcontributes towards a better and faster redesign of product families.References[1] Arana, I., Ahriz, H., Fothergill, P. Redesign Knowledge Analysis, Representation and Reuse. InIndustrial Knowledge Management A Micro-level Approach, Roy, R., (Ed.), Springer-Verlag, 139-146,2000.[2] Arana, I., Ahriz, H., Fothergill, P. Improving redesign support. In Proceedings of the Fifth WorldConference on Integrated Design and Process Technology (IDPT'2000), Dallas, TX, 2000, 8 pages(CDRom).[3] Arana, I., Ahriz, H., Verification of Redesign Models: A CSP Approach. In the Proceedings of theThirteenth International Conference on Engineering Design, ICED'01 Glasgow, August 21-23, pp 283-290, 2001.[4] Barták, R. Constraint Programming: In pursuit of the Holy Grail. In Proceedings of WDS99 (invitedlecture), Prague, June 1999.[5] Brown, D.C., Chandrasekaran, B., Design Problem Solving: Knowledge Structures and ControlStrategies. Morgan Kaufmann. 1989.[6] Knutilla, A., Schlenoff, C., Ray, S., et al, NISTIR 6160, National Institute of Standards andTechnology, Gaithersburgh, MD. 1998,[7] Owen, J., STEP: an Introduction. Information Geometers Ltd. 1993[8] Preece, A. “Evaluating Verification and Validation Methods in Knowledge Engineering. ” In IndustrialKnowledge Management: A Micro-level Approach, Springer-Verlag, pp. 91-104, 2000.[9] Rumbaugh, J., Blaha, M., Premerlani, W. Object Oriented Modelling and Design. Prentice-Hall. 1991,[10] Schreiber, G., Wielinga, B., de Hoog, R., Akkermans, H., CommonKADS: a ComprehensiveMethodology for KBS Development. IEEE Expert 9, 6, 28-37. 1994.[11] Schreiber, G., Akkermans, H., Anjewierden, A., de Hoog, R., Shadbolt, N., Van de Velde, W.,Wielinga, B. Knowledge Engineering and Management: The CommonKADS Methodology, The MITPress, 2000.

A methodology for the elicitation of redesign knowledge.

https://rgu-repository.worktribe.com/preview/294765/AHRIZ%202002%20A%20methodology%20for%20the%20elicitation.pdf

A methodology for the elicitation of redesign knowledge.

Abstract

Similar works

Full text

Available Versions

Open Access Institutional Repository at Robert Gordon University