7 Resources For CATIA Macro Programmers

See discussions, stats, and author profiles for this publication at: https://www.researchgate.
net/publication/266142103
Best Practices in Knowledge-based Engineering (KBE) - Catia Operators

Exchange (COE) Report
Technical Report · January 2006

DOI: 10.13140/2.1.4370.5602
CITATIONS READS
4 3,608
1 author:
Brian Prasad
California Institute of Technology
263 PUBLICATIONS 2,698 CITATIONS
SEE PROFILE
Some of the authors of this publication are also working on these related projects:
Concurrent Engineering Fundamentals: Volume 2 Chapters View project
Book reviews View project
All content following this page was uploaded by Brian Prasad on 27 September 2014.
The user has requested enhancement of the downloaded file.

Best Practices in KBE (Draft Rev 3.0) May 15, 2006
Best Practices in KBE
Document Edited by:

Brian Prasad and
Editorial Board Members
(See Pages 3-4 for listing)
Articles Contributed by:

And
Articles Revised and Reviewed by:
COE Members
(Please see each article header for details)
COE/DPC-KBE Task Force
Sponsored by: COE/DPC 2005 KBE Committee
DRAFT REVISION 3.0 (May 1, 2006)
Please direct all enquiries to: Dr. Brian Prasad, COE/DPC KBE Chair, bprasad@parker.com.
Page 1

Historical Background:
During the COE-2005 Conference in Phoenix, Arizona, Brian Prasad (as an incoming Chair for the COE-
DPC KBE) met with several key leaders at COE 2005 Conference team.
The consensus was that many of the organizations (and our COE-KBE work force in automotive and
aerospace industries), by trial and error, may have found “some KBE best practices.” They may have
uncovered “modeling tips in KBE” in search for design automation, knowledge reuse and integration. This
may include tips on “how to use or create a feature in CATIA V5 via KBE” or to more general tips, such
as, “how to make your KBE model more robust and morph-able?”
The team felt, that our COE users at large would benefit a lot, if we could help gather all those tips and
articles into a KBE Best Practices document.
Being the incoming chair for DPC, Brian Prasad took this responsibility to facilitate creation of such a
document. He formed a task force. Working with the COE members, who responded, Dr. Prasad created
a Table of Contents and sent out several call for Contributions. He posted it onto the KBE focus groups,
COE NewsNet and other places and email sites.
This resulted into formation of Revision One of the so called “KBE Best Practices Document
(KBP).”
In the beginning “birds of the feather” stages of its development, Brian Prasad worked with
select few contributors from our COE organization, added more sections, compiled all the
contributions into sections and created an improved version of the same. KBE best Practices
document soon exploded into several chapters and sections.
About a week before our COE-2006 Conference in Atlanta, GA, Brian Prasad created a new
complete version (Revision 2) of the KBP document. The KBP document- Rev 2 was sent to the
Editorial Board Members and contributing Authors & co-authors via Email attachments for their
review. The plan was to get together as a group and discuss the changes at the COE-2006
Conference.
During the COE-2006 Conference, KBE-DPC Committee with the help of PIC Chair, Scott
Hazel and his team held a second Annual KBE Roundtable and Open Forum on Wednesday
March 22, 2006 in Atlanta, GA, USA. The needs and contents of this document were discussed
at length. It was decided that in order to facilitate easy collaborations among the COE members,
an online media -- accessible to all COE members --should be used.
After careful evaluation of various collaborating options including Email, Wiki Encyclopedia
and COE-KBE Forum, the managing editors decided to employ the KBE forum for this purpose.
Thanks to "'Bill Abramson'" w_abramson@verizon.net, "'Perlman, Rich'"
Page 2
Rich.Perlman@ngc.com and John M. Switlik [mailto:john.m.switlik@ieee.org] for their

approval and support.
After coming back from COE-2006, Brian Prasad gathered all the changes and created a
REVISION 3 of the Document. The KBP-REV3 document you are looking at is the result of
such solicitations. See TOC for details.
Due credits are given to individuals by listing their names against their contributions. At the
beginning of each article there is a header, which lists the following:
Contributing Author: Your First and Last name Affiliation & Date --when
completed
Co-Author: Joe Blow IBM IT Group VP, May 1,
2006
Revised By:
Edited By:
Edited By:
Reviewed By:
KBE Forum as a Tool for Collaboration

Brian Prasad and John M. Switlik have established an approved process for
collaborating via KBE Forum with our KBE-COE members openly. There is a
separate document entitled “Collaborating on Building KBP Via KBE Forum.doc”
created for this purpose. We plan to track all DOT.revisions for each KBP
chapter independently. Every alternate month, we would like to bring back all
of DOT.contributions made to the chapters into a NEXT level of their RELEASE.
Please read the “Collaborating on Building KBP Via KBE Forum.doc” document
carefully before posting changes. Thanks!!!
Page 3

Introduction
There are many different ways of implementing a KBE or an “automated” solution. It is not a trivial exercise to find the
one approach that best fits your application and at the same time possesses some desirable “ease of use” features,
such as most robust, the simpler, etc.. Examples of different ways of implementing automated solutions are:
One can build an application using KTI/ICAD IDL language. Many of us --old timers have done that.
One can do an application in VBA, many of us done that too.
One can built an application in VB Scripts.
Some of us have done the same using in KnowledgeWare Tools.
Some of us had done it using PKT/GScript Language.
Some of us have done using CATIA V5 Templates.
In fact, there are many ways of doing (building a KBE application) even within our CATIA KnowledgeWare tools set
(KWA, KWE, PKT and BKT).
Then, the real question is how should we build this “automated” application so that a resulting “KBE” application
exhibits the following characteristics?
That a resulting application is dynamic. Rules reconfigure themselves or the outputs based on input
changes.
That it (my application) is Generic.—many new, known or unknown cases can be derived from one model or
a “just-one” code representation.
That it’s generative.-- new rule bodies (or models) are created automatically from the old ones (e.g. model
templates) based on changes in input specifications.
That it’s high level. A small amount of KBE code (in the form of high-level instructions or language) produces
significant results (manipulating a large number of objects)
That it’s demand-driven. System (knowledge-engine) knows the sequence in which rules become active and
controls how those rules get fired. Thus, relieving the users (KEs) to worry about (program) or to control the
so called “rule sequencing” themselves.
The above list of “TOP FIVE” is what distinguishes a true “KBE application” from its “Pure automation” solutions. The
latter (pure Automation) solutions are often built using traditional programming tools -- such as pure C++, VBA or VB
Scripts.
Members of the Editorial Board:

The following people have been identified but they have not been firmed up to serve on the
Board. The actions will be taken once we have a good Table of Contents to be sent out.
Member Affiliation/Company Email ID Areas of

Name Focus
(TOC Sections
Reviewed/Edit
ed)
Gregory A. Vought Aircraft
Premetz (GP)
Ray Anderson Design Specialist - KM/KBE/CAD Mailto:raymond.ande
(RA) (Accepted) Engineering - TWEZD rson@airbus.com
Airbus North America Engineering Inc.
Phil Thomas IBM, PLM Application Engineer
Page 4
(PT)
Pierre Pinard DS- KBE Support
(PP)
Fabrice Dreneali Manager R&D Solutions, DS, France
(FD)
John M. Switlik Associate Technical Fellow
(Accepted) Wichita Define Systems/Knowledge Based
Systems
James Boeing, Manager KBE products and

Fernandez, Services
(JM)Ph.D.
Rick VanWetten Siemens VDO
(RV)
Rodney L. Boeing
Dreisbach, Ph.D.
(RD)
William J. Moon Boeing
(WM)
Mike Twelves Corus
(MT) (Accepted)
Paul Webb (PW) Application Consultant , KBE
(Accepted) KTI/DS
Danny Bouchard Aerospace Practice Consultant Cell phone: (206)-
(Accepted) Dassault Systemes Services 799-9730
David W. Pigden Goodrich

(DP)
Brett Ade (BA) MSC Software
Franck Montigon Dassault Systèmes CATIA Strategy on
(FM) Knowledgeware,
FEA and Shape
Design and Styling
João Paulo Technology Development Engineer Phone: + 55 12

Rebucci Lirani Embraer - São José dos Campos 3927-6418
E-mail:
jp.lirani@embraer.co
m.br
More to Come
Later
What Our KBE Document is or is not?

Before we describe the Table of Contents of the proposed document, it is important that we look
at it from “Applications perspectives” and “Applications developer’s perspectives.” That means
we need to mange our readers’ expectations.
What our KBE Document is What Our KBE Document is NOT

A place where you can find Best Practices An Extension of DS/Knowledge Ware
in KBE Documents/Online Help
A place where some of the Benefits of A better Users Manual than what DS/KW supplies.
Page 5
capturing Engineering Intents (via KBE) Differences between KWA rules and KWE rules
versus pure “geometry” (Why use KBE?)
Describes What makes an application Provides more examples than what DS/Knowledge-
Generic, Robust, Reusable and Portable Ware Tools
How to ensure that rules are dynamically Better Examples than what DS provides in their
controlled and not subject to constant code Users Manual.
changes
Methods of Capturing Rules while building A Tutorial on KBE
KBE objects
Methods of Passing Parameters A step by step description of How to use various
(Integration) across KBE objects Knowledge-Ware tools
Which DS/KW Tools to use in what Describe Various Knowledge-Ware Tools:
situations. Describe situations when to use Parameters, Rules, KW terminology, and Better use
them and when Not to use them (what of PKT and PEO tools. (you will find some of these
makes best sense) in the appendix)
How to Build a best class of KBE Description of DS/KW tools and related Concepts
applications using our DS/KW tools
Describe SmartParts and Null Parts Propose Enhancement Requests for adding new
Concepts in KBE with KW Examples functions in DS/KW tools.
Acknowledgement
The Authors would like to thank the members of the Editorial Review board, contributing
authors/coauthors and the COE members for providing feedbacks and taking time to check the
accuracy of the contributions/results reported herein.
Authors would also to thank the COE Board of directors and DPC-KBE Chairs for sponsoring
creation of this document. Without the concerted efforts of everyone involved, this would not
have been possible.
The Table of contents of the proposed document is described next.
Page 6

Table of Contents (Tentative)
TOC Lead Supporting Page
Authors/ Authors/ Numbers
Coauthors CoAuthors
1.0 Introduction
1.1 Designing Products? BP AM1
1.1.1 Why Consider “Product as a System”? Brian Prasad
1.2 What is KBE? BP AM1
1.3 KBE Tools BP AM1
1.4 What is KnowledgeWare? Francois
Riche
2.0 KBE Concepts

2.1 Capturing Engineering Intent BP AM1
2.2 Morphing Strategies BP
2.3 How to represent Knowledge? - AM1
Modularization of Knowledge
2.4 Knowledge-centered KBE versus CAD- AM1
centered KBE
2.5 How KBE Differs from Parametric , BP
Relational, (Variational) CAD
2.6 How independent should knowledge be from AM1
the tool (environment)
2.7 Top-down philosophy (I-CAD) vs Bottom-up AM1/JP
Philosophy (V5)
2.8 How to model knowledge (before constructing
an application)
2.9 Moka AM1, Ray Ray Anderson
Anderson
3.0 KBE Rule Languages

