information systems for architectural design - lth · anders ekholm: information systems for...

An

Anders Ekholm

Information systemsfor architectural design– experiences from the BAS·CAAD and ACTIVITY projects

TDwmFflf

ders Ekholm: Information systems for architectural design 1

Architectural design is a process of creative problem solving, moreover,

architects manage not only information about the building but also

about the user organisation. Therefore, information systems for architectural

design must support the development of new ideas and concepts,

and must be able to handle both building and user data. The paper presents

two recently developed prototype applications, built on a conceptual model

for the architectural design process, BAS·CAAD with the objective to support

creative design, and ACTIVITY with the objective to support user activity

modelling as an integrated part of building design.

he revolution of architectural design practiseuring the last ‒ years the personal computer togetherith different software for visualisation, calculation and si-ulation have revolutionised architectural design practise.

or most tasks the drawing-table has been abandoned inavour of the computer platform. Currently, a second revo-ution takes place where building CAD programs are shiftingocus from drawing to modelling.

Model based CAD means that thedesign, i.e. the conceptual model of the designed object, isrepresented externally, outside the mind of the designer.This requires that both the process of design and the objectsof design must be problemised: What is design, and what isdesigned?

The general idea is that model based CAD-programsenable the designer to develop an object based “product”model of the building. Building product models enablecomputer integrated construction and facility manage-ment processes, CIC/FM (Björk ). They also enablenew ways of managing and structuring design information(Eastman ).

However, building design is a complex process involvingknowledge not only of the building or the built environ-ment but also the user organisation activities (Ekholm). The building design process starts with describingthe user organization and its requirements on the building,then, gradually the focus is shifted towards the building, itsconstruction and maintenance.

The design process is a process of search and gradual devel-opment (Simon ). It is less a matter of choice among

2 Nordisk Arkitekturforskning 2001:3

ready-made alternatives than a matter of creative problemsolving. A requirement on computer support for design isthat both functional requirements and technical solutionscan be developed and creatively combined.

The use of model based design and information mana-gement systems in the early stages during the programmingand proposal stages, as well as in the facility managementstages, put new requirements on these systems. Model basedCAD-systems must allow an incremental determination ofproperties, and not prescribe a specific design procedure. Itmust also be able to represent user activities as model objectsindependently from the building or its spaces.

This article presents results from current research intothese areas carried out at the division of Architectural andBuilding Design Methodology at Lund Institute of Tech-nology. Results are presented from the BAS•CAAD projectand the Activity project.

Aspects on building designTheoretical foundation for this researchThe theoretical foundation for this research is based on MarioBunge’s Treatise on Basic Philosophy (Bunge , ,

and ). The concepts used in this paper have beenpresented in earlier writings by the author, the interestedreader is recommended e.g. (Ekholm , and ,and Ekholm and Fridqvist , and ).

General aspects on designThe knowledge needed in different fields of design is sodiverse, e.g. concerning functions and materials, that it isimpossible to learn to design apart from specific knowledgeof the artefacts to be designed Bunge (:). However,there are generic theories of artefacts and of intellectual workthat could be applied in every design field.

The following sections outline some generic aspects ofthe substantive and methodological knowledge that is rele-vant for architects as well as other designers. The first sectionpresents some basic concepts that are needed to describe thereal world and conceptual representations, and the secondsection presents a generic model for the design process.

The development of methods and systems for architec-tural design must be based on knowledge of the architec-tural design process. In order to discuss the subject of archi-tectural design some general aspects of design are necessary

to clarify. The verb design means “to conceive and plan outin the mind”, and the noun design means “a mental project orscheme in which means to an end are laid out” (Webster’s). Accordingly, a design (verb) process results in a de-sign (noun).

Design as conceptual modellingConceptual representationsA design is a conceptual representation of the intended artefactand its realisation. A conceptual representation is made upof concepts that refer to the intended artefact and representits properties. This conceptual representation is developedduring the design process. The building blocks of conceptualrepresentations are two kinds of concepts, classes and attributes.

The process of discriminating between objects, concreteor abstract, results in the formation of kinds or classes, e.g.the class of buildings or the class of ideas (Bunge :).Similarities and differences between objects are based ondifferences in properties. The concept of a property is calledattribute. Class concepts refer to the object as a whole, whileattributes represent the object’s properties (ibid ).

