Knowledge Based Engineering (KBE): Update

Introduction
What is KBE? Knowledge Based Engineering (KBE) is a working discipline that is regularly used within the product industry. A COE Forum Discussion Area actively supports the discipline. Each release of CATIA v5 has been accompanied with improvements to workbenches that support KBE. According to a recent COE NewsNet article, KBE is a bridge “between knowledge management and design automation.” As such, KBE systems would have qualities that distinguish them from other computing systems. These qualities are that KBE be “dynamic, generative, high level, and demand driven.”

A site at ‘wikipedia’ has been set up to document KBE and its roles. The article looks at the Origins and Status of KBE.

Origins of KBE
Across the product industry, there are continual pushes for progress; these arise from several motivating factors and result in a relentless pursuit for improvements. Whether the drivers for this pursuit are cost or quality or other, it comes around at some time or another to computation.

For the product industry, computation means CAD/CAE/CAM (CAx) and PLM. CAx has evolved along with the computer. PLM is a recent entry to the vernacular. Another resource is optimization; when optimization is coupled with CAx, we have a very powerful mix of tools.

KBE can be seen as an improvement effort that was complementary to CAx; it can be dated from the 1980s with a success story that sustained itself long enough into the 1990s to get attention. As with any bit of progress, KBE flashed on the horizon, lit the sky for awhile, and then experienced a downslide.

Analysis of why KBE had a hiatus can identify expectation management as one issue. Changes in expectation can become problematic when the computational is involved since many times rewards come almost miraculously. Don’t we always expect more from our systems given our natural bent at extrapolating? Does that not make our expectations hard to manage? Do we not then get frustrated when we see just how much work is needed to effect benefit?

Another factor related to the KBE decline in favor was computational in nature. What the industry has seen in the past 20 years is a steady progress in computing capability, both in hardware and software. One problem with this is that, as new software paradigms mature, processes that depend upon the existing capability have to adapt and to do so is not without its pain. This leads to a conflict between the requirements of legacy systems and the push to be playing with the new toys (green field). Can we ever temper our ‘grass is greener over there’ selves?

Now, to be fair, recent maturity levels for software are so substantially supported and exist on so many fronts that the types of adjustments needed are going to be wide and deep. They will be more than process oriented. For instance, progress in computation has always caused change in human dynamics with the computer. Now, given the incursion of the computational into the knowledge arena, a traditional human domain, a whole new game has to be developed.

The problem is partly our own fault. Well-trained staffs resolve problems daily in their work; ought some of those solutions, if looked at carefully, be appreciated as truly remarkable? Somehow and some day, one might think, perhaps we’ll learn to appreciate human talent.

Granted, in many cases, progress has been enabled by staff having access to advanced computational tools. Early on, KBE success was related directly to explicit inclusion of the ‘person’ into the loop (PL). This essentially served two purposes. For one, KBE systems did not have to be complete. For another, a PL can help bound decision spaces.

In terms of completion, the story here is not unlike the general ‘earned value’ problem of engineering. When is something 100% complete? KBE allowed partial completions with the expectation that the PL would finalize the artifacts produced by the KBE system. As one might expect, this type of framework can grate for several good reasons. Accelerated output from the computational can easily swamp any manual review. Rework of this nature does not fit into a lean approach.

Probably of greater importance though was that the PL helped prune decision spaces which can grow very large due to combinatorial effects. It ought to be noted that one of the KBE user groups called its publication ‘Vertigo’ in recognition of the problems of trying to order large spaces into something that is coherent and to bound growth of the same spaces.

Again, in retrospect, some of the complexity came from grayness that might be attributable to ambiguity. Well-trained minds can handle such situations and apply rules of disambiguation. The more modern modeling approaches explicitly work to reduce ambiguity.

Status of KBE
KBE is at a crossroads where it can make use of a basic re-structuring of software paradigms and can apply progress that’s been made in modeling knowledge. Opinions differ about how some of these new approaches ought to be applied, however let’s look at a few of the current views and their implications.

There is now more appreciation for the differences between product and process that is directly attributable to modeling advances. Ignoring for now how these two might not be entirely disjoint and could overlap (that is, product and process), if a KBE systems is aware of the differences and can apply the appropriate discriminating criteria, then it can offer varying techniques accordingly.

A presentation at the recent COE Aerospace Conference looked at KBE from the framework of model based design. According to the presentation, KBE systems need to capable and formal. ‘Capable’ in this sense refers to several things listed below. Formal refers to reasoning support.

In brief, a KBE system ought to do the following.

1. know about the real world,
2. be able to handle that knowledge in a multi-disciplinary fashion,
3. know how to structure and re-use knowledge, and
4. allow automation (even support self-adaptation).

Now, that collection is neither small nor trivial; expectations for KBE have not waned. One can add that KBE know how to handle the PLM perspective. In general, we need methods that can handle trades and decisions that weigh both technical and business constraints.

In recent years, it has been difficult to find a comprehensive set of methods that would help cover all those requirements. In one case, we had an underlying workbench thrust that put a focus on product structure with an advanced GUI to support a designer. This structural approach (in a modeling context) allowed the embedding of knowledge (of a local nature) at specific properties. Coupled with the product structure was link technology that allowed definition of interrelations.

In this framework, putting together these types of pieces through clever use of the newer software features allowed development of intricate part assemblies that could adjust by parameter change. An example would be shape morphing within a loose topological bound in order to meet changes in requirements. That type of ‘adaptation’ could be coupled with a ‘behavior’ metaphor and look smart. It exhibits the classic stimulus/response link that we can observe in nature. This type of shape morphing only became feasible through implementation of a more robust CAx framework.

In another case different than the workbench model, KBE was supported with a programmatic approach that was free-from and without any limitations on extension of capability. One downfall of this approach was a constrained link with a GUI resulting in disparateness between logic and visualization. For KBE, there were many others than these two approaches on the market.

In essence, KBE needs a coherent set of methods that includes product/process modeling, visualization support, proper ‘meta’ level modeling, and reasoning. In a sense, assembly structures and PLM operators do offer some of this type of support. It has been shown that one can accomplish ‘meta’ level processing using relational links.

But, we need to ask several questions about the future characteristics of KBE methods and tools. One of these is the following: does KBE need to support automated reasoning? If so, that would mean support for formal processing; in this sense, ‘formal’ pertains to sufficient rigor on the part of the system to sustain reasoning in a reliable fashion.

This article is a brief overview. Further information about KBE can be found at the references in the Introduction.

John M. Switlik
john.m.switlik@ieee.org