3.1 KWare Language Francois BP DB
Riche
3.2 GenSCript Francois BP DB
Riche
3.3 VB Scripts & VBA Francois BP DB
Riche
Page 7
4.0 Feature-based Modeling

Concepts
4.1 Parametric Design (is like simple CAD-pure BP
geometry modeling)
4.2 Parametric Templates (is like Part Templates, BP
if only pure geometry is involved) A top down
modeling concept. Adding and Linking
independent parameters with a Parametric Design.
4.3 Part Geometric Features -- UDF &
PowerCopy
5.0 Assembly Modeling

Concepts
5.1 Assembly Geometric Templates FM
6.0 Problem Definition

6.1 Generic Modeling Strategies BP
6.2 Generalizations versus Specific Cases BP
6.3 Systems Engineering Approach (very BP
interesting!)
6.3.1 Problem Decomposition BP
6.3.2 Problem Aggregations BP
6.3.3 Problem Solutions Strategies BP
7.0 Rule-based Modeling

Concepts
(This talks about how we go about adding non-
geometric features. A template could be more
than a parametric part. )
7.1 Template-based Modeling BP
7.2 How to construct Templates? JP
7.2.1 Making templates Robust JP
7.2.2 Generic utility parts JP
7.2.3 Methodology for Templates JP
7.2.4.VB Scripts JP
7.2.5 Reactions and VBScripts JP
7.2.6 Publications – parameters & geometry to JP
publish
JP
7.3 Components-based Modeling
Page 8
8.0 How to architect KBE

applications in V5 (Integration
Strategies)
8.1 Setting the environment
8.2 Creating parameters, lists, etc.. JP
8.3 Creating Geometry (PartDesign, JP
GSD,Sketcher)
8.4 Exchange between VB and Catia (External JP
Parameters)
8.5 Passing Matching Attributes across BP
Parts/Templates. This is a technique which makes
your KWE Rule generic. If you have a method to
match assigned values of “matching Parameters”
across two parts, you could make your KBE
“scripts” very GENERIC.
8.6 Attributes Linking via Rule Bodies -This a BP
GETATTRIBUTE and SETATTRIBUTE method
used in KWE.
8.7 Exchanging parameters between Catia and BP
external app
8.8 Rules inside VB or Catia (KWA)? JP
8.9 Reaction-based Linking (see 8.c.ii) JP
8.10 Instantiating UDFs JP
8.11 Quantification (via VB or Loop) JP
8.12 Update Configurations AM1/JP
8.13 Working with Other Modules (Sheetmetal, JP
Composites, etc..)
9. System Solution Strategies

9.1 UI (User Interface) JP/AM1
9.2 Optimization inside Catia (PEO) or via VB?
10. Example Problems
11. Appendices:
Appendix A: Brief Description

of Tools to Develop KBE in
Catia V5
Introduction DB/BP
Appendix AA:V5 Fundamentals Danny
Page 9
Bouchard
Parameters DB
Formulas DB
Design Tables DB
Macros in VBA or VB DB
Appendix AB: Knowledge Advisor Danny

Bouchard
Lists DB
Rules DB
Checks DB
Actions DB
Reactions DB
Loops DB
VBScripts DB
Appendix AC: Product Knowledge Template Danny

Bouchard
User-defined feature (UDF) DB
Part Template DB
Assembly Template DB
Generative Script DB
Appendix AD: Business Process Knowledge Danny

Template Bouchard
Technological objects DB
Behaviors DB
Loops DB
BKT app DB
Appendix B: References &

Papers on KBE and Catia V5
Introduction DB/BP
Footnote: Note the legends (e.g., BP – Brian Prasad) are short abbreviations. DB: Danny
Bouchard. They are described in Chapter 5 and Sections 5.1, 5.2 and 5.3. RA: Ray Anderson
Page 10

Chapter 1: Introduction
1.0 Introduction
1.1 Designing Products? BP AM1
1.1.1 Why Consider “Product as a System”? Brian Prasad
1.2 What is KBE? BP AM1
1.3 KBE Tools BP AM1
1.4 What is KnowledgeWare? Francois
Riche
1.1 Designing Products

