School of Computer and Applied Sciences. Georgia Southwestern State University ... paradigm is the automotive industry, where many products change only ...
IEEE Transactions on SMC
A Formalism for Modeling Engineering Design Processes Jeong-Soo Ahn Department of Mechanical Engineering The University of Texas at Austin Srinivasan Ramaswamy School of Computer and Applied Sciences Georgia Southwestern State University Richard H. Crawford Department of Mechanical Engineering The University of Texas at Austin ABSTRACT This paper presents a mathematical and graphical formalism for modeling computational engineering design processes, particularly to enhance variant product design in industries. The proposed modeling formalism provides a methodology for transforming a textual problem statement into a mathematical, parametric model. The explicit representation of the designer’s solution strategy is also formalized. Petri net theory provides a framework for developing a graph-theoretical tool for representing the parametric process model. The parametric process model is formally interpreted in terms of atomic process units, called design actors.
The
assembly of design actors according to their data dependencies results in a directed graph, called a design actor network, whose execution produces a promising solution (or solutions) to the problem. The dynamic behavior of a design process is investigated by the simulation of a design actor network. This modeling formalism is demonstrated with a simple example of caliper disc brake design for an automotive application. 1.
Introduction Engineering design in many industries is variant in nature, consisting primarily of
incremental changes not only to an existing ‘reference’ product, but also to the process by which it has been realized. A good example of an industry that operates largely in this variant design
1
Ahn, Ramaswamy and Crawford
IEEE Transactions on SMC paradigm is the automotive industry, where many products change only slightly from year to year. However, most commercial computer-aided design (CAD) systems do not fully support such variant design, since they only represent completed products, to the exclusion of the design process (for example, [4]). That is, the representation in such systems is focused on what the product is, particularly details and documentation of the geometry of the design product, but not on how the designer creates the product. Moreover, most efforts in the design theory and methodology research communities have provided no methodology for guiding the representation of the how. One key to successful variant design is the explicit representation of a design process for a reference product [15]. This will enable efficient management of modifying the process and documenting variant designs for later use. This paper illustrates a formal representation of a computational design process (CDP) that captures the how of variant design. A CDP is defined as a sequence of computational tasks that, when executed, produces a promising solution (or solutions) to a design problem.
That is, a CDP is a procedural
representation of engineering design in the parametric design paradigm [7, 9]. The proposed formalism is based on Petri net theory, which has been popularly used to provide a mathematical background and methodology for system modeling, representation, simulation and analysis in the fields of computer science, management information systems and manufacturing systems. We have adapted Petri net theory for CDP modeling with extensions to represent data dependencies between computational tasks, decisions and iterations in design processes. The proposed formalism provides the designer with a methodology of representing a textual problem statement and associated solution process as a parametric, mathematical process model [2, 11]. Atomic tasks in the model are identified and interpreted in terms of independent computational units, called design actors (DAs), and data dependencies among the DAs. The designer’s solution strategy is also explicitly represented in terms of DAs, resulting in a directed graph, called a design actor network (DA network). The execution of a DA network produces a promising solution (or solutions) to the problem.
2
Ahn, Ramaswamy and Crawford
IEEE Transactions on SMC The rest of this paper is organized as follows. In Section 2, Petri net theory is briefly reviewed. In Section 3, which is the key section of the paper, CDP modeling with DAs is presented. Simulation of the dynamic behavior of a CDP is discussed in Section 4. Section 5 presents an example to demonstrate the proposed formalism. Section 6 concludes the paper. 2.
Petri Net Theory Petri nets have been used as mathematical, graphical tools for modeling and analyzing
information processing systems whose dynamic behaviors are characterized by concurrency, synchronous, distributed operations, conflicts due to decisions, and non-determinism [12]. A basic Petri net structure consists of places and transitions interconnected by directed arcs. Places are denoted by circles and represent conditions, while transitions are denoted by bars and represent events. The directed arcs in a Petri net represent flow of control; the occurrence of events is controlled by a set of conditions. For example, the translation of a flowchart to a Petri net is illustrated in Figure 1, where the nodes of the flowchart are replaced by transitions and the arcs by places in the Petri net with program counter interpretation. p1 A
Read a, b, c
A D
B a >0
F
p2
Write c
T
C
C
a = a− 1 c = b⋅ a
B.T p3
B.F p4
D
p5
Figure 1: A Petri net representation of a program. In addition to its graphical structure, a Petri net is effectively used to simulate the dynamic behavior of the modeled system in terms of states (or markings) and their changes during execution. A marking is an assignment of tokens to the places, where a token denotes that the corresponding condition is true. Thus the marking of places describes the current state of the Petri net in terms of the conditions that are true and those that are false. The Petri net
3
Ahn, Ramaswamy and Crawford
IEEE Transactions on SMC execution changes the number and location of tokens according to the rule of transition enabling and firing [10]: (1) a transition t is enabled if each input place p is marked with w(p,t) tokens, where w(p,t) is the weight of the arc from p to t; (2) an enabled transition may or may not fire (depending on whether or not the event actually takes place); and (3) an enabled transition t is fired by removing w(p,t) tokens from each input place p and adding w(t,p) tokens to each output place p. Figure 2 shows a marking evolution by firing a transition in Figure 1. Since the places in the figure can be interpreted as program counter locations, a token residing in a place denotes that the current instruction is ready to execute. For example, a token in the place p1 means that the program counter is positioned to execute the transition A; the firing of the transition A moves the program counter by depositing a token in the place p2 and removing the token in the place p1, as shown in Figure 2. p1
p1
A
A Firing A
p2 C
B.T p3
p2 B.F p4
C D
p5
B.T p3
B.F p4
D
p5
Figure 2: Marking evolution due to a transition firing. Petri nets can also be formally analyzed to evaluate the structural and behavioral properties of the modeled system, which serves to influence future revision of the modeled system and thus hopefully leads to an improved system. One basic disadvantage related to the applicability of Petri nets for the modeling and analysis of complex systems is the problem of state-space explosion. Even for a moderately sized system, exploring the state space of a Petri net based on exhaustive simulation of the possible marking evolution makes the Petri net model unreasonably complex to be analyzed. In this research, this state-explosion problem is addressed
4
Ahn, Ramaswamy and Crawford
IEEE Transactions on SMC by defining a DA network as being safe from the viewpoint of Petri nets, where the term ‘safeness’ denotes that the number of tokens on each place cannot exceed one [6]. Petri nets are also used to represent the flow of data in a system by modeling instructions or computational steps as transitions and operands as places. Tokens denote the current values as well as the availability of data for corresponding operands. A special type of transition, called a duplicator [3], is defined to specify explicitly the data flow between operands and instructions by duplicating an incoming token and emitting its copies over outgoing arcs to corresponding transitions. Some extensions have been directed at increasing Petri net modeling power. The definition of inhibitor and activator arcs [13, 14, 18] are directed towards decreasing some types of complexities involved in modeling decision making processes. In our research, the concept of using duplicators is adapted to model explicit data dependencies among DAs, and the activator arc extension is adapted to model the concept of refresh arcs in any DA network. We claim that Petri net theory provides a formal foundation for modeling a CDP and describing its computational behavior, for the following reasons: (1) The computational behavior of a CDP is also characterized as parallel, synchronous, distributed, conflicting, and nondeterministic (or iterative); (2) The structure of a DA network can be equivalently interpreted as a Petri net; and (3) The dynamic behavior of a CDP can be described by Petri net analysis techniques. Our approach to adapting Petri net theory for representing CDPs is described in the next section. 3.
Formal CDP Representation with Design Actors This section presents a graph-based, mathematical CDP modeling tool. The formalism
provides the designer with a methodology for parametric problem modeling and explicit representation of the associated solution process. 3.1
Design Actor Context — Parametric Model of a Problem Statement Engineering design can be described as the transformation of a design problem, stated in
terms of specifications and functional requirements, into a complete description of a desirable
5
Ahn, Ramaswamy and Crawford
IEEE Transactions on SMC product that fulfills the customer’s primitive needs. In particular, parametric design, the focus of this work, involves (1) establishing performance criteria as functions of design parameters and variables, (2) simulating (or testing) proposed designs to understand the relationships among the design variables and performance measures, and (3) the evaluation of constraints. The process consists of (usually) iterative cycles of posing values for design variables, and predicting performance (or testing performance) and evaluating constraints. To predict performance by simulation requires a mathematical model. The development of a mathematical model of a problem statement necessitates a formal representation of constraints and functional requirements as well as the attributes and properties of a product and its environment. Specifications are statements of the designer’s demands or wishes for a design solution to the problem: demands are requirements that must be met under all circumstances; wishes are requirements that should be taken into consideration whenever possible [11].
The designer’s demands are formally described as constraints.
Functional
requirements are the designer’s characterization of the desired behaviors of a product [17]. Important attributes and properties of a product are identified and represented in terms of design parameters or variables.
These design parameters are used to describe the functional
relationships between specified functional performance and the attributes, and thus to represent a mathematical model that anticipates the behavior of a final product. Our proposed modeling formalism focuses on parametric modeling of a product [5] and is based on a design actor context (DA context), formally defined as follows: Definition 1.
(DA Context). A DA context, Ω, is defined as a parametric model of a given
parametric problem statement and consists of a tuple Ω = (Α,Φ), where Α denotes a set of design parameters or variables, and Φ defines a set of mathematical relationships between design parameters or variables defined in Α. Definition 2.
(Design parameters and variables) The set Α in Ω is decomposed into three
disjoint sets: applied parameters (Q), design variables (X) and derived parameters (D). Applied parameters represent the attributes and properties of a product and its environment 6
Ahn, Ramaswamy and Crawford
IEEE Transactions on SMC whose values are fixed and unchanged during the execution of the design process. Design variables are the primary attributes of a product that must be determined. Their computational behavior is formally defined as iteration. That is, a design variable must converge iteratively on a final value which best satisfies given performance requirements without violating the constraints. Derived parameters are secondary attributes or performance measures that are defined as mathematical functions of the elements in Q, X, and D. Definition 3.
(Functions and constraints) The set Φ in Ω is decomposed into functions F
and constraints C. A function is defined as a quadruple (fn,I,eval,o), where fn is a unique function name, I is a set of input parameters, eval is a functional expression of how the output value is computed, and o ∈D is an output parameter.
A constraint is defined as a triple
(cn,I,eval), where cn is a unique constraint name, I is a set of input parameters, and eval is a conditional expression in a form of predicate. Constraints are special functions that limit the search for a design solution in the solution space. In addition, the designer’s desire for satisfactory performance of a product may be imposed on a problem statement, and must be formally represented in a mathematical model. In a DA context, the desired functionality and performance level is formally modeled as a design goal. A design goal is typically a statement (or labeled function) rather than a simple function in the sense that it indicates the designer’s preference for product performance, where the ‘label’ indicates a desired direction to search for a promising solution in the solution space. A measure of a product’s performance is called a performance indicator. Definition 4.
(Design Goal). A design goal G is defined as a tuple (gn,Minimize d) or
(gn,Maximize d), where gn is a unique design goal name and d ∈D is a performance indicator. A design goal models the designer’s preference for the final product with respect to performance levels, and thus it is described as a statement rather than a function. In our research, a design goal is formally modeled as either ‘minimization’ or ‘maximization’ of a performance indicator. The DA context provides a framework for formalizing the transformation of a problem statement into a mathematical model: parametric modeling, explicitness of specifications, 7
Ahn, Ramaswamy and Crawford
IEEE Transactions on SMC functional requirements and the designer’s desire for a satisfactory solution. The structure of a DA context implies a general iterative approach to design: “Given Q, find values for X which best satisfy G without violating any of C”. 3.2
Methodology for DA context Modeling In this section, a methodology for translating a textual problem statement into a DA
context is presented. The methodology provides a step-by-step approach to the parametric problem modeling. The methodology for constructing a DA context for given design problem consists of four steps: Identify attributes of a product and its environment. Important attributes of a product and its environment must be first identified and selected as the known attributes, unknown attributes and derivable attributes. These identified attributes are categorized into three different sets: applied parameters (Q), design variables (X) and derived parameters (D). Represent functional requirements for a product. Once design entities in Q, X and D are established, the designer must represent required functions for the product. Functional requirements are represented by modeling properties and behaviors of a product as functions (F) between design entities. This is equivalent to the declaration of functions F in a DA context. Represent the designer’s demands for a product. The designer is also required to represent the demands for the product that must be invariably satisfied. Among them are the limits on allowable values for X and D, such as spatial restrictions on the product, decisions on available resources for energy and material, etc. These demands are formally represented as constraints C in a DA context. Constraints are in the form of predicates, including the usual equalities and inequalities, and are represented in terms of design entities in Q, X, and D. Represent the designer’s wishes for a product.
8
Ahn, Ramaswamy and Crawford
IEEE Transactions on SMC The designer's wishes for desirable behavior or functionality of a product are represented as design goals G in a DA context. A desirable behavior of a product is represented as a performance indicator that is a derived parameter. 3.3
A DA Context Modeling Example A simple design example is used to illustrate the DA context modeling methodology.
The problem, taken from [16], is the design of a caliper disc brake for automotive applications. The problem is textually stated as follows: “Caliper disc brakes first came into their own on European cars, the first applications being on competition and sports cars where their superior fade resistance and stability were particularly significant. The first problem encountered in adapting them to American cars was the greater weight of American cars as compared to European cars. This requires either much higher lining pressure or higher effective brake radius. But wheel rim configurations and space restrictions are assumed, and will represent constraints on the design for maximum effective brake radius.
A floating caliper disc brake system is to be designed for
minimization of stopping time.” The given problem statement is formally transformed into a DA context according to the proposed methodology. For the design and analysis, the following assumptions are made about disc, lining, heat dissipation and energy absorption as follows [16]: 1. The disc is planar and solid. 2. The heat dissipated is due to a single stop and is totally stored in the disc. 3. The caliper disc brake is floating to prevent bending stresses on the disc. 4. The lining is circular. 5. The energy to be absorbed is uniformly distributed on all brakes. Table 1 shows a DA context, resulting from the application of the modeling methodology to the given problem statement. The following describes the step-by-step approach to construct a DA context. Step 1. Identification of Q, X, and D. 9
Ahn, Ramaswamy and Crawford
IEEE Transactions on SMC The configuration and specifications for caliper disc brake system must be established by identifying parameters or variables for describing the brake system. Details for the vehicle and its environment such as vehicle weight (W), speed (V), and tire radius (Rt), are identified as known attributes. The configuration for the pressure cylinder, disc and lining (ex: piston diameter (Dp), disc diameter (D), etc.) are given as input specifications. Lining diameter (d) and oil pressure (po) are identified as design variables whose values must be determined to satisfy minimum stopping time. Other parameters such as braking torque (Q) and stopping time (Ts) are identified as derived parameters for representing the behaviors of the brake system. Step 2. Representation of functional relationships F between Q, X and D. The properties and behaviors of the brake system are represented by establishing functional relationships between Q, X and D. For design purposes, for example, braking torque (Q) is derived with the assumption of uniform wear: pr = constant, where p is local lining pressure at any radius of the disc, r. Step 3. Representation of constraints C in terms of Q, X and D. In the example, five constraints are required due to configuration restrictions on the lining, specifications for maximum oil and lining pressure, the heat capacity of disc and a constraint against skidding. All of these are expressed as inequalities in terms of elements of Q, X and D. Step 4. Representation of design goals G. The design criterion, as stated in the given problem, is to minimize stopping time. Thus one design goal is represented as the minimization of stopping time with the derived parameter Ts for stopping time as the performance indicator.
10
Ahn, Ramaswamy and Crawford
IEEE Transactions on SMC Table 1. A DA context — parametric modeling of given problem statement. 1. Applied parameters (Q) name description value W vehicle weight per wheel (lb) 750 Rt tire radius (in.) 14 Dp piston diameter (in.) 2.0 a disc thickness (in.) 0.3 radius of lining centerline (in.) 4.5 R max max. lining diameter (in.) 2.0 d max po max. oil pressure (psi) 1000 g gravity acceleration (ft/sec2) 32.2 specific heat of disc (Btu/lboF) 0.12 c 2. Design Variables (X) name description d diameter of lining (in.) 3. Derived parameters (D) name description F total force on the disc (lb) pmax max. lining pressure (psi) braking torque (lb-in.) Q kinetic energy (lb-ft) E initial rpm of disc (rpm) N 4. Functions (F) name inputs f1 D, po F = π D2 po / 4 R+0 . 5 d f2 R, d −1
I1 =
∫
4 tan
name V D T pumax dmin µ µt ti ρ
description vehicle speed (mph) disc diameter (in.) max. disc temperature (oF) max. lining pressure (psi) min. lining diameter (in.) friction coef. at lining and disc friction coef. at tire and road ambient temperature (oF) mass density of disc (lbm/in3)
name po
oil pressure (psi)
name I1 I2 Qs tf Ts
description dummy parameter 1 dummy parameter 2 skidding torque (lb-in.) final temperature of disc (oF) stopping time (min.)
value 60 11.5 500 400 1.8 1.0 1.0 95 0.28
description
evaluator
( d4 − ( R− r ) 2 ) (( R+ r )2 − d4 ) dr 2
2
output F I1
R-0. 5d
f3 f4
F, I1, R, d I1, R, d
pmax = F / I1 (R - 0.5 d) I2 =
∫
R+ d/ 2
R-d / 2
4r I1
pmax
tan −1 ( d4 − (R − r ) 2 ) (( R+ r ) 2 − 2
2
d 4
) dr
I2
f5 f6 f7 f8
µ, F, I2 W, µt, Rt W, V, g E, c, ρ, D, a, ti
Q = 2 µ F I2 Qs = W µt Rt E = W V2 / 2 g tf = 4 E / 778 π c ρ D2 a + ti
Q Qs E
f9 f10
V, Rt
N = 528 V / π Rt Ts = E / 2 π µ F I2 N
N Ts
µ, F, I2, N, E 5. Constraints (C) name description c1 limit on lining diameter c2 limit on oil pressure c3
inputs dmin, dmax, d pomax, po pumax, pmax
limit on lining pressure
c4 c5
limit on heat capacity of disc constraint against skidding 6. Design goals (G) name description g1 minimize stopping time
T, tf Q, Qs performance indicator Ts
11
tf
evaluator ≤ d ≤ dmax po ≤ pomax pmax ≤ pumax tf ≤ T Q ≤ Qs dmin
evaluator Minimize Ts.
Ahn, Ramaswamy and Crawford
IEEE Transactions on SMC 3.4
Definition of Design Actors The DA context model provides an abstract representation of a product in terms of a
subset of its attributes, and a partial description of the process in terms of functional dependencies among its attributes, constraints and goals in a declarative manner describing ‘what’ a product should be. In order to produce a solution, a mechanism must be provided to transform this declarative model of design into a corresponding procedural representation of design that can be executed to assign values to the parameters in the mathematical model. In this research, design entities and functional relationships among them in a DA context are modeled by independent computational units, called design actors (DAs).
Design
procedures and decisions made during the process as well as computer-aided engineering (CAE) tools and programs are also explicitly modeled by DAs. Several different types of DAs are defined to translate a DA context and the associated solution process according to their computational behaviors. The structure of a CDP is represented as a set of DAs and their data dependencies; that is, a CDP is represented as the assembly of different DAs according to their data dependencies. Definition 5.
(Design Actors). A design actor (DA) is an atomic process unit; a CDP is
described as a set of DAs which are assembled according to their input and output relations. DAs are categorized into two disjoint sets of parameter actors and task actors according to different functional characteristics: a parameter actor stores design information, and a task actor manipulates design information. Definition 6.
(Parameter Actors). Each parameter actor is an ordered tuple defined by (p,r),
where p is a unique parameter actor name, and r is its current value. A parameter actor is defined to model a design entity in Q, X and D of a DA context. It stores data or control information, and if available, the value is referenced by task actors, as defined below. Knowledge resources which provide design data and information in a CDP are also explicitly represented as parameter actors.
12
Ahn, Ramaswamy and Crawford
IEEE Transactions on SMC Definition 7.
(Task Actors). A task actor is defined as a quadruple (t, I, eval, O), where t is a
unique task actor name, I is a set of input parameter actors, eval denotes the computational behavior of the task actor, and O is a set of output parameter actors. Task actors are defined to model functional relationships, such as functions and constraints, among design entities in a DA context, and computational tasks for design procedures and decisions in a solution process. Task actors are classified into mapping actors, copying actors and branching actors according to their unique computational behaviors. The following describes their different definitions. Definition 8.
(Mapping Actors).
A mapping actor is defined to represent a functional
mapping of one or more inputs to a single output (MISO). The structure of a mapping actor is a four tuple (t, I, fun, O), where t is a unique mapping actor name, I is a list of input parameter actors, fun is a functional expression in terms of multiple input parameters, and O is its single output parameter actor. A DA context may have design entities which are referenced by two or more functions or constraints. There are also cases where multiple computational tasks share the same resources. This kind of dependency is called resource dependency [8]. In DA modeling, the resource dependency complicates the simulation of the dynamic behavior of a CDP (described in Section 4) due to combinatorial explosion of the state space of the DA network. This dependency can be removed by the concept of duplicating the shared resources and specifying each dependency independently. In this research, a copying actor, adapted from dataflow computation modeling by Petri nets, is defined to address the state-space explosion problem. Copying actors are used in interpreting a DA context in terms of DAs by duplicating design entities referenced by multiple functions or constraints. Definition 9.
(Copying Actors). A copying actor is defined as a quadruple (t, I, dup, O),
where t is a unique copying actor name, I is a single parameter actor to be duplicated, dup denotes the task of duplicating an incoming actor into multiples (SIMO), and O is a list of parameter actors, whose names are uniquely defined, but whose values are exactly the same as the incoming actor. 13
Ahn, Ramaswamy and Crawford
IEEE Transactions on SMC Definition 10.
(Branching Actors). A branching actor is defined as a four-tuple (t, I, con,
O), where t is a unique branching actor name, I is a list of input parameter actors, con is a conditional expression in terms of input parameters, whose evaluation result is always control signals (e.g., the Boolean result), and O is a list of a special type of parameter actors, called semaphore actors, as defined below. Branching actors represent statements in the form of predicates which evaluate to truth values. A branching actor evaluates a conditional expression and selects a task based on the evaluation result. For example, the Boolean result of either true or false is bound to the corresponding semaphore actor. Definition 11.
(Semaphore Actors). A semaphore actor is a special parameter actor that
models a decision predicate. A semaphore actor does not participate in a DA context modeling, but is used to model the control flow from a branching actor. The definition of a semaphore actor ensures that a DA network is structurally equivalent to a Petri net, and thus Petri net analysis techniques can be used to simulate the dynamics of a DA network. For example, if a mapping actor evaluates to a Boolean result, two semaphore actors are defined to represent control flows of ‘truth’ and ‘falseness’ such that either the truth or falseness is bound to corresponding semaphore actor. 3.5
Design Actor Structure and Design Actor Network Interpretation of a DA context and the associated solution process in terms of DAs
provides the structure of a CDP. The structure of a CDP is formally represented as a design actor structure (DA structure), which is defined by a set of parameter actors, a set of task actors, input functions and output functions. Definition 12.
(DA structure). A DA structure S is a four-tuple: S = (P, T, I, O), where P is
a finite set of parameter actors, T is a finite set of task actors, and I and O are sets of input and output functions of DAs, respectively. The sets of parameter actors and task actors are disjoint, P ∩ T = ∅ . The input and output functions of a parameter actor p ∈P are mappings from p to a
14
Ahn, Ramaswamy and Crawford
IEEE Transactions on SMC set of task actors, while those of a task actor t ∈T are mappings from t to a set of parameter actors. Each element in a DA context Ω=(Α,Φ)=({Q,X,D},{F,C,G}) is modeled as a DA. A parameter actor models an element Α=(Q,X,D) in Ω. Elements Φ=(F,C,G) in Ω as well as design procedures and decisions in its solution process are modeled in terms of task actors and input/output functions which represent data dependencies between DAs. The input function of a parameter actor p ∈P denotes a set of task actors that define its value, while its output function defines a set of task actors that reference its value. The input function of a task actor t ∈T describes the set of parameter actors whose values are referenced by t. The output function of a mapping actor is given as a single parameter actor whose value is defined by the mapping actor, while the output function of a branching actor is defined by a set of two or more semaphore actors, each of which stores the evaluation result of the conditional expression defined in the branching actor. A DA structure is equivalently represented as a directed graph, called a design actor network (DA network), to allow the topology of its structure to be readily verified. Corresponding to a DA structure, a DA network has two main types of nodes, represented by circles and rectangles. A circle represents a parameter actor, while a rectangle represents a task actor. A semaphore actor is represented by a double circle to distinguish its computational behavior from other parameter actors. Directed arcs represent data dependencies between DAs; arc directions are either from the parameter actors to the task actors or from task actors to parameter actors. An arc directed from a parameter actor p to a task actor t defines the parameter actor to be an input of the task actor (say, input actor). An output actor is indicated by an arc directed from the task actor to the parameter actor. Since the nodes of the network can be partitioned into two disjoint sets, such that each arc is directed from an element of one set (parameter or task actor) to an element of another set (task or parameter actor), the DA network is a bipartite directed graph.
15
Ahn, Ramaswamy and Crawford
IEEE Transactions on SMC Definition 13.
(DA network). A DA network N is a bipartite directed graph, N=(V, E),
where V={v1,v2, ⋅⋅⋅ ,vm} is a set of nodes and E={e1,e2,
⋅⋅⋅,e } is a set of directed arcs, e =(v , n
i
j
vk), with vj, vk ∈V. The set V can be partitioned into two disjoint sets of parameter actors and task actors, as defined in the DA structure, such that V=P ∪ T, P ∩ T= ∅ , and for each directed arc, ei ∈E, if ei=(vj, vk), then either vj ∈P and vk ∈T or vj ∈T and vk ∈P. 3.6. Interpretation of a DA context with DAs The procedural representation of design involves four main steps: (1) the interpretation of a DA context; (2) the explicit representation of the associated solution process, (3) the explicit representation of iterations in a CDP, and (4) the execution of the CDP to generate a solution to the problem. This section deals with the formal interpretation of a DA context in terms of DAs, resulting in a DA structure and corresponding DA network.
This formalism provides the
semantic and syntactic interpretation of the elements in a DA context. Applied Parameters The value of an applied parameter q ∈Q does not change throughout the execution of a CDP. Thus its computational behavior is modeled as a parameter actor p ∈P that has no incoming arcs, and one outgoing arc to represent the reference of its value by other task actors; i.e., I(p) = ∅ . In particular, the parameter actor that models an applied parameter in a DA context is called a source actor. Figure 3 illustrates the interpretation of the applied parameter Dp=2.0 in. in Table 1 as a source actor in a DA network, and the reference of its value by the mapping actor f1. f1
I(Dp ) = ∅ O(Dp) = {f1 }
(Dp ,2.0 in.)
Figure 3: Interpretation of an applied parameter as a source actor. Another example of referencing a source actor by two or more task actors is illustrated in Figure 4, where the applied parameter W=750 lbs in Table 1 is referenced by both mapping actors f6 and f7. The source actor W is duplicated by the mapping actor cw into two parameter actors W1 and W2 , each of which is referenced by f6 and f7, respectively.
16
Ahn, Ramaswamy and Crawford
IEEE Transactions on SMC (W,750 lbs)
c
w
(W1 ,750 lbs) f6 I(W) = ∅ O(W) = {f 6,f7 }
(W2,750 lbs) f7
Figure 4: Reference of a source actor by multiple task actors. Design Variables Since a design variable x ∈X represents a characteristic attribute of a product, some computational tasks are required to determine its value. As mentioned in Section 3.1, a design variable is characterized to be iterative so that it converges iteratively on a final value until the design goals are best satisfied with no constraint violations. The iterative nature of a design variable necessitates the following two types of computational tasks: initialize its value and update its value whenever needed. However, the value of a design variable is unspecified in the DA context model, since the strategy for determining its value is missing. Thus the above two computational tasks are not established in the DA context.
Like an applied parameter, a design variable can also be modeled as a parameter actor. However, there is a significant difference in their semantics due to different computational behaviors: an applied parameter is not changed throughout the process, while a design variable is initially undefined so that methods are necessary to initialize and update its value. Figure 5 illustrates the syntactical and semantic interpretation of a design variable d, which is referenced by the functions f2, f3, f4 and c1 in Table 1, in terms of DAs. The design variable d is modeled as the parameter actor whose name is d. The mapping actor m1 initializes d; m2 redefines its value during iteration. References to d by mapping actors f2, f3, f4 and c1 are represented by copying its value to duplicate parameter actors through the copying actor cd and modeling the corresponding data flows to them.
17
Ahn, Ramaswamy and Crawford
IEEE Transactions on SMC
d4
c1
d2 f3
d
cd
initialize d
I(d) = {m1 , m2 } O(d) = {f2, f3, f4, c1}
f2 d1 f4
update d d3
Figure 5: Syntactic and semantic interpretation of a design variable. Derived Parameters Like an applied parameter and a design variable, a derived parameter d ∈D is also modeled as a parameter actor. The value of a derived parameter is computed by evaluating a functional mapping of the inputs to d. The mapping function is modeled as a mapping actor. The derived parameter may be referenced by other tasks; i.e., the parameter actor for a derived parameter may or may not have an outgoing arc. If there is no outgoing arc, then the parameter actor is called a sink actor with O(d)= ∅ .
Figure 6 illustrates the interpretation of the
computational behavior of a derived parameter Qs in Table 1.
In the figure, the derived
parameter Qs is modeled by the parameter actor whose name is Qs. The computation of its value is defined by the mapping actor f6, and the arc (Qs,c5) models the reference of Qs by the branching actor c5. f6
Qs
I(Qs) = {f6} O(Qs) = {c5} c5
Figure 6: Interpretation of the computational behavior of a derived parameter. Functional Mappings A function, f:(p1 × p2 × ⋅⋅⋅ × pn) → d, that maps multiple inputs pi ∈Α (i=1,2,
⋅⋅⋅,n) to a
single output d ∈D is modeled as a mapping actor. The structure of a function (fn,I,eval,o) in a
18
Ahn, Ramaswamy and Crawford
IEEE Transactions on SMC DA context is formally interpreted into a DA structure and corresponding DA network as follows: •
A function is modeled as a mapping actor f.
•
fn is interpreted as the unique name of f to be modeled.
•
Each element in I is modeled by a corresponding parameter actor and is given as an input
actor to f; i.e., I(f)= . Each input actor is connected by an input arc to f, along which its current value is referenced by f. •
eval is defined as the evaluator of f and is a functional expression for computing an output.
•
o is modeled as the corresponding parameter actor for either a derived parameter or a design variable, and is an output actor to f, i.e., O(f)=o. An arc connects f to this parameter actor; the computed value is bound to the output actor as its current value.
Figure 7 illustrates the interpretation of the function f8 in Table 1 into a corresponding DA network. E
c
4E
778πcρD 2a
f8 + ti
tf
ρ
I(f8 ) = {E, c, ρ, D, a, ti } O(f8) = {tf}
ti D
a
Figure 7: An interpretation of a functional mapping into a DA network. Constraints Unlike functions, constraints are generally represented as statements in the form of predicates with multiple inputs pi ∈Α (i=1,2, ⋅⋅⋅ ,n), and they evaluate to a truth value of true or false. The structure of a constraint (cn,I,eval) in a DA context is formally interpreted as a DA structure and corresponding DA network as follows. •
A constraint is modeled as a branching actor c.
•
cn is interpreted as the unique name of c.
•
Each element in I is modeled as an input actor to c; i.e., I(c)=I.
19
Ahn, Ramaswamy and Crawford
IEEE Transactions on SMC •
eval is defined as the evaluator which is expressed in the form of a predicate inside c.
•
Since the evaluator returns either true or false, but not both, there is no need to define a parameter actor d ∈D for its output. Instead, two semaphore actors are used to hold these truth values. Based on the evaluation result, the branching actor binds either the true or false value to corresponding semaphore actor.
Figure 8 illustrates the interpretation of a constraint c3 in Table 1 into corresponding DA network according to the above interpretation rule. pumax
pmax
I(c3 ) = {pmax, pumax} O(c3) = {c3:T , c3 :F}
c3 c3:T
c3:F
Figure 8: An interpretation of a constraint into a DA network. Design Goals As stated in Section 3.1, the designer’s desire for satisfactory performance or functionality of a product is formally modeled as a design goal in a DA context. A design goal is typically described as a statement rather than simply a function, i.e., a statement that indicates the desired product behavior. In this research, a design goal is formally stated as “the designer wants to minimize (or maximize) a performance indicator”. For example, the desire for the most uniform gear chain is modeled as “maximize the uniformness of the gear chain”. The structure of a design goal (gn, Minimize g) or (gn, Maximize g) and its computational behavior are formally interpreted into a corresponding DA network in the following way, where g represents a performance indicator g ∈D. • Since g is given as a derived parameter, it is modeled as a parameter actor, as described above.
20
Ahn, Ramaswamy and Crawford
IEEE Transactions on SMC • Either “minimize g” or “maximize g” implies that a comparison criterion must be provided to compare the current value of g with the previous best one, and select the best solution among many feasible solutions. • The comparison is formalized in the form of a predicate, and thus modeled as a branching actor whose name is uniquely given as gn. • Like the modeling of a constraint as a branching actor, two semaphore actors are modeled to hold the comparison result. Figure 9 illustrates the interpretation of a design goal (g1, Minimize Ts) in Table 1 as a DA network according to the above interpretation rule. In this figure, the goal’s computational behavior implies the definition of a parameter actor Tsbest to store the previous “best” value of Ts and comparison of the values of Ts with Tsbest. g1 Tsbest
Minimize T s
g1:T
Ts
g1:F
I(g1 ) = {T s, T sbest} O(g1) = {g1:T , g1:F}
Figure 9: An interpretation of a design goal into a DA network. 3.7
Explicit Representation of a Solution Process As described above, a DA context provides a declarative representation of the attributes,
properties and behaviors of a product as well as specifications, functional requirements and the designer’s wishes for the product, in terms of design parameters or variables, and functional dependencies among them. A DA context provides a partial description of the process by which the deterministic relations among DAs are represented; that is, derived parameters, constraints and design goals are evaluated from given applied parameters and design variables. However, an important aspect of a CDP is missing in a DA context: the strategy for controlling the generation of solutions towards satisfaction of the design goals. Representation of this strategy consists of explicit declaration of decisions to be made as the CDP is executed, and procedures for initializing and updating the design variables to achieve improved performance.
21
Ahn, Ramaswamy and Crawford
IEEE Transactions on SMC A CDP is composed of a set of distinct design procedures and decisions, and how they are combined determines the structure of the CDP. Among such tasks are simple functional mappings, as described before, access to CAE tools, data retrieval from databases, etc. In particular, the designer must make decisions about shape, material properties, manufacturing technologies, control of a CDP execution, etc., based on information provided by handbooks and standards, numeric analyses (e.g., finite element analysis), company policy, personal expertise, and solution strategy. Therefore, it is necessary to formally represent design procedures for manipulating knowledge resources and decision making. Modeling of Design Procedures In modern design, much knowledge is employed to solve complex design problems. This knowledge has different forms including computer programs and databases. Information must be shared among these resources during the execution of a CDP.
However,
communication between knowledge resources causes integration problems, since knowledge resources are typically not designed to communicate with each other, but are written as standalone programs. To reduce such communication problems, a uniform interface mechanism must be developed to provide an environment for utilizing engineering resources while maintaining their integrity. In our research, design procedures can be described abstractly as the design tasks for manipulating knowledge resources, consisting of the following three subtasks: reference inputs for the associated knowledge resource; evaluate the resource; define the necessary output information. These three subtasks can be formally modeled as a mapping actor, since its structure (fn,I,eval,o) provides the interpretation of these subtasks in one abstraction. The first subtask ‘reference’ can be performed by preparing I, eval represents the second subtask ‘evaluation’, and the third subtask ‘definition’ is modeled by o. For example, consider that a magnetic force analysis program is used to characterize the radial force generated by an air-core solenoid in the design of an optic disk driver [1]. Execution of this program requires a sequence of the following three tasks: preparing an input
22
Ahn, Ramaswamy and Crawford
IEEE Transactions on SMC file for the geometry of solenoid shown in Figure 10, executing the program, and retrieving the value of maximum radial force (Frmax) from the output file. z d
magnet
d x n layers
Agap r solenoid coil
d x m turns
Ri
Ro
Figure 10: Geometry of a solenoid coil. Figure 11 shows a DA network for modeling these procedures. The program, input file and output file are modeled as parameter actors, named Fcode, Infile and Outfile, respectively. Design tasks for preparing input file, running the program and retrieving the value of Frmax are modeled by mapping actors named Input-maker, Force-actor and File-reader, respectively. n
m
Ro
Ri
d Agap
Prepare input file
i
Input-maker Force-actor
Infile
Fcode
Run the program
Outfile
Retrieve F rmax from input file
F rmax
File-reader
Figure 11: An interpretation of a design procedure into a DA network. Modeling of Decisions During the design process, many decisions are made to direct process execution. However, these decisions may cause conflict in sequencing computational tasks. In our research, decision actions are formally expressed as “conditional selection statements” in a mathematical notation. Conflict resolution can be controlled by testing the conditional expression of the decision and forcing a correct computational task to fire.
A decision is formalized as a
(multiple) branch selection statement, IF-THEN-ELSE or SWITCH-CASE statement as follows: IF exp THEN s1 ELSE s2
for binary branching or, 23
Ahn, Ramaswamy and Crawford
IEEE Transactions on SMC SWITCH exp (...,case vi si,...)
for multiple branching.
These selection statements serve as selectors in the following sense: let si (i=1,
⋅⋅⋅,n) consist of a
single task or sets of tasks. In the former case, if exp, called the controlling expression, evaluates to true, s1 that forms the target of THEN is selected to execute; otherwise, s2 that is the target of ELSE is selected. In the latter case, exp is evaluated, in order, against vi in the CASE statements. When a match is found, the corresponding si is selected. Decision-making, represented formally as conditional selection statements as above, can be explicitly interpreted in terms of DAs as follows. • The controlling expression exp can be formally stated in the form of a predicate, which is equivalent to a constraint in a DA context. Thus, it is modeled as a branching actor and two semaphore actors for controlling the selection of correct subsequent tasks. • exp can also be modeled as a branching actor that tests against given CASE statements and the same number of semaphore actors as CASE statements to control the selection of correct subsequent tasks. • The target si (i=1,
⋅⋅⋅,n) is modeled as one or more task actors.
Consider, for example, a decision for determining the number of webs in the design of a crankshaft for an automotive application, based on the type of engine block (e.g., in-line or Vtype engine), which is stated as follows: IF engine-type='in-line, THEN #web=0, ELSE #web=3. As shown in Figure 12, this conditional statement can be interpreted as one branching
actor, two semaphore actors and two mapping actors whose structures are represented as follows: (c1, {engineType}, engineType='in-line) for the controlling expression, (m1, {c1:true}, #web=0, #web) for the THEN target, and (m2, {c1:false}, #web=3, #web) for the ELSE target.
24
Ahn, Ramaswamy and Crawford
IEEE Transactions on SMC c1 :false
c1
m2
engineType='in-line
#web=3
engineType c 1:true
#web=0 m1
I(c1 ) = {engineType } O(c1 ) = {c1:true,c1 :false} I(m1 ) = {c 1:true} I(m2 ) = {c 1:false } O(m1 ) = O(m2 ) = {#web}
#web
Figure 12: An interpretation of a decision into a DA network. Another example is to consider a decision for determining the vee-angle (av) of an engine block, depending on the number of cylinders (#cyl) in the crankshaft design, which is stated as follows: SWITCH (#cyl) {CASE 8 av=90o, CASE 4 av=0o, CASE 6 select av from (0o,60o,90o)}. This multiple statement is interpreted as two mapping actors for parameters #cyl and av, one branching actor for testing the value of #cyl, three semaphore actors, three mapping actors for CASE targets. The DA network shown in Figure 13 shows the interpretation of this example. #cyl c1 test the value of #cyl c1:4 m2 av=0 o
c1 :8 m1 av=90o
c 1:6 m3 select av from (0 o,60o,90o)
I(c1 ) = {#cyl} O(c1) = {c1 :8,c1:6,c1:4} I(m1 ) = {c1 :8} I(m2 ) = {c1 :4} I(m3 ) = {c1 :6} O(m 1) = O(m2 ) = O(m4) = {av}
av
Figure 13: An interpretation of a decision for vee-angle determination. 3.8
Iteration in a CDP A CDP can be characterized as being iterative in the sense that the structure of a DA
context implies iteration; that is, the designer improves a given design by finding values for the design variables, determining whether (or how well) the design satisfies the requirements, and repeating the design process until a satisfactory solution has been obtained. However, a DA context provides only deterministic (or feedforward) data dependencies among design entities and tasks, since the designer’s strategy and method for finding the best solution are not
25
Ahn, Ramaswamy and Crawford
IEEE Transactions on SMC represented in the DA context. That is, a DA context represents “what” the design problem should be; its corresponding DA network is represented as a directed acyclic graph. In addition to a DA context, the designer must represent the strategy and method of “how” the design goal is achieved. That is, feedback data dependencies between design goals and design variables are necessary to supply information on goal evaluation to decide whether the design process should continue or conclude. Feedback and feedforward data dependencies among DAs enable iteration in a CDP.
An iterative process generally consists of
four
subfunctions: initialize the process; compare the current performance indicator value with the previous best one; detect convergence for termination; and update the design solution. In this research, iteration in a CDP is formally represented as an iteration statement such as “DO body WHILE exp” in a high level programming language, and modeled as a loop in the corresponding
DA network. The controlling expression exp is modeled as a branching actor and body consists of a set of task actors. During the iteration, whenever the current design solution evaluates to be infeasible due to the violation of a constraint, the values of design parameters that directly or indirectly depend on design variables are no longer valid and thus unavailable to be referenced by other design tasks. An unbinding process, which will be described in Section 4.2, is necessary to invalidate current dependent parameters before a new design solution is generated. 4. Simulation of the Dynamics of a DA Network This section presents a formalism for simulating the dynamic behavior of a CDP, where ‘dynamic’ means execution of the CDP. Like most dynamic systems, the dynamics of a DA network can be formally described in terms of states and state changes.
The proposed
formalism for dynamic simulation of a CDP is based on Petri net theory. A token is defined to denote the existence and availability of the current value of a parameter actor through the DA network. Token distributions define the states of a DA network. The state changes of a DA network are represented by changes in the number and location of tokens as the DA network is
26
Ahn, Ramaswamy and Crawford
IEEE Transactions on SMC dynamically simulated according to the rule of firing task actors, thereby executing the DA network. 4.1
DA Network Markings A procedural representation of design requires that a CDP be computable (or executable)
to produce a promising solution to the problem. In this research, computability is defined as the reachability of a DA network from a given initial state to an acceptable final state. A state is represented as the marking of a DA network, i.e., the assignment of tokens to parameter actors. The purpose of a token is to denote that a parameter actor is bound to its current value and this value is available to be referenced by other task actors. The placement of a single token in a parameter actor indicates the existence and availability of its current value through the network. A marking M is an assignment of tokens to the parameter actors in a DA network. The number and positions of tokens may change during the execution of a DA network, resulting in a change of states. Thus tokens are used to define the execution of a DA network. Definition 14.
(Marking or State). A marking M of a DA network is a function from the set
of parameter actors P to the set of nonnegative integers of either 0 or 1, denoting the absence or existence of a single token in a parameter actor, respectively. The marking M can also be defined as an n-vector, M=(M1,M2, ⋅⋅⋅ ,Mn), where n= P and each Mi (i=1,2,
⋅⋅⋅,n) is either 0 or 1 for the parameter actor p ∈P. i
Mi=1 denotes that the
parameter actor pi has its current value available for reference through the network, while Mi=0 denotes that the current value of pi is undefined and thus unavailable to be referenced. In a DA network, tokens are represented by small dots in the circles which represent the parameter actors of a DA network. 4.2. Algorithm for a DA Network Execution A task actor is defined to be enabled if a token is assigned to each of its input actors. An enabled task actor fires by removing tokens from its input parameter actors and creating a new token for its (selected) output parameter actor. The execution of a DA network is described as
27
Ahn, Ramaswamy and Crawford
IEEE Transactions on SMC the changes of states caused by successive “firings” of task actors from the initial state to a final state. The initial state, final state and the rule for firing are defined below. Definition 15.
(Initial State).
The initial state Mo of a DA network is defined as the
assignment of tokens to all source actors in a DA context and other parameter actors which are used in modeling its associated process, and whose values are initialized. Definition 16.
(Final States). The final states Mf of a DA network are defined as a set of
possible markings of sink actors. That is, a final state is the assignment of ω tokens to a sink actor, regardless of markings of non-sink actors, where ω denotes either 0 or 1. Definition 17.
(Enabling of a task actor) A task actor is said to be enabled if all of its
input actors are marked. Definition 18.
(Firing of a task actor) An enabled actor is fired by removing tokens from
its input actors and creating a new token for its (selected) output actor. The firing of an enabled actor consists of three subtasks: the removal of tokens from its input actors to reference their current values; the evaluation of the functional or conditional expression defined within the task actor; and the creation of a new token for its output actor to bind the evaluation result as the current value for that output actor. Definition 19.
(Unbinding process) During the iterative process, whenever new values are
generated for design variables, the values of parameter actors which directly or indirectly depend on design variables are no longer valid, and must be re-evaluated. To accomplish this reevaluation of dependent actors, their current values must first be removed (this is called an unbinding process), and then new values must be computed. This unbinding process is the removal of tokens from dependent actors to invalidate their current values. Definition 20.
(Rule for DA network execution). Given a DA network with initial state
Mo, the DA network executes by enabling and firing task actors according to the following algorithm, as illustrated in Figure 14. Step 1. Define the initial state Mo as the current state M of a DA network.
28
Ahn, Ramaswamy and Crawford
IEEE Transactions on SMC Step 2. Establish a set U of enabled task actors. If U is empty, the execution halts, denoting that the DA network is uncomputable. Step 3. An enabled task actor may or may not fire, depending on whether or not the corresponding computation actually takes place. If there exist task actors in U that model constraints in a DA context, they are fired in parallel. If their evaluation indicates that the current design solution is infeasible, an unbinding process is necessary to remove tokens in dependent actors, since they are no longer valid. If there do not exist task actors for constraints in the DA context, all enabled actors in U are fired according to the definition 18. The firing of enabled task actors changes the current state M to the next state M'. Step 4. Define the next state M' as the current state M. If M reaches one of the final states, the execution is completed. If not, return to Step 2. Mo → M Prepare the enabled actor list U. The execution completes. yes Empty U?
Mnew → M
no
∃ x ∈ C and x ∈ U ?
yes
The execution halts.
no
Fire all task actors in U.
no
Mnew ∈ M f
Define new state M new.
yes Fire only x i, i=1,2, ..., n
feasible?
no
Unbind dependent actors.
yes
Figure 14: Algorithm for the execution of a DA network. 4.3
Extension of Modeling with a DA Network It was mentioned in Section 2 that the dynamic behavior of a DA network is
characterized by sequential and parallel operations, synchronizations, conflicts and iterations. In particular, iteration may require repetitive definitions and/or references of some parameter
29
Ahn, Ramaswamy and Crawford
IEEE Transactions on SMC actors. Two special types of arcs must be considered in modeling iteration in the network: (1) there are more references of an input parameter actor by a task actor involved in iteration than its actual definitions, (2) there are more definitions of an output parameter actor by a task actor involved in iteration than its references. By definition 18, the former case causes the depletion of tokens on every iteration, which may halt the iteration unexpectedly; the letter case causes the increase of tokens on every iteration. This violates the notion of a token defined in Section 4.1, since the DA network may possibly lead to an unbounded number of tokens in some parameter actors. A simple extension to DA network modeling which addresses the first problem is an activator arc. An activator arc from a parameter actor p to a task actor t models the data flow of referencing p by t as needed; p is called the activator input to distinguish it from other (normal) input actors. An activator arc has a small dot rather than an arrowhead at t. The firing rule is changed as follows: t is enabled when tokens are in all of its (normal) inputs and activator inputs. The firing of t removes tokens from (normal) input actors, but does not remove tokens from its activator inputs. The second problem is also addressed by a simple extension of a DA network modeling, called a refresh arc from a mapping actor m to a parameter actor p, where p is said to be a refresh actor. The behavior of a refresh arc is described as follows: If m is enabled and p is not bound (i.e., empty token), m is fired to create a new token for p. However, if there already exists a token in p, the firing removes a token to unbind the current value and creates a new token to bind the new value simultaneously, thereby maintaining a single token in p. This arc helps in maintaining bound tokens in the iterative definition of refresh actors. A refresh arc is represented by a dashed arc. An activator arc only connects a parameter actor to a task actor, while a refresh actor arc only connects a task actor to a parameter actor. Figure 15 illustrates the use of activator arcs and refresh arcs for modeling an iteration in a CDP.
30
Ahn, Ramaswamy and Crawford
IEEE Transactions on SMC
d1 :F
dmin d1:T
q1
p1
d1 q
Ts
d p2
T s1
Tsbest
dmax
Ts2
qmax
d2 :F
q2
d2 d2 :F
p5 p6
Figure 15: The use of activator and refresh arcs in modeling an iteration. 4.4
DA State Network — State Space of a DA Network As mentioned in Section 4.2, a DA network is computable if and only if the final state of
the DA network is reachable from an initial marking Mo. That is, the firing of task actors changes the state space of a DA network. In this research, the simulation of a DA network execution results in a directed graph, called a DA state network, which represents a reachable state space of a DA network. Definition 21.
(DA state network) A DA state network defined as a tuple (M, S), where M
is a set of markings, and S is a set of directed arcs. Each arc (Mi, Mj) is labeled by one or more task actors whose firing changes the state of a DA network from Mi to Mj. A DA state network is a graphical representation of the execution of a DA network according to the execution algorithm defined in Section 4.2. That is, each node represents a state (or marking) reachable from Mo and each arc represents the firing of task actors in parallel. The concept of a Petri net reachability graph [12] is used to construct the state space of a DA network by means of representing firing sequences of task actors in the network in terms of changes of states. From the viewpoint of Petri net theory, the state space of a DA state network is characterized to be finite, since the DA network is always bound (or safe); i.e., there exists at most a single token in each parameter actor for any markings reachable from Mo. Boundedness of a DA network makes the construction of a DA state network straightforward, addressing the
31
Ahn, Ramaswamy and Crawford
IEEE Transactions on SMC state explosion problem of Petri nets. Moreover, direct analysis of a DA state network enables the investigation of dynamic behaviors of the modeled CDP, which is illustrated in the next section. 5. Illustrative Example for DA Network Modeling and Simulation This section demonstrates the proposed modeling formalism with DA networks and simulation of dynamic behaviors of the modeled CDP. The design example, which is used to illustrate the methodology of transforming a textual problem statement into a DA context in Section 3.2, is employed to demonstrate further modeling and simulation formalism.
The
translation of the declarative representation of a DA context into a procedural representation is also illustrated by explicit modeling of the associated solution process. The resulting iterative process is represented as a DA network by providing deterministic and non-deterministic relations between DAs.
The dynamics of a DA network can also be investigated by the
simulation of the network execution as a corresponding DA state network and direct analysis of the DA state network. 5.1
DA Network Representation of a DA Context After transforming a problem statement into a DA context, each element in the DA
context is interpreted in terms of DAs, providing the declaration of design entities and tasks and the structure of information flows and dependencies between them. Figure 16 shows the DA network representation of the DA context in Table 1. Figure 16, however, represents the deterministic data dependencies between DAs. No iteration is modeled in the network, since the strategy of determining the values of design variables that best satisfy the design goals is not established in the DA context. The next section describes solution process modeling in terms of DAs according to Sections 3.7 and 3.8.
32
Ahn, Ramaswamy and Crawford
IEEE Transactions on SMC po2
c2 :F
c2
c 2:T
po
pomax po1
Dp
F3
F1
f1
F2 pmax
F
dmin d4
f3
c1
dmax
I 11
d2
d
c1 :F
d1
f2
c 1:T
Q
I1 d3
µt W
R1
f5
R2
I 21 I2
W2
R3
R
W1
Rt f7 V1 E
E2
E1
ρ
Qs
µ2
Ts
g1
g1 :T
c5
c3
c5 :T
f9
c 3:T N
V
g1:F tf
a
µ
f10
Rt 2
c5:F
c 3:F
c4 :T c4
ti D
pumax
f8
c
V2
I 22
R t1
g
µ1
I1 2
f4
f6
T
c4 :F
Figure 16: A deterministic DA network for the DA context in Table 1.
5.2
Solution Process Modeling and Representation The solution process for this problem is iterative in nature, in that design variables d and
po must continually update their values to satisfy a design goal g1. To solve this problem, feedback relationships among d, po and g1 must be established by specifying the strategy and methods for determining the feasibility and convergence of the solution, for updating the design variables, and for controlling the iteration in the process. For this example, a random search method [19, 16] is employed as a solution strategy. Although this method is not particularly efficient, the purpose of this example is to illustrate the DA-based modeling and procedural
33
Ahn, Ramaswamy and Crawford
IEEE Transactions on SMC representation of design, and not to demonstrate the effectiveness of any particular solution strategy. Other strategies can be implemented as well. Implementation of a random search method involves the following design procedures and decisions: determine random values for d and po for initialization and their updates; compare the current solution with the previous best one; and determine the convergence of a solution for termination.
Figure 17 shows a solution strategy with a random search method.
New
parameters are defined to perform such computational tasks; they are not active participants in problem modeling, but only involved in the process representation. These include q and qmax for the iteration counter and its limit, and parameters for storing the best values of design variables (dbest, pobest) and the design goal (Tsbest) during the iteration. Table 2 describes the new processrelated parameters, design procedures and decisions involved in the solution process. Start Given: q, qmax, and Tsbest
q ≤ qmax
no
stop the process.
yes determine d and po.
update solution.
yes
yes
better? no
feasible? no
q =q + 1
Figure 17: Solution strategy with a random search method.
34
Ahn, Ramaswamy and Crawford
IEEE Transactions on SMC Table 2. Definition of process parameters and tasks in the solution process. 1. Process parameters name q index for counting iteration qmax maximum iteration number dbest previous best value of d pobest previous best value of po Tsbest previous best value of Ts 2. Design procedures name inputs p1 dmin, dmax, d1:T p2 pomax, d1:T p3 d, d2:T p4 po, d2:T p5 Ts, d2:T p6 q, (c3:F, c4:F, c5:F, d2:T, or d2:F) 3. Decisions name inputs d1 q, qmax d2 Ts, Tsbest, c3:T, c4:T, c5:T
description
initial value 1 500 undefined undefined 10 × 1010
evaluator generate random number for d between dmin and dmax. generate random number for po less than pomax. assign current value of d to dbest. assign current value of po to pobest. assign current value of Ts to Tsbest. increase the iteration number q by 1 at every iteration.
output d po dbest pobest Tsbest q
evaluator if not q ≤ qmax, stop the iteration. if Ts ≤ Tsbest, update d, po and Ts.
Each element which is related to the process model in Table 2 is also interpreted in terms of DAs, and assembled with the DA network shown in Figure 16 according to their data dependencies. Constraints c1 and c2 that limit the values of design variables d and po are used to determine feasible values for d and po, respectively. Process parameters q, qmax and Tsbest in Table 2 are modeled as parameter actors, design procedures are modeled as mapping actors, and decisions are modeled in terms of branching actors and semaphore actors. The procedural representation of a CDP for the example is shown in Figure 18. In Figure 18, the semaphore actor, named p6:s, represents the common output actor which is shared by branching actors c3, c4, c5 and d2.
The semaphore actor is non-
deterministically marked after firing any one of the branching actors. The following arcs are modeled as activator arcs, since they have more references than definitions during iteration: (qmax,d1), (pomax,p2), (dmin,p1), (dmax,p1), (R,f2), (R,f3), (R,f4), (µ,f5), (µ,f10), (pumax,c3), (tf,c4), (T,c4), (N,f10), (E,f10), and (Tsbest,d2).
35
On the other hand, the arcs (p3,dbest),
Ahn, Ramaswamy and Crawford
IEEE Transactions on SMC (p4,pobest) and (p5,Tsbest) are modeled as refresh arcs since they have more definitions than references. pomax
p2 po d1:F
d1 :T1 d1 :T
q1
d1 q
po 2
po1 Dp
d
dmax
d1
µt
f2
Q
f5
R1
f6
R2
I 21 I2
R3
R
µ1
I1 2
f4
W1 W2
I1
d3
p6
f3
d4
W
I 11
d2
p1
p6:S
pmax
F
dmin
q2
F2
F1
f1
d1 :T2 qmax
F3
Rt f7 V1 E
E2
Qs
V2
Ts
T s2
N
d2:T tf
f8
a
p5 c4
ti D
c5 :T d2 c3 :T
d2 :T1
ρ
c3
c5
E1 c
pumax
T s1
Ts best
f9
V
µ
f10
Rt 2
µ2
I 22
Rt1
g
!!!! ! !!! ! !! !! !!! ! ! ! !! !!! !!!! ! !!!
d2 :T2 p4
c4 :T dbest
T
p3 d2 :T3
pobest
Figure 18: A completeDA network — procedural representation of the DA context in Table 1. The DA network of Figure 18 is executed by defining the initial state, final states and applying the rule of task actor firings defined in Section 4.2. As shown in Figure 18, the initial state is given by placing a token in each source actor and process parameter actors whose values are initialized by the designer; the final state is defined as the assignment of tokens to d1:F, dbest, pobest and Tsbest. Figure 19 shows the DA state network, resulting from the network execution.
36
Ahn, Ramaswamy and Crawford
IEEE Transactions on SMC Mo
d1
M1
d1
M2 p1// p2// f6 // f7 // f9
M3 f1 // f2// f8 p1// p2
M20
f1// f2
M21
c4
M 15
M4
c4
M5
f3 // f4
p6
M6
d1
M7
d1
d1
M 19
d1
M18
p6
M17
c3
M 16
M8
f3 // f4
p1// p2
c3 p1 // p2
M 42
f1// f2
M 43
M37
f1// f2
M36
f3 // f4 d1
M40
p6
M 39
c3
M38
f3 // f4
c3
M 33
d2
M52
c5
p6
M32
p3 // p4 // p5
M47
M30
c5
M 23
M29
M25 d1
f1 // f2
M50
M26
c5
c3
M10 f3 // f4
f1 // f2
M 24
M51
M 46 p6
d2
p6
c5
p3// p4// p5
M 31
c5
Mf
M 45
f1 // f2
f5// f10
f5// f10
M 53
M9
M 22
d2
d1
M 44
d2
M 35 d1
d1
M 41
p1// p2
M28
M11 c3
p1 // p2 d1
M27
M12 f5// f10
M13
c5
M 14
p1 // p2 d1
M 49
d1
M48
Figure 19: A DA state network—execution of the DA network in Figure 18.
5.3 Discussion The formalism for modeling and simulation of CDPs has been demonstrated with the design example. The proposed methodology for DA context modeling is demonstrated through the step-by-step approach to the transformation of given textual problem statement into a DA context. This example also illustrates the explicit representation of the designer’s solution strategy.
Moreover, this example demonstrates the usefulness of the proposed modeling
formalism based on the assertion that (1) the formalism provides graph-theoretical representation of both the DA context and associated solution strategy as a DA network, and (2) the DA
37
Ahn, Ramaswamy and Crawford
IEEE Transactions on SMC network visualizes the topology of a CDP by which the designer can readily verify the data and control structure of the modeled CDP. In addition, this example demonstrates the proposed simulation formalism by representing the network execution graph-theoretically as a DA state network. The DA state network visualizes the state space of the modeled CDP. The topology allows the designer to investigate some important dynamic behaviors of the DA network. For example, we can identify one important property by directly inspecting a sequence of state transitions in the DA state network of Figure 19: the complete execution of the DA network greatly depends on whether constraint c4 is satisfied or not, regardless of other constraints. If c4 is not satisfied, no feasible solution is generated since the final state can never be reached. This property provides the designer with the insight that careful consideration of heat capacity of the disc is critical in this caliper disc brake system design. 6.
Summary and Conclusion This research presents a formalism for computational modeling of engineering design
processes. The formalism provides a methodology for representing both the “what” and “how” of the design process in a unified manner. The development of this modeling formalism is based on Petri net theory to provide a graph-theoretic representation of a CDP, i.e., a DA network. Since a DA network can be described as a bound (simply, safe) Petri net, the simulation of dynamic behaviors of the DA network is straightforward, addressing the state-explosion problem of Petri nets. Moreover, since the structure of a DA network is equivalently interpreted by Petri net theory, structural and dynamic behaviors of the DA network can be analyzed by Petri net analysis techniques. It can be concluded that a DA network is a promising tool for modeling and analyzing engineering design processes. The proposed modeling formalism can be used as a theoretical model for the development of a formal language specialized for design and a graphical, icon-based interface to the language specialized for design. We believe that the graph-like structure of design processes modeled as DAs lends itself readily to this type of interface. The interface will enhance variant 38
Ahn, Ramaswamy and Crawford
IEEE Transactions on SMC product designs by including editing tools that will support incremental development and modification of CDPs. Design process representation through the proposed design language and its graphical interface will provide the vehicle for practicing engineers to document products more thoroughly for later use as product variants. References 1.
Ahn, J-S., Representation of Embodiment Design Processes, MS Thesis, The University of Texas at Austin, May 1993.
2.
Asimow, M., Introduction to Design, Prentice-Hall, 1962.
3.
Bohm, A. P. W., Dataflow Computation, Centre for Mathematics and Computer Science, Amsterdam, 1980.
4.
Chen, A., McGinnis, B., Ullman, D., and Dietterich, T. G., "Design History Knowledge Representation and Its Basic Computer Implementation", The 1990 ASME Design Technical Conferences — 2nd International Conference on Design Theory and Methodology, Chicago, Illinois, September 16-19, 1990, pp. 175-184.
5.
Crawford, R. H., Knowledge Management for Preliminary Mechanical Design, Ph.D. Thesis, Purdue University, December 1989.
6.
DiCesare, F., Harhalakis, G., Proth, J. M., Silva, M., and Vernadat, F. B., Practice of Petri Nets in Manufacturing, Chapman & Hall, 1993.
7.
Finger, S., and Dixon, J. R., "A Review of Research in Mechanical Engineering Design. Part 1: Descriptive, Perspective, and Computer-based Models of Design Processes", Research in Engineering Design, 1989, pp. 51-67.
8.
Gasser, L., and Hill, R. W., "Coordinated Problem Solvers", Anual Review of Computer Science, Vol. 4, 1990, pp. 203-253.
39
Ahn, Ramaswamy and Crawford
IEEE Transactions on SMC 9.
Kannapan, S., and Marshek, K. M., "A Parametric Approach to Machine and Machine Element Design", Technical Report 198, Department of Mechanical Engineering, The University of Texas at Austin, August 1987.
10. Murata, T., "Petri Nets: Properties, Analysis and Applications", Proceedings of the IEEE, Vol. 77, No. 4, April 1989, pp. 541-580. 11. Pahl, G., and Beitz, W., Engineering Design: A Systematic Approach, Springer-Verlag, New York, 1991. 12. Peterson, J. L., Petri Net Theory and the Modeling of Systems, Prentice-Hall, Inc., 1981. 13. Ramaswamy, S., Hierarchical Tme-Extended Petri Nets for Integrated Control and Diagnostics of Multilevel Systems, Ph.D. Thesis, The Center for Advanced Computer Studies, The University of Southwestern Louisiana, 1994. 14. Ramaswamy, S., and Valavanis, K. P. , "Modeling, Analysis and Simulation of Failures in a Materials Handling System with Extended Petri Nets", IEEE Transactions on Systems, Man and Cybernetics, Vol. 24, No. 9, September 1994, pp. 1358-1373. 15. Sferro, P. R., Bolling, G. F., and Crawford, R. H., "It's Time for the Omni-Engineer", Manufacturing Engineering, June 1993, pp. 60-63. 16. Siddall, J. N., Optimal Engineering Design: Principles and Applications, Marcel Dekker, Inc., 1982. 17. Suh, N. P., The Principles of Design, Oxford University Press, New York, 1990. 18. Valvanis, K. P., "On the Hierarchical Modeling Analysis and Simulation of Flexible Manufacturing Systems with Extended Petri Nets", IEEE Transactions on Systems, Man, and Cybernetics, Vol. 20, No. 1, February 1990, pp. 94-110. 19. Vanderplaats, G. N., Numerical Optimization Techniques for Engineering Design with Applications, McGraw-Hill, 1984.
40
Ahn, Ramaswamy and Crawford
