A PRELIMINARY STUDY ON CONCEPTUAL DESIGN OF MECHATRONIC SYSTEMS

Transcription

1 A PRELIMINARY STUDY ON CONCEPTUAL DESIGN OF MECHATRONIC SYSTEMS Li Chen 1 Murali Jayaram The University of Toronto and Manufacturing Integration Laboratory Department of Mechanical and Industrial Engineering 5 King s College Road, Toronto, ON, CANADA M5S 3G8 Tel: (416) Fax: (416) chenl@mie.utoronto.ca Abstract- A mechatronic system is a cross-disciplinary system that encompasses not only mechanical and electronic components but also built-in informational/software constituents for controlling them. ing such systems requires multidisciplinary expertise, spanning the disciplines through electronics, software, computers, mechanical, electrical and control engineering. This paper addresses the conceptual design of mechatronic systems under the thrust of concurrent engineering. An enhanced conceptual design methodology describing the early design stage of mechatronic systems is presented through an example illustration. This methodology treats each feasible solution as a solution strategy and then relates them through the analysis of customer requirements and domain (discipline) constraints. The development of the methodology is based on the study of Quality Function Deployment (QFD), Axiomatic (AD), Theory of Inventive Problem Solving (TRIZ). Index Terms-- Conceptual, Mechatronic Systems, Quality Function Deployment, Axiomatic, Theory of Inventive Problem Solving, Concurrent Engineering I. INTRODUCTION Recent advances in technology have encouraged the shift of engineered products from single-disciplinary to crossdisciplinary. A mechatronic product is typically a crossdisciplinary system that encompasses not only mechanical and electronic components but also built-in informational/software constituents for controlling them. A wide spectrum of engineered products on the global market is mechatronics intensive or relevant, ranging from household appliances to medical electronic apparatus to industrial robots or automo tive systems. ing such systems requires multidisciplinary expertise, spanning the disciplines through electronics, sensor and transducer technology, control and system engineering, information technology, computer software and hardware, artificial intelligence, mechanical design, materials and manufacturing. The complexity of such systems requires the application of concurrent engineering during the design process. In this paper, attention is devoted to the evaluation of mechatronic systems based on a concurrent engineering approach with emphasis on the early design stage. 1 Corresponding author, also ASME member. Mechatronics is to achieve a synergy between various engineering domains. Each domain in a mechatronic system is characterized by specific rules and definitions. Conventional design of multi-domain, cross-disciplinary systems is based on an over-the-wall approach [3], which is generally associated with strict design rules and tradeoff, deteriorating the overall efficacy of the design. To overcome this problem, the advocate of concurrent engineering [3] is to enhance the design process both costeffectively and time-efficiently. In a multi-domain environment, a variety of design solutions are possible. Only some of these serve as ideal solutions. The identification of this ideal solution space can be attained by adopting a suitable conceptual design methodology. Mechatronic systems can be divided (for simplicity) into, mechanical, microelectronics and software domains. The sub-system level analysis can be accomplished by classifying the design problem into two general domains, i.e., Product and Information System. The Product Domain is concerned with mechanical components and their geometry, and the Information System domain with the implementation of microelectronics and related software. In the following sections, underlying theories and methodologies related to this work will be reviewed first. Then an enhanced conceptual design methodology describing the early design stage of mechatronic systems will be presented along with the exa mple study of a pick and place robot. This methodology will be further summarized to conclude this work. II. RELATED WORK The conceptual design methodology to be presented is developed with reference to Quality Function Deployment (QFD) [8], Axiomatic (AD) [9], and Theory of Inventive Problem Solving (TRIZ) [10]. They will be reviewed as follows. QFD converts the raw customer requirements into appropriate functional requirements that can be easily considered in the design process. The process of conversion essentially begins with the identification of customer requirements and tabulating them along with their importance values. To satisfy these initial customer