Contributing Author: Brian Prasad, Parker Aerospace, Irvine,
CA, May 2006
Co-Author:
Revised By:
Edited By:
Edited By:
Reviewed By:
Often while designing an artifact, engineering teams forget that the product is a system. It
consists of a number of subassemblies, each fulfilling a different but distinct function. A
subassembly is a group of two or more units that can be brought together (say for instance, share
common axes or fit together). Subassembly information includes sub-systems, components,
parts, and features (materials, attributes, parameters, and geometric features).
Process information includes assembly features (joining faces, aligning bolts, common axes,
welding lines, etc.), design methods (such as parts layout, design rules, analysis methods,
packaging, tolerance dimensions, and material substitution and form features options. A feature
is a representation of form, intent, and relevance to some aspect of part design of interest to
either functionality (part features or so called form features) or manufacturability (e.g., DFX—
Design for X-ability) [Nielsen, 1990]. Form signifies the attributes of the features present, their
connectivity (topology) and geometry. Relevancy points the reason a feature is included in the
design (e.g., issues related to functionality or DFX rules). Intent represents the imposed
constraints by the CE teams on the freedom of the parts’ function or rules associated with a DFX
principle.
In order to achieve a truly integrated product and process design (IPPD), all the above needs
have to be considered simultaneously. The core concept of IPPD is the “system definitions.”
Consider what Szucs [1980, pp. 42] stated: The term system is used to denote an object
composed of certain elements that are linked by well-defined (but not necessarily known)
Page 11
relationships. It is stipulated that the system may interact with its environment (receive external
stimuli) and that its behavior comprises responses that are useful or profitable to the operator.
Objects completely isolated from their environment (completely closed system) and phenomena
that cannot be influenced by person are not regarded as systems in the technological sense.
Before we take a close look at the requirements of a full IPPD system, let us review what
constitutes a system. Truly, a system has three parts:
(a) Class Hierarchy (a structure definition):
Class hierarchy is a very efficient mechanism for system definition because one can use
method and variable definitions in more than one subclass (such as sub-systems, components,
etc.) without duplicating their definitions. For example, consider a system that represents
various kinds of human operated vehicles (See Figure 1). This system would contain a
generic class for vehicles, with subclasses for all the specialized types. Five major subclasses
include: auto, truck, bus, aircraft and land transport devices. Their vehicle class would
contain the methods and variables that were pertinent to all vehicle features, such as
identification numbers, passenger loads, fuel capacity, etc. The subclasses, in turn, would
contain any additional methods and variables that were specific to the specialized cases
[Taylor, 1993]. Truck may consist of pick-up, van and a tractor-trailer. Land transport
devices may include subclasses such as motorcycles, bicycles, skateboards and unicycles.
{motorcycles }
{bicycles}
{skateboards}  [Land transport devices]

********
{unicycles}
Where  denotes an element of a set or member of the class hierarchy.

(b) Integration Hierarchy (an assembly definition):
[Land transport devices]  { motorcycles, bicycles, skateboards and unicycles}

Where  denotes “is a member of superclass set”. The elements in the curly bracket
are its member classes.
Page 12
(c) Constancy-of-specifications, requirements, purpose or

goals:
This identifies the key product functions, requirements or constraints (RCs) of the
product system, some of them are also common to its elements (product sub-classes). For
example, general system-level RCs must gives rise to components’ (e.g., a department
unit) level RCs. Constancy means carrying the same definition and the same sets of
requirement’s hierarchy and management process throughout a product development
process. IPD Teams must agree on a common set of engineering requirements that relate
to the company’s (high-level product development) goals and customer needs.
Constancy of RCs also provides a common set of ground rules for mutual cooperation
and communication throughout the product development community. If a product
development process is “left to themselves in the Western world, components become
selfish, competitive, independent profit centers [Deming, 1993].”
RCs parts  RCs components  RCs subsystems  RCs system  RCs department  RCs SBUs 
RCs enterprise
Where,  denotes an element of.
Figure 1.0.1: Class of Human Operated Vehicles
1.1.1 Why Consider “Product as a System”?

There are many advantages in considering “Product” as a System.
Page 13
Today, most companies are under extreme pressure to develop products within time periods that
are rapidly shrinking. As the market changes, so does the requirements. This is more pronounced
if the products are consumer-based. For instance, the product that a consumer wants today, may
not like when delivered three years from now. Associated with this are the urgencies and
pressures on the manufacturers’ part to modify their product characteristics based on the up-to-
date requirements, while the product is still being developed. This has chilling effects in
managing the complexity of such continuously varying product specifications and handling the
ongoing changes. This is because, today, it takes an extensive time and efforts to propagate the
specifications throughout the product design and development (PDD) process and then turn them
into opportunities for growth and profits. The ongoing success of a “learning type” organization
lies in its ability to apply novel methods and tools like KBE to capture its entire life-cycle PDD
process (including its system definitions) into a system of “KBE Solutions.” Considering
“Product as a System” while building a system of “KBE Solutions” has many benefits:
 The captured “product system” knowledge in the “KBE Solutions” could be reused quickly
at the product’s “system definitions” level in order to configure many relevant subsystem
solutions/possibilities.
 Organization could quickly react to changing requirements since system requirements are
part of the KBE system definitions
 Organization could apply the “system-definitions knowledge” of KBE solutions as a proven
baseline (starting point) to reinvent itself on new ideas or products that are not part of its
KBE solution family yet; and
 By leveraging existing system knowledge in KBE Solutions, it is easy for organization to
keep up with ever changing technology, new product introduction and innovation.
Many companies are stepping up the pace of life-cycle knowledge capture and are applying
“KBE solutions & tools” more and more upfront in the product development process. By doing
so, many organizations are achieving greater flexibility in new ways of engineering products
more correctly the first time, and more often thereafter.
1.1.2 References
Deming, W.E., 1993, The New Economics, Cambridge, MA, published by MIT Center for Advanced
Engineering Study, November 1993.
Nielsen, E., 1990, “Designing Mechanical Components with Features”, Ph.D. Thesis, University of
Massachusetts, Amherst, MA.
Prasad, B., 1996, Concurrent Engineering Fundamentals: Integrated Product and Process Organization –
Volume I, Prentice Hall PTR, Upper Saddle River, New Jersey.
Prasad, B., 1997, Concurrent Engineering Fundamentals: Integrated Product a Development – Volume II,
Prentice Hall PTR, Upper Saddle River, New Jersey.
Prasad B. and Rogers, J., 2005, “A Knowledge-Based System Engineering Process For Obtaining
Engineering Design Solutions, Proceedings of IDETC/CIE 2005. ASME 2005 International Design
Engineering Technical Conferences & Computers and Information in Engineering Conference, September
24-28, 2005, Long Beach, California, USA. DETC2005-85561
Prasad, B. “What Distinguishes KBE from Automation, COE NewsNet – June 2005,
http://www.coe.org/newsnet/Jun05/knowledge.cfm#1
Page 14
Pugh, S., 1991, Total Design, Addison-Wesley Publishers, Wokingham, UK.

Szucs, E., 1980, “Similitude and Modeling”, Elsevier Scientific Publishing Company, 1980, pp. 42.
Taylor, D.A., 1993, “Object-Oriented Technology - A Manger’s Guide”, Addison-Wesley Publishing
Company, Reading, MA.
Nevins, J.L., and Whitney, D.E., et.al., 1989, Concurrent Design of Products and Processes, McGraw-Hill
Publishing Co., New York, pp. 1-24.
Patton, J., 1980, Maintainability and Maintenance Management, Instrument Society of America,
Research Triangle Park, N.C.
Page 15

1.2 What is KBE?
Contributing Author: Brian Prasad Parker Aerospace, Irvine,
CA
Co-Author:
Revised By:
Edited By:
Edited By:
Reviewed By:
1.2.1 Introduction
For more than two decades, manufacturers have utilized PLM, previously known as computer-aided
design/manufacturing (CAD/CAM) technology to automate product design and development. Almost
every product development organization has leveraged CAD geometry creation tools — first 2D drafting
packages, and today, as 3D solid modeling systems. Today, solid modeling is most common to automate
the development of engineering drawings and to document production models, compress design cycles,
reduce prototype development costs, and improve product quality. While CAD/CAM tools have helped
many manufacturers realize substantial productivity gains, cost reductions, and time savings, they seldom
incorporate the unique knowledge, experience, and know-how gained over time. Often inclusion of such
knowledge is an increasingly valuable part of the product development process (PDP). In most
organizations, typically, an engineering design is separated from CAD or “detailing of design.” Engineers
often come up with the design in the form of a set of new/modified concepts and a set of new/modified
cross-sectional profiles or sketches. They pass those artifacts to the CAD/CAM designers. The CAD
designers use CAD/CAM tools for detailing the geometry of the parts. The fact is every time, these
engineers design a new product, they must rely on the presence of their mind to incorporate the
company’s product development knowledge, best practices, and experience into the products.
1.2.2 Situation Analysis

Even those manufacturers that utilize legacy design geometry for new product development, refining prior
designs with each product cycle, cannot do so in an automated, managed fashion that applies the
knowledge the organization has accumulated over the years in terms of formalized rules and unique
automated processes. This valuable information is often stored in the engineers’ minds (see Figure
1.2.1.) or tucked away in a file cabinet, and many manufacturing concerns have either lost valuable
design knowledge when engineers retire or leave the company or experience unnecessary development
delays because of the need to go back and implement these rules and processes late in the development
cycle.
Page 16
Figure 1.2.1 : A Typical Manual-based Product Development Process Scenario
The need to capture, manage, and utilize design knowledge and automate processes unique to a
manufacturer’s product development experience has led to the development of knowledge-based
Engineering (KBE) technology.
1.2.3 Text Book Definition of KBE

“Knowledge-based Engineering (KBE) is a methodology for capturing life-
cycle intent about an object or an artifact (such as a part), including
operational, functional and performance concerns in addition to capturing its
parametric geometric variation. Later when the part or object is instantiated,
with a set of input specifications, the captured knowledge is kicked in to size,
to verify and finally to satisfy the relevant X-ability and life-cycle concerns on
the part generated through this process.”
Ref: CE Fundamentals Book, Vol. 2, pp. 298., 1996
Competitive pressures in a global economy are making product lifecycle management (PLM) a critically
important technology component for today’s manufacturers (see Figure 1.2.1). Often PLM is a living,
evolving process for each product we manufacture. KBE is the solution for managing that process easily,
efficiently, and cost-effectively. CATIA V5, provides an array of common KBE tools to capture such PLM
processes—from concept to engineering to manufacturing—knowledge (see Figure 1.2.2).
KBE provides the solution for tying all product development technologies and processes together,
automating product design, maintaining product quality, capturing and managing product knowledge, and
providing manufacturers with a distinct competitive advantage.
The KBE developers often use a high-level authoring tool—often a language-based KBE tool to capture
all sorts of knowledge elements, to organize products and processes, and link them systematically.
Page 17
Figure 1.2.2 Role of KBE in Capturing PLM Knowledge

1.2.4 Purpose of KBE?
The purpose of KBE is to provide a specialized design environment to the users for capturing product life-
cycle intents. The design environment of KBE is commonly provided in a form of a high-level language or
commands. Using such high-level language, it is much easier and faster to automate certain PLM, CAE
and PDM -- product design functions, apply formal design rules and constraints, and leverage the
company’s design and manufacturing experience. The goal of KBE technology is to provide design
organizations with a high-level programming environment for capturing and infusing this valuable
knowledge into its product design processes and to engineer2manufacture products with more consistent
product quality and increased production efficiencies.
KBE is a mature methodology that bridges the gap between knowledge management and design
automation, integrating their best features with today’s proven product development tools—PLM (referred
previously as CAD/CAM), CAE (computer aided engineering), PDM (product data management), and
ERP (enterprise resource planning). With proper use of KBE, it could provide real results to some of the
biggest challenges manufacturers and engineering organizations face today.
1.2.5 References
[1] Rogers, Jeff “Getting the Most Gains Out of Knowledge-based Engineering – Parker Aerospace
Experiences”, 2004 Annual Conferences & TechniFair, April 25-28, Fontainebleau Hilton Resort, Miami
Beach, Florida, 2004.
[2] Prasad, B., 1996, Concurrent Engineering Fundamentals: Integrated Product and Process Organization – Volume
I, Prentice Hall PTR, Upper Saddle River, New Jersey.
[3] Prasad, B., 1997, Concurrent Engineering Fundamentals: Integrated Product a Development – Volume II,
Prentice Hall PTR, Upper Saddle River, New Jersey.
[4] RuleStream KBE Architecture White Paper on “The New Generation in Knowledge-based Engineering
(KBE) and Design Automation Technology” RuleStream Corporation, Wakefield, MA, 2003-2004
Page 18

1.3 KBE Tools
CA
Co-Author: Francois Riche Dassault Systems, France
Revised By:
Edited By:
Edited By:
Reviewed By:
Page 19

1.4 What is KnowledgeWare?
CA
Co-Author: Francois Riche Dassault Systems
Revised By:
Edited By:
Edited By:
Reviewed By:
Page 20

Chapter 2: KBE Concepts
2.0 KBE Concepts
2.1 Capturing Engineering Intent BP AM1
2.2 Morphing Strategies BP
2.3 How to represent Knowledge? - AM1
Modularization of Knowledge
2.4 Knowledge-centered KBE versus CAD- AM1
centered KBE
2.5 How KBE Differs from Parametric , BP
Relational, (Variational) CAD
2.6 How independent should knowledge be from AM1
the tool (environment)
2.7 Top-down philosophy (I-CAD) vs Bottom-up AM1/JP
Philosophy (V5)
2.8 How to model knowledge (before constructing an
application)
2.9 Moka AM1, Ray Ray
ANDERSON ANDERSON
2.0 Introduction
CA
Co-Author:
Revised By:
Edited By:
Edited By:
Reviewed By:
Many of you may have come across numerous ways of “doing automation”. Numerous ways of “linking
two dissimilar systems”, “coupling two domains (disciplines) or programs”, “two databases”, or “building
an automated design systems.” You may have noticed that some ways of “automation and integration”
gives better “flexibility and adaptability” than others. Likewise, there are many ways of building an
“application”, which performs one or more of the above automated functions. Not all such automated
applications, however, results in good KBE applications. KBE applications are different in many aspects.
KBE possesses some unique set of characteristics [see Ref. 1-6] that distinguishes it from the rest (of the
automated applications). Before, we explore further about its (KBE) characteristics; let us review first a
textbook definition of KBE [3].
Page 21
2.0.1 Characteristics of Traditional Design Automation

Approaches
Traditional design automation approaches can be characterized either as piecewise automation or a
tightly coupled, hard-coded procedure-based programming.
Some design automation programs simply use Visual Basic, C++, or a CAD macro language (e.g.
CAA) in conjunction with equations and design tables to enable engineers to automate certain
CAD tasks and geometry creation routines.
Other automation approaches involve retentions of knowledge by domain experts who
communicate with computer programmers to apply that knowledge in the form of custom-
developed design automation applications. [Ref 1. ]
Figure 2.0.1 Procedural versus Modular mode of Automation Approaches
2.0.2 Differences between Conventional Programming and

KBE
Most traditional design automation approaches suffer from lack of the dynamic nature of product
development formulation. Whenever anything about a product model changes, computer programmers
are needed to update the computer code. The approach is referred as “conventional programming” where
programmers need to hard-code all possible “use-scenarios.”
Since most traditional applications are outside of the strategic PLM systems, they do not communicate
effectively with the company’s strategic CAD, CAE, or PDM systems. In short, traditional design
automation approaches suffer from “knowledge gap and communication lag”. The process is not dynamic.
Rules do not reconfigure when knowledge about its existence change. In other words, whenever new
knowledge is discovered or when old knowledge is to be replaced with its new counterparts, the custom-
developed program has to be manually updated at additional cost and delay. By the time a design
automation program is completed, it’s often obsolete, providing little flexibility for change and evolution in
product development.[Ref. 1]
Page 22
Figure 2.0.2: Procedural Mode of Automation and Knowledge Integration
2.0.3 Differences between Excel Spreadsheet and KBE

A shortcut often taken by engineers frustrated by the amount of programming required during “traditional
design automation approach” is to link spreadsheets and CAD models. The Microsoft Excel is one of the
first tools engineers often use to experiment with and to implement “traditional design automation”. This is
because every engineer can relate to the capabilities of Excel and they are quite familiar with it.
There are several commonalities between Excel and KBE systems, and both take the modeling
capabilities to a level much better than “traditional design automation”. Let’s see how this is done in
Excel. First of all, an end-user defines a replica or a model of a physical or abstract system (say, in excel
using formula in cells and conditional rules). By creating such Excel models, end-users can now enter or
change values for model parameters, use rules to calculate the effect of the parameter values, and then
produce results derived from them. In most electronic spreadsheets (as in Excel), the language is
declarative rather than procedural. This means that the order of operations needs not to be specified. The
system figures out the order needed from the relationships defined by the formulas, just as a spreadsheet
program does when it re-calculates the model upon a change of values entered in a cell.
Unlike spreadsheets, KBE models are, however, object-oriented (O-O). Instead of using a matrix of cells
to organize the data, the KBE modeler organizes data into named objects. This allows creation of a
practically unlimited variety of topologies for the dependency network that links the elements of the model
(components and relationships). In addition to this characteristic, essential to the modeling of engineering
rules, the entire major attributes of the object-oriented paradigm: abstraction, encapsulation, modularity,
and hierarchy are included. KBE models differ from most general-purpose O-O languages in being
primarily declarative rather than procedural in nature.
2.0.4 What characterizes a true KBE Application?

If we understand to deal with the differences in building an "automated application", one using a “traditional approach”
and a second one using “KBE Technology,” we would then be in a better position to compare and contrast their
obvious similarities and differences [see refs. 5-6]. We would be able to appreciate the underlying benefits KBE
technology brings to the PLM community at large.
Page 23
KBE is still new and emerging concept. We need to understand what we can do with KBE and how can we do those
more “efficiently and generically” so that it is “portable,” and succinct. You don’t want your KBE application to become
a maintenance nightmare in a short span of time. Meaning, the KBE application should not suffer from frequent code
changes.
DYNAMIC, GENERIC, GENERATIVE, HIGH-LEVEL, and DEMAND-DRIVEN are FIVE words that have greater
meaning in KBE.
I believe, they (the FIVE above) represent a set of characteristics (call it a set of enablers) for qualifying an
application to be a true KBE application [see Refs. 4-5]. There are many ways of building a KBE application. One can
build an application using KTI/ICAD IDL language. Many of us --old timers have done that. One can do an application
in VBA, many of us done that too. One can built an application in VB Scripts. Some of us have done the same using
in KnowledgeWare Tools. Some of us had done it using PKT/GScript Language. Some of us have done using CATIA
V5 Templates. In fact, I could submit to you there are many ways of doing (building a KBE application) even with our
CATIA KnowledgeWare tools set (KWA, KWE, PKT and BKT).
Then, the real question is how should you build this application so that your resulting “KBE” application have (by
inheritance) the above FIVE qualities?
That your application is dynamic. Rules reconfigure themselves or the outputs based on input changes.
That it (your application) is Generic.—many new, known or unknown cases can be derived from one model or a
“just-one” code representation.
That it’s generative. -- New rule bodies (or models) are created automatically from the old ones (e.g. model
templates) based on changes in input specifications.
That it’s high level. A small amount of KBE code (in the form of high-level instructions or language) produces
significant results (manipulating a large number of objects)
That it’s demand-driven. System (knowledge-engine) knows the sequence in which rules become active and
controls how those rules get fired. Thus, relieving the users (Kegs) to worry about (program) or to control the so
called “rule sequencing” themselves.
Today, there exists numerous standalone programs written in C++; Visual Basic and Excel spreadsheets
[see Ref. 2]. While these automation solutions satisfy specific product development needs, they are often
not part of a system solution nor are they integrated into the mainstream of PLM –say at an enterprise
level. As such, any of them could not be called a true KBE Application. Many of such automated solutions
present serious shortcomings (like maintenance nightmare) and many disadvantages (like excessive cost
of integrations and maintenance) compared to the new generation of KBE technology having the above
set of FIVE built-in qualities.
2.0.5 References
[1] Parker KBE Architecture White Paper on “Knowledge-Driven Automation Program”, Parker Hannifin
Corp, Irvine, CA. 2004-2005.
(KBE) and Design Automation Technology” RuleStream Corporation, Wakefield, MA, 2003-2004.
[3] Prasad, B., “Concurrent Engineering Fundamentals: Volume 2: Integrated Product and Process
Development, Chapter 6 – Capturing Life-Cycle Intent and KBE, Prentice Hall, 1977.
[4] See COE/KBE Focus Group Discussion Thread:
http://www.coe.org/forums/messageview.cfm?catid=19&threadid=6412
[5] Rogers, Jeff “Getting the Most Gains Out of Knowledge-based Engineering – Parker Aerospace
Experiences”, 2004 Annual Conferences & TechniFair, April 25-28, Fontainebleau Hilton Resort, Miami
Beach, Florida, 2004.
[6] Prasad, Brian “Knowledge Driven Automation”, Enterprise Engineering Systems, ParTech 2004, June 23 - 25,
2004, Sheraton Hotel Cleveland Hopkins Airport, Ohio, 2004.
Page 24

2.1 Capturing Engineering Intent
CA
Co-Author:
Revised By:
Edited By:
Edited By:
Reviewed By:
Page 25

2.2 Morphing Strategies
CA
Co-Author:
Revised By:
Edited By:
Edited By:
Reviewed By:
Page 26

2.3 How to represent Knowledge? - Modularization of
Knowledge
Contributing Author: Alexandre Carvalho de Moura Product Development
Engineer, CAE
Applications
Embraer - São José dos
Campos
Co-Author:
Revised By:
Edited By:
Edited By:
Reviewed By:
In typical Expert Systems (ES), and in KBE applications knowledge is fundamentally expressed by means
of if then else rules, as the former is an inheritor of the ES.
However in order to be effective the rules must be contained in a base that can be easily managed, i.e.
easy to update and easy to expand.
Rules also need a shell to organize them and allow them to connect themselves for achievement of a
result. Such a shell is referenced as the inference engine. Inference is the mean by which the rules can
be combined together in order to answer a specified question from the user, as whenever one for
example guesses:
‘What if I increase the rib cap thickness by 2 mm?
If the rule base (knowledge base) is sufficiently complete it should be able to react correctly to the user
request, producing results based upon the chaining of the rules aided by the inference engine.
Once more there comes the Artificial Intelligence (AI) with its concept to help us. The Object Oriented
(OO) paradigm, that supports the programming languages of the main KBE vendors was born in the AI
context, as a form of knowledge representation and originally named as ‘Frame. For more details
concerning Frames, see 2.9.1 Ref 1.
Frames essentially consist of a set of attributes which describe the properties of an object represented by
the frame. The values assigned to the attributes can be other frames, resulting in interdependency
between the frames. The frames can also be organized in a specialization hierarchy, creating an
inheritance relationship. In the example shown in the Figure 2.3.1 the frame living-room is a
specialization of the frame room and inherits all his attributes.
Frame: room Super Frame: Covered Compartment

Attributes Default Type
Page 27
N of walls 4 Integer
Shape rectangular Symbol
Height Real(m)
2
Area Real(m )
3
Volume Real(m )
Frame: living-room Super Frame: room

Attributes Default Type
Furniture (sofa, table with chairs) List-of-symbols
Function social relationship symbol
Figure 2.3.1 – Representing knowledge by means of Frames

‘Frames are considered by many authors as a sort of inference engine as it can be infers from a set of
statements simply using his paradigms of inheritance, specialization, messages, methods (behaviors),
overriding and encapsulation.
The CATIA V5 technology does not specifically provides neither a repository for rules nor an OO
language or any type of inference engine. CATIA provides an associative structure of features that can
behave as objects.
A User Defined Feature (UDFs, see item 7.2) for example consists of a template which can encapsulate
product data based upon more basic CATIA native features in order to produce more specialized results.
Templates, as well as typical objects of the OO paradigm, can be instantiated by having their inputs filled
in. Once instantiated the templates can share their attributes by publishing their parameters and provide
additional outputs.
Engineering Knowledge can be stored in a CATIA template by means of parameter formulas and
KWA rules. Configuration and geometry related knowledge can also be captured by the process
of construction embedded in the UDF.
2.3.1 Scenario
Actually the idealization of a CATIA V5 application by means of small building blocks, such as the UDFs,
is a way to represent the knowledge associated with the product using objects, each one with its related
knowledge.
Let us considerer for example a CATIA V5 application for typical machined wing ribs (see Figure 2). A
wing rib can be represented by a set of features listed below:
 Web Shell
 Horizontal web stiffeners
 Vertical stiffeners
 Stringers cutouts
 Lightening holes
Page 28
Figure 2.3.2 -Machined Wing Rib
Each of these features can be treated as individual components (objects, templates or UDFs) with their
related knowledge. In order to exist (to be possible to instantiate them) the UDFs need some mandatory
inputs.
The knowledge associated to each component, including geometry construction and design/engineering
rules, can be represented using structures similar to Frames, with some additional slots, as follows:
UDF Web shell

Inputs Parameters Type Rules/Knowledge
Upper Skin Upper cap thickness Real(mm) Geometry Engineering/Design
Lower Skin Lower cap thickness Real(mm) Sculpt the
Front Spar Plane Upper cap width Real(mm) block by
Rear Spar Plane Lower cap width Real(mm) splitting it
Rib Reference Plane Web thickness Real(mm) by upper &
lower Skin
Surfaces
UDF Vertical web stiffener

Inputs Parameters Type Rules/ Knowledge
Initial positioning Width Real(mm) Geometry Engineering/Design
Final positioning Height Real(mm) Linear
curve
connecting
end points
on the skin
surfaces
UDF Horizontal web stiffener

Inputs Parameters Type Rules/Knowledge
Page 29
Positioning Width Real(mm) Geometry Engineering/Design

Upper or lower skin Height Real(mm) Offset from  Minimum distance
curve upper or from the skin curve
lower skin <= C mm
intersection
curve
UDF Stringer cutout

Stringer curve Width Real(mm) Geometry Engineering/Design
Stringer height Height Real(mm) Intersection  Height=2*radius
Radius Real(mm) point  Height = 1,2*
between stringer height
stringer and
skin curves
UDF Lightening hole

Limiting stiffener Hole corner radius Real(mm) Geometry Engineering/Design
curves Hole shape  Corner radius <=
controlled minimum distance
by offset of between stiffeners
the stiffener  If minimum distance
curves between stiffener<X
then deactivate hole
2.3.2 Benefits of knowledge modularization

The modularized approach previously presented makes the knowledge more manageable and organized.
It’s easier to update and maintain the knowledge base, as it’s done in smaller building blocks.
Furthermore it’s not necessary to reconstruct or modify the whole application when the knowledge need
to be updated or some fix in the geometric construction process is needed.
Modularization also offers knowledge protection from those who may corrupt it or violate it. It’s a
guarantee that a validated process is going to be respected.
2.3.3. Drawbacks and challenges

Even though the knowledge involved in a typical wing rib application can be represented by a structure of
objects which can exchange data each others, one of the most powerful aspects of the OO paradigm, the
inheritance, is not fully available in CATIA V5.
A more complicate situation can arise if the capture of more complex knowledge in an application is
required in such a way that rules individually embedded in UDFs are not sufficient to represent the whole
knowledge involved. That happens when rules involving more than one UDF which does not exchange
data each other need to be created, as for example a rule that checks the intersection between two wing
rib web stiffeners and takes a decision. The solution required in this case would be the creation of a huge
UDF that would encapsulate all features or the creation of a separate rule in the application either using a
KWA VB macro in a reaction or a VB macro. Huge UDFs are difficult to maintain and update and keeping
them robust is not a straightforward task.
Page 30

2.4 Knowledge-centered KBE versus CAD-centered
KBE
Engineer, CAE
Applications
Campos
Co-Author:
Revised By:
Edited By:
Edited By:
Reviewed By:
Traditional old KBE frameworks, as ICAD for example, forces the Knowledge engineer to initially conceive
an abstraction of the product, establish a mental model, representing it in a programming language
proper for knowledge representation and then obtaining its graphical representation. That was usually
the approach of having a code editor separate from the main browser that works as the graphical kernel
interface of the product. In this type of architecture there’s a CAD engine that establishes a client server
relationship with the knowledge base. That’s what one usually calls by a Knowledge Centered KBE
approach.
On the other hand, experienced designers, who are used to manipulate traditional CAD softwares with
wide visual interfaces resources, represent substantial part of the KBE experts in industry. These may
prefer the traditional CAD UI resources as they feel more comfortable to initiate the product conception
from a draft, directly defining very basic geometric components to represent his mental model. And then
from the basic topology the rules controlling the product definition can be plugged in. In this case there’s
no clear distinction between the graphical representation environment and a shell that holds the
knowledge base. This approach is usually considered as a CAD centered KBE approach and is adopted
by Dassault Systemes (DS) in the CATIA V5 Knowledgeware technology with his knowledge features.
In a CAD centered approach, the process of representing knowledge is not creating abstract objects but
creating geometry (CAD) that will further receive rules associated to it. The geometry will them be
generalized, turning itself to a template for constructing different configurations.
2.4.1 Advantages and Drawbacks

It’s not intention of this best practices document to discuss the best approach to be adopted in place of
the other, but indicate the main aspects of both.
Knowledge centered KBE does not limit the knowledge architect over the topology point of view.
Knowledge centered makes the KBE engineer think about the why and not the what of the
engineering product.
Page 31
CAD centered approach forces the KBE engineer to start from a CAD model when defining an
application, unlike the knowledge centered approach which make the application arises from an
problem abstraction.
The CAD centered approach focuses more on the visual aspect of the knowledge; shape based,
making the engineering design process more transparent to the designer.
The CAD centered approach makes the designers feel more comfortable to capture knowledge
as they usually get scared with the possibility of writing code lines.
The CAD centered approach can be easier and faster to prototype as it uses more interactive
tools for product construction. Nevertheless that can be more painful if the capture of more
complex knowledge rules in the product are needed, as there’s no formal way to represent
knowledge. In CATIA V5 that capacity is provided by specific features spread through the
knowledgeware workbenches.
On the other hand interactivity is not an enemy of the knowledge centered approach.
One of the great advantages of the Knowledge centered approach is that the knowledge is independent
from the geometric model, allowing it to be represented in multiples CAD platforms by means of neutral
format files. That’s where the MOKA methodology can come to scene.
Page 32

2.5 How KBE Differs from Parametric and Expert
System.
Contributing Author: Brian Prasad KBE Architect, Parker
Aerospace, Irvine, CA.
Co-Author:
Revised By:
Edited By:
Edited By:
Reviewed By:
2.5.1 Historical Perspectives:

Historically, Parametric Engineering (PE) was often an enhancement to the macro languages
introduced in CAD systems in the 1970s. The purpose of the macro languages was to provide
the designer (non-programmer) with tools to automate repetitive design tasks. These macro
languages proved to be too difficult to use for most designers; however, the benefits of
automating repetitive tasks was clear to everyone.
PE technology automated creation of CAD geometric models through algorithms and procedures
that map a pre-defined set of inputs to a pre-defined set of outputs in a generalized fashion. The
goal of PE was to automate the design of families of components, sub-systems, and systems with
similar geometric characteristics. The mapping transformations, which formed the knowledge-
base in a PE system, were generally first order and based on well-known paradigms and
procedures. This knowledge was typically hard-coded in a computer program, and was very
difficult to update and maintain. The advantages of a PE system included reduction in design
time and reduction in design variations. PE systems required a substantial amount of domain
knowledge, where the domain knowledge was fairly static. Therefore, PE systems typically
automated designs based on a priori procedures and did not provide creative solutions to
dynamic problems.
Historically, Expert Systems employed a set of artificial intelligence and statistical tools to
perform reasoning at near human level. Technologies such as expert systems, genetic algorithm,
case-based reasoning, neural nets, fuzzy logic, and blackboard systems were employed to
emulate various forms of reasoning and knowledge representation/utilization.
Today, leading CAD systems are now offering more generalized PE, Expert System and
constraint-based tools all in one called Knowledge-Based Engineering (KBE). In such tools no
differentiations is the made between PE APIs, and KBE APis, and knowledge access or solving
Page 33
algorithms or methods. Most CAD systems have developed a set of generalized KBE APIs, and
other tools to automate designs. Specialized systems (e.g., ICAD, Intent, TK/Solver and
Knowledgeware) have also demonstrated a large market opportunities for leveraging KBE
technology in product development domain.
Today, KBE technology focuses on solving hard problems that typically require human
experience and intuition, e.g., learning, pattern recognition, classification, scheduling,
configuration, and optimization. KBE systems solve both the non-geometric and geometric
problems.
2.5.2 What KBE Offers?

Besides adding value by automating design process, KBE offers other benefits including
capturing human expertise, inference, learning, and solving complex engineering problems.
Previously, PE was applicable in the Detail Design phase, and ES was applicable in the
Conceptualization phase. Today KBE covers the entire PLM domain from idea to grave.
The business value of KBE is to reduce the time taken in the entire life-cycle process and reduce
design variations by implementing common design standards, parts, and procedures. Such
savings are highly quantifiable and quite significant.
It must be noted that in the Conceptualization phase, a typical release engineer may propose
multiple design alternatives via KBE. Usually, the initial designs are not perfect, resulting in
many feedback loops in the design process. Thus, via KBE the search for an optimal concept
could be based on a number of algorithms-- trial & error, the intuition and experience of the
release engineer, or illusive altogether. KBE thus adds business value by proposing better design
concepts, hence reducing design time and costs be minimizing the feedback loops in the design
process.
2.5.3 References
Kasravi K., Understanding Knowledge-Based CAD/CAM, CAE Magazine, October 1994.
(KBE) and Design Automation Technology” RuleStream Corporation, Wakefield, MA, 2003-2004.
[3] Prasad, B., “Concurrent Engineering Fundamentals: Volume 2: Integrated Product and Process
Development, Chapter 6 – Capturing Life-Cycle Intent and KBE, Prentice Hall, 1977.
Page 34

2.6 How independent should knowledge be from the
tool (environment)
Engineer, CAE
Applications
Campos
Co-Author:
Revised By:
Edited By:
Edited By:
Reviewed By:
Page 35

2.7 Top-down philosophy (I-CAD) vs Bottom-up
Philosophy (V5)
Engineer, CAE
Applications
Campos
Co-Author:
Revised By:
Edited By:
Edited By:
Reviewed By:
Actually this subject is strongly related to the Knowledge Centered and the CAD centered approach
discussed in the item 2.4.The first approach starts to conceive the application from the knowledge (rule
base) that, together the requirements are considered as being the top of the product definition. The
former one forces the KBE developer to start the definition of the product by the shape itself, not by the
functions it will perform. That was supposed to happen at the end of the process of its definition.
Experienced CAD designers which became KBE engineers may, however, find difficult to adopt the top-
down philosophy, starting an application from the rules, as they always worked under the product
topology point of view.
One may think that CATIA V5 limits the feasibility of adopting the top-down philosophy due its CAD
centered approach. However, the relationship between the building blocks composing the product
objects/components as well as the design process involved can be architected before the application is
developed and as will be seen in the next section, that can result in lots of benefits.
This issue is strongly related to the availability/existence of an effective methodology for modeling the
knowledge,
Page 36

2.8 How to model knowledge (before constructing an
application)
Engineer, CAE
Applications
Campos
Co-Author:
Revised By:
Edited By:
Edited By:
Reviewed By:
In addition to an affective methodology for Knowledge Modeling some existent graphical

modeling languages, such as UML (Unified Modeling Language) and SysML (Systems
Modeling Language) are widely adopted for general OO applications architecture. These
graphical representations are quite useful in representing objects of an application and how these
objects relate each others. By using a common specification graphical language to represent the
business process of an application or system one can easily specify, design, verify and validate
the system as a whole.
As it will be seen in the next section (MOKA) an extension of the UML language has been made
in order to better adapt to the KBE context, especially concerning the knowledge capture and
management.
Page 37

2.9 Moka
Engineer, CAE
Applications
Campos
Co-Author:
Revised By:
Edited By:
Edited By:
Reviewed By:
The MOKA project, whose acronym stands for Methodology for Knowledge Based Engineering
Applications, was created in 1998 in order to provide a way of reducing the amount of investment for
development of a KBE application (see 2.9.2 Ref 2).The project resulted in a methodology that provided a
way of representing engineering knowledge by means of models and a software to support this.
In spite of the fact the MOKA methodology hasn’t succeed in providing an effective tool for automatic
code generation for KBE applications, it represents today an efficient methodology for Knowledge
Management bringing benefits for lots of companies that considerer the knowledge as his main wealth.
The MOKA approach when incorporated in a software tool proved to be efficient in identifying the called
raw knowledge in the company, i.e. the knowledge on the form of documents, spreadsheets, charts,
diagrams and even from the design expert’s minds, creating clear representations (models) of that
knowledge in a such way it can be more computer-understandable.
Besides promoting the validation of the corporate knowledge, MOKA allows a structured process of
knowledge reuse and sharing, publishing it and disseminating it through the company. MOKA acts just on
that situation considered critical and encountered by all big companies that need to be competitive in
developing new products. As depicted in Figure 2.9.1, knowledge is usually hard to access and find; lots
of money is lost when someone leaves the company; even if the knowledge is accessible, most of times
it’s disorganized and hard to understand and use.
Page 38
HARD TO ACCESS VOLATILE
KNOWLEDGE UNPROTECTED
HARD TO USE
DISORGANIZED
Figure 2.9.1- The Knowledge
The MOKA methodology consists of the capture of the engineering product related knowledge in two
models: Informal and Formal model
2.9.1 Informal model

The informal model is represented by means of the so-called ICARE forms separately for the product and
the process. For more details see 2.9.2 Ref 2.
2.9.2 Formal Model

According to 2.9.2 Ref 2 the formal model is “a graphical object-oriented representation of engineering
knowledge at one level of abstraction above application code”. This graphical representation, so named
“view”, uses the UML-derived language MML (Moka Modelling Language) and is created from the
Informal model (ICARE Forms). Likewise the Informal model the Formal model represents separately the
product and the process knowledge related to an engineering product. For the scope of this best
practices document focus will be given on the product knowledge instead of the process knowledge.
2.9.2.1 Formal Product Model

The Formal Product Model is structured in five views:
 Structure View (how the product is structured)

 Function View (what the product does)
 Behaviour View (how the product behaves)
 Technology View (materials and manufacturing)
Page 39
 Representation View (geometry: size, shape, position)
For a detailed description of all views see 2.9.2 Ref 2.
2.9.3 CATIA and MOKA

It’s clear that a direct application of the MOKA methodology on CATIA V5 applications can be performed
through the Structure and Representation views. As relevant components of the product related
knowledge, the product structure and the geometric representation can be easily conceived by means of
the Structure and Representation views MML diagrams.
2.9.3.1 Structure View

Just as in the CATIA V5 product tree the Structure View is represented by the following types of objects:
 Product,
 Assemblies
 Parts
 Composite
 Features
These objects are linked by relations of type “composed of”.
 A product is composed of assemblies and/or parts

 An assembly is composed of parts and/or other assemblies
 A part is composed of composite features and/or features
 A composite feature is composed of features and/or other composite features
2.9.3.2 Representation View

The Representation View depicts essentially the strategy of construction of product geometry,
representing the knowledge concerning the size, shape, positioning, and relations associated to
assemblies, parts and features.
The Representation View is composed of the following objects:
 Geometry
 Complex Geometry
 Simple Geometry
 FEM (finite element entity)
The objects contain properties, i.e. attributes, in order to better describe the geometry and the
components:
 Diameter, length, width, height, thickness

 Position
 Orientation
 Geometric operator
These objects are linked by relations of type “composed of” and “is a”.
 A box is a simple geometry
 A pad is a complex geometry
 A fuselage tail is a complex geometry
Page 40
2.9.3.3 Example
As a demonstration of application of the MOKA methodology in the aircraft industry scenario one can
exhibit the process of geometric modeling of the machined wing box rib shown on Figure 2.3.2 in a
Representation View. A wing rib is constructed basically from a thick plate split by two aerodynamic
surfaces. Additionally, lightening holes and web stiffeners can be included.
The rib web stiffeners can be created using the rib feature in CATIA V5 mechanical design workbench,
which takes as inputs the profile sketch and the guide curve. The profile sketch can be a very simple
geometry, as a rectangle for example. The guide curves can be either simple lines (for a vertical stiffener)
or offsets from the upper rib profile curve (in case of horizontal stiffeners). In fact any other rule can be
adopted in this case.
The lightening holes can be constructed by subtracting Pads from the rib web plate. Pad is also a feature
in the mechanical design workbench which takes as input a sketch profile and the depth of extrusion. The
profile sketch is created from four arcs and four lines, which can be offsets of the related stiffener curves.
The MOKA Representation View of the process of creation of a wing rib is depicted in the Figure 2.9.2.
Page 41
Figure 2.9.2 – Wing Rib Construction Representation View
2.9.3. Concluding Remarks

As CATIA V5 does not effectively provide a programming language it might be difficult to choose the best
strategy in order to capture the geometry construction process, from the representation view into a CATIA
KBE application. The entire process can be captured in a sequence of VBA instructions or even be
modularized in sets of UDFs.
Even though the automation of code generation in whatever language is still a dream, some kind of direct
translation of the objects either of the Structure View or the Representation View into a CATIA application
can be imagined using neutral format files as XML for instance. However it’s not the purpose of this best
practices directives document to teach how to perform such an automation task, but unlike that try to
indicate the route of solution.
Even so the MOKA methodology brings some clear benefits inside and outside the KBE community:
 Easy Identification of lack of consistency in the design process

 Reduction of developing cycle time of KBE applications, as the application architecture is an output of
the methodology
 Promotes the validation of knowledge with experts
 Makes the knowledge more understandable
Page 42
2.9.4 References
2.9.1 Ref 1-Inteligência Artificial-Ferramentas e Teorias, Guilherme Bittencourt.Chap. 5, item 5.5.3;
2.9.2 Ref 2-Managing Engineering Knowledge, MOKA: Methodology for Knowledge Based Engineering
Applications. Edited by Melody Stokes for the MOKA Consortium;
Page 43
Chapter 3: KBE Rule Languages

3.0 KBE Rule Languages
3.1 KWare Language Francois BP DB
Riche
3.2 GenSCript Francois BP DB
Riche
3.3 VB Scripts & VBA Francois BP DB
Riche
Page 44

Chapter 4: Feature-based Modeling
Concepts
4.0 Feature-based Modeling
Concepts
4.1 Parametric Design (is like simple CAD-pure BP
geometry modeling)
4.2 Parametric Templates (is like Part Templates, BP
if only pure geometry is involved) A top down
modeling concept. Adding and Linking
independent parameters with a Parametric Design.
4.3 Part Geometric Features -- UDF &
PowerCopy
Page 45
Chapter 5: Assembly Modeling Concepts

5.0 Assembly Modeling
Concepts
5.1 Assembly Geometric Templates FM
Page 46

Chapter 6: Problem Definition
6.0 Problem Definition
6.1 Generic Modeling Strategies BP
6.2 Generalizations versus Specific Cases BP
6.3 Systems Engineering Approach (very BP
interesting!)
6.3.1 Problem Decomposition BP
6.3.2 Problem Aggregations BP
6.3.3 Problem Solutions Strategies BP
Page 47

Chapter 7: Rule-based Modeling
Concepts
7.0 Rule-based Modeling
Concepts
(This talks about how we go about adding non-
geometric features. A template could be more
than a parametric part. )
7.1 Template-based Modeling BP
7.2 How to construct Templates? JP
7.2.1 Making templates Robust JP
7.2.2 Generic utility parts JP
7.2.3 Methodology for Templates JP
7.2.4.VB Scripts JP
7.2.5 Reactions and VBScripts JP
7.2.6 Publications – parameters & geometry to JP
publish
JP
7.4 Components-based Modeling
Page 48

Chapter 7: Rule-based Modeling
Concepts
7.2 How to Construct Templates?
Contributing Author: João Paulo Rebucci Lirani Technology Development
Engineer
Campos
Co-Author:
Revised By:
Edited By:
Edited By:
Reviewed By:
Templates are en efficient way of embedding knowledge for parts which are of not great
complexity and allows reuse of designs to other Products. There are two types of Template
entities in CATIA V5 for Part level:
 PowerCopy (PWC)
 User-defined Feature (UDF)
Powercopies (PWCs) are very similar to UDFs, both encapsulates all the knowledge to make it
work. But, Powercopies do not hide knowledge inside it, that is, all design operations registered
in a Powercopy are exposed to the user after instantiation. In UDF, knowledge is hidden. UDFs
are displayed as a “block” in Product Tree -- like any other Catia feature (like Pad or Line),
allowing all knowledge to be hidden and exposing only the published set of user parameters.
 For templates that are instantiated extensively throughout the Product Tree, UDFs are
recommended because it helps to organize the structure.
 Another advantage of UDFs is the possibility to have multiple outputs, while
powercopies usually concern one output (although it displays all the objects inside it).
 Another drawback for PWCs is multiple instantiation: once there is more than one PWC
in the model, naming convention becomes a problem. As geometrical entities and
parameters are created in Product Tree, entities names are changed to .1, .2, etc, losing
associativity. This could be solved using an UDF.
Throught a KBE perspective, UDFs are preferred to PWCs. The major drawback for using PKT
is licence costs. PWCs may be used and instantiated using regular HD2 licenses (no special
license) , while UDF require PKT licence for development and KT1 licence for production
(instantiation). For more information on PowerCopy and UDF, please consult the Appendix.
7.2.1 Making templates Robust
Page 49
The main objective of this section is building templates that are robust to user interaction, that is,
that work in different environments and do not crash. Also, as these Templates may be used in
automation processes, geometrical ambiguities must be handled inside the template.
The main aspects that have to be considered when building robust templates is :
 Follow a construction methodology (presented furthermore)
 References to vertices, edges and faces (must not use)
 Dealing with geometrical ambiguities
Templates must work in such a way that they are robust to user interaction and geometric
variances. For example, a curve in a support may have two parallel curves associated to it
(inwards or outwards), as showed in fig. 1. Here’s a relation of some geometrical elements that
presents ambiguities:
- curve extremes
- curve orientation
- plane normal
- surface normal
- parallel curves orientation
- parallel plane orientation
- split orientation
Parallel Curves:
which one ?
Original Curve
Fig1. Ambiguity example for parallel curve
Page 50
7.2.2 Generic Utility parts

To deal with geometrical ambiguities, it must be created generic utility parts/templates, that
returns a single unambiguous output.
A generic utility part is an UDF that takes an input and gives one and only output. The way to
eliminate an ambiguity is giving reference information , either geometrical or parameter, and
embedding rules that solves this ambiguity.
Here is a list of suggested generic utility parts:
 Directed curve
 Directed surface
 Directed pad
 Directed Surface split
 Directed Solid Split
 Directed extend curve
 Directed parallel curve
The method for building a generic utility part is:
 Create Inputs
o Geometrical entities
o References
 Build multiple geometrical options
 Create empty Output geometrical parameter
 Create Measure parameters with formulae
 Create a Rule which decides, based on the parameters above, which output will be valid
and passes it to the Output parameter.
Then an UDF must be created in order to encapsulate this knowledge.
7.2.2.1 Illustrative Example

As an example, a generic utility part for parallel curve will be created. Inputs:
 Original Curve
 Support surface
 Reference point
The reference point will indicate for which side the parallel will be created.
Two parallel curves will be created: one for default side and another for opposite side. Two
Length parameters are created, associated with 2 formulae, first parameters measures the
distance between Reference point and default parallel curve. Second parameter measures the
distance between Reference point and opposite side parallel.
Page 51
Then, a KWA Rule must be created to decide whether curve will be chosen: the curve whose
parameter has a smaller length (see Rule below). The chosen one is passed to an empty curve
parameter, which will be the UDF output.
Empty Curve parameter

Figure.2 Part Tree showing organized information
Rule :
if distance(Body\Parallel.1 , Inputs\Point.1 ) < distance(Body\Parallel.2 , Inputs\Point.1 )

{
Output\OutputCurve = Body\Parallel.1
}
else
Page 52
{
Output\OutputCurve = Body\Parallel.2
}
7.2.3 Methodology for Templates

7.2.4 VB Scripts
7.2.5 Reactions and VBScripts
7.2.6 Publications – parameters & geometry to publish
Page 53

Chapter 8: How to architect KBE
Strategies)
8.0 How to architect KBE
Strategies)
8.1 Setting the environment
8.2 Creating parameters, lists, etc.. JP
8.3 Creating Geometry (PartDesign, JP
GSD,Sketcher)
8.4 Exchange between VB and Catia (External JP
Parameters)
8.5 Passing Matching Attributes across BP
Parts/Templates. This is a technique which makes
your KWE Rule generic. If you have a method to
match assigned values of “matching Parameters”
across two parts, you could make your KBE
“scripts” very GENERIC.
8.6 Attributes Linking via Rule Bodies -This a BP
GETATTRIBUTE and SETATTRIBUTE method
used in KWE.
8.7 Exchanging parameters between Catia and BP
external app
8.8 Rules inside VB or Catia (KWA)- Where to AM1 JP
Store Rules?
8.9 Reaction-based Linking (see 8.c.ii) JP
8.10 Instantiating UDFs JP
8.11 Quantification (via VB or Loop) JP
8.12 Update Configurations AM1/JP
8.13 Working with Other Modules (Sheetmetal, JP
Composites, etc..)
Page 54
8.8 Rules inside VB or CATIA (KWA) – Where to store

