KBP Document Status

The “KBE Best Practices (KBP)” document is now available on the COE Forum for concurrent development. An administrating thread in the Forum  contains the document with a file for each Chapter. Details about the approach can be found in the procedures document on the thread.

The document contains 10 Chapters that cover both generic and specific information about KBE systems; it also contains material related to CATIA v5 workbenches. An Appendix looks at CATIA v5 tools, provides references and papers on implementing KBE in CATIA v5, and discusses the past, present and future of KBE.

Status on the progress of this document will be reported regularly in this Newsnet section.

A Proposal for CATIA V6
Walter W.Wilson, Lockheed Martin Enterprise Information Systems, Fort Worth, Texas

What is the best way to represent an aircraft design?  The design of an aircraft can cost a billion dollars or more.  The product of that effort is mostly intangible -- information -- geometric and other information.  In the old days this information was stored in paper drawings.  While inflexible, they had the advantage that any engineer could read them and that engineers 100 years from now could read them.  Now we store our design data in CAD (such as, CATIA) models.

1. Problems with CATIA

The problem with CATIA is that our design data is stored in a vendor's secret proprietary binary file format.  We need a license to access our own data!  High-level information such as associativity and parameterization is difficult to transfer between different CAD systems.  We are supposed to maintain our design data over the life of an aircraft program, but will our CATIA models be readable decades from now?  Can we have the openness, accessibility, and human readability of paper drawings along with all the advantages of computer representation?

2. An Engineering Design Language

This paper proposes that our engineering design data be represented in a textual, human-readable programming language.  The language would store the operations, parameters, formulas, and knowledge that define the geometry.  From these definitions the screen image, STEP files, etc., would be computed.  Note that this language would not store "low-level geometry" -- megabytes of surface control points and triangles.  Instead this would be computed from the high-level definitions.  The definitions in this language could be considered a record of the interactive operations that define the geometry.  This would be a "declarative" programming language -- one where you tell the computer what to do, not how to do it.  It would be a language for defining "complex data" -- that is, data plus functions on the data.

Definitions in this language might look something like the following:

  (PT3 (coords 5 15 1.5))
 (CRV1 (cubic_spline PT1 PT3 PT4 (project PT2 SURF1) PT7))
 (SURF2 (offset 0.1 SURF1))
 (CRV2 (geodesic SURF2 PT1 PT4))  ! geodesic curve
 (ht .5)                          ! symbolic constants
 (radius .3)
 (depth .2)
 (SOL1 (hole (coords 1 1.5 ht) radius depth
              (cuboid (coords 0 0 0) (coords 2 3 ht))))
         ! -- cuboid solid with cylindrical hole