2 requirements, functional requirements are generated. The entire solution set of functional requirements that satisfy most of the customer requirements are considered. Based on these functional requirements, various design parameters are proposed. Apart from these, the target value of each design parameter and comparative data from the competitors are also obtained. Hauser and Clausing [8] elucidated the methodology through the House of Quality [4]. AD divides the design process into four domains, that is, customer domain, functional domain, physical domain and process domain. Each domain is characterized by unique sets of variables, functions and constraints. AD provides design axioms, theorems and corollaries to define relationships between the functional requirements and corresponding design parameters, where the most widely used axioms are Independence Axiom: Maintain the independence of functional requirements. Information Axiom: Minimize the information content of the design. AD suggests a good design be un-coupled or de-coupled in order to satisfy the Independence Axiom [9]. Based on its framework, the generation of design concepts is structured systematically and the goodness of a design can be evaluated conceptually. TRIZ states that all designs tend to achieve an ideal state in which functionality should be achieved without any resource consumption. In the design process, a designer usually faces many domain conflicts. The common method to cope with these conflicts is to identify a parameter set, such that the increase of the first parameter causes the decrease of the second parameter resulting in overall system improvement. Based on the analysis of numerous patents, Altshuller [10] defined many heuristic rules and tables [11], which indicate the procedures to resolve the domain conflicts. In order to apply TRIZ, a conflict must be recognized. In the sub-functional level of QFD and AD, the sub-functions are bounded by the limitations of the main function and the customer requirements, eventually yielding conflicts. These conflicts can be resolved by the application of TRIZ, thereby being integrated with QFD and AD. Similarly, TRIZ can also be applied across domains, in which case the inter domain constraints and boundaries define the system. In this work, QFD will be used as a baseline for the analysis of the mapping from customer to engineering requirements, AD will be adopted as a guideline to generate feasible, good design solution alternatives, and TRIZ will be applied to deal with domain conflicts in design. III. PROPOSED METHODOLOGY The mechatronic design problem is initially divided into two sub-categories -Product Domain and Information System Domain. This is done to reduce the functional complexity of the system. Each domain is analyzed separately and decomposed functionally. The sub-functions are generated using AD and TRIZ. For each sub-function, a design parameter is generated. Each design parameter is then ranked according to various design characteristics such as reliability, cost, manufacturability, etc. Such information that is associated with a design parameter is called a solution strategy (SS). The solution strategies are subjected to various design domains (e.g., microelectronics, control, information systems) and the analysis of the solution strategies is tabulated accordingly. The solution strategies are later subjected to aggregation based on information flow, system boundaries/constraints and product design constraints. The aggregation corresponding to maximum satisfaction of the customer requirements and having a suitable preference rating is taken as an acceptable design. Figure 1 illustrates the overall methodology proposed, which will be further discussed through the example study of a pick and place robot [5]. The implementation procedure will be presented in a step-by-step manner, along with the general flow of the methodology. It is assumed that the customer requirements of the example are initially available, and the final design scheme must satisfy all these requirements. For a typical pick and place robot, it is required to carry a load vertically, rotate about its base, and release the load in a horizontal plane. A. Procurement of Customer Requirements The gathering of customer requirements is an initial yet important phase in any design. The initial customer requirements are collected and tabulated along with their relative importance values (scale used in this example 1,3,9 ). The rankings of the customer requirements are taken from the customers and are tabulated with the customer requirements (see Table 1). Usually the customer requirements are not specific and tend to overlap considerably. In order to avoid the complexity of the customer requirements, a tradeoff strategy has to be adopted and key customer requirements have to be selected. The customer requirements should be simplified by a method similar to (but not necessary) decomposition, such that they are no longer logically dependant on each other. To achieve this, for example, the Independence Axiom in AD [9] can be applied. The requirements with rank 9,3 are taken as must requirements and the requirements with rank 1 as wish requirements. The must requirements are those requirements that have to be satisfied in design. The wish requirements are those requirements that are subjected to tradeoff. The customer requirements are classified accordingly and they are tabulated along with the original set of customer requirements in Table 1. From Table 1, it seems that the requirements {CR4, CR5, CR7, CR10, CR11} are not so important to the customer, as such, they are treated as the wish requirements subject to tradeoff. The tradeoff strategy aims to determine the key requirement among a set of requirements. This is accomplished by identifying the interactions of the wish