rules?
Engineer, CAE
Applications
Campos
Co-Author:
Revised By:
Edited By:
Edited By:
Reviewed By:
Actually the way of structuring a KBE application in CATIA V5 is in great part guided by how
and where the rules will be kept. One can still guess if the KWA rules should be preferable
embedded in a UDF or outside it in KWA rule in a CATPart document which handles other
UDFs. Another option would be using VB programming to create the rules associated to the
product by means of macros, reactions with macros, or even VB User Interfaces (UI) with
command buttons that triggers any check.
Thus the following options can be listed

 Rules embedded in UDFs
 Rules outside the UDF, but in KWA rules in the CATPart
 Coding of rules using VB programming
o KWA reaction with macro
o Macro
o VBA form
8.8.1 Rules embedded in UDFs

As described in item 2.1.3, encapsulation of rules inside an UDF provides some benefits, such as
easiness of maintenance, modularization, and protection, among others. When the rule refers to
components which are mandatory for the UDF construction (inputs and construction elements)
the encapsulation of the rule inside the UDF is completely indicated.
Let us considerer for example a UDF that inserts a lightening hole in wing rib web. The UDF
takes as inputs four curves representing four web stiffeners (2 horizontal e 2 vertical), as depicted
in the Figure 3. The hole profile is constructed by means of the inward offset of the curves and
four corner radius. Besides the construction rules which are implicit in the process of geometry
generation two design rules were created as follows:
1) A KWA rule that states that when the minimum distance between the two curves in the
pair of rib web stiffeners (which is less), either horizontal or vertical, is less than a
minimum value the hole is deactivated (see Figure 4).
2) A KWA check that states that when the user chooses a corner radius value greater than a
certain value, a rule based radius is set (see Figure 5).
Page 55
In both cases the rules don’t require any unusable element in the UDF as the elements they
handle are essential elements for the UDF in order to be instantiated. They are particular to the
specific scenario of creating a lightening hole and do not need any external geometric elements
which are not related to the hole geometry.
Figure 3 - Lightenig Hole UDF
Page 56
Figure 4 – Hole deactivation rule
Figure 5 – Corner radius rule
Page 57
8.8.2 Rule in a CATPart outside the UDF

