Riding the KBE Rollercoaster

By Bhushan Patwardhan

Knowledge-based engineering (KBE) means different things to different people. For purposes of this article, it refers to a practice of using the right knowledge at the right time in a design process to facilitate its automation, in part or whole.

  The main motivation behind KBE is an integrated approach to product design, with the goal of optimizing a design and associated process by making it predictable, leaner, faster, repeatable and efficient. Apart from that, KBE tries to apply a set of techniques to a design process, enabling organizations to manage knowledge as an important asset. Once knowledge is properly managed, it can be harnessed effectively when needed. For example, a design process can be automated, a sales configurator can be created, and engineer-to-order (ETO) designs can be configured quickly.

  KBE problems are often categorized into parametric,  configurational, generative, etc., with configurational problems further categorized into x to order (xTO), where x can be assemble, build, configure,  manufacture, etc.

Various factors increase the complexity of the product configuration problem, thus requiring a more demanding KBE framework.

But a deeper examination of various categories reveals that the basic nature of the KBE problem involves product configuration and computer-aided technologies (CAx) modeling. However, from a KBE framework standpoint, it is important to differentiate between generative and configurational problems, because solving generative problems demands access to free-form geometry parameters inside the KBE environment. If we accept that generative KBE problems are special forms of configurational problems, then we also realize that it takes a specialized KBE environment to solve such problems.

  Two KBE Problem Categories
Generative problems are associated with parts that cannot be “parameterized” and “templatized.” It is associated with parts and assemblies that create, modify or build on free-form features. Typically, the design process for these products starts from free-form features like curves and surfaces, and proceeds with more features created to match the form of input geometry. For example, an aircraft leading edge rib is built from loft data. The design process demands several non-parametric, free-form features to be created to match the input loft surface. Ship structural elements and dies for automotive body panels are two more examples where generative KBE provides the most complete and effective method for automating design processes.

Configurational problems relate to products configured or created per order. A traditional configurational problem involves rule-driven configuration of parts from CAx templates, applying assembly conditions to build complete product models, driving downstream CAx model for analysis, etc. If a product configuration requires only the manipulation of part parameters, then a CAD-based assembly automation solution is sufficient. However, such an environment may be insufficient where product configuration rules also lead to situations where individual part quantity, location, type and/or design parameters change based on customer requirements.

  To build a comprehensive KBE solution for a product design problem, it is critical to understand all possible product family variations and how a single product family may be divided into multiple knowledge models to make it suitable for process automation.

  KBE History
The current state of uncertainty in KBE practice can be attributed to several reasons. After CAD underwent a parametric revolution in the 1990s, it started competing with KBE. There was confusion about where CAD ended and KBE began. A handful of KBE vendors, busy competing against one another, did not rise above the din and clearly communicate KBE differentiators. CAD vendors, because of their size and market penetration, won the battle for customers—and KBE vendors found it difficult to survive.

  Product design organizations were reluctant to promote KBE for several reasons, including driving tough cultural change through an organization, organizational politics and conflicts between IT and engineering departments over KBE implementation. The reluctance of design organizations to bear costs associated with development, maintenance and complexity associated with a programmed solution, as well as the lack of standardization in process automation practice also contributed.

  On the other hand, CAx vendors had their own reasons for failing to promote KBE. Some have argued that a CAD company promoting KBE could cannibalize their own CAD license sales because an automated design process with one KBE license could, potentially, replace several CAD licenses.

  Because KBE deals with the creation/configuration of parts and assemblies, most CAD companies have tried to integrate their KBE acquisitions within CAD environments without realizing that a process-centric KBE technology may be better suited to be integrated with PLM.

  This integration has not always been seamless. If CAD is a model output of KBE, then KBE should drive CAD output. However, most CAD companies have integrated KBE in ways where CAD environments drive KBE.

  Most KBE frameworks in the market are not transparent because they lack an effective knowledge management component. In addition, the high cost of KBE software (in addition to CAD licenses) and specialized consulting have also deterred many design organizations.

  The Future of KBE
Are there business drivers that demand better KBE tools, and are there technology enablers to fulfill them? From past, limited successes of KBE, it is evident that there is sufficient technology on hand to create a KBE environment to handle various configurational problems.

  Over the years, organizational willingness has been a big hurdle in driving KBE projects forward. On the other hand, CAx vendors have not provided compelling KBE environments to overcome organizational inertia. A next-generation product configurator will require collecting best-in-class features from past experiences into a new, integrated product offering.

  One important step in that direction will be to stop looking at KBE as a natural extension of CAD, and look at it from a process or product lifecycle management (PLM) perspective. This could be the single-most important paradigm change to put KBE (and product configuration) into the right perspective. Process-centric KBE belongs in the domain of PLM (or other process related product offering) and not as part of a CAD model. A subtle change in current relationship between CAx and KBE tools can lead to significant benefit in streamlining the KBE environment. It will let KBE integrate various modeling activities associated with product design by giving KBE process much-needed control over the modeling environment.

  Three Essentials to a KBE Framework
1. The knowledge manager (KM) serves as a repository of knowledge. It is an application-independent, generic environment, capable of storing various forms of knowledge associated with a design organization. The KM not only includes discrete pieces of knowledge, information or databases,  but also common, generic knowledge objects. Making the KM transparent through a web-based front-end will do wonders for any KBE tool.

  2. The knowledge configurator (KC) serves as the KBE system development environment to build product-specific knowledge models (or knowledge templates) in the form of a product and process structure tree. It is a development environment with an editor and/or form-based user interface used to define product and process knowledge models. It accesses relevant knowledge from the KM, and applies it to a knowledge model. To facilitate an integrated product development approach, the KC should also provide exposure to various CAx modeling environments through a consistent set of syntax.

  3. The knowledge browser (KB) serves as a testing as well as run-time, user access environment for knowledge models. Ideally, the KB should be the CAx modeler itself, with access to the product knowledge model.

  It is also interesting to note that many large and small design organizations, frustrated with the escalating costs for CAx licensing,  consulting and backward compatibility issues, may be eager to break free of proprietary shackles and seriously consider an open-source CAD and KBE framework.

  From my perspective, it has been a rollercoaster ride for KBE over the last 20 years. Growth in the 1980s and 1990s, coupled with the decimation of independent KBE vendors through the 2000s, has been followed by recent signs of rejuvenation. Will the recent signs turn into an industry-wide trend, or will it be another bump in the rollercoaster?

Bhushan Patwardhan is currently based in Puné, India. He has more than 20 years of experience implementing IT-enabled engineering for a variety of companies in the automotive, aerospace and manufacturing industries. He has implemented KBE projects for Fortune 500 companies, as well as medium and small companies, in North America, Europe and Asia. He can be reached via [email protected].