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