548 IEEE TRANSACTIONS ON SYSTEMS, MAN, AND CYBERNETICS, VOL. 22, NO. 3, MAY/JUNE 1992

Functional Implications of Component Commonality in Operational Systems

Lawrence Dale Thomas

Abstruct- The application of commonality in a system represents an attempt to reduce costs by reducing the number of unique com- ponents. Researeh in this a m has primarily addressed a significant benefit of commonality, the reduction of parts inventories in assemble- to-order manufacturing systems. Likewise, in an operational system subject to component failures, spares inventories are reduced through the increased commonality of components. However, commonality tends to degrade system performance parameters, a degradation that can preclude commonality in resource constrained systems such as spacecraft. The functional impacts of component commonality on a system is addressed in a manner that allows inclusion in a commonality analysis.

I. INTRODUCTION Commonality can be defined as a measure of the number of

unique components in a system relative to the total number of components in the system. The application of commonality in a system represents an attempt to reduce costs by reducing the number of unique components. The life cycle cost of systems is typically said to be comprised of four components: Research and development cost, production cost, operation cost, and disposal cost [3]. Ideally, increased commonality reduces research and development costs by replacing duplicate research and development efforts on functionally similar system components with a single development effort. Like- wise, increased commonality reduces production costs through larger production lot sizes and reduces operations costs through increased standardization [6].

A unique component possesses some quantifiable differences in form or function relative to another component; in this context, two components can be unique with respect to each other even though they are common with respect to other components. Given two unique components A and B, common component AB must incorporate the functions required of both A and B, and is used in all applications within the system that formerly used either A or B . The general formulation of commonality is one in which a new component AB results from making component A common with component B . For example, if pump A must operate under high pressure and pump B must provide a high flow rate, then common pump AB must operate under high pressure and provide high flow rates. A less general formulation provides for the direct replacement of component A by component B, which then becomes the common component AB to be used in both applications. For example, a larger tank B can be used instead of a smaller tank A in those applications within the system that use tank A. This formulation is adequate for the example of Section V.

Since the common component AB must satisfy the functional requirements of both component A and component B, in general component AB will possess some excess functions when compared to item A and other excess functions compared to item B . The manifes- tations of this excess functionality can be increased weight, volume, and power consumption or decreased mean time between failure

Manuscript received June 28, 1990; revised March 29, 1991, and October

The author is with the National Aeronautics and Space Administration at

IEEE Log Number 9106498.

29, 1991.

the George C. Marshall Space Flight Center, EJ13, Huntsville, AL 35812.

(MTEIF) for hardware items; another manifestation can be increased complexity of the item AB relative to items A and B, resulting in increased purchase cost per unit. Clearly, for two components A and B, which are identical, cost savings will result from making A and B common; cost savings will follow from the elimination of a redundant development effort, from a single production lot instead of two smaller production lots, and a smaller spares inventory. However, in general components A and B are only similar rather than identical. Thus, commonality analyses must quantify the system performance impacts associated with commonality in conjunction with purchase and operating cost savings.

11. BACKGROUND

The body of research in commonality is primarily devoted to the subject of inventory for assemble-to-order systems. Assemble-to- order is a manufacturing strategy where parts and subassemblies are stocked in inventory according to forecasts, while the final assembly of products is delayed until customer orders have been received [21]. It has been proven that component inventories are reduced for arbitrary demand distributions when a common component is used instead of two or more unique components [l], [9]. The assemble- to-order inventory problem is analogous to the maintenance spares inventory problem for an operational system, where spare components are stocked according to some forecast demand or component failure rate. Thus, for systems where storage space is tightly constrained or if the carrying cost is particularly high for a given family of components, the application of commonality can be of benefit.

Another potential benefit of commonality can be the reduction of system development costs. The Space Station Freedom Program employs common structural subassemblies in the module pressure shells to reduce development costs; by designing fewer pieces of unique structure, the engineering, tooling, and qualification costs are lowered [12], [14]. Component commonality can also allow the possibility of cannibalization, where a malfunctioning product can be stripped of its functioning components for emergency maintenance of other products [ll].

The foregoing benefits of commonality, plus some others, are well known. To a smaller extent, the costs of commonality have also been studied. Again in the context of assemble-to-order inventory system, increasing commonality leads to less flexibility in the product line [SI. The disutility of refusing to provide each segment of customers with an item fitting their exact requirements will lead to lost sales and hence decreased demand. In terms of operational systems, this is analogous to degrading system functional parameters, such increased weight and power consumption, which can limit the application of commonality in tightly constrained systems.

The solution of the commonality problem has received considerable attention. Early solution strategies centered on various nonlinear programming techniques [4], [8], [13], [17]. Later, heuristics were developed for solution of the commonality problem [2] ,[16], and some heuristic algorithms included the disutility costs of commonality [lo], [U]. One type of heuristic solution strategy, clustering methods, has considerable intuitive appeal for commonality analyses [7], [ 191, [20]. The following sections will discuss the operational systems impacts of commonality in a framework that will allow inclusion in the clustering methods used for commonality analysis.

111. QUANTIFICATION OF EXCFSS FUNCTIONALITY Let set h- = { 1 ,2 , . . . , M } denote the M types of components

k in a commonality analysis. For all k E K, let I k define the set

0018-9472/92$03.00 0 1992 IEEE

111 I

IEEE TRANSACTIONS ON SYSTEMS, MAN, AND CYBERNETICS, VOL. 22, NO. 3, MAYNUNE 1992

of individual components i to be replaced by common component k. Each individual component i may be characterized by a m- dimensional attribute vector 2,; each attribute x ~ , ~ is a nonnegative real number that either 1) represents a function required by at least one component or 2) quantifies a design parameter of a component. For design parameters, the attribute typically quantifies the “design driving” specifications (maximum power, minimum noise emission, etc.) since each component must satisfy certain physical constraints.

