Mechatronics, IEEE/ASME Transactions on - IEEE Xplore

IEEE/ASME TRANSACTIONS ON MECHATRONICS, VOL. 4, NO. 2, JUNE 1999

119

Synthesis of Modular Mechatronic Products: A Testability Perspective Chun-Che Huang, Member, IEEE, and Andrew Kusiak, Member, IEEE

Abstract—Producing modular products that combine modules with the consideration of product performance, e.g., testability of electronic systems, is frequently stated as a design goal. However, most of mechatronic frameworks (models) discussed in the literature do not consider testability of electronic subsystems of mechatronic products. This paper assumes that the product modules have been established, and aims at the development of modular mechatronic products with the consideration of testability of electronic subsystems as a performance criterion. The generation of modular products and module testability issues are discussed. Testability points, testability values, and access paths for a module/system are crucial to the generation of modular mechatronic products. A generalized label-correcting algorithm is developed to determine the points of focus, testability values, and access paths in modules. This paper contributes to the development of modular mechatronic products with the consideration of testability of electronic subsystems. Index Terms—Label-correcting algorithm, mechatronics, modularity, product synthesis, testability.

I. INTRODUCTION

F

LEXIBILITY is the key issue in the design of mechatronic products. It can be accomplished by creating plug-andplay compatible modules [1]. Modules involve components, the functional, spatial, and other interface characteristics of which fall within the range of variations allowed by the standard interfaces. By mixing and matching modules, a large number of products with distinctive functionalities, features, and/or performance levels can be generated [2]–[4]. Potential benefits of modularity include economy of scale, increased feasibility of product/component change, increased product variety, reduced order lead-time decoupling tasks, and ease of product upgrade, maintenance, repair, and disposal [5]–[7]. Modularity reduces the cost of assembly. The assembly process often impacts more than 50% of the total manufacturing cost, and 40%–60% of the total test time [8]. The generation of modular products by combining modules with the consideration of product performance, e.g., testability, is frequently stated as the goal of good design practice [9]. Manuscript received March 11, 1997; revised September 3, 1997, August 6, 1998, and December 8, 1998. Recommended by Technical Editor T. Inoue. This work was supported in part by the National Science Council of Taiwan under Grant NSC87-2218-E-260-004. C.-C. Huang is with the Intelligent Systems and Information Management Laboratory, Department of Industrial Management, National Chi-Nan University, Puli, 545 Taiwan, R.O.C. A. Kusiak is with the Intelligent Systems Laboratory, Department of Industrial Engineering, University of Iowa, Iowa City, IA 52242-1527 USA. Publisher Item Identifier S 1083-4435(99)04811-5.

However, modularity has not received sufficient attention in the literature [6], [10], [11]. The testability of each product module effects its performance. The insufficient access to individual electronic modules may decrease the testability of the overall system [12]. The design and implementation of a modular system is simplified as the complete system’s behavior depends on the combined complexity of its modules. For example, assume that a module is represented as a state machine, thus expressing its behavior in terms of states, transitions, and conditions. In general, if a states, there are at least different transitions, module has each requiring at least one test. For a system with modules, Clearly, the testability of modular the number of states is systems would improve considerably if the electronic modules were tested separately. Hence, modular hardware–software designs should incorporate access paths for testing. Most frameworks (models) for mechatronics discussed in the literature do not consider the testability of electronic subsystems. However, mechatronic products incorporate electronics [13]. In this paper, it is assumed that the product modules have been defined. The development of modular mechatronic products with the consideration of electronic testability is presented. Section II discusses the issues involved in the testability of electronic modules. A generalized label-correcting (LC) algorithm is developed to determine the testability values, points of focus, and access paths for a module. Section III discusses the generation of modular products. Based on the testability concept of Section II and the design model of Section III, in Section IV a modulebased design approach with the consideration of testability of electronic subsystems is developed and illustrated with an example. Section V concludes the paper. II. TESTABILITY

OF

ELECTRONIC MODULES

Designers of complex integrated circuits incorporate testability features into these circuits for ease of testing. In Section II-A, two types of testability measures are discussed. The testability at a system level is discussed in Section II-B. In Section II-C, based on the testability measures at a system level, a generalized LC algorithm is developed to determine the points of focus and access paths in a module. A. Testability Measures Testability is quite difficult to define. In technical terms, it incorporates controllability and observability. Controllability is a measure of the ease or difficulty of getting a circuit into

1083–4435/99$10.00  1999 IEEE

120

Fig. 1. AND–NOR invert circuit.

a known state. Observability is a measure of the ability to determine the logic values present in a circuit. A generally accepted set of measures for controllability and observability at each node of a circuit consists of six values divided into two classes [14]. The two classes are combinational and sequential values. The combinational values correspond to the outputs that are dependent only upon the current inputs, and the sequential values correspond to the outputs that depend not only upon the current inputs, but also upon the past history of those inputs. Here, the following notation is used: combinational controllability value, and the node stuck at 0; combinational controllability value, and the node stuck at 1; sequential controllability value, and the node stuck at 0; sequential controllability value, and the node stuck at 1; combinational observability value; sequential observability value. Examples of controllability/observability equations are presented next [14]. and For a three-input AND gate with inputs and output

where refers to the current combinational controli.e., the input signal of 0 or 1, and lability value of input the same as and In most cases, is greater than but not in the case of and The cost functions, e.g., for and for are used to measure the “difficulty” of setting a line to a value corresponding to the controllability, or of propagating an error from a line to an obserable point to the observability, respectively. The type of circuits impacts the cost function. For example, consider the AND–NOR-invert circuit in Fig. 1. The combinational observability for input 1 is


