- Email: [email protected]
CAD model for performance evaluation
Budding and Encironmenl, Vol. 31, No. 4, pp. 345-361, 1996 Copyright ii 1996 Elsewer Science Ltd. All nghts reserved Printed m Great Britam 036&1323/96 $15.00+0.00
Pergamon PII: SO360-1323(96)00004-2
CAD Model for Performance A. WIEZEL* R. BECKERf
Evaluation
(Received 28 March 1995; accepted 21 November 1995)
A CAD assistant, PREVENT, has been developed to help evaluate building performance during the various design stages. The system accommodates the whole design process and provides both evaluation and diagnosis upon request. It has the capability to capture the design intent directly from sketches and to evaluate the jitness of the emerging solution to the demands of the building user. The structure and the functions of various components of evaluation by PREVENT are presented. A design model for a performance evaluation by PREVENT is proposed and tested. Copyright 0 1996 Elsevier Science Ltd.
1. INTRODUCTION 1.1.
and building occupancy. (For detailed reports on BMPs consult < irma.hs.jhu.edu > through Gopher.) If these models are to materialize, the design artifact, the building, should be represented in a manner that satisfies all the participants throughout the entire design and planning process. However, the cost of such an extensive representation is prohibitive despite the development of the appropriate computer technology [2, 31. The common solution is to use different tools for different stages and aspects of the process, with each tool having its own model [4]. Unfortunately, this approach, by its nature, does not solve the problems arising from the above mentioned factors. Recent reports [S-7], however, suggest that integrative CAD tools, destined to model the whole design process, are about to emerge. These tools will benefit from the advancements in computer science and cognitive science and will be able to support the whole design process both in depth (from conceptual to detailed design) and in breadth (will serve all the participants). They are based on specifically developed building models and will require the designer to follow a given (new) design and modeling method. In this paper, the authors present a new design and modeling tool that will support the whole design process.
Background
Building design is a complex creative process involving the participation of investors, developers, owners, architects, advisors and, sometimes, contractors. The concerns of these participants, who may have opposing goals, are usually very different. Therefore, steering the design process is a difficult task that is encumbered by the following factors. l
l
l
l
l
The number of aspects to be simultaneously considered and the large volume of information and knowledge to be dealt with is beyond the capacity of the human brain [ 11. Lack of knowledge in certain domains may cause potential problems to be overlooked and, as a consequence, relevant advisors will not even be included in the design team. The various advisors participating in the design process usually do not efficiently communicate with one another, and the participation in the design process is as an individual (at pre-defined stages) rather than as an integrated team. The narrow specialization of individual advisors, combined with their differing personal character and reputation, can induce an unequilibrated consideration of recommendations. Because in many cases the intended user of the designed building is the party with the least technical knowledge, his/her interests are often insufficiently considered.
1.2. Objectives The authors’ view of Computer Aided Design tools is that a CAD system should ideally not only represent the model of the designed artifact, but should also act as an expert who “stands behind the shoulder of the designer”. The CAD system should interfere as little as possible with the design habits of its user. However, while viewing the drawings as they are created during the design process, this expert should be ready, upon request, to state opinions and comments. The main objective of this study was to investigate and demonstrate the feasibility of such a CAD system. The general description of the CAD system, and the guiding philosophy, were presented previously [S]. This paper presents the computerized model that was developed to support the CAD system and the approach that led to this model. The prototype that was developed
The computer can theoretically overcome these problems by hosting the whole design process and providing support for the decision making. Indeed, extensive efforts are being made to develop building product models (BPMs) so that they can offer a framework for multiple users during all the stages of design, contracting, erection,
*Del E. Webb School of Construction, Arizona sity, Tempe, AZ 85287, U.S.A. iDepartment of Civil Engineering, Technion, Israel.
State UniverHaifa
32000,
345
346
A. Wiezel
attempts to enrich the content of current CAD models, allowing accommodation of not only the designed artifact (the design decisions) but also the design intent and its implications. The model works as an attachment to existing CAD systems (such as AutoCAD), permitting the designer to follow his/her own design habits.
2. DEVELOPMENT 2.1. Basic considerations The transforming of the design intent into a design solution constitutes the core of the design process. This transformation is commonly referred to as the synthesis stage in a three-step design cycle: analysis, synthesis, and evaluation. Except for those cases in which it is based on prescribed procedures, the synthesis activity is not yet well understood. Despite some success reported in formalizing the process of generating design solutions, synthesis is still considered a creative activity best left to humans. The remaining two components of the design cycle, analysis to establish the design intent and evaluation of the design alternatives, are considered to be more susceptible to formalization. They constitute the main interest of this study. 2.2. Limitations Despite the efforts made to formalize design knowledge and practice (for a comprehensive survey see [9]), the only systematic method for design analysis and evaluation is by applying the performance concept in design. Performance requirements and criteria reflect, in rational and rather quantifiable type terms, the needs of human users and others. Therefore, all the typical activities must be duly accommodated and planned in such a way that they can be carried out without excessive disturbances. Levels of building performance are the degrees of fulfilment of these needs. In the regular, noncomputerized process, due to the actual stage of design knowledge, the performance approach is usually applied only to “hard, engineering-type” attributes (serviceability limit state, ultimate limit state, user’s health and safety, prevention of water penetration and moisture problems. durability and maintenance, fire safety, internal climate, acoustics, lighting, spatial characteristics). Attributes that cannot be expressed in “objective” quantifiable data (the “soft, architectural-type” attributes such as aesthetics, well being, likes and dislikes, meaning and image, contribution of the building to the social coherence, group or corporate identity, etc.) are left to the subjective consideration of the participants in the design process or even tend to be neglected (at least some of them) [IO]. Formalization of the design process for its implementation in a computerized environment cannot yet overcome this limitation. Moreover, even the treatment of those “hard” attributes that are difficult to translate into algorithms or relative simple heuristics proves to be a cumbersome task when the rules of good design practice have to be taught to computers. (Attributes such as water tightness and, to some degree, durability and maintenance, are included in this category.) Even the well established, scientifically based. evalu-
and R. Becker ation methods regarding attributes such as thermal or acoustic performance of buildings, were developed to fit only the present sequence of the design process. Developed for the relatively loose contact between the design manager (usually the architect) and his/her advisors, these methods are suitable for either the nonspecialized professional or the highly specialized expert, The design evaluation and. as a consequence, the evolution of the design solution. are thus based on the designer’s general “rules of good practice” and periodic feedback from the involved specific advisors. The process, being cumbersome and interruptive, may lead to one of the following events: either a design that neglects certain performance requirements or the limitation of the designer’s creativity due to an overly constricted thinking pattern imposed by an overly dominant advisor. The model presented here aims to overcome this cumbersome and interruptive drawback. However. at this stage only attributes having “solid” evaluation methods were implemented in the case study. As shown below, the system will be able to accommodate any other subject as soon as the necessary evaluation methods are developed. 2.3. Charucterization of the problem Three main characteristics of building design distinguish it from common design problems: ill structured process, open endedness, and no fixed starting point [l]. To cope with these characteristics and provide performance evaluation, the structure of a computer model aiming to serve the entire design process must be able to reflect the different abstraction levels emerging during the modeled process and must provide the evaluators with the appropriate existing data. Building models (blueprints or computer models) are destined to store and transfer information regarding the designed building. In their final stage they include all of the information about the building, although most of it in an implicit manner, permitting evaluation of the emerging building attributes only by a trained professional. Appropriate modeling techniques can facilitate the extraction of some implicit information [ 1 I -131, but the particular information that is critical for performance evaluation during early design stages is highly context dependent and, using the above mentioned modeling techniques. can be extracted only when the design is completed. During the early design stages, the intentions of the designer are only vaguely represented by the records he/she makes (usually sketches). At this stage the design brief, containing the knowledge about what is expected to be designed, constitutes a clear context for the interpretation of those early records (see for example [I I]), To permit the interpretation of the design records, models serving the CAD systems must represent not only the results of elapsed design actions but, to some extent, even the undeveloped, expected ones. The CAD system presented in this paper addresses the problems stated above. The system is based on a dynamic model that reflects the graphical representation of the emerging artifact as well as the meaning of the drawing. The model accommodates both former and forthcoming design decisions. allowing interpretations and evaluations to be made.
CAD Model for Performance
Design evolution I:ig. 1. Evolution
of a dynamic
design model
2.4. General characteristics of’ the solution By representing both former and forthcoming design decisions, the model displays, through its structure, the status of the design process. The size of this type of model is inversely related to the design stage. The model is extensive at the beginning of the design, when the range of decisions that might be taken is very large. At the end of the design process the model is relatively small, and it represents “only” the building itself (Fig. 1). As the design process unfolds, the design model changes dynamically. Each design stage is characterized by a certain relation between the two categories of represented decisions. It must be stated here that within the design model the building and the design intent represent the main core, while the assumptions about the decisions to be taken are left to an inference engine providing the necessary assertions only by specific request. Within this approach, separate collections of rules, each representing a specific domain knowledge, are responsible for the development of parts of the design model and for evaluating the represented domain.
3. CAPTURING
THE DESIGN
INTENT
Design intent can be described as the collection of data, knowledge, and reasoning that lead to the creation of a design [14]. The most concise statement of the design intent is the design brief. The brief contains the design constraints and goals and should be clearly stated at the beginning of the design process. The interpretation and processing of the data in the brief differ from designer to designer. These interpretation and creativity differences are responsible for the different outcomes of distinct design processes based on the same brief. Whatever the outcome would be, there is a common pool of knowledge representing the social and professional conventions upon which the communication of the design intent is based. This pool of knowledge gives the professional an understanding of unfinished design documents, such as sketches or notes, even if these documents contain only a small amount of specific information. With the knowledge of the design process, the professional can trace back to the design intent, using the information in the documents and the contents of the brief. An understanding of the design documents, be they
Evaluation
347
completed or working documents, is based on two types of information: direct information and implicit information. Direct information is defined here as the meaning attached by professionals, but not necessarily by the designer him/herself, to the symbols appearing on the design notes or drawings. Examples of direct information are the conventional symbols representing fixtures, the words on notes or sketches, dimensions, etc. The meaning of the direct information is unequivocal and context independent. For example, the meaning of the word “bath” is clear even if it is placed outside the building lines. However, the intent of the designer in this case is not clear. As opposed to direct information, implicit information is not directly placed in the design notes or drawings. It is perceived as the information detailing the intentions of the designer and can be easily extracted by professionals. It is information that emerges from the context of the designer’s actions. An example is the creation of rooms when partitiog N ~11sare drawn. Direct and implicit information are the bases for understanding the design intent and for evaluating the design. As stated above, the system presented here is limited only to the aspects of physical performance of the designed building. As a consequence, the search for direct and implicit information limits itself to information pertinent to the relevant subjects only.
3.1. Capturing the direct injbrmation The direct information in the design documents (sketches, notes, drawings) can take one of two forms: words or drawn symbols. Capturing the information registered in words is a twostep process of reading and matching the information in the appropriate explanatory dictionary. The explanatory dictionary (also called dictionary of terms) is responsible for connecting the information to the performance evaluators described later. Although it is technically possible to use handwriting recognition systems, Optical Character Recognition (OCR), or to enter text directly with a keyboard, the implemented solution was to pick the appropriate meaning directly from a dictionary of terms. This solution was adopted mainly because it allows easy implementation and ensures an error-free environment for the user. A secondary reason for adopting this solution was its consistency with the use of drawn conventional symbols. (A limited example of the conventional symbols implemented in the system is presented in the Picking Tables on the left side of Fig. 5.) Since the conventional symbols are actually graphic representations of the dictionary terms, this solution allowed the construction of a unitary palette of correspondence containing both drawn symbols and written words. Moreover, this solution allowed an easier capture of the implicit information. A more difficult problem is interpreting the lines drawn in a sketch or plan. The adopted solution was to limit the use of the system to the interpretation of horizontal sections (plans). This limitation considers every drawn line to be a wall. Further details about the capturing of direct information are given in Section 5, Implementation, in which the sketch recognition is presented.
348
A. Wiezel and R. Becker
archical
i
storm
I rUorW
&tpU. i
dept.
! d&U.
unit
1’
eUomv
,’ ,’
tree
P = :
rmnniu ’ 1
Fig. 2. Hierarchical
3.2. Capturing the implicit information Implicit information is not directly entered by the designer; rather, it emerges from the direct information. As such, the implicit information will represent components at a different hierarchical level from those directly drawn by the designer. From the point of view of performance evaluation, the most detailed hierarchical level consists of the physical requirements for the activities of the user. However, it is usually impossible for human designers to keep track of all of the requirements of all of the activities taking place during a given time in a given building. To cope at least partially with this problem, architects usually refer to activity zones or areas, each of which implicitly accommodates several activities. These areas can be considered as the “basic data” for the partitioning of a building. Apart from the physical requirements deriving from the accommodated activities, the activity zones are characterized by requirements of size, shape, and specific equipment such as furniture and fixtures. The placement of a specific piece of equipment in a certain place is evidence of the designer’s intention to assign that space to the activity using that equipment. The building can be perceived thus as an assemblage of activity areas grouped together (with overlaps) to form spaces and zones functionally and/or geometrically connected in a hierarchical tree. An example of a generic hierarchical tree for a building is presented in Fig. 2. The bottom-up approach, starting with equipment placement, can be found in the area of single-space-building design. However, for almost all other buildings. designers usually deal at the beginning of the design with larger zones, leaving the assignment of activity areas to later stages. An understanding of the building hierarchy is essential
partitioning
of a building
for capturing the implicit information. A description of the general building hierarchy should be communicated to the computer with the brief. (An example of the interface for hierarchy definition is given in Fig. A3 in the Appendix.) For given types of buildings, generic hierarchies can be archived in a library of building types. For example, the hierarchy for repetitive types of buildings for housing, hotels. office buildings, schools, etc., can be retrieved from the library of building types. In the case of innovative conceptual design, the hierarchy may also be the target of the innovative approach. Appropriate mechanisms are provided to either define the hierarchy at the beginning of the project, and/or to re-define it during the design process itself, when the system could misinterpret implicit information. As the design evolves, the designer concentrates on different levels of subdivisions in the layout, but the underlying assumption is that he/she will always deal with a certain level of functional partition (like units, zones, spaces, etc.). Identifying the hierarchical level of the functional partition allows the system to infer information about the levels that were not directly entered on the sketch. Two categories of inferred implicit information can be identified. Unequivocal information. This is the information representing specific decisions that were made but were not recorded directly. It actually enables the reconstruction of the whole from its parts. Since the relationships between the levels in the defined building hierarchy are of the type “part of ,__”or “contains . ..“. knowing all the parts of a higher level partition means, in fact, that the whole partition is known. Information about the remaining decision possibilities. The borders of a known given partition rep-
CAD Model for Performance resent the boundaries for the placement of its subdivisions, thus limiting the possible assumptions for the positions of the unallocated functions. The way the possible allocations are considered is presented in the next section.
Evaluation
349
The main problem arising from this approach is the tremendous number of possible location combinations to be considered. To overcome this deficiency, a set of natural constrictions has been applied at the stage of capturing the design intent of the intermediate design stages. Spaces belonging to a certain group are checked only within the boundaries of the group. That is, for a given apartment, possible room locations will be checked only within the sketched limits of the apartment. . The hierarchical level (Fig. 2) of the group to be checked will be equal to the lowest hierarchical level of the spaces that were settled by the designer. The adjacency of a space (or hierarchical group of spaces) to a wall is considered as one location, no matter where the considered space can be located along the wall. Corners are treated as distinct locations. Alternative locations are considered only for spaces that were not settled by the designer. Alternative locations contradicting special brief requests, such as landscape facing or predetermined orientation, are not considered. Adjacency combinations for two unsettled spaces are not considered. Although adjacency combinations of types of spaces have to be checked in order to provide appropriate recommendations, these combinations are rather part of the knowledge processing than of the building model.
l
4. A DESIGN MODEL FOR PERFORMANCE EVALUATION 4.1. Predicting the performance Quantitative evaluation of the performances of a given design can be accomplished with some numerical accuracy only when the design is complete. However, many of the factors affecting the performances are settled at the very early stages of conceptual and schematic design. The partial qualitative significance of these factors is generally well known and, translated into design guidelines, appears in written reports, handbooks, and guides for architects. This bulk of information cannot be handled by the designer simultaneously with the design activity, and usually requires different skills from those necessary for conceptual design. It should thus be the task of the automated performance evaluator to “look” at the design drawings, at any point along the design process that the designer requests it, and to submit an evaluation report regarding the decisions already made. The evaluator should also give significant guidance, relevant to the information that already exists in the drawings, for further decisions. In most design situations, the first decisions taken by the designer are with regard to the orientation, general building layout, and allocation of transparent versus opaque areas on the facades. The last decisions are usually those pertaining to specific materials and cross sections of building elements. Thus, at the “sketch” stage, performance evaluation should be related primarily to the defined boundaries of the designed artifacts (commodities, spaces, or groups of them). At later stages, automatic consultations regarding physical properties of building elements may become valuable to the designer. The performance attributes that are significantly affected by the initial design decisions are those depending on local, external conditions. They include the view from the inside, thermal comfort and energy usage, ventilation, acoustics, natural lighting, some aspects of fire and user safety, wind resistance, durability of external finishes, and rain protection. For the present stage of feasibility development of the computerized system, only the first five of these attributes were implemented. Until the introduction of all the others is accomplished the system cannot become a commercially available “automatic advisor”. From the previous discussion we conclude that it is possible to evaluate, to some extent, the foreseen ranges of performances of spaces represented in the drawings. These evaluations will be based exclusively on the assumed location of the spaces. Although the actual performance level will depend on the physical properties of the boundary elements, a strategic advisory declaring the fitness or unsuitability of a specific location will be valid. Thus, the design model must recognize spaces in conjunction with their functions and locations even before the final location of the spaces is decided by the designer.
The resulting building model reflects the actual stage of design and forms the basis for performance evaluation. The design stage is defined by both the available data (decisions that have previously been made) and the hierarchical level of the designed spaces. Appropriate rules, generated to fit the actual stage of design, are responsible for scanning the two main components of the design model: the building and the assumptions. Depending on the source of the supplied information, i.e. the completed design phase or assumption, the same evaluation rule will provide either diagnosis or guidance. The results of the evaluation have to be gathered in a database to permit the user to receive only relevant feedback. 4.2. Modeling for performance evaluation In order to allow the completion of the described process, the design model has to comprise (or to have pointers toward) information about the building, the user and the user’s activities and requirements, the brief (description of the building hierarchy), the site, and the intended building technology (general types of expectable elements). As the activities of the user take place at definite and known parts of the day or night, the system is controlled by a clock that cycles through each part of the representative day for each season. This way the model will represent the different states of the building, taking into account the occurrence of the user’s activities and their interactions. An example of the design model is depicted in Fig. 3. The data structure represented in Fig. 3 constitutes only the seed of the model of a dwelling. The seed contains the necessary information to start the design process before any sketch is made. Seeds are archived and can be modified to serve new projects. As the design evolves, more and more information is gathered about the design
350
A. Wiezel und I-2.Brckrt
\
DsfdtFbart
Fig. 3. Main structure
-
: --
- J-b ffL7d
of the model after the definition
of the brief.
CAD Modelfor
Performance Evaluation
351
a START _ (no sketch)
Fig. 4. Images of the net of objects during the design process.
decisions. This information is stored in the branch representing the emerging building (the “Building” branch in Fig. 3). Information gathering and storage is a two-step process. During the first step the sketches or plans are read and interpreted. In this stage connected lines are converted into shapes, allowing the system to automatically identify the created spaces and the building elements (i.e. walls) as well as the destinations that were already assigned. The information about the created spaces and elements and their links to the plan or sketch are stored in the “Plans” branch of the building model. When the design is finished, this branch completely instantiates the building hierarchy, as represented in the brief. In the second step, destinations are assumed for the unassigned spaces according to the rules presented in the previous section. The assumptions are temporarily stored as “Suppositions” in the model. In the intermediary stages the branch representing suppositions will grow. As more and more information is gained, the supposition branch decreases and the “Certitudes” branch, representing unequivocal situations, will grow to reflect the occurrence of the user activities in the building. Figure 4 illustrates the change of the model during the design process. Figure 4a displays schematically the seed presented in Fig. 3, while Fig. 4b presents in the same schematic manner an intermediate stage of design, the one generated by the sketch on the left. It can be noticed that, at the relatively early design stage depicted in Fig. 4b, the model represents mainly suppositions. The situations and the evaluation branches of the
model are generated by appropriate rules within the constraints explained in the previous section. The situations are, in fact, representations of the assertions made by those rules, and they change as the design develops. Once the evaluation is made, only the relevant situations are to be kept in the model.
5. IMPLEMENTATION A working prototype called PREVENT (PeRformance Evaluation ENlightenment Tool) was developed on the basis of the presented model. PREVENT was developed using KAPPA [ 151 and AutoCAD [ 161, and it is intended to serve as “the performance expert who stands behind the shoulder of the architect”. The general description chart of PREVENT is presented in Fig. 5. This section further details the main components of PREVENT.
5.1. Describing the brief Working in a Windows environment, PREVENT provides an appropriate interface for defining both the brief and the activities of the user as well as for generating the building layouts. Site and technology characteristics have to be drawn from data banks. The description of the user’s activities and of the different spaces in the building should be obtained from the owner or the designer. An appropriate interface was designed to allow an easy description of the site and technology, as well as of the brief. Since this information is accepted by the system as is, it is called declarative information. Other information produced by the system and based on declarative information, is called dynamic information. It is referred to in the section presenting the feedback given by the system.
352
A. Wiezel and R. Becker
I
Performance
Evaluation
i...
: Dynamic Hierarchic i, ._...... Building Model
,.
:
.
T..
i Evaluation Results :
j
f.. 1 .....
IDesign Interpreter
-..’
r-
Correspondence Maker for Graphic Signs
1hteradive AutoUSP
Routines
t
-._---_.--L._____.___-,
I
Geometric and Topologic
/
________v____.._..
DDE (Dynamic Data Exchange)
I /
Hypertext
/ DBMS
I
1
r____-------_,
\ Topologtc Functions I
,
I AutoLlsp
AOutlwS
1
,
L______----_--
1
Picking Tables
I Sketch (AutoCAD)
i Automatic Correction 1 of Sketch Errors
Drawing Tools \
Fg.
5. Main components
I
[ AutoL~Sp
and information
A partial list of the declarative information fed into the system is presented in Fig. 6. All of the information is recorded in an object oriented manner. Specific values are contained in slots and grouped into classes, A class (of objects) can be seen as a “form” in which information has to be filled in. Usually a class will have several instances - forms that have been filled in. For example the class “Activities” refers to how an activity is described within the system, and will have several instances, such as preparing lessons, having dinner, or watching TV. Designers express the user activities and requirements in a form of “fuzzy” natural language (long/short, hot/ warm/cool/cold, quiet/noisy etc.), and they receive the advice or criticism in the same terms. On the other hand
Routines
; 9
1
flow of PREVENT
the evaluation of the performance is done with clear binary logic applied to physical quantities, so a process of defuzzification/fuzzification should be applied. The strictness of the evaluation is determined by fine-tuning the fuzzification process. At this stage the system is based on the conventional set theory, meaning that the terms used (hot/warm/cool,cold, long/short, etc.) are mutually exclusive when applied to the measure they describe (such as temperature, duration, etc.). 5.2. Sketch recognition The layout generation can be done either by typical CAD methods or as “free hand” sketches (by means of computer aids). Since by convention all the direct information is introduced by using symbols from the
CAD Modelfor
CLASS
SLOT
Activities:
Avg_Noise_Level DaylightingCategory Duration Intensity Max_Permissible_Noise Occurrence(list) Quiet-Noise-Level SummerClo(descriptor) SummerIcl(value) Sunlight_Requirement Thermal_Sensitivity VisualContact WinterClo(descriptor) WinterIcl(value) No_of_Apartments Pti_of_Story Rooms (list) Intensity Period (list) Icl
Aptmt_Types
BasicActivits Clothing_Ens embls: Clock
Performance
353
Evaluation
Noise-Intensity (list) Noise_Source_Coord. (list) WindDirection
Part_of_day (list) Seasons (list) Fig. 6. Slots containing declarative information.
Picking Table (see Fig. 5) it is assumed that the “free hand” drawn lines represent walls. By default, the underlying CAD modeler (AutoCAD) will store the lines on a specially defined layer, namely WALLS. The symbols selected from the Picking Table have a layer of their own (different from WALLS), and contain relevant alphanumeric attributes (such as name, number, destination, type, etc.). Furthermore, the symbols have one or two insertion points. For example, the indication of a specific apartment (using the sign “Ap.” in the Picking Table of Fig. 5) is done by indicating a single reference point, while the staircase (presented in Fig. 5) will be inserted, using two representative corners. For the objects defined by two points, an “artificial” reference point was defined in the middle of the object. Reference points are used by the algorithm that identifies the indicated areas, described below. The definition of the conventional symbols is done by the user and has to match the hierarchies defined in the brief. However, since each designer usually develops a personal pool of conventional symbols, the definition process can be done once. In this process, called “the personalization of the system”, further modifications are enabled upon request. Most of the symbols are externally referenced blocks with attributes. In order to enable the automatic identification (as much as possible) of the physical meaning of the graphic input, the system is provided with a sketch transformer and interpreter. The sketch transformer, implemented in AutoLISP, can be fine tuned to fit the drawing accuracy of the user. Fine tuning is based on two parameters which are easily depicted by the human eye: maximal gap (between lines) that should be closed, and maximal slant
deviation. Figure 7 illustrates the depiction of the two parameters. Although the fine tuning process is interactive and iterative, no more than two iterations are usually necessary to convert the sketch into a drawing that can be evaluated by the system. The sketch transformer works in five steps, described below and exemplified in Fig. 8. The drawings on the left are presented the way the original sketch appears on the computer screen after the completion of each step, while the ones on the right are explosion presentations of the drawings on the left. The five steps performed by the sketch transformer are as folllows. 1. It straightens the segments (makes them horizontal or vertical). 2. It connects the ends of the segments that are within the assumed drawing errors (gap and slant). 3. It transforms the multiple overlapping (or almost overlapping) lines into single lines of maximum length. 4. It trims and connects the corners. 5. It divides the lines into separate segments defined between the intersections. Once the sketch is transformed and the walls segmented, a second algorithm, responsible for identifying adjacencies, is called into action. Since all the walls are segmented, every wall will separate two and only two adjacent spaces. However, the same two spaces can be separated by more than one wall. The performance evaluation is based on the function of the walls (containing closed openings) to separate spaces. Exterior walls are a special case, separating a space from the exterior. The algorithm that identifies the spaces’ boundaries
354
A. Wiezel and R. Becker
Free hand Sketch r
Maxima1 S1ant
This gap will be left open The slant of this line will not change
Corrected
Fig. 7. Depicting
Sketch
the maximal
gap and maximal and,
Step
0
On screen
Exploded
1
2 cl 3 0 4 cl
slant for a sketch
as a consequence.
their
adjacencies,
uses
a simple
to find closed contours. The way the routine works can be best described by using an analogy to a mouse who is trying to exit a room with closed doors (Fig. 9). The mouse starts from a given point and runs to a wall, then runs along the walls in the same direction (clockwise, for example). When the mouse passes the second time through the same point. it has marked all the walls of the given room. Special attention has to be given to the way the mouse turns at intersections. The mouse should follow the path (wall) making the largest angle (clockwise in our convention) with the direction he comes from. Since in the adopted representation walls have no width, several exceptions are intercepted and treated as special cases. (For example, the internal-to-room wall shown in room B of Fig. 9.) The starting points for the algorithm are the reference points of the conventional symbols mentioned earlier. The case of the exterior walls is solved in a similar manner, with the lower left-most corner of the building chosen as a starting point (point S in Fig. 9) the point at which the mouse will start trying to enter the building. The choice of the starting point proved to have a major influence on the simplicity of the algorithm. At the end of the adjacency identification process a wall can be in one of the following situations. routine
I. The spaces (rooms) on both sides are assigned and, as
5 0
far as the performance evaluator is concerned, known with certitude. 2. Only the space on one side is known with certitude. 3. None of the adjacent spaces is known (at this stage of evaluation). Fig. 8. Steps for transforming
a sketch
Because
of the problem
of too many
repetitive
com-
CAD Model for Performance
355
Evaluation
y--__----_----_ti Fig. 9. Identifying contours of rooms and the whole building.
binations, the system walls of types 1 and walls but were drawn recognizable adjacent system.
analyses only situations created by 2. Since lines that do not represent on the sketch will usually have no spaces, they will be ignored by the
5.3. Feedback The interface was developed with the assumption that designers prefer to receive feedback only by request and, therefore, that the user will turn off a system warning that sounds each time an improper decision is emerging. In addition to reducing the annoyance by the system, evaluation upon request allows the designer to complete the information he/she wants to be checked and decreases the wrong guesses of the computer. Appropriate dialog boxes guide the designer in defining the activities of the user and the building hierarchy. Based on the needs of the user, as stated in the brief, and on the information resulting from the interpreted sketch, PREVENT evaluates the following aspects: the view from the inside, thermal comfort and energy usage, ventilation, acoustics, and natural lighting. During the evaluation, the system will make different assumptions based on the data in the brief and the design stage, and will create new data (information*). This type of data is called dynamic data and it is also organized in an object oriented manner (as the declarative information in the description of the design brief). Figure 10 presents a list of the dynamic information generated by the system. The results of the evaluation are stored and presented in six groups. Best design decisions: lists the situations (location and occurrence of activities) that will be particularly well hosted by the building. Non-efficient design decisions: lists the locations that over-perform the needs of the user. It is supposed that those locations can be better used for other activities. Improper design decisions: lists the situations when the needs of the user are not matched. Conflicting situations: lists both the situation and the causes of the conflicts. The system does not attempt to solve the conflict. Examples of identified conflicts
* By defimtion information means structured data.
are: required position of the blinds on summer afternoons during family dining (open for viewing the landscape/closed to prevent high energy gains), status of the window during sleeping in the master bedroom in summer nights (open for ventilation, closed to prevent noise), etc. Hints: similar to best design decisions, with the difference that the locations considered are not assigned by the designer, but by the computer. Possible locations are checked according to the principles explained in section “Predicting the performance”. Warnings: lists the still unassigned locations that are unsuitable for specific activities. An English-like report generator was implemented to present the results. The report is generated automatically by browsing the instances of the objects representing the six categories of evaluation described above. Figure 11 depicts an example of how the values generated by the system fill the slots in the lines of the report. An example of using the system is presented in the Appendix.
6. CONCLUSION Design efficiency and quality can be improved by releasing the designer from the technical activity of performance evaluation and enabling him/her to concentrate on the creative aspects of the design. At the earlier design stages the use of classical geometric modeling as a basis for integrative CAD systems proves to be insufficient for accommodating even conventional performance evaluation. To allow the juxtaposition of several design tasks such as evaluation, data seeking, and coordination, explicit representation of the design decisions should be provided. A comprehensive design model should thus include specific representation means to serve the design evaluators and generators, and a form of common geometric model. Due to the complexity of the considered problems, the design model must have an open data structure, such as tree or lattice, in which any of separate design aspects can have its own representation branch and links to the pertinent data from other branches. This paper focuses
A. Wiezel and R. Becker
356
CLASS Situations:
Functionalities
Conflictual
Activity
Fig. 10. Slots contammg
dynamic
INSTANCE:
SLOT Blinds Blinds-Activity Blinds-Cause Critical_Acoustic_Activity Critical_Thermal_Activity EnergyGain InRoom_Activities (list) Occurrence Opened_Window_Activity Opened Window Cause Other_side_Activ%es (list) Other_side_Room Penetrating-Noise Quiet_Noise_Level Season Thermal-Sensitivity Var Wall
information.
W4_4 1
Parent:
Apl_LivingRoom_Unsuited_Winter Description
=&
I Season = Winter
I Occurrence
= afternoon
I
Room= Api_Livi
1
I
, i:::_.:c1
i
t
. It will be &
in winter afternoons
during family dining near wall I%! in LivingRom
Fig. 11. Example
of report
only on the modeling of a relatively limited section of the design process, the performance evaluation. The prototype intelligent CAD system developed on the basis of the presented design model deals with a limited number of attributes, but it enlightens the complexity of this system on one hand and its advantages on the other. The use of the system may help prevent the
line generated
of&&_!
by PREVENT.
design of both inadequate
and over-designed solutions by extensively comparing the behavior of the building with the user requirements while taking into account their variation during the periods of day and night, summer and winter, etc. It also permits the gaining of extensive experience by providing hints and criticism relative to many different design alternatives.
REFERENCES
I.
M. de Vries and H. Wagter.
A CAAD
model for use in early design phases.
In The Elecrronic~ Design
CAD Model for Performance
2. 3. 4. 5. 6. 7. 8. 9.
10. 11. 12. 13. 14. 15. 16.
Evaluation
351
Studio (Edited by M. McCullough, W. J. Mitchelland P. Purcell), pp. 215-228, MIT Press, Cambridge, MA (1990). S. Port, The Management of CAD for Construction, BSP Professional Books, London (1989). C. M. Eastman, Modeling of buildings: evolution and concepts. Automation in Construction 2, 99% 109 (1992). G. Schmidt, Classes of design ~ classes of tools. In The Electronic Design Studio (Edited by M. McCullough, W. J. Mitchell and P. Purcell), pp. 77790, MIT Press, Cambridge, MA (1990). G. Carrara, Y. E. Kalay and G. Novembri, Multi-modal representation of design knowledge. Automation in Construction 2, 11l-121 (1992). G. A. van Nederveen and F. P. Tolman, Modeling multiple views of buildings. Automation in Construction 2, 215-224 (1992). T. Froese, Project modeling and data standards for AEC: concepts. IRMA-tica’93, E-Mail Workshop on the IRMA modelfor Computer-Integrated Construction, Gopher: (1993). R. Becker and A. Wiezel, A computerized system for performance integrated computer aided design. Architectural Science Review 36, 113-l 19 (1993). R. Oxman and R. Oxman, The computability of architectural knowledge. In The Electronic Design Studio (Edited by M. McCullough, W. J. Mitchell and P. Purcell), pp. 171-l 86, MIT Press, Cambridge, MA (1990). P. R. Jockusch, How can we achieve a good building? In Evaluating and Predicting Design Performance (Edited by Y. E. Kalay), pp. 51-65, John Wiley, New York (1992). A. van Kempen, H. Kok and H. Wagter, Design modelling. Automarion in Construction 2, l-13 (1992). Y. Yamazaki, Integrated design and construction planning system for Computer Integrated Construction. Automation in Construction 2, 21-26 (1992). A. Shapira, Octree subdivision of building elements. ASCE Journal of Computing in Civil Engineering 7,439457 (1993). J. M. De La Garza and P. Alcantra Jr, Applications of design intent in value engineering. AIENG ‘93 Conference, Toulouse, France (1993). IntelliCorp, Inc., KAPPA-PC reference manual, version 1.2, Mountain View, CA (1992). Autodesk, Inc., AutoCAD Release 10, user manual, Sausalito, CA (1989).
APPENDIX A sample of the use of the system is shown in Figs Al and A2. More dialog boxes collect data about typical clothing, and landscape (see Figs A3-A8).
pfnt
Edit
Eontml
1
Qptions
&indow
Check the design
Image
1
F,
FkRtomance Naluatlon ENllghtment Tool TECHNION ISRAEL :aculty of CMI Engineering
Fig. Al. PREVENT
~ main screen
noise, lighting
358
A. Wiezel and R. Becker
CAD Modelfor
Performance
Evaluation
See Defined ActMy Zones
Dcffne New ActMly Zone
See Deffned Types of Rooms
Dcflnc New Type of Room
Fig. A3. Visualization
Fig. A4. Designation
of the defined room types,
of maximal
linear error.
359
360
A. Wiezel and R. Becker
Fig. A5. Designation
Fig. A6. Use of conventional
of maximal
symbols
angular
errors.
to designate
zones
361
CAD Model for Performance Evaluation
..J.$ ,,;.l’i: ‘i; , / ii >,.-.:,$ ?i‘.* I’
.
/ ;
‘x .’ 7
/
-. fL.z * . -$y;:::
* . ...p+ ?-%. ... .. .. ... .... ... .... .. .. .... ..... ..... ..2..
Fig. A7. Use of conventional
Pint
EdiI control
QpUons
symbols
to designate
orientation
Wndow
It will be Yarn in AfternOOn during FamilyDining It will be Yam in Noon during FamilyDining
It rill be Cold in Afternoon during FamilyDining 11 be Cold in Moon during FamilyDining
Fig. AS. Example
of a report.
(north).
Pergamon PII: SO360-1323(96)00004-2
CAD Model for Performance A. WIEZEL* R. BECKERf
Evaluation
(Received 28 March 1995; accepted 21 November 1995)
A CAD assistant, PREVENT, has been developed to help evaluate building performance during the various design stages. The system accommodates the whole design process and provides both evaluation and diagnosis upon request. It has the capability to capture the design intent directly from sketches and to evaluate the jitness of the emerging solution to the demands of the building user. The structure and the functions of various components of evaluation by PREVENT are presented. A design model for a performance evaluation by PREVENT is proposed and tested. Copyright 0 1996 Elsevier Science Ltd.
1. INTRODUCTION 1.1.
and building occupancy. (For detailed reports on BMPs consult < irma.hs.jhu.edu > through Gopher.) If these models are to materialize, the design artifact, the building, should be represented in a manner that satisfies all the participants throughout the entire design and planning process. However, the cost of such an extensive representation is prohibitive despite the development of the appropriate computer technology [2, 31. The common solution is to use different tools for different stages and aspects of the process, with each tool having its own model [4]. Unfortunately, this approach, by its nature, does not solve the problems arising from the above mentioned factors. Recent reports [S-7], however, suggest that integrative CAD tools, destined to model the whole design process, are about to emerge. These tools will benefit from the advancements in computer science and cognitive science and will be able to support the whole design process both in depth (from conceptual to detailed design) and in breadth (will serve all the participants). They are based on specifically developed building models and will require the designer to follow a given (new) design and modeling method. In this paper, the authors present a new design and modeling tool that will support the whole design process.
Background
Building design is a complex creative process involving the participation of investors, developers, owners, architects, advisors and, sometimes, contractors. The concerns of these participants, who may have opposing goals, are usually very different. Therefore, steering the design process is a difficult task that is encumbered by the following factors. l
l
l
l
l
The number of aspects to be simultaneously considered and the large volume of information and knowledge to be dealt with is beyond the capacity of the human brain [ 11. Lack of knowledge in certain domains may cause potential problems to be overlooked and, as a consequence, relevant advisors will not even be included in the design team. The various advisors participating in the design process usually do not efficiently communicate with one another, and the participation in the design process is as an individual (at pre-defined stages) rather than as an integrated team. The narrow specialization of individual advisors, combined with their differing personal character and reputation, can induce an unequilibrated consideration of recommendations. Because in many cases the intended user of the designed building is the party with the least technical knowledge, his/her interests are often insufficiently considered.
1.2. Objectives The authors’ view of Computer Aided Design tools is that a CAD system should ideally not only represent the model of the designed artifact, but should also act as an expert who “stands behind the shoulder of the designer”. The CAD system should interfere as little as possible with the design habits of its user. However, while viewing the drawings as they are created during the design process, this expert should be ready, upon request, to state opinions and comments. The main objective of this study was to investigate and demonstrate the feasibility of such a CAD system. The general description of the CAD system, and the guiding philosophy, were presented previously [S]. This paper presents the computerized model that was developed to support the CAD system and the approach that led to this model. The prototype that was developed
The computer can theoretically overcome these problems by hosting the whole design process and providing support for the decision making. Indeed, extensive efforts are being made to develop building product models (BPMs) so that they can offer a framework for multiple users during all the stages of design, contracting, erection,
*Del E. Webb School of Construction, Arizona sity, Tempe, AZ 85287, U.S.A. iDepartment of Civil Engineering, Technion, Israel.
State UniverHaifa
32000,
345
346
A. Wiezel
attempts to enrich the content of current CAD models, allowing accommodation of not only the designed artifact (the design decisions) but also the design intent and its implications. The model works as an attachment to existing CAD systems (such as AutoCAD), permitting the designer to follow his/her own design habits.
2. DEVELOPMENT 2.1. Basic considerations The transforming of the design intent into a design solution constitutes the core of the design process. This transformation is commonly referred to as the synthesis stage in a three-step design cycle: analysis, synthesis, and evaluation. Except for those cases in which it is based on prescribed procedures, the synthesis activity is not yet well understood. Despite some success reported in formalizing the process of generating design solutions, synthesis is still considered a creative activity best left to humans. The remaining two components of the design cycle, analysis to establish the design intent and evaluation of the design alternatives, are considered to be more susceptible to formalization. They constitute the main interest of this study. 2.2. Limitations Despite the efforts made to formalize design knowledge and practice (for a comprehensive survey see [9]), the only systematic method for design analysis and evaluation is by applying the performance concept in design. Performance requirements and criteria reflect, in rational and rather quantifiable type terms, the needs of human users and others. Therefore, all the typical activities must be duly accommodated and planned in such a way that they can be carried out without excessive disturbances. Levels of building performance are the degrees of fulfilment of these needs. In the regular, noncomputerized process, due to the actual stage of design knowledge, the performance approach is usually applied only to “hard, engineering-type” attributes (serviceability limit state, ultimate limit state, user’s health and safety, prevention of water penetration and moisture problems. durability and maintenance, fire safety, internal climate, acoustics, lighting, spatial characteristics). Attributes that cannot be expressed in “objective” quantifiable data (the “soft, architectural-type” attributes such as aesthetics, well being, likes and dislikes, meaning and image, contribution of the building to the social coherence, group or corporate identity, etc.) are left to the subjective consideration of the participants in the design process or even tend to be neglected (at least some of them) [IO]. Formalization of the design process for its implementation in a computerized environment cannot yet overcome this limitation. Moreover, even the treatment of those “hard” attributes that are difficult to translate into algorithms or relative simple heuristics proves to be a cumbersome task when the rules of good design practice have to be taught to computers. (Attributes such as water tightness and, to some degree, durability and maintenance, are included in this category.) Even the well established, scientifically based. evalu-
and R. Becker ation methods regarding attributes such as thermal or acoustic performance of buildings, were developed to fit only the present sequence of the design process. Developed for the relatively loose contact between the design manager (usually the architect) and his/her advisors, these methods are suitable for either the nonspecialized professional or the highly specialized expert, The design evaluation and. as a consequence, the evolution of the design solution. are thus based on the designer’s general “rules of good practice” and periodic feedback from the involved specific advisors. The process, being cumbersome and interruptive, may lead to one of the following events: either a design that neglects certain performance requirements or the limitation of the designer’s creativity due to an overly constricted thinking pattern imposed by an overly dominant advisor. The model presented here aims to overcome this cumbersome and interruptive drawback. However. at this stage only attributes having “solid” evaluation methods were implemented in the case study. As shown below, the system will be able to accommodate any other subject as soon as the necessary evaluation methods are developed. 2.3. Charucterization of the problem Three main characteristics of building design distinguish it from common design problems: ill structured process, open endedness, and no fixed starting point [l]. To cope with these characteristics and provide performance evaluation, the structure of a computer model aiming to serve the entire design process must be able to reflect the different abstraction levels emerging during the modeled process and must provide the evaluators with the appropriate existing data. Building models (blueprints or computer models) are destined to store and transfer information regarding the designed building. In their final stage they include all of the information about the building, although most of it in an implicit manner, permitting evaluation of the emerging building attributes only by a trained professional. Appropriate modeling techniques can facilitate the extraction of some implicit information [ 1 I -131, but the particular information that is critical for performance evaluation during early design stages is highly context dependent and, using the above mentioned modeling techniques. can be extracted only when the design is completed. During the early design stages, the intentions of the designer are only vaguely represented by the records he/she makes (usually sketches). At this stage the design brief, containing the knowledge about what is expected to be designed, constitutes a clear context for the interpretation of those early records (see for example [I I]), To permit the interpretation of the design records, models serving the CAD systems must represent not only the results of elapsed design actions but, to some extent, even the undeveloped, expected ones. The CAD system presented in this paper addresses the problems stated above. The system is based on a dynamic model that reflects the graphical representation of the emerging artifact as well as the meaning of the drawing. The model accommodates both former and forthcoming design decisions. allowing interpretations and evaluations to be made.
CAD Model for Performance
Design evolution I:ig. 1. Evolution
of a dynamic
design model
2.4. General characteristics of’ the solution By representing both former and forthcoming design decisions, the model displays, through its structure, the status of the design process. The size of this type of model is inversely related to the design stage. The model is extensive at the beginning of the design, when the range of decisions that might be taken is very large. At the end of the design process the model is relatively small, and it represents “only” the building itself (Fig. 1). As the design process unfolds, the design model changes dynamically. Each design stage is characterized by a certain relation between the two categories of represented decisions. It must be stated here that within the design model the building and the design intent represent the main core, while the assumptions about the decisions to be taken are left to an inference engine providing the necessary assertions only by specific request. Within this approach, separate collections of rules, each representing a specific domain knowledge, are responsible for the development of parts of the design model and for evaluating the represented domain.
3. CAPTURING
THE DESIGN
INTENT
Design intent can be described as the collection of data, knowledge, and reasoning that lead to the creation of a design [14]. The most concise statement of the design intent is the design brief. The brief contains the design constraints and goals and should be clearly stated at the beginning of the design process. The interpretation and processing of the data in the brief differ from designer to designer. These interpretation and creativity differences are responsible for the different outcomes of distinct design processes based on the same brief. Whatever the outcome would be, there is a common pool of knowledge representing the social and professional conventions upon which the communication of the design intent is based. This pool of knowledge gives the professional an understanding of unfinished design documents, such as sketches or notes, even if these documents contain only a small amount of specific information. With the knowledge of the design process, the professional can trace back to the design intent, using the information in the documents and the contents of the brief. An understanding of the design documents, be they
Evaluation
347
completed or working documents, is based on two types of information: direct information and implicit information. Direct information is defined here as the meaning attached by professionals, but not necessarily by the designer him/herself, to the symbols appearing on the design notes or drawings. Examples of direct information are the conventional symbols representing fixtures, the words on notes or sketches, dimensions, etc. The meaning of the direct information is unequivocal and context independent. For example, the meaning of the word “bath” is clear even if it is placed outside the building lines. However, the intent of the designer in this case is not clear. As opposed to direct information, implicit information is not directly placed in the design notes or drawings. It is perceived as the information detailing the intentions of the designer and can be easily extracted by professionals. It is information that emerges from the context of the designer’s actions. An example is the creation of rooms when partitiog N ~11sare drawn. Direct and implicit information are the bases for understanding the design intent and for evaluating the design. As stated above, the system presented here is limited only to the aspects of physical performance of the designed building. As a consequence, the search for direct and implicit information limits itself to information pertinent to the relevant subjects only.
3.1. Capturing the direct injbrmation The direct information in the design documents (sketches, notes, drawings) can take one of two forms: words or drawn symbols. Capturing the information registered in words is a twostep process of reading and matching the information in the appropriate explanatory dictionary. The explanatory dictionary (also called dictionary of terms) is responsible for connecting the information to the performance evaluators described later. Although it is technically possible to use handwriting recognition systems, Optical Character Recognition (OCR), or to enter text directly with a keyboard, the implemented solution was to pick the appropriate meaning directly from a dictionary of terms. This solution was adopted mainly because it allows easy implementation and ensures an error-free environment for the user. A secondary reason for adopting this solution was its consistency with the use of drawn conventional symbols. (A limited example of the conventional symbols implemented in the system is presented in the Picking Tables on the left side of Fig. 5.) Since the conventional symbols are actually graphic representations of the dictionary terms, this solution allowed the construction of a unitary palette of correspondence containing both drawn symbols and written words. Moreover, this solution allowed an easier capture of the implicit information. A more difficult problem is interpreting the lines drawn in a sketch or plan. The adopted solution was to limit the use of the system to the interpretation of horizontal sections (plans). This limitation considers every drawn line to be a wall. Further details about the capturing of direct information are given in Section 5, Implementation, in which the sketch recognition is presented.
348
A. Wiezel and R. Becker
archical
i
storm
I rUorW
&tpU. i
dept.
! d&U.
unit
1’
eUomv
,’ ,’
tree
P = :
rmnniu ’ 1
Fig. 2. Hierarchical
3.2. Capturing the implicit information Implicit information is not directly entered by the designer; rather, it emerges from the direct information. As such, the implicit information will represent components at a different hierarchical level from those directly drawn by the designer. From the point of view of performance evaluation, the most detailed hierarchical level consists of the physical requirements for the activities of the user. However, it is usually impossible for human designers to keep track of all of the requirements of all of the activities taking place during a given time in a given building. To cope at least partially with this problem, architects usually refer to activity zones or areas, each of which implicitly accommodates several activities. These areas can be considered as the “basic data” for the partitioning of a building. Apart from the physical requirements deriving from the accommodated activities, the activity zones are characterized by requirements of size, shape, and specific equipment such as furniture and fixtures. The placement of a specific piece of equipment in a certain place is evidence of the designer’s intention to assign that space to the activity using that equipment. The building can be perceived thus as an assemblage of activity areas grouped together (with overlaps) to form spaces and zones functionally and/or geometrically connected in a hierarchical tree. An example of a generic hierarchical tree for a building is presented in Fig. 2. The bottom-up approach, starting with equipment placement, can be found in the area of single-space-building design. However, for almost all other buildings. designers usually deal at the beginning of the design with larger zones, leaving the assignment of activity areas to later stages. An understanding of the building hierarchy is essential
partitioning
of a building
for capturing the implicit information. A description of the general building hierarchy should be communicated to the computer with the brief. (An example of the interface for hierarchy definition is given in Fig. A3 in the Appendix.) For given types of buildings, generic hierarchies can be archived in a library of building types. For example, the hierarchy for repetitive types of buildings for housing, hotels. office buildings, schools, etc., can be retrieved from the library of building types. In the case of innovative conceptual design, the hierarchy may also be the target of the innovative approach. Appropriate mechanisms are provided to either define the hierarchy at the beginning of the project, and/or to re-define it during the design process itself, when the system could misinterpret implicit information. As the design evolves, the designer concentrates on different levels of subdivisions in the layout, but the underlying assumption is that he/she will always deal with a certain level of functional partition (like units, zones, spaces, etc.). Identifying the hierarchical level of the functional partition allows the system to infer information about the levels that were not directly entered on the sketch. Two categories of inferred implicit information can be identified. Unequivocal information. This is the information representing specific decisions that were made but were not recorded directly. It actually enables the reconstruction of the whole from its parts. Since the relationships between the levels in the defined building hierarchy are of the type “part of ,__”or “contains . ..“. knowing all the parts of a higher level partition means, in fact, that the whole partition is known. Information about the remaining decision possibilities. The borders of a known given partition rep-
CAD Model for Performance resent the boundaries for the placement of its subdivisions, thus limiting the possible assumptions for the positions of the unallocated functions. The way the possible allocations are considered is presented in the next section.
Evaluation
349
The main problem arising from this approach is the tremendous number of possible location combinations to be considered. To overcome this deficiency, a set of natural constrictions has been applied at the stage of capturing the design intent of the intermediate design stages. Spaces belonging to a certain group are checked only within the boundaries of the group. That is, for a given apartment, possible room locations will be checked only within the sketched limits of the apartment. . The hierarchical level (Fig. 2) of the group to be checked will be equal to the lowest hierarchical level of the spaces that were settled by the designer. The adjacency of a space (or hierarchical group of spaces) to a wall is considered as one location, no matter where the considered space can be located along the wall. Corners are treated as distinct locations. Alternative locations are considered only for spaces that were not settled by the designer. Alternative locations contradicting special brief requests, such as landscape facing or predetermined orientation, are not considered. Adjacency combinations for two unsettled spaces are not considered. Although adjacency combinations of types of spaces have to be checked in order to provide appropriate recommendations, these combinations are rather part of the knowledge processing than of the building model.
l
4. A DESIGN MODEL FOR PERFORMANCE EVALUATION 4.1. Predicting the performance Quantitative evaluation of the performances of a given design can be accomplished with some numerical accuracy only when the design is complete. However, many of the factors affecting the performances are settled at the very early stages of conceptual and schematic design. The partial qualitative significance of these factors is generally well known and, translated into design guidelines, appears in written reports, handbooks, and guides for architects. This bulk of information cannot be handled by the designer simultaneously with the design activity, and usually requires different skills from those necessary for conceptual design. It should thus be the task of the automated performance evaluator to “look” at the design drawings, at any point along the design process that the designer requests it, and to submit an evaluation report regarding the decisions already made. The evaluator should also give significant guidance, relevant to the information that already exists in the drawings, for further decisions. In most design situations, the first decisions taken by the designer are with regard to the orientation, general building layout, and allocation of transparent versus opaque areas on the facades. The last decisions are usually those pertaining to specific materials and cross sections of building elements. Thus, at the “sketch” stage, performance evaluation should be related primarily to the defined boundaries of the designed artifacts (commodities, spaces, or groups of them). At later stages, automatic consultations regarding physical properties of building elements may become valuable to the designer. The performance attributes that are significantly affected by the initial design decisions are those depending on local, external conditions. They include the view from the inside, thermal comfort and energy usage, ventilation, acoustics, natural lighting, some aspects of fire and user safety, wind resistance, durability of external finishes, and rain protection. For the present stage of feasibility development of the computerized system, only the first five of these attributes were implemented. Until the introduction of all the others is accomplished the system cannot become a commercially available “automatic advisor”. From the previous discussion we conclude that it is possible to evaluate, to some extent, the foreseen ranges of performances of spaces represented in the drawings. These evaluations will be based exclusively on the assumed location of the spaces. Although the actual performance level will depend on the physical properties of the boundary elements, a strategic advisory declaring the fitness or unsuitability of a specific location will be valid. Thus, the design model must recognize spaces in conjunction with their functions and locations even before the final location of the spaces is decided by the designer.
The resulting building model reflects the actual stage of design and forms the basis for performance evaluation. The design stage is defined by both the available data (decisions that have previously been made) and the hierarchical level of the designed spaces. Appropriate rules, generated to fit the actual stage of design, are responsible for scanning the two main components of the design model: the building and the assumptions. Depending on the source of the supplied information, i.e. the completed design phase or assumption, the same evaluation rule will provide either diagnosis or guidance. The results of the evaluation have to be gathered in a database to permit the user to receive only relevant feedback. 4.2. Modeling for performance evaluation In order to allow the completion of the described process, the design model has to comprise (or to have pointers toward) information about the building, the user and the user’s activities and requirements, the brief (description of the building hierarchy), the site, and the intended building technology (general types of expectable elements). As the activities of the user take place at definite and known parts of the day or night, the system is controlled by a clock that cycles through each part of the representative day for each season. This way the model will represent the different states of the building, taking into account the occurrence of the user’s activities and their interactions. An example of the design model is depicted in Fig. 3. The data structure represented in Fig. 3 constitutes only the seed of the model of a dwelling. The seed contains the necessary information to start the design process before any sketch is made. Seeds are archived and can be modified to serve new projects. As the design evolves, more and more information is gathered about the design
350
A. Wiezel und I-2.Brckrt
\
DsfdtFbart
Fig. 3. Main structure
-
: --
- J-b ffL7d
of the model after the definition
of the brief.
CAD Modelfor
Performance Evaluation
351
a START _ (no sketch)
Fig. 4. Images of the net of objects during the design process.
decisions. This information is stored in the branch representing the emerging building (the “Building” branch in Fig. 3). Information gathering and storage is a two-step process. During the first step the sketches or plans are read and interpreted. In this stage connected lines are converted into shapes, allowing the system to automatically identify the created spaces and the building elements (i.e. walls) as well as the destinations that were already assigned. The information about the created spaces and elements and their links to the plan or sketch are stored in the “Plans” branch of the building model. When the design is finished, this branch completely instantiates the building hierarchy, as represented in the brief. In the second step, destinations are assumed for the unassigned spaces according to the rules presented in the previous section. The assumptions are temporarily stored as “Suppositions” in the model. In the intermediary stages the branch representing suppositions will grow. As more and more information is gained, the supposition branch decreases and the “Certitudes” branch, representing unequivocal situations, will grow to reflect the occurrence of the user activities in the building. Figure 4 illustrates the change of the model during the design process. Figure 4a displays schematically the seed presented in Fig. 3, while Fig. 4b presents in the same schematic manner an intermediate stage of design, the one generated by the sketch on the left. It can be noticed that, at the relatively early design stage depicted in Fig. 4b, the model represents mainly suppositions. The situations and the evaluation branches of the
model are generated by appropriate rules within the constraints explained in the previous section. The situations are, in fact, representations of the assertions made by those rules, and they change as the design develops. Once the evaluation is made, only the relevant situations are to be kept in the model.
5. IMPLEMENTATION A working prototype called PREVENT (PeRformance Evaluation ENlightenment Tool) was developed on the basis of the presented model. PREVENT was developed using KAPPA [ 151 and AutoCAD [ 161, and it is intended to serve as “the performance expert who stands behind the shoulder of the architect”. The general description chart of PREVENT is presented in Fig. 5. This section further details the main components of PREVENT.
5.1. Describing the brief Working in a Windows environment, PREVENT provides an appropriate interface for defining both the brief and the activities of the user as well as for generating the building layouts. Site and technology characteristics have to be drawn from data banks. The description of the user’s activities and of the different spaces in the building should be obtained from the owner or the designer. An appropriate interface was designed to allow an easy description of the site and technology, as well as of the brief. Since this information is accepted by the system as is, it is called declarative information. Other information produced by the system and based on declarative information, is called dynamic information. It is referred to in the section presenting the feedback given by the system.
352
A. Wiezel and R. Becker
I
Performance
Evaluation
i...
: Dynamic Hierarchic i, ._...... Building Model
,.
:
.
T..
i Evaluation Results :
j
f.. 1 .....
IDesign Interpreter
-..’
r-
Correspondence Maker for Graphic Signs
1hteradive AutoUSP
Routines
t
-._---_.--L._____.___-,
I
Geometric and Topologic
/
________v____.._..
DDE (Dynamic Data Exchange)
I /
Hypertext
/ DBMS
I
1
r____-------_,
\ Topologtc Functions I
,
I AutoLlsp
AOutlwS
1
,
L______----_--
1
Picking Tables
I Sketch (AutoCAD)
i Automatic Correction 1 of Sketch Errors
Drawing Tools \
Fg.
5. Main components
I
[ AutoL~Sp
and information
A partial list of the declarative information fed into the system is presented in Fig. 6. All of the information is recorded in an object oriented manner. Specific values are contained in slots and grouped into classes, A class (of objects) can be seen as a “form” in which information has to be filled in. Usually a class will have several instances - forms that have been filled in. For example the class “Activities” refers to how an activity is described within the system, and will have several instances, such as preparing lessons, having dinner, or watching TV. Designers express the user activities and requirements in a form of “fuzzy” natural language (long/short, hot/ warm/cool/cold, quiet/noisy etc.), and they receive the advice or criticism in the same terms. On the other hand
Routines
; 9
1
flow of PREVENT
the evaluation of the performance is done with clear binary logic applied to physical quantities, so a process of defuzzification/fuzzification should be applied. The strictness of the evaluation is determined by fine-tuning the fuzzification process. At this stage the system is based on the conventional set theory, meaning that the terms used (hot/warm/cool,cold, long/short, etc.) are mutually exclusive when applied to the measure they describe (such as temperature, duration, etc.). 5.2. Sketch recognition The layout generation can be done either by typical CAD methods or as “free hand” sketches (by means of computer aids). Since by convention all the direct information is introduced by using symbols from the
CAD Modelfor
CLASS
SLOT
Activities:
Avg_Noise_Level DaylightingCategory Duration Intensity Max_Permissible_Noise Occurrence(list) Quiet-Noise-Level SummerClo(descriptor) SummerIcl(value) Sunlight_Requirement Thermal_Sensitivity VisualContact WinterClo(descriptor) WinterIcl(value) No_of_Apartments Pti_of_Story Rooms (list) Intensity Period (list) Icl
Aptmt_Types
BasicActivits Clothing_Ens embls: Clock
Performance
353
Evaluation
Noise-Intensity (list) Noise_Source_Coord. (list) WindDirection
Part_of_day (list) Seasons (list) Fig. 6. Slots containing declarative information.
Picking Table (see Fig. 5) it is assumed that the “free hand” drawn lines represent walls. By default, the underlying CAD modeler (AutoCAD) will store the lines on a specially defined layer, namely WALLS. The symbols selected from the Picking Table have a layer of their own (different from WALLS), and contain relevant alphanumeric attributes (such as name, number, destination, type, etc.). Furthermore, the symbols have one or two insertion points. For example, the indication of a specific apartment (using the sign “Ap.” in the Picking Table of Fig. 5) is done by indicating a single reference point, while the staircase (presented in Fig. 5) will be inserted, using two representative corners. For the objects defined by two points, an “artificial” reference point was defined in the middle of the object. Reference points are used by the algorithm that identifies the indicated areas, described below. The definition of the conventional symbols is done by the user and has to match the hierarchies defined in the brief. However, since each designer usually develops a personal pool of conventional symbols, the definition process can be done once. In this process, called “the personalization of the system”, further modifications are enabled upon request. Most of the symbols are externally referenced blocks with attributes. In order to enable the automatic identification (as much as possible) of the physical meaning of the graphic input, the system is provided with a sketch transformer and interpreter. The sketch transformer, implemented in AutoLISP, can be fine tuned to fit the drawing accuracy of the user. Fine tuning is based on two parameters which are easily depicted by the human eye: maximal gap (between lines) that should be closed, and maximal slant
deviation. Figure 7 illustrates the depiction of the two parameters. Although the fine tuning process is interactive and iterative, no more than two iterations are usually necessary to convert the sketch into a drawing that can be evaluated by the system. The sketch transformer works in five steps, described below and exemplified in Fig. 8. The drawings on the left are presented the way the original sketch appears on the computer screen after the completion of each step, while the ones on the right are explosion presentations of the drawings on the left. The five steps performed by the sketch transformer are as folllows. 1. It straightens the segments (makes them horizontal or vertical). 2. It connects the ends of the segments that are within the assumed drawing errors (gap and slant). 3. It transforms the multiple overlapping (or almost overlapping) lines into single lines of maximum length. 4. It trims and connects the corners. 5. It divides the lines into separate segments defined between the intersections. Once the sketch is transformed and the walls segmented, a second algorithm, responsible for identifying adjacencies, is called into action. Since all the walls are segmented, every wall will separate two and only two adjacent spaces. However, the same two spaces can be separated by more than one wall. The performance evaluation is based on the function of the walls (containing closed openings) to separate spaces. Exterior walls are a special case, separating a space from the exterior. The algorithm that identifies the spaces’ boundaries
354
A. Wiezel and R. Becker
Free hand Sketch r
Maxima1 S1ant
This gap will be left open The slant of this line will not change
Corrected
Fig. 7. Depicting
Sketch
the maximal
gap and maximal and,
Step
0
On screen
Exploded
1
2 cl 3 0 4 cl
slant for a sketch
as a consequence.
their
adjacencies,
uses
a simple
to find closed contours. The way the routine works can be best described by using an analogy to a mouse who is trying to exit a room with closed doors (Fig. 9). The mouse starts from a given point and runs to a wall, then runs along the walls in the same direction (clockwise, for example). When the mouse passes the second time through the same point. it has marked all the walls of the given room. Special attention has to be given to the way the mouse turns at intersections. The mouse should follow the path (wall) making the largest angle (clockwise in our convention) with the direction he comes from. Since in the adopted representation walls have no width, several exceptions are intercepted and treated as special cases. (For example, the internal-to-room wall shown in room B of Fig. 9.) The starting points for the algorithm are the reference points of the conventional symbols mentioned earlier. The case of the exterior walls is solved in a similar manner, with the lower left-most corner of the building chosen as a starting point (point S in Fig. 9) the point at which the mouse will start trying to enter the building. The choice of the starting point proved to have a major influence on the simplicity of the algorithm. At the end of the adjacency identification process a wall can be in one of the following situations. routine
I. The spaces (rooms) on both sides are assigned and, as
5 0
far as the performance evaluator is concerned, known with certitude. 2. Only the space on one side is known with certitude. 3. None of the adjacent spaces is known (at this stage of evaluation). Fig. 8. Steps for transforming
a sketch
Because
of the problem
of too many
repetitive
com-
CAD Model for Performance
355
Evaluation
y--__----_----_ti Fig. 9. Identifying contours of rooms and the whole building.
binations, the system walls of types 1 and walls but were drawn recognizable adjacent system.
analyses only situations created by 2. Since lines that do not represent on the sketch will usually have no spaces, they will be ignored by the
5.3. Feedback The interface was developed with the assumption that designers prefer to receive feedback only by request and, therefore, that the user will turn off a system warning that sounds each time an improper decision is emerging. In addition to reducing the annoyance by the system, evaluation upon request allows the designer to complete the information he/she wants to be checked and decreases the wrong guesses of the computer. Appropriate dialog boxes guide the designer in defining the activities of the user and the building hierarchy. Based on the needs of the user, as stated in the brief, and on the information resulting from the interpreted sketch, PREVENT evaluates the following aspects: the view from the inside, thermal comfort and energy usage, ventilation, acoustics, and natural lighting. During the evaluation, the system will make different assumptions based on the data in the brief and the design stage, and will create new data (information*). This type of data is called dynamic data and it is also organized in an object oriented manner (as the declarative information in the description of the design brief). Figure 10 presents a list of the dynamic information generated by the system. The results of the evaluation are stored and presented in six groups. Best design decisions: lists the situations (location and occurrence of activities) that will be particularly well hosted by the building. Non-efficient design decisions: lists the locations that over-perform the needs of the user. It is supposed that those locations can be better used for other activities. Improper design decisions: lists the situations when the needs of the user are not matched. Conflicting situations: lists both the situation and the causes of the conflicts. The system does not attempt to solve the conflict. Examples of identified conflicts
* By defimtion information means structured data.
are: required position of the blinds on summer afternoons during family dining (open for viewing the landscape/closed to prevent high energy gains), status of the window during sleeping in the master bedroom in summer nights (open for ventilation, closed to prevent noise), etc. Hints: similar to best design decisions, with the difference that the locations considered are not assigned by the designer, but by the computer. Possible locations are checked according to the principles explained in section “Predicting the performance”. Warnings: lists the still unassigned locations that are unsuitable for specific activities. An English-like report generator was implemented to present the results. The report is generated automatically by browsing the instances of the objects representing the six categories of evaluation described above. Figure 11 depicts an example of how the values generated by the system fill the slots in the lines of the report. An example of using the system is presented in the Appendix.
6. CONCLUSION Design efficiency and quality can be improved by releasing the designer from the technical activity of performance evaluation and enabling him/her to concentrate on the creative aspects of the design. At the earlier design stages the use of classical geometric modeling as a basis for integrative CAD systems proves to be insufficient for accommodating even conventional performance evaluation. To allow the juxtaposition of several design tasks such as evaluation, data seeking, and coordination, explicit representation of the design decisions should be provided. A comprehensive design model should thus include specific representation means to serve the design evaluators and generators, and a form of common geometric model. Due to the complexity of the considered problems, the design model must have an open data structure, such as tree or lattice, in which any of separate design aspects can have its own representation branch and links to the pertinent data from other branches. This paper focuses
A. Wiezel and R. Becker
356
CLASS Situations:
Functionalities
Conflictual
Activity
Fig. 10. Slots contammg
dynamic
INSTANCE:
SLOT Blinds Blinds-Activity Blinds-Cause Critical_Acoustic_Activity Critical_Thermal_Activity EnergyGain InRoom_Activities (list) Occurrence Opened_Window_Activity Opened Window Cause Other_side_Activ%es (list) Other_side_Room Penetrating-Noise Quiet_Noise_Level Season Thermal-Sensitivity Var Wall
information.
W4_4 1
Parent:
Apl_LivingRoom_Unsuited_Winter Description
=&
I Season = Winter
I Occurrence
= afternoon
I
Room= Api_Livi
1
I
, i:::_.:c1
i
t
. It will be &
in winter afternoons
during family dining near wall I%! in LivingRom
Fig. 11. Example
of report
only on the modeling of a relatively limited section of the design process, the performance evaluation. The prototype intelligent CAD system developed on the basis of the presented design model deals with a limited number of attributes, but it enlightens the complexity of this system on one hand and its advantages on the other. The use of the system may help prevent the
line generated
of&&_!
by PREVENT.
design of both inadequate
and over-designed solutions by extensively comparing the behavior of the building with the user requirements while taking into account their variation during the periods of day and night, summer and winter, etc. It also permits the gaining of extensive experience by providing hints and criticism relative to many different design alternatives.
REFERENCES
I.
M. de Vries and H. Wagter.
A CAAD
model for use in early design phases.
In The Elecrronic~ Design
CAD Model for Performance
2. 3. 4. 5. 6. 7. 8. 9.
10. 11. 12. 13. 14. 15. 16.
Evaluation
351
Studio (Edited by M. McCullough, W. J. Mitchelland P. Purcell), pp. 215-228, MIT Press, Cambridge, MA (1990). S. Port, The Management of CAD for Construction, BSP Professional Books, London (1989). C. M. Eastman, Modeling of buildings: evolution and concepts. Automation in Construction 2, 99% 109 (1992). G. Schmidt, Classes of design ~ classes of tools. In The Electronic Design Studio (Edited by M. McCullough, W. J. Mitchell and P. Purcell), pp. 77790, MIT Press, Cambridge, MA (1990). G. Carrara, Y. E. Kalay and G. Novembri, Multi-modal representation of design knowledge. Automation in Construction 2, 11l-121 (1992). G. A. van Nederveen and F. P. Tolman, Modeling multiple views of buildings. Automation in Construction 2, 215-224 (1992). T. Froese, Project modeling and data standards for AEC: concepts. IRMA-tica’93, E-Mail Workshop on the IRMA modelfor Computer-Integrated Construction, Gopher:
APPENDIX A sample of the use of the system is shown in Figs Al and A2. More dialog boxes collect data about typical clothing, and landscape (see Figs A3-A8).
pfnt
Edit
Eontml
1
Qptions
&indow
Check the design
Image
1
F,
FkRtomance Naluatlon ENllghtment Tool TECHNION ISRAEL :aculty of CMI Engineering
Fig. Al. PREVENT
~ main screen
noise, lighting
358
A. Wiezel and R. Becker
CAD Modelfor
Performance
Evaluation
See Defined ActMy Zones
Dcffne New ActMly Zone
See Deffned Types of Rooms
Dcflnc New Type of Room
Fig. A3. Visualization
Fig. A4. Designation
of the defined room types,
of maximal
linear error.
359
360
A. Wiezel and R. Becker
Fig. A5. Designation
Fig. A6. Use of conventional
of maximal
symbols
angular
errors.
to designate
zones
361
CAD Model for Performance Evaluation
..J.$ ,,;.l’i: ‘i; , / ii >,.-.:,$ ?i‘.* I’
.
/ ;
‘x .’ 7
/
-. fL.z * . -$y;:::
* . ...p+ ?-%. ... .. .. ... .... ... .... .. .. .... ..... ..... ..2..
Fig. A7. Use of conventional
Pint
EdiI control
QpUons
symbols
to designate
orientation
Wndow
It will be Yarn in AfternOOn during FamilyDining It will be Yam in Noon during FamilyDining
It rill be Cold in Afternoon during FamilyDining 11 be Cold in Moon during FamilyDining
Fig. AS. Example
of a report.
(north).