3 requirements and the must requirements. A ranking procedure is used to determine the relationships between these requirements, where 1 represents a strong relationship and 0 a weak relationship. Mathematically, the objective is to find X requirement {X 1, X 2..X n }, which maximizes the interaction function f(x,y), where {Wish requirements} = X the set of wish requirements {Must requirements} = Y the set of must requirements {Customer requirements} = {Must requirements} {Wish requirements} The wish requirement that conveys maximum interaction is taken as an additional must requirement. Finally, the remaining wish requirements are ranked in descending order according to their final ranks obtained from the tradeoff table. Table 2 shows that the requirement, CR10, even not so important to the customer, becomes an important concern for the designer as it has a significant impact on all must requirements. As a result, CR10 is added to the must requirement category. The wish requirements {CR4, CR5} show moderate association with the must requirements. These two requirements serve as external factors that control the wish requirements and design. The final classification of the requirements is summarized in Table 3. This ends up the initial stage of conceptual design, which is the analysis of the customer requirements. Table 2. Tradeoff Table Must CR s CR1 CR2 CR3 CR6 CR8 CR9 Wish CR s Scores CR CR CR CR CR B. Selection of FR s and DP s The second phase is to develop design parameters through the generation of functional requirements for the customer requirements. In order to achieve this, TRIZ and AD should be both employed. Figure 1. Enhanced Conceptual Methodology Flowchart Table 1. Customer Requirements with Classifications Serial No. Customer Requirements Importance Values Classification CR1 Ability to lift load 9 Must CR2 Good position accuracy 9 Must CR3 Use available energy source 3 Must CR4 Occupies smaller volume 1 Wish CR5 Easy to repair 1 Wish CR6 Easy to control 9 Must CR7 Cheap 1 Wish CR8 Good reliability 9 Must CR9 Must be easily computerized 9 Must CR10 Fast operation time 1 Wish CR11 Use metal parts 1 Wish The interaction function is user defined and domain dependent, subject to the complexity of the problem. In this example, the interaction function is defined as the dependency between the wish and must requirements. The functional requirements are decomposed hierarchically to obtain sub-functional requirements until they reach the most simplified. System dependant decomposition based on material, process or energy flow is commonly used. Each sub-functional requirement can have more than one feasible design parameter to it (see Fig. 2). The design parameters for each functional requirement is obtained by the application of AD [9] and TRIZ [10]. All the feasible design parameters can be used for developing solution strategies. For each design parameter, a solution strategy can be made in association with it (see Fig. 2). The solution strategy defines an appropriate solution and its characteristics such as cost, reliability, efficiency, ease to repair or manufacture, etc. There may exist more than one design parameter for each functional requirement. The general procedure conventionally adopted is to generate design parameters without considering constraints or boundaries. This is followed by performing analysis in a solution neutral environment, thus making it possible to choose feasible solutions [6]. However, this process may incur errors and system violation, as certain solutions may not be defined in the solution space. In order to eliminate these erroneous solutions, a process model based on concurrent engineering is suggested and illustrated in Fig. 3.