Fig. 2. Node observability.

At time assume the signals of inputs 1, 2, 3, and 4 to be 1, 0, 1, and 0. The output of gate is 1. The observability of input 1 is The sequential observability for node in Fig. 2 is computed using a similar equation

The values of controllability/observability for the gates are computed in such a way that the higher numbers are assigned to the gates that are more difficult to control/observe. Basic testability equations are available in the literature on testing of electronic circuits, e.g., [14] or [15]. The module testability value, discussed later in this paper, is used to select modules. In general, a module with lower testability value is more desirable for inclusion in a product. B. System-Level Testability A mechatronic system integrates mechanics, electronics, and information technology [12]. To reduce the test complexity at the system level, the following two strategies are followed. 1) System Partitioning—Modular design naturally supports this strategy. 2) Adding Test Functionality—This allows controlling and observing individual modules and the interactions among them for testing purposes. In this paper, test functionality of electronic and information modules of mechatronic systems is discussed. 1) Partitioning: Partitioning implies that a system should be decomposed into independent modules with the minimal interaction and communication between the modules. During testing, modules can be easily isolated from their environment. The number of possible states increases exponentially if the modules include interacting, parallel, and finite-state machines. This dramatically increases the number of test scenarios required. 2) Adding Test Functionality: To test individual modules and their interactions, a test stimulus is provided to the modules and the response at their boundaries is observed. Controlling the module boundaries and observing them directly in the system environment is required. In general, however, this is not possible. Hence, paths are required via other modules to offer test stimuli and observe the responses of a module under in Fig. 3 neither can be testing. The boundary of module controlled, nor can be observed. Thus, testing requires paths through other modules. This limited control and observation capability seriously reduce testability for several reasons.

HUANG AND KUSIAK: SYNTHESIS OF MODULAR MECHATRONIC PRODUCTS

Fig. 3. Interaction network of modules.

1) Test paths must be set up and maintained to and from the module. This may be infeasible or at least may require a significant effort. 2) The location of errors occurring in the module under test or in the path is unknown. 3) In real-time systems, the order and timing of events is critical. Thus, during testing, the timing of incoming events may be controlled, and the timing of outgoing events may be observed. This is difficult to achieve without direct access to the module under test. To improve testability, the test functionality is considered and the system specifications with three types of test functions are used [16]. a) Transparent test mode (TTM): The accessibility problem can be eliminated if the modules that constitute a path to the module under test are transparent, i.e., they convey signals without any change. The module’s behavior is extended with an additional transparent-test operation mode. Whenever a module becomes a TTM, it passes incoming events directly to the outgoing events in a predefined way, providing a transparent path from the module inputs to its outputs. This approach, however, often applies for testing one module only, which hardly fits with a generic testability approach. Nonetheless, the TTM concept can be useful. b) Built-in self-test (BIST): A module can be equipped with a self-test, which reduces the overall cost of testing. The module’s BIST functionality offers test stimuli to the module and observes and evaluates the responses. Start and control of the BIST in the module is performed from the system environment. When the test ends, it returns a go/no-go response to the system environment. c) Point of control and observation (PCO): Inserting points at the module boundaries allows one to control and observe interconnections between modules. A PCO inserted in an interconnection between two modules has three operation modes: transparent, observation, and test. A complete PCO implementation supports all three modes. However, it is also possible to implement only two of them. In an observation mode, the PCO is used to monitor the content of a data store. In the test mode, the PCO can be used to read and write a data store. A PCO in a system is controlled individually via its input. A common mode can control multiple PCO’s.

121

TTM and PCO functionality offer paths between the system environment and the modules embedded. In addition to the test information, these paths can also transport system management information, such as programming updates and data. In summary, the following paths are crucial in testing [16], [17]: • critical path tracing; • shortest path to tracing or minimal signal loss path; • maximum reliability path; • minimum reliability path; • least reliable component; • minimum controllability path; • minimum observability path; • transparent path with signal 0; • transparent path with signal 1; • access path to the PCO. The computation of these paths and their values involves addition, subtraction, multiplication, and comparative operations. By combining various operators ( , , and ) and comparators ( and ), problems of different types can be formulated and solved. For example, the operator “ ” is used for problems involving cost or time, and “ ” for problems involving reliability. The comparator “ ” is used for the minimization problem and “ ” for the maximization problem. Next, a generalized LC algorithm is developed to determine points, paths, and testability values.

C. The Generalized LC Algorithm A network can represent the structure of a circuit, which is useful, as many concepts and algorithms of the graph theory can be applied [17]. In this paper, a network with logic connectors (e.g., AND, XOR, and OR) is used to represent circuits. The main idea behind the generalized LC algorithm is based on the LC algorithm (also called Dijkstra’s algorithm) that determines the shortest flow path [18], [19]. The distance between any two nodes and in a network satisfies the for all following optimality condition: set of edges where is the distance between is the distance between node and the source node, and is the weight on edge node and the source node, and At each stage, the algorithm maintains a set of distance The label is either , indicating that a directed labels path from source to node has not been determined, or it is the length of a directed path from the source to node All nodes in the path are tracked by a predecessor index pred The types of problems that can be solved with the generalized LC algorithm are listed in Table I. For example, the and provides all access paths to solution of problems and —the shortest and critical the module; problems and —the reliaaccess path to the module; problems —the least reliable bility of the underlying paths; problem and —the testability of a module. module; and problems aims at the application of Finding a transparent path the TTM. Hence, the generalized LC algorithm is more useful than the algorithms of Keiner and West [20], and Goldstein

