COE/KBE Task Force to Develop Best Practices in ...

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, [email protected]. Page 1


Best Practices in KBE Sponsored by: COE/DPC 2005 KBE Committee Historical Background: During the COE-2005 Conference in Phoenix, Arizona, Brian Prasad (as an incoming Chair for the COEDPC 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'" [email protected], "'Perlman, Rich'" Please direct all enquiries to: Dr. Brian Prasad, COE/DPC KBE Chair, [email protected]. Page 2

Best Practices in KBE (Draft Rev 3.0) May 15, 2006 [email protected] and John M. Switlik [mailto:[email protected]] 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:

IBM IT Group VP, May 1, 2006

Joe Blow

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!!!



Best Practices in KBE Sponsored by: COE/DPC 2005 KBE Committee 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 Name

Affiliation/Company

Gregory A. Premetz (GP) Ray Anderson (RA) (Accepted)

Vought Aircraft

Phil Thomas

Design Specialist - KM/KBE/CAD Engineering - TWEZD Airbus North America Engineering Inc. IBM, PLM Application Engineer

Email ID

Areas of Focus (TOC Sections Reviewed/Edit ed)

Mailto:raymond.ande [email protected]


Best Practices in KBE (Draft Rev 3.0) May 15, 2006 (PT) Pierre Pinard (PP) Fabrice Dreneali (FD) John M. Switlik (Accepted)

DS- KBE Support Manager R&D Solutions, DS, France Associate Technical Fellow Wichita Define Systems/Knowledge Based Systems

James Fernandez, (JM)Ph.D. Rick VanWetten (RV) Rodney L. Dreisbach, Ph.D. (RD) William J. Moon (WM) Mike Twelves (MT) (Accepted) Paul Webb (PW) (Accepted) Danny Bouchard (Accepted)

Boeing, Manager KBE products and Services

David W. Pigden (DP) Brett Ade (BA) Franck Montigon (FM)

Goodrich

João Paulo Rebucci Lirani

Technology Development Engineer Embraer - São José dos Campos

Siemens VDO Boeing

Boeing Corus Application Consultant , KBE KTI/DS Aerospace Practice Consultant Dassault Systemes Services

Cell phone: 799-9730

(206)-

MSC Software Dassault Systèmes

CATIA Strategy on Knowledgeware, FEA and Shape Design and Styling Phone: + 55 12 3927-6418 E-mail: [email protected] 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 in KBE A place where some of the Benefits of

An Extension of DS/Knowledge Ware Documents/Online Help A better Users Manual than what DS/KW supplies.


Best Practices in KBE (Draft Rev 3.0) May 15, 2006 capturing Engineering Intents (via KBE) versus pure “geometry” (Why use KBE?) Describes What makes an application Generic, Robust, Reusable and Portable How to ensure that rules are dynamically controlled and not subject to constant code changes Methods of Capturing Rules while building KBE objects Methods of Passing Parameters (Integration) across KBE objects Which DS/KW Tools to use in what situations. Describe situations when to use them and when Not to use them (what makes best sense) How to Build a best class of KBE applications using our DS/KW tools Describe SmartParts and Null Parts Concepts in KBE with KW Examples

Differences between KWA rules and KWE rules Provides more examples than what DS/KnowledgeWare Tools Better Examples than what DS provides in their Users Manual. A Tutorial on KBE A step by step description of How to use various Knowledge-Ware tools Describe Various Knowledge-Ware Tools: Parameters, Rules, KW terminology, and Better use of PKT and PEO tools. (you will find some of these in the appendix) Description of DS/KW tools and related Concepts Propose Enhancement Requests for adding new 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.



Best Practices in KBE Table of Contents (Tentative) TOC

Lead Supporting Page Authors/ Authors/ Numbers Coauthors CoAuthors

1.0 Introduction 1.1 Designing Products? 1.1.1 Why Consider “Product as a System”? 1.2 What is KBE? 1.3 KBE Tools 1.4 What is KnowledgeWare?

BP

AM1

Brian Prasad

BP BP Francois Riche

AM1 AM1

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

BP BP AM1

AM1

2.9 Moka

AM1, Ray Anderson

Ray Anderson

Francois Riche Francois Riche Francois Riche

BP

DB

BP

DB

BP

DB

2.0 KBE Concepts

AM1 BP AM1 AM1/JP

3.0 KBE Rule Languages 3.1 KWare Language 3.2 GenSCript 3.3 VB Scripts & VBA



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 6.2 Generalizations versus Specific Cases 6.3 Systems Engineering Approach (very interesting!) 6.3.1 Problem Decomposition 6.3.2 Problem Aggregations 6.3.3 Problem Solutions Strategies

BP BP BP BP BP BP

7.0 Rule-based Modeling Concepts (This talks about how we go about adding nongeometric features. A template could be more than a parametric part. ) 7.1 Template-based Modeling 7.2 How to construct Templates? 7.2.1 Making templates Robust 7.2.2 Generic utility parts 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

BP JP JP JP JP JP JP JP JP

7.3 Components-based Modeling



8.0 How to architect KBE applications in V5 (Integration Strategies) 8.1 Setting the environment 8.2 Creating parameters, lists, etc.. 8.3 Creating Geometry (PartDesign, GSD,Sketcher) 8.4 Exchange between VB and Catia (External Parameters) 8.5 Passing Matching Attributes across 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 GETATTRIBUTE and SETATTRIBUTE method used in KWE. 8.7 Exchanging parameters between Catia and external app 8.8 Rules inside VB or Catia (KWA)? 8.9 Reaction-based Linking (see 8.c.ii) 8.10 Instantiating UDFs 8.11 Quantification (via VB or Loop) 8.12 Update Configurations 8.13 Working with Other Modules (Sheetmetal, Composites, etc..)

JP JP JP BP

BP

BP JP JP JP JP AM1/JP JP

9. System Solution Strategies 9.1 UI (User Interface) 9.2 Optimization inside Catia (PEO) or via VB?

JP/AM1

10. Example Problems 11. Appendices: Appendix A: Brief Description of Tools to Develop KBE in Catia V5 Introduction Appendix AA:V5 Fundamentals

DB/BP Danny


Best Practices in KBE (Draft Rev 3.0) May 15, 2006 Bouchard

Parameters Formulas Design Tables Macros in VBA or VB

Appendix AB: Knowledge Advisor

DB DB DB DB

Danny Bouchard

Lists Rules Checks Actions Reactions Loops VBScripts

DB DB DB DB DB DB DB

Appendix AC: Product Knowledge Template

Danny Bouchard

User-defined feature (UDF) Part Template Assembly Template Generative Script

DB DB DB DB

Appendix AD: Business Process Knowledge Template Technological objects Behaviors Loops BKT app

Danny Bouchard

DB DB DB 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



Best Practices in KBE Chapter 1: Introduction 1.0 Introduction 1.1 Designing Products? 1.1.1 Why Consider “Product as a System”? 1.2 What is KBE? 1.3 KBE Tools 1.4 What is KnowledgeWare?

BP

AM1

Brian Prasad

BP BP Francois Riche

AM1 AM1

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) Please direct all enquiries to: Dr. Brian Prasad, COE/DPC KBE Chair, [email protected]. Page 11

