AI includes Knowledge-based Engineering (KBE)
- 1st – AI, not solely ML (see below)
- 2nd – Knowledge and truth
- 3rd – Physicalness and mathematics
- 4th – ML’s emerge/surge and data/decisions
- 5th – Where do we go from here?
By: John M. Switlik, December 2023; Context: Sperry Univac Knowledge Systems Center.
After briefly touching upon AI (Artificial Intelligence), we will look at KBE from the perspective of several years. Engineering efficiency has always been a factor for progress. Engineering has had its own College in most Universities.
As a historical aside, Count Rumford, a Loyalist colonist went to Europe at the start of the American Revolution and found success there. Later, he gave money to Harvard in the early 1800s to found their Engineering College. Prior to this, Harvard had been more a general college with a major emphasis on divinity studies.
Jumping ahead, with the arrival of the computer, engineering motivated many enhancements. In particular, there was support for algorithms that solved the mathematical systems that engineering finds necessary. One principal language for work was FORTRAN which is still very much in use today.
This article has a focus on computational engineering which, for one thing, brings us to AI’s role in the 1980/90s. We will look at a contemporary of FORTRAN which played a role in KBE.
AI (and Lisp)
The 1950s start of AI was primarily done by mathematicians, many of whom were applied in focus. However, logic and qualitative modes were of interest too. They still need to be and will be hugely important in the future. John McCarthy defined Lisp to be a flexible handler of symbols. On top of his language, there were additions that supported models which were composed of objects with attributes and actions.
Lisp’s representational approach allowed easy building of associations in a lazy mode. Types were handled with a method called late binding and could be mixed within the definition of an attribute. Actions were implemented by a “function” call where the Lisp function provided the overlay and hand-shaking for remote procedures.
As an aside, functional programming was an attempt to constrain programming activities to allow more sound operational choices. However, that set of constraints works against creativity as needed for the design and implementation work. Whereas Lisp (and the languages that it influenced) still extant today, provided wide support for creativity. We will detail some of these uses.
Distributed computational modes were prototyped on Lisp. One of the first instances of shared memory across devices was with the Lisp Machine which we will look at further. Mathematical computational systems were defined on Lisp. Some of these are still around. Wolfram’s main system was originally developed using Lisp.
It might be said that Lisp offered superb support for qualitative modeling. The next section looks at its use in engineering which is heavily quantitative. However, engineering is also a heavy user of mathematical systems of equations. In the KBE context, Lisp allowed interchange of data with numeric processors. Early computing mainly automated slide-rule functions. FORTRAN and other languages over time allowed more complicated functionality. Logic was primitive Boolean types, for the most part.
But, mathematics is about more than numbers and crunching them. Higher-order logics do come into play. Too, as we have seen emerge over time, there are many types of modeling approaches. It is time to look at KBE’s role in this manner within engineering.
Knowledge-based engineering (KBE)
One of the early KBE systems was implemented on a Lisp Machine. Available to it were all the facilities of Lisp as well as access to development work from universities. The approach was model-based reasoning. There were associations between objects that mapped to real world states of affairs. Rather than rules, KBE used constraint satisfaction which is less general. The focus was on the model and relationships between objects as either individual parts or as an assembly of parts.
At the time, databases were maturing. Process management was coming to the fore. KBE covered the whole spectrum of these forward-looking activities and served as a unifying agent during crucial times in the program.
For one thing, KBE provided means to develop CAD models that were not then extant. We will look at ICAD which came out of the lab at MIT. As well, we can use the Boeing 777 program as an example (next section).
After that program, KBE, within Boeing, continued to provide support with increasing demands due to its ability. We will look at KBE over the years from then to now. But, more generally, KBE is still extant with many vendors offering the capability. Of late, along with the machine learning thrust, “generative” design has been getting attention. Some engineers remind us of this: unless there is a serious tie with engineering constraints and the underlying physics, this is art.
One might say, as we have seen this year with the generative modes (xNN/LLM, in particular), the jury is still out. In fact, we have not even seen reasonable data to try to make a determination. Why? Where can the data be generated in other than a make-believe style as has emerged in the machine learning situation?
This article suggests one that will be discussed in appropriate detail to foster the needed discussions. That will come later. Now, let’s look a KBE as it has been known from the late 1980s until now.
KBE and Boeing
The Boeing 777 project attempted the first attempt at using digital definition on a grand scale. The 777 aircraft is still in service. At the time of first test flight, some of the remarks were as follows:
- best fit ever; improved handling of aero and load requirements; greatly enhanced materials specifications in quality and effectivity of the fabrication and assembly processes; and more. There are many reports that we can point to.
There are many that could be and were used. This article looks at one approach that was delivered eventually in Visual Basic on a PC. In the beginning, though, it was delivered in Common Lisp (CL).
Briefly, CL was defined and delivered on the engineering workstations that appeared in the 1980s. This allowed KBE to move to networked workstations where distributed modes allowed real-time, 24/7 support for interactive and batch work. A boost in efficiency came when a compiler for Common Lisp was developed. This allowed executable code to be packaged for background work including being implemented as embedded systems.
In Boeing, KBE was supported by the Company’s world class libraries of engineering and mathematical routines. These supported the CAE and other analysis requirements. Too, the mathematical support for advanced NURBS work ensured that the solid modeling could go beyond the primitive stage associated with conic equations. KBE would pull CAD models and improve the mathematical representation.
Now, multiphysics has become the norm where systems handle representational balancing through various means. As mentioned in the last section, future work would preserve that progress. Generative design, with its data focus, has problems that need to be lifted to awareness. We will be getting into that.
Back to the approach at Boeing, KBE was used with defined steps to improve both the process and the parts being defined and built. The whole process and the results were under the control of certified engineers who approved the designs prior to release to manufacturing where existing processes were in place. One result was a better passing of information and data down the line overcoming some of the silos that had developed with the old processes.
Program reviews for this aircraft have been published. We will be providing a list of those. However, our focus in the beginning is technical as the current “AI” has resulted in a situation where unknowns have multiplied somewhat due to the growth of influence of computing on people.
Of course, by the time of KBE, CAD/CAE and other routines had improved, as had the database management systems. KBE was an integrating system that helped ensure a proper maturing of computational support as the overall process management effort sought measurable improvement. Several KBE projects attained the SEI CMM Level 5 rating (dealing with software engineering and maturity) which is significant.
MSJO (KBE project)
This series will look at the history of KBE. There will be some specific examples such as support for design and build of critical parts that required forging and machining. One project that started with the 777 project will be featured which dealt with representation choices and providing an optimized set of information to the organization that handled “master” data through time. The name implies the focus: Multiple Surface Join and Offset (MSJO). Solid modelers require strict handling of the mathematical expressions.
MSJO work supported many steps along the process. Part and tool designs were scrutinized and optimized for representational efficiency which allowed more effective downstream processing. Early design efforts enhanced form while preserving fit. In other domains, data collection schemes.
There are many other examples that will be covered with the context of the supporting data for an approved Patent. One of these involved design and build of forging dies which was briefly described in this post: Forging examples.
Summary
This article is an introduction to an expected series that will look at current issues and discuss consequences in a manner that is technical in focus. One intent is to determine topics that must be brought to the table. But, an imperative is to also keep the history in focus. KBE is one of many pieces that could make up the eventual AI which machine learning, solely, is not. Future articles will address quantitative/qualitative imbalances which result from prior choices. Too, we will show the evolution of computing and how AI came to be in the past and touch upon the current manifestation’s powerful grasp on human imagination. A principal theme will be that gaming (and non-strict metrical spaces) cannot attain the stature of being “engineering” for several reasons. It needs to be mentioned that many universities are involved with KBE. There are various pieces of information to gather, such as the extent of KBE incursion into the market over the years. The author of this article has an interest in truth engineering which arose from the experiences in early KBE. Expect that theme to be regularly touched upon as this series expands.
Notes
The below list provides links to material that associates with the history of KBE.
- Languages. After several iterations using Lisp, ICAD moved to a PC which could support Common Lisp and ICAD. At the same time, the CAD package was improved. Later, ICAD was bought by the CAD vendor and shelved. However, KBE continued with newer systems: How Paradigms of Computing Might Relate to KBE (2007), John M. Switlik, CTO, AJSwtlk (formerly, Technical Fellow at Boeing) – developer of MSJO.
- CATIA Knowledge-Based Engineering (2018) – provider of CAD/CAX for Boeing. Page provides information relating to a course that covers KBE well. KBE covers a lot of bases including dynamics analysis and action.
- Formalization of engineering knowledge for industrial robots … (2020) – mentions some of the history as well as the current state of the art.
Systems and methods for filtering and smoothing data, US7139674B2, Switlik and Klein
As mentioned in the Wikipedia page on the subject, KBE is important, in many ways. We all understand and appreciate knowledge. Having the computer involved in an old industry (of the human intelligence) has brought both boon and bane. Sometimes, it seems as if the latter is more prevalent.
Context
Boeing Commercial Aircraft