The language would support new function definitions, such as the following which defines square blocks with holes at diagonal positions:

  (function (Block side)
     (height .5)
     (- (cuboid (coords -side/2 -side/2 0)
                (coords  side/2  side/2 height))
        (+ (cylinder (coords -.5 -.5 0) (dir 0 0 1) .25)
           (cylinder (coords  .5  .5 0) (dir 0 0 1) .25))
     )
  )

  (Block1 (Block 2.0))
  (Block2 (Block 2.5))

  ... or

  (for i in 0..9 do
     (B<i> (Block 2.0+.25*i)) 

Here a "for" loop defines a set of blocks of varying sizes.

3. Advantages

The advantages of an engineering design language include the following:
 
a. Text definitions are human readable.
-- you don't need a license to access your own data
 
b. Data is stored at a higher semantic level.
-- Function definitions vs. arrays of numbers
-- Definitions are at the level that engineers think

c. Text definitions complement image.
-- Image gives fast, intuitive understanding;
-- Text gives precise and complete information

d. Editing can be done both textually and graphically.
-- Some modifications are easier in text: undo/redo

e. Complete history and associativity are inherent in these definitions.
 
f. Parametric design using symbolic constants and formulas is encouraged.

g. Language provides programmability.
-- Definition of new functions should be easier than using a CAD system API since the programming environment is integrated with the data representation.

h. Easier design automation.
-- Language provides environment for engineering rules and knowledge

i. Can add analysis functions for design optimization.
-- Automatic optimization of parameters

j. Better documentation of the design.
-- Text definitions and textual comments provide information often omitted from typical CAD models.

k. Definitions would be "exact".
-- Terms such as 0.1, 1/3, cos 30deg, etc., would represent exact rational or symbolic values.  A definition of an intersection curve or offset surface represents the exact geometric object.  All approximations would be confined to the evaluated low-level geometry.  (I suspect that exact definitions will be easier to move to future modelers than much of our current geometry, which only fits together "within tolerance".)

l. Easier design reuse.
-- It should be easier to reuse portions of a design and to develop "design templates".

4. The Case for an Open Source Modeler
(Dassault folks may want to skip this section.)

For an engineering design language to be completely accessible, its implementation -- a geometric engine -- should be open source.  Engineers may need control over the approximation algorithms that compute the low-level surface and solid geometry from the definitions.  Definitions should yield identical results on different systems; this means that identical algorithms must be used.  Long-term accessibility is better guaranteed if the language implementation can be archived along with the data definitions.

I recommend a logic programming language called "axiomatic language" as the foundation for an engineering design language.  Axiomatic language is intended as a pure specification language, which would be appropriate to this data specification task.  It is an extremely simple language, which would make it easy to standardize, but also highly extensible so it can be built up.  The language can also act as a meta-language, in which new language constructs or an embedded domain specific language can be defined.  The disadvantage of axiomatic language is that the problem of transforming specifications into efficient programs (i.e., "automatic programming") has not been solved in general, so a major advance will be needed before the language is ready for production use.

5. Summary

A language would be a better representation for engineering design data than a vendor’s proprietary file format.  It would improve the design product by providing higher-level definitions, better documentation of the design, and a more optimal design.  It should increase the productivity of engineers by providing easier refinement of a design, increased design automation, and more reusability.

Walter can be reached at walter.w.wilson@lmco.com.

Reflections on KBE

As the KBP TOC indicates, there can be a lot involved with doing KBE. For one thing, KBE has a history that is a mosaic and a future that is unclear. For another, KBE practice is not easy to do. That may be in part due to the fact that there are a few different ways to look at KBE.
On the other hand, there are some underlying issues that need to be addressed. It is hoped that working the KBP document will help the team bring some of the issues into a better focus.
Of the several issues related to KBE, let’s look at two of these that deal with language and with end-user computing.

• In reference to language, the above article is based upon a presentation (“CATIA V6 Proposal”) that was given at both a North Texas COE meeting and at the 2005 COE Aerospace Workshop. One question raised in Walter’s work deals with the timeframe of availability required for knowledge encoded in some type of system. The knowledge would need to be preserved through time and be accessible without loss. That is, the knowledge would have to be readable (implying a method of persistence that will be sound in later years) and to be meaningful (the issues related to representation and language). 
• The issue of time goes far beyond KBE. The nature of KBE modeling puts it at the forefront of the discussion.  If there were a neutral language, would it of necessity be of a ‘logic programming’ basis? Further discussion of the characteristics need for long term storage related to a 100-year language. 
• In reference to end-user computing, early KBE successes were of several types, but two can be used to discuss this topic. KBE allowed encapsulation of expertise such that a system could either augment a design process or play a major role, almost as a peer. In terms of the former, KBE tools allowed quick development and helped sustain process evolution. It allowed either a SME to be more productive through automation of tasks or helped spread the knowledge of the SME around. 
• In terms of the ‘peer’ role, KBE success resulted from having the man-in-the-loop that allowed a means to ride herd on the system as it tackled hard compute problems. This visual oversight, with its frequent checks along a computational path, ensured that things were progressing or that results were of use. In other words, the event was an SME expert working as a team with a smart system.
• Recent advance toward a newer KBE approach wants to increase the amount of knowledge (expertise) embedded within a system. One problem may arise in that the effort puts information behind a wall that may not be easily opened for review.
• Having the wall forces verification to be mainly of the ‘duck test’ variety that is behavioral in scope. Even from the SME perspective, there is a whole lot of black box to deal with. What role will language, and perhaps one that is external, need to play in this case?
• Furthermore, several ‘tricks’ are expected to support this KBE push. For one, an accumulation of combinations of relationships is thought to be sufficient to model all important factors of an event. That is, parameters, and simple rules, are the focus allowed by the wall. Yet, the system pieces that process these items are not amenable to assessment via a proof (or even model) theoretic method. 
• As well, it is expected that simulation can be used within a visualization and analysis framework such that simulation will essentially provide a proxy for reality. Applying analysis against the ‘simulated’ world is taken to be (almost, how close?) equivalent with seeing the real thing. Can simulation mimic the world enough to model occurrences related to any situation as they may unfold in reality?
• As an example, in CFD systems that model flow and use various presentation techniques to ‘play’ results to the user, can the underlying model be used to fully describe properties at a point? That is, can the underlying model be used as a proxy for reality in further processing? Not generally is the answer. This type of chaining of computational effects will be something that needs attention.

Since one trend of KBE is to increase automation, there will be many more decisions pushed behind the wall, so to speak. One question is how amenable will these be to overview which requires readability at the time of the KBE run, and later (perhaps, much later), via review of results. That is one concern of the first bullet, above. Another set of questions would deal with the complication stemming from ‘ontological’ differences which exist between a computational event and its parallel in the human-oriented processing. How is the ‘truth’ to be managed?

For further discussion, please contact John.m.switlik@ieee.org.