122


PROBLEM TYPES

AND THE

TABLE I CORRESPONDING OPERATORS, COMPARATORS,

AND

OBJECTIVES

D : node initial value 2: group operator for the set of paths connected with And connectors [Op]: an arithmetic operator type [Cp]: comparison operator (comparator) CC 0: combinational controllability value and the node stuck at 0 CC 1: combinational controllability value and the node stuck at 1 SC 0: sequential controllability value and the node stuck at 0 SC 1: sequential controllability value and the node stuck at 1 CO: combinational observability value SO: sequential observability value I : primary input Y : primary output N : internal node int

and Thigpen [14] applicable to the controllability/observability problem only. The following notation is used in the generalized LC algorithm: module network with nodes and connectors; Act-node node of a module network that is not a logical connector; AND, OR, XOR logic gates, respec&, tively; Output No output number or output name; Input No input number or output name; _Node(Output No) final node (output number); distance between the source node and node ; value or symbol of node itself, e.g., cost; node preceding node ; Pred list of activity nodes succeeding actSucc node ;

First (Succ( ))

first activity node in the list of Succ( ) Stack set of nodes or logical connectors stored according to the first-in-lastout (FILO) rule; input node of the generalized LC algorithm; initial value of And stack ; Group set of paths in the And stack ; Input to the algorithm: The network. Output of the algorithm: Varies depending on the type of the objective function (see the last column of Table I). The generalized LC algorithm uses the concept of the optimal condition of the LC algorithm applicable to traditional networks. One of the main differences between the traditional networks and logic networks is that the latter have more types of logical connectors, e.g., “OR,” “AND,” “XOR,” or “act-node” type, and the former with “OR” type only. The algorithm performs a backward search, from a selected output point to all accessible points. It processes the stack of nodes or logical


Fig. 4. The flow chart of the generalized LC algorithm.

connectors based on the LIFO rule. At each iteration, a node in the stack is Pulled out to explore and its precedent node(s) is (are) Pushed into the stack. • For the nonlogical nodes, the algorithm executes steps 2 and 3 to attain optimality. • For the OR gate, steps 2 and 4 of the LC algorithm are applied to create branches and store new precedent node(s) in the stack. • For the AND gate, steps 5–7 create an AND stack (a recursive subroutine). The LC algorithm recurs at each AND stack. The algorithm terminates when all nodes in the stack are pulled, i.e., the stack is empty. The running time of the which is generalized label correcting algorithm is same as Dijkstra’s algorithm, where is the number of nodes is the number of edges. The logic of the generalized and LC algorithm is illustrated in Fig. 4. The generalized LC algorithm is as follows:

123