Best Practices in KBE (Draft Rev 3.0) May 15, 2006 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

(b)

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

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.



(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 enterprise Where,

RCs components

 RCs

subsystems

 RCs

system



RCs department

 RCs

SBUs



 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.


Best Practices in KBE (Draft Rev 3.0) May 15, 2006 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-todate 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


Best Practices in KBE (Draft Rev 3.0) May 15, 2006 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.



Best Practices in KBE Chapter 1: Introduction 1.2 What is KBE? Contributing Author: Brian Prasad

Parker Aerospace, Irvine, CA


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.



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 lifecycle 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.



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 lifecycle 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



Best Practices in KBE Chapter 1: Introduction 1.3 KBE Tools Contributing Author: Brian Prasad Co-Author: Revised By: Edited By: Edited By: Reviewed By:

Francois Riche

Parker Aerospace, Irvine, CA Dassault Systems, France



Best Practices in KBE Chapter 1: Introduction 1.4 What is KnowledgeWare? Contributing Author: Brian Prasad Co-Author: Revised By: Edited By: Edited By: Reviewed By:

Francois Riche

Parker Aerospace, Irvine, CA Dassault Systems



Best Practices in KBE Chapter 2: KBE Concepts 2.0 KBE Concepts 2.1 Capturing Engineering Intent 2.2 Morphing Strategies 2.3 How to represent Knowledge? Modularization of Knowledge 2.4 Knowledge-centered KBE versus CADcentered KBE 2.5 How KBE Differs from Parametric , Relational, (Variational) CAD 2.6 How independent should knowledge be from the tool (environment) 2.7 Top-down philosophy (I-CAD) vs Bottom-up Philosophy (V5)

BP BP AM1

AM1

AM1 BP AM1 AM1/JP

2.8 How to model knowledge (before constructing an application)

2.9 Moka

AM1, Ray ANDERSON

Ray ANDERSON

2.0 Introduction Contributing Author: Brian Prasad


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].



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 customdeveloped 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 customdeveloped 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]



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.


