About COE Membership Events & Education Collaboration Links & Resources
COE NewsNet – June 2005
 
COE Feature
Inside COE
Technology Update
Intel Microsoft Environment
Tips and Techniques
Implementation Network
    Academia News
    Industry Outlook
    Rug News
    Knowledge Technology

    Archives

    Contribute to Newsnet

    About the Editor


    Knowledge Technology

    What Distinguishes KBE from Automation

    Brian Prasad1, Ph.D. KBE Leader, Parker Aerospace, Irvine, CA.

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

    What is KBE?
    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 [3].

    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 are facing today.

    Purpose of KBE?
    The purpose of KBE is to provide a specialized design environment to the users for capturing PLM life-cycle intents. The design environment of KBE is commonly provided in a form of a high-level language or commands [see Ref. 3 and 5]. Using such high-level language, it is much easier and faster to automate certain 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.

      .  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 low-level 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 2.]

      .  Major Problems with traditional Applications

      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 source 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 serious   “knowledge gap and communication lack”. 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]

      .  Differences between Excel Spreadsheet and KBE

      A shortcut often taken by engineers frustrated by the amount of   “conventional” programming required by traditional design   automation approach is to link spreadsheets and CAD models [see   Ref. 2]. 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,   but they often take the procedural capabilities to a new level.   Let’s see how this is done in Excel. First of all, an Excel   application defines a model of a physical or abstract system.   The Excel model allows the end-user to enter or change values   for model parameters, uses rules to “dynamically” calculate the   effect of the parameter values, and then produce results derived   from them. The aforementioned process is no different than what   one would do in KBE. Similar to electronic spreadsheets, the KBE   language is also declarative rather than procedural. This means   that the order of operations need not 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, which allows   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 Language differs from most   general-purpose O-O languages (like C++ or VB) in being   primarily declarative rather than procedural in nature.

    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.

    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.


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

    Contact
    Brian Prasad, Ph.D. KBE Leader, Parker Aerospace, Irvine, CA.
    bprasad@parker.com


    Thank you for taking the time to read COE NewsNet! Though we hope that you will continue to benefit from and leverage each issue of COE NewsNet, if you do not wish to receive future email announcements of each issue, please email us at coe@coe.org and include "Unsubscribe from COE NewsNet" in the subject. Thank you!


    Email This Page
    401 North Michigan Avenue, Chicago, IL 60611-4267 | (312) 321-5153 | (800) COE-CALL (U.S.)