Go to the table of contents.

Previous ...

4.7 Integrated product model and platform-based development

4.7.1 Analytical target cascading and optimal model-based decomposition

The need for integrated product models that include several domains is recognized by many researchers. One example is Michalek et al. (2005) who considered three domains: market, manufacturing, and product simultaneously in an optimization model (Figure 44). In their approach, decision models from design, business, and manufacturing are coordinated with one another to make trade-offs with respect to company level objectives and derive a consistent solution that is optimal for the company. The proposed approach is based on analytical target cascading (ATC) for the coordination of the domain models.

Figure 44: A concurrent engineering process (Michalek et al, 2005).

Analytical target cascading (ATC) is a mathematical optimization technique for decomposing a system into a hierarchy of sub-systems and coordinating the optimization of each sub-system in such a way that an optimal solution for the overall system is reached. In the case described in Figure 44, the business, design, and manufacturing are viewed as sub-systems. Decomposition of a system into a hierarchy of sub-systems provides several advantages. It assists in model management and enables less complex models, since each sub-system model will typically have fewer variables and constraints than a single full system model. In ATC (Figure 45) targets are set at each level in the hierarchy for the sub-systems at the level below in order for the system to achieve its own targets set by the next higher level systems. This procedure is iterated at each level of the hierarchy until convergence. It has been shown that a solution arbitrarily close to the optimal solution for the full system optimization model will be reached when certain coordination strategies are used in the ATC process.

Figure 45: Hierarchically partitioned optimal design problem for a product family
(Kokkolaras et al. 2002).

The approach facilitates communication in concurrent engineering at design stages where parametric models can be called upon in order to resolve trade-offs toward meeting company level objectives. The modularity of the ATC-based methodology allows for additions to the sub-models in an existing hierarchy without causing a need to start again from scratch. This enables an iterative refinement approach to the optimization problem.

Figure 46: Generic coordination strategy for (a) hierarchically and (b) non-hierarchically partitioned problems (Michelena & Papalambros, 1997)

Michelena & Papalambros (1997) focus on how to decompose a problem into a set (hierarchical or non-hierarchical) of sub-problems (Figure 46). Three types of decomposition are commonly found in the design and optimization literature according to Michelena & Papalambros. Object decomposition divides a system into physical components. Aspect decomposition divides a system according to the different specialties involved in its modeling and is the basis for multi-disciplinary optimization (MDO). Sequential decomposition is applied to problems involving a flow of elements or information. There are, however, some concerns with these approaches to decomposition. Object and aspect decomposition assume a natural decomposition of the problem. A drawback in object decomposition is that, in large, highly integrated systems, drawing boundaries around physical components and sub-assemblies is very subjective. Aspect decomposition, often defined by management considerations, may fail to account for disciplinary coupling. Sequential decomposition presumes a one directional design information flow that contradicts the cooperative behavior in concurrent engineering. A drawback common to the three approaches is that computational resources may not match the naturally generated system decomposition.

Michelena & Papalambros (1997) present a formal method for optimal model-based decomposition (OMBD). Model-based decomposition allows identification of weakly connected model structures. Hypergraphs are used to represent design models, and the OMBD problem is formulated as a hypergraph partitioning problem. Function dependence on variables can be represented by a Boolean matrix termed the functional dependence table (FDT), where rows are labeled with design relation/function names and columns are labeled with design and state/behavior variable names. An entry in the matrix is true if the function (row) depends on the variable (column); otherwise it is false.

When the design problem is represented by a hypergraph the vertices represent design functions (i.e. objective and constraints) or simulation modules, and hyperedges represent design and state/behavior variables. A hyperedge represents a variable if and only if every vertex of the hyperedge represents a function that depends on this variable. The cardinality of the hyperedge for a variable is equal to the number of true entries in the column of the FDT.

In optimal model-based decomposition two objectives are to be achieved: (a) minimizing the interconnections between the sub-problems; and (b) balancing the size of the sub-problems. The first objective seeks to reduce the size of the master problem at hand and thus the efforts required to coordinate the sub-problems. The second objective aims to balance the resources required to solve each individual sub-problem. To achieve these objectives the OMBD problem is formulated as a hypergraph partitioning problem. Michelena & Papalambros (ibid.) provide an overview of approaches to the hypergraph partitioning problem and illustrate the approach with a powertrain system design example.

4.7.2 Approaches to design knowledge representation

Kitamura & Mizoguchi (2004) state that it has been recognized that design knowledge is scattered around technology and target domains. One of the two major reasons for this is that different frameworks (viewpoints) for conceptualization of design knowledge are used when people try to describe knowledge in different domains. The other is that several key functional concepts are left undefined or even unidentified. Ontological engineering is applied in order to contribute to the resolution of these difficulties. Ontology can guide the conceptualization of artifacts from a functional point of view, and the authors present an innovative framework for systematization of functional knowledge (Figure 47).

