Knowledge-based engineering (KBE) is the application of knowledge-based systems technology to the domain of manufacturing design and production. The design process is inherently a knowledge-intensive activity, so a great deal of the emphasis for KBE is on the use of knowledge-based technology to support computer-aided design (CAD) however knowledge-based techniques (e.g. knowledge management) can be applied to the entire product lifecycle.
The CAD domain has always been an early adopter of software-engineering techniques used in knowledge-based systems, such as object-orientation and rules. Knowledge-based engineering integrates these technologies with CAD and other traditional engineering software tools.
Benefits of KBE include improved collaboration of the design team due to knowledge management, improved re-use of design artifacts, and automation of major parts of the product lifecycle.
Overview
KBE is essentially engineering on the basis of knowledge models. A knowledge model uses knowledge representation to represent the artifacts of the design process (as well as the process itself) rather than or in addition to conventional programming and database techniques.
The advantages to using knowledge representation to model industrial engineering tasks and artifacts are:
- Improved integration. In traditional CAD and industrial systems each application often has its own slightly different model. Having a standardized knowledge model makes integration easier across different systems and applications.
- More re-use. A knowledge model facilitates storing and tagging design artifacts so that they can easily be found again and re-used. Also, knowledge models are themselves more re-usable by virtue of using formalism such as IS-A relations (classes and subclasses in the object-oriented paradigm). With subclassing it can be very easy to create new types of artifacts and processes by starting with an existing class and adding a new subclass that inherits all the default properties and behaviors of its parents and then can be adapted as needed.
- Better maintenance. Class hierarchies not only facilitate re-use they also facilitate maintenance of systems. By having one definition of a class that is shared by multiple systems, issues of change control and consistency are greatly simplified.
- More automation. Expert system rules can capture and automate decision making that is left to human experts with most conventional systems.
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 includes 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).
There are two primary ways that KBE can be implemented:
- Build knowledge models from the ground up using knowledge-based technology
- Layer knowledge-based technology on top of existing CAD, simulation, and other engineering applications
An early example of the first approach was the Simkit tool developed by Intellicorp in the 1980s. Simkit was developed on top of Intellicorp's Knowledge Engineering Environment (KEE). KEE was a very powerful knowledge-based systems development environment. KEE started on Lisp and added frames, objects, and rules, as well as powerful additional tools, such as hypothetical reasoning and truth maintenance. Simkit added stochastic simulation capabilities to the KEE environment. These capabilities included an event model, random distribution generators, simulation visualization, and more. The Simkit tool was an early example of KBE. It could define a simulation in terms of class models and rules and then run the simulation as a conventional simulation would. Along the way, the simulation could continue to invoke rules, demons, and object methods, providing the potential for much richer simulation as well as analysis than conventional simulation tools.
One of the issues that Simkit faced was a common issue for most early KBE systems developed with this method: The Lisp knowledge-based environments provide very powerful knowledge representation and reasoning capabilities; however, they did so at the cost of massive requirements for memory and processing that stretched the limits of the computers of the time. Simkit could run simulations with thousands of objects and do very sophisticated analysis on those objects. However, industrial simulations often required tens or hundreds of thousands of objects, and Simkit had difficulty scaling up to such levels.
The second alternative to developing KBE is illustrated by the CATIA product suite. CATIA started with products for CAD and other traditional industrial engineering applications and added knowledge-based capabilities on to them; for example, their KnowledgeWare module.
History
KBE developed in the 1980s. It was part of the initial wave of investment in Artificial Intelligence for business that fueled expert systems. Like expert systems, it relied on what at the time were leading edge advances in corporate information technology such as PCs, workstations, and client-server architectures. These same technologies were also facilitating the growth of CAx and CAD software. CAD tended to drive leading edge technologies and even push them past their current limits.[5] The best example of this was object-oriented programming and database technology, which were adapted by CAD when most corporate information technology shops were dominated by relational databases and procedural programming.
As with expert systems, KBE suffered a downturn during the AI Winter. Also, as with expert systems and artificial intelligence technology in general, there was renewed interest with the Internet. In the case of KBE, the interest was perhaps strongest in the business-to-business type of electronic commerce and technologies that facilitate the definition of industry standard vocabularies and ontologies for manufactured products.
The semantic web is the vision of Tim Berners Lee for the next generation of the Internet. This will be a knowledge-based Internet built on ontologies, objects, and frame technologies that were also enabling technologies for KBE. Important technologies for the semantic web are XML, RDF, and OWL. The semantic web has excellent potential for KBE, and KBE ontologies and projects are a strong area for current research.
KBE and product lifecycle management
Product Lifecycle Management (PLM) is the management of the manufacturing process of any industry that produces goods. It can span the full product lifecycle from idea generation to implementation, delivery, and disposal. KBE at this level will deal with product issues of a more generic nature than it will with CAx. A natural area of emphasis is on the production process; however, lifecycle management can cover many more issues such as business planning, marketing, etc. An advantage of using KBE is getting the automated reasoning and knowledge management services of a knowledge-based environment integrated with the many diverse but related needs of lifecycle management. KBE supports the decision processes involved with configuration, trades, control, management, and a number of other areas, such as optimization.
KBE and CAx
CAx refers to the domain of computer-aided tools for analysis and design. CAx spans multiple domains. Examples are computer-aided design of manufactured parts, software, the architecture of buildings, etc. Although each specific domain of CAx will have very different kinds of problems and artifacts, they all share common issues as well such as having to manage collaboration of sophisticated knowledge workers, design and re-use of complex artifacts, etc.
Essentially KBE extends, builds on, and integrates with the CAx domain typically referred to as Computer Aided Design (CAD). In this sense KBE is analogous to Knowledge-Based Software Engineering, which extended the domain of Computer Aided Software Engineering with knowledge-based tools and technology. What KBSE was to software and CASE, KBE is to manufactured products and CAD.
An example can be taken from Boeing's experience. The 777 Program took on the challenge of having a digitally-defined plane. That required an investment in large-scale systems, databases, and workstations for design and analytical engineering work. Given the magnitude of the computing work that was required, KBE got its toe in the door, so to speak, through a "pay as you go plan." Essentially, this technique was to show benefits and then to obtain more work (think agile engineering) thereby. In the case of the 777, the project got to where influences to changes in the early part of the design/build stream (loads) could be recomputed over a weekend to allow evaluation by downstream processes. As required, engineers were in the loop to finish and sign off on work. At the same time, CAx allowed tighter tolerances to be met. With the 777, KBE was so successful that subsequent programs applied it in more areas. Over time, KBE facilities were integrated into the CAx platform and are a normal part of the operation.
KBE and knowledge management
One of the most important knowledge-based technologies for KBE is knowledge management. Knowledge management tools support a wide spectrum repository, i.e., a repository that can support all different types of work artifacts: informal drawings and notes, large database tables, multimedia and hypertext objects, etc. Knowledge management provides the various group support tools to help diverse stake holders collaborate on the design and implementation of products. It also provides tools to automate the design process (e.g., rules) and to facilitate re-use.
KBE methodology
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," proposes solutions which focus on the structuring and formalization steps as well as links to the implementation.
An alternative to MOKA is to use general knowledge engineering methods that have been developed for expert systems across all industries or to use general software development methodologies such as the Rational Unified Process or Agile methods.
Languages for KBE
Two critical issues for the languages and formalisms used for KBE are:
- Knowledge-based vs. procedural programming
- Standardization vs. proprietary
Knowledge-based vs. procedural programming
A fundamental trade-off identified with knowledge representation in artificial intelligence is between expressive power and computability. As Levesque demonstrated in his classic paper on the topic, the more powerful a knowledge-representation formalism one designs, the closer the formalism will come to the expressive power of first order logic. As Levesque also demonstrated, the closer a language is to First Order Logic, the more probable that it will allow expressions that are undecidable or require exponential processing power to complete. In the implementation of KBE systems, this trade off is reflected in the choice to use powerful knowledge-based environments or more conventional procedural and object-oriented programming environments.
Standardization vs. proprietary
There is a trade off between using standards such as STEM and vendor- or business-specific proprietary languages. Standardization facilitates knowledge sharing, integration, and re-use. Proprietary formats (such as CATIA) can provide competitive advantage and powerful features beyond current standardization.
Genworks GDL, a commercial product whose core is based on the AGPL-licensed Gendl Project, 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). Gendl/GDL itself is proposed as a de facto standard for ANSI CL-based KBE languages.
In 2006, the Object Management Group released a KBE services RFP document and requested feedback. To date, no OMG specification for KBE exists; however, there is an OMG standard for CAD services.
An example of a system-independent language for the development of machine-readable ontologies that is in the KBE domain is Gellish English.