4 Table 3. Final Set of Customer Requirements Serial No. Customer Requirements 1 Ability to Lift Load 2 Good position accuracy 3 Use available energy source 4 Occupies smaller volume 5 Easy to repair 6 Easy to control 7 Good Reliability 8 Must be easily computerized 9 Fast Operation time domains as a whole. The solution strategies of each domain must also be defined in this common space. Figure 4 suggests a dual-domain based concurrent design model to illustrate the above concept. In the example, the functional requirements are obtained by decomposition-based functional analysis. Given below are the results: FR1: Grip load and Release load FR2: Rotate load FR3: Easy to control (Information system domain) FR4: Easy to computerize (Information system Domain) FR5: Use available energy source FR6: Lift load FR11 Table 4. Activities Done in Each Domain DP1 DP2 DP3 parameters Activities Constraints SS1 SS2 SS3 Solution strategies Product Geometry, Physical Shape, Feasibility of Mechanical Material Flow, Geometric Constraints, Physical Parts Figure 2. FR with its DP s and SS s Information Systems Microelectronics Information System, Software, Control System Input Output of Circuits System Energy Constraints Product Mechanical Figure 3 Domain Allocation: Top Level Structure Product Product Performance Product Components Figure 4. Concurrent Model Information System Microelectronics Information Systems Information System Information Transfer S1 S2 S3 S4 S5 S6 Availability Information Components Control Solution strategies The intersection space of the two design domains Figure 3 shows overall concurrency in existence between the Product Domain and the Information System Domain. The intra-domain concurrency is also maintained in the Information System Domain among different disciplines. This process of domain allocation defines strict boundaries and constraints enabling the designer to focus on the potential solutions. Some of the activities that are focused on the two domains are given in Table 4. Since mechatronics is a multidisciplinary system, the design availability of the system is common to all related domains. This means that a feasible solution must be selected in such a way that it should fall in the intersection of all the The problem is divided into product domain and information system domain, according to Fig. 3 and Table 4. For this example, design alternatives can be selected in terms of various energy resources such as mechanical, electrical, pneumatic, hydraulic, etc. The target system is evaluated with respect to each of these resources so that a proper design parameter candidate is generated and a corresponding solution strategy is determined. In order to apply TRIZ, three entities must be defined in terms of field, object and tool [10]. For illustration, consider a functional requirement as grip load and release load of the robot. Here object is the load (that has to be lifted), tool is the system drive assembly (solution), and field is mechanical, electrical, pneumatic or hydraulic. Evaluating each field by the application of AD and TRIZ, the following solution alternatives are obtained. FR1: Grip Load & Release Load Mechanical (DP11): Use the worm-wheel-gear arrangement that fastens with two blocks such that when worm rotates, the blocks come closer and grip the work piece. When it rotates in opposite direction, the load is released. Grip 1 0 Rotate worm = Re lease 0 1 Gear reverese worm rotation Electrical (DP12): Use a motor drive to move a mechanical gripper. Grip 1 0 Rotate mechanical arrangement power motor = Re lease 0 1 change current direction Hydraulic & Pneumatic (DP13, DP14): These two setups have the same solutions, except for the fact that their

5 driving fields are different. The solution is to use an actuator for gripping and flow valve for release. Grip 1 0 Gripper = Re lease 0 1 Control valve Likewise, by applying Independence Axiom and TRIZ, the design parameters for the remaining FR s are obtained. Rankings are made between each design parameter and the customer requirements. Mapping is denoted as 1 for a strong relationship and 0 for a weak relationship. The design parameter that shows the maximum relationship with the customer requirements is chosen as a feasible design parameter for its corresponding functional requirement. The pneumatic solution satisfies all the customer requirements. Although fields other than pneumatics satisfy the system, the best option is to use a field that satisfies all the customer requirements. Hence, the pneumatic system is chosen as the field for the problem. The design parameters corresponding to the functional requirements for this field is selected. These functional requirements have to be satisfied in order to obtain the necessary design. The functional requirements may be coupled in nature. In order to determine whether they are coupled, relationships are made among the functional requirements (see Table 6). The relationships are 1 for a relationship and 0 for a weak relationship. The FR s set, {FR14, FR34, FR44}, has similar scores. This shows that these functional requirements are interdependent and therefore, they should be made independent. This can be achieved by configuring independent circuits, also enhancing the controllability of the robot. The solution is obtained by the application of AD principles, where the functional requirement is to maintain independence of operation and the corresponding design parameter is independent circuits. The relationships between the functional requirements are established once again, after the circuits are made independent. This result is presented in Table 7. If functional dependencies still occur in the system, a new set of design parameters should be sought and the system should be analyzed again. Note that the functional requirements are associated with the corresponding sets of design parameters and solution strategies. C. Analysis of Solution Strategies The solution strategies that are obtained from the analysis of FR and DP are now sent to the other design domains for analysis. In the other domains, the functionality and feasibility of design for the selected solution strategies are evaluated (see Fig. 5). The solution strategies that are present in the common design availability space (see Fig. 4) are selected. This is followed by the aggregation of all the selected solution strategies. Figure 6 represents an aggregation model based on the modification to the model in [1]. This aggregation is dictated by domain constraints according to energy flow or signal flow. The aggregation of solution strategies satisfying the Independence Axiom and having maximum performance preference is taken as a final design. Table 5. Relationship Matrix of House of Quality Functional Requirements FR1 FR2 FR3 Parameters DP11 DP12 DP13 DP14 DP21 DP22 DP23 DP24 DP31 DP32 DP33 DP34 Customer requirements CR CR CR CR CR CR CR CR CR Scores DP14 DP24 DP34 Functional Requirements FR4 FR5 FR6 Parameters DP41 DP42 DP43 DP44 DP51 DP52 DP53 DP54 DP61 DP62 DP63 DP64 Customer requirements CR CR CR CR CR CR CR CR CR Scores DP44 DP54 DP64 Table 6. Roof of House of Quality The above methodology can be applied to Product Domain and Information System Domain in a concurrent fashion. These two domains must be checked simultaneously for the possible solutions. Based on the methodology proposed, the conceptual design solution to the example is finally worked out. The final results are illustrated in Fig.7, Fig. 8 and Fig. 9, respectively. Following a systematic procedure, the application of the methodology makes its design easier, more effective and efficient.