The object-property dichotomy is purely conceptual. Aproperty has no separate existence from the objects thathave them. It may be argued that the concept of property isquestionable and could be regarded unnecessary; and thatit would be sufficient to state that there are different kindsof objects. However, it is epistemologically useful to con-ceptually separate the object from its properties. During aprocess of investigation we attribute properties to objectsand try out our hypothesis by testing whether the objectshave the property or not. For example, design is characte-rized by conceptualising properties and attributing these tothe designed object (Bunge :).

Systems and their propertiesA system is an extremely generic kind of thing; its propertiesare common to every complex thing. A system’s compositionis a set of parts with bonding relations, its environment is aset of things that interact with the system, its structure is theset of all relations, intrinsic and extrinsic, and its mechanismis a set of internal processes. A process is a sequence of events;an activity is a goal-directed process. An artefact is a man-made or man-controlled system; it is made with a purposeto make certain activities possible.

art Ekholm ny 01-09-05, 12.122

Anders Ekholm: Information systems for architectural design 3

A human activity system that involves the use of artefactsis also called a sociotechnical system. Work is a specific kindof activity, it is a useful activity. A sociotechnical system en-gaged in some work activity is in management sciencecalled an ”organisation” (Child ), ”human activity sys-tem” (Checkland ), or ”enterprise” (Bubenko ).

Properties of systems are either intrinsic or mutual. Ex-amples of intrinsic properties are mass and material. A mutual,or relational, property depends on a relation between things.The relation may be functional, i.e. affecting the relatedsystems, e.g. connected-to, sitting-on, or controlling, or theymay be comparative like spatio-temporal properties, e.g.longer-than, to-the-left-of, or during. In a relatively stableenvironment functions and spatio-temporal properties canbe seen as intrinsic properties.

To adopt a view, or aspect, on a system is to observe aspecific set of properties. Of specific interest to design arethe functional and compositional views. A functional viewfocuses on the system’s extrinsic properties, its relations tothe environment, while a compositional view focuses onintrinsic properties, i.e. the properties of the compositionalparts and their structure. See Figure .

Figure 1. Functional and compositional views on systems

Information systems, static and dynamicAn information system is a computer-based system, whichmakes it possible to store and retrieve information of rele-vance to the information needs of a user. It consists of aconceptual schema, an information base and an infor-mation processor (ISO :). The conceptual schema ismade up of entities and relations that refer to and representthe objects that the system handles information about. The

information base holds the entity values, e.g. measurementsor other data that the user determines. The information pro-cessor is a software tool that makes it possible to query andupdate the conceptual schema and the information base.

The conceptual schema can be understood as an externalconceptual representation of the object that the systemhandles information about. The entities of the conceptualschema together with the attribute values in the informa-tion base make up a model of a specific object. Informationsystems assist the user in managing information about anobject. However, statements are restricted to those, whichare made possible by the schema entities and their valuespaces. This is problematic to an information system fordesign since it must assist in the development of a con-ceptual representation, i.e. in the development of the con-ceptual schema.

Information systems can be characterised as dynamic orstatic. The user cannot create new entities in a static system,which must be possible in a dynamic system. In a static system,the model objects have to retain their class and attributesonce instantiated into the model. In a dynamic system theuser would be able to reclassify and exchange attributes ofthe model objects during modelling.

An information system based on a fixed conceptual schema,or without possibilities for reclassification of model objects,is not suitable for creative design, e.g. the earliest, mostdynamic phases, since a fixed schema and static objects areat odds with the evolving semantics of design (Eastman andSiabiris ). The BAS•CAAD system is an example of afully dynamic system, while the ACTIVITY system is staticconcerning definition of new attributes, but to some extentdynamic concerning reclassification of model objects.

Design as problem solvingProblem solvingDesign may be seen as a problem solving process similar toproblem solving in everyday life or in science. Problem sol-ving in general is a process of purposeful exploration, “aproblem arises when a living creature has a goal and doesnot know how this goal is to be reached” (Duncker ).

Therefore, problem recognition requires that a personhas both knowledge and a goal. A goal can be defined as anintended state of a system. The system may be abstract, e.g. ascientific theory, or concrete, e.g. an industry product. The

art Ekholm ny 01-09-05, 12.133


Figure 2. The problem solving process

required knowledge is a background knowledge that allowsthe person to define the goal, and to recognise that certainsolution knowledge is missing. A problem can be defined aslack of solution knowledge in relation to background know-ledge and goal. A thorough discussion of the concept ofproblem may be found in (Bunge ).

