Knowledge Based Engineering Methodologies

A KBE system consists of a lifecycle requiring the identification, capture, structure, formalise and implementing the knowledge. Developing a KBE application requires the use of different tools at the various stages of the KBE lifecycle. According to Reddy et al., (2015) most KBE platforms only support the implementation stage of the KBE lifecycle but not the development process. Developing a good KBE system must be robust in terms of managing, safeguarding and updating the system in a structured manner. The following sections will look at some accepted KBE methodology. 2.4.2.1 MOKA

Methodology and tools Oriented to knowledge based Applications (MOKA) is a well- known and applied methodology which satisfies to a great extent most of the objectives of KBE system. According to Curran et al. (2010) and Klein et al. (2010), MOKA was a European research project set up as an international standard for Knowledge Based System development. MOKA is adopted in the aerospace and automobile industry which serves as a bridge between raw knowledge and KBE platform. MOKA does this by breaking down and stacking up knowledge and associating them with a predefined network of a problem domain for various users to relate with.

The objectives of MOKA project were to;

i) Reduce KBE application development times and cost

iv) Provide a tool supporting the methodology (MOKA Group, 2000).

MOKA methodology consists of six steps: Identify, Justify, Capture, Formalize, Package and Activate as shown in Figure 2.8 mainly focuses on capturing and formalizing knowledge.

Figure 2. 8: MOKA Lifecycle (MOKA Consortium, 2001)

Identify – this stage takes existing business opportunity into account and selects the appropriate KBE application with resources needs necessary to build.

Justify – at this stage, technical, financial and cultural risk analysis is carried out by senior managers based on project plan developed to consider whether the project is viable or not.

Capture – raw knowledge is collected at this stage and structured into ‘Informal Models’ using ICARE (Illustration, Constraint, Activity, Rules and Entity) forms. ICARE elements are represented using process flow models and hierarchical charts.

Formalize – at this stage, the informal models are translated into formal models using MOKA Modelling Language (MML) which is based on the Universal Modelling Language (UML), making it easy for software engineers to understand.

Package – at this stage, the formal model is used to create actual software tools implemented in a KBE system.

Activate – at this stage, the software is installed, distributed and support made available for the daily use of the KBE system.

2.4.2.2 Intelligent Computer Aided Design (ICAD)

ICAD was the first CAD software in the field of KBE system developed in the early 1980s by KTI which increased the use of industrial design automation. ICAD has two interfaces, the first of which takes care of actual product geometry and the second interface handles programming of rules linked to the geometry. The system uses its own developed language known as the ICAD Design Language (IDL) which is based on a List Processing Language (LISP).

According to (Knutson, 2003) and (Bernard, 2003), the history of ICAD has been through a lot of changes which includes the sale of KTI to Dassault Systemes in 2002. ICAD in its earlier versions was made up of CAD engine with tools for capturing geometric knowledge and tool rules to generate 3D models automatically having specific input parameters. Cooper (2001) concludes that the ICAD system was extensively used within the automotive and aerospace engineering domain with major customers including Jaguar, British Aerospace, Airbus and others where Jaguar Motorcar Company applied it to assess manufacturing feasibility of vehicle headlights. However, more recent versions had an integrated approach, mainly centring on the knowledge and aspects of application development, and proving interfaces with common tools such as Parasolid, Solidworks, CATIA V5 and AutoCAD as well as with other standard desktop applications such as Excel (KTI, 2002).

2.4.2.3 Model-based and Incremental Knowledge Engineering (MIKE)

MIKE which stands for Model-based and Incremental Knowledge Engineering is a Knowledge Based Engineering methodology which supports iterative system development and prototyping compared with others which finalises all models before specific implementation begins (Studer, 1998). Angele (1998) mentions that MIKE “proposes the integration of semiformal and formal specification techniques and prototyping into an engineering framework”.

Figure 2.9: Main processes and deliverables of the MIKE methodology (Studer, 1998)

The different models in the MIKE methodology (Figure 2.9) shows various outcomes of different steps of the building process. The methodology claims that the knowledge engineers are responsible for representing knowledge in the elicitation model, structure model, model of expertise, design model and the final system. They either represent the same knowledge in different manners or extend existing models in another representation (Decker et. al., 1996).

According to Angele (1998) and Studer (1998), MIKE consists of two knowledge models, informal model and formal model. The informal knowledge model is created using techniques such as data flow diagrams, state transition diagrams, entity relationship diagrams and process flow diagrams which are high level representations of knowledge that is easily understood by users. However, the formal model is based on the capability of modelling in CommonKADS using Knowledge Acquisition and Representation Language (KARL). The KARL allows a working model to be tested in the entire development process by practically ensuring the completeness competence of the formal knowledge model. CommonKADS is a comprehensive methodology for developing knowledge based systems (Schreiber et al. 94).

Modelling in KARL requires the creation of an organizational model (de Hoog et al. 94) which considers the dynamic aspects, such as workflow, only in one direction. However, there is no description of how to integrate and use these models (Schreiber et al. 94).