Step 1.Remove element from the stack with more than one branch input If Go to step 5 Else Go to step 2 Endif Repeat step 1 until Stack END succ( ) , Length( ) , where is Path the destination node Step 2.For each such that edge If Succ( ) “A ” prec( ), , Loop Else act-node, go to step 3 If or or &, go to step 4 is found Repeat step 2 until no more edges Go to Step 1 (First(Succ( ))) Step 3.If (first(Succ( ))) Succ( Succ( ) Stack Go to step 2 Else Go to step 2 Endif Succ( ) Step 4.Succ( ) Stack Go to step 2 stack Step 5.Create an Go to step 6 edge Step 6.For each If in Succ( ) “A ” prec Loop Else For all final nodes with &, do:

(First(Succ( ))) Stack Go to step 1; repeat the algorithm Add the sub-optimal paths of – to Group each Enddo Endif Go to step 7 Step 7. If for all Group , where is the optimal value of path Succ Succ( ), where Group

Step 0. Set: Node (Output No.) for each act node Stack Succ

connecting

Endif Output No. Go to step 2

124


point/path boundary based on IEEE standards, e.g., Standard 1149 [21]. Example 2: Consider the ANS 310 module [22]. Find the minimum signal loss path to output 2 in the module network of Fig. 7 ( -type problem in Table I), where corresponds to OR gate 1, to XOR gate 1, and &1 to AND gate 1, respectively, and so on. The node in this module network is either a function gate or logic gate. Assume that each label number denotes the signal lost in a module, where to 10. The Result: For any node the shortest path to Output 2 For instance, the minimum is Succ( ), of the length Succ(0) 0, signal loss path from Input 1 to Output 2 (the steps of the 1, 2, 7, output 2 , the length algorithm are presented in Appendix B). In the next section, a design model combining modules that meet various functional requirements is presented.

Fig. 5. Circuit from [15].

III. DESIGN Fig. 6. The module network of the circuit in Fig. 5. TABLE II CONTROLLABILITY VALUES

OF

MODULAR PRODUCTS

A. The Model as an artifact that includes Define a model of product functionality of all modules and their relations (e.g., input/output interfaces). (1) where

TABLE III OBSERVABILITY VALUES

Example 1: Consider the circuit in Fig. 5 [15]. The module network of the circuit in Fig. 5 is presented in Fig. 6. In this paper, a module network is the network with logic connectors representing the structure of a circuit. Compute the controllability and observability equations presented in Section II-A. The controllability and observability values of each node are presented in Tables II and III, represents the node number (between respectively, where 6 and 10). The Result: Applying the generalized LC algorithm, the minimum controllability and observability paths to the output are 6, 10 or 8, 10 . The steps of the algorithm are presented in Appendix A. With the testability points/paths determined (see Table I), the corresponding test functionality points are placed at the

; product model; functional requirement of product model ; module from module database ; mapping from functional requirement space onto i.e., the function of selecting canmodule space didate modules; index set of functional requirements for the product model . The general framework of synthesis with modules is illustrated in Fig. 8. and are selected Initially, two candidate modules fulfilling the functional requirefrom module database ments, a clock requirement and a control and decode requirement. Let the current index set of functional requirements for The two requirements included the product model and By matching the two in the set are denoted as and , i.e., the output of matched to the modules a higher level model is created input of

The new model is stored in the model base and used for synthesis at the next step. Adding and mapping operations are used in the synthesis process. B. Adding Operation The adding operation refers to the combination of modules. In the combination process, the feasibility of including candi-


125

Fig. 7. Module network.

Fig. 8. The framework of design synthesis.

date modules is checked based on engineering and interface constraints. Testability constraints examined in this paper belong to the set of engineering constraints [23]. Testability is the ability to generate, evaluate, and apply tests to satisfy a number of predefined objectives, e.g., fault coverage, fault isolation, runtime, and time to profit, subject to the two fundamental constraints of time and money [24]. All test-related decisions

should be made as early as possible in the design process. The consideration of all relevant test requirements must be an integral part of system design—not an afterthought. Achieving the desired test quality at minimum cost requires one to consider test engineering at all development stages: planning, design, validation, test pattern and program generation, and testing on automatic test equipment. For the testability constraints, one can refer to [25] and [26] and IEEE standards, e.g., Standard

126


(a)

(b)

(c)

Fig. 9. Digital feedback loops. (a) Removable jumper (acceptable). (b) External jumper (better). (c) External control (best).

1941. The following is an example of testability constraints at the board level: • In a logic feedback system, it is impossible to definitively isolate a fault with the loop closed. The larger the loop, the more difficult it is to troubleshoot. Various techniques can be employed to break up feedback loops, and some of these are illustrated in Fig. 9. Interface constraints refer to the input/output interface requirements to match two modules, e.g., the layout of pins to plug in a port. In general, the module interfaces can be classified as follows [6], [27], [28]. 1) Attachment (surface) interface: How one module may be physically connected to other interfaces. Type: Represents exclusive attachment type, e.g., plug in, stick, etc. Shape: 11 types of form features can be used, e.g., a pin. Position: Position of attachment, e.g., top, middle, bottom. Size: Size of attachment area, e.g., 12.5 cm . Number: Number of attachments, e.g., 30-pin RAM. 2) Power transfer interface: The power is to be transferred between modules, e.g., 110 V. 3) Control and communication interface: Type of signals to : Digital, : be exchanged between modules, e.g., Analog. 4) Environmental interface: Various ways in which the functioning of one module may generate heat, magnetic fields, or other environmental disturbances that can be accommodated by other modules, e.g., heat dissipation 10 W/cm . If the interface constraint is not satisfied, an adaptive module is considered for placement between the two basic modules. The basic module refers to the module implementing the basic functions, which are not variable in principle and are fundamental to a product. The adaptive module is a module in which the adaptive functions are implemented. The adaptive modules handle unpredictable constraints [29].

Fig. 10. Mapping between

RP and M .

In this paper, the mapping model generates a desired product with minimum testability value subject to the budget constraints. Also, this paper assumes that the interface constraints are relaxed by the application of adaptive modules. Notation is as follows: testability value of module generated by the generalized LC algorithm; cost of module ; budget; 1 if module is mapped onto functional requirement , 0 otherwise; index set of functional requirements for product model ; index set of modules in the space . The following model minimizes the largest testability value of the modules selected subject to three constraints: (2) subject to for

(3) for all

(4) (5)

Constraint (3) limits the total cost of modules. Constraint (4) ensures that each functional subrequirement is satisfied. Constraint (5) ensures the integrality of variable The model presented next minimizes the total testability value of the modules selected (6)

C. Mapping Operation allows selecting a module from the Mapping function to satisfy functional requirements from the module set (see Fig. 10). space in The selection process is based on general constraints and the testability values of modules. The general constraints refer to the overall requirements of a product, e.g., the total cost should not exceed the budget or the total signal loss should not exceed the value recommended by the IEEE standards.

subject to

(3)–(5)

The two mapping models presented are known as the bipartite weight matching problems [30]. Based on the testability concept of Section II and the design model of Section III, a module-based design approach with the consideration of testability of electronic subsystems is developed next.


Fig. 11.

127

The module-based synthesis.

A. Module-Based Design Synthesis In this section, a procedure for the module-based product synthesis is presented with the consideration of system’s level testability.

Fig. 12.

Module logic chain.

IV. DESIGN OF PRODUCTS WITH THE SYSTEM-LEVEL TESTABILITY CONSIDERED Given a set of modules in the space and a a set of set of functional requirements in the space is to be generated and evaluated. feasible module solutions The modules with desired testability values are synthesized. The system-level testability is improved by incorporating test functionality in the necessary test paths and the interaction points between the modules. For the purpose of the algorithm discussed next, define an interaction network as the network that connects the modules determined and represents the structure of a product.

