Knowledge-based Engineering - Languages For KBE

Languages For KBE

Some questions can be asked in regard to KBE implementation: can we represent knowledge in a vendor-neutral format? can the knowledge in our designs be retained for decades, long after a vendor system (such as CATIA) has disappeared?

These questions are addressed in the 2007 NASA-ESA Workshop on Product Data Exchange presentation A Language for Engineering Design by Walter Wilson of Lockheed Martin.

Mr. Wilson advocates using a type of programming language to define design data—operations, parameters, formulas, etc. -- instead of a proprietary file format (such as Dassault's CATIA). One's data would no longer be tied to a specific CAD system. Unlike STEP, which inevitably lags commercial CAD systems in the features it supports, programmability would allow the definition of new design features.

A logic programming language is proposed as the basis for the engineering design language because of its simplicity and extensibility. The geometric engine for the language features would be open source to give engineers control over approximation algorithms and to better guarantee long-term accessibility of the data.

Meanwhile, the open-source General-purpose Declarative Language ("Gendl") (available at github and in commercial packages from Genworks) addresses the issue of application longevity by providing a high-level declarative language kernel which is a superset of a standard dialect of the Lisp programming language (ANSI Common Lisp, or CL).

The Gendl kernel follows a concise, pragmatic language specification representing a proposed de facto neutral format for representing KBE-style knowledge. It consists of the same Smalltalk-inspired declarative object-oriented (and object-centric) message-passing format which been a common thread among classical KBE systems for more than two decades. While CL is a multi-paradigm language (supporting procedural, object-oriented, and functional programming), the core features of KBE tend to share several aspects with Functional programming languages "under the hood" (e.g. lazy evaluation, immutable data). However there is a consensus that pure Functional programming is too esoteric for typical engineers to practice, so one of the purposes of a declarative KBE language such as Gendl is to provide an "engineer-friendly" object-centric front-end on what is essentially a Functional language programming environment.

Because Gendl applications are written as a strict superset of a standard Lisp dialect, only the high-level declarative surface syntax is Gendl-specific. The bulk of application code is purely compliant with the underlying language standard. And because of Lisp's inherent (and unique) support for code transformation macros, even this surface syntax is subject to straightforward automated conversion among other variations of the de facto standard. It is reasonable to expect that implementations following this approach will eventually converge on a true vendor-neutral Standard KBE language specification.

The Pacelab Suite addresses the problem that functional programming languages are still not widely accepted by potential KBE users. Engineers are usually trained in procedural and object-oriented programming languages; in quite a few software environments (Excel, MATLAB and FORTRAN) used by engineers the procedural programming style clearly dominates. Therefore the Pacelab Suite rebases the inherent technological advantages offered by a development and runtime environment like Common Lisp, on a new technological paradigm (.NET Framework) equally supporting procedural, object-oriented and functional languages.