On "How to Build KBE Solutions for Products That Are More GENERIC, ROBUST and REUSABLE" – Part 1: System Definition
Brian Prasad, Ph.D., Control Systems Division, Parker Aerospace

INTRODUCTION

Often while designing an artifact, engineering teams forget that the product is a system. It consists of a number of subassemblies, each fulfilling a different but distinct function. A subassembly is a group of two or more units that can be brought together (say for instance, share common axes or fit together). Subassembly information includes sub-systems, components, parts, and features (materials, attributes, parameters, and geometric features).

Process information includes assembly features (joining faces, aligning bolts, common axes, welding lines, etc.), design methods (such as parts layout, design rules, analysis methods, packaging, tolerance dimensions, and material substitution and form features options. A feature is a representation of form, intent, and relevance to some aspect of part design of interest to either functionality (part fea¬tures or so called form features) or manufacturability (e.g., DFX—Design for X-ability) [Nielsen, 1990]. Form signifies the attributes of the features present, their connectivity (topology) and geometry. Relevancy points the reason a feature is included in the design (e.g., issues related to functionality or DFX rules). Intent represents the imposed constraints by the CE teams on the freedom of the parts’ function or rules associated with a DFX principle.

In order to achieve a truly integrated product and process design (IPPD), all the above needs have to be considered simultaneously. The core concept of IPPD is the “system definitions.” Consider what Szucs [1980, pp. 42] stated: The term system is used to denote an object composed of certain elements that are linked by well-defined (but not necessarily known) relationships. It is stipu¬lated that the system may interact with its environment (receive external stimuli) and that its behavior comprises responses that are useful or profitable to the operator. Objects completely isolated from their environment (completely closed system) and phenomena that cannot be influenced by person are not regarded as systems in the technological sense.

Before we take a close look at the requirements of a full IPPD system, let us review what constitutes a system. Truly, a system has three parts:

1. Class Hierarchy (a structure definition):
   
   Class hierarchy is a very efficient mechanism for system definition because one can use method and variable definitions in more than one subclass (such as sub-systems, components, etc.) without duplicating their definitions. For example, consider a system that represents various kinds of human operated vehicles (See Figure 1). This system would contain a generic class for vehicles, with subclasses for all the specialized types. Five major subclasses include: auto, truck, bus, aircraft and land transport devices. Their vehicle class would contain the methods and variables that were pertinent to all vehicle features, such as identifica¬tion numbers, passenger loads, fuel capacity, etc. The subclasses, in turn, would contain any additional methods and variables that were specific to the specialized cases [Taylor, 1993]. Truck may consist of pick-up, van and a tractor-trailer. Land transport devices may include sub¬classes such as motorcycles, bicycles, skateboards and unicycles.
   
   {motorcycles}
   {bicycles}
   {skateboards} ε [Land transport devices]
   ********
   {unicycles}
   Where ε denotes an element of a set or member of the class hierarchy.
   
2. Integration Hierarchy (an assembly definition):
   
   [Land transport devices] > {motorcycles, bicycles, skateboards and unicycles} Where > denotes “is a member of superclass set”. The elements in the curly bracket are its member classes.
   
3. Constancy-of-specifications, requirements, purpose or goals:
   This identifies the key product functions, requirements or constraints (RCs) of the product system, some of them are also common to its elements (product sub-classes). For example, general system-level RCs must gives rise to components’ (e.g., a department unit) level RCs. Constancy means carrying the same definition and the same sets of requirement’s hierarchy and management process throughout a product development process. IPD Teams must agree on a common set of engineering requirements that relate to the company’s (high-level product development) goals and customer needs. Constancy of RCs also provides a common set of ground rules for mutual cooperation and communication throughout the product development community. If a product development process is “left to themselves in the Western world, compo¬nents become selfish, competitive, independent profit centers [Deming, 1993].”
   
   RCs parts Ε RCs components Ε RCs subsystems Ε RCs system
   Ε RCs department Ε RCs SBUs Ε RCs enterprise
   
   Where, Ε denotes an element of.

Figure 1: Class of Human Operated Vehicles

Why Consider “Product as a System”?

There are many advantages in considering “Product” as a System.

Today, most companies are under extreme pressure to develop products within time periods that are rapidly shrinking. As the market changes, so does the requirements. This is more pronounced if the products are consumer-based. For instance, the product that a consumer wants today, may not like when delivered three years from now. Associated with this are the urgencies and pressures on the manufacturers’ part to modify their product characteristics based on the up-to-date requirements, while the product is still being developed. This has chilling effects in managing the complexity of such continuously varying product specifications and handling the ongoing changes. This is because, today, it takes an extensive time and efforts to propagate the specifications throughout the product design and development (PDD) process and then turn them into opportunities for growth and profits. The ongoing success of a “learning type” organization lies in its ability to apply novel methods and tools like KBE to capture its entire life-cycle PDD process (including its system definitions) into a system of “KBE Solutions.” Considering “Product as a System” while building a system of “KBE Solutions” has many benefits:

• The captured “product system” knowledge in the “KBE Solutions” could be reused quickly at the product’s “system definitions” level in order to configure many relevant subsystem solutions/possibilities.
• Organization could quickly react to changing requirements since system requirements are part of the KBE system definitions
• Organization could apply the “system-definitions knowledge” of KBE solutions as a proven baseline (starting point) to reinvent itself on new ideas or products that are not part of its KBE solution family yet; and
• By leveraging existing system knowledge in KBE Solutions, it is easy for organization to keep up with ever changing technology, new product introduction and innovation.

Many companies are stepping up the pace of life-cycle knowledge capture and are applying “KBE solutions & tools” more and more upfront in the product development process. By doing so, many organizations are achieving greater flexibility in new ways of engineering products more correctly the first time, and more often thereafter.

Capturing Systems Definitions via KBE makes the product Generic. For definition of what constitutes a Generic System, please refer to a prior article of Prasad (2005). What Distinguishes KBE from Automation

There is also a large return on investments; if we apply KBE solution at the system definition levels (like planning, product definition or conceptual design stages).

Figure 2: Incurred and future costs

Figure 2 illustrates the difference between the actually in¬curred cost and the future cost commitment (the locked-in cost of future spending at that stage of development). Two Curves are shown: Curve “c” represents the actual-costs incurred at any stage. Curve “d” is the future-cost that is committed at any stage due to decisions made earlier before this stage. They are based on data reported by Comput¬er-Aided Manufacturing (CAM) International Inc. The first stage is an ideal place for new ideas, new concepts, and new equipment, new processes, new technology, etc., to avoid possible changes in direction and backtracking at later stages. The system definition stage for KBE starts at the planning stage.

It has been reported [Patton, 1980] that 70% of the total cost of manufacturing a product is committed by the time of conceptual formulation, rising to 85% by the start of development before any hardware is built. Since the actual time and expense in product development during this initial stage is low (10-30%), any changes, introduced at this point, cost very little but can greatly influence the subsequent costs of the production [Nevins and Whitney, 1989].

Having a definition of what constitutes a system is the first step of being able to manage an IPPD system. However, a product-breakdown structure or its definition alone is not enough. The design of a typical automobile, aircraft, helicopter or a computer system involves thousands of engineers making millions of design decisions over several years. Class hierarchy was one of the key elements of organizing a complex product as described by Prasad [Chapter 8, pp. 380-387].

Decomposing the product realization process into class hierarchy of discrete activities is another essen¬tial element of IPPD. This is a future topic of Part 2 On “How to Build KBE Solutions.” It will be discussed in the next issue of COE NewsNet.

Acknowledgement

A technical paper [Prasad and Rogers, 2005] on which article is based was presented and published in the proceedings of the ASME 2005 International Design Engineering Technical Conferences & Computers and Information in Engineering Conference, September 24-28, 2005, Long Beach, California. (Paper No. DETC2005-85561)

References

• Deming, W.E., 1993, The New Economics, Cambridge, MA, published by MIT Center for Advanced Engineering Study, November 1993.
• Nielsen, E., 1990, “Designing Mechanical Components with Features”, Ph.D. Thesis, University of Massachusetts, Amherst, MA.
• Prasad, B., 1996, Concurrent Engineering Fundamentals: Integrated Product and Process Organization – Volume I, Prentice Hall PTR, Upper Saddle River, New Jersey.
• Prasad, B., 1997, Concurrent Engineering Fundamentals: Integrated Product a Development – Volume II, Prentice Hall PTR, Upper Saddle River, New Jersey.
• Prasad B. and Rogers, J., 2005, “A Knowledge-Based System Engineering Process For Obtaining Engineering Design Solutions, Proceedings of IDETC/CIE 2005. ASME 2005 International Design Engineering Technical Conferences & Computers and Information in Engineering Conference, September 24-28, 2005, Long Beach, California, USA. DETC2005-85561
• Prasad, B. “What Distinguishes KBE from Automation, COE NewsNet – June 2005, http://www.coe.org/newsnet/Jun05/knowledge.cfm#1
• Pugh, S., 1991, Total Design, Addison-Wesley Publishers, Woking¬ham, UK.
• Szucs, E., 1980, “Similitude and Modeling”, Elsevier Scientific Pub¬lishing Company, 1980, pp. 42.
• Taylor, D.A., 1993, “Object-Oriented Technology - A Manger’s Guide”, Addison-Wesley Publishing Company, Reading, MA.
• Nevins, J.L., and Whitney, D.E., et. al., 1989, Concurrent Design of Products and Processes, McGraw-Hill Publishing Co., New York, pp. 1-24.
• Patton, J., 1980, Maintainability and Maintenance Management, Instrument Society of America, Research Triangle Park, N.C.