1) Apply the generalized LC algorithm to the module network of the circuit to determine the testability value, points, and paths. Given the points/paths, the boardlevel testability points that perform the desired test functionality are determined based on the test guidelines. 2) Select modules to construct an interaction network by solving the mapping model (I) or (II). 3) Apply the generalized LC algorithm to determine the testability points and paths among the modules. Given the points/paths, the system-level testability points that perform the desired test functionality are generated based on the test guidelines. In this procedure, Steps 1–4 correspond to Stage 1, Steps 5–7 to Stage 2, and Steps 8–10 to Stage 3. 1) Define the functional requirement space 2) Initialize the module space to include all module candidates based on 3) Apply the generalized LC algorithm to the module network of the circuit to determine the testability value, points, and paths in the logic network. 4) Incorporate the testability points at the board level.

128

Fig. 13.


The interaction network of the module logic chain in Fig. 12.

5) Solve the mapping model to obtain modules that satisfy the functional subrequirements. 6) Verify the interface constraints. If violated and an adaptive module is available in the module space, then insert the adaptive module; otherwise remove one of the incompatible modules and repeat Step 5). 7) Construct an interaction network for the design product. 8) Use the generalized LC algorithm to determine the testability points/access paths. 9) Verify the testability constraints. If violated, add testability points at the system level. 10) Output the final prototype. The synthesis procedure is illustrated in Fig. 11. The functional requirements are placed in the functional requirement database. Initially, the modules available are stored in the module database. To satisfy all functional subrequirements, the mapping model is developed and the mapping operation is applied. The product model includes modules with the desired testability values. The generalized LC algorithm is applied to find the points/paths within and among modules in order to insert the testability points at the board and system level based on the testability guidelines. Finally, the prototype is generated when the overall testability and interface constraints are satisfied.

B. Illustrative Example Example 3—Design for Testability Benchmark: Consider a computer numerical controller (CNC) that includes computation, actuation, instrumentation, and a target system [31]. Modular circuit boards are used to implement the computation and instrumentation functions. The logic chain presented in Fig. 12 includes 12 modules, the modular circuit boards, mechanical modules, and information processing modules. The modular circuit boards contain VLSI IC’s and some ASIC’s, along with a regular sequential logic that contains feedback loops [25]. In Steps 1–5, the modules and satisfying

Fig. 14. The circuit with

CP ’s and OP ’s added.

the functional requirements are selected. For example, module (in Example 2) is selected because of the desired low controllability/observability value. The adaptive module connects modules and as the interface constraints and are violated (Step 6). Another adaptive of connects and module The circuit in Fig. 12 with sequential logic contains feedback loops which can be initialized. The small circles in Fig. 12 denote connectors. The interaction network of the circuit in Fig. 12 is presented in Fig. 13. is suggested by the testability guideline concerned This allows initialwith the buried memory element izing it without a “homing sequence.” Using the generalized is deLC algorithm, the path is added. termined to be critical and an observable point ’s and ’s may be identified in the points of focus Other and paths in the interaction network based on the guidelines for the feedback loop. The is inserted (Step 9), e.g., in the minimum reliability paths The system is partitioned into two test subsystems. is an observable point for Subsystem 1. Partitioning and adding ’s and ’s for testability leads to the circuit in more Fig. 14.


V. CONCLUSION In this paper, testability of electronic modules in mechatronic systems was discussed. A generalized LC algorithm to determine testability values, points, and access paths for modules was developed. The algorithm solves a large class of problems presented in Section II for different values of the initial node. A module-based design approach with testability consideration was presented and illustrated with an example of a six-logic chain. This paper contributes in the development of modular mechatronic products with the consideration of performance criteria, e.g., testability of electronic subsystems. The generalized LC algorithm is useful in determining testability values, points, and paths. The following issues require further studies. 1) The design model and synthesis algorithms developed in this paper are generic. They need to be applied to specific products and systems. 2) The generalized LC algorithm determines the desired paths. It should be incorporated in an expert system supporting a range of testability issues. 3) The tradeoff analysis of the design guidelines for testability should be developed. 4) Design for testability of mechanical modules should be researched. APPENDIX A EXAMPLE 1: STEPS OF THE ALGORITHM Find the minimum controllability path. The controllability values of each node are presented in Table II. Step 0. Step 1. Step 2. Step 3. Step Step Step Step

2. 1. 2. 3.

Step 2. Step 3.

Step 2. Step 3.

Step Step Step Step

2. 1. 2. 4.

Step 2. Step 1. Step 5.

for all , 10, OUT , Stack 10 , Succ( ) Remove 10, , Go to Step 2 , Go to Step 3 For 6 ,7, 8, Output 2 , Succ( ) Succ(6, 7, 8) , Go to Step 2 Stack No more edges, Go to Step 1 , Go to Step 2 Remove , Go to Step 3 For (First(Succ(10))) , Succ(6) 6, 10, Output 2 , , Go to Step 2 Stack , Go to Step 3 For (First(Succ(10))) , Succ(7) 7, 10, Output 2 , 6, 7 , Go to Step 2 Stack , Go to Step 3 For (First(Succ(10))) , Succ(8) 8, 10, Output 2 , 6, 7, 8 , Go to Step 2 Stack No more edges, Go to Step 1 , Go to Step 2 Remove 6, , Go to Step 4 For 1, 7, 8 , Succ( ) Succ(6), Stack Go to Step 2 No more edge( ), Go to Step 1 1, Go to Step 5 Remove 1, 1, Go to Step 6