A tentative problem solution, also called hypothesis,describes a goal, and a testable cause of action that results inthis goal. The test may be theoretical, relating the solutionto existing knowledge, or empirical, involving an experi-ment or construction and test of the artefact or a model ofit. The specific character of a design problem is its goal, asatisfactory state of a concrete system or process, and acause of action that results in this. During the design process,hypotheses and tests are made alternately, and the intendedartefact and its properties are determined incrementally.

The problem solving cycleEvery design process is initiated by a problem. The problemdefinition is followed first by synthesis, leading to a tentativesolution, and then by analysis, investigating the proposedsolution. The synthesis question is: Which object has theseproperties? And the analysis question is the inverse: Whichproperties does this object have? Synthesis may be regardedas starting from a functional view on the object, proceedingfrom the outside inwards, or top-down, while analysis startsfrom a compositional view, proceeding from the inside

outwards, or bottom-up. The result of analysis is added tothe background knowledge. The design cycle, by Simon(:) called the Generator-Test Cycle, proceeds until asatisfactory solution has been developed. The cycle is illust-rated in Figure .

A design problem may be characterised as open or closed,and the process of problem solving routine or innovative.To a closed problem the determining factors and their com-binations are well known; it may be solved by a routine thatconsists in selecting a prototype solution and determiningthe values of its attributes. To an open problem, neither thedetermining factors nor their combinations are known. Aprototype solution cannot be applied since new kinds ofthings or processes must be explored or invented. Openproblems have been called ”wicked” (Rittel ).

Prototype systems for building designThe BAS•CAAD projectBAS•CAAD is an acronym for Building and User ActivitySystems Modelling for Computer Aided Architectural De-sign. The overall aim of the BAS•CAAD project has been tocontribute to the development of CAAD tools for the earlystages of the design process including brief development.One of the most important results of the BAS•CAAD projectis its conceptual schema, based on the generic concept ofsystem, from which different domain specific frameworksand product models can be built (Ekholm and Fridqvist ).

Design statements consist of attributes that characterisethe designed artefact. The BAS•CAAD system is designed tocollect, analyse and communicate such statements. Designstatements may be complex, involving several kinds of attri-butes, e.g. “red, clay, chimney brick”, or they may be elemen-tary, involving only one attribute, e.g. “chimney brick”.The statements need not be verbal, also D drawings or Dmodels can be treated as design statements. Design state-ments can be stored as library objects, generic or projectspecific. Examples of such objects are everything frombuildings and organisations to construction products, per-sons and equipment.

The entities in the latest implementation of the BAS•CAADschema are ThingClass (T), Relation (R) and UnaryAttribute(A) (ibid). ThingClass refers to concrete systems, UnaryAtt-ribute represents intrinsic properties of concrete systems,and Relation represents relations between, or mutual pro-

art Ekholm ny 01-09-05, 12.134


Figure 3. Examples of user interface windows for the BASoCAAD system

perties of, systems. The term UnaryAttribute designates anintrinsic attribute and not a mutual property, it also servesto distinguish these intrinsic attributes from the generalconcept of attribute used in the text.

A ThingClass consists of a -tuple of sets of attributes,T =(T

G, T

C, R

I, T

E, R

E, A

U). T

G stands for “generic ThingClass”,

TC stands for “composition (or part) ThingClass”, R

I stands for

“intrinsic Relation”, TE stands for “environment ThingClass”,

RE stands for “extrinsic Relation”, and A

U stands for “Unary-

Attribute”. The attributes reflect that a ThingClass can repre-sent a system with composition, environment and structure.

Only seven different types of elementary statements arepossible. The first is the statement “there is a thing calledT”, which corresponds to creating and identifying a Thing-Class. The other six elementary statements are:

• TG: T is a kind of Y (= kind T is a specialisation of Y)

• TC: T is composed of a P part

• RI: T is internally structured, so that a part of kind P

has a RI -relation to a part of kind P

• TE: T has an environment, which includes an E thing

• RE: T is related by an R

E -relation to an E in its environment

• AU: T has the intrinsic property Q.

The ThingClass instance with no other attributes defined,refers to an object with only existence determined. The se-paration of object existence from object attributes allowsthe designer to add or remove attributes as the design pro-cess proceeds. This is a basic requirement on a dynamic in-formation system for creative design, but diverges from themainstream product modelling practice, which is based onthe idea of static information systems and instantiation ofpredefined classes.