For each component k E A’, let the m-dimensional attribute vector pk define the span of functions and design parameters. Let an m- dimensional operations vector /3 define the operations by which each element p k , J of p k is determined from zz for all i E I k such that

pk = ( ’ ~ ‘ ( ( z u p z u ) p ~ ” ’ ‘ ’ p Z y ) , ~ ~ ~ ~ w , ~ E I k . (1)

Let each operation /3, E /? be defined such that the following conditions hold:

1. Identity-zupzu = zuifz , = zu for all u,v E I(. 2. Commutativity-z,pz, = z,pzu for all u ,v E I i . 3. Associativity-z,~(z,pz,) = (z,pz,)pz, for all U , u , w E

I i . These conditions ensure that 1) a component is a direct substitute for an identical component and 2) the definition of common component attributes pk is independent of the order in which the constituent components z2, i E I k , are considered. Functions typically employed for /3, include maximum, minimum, arithmetic average, or a logical OR.

In general the attributes of the common component defined by p k differ from the attributes of the unique components z,, i E I k , which it replaces. The excess functionality U k , which results from common component k may then be quantified as the sum of the differences between p k and each z,, i E I k :

where C, is a normalizing constant for the various attributes and QN, is the number of units of component i required in the design. Note that an absolute difference is used to quantify excess functionality since the design driving specifications quantified as the p k , 3 can range from minimums to m a x h ” of the ~ , , ~ , i E 4; the amount by which a common component k emits less noise than is required for a unique component i, i E Ik, is also considered excess functionality. The system excess functionality S is then the sum of the excess functionality u k for each component:

k € K

for all components k E A’ in a system.

(3)

Iv. THE RELATIONSHIP OF COMMONALITY AND EXCESS FUNCTIONALITY