129

Step 6.For , no more edge( ), Go to Step 1 Step 1.Stack empty, End, 1, 6, 10, OUT found Path , no more edge( ), Go to Step 1 For Step 1.Stack empty, End, 2, 6, 10, OUT found Path Step 1.Stack empty, End No more optimal path found, Go to Step 7 , Go to Step 2 Step 7. Step 2.No more edges, Go to Step 1 , Go to Step 2 Step 1.Remove 7, 2, Go to Step 4 Step 2.For 2, 8 , Step 4.Succ( 2) Succ(7), Stack Go to Step 2 Step 2.No more edge( ), Go to Step 1 2, Go to Step 5 Step 1.Remove 2, 2, Go to Step 6 Step 5. , no more edge( ), Go to Step 1 Step 6.For Step 1.Stack empty, End, 3, 7, 10, OUT found Path , Go to Step 3 For (First(Succ(7))) Step 3. , 9, 7, 10, OUT , Succ(9) , Go to Step 2 Stack Step 2.No more edges, Go to Step 1 , Go to Step 2 Step 1.Remove 9, , Go to Step 3 Step 2.For Step 3.Succ( ) Succ(9, 7, 10) 9 ,7, 10, OUT , Stack , Go to Step 2 Step 2.No more edges, Go to Step 1 , , Go to Step 2 Step 1.Remove , no more edge( ), For Go to Step 1 Step 1.Stack empty, End, 4, 9, 7, 10, OUT found Path Step 1.Stack empty, End No more optimal path found, Go to Step 7 , Go to Step 2 Step 7. , Go to Step 2 Step 1.Remove 8, 3, Go to Step 4 Step 2.For , Step 4.Succ( 3) Succ(8), Stack Go to Step 2 Step 2.No more edge( ), Go to Step 1 , , Go to Step 2 Step 1.Remove , Go to Step 6 Step 5. , Go to Step 3 Step 6.For Step 3.Succ( ) Succ(9, 8, 10) 9, 8, 10, OUT , Stack , Go to Step 2 Step 2.No more edges, Go to Step 1 , , Go to Step 2 Step 1.Remove , no more edge( ), For Go to Step 1 Step 1.Stack empty, End, 4, 9, 8, 10, OUT found Path

130


For , no more edge( ), Go to Step 1 Step 1. Stack empty, End, 5, 8, 10, OUT found Path Step 1. Stack empty, End No more optimal path found, Go to Step 7 , Go to Step 2 Step 7. Step 2.No more edges, Go to Step 1 Step 2. No more edges, Go to Step 1 Step 1. Stack empty END Results For the module, six paths are found. The minimal controllability path is 6, 10 . APPENDIX B EXAMPLE 2: STEPS OF THE ALGORITHM Find the minimum signal loss path. Assume that each label denotes the volume of signal lost in a module. for all Step 0. , Succ( ) 7, Output 2 , 7 , Stack Step 1. Remove 7, , Go to Step 2 , Go to Step 3 Step 2. For 7, Output 2 , Step 3. Succ( ) Succ(7) , Go to Step 2 Stack Step 2. No more edges, Go to Step 1 , , Go to Step 2 Step 1. Remove , Go to Step 4 Step 2. For 7, Output 2 , Step 4. Succ( ) Succ( ) , Go to Step 2 Stack , Go to Step 3 Step 2. For (First(Succ(7))) Step 3. , Succ(8) 8, 7, Output 2 , , Go to Step 2 Stack Step 2. No more edges, Go to Step 1 , Go to Step 2 Step 1. Remove 8 from Stack, , Go to Step 4 Step 2. For 7, Output 2 , Step 4. Succ( 1) Succ(8) , Go to Step 2 Stack Step 2. No more edges, Go to Step 1 , Go to Step 5 Step 1. Remove 1, , Go to Step 6 Step 5. , , Step 6. For , Succ( ) , Stack Go to Step 1, repeat the algorithm: , Go to Step 2 Step 1. , Go to Step 3 Step 2. , Step 3. , Stack , Go to Step 2 Step 2. No more edge( ), Go to Step 1 , Go to Step 2 Step 1. In put 1, no more edge( ), Step 2. Go to Step 1 Step 1. Stack empty, End, Path Input 1, 0, found , , Stack , For , Go to Step 1, repeat the algorithm , Go to Step 2 Step 1. Input 2, no more edge( ), Step 2. Go to Step 1 Step 1. Stack empty, End, Input 2, 9, &1 found Path and in the Group0, Go to Step 7 Put

Step 7.

Step Step Step Step

2. 1. 2. 4.

Step 2. Step 4. Step Step Step Step

2. 1. 2. 3.

, Succ 0, 8, 7 Succ(9) 0, 8, 7 , Go to Step 2 No more edges, Go to Step 1 , , Go to Step 2 Remove , Go to Step 4 For 7, Output 2 , Succ(&3) Succ , Go to Step 2 Stack , Go to Step 4 For 7, Output 2 , Succ( ) Succ , Go to Step 2 Stack No more edges, Go to Step 1 , , Go to Step 2 Remove , Go to Step 3 For (First(Succ( )))

Stack Step 2. For Step 3.

Step Step Step Step

2. 1. 2. 4.

Step Step Step Step

2. 1. 2. 3.

Step Step Step Step

2. 1. 2. 4.

Step Step Step Step

2. 1. 2. 3.