As already mentioned in item 2.3 (How to represent knowledge), if the rules affect one or more
components (UDFs) in the product, and these components are disconnected, an external
independent KWA rule should be created.
As an example let us considerer the scenario concerning the generation of system holes in a wing
rib web. An UDF can be created that takes as inputs the curve representing the system line and
the hole radius associated to it and whose output is a flanged circular hole in the rib web. One
can think about a rule that states that if the minimum distance L between two existing system
lines is less than twice the hole radius R plus a distance d value then a single race-track shape
hole is generated, instead of two circular ones (see Figure 6).
L > 2R + d
L < 2R + d
Figure 6- System Holes rule
Page 58
If the scenario presented is constituted of only two system lines the following steps can be
performed to face this situation:
 Creation of an UDF that takes as inputs one system line curve and the hole radius
and whose output is a circular hole in the rib web
 Creation of an UDF that takes as inputs two system line curves and the hole radius
and whose output is in a race-track shape hole in the rib web
 creating a Length type parameter, editing in it a formula that measures the
minimum distance between the two system lines intersecting points with the rib
web plane
 Creating a KWA rule that verifies if the minimum distance between the
intersecting points is less than twice the hole radius value plus a distance value. If
the statement it’s false, the single hole UDF is instantiated twice, by means of a
VB macro feature for example. If it’s true the race-track hole UDF is instantiated
using a macro likewise (see Figure 7).
L < 2 R + d – race-track hole
L > 2 R + d – circular holes

