Knowledge-based engineering

From Wikipedia, the free encyclopedia
Jump to: navigation, search

Knowledge-based engineering (KBE) is a discipline with roots in computer-aided design (CAD) and knowledge-based systems but has several definitions and roles depending upon the context. An early role was support tool for a design engineer generally within the context of product design.

Overview[edit]

KBE can be defined as engineering on the basis of digital knowledge models. Such knowledge models are the result of knowledge modeling that uses knowledge representation techniques to create the computer interpretable models. The knowledge models can be imported in and/or stored in specific engineering applications that enable engineers to specify requirements or create designs on the basis of the knowledge in such models. There are various methods available for the development of knowledge models, most of them are system dependent. An example of a system-independent language for the development machine-readable ontology databases, including support for basic engineering knowledge, is called Gellish English. An example of a CAD-specific system that can store knowledge and use it for design is the CATIA program through its KnowledgeWare module. An example of a CAD-independent, language-based KBE system with full compiler and support for runtime application deployment is Genworks GDL from Genworks International.

KBE can have a wide scope that covers the full range of activities related to Product Lifecycle Management and Multidisciplinary design optimization. KBE's scope would include design, analysis (computer-aided engineering – CAE), manufacturing, and support. In this inclusive role, KBE has to cover a large multi-disciplinary role related to many computer aided technologies (CAx).

KBE also has more general overtones. One of its roles is to bridge knowledge management and design automation.[1] Knowledge processing is a recent advance in computing. It has played a successful role in engineering and is now undergoing modifications (to be explained). An example of KBE’s role is generative mechanical design.[2] There are others. KBE can be thought of as an advanced form of computer applications (in some forms with an extreme end-user computing flavor) that support PLM and CAx.

There are similar techniques, such as electronic design automation. AAAI provides a long list of engineering applications.[3] some of which are within the KBE umbrella. At some point, the concept of KBE might split into several sub-categories as MCAD and ECAD are just two of many possible types of design automation.

History[edit]

KBE essentially was a complementary development to CAx [4] and can be dated from the 1980s (See Also, ICAD). CAx has been developing along with the computer after making large strides in the 1970s.

KBE technologies suffered a downslide during AI Winter. While KBE had sufficient success stories that sustained it long enough into the 1990s, very high expectations and the inability to meet them with KBE resulted in it being considered obsolete in a way similar to LISP AI designs.

KBE, as implemented with ICAD can be thought of as an advanced form of computer applications (in some forms with an extreme end-user computing flavor) that support PLM and CAx.

Success of early KBE prototypes was remarkable; eventually this led to KBE being considered as the basis for generative design with many expectations for hands-off performance where there would be limited human involvement in the design process.

KBE and product lifecycle management[edit]

The scope of PLM involves all the steps that exist within any industry that produces goods. KBE at this level will deal with product issues of a more generic nature than it will with CAx. Some might call this level 'assembly' in orientation. However, it's much more than that as PLM covers both the technical and the business side of a product.

KBE then needs to support the decision processes involved with configuration, trades, control, management, and a number of other areas, such as optimization.

Recently[when?] the Object Management Group released a RFP document and requested feedback.[5]

KBE and CAX[edit]

CAx crosses many disciplinary bounds and provides a sound basis for PLM. In a sense, CAx is a form of applied science that uses most of the disciplines of engineering and their associated fields. Materials science comes to mind.

KBE's support of CAx may have some similarities with its support of PLM but, in a sense, the differences are going to be larger.

The KBE flavor at the CAx level may assume a strong behavioral flavor. Given the underlying object oriented focus, there is a natural use of entities possessing complicated attributes and fulfilling non-trivial roles. One vendor's approach provides a means via workbenches to embed attributes and methods within sub-parts (object) or within a joining of sub-parts into a part.

As an aggregate, the individual actions, that are event driven, can be fairly involved. This fact identifies one major problem, namely control of what is essentially a non-deterministic mixture. This characteristic of the decision problem will get more attention as the KBE systems subsume more levels and encompasses a broader scope of PLM.

KBE and knowledge management[edit]

KBE is related to knowledge management which has many levels itself. Some approaches to knowledge are reductionistic, as well they ought to be given the pragmatic focus of knowledge modeling. However, due to KBE dealing with aggregates that can be quite complicated both in structure and in behavior, some holistic notions (note link to Complex systems) might be apropos.

Also, given all the layers of KBE and given the fact that one part of an associated space is heavily mathematical (namely, manifold in nature), KBE is extremely interesting from the knowledge viewpoint (or one would hope).

All one has to do is note that the KBE process's goal is to produce results in the 'real world' via artifacts and to do so using techniques that are highly computational. That, in essence, is the epitome of applied science/engineering, and it could never be non-interesting.

KBE methodology[edit]