Step 2. Step 1. Step 2. Step 1. Step 2. Step 4. Step 2. Step 1. Step 2.

, Succ(3) 3, 7, Output 2 , , Go to Step 2 , Go to Step 3 (First(Succ( )))

, Succ(2) 2, 7, Output 2 , 2, 3, , Go to Step 2 Stack No more edges, Go to Step 1 , Go to Step 2 Remove 2, , Go to Step 4 For 2, 7, Output 2 , Succ( ) Succ(2) , Go to Step 2, Stack Go to Step 2 No more edges, Go to Step 1 , , Go to Step 2 Remove , Go to Step 3 For (First(Succ( ))) , Succ(1) 1, 2, 7, Output 2 , 1, 3, , Go to Step 2 Stack No more edges, Go to Step 1 , Go to Step 2 Remove 1, , Go to Step 4 For 1, 2, 7, Output 2 , Succ( ) Succ(1) , Go to step 2 Stack No more edges, Go to Step 1 , , Go to Step 2 Remove , Go to Step 3 For (First(Succ( ))) , Succ(0) 0, 1, 2, 7, Output 2 , 0, 3, , Go to Step 2 stack No more edges, Go to Step 1 , Go to Step 2 Remove 0, Input 1, No more edges, For Go to Step 1 Stack , Go to Step 2 Remove 3, , Go to Step 4 For 3, 7, Output 2 , Succ( ) Succ(3) , Go to Step 2 Stack No more edges, Go to Step 1 , , Go to Step 2 Remove , Go to Step 4 For


Step 4.Succ( ) Succ( ) 3, 7, Output 2 , , Go to Step 2 Stack Step 2.No more edges, Go to Step 1 , , Go to Step 2 Step 1.Remove , Go to Step 3 Step 2.For (First(Succ( ))) Step 3. , , Go to Step 2 Stack Step 2.No more edges, Go to Step 1 , Go to Step 5 Step 1.Remove &3, , Go to Step 6 Step 5. , , , Step 6.For , Succ(6) Stack 6, 7, Output 2 , Go to Step 1, repeat the algorithm , Go to Step 2 Step 1. , Go to Step 4 Step 2. , Step 4. Succ(&2) Succ(6), Stack Go to Step 2 Step 2. No more edge( ), Go to Step 1 , Go to Step 2 Step 1. , Go to Step 3 Step 2. , Step 3. , Succ(4) 4 Succ(&2), Stack , Go to Step 2 Step 2. No more edge ( ), Go to Step 1 , Go to Step 2 Step 1. , Go to Step 4 Step 2. , Step 4. Succ( ) Succ( ), Stack Go to Step 2 Step 2. No more edge( ), Go to Step 1 , Go to Step 2 Step 1. , Go to Step 3 Step 2. , Step 3. Go to Step 2 , Go to Step 4 Step 2. , Step 4. Succ( ) Succ( ), Stack Go to Step 2 Step 2. No more edge( ), Go to Step 1 , Go to Step 2 Step 1. in the Succ( ), a loop existed, Step 2. no more edge( ), Go to Step 1. Step 1. Stack = empty, End No optimal path found, Go to Step 7 , Go to Step 2 Step 7. Step 2.No more edges, Go to Step 1 , 2, Go to Step 2 Step 1.Remove , Got Step 4 Step 2.For Step 4.Succ( ) Succ( ) 1, 4, 6, 5, 7, Output 2 , , Go to Step 2 Stack , Go to Step 4 Step 2. Step 4.Succ( ) Succ( ) 1, 4, 6, 5, 7, Output 2 , , Go to Step 2 Stack Step 2.No more edges, Go to Step 1 , , Got Step 2 Step 1.Remove

131