Figure 7 – System Holes rule
An alternative in this scenario would be the encapsulation of the minimum distance rule within a
single UDF that would morph the hole profile according the minimum distance value. In this
Page 59
case the UDF would always take as inputs two system lines, instantiating two circular holes if L
> 2 R + d or one race-track shape hole if L < 2 R + d. The latter situation will however request
the deactivation of a circular hole for one of the two system lines, forcing us to keep unusable
elements in the UDF.
8.8.4 Coding of rules using VB programming

The scenario presented in the previous section has the limitation of working only when there are
exactly two system lines.
If multiple system lines were present in the product a VB code should be written to test in run
time the distances between all individual lines each others in order to select those pairs of lines
which would fall in the situation of violation of the minimum distance rule. And then, those pairs
should be used as inputs for the race-track shape hole UDF instantiation. For all the remaining
system lines the single circular hole UDF would be instantiated.
The difficulty of using a KWA rule in this scenario resides in the fact that there isn’t a fixed
number of system lines or a single parameter measuring the minimum distance between pairs of
system lines, forcing the creation of a VB loop that, for each iteration, computes in run time the
minimum distance between the pairs of system lines.
8.8.5 Concluding remarks

Whenever the components referred in the rule are either mandatory inputs in the UDF, or
essential construction elements in it, the rule should be embedded in the UDF. Otherwise we
would be forced to include unnecessary inputs adding junk in the UDFs, making them huge and
difficult to manage. Furthermore too many unnecessary components in a UDF take us in the
opposite direction of minimizing performance troubles in the application.
It’s easy to conclude that when more complex knowledge is required in an application one starts
to reach the limitations of the KWA rule feature. In that case one should lay hold of VB
programming.
As a major advice, whenever it’s possible and unless it’s unfeasible the rules should be stored in
KWA Rule features for two reasons:
 They support a high level engineering language
 They offer associativity
 Easiness of managing and maintenance of the knowledge base
