design space may be narrowed down to building a two story house that is. 2000 square ..... 1) The required fire-resistance ratinq for firewall. separatinq industrial ...
~-----------.-
,
.1
I.N"l'i:GRATING BOILDmG CODES INTO DESIGN SYSTEMS
by Steven M. Cornick Debbie A. Leishman Dr. J. Russell Thomas 1 Abstract The integration of regulatory codes within CAD design system3 is important if designers are to use computers effectively in the design process. At present, regulations only implicitly contain models of objects within their scope and subsystem3. These models need to be made explicit for incorporation into intelligent design system3. This paper outlines one way to incorporate these reference models. The goal is to develop system3 that use both geometric and non geometric (technical and administrative) information about the design process in order to aid the designer in their task. To ensure a flexible system, it is proposed that the reference models (objects in the design and the relationships between the objects) be separated from the technical requirements or constraints prescribed by the regulation. Keywords: Compliance checking, Constraints, Design, Knowledge Representation, Models, Regulations.
1AD correspondence and requests for reprints should be addressed to Dr RusseU Thomas, National Research Council Canada, Building M-20, Montreal Road, Ottawa, Ontario KIA OR6, Canada.
439
BUILD~G CODES INTO DESIGN SYaT&IC&
by
Steven H. Cornick
Debbie A. leishman Dr. J. Russell Thomas Abetrect The integration of re 1 important if designer~a::o~~ codes within CAD design systems is use process. At present, regUlati computers effectively in the design objects within their scope andon~onlY implicitly contain modela Of ~~i~Cit for incorporation intoSin~~~i!~~t ~heeaie models need to be made nes one way to inco ' s lin syst..... This develop systems that user~~~~t;e~he~eireferencemodels. The goal ~:~~ administrative) informatio me r c and non geometric Itechnical designer in their task T~ about the design process in order to aid ~~d that the reference mod~ls o~nsure a flexible system, it is pro sed e between the objects) be se~ar1~c~sfin the design and the relati~ships constraints prescribed by the r:9Ul:~~o~~e technical requirements or Keywords: Compliance h ki Representation, U d 1 c ec nq, Constraints, Oesi nn , Kno~ledne nO e s, Regulationa. ,.." ~ Introduction Design is a goal oriented activi artifact which satisfy certain ;~ that produce~ de3criptions of an (Coyne, R03e~n, Radford aalach ~ormance requlrernents and cOnstraints t~~ of de3iqn includin~ tlnanC~~lran, , Gero, 1990). There are ~n mechanical engineering design f f P11nning of profitable portfolios Y design of bUildinqs. In each 0 unct onal m47hine, and architectural specifications tor a desi d of these, input ~s in the to~ of system produced. The out~~t ~;s~~ ~lonq with con3traints on the final realizes the specific.tions ond e escription of a system that of going from input sat i sfies the constraints Thi space that i5 not ~~~~~~t~~~icates a potenti~lly infinite :e~~~~ess understood in specific domains. in general and only partially syst~ is how to make search i The challenge for computer based desi n time producing "good" designs. n this Space tractable while at the s~
weir
,n bUilding design, architects
-
d
.
~elating to structure3 or parts 4n t englneers take ~pecifications
cbnstraints and through an itera~i structures to be designed along with ve textual material sufficient for h process, produce blueprint3 and t e structure to be constructed. Build.i.ng Deai5/U I t is generally agteed that the f designing structures (As~ow, 196~~~owin9 model deScribes the proce~s of
1
YSiS --> Synthesis --> EValrtion
In the Analysi. pha,e of the model a problem to be solved is analyzed and a statement of goals, requirements, objectives and constraints is produced. The requirements and constraints can be thouqht of toqether as specifying perfonnances required of the system. For example, a problem may be to build a house on a particular site with an objective of ~nimizin9 cost. Uaer requirement. are taken into account along with specifics like size of the lot and soil type. With these understood the design space may be narrowed down to building a two story house that is 2000 square feet on a 50 by 150 foot lot, for example. The Synthe.i. phase repreaents production of the actual designs. In the final stage the designs that have been produced are Evaluatad to see if they meet the original requirements and constraints. In addition, the objectives can be used to rank the designs and identify "better" designs. The above model also shows that this process is iterative and the ev.luation of initial designs CAn lead to another cycle Of Analysis, Synthesis, Evaluation until the designer is satisfied with the results. An important aspect of the model is that it does not require any stage to be completed before moving onto the next. Design of buildings is such a complex task that complete deaign in one paas through the cycle is nearly impossible. We can also characterize the above model of design as defining the search space of applicable designs. One part of this space as shown in Figure 1 represents all designs that can be generated given some description such a, a grammar that defines how components of a design may be configured together. The second space shown in Figure 1 is interpretative and defines the set obtained by taking a design description, interpreting the lines drawn on a page as objects and mapping those objects to certain performances required of the design. Thus the desired designs produced by the above model are the intersection of all possible configurations for specified components of a design with all pos.ible interpr.tations of a design description (Coyne et .1., 1990). That is, an intersection betw.en all possible ·correct" designs and all deaiqna that result from. specified process of deaiqn generation. The id•• of design spaces alao has Lmportant implications for integration of computer based design .ystarns with CAD programs. If designs produced with CAD programs are based on the S&me object. being interpreted for evaluation purpo,es then the two systems can be tied together and work sea~essly. Deeign Type. Both architects and engineers function as designers and thus follow the three phases defined in the above model. The distinction between these two types of designers can be described in two ways. Architects deal mainly with matters of form, proportion, color and texture of buildin9s. Architects thus work mostly at the conceptual stage of design. Engineer. on the other hand work more at the detailed stage of design, and are often constrained by architectural decisions. The second way of describin9 the distinction between architects and engineers is to quantify the constr.ints imposed on them during design. Architects deal with the following constraints When designing: 1) 2) 3) 41
constraints related to design performance and function, constraints related to physical laws, requlatory constraints defined by building codes and standard3 geometric and topological con.traints.
1
Engineers deal mainly with the first three kinds of constraints. 440
441
--------------------··············••••••••
~illlli~···,·1ll1l• •••1M1il1l§~ ...
spaces of designs
~
l"fm:~'
:-;atL
drawinq cereain roo~ such as a kiechen, baehroom and bedroom. This knowledqe can help determine ehe objecta in a drawinq if ehey are noe already labelled. Durinq ehe aceual requiremenes checkinq process it will aqain be beneficial to use extracted buildinq models to help clasaify objecta to be checked. If these models and sub-model. have constrainta associated with them a. waa described above tor synthesis, ehen only thoae conser.ints that apply to specific objects need be checked. This combination of models, constrainea and classification will aid the evaluation process. froc,,:! Model$;
desired designs Fiqure 1.
Desiqn Spaces.
Modala in Desi9J> With • better understand!n of h design, we can look at the 9 mod ~ e ~ffect of conatrainta on building both fit into the desiqn modele ~ t ese constraints apply to and how kinds of models can be identif1~d :nalyst~, s~thesis, evaluation. Two models and process models St s wor 109 w~thin design; static art~fact that is bein9 pr~duce~t;~t~~:uc~ur41 models refer to the actual ar~lfact. Process ~ls refer to the ~ a~ 7he process of prOducinq the be>nq designed. These two t s of ec s>ons ~de as a buildinq is in the three phases of desi~ models have d>fferinq roles to play
Process models alao ex18t within deslqn and represent desiqn actions taken and any decisions related to tho•• actions. The •• models ar. quite difterene from static models and may contain for eXlmple, a sequence of decisions about the choice and application of various prototypes. Such models are important mainly in the synthesis phase, where they can be used to control an automated design process. In addition, havinq an understandinq of these models can also allow for reuse of desiqns. Reuse corresponds to replayinq a desiqn history containinq actions and decisions about actions to aid in the desiqn of a new structure. Psycholoqical studies have shown that reuse of past desiqn histories can often resule in better qualiey desiqns (Akin, 1988) . Havinq discussed the importance and possibility of utili.inq models and constraints within the three desiqn phases, the remainder of this paper will focus on the application of models and constraints to the evaluation phase. The modele represent structures and sub-structures and the constraints represent the requlatory requirements present in buildinq codes.
StAtic Model,
In the ~alysis pha.e of desi n
r
.
attributes identified. These9a~t ~~~rements are analyzed and building OCcupancy and use help to define ~n ~~~si such as buildinq type,
built. This general model can then be t a~ model of the structure to be constraints specified in buildi d use to derive some of the . ng co es and standards that apply and
must be Met.
l~ ~~;t~~t~:~t~e~has;h~he initial
model of the buildinq to be designed constraints. One e~:~~;i~~~i P10cess can aqaio utilize models ~h, synthesis process (Gero , Rosenm:n sl~~;)useT~f prototypes to aid by Ge ro and Rosenman represent v i ' . e prototypes described structures and can be used to re;r abalizedimodels of structures Or subproblems. These proto' s ma resent typ cal SOlutions to desiqn SOlutions for office b~~inq Yfcorrespond to typical structural it 6130 possible to encapS:la~~ :~~~*eth Giv~nla prototypical model, ap~ly as spec1fied in building requl ti e me e constraints that prototype tor apartments might conta~n ~ns't Foir exanple, the stzuctural to floor ~y~te~. ons ra nts that relate bay sizes
an~
1s
The Eyaluation phase also ut'li interpreting drawings and to~ ze~ mo~el~ and constraints both tor
If models of 03siblper orm "9 the conformance Checking code~ .~d regulations t~en the:es~~~c~res Are extracted from building what obJects may be found in a d ' used to set up expectations of represents a residential ho~ th~~w~ng. FO [ example if a drawing
~l.
ADd requlatory cODatraint. in e.aluatiOD of
deai~
In this section we will ex~ne how representing a build1nq regulation as a set ot mod.le and aasociated constraints can be used durinq the evaluation phase ot the desiqn cycle. Specifically we are concerned with checkinq a desiqn for compliance with various buildinq regulations. The regulation we have chosen to work with is the National Building Code of Canada (NBCC, 1985). It was chosen because it is a regulation that is produced by our Institute l and there is considerable local expertise in interpreting the document. We have concentrated on 4 particul.r section of the Buildinq Code 2 , specifically the 15 sentences in the 1985 Building Code regulatinq the construction of firewalle. This section was chosen as it was thouqht to be relatively simple in terms of its scope and the constraints it represents. The compliApce checkiog proce33
Buildinq requlations impose constraint a on desiqners in the form of performance requirements and prescriptive requirements. During the process of design a designer vill have some knowledge of the constraints imposed by various buildinq regulations on the problem. Usually this
process.
you wou ld expect to find within the
1 The In~titute for Research in Construction, National Research Council ot Canada. 2 The terms Building Code and Code shall refer to the National Building Code of Canada.
442 443
I knowledge is a cOmbination of 9
of the designec's experience
1
:~era
.
and 5pec~fic rules that to~ part
potential .olution must be e~aluat;~ew~~~ of one of the design cycles a regulations (in our case the Building Cod ~espe~t to appropriate be • complicated and
time
consuminq tasK e
ExarnTieiev41uation process n ng the compliance
can
checking process will hel . of the design cycle. p us understand aspects of the evaluation phase A design can be considered 4S 4 systam of ass~liea materials. Constituent parts of 4 d 1 ' components, and characteristics Or attributes C as 90 mdy have predefined noncombustible material. A b~iCkO~~~!t~~sfor example, is ~nown to be a
fire-resistance rating. This knowledge is been .~~wn to have a 2 hour part of the background infOrMation of the b~!~~fa ~ kn~wn and forms characteristics of a design must be derived. Th~9s~~e~t e~ther derived information about a buildinN i. the b 1ld' 3 ample of contains a s t f bj i ~ u ~ng.area. A design either knowneorode~iv:~t~C~y~~:~t~i~~t~;9~~~ characteristics that are
regulation.
a.
Where theons of the
selectional constraints and generalization operations for logic and model theory. Of particular interest here are the generali~ation oper.tion~. If two conceptual graphs are compared, it is possible to
3)
concepts in v, if a relation links two conceptS in v then it also links the corresponding concepts in u'.
describe a common generalization of the two graphs. Any two
9raph~ ~ill
always have a
lea~t
one common generalization,
namely [Tl, the universal graph, sinc_ it is a generalization of all graphs. Consider the two graphs ul and u2 and their common generalization v.
Constraint
Sets
u1: u2:
v;~ The projection of the graph v into ul and u2 is then;
Ul':~ u2':
Model ~igure
I.
associated
Models point to ~ets of con~traint3.
lperson:sue~
A introduction to conceptual graphs and the basic graph operations can be found in Leishman (1989). i h f' t Given & conceptual qraph of a desiqn and on~ of,a constra nt, t e lrs A o~ration would be to find a common general~zatlon of the two graphs.
ISS
projection of the co~n generalization into the graph of the design would then select a portion ot it ~Lmil.% to the conatraint. The two
graphs can then be compared by matching them. If the match fails then the constraint is violated. In a design that complies each item ahould match. If there is no common generalization (i.e. the generalization returns [TJ) then the constraint does not apply in the current Context This process is shown in Figure 9. .
compliance checking. Another approach might be to represent the logic of the Building Code separately from the models and constraints. This knowledge would describe how to propagate the constraints. How are mpde]:s and CQo3traint.!l n"efu1")
In aummary, modela and constraints are useful in the compliance cheCking process. Since the models are derived from the Building Code they help in classifying designs with respect to the Building Code by providing a template Or fr&me to match the design against. They are useful in that once a match i. made a set of expectation. i. generated. This can be a • • imple a .et of .lots to be filled in or it may repre.ent information to be derived about a design and cheCked against performance criteria.
a.
Common generalization
Model
Hodels also provide us with access to layers of inherited information. In a bottom-up approach to compliance checking a model can be expanded, by substituting supertypes, until the required information becomes known. This is a sort of baCk propagation of constraints (e.g. if the parapet is 150 mm then the required fire-resistance rating must be two hours therefore the building contains no occupancies of type E or F) . In a top-down approach the models and their associated conatrainta aerve to generate an envelope within which the remainin91 more apeciali&ed
d)
models must lie.
In
effect this is the same as classification.
DiecuaaioA Projection 01 corrvnon generaizatJon Into model if required /. value then fajl
~
L...-_---J
Figure 9. Compliance checking using graph operation~, a) repre~ents a graph of a model, b) represents a graph of a constraint, c) is the common generalization of the model and conatraint, d) is the graph of the projection o~ the common generalization in the model. Checking the constraint then ~nvolves comparing graphs b) and d) .
In this paper we have outlined the broader issues relating the design process, as envls4qed within the construction industry, to computerized
support for such activitiea. The major thrust in this paper has focused upon the evaluation phase of the design process (Asimow 1962) with the description of a system based upon an existing body of regulatory codes (NBCC 1985). Within this approach we have identified the need for both Static and Process models along with their associated constraints imposed by both the regulatory documents and the Users objectives. The derivation of the static models from the regulatory codes has not only provided us with a clearer understanding of the implicit models
I".sue"
contained within the code documents but has also pointed areas of confusion within the documents the~elves. By separating the modele
~here are 3evecal issues regardinq autOmAted compliAnce checking that have not been fully addressed. The first is that the constraints ~the r~ations) can be related to each other. Thi~ linking has
from the constraints imposed by the codes we hope to provide a system which can be adapted to changes in the regulations by chanqing the
impllca~ions in the architecture of any automated cheCking system. There w111 certainly be dependencies Among the attributes and characteristics derived from the Building Code
(probably a direct result
of the fact that the Code is based on implicit models).
It is possible
constraints on the models rather than having to make changes to the
models themselves.
Over time, the models contained in regulatory codes
are stable and the chanqee that do occur are qenerally .,sociated with constraints on the mod.la. The next .tep in our rese.rch prQ9ramme is
the integration of thio system with CAD and an associated object
to map the~e dependenciea into a net~ork of con~trainta. The creation of con3tro~nt networks from buildinq regulations is similar to work done by Neal Holtz (1982) on u~in9 constraint propagation in design and to
oriented database.
The second issue is where should this knowledge reside 9iven the conceptual separation between models and constraints? One approach is to encapsulate all the appropriate knowledqe in the model and constraint sets: Thus several models ml9ht point to the same constraint ~as shown in F1gure 7 above). The constraint dependencies would be contained in
Akin, O. (1988). Expertise of the Architect. In M. D. Rychener lEd.), Expert System" tor Engineering Design lpp. 113-196). San Diego, CA: Academic Press, Inc.
the SASE model IFenves, Wright, Stahl, , Reed, 1981).
the constraint sets.
(56
This approach seems to lend itself to rule-based
Asimow,
w.
(1962).
Introductlon to De3ign. Englewood Cliffs,
New Jersey:
Prentice-Hall.
457
Cornick, S. H., Lehhman 0; A., , Tnomas, J. R. (1990). The Integration of Regulatory Codes with Design Syst.ma. In A. Gulliver (Ed.), Canadian Conference on Electrical and Computer Engineering: Ten Years to 2000, 1 (pp. 14.4.1-14.4.5). Ottawa, Ontario: Canadian Society for Electrical and Computer Engineering. Sept. 4-6.
.
l
.
~
~
J
~
.
~
~
.................:.:.,;!I1llI• •
·
'
"
·
a
1I'...
. ' .
~
O .....
>
••.
-
I111
~
----------------
,
..•..tr,.
&ppaDdi&~.
~ type bierercby and rel.tioD.
The following are definitions of relations used are taken from Sowa p. 415 (1984). agADt. (AGENT) links (ACT) to i(ENTITY )' whlere Zxamp e: represents the actor of tne act on.
Coyne, R. (19901. Logic of Design Actions. Knowledge-Based Systems, 3(4),242-257. Coyne, R. 0., Roseman, H. A., Radford, A. D., salachandran, H" ~ Gero, J. S. (1990). Knowledge-Based Design Systama. Sydney, Australia: Addiaon-Wesley. Fenves, S. J., Wrignt , R. N., Stahl, F. I., , Reed, K. A. (1987). Introduction to SASE: Standards Analysis, Synthesis, and Expression NBSIR 87-3513). National Bureau of Standards, U.S. Department of
to link concepts.
They
i~: ~~I~~ ~;;~:Pt .
attribute. (ATTRIBUTE) links [ENTITY:"x) to (ENTITY:"y) wnere 'x has the attribute "y. Example: The rosa is red.
No.
Conmerce. Gero, J. S., , Rosenman, H. A. (1989). A Conceptual Framework for Knowledge-Based Design Research at Sydney University's Design Computing Unit. In J. S. Garo (Ed.), Artificial Intelligence in Design, 1 (pp. 363-382). Cambridge, UK: Computional Hechanics Publications!SpringerVerlag. July.
10cetioD.
Hamer, J., Hosking, J. G., , Hugridge, W. B. (1988). The Evolution of Class L4nguage No. 75 Building Research Association of New Zealand.
maDA8r. (KANNER) links an (ACT) to an (ATTRIBUTE). ambulance arrived quickly.
Holtz, N. H. (1982) Symbolic Hanipulation of Design Constraints. PhD. Theais, Department of Civil Engineering, Carnegie-Hellon University. Leiahman, O. A. (1989) A Principled Analogical Tool. Haatera Theais, Department of Computer Science, University of Calgary.
(LOC)
links a
(T) to a
[PIeACE).
Example:
Vehicle5 arrive at
• .station.
Ambul.~:'
EXAlllPle:
agent
material. (MATR) links an [ACT) to a (SUBSTANCE) used in the process. Example: The gun w.... carved out of soap.
Hackworth, A. K. (1987). Constraint Satisfaction. In S. C. Shapiro (Ed.), Encyclopedia of Artificial Intelligence (pp. 205-211). New York, New York: Jonn Wiley' Sons. The National Building Code of Canada. National Researcn Council of Canada.
(1985), Ottawa Ontario Canada:
Sowa, J. F. (1984). Conceptu.~ Structure3: Information Hind and Hachine. Don Hills, Ontario: Addison-Wealey.
Proce~slng
object. Example:
(OBJECT) links an (ACT) to an (ENTITY), which is acted upon. The cat swallowed the canary.
in
Vanier, D. J. (1991). A Parsimonious Classification System to Extract P_oject-Specific Building Codea. To appear in Computers and Building Starldard~. Espoo, Finland. June 8-15.
where .y is a part (PART) links an [ENTITY:·X) to an (ENTITY:"y) part. of *x. Example: A finger is part ot a band.
~ A partial type hierarchy of concept' derived from the firewall section of tne Building Code.
459 458
• • • • • • • • • • • • • • • • • • • • • •_.iIIT• •Iill.IliT.rlll....Iil• •5i1~iIi'lil·iiI$:iI'¥l1WI·li·li'·~'1{pt"t'~·iilt~'lw.'"'.."ilo~.·.,.,.·...
UnlveruJ
,..j~-Iil;:i~i1M~,>~:;;5
.....
t
._, -,.. ~ 1""'-
I ~ ~""""'" ~..
Conslructed~?
Flr.. reslsWlCe
Act
rating
/ Fir..raled
Cleate
ConauucUon T~
Pass
Reactlon
I
\.
Prevent
Chemical Reaction
I
Through
FA
/" Fire safety Combustible Noncombustible ConsUUCtion Construction
Aperture
I OperOng
Mobile entity
.........." Flame Heat
Smoke
PhyaObj
Spaoe
\ Artifact
I Atea
/""Place Ban1er
~/ \ ~~oraJea
Asser ~ i~ ConstructIOn assacrbly
Closure
I ~ "'-. ,,/
SLbctance -TIme
Station~ entity
,
/""-Water
Matenal
./ Masonry
Concrete
St~r
Buildong
Building usacrbly
Fir....paration
Wall asoembly
Fire ...paralion means a conatnJ