Best Practices in KBE (Draft Rev 3.0) May 15, 2006 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. [2] RuleStream KBE Architecture White Paper on “The New Generation in Knowledge-based Engineering (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.



Best Practices in KBE Chapter 2: KBE Concepts 2.1 Capturing Engineering Intent Contributing Author: Brian Prasad





Best Practices in KBE Chapter 2: KBE Concepts 2.2 Morphing Strategies Contributing Author: Brian Prasad





Best Practices in KBE Chapter 2: KBE Concepts 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 Attributes

Super Frame: Covered Compartment Default Type


Best Practices in KBE (Draft Rev 3.0) May 15, 2006 N of walls Shape Height Area Volume

4 rectangular

Frame: living-room Attributes Furniture Function

Super Frame: room Default (sofa, table with chairs) social relationship

Integer Symbol Real(m) 2 Real(m ) 3 Real(m )

Type List-of-symbols 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



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 Inputs Upper Skin Lower Skin Front Spar Plane Rear Spar Plane Rib Reference Plane

Web shell Parameters Upper cap thickness Lower cap thickness Upper cap width Lower cap width Web thickness

Type Real(mm) Real(mm) Real(mm) Real(mm) Real(mm)

Rules/Knowledge Geometry Engineering/Design

UDF Inputs Initial positioning Final positioning

Vertical web stiffener Parameters Width Height

Type Real(mm) Real(mm)

Rules/ Knowledge Geometry Engineering/Design

UDF Inputs

Horizontal web stiffener Parameters Type

Sculpt the block by splitting it by upper & lower Skin Surfaces

Linear curve connecting end points on the skin surfaces

Rules/Knowledge


Best Practices in KBE (Draft Rev 3.0) May 15, 2006 Positioning Upper or lower skin curve

Width Height

Real(mm) Real(mm)

Geometry

Engineering/Design

Offset from upper or lower skin intersection curve



UDF Inputs Stringer curve Stringer height

Stringer cutout Parameters Width Height Radius

Type Real(mm) Real(mm) Real(mm)


UDF Inputs Limiting stiffener curves

Lightening hole Parameters Hole corner radius

Type Real(mm)


Intersection point between stringer and skin curves

Hole shape controlled by offset of the stiffener curves

 





Minimum distance from the skin curve 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 3Ref 4-



Best Practices in KBE Chapter 9: System Solution Strategies 9. System Solution Strategies 9.1 UI (User Interface) 9.2 Optimization inside Catia (PEO) or via VB?

JP/AM1



Best Practices in KBE Chapter 10: Example Problems



Best Practices in KBE Chapter 11: Appendices: Appendix A: Brief Description of Tools to Develop KBE in Catia V5 Introduction Appendix AA:V5 Fundamentals Parameters Formulas Design Tables Macros in VBA or VB

Appendix AB: Knowledge Advisor Lists Rules Checks Actions Reactions Loops VBScripts Appendix AC: Product Knowledge Template User-defined feature (UDF) Part Template Assembly Template Generative Script Appendix AD: Business Process Knowledge Template Technological objects Behaviors Loops BKT app

DB/BP Danny Bouchard

DB DB DB DB

Danny Bouchard

DB DB DB DB DB DB DB Danny Bouchard

DB DB DB DB Danny Bouchard

DB DB DB DB


Best Practices in KBE (Draft Rev 3.0) May 15, 2006 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



Best Practices in KBE 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


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.



11.2 APPENDIX AA: CATIA V5 FUNDAMENTALS KBE TOOLS Contributing Author: Danny Bouchard



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.



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.



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 Please direct all enquiries to: Dr. Brian Prasad, COE/DPC KBE Chair, [email protected]. Page 68

Best Practices in KBE (Draft Rev 3.0) May 15, 2006 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.



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.



11.3 APPENDIX AB: CATIA V5 KNOWLEDGE ADVISOR TOOLS Contributing Author: Danny Bouchard



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.



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 Please direct all enquiries to: Dr. Brian Prasad, COE/DPC KBE Chair, [email protected]. Page 72

Best Practices in KBE (Draft Rev 3.0) May 15, 2006 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 Please direct all enquiries to: Dr. Brian Prasad, COE/DPC KBE Chair, [email protected]. Page 73

Best Practices in KBE (Draft Rev 3.0) May 15, 2006 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



11.4 APPENDIX AC: CATIA V5 PRODUCT KNOWLEDGE TOOLS Contributing Author: Danny Bouchard



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 reinstantiation. 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



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.


Best Practices in KBE (Draft Rev 3.0) May 15, 2006 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.



Best Practices in KBE 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, DETC200585561

Contributing Author: Co-Author:

Brian Prasad Jeff Rogers

G:\CSD Groups\ Team_KDA\ASME-DTC-2005\ASME Presentation\ASME-DETC2005-8


COE/KBE Task Force to Develop Best Practices in ...

COE/KBE Task Force to Develop Best Practices in ...

Suggest Documents

5Questions To Avoid Pitfalls And Develop Best Practices - Together ...

5Questions To Avoid Pitfalls And Develop Best Practices - Together ...

BURGOS_RUIZ_12 didactic best practices to develop the most ...

Aligning Best Practices to Develop Targeted Critical Thinking ... - Eric

Task Management Best Practices White Paper - REXwireless

Emerging Best Practices of Chinese Globalizers: Develop the ...

International Practices Task Force - The Center for Audit Quality

best practices in best practices in traffic incident management traffic ...

Climate change task force - press release - Task Force on Climate ...

TBIEDGE Task Force 1 Task Force Members: Karen McCulloch, PT ...

Obstacles to Good Corporate Governance in Canada - Task Force to ...

Applying the Plan-Do-Check-Act Cycle to Develop Best Practices in ...

NCCN Task Force Report

refugee task force - Data.unhcr.org

essn task force - Data.unhcr.org

refugee task force - Data.unhcr.org

essn task force - Data.unhcr.org

essn task force - Data.unhcr.org

essn task force - Data.unhcr.org

essn task force - Data.unhcr.org

refugee task force - Data.unhcr.org

essn task force - Data.unhcr.org

essn task force - Data.unhcr.org

essn task force - Data.unhcr.org