- Email: [email protected]
Symbolic modelling and design methodology
Symbolic modelling and design methodology Delbert L Kimbler, Bevlee A Watford and Robert P Davis Department of Industrial Engineering, Clemson University, Clemson, SC 29634-0920, USA
Within the domain of design methodology, symbolic modelling exists as a means of organizing a design effort. Further, the use of symbolic modelling in engineering design leads to a proper demarcation between design and analysis. This use of symbolic modelling is illustrated through examples in normative and simulation modelling. The separation of modelling and analysis is shown to be an important principle in quali~y of design. Keywords: symbolic modelling, design methodology, engineering design
There is considerable research and discussion surrounding the definition and description of contemporary design theories and methodologies. In fact, there remains significant debate as to whether there are any design 'theories' and what specifically characterizes a design methodology. This paper addresses these issues with regard to symbolic modelling. In particular, the methodologies employed in the development of normative (optimization) mathematical models and digital computer simulation models are described as design methodologies. The purpose of this paper is to characterize (and illustrate) these symbolic modelling activities as specific design methodologies as opposed to those employed in the analysis of models. The reader is assumed to be familiar with the three basic categories of models: iconic, analogue and symbolic. Each of these, in turn, represents a greater degree of abstraction in depicting the entity (or system) being modelled. Further, each represents an attempt to capture the salient features of the entity, the major difference being the context in which these features are represented. On one extreme, a methodology for the design of an iconic (physical) model may be readily interpretable as a design methodology due to the limited degree of abstraction and similarity of context relative to the entity
208
being modelled. Conversely, methodologies employed in the development of symbolic models are more difficult to characterize and interpret because of the degree of abstraction and dissimilarity of context. In either extreme, modelling (as with any other design activity) comprises both art and science. In the succeeding sections of this paper, the authors characterize methodologies for two classes of symbolic modelling activities.
SYMBOLIC MODELLING Before beginning with specific cases, it is important to distinguish between modelling and analysis in design. (This is especially important in symbolic modelling, since its greater generality and degree of abstraction substantially broaden the limits of the design process when compared to iconic or analogue models. The discussion that follows deals primarily with symbolic models.) Design itself may be characterized as an iterative process of modelling, analysis and decision directed at achieving a goal. This goal may deal with the development of a tangible device or product, or it may consist of a solution to an abstract problem. The design is the overall methodology of solving the problem within a
0142-694X/88/04208--06 $03.00 © 1988 Butterworth & Co (Publishers) Ltd
DESIGN STUDIES
known context or domain. (This rather loose definition is useful because of the limits it does not impose, and because it is consistent with design development in the field of artificial intelligence, especially AI-based planners.) By using this definition, then, the design cycle proceeds as follows. First, a goal is recognized within a problem domain. This leads to the development of a model, which is abstracted from the domain. Some operation of the model then results in data for analysis, the result of the analysis then leading to one or more decisions or conclusions. This process is iterative, and at any stage in the process an earlier stage may be subject to revision. The goal-directed nature of the process guides the development of decisions and conclusions regarding the system, but these are inferred based on the operation of a model of the system. While the goal orientation provides a global structure to the problem, there are in fact three processes at work, and possibly three methodologies. These are modelling, analysis and decision, all comprising the overall process of design. Further, while these methodologies may be treated separately, they are operationally complementary and interdependent. The simplest is the decision methodology and process, since it is defined by the model and analysis. Given a model and analysis within a problem domain, the decision process can be considered as identifying a favourable outcome or action, favourable to the goal. The possible outcomes or actions are defined by the model and analysis, and the decision methodology is inherent in the analysis methodology. So, there are in fact two methodologies requiring study in this paradigm: modelling and analysis. The importance of a distinction between modelling and analysis is seen when it is considered that the analysis operates upon data or experiments defined within the confines of the model. The model, however, does not specify the analysis, although it may limit the analysis methodologies. The model, then, is a structure abstracted from a real or hypothesized system, which provides the possibility of analysis. A single model may support a variety of analyses, and analysis methodologies, while precluding others. The significant interaction between modelling and analysis is that some information about the analysis methodology should be available when the model is developed. An attempt at using an analysis methodology that is not supported by the model will result in either model revision or selection of an alternate methodology, leading to the iterative cycle of design. A related issue is the choice of a formalist (top-down) versus empiricist (bottom-up) approach to design. The discussion above would appear to favour a formal approach of [goal] --~ [decision context] --~ [analysis domain] ~ [model domain]. In fact, at least two passes of design decisions need to be made. The first, top-down pass begins with the goal and proceeds to the model in specifying the set of decision alternatives, analysis alternatives and model scope. This pass deals not with methodology, but with limits. It defines the problem domain as it relates to possible decisions, analysis
Vol 9 No 4 October 1988
alternatives and models. This phase is shown in the flowchart in Figure 1. Given a goal and decision context, the analysis and modelling domains are developed iteratively. For each analysis methodology, a corresponding modelling methodology is sought. The analysis methodology is selected to support the specified decision, and the modelling methodology is selected to support the desired analysis. While this might seem contradictory to the philosophy of 'model first', two factors resolve the apparent contradiction. First, the specification of goals and decision can be regarded as the initial steps in defining the model domain. Second, this first phase consists of selecting methodologies (determining the bounds of the problem), not modelling and analysing. The specification of analysis and model domains continues, with the modelanalysis domains reviewed for viability. Two outcomes are possible. First, no viable combination may be found. In this case, the most likely modelling methodology is selected. Second, one or more viable model-analysis combinations are identified. In this case, the most likely combination is selected. Work then proceeds to the second stage. The second pass takes place within each of the three processes, and may be formal or empirical, as appropriate. The item of critical importance is that model detail be complete before analysis begins, and that analysis be complete before decisions are made. Thus additional passes through the process may be made in the order [model] ~ [analysis] ~ [decision], a seemingly bottomup approach, while approaches within each process may be either top-down or bottom-up, as appropriate. The flowchart in Figure 2 illustrates this process. If a suitable analysis methodology was selected in the first phase, a model is developed and analysis performed, leading to a decision that is evaluated for goal satisfaction. If the goal
YES~
] NO
YES
YES
Figure I. Formalist (top-down) phase
209
is not satisfied, the goal is revised and the first phase repeated. If a suitable analysis methodology was not selected, the model is developed and then modified in an attempt to admit analysis. If this is fruitful, the analysis and decision proceed as above. Otherwise, the goal is revised and the first phase repeated. Within this design structure, then, are two keys to quality of design. The overall process is a goal-directed formalist process, leading to definition of design process boundaries and possible final values. Individual process methodologies are selected as appropriate, in the order [model] --~ [analysis] --~ [decision]. By adhering to these principles, the designer describes and controls his design world in a rational way, leading to decisions and actions that are valid within the limits he has set, the scope and fidelity of the model, and the accuracy of the analysis. In one sense, this paradigm is similar to the scientific method of theory, experiment and confirmation. Given that the methodologies may all be heuristic, and that the process is certainly heuristic, it is similar to the engineering method defined by Koen 2.
Develop model
1
1
Normative mathematical modelling Certainly there are a number of approaches that can be described for the development of a normative mathematical model. One methodology, which is both simple to follow and typically yields a useful model, is described in Table 1. This methodology is defined in the context of a sequence of questions, the resolution of which should yield a mathematical model of the problem being investigated. To illustrate this methodology, consider the following example problem. A manufacturing cell is to be configured from three types of equipment: a drilling machine, a robotic part transfer device and a milling machine. There will be one
Table 1. Mathematical model design methodology
Modify model and review analysis methodologies
Basic questions concerning the problem system
Analogous mathematical modelling questions
What is the criterion employed in evaluating performance?
What is the objective?
Identify decision
What characteristics of the system affect its performance and how do they affect it?
What are the decision variables and what is the objective function?
Number of teeth in a milling cutter; Number of geophones in a seismic test
Goal satisfied ?
What limitations exist on one's ability to manipulate the decisions in order to improve performance?
What are the constraint domains?
Capital, Time, Force, Horsepower
How do the decisions interact with the constraining domains to restrict one's ability to manipulate them?
What are the constraint relationships?
Equations, Linear/ nonlinear functions, Process dynamics
Perform analysis
methodology found
model revision
Within this design paradigm, the methodologies of primary importance are modelling and analysis, since the decision process may be, and frequently is, defined by the set of possible outcomes and the analysis methodology. Further, since the analysis must take place within the confines of the model, the development of the model is paramount in the design process. Given the development of a design context, the modelling methodology and its result determine bounds on the quality of the design outcome. The two modelling examples that follow, mathematical programming and discrete-time simulation, illustrate modelling methodologies. Paradoxically, these examples are typically associated with analysis, not modelling. Their power, however, lies in modelling a system symbolically; the analysis component is shown to be relatively simple.
N~,..~~
Revise goal and repeat first phase
2 Finished
Examples Minimize COSt,
Maximize reliablity
Figure 2. Empiricist (bottom-up) phase
210
DESIGN STUDIES
of each type of equipment in the cell. The problem is one of selecting a specific piece of equipment, of each type, from among several candidate pieces of equipment. The result will yield a basic configuration for the cell. There are five different drilling machines, three robots and four milling machines from which to choose. The stated objective is to minimize the total procurement cost of the equipment selected. The restrictions placed on this procurement are that: (1) the total time required to process and transfer a part through the cell is limited to six minutes, and (2) the total area occupied by the three pieces of equipment in square metres is limited to forty or less. Data describing the candidate pieces of equipment are found in Table 2. The steps in the model design methodology are now applied. (1) What is the objective? As stated, it is to minimize the total procurement cost. Let Z represent this cost in thousands of dollars.
What is the objective function? Z = 70x] + 45Xz + 60x3 + 40x4 + 50x5 + 40yl + 35y2 + 37y3 + 120Wl + 100w2 + 140w3 + 150w4 (3) What are the constraint domains? Two of these are obvious and two are not so obvious. There are limitations on time and limitations on space. Also, there is the limitation that one can select only one of each type of equipment. Further, one must have a basis for allowing the decision variables to represent this selection process, i.e. a decision variable domain definition. Beginning with this last restriction, let xi =
1, if drilling machine i is selected 0, if not
Table 2. Example 1 Data Attributes Machine
Cost ($1000)
Process minutes per part
Space (m2)
Drill 1 2 3 4 5
70 45 60 40 5O
1.5 2.5 2.0 3.5 3.0
12 I0 13 15 12
Robot 1 2 3 Mill 1 2 3 4
40 35 37 120 100 140 150
0.5 1.0 0.75 4.0 4.0 3.5 3.0
10 12 10 16 13 14 17
1, if robot j is selected 0, if not and
wk=
1, if milling machine k is selected 0, if not
Thus the decisions are represented as Boolean variables. How do the decisions interact with the constraining domains? Taking the selection restrictions, one can ensure that only one of each type of equipment is selected by the following: X 1 + X 2 + X 3 + X 4 + X5 = 1 Yl +Y2 +Y3 = 1 W 1 "4- W 2 +
W 3 -'~ W 4
1
=
The time restriction and space constraint are rather straightforward, and follow. Time: 1.5xl + 2.5x2 + 2.0x3 + 3.5x4 + 3.0x5 + 0.5y] + 1.0y2 + 0.75y3 + 4.0Wl + 4.0w2 + 3.5w3 + 3.0w4 -< 6 Space: 12Xl + 10X2 + 13X3 + 15x4 + 12Xs + 10yl + 12yz + 10y3 + 16Wl + 13W2 + 14W3 + 17w4 --< 40
(2) What are the decision variables? Let x i < ) the selection of drilling machine i Let y j , , the selection of robot j Let wk , ~ the selection of milling machine k
YJ --
This completes the symbolic design methodology. The model that results is readily recognized as a zero-one linear program, and is summarized in Figure 3. The analysis process would consist of arriving at a solution using a standard solution algorithm, with the decision taken directly from the solution variables at optimality. The symbolic design, in this case, results in a model with a single method of analysis and direct interpretation of decision.
Discrete simulation modelling Discrete simulation is used to model systems in which the dynamics may be described by a system state that is observed only immediately after changes to that state (event times). Thus the model must capture the system logic as well as it dynamic behaviour. In its purest form, discrete-event simulation requires an explicit definition of all system states and events (state changes) together with the logical structure that causes events. This kind of simulation model, then, is a set of event descriptions and a state vector, typically implemented in a high-level programming language. Advances in specialized languages 3'4'6 have led to the process-interaction approach to simulation, in which a process is defined and an entity interacts with this process as the simulation proceeds. While the actual execution of the simulation programme may continue to be event driven, the symbolic model can be as simple as a Min: • =
70~. + 45x2
st
15x.+
+
25~ 2
60x 3 +
40x 4
20x3+
35x ~
+
50x s + 30x~
12xl +
10x2
+
13x3 +
15x.
+
12x 5 +
xl +
x2
÷
*3 +
x.
+
x5
40y I
+ 35y 2 ÷
05y I
10y2+
37y3
+ 1 2 0 w , + lOOwz
075y 3
+
lOy~
+
f2~'2 +
18yj
+
V.
+
V2 +
V3
40w~
+ 140w 3 + 150w 4
+
40w 2
16wl +
13w~
+
35w3+ ~4w 3 +
w2
+
w3 +
30w4
~; 6
17w~ ~ 4 0 -1 -1
wl
+
w4
1
X l , x 2 , x 3 , x 4 , x s , y l , Y2, ~'3, w l , w~, w 3 , w4 E (0, 1 )
Figure 3. Example zero-one linear program
Vo| 9 No 4 October 1988
211
flowchart of the process, together with names and definitions linking the flowchart to the system modelled. As with the previous example, the symbolic model can be developed through a series of questions, shown in Table 3. (These questions deal with the process-interaction approach. The discrete-event approach would require substantially more detail, and the questions would reflect the simulation methodology more than the system to be modelled. For example, the advance of time is modelled by the logic of the event at the end of the time advance and its effect on the system state vector, rather than modelling by the duration of time that an entity is in a process directly.) In this example, consider the processing of a manufactured component through a series of two machining cells. The first cell contains two machines, either of which may be used for the first process. The second cell has a single machine. Both cells have limited areas for components to wait before processing, and components must wait until a machine is free, since the process steps must be completed in order. This two-step process may be considered independently of preceding and succeeding operations on the component. Each cell process requires a known amount of time, which is the same for all parts. The objective of this study is to determine the required waiting area for work in process in each cell. The steps in the simulation model design methodology are now applied. (1) What is the primary entity of interest? The manufactured component moves through the system of machines; it is the entity of interest. (2) What are the modes of entity entry and exit? Arrival of an entity across the system boundary is controlled by a prior process. Its arrival time may be determined, but it can be represented by a function or Table 3. Simulation model design methodology
Basic questions concerning the problem/system
Analogous simulation modelling questions
Examples
What object traverses and interacts with the system?
What is the primary entity of interest?
Component, job, customer
What are the system boundaries?
What are the modes of entity entry and exit?
Customer arrival, job completion
What is the logical nature of the system?
What is the order of key processes?
Flowchart
How does the object behave or interact with the system?
What input data is necessary?
Arrival rates, patterns
What are the process characteristics?
What are the key process parameters?
Queue capacity, explicit delays
What are the process measurements of interest?
What data collection is necessary? What variables should be tabulated?
Time in system, queue length
212
variable in the model. Exit of the component occurs after completion of the second process; its progress beyond this stage is of no interest. (3) What is the order of key processes? The key processes in order are: waiting for the first machine, being processed in the first cell, transport to the second cell, waiting for the second machine, and being processed in the second cell. (4) What input data is necessary? Activities and events exogenous to the system may affect events within the system. A typical example is that of arrivals to the system, whose arrival rate and pattern are fixed outside the system boundary. (5) What are the key process parameters? At this stage, it is only necessary that the parameters be identified qualitatively. Waiting occurs in queues, where capacity is a controlling parameter. Processing requires time, so time required in each process is a key parameter. These may be represented by variables or functions. (6) What data collection is necessary? What variables should be tabulated? From the object of the study, it is necessary to observe and collect observations of queue length in each cell. It is frequently useful, as a benchmark for comparison or for validation of the model, to tabulate time in system and cycle time for completed components. This completes the design methodology for this simple system. The resulting model is a flowchart, as shown in Figure 4. Note that, at this stage, the model remains completely symbolic, consisting of graphical symbols and variable or function names. This allows the model to be developed independently of the experimental details, such as arrival and processing times. This segregation of model and experiment is based on work by Ziegler 7 and has been implemented in the SIMAN simulation language by Pegden 3. Other languages with this process orientation are amenable to a similar model development, but eventually require that variables or functions be assigned values explicitly in the model or have values read as data. Operationally, quite a few questions remain. For example, there must be a way of starting and stopping the simulation, and regulating the means of data collection and analysis. The model, however, is finished. The issues of simulation control and data collection properly belong in the analysis process; they are addressed here only to the extent that they may affect model development, where prior knowledge of data to be collected may be used to reduce the extent of the review-and-revise cycle of programming. The use of simulation brings out a further consideration in the separation of modelling and analysis in design. While the mathematical model example leads to relatively simple procedural analysis, the analysis of simulation experiments is not subject to a clear set of computational procedures. Typically simulations contain random inputs, and data collected are realizations of random variables. Simulation experiments are analysed by statistical inference, and the quality of the analysis is
DESIGN STUDIES
Jobs enter the system at rate x (1)
1
Jobs wait in queue 1 until machine in cell 1 is idle
1 Job moves to idle unit of
cell 1, and makes it busy
1 Delay in cell 1 for x (2) time units
Jobs wait in queue 2 until cell 2 is idle
1 Job moves to cell 2, I machine becomes busy
1 Delay in cell 2 for x(2) time units
1
Job exits from cell 2, machine in cell 2 is now idle
1 Job exits from cell 1,
this paradigm are a formal, or top-down, goal-directed approach to the design process, followed by an ad hoc mixture of formal and empirical approaches with the modelling, analysis, and decision processes. The symbolic modelling methodology is seen to be of primary importance, for the limitations and influence the model imposes on the analysis process. A related issue is the importance of separation between model and analysis. In addition to the points made through two examples, the modelling process and its methodology must be considered with regard to the information contained in the model itself. The very act of modelling accumulates, integrates and synthesizes information and knowledge about a system. When modelling and analysis are combined, this knowledge may be obscured. Conversely, when modelling and analysis are considered as separate processes, the modelling methodology may be used to gain knowledge about the system that would otherwise be lost or ignored. The simulation example led to a futher separation of analysis into experimental design and experimental analysis, both separate from modelling. While the analysis following development of a mathematical program model is procedural, the analysis following development of a simulation model is typically experimental. This example illustrates the extreme importance associated with the separation of modelling from analysis.
~rocess e n ~
machine becomes idle
REFERENCES
Figure 4. Simulation model
dependent on the operational decisions influencing the experiments themselves. A common error is to begin collecting data before developing a clear design goal and analysis plan. A perfectly valid model may yield invalid results if the design cycle of [model] ~ [analysis] [decision] is not adhered to. In this case, the analysis process must be further broken down, into experimental design and experimental analysis, both conducted within the problem domain and in view of the design goal.
Cohen, P R and Feigenbaum, E A (Editors) The Handbook of Artificial Intelligence Heuristech Press, Stanford, CA (1986) Koen, B V Definition of the Engineering Method American Society for Engineering Education, Washington, D.C. (1987) 3 Pegden, C D Introduction to S I M A N Systems Modeling Corp., State College, PA (1986) Pritsker, A A B and Pegden, C D Introduction to Simulation and SLAM Systems Publishing Co., West Lafayette, IN (1979) 5 Saeerdoti, E D 'Planning in a hierarchy of abstraction spaces' Artificial Intelligence Vol 5 (1974)
SUMMARY
6 Sehriber, T J Simulation Using GPSS, John Wiley and Sons, New York (1974)
A paradigm of design methodology dealing with symbolic modelling has been presented. The key elements of
7 Ziegler, B P Theory of Modeling and Simulation, John Wiley and Sons, New York (1976)
Vol 9 No 4 October 1988
213
Within the domain of design methodology, symbolic modelling exists as a means of organizing a design effort. Further, the use of symbolic modelling in engineering design leads to a proper demarcation between design and analysis. This use of symbolic modelling is illustrated through examples in normative and simulation modelling. The separation of modelling and analysis is shown to be an important principle in quali~y of design. Keywords: symbolic modelling, design methodology, engineering design
There is considerable research and discussion surrounding the definition and description of contemporary design theories and methodologies. In fact, there remains significant debate as to whether there are any design 'theories' and what specifically characterizes a design methodology. This paper addresses these issues with regard to symbolic modelling. In particular, the methodologies employed in the development of normative (optimization) mathematical models and digital computer simulation models are described as design methodologies. The purpose of this paper is to characterize (and illustrate) these symbolic modelling activities as specific design methodologies as opposed to those employed in the analysis of models. The reader is assumed to be familiar with the three basic categories of models: iconic, analogue and symbolic. Each of these, in turn, represents a greater degree of abstraction in depicting the entity (or system) being modelled. Further, each represents an attempt to capture the salient features of the entity, the major difference being the context in which these features are represented. On one extreme, a methodology for the design of an iconic (physical) model may be readily interpretable as a design methodology due to the limited degree of abstraction and similarity of context relative to the entity
208
being modelled. Conversely, methodologies employed in the development of symbolic models are more difficult to characterize and interpret because of the degree of abstraction and dissimilarity of context. In either extreme, modelling (as with any other design activity) comprises both art and science. In the succeeding sections of this paper, the authors characterize methodologies for two classes of symbolic modelling activities.
SYMBOLIC MODELLING Before beginning with specific cases, it is important to distinguish between modelling and analysis in design. (This is especially important in symbolic modelling, since its greater generality and degree of abstraction substantially broaden the limits of the design process when compared to iconic or analogue models. The discussion that follows deals primarily with symbolic models.) Design itself may be characterized as an iterative process of modelling, analysis and decision directed at achieving a goal. This goal may deal with the development of a tangible device or product, or it may consist of a solution to an abstract problem. The design is the overall methodology of solving the problem within a
0142-694X/88/04208--06 $03.00 © 1988 Butterworth & Co (Publishers) Ltd
DESIGN STUDIES
known context or domain. (This rather loose definition is useful because of the limits it does not impose, and because it is consistent with design development in the field of artificial intelligence, especially AI-based planners.) By using this definition, then, the design cycle proceeds as follows. First, a goal is recognized within a problem domain. This leads to the development of a model, which is abstracted from the domain. Some operation of the model then results in data for analysis, the result of the analysis then leading to one or more decisions or conclusions. This process is iterative, and at any stage in the process an earlier stage may be subject to revision. The goal-directed nature of the process guides the development of decisions and conclusions regarding the system, but these are inferred based on the operation of a model of the system. While the goal orientation provides a global structure to the problem, there are in fact three processes at work, and possibly three methodologies. These are modelling, analysis and decision, all comprising the overall process of design. Further, while these methodologies may be treated separately, they are operationally complementary and interdependent. The simplest is the decision methodology and process, since it is defined by the model and analysis. Given a model and analysis within a problem domain, the decision process can be considered as identifying a favourable outcome or action, favourable to the goal. The possible outcomes or actions are defined by the model and analysis, and the decision methodology is inherent in the analysis methodology. So, there are in fact two methodologies requiring study in this paradigm: modelling and analysis. The importance of a distinction between modelling and analysis is seen when it is considered that the analysis operates upon data or experiments defined within the confines of the model. The model, however, does not specify the analysis, although it may limit the analysis methodologies. The model, then, is a structure abstracted from a real or hypothesized system, which provides the possibility of analysis. A single model may support a variety of analyses, and analysis methodologies, while precluding others. The significant interaction between modelling and analysis is that some information about the analysis methodology should be available when the model is developed. An attempt at using an analysis methodology that is not supported by the model will result in either model revision or selection of an alternate methodology, leading to the iterative cycle of design. A related issue is the choice of a formalist (top-down) versus empiricist (bottom-up) approach to design. The discussion above would appear to favour a formal approach of [goal] --~ [decision context] --~ [analysis domain] ~ [model domain]. In fact, at least two passes of design decisions need to be made. The first, top-down pass begins with the goal and proceeds to the model in specifying the set of decision alternatives, analysis alternatives and model scope. This pass deals not with methodology, but with limits. It defines the problem domain as it relates to possible decisions, analysis
Vol 9 No 4 October 1988
alternatives and models. This phase is shown in the flowchart in Figure 1. Given a goal and decision context, the analysis and modelling domains are developed iteratively. For each analysis methodology, a corresponding modelling methodology is sought. The analysis methodology is selected to support the specified decision, and the modelling methodology is selected to support the desired analysis. While this might seem contradictory to the philosophy of 'model first', two factors resolve the apparent contradiction. First, the specification of goals and decision can be regarded as the initial steps in defining the model domain. Second, this first phase consists of selecting methodologies (determining the bounds of the problem), not modelling and analysing. The specification of analysis and model domains continues, with the modelanalysis domains reviewed for viability. Two outcomes are possible. First, no viable combination may be found. In this case, the most likely modelling methodology is selected. Second, one or more viable model-analysis combinations are identified. In this case, the most likely combination is selected. Work then proceeds to the second stage. The second pass takes place within each of the three processes, and may be formal or empirical, as appropriate. The item of critical importance is that model detail be complete before analysis begins, and that analysis be complete before decisions are made. Thus additional passes through the process may be made in the order [model] ~ [analysis] ~ [decision], a seemingly bottomup approach, while approaches within each process may be either top-down or bottom-up, as appropriate. The flowchart in Figure 2 illustrates this process. If a suitable analysis methodology was selected in the first phase, a model is developed and analysis performed, leading to a decision that is evaluated for goal satisfaction. If the goal
YES~
] NO
YES
YES
Figure I. Formalist (top-down) phase
209
is not satisfied, the goal is revised and the first phase repeated. If a suitable analysis methodology was not selected, the model is developed and then modified in an attempt to admit analysis. If this is fruitful, the analysis and decision proceed as above. Otherwise, the goal is revised and the first phase repeated. Within this design structure, then, are two keys to quality of design. The overall process is a goal-directed formalist process, leading to definition of design process boundaries and possible final values. Individual process methodologies are selected as appropriate, in the order [model] --~ [analysis] --~ [decision]. By adhering to these principles, the designer describes and controls his design world in a rational way, leading to decisions and actions that are valid within the limits he has set, the scope and fidelity of the model, and the accuracy of the analysis. In one sense, this paradigm is similar to the scientific method of theory, experiment and confirmation. Given that the methodologies may all be heuristic, and that the process is certainly heuristic, it is similar to the engineering method defined by Koen 2.
Develop model
1
1
Normative mathematical modelling Certainly there are a number of approaches that can be described for the development of a normative mathematical model. One methodology, which is both simple to follow and typically yields a useful model, is described in Table 1. This methodology is defined in the context of a sequence of questions, the resolution of which should yield a mathematical model of the problem being investigated. To illustrate this methodology, consider the following example problem. A manufacturing cell is to be configured from three types of equipment: a drilling machine, a robotic part transfer device and a milling machine. There will be one
Table 1. Mathematical model design methodology
Modify model and review analysis methodologies
Basic questions concerning the problem system
Analogous mathematical modelling questions
What is the criterion employed in evaluating performance?
What is the objective?
Identify decision
What characteristics of the system affect its performance and how do they affect it?
What are the decision variables and what is the objective function?
Number of teeth in a milling cutter; Number of geophones in a seismic test
Goal satisfied ?
What limitations exist on one's ability to manipulate the decisions in order to improve performance?
What are the constraint domains?
Capital, Time, Force, Horsepower
How do the decisions interact with the constraining domains to restrict one's ability to manipulate them?
What are the constraint relationships?
Equations, Linear/ nonlinear functions, Process dynamics
Perform analysis
methodology found
model revision
Within this design paradigm, the methodologies of primary importance are modelling and analysis, since the decision process may be, and frequently is, defined by the set of possible outcomes and the analysis methodology. Further, since the analysis must take place within the confines of the model, the development of the model is paramount in the design process. Given the development of a design context, the modelling methodology and its result determine bounds on the quality of the design outcome. The two modelling examples that follow, mathematical programming and discrete-time simulation, illustrate modelling methodologies. Paradoxically, these examples are typically associated with analysis, not modelling. Their power, however, lies in modelling a system symbolically; the analysis component is shown to be relatively simple.
N~,..~~
Revise goal and repeat first phase
2 Finished
Examples Minimize COSt,
Maximize reliablity
Figure 2. Empiricist (bottom-up) phase
210
DESIGN STUDIES
of each type of equipment in the cell. The problem is one of selecting a specific piece of equipment, of each type, from among several candidate pieces of equipment. The result will yield a basic configuration for the cell. There are five different drilling machines, three robots and four milling machines from which to choose. The stated objective is to minimize the total procurement cost of the equipment selected. The restrictions placed on this procurement are that: (1) the total time required to process and transfer a part through the cell is limited to six minutes, and (2) the total area occupied by the three pieces of equipment in square metres is limited to forty or less. Data describing the candidate pieces of equipment are found in Table 2. The steps in the model design methodology are now applied. (1) What is the objective? As stated, it is to minimize the total procurement cost. Let Z represent this cost in thousands of dollars.
What is the objective function? Z = 70x] + 45Xz + 60x3 + 40x4 + 50x5 + 40yl + 35y2 + 37y3 + 120Wl + 100w2 + 140w3 + 150w4 (3) What are the constraint domains? Two of these are obvious and two are not so obvious. There are limitations on time and limitations on space. Also, there is the limitation that one can select only one of each type of equipment. Further, one must have a basis for allowing the decision variables to represent this selection process, i.e. a decision variable domain definition. Beginning with this last restriction, let xi =
1, if drilling machine i is selected 0, if not
Table 2. Example 1 Data Attributes Machine
Cost ($1000)
Process minutes per part
Space (m2)
Drill 1 2 3 4 5
70 45 60 40 5O
1.5 2.5 2.0 3.5 3.0
12 I0 13 15 12
Robot 1 2 3 Mill 1 2 3 4
40 35 37 120 100 140 150
0.5 1.0 0.75 4.0 4.0 3.5 3.0
10 12 10 16 13 14 17
1, if robot j is selected 0, if not and
wk=
1, if milling machine k is selected 0, if not
Thus the decisions are represented as Boolean variables. How do the decisions interact with the constraining domains? Taking the selection restrictions, one can ensure that only one of each type of equipment is selected by the following: X 1 + X 2 + X 3 + X 4 + X5 = 1 Yl +Y2 +Y3 = 1 W 1 "4- W 2 +
W 3 -'~ W 4
1
=
The time restriction and space constraint are rather straightforward, and follow. Time: 1.5xl + 2.5x2 + 2.0x3 + 3.5x4 + 3.0x5 + 0.5y] + 1.0y2 + 0.75y3 + 4.0Wl + 4.0w2 + 3.5w3 + 3.0w4 -< 6 Space: 12Xl + 10X2 + 13X3 + 15x4 + 12Xs + 10yl + 12yz + 10y3 + 16Wl + 13W2 + 14W3 + 17w4 --< 40
(2) What are the decision variables? Let x i < ) the selection of drilling machine i Let y j , , the selection of robot j Let wk , ~ the selection of milling machine k
YJ --
This completes the symbolic design methodology. The model that results is readily recognized as a zero-one linear program, and is summarized in Figure 3. The analysis process would consist of arriving at a solution using a standard solution algorithm, with the decision taken directly from the solution variables at optimality. The symbolic design, in this case, results in a model with a single method of analysis and direct interpretation of decision.
Discrete simulation modelling Discrete simulation is used to model systems in which the dynamics may be described by a system state that is observed only immediately after changes to that state (event times). Thus the model must capture the system logic as well as it dynamic behaviour. In its purest form, discrete-event simulation requires an explicit definition of all system states and events (state changes) together with the logical structure that causes events. This kind of simulation model, then, is a set of event descriptions and a state vector, typically implemented in a high-level programming language. Advances in specialized languages 3'4'6 have led to the process-interaction approach to simulation, in which a process is defined and an entity interacts with this process as the simulation proceeds. While the actual execution of the simulation programme may continue to be event driven, the symbolic model can be as simple as a Min: • =
70~. + 45x2
st
15x.+
+
25~ 2
60x 3 +
40x 4
20x3+
35x ~
+
50x s + 30x~
12xl +
10x2
+
13x3 +
15x.
+
12x 5 +
xl +
x2
÷
*3 +
x.
+
x5
40y I
+ 35y 2 ÷
05y I
10y2+
37y3
+ 1 2 0 w , + lOOwz
075y 3
+
lOy~
+
f2~'2 +
18yj
+
V.
+
V2 +
V3
40w~
+ 140w 3 + 150w 4
+
40w 2
16wl +
13w~
+
35w3+ ~4w 3 +
w2
+
w3 +
30w4
~; 6
17w~ ~ 4 0 -1 -1
wl
+
w4
1
X l , x 2 , x 3 , x 4 , x s , y l , Y2, ~'3, w l , w~, w 3 , w4 E (0, 1 )
Figure 3. Example zero-one linear program
Vo| 9 No 4 October 1988
211
flowchart of the process, together with names and definitions linking the flowchart to the system modelled. As with the previous example, the symbolic model can be developed through a series of questions, shown in Table 3. (These questions deal with the process-interaction approach. The discrete-event approach would require substantially more detail, and the questions would reflect the simulation methodology more than the system to be modelled. For example, the advance of time is modelled by the logic of the event at the end of the time advance and its effect on the system state vector, rather than modelling by the duration of time that an entity is in a process directly.) In this example, consider the processing of a manufactured component through a series of two machining cells. The first cell contains two machines, either of which may be used for the first process. The second cell has a single machine. Both cells have limited areas for components to wait before processing, and components must wait until a machine is free, since the process steps must be completed in order. This two-step process may be considered independently of preceding and succeeding operations on the component. Each cell process requires a known amount of time, which is the same for all parts. The objective of this study is to determine the required waiting area for work in process in each cell. The steps in the simulation model design methodology are now applied. (1) What is the primary entity of interest? The manufactured component moves through the system of machines; it is the entity of interest. (2) What are the modes of entity entry and exit? Arrival of an entity across the system boundary is controlled by a prior process. Its arrival time may be determined, but it can be represented by a function or Table 3. Simulation model design methodology
Basic questions concerning the problem/system
Analogous simulation modelling questions
Examples
What object traverses and interacts with the system?
What is the primary entity of interest?
Component, job, customer
What are the system boundaries?
What are the modes of entity entry and exit?
Customer arrival, job completion
What is the logical nature of the system?
What is the order of key processes?
Flowchart
How does the object behave or interact with the system?
What input data is necessary?
Arrival rates, patterns
What are the process characteristics?
What are the key process parameters?
Queue capacity, explicit delays
What are the process measurements of interest?
What data collection is necessary? What variables should be tabulated?
Time in system, queue length
212
variable in the model. Exit of the component occurs after completion of the second process; its progress beyond this stage is of no interest. (3) What is the order of key processes? The key processes in order are: waiting for the first machine, being processed in the first cell, transport to the second cell, waiting for the second machine, and being processed in the second cell. (4) What input data is necessary? Activities and events exogenous to the system may affect events within the system. A typical example is that of arrivals to the system, whose arrival rate and pattern are fixed outside the system boundary. (5) What are the key process parameters? At this stage, it is only necessary that the parameters be identified qualitatively. Waiting occurs in queues, where capacity is a controlling parameter. Processing requires time, so time required in each process is a key parameter. These may be represented by variables or functions. (6) What data collection is necessary? What variables should be tabulated? From the object of the study, it is necessary to observe and collect observations of queue length in each cell. It is frequently useful, as a benchmark for comparison or for validation of the model, to tabulate time in system and cycle time for completed components. This completes the design methodology for this simple system. The resulting model is a flowchart, as shown in Figure 4. Note that, at this stage, the model remains completely symbolic, consisting of graphical symbols and variable or function names. This allows the model to be developed independently of the experimental details, such as arrival and processing times. This segregation of model and experiment is based on work by Ziegler 7 and has been implemented in the SIMAN simulation language by Pegden 3. Other languages with this process orientation are amenable to a similar model development, but eventually require that variables or functions be assigned values explicitly in the model or have values read as data. Operationally, quite a few questions remain. For example, there must be a way of starting and stopping the simulation, and regulating the means of data collection and analysis. The model, however, is finished. The issues of simulation control and data collection properly belong in the analysis process; they are addressed here only to the extent that they may affect model development, where prior knowledge of data to be collected may be used to reduce the extent of the review-and-revise cycle of programming. The use of simulation brings out a further consideration in the separation of modelling and analysis in design. While the mathematical model example leads to relatively simple procedural analysis, the analysis of simulation experiments is not subject to a clear set of computational procedures. Typically simulations contain random inputs, and data collected are realizations of random variables. Simulation experiments are analysed by statistical inference, and the quality of the analysis is
DESIGN STUDIES
Jobs enter the system at rate x (1)
1
Jobs wait in queue 1 until machine in cell 1 is idle
1 Job moves to idle unit of
cell 1, and makes it busy
1 Delay in cell 1 for x (2) time units
Jobs wait in queue 2 until cell 2 is idle
1 Job moves to cell 2, I machine becomes busy
1 Delay in cell 2 for x(2) time units
1
Job exits from cell 2, machine in cell 2 is now idle
1 Job exits from cell 1,
this paradigm are a formal, or top-down, goal-directed approach to the design process, followed by an ad hoc mixture of formal and empirical approaches with the modelling, analysis, and decision processes. The symbolic modelling methodology is seen to be of primary importance, for the limitations and influence the model imposes on the analysis process. A related issue is the importance of separation between model and analysis. In addition to the points made through two examples, the modelling process and its methodology must be considered with regard to the information contained in the model itself. The very act of modelling accumulates, integrates and synthesizes information and knowledge about a system. When modelling and analysis are combined, this knowledge may be obscured. Conversely, when modelling and analysis are considered as separate processes, the modelling methodology may be used to gain knowledge about the system that would otherwise be lost or ignored. The simulation example led to a futher separation of analysis into experimental design and experimental analysis, both separate from modelling. While the analysis following development of a mathematical program model is procedural, the analysis following development of a simulation model is typically experimental. This example illustrates the extreme importance associated with the separation of modelling from analysis.
~rocess e n ~
machine becomes idle
REFERENCES
Figure 4. Simulation model
dependent on the operational decisions influencing the experiments themselves. A common error is to begin collecting data before developing a clear design goal and analysis plan. A perfectly valid model may yield invalid results if the design cycle of [model] ~ [analysis] [decision] is not adhered to. In this case, the analysis process must be further broken down, into experimental design and experimental analysis, both conducted within the problem domain and in view of the design goal.
Cohen, P R and Feigenbaum, E A (Editors) The Handbook of Artificial Intelligence Heuristech Press, Stanford, CA (1986) Koen, B V Definition of the Engineering Method American Society for Engineering Education, Washington, D.C. (1987) 3 Pegden, C D Introduction to S I M A N Systems Modeling Corp., State College, PA (1986) Pritsker, A A B and Pegden, C D Introduction to Simulation and SLAM Systems Publishing Co., West Lafayette, IN (1979) 5 Saeerdoti, E D 'Planning in a hierarchy of abstraction spaces' Artificial Intelligence Vol 5 (1974)
SUMMARY
6 Sehriber, T J Simulation Using GPSS, John Wiley and Sons, New York (1974)
A paradigm of design methodology dealing with symbolic modelling has been presented. The key elements of
7 Ziegler, B P Theory of Modeling and Simulation, John Wiley and Sons, New York (1976)
Vol 9 No 4 October 1988
213