8.8.6 References
Ref 3-
Ref 4-
Page 60

Chapter 9: System Solution Strategies
9. System Solution Strategies
9.1 UI (User Interface) JP/AM1
9.2 Optimization inside Catia (PEO) or via VB?
Page 61

Chapter 10: Example Problems
Page 62

Chapter 11: Appendices:
Appendix A: Brief Description
of Tools to Develop KBE in
Catia V5
Introduction DB/BP
Appendix AA:V5 Fundamentals Danny
Bouchard
Parameters DB
Formulas DB
Design Tables DB
Macros in VBA or VB DB
Appendix AB: Knowledge Advisor Danny

Bouchard
Lists DB
Rules DB
Checks DB
Actions DB
Reactions DB
Loops DB
VBScripts DB
Appendix AC: Product Knowledge Template Danny

Bouchard
User-defined feature (UDF) DB
Part Template DB
Assembly Template DB
Generative Script DB
Appendix AD: Business Process Knowledge Danny

Template Bouchard
Technological objects DB
Behaviors DB
Loops DB
BKT app DB
Page 63
Footnote: Note the legends (e.g., BP – Brian Prasad) are short abbreviations. DB: Danny
Bouchard. They are described in Chapter 5 and Sections 5.1, 5.2 and 5.3. RA: Ray Anderson
Page 64

Chapter 11: Appendix A: Brief
Description of Tools to Develop KBE in
Catia V5
11.1 Introduction
Contributing Author: Danny Bouchard Aerospace Practice
Consultant
Dassault Sytemes Services
Co-Author:
Revised By:
Edited By:
Edited By:
Reviewed By:
The main goal of this appendix A is to overview Dassault Systemes CATIA V5 KBE tools and
provides the reader useful means to understand and efficiently use those tools to develop
automated KBE applications for downstream processes. Recommendations for basic and best
approaches to efficiently use those tools are provided.
The appendix A is divided in four different sections. The first section will go trough a quick
overview of the fundamentals and basic tools of CATIA V5 and we will focus on when and
when not to use those tools. The second section will show examples of usage of CATIA V5
intrinsic KBE tools. The last two sections will be overviews of different kinds of knowledge
templates.
Page 65
11.2 APPENDIX AA: CATIA V5 FUNDAMENTALS KBE

TOOLS
Consultant
Co-Author:
Revised By:
Edited By:
Edited By:
Reviewed By:
11.2.1 Parameters
Parameters are at the root of most of the KBE applications in CATIA V5. They can have
multiple type and they can take multiple values.
There are two major kinds of parameters in CATIA V5. First, there are parameters that define
intrinsic properties of a model, such as mass, volume, density and so on. The value of those
parameters is always changing from model to model, even if those models were generated from
the same design template. The user should be careful on the reusability of those parameters to
produce design templates or generic models. Some of ten could be reusable, and some of them
will have to be regenerated. We could call them intrinsic parameters. While some of these
parameters are automatically generated by CATIA after the model has been built, others can be
created by the user to generate other mechanical, or even thermal or chemical properties. As an
example, the parameters in figure A1 were automatically generated by CATIA with a measure
tool. Then, user parameters (force, acceleration) were created to link some of the previously
generated parameters.
Page 66
Figure H1 : Intrinsic parameters
If I have 40 different models of brake discs (for example, hole patterns are different), I’ll have to
regenerate intrinsic properties with the measure tool for each model.
The second kind of parameters can be called driving or user-defined parameters. Those
parameters are most of the time driven by formulas and other parameters and will be used to
produce design templates and generic models. It is recommended to characterize as much as
possible generic models with user parameters and drive them with formulas (see next section). In
the next example (see figure A2), the number of bolts required to fix the brake disc is controlled
by only one parameter that can quickly and completely change design and bill of material
requirements.
Page 67
Figure A2: Significant design change controlled by one user parameter
To make sure parameters efficiently support quick design changes, the design of the part itself
should include the proper features (and its associated intrinsic parameters) to support quick
design changes. This is where good modeling techniques have to be taken into account.
Parameters can also be used to store text data. In a 3D-only world, common notes that used to be
on a drawing can be stored in parameters in lieu of 3D annotations (see figure A3). The usage of
this approach shall be driven by manufacturing downstream processes after the 3D model has
been built. The population of those parameters could then be easily automated with macros and
scripts applications.
Figure A3: Usage of parameters to store text data
The usage of parameters can suit multi engineering requirements purposes. Remember to use
them, name them and drive them efficiently so that any downstream user that reads the model
can easily understand the intention of its author. For large amount of parameters to populate,
KBE scripts (see section XX) shall be developed to automatically populate those parameters.
As a summary, here are some guidelines for parameterization recommended practices:
Use parameters to define an interface to the part consistent with its design inputs and
outputs
Give parameters logical names and avoid using special characters and spaces
Create as many parameters as needed, but avoid cluttering the part
Page 68
Order parameters logically

Use geometrical sets to organize your parameters (See figure A3)
Avoid circular relations unless solving a set of equations
Map User Parameters to Intrinsic Parameters if modifying the intrinsic values (especially
useful when setting up for VB)
Use consistent types and units in formulas.
11.2.2 Formulas
A formula is a CATIA feature used to define a parameter and it can be manipulated like any
other feature. It can contain typical operators (+, -, x, /) and respects all mathematical laws. The
best approach to use formulas is to use them with renamed parameters so any downstream user
can understand the knowledgeware intent of the creator. Figure A4 shows two different ways of
defining parameters with a formula. One is clearly understandable, and the other one is hard to
see where it as on the model, unless the user edit the formula.
Figure A4: Formula that defines same parameters (not renamed, renamed)
11.2.3 Design tables

The main advantage of design tables is that it allows the user to create different configurations
from a single model. It drives parameters of a single generic model from external values. Those
values can be stored either in an Excel spreadsheet or a tabulated text file. A set of parameter
values in a design table is then called a configuration and is registered in a row of the table.
When should a Design Table be used?
To capture design intent through external files
To completely redefine a design when standard configurations are known
To export parameters to a spreadsheet
To help create standard component Catalogs
Standard parts such as screws, washers and nuts are examples of mechanical parts that can be
described by design table (see figure A5). Those parts can then be quickly and easily stored in
catalogs under standard components families.
Page 69
Figure A5: Different bolts configuration obtained from a single model thru a design table
11.2.4 Macros & Scripts

Macros and scripts are powerful tools to automate repeatable tasks. A macro is defined as a
series of functions, written in a scripting language, that are grouped into a single command to
automatically perform a requested task. From the extraction of bill of materials from assemblies
to automatic renaming of point features, macros coded in VBA or VB Script can automate
thousands of repeatable tasks to manage large amount of data. A typical example is CATIA V5
feature; when a user creates a CATIA point, the software will give a default name (point.1) to the
point. What if the user has 500 points that defines fastener locations? Then, a specific naming
convention implicitly telling any downstream user where those fasteners are located would be
required. A macro would therefore be perfect to automate the point renaming process.
It has been demonstrated in the past that in many industrial cases, the problems encountered with
macros are not due to errors in the scripting or VBA host implementation but because of
programming errors in the script macros.
Therefore, for beginners who have never done scripting before, it is recommended to first
familiarize with general rules of scripting / coding syntax (code presentation, indentation,
variables, objects, classes, comments, etc.). To use and understand macros in CATIA V5, it is
strongly recommended to beginners to record macros while they perform tasks in CATIA. This
is going to help a lot the user to understand to specific CATIA CAA V5 automation objects, how
they are linked together and how they are used thru functions in a specific CATIA V5 macro. For
advanced users, the more CAA V5 automation objects they can be familiar with, the more they
can automate processes in different CATIA workbenches. Macros that change/automate a big
amount of data and that produce significant changes in a model with a small amount of code
should be achieved.
Page 70
11.3 APPENDIX AB: CATIA V5 KNOWLEDGE ADVISOR