Consider now the changes in excess functionality that occur when two components are made common. For two components U , U E I{, it can be shown that

uuu 2 U” + u u (4)

for a common component used instead of components U and U. P r m t Consider two components a and b. Let these components

be described by attribute vectors za and X b respectively. Let these two components be replaced by a common component ab, described by pa, where pob= xo /3 2 6 by (1). Define m-dimensional vectors p and q such that, employing property (1) for /3 operations:

P3 5 k b , 3 5 qJ

where

549

and

qJ = m a x { z a , 3 ? Z b , . ? )

for j = 1,2 , ’ . . , m. Thus, since each p a b , J is bounded by x ~ , ~ and X b , j , and since u a b is a linear function of absolute differences, then (Tab is invariant to all feasible values of pa,.

Now consider the case where a and b are two components described by pa and pb. The feasible regions for pa and pb are contained in the feasible region for pa,. If the feasible region for pa is equal to that for p b , then gab = ua + otherwise, Cab > U, + Ob. Q.E.D.

The weak form of inequality is required for the case when U and U are identical components such that p, = pu. If U and v are not identical components, then p, # pu and the strong inequality holds:

u u u > uu + ou for U , v E K. The strong inequality in (5) is valid in general since two or more identical components can be considered as one component k by adjusting the component quantity QNk. Hence, the discussion that follows will assume that arbitrary components U , v E I< are not identical.

to be the increase in excess functionality that results from making component U common with component v:

(5)

Define the quantity 6,

u u v = U , + uv + 6, v (6)

for U , U E I< where 6, > 0 by (5). Let 6, be partitioned as

where 6,1,u and 6,lUu denote the excess functionality incurred due to the usage of component uv instead of component U and component v, respectively, within the system.

Now consider a third component w E K; without loss of general- ity, let 6, < 6, < 6, W . If component w is made common with component uv, component uvw results and

u u u w = UUU + o w + 6uu.w

where

6uv1uuw 2 6 U l U W , 6ulvw. (8)

from (6) and (7). Now let it be assumed that when two components u ,u E A’ are made common, the component uu differs at least as much from a third component w E K as do the individual components U and v. Thus:

6uv1uuw 2 6 U [ U W , 6uIuw. (9)

This assumption is generally valid in practice. Likewise, make a similar assumption for component w :

6 w l u v w L 6wluw,bw1uw. (10)

Then, from assumptions (9) and (lo), (8) can be expressed as

or

6uv:w 2 6u:w

and, since 6u:w > bur,, then

6uu:, > 6u:u

IEEE TRANSACTIONS ON SYSTEMS, MAN, AND CYBERNETICS, VOL. 22, NO. 3, MAY/JUNE 1992

N

Fig. 2. Relationship of commonality and excess functionality for electrical motors.

fewer than 13 types of motors. A least squares exponential curve of the form

s = 36,315. exp (-0.424N)

provides a reasonable fit to the data depicted in Fig. 2, with the regression generating a coefficient of determination of 98.4%. This result agrees with the discussion of Section IV. Similar exponential relations between commonality and excess functionality have been observed in commonality analyses of water tanks, berthing interfaces, equipment rack interfaces, and a detailed analysis of electrical motors [181.

VI. CONCLUSION The foregoing discussion represents an attempt to apply some of the

previously obtained results in commonality to operational systems. It was shown that the application of commonality to a system has adverse impacts on design efficiency; this reduced design efficiency can take the form of increased component weight, volume, and power consumption. Further, these impacts become progressively more severe as commonality is increased. In highly resource constrained systems such as spacecraft, any degradation of efficiency may be unacceptable. Therefore, when considering commonality as a system design strategy, the disutility of commonality must be included when quantifying the benefits anticipated from its application.

ACKNOWLEDGMENT The author wishes to thank Dr. Robert A . Brown for his motivation

to pursue this research.

551

REFERENCES

[l] K. R. Baker, M. J. Magazine, and H. L. W. Nuttle, “The effect of commonality on safety stock in a simple inventory model,” Management Sci., vol. 32, no. 8, pp. 982-988, 1986.

[2] J. E. Beige1 and B. Bulcha, “System modularization under constraints,” in Proc. AIIE 1976 Sys. Eng. Conf, Boston, pp. 158-162, 1976.

[3] B. S. Blanchard and W. J. Fabrycky, Systems Engineering anddnalysis. Englewood Cliffs, NJ: Prentice-Hall, 1981, p. 494.

[4] A. Charnes and M. Kirby, “Modular design, generalized inverses, and convex programming,” Operations Res., vol. 13, no. 5, pp. 836-847, 1965.

[5] D. A. Collier, “Justifying component part standardization,” in Proc. 12th Nut. AIDS Cont, Las Vegas, NV, 1980, p. 405.

[6] -, “The measurement and operating benefits of commonality,” Decision Science, vol. 12, no. 1, pp. 85-96, 1981.

[7] A. Dogramaci, “Design of common components considering implica- tions of inventory costs and forecasting,” AIIE Trans., vol. 11, no. 2, pp. 129-135, 1979.

[8] D. H. Evans, “Modular design-A special case in nonlinear program- ming,” Operations Res., vol. 11, no. 4, pp. 637-647, 1963.

[9] Y. Gerchak, M. J. Magazine, and A. B. Gamble, “Component common- ality with service level requirements,” Management Sci., vol. 34, no. 6, pp. 753-760, 1988.

[lo] J. Goldberg and J. Zhu, “Module design with substitute parts and multiple vendors,” Eur. J. Operational Res., vol. 41, pp. 335-346, 1989.

[ 111 W. M. Hirsch, M. Meisner, and C. Boll, “Cannibalization in multicom- ponent systems and the theory of reliability,” Naval Res. Log. Quart., vol. 15, no. 3, pp. 331-359, 1968.

[12] G. D. Hopson, L. D. Thomas, and C. C. Daniel, “The principle of commonality and its application to the space station freedom program,” IAF-89-081, a paper presented at the 40th IAF Inter. Astro. Congress, Malaga, Spain, Oct. 7-13, 1989.

[I31 U. Passy, “Modular design: An application of structured geometric programming,” Operations Res., vol. 18, no. 3, pp. 441453, 1970.

[14] L. E. Powell and E. E. Beam, “Commonality analysis for the NASA space station common module,” IAF-85-22, presented at the 36th IAF Inter. Astro. Congress, Stockholm, Oct. 7-12, 1985.

[ 151 D. P. Rutenberg, “Design commonality to reduce multi-item inventory: Optimal depth of a product line,” Operations Res., vol. 19, no. 2, pp.

[16] D. P. Rutenberg and T. L. Shaftel, “Product design: Subassemblies for multiple markets,” ManagementSci., vol. 18, no. 4, pt. 1, pp. B220-231, 1971.

[17] T. L. Shaftel, “An integer approach to modular design,” Operations Res., vol. 19, no. 1, pp. 130-134, 1971.

1181 L. D. Thomas, “A methodology for commonality analysis, with ap- plications to selected space station systems,” NASA Tech. Memo. no. TM-100364, Marshall Space Flight Center, May 1989.

[19] L. D. Thomas, “Commonality analysis using clustering methods,” to appear in Operations Res.

1201 J. C. Wei and G. M. Kern, “Commonality analysis: A linear cell clustering algorithm for group technology,” Int. J. Prod. Res., vol. 27, no. 12, pp. 2053-2062, 1989.

[21] U. Wemmerlov, “Assemble-to-order manufacturing: Implications for materials planning,” J. Operations Management, vol. 4, no. 4, pp.

491-509, 1971.

347-368, 1984.