Even though functional representation has been extensively investigated and a great many functional representation languages have been proposed, the authors argue that most of the representations are ad hoc and lack generality and consistency. Concerning the modeling of artifacts, there exist two major viewpoints: device-centered and process-centered views. In the device-centered view any artifact is regarded as a composition of devices processing input in order to produce output that is what the users need. The process-centered view concentrates on the phenomena occurring in each artifact (device) to obtain the output result where little attention is paid to the devices. Device ontology imposes a frame or viewpoint on an event to introduce an engineering perspective. That is, it introduces the concepts of a black box equipped with input and output ports. Although physical process ontology, which specifies the process-centered view, is more fundamental than device ontology, there are some cases where process ontology instead of device ontology is directly employed to model real world events/phenomena. Typical cases are found in modeling chemical processes, for which device ontology is not appropriate. The major difference between the two is that, while device ontology has an agent, which is considered as something that plays the main role in obtaining the output, process ontology does not have such an agent, but has participants, which only participate in the phenomena occurring. Needless to say, such an agent coincides with a device in device ontology. Device ontology specifies the roles played by the elements that collectively constitute a device. The concept of a role is interesting in ontological engineering because an operand plays different roles in different situations. This fact has been a major source of failure in many conceptualizations of the world. For example, a man plays many roles, such as husband, father, and son in his family. These roles are defined in the family context, and hence they are specified by family ontology. Thus, device ontology can be said to be a role specification system for the elements we recognize in a device in general.

Figure 47: Hierarchy of ontology and knowledge of function (Kitamura & Mizoguchi, 2004).

Kitamura & Mizoguchi (2004) present an extended device ontology. Things that exist in the device ontology are grouped into two categories: device and operand. A device has input and output ports that are used to connect it to another device (or more accurately to a conduit). A device consists of other devices in smaller grain size and is usually organized in a whole-part hierarchy of sub-devices. An operand is something that can be considered as that it goes through a device from the input port to the output port, during which it is processed by the device. Examples of an operand include substances such as fluid, or energy, such as heat, motion, force, information, etc. An operand has attributes whose values change over time. A device is something that operates on an operand that goes through the device. The state change of an operand is realized by the difference between the states of the operand at the input port and that at the output port. A conduit is defined as a special type of a device that can be considered as transmitting an operand to an output port without any change in an ideal situation. Examples include a pipe, a shaft, etc. A medium is something that holds an operand and enables it to flow among devices. For example, steam can play the role of a medium because it can hold heat energy. In some domains, a conduit can play the role of medium. For example, while a shaft is a conduit for force and motion, at the same time, it plays the role of medium for them. Furthermore, four kinds of behavior are identified. B0 behavior is defined as the change of an attribute value of an operand at the same location over time. A typical example is an increase of the temperature of a fluid at some observation point over time. B1 behavior is defined as the change of an attribute value of an operand from what it is at the input port of a device to what it is at the output of the device. For example, the increase in the temperature of steam that occurs as it goes through a heater is B1 behavior. The key difference between B0 and B1 is that, while B0 behavior concentrates on the location of the observation rather than the identity of the observed operand, B1 behavior concentrates on the identity of the observed operand rather than the location. B2 behavior is defined as the change of something inside a device rather than at input/output ports. The something could be a motion of a part of the device or an inner state of the device. For example, "rotation of fins in a fan" is an inner behavior of "to fan", "a shaft is twisted" is an inner behavior of "to transmit torque", etc. This behavior is based on an answer to a question such as "what motion is the device performing?" and is not the behavior of the device of smaller grain size but that identified by peeping into the device with a violation of the "black box principle" of device ontology. B3 behavior is defined as any behavior to another device. The important aspect here is that B0 and B1 behaviors are concerned with operands rather than devices. All these definitions share the notion that behavior is a conceptualization of the change of attribute values in spatio-temporal space over time. The differences come from the way the location in the spatio-temporal space is treated and the target of the operation to be interpreted as behavior. A function of a device is defined as the teleological interpretation of B1 behavior in pursuit of a given goal. This gives that a function of a device is context-dependent while B1 behavior is constant independent of the context. Considering that, in most cases of design, the context of a device is determined by the goal to be achieved by the device, the function of a device is determined goal- or purpose-dependently. This reflects the reality that definition of function tends to be context dependent and hence, in many cases, functional knowledge is hardly reusable.

Figure 48: Hierarchy of a power plant target object (Kitamura & Mizoguchi, 2004).

Figure 48 shows a structure-behavior-function hierarchy. Structure here means topological relations among components (devices). The structure of a device constitutes a hierarchical structure according to the grain size, which is shown in the lowest plain in Figure 48. Behavior means B1 behavior. What is obtained by a teleological interpretation of B1 behavior under a given goal is called (base) function. The term "base" is used to discriminate it from meta-function. A function is achieved by performing (achieving) a series of sub-functions, which is called a method of function achievement. On the other hand, a conceptualization of the principle or intended phenomenon or structure that gives justification for why and how the method achieves the function is called way of function achievement and is considered as the reference to the essential property of the structure and behavior that achieve the function. Note that whole-part hierarchies in the different layers do not always correspond to each other. Although the typical functional structure is one analog to the structural hierarchy, it could have many other different hierarchies according to the viewpoint to organize functional components. Meta-function is a conceptualization of a type of a base function and inter-dependency between them. While a base function is concerned with the change of operands in the domain, meta-function is concerned with base functions. Meta-function as inter-dependency between base functions is defined as a teleological interpretation of causal relation between base functions. Kitamura et al. (2004) provide a description of an approach to computer implementation of a design support tool based on the framework described above.

Continue ...

Go to table of contents.