The BAS•CAAD system supports generic design opera-tions like generalising, specialising, aggregating, decompo-sing, and adding and removing attributes. Design statementsare stored in instances of ThingClass. Instance attributes arespecified by reference to library objects. In order for theBAS•CAAD system to function in the construction context,it is necessary that its libraries contain entities belonging toestablished building classification and attribute systems.However, today these systems are poorly developed for usein the early design stage (Ekholm b).

The BAS•CAAD system has been implemented in Small-talk, an object oriented programming environment. A se-

quence of implementations are presented in Sverker Frid-qvist’s doctoral thesis (Fridqvist ). Figure shows anexample of a user interface.

Further prototype development may include the followingaspects:

• Inclusion of meta data in the data model, e.g. originator,creation time, and official state

• Separation of function from technical solution in the datamodel or the library structure.

• Development of libraries to provide model objects adaptedfor the needs of the construction and facility manage-ment sector

• Incorporation of functions supported by different BAS•CAAD prototypes into a new prototype system

• Investigation of user interface for dynamic informationsystems for design.

• Further study of dynamic design systems, e.g. concerningautomatic classification, and mapping between classifi-cation systems.

The ACTIVITY prototypeUser activity information in architectural designWhen an organisation is formed or changed, it may requirea new or renewed building. The process of acquiring asuitable building starts with a description of the organisationand its activities. The activity description is used as a basisfor developing a space function program, which defines require-ments on the building’s spaces. The following step includesdevelopment of a building program, which defines additionalrequirements on the building. The building program together

art Ekholm ny 01-09-05, 12.135


Figure 4. The building design process

Figure 5. User interface from ACTIVITY

with the activity description and space program are used asa background for building design, but can also be used forbuilding performance analysis during the facility manage-ment stage. See Figure .

Model based CAD-systems for building design may sup-port the fundamental design steps of problem definition,synthesis and analysis. An application that allows the develop-

ment of a user activity description assists the problem defi-nition work, while the building design application assiststhe synthesis work and allows the designer to document thebuilding property decisions. Building design analysis includestechnical performance, usability and cost calculations. Cer-tain geometrical properties can be visually evaluated, whileother properties can be evaluated through calculation, e.g.fire escape routes, ventilation, and lighting levels. The testresults are used as background knowledge for subsequentdesign process cycles.

Implementation of ACTIVITY

The idea of modelling user activities as an integral part of thebuilding design process is implemented in the ACTIVITYproject. ACTIVITY was developed as an add-on to the esta-blished architectural design software ArchiCAD. An add-on is a separate program that expands the functionality ofanother program, and can only be run within this. ACTIVITYhas its own user interface accessible from the interface ofArchiCAD, e.g. new menus, dialogue boxes, floating pa-lettes, etc.

The basic entity is the Activity. It is based on a functionalview on an organisation or part of an organisation. AnActivity may have other activities as functional parts, or be

a functional part itself of other activities.An Activity is composed of Person and Equip-ment. The constituent Person and Equip-ment may be determined for an Activity atany level in the “hierarchy”. An Activity mayhave Name, Description, Duration, andRelations. There are four Relations that canbe specifically shown: Visibility, Sound, Dis-tance, and Adjacency. These may have valueswhich however, can only be described, func-tionality is not implemented. A Person canonly exist within an Activity. Equipment maybe composed of other Equipment, and canexist independently during the time periodbetween the activities in which it appear.Figure shows an example of the user inter-face.

ACTIVITY has been tested by modellinga small school with its classes. The differentprogram tools have been applied to describe

art Ekholm ny 01-09-05, 12.146


Figure 6. Art in class A, and Computer in class B, observed on a Monday morning

Figure 7. In the 3D mode also the extension in 3D of the Activity Spaces is visible

the lessons during the day as a system of activities.For a more detailed account, see (Ekholm a).An example of the program in use can be seen inFigure , where the floor plan view illustrates Artin class A, and Computer in class B. The activitieswere observed at .: AM, Monday , Sep-tember . In Figure , the same activities andtheir spatial extension are shown in D.

Further investigationsActivity modelling applications may strongly en-hance the functionality of building design software,especially in the problem definition and analysisphases of design. The integration of activity objectsin software for building design opens new possi-bilities for building design methodology develop-ment.

In this prototype it has not been possible toimplement a relation between activities and buil-ding spaces, or functions to manage all the infor-mation needed for space function programming.Several aspects could be investigated in furtherimplementations, for example:

• Illustration of user activities and how they areaccommodated in the building

• Spatial lay-out which coordinates spatial re-quirements of buildings and activities

• Temporal space use analysis for different useduring a time period

• Versatility analysis of the building’s capacityto accommodate different activities

• Space function programs for building designand facility management

• Libraries of activity systems together with theirbuilding requirements

• Process modelling representing input and out-put of processes.

art Ekholm ny 01-09-05, 12.157


ReferencesBJÖRK B.-C. . Requirements and information structures for

building product data models. VTT Publications

(Technical research centre of Finland, Espoo)EASTMAN C. . Building Product Models: Computer En-

vironments Supporting Design and Construction. CRCPr, London.

BUBENKO jr J. A., , ”Extending the scope of informa-tion modelling”, Report No. DSV –. Departmentof Computer and Systems Science, KTH, Stockholm.

BUNGE M. . Ontology I: The Furniture of the World, Vol. of Treatise on Basic Philosophy. Reidel, Dordrecht andBoston.

BUNGE M. . Ontology II: A World of Systems, Vol. ofTreatise on Basic Philosophy. Reidel, Dordrecht andBoston.

BUNGE M. . Epistemology and Methodology I: Exploringthe World, Vol. of Treatise on Basic Philosophy. Reidel,Dordrecht and Boston.

BUNGE M. . Epistemology and Methodology III: Philosophyof Science and Technology, Vol. of Treatise on BasicPhilosophy. Reidel, Dordrecht and Boston.

CHECKLAND P. . Systems Thinking, Systems Practice. JohnWiley & Sons, Chichester.

CHILD J. . Organization: A guide to problems and practice.Paul Chapman Publ. London.

DUNCKER K. , On problem-solving Psychological Mono-graph , No. . Quoted from (Bunge :).

EASTMAN C. M. and A. SIABIRIS . “A generic buildingproduct model incorporating building type informa-tion”. Automation in Construction, (), p. –.

EKHOLM A. a. “Activity objects in CAD programs forbuilding design”. Forthcoming in Proceedings fromCAADFutures . TUE, Eindhoven.

EKHOLM A. b. “BSAB och klassifikation för produkt-modellering och design”. Slutrapport förstudie --. AB Svensk Byggtjänst, Stockholm.

EKHOLM A., , “A systemic approach to building model-ling – analysis of some object-oriented building productmodels”. In: Björk, B.-C. (ed.) CIB W Workshop,Aug. – , Esbo, Finland.

EKHOLM A., , Systemet Människa-Byggnadsverk – Ettontologiskt perspektiv. Statens råd för byggnadsforsk-ning R:, Stockholm.

EKHOLM A. and S. FRIDQVIST, , “A concept of space forbuilding classification, product modelling, and design”.Automation in Construction, (), p. –.

EKHOLM A. and S. FRIDQVIST, , “A dynamic informa-tion system for design applied to the construction con-text”. In: Björk B.-C. and A. Jägbeck (eds) The Life-Cycle of IT Innovations: Proceedings of the CIB W Con-ference, June –, . Royal Institute of Technology,Stockholm.

EKHOLM A. and S. FRIDQVIST, , “Modelling of user or-ganisations, buildings and spaces for the design pro-cess”. In Turk Z. (ed.) Construction on the InformationHighway. Proceedings from the CIB W Workshop, – June , Bled, Slovenia.

FRIDQVIST S. , Property-oriented information systemsfor design. Prototypes for the BAS·CAAD project. (Diss.)Lund Institute of Technology, Lund University, Lund

ISO , Concepts and terminology for the conceptual schemaand the information base ISO/DTR (TC), alsoSIS teknisk rapport . SIS, Stockholm.

RITTEL H. , In N. Cross Developments in Design Met-hodology. John Wiley and Sons, London.

SIMON H. , The Sciences of the Artificial. MIT Press,Cambridge.

WEBSTERS , New Collegiate Dictionary. Electronic edi-tion. G&C Merriam Co.,Springfield, Massachussetts.

FOTO?

Anders Ekholm, Professor of Architectural andBuilding Design Methodology,Dept of Construction and Architecture,Lund Institute of Technology, Lund Universityhttp://www.caad.lth.se/[email protected]

art Ekholm ny 01-09-05, 12.158

information systems for architectural design - lth · anders ekholm: information systems for...

Documents