The development of KBE applications concerns the requirements to identify, capture, structure, formalize and finally implement knowledge. Many different so-called KBE platforms support only the implementation step which is not always the main bottleneck in the KBE development process. In order to limit the risk associated with the development and maintenance of KBE application there is a need to rely on an appropriate methodology for managing the knowledge and maintaining it up to date. As example of such KBE methodology the EU project MOKA "Methodology and tools Oriented to Knowledge based Applications" propose solutions which focus on the structuration and formalization steps as well as links to the implementation.[6]

An alternative to MOKA is to use a general methodology for developing knowledge bases for expert systems and for intranet pages.[7]

Languages for KBE[edit]

Some questions can be asked with regard to KBE implementation: Can knowledge be represented 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.[8] It 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.[9] 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, Genworks GDL,[10] a commercial product whose core is based on the AGPL-licensed Gendl Project,[11] 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.[12] 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 Genworks GDL is to provide an "engineer-friendly" object-centric front-end on what is essentially a Functional language programming environment.

Because Genworks GDL applications are written as a strict superset of a standard Lisp dialect, only the high-level declarative surface syntax is GDL-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[13] addresses the problem that functional programming languages are still not widely accepted by potential KBE users. Pacelab Suite rebases the 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.

KBE in Academia[edit]

Implementations[edit]

The following KBE development packages are commercially available:

For CAD[edit]

For General-purpose development of Web-deployed applications[edit]

For analysis, design and engineering processes[edit]

KBE futures, KBE theory[edit]

KBE, as a particular example of KBS, is a multi-disciplinary framework that has more than practical considerations. Not only will KBE require successful handling of issues of the computational (Ontology, Artificial Intelligence, Entscheidungsproblem, Interactive computation, Category Theory, ...) and logic (non-monotonic issues related to the qualification, frame, and ramification problems)), it will touch upon all sciences that deal with matter, its manipulations, and the related decisions. In a sense, Product Lifecycle Management allows us to have the world as a large laboratory for experimental co-evolution of our knowledge and artificial co-horts. As noted in ACM Communications, "Computers will grow to become scientists in their own right, with intuitions and computational variants of fascination and curiosity." [14] What better framework is there to explore the "increasingly complicated mappings between the human world and the computational"?

A continuing theme will be resolving the contextual definitions for KBE into a coherent discipline and keeping a handle on managing the necessary quantitative comparisons. One issue considers what limits there may be to the computational; this study requires a multi-disciplinary focus and an understanding of the quasi-empirical. Given the knowledge focus of KBE, another issue involves what limits there might be to a computational basis for knowledge and whether these are overcome with the more advanced types of human-machine interface.

It is important not to treat the KBE technology in isolation, but focus more on its role in the overall Product Development Process (PDP). During development, it is important to streamline the process from knowledge capture towards software implementation. To this end, close-coupling between Knowledge Management and KBE is desired. Transitions from data and information inside a Knowledge Base towards software code is of particular relevance. The best results can be achieved by using model-driven software development principles, which includes automatic code generation and round-tripping. The use of KBE during a PDP not only requires the ability to easily set-up (existing) KBE applications from a knowledge level, but also the ability to store back the results after execution of the tool. In order to use KBE on a strategical level as decision-making and planning support mechanism, it is important to relate results back to the system engineering domain (requirements, functions, options, embodiment). From deployment perspective, a better integration with other IT tools should be realized. Couplings between KBE applications, Knowledge Bases and Simulation Workflow Management software are of particular importance. The iProd project tries to take KBE to the next level by addressing these aspects.[15] The iProd framework uses KBE technology as a reasoning mechanism to infer new product knowledge and, as a means to automate virtual execution (CAE simulation) and as MDO-enabler. On an IT level, it prototypes KB-KBE couplings (code generation, round-tripping, results storage and automatic workflow generation) and SWFM-KBE integration (on the basis of the software-as-a-service paradigm).

See also[edit]

References[edit]

  1. ^ COE Newsnet, 06/05, What distinguishes KBE from automation?
  2. ^ COE Newsnet, 04/05 Generative Mechanical Design: An Asset for Small & Medium-Sized Businesses
  3. ^ AAAI Engineering, subtopic of Applications
  4. ^ COE Newsnet 10/05 Knowledge Based Engineering (KBE: Update)
  5. ^ KBE services for PLM
  6. ^ MOKA project
  7. ^ "Knowledge Acquisition in Practice: A Step-by-step Guide" by Nick Milton [1]
  8. ^ Walter Wilson of Lockheed Martin. "A Language for Engineering Design". 
  9. ^ http://www.axiomaticlanguage.org
  10. ^ http://www.genworks.com
  11. ^ http://github.com/genworks/gendl
  12. ^ http://www.genworks.com/downloads/customer-documentation/usage.txt
  13. ^ http://www.pace.de/en/group.php?myid=2&subid=0&mydataid=5
  14. ^ ACM Communications, 11/09 Deep Data Dives Discover Natural Laws
  15. ^ iProd project (integrated management of product heterogeneous data)

External links[edit]