- Email: [email protected]
Multi-disciplinary system decomposition of complex mechatronics systems
CIRP Annals - Manufacturing Technology 60 (2011) 191–194
Contents lists available at ScienceDirect
CIRP Annals - Manufacturing Technology jou rnal homep age : ht t p: // ees .e lse vi er. com/ci rp/ def a ult . asp
Multi-disciplinary system decomposition of complex mechatronics systems H. Komoto a,b,*, T. Tomiyama (1)b a b
National Institute of Advanced Industrial Science and Technology, Tsukuba, Japan Faculty of Mechanical, Maritime and Materials Engineering, Delft University of Technology, Delft, The Netherlands
A R T I C L E I N F O
A B S T R A C T
Keywords: System architecture Complexity Computer aided design
Modern mechatronics systems are increasingly becoming complex in terms of the size and multidisciplinarity. System architecting of such multi-disciplinary systems defines subsystems and their interfaces through hierarchical system decomposition. As opposed to traditional system decomposition methods using building blocks associated with functions, this paper proposes a method to decompose a system by defining physical phenomena that constrain clustering patterns of system parameters. A case study of a printer demonstrates the method implemented on a computational tool, which supports systematic generation of decomposition candidates and configuration of sensor–actuator combinations based on the method. ß 2011 CIRP.
1. Introduction Modern mechatronics systems, such as hybrid vehicles, medical instruments, and high-end printers, are increasingly becoming complex both quantitatively (size) and qualitatively (multidisciplinarity) [1,2]. System architecting is basically a conceptual design process within the development of such a product (see the V-model in [3]). It includes four major subprocesses: (1) identifying requirements to be translated to system descriptions, (2) hierarchically decomposing the system to subsystems, (3) defining behaviors and structure of subsystems, and (4) defining interfaces among subsystems. While multi-disciplinarity is one of the sources for innovative system architecture [4], it also increases complexity of products and chances of design failures [2]. System decomposition into smaller subsystems based on the divide-and-conquer principle plays a crucial role in reducing complexity both quantitatively and qualitatively. Traditionally, system decomposition assumes building blocks, for example, machine elements, established components, and mechanisms in mechanical design [5] (Fig. 1(a)). These building blocks are associated with functions and allow a system architect to construct embodiment from functional decomposition of requirements. If there is no existing building block that satisfies a certain functional requirement, a new building block has to be designed using building blocks at a lower level. In this paper, an alternative decomposition approach is proposed for system architecting of complex multi-disciplinary systems when these building blocks are not available, which is illustrated in Fig. 1(b). This is done by first identifying relevant physical phenomena (which includes entities), and second by finding parameters and their relationships that will cause those physical phenomena. Third, entities defined in the physical phenomena are
* Corresponding author. 0007-8506/$ – see front matter ß 2011 CIRP. doi:10.1016/j.cirp.2011.03.102
selectively unified, which defines a system decomposition. Different selection of unification results in different decompositions. Fourth, these parameters inside physical phenomena and their relationships will form a parameter network, which could be used for validation and verification. The method can systematically generate and suggest different decomposition candidates by re-clustering the parameter network. The paper formalizes the decomposition process and presents a computational tool to support it. The proposed method has two main advantages compared with past work such as function decomposition and modularization methods studied in function modeling (e.g., [6–8]) and product architecture (e.g., [9]). The first advantage is that it supports system decomposition even without clearly defined building blocks, because the method allows defining a system decomposition from the physical phenomenon level. This feature allows exploring different system decompositions, which is the second advantage of the method. This work is an extension of our study on the development of a computational tool for system architecting [10]. The previous tool supported modeling of a system using parameters and their dependency consistently with abstract concepts (e.g., function, behavior, state, and structure) independently of specific engineering domains. The tool supported system decomposition by following the Function-Behavior-State (FBS) modeling [6]. However, the tool could not systematically generate different decomposition candidates and visualize decomposition results with parameters and their dependency. This study extended the system architecting tool with the proposed method. The paper is structured as follows. Section 2 describes the requirements of a method for system decomposition in system architecting followed by a review of related methods. In Section 3, the proposed method for system decomposition is described in detail. Section 4 illustrates an application of the proposed method to system architecting of a printer, which is a typical multidisciplinary mechatronics system. Section 5 summarizes and concludes the paper.
[()TD$FIG]
[()TD$FIG]
H. Komoto, T. Tomiyama / CIRP Annals - Manufacturing Technology 60 (2011) 191–194
192
Fig. 2. Physical phenomena.
Fig. 1. System decomposition approaches.
2. System decomposition in system architecting 2.1. Requirements A system decomposition method within system architecting (Fig. 1) should satisfy the following three requirements. Multi-disciplinarity: A system decomposition method should be able to decompose multi-disciplinary systems. The decomposition process and system descriptions should be independent of specific aspects. Building blocks: A system decomposition method should be able to decompose a system even without known building blocks. The method should be able to generate decomposition down from the physical phenomenon level. Systematic generation of decomposition candidates: A system decomposition method should be able to systematically (automatically) generate all possible decompositions that satisfy given requirements. 2.2. Function modeling System decomposition is possible from various perspectives, including physical phenomenon-based function [6–8] and geometrical connectivity [9], although this paper focuses only on functional decomposition based on physical phenomena. Such a perspective defines how to capture, model, and represent systems and is called ‘‘ontology’’ [11]. There are several ontologies for the support of functional decomposition. One of the methods treats functions as mechanisms to transform energy, material, and signal [7]. Another method is the Function-Behavior-State (FBS) scheme [6] that supports modeling functions as symbols associated with symbols representing behavioral and structural concepts, which is more general than the transformation-based function modeling method. Both methods can be used to define functional system decomposition in terms of the behavior and structure of systems and systematically (automatically) generate decomposition candidates, although there is no such implementation yet. The current work is an attempt to automatically generate multiple decomposition candidates taking the behavior and structure of systems into consideration.
Our method uses physical phenomena combined with entities and relations among the parameters of entities. Fig. 2 illustrates the formalization of physical phenomena. Entities are instantiated with instantiation of subsuming physical phenomena. Instantiated entities can be combined or unified if necessary. Parameters of these entities are updated as a result of unification. For instance, two physical phenomena, conductive heat transfer and linear motion in Fig. 2 subsume entities, object and mass, which are separately defined in them. Depending on the physical decomposition by system architects, instantiation of these physical phenomena may result in a new entity that inherits the parameters of both object and mass (i.e., an entity that moves and absorbs heat), or two independent entities. This formalization of physical phenomena has several advantages for system decomposition in system architecting. First, the method can enrich the knowledge base of building blocks (entities). Second, the formalization can represent other types of parameter dependency. For instance, it can describe additional processes that control physical phenomena in a system. Third, disjoint of entities in a physical phenomenon will reject impossible decomposition candidates after instantiation of multiple physical phenomena. In Section 4, these advantages are shown through an illustrative system decomposition case. 3.2. System decomposition procedure and its implementation The decomposition procedure using the formalization of physical phenomena in Section 3.1 is implemented in the following algorithm (see Fig. 3). 1. The target parameters of a system are defined. Target parameters can be customer requirements identified through function modeling, or they are directly defined if obvious from the perspective of system architects. 2. Physical phenomena that will influence these target parameters are looked up in the physical phenomena knowledge base. Since these phenomena have descriptions about relationships among parameters (e.g., constraints and physical rules), other parameters related to the target parameters are identified with [()TD$FIG] them.
3. Multi-disciplinary system decomposition 3.1. System description based on physical phenomena In order to describe a system to be decomposed in system architecting, our method focuses on physical phenomena, which define processes that take place in the system, and relations among parameters. For instance, convective heat transfer (a physical phenomenon) can be described by heat flow (a process) from source to object through fluid, and the quantity of heat flow depends on the temperature of object and source, and the thermal conductivity of fluid. Here, source, object, and fluid are all entities. Such knowledge about causality and parameter relations can be extracted from engineering textbooks. This is independent of the system’s model itself.
Fig. 3. Implementation of system decomposition procedure: (a) target parameters, (b) physical phenomena candidates, (c) selected physical phenomena, (d) decomposition candidates, (e) selected decomposition and (f) update of system model.
[()TD$FIG]
H. Komoto, T. Tomiyama / CIRP Annals - Manufacturing Technology 60 (2011) 191–194
193
3. All selected physical phenomena are instantiated and unifiable entities can be selectively unified. Here all possible unification patterns are examined, while removing impossible patterns following disjoint information defined in physical phenomena. This will results in decomposition candidates. 4. A decomposition candidate is selected from the candidates as a solution. As a result, new entities are instantiated and the system model is updated in terms of the parameters of entities and their relations. Some of these parameters become new target parameters and the procedure continues iteratively for hierarchical system decomposition. The procedure has been implemented on a computational tool for system architecting [10] which was developed as an extension of the Knowledge Intensive Engineering Framework (KIEF) [11]. Fig. 3 describes the implementation. Qualitative Process Abduction System (QPAS) [12] in KIEF has been modified to generate suggestions of physical phenomena regarding target parameters using the physical phenomena knowledge base. The parameter network modeler of the tool is used to visualize parameters and their relations. Fig. 5. System decomposition interface.
4. A case study This section illustrates a system decomposition example of a printer with the proposed method. This example illustrates how the system architect identifies the parameters of entities such as paper and heating subsystem and explores possible sensor– actuator configurations for control purposes through system decomposition. 4.1. From customer requirements to system parameters The system architect builds an initial printer model that consists of quality and productivity of printer and length and mass of paper. Fig. 4(a) shows the initial model on the parameter network modeler, in which green boxes are entities containing parameters. These parameters represent customer requirements about the performance and operational range of the printer. They are selected as target parameters by the system architect (Step 1) and are used to select physical phenomena or processes, which contain the parameters of the printer related with the customer requirements. For instance, the QPAS algorithm finds a process sheet printing predefined in the physical phenomena knowledge base, because the process includes parameter relations indicating that productivity is proportional to velocity of paper, inverse proportional to length of paper and distance between sheets (as a parameter of system). Instantiation of such processes (Step 2) immediately results in instantiation of new parameters of existing entities (Step 4) (i.e., Step 3 is omitted), because the instantiated processes do not instantiate new entities. Fig. 4(b) shows the updated system model, in which orange boxes are physical phenomena (processes) containing the indices of parameter relations. Fig. 4(c) shows the detail of the parameter relations in Fig. 4(b).
[()TD$FIG]
4.2. Development of the system architecture The main architecture of the printer is determined through system decomposition. Fig. 5 shows the screen hardcopy of the system decomposition interface at this stage. Temperature, velocity, and surface pressure of paper are selected as target parameters (Step 1). The QPAS algorithm suggests several candidate physical phenomena that can potentially change the value of the target parameters. For instance, convective heating and conductive heating are suggested as physical phenomena regarding temperature of paper. Four physical phenomena are selected in order to change the target parameters (Step 2). Fig. 5(a) shows the list of selected physical phenomena and the corresponding target parameters. Taking the list as input, the tool suggests 151 decomposition candidates (Step 3). Fig. 6 shows some of the suggested decomposition candidates, in which entities that are potentially instantiated as new entities are distinguished with factual names (e.g., transfer belt and conductive heater), since they do not have specific name during instantiation. Fig. 6(a) shows the decomposition with instantiation of the minimum number of new entities, in which system included all entities defined in the selected physical phenomena except for air. The disjoint information about the potential entities defined in each physical phenomenon assures that they are not unified with paper, because the correspondence between paper and one of the entities in each physical phenomenon has been assigned. Air is not unified with either system or paper, because the physical phenomenon convective heating consists of three disjoint entities (such as source, object, and fluid in Fig. 2). Fig. 6(b) shows the decomposition with instantiation of the maximum number of new entities. In the decomposition, the potential entities, which do not correspond to paper, are treated as individual entities. Fig. 6(c) shows an intermediate decomposition, in which two entities (convective heater and transfer belt) were treated as a unified entity. Fig. 7
[()TD$FIG]
Fig. 4. Identification of system parameters based on requirements.
Fig. 6. Examples of suggested decomposition candidates.
[()TD$FIG]
194
H. Komoto, T. Tomiyama / CIRP Annals - Manufacturing Technology 60 (2011) 191–194
5. Summary and conclusions
Fig. 7. A system decomposition result (based on Fig. 6(c)).
[()TD$FIG]
This paper has proposed a method for multi-disciplinary system decomposition for system architecting of complex mechatronics systems. It first analyzed the requirements of such a method in comparison with the function modeling methods in past literature. It presented a method to decompose a system with the knowledge about physical phenomena, which results in the parameters of subsystems and their relations. It described the implementation of the method followed by the demonstration showing systematic generation of decomposition candidates and exploration of sensor–actuator configurations for control design. The method could provide an alternative way for the modeling of the knowledge of system decomposition, which is different from that of physical (structural) decomposition called building blocks. Acknowledgements This work has been carried out as part of the Octopus project with Oce´-Technologies B.V. under the responsibility of the Embedded Systems Institute in Eindhoven, the Netherlands, partially supported by the Netherlands Ministry of Economic Affairs under the Bsik program.
Fig. 8. Examples of sensor–actuator combinations.
shows the selected decomposition based on Fig. 6(c) on the parameter network modeler (Step 4). 4.3. Configuration of sensor–actuator combinations Sensor–actuator combinations are important from the control engineering viewpoint. For example, from the system decomposition in Fig. 7, it is desirable for the system architect to be able to identify appropriate control parameters to keep the temperature of paper constant. These combinations can be added to the system architecture by defining physical phenomena that include entities such as object, sensor, and actuator, and relations between parameters of object and actuator (i.e., measured parameters through sensor and controlled parameters). Fig. 8 shows examples of sensor–actuator combinations added to the system architecture shown in Fig. 7. With this feature, the system architect can make decisions regarding sensor–actuator configurations (e.g., whether a combination is defined as a local control within a subsystem or a control across subsystems) on domain independent parameter network.
References [1] Suh NP (2005) Complexity in Engineering. Annals of the CIRP 54(2):46–63. [2] Tomiyama T, D’Amelio V, Urbanic J, ElMaraghy W (2007) Complexity of Multidisciplinary Design. Annals of the CIRP 56(1):185–188. [3] Forsberg K, Mooz H (1992) The Relationship of Systems Engineering to the Project Cycle. Engineering Management Journal 4(3):36–43. [4] Williams BC (1990) Interaction-based Invention: Designing Novel Devices from First Principles. Proceedings of AAAI-90, 349–356. [5] Pahl G, Beitz W, Feldhusen J, Grote KH (2007) in Wallace K, Blessing L, (Eds.) Engineering Design—A Systematic Approach. 3rd ed. Springer, Berlin. [6] Umeda Y, Ishii M, Yoshioka M, Tomiyama T (1996) Supporting Conceptual Design based on the Function-Behavior-State Modeler. Artificial Intelligence for Engineering Design Analysis and Manufacturing 10(4):275–288. [7] Stone R, Wood K (2000) Development of a Functional Basis for Design. Journal of Mechanical Design 122(4):359–370. [8] Van Beek T, Erden MS, Tomiyama T (2010) Modular Design of Mechatronic Systems with Function Modeling. Mechatronics 20:850–863. [9] Huang G, Bin S, Halevi G (2003) Product Platform Identification and Development for Mass Customization. Annals of the CIRP 52(1):117–120. [10] Komoto H, Tomiyama T (2010) A System Architecting Tool for Mechatronic Systems Design. Annals of the CIRP 59(1):171–174. [11] Yoshioka M, Umeda Y, Takeda H, Shimomura Y, Nomaguchi Y, Tomiyama T (2004) Physical Concept Ontology for the Knowledge Intensive Engineering Framework. Advanced Engineering Informatics 18:95–113. [12] Ishii M, Tomiyama T, Yoshikawa H (1993) A Synthetic Reasoning Method for Conceptual Design. Proceedings of the IFIP TC5/WG5.3 Conference on Towards World Class Manufacturing, 57–70.
Contents lists available at ScienceDirect
CIRP Annals - Manufacturing Technology jou rnal homep age : ht t p: // ees .e lse vi er. com/ci rp/ def a ult . asp
Multi-disciplinary system decomposition of complex mechatronics systems H. Komoto a,b,*, T. Tomiyama (1)b a b
National Institute of Advanced Industrial Science and Technology, Tsukuba, Japan Faculty of Mechanical, Maritime and Materials Engineering, Delft University of Technology, Delft, The Netherlands
A R T I C L E I N F O
A B S T R A C T
Keywords: System architecture Complexity Computer aided design
Modern mechatronics systems are increasingly becoming complex in terms of the size and multidisciplinarity. System architecting of such multi-disciplinary systems defines subsystems and their interfaces through hierarchical system decomposition. As opposed to traditional system decomposition methods using building blocks associated with functions, this paper proposes a method to decompose a system by defining physical phenomena that constrain clustering patterns of system parameters. A case study of a printer demonstrates the method implemented on a computational tool, which supports systematic generation of decomposition candidates and configuration of sensor–actuator combinations based on the method. ß 2011 CIRP.
1. Introduction Modern mechatronics systems, such as hybrid vehicles, medical instruments, and high-end printers, are increasingly becoming complex both quantitatively (size) and qualitatively (multidisciplinarity) [1,2]. System architecting is basically a conceptual design process within the development of such a product (see the V-model in [3]). It includes four major subprocesses: (1) identifying requirements to be translated to system descriptions, (2) hierarchically decomposing the system to subsystems, (3) defining behaviors and structure of subsystems, and (4) defining interfaces among subsystems. While multi-disciplinarity is one of the sources for innovative system architecture [4], it also increases complexity of products and chances of design failures [2]. System decomposition into smaller subsystems based on the divide-and-conquer principle plays a crucial role in reducing complexity both quantitatively and qualitatively. Traditionally, system decomposition assumes building blocks, for example, machine elements, established components, and mechanisms in mechanical design [5] (Fig. 1(a)). These building blocks are associated with functions and allow a system architect to construct embodiment from functional decomposition of requirements. If there is no existing building block that satisfies a certain functional requirement, a new building block has to be designed using building blocks at a lower level. In this paper, an alternative decomposition approach is proposed for system architecting of complex multi-disciplinary systems when these building blocks are not available, which is illustrated in Fig. 1(b). This is done by first identifying relevant physical phenomena (which includes entities), and second by finding parameters and their relationships that will cause those physical phenomena. Third, entities defined in the physical phenomena are
* Corresponding author. 0007-8506/$ – see front matter ß 2011 CIRP. doi:10.1016/j.cirp.2011.03.102
selectively unified, which defines a system decomposition. Different selection of unification results in different decompositions. Fourth, these parameters inside physical phenomena and their relationships will form a parameter network, which could be used for validation and verification. The method can systematically generate and suggest different decomposition candidates by re-clustering the parameter network. The paper formalizes the decomposition process and presents a computational tool to support it. The proposed method has two main advantages compared with past work such as function decomposition and modularization methods studied in function modeling (e.g., [6–8]) and product architecture (e.g., [9]). The first advantage is that it supports system decomposition even without clearly defined building blocks, because the method allows defining a system decomposition from the physical phenomenon level. This feature allows exploring different system decompositions, which is the second advantage of the method. This work is an extension of our study on the development of a computational tool for system architecting [10]. The previous tool supported modeling of a system using parameters and their dependency consistently with abstract concepts (e.g., function, behavior, state, and structure) independently of specific engineering domains. The tool supported system decomposition by following the Function-Behavior-State (FBS) modeling [6]. However, the tool could not systematically generate different decomposition candidates and visualize decomposition results with parameters and their dependency. This study extended the system architecting tool with the proposed method. The paper is structured as follows. Section 2 describes the requirements of a method for system decomposition in system architecting followed by a review of related methods. In Section 3, the proposed method for system decomposition is described in detail. Section 4 illustrates an application of the proposed method to system architecting of a printer, which is a typical multidisciplinary mechatronics system. Section 5 summarizes and concludes the paper.
[()TD$FIG]
[()TD$FIG]
H. Komoto, T. Tomiyama / CIRP Annals - Manufacturing Technology 60 (2011) 191–194
192
Fig. 2. Physical phenomena.
Fig. 1. System decomposition approaches.
2. System decomposition in system architecting 2.1. Requirements A system decomposition method within system architecting (Fig. 1) should satisfy the following three requirements. Multi-disciplinarity: A system decomposition method should be able to decompose multi-disciplinary systems. The decomposition process and system descriptions should be independent of specific aspects. Building blocks: A system decomposition method should be able to decompose a system even without known building blocks. The method should be able to generate decomposition down from the physical phenomenon level. Systematic generation of decomposition candidates: A system decomposition method should be able to systematically (automatically) generate all possible decompositions that satisfy given requirements. 2.2. Function modeling System decomposition is possible from various perspectives, including physical phenomenon-based function [6–8] and geometrical connectivity [9], although this paper focuses only on functional decomposition based on physical phenomena. Such a perspective defines how to capture, model, and represent systems and is called ‘‘ontology’’ [11]. There are several ontologies for the support of functional decomposition. One of the methods treats functions as mechanisms to transform energy, material, and signal [7]. Another method is the Function-Behavior-State (FBS) scheme [6] that supports modeling functions as symbols associated with symbols representing behavioral and structural concepts, which is more general than the transformation-based function modeling method. Both methods can be used to define functional system decomposition in terms of the behavior and structure of systems and systematically (automatically) generate decomposition candidates, although there is no such implementation yet. The current work is an attempt to automatically generate multiple decomposition candidates taking the behavior and structure of systems into consideration.
Our method uses physical phenomena combined with entities and relations among the parameters of entities. Fig. 2 illustrates the formalization of physical phenomena. Entities are instantiated with instantiation of subsuming physical phenomena. Instantiated entities can be combined or unified if necessary. Parameters of these entities are updated as a result of unification. For instance, two physical phenomena, conductive heat transfer and linear motion in Fig. 2 subsume entities, object and mass, which are separately defined in them. Depending on the physical decomposition by system architects, instantiation of these physical phenomena may result in a new entity that inherits the parameters of both object and mass (i.e., an entity that moves and absorbs heat), or two independent entities. This formalization of physical phenomena has several advantages for system decomposition in system architecting. First, the method can enrich the knowledge base of building blocks (entities). Second, the formalization can represent other types of parameter dependency. For instance, it can describe additional processes that control physical phenomena in a system. Third, disjoint of entities in a physical phenomenon will reject impossible decomposition candidates after instantiation of multiple physical phenomena. In Section 4, these advantages are shown through an illustrative system decomposition case. 3.2. System decomposition procedure and its implementation The decomposition procedure using the formalization of physical phenomena in Section 3.1 is implemented in the following algorithm (see Fig. 3). 1. The target parameters of a system are defined. Target parameters can be customer requirements identified through function modeling, or they are directly defined if obvious from the perspective of system architects. 2. Physical phenomena that will influence these target parameters are looked up in the physical phenomena knowledge base. Since these phenomena have descriptions about relationships among parameters (e.g., constraints and physical rules), other parameters related to the target parameters are identified with [()TD$FIG] them.
3. Multi-disciplinary system decomposition 3.1. System description based on physical phenomena In order to describe a system to be decomposed in system architecting, our method focuses on physical phenomena, which define processes that take place in the system, and relations among parameters. For instance, convective heat transfer (a physical phenomenon) can be described by heat flow (a process) from source to object through fluid, and the quantity of heat flow depends on the temperature of object and source, and the thermal conductivity of fluid. Here, source, object, and fluid are all entities. Such knowledge about causality and parameter relations can be extracted from engineering textbooks. This is independent of the system’s model itself.
Fig. 3. Implementation of system decomposition procedure: (a) target parameters, (b) physical phenomena candidates, (c) selected physical phenomena, (d) decomposition candidates, (e) selected decomposition and (f) update of system model.
[()TD$FIG]
H. Komoto, T. Tomiyama / CIRP Annals - Manufacturing Technology 60 (2011) 191–194
193
3. All selected physical phenomena are instantiated and unifiable entities can be selectively unified. Here all possible unification patterns are examined, while removing impossible patterns following disjoint information defined in physical phenomena. This will results in decomposition candidates. 4. A decomposition candidate is selected from the candidates as a solution. As a result, new entities are instantiated and the system model is updated in terms of the parameters of entities and their relations. Some of these parameters become new target parameters and the procedure continues iteratively for hierarchical system decomposition. The procedure has been implemented on a computational tool for system architecting [10] which was developed as an extension of the Knowledge Intensive Engineering Framework (KIEF) [11]. Fig. 3 describes the implementation. Qualitative Process Abduction System (QPAS) [12] in KIEF has been modified to generate suggestions of physical phenomena regarding target parameters using the physical phenomena knowledge base. The parameter network modeler of the tool is used to visualize parameters and their relations. Fig. 5. System decomposition interface.
4. A case study This section illustrates a system decomposition example of a printer with the proposed method. This example illustrates how the system architect identifies the parameters of entities such as paper and heating subsystem and explores possible sensor– actuator configurations for control purposes through system decomposition. 4.1. From customer requirements to system parameters The system architect builds an initial printer model that consists of quality and productivity of printer and length and mass of paper. Fig. 4(a) shows the initial model on the parameter network modeler, in which green boxes are entities containing parameters. These parameters represent customer requirements about the performance and operational range of the printer. They are selected as target parameters by the system architect (Step 1) and are used to select physical phenomena or processes, which contain the parameters of the printer related with the customer requirements. For instance, the QPAS algorithm finds a process sheet printing predefined in the physical phenomena knowledge base, because the process includes parameter relations indicating that productivity is proportional to velocity of paper, inverse proportional to length of paper and distance between sheets (as a parameter of system). Instantiation of such processes (Step 2) immediately results in instantiation of new parameters of existing entities (Step 4) (i.e., Step 3 is omitted), because the instantiated processes do not instantiate new entities. Fig. 4(b) shows the updated system model, in which orange boxes are physical phenomena (processes) containing the indices of parameter relations. Fig. 4(c) shows the detail of the parameter relations in Fig. 4(b).
[()TD$FIG]
4.2. Development of the system architecture The main architecture of the printer is determined through system decomposition. Fig. 5 shows the screen hardcopy of the system decomposition interface at this stage. Temperature, velocity, and surface pressure of paper are selected as target parameters (Step 1). The QPAS algorithm suggests several candidate physical phenomena that can potentially change the value of the target parameters. For instance, convective heating and conductive heating are suggested as physical phenomena regarding temperature of paper. Four physical phenomena are selected in order to change the target parameters (Step 2). Fig. 5(a) shows the list of selected physical phenomena and the corresponding target parameters. Taking the list as input, the tool suggests 151 decomposition candidates (Step 3). Fig. 6 shows some of the suggested decomposition candidates, in which entities that are potentially instantiated as new entities are distinguished with factual names (e.g., transfer belt and conductive heater), since they do not have specific name during instantiation. Fig. 6(a) shows the decomposition with instantiation of the minimum number of new entities, in which system included all entities defined in the selected physical phenomena except for air. The disjoint information about the potential entities defined in each physical phenomenon assures that they are not unified with paper, because the correspondence between paper and one of the entities in each physical phenomenon has been assigned. Air is not unified with either system or paper, because the physical phenomenon convective heating consists of three disjoint entities (such as source, object, and fluid in Fig. 2). Fig. 6(b) shows the decomposition with instantiation of the maximum number of new entities. In the decomposition, the potential entities, which do not correspond to paper, are treated as individual entities. Fig. 6(c) shows an intermediate decomposition, in which two entities (convective heater and transfer belt) were treated as a unified entity. Fig. 7
[()TD$FIG]
Fig. 4. Identification of system parameters based on requirements.
Fig. 6. Examples of suggested decomposition candidates.
[()TD$FIG]
194
H. Komoto, T. Tomiyama / CIRP Annals - Manufacturing Technology 60 (2011) 191–194
5. Summary and conclusions
Fig. 7. A system decomposition result (based on Fig. 6(c)).
[()TD$FIG]
This paper has proposed a method for multi-disciplinary system decomposition for system architecting of complex mechatronics systems. It first analyzed the requirements of such a method in comparison with the function modeling methods in past literature. It presented a method to decompose a system with the knowledge about physical phenomena, which results in the parameters of subsystems and their relations. It described the implementation of the method followed by the demonstration showing systematic generation of decomposition candidates and exploration of sensor–actuator configurations for control design. The method could provide an alternative way for the modeling of the knowledge of system decomposition, which is different from that of physical (structural) decomposition called building blocks. Acknowledgements This work has been carried out as part of the Octopus project with Oce´-Technologies B.V. under the responsibility of the Embedded Systems Institute in Eindhoven, the Netherlands, partially supported by the Netherlands Ministry of Economic Affairs under the Bsik program.
Fig. 8. Examples of sensor–actuator combinations.
shows the selected decomposition based on Fig. 6(c) on the parameter network modeler (Step 4). 4.3. Configuration of sensor–actuator combinations Sensor–actuator combinations are important from the control engineering viewpoint. For example, from the system decomposition in Fig. 7, it is desirable for the system architect to be able to identify appropriate control parameters to keep the temperature of paper constant. These combinations can be added to the system architecture by defining physical phenomena that include entities such as object, sensor, and actuator, and relations between parameters of object and actuator (i.e., measured parameters through sensor and controlled parameters). Fig. 8 shows examples of sensor–actuator combinations added to the system architecture shown in Fig. 7. With this feature, the system architect can make decisions regarding sensor–actuator configurations (e.g., whether a combination is defined as a local control within a subsystem or a control across subsystems) on domain independent parameter network.
References [1] Suh NP (2005) Complexity in Engineering. Annals of the CIRP 54(2):46–63. [2] Tomiyama T, D’Amelio V, Urbanic J, ElMaraghy W (2007) Complexity of Multidisciplinary Design. Annals of the CIRP 56(1):185–188. [3] Forsberg K, Mooz H (1992) The Relationship of Systems Engineering to the Project Cycle. Engineering Management Journal 4(3):36–43. [4] Williams BC (1990) Interaction-based Invention: Designing Novel Devices from First Principles. Proceedings of AAAI-90, 349–356. [5] Pahl G, Beitz W, Feldhusen J, Grote KH (2007) in Wallace K, Blessing L, (Eds.) Engineering Design—A Systematic Approach. 3rd ed. Springer, Berlin. [6] Umeda Y, Ishii M, Yoshioka M, Tomiyama T (1996) Supporting Conceptual Design based on the Function-Behavior-State Modeler. Artificial Intelligence for Engineering Design Analysis and Manufacturing 10(4):275–288. [7] Stone R, Wood K (2000) Development of a Functional Basis for Design. Journal of Mechanical Design 122(4):359–370. [8] Van Beek T, Erden MS, Tomiyama T (2010) Modular Design of Mechatronic Systems with Function Modeling. Mechatronics 20:850–863. [9] Huang G, Bin S, Halevi G (2003) Product Platform Identification and Development for Mass Customization. Annals of the CIRP 52(1):117–120. [10] Komoto H, Tomiyama T (2010) A System Architecting Tool for Mechatronic Systems Design. Annals of the CIRP 59(1):171–174. [11] Yoshioka M, Umeda Y, Takeda H, Shimomura Y, Nomaguchi Y, Tomiyama T (2004) Physical Concept Ontology for the Knowledge Intensive Engineering Framework. Advanced Engineering Informatics 18:95–113. [12] Ishii M, Tomiyama T, Yoshikawa H (1993) A Synthetic Reasoning Method for Conceptual Design. Proceedings of the IFIP TC5/WG5.3 Conference on Towards World Class Manufacturing, 57–70.