Step 2.For , Go to Step 3 , Stack , Go to Step 2 Step 3. Step 2.No more edges, Go to Step 1 , , Go to Step 2 Step 1.Remove , Go to Step 3 Step 2.For , Stack , Go to Step 2 Step 3. Step 2.No more edges, Go to Step 1 Step 1.Stack empty END Results: For any node , the shortest path to Output 2 is . For instance, the shortest path Succ( ), of the length 0, 1, 2, 7, output 2 , from Input 1 to Output 2 Succ(0) the length REFERENCES [1] H. M. J. Van Brussel, “Mechatronics—A powerful concurrent engineering framework,” IEEE/ASME Trans. Mechatron., vol. 1, pp. 127–136, Mar. 1996. [2] R. N. Langlois and P. L. Robertson, “Networks and innovation in a modular system: Lessons from the microcomputer and stereo component industries,” Res. Policy, vol. 21, no. 4, pp. 297–313, 1992. [3] S. W. Sanderson and V. Uzumeri, “Strategies for new product development and renewal: Design-based incrementalism,” Center Sci. Technol. Policy, Rensselaer Polytechnic Inst., Troy, NY, 1990. [4] W. Ward, J. F. Liker, J. J. Cristiano, and D. K. Sobek, “The second Toyota paradox: Delaying decisions can make better cars faster,” Sloan Manage. Rev., vol. 36, no. 3, pp. 43–61, 1995. [5] J. L. Nevins and D. E. Whitney, Concurrent Design of Products and Processes: A Strategy for the Next Generation in Manufacturing. New York: McGraw-Hill, 1989. [6] G. Pahl and W. Beitz, Engineering Design. New York: SpringerVerlag, 1988. [7] J. Corbett, M. Dooner, J. Meleka, and C. Pym, Design for Manufacturing: Strategies, Principles, and Techniques. Reading, MA: AddisonWesley, 1991. [8] M. M. Andreason, S. Khler, and T. Lund, Design for Assembly. Bedford, U.K.: IFS Publications, 1983. [9] P. T. Kidd, Agile Manufacturing: Forging New Frontiers. New York: Addison-Wesley, 1994. [10] G. V. Shirley, “Models for managing the redesign and manufacture of product sets,” J. Manuf. Oper. Manage., vol. 3, no. 1, pp. 85–104, 1990. [11] K. Ulrich and K. Tung, “Fundamentals of product modularity,” in Issues in Design/Manufacture Integration 1991, A. Sharon, Ed. New York: ASME, 1991, pp. 73–79. [12] R. Isermann, “Modeling and design methodology for mechatronic systems,” IEEE/ASME Trans. Mechatron., vol. 1, pp. 16–28, Mar. 1996. [13] N. Kyura and H. Oho, “Mechatronics—An industrial perspective,” IEEE/ASME Trans. Mechatron., vol. 1, pp. 10–15, Mar. 1996. [14] L. H. Goldstein and E. L.Thigpen, “Scoap: Sandia controllability/observability analysis program,” in Proc. 17th Design Automation Conf., 1980, pp. 190–196. [15] A. Miczo, Digital Logic Testing and Simulation. New York: Harper & Row, 1990, p. 269. [16] H. P. E. Vranken, M. F. Witteman, and R. van Wuijtswinkel, “Design for testability in hardware-software systems,” IEEE Design & Test, vol. 12, pp. 79–81, Jan.–Mar. 1996. [17] M. Abramovici, M. A. Breuer, and A. D. Friedman, Digital Systems Testing and Testable Design. New York: IEEE Press, 1990, pp. 26-29. [18] E. W. Dijkstra, “A note on two problems in connection with graphs,” Num. Math., vol. 1, no. 4, pp. 269–654, 1959. [19] T. H. Cormen, C. E. Leiserson, and R. L. Rivest, Introduction to Algorithms. Cambridge, MA: MIT Press, 1996, pp. 514–539. [20] W. Keiner and R. West, “Testability measures,” in Proc. 1977 ATUOTESTCON, pp. 49–55. [21] K. Parker, The Boundary-Scan Handbook. Boston, MA: Kluwer, 1992. [22] Wu-Tain Company, Handbook of Circuit Design. Taipei, R.O.C.: WuTain, 1990, p. 109. [23] P. J. O’Grady, C. Kim, and Y. Kim, “Feature-based design of electronics assemblies,” Int. J. Testability Res., vol. 34, no. 5, pp. 1307–1330, 1996. [24] R. G. Bennetts, “Progress in design for test: A personal view,” IEEE Design & Test, vol. 11, pp. 53–59, Jan.–Mar. 1994. [25] J. Turino, Design to Test. New York: Van Nostrand Reinhold, 1990.

132


[26] R. C. Aitken, “An overview of test synthesis tools,” IEEE Design Test Comput., vol. 12, pp. 8–15, Jan.–Mar. 1995. [27] R. Sanchez, “Strategic product creation: Managing new interactions of technology, markets, and organizations,” Eur. Manage. J., vol. 14, no. 2, pp. 121–138, 1996. [28] D. D. Gajski and F. Vahid, “Specification and design of embedded hardware-software systems,” IEEE Design Test Comput., vol. 12, pp. 53–67, Jan.–Mar. 1995. [29] A. Kusiak and C. C. Huang, “Development of modular products,” IEEE Trans. Comp., Packag., Manufact. Technol. A, vol. 19, pp. 523–538, Dec. 1996. [30] C. H. Papadimitriou and K. Steiglitz, Combinatorial Optimization: Algorithms and Complexity. Englewood Cliffs, NJ: Prentice-Hall, 1982, pp. 247–270. [31] D. M. Auslander, “What is mechatronics?” IEEE/ASME Trans. Mechatron., vol. 1, pp. 5–9, Mar. 1996.

Andrew Kusiak (M’90) received the M.S. degree in mechanical engineering from Warsaw Technical University, Warsaw, Poland, in 1974 and the Ph.D. degree in operations research from the Polish Academy of Sciences, Warsaw, Poland, in 1979. He is currently a Professor in the Department of Industrial Engineering, University of Iowa, Iowa City. He is interested in product development, manufacturing, healthcare informatics and technology, and applications of artificial intelligence and optimization. He is the author of numerous research papers published in technical journals. He speaks frequently at international meetings, conducts professional seminars, and consults for industrial corporations. He serves on the editorial boards of 16 journals, edits a book series, and is the Editor-in-Chief of the Journal of Intelligent Manufacturing.

Chun-Che Huang (M’97) received the M.S. degree in operations research from Columbia University, New York, NY, in 1994 and the Ph.D. degree in industrial engineering from the University of Iowa, Iowa City, in 1997. He is currently an Assistant Professor in the Department of Industrial Management, National ChiNan University, Puli, Taiwan, R.O.C. His interests include decision support systems, intelligent systems, and concurrent engineering. His technical papers have been published in the IEEE TRANSACTIONS ON SYSTEMS, MAN, AND CYBERNETICS, IEEE TRANSACTIONS ON COMPONENTS, PACKAGING, AND MANUFACTURING TECHNOLOGY, International Journal of Production Research, and Computer-Aided Design.