TOOLS
Consultant
Co-Author:
Revised By:
Edited By:
Edited By:
Reviewed By:
11.3.1 Lists
CATIA V5 lists features are used to manage a big amount of objects or parameters in the form of
a list. Usage of lists becomes helpful to manage bigger models. A possible example would be a
generic model of an airplane stringer on which hundreds of fastener holes location and definition
varies along the fuselage. Such a generic model would involve a change in combination of holes
diameters / locations per stress analysis requirements. Therefore, a combination (list) of
parameters characterizing those holes diameters / locations could be established in the stringer
generic model for each stringer location along the airplane fuselage.
11.3.2. Rules
A rule is a set of instructions that is used to control certain parameters and events according to a
given context (engineering, manufacturing, marketing, etc.) and its context is generally defined
using a conditional expression. There are two types of rules in CATIA V5: advisor rules and
expert rules. The main difference being in the fact that expert rules interact with models at the
class level (all features) as opposed to a specific feature for advisor rules.
Rules can be used for multi purposes. Best approaches are to use them to control the design.
Remember that a rule will control a parameter’s value if it is set in the rule. A typical example
could be the control of the interface with the surrounding structure of a ducting installation in an
airplane. Depending on the surrounding structure, the user has to install brackets at different
location to support the ducting network. A rule could be establish saying: “If surrounding
structure/Part Number= 1234567 then...install bracket”. This is a generic example to show the
advantage of creating rules when doing interface designs. Another example (see figure A6) could
be to control export control rules and licensing within an entire CATIA model or on specific
features.
Page 71
Figure A6: Advisor rule controlling export control data on a specific feature
As a summary, here basic best practices on the usage of both advisor and expert rules:
 Use Advisor Rules when the exact affected feature is known and well defined
 Try to use If – Else If – Else statements as opposed to just multiple If statements
 Try to logically order actions in a Rule
 Click on a feature or Parameter in the specification tree as opposed to typing the
name in the rule editor.
 Remember that the editor is CASE sensitive.
 If creating a lot of code, select “Apply” after each major segment to assure that
the code is valid.
 Always use parenthesis ( ) and brackets { } to input statements
Typical cases where and when to use advisor rules:

 Rules are created in a Part or Assembly document and can be stored in Catalogs
 To enforce design intent and company standards
 To ensure that a model will be created correctly
 To change (including changing and creating geometry) a model based on
specific requirements
 To fire/trigger specific actions that should take place on a model
Typical cases where and when to use expert rules:

 When the exact feature is unknown, but the class type is known
 To perform operations at a class level
 To control more than one feature at a time
11.3.3 Checks
A Check is a tool using knowledgeware language syntax to verify specific conditions
specified in the Check to control design targets (typical examples are weight, costs,
design guidelines, etc.). Like rules, there’s also two types of checks: advisor checks
Page 72
and expert checks. Here again, the difference is that t expert checks interact with
models at the class level as opposed to a specific feature for advisor checks. Unlike
rules, Checks do not have an impact on parameter values. Once a check has been
established, the user has to respect the check’s requirements to complete the model.
On an airplane program for example, weight targets are very important. In our example
(figure A7), the weight of a generic model for a bracket cannot exceed 52 grams.
Otherwise, a pop-up message appears.
Figure A7: Usage of a check to control the weight of a part

As summary, basic best practices approaches, as well as typical cases on where and
when to use advisor and expert checks are similar to the ones for rules (see previous
sections). Keep in mind that the intent of the when is to provide designers feedback on
the accuracy of the model with respect to business and engineering requirements.
11.3.4 Reactions
Reactions are similar to rules and they were created to cope the limitations of rules and
enabling more associative design. The main limitation that helps the user identifying the
need of using a reaction is the fact that a rule cannot control parameters and feature
updates. On the other hand, reactions can control those updates and even if it is similar
to a rule, it can control a much larger amount of updates and can drive complex design
changes. Since the language for reaction is similar but can be much more complex than
the one for rules, it is recommended that the user gets familiar in writing and
understanding rules before starting using reactions.
For compatibility and extensive usage of reactions, it is highly recommended that they
can be coded in VB Script language. The ideal scenario would be to have them in both
CATIA V5 knowledge and VB Script languages, but the industry ask for results in the
shortest amount of time!
11.3.5 Loops
A CATIA V5 loop is another powerful knowledgeware tool that uses knowledgeware
languages to drive design and engineering changes. Do not confuse with the loop
statement (Do – While) used in all computer languages that executes a statement until it
becomes false. Loops shall be used to automatically create complex patterns that
cannot be achieved with typical pattern features or fast multi-instantiation of features in
CATIA V5. It is highly recommended to program loops with user templates such as
power copies or user features. This will allow users to achieve complex instantiation of
those user templates simply by using the loop function. For example, a user wants to do
Page 73
a fast instantiation of holes drilling directions to join two parts together. He defines a
user template with three inputs: a point, a line and a surface. Then he creates a loop
that instantiate a line-point-line combination for every holes location (see figure A8)
Figure A8: Fast instantiation of holes drilling directions using loop capabilities
Page 74
11.4 APPENDIX AC: CATIA V5 PRODUCT

KNOWLEDGE TOOLS
Consultant
Co-Author:
Revised By:
Edited By:
Edited By:
Reviewed By:
11.4.1 User Defined features (UDF)

CATIA V5 user define features includes power copies and user features. The difference
between both tools is that the user feature template can include inputs, meta-inputs and
outputs, where a power copy only includes inputs in its definition. Those UDF basically
consists of sets of features and parameters grouped together for reuse, or re-
instantiation. They can be grouped in sub-families in libraries and catalogs. UDF are
the new generation of DETAILS or DITTOS in the CATIA V4 world.
A common practice is to use both tools for multi instantiation of complex design
features. They are also often combined with other knowledgeware tools such as advisor
or expert checks, to avoid re-editing the UDF once it has been multi-instantiated. As a
simple example, the combination of a pad with a parameterized cutout (figure A9) could
be used for smart design templates, along with a check to make sure it will suit design
requirements
Page 75
Figure I: UDF definition for re-instantiation
As a summary, here are some basics best practices on the usage of UDF:
 Recommended to be used on Bodies, Sketches, Features, Design Tables and
Relations
 Keep geometry as simple as possible and use the least possible number of
elements as inputs. Keep those inputs in a logical sequence
 Give geometry and parameters meaningful names so that they are
understandable by downstream users
 Constrain as much as possible to the inputs.
 Avoid constraining 2D elements to “HV Axis” unless Positioned Sketch is used.
 Avoid using Projections or Intersections in Sketches if possible.
 Be aware of existing Master Parent/Child Relationships and relational design
links for part updates
11.4.2 Parts, documents and assembly Templates

Parts, documents and assembly templates do have common architecture, similar to UDF. The
main difference of those templates with UDF is the instantiation method and the context of that
instantiation.
This being said, the part template is a feature itself that is created in the CATIA model. It is
similar to User Defined Features described in the previous section. The main difference being
that they are always stored in libraries and catalogs to use them in other contexts. Several part
templates may be defined in the same CATIA model.
Page 76
Document Templates are also similar to User Features, except that the entire document is used
and not a subset of features, so they are instantiated into products (assemblies). They are
instances in assemblies and there are several methods to instantiate those templates into a
product.
Assembly templates, created interactively, always reference the root product of another
assembly. Once this template is created, the user stores it in a catalog and uses it in another
context. We are then talking about in-context and out-of context instances, which is out of the
scope of this document. The template definition is a feature located in the CATIA Product
document itself. Several assembly templates may be defined in the same CATIA Product
document.
Page 77

Chapter 11: Appendix B: References &
Papers on KBE and Catia V5
1. “A KNOWLEDGE-BASED SYSTEM ENGINEERING PROCESS FOR OBTAINING
ENGINEERING DESIGN SOLUTIONS”, Proceedings of DETC/CIE 2005 ASME 2005
International Design Engineering Technical Conferences & Computers and Information in
Engineering Conference, September 24-28, 2005, Long Beach, California, USA, DETC2005-
85561
Contributing Author: Brian Prasad

Co-Author: Jeff Rogers
G:\CSD Groups\
Team_KDA\ASME-DTC-2005\ASME Presentation\ASME-DETC2005-8
Page 78
View publication stats

7 Resources For CATIA Macro Programmers

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

7 Resources For CATIA Macro Programmers

Uploaded by

Copyright:

Available Formats

See discussions, stats, and author profiles for this publication at: https://www.researchgate.

Best Practices in Knowledge-based Engineering (KBE) - Catia Operators

Technical Report · January 2006

Concurrent Engineering Fundamentals: Volume 2 Chapters View project

Book reviews View project

The user has requested enhancement of the downloaded file.

Best Practices in KBE

Document Edited by:

Articles Contributed by:

COE/DPC-KBE Task Force

Sponsored by: COE/DPC 2005 KBE Committee

DRAFT REVISION 3.0 (May 1, 2006)

Best Practices in KBE

Rich.Perlman@ngc.com and John M. Switlik [mailto:john.m.switlik@ieee.org] for their

KBE Forum as a Tool for Collaboration

Best Practices in KBE

Members of the Editorial Board:

Member Affiliation/Company Email ID Areas of

James Boeing, Manager KBE products and

David W. Pigden Goodrich

João Paulo Technology Development Engineer Phone: + 55 12

What Our KBE Document is or is not?

What our KBE Document is What Our KBE Document is NOT

The Table of contents of the proposed document is described next.

Best Practices in KBE

2.0 KBE Concepts

3.0 KBE Rule Languages

4.0 Feature-based Modeling

5.0 Assembly Modeling

6.0 Problem Definition

7.0 Rule-based Modeling

8.0 How to architect KBE

9. System Solution Strategies

10. Example Problems

Appendix A: Brief Description

Appendix AB: Knowledge Advisor Danny

Appendix AC: Product Knowledge Template Danny

Appendix AD: Business Process Knowledge Danny

Appendix B: References &

Best Practices in KBE

1.1 Designing Products

{skateboards}  [Land transport devices]

Where  denotes an element of a set or member of the class hierarchy.

[Land transport devices]  { motorcycles, bicycles, skateboards and unicycles}

(c) Constancy-of-specifications, requirements, purpose or

Where,  denotes an element of.

Figure 1.0.1: Class of Human Operated Vehicles

1.1.1 Why Consider “Product as a System”?

Pugh, S., 1991, Total Design, Addison-Wesley Publishers, Wokingham, UK.

Best Practices in KBE

1.2.2 Situation Analysis

Figure 1.2.1 : A Typical Manual-based Product Development Process Scenario

1.2.3 Text Book Definition of KBE

Ref: CE Fundamentals Book, Vol. 2, pp. 298., 1996

Figure 1.2.2 Role of KBE in Capturing PLM Knowledge

Best Practices in KBE

Best Practices in KBE

Best Practices in KBE

2.0.1 Characteristics of Traditional Design Automation

Figure 2.0.1 Procedural versus Modular mode of Automation Approaches

2.0.2 Differences between Conventional Programming and

Figure 2.0.2: Procedural Mode of Automation and Knowledge Integration