Handbook on Intelligent Healthcare Analytics

There are two core components of the KBSs:

• Information base (consists of a collection of details and a set of laws, structures, or procedures).

• Inference engine (Responsible for the extension of the information base to the issue at hand).

In contrast to human expertise, there are pros and cons to utilizing KBSs.

It starts with a discussion about what KBE is in this book and begins with a simple definition: Knowledge-based Engineering (KBE) uses the knowledge of product and operation, which was collected and retained in specific software applications, to enable its direct usage and reuse in the development of new products and variants. KBE’s implementation consists of applying a specific class of computing tools, called the KBE systems, which enable engineers to acquire and reuse engineering knowledge using methods and methodologies. The name of the KBE architecture is derived from the mixture of KBS and engineering, which are one of the major outcomes of AI. In the 1970s, KBE systems demonstrate the advancement of the KBS by applying the special engineering industry requirements. KBE systems combine KBS rule-based logic technologies with engineering data analysis and geometry like CAD.

For these reasons, a traditional KBE architecture provides the user with a programming language that is generally object-oriented and one (something more) embedded or closely connected CAD engine. The vocabulary of programming enables the user to capture and reuse rules and procedures in engineering, while the object-oriented approach of design corresponds well with how engineers see the world: systems abstract assets of objects, defined by parameters and behaviors, linked by relationships. Access and management by the programming language of the CAD engine meet the geometry handling requirements characteristic of the engineering architecture. The MIT AI laboratories and the Computer Vision CAD Group developed the first commercially available KBE system named ICAD1984 (now PTC). Fortunately, this asks the first inquiry you will hear in Figure 1.3about KBE.

It will be useful at this stage to quickly clarify what we refer to as information and how we use this term to describe concepts other than data and evidence. Both terms are sometimes misused in the traditional spoken language; truth and knowledge are often interchangeably used. The hierarchy of data and intellect (and knowledge) is the subject of long-term disputes between epistemologists and IT experts. Since this subject goes well beyond the scope of this chapter, this is our definition of data. Data are objects that have no meaning before they are put in form like symbols, statistics, digits, and indications. The information consists of important processed data. The context in which the data are collected gives it meaning, importance, and intent. Human and electronic information can be collected, shared, and processed. The knowledge is encrypted by code, normally organized in a structure or size, and stored in hard or soft media to accomplish this. Awareness is the condition of information and awareness processing, which requires the chance to act.

New information may be produced as a result of the application of knowledge. The IGES file with a geometrical definition of the surface as a piece of information is an example of this. IGES files will be encoded with numbers and symbols (i.e., data) and will only provide knowledge useful if they understand the meaning (i.e., the fact they are the data of an IGES file). The information which can be collected with a KBE method is regarded as a simple example of the algorithm that reads such an IGES file, reconstructs a specified surface model, intersects it with a floor plane, and, if the crossroad is non-zero, calculates the length of the corresponding curve. It is also sensible to ask why geometry varies from the standard CAD paradigm and enables the creation and manipulation of geometry. Owing to the varying scopes of these systems, the differences are important. Digitized drawing systems, which allow programmers to catch their ideas have been designed to create CAD systems. They build and store the results using the CAD framework’s geometry simulation functions. A set of points, lines, planes, and solids with reference and note are an almost all-inclusive link to the structure. These data provide enough information for the creation of a system that can be used to build a specification by production engineers. In doing so, creators store the specifics of “what,” but they retain the “how” and “why.” In a sense, the CAD approach can be considered a system “posterior,” because before it can be moved to the system it is necessary to know what the principle is like. It can be argued that CAD is geometry or drawing/drawing engineering to distinguish this approach from KBE.

Figure 1.3 KBE.

KBE-supported technology is different. Technology Instead of shifting “what,” engineering experts are trying to move “how” and “why,” encapsulating in the KBE process knowledge and thinking instead of geometry in the CAD framework. Not only does this work by manipulating geometric structures, but programming is needed rather than writing. The “how” and “why” in engineering are in some cases used in textbooks, databases, tip sheets, and several other outlets. Much of the knowledge is held up by engineers, mostly in a manner that is strongly compiled and not specifically suitable for translation to the KBE procedure. This experience should be sufficiently transparent to create a KBE program to be codified into a software application capable of producing all kinds of product specifics, including geometry templates, scores, and data that are not associated with the geometry. Because of its capacity to generate a specification rather than simply text, it is widely referred to as a generative model.

How easy is the use of KBE? It is only necessary to rapidly generate different configurations and variants of a given variable. In certain practical cases, this is not essential, so it may be a wrong expenditure to try to clarify details and program a KBE system. One-off prototypes and designs that need not be optimized or prototype versions for space travel are usually outside the scope of KBE implementation.

It explores the design field through the development of different design variants within the product family and evaluates its performance compared to previously tested versions with the multidisciplinary optimization (MDO) application. KBE will assist in many respects in this case.

It enables stable product parametric models to be generated which make topology changes and the freedom to make adaptation changes usually impossible for those built with a conventional CAD framework. This is important when considering broad variations like those which occur when a yacht manufacturer decides to accept one or more hull settings. It supports the integration into MDO through automation of the generation of necessary disciplinary abstractions of heterogeneous sets of analytical methods (low and high fidelity, in-house and off-shelf). It removes the optimizer from the challenge of managing the spatial integration constraints that generative models should guarantee. This is essential because the user does not need to specify constraints on configuration variables or restrictions to avoid intersection of two elements; or because a certain structural element does not need to remain beyond the same outer mold line; or because, during optimization, two products are expected to have a certain relative position apart.