MOKA Methodology and tools Oriented to Knowledge based engineering Applications

1
MOKA Methodology and tools Oriented to
Knowledge based engineering Applications
OMG KBE Services for Engineering Design Request
for Proposal August 24, 2004, Montreal Canada

• Cirrus Shakeri
• KTI

2
MOKAHistory

• Methodology and tools Oriented to Knowledge based
  engineering Applications
• It was part of the many research and development
  initiatives conceived within the umbrella of the
  AIT project (Advanced Information Technology,
  Pilot Phase Esprit Project 7704). This suite of
  initiatives was part funded by the European
  Commission and was extensively user driven to
  establish the future IT needs of the European
  automotive and aerospace manufacturers.
• The project began in January, 1998 and lasted 30
  months. The project partners included
• Industrial Users
• Aerospatiale Matra (leader of the project)
• BAE SYSTEMS
• Daimler-Chrysler
• PSA Peugeot Citröen
• IT vendors
• Knowledge Technologies International (KTI)
• Decan Consulting Services
• Academia
• Coventry University KEM Centre

3
MOKA in a Glance
4
MOKA Methodology
KB Application
ICARE Forms
Meta-models MML
Charts
5
A MOKA Project
6
MOKAInformal Model
7
MOKA ICARE Forms
8
MOKA ICARE FormsEntity

• Entity forms are used for defining
• Structures to describe the product family in
  terms of assemblies, sub-assemblies, parts, etc.
• Functions to investigate the functionality of a
  product and to record possible design solutions
  and the rationale behind their selection
• Behaviour to record the way in which a design
  fulfils a function and ways in which behaviour
  can change under different circumstances.

9
MOKA ICARE FormsEntity
10
MOKA ICARE FormsEntity
11
MOKA ICARE FormsConstraint
12
MOKA ICARE FormsConstraint
13
MOKA ICARE FormsActivity
14
MOKA ICARE FormsActivity
15
MOKA ICARE FormsRule
16
MOKA ICARE FormsRule
17
MOKA ICARE FormsIllustration
18
Relationships
19
ICARE Forms
20
MOKAFormal Model
21
MOKA Metamodeling Levels
22
Product Model

• The Product Model describes the 'WHAT' of an
  engineering product. It contains all the
  knowledge that describes the product itself - how
  the product is built up from assemblies and
  parts, the materials used, the way the product is
  intended to behave and the functions that it will
  fulfill, the way in which the product is
  manufactured and its shape and size.
• The model includes constraints - issues like
  limitations on the attributes (for example,
  restricting length or diameter) or offering
  alternatives within the structure (for example,
  using studs or bolts for attaching the cap on a
  connecting rod - in an either/or situation).
• The Product Model contains enough information in
  a general sense to describe the product fully.
• Product model does not specifically include any
  knowledge about how to design the product in
  engineering terms or why the product is designed
  in the way that it is.

23
Product Metamodel Views

• The Product Model uses MML in terms of
  pre-defined UML class diagrams for representing
  knowledge objects. The number of knowledge
  objects can be very large.
• To make life easier, the knowledge objects are
  sorted into views represented by packages in
  UML.
• The MML classes are essentially UML class objects
  which, when used to build models, become
  stereotypes.
• The stereotypes provide a further refinement of
  the knowledge categorisation that began with the
  ICARE forms. All the classes in the Product
  meta-model both provided by default in MML and
  those added by the user - derive from the MML
  Base Class

24
Product ModelStereotypes
25
Predefined Views for Product Model
26
Product Metamodel ViewsStructure
Example MML Product Physical Structure
meta-model This representation is the Structure
view in the formal Product Model
27
Product ModelStructure View
Example An instantiation of the Structure
View This example shows an instantiation of the
Structure view, given in the previous example.
28
Product ModelBehavior View
29
The Product Metamodel
30
Design Process Model

• DPM is the opportunity to record the design
  rationale of a product (the WHY).

• Core equation of design theory

completeD,K(R) ? fulfillsD,K(M,R) ?
consistentD,K(M) ? solutionD,K(M,R)

• The design description M is a solution to the
  problem formulated by a complete requirement set
  R (in a given context K, subject to a domain
  theory D) if, and only if, M is consistent and
  fulfils these requirements.

31
Categories of Knowledge

• Dynamic knowledge categories
• label attached to the domain knowledge
• Tasks
• definition of sequence and method
• Goals
• objectives of the task
• Strategic knowledge
• overall guidance for the entire design process

32
Process Metamodel

• CommonKADS
• Four layers for process modeling Strategy, Task,
  Inference, Domain Layer (product model)

33
Process Knowledge ModelingversusProduct
Knowledge Modeling
Task Knowledge
Configuration Design
Process Knowledge
Inference Knowledge
specify
operationalize
propose
verify
modify
critique
Domain Knowledge
Product Knowledge
requirements
skeletal design
extension design
design
34
Process Metamodel
35
MOKAThe Important Points

• Distinction between Product and Process Models
• Fixing the meta-metamodel level
• Leave the metamodel level flexible
• Use OMG standards
• UML
• MOF
• MDA (model-driven architecture)

36
What is missing in MOKA?

• Concrete meta-model for the process
• Expressive-enough representation schemes for the
  process
• Proper guidelines for linking of the process to
  the product
• Direct translation of the informal model to the
  formal model
• Formal representation of the strategy knowledge
  associated with the dynamic processes
• Its a natural text language representation in
  MOKA
• A modeling construct for representing the actors
  in the process

37
What are we looking for in a KBE Standard?

• Interoperability between different KBE systems?
• Interoperability between KBE systems and other
  CAE tools?
• Interchangeability between different KBE models?
• A list of KBE services with definition of each
  service?
• A list of standard functionality for KBE
  software?
• A standard approach to KBE? (e.g., top-down vs.
  bottom-up)?
• A standard language for describing KBE models?
• An engineering ontology?
• Standard approach and techniques for knowledge
  management and knowledge engineering side of KBE?

38
END