6 Table 7. Interactions between FR s after the Decomposition of Circuits FR1 DP 14 SS 1 FR2 DP 24 SS 2 FR3 DP 34 SS 3 FR4 DP 44 SS 4 FR5 DP 54 SS 5 FR6 DP 64 SS 6 Sent to Microelectronics, Information Systems and Control Domain for Analysis. Figure 5. Relationship between {FR s, DP s, SS s} and other Domains IV. CLOSURE The methodology proposed in this paper describes the application of concurrent engineering to the conceptual design of complex mechatronic systems. The customer requirements are initially collected and then evaluated. The functional requirements are identified and analyzed in both product domain and information system domain. The final set of functional requirements is assessed with customer requirements in the House of Quality. The roof of HOQ is used to determine potential conflicts among various functional requirements, which can be resolved by the application of AD and TRIZ. The proposed methodology is aimed at the initial stage of the design and analysis of mechatronic systems. As a result, the framework of conceptual design with application to mechatronic systems has been presented and formalized. Future work includes determination of the activities and constraints of various domains forming a mechatronic system as well as incorporation of inter-domain analysis tools (e.g., rapid prototyping [7]) and analysis tools for electronic components. V. ACKNOWLEDGEMENTS This project is funded in part under MMO Project #DE614 from Materials and Manufacturing Ontario (MMO). The second author also acknowledges Glynn Williams Fellowship of the University of Toronto in support of his study. Figure 6. Overall Model Figure 7.Conceptual Model Figure 8.Conceptual Circuit Model of the Rotating and Linear Actuators Figure 9.Conceptual Circuit Model of the Gripper VI. REFERENCES [1] Luckel, J. (editor), Gausemeier, J., Brexel, D., Frank, T. and Humpert, A., Integrated Product Development A New Approach for Computer Aided Development in the Early Stages, Proceedings of the Third Conference on Mechatronics and Robotics, October 1995 Paderborn, B.G. Teubner Stuttgart 1995, pp , [2] Hendrick, M.J. and Van Brussel, Mechatronics-A Powerful Concurrent Engineering Framework, IEEE/ASME Transactions on Mechatronics, Vol. 1, No. 2, pp. 127, June [3] Syan, S.C., (editor) and Menon, U. (editor), Concurrent Engineering: Concepts, Implementation and Practice, Chapman & Hall Inc., pp. 4-5, [4] ReVelle, J.B., Moran, J.W. and Cox, C.A., The QFD Handbook, John Wiley & Sons Inc. New York, [5] Fraser, C., Milne, J., Integrated Electrical and Electronic Engineering for Mechanical Engineers, McGraw-Hill, pp , [6] Pahl, G., and Beitz, W., Engineering, Springer Great Britain, [7] Popovic, D., and Vlacic, L., Mechatronics in Engineering and Product Development, Marcel-Dekker Inc., pp , [8] Clausing, D.P., Total Quality Development, ASME Press New York, [9] Suh, N.P., The Principles of, Oxford University Press New York, [10] Altshuller, G.S., And Suddenly the Inventor Appeared, Technical Innovation Center Inc. Auburn M.A., [11] Altshuller, G.S., Creativity as an Exact Science-The Theory of the Solution of Inventive Problem Solving, Gordon and Breach Science Publishers New York, [12] Coelingh, E., Vries, T.J.A., and Van Amerongen, J., Automated conceptual design of mechatronic systems, Journal A 38(3), Special issue on Computer Aided Control System, Vol. 38, No. 3, 1997.